9.7 Будущее tcp и его производительность

9.7.1. TCP функционирует уже в течение многих лет и по SLIP каналам со скоростью 1200 бит в секунду, и по Ethernet. В 80-х и начале 90-х годов Ethernet был основным типом канального уровня для TCP/IP. Несмотря на то, что TCP корректно работает на скоростях больших, чем предоставляемые Ethernet (телефонные линии T3, FDDI и гигабитные сети, например), на повышенных скоростях начинают сказываться некоторые ограничения TCP.

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

Характеристики определения транспортного MTU, опции масштабирования окна, опции временной марки и T/TCP – уже совместимы с существующими реализациями TCP. Новые системы, которые имеют эти опции, могут общаться с более ранними системами. За исключением дополнительных полей в ICMP сообщении, которые могут быть использованы при определении транспортного MTU, новые опции должны быть реализованы только на конечных системах, которые хотят пользоваться их преимуществами.

9.7.2 Транспортный MTU - это минимальный MTU в любой из сетей, по которым проходит маршрут между двумя хостами. При определении транспортного MTU в IP заголовке устанавливается бит "не фрагментировать" (DF - don't fragment), что позволяет определить, необходимо ли какому-либо маршрутизатору на текущем маршруте фрагментировать IP дейтаграммы, которые мы посылаем.

Алгоритм определения транспортного MTU TCP работает следующим образом: когда соединение установлено, TCP использует минимальный MTU исходящего интерфейса или MSS, объявленный удаленным концом, в качестве исходного размера сегмента. Алгоритм определения транспортного MTU не позволяет TCP превосходить MSS, объявленный удаленным концом. Если удаленный конец не указал MSS, то он устанавливается по умолчанию в значение равное 536. Реализации могут сохранить информацию о транспортном MTU определенного канала.

После того как выбран исходный размер сегмента, во всех IP дейтаграммах, отправляемых TCP по этому соединению, устанавливается бит DF. Если промежуточному маршрутизатору необходимо фрагментировать дейтаграмму, в которой установлен бит DF, он отбрасывает дейтаграмму и генерирует ICMP ошибку "не могу фрагментировать" (can't fragment). Если принята такая ICMP ошибка, TCP уменьшает размер сегмента и повторяет передачу. Если маршрутизатор сгенерировал новую ICMP ошибку, размер сегмента может быть установлен в MTU следующей пересылки минус размеры IP и TCP заголовков.

Если возвратилась старая ICMP ошибка, должно быть использовано следующее меньшее значение MTU. Когда осуществляются повторные передачи, вызванные этими ICMP ошибками, окно переполнения не должно изменяться, вместо этого должен быть использован медленный старт.

Так как маршруты могут меняться со временем, по истечении определенного времени после последнего уменьшения транспортного MTU, можно попробовать большее значение (до величины минимального MSS, объявленного удаленным концом, или MTU исходящего интерфейса). RFC 1191 рекомендует, чтобы этот временной интервал составлял примерно 10 минут.

Используя обычное для работы в глобальных сетях значение, MSS по умолчанию равное 536, алгоритм определения транспортного MTU избегает фрагментации по промежуточным каналам с MTU меньшим, чем 576 (что встречается довольно редко). Также можно избежать фрагментации в локальных сетях, когда промежуточный канал (Ethernet) имеет меньший MTU, чем сеть конечного пункта назначения (Token Ring). В процессе определения транспортного MTU (при работе в глобальных сетях с MTU большим, чем 576), системы не должны использовать MSS по умолчанию равный 536 байт для нелокальных пунктов назначения. Предпочтительней выбирать MSS, равный MTU исходящего интерфейса (естественно, минус размер IP и TCP заголовков).

9.7.3 Лучше использовать большие пакеты, потому что отправка меньшего количества больших пакетов "дешевле", чем отправка большего количества маленьких пакетов. (Подразумевается, что пакеты не настолько велики, чтобы вызвать фрагментацию.) Представьте себе следующий пример. Мы посылаем 8192 байта через четыре маршрутизатора, каждый из которых подключен к телефонной линии T1 (1544000 бит/сек). Во-первых, мы используем два пакета размером 4096 байт.

Основная проблема заключается в том, что маршрутизаторы - это устройства, которые работают по принципу "сохранить и перенаправить". Они обычно получают входящий пакет целиком, проверяют на правильность IP заголовок, включая контрольную сумму IP, принимают решение о маршрутизации и затем начинают отправку исходящего пакета. На отправку всех 8192 байт от R1 до R4 будет истрачено четыре отрезка времени. Время на каждую пересылку будет составлять

[(4096 + 40 байт)*8 бит/байт]/1544000 бит/сек = 21,4 миллисекунды на пересылку

(IP и TCP заголовки составляют 40 байт.) Полное время, которое тратится на отправку данных, состоит из количества пакетов, плюс количество пересылок, минус один и составляет четыре отрезка времени или 85,6 миллисекунды. Каждый канал остается неиспользованным в течение двух отрезков времени или 42,8 миллисекунды.

Рассмотрим, что произойдет, если мы пошлем 16 пакетов размером 512 байт.

Это передача займет больше отрезков времени, однако каждый отрезок короче, так как отправляются пакеты меньшего размера.

[(512 + 40 байт)*8 бит/байт]/1544000 бит/сек = 2,9 миллисекунды на пересылку

Сейчас полное время составляет (18*2,9) = 52,2 миллисекунды. Каждый канал снова не занят в течение двух отрезков времени, что сейчас составляет 5,8 миллисекунды.

В этом примере мы игнорировали время, которое необходимо для того, чтобы вернулось подтверждение (ACK), также мы проигнорировали время, необходимое для установления и разрыва соединения, и не приняли во внимание то, что по каналам может двигаться и другой трафик. Тем не менее, расчеты указывают, что отправка больших пакетов всегда эффективней. Однако, для различных сетей требуются более подробные исследования.

9.7.4 Ёмкость соединения можно рассчитать следующим образом:

Емкость (бит) равна ширине полосы, (бит/сек) умноженную на время возврата (сек). И назвали это емкостью канала в зависимости от полосы пропускания. Иногда эта величина называется размером канала между двумя точками.

Существующие ограничения TCP начинают влиять на производительность по мере увеличения емкости каналов. В Таблице 13 показаны некоторые значения для различных типов сетей.

Таблица 13- Емкость канала для различных сетей

Сеть	Ширина полосы (бит/сек)	Время возврата (миллисекунды)	Емкость канала (байты)
Локальная сеть на основе Ethernet	10000000	3	3750
Трансконтинентальный канал, телефонная линия T1	1544000	60	11580
Спутниковый канал, телефонная линия T1	1544000	500	95500
Трансконтинентальный канал, телефонная линия T3	45000000	60	337500
Трансконтинентальный гигабитный канал	1000000000	60	7500000

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

Сети с большой емкостью канала называются сетями с повышенной пропускной способностью (LFN - long fat networks, произносится как "elephant(s)", elephant (англ.) - слон), а TCP соединения, работающие на LFN, называются каналами с повышенной пропускной способностью (long fat pipe). Можно сказать, что эти каналы могут быть расширены в горизонтальном направлении (большие RTT) или в вертикальном направлении (большая ширина полосы передачи) или в обоих направлениях. Однако с подобными каналами с повышенной пропускной способностью возникают некоторые проблемы.

Размер окна TCP находится в 16-битном поле TCP заголовка, ограничивая размер окна величиной, равной 65535 байт. Как видно из последней колонки в таблице 13, существующие сети уже требуют большего окна, чем 65535 для достижения максимальной пропускной способности. Опция масштабирования окна решает эту проблему.

Пакеты, теряемые в LFN, могут значительно уменьшить пропускную способность. Если потерян только один сегмент, алгоритм быстрой передачи и быстрого восстановления, сделает так, что канал не сузится. Однако, даже при использовании этого алгоритма, потеря больше чем одного пакета внутри окна обычно приводит к тому, что канал сужается. (Если канал сузился, снова используется медленный старт, что в несколько раз увеличивает время возврата, прежде чем канал будет снова заполнен.) Чтобы обработать потерю нескольких пакетов внутри окна, в RFC 1072 [Jacobson and Braden 1988] было предложено использовать cелективные подтверждения (SACK). Однако, начиная с RFC 1323, от использования этой характеристики отказались, потому что авторы обнаружили несколько технических проблем, которые необходимо решить перед включением этой опции в TCP.

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

TCP идентифицирует каждый байт данных уникальным 32-битным номером последовательности. Если сегмент, задержанный в сети, появится после того, как соединение, которому он принадлежал, уже закрыто, и когда установлено новое соединение между теми же двумя хостами и теми же номерами портов? То во-первых, вспомним, что поле TTL в IP заголовке содержит максимальное время жизни любой IP датаграммы - 255 пересылок или 255 секунд (что кончится первым). Максимальное время жизни сегмента (MSL) это параметр, зависящий от реализации и используемый для того, чтобы не возникла подобная ситуация. Рекомендуемое значение для MSL - 2 минуты (при этом 2MSL будет равно 240 секундам), однако многие реализации устанавливают MSL в 30 секунд. Еще одна проблема с номерами последовательности TCP возникает при использовании LFN. Так как величина номера последовательности ограничена, тот же самый номер последовательности будет использован повторно после того, как будет передано 4.294.967.296 байт. Что произойдет, если сегмент, содержащий байт с номером последовательности N, будет задержан в сети и появится позже, когда соединение все еще открыто? Эта проблема появится только в том случае, если тот же самый номер последовательности N повторно используется в течение периода MSL, то есть в том случае, если сеть настолько быстрая, что номер последовательности успевает повториться за время меньшее, чем MSL. Для Ethernet необходимо почти 60 минут, чтобы послать такое количество данных, поэтому подобная ситуация не возможна. Однако время, необходимое на то, чтобы появился номер последовательности, который уже существует в сети, уменьшается с ростом ширины пропускания сети: для телефонных линий T3 (45 Мбит/сек) требуются 12 минут, для FDDI (100 Мбит/сек) - 5 минут, а для гигабитных сетей (1000 Мбит/сек) - 34 секунды. В данном случае проблема не связана с емкостью канала, а связана с шириной полосы.

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

Представим процесс отправки файла размером 1 миллион байт через Соединенные Штаты, с предполагаемой латенсией, равной 30 миллисекундам.

На рисунке 113 показаны два сценария, верхний соответствует использованию телефонной линии T1 (1544000 бит/сек), а нижний подразумевает использование сети 1 гигабит/сек. Время показано по оси ОХ, (отправитель находится слева, а получатель справа), а емкость

Рисунок 113 - Отправка файла размером 1 Мбайт по сетям с 30-миллисекундной латенсией

показана по оси OY.

Закрашенный прямоугольник на обоих рисунках - это 1 миллион байт, который необходимо отправить.

На рисунке 113 показано состояние обеих сетей через 30 миллисекунд. В обеих сетях первый бит данных достиг удаленного конца через 30 миллисекунд (латенсия), однако в случае сети T1

(емкость канала - 5790 байт), 994210 байт все еще находятся у отправителя, ожидая того, что они будут отправлены. Емкость гигабитной сети составляет 3750000 байт, поэтому файл целиком занимает всего лишь около 25% канала. Последний бит файла достигает получателя через 8 миллисекунд после первого бита.

Полное время передачи файла по сети T1 составляет 5,211 секунды. Если мы увеличить ширину полосы пропускания, например, с использованием сети T3 (45000000 бит/сек), полное время уменьшится до 0,208 секунды. Увеличение ширины полосы в 29 раз уменьшает полное время в 25 раз.

В случае гигабитной сети полное время, необходимое на передачу файла, составляет 0,038 секунды: 30-миллисекундная латенсия (задержка) плюс 8 миллисекунд на реальную передачу файла. Предположим, мы можем, увеличить ширину полосы пропускания до 2 гигабит/сек, однако в этом случае мы уменьшим полное время передачи до всего лишь 0,034 секунды: та же самая 30-миллисекундная латенсия (задержка) плюс 4 миллисекунды на передачу файла. Таким образом, удвоение полосы передачи, уменьшает полное время всего лишь на 10%. В случае гигабитных скоростей мы уже ограничены латенсией (задержкой), а не шириной полосы.

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

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

Эта опция может появиться только в сегменте SYN. Таким образом, коэффициент масштабирования определяется в каждом направлении при установлении соединения. Чтобы включить масштабирование окна, оба конца должны активизировать опцию в своих сегментах SYN. Сторона, осуществляющая активное открытие, посылает опцию в своем SYN, однако сторона, осуществляющая пассивное открытие, может послать опцию, только если эта опция установлена в полученном SYN. Коэффициент масштабирования может быть различен для каждого направления.

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

Представим, что используем опцию масштабирования окна со сдвиговым счетчиком, равным S для отправки и со сдвиговым счетчиком, равным R, для приема. В этом случае каждые 16 бит объявленного окна, которые мы получаем от удаленного конца, сдвигаются влево на R бит, чтобы получить реальный размер объявленного окна. Каждый раз, когда мы отправляем объявление окна на удаленный конец, мы берем реальный 32-битный размер окна, сдвигаем его вправо на S бит, помещаем получившийся результат (16-битное значение) в TCP заголовок.

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

9.7.7 Опция временной марки (timestamp) позволяет отправителю поместить значение временной марки в каждый сегмент. Получатель возвращает это значение в подтверждении, что позволяет отправителю рассчитать RTT при получении каждого ACK. (Мы должны сказать "каждый ACK", а не "каждый сегмент", так как TCP обычно подтверждает несколько сегментов с помощью одного ACK.) Мы сказали, что большинство современных реализаций рассчитывают одно RTT на окно, что вполне достаточно, если окно содержит 8 сегментов. Однако в случае, если окно имеет большие размеры, требуется лучший расчет RTT.

Раздел 3.1 в RFC 1323 объясняет причины, по которым требуется лучшая оценка RTT при больших размерах окна. Обычно RTT измеряется с помощью сигнала данных (сегмент данных), с небольшой частотой (один раз на окно). Когда в окне 8 сегментов, скорость сигналов составляет одну восьмую скорости данных, что вполне приемлемо, однако когда в окне 100 сегментов, скорость сигналов составляет 1/100 от скорости данных. При этом RTT может быть рассчитано некорректно, что, в свою очередь, может вызвать повторные передачи, в которых нет необходимости. Если сегмент потерян, все становится еще хуже.

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

Временная марка - монотонно увеличивающееся значение. Так как получатель отражает то, что он получает, его не интересуют конкретные значения временных марок. Эта опция не требует какой-либо формы синхронизации часов между двумя хостами. RFC 1323 рекомендует, чтобы значение временной марки увеличивалось на единицу в диапазоне от 1 миллисекунды до 1 секунды.

Эта опция устанавливается при открытии соединения таким же образом, как и опция масштабирования окна, которую мы рассмотрели в предыдущем разделе. Сторона, осуществляющая активное открытие, устанавливает опцию в своем SYN. Только если опция получена в SYN с удаленного конца, она может быть установлена в следующих сегментах.

Мы видели, что получающий TCP не должен подтверждать каждый полученный сегмент данных. Если получатель отправляет ACK, подтверждающий два принятых сегмента данных, которая из принятых временных марок отправляются назад в поле эха отклика на временную марку?

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

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

Этот алгоритм обрабатывает два следующих случая:

- Если подтверждения (ACK) задержаны получателем, значение временной марки, возвращаемое эхом, будет соответствовать самому раннему подтверждаемому сегменту. Например, если прибыло два сегмента содержащие байты 1-1024 и 1025-2048, оба с опцией временной марки, а получатель подтверждает их обоих с ACK 2049, временная марка в ACK будет иметь значение из первого сегмента, содержащего байты 1-1024. Это делается именно так, потому что отправитель должен рассчитать свой тайм-аут для повторной передачи с учетом задержанных ACK.

- Если полученный сегмент принят в своем окне, но его номер последовательности не соответствует ожидаемому, можно сделать предположение, что предыдущий сегмент был потерян. Однако когда этот отсутствующий сегмент получен, именно его временная марка будет отражена эхом, а не временная марка сегмента, пришедшего "вне очереди". Например, представьте себе три сегмента, каждый из которых содержит 1024 байта, они приняты в следующем порядке: сегмент 1 с байтами 1-1024, сегмент 3 с байтами 2049-3072 и затем сегмент 2 с байтами 1025-2048. Будут отправлены следующие подтверждения: ACK 1025 - с временной маркой из сегмента 1 (обычный ACK для ожидаемых данных); ACK 1025 - с временной маркой из сегмента 1 (дублированный ACK в ответ на сегмент, пришедший "в окне", но "вне последовательности"); ACK 3073 - с временной маркой из сегмента 2 (но не с последней временной маркой из сегмента 3). В подобных случаях RTT может быть оценен несколько раз, что все же лучше, чем неверная оценка RTT. Также, если последний ACK содержит временную марку из сегмента 3, он может включать в себя время, необходимое для возврата дублированного ACK и повторной передачи сегмента 2, или он может включать в себя время, выделенное отправителем на тайм-аут повторной передачи для сегмента 2. В обоих случаях отражение эхом временной марки из сегмента 3 может повлиять на расчет RTT отправителем.

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

9.7.8 Алгоритм PAWS. PAWS - это защита от перехода номеров последовательности через ноль

Представим TCP соединение, использующее опцию масштабирования окна, с максимально возможным окном 1 гигабайт (2³⁰). (Самое большое окно даже меньше чем это, 65535 * 2¹⁴, а не 2¹⁶ * 2¹⁴, однако это не должно влиять на наши рассуждения.) Также представьте, что используется опция временной марки, и что значение временной марки, назначенное отправителем, увеличивается на единицу для каждого отправляемого окна. (Это достаточно устаревший способ, обычно значение временной марки увеличивается значительно быстрее.) В таблице 14 показан поток данных между двумя хостами, возникающий при передаче 6 гигабайт. Чтобы избежать большого количества десятизначных цифр, мы используем запись G, что означает умножение на 1.073.741.824. Мы также используем форму записи, где J:K означает байты от J до K-1, включая байт K-1.

Таблица 14. Передача 6 гигабайт в шести 1-гигабайтных окнах

Время	Отправ-ленные байты	Отправленный номер последователь-ности	Отправленная временная марка	Получение
A	G:1G	0G:1G	1	принято нормально
B	G:2G	1G:2G	2	принято нормально, но один сегмент потерян и передан повторно
C	G:3G	2G:3G	3	принято нормально
D	G:4G	3G:4G	4	принято нормально
E	G:5G	0G:1G	5	принято нормально
F	G:6G	1G:2G	6	принято нормально, но повторно переданный сегмент появился в сети повторно

32-битный номер последовательности перешел через ноль между моментами времени D и E. Мы предположили, что один сегмент потерялся в момент времени B и был передан повторно. Также мы предположили, что потерянный сегмент повторно появился в сети в момент времени F.

Разница во времени между моментами, когда сегмент был потерян и появился повторно, меньше, чем MSL; иначе сегмент должен быть отброшен каким-либо маршрутизатором по истечению его TTL. Такая проблема возникает только на высокоскоростных соединениях, где старые сегменты могут повторно появиться и содержать номер последовательности, который в настоящее время передается.

Также мы можем видеть из таблицы 14, что использование временной марки решает эту проблему. Получатель рассматривает временную марку как 32-битное расширение к номеру последовательности. Так как потерянный сегмент, повторно появившийся в момент времени F, имел временную марку, равную 2, что меньше, чем самая последняя, приемлемая временная марка (5 или 6), он отбрасывается алгоритмом PAWS.

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

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

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

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

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

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

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

Еще одна проблема с TCP - это состояние «TIME WAIT», которое требует ожидания в течение 2MSL.

Две модификации, необходимые для 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 - значение тайм-аута повторной передачи).

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

От клиента к серверу осуществляется при активном открытии: 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 и его отклонение также должны быть кэшированы для сервера.

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

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

9.7.10 Цифры, которые публиковались в середине 80-х годов, показывали пропускную способность TCP по Ethernet где-то в районе 100000-200000 байт в секунду. С того времени многое изменилось. Современное аппаратное обеспечение (рабочие станции и быстрые персональные компьютеры) обеспечивает передачу 800000 байт в секунду и больше.

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

Таблица 15 - Размеры полей для Ethernet при расчете максимальной теоретически возможной пропускной способности

Поле	Количество байт данных	Количество байт подтверждения
Преамбула Ethernet	8	8
Адрес назначения Ethernet	6	6
Адрес источника Ethernet	6	6
Поле типа Ethernet	2	2
Заголовок IP	20	20
Заголовок TCP	20	20
Пользовательские данные	1460	0
Заполнение (до минимального размера Ethernet)	0	6
Контрольная сумма Ethernet	4	4
Промежуток между пакетами (9,6 микросекунды)	12	12
Всего	1538	84

Рассмотрим расчет для всех составляющих: преамбула, байты заполнения, которые добавляются к подтверждению, контрольная сумма, и минимальный промежуток между пакетами (9,6 микросекунды, что равно 12 байтам при скорости 10 Мбит/сек).

Для этого предположим, что отправитель передает два полноразмерных сегмента данных, после чего получатель отправляет ACK на эти два сегмента. Максимальная пропускная (throughput) способность (для пользовательских данных) будет равна

throughput = [(2 x 1460 байт)/(2 x 1538 + 84 байта)] x [(10.000.000 бит/сек)/(8 бит/байт)] = 1.155.063 байт/сек

Если окно TCP открыто на его максимальный размер (65535, опция масштабирования окна не используется), это позволяет отправить окно размером в 44 сегмента, каждый из которых размером 1460 байт. Если получатель отправляет ACK на каждый 22-й сегмент, расчет будет следующим

throughput = [(22 x 1460 байт)/(22 x 1538 + 84 байта)] x [(10.000.000 бит/сек)/(8 бит/байт)] = 1.183.667 байт/сек

Это теоретический предел, при расчете которого сделаны некоторые допущения: не произойдет коллизии (столкновения) между ACK, отправленным получателем, и одним из сегментов отправителя; отправитель может передать два сегмента с минимальным промежутком Ethernet; и получатель может сгенерировать ACK внутри минимального промежутка Ethernet. Несмотря на оптимизм этих цифр, Измеренная скорость равна 1.075.000 байт/сек по Ethernet, со стандартной многопользовательской рабочей станцией (быстрая рабочая станция), что составляет примерно 90% от теоретического значения.

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