Пользователи системы



страница38/42
Дата01.12.2017
Размер5.38 Mb.
ТипПрограмма
1   ...   34   35   36   37   38   39   40   41   42

Транспортный уровень


Транспортных протоколов в TCP/IP два – это TCP (Transmission ControlProtocol, протокол управления соединением) и UDP (User Datagram Protocol). UDP устроен просто. Пользовательские данные помещаются в единственный транспортный пакет-датаграмму, которой приписываются обычные для транспортного уровня данные: адреса и порты отправителя и получателя, после чего пакет уходит в сеть искать адресата. Проверять, был ли адресат способен этот пакет принять, дошел ли пакет до него и не испортился ли по дороге, предоставляется следующему – прикладному – уровню.

Иное дело – TCP. Этот протокол очень заботится о том, чтобы передаваемые данные дошли до адресата в целости и сохранности. Для этого предпринимаются следующие действия:



  1. Устанавливается соединение

Перед тем, как начать передавать данные, TCP проверяет, способен ли адресат их принимать. Если адресат отвечает согласием на открытие соединения, устанавливается двусторонняя связь между ним и отправителем. Помимо адресов отправителя и адресата и номеров портов на отправителе и адресате, в TCP-соединении участвуют два номера последовательности (SEQuential Number, SEQN), с помощью которых каждая сторона проверяет, не потерялись ли пакеты по пути, не перепутались ли.

  1. Обрабатываются подтверждения

Двусторонняя связь нужна еще и потому, что на каждый TCP-пакет с любой стороны требуетсяподтверждение того, что этот пакет принят. Упрощенно можно представить дело так, что отправитель и адресат по очереди обмениваются пакетами, каждый из которых содержит подтверждение только что принятого, и, возможно, полезные данные. Если происходит какая-то ошибка, она возвращается вместо подтверждения и отправитель обрабатывает ее (например, поcылает пакет еще раз).

  1. Отслеживаются состояния абонентов

С первым же подтверждением каждый из абонентов передает размер т. н. скользящего окна (sliding window). Этот размер показывает, сколько еще данных готов принять адресат. Отправитель посылает сразу несколько пакетов суммарным размером с это окно, а после ждет подтверждения об их принятии. Когда приходит подтверждение первого из пакетов в окне, окно "скользит" вперед: теперь оно начинается со второго пакета, и в него попадает один или несколько еще не посланных пакетов. Если адресат может принять больше данных, он сообщает о большем размере окна, а если данные перерабатываться не успевают – о меньшем.

Кажется, что TCP – протокол во всех отношениях более удобный, чем UDP. Однако в тех случаях, когда пользовательские данные всегда помещаются в один пакет, зато самих пакетов идет очень много, посылать всего одну датаграмму намного выгоднее, чем всякий раз устанавливать соединение, пересылать данные и закрывать соединение (что требует, как минимум, по три пакета в каждую сторону). Очень трудно использовать TCP для широковещательных передач, когда число абонентов-адресатов весьма велико или вовсе неизвестно. Посмотреть параметры всех передаваемых через сетевой интерфейс пакетов можно с помощью команды tcpdump -piинтерфейс, хотя Мефодию не хватило поверхностного знания TCP/IP для того, чтобы понять выдачу этой команды.


Прикладной уровень


Как бы ни был надежен протокол TCP, он не имеет никакого понятия о том, что же, собственно, за данные с его помощью передаются. Да и не должен: принцип разделения уровней не позволяет заглядывать "внутрь" передаваемого пакета, и способов наверняка распознать используемый в нем прикладной протокол нет. Прикладной уровень, в отличие от транспортного, предусматривает сколько угодно протоколов передачи данных. Интерпретация данных, в конце концов, дело уже не ядра, а какой-нибудь программы ("приложения", как правило,демона). Для того чтобы можно было предположить, какой протокол используется при передаче данных, а также для того, чтобы система могла передать эти данные соответствующей программе, еще на транспортном уровне было введено понятие порта.

Клиент-серверная модель


