Установление и разрыв TCP соединения. Создание и Завершение TCP Соединения

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

Привычный нам веб (world wide web) основан на протоколе HTTP (hyper-text transfer protocol), который в своб очередь работает на основе TCP. Это классический пример использования стека протоколов. Есть еще протоколы электронной почты IMAP/POP и SMTP, протоколы удаленной оболочки SSH, удаленного рабочего стола RDP, баз данных MySQL, SSL/TLS, и тысячи других приложений со своими протоколами (..)

Чем же отличаются все эти протоколы? Все довольно просто. Помимо различных задач, поставленных при разработке (например, скорость, безопасность, устойчивость и прочие критерии), протоколы созданы с целью разграничения. Например, существуют протоколы прикладного уровня, разные у разных приложений: IRC, Skype, ICQ, Telegram и Jabber - несовместимы друг с другом. Они разработаны для выполнения конкретной задачи, и в данном случае возможность звонить по WhatsApp в ICQ просто не определена технически, так как приложения используют различный протокол. Но их протоколы основываются на одном и том же протоколе IP.

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

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

Если уж совсем-совсем простым языком, это почтовая служба.

У каждого участника IP-совместимой сети есть свой собственный адрес, который выглядит примерно так: 162.123.058.209. Всего таких адресов для протокола IPv4 - 4,22 миллиарда.

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

TCP/IP - это набор протоколов.

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

Что за TCP/IP (сейчас будет совсем просто, пусть коллег не бомбит):

Информация до вашего компа идет по проводам (радио или что еще - не суть важно). Если по проводам пустили ток - значит 1. Выключили - значит 0. Получается 10101010110000 и так далее. 8 ноликов и единиц (битов) это байт. Например 00001111. Это можно представить как число в двоичном виде. В десятичном виде байт - это число от 0 до 255. Эти числа сопоставляет с буквами. Например 0 это А, 1 это Б. (Это называется кодировка).

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

Это первый протокол.

Компьютерам как то понимать, что один из них перестал отдавать информацию (типа "я все сказал"). Для этого в начале последовательности данных 010100101 компьютеры могут слать несколько бит, длинну сообщения, которое они хотят передать. Например, первые 8 бит могут означать длину сообщения. То есть сначала в первых 8 битах передают закодированное число 100 и потом 100 байт. После этого принимающий компьютер будет ожидать следующие 8 бит и следующее сообщение.

Вот у нас еще один протокол, с его помощью можно передавать сообщения (компьютерные).

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

Связь не всегда надежная. Для надежной доставки сообщений (компьютерных) используют TCP. При выполнении протокола TCP компьютеры будут переспрашивает друг друга - правильное ли они сообщение получили. Есть еще UDP - это когда компы не переспрашивают то ли они получили. Зачем надо? Вот вы слушаете интернет радио. Если пару байт придет с ошибками - вы услышите например "пш" и дальше снова музыку. Не смертельно, да и не особо важно - для этого используют UDP. А вот если пару байт испортятся при загрузку сайта - вы получите хрень на мониторе и ничего не поймёте. Для сайтом используют TCP.

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

Еще есть http протокол. Первая строчка - адрес сайта, последующие строчки - текст который вы шлете на сайт. Все строчки http - это текст. Который засовывают в TCP сообщение, которое адресуют с помощью IP и так далее.

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

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

Помимо этого, TCP обеспечивает:

• Надёжную доставку сегментов.
• Упорядочивание сегментов при получении.
• Работу с сессиями.
• Контроль за скоростью передачи.

Рассмотрим эти возможности более детально.

Надёжная доставка сегментов

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

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

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

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

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

Работа с сессиями

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

Контроль за скоростью передачи

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

Благодаря механизму скользящего окна (sliding window), TCP может работать с сетями разной надёжности. Механизм плавающего окна позволяет менять количество пересылаемых байтов, на которые надо получать подтверждение от адресата. Чем больше размер окна, тем больший объём информации будет передан до получения подтверждения. Для надёжных сетей подтверждения можно присылать редко, чтобы не добавлять трафика, поэтому размер окна в таких сетях автоматически увеличивается. Если же TCP видит, что данные теряются, размер окна автоматически уменьшается. Это связанно с тем, что если мы передали, например, 3 килобайта информации и не получили подтверждения, то мы не знаем, какая конкретно часть из них не дошла и вынуждены пересылать все три килобайта заново. Таким образом, для ненадёжных сетей, размер окна должен быть минимальным.

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

Структура TCP

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

• Source port и Destination port - это соответственно номера портов получателя и отправителя, идентифицирующие приложений на отправляющем и принимающем узлах.
• Sequence number и Acknowledgment number - это порядковый номер сегмента и номер подтверждения, которые используются для надёжной доставки. Например, если отправитель шлёт сегмент с SN 100, то получатель может ответить на него ACK 101 SN200, что означает: «Я получил твой сегмент с номером 100 и жду от тебя 101-го, кстати, у меня своя нумерация. Мои номера начинаются с 200» Отправитель, в свою очередь, может ответить SN101 ACK201, что означает «Я получил от тебя сегмент с номером 200, могу принять следующий 201-ый, а вот тебе мой 101-ый сегмент, которого ты ждёшь». Ну и так далее.
• Header length - Это четырёхбитное поле, содержащее в себе длину заголовка TCP сегмента.
• Reserved - 6 зарезервированных на всякий случай бит.
• Control - поле с флагами, которые используются в процессе обмена информацией и описывают дополнительное назначение сегмента. Например, флаг FIN используется для завершения соединений, SYN и ACK - для установки.
• Window - содержит размер окна, о чём было сказано выше.
• Checksumm - контрольная сумма заголовка и данных.
• Urgent - признак важности (срочности) данного сегмента.
• Options - дополнительное необязательное поле, которое может использоваться, например, для тестирования протокола.
• В разделе данных содержатся собственно данные, полученные от протокола уровня приложений, либо их кусок, если данные пришлось разбивать.

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

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

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

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

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

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

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

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

3. Клиент-инициатор отвечает значением подтверждения, равным номеру последовательности, который он получил, плюс один. Это шаг завершает процесс установления соединения.

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

URG - Поле "Указатель важности" задействовано

ACK - Поле "Номер подтверждение" задействовано

PSH - Функция Push (протолкнуть данные, накопившиеся в буфере, в приложение пользователя)

RST - Сброс соединения

FIN - Больше нет данных от отправителя, завершение соединения

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

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

Прежде чем данные могут быть отправлены между двумя хостами по протоколу 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, гораздо меньшее количество людей знает, что это протокол передачи данных. Но практически никто не знает, как он устроен.

Внимание! Этот материал рассчитан на тех, кого действительно интересуется вопросом: «Как устроена сеть, и что я могу сделать, если буду это знать». Если же тебя еще смущают слова вроде 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-пакетом (означает «не знаю о чем ты», никакого соединения не устанавливается), но, надеюсь, более подробно мы поговорим с тобой об этом в следующий раз.