В прошлой статье я рассказывала об интернет протоколе IP, который лежит в основе отправки и получения пакетов интернета. Но IP — это далеко не единственный протокол необходимый для функционирования сети Интернет. Поверх протокола IP реализуется протокол транспортного уровня — tcp. Как это работает? Даже читая сейчас мой Блог о фотографии, вы делаете это через протоколы TCP, IP и HTML. Рано или поздно я бы всё равно затронула эти темы, ведь вести блог и не знать ничего об устройстве веб-сайтов и сети Интернет — как-то странно, да и вообще не очень умно. Именно не зная основ, я несколько лет мучилась с Яндексом, пока не поняла наконец, что нужно проверять ответы сервера на запросы ботов, но это уже совсем другая история.

Давайте разберём связку IP и TCP поподробнее. Как я уже писала ранее, именно IP протокол отвечает за доставку пакетов, но отправить их можно только после того, как между двумя хостами, т.е. компьютерами, будет установлено «знакомство» и будет налажен «диалог». Этот процесс функционирует посредствам TCP.

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

Абстрактные сокеты

Для того, чтобы два хоста могли взаимодействовать и получать друг от друга данные с помощью tcp используется сокет. Вернее абстракция сокета, потому что физически его вообще-то нет, это двунаправленный канал. Сокеты используют порты с определёнными номерами, вернее любое 16-битное целое число. Для того, чтобы подсоединиться для передачи данных к какому-то хосту, нужно знать номер его порта. При этом второму хосту номер порта присваивается автоматически. Если номер хоста указан неверно, то пользователь получит отчёт об ошибке и передать ничего не получится. В этом процессе фигурируют 5 переменных: два ip адреса хостов, два номера портов и сам протокол tcp.

Хорошо, номер порта указали, соединение установлено. Что дальше? Для этого понадобится представить оживленную трассу с разными полосами. Если автомобилей на ней слишком много, то движение замедлится, а если кто-то начнёт нарушать правила, но вообще случится пробка. То же самое происходит и с соединениями в сети. Главная задача tcp — не допустить перегрузки сети. Потому что перегрузка — это потеря пакетов ip.

Буфер обмена и скользящее окно

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

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

Деление на сегменты

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

Фазы отправки и получения TCP

Медленный старт

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

Аддитивное увеличение

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

Мультипликативное уменьшение

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

Адаптивность и надёжность tcp

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

В случае наступления таймаута, цикл начинается заново с медленного старта.

Обмен «флагами» между хостами

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

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

Точно так же в конце взаимодействия хост отправляет флаг FIN, но канал закроется только после того, как обе стороны отправят на это свои подтверждения FIN и АCS. Конечным флагом будет ACS. После этого канал закроется.