Тайм-ауты и повторные передачи TCP
         

T/TCP расширение TCP для транзакций



T/TCP: расширение TCP для транзакций

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

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

Необходимо избежать лишних действий при установлении и разрыве соединения. Когда это возможно, необходимо отправлять один пакет с запросом и получать один пакет с откликом. Латенсия должна быть уменьшена до RTT плюс SPT, где RTT это время возврата, а SPT это время необходимое серверу для обработки запроса. Сервер должен определять дублированные запросы и не повторять транзакцию, когда прибывает дублированный запрос. (Другими словами, сервер не обрабатывает запрос снова. Он должен послать назад сохраненный отклик, соответствующий запросу.)

Одно из рассмотренных нами приложение, использующее этот тип сервиса - система имен доменов (DNS, глава 14). Надо отметить, что DNS сервер не осуществляет повторную обработку дублированных запросов.

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

Оптимальное решение - это транспортный уровень, который включает в себя эффективную обработку транзакций. Протокол транзакций, который мы описываем в этом разделе, называется T/TCP. Протокол определен в RFC 1379 [Braden 1992b] и [Braden 1992c].

Для большинства TCP реализаций требуются 7 сегментов, чтобы открыть и закрыть соединение (см. рисунок 18.13). Здесь добавляются еще три сегмента: один с запросом, другой с откликом и подтверждением на запрос и третий с подтверждением на отклик. Если в сегменты добавлены дополнительные управляющие биты - а именно, первый сегмент содержит SYN, запрос клиента, и FIN - клиенту все кажется, что имеют место лишние действия, которые выражается в виде удвоенного значения RTT плюс SPT. (Отправка SYN вместе с данными и FIN разрешена; сможет ли TCP обработать подобную ситуацию корректно - это уже другой вопрос.)

Еще одна проблема с TCP это состояние TIME_WAIT, которое требует ожидания в течение 2MSL. Как показано в упражнении 14 главы 18, это ограничивает скорость транзакций между двумя хостами на величине примерно 268 в секунду.

Две модификации, необходимые для TCP, чтобы обрабатывать транзакции, заключаются в том, чтобы избежать трехразового рукопожатия и сократить состояние TIME_WAIT. T/TCP избегает трехразового рукопожатия с использованием ускоренного открытия:

T/TCP назначает каждому соединению номер в соответствии с 32-битным счетчиком соединений (CC - connection count), вне зависимости от того, осуществляется ли активное или пассивное открытие. Значение CC хоста назначается из общего счетчика, который увеличивается на единицу при каждом его использовании. Каждый сегмент между двумя хостами, использующими T/TCP, включает новую TCP опцию, которая называется CC. Эта опция имеет длину 6 байт и содержит 32-битное значение CC отправителя для соединения. Хост имеет кэш для каждого хоста, с которым был осуществлен обмен. В кэше содержится значение CC из последнего полученного от этого хоста сегмента SYN. Когда опция CC получена в исходном SYN, получатель сравнивает значение с сохраненным значением для этого отправителя. Если полученное CC больше чем кэшированное CC, SYN новый, и любые данные, находящиеся в сегменте, передаются принимающему приложению (серверу). Соединение называется наполовину синхронизированным. Если полученное CC не больше чем кэшированное CC, или если принимающий хост не имеет кэшированного CC для этого клиента, осуществляется стандартное трехразовое рукопожатие TCP. SYN, ACK сегмент в отклике на первоначальный SYN, отражает эхом полученное значение CC в другой новой опции, которая называется CC эхо или CCECHO. С помощью значения CC в сегментах, не содержащих SYN, определяются и отбрасываются любые дублированные сегменты от предыдущих воплощений того же самого соединения.

Благодаря ускоренному открытию отпадает необходимость в трехразовом рукопожатии, за исключением того случая когда оба, и клиент, и сервер, вышли из строя и перезагрузились. Однако мы платим за это тем, что сервер должен помнить последний полученный CC от каждого клиента.

Состояние TIME_WAIT становится короче, потому что расчет задержки TIME_WAIT осуществляется динамически, на основании измеренного RTT между двумя хостами. Задержка TIME_WAIT устанавливается в RTO умноженное на 8 (RTO - значение тайм-аута повторной передачи, глава 21, раздел "Определение времени возврата").

С использованием этих характеристик, минимальная последовательность транзакций заключается в обмене тремя сегментами:

От клиента к серверу, осуществляется при активном открытии: SYN-клиента, данные от клиента (запрос), FIN-клиента и CC-клиента. TCP сервер, осуществляющий пассивное открытие, получает эти сегменты и если CC-клиента больше чем кэшированный CC для этого клиента, данные клиента передаются приложению сервера, которое обрабатывает запрос. От сервера к клиенту: SYN-сервера, данные сервера (отклик), FIN-сервера, подтверждение на FIN-клиента, CC-сервера и CCECHO на CC-клиента. Так как подтверждения TCP - обобщающие, ACK на FIN-клиента подтверждает SYN-клиента, данные и FIN. Когда TCP клиент получает этот сегмент, он передает отклик приложению клиента. От клиента к серверу: ACK на FIN-сервера, который подтверждает SYN-сервера, данные и FIN.

Время отклика клиента на его запрос составляет RTT плюс SPT.



В реализации этой TCP опции существует множество особенностей, которые мы кратко рассмотрим:

  • ACK на SYN сервера (второй сегмент) должен быть задержан, чтобы позволить отклику передаваться вместе с ним. (Обычно ACK на SYN не задерживается.) Он не может быть задержан надолго, иначе клиент отработает тайм-аут и осуществит повторную передачу.
  • Запрос может состоять из нескольких сегментов, однако сервер должен предусмотреть вариант, когда данные приходят в беспорядке. (Обычно, когда данные прибывают перед SYN, они отбрасываются и генерируется сброс. В случае T/TCP данные, прибывшие в беспорядке, должны быть поставлены в очередь.)
  • API должен позволять процессу сервера отправлять данные и закрывать соединение с помощью одной операции, что позволит FIN во втором сегменте передаваться вместе с откликом. (Обычно приложение отправляет отклик, что вызывает отправку сегменту данных, а затем закрывает соединение, отправляя FIN.)
  • Клиент отправляет данные в первом сегменте перед получением объявления MSS от сервера. Чтобы не ограничивать клиента значением MSS равным 536, MSS для данного хоста должно быть кэшировано вместе с его значением CC.
  • Клиент отправляет данные серверу без получения объявления окна от сервера. T/TCP предоставляет окно по умолчанию равное 4096 байтам, а также кэширует порог переполнения для сервера.
  • В случае минимального обмена тремя сегментами может быть измерен только один RTT для каждого направления. RTT, измеренный клиентом, включает время, необходимое серверу для обработки запроса. Это означает, что хэшированное значение RTT и его отклонение также должны быть кэшированы для сервера; это напоминает то, что мы описали в разделе "Показатели на маршрут" главы 21.

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

Альтернативный протокол транзакций - VMTP, Versatile Message Transaction Protocol. Он описан в RFC 1045 [Cheriton 1988]. В отличие от T/TCP, который вносит небольшое количество расширений в существующий протокол, VMTP это транспортный уровень в целом, который использует IP. VMTP занимается определением ошибок, повторными передачами и предотвращением дублирования. Он также поддерживает групповые способы рассылки.



Содержание раздела