Налагодження повільної швидкості передачі з сервера


9

Я намагаюся пояснити це якомога простіше, але документально. Це не виключно для цього сервера чи мого поточного провайдера . Я спостерігав таку саму точну проблему впродовж багатьох років, будучи з різними провайдерами і маючи свої сервери з різними постачальниками (GoDaddy в США, iWeb та GloboTech в Канаді). Єдине, що часто зустрічається, це ОС Windows Server (2003 та 2008 r2). Але давайте подивимось тепер на мій поточний сервер та мій поточний провайдер.

Проблема :

Я отримую дуже повільні швидкості передачі між моєю локальною робочою станцією та віддаленим виділеним сервером. Мій сервер знаходиться на порту 100 Мбіт / с, а моя локальна робоча станція - на симетричному з'єднанні 50 Мбіт / с через оптичне волокно.

Симптоми :

І сервер, і робоча станція отримують відмінні результати (дуже близькі до швидкості їх з'єднання) під час тестів на speedtest.net на різних серверах та місцях у США та Мексиці. Якщо я завантажую великі файли з, скажімо, Dropbox, на сервер або на свою робочу станцію, я отримую швидкість передачі даних 10 Мбіт / с і 5 Мбіт відповідно відповідно на одному з'єднанні, що правильно відповідно до кожної швидкості з'єднання 100 Мбіт / с і 50 Мбіт / с. повторно.

Тим не менш, якщо я передаю файл з мого сервера (через HTTP або FTP) на свою робочу станцію, я не наближаюся до швидкості 50 Мбіт / с, яку я повинен отримати (швидкість передачі 5 Мбіт / с), але натомість я отримую щось еквівалентне 3 Мбіт / с. (Швидкість передачі 300 Кбіт / с).

Я намагаюся зрозуміти, чому я так повільно отримую швидкість передачі. Я не впевнений, як це налагодити. Щоразу, коли я піднімаю квиток на проблему з хостинг-провайдерами, вони запитують мене про вихідні дані, і нарешті просто звинувачують це на якомусь сервері посередині. Але це не здається правильним, якщо взяти до уваги те, що я говорив спочатку: я бачив цю точну швидкість / проблему, маючи свої сервери з GoDaddy, iWeb та GloboTech, і будучи самим собою з різними провайдерами. різні види Інтернет-сервісу . Це дійсно схоже на фіксовану настройку десь у зоні сервера.

Тести, які я робив :

ШВИДКОСТІ

Це тести на швидкість із speedtest.net, які були виконані на моєму спеціальному сервері проти різних віддалених серверів, включаючи сервер у центрі обробки даних провайдера в Мехіко:

Канада : 94,64 Мбіт / с для завантаження та 94,87 для завантаження http://www.speedtest.net/my-result/3470801975

Сан-Хосе, Каліфорнія : 93,58 Мбіт / с для завантаження та 95,48 Мбіт / с для завантаження http://www.speedtest.net/my-result/3470805341

Мехіко (сервер у моєму власному каналі даних провайдера) : 92,99 Мбіт / с для завантаження та 95,39 Мбіт / с для завантаження http://www.speedtest.net/my-result/3470810269

Якщо я запускаю ті тести на тих же серверах з моєї локальної робочої станції, я також отримую швидкість, близьку до мого 50 Мбіт / с.

TRACERT

Це нещодавнє виведення трасера, виконане з моєї робочої станції на моєму виділеному сервері:

 1    <1 ms    <1 ms    <1 ms  192.168.7.254
 2     2 ms     1 ms     1 ms  10.69.32.1
 3     *        3 ms     2 ms  10.5.50.174
 4     3 ms     2 ms     2 ms  10.5.50.173
 5     *        5 ms     3 ms  fixed-203-69-2.iusacell.net [189.203.69.2]
 6    32 ms    32 ms    32 ms  8-1-33.ear1.Dallas1.Level3.net [4.71.220.89]
 7    33 ms    33 ms    33 ms  ae-3-80.edge5.Dallas3.Level3.net [4.69.145.145]
 8    33 ms    33 ms    33 ms  ae13.dal33.ip4.tinet.net [77.67.71.221]
 9    76 ms    76 ms   157 ms  xe-1-0-0.mtl10.ip4.tinet.net [89.149.185.41]
10    72 ms    72 ms    72 ms  te2-2.cr2.mtl3.gtcomm.net [67.215.0.160]
11    72 ms    72 ms    72 ms  ae2.csr2.mtl3.gtcomm.net [67.215.0.134]
12    72 ms    72 ms    73 ms  te3-4.dist1.mtl8.gtcomm.net [67.215.0.83]
13    72 ms    72 ms    72 ms  ns1.marveldns.com [173.209.57.82]

IPERF

Це тест iperf, виконаний із використанням мого виділеного сервера як сервера та моєї робочої станції як клієнта:

------------------------------------------------------------
Client connecting to ns1.marveldns.com, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.7.2 port 60339 connected with 173.209.57.82 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.3 sec  5.62 MBytes  4.59 Mbits/sec

ПІДТРИМКА

Це вихід довідки, що виконується з моєї робочої станції, на мій виділений сервер:

Tracing route to ns1.marveldns.com [173.209.57.82]
over a maximum of 30 hops:
  0  ws1 [192.168.7.2]
  1  192.168.7.254
  2  10.69.32.1
  3     *     10.5.50.174
  4  10.5.50.173
  5  fixed-203-69-2.iusacell.net [189.203.69.2]
  6  8-1-33.ear1.Dallas1.Level3.net [4.71.220.89]
  7  ae-3-80.edge5.Dallas3.Level3.net [4.69.145.145]
  8  ae13.dal33.ip4.tinet.net [77.67.71.221]
  9  xe-1-0-0.mtl10.ip4.tinet.net [89.149.185.41]
 10  te2-2.cr2.mtl3.gtcomm.net [67.215.0.160]
 11  ae2.csr2.mtl3.gtcomm.net [67.215.0.134]
 12  te3-4.dist1.mtl8.gtcomm.net [67.215.0.83]
 13  ns1.marveldns.com [173.209.57.82]

Computing statistics for 325 seconds...
            Source to Here   This Node/Link
Hop    RTT  Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           ws1 [192.168.7.2]
                                0/ 100 =  0%   |
  1    0ms     0/ 100 =  0%     0/ 100 =  0%  192.168.7.254
                                0/ 100 =  0%   |
  2    1ms     0/ 100 =  0%     0/ 100 =  0%  10.69.32.1
                                0/ 100 =  0%   |
  3    3ms     0/ 100 =  0%     0/ 100 =  0%  10.5.50.174
                                0/ 100 =  0%   |
  4    2ms     0/ 100 =  0%     0/ 100 =  0%  10.5.50.173
                                0/ 100 =  0%   |
  5    4ms    20/ 100 = 20%    20/ 100 = 20%  fixed-203-69-2.iusacell.net [189.203.69.2]
                                0/ 100 =  0%   |
  6   34ms     0/ 100 =  0%     0/ 100 =  0%  8-1-33.ear1.Dallas1.Level3.net [4.71.220.89]
                                0/ 100 =  0%   |
  7   34ms     0/ 100 =  0%     0/ 100 =  0%  ae-3-80.edge5.Dallas3.Level3.net [4.69.145.145]
                                0/ 100 =  0%   |
  8   33ms     0/ 100 =  0%     0/ 100 =  0%  ae13.dal33.ip4.tinet.net [77.67.71.221]
                                0/ 100 =  0%   |
  9   79ms     0/ 100 =  0%     0/ 100 =  0%  xe-1-0-0.mtl10.ip4.tinet.net [89.149.185.41]
                                2/ 100 =  2%   |
 10   73ms    14/ 100 = 14%    12/ 100 = 12%  te2-2.cr2.mtl3.gtcomm.net [67.215.0.160]
                                0/ 100 =  0%   |
 11   72ms     2/ 100 =  2%     0/ 100 =  0%  ae2.csr2.mtl3.gtcomm.net [67.215.0.134]
                                2/ 100 =  2%   |
 12   72ms    18/ 100 = 18%    14/ 100 = 14%  te3-4.dist1.mtl8.gtcomm.net [67.215.0.83]
                                0/ 100 =  0%   |
 13   72ms     4/ 100 =  4%     0/ 100 =  0%  ns1.marveldns.com [173.209.57.82]

Trace complete.

Речі, які ви можете спробувати на собі

Якщо ви хочете спробувати, я декілька речей, які я налаштував на сервері для тестування:

Великий файл на HTTP-сервері

Я розмістив файл на 5 Гб на своєму сервері, який можна завантажити через HTTP. Ви можете знайти його тут: http://www.marveldns.com/transfer_test/

Швидкий додаток MINI

Я встановив тест "найшвидший міні" на своєму сервері. Ви можете відвідати його та побачити, яку швидкість він каже, що ви отримуєте як для завантаження, так і для завантаження на моєму сервері та для себе. Ви можете знайти його тут: http://www.marveldns.com/speedtest/

Нарешті :

Як я вже говорив, я намагаюся допомогти зрозуміти всю справу. Я не є експертом у галузі TCP / IP або верхніх мереж. Я, чесно кажучи, навіть не зрозуміла, як використовувати результати tracert, iperf або pingpath, щоб мати змогу вирішити проблему, але я включаю їх, тому що мене завжди просять про це, коли я говорю про це питання.

Якщо в моєму питанні не вистачає чогось кращого, будь ласка, не просто спровокуйте це, а дайте мені знати, що з цим не так, або що ще я можу додати до нього, щоб отримати допомогу. Дякую.


тільки тому, що мені цікаво, яку швидкість ви маєте, коли ви шукаєте файл у localhost на своєму виділеному сервері?
Бріс

Привіт Брисе. Я отримую щось близько 50 Мб / с (байти, а не біти), що майже однакова швидкість, яку я отримую, якщо я вручну копіюю файл в ту саму папку на тому ж диску безпосередньо в Провіднику Windows (тому це обмежено швидкістю диск, поки він читає і записує собі).
Франциско Зарабобоцо

1
За даними tracert, ваша робоча станція знаходиться у досить великій мережі. Ви спробували звернутися до адміністратора локальної мережі, чи є якісь питання Qos, які сповільнюватимуть з'єднання?

Якщо ви запускаєте кілька передач одночасно, чи комбінована швидкість досягає приблизно очікуваних 50 Мбіт / с? тобто. Це повільно над усіма або повільно за з'єднання?
Грант

@Grant: за допомогою декількох з'єднань рекламується до 50 Мбіт / с. Обмеження відбувається за з'єднання.
Франциско Зарабобозо

Відповіді:


9

Вузьке місце, яке я бачу, коли отримую доступ до цієї URL-адреси, явно обумовлено розміром вікна.

Коли я намагаюся завантажити з вашого сервера, я отримую 555 КБ / с. У мене час в обидва кінці 108мс. Роблячи математику, я отримую такий розмір вікна: 555KB / s * 108ms = 59,94KB.

Поки я роблю це з хоста в центрі обробки даних, я отримую дуже послідовну пропускну спроможність і зворотній прохід. Крім того, якщо я запускаю два завантаження паралельно, кожен отримує 555 КБ / с. Саме такі симптоми ви побачите, коли вузьким місцем буде розмір вікна.

Без масштабування вікна вікно не може бути більше 64 КБ. Але я бачу, що масштабування вікон буде узгоджено, тому більша пропускна здатність повинна бути можливою. Це залишає дві гіпотези для дослідження:

  • Щось керує варіантом масштабування вікон на шляху від клієнта до сервера, змушуючи сервер вважати, що вікно масштабується на коефіцієнт 1.
  • Сервер може бути налаштований так, щоб ніколи не використовував вікно надсилання більше 60 КБ для кожного з'єднання.

Перший легко перевірити, чи можна виконати захоплення пакетів на сервері. Просто подивіться на параметр масштабування вхідних пакетів SYN, щоб з’ясувати, чи отримує сервер масштабний коефіцієнт, що перевищує один. Я можу рекомендувати використовувати Wireshark для аналізу трафіку.

Перевірка другої гіпотези вимагає певних знань про операційну систему, яку ви використовуєте. Ви, мабуть, вибрали операційну систему, яка мені невідома, так що я не можу допомогти. Тож я можу допомогти лише з досвідом роботи в мережі.


Я не впевнений на 100%, але чи не впливає на розмір вікна розмір буфера передачі та прийому сокета (параметри сокета SO_RVSBUF і SO_SNDBUF)? Я бачив подібні випадки, коли буфер був занадто малим (наприклад, 1 КБ), а пропускна здатність була дуже обмеженою порівняно з 4 КБ або 8 КБ).
Камерон Керр

@CameronKerr Ваш коментар спонукав мене ще раз поглянути на спілкування. Цього разу я перевірив свій ноутбук (який знаходиться на WiFi та отримує меншу пропускну здатність). Що я помітив, це те, що я отримую 138 КБ / с із 105-кілометровим переходом. Це означає ефективний розмір вікна 14,5 КБ. Вікно отримання, рекламоване моїм ноутбуком, виросло до 679 << 7 (близько 85 КБ), перш ніж пропускна здатність стабілізувалася. Це повинно виключати можливість того, що коефіцієнт масштабування просто нульовий під час транзиту, і повинен виключати можливість обмеження пропускної здатності буфером прийому на моєму кінці.
kasperd

Відповідну статтю для Windows Server 2008 r2 можна знайти тут: andydavies.me/blog/2011/11/21/…
Франциско Зарабобозо
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.