IP и другие протоколы нижнего уровня

Корпоративная сеть — это сложная система, состоящая из большого числа раз­нообразных компонентов: компьютеров, концентраторов, маршрутизаторов, ком­мутаторов, системного прикладного программного обеспечения и т. д. Основная задача системных интеграторов и администраторов сетей состоит в том, чтобы эта система как можно лучше справлялась с обработкой потока информации и позволяла пользователям решать их прикладные задачи. Прикладное программ­ное обеспечение часто обращается к службе, обеспечивающей связь с другими прикладными программами по сети. Этой службой является механизм межсете­вого обмена.

Парадигмы обработки корпоративной информации не постоянны. Приме­ром резкого изменения подхода к обработке корпоративной информации стал беспрецедентный рост популярности глобальной сети Internet за последние 2-3 года. Сеть Internet изменила способ представления информации, объединив на своих узлах все ее виды — текст, графику и звук. Транспортная система сети Internet существенно облегчила задачу построения распределенной корпоратив­ной сети.

Основой сети Internet является набор протоколов, называемый стеком прото­колов TCP/IP (Transmission Control Protocol/Internet Protocol, протокол управ­ления передачей/протокол сети Internet). Он реализует межсетевой обмен.

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

История создания TCP/IP ведет свое начало с момента, когда министерства обороны США столкнулось с проблемой объединения большого числа компьютеров с различными операционными системами. В 1970 году был разработан необходимый набор стандартов. Протоколы, разработанные на базе этих стандартов, получили обобщенное название TCP/IP.

Стек TCP/IP был изначально разработан для сети Advanced Research Project Agency Network (ARPANET). ARPANET рассматривалась как экспериментальная распределенная сеть с коммутацией пакетов. Эксперимент применению TCP/IP в этой сети закончился положительно. В результате с протоколов был принят в промышленную эксплуатацию, а в дальнейшем расширялся и совершенствовался в течение нескольких лет. Позже стек адаптировали для использования в локальных сетях. В начале 1980 года протокол с составной частью операционной системы Berkley UNIX v4.2. В том же году появилась объединенная сеть Internet. Переход к технологии Internet б завершен в 1983 году, когда министерство обороны США решило, что все компьютеры, присоединенные к глобальной сети, будут использовать стек протоколов TCP/IP.

Стек TCP/IP предоставляет пользователям две основные службы, которые используют прикладные программы:

q Дейтаграммное средство доставки пакетов. Это означает, что протоколы стека TCP/IP определяют - маршрут передачи небольшого сообщения, основываясь только на адресной информации, находящейся в этом coo6щении. Доставка осуществляется без установки логического соединения. Такой тип доставки делает протоколы TCP/IP адаптируемыми к широкому диапазону сетевого оборудования;

q Надежное потоковое транспортное средство. Большинство приложений требуют от коммуникационного программного обеспечения автоматического восстановления при ошибках передачи, потери пакетов или c6оев промежуточных маршрутизаторах. Надежное транспортное средство позволяет устанавливать логическое соединение между приложениями, а затем посылать большие объемы данных по этому соединению.

Основными преимуществами стека протоколов TCP/IP являются:

q Независимость от сетевой технологии. TCP/IP не зависит от оборудования, так как он только определяет элемент передачи — дейтаграмму - описывает способ ее движения по сети;

q Всеобщая связанность. Стек позволяет любой паре компьютеров, которые его поддерживают, взаимодействовать друг с другом. Каждому компьютеру назначается логический адрес, а каждая передаваемая дейтаграмма содержит логические адреса отправителя и получателя. Промежуточные маршрутизаторы используют адрес получателя для принятия решения маршрутизации;

q Подтверждения. Протоколы стека TCP/IP обеспечивают подтверждения правильности прохождения информации при обмене между отправителем и получателем;

q Стандартные прикладные протоколы. Протоколы TCP/IP включают в свой состав средства поддержки основных приложений, таких как элект­ронная почта, передача файлов, удаленный доступ и т. д.

