Текст книги "UNIX: разработка сетевых приложений"

Автор книги: Уильям Ричард Стивенс

Соавторы: Эндрю М. Рудофф,Билл Феннер
сообщить о нарушении

Текущая страница: 3 (всего у книги 88 страниц) [доступный отрывок для чтения: 32 страниц]

1.7. Модель OSI

Распространенным способом описания уровней сети является предложенная Международной организацией по стандартизации (International Standards Organization, ISO) модель взаимодействия открытых систем( open systems interconnection, OSI). Эта семиуровневая модель показана на рис. 1.5, где она сравнивается со стеком протоколов Интернета.

Рис. 1.5. Уровни модели OSI и набор протоколов Интернета

Мы считаем, что два нижних уровня модели OSI соответствуют драйверу устройства и сетевому оборудованию, которые имеются в системе. Обычно нам не приходится беспокоиться об этих уровнях, за исключением того, что мы должны знать некоторые свойства канального уровня – например, что MTU (максимальная единица передачи) Ethernet, которая описывается в разделе 2.11, имеет размер 1500 байт.

Сетевой уровень управляется протоколами IPv4 и IPv6, оба они описываются в приложении А. Из протоколов транспортного уровня мы можем выбирать TCP, UDP и SCRIPT, они описываются в главе 2. На рис. 1.5 изображен разрыв между TCP и UDP; это означает, что приложение может обойти транспортный уровень и использовать IPv4 или IPv6 непосредственно. В таких случаях речь идет о символьных сокетах( raw socket), которые будут описаны в главе 28.

Три верхних уровня модели OSI соответствуют уровню приложений. Приложением может быть веб-клиент (браузер), клиент Telnet, веб-сервер, сервер FTP или любое другое используемое нами приложение. В случае протоколов Интернета три верхние уровня модели OSI разделяются очень редко.

Описанный в этой книге API сокетов является интерфейсом между верхними тремя уровнями («приложением») и транспортным уровнем. Это один из важнейших вопросов книги: как создавать приложения, используя сокеты TCP и UDP. Мы уже упоминали о символьных сокетах, и в главе 29 мы увидим, что можем даже полностью обойти уровень IP, чтобы читать и записывать свои собственные кадры канального уровня.

Почему сокеты предоставляют интерфейс между верхними тремя уровнями модели OSI и транспортным уровнем? Для подобной организации модели OSI имеются две причины, которые мы отобразили на правой стороне рис. 1.5. Прежде всего, три верхних уровня отвечают за все детали, имеющие отношение к приложению (например, FTP, Telnet, HTTP), но знают мало об особенностях взаимодействия по сети. Четыре же нижних уровня знают мало о приложении, но отвечают за все, что связано с коммуникацией: отправку данных, ожидание подтверждения, упорядочивание данных, приходящих не в должном порядке, расчет и проверку контрольных сумм и т.д. Второй же причиной является то, что верхние три уровня часто формируют так называемый пользовательский процесс( user process), в то время как четыре нижних уровня обычно поставляются как часть ядра операционной системы. Unix, как и многие современные операционные системы, обеспечивает разделение пользовательского процесса и ядра. Следовательно, интерфейс между уровнями 4 и 5 является естественным местом для создания API.

1.8. История сетевого обеспечения BSD

API сокетов происходит от системы 4.2BSD (Berkeley Software Distribution – программное изделие Калифорнийского университета, в данном случае – адаптированная для Интернета реализация операционной системы Unix, разрабатываемая и распространяемая этим университетом), выпущенной в 1983 году. На рис. 1.6 показано развитие различных реализаций BSD и отмечены главные этапы развития TCP/IP. Некоторые изменения API сокетов также имели место в 1990 году в реализации 4.3BSD Reno, когда протоколы OSI были включены в ядро BSD.

Вертикальная цепочка систем на рис. 1.6 от 4.2BSD до 4.4BSD включает версии, созданные группой исследования компьютерных систем (Computer System Research Group, CSRG) университета Беркли. Для использования этих реализаций требовалось, чтобы у получателя уже была лицензия на исходный код для Unix. Однако весь код сетевых программ – и поддержка на уровне ядра (например, стек протоколов TCP/IP и доменные сокеты Unix, а также интерфейс сокетов), и приложения (такие, как клиенты и серверы Telnet и FTP), были разработаны независимо от кода Unix, созданного AT&T. Поэтому начиная с 1989 года университет Беркли начал выпускать реализации системы BSD, не ограниченные лицензией на исходный код Unix. Эти реализации распространялись свободно и, в конечном итоге, стали доступны через анонимные FTP-серверы фактически любому пользователю Интернета.

