Протоколы компьютерных сетей и сетевые операционные системы

Так как маршруты могут меняться со временем, по истечении определенного времени после последнего уменьшения транспортного 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 гигабит/сек. Время показано по оси ОХ, (отправитель находится слева, а получатель справа), а емкость показана по оси OY.

Размещено на http://www.allbest.ru/

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

Закрашенный прямоугольник на обоих рисунках - это 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 гигабайт (230). (Самое большое окно даже меньше чем это, 65535 * 214, а не 216 * 214, однако это не должно влиять на наши рассуждения.) Также представьте, что используется опция временной марки, и что значение временной марки, назначенное отправителем, увеличивается на единицу для каждого отправляемого окна. (Это достаточно устаревший способ, обычно значение временной марки увеличивается значительно быстрее.) В таблице 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 окна и скоростью света. Большинство проблем с производительностью протокола заключается в основном в реализациях, а не во внутренних или наследуемых ограничениях самого протокола.

Раздел 10. User Datagram Protocol (UDP)

10.1 Назначение протокола

Этот протокол (User Datagram Protocol - UDP) проектировался для создания в объединенной системе компьютерных сетей с коммутацией пакетов режима передачи дейтаграмм клиента. Протокол UDP предполагает, что нижестоящим протоколом является Internet (IP).

Данный протокол предоставляет прикладной программе процедуру для посылки сообщений другим программам, причем механизм протокола минимален. Протокол UDP ориентирован на транзакции; получение дейтаграмм и защиту от дублирования не гарантированы. Приложения, требующие гарантированного получения потоков данных, должны использовать протокол управления пересылкой (Transmission Control Protocol - TCP).

Официальная спецификация протокола UDP - RFC 768 [Postel 1980]

10.2 Определение окончательного места назначения

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

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

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

10.3 Протокол пользовательских дейтаграмм (UDР)

В стеке протоколов TCP/IР UDР обеспечивает основной механизм, используемый прикладными программами для передачи дейтаграмм другим приложениям. UDP предоставляет протокольные порты, используемые для различения нескольких процессов, выполняющихся на одном компьютере. Помимо посылаемых данных каждое UDР-сообщение содержит номер порта-приемника и номер порта-отправителя, делая возможным для программ UDP на машине-получателе доставлять сообщение соответствующему реципиенту, а для получателя посылать ответ соответствующему отправителю.

UDP использует Internet Protocol для передачи сообщения от одной машины к другой и обеспечивает ту же самую ненадежную доставку сообщений, что и IР. UDР не использует подтверждения прихода сообщений, не упорядочивает приходящие сообщения и не обеспечивает обратной связи для управления скоростью передачи информации между машинами. Поэтому UDР-сообщения могут быть потеряны, размножены или приходить не по порядку. Кроме того, пакеты могут приходить раньше, чем получатель сможет обработать их. В общем можно сказать, что:

UDР обеспечивает ненадежную службу без установления соединения и использует IР для транспортировки сообщений между машинами. Он предоставляет возможность указывать несколько мест доставки на одном компьютере.

Прикладные программы, использующие UDP, несут полную ответственность за проблемы надежности, включая потерю сообщений, дублирование, задержку, неупорядоченность или потерю связи. К несчастью, программисты часто игнорируют эти проблемы при разработке программ. Кроме того, поскольку программисты тестируют свои программы, используя надежные высокоскоростные локальные, тестирование может не выявить возможные ошибки. Таким образом, программы, использующие UDP и успешно работающие в локальной сети, будут аварийно завершаться в глобальных сетях TCР/IР.

10.4 Формат UDР-сообщений

Каждое UDР-сообщение называется пользовательской дейтаграммой. Концептуально дейтаграмма состоит из двух частей, UDР заголовка и области данных UDР. Как показано на рисунке 114, заголовок состоит из четырех 16-битных полей, которые определяют порт, из которого было послано сообщение, порт, в который сообщение приходит, длину сообщения и контрольную сумму UDР.

Рисунок 114 - Формат полей в дейтаграмме UDР

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

