Мы уже рассмотрели части сетевого оборудования и программного обеспечения, которые делают возможным межсетевое взаимодействие, объяснили базовые сетевые технологии и разрешение адресов. Эта глава рассматривает фундаментальный принцип доставки без установления соединения и обсуждает, как он реализуется с помощью Межсетевого протокола(IP), одного из двух основных протоколов, используемых при межсетевом обмене. Мы изучим формат дейтаграмм IP и увидим, как они образуют основу для всех видов межсетевого взаимодействия. Следующие две главы продолжат изучение Межсетевого Протокола, обсуждая вопросы маршрутизации дейтаграмм и обработки ошибок.
Глава 3 рассмотрела межсетевую архитектуру, в которой машины-шлюзы соединяют группу физических сетей. Знание архитектуры может ввести в заблуждение, так как внимание следует сосредоточить на интерфейсе, который предоставляет интернет пользователям, а не на технологии взаимного соединения.
Пользователь представляет себе интернет в виде одной виртуальной сети, соединяющей все ГВМ, с помощью которой и делается возможным взаимодействие; его настоящая архитектура является невидимой и ненужной.
По существу интернет является абстракцией физической сети, так как, на самом нижнем уровне, он обеспечивает те же самые возможности: прием пакетов и доставка их. Более высокие уровни межсетевого программного обеспечения добавляют большую часть богатых возможностей, доступным пользователям.
На концептуальном уровне интернет TCP/IP обеспечивает три множества средств, как показано на рисунке 7.1; их расположение на рисунке предполагает зависимости между ними. На самом нижнем уровне, средство доставки без установления соединения обеспечивает основу для всего остального. На следующем уровне надежное транспортное средство обеспечивает платформу более высокого уровня, от которую опираются приложения. Мы вскоре освоим каждое из этих трех средств, поймем, что они обеспечивают, и увидим, какие протоколы связаны с ними.
--------------------------------------------
| ПРИКЛАДНЫЕ СРЕДСТВА |
--------------------------------------------------
| НАДЕЖНОЕ ТРАНСПОРТНОЕ СРЕДСТВО |
--------------------------------------------------------
| СРЕДСТВО ДОСТАВКИ ПАКЕТОВ БЕЗ УСТАНОВЛЕНИЯ СОЕДИНЕНИЯ|
--------------------------------------------------------
Хотя мы можем связать протокольное программное обеспечение с каждым из средств на рисунке 7.1, причина выделения их как концептуальных частей интернета состоит в том, что они ясно указывают на философские предпосылки при разработке. Главное заключается в том, что:
Программное обеспечение Интернета разработано на основе трех концептуальных сетевых средств, расположенных в иерархическом порядке; основная причина их успеха состоит в том, что эта архитектура является очень надежной и адаптируемой.
Одним из самых значительных преимуществ такого концептуального разделения является то, что становится возможным заменить одно средство, не влияя при этом на работу других. Поэтому, можно организовать параллельные исследование и разработку всех трех средств.
Самое фундаментальное межсетевое средство представляет собой систему доставки пакетов. Технически это средство определено как ненадежная система доставки пакетов без установления соединения, аналогично средству, обеспечиваемому сетевым оборудованием, которое работает по принципу негарантированной доставки. Это средство называется ненадежным, так как доставка не гарантируется. Пакеты могут быть потеряны, дублированы, задержаны или доставлены не по порядку, но средство не обнаружит такие ситуации, а также не сможет сообщить о них отправителю или получателю. Это средство называется "без установления соединения", так как каждый пакет обрабатывается независимо от других пакетов. Последовательность пакетов, посылаемая от одной машины к другой, может передаваться по различным путям, а некоторые из них могут быть даже потеряны, в то время, как остальные будут доставлены. Наконец, можно сказать, что средство использует доставку в лучшем случае (best-effort delivery), так как межсетевое программное обеспечение делает настоящую попытку доставить пакет. То есть, интернет не удаляет пакеты по своему желанию; ненадежность возникает только тогда, когда не хватает ресурсов, или происходят сбои в используемых физических сетях.
Протокол, который определяет ненадежной доставки без установления соединения, называется Межсетевым Протоколом, и обычно обозначается своими инициалами, IP(аббревиатура IP привела к появлению термина IP-адрес). IP обеспечивает определение трех важных вещей. Во-первых, протокол IP определяет базовый элемент передачи данных, используемый во всем интернете TCP/IP. Во-вторых, программное обеспечение IP выполняет функцию маршрутизации, выбора пути, по которому будут передаваться данные. В-третьих, помимо точной, формальной спецификации форматов данных и функции маршрутизации, IP включает набор правил, которые воплощают в жизнь идею ненадежной доставки пакетов. Эти правила указывают, как ГВМ и шлюзам следует обрабатывать пакеты, как и когда следует генерировать сообщения об ошибках, и условия, при которых можно удалять пакеты. IP является такой фундаментальной частью, что интернет TCP/IP иногда называют технологией на основе IP.
Мы начинаем рассмотрение IP в этой главе с обзора формата пакета, описанного в нем. Маршрутизацию и обработку ошибок мы рассмотрим в следующих главах.
Между физической сетью и интернетом TCP/IP существует много аналогий. В физической сети единицей передачи является кадр, который состоит из заголовка и данных, где заголовок содержит информацию, такую как адреса отправителя и получателя. Интернет называет свой базовый элемент передачи межсетевой дейтаграммой(иногда ее называют IP-дейтаграммой или просто дейтаграммой). Как и кадр физической сети, дейтаграмма делится на поле заголовка и поле данных. Кроме того, как и кадр, заголовок дейтаграммы содержит адреса отправителя и получателя, а также поле типа, которое идентифицирует содержимое дейтаграммы. Ну, и конечно, разница между ними состоит в том, что заголовок дейтаграммы содержит IP-адреса, в то время как заголовок кадра - физические адреса. Рисунок 7.2 показывает общую форму дейтаграммы:
----------------------------------------------------------- | ЗАГОЛОВОК | ОБЛАСТЬ ДАННЫХ | | ДЕЙТАГРАММЫ | ДЕЙТАГРАММЫ | -----------------------------------------------------------
Теперь, после того, как мы описали общий формат IP-дейтаграммы, можно рассмотреть ее содержимое более детально. Рисунок 7.3 показывает расположение полей дейтаграммы:
0 4 8 16 19 24 31 ------------------------------------------------------------ |версия|длина| тип сервиса| общая длина | ------------------------------------------------------------ | идентификация |флаги |смещение фрагмента | ------------------------------------------------------------ |время жизни | протокол | КС заголовка | ------------------------------------------------------------ | IP-адрес отправителя | ------------------------------------------------------------ | IP-адрес получателя | ------------------------------------------------------------ | Опции IP(если есть) |заполнение | ------------------------------------------------------------ | Данные | ------------------------------------------------------------ | ... | ------------------------------------------------------------
Так как обработка дейтаграммы происходит с помощью программного обеспечения, оборудование не накладывает никаких ограничений на ее содержимое и формат. Например, первое 4-битовое поле в дейтаграмме(ВЕРСИЯ) содержит версию протокола IP , используемую при создании дейтаграммы. Оно используется отправителем, получателем, и всеми шлюзами между ними для уверенности в том, что все они используют один и тот же формат дейтаграммы. Всему программному обеспечению IP требуется проверять поле версии перед обработкой дейтаграммы, чтобы быть уверенным в том, что ее формат соответствует тому формату, который ожидает это обеспечение. Если стандарт меняется, машины будут отбрасывать дейтаграммы с версией протокола, отличающейся от версии, на которой они работают, предохраняя себя от неправильной интерпретации содержимого дейтаграммы из-за устаревшего формата. Текущая версия протокола IP - 4.
Поле длины заголовка(ДЛИНА) также занимает 4 бита и хранит длину заголовка дейтаграммы в 32-битных словах. Как мы увидим, все поля в заголовке имеют фиксированную длину, за исключением поля ОПЦИИ IP и соответствующего ему поля ЗАПОЛНЕНИЕ. Наиболее простой заголовок, без опций и заполнения, занимает 20 октетов и имеет в поле длины заголовка значение 5.
Поле ОБЩАЯ ДЛИНА дает длину IP-дейтаграммы, измеренную в октетах, включая октеты в заголовке и данных. Размер области данных может быть вычислен с помощью вычитания длины заголовка(ДЛИНА) из ОБЩЕЙ ДЛИНЫ. Так как поле ОБЩАЯ ДЛИНА занимает 16 бит, максимально возможный размер дейтаграммы IP - 65535 октетов. В большинстве приложений это ограничение несущественно. Но оно может стать важным в будущем, когда сети с более высокими скоростями смогут передавать пакеты данных длиннее чем 65535 октетов.
8-битовое поле ТИП СЕРВИСА указывает, как следует обрабатывать дейтаграмму, и разделено на пять подполей, как показано на рисунке 7.4:
0 1 2 3 4 5 6 7 ------------------------------------------------------------- | приоритет | D | T | R | не используется | -------------------------------------------------------------
Три бита ПРИОРИТЕТА указывают приоритет дейтаграммы, значения которого могут меняться от 0(обычный приоритет) до 7(управление сетью), позволяя отправителям передавать информацию о важности каждой дейтаграммы. Хотя программное обеспечение большинства ГВМ и шлюзов игнорирует тип сервиса, он является важным понятием, так как обеспечивает механизм, который впоследствии позволит управляющей информации иметь больший приоритет, чем данные. Например, если все ГВМ и шлюзы будут учитывать приоритет, станет возможной реализация алгоритмов управления перегрузкой сети, на которые не будет влиять перегрузка, которой они пытаются управлять.
Биты D, T и R описывают тип передачи, который нужен дейтаграмме. Установка бита D запрашивает минимальные задержки при передаче, бита T - максимальную пропускную способность, а бита R - максимальную надежность. Конечно, интернет не может гарантировать выполнение запрошенного сервиса(например, может быть так, что нет пути к назначению с запрошенными качествами). Поэтому, мы будем рассматривать запрос сервиса как указание алгоритмам маршрутизации, а не как требование. Если шлюз знает более чем один маршрут к указанному назначению, он может использовать поле типа транспорта для выбора пути с характеристиками наиболее близкими требуемым. Например, предположим, что шлюз может выбирать между низкоскоростной арендованной линией или высокоскоростной(но с большими паузами) спутниковой линией. Дейтаграммы, передающие нажатия клавиш от пользователя к удаленному компьютеру, могут иметь установленным бит D, запрашивая таким образом самую быструю доставку, в то время как дейтаграммы, используемые при передаче большого файла, могут иметь установленным бит T, запрашивая передачу по высокоскоростной спутниковой линии.
Важно понимать, что алгоритмы маршрутизации должны выбирать из используемых физических сетевых технологий , которые имеют определенные характеристики задержки, пропускной способности и надежности. Часто данная технология использует компромисс между этими характеристиками(например, высокой скоростью передачи и большей задержкой). Поэтому, идея состоит в том, чтобы дать алгоритму указание о том, что наиболее важно; не имеет смысла указывать все три типа сервиса. Подведем итоги:
Мы рассматриваем спецификацию типа передачи как указание алгоритму маршрутизации, которое помогает выбрать один путь к назначению из группы на основе знаний об аппаратных технологиях, использующихся на этих путях. Интернет не гарантирует выполнения запрошенного транспортного сервиса.
Перед тем, как мы сможем понять следующие поля дейтаграммы, нам нужно рассмотреть, как дейтаграммы соотносятся с кадрами физической сети. Мы начнем с вопроса: "Каков максимальный размер дейтаграммы ?" В отличие от кадров физической сети, которые должны распознаваться оборудованием, дейтаграммы обрабатываются программным обеспечением. Они могут иметь любую длину, какую выберут разработчики протокола. Мы видели, что текущий формат дейтаграммы выделяет 16 бит под поле общей длины, ограничивая дейтаграмму 65535 октетами. Тем не менее, этот предел может быть изменен в следующих версиях протокола.
Более фундаментальные ограничения на размер дейтаграммы накладываются практикой работы. Мы знаем, что по мере того, как дейтаграммы передаются от одной машины к другой, они всегда должны транспортироваться базовыми физическими сетями. Для эффективности межсетевой передачи нам нужно быть уверенным в том, что каждая дейтаграмма передается в отдельном физическом кадре. То есть, мы хотим, чтобы наша абстракция пакета физической сети напрямую соответствовала реальному пакету, если это возможно. Идея передачи одной дейтаграммы в одном сетевом кадре называется инкапсуляцией. Для базовой сети дейтаграмма выглядит так же, как и любое другое сообщение, посылаемое от одной машины к другой. Оборудование как не знает формата дейтаграммы, так и не понимает IP-адреса назначения. Поэтому, как показывает рисунок 7.5, когда одна машина посылает IP-дейтаграмму другой, вся дейтаграмма передается как часть данных сетевого кадра.
-------------------------------------------------
|заголовок | область данных дейтаграммы |
|дейтаграммы | |
-------------------------------------------------
| |
V V
-----------------------------------------------------------
|заголовок| |
|кадра | область данных кадра |
-----------------------------------------------------------
В идеальном случае вся дейтаграмма IP помещается в одном физическом кадре, делая эффективной передачу по физической сети(Одно из полей в заголовке кадра идентифицирует, какие данные передаются. Ethernet использует значение типа 0800(в шестн) для указания того, что область данных содержит инкапсулированную дейтаграмму IP). Чтобы достигнуть такой эффективности, разработчики IP могли выбрать максимальный размер дейтаграммы таким, чтобы она всегда помещалась в один кадр. Но какой размер кадра следует выбрать ? Помимо всего прочего, дейтаграмма может передаваться по различным типам физических сетей по мере того, как она транспортируется по интернету к своему назначению.
Чтобы понять проблему, нам нужно знать одну вещь о сетевом оборудовании: каждая технология коммутации пакетов устанавливает фиксированную верхнюю границу количества данных, которые могут быть переданы в одном физическом кадре. Например, Ethernet ограничивает размер передачи 1500 октетами данных(ограничение в 1500 октетов взято из спецификации Ethernetа; использование заголовка SNAP со стандартом 802.3 ограничивает размер до 1492 октетов. Некоторое оборудование допускает несколько большие кадры), в то время как proNET-10 допускает кадры до 2044 октетов. Мы будем называть такие ограничения МАКСИМАЛЬНАЯ ЕДИНИЦА ПЕРЕДАЧИ(maximum transfer unit - MTU) или МЕП. Величина МЕП может быть довольно маленькой: некоторые аппаратные технологии ограничивают размер передачи до 128 октетов или даже меньше. Ограничение размера дейтаграмм до наименьшего МЕП в интернете делает передачу неэффективной, когда эти дейтаграммы передаются по сети, которая может транспортировать кадры большего размера. Тем не менее, разрешение дейтаграммам иметь размер больший, чем минимальный сетевой МЕП в интернете, означает, что дейтаграммы не всегда будут помещаться в один сетевой кадр.
Выбор понятен: ключевым моментом при разработке интернета было стремление скрыть базовые сетевые технологии и сделать взаимодействие удобным для пользователя. Поэтому, вместо разработки дейтаграмм, удовлетворяющих текущим ограничениям физических сетей, программное обеспечение TCP/IP выбирает удобный начальный размер дейтаграммы и определяет способ разделения больших дейтаграмм на маленькие части, когда дейтаграмма пересекает сеть, имеющую маленький МЕП. Маленькие части, на которые делится дейтаграмма, называются фрагментами, а процесс деления дейтаграммы - фрагментацией.
Как показывает рисунок 7.6, фрагментация обычно осуществляется шлюзом где-либо на пути между отправителем дейтаграммы и ее истинным получателем. Шлюз принимает дейтаграмму из сети с большим МЕП и должен передать ее по сети, в которой МЕП меньше, чем размер дейтаграммы.
------- -------
|ГВМ | |ГВМ |
| А | | Б |
------- -------
| |
Сеть 1| + + Сеть 3|
--------------- + + ----------------
МЕП=1500 | ----- + Сеть 2 + ----- | МЕП=1500
--|Ш1 |-- +-----|Ш2 |---
----- + МЕП=620 + -----
+ + +
+ + +
На рисунке оба ГВМ напрямую присоединения к Ethernetам, которые имеют МЕП в 1500 октетов. Поэтому оба ГВМ могут генерировать и посылать дейтаграммы до 1500 октетов длины. Путь между ними, тем не менее, включает сеть с МЕП, равным 620. Если ГВМ А посылает ГВМ Б дейтаграмму длиннее 620 октетов, шлюз Ш1 будет фрагментировать дейтаграмму. Аналогично, если Б посылает большую дейтаграмму А, шлюз Ш2 будет фрагментировать дейтаграмму. Размер фрагмента выбирается таким, чтобы каждый фрагмент мог транспортироваться в одном кадре. Кроме того, так как IP передает значение смещения данных в восьмерках октетов, размер фрагмента должен быть выбран кратным восьми. Конечно, выбор числа октетов, кратного восьми и наиболее близкого к сетевой МЕП, не обязательно делит дейтаграмму на равные части; последняя часть часто короче, чем остальные. Фрагменты должны собираться для воссоздания полной копии исходной дейтаграммы перед тем, как она будет обрабатываться у получателя.
Протокол IP как не ограничивает дейтаграммы до маленького размера, так и не гарантирует, что большие дейтаграммы будут доставлены без фрагментации. Отправитель может выбрать любой размер дейтаграммы, какой он посчитает уместным; фрагментация и сборка производятся автоматически, не требуя специальных действий от отправителя. Спецификация IP устанавливает, что шлюзы должны принимать дейтаграммы с размерами, не превосходящими МЕП сетей, к которым они присоединены. Кроме того, шлюзы должны всегда обрабатывать дейтаграммы до 576 октетов. (От ГВМ также требуется принимать и собирать при необходимости дейтаграммы не короче 576 октетов).
Фрагментация дейтаграммы означает разделение ее на несколько частей. Вы можете удивиться, когда узнаете, что каждая часть имеет точно такой же формат, как и исходная дейтаграмма. Рисунок 7.7 иллюстрирует результат фрагментации.
------------------------------------------------------------
| заголовок | данные1 \ данные2 \ данные3 |
| дейтаграммы | 600 октетов \ 600 октетов \200 октетов |
------------------------------------------------------------
(а)
------------------------------
|заголовок | данные1 | фрагмент 1(смещение 0)
|фрагмента 1 | |
------------------------------
------------------------------
|заголовок | данные2 | фрагмент 2(смещение 600)
|фрагмента 2 | |
------------------------------
-------------------------
|заголовок | данные3| фрагмент 3(смещение 1200)
|фрагмента 3 | |
-------------------------
(б)
Каждый фрагмент содержит заголовок дейтаграммы, который дублирует большую часть заголовка исходной дейтаграммы(кроме бита в поле ФЛАГИ, который показывает. что это фрагмент), и столько данных, сколько может содержать фрагмент, чтобы общая длина была меньше, чем МЕП сети, по которой он путешествует.
Стоит ли собирать дейтаграмму после прохождения одной сети, или лучше передать фрагменты к месту назначения, а уж потом собирать их ? В интернете TCP/IP как только дейтаграмма была фрагментирована, фрагменты передаются как отдельные дейтаграммы на всем протяжении пути до места назначения, где они и должны собираться. Оставление фрагментации на всем протяжении пути имеет два недостатка. Во-первых, так как дейтаграммы не собираются сразу же после прохождения сети с маленьким МЕП, маленькие фрагменты будут передаваться с места фрагментации до места назначения. Сборка дейтаграмм в месте назначения может привести к неэффективности: даже если некоторые сети, проходимые после места фрагментации, имеют большое значение МЕП, их будут пересекать только маленькие фрагменты. Во-вторых, если какой-либо фрагмент будет потерян, дейтаграмму нельзя будет восстановить. Принимающая машина запускает таймер сборки при приеме первого фрагмента. Если таймер обнуляется до того, как приняты все фрагменты, принимающая машина удаляет оставшиеся части, не обрабатывая дейтаграмму. Поэтому, вероятность потери дейтаграммы увеличивается при использовании фрагментации, так как потеря одного фрагмента приводит к потере всей дейтаграммы.
Несмотря на эти небольшие недостатки, выполнение сборки в месте назначения хорошо работает. Оно позволяет независимо маршрутизировать фрагменты и не требует от промежуточных шлюзов хранения собираемых фрагментов.
Три поля в заголовке дейтаграммы, ИДЕНТИФИКАЦИЯ, ФЛАГИ и СМЕЩЕНИЕ ФРАГМЕНТА, управляют фрагментацией и сборкой дейтаграмм. Поле ИДЕНТИФИКАЦИЯ содержит уникальное целое число, которое идентифицирует дейтаграмму. Напомним, что когда шлюз фрагментирует дейтаграмму, он копирует большую часть полей в заголовке дейтаграммы в каждый фрагмент. Поле ИДЕНТИФИКАЦИЯ должно копироваться. Его основная цель - позволить назначению узнать, что какой дейтаграмме принадлежат прибывающие фрагменты. Когда появляется фрагмент, назначение использует поле ИДЕНТИФИКАЦИЯ вместе с полем адреса источника для идентификации дейтаграммы. Компьютер, посылающий IP-дейтаграммы, должен генерировать уникальное значение для поля ИДЕНТИФИКАЦИЯ для каждой отдельной дейтаграммы(в теории, повторные передачи дейтаграммы должны содержать то же самое значение в поле ИДЕНТИФИКАЦИЯ, что и в исходной дейтаграмме; на практике, протоколы высокого уровня обычно выполняют повторную передачу как новую дейтаграмму со своей ИДЕНТИФИКАЦИЕЙ). Одна из технологий, используемых в программном обеспечении IP, хранит глобальный счетчик в памяти, инкрементирует его каждый раз, когда создается новая дейтаграмма, и копирует результат в поле ИДЕНТИФИКАЦИЯ дейтаграммы.
Напомним, что каждый фрагмент имеет точно такой же формат, что и полная дейтаграмма. Для фрагмента поле СМЕЩЕНИЕ ФРАГМЕНТА указывает смещение в исходной дейтаграмме данных, передаваемых в фрагменте, измеряемое в 8 октетах(смещения измеряются в восьмерках октетов для сохранения места в заголовке), начиная со смещения ноль. Для сборки дейтаграммы назначение должно получить все фрагменты, начиная с фрагмента со смещением 0 до фрагмента с наибольшим смещением. Фрагменты необязательно прибывают по порядку, и не существует взаимодействия между шлюзом, который фрагментирует дейтаграммы, и назначением, которое пытается собирать их.
Младшие два бита из трехбитового поля ФЛАГИ управляют фрагментацией. Обычно прикладное программное обеспечение, использующее TCP/IP, не заботится о фрагментации, так как и фрагментация, и сборка являются автоматическими процедурами, которые выполняются на низком уровне в операционной системе незаметно для пользователя. Тем не менее, для тестирования межсетевого программного обеспечения или отладки рабочих проблем может оказаться важной проверка размеров дейтаграмм, для которых осуществляется фрагментация. Первый управляющий бит помогает при таком тестировании, указывая возможность фрагментации дейтаграммы. Он называется битом НЕ ФРАГМЕНТИРОВАТЬ, так как установка его в единицу указывает, что дейтаграмму нельзя фрагментировать. Приложение может выбрать запрет фрагментации, когда нужна лишь целая дейтаграмма. Например, рассмотрим последовательность загрузки компьютера, при которой машина начинает выполнять небольшую программу в ПЗУ, которая использует интернет для запроса начального образа операционной системы, а другая машина посылает ей его. Если программное обеспечение разработано так, что ему нужно либо все, либо ничего, дейтаграмма должна иметь установленный бит НЕ ФРАГМЕНТИРОВАТЬ. Всякий раз, когда шлюзу нужно фрагментировать дейтаграмму с установленным битом НЕ ФРАГМЕНТИРОВАТЬ, шлюз удаляет дейтаграмму и посылает обратно источнику сообщение об ошибке.
Младший бит в поле ФЛАГИ указывает, содержит ли фрагмент данные из середины дейтаграммы или из конца. Он называется битом ЕЩЕ ФРАГМЕНТЫ. Чтобы увидеть, почему нужен этот бит, рассмотрим программное обеспечение IP у получателя, пытающееся собрать дейтаграмму. Оно будет получать фрагменты( возможно не по порядку) ,и ему нужно будет знать, когда оно получило все фрагменты дейтаграммы. Когда появляется еще один фрагмент, поле ОБЩАЯ ДЛИНА в заголовке указывает размер фрагмента, а не размер всей дейтаграммы, поэтому назначение не может использовать поле ОБЩАЯ ДЛИНА для того, чтобы определить, собрало ли оно все фрагменты. Бит ЕЩЕ ФРАГМЕНТЫ легко решает проблему: как только назначение получает фрагмент со сброшенным битом ЕЩЕ ФРАГМЕНТЫ, оно знает, что этот фрагмент несет в себе данные из конца исходной дейтаграммы. На основе полей СМЕЩЕНИЕ ФРАГМЕНТА и ОБЩАЯ ДЛИНА оно может вычислить длину исходной дейтаграммы. Проверив СМЕЩЕНИЕ ФРАГМЕНТА и ОБЩАЯ ДЛИНА у всех прибывших фрагментов, получатель может определить, содержат ли фрагменты все данные, требуемые для сборки исходной дейтаграммы.
Поле ВРЕМЯ ЖИЗНИ указывает сколько секунд может оставаться дейтаграмма в межсетевой системе. Эта идея является насколько простой, настолько и важной: всякий раз, когда машина передает дейтаграмму в интернет, она устанавливает максимальное время, которое может существовать дейтаграмма. Шлюзы и ГВМ, обрабатывающие дейтаграмму, должны декрементировать поле ВРЕМЯ ЖИЗНИ по мере того, как идет время, и удалять дейтаграмму из интернета, когда время вышло.
Оценить время точно трудно, так как шлюзы обычно не знают время передачи между физическими сетями. Несколько правил упрощают обработку и делают легкой обработку дейтаграмм без синхронизации часов. Во-первых, каждому шлюзу на пути от источника к назначению требуется декрементировать поле ВРЕМЯ ЖИЗНИ на единицу, когда он обрабатывает заголовок дейтаграммы. Более того, для обработки случаев перегруженных шлюзов, которые приводят к большим паузам при передаче, каждый шлюз хранит локальное время прихода дейтаграммы и декрементирует ВРЕМЯ ЖИЗНИ на число секунд, в течение которого дейтаграмма находилась в шлюзе, ожидая обслуживания.
Всякий раз, когда поле ВРЕМЯ ЖИЗНИ становится нулевым, шлюз удаляет дейтаграмму и посылает сообщение об ошибке обратно источнику. Идея хранить таймер для дейтаграмм является интересной, так как она гарантирует, что дейтаграммы не смогут вечно путешествовать по интернету, даже если таблицы маршрутизации разрушатся и шлюзы будут маршрутизировать дейтаграммы по кольцу.
Поле ПРОТОКОЛ аналогично полю типа в кадре Ethernetа. Значение в поле ПРОТОКОЛ указывает, какой протокол высокого уровня использовался при создании сообщения, передаваемого в области ДАННЫЕ дейтаграммы. По существу, значение в ПРОТОКОЛ специфицирует формат области ДАННЫЕ. Отображение между протоколом высокого уровня и целым числом, используемым в поле ПРОТОКОЛ, должно администрироваться ответственным центром, чтобы гарантировать действие соглашения по всему интернету.
Поле КОНТРОЛЬНАЯ СУММА ЗАГОЛОВКА удостоверяет целостность значений полей заголовка. Контрольная сумма IP формируется путем представления заголовка как последовательности 16-битовых чисел( с сетевым порядком байт), сложения их вместе, используя арифметику с дополнительным представлением отрицательных чисел, и получения отрицания числа. При вычислении контрольной суммы поле КОНТРОЛЬНАЯ СУММА ЗАГОЛОВКА предполагается равным нулю. Стоит заметить, что эта контрольная сумма применима только к числам, находящимся в заголовке IP, а не в данных. Разделение контрольной суммы для заголовка и для данных имеет свои преимущества и недостатки. Так как заголовок обычно занимает меньше октетов, чем данные, наличие отдельной контрольной суммы для него уменьшает время обработки в шлюзах, которым требуется вычислять только контрольную сумму заголовка. Это разделение также позволяет протоколам более высокого уровня выбирать свои собственные схемы расчета контрольной суммы для данных. Главным недостатком является то, что протоколы более высокого уровня вынуждены добавлять свои контрольные суммы или рисковать тем, что они не смогут обнаружить искажения данных.
Поля АДРЕС ОТПРАВИТЕЛЯ IP и АДРЕС ПОЛУЧАТЕЛЯ IP содержат 32-битовые IP-адреса отправителя дейтаграммы и конечного получателя. Хотя дейтаграмма может проходить через большое число промежуточных шлюзов, поля отправителя и получателя никогда не изменяются; они указывают IP-адреса истинного источника и конечного назначения.
Поле, названное ДАННЫЕ на рисунке 7.3, показывает начало области данных в дейтаграмме. Его длина зависит, конечно, от того, что посылается в дейтаграмме.
Поле ОПЦИИ IP, рассматриваемое ниже, имеет переменную длину. Поле, названное ЗАПОЛНЕНИЕ, зависит от выбранных опций. Оно представляет собой биты, содержащие нули, которые могут потребоваться для дополнения заголовка дейтаграммы до длины, кратной 32 битам(напомним, что поле длины заголовка указывает ее в 32-битных словах).
Поле ОПЦИИ IP, следующее за адресом назначения, не требуется в каждой дейтаграмме; опции включаются, в основном, для тестирования или отладки сети. Обработка опций, тем не менее, является составной частью протокола IP, поэтому все стандартные реализации включают ее.
Длина поля ОПЦИИ IP меняется в зависимости от того, какие опции выбраны. Некоторые опции имеют длину один октет; они состоят из кода опции, занимающего один октет. Другие опции имеют переменную длину. Когда в дейтаграмме есть опции, они размещаются друг за другом, без специальных разделителей между ними. Каждая опция состоит из кода опции длиной в один октет, за которым может следовать длина опции(тоже занимает один октет) и группы октетов данных для этой опции. Октет кода опции делится на три поля, как показано на рисунке 7.8.
0 1 2 3 4 5 6 7
----------------------------------------------------------
| КОПИРОВАТЬ | КЛАСС ОПЦИИ | НОМЕР ОПЦИИ |
----------------------------------------------------------
Этими полями являются однобитовый флаг КОПИРОВАТЬ, двухбитовый КЛАСС ОПЦИИ и пятибитовый НОМЕР ОПЦИИ. Флаг КОПИРОВАТь управляет тем, как шлюзы рассматривают опции при фрагментации. Когда бит КОПИРОВАТЬ установлен в 1, он указывает, что эта опция должна копироваться во все фрагменты. Когда он установлен в 0, бит КОПИРОВАТь означает, что опцию нужно копировать только в первый фрагмент, а не во все.
Биты КЛАСС ОПЦИИ и НОМЕР ОПЦИИ указывают общий класс опции и номер опции внутри этого класса. Таблица на рисунке 7.9 показывает, как назначены номера классам.
| Класс опции | Значение |
| 0 | Управление дейтаграммой или сетью |
| 1 | Зарезервировано |
| 2 | Отладка и измерения |
| 3 | Зарезервировано |
Таблица на рисунке 7.10 приводит список возможных опций в IP-дейтаграммах и указывает для них значения КЛАССА ОПЦИИ и НОМЕРА ОПЦИИ. Как показывает этот список, большая часть опций используется для целей управления.
| Класс опции | Номер опции | Длина | Описание |
|---|---|---|---|
| 0 | 0 | - | Конец списка опций. Используется, если опция не заканчивается в конце заголовка(смотри также поле дополнения) |
| 0 | 1 | - | Нет операции(используется для выравнивания октетов в списке опций) |
| 0 | 2 | 11 | Секретность(для военных приложений) |
| 0 | 3 | пер | Слабая маршрутизация источника. Используется для маршрутизации дейтаграммы по указанному пути. |
| 0 | 7 | пер | Запись маршрута. Используется для трассировки маршрута |
| 0 | 8 | 4 | Идентификатор потока. Используется для передачи идентификатора потока SATNET (недействительно) |
| 0 | 9 | пер | Сильная маршрутизация источника Используется для маршрутизации дейтаграммы по указанному пути |
| 2 | 4 | пер | Межсетевые временные метки. Используется для записи временных меток по маршруту |
Опции маршрутизации и временных меток являются самыми интересными, так как они обеспечивают способ наблюдения или управления тем, как межсетевые шлюзы маршрутизируют дейтаграммы. Опция запись маршрута позволяет источнику создать пустой список IP-адресов и заставить каждый шлюз, обрабатывающий дейтаграмму, добавлять свой IP-адрес к этому списку. Рисунок 7.11 показывает формат опции записи маршрута.
Как описано выше, поле КОД содержит номер опции и класс опции( 7 для записи маршрута). Поле ДЛИНА указывает общую длину опции в том виде, в котором она представлена в IP-дейтаграмме, включая первые три октета. Поля, начиная с поля, помеченного ПЕРВЫЙ IP-АДРЕС, составляют область, зарезервированную под хранение межсетевых адресов. Поле УКАЗАТЕЛЬ определяет смещение внутри опции первого свободного слота.
0 8 16 24 ------------------------------------------- | КОД(7) | ДЛИНА | УКАЗАТЕЛЬ | ---------------------------------------------------------- | Первый IP-адрес | ---------------------------------------------------------- | Второй IP-адрес | ---------------------------------------------------------- | ....... | ----------------------------------------------------------
Всякий раз, когда машина обрабатывает дейтаграмму, имеющую опцию записи маршрута, она добавляет свой адрес к списку записи маршрута(в опции должно быть выделено достаточно места исходным отправителем для того, чтобы поместились все нужные элементы). При добавлении себя к списку машина сначала сравнивает поля указателя и длины. Если указатель больше, чем длина, то список полон, и машина отправляет дейтаграмму, не добавляя нового элемента. Если список не полон, машина вставляет 4-байтовый IP-адрес в позицию, определенную УКАЗАТЕЛЕМ, и увеличивает значение УКАЗАТЕЛЯ на четыре.
При прибытии дейтаграммы машина-получатель должна выделить и обработать список IP-адресов. Если получатель обрабатывает дейтаграмму обычным образом, он будет игнорировать записанный путь. Отметим, что отправитель должен разрешить наличие опции записи маршрута, а получатель должен быть согласен обработать полученный список; сама по себе машина не получит автоматически информацию о пройденном пути автоматически, если она включит опцию записи маршрута.
Другой идеей, которую создатели сетей нашли интересной, является опция пути источника. Идея, лежащая в основе маршрутизации источника, заключается в том, чтобы отправитель мог определять путь в интернете. Например, для тестирования пропускной способности конкретной физической сети N системные администраторы могут использовать маршрутизацию источника для направления IP-дейтаграмм через сеть N, даже если шлюзы обычно выбирают путь, не включающий ее. Возможность делать такие тесты особенно важна в производственной среде, так как позволяет сетевым администраторам маршрутизировать дейтаграммы пользователей по сетям, про которые известно, что они работают корректно, и параллельно с этим проверять другие сети. Конечно, такая маршрутизация полезна только для тех людей, которые понимают топологию сети; среднему пользователю не нужно знать или использовать эту опцию.
IP поддерживает две формы маршрутизации источника. Одна форма, названная строгой маршрутизацией источника, определяет путь с помощью включения последовательности IP-адресов в эту опцию как показывает рисунок 7.12.
0 8 16 24 ------------------------------------------- | КОД(137) | ДЛИНА | УКАЗАТЕЛЬ | ---------------------------------------------------------- | Первый IP-адрес | ---------------------------------------------------------- | Второй IP-адрес | ---------------------------------------------------------- | ....... | ----------------------------------------------------------
Строгая маршрутизация источника означает, что адреса определяют точный путь, которым должна следовать дейтаграмма, при передаче ее к месту назначения. Путь между двумя последовательными адресами в списке должен состоять из одной физической сети; если шлюз не может выполнить строгую маршрутизацию источника, возникает ошибка. Другая форма, называемая слабой маршрутизацией источника, также включает последовательность IP-адресов. Она определяет, что дейтаграмма должна следовать через эту последовательность IP-адресов, но допускает наличие нескольких переходов через сети между последовательными адресами в списке.
Обе опции маршрутизации источника требуют от шлюзов на всем пути заменять элементы списка адресов своими сетевыми адресами. Поэтому, когда дейтаграмма поступает к получателю, она содержит список всех посещенных адресов, точно такой же, как и список, создаваемый опцией записи маршрута.
Формат опции маршрутизации источника напоминает показанный выше формат опции записи маршрута. Каждый шлюз проверяет поля УКАЗАТЕЛЬ и ДЛИНА, чтобы обнаружить переполнение списка. Если оно произошло, указатель будет больше, чем длина, и шлюз будет маршрутизировать дейтаграмму к ее назначению обычным образом. Если список заполнен еще не до конца, шлюз на основании указателя выделяет IP-адрес, заменяет его на адрес шлюза(шлюз имеет по одному адресу для каждого интерфейса; он записывает адрес, соответствующий сети, по которой он отправляет дейтаграмму) и маршрутизирует дейтаграмму, используя адрес, полученный из списка.
Опция временных меток работает аналогично опции записи маршрута в том отношении, что опция временных меток содержит вначале пустой список, а каждый шлюз на всем протяжении пути от источника к назначению заполняет элемент в этом списке. Каждый элемент в списке состоит из двух 32-битных частей: IP-адреса шлюза, заполнившего этот элемент, и 32-битового целого числа - временной метки. Рисунок 7.13 приводит формат опции временных меток.
0 8 16 24 31 ---------------------------------------------------------- | КОД(68) | ДЛИНА | УКАЗАТЕЛЬ |ПЕРЕП | ФЛАГИ | ---------------------------------------------------------- | Первый IP-адрес | ---------------------------------------------------------- | Первая временная метка | ---------------------------------------------------------- | ....... | ----------------------------------------------------------
На рисунке поля ДЛИНА и УКАЗАТЕЛЬ используются для указания длины зарезервированного места и местонахождения следующего неиспользованного слота( как в опции записи маршрута). 4-битовое поле ПЕРЕП содержит целое число шлюзов, которые не смогли записать временные метки из-за слишком маленького размера опции. Значение в 4-битовом поле ФЛАГИ определяет точный формат опции и говорит шлюзам, как записывать временные метки. Допускаются следующие значения:
| Значение | Смысл |
|---|---|
| 0 | Только запись временных меток, IP-адреса опускаются |
| 1 | Указывать перед каждой временной меткой IP-адрес (формат, показанный на рисунке 7.13) |
| 3 | IP-адреса указываются отправителем, шлюз только записывает временную метку, если следующий IP-адрес в списке соответствует IP-адресу шлюза. |
Временные метки определяют время и дату, когда шлюз обрабатывал дейтаграмму, и выражаются в миллисекундах после полуночи по Гринвичу. Если стандартное представление времени невозможно, шлюз может использовать любое представление локального времени при условии, что он устанавливает старший бит в поле временной метки. Конечно, временные метки, записываемые независимыми компьютерами, не всегда согласованы, даже если представлены во времени по Гринвичу; каждая машина сообщает время согласно своим локальным часам, а часы могут идти по-разному. Поэтому, временные метки всегда рассматриваются как приблизительные оценки, независимо от их представления.
Может показаться странным, что опция временных меток включает механизм, заставляющий шлюзы записывать их IP-адреса вместе с временными метками, так как опция записи маршрута обеспечивает эту возможность. Тем не менее, запись IP-адресов вместе с временными метками позволяет избежать неоднозначности. Одновременная запись маршрута с временными метками также полезна потому, что она позволяет приемнику узнать точно, какой путь прошла дейтаграмма.
Идея, лежащая в основе применения бита КОПИРОВАТЬ в поле опции КОД, теперь понятна. При фрагментации дейтаграммы шлюз повторяет некоторые IP-опции во всех фрагментах, в то время как другие помещаются только в один фрагмент. Например, рассмотрим опцию, используемую для записи маршрута дейтаграммы. Мы говорили, что каждый фрагмент будет обрабатываться как независимая дейтаграмма, поэтому не гарантируется, что все фрагменты будут следовать по одному и тому же пути к месту назначения. Если все фрагменты содержат опцию записи маршрута, назначение может получить свой список шлюзов от каждого фрагмента. Оно не сможет создать одного списка для собранной дейтаграммы. Поэтому, стандарт IP определяет, что опция записи маршрута должна копироваться только в один из фрагментов.
Не все опции IP должны находиться в одном фрагменте. Рассмотрим, например, опцию маршрутизации источника, которая определяет, как должна передаваться дейтаграмма через интернет. Информация о маршрутизации источника должна находиться в заголовках всех фрагментов, иначе фрагменты не будут следовать указанным путем. Поэтому, поле кода для маршрутизации источника указывает, что эта опция должна копироваться во все фрагменты.
Фундаментальным средством, обеспечиваемым программным обеспечением TCP/IP , является ненадежная система доставки пакетов без установления соединения. Межсетевой протокол(IP) формально определяет формат межсетевых пакетов, называемых дейтаграммами, и неформально воплощает в себе идеи доставки без установления соединения. Эта глава была сосредоточена главным образом на форматах дейтаграмм; следующие главы рассмотрят маршрутизацию IP и обработку ошибок.
Аналогично физическому кадру, дейтаграмма IP делится на заголовок и область данных. Помимо другой информации, заголовок дейтаграммы содержит IP-адреса источника и назначения, управление фрагментацией, приоритет и контрольную сумму, используемую для обнаружения ошибок передачи. Кроме полей фиксированной длины, каждый заголовок дейтаграммы может содержать поле опций. Поле опций имеет переменную длину, зависящую от числа и типов используемых опций, а также от размеров области данных, выделенной для каждой опции. Предназначенные для облегчения наблюдения и управления интернетом, опции позволяют указать или записать информацию о маршруте, или собрать временные метки о том, как дейтаграмма передается по интернету.
7.1 Что является самым большим достоинством контрольной суммы IP, учитывающей только заголовок, но не данные ? А недостатком ?
7.2 Нужно ли использовать контрольную сумму IP при посылке пакетов по Ethernetу ?
7.3 Каково значение МЕП для MILNET ? NSFNET ? X25NET ?Hyperchannel ?
7.4 Как вы думаете , больший или меньший размер МЕП будут иметь высокоскоростные локальные сети по сравнению с более медленными глобальными сетями ?
7.5 Докажите, что фрагменты должны иметь маленькие, нестандартные заголовки.
7.6 Установите, когда в последний раз менялась версия протокола IP. Имеет ли смысл на самом деле иметь номер версии протокола ?
7.7 Можете ли вы догадаться, почему для IP была выбрана контрольная сумма с дополнением до единицы вместо циклической проверки ?
7.8 Каковы преимущества сборки в месте конечного назначения вместо сборки после того, как дейтаграмма пересекла одну сеть ?
7.9 Какой минимальный МЕП требуется для посылки дейтаграммы IP, содержащей по крайней мере один октет данных ?
7.10 Предположим, вы решили реализовать обработку IP-дейтаграммы с помощью оборудования. Существуют ли другие расположения полей заголовка, делающие ваше оборудование более эффективным ? А более простым ?
7.11 Если вы имеете доступ к реализации IP, изучите ее и проверьте доступные вам реализации IP на предмет удаления ими дейтаграмм с устаревшим номером версии.
Назад | Содержание | Вперед