С точки зрения прикладного уровня, порт – это идентификатор сервиса, предоставляемого системой. В самом деле, практически любой акт передачи данных выглядит, как если бы некий клиент, которому эти данные нужны, запрашивал их у сервера, который может их предоставить1). Отношения между программами, которые связываются по сети друг с другом, почти всегда асимметричны: одной что-то надо, у другой это что-то есть. При установлении соединения и приложение (программа-клиент), и служба (программа-сервер) используют механизмсокетов, описанный в лекции 11, однако ведут себя по-разному.

Служба, запускаясь на сервере, создает сетевой сокет и прикрепляет его к определенному порту сервера с помощью системного вызова bind(). Затем она регистрируется в качестве обработчика запросов (listener), приходящих на этот порт. Служба ждет запросов, и когда они поступают, предпринимает какие-нибудь действия, например, считывает пришедшие данные и анализирует их в соответствии со своим протоколом, отсылает какие-то данные абоненту, пославшему запрос и т. п.

Приложение, запускаясь на клиенте, также создает сокет и присоединяется с его помощью к тому же порту насервере, где запущена служба, используя системный вызов connect(). Затем оно, как и служба, посылает и получает данные. Разницы между обменом данными по сетевому сокету и по сокету в файловой системе нет. Очередность обмена данными определяется прикладным протоколом.

Как приложение узнает, к какому именно порту необходимо подключиться? За большинством прикладных протоколов закреплен постоянный номер порта. Постоянные номера портов и названия соответствующих протоколов хранятся в файле /etc/services:

[root@localhost root]# wc /etc/services

553 2794 19869 /etc/services

[root@localhost root]# egrep "^(ftp|http|smtp|ssh).*tcp" /etc/services

ftp 21/tcp # File Transfer [Control]

ssh 22/tcp # SSH Remote Login Protocol

smtp 25/tcp mail # Simple Mail Transfer Protocol

http 80/tcp www www-http # World Wide Web HTTP

Пример 14.6. Постоянные номера портов для некоторых протоколов (html, txt)

Этот файл – не догма, а руководство к действию: каждый может организовать, допустим, сервис HTTP по 25-мупорту. Только как об этом узнают другие клиенты и что подумают почтовые программы, ожидая по этому портувстретить сервис SMTP (пересылка почты)? Вывести список установленных соединений, а также служб-обработчиков можно командой netstat:

[root@localhost root]# netstat -anA inet

Active Internet connections (servers and established)

Proto Recv-Q Send-Q Local Address Foreign Address State

tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN

tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN

tcp 0 0 192.168.102.125:22 192.168.102.1:33208 ESTABLISHED

udp 0 0 0.0.0.0:11 0.0.0.0:*

Пример 14.7. Просмотр установленных соединений и служб (html, txt)

Здесь видно, что на компьютере зарегистрировано два TCP-обработчика (на портах 111 и 22), один UDP-обработчик по 11-му порту (понятие Listener, то есть обработчик соединения для UDP не имеет смысла), а также установлено одно соединение с компьютера 192.168.102.1, исходящий порт 33208, к 22-му порту (это порт службы Secure Shell, предоставляющей удаленный терминальный доступ... видимо, Гуревич работает?). В более сложных случаях, когда номер порта заранее неизвестен, а известно только название и версия сервиса, используется служба portmap, которая раздает незанятые порты службам и сообщает приложениям, к какому из них надо обратиться. Порт 111 соответствует именно этой службе.


Обслуживание прикладного уровня в Linux


Самый простой способ проверить, предоставляет ли некий сервер услуги по некоему TCP-порту – это подключиться к нему. Если под рукой нет приложения, работающего по соответствующему протоколу, не беда: подойдет утилита telnet. В качестве первого параметра следует указатьадрес компьютера, к которому нужно подключиться, а в качестве второго (необязательного) – номер порта. Когда-то эта утилита использовалась в качестве клиента к терминальной службе, однако от нее пришлось отказаться: пароль пользователя передавался по сети незашифрованным. Но в качестве клиента других служб, многие из которых используют текстовые протоколы, telnet используется и поныне. Если даже протокол не текстовый, можно выйти в командный режим telnet, нажав "^[", и подать команду close, которая закроет соединение:

