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 запросе отправитель указывает свой локальный адрес.

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

TCP- Transmission Control Protocol

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

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

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

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

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

Заголовок TCP

Поле	Длина	Описание
Порт источника	2 байта	Номер порта источника
Порт назначения	2 байта	Номер порта назначения
Последовательный номер	4 байта	Последовательный номер генерируется источником и используется назначением, чтобы переупорядочить пакеты для создания исходного сообщения и отправить подтверждение источнику.
Номер подтверждения	4 байта	Если установлен бит АСК поля "Управление", в данном поле содержится следующий ожидаемый последовательный номер.
Смещение данных	4 бита	Информация о начале пакета данных.
Резерв	6 битов	Резервируются для будущего использования.
Управление	6 битов	Биты управления содержат флаги, указывающие, верны ли поля подтверждения (АСК), указателя срочности (URG), следует ли сбрасывать соединение (RST), послан ли синхронизирующий последовательный номер (SYN) и т. д.
Размер окна	2 байта	В этом поле указывается размер приемного буфера. Используя подтверждающие сообщения, получатель может информировать отправителя о максимальном размере данных, которые тот может отправить.
Контрольная сумма	2 байта	Контрольная сумма заголовка и данных; по ней определяется, был ли искажен пакет.
Указатель срочности	2 байта	В этом поле целевое устройство получает информацию о срочности данных.
Опции	переменная	Необязательные значения, которые указываются при необходимости.
Дополнение	переменная	В поле дополнения добавляется столько нулей, чтобы заголовок заканчивался на 32-битной границе.

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

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

UDP - User Datagram Protocol

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

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

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

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

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

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

User Datagram Protocol - UDP

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

Рис. 2.10. Структура заголовка UDP-сообщения

Единица данных протокола UDP называется UDP-пакетом или пользовательской дейтаграммой (user datagram). UDP-пакет состоит из заголовка и поля данных, в котором размещается пакет прикладного уровня. Заголовок имеет простой формат и состоит из четырех двухбайтовых полей:

UDP source port - номер порта процесса-отправителя,

UDP destination port - номер порта процесса-получателя,

UDP message length - длина UDP-пакета в байтах,

UDP checksum - контрольная сумма UDP-пакета

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

Порты в заголовке определяют протокол UDP как мультиплексор, который позволяет собирать сообщения от приложений и отправлять их на уровень протоколов. При этом приложение использует определенный порт. Взаимодействующие через сеть приложения могут использовать разные порты, что и отражает заголовок пакета. Всего можно определить 216 разных портов. Первые 256 портов закреплены за, так называемыми "well known services", к которым относятся, например, 53 порт UDP, который закреплен за сервисом DNS.

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

Наиболее известными сервисами, основанными на UDP, является служба доменных имен BIND и распределенная файловая система NFS. Если возвратиться к примеру traceroute, то в этой программе также используется транспорт UDP. Собственно, именно сообщение UDP и засылается в сеть, но при этом используется такой порт, который не имеет обслуживания, поэтому и порождается ICMP-пакет, который и детектирует отсутствие сервиса на принимающей машине, когда пакет наконец достигает машину-адресата.

Transfer Control Protocol - TCP

Если для приложения контроль качества передачи данных по сети имеет значение, то в этом случае используется протокол TCP. Этот протокол еще называют надежным, ориентированным на соединение и потокоориентированным протоколом. Прежде чем обсудить эти свойства протокола, рассмотрим формат передаваемой по сети датаграммы (рисунок 2.11). Согласно этой структуре, в TCP, как и в UDP, имеются порты. Первые 256 портов закреплены за WKS, порты от 256 до 1024 закреплены за Unix-сервисами, а остальные можно использовать по своему усмотрению. В поле Sequence Number определен номер пакета в последовательности пакетов, которая составляет все сообщение, за тем идет поле подтвержденияAsknowledgment Number и другая управляющая информация.

Рис. 2.11. Структура пакета TCP

Порт источника (SOURS PORT) занимает 2 байта, идентифицирует процесс-отправитель;

