Реферат: Протоколы TCP/IP - текст реферата. Скачать бесплатно.
Банк рефератов, курсовых и дипломных работ. Много и бесплатно. # | Правила оформления работ | Добавить в избранное
 
 
   
Меню Меню Меню Меню Меню
   
Napishem.com Napishem.com Napishem.com

Реферат

Протоколы TCP/IP

Банк рефератов / Программирование

Рубрики  Рубрики реферат банка

закрыть
Категория: Реферат
Язык реферата: Русский
Дата добавления:   
 
Скачать
Microsoft Word, 343 kb, скачать бесплатно
Заказать
Узнать стоимость написания уникального реферата

Узнайте стоимость написания уникальной работы

Семейство протоколов TCP/IP 1. Введение Семейство протоколов TCP/IP широко применяет ся во всем мире для объединения компьютер ов в сеть Internet. Единая сеть Internet состоит из множества сетей различной физической природы , от локальных сетей типа Ethernet и Token Ring, до глобал ьных сетей типа NSFNET. Основное вни м ан ие в книге уделяется принципам организации межсетевого взаимодействия . Многие технические детали , исторические вопросы опущены . Более по дробную информацию о протоколах TCP/IP можно найти в RFC (Requests For Comments) - специальных документах , выпускаемы х Сетевым Информационным Центром ( Network Information Center - NIC ). Приложение 1 содержит путеводитель по RFC, а приложение 2 отражает положение дел в области стандартизации проток олов семейства TCP/IP на начало 1991 года . В книге приводятся примеры , осно ва нные на реализации TCP/IP в ОС UNIX. Однако основны е положения применимы ко всем реализациям TCP/IP. Надеюсь , что эта книга будет полезна тем , кто профессионально работает или соб ирается начать работать в среде TCP/IP: системным администраторам , системн ым программистам и менеджерам сети. 2. Основы TCP/IP Термин "TCP/IP" обычно обозначает все , что с вязано с протоколами TCP и IP. Он охватывает це лое семейство протоколов , прикладные программы и даже саму сеть . В состав семейства входят протоколы UDP, ARP, ICMP, TELNET, FTP и многие другие . TCP/IP - это технология межсетевого взаимодействия , технология internet. Сеть , которая использует технолог ию internet , называется " internet ". Если речь идет о глобальной с ети , объединяющей множество сетей с тех нологией internet, то ее называют Internet. 2.1. Модуль IP создает единую логическую сеть Архитектура протоколов TCP/IP предназначена для объединенной сети , состоящей из соединенных друг с другом шлюзами отдельных разнородны х пакетных подсетей , к которым подключаю тся разнородные машины . Каждая из подсетей работает в соответствии со своими специфич ескими требованиями и имеет свою природу средств связи . Однако предполагается , что кажд ая подсеть может принять пакет информации (данные с соответствующим сетевы м заголовком ) и доставить его по указанному адресу в этой конкретной под сети . Не требуется , чтобы подсеть гарантировала обязательн ую доставку пакетов и имела надежный скво зной протокол . Таким образом , две машины , п одключенные к одной подсети могут обменив а ться пакетами . Когда необходимо передать пакет между машинами , подключенными к разным подсетям , т о машина-отправитель посылает пакет в соответ ствующий шлюз (шлюз подключен к подсети та кже как обычный узел ). Оттуда пакет направ ляется по определенному маршр уту через систему шлюзов и подсетей , пока не дост игнет шлюза , подключенного к той же подсет и , что и машина-получатель ; там пакет напра вляется к получателю . Объединенная сеть обесп ечивает датаграммный сервис . Проблема доставки пакетов в такой сис теме решае тся путем реализации во все х узлах и шлюзах межсетевого протокола IP. М ежсетевой уровень является по существу базовы м элементом во всей архитектуре протоколов , обеспечивая возможность стандартизации протоколов верхних уровней . 2.2. Структура связей проток о льных модулей Введем ряд базовых терминов , которые м ы будем использовать в дальнейшем . Драйвер - это программа , непосредственно вз аимодействующая с сетевым адаптером . Модуль - э то программа , взаимодействующая с драйвером , с етевыми прикладными программами или другими модулями . Драйвер сетевого адаптера и , во зможно , другие модули , специфичные для физичес кой сети передачи данных , предоставляют сетев ой интерфейс для протокольных модулей семейст ва TCP/IP. Название блока данных , передаваемого по сети , зависит от того , на каком ур овне стека протоколов он находится . Блок д анных , с которым имеет дело сетевой интерф ейс , называется кадром ; если блок данных н аходится между сетевым интерфейсом и модулем IP, то он называется IP-пакетом ; если он - м ежду модулем IP и мо д улем UDP, то - UDP- датаграммой ; если между модулем IP и модулем TCP, то - TCP-сегментом (или транспортным сообщением ); наконец , если блок данных находится на уровне сетевых прикладных процессов , то он называется прикладным сообщением . Эти определения , кон ечно , несовершенны и неполны . К тому же они меняются от публикации к публикации . Более подробные определения можно найти в RFC-1122, раздел 1.3.3. 2.4. П отоки данных Рассмотрим потоки данных , проходящие чере з стек протоколов , изображенный на рис .1. В случа е использования протокола TCP (Transmission Control Protocol - протокол управления передачей ), данные п ередаются между прикладным процессом и модуле м TCP. Типичным прикладным процессом , использующим протокол TCP, является модуль FTP (File Transfer Protoco l п ротокол передачи файлов ). Стек протоколов в этом случае будет FTP / TCP / IP / ENET . При использовании протокола UDP (User Datagram Protocol - протокол пользовательских датагр амм ), данные передаются между прикладным проце ссом и модулем UDP. Например , SNMP ( Sim ple Network Management Protocol - простой протокол управления сетью ) пользуется транспортными услугами UDP. Его стек протоколов выглядит так : SNMP/UDP/IP/ENET. Модули TCP, UDP и драйвер Ethernet являются мультиплек сорами n x 1. Действуя как мультиплексоры , они переключают несколько входов на один выход . Они также являются демультиплексорами 1 x n. Как демультиплексоры , они переключают один вход на один из многих выходов в соответс твии с полем типа в заголовке протокольно го блока данных (рис .2). Когда Ethe rnet-кадр попадает в драйвер сетевого интерфейса Ethernet, он может быть нап равлен либо в модуль ARP (Address Resolution Protocol адресный проток ол ), либо в модуль IP (Internet Protocol - межсетевой протокол ). На то , куда должен быть направлен Ethernet-ка д р , указывает значение поля типа в заголовке кадра . Если IP-пакет попадает в модуль IP, то содержащиеся в нем данные могут быть пере даны либо модулю TCP, либо UDP, что определяется полем "протокол " в заголовке IP-пакета . Если UDP-датаграмма попадает в мод ул ь UDP, то на основании значения поля "порт " в заголовке датаграммы определяется прикладная программа , которой должно быть передано п рикладное сообщение . Если TCP-сообщение попадает в модуль TCP, то выбор прикладной программы , которой должно быть передан о сообще ние , осуществляется на основе значения поля "порт " в заголовке TCP-сообщения . Мультиплексирование данных в обратную сто рону осуществляется довольно просто , так как из каждого модуля существует только один путь вниз . Каждый протокольный модуль доб ав ляет к пакету свой заголовок , на основании которого машина , принявшая пакет , выполняет демультиплексирование. Данные от прикладного процесса проходят через модули TCP или UDP, после чего попадают в модуль IP и оттуда - на уровень сетево го интерфейса . Хотя технология internet поддерживает много различных сред передачи данных , здесь мы будем предполагать использование Ethernet, так как именно эта среда чаще всего служит физ ической основой для IP-сети . Машина на рис .1 имеет одну точку соединения с Ethernet. Ш естибайтный Ethernet-адрес является уникальным для каждого сетевого адаптера и распознается драйвером . Машина имеет также четырехбайтный IP-адрес . Этот адрес обозначает точку доступа к сети на интерфейсе модуля IP с драйвером . IP-адрес должен быть уникаль ным в преде лах всей сети Internet. Работающая машина всегда знает свой IP- адрес и Ethernet-адрес . 2.5. Работа с несколькими се тевыми интерфейсами [1] В документации по TCP/IP термины шлюз (gateway) и IPмаршрутизатор (IP-router) часто используются как син онимы . Мы сочли возможным использовать более распространенный термин "шлюз ". исходящи й в сети , и принимает адресованные ему Ethernet-кадры , а также Ethernet-кадры с адресом "FF:FF:FF:FF:FF:FF" (в 16-ричной системе ), который обозначает "вс ем ", и использует с я при широковеща тельной передаче . Ethernet реализует метод МДКН /ОС (множественны й доступ с контролем несущей и обнаружени ем столкновений ). Метод МДКН /ОС предполагает , что все устройства взаимодействуют в одной среде , в каждый момент времени может передава ть только одно устройство , а п ринимать могут все одновременно . Если два устройства пытаются передавать одновременно , то происходит столкновение передач , и оба устр ойства после случайного (краткого ) периода ожи дания пытаются вновь выполнить передачу . 3.1. А налогия с разговором Хорошей аналогией взаимодействиям в среде Ethernet может служить разговор группы вежливых людей в небольшой темной комнате . При э том аналогией электрическим сигналам в коакси альном кабеле служат звуковые волны в ком нате . Каждый челов ек слышит речь других людей (контроль несущей ). Все люди в к омнате имеют одинаковые возможности вести раз говор (множественный доступ ), но никто не г оворит слишком долго , так как все вежливы . Если человек будет невежлив , то его п опросят выйти (т.е . удалят и з сети ). Все молчат , пока кто-то говорит . Если два человека начинают говорить одновременно , то они сразу обнаруживают это , поскольку с лышат друг друга (обнаружение столкновений ). В этом случае они замолкают и ждут нек оторое время , после чего один из них в н овь начинает разговор . Другие люд и слышат , что ведется разговор , и ждут , пока он кончится , а затем могут начать говорить сами . Каждый человек имеет собстве нное имя (аналог уникального Ethernet-адреса ). Каждый раз , когда кто-нибудь начинает говорить , о н на з ывает по имени того , к кому обращается , и свое имя , например , "С лушай Петя , это Андрей , ... ля-ля-ля ..." Если кто- то хочет обратиться ко всем , то он гов орит : "Слушайте все , это Андрей , ... ля-ля-ля ..." (ш ироковещательная передача ). 4. Протокол ARP В этом разделе мы рассмотрим то , как при посылке IP-пакета определяется Ethernet-а дрес назначения . Для отображения IP-адресов в Ethernetадреса используется протокол ARP (Address Resolution Protocol - адресный протокол ). Отображение выполняется только для от п равляемых IP-пакетов , так как только в момент отправки создаются заголовки IP и Ethernet. 4.1. ARP-таблица для преобразования адресов Принято все байты 4-байтного IP-адреса за писывать десятичными числами , разделенными точкам и . При записи 6-байтного Ethern et-адреса кажды й байт указывается в 16-ричной системе и отделяется двоеточием . ARP-таблица необходима потому , что IP-адреса и Ethernet-адреса выбираются независимо , и нет какого-либо алгоритма для преобразования одн ого в другой . IP-адрес выбирает менеджер сети с учетом положения машины в сети internet. Если машину перемещают в другую часть сети internet, то ее IP-адрес должен быть изме нен . Ethernet-адрес выбирает производитель сетевого интерфейсного оборудования из выделенного для него по лицензии адресно г о про странства . Когда у машины заменяется плата сетевого адаптера , то меняется и ее Ethernet-а дрес . 4.2. Порядок преобразования адресов В ходе обычной работы сетевая програм ма , такая как TELNET, отправляет прикладное сообщен ие , пользуясь транспортными усл угами TCP. Мод уль TCP посылает соответствующее транспортное сообщ ение через модуль IP. В результате составляется IP-пакет , который должен быть передан драйв еру Ethernet. IP-адрес места назначения известен прикл адной программе , модулю TCP и модулю IP. Необ х одимо на его основе найти Ethernet- адрес места назначения . Для определения иском ого Ethernet-адреса используется ARP-таблица . 4.3. Запросы и ответы протокола ARP Как же заполняется ARP-таблица ? Она запол няется автоматически модулем ARP, по мере необхо димо сти . Когда с помощью существующей ARP-таблицы не удается преобразовать IP-адрес , то происходит следующее : 1) По сети передается широковещательный ARP-запрос . 2) Исходящий IP-пакет ст авится в очередь . 4.4. Продолжение преобразования адресов Новая запись в ARP-таблице появляется автоматически , спустя несколько миллисекунд после того , как она потребовалась . Как вы помните , ранее на шаге 2 исходящий IP-пакет был поставлен в очередь . Теперь с исп ользованием обновленной ARP-таблицы выполняется пре образование I Pадреса в Ethernet-адрес , пос ле чего Ethernet-кадр передается по сети . Полнос тью порядок преобразования адресов выглядит т ак : 1) По сети передается широковещательный ARP-зап рос . 2) Исходящий IP-пакет ставится в очередь . 3) Возвращается ARP-ответ , содержащ и й инфо рмацию о соответствии IP- и Ethernet-адресов . Эта информация заносится в ARP-таблицу . 4) Для преобразования IP-адреса в Ethernet-а дрес у IP-пакета , постав ленного в очередь , используется ARP-таблица . 5) Ethernet-кадр передается по сети Ethernet. Ко роче говоря , если с помощью ARP-таблицы не удается сразу осуществить преобр азование адресов , то IP-пакет ставится в оче редь , а необходимая для преобразования информ ация получается с помощью запросов и отве тов протокола ARP, после чего IP-пакет передается п о назначению . Если в сети нет машины с искомым IP-адресом , то ARP-ответа не будет и не будет записи в ARP-таблице . Протокол IP будет уничтожать IP-пакеты , направляемые по этому а дресу . Протоколы верхнего уровня не могут отличить случай повреждения сети Et hernet от случая отсутствия машины с искомым IP-адресо м . Некоторые реализации IP и ARP не ставят в очередь IP-пакеты на то время , пока они ждут ARP-ответов . Вместо этого IP-пакет просто уничтожается , а его восстановление возлагает ся на модуль TCP или прик ладной процесс , работающий через UDP. Такое восстановление выпо лняется с помощью таймаутов и повторных п ередач . Повторная передача сообщения проходит успешно , так как первая попытка уже вызва ла заполнение ARP-таблицы . Следует отметить , что каждая машина и меет отдельную ARP-таблицу для каждого с воего сетевого интерфейса. 5. Межсетевой протокол IP Модуль IP является базовым элементом технол огии internet, а центральной частью IP является его таблица маршрутов . Протокол IP использует эту таблицу при принят ии всех решений о маршрутизации IP-пакетов . Содержание таблицы м аршрутов определяется администратором сети . Ошибк и при установке маршрутов могут заблокировать передачи . Чтобы понять технику межсетевого взаимоде йствия , нужно понять то , как используется таб лица маршрутов . Это понимание необходи мо для успешного администрирования и сопровож дения IP-сетей. 5.1. Прямая маршрутизация Менеджер сети присваивает каждой сети Ethernet уникальный номер , называемый IP-номером сети . На рис .7 IP-номера не показаны , вмест о них используются имена сетей . Когда машина A посылает IP-пакет машине B, то процесс передачи идет в пределах одной сети . При всех взаимодействиях между маши нами , подключенными к одной IP-сети , используетс я прямая маршрутизация , обсуждавшаяся в преды дуще м примере . Когда машина D взаимодействует с машиной A, то это прямое взаимодействие . Когда машина D взаимодействует с машиной E, то это прямое взаимодействие . Когда машина D взаимодействует с машиной H, то это прямое взаимодействие . Это так , поскольку каж дая пара этих машин принадлежит одной IP-сети . Однако , когда машина A взаимодействует с машинами , включенными в другую IP-сеть , то взаимодействие уже не будет прямым . Машина A должена использовать шлюз D для ретрансляции IP-пакетов в другую IP-сеть . Такое взаим одействие называется "косвенным ". Маршрутизация IP-пакетов выполняется модулями IP и является прозрачной для модулей TCP, UDP и прикладных процессов . Итак , при прямой маршрутизации IP- и Ethernet-а дреса отправителя соответствуют адресам того узла , который послал IP-пакет , а IP- и Ethernet-а дреса места назначения соответствуют адресам получателя . При косвенной маршрутизации IP- и Ethernet- адреса не образуют таких пар . В данном примере сеть internet является очен ь простой . Реальные сети могут быть го раздо сложнее , так как могут содержать несколько шлюзов и несколько типов физич еских сред передачи . В приведенном примере несколько сетей Ethernet объединяются шлюзом для того , чтобы локализовать широковещательный трафик в каждой сети . 5.3. Правила маршру т изации в модуле IP Выше мы показали , что происходит при передаче сообщений , а теперь рассмотрим п равила или алгоритм маршрутизации . Для отправляемых IP-пакетов , поступающих от модулей верхнего уровня , модуль IP должен о пределить способ доставки - прямой или ко свенный - и выбрать сетевой интерфейс . Этот выбор делается на основании результатов по иска в таблице маршрутов . Для принимаемых IP-пакетов , поступающих от сетевых драйверов , модуль IP должен решить , нужно ли ретранслировать IP-пакет по другой сети и ли передать его на верхний уровень . Если модуль IP решит , что IP-пакет должен быть ретранслирован , то дальнейшая раб ота с ним осуществляется также , как с отправляемыми IP-пакетами . Входящий IP-пакет никогда не ретранслируетс я через тот же сетевой интерфей с , через который он был принят . Решение о маршрутизации принимается до того , как IP-пакет передается сетевому драйве ру , и до того , как происходит обращение к ARP-таблице . 5.4. IP-адрес Менеджер сети присваивает IP-адреса машинам в соответствии с тем , к к аким IP-сетям они подключены . Старшие биты 4-х б айтного IP-адреса определяют номер IP-сети . Оставш аяся часть IP-адреса - номер узла (хостномер ). Для машины из табл .1 с IP-адресом 223.1.2.1 сетевой номер равен 223.1.2, а хост-номер - 1. Напомним , что IP-ад р ес узла идентифицирует точку доступа модуля IP к сетевому интерфейсу , а не всю машину . Существуют 5 классов IP-адресов , отличающиеся количеством бит в сетевом номере и хос т-номере . Класс адреса определяется значением его первого октета . Адреса класса A п редназначены для использования в больших сетях общего пользова ния . Они допускают большое количество номеров узлов . Адреса класса B используются в сетя х среднего размера , например , сетях университе тов и крупных компаний . Адреса класса C исп ользуются в сетя х с небольшим ч ислом компьютеров . Адреса класса D используются при обращениях к группам машин , а адрес а класса E зарезервированы на будущее . Прежде чем вы начнете использовать се ть с TCP/IP, вы должны получить один или не сколько официальных сетевых номеров . Выделен ием номеров (как и многими другими вопроса ми ) занимается DDN Network Information Center (NIC) [2]. Выделение номеров произв одится бесплатно и занимает около недели . Вы можете получить сетевой номер вне зави симости от того , для чего предназначена в аша сеть . Даже если ваша сеть не имеет связи с объединенной сетью Internet, получение уникального номера желательно , так как в этом случае есть гарантия , что в будущем при включении в Internet или при подключении к сети другой организации не возникнет кон ф ликта адресов . Одно из важнейших решений , которое нео бходимо принять при установке сети , заключает ся в выборе способа присвоения IP-адресов в ашим машинам . Этот выбор должен учитывать перспективу роста сети . Иначе в дальнейшем вам придется менять адреса . К огда к сети подключено несколько сотен машин , из менение адресов становится почти невозможным . Организации , имеющие небольшие сети с числом узлов до 126, должны запрашивать сетевые номера класса C. Организации с большим чис лом машин могут получить нескольк о но меров класса C или номер класса B. Удобным ср едством структуризации сетей в рамках одной организации являются подсети . 5.6. Подсети Адресное пространство сети internet может быть разделено на непересекающиеся подпространства - "подсети ", с каждой из к оторых можно работать как с обычной сетью TCP/IP. Таким образом единая IP-сеть организации может стр оиться как объединение подсетей . Как правило , подсеть соответствует одной физической сети , например , одной сети Ethernet. [2] SRI International, Room EJ21 0, 333 Ravenswood Avenue, Menlo Park, California 94025, USA. Тел . 1-800-235-3155. E-mail: NIC@NIC.DDN.MIL клас са C. Однако такое решение имеет два недост атока . Первый , и менее существенный , заключаетс я в пустой трате сетевых номеров . Более серьезный недос т аток состоит в том , что если ваша организация имеет неск олько сетевых номеров , то машины вне ее должны поддерживать записи о маршрутах дос тупа к каждой из этих IP-сетей . Таким об разом , структура IP-сети организации становится видимой для всего мира . При к а ких-либо изменениях в IP-сети информация о н их должна быть учтена в каждой из маш ин , поддерживающих маршруты доступа к данной IP-сети . Подсети позволяют избежать этих недостатк ов . Ваша организация должна получить один сетевой номер , например , номер класса B. Ст андарты TCP/IP определяют структуру IP-адресов . Для IP- адресов класса B первые два октета являются номером сети . Оставшаяся часть IP-адреса може т использоваться как угодно . Например , вы можете решить , что третий октет будет опре делять номер подсети, а четверый о ктет - номер узла в ней . Вы должны опис ать конфигурацию подсетей в файлах , определяю щих маршрутизацию IP-пакетов . Это описание являе тся локальным для вашей организации и не видно вне ее . Все машины вне вашей организации видят одну большую IPсе т ь . Следовательно , они должны поддерживать только маршруты доступа к шлюзам , соединя ющим вашу IP-сеть с остальным миром . Изменен ия , происходящие в IP-сети организации , не ви дны вне ее . Вы легко можете добавить н овую подсеть , новый шлюз и т.п . 5.7. Как на зн а чать номера сетей и подсетей После того , как решено использовать по дсети или множество IP-сетей , вы должны реши ть , как назначать им номера . Обычно это довольно просто . Каждой физической сети , нап ример , Ethernet или Token Ring, назначается отдельный номер подсети или номер сети . В некоторых случаях имеет смысл назначать одной физиче ской сети несколько подсетевых номеров . Напри мер , предположим , что имеется сеть Ethernet, охватываю щая три здания . Ясно , что при увеличении числа машин , подключенных к этой сети, придется ее разделить на несколько отдельных сетей Ethernet. Для того , чтобы избежать необходимости менять IP-адреса , когда это про изойдет , можно заранее выделить для этой с ети три подсетевых номера - по одному на здание . (Это полезно и в том случае , ког д а не планируется физическое д еление сети . Просто такая адресация позволяет сразу определить , где находится та или иная машина .) Однако прежде , чем выделять три различных подсетевых номера одной физи ческой сети , тщательно проверьте , что все ваши программы с пособны работать в такой среде . Вы также должны выбрать "маску подсети ". Она используется сетевым программным обеспе чением для выделения номера подсети из IP-а дресов . Биты IP-адреса , определяющие номер IP-сети , в маске подсети должны быть равны 1, а биты, определяющие номер узла , в мас ке подсети должны быть равны 0. Как уже отмечалось , стандарты TCP/IP определяют количество окт етов , задающих номер сети . Часто в IP-адресах класса B третий октет используется для за дания номера подсети . Это позволяет иметь 2 5 6 подсетей , в каждой из которых может быть до 254 узлов . Маска подсети в такой системе равна 255.255.255.0. Но , если в ва шей сети должно быть больше подсетей , а в каждой подсети не будет при этом более 60 узлов , то можно использовать маску 255.255.255.192. Это позволяет иметь 1024 подсети и до 62 узлов в каждой . (Напомним , что номера узлов 0 и "все единицы " используются особым образом .) Обычно маска подсети указывается в фа йле стартовой конфигурации сетевого программного обеспечения . Протоколы TCP/IP позво ляют также запрашивать эту информацию по сети. 5.8. Имена В большинстве случаев файлы "hosts" могут б ыть одинаковы на всех узлах . Заметим , что о узле delta в этом файле есть всего одна запись , хотя он имеет три IP-адреса (рис .11). Узел delta доступен по л юбому из этих IP-адресов . Какой из них используется , не имеет значения . Когда узел delta получает IP-пакет и проверяет IP-адрес места назначен ия , то он опознает любой из трех своих IP-адресов . Эти три строки файла hosts задают каждому IP-адресу узла delta символьные имена . Факт ически , первый IP-адрес имеет два имени : "devnetrouter" и "delta", которые являются синонимами . На практике имя "delta" используется как общеупотребительное и мя машины , а остальные три имени - для администрирования сети . Файлы hosts и networks используются командами администрирования и прикладными программами . Он и не нужны собственно для работы сети internet, но облегчают ее использование. 5.9. IP-таблица маршрутов Как модуль IP узнает , какой именно сетев ой интерфейс нужно использо вать для о тправления IP-пакета ? Модуль IP осуществляет поиск в таблице маршрутов . Ключом поиска служит номер IP-сети , выделенный из IP-адреса места назначения IP-пакета . Таблица маршрутов содержит по одной с троке для каждого маршрута . Основными столбца ми таблицы маршрутов являются номер сет и , флаг прямой или косвенной маршрутизации , IP-адрес шлюза и номер сетевого интерфейса . Эта таблица используется модулем IP при обра ботке каждого отправляемого IP-пакета . В большинстве систем таблица маршрутов может быт ь изменена с помощью кома нды "route". Содержание таблицы маршрутов определяется менеджером сети , поскольку менеджер сети присваивает машинам IP-адреса . 5.10. Подробности прямой маршрутизации Узел alpha посылает IP-пакет узлу beta. Этот пак ет находится в м одуле IP узла alpha, и IP-а дрес места назначения равен IP-адресу beta (223.1.2.2). Моду ль IP с помощью маски подсети выделяет номе р сети из IP-адреса и ищет соответствующую ему строку в таблице маршрутов . В дан ном случае подходит первая строка . Остальная информация в найденной ст роке указывает на то , что машины этой сети доступны напрямую через интерфейс номер 1. С помощью ARPтаблицы выполняется преобразован ие IP-адреса в соответствующий Ethernetадрес , и че рез интерфейс 1 Ethernet-кадр посылается узлу bet a . Если прикладная программа пытается послат ь данные по IP-адресу , который не принадлежи т сети development, то модуль IP не сможет найти соответствующую запись в таблице маршрутов . В этом случае модуль IP отбрасывает IP-пакет . Н екоторые реализации протокол а возвращают сообщение об ошибке "Сеть не доступна ". 5.12. По дробности косвенной маршрутизации Узел alpha посылает IP-пакет узлу epsilon. Этот па кет находится в модуле IP узла alpha, и IP-адрес места назначения равен IP-адресу узла epsilon (223.1.3.2). М од уль IP выделяет сетевой номер из IP-адр еса (223.1.3) и ищет соответствующую ему строку в таблице маршрутов . Соответствие находится в о второй строке . Запись в этой строке указывает на то , что машины требуемой сети доступны через шлюз devnetrouter. Модуль I P в узле alpha осущес твляет поиск в ARP-таблице , с помощью которог о определяет Ethernet-адрес , соответствующий IP-адресу devnetrouter. Затем IP-пакет , содержащий IP-адрес места назн ачения epsilon, посылается через интерфейс 1 шлюзу devnetrouter. IP-пакет принимается сетевым интерфейсо м в узле delta и передается модулю IP. Проверяет ся IP-адрес места назначения , и , поскольку он не соответствует ни одному из собственны х IP-адресов delta, шлюз решает ретранслировать IP-пак ет . Узел epsilon принимает IP-пакет , и его м одуль IP проверяет IP-адрес места назначения . Он соответствует IP-адресу epsilon, поэтому содержащееся в IP-пакете сообщение передается протокольному м одулю верхнего уровня. 6. Установка маршрутов До сих пор мы рассматривали то , ка к используетс я таблица маршрутов для маршрутизации IP-пакетов . Но откуда берется инфо рмация в самой таблице маршрутов ? В данном разделе мы рассмотрим методы , позволяющие поддерживать корректность таблиц маршрутов . 6.1. Ф иксированные маршруты Простейший способ проведен ия маршрути зации состоит в установке маршрутов при з апуске системы с помощью специальных команд . Этот метод можно применять в относительн о маленьких IP-сетях , в особенности , если их конфигурации не часто меняются . На практике большинство машин автоматичес ки формирует таблицы маршрутов . Например , UNIX добавляет записи о IP-сетях , к которым есть непосредственный доступ . Стартовый файл может содержать команды ifconfig ie0 128.6.4.4 netmask 255.255.255.0 ifconfig ie1 128.6.5.35 netmask 255.255.255.0 Они по казывают , что сущ ествуют два сетевых интерфейса , и устанавлива ют их IP-адреса. В стартовом файле могут быть команды , определяющие маршруты доступа к другим 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-адрес места назначения не встречается в таблице маршрутов явно . Обычно маршрут по у молчанию указывает 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 должны использовать со общения о перенаправлении для добавления запи сей в таблицу маршрутов . Предположим , таблица марш р утов в начале выглядит следующим образом : Эта таблица содержит запись о локальн ой 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 на машине-отправителе должен добавить запись в таблицу маршрутов : До сих пор мы рассматривали способы добавления маршрутов в 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). Фактически машина A спрашивает : "Если кто-ни будь знает Et hernet-адрес узла 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, и имеет E t hernet-адрес 2:7:1:0:EB:CD. Когда узел A захочет послать нов ый IP-пакет узлу B, он использует указанный Ethernet-адрес . Кадр , содержащий IP-пакет , попадет к шлюзу R, а он переправит его по назначени ю . Обычно рекомендуется использовать таблицу маршрутов , т ак как архитектура протокол ов TCP/IP предусматривает выполнение маршрутизации на межсетевом уровне . Однако иногда протокол ARP с представителем очень полезен . Он может помочь в следующих случаях : 1) в IP-сети ест ь узел , который не умеет работать с по дсетя м и ; 2) в IP-сети есть узел , ко торый не может соответствующим образом реаги ровать на сообщения перенаправления ; 3) неже лательно выбирать какой-либо шлюз как маршрут по умолчанию ; 4) программное обеспечение не способно восстанавливаться при сбоях на маршрут ах . Иногда протокол ARP с представителем выбираю т из-за удобства . Дело в том , что он упрощает работу по начальной установке таб лицы маршрутов . Даже в простейших IP-сетях т ребуется устанавливать маршрут по умолчанию , то есть использовать команду типа "rout e 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-серии ис пользуются главным образом в системах , работающих под управлен ием ОС 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 - это гораздо больше , чем просто утилита для рисования окон ; это целая философия человеко-машинного взаимод ействия.
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Финансовое право
32Хозяйственное право
33Экологическое право
34Юриспруденция
 
