Реферат: Понятие протокола, и связанные с ним понятия

Введение 3

Понятие протокола, и связанные с ним понятия. 3

Протоколы сети Internet 5

Протокол IP (Internet Protocol). 8

Место протокола IP в иерархии протоколов сети Internet. 8

Структура IP-пакета 11

Адресация в IP-протоколе 15

Адресация в IP-сетях 17

Виды адресов: Локальные (Физические, MAC) адреса, Сетевые адреса (IP), Символьные имена (DNS). 17

Установление соответствия между адресами разных уровней, протоколы преобразования адресов. 19

Виды IP-адресов и их интерпретация. 22

Протоколы, обслуживающие стек TCP/IP. 25

Состав и структура системы протоколов межсетевого (Internet) уровня стека TCP/IP. 25

Протокол контрольных сообщений Internet ICMP. 26

Протоколы ARP/RARP. 34

Транспортный уровень. Протоколы TCP и UDP. 37

Место протоколов UDP и TCP в иерархии протоколов сети Internet. 37

Протокол UDP. 38

Протокол ТСР 39

Реализация TCP. 46

Интерфейс между прикладными программами и TCP. 46

События, возможные при передаче информации с использованием TCP. 53

Динамика работы и параметры времени ожидания. 60

Оптимизация TCP. Управление потоком. 62

Выбор размера TCP-сегмента и синдром “узкого окна”. 62

Медленный старт в TCP. 64

Устранение перегрузок средствами TCP. 66

Маршрутизация. Общие положения. 69

Общее понятие о маршрутизации. 69

Маршрутизация пакетов по таблицам и без таблиц. 71

Создание и модификация таблиц маршрутной информации. Виды протоколов маршрутизации. 76

Внутренние протоколы маршрутизации – RIP и OSPF. 79

Дистанционно-векторный протокол RIP. 79

Протокол OSPF – пример протокола состояния связей 82

Факультативный материал – форматы сообщений OSPF подробно. 87

Автономные системы и их взаимодействие. Внешняя маршрутизация. 93

Понятие о маршрутной политике. 93

Протокол внешней маршрутизации BGP-4. Состав и функции. 95

Мультивещательные группы. Маршрутизация мультивещательных (multicasting) пакетов. 105

Общее представление о Multicasting. Протокол IGMP. 105

Маршрутизация multicast-пакетов. Изменения протоколов маршрутизации для поддержки multicast-групп. 109

Уровень сетевых интерфейсов TCP/IP. 115

Общие сведения о взаимодействии TCP/IP с оборудованием компьютерных сетей. 115

Спецификации передачи трафика IP в локальных сетях (LAN). 117

Спецификации передачи трафика IP в глобальных сетях (WAN). 119

Передача IP трафика через произвольные цифровые каналы. Протоколы SLIP и PPP. 121

Факультативный материал – сжатие заголовков TCP/IP на примере сжатия Ван Джакобсона. 126

Система назначения и разрешения доменных имен DNS. 129

Принципы назначения символьных имен. Альтернативные DNS варианты: WINS, NetBIOS-имена. 129

Иерархическая организация доменных имен. 130

Система назначения и администрирования доменных имен DNS. 132

Факультативный материал – трансляция IP-адресов в IP-адреса. – протоколы NAT и NAPT. 135

Разрешение некоторых проблем, связанных с NAT. Протокол STUN. 138

Системы передачи электронной почты. 141

Назначение систем передачи электронной почты. 141

Протоколы POP3 та SMTP. 143

Дополнительные возможности электронной почты. Спецификация MIME. Протоколы IMAP. 149

Другие протоколы прикладного уровня стека TCP/IP. 154

Протокол FTP. 154

Протокол HTTP. 155

Конфигурирование TCP/IP систем. 167

Задачи конфигурирования. 167

Параметры конфигурации и их взаимосвязь. 168

Файлы конфигурационной информации. 171

Защита компьютерных сетей. 174

Виды угроз, от которых следует защищать компьютерные сети. 174

Основные приемы сетевых атак. 177

Конкретные формы атак на IP-сети. 180

Приложения 191

Приложение 1. Схема машины конечных состояний протокола TCP. 191

Приложение 2. Стандартные multicast адреса Internet. 191

Приложение 3. Стандартные протоколы стека TCP/IP. 193

Литература 195



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

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

Так устройства или процессы? Обмен информацией происходит между обрабатывающими ее процессами посредством устройств. Между устройствами происходит обмен сигналами, несущими информацию. Но обмен этот, в свою очередь, организуется посредством процессов! Так что и устройства, и процессы.

^ Формы и процедуры. Как правило, протокол регламентирует некие структуры данных, чаще всего именуемые кадрами, пакетами и т.д., посредством которых осуществляется обмен, и правила их интерпретации и обработки.

Можно провести аналогию, например, с математическими понятиями, когда определяются, например, числа (натуральные, целые, рациональные, действительные, комплексные), и операции над ними (4 основных арифметических, функции). Продолжая аналогию, вспомним, что из чисел можно формировать более сложные объекты, например, векторы, матрицы и т.д. Эти сложные объекты в свою очередь имеют свои операции, применимые к ним. В свою очередь, эти сложные объекты могут представлять, например, некую систему уравнений, которая имеет некую физическую интерпретацию (токи в участках электрической цепи, координаты небесного тела, распределение электронной плотности около атомов в сложной молекуле, или вероятность наступления беременности у самки носорога), и соответствующий процесс подчинен своим специфическим законам. При этом электронщика, астронома, химика и биолога интересуют в первую очередь законы и свойства объектов своей предметной области, а не то, как складываются комплексные числа или перемножаются матрицы – для этого имеется готовый математический аппарат.

Аналогичным образом, процесс обмена информацией имеет ряд иерархических уровней, на которых взаимодействуют устройства и процессы. Общепринятым языком описания такого взаимодействия является 7-уровневая эталонная логическая модель взаимодействия открытых систем (ЭМ ВОС, OSI – Open System Interface).

В общем случае ЭМ ВОС выделяет следующие уровни взаимодействия:

Физические связи между элементами (механические, электрические, преобразование сигналов) – физический уровень (управление каналом связи).

Установление, поддержание, разъединение соединений (каналов) – канальный уровень (управление каналом передачи данных).

Маршрутизация, коммутация, адресация информации – сетевой уровень (управление потоками данных).

Управление передачей данных от системы – источника к системе – потребителю (без обработки в промежуточных узлах) – транспортный уровень.

Первые 4 уровня образуют транспортную службу.


Организация и проведение сеансов связи между отдельными процессами – сеансовый уровень.

Первые 5 уровней в совокупности составляют сетевой метод доступа.


Интерпретация и преобразование передаваемых между процессами данных к виду, удобному для обработки процессами – уровень представления данных.

Выполнение прикладных программ, управление терминалами, административное управление сетью – прикладной уровень.


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

Физический уровень и связанные с ним протоколы реализуются аппаратной частью компьютера и аппаратуры передачи данных.

Канальный уровень реализуется также аппаратной частью под управлением программ операционной системы (DOS – Interlnk/Intersvr, Windows – Удаленный доступ и прямое соединение, драйверы устройств и т.д.).

Эти уровни обычно считаются частью базовой сетевой технологии. Различные базовые сетевые технологии подробно рассматриваются в курсе “современные телекоммуникационные технологии для компьютерных сетей” (СТТ).

Вышестоящие уровни, начиная с сетевого, реализуются программным обеспечением и составляют стек телекоммуникационных протоколов.

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

Система протоколов Internet, известная как стек TCP/IP, разрабатывалась исследовательским подразделением DARPA Министерства Обороны США с 1969 года, и в первом приближении сложилась к началу 1980-х годов.

Изначально она предназначалась для объединения разнородных сетей военного ведомства США, и должна была обеспечить их согласованное функционирование, в том числе и в случае нанесения по США массированного ядерного удара. Отдельные элементы (в том числе целые сети) могут выйти из строя, но оставшаяся сеть должна функционировать. Можно констатировать, таким образом, что создание этой системы протоколов, а на их основе – глобальной сети Internet – один из немногих (если не единственный) положительный результат Холодной войны.
^ Протоколы сети Internet





Структура стека протоколов TCP/IP несколько отличается от модели OSI. В нем выделяется 4 уровня – сетевых интерфейсов, межсетевого взаимодействия(Internet), транспортный и уровень приложений.