Резкий рост сети Internet и все большее распространение стека протоколов TCP/IP привело к выпуску серии документов, которые призваны способство­вать дальнейшему упорядоченному развитию протоколов. Организация Internet Activities Board (IAB) выпускает документы, называемые RFC (Request For Comments, обращение за разъяснением). Некоторые RFC описывают сетевые службы или протоколы и их реализацию, другие документы описывают условия применения. В RFC опубликованы стандарты TCP/IP. При этом следует иметь в виду, что стандарты TCP/IP всегда публикуются в виде документов RFC, но не все RFC определяют стандарты.

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

Содержание документов RFC делится на две части:

q Состояние стандартизации. Протокол может иметь несколько состояний:

· Стандарт на протокол утвержден;

· Стандарт на протокол предлагается к рассмотрению;

· Предлагается экспериментальный протокол;

· Протокол устарел и в настоящее время не используется;

q Статус протокола. Протокол может иметь несколько статусов:

· Протокол должен быть внедрен;

· Протокол рекомендуется для внедрения;

· Протокол может внедряться производителем по выбору;

· Протокол не рекомендуется для внедрения.

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

q Распознавать сбои в сети и восстанавливать ее работоспособность;

q Распределять пропускную способность сети и уменьшать поток данных при перегрузке;

q Распознавать задержки и потери пакетов и принимать контрмеры;

q Распознавать ошибки в данных и информировать о них прикладное программное обеспечение;

q Упорядочивать движение пакетов в сети.

Такое количество функциональных возможностей не может вместить ни один протокол. Поэтому был создан набор взаимодействующих протоколов, на­званный стеком. Так как стек протоколов TCP/IP был разработан до появления эталонной модели OSI, то соответствие его уровней с уровнями OSI достаточно условно. В табл. 6.1 показаны структура стека протоколов TCP/IP и соответст­вие уровней OSI и стека TCP/IP уровням модели ATM.

Таблица 6.1. Соответствие уровней стека TCP/IP уровням моделей OSI и ATM

Теоретически, посылка сообщения от одной прикладной программы к другой означает последовательную передачу сообщения вниз по уровням стека у отпра­вителя, передачу сообщений по уровню сетевого интерфейса (уровню IV) или, в соответствии с эталонной моделью OSI, по физическому уровню, прием сообще­ния получателем и передачу его вверх по уровням. Физический уровень может быть реализован транспортными механизмами ATM. На практике, взаимодейст­вие уровней стека организовано гораздо сложнее. Каждый уровень принимает решение о правильности сообщения и производит определенное действие на ос­новании типа сообщения или адреса назначения. В структуре стека протоколов TCP/IP имеется явный «центр тяжести» — это сетевой уровень и его протокол IP. Протокол IP может взаимодействовать с несколькими протоколами более высокого уровня и несколькими сетевыми интерфейсами. То есть, на практике процесс передачи сообщений от одной прикладной программы к другой будет выглядеть следующим образом: отправитель передает сообщение, которое на уровне III протоколом IP помещается в дейтаграмму и посылается в сеть (сеть 1). На промежуточных устройствах, например маршрутизаторах, дейта­грамма передается вверх до уровня протокола IP, который отправляет ее обрат­но вниз, в другую сеть (сеть 2). Когда дейтаграмма достигает получателя, протокол IP выделяет сообщение и передает его на верхние уровни.

Структуру стека протоколов TCP/IP можно разделить на четыре уровня.

Самый нижний — уровень сетевого интерфейса (уровень IV) — соответству­ет физическому и канальному уровням модели OSI. В стеке протоколов TCP/IP этот уровень не регламентирован. Уровень сетевого интерфейса отвечает за прием дейтаграмм и передачу их по конкретной сети. Интерфейс с сетью может быть реализован драйвером устройства или сложной системой, которая исполь­зует свой протокол канального уровня (коммутатор, маршрутизатор). Он под­держивает стандарты физического и канального уровней популярных локальных сетей: Ethernet, Token Ring, FDDI и т. д. Для распределенных сетей поддержи­ваются протоколы соединений РРР и SLIP, а для глобальных сетей — протокол Х.25. Предусмотрена поддержка технологии коммутации ячеек — ATM. Обыч­ной практикой стало включение в стек протоколов TCP/IP новых технологий локальных или распределенных сетей и регламентация их новыми документа­ми RFC.

