Основной функцией транспортного уровня является транспортировка сообщений между приложениями узла источника и узла назначения. Приложение узла источника формирует сообщение и передает его на приложение узла назначения независимо от маршрута, т.е. независимо от протоколов сетевого уровня, и независимо от среды передачи, т.е. независимо от протоколов канального и физического уровней. Транспортный уровень реализует управление потоком информации от источника до устройства назначения.
В разделе 3.3 отмечено, что Транспортный уровень делит большое сообщение узла источника информации на части, при этом добавляет заголовок и формирует сегменты определенного объема, а короткие сообщения может объединять в один сегмент. В узле назначения происходит обратный процесс. В заголовке сегмента задаются номера порта источника и назначения, которые адресуют службы верхнего уровня приложений для обработки данного сегмента. Кроме того, транспортный уровень может обеспечивать надежную доставку пакетов. При обнаружении потерь и ошибок на этом уровне формируется запрос повторной передачи, при этом используется протокол TCP. Когда необходимость предварительного соединения и проверки правильности доставленного сообщения отсутствует, то используется более простой и быстродействующий протокол дейтаграмм пользователя (User Datagram Protocol - UDP).
Транспортный уровень моделей OSI и TCP/IP одинаков как по функциям, так и по названию (см. рис 3.5). Термин TCP/IP - это комбинация двух протоколов. Протокол IP функционирует на сетевом Уровне 3 моделиOSI, он является протоколом дейтаграммного типа без предварительного соединения (connectionless), который обеспечивает доставку сообщения через сеть по возможности, т.е. доставку с наибольшими возможными усилиями (best-effort delivery), но без гарантий, т.е. доставка не надежная.
Протокол управления передачей TCP работает на транспортном Уровне 4 модели OSI и является протоколом, ориентированным на предварительное соединение (connection-oriented), что обеспечивает контроль потока и надежность доставки. Когда эти протоколы (TCP/IP) объединены, они обеспечивают более широкий объем услуг: малую задержку и высокую надежность. Всемирная сеть Интернет строится на основе набора (стека) протоколов TCP/IP.
Контроль доставки сообщения из одного конца соединения до другого и надежность обеспечены целым рядом параметров, передаваемых в заголовках сегментов:
Транспортный уровень устанавливает логическое соединение между двумя конечными точками сети. Протоколы транспортного уровня сегментируют данные, посланные приложениями верхнего уровня на передающей стороне, и повторно собирают (реассемблируют) из полученных сегментов целое сообщение на приемной стороне.
Таким образом, протоколы транспортного уровня реализуют сегментацию данных и повторную сборку целого сообщения из полученных сегментов. Большинство сетей имеет ограничение на объем передаваемых сообщений. Поэтому Транспортный уровень делит большое сообщение прикладного уровня на сегменты данных, размер которых соответствует требованиям протокола единиц данных (Protocol Data Unit - PDU) более низких уровней сетевой модели. Кроме того, если в процессе контроля обнаружится, что принятое сообщение содержит ошибку, то возникает необходимость повторной передачи всего большого сообщения. При обнаружении ошибки в одном из принятых сегментов только данный сегмент будет передан повторно.
Мультиплексирование сегментов передаваемых данных позволяет одновременно передавать различные потоки данных. При этом высокоскоростной поток передаваемых сообщений, например видео-поток, не заблокирует другие сообщения.
На каждом конечном узле сети может быть запущено много разных приложений. Кроме того, сегменты могут быть направлены одному или многим узлам назначения. Процесс обмена данными между приложениями источника и назначения называется сеансом связи. Протоколы транспортного уровня обеспечивают многочисленные одновременно протекающие процессы обмена данными, т.е. отслеживают отдельные сеансы связи. Множество одновременно протекающих процессов обмена данными верхнего уровня (множество сеансов связи) может быть мультиплексировано поверх одного логического транспортного соединения.
Чтобы передавать потоки данных соответствующим приложениям, протокол транспортного уровня должен идентифицировать каждое приложение. В протоколах TCP и UDP в качестве идентификатора приложения используют номер порта. Номер порта в заголовке сегмента транспортного уровня указывает, какое приложение создало передаваемое сообщение, и какое должно обрабатывать полученные данные. При множестве одновременно протекающих процессах обмена данными каждому из приложений или услуг назначается свой адрес (номер порта) так, чтобы транспортный уровень мог определить, с каким конкретно приложением или службой должны взаимодействовать передаваемые данные.
Наиболее известными протоколами транспортного уровня являются протокол контроля передачи (Transmission Control Protocol - TCP) и протокол дейтаграмм пользователя (User Datagram Protocol - UDP). Протокол контроля передачи TCP является ориентированным на предварительное соединение (connection-oriented). Помимо деления сообщения на сегменты и идентификации приложений (задание номеров портов источника и назначения) TCP обеспечивает надежность и контроль потока. Он взаимодействует с протоколами верхнего прикладного уровня приложений: HTTP, SMTP, FTP, Telnet и другими. Протокол UDP является протоколом дейтаграммного типа (connectionless), он взаимодействует с такими протоколами прикладного уровня, как система доменных имен (DNS), передачи потока видеоданных (Video Steaming), голос поверх IP (Voice over IP) и рядом других. Следует отметить, что система DNS взаимодействует как с TCP, так и с UDP.
Итак, протокол транспортного уровня TCP помимо деления сообщения на сегменты и идентификации приложений обеспечивает:
Для облегчения контроля и обеспечения надежности сообщения передаются частями (порциями), т.е. сегментами. При этом протокол транспортного уровня узла источника должен прослеживать каждый сегмент данных при передаче и повторно передавать любую часть сообщения, прием которой не был подтвержден устройством назначения. Транспортный уровень конечного узла на приемной стороне должен отследить получение данных и подтвердить это получение.
Контроль потока необходим, чтобы гарантировать, что источник, передавая данные с некоторой скоростью, не переполняет буферные устройства узла назначения. Если узел назначения не может обрабатывать данные в темпе их поступления, то может произойти переполнение буферов и потеря данных. Управление скоростью передачи данных обеспечивается изменением размера окна (Window Size), который указывает, сколько байт данных должно быть передано за одну порцию. При переполнении буферных устройств узел назначения посылает источнику требование уменьшения размера окна, т.е. снижения скорости передачи.
После получения каждой порции данных узел назначения посылает источнику подтверждение принятых данных или подтверждение доставки (acknowledgment).
Подтверждение (квитирование) обеспечивает надежность сети передачи данных. Если подтверждение не получено, то неподтвержденная часть данных передается узлом источником повторно.
В дейтаграммных IP-сетях пакеты одного сообщения между двумя конечными устройствами могут проходить разными путями. Поэтому на узел назначения сегменты могут прийти не в том порядке, в котором были переданы. Надежный протокол транспортного уровня (ТСР) должен восстановить правильный порядок сегментов и собрать переданное сообщение, т.е. реассемблировать его.
Адресация приложений, надежность, контроль потока, сегментация сообщений и их реассемблирование, реализуются путем задания ряда параметров в заголовке сегмента TCP, размер которого 20 байт.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Рис. 9.1. Формат заголовка сегмента TCP | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Поля заголовка TCP сегмента определяют следующее:
Заголовок TCP (рис. 9.1) содержит номер последовательности (Sequence Number), используемый, чтобы гарантировать объединение частей (сегментов) сообщения в том порядке, в котором они были переданы. TCP обеспечивает надежность передачи сообщений за счет передачи номера подтверждения, и контроль потока, управляемого размером окна. Однако TCP потребляет много ресурсов и вносит задержку в передачу данных. При передаче некоторых видов трафика (аудио- и видеоинформация) задержка и особенно ее вариация могут исказить передаваемые сообщения.
Когда требования высокой скорости передачи данных, минимизации задержек и джиттера превалируют над надежностью и гарантией доставки сообщения, то используется более простой и быстрый протокол дейтаграмм пользователя (UDP). Протокол UDP не имеет механизма реассемблирования принятых сегментов, поэтому возможны ошибки при объединении сегментов данных при передаче по сложной сети. Однако скорость передачи данных с использованием протокола UDP выше, чем TCP.
Поскольку UDP является протоколом дейтаграммного типа, то в заголовке его сегмента (рис. 9.2) отсутствуют такие параметры, как Номер последовательности, Номер подтверждения, Размер окна, характерные для протокола TCP.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Рис. 9.2. Формат сегмента UDP | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Поля UDP сегмента определяют следующее:
Поскольку протокол UDP не обладает механизмами надежности, то она обеспечивается протоколами верхнего уровня приложений. Однако небольшой размер заголовка UDP и отсутствие дополнительной обработки номера последовательности, размера окна и пересылки подтверждения получения данных повышают скорость обработки и передачи сообщений по сравнению с протоколом ТСР. При пропадании какого-либо сегмента на видеоизображении (или в голосовом сообщении) появится помеха, которую пользователь может и не заметить. При надежной доставке (ТСР) повторная передача пропавшего сегмента может занять много времени, что приведет к значительному искажению изображения (звука). Поэтому протокол UDP используется для передачи аудио- и видеоинформации.
Комбинация номера порта и IP-адреса образует комплексный адрес, называемый сокет (socket address), который определяет не только уникальное устройство, но и программное обеспечение, используемое для создания и обработки сообщения, например, 192.168.10.17:1275; 10.1.10.6:53.
Номера портов делятся на несколько типов:
Номера известных портов заданы организацией Internet Assigned Numbers Authority (IANA), распределяющей адреса в Интернете. Номера известных портов назначаются протоколам и службам сервиса уровня приложений. Примеры номеров некоторых известных портов протокола TCP приведены в табл. 9.1
| Протоколы | FTP | Telnet | SMTP | HTTP | HTTPS | POP3 |
|---|---|---|---|---|---|---|
| Порты | 20, 21 | 23 | 25 | 80 | 443 | 110 |
В приложении протокола передачи файлов FTP используются два известных (стандартных) номера порта 20 и 21. Порт 20 используется для передачи данных, а порт 21 - для управления соединением.
Среди номеров известных портов протокола UDP наиболее распространенными являются: протокол TFTP - 69, RIP - 520.
Служба DNS с номером порта 53 и простой протокол управления сетью (Simple Network Management Protocol - SNMP) с номером порта 161 взаимодействуют как с протоколом TCP, так и с UDP.
Зарегистрированные порты назначаются как пользователям, так и приложениям. Когда зарегистрированные порты не используются для ресурсов сервера, они могут быть использованы динамически клиентом как номер порта источника. Приложения клиента выбирают номера порта источника из этого диапазона. Из зарегистрированных номеров портов можно отметить 8008 и 8080, которые часто используются Proxy-серверами.
Комплексные адреса (сокеты) широко используются при обращении клиентов к серверам. Источник запроса идентифицируется сокетом, образованным IP-адресом и номером порта, который генерируется случайным образом. Например, сокет 10.0.118.52:1244 определяет клиента, как источник запроса. Сокет 10.0.118.3:80 определяет IP-адрес устройства и программное обеспечение, используемое для обработки запроса (сервер HTTP). При ответе сервер формирует сообщение, где сокет 10.0.118.52:1244 используется в качестве адреса назначения. Разные номера портов с одним IP-адресом источника позволяют клиенту формировать несколько разных запросов.
Если необходимо узнать, какие TCP соединения активны на сетевом конечном узле, то можно использовать команду ) указаны: протокол (TCP), локальные адреса (имена) узлов с динамически назначенными номерами портов, внешние адреса (имена) узлов назначения с номером порта, а также состояние связи. В данном примере (рис 9.3) номер порта локального адреса является динамически назначаемым зарегистрированным портом источника с номером больше 1023. Для адреса www.cisco.com внешний порт задан символически (http). Состояние связи может быть с установленным соединением (ESTABLISHED) или с ожиданием окончания соединения (TIME_WAIT), когда был послан запрос окончания соединения (FIN).
(рис 9.3) Результат выполнения команды netstat
Поскольку TCP является протоколом, ориентированным на предварительное соединение (connection-oriented), то сначала необходимо установить сессию между приложениями конечных устройств. Узел отправитель инициализирует соединение, которое должно быть подтверждено узлом получателем. Программное обеспечение протокола TCP обменивается сообщениями через сеть, чтобы проверить, что передача разрешена и что обе стороны готовы к ней.
Соединение между двумя устройствами производится за три этапа (рис 9.4).
(рис 9.4) Установление соединения
Во-первых, узел отправитель инициализирует установление связи путем посылки узлу получателю запроса синхронизации SYN (1).
Во-вторых, узел получатель подтверждает запрос синхронизации и задает свои параметры синхронизации ACK (2).
В-третьих, узлу получателю посылается подтверждение, что обе стороны готовы для передачи данных (3).
Такой механизм получил название трехэтапного установления связи (Three-way handshake). Оба узла должны согласовать начальные номера последовательности передаваемых частей информации, что происходит через обмен сегментами синхронизации (SYN) и подтверждения (ACK).
Синхронизация требует, чтобы каждая сторона послала собственный начальный номер последовательности и получила подтверждение от другой стороны. Каждая сторона, получив начальный номер последовательности от другой стороны, отвечает подтверждением ACK. Например, последовательность, соответствующая рис 9.4, будет следующей:
При установлении соединения задается начальное значение номера байта передаваемых данных. Этот номер увеличивается по мере передачи байт. Поэтому на приемной стороне можно отследить потерянные сегменты.
Сегменты данных нужно предоставить пользователю получателю в том же порядке, в котором они были переданы. Сбой происходит, если какие-то сегменты данных потеряны, повреждены или получены в неверном порядке. Поэтому получатель должен подтвердить получение каждого сегмента. Однако если бы отправитель ждал ответ ACK после посылки каждого сегмента, то производительность сети была бы низкой. Поэтому, надежный, ориентированный на предварительное соединение протокол TCP, позволяет послать несколько сегментов прежде, чем отправитель получит подтверждение ACK.
Размер окна (Window Size) заголовка сегмента TCP определяет, сколько байт передается в одной порции подтверждаемых данных. Последовательность сегментов передаваемых данных представляет собой последовательность байтов. Поэтому и размер окна в заголовке сегмента задается в количестве передаваемых байтов. Узел-получатель передает отправителю подтверждение ACK, когда примет указанное в окне количество байтов данных.
На рис 9.5 приведен пример, когда размер окна составляет 3000 байт.
(рис 9.5) Процесс передачи байт данных
Каждый передаваемый сегмент содержит 1500 байт, что соответствует размеру поля данных кадра Ethernet. Поэтому узел-отправитель передает два сегмента подряд, на которые узел-получатель посылает подтверждение ACK с номером следующего ожидаемого байта, т.е. ACK = 3001. После получения узлом-отправителем подтверждения процесс передачи данных повторяется.
Если какой-то сегмент в процессе передачи был потерян, например, из-за перегрузки сети, то узел-получатель в ответе укажет начальный номер потерянного сегмента (рис 9.6), чтобы этот сегмент был передан повторно. При этом размер окна может быть уменьшен до 1500 байт, т.е. до размера одного передаваемого сегмента.
(рис 9.6) Перегрузка в процессе передачи данных
Перегрузка буферов данных может произойти по следующим причинам:
Когда данные прибывают на узел-получатель слишком быстро, то буферные устройства адресата могут оказаться перегружены и приходящие пакеты будут отбрасываться. Чтобы не потерять данные, процесс TCP на узле-получателе может послать отправителю индикатор "не готов", чтобы отправитель приостановил передачу данных.
Когда получатель вновь сможет обрабатывать дополнительные данные, он посылает индикатор "готов". Когда этот индикатор получен, отправитель может продолжить передачу.
При передаче срочных сообщений используется бит URG в поле кода передаваемых сегментов. Такие сегменты передаются в первую очередь, даже за счет впереди стоящих в очереди сегментов.
Завершение соединения в конце передачи данных происходит в 4 этапа:
На этом соединение заканчивается, т.е. завершение соединения происходит в четыре этапа.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.