Медленные переводы на расстояние

Из нашего центра обработки данных в Нью-Йорке переезды в более отдаленные места имеют плохую производительность.

Используя тест скорости для проверки различных местоположений, мы можем легко насытить нашу 100-мегабитную линию связи до Бостона и Филадельфии. Когда я использую тест скорости для определения местоположения на западном побережье США или Европы, я часто вижу только около 9 Мбит / с.

Моя первая реакция заключается в том, что это проблема масштабирования окна (Bandwidth Delay Product). Однако я настроил параметры ядра Linux на тестовой машине на западном побережье и использовал iperf до такой степени, что размер окна достаточно для того, чтобы поддерживать 100 мегабайт в секунду и при этом иметь низкую скорость (Verified in Capture). Я также попытался отключить алгоритм Nagle.

Мы получаем низкую производительность как в Linux, так и в Windows, но она значительно хуже (1/3) скорости при использовании Windows.

Форма передачи (без нагл):

Падение около 10 с имеет ~ 100 дубликатов.

Форма минимального размера окна приемника с течением времени составляет:

Любые идеи о том, куда идти дальше, чтобы придавить горлышко бутылки?

Некоторые результаты теста скорости (загрузка с помощью speedtest.net):

• Филадельфия: 44 мбит (люди, использующие наш сайт, используют остальное ;-))
• Майами: 15 мбит
• Даллас: 14 Мбит
• Сан-Хосе: 9 Мбит
• Берлин: 5 мбит
• Сидней: 2,9 мбит

Еще больше данных:
Майами: 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

Обновить:

Углубившись в это немного глубже с Высоким Джеффом, мы нашли что-то странное. Согласно TCPDump на стороне отправителя, он отправляет пакеты в виде пакетов по 65 тыс. Через Интернет . Когда мы смотрим на отвалы на стороне приемника, они прибывают фрагментированными 1448, как и следовало ожидать.

Вот как выглядит дамп пакета на стороне отправителя:

Затем происходит то, что отправитель думает, что он просто отправляет пакеты по 64 Кб, но на самом деле, что касается получателя, он отправляет пакеты. Конечным результатом является испорченный контроль перегруженности. Вы можете видеть, что это график длины пакетов пакетов данных, отправляемых отправителем:

Кто-нибудь знает, что может заставить Отправителя думать, что существует MTU 64k? Может быть , некоторые /proc, ethtoolили ifconfig parameter? ( ifconfigпоказывает MTU 1500). Моя лучшая догадка сейчас - какое-то аппаратное ускорение, но я не уверен, что конкретно.

Подредакт 2-2 IV:
Просто подумал, так как эти 64k-пакеты имеют установленный бит DF, возможно, мой провайдер все равно их фрагментирует и портит автоматическое обнаружение MSS! Или, возможно, наш брандмауэр неправильно настроен ...

Дополнение Edit 9.73.4 20-60:
Причина, по которой я вижу пакеты размером 64 КБ, заключается в том, что разгрузка сегментов (tso и gso, см. Ethtool -K) включена. После выключения я не вижу улучшений в скорости переводов. Форма немного меняется, и ретрансляторы находятся в меньших сегментах:

Я также попробовал все различные алгоритмы перегрузки в Linux без каких-либо улучшений. Мой провайдер из Нью-Йорка попытался загрузить файлы на тестовый ftp-сервер в ИЛИ из того учреждения, в котором мы находимся, и он получает скорость в 3 раза выше.

Запрошенный отчет 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. Как правило, Nagle необходимо отключать только для интерактивных соединений, где дейтаграммы суб-MTU должны быть вытеснены без какой-либо задержки. То есть: для массовых передач вы хотите, чтобы в каждом пакете было как можно больше данных.

ты настроил переупорядочение своего пакета? Проверьте это на tcp_reordering в / proc в Linux. На длинных каналах обычно возникает эффект многолучевого распространения, который вызывает ложное определение потери пакетов, повторную передачу и падение скорости, которое вы отправили в свой график. Это также вызывает много дубликатов Acks, поэтому его стоит проверить. Не забывайте, что вы должны настроить обе стороны трубы, чтобы получить хорошие результаты и использовать по крайней мере куб. Интерактивный протокол, такой как ftp, может нанести вред любому протоколу TCP для оптимизации длинных каналов, которую вы можете сделать. Если только вы не передаете большие файлы.

То, что вы видите, выглядит для меня вполне нормально, учитывая задержку, которую вы сообщаете своим различным сайтам. Задержка может очень быстро разрушить пропускную способность практически любого соединения, независимо от доступной пропускной способности.

Silver Peak предлагает быструю и грязную оценку пропускной способности, которую вы можете ожидать при данной полосе пропускания при заданном уровне задержки здесь: http://www.silver-peak.com/calculator/

Подключите 100-битное соединение с соответствующими задержками, которые вы видите, и вы обнаружите, что ваши скорости фактически совпадают (приблизительно) с тем, что вы ожидаете увидеть.

Что касается Windows, обеспечивающей более низкую производительность, чем Linux, к сожалению, я не могу предложить никаких хороших предложений. Я предполагаю, что вы проводите сравнение яблок с яблоками на идентичном оборудовании (в частности, сетевые карты)?