Сетевой уровень (уровень III) — это уровень межсетевого взаимодействия. Уровень управляет взаимодействием между пользователями в сети. Он прини­мает запрос на посылку пакета от транспортного уровня вместе с указанием адреса получателя. Уровень инкапсулирует пакет в дейтаграмму, заполняет ее заголовок и при необходимости использует алгоритм маршрутизации. Уровень обрабатывает приходящие дейтаграммы и проверяет правильность поступившей информации. На стороне получателя дейтаграммы программное обеспечение се­тевого уровня удаляет заголовок дейтаграммы и определяет, какой из транспорт­ных протоколов будет обрабатывать пакет.

В качестве основного протокола сетевого уровня в стеке протоколов TCP/IP используется протокол IP, который создавался как раз с целью передачи инфор­мации в распределенных сетях. Достоинством протокола IP является воз­можность его эффективной работы в сетях со сложной топологией. При этом протокол рационально использует пропускную способность низкоскоростных линий связи. В основе протокола IP заложен дейтаграммный метод, который не гарантирует доставку пакета, но «стремится» к этому. Для поддержки совмест­ной работы протокола IP и технологии ATM комитетом IETF был разработан стандарт «Классический IP и ARP поверх ATM», который позволяет преобразо­вывать IP-адреса сетевого уровня в адреса ATM и передавать пакеты ТСР/IP по сети ATM. К этому уровню относятся все протоколы, которые создают, под­держивают и обновляют таблицы маршрутизации. Кроме того, на этом уровне функционирует протокол обмена информацией об ошибках между маршрутиза­торами в сети и отправителями.

Следующий уровень — транспортный (уровень II). Основной его задачей яв­ляется взаимодействие между прикладными программами. Транспортный уро­вень управляет потоком информации и обеспечивает надежность передачи. Для этого использован механизм подтверждения правильного приема с дублирова­нием передачи утерянных или пришедших с ошибками пакетов. Транспортный Уровень принимает данные от нескольких прикладных программ и посылает их более низкому уровню. При этом он добавляет дополнительную информацию к каждому пакету, в том числе контрольную сумму. На этом уровне функциони­рует протокол управления передачей данных TCP (Transmission Control Proto­col) и протокол передачи прикладных пакетов дейтаграммным методом UDP (User Datagram Protocol). Протокол TCP обеспечивает гарантированную достав­ку данных за счет образования логических соединений между удаленными при­кладными процессами. Работа протокола UDP аналогична IP, но основной его задачей является связь сетевого протокола и различных приложений.

Самый верхний уровень (уровень I) — прикладной. На этом уровне реали­зованы широко используемые сервисы прикладного уровня. К ним относятся: протокол передачи файлов между удаленными системами (FTP), протокол эму­ляции удаленного терминала (telnet), почтовые протоколы, протокол разреше­ния имен (DNS) и т. д. Каждая прикладная программа выбирает тип транспортировки — либо непрерывный поток сообщений, либо последователь­ность отдельных сообщений. Прикладная программа передает данные транспорт­ному уровню в требуемой форме.

Рассмотрение принципов функционирования стека протоколов TCP/IP целе­сообразно начать с протоколов уровня III. Это связанно с тем, что протоколы более высоких уровней в своей работе опираются на функциональные возмож­ности протоколов низкого уровня. Для понимания маршрутизации в корпо­ративных сетях изучение протоколов рекомендуется проводить в следующей последовательности: IP, ARP, ICMP, UDP и TCP. Это связано с тем, что для доставки информации между удаленными системами в распределенной сети ис­пользуются в той или иной степени все члены семейства TCP/IP.

