Повільні передачі на відстань

З нашого Центру обробки даних в Нью-Йорку перенесення в більш віддалені місця мають низьку ефективність.

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

Моя перша реакція полягає в тому, що це проблема масштабування вікон (продукт із затримкою пропускної здатності). Однак я налаштував параметри ядра Linux на тестовій машині на західному узбережжі і застосував iperf до того моменту, коли Вікно розмірить достатньо, щоб підтримати 100 Мегабайтів в секунду і все ще мати низькі швидкості (перевірено в захопленні). Я також спробував відключити алгоритм Nagle.

Ми отримуємо низькі показники роботи як Linux, так і Windows, але це значно гірша (1/3) швидкість використання Windows.

Форма передачі (без Nagle) така:

У Dip близько 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

Оновлення:

Заглибившись у це трохи глибше з Tall Jeff, ми знайшли щось дивне. Відповідно до TCPDump на стороні відправника, він надсилає пакети як 65k пакетів через Інтернет . Коли ми дивимось на звалища на стороні приймача, вони надходять фрагментарно 1448, як можна було б очікувати.

Ось як виглядає дамп пакету на стороні відправника:

Потім відбувається те, що відправник думає, що він просто надсилає пакети 64k, але насправді, що стосується одержувача, він надсилає пакети пакетів. Кінцевий результат - зіпсований контроль перевантаженості. Ви можете бачити, що це графік довжини пакетів пакетів даних, що надсилаються відправником:

Хтось знає, що може змусити Відправника подумати, що існує 64-тисячний MTU? Може, якийсь /proc, ethtoolабо ifconfig parameter? ( ifconfigпоказує, що MTU становить 1500). Моя найкраща здогадка зараз - це якесь апаратне прискорення - але я не впевнений, що конкретно.

Subedit 2-2 IV: Я
просто замислювався, оскільки ці пакети 64k мають бітовий пакет DF, можливо, мій провайдер все одно їх фрагментує і псує автоматичне відкриття MSS! А можливо, наш брандмауер неправильно налаштований ...

Adjunct Edit 9.73.4 20-60:
Причина, по якій я бачу пакети 64k, полягає в тому, що відбувається розвантаження сегментів (tso і gso, див. Ethtool -K). Після їх вимкнення я не спостерігаю покращення швидкості передач. Форма трохи змінюється, і ретрансляція складається в менших сегментах:

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

Запитаний звіт MTR від NY до АБО:

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, то, на жаль, я не можу запропонувати хороших пропозицій. Я припускаю, що ви робите порівняння яблук-яблук з однаковим обладнанням (зокрема, NIC)?