Протоколы сетевого взаимодействия TCP/IP

Содержание

Введение

1. Соотношение между OSI/ISO и TCP/IP

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

3. Межсетевой протокол IP

4. Протокол управления передачей TCP

5. Протокол дэйтаграмм пользователя UDP

6. Межсетевой протокол управляющих сообщений ICMP

7. Протоколы сетевого уровня

Литература

Протоколы информационно-вычислительных сетей. Под. ред. Мизина И.А. и Кулешова А.П. М.: Радио и связь, 1990, 504 с.

Halsall F. Data communications, computer networks and open systems. Addison-Wesley publishing company, 1992, 772 pp.

Santifaller M. TCP/IP and ONC/NFS: internetworking in a UNIX environment. Addison-Wesley (Deutschland) GmbH, 1994, 288 pp.

Введение

Протоколы сетевого взаимодействия 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.

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

Согласно терминологии 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 (Transmission Control Protocol) и быстрый протокол дэйтаграмм пользователя UDP (User Datagram Protocol). TCP реализует сетевое взаимодействие в режиме с установлением логического (виртуального) соединения, а UDP - без оного.

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

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

3. IP-адрес

IP-адрес представляет собой четырехбайтовое число, старшие (крайние левые) биты которого определяют класс IP-адреса. Для классов A, B и C четыре байта адреса делятся между идентификатором (номером) сети и идентификатором (номером) узла в сети как это показано на рис. 3.2.

Сети классов A, B и C абсолютно равноправны и отличаются лишь допустимым количеством узлов в них. Идентификаторы узлов, состоящие из одних нулевых или единичных битов имеют специальный смысл:

IP-адрес с нулевым идентификатором узла используется для обозначения сети в целом;

IP-адрес с идентификатор узла в виде единичных битов является широковещательным (broadcast) адресом.

IP-адреса принято записывать в так называемой "точечной нотации" - в виде последовательности разделенных точками четырех десятичных (или шестнадцатиричных с префиксом 0x) чисел, представляющих значения отдельных байтов.

Каждый узел в сети имеет, по крайней мере, один уникальный IP-адрес.

Кроме классов A, B и C существуют еще два класса IP-адресов - D и E (см. рис. 3.3).

Класс D используется для организации многопунктового (multicast) режима посылки сообщений: IP-сегмент, посылаемый по IP-адресу класса D, доставляется всем узлам сети, имеющим указанный идентификатор группы узлов. Описание данного режима дано в RFC 1112.

Примечание. Не все современные реализации протоколов TCP/IP поддерживают многопунктовое вещание.

Для обеспечения гибкости при создании и администрировании сетей различного размера в 1985 г. было введено понятие "подсеть" (RFC 950), позволяющее использовать один и тот же IP-адрес классов A,B или C для разных подсетей.

Такая возможность обеспечивается специальной битовой маской (netmask), ассоциированной с IP-адресом и определяющей распределение битов IP-адреса между идентификатором подсети и идентификатором узла.

Пусть, например, IP-адрес класса C 194.85.36.0 планируется использовать для организации четырех подсетей. Это потребует выделения двух битов из части IP-адреса, относящейся к идентификатору узла. Такое "перепланирование" структуры IP-адреса реализуется сетевой маской 255.255.255.192, где десятичное 192 - это двоичное 11000000.

Эта сетевая маска формирует IP-адрес не из двух, а из трех комронент:

идентификатор сети (24 бита);

идентификатор подсети (2 бита);

идентификатор узла (6 бит).

Каждая из четырех образованных подсетей может иметь до 62 узлов с идентификаторами от 1 до 62, идентификатор узла с номером 63 является широковещательным идентификатором для подсети.

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

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

Примечание. Некоторые современные реализации протоколов маршрутизации для TCP/IP позволяют выделять "подподсети" в подсетях.

4. Протокол управления передачей TCP

Протокол управления передачей TCP (Transmission Control Protocol) является протоколом транспортного уровня и базируется на возможностях, предоставляемых межсетевым протоколом IP. Основная задача TCP - обеспечение надежной передачи данных в сети. Его транспортный адрес в заголовке IP-сегмента равен 6. Описание протокола TCP дано в RFC 793.

Его основные характеристики перечислены ниже:

реализует взаимодействие в режиме с установлением логического (виртуального) соединения;

обеспечивает двунаправленную дуплексную связь;

организует потоковый (с точки зрения пользователя) тип передачи данных;

дает возможность пересылки части данных, как "экстренных";

для идентификации партнеров по взаимодействию на транспортном уровне использует 16-битовые "номера портов";

реализует принцип "скользящего окна" (sliding window) для повышения скорости передачи;

поддерживает ряд механизмов для обеспечения надежной передачи данных.

