это надежный транспортный уровень. Один

Введение

TCP - это надежный транспортный уровень. Один из способов обеспечения надежности заключается в том, что удаленный участник обмена подтверждает полученные данные. Однако, сегменты данных, которые должны быть подтверждены, могут быть потеряны. TCP отрабатывает подобные ситуации установкой тайм-аута, при отправке данных; если данные не были подтверждены до момента истечения тайм-аута, TCP передает их повторно. Основными составляющими частями подобной технологии являются тайм-ауты и повторные передачи. Как определяются величины тайм-аутов, и как часто осуществляются повторные передачи?
Мы уже видели два примера тайм-аута и повторной передачи: (1) в примере, посвященном недоступности порта ICMP в разделе "ICMP ошибка недоступности порта" главы 6, мы видели, что TFTP клиент, использующий UDP, применяет простую стратегию тайм-аута и повторной передачи: он устанавливает период тайм-аута в 5 секунд и осуществляет повторную передачу каждые 5 секунд. (2) В примере ARP для несуществующего хоста (глава 4, раздел "Примеры ARP") мы видели, что когда TCP старается установить соединение, он повторно передает свои SYN, используя увеличенные задержки между каждой повторной передачей.
TCP управляет четырьмя таймерами для каждого соединения.

Таймер повторной передачи (retransmission) используется в том случае, когда ожидается подтверждение от удаленного конца. В этой главе таймер повторной передачи рассматривается подробно, также рассматриваются соответствующие характеристики, такие как предотвращение переполнения.
Устойчивый (persist) таймер, в течение которого сохраняется информация о размере окна передачи, даже если удаленный конец закрыл свое приемное окно. В главе 22 этот таймер будет описан более подробно.
Таймер времени жизни (keepalive) определяет, когда можно считать, что удаленный конец вышел из строя или перезагрузился. Этот таймер описывается в главе 23.
Таймер 2MSL определяет время, в течение которого соединение может быть в состоянии TIME_WAIT. Это описано в разделе "Диаграмма состояний передачи TCP" главы 18.

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

Введение

Мы видели, что TCP получатель осуществляет управление потоком данных, указывая количество данных, которые он хочет получить от отправителя: размер окна. Что происходит, когда размер окна становится равным 0? Обычно это останавливает отправителя, который прекращает передавать данные до тех пор, пока размер окна станет ненулевым.
Именно так разворачивались события на рисунке 20.3. Когда отправитель получает сегмент 9, открывающий окно, которое было закрыто сегментом 8, он немедленно начинает посылать данные. TCP должен предпринять какие-либо действия в том случае, если подтверждение, открывающее окно (сегмент 9) было потеряно. Подтверждения передаются ненадежно - другими словами, TCP не подтверждает сами подтверждения, он подтверждает только сегменты, содержащие данные.
Если подтверждение потеряно, на каждом конце соединения будут ждать действий от удаленного конца: получатель ожидает получить данные (так как он отправил отправителю ненулевое окно), а отправитель надеется получить обновление окна, которое позволит ему продолжить передачу. Чтобы выйти из подобного тупика, отправитель использует устойчивый (persist) таймер, в соответствии с которым осуществляется периодический опрос получателя на предмет, не был ли увеличен размер окна. Сегменты, которые при этом посылает отправитель, называются пробами окна (window probes) . В этой главе мы рассмотрим пробы окна и устойчивый таймер. Также мы рассмотрим синдром "глупого окна", который непосредственно связан с устойчивым таймером.

Введение

Большинство новичков в TCP/IP, как правило, бывают очень удивлены, когда узнают, что по свободному TCP соединению не передаются данные. А это именно так, то есть если ни один из процессов на концах TCP соединения не посылает данные другому процессу, обмена между двумя TCP модулями не осуществляется. Например, не осуществляется опросов, как это происходит в других сетевых протоколах. Другими словами, мы можем запустить процесс клиента, который установит TCP соединение с сервером, а затем уйти на несколько часов, дней, недель или месяцев, а соединение будет держаться. Промежуточные маршрутизаторы могут выходить из строя и перезагружаться, телефонные линии могут обрыватьься и восстанавливаться, однако если хосты на концах соединения не будут перезагружены, соединение будет оставаться установленным.
При этом подразумевается, что ни одно из приложений - клиент или сервер - не имеет таймеров на прикладном уровне, которые позволяют определить отсутствие активности по соединению, и прекратить работу приложения. Обратитесь к концу раздела "BGP: протокол граничных маршрутизаторов" главы 10, где показано, что BGP посылает пробы приложениям на удаленном конце каждые 30 секунд. Это прикладной таймер, который действует независимо от TCP таймера "оставайся в живых".
Однако существуют моменты, когда сервер хочет узнать, что случилось с хостом клиента: или он вышел из строя и был выключен, или вышел из строя и перезагрузился. Таймер "оставайся в живых" (keepalive timer) это характеристика большинства реализаций, которая предоставляет эту возможность.
Таймеры "оставайся в живых" не являются частью TCP спецификации. Требования к хостам Host Requirements RFC приводят три причины, по которым их не следует использовать: (1) они могут привести к тому, что абсолютно нормальное соединение будет разорвано из-за непродолжительного сбоя, (2) они занимают определенную ширину полосы, и (3) они стоят денег, так как обмен пакетами между сетями имеет определенную цену. Тем не менее, большинство реализаций имеют таймер "оставайся в живых".
Необходимость иметь таймер "оставайся в живых" все еще обсуждается. Многие считают, что подобный опрос удаленного конца не свойственен TCP и должен по необходимости осуществляться приложением. От подобных заявлений отдает религией, в основном из-за того, что они декларируются очень эмоционально и с большим жаром.
Опция "оставайся в живых" может вызвать разрыв устойчивого соединения между двумя процессами из-за временной потери соединения между двумя конечными системами. Например, если проба "оставайся в живых" отправлена в тот момент, когда промежуточный маршрутизатор вышел из строя и перезагружается, TCP подумает, что вышел из строя хост клиента, что, естественно, не так.
Характеристика "оставайся в живых" предназначена для того, чтобы приложение сервера могло оценить поведение клиентов и имело возможность определить, что клиент вышел из строя. Большинство версий Telnet и Rlogin серверов по умолчанию включают опцию "оставайся в живых".
Можно привести пример, однозначно доказывающий необходимость характеристики "оставайся в живых". Пользователи персональных компьютеров часто заходят терминалами на хост с помощью Telnet. В конце рабочего дня они просто выключают питание компьютера, не закрыв соединения. При этом остается полуоткрытое соединение. На рисунке 18.16 мы показали, что отправка данных по полуоткрытому соединению приводит к возврату сброса (reset), однако это происходит в том случае когда данные отправляются клиентом. Если клиент исчез, оставив полуоткрытое соединение на конце сервера, а сервер ожидает каких-либо данных от клиента, он будет ждать вечно. Характеристика "оставайся в живых" предназначена для того, чтобы помочь серверу определить наличие полуоткрытых соединений.

Введение

TCP функционирует уже в течение многих лет и по SLIP каналам со скоростью 1200 бит в секунду и по Ethernet. В 80-х и начале 90-х годов Ethernet был основным типом канального уровня для TCP/IP. Несмотря на то, что TCP корректно работает на скоростях больших, чем предоставляемые Ethernet (телефонные линии T3, FDDI и гигабитные сети, например), на повышенных скоростях начинают сказываться некоторые ограничения TCP.
В этой главе рассматриваются некоторые предложения посвященные модификациям TCP, которые позволяют добиться максимальной пропускной способности на высоких скоростях. Во-первых, мы рассмотрим механизм определения транспортного MTU, который мы уже упоминали раньше. Сейчас мы подробно рассмотрим, как он функционирует с TCP. Этот алгоритм позволяет TCP использовать MTU больше чем 536 для соединений по глобальным сетям, что, в свою очередь, повышает пропускную способность.
Затем мы рассмотрим каналы с повышенной пропускной способностью (long fat pipes), сети, имеющие большую емкость канала зависящую от полосы пропускания (bandwidth-delay product), и ограничения TCP, которые становятся существенными для этих сетей. Здесь описаны две новые опции TCP, используемые для работы с каналами с повышенной пропускной способностью (long fat pipes): опция масштабирования окна (позволяет использовать окна TCP с максимальным размером больше чем 65535 байт) и опция временной марки. Опция временной марки позволяет TCP осуществлять более аккуратный расчет RTT для сегментов данных, а также предоставляет защиту от перехода номеров последовательности через ноль, что может возникнуть на высоких скоростях. Эти две опции определены в RFC 1323 [Jacobson, Braden, and Borman 1992].
Также мы рассмотрим T/TCP - модификацию TCP для транзакций. Режим транзакций это характеристики коммуникации, при которых на запрос от клиента приходит отклик от сервера. Основная задача T/TCP заключается в том, чтобы уменьшить количество сегментов, которыми обмениваются два участника соединения, при этом отпадает необходимость в трехразовом рукопожатии (three-way handshake) и четырех сегментах, которыми необходимо обменяться, чтобы закрыть соединение. При этом клиент получает отклик от сервера через время равное одному RTT плюс время, необходимое для обработки запроса.
И самое замечательное в этих новых опциях - в характеристике определения транспортного MTU, опции масштабирования окна, опции временной марки и T/TCP - это то, что они совместимы с уже существующими реализациями TCP. Новые системы, которые имеют эти опции, могут общаться с более ранними системами. За исключением дополнительных полей в ICMP сообщении, которые могут быть использованы при определении транспортного MTU, новые опции должны быть реализованы только на конечных системах, которые хотят пользоваться их преимуществами.
Мы закончим эту главу рассмотрением публикаций, вышедших в настоящее время и имеющих отношение к производительности TCP.

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