Команда открытия
Формат
OPEN (свой порт, чужой порт, активный/пассивный [,контрольное время] [,приоритет] [,безопасность] [,опции]) -> местное имя для соединения
Мы полагаем, что местная программа TCP несет ответственность за идентификацию обслуживаемых процессов и будет проверять принадлежность процессов, желающих обратиться к данному соединению. В зависимости от реализации протокола TCP, либо программа TCP, либо протокол более нижнего уровня (например, IP) будут создавать адрес отправителя, а точнее, идентификаторы для локальной сети и интерфейса TCP. Такая предусмотрительность является результатом учета безопасности, а именно того, чтобы ни одна из программ TCP не смогла замаскироваться под какую-либо другую, и т.д. Аналогичным образом ни один процесс не должен замаскироваться под другой без того, чтобы не иметь конфликт с протоколом TCP.
Если флаг активный/пассивный установлен в состояние "пассивный", то это означает, что дан запрос на "прослушивание" (LISTEN) сигнала установления соединения извне. Пассивное открытие может дать либо полное описание чужого сокета, с которым должно быть установлено данное соединение, либо не давать никаких указаний по поводу чужого сокета, который должен дать сигнал. Пассивное открытие соединения с четко определенным чужим сокетом может стать в любой момент активным открытым соединением, если будет дана команда на посылку данных (SEND). Создается блок управления передачей (TCB) и частично заполняется информацией, полученной от параметров команды OPEN.
В случае команды на активное открытие (OPEN) протокол TCP немедленно запустит процедуру синхронизации (точнее, установления) соединения.
Контрольное время, если оно присутствует среди параметров функции, позволяет клиенту установить контрольное время ликвидации для всех данных, посылаемых от имени протокола TCP. Если в течение этого контрольного времени какие-либо данные не достигли своего адресата, программа TCP ликвидирует соединение. В настоящее время общепринятым контрольным временем являются пять минут.
Программа протокола TCP или какая- либо компонента операционной системы будет проверять права клиента на открытие соединения, имеющего заказанные клиентом приоритет и безопасность. Если приоритет или безопасность/закрытость не указаны, должен использоваться вызов CALL, использующий значения этих параметров, принятые по умолчанию.
Программа протокола TCP будет воспринимать приходящие запросы только если они имеют тот же самый уровень безопасности/закрытости. Приоритет запросов должен быть равен или превышать приоритет, указанный в команда открытия (OPEN).
Если приоритет для соединения оказывается больше, чем значение, указанное в запросе CALL, то берется приоритет из пришедшего запроса и становится постоянной характеристикой соединения. Разработчики могут перепоручить клиентам ведение переговоров по поводу установления приоритета соединения. Например, клиент может указывать приоритет, который должен быть присвоен соединению. В другом примере, любая попытка повысить приоритет соединения должна получить санкцию клиента.
По завершении операции протокол TCP возвращает клиенту местное название для открытого соединения. Впоследствии имя соединения может использоваться в качестве короткого обозначения для соединения, идентифицируемого парой <местный сокет, чужой сокет >.
Команда получения
Формат
RECEIVE (местное имя соединения, адрес буфера, счетчик байт) -> счетчик байт, флаг срочности, флаг проталкивания
Данная команда размещает получаемую информацию в буфере, связанном с конкретным соединением. Если команде не предшествует команда OPEN или если процесс, осуществляющий вызов, не уполномочен на использование данного соединения, то возвращается ошибка.
В простейшей реализации протокола управление не должно передаваться осуществившей вызов программе до тех пор, пока либо не будет заполнен буфер, либо не произойдет какая-либо ошибка. Однако данная схема в значительной мере подвержена блокировкам.
Более сложная реализация могла бы позволить за раз выдвигать несколько команд RECEIVE. Эти запросы будут выполняться по мере поступления сегментов с данными. Такая стратегия позволяет увеличить пропускную способность за счет применения более развитой схемы (возможно, асинхронной), а также оповещения программы о том, что получен сигнал проталкивания PUSH или заполнен буфер.
Если получено достаточное количество данных, чтобы заполнить буфер до того, как получен сигнал проталкивания PUSH, то в ответ на RECEIVE не будет установлен флаг PUSH. Буфер будет со держать столько данных, насколько позволяет его емкость. Если сигнал PUSH обнаружен до того, как буфер заполнился, то буфер будет возвращен заполненным частично и с сигналом PUSH.
Если обнаружены срочные данные, то сразу же по их прибытии клиент будет оповещен сигналом от программы протокола TCP. Клиент, получающий данные, должен по этому сигналу перейти в "срочный режим". Если флаг срочности URGENT установлен, то дополнительные срочные данные останутся неполученными. Если флаг URGENT сброшен, то данный запрос на получение RECEIVE возвратит все срочные данные и клиент может освободиться от "срочного режима". Заметим, что данные, следующие за указателем срочности (несрочные данные) не могут быть доставлены к клиенту в одном и том же буфере с предыдущими срочными данными, если сам клиент не определил четко границу.
Чтобы проводить различие между несколькими сделанными командами на получение RECEIVED и следить за заполнением буферов, код, возвращаемый клиенту сопровождается как указателем на буфер, так и количеством действительно полученных данных.
Другие реализации команды RECEIVE могут сами выделять буфер для размещения получаемых данных или же программа протокола TCP может одновременно с клиентом пользоваться циклическим буфером.
Команда закрытия соединения
Формат
CLOSE (локальное имя соединения)
Данная команда приводит к закрытию указанного соединения. Если соединение не открыто или отдавший команду процесс не уполномочен использовать данное соединение, то возвращается со общение об ошибке. Предполагается, что закрытие соединения будет медлительной операцией в том смысле, что оставшиеся команды посылки SEND будут еще некоторое время передавать данные (и даже, в случае необходимости, делать это повторно), насколько это позволит управление потоком, и не будет выполнена заказанная работа. Таким образом, можно будет сделать несколько команд посылки SEND, а затем закрыть соединение командой CLOSE, будучи уверенным, что отправленные данные достигнут адресата. Очевидно, что клиенты должны продолжать давать команды получения данных с уже закрытых соединений, поскольку чужая программа будет еще пытаться переслать оставшиеся у нее данные.
Итак, команду CLOSE следует интерпретировать как "у меня нет больше данных для пересылки", а не как "я больше не хочу ничего получать". Может случиться (если протокол на уровне клиента не продуман до конца), что сторона, закрывающая соединение, не сможет избавиться от всех своих данных до истечения контрольного времени. В этом случае команда CLOSE транслируется в ABORT, и программа TCP отказывается от соединения.
Клиент может дать команду CLOSE в любой момент по своему собственному усмотрению, а также в ответ на различные сообщения от протокола TCP (например, когда выполнено закрытие соединения с чужой стороны, превышено контрольное время передачи, адресат недоступен).
Поскольку закрытие соединения требует общения с чужой программой TCP, то соединения могут пребывать в закрытом состоянии короткое время. Попытки повторно открыть соединение до того, как программа TCP отреагирует на команду CLOSE, приведет к возврату на вызов сообщения об ошибке.
Команда закрытия предполагает выполнение операции проталкивания данных через соединение.
Коммуникация данных
Набор данных, передаваемых по соединению, можно рассматривать как поток октетов. Пользователь, отправляющий данные, указывает при запросе по посылку, следует ли данные, отправляемые при этом запросе, немедленно проталкивать через сеть к получателю. Указание осуществляется установкой флага PUSH (проталкивание).
Программа протокола TCP может собирать данные, принимаемые от пользователя, а затем передавать их в сеть по своему усмотрению в виде сегментов. Если же выставлен запрос на проталкивание, то протокол должен передать все не отправленные ранее данные. Когда программа протокола TCP, принимающая данные, сталкивается с флагом проталкивания, ей не следует ожидать получения новых данных по сети до тех пор, пока уже имеющиеся данные не будут переданы ждущему их местному процессу.
Нет нужды привязывать функции проталкивания к границам сегмента. Данные, содержащиеся в каком-либо сегменте, могут быть результатом одного или нескольких запросов на посылку. Или же один запрос может породить несколько сегментов.
Целью функции проталкивания и флага PUSH является проталкивание данных через сеть от отправителя к получателю. Функция не осуществляет обработки самих данных.
Существует связь между функцией проталкивания и использованием буферов данных в интерфейсе между пользователем и протоколом TCP. Каждый раз, когда в буфер получателя приходят данные с флагом PUSH, содержимое этого буфера передается пользователю на обработку, даже если буфер и не был заполнен. Если приходящие данные заполняют буфер пользователя до того, как получена команда проталкивания, пользователю отправляется блок данных, соответствующий размеру буфера. Протокол TCP имеет также средства для сообщения получателю, что с некоторого момента он имеет дело со срочными данными. Протокол TCP не пытается определить, что именно пользователь делает со ждущими обработки срочными данными. Однако обычно предполагается, что получающий данные процесс будет предпринимать усилия для быстрой обработки срочных данных.
Концепция периода молчания в протоколе 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 секунд. При сбое определенное место в очереди в течении определенного времени продолжает оставаться занятым октетами из последнего отправленного сегмента. Если вскоре создается новое соединение и оно использует какие-либо номера из очереди в момент, когда ими еще пользуется сегмент из предыдущей реализации соединения, то следовательно эта область перекрывания номеров очередей может являться причиной проблем у получателя. <
Контрольное время повторной посылки
Вследствие непостоянства сетей, составляющих единую объединенную систему, и большого числа клиентов, пользующихся услугами 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 пакует данные из этих буферов в сегменты, а затем вызывает модуль Internet для передачи каждого сегмента на программу протокола TCP, являющуюся адресатом. Этот адресат в свою очередь помещает данные из сегмента в буферы получателя и затем оповещает своего клиента о прибытии предназначенных ему данных. Программы протокола TCP помещают в сегменты контрольную информацию, которая затем используется ими для проверки очередности передачи данных.
Модель Internet коммуникаций состоит в том, что с каждой программой протокола TCP связан модуль протокола Internet, обеспечивающий ей интерфейс с локальной сетью. Данный модуль Internet помещает сегменты TCP в Internet датаграммы, а затем направляет их на другой Internet модуль или же промежуточный шлюз. Для передачи датаграммы по локальной сети она в свою очередь помещается в пакет соответствующего типа.
Коммутаторы пакетов могут осуществлять дальнейшую упаковку, фрагментацию или другие операции с тем, чтобы в локальной сети осуществить передачу пакетов по назначению на модуль Internet.
На шлюзах между локальными сетями датаграмма Internet освобождается от пакета локальной сети и исследуется с тем, чтобы определить, по какой сети она должна в дальнейшем идти. Затем Internet датаграмма упаковывается в пакет, соответствующий выбранной локальной сети, и посылается на следующий шлюз или же прямо к конечному получателю.
Шлюз имеет возможность разбивать Internet датаграмму на более мел кие датаграммы-фрагменты, если это необходимо для передачи по очередной локальной сети. Чтобы осуществить это, шлюз сам создает набор Internet датаграмм, помещая в каждую по одному фрагменты. В дальнейшем фрагменты могут быть снова разбиты следующими шлюзами на еще более мелкие части. Формат фрагмента Internet датаграммы спроектирован так, чтобы адресат - модуль Internet смог собрать фрагменты снова в исходные Internet датаграммы.
Internet модуль, являющийся адресатом, выделяет сегмент из датаграммы (после ее сборки в случае необходимости) и затем передает его по назначению на программу протокола TCP.
Данная простая модель действия протокола зачастую замалчивает множество деталей. Одной из важных характеристик является тип сервиса. Этот признак дает указание шлюзу (или модулю Internet) о выборе параметров сервиса, которые должны использоваться при передаче датаграммы в очередной локальной сети. Приоритет датаграммы указывается среди информации о типе сервиса. Датаграммы также могут нести информацию о безопасности с тем, чтобы позволить хост-компьютерам и шлюзам, действующим в многоуровневой системе безопасности, подвергать проверке соответствующие датаграммы.
Мультиплексирование и демультиплексирование прикладных протоколов с помощью протокола UDP
Протокол UDP ведет для каждого порта две очереди: очередь пакетов, поступающих в данный порт из сети, и очередь пакетов, отправляемых данным портом в сеть.
Процедура обслуживания протоколом UDP запросов, поступающих от нескольких различных прикладных сервисов, называется мультиплексированием.
Распределение протоколом UDP поступающих от сетевого уровня пакетов между набором высокоуровневых сервисов, идентифицированных номерами портов, называется демультиплексированием.
Хотя к услугам протокола UDP может обратиться любое приложение, многие из них предпочитают иметь дело с другим, более сложным протоколом транспортного уровня TCP. Дело в том, что протокол UDP выступает простым посредником между сетевым уровнем и прикладными сервисами, и, в отличие от TCP, не берет на себя никаких функций по обеспечению надежности передачи. UDP является дейтаграммным протоколом, то есть он не устанавливает логического соединения, не нумерует и не упорядочивает пакеты данных.
С другой стороны, функциональная простота протокола UDP обуславливает простоту его алгоритма, компактность и высокое быстродействие. Поэтому те приложения, в которых реализован собственный, достаточно надежный, механизм обмена сообщениями, основанный на установлении соединения, предпочитают для непосредственной передачи данных по сети использовать менее надежные, но более быстрые средства транспортировки, в качестве которых по отношению к протоколу TCP и выступает протокол UDP. Протокол UDP может быть использован и в том случае, когда хорошее качество каналов связи обеспечивает достаточный уровень надежности и без применения дополнительных приемов типа установления логического соединения и квитирования передаваемых пакетов. <
Надежные коммуникации
Поток данных, посылаемый на TCP соединение, принимается получателем надежно и в соответствующей очередности.
Передача осуществляется надежно благодаря использованию подтверждений и номеров очереди. Концептуально каждому октету данных присваивается номер очереди. Номер очереди для первого октета данных в сегменте передается вместе с этим сегментом и называется номером очереди для сегмента. Сегменты также несут номер подтверждения, который является номером для следующего ожидаемого октета данных, передаваемого в обратном направлении. Когда протокол TCP передает сегмент с данными, он помещает его копию в очередь повторной передачи и запускает таймер. Когда приходит подтверждение для этих данных, соответствующий сегмент удаляется из очереди. Если подтверждение не приходит до истечения срока, то сегмент посылается повторно.
Подтверждение протокола TCP не гарантирует, что данные достигли конечного получателя, а только то, что программа протокола TCP на компьютере у получателя берет на себя ответственность за это.
Для направления потока данных между программами протоколов TCP используется механизм управления потоками. Получающая программа протокола TCP сообщает "окно" посылающей программе. Данное окно указывает количество октетов (начиная с номера подтверждения), которое принимающая программа TCP готова в настоящий момент принять.
Номер очереди
Основополагающей идеей в проектировании протокола является то, что каждый октет данных, посылаемый на TCP соединение, имеет номер очереди. Поскольку каждый октет пронумерован, то каждый из них может быть опознан. Приемлемый механизм опознания является накопительным, так что опознание номера X означает, что все октеты с предыдущими номерами уже получены. Этот механизм позволяет регистрировать появление дубликатов в условиях повторной передачи. Нумерация октетов в пределах сегмента осуществляется так, чтобы первый октет данных сразу вслед за заголовком имел наименьший номер, а следующие за ним октеты имели номера по возрастающей.
Важно помнить о том, что количество номеров для очереди, хоть и велико, но ограничено. Диапазон номеров - от 0 до 2**32-1. Поскольку набор ограничен, то все арифметические операции с номерами очередей должны осуществляться по модулю 2**32. Это совсем не означает всякий раз предварительную арифметическую проверку номеров очереди на попадание в диапазон от 2**32-1 до 0. В работе с модульной арифметикой есть некие тонкости, поэтому нужно аккуратно программировать сравнение столь больших величин. Так символ '=<' означает "меньше или равно" (по модулю 2**32).
Протокол TCP должен осуществлять следующие типы сравнения для номеров очереди:
| (a) | является ли номер в подтверждении номером очереди для октетов, уже отправленных, но еще не получивших подтверждения; |
| (b) | получили ли все октеты в сегменте подтверждение своих номеров (т.е. следует ли удалить данный сегмент из очереди на повторную посылку); |
| (c) | содержит ли пришедший сегмент ожидаемые нами номера (т.е. "перекрывает" ли этот сегмент окно получателя). |
В ответ на посылку данных протокол TCP будет получать их подтверждение. Для работы с полученным подтверждением необходимо уметь делать сравнение для
| самого старого из номеров, не имевших подтверждения, |
| следующего номера очереди, ждущего посылки, |
| номера подтверждения, полученного от чужой принимающей программы TCP (следующего номера очереди, ожидаемого чужой программой TCP), |
| номера очереди первого октета в сегменте, |
| количества октетов в поле данных сегмента (учитывая SYN и FIN), |
| номера очереди последнего октета из сегмента. |
/p>
Новое подтверждение (называемое "подтверждением приемлемости") - это подтверждение выполнимости неравенств
SND.UNA < SEG.ACK =< SND.NXT
Сегмент из очереди повторной посылки получает полное подтверждение, если сумма его номера в очереди и длины поля данных меньше или равна номеру подтверждения из пришедшего сегмента.
При получении данных необходимо производить операции сравнения для следующих величин:
| следующий номер из очереди приходящих сегментов, а также левая или нижняя граница окна получения, |
| номер очереди последнего сегмента, ожидаемого в приходящем сегменте, а также правая или верхняя граница окна получения, |
| первый номер в очереди, принесенный пришедшим сегментом, |
| последний номер в очереди, принесенный пришедшим сегментом. |
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 |
Мы получили преимущество данной схемы нумерации в том, что она допускает также защиту для определенной управляющей информации. Это достигается косвенным образом посредством включения некоторых контрольных флагов в очередь, так что они могут быть повторно посланы и подтверждены без сбоя (т.е. будет задействована одна или несколько копий).
Управляющая информация реально находится не в поле данных сегмента. Следовательно, мы должны принять правила косвенного присвоения номеров очереди сегментам управления. SYN и FIN являются единственными управляющими сигналами, приемлемыми для такой защиты, и они используются только при открытии и закрытии соединения. Для целей поддержания очередности, сигнал SYN рассматривается как стоящий перед первым действительным октетом данных в сегменте, куда оба они были помещены. В то же время FIN считается стоящим после последнего реального октета данных в сегменте. Длина сегмента (SEG.LEN) учитывает как данные, так и номера очереди, отведенные под управление. В случае, когда присутствует SYN, значение SEG.SEQ соответствует номеру в очереди для сигнала SYN.
Обработка событий
Обработка, описанная в данной главе, является лишь примером одной из возможных реализаций протокола. Иные реализации могут иметь несколько иные процедуры обработки, однако они должны отличаться от описанных в данной главе лишь в деталях, но никак не по существу.
Деятельность программы протокола TCP можно рассматривать как реагирование на события. Эти происходящие события можно разбивать на три категории: запросы клиентов, прибытие сегментов, истечение контрольного времени. Данная глава описывает деятельность в протоколе TCP в ответ на каждое их этих событий. Во многих случаях необходимая обработка зависит от состояния соединения. События, которые могут произойти:
Команды клиента
 | на открытие соединения |