Несмотря на то, что для пользователя передача данных с использованием протокола TCP выглядит как потоковая, на самом же деле обмен между партнерами осуществляется посредством пакетов данных, которые мы будем называть "TCP-пакетами".

4.1. Заголовок TCP-пакета

На рис. 4.1 приведен формат заголовка TCP-пакета.

Порт источника и порт приемника

16-битовые поля, содержащие номера портов, соответственно, источника и адресата TCP-пакета. Подробное описание понятия "номер порта" дано в "Номер порта".

Номер в последовательности (sequence number)

32-битовое поле, содержимое которого определяет (косвенно) положение данных TCP-пакета внутри исходящего потока данных, существующего в рамках текущего логического соединения.

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

Номер подтверждения (acknowledgement number)

32-битовое поле, содержимое которого определяет (косвенно) количество принятых данных из входящего потока к TCP-модулю, формирующему TCP-пакет.

Смещение данных

четырехбитовое поле, содержащее длину заголовка TCP-пакета в 32-битовых словах и используемое для определения начала расположения данных в TCP-пакете.

Флаг URG

бит, установленное в 1 значение которого означает, что TCP-пакет содержит важные (urgent) данные. Подробно о данных этого типа сказано в "Важные данные".

Флаг ACK

бит, установленное в 1 значение которого означает, что TCP-пакет содержит в поле "номер подтверждения" верные данные.

Флаг PSH

бит, установленное в 1 значение которого означает, что данные содержащиеся в TCP-пакете должны быть немедленно переданы прикладной программе, для которой они адресованы. Подтверждение для TCP-пакета, содержащего единичное значение во флаге PSH, означает, что и все предыдущие TCP-пакеты достигли адресата.

Флаг RST

бит, установливаемый в 1 в TCP-пакете, отправляемом в ответ на получение неверного TCP-пакета. Также может означать запрос на переустановление логического соединения.

Флаг SYN

бит, установленное в 1 значение которого означает, что TCP-пакет представляет собой запрос на установление логического соединения. Получение пакета с установленым флагом SYN должно быть подтверждено принимающей стороной.

Флаг FIN

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

Размер окна

16-битовое поле, содержащее количество байт информации, которое может принять в свои внутренние буфера TCP-модуль, отправляющий партнеру данный TCP-пакет. Данное поле используется принимающим поток данных TCP-модулем для управления интенсивностью этого потока: так, установив значение поля в 0, можно полностью остановить передачу данных, которая будет возобновлена только, когда размер окна примет достаточно большое значение. Максимальный размер окна зависит от реализации, в некоторых реализациях максимальный размер может устанавливаться системным администратором (типичное значение максимального размера окна - 4096 байт). Определение оптимального размера окна - одна из наиболее сложных задач реализации протокола TCP (см. "Исключение малых окон").

Контрольная сумма

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

Указатель

16-битовое поле, содержащее указатель (в виде смещения) на первый байт в теле TCP-пакета, начинающий последовательность важных (urgent) данных. Данные этого типа и механизм их обработки описаны в "Важные данные".

Дополнительные данные заголовка

последовательность полей произвольной длины, описывающих необязательные данные заголовка. Протокол TCP определяет только три типа дополнительных данных заголовка:

конец списка полей дополнительных данных;

пусто (No Operation);

максимальный размер пакета.

Дополнительные данные последнего типа посылаются в TCP-заголовке в момент установления логического соединения для выражения готовности TCP-модулем принимать пакеты длиннее 536 байтов. В UNIX-реализациях длина пакета обычно определяется максимальной длиной IP-сегмента для сети.

4.2. Номер порта

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

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

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

используемый транспортный протокол (TCP или UDP);

IP-адрес сервера;

номер порта сервера;

IP-адрес клиента;

номер порта клиента.

Для того, чтобы клиент мог обращаться к необходимому ему серверу, он должен знать номер порта, по которому сервер ожидает обращения к нему ("слушает сеть"). Для прикладных программ, получивших наибольшее распространение в сетях на основе TCP/IP, номера портов фиксированы и носят название "хорошо известных номеров портов" (well-known port numbers). В UNIX-системах такие номера портов содержатся в файле /etc/services. Ниже приводятся примеры хорошо известных номеров портов для некоторых серверов (служб).

Служба Номер порта Протокол

---------------------------------

ftp-data 20 TCP

ftp 21 TCP

telnet 23 TCP

smtp 25 TCP

time 37 TCP

time 37 UDP

finger 79 TCP

portmap 111 TCP

portmap 111 UDP

exec 512 TCP

login 513 TCP

shell 514 TCP

who 513 UDP

talk 517 UDP

route 520 UDP

Xserver 6000 TCP

