다운로드 속도는 홉 수, 각 홉의 지연 시간, 그리고 그들 간의 대역폭에 의해 결정됩니다.
VPN을 사용하면 홉 수가 적어지고 속도가 빨라집니다. 기본적으로 터널을 사용하는 것이죠.
TCP는 받은 바이트를 확인해야 합니다. 아직 확인하지 않은 최대 바이트 수가 있으며, 그 이후에는 전송이 중단됩니다. 지연으로 인해 이로 인해 단일 TCP 스트림의 최대 처리량은 2Gbps에 미치지 못합니다.
만약 귀하의 ISP와 귀하 사이의 파이프가 2Gbps라면, S3 사이의 더 큰 파이프는 무의미해집니다. 병목 현상은 바로 귀하와 ISP 사이의 연결이죠. 그리고 이는 제한될 수 밖에 없어요.
이걸 ‘속이기’ 위한 방법도 있는데, 예를 들어 원본 압축 후 다운로드하고 압축을 푸는 것인데, 서버와 클라이언트가 이 기능을 지원한다면 속도 한도를 넘는 것처럼 보이게 할 수 있습니다.
위의 몇몇 포인트에 대해, VPN이 엔드 투 엔드에서 점보 프레임(jumbo frames)을 사용할 수 있고, 깨끗한 연결은 더 작은 TCP 프레임을 사용할 수도 있어요.
VPN AN은 136787로 PacketHub를 보여주고, Comcast는 7922입니다.
그들이 가정용 사용자에게 2.0Gbps 서비스를 제공한다고 생각하지만, 데이터 센터에서는 1Gbps 스위치를 사용하는 건가요?
그건 오로지 S3로 업로드하는 것에만 해당되는 것 같아요.
추측컨대, VPN이 DNS 문제와 관련이 있을 수 있어요. 문서에 따르면, S3 도메인의 모든 IP에 요청을 분산하는 게 필요할 수도 있겠네요.
VPN을 사용하면 홉 수가 줄어들기 때문에 속도가 향상됩니다.
VPN 연결은 여전히 공개 인터넷을 통해 라우팅됩니다.
이건 큰 윈도우 크기를 사용하는 것이 핵심입니다. TCP로 수 GB/s의 데이터를 전송하는 것은 가능하지만, 양쪽 끝에서 충분히 큰 버퍼가 있어야 합니다. 그렇지 않으면 재전송이 필요할 때 문제죠.
Cloudflare의 관련 기사: https://blog.cloudflare.com/optimizing-tcp-for-high-throughput-and-low-latency/
경로가 다르기 때문에, Comcast는 Amazon과 PNI를 맺었을 가능성이 높고, 혼잡하거나 더 오래 걸리는 경로를 선호할 수 있어요.
PacketHub도 더 좋은 경로를 사용할 수 있겠죠.
tcptraceroute -q 1 <s3.<region>.amazonaws.com 443> 명령어를 시도해보세요.
또한, S3 버킷이 어떤 리전에 있나요?
이건 다운로드와 업로드 모두에 적용됩니다.
주로 장거리 전송에 적용되지만, 효과가 있을 수 있습니다. 한번 시도해보세요.
주요 제공업체의 VPN은 근처의 입구점과 목적지 근처의 출구점을 가지고 있어요. VPN 내부 네트워크는 대부분 스위칭 네트워킹이라 홉이 거의 없습니다.
이게 콘텐츠 가속 서비스의 작동 방식입니다.
몇 가지 시도해봤는데, 가장 중요한 지역은 us-east-1입니다. 모두 비슷한 처리량 한계가 있네요.
트레이서트는 25홉을 보여주는데, 마지막으로 주소가 확인되는 것은 10번째 홉으로 be-1112-cs01.dallas.tx.ibone.comcast.net입니다.
VPN을 사용할 때는 이상하게도 홉이 하나만 보여지고, 20ms 핑이 측정됩니다(일반 63ms보다 빠름). 두 경우 모두 마지막 홉은 s3-1.amazonaws.com이고, IP 주소가 다릅니다. MTR을 사용하면 13-14홉이 나오며, 마지막으로 확인되는 주소는 dls-b23-link.ip.twelve99.net 또는 다른 테스트에서는 be2764.ccr41.dfw02.atlas.cogentco.com입니다.
가장 먼저 만나는 차이점은 두 경우 모두 내 라우터가 아닙니다:
VPN 없음: po-321-339-rur401.denver.co.denver.comcast.net
VPN: v1201.den-cs1-core-1-cdn77.com