더 높은 대역폭의 인터넷 연결이 핑 응답 시간을 줄입니까?


15

연결 속도가 빠를수록 대기 시간이 줄어든다는 것은 분명합니다.하지만 궁금합니다 : 전 세계 반대편의 호스트에서 원격으로 작업하고 있습니다. 빛은 매우 빠르게 (나노 초당 1 피트) 여행 할 수 있으며 우리 모두 광대역 연결을 가지고 있습니다. 1,000kbps 업로드 및 10,000kbps 다운로드 초과 :

더 높은 대역폭 연결은 핑에 걸리는 시간을 줄입니까? 데이터가 매우 적기 때문에 더 빠른 연결이 어떻게 도움이됩니까? 현재 핑은 450ms가 걸립니다. 개선 할 수있는 방법이 있습니까 ??


7
임의의 참고 사항, 3TB 하드 드라이브로 AirBus를 채우고 대서양을 건너면 연결 속도는 수십 Gb / 초이지만 대기 시간은 몇 시간입니다.
Sugudge

450ms는 위성처럼 시작됩니다. 나는 세계의 거의 반쯤 가고 (Chicago-> Berlin) 약 125ms가 있습니다. 이것을 선형으로 취하면 450ms는 전 세계적으로 거의 될 것입니다. 뭔가 이상하다.
TomTom

2
@TomTom-작전은 호주의 프로필에 따라 호주에서 왔으며, 이는 우리 나라의 한심한 대기 시간으로 유명합니다. 내 생각에 그 지연 시간의 대부분은 그의 패킷이 나라를 떠나기 전에 발생한다는 것입니다. TPG와 같은 사람과 함께 있다면 ISP를 떠나기 전에 발생했을 수 있습니다.
Mark Henderson

답변:


24

첫째, 대역폭은 대기 시간과 다릅니다. 연결 속도가 빠르다고해서 반드시 대기 시간이 단축되는 것은 아닙니다. 450ms는 조금 느리게 보이지만 전 세계에서 1/2 길을 가고 있다면 그다지 멀지 않습니다. 기준 프레임으로 고속, 낮은 대기 시간 링크는 미국을 가로 질러 ~ 70-80ms가 소요됩니다. 공급자가보다 최적의 피어링 경로를 가지고 있다고 가정하면 공급자를 변경하여 대기 시간을 조금 줄일 수 있습니다. 그러나 나는 약속 할 수 없습니다.


2
다시 말해서 응답 시간을 향상시키는 유일한 방법은 더 나은 경로를 가진 다른 공급자를 사용하는 것입니다. 그 맞습니까?

2
우리는 더 많은 것을 설명하기 위해 트레이스 루트 (양방향)를 볼 필요가 있습니다. 첫 번째 대기 시간 (마지막 마일)을 알면 다른 공급자가 실제로 도움을 줄지 여부를 결정하는 데 도움이 될 수 있습니다.
m 커크 호프

tracereoutes는 인터넷을 통해 보이는 것처럼 엄청나게

아뇨, 서버가있는 모든 위치에서 트레이스 루트가 제대로 작동합니다. 죄송합니다.
TomTom

연결이 잘못되어 Netlimiter를 사용하여 대역폭을 제한하면 테스트에서 더 높은 핑을 얻습니다. 예를 들어 대역폭의 50 %를 비활성화하면 핑이 크게 증가합니다.
Bluedayz

11

"빠른"연결 (참조로)은 대기 시간을 낮추지 않습니다. "빠른"연결은 주어진 시간에 더 많은 데이터를 와이어에 배치 할 수있게합니다.

대역폭은 용량을 측정 한 것입니다.

지연 시간은 지연의 척도입니다.

편집하다

