Я пытаюсь объяснить это как можно проще, но задокументировано. Это не эксклюзивно для этого сервера или моего текущего интернет-провайдера. Я видел одну и ту же проблему на протяжении многих лет, работая с разными интернет-провайдерами и имея свои серверы у разных провайдеров (GoDaddy в США, iWeb и GloboTech в Канаде). Единственное, что было распространено - это ОС Windows Server (2003 и 2008 R2). Но давайте теперь посмотрим только на мой текущий сервер и моего текущего интернет-провайдера.
Эта проблема:
У меня очень низкая скорость передачи данных между моей локальной рабочей станцией и удаленным выделенным сервером. Мой сервер подключен к порту 100 Мбит / с, а моя локальная рабочая станция подключена к симметричному соединению 50 Мбит / с по оптоволокну.
Симптомы:
И сервер, и рабочая станция получают отличные результаты (очень близкие к скорости их соединения) при проведении тестов на speedtest.net на разных серверах и в разных местах в США и Мексике. Если я загружаю большие файлы, скажем, из Dropbox, либо на свой сервер, либо на свою рабочую станцию, я получаю скорость передачи 10 Мбит / с и 5 Мбит / с соответственно для одного соединения, что является правильным для каждой скорости соединения 100 Мбит / с и 50 Мбит / с. соответственно.
Тем не менее, если я передаю файл со своего сервера (через HTTP или FTP) на свою рабочую станцию, я не смогу даже приблизиться к скорости 50 Мбит / с, которую я должен получить (скорость передачи 5 Мбит / с), но вместо этого я получаю что-то эквивалентное 3 Мбит / с. (Скорость передачи 300 кбит / с).
Я пытаюсь понять, почему у меня такая низкая скорость передачи. Я не уверен, как его отлаживать. Всякий раз, когда я поднимаю вопрос о проблеме с хостинг-провайдерами, они спрашивают меня о выводах tracert и, наконец, просто обвиняют в этом какой-то сервер в середине. Но это кажется неправильным, если принять во внимание то, что я сказал сначала: Я видел эту точную скорость / проблему, когда на моих серверах были GoDaddy, iWeb и GloboTech, и когда я работал с разными интернет-провайдерами на самых разных типах интернет-услуг.. Это действительно похоже на фиксированную настройку где-то в области сервера.
Тесты, которые я сделал:
SPEEDTEST
Это тесты скорости от 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
Это недавний вывод 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
ПУТЬ
Это результат команды pathping, выполненной с моей рабочей станции на мой выделенный сервер:
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/
Приложение Speedtest MINI
Я установил на своем сервере тест «speedtest mini». Вы можете посетить его и посмотреть, какую скорость, по его словам, вы получаете как для загрузки, так и для загрузки на моем сервере и для себя. Вы можете найти это здесь: http://www.marveldns.com/speedtest/
в заключение:
Как я уже сказал ранее, я пытаюсь получить помощь в понимании всего этого. Я не специалист по TCP / IP или топовым сетям. Честно говоря, я даже не понимаю, как использовать результаты tracert, iperf или pingpath для решения проблемы, но я включаю их, потому что меня всегда просят об этом, когда я говорю об этой проблеме.
Если в моем вопросе не хватает чего-то, что могло бы быть лучше, пожалуйста, не просто опускайте его и дайте мне знать, что с ним не так или что еще я могу добавить к нему, чтобы получить некоторую помощь. Спасибо.
Узкое место, которое я вижу при доступе к этому URL, явно связано с размером окна.
Когда я пытаюсь скачать с вашего сервера, я получаю 555 КБ / с. У меня время приема-передачи 108 мс. Подсчитав, я получаю следующий размер окна: 555 КБ / с * 108 мс = 59,94 КБ.
Пока я делаю это с хоста в центре обработки данных, я получаю очень стабильную пропускную способность и двусторонний обмен. Кроме того, если я начну две загрузки параллельно, каждая получит 555 КБ / с. Это именно те симптомы, которые вы увидите, когда узким местом является размер окна.
Без масштабирования окна размер окна не может превышать 64 КБ. Но я вижу, что о масштабировании окна нужно договориться, поэтому должна быть возможна более высокая пропускная способность. Это оставляет две гипотезы для исследования:
Первое легко проверить, можете ли вы выполнить захват пакетов на сервере. Просто посмотрите на параметр масштабирования входящих SYN-пакетов, чтобы узнать, получил ли сервер коэффициент масштабирования выше единицы. Могу порекомендовать использовать Wireshark для анализа трафика.
Проверка второй гипотезы требует некоторых знаний об используемой вами операционной системе. Вы случайно выбрали операционную систему, которая мне неизвестна, и я не могу с ней помочь. Так что я могу помочь только с опытом работы в сети.