35Иностранные языки
36Информатика, информационные технологии
37Базы данных
38Компьютерные сети
39Программирование
40Искусство и культура
41Краеведение
42Культурология
43Музыка
44История
45Биографии
46Историческая личность
47Литература
 
48Маркетинг и реклама
49Математика
50Медицина и здоровье
51Менеджмент
52Антикризисное управление
53Делопроизводство и документооборот
54Логистика
 
55Педагогика
56Политология
57Правоохранительные органы
58Криминалистика и криминология
59Прочее
60Психология
61Юридическая психология
 
62Радиоэлектроника
63Религия
 
64Сельское хозяйство и землепользование
65Социология
66Страхование
 
67Технологии
68Материаловедение
69Машиностроение
70Металлургия
71Транспорт
72Туризм
 
73Физика
74Физкультура и спорт
75Философия
 
76Химия
 
77Экология, охрана природы
78Экономика и финансы
79Анализ хозяйственной деятельности
80Банковское дело и кредитование
81Биржевое дело
82Бухгалтерский учет и аудит
83История экономических учений
84Международные отношения
85Предпринимательство, бизнес, микроэкономика
86Финансы
87Ценные бумаги и фондовый рынок
88Экономика предприятия
89Экономико-математическое моделирование
90Экономическая теория

 Анекдоты - это почти как рефераты, только короткие и смешные Следующий
Девушка всех уверяла, что она не красива, но алкоголь не обманешь.
Anekdot.ru

Узнайте стоимость курсовой, диплома, реферата на заказ.

Обратите внимание, реферат по программированию "Протоколы TCP/IP", также как и все другие рефераты, курсовые, дипломные и другие работы вы можете скачать бесплатно.

Смотрите также:


Банк рефератов - РефератБанк.ру
© РефератБанк, 2002 - 2016
Рейтинг@Mail.ru