Стек протоколов TCP/IP включает большое число протоколов прикладного уровня. Они выполняют различные функции, в том числе: управление сетью, передачу файлов, оказание распределенных услуг при использовании файлов, эмуляцию терминалов, передачу электронной почты и т. д. Протокол передачи файлов (File Transfer Protocol — FTP) обеспечивает пересылку файлов между компьютерными системами. Протокол Telnet эмулирует терминал. Простой про­токол управления сетью (Simple Network Management Protocol — SNMP) ис­пользуется для сообщений об аномальных условиях в сети и установления значений допустимых порогов в сети. Простой протокол передачи почты (Simple Mail Transfer Protocol — SMTP) обеспечивает пересылку электронной почты. Эти протоколы и другие приложения используют TCP/IP.

Стек протоколов TCP/IP еще долгое время будет базовым в корпоративных сетях. Это связано с практически полным отсутствием новых приложений, спо­собных работать самостоятельно поверх сетей ATM. В этой связи в последние годы разработано и предложено к внедрению несколько различных вариантов использования стека протоколов TCP/IP в сетях ATM, иногда даже несмотря на некоторое снижение эффективности и пропускной способности сетей ATM. Например, эффективность TCP достаточно серьезно снижается из-за необходи­мости проведения фрагментации при поступлении пакета TCP/IP на уровень адаптации ATM (AAL). Необходимость преобразования пакета связана со зна­чительно большим его размером по отношению к ячейке. Резкое снижение эф­фективности сети может произойти при потере хотя бы одной ячейки. В этом случае неизбежной будет повторная передача всего пакета, что приведет к до­полнительной загрузке сети.

Стек TCP/IP — это тот сетевой и протокольный базис, на котором построен Internet. В стеке протоколов TCP/IP схема идентификации абонентов в сети аналогична физической адресации. Каждому устройству в сети присваивается уникальный 32-битный адрес, который называется IP-адресом. Он имеет вполне определенную структуру. В адрес входит идентификатор сети, к которой подсое­динено устройство, и идентификатор самого устройства, уникальный в данной сети.

Компьютеры или другие сложные сетевые устройства, подсоединенные к не­скольким физическим сетям, имеют несколько IP-адресов — по одному на каж­дый сетевой интерфейс. Можно сказать, что адрес в сети Internet назначается не отдельному устройству, а сетевому интерфейсу. Схема адресации позволяет про­водить единичную (unicast), широковещательную (broadcast) и групповую (mul­ticast) адресацию.

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

Групповая адресация используется для отправки сообщений определенным адресатам (multicasting). Поддержка групповой адресации обязательна для мно­гих приложений, например, интерактивных конференций, электронной почты и групп новостей. Для групповой передачи рабочие станции и маршрутизаторы используют протокол IGMP (Internet Group Management Protocol), который предоставляет информацию о принадлежности устройств определенным группам.

IP-адреса больших сетей в Internet определяются специальной организаци­ей - Internet Network Information Center (InterNIC). Назначение идентифи­каторов устройств не входит в компетенцию InterNIC и находится в ведении системного администратора конкретной сети. До 1 апреля 1993 г. (дата создания InterNIC) назначение IP-адресов и имен доменов DNS выполнялось организа­цией Network Information Center (NIC). В настоящее время NIC обслуживает только сети министерства обороны США — DDN (Defense Data Network). Все остальные организации, входящие в Internet, обслуживаются InterNIC.

В больших корпоративных сетях управлять IP-адресами «вручную» практи­чески невозможно. В частности, чрезвычайно сложно гарантировать уникаль­ность адресов. А назначать IP-адреса приходится достаточно часто. Например, если рабочая станция перемещается в другую подсеть, необходимо сменить ее сетевой идентификатор. Для помощи сетевому администратору в этом нелегком деле разработаны различные программные продукты и сетевые технологии.

В стек TCP/IP входит множество протоколов, отвечающих различным уровням эталонной модели OSI. В этой главе описаны все основные протоколы в порядке от низших уровней к высшим. Протокол TCP изложен в следующей главе.

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

При постоянных виртуальных соединениях конечные станции заведомо из­вестны и не требуется использовать адресную схему.

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

Протокол IP

Описание протокола IP (Internet Protocol) дано в документе RFC 791. IP яв­ляется базовым протоколом всего стека TCP/IP. Он отвечает за передачу информации по сети. Информация передается блоками, которые называются дейтаграммами.

IP является протоколом сетевого уровня. При этом для каждой среды пере­дачи данных, например, Ethernet и ATM, определен способ инкапсуляции IP-дейтаграмм. Маршрутизаторы пересылают инкапсулированные дейтаграммы по различным сетям, образуя объединение IP-сетей, по которому каждая рабочая станция может поддерживать связь по протоколу IP с любой другой рабочей станцией.

Услуги, предлагаемые протоколом IP, сводятся к негарантированной достав­ке дейтаграмм. Протокол IP не исключает потерь дейтаграмм, доставки дейта­грамм с ошибками, а также дублирования и нарушения порядка следования дейтаграмм, заданного при их отправлении.

Протокол IP выполняет фрагментацию и сборку дейтаграмм, если принятый размер кадров в данной сети (или участке распределенной сети) отличается от размера исходных дейтаграмм. В протоколе IP отсутствуют механизмы повыше­ния достоверности передачи данных, управления протоколом и синхронизации, которые обычно предоставляются в протоколах более высокого уровня. Прото­кол IP получает информацию для передачи от протоколов, расположенных по сравнению с ним на более высоком уровне. К этим протоколам, прежде всего, относятся протоколы TCP и UDP. После получения информации от них прото­кол IP передает дейтаграммы через распределенную сеть, используя сервисы локальных сетей.

Дейтаграмма состоит из заголовка и поля данных, которое следует сразу за заголовком. Длина поля данных определяется полем «Общая длина» в заголов­ке. На рис. 6.1 показан формат заголовка IP-дейтаграммы.

Рис. 6.1. Формат заголовка дейтаграммы протокола IP

q Поле «Номер версии» указывает на версию используемого протокола IP. В настоящее время распространена версия 4, но планируется переход к версии 6. Связь между абонентами гарантируется только в том случае, если все они работают с одной версией протокола IP. Перед обработкой дейтаграммы это поле проверяется. Если используется, например, версия 4, то при обработке будут отбрасываться дейтаграммы с версией 6.

q Поле «Длина заголовка» определяет длину заголовка в 32-битовых сло­вах. Заголовок может иметь минимальный размер 5 слов. При увеличении объема служебной информации эта длина может быть увеличена за счет поля «Опции».

q Поле «Тип сервиса» определяет способ обслуживания дейтаграммы. Первые три бита (0-2) этого поля задают приоритет дейтаграммы. Возможные значения приоритета — от 0 (обычная дейтаграмма) до 7 (уп­равляющая дейтаграмма). Устройства в сети учитывают приоритет дей­таграммы и обрабатывают в первую очередь более важные. Информация в остальных битах поля используется протоколами маршрутизации OSPF и BGP. Протоколы маршрутизации отвечают за вычисление наилучшего маршрута к получателю, основываясь на понятии «стоимость пути». Ею может быть скорость, надежность и т. д.

Третий бит (бит 2 — отсчет начинается с нулевого бита) определяет вид за­держки: 0 — нормальная задержка, 1 — малая задержка. Этот бит учитывается различными алгоритмами управления перегрузкой сети. Четвертый бит (3) оп­ределяет пропускную способность (нормальная или высокая). Пятый бит (4) определяет надежность доставки. Шестой и седьмой биты зарезервированы. От­метим, что программное обеспечение большинства рабочих станций и маршру­тизаторов игнорирует тип сервиса.