[root@localhost root]# telnet 192.168.102.1 112

Trying 192.168.102.1...

telnet: connect to address 192.168.102.1: Connection refused

[root@localhost root]# telnet 192.168.102.1 111

Trying 192.168.102.1...

Connected to 192.168.102.1.

Escape character is '^]'.

^[

telnet> close



Connection closed.

Пример 14.8. Использование telnet (html, txt)

В сценариях вместо интерактивной утилиты telnet стоит использовать netcat, которая работает как cat в указанный сокет или из него. Как уже говорилось, интерпретацией прикладных протоколов занимаются разнообразные программы. Прикладной протокол можно представить как обмен сообщениями, часто текстовыми, между клиентом и сервером. Было бы естественно оформлять такие программы в виде фильтров, чтобы пользоваться простейшими функциями ввода-вывода. Однако механизм сокетов предусматривает асинхронную передачу данных, для чего используются другие функции. Программа, желающая обслуживать сетевые соединения по определенному порту, должна удовлетворять четырем требованиям:



  1. Быть демоном, то есть постоянно находиться в памяти;

  2. Создавать сокет, прикреплять его к порту;

  3. Регистрироваться как обработчик по этому сокету и принимать соединения (возможно, придется обрабатывать несколько соединений одновременно);

  4. Анализировать прикладной протокол и действовать по результатам анализа.

Нетрудно заметить, что первые три свойства – общие для большинства сервисов. В Linux есть метадемон inetd, который берет на себя всю общую сетевую часть работы, а программам предоставляет разбираться в прикладном протоколе. Организовать свой сетевой сервис с помощью inetd становится очень просто: пользователь программирует фильтр, задача которого – обмениваться командами прикладного протокола с помощью стандартного ввода и стандартного вывода. Этот фильтр регистрируется в настройках inetd с указанием порта, с которого будут приниматься запросы. После чего сам inetd становится обработчиком запросов по всем указаннымпортам, сам открывает соединение, запуская соответствующий фильтр, а данные из сокета пересылает туда и обратно по двум каналам. При этом фильтр-обработчик даже не должен быть демоном: это обычная программа, которая завершается, когда это предусмотрено прикладным протоколом, или когда закрывается входной поток.

Мефодий минут за пять написал службу, которая в ответ на подключение передает календарь на текущий месяц. В его системе используется модернизированная версия inetd – xinetd, обученная чтению конфигурационных файлов по схеме ".d":

[root@localhost root]# grep quake /etc/services

quake 26000/tcp

quake 26000/udp

[root@localhost root]# cat /etc/xinetd.d/calendar

service quake

{

socket_type = stream



protocol = tcp

wait = no

user = nobody

server = /usr/bin/cal

disable = no

}

Пример 14.9. Настройка cal в качестве сетевой службы (html, txt)

Вместо номера порта можно использовать название протокола из /etc/services. Мефодий воспользовался портом26000 (чем мог создать некоторые трудности любителям одной компьютерной игры). Осталось только перезагрузитьxinetd, чтобы он нашел новый конфигурационный файл, и подключиться к порту 26000:

[root@localhost root]# service xinetd restart

Stopping xinetd service: [ DONE ]

Starting xinetd service: [ DONE ]

[root@localhost root]# telnet localhost quake

Trying 127.0.0.1...

Connected to localhost.

Escape character is '^]'.

December 2004

Su Mo Tu We Th Fr Sa

1 2 3 4

5 6 7 8 9 10 11



12 13 14 15 16 17 18

19 20 21 22 23 24 25

26 27 28 29 30 31

Пример 14.10. Подключение к самодельной службе "календарь" (html, txt)

Служба доменных имен


В предыдущих примерах Мефодий использовал ключ "-n" многих сетевых утилит, чтобы избежать путаницы между IP-адресами и доменными именамикомпьютеров. С другой стороны, доменные имена – несколько слов (часто осмысленных) —запоминать гораздо удобнее, чем адреса (четыре числа).

Когда-то имена всех компьютеров в сети, соответствующие IP-адресам, хранились в файле /etc/hosts. Пока абоненты Internet были наперечет, поддерживать правильность его содержимого не составляло труда. Как только сеть начала расширяться, неувязок стало больше. Трудность была не только в том, что содержимое hosts быстро менялось, но и в том, что за соответствие имен адресам в различных сетях отвечали разные люди и разные организации. Появилась необходимость структурировать глобальную сеть не только топологически (с помощью IP и сетевых масок), но иадминистративно, с указанием, за какие группы адресов кто отвечает.

Проще всего было структурировать сами имена компьютеров. Вся сеть была поделена на домены – зоны ответственности отдельных государств ("us", "uk", "ru", "it" и т. п.) или независимые зоны ответственности ("com", "org", "net", "edu" и т. п.). Для каждого из таких доменов первого уровня должно присутствовать подразделение, выдающее всем абонентам имена, заканчивающиеся на ".домен" Подразделение обязано организовать и поддерживать службу, заменяющую файл hosts: любой желающий имеет право узнать, какой IP-адрес соответствует имени компьютера в этомдомене или какому доменному имени соответствует определенный IP-адрес.

Такая служба называется DNS (Domain Name Service, служба доменных имен). Она имеет иерархическую структуру. Если за какую-то группу абонентов домена отвечают не хозяева домена, а кто-то другой, ему выделяется поддомен (или домен второго уровня), и он сам распоряжается именами вида"имя_компьютера.поддомен.домен". Например, за компьютеры в домене ".ru", принадлежащие корпорации "Dry Bugs", отвечают сотрудники соответствующего подразделения этой корпорации. Корпорация владеет поддоменомdbugs.ru. В домене ru не обязаны знать, какие именно адреса есть в поддомене, но обязаны предоставить информацию о том, как обратиться к серверу имен поддомена dbugs.ru.Сами сотрудники "Dry Bugs" тоже отвечают только за несколько собственных компьютеров, а всю ответственность за компьютеры в подразделениях перекладывают на сетевых администраторов этих подразделений, выделив им поддомены третьего уровня –pr.dbugs.ru, cook.dbugs.ru и warehouse.dbugs.ru. Таким образом, получается нечто вроде распределенной сетевой базы данных, хранящей короткие записи о соответствии доменных имен IP-адресам.



Доменное имя. Имя абонента Internet, имеющее текстовый формат и используемое вместо IP-адреса. Состоит из собственного имени абонента в домене и имени домена, определяющего административную принадлежность абонента. В отличие от IP-адреса, доменное имя не задается самим абонентом сети, а устанавливается службойдоменных имен.

Все программы, работающие с доменными именами, оказываются клиентами какого-нибудь сервера доменных имен (DNS-сервера). Для этого они обращаются к функциям из библиотеки libresolv (или им подобным), а те уже определяют, как превратить доменное имя в адрес. Функции используют файл /etc/host.conf, описывающий, какими способами они должны выполнять преобразование доменных имен в адреса и обратно, а также формат выдачи данных в различных случаях. Обычно сначала проверяется файл /etc/hosts, а если там соответствий не найдено – /etc/resolv.conf. В resolv.conf указан домен по умолчанию (он приписывается в конец имени, если другим способом имя никак не удается преобразовать в адрес) и один-два адреса DNS-серверов, к которым и обращаются функции. В роли таких клиентов выступили утилиты ping и traceroute в предыдущих примерах, преобразуя имя www.ru в адрес 194.87.0.50. Если утилите traceroute не указывать ключ "-n", она подаст несколько DNS-запросов, по одному на каждый маршрутизатор, на обратное преобразование – из IP-адреса вдоменное имя:

order hosts,bind

multi on


[root@localhost root]# cat /etc/resolv.conf

domain nipponman.ru

nameserver 192.168.102.1

[root@localhost root]# traceroute -q1 www.ru

traceroute to www.ru (194.87.0.50), 30 hops max, 38 byte packets

1 fuji.nipponman.ru (192.168.102.1) 1.378 ms

2 ppp83-237-29-1.pppoe.mtu-net.ru (83.237.29.1) 41.155 ms

3 195.34.53.53 (195.34.53.53) 48.503 ms

4 195.34.53.53 (195.34.53.53) 24.033 ms

5 M9-cr01-A197-cr01.core.mtu.ru (195.34.53.10) 33.414 ms

6 M9-gw2-M9-cr01.core.mtu.ru (195.34.53.81) 26.259 ms

7 s-b3-pos0-0.telia.net (213.248.67.93) 59.791 ms

8 s-bb1-pos5-0-0.telia.net (213.248.66.1) 67.011 ms

9 mow-b1-pos1-0.telia.net (213.248.101.10) 76.138 ms

10 demos-101566-mow-okt-i1.c.telia.net (213.248.78.170) 78.591 ms

11 m9-3-GE4-0-0-vl10.Demos.net (194.87.0.66) 69.813 ms

12 www.ru (194.87.0.50) 70.583 ms

Пример 14.11. Работа DNS-клиента, встроенного в traceroute (html, txt)

Как видно из примера, обратное преобразование в современной сети работает не всегда. Отсутствие обратной зоны не поощряется сообществом, но и не считается преступлением. Мефодий заметил, что компьютер, не имеющий обратного преобразования адреса, вообще какой-то странный: один раз он передал пакет сам себе(здесь Мефодий не совсем прав: на самом деле этот маршрутизатор отчего-то уменьшает TTL пакета на 2, поэтому-то и на третьем, и на четвертом шаге именно он возвращает ICMP-сообщение). Кстати сказать, именно по причине того, что DNS- запрос невелик, зато даже один абонент сети может выдать их множество, основным транспортным протоколом для DNS выбран UDP, а не TCP (это не касается протоколов обмена целыми зонами между DNS-серверами – там, конечно, господствует TCP).

Если вся задача пользователя – это послать DNS-запрос, то лучше воспользоваться утилитой host, специально для этого предназначенной:

methody@localhost:~ $ host www.ru

www.ru has address 194.87.0.50

methody@localhost:~ $ host 194.87.0.51

51.0.87.194.in-addr.arpa domain name pointer www.demos-internet.ru.

methody@localhost:~ $ host -t ns www.ru

www.ru name server ns.demos.su.

www.ru name server ns1.demos.net.

methody@localhost:~ $ host -t mx www.ru

www.ru mail is handled by 5 hq.demos.ru.



Пример 14.12. Утилита host (html, txt)

Довольно необычен формат, в котором хранятся таблицы обратного преобразования адресов. Оказывается, IP-адрес представлен в такой таблице как имя в домене in-addr.arpa, причем это имя совпадает с адресом, записанным задом наперед. Такой формат идет от иерархической структуры DNS. Если некоторая организация получает во владение сеть, допустим, 194.0.0.0/8, она должна обслуживать DNS-запросы к домену 194.in-addr.arpa. Если при этом сеть 194.87.0.0/16 передана другой организации, ей же передается обязанность обслуживать DNS-запросы к поддомену этого домена – 87.194.in-addr.arpa, и так вплоть до собственно IP-адресов. Вместо host можно использовать утилиту dig, которая выводит больше информации о том, как проходил сам запрос.

Помимо записей типа "адрес" (A, прямое преобразование) и "указатель на имя" (PTR, обратное преобразование), в системе DNS может храниться и другая информация. Таблица (зона) некоторого домена должна содержать адресадоменных серверов всех его поддоменов (записи типа NS). Кроме того, в домене должно быть определено имяпочтового пересыльщика (запись типа MX). Если почтовый пересыльщик домена не указан, электронная почта направляется почтовому пересыльщику родительского домена.

В зоне DNS есть даже запись типа "просто текст", TXT: при желании можно самому определить интерпретацию полей этой записи и организовать поверх DNS предназначенную для каких угодно целей базу данных по IP-адресам или доменным именам1). В отличие от dig, которой для запроса к обратной зоне требуется ключ "-x", утилитаhost различает запросы к прямой и обратной зонам по тому, задан ли в качестве параметра адрес или доменное имя. Для указания конкретного типа искомой записи обеим утилитам требуется этот тип передать явно. Тип anyозначает поиск всех записей с указанным именем:

methody@localhost:~ $ dig www.us any

; <<>> DiG 9.2.4rc5 <<>> www.us any

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6451

;; flags: qr rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 4

;; QUESTION SECTION:

;www.us. IN ANY

;; ANSWER SECTION:

www.us. 1766 IN A 209.173.57.26

www.us. 1766 IN A 209.173.53.26

www.us. 1767 IN NS pine.neustar.com.

www.us. 1767 IN NS willow.neustar.com.

www.us. 1767 IN NS cypress.neustar.com.

www.us. 1767 IN NS oak.neustar.com.

www.us. 1771 IN MX 20 pine.neustar.com.

www.us. 1771 IN MX 5 oak.neustar.com.

www.us. 1771 IN MX 5 willow.neustar.com.

www.us. 1771 IN MX 10 cypress.neustar.com.

;; ADDITIONAL SECTION:

pine.neustar.com. 135024 IN A 209.173.57.70

willow.neustar.com. 135024 IN A 209.173.53.84

cypress.neustar.com. 135024 IN A 209.173.57.84

oak.neustar.com. 135024 IN A 209.173.53.70

;; Query time: 932 msec

;; SERVER: 192.168.102.1#53(192.168.102.1)

;; WHEN: Wed Dec 22 22:01:24 2004

;; MSG SIZE rcvd: 281



