Ключевые тайны TCP-соединений сетевых пакетных брокеров: раскрыта необходимость тройного рукопожатия

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

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

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

 Трехстороннее рукопожатие TCP

Давайте подробнее рассмотрим TCP-пакеты, которые отправляются при каждом соединении.

Изначально и клиент, и сервер ЗАКРЫТЫ. Во-первых, сервер активно прослушивает порт и находится в состоянии LISTEN, а это означает, что сервер необходимо запустить. Далее клиент готов начать доступ к веб-странице. Ему необходимо установить соединение с сервером. Формат первого пакета подключения следующий:

 SYN-пакет

Когда клиент инициирует соединение, он генерирует случайный начальный порядковый номер (client_isn) и помещает его в поле «Порядковый номер» заголовка TCP. В то же время клиент устанавливает положение флага SYN на 1, чтобы указать, что исходящий пакет является пакетом SYN. Клиент указывает, что желает установить соединение с сервером, отправляя на сервер первый пакет SYN. Этот пакет не содержит данных прикладного уровня (то есть отправленных данных). На этом этапе статус клиента отмечается как SYN-SENT.

Пакет SYN+ACK

Когда сервер получает пакет SYN от клиента, он случайным образом инициализирует свой серийный номер (server_isn), а затем помещает этот номер в поле «Серийный номер» заголовка TCP. Затем сервер вводит client_isn + 1 в поле «Номер подтверждения» и устанавливает биты SYN и ACK в 1. Наконец, сервер отправляет клиенту пакет, который не содержит никаких данных прикладного уровня (и никаких данных для сервера). отправить). В это время сервер находится в состоянии SYN-RCVD.

Пакет подтверждения

Как только клиент получает пакет от сервера, ему необходимо выполнить следующие оптимизации для ответа на окончательный ответный пакет: во-первых, клиент устанавливает бит ACK заголовка TCP ответного пакета на 1; Во-вторых, клиент вводит значение server_isn + 1 в поле «Подтвердить номер ответа»; Наконец, клиент отправляет пакет на сервер. Этот пакет может переносить данные от клиента к серверу. По завершении этих операций клиент перейдет в состояние ESTABLISHED.

Как только сервер получает ответный пакет от клиента, он также переключается в состояние ESTABLISHED.

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

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

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

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

трехстороннее рукопожатие позволяет избежать исторических дублирующих соединений

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

1. Старые пакеты SYN поступают на сервер раньше последних пакетов SYN.
2- Сервер ответит клиенту пакет SYN + ACK после получения старого пакета SYN.
3. Когда клиент получает пакет SYN + ACK, он определяет, что соединение является историческим соединением (истек порядковый номер или тайм-аут) в соответствии со своим собственным контекстом, а затем отправляет пакет RST на сервер, чтобы прервать соединение.

При соединении с двумя рукопожатиями невозможно определить, является ли текущее соединение историческим. Трехстороннее рукопожатие позволяет клиенту определить, является ли текущее соединение историческим соединением, на основе контекста, когда он готов отправить третий пакет:

1. Если это историческое соединение (истек порядковый номер или тайм-аут), пакет, отправленный при третьем рукопожатии, является пакетом RST для прерывания исторического соединения.
2. Если это не историческое соединение, пакет, отправленный в третий раз, является пакетом ACK, и две взаимодействующие стороны успешно устанавливают соединение.

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

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

Приемник может исключить дублирование данных и обеспечить точность данных.

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

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

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

Синхронизируйте исходные серийные номера обеих сторон.

Хотя четырехэтапное рукопожатие также возможно для надежной синхронизации исходных порядковых номеров обеих сторон, второй и третий этапы можно объединить в один этап, в результате чего получится трехэтапное рукопожатие. Однако два рукопожатия могут гарантировать только то, что начальный порядковый номер одной стороны успешно получен другой стороной, но нет никакой гарантии, что начальный порядковый номер обеих сторон может быть подтвержден. Таким образом, трехстороннее рукопожатие — лучший выбор для обеспечения стабильности и надежности TCP-соединений.

Причина 3: избегайте напрасной траты ресурсов
Если используется только «двойное рукопожатие», когда запрос SYN клиента блокируется в сети, клиент не может получить пакет ACK, отправленный сервером, поэтому SYN будет отправлен повторно. Однако, поскольку третьего рукопожатия нет, сервер не может определить, получил ли клиент подтверждение ACK для установления соединения. Таким образом, сервер может заранее установить соединение только после получения каждого запроса SYN. Это приводит к следующему:

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

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

Избегайте пустой траты ресурсов

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

Краткое содержание
Брокер сетевых пакетовУстановление TCP-соединения осуществляется с помощью трехэтапного рукопожатия. Во время трехстороннего рукопожатия клиент сначала отправляет серверу пакет с флагом SYN, указывающий, что он хочет установить соединение. После получения запроса от клиента сервер отвечает клиенту пакетом с флагами SYN и ACK, указывая, что запрос на соединение принят, и отправляет свой собственный начальный порядковый номер. Наконец, клиент отправляет серверу флаг ACK, указывающий, что соединение успешно установлено. Таким образом, две стороны находятся в состоянии ESTABLISHED и могут начать отправлять данные друг другу.

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


Время публикации: 08 января 2025 г.