대역폭과 대기 시간의 차이에 대한 예는 다음과 같습니다. 하나의 10Mbps와 다른 1Mbps의 인터넷 연결 2 개를 상상해보십시오. 둘 다 대기 시간이 50ms입니다. 이제 연결의 다른 쪽 끝에있는 원격 터미널에 키 입력을 보내고 있다고 상상해보십시오. 간단하게하기 위해 각 키 스트로크가 1Mbps의 대역폭을 소비한다고 말할 수 있습니다. 10Mbps 연결에서 문자 A, B, C, D, E, F, G, H, I, J를 동시에 보낼 수 있으므로 모두 50ms 후에 원격 터미널에 도착하여 에코됩니다. 화면 ... 동시에. 이제 1Mbps 연결에서는 각 키 입력이 사용 가능한 모든 대역폭을 사용하기 때문에 각 키 입력이 독립적으로 전송됩니다. 따라서 문자 A가 전송 된 다음 50ms 후에 원격 터미널에서 수신되고 화면에 표시되고 그 다음에 문자 B 50ms가 표시됩니다. 그런 다음 문자 C는 문자 J까지입니다. 10 개의 문자가 모두 원격 터미널에서 수신되고 화면에 에코되는 데 500ms가 소요됩니다. 10Mbps 연결이 더 빠릅니까? 아닙니다. 대기 시간은 1Mbps 연결과 마찬가지로 50ms입니다. 처리량 (대역폭)이 높고 한 번에 더 많은 데이터를 와이어에 배치 할 수있어 더 빠릅니다. 이것이 대역폭 (용량)과 대기 시간 (지연)의 차이입니다. 엄밀한 의미에서 "빠른"연결 (참조하는 방식)은 대기 시간을 줄이지 않습니다. 처리량 (대역폭)이 높고 한 번에 더 많은 데이터를 와이어에 배치 할 수있어 더 빠릅니다. 이것이 대역폭 (용량)과 대기 시간 (지연)의 차이입니다. 엄밀한 의미에서 "빠른"연결 (참조하는 방식)은 대기 시간을 줄이지 않습니다. 처리량 (대역폭)이 높고 한 번에 더 많은 데이터를 와이어에 배치 할 수있어 더 빠릅니다. 이것이 대역폭 (용량)과 대기 시간 (지연)의 차이입니다. 엄밀한 의미에서 "빠른"연결 (참조하는 방식)은 대기 시간을 줄이지 않습니다.


대역폭 연결이 높을수록 핑 응답 시간이 줄어 듭니까? 그렇지 않은 경우 : 더 나은 응답 시간을 얻을 수있는 방법이 있습니까?

1
아닙니다. 설명은 내 편집을 참조하십시오.
joeqwerty

7

연결은 대기 시간과 대역폭의 두 가지 주요 요소로 측정됩니다. "고속"또는 "빠른"과 같은 것은 없습니다. 이들은 두 배의 마케팅을하며 전문적으로 관리되는 연결의 맥락에서 의미가 없습니다.


다른 대역폭 응답과 동일하게 응답 할 수 있습니까? 대역폭이 높을수록 핑 응답 시간이 줄어 듭니까? 그렇지 않은 경우 : 더 나은 응답 시간을 얻을 수있는 방법이 있습니까?

2
대역폭과 대기 시간은 독립적입니다. 대기 시간은 (보통) 연결 매체 (무선이 느리고 모뎀이 느리고 케이블 모뎀이 빠르므로 T1과 광섬유도 빠름), 거리 (전기가 빛의 속도 근처로 이동하여 사용자보다 느림) 혼잡 (당신의 차례를 기다리는 시간이 추가됩니다). 첫 번째 요소는 실제로 제어 할 수있는 유일한 요소입니다.
크리스 S

"하지만 다른 사람보다 초당 더 많은 패킷을 이동합니다"보다는 "고속 연결"이라고 말하는 것이 더 쉽습니다!
JYelton

이해했지만-옳지 않다-은화가 말한 것을 보라. 32 바이트의 핑 (Ping)을 예로 들겠습니다. 각 피어의 대역폭이 초당 32 바이트보다 크고 다른 통신을 수행하지 않는 한 다른 통신사에 도달하는 데 대기 시간이 걸리기 만합니다. 실제로 피어가 32 바이트 핑을 다운로드해야하기 때문에 1 초 이상 대기 시간이 걸리지 만 연결에 초당 320 바이트의 대역폭이 있으면 0.1 초 이상 대기 시간이 걸립니다. 1MB / s를 초과하는 연결에 도달하면 다운로드 시간이 짧습니다. 그러나 실버 파이어가 옳습니다.

2
총 전송 시간은 대기 시간과 동일하지 않습니다. 핑 테스트는 매우 작은 전송을 전송하여 대기 시간을 추정하려고합니다. 대역폭, 특히 극단적 인 예에서 총 전송 시간에 영향을 미친다는 사실은 저에게 또는 표준 핑 테스트를 결정한 사람들이 32 바이트가 될 경우 손실되지 않습니다. 지연 시간은 전송 시작에서 다른 끝에서 수신 시작까지 전송하는 데 걸리는 시간입니다. 과장은 좋은 예를 만든다 : 당신은 100MB의 파일과의 연결을 테스트했고, 그 3 시간이 걸렸다 경우, 연결이 아마 3 시간의 대기 시간이 없습니다.
Chris S

