2.3. Tcp, udp и другие
Transmission Control Protocol — это протокол, который используется для обеспечения услуг по надёжной упорядоченной доставке данных. Это протокол транспортного уровня эталонной модели ISO/OSI.
Протокол TCP тесно завязан на IP и выполняет в Internet очень важную транспортную функцию, и именно поэтому часто технологию, основанную на IP, называют не просто технологией IP, a TCP/IP. TCP/IP — это технология межсетевого взаимодействия, технология internet. Сеть, которая использует технологию internet, называется internet4.
Термин "TCP/IP" обычно обозначает всё, что связано с протоколами TCP и IP. Он охватывает целое семейство протоколов, прикладные программы и даже саму сеть. В состав семейства входят протоколы TCP, UDP, ICMP, telnet, FTP и многие другие. Иерархия протоколов семейства TCP/IP показана5 на рис. 2.1
Рис. 2.1: Иерархия протоколов семейства IP
TCP предоставляет более высоким уровням транспортную услугу— так называемое ТСР-соединение, являющееся разновидностью виртуального канала.
Примечание. Дадим краткие разъяснения к рис. 2.1. На этом рисунке представлены для примера следующие протоколы из великого семейства IP:
TCP См. RFC 793, 962, 1072, 1078, 1185, 1323, 1644, 1693 и т.д. UDP См. RFC 768, 1240 и т.д.
FTP — протокол пересылки файлов. С помощью этого протокола организовывается пересылка файлов по Сети. Технические подробности можно узнать из RFC-документации, а именно: RFC 468, 478, 959, 1579, 1635, 1639.
Telnet — протокол эмуляции терминала удалённой машины. С помощью этого протокола организовываются сеансы работы на удалённых машинах сети — эмулируется терминал далёкого компьютера. NIC просто изобилует информацией в виде RFC-документов по этому протоколу. Вот лишь некоторые из этих документов: RFC 854, 764, 818, 1184, 1408, 1411, 1412, 1416, 1572.
SMTP — протокол пересылки простой почты — протокол, обеспечивающий работу e-mail. См. техническую документацию в RFC 788, 821, 822, 1123, 1651, 1733.
TFTP — протокол простейшей (тривиальной) пересылки файлов. Осуществляет пересылку файлов дейтаграммными средствами UDP. См. RFC 1350.
DNS — протокол доменной (региональной) системы имён — протокол запросов на преобразование имён из доменной формы в машинную —числовую. См. RFC 883,974,1101,1183,1611,1612, 1706 и т.д.
Служба времени — служба синхронизации разнесённых в сети часов. Это протокол сетевого времени — NTP. См. RFC 956-958, 1129, 1165, 1305 и т.д.
RIP — информационный протокол маршрутизации. Используется для поддержания достоверной информации о состоянии сети, необходимой для маршрутизации. Описан в RFC 1058, 1721-1724.
GGP — протокол "шлюз — шлюз" — межшдюэовый протокол. Этот протокол использовался в объединённой сети Internet— ARPAnet. Ныне представляет чисто исторический интерес. См. RFC 823.
НМР — протокол мониторинга хоста — протокол непрерывного слежения (контроля) за хостом (сетевым рабочим компьютером). См. RFC 869.
EGP — внешний межшлюзовый протокол. Этот протокол используется при взаимодействии отдельных шлюзов различных автономных систем (AS), осуществляемом с целью обмена маршрутной информацией. См. RFC 827, 888, 890, 904, 911, 1092;
ICMP — протокол межсетевых управляющих сообщений — сетевой протокол, предоставляющий процессам в сети возможность предпочтительного выбора в своём множестве маршрутов пересылки и других подобных вещей. Хотя он пользуется транспортными услугами IP, в действительности, ICMP является важной частью IP, именно поэтому мы его так выделили на рисунке. См. документы RFC 777, 792, 1256.
Протоколы IGP, GGP и ICMP транспортными не являются. Эти протоколы являются служебными — они обеспечивают работу сетевого уровня. Без них IP был бы не дееспособен. Таким образом, если исходить из их функционального предназначения, эти протоколы следовало бы отнести к межсетевому уровню, т.е. поставить в один ряд с IP. Но наша схема показывает только "кто на ком ездит". IGP, GCP и ICMP базируются на IP, поэтому мы их и поставили выше.
Транспортными являются только протоколы TCP и UDP, — именно они организуют транспортные услуги, которыми пользуются все протоколы более высокого уровня.
Продолжим описание процесса передачи данных с помощью протокола ТСР.
Виртуальный канал — это просто такая волшебная трубочка. То, что кладётся в нее с одной стороны, волшебным образом появляется в целости и сохранности на другом конце, причем, именно в таком порядке, каком всё входило в неё на исходном конце. И эта трубочка обладает удивительным свойством: она может пересылать одновременно в двух направлениях. Сейчас мы всё это волшебство рассмотрим внимательно и увидим, конечно, что ничего волшебного там нет, а всё очень просто.
Протокол TCP занимается пересылкой больших объёмов информации, используя для этого возможности протокола IP. Как это делается? Вполне здраво можно рассмотреть следующую ситуацию. Нужно переслать книгу по почте, но та принимает только письма и ничего более? Что делать? Очевидный метод: просто разодрать её на страницы и отправить их отдельными конвертами. Получатель, руководствуясь номерами страниц, легко сможет книгу восстановить. Этим простым и естественным методом и пользуется TCP. Схема передачи для этого случая представлена на рис.2.2.
TCP-модуль делит информацию, которую надо переслать, на несколько частей приемлемого размера. Нумерует каждую часть, чтобы позже восстановить порядок. Чтобы пересылать эту нумерацию вместе с данными, он обкладывает каждый такой фрагмент своей обложкой — конвертом, который содержит служебную информацию. Это и есть TCP-конверт. Далее он передаёт этот получившийся ТСР-пакет модулю сетевого уровня — IP-модулю, который помещает каждый переданный ему сверху блок данных (TCP-пакет.) в отдельный IP-конверт, указывает на нём, куда и кому (какому модулю транспортного уровня) его нужно передавать, — получается IР-пакет, с которым сеть уже умеет обращаться. Откуда IP-модуль узнает, какой сетевой адрес следует указывать на IP-конверте? Этот адрес ему сообщает ТСР-модуль.
Что делает с информацией при пересылке "простым и естественным" способом отправитель, схематично показано на рис. 2.3.
Немного об аналогиях этой схемы. Отдельные листы книги — это аналог TCP- пакетов: на них в колонтитуле указано, из какой они книги, а также имеется информация об их положении в исходной последовательности (номера страниц). Большие конверты, в которые укладываются отдельные листы (каждый лист — в отдельный конверт), — это аналоги IP-пакетов: они содержат полную адресную информацию (адреса получателя и отправителя). Маленькие конверты — это _аналоги пакетов локальных сетей, используемых в качестве среды передачи (например, Ethernet): на них указана полная адресная информация локальной сети. IP-пакеты для пересылки упаковываются в пакеты, используемые самой средой передачи данных. При этом, если IP-пакет не помещается в отдельный пакет локальной сети, он разбивается на несколько частей подходящего размера. Точнее не просто разбивается, а разделяется на несколько IP-пакетов. IP-пакет несёт информацию, необходимую для отслеживания подобных случаев "разборки" IP-пакета и обратной его "сборки". Далее для простоты картины будем считать, что разборки и обратной сборки нет.
Итак, отправитель передал IP-пакеты в Сеть. Доставка получателю — забота сетевого уровня.
При собственно пересылке по Сети эти фрагменты (IP-пакеты) перемежаются с другими аналогичными от других пользователей, поэтому пересылка получается достаточно дешёвой, IР-пакеты пересылаются независимо друг от друга и потихоньку (за пару-тройку десятых секунды (0,2-0,3 с)), а то и быстрее, доходят до получателя.
Получатель по получении распаковывает IP-конверты, на которых указано, что в них лежат ТСР-конверты, и передаёт их содержимое ТСР-модулю. TCP-модуль, в свою очередь, распаковывает эти переданные ему снизу блоки данных, которые должны быть TCP-пакетами, проверяет правильность пересылки, и пометает содержащиеся в них данные в последовательность частей в соответствующее место. Если чего-то не достаёт, он требует переслать этот кусочек снова. В конце концов, информация собирается в нужном порядке и полностью восстанавливается. Вот теперь этот массив пересылается выше к пользователю (на диск, на экран, на печать).
TCP-протокол
UDP-протокол
TCP – высокие надежность, помехоустойчивость
Рис.2.2 Принципы передачи протоколами TCP, UDP
Рис. 2.3: Передача данных в многоуровневой модели
В действительности, это слегка утрированный взгляд на TCP. В реальности пакеты не только теряются, но и могут искажаться при передаче из-за наличия помех на линиях связи. TCP решает и эту проблему. Для этого он пользуется системой кодов, исправляющих ошибки. Существует, целая наука о таких кодировках. Простейшим примером такового служит код с добавлением к каждому пакету контрольной суммы (и к каждому байту бита проверки на чётность). При помещении в TCP-конверт вычисляется контрольная сумма, которая записывается в TCP-заголовок. Если при приёме заново вычисленная сумма не совпадает с той, что указана на конверте, значит что-то тут не то, — где-то в пути имели место искажения, так что надо переслать этот пакет по-новой, что и делается.
Протокол TCP требует, чтобы все отправленные данные были подтверждены принявшей их стороной. Он использует ожидания "(таймауты) и повторные передачи для обеспечения надёжной доставки. Отправителю разрешается передавать некоторое количество данных, не дожидаясь подтверждения приёма ранее отправленных. Таким образом, между отправленными и подтверждёнными данными существует окно уже отправленных, но ещё не подтверждённых данных. Количество байт, которое можно передавать без подтверждения, называется размером окна. Как правило, размер окна устанавливается в стартовых файлах сетевого программного обеспечения.
Так как TCP-канал является дуплексным, т.е. информация может передаваться по нему одновременно в обоих направлениях, то подтверждения для данных, идущих в одном направлении, могут передаваться вместе с данными, идущими в противоположном направлении. Приёмники на обеих сторонах виртуального канала выполняют управление потоком передаваемых данных для того, чтобы не допускать переполнения буферов.
Таким образом, протокол TCP обеспечивает гарантированную доставку с установлением логического соединения в виде байтовых потоков. Он освобождает прикладные процессы от необходимости использовать ожидания и повторные передачи для обеспечения надёжности. Наиболее типичными прикладными процессами, использующими TCP, являются ftp, telnet и e-mail. Кроме того, TCP использует система X-Windows (стандартный многооконный графический интерфейс), "г-команды".
Большие возможности TCP даются не бесплатно, реализация TCP требует большой производительности процессора и большой пропускной способности сети. Когда прикладной процесс начинает использовать TCP, то начинают общаться модуль TCP на машине отправителя и модуль TCP на машине получателя. Эти два оконечных модуля TCP поддерживают информацию о состоянии соединения — виртуального канала. Этот виртуальный канал потребляет ресурсы обоих оконечных модулей TCP. Канал этот, как уже указывалось, является дуплексным.
Конец TCP-канала называют TCP-портом, т.е. TCP-порт — это конец той самой волшебной трубочки, куда нужно заливать информацию для её передачи. Залитая в один конец волшебной трубочки информация польётся в целости и сохранности из другого её конца.
Проще говоря, один прикладной процесс пишет данные в свой TCP-порт, откуда они модулями соответствующих уровней по цепочке передаются по сети и выдаются в TCP-порт на другом конце канала, и другой прикладной процесс читает их отсюда — из своего ТСР-порта.
Для ясности и полноты картины, необходимо сделать здесь важное замечание: модуль TCP разбивает поток байтов на фрагменты, не сохраняя при этом границ между записями. То есть, если один прикладной процесс помещает 3 блока данных в TCP-порт, то со всем не обязательно, что другой прикладной процесс на другом конце виртуального канала получит из своего TCP-порта именно 3 блока данных, причём именно таких (по разбиению), что были переданы с другого конца. Меня информация будет получена исправно и с сохранением порядка, передачи, но она может уже быть разбита по-другому и на иное количество частей. Не существует зависимости между числом и размером записываемых сообщений с одной стороны и числом и размером считываемых сообщений с другой стороны.
Для наглядности продемонстрируем процесс передачи приложения, пример которого представлен на рис. 2.3. He теряя общности, можно для определённости предполагать, что в качестве среды передачи используется локальная сеть Ethernet.
Ethernet может использоваться любыми технологиями сетевого уровня: DECnet, Novell, TCP/IP. Более того, они могут использоваться одновременно в одной и той же локальной сети независимо друг от друга! Трафики этих сетей будут абсолютно независимы и друг с другом взаимодействовать не будут. Вернёмся к нашим «баранам».
На рис. 2.4. вы видите, что творится с данными при их отправке по TCP-каналу. Маленькие прямоугольники с надписями TCP, IP и Eth, подклеенные к началам блоков данных, суть протокольные заголовки соответственно TCP, IP и Ethernet. Маленькое уточнение: TCP и IP всю свою служебную информацию помещают в заголовок, а Ethernet часть своей информации помешает в заголовок, а контрольную сумму — в конец пакета, именно эта контрольная сумма (check summ) представлена на рисунке прямоугольником с надписью chk.
На конце отправителя ситуация очевидна. Теперь получившиеся Ethenet-пакеты пересылаются по физическому уровню сети Ethernet. При этом возможны сбои в работе сети, часть пакетов может потеряться, часть может где-то (например, в мостах) ненароком задержаться, и "гулять" по сети дольше других, информация в пакетах может исказиться. То, что придёт на другой конец Ethernet-линии, будет представлять мешанину из того, что было послано.
Рис. 2.4: Схема обработки данных, производимой отправителем
Рис. 2.5: Схема обработки данных, производимой получателем
Откуда сеть Ethernet узнает, кому доставлять послания? Мы это уже выяснили в разговоре о сетевом уровне. Поднявшись на следующий уровень, мы можем и должны вообще забыть о том, как работают уровни ниже данного. Это сильно упрощает работу. В этой простоте — сила многоуровневой схемы ISO/OSI. Теперь смотрите на рис.2.5. Там вы видите, что происходит с данными по их получении на другом конце.
Видите, пакет, с блоком "И !" между IP-уровнем и ТСР-уровнем перескакивает в конец последовательности. Этим мы хотели показать, что возможно перемешивание порядка пакетов даже на уровне IP. Хотя, вообще говоря, такое поведение этого пакета можно объяснить и по-другому: просто TCP-уровень обнаружил искажение информации пакета и затребовал повторной пересылки этого блока данных.
Итак, восстановление целостности информации и её порядка происходит на TCP-уровне. TCP, однако, не сохраняет границ тех блоков, которые ему были спущены сверху — это хорошо видно при сравнении рисунков: отправитель передал TPC-модулю блоки "ДЭВИ! ", "ГДЕ, " БАРАНЫ?", а его коллега-получатель получил блоки "ДЭВ", "И! ", "ГДЕ", " БА", "РАН", "Ы?".
Итак, TCP эмулирует выделенную линию связи двух пользователей. Гарантирует неизменность передаваемой информации. Что входит на одном конце, выйдет с другого. Хотя в действительности никакая прямая линия отправителю и получателю в безраздельное владение не выделяется, другие пользователи могут пользовать те же узлы и каналы связи в сети в промежутках между пакетами этих двух, но извне это, практически, именно так и выглядит.
Как бы хорошо это не звучало, однако, это не панацея. Как уже отмечалось, установка TCP-виртуального канала связи требует расходов на инициирование и поддержание соединения и приводит к задержкам передачи. Если вся эта суета — излишество, лучше обойтись без неё. Если все данные, предназначенные для пересылки, умещаются в одном пакете, и если вас не особенно заботит надёжность доставки8, то можно обойтись без TCP.
Имеется другой стандартный протокол транспортного уровня, который не отягощен такими накладными расходами. Этот протокол называется UDP — User Datagram Protocol — протокол пользовательских дейтаграмм. Он используется вместо TCP. Здесь данные помещаются не в TCP, а в UDP-конверт (рис.2.2), который также помещается в IP-конверт. Этот протокол реализует дейтаграммный способ передачи данных. Хотя IP-пакет есть дейтаграмма, он по своему уровню не пригоден для прямого использования в прикладных процессах, например, хотя бы из соображений соответствия передачи эталонной модели ISO/OSI.
Дейтаграмма — это пакет, передаваемый через сеть независимо от других пакетов без установления логического соединения и подтверждения приёма. Дейтаграмма совершенно самостоятельна, поскольку она сама содержит всю необходимую для её передачи информацию. Например, TCP-пакет не является дейтаграммой, поскольку содержит только номер TCP-канала, а собственно адресная информация содержится только в заголовке IP- пакета, в который помещается ТСР-пакет.
Передача дейтаграммы происходит безо всякого предварения и подготовки. Дейтаграммы, сами по себе, ire содержат средств обнаружения и исправления ошибок передачи, поэтому при передаче данных с их помощью следует принимать меры по обеспечению надёжности пересылки информации. Методы организации надёжности могут быть самыми разными, обычно же используется метод подтверждения приёма посылкой отклика при получении каждой дейтаграммы.
UDP проще TCP, поскольку он не заботится о возможной пропаже данных, пакетов, о сохранении правильного порядка данных и т.д. UDP используется для приложений, которые посылают только короткие сообщения и могут просто повторить своё послание, если отклик с подтверждением не придёт достаточно быстро.
Предположим, что вы пишете программу, которая просматривает базу данных с телефонными номерами где-нибудь в другом месте сети. Совершенно незачем устанавливать TCP связь, чтобы передать 33 или около того символов в каждом направлении. Вы можете просто уложить, имя в UDP-пакет, запаковать это в IP-пакет и послать.
На другом конце прикладная программа получит пакет, прочитает имя, посмотрит телефонный номер, положит его в другой VDP-пакет и отправит обратно. Что произойдёт, если пакет по пути потеряется? Ваша программа должна действовать так: если она ждёт ответа слишком долго и становится ясно, что пакет затерялся, она должна повторить свой запрос, т.е. послать ещё раз то же самое. Так обеспечивается надёжность передачи при использовании протокола UDP.
В отличие от TCP, данные, отправляемые прикладным процессом транспортными средствами UDP, достигают места назначения как единое целое. Например, если процесс-отправитель производит 3 записи в 1ЮР-порт, то процесс-получатель должен будет сделать 3 чтения из своего UDP-nopma. Размер каждого записанного сообщения будет совпадать с размером соответствующего прочитанного. Протокол UDP сохраняет границы сообщений, определяемые прикладным процессом. Он никогда не объединяет несколько сообщений в одно целое и не делит одно сообщение на части.
Альтернатива TCP-UDP позволяет программисту гибко и рационально использовать предоставленные ресурсы, исходя из своих возможностей и. потребностей. Если нужна надёжная доставка, то лучше может быть TCP. Если нужна доставка дейтаграмм, то — UDP. Если нужна эффективная доставка по длинному и ненадёжному каналу передачи данных, то лучше использовать TCP. Если нужна_ эффективность на быстрых сетях с короткими соединениями, лучше всего будет JJDP. Если потребности не попадают ни в одну из этих категорий, то выбор транспортного протокола не ясен. Прикладные программы, конечно, могут устранять некоторые недостатки выбранного транспортного средства. Например, если вы выбрали UDP, а вам необходима надежность, то ваша прикладная программа должна обеспечить её сама, как описано выше: требовать подтверждения, пересылки утерянных или увечных пакетов и т.д. Если вы выбрали TCP, а вам нужно передавать записи, то прикладная программа должна вставлять метки в поток байтов так, чтобы можно было различить записи.
До сих пор мы ничего не сказали о том, возможно ли создание и одновременное использование нескольких виртуальных каналов. Естественно, было бы удобно, если бы транспортная компонента (TCP и UDP) могла предоставлять услуги по доставке данных сразу многим процессам более высокого уровня.
Мы уже намекали, что в Internet прикладные процессы осуществляют доступ к услугам транспортного уровня в различных точках, называемых портами. Порт в данном случае — чистая абстракция, весь cмысл которой заключён в её номере. Номер порта указывается среди прочей служебной информации в заголовке пакета транспортного уровня. Именно по этому номеру порта модуль (процесс) транспортного уровня различает данные разных процессов прикладного уровня.
Информация, помещённая каким-либо прикладным процессом в порт с номером N на компьютере отправителя, будет передана транспортной компоненте адресата, которая выдаст его получателю прикладного уровня в порт с указанным номером К. Таким образом, номера портов определяют не только получателя, но и отправителя.
Например, на компьютере одновременно могут работать telnet, ftp, e-mail потому, что они используют различные TCP-порты. Одновременно с ними может работать ещё и множество приложений, использующих разные VDP-порты, к примеру, NFS, TFTP, DNS.