Чем отличается протокол TCP от UDP, простым языком.

На канальном и сетевом уровне протоколов TCP / IP пакета , которые касаются основного механизма передачи блоков данных между странами и между сетями, являются основами TCP / IP . Они используют стек протоколов, но они не используются непосредственно в приложениях, которые работают по протоколу TCP / IP . В этой статье мы рассмотрим два протокола, которые используются приложениями: User Datagram Protocol (UDP) и Transmission Control Protocol (TCP).

Протокол дейтаграммы пользователя
User Datagram Protocol очень простой протокол. Как и IP , это надежный протокол без соединений. Вам не нужно устанавливать соединение с хостом для обмена данными с ним, используя UDP , и не существует механизма для обеспечения передаваемых данных.
Блок данных, передаваемых с помощью UDP называется датаграммой. UDP добавляет четыре 16-битных поля заголовка (8 байт) к передаваемым данным. Эти поля: длина поля, поле контрольной суммы, а также источник и номер порта назначения. «Порт», в этом контексте, представляет собой программное обеспечение порта, а не аппаратный порт.
Концепция номера порта является общей для обоих UDP и TCP . Номера портов определяют, какой модуль протокола направляет (или получает) данные. Большинство протоколов имеют стандартные порты, которые обычно используются для этого. Например, протокол Telnet обычно использует порт 23. Simple Mail Transfer Protocol (SMTP), использует порт 25. Использование стандартных номеров портов позволяет клиентам взаимодействовать с сервером без предварительной установки, какой порт использовать.
Номер порта и протокола в поле в заголовка IP дублируют друг друга в какой-то степени, хотя поля протокола не доступны для протоколов более высокого уровня. IP использует поле протокола, чтобы определить, куда должны быть переданы данные на UDP или TCP модули. UDP или TCP используют номер порта, чтобы определить, какой протокол прикладного уровня, должен получать данные.
Несмотря на то, UDP не является надежным, он все еще подходящий выбор для многих приложений. Он используется приложениями в реальном времени, такими как потоковое аудио и видео, где, если данные будут потеряны, то лучше обойтись без него, чем отправить его снова по порядку. Он также используется протоколами, такими как Simple Network Management Protocol (SNMP).
Трансляция
UDP подходит для информационного вещания, поскольку он не требует подключения к открытой связи.Цели широковещательного сообщения определяются отправителем, на указанный в IP-адрес назначения. UDP датаграммы с адресом назначения IP все бинарные 255.255.255.255) и будет получен каждый хост в локальной сети. Обратите внимание на слово местные: дейтаграммы с таким адресом не будут приняты маршрутизатором к Интернету.
Передачи могут быть направлены на конкретные сети. UDP датаграммы с хоста и подсети части IP-адреса, установленные как бинарные транслируются на все узлы на всех подсетях сети, которая соответствует чистой части IP-адреса. Если только принимающая сторона (другими словами, все биты, которые равны нулю в маске подсети) устанавливается в бинарные, то вещание ограничено для всех хостов в подсети, который соответствует остальной части адреса.
Многоадресная рассылка используются для передачи данных в группе хостов, которые выразили желание их получать. Многоадресная UDP датаграмма имеет адрес назначения, в котором первые четыре бита 1110, предоставлены адреса в диапазоне 224.xxx в 239.xxx Остальные биты адреса используются для обозначения группы многоадресной рассылки. Это, скорее, как радио-или телеканал. Так, например, 224.0.1.1 используется для протокола NTP. Если TCP / IP приложения хотят получить многоадресное сообщение, они должны присоединиться к соответствующей группе многоадресной рассылки, что он и делает, передавая адрес группы в стек протоколов.
Широкое вещание, по сути, фильтруют передачу. Multicaster не рассматривает индивидуальные сообщения для каждого хоста, который присоединяется к группе. Вместо этого, сообщения в эфир, и драйвера на каждом хосте решают, следует ли игнорировать их или передать содержимое стеку протоколов.
Это означает, что многоадресные сообщения должны транслироваться по всему Интернету, так как multicaster не знает, какие хосты хотят получать сообщения. К счастью, это не является необходимым. IP использует протокол под названием Internet Group Management Protocol (IGMP), чтобы сообщить маршрутизаторам, какие хосты хотят получать сообщения многоадресной группы, так что сообщения отправляются только туда, где они необходимы.
Протокол управления передачей
Transmission Control Protocol является протоколом транспортного уровня и используется большинством интернет-приложений, такими как Telnet, FTP и HTTP. Это протокол с установлением соединения. Это означает, что два компьютера - один клиент, другой сервер и между ними необходимо установить соединение до того, как данные могут передаваться между ними.
TCP обеспечивает надежность. Приложение, которое использует TCP знает, что он отправляет данные полученные на другом конце, и что он получил их правильно. TCP использует контрольные суммы, как на заголовках,так и на данных. При получении данных, TCP посылает подтверждение обратно к отправителю. Если отправитель не получает подтверждения в течение определенного периода времени, данные отправляются повторно.
TCP включает в себя механизмы обеспечения данных, которые поступают в обратной последовательности, в порядке как они были отправлены. Он также реализует управление потоком, так что отправитель не может подавить приемник данных.
TCP передает данные, используя IP, в блоках, которые называются сегментами. Длина отрезка определяется протоколом. В дополнение к IP-заголовку, каждый сегмент состоит из 20 байт заголовка. Заголовок TCP начинается с 16-битного источника и поля назначения номера порта. Как и UDP , эти поля определяют уровень приложения, которые направлены и на получение данных. IP-адрес и номер порта, вместе взятые однозначно идентифицируют службы, работающие на хозяина, и пары известной как гнездо.
Далее в заголовке идет 32-битный порядковый номер. Это число определяет позицию в потоке данных, что должен занимать первый байт данных в сегменте. Порядковый номер TCP позволяет поддерживать поток данных в правильном порядке, хотя сегменты могут быть получены из последовательности.
Следующее поле представляет собой 32-битное поле, которое используется для передачи обратно отправителю, что данные были получены правильно. Если ACK флаг, которым он обычно и бывает, то это поле содержит положение следующего байта данных, что отправитель сегмента ожидает получить.
В TCP нет необходимости для каждого сегмента данных, которые будут признаны. Значение в поле подтверждения интерпретируется как «все данные до сих пор получены ОК». Это экономит полосу пропускания, когда все данные направляются в одну сторону, уменьшая потребность в признании сегментов. Если данные одновременно отправляються в обоих направлениях, как в полной дуплексной связи, то марки не связаны с расходами,так как сегмент передачи данных в одну сторону может содержать подтверждение для данных, передаваемых по-другому.
Далее в заголовке представляется 16-битное поле, содержащее длину заголовка и флаги. TCP заголовки могут содержать дополнительные поля, так что длина может варьироваться от 20 до 60 байт. Флаги: URG, ACK (который мы уже упоминали), PSH, RST, SYN и FIN. Позже,мы рассмотрим некоторые другие флаги.
Заголовок содержит поле, называемое размером окна, что дает количество байт, которые приемник может принять. Также существует 16-битная контрольная сумма, охватывающая как заголовок,так и данные. Наконец (до дополнительных данных) есть поле называемое «указатель срочности». Когда флаг URG установлен, это значение интерпретируется как смещение порядкового номера. Он определяет начало данных в потоке, которые должны быть обработаны в срочном порядке. Эти данные часто называют данными «вне группы». Пример её использования, когда пользователь нажимает клавишу перерыв, чтобы прервать выход из программы во время Telnet сессии.

