Конечные стороны соединения остаются в состоянии ESTABLISHED, пока одна из сторон не приступит к закрытию соединения, послав сегмент FIN. В процессе обычного закрытия сторона, инициирующая это закрытие, проходит через состояния, показанные в таблице 10.5. Ее партнер проходит через состояния, представленные в таблице 10.6.
Таблица 10.5 Последовательность состояний стороны, закрывающей соединение
Состояния закрывающей стороны Событие Описание ESTABLISHED Локальное приложение запрашивает закрытие соединения. TCP посылает FIN/ACK. FIN-WAIT-1 Закрывающая сторона ожидает ответа партнера. Напомним, что от партнера все еще могут прибывать новые данные. TCP получает ACK. FIN-WAIT-2 Закрывающая сторона получила ACK от партнера, но еще не пришел FIN. Закрывающая сторона ожидает FIN, принимая поступающие данные. TCP получает FIN/ACK. Посылает ACK. TIME-WAIT Соединение поддерживается в неопределенном состоянии, чтобы позволить прибыть или отбросить все еще существующие в сети дублированные данные или дублированный FIN. Период ожидания вдвое больше оценки максимального времени жизни сегмента. CLOSED Удалена вся информация о соединении.
Таблица 10.6 Последовательность состояний партнера по закрытию соединения
Состояние партнера Событие Описание ESTABLISHED TCP получает FIN/ACK. CLOSE-WAIT Прибыл FIN. TCP посылает ACK. TCP ожидает от своего приложения закрытия соединения. В этот момент приложение может посылать достаточно большое количество данных. Локальное приложение инициализирует закрытие соединения. TCP посылает FIN/ACK. LAST-ACK TCP ожидает конечный ACK. TCP получает ACK. CLOSED Удалена вся информация о соединении.
10.17.1 Анализ состояний соединения TCP
Команда netstat -an позволяет проверить текущее состояние соединения. Ниже показаны соединения в состояниях listen, startup, established, closing и time-wait.
Отметим, что номер порта соединения указан в конце каждого локального и внешнего адреса. Видно, что имеется трафик TCP как для входной, так и для выходной очередей.
> netstat -an
Active Internet connections
Pro Recv-Q Send-Q Local Address Foreign Address (state)
Tcp 0 0 128.121.50.145.25 128.252.223.5.1526 SYN_RCVD
Tcp 0 0 128.121.50.145.25 148.79.160.65.3368 ESTABLISHED
Tcp 0 0 127.0.0.1.1339 127.0.0.1.111 TIME_WAIT
Tcp 0 438 128.121.50.145.23 130.132.57.246.2219 ESTABLISHED
Tcp 0 0 128.121.50.145.25 192.5.5.1.4022 TIME_WAIT
Tcp 0 0 128.121.50.145.25 141.218.1.100.3968 TIME_WAIT
Tcp 0 848 128.121.50.145.23 192.67.236.10.1050 ESTABLISHED
Tcp 0 0 128.121.50.145.1082 128.121.50.141.6000 ESTABLISHED
Tcp 0 0 128.121.50.145.1022 128.121.50.141.1017 ESTABLISHED
Tcp 0 0 128.121.50.145.514 128.121.50.141.1020 CLOSE_WAIT
Tcp 0 1152 128.121.50.145.119 192.67.239.23.3572 ESTABLISHED
Tcp 0 0 128.121.50.145.1070 192.41.171.5.119 TIME_WAIT
Tcp 579 4096 128.121.50.145.119 204.143.19.30.1884 ESTABLISHED
Tcp 0 0 128.121.50.145.119 192.67.243.13.3704 ESTABLISHED
Tcp 0 53 128.121.50.145.119 192.67.236.218.2018 FIN_WAIT_1
Tcp 0 0 128.121.50.145.119 192.67.239.14.1545 ESTABLISHED
Tcp 0 0 *.19 *.* LISTEN
Tcp 0 0 *.13 *.* LISTEN
Tcp 0 0 *.9 *.* LISTEN
Tcp 0 0 *.7 *.* LISTEN
Tcp 0 0 *.31 *.* LISTEN
10.18 Замечания о реализациях
С самого начала протокол TCP предназначен для взаимодействия сетевого оборудования от различных производителей. Спецификация TCP не указывает точно, как должны работать внутренние структуры реализации. Эти вопросы оставлены для разработчиков, которые призваны найти наилучшие механизмы для каждой конкретной реализации.
Даже RFC 1122 (документ Host Requirements — требования к хостам) оставляет достаточную свободу для вариаций. Каждая из реализуемых функций маркируется определенным уровнем совместимости:
■ MUST (Необходимо)
■ SHOULD (Рекомендовано)
■ MAY (Разрешено)
■ SHOULD NOT (Не рекомендовано)
■ MUST NOT (Не нужно)
К сожалению, иногда встречаются продукты, не реализующие требования MUST. В результате пользователи испытывают неудобства от снижения производительности.
Некоторые хорошие методы реализации не учитываются в стандартах. Например, улучшение безопасности возможно при ограничении использования общеизвестных портов привилегированными процессами системы, если в локальной операционной системе поддерживается этот метод. С целью увеличения производительности в реализациях должно быть как можно меньше копирования и перемещения посланных или извлеченных данных.
Стандартный прикладной интерфейс программирования не определен (как и политика безопасности), чтобы осталось свободное поле деятельности для экспериментирования с разными комплектами программных инструментов. Однако это может привести к использованию различных программных интерфейсов на каждой из платформ и не позволит перемещать прикладное программное обеспечение между платформами.
Фактически разработчики основывают свои комплекты инструментов на программном интерфейсе Socket, заимствованном из Berkeley. Значение программного интерфейса возросло с появлением WINSock (Windows Socket), что привело к быстрому увеличению новых приложений для настольных систем, которые могли работать поверх любого интерфейса WINSock, совместимого со стеком TCP/IP.
10.19 Дополнительная литература
Оригинал стандарта TCP определен в RFC 793. Модернизации, исправления, и требования совместимости рассмотрены в RFC 1122. Керн (Каш) и Партридж (Partridge) опубликовали статью Improving Round-Trip Estimates in Reliable Transport Protocols в журнале Proceedings of the ACM SIGCOMM 1987. Статья Джекобсона (Jacobson) Congestion Avoidance and Control появилась в Proceedings of the ACM SIGCOMM 1988 Workshop. Джекобсон издал также несколько RFC, пересматривающих алгоритмы повышения производительности.
Глава 11
Конфигурация с помощью BOOTP и DHCP
11.1 Введение
Наиболее заметным явлением в компьютерной области, произошедшим в последние несколько лет, является распространение сетей TCP/IP на настольные системы. Необходимая для этого инфраструктура — маршрутизаторы, мосты, коммутаторы и концентраторы — увеличилась до соответствующего такому расширению количества.
Обслуживающий персонал столкнулся с проблемами постоянного подключения и перемещения новых устройств, а также с необходимостью изменения сетевой конфигурации для соответствия современным требованиям к сетям. Все это привело к необходимости создания механизма для автоматизации конфигурации сетевых узлов, распределенных операционных систем и сетевого программного обеспечения. Наиболее эффективным способом реализации такого механизма может быть сохранение конфигурационных параметров и образов программного обеспечения на одном или нескольких серверах загрузки (boot server). Во время запуска система взаимодействует с таким сервером, получает от него начальные параметры конфигурации и при необходимости загружает с него нужное программное обеспечение.
