거리에 따른 느린 전송

NY Datacenter에서 멀리 떨어진 지역으로 이전하는 경우 성능이 저하됩니다.

속도 테스트를 사용하여 다양한 위치를 테스트함으로써 100mbit 업 링크를 보스턴과 필라델피아로 쉽게 포화시킬 수 있습니다. 속도 테스트를 사용하여 미국이나 유럽의 서해안에 위치 할 때 종종 약 9mbit / s 만 보입니다.

첫 번째 반응은 이것이 창 스케일링 문제 (대역폭 지연 제품)라는 것입니다. 그러나 서해안의 테스트 시스템에서 Linux 커널 매개 변수로 조정하고 iperf를 사용하여 Window가 초당 100 메가 바이트를 지원하기에 충분한 크기로 조정되고 여전히 느린 속도를 갖습니다 (Capture에서 확인 됨). 또한 Nagle 알고리즘을 비활성화하려고 시도했습니다.

우리는 Linux와 Windows 모두에서 성능이 떨어지지 만 Windows를 사용하는 속도는 (1/3) 크게 떨어집니다.

전송 형태 (Nagle 제외)는 다음과 같습니다.

10 초 정도의 딥은 ~ 100 개의 중복 킥을 가지고 있습니다.

시간에 따른 수신기의 최소 창 크기의 모양은 다음과 같습니다.

병목을 고정하기 위해 어디로 가야할지에 대한 아이디어가 있습니까?

일부 속도 테스트 결과 (speedtest.net을 사용하여 업로드) :

• 필라델피아 : 44 mbit (우리 사이트를 이용하는 사람들은 나머지를 사용하고 있습니다 ;-))
• 마이애미 : 15mbit
• 댈러스 : 14mbit
• 산호세 : 9 mbit
• 베를린 : 5mbit
• 시드니 : 2.9mbit

더 많은 데이터 :
마이애미 : 69.241.6.18

 2  stackoverflow-nyc-gw.peer1.net (64.34.41.57)  0.579 ms  0.588 ms  0.594 ms
 3  gig4-0.nyc-gsr-d.peer1.net (216.187.123.6)  0.562 ms  0.569 ms  0.565 ms
 4  xe-7-2-0.edge1.newyork1.level3.net (4.78.132.65)  0.634 ms  0.640 ms  0.637 ms
 5  vlan79.csw2.newyork1.level3.net (4.68.16.126)  4.120 ms  4.126 ms vlan89.csw3.newyork1.level3.net (4.68.16.190)  0.673 ms
 6  ae-81-81.ebr1.newyork1.level3.net (4.69.134.73)  1.236 ms ae-91-91.ebr1.newyork1.level3.net (4.69.134.77)  0.956 ms ae-81-81.ebr1.newyork1.level3.net (4.69.134.73)  0.600 ms
 7  ae-10-10.ebr2.washington12.level3.net (4.69.148.50)  6.059 ms  6.029 ms  6.661 ms
 8  ae-1-100.ebr1.washington12.level3.net (4.69.143.213)  6.084 ms  6.056 ms  6.065 ms
 9  ae-6-6.ebr1.atlanta2.level3.net (4.69.148.105)  17.810 ms  17.818 ms  17.972 ms
10  ae-1-100.ebr2.atlanta2.level3.net (4.69.132.34)  18.014 ms  18.022 ms  18.661 ms
11  ae-2-2.ebr2.miami1.level3.net (4.69.140.141)  40.351 ms  40.346 ms  40.321 ms
12  ae-2-52.edge2.miami1.level3.net (4.69.138.102)  31.922 ms  31.632 ms  31.628 ms
13  comcast-ip.edge2.miami1.level3.net (63.209.150.98)  32.305 ms  32.293 ms comcast-ip.edge2.miami1.level3.net (64.156.8.10)  32.580 ms
14  pos-0-13-0-0-ar03.northdade.fl.pompano.comcast.net (68.86.90.230)  32.172 ms  32.279 ms  32.276 ms
15  te-8-4-ur01.northdade.fl.pompano.comcast.net (68.85.127.130)  32.244 ms  32.539 ms  32.148 ms
16  te-8-1-ur02.northdade.fl.pompano.comcast.net (68.86.165.42)  32.478 ms  32.456 ms  32.459 ms
17  te-9-3-ur05.northdade.fl.pompano.comcast.net (68.86.165.46)  32.409 ms  32.390 ms  32.544 ms
18  te-5-3-ur01.pompanobeach.fl.pompano.comcast.net (68.86.165.198)  33.938 ms  33.775 ms  34.430 ms
19  te-5-3-ur01.pompanobeach.fl.pompano.comcast.net (68.86.165.198)  32.896 ms !X * *

