Практическая работа №4.
Изучение работы протоколов верхнего уровня
Теоретическая часть
Протоколы прикладного уровня обеспечивают взаимодействие между человеком и сетью. Примеры часто используемых протоколов в сети: 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. это версия протокола. Теперь о нижней строчке. Здесь указывается адрес сервера или имя, на котором располагается нужный ресурс.
Давайте посмотрим, как это работает на практике. Запустим программу Cisco Packet Tracer. Добавим туда компьютер с сервером (находятся они на вкладке «End Devices»), как на картинке ниже.
Соединяем компьютер с сервером перекрестным кабелем (англ. crossover cable). В CPT он находится на вкладке «Connections», обозначается пунктиром и называется «Copper Cross-Over». Теперь займемся настройкой компьютера и веб-сервера.
1) Отрываем вкладки «Desktop» на рабочем компьютере и сервере, далее переходим в окно «IP Configuration». Откроются окна, как на рисунке выше. Это окна конфигурации узлов в сети.
2) Укажем IP-адреса в строки, указанные цифрой 2.
3) В поля, указанные цифрой 3, вводится маска подсети. Она нужна для того, чтобы узлу было понятно, в одной подсети он находится с другим узлом или нет. Остальные значения оставим пустыми.
Теперь требуется включить сервис HTTP на сервере.
1) Переходим на вкладку «Services».
2) Выбираем слева сервис HTTP.
3) Открывается окно настройки сервиса и файловый менеджер. Если у кого есть навыки по работе c HTML, то можете здесь создать страницу. Но у нас уже есть готовый шаблон, и мы им воспользуемся. Не забываем включить службу HTTP и HTTPS.
HTTPS (HyperText Transfer Protocol Secure) - э то, по сути, расширение протокола HTTP, которое поддерживает криптографические протоколы и передает информацию не в открытом виде, а в зашифрованном. 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, в браузере он обозначается в виде замка. Например 
.
II) DNS (Domain Name System). Система доменных имен. Она сообщает, какой 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.
Как мы помним, для обмена между узлами недостаточно 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 адреса на месте.
Далее процесс аналогичен работе с протоколом HTTP. В финале по имени «cisadmin.ru» откроется страница, находящаяся на сервере с IP адресом 192.168.1.2.
Утилита nslookup.
Nslookup позволяет обратиться к DNS-серверу и узнать у него информацию о имени или IP-адресе.
Кликаем по компьютеру на схеме и на вкладке «Desktop» выбираем «Command Prompt». Это имитация командной строки.
Введем nslookup и нажмем ENTER.
Открывается сама утилита, о чем свидетельствует знак птички слева. Показывается нам адрес DNS-сервера и его имя. Так как имени нет, то он дублирует туда строку с IP-адресом.
Ну и самое время вписать туда доменное имя и узнать, что он выдаст в ответ.
Выдает он имя и адрес, как и предполагалось. В принципе, когда вы обращаетесь на веб-сайт, он сам выполняет эту процедуру. Вы видели этот запрос выше.
III) DHCP (Dynamic Host Configuration Protocol). Протокол динамической настройки узла. Он позволяет узлам динамически получать IP адреса и другие параметры для корректной работы в сети (основной шлюз, маску подсети, адреса DNS-серверов).
При помощи DHCP можно обеспечить полный контроль над IP адресами: создавать отдельные пулы для каждой подсети, выдавать адреса в аренду, резервировать адреса и многое другое.
Давайте посмотрим, как он работает на практике.
И видим, что добавился новый сервер. Конечно можно было все роли отдать одному серверу, но, чтобы вы понимали, как ходят данные, пусть для каждой роли будет отдельный сервер.
Настроим сервер.
Присваиваем свободный адрес и маску.
Перейдем к роли DHCP.
1) Выбираем службу DHCP, и тут уже создан стандартный пул. Его удалить нельзя. Только изменить.
Пул IP-адресов – этодиапазон IP-адресов, из которого назначаются IP-адреса пользователям при их создании.
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-сервер перед выдачей этого адреса, отправляет ICMP сообщение или ping.
Если на ping DHCP-серверу кто-то ответит, то значит адрес занят и всю процедуру он будет повторять, но с другим IP-адресом. Но это тоже не самое толковое решение. Если компьютер со статически назначенным адресом будет выключен, то он не ответит на ping DHCP-сервера, и, соответственно, DHCP решит, что адрес не занят и присвоит его какому-то узлу. Но, как только компьютер включится, появится 2 компьютера с одинаковыми IP-адресами.
Конечный итог, который сформирует 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». Что означает, что данные успешно получены, о чем свидетельствуют заполненные поля ниже.
IV) POP3 (англ. Post Office Protocol Version 3). Протокол почтового отделения версии 3. Протокол, который используют клиенты для получения почтовых писем с сервера. Версии 1-ая и 2-ая устарели и в нынешнее время не используются. Работает он по принципу «загрузи и удали». Это значит, что клиент заходит на сервер и смотрит, есть ли для него письмо. И если оно присутствует, он загружает его к себе и ставит отметку об удалении на сервере. Порт, который он прослушивает — 110. Довольно известный номер порта, поэтому возьмите себе на заметку. Так же как и у протокола HTTP, у него есть расширенная версия — POP3S. При помощи дополнительного криптографического протокола, как SSL, шифруется содержимое, и письма передаются в защищенном виде. Аналог POP3 - протокол IMAP (англ. Internet Message Access Protocol). Протокол доступа к электронной почте. Главное их различие в том, что клиент, заходя на сервер, не удаляет почту, а копирует ее. Таким образом, у клиента отображается копия почтового ящика, который хранится на почтовом сервере. И если клиент у себя удаляет какое-либо письмо, то оно удаляется только у него. На сервере оригинал остается целым. Слушает он 143 порт.
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» пишем почтовый ящик. Для директора — это director@cisadmin.ru.
3) В поля «Incoming Mail Server» и «Outgoing Mail Server» записываем адрес почтового сервера (192.168.1.4)
4) В поле «User Name» пишем сам логин. То есть Director и соответственно пароль 123.
Нажимаем кнопку «Save», и перед нами открывается почтовый клиент. CPT назвал его почтовым обозревателем.
Аналогичная настройка будет на компьютере рабочего. Привожу скрин.
Теперь самое время посмотреть, как работает почта. Давайте сначала посмотрим, как она работает в режиме реального времени, а после разберем подробнее в режиме симуляции.
Открываем почтовый клиент на компьютере директора и создадим письмо.
Жмем на кнопу «Compose», и перед нами открывается привычное окно.
Здесь все как обычно. Пишем кому отправляем, тему письма, сам текст письма и нажимаем кнопку «Send».
Видим следующее сообщение о том, что отправка завершена успешно. Замечательно! Теперь посмотрим, как письмо будет доставлено рабочему.
Открываем почтовый клиент на компьютере рабочего.
И видим, что письма нет. А все потому, что клиент в CPT не поддерживает автоматическое обновление и приходится это делать вручную. Нажимаем кнопку «Receive».
Видим появившееся письмо и сообщение об успешном получении. Откроем письмо и посмотрим, не побилось ли.
И да, письмо, действительно, дошло целым и невредимым. Ответим на это письмо и заодно проверим, что письма ходят в обе стороны. Нажимаем кнопку «Reply» и пишем ответ.
Отправляем письмо и переходим к компьютеру директора. И, соответственно, жмем кнопку «Receive», чтобы обновить почту.
Появилось письмо, а ниже и сообщение об успешном получении.
Открываем письмо, чтобы до конца удостовериться.
Письмо дошло, а значит все работает.
Давайте разберем поподробнее. Переключим среду в режим симуляции и отправим письмо. Не буду я создавать что-то новое, а просто отвечу на выше полученное письмо.
Все почтовые протоколы работают с TCP. А это значит, что перед тем, как начнет работать почтовый протокол, а в данном случае протокол SMTP, должно установиться предварительное соединение между компьютером и сервером. Это мы сейчас и наблюдаем.
Сейчас процесс установления соединения нас мало интересует. Мы сейчас говорим про почтовые протоколы, и поэтому я пропущу этот процесс и буду ждать появления SMTP.
1) Появился долгожданный SMTP, о чем свидетельствует запись в панели симуляции, и откроем их. Обратим внимания на TCP-порты, чтобы удостовериться, что это он. И видим, что в «Destination Port» стоит 25 номер. А в «Source Port» записан динамически придуманный порт, чтобы сервер мог идентифицировать клиента. Все правильно.
2) Смотрим ниже на данные SMTP, и здесь нет ничего интересного. CPT показывает нам его, как обычный блок данных.
Дальше он передает эти данные серверу. Посмотрим, что будет происходить дальше.
Сервер, получив данные от компьютера, формирует ответное сообщение. Обратите внимание на изменения. Номера, которые присутствовали ранее, поменялись местами, а именно «Source Port» и «Destination Port». Теперь источником является сервер, а назначением — компьютер. Это сообщение о доставке письма серверу.
После этого работа протокола SMTP закончена, и компьютер может начать закрывать TCP-сессию. Чем он и займется.
Теперь когда письмо отправлено, и мы знаем, что оно лежит на сервере, попробуем получить это письмо. Открываем компьютер рабочего и жмем кнопку «Receive».
Как и с SMTP, в POP3 тоже создается TCP-сессия. Посмотрим на номера портов. В «Destination Port» стоит 110 номер порта. Это и есть стандартный номер порта для протокола POP3. В «Source Port» стоит порт 1028.
Смотрим дальше и ждем выхода POP3.
Вот он появился и наблюдаем, что в поле POP3 такая же картина, что и в SMTP, т.е. все то, что и так было понятно. Дальше он отправляет этот запрос на сервер, и сервер должен ответить письмом, если оно там есть.
Мы знаем, что оно там есть и наблюдаем, как сервер формирует ответное сообщение. И также как с SMTP, он меняет местами порты отправления и назначения. На прикладном уровне запакованы какие-то POP3 данные. Это и есть само письмо.
Как только данные попадут на компьютер, они сразу должны высветиться в почтовом клиенте.
И как только данные получены, о чем здесь свидетельствует галочка на фиолетовом пакете, письмо сразу же высвечивается в клиенте. Дальше, как и в SMTP, будет закрытие TCP-сессии.
Порядок выполнения и сдачи работы
- Изучить теоретическую и практическую часть.
- Выполнить в PacketTracer практическую часть по варианту: Подробно пояснить и продемонстрировать работу протокола.
| № вар. | Протокол |
| HTTP | |
| DNS | |
| SMTP | |
| HTTP | |
| DNS | |
| SMTP | |
| HTTP | |
| DNS | |
| SMTP | |
| HTTP | |
| DNS | |
| SMTP | |
| HTTP | |
| DNS | |
| SMTP | |
| HTTP | |
| DNS | |
| SMTP | |
| HTTP | |
| DNS |
3. Сдать преподавателю теорию работы путём ответа на контрольные вопросы.
Контрольные вопросы