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

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

В протоколе TCP-соединения устанавливаются с помощью «тройного рукопожатия», описанного в разделе «Установка соединения». Чтобы установить соединение, одна сторона (например, сервер) пассивно ожидает входящего соединения, выполняя примитивы LISTEN и ACCEPT, либо указывая конкретный источник, либо не указывая его.

Другая сторона (например, клиент) выполняет примитив CONNECT, указывая IP-адрес и порт, с которым он хочет установить соединение, максимальный размер TCP-сегмента и, по желанию, некоторые данные пользователя (например, пароль). Примитив CONNECT посылает TCP-сегмент с установленным битом SYN и сброшенным битом АСК и ждет ответа.

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

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

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

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

Разрыв соединения TCP

Хотя TCP-соединения являются полнодуплексными, чтобы понять, как происходит их разъединение, лучше считать их парами симплексных соединений. Каждое симплексное соединение разрывается независимо от своего напарника. Чтобы разорвать соединение, любая из сторон может послать TCP-сегмент с установленным в единицу битом FIN, что означает, что у него больше нет данных для передачи. Когда этот TCP-сегмент получает подтверждение, это направление передачи закрывается. Тем не менее, данные могут продолжать передаваться неопределенно долго в противоположном направлении. Соединение разрывается, когда оба направления закрываются. Обычно для разрыва соединения требуются четыре TCP-сегмента: по одному с битом FIN и по одному с битом АСК в каждом направлении. Первый бит АСК и второй бит FIN могут также содержаться в одном ТСР-сегменте, что уменьшит количество сегментов до трех.

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

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

Управление передачей в TCP

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

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

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

Отправители не обязаны передавать данные сразу, как только они приходят от приложения. Также никто не требует от получателей посылать подтвержде­ния как можно скорее. Например TCP-сущность, получив от прило­жения первые 2 Кбайт данных и зная, что доступный размер окна равен 4 Кбайт, была бы совершенно права, если бы просто сохранила полученные данные в буфере до тех пор, пока не прибудут еще 2 Кбайт данных, чтобы передать сразу сегмент с 4 Кбайт полезной нагрузки. Эта свобода действий может использоваться для улучшения производительности.

Рассмотрим TELNET-соединение с интерактивным редактором, реагирующим на каждое нажатие клавиши. В худшем случае, когда символ прибывает к передающей TCP-сущности, она создает 21-байтовый TCP-сегмент и передает его IP-уровню, который, в свою очередь, посылает 41-байтовую IP-дейтаграмму.

На принимающей стороне TCP-сущность немедленно отвечает 40-байтовым подтверждением (20 байт TCP-заголовка и 20 байт IP-заголовка). Затем, когда редактор прочитает этот байт из буфера, TCP-сущность пошлет обновленную информацию о размере буфера, передвинув окно на 1 байт вправо. Размер этого пакета также составляет 40 байт. Наконец, когда редактор обработает этот символ, он отправляет обратно эхо, передаваемое 41-байтовым пакетом. Итого для каждого введенного с клавиатуры символа пересылается четыре пакета общим размером 162 байта. В условиях дефицита пропускной способности линий этот метод работы нежелателен.

Для улучшения ситуации многие реализации TCP используют задержку подтверждений и обновлений размера окна на 500 мс в надежде получить дополни­тельные данные, вместе с которыми можно будет отправить подтверждение од­ним пакетом. Если редактор успеет выдать эхо в течение 500 мс, удаленному пользователю нужно будет выслать только один 41-байтовый пакет, таким образом, нагрузка на сеть снизится вдвое.

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

Алгоритм Нагля широко применяется различными реализациями протокола TCP, однако иногда бывают ситуации, в которых его лучше отключить. В частности, при работе приложения X-Windows в Интернете информация о перемещениях мыши пересылается на удаленный компьютер. (X-Window - это система управления окнами в большинстве ОС типа UNIX). Если буферизировать эти данные для пакетной пересылки, курсор будет перемещаться рывками с большими паузами, в результате чего пользоваться программой будет очень сложно, почти невозможно.

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

