TCP - это транспортный механизм, предоставляющий поток данных, с предварительной установкой соединения, за счёт этого дающий уверенность в достоверности получаемых данных, осуществляет повторный запрос данных в случае потери данных и устраняет дублирование при получении двух копий одного пакета. В отличие от UDP , гарантирует, что приложение получит данные точно в такой же последовательности, в какой они были отправлены, и без потерь.
Протокол TCP используется в тех случаях, когда требуется надежная доставка сообщений. Он освобождает прикладные процессы от необходимости использовать таймауты и повторные передачи для обеспечения надежности. Наиболее типичными прикладными процессами, использующими TCP, являются FTP (File Transfer Protocol - протокол передачи файлов) и TELNET. Кроме того, TCP используют система X-Window, rcp (remote copy - удаленное копирование) и другие "r-команды". Большие возможности TCP даются не бесплатно. Реализация TCP требует большой производительности процессора и большой пропускной способности сети. Внутренняя структура модуля TCP гораздо сложнее структуры модуля UDP.
Реализация TCP, как правило, встроена в ядро системы, хотя есть и реализации TCP в контексте приложения.
Когда осуществляется передача от компьютера к компьютеру через Internet, TCP работает на верхнем уровне между двумя конечными системами, например, интернет-браузер и интернет-сервер. Также TCP осуществляет надежную передачу потока байт от одной программы на некотором компьютере в другую программу на другом компьютере. Программы для электронной почты и обмена файлами используют TCP. TCP контролирует длину сообщения, скорость обмена сообщениями, сетевой трафик.
Когда прикладной процесс начинает использовать TCP, то модуль TCP на машине клиента и модуль TCP на машине сервера начинают общаться. Эти два оконечных модуля TCP поддерживают информацию о состоянии соединения, называемого виртуальным каналом. Этот виртуальный канал потребляет ресурсы обоих оконечных модулей TCP. Канал является дуплексным; данные могут одновременно передаваться в обоих направлениях. Один прикладной процесс пишет данные в TCP-порт, они проходят по сети, и другой прикладной процесс читает их из своего TCP-порта.
Протокол TCP разбивает поток байт на пакеты; он не сохраняет границ между записями. Например, если один прикладной процесс делает 5 записей в TCP-порт, то прикладной процесс на другом конце виртуального канала может выполнить 10 чтений для того, чтобы получить все данные. Но этот же процесс может получить все данные сразу, сделав только одну операцию чтения. Не существует зависимости между числом и размером записываемых сообщений с одной стороны и числом и размером считываемых сообщений с другой стороны.
Протокол TCP требует, чтобы все отправленные данные были подтверждены принявшей их стороной. Он использует таймауты и повторные передачи для обеспечения надежной доставки. Отправителю разрешается передавать некоторое количество данных, не дожидаясь подтверждения приема ранее отправленных данных. Таким образом, между отправленными и подтвержденными данными существует окно уже отправленных, но еще неподтвержденных данных. Количество байт, которые можно передавать без подтверждения, называется размером окна. Как правило, размер окна устанавливается в стартовых файлах сетевого программного обеспечения. Так как TCP-канал является дуплексным, то подтверждения для данных, идущих в одном направлении, могут передаваться вместе с данными, идущими в противоположном направлении. Приемники на обеих сторонах виртуального канала выполняют управление потоком передаваемых данных для того, чтобы не допускать переполнения буферов.
Схема работы пользовательского приложения с TCP в общих чертах состоит в следующем. Для передачи данных пользовательскому процессу надо вызвать соответствующую функцию TCP, с указанием на буфер передаваемых данных. TCP упаковывает эти данные в сегменты своего стека и вызывает функцию передачи протокола нижнего уровня, например IP.
На другом конце, получатель TCP группирует поступившие от протокола нижнего уровня данные в принимающие сегменты своего буфера, проверяет целостность данных, передает данные пользовательскому процессу и уведомляет отправителя об их получении.
Пользовательский интерфейс с TCP может выполнять такие команды как открыть (OPEN) или закрыть соединение (CLOSE), отправить (SEND) или принять (RECEIVE) данные, а также получить состояние соединения (STATUS).
В модели межсетевого соединения взаимодействие TCP и протоколов нижнего уровня, как правило, не специфицировано, за исключением того, что должен существовать механизм, который обеспечивал бы асинхронную передачу информации от одного уровня к другому. Результатом работы этого механизма является инкапсуляция протокола более высокого уровня в тело протокола более низкого уровня. Реализуется этот механизм через интерфейс вызовов между TCP и IP.
В результате работы этого механизма каждый TCP пакет вкладывается в «конверт» протокола нижнего уровня, например, IP. Получившаяся таким образом дейтаграмма содержит в себе TCP-пакет так же как TCP пакет содержит пользовательские данные.
ТСР-сегменты отправляются как IP-дейтаграммы. Заголовок TCP, следующий за IP-заголовком, содержит информацию TCP-протокола.
Source Port (16 бит). Порт отправителя.
Destination Port (16 бит). Порт получателя.
Sequence Number (32 бита). Номер кадра. Номер кадра первого октета данных в этом сегменте (за исключением пакета, где присутствует флаг SYN). Если в пакете присутствует флаг SYN, то номер данного пакета становится номером начала последовательности (ISN) и номером первого октета данных становится номер ISN+1.
Acknowledgment Number (32 бита). Поле номера кадра подтвержденного получения. Если пакет содержит установленный контрольный бит АСК, то это поле содержит номер следующего пакета данных отправителя, который ожидает получатель. При установленном соединении пакет подтверждения отправляется всегда.
Data Offset (4 бита). Поле величины смещения данных. Оно содержит количество 32-битных слов заголовка TCP-пакета. Это число определяет смещение расположения данных в пакете.
Reserved (6 бит). Резервное поле. Поле зарезервировано.
Флаги управления (слева направо):
Window (16 бит). Окно. Это поле содержит количество байт данных, которое отправитель данного сегмента может принять, отсчитанное от номера байта, указанного в поле Acknowledgment Number.
Checksum (16 бит). Поле контрольной суммы. Это поле содержит 16 бит суммы побитных дополнений 16-битных слов заголовка и данных. Если сегмент содержит нечетное число байт заголовка и данных, последний байт дополняется справа нулями. При вычислении контрольной суммы поле контрольной суммы полагается равным нулю.
Urgent Pointer (16 бит). Поле указателя срочных данных. Это поле содержит значение счетчика пакетов, начиная с которого следуют пакеты повышенной срочности. Это поле принимается во внимание только в сегментах с установленным флагом URG.
Options. Поле дополнительных параметров: может быть переменной длины.
Padding. Заполнение: переменная длина. Заполнение (нулями) TCP-заголовка используется для выравнивания его по 32-битному слову.
Эта ссылка на наглядное видео. К сожалению, оно на английском языке, но и так понятно.Многим знакома аббревиатура 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-пакетом (означает «не знаю о чем ты», никакого соединения не устанавливается), но, надеюсь, более подробно мы поговорим с тобой об этом в следующий раз.
Прежде чем данные могут быть отправлены между двумя хостами по протоколу TCP , должно быть установлено соединение. Один хозяин, называется сервер, слушает запросы на подключение. Хост запрашивает соединение и называется клиентом. Для запроса на подключение, клиент отправляет сегмент TCP с указанием своего номера порта и что он хочет подключиться. SYN (синхронизация порядковых номеров), флаг установлен, последовательность исходных данных клиента указывает номер.
Для предоставления связи, сервер отвечает на сегмент, в котором содержится заголовок исходной последовательности данных номера. SYN и ACK флаги установлены. Для подтверждения получения данных клиента порядковый номер в поле подтверждения содержит это значение плюс один.
Для завершения протокола установления соединения, клиент подтверждает номер последовательности данных серверу, отправляя обратно сегмент с установленным флагом ACK и признания поля, содержащего данные сервера и порядковый номер плюс один.
TCP сегменты
передаются только между клиентом и сервером, если есть данные в потоке. Происходит опрос состояния. Если линия связи выходит из строя, на конце будут знать об отказе, пока данные не будут отправлены. На практике применение тайм-аута, как правило, разрывает соединение, если определенный промежуток времени прошел без активности. Тем не менее, можно продолжить не удачную сессию, как будто ничего не произошло, если вы можете установить соединение снова. (Заметим, что это верно только если ваш провайдер предоставляет вам фиксированный IP-адрес
. Если IP-адрес
выделяется динамически при входе в систему, вы не сможете возобновить связь, потому что ваш сокет (который, как мы уже отмечали ранее, состоит из вашего IP-адреса
и номера порта) был бы другой.
Передача данных
После того, как соединение было установлено, данные могут быть отправлены. TCP-протокол
скользящего окна означает, что нет необходимости ждать когда следует признать один сегмент, прежде чем другой может быть отправлен. Подтвержения отправляются только в случае необходимости немедленно или через определенный истекший интервал. Это делает TCP
эффективным протокол для массовой передачи данных.
Одним из примеров, когда подтверждение отправляется немедленно, когда отправитель заполнит входной буфер приемника. Управление потоком осуществляется с помощью поля размера окна в заголовке TCP
. В части, содержащей признание размера окна будет равно нулю. Когда приемник снова может принимать данные, направляется второе подтверждение с указанием новых размеров окна. Такое признание называется окно обновления.
При интерактивной сессии Telnet
, один введенный символ на клавиатуре может быть отправлен в своем сегменте TCP
. Каждый персонаж может быть признан сегментом вступления в другую сторону. Если вводимые символы нашли свое отражение на удаленном хосте, тогда еще пара отрезков могут быть получены, первый удаленным хостом, а второй, его признания, по Telnet клиента. Таким образом, один типизированный характер может привести к четырём IP-пакетам
, каждый из которых содержит 20 байт IP-заголовка
, 20 байт заголовка TCP
и только один байт данных, передаваемых через Интернет.
TCP
имеет некоторые особенности, чтобы попытаться сделать вещи немного более эффективным. Подтверждение задержки до 500 мс может быть указано в надежде, что в течение этого времени некоторые данные могут быть направлены в другую сторону, и признание контрольных данных вместе с ней.
Неэффективность отправки многих очень маленьких сегментов уменьшается на то, что называется Nagle алгоритмом. Это указывает, что сегмент TCP
содержащий меньше данных, чем рекламируемый размер окна получателя может быть отправлен только если предыдущая часть была признана. Небольшое количество данных объединяются, пока они либо равны размеру окна, или если получил признание предыдущий сегмент. Чем медленнее соединение, тем больше будет период, в течение которого данные могут быть объединены, и, следовательно, меньше отдельных сегментов TCP
будет отправлено в течение занятой ссылки.
Исправление ошибок
Важным преимуществом TCP на UDP
является то, что это надежный транспортный протокол передачи данных. Он может обнаружить данные которые были успешно получены на другом конце, а если не были получены, TCP
может предпринять шаги, чтобы исправить ситуацию. Если ничего не помогает, он может сообщить отправкой проблемы, так что он знает, что передача не удалась.
Самой распространенной проблемой является то, что сегмент TCP
потерян или поврежден. TCP
занимается этим, отслеживая принятые данные, которые он посылает. Если подтверждение не получено в течение интервала определённого протоколом, данные передаются снова.
Интервал, TCP
будет ждать перед повторной передачей данных и зависит от скорости соединения. Протокол контролирует время, которое обычно требуется, чтобы получить признание и использует таймер для расчета периода для ретрансляции. Если подтверждение не будет получено после повторной отправки данных один раз, он отправляется повторно, на всё возрастающих интервалах, пока не будет получен ответ или (обычно) значение применения тайм-аута превышено.
Как уже упоминалось, TCP
реализует поток управления с помощью поля размера окна в заголовке. Потенциал тупиковой ситуации возникает, если приемник останавливает поток данных, установив размер окна в ноль, и сегмент окна обновления, который предназначен для запуска потока данных снова теряется. На каждом конце соединения будут остановки, ожидая, пока другие что-то сделают.
Подтверждения сами по себе не ACKed, в этом случае стратегия ретрансляции не решит проблемы. Чтобы предотвратить возникновение тупиковой ситуации, TCP
посылает зонд сообщения окна через регулярные промежутки времени для запроса о его приемнике размера окна.
Закрытие соединения
Когда приходит время, чтобы закрыть соединение TCP
, каждое направление потока данных должно быть закрыто в отдельности. Один конец связи посылает сегмент, в котором установлен флаг FIN (закончил передачу данных). Получение данного сегмента признают, и принимающая сторона уведомляет его применение, чтобы другая сторона закрыла соединение,потому что осталась половина соединения.
Приемник может, если пожелает, продолжать передавать данные в другом направлении. Обычно, принимающее приложение будет заставлять TCP
закрывать вторую половину соединения, используя такую же процедуру.
Хотя есть и реализации TCP в контексте приложения.
Когда осуществляется передача от компьютера к компьютеру через Интернет, TCP работает на верхнем уровне между двумя конечными системами, например, браузером и веб-сервером. Также TCP осуществляет надежную передачу потока байтов от одной программы на некотором компьютере к другой программе на другом компьютере. Программы для электронной почты и обмена файлами используют TCP. TCP контролирует длину сообщения, скорость обмена сообщениями, сетевой трафик.
| Бит | 0 - 3 | 4 - 9 | 10 - 15 | 16 - 31 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | Порт источника | Порт назначения | ||||||||||||||||||||||||||||||
| 32 | Номер последовательности | |||||||||||||||||||||||||||||||
| 64 | Номер подтверждения | |||||||||||||||||||||||||||||||
| 96 | Смещение данных | Зарезервировано | Флаги | Размер Окна | ||||||||||||||||||||||||||||
| 128 | Контрольная сумма | Указатель важности | ||||||||||||||||||||||||||||||
| 160 | Опции (необязательное, но используется практически всегда) | |||||||||||||||||||||||||||||||
| 160/192+ | Данные |
|||||||||||||||||||||||||||||||
Номер последовательности выполняет две задачи:
Поскольку поток TCP в общем случае может быть длиннее, чем число различных состояний этого поля, то все операции с номером последовательности должны выполняться по модулю 2^32. Это накладывает практическое ограничение на использование TCP. Если скорость передачи коммуникационной системы такова, чтобы в течение MSL (максимального времени жизни сегмента) произошло переполнение номера последовательности, то в сети может появиться два сегмента с одинаковым номером, относящихся к разным частям потока, и приёмник получит некорректные данные.
Если установлен флаг ACK, то это поле содержит номер последовательности, ожидаемый получателем в следующий раз. Помечает этот сегмент как подтверждение получения.
Это поле определяет размер заголовка пакета TCP в 4-байтных (4-октетных) словах. Минимальный размер составляет 5 слов, а максимальный - 15, что составляет 20 и 60 байт соответственно. Смещение считается от начала заголовка TCP.
Зарезервировано (6 бит) для будущего использования и должно устанавливаться в ноль. Из них два (5-й и 6-й) уже определены:
Это поле содержит 6 битовых флагов:
В этом поле содержится число, определяющее в байтах размер данных, которые отправитель готов принять.
TCP-заголовок не содержит информации об адресе отправителя и получателя, поэтому даже при совпадении порта получателя нельзя с точностью сказать, что сообщение пришло в нужное место. Поскольку назначением протокола TCP является надёжная доставка сообщений, то этот момент имеет принципиальное значение. Эту задачу можно было решить разными способами. Самый очевидный - добавить информацию об адресе назначения в заголовок TCP, однако это, во-первых, приводит к дублированию информации, что снижает долю полезной информации переносимой TCP-сегментом, а во-вторых, нарушает принцип инкапсуляции модели OSI. Поэтому разработчики протокола пошли другим путём и использовали дополнительный псевдозаголовок:
TCP-псевдозаголовок IPv4
TCP-псевдозаголовок IPv6
Псевдозаголовок не включается в TCP-сегмент. Он используется для расчета контрольной суммы перед отправлением сообщения и при его получении (получатель составляет свой псевдозаголовок, используя адрес хоста, с которого пришло сообщение, и собственный адрес, а затем считает контрольную сумму).
Поле контрольной суммы - это 16-битное дополнение к сумме всех 16-битных слов заголовка(включая псевдозаголовок) и данных. Если сегмент, по которому вычисляется контрольная сумма, имеет длину не кратную 16-ти битам, то длина сегмента увеличивается до кратной 16-ти, за счет дополнения к нему справа нулевых битов заполнения. Биты заполнения (0) не передаются в сообщении и служат только для расчёта контрольной суммы. При расчёте контрольной суммы значение самого поля контрольной суммы принимается равным 0.
16-битовое значение положительного смещения от порядкового номера в данном сегменте. Это поле указывает порядковый номер октета, которым заканчиваются важные (urgent) данные. Поле принимается во внимание только для пакетов с установленным флагом URG.
Могут применяться в некоторых случаях для расширения протокола. Иногда используются для тестирования. На данный момент в опции практически всегда включают 2 байта NOP (в данном случае 0x01) и 10 байт, задающих timestamps . Вычислить длину поля опции можно через значение поля смещения.
В отличие от традиционной альтернативы - UDP, который может сразу же начать передачу пакетов, TCP устанавливает соединения, которые должны быть созданы перед передачей данных. TCP соединение можно разделить на 3 стадии:
| Состояния сеанса 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 (подтверждения на свой запрос о разъединении) |
Процесс начала сеанса TCP - обозначаемое как "рукопожатие" (handshake), состоит из 3 шагов.
1. Клиент, который намеревается установить соединение, посылает серверу сегмент с номером последовательности и флагом SYN.
2. Если клиент получает сегмент с флагом SYN, то он запоминает номер последовательности и посылает сегмент с флагом ACK.
3. Если сервер в состоянии SYN-RECEIVED получает сегмент с флагом ACK, то он переходит в состояние ESTABLISHED.
Процесс называется "трехэтапным согласованием" ("three way handshake"), так как несмотря на то что возможен процесс установления соединения с использованием 4 сегментов (SYN в сторону сервера, ACK в сторону клиента, SYN в сторону клиента, ACK в сторону сервера), на практике для экономии времени используется 3 сегмента.
Пример базового 3-этапного согласования:
TCP A TCP B
1. CLOSED LISTEN
2. SYN-SENT -->
В строке 2 TCP A начинает передачу сегмента SYN, говорящего об использовании номеров последовательности, начиная со 100. В строке 3 TCP B передает SYN и подтверждение для принятого SYN в адрес TCP A. Надо отметить, что поле подтверждения показывает ожидание TCP B приема номера последовательности 101, подтверждающего SYN с номером 100.
В строке 4 TCP A отвечает пустым сегментом с подтверждением ACK для сегмента SYN от TCP B; в строке 5 TCP B передает некоторые данные. Отметим, что номер последовательности сегмента в строке 5 совпадает с номером в строке 4, поскольку ACK не занимает пространства номеров последовательности (если это сделать, придется подтверждать подтверждения - ACK для ACK!).
При обмене данными приемник использует номер последовательности, содержащийся в получаемых сегментах, для восстановления их исходного порядка. Приемник уведомляет передающую сторону о номере последовательности байт, до которой он успешно получил данные, включая его в поле «номер подтверждения». Все получаемые данные, относящиеся к промежутку подтвержденных последовательностей, игнорируются. Если полученный сегмент содержит номер последовательности больший, чем ожидаемый, то данные из сегмента буферизируются, но номер подтвержденной последовательности не изменяется. Если впоследствии будет принят сегмент, относящийся к ожидаемому номеру последовательности, то порядок данных будет автоматически восстановлен исходя из номеров последовательностей в сегментах.
Для того, чтобы передающая сторона не отправляла данные интенсивнее, чем их может обработать приемник, TCP содержит средства управления потоком. Для этого используется поле «окно». В сегментах, направляемых от приемника передающей стороне в поле «окно» указывается текущий размер приемного буфера. Передающая сторона сохраняет размер окна и отправляет данных не более, чем указал приемник. Если приемник указал нулевой размер окна, то передача данных в направлении этого узла не происходит, до тех пор пока приемник не сообщит о большем размере окна.
В некоторых случаях передающее приложение может явно затребовать протолкнуть данные до некоторой последовательности принимающему приложению, не буферизируя их. Для этого используется флаг PSH. Если в полученном сегменте обнаруживается флаг PSH, то реализация TCP отдает все буферизированные на текущий момент данные принимающему приложению. «Проталкивание» используется, например, в интерактивных приложениях. В сетевых терминалах нет смысла ожидать ввода пользователя после того, как он закончил набирать команду. Поэтому последний сегмент, содержащий команду, обязан содержать флаг PSH, чтобы приложение на принимающей стороне смогло начать её выполнение.
Завершение соединения можно рассмотреть в три этапа:
TCP требует явного указания максимального размера сегмента (MSS) в случае, если виртуальное соединение осуществляется через сегмент сети, где максимальный размер блока (MTU) менее, чем стандартный MTU Ethernet (1500 байт).
В протоколах туннелирования, таких как GRE , IPIP, а также PPPoE MTU туннеля меньше чем стандартный, поэтому сегмент TCP максимального размера имеет длину пакета больше, чем MTU. Поскольку фрагментация в подавляющем большинстве случаев запрещена, то такие пакеты отбрасываются.
Проявление этой проблемы выглядит как «зависание» соединений. При этом «зависание» может происходить в произвольные моменты времени, а именно тогда, когда отправитель использовал сегменты длиннее допустимого размера.
Для решения этой проблемы на маршрутизаторах применяются правила Firewall-а, добавляющие параметр MSS во все пакеты, инициирующие соединения, чтобы отправитель использовал сегменты допустимого размера.
MSS может также управляться параметрами операционной системы.
Хотя протокол осуществляет проверку контрольной суммы по каждому сегменту, используемый алгоритм считается слабым . Так в 2008 году не обнаруженная сетевыми средствами ошибка в передаче одного бита, привела к остановке серверов системы Amazon Web Services .
В общем случае распределенным сетевым приложениям рекомендуется использовать дополнительные программные средства для гарантирования целостности передаваемой информации .
Основная статья: Атаки на TCP
Недостатки протокола проявляются в успешных теоретических и практических атаках, при которых злоумышленник может получить доступ к передаваемым данным, выдать себя за другую сторону или привести систему в нерабочее состояние.
Многие реализации стека TCP/IP предоставляют возможности использования аппаратной поддержки для автоматического расчёта контрольной суммы в сетевом адаптере до передачи в сеть или после приёма из сети для верификации. Это может освобождать операционную систему от использования ценных тактов процессора при вычислении контрольной суммы.
Эта функция может приводить к тому, что анализаторы трафика , перехватывающие исходящие пакеты до их передачи в сетевой адаптер и не знающие о делегировании расчёта контрольной суммы сетевому адаптеру, могут сообщать об ошибке контрольной суммы в исходящих пакетах.
Вообще, организация соединения по протоколу TCP начинается с так называемого трехстороннего квитирования (рукопожатия).
Отправляется пакет с выставленным флагом SYN, что означает инициализацию сессии. Разумеется, на этом этапе будет задан порт источника и порт назначения (порт источника выбирается случайно из диапазона 1024-65535), хотя на этом участке можно выделить два диапазона ещё. Порты с 1024 до 49151 используются для проприетарных приложений, контролируется IANA (те же чуваки, которые и выделяют IP адреса). Порт назначения здесь зависит от используемой службы. Стандартные порты ssh – 22, http – 80, pop3 – 110 и т.д. Все эти порты прописаны в c:\Windows\System32\drivers\etc\services ну или аналогичный файл в Linux.
SYNКак же выбирается этот номер? Приведу выдержку из RFC 793:
При организации нового соединения генерируется начальный порядковый номер (initial sequence number) ISN. Генерация номера основана на текущем (возможно, фиктивном) 32-битовом значении времени, в котором младший бит инкрементируется приблизительно каждые 4 микросекунды. Таким образом, цикл номеров ISN занимает около 4.55 часа. Поскольку мы предполагаем, что сегмент сохраняется в сети в течение времени, не превышающего MSL (Maximum Segment Lifetime – максимальное время жизни
сегмента), и значение MSL < 4.55 час., можно считать значения ISN уникальными.
То есть в первом пакете с битом SYN задается некий номер последовательности. На скрине выше я привел пример, видим бит SYN и ISN 2686526190 .
В ответ на этот пакет, сервер, если он не против соединения, посылает пакет с битами SYN,ACK и произвольным номером последовательности Sequence Number, вычисленным по похожему принципу. А поле Acknowledgment Number будет равняться полю ISN+1.
На примере видно, что сгенерировано число Initial Receive Sequence (IRS) = 675813843 и пакет послан как ответ AN: 2686526191 (предыдущий SN: 2686526190 + 1).
Теперь инициатору подключения не остается ничего другого, как ответить ACK и пояснить, что речь идёт об Acknowledgment number предыдущего шага IRS + 1, т.е. 675813843+1 = 675813844! А Sequence nuber остаётся неизменным, AN предыдущего пакета 2686526191.
ACK
Иначе, в переводе с TCP на русский это выглядит так:
Всё. С этого момента соединение считается установленным. Дальнейшие пакеты будут передавать уже полезную нагрузку – данные протоколов вышестоящих уровней, например SSH.
При этому так же происходит взаимное увеличение Sequence Number у сервера и у клиента, но только уже не на 1, а на размер отправляемых данных.
