Текст книги "Операционная система UNIX"

Автор книги: Андрей Робачевский

сообщить о нарушении

Текущая страница: 31 (всего у книги 39 страниц)

Краткая история TCP/IP

История создания и развития протоколов TCP/IP неразрывно связана с Internet – интереснейшим достижением мирового сообщества в области коммуникационных технологий. Internet является глобальным объединением разнородных компьютерных сетей, использующих протоколы TCP/IP и имеющих общее адресное пространство. Явление Internet уникально еще и потому, что эта глобальная сеть построена на принципах самоуправления (хотя ситуация отчасти начинает меняться). Однако вернемся к истории.

Сегодняшняя сеть Internet "родилась" в 1969 году, когда агентство DARPA получило заказ на разработку сети, получившей название ARPANET. Целью создания этой сети было определение возможностей использования коммуникационной технологии пакетной коммутации. В свою очередь, агентство DARPA заключило контракт с фирмой Bolt, Beranek and Newman (BBN). В сентябре 1969 года произошел запуск сети, соединивший четыре узла: Станфордский исследовательский институт (Stanford Research Institute), Калифорнийский университет в Санта-Барбаре (University of California at Santa Barbara), Калифорнийский университет в Лос-Анжелесе (University of California at Los Angeles) и Университет Юты (University of Utah). Роль коммуникационных узлов выполняли мини-компьютеры Honeywell 316, известные как Interface Message Processor (IMP).

Запуск и работа сети были успешными, что определило быстрый рост ARPANET. В то же время использованием сети в своих целях заинтересовались исследователи, далекие от военных кругов. Стали поступать многочисленные запросы от руководителей университетов США в Национальный научный фонд (National Science Foundation, NSF) с предложениями создания научно-образовательной компьютерной сети. В результате в 1981 году NSF одобрил и финансировал создание сети CSNET (Computer Science Network).

В 1984 году ARPANET разделилась на две различные сети: MILNET, предназначенную исключительно для военных приложений, и ARPANET для использования в "мирных" целях.

