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

         

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



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

Мы должны сделать расчет для всех составляющих: преамбула, байты заполнения, которые добавляются к подтверждению, контрольная сумма, и минимальный промежуток между пакетами (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. Несмотря на оптимизм, который так и пышет из этих цифр, [Warnock 1991] приводит измеренную скорость равную 1.075.000 байт/сек по Ethernet, со стандартной многопользовательской рабочей станцией (быстрая рабочая станция), что составляет примерно 90% от теоретического значения.

Что касается более быстрых сетей, таких как FDDI (100 Мбит/сек), [Schryver 1993] рассказывает, что три поставщика демонстрировали TCP поверх FDDI со скоростью в диапазоне от 80 до 98 Мбит/сек. В случае, когда доступна большая ширина полосы пропускания, [Borman 1992] сообщает, что было получено до 781 Мбит/сек между двумя компьютерами Cray Y-MP по каналу HIPPI 800 Мбит/сек, и 907 Мбит/сек между двумя процессами с использованием loopback интерфейса на компьютере Cray Y-MP.

Следующие практические ограничения применимы для всех реальных сценариев [Borman 1991].

  1. Вы не можете запустить что-либо быстрее, чем скорость самого медленного канала.
  2. Вы не можете двигаться быстрее, чем ширина пропускания памяти в самой медленной машине. Здесь подразумевается, что ваша реализация обрабатывает данные за один раз. Если нет (то есть, ваша реализация делает один шаг, чтобы скопировать их из пространства пользователя в ядро, затем еще один, чтобы рассчитать TCP контрольную сумму), у вас все будет работать еще медленнее. [Dalton et al. 1993] описывает способы улучшения производительности стандартной Berkeley реализации, когда количество шагов было уменьшено до одного копирования. [Partridge and Pink 1993] применяет то же улучшение "копирование и контрольная сумма" для UDP, вместе с улучшением производительности, что повышает производительность UDP примерно на 30%.
  3. Вы не можете двигаться быстрее, чем размер окна, предложенный получателем, поделенный на время возврата. (Это наше уравнение емкости канала, где размер окна используется как емкость канала и используется для расчета ширины полосы.) Если мы используем максимальный коэффициент масштабирования окна равный 14 из раздела "Опция масштабирования окна", то получим размер окна равный 1,073 Гбайта; эта величина, поделенная на RTT, будет являться пределом ширины полосы пропускания.

Смысл всех приведенных выше цифр заключается в том, что реальный верхний предел того, насколько быстро может работать TCP, определяется размером TCP окна и скоростью света. В заключение, можно, ссылаясь на [Partridge and Pink 1993], заявить, что большинство проблем с производительностью протокола заключается в основном в реализациях, а не во внутренних или наследуемых ограничениях самого протокола.



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