Заголовок какого протокола содержит номер порта отправителя
Обновлено: 25.04.2024
Протокол TCP (Transmission Control Protocol, Протокол контроля передачи) обеспечивает сквозную доставку данных между прикладными процессами, запущенными на узлах, взаимодействующих по сети. Стандартное описание TCP содержится в RFC-793.
TCP - надежный байт-ориентированный (byte-stream) протокол с установлением соединения . TCP находится на транспортном уровне стека TCP/IP, между протоколом IP и собственно приложением. Протокол IP занимается пересылкой дейтаграмм по сети, никак не гарантируя доставку, целостность, порядок прибытия информации и готовность получателя к приему данных; все эти задачи возложены на протокол TCP.
При получении дейтаграммы, в поле Protocol которой указан код протокола TCP (6), модуль IP передает данные этой дейтаграммы модулю TCP. Эти данные представляют собой TCP-сегмент, содержащий TCP-заголовок и данные пользователя (прикладного процесса). Модуль TCP анализирует служебную информацию заголовка, определяет, какому именно процессу предназначены данные пользователя, проверяет целостность и порядок прихода данных и подтверждает их прием другой стороне. По мере получения правильной последовательности неискаженных данных пользователя они передаются прикладному процессу.
Ниже основные функции протокола TCP и их реализация рассмотрены более подробно.
3.1.1. Базовая передача данных
Протокол TCP рассматривает данные клиента как непрерывный неинтерпретируемый поток октетов. TCP разделяет этот поток на части для пересылки на другой узел в TCP-сегментах некоторого размера. Для отправки или получения сегмента модуль TCP вызывает модуль IP.
Немедленное отправление данных может быть затребовано процессом-клиентом от TCP-модуля с помощью специальной функции PUSH, иначе TCP сам будет решать, как накапливать и когда отправлять данные клиента или когда передавать клиенту полученные данные.
3.1.2. Обеспечение достоверности
Модуль TCP обеспечивает защиту от повреждения, потери, дублирования и нарушения очередности получения данных.
Для выполнения этих задач все октеты в потоке данных сквозным образом пронумерованы в возрастающем порядке. Заголовок каждого сегмента содержит число октетов данных в сегменте и порядковый номер первого октета той части потока данных, которая пересылается в данном сегменте. Например, если в сегменте пересылаются октеты с номерами от 2001 до 3000, то номер первого октета в данном сегменте равен 2001, а число октетов равно 1000.
Номер первого байта в потоке определяется на этапе установления соединения и обозначается ISN+1 (подробнее см. п. 3.1.4). Например, ISN+1=1.
Также для каждого сегмента вычисляется контрольная сумма, позволяющая обнаружить повреждение данных.
При удачном приеме октета данных принимающий модуль посылает отправителю подтверждение о приеме - номер удачно принятого октета. Если в течение некоторого времени отправитель не получит подтверждения, считается, что октет не дошел или был поврежден, и он посылается снова. Этот механизм контроля надежности называется PAR (Positive Acknowledgment with Retransmission). В действительности подтверждение посылается не для одного октета, а для некоторого числа последовательных октетов (подробнее см. п. 3.1.5).
Нумерация октетов используется также для упорядочения данных в порядке очередности и обнаружения дубликатов (которые могут быть посланы из-за большой задержки при передаче подтверждения или потери подтверждения).
3.1.3. Разделение каналов
Протокол TCP обеспечивает работу одновременно нескольких соединений. Каждый прикладной процесс идентифицируется номером порта . Заголовок TCP-сегмента содержит номера портов процесса-отправителя и процесса-получателя. При получении сегмента модуль TCP анализирует номер порта получателя и отправляет данные соответствующему прикладному процессу.
Все распространенные сервисы Интернет имеют стандартизованные номера портов. Например, номер порта сервера электронной почты - 25, сервера FTP - 21. Список стандартных номеров портов можно найти в файле /etc/services (Unix).
Совокупность IP-адреса и номера порта называется сокетом . Сокет уникально идентифицирует прикладной процесс в Интернет. Например, сокет сервера электронной почты на хосте 194.84.124.4 обозначается как 194.84.124.4.25; часто номер порта отделяется двоеточием.
3.1.4. Управление соединениями
Соединение - это совокупность информации о состоянии потока данных, включающая сокеты, номера посланных, принятых и подтвержденных октетов, размеры окон.
Каждое соединение уникально идентифицируется в Интернет парой сокетов.
Соединение характеризуется для клиента именем, которое является указателем на структуру TCB (Transmission Control Block), содержащую информацию о соединении.
Открытие соединения клиентом осуществляется вызовом функции OPEN, которой передается сокет, с которым требуется установить соединение. Функция возвращает имя соединения. Различают два типа открытия соединения: активное и пассивное.
При активном открытии TCP-модуль начинает процедуру установления соединения с указанным сокетом, при пассивном - ожидает, что удаленный TCP-модуль начнет процедуру установления соединения с указанного сокета. Указание 0.0.0.0:0 в качестве сокета при пассивном открытии означает, что ожидается соединение с любого сокета. Такой способ применяется в демонах - серверах Интернет, которые ждут установления соединения от клиента. Клиент же применяет процедуру активного открытия; сокет при этом формируется из IP-адреса сервера и стандартного номера порта для данного сервиса.
Закрытие соединения клиентом производится с помощью функции CLOSE, которой передается имя соединения.
Процедура установления соединения происходит следующим образом.
Предположим, узел А желает установить соединение с узлом В. Первый отправляемый из А в В TCP-сегмент не содержит полезных данных, а служит для установления соединения. В его заголовке (в поле Flags, см. п. 3.2) установлен бит SYN, означающий запрос связи, и содержится ISN (Initial Sequence Number - начальный номер последовательности) - число, начиная с которого узел А будет нумеровать отправляемые октеты (например, 0). В ответ на получение такого сегмента узел В откликается посылкой TCP-сегмента, в заголовке которого установлен бит ACK, подтверждающий установление соединения для получения данных от узла А. Так как протокол TCP обеспечивает полнодуплексную передачу данных, то узел В в этом же сегменте устанавливает бит SYN, означающий запрос связи для передачи данных от В к А, и передает свой ISN (например, 0). Полезных данных этот сегмент также не содержит. Третий TCP-сегмент в сеансе посылается из А в В в ответ на сегмент, полученный из В. Так как соединение А -> В можно считать установленным (получено подтверждение от В), то узел А включает в свой сегмент полезные данные, нумерация которых начинается с номера ISN(A)+1. Данные нумеруются по количеству отправленных октетов. В заголовке этого же сегмента узел А устанавливает бит ACK, подтверждающий установление связи B -> A, что позволяет хосту В включить в свой следующий сегмент полезные данные для А.
Рис. 3.1.1. Установка TCP-соединения
Сеанс обмена данными заканчивается процедурой разрыва соединения, которая аналогична процедуре установки, с той разницей, что вместо SYN для разрыва используется служебный бит FIN (“данных для отправки больше не имею”), который устанавливается в заголовке последнего сегмента с данными, отправляемого узлом.
3.1.5. Управление потоком
Для ускорения и оптимизации процесса передачи больших объемов данных протокол TCP определяет метод управления потоком, называемый методом скользящего окна, который позволяет отправителю посылать очередной сегмент, не дожидаясь подтверждения о получении в пункте назначения предшествующего сегмента.
Протокол TCP формирует подтверждения не для каждого конкретного успешно полученного пакета, а для всех данных от начала посылки до некоторого порядкового номера ACK SN (Acknowledge Sequence Number) исключительно. В качестве подтверждения успешного приема, например, первых 2000 байт, высылается ACK SN = 2001: это означает, что все данные в байтовом потоке под номерами от ISN+1=1 до данного ACK SN -1 (2000) успешно получены (см. рис. 3.1.2).
Рис. 3.1.2. Метод скользящего окна
Вместе с посылкой отправителю ACK SN получатель объявляет также “размер окна”, например - 6000. Это значит, что отправитель может посылать данные с порядковыми номерами от текущего ACK SN = 2001 до (ACK SN + размер окна -1) = 8000, не дожидаясь подтверждения со стороны получателя. Допустим, в данный момент отправитель посылает тысячеоктетный сегмент с порядковым номером данных SN=4001. Если не будет получено новое подтверждение (новый ACK SN), отправитель будет посылать данные, пока он остается в пределах объявленного окна, то есть до номера 8001. После этого посылка данных будет прекращена до получения очередного подтверждения и (возможно) нового размера окна. Однако размер окна выбирается таким образом, чтобы подтверждения успевали приходить вовремя и остановки передачи не происходило - для этого и предназначен метод скользящего окна. Размер окна может динамически изменяться получателем.
Для временной остановки посылки данных достаточно объявить нулевое окно. Но даже и в этом случае через определенные промежутки времени будут отправляться сегменты с одним октетом данных. Это делается для того, чтобы отправитель гарантированно узнал о том, что получатель вновь объявил ненулевое окно, поскольку получатель обязан подтвердить получение “пробных” сегментов, а в этих подтверждениях он укажет также и текущий размер своего окна.
Как уже было сказано выше, протокол TCP позволяет вести полнодуплексную передачу. Один и тот же сегмент, высылаемый, например, из В в А, может содержать в заголовке служебную информацию по подтверждению получения данных от А, а в поле данных - полезные данные для А.
Модуль TCP может оптимизировать максимальный размер сегмента исходя из значений MTU на разных участках маршрута (см. также п. 2.4.2, "Path MTU Discovery") и других характеристик соединения.
В случае, если никакие данные приложениями не передаются, а соединение открыто, модуль TCP может периодически посылать сегменты-зонды для выяснения того, не отключилась ли другая сторона без уведомления партнера (например, в результате обрыва линии или другим некорректным образом). Такое зондирование проводится примерно каждые два часа неактивности.
3.2. Заголовок TCP-сегмента
TCP-сегмент состоит из заголовка и данных.
Заголовок сегмента состоит из 32-разрядных слов и имеет переменную длину, зависящую от размера поля Options, но всегда кратную 32 битам. За заголовком непосредственно следуют данные - часть потока данных пользователя, передаваемая в данном сегменте.
Значения полей заголовка следующие.
Source Port (16 бит), Destination Port (16 бит) - номера портов процесса-отправителя и процесса-получателя соответственно.
Sequence Number (SN) (32 бита) - порядковый номер первого октета в поле данных сегмента среди всех октетов потока данных для текущего соединения, то есть если в сегменте пересылаются октеты с 2001-го по 3000-й, то SN=2001. Если в заголовке сегмента установлен бит SYN (фаза установления соединения), то в поле SN записывается начальный номер (ISN), например, 0. Номер первого октета данных, посылаемых после завершения фазы установления соединения, равен ISN+1. Acknowledgment Number (ACK) (32 бита) - если установлен бит ACK, то это поле содержит порядковый номер октета, который отправитель данного сегмента желает получить. Это означает, что все предыдущие октеты (с номерами от ISN+1 до ACK-1 включительно) были успешно получены.
Data Offset (4 бита) - длина TCP-заголовка в 32-битных словах.
Reserved (6 бит) - зарезервировано; заполняется нулями.
Control Bits (6 бит) - управляющие биты; активным является положение “бит установлен”.
URG - поле срочного указателя (Urgent Pointer) задействовано;
ACK - поле номера подтверждения (Acknowledgment Number) задействовано;
PSH - осуществить “проталкивание” - если модуль TCP получает сегмент с установленным флагом PSH, то он немедленно передает все данные из буфера приема процессу-получателю для обработки, даже если буфер не был заполнен;
RST - перезагрузка текущего соединения;
SYN - запрос на установление соединения;
FIN - нет больше данных для передачи.
Window (16 бит) - размер окна в октетах (см. выше п. 3.1.5).
Urgent Pointer (16 бит) - используется для указания длины срочных данных, которые размещаются в начале поля данных сегмента. Указывает смещение октета, следующего за срочными данными, относительно первого октета в сегменте. Например, в сегменте передаются октеты с 2001-го по 3000-й, при этом первые 100 октетов являются срочными данными, тогда Urgent Pointer = 100. Протокол TCP не определяет, как именно должны обрабатываться срочные денные, но предполагает, что прикладной процесс будет предпринимать усилия для их быстрой обработки. Поле Urgent Pointer задействовано, если установлен флаг URG.
Options - поле переменной длины; может отсутствовать или содержать одну опцию или список опций, реализующих дополнительные услуги протокола TCP. Опция состоит из октета "Тип опции", за которым могут следовать октет "Длина опции в октетах" и октеты с данными для опции.
Стандарт протокола TCP определяет три опции (типы 0,1,2).
Опции типов 0 и 1 ("Конец списка опций" и "Нет операции" соответственно) состоят из одного октета, содержащего значение типа опции. При обнаружении в списке опции "Конец списка опций" разбор опций прекращается, даже если длина заголовка сегмента (Data Offset) еще не исчерпана. Опция "Нет операции" может использоваться для выравнивания между опциями по границе 32 бит.
Опция типа 2 "Максимальный размер сегмента" состоит из 4 октетов: одного октета типа опции (значение равно 2), одного октета длины (значение равно 4) и двух октетов, содержащих максимальный размер сегмента, который способен получать TCP-модуль, отправивший сегмент с данной опцией. Опцию следует использовать только в SYN-сегментах на этапе установки соединения.
Padding - выравнивание заголовка по границе 32-битного слова, если список опций занимает нецелое число 32-битных слов. Поле Padding заполняется нулями.
3.3. Промежуточные состояния соединения
TCP-соединение во время функционирования проходит через ряд промежуточных состояний. Это состояния LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, а также фиктивное состояние CLOSED. (Состояние CLOSED является фиктивным, поскольку оно представляет отсутствие соединения.) Переход из одного состояния в другое происходит в ответ на события, как то: запросы клиента, приход сегментов, истечение контрольного времени.
Определены следующие запросы процесса-клиента модулю TCP (с каждым запросом, кроме OPEN, передается имя соединения):
ACTIVE-OPEN - активное открытие соединения;
PASSIVE-OPEN - пассивное открытие соединения (см. выше п. 3.1.4);
SEND - отправка данных (передается указатель на буфер данных, размер буфера, значения флагов URG и PSH);
RECEIVE - получение данных (передается указатель на буфер данных, размер буфера; возвращается счетчик полученных октетов, значения флагов URG и PSH);
STATUS - запрос состояния соединения;
CLOSE - закрытие соединения (производится досылка всех неотправленных данных и обмен сегментами с битом FIN);
ABORT - ликвидация соединения (уничтожаются блок TCB и все неотправленные данные, посылается сегмент с битом RST).
Деятельность программы протокола TCP можно рассматривать как реагирование на события в зависимости от состояния соединения.
Ниже описаны состояния соединения и приведены диаграммы переходов. Под термином "процесс" здесь понимается процесс TCP-модуля, работающий с данным соединением на локальном узле; термин "чужой" относится к процессу, работающему с данным TCP-соединением на удаленном узле.
LISTEN - процесс пассивно ждет запроса со стороны чужих сокетов.
SYN-SENT - процесс отправил свой SYN и ждет чужого SYN.
SYN-RECEIVED - процесс получил чужой SYN, отправил (раньше или только что) свой SYN и ждет ACK на свой SYN.
ESTABLISHED - процесс отправил ACK на чужой SYN, получил ACK на свой SYN; соединение установлено.
FIN-WAIT-1 - процесс первый отправил свой FIN и ждет реакцию той стороны; при этом он, возможно, продолжает получать данные.
FIN-WAIT-2 - процесс получил ACK на свой ранее отправленный FIN, но не получил чужой FIN; ждет чужой FIN; при этом, возможно, продолжает получать данные.
CLOSE-WAIT - процесс, не отправив свой FIN (возможно, не собираясь прекращать соединение), получает чужой FIN; он отправляет ACK на чужой FIN, но при этом, возможно, продолжает отправлять данные.
LAST-ACK - процесс отправил свой FIN, но ранее он уже получил FIN с той стороны и отправил на него ACK; поэтому процесс ожидает чужой ACK на свой FIN для окончательного закрытия соединения.
CLOSING - процесс ранее отправил свой FIN и еще не получил не него подтверждение, но получил чужой FIN (и отправил на него ACK); ждет ACK на свой FIN.
TIME-WAIT - процесс ранее отправил свой FIN и получил на него подтверждение, получил чужой FIN и только что отправил на него ACK; теперь процесс ждет некоторое время (два времени жизни сегмента, обычно 4 минуты) для гарантии того, что та сторона получит его ACK на свой FIN, после чего соединение будет окончательно закрыто.
CLOSED - соединение отсутствует.
В диаграммах пп. 3.3.1 и 3.3.2 состояния соединения заключены в прямоугольники, переходы между ними показаны стрелками, с каждой стрелкой соотносится овал, поясняющий причину перехода. В овале над горизонтальной чертой указывается событие, вызвавшее переход (курсивом обозначено поступление запросов от локального процесса-клиента); под горизонтальной чертой - действие, сопутствующее переходу.
3.3.1. Фаза установления соединения
3.3.2. Фаза закрытия соединения
Проблемы возникновения некорректных ситуаций, например, наполовину открытое соединение, получение заблудившихся в сети старых SYN-сегментов, неожиданный крах программ и т.п., решаются путем детектирования ошибки (несоответствие или бессмысленные значения ACK или SN), после чего посылается сигнал RST (сегмент с установленным битом RST) и соединение ликвидируется.
TCP-отправитель передает каждый сегмеит в одном IP-пакете вместе с ТСР-за- головком. Как показано на рис. 5.8, TCP-заголовок состоит из следующих полей.
Рис. 5.8. Формат ТСР-сегмеита
• Номер порта источника (source port) (16 бит). 16-битный помер порта, ассоциированный с ТСР-отправителем. IP-адрес отправителя содержится в IP-заголовке.
• Номер порта получателя (destination port) (16 бит). 16-битный помер норга, ассоциированный с ТСР-получателем. IP-адрес получателя содержится в IР-за- головке.
• Порядковый номер (sequence number) (32 бита). 32-битпый порядковый номер идентифицирует позицию первого байта сегмепта, содержащегося в пакете. Получатель использует порядковый номер для идентификации местоположения сегмепта в потоке байтов и реорганизации сегментов, поступающих не в том порядке. Перед передачей первого сегмента отправитель выбирает начальный порядковый номер, который представляет пачало упорядоченного байтового потока. Порядковые номера для всех сегментов строятся относительно этого начального порядкового номера.
• Номер подтверждения (acknowledgement number) (32 бита). Для подтверждения получения данных TCP-заголовок содержит 32-битпый помер подтверждения. Это поле указывает на следующий байт, который ожидается получателем, и корректно только в том случае, если флаг ACK установлен в 1. Когда приложение А передает данные приложению В, TCP-заголовок содержит порядковый помер каждого сегмента, и пакеты от В к А подтверждают получение этих сегментов.
• Длина заголовка (header length) (4 бита). 4-битная Длина заголовка указывает на количество 32-бигпых слов в TCP-заголовке. Заголовок обычно имеет длину 20 байтов, что соответствует пяти 32-битным словам. Более длинным заголовок может быть в случае использования отправителем опций TCP, которые содержат дополнительную управляющую информацию.
• Зарезервировано (6 бит). 6-битпое поле зарезервировано для будущего использования.
– URG. Флаг URG (флаг срочности) инструктирует TCP-получателя обратиться к части сегмента, идентифицируемой 16-бигпым полем указателя срочности в ТСР-заголовке.
– ACK. Флаг ACK (подтверждения) устанавливается при отправке подтверждения. Если флаг ACK установлен, 32-битное поле подтверждения указывает, сколько данных было получено отправителем. В пачале передачи данных ТСР-отиравитель почти всегда устанавливает бит ACK.
– PSH. Флаг PSH (форсированной отправки) указывает, что ТСР-получа- тель должен немедленно передать входящие данные сокету приложения.
– RST. Флаг RST (сброс) устанавливается при разрыве ТСР-соединения.
– SYN. Флаг SYN (синхронизации) устанавливается при установлении TCP-соединения. Если флаг SYN установлен, значение в иоле порядкового номера идентифицирует начальный порядковый помер.
~ FIN. Флаг FIN (окончания передачи) устанавливается, когда отправитель закончил передачу данных. При чтении принимающим приложением из сокета FIN преобразуется в символ конца файла.
Флаги SYN, ACK, FIN и RST будут подробнее обсуждаться далее в этом разделе. На практике большинство операционных систем не предоставляет для отправляющего приложения возможность установки флага PSH, а для ТСР-полу- чателя — возможность реакции на этот флаг. Флаг URG применяется для уведомления интерактивных приложений, таких как Telnet, о наличии управляющих символов (например, ctrl-C), которые могут повлиять на обработку предыдущих байтов в потоке.
• Окно приема (receiver windows) (16 битов). 16-битпое поле окпа приема содержит число дополнительных байтов, которые получатель может принять, помимо подтвержденных на данный момепт данных. Чтобы избежать переполнения входного буфера, TCP-отправитель не должен передавать данные, объем которых превышает размер окпа приема.
• Контрольная сумма TCP (TCP checksum) (16 битов). 16-битная контрольная сумма помогает TCP-получателю обнаруживать поврежденные пакеты.
В отличие от контрольной суммы IP-заголовка, контрольная сумма TCP распространяется и на заголовок, и на данные. Контрольная сумма дает возможность получателю выявить, был ли ТСР-сегмент поврежден во время передачи но сети. Отправитель вычисляет контрольную сумму массива из заголовка и данных. Получатель пересчитывает контрольную сумму и сравнивает ее со значением в заголовке TCP. Если результаты различаются, получатель отвергает поврежденный накет. Получатель не подтверждает получение поврежденного пакета. Следовательно, отправитель должен повторно передать не поступившие данные.
• Указатель срочных данных (urgent pointer) (16 битов). Если флаг URG установлен, 16-битпый указатель срочпых данных обращает впимапие получателя на определенную часть входных данных (например, символ ctrl-C, который прерывает передачу данных). 16-битпый указатель срочных данных идентифицирует последний байт срочных данных как целочисленное смещение от порядкового номера в ТСР-заголовке.
IP-заголовок содержит некоторую информацию, необходимую для ТСР-соеди- пегшя, включая IP-адреса отправителя и получателя, а также размер пакета. Размер IP-пакета представляет собой сумму длип IР-заголовка, TCP-заголовка и TCP-сегмента. Длина IP-заголовка включается в IP-заголовок, а длина ТСР-заго- ловка включается в ТСР-заголовок.
Рис. 5.9. Четыре сегмента в ТСР-соединспии (третий сегмент утерян)
При поступлении пакета получатель определяет диапазон байтов, занимаемый TCP-сегментом, основываясь на его порядковом номере и длипе. Предположим, что отправитель пачал с исходного порядкового номера 4500 и передает данные 100-байтпыми сегментами, как показано на рис. 5.9. Порядковый помер 4500 соответствует открытию ТСР-соединения. Первый сегмент имеет порядковый номер 4501 и длину 100, и занимает байты с 4501 по 4600. Второй сегмент имеет порядковый помер 4601 и длину 100, и т.д. Допустим, что В получает первый, второй и четвертый сегменты; третий 100-байтный сегмент был утерян или задержап. Поскольку В было иолучено только 200 последовательных байтов потока, подтверждающий пакет от В к А будет иметь помер подтверждения, равный 4701 (4501+200). Номер байта 4701 представляет собой порядковый помер следующего байта, который В ожидает получить. Важно отметить, что поле порядкового номера соответствует передаче сегмента, а поле номера подтверждения соответствует получению данных. Приложения А и В могут передавать данные друг другу одновременно. Для любого пакета значения полей порядкового номера и номера подтверждения не взаимосвязаны, поскольку они не отпосягся к одному и тому же направлению передачи.
User Datagram Protocol
TCP/IP (иногда называют UDP/IP)
Ядра Windows, Linux, UNIX
Ядра Windows, Linux, UNIX
UDP использует простую модель передачи, без неявных "рукопожатий" для обеспечения надежности, упорядочивания или целостности данных. Таким образом, UDP предоставляет ненадежный сервис, и датаграммы могут прийти не по порядку, дублироваться или вовсе исчезнуть без следа. UDP подразумевает, что проверка ошибок и исправление либо не необходимы, либо должны исполняться в приложении. Чувствительные ко времени приложения часто используют UDP, так как предпочтительнее сбросить пакеты, чем ждать задержавшиеся пакеты, что может оказаться невозможным в системах реального времени. При необходимости исправления ошибок на сетевом уровне интерфейса приложение может задействовать TCP или SCTP, разработанные для этой цели.
Природа UDP как протокола без сохранения состояния также полезна для серверов, отвечающих на небольшие запросы от огромного числа клиентов, например DNS и потоковые мультимедийные приложения вроде IPTV, Voice over IP, протоколы туннелирования IP и многие онлайн-игры.
Содержание
Служебные порты
IANA разбила номера портов на три группы.
Структура пакета
UDP обеспечивает многоканальную передачу (с помощью номеров портов) и проверку целостности (с помощью контрольных сумм) заголовка и существенных данных. Надежная передача в случае необходимости должна реализовываться пользовательским приложением.
Заголовок UDP состоит из четырех полей, каждое по 2 байта (16 бит). Два из них необязательны к использованию в IPv4 (розовые ячейки в таблице), в то время как в IPv6 необязателен только порт отправителя.
Порт отправителя
В этом поле указывается номер порта отправителя. Предполагается, что это значение задает порт, на который при необходимости будет посылаться ответ. В противном же случае, значение должно быть равным 0. Если хостом-источником является клиент, то номер порта будет, скорее всего, эфемерным. Если источником является сервер, то его порт будет одним из "хорошо известных".
Порт получателя
Это поле обязательно и содержит порт получателя. Аналогично порту отправителя, если клиент - хост-получатель, то номер порта эфемерный, иначе (сервер - получатель) это "хорошо известный порт".
Длина датаграммы
Поле, задающее длину всей датаграммы (заголовка и данных) в байтах. Минимальная длина равна длине заголовка - 8 байт. Теоретически, максимальный размер поля - 65535 байт для UDP-датаграммы (8 байт на заголовок и 65527 на данные). Фактический предел для длины данных при использовании IPv4 - 65507 (помимо 8 байт на UDP-заголовок требуется еще 20 на IP-заголовок).
В Jumbogram-ах IPv6 пакеты UDP могут иметь больший размер. Максимальное значение составляет 4,294,967,295 байт (2^32 - 1), из которых 8 байт соответствуют заголовку, а остальные 4,294,967,287 байт - данным.
Контрольная сумма
Поле контрольной суммы используется для проверки заголовка и данных на ошибки. Если сумма не сгенерирована передатчиком, то поле заполняется нулями. Поле не является обязательным для IPv4.
Расчёт контрольной суммы
Метод для вычисления контрольной суммы определен в RFC 768.
Нулевое значение контрольной суммы зарезервировано, и означает что датаграмма не имеет контрольной суммы. В случае, если вычисленная контрольная сумма получилась равной нулю, поле заполняют двоичнымим единицами.
Пример расчёта контрольной суммы
Для примера рассчитаем контрольную сумму нескольких 16-битных слов: 0x398a, 0xf802, 0x14b2, 0xc281 . Находим их сумму с поразрядным дополнением.
0x398a + 0xf802 = 0x1318c → 0x318d
0x318d + 0x14b2 = 0x0463f → 0x463f
0x463f + 0xc281 = 0x108c0 → 0x08c1
Теперь находим поразрядное дополнение до единицы полученного результата:
0x08c1 = 0000 1000 1100 0001 → 1111 0111 0011 1110 = 0xf73e или, иначе — 0xffff − 0x08c1 = 0xf73e . Это и есть искомая контрольная сумма.
Различие между IPv4 и IPv6 в данных, используемых для вычисления контрольной суммы.
Псевдозаголовки
Псевдозаголовок для IPv4
Если UDP работает над IPv4, контрольная сумма вычисляется при помощи псевдозаголовка, который содержит некоторую информацию из заголовка IPv4. Псевдозаголовок не является настоящим IPv4-заголовком, используемым для отправления IP-пакета. В таблице приведен псевдозаголовок, используемый только для вычисления контрольной суммы.
Адреса источника и получателя берутся из IPv4-заголовка. Значения поля "Протокол" для UDP равно 17 (0x11). Поле "Длина UDP" соответствует длине заголовка и данных.
Вычисление контрольной суммы для IPv4 необязательно, если она не используется, то значение равно 0.
Псевдозаголовок для IPv6
При работе UDP над IPv6 контрольная сумма обязательна. Метод для ее вычисления был опубликован в RFC 2460:
При вычислении контрольной суммы опять используется псевдозаголовок, имитирующий реальный IPv6-заголовок:
Адрес источника такой же, как и в IPv6-заголовке. Адрес получателя - финальный получатель; если в IPv6-пакете не содержится заголовка маршрутизации (Routing), то это будет адрес получателя из IPv6-заголовка, в противном случае, на начальном узле, это будет адрес последнего элемента заголовка маршрутизации, а на узле-получателе - адрес получателя из IPv6-заголовка. Значение "Следующий заголовок" равно значению протокола - 17 для UDP. Длина UDP - длина UDP-заголовка и данных.
Надежность и решения проблемы перегрузок
Из-за недостатка надежности, приложения UDP должны быть готовыми к некоторым потерям, ошибкам и дублированиям. Некоторые из них (например, TFTP) могут при необходимости добавить элементарные механизмы обеспечения надежности на прикладном уровне.
Но чаще такие механизмы не используются UDP-приложениями и даже мешают им. Потоковые медиа, многопользовательские игры в реальном времени и VoIP - примеры приложений, часто использующих протокол UDP. В этих конкретных приложениях потеря пакетов обычно не является большой проблемой. Если приложению необходим высокий уровень надежности, то можно использовать другой протокол (TCP) или erasure codes.
Более серьезной потенциальной проблемой является то, что в отличие от TCP, основанные на UDP приложения не обязательно имеют хорошие механизмы контроля и избежания перегрузок. Чувствительные к перегрузкам UDP-приложения, которые потребляют значительную часть доступной пропускной способности, могут поставить под угрозу стабильность в Интернете.
Сетевые механизмы были предназначены для того, чтобы свести к минимуму возможные эффекты от перегрузок при неконтролируемых, высокоскоростных нагрузках. Такие сетевые элементы, как маршрутизаторы, использующие пакетные очереди и техники сброса, часто являются единственным доступным инструментом для замедления избыточного UDP-трафика. DCCP (англ. Datagram Congestion Control Protocol - протокол контроля за перегрузками датаграмм) разработан как частичное решение этой потенциальной проблемы с помощью добавления конечному хосту механизмов для отслеживания перегрузок для высокоскоростных UDP-потоков вроде потоковых медиа.
Приложения
Многочисленные ключевые Интернет-приложения используют UDP, в их числе - DNS (где запросы должны быть быстрыми и состоять только из одного запроса, за которым следует один пакет ответа), Простой Протокол Управления Сетями (SNMP), Протокол Маршрутной Информации (RIP), Протокол Динамической Конфигурации Узла (DHCP).
Голосовой и видеотрафик обычно передается с помощью UDP. Протоколы потокового видео в реальном времени и аудио разработаны для обработки случайных потерь пакетов так, что качество лишь незначительно уменьшается вместо больших задержек при повторной передаче потерянных пакетов. Поскольку и TCP, и UDP работают с одной и той же сетью, многие компании замечают, что недавнее увеличение UDP-трафика из-за этих приложений реального времени мешает производительности TCP-приложений вроде систем баз данных или бухгалтерского учета. Так как и бизнес-приложения, и приложения в реальном времени важны для компаний, развитие качества решений проблемы некоторыми рассматривается в качестве важнейшего приоритета.
Сравнение UDP и TCP
TCP - ориентированный на соединение протокол, что означает необходимость "рукопожатия" для установки соединения между двумя хостами. Как только соединение установлено, пользователи могут отправлять данные в обоих направлениях.
Область использования UDP
Формат UDP-дейтограмм
Рис. 4.4.2.1 Формат UDP-дейтограмм
Таблица 4.4.2.1 Номера UDP-портов (более полный перечень в RFC-1700; Если какой-то номер порта в перечне отсутствует, это не означает, что он не зарезервирован и его можно использовать, просто я сэкономил место). См. IANA, а также Приложения.
Стандартные номера портов UDP
| Номер порта | Обозначение | Назначение |
| 1397 | Аudio-activmail | Активная звуковая почта |
| 1398 | Video-activmail | Активная видео-почта |
| 5002 | RFE | Радио-Ethernet |
| 6000-6063 | X11 | Система X Window |
| 7008 | AFS3-update | Сервер-сервер актуализация |
Схема вычисления контрольных сумм
Модуль IP передает поступающий IP-пакет модулю UDP, если в заголовке этого пакета указан код протокола UDP. Когда модуль UDP получает дейтограмму от модуля IP, он проверяет контрольную сумму, содержащуюся в ее заголовке. Если контрольная сумма равна нулю, это означает, что отправитель ее не подсчитал. ICMP, IGMP, UDP и TCP протоколы имеют один и тот же алгоритм вычисления контрольной суммы (RFC-1071). Но вычисление контрольной суммы для UDP имеет некоторые особенности. Во-первых, длина UDP-дейтограммы может содержать нечетное число байт, в этом случае к ней добавляется нулевой байт, который служит лишь для унификации алгоритма и никуда не пересылается. Во-вторых, при расчете контрольной суммы для UDP и TCP добавляются 12-байтные псевдо-заголовки, содержащие IP-адреса отправителя и получателя, код протокола и длину дейтограммы (см. рис. 4.4.2.2). Как и в случае IP-дейтограммы, если вычисленная контрольная сумма равна нулю, в соответствующее поле будет записан код 65535.
Рис. 4.4.2.2. Псевдозаголовок, используемый при расчете контрольной суммы
Может возникнуть вопрос, зачем вычислять и проверять контрольную сумму, если подтверждение доставки и повторная пересылка в рамках протокола не предусмотрены. Дело в том, что UDP используется не только для мультимедийных задач но и некоторыми другими протоколами (DNS, SNMP и др.), где повторные запросы и отклики могут выполняться на прикладном уровне.
Так как максимальная длина IP-дейтограммы равна 65535 байтам, максимальная протяженность информационного поля UDP-дейтограммы составляет 65507 байт. На практике большинство систем работает с UDP-дейтограммами с длиной 8192 байта или менее (Ethernet допускает 1508 байт). Детальное описание форматов, полей пакетов и пр. читатель может найти в RFC-768. Смотри также RFC-2147 (IPv6 Jumbo), RFC-2508 (компрессия заголовков) и RFC-3828 (Lightweight UDP).
Нашел применение UDP и в протоколе Teredo (туннелирование IPv6 для систем NAT).
Заголовок какого протокола содержит номер порта отправителя
Нужны новые клиенты? Тогда Вам рекомендуем посмотреть этот раздел нашего сайта
_____
Заголовок TCP содержит информацию, которая определена TCP протоколом. В данном разделе описаны компоненты заголовка TCP.
Сегменты TCP передаются с помощью использования пакетов IP. Заголовок TCP следует за заголовком IP,. Это разделение допускает существование других протоколов на уровне хоста, отличных от TCP. Поля TCP заголовка включают следующие:
Порт отправителя (Source port): номер порта источника (16 бит)
Порт получателя (Destination port): номер порта назначения (16 бит)
Порядковый номер (Sequence number): порядковый номер первого октета данных
сегмента, используемый для гарантии правильного упорядочения приходящих данных
(32 бита)
Номер подтверждения (Acknowledgment number): следующий ожидаемый октет
TCP (32 бита)
Длина заголовка (Header length): количество 32-битных слов в заголовке (4 бита)
Зарезервировано (Reserved): установлено в 0 (3 бита)
Управляющие биты (Control bits): функции управления – такие как установка,
перегрузка и разрыв сеанса (9 бит). Одиночный бит, который имеет специальное
значение, часто рассматриваемое как флаг.
Окно (Window): число октетов, которое устройство согласно принять (16 бит)
Контрольная сумма (Checksum): вычисленная контрольная сумма полей заголовка и
данных (16 бит)
Указатель срочности данных (Urgent): показывает конец срочных данных (16 бит)
Опции (Options): в настоящее время определена одна опция – максимальный размер
сегмента TCP (0 или 32 бита)
Данные (Data): данные протокола вышележащего уровня (upper-layer protocol – ULP)
(переменная длина)
Сети и системы передачи информации
Официальная документация по Internet
Все разработчики должны придерживаться этой документации, но на практике, не всегда так происходит.
Адресация в сети Internet.
Компьютер в сети TCP/IP может иметь адреса трех уровней (но не менее двух):
IP-адрес, состоящий из 4 байт, например, 109.26.17.100. Этот адрес используется на сетевом уровне. Он назначается администратором во время конфигурирования компьютеров и маршрутизаторов.
IP-адреса принято записывать разбивкой всего адреса по октетам (8), каждый октет записывается в виде десятичного числа, числа разделяются точками. Например, адрес
10100000010100010000010110000011
записывается как
Перевод адреса из двоичной системы в десятичную
IP-адрес хоста состоит из номера IP-сети, который занимает старшую область адреса, и номера хоста в этой сети, который занимает младшую часть.
Базовые протоколы (IP, TCP, UDP)
Стек протоколов TCP/IP
Открытые стандарты протоколов, разрабатываемые независимо от программного и аппаратного обеспечения;
Независимость от физической среды передачи;
Система уникальной адресации;
Стандартизованные протоколы высокого уровня для распространенных пользовательских сервисов.
Стек протоколов TCP/IP
Стек протоколов TCP/IP делится на 4 уровня:
Физический и канальный.
Позже была принята 7-ми уровневая модель ISO.
Данные передаются в пакетах. Пакеты имеют заголовок и окончание, которые содержат служебную информацию. Данные, более верхних уровней вставляются, в пакеты нижних уровней.
Пример инкапсуляции пакетов в стеке TCP/IP
Физический и канальный уровень.
Стек TCP/IP не подразумевает использования каких-либо определенных протоколов уровня доступа к среде передачи и физических сред передачи данных. От уровня доступа к среде передачи требуется наличие интерфейса с модулем IP, обеспечивающего передачу IP-пакетов. Также требуется обеспечить преобразование IP-адреса узла сети, на который передается IP-пакет, в MAC-адрес. Часто в качестве уровня доступа к среде передачи могут выступать целые протокольные стеки, тогда говорят об IP поверх ATM, IP поверх IPX, IP поверх X.25 и т.п.
Межсетевой уровень и протокол IP.
Основу этого уровня составляет IP-протокол.
IP (Internet Protocol) – интернет протокол.
Первый стандарт IPv4 определен в RFC-760 (DoD standard Internet Protocol J. Postel Jan-01-1980)
Первый стандарт IPv6 определен в RFC-1883 (Internet Protocol, Version 6 (IPv6) Specification S. Deering, R. Hinden December 1995)
Протокол IP доставляет блоки данных от одного IP-адреса к другому.
Программа, реализующая функции того или иного протокола, часто называется модулем, например, “IP-модуль”, “модуль TCP”.
Когда модуль IP получает IP-пакет с нижнего уровня, он проверяет IP-адрес назначения.
Также может потребоваться, на границе сетей с различными характеристиками, разбить IP-пакет на фрагменты (фрагментация), а потом собрать в единое целое на компьютере-получателе.
Структура дейтограммы IP. Слова по 32 бита.
TOS играет важную роль в маршрутизации пакетов. Интернет не гарантирует запрашиваемый TOS, но многие маршрутизаторы учитывают эти запросы при выборе маршрута (протоколы OSPF и IGRP).
Коды некоторые протоколов RFC-1700 (1994)
Протокол IP является маршрутизируемый, для его маршрутизации нужна маршрутная информация.
Маршрутная информация, может быть:
Статической (маршрутные таблицы прописываются вручную)
Динамической (маршрутную информацию распространяют специальные протоколы)
Протоколы динамической маршрутизации:
Другие служебные IP-протоколы
Анализируя заголовок своего пакета, полученного от межсетевого уровня, транспортный модуль определяет по номеру порта получателя, какому из прикладных процессов направлены данные, и передает эти данные соответствующему прикладному процессу. Номера портов получателя и отправителя записываются в заголовок транспортным модулем, отправляющим данные; заголовок транспортного уровня содержит также и другую служебную информацию; формат заголовка зависит от используемого транспортного протокола.
На транспортном уровне работают два основных протокола: UDP и TCP.
Делает проверку целостности данных, если пакет битый посылает повторный запрос.
Структура дейтограммы TCP. Слова по 32 бита.
UDP (Universal Datagram Protocol) — универсальный протокол передачи данных, более облегченный транспортный протокол, чем TCP.
Основные отличия от TCP:
Отсутствует соединение между модулями UDP.
При потере пакета запрос для повторной передачи не посылается
Структура дейтограммы UDP. Слова по 32 бита.
Не все поля UDP-пакета обязательно должны быть заполнены. Если посылаемая дейтаграмма не предполагает ответа, то на месте адреса отправителя могут помещаться нули.
Протокол реального времени RTP
По номеру порта транспортные протоколы определяют, какому приложению передать содержимое пакетов.
А происходит это все посредством особого набора/стеку правил — TCP/IP, благодаря которому и работает интернет. Он включает в себя протоколы, каждый из которых ответственен за определенную функцию в сети.
Прошлый материал был, как раз посвящен TCP IP, сегодня же мы разберем за что отвечает протокол TCP и что это вообще такое.
TCP протокол
TCP — это транспортный протокол, является частью стека протоколов TCP IP, он выполняет функции управления передачей данных и следит за их сохранностью, считается надежным. Расшифровывается как Transmission Control Protocol (протокол управления передачей).
Это стандарт, который определяет как нужно устанавливать связь и поддерживать ее, чтобы две программы могли обмениваться данными между собой.
Интересно! Существует еще один транспортный протокол UDP, о нем мы поговорим в следующей отдельной статье, там же и разберем, чем они вообще отличаются друг от друга.
Является именно надежным протоколом так как:
1. Использует логическое соединение, благодаря чему обеспечивается надежная доставка данных.
2. Пронумеровывает передаваемые пакеты данных и проверяет их доставку, принимающая сторона высылает подтверждение о получении, в случае потери каких-либо пакетов создается повторная передача.
3. Делит передаваемые данные на части — пакеты данных, затем передает их нижнему уровню, и собирает их, когда они приходят к получателю.
4. Проверяет контрольную сумму передаваемых пакетов, если она отличается — создается новая отправка.
5. Проверяет пакеты на дубликаты, в случае обнаружения таковых — уничтожает.
6. Контролирует скорость передачи.
Заголовок TCP протокола
Весит 20 байт, если нет дополнительных опций, вот как он выглядит:
У каждого TCP сегмента указывается порт источника и назначения, с помощью которых происходит идентификация отправляющего и принимающего приложения. Эти порты вместе с IP адресами уникально идентифицируют каждое соединение. Комбинация IP и порта — это сокет (socket).
Номер последовательности — нумерация каждого отправляемого байта в потоке передаваемых данных. А номер подтверждения — это следующий номер байта после полученного, который ждет получатель. Т.е. передача идет последовательно, например, получатель получил 100-ый байт, следующим ждет 101.
Остальные значения можно понять из самой картинки. Разве, что размер окна — он скользящий, т.е. зависит от качества сети. Если много данных теряется он может уменьшаться и наоборот. Он регулирует количество передаваемых байтов.
А флаги: URG, ACK, PSH и т.д. — описывают дополнительные значения сегмента, так, например, флаг FIN применяется для завершения соединения.
Также, вам может быть интересна статья о том, что такое dns сервер. В ней очень подробно и интересно описано об этой глобальной системе.
Как работает TCP соединение
Соединение отправителя и получателя (два узла) происходит так:
1. Отправитель отсылает получателю специальный пакет, именуемый SYN, т.е. пригашает к соединению
2. Получатель отвечает уже пакетом SYN-ACK, т.е. соглашается
3. Отправитель отсылает спец. пакет ACK, т.е. подтверждает, что согласие получено
На этом TCP-соединение успешно установлено и получатель с отправителем могут спокойно обмениваться информацией. При передаче все пакеты данных нумеруются, отсылаются подтверждения о получении каждого из них, а потерянные пересылаются заново.
TCP порты
На каждом компьютере установлено, как минимум несколько программ. И сразу несколько из них могут обмениваться информацией, как же их различать? Именно для этого и были придуманы TCP порты, это по сути уникальный идентификатор соединения между двумя программами.
Номер порта — это число от 0 до 65535 в 16 битном формате, оно указывает какому именно приложению предназначается определенный пакет данных. Т.е. позволяет различным программам, работающим на одном компьютере, независимо друг от друга отправлять и получать информацию.
Есть целый ряд уже зарезервированных портов, которые являются стандартом:
Также, стоит отметить, что порты данного протокола никак не пересекаются с такими же, но у UDP. Так, например, порт: 1234 не пересечется с таким же, но у UDP.
В заключение
Вот вы и узнали, что это такое, постарался написать, как можно более понятно, без лишних терминов. Главное знать, как это работает и серфинг в интернете станет еще куда интереснее.
Читайте также: