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


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 номер порта. Это и есть стандартный номер порта для протокола POP 3. В «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
  • Добавить метки

    SMTP (англ. Simple Mail Transfer Protocol - простой протокол передачи почты) - это широко используемый сетевой протокол, предназначенный для передачи электронной почты в сетях TCP/IP.

    SMTP впервые был описан в RFC 821 (1982 год); последнее обновление в RFC 5321 (2008) включает масштабируемое расширение - ESMTP (англ. Extended SMTP). В настоящее время под «протоколом SMTP», как правило, подразумевают и его расширения. Протокол SMTP предназначен для передачи исходящей почты с использованием порта TCP 25.

    В то время, как электронные почтовые серверы и другие агенты пересылки сообщений используют SMTP для отправки и получения почтовых сообщений, работающие на пользовательском уровне клиентские почтовые приложения обычно используют SMTP только для отправки сообщений на почтовый сервер для ретрансляции. Для получения сообщений клиентские приложения обычно используют либо POP (англ. Post Office Protocol - протокол почтового отделения), либо IMAP (англ. Internet Message Access Protocol), либо проприетарные протоколы (такие как Microsoft Exchange и Lotus Notes/Domino) для доступа к учетной записи своего почтового ящика на сервере.

    POP3

    POP3 (англ. Post Office Protocol Version 3 - протокол почтового отделения, версия 3) - стандартный Интернет-протокол прикладного уровня, используемый клиентами электронной почты для получения почты с удаленного сервера по TCP/IP-соединению.

    Стандартный порт РОP3 - 110.

    POP и IMAP (Internet Message Access Protocol) - наиболее распространенные Интернет-протоколы для извлечения почты. Практически все современные клиенты и серверы электронной почты поддерживают оба стандарта. Протокол POP был разработан в нескольких версиях, нынешним стандартом является третья версия (POP3). Большинство поставщиков услуг электронной почты (такие как Hotmail, Gmail и Yahoo! Mail) также поддерживают IMAP и POP3. Предыдущие версии протокола (POP, POP2) устарели.

    Альтернативным протоколом для сбора сообщений с почтового сервера является IMAP.

    IMAP

    IMAP (англ. Internet Message Access Protocol) - протокол прикладного уровня для доступа к электронной почте.

    Базируется на транспортном протоколе TCP и использует порт 143.

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

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

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

    ГОСТ Р МЭК 60870-5-103-2005: Устройства и системы телемеханики. Часть 5. Протоколы передачи. Раздел 103. Обобщающий стандарт по информационному интерфейсу для аппаратуры релейной защиты - Терминология ГОСТ Р МЭК 60870 5 103 2005: Устройства и системы телемеханики. Часть 5. Протоколы передачи. Раздел 103. Обобщающий стандарт по информационному интерфейсу для аппаратуры релейной защиты оригинал документа: 3.2 архитектура повышенной… … Словарь-справочник терминов нормативно-технической документации

    протокол верхнего уровня - Любой протокол в многоуровневой иерархии, использующей протокол IP или TCP, который лежит выше протокола IP или TCP. В число таких протоколов входят протоколы транспортного уровня, протоколы уровня представления и прикладного уровня. Тематики… … Справочник технического переводчика

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

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

    SMB (сокр. от англ. Server Message Block) сетевой протокол прикладного уровня для удалённого доступа к файлам, принтерам и другим сетевым ресурсам, а также для межпроцессного взаимодействия. Первая версия протокола была разработана… … Википедия

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

    Стандарт Международного союза электросвязи по передаче факсимильных сообщений в реальном времени через IP сети. Для факсов, передаваемых по протоколу T.38 зарезервирован тип image/t38. Содержание 1 История 2 Обзор 3 Операции … Википедия

    Книги

    • . Net. Сетевое программирование для профессионалов / Professional . NET Network Programming , Винод Кумар,Эндрю Кровчик,Номан Лагари,Аджит Мунгале,Кристиан Нагел,Тим Паркер,Шриниваса Шивакумар. 400 стр. Сетевая организация ПО - одна из центральных задач программирования при разработке бизнес-приложений. Прочитав книгу, вы сможете уверенно программировать сетевые задачи в. NET и…
    • . NET Сетевое программирование , Кумар Винод, Кровчик Эндрю, Лагари Номан. Сетевая организация ПО - одна из центральных задач программирования при разработке бизнес-предложений. Прочитав книгу, вы сможете уверенно программировать сетевые задачи в. NET и будете…

    Ключевой термин: протокол.

    Протокол (protocol) - набор правил, алгоритм обмена информацией между абонентами сети.

    Второстепенные термины

      Стек протоколов (protocol stack) - это комбинация протоколов. Каждый уровень определяет различные протоколы для управления функциями связи или ее подсистемами. Каждому уровню присущ свой набор правил.

      Привязка (binding) является установкой соответствия стека протоколов плате сетевого адаптера.

      Прикладные протоколы - это протоколы, работающие на верхнем уровне модели OSI и обеспечивающие взаимодействие приложений и обмен данными между ними.

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

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

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

    Протоколы (protocols) - это правила и технические процедуры, позволяющие нескольким компьютерам при объединении в сеть общаться друг с другом.

    Три основных момента, касающихся протоколов.

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

      Протоколы работают на разных уровнях модели OSI. Функции протокола определяются уровнем, на котором он работает.

      Если, например, какой-то протокол работает на Физическом уровне, то это означает, что он обеспечивает прохождение пакетов через плату сетевого адаптера и их поступление в сетевой кабель.

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

    Как сетевые функции распределены по всем уровням модели OSI, так и протоколы совместно работают на различных уровнях стека протоколов. Уровни в стеке протоколов соответствуют уровням модели OSI. В совокупности протоколы дают полную характеристику функциям и возможностям стека.

    Работа протоколов

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

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

    Компьютер-отправитель

    Компьютер-отправитель в соответствии с протоколом выполняет следующие действия:

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

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

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

    Компьютер-получатель

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

      принимает пакеты данных из сетевого кабеля;

      через плату сетевого адаптера передает пакеты в компьютер;

      удаляет из пакета всю служебную информацию, добавленную компьютером-отправителем;

      копирует данные из пакетов в буфер - для их объединения в исходный блок данных;

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

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

    Маршрутизируемые и немаршрутизируемые протоколы

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

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

    Протоколы в многоуровневой архитектуре

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

      подготовку;

      передачу;

      прием;

      последующие действия.

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

    Стеки протоколов

    Стек протоколов (protocol stack) - это комбинация протоколов. Каждый уровень определяет различные протоколы для управления функциями связи или ее подсистемами. Каждому уровню присущ свой набор правил.

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

    Привязка

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

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

    Привязка (binding) не ограничивается установкой соответствия стека протоколов плате сетевого адаптера. Стек протоколов должен быть привязан (или ассоциирован) к компонентам, уровни которых и выше, и ниже его уровня. Так, TCP/IP наверху может быть привязан к Сеансовому уровню NetBIOS, а внизу - к драйверу платы сетевого адаптера. Драйвер, в свою очередь, привязан к плате сетевого адаптера.

    Стандартные стеки

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

      набор протоколов ISO/OSI;

      IBM System Network Architecture (SNA);

      Digital DECnet;

      Novell NetWare;

      Apple AppleTalk;

      набор протоколов Интернета, TCP/IP.

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

      прикладной;

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

      сетевой.

    Схема расположения этих типов соответствует модели OSI.

    Прикладные протоколы

    Прикладные протоколы работают на верхнем уровне модели OSI. Они обеспечивают взаимодействие приложений и обмен данными между ними. К наиболее популярным прикладным протоколам относятся:

      АРРС (Advanced Program-to-Program Communication) - одноранговый SNA-протокол фирмы IBM, используемый в основном на AS/400;

      FTAM (File Transfer Access and Management) - протокол OSI доступа к файлам;

      X.400 - протокол CCITT для международного обмена электронной почтой;

      Х.500 - протокол CCITT служб файлов и каталогов на нескольких системах;

      SMTP (Simple Mail Transfer Protocol) - протокол Интернета для обмена электронной почтой;

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

      SNMP (Simple Network Management Protocol) - протокол Интернета для мониторинга сети и сетевых компонентов;

      Telnet - протокол Интернета для регистрации на удаленных хостах и обработки данных на них;

      Microsoft SMBs (Server Message Blocks, блоки сообщений сервера) и клиентские оболочки или редиректоры;

      NCP (Novell NetWare Core Protocol) и клиентские оболочки или редиректоры фирмы Novell;

      Apple Talk и Apple Share - набор сетевых протоколов фирмы Apple;

      AFP (AppleTalk Filling Protocol) - протокол удаленного доступа к файлам фирмы Apple;

      DAP (Data Access Protocol) - протокол доступа к файлам сетей DECnet.

    Транспортные протоколы

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

      TCP (Transmission Control Protocol) - TCP/IP-протокол для гарантированной доставки данных, разбитых на последовательность фрагментов;

      SPX - часть набора протоколов IPX/SPX (Internetwork Packet Exchange/Sequential Packet Exchange) для данных, разбитых на последовательность фрагментов, фирмы Novell;

      NWLink - реализация протокола IPX/SPX от фирмы Microsoft;

      NetBEUI - устанавливает сеансы связи между компьютерами (NetBIOS) и предоставляет верхним уровням транспортные услуги (NetBEUI);

      АТР (AppleTalk Transaction Protocol), NBP (Name Binding Protocol) - протоколы сеансов связи и транспортировки данных фирмы Apple.

    Сетевые протоколы

    Сетевые протоколы обеспечивают услуги связи. Эти протоколы управляют несколькими типами данных: адресацией, маршрутизацией, проверкой ошибок и запросами на повторную передачу. Сетевые протоколы, кроме того, определяют правила для осуществления связи в конкретных сетевых средах, например Ethernet или Token Ring. К наиболее популярным сетевым протоколам относятся:

      IP (Internet Protocol) - TCP/IP-протокол для передачи пакетов;

      IPX (Internetwork Packet Exchange) - протокол фирмы NetWare для передачи и маршрутизации пакетов;

      NWLink - реализация протокола IPX/SPX фирмой Microsoft;

      NetBEUI - транспортный протокол, обеспечивающий услуги транспортировки данных для сеансов и приложений NetBIOS;

      DDP (Datagram Delivery Protocol) - AppleTalk-протокол транспортировки данных.

    Стандартные стеки коммуникационных протоколов

    Важнейшим направлением стандартизации в области вычислительных сетей является стандартизация коммуникационных протоколов. В настоящее время в сетях используется большое количество стеков коммуникационных протоколов. Наиболее популярными являются стеки: TCP/IP, IPX/SPX, NetBIOS/SMB, DECnet, SNA и OSI. Все эти стеки, кроме SNA на нижних уровнях - физическом и канальном, - используют одни и те же хорошо стандартизованные протоколы Ethernet, Token Ring, FDDI и некоторые другие, которые позволяют использовать во всех сетях одну и ту же аппаратуру. Зато на верхних уровнях все стеки работают по своим собственным протоколам. Эти протоколы часто не соответствуют рекомендуемому моделью OSI разбиению на уровни. В частности, функции сеансового и представительного уровня, как правило, объединены с прикладным уровнем. Такое несоответствие связано с тем, что модель OSI появилась как результат обобщения уже существующих и реально используемых стеков, а не наоборот.

    Стек OSI

    Следует четко различать модель OSI и стек OSI. В то время как модель OSI является концептуальной схемой взаимодействия открытых систем, стек OSI представляет собой набор вполне конкретных спецификаций протоколов. В отличие от других стеков протоколов стек OSI полностью соответствует модели OSI, он включает спецификации протоколов для всех семи уровней взаимодействия, определенных в этой модели. На нижних уровнях стек OSI поддерживает Ethernet, Token Ring, FDDI, протоколы глобальных сетей, Х.25 и ISDN, - то есть использует разработанные вне стека протоколы нижних уровней, как и все другие стеки. Протоколы сетевого, транспортного и сеансового уровней стека OSI специфицированы и реализованы различными производителями, но распространены пока мало. Наиболее популярными протоколами стека OSI являются прикладные протоколы. К ним относятся: протокол передачи файлов FT AM, протокол эмуляции терминала VTP, протоколы справочной службы Х.500, электронной почты Х.400 и ряд других.

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

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

    Стек OSI - международный, независимый от производителей стандарт. Его поддерживает правительство США в своей программе GOSIP, в соответствии с которой все компьютерные сети, устанавливаемые в правительственных учреждениях США после 1990 года, должны или непосредственно поддерживать стек OSI, или обеспечивать средства для перехода на этот стек в будущем. Тем не менее стек OSI более популярен в Европе, чем в США, так как в Европе осталось меньше старых сетей, работающих по своим собственным протоколам.

    Стек TCP/IP

    Стек TCP/IP был разработан по инициативе Министерства обороны США более 25 лет назад для связи экспериментальной сети ARPAnet с другими сетями как набор общих протоколов для разнородной вычислительной среды. Большой вклад в развитие стека TCP/IP, который получил свое название по популярным протоколам IP и TCP, внес университет Беркли, реализовав протоколы стека в своей версии ОС UNIX. Популярность этой операционной системы привела к широкому распространению протоколов TCP, IP и других протоколов стека. Сегодня этот стек используется для связи компьютеров всемирной информационной сети Internet, а также в огромном числе корпоративных сетей.

    Стек TCP/IP на нижнем уровне поддерживает все популярные стандарты физического и канального уровней: для локальных сетей - это Ethernet, Token Ring, FDDI, для глобальных - протоколы работы на аналоговых коммутируемых и выделенных линиях SLIP, РРР, протоколы территориальных сетей Х.25 и ISDN.

    Основными протоколами стека, давшими ему название, являются протоколы IP и TCP. Эти протоколы в терминологии модели OSI относятся к сетевому и транспортному уровням соответственно. IP обеспечивает продвижение пакета по составной сети, a TCP гарантирует надежность его доставки.

    За долгие годы использования в сетях различных стран и организаций стек TCP/IP вобрал в себя большое количество протоколов прикладного уровня. К ним относятся такие популярные протоколы, как протокол пересылки файлов FTP, протокол эмуляции терминала telnet, почтовый протокол SMTP, используемый в электронной почте сети Internet, гипертекстовые сервисы службы WWW и многие другие.

    Сегодня стек TCP/IP представляет собой один из самых распространенных стеков транспортных протоколов вычислительных сетей. Действительно, только в сети Internet объединено около 10 миллионов компьютеров по всему миру, которые взаимодействуют друг с другом с помощью стека протоколов TCP/IP.

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

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

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

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

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

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

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

    Стек IPX/SPX

    Этот стек является оригинальным стеком протоколов фирмы Novell, разработанным для сетевой операционной системы NetWare еще в начале 80-х годов. Протоколы сетевого и сеансового уровней Internetwork Packet Exchange (IPX) и Sequenced Packet Exchange (SPX), которые дали название стеку, являются прямой адаптацией протоколов XNS фирмы Xerox, распространенных в гораздо меньшей степени, чем стек IPX/SPX. Популярность стека IPX/SPX непосредственно связана с операционной системой Novell NetWare, которая еще сохраняет мировое лидерство по числу установленных систем, хотя в последнее время ее популярность несколько снизилась и по темпам роста она отстает от Microsoft Windows NT.

    Многие особенности стека IPX/SPX обусловлены ориентацией ранних версий ОС NetWare (до версии 4.0) на работу в локальных сетях небольших размеров, состоящих из персональных компьютеров со скромными ресурсами. Понятно, что для таких компьютеров компании Novell нужны были протоколы, на реализацию которых требовалось бы минимальное количество оперативной памяти (ограниченной в IBM-совместимых компьютерах под управлением MS-DOS объемом 640 Кбайт) и которые бы быстро работали на процессорах небольшой вычислительной мощности. В результате протоколы стека IPX/SPX до недавнего времени хорошо работали в локальных сетях и не очень - в больших корпоративных сетях, так как они слишком перегружали медленные глобальные связи широковещательными пакетами, которые интенсивно используются несколькими протоколами этого стека (например, для установления связи между клиентами и серверами). Это обстоятельство, а также тот факт, что стек IPX/SPX является собственностью фирмы Novell и на его реализацию нужно получать лицензию (то есть открытые спецификации не поддерживались), долгое время ограничивали распространенность его только сетями NetWare. Однако с момента выпуска версии NetWare 4.0 Novell внесла и продолжает вносить в свои протоколы серьезные изменения, направленные на их адаптацию для работы в корпоративных сетях. Сейчас стек IPX/ SPX реализован не только в NetWare, но и в нескольких других популярных сетевых ОС, например SCO UNIX, Sun Solaris, Microsoft Windows NT.

    Стек NetBIOS/SMB

    Этот стек широко используется в продуктах компаний IBM и Microsoft. На физическом и канальном уровнях этого стека используются все наиболее распространенные протоколы Ethernet, Token Ring, FDDI и другие. На верхних уровнях работают протоколы NetBEUI и SMB.

    Протокол NetBIOS (Network Basic Input/Output System) появился в 1984 году как сетевое расширение стандартных функций базовой системы ввода/вывода (BIOS) IBM PC для сетевой программы PC Network фирмы IBM. В дальнейшем этот протокол был заменен так называемым протоколом расширенного пользовательского интерфейса NetBEUI - NetBIOS Extended User Interface. Для обеспечения совместимости приложений в качестве интерфейса к протоколу NetBEUI был сохранен интерфейс NetBIOS. Протокол NetBEUI разрабатывался как эффективный протокол, потребляющий немного ресурсов и предназначенный для сетей, насчитывающих не более 200 рабочих станций. Этот протокол содержит много полезных сетевых функций, которые можно отнести к сетевому, транспортному и сеансовому уровням модели OSI, однако с его помощью невозможна маршрутизация пакетов. Это ограничивает применение протокола NetBEUI локальными сетями, не разделенными на подсети, и делает невозможным его использование в составных сетях. Некоторые ограничения NetBEUI снимаются реализацией этого протокола NBF (NetBEUI Frame), которая включена в операционную систему Microsoft Windows NT.

    Протокол SMB (Server Message Block) выполняет функции сеансового, представительного и прикладного уровней. На основе SMB реализуется файловая служба, а также службы печати и передачи сообщений между приложениями.

    Стеки протоколов SNA фирмы IBM, DECnet корпорации Digital Equipment и AppleTalk/AFP фирмы Apple применяются в основном в операционных системах и сетевом оборудовании этих фирм.

    На рис. 3.4.3 показано соответствие некоторых, наиболее популярных протоколов уровням модели OSI. Часто это соответствие весьма условно, так как модель OSI - это только руководство к действию, причем достаточно общее, а конкретные протоколы разрабатывались для решения специфических задач, причем многие из них появились до разработки модели OSI. В большинстве случаев разработчики стеков отдавали предпочтение скорости работы сети в ущерб модульности - ни один стек, кроме стека OSI, не разбит на семь уровней. Чаще всего в стеке явно выделяются 3-4 уровня: уровень сетевых адаптеров, в котором реализуются протоколы физического и канального уровней, сетевой уровень, транспортный уровень и уровень служб, вбирающий в себя функции сеансового, представительного и прикладного уровней.

    Реализация межсетевого взаимодействия средствами TCP/IP

    В настоящее время стек TCP/IP является самым популярным средством организации составных сетей. На рис. 3.4.4 показана доля, которую составляет тот или иной стек протоколов в общемировой инсталляционной сетевой базе. До 1996 года бесспорным лидером был стек IPX/SPX компании Novell, но затем картина резко изменилась - стек TCP/IP по темпам роста числа установок намного стал опережать другие стеки, а с 1998 года вышел в лидеры и в абсолютном выражении. Именно поэтому дальнейшее изучение функций сетевого уровня будет проводиться на примере стека TCP/IP.

    В стеке TCP/IP определены 4 уровня (рис. 3.4.5). Каждый из этих уровней несет на себе некоторую нагрузку по решению основной задачи - организации надежной и производительной работы составной сети, части которой построены на основе разных сетевых технологий.

    Таблица 3.4.1. Многоуровневая архитектура стека TCP/IP

    Уровень 1 Прикладной уровень
    Уровень 2 Основной (транспортный) уровень
    Уровень 3
    Уровень 4 Уровень сетевых интерфейсов

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

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

    Основным протоколом сетевого уровня (в терминах модели OSI) в стеке является протокол IP (Internet Protocol). Этот протокол изначально проектировался как протокол передачи пакетов в составных сетях, состоящих из большого количества локальных сетей, объединенных как локальными, так и глобальными связями. Поэтому протокол IP хорошо работает в сетях со сложной топологией, рационально используя наличие в них подсистем и экономно расходуя пропускную способность низкоскоростных линий связи. Так как протокол IP является дейтаграммным протоколом, он не гарантирует доставку пакетов до узла назначения, но старается это сделать.

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

    Основной уровень

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

    На этом уровне функционируют протокол управления передачей TCP (Transmission Control Protocol) и протокол дейтаграмм пользователя UDP (User Datagram Protocol). Протокол TCP обеспечивает надежную передачу сообщений между удаленными прикладными процессами за счет образования логических соединений. Этот протокол позволяет равноранговым объектам на компьютере-отправителе и компьютере-получателе поддерживать обмен данными в дуплексном режиме. TCP позволяет без ошибок доставить сформированный на одном из компьютеров поток байт в любой другой компьютер, входящий в составную сеть. TCP делит поток байт на части - сегменты и передает их ниже лежащему уровню межсетевого взаимодействия. После того как эти сегменты будут доставлены средствами уровня межсетевого взаимодействия в пункт назначения, протокол TCP снова соберет их в непрерывный поток байт.

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

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

    Прикладной уровень объединяет все службы, предоставляемые системой пользовательским приложениям. За долгие годы использования в сетях различных стран и организаций стек TCP/IP накопил большое количество протоколов и служб прикладного уровня. Прикладной уровень реализуется программными системами, построенными в архитектуре клиент-сервер, базирующимися на протоколах нижних уровней. В отличие от протоколов остальных трех уровней, протоколы прикладного уровня занимаются деталями конкретного приложения и "не интересуются" способами передачи данных по сети. Этот уровень постоянно расширяется за счет присоединения к старым, прошедшим многолетнюю эксплуатацию сетевым службам типа Telnet, FTP, TFTP, DNS, SNMP сравнительно новых служб таких, например, как протокол передачи гипертекстовой информации HTTP.

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

    Идеологическим отличием архитектуры стека TCP/IP от многоуровневой организации других стеков является интерпретация функций самого нижнего уровня - уровня сетевых интерфейсов. Протоколы этого уровня должны обеспечивать интеграцию в составную сеть других сетей, причем задача ставится так: сеть TCP/IP должна иметь средства включения в себя любой другой сети, какую бы внутреннюю технологию передачи данных эта сеть не использовала. Отсюда следует, что этот уровень нельзя определить раз и навсегда. Для каждой технологии, включаемой в составную сеть подсети, должны быть разработаны собственные интерфейсные средства. К таким интерфейсным средствам относятся протоколы инкапсуляции IP-пакетов уровня межсетевого взаимодействия в кадры локальных технологий. Например, документ RFC 1042 определяет способы инкапсуляции IP-пакетов в кадры технологий IEEE 802. Для этих целей должен использоваться заголовок LLC/ SNAP, причем в поле Туре заголовка SNAP должен быть указан код 0x0800. Только для протокола Ethernet в RFC 1042 сделано исключение - помимо заголовка LLC/ SNAP разрешается использовать кадр Ethernet DIX, не имеющий заголовка LLC, зато имеющий поле Туре. В сетях Ethernet предпочтительным является инкапсуляция IP-пакета в кадр Ethernet DIX.

    Уровень сетевых интерфейсов в протоколах TCP/IP не регламентируется, но он поддерживает все популярные стандарты физического и канального уровней: для локальных сетей это Ethernet, Token Ring, FDDI, Fast Ethernet, Gigabit Ethernet, 100VG-AnyLAN, для глобальных сетей - протоколы соединений "точка-точка" SLIP и РРР, протоколы территориальных сетей с коммутацией пакетов Х.25, frame relay. Разработана также специальная спецификация, определяющая использование технологии ATM в качестве транспорта канального уровня. Обычно при появлении новой технологии локальных или глобальных сетей она быстро включается в стек TCP/IP за счет разработки соответствующего RFC, определяющего метод инкапсуляции IP-пакетов в ее кадры (спецификация RFC 1577, определяющая работу IP через сети ATM, появилась в 1994 году вскоре после принятия основных стандартов этой технологии).

    Соответствие уровней стека TCP/IP семиуровневой модели ISO/OSI

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

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

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

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

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

    Протокол TCP нарезает из потока данных сегменты.

    Единицу данных протокола UDP часто называют дейтаграммой (или датаграм-мой). Дейтаграмма - это общее название для единиц данных, которыми оперируют протоколы без установления соединений. К таким протоколам относится и протокол межсетевого взаимодействия IP.

    Дейтаграмму протокола IP называют также пакетом.

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

    Выводы по теме

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

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

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

      Важнейшим направлением стандартизации в области вычислительных сетей является стандартизация коммуникационных протоколов. Наиболее популярными являются стеки: TCP/IP, IPX/SPX, NetBIOS/SMB, DECnet, SNA и OSI.

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

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

      а) прикладной;

      б) транспортный;

      в) сетевой.

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

      Прикладной уровень объединяет все службы, предоставляемые системой пользовательским приложениям: традиционные сетевые службы типа telnet, FTP, TFTP, DNS, SNMP, а также сравнительно новые, такие, например, как протокол передачи гипертекстовой информации HTTP.

      На основном уровне стека TCP/IP, называемом также транспортным, функционируют протоколы TCP и UDP. Протокол управления передачей TCP решает задачу обеспечения надежной информационной связи между двумя конечными узлами. Дейтаграммный протокол UDP используется как экономичное средство связи уровня межсетевого взаимодействия с прикладным уровнем.

      Уровень межсетевого взаимодействия реализует концепцию коммутации пакетов в режиме без установления соединений. Основными протоколами этого уровня являются дейтаграммный протокол IP и протоколы маршрутизации (RIP, OSPF, BGP и др.). Вспомогательную роль выполняют протокол межсетевых управляющих сообщений ICMP, протокол группового управления IGMP и протокол разрешения адресов ARP.

      Протоколы уровня сетевых интерфейсов обеспечивают интеграцию в составную сеть других сетей. Этот уровень не регламентируется, но поддерживает все популярные стандарты физического и канального уровней: для локальных сетей - Ethernet, Token Ring, FDDI и т. д., для глобальных сетей - Х.25, frame relay, PPP, ISDN и т. д.

      В стеке TCP/IP для именования единиц передаваемых данных на разных уровнях используют разные названия: поток, сегмент, дейтаграмма, пакет, кадр.


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

    • DNS - распределенная система доменных имен, которая по запросу, содержащему доменное имя хоста сообщает IP адрес;
    • HTTP - протокол передачи гипертекста в Интернет;
    • HTTPS - расширение протокола HTTP, поддерживающее шифрование;
    • FTP (File Transfer Protocol - RFC 959) - протокол, предназначенный для передачи файлов в компьютерных сетях;
    • Telnet (TELecommunication NETwork - RFC 854) - сетевой протокол для реализации текстового интерфейса по сети;
    • SSH (Secure Shell - RFC 4251) - протокол прикладного, позволяющий производить удаленное управление операционной системой и передачу файлов. В отличие от Telnet шифрует весь трафик;
    • POP3 – протокол почтового клиента, который используется почтовым клиентом для получения сообщений электронной почты с сервера;
    • IMAP - протокол доступа к электронной почте в Интернет;
    • SMTP – протокол, который используется для отправки почты от пользователей к серверам и между серверами для дальнейшей пересылки к получателю;
    • LDAP - протокол для доступа к службе каталогов X.500, является широко используемым стандартом доступа к службам каталогов;
    • XMPP (Jabber) - основанный на XML расширяемый протокол для мгновенного обмена сообщениями в почти реальном времени;
    • SNMP - базовый протокол управления сети Internet.

    Рассмотрим более подробно некоторые из этих протоколов.

    FTP позволяет подключаться к серверам FTP, просматривать содержимое каталогов и загружать файлы с сервера или на сервер; кроме того, возможен режим передачи файлов между серверам; FTP позволяет обмениваться файлами и выполнять операции над ними через TCP-сети. Данный протокол работает независимо от операционных систем. Исторически протокол FTP предложил открытую функциональность, обеспечивая прозрачный перенос файлов с одного компьютера на другой по сети. Это не так тривиально, как может показаться, так как у разнотипных компьютеров могут различаться размеры слов, биты в словах могут храниться в неодинаковом порядке или использоваться разные форматы слов.

    1. Telnet

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


    Сходен по функциональности с протоколами telnet и rlogin, но, в отличие от них, шифрует весь трафик, включая и передаваемые пароли. SSH-клиенты и SSH-серверы имеются для большинства операционных систем.

    1. Почтовые протоколы .

    Хотя telnet и FTP были (и остаются) полезными, первым приложением, совершившим переворот в сознании пользователей компьютеров сети ARPANET, стала электронная почта. До сети ARPANET существовали системы электронной почты, но все они были однокомпьютерными системами. В 1972 г. Рэй Томлинсон (Ray Tomlinson) из компании BBN написал первый пакет, предоставляющий распределенные почтовые услуги в компьютерной сети из нескольких компьютеров. Уже к 1973 г. исследования управления ARPA показали, что три четверти всего трафика сети ARPANET составляла электронная почта. Польза электронной почты оказалась столь велика, что все больше пользователей стремилось подключиться к сети ARPANET, в результате чего возрастала потребность в добавлении новых узлов и использовании высокоскоростных линий. Таким образом, появилась тенденция, сохраняющаяся и по сей день.

    • POP3 (Post Office Protocol Version 3 - RFC 1939) - протокол, который используется почтовым клиентом для получения сообщений электронной почты с почтового сервера;
    • IMAP (Internet Message Access Protocol - RFC 3501) - протокол доступа к электронной почте. Аналогичен POP3, однако предоставляет пользователю богатые возможности для работы с почтовыми ящиками, находящимися на центральном сервере. Электронными письмами можно манипулировать с компьютера пользователя (клиента) без необходимости постоянной пересылки с сервера и обратно файлов с полным содержанием писем.
    • SMTP (Simple Mail Transfer Protocol - RFC 2821) - протокол, предназначенный для передачи электронной почты. Используется для отправки почты от пользователей к серверам и между серверами для дальнейшей пересылки к получателю. Для приема почты почтовый клиент должен использовать протоколы POP3 или IMAP.

    Базовым протоколом сети гипертекстовых ресурсов Веб является протокол HTTP. В его основу положено взаимодействие "клиент-сервер ", то есть предполагается, что:

    1. Потребитель-клиент инициировав соединение с поставщиком-сервером посылает ему запрос;
    2. Поставщик-сервер , получив запрос, производит необходимые действия и возвращает обратно клиенту ответ с результатом.

    При этом возможны два способа организации работы компьютера-клиента:

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

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



    Есть вопросы?

    Сообщить об опечатке

    Текст, который будет отправлен нашим редакторам: