TCP/IP

ющая IP-адресу места назначения, то из нее просто берется Ethernet-адрес,

и кадр, содержащий IP-пакет, отправляется. Если такой записи нет, то

посылается широковещательный ARP-запрос. Узел с искомым IP-адресом наз-

начения принимает его и в ARP-ответе сообщает свой Ethernet-адрес. Эти

действия соответствуют обычному протоколу ARP, описанному выше.

Протокол ARP с представителем основан на том, что шлюзы работают как

представители удаленных узлов. Предположим, в подсети 128.6.5 имеется

узел 128.6.5.2 (узел A на рис.12). Он желает послать IP-пакет узлу

128.6.4.194, который подключен к другой сети Ethernet (узел B в подсети

128.6.4). Существует шлюз с IP-адресом 128.6.5.1, соединяющий две под-

сети (шлюз R).

сеть 1 сеть 2

128.6.5 128.6.4

----o----------------o--- --o---------------o--------

| | | |

------------- ------------- ---------------

| 128.6.5.2 | | 128.6.5.1 | | 128.6.4.194 |

| A | | 128.6.4.1 | | B |

------------- | R | ---------------

-------------

Рис.12. Сеть, использующая протокол ARP с представителем

Если в ARP-таблице узла A нет маршрута доступа к узлу B, то узел A посы-

лает ARP-запрос узлу B. Фактически машина A спрашивает: "Если кто-нибудь

знает Ethernet-адрес узла 128.6.4.194, сообщите мне его". Узел B не

может ответить на запрос самостоятельно. Он подключен к другой сети Eth-

ernet и никогда даже не увидит этот ARP-запрос. Однако шлюз R может

работать от его имени. Шлюз R отвечает: "Я здесь, IP-адресу 128.6.4.194

соответствует Ethernet-адрес 2:7:1:0:EB:CD", где 2:7:1:0:EB:CD в действи-

тельности является Ethernet-адресом шлюза. Это создает иллюзию, что узел

128.6.4.194 подключен непосредственно к той же локальной сети Ethernet,

что и узел A, и имеет Ethernet-адрес 2:7:1:0:EB:CD. Когда узел A захочет

послать новый IP-пакет узлу B, он использует указанный Ethernet-адрес.

Кадр, содержащий IP-пакет, попадет к шлюзу R, а он переправит его по наз-

начению.

Заметим, что полученный эффект такой же, как если бы в таблице марш-

рутов была запись

--------------------------------------------------------

| адрес флаг вида шлюз интерфейс |

| назначения маршрутизации |

--------------------------------------------------------

| 128.6.4.194 косвенная 128.6.5.1 pe0 |

--------------------------------------------------------

за исключением того, что маршрутизация выполняется на уровне модуля ARP,

а не модуля IP.

Обычно рекомендуется использовать таблицу маршрутов, так как архи-

тектура протоколов TCP/IP предусматривает выполнение маршрутизации на

межсетевом уровне. Однако иногда протокол ARP с представителем очень

полезен. Он может помочь в следующих случаях:

1) в IP-сети есть узел, который не умеет работать с подсетями;

2) в IP-сети есть узел, который не может соответствующим образом реаги-

ровать на сообщения перенаправления;

3) нежелательно выбирать какой-либо шлюз как маршрут по умолчанию;

4) программное обеспечение не способно восстанавливаться при сбоях на

маршрутах.

Иногда протокол ARP с представителем выбирают из-за удобства. Дело

в том, что он упрощает работу по начальной установке таблицы маршрутов.

Даже в простейших IP-сетях требуется устанавливать маршрут по умолчанию,

то есть использовать команду типа "route add defailt ...", как в ОС UNIX.

При изменении IP-адреса шлюза эту команду приходится менять во всех

узлах. Если же использовать протокол ARP с представителем, т.е. в

команде установки маршрута по умолчанию указать метрику 0, то при замене

IP-адреса шлюза команду начальной установки менять не придется, так как

протокол ARP с представителем не требует явного задания IP-адресов шлю-

зов. Любой шлюз может ответить на ARP-запрос.

Для того, чтобы избавить пользователей от обязательной начальной

установки маршрутов, некоторые реализации TCP/IP используют протокол ARP

с представителем по умолчанию в тех случаях, когда не находят подходящих

записей в таблице маршрутов.

* 7. Протокол UDP *

Протокол UDP (User Datagram Protocol - протокол пользовательских

датаграмм) является одним из двух основных протоколов, расположенных

непосредственно над IP. Он предоставляет прикладным процессам транспорт-

ные услуги, которые не многим отличаются от услуг, предоставляемых прото-

