×

Предупреждение

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

IP фрагментация

Неотвеченый вопрос
Май 23rd, 2012
User Badges:
  • Bronze, 100 points or more

Добрый день коллеги, хотелось бы задать вопрос из области общих знаний. Допустим мы имеем фрагментированный пакет который передается по сети, из теории следует:

"Если хотя бы один фрагмент утерян — весь пакет должен быть отправлен заново."

Но почему? Неужели нельзя запросить отдельно фрагмент?

pmtud_ipfrag_02.gif

Картинка взята с http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml
Т.е. имеем потерю фрагмента sequence 0-2 мы легко определяем границы нехватающих данных (1501-3000-й байты) по остальным фрагментам (Fragment offset). Конечно если мы не получили последний фрагмент, где MF (more fragment) флаг 0, то мы не знаем последний фрагмент это или нет, но с остальными фрагментами таких проблем нет.

I have this problem too.
0 голоса
Loading.
Pavel Doronin ср, 05/23/2012 - 19:38
User Badges:
  • Bronze, 100 points or more

Допустим так. В скобках MTU.


HOST(1500)----(1500)ROUTER1(576)-----(576)ROUTER2(1500)---(1500)HOST


Хост послал пакет 1500 байт, ROUTER1 разбил их на 3 фрагмента и отправил на ROUTER2, допустим потеряли 2-й фрагмент, есть 1-й и 3-й.



1-й

572 байта = 20  +   552          offset =0

                        IP    TCP+data

                       байты 0-552

2-й

572 байта= 20  +   552          offset =69 (data from 1-st byte/8=552/8=69)

                       IP    data only

                      байты 553-1104

3-й

376 байта = 20  +   356          offset =138 ((data from1-st byte+ data from 2-nd byte)/8 = (552+552)/8=138)

                        IP    data only

                       байты 1105-1500


Из того что мы потеряли 2-й фрагмент можно вычислить какие байты потеряны по offset'ам. Имеем offset 0 и 552 байта данных и offset 138 и 356 байт данных. Т.е. по фрагменту 1 можно вычмслить offset 2-го фрагмента (69). По фрагменту 3 мы знаем offset 138, имея эти данные мы знаем что недостает данных с 69 по 138 offset. т.е. с 69*8+1=553 по 138*8=1104.

nkarpysh ср, 05/23/2012 - 20:04
User Badges:
  • Cisco Employee,

Добрый День.


ИМХО:


Проблема в том, что спрашивать не у кого.


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


По крайней мере я так понимаю.


Николай.

Pavel Doronin ср, 05/23/2012 - 22:20
User Badges:
  • Bronze, 100 points or more

Ну у роутера никак не спросит это точно, ведь то у стройство которое фрагментирует не оставляет о себе никаких сведений. Собирает фрагменты конечный получатель, и только он может знать что утеряны фрагменты. В чем проблема спросить у хоста отправителя?  Ведь отправитель пока не получил подтверждение о получении пакета держит его в буфере (для ретрансляции при потере). Что мешает реализовать функционал запроса частичных даннных у хоста отправителя с такого-то по такой бит? Единственно что отправитель должен будет отправить пакет отформатированный как фрагмент а не как обычный. Т.е. с офффсетом и флагами. Также отправитель может не держать его в буфере для ожидания подтверждения.

Даже имея TCP заголовок только в первом фрагменте мы может запросить данные у отправителя по полю IDENTIFIER

nkarpysh ср, 05/23/2012 - 23:13
User Badges:
  • Cisco Employee,

Одна из теоритических проблем в следующем.


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


В итоге получаем 2-ную инкапсуляцию как минимум + опять этот пакет будет больше МТУ - так как он равен МТУ (потерянные биты + заголовок фрагментации) + новый IP заголовок.  И мы опять его будем фрагментировать. Те даже если все пройдет гладко - особой выгоды мы не получим - может даже будет бОльшая задержка (так как по сравнению с простой пересылкой пакета - добавиться время на вычленение части пакета на источнике + какая-то новая обработка таких кусков на получателе).




Опять - всего лишь размышления.


Николай

Pavel Doronin чт, 05/24/2012 - 00:11
User Badges:
  • Bronze, 100 points or more

Не совсем понял про 2-ю инкапсуляцию. Получатель не поймет такой пакет.

При отправке фрагмента на источнике нет нужды в двойной инкапсуляции, т.е. не инкапсулируем фрагмент в новый IP пакет, а пересылаем IP пакет в котором помимо IP адресов еще заполняем поле  offset и флаги, соответственно получатель поймет его как фрагмент.

