Следующие разделы объясняют, как работают некоторые из наиболее общих команд TCP, и дают значительно лучшее понимание ситуации при поиске неисправностей. Описанные ниже пользовательские команды определяют базовые функции, которые будет выполнять TCP для поддержки коммуникации между процессами. Хотя эти команды не обязательно будут видны, мы найдем признаки их работы в рассматриваемых примерах трассировки. Различные реализации могут изменять точный формат или предоставлять комбинации или подмножества базовых функций в одиночных вызовах. В частности, некоторые реализации могут захотеть открывать соединение автоматически при получении команды пользователя SEND (послать) или RECEIVE (получить) для данного соединения. При предоставлении средств коммуникации между процессами TCP должен не только принимать команды, но также и возвращать информацию процессам, которые он обслуживает. Она представляет собой общую информацию о соединении (т.е. прерывания, удаленное закрытие, связывание неопределенного внешнего сокета). Ответы на специальные команды пользователя указывают успех или различные виды отказов.
Мы предполагаем, что локальный TCP знает идентичность процессов, которые он обслуживает, и будет проверять полномочия процесса на использование указанного соединения. В зависимости от реализации TCP идентификаторы локальной сети и TCP для адреса источника будут поставляться либо TCP, либо протоколом нижнего уровня (например, IP). Эти свойства являются результатом рассмотрения вопросов безопасности, чтобы один TCP не смог маскировать другой, и т.д. Аналогичным образом, ни один процесс не может маскировать другой без возникновения конфликта TCP.
Если флаг "активный/пассивный" (Active/Passive) задан как пассивный, то он представляет собой вызов LISTEN для входящего соединения. Пассивное открытие может иметь либо полностью специфицированный внешний сокет, ожидающий определенное соединение, либо не специфицированный внешний сокет, ожидающий любой вызов. Полностью специфицированный пассивный вызов можно сделать активным последующим выполнением команды SEND. Блок управления передачей (ТСВ) создается и частично заполняется данными из параметров команды OPEN. На активной команде OPEN TCP сразу начнет процедуру синхронизации (т.е. создания) соединения.
Параметр задержки (если присутствует) позволяет вызывающей стороне установить задержку для всех данных, переданных TCP. Если данные не будут доставлены в место назначения в течение времени задержки, TCP прервет соединение. По умолчанию в настоящее время используется пять минут.
TCP или некоторый компонент операционной системы будет проверять полномочия пользователя на открытие соединения с указанным приоритетом или защитой/ячейкой. Отсутствие приоритета или спецификации защиты/ячейки в вызове OPEN указывает, что должны использоваться значения по умолчанию.
TCP будет принимать входящие запросы как подходящие только в том Случае, если информация защиты/ячейки в точности совпадает и если приоритет равен или выше приоритета, запрошенного в вызове OPEN.
Приоритет соединения равен большему из значений, запрошенному в вызове OPEN и полученному из входящего запроса, и фиксируется на этом значении в течение жизни соединения. Реализации могут захотеть предоставить пользователю управление этим согласованием приоритета. Например, пользователь может определять, что приоритет должен точно совпадать, или что любая попытка увеличить приоритет подтверждается пользователем.
TCP будет возвращать пользователю имя локального соединения. Имя локального соединения может затем использоваться в качестве сокращенного термина для соединения, определенного парой <локальный сокет внешний сокет>.
Этот вызов заставляет послать данные, содержащиеся в указанном пользователем буфере, в указанное соединение. Если соединение еще не было открыто, то SEND рассматривается как ошибка. Некоторые реализации могут позволять пользователю сделать вызов SEND и в такой ситуации. В этом случае будет автоматически выполняться команда OPEN. Если вызывающий процесс не уполномочен использовать это соединение, то возвращается ошибка.
Если задан флаг PUSH, данные должны сразу передаваться получателю, и бит PUSH будет установлен в последнем сегменте, созданном из буфера. Если флаг PUSH не установлен, данные могут комбинироваться с данными из последующих команд SEND для эффективности передачи.
Если установлен флаг URGENT, то в сегментах, посланных TCP назначения, будет задан указатель срочности. Получающий TCP будет сигнализировать об условии срочности получающему процессу, если указатель срочности показывает, что данные, предшествующие указателю срочности, не были получены получающим процессом. Назначение срочности состоит в стимуляции получателя к обработке срочных данных и для указания получателю, когда все известные в данный момент срочные данные будут получены. Число раз, которое TCP посылающего пользователя сигнализирует о срочности, не обязательно будет равно числу уведомлений получающего пользователя о присутствии срочных данных.
Если в OPEN не был определен никакой внешний сокет, но соединение установлено (например, потому что прослушиваемое соединение стало определенным в связи с получением внешнего сегмента на локальном соке-те), то обозначенный буфер посылается на подразумеваемый внешний сокет. Пользователи, которые применяют SEND с не указанным внешним сокетом, могут делать это, даже не зная точно адрес внешнего сокета.
Однако если SEND выполняется до того, как был определен внешний сокет, то будет возвращаться ошибка. Пользователи могут применять вызов STATUS для определения статуса соединения. В некоторых реализациях TCP может уведомлять пользователя, когда связывается неопределенный сокет.
Если определяется задержка, то задержка текущего пользователя этого соединения изменяется на новое значение. В простейшей реализации SEND не будет возвращать управление посылающему процессу, пока либо передача не будет завершена, либо не истечет время задержки. Однако этот простой метод может приводить к блокированию (например, обе стороны соединения могут пытаться выполнить SEND, не выполнив ни одной команды RECEIVE) и реализует плохую производительность, поэтому он не рекомендуется. Более сложная и современная реализация будет немедленно возвращать управление, чтобы следующий процесс выполнялся одновременно с сетевым вводом-выводом, и, более того, чтобы реализовать несколько выполняющихся SEND. Несколько SEND обслуживаются в порядке простой очереди, поэтому TCP будет создавать очередь из тех, кого он не может обслужить немедленно.
Здесь неявно предполагается асинхронный интерфейс пользователя, где SEND в дальнейшем вызывает появление некоторого вида SIGNAL (сигнала) или псевдопрерывания от обслуживающего TCP. Альтернативой является немедленный возврат ответа. Например, SEND мог бы немедленно вернуть локальное подтверждение, даже если посланный сегмент не был подтвержден удаленным TCP. Можно было бы оптимистично предполагать конечный успех. Если мы ошиблись, то соединение будет закрыто в любом случае в связи с истечением времени ожидания. В реализациях такого рода (синхронных) все равно будут некоторые асинхронные сигналы, но они будут иметь дело с самим соединением, а не со специфическими сегментами или буферами.
Чтобы процесс различал индикаторы успеха/неудачи для различных SEND, может оказаться удобным возвращать адрес буфера вместе с кодированным ответом на запрос SEND. Сигналы TCP пользователю обсуждаются ниже с указанием информации, которая должна быть возвращена вызывающему процессу.
TCP вызывает модуль низкоуровневого протокола для реальной отправки и получения информации через сеть. Одним из случаев является система взаимодействия сетей ARPA, где низкоуровневым протоколом будет IP. Если низкоуровневым протоколом является IP, он предоставляет аргументы для типа службы и для времени жизни. TCP использует следующие настройки для этих параметров: Type of service = precedence: routine; Delay: normal; Throughput: normal; Reliability: normal; или 00000000. Время жизни = одна минута, или 00111100. Отметим, что предполагаемое максимальное время жизни сегмента равно двум минутам. Здесь мы явно указываем, что сегмент будет уничтожен, если его окажется невозможно доставить по Интернету в течение одной минуты. Если нижним уровнем является IP (или другой протокол, который предоставляет это свойство) и используется маршрутизация источника, интерфейс должен разрешать передавать информацию о маршруте. Особенно важно, чтобы адреса источника и места назначения, используемые в контрольной сумме TCP, принадлежали исходному источнику и конечному месту назначения. Также важно сохранить маршрут возврата для ответа на запросы соединения.
Любой низкоуровневый протокол должен предоставлять адрес источника, адрес места назначения, поля протокола и некоторый способ определения "длины TCP" одновременно для предоставления функционально эквивалентной службы IP и для использования в контрольной сумме TCP. Обработка, показанная в этом разделе, является примером одной возможной реализации. Другие реализации могут иметь иную последовательность обработки, но они должны отличаться от приведенной в данном разделе только в деталях, а не по существу. Активность TCP можно охарактеризовать как реакцию на события. Происходящие события можно разделить на три категории: пользовательские вызовы, прибывающие сегменты и истечение времени ожидания. Этот раздел описывает обработку, которую выполняет TCP в ответ на каждое из этих событий. Во многих случаях требуемая обработка зависит от состояния соединения.
Протокол IP создан для использования в связанных системах компьютерных коммуникационных сетей с коммутацией пакетов. Протокол IP обрабатывает передаваемые от источника к месту назначения блоки данных, называемые дейтаграммами, где источниками и местами назначения являются хосты, идентифицированные адресами фиксированной длины. Протокол IP предусматривает также фрагментацию и повторную сборку длинных дейтаграмм.
Функции IP ограничены доставкой пакетов битов (дейтаграмм Интернета) от источника к месту назначения через связанную систему сетей. В нем не существует механизмов для обеспечения надежности двухточечной передачи данных, управления потоком, упорядочивания или других служб, присутствующих обычно в протоколах взаимодействия хостов. Протокол IP может использовать службы поддерживающих его сетей для предоставления служб различных типов и качества.
Этот протокол вызывается протоколами взаимодействия хостов в среде Интернета. Он вызывает протоколы локальных сетей для переноса дейтаграмм Интернета к следующему шлюзу или хосту места назначения. Например, модуль ТСР будет вызывать модуль IP, чтобы получить сегмент ТСР (включая заголовок ТСР и данные пользователя) как часть с данными дейтаграммы IP. Модуль ТСР будет предоставлять адреса и другие параметры в заголовке IP модулю IP как аргументы вызова. Модуль IP будет затем создавать дейтаграмму IP и вызывать интерфейс локальной сети для передачи дейтаграммы.
Протокол IP реализует две базовые функции: адресацию и фрагментацию. Модули IP используют адреса, передаваемые в заголовке ГР, для передачи дейтаграмм IP в направлении их места назначения. Выбор пути доступа для передачи называется маршрутизацией. Модули IP используют поля заголовка IP в случае необходимости для фрагментации и повторной сборки дейтаграмм IP.
Модель работы состоит в том, что модуль IP располагается на каждом хосте, вовлеченном в коммуникацию Интернета, и на каждом шлюзе, который соединяет сети. Эти модули используют общие правила для интерпретации полей адреса и для фрагментации и сборки дейтаграмм IP. Кроме того, эти модули (особенно на шлюзах) имеют процедуры для принятия решений о маршрутизации и другие функции.
Протокол IP интерпретирует каждую дейтаграмму IP как независимую сущность, не связанную с другой дейтаграммой IP. Не существует никаких соединений или логических связей (виртуальных или каких-либо других).
Протокол IP использует четыре ключевых механизма при предоставлении своих служб: тип службы, время жизни, параметры и контрольная сумма заголовка. Тип службы используется для указания качества желательной службы. Тип службы является абстрактным или обобщенным множеством параметров, характеризующих варианты служб, предоставляемых в сетях, из которых состоит Интернет. Это указание типа службы должно использоваться шлюзами для выбора параметров реальной передачи для определенной сети, которая будет применяться для следующего перехода или для следующего шлюза при маршрутизации дейтаграммы IP. Время жизни является указанием верхней границы времени жизни дейтаграммы IP. Оно задается отправителем дейтаграммы и уменьшается в точках вдоль маршрута, где оно обрабатывается. Если время жизни достигает нуля до того, как дейтаграмма Интернета достигает своего места назначения, дейтаграмма IP разрушается. Время жизни можно считать пределом времени саморазрушения.
Параметры, предоставляемые для управляющих функций, необходимы или полезны в некоторых ситуациях, но для большинства обычных коммуникаций не нужны. Параметры включают обеспечение отметок времени, безопасности и специальной маршрутизации. Контрольная сумма заголовка предоставляет проверку того, что информация, используемая при обработке дейтаграмм IP, была передана правильно. Данные могут содержать ошибки. Если контрольная сумма заголовка неправильная, дейтаграмма IP тотчас отбрасывается сущностью, которая обнаружила ошибку. Протокол IP не предоставляет надежного средства коммуникации. Не существует подтверждений между конечными точками или точками перехода. Отсутствует контроль ошибок данных, только контрольная сумма заголовка. Не существует повтора передачи и управления потоком. Обнаруженные ошибки могут сообщаться через протокол IСМР, который реализован в модуле протокола IP.
Протокол IP, с одной стороны, общается с протоколами коммуникации хостов более высокого уровня, а с другой стороны, с протоколом локальной сети.
Модель работы при передаче дейтаграмм из одной прикладной программы в другую иллюстрирует следующий сценарий. Предположим, что эта передача будет включать один промежуточный шлюз. Передающая прикладная программа готовит свои данные, вызывает свой локальный модуль IР для отправки этих данных в виде дейтаграммы и передает адрес места назначения и другие параметры в качестве аргументов вызова. Модуль IР готовит заголовок дейтаграммы и присоединяет к нему данные. Модуль определяет адрес локальной сети для этого адреса IР; в данном случае это адрес шлюза. Он посылает эту дейтаграмму и адрес локальной сети в локальный сетевой интерфейс. Локальный сетевой интерфейс создает локальный сетевой заголовок и присоединяет к нему дейтаграмму, а затем посылает результат через локальную сеть. Дейтаграмма прибывает на хост шлюза в оболочке заголовка локальной сети, интерфейс локальной сети удаляет этот заголовок и передает дейтаграмму модулю IР. Модуль определяет из адреса IР, что дейтаграмма должна быть передана на другой хост во второй сети. Модуль определяет адрес локальной сети для хоста назначения. Он обращается к интерфейсу локальной сети, чтобы послать ей дейтаграмму. Интерфейс локальной сети создает заголовок локальной сети и присоединяет дейтаграмму, посылая результат хосту назначения. На хосте назначения дейтаграмма освобождается от заголовка локальной сети интерфейсом локальной сети и передается модулю IР.
Модуль IР определяет, что дейтаграмма предназначена для прикладной программы на этом хосте. Он передает данные прикладной программе в ответ на системный вызов, передавая адрес источника и другие параметры, как результат вызова.
Функция или назначение протокола IР состоит в переносе дейтаграмм в пределах объединенной сети, или сетевого комплекса. Это реализуется путем передачи дейтаграмм из одного модуля IР в другой, пока не будет достигнуто место назначения. Модули IР располагаются на хостах и шлюзах в системе Интернет. Дейтаграммы маршрутизируются из одного модуля IР в другой через отдельные сети на основе интерпретации адреса IР. Таким образом, одним из важных механизмов протокола IР является IР-адрес.
При маршрутизации сообщений из одного модуля IР в другой дейтаграммам может понадобиться пересекать сеть, максимальный размер пакета в которой меньше размера дейтаграммы. Чтобы преодолеть эту трудность, в протоколе IР предоставлен механизм фрагментации.
Существует различие между именами, адресами и маршрутами. Имя указывает, что мы ищем. Адрес указывает, где это находится. Маршрут указывает, как туда попасть. Протокол IР имеет дело прежде всего с адресами. Задача протоколов высокого уровня (т.е. протокола хост-хост или приложения) — выполнить отображение из имен в адреса. Модуль IР отображает IР-адреса в адреса локальной сети. Задача низкоуровневых процедур (т.е. локальной сети или шлюзов) — выполнить отображение из адресов локальной сети или маршрутов.
Адреса имеют фиксированную длину из четырех октетов (32 бита). Адрес начинается с номера сети, за которым следует локальный адрес (называемый "собственным" полем). Есть три формата классов адресов IР: в классе (а) старший бит равен нулю, следующие семь битов определяют сеть, а последние 24 бита являются локальным адресом; в классе (Ь) старшими двумя битами будут один-ноль, следующие 14 битов определяют сеть, а последние 16 битов являются локальным адресом; в классе (с) старшими тремя битами будут один-один-ноль, следующие 21 бита определяют сеть, а последние восемь битов являются локальным адресом.
При отображении адресов IР в адреса локальной сети должна быть проявлена осторожность; в ряде случаев единственный физический хост должен действовать как несколько различных хостов за счет использования нескольких различных адресов IР. Некоторые хосты будут также иметь несколько физических интерфейсов (мультихост). Должно быть предусмотрено существование хоста с несколькими физическими сетевыми интерфейсами, каждый из которых может иметь несколько логических адресов IР.