колом IP. Протокол UDP обеспечивает ненадежную доставку датаграмм и не

поддерживает соединений из конца в конец. К заголовку IP-пакета он

добавляет два поля, одно из которых, поле "порт", обеспечивает мультип-

лексирование информации между разными прикладными процессами, а другое

поле - "контрольная сумма" - позволяет поддерживать целостность данных.

Примерами сетевых приложений, использующих UDP, являются NFS (Net-

work File System - сетевая файловая система) и SNMP (Simple Network

Management Protocol - простой протокол управления сетью).

7.1. Порты

Взаимодействие между прикладными процессами и модулем UDP осуществ-

ляется через UDP-порты. Порты нумеруются начиная с нуля. Прикладной

процесс, предоставляющий некоторые услуги другим прикладным процессам

(сервер), ожидает поступления сообщений в порт, специально выделенный для

этих услуг. Сообщения должны содержать запросы на предоставление услуг.

Они отправляются процессами-клиентами.

Например, сервер SNMP всегда ожидает поступлений сообщений в порт

161. Если клиент SNMP желает получить услугу, он посылает запрос в UDP-

порт 161 на машину, где работает сервер. В каждом узле может быть только

один сервер SNMP, так как существует только один UDP-порт 161. Данный

номер порта является общеизвестным, то есть фиксированным номером, офици-

ально выделенным для услуг SNMP. Общеизвестные номера определяются стан-

дартами Internet.

Данные, отправляемые прикладным процессом через модуль UDP, дости-

гают места назначения как единое целое. Например, если процесс-

отправитель производит 5 записей в UDP-порт, то процесс-получатель должен

будет сделать 5 чтений. Размер каждого записанного сообщения будет сов-

падать с размером каждого прочитанного. Протокол UDP сохраняет границы

сообщений, определяемые прикладным процессом. Он никогда не объединяет

несколько сообщений в одно и не делит одно сообщение на части.

7.2. Контрольное суммирование

Когда модуль UDP получает датаграмму от модуля IP, он проверяет

контрольную сумму, содержащуюся в ее заголовке. Если контрольная сумма

равна нулю, то это означает, что отправитель датаграммы ее не подсчиты-

вал, и, следовательно, ее нужно игнорировать. Если два модуля UDP взаи-

модействуют только через одну сеть Ethernet, то от контрольного суммиро-

вания можно отказаться, так как средства Ethernet обеспечивают достаточ-

ную степень надежности обнаружения ошибок передачи. Это снижает наклад-

ные расходы, связанные с работой UDP. Однако рекомендуется всегда выпол-

нять контрольное суммирование, так как возможно в какой-то момент измене-

ния в таблице маршрутов приведут к тому, что датаграммы будут посылаться

через менее надежную среду.

Если контрольная сумма правильная (или равна нулю), то проверяется

порт назначения, указанный в заголовке датаграммы. Если к этому порту

подключен прикладной процесс, то прикладное сообщение, содержащееся в

датаграмме, становится в очередь для прочтения. В остальных случаях

датаграмма отбрасывается. Если датаграммы поступают быстрее, чем их

успевает обрабатывать прикладной процесс, то при переполнении очереди

сообщений поступающие датаграммы отбрасываются модулем UDP.

* 8. Протокол TCP *

Протокол TCP предоставляет транспортные услуги, отличающиеся от

услуг UDP. Вместо ненадежной доставки датаграмм без установления соеди-

нений, он обеспечивает гарантированную доставку с установлением соедине-

ний в виде байтовых потоков.

Протокол TCP используется в тех случаях, когда требуется надежная

доставка сообщений. Он освобождает прикладные процессы от необходимости

использовать таймауты и повторные передачи для обеспечения надежности.

Наиболее типичными прикладными процессами, использующими TCP, являются

FTP (File Transfer Protocol - протокол передачи файлов) и TELNET. Кроме

того, TCP используют система X-Window, rcp (remote copy - удаленное копи-

рование) и другие "r-команды". Большие возможности TCP даются не бесп-

латно. Реализация TCP требует большой производительности процессора и

большой пропускной способности сети. Внутренняя структура модуля TCP

гораздо сложнее структуры модуля UDP.

Прикладные процессы взаимодействуют с модулем TCP через порты. Для

отдельных приложений выделяются общеизвестные номера портов. Например,

сервер TELNET использует порт номер 23. Клиент TELNET может получать

услуги от сервера, если установит соединение с TCP-портом 23 на его

машине.

Когда прикладной процесс начинает использовать TCP, то модуль TCP на

машине клиента и модуль TCP на машине сервера начинают общаться. Эти два

оконечных модуля TCP поддерживают информацию о состоянии соединения,

называемого виртуальным каналом. Этот виртуальный канал потребляет

ресурсы обоих оконечных модулей TCP. Канал является дуплексным; данные

могут одновременно передаваться в обоих направлениях. Один прикладной

процесс пишет данные в TCP-порт, они проходят по сети, и другой приклад-

ной процесс читает их из своего TCP-порта.

Протокол TCP разбивает поток байт на пакеты; он не сохраняет границ

между записями. Например, если один прикладной процесс делает 5 записей

в TCP-порт, то прикладной процесс на другом конце виртуального канала

может выполнить 10 чтений для того, чтобы получить все данные. Но этот

же процесс может получить все данные сразу, сделав только одну операцию

чтения. Не существует зависимости между числом и размером записываемых

сообщений с одной стороны и числом и размером считываемых сообщений с

другой стороны.

Протокол TCP требует, чтобы все отправленные данные были подтверж-

дены принявшей их стороной. Он использует таймауты и повторные передачи

для обеспечения надежной доставки. Отправителю разрешается передавать

некоторое количество данных, недожидаясь подтверждения приема ранее отп-

равленных данных. Таким образом, между отправленными и подтвержденными

данными существует окно уже отправленных, но еще неподтвержденных данных.

Количество байт, которые можно передавать без подтверждения, называется

размером окна. Как правило, размер окна устанавливается в стартовых фай-

лах сетевого программного обеспечения. Так как TCP-канал является дуп-

лексным, то подтверждения для данных, идущих в одном направлении, могут

передаваться вместе с данными, идущими в противоположном направлении.

Приемники на обеих сторонах виртуального канала выполняют управление

потоком передаваемых данных для того, чтобы не допускать переполнения

буферов.

* 9. Протоколы прикладного уровня *

Почему существуют два транспортных протокола TCP и UDP, а не один из

них? Дело в том, что они предоставляют разные услуги прикладным процес-

сам. Большинство прикладных программ пользуются только одним из них.

Вы, как программист, выбираете тот протокол, который наилучшим образом

соответствует вашим потребностям. Если вам нужна надежная доставка, то

лучшим может быть TCP. Если вам нужна доставка датаграмм, то лучше может

быть UDP. Если вам нужна эффективная доставка по длинному и ненадежному

каналу передачи данных, то лучше может подойти протокол TCP. Если нужна

эффективность на быстрых сетях с короткими соединениями, то лучшим может

быть протокол UDP. Если ваши потребности не попадают ни в одну из этих

категорий, то выбор транспортного протокола не ясен. Однако прикладные

программы могут устранять недостатки выбранного протокола. Например,

если вы выбрали UDP, а вам необходима надежность, то прикладная программа

должна обеспечить надежность. Если вы выбрали TCP, а вам нужно переда-

вать записи, то прикладная программа должна вставлять маркеры в поток

байтов так, чтобы можно было различить записи.

Какие же прикладные программы доступны в сетях с TCP/IP?

Общее их количество велико и продолжает постоянно увеличиваться.

Некоторые приложения существуют с самого начала развития internet. Нап-

ример, TELNET и FTP. Другие появились недавно: X-Window, SNMP.

Протоколы прикладного уровня ориентированы на конкретные прикладные

задачи. Они определяют как процедуры по организации взаимодействия опре-

деленного типа между прикладными процессами, так и форму представления

информации при таком взаимодействии. В этом разделе мы коротко опишем

некоторые из прикладных протоколов.

9.1. Протокол TELNET

Протокол TELNET позволяет обслуживающей машине рассматривать все

удаленные терминалы как стандартные "сетевые виртуальные терминалы"

строчного типа, работающие в коде ASCII, а также обеспечивает возможность

согласования более сложных функций (например, локальный или удаленный

эхо-контроль, страничный режим, высота и ширина экрана и т.д.) TELNET

работает на базе протокола TCP. На прикладном уровне над TELNET нахо-

дится либо программа поддержки реального терминала (на стороне пользова-

теля), либо прикладной процесс в обсуживающей машине, к которому осу-

ществляется доступ с терминала.

Работа с TELNET походит на набор телефонного номера. Пользователь

набирает на клавиатуре что-то вроде

telnet delta

и получает на экране приглашение на вход в машину delta.

Протокол TELNET существует уже давно. Он хорошо опробован и широко

распространен. Создано множество реализаций для самых разных операцион-

ных систем. Вполне допустимо, чтобы процесс-клиент работал, скажем, под

управлением ОС VAX/VMS, а процесс-сервер под ОС UNIX System V.

9.2. Протокол FTP

Протокол FTP (File Transfer Protocol - протокол передачи файлов)

распространен также широко как TELNET. Он является одним из старейших

протоколов семейства TCP/IP. Также как TELNET он пользуется транспорт-

ными услугами TCP. Существует множество реализаций для различных опера-

ционных систем, которые хорошо взаимодействуют между собой. Пользователь

FTP может вызывать несколько команд, которые позволяют ему посмотреть

каталог удаленной машины, перейти из одного каталога в другой, а также

скопировать один или несколько файлов.

9.3. Протокол SMTP

Протокол SMTP (Simple Mail Transfer Protocol - простой протокол

передачи почты) поддерживает передачу сообщений (электронной почты) между

произвольными узлами сети internet. Имея механизмы промежуточного хране-

ния почты и механизмы повышения надежности доставки, протокол SMTP допус-

кает использование различных транспотных служб. Он может работать даже в

сетях, не использующих протоколы семейства TCP/IP. Протокол SMTP обеспе-

чивает как группирование сообщений в адрес одного получателя, так и разм-

ножение нескольких копий сообщения для передачи в разные адреса. Над

модулем SMTP располагается почтовая служба конкретных вычислительных сис-

тем.

9.4. r-команды

Существует целая серия "r-команд" (от remote - удаленный), которые

впервые появились в ОС UNIX. Они являются аналогами обычных команд UNIX,

но предназначены для работы с удаленными машинами. Например, команда rcp

является аналогом команды cp и предназначена для копирования файлов между

машинами. Для передачи файла на узел delta достаточно ввести

rcp file.c delta:

Для выполнения команды "cc file.c" на машине delta можно использовать

комаду rsh:

rsh delta cc file.c

Для организации входа в удаленную систему предназначена команда rlogin:

rlogin delta

Команды r-серии используются главным образом в системах, работающих

под управлением ОС UNIX. Существуют также реализации для MS-DOS.

Команды избавляют пользователя от необходимости набирать пароли при входе

в удаленную систему и существенно облегчают работу.

9.5. NFS

Сетевая файловая система NFS (Network File System) впервые была раз-

работана компанией Sun Microsystems Inc. NFS использует транспортные

услуги UDP и позволяет монтировать в единое целое файловые системы нес-

кольких машин с ОС UNIX. Бездисковые рабочие станции получают доступ к

дискам файл-сервера так, как-будто это их локальные диски.

NFS значительно увеличивает нагрузку на сеть. Если в сети использу-

ются медленные линии связи, то от NFS мало толку. Однако, если пропуск-

ная способность сети позволяет NFS нормально работать, то пользователи

получают большие преимущества. Поскольку сервер и клиент NFS реализуются

в ядре ОС, все обычные несетевые программы получают возможность работать

с удаленными файлами, расположенными на подмонтированных NFS-дисках,

точно также как с локальными файлами.

9.6. Протокол SNMP

Протокол SNMP (Simple Network Management Protocol - простой протокол

управления сетью) работает на базе UDP и предназначен для использования

сетевыми управляющими станциями. Он позволяет управляющим станциям соби-

рать информацию о положении дел в сети internet. Протокол определяет

формат данных, их обработка и интерпретация остаются на усмотрение управ-

ляющих станций или менеджера сети.

9.7. X-Window

Система X-Window использует протокол X-Window, который работает на

базе TCP, для многооконного отображения графики и текста на растровых

дисплеях рабочих станций. X-Window - это гораздо больше, чем просто ути-

лита для рисования окон; это целая философия человеко-машинного взаимо-

действия.

* 10. Взаимозависимость протоколов семейства TCP/IP *

Ниже на рисунке предсавлена схема взаимосвязей между протоколами

семейства TCP/IP.

Прикладной FTP TELNET SMTP TFTP DNS Сужба времени Эхо

уровень | | | | | | |

-------------- --------------------------

| |

Транспортный TCP GGP HMP EGP UDP

уровень | | | | |

-------------------------------

|

Межсетевой IP/ICMP

уровень |

--------------------------------------

| | | |

Сетевой Локальные ARPANET SATNET Пакетная

уровень сети радиосеть

Рис.13. Структура взаимосвязей протоколов семейства TCP/IP

Подробное описание протоколов можно найти в RFC, тематический ката-

лог которых приведен в Приложении 1, а состояние стандартов отражено в

Приложении 2.

[pic]

Last-modified: Wed, 17 Mar 1999 16:31:31 GMT

Начало формы

[pic][pic][pic][pic]

Страницы: 1, 2, 3, 4, 5