Я использую быструю сеть Ethernet со скоростью 100 Мбит / с, размер кадра которой меньше 1500 байт (1472 байт для полезной нагрузки согласно моему учебнику). Таким образом, я смог отправить и получить пакет UDP размером 65507 байт, что означает, что размер пакета был 65507 + 20 (заголовок IP) + 8 (заголовок UDP) = 65535.
Если сам размер полезной нагрузки кадра составляет максимум 1472 байта (согласно моему учебнику), как размер пакета IP может быть больше, чем тот, который здесь равен 65535?
Я использовал код отправителя как
char buffer[100000];
for (int i = 1; i < 100000; i++)
{
int len = send (socket_id, buffer, i);
printf("%d\n", len);
}
Код получателя как
while (len = recv (socket_id, buffer, 100000))
{
printf("%d\n". len);
}
Я заметил, что send returns -1на i > 65507и recvпечатает или получает пакет maximum of length 65507.
tcpip
udp
network-protocols
mtu
sysadmin1138
источник
источник
By default, Linux UDP does path MTU (Maximum Transmission Unit) discovery. This means the kernel will keep track of the MTU to a specific target IP address and return EMSGSIZE when a UDP packet write exceeds it.Уровень IP фрагментирует ваш пакет на передающей стороне, а затем снова собирает его обратно на принимающей стороне, прежде чем передать его в UDP. На уровне UDP вы не можете сказать, что пакет был фрагментирован. Если вы используете инструмент захвата пакетов, такой как Wireshark , вы должны увидеть, что ваш компьютер получает IP-пакеты, ограниченные MTU.
источник
Оказывается, что разрешение стеку TCP / IP фрагментировать пакеты по мере необходимости намного меньше затрат, чем отправка отдельных пакетов.
источник
UDP ничего не знает о MTU. Пакеты UDP могут иметь любой размер от 8 до 65535 байтов. Уровни протокола ниже UDP либо могут отправить пакет определенного размера, либо отклонят отправку этого пакета с ошибкой, если она слишком велика.
Уровень ниже UDP обычно IP, либо IPv4, либо IPv6. И IP-пакет может иметь любой размер от 20 (IPv4) / 40 (IPv6) до 65535 байтов, это столько же, сколько UDP. Однако IP поддерживает механизм, называемый фрагментацией . Если IP-пакет больше по размеру, чем тот, который может транспортировать нижний уровень, IP может разделить один пакет на несколько пакетов, называемых фрагментами. Каждый фрагмент фактически является собственным IP-пакетом (имеет собственный IP-заголовок) и также сам отправляется в пункт назначения; Задача получателя состоит в том, чтобы собрать все фрагменты и восстановить из них полный пакет перед передачей полученных данных на следующий более высокий уровень (например, UDP).
Протокол Ethernet может передавать только кадры с полезной нагрузкой от 46 до 1500 байт (есть исключения, но это выходит за рамки этого ответа). Если данные полезной нагрузки меньше 46 байтов, они дополняются до 46 байтов. Если данные полезной нагрузки превышают 1500 байт, интерфейс откажется принять их. Если это произойдет, то теперь IP-уровень решит либо фрагментировать пакет, чтобы ни один фрагмент не был длиннее 1500 байт, либо сообщить об ошибке следующему более высокому уровню, если фрагментация была отключена или запрещена для этого конкретного соединения.
Фрагментации, как правило, следует избегать, так как
Вот почему TCP разумно принимает свой размер кадра, так что пакетам никогда не требуется IP для их фрагментации. Это можно сделать, запретив IP фрагментировать пакеты, и если IP сообщает, что пакет слишком велик для отправки, TCP уменьшает размер кадра и повторяет попытку, пока больше не сообщается об ошибке.
Для UDP, однако, это будет задачей самого приложения, поскольку UDP является «тупым» протоколом, у него нет собственной логики управления, что делает его очень гибким, быстрым и простым.
Единственный размер UDP, на который можно всегда ориентироваться, - это 576 минус 8 байтов заголовка UDP и минус 20 (v4) / 40 (v6) байтов IP, поскольку стандарт IP требует, чтобы каждый хост IP мог принимать IP-пакеты с общий размер 576 байт. Реализация вашего протокола не будет соответствовать стандарту, если он не может принимать пакеты хотя бы такого размера. Обратите внимание, однако, что стандарт не говорит 576 без фрагментации, поэтому даже пакет из 576 байтов IP может быть фрагментирован между двумя хостами.
Единственный размер пакета, который вы можете использовать для переноса без фрагментации, составляет 24 байта для IPv4 и 56 байтов для IPv6, так как наименьшие заголовки IP для фрагмента составляют 20/48 байтов (v4 / v6), а фрагмент должен иметь как минимум 4/8 байт (v4 / v6) данные полезной нагрузки. Таким образом, транспортная система ниже уровня IP, которая не может транспортировать по меньшей мере пакеты этих размеров, не может использоваться для транспортировки IP-трафика.
И прежде чем кто-либо прокомментирует, что заголовок IPv6 имеет только 40 байтов: это правильно, но, в отличие от заголовка IPv4, стандартный заголовок IPv6 не имеет полей заголовка для фрагментации. Если пакет должен быть фрагментирован, то заголовок расширения фрагментации должен быть добавлен ниже базового заголовка IPv6, и этот заголовок расширения имеет длину 8 байтов. Кроме того, в отличие от IPv4, смещения фрагментации в IPv6 подсчитываются в 8 байтах, а не в 4 байтовых единицах, таким образом, фрагмент может переносить только полезную нагрузку, кратную 8 байтов в случае IPv6.
источник
Чтобы ответить на ваш вопрос: «Если сам размер полезной нагрузки кадра составляет максимум 1472 байта (согласно моему учебнику), как размер пакета IP может быть больше, чем тот, который здесь равен 65535?»
Это происходит из-за функции разгрузки, называемой UFO. (UDP Fragmentation Offload). Пожалуйста, обратитесь к этой ссылке.
Вы можете проверить и отключить функции разгрузки через ethtool -k ethX и ethtool -K ethX соответственно.
источник
Если вы отслеживаете исходящие кадры, возможно, ваш сетевой адаптер поддерживает разгрузку сегментации и он включен. С включенной разгрузкой сегментации сетевая карта сама обрабатывает сегментирование пакета / кадра в соответствующий размер, а не сетевой стек. Это освобождает процессор компьютера для выполнения других задач, повышая производительность. В linux ethtool -k [устройство] покажет флаги разгрузки.
источник