В 1986 году фонд NSF финансировал создание опорной сети, соединившей каналами с пропускной способностью 56 Кбит/с шесть суперкомпьютерных центров США. Сеть получила название NSFNET и просуществовала до 1995 года, являясь основной магистралью Internet. За это время пропускная способность опорной сети возросла до 45 Мбит/с, а число пользователей превысило 4 миллиона.[66]66
  Общее число пользователей Internet на начало 1995 года составило 4852000, из них в США – более 3 миллионов. Уже к середине 1996 года сеть Internet имела следующие показатели: почти 13 миллионов хостов, 134 365 сетей, почти полмиллиона зарегистрированных доменов. На начало 1997 года население Internet по сведениям компании Network Wizards (http://www.nw.com) составляло 16 146 000 хостов (число записей в системе DNS), расположенных в 828 000 доменах. Правда, на запрос «откликнулось» в среднем около 3 миллионов хостов.


[Закрыть]

Стремительное развитие NSFNET сделало бессмысленным дальнейшее существование ARPANET. В июне 1990 года Министерство обороны США приняло решение о прекращении работы сети. Однако уроки, полученные в процессе создания и эксплуатации ARPANET, оказали существенное влияние на развитие коммуникационных технологий, таких как локальные сети и сети пакетной коммутации.

При создании ARPANET был разработан и протокол сетевого взаимодействия коммуникационных узлов. Он получил название Network Control Program (NCP). Однако этот протокол строился на предположении, что сетевая среда взаимодействия является абсолютно надежной. Учитывая специфику ARPANET, такое предположение являлось, мягко говоря, маловероятным: качество коммуникационных каналов могло существенно изменяться в худшую сторону (особенно при предполагаемом использовании радио– и спутниковой связи), а отдельные сегменты сети могли быть разрушены.[67]67
  Принимая во внимание существовавшие в то время отношения между СССР и США, приходится констатировать, что такое вполне могло произойти. Сегодня предположение о надежности сети также не всегда справедливо, только роль бомб и ракет исполняют ковши экскаваторов.


[Закрыть] Таким образом, подход к коммуникационной среде нуждался в пересмотре, и, как следствие, возникла необходимость разработки новых протоколов. Еще одной задачей, стоявшей перед разработчиками, являлось обеспечение согласованной работы связанных сетей (internet), использующих различные коммуникационные технологии (например, пакетное радио, спутниковые сети и локальные сети). Результатом исследований в этой области явилось рождение нового семейства протоколов – Internet Protocol (IP), с помощью которого осуществлялась базовая доставка данных в гетерогенной коммуникационной среде, и Transmission Control Protocol (TCP), который обеспечивал надежную передачу данных между пользователями в ненадежной сетевой инфраструктуре. Спецификации этих протоколов в 1973 году получили статус стандартов Министерства обороны MIL-STD-1777 и MIL-STD-1778 соответственно.

Архитектура TCP/IP

Архитектура семейства протоколов TCP/IP основана на представлении, что коммуникационная инфраструктура включает три объекта: процессы, хосты, и сети. Процессы являются основными коммуникационными объектами, поскольку между процессами, в конечном итоге, осуществляется передача информации. Выполнение процессов происходит на различных хостах (или компьютерах). Передача информации между процессами проходит через сети, к которым подключены хосты.

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

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

□ Уровень приложений/процессов (Application/process layer)

□ Транспортный уровень (Host-to-host layer)

□ Уровень Internet (Internet layer)

□ Уровень сетевого интерфейса (Network interface layer)

Уровень сетевого интерфейса составляют протоколы, обеспечивающие доступ к физической сети. С помощью этих протоколов осуществляется передача данных между коммуникационными узлами, подключенными к одному и тому же сетевому сегменту (например, сегменту Ethernet или каналу точка-точка). Протоколы этого уровня должны поддерживаться всеми активными устройствами, подключенными к сети (например, мостами). К этому уровню относятся протоколы Ethernet, IEEE802.X, SLIP, PPP и т.д. Протоколы уровня сетевого интерфейса формально не являются частью семейства TCP/IP, однако стандарты Internet определяют, каким образом должна осуществляться передача данных TCP/IP с использованием вышеперечисленных протоколов.

Уровень Internet составляют протоколы, обеспечивающие передачу данных между хостами, подключенными к различным сетям. Одной из функций, которая должна быть реализована протоколами этого уровня, является выбор маршрута следования данных, или маршрутизация. Сетевые элементы, осуществляющие передачу данных из одной сети в другую, получили название шлюзов (gateway).[68]68
  Более точным названием этих устройств является «маршрутизатор» (router). С формальной точки зрения термин «шлюз», применительно к данным устройствам, не совсем верен. Модель OSI определяет шлюз, как устройство, которое может осуществлять функции передачи на всех семи уровнях (подробнее о модели OSI будет рассказано в следующем разделе). Однако в мире UNIX маршрутизаторы почему-то называют шлюзами, и мы будем придерживаться этой терминологии.


[Закрыть] Шлюз имеет несколько сетевых интерфейсов, подключенных к различным физическим сетям, и его основной задачей является выбор маршрута передачи данных из одного сетевого интерфейса в другой. Основной представитель уровня Internet – протокол IP.

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

Наконец, протоколы уровня приложений обеспечивают функционирование прикладных услуг, таких как удаленный терминальный доступ, копирование удаленных файлов, передача почтовых сообщений и т.д. Работу этих приложений обеспечивают протоколы Telnet, File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP) и т.д.

На рис. 6.1 показана иерархическая четырехуровневая модель семейства протоколов TCP/IP. Заметим, что протоколы уровня сетевого интерфейса, фактически не являются частью семейства, поскольку не определены ни стандартами Министерства обороны США, ни стандартами Internet. Вместо этого используются существующие протоколы сети и определяются методы передачи трафика TCP/IP с помощью данной коммуникационной технологии. Например, RFC894 (A Standard for the Transmission of IP Datagrams over Ethernet Networks) определяет формат и процедуру передачи IP-пакетов в сетях Ethernet, a RFC 1577 (Classical IP and ARP over ATM) – в сетях ATM.

Рис. 6.1. Архитектура протоколов TCP/IP

На рис. 6.2 показана базовая коммуникационная схема протоколов TCP/IP. Коммуникационная инфраструктура может состоять из нескольких физических сетей. Для передачи данных в физической сети между подключенными хостами используется некоторый протокол уровня сетевого интерфейса, определенный для данной технологии передачи данных (Ethernet, FDDI, ATM и т.д.). Отдельные сети связаны между собой шлюзами, – устройствами, подключенными одновременно к нескольким сетям и служащими для передачи пакетов данных из одного интерфейса в другой. Выполнение этой функции обеспечивается протоколом IP. Как видно из рисунка, протокол IP выполняется на хостах и шлюзах и в конечном итоге обеспечивает доставку данных от хоста-отправителя к хосту– получателю. За обмен данными между процессами отвечают протоколы транспортного уровня – TCP или UDP. Поскольку работа транспортных протоколов обеспечивает передачу данных между удаленными процессами, протоколы этого уровня должны быть реализованы на хостах. При этом шлюзов для TCP или UDP как бы не существует, поскольку их присутствие и работу полностью скрывает протокол IP. Наконец, процессы также используют некоторый протокол для обмена данными, например Telnet или FTP.

Рис. 6.2. Коммуникационная схема TCP/IP

Для правильного обмена данными каждый коммуникационный узел должен иметь уникальный адрес. На самом деле, как правило, существует несколько уровней адресации. Например, в локальной сети, каждый сетевой интерфейс (первый уровень модели) имеет т.н. MAC-адрес. С помощью этого адреса обеспечивается доставка данных требуемому получателю в физической сети. Для доставки данных IP необходимо адресовать хост-получатель. Для этого используется т.н. IP– или Internet-адрес. Наконец, хост, получивший данные, должен доставить их требуемому процессу. Таким образом, каждый процесс хоста, участвующий в коммуникационном взаимодействии также имеет адрес. Этот адрес получил название номера порта.

Таким образом, для того чтобы однозначно адресовать принимающую сторону, отправитель данных должен указать адреса хоста (IP-адрес) и процесса на этом хосте (номер порта). Он также должен указать, какой протокол транспортного уровня будет использован при обмене данными (номер протокола). Поскольку путь данных может проходить по нескольким физическим сегментам, физический адрес, или MAC-адрес, сетевого интерфейса не имеет смысла и определяется автоматически на каждом этапе пересылки (hop) между шлюзами.

Попробуем вкратце рассмотреть процесс передачи данных от процесса 2000 (номер порта), выполняющегося на хосте А, к процессу 23, выполняющемуся на хосте В. Согласно рис. 6.2 хосты расположены в разных физических сегментах, соединенных шлюзом X. Для этого процесс 2000 передает некоторые данные модулю протокола TCP (допустим, что приложение использует этот транспортный протокол), указывая, что данные необходимо передать процессу 23 хоста В. Модуль TCP, в свою очередь, передает данные модулю IP, указывая при только адрес хоста В. Модуль IP выбирает маршрут и соответствующий ему сетевой интерфейс (если их несколько) и передает последнему данные, указывая шлюз X в качестве промежуточного получателя.

Можно заметить, что наряду с передачей данных, каждый уровень обработки передает последующему некоторую управляющую информацию (IP-адрес, номер порта и т.д.). Эта информация необходима для правильной доставки данных адресату. Поэтому каждый протокол формирует пакет (Protocol Data Unit, PDU), состоящий из данных, переданных модулем верхнего уровня, и заголовка, содержащего управляющую информацию. Эта управляющая информация распознается модулем того же уровня (peer module) удаленного узла и используется для правильной обработки данных и передачи их соответствующему протоколу верхнего уровня.

На рис. 6.3 схематически показан процесс обработки данных при их передаче между хостами сети с использованием протоколов TCP/IP. С точки зрения процессов 23 и 2000 между ними существует коммуникационный канал, обеспечивающий надежную и достоверную передачу потока данных, внутреннюю структуру которого определяют сами процессы по предварительной договоренности (например, в соответствии с протоколом Telnet). Модуль TCP хоста А обменивается сегментами данных с парным ему модулем TCP хоста В, не задумываясь о топологии сети или физических интерфейсах. Задача модулей TCP заключается в обеспечении достоверной и последовательной передачи данных между модулями приложений (процессов). TCP не интерпретирует прикладные данные и ему безразлично, передается ли в сегменте фрагмент почтового сообщения, файл или регистрационное имя пользователя. В свою очередь модуль IP хоста А передает данные, полученные от транспортных протоколов, модулю IP хоста В, не заботясь о надежности и последовательности передачи. Он не интерпретирует данные TCP, поскольку его задача – правильно адресовать отправляемую датаграмму. Поэтому модулю IP все равно, передает ли он данные TCP или UDP, управляющие сегменты или инкапсулированные прикладные данные.

Рис. 6.3. Обработка данных в соответствии с протоколами TCP/IP

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

Общая модель сетевого взаимодействия OSI

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

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

Такая общая модель была принята в 1983 году Международной организацией по стандартизации (International Organization for Standardization, ISO), и получила название модели взаимодействия открытых систем (Open Systems Interconnection, OSI). Эта модель является основой для объединения разнородных компьютеров в гетерогенную сетевую инфраструктуру. Данная архитектура определяет возможность установления соединения между любыми двумя системами, удовлетворяющими модели и поддерживающими соответствующие стандарты.

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

Модель OSI состоит из семи уровней, краткое описание которых приведено в табл. 6.1.

Таблица 6.1. Семь уровней модели OSI

