Сколько пакетов будет отправлено tcp соединения. Разбираем по косточкам компьютерные сети: HTTP, TCP, REST. Как передается сообщение

Формат заголовка TCP

Сегменты протокола TCP состоят из заголовка и блока данных.

Рис. 1.41. Формат заголовка сегмента TCP

Заголовок сегмента имеет следующие поля:

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

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

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

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

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

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

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

URG – признак наличия срочных (внеполосных) данных.

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

Примечание:

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

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

Примечание:

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

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

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

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

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

Для всех состояний, кроме SYN_SENT (см. ниже), все сегменты с сигналом перезагрузки (RST) проходят проверку полей номера последовательности SEQ. Сигнал перезагрузки признается, если его номер очереди попадает в окно приема. В состоянии же SYN_SENT (сигнал RST получен в ответ на посылку инициирующего сигнала SYN), сигнал RST признается, если поле ACK подтверждает ранее сделанную посылку сигнала SYN. Получатель сигнала RST вначале проверяет его, и лишь потом меняет свое состояние. Если получатель (сервер) находился в состоянии LISTEN, то он игнорирует сигнал. Если получатель находился в состоянии SYN_RECEIVED, то он возвращается вновь в состояние LISTEN. В иных случаях получатель ликвидирует соединение и переходит в состояние CLOSED. Если получатель находится в каком-либо ином состоянии, то он ликвидирует соединение и прежде чем перейти в состояние CLOSED, оповещает об этом своего клиента. В общем случае сигнал "сброс" (reset) посылается модулем TCP в том случае, если прибывающие сегменты не принадлежат указанному соединению или когда запрос о соединении прибывает и при этом не существует процесса, который слушает порт назначения.

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

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

Примечание:

В одном сегменте может быть установлено более чем один из четырех флагов, однако обычно взведен бывает только один или два флага. В RFC-1025 сегмент, в котором максимальная комбинация всех доступных флагов «взведена» одновременно (SYN, URG, PSH, FIN и 1 байт данных), называется пакетом "Камикадзе" (в английском языке существует еще несколько определений подобного пакета, а именно - "грязный пакет", "пакет Новогодней елки" и т.п.).

Размер окна (WINDOW) занимает 2 байта, содержит объявляемое значение размера окна приема в байтах; Начальное значение этого поля является своеобразной константой, также как IP -TTL, характеризующей данную ОС. В некоторых случаях для однозначного определения типа ОС достаточно извлечь значение поля Window в TCP-заголовке принятого сегмента. Так, ОС AIX - единственная ОС, имеющая значение Window=0x3F25. Стек TCP/IP в ОС Windows типа NT5, как и OpenBSD и FreeBSD, имеет Window=0x402E;

Контрольная сумма (CHECKSUM) занимает 2 байта, рассчитывается по сегменту. Если сегмент содержит нечетное число байтов в заголовке/или тексте, последние байты дополняются справа 8 нулями для выравнивания по 16-битовой границе. Биты заполнения (0) не передаются в сегменте и служат только для расчета контрольной суммы. При расчете контрольной суммы значение самого поля контрольной суммы принимается равным 0;

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

Опции (OPTIONS) – это поле имеет переменную длину и может вообще отсутствовать; используется для решения вспомогательных задач, например, при объявлении максимального размера сегмента; опции разрешено слать только в SYN и ACK+SYN сегментах (более подробно об опциях TCP см. ниже.)

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

После заполнителя идут непосредственно байты данных сегмента.

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

На компьютере в сети обязательно должен быть установлен сетевой экран – файрволл (firewall), который отслеживает приходящие (incoming) SYN-сегменты и или оповещает пользователя, или просто отбрасывает их с соответствующей фиксацией в лог-файле. Тот же файрволл фиксирует и исходящие от ваших приложений SYN-сегменты (например, от броузера) и также оповещает пользователя, что "такая-то" программа требует выхода в Интернет. Это особенно важно для случая заражения хоста каким-либо вирусом, который пытается с вашего компьютера самостоятельно выйти в сеть, чтобы установить TCP-соединение с "вражеским" хостом – например, это может быть вирус-троян.

Тот факт, что TCP-сессия всегда начинается посылкой SYN-сегмента, привел к возникновению нового типа инициирования начала сессии с помощью посылки вместо первого SYN-сегмента ACK-сегмента – сетевые экраны (файрволлы) не препятствуют прохождению через них таких сегментов – ведь это просто служебная квитанция уже начатой легальной сессии – так они в общем-то справедливо считают. И если на одну TCP-сессию приходится всего два SYN-сегмента – туда и обратно, то ACK-сегментов может быть тысячи!

Опции в заголовке TCP

Заголовок TCP в поле опций может содержать дополнительные параметры соединения. Единственные параметры, определенные в первоначальной спецификации TCP RFC-793, это – конец списка опций, отсутствие операции (nop) и опция максимального размера сегмента MSS. Форматы наиболее часто применяемых опций приведены на рис.1.42.

Рис. 1.42. Формат основных опций TCP

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

Задача опции NOP "нет операции" состоит в том, чтобы позволить отправителю дополнять поля опций до величины, кратной 4 байтам. Например, если мы инициируем подключение TCP в системе 4.4BSD, программа tcpdump выводит следующие параметры TCP в начальном сегменте SYN:

Опция MSS

При установлении соединения каждая сторона может объявить MSS, который она собирается передавать. Опция MSS может быть использована только в SYN-сегменте. Если одна сторона не принимает опцию MSS от другой стороны, то используется размер по умолчанию в 536 байт, так как минимальный размер буфера для сборки пакетов (при фрагментации в IPv4) регламентирован размером 576 байт.

Опция масштабирования окна

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

1-байтовый сдвиговый счетчик находится в диапазоне от 0 (нет масштабирования) до 14. Максимальное значение равное 14 соответствует окну размером 1.073.725.440 байт (65535 * 2 14).

Эта опция может появиться только в сегменте SYN; таким образом, коэффициент масштабирования определяется в каждом направлении при установлении соединения. Чтобы включить масштабирование окна, оба конца должны активизировать опцию в своих сегментах SYN. Сторона, осуществляющая активное открытие, посылает опцию в своем SYN-сегменте, однако сторона, осуществляющая пассивное открытие, может послать опцию, только если эта опция установлена в полученном SYN-сегменте. Коэффициент масштабирования может быть различен для каждого направления.

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

Требования к хостам Host Requirements RFC требуют, чтобы TCP принимал эту опцию в любом сегменте. (Единственная заранее определенная опция, максимальный размер сегмента, может появиться только в сегментах SYN.) Также этот документ требует, чтобы модуль TCP игнорировал любые опции, которые он не понимает. Это легко осуществимо, так как все новые опции имеют поле длины.

Представьте, что мы используем опцию масштабирования окна со сдвиговым счетчиком равным S для отправки и со сдвиговым счетчиком равным R для приема. В этом случае каждые 16 бит объявленного окна, которые мы получаем от удаленного конца, сдвигаются влево на R бит, чтобы получить реальный размер объявленного окна. Каждый раз, когда мы отправляем объявление окна на удаленный конец, мы берем реальный 32-битный размер окна, сдвигаем его вправо на S бит и помещаем получившийся результат (16-битное значение) в TCP-заголовок.

Опция временной марки

Опция временной метки (timestamp) позволяет отправителю поместить значение временной метки в каждый сегмент. Получатель возвращает это значение в подтверждении, что позволяет отправителю рассчитать RTT (Round Trip Time, период обращения) при получении каждого ACK. (Мы должны сказать "каждый ACK", а не "каждый сегмент", так как многие реализации TCP обычно подтверждают несколько сегментов с помощью одного ACK.) Обычно большинство современных реализаций рассчитывают одно RTT на окно, что вполне достаточно, если окно содержит 8 сегментов. Однако в случае, если окно имеет большие размеры, требуется лучший расчет RTT.

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

Выборочное подтверждение (TCP Selective Acknowledgement - SACK, RFC-2018).

Выборочное подтверждение (SACK) - стратегия, призванная скорректировать некоторые недостатки кумулятивного подтверждения. С помощью выборочного подтверждения получатель данных может оповещать отправителя о любых сегментах, которые прибыли успешно, так что отправителю потребуется повторно передать только фактически утерянные сегменты. Эта идеология представляет собой модификацию предложений RFC-1072 и сравнительно недавно одобрена консорциумом IETF. Она позволяет подтверждать прием данных не в порядке их поступления, как это было раньше, а выборочно и уже применяется во многих транспортных протоколах: NETBLT, XTP, RDP, NADIR и VMTP.

Для выборочного подтверждения необходимо указание 2 опций:

Sack-Permitted (SACK разрешен). Двухбайтовая опция типа 4. Может быть послана только в SYN-сегменте.

Собственно опция SACK. Опция типа 5 переменной длины.

На рис.1.42 эти опции не показаны.

В операционной системе Windows эта опция появилась, начиная с версии Win98SE.

1. Внеполосные данные протокола TCP

Концепция внеполосных данных существует во многих протоколах транспортного уровня. Представим, что на другом конце соединения произошли некоторые события и о них надо срочно оповестить своего партнера по соединению. Вполне возможно, что к этому времени TCP-модуль уже занес в свой буфер передачи очередную порцию «обычных» данных. Можно было бы создать новое соединение (что в принципе и делается в «быстрых» сетях), но если соединение очень медленное, то более эффективно использовать уже существующее. Протокол TCP в таком случае использует флаг URG и срочный указатель Urgent Pointer, размещаемые в заголовке отправляемого сегмента, а сами «неотложные» данные размещаются в поле данных. О таких данных говорят, что они передаются вне потока – Out Of Band – OOB. Правда, в некоторых авторитетных источниках корректность этого названия подвергается сомнению – действительно, как мы увидим в разделе 2.9.1.1, такие данные могут быть размещены как "вне потока" обычных данных, так и внутри них. На наш взгляд, термин "внеполосные данные" следует заменить на более соответствующее истине название "срочные данные", а уж потом говорить о том, как они посылаются – вне потока или в нем.

Сегмент с установленным флагом URG посылается по соединению всегда, даже если поток передачи приостановлен. А вот сами «срочные» данные могут быть или отосланы, или нет, в зависимости от многих обстоятельств (места в буфере, количества уже отосланных данных и т.д.)

Сколько же байтов можно переслать в качестве неотложных? Пересылать то можно и несколько, но «настоящим» внеполосным байтом будет лишь один. Даже если мы запишем в параметре функции посылки данных несколько байт, то неотложным будет являться самый последний из них. Читателя, интересующегося этим вопросом более глубоко, мы отсылаем к фундаментальной книге У. Стивенса . Здесь только заметим, что внеполосные данные применяются немногими современными приложениями – это FTP, telnet и rlogin.

1. Как передается сообщение

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

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

Важно помнить о том, что количество номеров для очереди, хоть и велико, но ограничено. Диапазон номеров – от 0 до 2**32-1.

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

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

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

Если сообщение состоит из нескольких ТСР-сегментов (не путать с IР-пакетами), TCP-модуль на машине-получателе собирает его, исходя из порядковых номеров сегментов, хранящихся в заголовке. Если сегмент утерян или поврежден (последнее обнаруживается с помощью контрольной суммы в заголовке сегмента), отправителю посылается сообщение, содержащее порядковый номер ошибочного или потерянного сегмента. В этом случае отправитель повторно передает сегмент.

1. Таймеры TCP

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

Таймер повторной передачи

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