| на посылку данных |
| на получение данных |
| на закрытие соединения |
| на ликвидацию соединения |
| на определение статуса соединения |
Получения сегментов
Истечение контрольного времени
| для действий клиента |
| для повторной посылки |
| в состоянии ожидания |
Модель интерфейса TCP и клиента состоит в том, что команды клиента выполняются немедленно, а вероятный отложенный отчет предоставляется через механизм событий или псевдопрерываний. В дальнейшем описании понятие "сигнал" может обозначать некое основание для посылки отложенного отчета.
Сообщение об ошибках предоставляется в виде текстовых строк. Например, команды клиента, адресованные к несуществующим соединениям, получат сообщение "error: connection not open".
Пожалуйста учтите, что в дальнейшем вся арифметика для номеров очереди, номеров подтверждения, окон и т.д. осуществляется по модулю 2**32, что соответствует размеру множества номеров очередей.
Заметим также, что "=<" означает "меньше или равно" (по модулю 2**32).
Чтобы постичь смысл обработки приходящих сегментов, естественным было бы представить, что они сперва проверяются на корректность номера очереди (т.е. что их информация попадает в диапазон "окна получения" среди ожидаемых номеров очереди) и что они, в общем случае, будут ставиться в очередь и подвергаться обработке соответственно своим номерам.
Если одни сегменты перекрываются с другими, ранее полученными сегментами, то мы конструируем сегмент, содержащий лишь действительно новые данные, а затем соответствующим образом корректируем поля заголовка.
Заметим, что состояние программы протокола TCP остается при обработке событий без изменений, если обратное не указано особо.
Запрос OPEN
Состояние CLOSED (т.е. блок TCB отсутствует)
Создать новый блок управления передачей (TCB) для хранения информации о состоянии соединения. Заполнить поля идентификатора местного сокета, чужого сокета, приоритета, закрытости/безопасности, а также контрольного времени для клиента. Заметим, что некоторые параметры чужого сокета могут остаться не конкретизированными при пассивном открытии и соответствующие им поля должны быть заданы исходя из параметров пришедшего SYN сигнала. Клиенту может быть предоставлена возможность проверять параметры безопасности и приоритета, если в ответ на такой запрос не будет получено сообщение "error: precedence not allowed" или "error: security/ compartment not allowed". В случае пассивного открытия следует перейти в состояние LISTEN и вернуть управление давшему команду OPEN процессу. Если открытие является активным, а чужой сокет не конкретизирован, то вернуть сообщение "error: fireign socket unspecified".
Если открытие является активным и указан чужой сокет, то послать сегмент с сигналом SYN. Выбирается начальный номер для очереди отправления. Посылаемый сегмент и сигналом SYN имеет форму <SEQ=ISS><CTL=SYN>. Установить переменную SND.UNA в ISS, а SND.NXT в ISS+1. Перейти в состояние SYN-SENT. Вернуть управление процессу, вызвавшему рассматриваемую команду.
Если сделавший запрос клиент не получил доступа к указанному в запросе сокету, то вернуть сообщение "error: connection illegal for this process". Если для создания нового соединения нет места в памяти компьютера, то вернуть сообщение "error: insufficient resources".
Состояние LISTEN
Если происходит активизация и указан чужой сокет, то сменить состояние соединения с пассивного на активный, выбрать ISS. Послать сегмент с сигналом SYN, занести в SND.UNA значение ISS, а в SND.NXT ISS+1. Перейти в SYN-SEND состояние.
Данные, указанные в команде SEND, могут быть посланы в том же сегменте с сигналом SYN, или же могут быть помещены в очередь на передачу, которая может быть осуществлена после перехода в ESTABLISHED состояние. Если в команде сделан запрос на применение бита срочности, то в результате ее выполнения должны быть посланы сегменты данных. Если в очереди заказов на пересылку нет места, то в результате будет получен ответ "error: insufficient resources". Если чужой сокет не указан, то вернуть сообщение "error: foreign socket unspecified"
Состояния
| SYN-SENT |
| SYN-RECEIVED |
| ESTABLISHED |
| FIN-WAIT-1 |
| FIN-WAIT-2 |
| CLOSE-WAIT |
| CLOSING |
| LAST-ACK |
| TIME-WAIT |
Запрос SEND
Состояние CLOSED (например, нет блока TCB)
Если клиент не имеет доступа к такому соединению, то вернуть сообщение "error: connection illegal for this process". В противном случае вернуть "error: connection does not exist".
Состояние LISTEN
Если указан чужой сокет, то сменить состояние соединения с пассивного на активный, выбрать номер ISS. Послать сегмент с сигналом SYN, установить SND.UNA в ISS, а SND.NXT в ISS+1. Установить новое состояние SYN-SENT. Данные из вызова SEND могут быть посланы вместе с сигналом SYN, а могут быть помещены в очередь и отправлены уже после установления ESTABLISHED состояния.
Если в команде дан запрос на применение бита срочности, то он должен быть передан вместе с сегментом данных, возникающим при выполнении этой команды. Если в очереди нет места для запроса, то вернуть сообщение "error: insufficient resources". Если чужой сокет не указан, то вернуть "error: foreign socket unspecified".
Состояние SYN-SENT
Состояние SYN-RECEIVED
Поместить данные в очередь с тем, чтобы отправить после установления ESTABLISHED состояния. Если в очереди нет места, то вернуть сообщение "error: insufficient resources".
Состояние ESTABLISHED
Состояние CLOSE-WAIT
Сегментировать буфер данных и переслать его с ответным подтверждением (значение подтверждения = RCV.NXT). Если для размещения этого буфера недостаточно места в памяти, то просто вернуть сообщение "error: insufficient resources".
Если установлен флаг срочности, то занести в SND.UP значение SND.NXT-1 и установить указатель срочности на уходящие сегменты.
Состояния
| FIN-WAIT-1 |
| FIN-WAIT-2 |
| CLOSING |
| LAST-ACK |
| TIME-WAIT |
Запрос RECEIVE
Состояние CLOSED (например, отсутствует блок TCB)
Если клиент не имеет доступа к такому соединению, вернуть сообщение "error: connection illegal for this process". В противном случае вернуть сообщение "error: connection does not exist".
Состояния
| LISTEN |
| SYN-SENT |
| SYN-RECEIVED |
Состояния
| ESTABLISHED |
| FIN-WAIT-1 |
| FIN-WAIT-2 |
Собрать данные из приходящих сегментов в буфере получения, а затем передать их клиенту. Установить флаг "обнаружено проталкивание" (PUSH), если это имеет место.
Если данным, передаваемым в настоящий момент клиенту, предшествовал RCV.UP, то оповестить клиента о присутствии срочных данных. Когда протокол TCP берет на себя ответственность за получение клиентом данных, то это фактически означает обмен информацией с отправителем в виде подтверждений.
Формирование такого подтверждения обсуждается ниже при рассмотрении алгоритма обработки приходящего сегмента.
Состояние CLOSE-WAIT
Поскольку партнер на другом конце соединения уже послал сигнал FIN, то команды RECEIVE должны получать данные, уже имеющиеся в системе, а не только те, которые уже переданы клиенту. Если в системе больше нет текста, ждущего своего запроса RECIVE, то передать клиенту сообщение "error connection closing". В противном случае использовать для удовлетворения запроса RECEIVE любую имеющуюся информацию.
Состояния
| CLOSING |
| LAST-ACK |
| TIME-WAIT |
Запрос CLOSE
Состояние CLOSED (например, нет блока TCB)
Если клиент не имеет доступа к такому соединению, вернуть сообщение "error: connection illegal for this process". В противном случае вернуть сообщение "error: connection does not exist".
Состояние LISTEN
Любые остающиеся неудовлетворенными запросы RECEIVE будут завершены с сообщением "error: closing". Стереть блок TCB, перейти в CLOSED состояние и вернуть управление клиенту.
Состояние SYN-SENT
Стереть блок TCB и вернуть сообщение "error closing" для любых еще остающихся в очередях запросов SEND или RECEIVE. Состояние SYN-RECEIVED
Если не сделано каких-либо запросов SEND и нет данных, ожидающих отправки, то сформировать FIN сегмент и послать его, а затем перейти в FIN-WAIT-1 состояние. В противном случае поместить данные в очередь для рассмотрения после установления ESTABLISHED состояния.
Состояние ESTABLISHED
Поместить запрос в очередь в ожидании, когда все данные предшествующих команд будут сегментированы. Тогда сформировать FIN сегмент и отправить его партнеру. В любом случае перейти в FIN-WAIT-1 состояние.
Состояние FIN-WAIT-1
Cостояние FIN-WAIT-2
Строго говоря, такая ситуация является ошибочной и должна привести к получению клиентом сообщения "error: connection closing". Однако может быть приемлемым также ответ "Ok", пока не отправлен второй FIN (хотя первый FIN может быть отправлен повторно).
Состояние CLOSE-WAIT
Поместить этот запрос в очередь, пока все предшествующие запросы SEND не будут помещены в сегменты. Затем послать сегмент с сигналом FIN, перейти в CLOSING состояние.
Состояния
| CLOSING |
| LAST-ACK |
| TIME-WAIT |
Запрос ABORT
Состояние CLOSED (например, нет блока TCB)
Если клиент не имеет доступа к такому соединению, вернуть сообщение "error: connection illegal for this process". В противном случае вернуть сообщение "error: connection does not exist".
Состояние LISTEN
Любые остающиеся запросы RECEIVED должны завершиться с возвратом сообщения "error: connection reset". Стереть блок TCB, перейти в состояние CLOSED, вернуть управление программе клиента.
Состояние SYN-SENT
Все находящиеся в очереди запросы SEND и RECEIVE должны получить сообщение "connection reset", стереть блок TCB, перейти в состояние CLOSED, вернуть управление клиенту.
Состояния
| SYN-RECEIVED |
| ESTABLISHED |
| FIN-WAIT-1 |
| FIN-WAIT-2 |
| CLOSE-WAIT |
<SEQ=SND.NXT><CTL=RST>
Все находящиеся в очереди запросы SEND и RECEIVED должны получить сообщение "connection reset". Все сегменты, находящиеся в очереди на передачу (за исключением только что сформированного сигнала RST) и в очереди на повторную пересылку должны быть ликвидированы. Стереть блок TCB, перейти в CLOSED состояние, вернуть управление клиенту.
Состояния
| CLOSING |
| LAST-ACK |
| TIME-WAIT |
Запрос STATUS
Состояние CLOSED (например, нет блока TCB)
Если клиент не имеет доступа у такому соединению, то возвратить сообщение "error: connection illegal for this process". В противном случае вернуть "error: connection does not exist".
Состояние LISTEN
Вернуть сообщение "state=LISTEN" и указатель на блок TCB.
Состояние SYN-SENT
Вернуть сообщение "state=SYN-SENT" и указатель на блок TCB.
Состояние SYN-RECEIVED
Вернуть сообщение "state=SYNRECEIVED" и указатель на блок TCB.
Состояние ESTABLISHED
Вернуть сообщение "state=ESTABLISHED" и указатель на блок TCB.
Состояние FIN-WAIT-1
Вернуть сообщение "state=FIN-WAIT-1" и указатель на блок TCB.
Состояние FIN-WAIT-2
Вернуть сообщение "state=FIN-WAIT-2" и указатель на блок TCB.
Состояние CLOSE-WAIT
Вернуть сообщение "state=CLOSE-WAIT" и указатель на блок TCB.
Состояние CLOSING
Вернуть сообщение "state=CLOSING" и указатель на блок TCB.
Состояние LAST-ACK
Вернуть сообщение "state=LAST-ACK" и указатель на блок TCB.
Состояние TIME-WAIT
Вернуть сообщение "state=TIME-WAIT" и указатель на блок TCB.
Приход сегментов
Если состояние соединения CLOSED (например, нет блока TCB), то все данные из указанного сегмента будут выброшены. Сегмент, пришедший с сигналом RST, будет ликвидирован. Сегмент же, не содержащий сигнала RST, вызовет посылку сигнала RST в ответ. Подтверждение и номер очереди будут выбраны таким образом, чтобы сделать последовательность перезагрузки приемлемой для программы TCP, отправившей сегмент, который и вызвал такую реакцию.
Если бит ACK сброшен, то используется номер очереди нуль:
<SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
Если же ACK установлен, то
<SEQ=SEG.ACK><CTL=RST>
Вернуть управление прерванной программе.
Если состояние соединения LISTEN, то
Сперва проверить присутствие сигнала RST.
Сигнал RST, пришедший вместе с сегментом, должен игнорироваться, а управление должно быть возвращено прерванной программе.
Во-вторых, проверить на присутствие ACK.
Любое подтверждение является ошибкой, если оно пришло на конец соединения, все еще находящийся в состоянии LISTEN. В ответ на любой сегмент, пришедший с ACK, должен быть сформирован приемлемый сегмент с сигналом перезагрузки. Сигнал RST должен быть сформирован следующим образом:
<SEQ=SEG.ACK><CTL=RST>
Вернуть управление прерванной программе.
В-третьих, проверить на присутствие сигнала SYN
Если установлен бит SYN, то проверить безопасность. Если значение параметра безопасность/закрытость в пришедшем сегменте не совпадает в точности со значением безопасность/ закрытость в блоке TCB, то послать сигнал перезагрузки и вернуть управление прерванной программе:
<SEQ=SEG.ACK><CTL=RST>
Если значение SEQ.PRC меньше, чем TCB.PRC, то перейти к следующему пункту.
Установить RCV.NXT в SEG.SEQ+1, IRS установить в SEG.SEQ, а остальные тексты и функции управления поместить в очередь для последующей обработки. Выбрать значение для ISS и отправить сегмент подтверждения в форме
<SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK>
Переменную SND.NXT установить в ISS+1, а SND.UNA в ISS. Установить для соединения новое состояние SYN-RECEIVED. Заметим, что в состоянии SYN-RECEIVED будут обрабатываться все приходящие данные и команды управления (вместе с SYN), но уже не будет как прежде осуществляться обработка сигналов SYN и ACK. Если состояние LISTEN не сформулировано полностью (например, не указан исчерпывающе чужой сокет, то именно в этот момент должны быть доопределены поля блока TCB, оставшиеся незаполненными.
В-четвертых, искать в пришедшем сегменте остальные команды управления, а также собственно данные. Любые сегменты с иными командами управления или заполненные текстом (но не содержащие сигнала SYN) должны получить от местной программы TCP подтверждение, и, таким образом, будут отброшены во время работы с подтверждением. Приходящий сегмент с сигналом RST не может быть правильным, поскольку он не может являться ответом на информацию, переданную данной реализацией соединения. Так что Вы вряд ли получите это сигнал, но если это произойдет, выбросьте пришедший сегмент и верните управление прерванной программе.
Если состояние соединения SYN-SENT
Во-первых, проверить бит ACK Если бит ACK выставлен, то
В случае, если SEG.ACK = <ISS или SEG.ACK > SND.NXT,
послать сигнал перезагрузки
<SEQ=SEG.ACK><CTL=RST>
( Если не выставлен бит RST. Если он все же выставлен, то, ничего не делая выкинуть пришедший сегмент и вернуть управление прерванной программе.) Ликвидировать сегмент, вернуть управление.
Если SND.UNA =< SEG.ACK =< SND.NXT, то полученное в сегменте подтверждение становится приемлемым.
Во-вторых, проверить бит RST.
В случае, если бит RST выставлен
Если ожидалось получение сегмента с подтверждением, то дать клиенту объявление "error: connection reset", вернуть сегмент, перейти в состояние CLOSED, убрать блок TCB, и, наконец, вернуть управление прерванной программе. В противном случае (нет подтверждения) ликвидировать сегмент и вернуть управление.
В-третьих, проверить уровни безопасности и приоритета
Если в пришедшем сегменте значения полей безопасность/ закрытость не совпадают в точности со значениями в блоке TCB, то послать сигнал перезагрузки, а точнее если имеется ACK, то послать
<SEQ=SEG.ACK><CTL=RST>
в противном случае послать
<SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
Если имеется значение ACK, то
приоритет в пришедшем сегменте должен совпадать с приоритетом, указанным в блоке TCB. Если это не так, то послать сигнал перезагрузки
<SEQ=SEG.ACK><CTL=RST>
Если же ACK отсутствует, то выполнить следующее
Если в сегменте указан приоритет выше, чем приоритет в блоке TCB, то, если это позволяют клиент и система, увеличить значение приоритета в блоке TCB до значения, указанного в сегменте.
Если же увеличивать приоритет не разрешается, послать сигнал перезагрузки:
<SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
Если в сегменте указан приоритет, меньший, чем в блоке TCB, то просто перейти к следующему пункту анализа.
В-четвертых, проверить установку бита SYN. Данный этап должен осуществляться только если бит ACK не вызывает проблем, или если он не установлен, сегмент также не содержит сигнала RST.
Если бит SYN установлен и параметры безопасности/ закрытости приоритета являются приемлемыми, то в переменную SEG.NXT записать значение SEG.SEQ+1, а IRS установить равным SEG.SEQ.
SND. UNA должно быть повышено до SEG.ACK (если имеется ACK), а любые сегменты в очереди на повторную посылку, получившие таким образом подтверждение, должны быть удалены.
Если SND.UNA > ISS (наш сигнал SYN получит подтверждение), то установить для соединения состояние ECTABLISHED и сформировать ACK сегмент
<SEQ-SND.NXT><ACK=RCV.NXT><CTL=ACK>
и отправить его. В этот сегмент могут быть включены данные или команды из очереди на отправление. Если в пришедшем сегменте есть иные команды или даже некий текст в поле данных, то продолжить обработку далее, начиная с шестого этапа ниже, где осуществляется проверка бита URG. Если таких команд и данных нет, передать управление прерванной программе. Если же бит SYN не установлен, то перейти в состояние SYN-RECEIVED, сформировать сегмент SYN, ACK:
<SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK>
и послать его. Если в пришедшем сегменте имеются команды или текст в поле данных, то поместить их в очередь для обработки после установления ESTABLISH состояния. Вернуть управление прерванной программе.
В-пятых, если установлены биты SYN или RST, то выкинуть пришедший сегмент и вернуть управление прерванной программе. Если во время прихода сегмента соединение находилось в состоянии, не описанном выше, то
Во-первых, проверить номер очереди
Состояния
| SYN-RECEIVED |
| ESTABLISHED |
| FIN-WAIT-1 |
| FIN-WAIT-2 |
| CLOSE-WAIT |
| CLOSING |
| LAST-ACK |
| TIME-WAIT |
Тест на приемлемость приходящего сегмента рассматривает четыре варианта:
| Длина сегмента |
Окно получения |
Текст |
| 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 |
/p>
Если RCV. WND нулевой, никакие сегменты не будут приемлемы, однако должна быть специально оговорена приемлемость получения правильных сигналов ACK, URG и RST.
Если приходящий сегмент неприемлем, то в ответ послать его подтверждение
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
если бит RST не установлен (если он все же выставлен, то выкинуть пришедший сегмент и вернуть управление прерванной программе. )
После посылки подтверждения ликвидировать не принятый сегмент и вернуть управление прерванной программе.
В дальнейшем рекомендации строятся на предположении, что пришедший сегмент является идеализированным и начинается с RSV.NXT, не выходящим за окно. Реальные же сегменты можно подгонять под такое предположение, отбрасывая любые их части, выходящие за пределы окна (включая даже сигналы SYN и FIN), и осуществляя дальнейшую их обработку только если сегмент после этого начинается с номера RCV.NXT. Сегменты с большими номерами в очереди сохраняются для обработки в дальнейшем.
Во-вторых, проверить бит RST.
Состояние SYN-RECEIVED
Если бит RST установлен, то выполнить следующие действия:
Если данное соединение было инициировано командой пассивного открытия OPEN (например, был осуществлен переход из состояния LISTEN), то возвратить данное соединение в состояние LISTEN, а управление вернуть прерванной программе. Нет нужды информировать об этом пользователя. Если данное соединение инициируется командой активного открытия OEPN (например, был переход из состояние SYN-SENT), то происходит отказ от этого соединения, а клиенту посылается сообщение "connection refused". В любом случае должны быть удалены все сегменты из очереди на повторную посылку. Кроме того, в случае активного открытия перейти в состояние CLOSED, удалить блок TCB и вернуть управление прерванной программе.
Состояния
| ESTABLISHED |
| FIN-WAIT-1 |
| FIN-WAIT-2 |
| CLOSE-WAIT |
Убрать все сегменты из очередей. Клиенты должны получить необязательное сообщение общего назначения "connection reset". Перейти в состояние CLOSED, стереть блок TCB и вернуть управление прерванной программе.
Состояния
| CLOSING |
| LAST-ACK |
| TIME-WAIT |
В-третьих, проверить значение безопасности и приоритета у пришедшего сегмента
Состояние SYN-RECIEVED
Если безопасность/закрытость и приоритет в пришедшем сегменте не совпадают с безопасностью/закрытостью и приоритетом, указанными в блоке TCB, то послать сигнал перезагрузки и возвратить управление прерванной программе.
Состояние ESTABLISHED
Если безопасность/закрытость и приоритет в пришедшем сегменте не совпадают в точности с безопасностью/ закрытостью и приоритетом, указанными в блоке TCB, то послать сигнал перезагрузки, все еще остающиеся не обслуженными запросы RECEIVED и SEND должны получить ответ "reset". Все сегменты из очередей должны быть удалены. Клиенты должны тоже получить необязательный общий сигнал "connection reset". Перейти в состояние CLOSED, удалить блок TCB и вернуть управление прерванной программе.
Заметим, что данная проверка ставится после проверки номера в очереди для того, чтобы предотвратить разрыв данного соединения, инициированный получением сегмента, оставшегося от прежнего соединения с иными безопасностью и приоритетом, существовавшего некогда между данными портами.
В-четвертых, проверить бит SYN
Состояния
| SYN-RECEIVED |
| ESTABLISHED |
| FIN-WAIT-1 |
| FIN-WAIT-2 |
| CLOSE-WAIT |
| CLOSING |
| LAST-ACK |
| TIME-WAIT |
Если SYN находится за пределами окна, то до данного пункта дело не должно дойти. Еще на первом этапе (проверка номера очереди) должно было быть послано подтверждение. В-пятых, проверить поле ACK Если бит ACK не установлен, то сегмент ликвидировать, а управление передать прерванной программе.
Если бит ACK установлен
Состояние SYN-RECEIVED.
Если SND.UNA =< SEG.ACK =< SND.NXT, то перейти в состояние ESTABLISHED и продолжить обработку.
Если же подтверждение в сегменте оказалось неприемлемым, то сформировать сегмент с сигналом перезагрузки
<SEQ=SEG.ACK><CTL=RST>
и послать его.
Состояние ESTABLISHED
Если SND.UNA < SEG.ACK =< SND.NXT, то установить в SND.UNA значение из SEG.ACK. Любые сегменты из очереди на повторную посылку, получившие при этом подтверждение, удаляются. Клиенты должны получить положительные отзывы на буферы, которые были посланы командой SEND, а ныне получили полное подтверждение (например, команда послать буфер с данными должна завершиться сообщением "ok").
Если подтверждение является дубликатом (SEG.ACK < SND.UNA), то его можно игнорировать.
Если сообщение ACK подтверждает что-либо, еще не отправленное (SEG.ACK > SND.NXT), то послать ACK, ликвидировать сегмент и вернуть управление прерванной программе.
Если SND.UNA < SEG.ACK =< SND.NXT, то следует обновить окно для посылки.
Если (SND.WL1 < SEG.SEQ или (SND.WL1 = SEG.SEQ и SND.WL2 =< SEG.ACK)), то установить SND.WND согласно значению SEG.WND, SND.WL1 в SEG.SEQ, SND.WL2 в SEG.ACK.
Заметим, что в SND.WND записано смещение относительно SND.UNA, xnj d SND.WL1 записан номер очереди для последнего сегмента, используемого для обновления SND.WND, а также, что в SND.WL2 записан номер подтверждения из последнего сегмента, используемого для обновления SND.WND. При этом проверка охраняет от использования устаревших сегментов для обновления окна.
Состояние FIN-WAIT-1
Все так же как при обработки в случае состояния ESTABLISHED, но если наш сигнал FIN теперь получил подтверждение, то перейти к FIN-WAIT-2 и продолжить обработку в таком состоянии.
Состояние FIN-WAIT-2
Все так же как при обработке для случая состояния ESTABLISHED, но если очередь повторной посылки пуста, то команда клиента на закрытие соединения CLOSE может получить подтверждение ("ok"), но при этом не удаляет блока TCB.
Состояние CLOSE-WAIT
Делается та же обработка, что была для случая со стояния ESTABLISHED.
Состояние CLOSING
Все так же, как при обработке в случае состояния ESTABLISHED, но если ACK в пришедшем сегменте подтверждает наш сигнал FIN, то перейти в состояние TIME-WAIT. В противном случае сегмент игнорируется.
Состояние LAST-ACK
Единственная вещь, которая может произойти в этом состоянии получение подтверждения на сигнал FIN. Если наш сигнал FIN не был подтвержден, то удалить блок TCB, перейти в состояние CLOSED и вернуть управление прерванной программе.
Состояние TIME-WAIT
Единственная вещь, которая может произойти в этом состоянии это повторная передача чужого сигнала FIN.
Подтвердить сигнал и повторно стартовать по истечении контрольного времени 2MSL.
В-шестых, проверить бит URG
Состояния
| ESTABLISHED |
| FIN-WAIT-1 |
| FIN-WAIT-2 |
Состояния
| CLOSE-WAIT |
| CLOSING |
| LAST-ACK |
| TIME-WAIT |
В-седьмых, обработать данные их сегмента
Состояния
| ESTABLISHED |
| FIN-WAIT-1 |
| FIN-WAIT-2 |
Если сегмент пуст и несет флаг проталкивания PUSH, то при возврате буфера оповестить клиента о том, что был получен сигнал PUSH.
Когда протокол TCP берет на себя ответственность за получение клиентом данных, то он должен также давать подтверждение факта получения этих данных.
Как только программа протокола TCP принимает на себя управление потоком данных, она ставит значение RCV.NXT перед блоком принимаемых данных, а RCV.WND устанавливает соответственно емкости буфера в данный момент. В общем случае значения RCV.NXT и RCV.WND не должны корректироваться в меньшую сторону.
Послать подтверждение в виде
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
Данное подтверждение должно быть добавлено к уходящему на другой конец соединения сегменту и, по возможности, без излишних задержек.
Состояния
| CLOSE-WAIT |
| CLOSING |
| LAST-ACK |
| TIME-WAIT |
В-восьмых, проверить бит FIN
Не обрабатывать сигнала FIN, если состояние CLOSED, LISTEN или SYN-SENT, поскольку нет возможности проверить SEG.SEQ, выкинуть пришедший сегмент и возвратить управление прерванной программе.
Если бит FIN установлен, то дать клиенту сигнал "connection closing", с тем же сообщением завершить все ждущие решения запросы RECEIVED, установить RCV.NXT перед местом в очереди сигнала FIN, послать для последнего подтверждение. Заметим, что сигнал FIN подразумевает проталкивание (PUSH) текстов во всех сегментах, еще не полученных клиентом.
Состояния
| SYN-RECEIVED |
| ESTABLISHED |
Состояние FIN-WAIT-1
Если наш сигнал FIN получил подтверждение (возможно в этом же сегменте), то перейти в состояние TIME-WAIT, за пустить контрольный таймер, отключить все иные таймеры. Если подтверждения не было, перейти в состояние CLOSING.
Состояние FIN-WAIT-2
Перейти в состояние TIME-WAIT. Запустить контрольный таймер, отключить все контрольные таймеры.
Состояние CLOSE-WAIT
Остаться в состоянии CLOSE-WAIT
Состояние CLOSING
Остаться в состоянии CLOSING
Состояние LAST-ACK
Остаться в состоянии LAST-ACK
Состояние TIME-WAIT
Остаться в состоянии TIME-WAIT. По истечении контрольного времени 2MSL стартовать повторно. Вернуть управление прерванной программе.
Истечение контрольного времени для клиента
Если истекло контрольного время, то в каком бы состоянии не находилась программа, убрать все очереди, дать клиенту общий сигнал "error: connection aborted due to user timeout", такой же сигнал дать всем ждущим обработки запросам, ликвидировать блок TCB, перейти в состояние CLOSED, вернуть управление прерванной программе.
Истечение контрольного времени для повторной посылки
В каком бы состоянии не находилась программа, если для сегмента в очереди на повторную посылку истекло контрольное время, послать этот сегмент еще раз, но уже вне очереди, произвести вновь инициализацию таймера повторной посылки, вернуть управление прерванной программе.
Истечение контрольного времени для состояния TIME-WAIT
Если истекло контрольное время для состояния TIME-WAIT, то ликвидировать соединение и блок TCB, перейти в состояние CLOSED, вернуть управление прерванной программе. <
Определения указанных опций
Конец списка опций
| 00000000 | тип 0 |
Этот код опции определяет конец списка опций. Конец списка может не совпадать с концом TCP заголовка, указанным в поле Data Offset.
Эта опция используется после всех опций, но не после каждой из них. Опцию необходимо использовать только в том случае, если иначе не будет совпадения с концом TCP заголовка.
Нет операций
| 00000001 | тип 1 |
Опции этого типа могут ставиться между опциями. Целью при этом может служить выравнивание очередной опции по границе слова. Нет гарантии, что отправители будут использовать данную опцию. Поэтому получатели должны быть готовы обрабатывать опции, даже если они не будут начинаться на границе слова.
Максимальный размер сегмента
| 00000010 | 00000100 | макс.разм.сегм. |
| тип 2 | длина 4 | . |
Поле данных опции - 16 бит. Если опция присутствует в списке, то она указывает для программы протокола TCP максимальный размер получаемого сегмента, отправившей сегмент с этой опцией. Эту опцию следует посылать лишь при первоначальном запросе на установление соединения (т.е. в сегментах с установленным контрольным битом SYN). Если данная опция не была использована, ограничения на размер отсутствуют.
Padding
(выравнивание) длина переменная Выравнивание TCP заголовка осуществляется с тем, чтобы убедиться в том, что TCP заголовок заканчивается, а поле данных сегмента начинается на 32-битной границе. Выравнивание выполняется нулями.
Отправление
| посылка неподтверждена |
| послать следующий сегмент |
| отправить окно |
| отправить срочный указатель |
| номер очереди сегмента, использованный для обновления последнего окна |
| номер подтверждения в сегменте, используемый для обновления последнего окна |
| первоначальный номер очереди отправления |
Передача данных
Коль соединение установлено, передача данных осуществляется с помощью обмена сегментами. Т.к. сегменты могут быть потеряны в результате ошибок (например, ошибки в контрольной сумме) или перегрузки сети, то программа протокола TCP использует механизм повторной посылки (по истечении определенного времени) с тем, чтобы убедиться в получении каждого сегмента. В главе, посвященной номерам очередей, обсуждалось, как программа TCP в сегментах осуществляет проверку номе ров очередей и номеров подтверждения на предмет их корректности.
Отправитель данных с помощью значения переменной SND.NXT отслеживает следующий номер в очереди, подлежащий отправке. Получатель данных с помощью переменной RCV.NXT отслеживает следующий номер, прибытие которого он ожидает. В переменную SND.UNA отправитель данных помещает значение самого старого номера, который был отправлен, но еще не получил подтверждения. Если бы поток данных моментально иссяк, а все отправленные данные получили подтверждение, то тогда бы все эти при переменные содержали одинаковое значение.
Когда отправитель информации создает и посылает некий сегмент, он увеличивает значение переменной SND.NXT. Адресат по получении сегмента увеличивает значение переменной RCV.NXT и отправляет подтверждение. Когда программа TCP, пославшая данные, получает подтверждение, она увеличивает значение SND.UNA. Разность в значениях этих переменных является мерой, характеризующей задержку сегментов в сети. Величина, на которую надо всякий раз осуществлять приращение значения этих переменных, является длиной поля данных в сегменте. Заметим, что поскольку соединения находятся в состоянии ESTABLISHED, все сегменты, в дополнение к собственно данным, должны нести некую информацию о подтверждении ранее отправленных сегментов.
Запрос пользователя о закрытии соединения (CLOSE) подразумевает использование функции проталкивания, что осуществляется с помощью контрольного флага FIN приходящем сегменте.
Передача срочной информации
Механизм срочной передачи протокола TCP предназначен для того, чтобы клиент, отправляющий данные, мог побудить получателя принять некую срочную информацию, а также позволить программе TCP, принимающей данные, информировать своего клиента, когда вся имеющаяся на настоящий момент информация будет получена.
Данный механизм позволяет помечать некую точку в потоке данных как конец блока срочной информации. Когда в программе TCP, принимающей данные, данная точка окажется впереди индикатора номера в очереди получения (RCV.NXT), эта программа TCP должна дать команду своему клиенту перейти в "срочный режим". Когда номер в очереди получения догонит срочный указатель в потоке данных, программа TCP должна дать команду клиенту прийти в "нормальный режим". Если срочный указатель сменит свое положение, когда клиент находится в "срочном режиме", последний не узнает об этом.
Данный метод использует поле флага срочности, который присутствует во всех передаваемых сегментах. Единица в поле контрольного флага URG означает, что задействовано поле срочности . Чтобы получить указатель этого поля в потоке данных, необходимо дополнить его номером рассматриваемого сегмента в очереди. Отсутствие флага URG означает отсутствие у отправителя не посланных срочных данных.
При указании срочности клиент должен также послать по крайней мере один октет данных. Если клиент, помещающий данные, дополнительно закажет функцию проталкивания, то передача срочной информации ждущему ее процессу многократно ускорится.
Период молчания
Чтобы быть уверенным в том, что программа TCP не создает сегмента, несущего номер очереди, который уже используется старым сегментом, все еще "ходящим" по сети, программа TCP должна сохранять молчание по крайней мере в течении времени жизни сегмента (MSL) до тех пор, пока она не назначит какие-либо номера очереди при запуске или восстановлении после сбоя, когда записи в памяти для прежних номеров из очереди были потеряны. В данной спецификации MSL берется равным 2 минуты.
Это значение выбрано разработчиками и может быть изменено, если практика покажет необходимость в этом. Заметим, что если программа протокола в некотором смысле повторно инициализируется, но при этом в памяти остались применявшиеся ранее номера очереди, то в ожидании нужды нет; следует лишь убедиться в том, что новые рабочие номера очередей больше, чем применявшиеся ранее.
Получение
| - получить следующий сегмент |
| - получить окно |
| - получить срочный указатель |
| - первоначальный номер очереди получения |
Нижеприведенные диаграммы могут помочь связать некоторые из этих переменных с местом в очереди
Очередь отправления
старые номера очереди, которые получили подтверждение
номера очереди для данных, не получивших подтверждения
номера очереди, допущенные к новой передаче
следующие номера очереди, чья передача еще не разрешена
Рис. 1 Очередь отправления
Окно отправления - это участок очереди, отмеченный меткой 3 на рисунке 1.
Очередь получения
старые номера очереди, которые получили подтверждение
номера очереди, допущенные к очередному этапу получения
следующие номера очереди, еще не получившие разрешения
Рис.2 Очередь получения
Окно получения - это участок очереди, отмеченный меткой 2 на рисунке 2.
В обсуждении также часто используются некоторые переменные, берущие свое значение из полей очередного сегмента.
Переменные для очередного сегмента
| номер очереди для сегмента |
| номер подтверждения для сегмента |
| длина сегмента |
| окно для сегмента |
| срочный указатель для сегмента |
| приоритет для сегмента |
Соединение во время функционирования проходит через серии промежуточных состояний. Это состояния LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, а также фиктивное состояние CLOSED. Состояние CLOSED является фиктивным, поскольку оно представляет состояние, когда не существует блока TCP, а потому и нет соединения. Краткое описание состояний:
| Ожидание запроса на соединение со стороны чужих портов и программ TCP |
| Ожидание парного запроса на установление соединения. С нашей стороны запрос уже сделан. |
| Ожидание подтверждения после того, как запрос соединения уже принят и отправлен. |
| Состояние открытого соединения, принимаемые данные можно представить пользователю. Это нормальное состояние соединения в фазе передачи данных. |
| Ожидание запроса от чужой программы TCP, или подтверждения ранее отправленного запроса на закрытие соединения. |
| Ожидание запроса на закрытие соединения со стороны чужой программы TCP. |
| Ожидание запроса на закрытие соединения со стороны своего клиента. |
| Ожидание подтверждения со стороны чужой программы TCP запроса о закрытии соединения. |
| Ожидание запроса на закрытие соединения, ранее отправленного чужой программе TCP (запрос включал также подтверждение получения чужого запроса на закрытие соединения). |
| Ожидание когда истечет достаточное количество времени и можно быть уверенным, что чужая программа TCP получила подтверждение своего запроса на закрытие соединения. |
| Состояние полного отсутствия соединения. |
/p>
Соединение TCP переходит с одного состояния на другое в ответ на события. Событие - это запросы клиента (открытие, посылка, получение, закрытие, отказ, получение состояния соединения), приход сегментов, и особенно тех, которые содержат флаги SYN, ACK, RST и FIN, а также истечение выделенного времени.
Диаграмма состояний на рисунке иллюстрирует лишь смену состояний, а также вызвавшие это события, производимые действия, но не адреса, условия ошибок, не действия, не связанные прямо с изменением состояния.
Более подробные сведения о действиях программы протокола TCP в ответ на события приведены в последней главе.
Замечание. Данная диаграмма является лишь сводной, но не должна восприниматься как полная спецификация.
<table border="0" cellpadding="0" cellspacing="0" width="100%">
Пожелания по управлению окном
Выделение очень малого окна приводит к передаче данных очень маленькими сегментами, тогда как лучший режим осуществляется при использовании сегментов большего размера.
Чтобы избежать применения малых окон, получателю данных предлагается откладывать изменение окна до тех пор, пока свободное место не составит X процентов от максимально возможного в памяти для этого соединения (где X может быть от 20 до 40).
Другой совет, чтобы не посылать малые сегменты, состоит в том, чтобы отправитель не спешил с посылкой данных, пока окно не станет достаточно большим. Но если клиент дает команду на использование функции проталкивания, то данные следует немедленно отправлять, даже если это будет осуществляться малым сегментом.
Заметим, что во избежание ненужных повторных пересылок не нужно медлить с посылкой подтверждений. Стратегия может заключаться в посылке подтверждения при получении сегмента малого размера (без обновления информации об окне), затем посылается другое подтверждение с новой информацией об окне, если последнее расширяется.
Сегмент, посылаемый для проверки нулевого окна, может инициировать разбивку передаваемых данных на все более и более мелкие сегменты. Если сегмент, содержащий единичный октет данных и отправленный для проверки нулевого окна, получен, то он займет один октет в имеющемся в данный момент окне. Если же программа TCP просто посылает столько данных, сколько может, всякий раз, когда окно ненулевое, то передаваемые данные будут разбиваться на большие и малые сегменты. По истечении некоторого времени случающиеся паузы в выделении окна получателем данные приведут к разбивке больших сегментов на многочисленные и уже не столь большие пары. Итак, по прошествии некоторого времени передача данных будет осуществляться преимущественно малыми сегментами.
Предложение состоит в том, чтобы реализации протокола TCP активно пытались объединить малые окна в более крупные, поскольку механизмы управления окном стремятся ввести много малых окон в простейших реализациях протокола.
Принцип устойчивости
Все реализации протокола TCP будут следовать общему принципу устойчивости: быть консервативным в своих действиях и предоставлять свободу для других. <
Приоритет и безопасность
Протокол TCP использует тип сервиса и опцию безопасности протокола Internet с тем, чтобы пользователям протокола TCP обеспечить приоритет и безопасность на каждом соединении. Не все модули протокола TCP обязательно будут действовать в многоуровневой системе обеспечения безопасности. Некоторые модули ограничиваются только обычными, неспецифическими соединениями, другие ограничиваются лишь первым уровнем безопасности и закрытости. Следовательно, некоторые реализации протокола TCP и услуг для пользователей могут использовать лишь часть многоуровневой системы безопасности.
Модули TCP, действующие в многоуровневой системе безопасности, должны адекватным образом выставлять в отсылаемых сегментах флаги безопасности и приоритета. Такие модули TCP должны также позволять своим клиентам или вышестоящим протоколам, таким как Telnet и THP, указывать требуемый уровень безопасности, закрытости и приоритета для устанавливаемых соединений.
Программное обеспечение хост-компьютера
Предполагается, что программа протокола TCP является модулем операционной системы. Клиенты обращаются к протоколу TCP в значительной степени так же, как если бы они обращались к файловой системе. Сам протокол TCP может обращаться к другим функциям операционной системы, к примеру, для управления структурами данных. Предполагается, что собственно интерфейс с локальной сетью осуществляется драйвером устройства. Протокол TCP не обращается непосредственно к драйверам сетевых устройств, а вместо этого делает вызов для модуля Internet протокола, который в свою очередь и обращается к драйверу устройства.
Механизм протокола TCP не исключает его реализации на входном процессоре. Однако, при такой реализации протокол общения между входными процессорами должен обеспечивать средства для поддержки описанного в этом документе интерфейса между пользователем и протоколом TCP.
Протокол ТСР
Протокол TCP предоставляет транспортные услуги, отличающиеся от услуг UDP. Вместо ненадежной доставки датаграмм без установления соединений, он обеспечивает гарантированную доставку с установлением соединений в виде байтовых потоков.
Протокол TCP используется в тех случаях, когда требуется надежная доставка сообщений. Он освобождает прикладные процессы от необходимости использовать таймауты и повторные передачи для обеспечения надежности. Наиболее типичными прикладными процессами, использующими TCP, являются FTP (File Transfer Protocol - протокол передачи файлов) и TELNET. Кроме того, TCP используют система X-Window, rcp (remote copy - удаленное копирование) и другие "r-команды". Большие возможности TCP даются не бесплатно. Реализация TCP требует большой производительности процессора и большой пропускной способности сети. Внутренняя структура модуля TCP гораздо сложнее структуры модуля UDP.
Прикладные процессы взаимодействуют с модулем TCP через порты. Для отдельных приложений выделяются общеизвестные номера портов. Например, сервер TELNET использует порт номер 23. Клиент TELNET может получать услуги от сервера, если установит соединение с TCP-портом 23 на его машине.
Когда прикладной процесс начинает использовать TCP, то модуль TCP на машине клиента и модуль TCP на машине сервера начинают общаться. Эти два оконечных модуля TCP поддерживают информацию о состоянии соединения, называемого виртуальным каналом. Этот виртуальный канал потребляет ресурсы обоих оконечных модулей TCP. Канал является дуплексным; данные могут одновременно передаваться в обоих направлениях. Один прикладной процесс пишет данные в TCP-порт, они проходят по сети, и другой приклад ной процесс читает их из своего TCP-порта.
Протокол TCP разбивает поток байт на пакеты; он не сохраняет границ между записями. Например, если один прикладной процесс делает 5 записей в TCP-порт, то прикладной процесс на другом конце виртуального канала может выполнить 10 чтений для того, чтобы получить все данные. Но этот же процесс может получить все данные сразу, сделав только одну операцию чтения. Не существует зависимости между числом и размером записываемых сообщений с одной стороны и числом и размером считываемых сообщений с другой стороны.
Протокол TCP требует, чтобы все отправленные данные были подтверждены принявшей их стороной. Он использует таймауты и повторные передачи для обеспечения надежной доставки. Отправителю разрешается передавать некоторое количество данных, не дожидаясь подтверждения приема ранее отправленных данных. Таким образом, между отправленными и подтвержденными данными существует окно уже отправленных, но еще неподтвержденных данных. Количество байт, которые можно передавать без подтверждения, называется размером окна. Как правило, размер окна устанавливается в стартовых файлах сетевого программного обеспечения. Так как TCP-канал является дуплексным, то подтверждения для данных, идущих в одном направлении, могут передаваться вместе с данными, идущими в противоположном направлении. Приемники на обеих сторонах виртуального канала выполняют управление потоком передаваемых данных для того, чтобы не допускать переполнения буферов. <
Протокол UDP
Протокол UDP намного проще, чем ТСР; он полезен в ситуациях, когда мощные механизмы обеспечения надежности протокола ТСР не обязательны. Заголовок UDP имеет всего четыре поля: поле порта источника (source port), поле порта пункта назначения (destination port), поле длины (length) и поле контрольной суммы UDP (checksum UDP). Поля порта источника и порта назначения выполняют те же функции, что и в заголовке ТСР. Поле длины обозначает длину заголовка UDP и данных; поле контрольной суммы обеспечивает проверку целостности пакета. Контрольная сумма UDP является факультативной возможностью.
Главным применением протокола UDP являются системы Internet Name Server, и Trivial File Transfer, SNMP.
Протокол управления передачей RTCP
Протокол управления передачей RTCP (Real-Time Transport Control Protocol) работает с несколькими адресатами для обеспечения обратной связи с отправителями данных RTP и другими участниками сеанса. RTCP использует тот же самый базовый транспортный протокол, что и RTP (обычно, UDP), но другой номер порта. Каждый участник сеанса периодически посылает RTCP-пакет всем остальным участникам сеанса.
RTCP выполняет следующие функции:
| обеспечение качества услуг и обратной связи в случае перегрузки; |
| идентификация отправителя; |
| оценка размеров сеанса и масштабирование. |
Многоадресность RTCP-пакетов дает возможность участникам группы оценить качество приема и сообщить о своих проблемах (например, утере пакетов, избыточной неравномерности передачи). Обратная связь с получателями важна также для диагностики ошибок при распространении пакетов.
RTCP-пакеты содержат стандартное текстовое описание отправителя, обеспечивающее его идентификацию. Кроме того, они помогают пользователю идентифицировать потоки, относящиеся к различным сеансам. Например, они дают возможность определить, что одновременно открыты отдельные сеансы для передачи аудио- и видеоинформации.
Оценка размера сеанса и масштабирование осуществляются управлением частотой передачи RTCP-пакетов. При небольшом числе участников один RTCP-пакет посылается максимум каждые 5 секунд. Цель состоит в том, чтобы трафик RTCP не превышал 5% от общего трафика сеанса.
Работа с соединениями
Механизмы управления потоком и обеспечения достоверности, описанные выше, требуют, чтобы программы протокола TCP инициализировали и поддерживали определенную информацию о состоянии каждого потока данных. Набор такой информации, включающий сокеты, номера очереди, размеры окон, называется соединением. Каждое соединение уникальным образом идентифицируется парой сокетов на двух концах.
Если два процесса желают обмениваться информацией, соответствующие программы протокола TCP должны сперва установить соединение (на каждой стороне инициализировать информацию о статусе). По завершении обмена информацией соединение должно быть расторгнуто или закрыто, чтобы освободить ресурсы для предоставления другим пользователям.
Поскольку соединения должны устанавливаться между ненадежными хост-компьютерами и через ненадежную коммуникационную систему Internet, то во избежание ошибочной инициализации соединений используется механизм подтверждения связи с хронометрированными номерами очереди.
Разделение каналов
Чтобы позволить на отдельно взятом компьютере многим процессам одновременно использовать коммуникационные возможности уровня TCP, протокол TCP предоставляет на каждом хост-компьютере набор адресов или портов. Вместе с адресами сетей и хост-компьютеров на коммуникационном уровне Internet они образуют сокет (socket - разъем).
Каждое соединение уникальным образом идентифицируется парой сокетов. Таким образом, любой сокет может одновременно использоваться во многих соединениях.
Соотнесение портов и процессов осуществляется каждым хост- компьютером самостоятельно. Однако оказывается полезным связывать часто используемые процессы (такие как "logger" или сервис с разделением времени) с фиксированными документированными сокетами.
Этот сервис можно впоследствии использовать через известные адреса. Установка и настройка адресов портов для других процессов может включать более динамичные механизмы.
Словарь (TCP)
1822
BBN Report 1822, "The Specification of the Interconnection of a Host and an IMP". Спецификация интерфейса между хост-компьютером и сетью ARPANET.
ACK
Контрольный бит (подтверждения), не занимающий какого-либо места в очереди. Бит информирует о том, что поле подтверждения в данном сегменте определяет номер очереди, который хочет получить программа протокола TCP, пославшая данный сегмент. Это означает подтверждение факта получения всех предшествующих сегментов в очереди.
ARPANET сообщение
Единица посылки между хост-компьютером и IMP в сети ARPANET. Максимальный размер такой единицы около 1012 октетов (8096 бит).
ARPANET пакет
Единица посылки между разными IMP внутри сети ARPANET. Максимальный размер такой единицы около 126 октетов (1008 бит).
Соединение
Логический путь для коммуникаций, определяемый парой сокетов.
Датаграмма
Сообщение, посылаемое через компьютерную коммуникационную систему с коммуникацией пакетов.
Адрес получателя
Адрес получателя это обычно идентификаторы сети и хост-компьютера
FIN
Контрольный бит (конечный), занимающий одно место в очереди и указывающий на то, что программа протокола TCP не будет более посылать данные или какие-либо команды, под которые следует в очереди отводить место.
Фрагмент
Часть логической единицы данных. В частности фрагмент Internet являются частью Internet датаграммы.
FTP
Протокол передачи файлов
Заголовок
Контрольная информация в начале сообщения, сегмента, фрагмента, пакета или блока данных
хост-компьютер
Просто компьютер. В частности, он является отправителем и получателем сообщений с точки зрения коммуникационной сети.
Идентификация
Поле Internet протокола. Значение этого поля назначает отправитель для идентификации с тем, чтобы осуществлять сборку фрагментов датаграммы.
IMP
Процессор интерфейсных сообщений, переключатель пакетов в сети APRANET.
Internet адрес
Адрес отправителя или получателя на уровне хоста
Internet датаграмма
Блок данных, передаваемый между модулем протокола Internet и программой вышестоящего протокола, снабженное Internet заголовком.
Internet фрагменты
Часть данных из Internet датаграммы, которая обзавелась собственным Internet заголовком.
IP
протокол Internet
IRS
Первоначальный номер в очереди получения. Первый номер очереди, который использует программа протокола TCP при посылке данных через соединение.
ISN
Первоначальный номер очереди. Первый номер, используемый соединением (либо ISS либо IRS). Определяется процедурой выбора, использующей таймер.
ISS
Первоначальный номер в очереди посылки. Первый номер очереди, используемый программой протокола TCP при посылке данных через соединение.
leader
Некая контрольная информация в начале сообщения или блока данных. В частности, в сети ARPANET контрольная информация о ARPANET сообщении записана в формате хост-IMP интерфейса.
Остающаяся очередь
Это следующий номер в очереди, который должен быть подтвержден программой TCP, получающей данные (или иначе наименьший номер в очереди, еще не получивший в данный момент своего подтверждения). Иногда на него ссылаются как на левый край окна посылки.
Местный пакет
Блок данных, передаваемый в местной сети
Модуль
Реализация, обычно программа, какого-либо протокола или иной процедуры.
MSL
Максимальное время жизни сегмента. Время, в течении которого TCP сегмент может существовать в системе объединенных сетей. Примерно оценивается в 2 минуты.
Октет
Байт, состоящий из восьми битов
Опции
Поле опций может содержать несколько опций, каждая опция может иметь длину в несколько октетов. В основном, опции используются для тестирования различных ситуаций. Например, опции могут нести временной штамп. Поля с опциями могут иметь оба протокола Internet и TCP.
Пакет
Пакет данных, имеющий заголовок, который в свою очередь может быть логически завершенным, а может и не быть. Чаще это означает физическую упаковку данных, нежели логическую.
Порт
Часть сокета, указывающая логический канал ввода или вывода для процесса, имеющего дело с данными.
Процесс
Некая использующаяся программа. Отправитель или получатель данных с точки зрения протокола TCP или иных фрагментов уровня хост-хост.
PUSH
Контрольный бит, который не требует места в очереди и указывает на то, что данный сегмент содержит данные, которые следует "протолкнуть" к клиенту-адресату.
RCV.NXT
Следующий номер в очереди получения
RCV.UP
Срочный указатель для получения
RCV.WND
Окно получения
Следующий номер в очереди получения
Это следующий номер в очереди, который хочет получить местная программа протокола TCP
Окно получения
Это понятие характеризует номера в очереди, которые должна по лучить местная программа протокола TCP. Таким образом, местная программа TCP считает, что сегменты, попадающие в диапазон от RCV.NXT до RCV.NXT+RCV.WND-1, несут данные и команды управления, которые следует принимать во внимание. Сегменты, чьи номера в очереди ни коим образом не попадают в этот диапазон, воспринимаются как дубликаты и ликвидируются.
RST
Контрольный бит (бит перезагрузки), который не занимает места в очереди и указывает, что получатель этого бита должен ликвидировать соединение без каких-либо дополнительных действий. Получатель может, основываясь на анализе номера очереди и поля подтверждения в сегменте, принесшем данный сегмент, решить, следует ли выполнять операцию перезагрузки или же следует проигнорировать эту команду. Ни в коем случае получатель сегмента с битом RST не должен давать в ответ ту же команду RST.
RTP
Протокол реального времени. Протокол для передачи критической информации между хост-компьютерами.
SEG.ACK
Подтверждение сегмента
SEG.LEN
Длина сегмента
SEG.PRC
Значение приоритета в сегменте
SEG.SEQ
Номер очереди для сегмента
SEG.UP
Поле срочного указателя для сегмента
SEG.WND
Поле окна в сегменте
Сегмент
Логический блок данных. В частности, сегмент TCP является блоком данных, который передается между парой TCP модулей.
Подтверждение сегмента
Номер для очереди в поле подтверждения в пришедшем сегменте
Длина сегмента
Место в очереди, которое занимают данные этого сегмента (с учетом также всех команд, под которые тоже отводится место в очереди).
Номер сегмента в очереди
Значение в поле номера у пришедшего сегмента
Номер в очереди отправления
Следующий номер очереди для местной программы протокола TCP, отправляющей данные и использующей эти номера для управления соединением. Первоначальный номер очереди (ISN) выбирается процедурой инициализации, а затем увеличивается на единицу с передачей по сети каждого октета данных или некоторой команды.
Окно посылки
Окно представляет собой набор номеров из очереди, которые желает получить чужая программа протокола TCP. Информация о границах этого окна берется из сегментов, пришедших от чужой программы TCP, получающей данные. Программе протокола TCP дозволяется посылать данные с номерами от SND.NXT до SND.UNA+SND.WND-1 (конечно, это подразумевает повторную посылку тех данных, чьи номера лежат между SND.UNA и SND.NXT).
SND.NXT
Очередь на посылку
SND.UNA
Очередь еще не посланных данных
SND.UP
Срочный указатель в очереди на посылку
SND.WL1
Номер очереди сегмента в последнем обновленном окне
SND.WL2
Номер подтверждения сегмента в последнем обновленном окне
SND.WND
Окно посылки
Сокет
Адрес, который особым образом включает в себя идентификатор порта. А именно, он включает связь Internet адреса с TCP портом
Адрес отправителя
Адрес отправления, обычно состоящий из идентификаторов сети и хост-компьютера.
SYN
Контрольный бит в приходящем сегменте, который занимает одно место в очереди и используется для инициализации соединения, для указания, где начинается отсчет номеров очереди.
TCB
Контрольный блок для передачи, некая структура данных, где записан статус соединения.
TCB.PRC
Приоритет данного соединения
TCP
Протокол управления пересылкой, протокол для надежной передачи информации между хост-компьютерами в системе объединенных сетей.
TOS
Тип сервиса, поле заголовка в Internet протоколе
Тип сервиса
Поле заголовка в Internet протоколе, которое определяет тип сервиса для данного фрагмента в стандарте Internet.
URG
Контрольный бит (бит срочности), который не требует места в очереди. Этот бит требует, чтобы клиенту был послан приказ использовать ускоренную обработку до тех пор, пока имеются данные, чьи номера в очереди меньше, чем указано в срочном указателе.
Срочный указатель
Срочный указатель имеет значение лишь если установлен бит URG. В поле срочного указателя определяется значение, которое указывает на некий октет данных,. Последний был связан с запросом клиента на срочную пересылку <
Спецификация для функций протокола
| Формат заголовка |
| Терминология |
| Номера последовательности |
| Установка соединения |
| Закрытие соединения |
| Приоритет и безопасность |
| Коммутация данных |
| Интерфейсы |
| Обработка событий |
Ссылки (TCP)
| [1] | Cerf, V., and R. Kahn, "A Protocol for Packet Network Intercommunication", IEEE Transactions on Communications, Vol. COM-22, No. 5, pp 637-648, May 1974. |
| [2] | Postel, J, (ed.) "Internet Protocol DARPA Internet Program Protocol Specification", RFC 791, USC/Information Sciences Institute, September 1981. |
| [3] | Dalal, Y. and C.Sunshine, "Connection Management in Transport Protocols", Computer Networks, Vol. 2, No. 6, pp. 454-473, December 1978. |
| [4] | Posterl, J, "Assigned Numbers", RFC 790, USC/Information Sciences Institute, September 1981. |
| Байты |
Разряды |
|||
7 6 5 4 3 2 1 0 |
7 6 5 4 3 2 1 0 |
7 6 5 4 3 2 1 0 |
7 6 5 4 3 2 1 0 |
|
0 |
Порт источника |
Порт получателя |
||
4 |
Длина протокольного блока |
Проверочная сумма |
||
8 . . |
Данные |
|||
Номера портов источника и получателя определяют прикладной процесс, инициировавший данное соединение. Закрепление номеров портов осуществляется в соответствии с Рекомендацией RFC-1700. Список основных портов приведен здесь.
Связь с другими протоколами
Нижеприведенная диаграмма иллюстрирует место протокола TCP в иерархии протоколов
Рис.2 Взаимосвязь протоколов
Предполагается, что протокол TCP будет в состоянии эффективно поддерживать протоколы более высокого уровня. Протокол TCP должен легко взаимодействовать с такими протоколами более высокого уровня, как ARPANET Telnet или AUDIN II THP to the TCP.
TCP команды клиента
В следующих параграфах функционально характеризуется интерфейс клиент/протокол TCP. Нотация вызова подобна нотации большинства процедур или нотации вызова функции в языках высокого уровня, однако это не означает неправомерность вызовов на обслуживание в виде ловушек (trap) (например SVC, UUO, EMT).
Описанные ниже команды клиента определяют основные операции, которые должна выполнять программа протокола TCP для поддержки коммуникаций между процессами. Отдельные реализации протокола должны определять свой собственный конкретный формат и могут обеспечить комбинации или наборы базовых функций для одиночных вызовов. В частности, некоторые реализации могут автоматически открывать соединение (OPEN), как только по нему клиент дает первую команду посылки (SEND) или получения (RECEIVE).
Для того, чтобы поддерживать интерфейс между процессами, про грамма TCP должна не только принимать команды, но и возвращать некую информацию обслуживаемым процессам. Эта информация состоит из:
| a) | общей информации о соединении (т.е. прерываний, закрытия соединения партнером, управление связью с не предопределенным чужим сокетом). |
| b) | ответа на конкретные команды клиента, указывающего на успешность действий или различные типы ошибок. |
TCP_NZN_PRT
Назначение номеров портов протоколов TCP и UDP
Все значения параметров протоколов используемых в сети Internet определяются оранизацией
IANA (Internet Assigned Numbers Authority). Полный список параметров регулярно издается в
рекомендациях серии RFC. Указанные ниже данные базируются на рекомендации RFC1700.
Порты в протоколах TCP и UDP используются для создания логических соединений, через
которые осуществляется обмен данными. Определенная область номеров портов жестко
закрепляется для идентификации определенных служб, обеспечивая тем самым их
узнаваемость. Данные номера иногда называют - «Узнаваемые порты» ("well-known port").
Диапазон номеров «узнаваемых портов» в настоящее время расширен до 0 – 1024.
Ниже приводится список данных значений.
Keyword Decimal Description References
------- ------- ----------- ----------
0/tcp Reserved
0/udp Reserved
# Jon Postel
tcpmux 1/tcp TCP Port Service Multiplexer
tcpmux 1/udp TCP Port Service Multiplexer
# Mark Lottor
compressnet 2/tcp Management Utility
compressnet 2/udp Management Utility
compressnet 3/tcp Compression Process
compressnet 3/udp Compression Process
# Bernie Volz
# 4/tcp Unassigned
# 4/udp Unassigned
rje 5/tcp Remote Job Entry
rje 5/udp Remote Job Entry
# Jon Postel
# 6/tcp Unassigned
# 6/udp Unassigned
echo 7/tcp Echo
echo 7/udp Echo
# Jon Postel
# 8/tcp Unassigned
# 8/udp Unassigned
discard 9/tcp Discard
discard 9/udp Discard
# Jon Postel
# 10/tcp Unassigned
# 10/udp Unassigned
systat 11/tcp Active Users
systat 11/udp Active Users
# Jon Postel
# 12/tcp Unassigned
# 12/udp Unassigned
daytime 13/tcp Daytime
daytime 13/udp Daytime
# Jon Postel
# 14/tcp Unassigned
# 14/udp Unassigned
# 15/tcp Unassigned [was netstat]
# 15/udp Unassigned
# 16/tcp Unassigned
# 16/udp Unassigned
qotd 17/tcp Quote of the Day
qotd 17/udp Quote of the Day
# Jon Postel
msp 18/tcp Message Send Protocol
msp 18/udp Message Send Protocol
# Rina Nethaniel <---none--->
chargen 19/tcp Character Generator
chargen 19/udp Character Generator
ftp-data 20/tcp File Transfer [Default Data]
ftp-data 20/udp File Transfer [Default Data]
ftp 21/tcp File Transfer [Control]
ftp 21/udp File Transfer [Control]
# Jon Postel
# 22/tcp Unassigned
# 22/udp Unassigned
telnet 23/tcp Telnet
telnet 23/udp Telnet
# Jon Postel
24/ tcp any private mail system
24/udp any private mail system
# Rick Adam
smtp 25/tcp Simple Mail Transfer
smtp 25/udp Simple Mail Transfer
# Jon Postel
# 26/tcp Unassigned
# 26/udp Unassigned
nsw-fe 27/tcp NSW User System FE
nsw-fe 27/udp NSW User System FE
# Robert Thomas
# 28/tcp Unassigned
# 28/udp Unassigned
msg-icp 29/tcp MSG ICP
msg-icp 29/udp MSG ICP
# Robert Thomas
# 30/tcp Unassigned
# 30/udp Unassigned
msg-auth 31/tcp MSG Authentication
msg-auth 31/udp MSG Authentication
# Robert Thomas
# 32/tcp Unassigned
# 32/udp Unassigned
dsp 33/tcp Display Support Protocol
dsp 33/udp Display Support Protocol
# Ed Cain
# 34/tcp Unassigned
# 34/udp Unassigned
35/tcp any private printer server
35/udp any private printer server
# Jon Postel
# 36/tcp Unassigned
# 36/udp Unassigned
time 37/tcp Time
time 37/udp Time
# Jon Postel
rap 38/tcp Route Access Protocol
rap 38/udp Route Access Protocol
# Robert Ullmann
rlp 39/tcp Resource Location Protocol
rlp 39/udp Resource Location Protocol
# Mike Accetta
# 40/tcp Unassigned
# 40/udp Unassigned
graphics 41/tcp Graphics
graphics 41/udp Graphics
nameserver 42/tcp Host Name Server
nameserver 42/udp Host Name Server
nicname 43/tcp Who Is
nicname 43/udp Who Is
mpm-flags 44/tcp MPM FLAGS Protocol
mpm-flags 44/udp MPM FLAGS Protocol
mpm 45/tcp Message Processing Module [recv]
mpm 45/udp Message Processing Module [recv]
mpm-snd 46/tcp MPM [default send]
mpm-snd 46/udp MPM [default send]
# Jon Postel
ni-ftp 47/tcp NI FTP
ni-ftp 47/udp NI FTP
# Steve Kille
auditd 48/tcp Digital Audit Daemon
auditd 48/udp Digital Audit Daemon
# Larry Scott
login 49/tcp Login Host Protocol
login 49/udp Login Host Protocol
# Pieter Ditmars
re-mail-ck 50/ tcp Remote Mail Checking Protocol
re-mail-ck 50/udp Remote Mail Checking Protocol
# Steve Dorner
la-maint 51/tcp IMP Logical Address Maintenance
la-maint 51/udp IMP Logical Address Maintenance
# Andy Malis
xns-time 52/tcp XNS Time Protocol
xns-time 52/udp XNS Time Protocol
# Susie Armstrong
domain 53/tcp Domain Name Server
domain 53/udp Domain Name Server
# Paul Mockapetris
xns-ch 54/tcp XNS Clearinghouse
xns-ch 54/udp XNS Clearinghouse
# Susie Armstrong
isi-gl 55/tcp ISI Graphics Language
isi-gl 55/udp ISI Graphics Language
xns-auth 56/tcp XNS Authentication
xns-auth 56/udp XNS Authentication
# Susie Armstrong
57/tcp any private terminal access
57/udp any private terminal access
# Jon Postel
xns-mail 58/tcp XNS Mail
xns-mail 58/udp XNS Mail
# Susie Armstrong
59/tcp any private file service
59/udp any private file service
# Jon Postel
60/tcp Unassigned
60/udp Unassigned
ni-mail 61/tcp NI MAIL
ni-mail 61/udp NI MAIL
# Steve Kille
acas 62/tcp ACA Services
acas 62/udp ACA Services
# E. Wald
# 63/tcp Unassigned
# 63/udp Unassigned
covia 64/tcp Communications Integrator (CI)
covia 64/udp Communications Integrator (CI)
# "Tundra" Tim Daneliuk
#
tacacs-ds 65/tcp TACACS-Database Service
tacacs-ds 65/udp TACACS-Database Service
# Kathy Huber
sql*net 66/tcp Oracle SQL*NET
sql*net 66/udp Oracle SQL*NET
# Jack Haverty
bootps 67/tcp Bootstrap Protocol Server
bootps 67/udp Bootstrap Protocol Server
bootpc 68/tcp Bootstrap Protocol Client
bootpc 68/udp Bootstrap Protocol Client
# Bill Croft
tftp 69/tcp Trivial File Transfer
tftp 69/udp Trivial File Transfer
# David Clark
gopher 70/tcp Gopher
gopher 70/udp Gopher
# Mark McCahill
netrjs-1 71/tcp Remote Job Service
netrjs-1 71/udp Remote Job Service
netrjs-2 72/tcp Remote Job Service
netrjs-2 72/udp Remote Job Service
netrjs-3 73/tcp Remote Job Service
netrjs-3 73/udp Remote Job Service
netrjs-4 74/tcp Remote Job Service
netrjs-4 74/udp Remote Job Service
# Bob Braden
75/ tcp any private dial out service
75/udp any private dial out service
# Jon Postel
deos 76/tcp Distributed External Object Store
deos 76/udp Distributed External Object Store
# Robert Ullmann
77/tcp any private RJE service
77/udp any private RJE service
# Jon Postel
vettcp 78/tcp vettcp
vettcp 78/udp vettcp
# Christopher Leong
finger 79/tcp Finger
finger 79/udp Finger
# David Zimmerman
www-http 80/tcp World Wide Web HTTP
www-http 80/udp World Wide Web HTTP
# Tim Berners-Lee
hosts2-ns 81/tcp HOSTS2 Name Server
hosts2-ns 81/udp HOSTS2 Name Server
# Earl Killian
xfer 82/tcp XFER Utility
xfer 82/udp XFER Utility
# Thomas M. Smith
mit-ml-dev 83/tcp MIT ML Device
mit-ml-dev 83/udp MIT ML Device
# David Reed <--none--->
ctf 84/tcp Common Trace Facility
ctf 84/udp Common Trace Facility
# Hugh Thomas
mit-ml-dev 85/tcp MIT ML Device
mit-ml-dev 85/udp MIT ML Device
# David Reed <--none--->
mfcobol 86/tcp Micro Focus Cobol
mfcobol 86/udp Micro Focus Cobol
# Simon Edwards <--none--->
87/tcp any private terminal link
87/udp any private terminal link
# Jon Postel
kerberos 88/tcp Kerberos
kerberos 88/udp Kerberos
# B. Clifford Neuman
su-mit-tg 89/tcp SU/MIT Telnet Gateway
su-mit-tg 89/udp SU/MIT Telnet Gateway
# Mark Crispin
dnsix 90/tcp DNSIX Securit Attribute Token Map
dnsix 90/udp DNSIX Securit Attribute Token Map
# Charles Watt
mit-dov 91/tcp MIT Dover Spooler
mit-dov 91/udp MIT Dover Spooler
# Eliot Moss
npp 92/tcp Network Printing Protocol
npp 92/udp Network Printing Protocol
# Louis Mamakos
dcp 93/tcp Device Control Protocol
dcp 93/udp Device Control Protocol
# Daniel Tappan
objcall 94/tcp Tivoli Object Dispatcher
objcall 94/udp Tivoli Object Dispatcher
# Tom Bereiter <--none--->
supdup 95/tcp SUPDUP
supdup 95/udp SUPDUP
# Mark Crispin
dixie 96/tcp DIXIE Protocol Specification
dixie 96/udp DIXIE Protocol Specification
# Tim Howes
swift-rvf 97/ tcp Swift Remote Vitural File Protocol
swift-rvf 97/udp Swift Remote Vitural File Protocol
# Maurice R. Turcotte
#
tacnews 98/tcp TAC News
tacnews 98/udp TAC News
# Jon Postel
metagram 99/tcp Metagram Relay
metagram 99/udp Metagram Relay
# Geoff Goodfellow
newacct 100/tcp [unauthorized use]
hostname 101/tcp NIC Host Name Server
hostname 101/udp NIC Host Name Server
# Jon Postel
iso-tsap 102/tcp ISO-TSAP
iso-tsap 102/udp ISO-TSAP
# Marshall Rose
gppitnp 103/tcp Genesis Point-to-Point Trans Net
gppitnp 103/udp Genesis Point-to-Point Trans Net
acr-nema 104/tcp ACR-NEMA Digital Imag. & Comm. 300
acr-nema 104/udp ACR-NEMA Digital Imag. & Comm. 300
# Patrick McNamee <--none--->
csnet-ns 105/tcp Mailbox Name Nameserver
csnet-ns 105/udp Mailbox Name Nameserver
# Marvin Solomon
3com-tsmux 106/tcp 3COM-TSMUX
3com-tsmux 106/udp 3COM-TSMUX
# Jeremy Siegel
rtelnet 107/tcp Remote Telnet Service
rtelnet 107/udp Remote Telnet Service
# Jon Postel
snagas 108/tcp SNA Gateway Access Server
snagas 108/udp SNA Gateway Access Server
# Kevin Murphy
pop2 109/tcp Post Office Protocol - Version 2
pop2 109/udp Post Office Protocol - Version 2
# Joyce K. Reynolds
pop3 110/tcp Post Office Protocol - Version 3
pop3 110/udp Post Office Protocol - Version 3
# Marshall Rose
sunrpc 111/tcp SUN Remote Procedure Call
sunrpc 111/udp SUN Remote Procedure Call
# Chuck McManis
mcidas 112/tcp McIDAS Data Transmission Protocol
mcidas 112/udp McIDAS Data Transmission Protocol
# Glenn Davis
auth 113/tcp Authentication Service
auth 113/udp Authentication Service
# Mike St. Johns
audionews 114/tcp Audio News Multicast
audionews 114/udp Audio News Multicast
# Martin Forssen
sftp 115/tcp Simple File Transfer Protocol
sftp 115/udp Simple File Transfer Protocol
# Mark Lottor
ansanotify 116/tcp ANSA REX Notify
ansanotify 116/udp ANSA REX Notify
# Nicola J. Howarth
uucp-path 117/tcp UUCP Path Service
uucp-path 117/udp UUCP Path Service
sqlserv 118/tcp SQL Services
sqlserv 118/udp SQL Services
# Larry Barnes
nntp 119/ tcp Network News Transfer Protocol
nntp 119/udp Network News Transfer Protocol
# Phil Lapsley
cfdptkt 120/tcp CFDPTKT
cfdptkt 120/udp CFDPTKT
# John Ioannidis
erpc 121/tcp Encore Expedited Remote Pro.Call
erpc 121/udp Encore Expedited Remote Pro.Call
# Jack O'Neil <---none--->
smakynet 122/tcp SMAKYNET
smakynet 122/udp SMAKYNET
# Mike O'Dowd
ntp 123/tcp Network Time Protocol
ntp 123/udp Network Time Protocol
# Dave Mills
ansatrader 124/tcp ANSA REX Trader
ansatrader 124/udp ANSA REX Trader
# Nicola J. Howarth
locus-map 125/tcp Locus PC-Interface Net Map Ser
locus-map 125/udp Locus PC-Interface Net Map Ser
# Eric Peterson
unitary 126/tcp Unisys Unitary Login
unitary 126/udp Unisys Unitary Login
#
locus-con 127/tcp Locus PC-Interface Conn Server
locus-con 127/udp Locus PC-Interface Conn Server
# Eric Peterson
gss-xlicen 128/tcp GSS X License Verification
gss-xlicen 128/udp GSS X License Verification
# John Light
pwdgen 129/tcp Password Generator Protocol
pwdgen 129/udp Password Generator Protocol
# Frank J. Wacho
cisco-fna 130/tcp cisco FNATIVE
cisco-fna 130/udp cisco FNATIVE
cisco-tna 131/tcp cisco TNATIVE
cisco-tna 131/udp cisco TNATIVE
cisco-sys 132/tcp cisco SYSMAINT
cisco-sys 132/udp cisco SYSMAINT
statsrv 133/tcp Statistics Service
statsrv 133/udp Statistics Service
# Dave Mills
ingres-net 134/tcp INGRES-NET Service
ingres-net 134/udp INGRES-NET Service
# Mike Berrow <---none--->
loc-srv 135/tcp Location Service
loc-srv 135/udp Location Service
# Joe Pato
profile 136/tcp PROFILE Naming System
profile 136/udp PROFILE Naming System
# Larry Peterson
netbios-ns 137/tcp NETBIOS Name Service
netbios-ns 137/udp NETBIOS Name Service
netbios-dgm 138/tcp NETBIOS Datagram Service
netbios-dgm 138/udp NETBIOS Datagram Service
netbios-ssn 139/tcp NETBIOS Session Service
netbios-ssn 139/udp NETBIOS Session Service
# Jon Postel
emfis-data 140/tcp EMFIS Data Service
emfis-data 140/udp EMFIS Data Service
emfis-cntl 141/tcp EMFIS Control Service
emfis-cntl 141/udp EMFIS Control Service
# Gerd Beling
bl-idm 142/tcp Britton-Lee IDM
bl-idm 142/udp Britton-Lee IDM
# Susie Snitzer <---none--->
imap2 143/ tcp Interim Mail Access Protocol v2
imap2 143/udp Interim Mail Access Protocol v2
# Mark Crispin
news 144/tcp NewS
news 144/udp NewS
# James Gosling
uaac 145/tcp UAAC Protocol
uaac 145/udp UAAC Protocol
# David A. Gomberg
iso-tp0 146/tcp ISO-IP0
iso-tp0 146/udp ISO-IP0
iso-ip 147/tcp ISO-IP
iso-ip 147/udp ISO-IP
# Marshall Rose
cronus 148/tcp CRONUS-SUPPORT
cronus 148/udp CRONUS-SUPPORT
# Jeffrey Buffun
aed-512 149/tcp AED 512 Emulation Service
aed-512 149/udp AED 512 Emulation Service
# Albert G. Broscius
sql-net 150/tcp SQL-NET
sql-net 150/udp SQL-NET
# Martin Picard <<---none--->
hems 151/tcp HEMS
hems 151/udp HEMS
# Christopher Tengi
bftp 152/tcp Background File Transfer Program
bftp 152/udp Background File Transfer Program
# Annette DeSchon
sgmp 153/tcp SGMP
sgmp 153/udp SGMP
# Marty Schoffstahl
netsc-prod 154/tcp NETSC
netsc-prod 154/udp NETSC
netsc-dev 155/tcp NETSC
netsc-dev 155/udp NETSC
# Sergio Heker
sqlsrv 156/tcp SQL Service
sqlsrv 156/udp SQL Service
# Craig Rogers
knet-cmp 157/tcp KNET/VM Command/Message Protocol
knet-cmp 157/udp KNET/VM Command/Message Protocol
# Gary S. Malkin
pcmail-srv 158/tcp PCMail Server
pcmail-srv 158/udp PCMail Server
# Mark L. Lambert
nss-routing 159/tcp NSS-Routing
nss-routing 159/udp NSS-Routing
# Yakov Rekhter
sgmp-traps 160/tcp SGMP-TRAPS
sgmp-traps 160/udp SGMP-TRAPS
# Marty Schoffstahl
snmp 161/tcp SNMP
snmp 161/udp SNMP
snmptrap 162/tcp SNMPTRAP
snmptrap 162/udp SNMPTRAP
# Marshall Rose
cmip-man 163/tcp CMIP/TCP Manager
cmip-man 163/udp CMIP/TCP Manager
cmip-agent 164/tcp CMIP/TCP Agent
smip-agent 164/udp CMIP/TCP Agent
# Amatzia Ben-Artzi <---none--->
xns-courier 165/tcp Xerox
xns-courier 165/udp Xerox
# Susie Armstrong
s-net 166/tcp Sirius Systems
s-net 166/udp Sirius Systems
# Brian Lloyd <---none--->
namp 167/tcp NAMP
namp 167/udp NAMP
# Marty Schoffstahl
rsvd 168/tcp RSVD
rsvd 168/udp RSVD
# Neil Todd
send 169/tcp SEND
send 169/udp SEND
# William D. Wisner
print-srv 170/tcp Network PostScript
print-srv 170/udp Network PostScript
# Brian Reid
multiplex 171/tcp Network Innovations Multiplex
multiplex 171/udp Network Innovations Multiplex
cl/1 172/tcp Network Innovations CL/1
cl/1 172/udp Network Innovations CL/1
# Kevin DeVault <<---none--->
xyplex-mux 173/tcp Xyplex
xyplex-mux 173/udp Xyplex
# Bob Stewart
mailq 174/tcp MAILQ
mailq 174/udp MAILQ
# Rayan Zachariassen
vmnet 175/tcp VMNET
vmnet 175/udp VMNET
# Christopher Tengi
genrad-mux 176/tcp GENRAD-MUX
genrad-mux 176/udp GENRAD-MUX
# Ron Thornton
xdmcp 177/tcp X Display Manager Control Protocol
xdmcp 177/udp X Display Manager Control Protocol
# Robert W. Scheifler
nextstep 178/tcp NextStep Window Server
NextStep 178/udp NextStep Window Server
# Leo Hourvitz
bgp 179/tcp Border Gateway Protocol
bgp 179/udp Border Gateway Protocol
# Kirk Lougheed
ris 180/tcp Intergraph
ris 180/udp Intergraph
# Dave Buehmann
unify 181/tcp Unify
unify 181/udp Unify
# Vinod Singh <--none--->
audit 182/tcp Unisys Audit SITP
audit 182/udp Unisys Audit SITP
# Gil Greenbaum
ocbinder 183/tcp OCBinder
ocbinder 183/udp OCBinder
ocserver 184/tcp OCServer
ocserver 184/udp OCServer
# Jerrilynn Okamura <--none--->
remote-kis 185/tcp Remote-KIS
remote-kis 185/udp Remote-KIS
kis 186/tcp KIS Protocol
kis 186/udp KIS Protocol
# Ralph Droms
aci 187/tcp Application Communication Interface
aci 187/udp Application Communication Interface
# Rick Carlos
mumps 188/tcp Plus Five's MUMPS
mumps 188/udp Plus Five's MUMPS
# Hokey Stenn
qft 189/tcp Queued File Transport
qft 189/udp Queued File Transport
# Wayne Schroeder
gacp 190/tcp Gateway Access Control Protocol
cacp 190/udp Gateway Access Control Protocol
# C. Philip Wood
prospero 191/tcp Prospero Directory Service
prospero 191/udp Prospero Directory Service
# B. Clifford Neuman
osu-nms 192/tcp OSU Network Monitoring System
osu-nms 192/udp OSU Network Monitoring System
# Doug Karl
srmp 193/tcp Spider Remote Monitoring Protocol
srmp 193/udp Spider Remote Monitoring Protocol
# Ted J. Socolofsky
irc 194/tcp Internet Relay Chat Protocol
irc 194/udp Internet Relay Chat Protocol
# Jarkko Oikarinen
dn6-nlm-aud 195/ tcp DNSIX Network Level Module Audit
dn6-nlm-aud 195/udp DNSIX Network Level Module Audit
dn6-smm-red 196/tcp DNSIX Session Mgt Module Audit Redir
dn6-smm-red 196/udp DNSIX Session Mgt Module Audit Redir
# Lawrence Lebahn
dls 197/tcp Directory Location Service
dls 197/udp Directory Location Service
dls-mon 198/tcp Directory Location Service Monitor
dls-mon 198/udp Directory Location Service Monitor
# Scott Bellew
smux 199/tcp SMUX
smux 199/udp SMUX
# Marshall Rose
src 200/tcp IBM System Resource Controller
src 200/udp IBM System Resource Controller
# Gerald McBrearty <---none--->
at-rtmp 201/tcp AppleTalk Routing Maintenance
at-rtmp 201/udp AppleTalk Routing Maintenance
at-nbp 202/tcp AppleTalk Name Binding
at-nbp 202/udp AppleTalk Name Binding
at-3 203/tcp AppleTalk Unused
at-3 203/udp AppleTalk Unused
at-echo 204/tcp AppleTalk Echo
at-echo 204/udp AppleTalk Echo
at-5 205/tcp AppleTalk Unused
at-5 205/udp AppleTalk Unused
at-zis 206/tcp AppleTalk Zone Information
at-zis 206/udp AppleTalk Zone Information
at-7 207/tcp AppleTalk Unused
at-7 207/udp AppleTalk Unused
at-8 208/tcp AppleTalk Unused
at-8 208/udp AppleTalk Unused
# Rob Chandhok
tam 209/tcp Trivial Authenticated Mail Protocol
tam 209/udp Trivial Authenticated Mail Protocol
# Dan Bernstein
z39.50 210/tcp ANSI Z39.50
z39.50 210/udp ANSI Z39.50
# Mark Needleman
#
914c/g 211/tcp Texas Instruments 914C/G Terminal
914c/g 211/udp Texas Instruments 914C/G Terminal
# Bill Harrell <---none--->
anet 212/tcp ATEXSSTR
anet 212/udp ATEXSSTR
# Jim Taylor
ipx 213/tcp IPX
ipx 213/udp IPX
# Don Provan
vmpwscs 214/tcp VM PWSCS
vmpwscs 214/udp VM PWSCS
# Dan Shia
softpc 215/tcp Insignia Solutions
softpc 215/udp Insignia Solutions
# Martyn Thomas <---none--->
atls 216/tcp Access Technology License Server
atls 216/udp Access Technology License Server
# Larry DeLuca
dbase 217/tcp dBASE Unix
dbase 217/udp dBASE Unix
# Don Gibson
#
mpp 218/tcp Netix Message Posting Protocol
mpp 218/udp Netix Message Posting Protocol
# Shannon Yeh
uarps 219/tcp Unisys ARPs
uarps 219/udp Unisys ARPs
# Ashok Marwaha <---none--->
imap3 220/ tcp Interactive Mail Access Protocol v3
imap3 220/udp Interactive Mail Access Protocol v3
# James Rice
fln-spx 221/tcp Berkeley rlogind with SPX auth
fln-spx 221/udp Berkeley rlogind with SPX auth
rsh-spx 222/tcp Berkeley rshd with SPX auth
rsh-spx 222/udp Berkeley rshd with SPX auth
cdc 223/tcp Certificate Distribution Center
cdc 223/udp Certificate Distribution Center
# Kannan Alagappan
# 224-241 Reserved
# Jon Postel
# 242/tcp Unassigned
# 242/udp Unassigned
sur-meas 243/tcp Survey Measurement
sur-meas 243/udp Survey Measurement
# Dave Clark
# 244/tcp Unassigned
# 244/udp Unassigned
link 245/tcp LINK
link 245/udp LINK
dsp3270 246/tcp Display Systems Protocol
dsp3270 246/udp Display Systems Protocol
# Weldon J. Showalter
# 247-255 Reserved
# Jon Postel
# 256-343 Unassigned
pdap 344/tcp Prospero Data Access Protocol
pdap 344/udp Prospero Data Access Protocol
# B. Clifford Neuman
pawserv 345/tcp Perf Analysis Workbench
pawserv 345/udp Perf Analysis Workbench
zserv 346/tcp Zebra server
zserv 346/udp Zebra server
fatserv 347/tcp Fatmen Server
fatserv 347/udp Fatmen Server
csi-sgwp 348/tcp Cabletron Management Protocol
csi-sgwp 348/udp Cabletron Management Protocol
# 349-370 Unassigned
clearcase 371/tcp Clearcase
clearcase 371/udp Clearcase
# Dave LeBlang
ulistserv 372/tcp Unix Listserv
ulistserv 372/udp Unix Listserv
# Anastasios Kotsikonas
legent-1 373/tcp Legent Corporation
legent-1 373/udp Legent Corporation
legent-2 374/tcp Legent Corporation
legent-2 374/udp Legent Corporation
# Keith Boyce <---none--->
hassle 375/tcp Hassle
hassle 375/udp Hassle
# Reinhard Doelz
nip 376/ tcp Amiga Envoy Network Inquiry Proto
nip 376/udp Amiga Envoy Network Inquiry Proto
# Kenneth Dyke
tnETOS 377/tcp NEC Corporation
tnETOS 377/udp NEC Corporation
dsETOS 378/tcp NEC Corporation
dsETOS 378/udp NEC Corporation
# Tomoo Fujita
is99c 379/tcp TIA/EIA/IS-99 modem client
is99c 379/udp TIA/EIA/IS-99 modem client
is99s 380/tcp TIA/EIA/IS-99 modem server
is99s 380/udp TIA/EIA/IS-99 modem server
# Frank Quick
hp-collector 381/tcp hp performance data collector
hp-collector 381/udp hp performance data collector
hp-managed-node 382/tcp hp performance data managed node
hp-managed-node 382/udp hp performance data managed node
hp-alarm-mgr 383/tcp hp performance data alarm manager
hp-alarm-mgr 383/udp hp performance data alarm manager
# Frank Blakely
arns 384/tcp A Remote Network Server System
arns 384/udp A Remote Network Server System
# David Hornsby
ibm-app 385/tcp IBM Application
ibm-app 385/tcp IBM Application
# Lisa Tomita <---none--->
asa 386/tcp ASA Message Router Object Def.
asa 386/udp ASA Message Router Object Def.
# Steve Laitinen
aurp 387/tcp Appletalk Update-Based Routing Pro.
aurp 387/udp Appletalk Update-Based Routing Pro.
# Chris Ranch
unidata-ldm 388/tcp Unidata LDM Version 4
unidata-ldm 388/udp Unidata LDM Version 4
# Glenn Davis
ldap 389/tcp Lightweight Directory Access Protocol
ldap 389/udp Lightweight Directory Access Protocol
# Tim Howes
uis 390/tcp UIS
uis 390/udp UIS
# Ed Barron <---none--->
synotics-relay 391/tcp SynOptics SNMP Relay Port
synotics-relay 391/udp SynOptics SNMP Relay Port
synotics-broker 392/tcp SynOptics Port Broker Port
synotics-broker 392/udp SynOptics Port Broker Port
# Illan Raab
dis 393/tcp Data Interpretation System
dis 393/udp Data Interpretation System
# Paul Stevens
embl-ndt 394/tcp EMBL Nucleic Data Transfer
embl-ndt 394/udp EMBL Nucleic Data Transfer
# Peter Gad
netcp 395/tcp NETscout Control Protocol
netcp 395/udp NETscout Control Protocol
# Anil Singhal <---none--->
netware-ip 396/tcp Novell Netware over IP
netware-ip 396/udp Novell Netware over IP
mptn 397/tcp Multi Protocol Trans. Net.
mptn 397/udp Multi Protocol Trans. Net.
# Soumitra Sarkar
kryptolan 398/tcp Kryptolan
kryptolan 398/udp Kryptolan
# Peter de Laval
# 399/tcp Unassigned
# 399/udp Unassigned
work-sol 400/tcp Workstation Solutions
work-sol 400/udp Workstation Solutions
# Jim Ward
ups 401/tcp Uninterruptible Power Supply
ups 401/udp Uninterruptible Power Supply
# Guenther Seybold
genie 402/tcp Genie Protocol
genie 402/udp Genie Protocol
# Mark Hankin <---none--->
decap 403/tcp decap
decap 403/udp decap
nced 404/tcp nced
nced 404/udp nced
ncld 405/tcp ncld
ncld 405/udp ncld
# Richard Jones <---none--->
imsp 406/tcp Interactive Mail Support Protocol
imsp 406/udp Interactive Mail Support Protocol
# John Myers
timbuktu 407/tcp Timbuktu
timbuktu 407/udp Timbuktu
# Marc Epard
prm-sm 408/ tcp Prospero Resource Manager Sys. Man.
prm-sm 408/udp Prospero Resource Manager Sys. Man.
prm-nm 409/tcp Prospero Resource Manager Node Man.
prm-nm 409/udp Prospero Resource Manager Node Man.
# B. Clifford Neuman
decladebug 410/tcp DECLadebug Remote Debug Protocol
decladebug 410/udp DECLadebug Remote Debug Protocol
# Anthony Berent
rmt 411/tcp Remote MT Protocol
rmt 411/udp Remote MT Protocol
# Peter Eriksson
synoptics-trap 412/tcp Trap Convention Port
synoptics-trap 412/udp Trap Convention Port
# Illan Raab
smsp 413/tcp SMSP
smsp 413/udp SMSP
infoseek 414/tcp InfoSeek
infoseek 414/udp InfoSeek
# Steve Kirsch
bnet 415/tcp BNet
bnet 415/udp BNet
# Jim Mertz
silverplatter 416/tcp Silverplatter
silverplatter 416/udp Silverplatter
# Peter Ciuffetti
onmux 417/tcp Onmux
onmux 417/udp Onmux
# Stephen Hanna
hyper-g 418/tcp Hyper-G
hyper-g 418/udp Hyper-G
# Frank Kappe
ariel1 419/tcp Ariel
ariel1 419/udp Ariel
# Jonathan Lavigne
smpte 420/tcp SMPTE
smpte 420/udp SMPTE
# Si Becker <71362.22@CompuServe.COM>
ariel2 421/tcp Ariel
ariel2 421/udp Ariel
ariel3 422/tcp Ariel
ariel3 422/udp Ariel
# Jonathan Lavigne
opc-job-start 423/ tcp IBM Operations Planning and Control Start
opc-job-start 423/udp IBM Operations Planning and Control Start
opc-job-track 424/tcp IBM Operations Planning and Control Track
opc-job-track 424/udp IBM Operations Planning and Control Track
# Conny Larsson
icad-el 425/tcp ICAD
icad-el 425/udp ICAD
# Larry Stone
smartsdp 426/tcp smartsdp
smartsdp 426/udp smartsdp
# Alexander Dupuy
svrloc 427/tcp Server Location
svrloc 427/udp Server Location
#
ocs_cmu 428/tcp OCS_CMU
ocs_cmu 428/udp OCS_CMU
ocs_amu 429/tcp OCS_AMU
ocs_amu 429/udp OCS_AMU
# Florence Wyman
utmpsd 430/tcp UTMPSD
utmpsd 430/udp UTMPSD
utmpcd 431/tcp UTMPCD
utmpcd 431/udp UTMPCD
iasd 432/tcp IASD
iasd 432/udp IASD
# Nir Baroz
nnsp 433/tcp NNSP
nnsp 433/udp NNSP
# Rob Robertson
mobileip-agent 434/tcp MobileIP-Agent
mobileip-agent 434/udp MobileIP-Agent
mobilip-mn 435/tcp MobilIP-MN
mobilip-mn 435/udp MobilIP-MN
# Kannan Alagappan
dna-cml 436/tcp DNA-CML
dna-cml 436/udp DNA-CML
# Dan Flowers
comscm 437/tcp comscm
comscm 437/udp comscm
# Jim Teague
dsfgw 438/tcp dsfgw
dsfgw 438/udp dsfgw
# Andy McKeen
dasp 439/tcp dasp Thomas Obermair
dasp 439/udp dasp tommy@inlab.m.eunet.de
# Thomas Obermair
sgcp 440/tcp sgcp
sgcp 440/udp sgcp
# Marshall Rose
decvms-sysmgt 441/tcp decvms-sysmgt
decvms-sysmgt 441/udp decvms-sysmgt
# Lee Barton
cvc_hostd 442/tcp cvc_hostd
cvc_hostd 442/udp cvc_hostd
# Bill Davidson
https 443/tcp https MCom
https 443/udp https MCom
# Kipp E.B. Hickman
snpp 444/tcp Simple Network Paging Protocol
snpp 444/udp Simple Network Paging Protocol
# [RFC1568]
microsoft-ds 445/tcp Microsoft-DS
microsoft-ds 445/udp Microsoft-DS
# Arnold Miller
ddm-rdb 446/tcp DDM-RDB
ddm-rdb 446/udp DDM-RDB
ddm-dfm 447/tcp DDM-RFM
ddm-dfm 447/udp DDM-RFM
ddm-byte 448/tcp DDM-BYTE
ddm-byte 448/udp DDM-BYTE
# Jan David Fisher
as-servermap 449/tcp AS Server Mapper
as-servermap 449/udp AS Server Mapper
# Barbara Foss
tserver 450/tcp TServer
tserver 450/udp TServer
# Harvey S. Schultz
# 451-511 Unassigned
exec 512/tcp remote process execution;
# authentication performed using
# passwords and UNIX loppgin names
biff 512/ udp used by mail system to notify users
# of new mail received; currently
# receives messages only from
# processes on the same machine
login 513/tcp remote login a la telnet;
# automatic authentication performed
# based on priviledged port numbers
# and distributed data bases which
# identify "authentication domains"
who 513/udp maintains data bases showing who's
# logged in to machines on a local
# net and the load average of the
# machine
cmd 514/tcp like exec, but automatic
# authentication is performed as for
# login server
syslog 514/udp
printer 515/tcp spooler
printer 515/udp spooler
# 516/tcp Unassigned
# 516/udp Unassigned
talk 517/tcp like tenex link, but across
# machine - unfortunately, doesn't
# use link protocol (this is actually
# just a rendezvous port from which a
# tcp connection is established)
talk 517/udp like tenex link, but across
# machine - unfortunately, doesn't
# use link protocol (this is actually
# just a rendezvous port from which a
tcp connection is established)
ntalk 518/tcp
ntalk 518/udp
utime 519/tcp unixtime
utime 519/udp unixtime
efs 520/tcp extended file name server
router 520/udp local routing process (on site);
# uses variant of Xerox NS routing
# information protocol
# 521-524 Unassigned
timed 525/tcp timeserver
timed 525/udp timeserver
tempo 526/tcp newdate
tempo 526/udp newdate
# 527-529 Unassigned
courier 530/tcp rpc
courier 530/udp rpc
conference 531/tcp chat
conference 531/udp chat
netnews 532/tcp readnews
netnews 532/udp readnews
netwall 533/tcp for emergency broadcasts
netwall 533/udp for emergency broadcasts
# 534-538 Unassigned
apertus-ldp 539/ tcp Apertus Technologies Load Determination
apertus-ldp 539/udp Apertus Technologies Load Determination
uucp 540/tcp uucpd
uucp 540/udp uucpd
uucp-rlogin 541/tcp uucp-rlogin Stuart Lynne
uucp-rlogin 541/udp uucp-rlogin sl@wimsey.com
# 542/tcp Unassigned
# 542/udp Unassigned
klogin 543/tcp
klogin 543/udp
kshell 544/tcp krcmd
kshell 544/udp krcmd
# 545-549 Unassigned
new-rwho 550/tcp new-who
new-rwho 550/udp new-who
# 551-555 Unassigned
dsf 555/tcp
dsf 555/udp
remotefs 556/tcp rfs server
remotefs 556/udp rfs server
# 557-559 Unassigned
rmonitor 560/tcp rmonitord
rmonitor 560/udp rmonitord
monitor 561/tcp
monitor 561/udp
chshell 562/tcp chcmd
chshell 562/udp chcmd
# 563/tcp Unassigned
# 563/udp Unassigned
9pfs 564/tcp plan 9 file service
9pfs 564/udp plan 9 file service
whoami 565/tcp whoami
whoami 565/udp whoami
# 566-569 Unassigned
meter 570/tcp demon
meter 570/udp demon
meter 571/tcp udemon
meter 571/udp udemon
# 572-599 Unassigned
ipcserver 600/tcp Sun IPC server
ipcserver 600/udp Sun IPC server
nqs 607/tcp nqs
nqs 607/udp nqs
urm 606/tcp Cray Unified Resource Manager
urm 606/udp Cray Unified Resource Manager
# Bill Schiefelbein
sift-uft 608/tcp Sender-Initiated/Unsolicited File Transfer
sift-uft 608/udp Sender-Initiated/Unsolicited File Transfer
# Rick Troth
npmp-trap 609/tcp npmp-trap
npmp-trap 609/udp npmp-trap
npmp-local 610/tcp npmp-local
npmp-local 610/udp npmp-local
npmp-gui 611/tcp npmp-gui
npmp-gui 611/udp npmp-gui
# John Barnes
ginad 634/tcp ginad
ginad 634/udp ginad
# Mark Crother
mdqs 666/tcp
mdqs 666/udp
doom 666/tcp doom Id Software
doom 666/tcp doom Id Software
#
elcsd 704/tcp errlog copy/server daemon
elcsd 704/udp errlog copy/server daemon
entrustmanager 709/tcp EntrustManager
entrustmanager 709/udp EntrustManager
# Peter Whittaker
netviewdm1 729/tcp IBM NetView DM/6000 Server/Client
netviewdm1 729/udp IBM NetView DM/6000 Server/Client
netviewdm2 730/tcp IBM NetView DM/6000 send/tcp
netviewdm2 730/udp IBM NetView DM/6000 send/tcp
netviewdm3 731/tcp IBM NetView DM/6000 receive/tcp
netviewdm3 731/udp IBM NetView DM/6000 receive/tcp
# Philippe Binet (phbinet@vnet.IBM.COM)
netgw 741/tcp netGW
netgw 741/udp netGW
netrcs 742/ tcp Network based Rev. Cont. Sys.
netrcs 742/udp Network based Rev. Cont. Sys.
# Gordon C. Galligher
flexlm 744/tcp Flexible License Manager
flexlm 744/udp Flexible License Manager
# Matt Christiano
#
fujitsu-dev 747/tcp Fujitsu Device Control
fujitsu-dev 747/udp Fujitsu Device Control
ris-cm 748/tcp Russell Info Sci Calendar Manager
ris-cm 748/udp Russell Info Sci Calendar Manager
kerberos-adm 749/tcp kerberos administration
kerberos-adm 749/udp kerberos administration
rfile 750/tcp
loadav 750/udp
pump 751/tcp
pump 751/udp
qrh 752/tcp
qrh 752/udp
rrh 753/tcp
rrh 753/udp
tell 754/tcp send
tell 754/udp send
nlogin 758/tcp
nlogin 758/udp
con 759/tcp
con 759/udp
ns 760/tcp
ns 760/udp
rxe 761/tcp
rxe 761/udp
quotad 762/tcp
quotad 762/udp
cycleserv 763/tcp
cycleserv 763/udp
omserv 764/tcp
omserv 764/udp
webster 765/tcp
webster 765/udp
phonebook 767/tcp phone
phonebook 767/udp phone
vid 769/tcp
vid 769/udp
cadlock 770/tcp
cadlock 770/udp
rtip 771/tcp
rtip 771/udp
cycleserv2 772/tcp
cycleserv2 772/udp
submit 773/tcp
notify 773/udp
rpasswd 774/tcp
acmaint_dbd 774/udp
entomb 775/tcp
acmaint_transd 775/udp
wpages 776/tcp
wpages 776/udp
wpgs 780/tcp
wpgs 780/udp
concert 786/tcp Concert
concert 786/udp Concert
# Josyula R. Rao
mdbs_daemon 800/tcp
mdbs_daemon 800/udp
device 801/tcp
device 801/udp
xtreelic 996/tcp Central Point Software
xtreelic 996/udp Central Point Software
# Dale Cabell
maitrd 997/tcp
maitrd 997/udp
busboy 998/tcp
puparp 998/udp
garcon 999/tcp
applix 999/udp Applix ac
puprouter 999/tcp
puprouter 999/udp
cadlock 1000/tcp
ock 1000/udp
1023/tcp Reserved
1024/udp Reserved
# IANA
Кроме номеров портов управляемых IANA существуют номера зарегестрированных портов, со
значениями выше 1024, которые зарегестрированны для использования в сети для
идентификации различных служб простых прльзователей. Значения данных номеров не
контролируются организацией IANA.
The Registered Ports are in the range 1024-65535.
Port Assignments:
Keyword Decimal Description References
------- ------- ----------- ----------
1024/tcp Reserved
1024/udp Reserved
# IANA
blackjack 1025/tcp network blackjack
blackjack 1025/udp network blackjack
iad1 1030/tcp BBN IAD
iad1 1030/udp BBN IAD
iad2 1031/tcp BBN IAD
iad2 1031/udp BBN IAD
iad3 1032/tcp BBN IAD
iad3 1032/udp BBN IAD
# Andy Malis
instl_boots 1067/tcp Installation Bootstrap Proto. Serv.
instl_boots 1067/udp Installation Bootstrap Proto. Serv.
instl_bootc 1068/tcp Installation Bootstrap Proto. Cli.
instl_bootc 1068/udp Installation Bootstrap Proto. Cli.
# David Arko <
socks 1080/tcp Socks
socks 1080/udp Socks
# Ying-Da Lee
nerv 1222/tcp SNI R&D network
nerv 1222/udp SNI R&D network
# Martin Freiss
hermes 1248/tcp
hermes 1248/udp
alta-ana-lm 1346/tcp Alta Analytics License Manager
alta-ana-lm 1346/udp Alta Analytics License Manager
bbn-mmc 1347/tcp multi media conferencing
bbn-mmc 1347/udp multi media conferencing
bbn-mmx 1348/tcp multi media conferencing
bbn-mmx 1348/udp multi media conferencing
sbook 1349/tcp Registration Network Protocol
sbook 1349/udp Registration Network Protocol
editbench 1350/tcp Registration Network Protocol
editbench 1350/udp Registration Network Protocol
# Simson L. Garfinkel
equationbuilder 1351/tcp Digital Tool Works (MIT)
equationbuilder 1351/udp Digital Tool Works (MIT)
# Terrence J. Talbot
lotusnote 1352/tcp Lotus Note
lotusnote 1352/udp Lotus Note
# Greg Pflaum
relief 1353/tcp Relief Consulting
relief 1353/udp Relief Consulting
# John Feiler
rightbrain 1354/tcp RightBrain Software
rightbrain 1354/udp RightBrain Software
# Glenn Reid
intuitive edge 1355/tcp Intuitive Edge
intuitive edge 1355/udp Intuitive Edge
# Montgomery Zukowski
#
cuillamartin 1356/tcp CuillaMartin Company
cuillamartin 1356/udp CuillaMartin Company
pegboard 1357/tcp Electronic PegBoard
pegboard 1357/udp Electronic PegBoard
# Chris Cuilla
#
connlcli 1358/tcp CONNLCLI
connlcli 1358/udp CONNLCLI
ftsrv 1359/tcp FTSRV
ftsrv 1359/udp FTSRV
# Ines Homem de Melo
mimer 1360/tcp MIMER
mimer 1360/udp MIMER
# Per Schroeder
linx 1361/tcp LinX
linx 1361/udp LinX
# Steffen Schilke <---none--->
timeflies 1362/tcp TimeFlies
timeflies 1362/udp TimeFlies
# Doug Kent
ndm-requester 1363/tcp Network DataMover Requester
ndm-requester 1363/udp Network DataMover Requester
ndm-server 1364/tcp Network DataMover Server
ndm-server 1364/udp Network DataMover Server
# Toshio Watanabe
#
adapt-sna 1365/tcp Network Software Associates
adapt-sna 1365/udp Network Software Associates
# Jeffery Chiao <714-768-401>
netware-csp 1366/ tcp Novell NetWare Comm Service Platform
netware-csp 1366/udp Novell NetWare Comm Service Platform
# Laurie Lindsey
dcs 1367/tcp DCS
dcs 1367/udp DCS
# Stefan Siebert
screencast 1368/tcp ScreenCast
screencast 1368/udp ScreenCast
# Bill Tschumy
gv-us 1369/tcp GlobalView to Unix Shell
gv-us 1369/udp GlobalView to Unix Shell
us-gv 1370/tcp Unix Shell to GlobalView
us-gv 1370/udp Unix Shell to GlobalView
# Makoto Mita
fc-cli 1371/tcp Fujitsu Config Protocol
fc-cli 1371/udp Fujitsu Config Protocol
fc-ser 1372/tcp Fujitsu Config Protocol
fc-ser 1372/udp Fujitsu Config Protocol
# Ryuichi Horie
chromagrafx 1373/tcp Chromagrafx
chromagrafx 1373/udp Chromagrafx
# Mike Barthelemy
molly 1374/tcp EPI Software Systems
molly 1374/udp EPI Software Systems
# Jim Vlcek
bytex 1375/tcp Bytex
bytex 1375/udp Bytex
# Mary Ann Burt
ibm-pps 1376/tcp IBM Person to Person Software
ibm-pps 1376/ udp IBM Person to Person Software
# Simon Phipps
cichlid 1377/tcp Cichlid License Manager
cichlid 1377/udp Cichlid License Manager
# Andy Burgess
elan 1378/tcp Elan License Manager
elan 1378/udp Elan License Manager
# Ken Greer
dbreporter 1379/tcp Integrity Solutions
dbreporter 1379/udp Integrity Solutions
# Tim Dawson
telesis-licman 1380/tcp Telesis Network License Manager
telesis-licman 1380/udp Telesis Network License Manager
# Karl Schendel, Jr.
apple-licman 1381/tcp Apple Network License Manager
apple-licman 1381/udp Apple Network License Manager
# Earl Wallace
udt_os 1382/tcp
udt_os 1382/udp
gwha 1383/tcp GW Hannaway Network License Manager
gwha 1383/udp GW Hannaway Network License Manager
# J. Gabriel Foster
os-licman 1384/tcp Objective Solutions License Manager
os-licman 1384/udp Objective Solutions License Manager
# Donald Cornwell
atex_elmd 1385/tcp Atex Publishing License Manager
atex_elmd 1385/udp Atex Publishing License Manager
# Brett Sorenson
checksum 1386/tcp CheckSum License Manager
checksum 1386/udp CheckSum License Manager
# Andreas Glocker
cadsi-lm 1387/tcp Computer Aided Design Software Inc LM
cadsi-lm 1387/udp Computer Aided Design Software Inc LM
# Sulistio Muljadi
objective-dbc 1388/tcp Objective Solutions DataBase Cache
objective-dbc 1388/udp Objective Solutions DataBase Cache
# Donald Cornwell
iclpv-dm 1389/tcp Document Manager
iclpv-dm 1389/udp Document Manager
iclpv-sc 1390/tcp Storage Controller
iclpv-sc 1390/udp Storage Controller
iclpv-sas 1391/tcp Storage Access Server
iclpv-sas 1391/udp Storage Access Server
iclpv-pm 1392/tcp Print Manager
iclpv-pm 1392/udp Print Manager
iclpv-nls 1393/tcp Network Log Server
iclpv-nls 1393/udp Network Log Server
iclpv-nlc 1394/tcp Network Log Client
iclpv-nlc 1394/udp Network Log Client
iclpv-wsm 1395/tcp PC Workstation Manager software
iclpv-wsm 1395/udp PC Workstation Manager software
# A.P. Hobson
dvl-activemail 1396/tcp DVL Active Mail
dvl-activemail 1396/udp DVL Active Mail
audio-activmail 1397/tcp Audio Active Mail
audio-activmail 1397/udp Audio Active Mail
video-activmail 1398/tcp Video Active Mail
video-activmail 1398/udp Video Active Mail
# Ehud Shapiro
cadkey-licman 1399/tcp Cadkey License Manager
cadkey-licman 1399/udp Cadkey License Manager
cadkey-tablet 1400/tcp Cadkey Tablet Daemon
cadkey-tablet 1400/udp Cadkey Tablet Daemon
# Joe McCollough
goldleaf-licman 1401/tcp Goldleaf License Manager
goldleaf-licman 1401/udp Goldleaf License Manager
# John Fox <---none--->
prm-sm-np 1402/tcp Prospero Resource Manager
prm-sm-np 1402/udp Prospero Resource Manager
prm-nm-np 1403/tcp Prospero Resource Manager
prm-nm-np 1403/udp Prospero Resource Manager
# B. Clifford Neuman
igi-lm 1404/ tcp Infinite Graphics License Manager
igi-lm 1404/udp Infinite Graphics License Manager
ibm-res 1405/tcp IBM Remote Execution Starter
ibm-res 1405/udp IBM Remote Execution Starter
netlabs-lm 1406/tcp NetLabs License Manager
netlabs-lm 1406/udp NetLabs License Manager
dbsa-lm 1407/tcp DBSA License Manager
dbsa-lm 1407/udp DBSA License Manager
# Scott Shattuck
sophia-lm 1408/tcp Sophia License Manager
sophia-lm 1408/udp Sophia License Manager
# Eric Brown
here-lm 1409/tcp Here License Manager
here-lm 1409/udp Here License Manager
# David Ison
hiq 1410/tcp HiQ License Manager
hiq 1410/udp HiQ License Manager
# Rick Pugh
af 1411/tcp AudioFile
af 1411/udp AudioFile
# Jim Gettys
innosys 1412/tcp InnoSys
innosys 1412/udp InnoSys
innosys-acl 1413/tcp Innosys-ACL
innosys-acl 1413/udp Innosys-ACL
# Eric Welch <--none--->
ibm-mqseries 1414/tcp IBM MQSeries
ibm-mqseries 1414/udp IBM MQSeries
# Roger Meli
dbstar 1415/tcp DBStar
dbstar 1415/udp DBStar
# Jeffrey Millman
novell-lu6.2 1416/tcp Novell LU6.2
novell-lu6.2 1416/udp Novell LU6.2
# Peter Liu <--none--->
timbuktu-srv1 1417/tcp Timbuktu Service 1 Port
timbuktu-srv1 1417/tcp Timbuktu Service 1 Port
timbuktu-srv2 1418/tcp Timbuktu Service 2 Port
timbuktu-srv2 1418/udp Timbuktu Service 2 Port
timbuktu-srv3 1419/tcp Timbuktu Service 3 Port
timbuktu-srv3 1419/udp Timbuktu Service 3 Port
timbuktu-srv4 1420/tcp Timbuktu Service 4 Port
timbuktu-srv4 1420/udp Timbuktu Service 4 Port
# Marc Epard
gandalf-lm 1421/tcp Gandalf License Manager
gandalf-lm 1421/udp Gandalf License Manager
# gilmer@gandalf.ca
autodesk-lm 1422/tcp Autodesk License Manager
autodesk-lm 1422/udp Autodesk License Manager
# David Ko
essbase 1423/tcp Essbase Arbor Software
essbase 1423/udp Essbase Arbor Software
hybrid 1424/tcp Hybrid Encryption Protocol
hybrid 1424/udp Hybrid Encryption Protocol
# Howard Hart
zion-lm 1425/ tcp Zion Software License Manager
zion-lm 1425/udp Zion Software License Manager
# David Ferrero
sas-1 1426/tcp Satellite-data Acquisition System 1
sas-1 1426/udp Satellite-data Acquisition System 1
# Bill Taylor
mloadd 1427/tcp mloadd monitoring tool
mloadd 1427/udp mloadd monitoring tool
# Bob Braden
informatik-lm 1428/tcp Informatik License Manager
informatik-lm 1428/udp Informatik License Manager
# Harald Schlangmann
#
nms 1429/tcp Hypercom NMS
nms 1429/udp Hypercom NMS
tpdu 1430/tcp Hypercom TPDU
tpdu 1430/udp Hypercom TPDU
# Noor Chowdhury
rgtp 1431/tcp Reverse Gosip Transport
rgtp 1431/udp Reverse Gosip Transport
#
blueberry-lm 1432/tcp Blueberry Software License Manager
blueberry-lm 1432/udp Blueberry Software License Manager
# Steve Beigel
ms-sql-s 1433/tcp Microsoft-SQL-Server
ms-sql-s 1433/udp Microsoft-SQL-Server
ms-sql-m 1434/tcp Microsoft-SQL-Monitor
ms-sql-m 1434/udp Microsoft-SQL-Monitor
# Peter Hussey
ibm-cics 1435/tcp IBM CISC
ibm-cics 1435/udp IBM CISC
# Geoff Meacock
sas-2 1436/tcp Satellite-data Acquisition System 2
sas-2 1436/udp Satellite-data Acquisition System 2
# Bill Taylor
tabula 1437/tcp Tabula
tabula 1437/udp Tabula
# Marcelo Einhorn
#
eicon-server 1438/tcp Eicon Security Agent/Server
eicon-server 1438/udp Eicon Security Agent/Server
eicon-x25 1439/tcp Eicon X25/SNA Gateway
eicon-x25 1439/udp Eicon X25/SNA Gateway
eicon-slp 1440/tcp Eicon Service Location Protocol
eicon-slp 1440/udp Eicon Service Location Protocol
# Pat Calhoun
cadis-1 1441/tcp Cadis License Management
cadis-1 1441/udp Cadis License Management
cadis-2 1442/tcp Cadis License Management
cadis-2 1442/udp Cadis License Management
# Todd Wichers
ies-lm 1443/tcp Integrated Engineering Software
ies-lm 1443/udp Integrated Engineering Software
# David Tong
marcam-lm 1444/tcp Marcam License Management
marcam-lm 1444/udp Marcam License Management
# Therese Hunt
proxima-lm 1445/tcp Proxima License Manager
proxima-lm 1445/udp Proxima License Manager
ora-lm 1446/ tcp Optical Research Associates License Manager
ora-lm 1446/udp Optical Research Associates License Manager
apri-lm 1447/tcp Applied Parallel Research LM
apri-lm 1447/udp Applied Parallel Research LM
# Jim Dillon
oc-lm 1448/tcp OpenConnect License Manager
oc-lm 1448/udp OpenConnect License Manager
# Sue Barnhill
peport 1449/tcp PEport
peport 1449/udp PEport
# Qentin Neill
dwf 1450/tcp Tandem Distributed Workbench Facility
dwf 1450/udp Tandem Distributed Workbench Facility
# Mike Bert
infoman 1451/tcp IBM Information Management
infoman 1451/udp IBM Information Management
# Karen Burns <---none--->
gtegsc-lm 1452/tcp GTE Government Systems License Man
gtegsc-lm 1452/udp GTE Government Systems License Man
# Mike Gregory
genie-lm 1453/tcp Genie License Manager
genie-lm 1453/udp Genie License Manager
# Paul Applegate
interhdl_elmd 1454/tcp interHDL License Manager
interhdl_elmd 1454/tcp interHDL License Manager
# Eli Sternheim eli@interhdl.com
esl-lm 1455/tcp ESL License Manager
esl-lm 1455/udp ESL License Manager
# Abel Chou
dca 1456/tcp DCA
dca 1456/udp DCA
# Jeff Garbers
valisys-lm 1457/tcp Valisys License Manager
valisys-lm 1457/udp Valisys License Manager
# Leslie Lincoln
nrcabq-lm 1458/tcp Nichols Research Corp.
nrcabq-lm 1458/udp Nichols Research Corp.
# Howard Cole
proshare1 1459/tcp Proshare Notebook Application
proshare1 1459/udp Proshare Notebook Application
proshare2 1460/tcp Proshare Notebook Application
proshare2 1460/udp Proshare Notebook Application
# Robin Kar
ibm_wrless_lan 1461/tcp IBM Wireless LAN
ibm_wrless_lan 1461/udp IBM Wireless LAN
#
world-lm 1462/tcp World License Manager
world-lm 1462/udp World License Manager
# Michael S Amirault
nucleus 1463/tcp Nucleus
nucleus 1463/udp Nucleus
# Venky Nagar
msl_lmd 1464/tcp MSL License Manager
msl_lmd 1464/udp MSL License Manager
# Matt Timmermans
pipes 1465/tcp Pipes Platform
pipes 1465/udp Pipes Platform mfarlin@peerlogic.com
# Mark Farlin
oceansoft-lm 1466/tcp Ocean Software License Manager
oceansoft-lm 1466/udp Ocean Software License Manager
# Randy Leonard
csdmbase 1467/tcp CSDMBASE
csdmbase 1467/udp CSDMBASE
csdm 1468/tcp CSDM
csdm 1468/udp CSDM
# Robert Stabl
aal-lm 1469/ tcp Active Analysis Limited License Manager
aal-lm 1469/udp Active Analysis Limited License Manager
# David Snocken +44 (71)437-7009
uaiact 1470/tcp Universal Analytics
uaiact 1470/udp Universal Analytics
# Mark R. Ludwig
csdmbase 1471/tcp csdmbase
csdmbase 1471/udp csdmbase
csdm 1472/tcp csdm
csdm 1472/udp csdm
# Robert Stabl
openmath 1473/tcp OpenMath
openmath 1473/udp OpenMath
# Garth Mayville
telefinder 1474/tcp Telefinder
telefinder 1474/udp Telefinder
# Jim White
taligent-lm 1475/tcp Taligent License Manager
taligent-lm 1475/udp Taligent License Manager
# Mark Sapsford
clvm-cfg 1476/tcp clvm-cfg
clvm-cfg 1476/udp clvm-cfg
# Eric Soderberg
ms-sna-server 1477/tcp ms-sna-server
ms-sna-server 1477/udp ms-sna-server
ms-sna-base 1478/tcp ms-sna-base
ms-sna-base 1478/udp ms-sna-base
# Gordon Mangione
dberegister 1479/tcp dberegister
dberegister 1479/udp dberegister
# Brian Griswold
pacerforum 1480/tcp PacerForum
pacerforum 1480/udp PacerForum
# Peter Caswell
airs 1481/tcp AIRS
airs 1481/udp AIRS
# Bruce Wilson, 905-771-6161
miteksys-lm 1482/tcp Miteksys License Manager
miteksys-lm 1482/udp Miteksys License Manager
# Shane McRoberts
afs 1483/tcp AFS License Manager
afs 1483/udp AFS License Manager
# Michael R. Pizolato
confluent 1484/tcp Confluent License Manager
confluent 1484/udp Confluent License Manager
# James Greenfiel
lansource 1485/tcp LANSource
lansource 1485/udp LANSource
# Doug Scott
nms_topo_serv 1486/tcp nms_topo_serv
nms_topo_serv 1486/udp nms_topo_serv
# Sylvia Siu
localinfosrvr 1487/tcp LocalInfoSrvr
localinfosrvr 1487/udp LocalInfoSrvr
# Brian Matthews
docstor 1488/tcp DocStor
docstor 1488/udp DocStor
# Brian Spears
dmdocbroker 1489/tcp dmdocbroker
dmdocbroker 1489/udp dmdocbroker
# Razmik Abnous
insitu-conf 1490/tcp insitu-conf
insitu-conf 1490/udp insitu-conf
# Paul Blacknell
anynetgateway 1491/tcp anynetgateway
anynetgateway 1491/udp anynetgateway
# Dan Poirier
stone-design-1 1492/tcp stone-design-1
stone-design-1 1492/udp stone-design-1
# Andrew Stone
netmap_lm 1493/tcp netmap_lm
netmap_lm 1493/udp netmap_lm
# Phillip Magson
ica 1494/tcp ica
ica 1494/udp ica
# John Richardson, Citrix Systems
cvc 1495/tcp cvc
cvc 1495/udp cvc
# Bill Davidson
liberty-lm 1496/tcp liberty-lm
liberty-lm 1496/udp liberty-lm
# Jim Rogers
rfx-lm 1497/tcp rfx-lm
rfx-lm 1497/udp rfx-lm
# Bill Bishop
watcom-sql 1498/tcp Watcom-SQL
watcom-sql 1498/udp Watcom-SQL
# Rog Skubowius
fhc 1499/tcp Federico Heinz Consultora
fhc 1499/udp Federico Heinz Consultora
# Federico Heinz
vlsi-lm 1500/tcp VLSI License Manager
vlsi-lm 1500/udp VLSI License Manager
# Shue-Lin Kuo
sas-3 1501/tcp Satellite-data Acquisition System 3
sas-3 1501/udp Satellite-data Acquisition System 3
# Bill Taylor
shivadiscovery 1502/tcp Shiva
shivadiscovery 1502/udp Shiva
# Jonathan Wenocur
imtc-mcs 1503/tcp Databeam
imtc-mcs 1503/udp Databeam
# Jim Johnstone
evb-elm 1504/ tcp EVB Software Engineering License Manager
evb-elm 1504/udp EVB Software Engineering License Manager
# B.G. Mahesh < mahesh@sett.com>
funkproxy 1505/tcp Funk Software, Inc.
funkproxy 1505/udp Funk Software, Inc.
# Robert D. Vincent
# 1506-1523 Unassigned
ingreslock 1524/tcp ingres
ingreslock 1524/udp ingres
orasrv 1525/tcp oracle
orasrv 1525/udp oracle
prospero-np 1525/tcp Prospero Directory Service non-priv
prospero-np 1525/udp Prospero Directory Service non-priv
pdap-np 1526/ tcp Prospero Data Access Prot non-priv
pdap-np 1526/udp Prospero Data Access Prot non-priv
# B. Clifford Neuman
tlisrv 1527/tcp oracle
tlisrv 1527/udp oracle
coauthor 1529/tcp oracle
coauthor 1529/udp oracle
issd 1600/tcp
issd 1600/udp
nkd 1650/tcp
nkd 1650/udp
proshareaudio 1651/tcp proshare conf audio
proshareaudio 1651/udp proshare conf audio
prosharevideo 1652/tcp proshare conf video
prosharevideo 1652/udp proshare conf video
prosharedata 1653/tcp proshare conf data
prosharedata 1653/udp proshare conf data
prosharerequest 1654/tcp proshare conf request
prosharerequest 1654/udp proshare conf request
prosharenotify 1655/tcp proshare conf notify
prosharenotify 1655/udp proshare conf notify
#
netview-aix-1 1661/tcp netview-aix-1
netview-aix-1 1661/udp netview-aix-1
netview-aix-2 1662/tcp netview-aix-2
netview-aix-2 1662/udp netview-aix-2
netview-aix-3 1663/tcp netview-aix-3
netview-aix-3 1663/udp netview-aix-3
netview-aix-4 1664/tcp netview-aix-4
netview-aix-4 1664/udp netview-aix-4
netview-aix-5 1665/tcp netview-aix-5
netview-aix-5 1665/udp netview-aix-5
netview-aix-6 1666/tcp netview-aix-6
netview-aix-6 1666/udp netview-aix-6
# Martha Crisson
licensedaemon 1986/tcp cisco license management
licensedaemon 1986/udp cisco license management
tr-rsrb-p1 1987/tcp cisco RSRB Priority 1 port
tr-rsrb-p1 1987/udp cisco RSRB Priority 1 port
tr-rsrb-p2 1988/tcp cisco RSRB Priority 2 port
tr-rsrb-p2 1988/udp cisco RSRB Priority 2 port
tr-rsrb-p3 1989/tcp cisco RSRB Priority 3 port
tr-rsrb-p3 1989/udp cisco RSRB Priority 3 port
#PROBLEMS!===================================================
mshnet 1989/tcp MHSnet system
mshnet 1989/udp MHSnet system
# Bob Kummerfeld
#PROBLEMS!===================================================
stun-p1 1990/ tcp cisco STUN Priority 1 port
stun-p1 1990/udp cisco STUN Priority 1 port
stun-p2 1991/tcp cisco STUN Priority 2 port
stun-p2 1991/udp cisco STUN Priority 2 port
stun-p3 1992/tcp cisco STUN Priority 3 port
stun-p3 1992/udp cisco STUN Priority 3 port
#PROBLEMS!===================================================
ipsendmsg 1992/tcp IPsendmsg
ipsendmsg 1992/udp IPsendmsg
# Bob Kummerfeld
#PROBLEMS!===================================================
snmp-tcp-port 1993/tcp cisco SNMP TCP port
snmp-tcp-port 1993/udp cisco SNMP TCP port
stun-port 1994/tcp cisco serial tunnel port
stun-port 1994/udp cisco serial tunnel port
perf-port 1995/tcp cisco perf port
perf-port 1995/udp cisco perf port
tr-rsrb-port 1996/tcp cisco Remote SRB port
tr-rsrb-port 1996/udp cisco Remote SRB port
gdp-port 1997/tcp cisco Gateway Discovery Protocol
gdp-port 1997/udp cisco Gateway Discovery Protocol
x25-svc-port 1998/tcp cisco X.25 service (XOT)
x25-svc-port 1998/udp cisco X.25 service (XOT)
tcp-id-port 1999/tcp cisco identification port
tcp-id-port 1999/udp cisco identification port
callbook 2000/tcp
callbook 2000/udp
dc 2001/tcp
wizard 2001/udp curry
globe 2002/tcp
globe 2002/udp
mailbox 2004/tcp
emce 2004/udp CCWS mm conf
berknet 2005/tcp
oracle 2005/udp
invokator 2006/tcp
raid-cc 2006/udp raid
dectalk 2007/tcp
raid-am 2007/udp
conf 2008/tcp
terminaldb 2008/udp
news 2009/tcp
whosockami 2009/udp
search 2010/tcp
pipe_server 2010/udp
raid-cc 2011/tcp raid
servserv 2011/udp
ttyinfo 2012/tcp
raid-ac 2012/udp
raid-am 2013/tcp
raid-cd 2013/udp
troff 2014/tcp
raid-sf 2014/udp
cypress 2015/tcp
raid-cs 2015/udp
bootserver 2016/tcp
bootserver 2016/udp
cypress-stat 2017/tcp
bootclient 2017/udp
terminaldb 2018/tcp
rellpack 2018/udp
whosockami 2019/tcp
about 2019/udp
xinupageserver 2020/tcp
xinupageserver 2020/udp
servexec 2021/tcp
xinuexpansion1 2021/udp
down 2022/tcp
xinuexpansion2 2022/udp
xinuexpansion3 2023/tcp
xinuexpansion3 2023/udp
xinuexpansion4 2024/tcp
xinuexpansion4 2024/udp
ellpack 2025/tcp
xribs 2025/udp
scrabble 2026/tcp
scrabble 2026/udp
shadowserver 2027/tcp
shadowserver 2027/udp
submitserver 2028/tcp
submitserver 2028/udp
device2 2030/tcp
device2 2030/udp
blackboard 2032/tcp
blackboard 2032/udp
glogger 2033/tcp
glogger 2033/udp
scoremgr 2034/tcp
scoremgr 2034/udp
imsldoc 2035/tcp
imsldoc 2035/udp
objectmanager 2038/tcp
objectmanager 2038/udp
lam 2040/tcp
lam 2040/udp
interbase 2041/tcp
interbase 2041/udp
isis 2042/tcp
isis 2042/udp
isis-bcast 2043/tcp
isis-bcast 2043/udp
rimsl 2044/tcp
rimsl 2044/udp
cdfunc 2045/tcp
cdfunc 2045/udp
sdfunc 2046/tcp
sdfunc 2046/udp
dls 2047/tcp
dls 2047/udp
dls-monitor 2048/tcp
dls-monitor 2048/udp
shilp 2049/tcp
shilp 2049/udp
dlsrpn 2065/ tcp Data Link Switch Read Port Number
dlsrpn 2065/udp Data Link Switch Read Port Number
dlswpn 2067/tcp Data Link Switch Write Port Number
dlswpn 2067/udp Data Link Switch Write Port Number
ats 2201/tcp Advanced Training System Program
ats 2201/udp Advanced Training System Program
rtsserv 2500/tcp Resource Tracking system server
rtsserv 2500/udp Resource Tracking system server
rtsclient 2501/tcp Resource Tracking system client
rtsclient 2501/udp Resource Tracking system client
# Aubrey Turner
#
hp-3000-telnet 2564/tcp HP 3000 NS/VT block mode telnet
www-dev 2784/tcp world wide web - development
www-dev 2784/udp world wide web - development
NSWS 3049/tcp
NSWS 3049/udp
ccmail 3264/tcp cc:mail/lotus
ccmail 3264/udp cc:mail/lotus
dec-notes 3333/tcp DEC Notes
dec-notes 3333/udp DEC Notes
# Kim Moraros
mapper-nodemgr 3984/tcp MAPPER network node manager
mapper-nodemgr 3984/udp MAPPER network node manager
mapper-mapethd 3985/tcp MAPPER TCP/IP server
mapper-mapethd 3985/udp MAPPER TCP/IP server
mapper-ws_ethd 3986/tcp MAPPER workstation server
mapper-ws_ethd 3986/udp MAPPER workstation server
# John C. Horton
bmap 3421/tcp Bull Apprise portmapper
bmap 3421/udp Bull Apprise portmapper
# Jeremy Gilbert
udt_os 3900/tcp Unidata UDT OS
udt_os 3900/udp Unidata UDT OS
# James Powell
nuts_dem 4132/tcp NUTS Daemon
nuts_dem 4132/udp NUTS Daemon
nuts_bootp 4133/tcp NUTS Bootp Server
nuts_bootp 4133/udp NUTS Bootp Server
# Martin Freiss
unicall 4343/tcp UNICALL
unicall 4343/udp UNICALL
# James Powell
krb524 4444/tcp KRB524
krb524 4444/udp KRB524
# B. Clifford Neuman
rfa 4672/ tcp remote file access server
rfa 4672/udp remote file access server
commplex-main 5000/tcp
commplex-main 5000/udp
commplex-link 5001/tcp
commplex-link 5001/udp
rfe 5002/tcp radio free ethernet
rfe 5002/udp radio free ethernet
telelpathstart 5010/tcp TelepathStart
telelpathstart 5010/udp TelepathStart
telelpathattack 5011/tcp TelepathAttack
telelpathattack 5011/udp TelepathAttack
# Helmuth Breitenfellner
mmcc 5050/tcp multimedia conference control tool
mmcc 5050/udp multimedia conference control tool
rmonitor_secure 5145/tcp
rmonitor_secure 5145/udp
aol 5190/tcp America-Online
aol 5190/udp America-Online
# Marty Lyons
padl2sim 5236/tcp
padl2sim 5236/udp
hacl-hb 5300/tcp # HA cluster heartbeat
hacl-hb 5300/udp # HA cluster heartbeat
hacl-gs 5301/tcp # HA cluster general services
hacl-gs 5301/udp # HA cluster general services
hacl-cfg 5302/tcp # HA cluster configuration
hacl-cfg 5302/udp # HA cluster configuration
hacl-probe 5303/tcp # HA cluster probing
hacl-probe 5303/udp # HA cluster probing
hacl-local 5304/tcp
hacl-local 5304/udp
hacl-test 5305/tcp
hacl-test 5305/udp
# Eric Soderberg
x11 6000-6063/tcp X Window System
x11 6000-6063/udp X Window System
# Stephen Gildea
sub-process 6111/tcp HP SoftBench Sub-Process Control
sub-process 6111/udp HP SoftBench Sub-Process Control
meta-corp 6141/tcp Meta Corporation License Manager
meta-corp 6141/udp Meta Corporation License Manager
# Osamu Masuda <--none--->
aspentec-lm 6142/tcp Aspen Technology License Manager
aspentec-lm 6142/udp Aspen Technology License Manager
# Kevin Massey
watershed-lm 6143/tcp Watershed License Manager
watershed-lm 6143/udp Watershed License Manager
# David Ferrero
statsci1-lm 6144/tcp StatSci License Manager - 1
statsci1-lm 6144/udp StatSci License Manager - 1
statsci2-lm 6145/tcp StatSci License Manager - 2
statsci2-lm 6145/udp StatSci License Manager - 2
# Scott Blachowicz
lonewolf-lm 6146/ tcp Lone Wolf Systems License Manager
lonewolf-lm 6146/udp Lone Wolf Systems License Manager
# Dan Klein
montage-lm 6147/tcp Montage License Manager
montage-lm 6147/udp Montage License Manager
# Michael Ubell
xdsxdm 6558/udp
xdsxdm 6558/tcp
afs3-fileserver 7000/tcp file server itself
afs3-fileserver 7000/udp file server itself
afs3-callback 7001/tcp callbacks to cache managers
afs3-callback 7001/udp callbacks to cache managers
afs3-prserver 7002/tcp users & groups database
afs3-prserver 7002/udp users & groups database
afs3-vlserver 7003/tcp volume location database
afs3-vlserver 7003/udp volume location database
afs3-kaserver 7004/tcp AFS/Kerberos authentication service
afs3-kaserver 7004/udp AFS/Kerberos authentication service
afs3-volser 7005/tcp volume managment server
afs3-volser 7005/udp volume managment server
afs3-errors 7006/tcp error interpretation service
afs3-errors 7006/udp error interpretation service
afs3-bos 7007/tcp basic overseer process
afs3-bos 7007/udp basic overseer process
afs3-update 7008/tcp server-to-server updater
afs3-update 7008/udp server-to-server updater
afs3-rmtsys 7009/tcp remote cache manager service
afs3-rmtsys 7009/udp remote cache manager service
ups-onlinet 7010/tcp onlinet uninterruptable power supplies
ups-onlinet 7010/udp onlinet uninterruptable power supplies
# Brian Hammill
font-service 7100/tcp X Font Service
font-service 7100/udp X Font Service
# Stephen Gildea
fodms 7200/tcp FODMS FLIP
fodms 7200/udp FODMS FLIP
# David Anthony
man 9535/tcp
man 9535/udp
isode-dua 17007/tcp
isode-dua 17007/udp
Терминология
Прежде чем мы сможем обсудить многие детали действия TCP протокола, нам необходимо ввести подробную терминологию. Для поддержания TCP соединения необходимо иметь несколько переменных. Мы решили, что эти переменные будут помещены в соответствующую запись - блок управления передачей (Transmission Control Block - TCB). Среди переменных блока TCB имеются номера местного и чужого сокетов, флаги безопасности и приоритета для данного соединения, указатели буферов посылки и получения, указатели текущего сегмента и очереди повторной посылки. Кроме всего этого в TCB имеются несколько переменных, имеющих отношение к номерам очередей отправителя и получателя.
Управление окном
Окно, посылаемое с каждым сегментом, указывает диапазон номеров очереди, которые отправитель окна (он же получатель данных) готов принять в настоящее время. Предполагается, что такой механизм связан с наличием в данный момент места в буфере данных.
Указание окна большого размера стимулирует передачу. Но если при шло большее количество данных, чем может быть принято программой TCP, данные будут отброшены. Это приведет к излишним пересылкам информации и ненужному увеличению нагрузки на сеть и программу TCP. Указание окна малого размера может ограничить передачу данных скоростью, которая определяется временем путешествия по сети после каждого посылаемого сегмента.
Такие механизмы протокола позволяют программе TCP заявлять большое окно, но впоследствии объявлять окна намного меньшего размера и не принимать такое большое количество данных. Такое, так называемое, сокращение окна выглядит довольно обескураживающе. Принцип устойчивости диктует, чтобы программа протокола TCP не сокращала сама окно, но была бы готова к таким действиям со стороны другой программы TCP.
Программа TCP, посылающая данные, должна быть готова принять от клиента и передать по сети по крайней мере один октет новых данных, даже если окно отправления равно нулю. Программа TCP должна периодически повторно посылать данные другой программе TCP, даже если окно нулевое. В случае нулевого окна рекомендуется использовать интервал повторной посылки в две минуты. Такие повторные посылки важны для того, чтобы гарантировать, что в случае, когда одна из двух программ TCP имеет нулевое окно, открытие этого окна будет гарантированно сообщено партнеру.
Когда программа TCP, получающая данные, имеет нулевое окно, но к ней приходит сегмент, то эта программа должна послать подтверждение и указать, какой следующий номер в очереди она ожидает и какое у нее окно в настоящий момент (окно нулевое).
Программа TCP пакует предназначенные к в пересылке данные в сегменты, заполняющие текущее окно. Однако она не может перепаковать уже имеющиеся сегменты в очереди на повторную посылку. Такая перепаковка хоть и не обязательна, но может быть полезна.
В соединении, имеющем односторонний поток данных, информация об окне будет передаваться с сегментами подтверждения, а они будут все иметь одинаковый номер очереди. Поэтому не будет способа восстановить их очередность при получении. Это не является серьезной проблемой, но может случайно привести к получению информации об окне из какого-нибудь устаревшего сообщения. Во избежание такой проблемы должен осуществляться отсев и информация об окне должна браться из сегментов, имеющих самый большой номер в очереди (это сегменты, чей номер подтверждения больше или равен наибольшему из ранее полученных номеров).
Процедура управления окном оказывает значительное влияние на характеристики коммуникаций. Дальнейшие комментарии содержат пожелания разработчикам.
Управление потоком
Протокол TCP дает средства получателю управлять количеством данных, посылаемых ему отправителем. Это достигается возвратом так называемого "окна" (window) вместе с каждым подтверждением, которое указывает диапазон приемлемых номеров, следующих за номером последнего успешно принятого сегмента. Окно определяет количество октетов, которое отправитель может послать до получения дальнейших указаний.
Установка соединения и его отмена
Чтобы идентифицировать отдельные потоки данных, поддерживаемые протоколом 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) и трижды обменивается сообщениями. Такой обмен называется трехвариантным подтверждением.
Соединение инициируется при встрече пришедшего сегмента, несущего флаг синхронизации (SYN), и ждущей его записи в блоке TCB. И сегмент и запись создаются пришедшими от пользователей запросами на открытие. Соответствие местного и чужого сокетов устанавливается при инициализации соединения. Соединение признается установленным, когда номера очередей синхронизированы в обоих направлениях между сокетами.
Отмена соединения также включает обмен сегментами, несущими на этот раз управляющий флаг FIN.
Установление соединения
"Подтверждение трех путей" - это процедура, используемая при установлении соединения. Эта процедура обычно инициируется программой протокола 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 |
/p>
Одновременная синхронизация соединения
Рисунок 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 |
Рисунок 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 |
на двух пассивных сокетах
Рисунок 12
Может быть множество других вариаций, которые могут быть объяснены нижеописанными правилами для создания и обработки сигналов RST.
Создание сигнала перезагрузки
Согласно главному правилу, сигнал перезагрузки (RST) должен посылаться всякий раз, когда приходит сегмент, который очевидным образом не предназначен для данного соединения. Если непонятно, имеет ли место данный случай, следует воздержаться от перезагрузки.
Можно выделить три группы состояний для соединения:
Если соединения не существует (CLOSED), то сигнал перезагрузки посылается в ответ на любой пришедший сегмент, за исключением встречного сигнала перезагрузки. В частности, сигналы SYN, адресованные на несуществующее соединение, отвергаются именно таким образом.
Если приходящий сегмент имеет флаг в поле ACK, то сегмент с сигналом перезагрузки получает номер для очереди из поля ACK первого сегмента. В противном случае сегмент с сигналом перезагрузки имеет нулевой номер очереди и значение в поле ACK, равным сумме номера очереди пришедшего сегмента и его же длины. Соединение остается в состоянии CLOSED.
Если соединение находится в каком-либо не синхронизированном состоянии (LISTEN, SYN-SENT, SYN-RECEIVED), если какие-либо подтверждения пришедшего сегмента еще не отправлены (сегмент несет неприемлемое значение в поле ACK) или пришедший сегмент имеет уровень безопасности/закрытости не соответствующий уровню и защите данного соединения, то отправляется сигнал перезагрузки.
Если наш сигнал SYN не был подтвержден, а уровень приоритета пришедшего сегмента больше запрошенного уровня, то либо будет увеличен местный уровень приоритета (если это приемлемо для пользователя и системы), либо будет послан сигнал перезагрузки. Или же если уровень приоритета пришедшего сегмента меньше запрошенного, то обработка будет продолжена далее, как если бы уровень был таким же (если чужая программа TCP не может повысить уровень приоритета до нашего, то это будет отмечено в следующем отправляемом ею сегменте, тогда и будет закрыто соединение). Если наш сигнал SYN получил подтверждение (возможно в пришедшем к нам сегменте), то уровень приоритета пришедшего сегмента должен точно соответствовать мест ному уровню. Если последнее условие не выполняется, посылается сигнал перезагрузки.
Если приходящий сегмент несет сигнал ACK, то сигнал перезагрузки будет иметь номер в очереди, соответствующий номеру сигнала ACK в пришедшем сегменте. В противном случае сигнал перезагрузки будет иметь нулевой номер очереди, а сигнал ACK - номер, равный сумме номера пришедшего сегмента и его же длины. Соединение не меняет своего состояния.
Если соединение находится в синхронизированном состоянии (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, оповещает об этом своего клиента. <
Выбор первоначального номера для очереди
Протокол не накладывает ограничения на многократное повторное использование конкретного соединения. Соединение задается подбором пары сегментов. Новые запросы на установление какого-либо соединения будут рассматриваться как повторные реализации этого соединения. Вследствие такого подхода возникает следующая проблема: "Как протокол TCP отличает дубликаты сегментов, оставшиеся от предыдущей реализации этого соединения?" Эта проблема становится явной, если соединение быстро открывается и закрывается несколько раз подряд, или же если соединение прерывает свою работу с потерей информации, хранившейся в оперативной памяти компьютера, и затем устанавливается повторно.
Чтобы избежать сбоя, мы должны избегать использования сегментов данной реализации соединения, когда в сети еще присутствуют те же самые номера очереди, оставшиеся от предыдущей реализации соединения. Мы желаем застраховаться от этого, даже если программа протокола TCP даст сбой и потеряет всю информацию об используемых ею номерах очередей. При создании новых соединений применяется генератор первоначальных номеров очереди (ISN), который выбирает новые 32 битные значения ISN. Генератор привязан к 32-битным часам (вероятно, фиктивным), чье значение меняется каждые 4 микросекунды. Таким образом, полный цикл часов ISN составляет примерно 4.55 часа. Поскольку мы полагаем, что сегменты будут существовать в сети не более максимального времени жизни сегмента (Maximum Segment Lifetime - 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 |
Подтверждение трех путей необходимо, поскольку номера очереди не привязываются к неким глобальным часам данной компьютерной сети, и программы TCP могут иметь различные механизмы для подбора номеров ISN. Получатель первого сигнала SYN не может знать, задержался ли этот сигнал и уже устарел, или это не так, даже если получатель не помнит последний номер очереди, использованный этим соединением (что тоже не всегда возможно). Так что он должен попросить отправителя проверить этот сигнал SYN.
Закрытие соединения
Состояние 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 |
/p>
Процедура одновременного закрытия соединения с обоих концов
Рисунок 14 <
  
|
| H.323 | В настоящее время для связи пользователей все активнее используются видеоконференция. Она обеспечивает как передачу текста, так и речи и видеоизображения, и все это в реальном масштабе времени.
Раньше это было очень дорогое удовольствие. Выделенные каналы скоростные каналы связи, дорогостоящее оборудование. Позволить себе такую роскошь могли только очень крупные корпорации и гос. структуры, и то только в случае крайней необходимости. После появления протоколов обеспечивающих реализацию данной услуги с помощью сети с интеграцией служб (ISDN), данная услуга стала более доступной, но ее широкое использование ограничивалось недостаточной распространенностью самих сетей ISDN. И только после появление готовых решений для построения систем видеоконференц-связи на базе пакетных сетей эта услуга начала свое победной шествие. Теперь ее выгодно использовать для организации связи сотрудников как в рамках интрасети корпорации, так и в для связи через глобальные сети. В данном обзоре мы рассмотрим основные протоколы и принципы функционирования и протоколы видеоконференций на базе пакетных сетей. Предлагаются следующие материалы:
|
HTTP - Протокол передачи гипертекстов
 |
Описание протокола НТТР |
|
Типы сообщений НТТР |
|
Соглашения HTTP |
HTTP (Hypertext Transfer Protokol) - протокол прикладного уровня, предназначен для распределения и управления информационными системами, реализующими механизм гипертекстовых ссылок. Он является основным объектно-ориентированным протоколом, который может решать задачи управления обменом между серверами и объектами распределенных систем, используя их методы запросов. Основным направлением развития HTTP является определение типа и способов представления данных; применение систем, независимых от способа передачи данных.
HTTP используется Word-Wide Web начиная с 1990 года. Первая версия НТТР - НТТР/0.9 - являлась простым протоколом передачи данных через Internet. В версии НТТР/1.0 добавлена возможность передачи сообщений в формате MIME, содержащем различную информацию о переданных данных и изменениях в семантике запрос/ответ. Однако, НТТР/1.0 полностью не удовлетворял требованиям открытой системы, надежного соединения и другим инструкциям, которые обеспечивают защиту вызванных приложений.
Рассматриваемая версия НТТР - НТТР/1.1 полностью совместима с НТТР/1.0, но содержит более строгие требования для обеспечения совместимости с различными приложениями. Данный протокол позволяет расширять набор методов, которые определяют цель запросов. НТТР/1.1 разработан в соответствии с требованиями поддержки универсальных указателей идентификатора URI (Universal Resurse Identifier), ресурсов URL (Universal Resurse Location) и имени URN (Universal Resurse Name), для определения ресурса, к которому обратилось приложение. Сообщения передаются службами электронной почты (Internet Mail) и службами стандарта MIME (Multipurpose Internet Mail Extensions), разработанного с целью пересылки по электронной почте Internet любых типов данных.
НТТР также используется как основной протокол для соединения агента пользователя и межсетевого шлюза с такими протоколами Internet как SMTP, NNTP, FTP, Gopher и WAIS, как протокол, позволяющий организовать гипер-доступ к ресурсам, доступным из различных приложений и облегчающий применение агентов пользователей.
Описание протокола НТТР
Протокол НТТР базируется на основе парадигмы запрос/ответ. Клиент посылает запросы серверу с указанием метода запроса, URI, версии протокола; сообщения передаются в соответствии со спецификацией MIME, содержащей информацию пользователя и поля, необходимые для установления соединения с сервером. Сервер, получив запрос, передает номер порта соединения, версию протокола соединения, сообщение об успешном соединении или ошибке при установлении сеанса, данные в соответствии со спецификацией MIME и служебные поля.
Большинство соединений НТТР инициализируется агентом пользователя и состоит из запроса на доступ к ресурсам необходимого сервера. Более сложные ситуации возникают, когда в цепочке запрос/ответ присутствует процесс-посредник. Выделяют три формы процессов-посредников: заместитель, шлюз и туннель. Процесс-заместитель - это передающий агент, который принимает запрос для URI, перезаписывает все части сообщения и передает преобразованный запрос серверу, определяемому по параметрам URI. Шлюз (межсетевой) - это принимающий агент, выступающий в роли отдельного сетевого уровня, который, если необходимо, может передать запрос вышестоящим службам протоколов. Туннель - это коммутатор между двумя точками соединения, который не изменяет семантику сеанса; туннель используется, когда необходимо передать информацию через посредника в том случае, когда посредник не может определить тип передаваемой информации. Сообщения, направляемые в соответствии с цепочками запрос/ответ, должны пройти через четыре различных соединения.
В Internet сеансы НТТР базируются на соединениях TCP/IP. По умолчанию используется порт 80, но возможно использование и других портов. Это не исключает возможности использовать НТТР как протокол прикладного уровня для других протоколов Internet или протоколов других сетей. НТТР предполагает наличие транспортного протокола; любой протокол, который удовлетворяет требованиям транспортного уровня, может использоваться для организации сеансов НТТР. Однако, функционирование НТТР/1.1 предполагает обеспечение устойчивого соединения.
Как пользователь, так и сервер должны быть способны корректно обработать ситуации преждевременного завершения сеанса, истечения времени тайм-аута или ошибки программы. В любом случае прекращение сеанса одним или обоими абонентами всегда сопровождается уничтожением запросов, независимо от их статуса.
Типы сообщений НТТР
Сообщения НТТР состоят из запросов от программы-клиента к серверу и ответов сервера программе-клиенту.
Существуют следующие типы сообщений: нулевой запрос, полный запрос, полный ответ.
Нулевой запрос (пустая строка) всегда должен игнорироваться. Программа-клиент не должна посылать нулевой запрос, но возможны ситуации ошибок и тестирования, в которых нулевой запрос может быть послан как ошибочный, и он не должен являться причиной ошибки на сервере. Нулевой запрос имеет вид: Null-Reqest: CRLF.
Сообщение полного запроса, передаваемое от программы-клиента к серверу включает метод доступа к ресурсу, идентификатор ресурса и версию используемого протокола. Для совместимости с более простым протоколом НТТР/0.9 используются две формы запросов НТТР: полный запрос и полный запрос с нулевым запросом (Full-Reqest | Null-Reqest). Полный запрос имеет вид:
| Поле запроса | Основной Заголовок |
Заголовок запроса |
Заголовок объекта | Тело объекта |
| (Reqest-Line) | (General-Header) | (Reqest-Header) | (Entity-Header) | (Entity-Body) |
Поле запроса состоит из метода доступа, идентификатора URI и версии протокола.
Поле “метод” определяет метод доступа к объекту, указанному в идентификаторе URI. Существуют следующие методы доступа:
 |
Conditional Get (условный) - когда в запросе используется поле If-Modified-Since. Метод Conditional Get означает, что определенный запросом объект будет передаваться в случае, если дата его модификации старше даты, указанной в поле If-Modified-Since; |
|
Partial Get (частный) - когда в запросе используется поле Range. Это позволяет определить, какую часть от определенного объекта требуется передать; |
/p>
Поле основного заголовка используется с сообщениями, которые будут передаваться и включает следующие поля:
|
Cashe-Control - поле директив, используемое процессами буферизации при инициализации цепочек запрос/ответ; |
|
Connection - поле, позволяющее клиенту и серверу определить опции, которые используются только в процессе соединения; |
|
Date - поле, содержащее время и дату; |
|
Via - поле, включающее информацию о протоколе передачи и трафике сообщения от клиента к серверу при запросе и от сервера к клиенту при ответе; |
|
Upgrade - поле, позволяющее программе пользователя определять, какие дополнительно протоколы она поддерживает и готова использовать, если сервер имеет возможность на переключение протоколов. Сервер должен использовать поле Upgade, содержащее сообщение 101 (“переключение протоколов”), для индикации включенных протоколов. |
/p>
Пример: Upgrade : HTTP/2.0, SHHTP/1.3, IRC/6.9 ,RTA/x11.
Поле заголовка запроса позволяет программе пользователя передать дополнительную информацию о запросе и о себе на сервер. Параметры поля заголовка используются как изменяемые модификаторы:
|
Accept - поле, которое может использоваться для определения множества медиатипов (media types), которые являются приемлемыми для ответа. Символ * используется для групп медиатипов, с символами */* используются все медиатипы, а “type/*” определяет все подтипы данного типа. Параметр диапазона q определяет значимость медиатипов в определенном диапазоне и определяет заинтересованность пользователя в конкретном медиатипе. По умолчанию q=1. В поле Accept, созданном клиентом НТТР/1.1, разделителем диапазона медиатипов от диапазона параметров является символ “:“. Сервер НТТР/1.1 должен корректно обрабатывать разделитель “;” , используемый в версии НТТР/1.0. |
Например, выражение “Accept: audio/* : q=0.2, audio/basic” может быть интерпретировано как “Я предпочитаю данные audio/basic, но пошлите мне любые аудио данные после того, как передадите 80% требуемых”. Если поле Accept отсутствует, то программа-пользователь запрашивает любые типы данных.
|
Поле Accept-Charset применяется для отображения символьной установки, используемой для запроса. Это поле позволяет программам клиента и сервера определить подмножество символьных кодов для устойчивой передачи данных. |
Пример: Accept-Charset : ISO-8859-5
Если поле Accept-Charset отсутствует, то могут использоваться любые символы. Иначе передаваемые символы должны соответствовать символьным установкам.
|
Поле Accept-Encoding содержит информацию об используемом методе уплотнения. |
|
Поле Accept-Language содержит информацию об используемом языке (En - английский; Da - датский и т.д.). |
Пример: Accept-Language : da ;
|
Поле Authorization может использоваться для передачи информации программой пользователя о самой себе. |
|
Поле From может содержать e-mail адрес Internet для пользователя, который контролирует запросы программы-пользователя. |
/p>
Пример: From : mastermail@w3.org.
|
Поле Host определяет номера портов и хостов - источников в Internet. Оно должно содержать сетевой адрес сервера или межсетевого шлюза в формате URI. Если не указывается номер порта, то по умолчанию принимается номер 80. |
Например, запрос к серверу < http: //www.w3.org/pub/WWW/>
должен включать : Get /pub/WWW/HTTP1.1
Host: www/w3/org.
|
Поле If-Modifided-Since используется совместно с методом Get для следующих целей: если запрашиваемый объект не был изменен со времени, указанного в поле, то копия объекта сервером передаваться не будет. |
|
Поле Referer позволяет программе клиента точно определить адрес (URI) источника. Это позволяет создать серверу внутренний список к ресурсам по интересам, регистрациям и т.д. |
|
Поле User-Agent содержит информацию об агенте пользователя. Это необходимо для определения статистики работы агента пользователя, для определения некорректной работы протоколов и автоматического распознавания агентов пользователей. |
|
Поле Max-Forward может использоваться с методом Trace для определения времени тайм-аута. |
Принято, что поле протокола, содержащее данные, называется “полем данных” или просто “данные”. Для НТТР понятие “поле данных” слишком узкое и не отражает настоящего предназначения. Поэтому введен термин “объект”, поскольку запрашиваться/передаваться могут не только данные, но и различная метаинформация, такая как изображения, аудиоинформация, мультипликация и т.д. Полный запрос и полный ответ cодержат объект, который состоит из заголовка и тела.
Заголовок объекта содержит различную информацию о теле объекта, а если тело объекта отсутствует, информацию об источнике, определенном в URI. Заголовок объекта содержит следующие поля:
|
Allow - поле содержит список установленных методов, поддерживаемых источником, определенном в URI. |
Пример : Allow: Get, Head, Put.
|
Content-Base - может быть использовано для спецификации базового URI с целью определения относительного URL в объекте. |
|
Content-Encoding - содержит информацию о типе кодирования, который был применен к источнику. |
|
Content-Language - поле содержит идентификатор языка, в формате которого передается информация. |
|
Content-Length - содержит размер объекта в десятичном виде. |
|
Content-Location - используется для определения адреса дополнительного источника, связанного с ссылкой в теле объекта. |
|
Content-Range - передается для определения размера блока сообщения, а также всей длины запрошенного/переданного объекта. |
/p>
Пример: HTTP/1.0 206 Partial content
DATE: Wed, 22 Feb 1997 16 : 00 : 00 GMT
LAST MODIFIED : Wed, 22 Feb 1997 15 : 50 : 00 GMT
CONTENT-RANGE: 21010 - 47021 / 47022
CONTENT-LENGHT: 26012
CONTENT-TYPE: IMAGE / GIF
|
Content-Type - содержит тип передаваемого объекта (тип метаинформации). |
|
Last-Modified - дата и время последней модификации объекта. |
|
Title - содержит название объекта. |
Пример: Title: HTTP - Протокол передачи гипертекстов.
|
Transfer-Encoding - содержит информацию о типе преобразования, который был применен к телу объекту для надежной передачи от источника к получателю. |
Тело объекта передается вместе с запросом или ответом в формате, определенном в полях заголовка сообщения. Тело объекта передается с запросом в том случае, если метод вызывается однажды.
Сообщение ответа, не зависимо от того, присутствует или нет тело объекта, зависит как от метода запроса, так и от кода состояния. Все ответы при использовании метода HEAD, а также ответы с кодами 1хх (информационные), 204 (“не содержит”) и 304 (“не изменен”) не должны содержать тело объекта. Все остальные ответы должны содержать тело объекта или значение поля Content-Length, установленное в 0.
После того, как сервер примет и проанализирует запрос от клиента, он посылает в формате НТТР ответное сообщение, которое имеет следующий вид:
Поле состояния (Status-Line) содержит версию протокола, код состояния (status-code) и связанные со значением кода пояснения.
Код состояния состоит из трехзначного десятичного кода, определяющего попытку определения и идентификации запроса. Код состояния используется автоматически, а пояснения предназначены для пользователя. Первая цифра кода определяет класс ответа. Последние две цифры определяют номер сообщения в классе. Всего определены пять классов:
|
1xx: информационный - запрос принят, процесс продолжается; |
|
2xx: успешное завершение - запрос был успешно принят, идентифицирован и обработан; |
|
3хх: переназначение - следующее действие должно быть обработано, чтобы завершить запрос; |
|
4хх: ошибка пользователя - запрос содержит неверный синтаксис или не может быть выполнен; |
|
5хх: ошибка сервера - сервер не может выполнить требуемый запрос. |
/p>
Все возможные значения кода состояния приведены ниже :
|
Код состояния (Status-Code) |
Пояснение (Reasone-Phrase) |
|
100 101 200 201 202 203 204 205 206 300 301 302 303 304 305 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 500 501 502 503 504 505 |
Продолжение Переключение протоколов Норма Принят Создан Не авторитетная информация Не содержит Сбросить содержание Частично содержит Множественный выбор Перемещен постоянно Перемещен временно Смотри другой Не изменен Используй посредника Неверный запрос Неизвестен Необходима оплата Запретный Не найден Метод не может быть разрешен Не доступен Требуется идентификация посредника Тайм-аут запроса Конфликт Послан Необходима длина Предварительная ошибка Тело запроса слишком велико URI запроса слишком велико Неподдерживаемый тип медиатипов Не применим Внутренняя ошибка сервера Не выполнено Ошибка межсетевого шлюза Служба не доступна Тайм-аут межсетевого шлюза Версия НТТР не поддерживается |
Основной заголовок, заголовок тела и тело объекта сообщения полного ответа идентичны соответствующим полям полного запроса.
Поле заголовка ответа позволяет серверу передавать дополнительную информацию об ответе, которая не может быть помещена в поле состояния и содержит сведения о сервере и возможности дальнейшего доступа к ресурсам, определенных в URI. Поле заголовка включает в себя:
|
Location (местоположение) - используется для перенаправления приема информации к источнику, отличному от указанного в URI для завершения запроса или определения нового источника. Если поле состояния имеет значение 201, то поле Location будет содержать тот новый ресурс, который был создан запросом. Если поле состояния имеет значение 3хх, то Location должно содержать URL приоритетного сервера для автоматического переадресования ресурса. |
|
Proxy-Authenticate - поле используется совместно с полем состояния, значение которого равно 407. Параметры поля состояния из вызовов показывают параметры и схему идентификации посредника по запросу URI. |
|
Public (для общего использования) - содержит список нестандартных методов, поддерживаемых сервером. Пример: Public: OPTIONS, MGET, MHEAD. |
|
Retry-After (обратись после) - поле используется совместно с полем состояния, имеющим код 503, для индикации того, как долго служба не будет доступна по запросу клиенту. Значение поля может быть представлено как дата в формате НТТР или время в секундах после окончания запроса. |
/p>
Пример : Retry-After : Wed , 14 Dec 1997 12 : 12 : 45 GMT
Retry-After : 180.
|
Server - поле содержит информацию о программном обеспечении, используемом сервером при обращении запроса. Пример : Server : Cern / 3.0 libwww / 2.17. |
|
WWW-Authenticate - поле использует код поля состояния, значение которого равно 407. Параметры поля состоят по крайней мере из одного вызова, который показывает параметры и схему(ы) идентификации посредника по запросу URI. |
Поле заголовка ответа может быть изменено/расширено только с измененной версией протокола. Неопределенные поля заголовков интерпретируются как тело объекта.
После установления соединения клиент НТТР посылает запрос. Запросы НТТР содержат методы доступа к объекту. Когда запрос будет послан, сервер имен начнет выполнять поиск хоста, указанного в URI запроса. После успешного завершения процедуры поиска начнется процесс установления соединения с сервером НТТР. Далее, в соответствии с методом запроса, сервер будет искать и готовить к передаче объекты, указанные в URI. Ответы сервера, помимо объекта, будут содержать коды состояния. Часто объекты содержат ссылки на другие объекты. Эти ссылки определяются с помощью синтаксиса языка гипертекстовых меток HTML. При инициализации метки автоматически формируется запрос к требуемому объекту, и алгоритм соединения и передачи объекта, описанный выше, повторяется снова.
Соглашения HTTP
Формат дата/время
Протокол НТТР поддерживает три различных формата представления информации о дате и времени:
|
Sun , 22 Feb 1997 13:15:45 GMT (здесь GMT - время по Гринвичу); |
|
Sunday , 22 - Feb - 97 13:15:45 GMT; |
|
Sun Feb 22 13:15:45 1997. |
Клиенты и серверы НТТР должны поддерживать все три формата, однако они должны создавать только первый формат для представления даты/времени в поле сообщения протокола НТТР.
Установка символов
Термин “установка символов” для НТТР подразумевает использования таблиц преобразования последовательности октетов в последовательность символов. Это определение позволяет использовать различные типы кодировок таблиц символов от самых простых, таких как US-ASCII, до комплексных таблиц, таких как ISO 2022.
Типы кодирования
Тип кодирования определяет способ преобразования объекта. Кодирование в основном используется для сжатия или криптографической защиты объекта доступа (информации). Тем самым обеспечивается семантическая защита сообщений и уменьшается объем передаваемой информации. Применяются следующие типы кодирования: gzip, x-gzip, compress, x-compress (gzip, compress соответствуют x-gzip, x-compress).
Кодирование gzip осуществляется программой GZIP. Этот формат соответствует кодированию Lempel-Ziv (LZ77) c 32-битовой проверочной последовательностью.
Кодирование compress осуществляется программой COMPRESS. Этот формат соответствует кодированию Lempel-Ziv-Welch (LZW).
| |
Служба WWW
World Wide Web (всемирная сеть, WWW или 3W) представляет собой информационную систему, базирующуюся на использовании гипертекста. Разработка системы WWW была начата Тимом Бернерс-Ли в 1989 г. Основная идея WWW состоит в объединении гипертекста с сетью Internet. Впервые WWW была реализована в центре ядерных исследований CERN (Женева).
Основу службы составляет сеть WWW-серверов, на которых размещены гипертекстовые документы, объединенные перекрестными ссылками. WWW- броузер (WWW-клиент) последовательно считывает документы с различных серверов. При этом части одного документа могут храниться на различных серверах. WWW-броузер самостоятельно анализирует гипертекстовый документ и формирует запросы на получение требуемого фрагмента с необходимого сервера. Таким образом, появляется возможность организовывать огромные хранилища структурированной информации, поиск и обновление которой осуществляется с минимальными затратами, кроме этого отсутствует необходимость в дублировании документов. Именно с началом использования службы WWW значительно упростился поиск и использование информации.
Основным форматом для представления гипертекстовых документов является HTML. Описание этого формата приведено ниже.
Для обмена информацией между WWW-серверами и клиентами используется протокол HTTP. <
Универсальный указатель идентификатора (URI)
Универсальный указатель идентификатора URI (Universal Resurse Identifiers) известен под разными наименованиями: адреса WWW, универсального указателя документа, универсального указателя идентификатора, а в конечном итоге является комбинацией Universal Resurse Locator (URL) и Universal Resurse Names (URN). Для НТТР URI является последовательностью символов, определяющих сетевые имена, расположение и различные характеристики сетевых ресурсов. Синтаксис URI достаточно прост и имеет следующий вид :
[ схема ] : // [ сетевой путь ] / [ компьютер ] [ ; параметры ] [ ? запрос ].
Первая часть URI содержит название схемы, т.е. название протокола, используя который, пользователь получит доступ к объекту. Вторая часть содержит полный адресный (сетевой) запрос к необходимому объекту с указанием необходимых параметров. Длина URI не должна превышать 255 байт, иначе сервер будет возвращать сообщение об ошибке.
<
Универсальный указатель ресурса (URL)
Поскольку URL является частным случаем URI, то синтаксис имеет идентичную структуру. URI позволяет задать определенным образом не только сетевой адрес компьютера, но и идентифицировать объекты на нем. Для доступа к объектам используются различные схемы (протоколы). В настоящее время активно используются следующие схемы доступа:
| Схема доступа | Описание | |
| file
ftp gopher http mailto news nntp prospero telnet wais | Имя файла в компьютере
Протокол передачи файлов Протокол gopher Протокол передачи гипертекста Адрес электронной почты Новости USENET Новости USENET по протоколу NNTP Служба каталогов prospero Сеанс telnet Сервер протокола wais |
Схема “http” используется для доступа к сетевым ресурсам с помощью протокола НТТР. Схема и семантика URL протокола НТТР имеет следующий вид:
http : // хост [ : порт ] / [ полный путь ],
где “хост” - действительное имя компьютера в Internet или его IP-адрес, а “порт” - номер приложения. Если порт не указан, то по умолчанию будет использоваться порт 80 (официальный порт протокола НТТР).
Формат блока данных
Блок данных Х.25 состоит из последовательности полей, показанной на . Поля Х.25 Уровня 3 образуют пакет Х.25; они состоят из заголовка и данных пользователя. Поля Х.25 Уровня 2 (LAPB) включают в себя поле управления уровнем блока данных и поле адресации, встроенный пакет Уровня 2 и проверочную последовательность блока данных (FCS).
Протокол определяет форматы собственно на трех уровня модели ЭМВОС:
 | уровне физического взаимодействия - протокол Х.25 Level-1; |
| уровне звена передачи данных - протокол Х.25 Level-2 (Lapb); |
| сетевом уровне - протокол Х.25 Level-3. |
Уровень 1 Х.25 использует протокол физического уровня Х.21 bis, который примерно эквивалентен RS-232-С. Протокол X.21 bis является производным от CCITT Recommendations V24 и V25, которые соответственно идентифицируют цепи межобмена и характеристики электрических сигналов интерфейса DTE/DCE. X.21 bis обеспечивает двухточечные связи, скорости до 19.2 Кб/сек и синхронную передачу с полным дублированием через четырех-проводной носитель. Максимальное расстояние между DTE и DCE -15 метров.
х битовое поле, которое указывает
Заголовок Х.25 Уровня 3 образован из "идентификатора универсального формата" - general format identifier - (GFI), "идентификатора логического канала"- logical channel identifier - (LCI) и "идентификатора типа пакета"- packet type identifier
- (PTI). GFI представляет собой 4- х битовое поле, которое указывает на универсальный формат заголовка пакета. LCI представляет собой 12-битовое поле, которое идентифицирует виртуальную цепь. Поле LCI является логически значимым в интерфейсе DTE/DCE. Другими словами, для организации виртуальной цепи PDN соединяет два логических канала, каждый из которых имеет независимый LCI, двумя интерфейсами DTE/DCE. Поле PTI идентифицирует один из 17 типов пакетов Х.25.
Поля адресации в пакетах установления обращения обеспечивают адреса DTE источника и пункта назначения. Они используются для организации виртуальных цепей, включающих передачу Х.25. Recommendation Х.121 CCITT определяет форматы адресов источника и пункта назначения. Адреса Х.121 (называемые также International Data Numbers, или IDN) имеют разную длину, которая может доходить до 14 десятичных знака. Четвертый байт в пакете организации обращения определяет длину адресов DTE источника и назначения. Первые четыре цифры IDN называются "код идентификации сети" - data network identification code - (DNIC). DNIC поделен на две части; первая часть (3 цифры) определяет страну, где находится PSN, вторая часть определяет саму PSN. Остальные цифры называются "номером национального терминала" - national terminal number - (NTN); они используются для идентификации определенного DTE в сети PSN. Формат адреса Х.121 представлен на рисунке.
Поля адресации, образующие адрес Х.121, необходимы только при использовании SVC, да и то только на время установления обращения. После того, как вызов организован, PSN использует поле LCI заголовка пакета данных для назначения конкретной виртуальную цепь отдаленному DTE.
Х.25 Уровня 3 использует три рабочих процедуры организации виртуальной цепи:
| Установления обращения |
| Передача данных |
| Раз'единение вызова |
Процедура передачи данных зависит от пакетов DATA. Х.25 Уровня 3 сегментирует и подвегает операции "обратный ассеблер" сообщения пользователя, если длина их превышает максимальный размер пакета для данной цепи. Каждому пакету DATA присваивается номер последовательности, поэтому можнo управлять неисправностями и потоком информации через интерфейс DTE/DCE.
Основы технологии
| Основные принципы |
| Формат блока данных |
Х.25 определяет характеристики телефонной сети для передачи данных. Чтобы начать связь, один компьютер обращается к другому с запросом о сеансе связи. Вызванный компьютер может принять или отклонить связь. Если вызов принят, то обе системы могут начать передачу информации с полным дублированием. Любая сторoнa может в любой момент прекратить связь.
Спецификация Х.25 определяет двухточечное взаимодействие между терминальным оборудованием (DTE) и оборудованием завершения действия информационной цепи (DCE). Устройства DTE (терминалы и главные вычислительные машины в аппаратуре пользователя) подключаются к устройствам DCE (модемы, коммутаторы пакетов и другие порты в сеть PDN, обычно расположенные в аппаратуре этой сети), которые соединяются с "коммутаторами переключения пакетов" (packet switching exchange) (PSE или просто switches) и другими DCE внутри PSN и, наконец, к другому устройству DTE. Взаимоотношения между об'ектами сети Х.25 показаны на рисунке.
DTE может быть терминалом, который не полностью реализует все функциональные возможности Х.25. Такие DTE подключаются к DCE через трансляционное устройство, называемое пакетный ассемблер/дизассемблер - packet assembler/disassembler - (РAD). Действие интерфейса терминал/PAD, услуги, предлагаемые PAD и взаимодействие между PAD и главной вычислительной машиной определены соответственно CCITT Recommendations X.28, X3 и Х.29.
Спецификация Х.25 составляет схемы Уровней 1-3 эталонной модели OSI. Уровень 3 Х.25 описывает форматы пакетов и процедуры обмена пакетами между равноправными об'ектами Уровня 3. Уровень 2 Х.25 реализован Протоколом Link Access Procedure, Balanced (LAPB). LAPB определяет кадрирование пакетов для звена DTE/DCE. Уровень 1 Х.25 определяет электрические и механические процедуры активации и дезактивации физической среды, соединяющей данные DTE и DCE. Это взаимоотношение представлено на рисунке. Необходимо отметить, что на Уровни 2 и 3 также ссылаются как на стандарты ISO - ISO 7776 (LAPB) и ISO 8208 (пакетный уровень Х.25).
Сквозная передача между устройствами DTE выполняется через двунаправленную связь, называемую виртуальной цепью. Виртуальные цепи позволяют осуществлять связь между различными элементами сети через любое число промежуточных узлов без назначения частей физической среды, что является характерным для физических цепей. Виртуальные цепи могут быть либо перманентными, либо коммутируемыми (временно). Перманентные виртуальные цепи обычно называют PVC; переключаемые виртуальные цепи- SVC. PVC обычно применяются для наиболее часто используемых передач данных, в то время как SVC применяются для спорадических передач данных. Уровень 3 Х.25 отвечает за сквозную передачу, включающую как PVC, так и SVC.
После того, как виртуальная цепь организована, DTE отсылает пакет на другой конец связи путем отправки его в DCE, используя соответствующую виртуальную цепь. DCE просматривает номер виртуальной цепи для определения маршрута этого пакета через сеть Х.25. Протокол Уровня 3 Х.25 осуществляет мультиплексную передачу между всеми DTE, которые обслуживает устройство DCE, расположенное в сети со стороны пункта назначения, в результате чего пакет доставлен к DTE пункта назначения.
Протокол Х.25 - сетевой уровень ITU-T
В середине-конце 1970 гг. потребовался определенный набор протоколов, чтобы обеспечить пользователям связность глобальной сети с общедоступными сетями передачи данных (PDN). Сети PDN, такие как TELENET и TYMNET, добились замечательного успеха, однако было ясно, что стандартизация протоколов еще больше увеличит число абонентов PDN за счет возросшей совместимости оборудования и более низких цен. Результатом последующих усилий по разработке в этом направлении была группа протоколов, самым популярным из которых является Х.25.
Протокол Х.25 (официально называемый CCITT Recommendation X.25 - "Рекомендация "Х.25 CCITT) был разработан компаниями общественных линий связи (в основном телефонными компаниями), а не каким-то отдельным коммерческим предприятием. Поэтому спецификация разработана так, чтобы обеспечить хорошую работоспособность независимо от типа системы пользователя или изготовителя. Пользователи заключают контракты с общедоступными сетями передачи данных, чтобы пользоваться их сетями с коммутацией пакетов (PSN), и им пред'является счет в зависимости от времени пользования PDN. Предлагаемые услуги (и взимаемая плата) регулируются Федеральной Комиссией по Связи (FCC).
Oдним из уникальных свойств Х.25 является его международный характер. Х.25 и связанными с ним протоколами управляет одно из агентств Организации Об'единненых Наций, называемое "Международный Союз по Телекоммуникациям (ITU). Комитет ITU, ответственный за передачу голоса и данных, называется Международным консультативным комитетом по телеграфии и телефонии (CCITT). Членами CCITT являются FCC, Европейские PTT, общедоступные сети передачи данных и множество компаний, занимающихся компьютерами и передачей данных. То, что Х.25 стал стандартом подлинно глобального значения, является прямым следствием присущих ему свойств.
Позднее протокол X.25 был включен в более полную модель взаимодействия открытых систем (рекомендации Х.200, Х.220), разработанную тем комитетом.
х битовое поле, которое указывает
Заголовок Х.25 Уровня 3 образован из "идентификатора универсального формата" - general format identifier - (GFI), "идентификатора логического канала"- logical channel identifier - (LCI) и "идентификатора типа пакета"- packet type identifier
- (PTI). GFI представляет собой 4- х битовое поле, которое указывает на универсальный формат заголовка пакета. LCI представляет собой 12-битовое поле, которое идентифицирует виртуальную цепь. Поле LCI является логически значимым в интерфейсе DTE/DCE. Другими словами, для организации виртуальной цепи PDN соединяет два логических канала, каждый из которых имеет независимый LCI, двумя интерфейсами DTE/DCE. Поле PTI идентифицирует один из 17 типов пакетов Х.25.
Поля адресации в пакетах установления обращения обеспечивают адреса DTE источника и пункта назначения. Они используются для организации виртуальных цепей, включающих передачу Х.25. Recommendation Х.121 CCITT определяет форматы адресов источника и пункта назначения. Адреса Х.121 (называемые также International Data Numbers, или IDN) имеют разную длину, которая может доходить до 14 десятичных знака. Четвертый байт в пакете организации обращения определяет длину адресов DTE источника и назначения. Первые четыре цифры IDN называются "код идентификации сети" - data network identification code - (DNIC). DNIC поделен на две части; первая часть (3 цифры) определяет страну, где находится PSN, вторая часть определяет саму PSN. Остальные цифры называются "номером национального терминала" - national terminal number - (NTN); они используются для идентификации определенного DTE в сети PSN. Формат адреса Х.121 представлен на Рис. 13-4.
Поля адресации, образующие адрес Х.121, необходимы только при использовании SVC, да и то только на время установления обращения. После того, как вызов организован, PSN использует поле LCI заголовка пакета данных для назначения конкретной виртуальную цепь отдаленному DTE.
Х.25 Уровня 3 использует три рабочих процедуры организации виртуальной цепи:
| Установления обращения |
| Передача данных |
| Раз'единение вызова |
Процедура передачи данных зависит от пакетов DATA. Х.25 Уровня 3 сегментирует и подвегает операции "обратный ассеблер" сообщения пользователя, если длина их превышает максимальный размер пакета для данной цепи. Каждому пакету DATA присваивается номер последовательности, поэтому можнo управлять неисправностями и потоком информации через интерфейс DTE/DCE.
Библиографическая справка
Протоколы Xerox Network Systems (XNS) разработаны корпорацией Xerox в конце 1970-начале 1980 гг. Они предназначены для использования в разнообразных средах передачи, процессорах и прикладных задачах офиса. Несколько протоколов XNS похожи на Протокол Internet (IP) и Протокол управления передачей (TCP), разработанных агентством DARPA для Министерства обороны США (DoD). Все протоколы XNS соответствуют основным целям проектирования эталонной модели OSI.
Благодаря своей доступности и раннему появлению на рынке, XNS был принят большинством компаний, использовавших локальные сети с момента их появления, в том числе компаниями Novell, Inc., Ungermann-Bass, Inc. (которая теперь является частью Tandem Computers) и 3Com Corporation. За время,прошедшее с тех пор, каждая из этих компаний внесла различные изменения в протоколы XNS. Novell дополнила их Протоколом доступа к услугам (Service access protocol - SAP), чтобы обеспечить об'явление о ресурсах, и модифицировала протоколы Уровня 3 OSI (которые Novell переименовала в Internetwork Packet Exchange - IPX - Oбмен межсетевыми пакетами) для работы в сетях IEEE 802.3, а не в сетях Ethernet. Ungermann-Bass модифицировала RIP для поддержания задержки, а также числа пересылок. Были также внесены другие незначительные изменения. С течением времени реализации XNS для об'единенных в сети РС стали более популярными, чем XNS в том виде, в котором они были первоначально разработаны компанией Xerox.
<
Доступ к среде XNS Xerox
Несмотря на то, что в документации XNS упоминаются X.25, Ethernet и HDLC, XNS не дает четкого определения того, что она называет протоколом уровня 0. Также, как и многие другие комплекты протоколов, XNS оставляет вопрос о протоколе доступа к носителю открытым, косвенным образом позволяя любому такому протоколу выполнять главную роль в транспортировке пакетов XNS через физический носитель. <
Протокол EP
Протокол неисправностей (Error Protocol - EP) может быть использован любым процессом клиента для уведомления другого процесса клиента о том, что в сети имеет место ошибка. Например, этот протокол используется в ситуациях, когда какая-нибудь реализация SPP распознала дублированный пакет. <
Протокол IDP
Протокол предназначен для организации межсетевого взаимодействия ЛВС. Использует дейтаграммный принцип обмена. Структура протокольного блока IDP приведена на рисунке. Назначение полей заголовка указано ниже.
|
Протокол IDP |
||||||||||||||||
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
0 |
Контрольная сумма |
|||||||||||||||
2 |
Общая длина пакета |
|||||||||||||||
4 |
Счетчик пройд. мостов |
Тип пакета |
||||||||||||||
6 8 |
Номер сети получателя |
|||||||||||||||
10 12 14 |
Адрес станции получателя |
|||||||||||||||
16 |
Сокет программы-получателя |
|||||||||||||||
18 20 |
Номер сети отправителя |
|||||||||||||||
22 24 26 |
Адрес станции отправителя |
|||||||||||||||
28 |
Сокет программы-отправителя |
|||||||||||||||
30 . . . |
Данные |
|||||||||||||||
 | Для данного протокола поле “Общая длина пакета” определяет длину протокольного блока, включая заголовок и данные. |
| Поле “Тип пакета” определяет тип следующего протокола. |
| Поля “Номер сети получателя (отправителя)” определяют номер ЛВС в рамках одной сети. |
| Поля “Адрес станции получателя (отправителя)” соответствуют МАС-адресам адаптеров доступа к ЛВС получателя или отправителя соответственно. Если дейтаграмма должна быть отправлена сразу всем пользователям одной сети, то поле адреса получателя имеет значение FFFFFFFFFFFF. |
| Поля “Сокет программы получателя (отправителя)” определяют тип обслуживаемого приложения (программы). Некоторые значения зарезервированы для использования определенными программами. |
XNS поддерживает пакеты с однопунктовой (из одного пункта в другой пункт), многопунктовой и широковещательной адресацией. Многопунктовые и широковещательные адреса далее делятся на 2 типа: прямые (directed) и глобальные (global). Прямые многопунктовые адреса доставляют пакеты членам группы многопунктовой адресации данной сети, заданной в адресе сети назначения с многопунктовой адресацией. Прямые широковещательные адреса доставляют пакеты всем членам заданной сети. Глобальные многопунктовые адреса доставляют пакеты всем членам данной группы в пределах всей об'единенной сети, в то время как глобальные широковещательные адреса доставляют пакеты во все адреса об'единенной сети. Один бит в номере хоста обозначает отдельный адрес в противовес многопунктовому адресу. Все единицы в поле хоста обозначают широковещательный адрес.
Протокол PEP
Протокол обмена пакетами (Packet Exchange Protocol - PEP) является протоколом типа запрос-ответ, предназначенным обеспечивать надежность, которая больше надежности простых услуг дейтаграмм (например, таких, которые обеспечивает IDP), но меньше надежности SPP. По своим функциональным возможностям РЕР аналогичен Протоколу дейтаграмм пользователя (UDP) из комплекта протоколов Internet. PEP базируется на принципе одного пакета, обеспечивая повторные передачи, но не обеспечивая выявление дублированных пакетов. Он полезен для прикладных задач, в которых транзакции запрос-ответ являются идемпотентными (повторяемыми без повреждения контекста), или в которых надежная передача выполняется на другом уровне.
Протокол RIP
Для маршрутизации пакетов в об'единенной сети XNS использует схему динамической маршрутизации, называемую Протоколом информации маршрутизации (RIP). В настоящее время RIP является наиболее широко используемым Протоколом внутренних роутеров (interior gateway protocol - IGP) в сообществе Internet-среде международной сети, обеспечивющей связность практически со всеми университетами и научно- исследовательскими институтами, а также многими коммерческими организациями в США. <
Протокол SPP
Протокол предназначен для обеспечения надежной передачи данных между пользователями на транспортном уровне. Протокол работает в режиме с установлением соединения. Он обеспечивает подтверждение переданных данных, сохранение порядка их следования и передачу массивов данных любого объема. Структура протокольного блока SPP представлена на рисунке. Ниже указано назначение полей заголовка.
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
||
0 |
Управл. потоком данных |
Тип данных |
|||||||||||||||
2 |
Идентификатор канала отправителя |
||||||||||||||||
4 |
Идентификатор канала получателя |
||||||||||||||||
6 |
Счетчик переданных пакетов |
||||||||||||||||
8 |
Номер следующего пакета |
||||||||||||||||
10 |
Количество буферов для приема |
||||||||||||||||
12 . . . |
Данные |
||||||||||||||||
| Поле “Тип данных” определяет тип передаваемых данных. Значения от 00 до FD игнорируются драйвером SPX и могут использоваться программой произвольно. Значение FE идентифицирует запрос разъединения. Значение FF идентифицирует подтверждение разъединения. |
| Поля “Идентификатор канала отправителя (получателя)” идентифицируют канал обмена в драйвере. Драйвер может организовывать одновременно несколько каналов обмена по каждому сокету. |
| Поля счетчиков определяют номера переданных и подтвержденных пакетов. Поле “Количество буферов для приема” указывает, сколько пакетов может в данный момент времени принять драйвер. |
| Формат поля “Управление потоком данных” приведен в таблице. |
Номер бита |
Назначение |
7 |
System Packet. Признак системных пакетов. При передаче данных установлен в 0. |
6 |
Бит используется драйвером. Назначение не определено. |
5 |
Atention. Этот бит игнорируется драйвером и передается в неизменном виде программе. |
4, 3, 2, 1, 0 |
End-of-Message. Этот бит может использоваться программой для сигнализации окончания передачи данных. Драйвер передает этот бит в неизменном виде. |
Длина пакетов SPP не может быть больше 576 байтов. Процессы клиента могут согласовывать использование различных размеров пакетов во время организации соединения, однако SPP не определяет характер такого согласования.
Протоколы архитектур XNS Xerox
Несмотря на то, что они имеют общие цели проектирования, концепция XNS о иерархии протоколов несколько отличается от той концепции, которую предлагает эталонная модель OSI. На рисунке показано приблизительное сравнение XNS и эталонной модели OSI.
Как видно из рисунка, Xerox обеспечивает 5-уровневую модель передачи пакетов. Уровень 0, который отвечает за доступ к каналу и манипуляцию потока битов, примерно соответствует Уровням 1 и 2 OSI. Уровень 1 примерно соответствует той части Уровня 3 OSI, которая относится к сетевому трафику. Уровень 2 примерно соответствует части Уровня 3, которая связана с маршрутизацией в об'единенной сети, и Уровню 4 OSI, который занимается связью внутри отдельных процессов. Уровни 3 и 4 примерно соответствуют двум верхним уровням модели OSI, которые заняты структурированием данных, взаимодействием между отдельными процессами и прикладными задачами. XNS не имеет протокола, соответствующего Уровню 5 OSI (сеансовый уровень).
Перечень протоколов сетевой архитектуры XNS XEROX приведен в таблице. Схема взаимодействий приведена здесь.
| Обозначение | Название протокола (анг.) | Назначение протокола |
| SPP | Sequence Packet Protocol | Транспортный протокол, ориентированный на соединение |
| PEP | Packet Exchange Protocol | Транспортный протокол, не ориентированный на соединение |
| RIP | Routing Information Protocol | Протокол обмена маршрутной информацией |
| Error Protocol | Протокол оповещения об ошибках | |
| Echo Protocol | Протокол проверки доступности сетевых объектов | |
| IDP | Internetwork Datagram Protocol | Сетевой протокол |
| Filing | ||
| Электронная почта | ||
| Printing | Доступ к удаленным принтерам | |
| Virtual Terminal | Виртуальный терминал | |
| GAP | Gateway Access Protocol | Протокол доступа и управления маршрутизаторами |
| XNS
Courier |
Message Stream Object Stream Block Stream |
Протоколы представительского уровня |
| XNS
Courier |
Pulk Data Transfer Protocol | Протокол сеансового уровня |
Протоколы высших уровней XNS Xerox
XNS предлагает несколько протоколов высших уровней. Протокол "Печатание" (Printing) обеспечивает услуги принтера. Протокол "Ведение картотеки" (Filing) обеспечивает услуги доступа к файлам. Протокол "Очистка (Сlearinghouse) обеспечивает услуги, связанные с присвоением имени. Каждый из этих протоколов работает в дополнение к протоколу "Курьер" (Сourier), который обеспечивает соглашения для структурирования данных и взаимодействия процессов.
XNS также определяет протоколы уровня четыре. Это протоколы прикладного уровня, но поскольку они имеют мало общего с фактическими функциями связи, в спецификации XNS нет каких-либо определений по существу.
И наконец, протокол "Эхо" (Echo Protocol) используется для тестирования надежности узлов сети XNS. Он используется для поддержки таких функций, как функции, обеспечиваемые командой ping, которую можно встретить в Unix и других средах. Спецификация XNS описывает протокол "Эхо" как протокол уровня два. <
Схема протоколов архитектуры XNS Xerox
На рисунке приведены схема взаимодействия протоколов сетевой архитектуры XNS Xerox и возможные схемы взаимодействия с другими сетевыми архитектурами.
<
