⚡ Ќовый онлайн курс по —етевым “ехнологи€м

до запуска осталось

ћерион Ќетворкс

7 минут чтени€

ѕредыдуща€ стать€ из цикла про попул€рные приложени€ TCP/IP тут.

”становление TCP-соединени€ происходит до того, как люба€ из других функций TCP сможет начать свою работу. ”становление соединени€ относитс€ к процессу инициализации полей "Sequence" и "Acknowledgment" и согласовани€ используемых номеров портов. Ќа рисунке 5 показан пример процесса установлени€ соединени€.

”становление TCP-соединени€

Ётот трехсторонний процесс установлени€ соединени€ (также называемый трехсторонним рукопожатием) должен завершитьс€ до начала передачи данных. —оединение существует между двум€ сокетами, хот€ в заголовке TCP нет единственного пол€ сокета. »з трех частей сокета подразумеваютс€ IP-адреса на основе IP-адресов источника и назначени€ в IP-заголовке. TCP подразумеваетс€, потому что используетс€ заголовок TCP, как указано значением пол€ протокола в заголовке IP. —ледовательно, единственные части сокета, которые необходимо закодировать в заголовке TCP, - это номера портов.

TCP сообщает об установлении соединени€, использу€ 2 бита в пол€х флагов заголовка TCP. Ёти биты, называемые флагами SYN и ACK, имеют особенно интересное значение. SYN означает "синхронизировать пор€дковые номера", что €вл€етс€ одним из необходимых компонентов при инициализации TCP.

Ќа рисунке 6 показано завершение TCP-соединени€. Ёта четырехсторонн€€ последовательность завершени€ проста и использует дополнительный флаг, называемый битом FIN. (FIN - это сокращение от "finished", как вы могли догадатьс€.) ќдно интересное замечание: перед тем, как устройство справа отправит третий сегмент TCP в последовательности, оно уведомл€ет приложение о том, что соединение прерываетс€. «атем он ожидает подтверждени€ от приложени€ перед отправкой третьего сегмента на рисунке. Ќа случай, если приложению потребуетс€ некоторое врем€, чтобы ответить, ѕ  справа отправл€ет второй поток на рисунке, подтвержда€, что другой ѕ  хочет разорвать соединение. ¬ противном случае ѕ  слева может повторно отправить первый сегмент.

«авершение TCP-соединени€

TCP устанавливает и завершает соединени€ между конечными точками, а UDP - нет. ћногие протоколы работают в рамках одних и тех же концепций, поэтому термины "ориентированный на соединение" и "без установлени€ соединени€" используютс€ дл€ обозначени€ общей идеи каждого из них. Ѕолее формально эти термины можно определить следующим образом:

  • ѕротокол, ориентированный на соединение: протокол, который требует обмена сообщени€ми до начала передачи данных или который имеет требуемую предварительно установленную коррел€цию между двум€ конечными точками.
  • ѕротокол без установлени€ соединени€: протокол, который не требует обмена сообщени€ми и не требует предварительно установленной коррел€ции между двум€ конечными точками.

¬осстановление после ошибок и надежность

TCP обеспечивает надежную передачу данных, что также называетс€ reliability or error recovery. ƒл€ обеспечени€ надежности TCP нумерует байты данных, использу€ пол€ "Sequence" и "Acknowledgment" в заголовке TCP. TCP обеспечивает надежность в обоих направлени€х, использу€ поле Sequence Number одного направлени€ в сочетании с полем Acknowledgment в противоположном направлении.

Ќа рисунке 7 показан пример того, как пол€ TCP Sequence и Acknowledgment позвол€ют ѕ  отправл€ть 3000 байтов данных на сервер, при этом сервер подтверждает получение данных. —егменты TCP на рисунке расположены по пор€дку, сверху вниз. ƒл€ простоты все сообщени€ содержат 1000 байтов данных в части данных сегмента TCP. ѕервый пор€дковый номер - красивое круглое число (1000), оп€ть же дл€ простоты. ¬ верхней части рисунка показаны три сегмента, каждый из которых на 1000 больше предыдущего, что указывает на первый из 1000 байтов сообщени€. (“о есть в этом примере первый сегмент содержит байты 10001999; второй - байты 20002999, а третий - байты 30003999.)

ѕодтверждение TCP без ошибок

„етвертый сегмент TCP на рисунке - единственный, который возвращаетс€ от сервера к веб-браузеру - подтверждает получение всех трех сегментов.  ак? «начение подтверждени€ 4000 означает: "я получил все данные с пор€дковыми номерами на единицу меньше 4000, поэтому € готов прин€ть ваш байт 4000 следующим". (ќбратите внимание, что это соглашение о подтверждении путем перечислени€ следующего ожидаемого байта, а не номера последнего полученного байта, называетс€ пр€мым подтверждением.)

