Насколько плоха ip фрагментация

Question

Я понимаю, что при отправке ip-сообщений каждый переход в сетевом пути между be и адресатом моего пакета будет проверять, больше ли MTU следующего перехода, чем размер отправленного мной пакета. Если это так, пакет будет фрагментирован, и эти два пакета будут отдельно отправлены на следующий переход, только для повторной сборки в месте назначения (или, в некоторых случаях, на первом обнаруженном маршрутизаторе NAT). Насколько я понимаю, это может быть довольно плохо, но я не совсем понимаю, почему.

• Я понимаю, что если соединение имеет тенденцию сбрасывать много пакетов, потеря одного фрагмента означает, что я должен повторно отправить весь пакет (это фактически единственная вещь, которую я понял сам)
• Есть ли вероятность, что вместо фрагментации мой пакет будет просто отброшен?
• Как идентифицировать фрагменты пакета? Могу ли я быть на 100% уверен, что они будут правильно собраны? Например, если я отправляю два ip-пакета одинаковой длины почти одновременно в один и тот же пункт назначения, какова вероятность того, что фрагменты этих двух будут поменены местами, как AAA, BBB, повторно собранные в ABA, BAB?

В принципе, если пакеты не отброшены и фрагменты собраны правильно, фактически использование фрагментации пакетов кажется хорошей идеей для экономии локальной пропускной способности и избежания необходимости отправлять все больше и больше заголовков вместо одного большого пакета.

Спасибо

Answer 1

Насколько мне известно, единственный случай, когда пакеты будут отброшены, а не фрагментированы (за исключением случаев, когда они все равно будут отброшены), это пакеты, помеченные как "не фрагментировать". Эти пакеты следует отбрасывать, а не фрагментировать.

Фрагментированные пакеты имеют в своих заголовках поля идентификатора, смещения фрагмента и других фрагментов, которые при объединении позволяют целевому хосту надежно собирать пакет после получения всех фрагментов. Смещение первого фрагмента равно нулю, а последний фрагмент имеет флаг "больше фрагментов", установленный в ноль. Все еще возможно (хотя и очень маловероятно) собрать неправильный пакет, если заголовки двух пакетов изменены, поэтому их смещения фрагментов обмениваются, но их контрольные суммы все еще действительны. Вероятность того, что это произойдет, практически равна нулю. Имейте в виду, что IP не предоставляет никакого механизма для обеспечения целостности полезной нагрузки данных, только целостность управляющей информации в заголовке.

Фрагментация пакетов обязательно тратит пропускную способность, поскольку каждый фрагмент имеет копию [большей части] исходного заголовка дейтаграммы. Пакеты могут быть фрагментированы до 8 байтов на фрагмент, поэтому мы можем получить пакет максимального размера 60 + 65536 байтов, фрагментированный на 60 * 8192 + 65536 байтов, что в худшем случае даст увеличение полезной нагрузки примерно на 750%. Единственный пример, который я могу привести, - это если вы фрагментируете пакет для параллельной отправки его фрагментов, используя какую-то схему мультиплексирования с частотным разделением, зная, что другие каналы свободны. В этот момент все еще кажется, что для обнаружения этого обстоятельства и разделения пакета требуется больше работы, чем было бы сэкономлено, а не просто для его отправки.

Все основные сведения о механизме фрагментации пакетов в IP можно найти в IETF RFC 791, если вы хотите получить дополнительную информацию.

Answer 2

Фрагментация IP может вызвать несколько проблем:

1) Увеличена потеря уровня приложения

Как вы упомянули, если отбросить один фрагмент, весь пакет уровня 4 будет потерян. Таким образом, для сети с малой случайной скоростью потери пакетов коэффициент потерь уровня приложений увеличивается примерно на число фрагментов для каждого пакета уровня 4.

2) Не все сети обрабатывают фрагментированные пакеты

Некоторые системы, такие как Google Compute Engine, не собирают фрагментированные пакеты.

3) Фрагментация может вызвать переупорядочение

Когда маршрутизаторы разделяют трафик по параллельным путям, они могут пытаться сохранить пакеты из одного потока на одном пути. Поскольку только первый фрагмент имеет информацию уровня 4, такую ​​как номер порта UDP/TCP, последующие фрагменты могут быть направлены по другому пути, что задерживает сборку пакета уровня 4 и вызывает переупорядочение.

4) Фрагментация может вызвать запутанное поведение, которое трудно отладить

Например, если вы отправляете два потока UDP, A и B, из одного источника в пункт назначения под управлением Linux, пункт назначения может отбрасывать пакеты из одного из потоков. Это связано с тем, что по умолчанию Linux "блокирует" очереди фрагментов, если из того же источника было получено более 64 других фрагментов. Если поток A имеет намного более высокую скорость передачи данных, чем поток B, 64 фрагмента из потока A могут поступать между фрагментами из потока B, вызывая отбрасывание фрагмента B.

Таким образом, хотя фрагментация IP-адресов может снизить накладные расходы путем минимизации заголовков пользователей, она может вызвать больше проблем, чем она того стоит.