^ Уровень сетевых интерфейсов отвечает за то, как именно IP-пакеты передаются сетями разных базовых технологий, называемых в терминологии стека TCP/IP локальными. Термин “локальная” в этом контексте означает только то, что данная технология применяется в отдельной сети, и не имеет отношения к понятиям “локальная сеть”(LAN)/”глобальная сеть”(WAN), как они применяются к базовым сетевым технологиям. Internet изначально создавался как “сеть сетей”, он объединяет на базе единого сетевого протокола сети самых разных базовых технологий, в этом смысле технологии, на которых построены отдельные объединяемые сети – локальные. В первом приближении можно считать, что он соответствует двум нижним уровням модели OSI – физическому и канальному. Но следует учитывать, что базовые технологии, на которых построены отдельные сети, сами могут быть достаточно сложными, например, ATM включает сетевой уровень и даже элементы транспортного. Уровень сетевых интерфейсов в это не вникает, он определяет инкапсуляцию пакетов в кадры или пакеты самого высокого уровня базовой технологии и пользуется ей как технологией уровня канала данных.

^ Межсетевой уровень обеспечивает объединение разнородных сетей в единую сеть под управлением протокола IP (Internet Protocol). Соответствует сетевому уровню модели OSI. Реализуется средствами как ПК, так и сети (маршрутизаторами). Межсетевой уровень отвечает, в частности, за адресацию, т.е. гарантирует, что маршрутизатор знает, что делать с вашими данными, когда они поступят. Единица данных, с которой оперирует протокол IP, называется пакетом. Адресная информация приводится в начале каждого пакета, в его заголовке. Она даёт сети достаточно сведений для доставки пакета данных по назначению. Каждый пакет перемещается по сети независимо от других пакетов, принадлежащих тому же соединению, и, в общем случае, пакеты одного сообщения могут доставляться по разным маршрутам.

Internet-адреса имеют единый формат для всей сети, независимо от систем адресов локальных сетей. 32-битный IP-адрес обычно записывается в виде четырёх десятичных чисел, каждое из которых не превышает 255. Каждое число представляет один из 4-х байт адреса. В годы становления протоколов стека TCP/IP термин «байт» не был общепринятым, поэтому в документах Internet байт часто называется октетом. При записи числа отделяются одно от другого точками, например:

192.112.36.5

128.174.5.6

Адрес фактически состоит из нескольких частей. Поскольку Internet – это сеть сетей, то начало адреса содержит информацию для маршрутизаторов о том, к какой сети относится Ваш компьютер. Правая часть адреса служит для того, чтобы сообщить сети, какой компьютер должен получить этот пакет. Каждый компьютер в Internet имеет свой уникальный адрес. Internet выполнила свою задачу, когда ее маршрутизаторы направили данные в соответствующую сеть, а эта локальная сеть – в соответствующий компьютер. В документах Internet маршрутизатор обычно называется шлюзом (Gateway), поскольку изначально ставилась задача объединения разнородных сетей. В настоящее время термин «шлюз» обычно используется для обозначения устройства, объединяющего совсем разнородные сети, например «шлюз IP-телефонии» – телефонную сеть с коммутацией каналов и IP-сеть с коммутацией пакетов. Поэтому мы будем пользоваться термином «маршрутизатор», но помнить о таком употреблении термина «шлюз» следует.

Для решения этой задачи маршрутизатор (и конечный узел тоже) должен, таким образом, во-первых, знать, кому (конечному узлу, либо следующему маршрутизатору) направить поступивший пакет. Во вторых, поскольку пакеты передаются через локальную сеть, имеющую свою, отличную от Internet, систему адресации, он должен знать, как преобразовать Internet-адрес в локальный адрес. Решение первой задачи обеспечивают протоколы обмена маршрутной информацией, часто называемые просто протоколами маршрутизации (на рисунке они не показаны, поскольку их много). Вторая задача решается протоколом разрешения адресов ARP, а протокол RARP решает обратную задачу – отыскание сетевого адреса по известному локальному адресу. Кроме того, к межсетевому уровню относится протокол контрольных сообщений ICMP, который служит для информирования узлов и маршрутизаторов о различных нештатных ситуациях в сети. Следует учесть, что поскольку протокол IP является универсальным “транспортным средством” сети Internet, ICMP сообщения, как и сообщения протоколов маршрутизации, передаются по сети в IP-пакетах, таким образом, формально они выглядят как протоколы более высокого, чем IP, уровня, хотя фактически они обеспечивают функционирование протокола IP.

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

