Учебник для вузов в. Олифер Н. Олифер Компьютерные Принципы, технологии, протоколы
 Скачать 22.28 Mb.
|
|
ГЛАВА 17 Базовые протоколы TCP/IP Эту главу мы начнем с изучения протоколов TCP и UDP, исполняющих посредническую роль между приложениями и транспортной инфраструктурой сети. В то время как задачей уровня межсетевого взаимодействия, к которому относится протокол IP, является передача данных между сетевыми интерфейсами в составной сети, главная задача транспортного уровня, которую решают протоколы TCP и UDP, заключается в передаче данных между прикладными процессами, выполняющимися на компьютерах в сети. Далее в этой главе рассматриваются протоколы маршрутизации, предназначенные для автомати ческого построения таблиц маршрутизации, на основе которых происходит продвижение пакетов сетевого уровня. Протоколы маршрутизации, в отличие от сетевых протоколов, таких как IP и IPX, не являются обязательными, так как таблица маршрутизации может строиться администратором сети вручную. Однако в крупных сетях со сложной топологией и большим количеством альтернативных маршрутов протоколы маршрутизации выполняют очень важную и полезную работу, автоматизируя построение таблиц маршрутизации, а также отыскивая новые маршруты при изменениях сети: от- (азах или появлении новых линий связи и маршрутизаторов. Мы рассмотрим также протокол ICMP, являющийся средством оповещения отправителя о причинах недоставки его пакетов адресату. Помимо диагностики ICMP используется для мониторинга сети. Так, в основе популярных утилит мониторинга ІР-сетей ping и traceroute лежат ІСМР-сообщения. 554 Глава 17. Базовые протоколы TCP/IP Протоколы транспортного уровня TCP и UDP К транспортному уровню стека T C P/IP относятся: □ протокол управления передачей (Transmission Control Protocol, TCP), описанный в стандарте RFC 793; □ протокол пользовательских дейтаграмм (User Datagram Protocol, UDP), описанный в стандарте RFC 768. Протоколы TCP и UDP, как и протоколы прикладного уровня, устанавливаются на ко нечных узлах. Порты и сокеты В то время как задачей уровня сетевого взаимодействия, к которому относится протокол IP, является передача данных между сетевыми интерфейсами в составной сети, главная за дача протоколов транспортного уровня TCP и UDP заключается в передаче данных между прикладными процессами, выполняющимися на компьютерах в сети. Каждый компьютер может выполнять несколько процессов, более того, даже отдельный прикладной процесс может иметь несколько точек входа, выступающих в качестве адре сов назначения для пакетов данных. Поэтому доставка данных на сетевой интерфейс компьютера-получателя — это еще не конец пути, так как данные необходимо переправить конкретному процессу-получателю. Процедура распределения протоколами TCP и UDP поступающих от сетевого уровня пакетов между прикладными процессами называется демультиплексированием (рис. 17.1). Протоколы транспортного уровня TCP и UDP 555 Существует и обратная задача: данные, генерируемые разными приложениями, работающи ми на одном конечном узле, должны быть переданы общему для всех них протокольному модулю IP для последующей отправки в сеть. Эту работу, называемую мультиплексиро ванием, тоже выполняют протоколы TCP и UDP. Протоколы TCP и UDP ведут для каждого приложения две системные очереди: очередь данных, поступающих к приложению из сети, и очередь данных, отправляемых этим при ложением в сеть. Такие системные очереди называются портами1, причем входная и вы ходная очереди одного приложения рассматриваются как один порт. Для идентификации портов им присваивают номера. Если процессы представляют собой популярные системные службы, такие как FTP, telnet, Нттр тртр^ DNS и т. п., то за ними закрепляются стандартные назначенные номера, называемые также хорошо известными (well-known) номерами портов. Эти номера за крепляются и публикуются в стандартах Интернета (RFC 1700, RFC 3232). Так, номер 21 закреплен за серверной частью службы удаленного доступа к файлам FTP, а 23 — за сервер ной частью службы удаленного управления telnet. Назначенные номера из диапазона от 0 до 1023 являются уникальными в пределах Интернета и закрепляются за приложениями централизованно. Для тех приложений, которые еще не стали столь распространенными, номера портов назначаются локально разработчиками этих приложений или операционной системой в ответ на поступление запроса от приложения. На каждом компьютере операционная система ведет список занятых и свободных номеров портов. При поступлении запроса от приложения, выполняемого на данном компьютере, операционная система выделяет ему первый свободный номер. Такие номера называют динамическими. В дальнейшем все сетевые приложения должны адресоваться к данному приложению с указанием назначен ного ему динамического номера порта. После того как приложение завершит работу, его номер возвращается в список свободных и может быть назначен другому приложению. Динамические номера являются уникальными в пределах каждого компьютера, но при этом обычной является ситуация совпадения номеров портов приложений, выполняемых на разных компьютерах. Как правило, клиентские части известных приложений (DNS, WWW, FTP, telnet и др.) получают динамические номера портов от ОС. Все, что было сказано о портах, в равной степени относится к обоим протоколам транс портного уровня (TCP и UDP). В принципе, нет никакой зависимости между назначением номеров портов для приложений, использующих протокол TCP, и приложений, работаю щих с протоколом UDP. Приложения, которые передают данные на уровень IP по про токолу UDP, получают номера, называемые UDP-портами. Аналогично, приложениям, обращающимся к протоколу TCP, выделяются ТСР-порты. Втом и другом случаях это могут быть как назначенные, так и динамические номера. Диа пазоны чисел, из которых выделяются номера TCP- и UDP-портов, совпадают: от 0 до 1023 для назначенных и от 1024 до 65 535 для динамических. Однако никакой связи между назначенными номерами TCP- и UDP-портов нет. Даже если номера TCP- и UDP-портов совпадают, они идентифицируют разные приложения. Например, одному приложению может быть назначен ТСР-порт 1750, а другому — UDP-порт 1750. В некоторых случаях, когда приложение может обращаться по выбору к протоколу TCP или UDP (например, {Порт приложения не надо путать с портами (сетевыми интерфейсами) оборудования. 556 Глава 17. Базовые протоколы TCP/IP таким приложением является DNS), ему, исходя из удобства запоминания, назначаются совпадающие номера TCP- и UDP-портов (в данном примере — это хорошо известный номер 53). Стандартные назначенные номера портов уникально идентифицируют тип приложения (FTP, или HTTP, или DNS и т. д.), однако они не могут использоваться для однозначной идентификации прикладных процессов, связанных с каждым из этих типов приложений. Пусть, например, на одном хосте запущены две копии DNS-сервера — DNS-сервер 1, DNS- сервер 2 (рис. 17.2). Каждый из этих DNS-серверов имеет хорошо известный UDP-порт 53. Какому из этих серверов нужно было бы направить запрос клиента, если бы в DNS-запросе в качестве идентификатора сервера был указан только номером порта? Сокет DNS-сервера 1 Щ DNS-сервер 1 (IP1, UDP-порт 53) DNS-клиент 2 DNS-сервер 2 1 Сокет DNS-сервера 2 (ІР2, UDP-порт 53) 1Р-дейтаграмма 0 * S 1 Порт назначения 53 1Р-адрес назначения IP2 UDP-дейтаграмма "-v— Кадр Рис. 17.2. Демультиплексирование протокола UDP на основе сокетов Чтобы снять неоднозначность в идентификации приложений, разные копии связываются с разными IP-адресами. Для этого сетевой интерфейс компьютера, на котором выполня ется несколько копий приложения, должен иметь соответствующее число ІР-адресов - на рисунке это ІР1 и ІР2. Во всех IP-пакетах, направляемых DNS-серверу 1, в качестве IP-адреса указывается ІР1, а DNS-серверу 2 — адрес ІР2. Поэтому показанный на рисунке пакет, в поле данных которого содержится UDP-дейтаграмма с указанным номером пор та 53, а в поле заголовка задан адрес ІР2, буден направлен однозначно определенному адресату — DNS-серверу 2. Прикладной процесс однозначно определяется в пределах сети и в пределах отдельного ком* пьютера парой (IP-адрес, номер порта), называемой сокетом (socket). Сокет, определенный ІР-адресом и номером UDP-порта, называется UDP-сокетом, а ІР-адресом и номером TCP- порта—ТСР-сокетом. Протоколы транспортного уровня TCP и UDP 557 ПРИМЕЧАНИЕ--------------------------------------------------------------------------------------------------------------- Здесь мы должны уточнить описанную в предыдущих главах упрощенную картину прохождения пакета вверх по стеку Действительно, как мы и отмечали, после получения ІР-пакета от протокола канального уровня протокол IP анализирует содержимое заголовка этого пакета, после чего заго ловок отбрасывается, и «наверх» передается содержимое поля данных ІР-пакета, например U D P- дейтаграмма. Упрощение состоит в том, что вместе с содержимым поля данных на транспортный уровень передается извлеченный из заголовка IP-адрес назначения, который и используется для однозначной идентификации приложения. Протокол UDP и UDP-дейтаграммы ПротдкШ УСЩ дейтаграммным протоколом, реализующим так называемый который не гарантирует доставку сообщений адресату. При работе на хосте-отправителе данные от приложений поступают протоколу UDP че рез порт в виде сообщений (рис. 17.3). Протокол UDP добавляет к каждому отдельному сообщению свой 8-байтный заголовок, формируя из этих сообщений собственные про токольные единицы, называемые UDP-дейтаграммами, и передает их нижележащему протоколу IP. В этом и заключаются его функции по мультиплексированию данных. а Заголовки г— і протокола UDP ^ ^ L g J К протоколу UDP-дейтаграммы Рис. 17.3. Работа протокола UDP на хосте-отправителе 558 1 Глава 17. Базовые протоколы TCP/IP Каждая дейтаграмма переносит отдельное пользовательское сообщение. Сообщения могут иметь различную длину, не превышающую однако длину поля данных протокола IP, ко торое, в свою очередь, ограничено размером кадра технологии нижнего уровня. Поэтому если буфер UDP переполняется, то сообщение приложения отбрасывается. Заголовок UDP состоит из четырех 2-байтных полей: □ номер UDP-порта отправителя; □ номер UDP-порта получателя; □ контрольная сумма; □ длина дейтаграммы. Далее приведен пример заголовка UDP с заполненными полями: Source Port - 0x0035 D e s t i n a t i o n Port - 0x0411 Total le ngt h - 132 (0x84) bytes Checksum - 0x5333 В этой UDP-дейтаграмме в поле данных, длина которого, как следует из заголовка, равна (132 - 8) байт, помещено сообщение DNS-сервера, что можно видеть по номеру порта источника ( S o u r c e P o r t = 0—0035). В шестнадцатеричном формате это значение равно стандартному номеру порта DNS-сервера — 53. Судя по простоте заголовка, протокол UDP не сложен. Действительно, его функции сводятся к простой передаче данных между прикладным и сетевым уровнями, а также примитивному контролю искажений в передаваемых данных. При контроле искажений протокол UDP только диагностирует, но не исправляет ошибку. Если контрольная сумма показывает, что в поле данных UDP-дейтаграммы произошла ошибка, протокол UDP про сто отбрасывает поврежденную дейтаграмму. Работая на хосте-получателе, протокол UDP принимает от протокола IP извлеченные из пакетов UDP-дейтаграммы. Полученные из IP-заголовка ІР-адрес назначения и из UDP-заголовка номер порта используются для формирования UDP-сокета, однозначно идентифицирующего приложение, которому направлены данные. Протокол UDP осво бождает дейтаграмму от UDP-заголовка. Полученное в результате сообщение он передает приложению на соответствующий UDP-сокет. Таким образом, протокол UDP выполняет демультиплексирование на основе сокетов. Протокол TCP и ТСР-сегменты Протсифл р с ш т Hcnhhkivttsi При работе на хосте-отправителе протокол TCP рассматривает информацию, поступаю щую к нему от прикладных процессов, как неструктурированный поток байтов (рис. 17.4). Поступающие данные буферизуются средствами TCP. Для передачи на сетевой уровень из буфера «вырезается» некоторая непрерывная часть данных, которая называется сегментом! и снабжается заголовком. 1 Заметим, что сегментом называют как единицу передаваемых данных в целом (поле данных и за- Протоколы транспортного уровня TCP и UDP 559 Рис. 17.4. Формирование TCP-сегментов из потока байтов ПРИМЕЧАНИЕ--------------------------------------------------------------------------------------------------- В отличие от протокола UDP, который создает свои дейтаграммы на основе логически обособленных единиц данных — сообщений, генерируемых приложениями, протокол TCP делит поток данных на сегменты без учета их смысла или внутренней структуры. Заголовок TCP-сегмента содержит значительно больше полей, чем заголовок UDP, что отражает более развитые возможности протокола TCP (рис. 17.5). Краткие описания боль шинства полей помещены на рисунке, а более подробно мы их рассмотрим, когда будем изучать функции протокола TCP. Коротко поясним значение однобитных полей, называемых флагами, или кодовыми битами (code bits). Они расположены сразу за резервным полем и содержат служебную информацию о типе данного сегмента. Положительное значение сигнализируется уста новкой этих битов в единицу: □ URG — срочное сообщение; □ АСК — квитанция на принятый сегмент; □ PSH — запрос на отправку сообщения без ожидания заполнения буфера; □ RST — запрос на восстановление соединения; □ SYN — сообщение, используемое для синхронизации счетчиков переданных данных при установлении соединения; Q FIN — признак достижения передающей стороной последнего байта в потоке пере даваемых данных. 560 Глава 17. Базовые протоколы TCP/IP 2 байта Порт источника (sours port) 2 байта __________ I__________ Порт приемника (destination port) Последовательный номер (sequence number) - номер первого байта данных в сегменте, определяет смещение сегмента относительно потока отправляемых данных Подтвержденный номер (acknowledgement number) - максимальный номер байта в полученном сегменте, * увеличенный на единицу Длина заголовка (hlen) Резерв (reserved) Окно (window) - количество байтов данных, ожидаемых отправителем данного сегмента, начиная с байта, номер которого указан в поле подтвержденного номера Контрольная сумма (checksum) Указатель срочности (urgent pointer) • указывает на конец данных, которые необходимо срочно принять, несмотря на переполнение буфера Параметры (options) - это поле имеет переменную длину и может вообще отсутствовать, используется для решения вспомогательных задач, например, для согласования максимального размера сегмента у ^ ^ Заполнитель (paddind) - это фиктивное поле может иметь переменную длину, ; , используется для доведения резмера заголовков до целого числа 32-битовых слов Рис. 17.5. Формат заголовка ТСР-сегмента Логические соединения — основа надежности TCP Основным отличием TCP от UDP является то, что на протокол TCP возложена дополнительная задача —* обеспечить надежную доставку сообщений, используя в качестве основы ненадежный дейтаграммный протокол IP. Для решения этой задачи протокол TCP использует метод продвижения данных с установ лением логического соединения. Как было сказано ранее, логическое соединение дает воз можность участникам обмена следить за тем, чтобы данные не были потеряны, искажены или продублированы, а также чтобы они пришли к получателю в том порядке, в котором были отправлены. Протокол TCP устанавливает логические соединения между прикладными процессами, причем в каждом соединении участвуют только два процесса. TCP-соединение является дуплексным, то есть каждый из участников этого соединения может одновременно получать и отправлять данные. На рис. 17.6 показаны сети, соединенные маршрутизаторами, на которых установлен про токол IP Установленные на конечных узлах протокольные модули TCP решают задачу Протоколы транспортного уровня TCP и UDP 561 обеспечения надежного обмена данными путем установления между собой логических соединений. Рис. 17.6. TCP-соединение создает надежный логический канал между конечными узлами При установлении логического соединения модули TCP договариваются между собой о параметрах процедуры обмена данными. В протоколе TCP каждая сторона соединения посылает противоположной стороне следующие параметры: □ максимальный размер сегмента, который она готова принимать; □ максимальный объем данных (возможно несколько сегментов), которые она разрешает другой стороне передавать в свою сторону, даже если та еще не получила квитанцию на предыдущую порцию данных (размер окна); □ начальный порядковый номер байта, с которого она начинает отсчет потока данных в рамках данного соединения. В результате переговорного процесса модулей TCP с двух сторон соединения определя ются параметры соединения. Одни из них остаются постоянными в течение всего сеанса связи, а другие адаптивно изменяются. В частности, в зависимости от загрузки буфера принимающей стороны, а также надежности работы сети динамически изменяется размер окна отправителя. Соединение устанавливается по инициативе клиентской части приложения. При необхо димости выполнить обмей данными с серверной частью приложение-клиент обращается к нижележащему протоколу TCP, который в ответ на это обращение посылает сегмент- запрос на установление соединения протоколу TCP, работающему на стороне сервера (рис. 17.7, а). В числе прочего в запросе содержится флаг SYN, установленный в 1. Получив запрос, модуль TCP на стороне сервера пытается создать «инфраструктуру» для обслуживания нового клиента. Он обращается к операционной системе с просьбой о вы делении определенных системных ресурсов для организации буферов, таймеров, счетчиков. Эти ресурсы закрепляются за соединением с момента создания и до момента разрыва. Если на стороне сервера все необходимые ресурсы были получены и все необходимые действия выполнены, то модуль TCP посылает клиенту сегмент с флагами АСК и SYN. |