Таймер повторной передачи отмеряет время ожидания квитанции на отправленный сегмент (Retransmission TimeOut, RTO). Этот параметр устанавливается с учетом типа сети и скоростей доставки сообщений. Если квитанция не поступает вовремя, сегмент отправляется вновь, а период повторной передачи увеличивается по экспоненциальному закону. Так повторяется несколько раз, пока период повторной передачи не достигнет некоторого заданного предела, после чего обслужи-ваемому процессу выдает сообщение об ошибке.

Выбор времени ожидания (тайм-аута) очередной квитанции является важной задачей, результат решения которой влияет на производительность протокола TCP.

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

При выборе величины тайм-аута должны учитываться скорость и надежность физических линий связи, их протяженность и многие другие подобные факторы. В протоколе TCP тайм-аут определяется с помощью достаточно сложного адаптивного алгоритма. При установлении соединения засекается время от момента отправки сегмента до прихода квитанции о его приеме (так называемое время оборота – RTT, Round Trip Time), на основании которого формируется начальное значение RTO. При дальнейших передачах получаемые значения RTT усредняются с весовыми коэффициентами, возрастающими от предыдущего замера к последующему. Это делается для усиления влияния последних замеров. В качестве тайм-аута выбирается среднее время оборота, умноженное на некоторый коэффициент. Практика показывает, что значение этого коэффициента должно превышать 2. В сетях с большим разбросом времени оборота при выборе тайм-аута учитывается и дисперсия этой величины.

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

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

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

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

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

Таймер задержки

Получателю могут поступать сегменты и после того, как соединение было им закрыто. Таймер задержки (quiet timer) связан с состоянием ожидания TIME_WAIT (см. раздел 1.7.13), которое предоставляет защиту от опоздавших пакетов, принадлежащих ранним соединениям; при этом они не будут интерпретироваться как часть нового соединения, которое использует те же самые локальный и удаленный IP адреса и номера портов. Это состояние иногда называется состоянием 2MSL – удвоенное время жизни TCP-сегмента Maximum Segment Lifetime.

Следуя RFC-793, в котором MSL определен равным 2 мин., общее время TIME_WAIT составит 4 мин. На практике это обычно не так. Например, в системах, производных от BSD, MSL равно 30 сек., так что состояние TIME_WAIT длится всего 1 мин. Можно встретить и другие значения в диапазоне от 30 сек. до 2 мин. Если в то время, когда процесс находится в состоянии TIME_WAIT, прибывает новый сегмент, то его таймер 2MSL перезапускается.

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

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

Чтобы защититься от подобных нежелательных ситуаций, RFC-793 указывает, что модуль TCP не должен создавать новые соединения до истечения MSL с момента перезагрузки. Этот период называется "тихое время" (quiet time).

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

Длительность задержки обычно выбирают равной удвоенному значению максимального времени жизни сегмента (оно совпадает со значением поля времени жизни в заголовке IP-пакета). В ответ на каждый пришедший в этот период сегмент отправляется сообщение об ошибке.

Таймер запросов

Таймер запросов (persistence timer) предусмотрен для такого довольно редкого случая, когда получатель, приостановивший передачу данных путем посылки сегмента с нулевым размером окна, отправляет своему партнеру сообщение о возобновлении работы, но тот его не получает. Если подтверждения теряются, то это в принципе может привести к тупиковой ситуации, когда обе стороны будут дожидаться прихода подтверждений. В таком случае, чтобы продолжить передачу, отправитель с периодом, задаваемым таймером, посылает запросы с одним байтом данных. В ответ на них он получает сегменты, где указан размер окна партнера. Если размер окна нулевой, адресат по-прежнему занят, а если нет, то он готов принимать полезную информацию, после чего передача данных возобновляется. Период повторения запросов определяются таймером запросов. Обычно это 60 секунд. Он взводится в момент получения TCP-пакета с нулевым значением поля "Размер окна" в его заголовке (типичное начальное значение для этого таймера - 5 секунд.)

Таймер контроля и таймер разъединения

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

