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-программы.

Протокол UDP

User Datagram Protocol (UDP) - это простой, ориентированный на дейтаграммы протокол без организации соединения, предоставляющий быстрое, но необязательно надежное транспортное обслуживание. Он поддерживает взаимодействия "один со многими" и поэтому часто применяется для широковещательной и групповой передачи дейтаграмм.

Internet Protocol (IP) является основным протоколом Интернета. Transmission Control Protocol (TCP) и UDP - это протоколы транспортного уровня, построенные поверх лежащего в основе протокола.

TCP/IP - это набор протоколов, называемый также "пакетом протоколов Интернета" (Internet Protocol Suite), состоящий из четырех уровней. Запомните, что TCP/IP не просто один протокол, а семейство или набор протоколов, который состоит из других низкоуровневых протоколов, таких, как IP, TCP и UDP. UDP располагается на транспортном уровне поверх IP (протокола сетевого уровня). Транспортный уровень обеспечивает взаимодействие между сетями через шлюзы. В нем используются IP-адреса для отправки пакетов данных через Интернет или другую сеть с помощью разнообразных драйверов устройств.

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

Пакеты

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

Дейтаграммы

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

MTU (Maximum Transmission Unit)

MTU характеризует канальный уровень и соответствует максимальному числу байтов, которое можно передать в одном пакете. Другими словами MTU - это самый большой пакет, который может переносить данная сетевая среда. Например, Ethernet имеет фиксированный MTU, равный 1500 байтам. В UDP, если размер дейтаграммы больше MTU, протокол IP выполняет фрагментацию, разбивая дейтаграмму на более мелкие части (фрагменты) так, чтобы каждый фрагмент был меньше MTU.

Порты

Чтобы поставить в соответствие входящим данным конкретный процесс, выполняемый в компьютере, UDP использует порты. UDP направляет пакет в соответствующее место, используя номер порта, указанный в UDP-заголовке дейтаграммы. Порты представлены 16-битными номерами и, следовательно, принимает значения в диапазоне от 0 до 65 535. Порты, которые также называют конечными точками логических соединений, разделены на три категории:

Хорошо известные порты - от 0 до 1023

Регистрируемые порты - от 1024 до 49151

Динамические / частные порты - от 49152 до 65535

Заметим, что порты UDP могут получать более одного сообщения в каждый промежуток времени. В некоторых случаях сервисы TCP и UDP могут использовать одни и те же номера портов, например 7 (Echo) или 23 (Telnet).

UDP использует следующие известные порты:

Перечень портов UDP и TCP поддерживается агентством IANA (Internet Assigned Numbers Authority) .

IP-адреса

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

Однонаправленный IP-адрес уникально определяет хост в сети, тогда как групповой IP-адрес определяет конкретную группу адресов в сети. Широковещательные IP-адреса получаются и обрабатываются всеми хостами локальной сети или конкретной подсети.

TTL

Значение времени жизни, или TTL (time-to-live), позволяет установить верхний предел числа маршрутизаторов, через которые может пройти дейтаграмма. Значение TTL не дает пакетам попасть в бесконечные циклы. Оно инициализируется отправителем и уменьшается на единицу каждым маршрутизатором, обрабатывающим дейтаграмму. Когда значение TTL становится нулевым, дейтаграмма отбрасывается.

Групповая рассылка

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

Принцип работы UDP

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

На предыдущем рисунке указано, что общая длина заголовка UDP составляет восемь байтов. Теоретически максимальный размер дейтаграммы IP равен 65 535 байтам. С учетом 20 байтов заголовка IP и 8 байтов заголовка UDP длина данных пользователя может достигать 65 507 байтов. Однако большинство программ работают с данными меньшего размера. Так, для большинства приложений по умолчанию установлена длина приблизительно 8192 байта, поскольку именно такой объем данных считывается и записывается сетевой файловой системой (NFS). Можно устанавливать размеры входного и выходного буферов.

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

На следующем шаге уровень IP добавляет 20 байтов заголовка, включающего TTL, IP-адреса источника и получателя и другую информацию. Это действие называют IP-инкапсуляцией.