UDP является простым протоколом и имеет определенную область применения. В первую очередь, это клиент-серверные взаимодействия и мультимедиа. Тем не менее, большинству интернет-приложений требуется надежная, последователь­ная передача. UDP не удовлетворяет этим требованиям, поэтому требуется иной протокол. Такой протокол называется TCP, и он является рабочей лошадкой Интернета.

Основы TCP

Протокол TCP (Transmission Control Protocol - протокол управления передачей) был специально разработан для обеспечения надежного сквозного байтового потока по ненадежной интерсети. Объединенная сеть отличается от отдельной сети тем, что ее различные участки могут обладать сильно различающейся топологией, пропускной способностью, значениями времени задержки, размерами пакетов и другими параметрами. При разработке TCP основное внимание уделялось способности протокола адаптироваться к свойствам объединенной сети и отказоустойчивости при возникновении различных проблем.

Протокол TCP описан в RFC 793. Со временем были обнаружены различные ошибки и неточности, и по некоторым пунктам требования были изменены. Подробное описание этих уточнений и исправлений дается в RFC 1122. Расширения протокола приведены в RFC 1323.

Каждая машина, поддерживающая протокол TCP, обладает транспортной сущностью TCP, являющейся либо библиотечной процедурой, либо пользовательским процессом, либо частью ядра системы. В любом случае, транспортная сущность управляет TCP-потоками и интерфейсом с IP-уровнем. TCP-сущность принимает от локальных процессов пользовательские потоки данных, разбивает их на куски, не превосходящие 64 Кбайт (на практике это число обычно равно 460 байтам данных, что позволяет поместить их в один кадр Ethernet с заголов­ками IP и TCP), и посылает их в виде отдельных IP-дейтаграмм. Когда IP-дейтаграммы с TCP-данными прибывают на машину, они передаются TCP-сущности, которая восстанавливает исходный байтовый поток. Для простоты мы иногда будем употреблять «TCP» для обозначения транспортной сущности TCP (части программного обеспечения) или протокола TCP (набора правил). Из контекста будет понятно, что имеется в виду. Например, в выражении «Пользователь передает данные TCP» подразумевается, естественно, транспортная сущность TCP.