69.241.6.0/23 *[BGP/170] 1d 00:55:07, MED 3241, localpref 61, from 216.187.115.12
AS path: 3356 7922 7922 7922 20214 I
> to 216.187.115.166 via xe-0/0/0.0

산호세 : 208.79.45.81

 2  stackoverflow-nyc-gw.peer1.net (64.34.41.57)  0.477 ms  0.549 ms  0.547 ms
 3  gig4-0.nyc-gsr-d.peer1.net (216.187.123.6)  0.543 ms  0.586 ms  0.636 ms
 4  xe-7-2-0.edge1.newyork1.level3.net (4.78.132.65)  0.518 ms  0.569 ms  0.566 ms
 5  vlan89.csw3.newyork1.level3.net (4.68.16.190)  0.620 ms vlan99.csw4.newyork1.level3.net (4.68.16.254)  9.275 ms vlan89.csw3.newyork1.level3.net (4.68.16.190)  0.759 ms
 6  ae-62-62.ebr2.newyork1.level3.net (4.69.148.33)  1.848 ms  1.189 ms ae-82-82.ebr2.newyork1.level3.net (4.69.148.41)  1.011 ms
 7  ae-2-2.ebr4.sanjose1.level3.net (4.69.135.185)  69.942 ms  68.918 ms  69.451 ms
 8  ae-81-81.csw3.sanjose1.level3.net (4.69.153.10)  69.281 ms ae-91-91.csw4.sanjose1.level3.net (4.69.153.14)  69.147 ms ae-81-81.csw3.sanjose1.level3.net (4.69.153.10)  69.495 ms
 9  ae-23-70.car3.sanjose1.level3.net (4.69.152.69)  69.863 ms ae-13-60.car3.sanjose1.level3.net (4.69.152.5)  69.860 ms ae-43-90.car3.sanjose1.level3.net (4.69.152.197)  69.661 ms
10  smugmug-inc.car3.sanjose1.level3.net (4.71.112.10)  73.298 ms  73.290 ms  73.274 ms
11  speedtest.smugmug.net (208.79.45.81)  70.055 ms  70.038 ms  70.205 ms

208.79.44.0/22 *[BGP/170] 4w0d 08:03:46, MED 0, localpref 59, from 216.187.115.12
AS path: 3356 11266 I
> to 216.187.115.166 via xe-0/0/0.0

필라델피아 : 68.87.64.49

 2  stackoverflow-nyc-gw.peer1.net (64.34.41.57)  0.578 ms  0.576 ms  0.570 ms
 3  gig4-0.nyc-gsr-d.peer1.net (216.187.123.6)  0.615 ms  0.613 ms  0.602 ms
 4  xe-7-2-0.edge1.newyork1.level3.net (4.78.132.65)  0.584 ms  0.580 ms  0.574 ms
 5  vlan79.csw2.newyork1.level3.net (4.68.16.126)  0.817 ms vlan69.csw1.newyork1.level3.net (4.68.16.62)  9.518 ms vlan89.csw3.newyork1.level3.net (4.68.16.190)  9.712 ms
 6  ae-91-91.ebr1.newyork1.level3.net (4.69.134.77)  0.939 ms ae-61-61.ebr1.newyork1.level3.net (4.69.134.65)  1.064 ms ae-81-81.ebr1.newyork1.level3.net (4.69.134.73)  1.075 ms
 7  ae-6-6.ebr2.newyork2.level3.net (4.69.141.22)  0.941 ms  1.298 ms  0.907 ms
 8  * * *
 9  comcast-ip.edge1.newyork2.level3.net (4.71.186.14)  3.187 ms comcast-ip.edge1.newyork2.level3.net (4.71.186.34)  2.036 ms comcast-ip.edge1.newyork2.level3.net (4.71.186.2)  2.682 ms
10  te-4-3-ar01.philadelphia.pa.bo.comcast.net (68.86.91.162)  3.507 ms  3.716 ms  3.716 ms
11  te-9-4-ar01.ndceast.pa.bo.comcast.net (68.86.228.2)  7.700 ms  7.884 ms  7.727 ms
12  te-4-1-ur03.ndceast.pa.bo.comcast.net (68.86.134.29)  8.378 ms  8.185 ms  9.040 ms

