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

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



Рисунок 24.5 Емкость канала для различных сетей.

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

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

  1. Размер окна TCP находится в 16-битном поле TCP заголовка, ограничивая размер окна величиной равной 65535 байт. Как видно из последней колонки на рисунке 24.5, существующие сети уже требуют большего окна, чем 65535, для достижения максимальной пропускной способности. Опция масштабирования окна, описанная в разделе "Опция масштабирования окна" этой главы, решает эту проблему.
  2. Пакеты, теряемые в LFN, могут значительно уменьшить пропускную способность. Если потерян только один сегмент, алгоритм быстрой передачи и быстрого восстановления, который мы описали в разделе "Быстрая повторная передача и алгоритм быстрого восстановления" главы 21, сделает так, что канал не сузится. Однако, даже при использовании этого алгоритма, потеря больше чем одного пакета внутри окна обычно приводит к тому, что канал сужается. (Если канал сузился, снова используется медленный старт, что в несколько раз увеличивает время возврата, прежде чем канал будет снова заполнен.) Чтобы обработать потерю нескольких пакетов внутри окна, в RFC 1072 [Jacobson and Braden 1988] было предложено использовать cелективные подтверждения (SACK). Однако, начиная с RFC 1323, от использования этой характеристики отказались, потому что авторы обнаружили несколько технических проблем, которые необходимо решить перед включением этой опции в TCP.
  3. В разделе "Пример RTT" главы 21 мы видели, что большинство TCP реализаций измеряют только одно время задержки на окно. Они не измеряют RTT для каждого сегмента. Однако для функционирования в LFN требуется лучшее измерение RTT. Опция временной марки, которая описана в разделе "Опция временной марки" этой главы, позволяет оценить время передачи нескольких сегментов, включая повторно переданные.
  4. TCP идентифицирует каждый байт данных уникальным 32-битным номером последовательности. Что произойдет, если сегмент, задержанный в сети, появится после того как соединение, которому он принадлежал, уже закрыто, и когда установлено новое соединение между теми же двумя хостами и теми же номерами портов? Во-первых, вспомним, что поле TTL в IP заголовке содержит максимальное время жизни любой IP датаграммы - 255 пересылок или 255 секунд (что кончится первым). В разделе "Диаграмма состояний передачи TCP" главы 18 мы определили, что максимальное время жизни сегмента (MSL) это параметр, зависящий от реализации и используемый для того, чтобы не возникла подобная ситуация. Рекомендуемое значение для MSL - 2 минуты (при этом 2MSL будет равно 240 секундам), однако мы видели в разделе "Диаграмма состояний передачи TCP" главы 18, что многие реализации устанавливают MSL в 30 секунд. Еще одна проблема с номерами последовательности TCP возникает при использовании LFN. Так как величина номера последовательности ограничена, тот же самый номер последовательности будет использован повторно после того, как будет передано 4.294.967.296 байт. Что произойдет, если сегмент, содержащий байт с номером последовательности N, будет задержан в сети и появится позже, когда соединение все еще открыто? Эта проблема появится только в том случае, если тот же самый номер последовательности N повторно используется в течение периода MSL, то есть в том случае, если сеть настолько быстрая, что номер последовательности успевает повториться за время меньшее чем MSL. Для Ethernet необходимо почти 60 минут, чтобы послать такое количество данных, поэтому подобная ситуация не возможна, однако время, необходимое на то, чтобы появился номер последовательности, который уже существует в сети, уменьшается с ростом ширины пропускания сети: для телефонных линий T3 (45 Мбит/сек) требуются 12 минут, для FDDI (100 Мбит/сек) - 5 минут, а для гигабитных сетей (1000 Мбит/сек) - 34 секунды. В данном случае проблема не связана с емкостью канала, а связана с шириной полосы. В разделе "PAWS: защита от перехода номеров последовательности через ноль" этой главы мы описываем способ, с помощью которого можно решить эту проблему: алгоритм PAWS (защита от перехода номеров последовательности через ноль), который использует опцию временной марки TCP.

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



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