У меня есть две виртуальные машины Linux, разделенные WAN-соединением 50 Мбит / с. RTT на этом канале WAN составляет около 70 мс, поэтому у него есть некоторая задержка. Я тестировал свою пропускную способность при загрузке в Интернет с каждой из этих виртуальных машин. Базовая настройка заключается в том, что сайт A имеет подключение к Интернету, а также соединение WAN с сайтом B. Сайт B использует подключение к Интернету на сайте A.
Я заметил, что сайт B загружает в Интернет изрядно медленнее, чем сайт A. Я просто использовал некоторые из этих сайтов тестирования скорости Интернета, чтобы проверить свою скорость загрузки. Я использовал один и тот же сайт для проверки скорости Интернета и сервер с каждого сайта для проведения тестирования. Я также много-много раз проводил тесты.
Я запустил несколько шапок Wireshark, чтобы посмотреть, что происходит. Я предположил, что Интернет-сервер не открывает достаточно широкое окно TCP, чтобы учесть мои 70 мс дополнительной задержки с сайта B. Однако окно TCP широко открыто, и на самом деле мой сервер на сайте B прекращает передачу, ожидая ACK. чтобы войти перед отправкой дополнительных данных.
Я просмотрел кучу вещей: временные метки TCP, SACK и масштабирование окна включены. Я увеличил свои буферы следующим образом:
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-сегмента на виртуальной машине (на моем сервере нет аппаратного TOE).
Тем не менее, Wireshark показывает мне, что я получаю не более 11 000 байт в полете. У меня действительно есть несколько отброшенных пакетов в начале передачи, но к тому времени, когда все действительно начнется, я ожидал, что в полете будет передаваться больше данных.
Может ли кто-нибудь пролить свет на то, почему отправитель скрывает данные, когда на самом деле их так мало?
В трассировке вашего пакета я вижу контроль перегрузки, реагирующий на потерю пакетов.
Клиент начинает отправку первых 9 сегментов, за которыми следует медленный старт, при этом он отправляет еще два сегмента каждый раз, когда получает пакет ACK.
Алгоритм медленного старта продолжается до тех пор, пока первый дублирующий ACK от сервера не укажет, что пакет был потерян. Это происходит в момент, когда в пути находится 20820 байт. После этого клиент будет увеличивать окно перегрузки медленнее.
Второй случай перегрузки происходит через полсекунды передачи. После этого количество передаваемых байтов возрастает примерно с 15 КБ и достигает 68012 байтов в пути к тому времени, когда происходит третий случай перегрузки, который составляет 6 секунд после передачи.
После третьего случая перегрузки в полете осталось около 54 КБ. Он увеличивается, пока не достигнет 94384 байта в полете, и произойдет четвертый случай перегрузки, это 10 секунд после передачи.
Есть еще несколько случаев скопления на оставшейся части трассы. Передача могла бы набрать скорость, если бы она не приводила к потере пакетов так часто, как это было раньше. После потери первого пакета уже потребовалось много времени, чтобы достичь полной скорости.
Итак, вам нужно выяснить, почему пакеты теряются так рано во время TCP-соединения. Оказывается, что потерянный в этот момент пакет является одним из 9 пакетов, отправленных последовательно в самом начале соединения. Это указывает на то, что клиент настроен на слишком высокий initcwnd настройка. Судя по предоставленному вами захвату одного пакета, разумной настройкой будет 4.
В initcwnd настройка указывается отдельно для каждой записи таблицы маршрутизации. Их можно просмотреть и изменить с помощью ip route команда.