현재 데이터 센터를 서해안에서 동해안으로 옮길 지 여부를 결정하려고합니다.

그러나 서해안 위치에서 동해안까지 지연되는 대기 시간이 발생했습니다. 다음은 Chrome에서 작은 .png 로고 파일을 검색하고 개발 도구를 사용하여 요청 소요 시간을 확인한 샘플 결과입니다.

• 서해안에서 동해안까지 :
  215ms 대기 시간, 46ms 전송 시간, 총 261ms
• 서해안에서 서해안까지 :
  114ms 대기 시간, 41ms 전송 시간, 총 155ms

미국 캘리포니아 주 버클리에 위치한 코발리스 (Corvallis, OR)가 지리적으로 내 위치와 더 가까워서 연결 속도가 조금 더 빨라질 것으로 예상합니다. 섬기는 사람. 그것은 .. 나에게 과도하게 보인다. 특히 실제 데이터를 전송하는 데 소요 된 시간이 10 % 만 증가했지만 지연 시간이 100 % 증가했습니다!

그 느낌은 ... 나에게 ..

도움이되는 몇 가지 링크를 찾았습니다 (Google을 통해 더 이상!) ...

• 라우팅 거리가 성능에 크게 영향을 줍니까?
• 지역은 네트워크 대기 시간에 어떤 영향을 줍니까?
• 유럽에서 미국으로의 인터넷 연결 지연

...하지만 권위있는 것은 없습니다.

이게 정상인가요? 정상적인 느낌이 들지 않습니다. 미국 동부 해안에서 서쪽 해안에서 네트워크 패킷을 이동할 때 예상되는 "일반적인"대기 시간은 얼마입니까?

빛의 속도 :
흥미로운 학문적 포인트로 빛의 속도를 이길 수는 없습니다. 이 링크 는 스탠포드에서 보스턴까지 가능한 최대 40ms에서 작동합니다. 이 사람이 계산을 할 때 인터넷이 "광속의 2 배 이내"에서 작동한다고 결정했기 때문에 전송 시간은 약 85ms입니다.

TCP 창 크기 :
전송 속도 문제가있는 경우 수신 창 tcp 크기를 늘려야 할 수 있습니다. 대기 시간이 긴 고 대역폭 연결 ( "긴 지방 파이프"라고 함) 인 경우 창 크기 조정을 활성화해야 할 수도 있습니다. 따라서 큰 파일을 전송하는 경우 창 업데이트를 기다릴 필요없이 파이프를 채울 수있는 충분한 수신 창이 있어야합니다. 나는 내 대답 Tuning a Elephant 에서 그것을 계산하는 방법에 대해 자세히 설명했습니다 .

지리 및 대기 시간 :
일부 CDN (Content Distribtuion Networks)의 실패 지점은 대기 시간과 지리를 동일시한다는 것입니다. 구글은 그들의 네트워크에 대해 많은 연구를했고 이것에 결함을 발견했다. 그들은 CDN 성능을 최적화하기 위해 엔드-투-엔드 경로 정보를 넘어서 백서에 결과를 발표했다 .

첫째, 대부분의 클라이언트가 지리적으로 가까운 CDN 노드를 통해 서비스를 제공하더라도 상당수의 클라이언트는 동일한 지역의 다른 클라이언트보다 대기 시간이 수십 밀리 초 더 높습니다. 둘째, 대기열 지연은 종종 클라이언트가 근처 서버와 상호 작용하는 이점을 무시한다는 것을 알았습니다.

BGP 피어링 :
또한 BGP (핵심 인터넷 라우팅 프로토콜) 및 ISP가 피어링을 선택하는 방법을 배우기 시작하면 재정 및 정치에 대한 정보가 더 많다는 것을 알게 될 것입니다. ISP에서. 유리 라우터를 사용하여 IP가 다른 ISP (Autonomous Systems)에 어떻게 연결되어 있는지 확인할 수 있습니다 . 특별한 후이즈 서비스를 사용할 수도 있습니다 .

