Мой источник отправляет пакеты по 4794 байта (по крайней мере, в зависимости от перехвата, который выглядит как 1 пакет каждый), однако, машина назначения отправляет 2 подтверждения для каждого пакета, отправленного из источника.
Я попытался изменить размер стека чтения компьютера назначения (/proc/sys/net/ipv4/tcp_rmem) на более высокое значение, чем 4906 (что является минимальным значением по умолчанию), но я не увидел никаких изменений.
Обе системы работают под управлением Linux (Centos).
Я использую tcpdump и 'wireshark' для анализа снимков.

Вот скриншот wireshark:

Src - 172.16.33.237, dst - 172.16.34.111.
Обратите внимание, что каждый пакет 4794 получает 2 подтверждения.
Пакеты из 194 байтов являются ответом приложения от пункта назначения (и я считаю, что это не имеет отношения к этому обсуждению)

|источник

3 ответа3

1

Многие сетевые адаптеры используют разгрузку больших сегментов, где драйвер сетевой карты отвечает за разделение данных TCP на более мелкие пакеты для передачи, а не на системный процессор. tcpdump/Wireshark перехватывает трафик до того, как его прервет сетевой адаптер, поэтому иногда вы можете видеть пакеты, размер которых превышает MTU интерфейса при перехвате.

Предполагая, что используется стандартный MTU в 1500 байт, для этого потребуется 4 пакета. Отложенное подтверждение TCP - это еще одна функция производительности, которая обычно приводит к отправке ACK для каждого второго пакета.

|источник
0

Прочитайте полную статью здесь.

Вы можете настроить размер буфера TCP. Сначала, пожалуйста, введите следующие команды, чтобы проверить настроенные значения: 

$ cat /proc/sys/net/ipv4/tcp_mem

Найдите максимальный объем памяти для получения сокета:

$ cat /proc/sys/net/core/rmem_default

$ cat /proc/sys/net/core/rmem_max

Для памяти отправляемого сокета:

$ cat /proc/sys/net/core/wmem_default

$ cat /proc/sys/net/core/wmem_max

И максимальное количество для буферов памяти:

$ cat /proc/sys/net/core/optmem_max

Значения настройки (wmem и rmem):

Вы должны установить максимальный размер отправляемого wmem и размера буфера rmem до 12 МБ для всех протоколов. Пожалуйста, следуйте командам:

# echo 'net.core.wmem_max=12582912' >> /etc/sysctl.conf

# echo 'net.core.rmem_max=12582912' >> /etc/sysctl.conf

Установите минимальный, начальный и максимальный размер (укажите в байтах):

# echo 'net.ipv4.tcp_rmem= 10240 87380 12582912' >> /etc/sysctl.conf

# echo 'net.ipv4.tcp_wmem= 10240 87380 12582912' >> /etc/sysctl.conf

Увеличить окно трансфера:

# echo 'net.ipv4.tcp_window_scaling = 1' >> /etc/sysctl.conf

Включить временные метки, как определено в RFC1323:

# echo 'net.ipv4.tcp_timestamps = 1' >> /etc/sysctl.conf

Включить подтверждения: 

# echo 'net.ipv4.tcp_sack = 1' >> /etc/sysctl.conf

Если метрики соединения для корневого кэша установлены при закрытии соединения, то:

# echo 'net.ipv4.tcp_no_metrics_save = 1' >> /etc/sysctl.conf

Установите максимальное количество пакетов для входной стороны:

# echo 'net.core.netdev_max_backlog = 5000' >> /etc/sysctl.conf

Пожалуйста, перезагрузите изменения:

# sysctl -p

Посмотреть изменения:

# tcpdump -ni eth0
|источник
0

MarkoPolo правильно. Но он не упомянул, что если вы используете сетевой сигнал, вы будете захватывать реальные пакеты, когда они отправляются по сети, и это будет иметь больше смысла. То, что вы видите, это 3 пакета, объединенные в один. Принимающий TCP использует задержанный ACK и подтверждает каждый один или два пакета.

Ответ приложения размером 194 байта имеет значение из-за поведения остановки и ожидания отправляющего устройства. Этот шаблон вызвал ваш вопрос. Если бы это была просто однонаправленная массовая передача без ответа сервера, развивалась бы совсем другая картина.

Кроме того, установка MTU на 9000 в сети с маршрутом по умолчанию, неверно. Это приведет к проблемам и ничего не добьется

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .