Компьютерная скорая помощь
| для будущих мам и малышей |
| всё для мобильного телефона |
 |
|
Компьютерная скорая помощь
|
|
|
||||||||||
|
Как Работает TCP
Самый распространенный сетевой протокол, используемый в Интернет это Transmission Control Protocol, или TCP. TCP использует «окно перегрузки» - число пакетов, которое должен послать или принять стек, прежде чем перейти в режим ожидания сигнала подтверждения. Чем больше размер этого окна, тем выше пропускная способность. Алгоритмы «медленного запуска» и «предотвращения перегрузки» определяют размер окна перегрузки. Максимальный размер окна перегрузки зависит от размера буфера, который ядро отводит для каждого сокета. Для каждого сокета существует значение буфера, установленное по умолчанию, которое программы могут изменять, используя системный вызов библиотек перед открытием сокета. Для некоторых операционных систем существует определенный максимум размера буфера на уровне ядра. Вы можете установить собственное значение буфера как для отправляющего, так и для принимающего конца сокета.
Чтобы достичь максимальной скорости, важно использовать оптимальный размер буфера для TCP сокета для используемого подключения. Если буферы слишком маленькие, окно перегрузки TCP некогда не откроется полностью, таким образом отправитель не сможет работать по полной. Если буферы слишком большие, отправитель попросту завалит получателя, что приведет к тому, что получатель просто будет резать пакеты и окно перегрузки выключится. Наиболее вероятна такая ситуация когда отправляющий хост по производительности лучше, чем получающий. Слишком большое окно на отправляющей стороне это не проблема, пока существует некоторый избыток памяти.
Рассчитываем Размер Буфера TCP
Предположим, что сеть не перегружена и пакеты в ней не теряются, тогда пропускная способность сети зависит прямо пропорционально от размера TCP буфера и сетевой задержки. Сетевая задержка есть не что иное, как количество времени, необходимое пакету для прохода через сеть. Чтобы сосчитать максимальную пропускную способность, нужно:
Пропускная способность = размер буфера / задержка
В обычной сети задержка между двумя офисами составит около 40ms, а в WinXP размер буфера по умолчанию равен 17,520 байт. Значит, максимальная пропускная способность будет равна:
17520 Байт / .04 секунды = .44 МБ/сек = 3.5 Мб/сек
Размер буфера по умолчанию для Mac OS X установлен в 64K, таким образом, при использовании Mac OS X у Боба получилось бы лучше, однако были бы достигнуты далеко не 100Mbps, которые по идее должны быть.
65936 Байт / .04 сек = 1.6 МБ/сек = 13 Мб/сек
(Люди, которые постоянно используют сеть, думают о битах в секунду, тогда как все оставшиеся думают о байтах, что часто приводит к путанице.)
Большинство экспертов по сетям соглашаются, что оптимальный размер буфера для определенной сети равен удвоенному произведению задержки и полосы пропускания:
Размер буфера = 2 * задержка * полоса пропускания
Программа
ping даст вам округленное время (round trip time - RTT) для сетевого соединения, что в два раза больше задержки. Формула принимает следующий вид:
Размер буфера = RTT * полоса пропускания
Для сети Боба ping вернул RTT в 80ms. Это значит, что размер буфера TCP должен быть:
.08 секунд * 100 Мбс / 8 = 1 МБ
Часто вы не знаете о пропускной способности сетевого маршрута. Определить пропускную способность сети иногда очень сложно. На сегодняшний день самой большой пропускной способностью является 1Gbps (в США, Европе и Японии), получается, что узкое место это местные сети на обоих концах. В моей практике я встречал в основном офисы, где компьютеры объединены 100Mbps сетью Ethernet. Тогда имеем следующую картину: 100Mbps=12MBps, что, согласитесь, совсем неплохо.
Перенастройка размера буфера никак не повлияет на производительность в сетях, где регламентированная скорость составляет 10Mbps или ниже; например, с хостами, соединенными через DSL, кабельный модем, ISDN, или линию T1. Существует программа
pathrate, которая выполняет хорошую работу: оценивает пропускную способность. Но она не позволяет проводить глубокий анализ полученных временных рядов. Например, не ставилась задача получать различные функции распределения, а так же недостаточен набор параметров, которые можно варьировать при проведении измерений. Программа работает только на платформе Linux и требует возможности логина на оба компьютера.
Устанавливаем размер буфера TCP
Итак, имеем две настройки, которые нужно оптимизировать: размер буфера TCP по умолчанию и максимальный размер буфера. С правами пользователя можно изменить размер буфера по умолчанию, но для изменения его максимального размера требуются права администратора. Заметьте, что большинство сегодняшних Unix-Like систем по умолчанию имеют значение максимального размера буфера TCP всего лишь 256K. В Windows нет максимального размера буфера по умолчанию, но администратор может его установить. Очень важно изменить размеры буферов у посылающей и принимающей машин. Изменение только отправляющего буфера не даст ничего, т.к. TCP согласовывает размер буфера с меньшим из двух. Это означает, что не обязательно устанавливать оптимальный размер буфера на отправляющей и принимающей машинах. Обычно делают следующее: устанавливают размер буфера на серверной стороне довольно большим (например 1,024K) и затем позволяют клиенту определить и установить «оптимальное» значение для данного сетевого маршрута. Чтобы установить размер буфера TCP, используйте метода setSendBufferSize и setReceiveBufferSize в Java, или вызов setsockopt в С. Ниже представлен пример установки размеров буфера ТСР в пределах приложения на Java:
java.net.Socket skt;
int sndsize;
int sockbufsize;
/* установка буфера отправки */
skt.setSendBufferSize(sndsize);
/* проверим получили ли мы то, что просили */
sockbufsize = skt.getSendBufferSize();
/* установим буфер получения */
skt.setReceiveBufferSize(sndsize);
/* еще разок проверим получили ли мы то, что хотели */
sockbufsize = skt.getReceiveBufferSize();
Хорошей идеей будет вызвать getSendBufferSize (или getReceiveBufferSize) после установки размера буфера. Таким образом, мы удостоверимся, что наша ОС поддерживает буферы таких размеров. Вызов setsockopt не вернет ошибку, если вы используете значение, большее чем максимальный размер буфера, но попросту будет использовать максимальный размер вместо значения, которое установили вы. Linux загадочным образом удваивает значение, которое вы передаете для размера буфера, так что когда вы делаете getSendBufferSize / getReceiveBufferSize и видите в два раза больше, чем указали, не волнуйтесь - для Linux это «нормально».
А вот и пример на С:
int skt, sndsize;
err = setsockopt(skt, SOL_SOCKET, SO_SNDBUF,
(char *)&sndsize, (int)sizeof(sndsize));
err = setsockopt(skt, SOL_SOCKET, SO_RCVBUF,
(char *)&sndsize, (int)sizeof(sndsize));
Фрагмент кода на С, проверяющий текущий размер буфера:
int sockbufsize = 0; size = sizeof(int);
err = getsockopt(skt, SOL_SOCKET, SO_RCVBUF,
(char *)&sockbufsize, &size);
Устанавливаем Максимальный Размер буфера TCP
Для большинства соединений невозможно увеличить предопределенный системой максимальный размер ТСР буфера. Например, возьмем соединение в 100Mbps между Калифорнией и Великобританией, время задержки RTT которого 150 мсек. Оптимальный размер буфера для такого соединения будет равен 1,9 МБ, что в 30 раз больше чем размер буфера по умолчанию и в 7,5 раз больше, чем максимальный размер буфера ТСР в Linux.
Чтобы поменять параметры ТСР в Linux, добавьте следующие строки в файл /etc/sysctl.conf, и затем запустите sysctl -p. Теперь наши настройки будут применяться во время загрузки.
# увеличиваем максимальный размер буфера ТСР
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
# увеличиваем ограничения автоподчтройки буфера ТСР Linux
# мин, по умолчанию, и максимальное число байт, которое можно использовать
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
Устанавливайте максимальные размеры буферов таким образом, чтобы полностью использовать ресурсы соединения. В Windows не требуется вносить каких-либо изменений, как например максимальный размер буфера ТСР по умолчанию (GlobalMaxTcpWindowSize) не определяется. На моем сайте TCP Tuning Guide web site можно найти информацию о том, как установить максимальный размер буфера в других операционных системах.
Обычно, я предлагаю следующее для большинства приложений, ориентированных на высокоскоростную (более 40Mbps), с большой задержкой (RTT > 10ms) сеть. Ваш клиент должен запустить ping, чтобы определить RTT и затем просто принять пропускную способность, равную 100Mbps. Ping трафик блокируется некоторыми сайтами. В этом случае можно воспользоваться утилитой synack, которая использует ТСР вместо ICMP для определения RTT. Если ваши пользователи разбираются в сетях, то можно предоставить им самим самостоятельно выбирать размер TCP буфера. Не правильно тупо устанавливать большие размеры буферов для всех сетевых маршрутов, особенно если приложение могут запустить через медленные линии, такие как DSL или модемы.
Linux на Помощь
Начиная с версии 2.4, в Linux добавлена возможность автоподстройки ТСР буфера отправителя. Это означает, что отправителю больше не нужно задумываться о вызове setsockopt(). Однако все еще следует выполнять setsockopt() на стороне получателя, и вам придется подкорректировать максимальный размер буфера при автоподстройке, что по умолчанию составляет лишь 128 кБ. Начиная с Linux 2.6.7, была добавлена функция автоподстройки для серверной стороны, таким образом вам не нужно больше думать о получателе. К несчастью, максимальный размер буфера ТСР все еще маленький - но хотя бы теперь это проблема системного администрирования, а не программиста.
Мои начальные результаты довольно-таки внушительные. После увеличения максимальных буферов ТСР, при соединении в 1Gbps через США (RTT = 67ms), производительность с 10Mbps при использовании Linux 2.4 поднялась до 700Mbps при использовании Linux 2.6.12, ускорение в 70 раз! На соединении из Калифорнии в Великобританию (RTT = 150 мсек), скорость с 4Mbps на Linux 2.4 выросла до 560Mbps - ускорение в 140 раз. Этого удалось достичь всего лишь увеличением максимального размера буфера ТСР.
В Linux 2.6 кроме того включены некоторые улучшения ТСР, что означает, что скорость можно увеличить еще в несколько раз. Особенно то, что в Linux 2.6 теперь используется алгоритм контроля перегрузки BIC (BIC - bus interface controller, контроллер магистрального интерфейса), который задумывался для увеличения производительности ТСР при использовании высокоскоростных линий и большими задержками. Ручная подстройка Linux 2.4 при использовании тех же соединений дает пропускную способность в 300Mbps через США и 70Mbps до Великобритании. Надеюсь, в скором времени все эти прелести появятся в Windows.
Наладка Сети
Если все попытки повысить пропускную способность закончились неудачей, то, скорее всего причина в самой сети. Итак, сначала попробуйте
netstat -s, чтобы посмотреть количество повторных передач. Если их много, то это говорит о том, что сеть перегружена, построена на плохом «железе» или вовсе с нарушением топологии. Также повторные передачи происходят в случае, когда отправляющая машина намного быстрее принимающей. Также обратите внимание на число ошибок, возвращаемых netstat - большое число ошибок также говорит о проблеме в самой сети. Мне самому с трудом верится, но очень часто причина неполадок LAN с сетями 100BT заключается в том, что хост настроен на работу в полном дуплексе, а свитч Ethernet работает в режиме полудуплекса, или наоборот. Новое оборудование автоматически согласует дуплексы, тогда как со старым могут возникнуть проблемы, результатом будет работающая, но ужасно медленная сеть. Лучше всего работать в режиме полного дуплекса, но некоторое старое оборудование 100ВТ поддерживает только полудуплекс. Смотрите TCP Tuning Guide, чтобы узнать, как проверить настройки дуплекса для вашего компьютера.
Internet2's Network Diagnostic Tool (NDT) - отличная утилита, предназначенная для определения проблем с перегрузкой и дуплексом. NDT это Java аплет, который можно запустить с одного из NDT серверов.
Обратите Внимание на Программу
scp
Для копирования файлов через Интернет обычно пользуются программой scp. К сожалению, тонкая настройка ТСР не поможет пропускной способности >scp, потому что в scp используется OpenSSL, в котором используются статически определенные потоки буферов. Эти буферы действуют на пропускную способность сети как узкое место, особенно в сетях с длинной задержкой и высокими скоростями. Питсбургская страница Сверхвысокопроизводительного Центра High Performance SSH/SCP объясняет это более подробно и, кроме того, там имеется патч для OpenSSL, устраняющий эту проблему.
8.4 Гб/с по сетям в ближайшем будущем
В ближайшем будущем мы сможем закачивать за секунды столько, сколько бы мы сейчас смогли закачать за минуты или даже часы. Такое станет возможным, если учёные из Университета Северной Каролины смогут воплотить свою технологию в жизнь.
Предполагается, что по новому сетевому протоколу мы сможем передавать информацию
со скоростью в 150,000 раз быстрее современных модемов. Tехнология, известная как
BIC-TCP или Binary Increase Congestion Transmission Control Protocol, позволяет минимизировать перегрузку сети и передавать большее число информации в каждом пакете.Протокол TCP, был разработан слишком давно, когда машины были ещё очень медленными, и пропускная способность сетей была очень низкой.
Ноябрь, 1994 г.
Документ содержит русский перевод спецификации протокола
TCP(Transmission Control Protocol ) - основного транспортного протокола стека IP , применяемого в международной компьютерной сети Internet . Оригинальный документ известен, как RFC793 .
Протокол управления передачей
(Transmission Control Protocol)
Проект DARPA Internet
Спецификация протокола
сентябрь 1981
подготовлено для
Агенства оборонных проектов расширенных исследований
Офис технологий обработки информации
1400 Wilson Boulevard
Arlington, Virginia 22209
Институтом Информатики
Университетом Южной Калифорнии
4676 Admiralty Way
Marina del Rey, California 90291
Содержание
Предисловие
1. Введение
1.1 Мотивация
1.2 Цель
1.3 О данном документе
1.4 Интерфейсы
1.5 Действие
2. Идеология протокола
2.1 Элементы системы объединенных сетей
2.2 Модель действия
2.3 Программное обеспечение хост-компьютера
2.4 Интерфейсы
2.5 Связь с другими протоколами
2.6 Надежные коммуникации
2.7 Установка соединения и его отмена
2.8 Коммутация данных
2.9 Приоритет и безопасность
2.10 Принцип устойчивости
3. Спецификация для функций протокола
3.1 Формат заголовка
3.2 Терминология
3.3 Номера последовательности
3.4 Установка соединения
3.5 Закрытие соединения
3.6 Приоритет и безопасность
3.7 Коммутация данных
3.8 Интерфейсы
3.9 Обработка событий
Словарь
Ссылки
Предисловие
Данный документ описывает Протокол управления передачей данных в DoD стан-
дарте (TCP). Данный стандарт основывается на девяти предыдущих изда-
ниях ARPA спецификации TCP, данный текст сильно отличается от них. В
него внесены большие изменения как в отношении концепций, так и в от-
ношении текста. Данное издание проясняет некоторые детали протокола и
не включает выравнивания по размеру буфера в конце письма, а также
переопределяет механизм писем как push функцию.
Джон Постел (Jon Postel)
Редактор
RFC: 793
заменяет RFC 761 и IENs: 129, 124, 112, 81, 55, 44, 40, 27, 21, 5
Протокол управления передачей
Протокол DARPA Internet
Спецификация протокола
1. Введение
Протокол управления передачей (TCP) предназначен для использования в качестве надежного протокола общения между хост-компьютерами в
коммуникационных компьютерных сетях с коммутацией пакетов, а также в системах, объединяющих такие сети.
Данный документ описывает функции, которые должны выполняться протоколом управления передачей, программу, которая реализует протокол, а
также ее интерфейс с программами или пользователями, нуждающимися в ее услугах.
1.1 Мотивация
Компьютерные коммуникационные системы играют все более важную роль в
военных, правительственных и гражданских приложениях. Этот документ в
первую очередь освещает требования к компьютерным коммуникациям в во-
енной области, и особенно к устойчивости в условиях недостаточной на-
дежности коммуникаций и возможности перегрузок. Тем не менее, многие
из этих проблем имеют место также в гражданском и правительственном
секторе.
В условиях, когда стратегические и тактические сети компьютерных ком-
муникаций возникают и исчезают, важно обеспечить средства для их со-
единения, а также стандартные протоколы коммуникации между процесса-
ми, которые бы поддерживали большой диапазон прикладных программ.
Предвидя потребность в таких стандартах, Представительство Секретари-
ата Обороны по научно-исследовательским и опытно- конструкторским ра-
ботам предъявило протокол управления передачей (Transmission Control
Protocol - TCP), описанный здесь, на основе стандартизации DoD прото-
кола коммуникаций между процессами.
TCP - это протокол обеспечения надежности прямых соединений, создан-
ный для многоуровневой иерархии протоколов, поддерживающих межсетевые
приложения. Протокол TCP обеспечивает надежность коммуникаций между
парами процессов на хост-компьютерах, включенных в различные ком-
пьютерные коммуникационные сети, которые объединены в единую систему.
В отношении надежности протоколов более низкого, чем TCP, уровня
сделаны весьма скромные запросы. TCP предполагает, что он может
получить простой, потенциально ненадежный сервис для своих датаграмм
со стороны протоколов нижнего уровня. В принципе, протокол TCP должен
быть работоспособен на большом наборе коммуникационных систем,
начиная с кабельных соединений и кончая сетями с переключением
пакетов или электрических цепей.
Протокол TCP основывается на концепциях, впервые описанных авторами
Cerf и Kahn в документе [1]. TCP занимает в многоуровневой архитек-
туре протоколов нишу непосредственно над протоколом Internet, который
позволяет протоколу TCP отправлять и получать сегменты информации пе-
ременной длины, заключенные в оболочку Internet датаграмм. Internet
датаграмма предоставляет средства для адресации отправителя и получа-
теля сегментов TCP в различных сетях. Протокол Internet также осу-
ществляет любую фрагментацию и сборку сегментов TCP, необходимую для
осуществления передачи и доставки через множество сетей и промежуточ-
ных шлюзов. Протокол Internet также обработывает информацию о приори-
тете, классификации безопасности, а также осуществляет разграничение
TCP сегментов. Так что данная информация может быть передана напрямую
через множество сетей.
Уровни протоколов
+----------------------+
| верхний уровень |
+----------------------+
| TCP |
+----------------------+
| протокол Internet |
+----------------------+
|коммуникационная сеть |
+----------------------+
Рис. 1
Большая часть этого документа написана всвязи с реализациями TCP про-
токола, которые вместе с протоколами более высокого уровня присут-
ствуют на хост-компьютере. Некоторые компьютерные системы будут вклю-
чаться в сети через главные компьютеры, содержащие протоколы уровней
TCP и Internet, а также специфическое сетевое программое обеспечение.
Спецификация TCP описывает ее интерфейс с протоколами более высокого
уровня, которые оказались осуществимы даже в случае главного компью-
тера, если реализован соответствующий протокол общения между хост-
компьютером и главным компьютером.
1.2 Цель
Протокол TCP обязан обеспечить надежный сервис для коммуникаций между
процессами в многосетевой системе. Протокол TCP должен быть общим
протоколом для коммуникаций между хост-компьютерами во множестве се-
тей.
1.3 О данном документе
Данный документ предоставляет описание поведения, ожидаемого от любой
реализации протокола TCP, а также его взаимодействия как с протокола-
ми более высокого уровня, так и с протоколами TCP на других компьюте-
рах. Оставшаяся часть данной главы дает очень краткий обзор действия
протокола и его интерфейсов. Глава 2 суммирует идейный базис для соз-
дания протокола TCP. Глава 3 дает как детальное описание поведения,
требуемого от протокола TCP при появлении различных событий (прибытие
новых сегментов, запрос от пользователя, ошибки и т.д.), так и описа-
ние деталей форматов TCP сегментов.
1.4 Интерфейсы
Протокол TCP взаимодействует с одной стороны с пользователем или при-
кладной программой, а с другой - с протоколом более низкого уровня,
таким как протокол Internet.
Интерфейс между прикладным процессом и протоколом TCP мы поясняем с
приемлемой детализацией. Этот интерфейс состоит из набора вызовов,
которые похожи на вызовы операционной системы, предоставляемые при-
кладному процессу для управления файлами. Например, в этом случае
имеются вызовы для открытия и закрытия соединений, для отправки и по-
лучения данных на установленных соединениях. Предполагается также,
что протокол TCP сможет асинхронно взаимодействовать с прикладными
программами. Хотя разработчикам TCP протокола и предоставлена значи-
тельная свобода в создании интерфейсов, которые соответствуют свой-
ствам конкретной операционной системы, все же от любой приемлемой ре-
ализации требуются некие обязательные минимальные функции интерфейса
между протоколом TCP и пользователем.
Интерфейс между протоколом TCP и протоколами более низкого уровня за-
дан в значительно меньшей степени, за исключением того, что должен
существовать некий механизм, с помощью которого эти два уровня могут
асинхронно обмениваться информацией друг с другом. Обычно полагают,
что протокол нижнего уровня задает данный интерфейс. Протокол TCP
спроектирован так, чтобы работать с весьма разнообразной средой объ-
единенных компьютерных сетей. В данном документе предполагается, что
протокол более низкого уровня - это Internet [2].
1.5 Действие
Как указывалось ранее, главной целью протокола TCP является обеспече-
ние надежного, безопасного сервиса для логических цепей или соедине-
ний между парами процессов. Чтобы обеспечить такой сервис, основыва-
ясь на менее надежных коммуникациях Internet, система должна иметь
возможности для работы в следующих областях:
- базовая передача данных
- достоверность
- управление потоком
- разделение каналов
- работа с соединениями
- приоритет и безопасность
Основные действия протокола TCP в каждой из этих областей описаны
в следующих параграфах.
Базовая передача данных
Протокол TCP способен передавать непрерывные потоки октетов
между своими клиентами в обоих направлениях, пакуя некое количес-
тво октетов в сегменты для передачи через системы Internet. В об-
щем случае протоколы TCP решают по своему усмотрению, когда произ-
водить блокировку и передачу данных.
Иногда пользователям бывает необходимо убедиться в том, что все
данные, переданные ими протоколу TCP, уже отправлены. Для этой це-
ли определена функция проталкивания (push). Чтобы убедиться в том,
что данные, отправленные протоколу TCP, действительно переданы,
отправитель указывает, что их следует протолкнуть к получателю.
Проталкивание приводит к тому, что программы протокола TCP сразу
осуществляют отправление и, соответственно, получение остающихся
данных. Правильно осуществленное проталкивание может быть невидимо
для получателя, а сама функция проталкивания может не иметь
маркера границы записи.
Достоверность
Протокол TCP должен иметь защиту от разрушения данных, потери,
дублирования и нарушения очередности получения, вызываемых
коммуникационной системой Internet. Это достигается присвоением
очередного номера каждому передаваемому октету, а также
требованием подтверждения (ACK) от программы TCP, принимающей
данные. Если подтверждения не получено в течении контрольного
интервала времени, то данные посылаются повторно. Со стороны
получателя номера очереди используются для восстановления
очередности сегментов, которые могут быть получены в неправильном
порядке, а также для ограничения возможности появления дубликатов.
Повреждения фиксируются посредством добавления к каждому
передаваемому сегменту контрольной суммы, проверки ее при
получении и последующей ликвидации дефектных сегментов.
До тех пор, пока программы протокола TCP продолжают функциони-
ровать корректно, а система Internet не развалилась полностью на
составные части, ошибки пересылки не будут влиять на правильное
получение данных. Протокол TCP защищает от ошибок коммуникационной
системы Internet.
Управление потоком
Протокол TCP дает средства получателю управлять количеством
данных, посылаемых ему отправителем. Это достигается возвратом так
называемого "окна" (window) вместе с каждым подтверждением, кото-
рое указывает диапазон приемлемых номеров, следующих за номером
последнего успешно принятого сегмента. Окно определяет количество
октетов, которое отправитель может послать до получения дальнейших
указаний.
Разделение каналов
Чтобы позволить на отдельно взятом компьютере многим процессам
одновременно использовать коммуникационные возможности уровня TCP,
протокол TCP предоставляет на каждом хост-компьютере набор адресов
или портов. Вместе с адресами сетей и хост-компьютеров на коммни-
кационном уровне Internet они образуют сокет (socket - разъем).
Каждое соединение уникальным образом идентифицируется парой соке-
тов. Таким образом, любой сокет может одновременно использоваться
во многих соединениях.
Соотнесение портов и процесов осуществляется каждым хост-
компьютером самостоятельно. Однако оказывается полезным связывать
часто используемые процессы (такие как "logger" или сервис с раз-
делением времени) с фиксированными документированными сокетами.
Этот сервис можно впоследствии использовать через известные адре-
са. Установка и настройка адресов портов для других процессов мо-
жет включать более динамичные механизмы.
Работа с соединениями
Механизмы управления потоком и обеспечения достоверности, опи-
санные выше, требуют, чтобы программы протокола TCP инициализиро-
вали и поддерживали определенную информацию о состоянии каждого
потока данных. Набор такой информации, включающий сокеты, номера
очереди, размеры окон, называется соединением. Каждое соединение
уникальным образом идентифицируется парой сокетов на двух концах.
Если два процесса желают обмениваться информацией, соответству-
ющие программы протокола TCP должны сперва установить соединение
(на каждой стороне инициализировать информаицию о статусе). По за-
вершении обмена информацией соединение должно быть расторгнуто или
закрыто, чтобы освободить ресурсы для предоставления другим поль-
зователям.
Поскольку соединения должны устанавливаться между ненадежными
хост-компьютерами и через ненадежную коммуникационную систему
Internet, то во избежание ошибочной инициализации соединений ис-
пользуется механизм подтверждения связи с хронометрированными но-
мерами очереди.
Приоритет и безопасность
Пользователи протокола TCP могут затребовать для своего соеди-
нения приоритет и безопасность. Предусмотрены принимаемые по умол-
чанию характеристики соединений, когда такие параметры не требуют-
ся.
2. Идеология протокола
2.1 Элементы системы обединенных сетей
Среда объединенных сетей состоит из хост-компьютеров, включенных в
сети, которые в свою очередь соединятся друг с другом через шлюзы.
Здесь предполагается, что компьютерные сети могут быть либо локальны-
ми (например, ETHERNET), либо большими сетями (например ARPANET), но
в любом случае они основываются на технологии коммутации пакетов. Ре-
альными агентами, создающими и потребляющими сообщения, циркулирующие
в сети, являются процессы. Протоколы различных уровней в сетях, на
шлюзах и на хост-компьютерах поддерживают систему коммуникаций между
процессами, которая обеспечивает двунаправленный поток данных по ло-
гическим соединениям между портами процессов.
Термин пакет используется здесь в общем случае для обозначения
порции данных, участвующей в отдельном элементарном акте взаимодей-
ствия между сетью и соединенным с ней хост-компьютером. В общем слу-
чае нас не будет касаться формат блоков данных, циркулирующих в сети.
С точки зрения коммуникационных сетей, хост-компьютеры - это ком-
пьютеры, связанные с сетью и являющиеся отправителями и получателями
пакетов. Процессы рассматриваются как активные элементы на хост-
компьютерах (согласно наболее общему определению процессов как испол-
няющихся программ). Предполагается, что даже терминалы, файлы и дру-
гие устройства ввода-вывода взаимодействуют друг с другом посредством
процессов. Таким образом, любые коммуникации рассматриваются как ком-
муникации между процессами.
Поскольку процесс может контролировать несколько коммуникационных
потоков, ведущих от него к другому процессу (или другим процессам),
то мы постулируем, что каждый процесс может иметь набор портов, через
которые он общается с портами других процессов.
2.2 Модель действия
Процесс пересылает данные, вызывая программу протокола TCP и пере-
давая ей в качестве аргументов буферы с данными. Протокол TCP пакует
данные из этих буферов в сегменты, а затем вызывает модуль Internet
для передачи каждого сегмента на программу протокола TCP, являющуюся
адресатом. Этот адресат в свою очередь помещает данные из сегмента в
буферы получателя и затем оповещает свего клиента о прибытии предназ-
наченных ему данных. Программы протокола TCP помещают в сегменты кон-
трольную информацию, которая затем используется ими для проверки оче-
редности передачи данных.
Модель Internet коммуникаций состоит в том, что с каждой програм-
мой протокола TCP связан модуль протокола Internet, обеспечивающий ей
интерфейс с локальной сетью. Данный модуль Internet помещает сегменты
TCP в Internet датаграммы, а затем направляет их на другой Internet
модуль или же промежуточный шлюз. Для передачи датаграммы по локаль-
ной сети она в свою очередь помещается в пакет соответствующего типа.
Коммутаторы пакетов могут осуществлять дальнейшую упаковку, фраг-
ментацию или другие операции с тем, чтобы в локальной сети осущест-
вить передачу пакетов по назначению на модуль Internet.
На шлюзах между локальными сетями датаграмма Internet освобождает-
ся от пакета локальной сети и исследуется с тем, чтобы определить, по
какой сети она должна в дальнейшем идти. Затем Internet датаграмма
упаковывается в пакет, соответствующий выбранной локальной сети, и
посылается на следующий шлюз или же прямо к конечному получателю.
Шлюз имеет возможность разбивать Internet датаграмму на более мел-
кие датаграммы-фрагменты, если это необходимо для передачи по очеред-
ной локальной сети. Чтобы осуществить это, шлюз сам создает набор
Internet датаграмм, помещая в каждую по одному фрагменты. В дальней-
шем фрагменты могут быть снова разбиты следующими шлюзами на еще бо-
лее мелкие части. Формат фрагмента Internet датаграммы спроектирован
так, чтобы адресат - модуль Internet смог собрать фрагменты снова в
исходные Internet датаграммы.
Internet модуль, являющийся адресатом, выделяет сегмент из дата-
граммы (после ее сборки в случае необходимости) и затем передает его
по назначению на программу протокола TCP.
Данная простая модель действия протокола зачастую замалчивает мно-
жество деталей. Одной из важных характеристик является тип сервиса.
Этот признак дает указание шлюзу (или модулю Internet) о выборе пара-
метров сервиса, которые должны использоваться при передаче датаграммы
в очередной локальной сети. Приоритет датаграммы указывается среди
информации о типе сервиса. Датаграммы также могут нести информацию о
безопасности с тем, чтобы позволить хост-компьютерам и шлюзам, дей-
ствующим в многоуровневой системе безопасности, подвергать проверке
соотвествующие датаграммы.
2.3 Программное обеспечение хост-компьютера
Предполагается, что программа протокола TCP является модулем опе-
рационной системы. Клиенты обращаются к протоколу TCP в значительной
степени так же, как если бы они обращались к файловой системе. Сам
протокол TCP может обращаться к другим функциям операционной системы,
к примеру, для управления структурами данных. Предполагается, что
собственно интерфейс с локальной сетью осуществляется драйвером
устройства. Протокол TCP не обращается непосредственно к драйверам
сетевых устройств, а вместо этого делает вызов для модуля Internet
протокола, который в свою очередь и обращается к драйверу устройства.
Механизм протокола TCP не исключает его реализации на входном про-
цессоре. Однако, при такой реализации протокол общения между входными
процессорами должен обеспечивать средства для поддержки описанного в
этом документе интерфейса между пользователем и протоколом TCP.
2.4 Интерфейсы
Для запросов со стороны пользователя к протоколу TCP интерфейс
TCP/пользователь обеспечивает открытие и закрытие соединения, посылку
и получение данных или же получение статуса соединения. Эти запросы
похожи на другие запросы программы пользователя к операционной систе-
ме, например, на запросы открытия, чтения и закрытия файла.
Интерфейс между протоколами TCP и Internet поддерживает запросы на
посылку и получение датаграмм, адресованных на модули TCP в хост-
компьютерах в любом месте сети Internet. Рассматриваемые запросы име-
ют аргументы для указания адреса, типа сервиса, приоритета, безопас-
ности, а также передачи другой правляющей информации.
2.5 Связь с другими протоколами
Нижеприведенная диаграмма иллюстрирует место протокола TCP в
иерархии протоколов
+------+ +-----+ +-----+ +-----+
|Telnet| | FTP | |Voice| ... | | Уровень приложений
+------+ +-----+ +-----+ +-----+
| | | |
+-----+ +-----+ +-----+
| TCP | | RTP | ... | | Уровень хостов
+-----+ +-----+ +-----+
| | |
+------------------------------+
| Internet протокол и ICMP | Уровень шлюзов
+------------------------------+
|
+------------------------------+
| протокол локальной сети | Сетевой уровень
+------------------------------+
Рис.2 Взаимосвязь протоколов
Предполагается, что протокол TCP будет в состоянии эффективно поддер-
живать протоколы более высокого уровня. Протокол TCP должен легко
взаимодействовать с такими протоколами более высокого уровня, как
ARPANET Telnet или AUDIN II THP to the TCP.
2.6 Надежные коммуникации
Поток данных, посылаемый на TCP соединение, принимается получате-
лем надежно и в соответствующей очередности.
Передача осуществляется надежно благодаря использованию подтвер-
ждений и номеров очереди. Концептуально каждому октету данных присва-
ивается номер очереди. Номер очереди для первого октета данных в сег-
менте передается вместе с этим сегментом и называется номером очереди
для сегмента. Сегменты также несут номер подтверждения, который явля-
ется номером для следующего ожидаемого октета данных, передаваемого в
обратном направлении. Когда протокол TCP передает сегмент с данными,
он помещает его копию в очередь повторной передачи и запускает тай-
мер. Когда приходит подтверждение для этих данных, соответствующий
сегмент удаляется из очереди. Если подтверждение не приходит до исте-
чения срока, то сегмент посылается повторно.
Подтверждение протокола TCP не гарантирует, что данные достигли
конечного получателя, а только то, что программа протокола TCP на
компьютере у получателя берет на себя ответственность за это.
Для направления потока данных между программами протоколов TCP
используется механизм управления потоками. Получающая программа прото-
кола TCP сообщает "окно" посылающей программе. Данное окно указывает
количество октетов (начиная с номера подтверждения), которое принима-
ющая программа TCP готова в настоящий момент принять.
2.7 Установка соединения и его отмена
Чтобы идентифицировать отдельные потоки данных, поддерживаемые
протоколом TCP, последний определяет идентификаторы портов. Поскольку
идентификаторы портов выбираются каждой программой протокола TCP не-
зависимо, то они не будут уникальны. Чтобы обеспечить уникальность
адресов для каждой программы протокола TCP, мы объединяем идентифици-
рующий эту программу Internet адрес и идентификатор порта. В резуль-
тате получаем сокет, который будет уникален во всех локальных сетях,
объединенных в единое целое.
Соединение полностью определяется парой сокетов на своих концах.
Локальный сокет может принимать участие во многих соединениях с раз-
личными чужими сокетами. Соединение можно использовать для передачи
данных в обоих направлениях, иными словами, оно является "полностью
дуплексным".
Протокол TCP волен произвольным образом связывать порты с процес-
сами. Однако при любой реализации протокола необходимо придерживаться
нескольких основополагающих концепций. Должны присутствовать общеиз-
вестные сокеты, которые протокол TCP ассоциирует исключительно с
"соответствующими им" процессами. Мы представляем себе, как будто
процессы могут "владеть"портами и что процессы могут инициировать со-
единения только с тех портов, которыми они владеют. (С точки зрения
реализации протокола "владение" ограничивается хост-компьютером, од-
нако мы можем представить себе команду пользователя по запросу порта
(Request Port) или же метод выделения группы уникальных портов данно-
му процессу, например посредством ассоциирования старших байтов в
имени порта с данным процессом).
Соединение задается командой OPEN (открыть), сделанной с локально-
го порта и имеющей аргументом чужой сокет. В ответ на такой запрос
программа протокола TCP предоставляет имя локального (короткого) со-
единения. По этому имени пользователь адресуется к данному соединению
при последующих вызовах. О соединениях следует помнить кое-какие вещи.
Мы предполагаем, что имеется некая структура данных, называемая бло-
ком управления передачей (Transmission Control Block -TCB), предназ-
наченная для сохранения описанной выше информации. Можно было бы ре-
ализовать протокол таким образом, чтобы локальное имя для соединения
было бы указателем на структуру TCB последнего. Запрос OPEN указывает
также, осуществляется ли соединение активным образом, или же происхо-
дит пассивное ожидание соединения извне.
Запрос на пассивное открытие соединения означает, что процесс ждет
получения извне запросов на соединение, вместо того, чтобы пытаться
самому установить его. Часто процесс, сделавший запрос на пассивное
открытие, будет принимать запросы на соединение от любого другого
процесса. В этом случае чужой сокет указывается как состоящий целиком
из нулей, что означает неопределенность. Неопределенные чужие сокеты
могут присутствовать лишь в командах пассивного открытия.
Сервисный процесс, желающий обслужить другие, неизвестные ему про-
цессы, мог бы осуществить запрос на пассивное открытие с указанием
неопределенного сокета. В этом случае соединение может быть установ-
лено с любым процессом, запросившим соединения с этим локальным соке-
том. Такая процедура будет полезна, если известно, что выбранный ло-
кальный сокет ассоциирован с определенным сервисом.
Общеизвестные сокеты представляют собой удобный механизм априорно-
го привязывания адреса сокета с каким-либо стандартным сервисом. На-
пример, процесс "сервер для программы Telnet" жестко связан с кон-
кретным сокетом. Другие сокеты могут быть зарезервированы за передат-
чиком файлов, Remote Job Entry, текстовым генератором, эхо-сервером,
а также Sink-процессами (последние три пункта связаны с обработкой
текстов). Адрес сокета может быть зарезервирован для доступа к проце-
дуре "просмотра", которая могла бы указывать сокет, через который
можно было бы получить новообразованные услуги. Концепция общеизвест-
ного сокета является частью TCP спецификации, однако собственно асо-
циирование сокетов с услугами выходит за рамки данного описания про-
токола (см. документ [4]).
Процессы могут осуществлять пассивные открытия соединений и ждать,
пока от других процессов придут соответсвующие завпросы на активное
открытие, а протокол TCP проинформирует их об установлении соедине-
ния. Два процесса, сделавшие друг другу одновременно запросы на ак-
тивное открытие, получат корректное соединение. Гибкость такого под-
хода становится критичной при поддержке распределенных вычислений,
когда компоненты системы взаимодействуют друг с другом асинхронным
образом.
Когда осуществляется подбор сокетов для локального запроса пассив-
ного открытия и чужого запроса на активное открытие, то принципиаль-
ное значение имеют два случая. В первом сслучае местное пассивное от-
крытие полностью определяет чужой сокет. При этом подбор должен осу-
ществляться очень аккуратно. Во втором случае во время местного пас-
сивного открытия чужой сокет не указывается. Тогда в принципе может
быть установлено соединение с любых чужих сокетов. Во всех остальных
случаях подбор сокетов имеет частичные ограничения.
Если на один и тот же местный сокет осуществлено несколько ждущих
пассивных запросов на открытие (записанных в блоки TCB), и осущест-
вляется извне активный запрос на открытие, то чужой активный сокет
будет связываться с тем блоком TCB, где было указание именно на этот
запросивший соединения сокет. И только если такого блока TCB не су-
ществует, выбор партнера осуществляется среди блоков TCB с неопреде-
ленным чужим сокетом.
Процедура установки соединения использует флаг управления синхро-
низацией (SYN) и трижды обменивается сообщениями. Такой обмен называ-
ется трехвариантным подтверждением [3].
Соединение инициируется при встрече пришедшего сегмента, несущего
флаг синхронизации (SYN), и ждущей его записи в блоке TCB. И сегмент
и запись создаются пришедшими от пользователей запросами на открытие.
Соответствие местного и чужого сокетов устанавливается при инициали-
зации соединения. Соединение признается установленным, когда номера
очередей синхронизированы в обоих направлениях между сокетами.
Отмена соединения также включает обмен сегментами, несущими на
этот раз управляющий флаг FIN.
2.8 Коммуникация данных
Набор данных, передаваемых по соединению, можно рассматривать как
поток октетов. Пользователь, отправляющий данные, указывает при за-
просе по посылку, следует ли данные, отправляемые при этом запросе,
немедленно проталкивать через сеть к получателю. Указание осуществля-
ется установкой флага PUSH (проталкивание).
Программа протокола TCP может собирать данные, принимаемые от
пользователя, а затем передавать их в сеть по своему усмотрению в ви-
де сегментов. Если же выставлен запрос на проталкивание, то протокол
должен передать все неотправленные ранее данные. Когда программа про-
токола TCP, принимающая данные, сталкивается с флагом проталкивания,
ей не следует ожидать получения новых данных по сети до тех пор, пока
уже имеющиеся данные не будут переданы ждущему их местному процессу.
Нет нужды привязывать функции проталкивания к границам сегмента.
Данные, содержащиеся в каком-либо сегменте, могут быть результатом
одного или нескольких запросов на посылку. Или же один запрос может
породить несколько сегментов.
Целью функции проталкивания и флага PUSH является проталкивание
данных через сеть от отправителя к получателю. Функция не
осуществляет обработки самих данных.
Существует связь между функцией проталкивания и использованием
буферов данных в интерфейсе между пользователем и протоколом TCP.
Каждый раз, когда в буфер получателя приходят данные с флагом PUSH,
содержимое этого буфера передается пользователдю на обработку, даже
если буфер и не был заполнен. Если приходящие данные заполняют буфер
пользователя до того, как получена команда проталкивания,
пользователю отправляется блок данных, соответствующий размеру
буфера. Протокол TCP имеет также средства для сообщения получателю,
что с некоторого момента он имеет дело со срочными данными. Протокол
TCP не пытается определить, что именно пользователь делает со ждущими
обработки срочными данными. Однако обычно предполагается, что
получающий данные процесс будет предпринимать усилия для быстрой
обработки срочных данных.
2.9 Приоритет и безопасность
Протокол TCP использует тип сервиса и опцию безопасности протокола
Internet с тем, чтобы пользователям протокола TCP обеспечить приори-
тет и безопасность на каждом соединении. Не все модули протокола TCP
обязательно будут действовать в многоуровневой системе обеспечения
безопасности. Некоторые модули ограничиваются только обычными, неспе-
цифическими соединениями, другие ограничиваются лишь первым уровнем
безопасности и закрытости. Следовательно, некоторые реализации прото-
кола TCP и услуг для пользователей могут использовать лишь часть мно-
гоуровневой системы безопасности.
Модули TCP, действующие в многоуровневой системе безопасности,
должны адекватным образом выставлять в отсылаемых сегментах флаги
безопасности и приоритета. Такие модули TCP должны также позволять
своим клиентам или вышестоящим протоколам, таким как Telnet и THP,
указывать требуемый уровень безопасности, закрытости и приоритета для
устанавливаемых соединений.
2.10 Принцип устойчивости
Все реализации протокола TCP будут следовать общему принципу
устойчивости: быть консервативным в своих действиях и предоставлять
свободу для других.
3 Спецификация для функций протокола
3.1 Формат заголовка
Передача TCP сегментов осуществляется в виде Internet датаграмм.
Заголовок датаграммы в Internet протоколе имеет несколько информаци-
онных полей, включая адреса отправляющего и принимающего хост-
компьютеров [2]. Заголовок TCP следует за Internet заголовком и до-
полняет его информацией, специфической для TCP протокола. Такое де-
ление допускает использование на уровне хост-компьютеров протоколов,
иных нежели TCP.
Формат TCP заголовка
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рис. 3 Формат TCP заголовка
Отметим, что каждая метка указывает здесь место для соответствующего
бита.
Source Port (порт отправителя) 16 бит
номер порта отправителя
Destination Port (порт получателя) 16 бит
номер порта получателя
Sequence Number (номер очереди) 32 бита
Номер очереди для первого октета данных в данном сегменте (за ис-
ключением тех случаев, когда присутствует флаг синхронизации SYN).
Если же флаг SYN присутствует, то номер очереди является инициали-
зационным (ISN), а номер первого октета данных - ISN+1.
Acknowledgment Number (номер подтверждения) 32 бита
Если установлен контрольный бит ACK, то это поле содержит следущий
номер очереди, который отправитель данной датаграммы желает полу-
чить в обратном направлении. Номера подтверждения посылаются по-
стоянно, как только соединение будет установлено.
Data Offset (смещение данных) 4 бита
Количество 32-битных слов в TCP заголовке. Указывает на начало по-
ля данных. TCP заголовок всегда кончается на 32-битной границе
слова, даже если он содержит опции.
Reserved 6 бит
Это резервное поле, должно быть заполнено нулями.
Control Bits (контрольные биты) 6 бит
Биты этого поля слева направо
URG: поле срочного указателя задействовано
ACK: поле подтверждения задействовано
PSH: функция проталкивания
RST: перезагрузка данного соединения
SYN: синхронизация номеров очереди
FIN: нет больше данных для передачи
Window (окно) 16 бит
Количество октетов данных, начиная с октета, чей номер указан в
поле подтверждения. Количество октетов, получения которых ждет
отправитель настоящего сегмента.
Checksum (контрольная сумма) 16 бит
Поле контрольной суммы - это 16-битное дополненение суммы всех 16-
битных слов заголовка и текста. Если сегмент содержит в заголовке
и тексте нечетное количество октетов, подлежащих учету в контоль-
ной сумме, последний октет будет дополнен нулями справа с тем,
чтобы образовать для предоставления контрольной сумме 16-битное
слово. Возникший при таком выравнивании октет не передается вместе
с сегментом по сети. Перед вычислением контрольной суммы поле этой
суммы заполняется нулями.
Контрольная сумма, помимо всего прочего, учитывает 96 бит псев-
дозаголовка, который для внутреннего употребления ставится перед
TCP заголовком. Этот псевдозаголовок содержит адрес отправителя,
адрес получателя, протокол и длину TCP сегмента. Такой подход
обеспечивает защиту протокола TCP от ошибшихся в маршруте сегмен-
тов. Эту информацию обрабатывает Internet протокол. Она передается
через интерфейс протокол TCP/локальная сеть в качестве аргументов
или результатов запросов от протокола TCP к протоколу IP.
+--------+--------+--------+--------+
| Адрес отправителя |
+--------+--------+--------+--------+
| Адрес получателя |
+--------+--------+--------+--------+
| нули | PTCL | длина TCP |
+--------+--------+--------+--------+
Длина TCP сегмента - это длина TCP заголовка и поля данных, из-
меренная в октетах. Это не является точным указанием количества
передаваемых по сети октетов, она не учитывает 12 октетов псевдо-
заголовка, но тем не менее расчет этого параметра все же произво-
дится.
Urgent Pointer (срочный указатель) 16 бит
Это поле сообщает текущее значение срочного указателя. Последний
является положительной величиной - смещением относительно номера
очереди данного сегмента. Срочный указатель сообщает номер очереди
для октета, следующего за срочными данными. Это поле интерпретиру-
ется только в том случае, когда в сегменте выставлен контрольный
бит URG.
Options (опции) длина переменная
Опции могут располагаться в конце TCP заголовка, а их длина кратна
8 бит. Все опции учитываются при расчете контрольной суммы. Опции
могут начинаться с любого октета. Они могут иметь два формата:
- однооктетный тип опций;
- октет типа опции, октет длины опции и октеты данных
рассматриваемой опции.
В октете длины опции учитываются октет типа опции, сам октет
длины, а также все октеты с данными.
Заметим, что список опций может оказаться короче, чем можно ука-
зать в поле Data Offset. Место в заголовке, остающееся за опцией
"End-of-Option", должно быть заполнено нулями. Протокол TCP должен
быть готов обрабатывать все опции.
В настоящее время определены следующие опции:
Тип Длина Значение
0 - конец списка опций
1 - нет операций
2 4 максимальный размер сегмента
Определения указанных опций
Конец списка опций
+--------+
|00000000| тип 0
+--------+
Этот код опции определяет конец списка опций. Конец списка может
не совпадать с концом TCP заголовка, указанным в поле Data Offset.
Эта опция используется после всех опций, но не после каждой из
них. Опцию необходимо использовать только в том случае, если иначе
не будет совпадения с концом TCP заголовка.
Нет операций
+--------+
|00000001| тип 1
+--------+
Опции этого типа могут ставиться между опциями. Целью при этом
может служить выравнивание очередной опции по границе слова. Нет
гарантии, что отправители будут использовать данную опцию. Поэтому
получатели должны быть готовы обрабатывать опции, даже если они не
будут начинаться на границе слова.
Максимальный размер сегмента
+--------+--------+--------+--------+
|00000010|00000100| макс.разм.сегм. |
+--------+--------+--------+--------+
тип 2 длина=4
Поле данных опции - 16 бит. Если опция присутствует в списке,
то она указывает для программы протокола TCP максимальный размер
получаемого сегмента, отправившей сегмент с этой опцией. Эту опцию
следует посылать лишь при первоначальном запросе на установление
соединения (т.е. в сегментах с установленным контрольным битом
SYN). Если данная опция не была использована, ограничения на раз-
мер отсутствуют.
Padding (выравнивание) длина переменная
Выравнивание TCP заголовка осуществляется с тем, чтобы убедиться в
том, что TCP заголовок заканчивается, а поле данных сегмента начи-
нается на 32-битной границе. Выравнивание выполняется нулями.
3.2 Терминология
Прежде чем мы сможем обсудить многие детали действия TCP протоко-
ла, нам необходимо ввести подробную терминологию. Для поддержания TCP
соединения необходиом иметь несколько переменных. Мы решили, что эти
переменные будут помещены в соответствующую запись - блок управления
передачей (Transmission Control Block - TCB). Среди переменных блока
TCB имеются номера местного и чужого сокетов, флаги безопасности и
приоритета для данного соединения, указатели буферов посылки и полу-
чения, указатели текущего сегмента и очереди повторной посылки. Кроме
всего этого в TCB имеются несколько переменных, имеющих отношение к
номерам очередей отправителя и получателя.
Отправление
SND.UNA - посылка неподтверждена
SND.NXT - послать следующий сегмент
SND.WND - отправить окно
SND.UP - отправить срочный указатель
SND.WL1 - номер очереди сегмента, использованный для обновления
последнего окна
SND.WL2 - номер подтверждения в сегменте, используемый для обновления
последнего окна
ISS - первоначальный номер очереди отправления
Получение
RCV.NXT - получить следующий сегмент
RCV.WND - получить окно
RCV.UP - получить срочный указатель
IRS - первоначальный номер очереди получения
Нижеприведенные диаграммы могут помочь связать некоторые из этих
переменных с местом в очереди
Очередь отправления
1 2 3 4
----------|----------|----------|----------
SND.UNA SND.NXT SND.UNA
+SND.WND
1. - старые номера очереди, которые получили подтверждение
2. - номера очереди для данных, не получивших подтверждения
3. - номера очереди, допущенные к новой передаче
4. - следующие номера очереди, чья передача еще не разрешена
Рис. 4 Очередь отправления
Окно отправления - это участок очереди, отмеченный меткой 3 на
рисунке 4.
Очередь получения
1 2 3
----------|----------|----------
RCV.NXT RCV.NXT
+RCV.WND
1. - старые номера очереди, которые получили подтверждение
2. - номера очереди, допущенные к очередному этапу получения
3. - следующие номера очереди, еще не получившие разрешения
Рис. 5 Очередь получения
Окно получения - это участок очереди, отмеченный меткой 2 на рисунке
5.
В обсуждении также часто используются некоторые переменные,
берущие свое значение из полей очередного сегмента.
Переменные для очередного сегмента
SEG.SEQ - номер очереди для сегмента
SEG.ACK - номер подтвержения для сегмента
SEG.LEN - длина сегмента
SEG.WND - окно для сегмента
SEG.UP - срочный указатель для сегмента
SEG.PRC - приоритет для сегмента
Соединение во время функционирования проходит через серии промежу-
точных состояний. Это состояния LISTEN, SYN-SENT, SYN-RECEIVED,
ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK,
TIME-WAIT, а также фиктивное состояние CLOSED. Состояние CLOSED явля-
ется фиктивным, поскольку оно представляет состояние, когда не су-
ществует блока TCP, а потому и нет соединения. Краткое описание сос-
тояний:
LISTEN - Ожидание запроса на соединение со стороны чужих портов
и программ TCP
SYN-SENT - Ожидание парного запроса на установление соединения. С
нашей стороны запрос уже сделан.
SYN-RECEIVED - Ожидание подтверждения после того, как запрос
соединения уже принят и отправлен.
ESTABLISHED - Состояние открытого соединения, принимаемые данные
можно представить пользователю. Это нормальное
состояние соединения в фазе передачи данных.
FIN-WAIT-1 - Ожидание запроса от чужой программы TCP, или
подтверждения ранее отправленного запроса на закрытие
соединения.
FIN-WAIT-2 - Ожидание запроса на закрытие соединения со стороны
чужой программы TCP.
CLOSE-WAIT - Ожидание запроса на закрытие соединения со стороны
своего клиента.
CLOSING - Ожидание подтверждения со стороны чужой программы TCP
запроса о закрытии соединения.
LAST-ACK - Ожидание запроса на закрытие соединения, ранее
отправленного чужой программе TCP (запрос включал
также подтверждение получения чужого запроса на
закрытие соединения).
TIME-WAIT - Ожидание когда истечет достаточное количество времени
и можно быть уверенным, что чужая программа TCP
получила подтверждение своего запроса на закрытие
соединения.
CLOSED - Состояние полного отсутствия соединения.
Соединение TCP переходит с одного состояния на другое в ответ на со-
бытия. Событие - это запросы клиента (открытие, посылка, получение,
закрытие, отказ, получение состояния соединения), приход сегментов, и
особенно тех, которые содержат флаги SYN, ACK, RST и FIN, а также ис-
течение выделенного времени.
Диаграмма состояний на рисунке 6 иллюстрирует лишь смену состояний, а
также вызвавшие это события, производимые действия, но не адреса, ус-
ловия ошибок, не действия, не связанные прямо с изменением состояния.
Более подробные сведения о действиях программы протокола TCP в ответ
на события приведены в последней главе.
Замечание. Данная диаграмма является лишь сводной, но не должна
восприниматься как полная спецификация.
.
Активное открытие
-------------------------
создание TCB, посылка SYN
+--------+ -----------------
| CLOSED | \
+--------+<--------------- \
| ^ \ \
Пассивное открытие | | CLOSE \ \
------------------ | | -------------- \ \
создание TCB | | ликвидация TCB \ \
V | \ \
+--------+ CLOSE \ \
| LISTEN | -------------- | |
+--------+ ликвидация TCB | |
получение SYN | | SEND | |
---------------- | | ----------- | V
+--------+ посылка SYN, ACK / \ посылка SYN +----------+
| |<------------------- --------------->| |
| SYN | получение SYN | |
| RCVD |<---------------------------------------------| SYN SENT |
| | посылка ACK | |
| |--------------------- -----------------| |
+--------+ \ / +----------+
| получение ACK для SYN | | получение SYN, ACK
| --------------------- | | ------------------
| x V V посылка ACK
| +--------+
| CLOSE | ESTAB |
| ----------- +--------+
| послать FIN CLOSE | | получить FIN
V ----------- | | ------------
+--------+ послать FIN / \ послать ACK +--------+
| FIN |<------------------- ----------------->| CLOSE |
| WAIT-1 |--------------------- | WAIT |
+--------+ \ получить FIN +--------+
| получить ACK для FIN | ------------- CLOSE |
| -------------------- | отправить ACK ----------- |
V x V послать FIN V
+--------+ +--------+ +--------+
| FIN | | CLOSING| |LAST-ACK|
| WAIT-2 | +--------+ +--------+
+--------+ Получить ACK для FIN | Получить ACK для FIN |
| -------------------- | -------------------- |
| получить FIN x V x |
| ------------ +--------+ V
\ послать ACK | TIME | +--------+
------------------------>| WAIT |----------------->| CLOSED |
+--------+ Timeout=2MSL +--------+
--------------
ликвидация TCB
3.3 Номер очереди
Основополагающей идеей в проектировании протокола является то, что
каждый октет данных, посылаемый на TCP соединение, имеет номер очере-
ди. Поскольку каждый октет пронумерован, то каждый из них может быть
опознан. Приемлемый механизм опознания является накопительным, так
что опознание номера X означает, что все октеты с предыдущими номера-
ми уже получены. Этот механизм позволяет регистрировать появление
дубликатов в условиях повторной передачи. Нумерация октетов в преде-
лах сегмента осуществляется так, чтобы первый октет данных сразу
вслед за заголовком имел наименьший номер, а следующие за ним октеты
имели номера по возрастающей.
Важно помнить о том, что количество номеров для очереди, хоть и
велико, но ограничено. Диапазон номеров - от 0 до 2**32-1. Поскольку
набор ограничен, то все арифметические операции с номерами очередей
должны осуществляться по модулю 2**32. Это совсем не означает всякий
раз предварительную арифметическую проверку номеров очереди на попа-
дание в диапазон от 2**32-1 до 0. В работе с модульной арифметикой
есть некие тонкости, поэтому нужно аккурактно программировать сравне-
ние столь больших величин. Так символ '=<' означает "меньше или рав-
но" (по модулю 2**32).
Протокол TCP должен осуществлять следующие типы сравнения для
номеров очереди:
(a) является ли номер в подтверждении номером очереди для октетов,
уже отправленных, но еще не получивших подтверждения;
(b) получили ли все октеты в сегменте подтверждение своих номеров
(т.е. следует ли удалить данный сегмент из очереди на повторную
посылку);
(c) содержит ли пришедший сегмент ожидаемые нами номера (т.е.
"перекрывает" ли этот сегмент окно получателя).
В ответ на посылку данных протокол TCP будет получать их подтвер-
ждение. Для работы с полученным подтверждением необходимо уметь де-
лать сравнение для
SND.UNA - самого старого из номеров, не имевших подтверждения,
SND.NXT - следующего номера очереди, ждущего посылки,
SEG.ACK - номера подтверждения, полученного от чужой принимающей про-
граммы TCP (следующего номера очереди, ожидаемого чужой
программой TCP),
SEG.SEQ - номера очереди первого октета в сегменте,
SEG.LEN - количества октетов в поле данных сегмента (учитывая SYN и
FIN),
SEG.SEQ+SEG.LEN-1 - номера очереди последнего октета из сегмента.
Новое подтверждение (называемое "подтверждением приемлемости") -
это подтверждение выполнимости неравенств
SND.UNA < SEG.ACK =< SND.NXT
Сегмент из очереди повторной посылки получает полное подтверждение,
если сумма его номера в очереди и длины поля данных меньше или равна
номеру подтверждения из пришедшего сегмента.
При получении данных необходимо производить операции сравнения для
следующих величин:
RCV.NXT - следующий номер из очереди приходящих сегментов, а также
левая или нижняя граница окна получения,
RCV.NXT+RCV.WND-1 - номер очереди последнего сегмента, ожидаемого в
приходящем сегменте, а также правая или верхняя граница
окна получения,
SEG.SEQ - первый номер в очереди, принесенный пришедшим сегментом,
SEG.SEQ+SEG.LEN-1 - последний номер в очереди, принесенный пришедшим
сегментом.
Считается, что сегмент перекрывает часть разрешенных номеров в
очереди получения, если
RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND или
RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND
Первая часть этого текста смотрит, попадает ли начало сегмента на ок-
но, а вторая часть - попадает ли в окно задняя часть сегмента. Если
выполняется какая-либо часть теста, то сегмент попадает в окно.
Действительность несколько сложнее. Выбирая окно нулеволй длины
или сегмент нулевой длины, мы получаем четыре варианта проверки на
приемлемость для приходящих сегментов
длина окно
сегмента получения тест
-------- --------- ---------------------------------------------
0 0 SEG.SEQ = RCV.NXT
0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
>0 0 неприемлемо
>0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND или
RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND
Заметим, что когда окно, получения нулевое, никакие сегменты прини-
маться не будут за исключением ACK сегментов. Таким образом, протокол
TCP может устанавливать нулевое окно получения при передаче данных и
получении подтверждений. Однако даже когда окно получения нулевое,
программа протокола TCP обязана обрабатывать поля RST и URG всех при-
ходящих сегментов.
Мы получили преимущество данной схемы нумерации в том, что она
допускает также защиту для определенной управляющей информации. Это
достигается косвенным образом посредством включения некоторых кон-
трольных флагов в очередь, так что они могут быть повторно посланы и
подтверждены без сбоя (т.е. будет задействована одна или несколько
копий). Управляющая информация реально находится не в поле данных
сегмента. Следовательно, мы должны принять правила косвенного присво-
ения номеров очереди сегментам управления. SYN и FIN являются един-
ственными управляющими сигналами, приемлемыми для такой защиты, и они
используются только при открытии и закрытии соединения. Для целей
поддержания очередности, сигнал SYN рассматривается как стоящий перед
первым действительным октетом данных в сегменте, куда оба они были
помещены. В то же время FIN считается стоящим после последнего реаль-
ного октета данных в сегменте. Длина сегмента (SEG.LEN) учитывает как
данные, так и номера очереди, отведенные под управление. В случае,
когда присутствует SYN, значение SEG.SEQ соответствует номеру в оче-
реди для сигнала SYN.
Выбор первоначального номера для очереди
Протокол не накладывает ограничения на многократное повторное ис-
пользование конкретного соединения. Соединение задается подбором пары
сегментов. Новые запросы на установление какого-либо соединения будут
рассматриваться как повторные реализации этого соединения. Вследствие
такого подхода возникает следующая проблема: "Как протокол TCP отли-
чает дубликаты сегментов, оставшиеся от предыдущей реализации этого
соединения?" Эта проблема становится явной, если соединение быстро
открывается и закрывается несколько раз подряд, или же если соедине-
ние прерывает свою работу с потерей информации, хранившейся в опера-
тивной памяти компьютера, и затем устанавливается повторно. Чтобы
избежать сбоя, мы должны избегать использования сегментов данной реа-
лизации соединения, когда в сети еще присутствуют те же самые номера
очереди, оставшиеся от предыдущей реализации соединения. Мы желаем
застраховаться от этого, даже если программа протокола TCP даст сбой
и потеряет всю информацию об используемых ею номерах очередей. При
создании новых соединений применяется генератор первоначальных номе-
ров очереди (ISN), который выбирает новые 32 битные значения ISN.
Генератор привязан к 32-битным часам (вероятно, фиктивным), чье зна-
чение меняется каждые 4 микросекунды. Таким образом, полный цикл ча-
сов ISN составляет примерно 4.55 часа. Поскольку мы полагаем, что
сегменты будут существовать в сети не более максимального времени
жизни сегмента (Maximum Segment Lifatime - MSL), и что MSL меньше,
чем 4.55 часа, то мы можем с основанием полагать, что номера ISN бу-
дут уникальны.
Для каждого соединения существует номер в очереди отправления и
номер в очереди получения. Первоначальный номер в очереди отправления
(ISS) выбирается программой TCP, посылающей данные в этой очереди, а
первоначальный номер в очереди получения (IRS) выясняется во время
установления соединения.
Во время установления или инициализации какого-либо соединения обе
программы протокола TCP должны синхронизировать друг с другом перво-
начальные номера очередей. Это осуществляется посредством обмена сег-
ментами, устанавливающими соединения, несущими контрольный бит, назы-
ваемый "SYN" (for synchronize - для синхронизации), несущими исходные
номера для очередей. Для краткости, сегменты, несущие бит SYN, также
называются SYN сегментами. Следовательно, решение проблемы требует
приемлемого механизма для подбора первоначального номера очереди и
немногочисленных сигналов подтверждения при обмене номерами ISN.
Синхронизация требует, чтобы каждая сторона, участвующая в соеди-
нении, посылала свой собственный первоначальный номер очереди, а так-
же получала подтверждение на это от напарника. Каждая сторона должна
также получить первоначальный номер очереди от напарника и послать
подтверждение.
1) A --> B сигнал SYN: мой номер очереди X
2) A <-- B сигнал ACK: ваш номер очереди X
3) A <-- B сигнал SYN: мой номер очереди Y
4) A --> B сигнал ACK: ваш номер очереди Y
Поскольку шаги 2 и 3 можно объединить в одно сообщение, последнее
называется подтверждением трех путей (трех сообщений).
Подтверждение трех путей необходимо, поскольку номера очереди не
привязываются к неким глобальным часам данной компьютерной сети, и
программы TCP могут иметь различные механизмы для подбора номеров
ISN. Получатель первого сигнала SYN не может знать, задержался ли
этот сигнал и уже устарел, или это не так, даже если получатель не
помнит последний номер очереди, использованный этим соединением (что
тоже не всегда возможно). Так что он должен попросить отправителя
проверить этот сигнал SYN. Подтверждение трех путей и преимущества
хронометрированной схемы обсуждаются в статье [3].
Период молчания
Чтобы быть уверенным в том, что программа TCP не создает сегмента,
несущего номер очереди, который уже используется старым сегментом,
все еще "ходящим" по сети, программа TCP должна сохранять молчание по
крайней мере в течении времени жизни сегмента (MSL) до тех пор, пока
она не назначит какие-либо номера очереди при запуске или восстанов-
лении после сбоя, когда записи в пямяти для прежних номеров из очере-
ди были потеряны. В данной спецификации MSL берется равным 2 минуты.
Это значение выбрано разработчиками и может быть изменено, если прак-
тика покажет необходимость в этом. Заметим, что если программа прото-
кола в некотором смысле повторно инициализируется, но при этом в па-
мяти остались применявшиеся ранее номера очереди, то в ожидании нужды
нет; следует лишь убедиться в том, что новые рабочие номера очередей
больше, чем применявшиеся ранее.
Концепция периода молчания в протоколе TCP
Данная спецификация ставит условие что компьютеры, потерпевшие
крах с потерей всей информации о последних номерах очередей, переда-
ваемых по открытым (т.е. не закрытым специальной командой) соедине-
ниям, будут воздерживаться от посылки каких-либо TCP сегментов в те-
чении по крайней мере максимального времени жизни сегмента (Maximum
Segment Lifetime - MSL) в системе Internet, чей частью и является
данный хост. В последующих параграфах приводится объяснение для этой
спецификации. Некоторые реализации протокола TCP могут нарушать со-
глашение о периоде молчания, рискуя при этом тем, что некоторые полу-
чатели в системе Internet будут воспринимать старые данные как новые,
или новые данные будут отброшены словно дубликаты в действительности
устаревших сегментов.
Программы протокола используют новые номер очереди всякий раз,
когда какой-либо сегмент формируется и помещается на хосте в очередь
отправления по сети. Процедура фиксирования дубликатов и алгоритм
очереди в протоколе TCP полагаются на уникальное связывание данных
сегмента с местом в очереди. Номера очереди не успевают пройти весь
диапазон в 2**32 значения, прежде чем связанные с ними данные из от-
правленного сегмента получат подтверждение от получателя, а все
копии-дубликаты упомянутого сегмента покинут сеть Internet. Без этого
условия можно предположить, что двум отдельным TCP сегментам могут
быть назначены одинаковые или перекрывающиеся номера, что вызовет
проблему у получателя при определении, какие данные являются новыми,
а какие устаревшими. Напомним, что каждый сегмент привязан как ко
множеству следующих друг за другом номеров очереди, так и к имеющимся
в этом сегменте октетам данных.
При обычных условиях программы TCP отслеживают текущий номер оче-
реди, подлежащий отправке, а также самое старое из ожидаемый подтвер-
ждений, что позволяет избежать ошибочного использования номера очере-
ди, прежде чем будет получено подтверждение от более раннего исполь-
зования этого же номера. Одно это не гарантирует, что старые данные -
дубликаты будут удалены из сети, поэтому номера очереди сделаны очень
большими, чтобы уменьшить вероятность того, что странствующие по сети
дубликаты вызовут сбой по прибытии. При скорости обмена 2
мегабайта/сек очереди в 2**32 октета хватает на 4.5 часа. Поскольку
максимальное время жизни сегмента в сети вряд ли превышает несколько
десятков секунд, это считается достаточной защитой для будущих сетей,
даже если скорости передачи данных возрастут до десятков мегабит/сек.
При скорости 100 мегабит/сек один цикл использования всех номеров
очереди составляет 5.4 минуты, что может быть достаточно мало, но еще
остается приемлемым.
Однако основной механизм регистрации дублей и поддержания очередей
может быть отменен, если программа протокола TCP, посылающая данные,
не имеет места в памяти для хранения номеров в очереди, которые она
использовала в последний раз для конкретного соединения. Например,
если программа TCP при создании всех соединений начинает с номера
очереди 0, то при сбое и повторном запуске программа TCP может по-
вторно сформировать прежнее соединение (возможно, после анализа напо-
ловину открытого соединения) и послать по нему пакеты, чьи номера в
очереди полностью совпадают или лишь частично перекрывают номера па-
кетов, которые еще присутствуют в сети и были отправлены предыдущей
реалиизацией этого же соединения. В отсутствие сведений о номерах
очереди, прежде использовавшихся для передачи информации по данному
конкретному соединению, спецификация протокола TCP рекомендует отпра-
вителю воздержаться на MSL секунд от посылки сегментов по этому со-
единению, что даст возможность сегментам, запущенным в сеть старой
реализацией соединения, покинуть систему.
От этой проблемы не защищены даже те хост-компьютеры, которые мо-
гут отслеживать текущее время и использовать его при выборе исходных
номеров очереди (т.е. даже если время используется для выбора исход-
ного номера при реализации каждого нового соединения).
В качестве примера предположим, что соединение открыто со старто-
вым номером очереди S. Предположим также, что это соединение исполь-
зуется не столь часто и возможно, функция определения исходного номе-
ра очереди (ISN(t)) принимает значение (скажем, S1), равное номеру
последнего сегмента, отправленного данной программой TCP, по этому
конкретному соединению, Теперь предположим, что именно в этот момент
хост-компьютер дал сбой, восстановился и устанавливает новую реализа-
цию этого соединения. Первоначальный номер очереди при этом будет
S1=ISN(t), а это последний номер очереди в старой реализации соедине-
ния! Если восстановление произойдет достаточно быстро, то старые ду-
бликаты, созданные с номером очереди, близким к номеру S1, могут быть
получены своим адресатом и обработаны так, как будто бы это новые
пакеты в новой реализации соединения.
Проблема состоит в том, что хост-компьютер - получатель может не
знать, как долго он был в состоянии сбоя и существуют ли еще в систе-
ме старые дубликаты, оставшиеся от прежних реализаций соединений.
Одним из путей решения этой проблемы является преднамеренная за-
держка в отправлении сегментов в течении времени MSL после восстанов-
ления вслед за крахом - это спецификация периода молчания. Хост-
компьютеры, предпочитающие избегать паузы, рискуют получить проблему
столкновения старых и новых пакетов на каком-либо адресате, пожелав-
шем не прибегать к периоду молчания.
Реализации протокола могут предложить пользователям TCP возмож-
ность выбора между ожиданием в соединениях после сбоя и несоблюдением
периода молчания для любых соединений. Очевидно, что для тех про-
грамм, где пользователь выбрал режим ожидания, в действительности, в
этом нет нужды после того, как компьютер был выключен по крайней мере
MSL секунд.
Итак, каждый отправленный сегмент занимает один или несколько но-
меров в очереди ожидания. Номера, отведенные под сегмент, являются
"занятыми" или "в работе", пока не истекут MSL секунд. При сбое опре-
деленное место в очереди в течении определенного времени продолжает
оставаться занятым октетами из последнего отправленного сегмента.
Если вскоре создается новое соединение и оно испльзует какие-либо
номера из очереди в момент, когда ими еще пользуется сегмент из пре-
дыдущей реализации соединения, то следовательно эта область перекры-
вания номеров очередей может являться причиной проблем у получателя.
3.4 Установление соединения
"Подтверждение трех путей" - это процедура, используемая при уста-
новлении соединения. Эта процедура обычно инициируется программой
протокола TCP в ответ на запрос другой программы TCP. Данная процеду-
ра также работает, если две программы TCP инициируют ее одновременно.
Когда попытка инициализации осуществляется с обоих концов одновремен-
но, каждая программа протокола TCP получает сегмент "SYN", который не
несет подтверждения для уже отправленного ею "SYN". Конечно, прибытие
старых дубликатов сегмента "SYN" может произвести впечатление на по-
лучателя, будто осуществляется одновременное открытие соединения.
Корректное применение сегментов "перезагрузки" может предотвратить
двусмысленность таких ситуаций.
Ниже приведены несколько примеров инициализации соединений. Хотя
эти примеры не показывают синхронизации соединения с помощью сегмен-
тов, несущих данные, это совершенно правомерно, поскольку программа
TCP, получающая сегменты, не передаст данные своему клиенту, пока не
станет очевидным корректность данных (т.е. данные должны
"складироваться" пользователем до тех пор, пока соединение не перей-
дет в состояние ESTABLISHED). Подтверждение трех путей уменьшает ве-
роятность появления ложных соединений. Получение информации для такой
проверки достигается посредством реализации обмена между памятью ком-
пьютера и циркулирующими в сети сообщениями.
Простейшая процедура подтверждения трех путей показана ниже на
рисунке 7. Рисунки следует интерпретировать следующим образом. Для
удобства каждая строка пронумерована. Правые стрелки (-->) показывают
отправление TCP сегмента от программы TCP A в программу TCB B, или же
получение сегмента программой B из программы A. Левые стрелки (<--)
показывают обратные процессы. Многоточие (...) показывает сегмент,
который все еще задерживается в сети. "XXX" указывает на сегмент,
который потерян или отвергнут. Комментарии появляются в скобках.
Здесь "состояния" программы протокола TCP соответствуют моменту сразу
после посылки или получения сегмента (содержимое этого сегмента пока-
зано в средней колонке каждой строки). Содержимое сегмента в приво-
дится в сокращенной форме и представляет собой номер очереди, флаги
управления и поле ACK. Остальные поля сегмента, такие как окно, длина
и поле данных остаются за рамками нашего интереса.
TCP A TCP B
1. CLOSED LISTEN
2. SYN-SENT --> <SEQ=100><CTL=SYN> --> SYN-RECEIVED
3. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
4. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED
5. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK><DATA> --> ESTABLISHED
Основная процедура подтверждения трех путей для
синхронизации соединения
Рисунок 7.
На строке 2 рисунка 7 программа TCP A начинает с посылки сигнала
SYN, показывая тем самым, что она будет использовать нимера очереди,
начиная с номера 100. На строке 3 программа TCB B посылает сигнал
SYN, а также подтверждение о том, что сигнал SYN со стороны программы
TCP A получен. Заметим, что поле подтверждения информирует о том, что
программа TCP B в данный момент ожидает получение номера 101. Послед-
нее также подтверждает, что сигнал SYN уже занял место в очереди под
номером 100.
На строке 4 для отправленного программой TCP B в строке 3 сигнала
SYN программа TCP A дает ответ с помощью пустого сегмента, содержаще-
го сигнал ACK . В строке 5 программа TCP A передает по сети уже некую
порцию данных. Заметим, что сегмент в строке 5 имеет тот же номер
очереди, что был у сегмента в строке 4, поскольку сигнал ACK в очере-
ди места не занимает (если бы это было не так, то нам следовало обза-
вестись подтверждением -ACK- для самого подтверждения!).
На рисунке 8 показана та же инициализация с незначительными услож-
нениями. Каждая программа TCP проходит по очереди состояния CLOSED,
SYN-SENT, SYN-RECIEVED и наконец, ESTABLISHED.
TCP A TCP B
1.CLOSED CLOSED
2.SYN-SENT --> <SEQ=100><CTL=SYN> ...
3.SYN-RECEIVED <-- <SEQ=300><CTL=SYN> <-- SYN-SENT
4. ... <SEQ=100><CTL=SYN> --> SYN-RECEIVED
5.SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ...
6.ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
7. ... <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED
Одновременная синхронизация соединения
Рисунок 8
Главной причиной для приненения подтверждения трех путей является
попытка преотвратить возникновение сбоев при получении старых дубли-
катов, инициирующих соединение. Для работы с подтверждением трех пу-
тей придумано специальное контрольное сообщение - перезагрузка
(reset). Если получающая сигнал программа TCP находится не в синхро-
низированном состоянии (т.е. в SYN-SENT, SYN-RECEIVED), то она воз-
вращает сигнал LISTEN, показывая, что она получила приемлемый сигнал
перезагрузки. Если же программа TCP находится в одном из синхронизи-
рованных состояний (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT,
CLOSING, LAST-ACK, TIME-WAIT), то она ликвидирует соединение и про-
информирует об этом своего клиента. Мы обсудим ниже такую ситуацию
при рассмотрении "наполовину открытых" соединений.
TCP A TCP B
1.CLOSED LISTEN
2.SYN-SENT --> <SEQ=100><CTL=SYN> ...
3.(дубликат) ... <SEQ=90><CTL=SYN> --> SYN-RECEIVED
4.SYN-SENT <-- <SEQ=300><ACK=91><CTL=SYN,ACK> <-- SYN-RECEIVED
5.SYN-SENT --> <SEQ=91><CTL=RST> --> LISTEN
6. ... <SEQ=100><CTL=SYN> --> SYN-RECEIVED
7.SYN-SENT <-- <SEQ=400><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
8.ESTABLISHED --> <SEQ=101><ACK=401><CTL=ACK> --> ESTABLISHED
Получение старого дубликата сигнала SYN
Рисунок 9
В качестве простого примера рассмотрим ситуацию с получением ста-
рых дубликатов на рисунке 9. На строке 3 старый дубликат сигнала SYN
достигает программу TCP B. Последняя не может определить, что это
старый дубликат, и поэтому отвечает обычным образом (строка 4). Про-
грамма TCP A обнаруживает ошибочное значение в поле ACK и поэтому
возвращает сигнал RST (перезагрузка). При этом значение поля SEQ вы-
бирается таким образом, чтобы сделать сегмент правдоподобным. Про-
грамма TCP B по получении сигнала RST переходит в состояние LISTEN.
Когда на строке 6 сигнал SYN, действительный, а не устаревший, дости-
гает программу TCP B, процесс синхронизации происходит нормально.
Если же сигнал SYN на строке 6 достигает программу TCP B прежде сиг-
нала RST, может возникнуть более сложная комбинация обмена с посылкой
RST в обоих направлениях.
Наполовину открытые соединения и другие аномалии
Уже установившееся соединение называется "наполовину открытым",
если одна из программ TCP закрыла соединение, или отказалась от него.
Причем сделала это на своем конце, не предупредив своего партнера.
Также такая ситуация может возникнуть, если нарушена синхронизация на
концах линии вследствие сбоя, приведшего к потере информации в памя-
ти. Если на таких соединениях делается попытка отправить данные в
каком-либо направлении, то автоматически производится перезагрузка
соединения. Однако пердполагается, что наполовину открытые соединения
являются редкостью, а процедура восстановления применяется в сети
весьма умеренно.
Если на конце A соединение считается уже несуществующим, а клиент
на конце B пытается послать данные, то это приведет к тому, что про-
грамма TCP на конце B получит контрольное сообщение о перезагрузке.
Такое сообщение показывает программе TCP на конце B, что что-то не-
правильно и ей предлагается ликвидировать это соединение.
Предположим, что два клиента в точках A и B общаются друг с дру-
гом, и в этот момент происходит крах, приводящий к потере информации
в памяти у программы TCP на конце A. В зависимости от операционной
системы, обслуживающей программу TCP A, вероятно, будет задейстовован
некий механизм исправления ошибки. Когда программа TCP A будет запу-
щена вновь, она, вероятно, вновь начнет свою работу с самого начала
или же с инструкции преодоления сбоя. В результате, программа A, ве-
роятно, попытается открыть (OPEN) соединение или послать информацию
(SEND) через соединение, которое, как она полагает, является откры-
тым. В последнем случае от местной программы TCP (на конце A) будет
получено сообщение "соединение не открыто". При попытке установить
соединение программа TCP A будет посылать сегмент, содержащий сигнал
SYN. Такой сценарий приводит к ситуации, показанной на рисунке 10.
После того, как программа TCP A потерпит крах, пользователь попытает-
ся повторно открыть соединение. Программа TCP B тем временем продол-
жает полагать, будто соединение остается открытым.
TCP A TCP B
1.сбой (номер посылки 300, получения - 100)
2.CLOSED ESTABLISHED
3.SYN-SENT --> <SEQ=400><CTL=SYN> --> (??)
4.(!!) <-- <SEQ=300><ACK=100><CTL=SYN> <-- ESTABLISHED
5.SYN-SENT --> <SEQ=100><CTL=RST> --> (ликвидация!!)
6.SYN-SENT CLOSED
7.SYN-SENT --> <SEQ=400><CTL=SYN> -->
Обнаружение наполовину открытого соединения
Рисунок 10
Когда на строке 3 сигнал SYN достигает программу TCP B, находящую-
ся в синхронизированном состоянии, а пришедший сегмент находится за
пределами окна, программа TCP B отвечает на это его подтверждением,
показывает номер очереди, который она желает получить (ACK=100). Про-
грамма TCP A, видя, что сегмент на строке 4 не подтвердил отправлен-
ную ею информацию, фиксирует отсутствие синхронизации и посылает сиг-
нал перезагрузки (RST), поскольку обнаружено, что соединение является
открытым наполовину. На строке 5 программа TCP B ликвидирует соедине-
ние. Программа TCP A будет продолжать попытки установить соедлинение.
Теперь возникшая проблема решается простым подтверждением трех путей
(рисунок 7).
Другой интересный сюжет имеет место, если программа TCP A терпит
крах, а программа TCP B, полагая, что находится в состоянии синхрони-
зации, пытается послать данные. Эта ситуация показана на рисунке 11.
В этом случае данные, отправленные программой TCP B, и пришедшие на
программу TCP A (строка 2). будут отвергнуты, поскольку используемого
ими соединения не существует. На основании этого программа TCP A по-
сылает сигнал RST. Как только сигнал RST принят программой TCP B, он
будет рассмотрен, а использованное прежде соединение будет ликвидиро-
вано.
TCP A TCP B
1.сбой (номер посылки 300, получения - 100)
2.(??) <-- <SEQ=300><ACK=100><DATA=10><CTL=SYN> <-- ESTABLISHED
3. --> <SEQ=100><CTL=RST> --> (ликвидация!!)
Активная сторона приводит к обнаружению
наполовину открытого соединения
Рисунок 11
На рисунке 12 показано, что две программы TCP - A и B - ,имея
пасивное состояние, ждут сигнала SYN. Старый дубликат сигнала, дости-
гает программу TCP B (строка 2), запускает ее. Возвращается сигнал
SYN-ACK (строка 3) и заставляет программу TCP A генерировать сигнал
RST (на строке 3 сигнал ACK неприемлем). Программа TCP B принимает
команду перезагрузки и волзвращается в пассивное состояние LISTEN.
TCP A TCP B
1.LISTEN LISTEN
2. ... <SEQ=Z><CTL=SYN> --> SYN-RECEIVED
3. (??) <-- <SEQ=X><ACK=Z+1><CTL=SYN,ACK> <-- SYN-RECEIVED
4. --> <SEQ=Z+1><CTL=RST> --> возврат в LISTEN
5.LISTEN LISTEN
Старый дубликат сигнала SYN инициирует перезагрузку
на двух пассивных сокетах
Рисунок 12
Может быть множество других вариаций, которые могут быть объяснены
нижеописанными правилами для создания и обработки сигналов RST.
Создание сигнала перезагрузки
Согласно главному правилу, сигнал перезагрузки (RST) должен посы-
латься всякий раз, когда приходит сегмент, который очевидным образом
не предназначен для данного соединения. Если непонятно, имеет ли мес-
то данный случай, следует воздержаться от перезагрузки.
Можно выделить три группы состояний для соединения:
1. Если соединения не существует (CLOSED), то сигнал перезагрузки по-
сылается в ответ на любой пришедший сегмент, за исключением
встречного сигнала перезагрузки. В частности, сигналы SYN, адресо-
ванные на несуществующее соединение, ответгаются именно таким об-
разом.
Если приходящий сегмент имеет флаг в поле ACK, то сегмент с сигна-
лом перезагрузки получает номер для очереди из поля ACK первого
сегмента. В противном случае сегмент с сигналом перезагрузки имеет
нулевой номер очереди и значение в поле ACK, равным сумме номера
очереди пришедшего сегмента и его же длины. Соединение остается в
состоянии CLOSED.
2. Если соединение находится в каком-либо несинхронизированном состо-
янии (LISTEN, SYN-SENT, SYN-RECEIVED), если какие-либо подтвержде-
ния пришедшего сегмента еще не отправлены (сегмент несет неприем-
лемое значение в поле ACK) или пришедший сегмент имеет уровень
безопасности/закрытости не соответствующий уровню и защите данного
соединения, то отправляется сигнал перезагрузки.
Если наш сигнал SYN не был подтвержден, а уровень приоритета при-
шедшего сегмента больше запрошенного уровня, то либо будет увели-
чен местный уровень приоритета (если это приемлемо для пользовате-
ля и системы), либо будет послан сигнал перезагрузки. Или же если
уровень приоритета пришедшего сегмента меньше запрошенного, то об-
работка будет продолжена далее, как если бы уровень был таким же
(если чужая программа TCP не может повысить уровень приоритета до
нашего, то это будет отмечено в следующем отправляемом ею сегмен-
те, тогда и будет закрыто соединение). Если наш сигнал SYN получил
подтверждение (возможно в пришедшем к нам сегменте), то уровень
приоритета пришедшего сегмента должен точно соответствовать мест-
ному уровню. Если последнее условие не выполняется, посылается
сигнал перезагрузки.
Если приходящий сегмент несет сигнал ACK, то сигнал перезагрузки
будет иметь номер в очереди, соответствующий номеру сигнала ACK в
пришедшем сегменте. В противном случае сигнал перезагрузки будет
иметь нулевой номер очереди, а сигнал ACK - номер, равный сумме
номера пришедшего сегмента и его же длины. Соединение не меняет
своего состояния.
3. Если соединение находится в синхронизированном состоянии
(ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-
ACK, TIME-WAIT), то любой неприемлемый сегмент (не попадающий в
окно номеров очереди, несущий неправильный номер подтверждения)
должен приводить к появлению сегмента с пустым полем подтвержде-
ния, содержащего текущий номер в очереди на посылку, а также под-
тверждение, указывающее на следующий ожидаемый с этого соединения
номер. Соединение остается в своем прежнем состоянии.
Если пришедший сегмент имеет уровень защиты, изоляции или прио-
ритета, не соответствующий местному уровню соединения, то отправ-
ляется сигнал перезагрузки, а соединение переходит в состояние
CLOSED. Сигнал перезагрузки имеет номер очереди, соответствующий
номеру сигнала ACK в пришедшем сегменте.
Обработка сигнала на перезагрузку
Для всех состояний, кроме SYN-SENT, все сегменты с сигналом пере-
загрузки (RST) проходят проверку полей SEQ. Сигнал перезагрузки приз-
нается, если его номер очереди попадает в окно. В состоянии же SYN-
SENT (сигнал RST получен в ответ на посылку инициирующего сигнала
SYN), сигнал RST признается, если поле ACK подтверждает ранее сделан-
ную посылку сигнала SYN.
Получатель сигнала RST сперва проверяет его, и лишь потом меняет
свое состояние. Если получатель находился в состоянии LISTEN, то он
игнорирует сигнал. Если получатель находился в состоянии SYN-
RECEIVED, то он возвращается вновь в состояние LISTEN. В иных случаях
плучатель ликивдирует соединение и переходит в состояние CLOSED. Если
получатель находтся в каком-либо ином состоянии, то он ликвидирует
соединение и прежде чем перейти в состояние CLOSED, оповещает об этом
своего клиента.
3.5 Закрытие соединения
Состояние CLOSED означает "я не имею данных для передачи". Конеч-
но, закрытие полнодуплексного соединения является предметом множества
интерпретаций, поскольку не очевидно, как интерпретировать в соедине-
нии сторону, получающую информацию. Мы решили интерпретировать CLOSE
в упрощенной манере. Клиент, находящийся в состоянии CLOSE, может все
еще получать информацию (RECEIVE) до тех пор, пока партнер тоже не
сообщит, что переходит в состояние CLOSE. Таким образом, клиент может
изящно завершить работу на своем конце соединения. Программа протоко-
ла TCP гарантированно получит все буферы с информацией, отправленные
до того, как соединение было закрыто. Поэтому клиенту, не ждущему
информации с соединения, следует лишь ждать сообщения об успешном
закрытии этого соединения, что означает, что все данные получены про-
граммой TCP, принимающей информацию. Клиенты должны сохранять уже
закрытые ими для чтения информации соединения до тех пор, пока про-
грамма протокола TCP не сообщит им, что такой информации больше нет.
Особое значение имеют три случая:
1) клиент инициирует закрытие соединения, дав команду своей программе
протокола TCP.
2) закрытие соединения начинается с того, что напарник посылает сюда
управляющий сигнал FIN.
3) оба клиента дают команду на закрытие одновременно.
Случай 1 Местный клиент инициирует закрытие
В этом случае создается сегмент с сигналом FIN и помещается в
очередь сегментов, ждущих отправления. После этого программа TCP
уже не будет принимать от этого клиента каких-либо команд на от-
правление данных по закрытому соединению, а сама переходит в со-
стояние FIN-WAIT-1. Тем не менее, в этом состоянии еще возможно
получение клиентом данных с этого соединения. Все сегменты, стоя-
щие в очереди, и сам сегмент с сигналом FIN будут в случае необхо-
димости посылаться напарнику вновь и вновь, пока не получат своего
подтверждения. Когда программа TCP партнера подтвердит получение
сигнала FIN, и сама отправит сюда свой сигнал FIN, местная про-
грамма может подтвердить получение последнего. Заметим, что про-
грамма TCP, получающая сигнал FIN, будет подтверждать его, но не
будет посылать своего собственного сигнала FIN до тех пор, пока ее
клиент тоже не закроет соединения.
Случай 2 Программа TCP получает из сети сигнал FIN.
Если из сети приходит невостребованный сигнал FIN, то принимаю-
щая его программа TCP может подтвердить получение такого сигнала и
оповестить своего клиента о том, что соединение закрыто. Клиент
ответит командой CLOSE, по которой программа TCP может после пере-
сылки оставшихся данных послать партнеру сигнал FIN. После этого
программа TCP ждет, пока не прийдет подтверждение на отправленный
ею сигнал FIN, после чего она ликвидирует соединение. Если под-
тверждения не было по истечении отведенного времени, то соединение
ликвидируется в принудительном порядке, о чем дается сообщение
клиенту.
Случай 3 Оба клиента закрывают соединение одновременно.
Одновременное закрытие соединения клиентами на обоих концах
приводит к обмену сегментами с сигналом FIN. Когда все сегменты,
стоящие в очереди перед сегментом с FIN, будут переданы и получат
подтверждение, каждая программа TCP может послать подтверждение на
полученный ею сигнал FIN. Обе программы по получении этих под-
тверждений будут ликвидировать соединение.
TCP A TCP B
1.ESTABLISHED ESTABLISHED
2.(Close)
FIN-WAIT-1 --> <SEQ=100><ACK=300><CTL=FIN,ACK> --> CLOSE-WAIT
3.FIN-WAIT-2 <-- <SEQ=300><ACK=101><CTL=ACK> <-- CLOSE-WAIT
4. (Close)
TIME-WAIT <-- <SEQ=300><ACK=101><CTL=FIN,ACK> <-- LAST-ACK
5.TIME-WAIT --> <SEQ=101><ACK=301><CTL=ACK> --> CLOSED
6. (2 MSL)
CLOSED
Нормальная процедура закрытия
Рисунок 13
TCP A TCP B
1.ESTABLISHED ESTABLISHED
2.(Close) (Close)
FIN-WAIT-1 --> <SEQ=100><ACK=300><CTL=FIN,ACK> ... FIN-WAIT-1
<-- <SEQ=300><ACK=100><CTL=FIN,ACK> <--
... <SEQ=100><ACK=300><CTL=FIN,ACK> -->
3.CLOSING --> <SEQ=101><ACK=301><CTL=ACK> ... CLOSING
<-- <SEQ=301><ACK=101><CTL=ACK> <--
... <SEQ=101><ACK=301><CTL=ACK> -->
4.TIME-WAIT TIME-WAIT
(2 MSL) (2 MSL)
CLOSED CLOSED
Процедура одновременного закрытия соединения с обоих концов
Рисунок 14
3.6 Приоритет и безопасность
Замысел этой части протокола состоит в том, что соединение может
существовать лишь между портами, имеющими одинаковое значение без-
опасности и закрытости, а уровень приоритета должен соответствовать
наибольшему из запрошенных этими двумя портами значений.
Параметры приоритета и безопасности, применяемые в протоколе TCP,
в точности соответствуют заявленным в протоколе Internet (IP) [2]. В
спецификации протокола TCP понятие "безопасность" должно включать
используемые в IP параметры, которые включают собственно безопас-
ность, закрытость, определение группы для пользователей, а также под-
держку различных ограничений.
Попытка соединиться с неприемлемыми значениями безопасности/ за-
крытости или же с недостаточно малым значением приоритета должна
отвергаться через посылку сигнала перезагрузки. Отказ в соединении по
причине недостаточного приоритета может осуществляться только после
получения подтверждения на сигнал SYN.
Заметим, что модули TCP, работающие лишь с значением приоритета,
установленным по умолчанию, будут тем не менее проверять приоритет
пришедших сегментов и, в случае необходимости, повышать уровень прио-
ритета, применяемый в данном конкретном соединении.
Параметры безопасности могут быть использованы даже программами
TCP, не поддерживающими систему безопасности (значения поля безопас-
ности относилось бы к неклассифицируемым данным). Таким образом,
хост-компьютеры, не поддерживающие систему безопасности, должны быть
готовы принимать параметры безопасности, хотя сами они в посылке та-
ких параметров не нуждаются.
3.7 Передача данных
Коль соединение установлено, передача данных осуществляется с по-
мощью обмена сегментами. Т.к. сегменты могут быть потеряны в резуль-
тате ошибок (например, ошибки в контрольной сумме) или перегрузки
сети, то программа протокола TCP использует механизм повторной посыл-
ки (по истечении определенного времени) с тем, чтобы убедиться в по-
лучении каждого сегмента. В главе, посвященной номерам очередей, об-
суждалось, как программа TCP в сегментах осуществляет проверку номе-
ров очередей и номеров подтверждения на предмет их корректности.
Отправитель данных с помощью значения переменной SND.NXT отслежи-
вает следующий номер в очереди, подлежащий отправке. Получатель дан-
ных с помощью переменной RCV.NXT отслеживает следующий номер, прибы-
тие которого он ожидает. В переменную SND.UNA отправитель данных по-
мещает значение самого старого номера, который был отправлен, но еще
не получил подтверждения. Если бы поток данных моментально иссяк, а
все отправленные данные получили подтверждение, то тогда бы все эти
при переменные содержали одинаковое значение.
Когда отправитель информации создает и посылает некий сегмент, он
увеличивает значение переменной SND.NXT. Адресат по получении сегмен-
та увеличивает значение переменной RCV.NXT и отправляет подтвержде-
ние. Когда программа TCP, пославшая данные, получает подтверждение,
она увеличивает значение SND.UNA. Разность в значениях этих перемен-
ных является мерой, характеризующей задержку сегментов в сети. Вели-
чина, на которую надо всякий раз осуществлять приращение значения
этих переменных, является длиной поля данных в сегменте. Заметим, что
поскольку соеднения находятся в состоянии ESTABLISHED, все сегменты,
в дополнение к собственно данным, должны нести некую информацию о
подтверждении ранее отправленных сегментов.
Запрос пользователя о закрытии соединения (CLOSE) подразумевает
использование функции проталкивания, что осуществляется с помощью
контрольного флага FIN приходящем сегменте
Контрольное время повторной посылки
Вследствие непостоянства сетей, составляющих единую объединенную
систему, и большого числа клиентов, пользующихся услугами TCP соеди-
нений, существует необходимость в динамическом определении контроль-
ного времени повторной посылки. В качестве иллюстрации здесь приво-
дится одна из процедур определения этого времени.
Пример процедуры измерения контрольного времени для повторной
посылки сегментов
Во-первых, измерьте время, прошедшее между посылкой октета дан-
ных, имеющего некий определенный номер в очереди, и получение под-
тверждения, указывающего наряду с другими и на этот номер (посыла-
емые сегменты не обязаны соответствовать полученным сегментам).
Измеренная временная задержка - это время обращения (Round Trip
Time - RTT). Следующий шаг - вычисление усредненного времени обра-
щения (Smoothed Round Trip Time - SRTT):
SRTT = (ALPHA * RSTT) + ( (1-ALPHA) * RTT)
Затем с помощью найденного значения определяется контрольное время
повторной посылки (Retransmission Timeout - RTO):
RTO = min[ UBOUND, max[ LBOUND, (BETA * SRTT) ]]
где UBOUND - верний предел контрольного времени (например, 1 мин),
LBOUND - нижний предел (например, 1 сек). ALPHA - фактор сглажива-
ния (например, от 0.8 до 0.9), а BETA - фактор изменения задержки
(например, от 1.3 до 2.0).
Передача срочной информации
Механизм срочной передачи протокола TCP предназначен для того,
чтобы клиент, отправляющий данные, мог побудить получателя принять
некую срочную информацию, а также позволить программе TCP, принимаю-
щей данные, информировать своего клиента, когда вся имеющаяся на на-
стоящий момент информация будет получена.
Данный механизм позволяет помечать некую точку в потоке данных как
конец блока срочной информации. Когда в программе TCP, принимающей
данные, данная точка окажется впереди индикатора номера в очереди
получения (RCV.NXT), эта программа TCP должна дать команду своему
клиенту перейти в "срочный режим". Когда номер в очереди получения
догонит срочный указатель в потоке данных, программа TCP должна дать
команду клиенту прийти в "нормальный режим". Если срочный указатель
сменит свое положение, когда клиент находится в "срочном режиме",
последний не узнает об этом.
Данный метод использует поле флага срочности, котрый присутствует
во всех передаваемых сегментах. Единица в поле контрольного флага URG
означает, что задействовано поле срочности . Чтобы получить указатель
этого поля в потоке данных, необходимо дополнить его номером рассмат-
риваемого сегмента в очереди. Отсутствие флага URG означает отсут-
ствие у отправителя непосланных срочных данных.
При указании срочности клиент должен также послать по крайней мере
один октет данных. Если клиент, помещающий данные, дополнительно за-
кажет функцию проталкивания, то передача срочной информации ждущему
ее процессу многократно ускорится.
Управление окном
Окно, посылаемое с каждым сегментом, указывает диапазон номаров
очереди, которые отправитель окна (он же получатель данных) готов
принять в настоящее время. Предполагается, что такой механизм связан
с наличием в данный момент места в буфере данных.
Указание окна большого размера стимулирует передачу. Но если при-
шло большее количество данных, чем может быть принято программой TCP,
данные будут отброшены. Это приведет к излишним пересылкам информации
и ненужному увеличению нагрузки на сеть и программу TCP. Указание
окна малого размера может ограничить передачу данных скоростью, кото-
рая определяется временем путешествия по сети после каждого посыла-
емого сегмента.
Такие механизмы протокола позволяют программе TCP заявлять большое
окно, но впоследствии объявлять окна намного меньшего размера и не
принимать такое большое количество данных. Такое, так называемое,
сокращение окна выглядит довольно обескураживающе. Принцип устойчиво-
сти диктует, чтобы программа протокола TCP не сокращала сама окно, но
была бы готова к таким действиям со стороны другой программы TCP.
Программа TCP, посылающая данные, должна быть готова принять от
клиента и передать по сети по крайней мере один октет новых данных,
даже если окно отправления равно нулю. Программа TCP должна периоди-
чески повторно посылать данные другой программе TCP, даже если окно
нулевое. В случае нулевого окна рекомендуется использовать интервал
повторной посылки в две минуты. Такие повторные посылки важны для
того, чтобы гарантировать, что в случае, когда одна из двух программ
TCP имеет нулевое окно, открытие этого окна будет гарантированно со-
общено партнеру.
Когда программа TCP, получающая данные, имеет нулевое окно, но к
ней приходит сегмент, то эта программа должна послать подтверждение и
указать, какой следующий номер в очереди она ожидает и какое у нее
окно в настоящий момент (окно нулевое).
Программа TCP пакует предназначенные к в пересылке данные в сег-
менты, заполняющие текущее окно. Однако она не может перепаковать уже
имеющиеся сегменты в очереди на повторную посылку. Такая перепаковка
хоть и не обязательна, но может быть полезна.
В соединении, имеющем односторонний поток данных, информация об
окне будет передаваться с сегментами подтверждения, а они будут все
иметь одинаковый номер очереди. Поэтому не будет способа восстановить
их очередность при получении. Это не является серьезной проблемой, но
может случайно привести к получению информации об окне из какого-
нибудь устаревшего сообщения. Во избежание такой проблемы должен осу-
ществляться отсев и информация об окне должна браться из сегментов,
имеющих самый большой номер в очереди (это сегменты, чей номер под-
тверждения больше или равен наибольшему из ранее полученных номеров).
Процедура управления окном оказывает значительное влияние на ха-
рактеристики коммуникаций. Дальнейшие комментарии содержат пожелания
разработчикам.
Пожелания по управлению окном
Выделение очень малого окна приводит к передаче данных очень
маленькими сегментами, тогда как лучший режим осуществляется при
использовании сегментов большего размера.
Чтобы избежать применения малых окон, получателю данных предла-
гается откладывать изменение окна до тех пор, пока свободное место
не составит X процентов от максимально возможного в памяти для
этого соединения (где X может быть от 20 до 40).
Другой совет, чтобы не посылать малые сегменты, состоит в том,
чтобы отправитель не спешил с посылкой данных, пока окно не станет
достаточно большим. Но если клиент дает команду на использование
функции проталкивания, то данные следует немедленно отправлять,
даже если это будет осуществляться малым сегментом.
Заметим, что во избежание ненужных повторных пересылок не нужно
медлить с посылкой подтверждений. Стратегия может заключаться в
посылке подтверждения при получении сегмента малого размера (без
обновления информации обокне), затем посылается другое другое под-
тверждение с новой информацией об окне, если последнее расширяет-
ся.
Сегмент, посылаемый для проверки нулевого окна, может иницииро-
вать разбивку передавамых данных на все более и более мелкие сег-
менты. Если сегмент, содержащий единичный октет данных и отправ-
ленный для проверки нулевого окна, получен, то он займет один ок-
тет в имеющемся в данный момент окне. Если же программа TCP просто
посылает столько данных, сколько может, всякий раз, когда окно
ненулевое, то передаваемые данные будут разбиваться на большие и
малые сегменты. По истечении некоторого времени случающиеся паузы
в выделении окна получателем данны приведут к разбивке больших
сегментов на многочисленные и уже не столь большие пары. Итак, по
прошествии некоторого времени передача данных будет осуществляться
преимущественно малыми сегментами.
Предложение состоит в том, чтобы реализации протокола TCP ак-
тивно пытались объединить малые окна в более крупые, поскольку
механизмы управления окном стремятся ввести много малых окон в
простейших реализациях протокола.
3.8 Интерфейсы
Конечно, здесь затрагиваются два интерфейса. Интерфейс клиент/
протокол TCP и интерфейс протокол TCP/протокол нижнего уровня. Мы
имеем более тщательно разработанную модель для первого из них. Но
здесь не рассматривается интерфейс с модулем протокола нижнего
уровня, поскольку это сделано в спецификации последнего. Для слу-
чая, когда в интерфейсе нижний уровень - это протокол IP, мы лишь
отметим некоторые из допустимых параметров, используемых протоко-
лом TCP.
Интерфейс клиент/TCP
Нижеприведенное функциональное описание команд клиента, посыла-
емых программе протокола TCP, является, в лучшем случае, умозри-
тельным, поскольку каждая операционная система будет иметь свои
характеристики. Следовательно, мы должны предупредить читателей о
том, что различные реализации протокола TCP могут иметь различный
интерфейс с клиентом. Однако, все реализации протокола TCP должны
обеспечивать некий минимальный набор услуг с тем, чтобы гарантиро-
вать, что все они придерживаются единой иерархии протокола. Данная
глава описывает функциональный интерфейс, обязательный для всех
реализаций протокола TCP.
TCP команды клиента
В следующих параграфах функционально характеризуется интерфейс
клиент/протокол TCP. Нотация вызова подобна нотации большинства
процедур или нотации вызова функции в языках высокого уровня, од-
нако это не означает неправомерность вызовов на обслуживание в
виде ловушек (trap) (например SVC, UUO, EMT).
Описанные ниже команды клиента определяют основные операции,
которые должна выполнять программа протокола TCP для поддержки
коммуникаций между процессами. Отдельные реализации протокола дол-
жны определять свой собственный конкретный формат и могут обеспе-
чить комбинации или наборы базовых функций для одиночных вызовов.
В частности, некоторые реализации могут автоматически открывать
соединение (OPEN), как только по нему клиент дает первую команду
посылки (SEND) или получения (RECEIVE).
Для того, чтобы поддерживать интерфейс между процессами, про-
грамма TCP должна не только принимать команды, но и возвращать
некую информацию обслуживаемым процессам. Эта информация состоит
из:
a) общей информации о соединении (т.е. прерываний, закрытия соеди-
нения партнером, управление связью с непредопределенным чужим
сокетом).
b) ответа на конкретные команды клиента, указыващего на успешность
действий или различные типы ошибок.
Команда открытия
Формат
OPEN (свой порт, чужой порт, активный/пассивный [,контрольное
время] [,приоритет] [,безопасность] [,опции]) -> местное имя
для соединения
Мы полагаем, что местная программа TCP несет ответственность
за идентификацию обслуживаемых процессов и будет проверять при-
надлежность процессов, желающих обратиться к данному соедине-
нию. В зависимости от реализации протокола TCP, либо программа
TCP, либо протокол более нижнего уровня (например, IP) будут
создавать адрес отправителя, а точнее, идентификаторы для ло-
кальной сети и интерфейса TCP. Такая предусмотрительность явля-
ется результатом учета безопасности, а именно того, чтобы ни
одна из программ TCP не смогла замаскироваться под какую-либо
другую, и т.д. Аналогичным образом ни один процесс не должен
замаскироваться под другой без того, чтобы не иметь конфликт с
протоколом TCP.
Если флаг активный/пассивный установлен в состояние
"пассивный", то это означает, что дан запрос на "прослушивание"
(LISTEN) сигнала установления соединения извне. Пассивное от-
крытие может дать либо полное описание чужого сокета, с которым
должно быть установлено данное соединение, либо не давать ника-
ких указаний по поводу чужого сокета, который должен дать сиг-
нал. Пассивное открытие соединения с четко определенным чужим
сокетом может стать в любой момент активным открытым соединени-
ем, если будет дана команда на посылку данных (SEND). Создается
блок управления передачей (TCB) и частично заполняется информа-
цией, полученной от параметров команды OPEN.
В случае команды на активное открытие (OPEN) протокол TCP
немедленн