Какой начальный порядковый номер сеанса isn
Перейти к содержимому

Какой начальный порядковый номер сеанса isn

  • автор:

Какой начальный порядковый номер сеанса isn

Протокол 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 рассматривает данные клиента как непрерывный неинтерпретируемый поток октетов. 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 может использовать алгоритм «медленного старта», формируя при установлении соединения окно перегрузки, размер которого изначально равен размеру одного сегмента. Это окно показывает, сколько сегментов TCP-модуль, с его собственной точки зрения, может отправить без получения подтверждения. Скользящее же окно, рассмотренное выше, показывает, какой объем неподтвержденных данных модулю разрешено отправить с точки зрения удаленного модуля, получателя его данных. После прихода подтверждения от получателя окно перегрузки увеличивается на 1 сегмент, и отправитель может выслать уже два сегмента, не дожидаясь подтверждения. Такой подход позволяет постепенно увеличивать нагрузку на сеть. Если окно перегрузки становится больше скользящего окна, объявляемого получателем, ограничение на передачу неподтвержденных данных устанавливает уже скользящее окно получателя.

В случае, если никакие данные приложениями не передаются, а соединение открыто, модуль 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).

Checksum (16 бит) — контрольная сумма, представляет собой 16 бит, дополняющие биты в сумме всех 16-битовых слов сегмента (само поле контрольной суммы перед вычислением обнуляется). Контрольная сумма, кроме заголовка сегмента и поля данных, учитывает 96 бит псевдозаголовка, который для внутреннего употребления ставится перед TCP-заголовком. Этот псевдозаголовок содержит IP-адрес отправителя (4 октета), IP-адрес получателя (4 октета), нулевой октет, 8-битное поле «Протокол», аналогичное полю в IP-заголовке, и 16 бит длины TCP сегмента, измеренной в октетах. Такой подход обеспечивает защиту протокола TCP от ошибшихся в маршруте сегментов. Информация для псевдозаголовка передается через интерфейс «Протокол TCP/межсетевой уровень» в качестве аргументов или результатов запросов от протокола TCP к протоколу IP.

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) и соединение ликвидируется.

Debugger’s tools

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

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

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

  • Сначала устанавливается, присутствует ли устройство назначения в сети.
  • Затем проверяется, имеется ли на устройстве назначения активный сервис и принимает ли он запросы на номер порта назначения, который инициирующий клиент планирует использовать для сеанса.
  • Далее устройству назначения сообщается, что клиент источника планирует установить сеанс связи на этом номере порта.

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

Шаг 1. Инициирующий клиент запрашивает сеанс связи клиент-сервер с сервером.
Шаг 2. Сервер подтверждает сеанс связи клиент-сервер и запрашивает сеанс связи сервер-клиент.
Шаг 3. Инициирующий клиент подтверждает сеанс связи сервер-клиент.
Используйте кнопки 1—3 на рисунке, чтобы просмотреть процесс установки TCP-соединения.

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

  • URG — поле «Указатель важности» задействовано
  • ACK — поле «Номер подтверждения» задействовано
  • PSH — протолкнуть данные
  • RST — оборвать соединение
  • SYN — синхронизировать порядковые номера
  • FIN — больше нет данных от отправителя

Поля ACK и SYN имеют отношение к рассматриваемому анализу трёхстороннего рукопожатия.

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

Шаг 1. Инициирующий клиент запрашивает сеанс связи клиент-сервер с сервером.

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

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

Управляющий флаг SYN установлен, а относительный порядковый номер равен 0. Несмотря на то, что анализатор протоколов на графике указывает относительные значения для порядкового номера и номера подтверждения, действительными значениями являются 32-битные двоичные номера. На рисунке показаны четыре байта, представленные в шестнадцатеричной системе исчисления.

Шаг 2. Сервер подтверждает сеанс связи клиент-сервер и запрашивает сеанс связи сервер-клиент.

Чтобы начать сеанс связи клиент-сервер, TCP-сервер должен подтвердить получение сегмента SYN от клиента. Для этого сервер возвращает сегмент клиенту с установленным флагом подтверждения (ACK), указывая на то, что номер подтверждения задействован. Если этот флаг в сегменте установлен, клиент считает это подтверждением того, что сервер получил SYN от клиента TCP.

Значение в поле номера подтверждения равно номеру ISN плюс 1. Это позволяет установить сеанс связи клиент-сервер. Для обеспечения сбалансированности сеанса флаг ACK остаётся установленным. Следует помнить, что сеанс связи между клиентом и сервером фактически представляет собой два односторонних сеанса: один клиент-сервер, другой — сервер-клиент. На втором шаге трёхстороннего рукопожатия сервер должен инициировать ответ клиенту. Чтобы начать этот сеанс, сервер использует флаг SYN точно так же, как это делал клиент. Он устанавливает управляющий флаг SYN в заголовке для установления сеанса типа сервер-клиент. Флаг SYN указывает на то, что начальное значение поля порядкового номера указано в заголовке. Это значение используется для отслеживания в этом сеансе потока данных от сервера к клиенту.

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

Шаг 3. Инициирующий клиент подтверждает сеанс связи сервер-клиент.

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

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

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

  • Отказ от установления TCP-сеансов
  • Разрешение сеансов только для определённых сервисов
  • Допуск трафика только в рамках уже установленных сеансов

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

Для прекращения соединения в заголовке сегмента должен быть установлен управляющий флаг Finish (FIN). Для завершения каждого одностороннего TCP-сеанса используется двухстороннее рукопожатие, которое состоит из сегмента FIN и сегмента ACK. Следовательно, чтобы завершить один сеанс связи, поддерживаемый протоколом TCP, необходимы четыре обмена данными, которые завершат оба сеанса, как показано на рис. 1.

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

Шаг 1. Когда у клиента больше нет данных для отправки в потоке, он отправляет сегмент с установленным флагом FIN.

Шаг 2. Сервер отправляет ACK, чтобы подтвердить получение FIN для завершения сеанса клиент-сервер.
Шаг 3. Сервер отправляет FIN клиенту, чтобы завершить сеанс сервер-клиент.
Шаг 4. Клиент возвращает ACK для подтверждения получения FIN от сервера.

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

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

На рис. 2 и 3 показано, что управляющие флаги FIN и ACK установлены в заголовке сегмента, закрывая таким образом HTTP-сеанс.

Соединение можно также завершить с помощью трёхстороннего рукопожатия. Когда у клиента больше нет данных для отправки, он передаёт FIN серверу. Если у сервера также нет данных для отправки, он может в ответ переслать сегменты с установленными флагами FIN и ACK, объединяя два шага в один. В ответ клиент отправляет ACK.

Надёжность и управление потоком

Повторное упорядочивание сегментов

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

Во время настройки сеанса связи устанавливается начальный порядковый номер сеанса (ISN). Этот номер ISN представляет начальное значение байтов для этого сеанса, которое передаётся получающему приложению. По мере передачи данных во время сеанса порядковый номер увеличивается на число переданных байт. Такое отслеживание байтов данных позволяет однозначно определять и подтверждать каждый сегмент. Можно выяснить, какие сегменты отсутствуют.

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

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

Подтверждение получения сегментов

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

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

Источнику сообщается, что узел назначения получил все данные в этом потоке до того байта (но не включая его), который обозначен номером ACK. Предполагается, что передающий узел отправит сегмент, в котором используется порядковый номер, равный номеру ACK.

Необходимо помнить, что каждое соединение фактически представляет собой два односторонних сеанса. Обмен номерами SEQ и ACK осуществляется в обоих направлениях.

В примере, показанном на рисунке, узел слева отправляет данные узлу справа. Он отправляет сегмент, который содержит 10 байт данных для этого сеанса, и порядковый номер, равный 1, в заголовке.

Получающий узел принимает сегмент на 4-м уровне и определяет, что порядковый номер равен 1, а также то, что сегмент содержит 10 байт данных. Затем узел отправляет сегмент обратно узлу слева, чтобы подтвердить получение этих данных. В этом сегменте узел устанавливает 11 в качестве номера ACK, чтобы показать, что в этом сеансе следующим байтом данных он ожидает получить байт с номером 11. Когда передающий узел получает это подтверждение, он может отправить следующий сегмент, содержащий данные для этого сеанса, которые начинаются с байта номер 11.

Из этого примера видно, что если бы отправляющему узлу пришлось ждать подтверждения каждых 10 байт, это создало бы значительную нагрузку на сеть. Чтобы снизить нагрузку, связанную с получением этих подтверждений, несколько сегментов данных можно отправить и подтвердить в одном сообщении TCP, отправленном в противоположном направлении. Это подтверждение содержит номер ACK, который указывается исходя из общего количества байтов, полученных в течение сеанса связи. Например, начиная с порядкового номера 2000 (если было получено 10 сегментов из каждых 1000 байт) источнику должен быть отправлен ACK с номером 12001.

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

Обработка потерь сегментов

Как бы хорошо ни была организована сеть, в ней время от времени случаются потери данных; по этой причине протокол TCP предусматривает способы управления этими потерями сегментов. Среди них — механизм для повторной передачи сегментов с неподтвержденными данными.

Сервис узла назначения, использующая протокол TCP, обычно подтверждает только данные, поступившие в непрерывной последовательности. В случае отсутствия одного или нескольких сегментов подтверждаются только данные в первой непрерывной последовательности байтов. Например, если были получены сегменты с порядковыми номерами от 1500 до 3000 и от 3400 до 3500, номером ACK будет 3001. Это связано с тем, что имеются сегменты с номерами SEQ от 3001 до 3399, которые не были получены.

Если TCP на узле источника не получит подтверждение по истечении установленного периода времени, он вернется к последнему полученному номеру ACK и повторно перешлёт данные из этой точки. Процесс повторной передачи не указывается в запросе комментариев (RFC), а оставляется до момента конкретной реализации протокола TCP.

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

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

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

Управление потоком

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

Для управления потоком TCP в первую очередь определяет количество сегментов данных, которое может принять устройство назначения. Заголовок TCP включает в себя 16-битное поле, которое называется размером окна. Это количество байтов, которое устройство назначения сеанса TCP способно принять и обработать единовременно. Исходный размер окна согласовывается во время запуска сеанса через трёхстороннее рукопожатие между устройствами источника и назначения. После согласования исходное устройство должно ограничить количество сегментов данных, отправленных устройству назначения, в соответствии с размером окна. Только после того как исходное устройство получит подтверждение того, что сегменты данных получены, оно может продолжить отправку остальных данных в этом сеансе.

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

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

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