Порт назначения (DESTINATION PORT) занимает 2 байта, идентифицирует процесс-получатель;

Последовательный номер (SEQUENCE NUMBER) занимает 4 байта, указывает номер байта, который определяет смещение сегмента относительно потока отправляемых данных;

Подтвержденный номер (ACKNOWLEDGEMENT NUMBER) занимает 4 байта, содержит максимальный номер байта в полученном сегменте, увеличенный на единицу; именно это значение используется в качестве квитанции;

Длина заголовка (HLEN) занимает 4 бита, указывает длину заголовка сегмента TCP, измеренную в 32-битовых словах. Длина заголовка не фиксирована и может изменяться в зависимости от значений, устанавливаемых в поле Опции;

Резерв (RESERVED) занимает 6 битов, поле зарезервировано для последующего использования;

Кодовые биты (CODE BITS) занимают 6 битов, содержат служебную информацию о типе данного сегмента, задаваемую установкой в единицу соответствующих бит этого поля:

URG - срочное сообщение;

ACK - квитанция на принятый сегмент;

PSH - запрос на отправку сообщения без ожидания заполнения буфера;

RST - запрос на восстановление соединения;

SYN - сообщение используемое для синхронизации счетчиков переданных данных при установлении соединения;

FIN - признак достижения передающей стороной последнего байта в потоке передаваемых данных.

Окно (WINDOW) занимает 2 байта, содержит объявляемое значение размера окна в байтах;

Контрольная сумма (CHECKSUM) занимает 2 байта, рассчитывается по сегменту;

Указатель срочности (URGENT POINTER) занимает 2 байта, используется совместно с кодовым битом URG, указывает на конец данных, которые необходимо срочно принять, несмотря на переполнение буфера;

Опции (OPTIONS) - это поле имеет переменную длину и может вообще отсутствовать, максимальная величина поля 3 байта; используется для решения вспомогательных задач, например, при выборе максимального размера сегмента;

Заполнитель (PADDING) может иметь переменную длину, представляет собой фиктивное поле, используемое для доведения размера заголовка до целого числа 32-битовых слов.

Надежность TCP заключается в том, что источник данных повторяет их посылку, если только не получит в определенный промежуток времени от адресата подтверждение об их успешном получении. Этот механизм называется Positive Asknowledgement with Retransmission (PAR) . Как мы ранее определили, единица пересылки (пакет данных, сообщение и т.п.) в терминах TCP носит название сегмента. В заголовке TCP существует поле контррольной суммы. Если при пересылке данные повреждены, то по контрольной сумме модуль, вычленяющий TCP-сегменты из пакетов IP, может определить это. Поврежденный пакет уничтожается, а источнику ничего не посылается. Если данные не были повреждены, то они пропускаются на сборку сообщения приложения, а источнику отправляется подтверждение.

Ориентация на соединение определяется тем, что прежде чем отправить сегмент с данными, модули TCP источника и получателя обмениваются управляющей информацией. Такой обмен называется handshake (буквально "рукопожатие"). В TCP используется трехфазный hand-shake:

Источник устанавливает соединение с получателем, посылая ему пакет с флагом "синхронизации последовательности номеров" (Synchronize Sequence Numbers - SYN). Номер в последовательности определяет номер пакета в сообщении приложения. Это не обязательно должен быть 0 или единица. Но все остальные номера будут использовать его в качестве базы, что позволит собрать пакеты в правильном порядке;

Получатель отвечает номером в поле подтверждения получения SYN, который соответствует установленному источником номеру. Кроме этого, в поле "номер в последовательности" может также сообщаться номер, который запрашивался источником;

Источник подтверждает, что принял сегмент получателя и отправляет первую порцию данных.

Графически этот процесс представлен на рисунке 2.12.

Рис. 2.12. Установка соединения TCP

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

Потоковый характер протокола определяется тем, что SYN определяет стартовый номер для отсчета переданных байтов, а не пакетов. Это значит, что если SYN был установлен в 0, и было передано 200 байтов, то номер, установленный в следующем пакете будет равен 201, а не 2.

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