whois -h v4-peer.whois.cymru.com "69.59.196.212"
PEER_AS | IP               | AS Name
25899   | 69.59.196.212    | LSNET - LS Networks
32869   | 69.59.196.212    | SILVERSTAR-NET - Silver Star Telecom, LLC

또한 linkrank 와 같은 gui 도구를 사용하여 이러한 피어링을 탐색하는 것이 재미 있으며 주변 인터넷 사진을 제공합니다.

이 사이트 는 미국 동부와 서부 해안 사이의 대기 시간이 약 70-80ms (일반적으로 샌프란시스코에서 뉴욕으로)라고 제안합니다.

대서양 횡단 경로
NY 78 런던
워시 87 프랑크푸르트

태평양 횡단 경로
SF 147 홍콩

미국 횡단 경로
SF 72 뉴욕

여기 내 타이밍이 있습니다 (저는 영국 런던에 있습니다. 따라서 서해안 시간이 동쪽보다 높습니다). 대기 시간 차이가 74ms이며 해당 사이트의 가치를 지원하는 것 같습니다.

NY - 108ms latency, 61ms transfer, 169 total
OR - 182ms latency, 71ms transfer, 253 total

이는 Chrome 개발 도구를 사용하여 측정되었습니다.

가능하면 ICMP로 먼저 측정하십시오. ICMP 테스트는 일반적으로 기본적으로 매우 작은 페이로드를 사용하고 3 방향 핸드 셰이크를 사용하지 않으며 HTTP처럼 스택에서 다른 응용 프로그램과 상호 작용할 필요가 없습니다. 어떤 경우이든 HTTP 결과가 ICMP 결과와 섞이지 않는 것이 가장 중요합니다. 그들은 사과와 오렌지입니다.

Rich Adams 의 대답에 따라 그가 추천 한 사이트 를 사용 하면 AT & T의 백본에서 ICMP 트래픽이 SF와 NY 끝점 사이를 이동하는 데 72ms가 걸린다는 것을 알 수 있습니다. 이는 당연한 일이지만 AT & T가 완전히 제어하는 ​​네트워크에 있다는 것을 명심해야합니다. 가정 또는 사무실 네트워크로의 전환은 고려하지 않습니다.

소스 네트워크에서 careers.stackoverflow.com에 대해 핑을 수행하는 경우 72ms (+/- 20ms)에서 너무 멀지 않은 것을 볼 수 있습니다. 이 경우 둘 사이의 네트워크 경로가 정상이고 정상 범위 내에서 실행되고 있다고 가정 할 수 있습니다. 그렇지 않다면 당황하지 말고 다른 곳에서 측정하십시오. ISP가 될 수 있습니다.

통과했다고 가정하면 다음 단계는 응용 프로그램 계층을 처리하고 HTTP 요청에 표시되는 추가 오버 헤드에 문제가 있는지 확인하는 것입니다. 하드웨어, OS 및 응용 프로그램 스택으로 인해 앱마다 다를 수 있지만, 동해안에 거의 동일한 장비가 있기 때문에 동해안 사용자가 서해안 서버에 도달하고 서해안 사용자가 동쪽에 도달 할 수 있습니다 연안. 두 사이트가 모두 올바르게 구성된 경우 모든 숫자가 동일하게 표시되지 않으므로 사용자가보고있는 것이 대략적으로 동등하다는 것을 보여줄 수 있습니다.

이러한 HTTP 시간에 차이가 크면 성능이 느린 사이트에 구성 문제가있는 경우 놀라지 않을 것입니다.

이제이 시점에 도달하면 앱 측에서 좀 더 적극적인 최적화를 시도하여 해당 숫자를 전혀 줄일 수 있는지 확인할 수 있습니다. 예를 들어 IIS 7을 사용하는 경우 캐싱 기능 등을 활용하고 있습니까? 어쩌면 당신은 거기에서 무언가를 이길 수 있습니다. TCP 창과 같은 저수준 항목을 조정할 때 스택 오버플로와 같은 것에 많은 영향을 미칠 것이라고 회의적입니다. 그러나 당신은 그것을 시도하고 측정 할 때까지 알 수 없습니다.