Уровень IP не гарантирует правильной доставки дейтаграмм, поэтому именно TCP приходится следить за истекшими интервалами ожидания и в случае необходимости заниматься повторной передачей пакетов. Бывает, что дейтаграммы прибывают в неправильном порядке. Восстанавливать сообщения из таких дейтаграмм обязан также TCP. Таким образом, протокол TCP призван обеспечить надежность, о которой мечтают многие пользователи и которая не предоставляется протоколом IP.

Модель службы TCP

В основе службы TCP лежат так называемые сокеты (гнезда или конечные точки), создаваемые как отправителем, так и получателем. Они обсуждались в разделе «Сокеты Беркли». У каждого сокета есть номер (адрес), состоящий из IP-адреса хоста и 16-битного номера, локального по отношению к хосту, называемого портом. Портом в TCP называют TSAP-адрес. Для обращения к службе TCP между сокетом машины отправителя и сокетом машины получателя должно быть явно установлено соединение.

Один сокет может использоваться одновременно для нескольких соединений. Другими словами, два и более соединений могут оканчиваться одним сокетом. Соединения различаются по идентификаторам сокетов на обоих концах - (socket1, socket2). Номера виртуальных каналов или другие идентификаторы не используются.

Номера портов со значениями ниже 1024, называемые популярными портами, зарезервированы стандартными сервисами. Например, любой процесс, желающий установить соединение с хостом для передачи файла с помощью протокола FTP, может связаться с портом 21 хоста-адресата и обратиться, таким образом, к его FTP-демону. Список популярных портов приведен на сайте www.iana.org.