Протокол IP обрабатывает каждую дейтаграмму в независимости от ее при­надлежности к тому или иному пакету. При этом используются четыре основ­ных механизма: установка типа сервиса, установка времени жизни, установка опций и вычисление контрольной суммы заголовка. Тип сервиса характеризует набор услуг, которые требуются от маршрутизаторов в распределенной сети. Эти параметры должны использоваться для управления выбором реальных ра­бочих характеристик при передаче дейтаграмм. В некоторых случаях передача дейтаграммы осуществляется с установкой приоритета, который дает данной дейтаграмме по сравнению с остальными некоторые преимущества при обработ­ке. Тип сервиса определяется тремя показателями: малой задержкой при переда­че, высокой достоверностью и большой пропускной способностью.

Поле «Время жизни». При определенных условиях IP-дейтаграммы могут попасть в замкнутый логический контур, образованный некоторой группой маршрутизаторов. Иногда такие логические контуры существуют в течение ко­роткого промежутка времени, порой они оказываются достаточно долговечными. Чтобы избавить сеть от дейтаграмм, циркулирующих в таких логических конту­рах слишком долго, протоколом IP устанавливается предельный срок пребы­вания дейтаграммы в сети. Он задается в поле «Время жизни» — TTL (Time To Live). Его содержимое уменьшается на единицу при прохождении дейтаграммы через маршрутизатор; при обнулении поля TTL дейтаграмма отбрасывается.

Первоначально спецификации IP включали еще одно требование: поле TTL должно уменьшаться, по крайней мере, один раз в секунду. Поскольку поле TTL является восьмиразрядным, это означает, что дейтаграмма могла находиться в сети не более 4.25 мин. На практике требование ежесекундного уменьшения поля TTL игнорируется, тем не менее в спецификациях многих протоколов сле­дующих уровней (TCP) по-прежнему предполагается, что максимальное время жизни дейтаграммы в сети составляет лишь две минуты.

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

q Поле «Общая длина» указывает общую длину дейтаграммы (заголовок и поле данных). Максимальный размер дейтаграммы может составлять 65535 байт. В подавляющем большинстве сетей столь большой размер дейтаграмм не используется. По стандарту все устройства в сети должны быть готовы принимать дейтаграммы длиной 576 байт. Эти ограничения необходимы для передачи дейтаграмм в физических кадрах. Передача дей­таграммы в кадре называется инкапсуляцией. С точки зрения низших уровней дейтаграмма выглядит так же, как и любое другое сообщение в сети. Сетевое оборудование не работает с дейтаграммами, поэтому дейтаграмма является частью области данных кадра (рис. 6.2).

Рис. 6.2. Инкапсуляция дейтаграммы в кадр

Функции фрагментации и сборки также возложены на протокол IP. Фраг­ментация — это разделение большой дейтаграммы на несколько небольших час­тей. В большинстве локальных и глобальных сетей есть ограничения на максимальный размер кадра. Эту величину называют максимальной единицей передачи (Maximum Transmission Unit, MTU). Например, в сетях Ethernet дан­ная величина составляет 1500 байт, а в сетях FDDI — 4096 байт.

Когда маршрутизатор переправляет дейтаграмму из одной сети в другую, может оказаться, что ее размер окажется недопустимым в новой сети. Специфи­кация IP предусматривает следующее решение этой проблемы: маршрутизатор может разбить дейтаграмму на более мелкие фрагменты, приемлемые для вы­ходной среды, а в пункте назначения эти фрагменты будут вновь объединены в дейтаграмму исходного вида. Формируемые маршрутизатором фрагменты иден­тифицируются смещением относительно начала исходной дейтаграммы. Дейта­грамма идентифицируется по отправителю, пункту назначения, типу протокола высокого уровня и 16-разрядному полю «Идентификатор». Все это в совокуп­ности должно образовывать уникальную комбинацию.