Уменьшение размера окна

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

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

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

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

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

Протокол TCP

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

Открытое TCP-соединение с трехсторонним квитированием

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

Рис. 6.2.1 Соединение с трехсторонним квитированием

Процесс синхронизации требует, чтобы каждая сторона послала свой номер ISN и получила подтверждение и ISN от другой стороны соединения. Каждая сторона должна принимать ISN от другой стороны и посылать положительное подтверждение (АСК) в определенном порядке, который описан в следующей последовательности шагов.

  1. А > В SYN — мой порядковый номер X.
  2. А < В АСК — твой порядковый номер X.
  3. А < В SYN — мой порядковый номер Y.
  4. А > В АСК — твой порядковый номер Y.

Простое подтверждение и работа с окнами в протоколе TCP

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

Скользящие окна в протоколе TCP

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

Порядковые номера и номера подтверждений в протоколе TCP

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

HackWare.ru

Этичный хакинг и тестирование на проникновение, информационная безопасность

Транспортные протоколы TCP и UDP

Оглавление: Компьютерные сети

6. Канальный уровень передачи данных

7. Маршрутизация данных

8. Служебный протокол ICMP

10. Настройка сетевых подключений в командной строке Linux

11. Определение проблем работы сети

12. Туннелизация

Сходства и различия TCP и UDP

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

Каждый сетевой пакет обоих протоколов TCP и UDP состоит из двух частей:

  • заголовок
  • непосредственно данные

В заголовке содержится «служебная информация» (можно сказать, что это метаданные) — порты пункта назначения и исходного узла, номер пакета в потоке, тип пакета и так далее.

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

Может возникнуть вопрос, зачем вообще нужен такой ненадёжный протокол UDP, если есть надёжный протокол TCP? Платой за надёжность протокола TCP является то, что в бухгалтерии называется «накладные расходы» (overheads) — суть в том, что для обеспечения механизма контроля доставки пакетов в протоколе TCP отправляется много данных, которые не содержат полезной информации, а служат только для установки и контроля соединения. К примеру, чтобы отправить хотя бы одни пакет с полезными данными в TCP нужно завершить трёхступенчатое рукопожатие, которое заключается в отправке 1 особого пакета от источника к пункту назначения, получения 1 пакета о возможности установить соединения и отправки ещё 1 специального пакета от источника с подтверждением, что всё готово к отправке — за это время с помощью протокола UDP можно было бы отправить уже несколько пакетов с полезными данными.

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

Детальное понимание TCP и UDP имеет значение при:

  • анализе сетевого трафика
  • настройке сетевого файервола iptables
  • понимания и защиты от DoS атак некоторого вида.

К примеру, понимая механизм TCP подключения, можно настроить файлервол (iptables) так, что будут запрещены все новые подключения с сохранением существующих, либо запретить любые входящие подключения с полным разрешением исходящих, понимать и предотвращать ряд DoS атак, понимать SYN и другие виды сканирований — почему они возможны и каков их механизм и т.д..

Протокол TCP

Transmission Control Protocol (TCP, протокол управления передачей) — один из основных протоколов передачи данных интернета, предназначен для управления передачей данных.

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

TCP широко используется во многих интернет-приложениях, включая World Wide Web (WWW), электронную почту, протокол передачи файлов, Secure Shell, одноранговый обмен файлами и потоковое мультимедиа.

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

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

Алгоритм работы TCP следующий:

  1. Устанавливается трёхэтапное рукопожатие между двумя узлами. На этом этапе узлы согласуют два числа — начальные номера первого пакета для каждого из узлов.
  2. При отправке пакетов узлы последовательно номеруют их, то есть каждому сетевому пакету присвоен один из последовательных номеров.
  3. В дополнении к номеру, для каждого пакета рассчитывается контрольная сумма. Получив пакет, вновь рассчитывается контрольная сумма для полученных данных — если она не совпадает, значит пакет был повреждён при передаче.
  4. Итак, поскольку все пакеты имеют последовательные номера, то становится видно если какие-то из них отсутствуют. В этом случае отправляется запрос на повторную отправку пакета.
  5. Если для какого-то пакета не совпала контрольная сумма, то отправляется запрос на повторную отправку пакета.

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

Всё это возможно с помощью заголовков TCP пакета.

Что такое 1 соединение TCP

Прежде чем изучить структуру заголовка TCP пакета, разберёмся, что такое 1 TCP соединение — это поможет яснее понимать, что именно мы анализируем в Wireshark и сколько TCP соединений нам нужно искать. К примеру, сколько TCP соединений задействуется при открытии 1 страницы веб-сайта? Типичный веб-сайт состоит из 1 страницы HTML кода, нескольких страниц каскадных таблиц стилей CSS и JavaScript файлов, а также пары десятков файлов изображений. Так вот, для получения каждого из этих файлов создаётся новое TCP соединеие. Для каждого из этих соединений выполняется трёхэтапное рукопожатие — это к вопросу о том, какие издержки, «накладные расходы» несёт в себе TCP.

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

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

Заголовок TCP

  • Порт источника — биты 0-15. Это порт источника пакета. Исходный порт изначально был связан напрямую с процессом в отправляющей системе. Сегодня мы используем хеш между IP-адресами и портами назначения и порта источника для достижения этой уникальности, которую мы можем привязать к одному приложению или программе.
  • Порт назначения — биты 16-31. Это порт назначения пакета TCP. Как и в случае с портом-источником, он изначально был напрямую связан с процессом в принимающей системе. Сегодня вместо этого используется хеш, который позволяет нам иметь больше открытых соединений одновременно. Когда пакет получен, порты назначения и исходные порты возвращаются в ответе обратно к первоначально отправляющему хосту, так что порт назначения теперь является портом источника, а порт источника является портом назначения.

Порт источника и порт назначения не обязаны быть одинаковыми: к примеру, если делается запрос к 80-му порту сервера, то этот запрос может прийти, например, с порта 34054.

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

  • Порядковый номер (Sequence number) — биты 32-63. Поле порядкового номера используется для установки номера в каждом TCP-пакете, чтобы можно было правильно упорядочить поток TCP (например, пакеты приводятся к правильному порядку). Затем в поле ACK возвращается порядковый номер, чтобы подтвердить, что пакет был принят правильно.

Указывает на количество переданных байт, и каждый переданный байт полезных данных (payload) увеличивает это значение на 1.

Если установлен флаг SYN (идёт установление сессии), то поле содержит изначальный порядковый номер — ISN (Initial Sequence Number). В целях безопасности это значение генерируется случайным образом и может быть равно от 0 до 2 32 -1 (4294967295). Первый байт полезных данных в устанавливающейся сессии будет иметь номер ISN+1.

В противном случае, если SYN не установлен, первый байт данных, передаваемый в данном пакете, имеет этот порядковый номер.

  • Номер подтверждения (Acknowledgment Number (ACK SN)) — биты 64-95. Это поле используется, когда мы подтверждаем определённый пакет, полученный хостом. Например, мы получаем пакет с одним установленным порядковым номером, и если с пакетом все в порядке, мы отвечаем пакетом ACK с номером подтверждения, равным оригинальному порядковому номеру.

Если установлен флаг ACK, то это поле содержит порядковый номер октета, который отправитель данного сегмента желает получить. Это означает, что все предыдущие октеты (с номерами от ISN+1 до ACK-1 включительно) были успешно получены.

Каждая сторона подсчитывает свой Sequence number для переданных данных и отдельно Acknowledgement number для полученных данных. Соответственно Sequence number каждой из сторон соответствует Acknowledgement number другой стороны.

  • Длина заголовка (смещение данных) — биты 96-99. В этом поле указывается длина заголовка TCP пакета и где начинаются фактические данные (полезная нагрузка). Поле имеет размер в 4 бита и указывает заголовок TCP в 32-битных словах. Заголовок должен всегда заканчиваться чётной 32-битной границей, даже с различными установленными опциями (опции могут отсутствовать вовсе, либо их количество может различаться). Это возможно благодаря полю Padding в самом конце заголовка TCP.

Минимальный размер заголовка составляет 5 слов, а максимальный — 15 слов, что даёт минимальный размер 20 байтов и максимум 60 байтов, что позволяет использовать до 40 байтов опций в заголовке. Это поле получило такое имя (смещение данных) из-за того, что оно также показывает расположение фактических данных от начала сегмента TCP.

Итак, длина заголовка определяет смещение полезных данных относительно начала сегмента. Например, Data offset равное 1111 говорит о том, что заголовок занимает пятнадцать 32-битных слова (15 строк*32 бита в каждой строке/8 бит = 60 байт).

  • Зарезервировано — биты 100-102. Эти биты зарезервированы для будущего использования.
  • Флаги (управляющие биты)
  • NS — бит 103. ECN-nonce — concealment protection
  • CWR (Congestion Window Reduced) — бит 104. Поле «Окно перегрузки уменьшено» — флаг установлен отправителем, чтобы указать, что получен пакет с установленным флагом ECE
  • ECE — бит 105. ECE (ECN-Echo) — Поле «Эхо ECN» — указывает, что данный узел способен на ECN (явное уведомление перегрузки) и для указания отправителю о перегрузках в сети (RFC 3168)
  • URG — бит 106. Поле «Указатель важности» задействовано. Если установлено значение 0, не используется Urgent Pointer, если установлено значение 1, то используется Urgent Pointer.
  • ACK — бит 107. Этот бит устанавливается для пакета, чтобы указать, что это ответ на другой полученный нами пакет, содержащий данные. Пакет подтверждения всегда отправляется, чтобы указать, что мы фактически получили пакет, и что он не содержит ошибок. Если этот бит установлен, исходный отправитель данных проверит номер подтверждения, чтобы увидеть, какой пакет фактически подтверждён, а затем выгрузит его из буферов.
  • PSH — бит 108. Флаг PUSH используется для указания протоколу TCP на любых промежуточных хостах отправлять данные фактическому пользователю, включая реализацию TCP на принимающем хосте. Это протолкнёт все данные, независимо от того, где и сколько из окна TCP было уже передано.
  • RST — бит 109. Флаг RESET установлен, чтобы сообщить другому концу разорвать TCP-соединение. Это делается в нескольких различных сценариях, основными причинами которых является то, что соединение по какой-то причине разорвалось, если соединение не существует или если пакет каким-то образом неправильный.
  • SYN — бит 110. SYN (или синхронизация номеров последовательности) используется во время первоначального установления соединения. Он устанавливается в двух экземплярах соединения: начальный пакет, который открывает соединение, и ответный пакет SYN/ACK. Он никогда не должен использоваться за пределами этих случаев.
  • FIN — бит 111. Бит FIN указывает, что у хоста, который отправил бит FIN, больше нет данных для отправки. Когда другой конец увидит бит FIN, он ответит FIN/ACK. Как только это будет сделано, хост, который первоначально отправил бит FIN, больше не сможет отправлять какие-либо данные. Однако другой конец может продолжать отправлять данные до тех пор, пока они не будет завершаться, и затем отправит пакет FIN обратно и дождётся окончательного FIN/ACK, после чего соединение отправляется в состояние CLOSED.
  • Размер окна (Window Size) — биты 112-127. Window Size определяет количество байт данных (payload), после передачи которых отправитель ожидает подтверждения от получателя, что данные получены. Иначе говоря, получатель пакета располагает для приёма данных буфером длиной «размер окна» байт.

