2.7. Организация и разрыв соединений
Для идентификации отдельных потоков данных, которыми может управлять TCP, этот протокол поддерживает идентификаторы портов. Поскольку идентификаторы портов выбираются независимо разработчиками реализаций TCP, эти идентификаторы могут оказаться неуникальными. Для обеспечения уникальной адресации каждого TCP идентификатор порта объединяется с адресом IP для хоста TCP; такая комбинация порта и адреса называется сокетом. Для сокетов обеспечивается уникальность в масштабах Сети.
Соединение однозначно идентифицируется парой сокетов для обоих концов соединения. Локальный сокет может использоваться во множестве соединений с различными внешними сокетами. Соединение может использоваться для передачи данных в обоих направлениях, т. е. является "полнодуплексным".
TCP распределяет номера портов между процессами по своему усмотрению, однако существуют базовые концепции, которым необходимо следовать в каждой реализации. Должны поддерживаться "хорошо известные" (well-known) номера портов, которые TCP будет связывать только с определенными процессами. Предполагается, что такими процессами могут быть собственные процессы TCP и эти процессы могут инициировать соединения только через такие "привилегированные" порты. Применительно к реализации распределение портов является локальным вопросом, но предполагается наличие пользовательской команды Request Port или иного метода выделения уникальной группы портов для данного процесса (например, путем связывания старших битов в номере порта с данным процессом).
При вызове OPEN соединение задается номером локального порта и удаленного сокета, передаваемыми в качестве аргументов. В ответ TCP возвращает короткое локальное имя соединения, которое пользователь может указывать в последующих вызовах функций. Есть несколько важных аспектов организации соединений, о которых следует помнить. Предполагается, что информация о соединении хранится в структуре данных TCB (Transmission Control Block — блок управления передачей). В некоторых реализациях локальное имя соединения просто указывает на структуру TCB для этого соединения. При вызове OPEN также указывается тип вызова — активный (соединение организуется сразу) или пассивный (ожидание).
Пассивный запрос OPEN означает, что процесс будет ждать входящего соединения, не делая попыток организовать соединение самому. Зачастую процесс, использовавший пассивный вызов OPEN, будет воспринимать входящие запросы соединений от любого хоста. В таких случаях внешний сокет с номером, содержащим только нули, будет использоваться для обозначения неуказанного сокета. Использование неуказанных внешних сокетов допускается только для пассивных вызовов OPEN. Сервисный процесс, который намерен обслуживать вызовы от неизвестных процессов, должен использовать пассивный вызов OPEN с неуказанным внешним сокетом. В таких случаях соединение может быть организовано с любым процессом, который запросит соединение с данным локальным сокетом. Такое решение полезно в тех случаях, когда известно, что локальный сокет связан с известным сервисом.
Сокеты Well-known обеспечивают удобный способ связывания адресов со стандартными службами. Например, серверный процесс Telnet постоянно связан с конкретным сокетом, а другие известные сокеты зарезервированы для таких служб как File Transfer, Remote Job Entry, Text Generator, Echoer, Sink (последние три используются в тестовых целях). Адрес сокета может быть зарезервирован для доступа к службе Look-Up, возвращающей номер сокета, по которому предоставляется новый сервис. Концепция хорошо известных сокетов является частью спецификации TCP, но выделение номеров для сокетов выходит за пределы этого документа (см. [RFC790]).
Процесс может использовать пассивный вызов OPEN и ждать соответствующего активного вызова OPEN другим процессом; после организации нужного соединения TCP будет информировать процесс об этом. Два процесса, одновременно использовавшие активные вызовы OPEN для связи друг с другом, будут корректно соединены. Такая гибкость очень важна для поддержки распределенных систем, в которых компоненты работают асинхронно.
Существует два важных случая соответствия между локальным пассивным вызовом OPEN и внешним активным вызовом OPEN. В первом случае локальный пассивный вызов OPEN полностью задает внешний сокет — соответствие является точным. Во втором случае локальный пассивный вызов OPEN оставляет внешний сокет неуказанным — приемлемы соединения с любыми внешними сокетами, соответствующими локальному сокету. Остальные случаи являются промежуточными вариантами. При наличии нескольких ожидающих пассивных вызовов OPEN (записанных в TCB) с одинаковым локальным сокетом внешний активный вызов OPEN будет соответствовать TCB в указанным внешним сокетом, который совпадает с внешним активным вызовом OPEN (при наличии такого TCB); в остальных случаях выбор осуществляется среди TCB с неуказанным внешним сокетом.
Процедуры организации соединений используют флаг контроля синхронизации (SYN) и включают обмен тремя сообщениями, известными three-way hand shake (трехэтапное согласование) [3].
Соединение инициируется при наличии входящего сегмента с флагом SYN и ожидающей записи TCB, которая была создана с помощью функции OPEN. Соответствие локального и внешнего сокета определяет возможность организации соединения. Соединение переходит в состояние established (организовано) после синхронизации порядковых номеров для обоих направлений. Разрыв соединения также включает обмен сегментами — в этом случае они содержат флаг завершения FIN.