Следует подчеркнуть связь между полями «Время жизни» и «Идентифика­тор». Действительно, во избежание смешивания фрагментов двух разных дей­таграмм источник IP-данных обязан исключить ситуацию, когда в один пункт назначения по одному и тому же протоколу в течение жизненного цикла дейта­граммы будут отправлены две дейтаграммы с совпадающими идентификаторами. В связи с тем, что идентификатор 16-разрядный, а наибольшее время жизни дейтаграммы исчисляется минутами (будем считать, что оно порядка 2 мин) получаем скорость передачи — 546 дейтаграмм в секунду. При максимальном размере дейтаграммы, равном 64 Кбайт, имеем общую скорость около 300 Мбит/с.

Проблема эффективного использования битов идентификатора оказалась практически разрешенной с появлением метода MTU Discovery, позволяющего определить значения MTU на всем пути к пункту назначения. Согласно этому методу конечная система может устанавливать в заголовке IP-дейтаграммы бит DF (Don't Fragment — не фрагментировать), запрещающий фрагментацию, ведь конечные системы могут заранее узнать о том, что отправляемые ими дейтаграм­мы имеют чрезмерную длину. Источник IP-трафика, устанавливающий бит DF теперь может не опасаться того, что две дейтаграммы перепутаются. Однако в сетевой среде, где технология MTU Discovery не применяется (в ней бит DF не несет функциональной нагрузки), необходимо предпринимать дополнительные меры для предотвращения подобной ситуации.

На рис. 6.3 показана процедура фрагментации и сборки дейтаграммы.

Рассмотрим пример фрагментации. Предположим, отправителю необходимо передать сообщение длиной 5600 байт. Отправитель работает в сети, у которой значение MTU составляет 4096 байт. При поступлении пакета на сетевой уро­вень, протокол IP делит его на две равные дейтаграммы по 2800 байт, устанав­ливая в первой дейтаграмме признак фрагментации (см. ниже) и присваивая пакету уникальный идентификатор. Бит фрагментации во второй дейтаграмме равен нулю, что указывает на последний фрагмент сообщения. Таким образом, дейтаграммы укладываются в кадр физического уровня данной сети (2800 байт данных + 20 байт заголовка меньше 4096 байт).

После маршрутизатора дейтаграммы необходимо передать в сеть с MTU, рав­ным 1500 байт. Для этого маршрутизатор делит поступающие дейтаграммы по­полам. Он формирует новые дейтаграммы, каждая из которых имеет размер 1400+20 байт, чтобы уложиться в MTU второй сети. Необходимо отметить, что маршрутизатор не собирает фрагменты в более крупные дейтаграммы, даже если на пути встречается сеть, допускающая такое укрупнение.

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

Поля «Идентификатор», «Флаги» и «Смещение фрагмента» (см. ниже) управляют фрагментацией и сборкой дейтаграммы.

Рассмотрим еще один пример фрагментации дейтаграммы. На этот раз мы будем внимательно следить за заголовком с приведением конкретных значений полей заголовка дейтаграммы протокола дейтаграммы. На рис. 6.4 показан ис­ходный заголовок дейтаграммы. Пусть MTU будет равно 280 байт. Допустим, что общая длина передаваемой дейтаграммы составляет 472 байта.

Рис. 6.4. Заголовок дейтаграммы до фрагментации

На рис. 6.5 показаны поля заголовков двух полученных в результате фраг­ментации дейтаграмм. Получающиеся дейтаграммы имеют максимальный раз­мер поля данных, равный 256 байт.

q Поле «Флаги»используется при фрагментации. Нулевой первый бит разре­шает фрагментацию, единичный — запрещает. Единичный второй бит указывает на последний фрагмент дейтаграммы.

q Поле «Смещение фрагмента»используется для указания смещения данных во фрагменте относительно начала исходной дейтаграммы. Чтобы получить сме­щение в байтах, надо значение этого поля умножить на 8. Первый фрагмент всегда имеет нулевое смещение. Поле используется при сборке фрагментов дей­таграммы после передачи по сетям с различными MTU.

q Поле «Протокол» показывает, какому протоколу верхнего уровня принадле­жит дейтаграмма. При поступлении дейтаграммы это поле указывает, какому приложению следует ее передать. В табл. 6.2 содержится перечень (неполный) протоколов.