TCP/IP
Стек протоколов TCP/IP (англ. Transmission Control Protocol/Internet Protocol) — собирательное название для сетевых протоколов разных уровней, используемых в сетях. Слово «стек» (англ. stack, стопка) подразумевает, что протокол TCP работает поверх IP.
В модели OSI данный стек занимает (реализует) все уровни и делится сам на 4 уровня: прикладной, транспортный, межсетевой, уровень доступа к сети (в OSI это уровни — физический, канальный и частично сетевой). На стеке протоколов TCP/IP построено всё взаимодействие пользователей в сети, от программной оболочки до канального уровня модели OSI. По сути это база, на которой завязано всё взаимодействие. При этом стек является независимым от физической среды передачи данных.
Уровни стека TCP/IP
HTTP (англ. HyperText Transfer Protocol — «протокол передачи гипертекста») — протокол прикладного уровня передачи данных (изначально - в виде гипертекстовых документов). Основой HTTP является технология «клиент-сервер», то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом.
HTTP в настоящее время повсеместно используется во Всемирной паутине для получения информации с веб-сайтов. В 2006 году в Северной Америке доля HTTP-трафика превысила долю P2P-сетей и составила 46 %, из которых почти половина — это передача потокового видео и звука[1].
HTTP используется также в качестве «транспорта» для других протоколов прикладного уровня, таких как SOAP, WebDAV.
Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (англ. Uniform Resource Identifier) в запросе клиента. Обычно такими ресурсами являются хранящиеся на сервере файлы, но ими могут быть логические объекты или что-то абстрактное. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т. д. Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.
HTTP — протокол прикладного уровня, аналогичными ему являются FTP и SMTP. Обмен сообщениями идёт по обыкновенной схеме «запрос-ответ». Для идентификации ресурсов HTTP использует глобальные URI. В отличие от многих других протоколов, HTTP не сохраняет своего состояния. Это означает отсутствие сохранения промежуточного состояния между парами «запрос-ответ». Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами. Браузер, посылающий запросы, может отслеживать задержки ответов. Сервер может хранить IP-адреса и заголовки запросов последних клиентов. Однако сам протокол не осведомлён о предыдущих запросах и ответах, в нём не предусмотрена внутренняя поддержка состояния, к нему не предъявляются такие требования.
SMTP (англ. Simple Mail Transfer Protocol — простой протокол передачи почты) — это сетевой протокол, предназначенный для передачи электронной почты в сетях TCP/IP.
SMTP используется для отправки почты от пользователей к серверам и между серверами для дальнейшей пересылки к получателю. Для приёма почты почтовый клиент должен использовать протоколы POP3 или IMAP.
Чтобы доставить сообщение до адресата, необходимо переслать его почтовому серверу домена, в котором находится адресат. Для этого обычно используется запись типа MX (англ. Mail eXchange — обмен почтой) системы DNS. Если MX запись отсутствует, то для тех же целей может быть использована запись типа A. Некоторые современные реализации SMTP-серверов (например, Exim[1]) для определения сервера, обслуживающего почту в домене адресата, также могут задействовать SRV-запись (RFC 2782).
Широкое распространение SMTP получил в начале 1980-х годов. До него использовался протокол UUCP, который требовал от отправителя знания полного маршрута до получателя и явного указания этого маршрута в адресе получателя, либо наличия прямого коммутируемого или постоянного соединения между компьютерами отправителя и получателя.
Sendmail был одним из первых (если не первым) агентом отправки сообщений, который начал работать с SMTP. В настоящее время протокол SMTP является стандартным для электронной почты и его используют все клиенты и серверы.
Протокол был разработан для передачи только текста в кодировке ASCII, кроме того, первые спецификации требовали обнуления старшего бита каждого передаваемого байта. Это не даёт возможности отсылать текст на национальных языках (например, кириллице), а также отправлять двоичные файлы (такие как изображения, видеофайлы, программы или архивы). Для снятия этого ограничения был разработан стандарт MIME, который описывает способ преобразования двоичных файлов в текстовые. В настоящее время большинство серверов поддерживают 8BITMIME, позволяющий отправлять двоичные файлы так же просто, как текст.
Сервер SMTP — это конечный автомат с внутренним состоянием. Клиент передает на сервер строку команда<пробел>параметры<перевод строки>. Сервер отвечает на каждую команду строкой, содержащей код ответа и текстовое сообщение, отделенное пробелом. Код ответа — число от 100 до 999, представленное в виде строки, трактующийся следующим образом:
* 2ХХ — команда успешно выполнена
* 3XX — ожидаются дополнительные данные от клиента
* 4ХХ — временная ошибка, клиент должен произвести следующую попытку через некоторое время
* 5ХХ — неустранимая ошибка
Текстовая часть ответа носит справочный характер и предназначен для человека, а не программы.
ESMTP — расширяемый протокол, в отличие от SMTP. При установлении соединения сервер объявляет о наборе поддерживаемых расширений (в качестве ответа на команду EHLO). Соответствующие расширения могут быть использованы клиентом при работе. Необходимо помнить, что если сессия начинается с команды HELO (используемой в «классическом» SMTP, RFC 821), то список расширений выводиться не будет.
Безопасность SMTP и спам
Изначально SMTP не поддерживал единой схемы авторизации. В результате этого спам стал практически неразрешимой проблемой, так как было невозможно определить, кто на самом деле является отправителем сообщения — фактически можно отправить письмо от имени любого человека. В настоящее время производятся попытки решить эту проблему при помощи спецификаций SPF, Sender ID, Yahoo Domain Keys. Единой спецификации на настоящий момент не существует.
SNMP (англ. Simple Network Management Protocol — простой протокол управления сетью) — это протокол управления сетями связи на основе архитектуры TCP/IP.
На основе концепции TMN в 1980—1990 гг. различными органами стандартизации был выработан ряд протоколов управления сетями передачи данных с различным спектром реализации функций TMN. К одному из типов таких протоколов управления относится SNMP.
Также это технология, призванная обеспечить управление и контроль за устройствами и приложениями в сети связи путём обмена управляющей информацией между агентами, располагающимися на сетевых устройствах, и менеджерами, расположенными на станциях управления. SNMP определяет сеть как совокупность сетевых управляющих станций и элементов сети (главные машины, шлюзы и маршрутизаторы, терминальные серверы), которые совместно обеспечивают административные связи между сетевыми управляющими станциями и сетевыми агентами.
Обычно при использовании SNMP присутствуют управляемые и управляющие системы. В состав управляемой системы входит компонент, называемый агентом, который отправляет отчёты управляющей системе. По существу SNMP агенты передают управленческую информацию на управляющие системы как переменные (такие как «свободная память», «имя системы», «количество работающих процессов»).
Управляющая система может получить информацию через операции протокола GET, GETNEXT и GETBULK. Агент может самостоятельно без запроса отправить данные, используя операцию протокола TRAP или INFORM. Управляющие системы могут также отправлять конфигурационные обновления или контролирующие запросы, используя операцию SET для непосредственного управления системой. Операции конфигурирования и управления используются только тогда, когда нужны изменения в сетевой инфраструктуре. Операции мониторинга обычно выполняются на регулярной основе.
Переменные, доступные через SNMP, организованы в иерархии. Эти иерархии и другие метаданные (такие, как тип и описание переменной) описываются Базами Управляющей Информации (англ. Management Information Bases (MIBs)).
FTP (англ. File Transfer Protocol — протокол передачи файлов) — протокол, предназначенный для передачи файлов в компьютерных сетях. FTP позволяет подключаться к серверам FTP, просматривать содержимое каталогов и загружать файлы с сервера или на сервер; кроме того, возможен режим передачи файлов между серверами (см. FXP).
FTP является одним из старейших прикладных протоколов, появившимся задолго до HTTP, в 1971 году. До начала 90-х годов на долю FTP приходилось около половины трафика в сети Интернет[источник не указан 20 дней]. Он и сегодня широко используется для распространения ПО и доступа к удалённым хостам.
Протокол FTP относится к протоколам прикладного уровня и для передачи данных использует транспортный протокол TCP. Команды и данные, в отличие от большинства других протоколов передаются по разным портам. Порт 20 используется для передачи данных, порт 21 для передачи команд.
Протокол не шифруется, при аутентификации передаёт логин и пароль открытым текстом. Если злоумышленник находится в одном сегменте сети с пользователем FTP, то, используя сниффер, он может перехватить логин и пароль пользователя, или, при наличии специального ПО, получать передаваемые по FTP файлы без авторизации. Чтобы предотвратить перехват трафика, необходимо использовать протокол шифрования данных SSL, который поддерживается многими современными FTP-серверами и некоторыми FTP-клиентами.
TELNET (англ. TELecommunication NETwork) — сетевой протокол для реализации текстового интерфейса по сети (в современной форме — при помощи транспорта TCP). Название «telnet» имеют также некоторые утилиты, реализующие клиентскую часть протокола.
Назначение протокола TELNET в предоставлении достаточно общего, двунаправленного, восьми битного байт ориентированного средства связи. Его основная задача заключается в том, чтобы позволить терминальным устройствам и терминальным процессам взаимодействовать друг с другом. Предполагается, что этот протокол может быть использован для связи вида терминал-терминал ("связывание") или для связи процесс-процесс ("распределенные вычисления").
Соединение TELNET - это TCP соединение, используемое для передачи данных, с различной управляющей информацией.
Протокол TELNET базируется на трех основных идеях: первая, концепция "Виртуального Сетевого Терминала" (англ. Network Virtual Terminal, NVT); вторая, принцип оговоренных опций; третья, симметричный вид терминалов и процессов.
1. Когда устанавливается TELNET соединение, предполагается, что на каждом конце соединения порождается и завершается "Виртуальный Сетевой Терминал" или ВСТ. ВСТ - это воображаемое устройство которое предоставляет стандартное, доступное через cеть, промежуточное представление классического терминала. Это устраняет необходимость в "серверном" и "клиентском" узлах для хранения информации о характеристиках каждого терминала и договоренностей о взаимодействии. Все узлы, как клиентский, так и серверный, отображают свои локальные характеристики устройства с тем, чтобы выступать в сети как ВСТ, и каждый мог принять похожее отображение с другой стороны. ВСТ предназначен для сведения баланса между чрезмерным ограничением и чрезмерными возможностями.
Примечание: "Пользовательский" хост - это обычно хост с привязанным к нему физическим терминалом, а "серверный" хост - это обычно хост предоставляющий некий сервис. Как альтернативную точку зрения, можно рассматривать случай когда соединяются равные хосты: терминал-терминал или процесс-процесс. Таким образом будем считать "пользовательским" хостом тот хост который инициирует соединение.
2. Принцип оговоренных опций охватывает тот факт, что многие хосты скорее всего будут хотеть предоставить дополнительные сервисы до или после их доступности в ВСТ, и многие пользователи захотят иметь сложные терминалы с элементами изысканности, вместо минимальных, для получения таких дополнительных сервисов. Независимые от, но структурированные в TELNET протоколе различные "опции" санкционированы и могут быть использованы с "DO, DON'T, WILL, WON'T" структурой (обсуждается ниже) для того, чтобы позволить пользователю и серверу сходиться в использовании более продуманного (или отличного) набора соглашений для их TELNET соединения. Такие опции включают изменение набора символов, режима эха, и т.д.
Базовая стратегия для налаживания использования опций - это на одной из сторон (или на обоих) инициировать запрос: будет ли определенная опция иметь какой либо эффект. Другая сторона может либо принять, либо отвергнуть запрос. Если запрос принимается, то опция немедленно вступает в силу; если же опция отвергается, то связанный аспект соединения остается как специфицировано для ВСТ. Очевидно, что сторона может всегда отвергать запрос на включение, и никогда не должна отвергать запрос на отключение некоторой опции начиная с момента когда стороны договорились о поддержке ВСТ.
Синтаксис оговоренной опции должен быть таким, чтобы если обе стороны запросят одновременно опцию, то каждый будет рассматривать запрос с другой стороны как положительное подтверждение этой опции.
3. Симметричность синтаксиса согласования может потенциально привести к бесконечному циклу согласования - когда каждая сторона видит входящие команды не подтверждает их, но для подтверждения посылает новый запрос. Для предотвращения таких циклов, необходимо придерживаться следующих правил:
* Стороны могут запрашивать только изменение статуса опции; т.е. сторона может не посылать "запрос" только для того, чтобы сообщить, что данная опция поддерживается.
* Если сторона получает что-то, что интерпретируется как запрос переключения в некоторый режим в котором эта сторона уже находится, то на такой запрос не нужно отправлять подтверждения.
* Всякий раз, когда одна сторона отправляет команду опции на другую сторону, не важно запрашивая или подтверждая, и использование опции должно иметь какой либо эффект на обработку данных, отсылаемых первой стороной второй стороне, то команда опции должна быть вставлена в потоке данных в том месте, с которого желательно, чтобы опция вступила в силу. (Следует отметить, что пройдет некоторое время между передачей запроса и получением подтверждения, и оно может быть отрицательным. Таким образом, хост может буферизовать данные, после отправки запроса опции и до получения ответа с принятием или отвержением опции, для того, чтобы скрыть "период неопределенности" от пользователя.)
Вероятно, что сразу после установки TELNET соединения, запросы опций будут шквалом передаваться в обоих направлениях соединения, из-за того, что каждая сторона будет пытаться получить наилучший сервис от другой стороны. Кроме того, опции могут быть использованы для динамического изменения характеристик соединения с тем, чтобы соответствовать изменяющимся локальным условиям. Например, ВСТ, как будет описано ниже, использует дисциплину передачи, хорошо подходящую для многих приложений "строка за раз" (таких как BASIC), но плохо подходит для приложений "символ за раз" (таких как NLS). Сервер мог бы выделить дополнительное процессорное время требуемое для дисциплины "символ за раз" если это подходит для локального процесса и договориться о соответствующей опции. Хотя, вместо того, чтобы надолго обременяться дополнительной тратой процессорного времени, можно переключиться (т.е. договориться) вернуться назад к ВСТ, когда детальный контроль больше не требуется.
Возможно что запросы, инициированные процессами, будут способствовать незаконченному циклу запроса, в случае когда процесс отвечает отказом на повторный запрос опции. Для исключения такой ситуации отклоненные запросы не должны быть повторены, пока что либо не измениться. Операционно, это может означать, что процесс начал выполнять другую программу или пользователь дал другую команду, или что либо случилось в контексте данного процесса или опции. Необходимо принять за правило то, что повторный запрос может быть послан только как результат более поздней информации с другой стороны или в случае локального вмешательства человека.
Проектировщики опции не должны себя чувствовать стесненными несколько ограниченным синтаксисом для оговоренной опции. Смысл простого синтаксиса состоит в том, чтобы упростить принятие опции. Если некоторая специфическая опция требует более сложной структуры согласований чем имеющаяся в "DO, DON'T, WILL, WON'T", то необходимо сначала договориться через существующую структуру согласований, а после того, как обе стороны удостоверятся в понимании этой опции, использовать свободно более экзотический синтаксис. Например, одна из сторон могла бы послать запрос на изменение (установку) длинны строки. Если он принимается, то может быть использован отличный от базового синтаксис для того, чтобы фактически договориться о длине строки; такие "под-согласования" могли бы включать поля для минимально, максимально и желательных длин строки. Важно то, что такие расширенные согласования никогда не должны начинаться, пока "стандартные" переговоры не привели к тому, что обе стороны могут понимать расширенный синтаксис.
В итоге, WILL XXX посылается одной из двух сторон, для того чтобы показать желание (предложение) стороны исполнять опцию XXX, DO XXX и DON'T XXX являются подтверждением и отвержением опции XXX соответственно, на запрос WILL XXX; аналогично, DO XXX отправляется для того, чтобы показать желание другой стороны (т.е. получателя DO) начать исполнять опцию XXX, WILL XXX и WON'T XXX являются подтверждением и отвержением опции XXX соответственно, на запрос DO XXX. Так как ВСТ - это то, что остается когда никакие опции не включены, ответы DON'T и WON'T гарантируют что соединение останется в состоянии которым обе стороны могут управлять. Таким образом, все хосты могут реализовать свои TELNET процессы так, чтобы они вообще не знали об опциях которые не поддерживаются, просто возвращая отвержение (т.е. отказываясь от опции) на любой запрос опции, которую данный процесс не может понять.
Протокол TELNET был сделан максимально симметричным по отношению к связке пользователь-сервер, для того, чтобы он легко и естественно покрывал случаи пользователь-пользователь и сервер-сервер. Желательно, но не обязательно, чтобы опции сохраняли этот принцип. В любом случае явно признается, что симметрия - это принцип, а не правило.
Сопутствующий документ "TELNET Option Specifications" предназначен для того, чтобы черпать из него информацию о процедуре написания новых опций.
Виртуальный Сетевой Терминал (ВСТ) является двунаправленным символьным устройством. У ВСТ есть принтер и клавиатура. Принтер отвечает за входящие данные, а клавиатура производит исходящие данные, которые передаются по TELNET соединению и если необходимо "эхо" - то эти данные так же передаются и на принтер ВСТ. Предполагается, что "эхо" не будет передаваться по сети (хотя существуют опции, которые позволяют включать "удаленный" режим эха операции, но хост не обязан поддерживать эту опцию). Набор символов - это семибитовый USASCII в восьмиразрядном поле, кроме изменений описанных в данном документе. Любое преобразование кодировки и анализ времени - это локальные проблемы и не затрагивают ВСТ.
Передача данных
Хотя сетевому TELNET подключению свойственен полный дуплекс, ВСТ должен рассматриваться как полудуплексное устройство, работающее в буферизированном строковом режиме. Таким образом пока стороны не договорились об опциях, следующие условия должны выполняться по умолчанию для передачи данных по TELNET соединению:
1. Насколько позволяет локальный размер буфера, данные должны накапливаться на том хосте, где они вводятся, до тех пор пока не будет готова к передаче полная строка данных или пока не будет подан явный локальный сигнал к передаче. Этот сигнал может быть сгенерирован процессом или человеком.
Причиной этого правила является высокая стоимость обработки входящих сетевых прерываний для некоторых хостов, а так же заданное спецификацией ВСТ "эхо" которое не должно передаваться через cеть. Таким образом кажется разумным буферизовать некоторое количество данных на стороне их источника. Многие системы предпринимают некоторые действия по обработке в конце каждой входящей строки (например, устройства построчной печати) и таким образом передача данных должна быть инициирована в конце строки. С другой стороны, пользователю или процессу может иногда понадобиться передать данные, которые не заканчиваются переводом строки и поэтому необходимо предусмотреть методы, которыми можно передать все буферизированные локальные данные немедленно.
2. Когда процесс завершил отправку данных на принтер ВСТ и не имеет никакого очередного ввода с клавиатуры ВСТ для дальнейшей обработки (т.е., в случае когда процесс на одном конце TELNET соединения не может продолжить без входящих данных с другой стороны) он должен передать команду Go Ahead (GA).
Это правило не является обязательным и не требует, чтобы команда GA отправлялась в конце каждой строки, так как серверы обычно не требуют специального сигнала (в дополнение к концу строки или другим локально определенным символам) чтобы начать обработку. Правильнее будет сказать, что команда TELNET GA сделана, чтобы помочь локальному компьютеру пользователя управлять физическим полудуплексным терминалом (например, IBM 2741) у которого есть "блокируемая" клавиатура. Описание этого терминала может помочь в понимании правильного использования команды GA.
Соединение терминал-компьютер всегда находится под контролем пользователя или компьютера. Ни один не может в одностороннем порядке захватить контроль над другим. На стороне терминала аппаратные средства реализованы так, чтобы отдавать контроль всякий раз, когда "строка" закончена (т.е. когда клавиша "конец строки" нажата пользователем). И когда это происходит, присоединенный (локальный) компьютер обрабатывая входные данные, решает, должен ли генерироваться вывод и если не должен, возвращает контроль терминалу. Если вывод должен генерироваться, то контроль сохраняется за компьютером пока все данные не будут переданы.
Трудности использования терминала такого типа по сети очевидны. "Локальный" компьютер более не в состоянии решить, сохранять ли контроль или нет после того, как был обнаружен сигнал конца строки; это решение может быть принято только "удаленным" компьютером, который обрабатывает данные. Поэтому команда TELNET GA обеспечивает механизм, посредством которого "удаленный" (сервер) компьютер может сообщить "локальному" (пользователю) компьютеру, что настало время передачи управления пользователю терминала. Это должно быть передано тогда и только тогда, когда пользователь должен контролировать терминал. Отметим, что преждевременная отправка команды GA, может привести к блокированию вывода, так как пользователь, вероятно, будет предполагать, что передающая система сделала паузу и поэтому он вряд ли введет перевод строки вручную.
Вышесказанное, конечно, не относится к направлению соединения пользователь-сервер. В этом направлении, GA можно отправить в любой время, но эта команда в этом направлении никогда не должна посылаться. Кроме того, если TELNET соединение используется для коммуникации типа процесс-процесс, то команду GA нельзя отправлять ни в одном из направлений. И в заключении, для соединения терминал-терминал, команда GA может не потребоваться в одном или обоих направлениях. Если хост планирует поддерживать соединение типа терминал-терминал, предполагается, что такой хост предоставит пользователю возможность вручную сообщить, когда нужно отправить команду GA; это требование не является обязательным для реализующего сторону типа "процесс".
Отметим, что симметричная модель TELNET требует, по крайней мере концептуально, чтобы ВСТ присутствовал на каждом конце TELNET соединения.
Стандартное представление управляющих функций
Как уже говорилось во Введении к этому документу, основная цель протокола TELNET - это обеспечить стандартный сетевой интерфейс терминальным устройствам и терминал-ориентированным процессам. Ранний опыт с этим типом соединения показал, что определенные функции осуществимы для большинства серверов, а вот методы вызова этих функций достаточно широко различаются. Для человека, который взаимодействует с несколькими серверными системами, эти отличия представляют достаточно большое неудобство. Поэтому ниже будет приведено стандартное представление для пяти функций. Эти стандартные представления являются стандартом, но не требуются в обязательном порядке (за исключением функции Interrupt Process (IP), которая может понадобиться другим протоколам, которые используют TELNET); то есть система, которая не предоставляет функцию локальным пользователям не должна предоставлять ее и сетевым пользователям и может обрабатывать стандартное представление для функции как пустую команду (No-operation). С другой стороны, система, которая предоставляет функцию локальному пользователю, обязана предоставлять ту же самую функцию и сетевому пользователю, который передает стандартное представление для функции.
Interrupt Process (IP)
Многие системы предоставляют функцию которая приостанавливает, прерывает, аварийно прекращает или обрывает деятельность пользовательского процесса. Эта функция часто используется, когда пользователь полагает, что его процесс находится в бесконечном цикле или когда был активизирован нежелательный процесс. IP - это стандартное представление для вызова этой функции. Необходимо отметить, что IP может потребоваться другим протоколам, которые используют TELNET, и поэтому эта функция должна быть реализована, если такие протоколы поддерживаются реализацией.
Abort Output (AO)
Многие системы предоставляют функцию, которая позволяет процессу, который генерирует вывод, завершаться (или достигнуть той же самой точки останова, которой он бы достиг, если бы добрался до завершения), но без отправки вывода на пользовательский терминал. Затем, эта функция обычно очищает любой уже произведенный вывод, но еще фактически не напечатанный (или отображенный) на терминале пользователя. AO - это стандартное представление для того, чтобы вызвать эту функцию. Например, некоторая подсистема могла бы принять команду пользователя, послать длинную текстовую строку на терминал пользователя как ответ, и наконец сообщить о готовности принять следующую команду, посылая символ "prompt" (упреждая его ) на пользовательский терминал. Если бы AO была получена во время передачи текстовой строки, то реализация должна былв бы подавить остаток текстовой строки, но передать символ prompt упреждающие. (Это отличается от действия, которое могло быть предпринято, при получении IP; IP мог бы вызвать подавление текстовой строки и выход из подсистемы.)
Следует отметить, что серверные системы, которые предоставляют эту функцию должны иметь в виду, что могут быть внешние к системе буфера (сетевые или на пользовательском локальном хосте) которые должны быть очищены; соответствующий способ сделать так, это передать сигнал "Synch" (описанный ниже) пользовательской системе.
Сигнал "Synch"
Многие системы с разделением времени (многозадачные системы) предоставляют механизмы, которые позволяют пользователю терминала восстанавливать управление над "бесконечным" процессом; функции IP и AO, описанные выше, являются примерами этих механизмов. Такие системы, когда они используются локально, имеют доступ ко всем сигналам которые вводит пользователь, являются ли они обычными символами или специальными сигналами, такими как поддерживаемая телетайпом кнопка "BREAK" или IBM 2741 кнопка "ATTN". Это не всегда так, когда терминалы подключены к системе через сеть; сетевые механизмы могут заставить такой сигнал быть забуферизированным в другом месте, например на хосте пользователя.
Чтобы решить эту проблему, в TELNET был введен механизм "Synch". Сигнал Synch включается в TCP Urgent notification (срочное уведомление) вместе с TELNET командой DATA MARK. Срочное уведомление, которое не подвергается дополнительному управлению сетевыми механизмами, управляющие TELNET соединением, используется, чтобы вызвать специальную обработку потока данных процессом, который получает эти данные. В этом режиме поток данных будет немедленно просканирован на предмет "интересных" сигналов как описано ниже, отказываясь от пришедших данных. TELNET команда DATA MARK (DM) является меткой синхронизации в потоке данных, которая указывает, что некоторый специальный сигнал уже попался и получатель может возвратиться к нормальной обработке потока данных.
Synch отправляется через TCP отправкой операции с флагом Urgent и DM как последним октетом данных.
Когда несколько Synch отправляются как непрерывная последовательность, срочные уведомления могут быть объединены. Невозможно посчитать количество срочных уведомлений, так как количество полученных будет меньше или равно количеству отправленных. В обычном режиме, DM не имеет действия; в срочном режиме, он сообщает конец срочной (urgent) обработки.
Если TCP указывает на конец срочных (urgent) данных раньше, чем будет найден DM, TELNET должен продолжить специальную обработку потока данных, пока не встретиться DM.
Если TCP указывает на то, что срочные (urgent) данные еще есть, после того как найдет DM, то такое может случиться из-за следующего Synch. TELNET должен продолжить специальную обработку данных, пока другой DM не будет найден.
"Интересные" сигналы определены, чтобы быть: стандартными TELNET представлениями IP, AO и AYT (но не EC или EL); локальными аналогами этих стандартных представлений; всеми другими TELNET командами; другими определенными по месту сигналами которые могут задействоваться без задержки сканирования потока данных.
Так как один из эффектов механизма SYNCH - это отказ от всех символов (исключая TELNET команды) между отправителем Synch и получателем, то этот механизм определен как стандартный путь очистки данных. Например, если пользователь в терминале передает AO, сервер, который получает AO (если он вообще обеспечивает эту функцию) должен вернуть пользователю Synch.
В итоге, так же как TCP Urgent notification требуется уровень TELNET как сигнал out-of-band, так и другим протоколам использующим TELNET, могут понадобиться TELNET команды, которые могут рассматриваться как out-of-band сигналы на различном уровне.
В соответствии с соглашением последовательность [IP,Synch] должна использоваться как такой сигнал. Например, предположим, что некоторый другой протокол, который использует TELNET, определяет строковую строку STOP аналогично TELNET команде AO. Предположим, что пользователь этого протокола желает, чтобы сервер обработал строку STOP, но соединение блокировано, потому что сервер обрабатывает другие команды. Пользователь должен проинструктировать свою систему:
1. Отправить символ TELNET IP;
2. Отправить последовательность TELNET SYNCH, которая состоит из:
Отправки Data Mark (DM) как единственного символа который посылается в срочном режиме TCP.
3. Отправка символьной строки STOP; и
4. Отправка аналога TELNET DM для другого протокола, если требуется.
Пользователь (или процесс действующий от его имени) должен передать последовательность TELNET SYNCH на шаге 2, чтобы гарантировать, что TELNET IP пройдет на серверном интерпретаторе TELNET.
Срочное уведомление должно разбудить процесс TELNET; IP должен разбудить следующий высокоуровневый процесс.
Network File System (NFS) — протокол сетевого доступа к файловым системам, первоначально разработан Sun Microsystems в 1984 году. Основан на протоколе вызова удалённых процедур (ONC RPC, Open Network Computing Remote Procedure Call, RFC 1057, RFC 1831). Позволяет подключать (монтировать) удалённые файловые системы через сеть, описан в RFC 1094, RFC 1813, и RFC 3530.
NFS абстрагирована от типов файловых систем как сервера, так и клиента, существует множество реализаций NFS-серверов и клиентов для различных операционных систем и аппаратных архитектур. В настоящее время (2007) используется наиболее зрелая версия NFS v.4 (RFC 3010), поддерживающая различные средства аутентификации (в частности, Kerberos и LIPKEY с использованием протокола RPCSEC_GSS) и списки контроля доступа (как POSIX, так и Windows-типов).
pNFS (параллельный NFS) — последняя версия стандарта NFS, включающая в себя распараллеленную реализацию общего доступа к файлам, которая увеличивает скорость передачи данных пропорционально размерам системы.