여기에 대한 답변 중 일부는 설명을 위해 ping 및 traceroute를 사용하고 있습니다. 이러한 도구는 그 자리에 있지만 네트워크 성능 측정에는 신뢰할 수 없습니다.

특히 (적어도 일부) Juniper 라우터는 ICMP 이벤트 처리를 라우터의 제어 평면으로 보냅니다. 이는 특히 백본 라우터에서 전달 평면보다 훨씬 느립니다.

ICMP 응답이 라우터의 실제 전달 성능보다 훨씬 느릴 수있는 다른 상황이 있습니다. 예를 들어 CPU 용량의 99 % 인 모든 소프트웨어 라우터 (전문 포워딩 하드웨어는 없음)가 여전히 트래픽을 잘 이동하고 있다고 가정하십시오. 추적 경로 응답을 처리하거나 트래픽을 전달하는 데 많은주기를 소비하고 싶습니까? 따라서 응답 처리는 우선 순위가 매우 낮습니다.

결과적으로 핑 / 추적 경로는 합리적인 상한선을 제공합니다 .

어쨌든-

다음은 미시간 대학교 (미국 중부)에서 스탠포드 (미국 서해안)까지의 추적 경로입니다. (그것은 "잘못된"방향으로 500 마일 떨어진 워싱턴 DC (미국 동부 해안)를 경유하여 발생합니다.)

% traceroute -w 2 www.stanford.edu
traceroute to www-v6.stanford.edu (171.67.215.200), 64 hops max, 52 byte packets
 1  * * *
 2  * * *
 3  v-vfw-cc-clusta-l3-outside.r-seb.umnet.umich.edu (141.211.81.130)  3.808 ms  4.225 ms  2.223 ms
 4  l3-bseb-rseb.r-bin-seb.umnet.umich.edu (192.12.80.131)  1.372 ms  1.281 ms  1.485 ms
 5  l3-barb-bseb-1.r-bin-arbl.umnet.umich.edu (192.12.80.8)  1.784 ms  0.874 ms  0.900 ms
 6  v-bin-arbl-i2-wsu5.wsu5.mich.net (192.12.80.69)  2.443 ms  2.412 ms  2.957 ms
 7  v0x1004.rtr.wash.net.internet2.edu (192.122.183.10)  107.269 ms  61.849 ms  47.859 ms
 8  ae-8.10.rtr.atla.net.internet2.edu (64.57.28.6)  28.267 ms  28.756 ms  28.938 ms
 9  xe-1-0-0.0.rtr.hous.net.internet2.edu (64.57.28.112)  52.075 ms  52.156 ms  88.596 ms
10  * * ge-6-1-0.0.rtr.losa.net.internet2.edu (64.57.28.96)  496.838 ms
11  hpr-lax-hpr--i2-newnet.cenic.net (137.164.26.133)  76.537 ms  78.948 ms  75.010 ms
12  svl-hpr2--lax-hpr2-10g.cenic.net (137.164.25.38)  82.151 ms  82.304 ms  82.208 ms
13  hpr-stanford--svl-hpr2-10ge.cenic.net (137.164.27.62)  82.504 ms  82.295 ms  82.884 ms
14  boundarya-rtr.stanford.edu (171.66.0.34)  82.859 ms  82.888 ms  82.930 ms
15  * * *
16  * * *
17  www-v6.stanford.edu (171.67.215.200)  83.136 ms  83.288 ms  83.089 ms

특히, 워시 라우터와 atla 라우터 (홉 7 & 8) 의 추적 경로 결과의 시간 차이에 유의하십시오 . 네트워크 경로는 먼저 씻은 다음 atla로 이동합니다. 세척에는 50-100ms가 걸리고 atla는 약 28ms가 걸립니다. 분명히 atla는 더 멀리 있지만 traceroute 결과는 더 가깝습니다.

네트워크 측정에 대한 많은 정보는 http://www.internet2.edu/performance/ 를 참조 하십시오 . (면책 조항, 나는 internet2에서 일했었다). 참조 : https://fasterdata.es.net/

원래 질문에 특정 관련성을 추가하려면 ... 스탠포드까지 83ms 왕복 핑 시간이 있었으므로 네트워크가 적어도이 속도로 진행될 수 있음을 알고 있습니다.

이 추적 경로에서 수행 한 연구 및 교육 네트워크 경로는 일반 인터넷 경로보다 빠를 수 있습니다. R & E 네트워크는 일반적으로 연결을 초과 프로비저닝하므로 각 라우터의 버퍼링이 불가능합니다. 또한 실제 교통량을 명확하게 나타내지 만 해안에서 해안까지의 긴 물리적 경로를 기록하십시오.

미시간-> 워싱턴, dc-> 애틀랜타-> 휴스턴-> 로스 앤젤레스-> 스탠포드

나는 일관된 차이점을보고 있으며 노르웨이에 앉아 있습니다.

serverfault       careers
  509ms            282ms
  511ms            304ms
  488ms            295ms
  480ms            274ms
  498ms            278ms

이는 Chrome의 리소스보기를 사용하고 각 링크를 반복해서 새로 고치는 과학적 정확하고 입증 된 방법으로 측정되었습니다.

서버 오류에 대한 경로 추적

Tracing route to serverfault.com [69.59.196.212]
over a maximum of 30 hops:

  1    <1 ms     1 ms    <1 ms  81.27.47.1
  2     2 ms     1 ms     1 ms  qos-1.webhuset.no [81.27.32.17]
  3     1 ms     1 ms     1 ms  81.27.32.10
  4     1 ms     2 ms     1 ms  201.82-134-26.bkkb.no [82.134.26.201]
  5    14 ms    14 ms    14 ms  193.28.236.253
  6    13 ms    13 ms    14 ms  TenGigabitEthernet8-4.ar1.OSL2.gblx.net [64.209.94.125]
  7    22 ms    21 ms    21 ms  te7-1-10G.ar3.cph1.gblx.net [67.16.161.93]
  8    21 ms    20 ms    20 ms  sprint-1.ar3.CPH1.gblx.net [64.212.107.18]
  9    21 ms    21 ms    20 ms  sl-bb20-cop-15-0-0.sprintlink.net [80.77.64.33]
 10   107 ms   107 ms   107 ms  144.232.24.12
 11   107 ms   106 ms   105 ms  sl-bb20-msq-15-0-0.sprintlink.net [144.232.9.109]
 12   106 ms   106 ms   107 ms  sl-crs2-nyc-0-2-5-0.sprintlink.net [144.232.20.75]
 13   129 ms   135 ms   134 ms  sl-crs2-chi-0-15-0-0.sprintlink.net [144.232.24.208]
 14   183 ms   183 ms   184 ms  sl-crs2-chi-0-10-3-0.sprintlink.net [144.232.20.85]
 15   189 ms   189 ms   189 ms  sl-gw12-sea-2-0-0.sprintlink.net [144.232.6.120]
 16   193 ms   189 ms   189 ms  204.181.35.194
 17   181 ms   181 ms   180 ms  core2-gi61-to-core1-gi63.silverstartelecom.com [74.85.240.14]
 18   182 ms   182 ms   182 ms  sst-6509b-gi51-2-gsr2-gi63.silverstartelecom.com [74.85.242.6]
 19   195 ms   195 ms   194 ms  sst-6509-peak-p2p-gi13.silverstartelecom.com [12.111.189.106]
 20   197 ms   197 ms   197 ms  ge-0-0-2-cvo-br1.peak.org [69.59.218.2]
 21   188 ms   187 ms   189 ms  ge-1-0-0-cvo-core2.peak.org [69.59.218.193]
 22   198 ms   198 ms   198 ms  vlan5-cvo-colo2.peak.org [69.59.218.226]
 23   198 ms   197 ms   197 ms  stackoverflow.com [69.59.196.212]