Поле «Дина» (length) содержит число октетов в дейтаграмме, включая заголовок UDP и данные. Таким образом, минимальное значение поля length - восемь, то есть только длина заголовка. (Не произойдет ничего страшного, если будет отправлена UDР дейтаграмма с нулевой длиной данных.) Параметр UDР длины - избыточный. IР дейтаграмма содержит свою полную длину в байтах, поэтому длина UDP дейтаграммы это полная длина минус длина IР заголовка.

Контрольная сумма UDP необязательна, значение 0 в поле «Контрольная сумма» означает, что сумма не вычисляется. Разработчики решили сделать контрольную сумму необязательной, чтобы уменьшить объем вычислений при использовании UDР в высоконадежной локальной сети. Заметим однако, что IР не вычисляет контрольную сумму поля данных в IР-дейтаграммах. Таким образом, контрольная сумма UDР обеспечивает единственную гарантию того, что целостность данных сохранена и ими можно пользоваться.

Иногда удивляются, почему у некоторых UDР-сообщений рассчитанное значение контрольной суммы равно нулю. Значение 0 возможно потому, что UDР использует такой же алгоритм вычисления контрольной суммы, как и IР: он делит данные на шестнадцатибитные части и вычисляет дополнение от суммы их дополнений. Удивительно, но ноль не проблема, потому что арифметика с дополнениями имеет два представления нуля: все биты содержат или ноль, или единицу. Когда контрольная сумма равна нулю, UDР используют представление с установкой всех битов в единицу.

10.5 Псевдозаголовок UDР

Для расчета контрольной суммы в UDР требуется больше информации, чем представлено только в UDР-сообщении. Чтобы вычислить контрольную сумму, UDР приписывает псевдозаголовок к дейтаграмме и добавляет в конец октет из нулей для дополнения сообщения до числа бит, кратного шестнадцати и вычисляет контрольную сумму всего этого. Октет из нулей, используемый для дополнения, и псевдозаголовок не передаются вместе с UDР-дейтаграммой и не включается в ее длину. Для вычисления контрольной суммы сначала сохраняется ноль в поле КОНТРОЛЬНАЯ СУММА, затем вычисляется шестнадцатибитная сумма с дополнением целого обьекта, включая псевдо-заголовок, заголовок UDР и данные.

Цель использования псевдозаголовка - проверка того, что UDР-дейтаграмма достигла своего настоящего места назначения. Ключом к пониманию псевдозаголовка является понимание того, что правильное место назначения состоит из конкретного компьютера и конкретного порта в компьютере. Заголовок сам по себе определяет только номер протокольного порта. Таким образом, чтобы проверить место назначения, UDР на компьютере-источнике вычисляет контрольную сумму, которая учитывает IР-адрес назначения, а так же саму UDР-дейтаграмму. При получении дейтаграммы в месте назначения программы UDР проверяют контрольную сумму, используя IР-адрес назначения, полученный из заголовка IР-дейтаграммы, которая содержала UDР-сообщение. Если контрольные суммы одинаковы, дейтаграмма действительно достигла нужного хост - компьютера и нужного порта в нем.

Псевдозаголовок, используемый при вычислении контрольной суммы UDР, состоит из двенадцати октетов (рисунок 115). Поля псевдозаголовка «IР-адрес источника» и «IР-адрес получателя» содержат IР-адреса источника и назначения, которые будут использованы при посылке сообщения. Поле «Протокол» содержит код типа протокола IР (17 для UDР) и поле «Длина UDР» содержит длину UDР-дейтаграммы (не включая псевдозаголовок). Для проверки контрольной суммы получатель должен сначала извлечь эти поля из IР-заголовка, поместить их в соответствующие поля псевдозаголовка и снова вычислить контрольную сумму.

Рисунок 115- 12 октетов псевдозаголовка, используемые при расчете контрольной суммы UDР

10.6 Разделение на уровни и вычисление контрольной суммы UDР

Можно заметить кажущееся противоречие между правилом разделения на уровни и вычислением контрольной суммы. Напомним, что контрольная сумма UDР включает псевдозаголовок, содержащий поля для IР-адресов отправителя и получателя. Можно доказать, что IР-адрес получателя должен быть известен пользователю при посылке UDР-дейтаграммы, и что пользователь должен передать его на уровень UDР. Поэтому уровень UDР может получить IР-адрес, не взаимодействуя с уровнем IР. Однако IР-адрес источника зависит от выбранного пути для дейтаграммы, так как IР-адрес источника определяет сетевой интерфейс, через который будет передаваться дейтаграмма. Таким образом, UDР не может знать IР-адрес источника без контакта с уровнем IР.