В архитектуре клиент-сервер довольно часто встречаются реализации, в которых клиент, отправив запрос на сервер, долгое время ожидает ответа сервера. Еще более актуальная ситуация - в реализациях TCP-сервера необходимо точно знать, сколько из соединившихся клиентов реально существуют. Многие из прикладных протоколов применяют для этого "пустую операцию" (NOP), которая время от времени производится между клиентом и сервером для проверки наличия соединения. Данный подход хорош тем, что он не зависит от реализации стека TCP/IP. Есть и другой метод – таймер контроля работоспособности (keep-alive).

Transporta un Sakaru Instit ūts , dabas zinātņu maģ ... - 2002 Baltijas Krievu instit ūts , lektore, docente. Transporta un sakaru instit ūts , lektore. SIA «L ...

Межсетевой протокол IP . Модуль IP является базовым элементом технологии Internet. Его центральной частью является таблица маршрутов. Таблица маршрутов заполняется администратором сети и обычно инициализируется в момент загрузки системы. Когда речь идет о простой локальной IP-сети, то протокол IP мало что добавляет к услугам Ethernet, за исключением того, что в сети будут работать все прикладные программы, реализованные для IP-технологии. Однако ситуация меняется, если речь идет о сетях, сопряженных шлюзом.

Протокол RIP (Routing Information Protocol) . Протокол предназначен для автоматического обновления таблицы маршрутов. При этом используется информация о состоянии сети, которая рассылается маршрутизаторами (routers). В соответствии с протоколом RIP любая машина может быть маршрутизатором. При этом все маршрутизаторы делятся на активные и пассивные. Активные маршрутизаторы сообщают о маршрутах, которые они поддерживают в сети. Пассивные маршрутизаторы читают эти широковещательные сообщения и исправляют свои таблицы маршрутов, но при этом сами информации в сеть не предоставляют. Обычно в качестве активных маршрутизаторов выступают шлюзы, а в качестве пассивных - обычные машины (hosts).

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

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

Прикладные программы взаимодействуют с модулем TCP также через порты. Существуют определенные стандартом номера портов, которые отведены под обслуживание стандартных сервисов Internet. Так telnet обслуживается через 23 порт, почта (SMTP) - через 25 и т.п.

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

Согласно протоколу TCP, поток байтов разбивается на пакеты. Любые данные для модуля TCP представляются в виде потока байтов. На другом конце виртуального канала данные снова собираются в поток. Модуль TCP не сохраняет разделения потоков данных на записи. Так можно записать в канал 5 записей по 80 байт, а прочитать одну в 400 байтов длиной

Подробное описание протокола tcp

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

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

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

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

Пользовательский интерфейс с TCP может выполнять такие команды как открыть (OPEN) или закрыть (CLOSE) соединение, отправить (SEND) или принять (RECEIVE) данные, или получить статус соединения (STATUS). Эти вызовы подобны любым другим вызовам функций операционной системы из пользовательской программы, таким как открытие, чтение или закрытие файла.

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

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

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

Логическая структура сетевого программного обеспечения, реализующего протоколы семейства TCP/IP в каждом узле сети Internet, изображена на рис. 2.12.

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

Рис. 2.12.Структура сетевого программного обеспечения семейства протоколов TCP/IP

 Потоки данных, стек протоколов, механизм гнезд и мультиплексирование соединений

 Процедура установления соединения и передача данных

 Механизмы обеспечения достоверности передаваемых данных

 Механизм контроля потока данных

 Флаг важности пакета, средства обеспечения безопасности протокола

Заголовок UDP всегда имеет длину 64 бита. Поля, определённые в сегменте UDP (см. рисунок) включают следующие:
1. Порт отправителя (Source port): номер порта источника(16 бит)
2. Порт получателя (Destination port): номер порта назначения (16 бит)
3. Длина сообщения (Length): длина заголовка UDP и данных UDP (16 бит)
4. Контрольная сумма (Checksum): вычисленная контрольная сумма полей заголовка и данных (16 бит)
5. Данные (Data): данные протокола вышележащего уровня (upper-layer protocol — ULP) (переменная длина)
Примеры протоколов, которые используют UDP: TFTP, SNMP, Network File System (NFS) и Domain Name System (DNS).

Заголовок 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)
(переменная длина)

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

Внимание! Этот материал рассчитан на тех, кого действительно интересуется вопросом: «Как устроена сеть, и что я могу сделать, если буду это знать». Если же тебя еще смущают слова вроде DNS, Telnet, Socket — то можешь сразу забить на этот материал — такие «страшные» слова тут конечно не встретятся, но от этого содержание понятней не станет…

Для тех кто остался:

Наверное, многие из вас слышали такие слова как SYN-flooding или IP-spoofing. Все это разновидности атак — первая D.O.S., вторая
состоит в подмене IP-адреса. На первый взгляд между этими примерами нет ничего общего, но между тем, это не так — обе эти атаки не возможны без глубокого знания протокола TCP, протокола на котором стоит
Inet.

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

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

Структура TCP-пакета:

Поясню только самые важные места:

Адрес получателя, порт получателя и адрес отправителя, порт отправителя — это надеюсь понятно.

Sequence Number(SYN) — номер очереди или последовательный номер, показывает порядковый номер пакета при передаче, именно поэтому принимающая система собирает пакеты именно так, как надо, а не в том порядке, как они пришли.

Acknowledgment Number(ACK) — номер подтверждения, показывает, на пакет с каким SYN отвечает удаленная система, таким образом мы имеем представление, что удаленная система получила наш пакет с данным
SYN.

Контрольные биты- 6 бит (на схеме между reversed и window). Значения битов:

URG: поле срочного указателя задействовано
ACK: поле подтверждения задействовано
PSH: функция проталкивания
RST: перезагрузка данного соединения
SYN: синхронизация номеров очереди
FIN: нет больше данных для передачи

DATA — это непосредственно те данные, которые мы хотим передать.

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

Когда мы хотим установить соединение, мы отправляем удаленной системе пакет следующей структуры:

Client — SYN (856779) — Host

Где Client- это мы, a Host — это удаленная система. Как ты видишь, мы посылаем пакет лишь с указанием SYN — это значит, что этот пакет первый, мы ни на что не отвечаем (отсутствует ACK). Данный пакет выглядит примерно так:

20 53 52 43 00 00 44 45 53 54 00 00 08 00 45 00 00 2C C3 00 40 00 20 06 10 0C CB 5E FD BA CB 5E F3 47 04 07 00 17 00 0D 12 CB 00 00 00 00 60 02 20 00 D9 70 00 00 02 04 05 B4 2D

Интересный момент в том, откуда берется SYN. SYN образуется от первоначального номера очереди
(ISN) — это 32-битный номер от 1 до 4294967295 (2 в 32-ой степени). ISN при перезагрузке системы равен 1, затем каждую секунду он увеличивается на 128000 (строго говоря изменение происходит каждые 4 микросекунды) + при каждом установленном соединении он увеличивается на 64000. Получается, что цикл уникальности ISN, при условии того, что никакие соединения не устанавливались, составляет примерно 4,55 часа. Поскольку ни один пакет так долго по сети не путешествует, мы можем полагать, что SYN будет абсолютно уникальным.

Получив наш пакет, удаленная система отвечает, что получила и готова установить соединение. Данные пакет выглядит так:

Host — SYN (758684758) и ACK (856780) — Client

Как видишь, удаленная система дает понять, что получила наш пакет. Для этого она посылает нам ACK с номером «наш SYN+1». В добавок к этому удаленная система посылает нам свой SYN (мы же тоже будем отвечать). А ответ наш будет такой:

Client — SYN (856780) и ACK (758684759) — Host

Думаю тебе уже должно быть все понятно. Если кто не понял, то пакет означает следующее: ваш пакет с SYN (758684758) получен, соединение установлено, наш SYN равен 856780.

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

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

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