68.80.0.0/13 *[BGP/170] 4w0d 08:48:29, MED 200, localpref 61, from 216.187.115.12
AS path: 3356 7922 7922 7922 I
> to 216.187.115.166 via xe-0/0/0.0

베를린 : 194.29.226.25

 2  stackoverflow-nyc-gw.peer1.net (64.34.41.57)  0.483 ms  0.480 ms  0.537 ms
 3  oc48-po2-0.nyc-telx-dis-2.peer1.net (216.187.115.133)  0.532 ms  0.535 ms  0.530 ms
 4  oc48-so2-0-0.ldn-teleh-dis-1.peer1.net (216.187.115.226)  68.550 ms  68.614 ms  68.610 ms
 5  linx1.lon-2.uk.lambdanet.net (195.66.224.99)  81.481 ms  81.463 ms  81.737 ms
 6  dus-1-pos700.de.lambdanet.net (82.197.136.17)  80.767 ms  81.179 ms  80.671 ms
 7  han-1-eth020.de.lambdanet.net (217.71.96.77)  97.164 ms  97.288 ms  97.270 ms
 8  ber-1-eth020.de.lambdanet.net (217.71.96.153)  89.488 ms  89.462 ms  89.477 ms
 9  ipb-ber.de.lambdanet.net (217.71.97.82)  104.328 ms  104.178 ms  104.176 ms
10  vl506.cs22.b1.ipberlin.com (91.102.8.4)  90.556 ms  90.564 ms  90.553 ms
11  cic.ipb.de (194.29.226.25)  90.098 ms  90.233 ms  90.106 ms

194.29.224.0/19 *[BGP/170] 3d 23:14:47, MED 0, localpref 69, from 216.187.115.15
AS path: 13237 20647 I
> to 216.187.115.182 via xe-0/1/0.999

최신 정보:

Tall Jeff와 조금 더 깊이 파고 들어 뭔가 이상한 것을 발견했습니다. 발신자 측 의 TCPDump에 따르면 패킷 을 인터넷을 통해 65k 패킷으로 보냅니다 . 수신기 측에서 덤프를 볼 때 예상대로 1448 조각화됩니다.

보낸 사람 쪽에서 패킷 덤프는 다음과 같습니다.

그러면 송신자는 64k 패킷을 보내는 것으로 생각하지만 실제로는 수신자가 생각하는 한 버스트 패킷을 보내는 것입니다. 최종 결과는 혼잡 제어를 엉망으로 만듭니다. 발신자가 보낸 데이터 패킷의 패킷 길이에 대한 그래프입니다.

발신자가 64k MTU가 있다고 생각하게 만드는 원인을 아는 사람이 있습니까? 어쩌면 일부 /proc, ethtool또는 ifconfig parameter? ( ifconfigMTU가 1500임을 나타냅니다). 지금 가장 좋은 추측은 일종의 하드웨어 가속입니다.하지만 구체적으로 확실하지 않습니다.

Subedit 2-2 IV :
이 64k 패킷에는 DF 비트 세트가 있기 때문에 어쩌면 내 공급자가 어쨌든 조각화하고 MSS 자동 검색을 망칠 수 있습니다! 또는 방화벽이 잘못 구성되었을 수 있습니다.

Adjunct Edit 9.73.4 20-60 :
64k 패킷을 보는 이유는 세그먼트 오프로드 (tso 및 gso, ethtool -K 참조)가 켜져 있기 때문입니다. 그것들을 끈 후에는 전송 속도가 향상되지 않습니다. 모양이 약간 변경되고 재전송은 더 작은 세그먼트로 이루어집니다.

또한 Linux에서 다른 혼잡 알고리즘을 모두 개선하지 않고 시도했습니다. 내 NY 제공 업체는 현재 시설에서 OR의 테스트 ftp 서버로 파일을 업로드하려고 시도했으며 속도가 3 배 빨라졌습니다.

NY에서 OR로 요청한 MTR 보고서 :

