 |
Концепция портов. Мультиплексирование и демультиплексирование
|
|
|
|
Транспортные протоколы. Протоколы TCP и UDP.
Транспортный уровень отвечает за доставку сообщений в том порядке, в каком они были отправлены, без потерь и дублирования. Сложность транспортного протокола определяется возможностями сети и Канальных уровней. В случае надежного Сетевого уровня от Транспортного уровня требуется лишь передать данные на следующий уровень. Если же Сетевой или Канальный уровень ненадежен, то Транспортный уровень должен контролировать последовательности пакетов, а также подтверждать их прием, обнаруживать и исправлять ошибки. Транспортный уровень отвечает за следующие функции.
- Прием сообщений с более высокого уровня и их сегментацию (если это необходимо).
- Надежную доставку сообщений с передачей подтверждений о приеме.
- Слежение за тем, чтобы компьютер-отправитель не передавал данные, если приемные буферы полностью заполнены.
- Мультиплексирование нескольких потоков межпроцессных сообщений или сеансов для одного логического соединения и отслеживание принадлежности сообщений сеансам.
Транспортные протоколы с установлением соединения разработаны для передачи большого количества данных, при этом информация должна быть разбита на сегменты, умещающиеся в отдельных пакетах. Сегментация данных и нумерация сегментов являются важным элементом процесса передачи и помимо этого делают осуществимым выполнение других функций, таких как исправление ошибок. Процесс маршрутизации, выполняемый на Сетевом уровне, является динамическим, и в случае передачи данных возможно возникновение ситуации, когда сегменты следуют до места назначения разными путями и приходят не в том порядке, как они были отправлены. Нумерация сегментов позволяет принимающей системе восстановить исходный порядок следования сегментов. Эта нумерация также дает возможность системе-получателю сообщить отправителю, какой из пакетов был поврежден или потерян. В результате, отправитель может не повторять целиком всю передачу, а повторно переслать только потерянные сегменты.
Управление потоком данных (flow control) - это одна из функций, обычно предоставляемая протоколами Транспортного уровня с установлением соединения. Она представляет собой механизм, согласно которому система, принимающая данные, может сообщить отправителю о том, что он должен снизить скорость передачи данных, или об опасности перегрузки системы получателя и потери данных.
Эталонная модель OSI определяет две формы исправления ошибок, которые могут быть реализованы протоколами Транспортного уровня с установлением соединения. Одна из них - это реакция на ошибки, обнаруженные другими протоколами стека. Данный механизм не предусматривает поиска ошибок передачи самим протоколом Транспортного уровня. Вместо этого, протокол Транспортного уровня получает извещение от протоколов Сетевого или Канального уровня о том, что возникла ошибка, и определенный пакет был потерян или поврежден. Ему остается только послать сообщение, содержащее перечень пакетов и запрос на их повторную пересылку обратно системе-отправителю.
Другая, форма исправления ошибок на Транспортном уровне представляет собой законченный процесс, начинающийся с обнаружения ошибок и заканчивающийся их коррекцией. Этот процесс охватывает и ошибки, которые еще не были обнаружены каким-либо другим способом. Механизм выявления ошибок Транспортного уровня обеспечивает контроль ошибок на всем участке между двумя конечными системами и включает в себя возможность исправления ошибок, которая осуществляется путем запроса у отправителя повторной передачи определенных пакетов.
|
|
|
Концепция портов. Мультиплексирование и демультиплексирование
|
|
|
Как уже было отмечено, главная задача транспортного уровня заключается в передаче данных между прикладными процессами. Эту задачу решают протокол управления передачей (Transmission Control Protocol, TCP) и протокол пользовательских дейтаграмм (User Datagram Protocol, UDP). Протоколы TCP и UDP имеют много общего. Тот и другой обеспечивают интерфейс с вышележащим прикладным уровнем, передавая данные, поступающие на входной интерфейс хоста, соответствующему приложению. При этом, оба протокола используют концепции «порт» и «сокет». Оба они также поддерживают интерфейс с нижележащим сетевым уровнем IP, упаковывая свои PDU в IP-пакеты. Однако, как мы увидим далее, различий между TCP и UDP гораздо больше, чем сходств.
Каждый компьютер может выполнять несколько процессов, более того, прикладной процесс тоже может иметь несколько точек входа, выступающих в качестве адреса назначения для пакетов данных. Поэтому после того, как пакет средствами протокола IP доставлен на сетевой интерфейс компьютера-получателя, данные необходимо переправить конкретному процессу получателю.
Существует и обратная задача: пакеты, которые отправляют в сеть разные приложения, работающие на одном конечном узле, обрабатываются общим для них протоколом IP. Следовательно, в стеке должно быть предусмотрено средство «сбора» пакетов от разных приложений для передачи протоколу IP. Эту работу выполняют протоколы TCP и UDP.
Процедура приема данных протоколами TCP и UDP, поступающих от нескольких различных прикладных служб, называется мультиплексированием. Обратная процедура – процедура распределения протоколами TCP и UDP поступающих от сетевого уровня пакетов между набором высокоуровневых служб – называется демультиплексированием.
Рис. 1. Мультиплексирование и демультиплексирование на транспортном уровне.
Протоколы TCP и UDP ведут для каждого приложения две очереди: очередь пакетов, поступающих к данному приложению из сети, и очередь пакетов, отправляемых данным приложением в сеть. Пакеты, поступающие на транспортный уровень, организуются операционной системой в виде множества очередей к точкам входа различных прикладных процессов. В терминологии TCP/IP такие системные очереди называются портами, причем входная и выходная очереди одного приложения рассматриваются как один порт. Для однозначной идентификации портов им присваивают номера. Номера портов используются для адресации приложений.
|
|
|
Если процессы представляют собой популярные общедоступные службы, такие как FTP, telnet, HTTP, TFTP, DNS и т.п., то за ними закрепляются стандартные, назначенные номера, также называемые хорошо-известными (популярными) (well-known) номерами портов. Так, номер 21 закреплен за службой удаленного доступа к файлам FTP, а 23 – за службой удаленного управления telnet. Назначенные номера являются уникальными в пределах Интернета и назначаются приложениям централизованно из диапазона от 0 до 1023.
Для тех приложений, которые еще не стали столь распространенными, чтобы закреплять за ними стандартные номера, номера портов назначаются разработчиками этих приложений или операционной системой локально в ответ на поступление запроса от приложения. На каждом компьютере операционная система ведет список занятых и свободных номеров портов. При поступлении запроса от приложения, выполняемого на данном компьютере, операционная система выделяет ему первый свободный номер. Такие номера называют динамическими. В дальнейшем все сетевые приложения должны адресоваться к данному приложению с указанием назначенного ему порта. После того как приложение завершит работу, выделенный ему локальный номер порта возвращается в список свободных и может быть назначен другому приложению. Динамические номера являются уникальными в пределах каждого компьютера, но при этом обычной ситуацией является совпадение номеров портов приложений, выполняемых на разных компьютерах. Как правило, клиентские части известных приложений (DNS, WWW, FTP, telnet и др.) получают динамические номера портов от ОС.
Все, что было сказано о портах, в равной степени относится к обоим протоколам транспортного уровня (TCP и UDP). В принципе нет никакой зависимости между назначением номеров для приложений, использующих протокол TCP, и приложений, работающих с протоколом UDP. Приложения, которые передают данные на уровень IP по протоколу UDP, получают номера, называемые UDP-портами. Аналогично приложениям, обращающимся к протоколу TCP, выделяются TCP-порты. В том и другом случаях это могут быть как назначенные, так и динамические номера. Диапазоны чисел, из которых выделяются TCP- и UDP-портов, совпадают: от 0 до 1023 для назначенных и от 1024 до 65535 для динамических. Однако никакой связи между назначенными номерами TCP- и UDP-портов нет.
|
|
|
Протокол UDP, являясь дейтаграммным протоколом, реализует сервис по возможности, то есть не гарантирует доставку своих сообщений, а, следовательно, никоим образом не компенсирует ненадежность дейтаграммного протокола IP.
Единица данных протокола UDP называется UDP-пакетом или пользовательской дейтаграммой (user datagram). Каждая дейтаграмма переносит отдельное пользовательское сообщение. Это приводит к естественному ограничению: длина дейтаграммы UDP не может превышать длины поля данных протокола IP, которое, в свою очередь, ограничено размером кадра технологии нижнего уровня. Поэтому если UDP-буфер переполняется, то данные приложения отбрасываются. Заголовок UDP-пакета, состоящий из четырех 2-байтовых полей, содержит поля порт источника, порт получателя, длина UDP и контрольная сумма. Поля порт источника и порт получателя идентифицируют передающий и получающий процессы.
Поле длина UDP содержит длину пакета UDP в байтах.
Поле контрольная сумма содержит контрольную сумму пакета UDP, вычисляемую по всему пакету UDP с добавленным псевдозаголовком.
Псевдозаголовок формируется исключительно для работы с контрольной суммой и имеет следующую структуру.
Поле протокол (длина 8 бит) идентифицирует протокол из заголовка пакета IP. Для UDP это значение равно 17.
Судя по простоте заголовка, протокол UDP очень сложным не является. Здесь стоит прямо сказать о том, чего UDP не делает. Итак, UDP не занимается контролем потока, контролем ошибок, повторной передачей после приема испорченного сегмента. Его функции сводятся к мультиплексированию и демультиплексированию данных между сетевым и прикладным уровнями. Для процессов, которым хочется управлять потоком, контролировать ошибки и временные интервалы, протокол UDP – это как раз то, что нужно. Одной из областей, где UDP применяется особенно широко, является область клиент-серверных приложений. Зачастую клиент посылает короткий запрос серверу и надеется получить короткий ответ. Если запрос или ответ теряется, клиент по прошествии определенного интервала может попытаться еще раз. Это позволяет не только упростить код, но и уменьшить требуемое количество сообщений по сравнению с протоколами, которым требуется начальная настройка.
|
|
|
Давайте рассмотрим, как протокол UDP решает задачу демультиплексирования. Казалось бы, для этой цели достаточно использовать номера портов. Кадры, несущие UDP-дейтаграммы, прибывают на сетевой интерфейс хоста, последовательно обрабатываются протоколами стека и, наконец, поступают в распоряжение протокола UDP. UDP извлекает из заголовка номер порта назначения и передает данные на соответствующий порт соответствующему приложению, то есть выполняет демультиплексирование.
Протокол TCP (Transmission Control Protocol) обеспечивает надежную транспортировку данных между прикладными процессами путем установления логического соединения.
Информация, поступающая к протоколу TCP от протоколов более высокого уровня, рассматривается протоколом TCP как неструктурированный поток байтов. Поступающие данные буферизируются средствами TCP. Для передачи на сетевой уровень из буфера «вырезается» некоторая непрерывная часть данных, которая называется сегментом. Сегмент состоит из фиксированного 20-байтного заголовка (плюс необязательная часть), за которой могут следовать байты данных. Размер сегментов определяется программным обеспечением TCP. Оно может объединять в один сегмент данные, полученные в результате нескольких операций записи, или, наоборот, распределять результата одной записи между несколькими сегментами. Размер сегментов ограничен двумя пределами. Во-первых, каждый сегмент, включая TCP-заголовок, должен помещаться 65 515-байтное поле полезной нагрузки IP-пакета. Во-вторых, в каждой сети есть максимальная единица передачи (MTU, Maximum Transfer Unit), и каждый сегмент должен помещаться в MTU. На практике размер максимальной единицы передачи составляет обычно 1500 байт (что соответствует размеру поля полезной нагрузки Ethernet), и таким образом определяется верхний предел размера сегмента.
4.1. Формат TCP-пакета
Заголовок TCP-сегмента содержит значительно больше полей, чем заголовок UDP, что отражает более развитые возможности первого протокола.
Рис. 5. Формат заголовка сегмента TCP.
Поле порт источника (Source Port) занимает 2 байта и идентифицирует процесс-отправитель.
Поле порт получателя (Destination Port) занимает 2 байтаи идентифицирует процесс-получатель.
Поля порядковый номер (Sequence Number) (длина 4 байта) и номер подтверждения (acknowledgement number) (длина 4 байта) нумеруют каждый отправленный или полученный байт данных. Реализуются как целые числа без знака, которые сбрасываются, когда достигают максимального значения. Каждая сторона ведет собственную порядковую нумерацию.
Поле длина заголовка занимает4 бита и представляет собой длину заголовка TCP-сегмента, измеренную в 32-битовых словах. Длина заголовка не фиксирована и может изменяться в зависимости от значений, устанавливаемых в поле параметры.
Поле резерв (Reserved) занимает 6 бит.
Поле флаги (Code Bits) занимает 6 бит и содержит шесть 1-битовых флагов:
- флаг URG (Urgent Pointer – указатель точности) устанавливается в 1 в случае использования поля указатель на срочные данные;
- флаг ACK (Acknowledgment – подтверждение) устанавливается в 1 в случае, если поле номер подтверждения содержит данные. В противном случае это поле игнорируется;
- флаг PSH (Push – выталкивание) означает, что принимающий стек TCP должен немедленно информировать приложение о поступивших данных, а не ждать пока буфер заполнится;
- флаг RST (Reset – сброс) используется для отмены соединения: из-за ошибки приложения, отказа от неверного сегмента, попытки создать соединение при отсутствии затребованного сервиса;
- флаг SYN (Synchronize – синхронизация) устанавливается при инициировании соединения и синхронизации порядкового номера;
- флаг FIN (Finished – завершение) используется для разрыва соединения. Он указывает, что отправитель закончил передачу данных.
Поле размер окна (Window) (длина 2 байта) содержит количество байт, которое может быть послано после байта, получение которого уже подтверждено.
Поле контрольная сумма (Checksum) (длина 2 байта) служит для повышения надежности. Оно содержит контрольную сумму заголовка, данных и псевдозаголовка, показанного на рис. 7. При выполнении вычислений поле контрольная сумма устанавливается равным нулю, а поле данных дополняется нулевым байтом, если его длина представляет собой нечетное число. Алгоритм вычисления контрольной суммы просто складывает все 16-разрядные слова в дополнительном коде, а затем вычисляет дополнение для всей суммы. В результате, когда получатель считает контрольную сумму всего сегмента, включая поле контрольная сумма, результат дожжен быть равен нулю.
|
|
|