ќднако этот пример не исправл€ет никаких ошибок; он просто показывает основы того, как хост-отправитель использует поле пор€дкового номера дл€ идентификации данных, а хост-получатель использует пр€мые подтверждени€ дл€ подтверждени€ данных. Ѕолее интересное обсуждение вращаетс€ вокруг того, как использовать эти же инструменты дл€ восстановлени€ ошибок. TCP использует пол€ "Sequence" и "Acknowledgment", чтобы принимающий хост мог заметить потерю данных, попросить отправл€ющий хост повторно отправить, а затем подтвердить, что повторно отправленные данные прибыли.

—уществует множество вариантов того, как TCP выполн€ет исправление ошибок. Ќа рисунке 8 показан только один такой пример, детализаци€ которого аналогична предыдущему. ¬еб-браузер снова отправл€ет три сегмента TCP, снова по 1000 байт каждый, снова с легко запоминающимис€ пор€дковыми номерами. ќднако в этом примере второй сегмент TCP не может пройти через сеть.

ѕодтверждение TCP с ошибками

–исунок указывает на три набора идей, лежащих в основе того, как думают два хоз€ина. ¬о-первых, справа сервер понимает, что он не получил все данные. ƒва полученных сегмента TCP содержат байты с номерами 10001999 и 30003999. ќчевидно, сервер не получил байты, пронумерованные между ними. «атем сервер решает подтвердить все данные вплоть до потер€нных, то есть отправить обратно сегмент с полем подтверждени€, равным 2000.

ѕолучение подтверждени€, которое не подтверждает все данные, отправленные на данный момент, заставл€ет хост-отправитель повторно отправить данные. ѕ  слева может подождать несколько секунд, чтобы убедитьс€, что другие подтверждени€ не поступ€т (использу€ таймер, называемый таймером повторной передачи), но вскоре решит, что сервер сообщает: "ћне действительно нужно 2000 - отправьте его повторно". ѕ  слева делает это, как показано на п€том из шести сегментов TCP на рисунке.

Ќаконец, обратите внимание, что сервер может подтверждать не только повторно отправленные данные, но и любые предыдущие данные, которые были получены правильно. ¬ этом случае сервер получил повторно отправленный второй сегмент TCP (данные с пор€дковыми номерами 20002999), и сервер уже получил третий сегмент TCP (данные с номерами 30003999). —ледующее поле подтверждени€ сервера подтверждает данные в обоих этих сегментах с полем подтверждени€, равным 4000.


”правление потоком с использованием окон

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

ћеханизм раздвижного окна имеет больше смысла на примере. ¬ примере, показанном на рисунке 9, используютс€ те же основные правила, что и в примерах на нескольких предыдущих рисунках. ¬ этом случае ни один из сегментов TCP не содержит ошибок, и обсуждение начинаетс€ на один сегмент TCP раньше, чем на предыдущих двух рисунках.

TCP Windowing

Ќачнем с первого сегмента, отправленного сервером на ѕ . ѕоле Acknowledgment должно быть вам знакомо: оно сообщает ѕ , что сервер ожидает следующий сегмент с пор€дковым номером 1000. Ќовое поле, поле окна, установлено на 3000. ѕоскольку сегмент передаетс€ на ѕ , это значение сообщает ѕ , что ѕ  может послать не более 3000 байтов по этому соединению до получени€ подтверждени€. »так, как показано слева, ѕ  понимает, что может отправл€ть только 3000 байтов, и прекращает отправку, ожида€ подтверждени€, после отправки трех 1000-байтовых сегментов TCP.

ѕродолжа€ пример, сервер не только подтверждает получение данных (без потерь), но и решает немного увеличить размер окна. ќбратите внимание, что второе сообщение, идущее справа налево на рисунке, на этот раз с окном 4000.  ак только ѕ  получает этот сегмент TCP, ѕ  понимает, что он может отправить еще 4000 байтов (окно немного больше, чем предыдущее значение).

ќбратите внимание, что хот€ на последних нескольких рисунках показаны примеры с целью объ€снени€ того, как работают механизмы, из этих примеров может сложитьс€ впечатление, что TCP заставл€ет хосты сидеть и долго ждать подтверждени€. TCP не хочет заставл€ть хост-отправитель ждать отправки данных. Ќапример, если подтверждение получено до того, как окно будет исчерпано, начинаетс€ новое окно, и отправитель продолжает отправл€ть данные до тех пор, пока текущее окно не будет исчерпано. „асто в сети, где мало проблем, мало потер€нных сегментов и небольша€ перегрузка, окна TCP остаютс€ относительно большими, а узлы редко ждут отправки.

«акрепим самое важное про TCP и UDP в следующей статье.


>