Linux API. Исчерпывающее руководство

Для реализации надежного обмена данными протокол TCP использует положительные подтверждения. То есть, когда сегмент успешно принят, получатель отсылает отправителю сообщение с подтверждением (сегмент с установленным битом ACK), как показано на рис. 57.3. Поле с номером подтверждения в этом сообщении содержит логический порядковый номер байта, следующего за данными, которые принимающая сторона надеется получить (иными словами, номер подтверждения ровно на 1 больше порядкового номера последнего байта в сегменте, передающем подтверждение).

Рис. 57.3.Подтверждения в протоколе TCP

Когда отправляющая сторона передает сегмент, она устанавливает таймер. Если по истечении времени ожидания подтверждение все еще не получено, сегмент отправляется заново.

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

57.6.3. Машина состояний и диаграмма перехода состояний в протоколе TCP

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

• LISTEN — сокет ожидает запрос на соединение со стороны удаленного клиента.

• SYN_SENT — сокет отправил от имени приложения, выполняющего активное открытие, сегмент с байтом SYN и теперь ждет ответа от удаленной стороны, чтобы завершить установку соединения.

• SYN_RECV — сокет, ранее пребывавший в состоянии LISTEN, принял байт SYN, послал в ответ SYN/ACK (то есть сегмент с установленными байтами SYN и ACK) и теперь ждет от удаленного сокета подтверждения, чтобы завершить установку соединения.

• ESTABLISHED — установка соединения с удаленным сокетом завершилась. Теперь можно передавать сегменты с данными в любом направлении.

• FIN_WAIT1 — приложение закрыло соединение. Сокет послал удаленной стороне байт FIN, чтобы прекратить взаимодействие, и теперь ждет подтверждения (бит ACK). Это и следующие три состояния относятся к приложению, выполняющему активное закрытие, — тому, которое первым разрывает соединение на своем конце.

• FIN_WAIT2 — сокет, ранее пребывавший в состоянии FIN_WAIT1, получил подтверждение от удаленной стороны.

• CLOSING — сокет, ранее ожидавший подтверждения в состоянии FIN_WAIT1, получил вместо этого бит FIN, сигнализирующий о том, что удаленная сторона тоже в данный момент пыталась выполнить активное закрытие (иными словами, оба конца TCP-соединения почти одновременно послали друг другу сегменты с битом FIN; такое бывает редко).

• TIME_WAIT — выполнив активное закрытие, сокет получил бит FIN, сигнализирующий о том, что удаленная сторона уже завершила пассивное закрытие. Теперь данный сокет должен провести определенное время в состоянии TIME_WAIT, чтобы гарантировать разрыв TCP-соединения и обеспечить истечение срока годности старых дублирующих сегментов в сети перед созданием нового экземпляра того же соединения (более подробно состояние TIME_WAIT рассматривается в подразделе 57.6.7). По завершении этого времени соединение закрывается, а связанные с ним ресурсы ядра освобождаются.

• CLOSE_WAIT — сокет получил от удаленной стороны байт FIN. Это и следующее состояния относятся к приложению, выполняющему пассивное закрытие, то есть ко второму приложению, закрывающему соединение.

• LAST_ACK — приложение выполнило пассивное закрытие, а сокет, ранее пребывавший в состоянии CLOSE_WAIT, послал удаленной стороне бит FIN и теперь ждет, когда та передаст подтверждение. Получив бит ACK, сокет закрывает соединение и освобождает связанные с собой ресурсы ядра.

Помимо описанных выше состояний документ RFC 793 предусматривает еще одно, фиктивное. Оно называется CLOSED и описывает ситуацию, когда соединения нет (то есть для поддержания TCP-соединения ядро не выделило никаких ресурсов).

В списке, приведенном выше, используются названия констант, определенных в исходном коде Linux. Они немного отличаются от названий, описанных в RFC 793.