Уровень приложений (Application layer)	Обеспечивает пользовательский интерфейс доступа к распределенным ресурсам
Уровень представления (Presentation layer)	Обеспечивает независимость приложений от различий в способах представления данных
Уровень сеанса (Session layer)	Обеспечивает взаимодействие прикладных программ в сети
Транспортный уровень (Transport layer)	Обеспечивает прозрачную передачу данных между конечными точками сетевых коммуникаций. Отвечает за восстановление ошибок и контроль за потоком данных
Сетевой уровень (Network layer)	Обеспечивает независимость верхних уровней от конкретной реализации способа передачи данных по физической среде. Отвечает за установление, поддержку и завершение сетевого соединения
Уровень канала данных (Data link layer)	Обеспечивает надежную передачу данных по физической сети. Отвечает за передачу пакетов данных – кадров и обеспечивает необходимую синхронизацию, обработку ошибок и управление потоком данных
Физический уровень (Physical layer)	Отвечает за передачу неструктурированного потока данных по физической среде. Определяет физические характеристики среды передачи данных

Рассмотрим процесс передачи данных между удаленными системами в рамках модели OSI. Пусть пользователю А системы C1 необходимо передать данные приложению В системы C2. Обработка прикладных данных начинается на уровне приложения. Уровень приложения передает обработанные данные и управляющую информацию на следующий уровень – уровень представления и т.д., пока данные наконец не достигнут физического уровня и не будут переданы по физической сети. Система C2 принимает эти данные и обрабатывает их в обратном порядке, начиная с физического уровня и заканчивая уровнем приложения, после чего исходные прикладные данные будут получены пользователем В.

Для того чтобы каждый уровень мог правильно обработать полученные данные, последние содержат также управляющую информацию. Эта управляющая информация интерпретируется только тем уровнем, для которого она предназначена, в соответствии с его протоколом, и невидима для других уровней: для верхних, потому что после обработки она удаляется, а для нижних – потому, что представляется им как обычные данные. Благодаря этому каждый уровень по существу общается с расположенным на удаленной системе равным (peer) ему уровнем. Таким образом, взаимодействие между удаленными системами можно представить состоящим из нескольких логических каналов, соответствующих уровням модели, передача данных в каждом из которых определяется протоколом своего уровня.

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

Нетрудно заметить, что модель TCP/IP отличается от модели OSI. На рис. 6.4 показана схема отображения архитектуры TCP/IP на модель OSI. Видно, что соответствие существует для уровня Internet (сетевой уровень) и транспортного уровня. Уровни сеанса, представления и приложений OSI в TCP/IP представлены одним уровнем приложений. Обсуждение соответствия двух моделей носит весьма теоретический характер, поэтому мы перейдем к более ценному для практики обсуждению прекрасно зарекомендовавших себя протоколов Internet.

Рис. 6.4. Соответствие между моделями TCP/IF и OSI

Протокол IP

Межсетевой протокол (Internet Protocol, IP) обеспечивает доставку фрагмента данных (датаграммы) от источника к получателю через систему связанных между собой сетей. В протоколе IP отсутствуют функции подтверждения, контроля передачи, сохранения последовательности передаваемых датаграмм и т.д. В этом смысле протокол IP обеспечивает потенциально ненадежную передачу. Надежность и прочие функции, отсутствующие у IP, при необходимости реализуются протоколами верхнего уровня. Например, протокол TCP дополняет IP функциями подтверждения и управления передачей, позволяя приложениям (или протоколам более высокого уровня) рассчитывать на получение упорядоченного потока данных, свободных от ошибок. Эта функциональность может быть реализована и протоколами более высокого уровня, как например это сделано в реализации распределенной файловой системы NFS, традиционно работающей на базе «ненадежного» транспортного протокола UDP. При этом работа NFS в целом является надежной.

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

Данные, формат которых понятен протоколу IP, носят название датаграммы (datagram), вид которой приведен на рис. 6.5. Датаграмма состоит из заголовка, содержащего необходимую управляющую информацию для модуля IP, и данных, которые передаются от протоколов верхних уровней и формат которых неизвестен IP. Вообще говоря, термин «датаграмма» обычно используется для описания пакета данных, передаваемого по сети без установления предварительной связи (connectionless).

Рис. 6.5. IP-датаграмма

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

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

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

Заголовок IP-датаграммы, позволяющий модулю протокола выполнить необходимую обработку данных, приведен на рис. 6.6.

Рис. 6.6. Заголовок IP-датаграммы

Заголовок занимает как минимум 20 октетов управляющих данных. Поле Version определяет версию протокола и ее значение равно 4 (для IPv4). Поле IHL (Internet Header Length) указывает длину заголовка в 32-битных словах. При минимальной длине заголовка в 20 октетов значение IHL будет равно 5. Это поле также используется для определения смещения, начиная с которого размещаются управляющие данные протоколов верхнего уровня (например, заголовок TCP). Поле Type of Service определяет требуемые характеристики обработки датаграммы и может принимать следующие значения:

Биты 0–2	Precedence. Относительная значимость датаграммы. Это поле может использоваться рядом сетей, при этом большее значение поля Precedence соответствует более приоритетному трафику (например, при перегрузке сети модуль передает только трафик со значением Precedence выше определенного порогового значения).
Бит 3	Delay. Задержка. Значение 0 соответствует нормальной задержке при обработке, значение 1 – низкому значению задержки.
Бит 4	Throughput. Скорость передачи. Значение 0 соответствует нормальной скорости передачи, значение 1 – высокой скорости.
Бит 5	Reliability. Надежность. Значение 0 соответствует нормальной надежности, значение 1 – высокой надежности.
Биты 6–7	Зарезервированы для последующего использования.

Поле Type of Service определяет обработку датаграммы при передаче через различные сети от источника к получателю. В большинстве случаев может оказаться невозможным удовлетворение сразу всех требований по обработке, предусмотренных полем Type of Service. Например, удовлетворение требования низкого значения задержки, может сделать невозможным повышение надежности передачи. Фактическое отображение параметров Type of Service на процедуры обработки конкретной сети зависит от архитектуры этой сети. Примеры возможных отображений можно найти в RFC 795 «Service mappings».

Поле Total Length содержит общий размер датаграммы в октетах. Размер поля (16 бит) ограничивает максимальный размер IP-датаграммы 65535 октетами.

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

Поле Flags содержит следующие флаги:

Бит 0	Зарезервирован
Бит 1	DF. Значение 0 позволяет фрагментировать датаграмму. Значение 1 запрещает фрагментацию. Если в последнем случае передача исходной датаграммы невозможна, модуль протокола просто уничтожает исходную датаграмму без уведомления
Бит 2	MF. Значение 0 указывает, что данный фрагмент является последним в исходной датаграмме (в исходной датаграмме значение равно 0). Значение 1 сообщает реассемблирующему модулю о том, что данный фрагмент исходной датаграммы не последний

Для фрагментации датаграммы большого размера модуль протокола формирует две или более новых датаграмм и копирует содержимое заголовка исходной датаграммы в заголовки вновь созданных. Флаг MF устанавливается равным 1 для всех датаграмм, кроме последней, для которой значение этого флага копируется из исходной датаграммы. Данные разбиваются на необходимое число частей с сохранением 64-битной границы. Соответствующим образом устанавливаются значения полей Total Length и Fragment Offset.

Получатель фрагментов, например хост, производит реассемблирование, объединяя датаграммы с равными значениями четырех полей: Identification, адрес источника (Source Address), адрес получателя (Destination Address) и Protocol. При этом положение фрагмента в объединенной датаграмме определяется полем Fragment Offset.

Следующее поле заголовка называется TTL (Time-to-Live) и определяет «время жизни» датаграммы в сети. Если значение этого поля становится равным 0, датаграмма уничтожается. Каждый модуль протокола, обрабатывающий датаграмму, уменьшает значение этого поля на число секунд, затраченных на обработку. Однако поскольку обработка датаграммы в большинстве случаев занимает гораздо меньшее время, a TTL все равно уменьшается на 1, то фактически это поле определяет максимальное количество хопов (число промежуточных передач через шлюзы), которое датаграмма может совершить. Смысл этой функции – исключить возможность засорения сети «заблудившимися»

Поле Protocol определяет номер протокола верхнего уровня, которому предназначена датаграмма. Значения этого поля для различных протоколов приведены в RFC 1700 «Assigned numbers», некоторые из них показаны в табл. 6.2.

Таблица 6.2. Некоторые номера протоколов

1	Internet Control Message Protocol, ICMP
2	Internet Group Management Protocol, IGMP
4	Инкапсуляция IP в IP
6	Transmission Control Protocol, TCP
17	User Datagram Protocol, UDP
46	Resource Reservation Protocol, RSVP
75	Packet Video Protocol, PVP

Завершает третье 32-битное слово заголовка его 16-битная контрольная сумма/поле Header Checksum.

Поля Source Address и Destination Address содержат соответственно адреса источника датаграммы и ее получателя. Это адреса сетевого уровня, или IP-адреса, размер которых составляет 32 бита каждый.

Поле Options содержит различные опции протокола, а поле Padding служит для выравнивания заголовка до границы 32-битного слова.