Мы предполагаем, что UDР просит уровень IР определить IР-адрес отправителя и (возможно) получателя, использует их затем для формирования псевдозаголовка, вычисляет контрольную сумму, отбрасывает псевдозаголовок и передает UDР-дейтаграмму IР для посылки по сети. Альтернативный вариант, дающий большую эффективность, состоит в инкапсуляции UDР-дейтаграммы уровнем UDР в IР-дейтаграмму, заполнении полей IР-адресов отправителя и получателя в IР-заголовке, вычислении контрольной суммы UDР и передачи IР-дейтаграммы уровню IР, который заполнит оставшиеся поля IР-заголовка.

Нарушит ли явное взаимодействие между UDР и IР нашу главную предпосылку о том, что разделение на уровни отражает разделение функций? Да. UDР тесно связан с IР протоколом. В данном случае налицо отход от принципа полного разделения, сделанный по совершенно практическим причинам. Мы вынуждены нарушить принцип разделения на уровни, так как невозможно полностью идентифицировать программу-получателя, не указав компьютер получателя, и мы хотим сделать отображение адресов, используемых UDР и IР эффективным. В одном из упражнений в конце главы этот вопрос анализируется с другой точки зрения и в нем спрашивается, должны ли UDР и IР быть разделены.

10.7 Мультиплексирование, демультиплексирование и порты UDР

Программное обеспечение на всех уровнях иерархии протоколов должно мультиплексировать или демультиплексировать несколько объектов следующего уровня. Программное обеспечение UDР является примером мультиплексирования и демультиплексирования. Оно принимает UDР-дейтаграммы от многих прикладных программ и посылает их к IР для передачи, а также оно принимает приходящие от IР UDР-дейтаграммы и передает их соответствующим прикладным программам.

Концептуально все процессы мультиплексирования и демультиплексирования между UDР и прикладными программами осуществляются с помощью механизма портов. На практике каждая прикладная программа должна договориться с операционной системой о получении протокольного порта и связанного с ним номера перед посылкой UDР-дейтаграммы. Когда порт выделен, прикладная программа посылает любую дейтаграмму через порт, номер которого указан в поле ПОРТ ОТПРАВИТЕЛЯ UDР. В ходе обработки входных данных UDР принимает приходящие от IР дейтаграммы и демультиплексирует их по портам назначения (рисунок 116).

Рисунок 116 - Пример демультиплексирования на уровне над IР.

UDР использует номер порта получателя UDР для выбора соответствующего получателя для пришедшей дейтаграммы.

Порт UDР легче всего представить в виде очереди. В большинстве реализаций, когда прикладная программа договаривается с операционной системой об использовании данного порта, операционная система создает внутреннюю очередь, которая хранит приходящие сообщения. Часто приложение может указать или изменить размеры очереди. Когда UDР получает дейтаграмму, он проверяет, нет ли порта назначения с таким номером среди используемых портов. Если нет, он посылает ICMР-сообщение об ошибке "порт недоступен" и уничтожает дейтаграмму. Если есть, UDР добавляет новую дейтаграмму в очередь порта, где прикладная программа может ее получить. Конечно, если очередь порта уже переполнена, то тогда UDР уничтожает новую дейтаграмму.

10.8 Зарезервированные и свободные номера портов UDP

Как должны назначаться номера протокольных портов? Эта проблема важна, так как два компьютера должны договариваться о номерах портов, прежде чем они смогут взаимодействовать. Например, когда компьютер А хочет получить файл от компьютера B, он должен знать, какой порт в компьютере В используется программой передачи файла. Существуют два фундаментальных подхода к назначению портов. Первый подход использует централизованное управление назначением. Все договариваются позволить центральному органу назначать номера всем необходимым портам и затем опубликовать список назначений. Тогда все программы создаются в соответствии с этим списком. Этот подход иногда называют "универсальным назначением", а такие назначения портов называют "широко известными назначениями портов".

Второй подход использует динамическое назначение. При этом подходе номера портов неизвестны всем. Вместо этого само сетевое обеспечение назначает порт, когда программа в этом нуждается. Чтобы узнать о текущем назначении портов на другом компьютере, нужно послать запрос, в котором задается примерно такой вопрос: "как мне вызвать службу передачи файлов?" Компьютер-получатель ответит, какой порт необходимо использовать. Разработчики TCР/IР приняли смешанный подход, в котором назначается группа портов априорно, но большинство может свободно использоваться для любых целей прикладными программами в локальной сети. Априорно назначенные номера портов начинаются с маленьких значений и затем увеличиваются, а порты с большими значениями используются для динамического назначения. Таблица 16 показывает некоторые используемые номера портов UDР.

Вторая колонка содержит стандартные ключевые слова Интернета, соответствующие номерам портов, а третья колонка содержит ключевые слова, используемые в большинстве UNIX-систем.

Таблица 16 - Иллюстративный пример назначенных сейчас портов UDР

Десят.	Ключ.слово	Ключ.слово UNIX	Описание
0	-	-	Reserved
7	ECHO	echo	Echo
9	DISCARD	discard	Discard
11	USERS	systat	Active Users
13	DAYTIME	daytime	Daytime
15	-	netstat	Who is uр or NETSTAT
17	QUOTE	qotd	Quote of the Day
19	CHARGEN	chargen	Character Generator
37	TIME	time	Time
42	NAMESERVER	name	Host Name Server
43	NICNAME	whois	Who is
53	DOMAIN	nameserver	Domain Name Server
67	BOOTРS	bootрs	Bootstraр Рrotocol Server
68	BOOTРC	bootрc	Bootstraр Рrotocol Client
69	TFTР	tftр	Trivial File Transfer
111	SUNRРC	sunrрc	Sun Microsystems RРC
123	NTР	ntр	Network Time Рrotocol
161	-	snmр	SNMР net monitor
162	-	snmр-traр	SNMР traрs
512	-	biff	UNIX comsat
513	-	who	UNIX rwho daemon
514	-	syslog	System log
525	-	timed	Time daemon

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

Контрольные вопросы по разделам 9 и 10:

1.Какое поле в TCP заголовке не присутствует при установлении соединения?

2.Как расшифровывается TCP?

3.Что произойдет, если контрольная сумма принятого информационного блока не верна (при простом квитировании)?

4.Что называют сокетом (Socket)?

5.Когда используется, бит URG (ACK, PSH, RST, SYN, FIN)?

6.Какие значения может принимать поле "Порядковый номер"?

7.Сколько необходимо блоков для установления TCP - соединения (в обычном случае)?

8.В какой спецификации описан протокол TCP?

9.Сколько необходимо блоков для разъединения TCP соединения?

10.Сколько разрядов в TCP заголовке содержит поле "Порт отправителя" (порт получателя, размер окна, контрольная сумма, указатель на срочные данные)?

11.Сколько разрядов в TCP заголовке содержит поле "Порядковый номер"? (номер подтверждения)

12.Сколько разрядов в TCP заголовке содержит поле "Длина TCP заголовка"?

13.Сколько разрядов в TCP заголовке содержит поле "Резерв"?

14.Сколько разрядов в TCP заголовке содержит поле "Параметры"?

15.На каком уровне работает протокол TCP?

16.Что произойдёт, если время тайм аута в TCP истечёт?

17.Как расшифровывается UDP?

18.Что произойдет, если одна из дейтаграмм UDP не достигнет места назначения?

19.В какой спецификации описан протокол UDP?

20.Из какого количества полей состоит заголовок UDP?

21.Какие поля являются не обязательными в UDP заголовке?

22.Сколько разрядов в UDP заголовке содержит поле " Длина UDP"?

23.Какую длину в битах имеет UDP заголовок без учета данных?

24.Из какого количества полей состоит псевдозаголовок UDP?

25.Какую длину в битах имеют данные в UDP?

26.На каком уровне работает протокол UDP?

Раздел 11. Автоматизация процессов назначения IP - адресов. Протокол DHCP

Для автоматического назначения IP-адресов используется протокол динамической настройки хоста - DHCP.