Модуль TCP

Модуль TCP

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

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

Для обеспечения передачи данных используются два таймера. Первый из них — таймер повторной передачи (retransmit timer). Этот таймер запускается при передаче сегмента, если он уже не был запущен. Если подтверждение получено, и отсутствуют неподтвержденные данные — таймер останавливается. Если же такие данные существуют, значение таймера присваивается равным начальному, и таймер запускается снова. Если значение таймера становится равным нулю, наиболее старые неподтвержденные данные передаются повторно (как минимум один полный сегмент), а таймер запускается снова, но уже с большим значением. Скорость увеличения значения таймера (timer backoff) определяется по специальной таблице и имеет экспоненциальный характер.

Второй таймер — это persist-таймер (таймер сохранения). Этот таймер обеспечивает защиту от потери управляющих сообщений, содержащих значения окна. В случае, если отправитель готов передать данные, но анонсированное получателем окно слишком мало (равно нулю или меньше определенного значения), и отсутствуют неподтвержденные данные (т. е. таймер повторной передачи не включен), включается таймер сохранения. Если таймер срабатывает (его значение становится равным нулю), а обновленное значение так и не получено, отправитель передает максимально допустимый объем данных, определяемый текущим окном. Если же в этом случае значение текущего окна равно нулю (нулевое окно), то передается пробный сегмент (window probe), содержащий один октет данных, и таймер запускается снова. Если сообщение с обновленным значением окна было утеряно, или получатель по-прежнему отказывается изменить его размер, будет получено подтверждение, содержащее текущее значение окна. Такая ситуация, когда получатель не может принимать дополнительные данные, может продлиться достаточно долго. Например, пользователь может приостановить терминальный вывод и уйти на обед. В этом случае отправитель будет периодически посылать пробные сегменты, а его окно будет по-прежнему закрыто.

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

Последний таймер из рассматриваемых, это 2MSL-таймер (2MSL — двойное максимальное время жизни сегмента в сети). Модуль TCP запускает этот таймер, когда производится завершение связи, и уже отправлено подтверждение полученному сегменту FIN. При этом отправитель не знает, получено ли его подтверждение. Поэтому он некоторое время ждет возможного повторного получения сегмента FIN, чтобы в свою очередь повторить подтверждение. Таймер запускается при переходе коммуникационного узла канала в состояние TIME-WAIT, и после его срабатывания соответствующий управляющий блок удаляется. Заметим, что это ожидание не блокирует процесс, выполнивший системный вызов close(2) сокета, отвечающего за данный канал. Другими словами, управляющий блок может существовать еще некоторое время после закрытия дескриптора сокета.