Как упоминалось ранее, максимальный размер пакета равен 65 507 байтам. Если пакет превышает установленный по умолчанию размер MTU, то уровень IP разбивает пакет на сегменты. Эти сегменты называются фрагментами, а процесс разбиения данных на сегменты - фрагментацией . Заголовок IP содержит всю информацию о фрагментах.

Когда приложение-отправитель "выбрасывает" дейтаграмму в сеть, она направляется по IP-адресу назначения, указанному в заголовке IP. При проходе через маршрутизатор значение времени жизни (TTL) в заголовке IP уменьшается на единицу.

Когда дейтаграмма прибывает к заданному назначению и порту, уровень IP по своему заголовку проверяет, фрагментирована ли дейтаграмма. Если это так, дейтаграмма собирается в соответствии с информацией, имеющейся в заголовке. Наконец прикладной уровень извлекает отфильтрованные данные, удаляя заголовок.

Недостатки UDP

По сравнению с TCP UDP имеет следующие недостатки:

Отсутствие сигналов квитирования . Перед отправкой пакета UDP, отправляющая сторона не обменивается с получающей стороной квитирующими сигналами. Следовательно, у отправителя нет способа узнать, достигла ли дейтаграмма конечной системы. В результате UDP не может гарантировать, что данные будут действительно доставлены адресату (например, если не работает конечная система или сеть).

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

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

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

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

Управление потоком . В UDP управление потоком отсутствует, в результате плохо спроектированное UDP-приложение может захватить значительную часть пропускной способности сети.

Преимущества UDP

По сравнению с TCP UDP имеет следующие преимущества:

Нет установки соединения . UDP является протоколом без организации соединений, поэтому он освобождает от накладных расходов, связанных с установкой соединений. Поскольку UDP не пользуется сигналами квитирования, то задержек, вызванных установкой соединений, также удается избежать. Именно поэтому DNS отдает предпочтение UDP перед TCP - DNS работала бы гораздо медленнее, если бы она выполнялась через TCP.

Скорость . UDP работает быстрее TCP. По этой причине многие приложения предпочитают не TCP, a UDP. Те же средства, которые делают TCP более устойчивым (например сигналы квитирования), замедляют его работу.

Топологическое разнообразие . UDP поддерживает взаимодействия "один с одним" и "один с многими", в то время как TCP поддерживает лишь взаимодействие "один с одним".

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

Размер заголовка . Для каждого пакета заголовок UDP имеет длину всего лишь восемь байтов, в то время как TCP имеет 20-байтовые заголовки, и поэтому UDP потребляет меньше пропускной способности сети.

Говоря о безопасности информации, мы имеем в виду конфиденциальность, целостность и доступность информации в каждый момент времени. И если с конфиденциальностью и доступностью все понятно, то как обеспечить целостность информации при ее передаче по сети? Для решения этой задачи нам пригодится знание сетевых протоколов. В данной статье мы рассмотрим протоколы TCP и UDP. Они входят в стек протоколов TCP/IP, относятся к транспортному уровню модели OSI и используются для передачи информации от узла к узлу.

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

UDP

UDP protocol – протокол, обеспечивающий передачу данных (датаграмм) без предварительного создания соединения между хостами. При отправке датаграмм нет уверенности в существовании получателя и его готовности к обмену. Сетевой протокол UDP не обеспечивает также упорядочивание датаграмм при получении. Он используется приложениями для которых существенное значение имеет время доставки, когда нет возможности ждать задержавшиеся или запрашивать потерянные пакеты, например, в системах реального времени. Датаграммы могут доставляться не в заданном порядке, дублироваться или вовсе не доставляться. Поэтому протокол UDP называют «ненадёжным протоколом датаграмм».

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

TCP

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

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

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

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

TCP и UDP отличия

Означает ли это, что протокол UDP не стоит использовать? Вовсе нет. За счет отсутствия «гарантии доставки» протокол UDP обеспечивает более высокую скорость передачи данных, чем TCP. По этой причине UDP оптимален для сетевых и онлайн игр, просмотра потокового видео, организации видео-связи и IP телефонии.

