logo
Сети_экзамен

Протоколы транспортного уровня tcp и udp.

К транспортному уровню стека TCP/IP относятся:

Протоколы ТСР и UDP, как и протоколы прикладного уровня, устанавливаются на конечных узлах.

Протокол UDP.

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

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

Заголовок UDP состоит из четырех 2-байтных полей:

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

Протокол TCP.

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

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

В отличие от протокола UDP, который создает свои дейтаграммы на основе логически обособленных единиц данных — сообщений, генерируемых приложениями, протокол ТСР делит поток данных на сегменты без учета их смысла или внутренней структуры.

Заголовок ТСР-сегмента содержит значительно больше полей, чем заголовок UDP, что отражает более развитые возможности протокола ТСР.

Основным отличием ТСР от UDP является то, что на протокол ТСР возложена дополнительная задача — обеспечить надежную доставку сообщений, используя в качестве основы ненадежный дейтаграммный протокол IP.

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

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

Получив запрос, модуль ТСР на стороне сервера пытается создать «инфраструктуру» для обслуживания нового клиента. Он обращается к операционной системе с просьбой о выделении определенных системных ресурсов. Если на стороне сервера все необходимые ресурсы были получены и все необходимые действия выполнены, то модуль ТСР посылает клиенту сегмент с флагами АСК и SYN. В ответ клиент посылает сегмент с флагом АСК и переходит в состояние установленного логического соединения (состояние ESTABLISHED). Когда сервер получает флаг АСК, он также переходит в состояние ESTABLISHED. На этом процедура установления соединения заканчивается, и стороны могут переходить к обмену данными.

Соединение может быть разорвано в любой момент по инициативе любой стороны. Для этого клиент и сервер должны обменяться сегментами FIN и АСК. Соединение считается закрытым по прошествии некоторого времени, в течение которого сторона-инициатор убеждается, что ее завершающий сигнал АСК дошел нормально и не вызвал никаких «аварийных» сообщений со стороны сервера.