4

여기 핑과 관련하여 말할 점이 있습니다.

일반적으로 ICMP 트래픽은 우선 순위가 높지 않습니다. 따라서 핑 또는 다른 ICMP 기반 트래픽을 사용하여 네트워크 지연 / 대기 시간을 측정하는 것이 정확하지 않습니다.

두 점 사이의 지연은 다음 공식을 사용하여 계산할 수 있습니다.

Total delay = transmission delay + propagation delay + processing delay

전송 지연은 와이어에서 패킷 비트를 푸시하는 시간입니다. 전파 지연은 매체와 관련이 있으며 대상에 도달하는 시간입니다. 처리 지연은 수신 및 송신 기계 / 라우터와 관련이 있습니다.


2

종종 그렇습니다. 그러나이 둘은 같은 것이 아니며 직접 연결되어 있지 않습니다. 일반적으로 더 많은 대역폭을 가진 연결은 사용되는 기술로 인해 대기 시간이 더 짧습니다.

그러나 항상 사실은 아닙니다. 대량의 데이터를 전송하는 빠른 방법을 고려하십시오. 12 개의 2TB 하드 드라이브에 데이터를 채우고 택배로 전송합니다. 데이터 전송 속도는 매우 높습니다 (24 시간 내에 24TB를 전송할 수 있다는 점에서 2000MBps 이상). 대기 시간도 매우 높습니다 (24 시간). 전화 접속은 대기 시간이 훨씬 짧지 만 전화 접속을 통해 24TB를 보내는 데 몇 년이 걸립니다.

둘을 직접 동일시하는 것은 좋지 않습니다. 지연 시간이 짧아야하는 경우 대역폭별로 구매하지 말고 구체적으로 문의해야합니다.


Tanenbaum 인용에 +1, 아마 당신이 그것을 모르는 경우에도 :-)
Massimo

0

지연 시간을 개선하기위한 유일한 실제 솔루션은 문제가있는 두 호스트 간의 홉 수를 줄이는 것입니다.

대기업 고객 인 경우 두 사이트 사이의 IP 경로를 짧게 (아마도 비용이 많이 들게) 만드는 방법에 대해 통신 제공 업체와 대화를 열 수 있어야합니다.


4
홉 수가 반드시 의미하는 것은 아닙니다. 나는 오히려 섬유를 통해 순전히 통과하는 30 홉이있는 경로를 사용하고 그 뒤에 위성 연결이있는 5 홉 경로를 사용하려고합니다.
m 커크 호프

0

당신은 사실을 수집하지 않고 많은 포지셔닝을했습니다. 가장 좋은 방법은 대기 시간이 긴 소스를 식별하는 것입니다. 어디서 시작합니까? 그런 다음 어떻게해야합니까?

traceroute 또는 더 나은 mtr (mytraceroute)을 실행하십시오. Windows를 사용하는 경우 winmtr을 사용할 수 있습니다. PingPlotter 도이를위한 좋은 도구입니다.

대기 시간이 긴 시작 위치를 찾은 다음이를 해결하기 위해 노력하십시오. 문제에 더 많은 대역폭을 던지는 것은 답이 아닙니다.


0

대량 데이터가 대화 형 데이터를 익사시키지 않는 한 높은 대역폭은 큰 도움이되지 않습니다. 양쪽에서 xDSL / 케이블 / 무선 대신 광섬유를 사용하는 경우 RTT에서 20-80ms를 면도 할 수 있습니다.

pingtest.net 을 사용하여 핑 테스트를 수행하여 각 링크의 품질을 확인하십시오. 지연 시간이 중요하지만 / jitter /도 큰 차이를 만들 수 있습니다. 지터가없는 느린 (3 Mbps) 연결보다 지터가있는 빠른 (예 : 15 Mbps) 연결이 훨씬 낫습니다.

TCP 연결 (예 : SSH, 텔넷 등)의 경우 일부 TCP 조정이 도움이 될 수 있습니다.

TCP 액셀러레이터 사용을 볼 수도 있습니다. 상업적인 것들이 있지만 pepsal 은 이미 차이를 만들 수 있습니다.


