Текст книги "Операционная система UNIX"

Автор книги: Андрей Робачевский

сообщить о нарушении

Текущая страница: 32 (всего у книги 39 страниц)

Адресация

Каждый IP-адрес можно представить состоящим из двух частей: адреса (или идентификатора) сети и адреса хоста в этой сети. Существует пять возможных форматов IP-адреса, отличающихся по числу бит, которые отводятся на адрес сети и адрес хоста. Эти форматы определяют классы адресов, получивших названия от А до D. Определить используемый формат адреса позволяют первые три бита, как это показано на рис. 6.7.

Рис. 6.7. Форматы IP-адресов

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

Адреса класса А позволяют использовать 7 бит для адресации сети, ограничивая таким образом количество сетей этого класса числом 126[69]69
  Вообще-то 7 бит позволяют адресовать 128 сетей, но адреса сетей 0 и 127 являются зарезервированными. Это же правило для адреса сети, состоящего из всех нулей или всех единиц (в двоичном виде), справедливо и для остальных классов.


[Закрыть]. Этот формат адреса напоминает формат, используемый в предтече современной глобальной сети Internet – сети ARPANET. В те времена мало кто мог предвидеть столь бурное развитие этих технологий и число 126 не казалось малым.

Число уникальных сетей класса В значительно больше – 16 382, поскольку адрес сети состоит из 14 бит. Однако сегодня и этого недостаточно – поэтому адреса сетей этого класса больше не предоставляются.[70]70
  Конечно, в изолированной сети (или сетях), не имеющей выхода в глобальную сеть Internet, вы вольны использовать адреса любого класса.


[Закрыть]

В настоящее время выделяются сети класса С. Сетей такого класса в Internet может быть не более 2 097 150. Но и это число сегодня нельзя назвать большим. При этом в каждой сети класса С может находиться не более 254 хостов.

Популярность локальных сетей в середине 80-х годов и стремительный рост числа пользователей Internet в последнее десятилетие привели к значительному "истощению" адресного пространства. Дело в том, что если ваша организация использует только четыре адреса сети класса С, то остальные 250 адресов "потеряны" для сообщества Internet и использоваться не могут. Для более эффективного распределения адресного пространства была предложена дополнительная иерархия IP-адреса. Теперь адрес хоста может в свою очередь быть разделен на две части – адрес подсети (subnetwork) и адрес хоста в подсети.

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

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

Рис. 6.8. Подсети

Если хост или шлюз "не знает", какую маску использовать, он формирует сообщение ADDRESS MASK REQUEST (запрос маски адреса) протокола ICMP и направляет его в сеть, ожидая сообщения ICMP ADDRESS MASK REPLY от соседнего шлюза.

Ряд IP-адресов имеют специальное значение и не могут присваиваться сетевым элементам (хостам, шлюзам и т.д.). Эти значения приведены в табл. 6.3.

Таблица 6.3. Специальные IP-адреса

	Адрес: 192.85.160.46 Маска: 255.255.255.240	Адрес сети: 192.85.160.0 Адрес подсети: 2 Адрес хоста: 14
Сеть:0, Хост:0	0.0.0.0	Данный хост в данной сети
Сеть:0, Хост:H	0.0.0.5	Определенный хост в данной сети (только для адреса источника)
Сеть:1111...1 Подсеть:1111...1 Хост:1111...1	255.255.255.255	Групповой адрес всех хостов данной подсети
Сеть:N Подсеть:1111...1 Хост:1111...1	192.85.160.255	Групповой адрес всех хостов всех подсетей сети N
Сеть:N Подсеть:S Хост:1111...1	192.85.160.47	Групповой адрес всех хостов подсети S сети N
Сеть: 127 Хост: 1	127.0.0.1	Адрес внутреннего логического хоста

Протоколы транспортного уровня

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

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

Как было показано, каждый уровень протоколов DARPA имеет собственную систему адресации. Например, для уровня сетевого интерфейса (соответствующего физическому уровню и уровню канала данных модели OSI) в локальных сетях используется физический адрес интерфейса. Он представляет собой 48-битный адрес, как правило, записанный в память платы. Для отображения физического адреса в адрес протокола верхнего уровня (Internet) используется специальный протокол трансляции адреса Address Resolution Protocol (ARP).

Уровень Internet (или сетевой уровень модели OSI) в качестве адресов использует уже рассмотренные нами IP-адреса. Для адресации протокола верхнего уровня используется поле Protocol заголовка IP-датаграммы.

Протоколы транспортного уровня замыкают систему адресации DARPA. Адреса, которые используются протоколами этого уровня и называются номерами портов (port number), служат для определения процесса (приложения), выполняющегося на данном хосте, которому адресованы данные. Другими словами, для передачи сообщения от источника к получателю требуется шесть адресов – по три с каждой стороны (физический адрес адаптера, IP-адрес и номер порта) – для однозначного определения пути. Номер порта адресует конкретный процесс (приложение) и содержится в заголовке TCP– или UDP-пакета. IP-адрес определяет сеть и хост, на котором выполняется процесс, и содержится в заголовке IP-датаграммы. Адрес сетевого адаптера определяет расположение хоста в физической сети.

Номера портов занимают 16 бит и стандартизированы в соответствии с их назначением. Полный список стандартных номеров портов приведен в RFC 1700 "Assigned Numbers". Часть из них в качестве примера приведена в табл. 6.4.

Таблица 6.4. Некоторые стандартные номера портов

7	echo	Echo
20	ftp-data	Передача данных по протоколу FTP
21	ftp	Управляющие команды протокола FTP
23	telnet	Удаленный доступ (Telnet)
25	smtp	Электронная почта (Simple Mail Transfer Protocol)
53	domain	Сервер доменных имен (Domain Name Server)
67	bootps	Сервер загрузки Bootstrap Protocol
68	bootpc	Клиент загрузки Bootstrap Protocol
69	tftp	Передача файлов (Trivial File Transfer Protocol)
70	gopher	Информационная система Gopher
80	www-http	World Wide Web (HyperText Transfer Protocol)
110	pop3	Электронная почта (POP версии 3)
119	nntp	Телеконференции (Network News Transfer Protocol)
123	ntp	Синхронизация системных часов (Network Time Protocol)
161	snmp	Менеджмент/статистика (Simple Network Management Protocol)
179	bgp	Маршрутизационная информация (Border Gateway Protocol)

User Datagram Protocol (UDP)

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

Однако благодаря минимальной функциональности протокола UDP, передача данных с его использованием вносит гораздо меньшие накладные расходы по сравнению, скажем, с парным ему транспортным протоколом TCP. Размер заголовка UDP, показанного на рис. 6.9, составляет всего 8 октетов.

Рис. 6.9. Заголовок UDP

Первые два поля, каждое из которых занимает по 2 октета, адресуют соответственно порты источника и получателя. Указание порта источника является необязательным и это поле может быть заполнено нулями. Поле Length содержит длину датаграммы, которая не может быть меньше 8 октетов. Поле Checksum используется для хранения контрольной суммы и используется только если протокол верхнего уровня требует этого. Если контрольная сумма не используется, это поле заполняется нулями. В противном случае она вычисляется по псевдозаголовку, содержащему IP-адреса источника и получателя датаграммы и поле Protocol из IP-заголовка. Вид псевдозаголовка представлен на рис. 6.10. То, что вычисление контрольной суммы включает IP-адреса, гарантирует, что полученная датаграмма доставлена требуемому адресату. Заметим, что для протокола UDP значение поля Protocol равно 17.

Рис. 6.10. Псевдозаголовок UDP

В качестве примеров протоколов уровня приложений, которые используют в качестве транспортного протокол UDP, можно привести:

□ Протокол взаимодействия с сервером доменных имен DNS, порт 53.

□ Протокол синхронизации времени Network Time Protocol, порт 123.

□ Протокол удаленной загрузки BOOTP, порты 67 и 68 для клиента и сервера соответственно.

□ Протокол удаленного копирования Trivial FTP (TFTP), порт 69.

□ Удаленный вызов процедур RPC, порт 111.

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

Transmission Control Protocol (TCP)

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

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

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

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

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

□ Доставка экстренных данных.

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

TCP-канал представляет собой двунаправленный поток данных между соответствующими объектами обмена – источником и получателем. Данные могут передаваться в виде пакетов различной длины, называемых сегментами. Каждый TCP-сегмент предваряется заголовком, за которым следуют данные, инкапсулирующие протоколы уровня приложения. Вид заголовка TCP-сегмента представлен на рис. 6.11.

Рис. 6.11. Формат TCP-сегмента

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

И порядковый номер, и номер подтверждения занимают по 32 бита в заголовке TCP-сегмента, таким образом, их максимальное значение составляет (2³² – 1), за которым следует 0. При установлении связи стороны договариваются о начальных значениях порядковых номеров (Initial Sequence Number, ISN) в каждом из направлений. Впоследствии первый октет переданных данных будет иметь номер (ISN+1).

Управление потоком данных осуществляется с помощью метода скользящего окна (sliding window). Каждый TCP-заголовок содержит также поле Window, которое указывает на количество данных, которое адресат готов принять, начиная с октета, указанного в поле Acknowledgement Number.

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

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

Значение этого поля измеряется в 32-битных словах. Таким образом, при минимальном размере заголовка поле Offset будет равно 5.

Далее заголовок содержит шесть управляющих флагов Flags, каждый из которых занимает отведенный ему бит:

URG	Указывает, что сегмент содержит экстренные данные, и поле Urgent pointer заголовка определяет их положение в сегменте.
ACK	Указывает, что заголовок содержит подтверждение полученных данных В поле Acknowledgement Number.
PSH	Указывает, что данные должны быть переданы немедленно, не ожидая заполнения сегмента максимального размера.
RST	Указывает на необходимость уничтожения канала.
SYN	Указывает, что сегмент представляет собой управляющее сообщение, являющееся частью «тройного рукопожатия» для синхронизации порядковых номеров при создании канала.
FIN	Указывает, что сторона прекращает передачу данных и желает закрыть виртуальный канал.

Поле контрольной суммы Checksum используется для защиты от ошибок. Контрольная сумма вычисляется на основании 12-октетного псевдозаголовка, содержащего, в частности IP-адреса источника и получателя, а также номер протокола. Цель включения в контрольную сумму части заголовка IP та же, что и для протокола UDP – дополнительно защитить данные от получения не тем адресатом.

Поле Urgent Pointer позволяет указать расположение экстренных данных внутри сегмента. Это поле используется при установленном флаге URG и содержит порядковый номер октета, следующего за экстренными данными.

В конце заголовка располагается поле Options переменной длины, которое может содержать различные опции, например, максимальный размер сегмента (MSS). Это поле дополняется нулями (Padding) для того, чтобы заголовок всегда заканчивался на границе 32 бит.

Состояния TCP-сеанса

Как уже говорилось, передача данных с использованием протокола TCP предусматривает предварительное установление связи, или создание логического TCP-канала. Эта предварительная фаза призвана усилить надежность протокола. В процессе этой фазы определяется начало TCP-потоков в обоих направлениях, их характеристики (например, максимальный размер окна), в это же время могут быть обнаружены «полуразрушенные» TCP-каналы прошлых сеансов передачи, некорректно закрытые, например, ввиду аварийного останова одной из сторон. Стороны выбирают произвольные начальные порядковые номера потоков, чтобы уменьшить вероятность обработки сегментов, принадлежащих «старым» сеансам.[71]71
  В нормальных условиях модули TCP хранят последние использованные порядковые номера. Поэтому при создании нового канала (сеанса) модуль выбирает следующее значение из адресного пространство порядковых номеров (которое составляет 2³²). При скорости передачи 2 Мбит/с потребуется 4,5 часа для передачи данных, адресуемых этими номерами (порядковыми и подтверждений). Это время на несколько порядков превышает время жизни TCP-сегмента в сети, которое по умолчанию составляет 2 секунды. Это гарантирует, что новые номера не «догонят» номера старых сегментов. Даже при скорости 100 Мбит/с полный цикл использования порядковых номеров составляет чуть больше 5 минут.


[Закрыть]

Начальная фаза сеанса передачи получила название "тройное рукопожатие" (three-way handshake), которое достаточно точно отражает процесс обмена служебными сегментами между сторонами. Этот процесс является ассиметричным – одна из сторон, называемая клиентом, инициирует начало сеанса, посылая другой стороне – серверу сегмент SYN.[72]72
  Сегмент SYN имеет установленный флаг SYN в заголовке – отсюда и его название.


[Закрыть] Как правило этот сегмент является числом служебным, т.е. не содержит полезных данных, его заголовок определяет номер порта и начальный порядковый номер потока клиент-сервер. Если сервер готов принять данные от клиента, он создает логический канал (размещая соответствующие структуры данных) и отправляет клиенту сегмент с установленным начальным порядковым номером потока сервер-клиент и флагами SYN и ACK, подтверждающий получение сегмента SYN и выражающего готовность сервера к получению данных. Наконец, и это третье рукопожатие, клиент отвечает сегментом с установленным флагом ACK, подтверждающим получение ответа от сервера и тем самым завершающим фазу создания TCP-канала. Процесс установления связи в TCP-сеансе представлен на рис. 6.12.

Рис. 6.12. Установление связи, передача данных и завершение TCP-сеанса

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

Завершение сеанса в TCP происходит в несколько этапов. Любая из сторон может завершить передачу данных, отправив сегмент с установленным флагом FIN (рис. 6.12). Получение такого сегмента подтверждается другой стороной и эквивалентно достижению конца файла при его чтении. Однако другая сторона может продолжать передавать данные, также впоследствии завершив передачу сегментом FIN. Подтверждение этого сегмента полностью разрушает канал и завершает сеанс. Для того чтобы гарантировать синхронизацию завершения сеанса, сторона, отправившая подтверждение на последний сегмент FIN, должна поддерживать сеанс достаточно долго, чтобы иметь возможность вновь подтвердить повторные сегменты FIN данного сеанса в случае, когда подтверждение не было получено другой стороной.

На рис. 6.12 также проиллюстрированы состояния коммуникационных узлов TCP-канала.

Как видно из рисунка, начальное состояние узла (сервера или клиента) – состояние CLOSED. Готовность сервера к обработке инициирующих запросов от клиента определяется переходом его в состояние LISTEN. С этого момента сервер может принимать и обрабатывать инициирующие сеанс сегменты SYN. При отправлении такого сегмента клиент переходит в состояние SYN-SENT и ожидает ответного запроса от сервера. Сервер при получении сегмента также отправляет сегмент SYN с подтверждением ACK и переходит в состояние SYN-RECEIVED. Подтверждение от клиента завершает «рукопожатие» и сеанс переходит в состояние ESTABLISHED. После завершения обмена данными одна из сторон (например, клиент) отправляет сегмент FIN, переходя при этом в состояние FIN-WAIT-1. Приняв этот сегмент другая сторона (например, сервер) отправляет подтверждение ACK и переходит в состояние CLOSE-WAIT, при этом канал становится симплексным – передача данных возможна только в направлении от сервера к клиенту. Когда клиент получает подтверждение он переходит в состояние FIN-WAIT-2, в котором находится до получения сегмента FIN. После подтверждения получения этого сегмента канал окончательно разрушается.

Расшифровка состояний приведена в табл. 6.5.

Таблица 6.5. Состояния TCP-сеанса

LISTEN	Готовность узла к получению запроса на соединение от любого удаленного узла.
SYN-SENT	Ожидание ответного запроса на соединение.
SYN-RECEIVED	Ожидание подтверждения получения ответного запроса на соединение.
ESTABLISHED	Состояние канала, при котором возможен дуплексный обмен данными между клиентом и сервером.
CLOSE-WAIT	Ожидание запроса на окончание связи от локального процесса, использующего данный коммуникационный узел.
LAST-ACK	Ожидание подтверждения запроса на окончание связи, отправленного удаленному узлу. Предварительно от удаленного узла уже был получен запрос на окончание связи и канал стал симплексным.
FIN-WAIT-1	Ожидание подтверждения запроса на окончание связи, отправленного удаленному узлу (инициирующий запрос, канал переходит в симплексный режим).
FIN-WAIT-2	Ожидание запроса на окончание связи от удаленного узла
CLOSING	Ожидание подтверждения от удаленного узла на запрос окончания связи.
TIME-WAIT	Таймаут перед окончательным разрушением канала, достаточный для того, чтобы удаленный узел получил подтверждение своего запроса окончания связи. Величина тайм-аута составляет 2 MSL (Maximum Segment Lifetime).[73]73   Значение MSL, рекомендованное в RFC 793 «Transmission Control Protocol», составляет 2 минуты. Однако в реальных системах типичными значениями MSL являются 30 секунд, 1 или 2 минуты. [Закрыть]
CLOSED	Фиктивное состояние, при котором коммуникационный узел и канал фактически не существуют.

Для обеспечения правильной обработки данных для каждого логического TCP-канала хранится полная информация о его состоянии, различных таймерах и о текущих порядковых номерах переданных и принятых октетов. Это необходимо, например, для корректной обработки служебных сегментов SYN и FIN.[74]74
  Эта информация представлена соответствующими структурами данных, называемыми TCB (Transmission Control Block). Как правило, коммуникационный узел, представляющий сетевой интерфейс для взаимодействующих процессов, хранит указатель на эти управляющие данные. Более подробно архитектура сетевых интерфейсов UNIX описана в следующих разделах.


[Закрыть]