Последними реализациями Беркли стали 4.4BSD-Lite в 1994 году и 4.4BSD-Lite2 в 1995 году. Нужно отметить, что эти две реализации были затем использованы в качестве основы для других систем: BSD/OS, FreeBSD, NetBSD и OpenBSD, и все четыре до сих пор активно развиваются и совершенствуются. Более подробную информацию о различных реализациях BSD, а также общую историю развития различных систем Unix можно найти в главе 1 книги [74].

Рис. 1.6. История различных реализаций BSD

Многие системы Unix начинались с некоторой версии сетевого кода BSD, включавшей API сокетов, и мы называем их реализациями, происходящими от Беркли, или Беркли-реализациями( Berkeley-derived implementations). Многие коммерческие версии Unix основаны на Unix System V Release 4 (SVR4). Некоторые из них включают сетевой код из Беркли-реализаций (например, UnixWare 2.x), в то время как сетевой код других систем, основанных на SVR4, был разработан независимо (например, Solaris 2.x). Мы также должны отметить, что система Linux, популярная и свободно доступная реализация Unix, неотносится к классу происходящих от Беркли: ее сетевой код и API сокетов были разработаны «с нуля».

1.9. Сети и узлы, используемые в примерах

На рис. 1.7 показаны различные сети и узлы, используемые нами в примерах. Для каждого узла мы указываем операционную систему и тип компьютера (потому, что некоторые операционные системы могут работать на компьютерах разных типов). Внутри прямоугольников приведены имена узлов, появляющиеся в тексте.

Рис. 1.7. Сети и узлы, используемые в примерах

Топология, приведенная на рис. 1.7, интересна для наших примеров, но на практике физическая топология сети оказывается не столь важной, поскольку взаимодействующие компьютеры обычно связываются через Интернет. Виртуальные частные сети (virtual private network, VPN) и защищенные подключения интерпретатора (secure shell connections, SSH) обеспечивают соединение, не зависящее от физического размещения компьютеров.

Обозначение «/24» указывает количество последовательных битов адреса начиная с крайнего левого, задающих сеть и подсеть. В разделе А.4 об этом формате рассказывается более подробно.

ПРИМЕЧАНИЕ

Хотим подчеркнуть, что настоящее имя операционной системы Sun – SunOS 5.x, а не Solaris 2.x, однако все называют ее Solaris.

Определение топологии сети

На рис. 1.7 мы показываем топологию сети, состоящей из улов, используемых в качестве примеров в этой книге, но вам нужно знать топологию вашей собственной сети, чтобы запускать в ней примеры и выполнять упражнения. Хотя в настоящее время не существует стандартов Unix в отношении сетевой конфигурации и администрирования, большинство Unix-систем предоставляют две основные команды, которые можно использовать для определения подробностей строения сети: netstatи ifconfig. Мы приводим примеры в различных системах, представленных на рис. 1.7. Изучите руководство, где описаны эти команды для ваших систем, чтобы понять различия в той информации, которую вы получите на выходе. Также имейте в виду, что некоторые производители помещают эти команды в административный каталог, например /sbinили /usr/sbin, вместо обычного /usr/bin, и эти каталоги могут не принадлежать обычному пути поиска ( PATH).

1.  netstat – iпредоставляет информацию об интерфейсах. Мы также задаем флаг -nдля печати численных адресов, а не имен сетей. При этом показываются интерфейсы с их именами.

linux % netstat -ni

Kernel Interface table

Iface  MTU Met    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg

eth0  1500   0 49211085      0      0      0 40540958      0      0      0 BMRU

lo   16436   0 98613572      0      0      0 98613572      0      0      0 LRU

Интерфейс закольцовки называется lo, a Ethernet называется eth0. В следующем примере показан узел с поддержкой Ipv6.

freebsd % netstat -ni

Name  Mtu Network      Address              Ipkts Ierrs    Opkts Oerrs Coll

hme0 1500      08:00:20:a7:68:6b 29100435    35 46561488     0    0

hme0 1500 12.106.32/24 12.106.32.254     28746630     – 46617260     –    -

hme0 1500 fe80:1::a00:20ff:fea7 686b/64

                       fe80:1::a00:20ff:fea7:68b

                                                0      –       0     –    -

hme0 1500 3ffe:b80:1f8d:1::1/64

                       3ffe:b80:1f8d:1::1       0      –        0    –    -

hme1 1500      08:00:20:a7:68:6b    51092      0    31537    0    0

hme1 1500 fe80:2::a00:20ff:fea7:686b/64

                       fe80:2::a00:20ff:fea7:686b

                                                0      –       90    –    -

hme1 1500 192.168.42   192.168.42.1         43584      –    24173    –    -

hme1 1500 3ffe:b80:1f8d:2::1/64

                       3ffe:b80:1f8d:2::1      78      –        8    –    -

lo0 16384                           10198      0    10198    0    0

lo0 16384 ::1/128      ::1                     10      –       10    –    -

lo0 16384 fe80:6::1/64 fe80:6::1                0      –        0    –    -

lo0 16384 127          127.0.0.1            10167      –    10167    –    -

gif0 1280                               6      0        5    0    0

gif0 1280 3ffe:b80:3:9ad1::2/128

                       3ffe:b80:3:9ad1::2       0      –        0    –    -

gif0 1280 fe80:8::a00:20ff:fea7:686b/64

                       fe80:8::a00:20ff:fea7:686b

                                                0      –        0    –    -

Мы разбили некоторые длинные строки на несколько частей, чтобы сохранить ясность представления.

2.  netstat -rпоказывает таблицу маршрутизации, которая тоже позволяет определить интерфейсы. Обычно мы задаем флаг -nдля печати численных адресов. При этом также приводится IP-адрес маршрутизатора, заданного по умолчанию:

freebsd % netstat -nr

Routing tables

Internet:

Destination   Gateway           Flags Refs   Use Netif Expire

default       12.106.32.1       UGSc    10  6877 hme0

12.106.32/24  link#1            UC       3     0 hme0

12.106.32.1   00:b0:8e:92:2c:00 UHLW     9     7 hme0  1187

12.106.32.253 08:00:20:b8:f7:e0 UHLW     0     1 hme0   140

12.106.32.254 08:00:20:a7:68:b6 UHLW     0     2 lo0

127.0.0.1     127.0.0.1         UH       1 10167 lo0

192.168.42    link#2            UC       2     0 hme1

192.168.42.1  08:00:20:a7:68:6b UHLW     0    11 lo0

192.168.42.2  00:04:ac:17:bf:38 UHLW     2 24108 hme1   210

Internet6:

Destination                        Gateway            Flags Netif Expire

::/96                              ::1                UGRSc lo0   =>

default                            3ffe:b80:3:9ad1::1 UGSc  gif0

::1                                ::1                UH    lo0

::ffff:0.0.0.0/96                  ::1                UGRSc lo0

3ffe:b80:3:9ad1::1                 3ffe:b80:3:9ad1::2 UH    gif0

3ffe:b80:3:9ad1::2                 link#8             UHL   lo0

3ffe:b80:1f8d::/48                 lo0                USc   lo0

3ffe:b80:1f8d:1::/64               link#1             UC    hme0

3ffe:b80:1f8d:1::1                 08:00:20:a7:68:6b  UHL   lo0

3ffe:b80:1f8d:2::/64               link#2             UC    hme1

3ffe:b80:1f8d:2::1                 08:00:20:a7:68:6b  UHL   lo0

3ffe:b80:1f8d:2:204:acff:fe17:bf38 00:04.ac:17:bf:38  UHLW  hme1

fe80::/10                          ::1                UGRSc lo0

fe80::%hme0/64                     link#1             UC    hme0

fe80::a00:20ff:fea7:686b%hme0      08:00:20:a7:68:6b  UHL   lo0

fe80::%hme1/64                     link#2             UC    hme1

fe80::a00:20ff:fea7:686b%hme1      08:00:20:a7:68:6b  UHL   lo0

fe80::%lo0/64                      fe80::1%lo0        Uc    lo0

fe80::1%lo0                        link#6             UHL   lo0

fe80::%gif0/64                     link#8             UC    gif0

fe80::a00:20ff:fea7:686b%gif0      link#8             UHL   lo0

ff01::/32                          ::1                U     lo0

ff02::/16                          ::1                UGRS  lo0

ff02::%hme0/32                     link#1             UC    hme0

ff02::%hem1/32                     link#2             UC    hme1

ff02::%lo0/32                      ::1                UC    lo0

ff02::%gif0/32                     link#8             UC    gif0

3. Имея имена интерфейсов, мы выполняем команду ifconfig, чтобы получить подробную информацию для каждого интерфейса:

linux % ifconfig eth0

eth0 Link encap:Ethernet HWaddr 00:C0:9F:06:B0:E1

     inet addr:206.168.112.96 Bcast:206.168.112.127 Mask:255.255.255.128

     UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

     RX packets:49214397 errors:0 dropped:0 overruns:0 frame:0

     TX packets:40543799 errors:0 dropped:0 overruns:0 carrier:0

     collisions:0 txqueuelen:100

     RX bytes:1098069974 (1047.2 Mb) TX bytes:3360546472 (3204.8 Mb)

     Interrupt:11 Base address:0x6000

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

4. Одним из способов определить IP-адрес нескольких узлов локальной сети является проверка широковещательного адреса (найденного нами на предыдущем шаге) с помощью утилиты ping.

linux % ping -b 206.168.112.127

WARNING: pinging broadcast address

PING 206.168.112.127 (206.168.112.127) from 206.168.112.96 : 56 (84) bytes of data.

64 bytes from 206.168.112.96: icmp_seq=0 ttl=255 time=241 usec

64 bytes from 206.168.112.40: icmp_seq=0 ttl=255 time=2 566 msec (DUP!)

64 bytes from 206.168.112.118: icmp_seq=0 ttl=255 time=2.973 msec (DUP!)

64 bytes from 206.168.112.14: icmp_seq=0 ttl=255 time=3.089 msec (DUP!)

64 bytes from 206.168.112.126: icmp_seq=0 ttl=255 time=3.200 msec (DUP!)

64 bytes from 206.168.112.71: icmp_seq=0 ttl=255 time=3.311 msec (DUP!)

64 bytes from 206.168.112.31: icmp_seq=0 ttl=255 time=3.541 msec (DUP!)

64 bytes from 206.168.112.7: icmp_seq=0 ttl=255 time=3.636 msec (DUP!)

...

1.10. Стандарты Unix

Когда писалась эта книга, наибольший интерес в сфере стандартизации Unix вызывала деятельность группы Остина по пересмотру общих стандартов (The Austin Common Standards Revision Group, CSRG). Ими было написано в общей сложности около 4000 страниц спецификаций, описывающих более 1700 интерфейсов программирования. Эти спецификации являются одновременно стандартами IEEE POSIX и The Open Group. Поэтому один и тот же стандарт может встретиться вам под разными названиями, например ISO/IEC 9945:2002, IEEE Std 1003.1-2001 и Single Unix Specification Version 3. В нашей книге мы будем называть этот стандарт просто: спецификация POSIX, за исключением разделов, подобных этому, где обсуждаются особенности различных более старых стандартов.

Проще всего получить копию этого консолидированного стандарта, заказав ее на компакт-диске или скачав из Сети (бесплатно). В любом случае начинать следует с http://www.UNIX.org/version3.

История POSIX

Слово «POSIX» представляет собой сокращение от «Portable Operating System Interface» (интерфейс переносимой операционной системы). POSIX – целое семейство стандартов, разрабатываемых организацией IEEE (Institute of Electrical and Electronics Engineers – Институт инженеров по электротехнике и радиоэлектронике). Стандарты POSIX также приняты в качестве международных стандартов ISO (International Standards Organization – Международная организация по стандартизации) и IEC (International Electrotechnical Commission – Международная комиссия по электротехнике), называемых ISO/IEC. История стандартов POSIX достаточно интересна, но мы рассмотрим ее кратко.

■ Первым из стандартов POSIX был IEEE Std 1003.1-1988 (317 страниц), и он определял интерфейс между языком С и оболочкой ядра типа Unix в следующих областях: примитивы процесса ( fork, exec, сигналы, таймеры), среда процесса (идентификаторы пользователя, группы процессов), файлы и каталоги (все функции ввода-вывода), ввод-вывод на терминал, системные базы данных (файлы паролей и групп) и архивные форматы tarи cpio.

ПРИМЕЧАНИЕ

Первый стандарт POSIX был пробной версией, выпущенной в 1986 году и известной как IEEE-IX. Название «POSIX» было предложено Ричардом Столлмэном (Richard Stallman).

■ Следующим был IEEE Std 1003.2-1990 (356 страниц), который стал международным стандартом (ISO/IEC 9945-1:1990). По сравнению с версией 1988 году в версии 1990 года были внесены минимальные изменения. К названию было добавлено «Часть 1: Системный программный интерфейс приложений [язык С]», что указывало, что этот стандарт являлся интерфейсом API, написанным на языке С.

■ Затем был выпущен двухтомный стандарт IEEE Std 1003.2-1992 (около 1300 страниц). Второй том был озаглавлен «Часть 2: интерпретатор и утилиты» и описывал интерпретатор команд (Основанный на интерпретаторе System V Bourne Shell) и порядка сотни утилит (программ, запускаемых из интерпретатора, от awkи basenameдо viи yacc). В тексте мы будем называть этот стандарт POSIX.2.

■ IEEE Std 1003.1b-1993 (590 страниц) изначально именовался IEEE 1003.4. Он стал дополнением стандарта 1003.1-1990 и включал расширения реального времени, разработанные группой P1003.4. Стандарт 1003.1b-1993 добавил к стандарту 1990 года следующие пункты: синхронизацию файлов, асинхронный ввод-вывод, семафоры, управление памятью (вызов mmapи разделяемая память), планирование выполнения, часы, таймеры и очереди сообщений.

■ Следующий стандарт POSIX – IEEE Std 1003.1, редакция 1996 года [50], включил в себя 1003.1-1990 (базовый API), 1003.1b-1993 (расширения реального времени), 1003.1с-1995 (функции управления потоками) и 1003.1i-1995 (технические исправления 1003.1b). Этот стандарт также называется ISO/IEC 9945-1:1996. Были добавлены три главы, посвященные программным потокам, и общий объем стандарта составил 743 страницы. В тексте мы будем называть его POSIX.1. В стандарт включено предисловие, где говорится, что стандарт ISO/IEC 9945 состоит из следующих частей:

 □ Часть 1. Системный API [язык С].

 □ Часть 2. Оболочка и утилиты.

 □ Часть 3. Системное администрирование (в стадии разработки).

Части 1 и 2 – это именно то, что мы называем POSIX.1 и POSIX.2.

ПРИМЕЧАНИЕ

Более четверти из 743 страниц отводится приложению, названному «Обоснование и замечания» («Rationale and Notes»). Это обоснование содержит историческую информацию и причины, по которым те или иные функции были включены или опущены. Часто обоснование бывает столь же информативным, как и официальный стандарт.

■ Стандарт IEEE Std 1003.1g: Protocol Independent Interfaces (PII) (интерфейсы, не зависящие от протокола) был принят в 2000 году. До появления единой спецификации Unix версии 3 этот стандарт имел наибольшее отношение к тематике данной книги, потому что он определяет сетевые API (называя их DNI – Detailed Network Interfaces, подробные сетевые интерфейсы):

 1) DNI/Socket, основанный на API сокетов 4.4BSD;

 2) DNI/XTI, основанный на спецификации X/Open XPG4.

Работа над этим стандартом началась в 80-х (рабочая группа P1003.12, позже переименованная в P1003.1g). В тексте мы будем называть его POSIX.1g.

Текущее состояние различных стандартов POSIX можно получить в Интернете по адресу http://www.pasc.org/standing/sd11.html.

История Open Group

The Open Group (Открытая группа) была сформирована в 1996 году объединением организаций X/Open Company (основана в 1984 году) и Open Software Foundation (OSF, основан в 1988 году). Эта группа представляет собой международный консорциум производителей и потребителей из промышленности, правительства и образовательных учреждений. Их стандарты тоже выходили в нескольких версиях.

■ В 1989 году X/Open опубликовала третий выпуск X/Open Portability Guide (Руководство по разработке переносимых программ) – XPG3.

■ В 1992 году был опубликован четвертый выпуск (Issue 4), а в 1994 – вторая его версия (Issue 4, Version 2). Последняя известна также под названием Spec 1170, где магическое число 1170 представляет собой сумму количества интерфейсов системы (926), заголовков (70) и команд (174). Есть и еще два названия: X/Open Single Unix Specification (Единая спецификация Unix) и Unix 95.

■ В марте 1997 года было объявлено о выходе второй версии Единой спецификации Unix. Этот стандарт программного обеспечения называется также Unix 98, и именно так мы называем эту спецификацию далее в тексте книги. Количество интерфейсов в Unix 98 возросло с 1170 до 1434, хотя для рабочей станции это количество достигает 3030, поскольку сюда входит CDE (Common Desktop Environment – общее окружение рабочего стола), которое, в свою очередь, требует системы X Window System и пользовательского интерфейса Motif. Подробно об этом написано в книге [55]. Полезную информацию можно также найти по адресу http://www.UNIX.org/version2. Сетевые службы, входящие в Unix 98, определяются как для API сокетов, так и для XTI. Эта спецификация практически идентична POSIX.1g.

ПРИМЕЧАНИЕ

К сожалению, X/Open обозначает свои сетевые стандарты с помощью аббревиатуры «XNS» – X/Open Networking Services. Например, версия этого документа, в которой определяются сокеты и технологии XTI для Unix 98 [86], называется «XNS Issue 5*. Дело в том, что в мире сетевых технологий аббревиатура «XNS» всегда служила акронимом для «Xerox Network Systems» (сетевые системы Xerox). Поэтому мы избегаем использования акронима «XNS» и называем соответствующий документ X/Open просто стандартом сетевого API Unix 98.