Можно было бы, конечно, связать FTP-демона с портом 21 еще во время загрузки, тогда же связать демона telnet с портом 23, и т. д. Однако если бы мы так сделали, мы бы только зря заняли память информацией о демонах, которые, на самом деле, большую часть времени простаивают. Вместо этого обычно пользуются услугами одного демона, называемого в UNIX inetd, который связывается с несколькими портами и ожидает первое входящее соединение. Когда оно происходит, inetd создает новый процесс, для которого вызывается подходящий демон, обрабатывающий запрос. Таким образом, постоянно активен только inetd, остальные вызываются только тогда, когда для них есть работа. Inetd имеет специальный конфигурационный файл, из которого он может узнать о назначении портов. Это значит, что системный администратор может настроить систему таким образом, чтобы с самыми загруженными портами (например, 80) были связаны постоянные демоны, а с остальными - inetd.

Все TCP-соединения являются полнодуплексными и двухточечными. Полный дуплекс означает, что трафик может следовать одновременно в противоположные стороны. Двухточечное соединение подразумевает, что у него имеются две конечные точки. Широковещание и многоадресная рассылка протоколом TCP не поддерживаются.

TCP-соединение представляет собой байтовый поток, а не поток сообщений. Границы между сообщениями не сохраняются. Например, если отправляющий процесс записывает в TCP-поток четыре 512-байтовых порции данных, эти данные могут быть доставлены получающему процессу в виде четырех 512-байтовых порций, двух 1024-байтовых порций, одной 2048-байтовой порции или как-нибудь еще. Нет способа, которым получатель смог бы определить, каким образом записывались данные.

Файлы в системе UNIX также обладают этим свойством. Программа, читающая райл, не может определить, как был записан этот файл: поблочно, побайтно или сразу целиком. Как и в случае с файлами системы UNIX, TCP-программы не имеют представления о назначении байтов и не интересуются этим. Байт для них - просто байт.

Получив данные от приложения, протокол TCP может послать их сразу или поместить в буфер, чтобы послать сразу большую порцию данных, по своему усмотрению. Однако иногда приложению бывает необходимо, чтобы данные были посланы немедленно. Допустим, например, что пользователь регистрируется на удаленной машине. После того как он ввел команду и нажал клавишу Enter, важно, чтобы введенная им строка была доставлена на удаленную машину сразу же, а не помещалась в буфер, пока не будет введена следующая строка. Чтобы вынудить передачу данных без промедления, приложение может установить флаг PUSH (протолкнуть).

Некоторые старые приложения использовали флаг PUSH как разделитель сообщений. Хотя этот трюк иногда срабатывает, не все реализации протокола TCP передают флаг PUSH принимающему приложению. Кроме того, если прежде чем первый пакет с установленным флагом PUSH будет передан в линию, TCP-сущность получит еще несколько таких пакетов (то есть выходная линия будет занята), TCP-сущность будет иметь право послать все эти данные в виде единой дейтаграммы, не разделяя их на отдельные порции.

Последней особенностью службы TCP, о которой следует упомянуть, являются срочные данные. Когда пользователь, взаимодействующий с программой в интерактивном режиме, нажимает клавишу Delete или Ctrl-C, чтобы прервать начавшийся удаленный процесс, посылающее приложение помещает в выходной поток данных управляющую информацию и передает ее TCP-службе вместе с флагом URGENT (срочно). Этот флаг заставляет TCP-сущность прекратить накоп­ение данных и без промедления передать в сеть все, что у нее есть для данного соединения.

Когда срочные данные прибывают по назначению, получающее приложение прерывается (то есть «получает сигнал», в терминологии UNIX), после чего оно может считать данные из входного потока и найти среди них срочные. Конец срочных данных маркируется, так что приложение может распознать, где они заканчиваются. Начало срочных данных не маркируется. Приложение должно само догадаться. Такая схема представляет собой грубый сигнальный механизм, оставляя все прочее приложению.

Протокол TCP

В данном разделе будет рассмотрен протокол TCP в общих чертах. В следующем разделе мы обсудим заголовок протокола, поле за полем.

