| |
Мы уже рассмотрели части сетевого оборудования и программного обеспечения, которые делают возможным межсетевое взаимодействие, объяснили базовые сетевые технологии и разрешение адресов. Эта глава рассматривает фундаментальный принцип доставки без установления соединения и обсуждает, как он реализуется с помощью Межсетевого протокола(IP), одного из двух основных протоколов, используемых при межсетевом обмене. Мы изучим формат дейтаграмм IP и увидим, как они образуют основу для всех видов межсетевого взаимодействия. Следующие две главы продолжат изучение Межсетевого Протокола, обсуждая вопросы маршрутизации дейтаграмм и обработки ошибок.
Глава 3 рассмотрела межсетевую архитектуру, в которой машины-шлюзы соединяют группу физических сетей. Знание архитектуры может ввести в заблуждение, так как внимание следует сосредоточить на интерфейсе, который предоставляет интернет пользователям, а не на технологии взаимного соединения.
Пользователь представляет себе интернет в виде одной виртуальной сети, соединяющей все ГВМ, с помощью которой и делается возможным взаимодействие; его настоящая архитектура является невидимой и ненужной.
По существу интернет является абстракцией физической сети, так как, на самом нижнем уровне, он обеспечивает те же самые возможности: прием пакетов и доставка их. Более высокие уровни межсетевого программного обеспечения добавляют большую часть богатых возможностей, доступным пользователям.
На концептуальном уровне интернет TCP/IP обеспечивает три множества средств, как показано на рисунке 7.1; их расположение на рисунке предполагает зависимости между ними. На самом нижнем уровне, средство доставки без установления соединения обеспечивает основу для всего остального. На следующем уровне надежное транспортное средство обеспечивает платформу более высокого уровня, от которую опираются приложения. Мы вскоре освоим каждое из этих трех средств, поймем, что они обеспечивают, и увидим, какие протоколы связаны с ними.
-------------------------------------------- | ПРИКЛАДНЫЕ СРЕДСТВА | -------------------------------------------------- | НАДЕЖНОЕ ТРАНСПОРТНОЕ СРЕДСТВО | -------------------------------------------------------- | СРЕДСТВО ДОСТАВКИ ПАКЕТОВ БЕЗ УСТАНОВЛЕНИЯ СОЕДИНЕНИЯ| --------------------------------------------------------
Рисунок 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 показывает общую форму дейтаграммы:
----------------------------------------------------------- | ЗАГОЛОВОК | ОБЛАСТЬ ДАННЫХ | | ДЕЙТАГРАММЫ | ДЕЙТАГРАММЫ | -----------------------------------------------------------
Рисунок 7.2 Общая форма IP-дейтаграммы, аналогии сетевому кадру в TCP/IP. IP специфицирует формат заголовка, включая IP-адреса источника и назначения. IP не описывает формат области данных; она может быть использована для транспортировки произвольных данных.
Теперь, после того, как мы описали общий формат IP-дейтаграммы, можно рассмотреть ее содержимое более детально. Рисунок 7.3 показывает расположение полей дейтаграммы:
0 4 8 16 19 24 31 ------------------------------------------------------------ |версия|длина| тип сервиса| общая длина | ------------------------------------------------------------ | идентификация |флаги |смещение фрагмента | ------------------------------------------------------------ |время жизни | протокол | КС заголовка | ------------------------------------------------------------ | IP-адрес отправителя | ------------------------------------------------------------ | IP-адрес получателя | ------------------------------------------------------------ | Опции IP(если есть) |заполнение | ------------------------------------------------------------ | Данные | ------------------------------------------------------------ | ... | ------------------------------------------------------------
Рисунок 7.3 Формат дейтаграммы Интернета, основного элемента передачи в интернете TCP/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 | не используется | -------------------------------------------------------------
Рисунок 7.4 Пять подполей, составляющих 8-битовое поле типа сервиса
Три бита ПРИОРИТЕТА указывают приоритет дейтаграммы, значения которого могут меняться от 0(обычный приоритет) до 7(управление сетью), позволяя отправителям передавать информацию о важности каждой дейтаграммы. Хотя программное обеспечение большинства ГВМ и шлюзов игнорирует тип сервиса, он является важным понятием, так как обеспечивает механизм, который впоследствии позволит управляющей информации иметь больший приоритет, чем данные. Например, если все ГВМ и шлюзы будут учитывать приоритет, станет возможной реализация алгоритмов управления перегрузкой сети, на которые не будет влиять перегрузка, которой они пытаются управлять.
Биты D, T и R описывают тип передачи, который нужен дейтаграмме. Установка бита D запрашивает минимальные задержки при передаче, бита T - максимальную пропускную способность, а бита R - максимальную надежность. Конечно, интернет не может гарантировать выполнение запрошенного сервиса(например, может быть так, что нет пути к назначению с запрошенными качествами). Поэтому, мы будем рассматривать запрос сервиса как указание алгоритмам маршрутизации, а не как требование. Если шлюз знает более чем один маршрут к указанному назначению, он может использовать поле типа транспорта для выбора пути с характеристиками наиболее близкими требуемым. Например, предположим, что шлюз может выбирать между низкоскоростной арендованной линией или высокоскоростной(но с большими паузами) спутниковой линией. Дейтаграммы, передающие нажатия клавиш от пользователя к удаленному компьютеру, могут иметь установленным бит D, запрашивая таким образом самую быструю доставку, в то время как дейтаграммы, используемые при передаче большого файла, могут иметь установленным бит T, запрашивая передачу по высокоскоростной спутниковой линии.
Важно понимать, что алгоритмы маршрутизации должны выбирать из используемых физических сетевых технологий , которые имеют определенные характеристики задержки, пропускной способности и надежности. Часто данная технология использует компромисс между этими характеристиками(например, высокой скоростью передачи и большей задержкой). Поэтому, идея состоит в том, чтобы дать алгоритму указание о том, что наиболее важно; не имеет смысла указывать все три типа сервиса. Подведем итоги:
Мы рассматриваем спецификацию типа передачи как указание алгоритму маршрутизации, которое помогает выбрать один путь к назначению из группы на основе знаний об аппаратных технологиях, использующихся на этих путях. Интернет не гарантирует выполнения запрошенного транспортного сервиса.
Перед тем, как мы сможем понять следующие поля дейтаграммы, нам нужно рассмотреть, как дейтаграммы соотносятся с кадрами физической сети. Мы начнем с вопроса: "Каков максимальный размер дейтаграммы ?" В отличие от кадров физической сети, которые должны распознаваться оборудованием, дейтаграммы обрабатываются программным обеспечением. Они могут иметь любую длину, какую выберут разработчики протокола. Мы видели, что текущий формат дейтаграммы выделяет 16 бит под поле общей длины, ограничивая дейтаграмму 65535 октетами. Тем не менее, этот предел может быть изменен в следующих версиях протокола.
Более фундаментальные ограничения на размер дейтаграммы накладываются практикой работы. Мы знаем, что по мере того, как дейтаграммы передаются от одной машины к другой, они всегда должны транспортироваться базовыми физическими сетями. Для эффективности межсетевой передачи нам нужно быть уверенным в том, что каждая дейтаграмма передается в отдельном физическом кадре. То есть, мы хотим, чтобы наша абстракция пакета физической сети напрямую соответствовала реальному пакету, если это возможно. Идея передачи одной дейтаграммы в одном сетевом кадре называется инкапсуляцией. Для базовой сети дейтаграмма выглядит так же, как и любое другое сообщение, посылаемое от одной машины к другой. Оборудование как не знает формата дейтаграммы, так и не понимает IP-адреса назначения. Поэтому, как показывает рисунок 7.5, когда одна машина посылает IP-дейтаграмму другой, вся дейтаграмма передается как часть данных сетевого кадра.
------------------------------------------------- |заголовок | область данных дейтаграммы | |дейтаграммы | | ------------------------------------------------- | | V V ----------------------------------------------------------- |заголовок| | |кадра | область данных кадра | -----------------------------------------------------------
Рисунок 7.5 Инкапсуляция IP-дейтаграммы в кадр. Физическая сеть рассматривает всю дейтаграмму, включая заголовок, как данные.
В идеальном случае вся дейтаграмма 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 + ----- + + + + + +
Рисунок 7.6 Иллюстрация того, где происходит фрагментация. Шлюз Ш1 фрагментирует большие дейтаграммы, посылаемые от А к Б; Ш2 фрагментирует большие дейтаграммы, посылаемые от Б к А.
На рисунке оба ГВМ напрямую присоединения к Ethernetам, которые имеют МЕП в 1500 октетов. Поэтому оба ГВМ могут генерировать и посылать дейтаграммы до 1500 октетов длины. Путь между ними, тем не менее, включает сеть с МЕП, равным 620. Если ГВМ А посылает ГВМ Б дейтаграмму длиннее 620 октетов, шлюз Ш1 будет фрагментировать дейтаграмму. Аналогично, если Б посылает большую дейтаграмму А, шлюз Ш2 будет фрагментировать дейтаграмму. Размер фрагмента выбирается таким, чтобы каждый фрагмент мог транспортироваться в одном кадре. Кроме того, так как IP передает значение смещения данных в восьмерках октетов, размер фрагмента должен быть выбран кратным восьми. Конечно, выбор числа октетов, кратного восьми и наиболее близкого к сетевой МЕП, не обязательно делит дейтаграмму на равные части; последняя часть часто короче, чем остальные. Фрагменты должны собираться для воссоздания полной копии исходной дейтаграммы перед тем, как она будет обрабатываться у получателя.
Протокол IP как не ограничивает дейтаграммы до маленького размера, так и не гарантирует, что большие дейтаграммы будут доставлены без фрагментации. Отправитель может выбрать любой размер дейтаграммы, какой он посчитает уместным; фрагментация и сборка производятся автоматически, не требуя специальных действий от отправителя. Спецификация IP устанавливает, что шлюзы должны принимать дейтаграммы с размерами, не превосходящими МЕП сетей, к которым они присоединены. Кроме того, шлюзы должны всегда обрабатывать дейтаграммы до 576 октетов. (От ГВМ также требуется принимать и собирать при необходимости дейтаграммы не короче 576 октетов).