Пример 14.13. Утилита dig (html, txt)

Основная особенность программного обеспечения Linux – многообразие продуктов, решающих сходные задачи, особенно если дело касается области, в которой существует несколько подходов к их решению. Открытая модель разработки программ, описанная далее в лекции 18, позволяет любому выбрать самый подходящий для него инструмент и развивать именно его. Поэтому список проектов, так или иначе связанных с Linux, насчитывает десятки (или даже сотни) тысяч наименований.

Конечно же, работа с самой операционной системой не может быть самоцелью. Все усилия Мефодия по изучению операционной системы Linux и основных утилит нужны были для того, чтобы он впоследствии мог наилучшим образом решать в этой операционной системе любые из своих прикладных задач, разрешимых при помощи компьютера. Как уже уяснил Мефодий, для очень многих задач достаточно стандартных инструментов Linux и текстового редактора, однако есть случаи, в которых все-таки необходима специальная прикладная программа, именно для этого предназначенная, или в которых специальная программа удобнее комбинации стандартных утилит.

В этой лекции дается краткий обзор прикладных программ для Linux, специально предназначенных для решения разнообразных пользовательских задач. Материал, вошедший в эту лекцию, следует воспринимать только как пример, демонстрацию того, что и как можно делать в Linux, но вовсе не как исчерпывающий список. В отличие от основных принципов устройства системы или стандартных утилит, обсуждавшихся в предыдущих лекциях, которые не изменяются (почти) в течение десятилетий, прикладное программное обеспечение – это область, где все меняется очень быстро. Технологии, сегодня считающиеся самыми передовыми, уже через несколько месяцев могут устареть. Вместе с ними могут устареть использующие их программы, а другие программы могут, наоборот, перейти в разряд наиболее современных и развитых. Поэтому перечисленные в этой лекции прикладные программы – это не безусловная рекомендация, а довольно случайная выборка, отражающая текущее состояние дел в разработке приложений для Linux. Самый лучший способ найти и выбрать подходящие прикладные программы для своих задач – посоветоваться с людьми, которые решают подобные задачи в Linux в настоящее время, и попробовать.

Нужно отдавать себе отчет в том, что прикладные программы для Linux не являются частью самой Linux, поэтому любой из названных ниже программ может не оказаться в каком-то из конкретных дистрибутивов Linux. Но почти наверняка в любом дистрибутиве найдется не меньше одной или даже нескольких программ для решения каждой из перечисленных ниже прикладных задач. Чтобы не загромождать изложение, мы остановимся лишь на самых распространенных программных продуктах, входящих во многие дистрибутивы Linux.




Поделитесь с Вашими друзьями:
1   ...   34   35   36   37   38   39   40   41   42


База данных защищена авторским правом ©vossta.ru 2019
обратиться к администрации

    Главная страница