Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
екция 17 25, 2013 20:22:20
Прикладной уровень модели TCP/IP обеспечивает возможность для пользовательских приложений на узлах сети обмениваться данными с помощью имеющихся транспортных сервисов. Приложения могут использовать соединения TCP или самостоятельно контролировать обмен данными с использованием транспорта UDP.
Можно разделить все множество прикладных протоколов и их программных реализаций на две больших категории.
К первой категории отнесем протоколы и прикладные процессы, клиентские элементы которых предназначенные для непосредственного взаимодействия с интерфейсами, ориентированными на человека. Таким интерфейсом может быть консоль, пользовательский файл или IP-телефон.
Ко второй категории отнесем протоколы и прикладные процессы, предназначенные для взаимодействия с программными или аппаратными интерфейсами системы. Они могут рассматриваться как обслуживающие по отношению к первой категории. Реализации этой категории протоколов могут выполнять как клиентские, так и серверные функции.
Попробуем систематизировать протоколы первой категории:
Коммуникационные протоколы:
POP3 (Post Office Protocol Version 3 - протокол почтового отделения версии 3) протокол, по которому почтовый клиент получает почту с почтового сервера
IMAP (Internet Message Access Protocol — протокол доступа к электронной почте Интернета), аналогичен по назначению POP3, но обладает существенно большими возможностями
ICQ (англоязычный фонетический омоним фразы I Seek You) протокол обмена мгновенными сообщениями
H.323 протокол обмена мультимедийной инфррмацией по сетям TCP/IP с негарантированной пропускной способностью)
SIP (Session Initiation Protocol — протокол установления сессии) протокол установления и завершения сеанса, включающего обмен мультимедийными данными для мгновенного обмена сообщениями, аудио и видео конференций
RTSP (Real Time Streaming Protocol) потоковый протокол реального времени используемый для удаленного управления потоками мультимедийных данных. При этом сама передача данных не является функцией протокола
Файловые протоколы
FTP (File Transfer Protocol) протокол передачи файлов
HTTP (HyperText Transfer Protocol) протокол передачи гипертекста
NFS (Network File System) протокол сетевого доступа к файловым системам
SMB (Server message block) протокол совместного использования файлов
Терминальные протоколы
RLOGIN (Remote LOGIN) протокол удаленного входа в систему
TELNET (TELecommunication NETwork) протокол удаленного текстового интерфейса
SSH (Secure Shell) протокол для безопасного удаленного доступа и передачи данных
X Window System протокол построения удаленных графических интерфейсов
Протоколы второй категории
Коммуникационные протоколы
SMTP (Simple Mail Transfer Protocol - простой протокол передачи почты) протокол, используемый при передачи почтовых сообщений между почтовыми серверами и от пользователя на почтовый сервер
Протоколы управления
SNMP (Simple Network Management Protocol - простой протокол управления сетью) протокол управления для сетей TCP/IP
NTP (Network Time Protocol) протокол определения точного времени в сетях с произвольной латентностью
Протоколы разрешения имен
DNS (Domain Name System - система доменных имён) протокол функционирования распределённой системы (базы данных), по доменному имени хоста определяющей и сообщающей его IP адрес или другую информацию
WINS (Windows Internet Name Service ) протокол сопоставления netbios-имён компьютеров с ip-адресами
NIS (Network Information Service - информационная служба сети) протокол доступа к системной конфигурации по всей сети
Приложения удаленного терминального подключения к сетевому узлу дают пользователю удаленный доступ к командной строке командной оболочки операционной системы узла и позволяют инициировать в ней выполнение программ. Отпадает необходимость иметь аппаратный терминал к каждому хосту, можно зайти терминалом на один хост, затем удаленным терминалом по сети на любой другой хост.
Терминальные драйверы имеют свой внутренний интерфейс с программными модулями, интерпретирующими ввод и вывод строк. В каноническом режиме интерпретаторы строк преобразуют неструктурированные последовательности данных, введенные с клавиатуры, в каноническую форму.
Терминалы пересылают машине всю введенную последовательность, включая, например, символы стирания предыдущего символа. Строковый интерфейс буферизует информацию в строки (набор символов, заканчивающийся символом возврата каретки) и обрабатывающий процесс стирает символы в строке, прежде чем переслать исправленную последовательность считывающему процессу.
В сетях TCP/IP существуют три приложения, позволяющие осуществить терминальный заход.
Протокол rlogin
Rlogin был предназначен для захода удаленным терминалом между Unix хостами. Поэтому он проще, чем Telnet, так как не требуется определения параметров, которые для одной и той же операционной системы известны заранее и для клиента, и для сервера.
Запуск приложения
Rlogin использует одно TCP соединение между клиентом и сервером. После того как TCP соединение установлено, между клиентом и сервером осуществляется следующая последовательность действий.
Клиент отправляет серверу четыре строки:
(a) нулевой байт
(b) имя пользователя на хосте клиента, заканчивающееся нулевым байтом
(с) имя пользователя на хосте сервера, заканчивающееся нулевым байтом
(d) тип терминала пользователя, за которым следует слэш (/), затем следует скорость терминала, и все это заканчивается нулевым байтом.
Необходимо отправить именно два имени пользователя, потому что пользователи не обязаны иметь одинаковые имена на разных хостах.
Тип терминала передается от клиента к серверу, потому что эта информация необходима для большинства полноэкранных приложений. Скорость терминала передается, потому что некоторые приложения работают по-разному в зависимости от скорости.
Сервер отвечает нулевым байтом.
У сервера есть опция, с помощью которой он может запросит пароль. Это осуществляется как обычный обмен данными по Rlogin соединению - специальные протоколы не применяются. Сервер отправляет клиенту строку (которую клиент отображает на терминале), чаще всего эта строка выглядит как Password:. Если клиент не вводит пароль в течение определенного времени (обычно 60 секунд), сервер закрывает соединение.
В домашней директории на сервере можно создать файл (который называется .rhosts) в котором будут содержаться имя хоста и имя пользователя. Если зайти терминалом с указанного хоста с указанным именем пользователя, то не выдается приглашение ввести пароль. С точки зрения безопасности очень не рекомендуют пользоваться этой возможностью.
Все что вводится в ответ на приглашение сервера ввести пароль, передается в виде открытого текста. Символы введенного пароля посылаются так, как они есть. Каждый, кто может прочитать пакеты в сети, может прочитать любой пароль. Последующие реализации Rlogin клиента, например в 4.4BSD, используют Kerberos для шифрации при передаче по сети.
В рабочем режиме клиент посылает за один раз серверу 1 байт, каждый байт сервер отражает эхо-откликом. Для оптимизации потока данных обычно используется алгоритм Нагла, поэтому несколько входных байтов отправляются по медленным сетям как один TCP сегмент. В итоге все то, что вводит пользователь, отправляется на сервер, а то, что сервер отправляет клиенту, отображается на терминале.
Существуют команды, которые могут быть отправлены от клиента к серверу и от сервера к клиенту.
Управление потоком
По умолчанию управление потоком обычно осуществляет Rlogin клиент. Клиент распознает ASCII символы STOP и START (Control-S и Control-Q), которые вводятся пользователем, и останавливает или стартует вывод на терминал.
Если это не сделано, каждый раз, когда мы вводим Control-S, чтобы остановить вывод на терминал, символ Control-S отправляется по сети к серверу, и сервер прекращает писать в сеть, однако данные (размер данных может достигать размера окна) могут быть уже выданы сервером в сеть и будут отображены на терминале, перед тем как вывод будет остановлен. Сотни или тысячи байт данных могут прокрутиться на экране, перед тем как вывод будет остановлен. На рисунке 26.3 показан подобный сценарий.
Рисунок 26.3 Функционирование Rlogin соединения в случае, если сервер поддерживает обмен STOP/START.
Для интерактивных пользователей подобная задержка отклика на ввод символа Control-S нежелательна.
Однако, иногда приложения, запущенные на сервере, должны интерпретировать каждый байт ввода, и они не хотят, чтобы клиент использовал символы Control-S и Control-Q каким-то особенным образом. В подобном случае сервер может сообщить клиенту, поддерживает ли он контроль потока данных или нет.
Прерывание от клиента
Проблема, напоминающая управление потоком данных, возникает, когда пользователь вводит символ прерывания (обычно DELETE или Control-C), чтобы прекратить процесс, запущенный на сервере. В этом случае также одно полное окно данных в канале между сервером и клиентом будет передано клиенту, до тех пор пока символ прерывания проделает свой путь по соединению в другом направлении. Мы хотим, чтобы символ прерывания остановил или прервал вывод данных на экран так быстро, как это возможно.
Изменения размера окна
Если существует возможность поделить дисплей на окна, мы можем динамически менять размер окна, в процессе работы приложения. Некоторые приложения (обычно те, которые манипулируют с целыми окнами, такие как полноэкранные редакторы) должны знать об этих изменениях. Большинство Unix систем каким-либо образом сообщают приложению об изменении размера окна.
В случае захода удаленным терминалом, изменения размера окна происходят на компьютере клиента, и об этом необходимо сообщить приложению, которое работает на сервере. Клиенту Rlogin необходима некоторая форма уведомления, для того чтобы сообщить серверу об изменении размера окна и о том, чему теперь равен новый размер окна.
Команды от сервера к клиенту
Рассмотрим четыре команды, которые сервер Rlogin может отправить клиенту по TCP соединению. Проблема заключается в том, что используется одно TCP соединение, поэтому сервер должен пометить байты команд так, чтобы клиент интерпретировал их именно как команды, а не отображал эти байты на терминале. Для этого используется режим срочности TCP.
Когда сервер отправляет команду клиенту, он входит в режим срочности, при этом последний байт срочных данных это и есть байт команды от сервера. Когда клиент получает уведомление о режиме срочности, он читает из соединения и сохраняет данные до тех пор, пока не будет получен байт с командой (последний байт срочных данных). Данные, которые сохранил клиент, могут быть выданы на терминал или проигнорированы, в зависимости от команды.
|
Байт |
Описание |
|
0х02 |
Сбросить вывод. Клиент отбрасывает все данные, принятые от сервера, до командного байта (последний байт срочных данных). Клиент также отбрасывает все данные, сбуферизированные и предназначенные для вывода на терминал. Сервер посылает эту команду, когда пользователь ввел символ прерывания. |
|
0х10 |
Клиент прекращает контролировать поток данных. |
|
0х20 |
Клиент возобновляет контроль потока данных. |
|
0х80 |
Клиент немедленно отвечает отправкой серверу текущего размера окна и уведомляет сервер, если в будущем размер окна изменится. Сервер обычно отправляет эта команду немедленно после установления соединения. |
Команды Rlogin, передаваемые от сервера клиенту.
Одна из причин, по которой описанные выше команды посылаются с использованием режима срочности TCP, заключается в том, что первая команда (сбросить вывод) должна быть отправлена клиенту, даже если поток данных от сервера к клиенту остановлен контролем потока данных TCP. Ситуация когда передача информации от сервера к клиенту остановлена управлением потоком данных может возникнуть, так как процессы, запущенные на сервере, обычно генерируют вывод быстрее, чем этот он может быть отображен на терминале клиента. Однако, достаточно редко может возникнуть ситуация, когда передача информациии от клиента к серверу будет остановлена управлением потоком данных, так как в этом направлении поток данных содержит только символы, вводимые пользователем.
Уведомление о срочности проходит по соединению, даже если размер окна был установлен в 0. Оставшиеся три команды не критичны по времени, однако они используют тот же механизм для упрощения реализации.
Команды от клиента к серверу
Определена только одна команда, передаваемая от клиента к серверу: это отправка серверу текущего размера окна. Изменение размера окна отправляется серверу только по получению от сервера команду 0x80.
В этом случае клиент должен иметь возможность пометить команду, чтобы она не были переданы приложению, запущенному на сервере. Клиент помечает команду с помощью отправки 2-х байт равных 0xff, за которыми следуют два специальных флаговых байта.
Для команды, управляющей размером окна, два флаговых байта это ASCII символы s. Затем следуют четыре 16-битных значения: количество символов в строке (обычно 25), количество символов в столбце (обычно 80), количество пикселей по оси X и количество пикселей по оси Y. Часто два последних 16-битных значения равны 0, так как большинство приложений, запускаемых Rlogin сервером, определяют размер экрана в символах, а не в пикселях.
Подобная форма представления команд называется командами в полосе (in-band signaling), так как командные байты передаются в обычном потоке данных. Байты, выделяющие команды из потока данных (0xff) выбраны таким образом, чтобы нажатие какой-либо клавиши не могло их сгенерировать. У подобной формы представления команд есть свои недостатки. Если мы сможем сгенерировать два последовательных байта равных 0xff с клавиатуры, за которыми будут следовать два ASCII символа s, следующие 8 введенных байт будут восприняты как размеры окна.
Команды Rlogin от сервера к клиенту называются командами, выходящими за полосу (out-of-band signaling).
Так как команды в полосе (in-band signaling) передаются от клиента к серверу, сервер должен просматривать каждый байт, принятый от клиента, в поисках двух последовательных байтов 0xff. В случае команд выходящих за полосу (out-of-band signaling) , которые передаются от сервера к клиенту, клиенту нет необходимости просматривать данные, которые он получает от сервера, до тех пор пока сервер не перейдет в режим срочности. Даже в режиме срочности клиенту необходимо только просмотреть байт, на который указывает указатель срочности. Так как соотношение количества байт, передаваемых в двух направлениях (от клиента к серверу и от сервера к клиенту), составляет примерно 1:20, то возникает необходимость использовать команды в полосе (in-band signaling) для небольшого потока данных (от клиента к серверу), и команды, выходящие за полосу (out-of-band signaling), для более загруженного потока данных (от сервера к клиенту).
Способы прекращения работы клиента
Обычно, все, что вводит пользователь Rlogin, отправляется на сервер. Однако иногда возникает необходимость пообщаться непосредственно с программой клиента Rlogin. При этом серверу отправлять ничего не нужно. Это делается путем ввода символа тильда (~) в первой позиции строки, за которым может следовать один из следующих четырех символов:
Две последние команды поддерживаются, только если клиент является Unix системой, которая поддерживает управление работами.
Протокол Telnet
Telnet был разработан для работаты между хостами под управлениием любых операционных систем, а также с любыми терминалами. Его спецификация определяет терминал, который может являться наиболее общим, и который называется виртуальным сетевым терминалом (NVT - network virtual terminal). NVT это воображаемое устройство, находящееся на обоих концах соединения, у клиента и сервера, с помощью которого устанавливается соответствие между их реальными терминалами. Таким образом, операционная система клиента должна определять соответствие между тем типом терминала, за которым работает пользователь, с NVT. В свою очередь, сервер должен устанавливать соответствие между NVT и теми типами терминалов, которые он (сервер) поддерживает.
NVT это символьное устройство с клавиатурой и принтером. Данные, введенные пользователем с клавиатуры, отправляются серверу, а данные, полученные от сервера, поступают на принтер. По умолчанию клиент отражает эхом на принтер все, что ввел пользователь, однако, ниже мы увидим что, существуют опции, которые позволяют изменить подобное поведение.
NVT ASCII
Термин NVT ASCII означает 7-битный вариант U.S. ASCII набора символов, который используется в семействе протоколов Internet. Каждый 7-битный символ отправляется как 8-битный байт со старшим битом установленным в 0.
Конец строки передается как двухсимвольная последовательность - CR (возврат каретки - carriage return), затем следует LF (пропуск строки - linefeed). В протоколах FTP, SMTP, Finger и Whois используют NVT ASCII для ввода команд клиента и откликов сервера.
Команды Telnet
Telnet использует команды в полосе (in-band signaling) в обоих направлениях. Байт 0xff (255 десятичный) называется IAC, "интерпретировать как команду". Следующий байт является командным байтом. Для того чтобы послать байт данных равный 255, отправляются два последовательных байта равных 255. (Выше было указано, что поток данных имеет формат NVT ASCII, то есть используются 7-битные значения, а это означает, что байт данных равный 255 не может быть отправлен посредством Telnet. Однако существует опция Telnet, описанная в RFC 856 [Postel and Reynolds 1983b], которая, позволяет передавать 8-битные данные.)
|
Имя |
Код (десятичный) |
Описание |
|
EOF |
236 |
конец файла |
|
SUSP |
237 |
подавить текущий процесс (управление задачами) |
|
ABORT |
238 |
прекратить процесс |
|
EOR |
239 |
конец записи |
|
SE |
240 |
конец подопции |
|
NOP |
241 |
пустая операция |
|
DM |
242 |
маркер данных |
|
BRK |
243 |
прерывание |
|
IP |
244 |
прервать процесс |
|
AO |
245 |
прекратить вывод |
|
AYT |
246 |
вы здесь? |
|
EC |
247 |
escape символ |
|
EL |
248 |
стереть строку |
|
GA |
249 |
идем дальше |
|
SB |
250 |
начало подопции |
|
WILL |
251 |
обсуждение опции (рисунок 26.9) |
|
WONT |
252 |
обсуждение опции |
|
DO |
253 |
обсуждение опции |
|
DONT |
254 |
обсуждение опции |
|
IAC |
255 |
байт данных 255 |
Команды Telnet, предваряемые IAC (255).
Большинство из этих команд используется достаточно редко.
Обсуждение опций
Несмотря на то, что при начале работы Telnet подразумевается, что на каждом конце находится NVT, первый обмен данными, который происходит по Telnet соединению, является обсуждением опций. Обсуждение опций это симметричный процесс - каждая сторона может послать запрос другой.
Каждая сторона может послать один из четырех различных запросов для любой заданной опции.
Так как правила Telnet позволяют стороне принять или отклонить запрос на включение опции (случаи 1 и 2), однако требуют, чтобы она всегда удовлетворяла запрос на выключение опции (случаи 3 и 4), из этих четырех возможных случаев может получиться шесть комбинаций:
|
|
Отправитель |
|
Получатель |
Описание |
|
1. |
WILL |
-> <- |
|
отправитель хочет включить опцию |
|
2. |
WILL |
-> <- |
|
отправитель хочет включить опцию |
|
3. |
DO |
-> <- |
|
отправитель хочет, чтобы получатель включил опцию |
|
4. |
DO |
-> <- |
|
отправитель хочет, чтобы получатель включил опцию |
|
5. |
WONT |
-> <- |
|
отправитель хочет выключить опцию |
|
6. |
DONT |
-> <- |
|
отправитель хочет, чтобы получатель выключил опцию |
Шесть сценариев обсуждения опции Telnet.
Обсуждение опции занимает 3 байта: IAC байт, за которым следует байт WILL, DO, WONT или DONT, затем ID байт, указывающий на ту опцию, которую необходимо включить или выключить. Таким образом, может быть обсуждено 40 опций. Описания опций и их кодирование специфицировано в нескольких документах RFC (Request for Comments). Примерами могут служить:
|
ID опции (десятичный) |
Имя |
RFC |
|
1 |
эхо |
857 |
|
3 |
запрещение команды go ahead |
858 |
|
5 |
статус |
859 |
|
6 |
маркер времени |
860 |
|
24 |
тип терминала |
1091 |
|
31 |
размер окна |
1073 |
|
32 |
скорость терминала |
1079 |
|
33 |
удаленный контроль потоком данных |
1372 |
|
34 |
линейный режим (linemode) |
1184 |
|
36 |
переменные окружения |
1408 |
Коды опций Telnet.
Обсуждение опции Telnet, как и многое другое в протоколе Telnet, процесс симметричный. Каждая сторона может начать процесс обсуждения опции. Однако заход удаленным терминалом не является симметричным процессом. Клиент решает свои задачи, а сервер свои. Некоторые опции Telnet применимы только к клиенту (например, требование включить линейный режим (linemode)), а некоторые предназначены только для сервера.
Обсуждение подопций
Некоторые опции требуют большего количества информации, нежели просто "включить" (enable) или "выключить" (disable). Например, установка типа терминала: для того чтобы клиент мог идентифицировать тип терминала, он должен отправить ASCII строку. Чтобы обработать эти опции, применяется обсуждение подопций.
Если клиент просит включить опцию, отправляя 3-байтовую последовательность
<IAC, WILL, 24>
где 24 (десятичное) это идентификатор опции типа терминала. Если получатель (сервер) говорит ДА, его ответ будет выглядеть как
<IAC, DO, 24>
Затем сервер посылает
<IAC, SB, 24, 1, IAC, SE>
спрашивая о типе терминала клиента. SB это команда, которая сообщает о начале подопций (suboption-begin). Следующий байт равный 24 указывает на то, что это подопция типа терминала. (SB всегда следует за номером опции, к которой относятся подопции.) Следующий байт равный 1 означает "отправьте ваш тип терминала". Перед командой конец подопций (suboption-end) должен опять стоять IAC, так же как и перед командой SB. Клиент отвечает командой
<IAC, SB, 24, 0, 'I', 'B', 'M', 'P', 'C', IAC, SE>
в случае, если его тип терминала ibmpc. Четвертый байт равный 0 означает "у меня следующий тип терминала". ("Официальный" список приемлемых типов терминалов находится в Assigned Numbers RFC, однако для Unix систем приемлем любой тип терминала, поддерживаемый сервером. Обычно это терминалы, поддерживаемые базами termcap или terminfo.) Типы терминалов, указываемые в подопциях Telnet, пишутся большими буквами и обычно преобразуются в маленькие буквы уже сервером.
Полудуплексный, символ за один раз, строка за один раз или линейный режим (Linemode)?
Существуют четыре режима, в которых функционирует большинство Telnet клиентов и серверов:
Этот режим используется редко. (NVT по умолчанию это полудуплексное устройство, которое требует исполнения команды GO AHEAD (GA) от сервера, перед тем как будет принят ввод от пользователя. Ввод пользователя отображается локальным эхом от NVT клавиатуры на NVT принтер, таким образом, от клиента к серверу посылаются только полные строки.)
Именно таким образом работает Rlogin. Каждый вводимый символ отправляется серверу отдельно от других. Сервер отражает эхом большинство символов, если только у приложения на сервере не отключено отражение эхом.
Проблемы, связанные с этим режимом, в основном связаны с задержками, вызванными отражением эхом по медленным сетям, и с большим объемом сетевого трафика. Однакона это наиболее распространенный режим и являющийся к тому же режимом по умолчанию.
Для того чтобы сервер мог войти в этот режим, у него должна быть включена опция SUPPRESS GO AHEAD. Обсуждение этой опции осуществляется следующим образом: клиент посылает DO SUPPRESS GO AHEAD (требуя от сервера, чтобы тот включил опцию), или сервер посылает WILL SUPPRESS GO AHEAD клиенту (спрашивая о возможности включить эту опцию для самого себя). Затем сервер осуществляет WILL ECHO, спрашивая о возможности включить отражение эхом.
Часто это называется "kludge line mode", потому что его реализация приходит от чтения между строк в RFC 858. Этот RFC декларирует, что должны присутствовать обе опции ECHO и SUPPRESS GO AHEAD, чтобы обеспечить ввод символа за один раз с удаленным эхом. Таким образом, если какая-либо из этих опций не включена, Telnet находится в режиме строка за один раз.
В данном случае этот термин означает реальную опцию linemode, определенную в RFC 1184 [Borman 1990]. Эта опция обсуждается клиентом и сервером и корректирует все недостатки в режиме строка за один раз. Новые реализации поддерживают эту опцию.
Сигнал синхронизации (Synch)
Telnet использует команду Data Mark в качестве сигнала синхронизации который передается в виде срочных данных TCP. Команда DM это метка синхронизации в потоке данных, которая сообщает принимающему о необходимости вернуться в обычный режим работы. Он может быть отправлен в любом направлении по Telnet соединению.
Когда один конец принимает уведомление о том, что другой конец вошел в режим срочности, он начинает читать из потока данных, отбрасывая все данные кроме Telnet команд. Последний байт срочных данных это DM байт. Причина, по которой используется режим срочности TCP, заключается в том, что он позволяет посылать Telnet команды по соединению, даже если поток TCP данных остановлен управлением потока данных TCP.
Управление клиентом
Как и в случае Rlogin клиента, Telnet клиент так же позволяет пообщаться с ним, вместо того чтобы отправлять пользовательский ввод серверу. Стандартный символ, позволяющий осуществить переход в режим управления клиентом (escape), это Control-] (control и правая квадратная скобка, что обычно печатается как "^]"). При этом клиент выводит приглашение, обычно выглядящее как "telnet>". В ответ на это приглашение можно вводить команды, что позволяет сменить характеристики сессии или напечатать какую-либо информацию. Команда help поддерживается большинством Unix клиентов и отображает все доступные команды.
Протокол FTP
Данный протокол является стандартом Internet для передачи файлов. RFC 959 [Postel and Reynolds 1985] является официальной спецификацией FTP. Это один из старейших протоколов, до массового распространения HTTP именно на этот протокол приходилась основная часть трафика интернета.
Передача файлов заключается именно в копировании целого файла из одной системы в другую и надо понимать, что это не доступ к файлам на удаленном хосте, предоставляемый, например, протоколом NFS.
FTP создавался для обмена файлами между хостами, работающими под управлением различных операционных систем, использующих различные структуры файлов и, возможно, различные наборы символов. Поэтому FTP поддерживает ограниченное количество типов файлов (ASCII, двоичное и так далее) и структуру файлов (поток байтов или ориентированный на запись).
FTP отличается от других приложений тем, что он использует два TCP соединения для передачи файла.
Первое - управляющее соединение устанавливается как обычное соединение клиент-сервер. Сервер осуществляет пассивное открытие на заранее известный порт FTP (21) и ожидает запроса на соединение от клиента. Клиент осуществляет активное открытие на TCP порт 21. Управляющее соединение существует все время, пока клиент общается с сервером. Это соединение используется для передачи команд от клиента к серверу и для передачи откликов от сервера
Второе - соединение для передачи данных открывается каждый раз, когда осуществляется передача файла между клиентом и сервером.
Процессы, участвующие в передаче файлов.
Интерактивный пользователь обычно не видит команды и отклики, которыми обмениваются по управляющему соединению интерпретаторы протокола клиента и сервера. Он взаимодействует с пользовательским интерфейсом. Интерфейс конвертирует ввод пользователя в FTP команды, которые отправляются по управляющему соединению. Отклики, возвращаемые сервером по управляющему соединению, также конвертируются в формат, удобный для пользователя.
Представление данных
Протокол FTP предоставляет различные способы управления передачей и хранения файлов. В самом общем случае пользователю предлагается выбор по четырем пунктам:
Первый пункт выбора: Тип файла.
Возможны следующие варианты
А - ASCII файлы (по умолчанию). Текстовый файл передается по соединению данных как NVT ASCII. При этом требуется, чтобы отправитель конвертировал локальный текстовый файл в NVT ASCII, а получатель конвертировал NVT ASCII в текстовый файл. Конец каждой строки передается в виде NVT ASCII символа возврата каретки, после чего следует перевод строки. Это означает, что получатель должен просматривать приходящий поток байт в поисках пары символов CR, LF.
Б - EBCDIC файлы (Extended Binary Coded Decimal Interchange Code — расширенный двоично-десятичный код обмена информацией; произносится «эб-си-дик». Разработанная IBM восьмибитная кодировка для мэйнфреймов). Альтернативный способ передачи текстовых файлов, когда на обоих концах системы использована кодировка EBCDIC.
С - Двоичные или бинарные файлы. Данные передаются как непрерывный поток битов.
Д - Локальный тип файлов. Способ передачи бинарных файлов между хостами, которые имеют различный размер байта. Количество битов в байте определяется отправителем. Для систем, которые используют 8-битные байты, локальный тип файла с размером байта равным 8 эквивалентен бинарному типу файла.
Второй пункт выбора: Управление форматом. Применяется только для ASCII и EBCDIC файлов. Варианты следующие:
А - Nonprint. (по умолчанию) Файл не содержит информацию вертикального формата.
Б - Telnet format control. Файл содержит управляющие символы вертикального формата Telnet.
С - Fortran carriage control. Первый символ каждой строки это Fortran символ управления формата.
Третий пункт выбора: Структура. Возможны три варианта.
А - Структура файла (по умолчанию). Файл воспринимается в виде непрерывного потока байтов. Файл не имеет внутренней структуры.
Б - Структура записи. Эта структура используется только в случае текстовых файлов (ASCII или EBCDIC).
С - Структура страницы. Каждая страница передается со своим номером, что позволяет получателю хранить страницы в случайном порядке. Практически не поддерживается.
Последний, четвертый пункт выбора: Режим передачи. Указывает на то, как файл передается по соединению данных.
А - Режим потока (по умолчанию). Файл передается как поток байтов. Для файловой структуры конец файла указывает на то, что отправитель закрывает соединение данных. Для структуры записи специальная 2-байтовая последовательность обозначает конец записи и конец файла.
Б - Режим блоков. Файл передается как последовательность блоков, перед каждым из них стоит один или несколько байт заголовков.
С - Сжатый режим. Простое кодирование неоднократно встречающихся повторяющихся байт. В текстовых файлах обычно сжимаются пустые строки или строки из пробелов, а в бинарных строки из нулевых байт.
Всего получится 72 способа передачи и хранения файла, однако многие из этих опций не поддерживаются в большинстве реализаций протокола.
Самые распространенные Unix реализации FTP клиента и сервера предоставляют следующий выбор:
Это ограничивает нас одним из двух режимов: ASCII или двоичный.
Команды FTP
Команды и отклики передаются по управляющему соединению между клиентом и сервером в формате NVT ASCII. В конце каждой строки команды или отклика присутствует пара CR, LF.
Клиент FTP может воспользоваться двумя командами Telnet - это команда прерывания процесса (<IAC, IP>) и Telnet сигнал синхронизации, использующий режим срочности (<IAC, DM> в режиме срочности). Эти команды используются для прекращения передачи файла или для того, чтобы отправить серверу запрос в процессе передачи.
Имеется также более 30 различных FTP команд, состоящих из 3 или 4 байт, а именно из заглавных ASCII символов, некоторые с необязательными аргументами. Приведем некоторые из них в таблице:
|
Команда |
Описание |
|
ABOR |
прервать предыдущую команду FTP и любую передачу данных |
|
LIST список файлов |
список файлов или директорий |
|
PASS пароль |
пароль на сервере |
|
PORT n1,n2,n3,n4,n5,n6 |
IP адрес клиента (n1.n2.n3.n4) и порт (n5 x 256 + n6) |
|
QUIT |
закрыть бюджет на сервере |
|
RETR имя файла |
получить (get) файл |
|
STOR имя файла |
положить (put) файл |
|
SYST |
сервер возвращает тип системы |
|
TYPE тип |
указать тип файла: A для ASCII, I для двоичного |
|
USER имя пользователя |
имя пользователя на сервере |
Распространенные FTP команды.
Некоторые команды полностью совпадают с тем, что вводит интерактивный пользователь в качестве FTP команд, они же в этом случае и передаются по управляющему соединению. Однако некоторые вводимые пользователем команды генерируют несколько FTP.
FTP отклики
Отклики состоят из 3-циферных значений в формате ASCII, и необязательных сообщений, которые следуют за числами. Цифровые значения предназначены программному обеспечению, а дополнительная строка может быть выведена пользователю. Каждая из трех цифр в коде отклика имеет собственный смысл. Значения первых и вторых цифр в коде отклика представлены ниже.
|
Отклик |
Описание |
|
1yz |
Положительный предварительный отклик. Действие началось, однако необходимо дождаться еще одного отклика перед отправкой следующей команды. |
|
2yz |
Положительный отклик о завершении. Может быть отправлена новая команда. |
|
3yz |
Положительный промежуточный отклик. Команда принята, однако необходимо отправить еще одну команду. |
|
4yz |
Временный отрицательный отклик о завершении. Требуемое действие не произошло, однако ошибка временная, поэтому команду необходимо повторить позже. |
|
5yz |
Постоянный отрицательный отклик о завершении. Команда не была воспринята и повторять ее не стоит. |
|
x0z |
Синтаксическая ошибка. |
|
x1z |
Информация. |
|
x2z |
Соединения. Отклики имеют отношение либо к управляющему, либо к соединению данных. |
|
x3z |
Аутентификация и бюджет. Отклик имеет отношение к логированию или командам, связанным с бюджетом. |
|
x4z |
Не определено. |
|
x5z |
Состояние файловой системы. |
Значения первой и второй цифр в 3-циферном коде отклика.
Третья цифра дает дополнительное объяснение сообщению об ошибке. Ниже приведены некоторые типичные отклики с возможными объясняющими строками.
Обычно каждая FTP команда генерируют отклик в одну строку. Например, команда QUIT сгенерирует следующий отклик: 221 Goodbye.
Если необходим отклик в несколько строк, первая строка содержит дефис вместо пробела после 3-циферного кода отклика, а последняя строка содержит тот же самый 3-циферный код отклика, за которым следует пробел
Управление соединением
Использовать соединение данных можно тремя способами.
FTP сервер посылает список файлов по соединению данных, вместо того чтобы посылать многострочные отклики по управляющему соединению. При этом появляется возможность избежать любых ограничений в строках, накладывающихся на размер списка директории, и позволяет просто сохранить список директории в файле, вместо того чтобы выдавать список на терминал.
Управляющее соединение остается в активизированном состоянии все время, пока установлено соединение клиент-сервер, однако соединение данных может выключаться и включаться по необходимости. Как выбираются номера портов для соединения данных, и как осуществляет открытие этого соединения?
В распространенном потоковом режиме передачи конец файла обозначает закрытие соединения данных. Из этого следует, что для передачи каждого файла или списка директории требуется установление нового соединения. Соответственно, процедура выглядит следующим образом:
На рисунке показано состояние соединений на третьем шаге процесса. Порт клиента управляющего соединения имеет номер 1173, а порт клиента для соединения данных назначен с номером 1174. Команда, посылаемая клиентом - PORT, а ее аргументы это шесть десятичных цифр в формате ASCII, разделенные запятыми. Четыре первых числа - это IP адрес клиента, на который сервер должен осуществить активное открытие (140.252.13.34 в данном примере), а следующие два - это 16-битный номер порта. Так как 16-битный номер порта формируется из двух цифр, его значение в этом примере будет 4 x 256 + 150 = 1174.
Команда PORT, передаваемая по управляющему соединению FTP.
На следующем рисунке показано состояние соединений, когда сервер осуществляет активное открытие соединения данных. Конечная точка сервера - это порт 20.
FTP сервер осуществляет активное открытие соединения данных.
Сервер всегда осуществляет активное открытие соединения данных. Обычно сервер также осуществляет активное закрытие соединения данных, за исключением тех случаев, когда клиент отправляет файл на сервер в потоковом режиме, который требует, чтобы клиент закрыл соединение (что делается с помощью уведомления сервера о конце файла).
Если клиент не выдает команду PORT, сервер осуществляет активное открытие на тот же самый номер порта, который использовался клиентом для управляющего соединения (1173 в данном примере). В этом случае все работает корректно, так как номера порта сервера для двух соединений различны: один 20, другой 21. Однако современные реализации не используют эту возможность.
Анонимный FTP
Популярной формой использования FTP является анонимный FTP (anonymous FTP). Если эта форма поддерживается сервером, она позволяет любому получить доступ к серверу и использовать FTP для передачи файлов. С помощью анонимного FTP можно получить доступ к огромному объему свободно распространяемой информации. В качестве имени пользователя в этом случае обычно используется "anonymous", а пароля адрес электронной почты пользователя.
Анонимный FTP с неизвестного IP адреса
Некоторые анонимные FTP серверы требуют, чтобы клиент имел корректное имя домена. Это позволяет серверу зарегистрировать имя домена и хоста, с который осуществлен заход. Единственная информация, которую может узнать сервер о клиенте из IP датаграммы - это IP адрес клиента. Сервер осуществляет запрос указателя в DNS, чтобы узнать доменное имя клиента. Если DNS сервер, отвечающий за хост клиента, не сконфигурирован корректно, запрос указателя не сработает с соответствующими последствиями.
Формально и пользователи, и программы могут обращаться к хостам, почтовым ящикам и другим ресурсам сети интернет по их IP адресам, но если для программы процедура «запоминания» IP адреса ничем не отличается от «запоминания» любых других 4-х байт информации любого типа, то для пользователя запоминание цифросочетаний вида 111.124.133.44 тяжело просто с точки зрения устройства нашей памяти. Кроме того, отождествление каких-либо служб с IP адресами хостов или серверов, на которых они функционируют крайне затрудняет процедуру их переноса в случае необходимости. Для учета «человеческого фактора» и отделения имен машин от их адресов было решено использовать текстовые ASCII-имена. Тем не менее, сеть понимает только численные адреса, поэтому нужен механизм преобразования ASCII-строк в IP адреса.
Когда все только начиналось, в сети ARPANET соответствие между текстовыми и двоичными адресами хранилось в специальных файлах, в которых перечислялись все хосты и их IP-адреса. В сети, состоящей из нескольких сотен больших машин такой подход работал вполне приемлемо.
Но когда к сети подключились тысячи рабочих станций возникли проблемы: быстро росло количество записей, которые нужно было хранить, и централизованное управление именами всех хостов гигантской международной сети довольно сложно.
Для решения этих проблем была разработана служба имен доменов (DNS, Domain Name System). Эта система используется для преобразования имен хостов и пунктов назначения электронной почты в IP-адреса, но также может использоваться и в других целях. Определение системы DNS было дано в RFC 1034 и 1035.
Доменным именем называется имя, состоящее из слов, разделенных точками. Левое слово имени относится к хосту. Все остальные слова образуют имя домена. Система имен имеет иерархическую, древовидную структуру.
Каждый узел (кружочки на рисунке) имеет метку длиной до 63 символов. Корень дерева это специальный узел без метки. Метки могут содержать заглавные буквы или маленькие. Имя домена (domain name) для любого узла в дереве - это последовательность меток, которая начинается с узла выступающего в роли корня, при этом метки разделяются точками. (Здесь видно отличие от привычной нам файловой системы, где полный путь всегда начинается с вершины (корня) и опускается вниз по дереву.) Каждый узел дерева должен иметь уникальное имя домена, однако одинаковые метки могут быть использованы в различных точках дерева.
Существует корневое имя, обозначаемое символом '.', оно часто не пишется в имени домена. Существуют имена доменов первого уровня. Они разделены на 2 категории - имена доменов территорий и имена доменов предметных областей. Имена доменов второго уровня и последующих могут быть любыми, при этом не может существовать двух одинаковых имен доменов или хостов. Итак, если Ni- доменное имя i-го уровня, а T- слово, то доменное имя i+1 уровня образуется по правилу Ni+1=T+Ni.. Имя домена, которое заканчивается точкой, называется абсолютным именем домена (absolute domain name) или полным именем домена (FQDN - fully qualified domain name).
Подчеркнем ещё раз, что поскольку IP-адреса уникально идентифицируют хосты в сети, существует взаимно-однозначное отношение между множеством имен хостов и множеством адресов.
Это отношение устанавливается таблицей, в которой столько записей типа «Имя хоста, IP-адрес», сколько существует доменных имен хостов. При наименовании нового хоста запись в таблицу нужно добавить, если переименован существующий, запись нужно изменить. Пользоваться такой системой имен удобно, потому что они легко запоминаются и не привязаны к территориально локализованным IP-сетям. Перенося поименованный ресурс с одного хоста на другой, вам достаточно изменить запись для его имени в таблице имен. На одном сайте сложно содержать такую таблицу для Интернет и невозможно поддерживать в актуальном состоянии.
База данных DNS является распределенной. Иерархической системе имен соответствует иерархическая система серверов DNS, на которых размещены фрагменты таблицы. В идеале для каждого домена должен существовать отдельный сервер имен. В базе данных сервера имен любого уровня должны содержаться записи о всех дочерних доменах следующего уровня. Все домены первого уровня содержаться в базе данных корневых серверов (root name servers). Их обслуживает организация NIC.
В реальности на одном хосте может размещаться база для нескольких доменов, и одинаковые или пересекающиеся базы могут располагаться на нескольких хостах. Ветвь дерева имен, находящаяся под единым управлением вместе с хостами, на которых расположена база данных этой ветви дерева называется зоной DNS. Обычно в зоне имеется один основной сервер DNS (primary name server) и несколько резервных (secondary name servers). Изменения в зоне вносятся в базу данных первичного сервера зоны с последующим дублированием этой информации на вторичные сервера.
Процесс передачи информации от первичного сервера вторичному называется передачей зоны (zone transfer). Когда в зоне появляется новый хост, администратор добавляет соответствующую информацию (минимум, имя и IP адрес) в дисковый файл на первичном сервере. Вторичные сервера регулярно опрашивают первичные (обычно каждые 3 часа), и если первичные содержат новую информацию, вторичный получает ее с использованием передачи зоны.
Исходя из заданной функциональности системы и ее структуры следует, что в состав протокола должны входить две компоненты - протокол разрешения имен в IP-адреса и протокол обмена данными между узлами распределенной базы данных, в частности, между основным и резервным серверами зоны.
Система разрешения адресов.
Для того, чтобы программное обеспечение стека протоколов TCP/IP могло пользоваться службой имен, в настройках стека должен быть указан IP - адрес сервера имен, в зону которого входит хост или другой сервер, принимающий запросы из сети хоста. Когда прикладной элемент использует для обозначения второй стороны в сеансе доменное имя, инициируется процесс разрешения IP - адреса. Прикладной элемент службы имен хоста отправляет запрос серверу имен. Если сервер имен может разрешить адрес, он отправляет отклик, содержащий этот адрес. Если сервер имен не может разрешить запрос, он может инициировать два сценария разрешения имени
Отклик сервера, контролирующего домен, называется авторитетным.
Каждый сервер имен в Интернет должен содержать в базе адреса корневых серверов.
Формат сообщения DNS
DNS использует протокол транспортного уровня UDP. При этом для DNS запроса и для DNS отклика используется одинаковый формат:
Поля запроса имеют следующее назначение.
Значение в поле идентификации (identification) устанавливается клиентом и возвращается сервером. Это поле позволяет клиенту определить, на какой запрос пришел отклик.
Поле флагов предназначено для настройки типа запроса. Назначение битовых полей, начиная с левого, следующее.
|
QR |
opcode |
AA |
TC |
RD |
RA |
0 |
rcode |
0 (стандартный запрос).
1 (инверсный запрос)
2 (запрос статуса сервера).
Формат каждого вопроса в разделе вопросов (question) следующий: имя вопроса, тип вопроса/отклика, класс вопроса:
Имя запроса (query name) - это искомое имя. Оно выглядит как последовательность из одного или нескольких слов. Каждое слово начинается с 1-байтового счетчика, который содержит количество следующих за ним букв слова. Имя заканчивается байтом равным 0, который является словом с нулевой длиной и обозначает корень. Каждый счетчик байтов должен быть в диапазоне от 0 до 63, так как длина слова ограничена 63 байтами.
Каждый вопрос имеет тип запроса, каждый отклик содержит запись ресурса определенного типа.
Протокол работает с вопросами нескольких классов. Вопрос о IP адресе только один из вариантов:
|
Типы запросов |
||
|
Имя |
Цифровое значение |
Описание |
|
A |
1 |
IP адрес |
|
NS |
2 |
сервер DNS |
|
CNAME |
5 |
каноническое имя |
|
PTR |
12 |
запись указателя |
|
HINFO |
13 |
информация о хосте |
|
MX |
15 |
запись об обмене почтой |
|
AXFR |
252 |
запрос на передачу зоны |
|
* или ANY |
255 |
запрос всех записей |
Разрешение имен. Кроме основной своей функции разрешения доменного имени хоста в его IP-адрес, протокол DNS обеспечивает и обратное разрешение IP-адреса в доменное имя при помощи подзон реверсивной зоны in_addr.arpa.
Структура базы данных DNS.
Записи ресурсов, из которых составлена база DNS, разделяются по функциональным типам. Приведем некоторые из типов.
|
Тип |
Описание |
|
A |
IP-адрес |
|
PTR |
Указатель реверсивной зоны |
|
CNAME |
Каноническое имя (псевдоним) |
|
MX |
Записи для серверов электронной почты |
|
NS |
Сервер имен домена |
Когда в домене присутствует вторичный сервер DNS, на него периодически дублируется вся эта информация (передача зоны). Для передачи зоны используется транспорт TCP.
Протокол SMTP
Появление масштабных территориально распределенных сетей не могло не подвигнуть пользователей на обмен текстовыми сообщениями. Изначально это была просто пересылка файлов, потом появились первые примитивные протоколы, работавшие с текстовыми файлами, включавшими адрес получателя. Но требования пользователей росли, им хотелось иметь возможность посылать сообщение не одному, а сразу целой группе получателей, получать уведомления о доставке, иметь удобный интерфейс для работы с почтой, иметь возможность пересылать не только текст, но и другие форматы данных.
Для обеспечения этих потребностей был разработан SMTP (Simple Mail Transfer Protocol) - простой почтовый протокол, описанный в RFC 821 [Postel 1982]. Формат сообщения электронной почты, которое передается между двумя MTA в соответствии с RFC 821 определяется в RFC 822 [Crocker 1982].
SMTP обеспечивает передачу почтовых сообщений между системами и уведомления о входящей почте. Обмен почтой с использованием TCP осуществляется посредством агентов передачи сообщений (MTA - message transfer agent). Пользователи обычно не общаются с MTA. Протокол определяет, как два MTA обмениваются сообщениями по TCP соединению.
При общении между двумя MTA используется NVT ASCII. Клиент подключается на порт 25 сервера, используя протокол telnet. Команды посылаются клиентом серверу, а сервер отвечает с помощью цифровых кодов и опциональных текстовых строк.
Команды SMTP представляют собой сообщения ASCII, передаваемые между хостами SMTP. Ниже приведен список поддерживаемых команд:
|
Команда |
Описание |
|
DATA |
Начинает сборку (composition) сообщения. |
|
EXPN<string> |
Возвращает имена из указанного списка рассылок. |
|
HELO <domain> |
Возвращает идентификацию почтового сервера. |
|
HELP <command> |
Возвращает информацию об указанной команду. |
|
MAIL FROM <host> |
Инициирует почтовый сеанс с хоста. |
|
NOOP |
Нет операций кроме подтверждений от сервера. |
|
QUIT |
Прерывает почтовую сессию. |
|
RCPT TO <user> |
Обозначает получателя почты. |
|
RSET |
Сбрасывает (Reset) почтовое соединение. |
|
SAML FROM <host> |
Передает почту на терминал пользователя и в почтовый ящик. |
|
SEND FROM <host> |
Передает почту на терминал пользователя. |
|
SOML FROM <host> |
Передает почту на терминал пользователя или в почтовый ящик. |
|
TURN |
Меняет ролями отправителя и получателя. |
|
VRFY <user> |
Проверяет идентификацию пользователя. |
Электронное сообщение состоит из трех частей.
Конверт используется MTA для доставки. Конверт может быть определен двумя SMTP командами:
MAIL From jen@mail.sgu.ru- отправитель
RCPT To nil@mail.ru- получатель
Заголовки используются пользовательскими агентами. Могут использоваться заголовки полей: Received, Message-Id, From, Date, Reply-To, To, Subject. Каждое поле заголовка содержит имя, после которого следует двоеточие, а затем следует значение этого поля. RFC 822 определяет формат и интерпретацию полей заголовка. Длинные поля заголовков могут быть разбиты на несколько строк, причем дополнительные строки начинаются с пробела.
Тело - это содержимое сообщения от отправителя к получателю. RFC 822 определяет тело сообщения как текстовые строки в формате NVT ASCII. Когда происходит передача содержимого с использованием команды DATA, заголовки передаются первыми, за ними следует пустая строка и затем следует тело сообщения. Каждая строка, передаваемая с использованием команды DATA, ограничена в длину 1000 байт.
Доставка сообщений происходит по следующей схеме. Пользовательский агент передает сообщение своему MTA. Агент по доменному имени в адресе получателя должен найти почтовый сервер MTA получателя. Для этого используются DNS-запросы типа MX, возвращающие для MTA отправителя доменное имя и адрес сервера, уполномоченного получать сообщения для домена получателя. RFC 974 [Partridge 1986] описывает, как MTA обрабатывает записи MX. После этого MTA отправителя, выступая в качестве клиента, устанавливает telnet - соединение на 25 порт найденного сервера и передает ему сообщение. Если сервер, получивший сообщение, является сервером получателя, в этом случае получатель содержится в его базе абонентов. Сообщение записывается в почтовый файл абонента. Если сервер является сервером пересылки, процедура MX-запроса повторяется и сообщение передается по цепочке, пока не будет доставлено.
Для чтения сообщений в почтовом файле сервера абонент может использовать локальную утилиту почтового клиента или пользоваться удаленным доступом к почтовым файлам по протоколам POP3 или IMAP.
NFS предоставляет клиентам прозрачный доступ к файлам и файловой системе сервера. Этим он отличается от FTP который обеспечивает только передачу файлов. С помощью FTP осуществляется полное копирование файла. NFS осуществляет доступ только к тем частям файла, к которым обратился процесс, и основное достоинство NFS в том, что он делает этот доступ прозрачным. Это означает, что любое приложение клиента, которое может работать с локальным файлом, с таким же успехом может работать и с NFS файлом, без каких либо модификаций самой программы
NFS это приложение клиент-сервер, построенное с использованием вызовов удаленных процедур (Remote Procedure Calls, RPC), чем принципиально отличается от рассмотренных нами ранее протоколов. Обычно клиент устанавливает соединение с заранее известным портом и затем, в соответствии с особенностями протокола, посылает запрос на выполнение определенного действия. В случае вызова удаленных процедур клиент создает вызов процедуры и затем отправляет его на исполнение серверу.
Клиент использует NFS протокол монтирования, чтобы смонтировать файловую систему сервера, перед тем как получить доступ к NFS файлам. Обычно это происходит при загрузке клиента. В результате клиент получает описатель файла файловой системы сервера.
Монтирование директории bsdi:/usr как /nfs/bsdi/usr на хосте sun.
Рассмотрим процесс работы протокола подробнее:
1. Для пользовательского приложения скрыто, обращается он к местному файлу или через NFS к файлу на удаленном хосте. За него это знает ядро операционной системы: в момент открытия файла оно определяет его местонахождение и в зависимости от этого в последующем все обращения к местным файлам отдает на обработку своей файловой системе, а те, что относятся к дальним файлам, направляет NFS-клиенту.
2. NFS-клиент посылает RPC-запросы на NFS-сервер через используемый транспортный протокол. Первые реализации NFS работали по UDP, но последующие реализации стали поддерживать возможность быть конфигурироваными на установление соединений по TCP.
3. NFS-сервер принимает дейтаграммы с запросами NFS-клиента на свой порт 2049 (UDP или TCP в зависимости от конфигурации).
4. При поступлении запроса от NFS-клиента, NFS-сервер транслирует его в запросы к своей местной файловой системе, которая и осуществляет соответствующие
действия на диске хоста сервера.
5. Обработка запроса на сервере может занять значительное время, особенно если потребуется выполнить манипуляции в его файловой системе. Чтобы в период
выполнения одного запроса не блокировать запросы от других NFS-клиентов, NFS-сервер должен обрабатывать их параллельно. Способ параллельной обработки зависит от возможностей конкретной операционной системы.
6. В свою очередь, и NFS-клиент, обслуживающий свой пользовательский процесс, вынужден, выслав RPC-запрос, в течение достаточно длительного времени ждать завершения его обработки на сервере до получения RPC-ответа. Поэтому и на клиентском хосте необходимо так или иначе обеспечить параллельное обслу живание многих использующих NFS пользовательских процессов, что также решается различными способами в зависимости от операционной системы.
Система NFS изначально создавалась для работы по протоколу UDP — эта возможность сохраняется и во всех последующих поколениях системы. Позднее появились версии NFS, позволяющие также работать и по TCP. Необходимость в этом появилась после того, как NFS стала использоваться за пределами локальных сетей.
Причина в том, что динамика работы в WAN отличается от работы в LAN, причем весьма существенно. Значения времени прохождения пакетов от клиента до сервера и обратно (RTT) в глобальных сетях нестабильны и могут сильно варьироваться, возрастает и вероятность возникновения перегрузок в сети. Эти присущие глобальным сетям особенности привели к разработке воплощенных в TCP методов адаптивного управления потоком данных, таких как алгоритмы медленного пуска (slow start) и предотвращения заторов (congestion avoidance). UDP же такими возможностями не обладает, поэтому работающие поверх UDP в глобальных сетях NFS-серверы и клиенты пришлось бы существенно усложнить, включив в их коды все необходимые алгоритмы, адаптирующие их к условиям WAN.
Проще оказалось поступить иначе — модифицировать клиентскую и серверную части NFS так, чтобы в своем обмене они могли использовать на транспортном уровне не UDP, a TCP.
X Window System, или просто X, это приложение клиент-сервер, которое позволяет нескольким клиентам (приложениям) использовать графический дисплей, управляемый сервером. Сервер это программное обеспечение, которое управляет дисплеем, клавиатурой и мышкой. Клиент это программа приложения, которая запущена либо на том же самом хосте, что и сервер, либо на другом хосте. В последнем случае обычная форма связи между клиентом и сервером это TCP.
В случае X клавиатура и дисплей принадлежат самому серверу. Поэтому в данном случае сервер это то, что предоставляет сервис. Сервис, предоставляемый X, это доступ к окну, клавиатуре и мышке. В случае Telnet сервис это терминальный заход на удаленный хост. В случае FTP сервис это файловая система сервера:
PROXYI
Из многочисленных значений английского слова "proxy" в интересующем нас контексте применимы следующие: «доверенное лицо», «полномочный представитель». То есть некто, действующий от вашего имени и по вашему поручению. В компьютерной терминологии «прокси» — это программа, которая передает запросы в Интернет, получает ответы и передает их обратно. Необходимость в такой программе обычно возникает, если с пользовательского места нельзя работать в Интернете напрямую, но выход есть на другом компьютере локальной сети. В этом случае программа – прокси работает на компьютере, имеющем выход в интернет, а остальные компьютеры сети настраивают таким образом, чтобы работа велась через него. Таким образом, если хоть один компьютер в локальной сети имеет доступ «вовне», то и все остальные могут пользоваться этим соединением.
Если мы попытаемся обойтись без прокси, каждому компьютеру должен быть выделен персональный «внешний» IP-адрес. Это хлопотно, обременительно в финансовом плане и, главное, снижает уровень безопасности: каждый компьютер сети может стать потенциальной мишенью хакеров, вирусных атак и прочих «прелестей» Интернета.
Вообще говоря, при таком «прямом» подключении тоже нужна программа-посредник на том компьютере, который непосредственно подключен к интернету. Но при наличии реальных IP-адресов эта программа — обычный маршрутизатор IP-пакетов. Она является либо частью операционной системы, либо, встроена в соответствующее оборудование. И к этой программе название «прокси» не применяют. Важное отличие маршрутизатора от прокси — при использовании маршрутизатора IP-пакеты остаются без изменений — в них сохраняются исходные адреса компьютеров локальной сети. А прокси всегда работает от своего «имени» и адреса клиентов не передаются, т.е. недоступны из Интернета. Маршрутизатор, меняющий адреса, уже является прокси (его называют NAT-proxy, NAT = network address translation).
Какие бывают виды прокси? Упомянутый выше NAT-proxy — самый простой вид прокси. Проблема NAT-proxy в ограниченности его возможностей. Он не анализирует информацию тех прикладных протоколов, которые через себя пропускают, поэтому и не имеют средств управления ими. Специализированные прокси (свой вид для каждого протокола) имеют ряд преимуществ и с точки зрения администраторов, и с точки зрения пользователей:
HTTP-proxy — самый распространенный. Он предназначен для организации работы браузеров и других программ, использующих протокол HTTP. Браузер передает прокси-серверу URL ресурса, прокси-сервер получает его с запрашиваемого веб-сервера (или с другого прокси-сервера) и отдает браузеру. У HTTP-proxy широкие возможности при выполнении следующих задач:
а) Можно сохранять полученные файлы на диске сервера. Впоследствии, если запрашиваемый файл уже скачивался, то можно выдать его с диска без обращения в интернет — увеличивается скорость и экономится внешний трафик. Эта опция называется кэшированием и именно её считают чуть ли не главной функцией прокси. Однако современный интернет очень динамичен, страницы часто формируются «на лету» и т.д. — такие данные кэшировать нельзя (веб-серверы обычно вставляют в HTTP-заголовки специальные указания об этом). Хотя многие прокси можно настроить так, чтобы эти указания частично игнорировались — например, перечитывать страницу не чаще одного раза в день.
б) Можно ограничивать доступ к ресурсам. Например, завести «черный список» сайтов, на которые прокси не будет пускать пользователей (или определенную часть пользователей, или в определенное время и т.д.). Ограничения можно реализовать по-разному. Можно просто не выдавать ресурс — например, выдавая вместо него страницу «запрещено администратором» или «не найдено». Можно спрашивать пароль и авторизованных пользователей допускать к просмотру. Можно, не спрашивая пароля, принимать решение на основании адреса или имени компьютера пользователя. Условия и действия могут быть очень разными.
Из перечисленных возможностей HTTP-proxy видно, насколько его использование может быть полезно в серьезной сети.
FTP-proxy бывает двух основных видов в зависимости от протокола работы самого прокси. С ftp-серверами этот прокси, конечно, всегда работает по протоколу FTP. А вот с клиентскими программами — браузерами и ftp-клиентами (CuteFTP, FAR, и др.) прокси может работать как по FTP, так и по HTTP. Второй способ удобнее для браузеров, т.к. исторически является для них «родным». Браузер запрашивает ресурс у прокси, указывая протокол целевого сервера в URL — http или ftp. В зависимости от этого прокси выбирает протокол работы с целевым сервером, а протокол работы с браузером не меняется — HTTP. Поэтому, как правило, функцию работы с FTP-серверами также вставляют в HTTP-proxy , т.е. HTTP-proxy , описаный выше, обычно с одинаковым успехом работает как с HTTP, так и с FTP-серверами. Но при «конвертации» протоколов FTP<->HTTP теряется часть полезных функций протокола FTP. Поэтому специализированные ftp-клиенты предпочитают и специальный прокси, работающий с обеими сторонами по FTP. Такой прокси называется FTP-gate, чтобы подчеркнуть отличие от FTP-proxy в составе HTTP-proxy . Также этот прокси называется и в некоторых ftp-клиентах. FTP-gate поддерживают различные способы указания в FTP-протоколе целевого сервера, с которым FTP-клиент хочет работать, в настройке FTP-клиентов обычно предлагается выбор этого способа, например как показано на рисунке ниже:
Здесь USER user@site, OPEN site, и т.д. — способ указания сервера, с которым производится работа. Такое многообразие связано с тем, что нет общепринятого стандарта на этот вид прокси, и применяются такие хитрые добавки к стандартным командам FTP-протокола.
HTTPS-прокси — фактически часть HTTP-proxy. "S" в названии означает "secure", т.е. безопасный. Не смотря на то, что программно это часть HTTP-proxy , обычно HTTPS выделяют в отдельную категорию (и есть отдельное поле для него в настройке браузеров). Обычно этот протокол применяют, когда требуется передача секретной информации, например, номеров кредитных карт. При использовании обычного HTTP-proxy всю передаваемую информацию можно перехватить средствами самого прокси (т.е. это под силу администратору локальной сети). Или на более низком уровне, например, tcpdump (т.е. и администратор провайдера и любого промежуточного узла и вообще — любой человек, имеющий физический доступ к маршрутам передачи ваших данных по сети, может при большом желании узнать ваши секреты). Поэтому в таких случаях применяют secure HTTP — всё передаваемое при этом шифруется. Прокси-серверу при этом дается только команда «соединится с таким-то сервером», и после соединения прокси передает в обе стороны шифрованный трафик. Но при этом отсутствует возможность узнать подробности (соответственно, отсутствуют и многие средства управления доступом — такие, как фильтрация картинок — не могут быть реализованы для HTTPS, т.к. прокси в этом случае неизвестно, что именно передается). Собственно, в процессе шифрации/дешифрации прокси тоже участия не принимает — это делают клиентская программа и целевой сервер. Наличие команды «соединиться с таким-то сервером» в HTTPS-прокси приводит к интересному и полезному побочному эффекту, которым все чаще пользуются разработчики клиентских программ. Так как после соединения с указанным сервером HTTPS-прокси лишь пассивно передает данные в обе стороны, не производя никакой обработки этого потока вплоть до отключения клиента или сервера, это позволяет использовать прокси для передачи почти любого TCP-протокола, а не только HTTP. То есть HTTPS-прокси одновременно является и простым POP3-прокси, SMTP-прокси, IMAP-прокси, NNTP-прокси и т.д. Никаких модификаций целевого сервера не требуется. Фактически HTTPS-прокси является программируемым mapping-proxy, как и Socks-proxy.
Mapping-proxy — способ заставить работать через прокси те программы, которые умеют работать с Интернетом только напрямую. При настройке такого сервиса администратор как бы создает «копию» целевого сервера, но доступную через один из портов прокси-сервера для всех клиентов локальной сети — устанавливает локальное «отображение» заданного сервера. Например, пользователи локальной сети хотят работать с почтовым сервером Mail.ru не через браузер, а с использованием почтовой программы Outlook Express или TheBat. Простейший способ работать с Mail.ru по POP3, т.е. установить через прокси локальное отображение сервера pop.mail.ru. И в Outlook вместо pop.mail.ru написать имя прокси-сервера и порт отображения. Outlook будет соединяться с прокси-сервером («думая», что это почтовый сервер), а прокси при этом будет соединяться с pop.mail.ru и прозрачно передавать всю информацию между Outlook и pop.mail.ru, таким образом «превращаясь» на время соединения в POP3-сервер. Неудобство Mapping-proxy в том, что для каждого необходимого внешнего сервера нужно вручную устанавливать отдельный порт на прокси. Но зато не требуется модификации ни серверов, ни клиентов. Особенно это помогает в случае необходимости «проксирования» многочисленных «доморощенных» протоколов, реализованных в играх или финансовых программах. Почему-то они часто игнорируют существование прокси и стандартных протоколов. Такие программы можно «обмануть» и направить через прокси практически всегда, если они не делают другой глупости — передачи клиентского IP-адреса внутри протокола и пытаются с ним соединяться напрямую еще раз (что невозможно, т.к. локальные адреса недоступны извне).
Socks-proxy. Разработан Дейвом Кобласом (Dave Koblas) из компании SGI. С начала существования протокол пережил несколько больших модификаций, а на сегодняшний день «в работе» находятся две версии протокола: Socks4 и Socks5. Не смотря на то, что Socks5 более «продвинут», сейчас с одинаковой степени распространены сервера как с поддержкой старой, так и новой версии. Протокол представляет собой транслятор (что-то вроде прокси сервера), но в отличие от обычных прокси Socks-клиент «сидит» между прикладным и транспортным уровнем в сетевой модели, а Socks-сервер находиться на прикладном уровне. Это означает, что такой сервер не привязан больше к протоколам высокого уровня. Сам протокол разработан для того, чтобы приложения, работающие на основе tcp и udp, могли использовать ресурсы сети, доступ к которым ограничен архитектурой или настройками (например, доступ к ресурсам Интернета из локальной сети для приложений, у которых вообще не предусмотрена работа с использованием прокси).
Теперь рассмотрим отличия версий протокола. Socks4 решает вопрос незащищенного пересечения межсетевых экранов приложениями клиент/сервер, основанными на протоколе TCP. Socks5 (RFC 1928), является дальнейшим расширением четвертой версии и включает в себя UDP. Он расширяет общую рамочную структуру (придавая ей, возможность использования мощных обобщенных схем идентификации) и систему адресации, включая в нее имя домена и адреса IP v.6. Socks4 поддерживает tcp, а Socks5 поддерживает tcp, udp, авторизацию и удаленный dns-запрос.
Вследствие того, что Socks не имеет никакого отношения к http, то данный вид прокси игнорирует все вопросы, связанные с модернизацией заголовков http-запросов. Socks-сервер будет передавать все данные в чистом виде от первого лица — то есть от себя. Другими словами можно сказать, что все Socks-серверы «анонимны». Socks не передает информацию о вашем ip-адресе, потому что это не предусмотрено его технологией. Соответственно отпадает множество проблем — например, кроме того, что он не передает ip-адрес, он, естественно, не модернизирует http-заголовки — и web-сервер никаким образом не может определить, что вы используете прокси. Для него работа с вами будет абсолютно прозрачной, как если бы вы работали с ним непосредственно. С той лишь разницей, что он будет видеть совсем другой ip-адрес.
25