Trace complete.

경력에 대한 Traceroute

Tracing route to careers.stackoverflow.com [64.34.80.176]
over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  81.27.47.1
  2     2 ms     1 ms    <1 ms  qos-1.webhuset.no [81.27.32.17]
  3     1 ms     1 ms     1 ms  81.27.32.10
  4     1 ms     1 ms     2 ms  201.82-134-26.bkkb.no [82.134.26.201]
  5    12 ms    13 ms    13 ms  193.28.236.253
  6    13 ms    14 ms    14 ms  TenGigabitEthernet8-4.ar1.OSL2.gblx.net [64.209.94.125]
  7    21 ms    21 ms    21 ms  ge7-1-10G.ar1.ARN3.gblx.net [67.17.109.89]
  8    21 ms    20 ms    20 ms  tiscali-1.ar1.ARN3.gblx.net [64.208.110.130]
  9   116 ms   117 ms   122 ms  xe-4-2-0.nyc20.ip4.tinet.net [89.149.184.142]
 10   121 ms   122 ms   121 ms  peer1-gw.ip4.tinet.net [77.67.70.194]
 11     *        *        *     Request timed out.

불행히도, 이제 루프 또는 다른 것으로 시작하여 30 홉까지 스타와 타임 아웃을 계속 한 다음 끝납니다.

트레이스 라우트는 시작 시점과 다른 호스트에서 온 것이므로 호스트 서버로 RDP를 실행해야했습니다.

동해안과 서해안의 잘 연결되고 잘 측정 된 링크에서 약 80-90ms의 대기 시간이 보입니다.

대기 시간을 얻는 위치를 확인하는 것이 흥미로울 것입니다. 레이어 4 트레이스 루트 (lft)와 같은 도구를 사용해보십시오. "마지막 마일"(즉, 지역 광대역 제공 업체)에서 얻을 수있는 많은 기회가 있습니다.

전송 시간이 약간만 영향을받는 것으로 예상됩니다. 패킷 손실과 지터는 두 위치 간의 전송 시간 차이를 조사 할 때보다 유용한 측정 값입니다.

유럽에서 온라인 게임 리니지 2 NA를 출시했을 때의 재미 :

Response time to east coast servers: ~110-120ms
Response time to west coast servers: ~190-220ms

이 차이는 예측할 수없는 인터넷의 특성을 고려하여 최대 100ms가 이성 내에 있음을 지원하는 것으로 보입니다.

저명한 Chrome 새로 고침 테스트를 사용하여 약 130ms와 다른 문서로드 시간을 얻습니다.

여기의 모든 사람들은 정말 좋은 지적이 있습니다. 자신의 POV에서 정확합니다.

그리고 여기에는 실제 정확한 대답이 없습니다. 왜냐하면 너무 많은 변수가 있기 때문에 주어진 대답은 백 변수 중 하나를 변경하여 항상 잘못 입증 될 수 있기 때문입니다.

72ms의 NY에서 SF 대기 시간은 패킷 캐리어의 PoP에서 PoP 로의 대기 시간입니다. 여기에는 PoP에서 PoP 로의 완벽한 세계 사이에서 정체, 패킷 손실, 서비스 품질, 비 순차적 패킷 또는 패킷 크기 또는 네트워크 경로 재 지정에 대해 여기에서 지적한 다른 위대한 요점을 고려하지 않았습니다. .

그런 다음 PoP에서 두 도시 내 실제 위치까지 마지막 마일 (일반적으로 수 마일)을 추가하면 이러한 모든 변수가 훨씬 유동적이되어 합리적인 추측 가능성에서 기하 급수적으로 증가하기 시작합니다!

예를 들어 나는 영업일에 뉴욕시와 SF 사이에서 테스트를 실시했습니다. 전 세계에서 교통 상황을 유발할 수있는 주요 "사고"가 없었던 날이 일을했습니다. 아마도 이것은 오늘날 세계에서 평균이 아니 었습니다! 그럼에도 불구하고 그것은 내 시험이었다. 실제로이 기간 동안 그리고 각 해안의 정상적인 업무 시간 동안 한 사업장에서 다른 사업장으로 측정했습니다.

동시에 웹에서 회로 공급자 번호를 모니터링했습니다.

결과는 사업장 위치의 문에서 문까지 88에서 100 ms 사이의 대기 시간 숫자였습니다. 여기에는 사무실 간 네트워크 대기 시간 숫자가 포함되지 않았습니다.

서비스 제공 업체 네트워크 대기 시간은 70 ~ 80ms입니다. 마지막 마일 대기 시간은 18에서 30ms 사이 일 수 있습니다. 두 환경 사이의 정확한 최고점과 최저점을 상관시키지 않았습니다.

NYC 타이밍 :

NY     OR
109ms  271ms
72ms   227ms
30ms   225ms
33ms   114ms
34ms   224ms

가정용 연결에서 Chrome 사용.

뉴저지 주 뉴 어크에있는 데이터 센터의 VPS에서 lft 사용 :

terracidal ~ # lft careers.stackoverflow.com -V
Layer Four Traceroute (LFT) version 3.0
Using device eth0, members.linode.com (97.107.139.108):53
TTL LFT trace to 64.34.80.176:80/tcp
 1  207.192.75.2 0.4/0.5ms
 2  vlan804.tbr2.mmu.nac.net (209.123.10.13) 0.4/0.3ms
 3  0.e1-1.tbr2.tl9.nac.net (209.123.10.78) 1.3/1.5ms
 4  nyiix.Peer1.net (198.32.160.65) 1.4/1.4ms
 5  oc48-po3-0.nyc-75bre-dis-1.peer1.net (216.187.115.134) 1.6/1.5ms
 6  216.187.115.145 2.7/2.2ms
 7  64.34.60.28 2.3/1.8ms
 8  [target open] 64.34.80.176:80 2.5ms

terracidal ~ # lft serverfault.com -V
Layer Four Traceroute (LFT) version 3.0
Using device eth0, members.linode.com (97.107.139.108):53
TTL LFT trace to stackoverflow.com (69.59.196.212):80/tcp
 1  207.192.75.2 36.4/0.6ms
 2  vlan803.tbr1.mmu.nac.net (209.123.10.29) 0.4/0.4ms
 3  0.e1-1.tbr1.tl9.nac.net (209.123.10.102) 1.3/1.4ms
 4  nyk-b3-link.telia.net (213.248.99.89) 1.6/1.4ms
 5  nyk-bb2-link.telia.net (80.91.250.94) 1.9/84.8ms
 6  nyk-b5-link.telia.net (80.91.253.106) 1.7/1.7ms
 7  192.205.34.53 2.1/2.1ms
 8  cr1.n54ny.ip.att.net (12.122.81.106) 83.5/83.6ms
 9  cr2.cgcil.ip.att.net (12.122.1.2) 82.7/83.1ms
10  cr2.st6wa.ip.att.net (12.122.31.130) 83.4/83.5ms
11  cr2.ptdor.ip.att.net (12.122.30.149) 82.7/82.7ms
12  gar1.ptdor.ip.att.net (12.123.157.65) 82.2/82.3ms
13  12.118.177.74 82.9/82.8ms
14  sst-6509b-gi51-2-gsr2-gi63.silverstartelecom.com (74.85.242.6) 84.1/84.0ms
15  sst-6509-peak-p2p-gi13.silverstartelecom.com (12.111.189.106) 83.3/83.4ms
16  ge-0-0-2-cvo-br1.peak.org (69.59.218.2) 86.3/86.2ms
**  [neglected] no reply packets received from TTLs 17 through 18
19  [target closed] stackoverflow.com (69.59.196.212):80 86.3/86.3ms