По умолчанию размер окна измеряется в байтах, поэтому ограничен 2 16 (65535) байтами. Однако благодаря TCP опции Window scale option этот размер может быть увеличен до 1 Гбайта. Чтобы задействовать эту опцию, обе стороны должны согласовать это в своих SYN сегментах.

  • Контрольная сумма — биты 128-143. Поле контрольной суммы — это 16-битное дополнение к сумме всех 16-битных слов заголовка (включая псевдозаголовок) и данных. Если сегмент, по которому вычисляется контрольная сумма, имеет длину не кратную 16-битам, то длина сегмента увеличивается до кратной 16-ти, за счёт дополнения к нему справа нулевых битов заполнения. Биты заполнения (0) не передаются в сообщении и служат только для расчёта контрольной суммы. При расчёте контрольной суммы значение самого поля контрольной суммы принимается равным 0.
  • Указатель важности (Urgent pointer) — биты 144-159. 16-битовое значение положительного смещения от порядкового номера в данном сегменте. Это поле указывает порядковый номер октета, которым заканчиваются важные (urgent) данные. Поле принимается во внимание только для пакетов с установленным флагом URG. Используется для внеполосных данных.
  • Опции — биты 160-**. Могут применяться в некоторых случаях для расширения протокола. Иногда используются для тестирования. На данный момент в опции практически всегда включают 2 байта NOP (в данном случае 0x01) и 10 байт, задающих timestamps. Вычислить длину поля опции можно через значение поля смещения.

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

  • Заполнение (Padding) — биты**. Поле Заполнение дополняет заголовок TCP, пока весь заголовок не закончится на 32-разрядной границе. Это гарантирует, что часть данных пакета начинается с 32-разрядной границы, и данные в пакете не теряются. Заполнение всегда состоит только из нулей.

Сессия TCP

Рукопожатие TCP (установление подключения TCP)

Для установления соединения TCP использует трёхэтапное рукопожатие.

Подключение можно выполнить только если вторая сторона прослушивает порт, к которому будет выполняться подключение: к примеру, веб-сервер прослушивает порты 80 и 443. То есть это не охватывается рукопожатием, но прежде чем клиент попытается соединиться с сервером, сервер должен сначала подключиться к порту и начать прослушивать его, чтобы открыть его для соединений: это называется пассивным открытием. Как только пассивное открытие установлено, клиент может инициировать активное открытие. Для установления соединения происходит трёхэтапное (или трёхступенчатое) рукопожатие:

Первый этап, отправка пакета с включённым флагом SYN: активное открытие выполняется клиентом, отправляющим SYN на сервер. Клиент устанавливает порядковый номер сегмента на случайное значение A.

Обратите внимание, что по умолчанию Wireshark показывает относительное значение порядкового номера (Sequence number), чуть ниже вы также можете видеть реальное значение (показано как raw).

Второй этап, отправка пакета с включённым флагом SYN-ACK: В ответ сервер отвечает SYN-ACK. Номер подтверждения установлен на единицу больше принятого Порядкового номера (Sequence number), то есть A+1. Поскольку сервер также будет отправлять данные, то для себя он тоже выбирает Порядковый номер (Sequence number) первого пакета с данными, который будет другим случайным числом B.

Третий этап, отправка пакета с включённым флагом ACK: наконец, клиент отправляет ACK обратно на сервер. Порядковый номер устанавливается равным полученному значению подтверждения, то есть A+1, а номер подтверждения устанавливается на единицу больше, чем принятый порядковый номер, то есть B+1.

На этом этапе и клиент, и сервер получили подтверждение соединения. Шаги 1, 2 устанавливают параметр соединения (порядковый номер) для одного направления, и оно подтверждается. Шаги 2, 3 устанавливают параметр соединения (порядковый номер) для другого направления, и он подтверждается. Таким образом устанавливается полнодуплексная (двухсторонняя) связь.

Передача данных в TCP