Примечание. Обратите внимание, что некоторые серверы (такие, например, как для службы portmap с номером порта 111) могут работать как по протоколу TCP, так и по протоколу UDP.

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

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

Средства разработки сетевых приложений на базе транспортных протоколов TCP и UDP описаны в "Сетевое программирование".

4.3. Принцип "скользящего окна"

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

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

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

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

Размер окна, как правило, определяется объемом свободного места в буферах принимающего TCP-модуля.

4.4. Важные данные

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

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

Для индикации наличия в TCP-пакете важных данных используется флаг URG TCP-заголовка, местоположение важных данных в теле TCP-пакета определяется полем "Указатель" TCP-заголовка - оно задает смещение (в стиле языка программирования C) первого байта важных данных в теле TCP-пакета. Рис. 4.3 иллюстрирует расположение важных данных в теле TCP-пакета.

Примечание. Протокол 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.6 иллюстрирует закрытие соединения по инициативе TCP-модуля A, посылающего партнеру TCP-пакет с установленным флагом FIN. Прием запроса на закрытие соединения TCP-модуль B подтверждает пакетом, содержащем в своем заголовке поле "Номер подтверждения", значение которого (1052) на 1 больше значения принятого "Номера в последовательности" (1051). После этого посылка каких-либо данных TCP-модулем A становится невозможной, однако модуль B имеет данные для передачи, которые он отправляет TCP-модулю A и получает подтверждение на их прием. Затем TCP-модуль B формирует пакет с флагом FIN, после подтверждения его приема соединение считается закрытым.

Примечание. Обратите внимание на то обстоятельство, что при подтверждении TCP-пакетов, содержащих единичные флаги SYN или FIN, значение поля "Номер подтверждения" на 1 больше значения соответствующего поля "Номер в последовательности", несмотря на то, что никакие данные в подтверждаемых TCP-пакетах не передаются.

Примечание. Рассмотренный пример не включает в себя ситуации, связанные с "потерей" TCP-пакетов в сети, и их обработку, связанную с повторной передачей данных.

5. Протокол дэйтаграмм пользователя UDP

Протокол дэйтаграмм пользователя UDP (User Datagram Protocol) является протоколом транспортного уровня и базируется на возможностях, предоставляемых межсетевым протоколом IP. Основная задача UDP - обеспечение "быстрой" передачи данных в сети. Его транспортный адрес в заголовке IP-сегмента равен 17. Описание протокола UDP дано в RFC 768.

Его основные характеристики перечислены ниже:

реализует взаимодействие в режиме без установлением логического (виртуального) соединения;

организует поблочный (дэйтаграммный, пакетный) тип передачи данных;

для идентификации партнеров по взаимодействию на транспортном уровне использует 16-битовые "номера портов";

не гарантирует надежной передачи данных (возможна как потеря UDP-пакетов, так и их дублирование);

не имеет средств уведомления источника UDP-пакета о правильности/ошибочности в его приеме адресатом;

не обеспечивает правильный порядок доставки UDP-пакетов от источника к приемнику;

может гарантировать целостность данных в UDP-пакете за счет использования контрольной суммы;

очень прост (особенно, по сравнению с протоколом TCP).

Следует отметить, что, по сути дела, протокол транспортного уровня UDP играет роль интерфейса для прикладных программ к средствам протокола межсетевого уровня IP.

Порт источника и порт приемника

16-битовые поля, содержащие номера портов, соответственно, источника и адресата UDP-пакета. Понятие "номер порта" обсуждается в "Протокол управления передачей TCP".

Длина

16-битовое поле, содержащее длину (в байтах) всего UDP-пакета, включая заголовок и данные.

Контрольная сумма

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

Если поле "Контрольная сумма" UDP-заголовка содержит нулевое значение, это означает, что источник UDP-пакета контрольную сумму не подсчитывал, и приемник выполнять ее проверку не должен. Некоторые реализации протокола UDP (например, в SunOS - клоне ОС UNIX от Sun Microsystems) контрольную сумму не подсчитывают в принципе, полагаясь на возможности контроля целостности данных, реализованные в протоколах сетевого уровня (например, в Ethernet).

7. Протоколы сетевого уровня

7.1. Ethernet

Протокол Ethernet был разработан в начале 1970-х годов совместно фирмами Xerox, DEC и Intel. На его базе в 1982 г. был принят международный стандарт IEEE 802.3.

Использование протокола сетевого уровня Ethernet совместно с протоколами TCP/IP регламентируется RFC 894.

Основными характеристиками протокола Ethernet являются следующие:

шинная логическая топология сети;

скорость передачи данных 10 мегабит в секунду;

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

обмен данными между узлами сети осуществляется кадрами;

для разделения шины между многими узлами используется механизм CSMA/CD;

обеспечивает широковещательную (broadcast) и многопунктовую (multicast) рассылку данных.

В качестве физической среды передачи данных Ethernet использует:

"толстый" коаксиальный кабель (так называемый 10base5 Ethernet);

"тонкий" коаксиальный кабель (10base2);

оптоволоконный кабель;

витая пара (10baseT).

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

Примечание. Существуют современные версии Ethernet, обеспечивающие скорость передачи в 100 мегабит в секунду.

Примечание. Ethernet позволяет объединить в локальную сеть узлы, расположенные друг от друга на расстоянии от нескольких десятков метров (10baseT) до нескольких километров (сегменты 10base5, связанные повторителями).

Механизм CSMA/CD (Carrier Sense Multiple Acces with Collision Detection - Множественный Доступ с Контролем Носителя и Обнаружением Столкновений) подразумевает следующий алгоритм получения узлом сети доступа к шине:

прослушивание шины (sense carrier) на предмет наличия в ней сигналов передачи данных другими узлами;

если шина занята, то отложить передачу, если свободна - начать передачу данных;

в течение первых 47 микросекунд передачи кадра данных вести проверку столкновений (collisions) в шине, связанных с возможным одновременным началом передачи данных и другими узлами сети;

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

Обмен данными по протоколу Ethernet всегда реализуется программно-аппаратно с помощью двух компонентов:

сетевого контроллера (чаще всего имеющего вид печатной платы, вставляемой в корпус ЭВМ), подключаемого к шине (коаксиальному кабелю, оптоволокну или витой паре медных проводов);

драйвера сетевого контроллера, обеспечивающего интерфейс сетевого программного обеспечения (например, IP-модуля) с контроллером.

Примечание. В ОС UNIX сетевой контроллер и его драйвер принято называть "сетевым интерфейсом".

Протоколы трансляции адресов

Ethernet подобно другим протоколам сетевого уровня обладает собственной системой адресации узлов сети, отличной от системы адресации, принятой в TCP/IP. Это приводит к необходимости взаимной трансляции адресов "IP-адрес в Ethernet-адрес" и обратно.

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

Для поддержания таблицы трансляции в актуальном состоянии, отражающем текущий состав узлов Ethernet-сети, используется протокол ARP (Address Resolution Protocol), описанный в RFC 826.

Протокол SLIP

Протокол SLIP (Serial Line Internet Protocol) обеспечивает соединение двух ЭВМ через последовательный интерфейс (например, V.24). Протокол SLIP описан в RFC 1055.

Протокол очень прост. Все SLIP-кадры начинаются со служебного символа 0xEB, называемого ESC, а заканчиваются служебным символом 0xC0, называемым END. Между этими символами располагаются передаваемые данные.

Если служебные символы встречаются в передаваемых данных, то они отсылаются приемнику в виде двухбайтовых последовательностей: {ESC, 0xEC} и {ESC, 0xED}. На принимающей стороне двухбайтовые последовательности преобразуются в ESC и END.

RFC 1055 не специфицирует максимальной длины кадра (MTU), но существующие реализации протокола ориентированы на значение MTU равное 1006 байт.

Примечание. Очевидно, что скорость передачи данных по последовательному интерфейсу невелика. Для повышения эффективности протокола SLIP в RFC 1144 была предложена его модификация, учитывающая то обстоятельство, что при TCP-взаимодействии по последовательной линии большинство полей IP- и TCP-заголовков остаются неизменными на все время логического соединения. Данная модификация SLIP реально пересылает в своих кадрах только те поля IP- и TCP-заголовков, которые меняют свое значение от кадра к кадру.

Протокол PPP

Протокол PPP (Point-to-Point Protocol) также может быть использован для соединения двух ЭВМ по последовательному интерфейсу. Протокол PPP (RFC 1331) разработан позднее протокола SLIP, поэтому в нем ликвидированы некоторые недостатки протокола SLIP, в частности:

поддерживаются различные протоколы вышележащего уровня (а не только IP);

используются контрольные суммы.

Для идентификации границ PPP-кадра используется служебный символ 0x7E.

Передаче данных по протоколу PPP предшествует этап тестирования и конфигурирования соединения с помощью протокола LCP (Link Control Protocol), являющегося частью PPP. LCP используется и для завершения соединения.

Кроме того, для обмена управляющей информацией используется протокол NCP (Network Control Protocol). Каждый протокол, лежащий выше PPP, имеет свою версию протокола NCP. NCP, определенный для протокола IP, носит название IPCP (Internet Protocol Control Protocol).

Дата добавления: 2017-02-01; Просмотров: 57; Нарушение авторских прав?; Мы поможем в написании вашей работы!