Рис. 2.13. Механизм передачи данных по TCP

В данном примере окно установлено в 250 байтов шириной. Это означает, что текущий сегмент - сегмент со смещением относительно SYN, равном 250 байтам. Однако, после передачи всего окна модуль TCP источника получил подтверждение на получение только первых 100 байтов. Следовательно, передача будет начата со 101 байта, а не с 251.

Таким образом, мы рассмотрели все основные свойства протокола TCP. Осталось только назвать наиболее известные приложения, которые использует TCP для обмена данными. Это в первую очередь TELNET и FTP, а также протокол HTTP, который является сердцем World Wide Web.

Прервем немного разговор о протоколах и обратим свое внимание на такую важнейшую компоненту всей системы TCP/IP как IP-адреса.

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

Порт всегда связан с IP-адресом хоста и типом и, таким образом, завершает назначение адреса сеанса связи. Он идентифицируется для каждого адреса и протокола с помощью 16-битного числа, широко известного как номер порта. Конкретные номера портов часто используются для определения конкретных услуг. Из тысяч перечисленных 1024 хорошо известных номера портов защищены в соответствии с соглашением, чтобы определить конкретные типы услуг на хосте. Протоколы, которые в основном используют порты, служат для управления процессами (например, протокол управления передачей (TCP) и User Datagram Protocol (UDP) из комплекта протоколов Internet).

Значение

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

Детали

Протоколы передачи данных - Transmission Control Protocol (TCP) и User Datagram Protocol (UDP) - применяются для того, чтобы указать номер порта назначения и источник в своих заголовках сегментов. Номер порта представляет собой 16-разрядное целое число без знака. Таким образом, он может быть в диапазоне от 0 до 65535.

Тем не менее TCP-порты не могут использовать номер 0. Порт источника для UDP не обязателен, и значение, равное нулю, означает его отсутствие.

Процесс связывает свои входные или выходные каналы через интернет-сокет (тип дескриптора файла) посредством транспортного протокола, номера порта и IP-адреса. Этот процесс известен как связывание, и он дает возможность передачи и приема данных через сеть.

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

Как они используются

Приложения, реализующие общие службы, часто используют специально зарезервированный и хорошо известный список портов TCP и UDP для приема запросов на обслуживание от клиентов. Этот процесс известен как прослушивание, и он включает в себя получение запроса с хорошо известного порта и установления диалога между сервером и клиентом «один-к-одному», с использованием одного и того же номера локального порта. Другие клиенты могут продолжать подключаться - это возможно, так как соединение TCP идентифицируется как цепочка, состоящая из локального и удаленного адресов и портов. Стандартные порты TCP и UDP определяются по соглашению под контролем Internet Assigned Numbers Authority (IANA).

Ядро сетевых сервисов (в первую очередь, WorldWideWeb), как правило, использует небольшие номера портов - меньше, чем 1024. Во многих операционных системах требуются специальные привилегии для приложений для привязки к ним, потому что они часто считаются критическими для функционирования IP-сетей. С другой стороны, конечный клиент соединения, как правило, применяет большое их количество, выделенных для краткосрочного использования, поэтому существуют так называемые эфемерные порты.

Структура

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

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

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

Примеры использования

Самым главным примером, где активно используются порты TCP/UDP, является почтовая система Интернет. Сервер применяется для работы с электронной почтой (отправкой и получением), и в целом нуждается в двух услугах. Первый сервис используется для транспортировки по электронной почте и с других серверов. Это достигается с помощью Как правило, приложение-служба SMTP прослушивает TCP-порт номер 25 с целью обработки входящих запросов. Другая услуга представляет собой POP (полностью - Post Office Protocol) либо IMAP (или Internet Message Access Protocol) который необходимы для клиентских приложений в электронной почте на машинах пользователей, чтобы получать с сервера сообщения электронной почты. Службами POP прослушиваются номера с TCP-порта 110. Вышеуказанные службы обе могут запускаться на одном и том же хост-компьютере. Когда это происходит, номер порта отличает сервис, запрошенный удаленным устройством - ПК пользователя либо каким-либо иным почтовым сервером.