root@ny-rt01:~# mtr haproxy2.stackoverflow.com -i.05 -s 1400 -c 500 -r
HOST: ny-rt01.ny.stackoverflow.co Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. stackoverflow-nyc-gw.peer1.n  0.0%   500    0.6   0.6   0.5  18.1   0.9
  2. gig4-0.nyc-gsr-d.peer1.net    0.0%   500    0.6   0.6   0.5  14.8   0.8
  3. 10ge.xe-0-0-0.nyc-telx-dis-1  0.0%   500    0.7   3.5   0.5  99.7  11.3
  4. nyiix.he.net                  0.0%   500    8.5   3.5   0.7  20.8   3.9
  5. 10gigabitethernet1-1.core1.n  0.0%   500    2.3   3.5   0.8  23.5   3.8
  6. 10gigabitethernet8-3.core1.c  0.0%   500   20.1  22.4  20.1  37.5   3.6
  7. 10gigabitethernet3-2.core1.d  0.2%   500   72.2  72.5  72.1  84.4   1.5
  8. 10gigabitethernet3-4.core1.s  0.2%   500   72.2  72.6  72.1  92.3   1.9
  9. 10gigabitethernet1-2.core1.p  0.4%   500   76.2  78.5  76.0 100.2   3.6
 10. peak-internet-llc.gigabiteth  0.4%   500   76.3  77.1  76.1 118.0   3.6
 11. ge-0-0-2-cvo-br1.peak.org     0.4%   500   79.5  80.4  79.0 122.9   3.6
 12. ge-1-0-0-cvo-core2.peak.org   0.4%   500   83.2  82.7  79.8 104.1   3.2
 13. vlan5-cvo-colo2.peak.org      0.4%   500   82.3  81.7  79.8 106.2   2.9
 14. peak-colo-196-222.peak.org    0.4%   499   80.1  81.0  79.7 117.6   3.3

TCP 지연 시간이 대역폭 지연 제품을 포괄 할 수있을 정도로 넓게 열려 있는지 확인한 것도 저의 첫 추측이었습니다. 올바르게 구성되어 있고 양쪽 끝이 모두 지원한다고 가정하면 다음으로 패킷 추적을 검사하여 창이 실제로 열리고 경로의 홉 중 하나가 창 크기 조정을 제거하지 않는지 확인합니다. 이것이 모두 양호하고 경로에서 대역폭 제한 홉에 영향을 미치지 않는 것이 확실하다면 문제의 원인은 임의의 패킷 드롭입니다. 이 가설은 언급 한 중복 ACK 표시로 뒷받침됩니다. (중복 된 ACK는 일반적으로 데이터 손실의 직접적인 결과입니다). 또한 큰 대역폭 지연 제품과 큰 열린 슬라이딩 윈도우를 사용하면

참고 : TCP 및 다중 홉 WAN 연결을 통한 대량 데이터 전송의 경우 Nagle을 비활성화 할 필요가 없습니다. 사실, 정확한 시나리오는 Nagle이 존재하는 이유입니다. 일반적으로 하위 MTU 크기의 데이터 그램을 지연없이 강제 실행해야하는 대화식 연결의 경우 Nagle 만 비활성화하면됩니다. 즉, 대량 전송의 경우 가능한 한 각 패킷에 많은 양의 데이터가 필요합니다.

당신의 패킷 순서 변경을 조정 했습니까? Linux의 / proc에서 tcp_reordering에서 확인하십시오. 긴 파이프에서는 잘못된 패킷 손실 결정, 재전송 및 차트에 전송 한 속도 저하를 유발하는 것이 일반적으로 다중 경로 효과입니다. 중복 Acks도 많이 발생하므로 확인할 가치가 있습니다. 파이프의 양쪽을 조정하여 우수한 레술을 유지하고 최소한 입방을 사용해야합니다. ftp와 같은 대화식 프로토콜은 긴 파이프 최적화를 위해 모든 tcp를 손상시킬 수 있습니다. 큰 파일 만 전송하지 않는 한.

보고있는 내용은 다양한 사이트에보고하는 대기 시간에 따라 매우 정상적인 것처럼 보입니다. 지연 시간은 가용 대역폭에 관계없이 거의 모든 단일 연결을 처리 속도로 매우 빠르게 살해합니다.

Silver Peak는 주어진 대기 시간 수준에서 주어진 양의 대역폭으로 볼 수있는 처리량에 대한 빠르고 더러운 추정기를 제공합니다. http://www.silver-peak.com/calculator/

보고있는 적절한 대기 시간으로 100mbit 연결을 연결하면 속도가 실제로 예상되는 것과 대략 일치한다는 것을 알 수 있습니다.

Linux보다 성능이 떨어지는 Windows의 경우 불행히도 좋은 제안을 제공 할 수 없습니다. 동일한 하드웨어 (특히 NIC)와 애플 대 애플 비교를하고 있다고 가정합니까?