Сжатие заголовков можно реализовать эффективно, если учитывать формат протокола. Одна из первых схем была разработана Ван Джекобсоном (1990) и применялась для сжатия TCP/IP-заголовков при передаче по медленным последовательным каналам. Она позволяет уменьшить обычный 40-байтовый TCP/IP-заголовок в среднем до 3 байт. Если посмотреть на рис. 6.46, можно догадаться, на чем основан этот метод. Дело в том, что многие поля заголовка не меняются от пакета к пакету. К примеру, совсем не обязательно передавать одно и то же значение времени жизни пакета или один и тот же номер TCP-порта с каждым пакетом. Эти поля можно пропустить при передаче пакета и заполнить при получении.
Остальные поля меняются по предсказуемому сценарию. К примеру, если потерь пакетов не происходит, порядковые номера TCP увеличиваются по мере отправки данных. Следовательно, получатель может предсказать наиболее вероятное значение. Номер необходимо указать только в том случае, если он отличается от ожидаемого. Но даже в таком случае можно передавать разность между данным номером и предыдущим, как в случае с номером подтверждения, который увеличивается, когда новые данные приходят в обратном направлении.
С помощью сжатия заголовков можно добиться того, чтобы в протоколах высоких уровней заголовки были простыми, а при передаче пакета по каналам с низкой пропускной способностью использовалось компактное кодирование. Надежное сжатие заголовков (ROHC, Robust Header Compression) — современный вариант сжатия заголовков, который определен в RFC 5795 как фреймворк. В соответствии с замыслом разработчиков, он не реагирует на потерю пакетов в беспроводных каналах. Для каждого набора протоколов — например, IP/UDP/RTP — существует отдельный профиль. Сжатые заголовки передаются с помощью отсылки к контексту, то есть фактически к соединению; значения полей заголовков можно легко предсказать для пакетов данного соединения, но не для пакетов других соединений. При нормальной работе ROHC размер заголовков для IP/UDP/RTP снижается от 40 байт до 1-3 байт.
Хотя основная цель компрессии заголовков — уменьшение потребляемой пропускной способности, с помощью этого механизма можно также снизить задержку. Задержка складывается из задержки распространения, фиксированной для данного сетевого пути, и задержки передачи, которая зависит от пропускной способности и объема передаваемых данных. Например, канал мощностью 1 Мбит/с отправляет 1 бит за 1 мкс. Если мы имеем дело с передачей медиаданных по беспроводной сети, такой канал считается достаточно медленным, поэтому задержка передачи составляет существенную часть общей задержки, и стабильно низкая задержка крайне важна для качества обслуживания.
Если использовать сжатие заголовков, объем передаваемых данных уменьшится, и вместе с ним уменьшится задержка передачи. Того же эффекта можно добиться, отправляя пакеты меньшего размера. Так мы фактически обменяем хорошие показатели накладных расходов, возникающих за счет программного обеспечения, на хорошие показатели задержки передачи. Стоит отметить, что еще одним источником задержки является время ожидания в очереди для доступа к беспроводному каналу. Этот фактор может оказаться важным, так как беспроводные сети обычно сильно загружены. В таком случае беспроводной канал должен включать механизмы качества обслуживания, обеспечивающие низкую задержку пакетам реального времени. Одного сжатия заголовков будет недостаточно.
6.6.6. Протоколы для протяженных сетей с высокой пропускной способностью
Появление гигабитных сетей, передающих данные на большие расстояния, приходится на начало 90-х годов. Их также называют протяженными сетями с высокой пропускной способностью (long fat networks). Сначала к ним пытались применить старые протоколы, но при этом сразу же возникло множество проблем. В данном разделе мы обсудим некоторые из этих проблем, переходя к более высоким скоростям и задержкам сетевых протоколов.
Первая проблема заключается в том, что многие протоколы используют 32-разрядные порядковые номера. В прежние годы, когда типичная скорость выделенных линий между маршрутизаторами равнялась 56 Кбит/с, хосту, который постоянно выдавал бы данные в сеть на полной скорости, потребовалось бы больше недели на то, чтобы у него закончились порядковые номера. С точки зрения разработчиков TCP 232 считалось неплохим приближением к бесконечности, поскольку вероятность блуждания пакетов по сети в течение недели практически равна нулю. В Ethernet со скоростью 10 Мбит/с критическое время снизилось с одной недели до 57 минут. Это, конечно, гораздо меньше, но даже с таким интервалом еще можно иметь дело. Когда же Ethernet выдает в Интернет данные со скоростью 1 Гбит/с, порядковые номера закончатся примерно через 34 с. Это уже никуда не годится, поскольку максимальное время жизни пакета в Интернете равно 120 с. Внезапно оказалось, что 232 совершенно не подходит в качестве значения, приближенного к бесконечности, поскольку стало очевидно, что отправителю, посылающему достаточно много пакетов, придется повторять их порядковые номера в то время, как старые пакеты все еще будут блуждать по сети.
Проблема состоит в том, что многие разработчики протоколов просто предполагали, что время цикла пространства порядковых номеров значительно превосходит максимальное время жизни пакетов. Соответственно, в этих протоколах даже не рассматривалась сама возможность того, что старые пакеты еще могут находиться где-то в сети, когда порядковые номера опишут полный круг. В гигабитных сетях это предположение оказалось неверным. К счастью, оказалось возможным расширить эффективный порядковый номер, взяв в качестве старших битов метку времени, которая добавляется в TCP-заголовок каждого пакета в качестве дополнительного параметра. Этот механизм называется детектированием повторного использования порядковых номеров (PAWS, Protection Against Wrapped Sequence numbers). Он описан в RFC 1323.
Вторая проблема состоит в необходимости существенного увеличения окна управления потоком. Рассмотрим, например, процесс отправки 64 Кбайт данных из Сан-Диего в Бостон при размере буфера получателя в 64 Кбайт. Пусть скорость передачи данных в линии составляет 1 Гбит/с, а время прохождения сигнала в одну сторону, ограниченное скоростью света в стекле оптоволокна, равно 20 мс. Вначале (t = 0), как показано на рис. 6.48, а, канал пуст. Только 500 мкс спустя все сегменты попадут в канал (рис. 6.48, б). Первый сегмент оказывается где-то в окрестностях Броли, все еще в Южной Калифорнии. Тем не менее передатчик уже должен остановиться, пока он не получит в ответ новую информацию об окне.
Через 20 мс первый сегмент, как показано на рис. 6.48, в, достигнет Бостона, и в ответ будет передано подтверждение. Наконец, через 40 мс после начала операции первое подтверждение возвращается к отправителю, после чего передается следующая порция данных. Поскольку линия передачи использовалась всего 0,5 мс из 40 мс, эффективность ее использования составит около 1,25 %. Такая ситуация является типичной для работы старых протоколов по гигабитным линиям.
При анализе производительности сетей полезно обращать внимание на произведение пропускной способности и времени задержки (bandwidth-delay product). Пропускная способность канала (в битах в секунду) умножается на время прохождения сигнала в оба конца (в секундах). В результате получается емкость канала в битах.
В примере на рис. 6.48 произведение пропускной способности и времени задержки равно 40 млн бит. Другими словами, отправитель к моменту получения ответа успеет переслать 40 млн бит, если будет передавать с максимальной скоростью. Столько бит потребуется, чтобы заполнить канал в обоих направлениях. Таким образом, порция данных в полмиллиона бит составляет всего 1,25 % емкости канала, что и выражается в 1,25 % эффективности использования канала.