В то время как номер порта прослушивания сервера корректно определен (IANA называет их хорошо известными портами), данный параметр клиента часто выбирается из динамического диапазона. В некоторых случаях клиенты и сервер по отдельности используют определенные TCP-порты, назначенные в IANA. Наглядным примером может служить DHCP, где клиентом во всех случаях используется UDP 68, а сервером - UDP 67.

Применение в URL-адресах

Номера портов иногда хорошо видны в Интернете или других унифицированных указателях информационных ресурсов (URL). По умолчанию HTTP использует а HTTPS - 443. Вместе с тем существуют и другие вариации. Например, URL-адрес http://www.example.com:8080/path/ указывает, что веб-браузер подключается к 8080 вместо сервера HTTP.

Список портов TCP и UDP

Как уже было отмечено, Internet Assigned Numbers Authority (IANA) несет ответственность за глобальную координацию DNS-Root, IP-адресации и других ресурсов Интернет-протокола. Это включает в себя регистрацию часто используемых номеров портов для известных интернет-сервисов.

Номера портов разделены на три диапазона: хорошо известные, зарегистрированные и динамические или частные. Хорошо известные (также известные как системные) - это имеющие номера от 0 до 1023. Требования, предъявляемые к новым назначениям в этом диапазоне, являются более строгими, чем для других регистраций.

Широко известные примеры

Примеры, находящиеся в данном списке, включают в себя:

• TCP 443 порт: HTTP Secure (HTTPS).
• 22: Secure Shell (SSH).
• 25: Простой протокол передачи почты (SMTP).
• 53: Система доменных имен (DNS).
• 80: Протокол передачи гипертекста (HTTP).
• 119: Протокол передачи сетевых новостей (NNTP).
• 123: Протокол сетевого времени (NTP)..
• 143: Internet Message Access Protocol (IMAP)
• 161: Простой протокол управления сетью (SNMP)1.
• 94: Internet Relay Chat (IRC).

Зарегистрированные порты содержат номера от 1024 до 49151. IANA поддерживает официальный список известных и зарегистрированных диапазонов. Динамические или частные - от 49152 до 65535. Один из вариантов использования этого диапазона предназначен для временных портов.

История создания

Концепция номера порта была создана ранними разработчиками ARPANET в условиях неформального сотрудничества авторов программного обеспечения и системных администраторов.

Термин «номер порта» еще не использовался в то время. Номерной ряд для удаленного хоста был 40-битным числом. Первые 32 бита были похожи на сегодняшний IPv4-адрес, но при этом наиболее значимыми были первые 8 бит. Наименее значительная часть числа (биты с 33 по 40) обозначали другой объект, который назывался AEN. Это и есть прототип современного номера порта.

26 марта 1972 года было впервые предложено создание каталога номеров сокета в RFC 322. призвали описать каждый постоянный номер на предмет его функций и сетевых услуг. Этот каталог был впоследствии опубликован в RFC 433 в декабре 1972 года и включал в себя список хостов, их номера портов и соответствующую функцию, используемую на каждом узле в сети. В мае 1972 года впервые были задокументированы официальные назначения номеров портов, сетевых служб, а также предложена специальная административная функция для ведения этого реестра.

Первый список TCP-портов имел 256 значений AEN, которые были разделены на следующие диапазоны:

• От 0 до 63: стандартные функции всей сети
• От 64 до 127: хост-специфичные функции
• От 128 до 239: зарезервированные для будущего использования
• От 240 до 255: любая экспериментальная функция.

Служба Telnet получила первое официальное присвоение значения 1. В начале существования ARPANET термином AEN также называли имя сокета, которое использовалось с первоначальным протоколом соединения (MSP) и компонентом программы управления сетью (NCP). При этом NCP был предшественником современных Интернет-протоколов, использующих порты TCP/IP.