Ключевым свойством TCP, определяющим всю структуру протокола, является то, что в TCP-соединении у каждого байта есть свой 32-разрядный порядковый номер. В первые годы существования Интернета базовая скорость передачи данных между маршрутизаторами по выделенным линиям составляла 56 Кбит/с. Хосту, постоянно выдающему данные с максимальной скоростью, потребовалось бы больше недели на то, чтобы порядковые номера совершили полный круг. При нынешних скоростях порядковые номера могут кончиться очень быстро, об этом еще будет сказано позже. Отдельные 32-разрядные порядковые номера используются для подтверждений и для механизма скользящего окна, о чем также будет сказано позже.

Отправляющая и принимающая TCP-сущности обмениваются данными в виде сегментов. Сегмент состоит из фиксированного 20-байтового заголовка (плюс необязательная часть), за которой могут следовать байты данных. Размер сегментов определяется программным обеспечением TCP. Оно может объединять в один сегмент данные, полученные в результате нескольких операций записи, или, наоборот, распределять результат одной записи между несколькими сегментами. Размер сегментов ограничен двумя пределами. Во-первых, каждый сегмент, включая TCP-заголовок, должен помещаться в 65 515-байтное поле полезной нагрузки IP-пакета. Во-вторых, в каждой сети есть максимальная единица передачи (MTU, Maximum Transfer Unit), и каждый сегмент должен помещаться в MTU. На практике размер максимальной единицы передачи составляет обычно 1500 байт (что соответствует размеру поля полезной нагрузки Ethernet), и таким образом определяется верхний предел размера сегмента.

Основным протоколом, используемым TCP-сущностями, является протокол скользящего окна. При передаче сегмента отправитель включает таймер. Когда сегмент прибывает в пункт назначения, принимающая TCP-сущность посылает обратно сегмент (с данными, если есть что посылать, или без данных) с номером

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

Хотя этот протокол кажется простым, в нем имеется несколько деталей, которые следует рассмотреть подробнее. Сегменты могут приходить в неверном порядке. Так, например, возможна ситуация, в которой байты с 3072-го по 4095-й уже прибыли, но подтверждение для них не может быть выслано, так как байты с 2048-го по 3071-й еще не получены. К тому же сегменты могут задерживаться в сети так долго, что у отправителя истечет время ожидания и он передаст их снова. Переданный повторно сегмент может включать в себя уже другие диапазоны фрагментов, поэтому потребуется очень аккуратное администрирование для определения номеров байтов, которые уже были приняты корректно. Тем не менее, поскольку каждый байт в потоке единственным образом определяется по своему сдвигу, эта задача оказывается реальной.

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

Заголовок ТСР-сегмента

Каждый сегмент начинается с 20-байтного заголовка фиксированного формата. За ним могут следовать дополнительные поля. После дополнительных полей может располагаться до 65 535 - 20 - 20 = 65 495 байт данных, где первые 20 байт - это IP-заголовок, а вторые - TCP-заголовок. Сегменты могут и не содержать данных. Такие сегменты часто применяются для передачи подтверждений и управляющих сообщений.

Рассмотрим TCP-заголовок поле за полем. Поля Порт получателя и Порт отправителя являются идентификаторами локальных конечных точек соединения. Номер порта вместе с IP-адресом хоста образуют уникальный 48-битный идентификатор конечной точки. Пара таких идентификаторов, относящихся к источнику и приемнику, однозначно определяет соединение.

Поля Порядковый номер и Номер подтверждения выполняют свою обычную функцию. Обратите внимание: поле Номер подтверждения относится к следующему ожидаемому байту, а не к последнему полученному. Оба они 32-разрядные, так как в TCP-потоке нумеруется каждый байт данных.

Поле Длина TCP-заголовка содержит размер TCP-заголовка, выраженный в 32-разрядных словах. Эта информация необходима, так как поле Факультативные поля, а вместе с ним и весь заголовок, может быть переменной длины. По сути, это поле указывает смещение от начала сегмента до поля данных, измеренное в 32-битных словах. Это то же самое, что длина заголовка.

