물리적 거리가 다운로드 속도에 영향을 줍니까?

방금 동료 동료와 논쟁을 벌 였는데 전문가들에게 연락 할 것이라고 생각했습니다. 시나리오는 다음과 같습니다. 연결 속도를 측정하는 웹 사이트를 사용하고있었습니다. 우리는 우리와 멀리 떨어진 서버를 사용하여 테스트했습니다 (우리는 말레이시아에 있고 서버는 미국에 있습니다). 약 2Mbps였습니다. 그런 다음 싱가포르의 서버를 사용해 보니 훨씬 빠릅니다 (약 15Mbps). 제 동료는 그것이 물리적 인 거리 때문이라고 생각했지만 그것이 중요하지 않다고 생각합니다. 처음 이해하면 데이터 교환이 시작되고 데이터 흐름이 시작되면 서버의 위치는 중요하지 않으며 결과는 거의 동일합니다. 여기에 뭔가 빠졌습니까? 실제로 어떻게 작동합니까?

제 동료는 그것이 물리적 인 거리 때문이라고 생각했지만 그것이 중요하지 않다고 생각합니다. 처음 이해하면 데이터 교환이 시작되고 데이터 흐름이 시작되면 서버의 위치는 중요하지 않으며 결과는 거의 동일합니다. 여기에 뭔가 빠졌습니까? 실제로 어떻게 작동합니까?

둘 다 역사의 어느 시점에서 옳았지만 당신의 이해는 대부분 정확합니다 ... 오늘 :). 친구가 전한 대답과 오늘날 우리가 가지고있는 능력 간에는 몇 가지 요소가 변경되었습니다.

• TCP 창 스케일링
• 호스트 버퍼 튜닝

본 결과의 차이는 다음의 영향을받을 수 있습니다.

• 패킷 손실
• 병렬 TCP 전송

TCP Window Scaling : 대역폭 지연 효과

친구가 언급했듯이 TCP의 오래된 구현은 TCP 헤더의 원래 16 비트 수신 창 크기에 의해 부과 된 한계로 인해 어려움을 겪었습니다 ( RFC 793 : 섹션 3.1 참조 ). RWIN은 승인되지 않은 데이터가 단일 TCP 소켓에서 대기 할 수있는 양을 제어합니다. 16 비트 RWIN은 높은 대역폭 지연 제품으로 제한된 인터넷 경로를 중요하게 생각합니다. 오늘날의 고 대역폭 인터넷 연결의 대부분은 16 비트 값으로 제한됩니다.

높은 RTT 값의 경우 매우 큰 RWIN을 갖는 것이 좋습니다. 예를 들어, 말레이시아에서 미국으로의 경로 RTT가 약 200ms 인 경우 원래 TCP RWIN은 2.6Mbps로 제한합니다.

_최대 처리량 = Rcv_Win / RTT

_최대 처리량 = 65535 * 8 / 0.200 *

처리량 _최대 = 2.6Mbps

RFC 1323은 이러한 제한을 극복하기 위해 "TCP 옵션"을 정의했습니다. 이러한 TCP 옵션 중 하나는 "창 크기 조정"입니다. 전체 수신 창 값을 얻기 위해 원래 RWIN 값을 곱하는 스케일 팩터를 도입합니다. 창 스케일링 옵션을 사용하면 최대 RWIN은 1073725440 바이트입니다. 동일한 계산을 적용합니다.

_최대 처리량 = Rcv_Win / RTT

_최대 처리량 = 1073725440 * 8 / 0.200 *

처리량 _최대 = 42.96Gbps

패킷 손실 이 문제가되지 않는 한 TCP는 전송 기간 동안 RWIN을 점차적으로 증가시킵니다 . 지연 시간이 긴 연결에서 실제로 큰 전송 속도를 보려면 큰 파일을 전송해야하므로 (TCP는 시간을 늘릴 시간이 있음) 패킷 손실은 연결에 문제가되지 않습니다.

패킷 손실

