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

Приложения, основанные на UDP, обычно не знают о размере MTU на маршруте между исходным и конечным узлами. Для обхода IP-фрагментации обычно выбирается консервативный подход, состоящий в выборе размера IP-датаграммы, не превышающего минимальный размер буфера сборки в IPv4, который равен 476 байтам (это значение, скорее всего, должно быть меньше MTU заданного маршрута). Восемь байт уходит на заголовок UDP, и еще минимум 20 нужно для IP-заголовка, что оставляет для самой UDP-датаграммы всего 548 байт. На практике многие приложения, основанные на UDP, выбирают для своих датаграмм еще более низкое ограничение — 512 байт (см. [Stevens, 1994]).

54.6.3. Протокол управления передачей (TCP)

Данный протокол предоставляет надежный двунаправленный канал взаимодействия двух точек (то есть приложений), основанный на соединении и реализованный в виде байтового потока (рис. 54.8). Для обеспечения всех этих возможностей протокол TCP должен выполнять действия, описанные в настоящем подразделе (подробное описание возможностей можно найти в книге [Stevens, 1994]).

Рис. 54.8.Сокеты, соединенные по TCP

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

Установка соединения

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

Упаковка данных в сегменты

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

Подтверждение, повторная передача и время ожидания

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

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

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

Порядок передачи

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

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

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

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

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