^ Транспортный Уровень реализуется протоколом TCP (Transmission Control Protocol), «протокол управления передачей» который часто упоминают вместе с протоколом IP, в том числе в названии стека, и протоколом UDP (user datagram protocol) «протокол пользовательских дейтаграмм».

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

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

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

Более простой «протокол пользовательских дейтаграмм» (User Datagram Protocol, UDP) также используется в некоторых прикладных программах. Вместо вкладывания Ваших данных в “конверт” TCP и помещения этого конверта в пакет IP прикладная программа вкладывает данные в “конверт” UDP, называемый обычно датаграммой, который и помещается в пакет IP. В отличии от ТСР, передающего поток данных, каждая датаграма составляет законченное сообщение. UPD проще ТСР, потому что этот протокол не заботится о пропавших пакетах, расположении данных в правильном порядке и других тонкостях. Если это требуется, то это дело приложения, использующего UDP. UDP используется для программ, которые посылают только короткие сообщения, и могут повторить передачу данных, если ответ задерживается, либо нечувствительны к потерям отдельных датаграмм. Кроме того, протокол TCP ориентирован на соединение «один к одному», и непригоден поэтому для посылки данных по схеме «один к многим», в этом случае также используется протокол UDP.

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

Высшие уровни модели OSI реализуются прикладными программами, и образуют уровень приложений. Сюда относятся и известные всем протоколы обмена гипертекстовой информацией HTTP, электронной почты POP3 и SMTP, пересылки файлов FTP. Сюда же относятся и менее известные, как протокол удаленного управления Telnet, либо остающиеся “в тени”, как протокол преобразования символьных имен в адреса DNS, и многие другие. Полный список протоколов этого уровня весьма обширен и все время пополняется.

Стандарты стека TCP/IP доступны в сети Internet как документы RFC (Request For Comments). Такое название обусловлено процедурой их принятия. Предложение в виде RFC размещается в Internet, обсуждается, уточняется, затем становится стандартом. Возможен, разумеется, и другой вариант – после обсуждения предложение отвергается и соответствующий RFC удаляется из Internet. В некоторых случаях, зависящих от руководящих органов Internet, RFC, хотя бы и ставшее стандартом de facto, не приобретает юридический статус стандарта Internet. Общее число RFC в настоящее время превышает 4000. Следует учесть, что хотя все стандарты TCP/IP являются RFC, не каждый RFC является стандартом TCP/IP. Часто RFC используются, например, для того, чтобы обратить внимание на какую-то проблему, не предлагая варианта ее разрешения. Список протоколов и соответствующих им RFC (неполный), по данным Семенова [8], приведен в приложении 3.
^ Протокол IP (Internet Protocol). Место протокола IP в иерархии протоколов сети Internet.
Сетевой протокол IP (Internet) создан для использования в объединенных системах компьютерных коммуникационных сетей с коммутацией пакетов.

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

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

Это обеспечивает гибкость протокола IP применительно к динамически меняющейся топологии сети (как мы помним, для таких сетей он изначально и создавался). Обратной стороной медали является относительная «прожорливость» протокола IP по вычислительным затратам маршрутизаторов, чему также способствует гибкость системы IP-адресации. По этой причине, хотя формирование стека протоколов TCP/IP было вчерне завершено к началу 80-х годов, и с этого времени началось его внедрение, прошло еще около 10 лет, пока он вышел на лидирующее положение по темпам ввода новых сетей и узлов, и около 15 лет, пока он стал лидером по абсолютному количеству узлов/сетей2.

Например, модуль TCP вызывает модуль IP с тем, чтобы получить сегмент TCP (включая заголовок TCP и данные пользователя) как информационную часть IP пакета. Модуль TCP обеспечивает адреса и другие параметры в заголовке модуля IP в качестве параметров рассматриваемого вызова. Модуль IP в этом случае создает пакет IP и прибегает к услугам локальной сети для передачи пакета IP. Обнаруженные ошибки и реакция на них обеспечиваются посредством протокола ICMP (Internet Control Message Protocol).

Протокол IP выполняет две главные функции: адресацию и фрагментацию.

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

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

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

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

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

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

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

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

Оригинальная версия спецификации IP-протокола (версия 4) – документ RFC-791 размещается на сервере ISI (Information Sciences Institute):

URL = http://info.internet.isi.edu/in-notes/rfc/files/rfc791.txt
^ Структура IP-пакета


Ver (Version) (версия) 4 бита

Поле версии показывает формат заголовка IP. В настоящее время используется 4 версия, и соответствующее поле содержит значение 4.
^ Hlen, IHL (длина IP заголовка) 4 бита
Длина IP заголовка измеряется в словах по 32 бита (4 байта) каждое и указывает на начало поля данных. Заметим, что корректный заголовок может иметь минимальный размер 5 слов. Максимальный определяется разрядностью поля длины и составляет, следовательно, 15 слов, то есть 60 байт.

^ Type of Service (тип сервиса) 8 бит

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

Что касается особенностей обслуживания, здесь выбор осуществляется между тремя альтернативами: малой задержкой, высокой достоверностью и высокой пропускной способностью. С начала 90-х годов была добавлена четвертая – минимальная цена.

биты 0–2 приоритет

бит 3 0 – нормальная задержка, 1 – малая задержка

бит 4 0 – нормальная пропускная способность, 1 – высокая пропускная способность.

бит 5 0 – обычная достоверность, 1 – высокая достоверность

биты 6–7 согласно RFC-791 зарезервированы, впоследствии бит 6 используется как признак оптимизации по стоимости 0 – обычная стоимость, 1 – малая стоимость. Для бита 7 предлагалось 0 – обычная безопасность, 1 – максимальная безопасность.

Приоритет

111 (7) – управление сетью. Значение "управление сетью" следует присваивать приоритету только для использования внутри локальной сети. Управление и реальное использование этого аргумента должно находиться в согласии с каждой применяющей его сетью.

110 (6) – межсетевое управление. Предназначен только для использования маршрутизаторами (шлюзами), берущими на себя управление.

101 (5) - CRITIC/ECP

100 (4) – более, чем мгновенно

011 (3) – мгновенно

010 (2) – немедленно

001 (1) – приоритетно

000 (0) – обычный приоритет

Использование индикации задержки, пропускной способности, достоверности и стоимости может, в некотором смысле, увеличить затраты на обслуживание. В частности, очевидно, что для того, чтобы выбирать маршруты с учетом заявленных требований, маршрутизатор должен вести не одну, а 4 таблицы маршрутизации – по одной на каждый тип сервиса (и, возможно, пятую – на случай, когда ни один признак не установлен). В большинстве сетей улучшение одного из этих параметров связано с ухудшением другого или других. Исключения, когда имело бы смысл устанавливать два из этих четырех признаков, очень редки. Первым протоколом динамической маршрутизации, поддерживающим метрики для типов сервиса, был OSPF, разработанный в 1991 году – и это при том, что первые 3 типа сервиса заявлены RFC-791 уже в 1980 году!

Тип обслуживания используется для указания типа обработки пакета при ее прохождении через систему Internet. Примеры отображения типа обслуживания в протоколе Internet на реальные услуги, предоставляемые такими сетями, как AUTODIN II, ARPANET, SATNET и PRNET даны в документе "Service Mapping".

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

^ Length, Total Length (общая длина) 16 бит

Общая длина – это длина пакета, измеренная в байтах, включая IP заголовок и поле данных. Это поле может задавать длину пакета вплоть до 65535 байтов. В большинстве хост-компьютеров и сетей столь большие пакеты не используются. Все хосты должны быть готовы принимать пакет вплоть до 576 байтов длиной (приходят ли они целиком или по фрагментам). Хостам рекомендуется отправлять пакеты размером более чем 576 байтов, только если они уверены, что принимающий хост готов обслуживать пакеты повышенного размера. Для большинства сетевых технологий общая длина пакета может быть получена от канального уровня, так что это поле выглядит избыточным. Увы, это не совсем так. Некоторые сетевые технологии, в том числе такая распространенная, как Ethernet, ограничивают минимальную длину кадра, и, как ни мало это ограничение (46 байт данных для Ethernet), IP-пакет может оказаться еще меньше. В этом случае без поля длины невозможно установить, где кончается пакет и начинается заполнение.

Identification (идентификатор) 16 бит

Идентификатор устанавливается отправителем для сборки фрагментов какого-либо пакета. Все фрагменты одного исходного пакета будут иметь один и тот же идентификатор.