Следом идет неиспользуемое 6-битное поле. Тот факт, что это поле выжило в течение четверти века, является свидетельством того, насколько хорошо проду­ман дизайн TCP.

Затем следуют шесть 1-битовых флагов. Бит URG устанавливается в 1 в слу­чае использования поля Указатель на срочные данные, содержащего смещение в байтах от текущего порядкового номера байта до места расположения срочных данных. Таким образом в протоколе TCP реализуются прерывающие сообщения. Как уже упоминалось, протокол TCP лишь обеспечивает доставку сигнала пользователя до получателя, не интересуясь причиной прерывания.

Если бит АСК установлен в 1, значит, поле Номер подтверждения содержит осмысленные данные. В противном случае данный сегмент не содержит подтверждения, и поле Номер подтверждения просто игнорируется.

Бит PSH является, по сути, PUSH-флагом, с помощью которого отправитель просит получателя доставить данные приложению сразу по получении пакета, а не хранить их в буфере, пока тот не наполнится. (Получатель может заниматься буферизацией для достижения большей эффективности.)

Бит RST используется для сброса состояния соединения, которое из-за сбоя хоста или по другой причине попало в тупиковую ситуацию. Кроме того, он используется для отказа от неверного сегмента или от попытки создать соединение. Если вы получили сегмент с установленным битом RST, это означает наличие какой-то проблемы.

Бит SYN применяется для установки соединения. У запроса соединения бит SYN= 1, а бит АСК = 0, что означает, что поле подтверждения не используется. В ответе на этот запрос содержится подтверждение, поэтому значения этих битов в нем равны: SYN= 1, ACK- 1. Таким образом, бит SYN используется для обозначения сегментов CONNECTION REQUEST и CONNECTION ACCEPTED, а бит АСК - что­бы отличать их друг от друга.

Бит FIN используется для разрыва соединения. Он указывает на то, что у отправителя больше нет данных для передачи. Однако, даже закрыв соединение, процесс может продолжать получать данные в течение неопределенного времени. У сегментов с битами FIN и SYN есть порядковые номера, что гарантирует правильный порядок их выполнения.

Управление потоком в протоколе TCP осуществляется при помощи скользящего окна переменного размера. Поле Размер окна сообщает, сколько байт может быть послано после байта, получившего подтверждение. Значение поля Размер окна может быть равно нулю, что означает, что все байты вплоть до Номер подтверждения-1 получены, но у получателя в данный момент какие-то проблемы, и остальные байты он пока принять не может. Разрешение на дальнейшую передачу может быть получено путем отправки сегмента с таким же значением поля Номер подтверждения и ненулевым значением поля Размер окна.

В некоторых протоколах, подтверждения приема кадров связаны с разрешениями на продолжение передачи. Эта связь следствие жестко закрепленного размера скользящего окна в этих протоколах. В TCP подтверждения отделены от разрешений на передачу данных. В сущности, приемник может сказать: «Я получил байты вплоть до k-ro, но я сейчас не хочу продолжать прием данных». Такое разделение (выражающееся в скользящем окне переменного размера) придает протоколу дополнительную гибкость. Далее мы обсудим этот аспект более детально.

Поле Контрольная сумма служит для повышения надежности. Оно содержит контрольную сумму заголовка, данных и псевдозаголовка. При выполнении вычислений поле Контрольная сумма устанавливается равным нулю, а поле данных дополняется нулевым байтом, если его длина представляет собой нечетное число. Алгоритм вычисления контрольной суммы просто складывает все 16-разрядные слова в дополнительном коде, а затем вычисляет дополнение для всей суммы. В результате, когда получатель считает контрольную сумму всего сегмента, включая поле Контрольная сумма, результат должен быть равен 0.

Псевдозаголовок содержит 32-разрядные IP-адреса отправителя и получате­ля, номер протокола для TCP (6) и счетчик байтов для TCP-сегмента (включая заголовок). Включение псевдозаголовка в контрольную сумму TCP помогает обнаружить неверно доставленные пакеты, хотя это нарушает иерархию протоколов, так как IP-адреса в нем принадлежат IP-уровню, а не TCP-уровню. В UDP для контрольной суммы используется такой же псевдозаголовок.

Поле Факультативные поля предоставляет дополнительные возможности, не покрываемые стандартным заголовком. С помощью одного из таких полей каждый хост может указать максимальный размер поля полезной нагрузки, который он может принять. Чем больше размер используемых сегментов, тем выше эффективность, так как при этом снижается удельный вес накладных расходов в виде 20-байтных заголовков, однако не все хосты способны принимать очень большие сегменты. Хосты могут сообщить друг другу максимальный размер поля полезной нагрузки во время установки соединения. По умолчанию этот размер равен 536 байтам. Все хосты обязаны принимать TCP-сегменты размером 536 + 20 = 556 байт. Для каждого из направлений может быть установлен свой максимальный размер поля полезной нагрузки.

Для линий с большой скоростью передачи и/или большой задержкой окно размером в 64 Кбайт оказывается слишком маленьким. Так, для линии ТЗ (44,736 Мбит/с) полное окно может быть передано в линию всего за 12 мс. Если значение времени распространения сигнала в оба конца составляет 50 мс (что типично для трансконтинентального оптического кабеля), 3/4 времени отправитель будет заниматься ожиданием подтверждения. При связи через спутник ситуация будет еще хуже. Больший размер окна мог бы улучшить эффективность, но 16-битовое поле Размер окна не позволяет этого сделать. В RFC 1323 был предложен новый параметр Масштаб окна, о значении которого два хоста могли договориться при установке соединения. Это число позволяет сдвигать поле Раз­мер окна до 14 разрядов влево, обеспечивая расширение размера окна до 230 байт (1 Гбайт). В настоящее время большинство реализаций протокола TCP поддерживают эту возможность.

Еще одна возможность, предложенная в RFC 1106 и широко применяемая сейчас, состоит в использовании протокола выборочного повтора вместо возврата на п. Если адресат получает один плохой сегмент и следом за ним большое количество хороших, у нормального TCP-протокола в конце концов истечет время ожидания и он передаст повторно все неподтвержденные сегменты, включая те, что были получены правильно. В документе RFC 1106 было предложено использовать отрицательные подтверждения (NAK), позволяющие получателю запрашивать отдельный сегмент или несколько сегментов. Получив его, принимающая сторона может подтвердить все хранящиеся в буфере данные, уменьшая таким образом количество повторно передаваемых данных.

User Datagram Protocol (UDP) (протокол пользовательских дейтаграмм) - является протоколом стандарта TCP/IP , определенный в стандарте RFC 768, "User Datagram Protocol (UDP)". UDP используется вместо TCP для быстрой и ненадежной транспортировки данных между TCP/IP хостами.

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

Чувствительные ко времени приложения часто используют UDP (видеоданные), так как предпочтительнее сбросить пакеты, чем ждать задержавшиеся пакеты, что может оказаться невозможным в системах реального времени. Также потеря одного или нескольких кадров, при передаче видеоданных по UDP, не так критична, в отличии от передачи бинарных файлов, где потеря одно пакета может привести к искажению всего файла. Еще одним преимуществом протокола UDP является то, что длина заголовка UDP составляет 4 байта, а у TCP протокола - 20 байт.

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

UDP заголовок

На рисунке показаны поля, присутствующие в UDP заголовке.

