• Сетевые протоколы. Протоколы локальных сетей

    Модели и протоколы компьютерных сетей

    13.6.1. Общее представление

    Протокол в общем смысле представляет собой правила поведения, известные обеим взаимодействующим сторонам. То же самое представляют собой сетевые протоколы: правила поведения, известные обеим взаимодействующим сторонам. Что, в какой момент, в ответ на какое сообщение нужно сделать, какие данные

    Для планомерного развития и стандартизации сетевых соединений, служб, технологии и устройств, необходимо некоторое всеобщее рамочное соглашение, определяющее основные принципы, параметры и термины, на основе которых можно будет разрабатывать конкретные решения. Такое рамочное соглашение, в общих чертах определяющее порядок приема и передачи информации на всех уровнях сетевого взаимодействия, получило название сетевой модели.


    Известно несколько стеков протоколов, самыми широко распространенны­ми из которых являются TCP/IP, IPX/SPX, NetBIOS/SMB. Мы ограничимся рассмотрением стека TCP/IP, поскольку на протоколах этого стека построен весь Интернет.

    13.6.2. Стек протоколов TCP/IP

    Уровень сетевых интерфейсов

    Уровню сетевых интерфейсов не сопоставлен ни один протокол, но на нем реа­лизована поддержка практически всех известных сегодня технологий и протоколов объединения компьютеров в сеть.

    Уровень межсетевого взаимодействия

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

    □ IP (Internet Protocol - протокол межсетевого взаимодействия). Решает задачу передачи данных между сетями.

    □ RIP (Routing Information Protocol - протокол маршрутной информации) и OSPF (Open Shortest Path First - выбор кратчайшего пути первым). Про­токолы сбора и конфигурирования маршрутной информации, отвечающие за выбор оптимального маршрута передачи данных.

    □ ICMP (Internet Control Message Protocol - протокол межсетевых управляющих сообщений). При помощи этого протокола собирается информация об ошибках доставки и длительности жизни пакетов, а также передаются тестирующие со­общения, подтверждающие наличие запрошенного узла в сети.

    Транспортный уровень

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

    □ TCP (Transmission Control Protocol - протокол управления передачей). Описы­вает правила создания логического соединения между удаленными процессами и механизм обработки ошибок доставки пакетов (механизм повторной передачи «сбойных» пакетов).

    □ UDP (User Datagramm Protocol - протокол пользовательских датаграмм). Упрощенный вариант протокола доставки данных без установления логического соединения и проверки ошибок доставки пакетов.

    Прикладной уровень

    К прикладному уровню относятся протоколы, носящие прикладной характер. Большинство этих протоколов связано с соответствующими прикладными про­граммами, работающими на их основе.

    □ FTP (File Trancfer Protocol - протокол передачи файлов). В качестве транс­портного протокола этот протокол использует TCP, что повышает надежность передачи файлов через большое количество промежуточных узлов.

    □ TFTP (Trivial File Trancfer Protocol - простейший протокол передачи файлов). Этот протокол базируется на UDP и используется в локальных сетях.

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

    □ Telnet - протокол, используемый для эмуляции терминала удаленной станции.

    □ SMTP (Simple Mail Transfer Protocol - простой протокол передачи сообщений). Передает сообщения электронной почты при помощи транспортного протокола TCP.

    □ HTTP (Hiper Text Transfer Protocol - протокол передачи гипертекста). Базовый протокол Всемирной паутины, без которой сегодня невозможно представить себе Интернет. Именно он обеспечивает передачу страниц сайтов на наши компьютеры.

    Кроме перечисленных базовых протоколов, в состав стека TCP/IP на приклад­ном уровне входит еще множество протоколов.


    13.6.3. Сетевая модель OSI

    Когда стек протоколов TCP/IP уже в полную силу обеспечивал функциониро­вание самых разнообразных сетей, международная организация по стандартизации (International Organization for Standartization, ISO) разработала концептуальную модель взаимодействия открытых систем (Open Systems Interconnection, OSI). Эта модель оказалась настолько удачной, что в настоящее время многие сетевые процессы и проблемы принято описывать именно в терминах модели OSI. В модели OSI три базовых понятия: уровень, интерфейс и протокол.

    Уровни пронумерованы от 7-го (верхний уровень) до 1-го (нижний уровень). Чем выше уровень, тем более глобальны решаемые им задачи. Каждый вышесто­ящий уровень реализует свою функциональность, получая услуги от нижележа­щего уровня и управляя им. Управление и передача услуг осуществляются через стандартные интерфейсы, благодаря которым вышестоящий уровень изолируется от детализации того, как именно реализует услуги нижележащий уровень. Вза­имодействие протоколов смежных уровней в одном узле осуществляется через интерфейсы.


    9) Маршрутизация: статическая и динамическая на примере RIP, OSPF и EIGRP.
    10) Трансляция сетевых адресов: NAT и PAT.
    11) Протоколы резервирования первого перехода: FHRP.
    12) Безопасность компьютерных сетей и виртуальные частные сети: VPN.
    13) Глобальные сети и используемые протоколы: PPP, HDLC, Frame Relay.
    14) Введение в IPv6, конфигурация и маршрутизация.
    15) Сетевое управление и мониторинг сети.

    P.S. Возможно, со временем список дополнится.


    Как вы помните из прошлой статьи (если не читали, то в содержании есть ссылка на нее), модель OSI в нынешнее время служит только в качестве обучения ролям каждого уровня. Работают же сети по стеку протоколов TCP/IP. Хоть TCP/IP состоит из 4 уровней, он вполне реализует все функциональные возможности, реализуемые в модели OSI. Ниже на картинке приведены сравнения уровней и их ролей.

    Начинаем разговор про протоколы верхнего уровня. Я не просто так назвал тему «Протоколы верхнего уровня», а не «Протоколы верхних уровней». Так как разбираем мы этот уровень по стеку TCP/IP, то у нас он «один за трех».

    Вообще с точки зрения сетевика, нам все равно, что происходит внутри прикладного уровня. Этим, как правило, занимаются программисты. Но важно знать, как формируются данные и инкапсулируются в нижестоящие уровни.
    У нас на работе, например, есть правило: мы обеспечиваем запуск приложения и его безошибочную передачу по сети. Если проблема заключается во внутренних программных сбоях, то мы переключаем на разработчиков, и это становится их заботой. Но бывают и проблемы, которые идут по тонкой грани между нами, и мы решаем их вместе.

    Итак, протоколы прикладного уровня обеспечивают взаимодействие между человеком и сетью. Этих протоколов огромное количество, и выполняют они совершенно различные роли. Я приведу примеры часто используемых протоколов в сети и покажу, как они работают на практике: HTTP, DNS, DHCP, SMTP и POP3, Telnet, SSH, FTP, TFTP.

    I) Протокол HTTP (англ. HyperText Transport Protocol). Протокол передачи данных, используемый обычно для получения информации с веб-сайтов. С каждым годом этот протокол становится все популярнее, и возможностей для его применения становится все больше. Использует он «клиент-серверную» модель. То есть существуют клиенты, которые формируют и отправляют запрос. И серверы, которые слушают запросы и, соответственно, на них отвечают.

    В качестве клиентов выступают известные многим веб-браузеры: Internet Explorer, Mozilla Firefox, Google Chrome и т.д. А в качестве серверного ПО используют:Apache, IIS, nginx и т.д.

    Для того, чтобы разобраться глубже в протоколе HTTP, взглянем на HTTP запрос от клиента к серверу.


    Нас интересуют только самая верхняя и самая нижняя строчки.

    В первой строчке используется такое понятие, как GET . Это, по сути, ключ запроса. Так как после GET стоит символ "/", то это означает, что запрашивается главная или корневая страница по URL (англ. Uniform Resource Locator) пути.

    URL - это некий идентификатор какого-либо ресурса в сети.

    Так же в этой строчке присутствует такая запись, как HTTP/1.1 . Это версия протокола. Довольно популярная версия. Выпустили ее в 1999 году, и до сих пор она служит верой и правдой. Хоть недавно был анонс версии 2.0, версия 1.1 занимает пока лидирующее положение.

    Теперь о нижней строчке. Здесь указывается адрес сервера или имя, на котором располагается нужный ресурс. Давайте посмотрим, как это работает на практике. Я буду использовать свою любимую программу Cisco Packet Tracer 6.2 (в дальнейшем CPT). Она проста в освоении и для демонстрации описанного идеально подходит. Могу сказать с уверенностью, что для подготовки к CCNA R&S, ее хватает вполне. Но только для нее.

    Открываем программу и добавим туда компьютер с сервером (находятся они на вкладке «End Devices»), как на картинке ниже


    Соединяем компьютер с сервером перекрестным кабелем (англ. crossover cable). В CPT он находится на вкладке «Connections», обозначается пунктиром и называется «Copper Cross-Over».

    Теперь займемся настройкой компьютера и веб-сервера.


    1) Отрываем вкладки «Desktop» на рабочем компьютере и сервере, далее переходим в окно «IP Configuration». Откроются окна, как на рисунке выше. Это окна конфигурации узлов в сети.

    2) Укажем IP-адреса в строки, указанные цифрой 2. Как помним из предыдущей статьи, IP-адреса нужны для идентификации узлов в сети. Подробнее мы разберем эту тему позже. Сейчас главное понимать, для чего нужен IP-адрес. Я специально выбрал сеть, начинающуюся с «192.168», так как она встречается чаще всего в домашних сетях.

    3) В поля, указанные цифрой 3, вводится маска подсети. Она нужна для того, чтобы узлу было понятно, в одной подсети он находится с другим узлом или нет. Но об этом позже.
    Остальные значения оставим пустыми.

    Теперь требуется включить сервис HTTP на сервере.


    1) Переходим на вкладку «Services».
    2) Выбираем слева сервис HTTP.
    3) Открывается окно настройки сервиса и файловый менеджер. Если у кого есть навыки по работе c HTML, то можете здесь создать страницу. Но у нас уже есть готовый шаблон, и мы им воспользуемся. Не забываем включить службу HTTP и HTTPS.

    Раз уже зашла речь о HTTPS (HyperText Transfer Protocol Secure), то скажу про него пару слов. Это, по сути, расширение протокола HTTP, которое поддерживает криптографические протоколы и передает информацию не в открытом виде, а в зашифрованном. В CPT очень поверхностно показана его работа, но для понимания вполне достаточно. Вспоминаем и запоминаем: HTTP использует 80 порт, а HTTPS 443 порт. Вообще номеров портов очень много, и все запомнить тяжело, но часто встречающиеся лучше запомнить.

    Теперь самое интересное. Нам надо перевести CPT из режима «Realtime» в режим «Simulation». Отличие их в том, что в режиме «Realtime» сеть ведет себя так, как она повела бы себя в реальной жизни и в реальном времени. Режим «Simulation» позволяет нам наблюдать за поведением сети в разные временные интервалы, а также проследить за каждым пакетом, раскрыть его и посмотреть, что он в себе несет. Переключаем среду, как показано на рисунке ниже.


    Здесь открывается «Simulation Panel», в которой несколько опций. Есть фильтр, в котором можно указать протоколы, которые вы хотите отслеживать, скорость перемещения пакета и навигационная панель, где можно наблюдать за сетью вручную, нажатием «Capture/Forward» или автоматически, при помощи кнопки «Auto Capture/Play».

    Оставляем все, как есть, и открываем компьютер.


    Переходим на вкладку «Desktop» и открываем «WEB Browser». Перед нами открывается окно веб-браузера. В строке URL пишем адрес нашего веб-сервера, нажимаем кнопку «Go» и наблюдаем следующую картину.


    Появились первые посылаемые данные на схеме и в окне «Simulation Panel». Это сегменты TCP, которые создадут сессию между компьютером и сервером. Сейчас нам это не интересно, и мы об этом поговорим в следующей статье. Поэтому я пропущу их до момента, когда будут созданы HTTP. Делать я это буду при помощи кнопки «Capture/Forward».


    И вот после установления соединения, компьютер формирует первые HTTP данные. В дальнейшем я буду называть их PDU, чтобы вы привыкали к данным терминам.

    1) Смотрим на схему и видим, что появилось 2 конверта. Это и есть наши данные. Нас интересует фиолетовый конверт. Это и есть созданный PDU.

    2) Теперь смотрим на «Simulation Panel» и видим, что в таблице появилась запись с типом HTTP. Эти данные нас интересуют. Также рядом с записью показан цвет, которым окрашены эти данные на схеме.

    3) Кликаем по HTTP (фиолетовый конверт), и перед нами открывается окно данных. Тут кратко показаны все нужные сведения по каждому уровню модели OSI. Можно кликнуть по любому уровню и получить информацию о том, что происходит на нем.

    Если вам интересно полностью раскрыть данные и рассмотреть подробно, из каких полей они состоят и что в них происходит, есть вкладка «Outbound PDU Details». Давайте перейдем на нее и посмотрим, как выглядят HTTP данные.


    На этой вкладке будут выводиться данные на всех уровнях. Нам пока надо посмотреть на HTTP. Они находятся в самом низу, поэтому тянем бегунок вниз. Выглядят они так же, как я и описывал их раньше.

    Теперь нам интересен этап, когда веб-сервер получит запрос и начнет предпринимать какие-то действия. Давайте нажмем на «Capture/Forward» и посмотрим, чем веб-сервер ответит. И вот, на рисунке ниже видим, что он отправил компьютеру какие-то данные. Давайте посмотрим, как они выглядят.


    1) Я случайно пережал кнопку и он уже начал формировать TCP на закрытие сессии. Ничего страшного. Находим PDU, адресованные от веб-сервера к клиенту. Как видим, он сразу показывает нам на схеме момент времени, в который я кликнул. Выбираем нужный конверт.

    2) Здесь уже видим другую картину. Сверху указывается версия HTTP, код «200 OK», означающий, что отправляется запрашиваемая страница, а не сообщение об ошибке. Далее указывается длина контента, тип файла, а также с какого сервера отправляется. И в самой нижней строке указывается, что передаются какие-то данные. После того, как данные дойдут до компьютера, можно наблюдать, что веб-браузер компьютера открыл страницу.


    Вот так работает протокол HTTP. Давайте рассмотрим его расширенную версию HTTPS. Как мы помним, эта версия поддерживает шифрование и не передает данные в открытом виде. В самом начале, мы включили сервис HTTP и HTTPS. Поэтому все готово, и можно запрашивать страницу. Отличие запроса в том, что перед адресом страницы вместо HTTP, пишем HTTPS.


    Видим надпись, что данные защищены, и мы их прочитать не можем. В принципе это все отличия, которые может показать CPT, но для базового понимания этого достаточно. От себя добавлю, что когда вы переходите на сайт, работающем по HTTPS, в браузере он обозначается в виде замка. Например

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

    Мы поговорили про HTTP, и теперь время разобрать протокол DNS. Данный протокол тесно связан с предыдущим протоколом, и скоро вы поймете почему.

    II) DNS (Domain Name System) . Система доменных имен. Если говорить в целом, то она хранит информацию о доменах. Например, какому IP адресу соответствует определенное имя. Приведу пример: когда вы открываете свой любимый сайт, то обращаетесь к нему по имени. Но в поля Source Address и Destination Address, которые работают на сетевом уровне (это тема следующей статьи, но я немного забегу вперед), нельзя вставить имя. Там обязательно должен присутствовать именно IP адрес. Вот DNS как раз этим и занимается. Она сообщает, какой IP адрес у запрошенного имени. Вы, к примеру, обращаетесь на google.ru. Ваш компьютер понятия не имеет, кто и что это. Он спрашивает у DNS-сервера: Кто такой google.ru? И сервер отвечает, что google.ru - это 74.125.232.239 (это один из его адресов). И уже после этого, компьютер отправляет запрос на 74.125.232.239. Для пользователя все останется по-прежнему, и в адресной строке он также будет видеть google.ru.

    Как обычно, покажу это на картинке


    Думаю, что выше описанное понятно, и двигаемся дальше. Служба эта иерархичная. И часто DNS-сервер (на котором запущена эта служба) работает в связке с другими DNS-серверами. Давайте разберем, что это значит. Иерархичность его заключается в том, что он работает с доменами уровня. Работает он от младшего уровня к старшему, слева направо.

    Например имя: ru.wikipedia.org. Cамым старшим будет доменное имя «org», а младшим - «ru». Но часто бывают случаи, когда DNS-сервер не может нам рассказать о каком-то доменном имени, и тогда он обращается к старшему DNS-серверу, который отвечает за доменные имена более высокого уровня. Не буду изобретать велосипед и приведу картинку из википедии. Там эта работа проиллюстрирована хорошо.


    Предположим, мы набрали в браузере адрес ru.wikipedia.org. Браузер спрашивает у сервера DNS: «какой IP-адрес у ru.wikipedia.org»? Однако сервер DNS может ничего не знать не только о запрошенном имени, но даже обо всём домене wikipedia.org. В этом случае сервер обращается к корневому серверу - например, 198.41.0.4. Этот сервер сообщает - «У меня нет информации о данном адресе, но я знаю, что 204.74.112.1 является ответственным за зону org.» Тогда сервер DNS направляет свой запрос к 204.74.112.1, но тот отвечает «У меня нет информации о данном сервере, но я знаю, что 207.142.131.234 является ответственным за зону wikipedia.org.» Наконец, тот же запрос отправляется к третьему DNS-серверу и получает ответ - IP-адрес, который и передаётся клиенту - браузеру.

    Открываю CPT и показываю, как это работает. Эта и следующие лабораторные работы буду основываться на предыдущей. Поэтому адресация будет такой же.


    Здесь добавлен еще один сервер, который будет выполнять роль DNS-сервера и коммутатор. Когда в сети появляются 3 и более устройств, то для их соединения используют коммутатор.

    Займемся настройкой DNS-сервера. Зайдем в «IP Configuration» и пропишем IP адрес с маской.

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


    1) В окне «Name» запишем имя, которое хотим привязать к IP адресу. (я написал имя своего будущего сайта, над которым идет работа).
    2) В окне «Address», соответственно, IP-адрес, который будет работать в связке с выше написанным именем. (здесь укажем тот же адрес, что и в лабораторной по HTTP - 192.168.1.2).
    3) Нажимаем кнопку «Add», чтобы добавить эту запись.
    4) Не забываем включить саму службу!

    Если все выполнили верно, то картина должна быть такой.


    Теперь надо в настройках сервера и компьютера указать адрес DNS-сервера.


    Настройка DNS-сервера и узлов закончена, и самое время проверить, как это дело работает. Переключаем среду в режим симуляции и попробуем с компьютера зайти на сайт по имени «cisadmin.ru».


    И видим, что создаются 2 конверта. Первый - это DNS, а второй - ARP. О ARP мы толком не говорили, так как это тема следующей статьи. Но раз он показал себя, то вкратце расскажу, для чего он. Как мы помним, для обмена между узлами недостаточно IP адреса, так как еще используются MAC-адреса, работающие на канальном уровне. Мы указали компьютеру IP адрес DNS-сервера. Но он не знает, какой у узла с IP-адресом 192.168.1.3 MAC-адрес. Он формирует ARP сообщение и выбрасывает его в сеть. Данный кадр (данные на канальном уровне называются - кадры) является широковещательным, то есть его получат все участники, находящиеся в одной локальной сети (правильно сказать все участники в одном широковещательном домене, но пока мы это не затрагивали, и я не буду грузить вас этим термином). И тот, у кого этот адрес, отправит обратное сообщение и сообщит свой MAC-адрес. Все остальные участники отбросят этот кадр. Смотрим рисунки.


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


    Кадры были разосланы и наблюдаем следующее. Кадр, который пришел на веб-сервер был отброшен, о чем говорит перечеркнутый конверт. Следовательно, кадр отбрасывается. А DNS-сервер, наоборот, узнал свой адрес и должен сформировать ответ.


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

    1) MAC-адреса. В Source MAC он записывает свой MAC-адрес, а в Destination MAC (Target MAC) адрес компьютера.
    2) В Source IP свой IP адрес, а в Target IP адрес ПК.

    Я думаю, здесь все понятно. Если непонятно, то спрашивайте. В следующей статье я более подробно о нем расскажу.

    Я нажимаю на «Capture/Forward» и смотрю, что будет дальше происходить.


    И вижу, что компьютер успешно получил ARP от сервера. Теперь он знает MAC-адрес DNS-сервера, а значит, и как с ним связаться. И сразу решает узнать у него, кто такой «cisadmin.ru». Мы можем открыть эти данные и посмотреть, что он там решил отправить. Открываем «Outbound PDU Details» и спускаемся в самый низ. Видим, что в верхнем поле «NAME» он записал запрашиваемое имя. Жмем кнопку «Capture/Forward» и cмотрим.


    DNS-сервер получает DNS-запрос. Он лезет в свою таблицу и видит, что такая запись у него присутствует, и формирует ответ. Открываем и видим, что изменилось поле LENGTH и равняется 4. То есть 4 байта. Столько занимает IP адрес. И, соответственно, записывает сам IP-адрес - 192.168.1.2. Это и есть адрес веб-сервера. Двигаюсь дальше.


    Видим, что компьютер получил сообщение от DNS-сервера, о чем свидетельствует галочка на коричневом конверте. И теперь он знает IP адрес веб-сервера. Сразу же он пытается установить TCP сессию, но возникает проблема. Он не знает MAC-адрес веб-сервера и запускает аналогичный ARP запрос, чтобы узнать. Смотрим.


    И тут аналогично предыдущему. DNS-сервер понял, что сообщение не для него, и отбрасывает. А веб-сервер узнает свой IP адрес и формирует ARP ответ.


    Дошел до компьютера ARP ответ. Теперь он знает MAC-адрес веб-сервера и пытается установить TCP сессию. Отправляет он TCP сегмент на 80-й порт. Раз уж протокол TCP снова дал о себе знать, и в следующих протоколах он тоже будет фигурировать, то вкратце объясню зачем он нужен. Как вы помните из первой статьи, я говорил, что он устанавливает соединение. Так вот теперь каждый блок данных, который будет отправлен от сервера компьютеру, будет промаркирован. Это нужно для того, чтобы клиент понимал, все ли данные он получил или какие-то потерялись. И, если какие-то данные потерялись, он сможет запросить их повторно. Потеря блока данных сайта может привести к тому, что сайт перекосит, и он отобразится криво. Но сейчас главное понимать, что TCP располагается на транспортном уровне и работает с портами. Я специально открыл окно, где это написано, чтобы вы постепенно привыкали к этим полям.

    Посмотрим, чем ответит компьютеру веб-сервер.


    Веб-сервер отправляет компьютеру ответное сообщение, и устанавливается сессия. И, когда все готово, компьютер формирует HTTP и отсылает его веб-серверу. Давайте посмотрим, что изменилось. А изменилась у нас самая последняя строчка. Если раньше там был записан IP адрес веб-сервера, то теперь там красуется доменное имя «cisadmin.ru». Но не забывайте, что доменное имя тут записано только в данных прикладного уровня. IP-адрес никуда не делся. Он располагается на сетевом уровне. Поэтому давайте сразу покажу IP пакет, где представлены эти адреса.


    И как видите, IP адреса на месте.

    Соответственно видим, что все прекрасно работает, и сайт открывается по доменному имени.
    И напоследок упомяну об одной очень важной утилите под названием nslookup . Она позволяет обратиться к DNS-серверу и узнать у него информацию о имени или IP-адресе. В CPT эта команда присутствует, и я предлагаю взглянуть на нее.

    Кликаем по компьютеру на схеме и на вкладке «Desktop» выбираем «Command Prompt». Это имитация командной строки.


    Открывается у нас окошко, подобное cmd в ОС Windows. Можно ввести знак "?" и нажать ENTER. Она покажет список всех доступных команд. Нам нужна команда nslookup. Введем ее и нажмем ENTER.


    Открывается сама утилита, о чем свидетельствует знак птички слева. Показывается нам адрес DNS-сервера и его имя. Так как имени нету, то он дублирует туда строку с IP-адресом.

    Ну и самое время вписать туда доменное имя и узнать, что он выдаст в ответ.


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

    Есть еще один файл в каждой ОС, который тесно связан с DNS. Название у него «hosts». Стандартное расположение его в Windows системах «windows\system32\drivers\etc\hosts». А в *nix подобных системах: "/etc/hosts". Делает он то же самое, что и DNS-сервера. И контролируется этот файл администратором компьютера. И самое важное: он имеет приоритет перед DNS-сервером. И, если у вас в файле написано, что сайту сайт соответствует IP адрес, который на самом деле соответствует google.ru, то, соответственно, открывать он будет google, а не habrahabr. Этим часто пользуются злоумышленники, когда вносят исправления в этот файл. Приведу скрин этого файла со своего компьютера.


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

    Вот такая интересная служба и протокол. Также как и с HTTP, приведу ссылку на скачивание данной лабы.

    III) DHCP (Dynamic Host Configuration Protocol). Протокол динамической настройки узла. Он позволяет узлам динамически получать IP адреса и другие параметры для корректной работы в сети (основной шлюз, маску подсети, адреса DNS-серверов). От себя скажу, что этот протокол спасает жизнь многим сисадминам по всему миру. Согласитесь, что ходить и вручную прописывать IP параметры каждому узлу, не самое приятное занятие.

    При помощи DHCP можно обеспечить полный контроль над IP адресами: создавать отдельные пулы для каждой подсети, выдавать адреса в аренду, резервировать адреса и многое другое.

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

    Давайте посмотрим, как он работает на практике.


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

    Настроим сервер.


    Присваиваем свободный адрес и маску. Перейдем к роли DHCP.


    1) Выбираем службу DHCP, и тут уже создан стандартный пул. Его удалить нельзя. Только изменить. Можете сами создать несколько пулов и вытворять с ними, что угодно, вплоть до удаления. Но стандартный всегда останется. Нам дополнительные пулы не нужны, поэтому переделаем под себя стандартный.

    2) Здесь можно добавить адрес шлюза, адрес DNS-сервера. Мы пока не касались вопроса шлюза, поэтому пока не будем его трогать. DNS-сервер у нас есть, и его можно указать. Ну и старт адресов оставим, как есть.

    3) Не забываем включить сервер!

    Переключаем среду в режим симуляции и посмотрим, как компьютер получит адрес.


    Соответственно переходим в настройки конфигурации и переключаем на DHCP.


    Видим, что создался DHCP-запрос. Давайте пройдемся по каждому его уроню и поверхностно посмотрим, что внутри.

    1) Протокол канального уровня (Ethernet). В «Source MAC» записывается адрес компьютера. А в «Destination MAC» записан широковещательный адрес (то есть всем).

    2) Протокол сетевого уровня (IP). В «Source IP» записывается адрес «0.0.0.0». Этот адрес вставляется, когда у запрашиваемого нет адреса. А в «Destination IP» вставляется широковещательный адрес «255.255.255.255».


    Посмотрим на поле UDP. Здесь используются порты 67 и 68. Это UDP порты, зарезервированные для DHCP.
    Теперь смотрим на поле DHCP. Здесь все по нулям, и только в поле «CLIENT HARDWARE ADDRESS» записан MAC-адрес компьютера.

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


    И видим, что все кроме DHCP-сервера отбросили данные.

    Дальше работу протокола расскажу на словах, потому что очень много пакетов и кадров будет сформировано, перед тем как DHCP-сервер выдаст адрес. Как только он получит запрос, он начинает искать свободный адрес в базе. Как только адрес найден, начинается следующий этап - это проверка адреса. Ведь, как мы помним, адрес можно назначить и вручную, в обход DHCP-сервера. Такое часто происходит, и даже в корпоративной среде находятся умники, которые вручную вписывают адрес. Для этого DHCP-сервер перед выдачей этого адреса, отправляет ICMP сообщение или ping.

    Мы пока не говорили и об этом. Поэтому заранее скажу, что утилита ping позволяет проверить доступность узла по IP-адресу. И, если на ping DHCP-серверу кто-то ответит, то значит адрес занят и всю процедуру он будет повторять, но с другим IP-адресом. Но это тоже не самое толковое решение. Сами понимаете, что если компьютер со статически назначенным адресом будет выключен, то он не ответит на ping DHCP-сервера, и, соответственно, DHCP решит, что адрес не занят и присвоит его какому-то узлу. Но, как только компьютер включится, появится 2 компьютера с одинаковыми IP-адресами. И тут могут начаться дикие чудеса. Современные системы уже научились правильно реагировать на это, но все же не стоит этого допускать и важно следить за этим. Я пропущу в CPT все эти данные, иначе получится диафильм из однообразных картинок. Я прикреплю эту лабу ниже, и вы сможете сами в этом убедиться. Приведу только конечный итог, который сформирует DHCP-сервер.


    И видим, что в поле "«YOUR» CLIENT ADDRESS" добавился адрес 192.168.1.1. Это адрес, который DHCP-сервер предлагает компьютеру. В поле «SERVER ADDRESS» DHCP-сервер добавляет свой адрес, чтобы компьютер знал, кто предлагает ему адрес. В поле «CLIENT HARDWARE ADDRESS» добавляется MAC-адрес компьютера (то есть того, кто запросил). И в самом низу представлена опция «DHCP Domain Name Server Option». Сюда записывается адрес DNS-сервера, который мы указали в настройках сервиса DHCP.

    Посмотрим, как компьютер получит адрес.


    И наблюдаем сообщение «DHCP Request Successful». Что означает, что данные успешно получены, о чем свидетельствуют заполненные поля ниже.

    Вот так работает протокол DHCP. Как обещал, ссылка для скачивания.

    IV) POP3 (англ. Post Office Protocol Version 3). Протокол почтового отделения версии 3. Протокол, который используют клиенты для получения почтовых писем с сервера. Версии 1-ая и 2-ая устарели и в нынешнее время не используются. Работает он по принципу «загрузи и удали». Что это значит? Это значит, что клиент заходит на сервер и смотрит, есть ли для него письмо. И если оно присутствует, он загружает его к себе и ставит отметку об удалении на сервере. Хорошо это или плохо, вопрос спорный. Кто-то утверждает, что это хорошо, так как сервер не бывает перегружен ненужными письмами. Я считаю иначе. Во-первых современная инфраструктура позволяет хранить большой объем писем, а во-вторых часто случается, что пользователь удаляет или теряет важное письмо, и найти его потом становится трудно. Хотя, стоит упомянуть, что некоторые клиенты можно настроить так, чтобы они не удаляли письма с сервера. Однако при стандартных настройках они удаляют письма с сервера. Поэтому будьте внимательнее. Порт, который он прослушивает - 110. Довольно известный номер порта, поэтому возьмите себе на заметку. Так же как и у протокола HTTP, у него есть расширенная версия - POP3S. При помощи дополнительного криптографического протокола, как SSL, шифруется содержимое, и письма передаются в защищенном виде. POP3S использует 995 порт. Мы обязательно рассмотрим протокол POP3 на практике, после того, как узнаем про протокол SMTP.

    Стоит упомянуть про аналог POP3. Это протокол IMAP (англ. Internet Message Access Protocol). Протокол доступа к электронной почте. Он более умный и посложнее, чем POP3. Но главное их различие в том, что клиент, заходя на сервер, не удаляет почту, а копирует ее. Таким образом, у клиента отображается копия почтового ящика, который хранится на почтовом сервере. И если клиент у себя удаляет какое-либо письмо, то оно удаляется только у него. На сервере оригинал остается целым. Слушает он 143 порт. Рассмотреть IMAP подробно в CPT не получится, так как полноценно он там не реализован.

    V) SMTP (англ. Simple Mail Transfer Protocol). Простой протокол передачи почты. Используется он, как вы поняли, для передачи почты на почтовый сервер. Вот почему мы изучаем POP3 и SMTP параллельно. Использует он 25 порт. Это тоже важно помнить.

    Также важно помнить, что все почтовые протоколы работают по TCP-соединению. То есть с установлением соединения. Здесь важно получить каждый пакет в целости и сохранности.

    Думаю, с теоретической точки зрения все понятно. Давайте перейдем к практике и посмотрим, как это работает.

    Открою я прошлую лабораторную работу по DHCP и слегка ее модернизирую.


    Убрал я HTTP-сервер и вместо него добавил компьютер рабочего, и назвал WORKER-PC. Присвою ему IP-адрес, который был у HTTP-сервера. То есть 192.168.1.2. Старый компьютер переименовал в DIRECTOR-PC. DNS-сервер я оставил. Он нам в этой лабе еще понадобится. Сервер DHCP переименовал в Mail-Server. И давайте его настроим.


    Адрес я не менял, и он остался от прошлой лабы. Пускай таким и остается. Переходим в службы и находим «EMAIL».


    1) В поле «Domain Name» надо записать имя домена. Это то, что будет писаться после знака "@". Обязательное требование. Любая почта записывается в таком формате - логин@домен. И нажимаем кнопку «Set». Я ее уже нажал, поэтому она не активна, но если внести изменения в поле ввода доменного имени, то она снова станет активной.

    2) И создадим пользователей. В поле «User» запишем первого пользователя. Это будет «Director». И зададим пароль «123». И нажимаем на знак "+", чтобы добавить его в базу. Аналогично создадим второго пользователя. Это будет «Worker» с таким же паролем «123».

    Создание пользователей закончено, и наблюдаем следующую картину.


    1) Видим в базе список созданных пользователей. Их можно удалять, добавлять и менять пароли при помощи кнопок справа.
    2) Не забываем включить службы POP3 и SMTP. Они по умолчанию включены, но проверка лишней не будет.

    На этом настройка на стороне сервера заканчивается, и теперь перейдем к настройке на стороне клиентов. Начнем с компьютера директора. Открываем вкладку «Desktop» и выбираем Email.


    После этого сразу откроется окно настройки.


    1) В поле «Your Name» пишем любое имя. Я напишу Director.
    2) В поле «Email Address» пишем почтовый ящик. Для директора - это [email protected].
    3) В поля «Incoming Mail Server» и «Outgoing Mail Server» записываем адрес почтового сервера (192.168.1.4)
    4) В поле «User Name» пишем сам логин. То есть Director и соответственно пароль 123.
    Нажимаем кнопку «Save», и перед нами открывается почтовый клиент. CPT назвал его почтовым обозревателем.

    Аналогичная настройка будет на компьютере рабочего. Привожу скрин.

    Теперь самое время посмотреть, как работает почта. Давайте сначала посмотрим, как она работает в режиме реального времени, а после разберем подробнее в режиме симуляции.

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


    Жмем на кнопу «Compose», и перед нами открывается привычное окно.


    Здесь все как обычно. Пишем кому отправляем, тему письма, сам текст письма и нажимаем кнопку «Send».


    Видим следующее сообщение о том, что отправка завершена успешно. Замечательно! Теперь посмотрим, как письмо будет доставлено рабочему.

    Открываем почтовый клиент на компьютере рабочего.


    И видим, что письма нету. А все потому, что клиент в CPT не поддерживает автоматическое обновление и приходится это делать вручную. Нажимаем кнопку «Receive».


    Видим появившееся письмо и сообщение об успешном получении. Откроем письмо и посмотрим, не побилось ли.


    И да, письмо, действительно, дошло целым и невредимым. Ответим на это письмо и заодно проверим, что письма ходят в обе стороны. Нажимаю я кнопку «Reply» и пишу ответ.


    Отправляю письмо и перехожу к компьютеру директора. И, соответственно, жму кнопку «Receive», чтобы обновить почту.


    Появилось письмо, а ниже и сообщение об успешном получении.

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


    Письмо дошло, а значит все работает.

    Давайте разберем поподробнее. Переключим среду в режим симуляции и отправим письмо. Не буду я создавать что-то новое, а просто отвечу на выше полученное письмо.


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

    Сейчас процесс установления соединения нас мало интересует. Мы сейчас говорим про почтовые протоколы, и поэтому я пропущу этот процесс и буду ждать появления SMTP.


    1) Появился долгожданный SMTP, о чем свидетельствует запись в панели симуляции, и откроем их. Обратим внимания на TCP-порты, чтобы удостовериться, что это он. И видим, что в «Destination Port» стоит 25 номер. А в «Source Port» записан динамически придуманный порт, чтобы сервер мог идентифицировать клиента. Все правильно.

    2) Смотрим ниже на данные SMTP, и здесь нет ничего интересного. CPT показывает нам его, как обычный блок данных.


    Сервер, получив данные от компьютера, формирует ответное сообщение. Обратите внимание на изменения. Номера, которые присутствовали ранее, поменялись местами, а именно «Source Port» и «Destination Port». Теперь источником является сервер, а назначением - компьютер. Это сообщение о доставке письма серверу.

    После этого работа протокола SMTP закончена, и компьютер может начать закрывать TCP-сессию. Чем он и займется.

    Теперь когда письмо отправлено, и мы знаем, что оно лежит на сервере, попробуем получить это письмо. Открываем компьютер рабочего и жмем кнопку «Receive».


    Как и с SMTP, в POP3 тоже создается TCP-сессия. Посмотрим на номера портов. В «Destination Port» стоит 110 номер порта. Это и есть стандартный номер порта для протокола POP3. В «Source Port» стоит порт 1028.


    Вот он появился и наблюдаем, что в поле POP3 такая же картина, что и в SMTP, т.е. все то, что и так было понятно.


    Мы знаем, что оно там есть и наблюдаем, как сервер формирует ответное сообщение. И также как с SMTP, он меняет местами порты отправления и назначения. На прикладном уровне запакованы какие-то POP3 данные. Это и есть само письмо.

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


    И как только данные получены, о чем здесь свидетельствует галочка на фиолетовом пакете, письмо сразу же высвечивается в клиенте. Дальше, как и в SMTP, будет закрытие TCP-сессии.

    Привожу ссылку на скачивание этой лабы.

    И еще, что я хотел бы показать в дополнение к почтовым протоколам - это роль DNS-сервера. Вы видели, что при совершении какого-либо действия в почтовом клиенте, он внизу нам писал IP-адрес сервера. Но есть возможность указывать не IP-адрес, а доменное имя. Давайте посмотрим, как это сделать.

    Ну и самое логичное, что приходит в голову - это то, что у нас есть почтовый сервер с адресом 192.168.1.4. И с этим адресом у нас будет работать доменное имя. Соответственно заходим на DNS-сервер и сопоставим этому адресу имя.

    Настройка на стороне DNS-сервера закончена, и осталось изменить 2 строчки в почтовых клиентах компьютеров. Открываем клиент на компьютере директора.


    И нажимаем на кнопку «Configure Mail».

    Открывается окно, которое мы видели на этапе начальной конфигурации клиента.


    Здесь надо поменять строки «Incoming Mail Server» и «Outgoing Mail Server». Вместо IP-адреса записываем доменное имя и нажимаем кнопку «Save».

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

    Сразу попробуем написать письмо директору и отправить.


    И после нажатия кнопки «Send», наблюдаем следующее.


    Внизу появляется сообщение о том, что он спросил у DNS-сервера адрес, и тот ему выдал IP-адрес почтового сервера. Отправка прошла успешно.

    Теперь зайдем на компьютер директора и нажмем на кнопку «Receive».


    Получаем письмо, а надпись ниже свидетельствует об успешной доставке. Вот еще один пример использования DNS-сервера в сети.

    Разобрали мы почтовые протоколы. И переходим к разбору следующего протокола.

    VI) Telnet (от англ. terminal network). Если переводить дословно, то это сетевой терминал. Основы этого протокола были заложены давным давно, и до сих пор он не теряет своей актуальности. Применяется он для отображения текстового интерфейса, а также для управления ОС. Очень полезный протокол, и каждый сетевой инженер обязан уметь работать с ним. Объясню почему. Каждое сетевое устройство, интерфейс которого представляет собой командную строку, настраивается либо при помощи специального консольного кабеля, либо через виртуальные терминалы, в который и входит протокол Telnet. И, если консольный кабель требует нахождения специалиста рядом с настраиваемым оборудованием, то настройка при помощи виртуальных терминалов, а в данном случае Telnet, не ограничивает специалиста в расстоянии. Можно находиться в другой комнате, здании, городе и все равно иметь возможность доступа к оборудованию. Я считаю это огромным плюсом. Из минусов данного протокола отмечу, что он фактически не защищенный и все передается в открытом виде. Использует он 23 порт. А самые популярные дистрибутивы, которые работают с этим протоколом - это Putty, Kitty, XShell и т.д. Я думаю закрепим его работу на практике.

    Использовать Telnet мы будем для доступа к коммутатору Cisco 2960. Он, как и все Cisco устройства, использует разработанную компанией Cisco операционную систему IOS. А интерфейс командной строки называется CLI (Command Line Interface). Давайте для начала настроим коммутатор. Повесим на него IP-адрес, так как без него мы не сможем попасть на коммутатор и разрешим доступ по Telnet. Я не буду приводить скриншоты, так как там нет графики. Просто дам список вводимых команд и поясню для чего они.

    Switch>enable - переход в привилегированный режим. Отсюда доступно большинство команд.

    Switch#configure terminal - переход в режим глобальной конфигурации. В этом режиме возможен ввод
    команд, позволяющих конфигурировать общие характеристики системы. Из режима глобальной конфигурации можно перейти во множество режимов конфигурации, специфических для
    конкретного протокола или функции.

    Switch(config)#username admin secret cisco - создаем пользователя с именем admin и паролем cisco.

    Switch(config)#interface vlan 1 - переходим в виртуальный интерфейс и повесим на него IP-адрес. Здесь прелесть заключается в том, что не важно, на каком именно из 24-х портов он будет висеть. Нам главное, чтобы просто с какого-либо порта был доступ до него.

    Switch(config-if)#ip address 192.168.1.254 255.255.255.0 - присваиваем последний адрес 192.168.1.254 с маской 255.255.255.0

    Switch(config-if)#no shutdown - по умолчанию интерфейс выключен, поэтому включаем его. В IOS 90% команд отменяются или выключаются путем приписывания перед командой «no».

    Switch(config)#line vty 0 15 - переходим в настройки виртуальных линий, где как раз живет Telnet. От 0 до 15 означает, что применяем это для всех линий. Всего можно установить на нем до 16 одновременных соединений.

    Switch(config-line)#transport input all - и разрешаем соединение для всех протоколов. Я специально настроил для всех протоколов, так как чуть позже будет рассматриваться другой протокол и лезть сюда ради одной команды не считаю разумным.

    Switch(config-line)#login local - указываем, что учетная запись локальная, и он будет проверять ее с той, что мы создали.

    Switch#copy running-config startup-config - обязательно сохраняем конфигурацию. Иначе после перезагрузки коммутатора все сбросится.

    Итак коммутатор настроен. Давайте подключимся к нему c рабочего компьютера. Открываем командную строку. Мы ее открывали, когда рассматривали nslookup. И пишем следующее.


    То есть команда telnet и адрес, куда подсоединиться.

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


    Соответственно пишем логин:admin и пароль:cisco (мы создавали его на коммутаторе).

    И он сразу пускает нас на коммутатор. Для проверки проверим доступность компьютера директора, при помощи команды ping.


    Ping успешен. Надеюсь, понятно, что проверка доступности осуществляется не с компьютера рабочего, а с коммутатора. Компьютер здесь является управляющим устройством и все. Рассматривать его в режиме симуляции я не буду. Он работает точно так же, как и почтовые протоколы, то есть создается TCP-сессия, и, после установления соединения, начинает работать Telnet. Как только он отрабатывает, он начинает разрывать соединение. Тут все просто. Привожу ссылку на скачивание.

    Давайте теперь разберем протокол SSH.

    VII) SSH (англ. Secure Shell). В переводе с английского - безопасная оболочка. Как и Telnet позволяет управлять ОС. Отличие его в том, что он шифрует весь трафик и передаваемые пароли. Шифруется при помощи алгоритма Диффи-Хеллмана . Кому интересно почитайте. Практически все современные ОС системы умеют работать с этим протоколом. Если у вас стоит выбор, какой протокол применять, то используйте SSH. Сначала немного помучаетесь в настройке, и многое будет непонятно, но со временем в голове уляжется. Главное запомните сейчас, что самое главное отличие SSH от Telnet - это то, что SSH шифрует трафик, а Telnet нет. Я думаю пора перейти к практике и посмотреть, как это работает. Подключаться и управлять мы будем тем же коммутатором. Давайте попробуем подключиться по SSH с компьютера директора к коммутатору.


    Здесь синтаксис команды немного другой, нежели при подключении по Telnet. Пишем ssh с ключом l, после набираем логин (у нас это admin) и адрес, куда подключаемся (192.168.1.254). Завершаем это дело клавишей ENTER. Выдается сообщение, что соединение было закрыто внешним хостом. То есть коммутатор закрыл соединение. Все потому, что не были созданы ключи, которые работают с шифрованием. Зайду на коммутатор и настрою его для корректной работы по SSH.

    Switch(config)#hostname SW1 - меняем имя коммутатора. С этим стандартным именем нельзя прописать домен, который нужен для генерации ключей.

    SW1(config)#ip domain-name cisadmin.ru - прописываем домен.

    SW1(config)#crypto key generate rsa - генерируем RSA ключи.

    The name for the keys will be: SW1.cisadmin.ru
    Choose the size of the key modulus in the range of 360 to 2048 for your
    General Purpose Keys. Choosing a key modulus greater than 512 may take
    a few minutes.

    How many bits in the modulus : 1024 - Указываем размер ключа. По умолчанию предлагается 512, но я введу 1024.
    % Generating 1024 bit RSA keys, keys will be non-exportable...
    Выходит сообщение о удачной генерации ключей.

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


    И уже выдается другое сообщение, с запросом на ввод пароля. Вводим пароль «cisco» и оказываемся на коммутаторе.

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


    И убедился, что все прекрасно работает. Привожу ссылку , чтобы убедились и вы.

    А я перехожу к следующему протоколу.

    VIII) FTP (англ. File Transfer Protocol). Протокол передачи файлов. Думаю из названия протокола ясно, что он передает файлы. Очень древний протокол, вышедший в начале 70-х годов. Появился он еще до HTTP и стека TCP/IP. Как работал раньше, так и сейчас работает по «клиент-сервер» модели. То есть, присутствует инициатор соединения и тот, кто его слушает. Есть несколько модификаций, которые поддерживают шифрование, туннелирование и так далее. Раньше с этим протоколом работали разные консольные утилиты, у которых не было графики и работали они, при помощи ввода определенных команд. В нынешнее время присутствуют и графические программы. Самой популярной и простой является Filezilla. В CPT реализован только консольный метод.

    Переходим к практике. За основу я возьму предыдущую лабораторку и почтовый сервер заменю FTP-сервером.


    В принципе схема аналогична предыдущей.

    Откроем FTP-сервер и перейдем в сервис FTP.


    По умолчанию служба включена, но лучше проверить.

    1) Цифрой 1 я отметил учетку, которая по умолчанию была здесь создана. Это стандартная учетная запись с логином «cisco» и таким же паролем. В правой колонке видим «Permission» - это права доступа. И видим, что данная учетка имеет все права. В тестовой среде нам как раз это и надо, но, работая в компании, всегда следите за правами каждой учетки.

    2) Цифрой 2 отмечено хранилище FTP. Здесь в основном прошивки для цисковских устройств.

    Сервис настроен и раз все так прекрасно, попробуем с ним поработать. Но для начала создам текстовый файл на компьютере директора, который потом выкачаю на FTP-сервер.

    Открываю компьютер директора и выбираю «Text Editor». Это аналог блокнота в ОС Windows.


    Напишу туда текст и сохраню его.

    Теперь попробуем залить этот файл на FTP-сервер. Открываем командную строку и пишем


    То есть, как помним ранее, в начале пишется используемый протокол, а потом следует адрес. Далее, после соединения, спрашивается логин (вводим cisco) и пароль (тоже cisco). И после аутентификации попадаем на сам FTP-сервер. Список доступных команд можно проверить командой "?".

    Чтобы что-то залить, используется команда «put», а скачать команда «get». Заливаем наш файл.


    Ввел я команду «put» и название файла, которое хочу скопировать. И показывает он нам сообщение, что все скопировано. Файл весит 20 байтов, а скорость передачи 487 байтов в секунду. Далее ввел команду «dir», чтобы проверить содержимое сервера. И засветился на нем файл message.txt под 17 номером.

    Осталось дело за малым. Это скачать файл на компьютер рабочего. Открываю я WORKER-PC и захожу в командную строку.


    Выполняю я практически те же действия, что и ранее. За исключением команды «get», а не «put». Видим, что файл скачен. Еще я ввел команду «dir», чтобы показать, что при скачивании файла, оригинал не удаляется. Скачивается его копия.

    И раз он скачал файл, то он должен появиться на компьютере. Открываю «Text Editor» и нажимаю File->Open.



    Вижу, что файл действительно присутствует и пробую его открыть.


    Файл пришел целым. Весь текст присутствует.

    Не буду повторно засорять вам голову, как это работает. Потому что работает оно точно так же, как и почтовые протоколы, Telnet, SSH и так далее. То есть создается TCP-сессия, и начинается передача/скачивание файла. Приведу только структуру его.


    В TCP обращаем внимание на номер порта. Это 21 порт (стандартный порт FTP). И в поле данных FTP обозначено, что это какие-то двоичные данные.

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

    И последний протокол, который остался - это TFTP.

    IX) TFTP (англ. Trivial File Transfer Protocol). Простой протокол передачи файлов. Придумали его в 80-х годах. Хоть FTP был достаточно популярным, не все его функции были нужны для решения простых задач. И был придуман его простой аналог. Он работает по UDP, то есть не требует установления соединения. Также он не требует аутентификации и авторизации. Достаточно знать его IP-адрес и самому его иметь. Это конечно не безопасно, так как адрес можно подделать. Но когда нужен простой протокол и не требуется авторизация, выбор падает на него. Очень плотно с ним работает цисковское оборудование, для копирования образа или скачивания на flash-память.

    Ничто не учит лучше, чем практика. Поэтому переходим к ней. Чудесным образом я обнаружил, что компьютеры в CPT не умеют работать с TFTP. Хорошо, что с цисковского оборудования не выпилили эту функцию. Поэтому будем учиться на нашем любимом коммутаторе. Схема остается такой же. Просто на FTP-сервере я включу сервис TFTP.


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

    Перейдем к коммутатору.

    SW1#dir - команда вывода содержимого файловой системы
    Directory of flash:/


    9 -rw- 1168 config.text

    64016384 bytes total (59600295 bytes free)

    У нас есть файл config.text. Попробуем его залить на TFTP - сервер.

    SW1#copy flash: tftp: - то есть указываем откуда, а потом куда. Здесь это с flash-памяти на tftp-сервер

    Source filename ? config.text - здесь он спрашивает имя файла, которое надо скопировать.

    указываем куда скопировать.

    Destination filename ? - и тут надо указать, под каким именем сохранить его на сервере. По умолчанию он предлагает сохранить его с тем же названием.И, если нажать клавишу ENTER, он выберет имя по умолчанию. Меня это устраивает, и я оставлю его таким же.

    Writing config.text....!!!

    1168 bytes copied in 3.048 secs (383 bytes/sec)

    И в заключительном сообщении он показывает, что все успешно скопировалось. Перейдем на TFTP-сервер и проверим.


    И вижу, что действительно он там присутствует. Значит коммутатор меня не обманул.

    Теперь попробуем что-нибудь скачать с сервера на коммутатор.

    SW1#copy tftp: flash: - здесь пишем наоборот. Сначала tftp, а потом flash

    Address or name of remote host ? 192.168.1.4 - адрес TFTP-сервера


    Записываю название
    Source filename ? c2960-lanbasek9-mz.150-2.SE4.bin

    Destination filename ? - здесь он спрашивает, как назвать его на самом коммутаторе. Я нажму ENTER и оставлю имя по умолчанию.

    Accessing tftp://192.168.1.4/c2960-lanbasek9-mz.150-2.SE4.bin…
    Loading c2960-lanbasek9-mz.150-2.SE4.bin from 192.168.1.4:!!!

    4670455 bytes copied in 0.057 secs (6587503 bytes/sec)

    Выдал он мне сообщение, что загрузка прошла успешно. Проверю я наличие прошивки командой «dir».

    SW1#dir
    Directory of flash:/

    1 -rw- 4414921 c2960-lanbase-mz.122-25.FX.bin
    10 -rw- 4670455 c2960-lanbasek9-mz.150-2.SE4.bin
    9 -rw- 1168 config.text

    64016384 bytes total (54929840 bytes free)

    Вижу, что действительно все на месте. И вдобавок он мне сообщает об объеме памяти и наличии свободного места.

    Закончили мы рассматривать протоколы верхнего уровня. Не думал я, что получится настолько длинная статья. Наверное виноваты картинки. Но постарался максимально кратко и по делу. Протоколов мы рассмотрели много, и все они не заменимы. Часто выручают жизнь сисадминам и любимым нами пользователям. Спасибо, что дочитали. Если что-то непонятно, оставляйте комментарии или сразу пишите в личку. А я пошел ставить чайник и пить вкусный чай с пирожными!

  • telnet
  • ssh
  • pop3
  • smtp
  • ftp
  • tftp
  • Добавить метки

    Стек протоколов TCP / IP - это набор протоколов, его название происходит от двух наиболее важных протоколов, являющиеся основой связи в сети Интернет . Протокол TCP разбивает передаваемую информацию на порции (пакеты) и нумерует их. С помощью протокола IP все пакеты передаются получателю. Далее с помощью протокола TCP проверяется, все ли пакеты получены. При получении всех порций TCP располагает их в нужном порядке и собирает в единое целое. В сети Интернет используются две версии этого протокола:

    • Маршрутизируемый сетевой протокол IPv4. В протоколе этой версии каждому узлу сети ставится в соответствие IP-адрес длиной 32 бита (т.е. 4 октета или 4 байта).
    • IPv6 позволяет адресовать значительно большее количество узлов, чем IPv4. Протокол Интернета версии 6 использует 128-разрядные адреса, и может определить значительно больше адресов.

    Примечание

    IP-адреса стандарта IPv6 имеют длину 128 бит и поэтому в четыре раза длиннее, чем IP-адреса четвертой версии. IP-адреса версии v6 записываются в следующем виде:X:X:X:X:X:X:X:X, где X является шестнадцатеричным числом, состоящим из 4-х знаков(16 бит), а каждое число имеет размер 4 бит. Каждое число располагается в диапазоне от 0 до F. Вот пример IP-адреса шестой версии: 1080:0:0:0:7:800:300C:427A. В подобной записи незначащие нули можно опускать, поэтому фрагмент адреса: 0800: записывается, как 800:.

    ARP

    Для взаимодействия сетевых устройств друг с другом необходимо, чтобы у передающего устройства был IP - и MAC -адреса получателя. Набор протоколов TCP / IP имеет в своем составе специальный протокол, называемый ARP (Address Resolution Protocol - протокол преобразования адресов), который позволяет автоматически получить MAC - адрес по известным IP -адресам

    DHCP-протокол

    Распределением IP -адресов для подключения к сети Интернет занимаются провайдеры, а в локальных сетях – сисадмины. Назначение IP -адресов узлам сети при большом размере сети представляет для администратора очень утомительную процедуру. Поэтому для автоматизации процесса разработан протокол Dynamic Host Configuration Protocol ( DHCP ) , который освобождает администратора от этих проблем, автоматизируя процесс назначения IP -адресов всем узлам сети.

    HTTP протокол

    HTTP протокол служит для передачи гипертекста, т.е. для пересылки Web-страниц с одного компьютера на другой. Основой HTTP является технология "клиент- сервер ", то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос , и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом.

    FTP протокол

    FTP протокол передачи файлов со специального файлового сервера на компьютер пользователя. Установив связь с удаленным компьютером, пользователь может скопировать файл с удаленного компьютера на свой или скопировать файл со своего компьютера на удаленный.

    POP протокол

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

    SMTP протокол

    SMTP -протокол, который задает набор правил для отправки почты. Сервер SMTP возвращает либо подтверждение о приеме, либо сообщение об ошибке , либо запрашивает дополнительную информацию.

    IP адрес по протоколу IPv4

    Одной из самых важных тем при рассмотрении TCP / IP является адресация IP . Адрес IP - числовой идентификатор , приписанный каждому компьютеру в сети IP и обозначающий местонахождение в сети устройства, которому он приписан. Адрес IP - это адрес программного, а не аппаратного обеспечения. IP - адрес узла идентифицирует точку доступа модуля IP к сетевому интерфейсу, а не всю машину.

    IP - адрес - сетевой (программный) адрес узла в компьютерной сети, построенной по протоколу IP .

    Каждый из 4х октет десятичной записи IP адреса может принимать значение в диапазоне от 0 до 255 и в теории такой адрес в десятичной форме записи может быть в диапазоне от 0.0.0.0 до 255.255.255.255. IP адрес - двоичное число, но для человека вместо записи в 32

    Глава 5

    Протоколы локальных сетей

    По прочтении этой главы и после выполнения практических заданий вы сможете:

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

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

    В начале XX века социолог Георг Герберт Мид (George Herbert Mead), изучая влияние языка на людей, пришел к выводу о том, что человеческий интеллект в первую очередь развился благодаря языку. Язык помогает нам находить смысл в окружающей реальности и истолковывать ее детали. В сетях аналогичную роль выполняют сетевые протоколы, которые позволяют разнообразным системам находить общую среду для взаимодействия.

    В этой главе описываются протоколы, чаще всего используемые в локальных сетях, а также сетевые операционные системы, в которых они применяются. Вы узнаете о преимуществах и недостатках каждого протокола, благодаря чему вам станут понятны области их использования. Самый популярный протокол локальных сетей – TCP/IP – рассматривается в этой главе лишь кратко, поскольку подробнее он будет описан в главе 6. В заключении текущей главы вы познакомитесь с методами повышения производительности локальных сетей и выбора тех протоколов, которые необходимы в конкретной ситуации.

    Протоколы локальных сетей и их применение в сетевых операционных системах

    Сетевые протоколы напоминают местный язык или диалект: они обеспечивают в сетях беспрепятственный обмен информацией между подключенными устройствами. Эти протоколы имеют значение и для простых электрических сигналов, передаваемых по сетевому коммуникационному кабелю. Я протоколов сетевые коммуникации были бы просто невозможны. Для та чтобы два компьютера могли свободно общаться друг с другом, они должны использовать один и тот же протокол подобно тому, как два человека вынуждены общаться на одном языке. I

    В локальной сети несколько протоколов могут работать индивидуально и в некоторых сочетаниях. Сетевые устройства (например, маршрутизаторы) часто настраиваются на автоматическое распознавание и конфигурирование различных протоколов (в зависимости от операционной системы, используемой в маршрутизаторе). Например, в одной локальной сети Ethernet один протокол может использоваться для подключения к мэйнфрейму, другой для работы с серверами Novell NetWare, а третий – для серверов Windows (например, под управлением системы Windows NT Server) (рис. 5.1).

    Можно установить мост-маршрутизатор, который будет автоматически распознавать каждый протокол и конфигурироваться соответствующим образом, в результате чего для одних протоколов он будет выступать в роли маршрутизатора, а для других – в роли моста. Наличие нескольких протоколов в сети эффективно тем, что такая сеть сможет одновременно выполнять множество функций (например, обеспечивать доступ к Интернета также к мэйнфреймам и серверам). Недостатком такого подхода является что некоторые протоколы будут работать в режиме широковещания, то есть, будут периодически посылать пакеты для идентификации сетевых устройств, генерируя значительный избыточный трафик.

    Некоторые сетевые протоколы получили широкое распространение благодаря тому, что они связаны с конкретными сетевыми операционными системами (например, с Windows-системами, мэйнфреймами IBM, сервера UNIX и Novell NetWare). Имеет смысл изучать протоколы применительно тем операционным системам, где они применяются. В этом случае становится понятным, для чего конкретный протокол нужен в сети определенного типа. Кроме того, в этом случае вам легче будет понять, как один протокол (например, NetBEUI) можно заменить другими протоколами (такими как TCP/IP). Однако перед тем как изучать протоколы и их взаимосвязь операционными системами, важно узнать об общих свойствах протокол локальных сетей.

    Общие свойства протоколов локальной сети

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

    Протоколы локальных сетей должны иметь следующие основные характеристики:

    Обеспечивать надежность сетевых каналов;

    Обладать высоким быстродействием;

    Обрабатывать исходные и целевые адреса узлов;

    Соответствовать сетевым стандартам, в особенности – стандарту IEEE 802.

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

    В табл. 5.1 перечислены протоколы локальных сетей и операционные системы, с которыми эти протоколы могут работать. Далее в главе указаны протоколы и системы (в частности, операционные системы серверов и хост компьютеров) будут описаны подробнее.

    4 Таблица 5.1. Протоколы локальных сетей и сетевые операционные системы

    Протокол

    Соответствующая операционная система

    Первые версии операционных систем Microsoft Windows

    UNIX, Novel NetWare, современные версии операционных систем Microsoft Windows, операционные системы мэйнфреймов IBM

    Операционные системы мэйнфреймов и миникомпьютеров IBM

    Клиентские системы, взаимодействующие с мэйнфреймами IBM, настроенными на работу с протоколом SNA

    Примечание

    Компьютерная операционная система – это совокупность программных средств, выполняющих на компьютере две функции. Во-первых, они взаимодействуют с аппаратными средствами компьютера и базовой системой ввода/вывода (Basic input/output system, BIOS). Во-вторых, они взаимодействуют с пользовательским интерфейсом (например, с графическим пользовательским интерфейсом (GUI) системах Windows или с подсистемой X Window и рабочими столами в систем UNIX). Для сетевых компьютерных операционных систем имеется еще третий уровень взаимодействия, на котором эти системы могут общаться между собой по сети с помощью одного или нескольких протоколов.

    Протоколы IPX / SPX и система Novell NetWare

    Протокол Internetwork Packet Exchange (IPX ) (межсетевой пакетный обмен) был разработан компанией Novell для одной из самых первых сетевых операционных систем, выполняющей серверные функции и названной NetWare. Первоначально эта система предназначалась для сетей Ethernet с шинной топологией, сетей с маркерным кольцом и сетей ARCnet, она была ориентирована на работу с одним файл-сервером. ARCnet – это одна из частных альтернативных сетевых технологий, в которой используются специальные пакеты с маркерами и смешанная топология (шина и звезда). В настоящее время операционная система NetWare стала аппаратно-независимой и может поддерживать различные топологии и протоколы.

    В качестве прототипа протокола IPX компания Novell использовала один из первых протоколов локальных сетей – протокол Xerox Network System (XNS ), адаптировав его для своей файл-серверной операционной системы NetWare. Компания Xerox Corporation предложила протокол XNS в качестве средства передачи данных по сетям Ethernet. В начале 1980-х годов некоторые производители выпустили собственные версии этого протокола. Вариант компании Novell определил возникновение протокола IPX, предназначенного для серверов NetWare. Одновременно эта компания разработала сопутствующий протокол, названный Sequenced Packet Exchange (SPX ) и ориентированный на работу с прикладными программами, например, с базами данных .

    Протоколы IPX/SPX широко используются в серверах NetWare до 4-й версии включительно. Начиная с версии NetWare 5.0, компания Novell предлагает пользователям переходить на стек протоколов TCP/IP. В настоящее время именно эти протоколы являются основными для версий NetWare 6.0 и выше, при этом пользователи могут по-прежнему применять протоколы IPX/SPX, в частности, для совместимости с устаревшими серверами и оборудованием (например, с принтерами).

    Когда в сети Ethernet на основе серверов NetWare конфигурируются протоколы IPX/SPX, можно использовать фреймы Ethernet четырех типов:

    o 802 .2 – относительно новый тип фреймов, применяемый в сетях, базирующихся на серверах NetWare версий с 3.21 по 4.x;

    o 802.3 – старый тип фреймов, применяемый в системах NetWare 286 (версий 2.x) и первых версиях системы NetWare и 3.1х);

    o Ethernet II для обеспечения совместимости с сетями Ethernet II и более эффективного форматирования фреймов;

    o Ethernet SNAP реализация описанного в главе 2 протокола SubNetwork Access Protocol (SNAP), предназначенного для работы специальных сл)Я и приложений фирм-изготовителей.

    Достоинства и недостатки

    Достоинством протокола IPX (несмотря на его солидный возраст) по сравнению с другими ранними протоколами является возможность его маршрутизации, т. е. то, что с его помощью можно передавать данные по многим подсетям внутри предприятия. Недостатком протокола является дополнительный трафик, возникающий из-за того, что активные рабочие станции используют часто генерируемые широковещательные пакеты для подтверждения своего присутствия в сети. При наличии множества серверов NetWare и нескольких сотен клиентов применяемые протоколом IPX широковещательные пакеты типа "я здесь" могут создавать значительный сетевой трафик (рис. 5.2).

    Назначение протокола SPX

    Протокол SPX, дополняющий IPX, обеспечивает передачу данных прикладных программ с большей надежностью, чем IPX. Протокол IPX работает несколько быстрее своего "компаньона", однако в нем используются службы без установления соединения, работающие на подуровне LLC Канального уровня. Это означает, что IPX гарантирует доставку фрейма в пункт назначения с меньшей вероятностью. В протоколе SPX применяются службы с установлением соединения, что повышает надежность передачи данных. Чаще всего при упоминаниях обоих протоколов (IPX и SPX) используют сокращение IPX/SPX.

    Протокол SPX широко применяется для передачи по сети содержимого Я данных. Кроме того, на основе этого протокола работают утилита удаленной консоли и службы печати фирмы Novell. Удаленная консоль позволяет рабочей станции администратора видеть ту же информацию, которая отображается на консоли файл-сервера NetWare, благодаря чему пользователь может удаленно выполнять системные команды сервера, не находясь за его клавиатурой.

    Развертывание протоколов IPX / SPX

    Для установки протоколов IPX/SPX на компьютерах с системой DOS используются специальные DOS-драйверы, разработанные для NetWare. На 32-разрядных операционных системах (например, Windows 95 и старших версия), ля установки протоколов можно запустить программу Novell Client32, которая обеспечит командную среду для доступа к серверам NetWare.

    Для того чтобы компьютеры под управлением Windows-систем могли обращаться к NetWare, можно также использовать два типа драйверов, позволяющих работать с несколькими протоколами: Open Datalink Interface (ODI) и Network Driver Interface Specification (NDIS).

    Когда в сети NetWare развернуты несколько протоколов (например, IPX/SPX и TCP/IP), серверы и клиенты зачастую используют драйвер Open Datalink Interface , ODI (открытый канальный интерфейс). Этот драйвер обеспечивает обмен данными с файл-серверами NetWare, мэйнфреймами и Мини-компьютерами, а также с Интернетом. ODI-драйверы можно применять в сетевых клиентах, работающих в среде MS-DOS и Microsoft Windows.

    В ранних версиях Windows (Windows 3.11, Windows 95, Windows 98 и Windows NT) компания Microsoft реализовала GDI-драйвер как 1б-разрядное приложение, которое не могло в полной мере использовать быстродействие и возможности 32-разрядной системы Windows 95 и более поздних версий.

    Начиная с Windows 95, для подключения к серверам NetWare по протоколу IPX/SPX применяются более совершенные решения компании Microsoft – протокол NetWare Link (NWLink ) IPX / SPX и драйвер Network Driver Interface Specification , NDIS (спецификация стандартного интерфейса сетевых адаптеров). В практических заданиях 5-1 и 5-2 рассказывается о том, как настроить системы Windows 2000 и Windows XP Professional для работы с протоколом NWLink.

    Как показано на рис. 5.3, драйверы NDIS (Microsoft) и ODI (Novell) работает на подуровне LLC Канального уровня, однако в отдельный момент времени к сетевому адаптеру может быть привязан только один из этих драйверов.

    DIV_ADBLOCK20">

    Эмуляция IPX / SPX

    Протокол NWLink эмулирует работу IPX/SPX, поэтому любая использующая его система Windows работает как компьютер или устройство, настроенное на работу с IPX/SPX. NDIS – это спецификация программного драйвера, используемая протоколом NWLink и позволяющая ему и другим сетевым протоколам взаимодействовать с сетевым адаптером компьютера. При этом используется процедура установления связи между протоколом и адаптером, называемая привязкой. Привязка (binding) некоторого протокола к определенному адаптеру позволяет этому адаптеру работать и обеспечивать интерфейс с сетевой средой.

    Привязка к драйверу NDIS

    Драйвер NDIS компании Microsoft может привязывать к одному сетевому адаптеру один или несколько протоколов, благодаря чему все эти протоколы смогут работать через данный адаптер. Если протоколов несколько, то между ними устанавливается определенная иерархия, и если в сети развернуто несколько протоколов, то сетевой адаптер в первую очередь попытается прочитать фрейм или пакет, используя протокол, находящийся на верхней ступени этот иерархии. Если форматирование фрейма или пакета соответствует другому протоколу, то адаптер попробует прочитать его с помощью следующего протокола, указанного в иерархии, и т. д.

    Совет

    С помощью драйвера NDIS один протокол можно привязать к нескольким сетевым адаптерам компьютера (например, в сервере). При наличии нескольких адаптеров можно распределить между ними сетевую нагрузку и ускорить реакцию сервера на запросы при большом количестве пользователей. Кроме того, несколько адаптеров используются в том случае, если сервер также выполняет функции маршрутизатора. Привязка одного протокола к нескольким адаптерам позволяет также снизить объем занимаемой памяти, поскольку серверу не понадобится загружать в нее несколько экземпляров одного протокола.

    Нужно заметить, что пользователь может сам организовывать иерархию протоколов, привязанных к адаптеру. Эта иерархия называется порядком привязки. Например, если первым в иерархии указан протокол IPX/SPX, а вторым – TCP/IP, то фрейм или пакет TCP/IP сначала интерпретируется как данные в формате IPX/SPX. Сетевой адаптер быстро определяет ошибку и повторно читает фрейм или пакет в формате TCP/IP, распознавая его правильно.

    Порядок привязки протоколов можно задавать в большинстве операционных систем Microsoft Windows (например, в Windows 2000 и Windows ХР). На рис. 5.4 изображен порядок привязки на компьютере, работающем под управлением Windows XP Professional. На этом рисунке протоколы, перечисления ниже строки File and Printer Sharing for Microsoft Networks , отображают nil док привязки протоколов, используемых для доступа к общим файлам и принтерам. Под строкой Client for Microsoft Networks показан порядок привязки протоколов, необходимых для доступа к сетевым серверам. В практических заданиях 5-3 и 5-4 вы узнаете о том, как установить порядок привязки протоколов в системах Windows 2000 и Windows XP Professional.

    DIV_ADBLOCK22">

    Примечание

    Как уже говорилось ранее в этой книге, не рекомендуется включать протокол RIP на серверах NetWare и Windows 2000/Server 2003, поскольку он создает в сети дополнительный трафик. Предпочтительнее, чтобы все задачи по маршрутизации выполняли специализированные сетевые маршрутизаторы.

    Таблица 5.2. Протоколы, используемые вместе с серверами NetWare

    Аббре виатура

    Полное название

    Описание

    Уровень модели OSI

    Internetwork Packet Exchange

    Используется как основной протокол передачи данных для приложений Ethernet. Можно применять любые типы фреймов: Ethernet 802.2, Ethernet 802.3, Ethernet II и Ethernet SNAP

    Сетевой и Транспортный

    Link Support Layer

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

    Канальный

    Multiple Link Interface Driver

    Соединяет два или несколько каналов в одну телекоммуникационную линию (например, два терминальных адаптера ISDN). В сетях Ethernet протокол MLID в сочетании с сетевым адаптером рабочей станции позволяет определить уровень конфликтов в сети, в сетях с маркерным кольцом он координирует передачи маркера

    Канальный (подуровень MAC)

    NetWare Core Protocol

    Часть операционной системы, обеспечивает обмен данными между клиентами и серверами при обращении к приложениям или открытым файлам, находящимся на сервере NetWare

    NetWare Link Services Protocol

    Обеспечивает пакеты IPX информацией о маршрутизации

    Routing Information Protocol

    Собирает информацию о маршрутизации для серверов, которые обеспечивают работу служб маршрутизации

    Service Advertising Protocol

    Позволяет клиентам NetWare идентифицировать серверы и сетевые службы, имеющиеся на них. Серверы генерируют широковещательные пакеты SAP каждые 60 с, а клиенты используют их для обнаружения ближайшего сервера

    Сеансовый Представительский Прикладной

    Sequenced Packet Exchange

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

    Транспортный

    Протокол NetBEUI и серверы Microsoft Windows

    Система Microsoft Windows NT начиналась как совместный проект компаний Microsoft и IBM по развитию серверной операционной системы LAN Manager. В начале 1990-х годов компания Microsoft перешла от LAN Manager к системе Windows NT Server, которая впоследствии стала широко распространенной операционной системой.

    На основе продукта Windows NT Server были созданы системы Windows 2000 Server и Windows Server 2003. Как и современные версии Novell NetWare системы Windows NT, Windows 2000 и Windows Server 2003 совместимы локальными сетями Ethernet и Token Ring, они могут масштабироваться от небольших компьютеров с Intel-совместимыми процессорами до многопроцессорных систем. Чаще всего с указанными системами используются протоколы TCP/IP, однако до сих пор имеются системы Windows NT Server версий 3.51 и 4.0, в которых реализован родной протокол систем Windows NT – NetBIOS Extended User Interface , NetBEUI . Этот протокол был создан для операционных систем LAN Manager и LAN Server до того, как появилась Windows BEUI был реализован в первых версиях Windows NT до сих пор имеется в системе Windows 2000 (хотя больше и не поддерживается в системах Microsoft, начиная с Windows ХР).

    Примечание

    На компьютерах под управлением Windows NT и Windows 2000 протокол NetBEUI также встречается под именем NBF (NetBEUI frame – фрейм NetBEUI). Если для анализа сетевого трафика использовать анализатор протоколов, то фреймы NetBEUI будут отмечены именно такой аббревиатурой .

    История NetBEUI

    Протокол NetBEUI первоначально был разработан компанией IBM в 1985 году как улучшенная модификация Network Basic Input / Output System , NetBIOS (базовая сетевая система ввода/вывода). NetBIOS – это не протокол, а метод взаимодействия прикладных программ с сетевыми устройствами, а также службы распознавания имен, используемых в сетях BIOS-имена даются различным объектам сети (таким как рабочие станции, серверы или принтеры). Например, имя пользователя может служить для идентификации его рабочей станции в сети, по имени HPLaser может осуществляться доступ к сетевому принтеру, а сервер может иметь имя AccountServer. Подобные имена облегчают поиск нужных сетевых ресурсов. Они транслируются (преобразуются) в адреса, используемые в сетевых коммуникациях, с помощью NetBIOS-служб Name Query.

    Область применения NetBEUI

    Протокол NetBEUI разрабатывался в то время, когда компьютерные сети в первую очередь означали локальные сети для относительно небольшого количества компьютеров (от нескольких до двух сотен). В процессе проектирования не учитывались особенности корпоративных сетей с маршрутизацией пакетов. По этой причине протокол NetBEUI нельзя маршрутизировать и лучше всего его применять в небольших локальных сетях под управлением относительно старых операционных систем компаний Microsoft и IBM:

    · Microsoft Windows 3.1 или 3.11;

    · Microsoft Windows 95;

    · Microsoft Windows 98;

    · Microsoft LAN Manager;

    · Microsoft LAN Manager for UNIX;

    · Microsoft Windows NT 3.51 или 4.0

    · IBM LAN Server.

    При переводе сети с Windows NT Server на Windows 2000 или Windows Server 2003 в первую очередь настройте серверы и рабочие станции, использующие NetBEUI, на работу с TCP/IP. Хотя системы Windows 2000 и поддерживают NetBEUI, компания Microsoft не рекомендует применять этот протокол более поздних операционных системах. Однако в том случае, если сеть небольшая (менее 50 клиентов) и не требуется доступ к Интернету, то протокол NetBEUI может оказаться более эффективным, чем TCP/IP.

    NetBEUI и эталонная модель OSI

    Протокол NetBEUI соответствует нескольким уровням модели OSI. Для взаимодействия сетевых интерфейсов используются Физический и Канальный уровни. В пределах Канального уровня для управления передачей кодирования и адресации фреймов задействуются подуровни LLC (Logical Link Control) и MAC (Media Access Control). Также протокол реализует функции, относящиеся к Транспортному и Сеансовому уровням (обеспечение надежности передачи, подтверждение приема пакетов, установка и завершения сеансов).

    Почему NetBEUI хорошо работает в сетях Microsoft

    Для ответа на вопрос, вынесенный в заголовок раздела, имеется несколько причин. Во-первых, протокол NetBEUI прост в установке, поскольку его не нужно конфигурировать как другие протоколы (например, для TCP/IP нужно указать адрес, а для IPX/SPX следует выбрать тип фрейма). Во-вторых протокол позволяет одновременно поддерживать в сети большое количество сеансов обмена информацией (до 254 в ранних версиях протокола, в предыдущих версиях это ограничение снято). Например, в соответствии со спецификациями Microsoft сервер Windows NT может обеспечивать работу 1000 сеансов на один сетевой адаптер (для серверов Windows 2000 такие проверки проводились). В-третьих, протокол NetBEUI расходует мало оперативной памяти и имеет высокое быстродействие в небольших сетях. В-четвертых в нем реализованы надежные механизмы обнаружения и устранения ошибок.

    Недостатки NetBEUI

    Невозможность маршрутизации является главным недостатком протокола NetBEUI в средних и крупных сетях, включая корпоративные сети. Маршрутизаторы не могут перенаправить пакет NetBEUI из одной сети другую, поскольку фрейм NetBEUI не содержит информации, указующие на конкретные подсети. Еще одним недостатком протокола является то, что для него имеется мало сетевых анализаторов (помимо тех инструментов, которые выпустила Microsoft).

    Примечание

    В практическом задании 5-5 рассказывается о том, как установить протокол NetBEUI на компьютере под управлением Windows 2000.

    Протокол AppleTalk и система Mac OS

    Компания Apple разработала семейство протоколов AppleTalk для организации сетей на базе компьютеров Macintosh, работающих под управлением операционной системы Mac OS. AppleTalk – это одноранговый сетевой протокол, т. е. он предназначен для обмена данными между рабочими станциями Macintosh даже при отсутствии сервера. Этот факт иллюстрируется на рис. 5.5, где показано, как для связи компьютеров Macintosh используется коммутатор. С протоколом AppleTalk могут работать операционные системы Novell NetWare, MS-DOS, Microsoft Windows 9 x / ME и Windows NT/2000/XP. Первая версия протокола называлась AppleTalk Phase I, она была выпущена в 1983 году. В 1989 году была разработана используемая до сих пор версия AppleTalk Phase II, которая позволяет работать большому количеству сетевых компьютеров и обеспечивает взаимодействие с большими гетерогенными сетями на основе нескольких протоколов.

    DIV_ADBLOCK27">

    Максимальное количество станций в сети AppleTalk Phase I равно 254, а для сети AppleTalk Phase II этот параметр равен нескольким миллионам. Адресация в сетях первого типа осуществляется с применением идентификации узла (node identification, ID), а в сетях второго типа при адресации исполняется как идентификатор узла, так и идентификатор сети. И последним отличием является то, что протокол AppleTalk Phase I может работать только в таких сетях, где других протоколов нет. Протокол AppleTalk Phase II функционирует в сетях со многими протоколами (например, IPX/SPX и ТСP/IP).

    Примечание

    Хотя протокол AppleTalk был разработан как одноранговый, он может применяться для обмена данными между серверами Mac OS X и Windows-системами настроенными на работу по этому протоколу.

    Службы AppleTalk

    В состав протокола AppleTalk входят три базовые службы:

    · удаленный доступ к сетевым файлам с использованием программ средств AppleShare File Server (в сочетании с протоколом AppleTalk Filing Protocol);

    · службы печати на основе программных средств AppleShare Print Server (которые используют протоколы Name Binding Protocol и Printer Access Protocol);

    · файловые службы на базе программ AppleShare PC для DOS - и Windows систем.

    AppleTalk и эталонная модель OSI

    В стеке AppleTalk исходным протоколом нижнего уровня (согласно модели OSI) является протокол LocalTalk Link Access Protocol , LLAP , работающий на физическом и Канальном уровнях и обеспечивающий устаревший метод доступа при передаче данных. При этом используются физические сетевые интерфейсы, разработанные для протокола LocalTalk, который может работать в небольших, медленных сетях при максимальном количестве станций в сети, равном 32 (для 300-метрового сегмента с шинной топологией). Допустимая скорость равна 230,4 Кбит/с, что чрезвычайно мало для современных сетевых технологий.

    Для назначения адресов в сети LocalTalk используется процесс, называемый состязанием. После включения питания компьютер Macintosh "соревнуется" с другими компьютерами за свой адрес, в результате чего он получает уникальный идентификатор узла (ID). При последующих включениях питания компьютер может получить другой адрес.

    Методы доступа AppleTalk

    В современных сетях AppleTalk Phase II применяются методы доступа Ethernet или маркерное кольцо, при этом могут использоваться интерфейсы, подходящие для любых других устройств Ethernet или Token Ring. Для упрощения Ethernet-коммуникацией в стеке AppleTalk имеется протокол EtherTalk Link Access Protocol , FLAP , функционирующий на Физическом и Канальном уровнях. С его помощью в сетях AppleTalk с шинной или смешанной топологией реализуется метод доступа CSMA/CD (см. главу 2). В сетях с маркерным кольцом используется протокол Token Talk Link Access Pro tocol , TLAP , также работающий на Физическом и Канальном уровнях. При этом используется передача маркера и кольцевая/звездообразная топология (как и в любой другой сети с маркерным кольцом).

    Сетевая адресация AppleTalk

    Адресация в сетях AppleTalk, использующих протокол ELAP и TLAP, осуществляется с помощью протокола AppleTalk Address Resolution Protocol , AARP , который позволяет распознавать физические или МАС-адреса сетевых адаптеров, благодаря чему эти адреса можно вставлять во фреймы AppleTalk. (Если компьютер Macintosh настроен на работу с AppleTalk и IP, протокол AARP используется для распознавания физических и IP-адресов.)

    Протоколы, входящие в стек AppleTalk

    Помимо LLAP, ELAP, TLAP и AARP, имеются и другие протоколы, входящие в семейство AppleTalk. Все они перечислены в табл. 5.3.

    Таблица 5.3. Протоколы, входящие в стек Apple

    Аббре виатура

    Полное название

    Описание

    Уровень модели OSI

    AppleTalk Address Resolution Protocol

    Используется для распознавания физических (MAC) адресов в сетях Ethernet и Token Ring. Если помимо AppleTalk применяется протокол IP, то AARP выполняет разрешение компьютерных и доменных имен в IP-адреса

    Канальный и Сетевой

    AppleTalk Data Stream Protocol

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

    Сеансовый

    AppleTalk Filing Protocol

    Позволяет рабочим станциям и серверам взаимодействовать друг с другом на Прикладном уровне

    Представительский

    AppleTalk Session Protocol

    Инициирует, поддерживает и закрывает соединения между станциями. Определяет порядок передачи фрагментов данных для надежной доставки принимающему узлу

    Сеансовый

    AppleTalk Transaction Protocol

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

    Транспортный

    Datagram Delivery Protocol

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

    EtherTalk Link Access Protocol

    Обеспечивает Ethernet-коммуникации с применением метода доступа CSMA/CD в шинных или смешанных топологиях

    Физический и Канальный

    LocalTalk Link Access Protocol

    Устаревший метод доступа, управляющий коммуникациями на Физическом (через интерфейсы и кабели) и Канальном уровнях в определенных ситуациях (например, когда для обеспечения адресации возникают состязания за получение уникального ID)

    Физический и Канальный

    Name Binding Protocol

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

    Транспортный

    Printer Access Protocol

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

    Сеансовый

    Routing Table Maintenance Protocol

    Используется для получения информации о сетевой маршрутизации при обновлении таблиц маршрутизации

    TokenTalk Link Access Protocol

    Обеспечивает работу маркерных сетей с кольцевой/звездообразной топологией

    Физический и Канальный

    Zone Information Protocol

    Поддерживает таблицу зон, на которые делятся сети AppleTalk и соответствующие им таблицы маршрутизации

    Сеансовый

    Совместимость AppleTalk с системами Mac OS X, Windows 2000 и Netware

    Родной серверной платформой для компьютеров Macintosh является продукт Mac OS X Server, созданный на базе операционной системы Mac OS X. С его помощью можно реализовать общий доступ к файлам и принтерам, управление сетевыми пользователями и группами, а также обеспечить работу веб-служб. Системы Mac OS X и Mac OS X Server поддерживают и AppleTalk, и TCP/IP.

    Сервер NetWare или Windows 2000 можно использовать в качестве сервера Для компьютеров Macintosh при наличии протокола AppleTalk Phase II. Например, для того, чтобы сервер Windows 2000 можно было установить в компьютерной сети Macintosh, на него следует поставить следующие компоненты:

    · AppleTalk Phase II;

    · File Services for Macintosh;

    · Print Services for Macintosh.

    После установки протокола AppleTalk система Windows 2000 Server сможет взаимодействовать с компьютерами Macintosh, настроенными на работу с AppleTalk Phase II. Наличие служб File Services for Macintosh позволяет выделить на сервере Windows 2000 дисковое пространство, на котором компьютеры Macintosh смогут хранить файлы, используя для доступа протокол AppleTalk. Службы Print Services for Macintosh позволяют компьютерам Macintosh обращаться к сетевым принтерам, работу которых обеспечим сервер Windows 2000.

    Практическое задание 5-6 познакомит вас с тем, как в системе Windows 2000 Server установить протокол AppleTalk Phase II, а также службы File Services for Macintosh и Print Services for Macintosh.

    Примечание

    Операционные системы Mac OS X и Mac OS X Server реализованы на ядре UNIX и даже имеют режим окна терминала, в котором можно выполнять многочисленные команды UNIX.

    Протокол TCP/IP и различные серверные системы

    Transmission Control Protocol / Internet Protocol , TCP / IP (Протокол управления передачей/Протокол Интернета) – самый распространенный в настоящее время стек протоколов, являющийся к тому же протоколом Интернета. В этом разделе дается лишь краткий обзор TCP/IP в контексте общего знакомства с важнейшими протоколами. Более подробно стек TCP/IP рассматривается в главе 6.

    Большинство операционных систем сетевых серверов и рабочих станций поддерживает TCP/IP, в том числе серверы NetWare, все системы Windows, UNIX, последние версии Mac OS, системы OpenMVS и z/OS компании IBM, а также OpenVMS компании DEC. Кроме того, производители сетевого оборудования создают собственное системное программное обеспечение для TCP/IP, включая средства повышения производительности устройств. Стек TCP/IP изначально применялся на UNIX-системах, а затем быстро распространился на многие другие типы сетей.

    Достоинства TCP/IP

    Среди многих достоинств стека TCP/IP можно упомянуть следующие:

    · он применяется во многих сетях и в Интернете, что делает его международным языком сетевых коммуникаций;

    · имеется множество сетевых устройств, предназначенных для работы с этим протоколом;

    · многие современные компьютерные операционные системы используют TCP/IP в качестве основного протокола;

    · для этого протокола существует много диагностических средств и анализаторов;

    · многие специалисты по сетям знакомы с протоколом и умеют его использовать.

    Протоколы и приложения, входящие в стек TCP/IP

    В табл. 5.4 перечислены протоколы и приложения, входящие в стек TCP/IP. О некоторых из них уже рассказывалось ранее. Более подробное описание имеется в главе б, а также и в последующих главах.

    Таблица 5.4. Протоколы и приложения, входящие в стек протоколов TCP/IP

    Аббревиатура

    Полное название

    Описание

    Уровень модели OSI

    Address Resolution Protocol

    Обеспечивает разрешение IP-адресов в МАС-адреса

    Канальный и Сетевой

    Domain Name System (приложение)

    Поддерживает таблицы, связывающие IP-адреса компьютеров с их именами

    Транспортный

    File Transfer Protocol

    Используется для передачи и приема файлов

    Сеансовый, Представительский и Прикладной

    Hypertext Transfer Protocol

    Используется для передачи данных в сети World Wide Web

    Представительский

    Internet Control Message Protocol

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

    Internet Protocol

    Управляет логической адресацией

    Network File System (приложение)

    Используется для передачи файлов по сети (предназначается для компьютеров UNIX)

    Сеансовый, Представительский и Прикладной

    Open Shortest Path First (протокол)

    Используется маршрутизаторами для обмена информацией (данными по маршрутизации)

    Point-to-Point protocol

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

    Routing Information Protocol

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

    Remote Procedure Call (приложение)

    Позволяет удаленному компьютеру выполнять процедуры на другом компьютере (например, на сервере)

    Сеансовый

    Serial Line Internet Protocol

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

    Simple Mail Transfer Protocol

    Используется для передачи электронной почты

    Представительский

    Transmission Control Protocol

    Протокол, ориентированный на установление соединений, что повышает надежность передачи данных

    Транспортный

    Telecommunications Network (приложение)

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

    Сеансовый, Представительский и Прикладной

    User Data Protocol

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

    Транспортный

    Протокол SNA и операционные системы IBM

    В устаревших мэйнфреймах IBM обычно используются протоколы стека Systems Network Architecture , SNA , который был изначально разработан в 1974 году. Фактически SNA – это набор частных протоколов, в которых в качестве метода доступа используется маркерное кольцо. Многие детали маркерных сетей, созданных компанией IBM, впоследствии были включены в стандарт IEEE 802.5. Однако в сети SNA кабельный участок обязательно строится на базе экранированной витой пары (STP), причем кабели имеют строго ориентированную маркировку (и разводку) (например, определенный конец кабеля должен идти к мэйнфрейму, а другой – к устройствам, подключенным к мэйнфрейму, таким как контроллеры дисковых накопителей или коммуникационных каналов). Это означает, что в сети SNA также используются частные (фирменные) кабельные разъемы и сетевые интерфейсы,

    Стек протоколов SNA и эталонная модель OSI

    Стек протоколов SNA базируется на семиуровневой модели (табл. 5.5), напоминающей эталонную модель OSI.

    Таблица 5.5. Семиуровневая модель SNA

    Уровень SNA

    Эквивалентный уровень OSI

    Назначение

    Службы транзакций (Transaction Services)

    Прикладной

    Самый высокий уровень, управляет службами, от которых зависит работа прикладных программ (например, распределенных баз данных и приложений, выполняющихся одновременно на нескольких мэйнфреймах)

    Представитель-ские службы (Presentation Services)

    Представитель-ский

    Управляет форматированием и преобразованием данных (например, перекодировкой из ASCII в EBCDIC и наоборот), также выполняет сжатие данных (хотя, в отличие от Представительского уровня OSI, этот уровень не обеспечивает шифрование данных)

    Управление потоком данных (Data Flow Control)

    Сеансовый

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

    Управление (Transmission Control)

    Транспортный

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

    Управление маршрутом (Path Control)

    Управляет маршрутизацией и созданием виртуальных каналов, фрагментирует сообщения на блоки меньших размеров при передаче данных через разнородные сети (эту задачу выполняет Транспортный уровень OSI)

    Управление(Data Link Control)

    Канальный каналом

    Форматирует данные на фреймы, обеспечивает маркерный доступ к сети при одноуровневых обменах данными между компьютерами

    Управление Физическим Устройством

    (Physical Control)

    Физический

    Обеспечивает генерирование и кодирование электрических сигналов, работу физических интерфейсов, топологию сети и коммуникационную среду (например, кабель)

    Достоинства и недостатки SNA

    Аналогично любому стеку протоколов, SNA имеет как достоинства, так и недостатки. Отмечая достоинства, следует сказать, что архитектура SNA существует уже более четверти века и обеспечивает надежные и проверенные средства обмена данными с системами IBM. Существенным недостатком является то, что SNA – это частный (фирменный) стек протоколов, для которого нужны специальные устройства и дополнительное обучение процедурам конфигурирования, управления и отладки. По этим причинам сети SNA с мэйнфреймами IBM обычно работают очень хорошо, но это требует больших затрат на обучение персонала и поддержку сети.

    Физические элементы сети SNA

    В традиционной сети SNA с компьютерами IBM терминалы рассматривав как физические модули типа 2 (type 2). Физический модуль – это некоторое устройство, которое может подключаться к мэйнфрейму или управлять доступом к нему.

    624 " style="width:467.8pt;border-collapse:collapse;border:none">

    Аббревиа - тура или название

    Полное название

    Описание

    Уровень модели SNA

    Advanced Peer-to-Peer Networking (улучшенный протокол одноранговых сетей)

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

    Управление передачей

    Customer Information Control System (абонентская информационно управляющая система)

    Управление потоком данных и Предста-вительские службы

    Distributed Data Management (управление распределен-ными данными)

    Программы, обеспечивающие удаленный доступ к информации, хранящейся на мэйнфреймах IBM (например, по удаленному подключению со стороны другого мэйнфрейма, находящегося в удалении)

    Службы транзакций

    Information Management System (информационно - управляющая система)

    Программная среда, предоставляющая программистам базовые средства взаимодействия с архитектурой SNA (в том числе безопасный доступ, управление файлами и накопителями). Альтернативой IMS является CICS

    Управление потоком данных Предста-вительские службы

    Network Control Program (программа управления сетью)

    Обеспечивает адресацию физических устройств и дополнительную логическую адресацию, а также маршрутизацию. Используется для шлюзовых коммуникаций SNA и управления ими (должна устанавливаться на любом шлюзе SNA для того, чтобы рабочие станции могли обращаться через шлюз к мэйнфрейму; см. главы 1 и 4, где шлюзы рассматриваются подробнее)

    Управление каналом и Управление маршрутом

    Synchronous Data Link Control (синхронное управление передачей данных)

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

    Управление физическим устройством и Управление каналом

    SNA Distributed Services (распределенные службы SNA)

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

    Службы транзакций

    System Services Control Point (точка управления системными службами)

    Программное обеспечение, управляющее VTAM

    Управлений передачей

    Метод доступа, используемый сетях SNA

    Управление физическим устройством Управление каналом

    Virtual Telecommuni-cations Access Method (виртуальный телекоммуника-ционный метод доступа)

    Управляет передачей данных в сети SNA (например, с помощью методов управления потоками). Обеспечивает обмен цифровыми данными

    Управление передачей

    Протокол DLC для доступа к операционным системам IBM

    Если для доступа к мэйнфрейму, работающему с SNA, используются компьютеры под управлением Windows 9 x , Windows NT и Windows 2000, то альтернативой SNA-шлюзу является установка протокола Data Link Control , DLC . Этот протокол эмулирует SNA, и он может также применяться для подключения к некоторым устаревшим моделям сетевых принтеров, которые могут работать только с ним (например, старые принтеры Hewlett-Packard).

    Совет

    Протокол DLC не поддерживается в Windows XP. Если вы рассматриваете возможность перехода на эту систему, то учтите, что с ней вы не сможете использовать DLC для доступа к мэйнфреймам IBM и, возможно, вам потребуется SNA-шлюз.

    В основном протокол DLC является альтернативой TCP/IP в тех случаях, когда некоторый хост использует SNA-коммуникации. Недостатком этого протокола является то, что он не маршрутизируется. Кроме того, он на самом деле не предназначен для одноранговых взаимодействий между рабочими станциями, а служит только для подключения к старым мэйнфреймам IBM (например, ES9000) или мини-компьютерам IBM (например, AS/400). В практическом задании 5-7 рассказывается о том, как установить DLC в системе Windows 2000.

    Протокол DNA для операционных систем компьютеров Digital (Compaq )

    Созданная в 1974 году архитектура Digital Network Architecture (DNA ) имеет такой же возраст, что и SNA. DNA использовалась в первых сетях компании Digital Equipment Corporation (DEC) и по-другому называлась DECnet. Затем этот стек протоколов применялся значительно реже.

    Архитектура DNA предусматривает использование фреймов Ethernet II (или DIX – аббревиатура от названий компаний-разработчиков Digital, Intel и Xerox) в шинной топологии. Одним из достоинств DNA является то, что с самого начала эта архитектура близко следовала эталонной модели OSI. He-Достаток DNA – то, что эта архитектура частная. Кроме того, после приобретения фирмы DEC компанией Compaq оригинальные компьютеры DEC и сети DNA стали менее популярными. Даже некогда известные компьютеры ча базе процессора DEC Alpha все чаще заменяются продаваемыми под маркой Compaq рабочими станциями и серверами, реализованными с использованием процессоров Intel Itanium.

    Поскольку DNA все реже встречается в сетях, уменьшается вероятность того, что вы столкнетесь с этой архитектурой на практике. Однако для общего представления в табл. 5.7 перечислены некоторые из протоколов и приложений, образующих стек DNA.

    Таблица 5.7. Протоколы и приложения, входящие в стек протоколов

    Аббревиатура

    Полное название

    Описание

    Уровень модели OSI

    Connectionless-Mode Network Service (сетевая служба без установления соединения)

    Обеспечивает работу служб без установления соединения (см. главу 2), а также маршрутизации

    Connection Oriented Network Service (сетевая служба с установлением соединения)

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

    Digital Data Communications Message Protocol (протокол сообщений передачи цифровых данных)

    Обеспечивает работу служб с установлением соединения и контролем ошибок. На уровне электрических сигналов позволяет осуществлять полудуплексную и полнодуплексную связь

    Физический Канальный(подуровень LLC)

    File Transfer, Access, and Management (передача файлов, доступ и управление)

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

    Прикладной

    High-Level Data Link Control (высокоуровневое управление каналом)

    Создает логические соединения (виртуальные каналы) в сетевом кабеле и координирует передачу данных мeжду ними. Управляет форматированием фреймов

    Физический и Канальный

    Соответствует стандарту Х.400 на почтовые службы

    Прикладной

    Naming Service (служба имен)

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

    Прикладной

    Network Virtual Terminal (служба сетевых виртуальных терминалов)

    Транслирует символы между Service терминалами, сетями DNA и хост-компьютерами

    Представительский и Прикладной

    Повышение производительности локальных сетей

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

    Вопросы для обсуждения

    При выборе протоколов, используемых в сети, рассмотрите следующие вопросы.

    · Должны ли пакеты маршрутизироваться?

    · Какого размера сеть – маленькая (менее 100 узлов), средняя (100 – 500 узлов) или крупная (свыше 500 узлов)?

    · Какие серверы используются и какие протоколы для них нужны?

    · Имеются ли мэйнфреймы и какие протоколы для них требуются?

    · Имеется ли непосредственный выход в Интернет или подключение к интранет-приложениям, использующим веб-технологии (виртуальная частная сеть)?

    · Какая скорость требуется для подключений к глобальной сети?

    · Имеются ли ответственные приложения?

    Если фреймы нужно маршрутизировать (например, в корпоративной сети), то лучше всего применять протокол TCP/IP, поскольку он ориентирован на маршрутизацию и распространен во многих сетях. Для маленьких и средних немаршрутизируемых сетей (менее 200 узлов) на базе серверов Windows NT и при условии отсутствия подключения к Интернету наилучшим выбором остается протокол NetBEUI, обеспечивающий быстрые и надежные коммуникации. В сетях NetWare (с серверами версий ниже 5.0) можно использовать IPX/SPX, хотя в смешанной сети, где имеются старые серверы NetWare и новые серверы Windows 2000, могут понадобиться протоколы IPX/SPX и TCP/IP. Протокол NWLink является хорошим средством для подключения систем Windows 9x/NT/2000 к старым серверам NetWare.

    Проблема каналов связи

    Наличие подключения к Интернету или веб-службам требует развертывания Протокола TCP/IP, при этом службы FTP могут использоваться для передачи файлов. Также протокол TCP/IP лучше всего применять для связи с со временными мэйнфреймами и компьютерами UNIX, поскольку для подключения к мэйнфрейму или к приложению, работающему на компьютере UNIX, может потребоваться эмуляция терминала по протоколу Telnet. Для подключения к мэйнфреймам IBM и мини-компьютерам (если они работа ют в среде SNA) можно также использовать протокол DLC. И, наконец, протокол DNA по-прежнему может понадобиться в сети, где имеются старые компьютеры DEC (например, DEC VAX).

    Примечание

    TCP/IP – наилучший протокол для средних и крупных сетей. Он может маршрутизироваться, обладает надежностью для ответственных приложения имеет надежный механизм контроля ошибок. В таких сетях важно иметь средства мониторинга сети и анализа неисправностей. Как изложено в главе 6, стек TCP/IP имеет протоколы, необходимые для решения подобных задач.

    Во многих случаях для разных сетевых приложений нужно использовать различные протоколы локальных сетей. Иногда в современных сетях в любых сочетаниях применяются протоколы TCP/IP, NetBEUI, IPX/SPX, SM и даже DNA. Как вы уже знаете, развернутые протоколы связаны с типом используемых операционных систем. Также на их выбор влияет наличие связи с глобальными сетями (например, для выхода в Интернет нужен протокол TCP/IP, который может также потребоваться для связи локальных сетей между собой через глобальную сеть). Если, скажем, TCP/IP используется серверами в одной локальной сети, а рабочие станции из другой сети должны обращаться к этим серверам, то обе локальные сети и связывающая их глобальная сеть должны обеспечивать передачу протокола TCP/IP.

    Удаление ненужных протоколов

    Иногда рабочие станции в сети остаются настроенными на использование нескольких протоколов даже после того как все хосты и серверы переведены на протокол TCP/IP. В этом случае легко можно повысить производительность сети, удалив с рабочих станций ненужные протоколы. В практическом задании 5-8 рассказывается, как удалить протокол DLC из системе Windows 2000, а в задании 5-9 вы узнаете, как удалить службу Client Service for NetWare (и протокол NWLink IPX/SPX) из систем Windows 2000 и Windows XP Professional.

    Резюме

    · В значительной степени архитектуру сетей определяют протоколы. Во многих сетях используется несколько протоколов, с помощью которых осуществляется доступ к различным операционным системам сетевых серверов и хост-компьютеров.

    · Обычно применяемые протоколы локальных сетей определяются типом сетевой серверной операционной системы, используемой в конкретной сети. Одной из старейших сетевых систем является NetWare, работающая со стеком протоколов IPX/SPX и обеспечивающая передачу данных между старыми версиями серверов NetWare и рабочими станциями (а также и другими серверами), подключенными к серверам. Протокол IPX/SPX реализован в тысячах локальных сетей, поскольку NetWare является одной из распространенных сетевых операционных систем. Однако в настоящее время благодаря тому, что многие сети связаны с Интернетом, новые версии NetWare (5.0 и выше) ориентированы на работу с более универсальным стеком протоколов TCP/IP.

    · Родным протоколом для систем Windows NT Server является NetBEUI, появление которого связано с разработкой сетевой операционной системы LAN Manager, которую компания Microsoft начинала совместно с фирмой IBM. В средних и крупных сетях с серверами Windows NT чаще используется стек TCP/IP. С появлением систем Windows 2000 и Windows Server 2003 протокол TCP/IP пришел на замену NetBEUI, что определяется требованиями службы Active Directory и необходимостью доступа к Интернету.

    · AppleTalk – это протокол, используемый компьютерами Macintosh с операционными системами Mac OS и Mac OS Server. Системы Windows NT, Windows 2000, Windows Server 2003 и Novell NetWare также поддерживают AppleTalk.

    · Некоторые сетевые серверные операционные системы (в частности, UNIX) изначально были ориентированы на работу со стеком TCP/IP (а также и с Интернетом). В других сетевых операционных системах (например, NetWare, Windows NT и Mac OS Server) стек TCP/IP был реализован уже после создания этих систем.

    · В первых системах IBM использовался стек протоколов SNA, который обеспечивал обмен данными между мэйнфреймами (мини-компьютерами) и терминалами, контроллерами и принтерами, а также между различными компьютерами. В операционных системах Windows имеется возможность установки протокола DLC для эмуляции коммуникаций SNA.

    · Стек протоколов DNA был разработан для использования в сетях на базе компьютеров DEC, однако в настоящее время он применяется редко, поскольку количество таких компьютеров в сетях значительно уменьшилось.

    · Простым и эффективным способом повышения производительности локальной сети является периодически проводимый анализ применяемых протоколов и удаление тех протоколов, которые больше не используются. Для доступа к компьютерам и принтерам.

    · Вплоть до начала 1990-х годов сетевые технологии в первую очередь разбивались в области протоколов локальных сетей. В настоящее время архитектура этих протоколов нашла логическое завершение в стеке TCP/IP, а частные протоколы (такие как IPX/SPX и NetBEUI) используются реже.

    В локальных сетях основная роль в организации взаимодействия узлов принадлежит протоколу канального уровня, который ориентирован на вполне определенную топологию ЛКС. Так, самый популярный протокол этого уровня - Ethernet - рассчитан на топологию "общая шина", когда все узлы сети параллельно подключаются к общей для них шине, а протокол Token Ring - на топологию "звезда". При этом применяются простые структуры кабельных соединений между РС сети, а для упрощения и удешевления аппаратных и программных решений реализовано совместное использование кабелей всеми РС в режиме разделения времени. Такие простые решения, характерные для разработчиков первых ЛКС во второй половине 70-х годов ХХ века, наряду с положительными имели и отрицательные последствия, главные из которых - ограничения по производительности и надежности.

    Поскольку в ЛКС с простейшей топологией (общая шина, кольцо, звезда) имеется только один путь передачи информации - моноканал, производительность сети ограничивается пропускной способностью этого пути, а надежность сети - надежностью пути. Поэтому по мере развития и расширения сфер применения локальных сетей с помощью специ-альных коммуникационных устройств (мостов, коммутаторов, маршрутизаторов) эти ограничения постепенно снимались. Базовые конфигурации ЛКС (шина, кольцо) превратились в элементарные звенья, из которых формируются более сложные структуры локальных сетей, имеющие параллельные и резервные пути между узлами.

    Однако внутри базовых структур локальных сетей продолжают работать все те же протоколы Ethernet и Token Ring. Объединение этих структур (сегментов) в общую, более сложную локальную сеть осуществляется с помощью дополнительного оборудования, а взаимодействие РС такой сети - с помощью других протоколов.

    В развитии локальных сетей, кроме отмеченных, наметились и другие тенденции:

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

      появление нового режима работы в ЛКС при использовании коммутаторов - полнодуплексного (хотя в базовых структурах локальных сетей РС работают в полудуплексном режиме, т. к. сетевой адаптер станции в каждый момент времени либо передает свои данные, либо принимает другие, но не делает это одновременно). Сегодня каждая технология ЛКС приспособлена для работы как в полудуплексном, так и в полнодуплексном режимах. Стандартизация протоколов ЛКС осуществлена комитетом 802, организованном в 1980 в институте IEEE. Стандарты семейства IEEE 802.Х охватывают только два нижних уровня модели ВОС - физический и канальный. Именно эти уровни отражают специфику локальных сетей, старшие уровни, начиная с сетевого, имеют общие черты для сетей любого класса.

    В локальных сетях канальный уровень разделен на два подуровня:

      логической передачи данных (LLC - Logical Link Control);

      управления доступом к среде (МАС - Media Access Control).

    Протоколы подуровней МАС и LLC взаимно независимы, т.е. каждый протокол подуровня МАС может работать с любым протоколом подуровня LLC, и наоборот.

    Подуровень МАС обеспечивает совместное использование общей передающей среды, а подуровень LLC организует передачу кадров с различным уровнем качества транспортных услуг. В современных ЛКС используются несколько протоколов подуровня МАС, реализующих различные алгоритмы доступа к разделяемой среде и определяющих специфику технологий Ethernet, Fast Ethernet, Gigabit Ethernet, Token Ring, FDDI, 100VG-AnyLAN.

    Протокол LLC . Для ЛКС этот протокол обеспечивает необходимое качество транспортной службы. Он занимает положение между сетевыми протоколами и протоколами подуровня МАС. По протоколу LLC кадры передаются либо дейтаграммным способом, либо с помощью процедур с установлением соединения между взаимодействующими станциями сети и восстановлением кадров путем их повторной передачи при наличии в них искажений.

    Технология Ethernet (стандарт 802.3) . Это самый распространенный стандарт локальных сетей. По этому протоколу в настоящее время работают большинство ЛКС. Имеется несколько вариантов и модификаций технологии Ethernet, составляющих целое семейство технологий. Из них наиболее известными являются 10-мегабитный вариант стандарта IEEE 802.3, а также новые высокоскоростные технологии Fast Ethernet и Gigabit Ethernet. Все эти варианты и модификации отличаются типом физической среды передачи данных.

    Все виды стандартов Ethernet используют один и тот же метод доступа к передающей среде - метод случайного доступа CSMA/CD. Он применяется исключительно в сетях с общей логической шиной, которая работает в режиме коллективного доступа и служит для передачи данных между любыми двумя узлами сети. Такой метод доступа носит вероятностный характер: вероятность получения среды передачи в свое распоряжение зависит от загруженности сети. При значительной загрузке сети интенсивность коллизий возрастает и ее полезная пропускная способ-ность резко падает.

    Полезная пропускная способность сети - это скорость передачи пользовательских данных, переносимых полем данных кадров. Она всегда меньше номинальной битовой скорости протокола Ethernet за счет служебной информации кадра, межкадровых интервалов и ожидания доступа к среде. Коэффициент использования сети в случае отсутствия коллизий и ожидания доступа имеет максимальное значение 0,96.

    Технологией Ethernet поддерживаются 4 разных типа кадров, имеющих общий формат адресов. Распознавание типа кадров осуществляется автоматически.

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

      номинальная пропускная способность - 10 Мбит/с;

      максимальное число РС в сети - 1024;

      максимальное расстояние между узлами в сети - 2500 м;

      максимальное число коаксиальных сегментов сети - 5;

      максимальная длина сегмента - от 100 м (для 10Base-T) до 2000 м (для 10Base-F);

      максимальное число повторителей между любыми станциями сети - 4.

    Технология Token Ring (стандарт 802.5) . Здесь используется разделяемая среда передачи данных, которая состоит из отрезков кабеля, соединяющих все РС сети в кольцо. К кольцу (общему разделяемому ресурсу) применяется детерминированный доступ, основанный на передаче станциям права на использование кольца в определенном порядке. Это право предается с помощью маркера. Маркерный метод доступа гарантирует каждой РС получение доступа к кольцу в течение времени оборота маркера. Используется приоритетная система владения маркером - от 0 (низший приоритет) до 7 (высший). Приоритет для текущего кадра определяется самой станцией, которая может захватить кольцо, если в нем нет более приоритетных кадров.

    В сетях Token Ring в качестве физической среды передачи данных применяется экранированная и неэкранированная витая пара и волоконно-оптический кабель. Сети работают с двумя битовыми скоростями - 4 и 16 Мбит/с, причем в одном кольце все РС должны работать с одной скоростью. Максимальная длина кольца - 4 км, а максимальное количество РС в кольце - 260. Ограничения на максимальную длину кольца связаны со временем оборота маркера по кольцу. Если в кольце 260 станций и время удержания маркера каждой станцией равно 10 мс, то маркер после совершения полного оборота вернется в активный монитор через 2,6 с. При передаче длинного сообщения, разбиваемого, например, на 50 кадров, это сообщение будет принято получателем в лучшем случае (когда активной является только РС-отправитель) через 260 с, что для пользователей не всегда приемлемо.

    Максимальный размер кадра в стандарте 802.5 не определен. Обычно он принимается равным 4 Кбайтам для сетей 4 Мбит/с и 16 Кбайтам для сетей 16 Мбит/с.

    В сетях 16 Мбит/с используется также и более эффективный алгоритм доступа к кольцу. Это алгоритм раннего освобождения маркера (ETR): станция передает маркер доступа следующей станции сразу же после окончания передачи последнего бита своего кадра, не дожидаясь возвращения по кольцу этого кадра и занятого маркера. В этом случае по кольцу будут передаваться одновременно кадры нескольких станций, что существенно повышает эффективность использования пропускной способности кольца. Конечно, и в этом случае в каждый данный момент ге-нерировать кадр в кольцо может только та РС, которая в этот момент владеет маркером доступа, а остальные станции будут лишь ретранслировать чужие кадры.

    Технология Token Ring (технология этих сетей была разработана еще в 1984 г. фирмой IBM) существенно сложнее технологии Ethernet. В ней заложены возможности отказоустойчивости: за счет обратной связи кольца одна из станций (активный монитор) непрерывно контролирует наличие маркера, время оборота маркера и кадров данных, обнаруженные ошибки в сети устраняются автоматически, например, потерянный маркер может быть восстановлен. В случае выхода из строя активного монитора выбирается новый активный монитор и процедура инициализации кольца повторяется.

    Стандарт Token Ring изначально предусматривал построение связей в сети с помощью концентраторов, называемых MAU, т.е. устройствами многостанционного доступа. Концентратор может быть пассивным (соединяет порты внутренними связями так, чтобы РС, подключенные к этим портам, образовали кольцо, а также обеспечивает обход какого-либо порта, если подключенный к этому порту компьютер выключается) или активным (выполняет функции регенерации сигналов и поэтому иногда называется повторителем).

    Для сетей Token Ring характерна звездно-кольцевая топология: РС подключаются к концентраторам по топологии звезды, а сами концентраторы через специальные порты Ring In (RI) и Ring Out (RO) объединяются для образования магистрального физического кольца. Сеть Token Ring может строиться на основе нескольких колец, разделенных мостами, маршрутизирующие кадры адресату (каждый кадр снабжается полем с маршрутом прохождения колец).

    Недавно технология Token Ring стараниями компании IBM получила новое развитие: предложен новый вариант этой технологии (HSTR), поддерживающий битовые скорости в 100 и 155 Мбит/с. При этом сохранены основные особенности технологии Token Ring 16 Мбит/с.

    Технология FDDI . Это первая технология ЛКС, в которой для передачи данных используется волоконно-оптический кабель. Она появилась в 1988 г. и ее официальное название - оптоволоконный интерфейс распределенных данных (Fiber Distributed Data Interface, FDDI). В настоящее время в качестве физической среды, кроме волоконно-оптического кабеля, применяется неэкранированная витая пара.

    Технология FDDI предназначена для использования на магистральных соединениях между сетями, для подключения к сети высокопроизводительных серверов, в корпоративных и городских сетях. Поэтому в ней обеспечена высокая скорость передачи данных (100 Мбит/с), отказоустойчивость на уровне протокола и большие расстояния между узлами сети. Все это сказалось на стоимости подключения к сети: для подключения клиентских компьютеров эта технология оказалась слишком дорогой.

    Существует значительная преемственность между технологиями Token Ring и FDDI. Основные идеи технологии Token Ring восприняты и получили совершенствование и развитие в технологии FDDI, в частности, кольцевая топология и маркерный метод доступа.

    В сети FDDI для передачи данных используются два оптоволоконных кольца, образующих основной и резервный пути передачи между РС. Станции сети подключаются к обоим кольцам. В нормальном режиме задействовано только основное кольцо. В случае отказа какой-либо части основного кольца оно объединяется с резервным кольцом, вновь образуя единое кольцо (это режим "свертывания" колец) с помощью концентраторов и сетевых адаптеров. Наличие процедуры "свертывания" при отказах - основной способ повышения отказоустойчивости сети. Существуют и другие процедуры для определения отказов в сети и восстановления ее работоспособности.

    Основное отличие маркерного метода доступа к передающей среде, используемого в сети FDDI, от этого метода в сети Token Ring заключается в том, что в сети FDDI время удержания маркера является постоянной величиной только для синхронного трафика, который критичен к задержкам передачи кадров. Для асинхронного трафика, не критичного к небольшим задержкам передачи кадров, это время зависит от загрузки кольца: при небольшой загрузке оно увеличивается, а при большой - может уменьшаться до нуля. Таким образом, для асинхронного трафика метод доступа является адаптивным, хорошо регулирующим временные перегрузки сети. Механизм приоритетов кадров отсутствует. Считается, что достаточно разделить трафик на два класса - синхронный, который обслуживается всегда (даже при перегрузках кольца), и асинхронный, обслуживаемый при малой загрузке кольца. Станции FDDI применяют алгоритм раннего освобождения маркера, как это сделано в сети Token Ring со скоростью 16 Мбит/с.

    В сети FDDI выделенный активный монитор отсутствует, все станции и концентраторы равноправны, при обнаружении отклонений от нормы они осуществляют повторную инициализацию сети и, если это не-обходимо, ее реконфигурацию.

    Результаты сравнения технологии FDDI с технологиями Ethernet и Token Ring приведены в табл.5.1 .

    Технологии Fast Ethernet и 100VG-AnyLAN . Обе эти технологии не являются самостоятельными стандартами и рассматриваются как развитие и дополнение технологии Ethernet, реализованное соответственно в 1995 и 1998 годах. Новые технологии Fast Ethernet (стандарт 802.3и) и 100VG-AnyLAN (стандарт 802.3z) имеют производительность 100 Мбит/с и отличаются степенью преемственности с классическим Ethernet.

    В стандарте 802.3и сохранен метод случайного доступа CSMA/CD и тем самым обеспечена преемственность и согласованность сетей 10 Мбит/с и 100 Мбит/с.

    В технологии 100VG-AnyLAH используется совершенно новый метод доступа - Demand Priority (DP), приоритетный доступ по требованию. Эта технология существенно отличается от технологии Ethernet. Она поддерживает различные типы трафика в довольно узкой области и не нашла широкого распространения.

    Отметим особенности технологии Fast Ethernet и ее отличия от технологии Ethernet:

      структура физического уровня технологии Fast Ethernet - более сложная, что объясняется использованием трех вариантов кабельных систем: волоконно-оптический кабель, витая пара категории 5 (используются две пары), витая пара категории 3 (используются четыре пары). Отказ от коаксиального кабеля привел к тому, что сети этой технологии всегда имеют иерархическую древовидную структуру;

      диаметр сети сокращен до 200 м, время передачи кадра минимальной длины уменьшено в 10 раз за счет увеличения скорости передачи в 10 раз;

      технология Fast Ethernet может использоваться при создании магистралей локальных сетей большой протяженности совместно с коммутаторами (полудуплексный вариант работы для этой технологии является основным);

      Таблица 17.1. Сравнение сетей различных топологий

      Характеристики

      Тип технологии

      Пропускная способность Мбит/с

      Топология

      Двойное кольцо

      Шина, звезда

      Звезда, кольцо

      Метод доступа

      Маркерный, доля от времени оборота маркера

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

      Среда передачи данных

      Оптоволокно, неэкранированная витая пара

      Толстый коаксиал, тонкий коаксиал, витая пара, оптоволокно

      Экранированная и неэкранированная витая пара, оптоволокно

      Максимальная длина сети (без мостов)

      200 км (100 км на кольцо)

      Максимальное расстояние между узлами

      Максимальное количество узлов

    • для всех трех спецификаций физического уровня, отличающихся типом применяемого кабеля, форматы кадров отличаются от форматов кадров технологий 10-мегабитного Ethernet;

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

      применяется метод кодирования 4В/5В, хорошо себя зарекомендовавший в технологии FDDI. В соответствии с этим методом каждые 4 бита передаваемых данных представляются 5 битами, т.е. из 32 комбинаций 5-битных символов для кодирования исходных 4-битных символов используются только 16 комбинаций, а из ос-тавшихся 16 комбинаций выбираются несколько кодов, которые используются как служебные. Один из служебных кодов постоянно передается в течение пауз между передачей кадров. Если он в линии связи отсутствует, то это свидетельствует об отказе физической связи;

      кодирование и синхронизация сигналов осуществляются с помощью биполярного кода NRZ;

      технология Fast Ethernet рассчитана на применение концентраторов-повторителей для образования связей в сети (то же самое имеет место для всех некоаксиальных вариантов Ethernet).

    Технология Gigabit Ethernet . Появление этой технологии представляет собой новую ступень в иерархии сетей семейства Ethernet, обеспечивающую скорость передачи в 1000 Мбит/с. Стандарт по этой технологии принят в 1998г., в нем максимально сохранены идеи классической технологии Ethernet.

    По поводу технологии Gigabit Ethernet следует отметить следующее:

      на уровне протокола не поддерживаются (так же, как и у его предшественников): качество обслуживания, избыточные связи, тестирование работоспособности узлов и оборудования. Что касается качества обслуживания, то считается, что высокая скорость передачи данных по магистрали и возможность назначения пакетам приоритетов в коммутаторах вполне достаточны для обеспечения качества транспортного обслуживания пользователей сети. Поддержка избыточных связей и тестирование оборудования осуществляются протоколами более высоких уровней;

      сохраняются все форматы кадров Ethernet;

      имеется возможность работы в полудуплексном и полнодуплексном режимах. Первый из них поддерживает метод доступа CSMA/CD, а второй - работу с коммутаторами;

      поддерживаются все основные виды кабелей, как и в предшествующих технологиях этого семейства: волоконно-оптический, коаксиальный, витая пара;

      минимальный размер кадра увеличен с 64 до 512 байт, максимальный диаметр сети тот же - 200 м. Можно передавать несколько кадров подряд, не освобождая среду.

    Технология Gigabit Ethernet позволяет строить крупные локальные сети, в которых серверы и магистрали нижних уровней сети работают на скорости 100 Мбит/с, а магистраль 1000 Мбит/с объединяет их, обеспечивая запас пропускной способности.

    Технология Wi-Fi . Технология Wi-Fi (произносится "вай-фай", сокр. от англ. Wireless Fidelity - беспроводная надежность) - это стандарт на оборудование Wireless LAN, которое устанавливается там, где развертывание кабельной системы невозможно или экономически нецелесообразно. Мобильные устройства этого оборудования (смартфоны и ноутбуки), оснащенные клиентскими Wi-Fi приемо-передающими устройствами, могут подключаться к локальной сети и получать доступ в Internet через так называемые точки доступа (хост-порты).

    Обычно схема Wi-Fi сети содержит не менее одной точки доступа и не менее одного клиента, но возможно подключение двух клиентов в режиме "точка-точка", и тогда точка доступа не используется, а клиенты со-единяются посредством сетевых адаптеров напрямую. Наименьшая скорость передачи данных для Wi-Fi - 1 Мбит/с. Стандарт Wi-Fi дает клиенту полную свободу при выборе критериев для соединения с другими клиентами. Последние версии операционных систем этого стандарта содержат функцию, которая показывает пользователю все доступные сети и позволяет переключаться между ними.

    Технология Wi-Fi применяется в основном для управления движущимися объектами, а также в тех случаях, когда невозможно прокладывать проводные сети Ethernet.

    Преимущества Wi-Fi:

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

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

      для клиентских станций возможно перемещение в пространстве;

      Wi-Fi - это набор глобальных стандартов, поэтому Wi-Fi-оборудование может работать в разных странах по всему миру.

    В качестве недостатков Wi-Fi можно отметить следующие:

      наличие ограничений в частотном диапазоне в различных странах;

      довольно высокое по сравнению с другими стандартами потребление энергии;

      ограниченный радиус действия (до 100 м);

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

      недостаточно высокая информационная безопасность. Отметим, что Microsoft Windows полностью поддерживает Wi-Fi посредством драйверов.

    До сих пор рассматривались протоколы, работающие на первых трех уровнях семиуровневой эталонной модели ВОС и реализующие соответствующие методы логической передачи данных и доступа к передающей среде. В соответствии с этими протоколами передаются пакеты между рабочими станциями, но не решаются вопросы, связанные с сетевыми фай-ловыми системами и переадресацией файлов. Эти протоколы не включают никаких средств обеспечения правильной последовательности приема переданных данных и средств идентификации прикладных программ, нуждающихся в обмене данными.

    В отличие от протоколов нижнего уровня, протоколы верхнего уровня (называемые также протоколами среднего уровня, так как они реализуются на 4-м и 5-м уровнях модели ВОС) служат для обмена данными. Они предоставляют программам интерфейс для передачи данных методом дейтаграмм, когда пакеты адресуются и передаются без подтвержде-ния получения, и методом сеансов связи, когда устанавливается логическая связь между взаимодействующими станциями (источником и адресатом) и доставка сообщений подтверждается.

    Здесь лишь коротко отметим протокол IPX/SPX, получивший некоторое применение в локальных сетях, особенно в связи с усложнением их топологии (вопросы маршрутизации перестали быть тривиальными) и расширением предоставляемых услуг. IPX/SPX - сетевой протокол NetWare, причем IPX (Internetwork Packet Exchange) - протокол межсетевого обмена пакетами, а SPX (Sequenced Packet Exchange) - протокол последовательного обмена пакетами.

    Протокол IPX/SPX . Этот протокол является набором протоколов IPX и SPX. Фирма Nowell в сетевой операционной системе NetWare применяет протокол IPX для обмена дейтаграммами и протокол SPX для обмена в сеансах связи.

    Протокол IPX/SPX относится к программно-реализованным протоколам. Он не работает с аппаратными прерываниями, используя функции драйверов операционных систем. Пара протоколов IPX/SPX имеет фиксированную длину заголовка, что приводит к полной совместимости разных реализаций этих протоколов.

    Протокол IPX применяется маршрутизаторами в сетевой операционной системе (СОС) NetWare. Он соответствует сетевому уровню модели ВОС и выполняет функции адресации, маршрутизации и переадресации в процессе передачи пакетов данных. Несмотря на отсутствие гарантий доставки сообщений (адресат не передает отправителю подтверждения о получении сообщения), в 95% случаев не требуется повторной передачи. На уровне IPX выполняются служебные запросы к файловым серверам, и каждый такой запрос требует ответа со стороны сервера. Этим и определяется надежность работы методом дейтаграмм, так как маршрутизаторы воспринимают реакцию сервера на запрос как ответ на правильно переданный пакет.

    Протокол SPX работает на транспортном уровне модели ВОС, но имеет и функции, свойственные протоколам сеансового уровня. Он осуществляет управление процессами установки логической связи, обмена и окончания связи между любыми двумя узлами (рабочими станциями) ЛКС. После установления логической связи пакеты могут циркулировать в обоих направлениях с гарантией того, что они передаются без ошибок. Протокол SPX гарантирует очередность приема пакетов согласно очередности отправления.