Рассмотрим на примере - начальное состояние таково: TCP-буфер приемной стороны полон, и отправителю это известно (то есть размер его окна равен 0). Затем интерактивное приложение читает один символ из TCP-потока. Принимающая TCP-сущность радостно сообщает отправителю, что размер окна увеличился, и что он теперь может послать 1 байт. Отправитель повинуется и посылает 1 байт. Буфер снова оказывается полон, о чем получатель и извещает, посылая подтверждение для 1-байтового сегмента с нулевым размером окна. И так может продолжаться вечно.

Дэвид Кларк (David Clark) предложил запретить принимающей стороне отправлять информацию об однобайтовом размере окна. Вместо этого получатель должен подождать, пока в буфере не накопится значительное количество сво­бодного места. В частности, получатель не должен отправлять сведения о новом размере окна до тех пор, пока он не сможет принять сегмент максимального размера, который он объявлял при установке соединения, или его буфер не освободился хотя бы наполовину.

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

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

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

Еще одна проблема получателя состоит в сегментах, полученных в неправильном порядке. Они могут храниться или отвергаться по усмотрению получателя. Разумеется, подтверждение может быть выслано, только если все данные вплоть до подтверждаемого байта получены. Если до получателя доходят сегменты О, 1, 2, 4, 5, 6 и 7, он может подтвердить получение данных вплоть до последнего байта сегмента 2. Когда у отправителя истечет время ожидания, он передаст сегмент 3 еще раз. Если к моменту прибытия сегмента 3 получатель сохранит в буфере сегменты с 4-го по 7-й, он сможет подтвердить получение всех байтов, вплоть до последнего байта сегмента 7.

- 1

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

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

Шаг 1. Отправка SYN пакета

Отправляется пакет с выставленным флагом 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 .

Шаг 2. Отправка подтверждения SYN+ACK

В ответ на этот пакет, сервер, если он не против соединения, посылает пакет с битами SYN,ACK и произвольным номером последовательности Sequence Number, вычисленным по похожему принципу. А поле Acknowledgment Number будет равняться полю ISN+1.


На примере видно, что сгенерировано число Initial Receive Sequence (IRS) = 675813843 и пакет послан как ответ AN: 2686526191 (предыдущий SN: 2686526190 + 1).

Шаг 3. Отправка подтверждения ACK

Теперь инициатору подключения не остается ничего другого, как ответить ACK и пояснить, что речь идёт об Acknowledgment number предыдущего шага IRS + 1, т.е. 675813843+1 = 675813844! А Sequence nuber остаётся неизменным, AN предыдущего пакета 2686526191.


ACK

Иначе, в переводе с TCP на русский это выглядит так:

  1. Клиент: Кодовое слово “1” (Sequence number), сервер, давай мутить! (SYN);
  2. Сервер: Моё кодовое слово “5” (Sequence number), клиент, на твой запрос по кодовому слову “1” (Acknowledgment number) отвечаю (+1) ну давай мутить (SYN+ACK).
  3. Клиент: Ну хорошо! Раз ты, сервер, получай мой окончательный ответ ответ (ACK) на твое согласие (5+1) на мой запрос (1+1).

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

При этому так же происходит взаимное увеличение Sequence Number у сервера и у клиента, но только уже не на 1, а на размер отправляемых данных.

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

Выполняет функции протокола транспортного уровня модели OSI.

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

Реализация TCP, как правило, встроена в ядро системы, хотя есть и реализации TCP в контексте приложения.

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

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

Установка соединения

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

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

Установка соединения

Процесс начала сеанса TCP называется «тройным рукопожатием».

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

2. Если клиент получает сегмент с флагом SYN, то он запоминает номер последовательности и посылает сегмент с флагом ACK.

3. Если сервер в состоянии SYN-RECEIVED получает сегмент с флагом ACK, то он переходит в состояние ESTABLISHED.

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

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

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

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

Завершение соединения можно рассмотреть в три этапа:

Посылка серверу от клиента флагов FIN и ACK на завершение соединения.

Сервер посылает клиенту флаги ответа ACK , FIN, что соединение закрыто.

После получения этих флагов клиент закрывает соединение и в подтверждение отправляет серверу ACK , что соединение закрыто.