태평양 전역의 인터넷 회선이 때때로 혼잡 해집니다. 가족 중 일부는 대만에 거주하며 Google 토크를 사용할 때 일상적으로 문제가 발생합니다. 미국에서 DSL 회선을 핑 (ping) 할 때 패킷 손실이 0.5 % 이상인 경우가 종종 있습니다. "느린"서버에 대한 0.5 %의 손실과 같은 상황이 발생하면 단일 TCP 소켓의 처리량을 매우 쉽게 제한 할 수 있습니다.

병렬 TCP 스트림

참고로, 일부 속도 테스트 웹 사이트는 병렬 TCP 스트림을 사용하여 처리량을 증가시킵니다 . 병렬 TCP 스트림은 경로에 패킷 손실이있는 경우 처리량을 획기적으로 증가시키기 때문에 결과에 영향을 줄 수 있습니다. 4 개의 병렬 TCP 스트림이 1 %의 일정한 패킷 손실로 고통받는 5Mbps 케이블 모뎀을 완전히 포화시키는 것을 보았습니다. 일반적으로 1 % 손실은 단일 TCP 스트림의 처리량을 낮 춥니 다.

보너스 자료 : 호스트 버퍼 튜닝

많은 구형 OS 구현에는 제한된 버퍼를 가진 소켓이있었습니다. 구형 OS (Windows 2000과 같은)의 경우 TCP가 많은 양의 데이터를 기내에서 허용하는지 여부는 중요하지 않습니다. 소켓 버퍼는 큰 RWIN을 활용하도록 조정되지 않았습니다. TCP 전송에서 고성능을 구현 하기 위해 많은 연구가 수행되었습니다 . 최신 운영 체제 (이 답변에서는 Windows Vista 이상을 "현대"라고 부를 수 있음)에는 소켓 버퍼 구현에 더 나은 버퍼 할당 메커니즘이 포함되어 있습니다.

짧은 대답 : 예. 거리는 단일 스트림 대역폭에 영향을 미칩니다.

인터넷은 그 효과를 제한하는 수단을 발전시켜 왔습니다. ACK 지연, 창 크기 조정, 기타 프로토콜 :-) 그러나 물리학은 여전히 ​​결국 승리합니다. 이 경우 너무 많은 홉에 대한 일반적인 네트워크 정체 일 가능성이 훨씬 높습니다. TCP 스트림을 종료하는 데 단 한 번의 드롭 패킷 만 있으면됩니다.

이것에 이미 우수 답변이 동안, 나는 추가 할 : 아니, 속도는 반드시 거리의 영향을받지 않습니다 및 예, 매우 자주 속도는 거리에 의해 영향을받는 모두 사실 수 있습니다.

왜 그런가요?

강력하게 단순화되고 거리가 멀수록 인터넷을 통해 더 많은 "홉"이 발생합니다. 최대 대역폭은 가장 느린 홉 및 일치하는 트래픽에 의해 결정됩니다. 거리가 증가하고 홉 속도가 다소 무작위로 분포됨에 따라 전체 속도가 느려질 확률 이 높아지고 있습니다. 또한 물리가 방해를 받고 대기 시간이 길어지면 링크 속도가 느려질 수 있습니다.

그러나 이것은 당연한 것으로 여겨져서는 안됩니다. 기술을 통해 우리는 거의 모든 원하는 대역폭으로 행성을 포괄하는 연결을 구축 할 수 있습니다. 그러나 대역폭과 거리는 적이며 연결 비용이 크게 증가하여 현재 필요한 연결에만 존재하지 않을 수 있습니다.

물론 이것은 지나치게 단순화되었지만 실제로는 이러한 상황이 매우 자주 발견됩니다. 그리고 놀랍게도 빠른 연결이나 배포 프록시가있을 때가 아닙니다. 그러나 모든 것이 순간이면 인터넷 속도에 대해 거의 생각하지 않습니다 ...

앤드류 마틴 에 따르면 대답은 '그렇다'