0

아마도 방화벽 / 라우터가 문제 일 것입니다 ...

고장이 어디에 있는지 실제로 알 수있는 유일한 방법은 위에서 언급 한대로 경로 추적을 수행하는 것입니다.


0

이 질문에 대한 여러 가지 답변이 있으며 정답은 (내 의견으로는) "그것은 달려있다"입니다.

포화 상태 인 경우 1gbit / s 연결 상태인지는 중요하지 않습니다. TCP (및 기타 프로토콜)는 99 %의 사례에서 전송 검사에 의존하므로 QoS 또는 유사한 기술로 올바르게 우선 순위가 지정되지 않습니다.

대칭 (SDSL, 파이버 등) 회선은 일반적으로 대기 시간이 짧은 작업에 더 적합합니다. TX와 RX를 공유하지 않기 때문입니다 (TCL ACK, ICMP 응답 등이 최대 속도로 다운로드하는 경우 방해받지 않음을 의미합니다). 민감한 애플리케이션 (특히 VoIP)에 대한 트래픽을 보장하려면 QoS가 여전히 필요합니다.

놀랍게도 TCP ACK의 우선 순위를 정할 때 Google의 조회수 (및 조회수)는 매우 적습니다. 네트워킹 전문가에게 문의하면 왜 필요한지 알 수 있습니다.


-1

예, 그러나 별로는 아닙니다.

대역폭이 높을수록 다른 패킷이 데이터를 전송하기 전에 패킷을 완전히 다운로드하는 데 걸리는 시간이 줄어들고 전체 패킷을 다운로드하는 데 걸리는 시간도 여기에서 중요한 요소이지만 실제로는 최악의 경우 10-20ms 만 추가됩니다 사례.

대기 시간의 또 다른 가능한 원인은 무선 전송입니다. 거의 모든 형태의 다중 액세스 무선은 일반 가정 무선이든 모바일 무선이든 관계없이 모든 사람이 데이터를 보내기 전에 모든 사람이 데이터 전송을 마칠 때까지 기다려야하기 때문에 대기 시간에 큰 타격을 줄 것입니다. 자신의 데이터. 무선 시스템을 통해 전송하는 사용자가 많을수록 속도와 대기 시간이 느려집니다 (다시, 주로 전송하기 전까지 기다리면서 발생 함)

가장 중요한 요소는 라우터 및 기타 WAN 인프라에서 데이터 패킷을 정렬하는 데 소요되는 시간입니다.

데이터 패킷이 전 세계를 이동하는 데 걸리는 이론상 최소 시간은 약 70ms입니다. 이는 패킷이 빛의 속도로 이동하는 시간입니다.

더 빠른 연결과 다른 ISP의 다른 사람들이 동일한 대기 시간을 겪고 있는지 확인하십시오. ISP 또는 연결로 인한 것일 수 있지만 그 가능성은 거의 없습니다.


짧은 대답입니다. 예, 대기 시간이 줄어들지 만 많지는 않습니다.
Silverfire

-2

대역폭과 지연은 다르지만 완전히 연결되지는 않았습니다. 기본적으로 사실이지만 상황은 흑백이 아닙니다. 사이에 회색 음영이 많이 있습니다.

더 큰 대역폭을 갖는 것이 반드시 더 낮은 지연을 갖는 것을 의미하지는 않으며, 반드시 동일하거나 더 높은 지연을 갖는 것을 의미하지는 않습니다.

호스트에서 대상까지 네트워크 장치와 물리적 미디어로 구성된 인프라에 따라 달라집니다.

한 ISP는 저 / 고 대역폭 연결의 우선 순위를 정할 수 있으며 하드웨어와 소프트웨어에 더 많은 이점을 제공하여 지연에 차이가 발생할 수 있습니다.

그리고 여기에 주어진 다른 예의 정신에서 그렇습니다. 동일한 용량을 가진 20 개의 디스크를 가진 트럭을 가져가는 것이 좋으며,이 20 개의 디스크 중 하나만 가지고 같은 트럭을 가져가는 것이 좋습니다. 그러나 디스크의 무게는 어떻습니까? 더 많은 디스크는 더 많은 연료와 더 느린 가속을 의미합니다. 그러나 트럭 엔진을 교체하면 어떻게됩니까?

따라서 짧은 대역폭과 지연은 다르지만 완전히 연결 해제되지는 않습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.