Обмен данными по TCP
В некоторых странах при встрече двух человек принято обмениваться рукопожатиями. Рукопожатие рассматривается обеими сторонами как сигнал для дружеского приветствия. Подключения в сети осуществляются примерно так же. При первом рукопожатии (на компьютерном языке это называется рукопожатием) отправляется запрос синхронизации. При втором рукопожатии первоначальный запрос синхронизации подтверждается, после чего согласовываются параметры подключения в противоположном направлении. Третий этап рукопожатия — это подтверждение, которое используется для информирования узла назначения о том, что обе стороны согласны установить подключение.
Если два узла взаимодействуют с использованием протокола TCP, соединение устанавливается до того, как обмен данными будет возможен. По завершении обмена данными все сеансы прекращаются, а соединение прерывается. Механизмы подключения и осуществления сеанса связи включают в себя функции TCP, обеспечивающие надёжность. На рисунке показаны этапы установления и прекращения TCP-соединения.
Узлы отслеживают каждый сегмент данных, передаваемых во время сеанса, и обмениваются информацией о полученных данных с использованием сведений в заголовке TCP. TCP — это полнодуплексный протокол, в котором каждое соединение представляет два односторонних потока обмена данными, или сеанса. Для установления связи узлы используют трёхстороннее рукопожатие. Биты управления в заголовке TCP обозначают этап и состояние подключения. При трёхстороннем рукопожатии выполняются следующие процессы.
- Сначала устанавливается, присутствует ли устройство назначения в сети.
- Затем проверяется, имеется ли на устройстве назначения активный сервис и принимает ли он запросы на номер порта назначения, который инициирующий клиент планирует использовать для сеанса.
- Далее устройству назначения сообщается, что клиент источника планирует установить сеанс связи на этом номере порта.
При подключениях по протоколу TCP клиент узла устанавливает связь с сервером. Ниже перечислены три шага для установления TCP-соединения.
Шаг 1. Инициирующий клиент запрашивает сеанс связи клиент-сервер с сервером.
Шаг 2. Сервер подтверждает сеанс связи клиент-сервер и запрашивает сеанс связи сервер-клиент.
Шаг 3. Инициирующий клиент подтверждает сеанс связи сервер-клиент.
Используйте кнопки 1—3 на рисунке, чтобы просмотреть процесс установки TCP-соединения.
Чтобы понять процесс трёхстороннего рукопожатия, посмотрите на различные значения данных, которыми обмениваются два узла. Заголовок сегмента TCP содержит шесть 1-битных полей с контрольной информацией, которая используется для управления процессами TCP. Эти поля приведены ниже.
- URG — поле «Указатель важности» задействовано
- ACK — поле «Номер подтверждения» задействовано
- RST — оборвать соединение
- SYN — синхронизировать порядковые номера
- FIN — больше нет данных от отправителя
Поля ACK и SYN имеют отношение к рассматриваемому анализу трёхстороннего рукопожатия.
Используя информацию, полученную с помощью программы анализа протоколов, например Wireshark, можно узнать, как осуществляется трёхстороннее рукопожатие TCP.
Шаг 1. Инициирующий клиент запрашивает сеанс связи клиент-сервер с сервером.
Клиент TCP начинает трёхстороннее рукопожатие путём отправки сегмента с установленным управляющим флагом SYN (синхронизировать порядковые номера), который обозначает начальное значение в поле номера последовательности в заголовке. Это значение последовательности, которое называется начальным порядковым номером (ISN), выбирается случайно и используется, чтобы начать отслеживание потока данных, которые пересылаются от клиента к серверу в этом сеансе. По мере продолжения сеанса обмена данными этот ISN-номер в заголовке каждого сегмента увеличивается на единицу для каждого байта данных, отправленного от клиента к серверу.
Как показано на рисунке, информация, предоставленная анализатором протоколов, содержит управляющий флаг SYN и относительный порядковый номер.
Управляющий флаг SYN установлен, а относительный порядковый номер равен 0. Несмотря на то, что анализатор протоколов на графике указывает относительные значения для порядкового номера и номера подтверждения, действительными значениями являются 32-битные двоичные номера. На рисунке показаны четыре байта, представленные в шестнадцатеричной системе исчисления.
Шаг 2. Сервер подтверждает сеанс связи клиент-сервер и запрашивает сеанс связи сервер-клиент.
Чтобы начать сеанс связи клиент-сервер, TCP-сервер должен подтвердить получение сегмента SYN от клиента. Для этого сервер возвращает сегмент клиенту с установленным флагом подтверждения (ACK), указывая на то, что номер подтверждения задействован. Если этот флаг в сегменте установлен, клиент считает это подтверждением того, что сервер получил SYN от клиента TCP.
Значение в поле номера подтверждения равно номеру ISN плюс 1. Это позволяет установить сеанс связи клиент-сервер. Для обеспечения сбалансированности сеанса флаг ACK остаётся установленным. Следует помнить, что сеанс связи между клиентом и сервером фактически представляет собой два односторонних сеанса: один клиент-сервер, другой — сервер-клиент. На втором шаге трёхстороннего рукопожатия сервер должен инициировать ответ клиенту. Чтобы начать этот сеанс, сервер использует флаг SYN точно так же, как это делал клиент. Он устанавливает управляющий флаг SYN в заголовке для установления сеанса типа сервер-клиент. Флаг SYN указывает на то, что начальное значение поля порядкового номера указано в заголовке. Это значение используется для отслеживания в этом сеансе потока данных от сервера к клиенту.
Как показано на рисунке, информация анализатора протоколов указывает на то, что управляющие флаги ACK и SYN установлены, а последовательный номер и номер подтверждения — отображаются.
Шаг 3. Инициирующий клиент подтверждает сеанс связи сервер-клиент.
Наконец, клиент TCP возвращает сегмент, содержащий ACK, — то есть ответ на TCP SYN, отправленный сервером. Пользовательские данные в этом сегменте отсутствуют. Значение в поле номера подтверждения на единицу больше, чем номер ISN, полученный от сервера. После того как между клиентом и сервером будут начаты оба сеанса, для всех дополнительных сегментов, которые пересылаются в этом процессе обмена данными, будут установлены флаги ACK.
Как показано на рисунке, информация анализатора протоколов отображает установленный управляющий флаг ACK, а также последовательный номер и номер подтверждения.
Для обеспечения дополнительной безопасности в сети передачи данных можно выполнить следующие процедуры.
- Отказ от установления TCP-сеансов
- Разрешение сеансов только для определённых сервисов
- Допуск трафика только в рамках уже установленных сеансов
Эти меры по обеспечению безопасности можно использовать как для всех, так и только для выбранных TCP-сеансов.
Для прекращения соединения в заголовке сегмента должен быть установлен управляющий флаг Finish (FIN). Для завершения каждого одностороннего TCP-сеанса используется двухстороннее рукопожатие, которое состоит из сегмента FIN и сегмента ACK. Следовательно, чтобы завершить один сеанс связи, поддерживаемый протоколом TCP, необходимы четыре обмена данными, которые завершат оба сеанса, как показано на рис. 1.
Примечание. В данной трактовке понятия «клиент» и «сервер» используются в качестве справки для облегчения понимания, но процесс завершения связи может быть инициирован любым из двух узлов с открытым сеансом.
Шаг 1. Когда у клиента больше нет данных для отправки в потоке, он отправляет сегмент с установленным флагом FIN.
Шаг 2. Сервер отправляет ACK, чтобы подтвердить получение FIN для завершения сеанса клиент-сервер.
Шаг 3. Сервер отправляет FIN клиенту, чтобы завершить сеанс сервер-клиент.
Шаг 4. Клиент возвращает ACK для подтверждения получения FIN от сервера.
Когда у клиента больше нет данных для передачи, он устанавливает флаг FIN в заголовке сегмента. Затем серверная часть соединения отправляет нормальный сегмент, содержащий данные, с установленным флагом ACK; при этом она использует номер подтверждения, который гарантирует получение всех байтов данных. После подтверждения всех сегментов сеанс закрывается.
На противоположном конце соединения сеанс прекращается таким же способом. Получатель указывает, что данных для отправки больше нет, установив флаг FIN в заголовке сегмента, отправленного источнику. Ответное подтверждение служит доказательством получения всех байтов данных, и этот сеанс, в свою очередь, закрывается.
На рис. 2 и 3 показано, что управляющие флаги FIN и ACK установлены в заголовке сегмента, закрывая таким образом HTTP-сеанс.
Соединение можно также завершить с помощью трёхстороннего рукопожатия. Когда у клиента больше нет данных для отправки, он передаёт FIN серверу. Если у сервера также нет данных для отправки, он может в ответ переслать сегменты с установленными флагами FIN и ACK, объединяя два шага в один. В ответ клиент отправляет ACK.
Надёжность и управление потоком
Повторное упорядочивание сегментов
Когда сервисы отправляют данные по протоколу TCP, сегменты могут быть доставлены на узел назначения в изменённом порядке. Чтобы получатель смог расшифровать изначальное сообщение, данные в этих сегментах повторно собираются в исходном порядке. Для этого в заголовке каждого пакета указываются порядковые номера.
Во время настройки сеанса связи устанавливается начальный порядковый номер сеанса (ISN). Этот номер ISN представляет начальное значение байтов для этого сеанса, которое передаётся получающему приложению. По мере передачи данных во время сеанса порядковый номер увеличивается на число переданных байт. Такое отслеживание байтов данных позволяет однозначно определять и подтверждать каждый сегмент. Можно выяснить, какие сегменты отсутствуют.
Порядковые номера сегментов обеспечивают надёжность, указывая, как необходимо повторно собрать и переупорядочить полученные сегменты, как показано на рисунке.
Получающий TCP-процесс помещает данные из сегмента в получающий буфер. Сегменты располагаются в соответствии с порядковыми номерами и после повторной сборки передаются на уровень приложений. Все сегменты, которые поступают с несоответствующими порядковыми номерами, сохраняются для последующей обработки. Затем, поступая с отсутствующими байтами, сегменты обрабатываются по порядку.
Подтверждение получения сегментов
Одной из функциональных особенностей протокола TCP является гарантия доставки каждого сегмента по назначению. Сервисы TCP на узле назначения подтверждают данные, полученные им от приложения источника.
Порядковый номер (SEQ) и номер подтверждения (ACK) используются совместно для подтверждения получения байтов данных, которые содержатся в переданных сегментах. Порядковый номер SEQ обозначает относительное число байтов, переданных во время этого сеанса, включая байты в текущем сегменте. TCP использует номер ACK, отправленный обратно источнику, чтобы обозначить следующий байт, который получатель рассчитывает получить. Это называется ожидаемым подтверждением.
Источнику сообщается, что узел назначения получил все данные в этом потоке до того байта (но не включая его), который обозначен номером ACK. Предполагается, что передающий узел отправит сегмент, в котором используется порядковый номер, равный номеру ACK.
Необходимо помнить, что каждое соединение фактически представляет собой два односторонних сеанса. Обмен номерами SEQ и ACK осуществляется в обоих направлениях.
В примере, показанном на рисунке, узел слева отправляет данные узлу справа. Он отправляет сегмент, который содержит 10 байт данных для этого сеанса, и порядковый номер, равный 1, в заголовке.
Получающий узел принимает сегмент на 4-м уровне и определяет, что порядковый номер равен 1, а также то, что сегмент содержит 10 байт данных. Затем узел отправляет сегмент обратно узлу слева, чтобы подтвердить получение этих данных. В этом сегменте узел устанавливает 11 в качестве номера ACK, чтобы показать, что в этом сеансе следующим байтом данных он ожидает получить байт с номером 11. Когда передающий узел получает это подтверждение, он может отправить следующий сегмент, содержащий данные для этого сеанса, которые начинаются с байта номер 11.
Из этого примера видно, что если бы отправляющему узлу пришлось ждать подтверждения каждых 10 байт, это создало бы значительную нагрузку на сеть. Чтобы снизить нагрузку, связанную с получением этих подтверждений, несколько сегментов данных можно отправить и подтвердить в одном сообщении TCP, отправленном в противоположном направлении. Это подтверждение содержит номер ACK, который указывается исходя из общего количества байтов, полученных в течение сеанса связи. Например, начиная с порядкового номера 2000 (если было получено 10 сегментов из каждых 1000 байт) источнику должен быть отправлен ACK с номером 12001.
Количество данных, которое может быть передано до получения подтверждения, называется размером окна. Размер окна — это поле в заголовке TCP, с помощью которого можно обрабатывать утраченные данные и управлять потоками.
Обработка потерь сегментов
Как бы хорошо ни была организована сеть, в ней время от времени случаются потери данных; по этой причине протокол TCP предусматривает способы управления этими потерями сегментов. Среди них — механизм для повторной передачи сегментов с неподтвержденными данными.
Сервис узла назначения, использующая протокол TCP, обычно подтверждает только данные, поступившие в непрерывной последовательности. В случае отсутствия одного или нескольких сегментов подтверждаются только данные в первой непрерывной последовательности байтов. Например, если были получены сегменты с порядковыми номерами от 1500 до 3000 и от 3400 до 3500, номером ACK будет 3001. Это связано с тем, что имеются сегменты с номерами SEQ от 3001 до 3399, которые не были получены.
Если TCP на узле источника не получит подтверждение по истечении установленного периода времени, он вернется к последнему полученному номеру ACK и повторно перешлёт данные из этой точки. Процесс повторной передачи не указывается в запросе комментариев (RFC), а оставляется до момента конкретной реализации протокола TCP.
При типичной реализации протокола TCP узел может переслать сегмент, поместить копию сегмента в очередь для повторной передачи и запустить таймер. После получения подтверждения данных сегмент удаляется из очереди. Если подтверждение не поступает до истечения времени таймера, сегмент пересылается повторно.
Нажмите кнопку «Воспроизведение» на рисунке, чтобы просмотреть анимированное представление повторной передачи потерянных сегментов.
В настоящее время узлы могут также использовать дополнительную функцию, которая называется выборочным подтверждением (SACK). Если оба узла поддерживают выборочные подтверждения, адресат может подтвердить байты в прерывающихся сегментах, в результате чего узел должен будет повторить передачу только недостающих данных.
Управление потоком
Протокол TCP также обеспечивает механизмы для управления потоком данных. Управление потоком позволяет поддерживать надёжность передачи по протоколу TCP путём регулировки скорости потока данных между узлами источника и направления в течение определённого сеанса. Управление потоком осуществляется путём ограничения количества сегментов данных, передаваемых за один раз, а также запроса подтверждений получения до отправки следующих сегментов.
Для управления потоком TCP в первую очередь определяет количество сегментов данных, которое может принять устройство назначения. Заголовок TCP включает в себя 16-битное поле, которое называется размером окна. Это количество байтов, которое устройство назначения сеанса TCP способно принять и обработать единовременно. Исходный размер окна согласовывается во время запуска сеанса через трёхстороннее рукопожатие между устройствами источника и назначения. После согласования исходное устройство должно ограничить количество сегментов данных, отправленных устройству назначения, в соответствии с размером окна. Только после того как исходное устройство получит подтверждение того, что сегменты данных получены, оно может продолжить отправку остальных данных в этом сеансе.
Во время задержки в получении подтверждения отправитель не отправляет дополнительных сегментов. В те периоды, когда сеть чрезвычайно загружена или ресурсы получающего узла на пределе, длительность задержки может увеличиться. По мере увеличения длительности задержки эффективная скорость передачи данных для этого сеанса снижается. Замедление передачи данных при каждом сеансе помогает уменьшить конфликт ресурсов на сетевом устройстве и устройстве назначения в случае запуска нескольких сеансов связи.
Упрощённое представление размера окна и подтверждений представлены на рисунке. В этом примере первоначальный размер окна для представленного сеанса TCP установлен как 3000 байт. Когда отправитель передаст 3000 байт, он ожидает подтверждения их получения перед передачей оставшихся сегментов в этом сеансе. После того как отправитель получит подтверждение от получателя, отправитель сможет передать дополнительные 3000 байт.
Протокол TCP использует размер окна, чтобы попытаться управлять скоростью передачи данных в соответствии с максимальным значением потока, которое поддерживается сетью и устройством назначения, одновременно с этим уменьшая потери данных и количество их повторных пересылок
Уменьшение размера окна
Ещё одним способом управления потоком данных является использование динамических размеров окон. Когда сетевые ресурсы ограничены, TCP может уменьшить размер окна, чтобы потребовать более частого подтверждения получения сегментов. Это позволяет эффективно снизить скорость передачи данных, поскольку источник чаще ожидает подтверждения их получения.
Принимающий узел отсылает значение размера окна на отправляющий узел, чтобы указать количество байтов, которое он готов принять. Если узлу назначения необходимо снизить скорость передачи данных из-за ограниченной памяти буфера, он может, например, пересылать узлу источника меньшее значение размера окна как часть подтверждения.
Как показано на рисунке, если на принимающем узле наблюдается перегрузка, он может ответить отправляющему узлу, переслав сегмент, который указывает меньший размер окна. На этом рисунке видно, что один из сегментов был потерян. В этом сеансе связи получатель уменьшил поле окна в заголовке TCP возвращаемых сегментов с 3000 до 1500, вследствие чего отправителю пришлось изменить размер окна 1500.
После периода передачи данных без потерь или ограничения ресурсов получатель начинает увеличивать поле окна, что уменьшает нагрузку на сеть, поскольку требуется отправка меньшего количества подтверждений. Размер окна продолжает увеличиваться до тех пор, пока не начнутся потери данных, в результате чего размер окна будет уменьшаться.
Этот динамический процесс увеличения и уменьшения размера окна в протоколе TCP происходит постоянно. В высокопроизводительных сетях размеры окон могут быть очень большими, поскольку потери данных отсутствуют. В сетях, в которых базовая инфраструктура находится под нагрузкой, размер окна, скорее всего, остается небольшим.