Ivan Krimmel ср, 05/23/2012 - 23:21
User Badges:
  • Gold, 750 points or more

Коллеги,


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


Иван.

Ivan Krimmel чт, 05/24/2012 - 02:02
User Badges:
  • Gold, 750 points or more

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


Иван.

Pavel Doronin чт, 05/24/2012 - 03:05
User Badges:
  • Bronze, 100 points or more

Ошибки ушли бы со временем.

Скорее всего дело вот в чем: восстанавливать фрагменты можно только посредством самого IP протокола, а не средствами TCP.

Фрагментируется IP а не TCP или любой другой транспортный протокол. Перед тем как передать весь пакет с уровня IP на уровень выше (TCP, UDP и т.д.), пакет должен быть полностью собран. Если мы потеряли фрагмент, мы не можем передать фрагмент на уровень выше. Т.е. мы должны умудрится восстановить пакет средствами самого IP! Для этого надо было бы превратить сам IP в TCP, т.е. сделать алгоритм его работы таким же как у TCP. Т.е. TCP ждет получение подтверждения занимая буфер и IP ждет подтверждения занимая буфер. Т.e. помимо TCP ACK, нам бы потребовалось что-то вроде бы IP ACK.

Dmitry Leontyev чт, 05/24/2012 - 13:23
User Badges:
  • Cisco Employee,

Павел, разрешите вставить свои пять копеек.

Все о чем вы говорите уже было в жизни сетей. Достаточно вспомнить хотя бы стек проктоколов X.25, в котором протокол на каждом уровне - канальном, сетевом, транспортном был надежным протоколом с установлением соединения и подтверждениями (читай вел себя как TCP). Так вот, эти все протоколы вымерли как мамонты (кто мне подскажет, Х.28 когда перестали использовать для подключения банкоматов ?). Потому что эти протоколы создавались для работы по плохим линиям с большим количеством ошибок и маленькой скоростью передачи. И лучше всего было на каждом сегменте проконтролировать правильность передачи. С появлением более менее скоростных и надежных линий связи (читай доступности оптоволоконных каналов), стали отказываться от многоуровневой проверки правильности передаваемой информации, для того чтобы минимизировать задержки (Frame Relay, ATM). Так как легче передать испорченный (с малой вероятностью) пакет целиком или последовательность пакетов, начиная с испорченного, оставляя один протокол в стеке, который будет заниматься контролем передачи, чем контролировать правильность передачи кадров на каждом уровне, утяжеляя стек протоколов и увеличивая задержки. Собственно тоже самое можно сказать и о паре протоколов для ЛВС Ethernet vs Token Ring.

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

Pavel Doronin чт, 05/24/2012 - 18:35
User Badges:
  • Bronze, 100 points or more

О чем и речь, что в IP нет возможности восстановить утеряные фрагменты/пакеты, поэтому потеря фрагмента/пакета = потере пакета.

Хотелось бы немного уточнить (в рамках познания истории) - X.25 это протокол всего-лишь канального уровня, откуда там взялся надежный сетевой?

Oleg Tipisov сб, 06/09/2012 - 11:53
User Badges:
  • Cisco Employee,
  • Events Top Contributors,

    Cisco, 2014

Любопытная дискуссия. X.25 всю жизнь был протоколом сетевого уровня, а на канальном уровне там работал LAPB.

Dmitry Leontyev сб, 06/09/2012 - 14:03
User Badges:
  • Cisco Employee,

Эх, скоро совсем забудем то, что долгие годы служило на благо цивилизации. Я имею ввиду протоколы Х-стека. На физическом уровне можно было использовать например Х.21, на канальном уровне работал X.25 канального уровня (Х.25/2) или LAPB, на сетевом уровне X.25 сетевого уровня (Х.25/3) или PLP, на транспортном Х.224, на уровне приложений Х.400, Х.500. Вот тут немного теории http://docwiki.cisco.com/wiki/X.25

Хороший был стек, надежный. Правительственные организации до начала 2000 годов на нем работали, банковские структуры, например S.W.I.F.T. Кстати многие с X.25 перешли впоследствии на MPLS.

Вот нашел новость в архивах о таком переходе http://www.global-one.by/resource/news/040707.html

Pavel Doronin вт, 06/12/2012 - 22:13
User Badges:
  • Bronze, 100 points or more

Делайте скидку на то что некоторые ещё институт не закончили в 2004 году ))), а там уже не преподавали X-стеки. Видимо уже не актуально было.

Действия

Информация о дискуссии