^ Flags (различные управляющие флаги) 16 бит

бит 0 зарезервирован, должен быть нуль

бит 1 (DF) 0 – разрешена фрагментация, 1 – запрет фрагментации

бит 2 (^ MF) 0 – последний фрагмент, 1 – будут еще фрагменты

Fragment Offset (смещение фрагмента) 13 бит. Это поле показывает, где в исходном пакете находится этот фрагмент. Смещение фрагмента изменяется порциями по 8 байт (64 бита). Первый фрагмент имеет смещение нуль.

Time to Live (Время жизни) 8 бит

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

Protocol (Протокол) 8 бит

Это поле показывает, какой протокол следующего уровня использует данные из IP пакета. Значения для различных протоколов приводятся в документе "Assigned Numbers"

^ Header Checksum (Контрольная сумма заголовка) 16 бит

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

Алгоритм расчета контрольной суммы следующий:

Поле контрольной суммы – это 16 бит, дополняющие биты в сумме всех 16-битовых слов заголовка. Для вычисления контрольной суммы значение этого поля устанавливается в нуль3. При расчете контрольной суммы сложение понимается в смысле циклического сложения (возникающий перенос складывается с младшим битом суммы). Таков же алгоритм расчета контрольных сумм протоколов TCP, UDP, ICMP, IGMP (см. далее). В отличии от IP, в этих протоколах контрольная сумма защищает и заголовок, и данные. Для протокола UDP расчет контрольной суммы может не выполняться, для остальных он обязателен. Несмотря на то, что уже в спецификации RFC-791 предполагалось со временем заменить контрольную сумму циклической контрольной последовательностью (CRC), это так и не было осуществлено. Контрольная сумма – еще одна дань универсальности протокола IP. Большинство базовых сетевых технологий проверяют целостность кадра канального уровня более эффективным способом, в этом случае механизм контрольной суммы избыточен. Но «большинство» – увы, еще не значит «все»!

^ Source Address (адрес отправителя) 32 бита

Destination Address (адрес получателя) 32 бита

Options (опции) поле переменной длины

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

- единичный байт с указанием типа опции

единичный байт с указанием типа опции, байт для указания длины опции, и, наконец, байты собственно данных.

Байт длины поля учитывает байт типа опции, сам себя и байты с данными для опции.

Байт типа опции состоит из трех полей:

1 бит флаг копирования

2 бита класс опции

5 бит номер опции

^ Флаг копирования показывает, что эта опция копируется во все фрагменты при фрагментации (0 – не копируется, 1 – копируется).

Класс опции

0 – управление

1 – зарезервировано

2 – отладка и измерения

3 – резервировано

Определены следующие опции Internet

Класс

номер

длина

Описание

0

0

1

Конец списка опций. Эта опция обозначает конец списка опций. Необходима только в том случае, если конец списка опций не совпал с окончанием IP заголовка.

0

1

1

Нет операции. Используется для выравнивания.

0

2

11

Безопасность. Используется для поддержания безопасности, изоляции, разделения на группы пользователей (TCC), обработки кодов ограничения, соответствующих требованиям DOD(МО) США.

0

3

перем. (байт-указатель+список IP-адресов)

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

0

9

перем. (то же)

Определение маршрута отправителя. Используется для передачи IP пакета, основанной на имеющейся у отправителя информации. Точный маршрут.

0

7

перем. (то же)

Запись маршрута. Используется для отслеживания проходимого IP пакетом маршрута.

0

8

4

Идентификатор маршрута. Используется для поддержки идентификации потока.

2

4

перем

Временной штамп Internet.

В целом механизм опций протокола IP был признан неудачным, и в версии IP v.6 заменен механизмом дополнительных заголовков.
^ Адресация в IP-протоколе
Отправителей и получателей на уровне хост-компьютера отличают IP адреса, а также поле протокола. Предполагается, что каждый протокол будет определять, есть ли нужда в дополнительном мультиплексировании на хосте, и, при необходимости, обеспечивать его. Протоколы TCP и UDP в этом случае используют 16-битный номер порта (port).

Чтобы обеспечить гибкость в присвоении адресов компьютерным сетям и позволить применение большого количества малых и средних сетей, поле адреса кодируется таким образом, чтобы определять малое количество сетей с большим количеством хостов, среднее количество сетей со средним количеством хостов и большое колич