Client — FIN(4894376) и ACK (1896955378) — Host

Host — ACK (4894377) — Client

Host — FIN (1896955378) и ACK (4894377) — Client

Client — ACK (1896955378) — Host

Думаю, ничего сложного здесь нет. Единственное, что стоит отметить — это флаг FIN, который означает желание завершить соединение.

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

Передача одного FIN Пакета = +1
Передача одного SYN Пакета = +1
Передача одного ACK Пакета = 0
Передача одного SYN/ACK Пакета = +1
Передача одного FIN/ACK Пакета = +1
Изменение за 1 секунду = +128,000
Установление одного соединения = +64,000

Возможно, кто-то спросит: «А что будет, если машин получит пакет с таким ACK, которого не было?» (SYN=ACK-1, а пакет с таким SYN мы не посылали). Получив ответ непонятно на что, мы в свою очередь ответим удаленной системе NACK-пакетом (означает «не знаю о чем ты», никакого соединения не устанавливается), но, надеюсь, более подробно мы поговорим с тобой об этом в следующий раз.

Транспортный уровень

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

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

Transmission Control Protocol

Transmission Control Protocol (TCP) (протокол управления передачей) - является обязательным протоколом стандарт TCP/IP , определенный в стандарте RFC 793, "Transmission Control Protocol (TCP)".

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

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

TCP обеспечивает свою надежность благодаря следующему:

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

• Порядковый номер выполняет две задачи:
• Если установлен флаг SYN, то это начальное значение номера последовательности - ISN (Initial Sequence Number), и первый байт данных, которые будут переданы в следующем пакете, будет иметь номер последовательности, равный ISN + 1.
• В противном случае, если SYN не установлен, первый байт данных, передаваемый в данном пакете, имеет этот номер последовательности.
• Номер подтверждения - если установлен флаг ACK, то это поле содержит номер последовательности, ожидаемый получателем в следующий раз. Помечает этот сегмент как подтверждение получения.
• Длина заголовка - задается словами по 32бита.
• Размер окна - количество байт, которые готов принять получатель без подтверждения.
• Контрольная сумма - включает псевдо заголовок, заголовок и данные.
• Указатель срочности - указывает последний байт срочных данных, на которые надо немедленно реагировать.
• URG - флаг срочности, включает поле "Указатель срочности", если =0 то поле игнорируется.
• ACK - флаг подтверждение, включает поле "Номер подтверждения, если =0 то поле игнорируется.
• PSH - флаг требует выполнения операции push, модуль TCP должен срочно передать пакет программе.
• RST - флаг прерывания соединения, используется для отказа в соединении
• SYN - флаг синхронизация порядковых номеров, используется при установлении соединения.
• FIN - флаг окончание передачи со стороны отправителя

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

TCP порты

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

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

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

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

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

Номера портов UDP и TCP не пересекаются.

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

Установление соединения TCP

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

Перед началом передачи каких-либо данных, согласно протоколу TCP, стороны должны установить соединение. Соединение устанавливается в три этапа (процесс «трёхкратного рукопожатия» TCP).

• Запрашивающая сторона (которая, как правило, называется клиент) отправляет SYN сегмент, указывая номер порта сервера, к которому клиент хочет подсоединиться, и исходный номер последовательности клиента (ISN).
• Сервер отвечает своим сегментом SYN, содержащим исходный номер последовательности сервера. Сервер также подтверждает приход SYN клиента с использованием ACK (ISN + 1). На SYN используется один номер последовательности.
• Клиент должен подтвердить приход SYN от сервера своим сегментов SYN, содержащий исходный номер последовательности клиента (ISN+1) и с использованием ACK (ISN+1). Бит SYN установлен в 0, так как соединение установлено.

После установления соединения TCP, эти два хоста могут передавать данные друг другу, так как TCP-соединение является полнодуплексным, они могут передавать данные одновременно.