PSH-ACK: Клиент отправляет запрос к серверу по HTTP протоколу, поскольку данные поместились в один сетевой пакет TCP, то он имеет флаг PSH, чтобы сервер не ждал продолжение получения данных, а отправил их веб-серверу для выполнения.

ACK: В ответ на принятую информацию сервер отправляет пакет ACK с номером успешно полученных данных.

PSH-ACK: Сервер обработал запрос и отправляет данные — веб страницу

ACK: клиент подтверждает, что данные получены

На последнем скриншоте:

1 — установка соединения

2 — передача данных

3 — завершение соединения

Завершение соединения

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

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

Также возможно разорвать соединение трёхэтапным рукопожатием, когда хост A отправляет FIN, а хост B отвечает FIN&ACK (просто объединяет 2 шага в один), а хост A отвечает ACK.

Некоторые операционные системы, такие как Linux и H-UX, реализуют полудуплексную последовательность закрытия в стеке TCP. Если хост активно закрывает соединение, но при этом остаются непрочитанными входящие данные, хост отправляет сигнал RST (потеря всех полученных данных) вместо FIN. Это гарантирует приложению TCP, что удалённый процесс прочитал все переданные данные, ожидая сигнала FIN, прежде чем он активно закроет соединение. Удалённый процесс не может различить сигнал RST для прерывания соединения и потери данных. Оба вызывают удалённый стек, чтобы потерять все полученные данные.

Как можно увидеть на скриншоте, завершение TCP соединения также происходит как (Linux с последним ядром):

Клиент: FIN-ACK

Сервер: FIN-ACK

Клиент: ACK

Состояния клиента и сервера

Состояния сеанса TCP
CLOSED Начальное состояние узла. Фактически фиктивное
LISTEN Сервер ожидает запросов установления соединения от клиента
SYN-SENT Клиент отправил запрос серверу на установление соединения и ожидает ответа
SYN-RECEIVED Сервер получил запрос на соединение, отправил ответный запрос и ожидает подтверждения
ESTABLISHED Соединение установлено, идёт передача данных
FIN-WAIT-1 Одна из сторон (назовём её узел-1) завершает соединение, отправив сегмент с флагом FIN
CLOSE-WAIT Другая сторона (узел-2) переходит в это состояние, отправив, в свою очередь сегмент ACK и продолжает одностороннюю передачу
FIN-WAIT-2 Узел-1 получает ACK, продолжает чтение и ждёт получения сегмента с флагом FIN
LAST-ACK Узел-2 заканчивает передачу и отправляет сегмент с флагом FIN
TIME-WAIT Узел-1 получил сегмент с флагом FIN, отправил сегмент с флагом ACK и ждёт 2*MSL секунд, перед окончательным закрытием соединения
CLOSING Обе стороны инициировали закрытие соединения одновременно: после отправки сегмента с флагом FIN узел-1 также получает сегмент FIN, отправляет ACK и находится в ожидании сегмента ACK (подтверждения на свой запрос о разъединении)

Описание данных состояний позволяет лучше понимать информацию, которую показывают программы о состоянии сети, такие как netstat и ss (смотрите также «Как проверить открытые порты на своём компьютере. Что означают 0.0.0.0, :*, [::], 127.0.0.1. Как понять вывод NETSTAT»).

Фильтры Wireshark для TCP

Чтобы увидеть только трафик TCP:

Показать трафик, источником или портом назначения которого является определённый порт, например 8080:

tcp.port==8080

Показать трафик, источником которого является порт 80:

tcp.srcport == 80

Показать трафик, который отправляется службе, прослушивающей порт 80:

tcp.dstport == 80

Показать TCP пакеты с включённым флагом SYN:

tcp.flags.syn==1

Показать TCP пакеты с включённым флагом SYN и отключённым флагом ACK:

tcp.flags.syn==1 && tcp.flags.ack==0

Аналогично и для других флагов:

tcp.flags.syn==1
tcp.flags.ack==1
tcp.flags.reset==1
tcp.flags.fin==1
tcp.flags.cwr==1
tcp.flags.ecn==1
tcp.flags.urg==1
tcp.flags.push==1
tcp.flags.ns==1

Также можно использовать синтаксис вида tcp.flags == 0x0XX, например:

  • FIN это tcp.flags == 0x001
  • SYN это tcp.flags == 0x002
  • RST это tcp.flags == 0x004
  • ACK это tcp.flags == 0x010
  • Установленные одновременно ACK и FIN это tcp.flags == 0x011
  • Установленные одновременно ACK и SYN это tcp.flags == 0x012
  • Установленные одновременно ACK и RST это tcp.flags == 0x014

Длина заголовка (смещение данных):

tcp.hdr_len == 32 tcp.hdr_len == 52 tcp.hdr_len > 32

Пакеты с установленными зарезервированными битами:

tcp.flags.res == 1
tcp.window_size_value == 11 tcp.window_size_value == 4468 tcp.window_size_value > 65000 tcp.window_size_value < 100

Вычесленный размер окна:

tcp.window_size == 45056 tcp.window_size == 11

Фактор масштабирования размера окна:

tcp.window_size_scalefactor == 4096

tcp.window_size_value — это необработанное значение размера окна, считываемое непосредственно из заголовка TCP, тогда как tcp.window_size — это вычисленный размер окна, который основан на том, применимо ли масштабирование окна или нет. Если масштабирование окна не используется или коэффициент масштабирования равен 1 или неизвестно, применимо ли масштабирование окна или нет, потому что трёхэтапное рукопожатие TCP не было захвачено, тогда эти два значения будут одинаковыми. С помощью tcp.window_size_scalefactor вы можете определить, какое из этих условий применимо — если его значение равно -1, то оно неизвестно, если его значение равно -2, тогда масштабирование окна не используется, а все остальные значения представляют фактический размер фактора масштабирования окна.

Чтобы показать пакеты, содержащие какую либо строку, например, строку hackware:

tcp contains hackware

Следовать потоку TCP с номером X:

tcp.stream eq X

Фильтровать по номеру потока:

tcp.seq == x

Показать повторные отправки пакетов. Помогает прослеживать замедление производительности приложений и потери пакетов:

tcp.analysis.retransmission

Этот фильтр выведен проблемные пакеты (потерянные сегменты, повторную отправку и другие. Этот фильтр проходят пакеты TCP Keep-Alive, но они не являются показателем проблем.

tcp.analysis.flags

Фильтры для оценки качества сетевого подключения.

Следующие характеристики относятся к TCP фреймам. Причём они не основываются на заголовках фрейма — рассматриваемые характеристики (пропуск данных, дубли) присвоены программой Wireshark исходя из анализа.

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

tcp.analysis.duplicate_ack_num == 1

Фильтр показа фреймов для которых не захвачен предыдущий сегмент:

tcp.analysis.ack_lost_segment

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

Для показа фреймов, которые являются ретрансмиссией (отправляются повторно):

tcp.analysis.retransmission

Вывод фреймов, которые получены не в правильном порядке:

tcp.analysis.out_of_order

Виды сканирований Nmap

Мы рассмотрели механизм рукопожатия TCP, напомним его структуру:

Знаменитый сканер портов Nmap по умолчанию выполняет сканирования с использованием полуотрытых соединений, или его ещё называют SYN сканированием. На самом деле, это не что иное, как отправленный пакет с включённым флагом SYN — то есть Nmap инициирует рукопожатие TCP. Если в ответ приходит пакет с флагами SYN-ACK (то есть удалённый хост отправляет свою часть рукопожатия), то это означает, что порт открыт. Если удалённый хост отвечает пакетом с флагом RST-ACK, то это означает, что порт закрыт.

Такой метод, с одной стороны, является универсальным — любой открытый порт обязательно должен ответить пакетом с флагами SYN-ACK, поскольку это стандарт транспортного протокола TCP. Но при этом Nmap не завершает рукопожатие, то есть не создаётся полноценное соединение и приложение, которое прослушивает просканированный порт, никогда не узнает об этом неудачном TCP рукопожатии, и этот факт не отобразиться в журналах этого приложения.

Пример сканирования портов:

sudo nmap -p 70-90 185.117.153.79

На следующем скриншоте мы можем видеть отправленные и полученные пакеты:

Первая группа пакетов (выделена прямоугольником) — пинг хоста, чтобы определить, доступен ли он. Также на этапе доступности хоста делается запрос к портам 80 и 443 (хотя порт 443 не указан для сканирования), видимо, также для подтверждения того, что хост онлайн.

Если от порта получен пакет SYN-ACK (сервер готов к установке соединения), то Nmap отвечает пакетом с флагом RST для обрыва начатого рукопожатия.

Вторая группа — они отмечены серым и зелёным — это непосредственно сканирование портов — это пакеты с флагом SYN. Серым отмечены те, которые прислали ответ RST-ACK (порт закрыт), а зелёным т е, которые прислали ответ SYN-ACK (порт открыт).

Пакеты RST-ACK, а также пакеты RST (от Nmap) помечены красным.

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

Кроме этого метода, Nmap поддерживает ещё несколько типов сканирования:

-sS/sT/sA/sW/sM: TCP SYN/с использованием системного вызова Connect()/ACK/Window/Maimon сканирования -sU: UDP сканирование -sN/sF/sX: TCP Null, FIN и Xmas сканирования --scanflags : Задать собственные TCP флаги

Если вы хотите узнать об этих опциях и типах сканирвоания подробнее, то рекомендуется изучить их на справочной странице Nmap: https://kali.tools/?p=1317

Теперь, когда понятна суть сканирований портов, можно предложить меры по защите сервера от сканирований. Если ваш сервер предназначен принимать входящие соединения (например, это веб сервер с SSH), то на 100% защититься от сканирований портов нельзя, поскольку для полуоткрытых соединений используются «легальные» TCP пакеты с флагом SYN, которые являются первой частью рукопожатий. Тем не менее в iptables или fail2ban можно настроить примерно такое правило: «если от одного удалённого хоста поступило более 10 SYN пакетов за указанный промежуток времени, то отклонять его последующие попытки подключения». Это затруднит или даже сделает невозможным массовое сканирование портов на вашем сервере.

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

Примеры iptables

[БУДЕТ ДОБАВЛЕНО ПОЗЖЕ]

Протокол UDP

Если вы смогли разобраться с TCP и его заголовками, то с UDP вам будет совсем просто.

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

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

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

Что такое 1 соединение UDP

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

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

Тем не менее при открытом UDP порте состояние сервера становится LISTEN (сервер ожидает запросов установления соединения от клиента). Также UDP соединение может иметь статус UCONN или ESTAB.

Как можно увидеть, UDP пакет отправлен с порта 42044:

Ответный UDP пакет также пришёл на порт 42044:

Если сравнить с TCP, то минимальное количество пакетов для отправки запроса и получения информации — 10, а для UDP минимальное количество пакетов для отправки запроса и получения информации — 2.

Заголовок UDP

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

Как и с протоколом TCP — для сервера обычно используется один из стандартных портов (например, порт 53 для DNS серверов), а порт источника выбирается произвольно для каждого соединения, обычно это номера портов с большим номером (десятки тысяч).

  • Длина — биты 32-47. Поле длины указывает длину всего пакета в октетах, включая заголовок и части данных. Самый короткий возможный пакет может быть длиной 8 октетов.

Поле, задающее длину всей датаграммы (заголовка и данных) в байтах. Минимальная длина равна длине заголовка — 8 байт. Теоретически, максимальный размер поля — 65535 байт для UDP-датаграммы (8 байт на заголовок и 65527 на данные). Фактический предел для длины данных при использовании IPv4 — 65507 (помимо 8 байт на UDP-заголовок требуется ещё 20 на IP-заголовок).

  • Контрольная сумма — биты 48-63. Контрольная сумма — это та же контрольная сумма, что и в заголовке TCP, за исключением того, что она содержит другой набор данных. Другими словами, это дополнение к сумме дополнительных частей заголовка IP, всего заголовка UDP, данных UDP и дополнения нулями в конце, когда это необходимо.

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

Фильтры Wireshark для UDP

Чтобы увидеть только трафик UDP:

Для UDP не используются флаги. Для этого протокола можно только указать порт.

Показать трафик, источником которого является порт 53:

udp.srcport == 53

Показать трафик, который отправляется службе, прослушивающей порт 53:

udp.dstport == 53

UDP пакет, в котором встречается определённая строка, например, строка hackware:

udp contains hackware

Порт назначения ИЛИ исходный порт:

udp.port == 53 udp.port > 40000 udp.port < 30
udp.length == 60 udp.length > 50000

Время между пакетами (для выявления проблем сети):

udp.time_delta > 1.5

Номер потока (запрос-ответ):

udp.stream == 5
udp.possible_traceroute

Сравнение UDP и TCP

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

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

UDP — более простой, основанный на сообщениях протокол без установления соединения. Протоколы такого типа не устанавливают выделенного соединения между двумя хостами. Связь достигается путём передачи информации в одном направлении от источника к получателю без проверки готовности или состояния получателя. В приложениях для голосовой связи через интернет-протокол (Voice over IP, TCP/IP) UDP имеет преимущество над TCP, в котором любое «рукопожатие» помешало бы хорошей голосовой связи. В VoIP считается, что конечные пользователи в реальном времени предоставят любое необходимое подтверждение о получении сообщения.

  • Ненадёжный — когда сообщение посылается, неизвестно, достигнет ли оно своего назначения — оно может потеряться по пути. Нет таких понятий, как подтверждение, повторная передача, тайм-аут.
  • Неупорядоченность — если два сообщения отправлены одному получателю, то порядок их достижения цели не может быть предугадан.
  • Легковесность — никакого упорядочивания сообщений, никакого отслеживания соединений и т. д. Это небольшой транспортный уровень, разработанный на IP.
  • Датаграммы — пакеты посылаются по отдельности и проверяются на целостность только если они прибыли. Пакеты имеют определенные границы, которые соблюдаются после получения, то есть операция чтения на сокете-получателе выдаст сообщение таким, каким оно было изначально послано.
  • Нет контроля перегрузок — UDP сам по себе не избегает перегрузок. Для приложений с большой пропускной способностью возможно вызвать коллапс перегрузок, если только они не реализуют меры контроля на прикладном уровне.
  • Широковещательные рассылки (Broadcasts) — при отсутствии соединения, UDP может делать широковещательные рассылки — отправленные пакеты могут быть адресованы для приёма всеми устройствами в подсети.
  • Многоадресная рассылка (Multicast) — поддерживается многоадресный режим работы, при котором один пакет дейтаграмм может быть автоматически направлен без дублирования группе подписчиков.

Связанные статьи:

  • Как проверить открытые порты на своём компьютере. Что означают 0.0.0.0, :*, [::], 127.0.0.1. Как понять вывод NETSTAT (81.5%)
  • Как работают компьютерные сети (78.8%)
  • Введение в IPv6 адреса: как пользоваться и как исследовать сеть (часть 2) (68.5%)
  • NetBIOS: что это, как работает и как проверить (63.8%)
  • VNC в Windows и Linux: настройка и аудит безопасности (63.8%)
  • Всё о RDP: от настройки до взлома (RANDOM - 52.9%)

факультете информационной безопасности от GeekBrains? Комплексная годовая программа практического обучения с охватом всех основных тем, а также с дополнительными курсами в подарок. По итогам обучения выдаётся свидетельство установленного образца и сертификат. По этой ссылке специальная скидка на любые факультеты и курсы!

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *