TCP/IP

Табл.15. Автоматически создаваемые записи

Эти записи определяют, что IP-пакеты для локальных подсетей 128.6.4 и

128.6.5 должны посылаться через указанные интерфейсы

В стартовом файле могут быть команды, определяющие маршруты доступа к

другим IP-сетям. Например,

route add 128.6.2.0 128.6.4.1 1

route add 128.6.6.0 128.6.5.35 0

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

записи. Первый адрес в командах является IP-адресом сети, второй адрес

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

а третий параметр является метрикой. Метрика показывает, на каком

“расстоянии” находится описываемая IP-сеть. В данном случае метрика - это

количество шлюзов на пути между двумя IP-сетями. Маршруты с метрикой 1 и

более определяют первый шлюз на пути к IP-сети. Маршруты с метрикой 0

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

дополнительный сетевой номер локальной IP-сети

Таким образом, команды, приведенные в примере, говорят о том, что для

доступа к IP-сети 128.6.2 должен использоваться шлюз 128.6.4.1, а IP-сеть

128.6.6 - это просто дополнительный номер для физической сети, подключенной

к интерфейсу 128.6.5.35

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

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

| маршрутизации |

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

| 128.6.2 косвенная 128.6.4.1 ie0 |

| 128.6.6 прямая ie1 |

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

Табл.16. Записи, добавляемые в таблицу маршрутов

Можно определить маршрут по умолчанию, который используется в тех случаях,

когда IP-адрес места назначения не встречается в таблице маршрутов явно.

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

достаточно информации для маршрутизации IP-пакетов со всеми возможными

адресами назначения

Если ваша IP-сеть имеет всего один шлюз, тогда все, что нужно сделать, -

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

как маршрут по умолчанию. После этого можно не заботиться о формировании

маршрутов в других узлах. (Конечно, сам шлюз требует больше внимания )

Следующие разделы посвящены IP-сетям, где есть несколько шлюзов

6.2. Перенаправление маршрутов

Большинство экспертов по межсетевому взаимодействию рекомендуют оставлять

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

таблицу маршрутов. Дело в том, что при каких-либо изменениях в IP-сети

приходится менять информацию во всех машинах. Например, при отключении

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

ждать, пока кто-то заметит это изменение в конфигурации IP-сети и внесет

исправления во все таблицы маршрутов

Простейший способ поддержания адекватности маршрутов заключается в том, что

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

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

ОС UNIX это делается командой “route add default 128.6.4.27.1”, где

128.6.4.27 является IP-адресом шлюза ) Как было описано выше, каждая машина

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

маршрута. Однако, когда в IP-сети есть несколько шлюзов, этот метод

работает не так хорошо. Кроме того, если таблица маршрутов имеет только

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

это более выгодно? Ответ состоит в том, что большинство шлюзов способны

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

для которых существуют более выгодные маршруты. “Перенаправление” является

специальным типом сообщения протокола ICMP (Internet Control Message

Protocol - протокол межсетевых управляющих сообщений). Сообщение о

перенаправлении содержит информацию, которую можно интерпретировать так: “В

будущем для IP-адреса XXXX используйте шлюз YYYY, а не меня”. Корректные

реализации TCP/IP должны использовать сообщения о перенаправлении для

добавления записей в таблицу маршрутов. Предположим, таблица маршрутов в

начале выглядит следующим образом:

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

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

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

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

| 127.0.0 прямая lo0 |

| 128.6.4 прямая pe0 |

| default косвенная 128.6.4.27 pe0 |

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

Табл.17. Таблица маршрутов в начале работы

Эта таблица содержит запись о локальной IP-сети 128.6.4 и маршрут по

умолчанию, указывающий шлюз 128.6.4.27. Допустим, что существует шлюз

128.6.4.30, который является лучшим путем доступа к IP-сети 128.6.7. Как им

воспользоваться? Предположим, что нужно посылать IP-пакеты по IP-адресу

128.6.7.23. Первый IP-пакет пойдет на шлюз по умолчанию, так как это

единственный подходящий маршрут, описанный в таблице. Однако шлюз

128.6.4.27 знает, что существует лучший маршрут, проходящий через шлюз

128.6.4.30. (Как он узнает об этом, мы сейчас не рассматриваем. Существует

довольно простой метод определения лучшего маршрута ) В этом случае шлюз

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

пакеты для узла 128.6.7.23 должны посылаться через шлюз 128.6.4.30. Модуль

IP на машине-отправителе должен добавить запись в таблицу маршрутов:

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

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

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

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

| 128.6.7.23 косвенная 128.6.4.30 pe0 |

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

Табл.18. Новая запись в таблице маршрутов

Все последующие IP-пакеты для узла 128.6.7.23 будут посланы прямо через

указанный шлюз

До сих пор мы рассматривали способы добавления маршрутов в IP-таблицу, но

не способы их исключения. Что случится, если шлюз будет выключен? Хотелось

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

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

уже не может послать сообщение перенаправления. Поэтому должен существовать

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

непосредственно. Лучший способ обнаружения неработающих шлюзов основан на

выявлении “плохих” маршрутов. Модуль TCP поддерживает различные таймеры,

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

можно пометить маршрут как “плохой” и вернуться к маршруту по умолчанию.

Аналогичный метод может использоваться при обработке ошибок шлюза по

умолчанию. Если два шлюза отмечены как шлюзы по умолчанию, то машина может

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

6.3. Слежение за маршрутизацией

Заметим, что сообщения перенаправления не могут использоваться самими

шлюзами. Перенаправление - это просто способ оповещения обычного узла о

том, что нужно использовать другой шлюз. Сами шлюзы должны иметь полную

картину о положении дел в сети internet и уметь вычислять оптимальные

маршруты доступа к каждой подсети. Обычно они поддерживают эту картину,

обмениваясь информацией между собой. Для этой цели существуют несколько

специальных протоколов маршрутизации. Один из способов, с помощью которого

узлы могут определять действующие шлюзы, состоит в слежении за обменом

сообщениями между ними. Для большинства протоколов маршрутизации существует

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

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

сети internet точно также, как это делается в шлюзах. Динамическая

корректировка таблицы маршрутов позволяет посылать IP-пакеты по оптимальным

маршрутам

Таким образом, слежение за маршрутизацией в некотором смысле “решает”

проблему поддержания корректности таблиц маршрутов. Однако существуют

несколько причин, по которым этот метод применять не рекомендуется.

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

еще подвергаются частым пересмотрам и изменениям. Появляются новые

протоколы маршрутизации. Эти изменения должны учитываться в программном

обеспечении всех машин

Несколько более специальная проблема связана с бездисковыми рабочими

станциями. По своей природе бездисковые машины сильно зависят от сети и от

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

располагается их область свопинга. Исполнение программ, следящих за

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

большими трудностями. Протоколы маршрутизации построены в основном на

широковещательных передачах. Например, все сетевые шлюзы могут

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

30 секунд. Программы, которые следят за такими передачами, должны быть

загружены на бездисковые станции через сеть. На достаточно занятой машине

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

отправляются в область свопинга. Поэтому программы, следящие за

маршрутизацией, большую часть времени находятся в свопинге. Когда они вновь

активизируются, должна производиться подкачка из свопинга. Как только

посылается широковещательное сообщение, все машины активизируют программы,

следящие за маршрутизацией. Это приводит к тому, что многие бездисковые

станции будут выполнять подкачку из свопинга в одно и тоже время. Поэтому в

сети возникнет временная перегрузка. Таким образом, исполнение программ,

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

очень нежелательно

6.4. Протокол ARP с представителем

Протокол ARP с представителем является альтернативным методом, позволяющим

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

сетях с широковещательной передачей, где для отображения IP-адресов в

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

будем предполагать, что имеем дело с сетью Ethernet

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

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

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

на уровне адресов Ethernet. Протокол ARP с представителем может

использоваться либо для маршрутизации IP-пакетов ко всем сетям, либо только

в локальной сети, либо в какой-то комбинации подсетей. Проще всего

продемонстрировать его использование при работе со всеми адресами

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

в мире подключены непосредственно к вашей локальной сети Ethernet. В ОС

UNIX это делается командой “route add default 128.6.4.2.0”, где 128.6.4.2 -

IP-адрес вашего узла. Как уже отмечалось, метрика 0 говорит о том, что все

IP-пакеты, которым подходит данный маршрут, должны посылаться напрямую по

локальной сети

Когда нужно послать IP-пакет узлу в локальной сети Ethernet, ваша машина

должна определить Ethernet-адрес этого узла. Для этого она использует ARP-

таблицу. Если в ARP-таблице уже есть запись, соответствующая 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

----о----------------о--- --о---------------о--------

| | | |

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

| 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 не может

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

никогда даже не увидит этот 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 (Network 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

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

[1] В документации по TCP/IP термины шлюз (gateway) и IP-маршрутизатор (IP-

router) часто используются как синонимы Мы сочли возможным использовать

более распространенный термин “шлюз”

[2]SRI International, Room EJ210, 333 Ravenswood Avenue, Menlo Park,

California 94025, USA. Тел. 1-800-235-3155. E-mail: NIC@NIC.DDN.MIL

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