Делитесь полезной информацией с близкими.

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.

Некоторые зарезирвированные порты
	Протокол	Использование
21	FTP	Передача файлов
23	Telnet	Дистанционный вход в систему
25	SMTP	Электронная почта
69	TFTP	Простейший протокол передачи файлов
79	Finger	Поиск информации о пользователе
80	HTTP	Мировая Паутина
110	POP-3	Удаленный доступ к электронной почте
119	NNTP	Группы новостей

Все 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), позволяющие получателю запрашивать отдельный сегмент или несколько сегментов. Получив его, принимающая сторона может подтвердить все хранящиеся в буфере данные, уменьшая таким образом количество повторно передаваемых данных.

UDP (англ. User Datagram Protocol - протокол пользовательских датаграмм) - это транспортный протокол для передачи данных в сетях IP без установления соединения. Он является одним из самых простых протоколов транспортного уровня модели OSI. Его IP-идентификатор - 0x11.

UDP обычно используется в таких приложениях, как потоковое видео и компьютерные игры, где допускается потеря пакетов, а повторный запрос затруднён или не оправдан, либо в приложениях вида запрос-ответ (например, запросы к DNS), где создание соединения занимает больше ресурсов, чем повторная отправка. Фактически функции UDP сводятся к операциям мультиплексирования и демультиплексирования, а также несложной проверке наличия ошибок в данных. Таким образом, при использовании U DP приложение почти напрямую взаимодействует с протоколом сетевого уровня IP.

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

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

Сравнение протоколов UDP от TCP.

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

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

FTP и HTTP – это примеры приложений, в которых для обеспечения доставки данных применяется протокол TCP.

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

Протокол ARP. Применение.

ARP (англ. Address Resolution Protocol - протокол определения адреса) - использующийся в компьютерных сетях протокол низкого уровня, предназначенный для определения адреса канального уровня по известному адресу сетевого уровня. Наибольшее распространение этот протокол получил благодаря повсеместности сетей IP, построенных поверх Ethernet, поскольку практически в 100 % случаев при таком сочетании используется ARP. Описание протокола было опубликовано в ноябре 1982 года в RFC 826. ARP был спроектирован для случая передачи IP-пакетов через сегмент Ethernet. При этом общий принцип, предложенный для ARP, может, и был использован и для сетей других типов.

Существуют следующие типы сообщений ARP: запрос ARP (ARP request) и ответ ARP (ARP reply). Система-отправитель при помощи запроса ARP запрашивает физический адрес системы-получателя. Ответ (физический адрес узла-получателя) приходит в виде ответа ARP.

Перед тем как передать пакет сетевого уровня через сегмент Ethernet, сетевой стек проверяет кэш ARP, чтобы выяснить, не зарегистрирована ли в нём уже нужная информация об узле-получателе. Если такой записи в кэше ARP нет, то выполняется широковещательный запрос ARP. Этот запрос для устройств в сети имеет следующий смысл: «Кто-нибудь знает физический адрес устройства, обладающего следующим IP-адресом?» Когда получатель с этим IP-адресом примет этот пакет, то должен будет ответить: «Да, это мой IP-адрес. Мой физический адрес следующий: …» После этого отправитель обновит свой кэш ARP и будет способен передать информацию получателю.

Записи в кэше ARP могут быть статическими и динамическими. Пример, данный выше, описывает динамическую запись кэша. Можно также создавать статические записи в таблице ARP.

ARP изначально был разработан не только для IP протокола, но в настоящее время в основном используется для сопоставления IP- и MAC-адресов.

Принцип работы

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

Все узлы локальной сети получают ARP запрос и сравнивают указанный там IP-адрес с собственным.

В случае их совпадения узел формирует ARP-ответ, в котором указывает свой IP-адрес и свой локальный адрес и отправляет его уже направленно, так как в ARP запросе отправитель указывает свой локальный адрес.