Помоги проекту - поделись книгой:
Таблица 1.3. Различные версии эхо-клиента, рассматриваемые в данной книге
| Листинг | Описание |
|---|---|
| 5.3 | TCP/IPv4, зависимый от протокола |
| 6.1 | TCP, использует функцию select |
| 6.2 | TCP, использует функцию select и работает в пакетном режиме |
| 8.3 | UDP/IPv4, зависимый от протокола |
| 8.5 | UDP, проверяет адрес сервера |
| 8.7 | UDP, вызывает функцию connect для получения асинхронных ошибок |
| 14.2 | UDP, тайм-аут при чтении ответа сервера с использованием сигнала SIGALRM |
| 14.4 | UDP, тайм-аут при чтении ответа сервера с использованием функции select |
| 14.5 | UDP, тайм-аут при чтении ответа сервера с использованием опции сокета SO_RCVTIMEO |
| 14.7 | TCP, использует интерфейс /dev/poll |
| 14.8 | TCP, использует интерфейс kqueue |
| 15.4 | Поток домена Unix, зависит от протокола |
| 15.6 | Дейтаграмма домена Unix, зависит от протокола |
| 16.1 | TCP, использует неблокируемый ввод-вывод |
| 16.6 | TCP, использует два процесса (функцию fork) |
| 16.14 | TCP, устанавливает соединение, затем посылает пакет RST |
| 20.1 | UDP, широковещательный, ситуация гонок |
| 20.2 | UDP, широковещательный, ситуация гонок |
| 20.3 | UDP, широковещательный, для устранения ситуации гонок используется функция pselect |
| 20.5 | UDP, широковещательный, для устранения ситуации гонок используются функции sigsetjmp и siglongmp |
| 20.6 | UDP, широковещательный, для устранения ситуации гонок в обработчике сигнала используется IPC |
| 22.4 | UDP, увеличение надежности протокола за счет применения повторной передачи, тайм-аутов и порядковых номеров |
| 26.1 | TCP, использование двух потоков |
| 27.4 | TCP/IPv4, задание маршрута от отправителя |
| 27.5 | UDP/IPv6, задание маршрута от отправителя |
Таблица 1.4. Различные версии эхо-сервера, рассматриваемые в данной книге
| Листинг | Описание |
|---|---|
| 5.1 | TCP/IPv4, зависимый от протокола |
| 5.9 | TCP/IPv4, зависимый от протокола, корректно обрабатывает завершение всех дочерних процессов |
| 6.3 | TCP/IPv4, зависимый от протокола, использует функцию select, один процесс обрабатывает всех клиентов |
| 6.5 | TCP/IPv4, зависимый от протокола, использует функцию poll, один процесс обрабатывает всех клиентов |
| 8.1 | UDP/IPv4, зависимый от протокола |
| 8.14 | TCP и UDP/IPv4, зависимый от протокола, использует функцию select |
| 14.6 | TCP, использует стандартный ввод-вывод |
| 15.3 | Доменный сокет Unix, зависимый от протокола |
| 15.5 | Дейтаграмма домена Unix, зависит от протокола |
| 15.13 | Доменный сокет Unix, с передачей данных, идентифицирующих клиента |
| 22.3 | UDP, печатает полученный IP-адрес назначения и имя полученного интерфейса, обрезает дейтаграммы |
| 22.13 | UDP, связывает все адреса интерфейсов |
| 25.2 | UDP, использование модели ввода-вывода, управляемого сигналом |
| 26.2 | TCP, один поток на каждого клиента |
| 26.3 | TCP, один поток на каждого клиента, машинонезависимая (переносимая) передача аргумента |
| 27.4 | TCP/IPv4, печатает полученный маршрут от отправителя |
| 27.6 | UDP/IPv4, печатает полученный маршрут от отправителя и обращает его |
| 28.21 | UDP, использует функцию icmpd для получения асинхронных ошибок |
| Д.9 | UDP, связывает все адреса интерфейсов |
1.7. Модель OSI
Распространенным способом описания уровней сети является предложенная Международной организацией по стандартизации (International Standards Organization, ISO)
Рис. 1.5. Уровни модели OSI и набор протоколов Интернета
Мы считаем, что два нижних уровня модели OSI соответствуют драйверу устройства и сетевому оборудованию, которые имеются в системе. Обычно нам не приходится беспокоиться об этих уровнях, за исключением того, что мы должны знать некоторые свойства канального уровня — например, что MTU (максимальная единица передачи) Ethernet, которая описывается в разделе 2.11, имеет размер 1500 байт.
Сетевой уровень управляется протоколами IPv4 и IPv6, оба они описываются в приложении А. Из протоколов транспортного уровня мы можем выбирать TCP, UDP и SCRIPT, они описываются в главе 2. На рис. 1.5 изображен разрыв между TCP и UDP; это означает, что приложение может обойти транспортный уровень и использовать IPv4 или IPv6 непосредственно. В таких случаях речь идет о
Три верхних уровня модели OSI соответствуют уровню приложений. Приложением может быть веб-клиент (браузер), клиент Telnet, веб-сервер, сервер FTP или любое другое используемое нами приложение. В случае протоколов Интернета три верхние уровня модели OSI разделяются очень редко.
Описанный в этой книге API сокетов является интерфейсом между верхними тремя уровнями («приложением») и транспортным уровнем. Это один из важнейших вопросов книги: как создавать приложения, используя сокеты TCP и UDP. Мы уже упоминали о символьных сокетах, и в главе 29 мы увидим, что можем даже полностью обойти уровень IP, чтобы читать и записывать свои собственные кадры канального уровня.
Почему сокеты предоставляют интерфейс между верхними тремя уровнями модели OSI и транспортным уровнем? Для подобной организации модели OSI имеются две причины, которые мы отобразили на правой стороне рис. 1.5. Прежде всего, три верхних уровня отвечают за все детали, имеющие отношение к приложению (например, FTP, Telnet, HTTP), но знают мало об особенностях взаимодействия по сети. Четыре же нижних уровня знают мало о приложении, но отвечают за все, что связано с коммуникацией: отправку данных, ожидание подтверждения, упорядочивание данных, приходящих не в должном порядке, расчет и проверку контрольных сумм и т.д. Второй же причиной является то, что верхние три уровня часто формируют так называемый
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 сокетов, и мы называем их
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 <Link#1> 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 <Link#2> 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 <Link#6> 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 <Link#8> 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
Поделиться книгой: