что обеспечивает протокол tcp
Sysadminium
База знаний системного администратора
Транспортный протокол TCP
Протокол TCP является одним из важнейших протоколов связи в компьютерных сетях. В этой статье познакомимся с ним поближе.
Что такое транспортные протоколы
Транспортные протоколы (TCP и UDP) используются для передачи информации. Информация передаётся маленькими частями – сетевыми пакетами. То есть поток информации разбивается на много маленьких пакетов.
Каждый пакет состоит из заголовка и самих данных. Заголовок содержит служебную информацию, например порт источника и назначения.
Особенности TCP
Главной особенностью TCP (Transmission Control Protocol) является то, что он гарантирует доставку всех отправленных пакетов. При этом проверяется целостность пакетов и их порядок. Если пакет потерялся или испортился, то получатель запросит эти пакеты у отправителя снова. Если пакеты пришли не в том порядке, то они на принимающей стороне всё равно обработаются в правильном. Этот механизм контроля доставки накладывает дополнительную нагрузку в виде увеличения служебной информации, которую нужно передать вместе с полезными данными.
TCP делит поток информации на сегменты. В одном сегменте может быть несколько пакетов. Каждый сегмент проверяется на целостность, и если все хорошо, отправляется подтверждение передающей стороне. Таким образом подтверждается не каждый пакет, а каждый сегмент, но в сегменте может оказаться и всего лишь один пакет.
Поверх протокола TCP работают многие прикладные протоколы:
TCP пакеты передаются не просто так, а в рамках установленного соединения – которое называют TCP сессией.
Подключение можно выполнить только если вторая сторона прослушивает порт, к которому будет выполняться подключение.
Алгоритм работы TCP
Алгоритм работы TCP следующий:
При открытии даже одной веб странички создаются несколько TCP соединений для:
И для каждого такого соединения вначале устанавливается сеанс, что замедляет передачу данных.
Заголовок TCP пакета
Заголовок TCP пакета состоит из следующих полей:
Флаги в заголовке TCP
Создание TCP сессии
Для установления соединения использует трехкратное рукопожатие.
Первый этап. Клиент отправляет на сервер пакет с флагом SYN. При этом клиент устанавливает порядковый номер сегмента на случайное значение A.
Второй этап. В ответ сервер отвечает пакетом с флагами SYN и ACK. Номер подтверждения установлен на единицу больше принятого (A+1). Поскольку сервер также будет отправлять данные, то для себя он тоже выбирает номер первого пакета, который будет другим случайным числом B.
Третий этап. Клиент отправляет ACK на сервер. Порядковый номер устанавливается равным A+1, а номер подтверждения устанавливается на B+1.
На этом этапе клиент и сервер получили подтверждение соединения и образовали двухстороннюю связь.
Передача данных в TCP
Теперь разберём пример передачи данных в уже установленном сеансе.
Клиент отравляет запрос к серверу. Поскольку данные поместились в один пакет TCP, он получил флаг PSH, чтобы сервер не ждал продолжение получения данных. При этом пакет получил 2 флага: ACK (подтвердил предыдущею передачу пакетов от сервера) и PSH.
В ответ на это сервер отправляет пакет ACK с номером успешно полученных данных.
Далее сервер обработал запрос и отправляет данные клиенту. Эти данные делятся на пакеты и отправляются сегментами.
Далее клиент подтверждает, что данные получены отправляя пакеты с флагом ACK.
Завершение сеанса TCP
Завершение сеанса использует четырёхкратное рукопожатие, причём каждая сторона завершает своё соединение независимо.
Когда одна из сторон хочет остановить свою половину соединения, она передаёт пакет FIN, который другая сторона подтверждает пакетом с ACK.
После того, как сторона, отправившая первый FIN, ответила с последним ACK, она ожидает некоторое время прежде чем окончательно закрыть соединение. В течение этого времени локальный порт недоступен для новых соединений.
Соединение может быть «полуоткрытым», и в этом случае одна сторона завершила свою часть, а другая — нет. Завершившая сторона больше не может отправлять какие-либо данные, но другая сторона может. Завершающая сторона должна продолжить чтение данных, пока другая сторона также не завершит свою работу.
Также возможно разорвать соединение трёхкратным рукопожатием, когда первая сторона отправляет FIN, а вторая отвечает FIN и ACK (просто объединяет 2 шага в один). Дальше первая сторона подтверждает завершение сеанса с помощью ACK.
Состояния сеанса TCP
Сеанс TCP может находится в следующих состояниях:
Вот мы и познакомились с одним из самых важных протоколов сети Интернет. Разобрались с его особенностями, алгоритмом работы. Узнали про сеансы TCP, пакеты и сегменты.
Протокол TCP
Что такое протокол TCP?
В отличие от протокола UDP гарантирует целостность передаваемых данных и подтверждения отправителя о результатах передачи. Используется при передаче файлов, где потеря одного пакета может привести к искажению всего файла.
TCP обеспечивает свою надежность благодаря следующему:
Заголовок TCP
Рассмотрим структуру заголовка TCP с помощью сетевого анализатора Wireshark:
TCP порты
Так как на одном и том же компьютере могут быть запущены несколько программ, то для доставки TCP-пакета конкретной программе, используется уникальный идентификатор каждой программы или номер порта.
Номер порта — это условное 16-битное число от 1 до 65535, указывающее, какой программе предназначается пакет.
TCP порты используют определенный порт программы для доставки данных, передаваемых с помощью протокола управления передачей (TCP). TCP порты являются более сложными и работают иначе, чем порты UDP. В то время как порт UDP работает как одиночная очередь сообщений и как точка входа для UDP-соединения, окончательной точкой входа для всех соединений TCP является уникальное соединение. Каждое соединение TCP однозначно идентифицируется двумя точками входа.
Каждый отдельный порт сервера TCP может предложить общий доступ к нескольким соединениям, потому что все TCP соединения идентифицируются двумя значениями: IP-адресом и TCP портом (сокет).
Номера портов UDP и TCP не пересекаются.
TCP программы используют зарезервированные или хорошо известные номера портов, как показано на следующем рисунке.
Установление соединения TCP
Давайте теперь посмотрим, как устанавливается TCP-соединения. Предположим, что процесс, работающий на одном хосте, хочет установить соединение с другим процессом на другом хосте. Напомним, что хост, который инициирует соединение называется «клиентом», в то время как другой узел называется «сервером».
Перед началом передачи каких-либо данных, согласно протоколу TCP, стороны должны установить соединение. Соединение устанавливается в три этапа (процесс «трёхкратного рукопожатия» TCP).
После установления соединения TCP, эти два хоста могут передавать данные друг другу, так как TCP-соединение является полнодуплексным, они могут передавать данные одновременно.
TCP протокол — что это такое, понятным языком
Каждый из нас знает, что по интернету можно передавать различные данные: голосовые сообщения, видео, документы, различные файлы и многое другое, но не все знают, как же это происходит.
А происходит это все посредством особого набора/стеку правил — TCP/IP, благодаря которому и работает интернет. Он включает в себя протоколы, каждый из которых ответственен за определенную функцию в сети.
Прошлый материал был, как раз посвящен TCP IP, сегодня же мы разберем за что отвечает протокол TCP и что это вообще такое.
TCP протокол
TCP — это транспортный протокол, является частью стека протоколов TCP IP, он выполняет функции управления передачей данных и следит за их сохранностью, считается надежным. Расшифровывается как Transmission Control Protocol (протокол управления передачей).
Это стандарт, который определяет как нужно устанавливать связь и поддерживать ее, чтобы две программы могли обмениваться данными между собой.
Интересно! Существует еще один транспортный протокол UDP, о нем мы поговорим в следующей отдельной статье, там же и разберем, чем они вообще отличаются друг от друга.
Является именно надежным протоколом так как:
1. Использует логическое соединение, благодаря чему обеспечивается надежная доставка данных.
2. Пронумеровывает передаваемые пакеты данных и проверяет их доставку, принимающая сторона высылает подтверждение о получении, в случае потери каких-либо пакетов создается повторная передача.
3. Делит передаваемые данные на части — пакеты данных, затем передает их нижнему уровню, и собирает их, когда они приходят к получателю.
4. Проверяет контрольную сумму передаваемых пакетов, если она отличается — создается новая отправка.
5. Проверяет пакеты на дубликаты, в случае обнаружения таковых — уничтожает.
6. Контролирует скорость передачи.
Заголовок TCP протокола
Весит 20 байт, если нет дополнительных опций, вот как он выглядит:
У каждого TCP сегмента указывается порт источника и назначения, с помощью которых происходит идентификация отправляющего и принимающего приложения. Эти порты вместе с IP адресами уникально идентифицируют каждое соединение. Комбинация IP и порта — это сокет (socket).
Номер последовательности — нумерация каждого отправляемого байта в потоке передаваемых данных. А номер подтверждения — это следующий номер байта после полученного, который ждет получатель. Т.е. передача идет последовательно, например, получатель получил 100-ый байт, следующим ждет 101.
Остальные значения можно понять из самой картинки. Разве, что размер окна — он скользящий, т.е. зависит от качества сети. Если много данных теряется он может уменьшаться и наоборот. Он регулирует количество передаваемых байтов.
А флаги: URG, ACK, PSH и т.д. — описывают дополнительные значения сегмента, так, например, флаг FIN применяется для завершения соединения.
Также, вам может быть интересна статья о том, что такое dns сервер. В ней очень подробно и интересно описано об этой глобальной системе.
Как работает TCP соединение
Соединение отправителя и получателя (два узла) происходит так:
1. Отправитель отсылает получателю специальный пакет, именуемый SYN, т.е. пригашает к соединению
2. Получатель отвечает уже пакетом SYN-ACK, т.е. соглашается
3. Отправитель отсылает спец. пакет ACK, т.е. подтверждает, что согласие получено
На этом TCP-соединение успешно установлено и получатель с отправителем могут спокойно обмениваться информацией. При передаче все пакеты данных нумеруются, отсылаются подтверждения о получении каждого из них, а потерянные пересылаются заново.
TCP порты
На каждом компьютере установлено, как минимум несколько программ. И сразу несколько из них могут обмениваться информацией, как же их различать? Именно для этого и были придуманы TCP порты, это по сути уникальный идентификатор соединения между двумя программами.
Номер порта — это число от 0 до 65535 в 16 битном формате, оно указывает какому именно приложению предназначается определенный пакет данных. Т.е. позволяет различным программам, работающим на одном компьютере, независимо друг от друга отправлять и получать информацию.
Есть целый ряд уже зарезервированных портов, которые являются стандартом:
Также, стоит отметить, что порты данного протокола никак не пересекаются с такими же, но у UDP. Так, например, порт: 1234 не пересечется с таким же, но у UDP.
В заключение
Вот вы и узнали, что это такое, постарался написать, как можно более понятно, без лишних терминов. Главное знать, как это работает и серфинг в интернете станет еще куда интереснее.
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
TCP/IP (Transmission Control Protocol/Internet Protocol)
Содержание
Стек протоколов ТСР/IP
IP-сеть
Транспортный уровень стека TCP/IP
Межсетевой уровень стека TCP/IP
Пример переноса данных в IP-сети
Как видно из предыдущих глав, глобальные сети Frame Relay и АТМ имеют различные системы нумерации, которые отличаются от системы нумерации локальной вычислительной сети (ЛВС) технологии Ethernet. Каждый компьютер Ethernet имеет уникальный физический адрес, состоящий из 48 бит. Этот адрес называется МАС-адресом и относится к канальному уровню — управлению доступом к среде MAC (Media Access Control). Для организации межсетевого взаимодействия подсетей различной технологии и адресации используются маршрутизаторы, включающие IP-пакеты. В состав этих пакетов входят глобальные IP-адреса. Каждый интерфейс маршрутизатора IP-сети и оконечного устройства включает два адреса – локальный адрес оконечного устройства подсети и IP-адрес.
Рассмотрим продвижение IP-пакета в сети (рис. 2).
Протоколы TCP/IP
Ниже приводится краткое описание протокола прикладного уровня SNMP и протокола транспортного уровня TCP архитектуры TCP/IP.
Протокол прикладного уровня SNMP
SNMP может управлять конфигурацией сети. Для сети FR это касается как физической, так и логической конфигурации сети, включая установление адресации, определение DLCI, назначение полосы пропускания для PVC. SNMP может управлять устранением неисправностей в сети при получении системой управления аварийных сообщений от агента сетевого устройства.
Обеспечение информационной безопасности протокола SNMP
В документе RFC 2574 [6] определяется модель USM (User Security Model – модель защиты пользователя) при использовании протокола SNMP. USM разрабатывалась с целью защиты от угроз следующих типов.
Протокол транспортного уровня TCP
Протокол транспортного уровня TCP выполняет функцию управления потоками между оконечными пунктами, так как уровень IP не гарантирует правильной доставки дейтаграмм. Дейтаграммы с уровня IP могут прибывать в неправильном порядке. Восстанавливает сообщения из таких дейтаграмм протокол TCP, обеспечивая этим надежный режим установленного соединения с низкой вероятностью потери пакета. Механизм управления потоками, используемый ТСP, отличается от механизма восстановления правильной последовательности кадров в Х.25 и называется схемой кредитов. В этой схеме считается, что каждый передаваемый байт данных имеет порядковый номер. Границы между сообщениями не сохраняются. Например, если отправляющий прикладной процесс записывает в ТСP-поток четыре 512-байтовые порции данных, эти данные могут быть доставлены получающему процессу в виде четырех 512-байтовых порций, либо двух 1024-байтовых порций, либо одной 2048-байтовой порции. Каждая протокольная единица PDU TCP называется сегментом TCP и включает в заголовок сегмента порт источника данных и порт получателя. Значения портов идентифицируют соответствующих пользователей (приложения) двух объектов TCP.
Логическая связь относится именно к данной паре значения портов. В процессе связи каждый объект отслеживает сегменты TCP, получаемые от другой стороны или отправленные другой стороне, для того, чтобы регулировать поток сегментов и восстанавливать утерянные или поврежденные сегменты. Стандартный номер порта однозначно идентифицирует тип приложения, однако он не может однозначно идентифицировать прикладной процесс этого приложения. Одно приложение может одновременно осуществлять несколько процессов. Поэтому прикладной процесс однозначно определяется в пределах сети и в пределах отдельного компьютера парой (IP-адрес, номер порта) и называется сокетом (socket). Логическое TCP-соединение однозначно идентифицируется парой сокетов, определенных для этого соединения двумя взаимодействующими сокетами.
При работе на хост-отправителе протокол TCP рассматривает информацию, поступающую к нему от уровня приложений, как неструктурированный поток байтов. Эти данные буферируются средствами TCP. На уровень IP из буфера «вырезаются» сегменты, к которым добавляются заголовки. В состав заголовка входят сегменты SYN и ACK, служащие для установления TCP-соединения.
Для передачи сегмента данных имеются три поля, связанные с управлением потоком (восстановлением целостности принятого сообщения): порядковый номер (SN), номер подтверждения (AN) и окно (W).Когда транспортный объект отправляет сегмент, он помещает в поле данных сегмента порядковый номер первого байта. Принимающий объект подтверждает получение сегмента с помощью обратного сегмента, в котором (АN=i, W=j), что означает:
Таким образом, протокол TCP обеспечивает надежную доставку сообщений, поступающих из сети от ненадежного дейтаграммного протокола на межсетевом уровне. В сети Х.25 функцию надежной доставки выполняет канальный уровень модели OSI, который был подробно рассмотрен в предыдущих главах, а в сети Frame Relay эту функцию выполняет протокол ITU-T Q.921.
Протоколы сетевого взаимодействия TCP/IP
Содержание
Литература
Введение
Протоколы сетевого взаимодействия TCP/IP являются результатом эволюционного развития протоколов глобальной вычислительной сети ARPANET.
Работы по созданию сети ARPANET были начаты рядом университетов США и фирмой BBN в 1968 г. В 1971 г. сеть была введена в регулярную эксплуатацию и обеспечивала для всех своих узлов три основные услуги:
Все эти средства базировались на транспортных услугах предоставляемых программой управления сети NCP (Network Control Program), реализующей свой внутренний набор протоколов.
Накопленный к 1974 г. опыт эксплуатации сети ARPANET выявил многие недостатки протоколов NCP и позволил определить основные требования к новому набору протоколов, получившему название TCP/IP:
Широко используемая ныне версия 4 протоколов TCP/IP была стандартизирована в 1981 г. в виде документов, называемых RFC (Request For Comment). Полный переход сети ARPANET на новые протоколы был завершен в 1982 г. Эта сеть сыграла роль «зародыша» всемирной сети Internet, построенной на базе протоколов TCP/IP.
Реализация протоколов TCP/IP оказалась наиболее удачной в версиях BSD4.2 и BSD4.3 операционной системы UNIX. Эта реализация является эталоном (станартом «de facto») для всех последующих.
Примечание. Первичным сервером хранения всех RFC является узел nisc.sri.com (доступ через анонимный FTP).
1. Соотношение между OSI/ISO и TCP/IP
В 1984 г. международная стандартизирующая организация ISO предложила модель взаимодействия открытых систем OSI (Open System Interconnection), являющуюся удобным средством описания стеков протоколов.
На рис. 1.1 представлено соотношение четырехуровневой архитектуры протоколов TCP/IP и семиуровневой архитектуры OSI.
Согласно терминологии TCP/IP элементы сетевого уровня называются подсетями (subnetworks). Идеология TCP/IP допускает, чтобы в качестве «подсетей» выступали реальные сети с их собственными стеками протоколов, узлами, шлюзами и т.п.
Внимание. Далее в данном учебном пособии для обозначения уровней стека протоколов используется терминология TCP/IP, а не OSI/ISO (если это не оговорено особо).
Внимание. В данном учебном пособии термин «шлюз» используется как обобщающий для понятий «маршрутизатор» (router), «мост» (bridge) и, собственно, «шлюз» (gateway).
2. Архитектура протоколов TCP/IP
На рис. 2.1 представлена архитектура основных протоколов TCP/IP, используемых на трех нижних уровнях стека.
Краеугольным камнем всей архитектуры является межсетевой протокол IP ( Internet Protocol ). С его помощью реализуется адресация узлов сети и доставка данных. Межсетевой протокол управляющих сообщений ICMP ( Internet Control Message Protocol ) предназначен для передачи диагностической информации и сообщений об ошибках в работе сети.
Примечание. Протокол ICMP отнесен к межсетевому уровню условно, т.к., с одной стороны, он пользуется возможностями протокола IP для транспортировки собственных данных, но, с другой стороны, сам для транспортировки данных пользователя не применяется.
Внимание. На каждом уровне стека протоколов TCP/IP обмен данными ведется блоками данных конечной длины. К сожалению, отсутствует устоявшаяся терминология в обозначении этих блоков. В данном учебном пособии названия блоков данных зависят от уровня стека протоколов, как это показано ниже.
3. Межсетевой протокол IP
Межсетевой протокол IP специфицирован в RFC 791. Его основные характеристики перечислены ниже:
3.1. Заголовок IP-сегмента
На рис. 3.1 приведен формат заголовка IP-сегмента.
4-хбитовое поле, содержащее номер версии протокола IP (номер текущей версии равен 4);
байт, содержащий набор критериев, определяющих тип обслуживания IP-сегментов. Детальное описание отдельных битов дано ниже:
На практике в большинстве реализаций протокола IP данное поле почти всегда равно 0, в UNIX-реализациях это поле не используется вовсе.
двухбайтовое поле, содержащее уникальный идентификатор IP-сегмента, присваиваемый ему посылающим узлом. Это поле используется для распознавания фрагментов одного IP-сегмента (в ситуациях, когда в ходе перемещения по глобальной сети единый IP-сегмент был разбит на несколько фрагментов по причине его недопустимо большой длины).
биты, используемые при обработке фрагментированных IP-сегментов.
Если бит DF (Don’t Fragment) установлен в 1, то это означает, что IP-сегмент не может быть разбит на фрагменты ни при каких условиях (даже, если он не может быть передан без этого далее к адресату и должен быть уничтожен).
Бит MF (More Fragments) указывает, является (MF=0) или нет (MF=1) данный IP-«подсегмент» последним в цепочке IP-«подсегментов», в которую был преобразован (фрагментирован) исходный IP-сегмент.
Алгоритм фрагментации описан ниже в разделе «Фрагментация IP-сегментов».
Каждый IP-модуль на любом узле сети обязан уничтожать IP-сегменты, для которых поле «время жизни» стало равным нулю. Этим предотвращается появление в сети IP-сегментов, «блуждающих» по ней бесконечное время. При этом узлу-источнику уничтоженного IP-сегмента посылается ICMP-сегмент, извещающий об этом событии.
В UNIX-реализациях, как правило, это поле заполняется источником IP-сегмента числом из диапазона 15. 30.
поле размером в байт, содержащее идентификатор протокола более высокого (обычно, транспортного) уровня, для которого предназначены данные IP-сегмента. Ниже приведены идентификаторы для ряда протоколов.
Контрольная сумма заголовка
Поскольку заголовок IP-сегмента содержит поле «время жизни», изменяющее свое значение в каждом узле, через который следует IP-сегмент, то для вычисления контрольной суммы должен использоваться эффективный (а, следовательно, простой алгоритм). Во всех протоколах, входящих в архитектуру TCP/IP, используется так называемая Internet-контрольная сумма, которая представляет собой дополнение 16-битной суммы всех 16-битных слов контролируемой информации.
Адрес источника и адрес приемника
четырехбайтовые IP-адреса узлов сети. Подробно структура IP-адреса описана ниже в «IP-адрес».
Дополнительные данные заголовка
последовательность полей произвольной длины, описывающих необязательные данные заголовка. Такие данные используются для специальных целей (управление сетью, секретность и т.п.) и кратко описаны ниже в «Дополнительные данные IP-заголовка».
не имеющие смысла данные, включаемые в заголовок только для выравнивания его длины до границы четырехбайтового слова.
3.2. IP-адрес
Сети классов A, B и C абсолютно равноправны и отличаются лишь допустимым количеством узлов в них. Идентификаторы узлов, состоящие из одних нулевых или единичных битов имеют специальный смысл:
Каждый узел в сети имеет, по крайней мере, один уникальный IP-адрес.
Класс D используется для организации многопунктового ( multicast ) режима посылки сообщений: IP-сегмент, посылаемый по по IP-адресу класса D, доставляется всем узлам сети, имеющим указанный идентификатор группы узлов. Описание данного режима дано в RFC 1112.
Примечание. Не все современные реализации протоколов TCP/IP поддерживают многопунктовое вещание.
Для обеспечения гибкости при создании и администрировании сетей различного размера в 1985 г. было введено понятие «подсеть» (RFC 950), позволяющее использовать один и тот же IP-адрес классов A,B или C для разных подсетей.
Эта сетевая маска формирует IP-адрес не из двух, а из трех комронент:
Каждая из четырех образованных подсетей может иметь до 62 узлов с идентификаторами от 1 до 62, идентификатор узла с номером 63 является широковещательным идентификатором для подсети.
Примечание. Для идентификатора подсети можно выделять только старшие (самые левые) биты из части IP-адреса, отводимой под идентификатор узла.
Примечание. Возможность разбиения сетей на подсети обусловливается, в первую очередь, средствами маршрутизации IP-сегментов, а не средствами IP-модулей, формирующих и обрабатывающих IP-сегменты.
Примечание. Некоторые современные реализации протоколов маршрутизации для TCP/IP позволяют выделять «подподсети» в подсетях.
3.3. Фрагментация IP-сегментов
Изменение размера IP-сегмента реализуется механизмом, называемым фрагментацией. IP-модуль на любом узле сети должен иметь возможность:
Каждый IP-фрагмент представляет собой полноценный IP-сегмент со своим собственным IP-заголовком. Однако заголовки всех IP-фрагментов содержат одинаковый идентификатор, совпадающий с идентификатором исходного IP-сегмента. Это позволяет распознавать все IP-фрагменты, относящиеся к одному исходному IP-сегменту.
IP-фрагменты в своих заголовках содержат поле «Смещение фрагмента», описывающее смещение данных IP-фрагмента в данных исходного IP-сегмента. Это поле позволяет корректно восстановить данные исходного IP-сегмента в принимающем IP-фрагменты узле даже в ситуации, когда IP-фрагменты приходят в порядке, от порядка их посылки (такое вполне возможно, т.к. IP-фрагменты могут следовать от источника к адресату по разным маршрутам).
Рассмотрим процесс фрагментации более подробно на следующем примере. IP-модуль на некотором узле получил IP-сегмент с идентификатором 9876 и данными длиной 300 байт (при этом бит запрета фрагментации DF установлен в 0). Этот IP-сегмент должен быть передан дальше к адресату через сеть, максимальный размер кадра которой равен 128 байтам.
Рис. 3.4 схематично представляет разбиение исходного IP-сегмента на 3 IP-фрагмента.
IP-фрагмент 1 содержит в своем заголовке следующую информацию:
IP-фрагмент 2 содержит в своем заголовке следующую информацию:
IP-фрагмент 3 содержит в своем заголовке следующую информацию:
IP-модуль на принимающем IP-фрагменты узле в ситуации, когда он должен транслировать IP-сегмент далее по сети, имеет три варианта действий с фрагментами:
В работе с IP-фрагментами на принимающей стороне используется специальный таймер, который с приходом первого фрагмента IP-сегмента устанавливается в исходное состояние (для UNIX-реализаций это, обычно, 30 сек) и начинает обратный счет. До момента обнуления таймера должны прийти все IP-фрагменты, относящиеся к этому сегменту. Если этого не произойдет, то все частично полученные данные IP-сегмента сбрасываются, а сам IP-сегмент считается утерянным.
3.4. Дополнительные данные IP-заголовка
Ниже кратко описываются дополнительные данные, которые могут включаться в IP-заголовок в случае необходимости.
список IP-адресов узлов сети, которые посетил IP-сегмент по пути к адресату. Каждый транзитный узел, через который следует IP-сегмент, помещает в этот список свой IP-адрес.
Временные метки (time stamp)
список моментов времени прохождения IP-сегмента через узлы сети, составляющие маршрут.
указание на обработку IP-сегмента в соответствии с требованиями безопасности (RFC 1038). Эта возможность имеется только в нескольких (военных) реализациях TCP/IP.
указание на завершение дополнительных данных IP-заголовка.
Каждый элемент дополнительных данных представляет собой
Для дополнительных данных, пополняемых в ходе продвижения IP-сегмента по сети (например, «пройденный маршрут»), источник IP-сегмента должен зарезервировать место необходимого объема в IP-заголовке. Такой подход обеспечивает упрощение (а, следовательно, и ускорение) обработки IP-сегмента в узлах маршрута.
4. Протокол управления передачей TCP
Его основные характеристики перечислены ниже:
Несмотря на то, что для пользователя передача данных с использованием протокола TCP выглядит как потоковая, на самом же деле обмен между партнерами осуществляется посредством пакетов данных, которые мы будем называть «TCP-пакетами».
4.1. Заголовок TCP-пакета
На рис. 4.1 приведен формат заголовка TCP-пакета.
Порт источника и порт приемника
16-битовые поля, содержащие номера портов, соответственно, источника и адресата TCP-пакета. Подробное описание понятия «номер порта» дано в «Номер порта».
Номер в последовательности (sequence number)
32-битовое поле, содержимое которого определяет (косвенно) положение данных TCP-пакета внутри исходящего потока данных, существующего в рамках текущего логического соединения.
Номер подтверждения (acknowledgement number)
32-битовое поле, содержимое которого определяет (косвенно) количество принятых данных из входящего потока к TCP-модулю, формирующему TCP-пакет.
четырехбитовое поле, содержащее длину заголовка TCP-пакета в 32-битовых словах и используемое для определения начала расположения данных в TCP-пакете.
бит, установленное в 1 значение которого означает, что TCP-пакет содержит важные (urgent) данные. Подробно о данных этого типа сказано в «Важные данные».
бит, установленное в 1 значение которого означает, что TCP-пакет содержит в поле «номер подтверждения» верные данные.
бит, установленное в 1 значение которого означает, что данные содержащиеся в TCP-пакете должны быть немедленно переданы прикладной программе, для которой они адресованы. Подтверждение для TCP-пакета, содержащего единичное значение во флаге PSH, означает, что и все предыдущие TCP-пакеты достигли адресата.
бит, установливаемый в 1 в TCP-пакете, отправляемом в ответ на получение неверного TCP-пакета. Также может означать запрос на переустановление логического соединения.
бит, установленное в 1 значение которого означает, что TCP-пакет представляет собой запрос на установление логического соединения. Получение пакета с установленым флагом SYN должно быть подтверждено принимающей стороной.
бит, установленное в 1 значение которого означает, что TCP-пакет представляет собой запрос на закрытие логического соединения и является признаком конца потока данных, передаваемых в этом направлении. Получение пакета с установленым флагом FIN должно быть подтверждено принимающей стороной.
16-битовое поле, содержащее Internet-контрольную сумму, подсчитанную для TCP-заголовка, данных пакета и псевдозаголовка. Псевдозаголовок включает в себя ряд полей IP-заголовка и имеет показанную на рис. 4.2 структуру.
16-битовое поле, содержащее указатель (в виде смещения) на первый байт в теле TCP-пакета, начинающий последовательность важных (urgent) данных. Данные этого типа и механизм их обработки описаны в «Важные данные».
Дополнительные данные заголовка
последовательность полей произвольной длины, описывающих необязательные данные заголовка. Протокол TCP определяет только три типа дополнительных данных заголовка:
Дополнительные данные последнего типа посылаются в TCP-заголовке в момент установления логического соединения для выражения готовности TCP-модулем принимать пакеты длиннее 536 байтов. В UNIX-реализациях длина пакета обычно определяется максимальной длиной IP-сегмента для сети.
4.2. Номер порта
Номера портов играют роль адресов транспортного уровня, идентифицируя на конкретных узлах сети, по сути дела, потребителей транспортных услуг, предоставляемых как протоколом TCP, так и протоколом UDP. При этом протоколы TCP и UDP имеют свои собственные адресные пространства: например, порт номер 513 для TCP не идентичен порту номер 513 для UDP.
Примечание. Своя собственная адресация на транспортном уровне стека протоколов сетевого взаимодействия необходима для обеспечения возможности функционирования на узле сети одновременно многих сетевых приложений. Наличие в TCP-заголовке номера порта позволяет TCP-модулю, получающему последовательности TCP-пакетов, формировать раздельные потоки данных к прикладным программам.
Для того, чтобы клиент мог обращаться к необходимому ему серверу, он должен знать номер порта, по которому сервер ожидает обращения к нему («слушает сеть»). Для прикладных программ, получивших наибольшее распространение в сетях на основе TCP/IP, номера портов фиксированы и носят название «хорошо известных номеров портов» (well-known port numbers). В UNIX-системах такие номера портов содержатся в файле /etc/services. Ниже приводятся примеры хорошо известных номеров портов для некоторых серверов (служб).
Примечание. Обратите внимание, что некоторые серверы (такие, например, как для службы portmap с номером порта 111) могут работать как по протоколу TCP, так и по протоколу UDP.
Программы-клиенты, являющиеся активной стороной во взаимодействии «клиент-сервер», могут использовать, как правило, произвольные номера портов, назначаемые динамически непосредственно перед обращением к серверу (как любые свободные на данном узле).
Примечание. Любая прикладная программа (будь то клиент или сервер) может открывать для взаимодействия любое количество портов для использования любых транспортных протоколов.
Средства разработки сетевых приложений на базе транспортных протоколов TCP и UDP описаны в «Сетевое программирование».
4.3. Принцип «скользящего окна»
Протоколы транспортного уровня, обеспечивающие надежную передачу данных, предполагают обязательное подтверждение принимающей стороной правильности полученных данных.
В «простых» протоколах сторона, отправляющая данные, отсылает пакет с данными принимающей стороне и переходит в состояние ожидания подтверждения получения правильных данных. Только после приема подтверждения становится возможной следующая посылка. Очевидно, что такой подход использует пропускную способность сети неэффективно.
Принцип «скользящего окна» обеспечивает «опережающую» посылку данных с «отложенным» их подтверждением. Следует отметить недостаток этого механизма: если в течение некоторого времени не будет получено «отсроченное» подтверждение ранее отправленного пакета, то отправляющий TCP-модуль будет вынужден повторить посылку всех TCP-пакетов, начиная с неподтвержденного.
Размер окна, как правило, определяется объемом свободного места в буферах принимающего TCP-модуля.
4.4. Важные данные
Протокол TCP предусматривает возможность информирования принимающей стороны взаимодействия отправляющей стороной о наличии в TCP-пакете важных данных ( urgent data ), требующих особого внимания согласно логике прикладной задачи.
Примечание. Отличие важных данных от данных основного потока заключается в том, что принимающая сторона должна, как правило, обработать их прежде ранее полученных, но еще не обработанных данных потока.
Примечание. Протокол TCP предусматривает передачу важных (urgent) данных в рамках общего потока данных («in-band»). Существуют протоколы (например, ISO), поддерживающие режим передачи важных (expedited) данных вне общего потока данных («out-band»), что в общем случае быстрее.
4.5. Этапы TCP-взаимодействия
Взаимодействие партнеров с использованием протокола TCP строится в три этапа:
Ниже с помощью трех рисунков дается описание каждого из этапов. Рисунки иллюстрируют последовательность обмена TCP-пакетами двумя TCP-модулями: A и B. TCP-пакеты представлены тремя полями TCP-заголовка («Номер в последовательности», «Номер подтверждения», «Флаги») и числом, характеризующим длину данных, составляющих тело TCP-пакета (заметим, что реально поля длины данных в TCP-заголовке нет). Стрелками показаны направления пересылки пакетов.
Рис. 4.4 иллюстрирует этап установления соединения, реализуемый как «трехшаговое рукопожатие» (three-way handshake). На первом шаге TCP-модуль A, играя роль клиента, посылает TCP-модулю B пакет с установленным флагом SYN и начальным значением номера в последовательности равным 1000. TCP-модуль B, будучи готов со своей стороны установить соединение, отвечает TCP-пакетом, подтверждающим правильный прием запроса (поле «Номер подтверждения» на 1 больше начального номера в последовательности для TCP-модуля A и среди флагов есть установленный в 1 флаг ACK) и информирующим о готовности установить соединение (взведен флаг SYN и установлен в 5000 начальный номер в последовательности). На третьем шаге TCP-модуль A подтверждает правильность приема TCP-пакета от B.
Примечание. Некоторые протоколы транспортного уровня (но не TCP) допускают обмен данными уже на этапе установления логического соединения.
Рис. 4.5 иллюстрирует этап двустороннего обмена данными между TCP-модулями A и B. TCP-модуль, принимающий адресованные ему данные, всегда подтверждает их прием, вычисляя значение поля «Номер подтверждения» в заголовке ответного TCP-пакета как сумму пришедшего «Номера в последовательности» и длины правильно принятых данных. Отметим, что посылка данных к партнеру и подтверждение принятых от него данных реализуются в рамках одного TCP-пакета.
Рис. 4.6 иллюстрирует закрытие соединения по инициативе TCP-модуля A, посылающего партнеру TCP-пакет с установленным флагом FIN. Прием запроса на закрытие соединения TCP-модуль B подтверждает пакетом, содержащем в своем заголовке поле «Номер подтверждения», значение которого (1052) на 1 больше значения принятого «Номера в последовательности» (1051). После этого посылка каких-либо данных TCP-модулем A становится невозможной, однако модуль B имеет данные для передачи, которые он отправляет TCP-модулю A и получает подтверждение на их прием. Затем TCP-модуль B формирует пакет с флагом FIN, после подтверждения его приема соединение считается закрытым.
Примечание. Обратите внимание на то обстоятельство, что при подтверждении TCP-пакетов, содержащих единичные флаги SYN или FIN, значение поля «Номер подтверждения» на 1 больше значения соответствующего поля «Номер в последовательности», несмотря на то, что никакие данные в подтверждаемых TCP-пакетах не передаются.
Примечание. Рассмотренный пример не включает в себя ситуации, связанные с «потерей» TCP-пакетов в сети, и их обработку, связанную с повторной передачей данных.
4.6. Таймеры
4.6.1. Таймер повторной передачи
Ясно, что величина RTO не может быть фиксированной, т.к. TCP-пакеты до разных адресатов следуют по различным маршрутам через сети, скорость передачи данных в которых может различаться более чем в тысячи раз. Для вычисления «оптимального» значения RTO в каждом логическом соединении используется специальная процедура, специфицированная в RFC 793.
Примечание. Приведенная формула обеспечивает фильтрацию нетипичных (пиковых) значений измеренной величины RTT.
«Оптимальное» значение RTO вычисляется по формуле:
Если после повторной посылки TCP-пакета, опять не будет получено его подтверждение за интервал времени RTO, то попытки послать TCP-пакеты будут повторены (до 12 раз), но каждый раз с экспоненциально возрастающим значением RTO. Только после неудачи всей серии повторных посылок связь между партнерами будет считаться аварийно закрытой.
4.6.2. Таймер возобновления передачи
В ходе взаимодействия двух TCP-модулей ( A и B ) вполне возможна следующая ситуация:
4.6.3. Таймер закрытия связи
Протокол TCP предусматривает следующий простой прием предотвращения появления в сети TCP-пакетов, не имеющих адресатов: после закрытия логического соединения между партнерами номера портов, использовавшихся в этом соединении, остаются еще некоторый интервал времени действительными, что дает возможность долго блуждавшим по сети TCP-пакетам добраться до места назначения (где они будут просто проигнорированы). Величина этого интервала равна удвоенному времени жизни IP-сегмента (обычно, 2*15=30 секунд).
Примечание. Пользователи ОС UNIX могут почувствовать эффект от использования этого приема, попытавшись перезапустить некоторую прикладную программу, использующую TCP, сразу же после ее завершения.
4.6.4. Таймеры поддержки соединения
Ниже описывается механизм, используемый для проверки ненарушенности логического соединения между TCP-модулями.
Каждый TCP-модуль, участвующий в логическом соединении, через фиксированный промежуток времени ( keep-alive timer ), равный обычно 45 секундам, периодически отправляет партнеру пустые (не содержащие данных) TCP-пакеты и ждет их подтверждения. Каждое полученное подтверждение говорит о ненарушенности соединения. Если же в течении определенного интервала времени ( idle timer ), равного обычно 360 секудам, не будет получено ни одного подтверждения, то логическое соединение считается оборванным.
Примечание. Очевидно, что данный механизм имеет смысл включать в работу только тогда, когда партнеры по TCP-взаимодействию приостановили по какой-либо причине обмен данных на достаточно длительный срок (более 45 секунд).
Примечание. Стандартная спецификация протокола TCP не включает в себя описанный механизм, однако он реализован во всех UNIX-системах.
4.7. Алгоритмы повышения эффективности
Ниже описываются некоторые алгоритмы, используемые для повышения эффективности взаимодействия по протоколу TCP в UNIX-реализациях и не являющиеся частью спецификации TCP.
4.7.1. Задержка подтверждения
Задержка отсылки подтверждения принятого пакета используется для сокращения числа TCP-пакетов, которыми обмениваются партнеры по взаимодействию. Поясним эффект от такой задержки следующим примером.
В ситуации без задержки TCP-модуль на стороне сервера, приняв пакет с данными и разместив их в своем буфере, сразу же отвечает подтверждающим пакетом, содержащим в своем заголовке и некоторый (уменьшенный) размер окна для приема последующих данных. Спустя некоторое (обычно, очень короткое) время данные из буфера передаются серверной части прикладной программы. Освобождение места в буфере заставляет TCP-модуль отправлять партнеру на стороне клиента TCP-пакет с новым (увеличившимся) размером окна. Тем временем прикладная программа, обработав полученные данные (часто за небольшое время), передает результат TCP-модулю для отсылки его клиенту, для чего модуль формирует еще один пакет. Итого: одна транзакция потребовала от TCP-модуля на стороне сервера посылки трех TCP-пакетов.
Введение же задержки при отсылке подтверждающего TCP-пакета позволяет в ряде случаев уменьшить количество пакетов с трех до одного, содержащего сразу подтверждение, новый размер окна и результирующие данные. Экспериментальные исследования показали, что во многих случаях «оптимальным» значением задержки является 0.2 секунды.
Для того, чтобы введение задержки сказывалось минимальным образом на приложения, предъявляющие жесткие требования к пропускной способности сети, задержка устанавливается нулевой при условии, что размер окна изменяется более чем на 35% или (в абсолютном исчислении) на удвоенный максимальный размер TCP-пакета.
4.7.2. Исключение малых окон
Во избежание деградации сети вследствие описанного явления используется следующий прием: TCP-пакет, информирующий посылающую данные сторону об увеличении размера окна, формируется только при выполнении одного из двух условий:
Кроме того TCP-модуль, отправляющий данные, должен делать это большими порциями.
4.7.3. Исключение коротких TCP-пакетов
Для борьбы с этим используется следующий прием:
Однако этот подход может сказаться на быстродействии некоторых приложений, чтобы избежать этого прикладной программе предоставляются средства для принудительного «выталкивания» буферизованных данных в необходимых случаях. Кроме того, существует возможность отключения описанного механизма.
4.7.4. Алгоритм медленного старта
Опыт эксплуатации сетей на основе TCP/IP показал, что с повышением загрузки сети (особенно, сети со шлюзом) ее пропускная способность падает (хотя, казалось бы, она должна оставаться постоянной). Исследования показали, что падение обусловлено появлением в сети большого числа TCP-пакетов, повторно посылаемых к активно используемому узлу сети (обычно это шлюз в другие сети). Дело в том, что приемный буфер TCP-модуля на шлюзе очень быстро заполняется, и TCP-модуль вынужден сбрасывать поступающие к нему пакеты.
Для предупреждения подобной ситуации необходимо согласование темпа передачи TCP-пакетов с возможностями их приема на узле-адресате. Задачу согласования решает алгоритм медленного старта, постепенно повышающий темп передачи данных от медленного до «оптимального», при котором нет повторных передач TCP-пакетов. Алгоритм использует так называемое » окно перегруженности » ( congestion window ), используемое на передающей стороне для определения максимального объема передаваемых данных вместо размера, получаемого от принимающей стороны в поле окна подтверждающего пакета.
Размер «окна перегруженности» определяется на передающей стороне путем постепенного его увеличения до момента появления повторных передач (ясно, что размер этого окна никогда не превышает размера окна на принимающей стороне). Однажды определенный размер «окна перегруженности» остается неизменным, пока вновь не появятся повторные передачи, однако периодически делаются осторожные попытки и увеличить этот размер.
Эксперименты показали, что данный алгоритм позволяет уменьшить количество повторно передаваемых TCP-пакетов на 50% и повысить пропускную способность сети на 30%.
5. Протокол дэйтаграмм пользователя UDP
Его основные характеристики перечислены ниже:
Следует отметить, что, по сути дела, протокол транспортного уровня UDP играет роль интерфейса для прикладных программ к средствам протокола межсетевого уровня IP.
На рис. 5.1 приведен формат заголовка UDP-пакета.
Порт источника и порт приемника
16-битовые поля, содержащие номера портов, соответственно, источника и адресата UDP-пакета. Понятие «номер порта» обсуждается в «Протокол управления передачей TCP».
16-битовое поле, содержащее длину (в байтах) всего UDP-пакета, включая заголовок и данные.
16-битовое поле, содержащее Internet-контрольную сумму, подсчитанную для UDP-заголовка, данных пакета и псевдозаголовка. Псевдозаголовок (такой же, как для подсчета контрольной суммы в TCP-заголовке) включает в себя ряд полей IP-заголовка и имеет показанную на рис. 5.2 структуру.
6. Межсетевой протокол управляющих сообщений ICMP
Межсетевой протокол управляющих сообщений ICMP (Internet Control Message Protocol), специфицированный в RFC 792, играет роль транспортного протокола для управляющей и диагностической информации, которой обмениваются между собой IP-, TCP- или UDP-модули скрытно от приложений. Протокол ICMP поддерживается в обязательном порядке ка ждым IP-модулем. Его транспортный адрес в IP-заголовке равен 1.
6.1. Заголовок ICMP-пакета
Поскольку протокол ICMP используется для транспортировки весьма различной информации, то фиксируется лишь общая структура заголовка ICMP-пакета, имеющего формат, показанный на рис. 6.1.
однобайтовое поле, содержащее идентификатор типа ICMP-пакета. Возможные значения этого поля приведены в таблице.
однобайтовое поле, значение которого конкретизирует назначение ICMP-пакета определенного типа.
16-битовое поле, содержащее Internet-контрольную сумму, подсчитанную для всего ICMP-пакета целиком.
четырезбайтовое поле, предназначенное для хранения разнообразной информации, специфичной для ICMP-пакетов определенного типа (например, номера в TCP-последовательности, IP-адреса и т.п.).
Здесь содержится заголовок IP-сегмента, явившегося порождения данного ICMP-пакета, и первые 8 байт данных тела этого IP-сегмента. Если ICMP-пакет есть результат проявления аномалии в TCP- или UDP-взаимодействии, то эти 8 байт будут представлять собой первые восемь байтов, соответственно, TCP- или UDP-заголовка, что дает возможность определить, в частности, номера портов (а, следовательно, и использующие их прикладные программы).
Для ICMP-пакетов некоторых типов это может содержать не начало IP-сегмента, а тестовые данные.
Источниками и обработчиками ICMP-пакетов могуть быть как IP-модули, так и TCP- и UDP-модули (но никогда прикладные программы).
Проблемы в доставке и обработке ICMP-пакетов никогда не приводят к порождению новых ICMP-пакетов, уведомляющих об этих проблемах. Сделано это с целью избежать возможных бесконечных циклов генерации ICMP-пакетов в сети.
6.2. Типы ICMP-пакетов
Здесь рассматриваются 6 типов ICMP-пакетов, реализованных во всех клонах и версиях ОС UNIX.
6.2.1. Адресат недоступен
ICMP-пакет этого типа генерируется в следующих случаях:
6.2.2. Подавление источника
В ситуациях, когда некоторый узел (как правило, шлюз) не имеет достаточно места в своих буферах для размещения интенсивно поступающих к нему данных, он может послать узлам-источникам ICMP-пакет данного типа ( source quench ). Узел-источник в ответ на такое уведомление обязан уменьшить темп передачи данных.
В ранних UNIX-реализациях протоколов TCP/IP ICMP-пакеты этого типа игнорировались. В TCP-реализациях, поддерживающих алгоритм медленного старта, в ответ на это сообщение уменьшается размер «окна перегруженности». UDP-модули игнорируют это сообщение, информируя при этом обслуживаемую прикладную программу о требовании приемника уменьшить интенсивность и/или размер дэйтаграмм.
6.2.3. Перенаправление
ICMP-пакет этого типа посылается источнику данных, когда узел-шлюз обнаруживает, что источник может направлять свои данные непосредственно к следующему шлюзу маршрута. Такой ICMP-пакет содержит в себе IP-адрес этого шлюза. Этот IP-адрес должен быть включен в таблицу маршрутизации на узле-источнике данных.
6.2.4. Эхо
Для реализации эха IP-модуль на узле A отправляет узлу B ICMP-пакет типа «запрос эха», содержащий в своем теле вместо IP-заголовка тестовые данные произвольной длины. Узел B, получив такой запрос, возвращает узлу A ICMP-пакет типа «ответ на запрос эха», содержащий те же данные, что и в запросе. Эхо-посылки используются для проверки достижимости удаленных узлов сети и измерения времени прохождения данных.
6.2.5. Исчерпано время жизни
ICMP-пакет данного типа посылается источнику IP-сегмента, который должен быть сброшен по одной из двух причин:
1) исчерпано время жизни IP-сегмента;
2) исчерпано допустимое время на сборку фрагментированного IP-сегмента.
6.2.6. Неверный параметр
С помощью ICMP-пакета данного типа источник IP-сегмента информируется о том, что данный сегмент сброшен вследствие наличия ошибки в каком-либо из полей его заголовка.
7. Протоколы сетевого уровня
Ниже кратко описывается реализвция стека протоколов TCP/IP на базе ряда протоколов сетевого уровня.
7.1. Ethernet
Использование протокола сетевого уровня Ethernet совместно с протоколами TCP/IP регламентируется RFC 894.
Основными характеристиками протокола Ethernet являются следующие:
В качестве физической среды передачи данных Ethernet использует:
Примечание. Существуют современные версии Ethernet, обеспечивающие скорость передачи в 100 мегабит в секунду.
Примечание. Ethernet позволяет объединить в локальную сеть узлы, расположенные друг от друга на расстоянии от нескольких десятков метров (10baseT) до нескольких километров (сегменты 10base5, связанные повторителями).
Обмен данными по протоколу Ethernet всегда реализуется программно-аппаратно с помощью двух компонентов:
Примечание. В ОС UNIX сетевой контроллер и его драйвер принято называть » сетевым интерфейсом «.
7.1.1. Формат кадра данных Ethernet
На рис. 7.1 представлен формат кадра данных протокола Ethernet. Для иллюстративных целей показана вложенность в кадр IP-сегмента (содержащего, в свою очередь, TCP-пакет).
64-битовое поле, содержащее фиксированную последовательность битов, используемую для синхронизации схем приема сигналов на узле-адресате.
Адрес приемника и адрес источника
48-битовые поля, содержащие Ethernet-адреса принимающего и передающего кадр узлов сети.
Каждый Ethernet-контроллер в мире имеет уникальный 6-байтовый адрес. Ethernet-адрес принято записывать в виде последовательности шести разделенных символом «двоеточие» двузначных шестнадцатиричных чисел, где каждое число представляет собой значение одного байта адреса, напрмер, f1:e2:d3:c4:b5:a6.
Примечание. Как правило, Ethernet-адрес жестко «зашит» в контроллере, однако существуют контроллеры, допускающие его изменение программным путем.
16-битовое поле, содержащее идентификатор протокола вышележащего уровня, использующего данный Ethernet-кадр. Т.е. поле определяет принадлежность содержимого тела кадра. Наличие данного поля в кадре обеспечивает возможность функционирования в одной сети на базе Ethernet одновременного нескольких различных стеков протоколов, а не только одного TCP/IP.
Примерами значений данного поля являются следующие:
содержит данные, передаваемые в кадре протоколом вышележащего уровня (на рисунке это IP-сегмент, тело которого используется для пересылки TCP-пакета).
Максимальная длина тела кадра протокола сетевого уровня обозначается как MTU (Maximum Transmission Unit) и для Ethernet составляет 1500 байтов.
32-битовое поле, содержащее CRC-контрольную сумму, подсчитанную для всего кадра.
В ситуациях, когда длина данных, передаваемых в теле кадра, недостаточна для формирования кадра длиной не менее 64 байтов, драйвер Ethernet-контроллера искусственно дополняет тело пакета до необходимой длины.
7.1.2. Протоколы трансляции адресов
Ethernet подобно другим протоколам сетевого уровня обладает собственной системой адресации узлов сети, отличной от системы адресации, принятой в TCP/IP. Это приводит к необходимости взаимной трансляции адресов «IP-адрес в Ethernet-адрес» и обратно.
В UNIX-системах такая трансляция выполняется с помощью специальной таблицы соответствий пар адресов различного типа, которая динамически создается и обновляется сетевым интерфейсом. В момент активизации сетевого интерфейса содержимое таблицы трансляции может загружаться из созданного вручную специального административного файла, однако это не является обязательным.
Структура ARP-сегмента приведена на рис. 7.2.
Поля длин задают длину адресов ( в нашем случае: «Длина HW-адреса» равна 6, а «Длина адреса» равна 4).
Поле «Операция» содержит идентификатор типа ARP-сегмента (запрос или ответ).
Примечание. Как видно из структуры ARP-сегмента протокол ARP может быть использован для совместной работы TCP/IP не только с протоколом Ethernet, но и с другими протоколами сетевого уровня, когда в этом есть необходимость.
Алгоритм использования протокола ARP для построения таблицы трансляции на некотором узле сети (назовем его А) выглядит следующим образом.
Для того, чтобы таблица трансляции адресов с малым временем реакции отслеживала изменения в сети, ее строки периодически (через 1. 20 минут) принудительно очищаются.
Примечание. Очевидно, что использование протокола ARP возможно только для сетей, обеспечивающих широковещательную рассылку данных.
Задачу построения строк таблицы трансляции по известному Ethernet-адресу решает протокол RARP (Reverse ARP), описанный в RFC 903 и использующий сегмент той же структуры, что протокол ARP. Определение IP-адреса по известному Ethernet-адресу требуется в момент начальной загрузки бездисковых ЭВМ, подключенных к сети.
Примечание. Использование протоколов ARP и RARP может быть отключено системным администратором.
7.2. Протокол SLIP
Протокол SLIP (Serial Line Internet Protocol) обеспечивает соединение двух ЭВМ через последовательный интерфейс (например, V.24 ). Протокол SLIP описан в RFC 1055.
Протокол очень прост. Все SLIP-кадры начинаются со служебного символа 0xEB, называемого ESC, а заканчиваются служебным символом 0xC0, называемым END. Между этими символами располагаются передаваемые данные.
Если служебные символы встречаются в передаваемых данных, то они отсылаются приемнику в виде двухбайтовых последовательностей:
RFC 1055 не специфицирует максимальной длины кадра (MTU), но существующие реализации протокола ориентированы на значение MTU равное 1006 байт.
Примечание. Очевидно, что скорость передачи данных по последовательному интерфейсу невелика. Для повышения эффективности протокола SLIP в RFC 1144 была предложена его модификация, учитывающая то обстоятельство, что при TCP-взаимодействии по последовательной линии большинство полей IP- и TCP-заголовков остаются неизменными на все время логического соединения. Данная модификация SLIP реально пересылает в своих кадрах только те поля IP- и TCP-заголовков, которые меняют свое значение от кадра к кадру.
7.3. Протокол PPP
Протокол PPP (Point-to-Point Protocol) также может быть использован для соединения двух ЭВМ по последовательному интерфейсу. Протокол PPP (RFC 1331) разработан позднее протокола SLIP, поэтому в нем ликвидированы некоторые недостатки протокола SLIP, в частности:
Для идентификации границ PPP-кадра используется служебный символ 0x7E.
Передаче данных по протоколу PPP предшествует этап тестирования и конфигурирования соединения с помощью протокола LCP (Link Control Protocol), являющегося частью PPP. LCP используется и для завершения соединения.
Кроме того, для обмена управляющей информацией используется протокол NCP (Network Control Protocol). Каждый протокол, лежащий выше PPP, имеет свою версию протокола NCP. NCP, определенный для протокола IP, носит название IPCP (Internet Protocol Control Protocol).