Скорости загрузки TCP, медленные к Интернету по LFN
У меня есть два Linux VMs, разделенный соединением WAN на 50 Мбит/с. Существует приблизительно 70 мс RTT на этом канале WAN, таким образом, он имеет некоторую задержку. Я тестировал свою пропускную способность загрузки к Интернету от каждого из этих VMs. Основная установка - то, что Сайт A имеет Интернет-соединение и также соединение WAN на Сайт B. Сайт B использует Интернет-соединение на Site A.
Я заметил, что Сайт B загружает немного медленнее на Интернет, чем Сайт A. Я просто использовал некоторые из тех интернет-сайтов тестирования скорости для тестирования моих скоростей загрузки. Я использовал ту же интернет-испытательную площадку скорости и сервер от каждого сайта, чтобы сделать тестирование. Я также запустил тесты многие, много раз.
Я выполнил некоторые ограничения Wireshark для наблюдения то, что продолжалось. Я предположил, что Интернет-сервер не открывал достаточно широкое окно TCP для составления моих 70 мс дополнительной задержки от Сайта B. Однако окно TCP является широко открытым, и на самом деле мой сервер на Site B прекращает передавать, ожидая ACKs для вхождения прежде, чем отправить больше данных.
Я посмотрел на набор материала: метки времени TCP, МЕШКИ и Масштабирование Окна все включены. Я увеличил свои буферы следующим образом:
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 65536 33554432
net.core.netdev_max_backlog = 30000
net.ipv4.tcp_congestion_control=cubic
Я также увеличился длиной очереди передачи следующим образом:
ifconfig eth0 txqueuelen 10000
Наконец, я отключил сегмент TCP программного обеспечения, разгружающийся на VM (нет никакого аппаратного ПАЛЬЦА НОГИ на моем сервере).
Все еще, хотя, Wireshark показывает мне, что я не получаю больше, чем приблизительно 11 000 байтов в полете. У меня действительно есть некоторые отброшенные пакеты около начала передачи, но к тому времени, когда вещи действительно начинаются, я ожидал бы, что больше данных будет течь в полете.
Кто-либо может пролить некоторый свет на то, почему отправитель сдерживает данные, когда такие маленькие данные находятся на самом деле в полете?
В трассировке вашего пакета я вижу контроль перегрузки, реагирующий на потерю пакета.
Клиент начинает с отправки первых 9 сегментов, за которыми следует медленный старт, где он отправляет еще два сегмента каждый раз, когда получает пакет ACK.
Алгоритм медленного старта продолжается до тех пор, пока первый дублированный ACK от сервера не укажет, что пакет был потерян. Это происходит в точке, где находится 20820 байт. После этого клиент будет увеличивать окно перегрузки медленнее.
Второй случай перегрузки случается только через полсекунды передачи. После этого количество передаваемых байтов возрастает примерно с 15 КБ и достигает 68012 байтов в пути к тому времени, когда происходит третий случай перегрузки, то есть через 6 секунд после передачи.
После третьего случая перегрузки в отправке находится около 54 КБ. . Он увеличивается, пока не достигнет 94384 байта в полете, и произойдет четвертый случай перегрузки, это 10 секунд после передачи.
Есть еще несколько случаев перегрузки на остальной части трассировки. Передача могла бы набрать скорость, если бы она не приводила к потере пакетов так часто, как это было раньше. Испытывая потерю первого пакета уже на раннем этапе, потребуется много времени для достижения полной скорости.
Итак, вам нужно выяснить, почему пакеты теряются так рано во время TCP-соединения. Оказывается, что потерянный в этот момент пакет является одним из 9 пакетов, отправленных последовательно в самом начале соединения. Это указывает на то, что клиент настроен со слишком высоким значением initcwnd . Судя по предоставленному вами захвату одного пакета, разумной настройкой будет 4 .
Настройка initcwnd указывается отдельно для каждой записи в таблице маршрутизации. Их можно просмотреть и изменить с помощью команды ip route .