• Порт отправителя - в этом поле указывается номер порта отправителя. Предполагается, что это значение задает порт, на который при необходимости будет посылаться ответ. В противном же случае, значение должно быть равным 0. Если хостом-источником является клиент, то номер порта будет, скорее всего, эфемерным. Если источником является сервер, то его порт будет одним из "хорошо известных".
• Порт получателя - это поле обязательно и содержит порт получателя. Аналогично порту отправителя, если клиент - хост-получатель, то номер порта эфемерный, иначе (сервер - получатель) это "хорошо известный порт".
• Длина дейтаграммы - поле, задающее длину всей дейтаграммы (заголовка и данных) в байтах. Минимальная длина равна длине заголовка - 8 байт. Теоретически, максимальный размер поля - 65535 байт для UDP-дейтаграммы (8 байт на заголовок и 65527 на данные). Фактический предел для длины данных при использовании IPv4 - 65507 (помимо 8 байт на UDP-заголовок требуется еще 20 на IP-заголовок).
• Контрольная сумма - поле контрольной суммы используется для проверки заголовка и данных на ошибки. Если сумма не сгенерирована передатчиком, то поле заполняется нулями.

Рассмотрим структуру заголовка UDP с помощью сетевого анализатора Wireshark:

UDP порты

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

Номер порта - это условное 16-битное число от 1 до 65535, указывающее, какой программе предназначается пакет.

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

Все номера портов UDP, которые меньше чем 1024 - зарезервированы и зарегистрированы в Internet Assigned Numbers Authority (IANA).
Номера портов UDP и TCP не пересекаются.

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

Протоколы TCP и UDP

TCP- Transmission Control Protocol

Обмен данными, ориентированный на соединения, может использовать надежную связь, для обеспечения которой протокол уровня 4 посылает подтверждения о получении данных и запрашивает повторную передачу, если данные не получены или искажены. Протокол TCP использует именно такую надежную связь. TCP используется в таких прикладных протоколах, как HTTP, FTP, SMTP и Telnet.

Протокол TCP требует, чтобы перед отправкой сообщения было открыто соединение. Серверное приложение должно выполнить так называемое пассивное открытие (passive open) , чтобы создать соединение с известным номером порта, и, вместо того чтобы отправлять вызов в сеть, сервер переходит в ожидание поступления входящих запросов. Клиентское приложение должно выполнить активное открытие (active open) , отправив серверному приложению синхронизирующий порядковый номер (SYN), идентифицирующий соединение. Клиентское приложение может использовать динамический номер порта в качестве локального порта.

Сервер должен отправить клиенту подтверждение (ACK) вместе с порядковым номером (SYN) сервера. В свою очередь клиент отвечает АСК, и соединение устанавливается.

После этого может начаться процесс отправки и получения сообщений. При получении сообщения в ответ всегда отправляется сообщение АСК. Если до получения АСК отправителем истекает тайм-аут, сообщение помещается в очередь на повторную передачу.

Поля заголовка TCP перечислены в следующей таблице:

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

Протокол TCP имеет встроенную возможность надежной доставки. Если сообщение не отправлено корректно, мы получим сообщение об ошибке. Протокол TCP определен в RFC 793.

UDP - User Datagram Protocol

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

UDP не требует открывать соединение, и данные могут быть отправлены сразу же, как только они подготовлены. UDP не отправляет подтверждающие сообщения, поэтому данные могут быть получены или потеряны. Если при использовании UDP требуется надежная передача данных, ее следует реализовать в протоколе более высокого уровня.

Так в чем же преимущества UDP, зачем может понадобиться такой ненадежный протокол? Чтобы понять причину использования UDP, нужно различать однонаправленную передачу, широковещательную передачу и групповую рассылку.

Однонаправленное (unicast) сообщение отправляется из одного узла только в один другой узел. Это также называется связью "точка-точка". Протокол TCP поддерживает лишь однонаправленную связь. Если серверу нужно с помощью TCP взаимодействовать с несколькими клиентами, каждый клиент должен установить соединение, поскольку сообщения могут отправляться только одиночным узлам.

Широковещательная передача (broadcast) означает, что сообщение отправляется всем узлам сети. Групповая рассылка (multicast) - это промежуточный механизм: сообщения отправляются выбранным группам узлов.

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