• Стеки протоколов
• Протоколы канального уровня
• Протоколы межсетевого уровня
• Транспортные протоколы
• Прикладные протоколы

Как уже упоминалось ранее, в локальных сетях могут совместно работать компьютеры разных производителей, оснащенные различным набором устройств и обладающие несхожими техническими характеристиками. На практике это означает, что для обеспечения нормального взаимодействия этих компьютеров необходим некий единый унифицированный стандарт, строго определяющий алгоритм передачи данных в распределенной вычислительной системе. В современных локальных сетях, или, как их принято называть в англоязычных странах, LAN (Local Area Network), роль такого стандарта выполняют сетевые протоколы.
Итак, сетевым протоколом, или протоколом передачи данных, называется согласованный и утвержденный стандарт, содержащий описание правил приема и передачи между несколькими компьютерами команд, файлов, иных данных, и служащий для синхронизации работы вычислительных машин в сети.
Прежде всего следует понимать, что в локальных сетях передача информации осуществляется не только между компьютерами как физическими устройствами, но и между приложениями, обеспечивающими коммуникации на программном уровне. Причем под такими приложениями можно понимать как компоненты операционной системы, организующие взаимодействие с различными устройствами компьютера, так и клиентские приложения, обеспечивающие интерфейс с пользователем. Таким образом, мы постепенно приходим к пониманию многоуровневой структуры сетевых коммуникаций - как минимум, с одной стороны мы имеем дело с аппаратной конфигурацией сети, с другой стороны - с программной.
Вместе с тем передача информации между несколькими сетевыми компьютерами - не такая уж простая задача, как это может показаться на первый взгляд. Для того чтобы понять это, достаточно представить себе тот круг проблем, который может возникнуть в процессе приема или трансляции каких-либо данных. В числе таких «неприятностей» можно перечислить аппаратный сбой либо выход из строя одного из обеспечивающих связь устройств, например, сетевой карты или концентратора, сбой прикладного или системного программного обеспечения, возникновение ошибки в самих передаваемых данных, потерю части транслируемой информации или ее искажение. Отсюда следует, что в локальной сети необходимо обеспечить жесткий контроль для отслеживания всех этих ошибок, и более того, организовать четкую работу как аппаратных, так и программных компонентов сети. Возложить все эти задачи на один-единственный протокол практически невозможно. Как быть?
Выход нашелся в разделении протоколов на ряд концептуальных уровней, каждый из которых обеспечивает интерфейс между различными модулями программного обеспечения, установленного на работающих в сети компьютерах. Таким образом, механизм передачи какого-либо пакета информации через сеть от клиентской программы, работающей на о/щом компьютере, клиентской программе, работающей на другом компьютере, можно условно представить в виде последовательной пересылки этого пакета сверху вниз от некоего протокола верхнего уровня, обеспечивающего взаимодействие с пользовательским приложением, протоколу нижнего уровня, организующему интерфейс с сетью, его трансляции на компьютер-получатель и обратной передачи протоколу верхнего уровня уже на удаленной машине (рис. 2.1).

Рис. 2.1. Концептуальная модель многоуровневой системы протоколов

Согласно такой схеме, каждый из уровней подобной системы обеспечивает собственный набор функций при передаче информации по локальной сети.
Например, можно предположить, что протокол верхнего уровня, осуществляющий непосредственное взаимодействие с клиентскими программами, транслирует данные протоколу более низкого уровня, «отвечающему» за работу с аппаратными устройствами сети, преобразовывая их в «понятную» для него форму. Тот, в свою очередь, передает их протоколу, осуществляющему непосредственно пересылку информации на другой компьютер. На удаленном компьютере прием данных осуществляет аналогичный протокол «нижнего» уровня и контролирует корректность принятых данных, то есть определяет, следует ли транслировать их протоколу, расположенному выше в иерархической структуре, либо запросить повторную передачу. В этом случае взаимодействие осуществляется только между протоколами нижнего уровня, верхние уровни иерархии в данном процессе не задействованы. В случае если информация была передана без искажений, она транслируется вверх через соседние уровни протоколов до тех пор, пока не достигнет программы-получателя. При этом каждый из уровней не только контролирует правильность трансляции данных на основе анализа содержимого пакета информации, но и определяет дальнейшие действия исходя из сведений о его назначении. Например, один из уровней «отвечает» за выбор устройства, с которого осуществляется получение и через которое передаются данные в сеть, другой «решает», передавать ли информацию дальше по сети, или она предназначена именно этому компьютеру, третий «выбирает» программу, которой адресована принятая информация. Подобный иерархический подход позволяет не только разделить функции между различными модулями сетевого программного обеспечения, что значительно облегчает контроль работы всей системы в целом, но и дает возможность производить коррекцию ошибок на том уровне иерархии, на котором они возникли. Каждую из подобных иерархических систем, включающих определенный набор протоколов различного уровня, принято называть стеком протоколов.
Вполне очевидно, что между теорией и практикой, то есть между концептуальной моделью стека протоколов и его практической реализацией существует значительная разница. На практике принято несколько различных вариантов дробления стека протоколов на функциональные уровни, каждый из которых выполняет свой круг задач. Мы остановимся на одном из этих вариантов, который представляется наиболее универсальным. Данная схема включает четыре функциональных уровня, и так же, как и предыдущая диаграмма, описывает не конкретный механизм работы какого-либо стека протоколов, а общую модель, которая поможет лучше понять принцип действия подобных систем (рис. 2.2).
Самый верхний в иерархической системе, прикладной уровень стека протоколов обеспечивает интерфейс с программным обеспечением, организующим
работу пользователя в сети. При запуске любой программы, для функционирования которой требуется диалог с сетью, эта программа вызывает соответствующий протокол прикладного уровня. Данный протокол передает программе информацию из сети в доступном для обработки формате, то есть в виде системных сообщений либо в виде потока байтов. В точности таким же образом пользовательские приложения могут получать потоки данных и управляющие сообщения - как от самой операционной системы, так и от других запущенных на компьютере программ. То есть, обобщая, можно сказать, что протокол прикладного уровня выступает в роли своего рода посредника между сетью и программным обеспечением, преобразуя транслируемую через сеть информацию в «понятную» программе-получателю форму.

Рис. 2.2. Модель реализации стека протоколов

Основная задача протоколов транспортного уровня заключается в осуществлении контроля правильности передачи данных, а также в обеспечении взаимодействия между различными сетевыми приложениями. В частности, получая входящий поток данных, протокол транспортного уровня дробит его на отдельные фрагменты, называемые пакетами, записывает в каждый пакет некоторую дополнительную информацию, например идентификатор программы, для которой предназначены передаваемые данные, и контрольную сумму, необходимую для проверки целостности пакета, и направляет их на смежный уровень для дальнейшей обработки. Помимо этого протоколы транспортного уровня осуществляют управление передачей информации - например, могут запросить у получателя подтверждение доставки пакета и повторно выслать утерянные фрагменты транслируемой последовательности данных. Некоторое недоумение может вызвать то обстоятельство, что протоколы транспортного уровня так же, как и протоколы прикладного уровня, взаимодействуют с сетевыми программами и координируют передачу данных между ними. Эту ситуацию можно прояснить на следующем примере: предположим, на подключенном к сети компьютере запущен почтовый клиент, эксплуатирующий два различных протокола прикладного уровня - РОРЗ (Post Office Protocol) и SMTP (Simple Mail Transfer Protocol) - и программа загрузки файлов на удаленный сервер - FTP-клиент, работающий с протоколом прикладного уровня FTP (File Transfer Protocol). Все эти протоколы прикладного уровня опираются на один и тот же протокол транспортного уровня - TCP/IP (Transmission Control Protocol/Internet Protocol), который, получая поток данных от вышеуказанных программ, преобразует их в пакеты данных, где присутствует указание на конечное приложение, использующее эту информацию. Из рассмотренного нами примера следует, что данные, приходящие из сети, могут иметь различное назначение, и, соответственно, они обрабатываются различными программами, либо различными модулями одного и того же приложения. Во избежание путаницы при приеме и обработке информации каждая взаимодействующая с сетью программа имеет собственный идентификатор, который позволяет транспортному протоколу направлять данные именно тому приложению, для которого они предназначены. Такие идентификаторы носят название программных портов. В частности, протокол прикладного уровня SMTP, предназначенный для отправки сообщений электронной почты, работает обычно с портом 25, протокол входящей почты РОРЗ - с портом 110, протокол Telnet - с портом 23. Задача перенаправления потоков данных между программными портами лежит па транспортных протоколах.
На межсетевом уровне реализуется взаимодействие конкретных компьютеров распределенной вычислительной системы, другими словами, осуществляется процесс определения маршрута движения информации внутри локальной сети и выполняется отправка этой информации конкретному адресату. Данный процесс принято называть маршрутизацией. Получая пакет данных от протокола транспортного уровня вместе с запросом на его передачу и указанием получателя, протокол межсетевого уровня выясняет, на какой компьютер следует передать информацию, находится ли этот компьютер в пределах данного сегмента локальной сети или на пути к нему расположен шлюз, после чего трансформирует пакет в дейтаграмму - специальный фрагмент информации, передаваемый через сеть независимо от других аналогичных фрагментов, без образования виртуального канала (специально сконфигурированной среды для двустороннего обмена данными между несколькими устройствами) и подтверждения приема. В заголовок дейтаграммы записывается адрес компьютера-получателя пересылаемых данных и сведения о маршруте следования дейтаграммы. После чего она передается на канальный уровень.

ПРИМЕЧАНИЕ
Шлюз - это программа, при помощи которой можно передавать информацию между двумя сетевыми системами, использующими различные протоколы обмена данными.

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

Протоколы канального уровня

Протоколы, обеспечивающие взаимодействие компьютера с сетью на самом низком, аппаратном уровне, во многом определяют топологию локальной сети, а также ее внутреннюю архитектуру. В настоящее время на практике достаточно часто применяется несколько различных стандартов построения локальных сетей, наиболее распространенными среди которых являются технологии Ethernet, Token Ring, Fiber Distributed Data Interface (FDDI) и ArcNet.
На сегодняшний день локальные сети, построенные на основе стандарта Ethernet, являются наиболее популярными как в нашей стране, так и во всем мире. На долю сетей Ethernet приходится почти девяносто процентов всех малых и домашних локальных сетей, что не удивительно, поскольку именно эта технология позволяет строить простые и удобные в эксплуатации и настройке локальные сети с минимумом затрат. Именно поэтому в качестве основного рассматриваемого нами стандарта будет принята именно технология Ethernet. Протоколы канального уровня поддержки Ethernet, как правило, встроены в оборудование, обеспечивающее подключение компьютера к локальной сети на физическом уровне. Стандарт Ethernet является широковещательным, то есть каждый подключенный к сети компьютер принимает всю следующую через его сетевой сегмент информацию - как предназначенную именно для этого компьютера, так и данные, направляемые на другую машину. Во всех сетях Ethernet применяется один и тот же алгоритм разделения среды передачи информации - множественный доступ с контролем несущей и обнаружением конфликтов (Carrier Sense Multiple Access with Collision Detection, CSMA/CD).
В рамках технологии Ethernet сегодня различается несколько стандартов организации сетевых коммуникаций, определяющих пропускную способность канала связи и максимально допустимую длину одного сегмента сети, то есть расстояние между двумя подключенными к сети устройствами. Об этих стандартах мы побеседуем в следующей главе, посвященной изучению сетевого оборудования, пока же необходимо отметить, что в рамках стандарта Ethernet применяется, как правило, одна из двух различных топологий: конфигурация сети с общей шиной или звездообразная архитектура.

Протоколы межсетевого уровня

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

Протокол IP

Протокол IP (Internet Protocol) используется как в глобальных распределенных системах, например в сети Интернет, так и в локальных сетях. Впервые протокол IP применялся еще в сети ArpaNet, являвшейся предтечей современного Интернета, и с тех пор он уверенно удерживает позиции в качестве одного из наиболее распространенных и популярных протоколов межсетевого уровня.
Поскольку межсетевой протокол IP является универсальным стандартом, он нередко применяется в так называемых составных сетях, то есть сетях, использующих различные технологии передачи данных и соединяемых между собой посредством шлюзов. Этот же протокол «отвечает» за адресацию при передаче информации в сети. Как осуществляется эта адресация?
Каждый человек, живущий на Земле, имеет адрес, по которому его в случае необходимости можно разыскать. Думаю, ни у кого не вызовет удивления то, что каждая работающая в Интернете или локальной сети машина также имеет свой уникальный адрес. Адреса в компьютерных сетях разительно отличаются от привычных нам почтовых. Боюсь, совершенно бесполезно писать на отправляемом вами в Сеть пакете информации нечто вроде «Компьютеру Intel Pentium III 1300 Mhz, эсквайру, Пэнии-Лэйн 114, Ливерпуль, Англия». Увидев такую надпись, ваша персоналка в лучшем случае фундаментально зависнет. Но если вы укажете компьютеру в качестве адреса нечто вроде 195.85.102.14, машина вас прекрасно поймет.
Именно стандарт IP подразумевает подобную запись адресов подключенных к сети компьютеров. Такая запись носит название IP-адрес.
Из приведенного примера видно, что IP-адрес состоит из четырех десятичных идентификаторов, или октетов, по одному байту каждый, разделенных точкой. Левый октет указывает тип локальной интрасети (под термином «интрасеть» (intranet) здесь понимается частная корпоративная или домашняя локальная сеть, имеющая подключение к Интернету), в которой находится искомый компьютер. В рамках данного стандарта различается несколько подвидов интрасетей, определяемых значением первого октета. Это значение характеризует максимально возможное количество подсетей и узлов, которые может включать такая сеть. В табл. 2.1 приведено соответствие классов сетей значению первого октета IP-адреса.

Таблица 2.1. Соответствие классов сетей значению первого октета IP-адреса

Адреса класса А используются в крупных сетях общего пользования, поскольку позволяют создавать системы с большим количеством узлов. Адреса класса В, как правило, применяют в корпоративных сетях средних размеров, адреса класса С - в локальных сетях небольших предприятий. Для обращения к группам машин предназначены широковещательные адреса класса D, адреса класса Е пока не используются: предполагается, что со временем они будут задействованы с целью расширения стандарта. Значение первого октета 127 зарезервировано для служебных целей, в основном для тестирования сетевого оборудования, поскольку IP-пакеты, направленные на такой адрес, не передаются в сеть, а ретранслируются обратно управляющей надстройке сетевого программного обеспечения как только что принятые. Кроме того, существует набор так называемых «выделенных» IP-адресов, имеющих особое значение. Эти адреса приведены в табл. 2.2.

Таблица 2.2. Значение выделенных IP-адресов

ПРИМЕЧАНИЕ
Хостом принято называть любой подключенный к Интернету компьютер независимо от его назначения.

Как уже упоминалось ранее, небольшие локальные сети могут соединяться между собой, образуя более сложные и разветвленные структуры. Например, локальная сеть предприятия может состоять из сети административного корпуса и сети производственного отдела, сеть административного корпуса, в свою очередь, может включать в себя сеть бухгалтерии, планово-экономического отдела и отдела маркетинга. В приведенном выше примере сеть более низкого уровня является подсетью системы более высокого уровня, то есть локальная сеть бухгалтерии - подсеть для сети административного корпуса, а та, в свою очередь, - подсеть для сети всего предприятия в целом.
Однако вернемся к изучению структуры IP-адреса. Последний (правый) идентификатор IP-адреса обозначает номер компьютера в данной локальной сети. Все, что расположено между правым и левым октетами в такой записи, - номера подсетей более низкого уровня. Непонятно? Давайте разберем на примере. Положим, мы имеем некий адрес в Интернете, на который хотим отправить пакет с набором свеженьких анекдотов. В качестве примера возьмем тот же IP-адрес- 195.85.102.14. Итак, мы отправляем пакет в 195-ю подсеть сети Интернет, которая, как видно из значения первого октета, относится к классу С. Допустим, 195-я сеть включает в себя еще 902 подсети, но наш пакет высылается в 85-ю. Она содержит 250 подсетей
более низкого порядка, но нам нужна 102-я. Ну и, наконец, к 102-й сети подключено 40 компьютеров. Исходя из рассматриваемого нами адреса, подборку анекдотов получит машина, имеющая в этой сетевой системе номер 14. Из всего сказанного выше становится очевидно, что IP-адрес каждого компьютера, работающего как в локальной сети, так и в глобальных вычислительных системах, должен быть уникален.
Централизованным распределением IP-адресов в локальных сетях занимается государственная организация - Стенфордский международный научно-исследовательский институт (Stanford Research Institute, SRI International), расположенный в самом сердце Силиконовой долины - городе Мэнло-Парк, штат Калифорния, США. Услуга по присвоению новой локальной сети IP-адресов бесплатная, и занимает она приблизительно неделю. Связаться с данной организацией можно по адресу SRI International, Room EJ210, 333 Ravenswood Avenue, Menlo Park, California 94025, USA, no телефону в США 1-800-235-3155 или по адресу электронной почты, который можно найти на сайте http://www.sri.com. Однако большинство администраторов небольших локальных сетей, насчитывающих 5-10 компьютеров, назначают IP-адреса подключенным к сети машинам самостоятельно, исходя из описанных выше правил адресации в IP-сетях. Тацой подход вполне имеет право на жизнь, но вместе с тем произвольное назначение IP-адресов может стать проблемой, если в будущем такая сеть будет соединена с другими локальными сетями или в ней будет организовано прямое подключение к Интернету. В данном случае случайное совпадение нескольких IP-адресов может привести к весьма неприятным последствиям, например к ошибкам в маршрутизации передаваемых по сети данных или отказу в работе всей сети в целом.
Небольшие локальные сети, насчитывающие ограниченное количество компьютеров, должны запрашивать для регистрации адреса класса С. При этом каждой из таких сетей назначаются только два первых октета IP-адреса, например 197.112.Х.Х, на практике это означает, что администратор данной сети может создавать подсети и назначать номера узлов в рамках каждой из них произвольно, исходя из собственных потребностей.
Большие локальные сети, использующие в качестве базового межсетевой протокол IP, нередко применяют чрезвычайно удобный способ структуризации всей сетевой системы путем разделения общей IP-сети на подсети. Например, если вся сеть предприятия состоит из ряда объединенных вместе локальных сетей Ethernet, то в ней может быть выделено несколько структурных составляющих, то есть подсетей, отличающихся значением третьего октета IP-адреса. Как правило, в качестве каждой из подсетей используется физическая сеть какого-либо отдела фирмы, скажем, сеть Ethernet, объединяющая все компьютеры бухгалтерии. Такой подход, во-первых, позволяет
излишне не расходовать IP-адреса, а во-вторых, предоставляет определенные удобства с точки зрения администрирования: например, администратор может открыть доступ к Интернету только для одной из вверенных ему подсетей или на время отключить одну из подсетей от локальной сети предприятия. Кроме того, в случае если сетевой администратор решит, что третий октет IP-адреса описывает номер подсети, а четвертый - номер узла в ней, то такая информация записывается в локальных таблицах маршрутизации сети вашего предприятия и не видна извне. Другими словами, данный подход обеспечивает большую безопасность.
Для того чтобы программное обеспечение могло автоматически выделять номера конкретных компьютеров из используемых в данной сетевой системе IP-адресов, применяются так называемые маски подсети. Принцип, по которому осуществляется распознавание номеров узлов в составе IP-адреса, достаточно прост: биты маски подсети, обозначающие номер самой IP-сети, должны быть равны единице, а биты, определяющие номер узла, - нулю. Именно поэтому в большинстве локальных IP-сетей класса С в качестве маски подсети принято значение 255.255.255.0: при такой конфигурации в состав общей сети может быть включено до 256 подсетей, в каждой из которых работает до 254 компьютеров. В ряде случаев это значение может изменяться, например, если возникла необходимость использовать в составе сети количество подсетей большее, чем 256, можно использовать маску подсети формата 255.255.255.195. В этой конфигурации сеть может включать до 1024 подсетей, максимальное число компьютеров в каждой из которых не должно превышать 60.
В локальных сетях, работающих под управлением межсетевого протокола IP, помимо обозначения IP-адресов входящих в сеть узлов принято также символьное обозначение компьютеров: например, компьютер с адресом 192.112.85.7 может иметь сетевое имя Localhost. Таблица соответствий IP-адресов символьным именам узлов содержится в специальном файле hosts, хранящемся в одной из системных папок; в частности, в операционной системе Microsoft Windows XP этот файл можно отыскать в папке flKCK:\Windows\system32\drivers\etc\. Синтаксис записи таблицы сопоставлений имен узлов локальной сети IP-адресам достаточно прост: каждый элемент таблицы должен быть расположен в новой строке, IP-адрес располагается в первом столбце, а за ним следует имя компьютера, при этом IP-адрес и имя должны быть разделены как минимум одним пробелом. Каждая из строк таблицы может включать произвольный комментарий, обозначаемый символом #. Пример файла hosts приведен ниже:

192.112.85.7 localhost # этот компьютер
192.112.85.1 server # сервер сети
192.112.85.2 director # компьютер приемной директора
192.112.85.5 admin # компьютер системного администратора

Как правило, файл hosts создается для какой-либо конкретной локальной сети, и его копия хранится на каждом из подключенных к ней компьютеров. В случае, если один из узлов сети имеет несколько IP-адресов, то в таблице соответствий обычно указывается лишь один из них, вне зависимости от того, какой из адресов реально используется. При получении из сети IP-пакета, предназначенного для данного компьютера, протокол IP сверится с таблицей маршрутизации и на основе анализа заголовка IP-пакета автоматически опознает любой из IP-адресов, назначенных данному узлу.
Помимо отдельных узлов сети собственные символьные имена могут иметь также входящие в локальную сеть подсети. Таблица соответствий IP-адресов именам подсетей содержится в файле networks, хранящемся в той же папке, что и файл hosts. Синтаксис записи данной таблицы сопоставлений несколько отличается от предыдущего, и в общем виде выглядит следующим образом: <сетевяе имя> <номер сети> [псевдонимы...] [#<конментарий>]
где сетевое имя - имя, назначенное каждой подсети, номер сети - часть IP-адреса подсети (за исключением номеров более мелких подсетей, входящих в данную подсеть, и номеров узлов), псевдонимы - необязательный параметр, указывающий на возможные синонимы имен подсетей: они используется в случае, если какая-либо подсеть имеет несколько различных символьных имен; и, наконец, комментарий - произвольный комментарий, поясняющий смысл каждой записи. Пример файла networks приведен ниже:

loopback 127
marketing 192.112.85 # отдел маркетинга
buhgalteria 192.112.81 # бухгалтерия
workshop 192.112.80 # сеть производственного цеха
workgroup 192.112.10 localnetwork # основная рабочая группа

Обратите внимание на то обстоятельство, что адреса, начинающиеся на 127, являются зарезервированными для протокола IP, а подсеть с адресом 192.112.10 в нашем примере имеет два символьных имени, используемых совместно.
Файлы hosts и networks не оказывают непосредственного влияния на принципиальный механизм работы протокола IP и используются в основном прикладными программами, однако они существенно облегчают настройку и администрирование локальной сети.

Протокол IPX

Протокол IPX (Internet Packet Exchange) является межсетевым протоколом, используемым в локальных сетях, узлы которых работают под управлением операционных систем семейства Nowell Netware. Данный протокол обеспечивает передачу дейтаграмм в таких сетях без организации логического соединения - постоянного двустороннего обмена данными между двумя узлами сети, которое организуется протоколом транспортного уровня. Разработанный на основе технологий Nowell, этот некогда популярный протокол в силу несовместимости с чрезвычайно распространенным стеком протоколов TCP/IP в настоящее время медленно, но верно утрачивает свои позиции.
Как и межсетевой протокол IP, IPX способен поддерживать широковещательную передачу данных посредством дейтаграмм длиной до 576 байт, 30 из которых занимает заголовок пакета. В сетях IPX используются составные адреса узлов, состоящих из номера сети, адреса узла и адреса прикладной программы, для которой предназначен передаваемый пакет информации, который также носит наименование гнезда или сокета. Для обеспечения обмена данными между несколькими сетевыми приложениями в многозадачной среде на узле, работающем под управлением протокола IPX, должно быть одновременно открыто несколько сокетов.
Поскольку в процессе трансляции данных протокол IPX не запрашивает подтверждения получения дейтаграмм, доставка данных в таких сетях не гарантируется, и потому функции контроля над передачей информации возлагаются на сетевое программное обеспечение. Фактически IPX обеспечивает только инкапсуляцию транслируемых по сети потоков данных в дейтаграммы, их маршрутизацию и передачу пакетов протоколам более высокого уровня.
Протоколам канального уровня IPX передает пакеты данных, имеющие следующую логическую структуру:

• контрольная сумма, предназначенная для определения целостности передаваемого пакета (2 байта);
• указание на длину пакета (2 байта);
• данные управления транспортом (1 байт);
• адрес сети назначения (4 байта);
• адрес узла назначения (6 байт);
• номер сокета назначения (2 байта);
• адрес сети-отправителя (4 байта);
• адрес узла-отправителя (6 байт);
• номер сокета-отправителя (2 байта);
• передаваемая информация (0-546 байт).

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

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

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

Протокол TCP

Протокол IP позволяет только транслировать данные. Для того чтобы управлять этим процессом, служит протокол TCP (Transmission Control Protocol), опирающийся на возможности протокола IP. Как же контролируется передача информации?
Положим, вы хотите переслать по почте вашему другу толстый журнал, не потратив при этом денег на отправку бандероли. Как решить эту проблему, если почта отказывается принимать письма, содержащие больше нескольких бумажных листов? Выход простой: разделить журнал на страницы и отправлять их отдельными письмами. По номерам страниц ваш друг сможет собрать журнал целиком. Приблизительно таким же способом работает протокол TCP. Он дробит информацию на несколько частей, присваивает каждой части номер, по которому данные впоследствии можно будет соединить воедино, добавляет к ней «служебную» информацию и укладывает все это в отдельный «IP-конверт». Далее этот «конверт» отправляется по сети - ведь протокол межсетевого уровня умеет обрабатывать подобную информацию. Поскольку в такой схеме протоколы TCP и IP тесно связаны, их часто объединяют в одно понятие: TCP/IP. Размер передаваемых в Интернете TCP/IP-пакетов составляет, как правило, от 1 до 1500 байт, что связано с техническими характеристиками сети.
Наверняка, пользуясь услугами обычной почтовой связи, вы сталкивались с тем, что обычные письма, посылки и иные почтовые отправления теряются и приходят совсем не туда, куда нужно. Те же проблемы характерны и для локальных сетей. На почте такие неприятные ситуации решают руководители почтовых отделений, а в сетевых системах этим занимается протокол TCP. Если какой-либо пакет данных не был доставлен получателю вовремя, TCP повторяет пересылку до тех пор, пока информация не будет принята корректно и в полном объеме.
В действительности данные, передаваемые по электронным сетям, не только теряются, но зачастую искажаются из-за помех на линиях связи. Встроенные в TCP алгоритмы контроля корректности передачи данных решают и эту проблему. Одним из самых известных механизмов контроля правильности пересылки информации является метод, согласно которому в заголовок каждого передаваемого пакета записывается некая контрольная сумма, вычисленная компьютером-отправителем. Компьютер-получатель по аналогичной системе вычисляет контрольную сумму и сравнивает ее с числом, имеющимся в заголовке пакета. Если цифры не совпадают, TCP пытается повторить передачу.
Следует отметить также, что при отправке информационных пакетов протокол TCP требует от компьютера-получателя подтверждения приема информации. Это организуется путем создания временных задержек при приеме-передаче - тайм-аутов, или ожиданий. Тем временем отправитель продолжает пересылать данные. Образуется некий объем уже переданных, но еще не подтвержденных данных. Иными словами, TCP организует двунаправленный обмен информацией, что обеспечивает более высокую скорость ее трансляции.
При соединении двух компьютеров их модули TCP следят за состоянием связи. При этом само соединение, посредством которого осуществляется обмен данными, носит название виртуального или логического канала.
Фактически протокол TCP является неотъемлемой частью стека протоколов TCP/IP, и именно с его помощью реализуются все функции контроля над передачей информации по сети, а также задачи ее распределения между клиентскими приложениями.

Протокол SPX

В точности так же, как протокол TCP для IP-сетей, для сетей, построенных на базе межсетевого протокола IPX, транспортным протоколом служит специальный протокол SPX (Sequenced Pocket eXchange). В таких локальных сетях протокол SPX выполняет следующий набор функций:

• инициализация соединения;
• организация виртуального канала связи (логического соединения);
• проверка состояния канала;
• контроль передачи данных;
• разрыв соединения.

Поскольку транспортный протокол SPX и межсетевой протокол IPX тесно связаны между собой, их нередко объединяют в общее понятие - семейство протоколов IPX/SPX. Поддержка данного семейства протоколов реализована не только в операционных системах семейства Nowell Netware, но и в ОС Microsoft Windows 9x/Me/NT/2000/XP, Unix/Linux и OS/2.

Протоколы NetBIOS/NetBEUI

Разработанный компанией IBM транспортный протокол NetBIOS (Network Basic Input/Output System) является базовым протоколом для локальных
сетей, работающих под управлением операционных систем семейств Nowell Netware и OS/2, однако его поддержка реализована также и в ОС Microsoft Windows, и в некоторых реализациях Unix-совместимых операционных систем. Фактически можно сказать, что данный протокол работает сразу на нескольких логических уровнях стека протоколов: на транспортном уровне он организует интерфейс между сетевыми приложениями в качестве надстройки над протоколами IPX/SPX, на межсетевом - управляет маршрутизацией дейтаграмм, на канальном уровне - организует обмен сообщениями между различными узлами сети.
В отличие от других протоколов, NetBIOS осуществляет адресацию в локальных сетях на основе уникальных имен узлов и практически не требует настройки, благодаря чему остается весьма привлекательным для системных администраторов, управляющих сетями с небольшим числом компьютеров. В качестве имен хостов протоколом NetBIOS используются значащие последовательности длиной в 16 байт, то есть каждый узел сети имеет собственное уникальное имя (permanent name), которое образуется из сетевого адреса машины с добавлением десяти служебных байтов. Кроме этого, каждый компьютер в сетях NetBIOS имеет произвольное символьное имя, равно как произвольные имена могут иметь логические*рабочие группы, объединяющие несколько работающих совместно узлов - такие имена могут назначаться и удаляться по желанию системного администратора. Имена узлов служат для идентификации компьютера в сети, имена рабочих групп могут служить, в частности, для отправки данных нескольким компьютерам группы или для обращения к целому ряду сетевых узлов одновременно.
При каждом подключении к распределенной вычислительной системе протокол NetBIOS осуществляет опрос локальной сети для проверки уникальности имени узла; поскольку несколько узлов сети могут иметь идентичные групповые имена, определение уникальности группового имени не производится.
Специально для локальных сетей, работающих на базе стандарта NetBIOS, корпорацией IBM был разработан расширенный интерфейс для этого протокола, который получил название NetBEUI (NetBIOS Extended User Interface). Этот протокол рассчитан на поддержку небольших локальных сетей, включающих не более 150-200 машин, и по причине того, что данный протокол может использоваться только в отдельных сегментах локальных сетей (пакеты NetBEUI не могут транслироваться через мосты - устройства, соединяющие несколько локальных сетей, нередко использующих различную среду передачи данных или различную топологию), этот стандарт считается устаревшим и более не поддерживается операционной системой Microsoft Windows XP, хотя его поддержка имеется в ОС семейства Windows 9х/МЕ/2000.

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

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

Протокол FTP

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

Протоколы РОРЗ и SMTP

Прикладные протоколы, используемые при работе с электронной почтой, называются SMTP (Simple Mail Transfer Protocol) и РОРЗ (Post Office Protocol), первый «отвечает» за отправку исходящей корреспонденции, второй - за доставку входящей.
В функции этих протоколов входит организация доставки сообщений e-mail и передача их почтовому клиенту. Помимо этого, протокол SMTP позволяет отправлять несколько сообщений в адрес одного получателя, организовывать промежуточное хранение сообщений, копировать одно сообщение для отправки нескольким адресатам. И РОРЗ, и SMTP обладают встроенными механизмами распознавания адресов электронной почты, а также специальными модулями повышения надежности доставки сообщений.

Протокол HTTP

Протокол HTTP (Hyper Text Transfer Protocol) обеспечивает передачу с удаленных серверов на локальный компьютер документов, содержащих код разметки гипертекста, написанный на языке HTML или XML, то есть веб-страниц. Данный прикладной протокол ориентирован прежде всего на предоставление информации программам просмотра веб-страниц, веб-браузерам, наиболее известными из которых являются такие приложения, как Microsoft Internet Explorer и Netscape Communicator.
Именно с использованием протокола HTTP организуется отправка запросов удаленным http-серверам сети Интернет и обработка их откликов; помимо
этого HTTP позволяет использовать для вызова ресурсов Всемирной сети адреса стандарта доменной системы имен (DNS, Domain Name System), то есть обозначения, называемые URL (Uniform Resource Locator) вида http:/ /www.domain.zone/page.htm (.html).

Протокол TELNET

Протокол TELNET предназначен для организации терминального доступа к удаленному узлу посредством обмена командами в символьном формате ASCII. Как правило, для работы с сервером по протоколу TELNET на стороне клиента должна быть установлена специальная программа, называемая telnet-клиентом, которая, установив связь с удаленным узлом, открывает в своем окне системную консоль операционной оболочки сервера. После этого вы можете управлять серверным компьютером в режиме терминала, как своим собственным (естественно, в очерченных администратором рамках). Например, вы получите возможность изменять, удалять, создавать, редактировать файлы и папки, а также запускать на исполнение программы на диске серверной машины, сможете просматривать содержимое папок других пользователей. Какую бы операционную систему вы ни использовали, протокол Telnet позволит вам общаться с удаленной машиной «на равных». Например, вы без труда сможете открыть сеанс UNIX на компьютере, работающем под управлением MS Windows.

Протокол UDP

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

Сквозные протоколы и шлюзы

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

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

Существующие на настоящий момент прикладные ресурсы Internet и соответствующие им протоколы можно свести в следующую таблицу (Таблица 1.3).

Таблица 1.3

В настоящее время e-mail и WWW почти вытеснили остальные сервисы, так что, например, Gopher и WAIS используются очень редко, а FTP постепенно ассимилируется Web’ом.

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

Электронная почта

Это один из двух наиболее распространенных в настоящее время прикладных ресурсов.

Электронная почта – это прикладной ресурс Internet, имеющий дело с данными в виде прикладных пакетов и работающий в рамках почтовых протоколов (например, ESMTP/POP3).

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

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

На прикладном уровне действуют почтовые протоколы.

SMTP - Simple Mail Transfer Protocol,

ESMTP - Extended Simple Mail Transfer Protocol и

POP 3 - Post Office Protocol.

Кроме программы Outlook Express существует несколько распространенных программ-клиентов для работы с электронной почтой. Это, например:

Почтовый блок программы Netscape Navigator.

Каждая из этих программ делает практически то же самое, что и Outlook Express и обладает таким же интерфейсом.

Структура адреса электронной почты

Для того, чтобы абоненты могли обмениваться сообщениями через электронную почту, у каждого из них должен быть уникальный адрес. Структура адреса электронной почты (e-mail – адреса) имеет вид, приведенный в Таблице 1.4.

Таблица 1.4.

К большинству других прикладных ресурсов (к Web-страницам, к файлам на FTP-серверах и др.) можно обратиться по универсальному URL-адресу (о нем будет сказано позже). Электронная почта с точки зрения структуры адресов стоит особняком, e-mail–адреса отличаются от URL-адресов. Это связано с историческими причинами. Адреса e-mail появились значительно раньше URL-адресов.

Электронная почта через Web

Существует возможность использовать электронную почту в рамках прикладного ресурса World Wide Web по протоколу НТТР.

В Internet есть Web-серверы, работающие как почтовые серверы – Web / Mail серверы . На таких серверах формируются Web-страницы, выполняющие функции простых почтовых программ-клиентов. Загружая такую страницу, пользователь, по сути дела, загружает программу-клиент электронной почты, аналогичную программе Outlook Express, хотя и обладающую более скромными возможностями.

Если Пользователь 1 зарегистрировал почтовый ящик на Web/Mail сервере, а Пользователь 2 работает с электронной почтой стандартным образом – через Почтовый сервер 2 и протоколы POP 3 и ESMTP, то общение между такими пользователями происходит следующим образом (Рис. 1.8).

При отправке сообщения от Пользователя 1 Пользователю 2 сообщение сначала пересылается на Web / Mail сервер по протоколу HTTP. Затем Web / Mail сервер осуществляет его отправку Почтовому серверу 2 по протоколу ESMTP. После получения сообщения Почтовым сервером 2 Пользователь 2 получает доступ к нему по протоколу POP 3. При отправке сообщения от Пользователя 2 Пользователю 1 реализуется обратный процесс: сначала сообщение отправляется Web / Mail серверу по протоколам POP 3 и ESMTP, после чего Пользователь 1 получает доступ к сообщению по протоколу HTTP.

Регистрация почтового ящика на Web / Mail серверах, как правило, бесплатна. Для того, чтобы зарегистрировать свой почтовый ящик в такой электронной почте, необходимо зайти на такой сервер по его адресу.

Главное преимущество Web-почты заключается в том, что обычная электронная почта доступна только с одного личного компьютера, подключенного к почтовому серверу провайдера через POP 3 - протокол. Web-почта доступна с любого компьютера, подключенного к Internet.

Среди недостатков Web-почты по сравнению с обычной почтой можно выделить следующие 3 недостатка.

1. Более скромный сервис, чем в специализированных почтовых клиентах типа Outlook Express.

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

3. Менее надежная защита информации, чем на сервере провайдера или в локальной сети.

Тем не менее, Web-почта развивается весьма бурными темпами, и сейчас уровень сервиса и объем предоставляемых ресурсов у крупнейших поставщиков услуг Web-почты (например, у mail.ru) не уступают обычной почте. Уровень защиты Web-почты у таких поставщиков (включая антивирусную, антиспамовую и антихакерскую защиты) также неуклонно растет. Кроме того, развиваются технологии доступа к Web-почте с помощью почтовых программ-клиентов типа Outlook Express. Вполне возможно, что в ближайшем будущем Web-почта вытеснит традиционную электронную почту.

Ресурс WWW

Подавляющее число пользователей Internet работает с прикладным ресурсом World Wide Web (или сокращенно WWW), который по-русски называют Всемирной паутиной.

Ресурс WWW был разработан в Центре ядерных исследований в Женеве группой физиков. В его основу была положена технология обмена гипертекстом, разработанная английским физиком Тимом Бернером Ли, который за изобретение этой технологии был удостоен в 2004 г. премии "Выдающиеся достижения тысячелетия" (Millennium Technology Prize). Тима Бернера Ли иногда по ошибке называют создателем сети Internet. На самом деле он изобретатель одного из прикладных ресурсов сети Internet – Всемирной Паутины WWW. Впервые этот ресурс появился в Internet в 1990 г., а к концу 1994 г. практически завоевал Сеть, вытеснив все основные, использовавшиеся до этого, ресурсы.

Ресурс WWW основан на протоколе прикладного уровня HTTP - Hyper Text Transfer Protocol и на языке HTML - Hyper Text Markup Language. В его основе также лежат такие понятия, как: HTML-документ, гипертекст, Web-страница, сайт.

Рассмотрим основные определения и элементы ресурса WWW.

Гипертекстовый документ или HTML-документ – это файл, состоящий из фрагментов текста и элементов языка HTML.

Можно также сказать, что такой документ состоит из гипертекста. HTML -документ хранится в виде файла с расширением html или htm.

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

Web-страница – это HTML документ, который расположен вместе со своими внутренними ссылками на сервере Internet. Он может передаваться другим узлам Internet по протоколу HTTP.

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

Броузер – это программа-клиент прикладного уровня, основным назначением которой является запрос, получение и отображение Web-страниц. Примером программы-броузера является Internet Explorer.

World Wide Web (WWW ) – это прикладной ресурс Internet, работающий по протоколу HTTP. Данные в WWW представляются в виде совокупности Web-страниц и сайтов, связанных между собой гиперссылками.

Работа ресурса WWW осуществляется следующим образом.

Если загрузить какую-нибудь Web‑страницу в броузер, например в Internet Explorer, то отображение этой страницы появится на экране в виде текста и рисунков, причем некоторые фрагменты текста и/или элементы изображений будут гиперссылками - щелчок по ним приведет к загрузке другой страницы, которая также будет содержать свои гиперссылки и т.д. Таким образом, различные Web-страницы оказываются связанными между собой гиперссылками. Любая Web-страница может указывать на любую другую, независимо от того, где она находится - в той же сети, в другом городе или в другой стране. Из-за этого структура гипертекстовых связей между Web-страницами оказывается весьма хаотичной и запутанной (Рис. 1.9).

Рис. 1.9. Структура гипертекстовых связей между Web-страницами

Изображенная на Рис. 1.9 структура ресурса WWW очень похожа на структуру самой сети Internet (Рис. 1.2). Сеть Internet состоит из миллионов связанных между собой компьютеров, причем связи эти весьма причудливы и хаотичны. Точно также WWW состоит из весьма хаотично связанных Web‑страниц. Однако, между этими структурами есть существенная разница. Сеть Internet состоит из компьютеров и других устройств, соединенных физическими связями (телефонными линиями, кабелями, эфирной связью и т.д.), а WWW состоит из Web-страниц, связанных логическими связями (гиперссылками). Структура логических связей не имеет никакого отношения к физической структуре сети.

Несмотря на указанную разницу, топологическое сходство между логической структурой WWW и физической структурой сети Internet обеспечивает очень органичное встраивание ресурса WWW в Internet. Этим, по-видимому, и объясняется такое бурное развитие ресурса WWW и ассимиляция им всех остальных ресурсов.

Структура URL - адреса

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

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

В Internet в основном используется универсальный формат адресов прикладных ресурсов, так называемый URL – Uniform Resource Locator.

Если пользователь знает URL-адрес информации, он может запросить необходимые данные у какой-либо сервисной системы. Обычно это WWW, но может быть и FTP, Gopher, WAIS и т.д.

Структура URL-адреса показана в следующей таблице (Таблица 1.5).

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

Таблица 1.5.

Первый компонент – протокол – указывает на прикладной ресурс, которому принадлежит запрашиваемый элемент. Например, протокол http указывает на ресурс WWW, протокол ftp указывает на ресурс FTP и т.д. Возможно также специальное значение file, которое соответствует файлу на том же локальном компьютере, или в той же локальной сети, где работает программа-клиент (а, следовательно, и пользователь, работающий с этой программой). Протокол, вообще говоря, должен быть задан в URL-адресе, однако, некоторые программы-клиенты (например, Internet Explorer) допускают отсутствие этого компонента, считая, что по умолчанию задан протокол http. Первый компонент URL-адреса отделяется от следующего компонента комбинацией из трех знаков - двоеточия и двух слешей:// .

Второй компонент URL-адреса задает узел Internet и должен присутствовать обязательно, если не задан протокол file. Если же задан протокол file, то компонент "узел" должен обязательно отсутствовать, т.к. протоколом уже определено, что узлом является текущий локальный компьютер.

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

Четвертый компонент – командная строка – указывает файл и какие-либо дополнительные параметры. Этот компонент является необязательным. Если в запросе, поступившем от программы-клиента, командная строка отсутствует, то программа-сервер отправляет файл, ссылка на который установлена по умолчанию. У Web-серверов это обычно файл с именем index.html, называемый заглавной страницей и содержащий каталог всей информации, находящейся на сервере.

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

Командная строка, как видно из таблицы, состоит из пути к файлу (полного имени файла) и параметров. Для разделения каталогов и подкаталогов (вложенных папок) используется слеш / , в отличие от аналогичной записи в OS Windows, где используется обратный слеш \ . Internet Explorer допускает любой из этих двух разделителей. Имя файла и параметры в командной строке разделяются знаком? . Для каждого параметра задается его имя и значение. Параметры отделяются друг от друга знаком & . Для присваивания параметру значения используется знак = . Если в параметре необходимо указать символы, код которых выходит за рамки основной кодовой таблицы ASCII, т.е. символы, коды которых не попадают в диапазон 32:127, то используется запись, состоящая из значка % и шестнадцатеричного значения кода символа.

Таким образом, в структуру URL-адреса могут входить 6 специальных символов: / , : , ? , & , = и % .

Примеры URL –адресов.

Http://www.ibm.com - обращение к заглавной странице сервера IBM.

Http://www.mfua.ru - обращение к заглавной странице сайта МФЮА.

Http://market.yandex.ru/search.xml?text=%EA%E8%E9&nl=0 - обращение к поисковой системе Яндекса для поиска товара "кий" ("EA", "E8" и "E9" - это шестнадцатеричные коды букв "к", "и", "й" соответственно.

Http://yandex.ru:8081 - то же, что и http://yandex.ru или http://yandex.ru/index.html.

Ftp://ftp.ipswitch.com/ipswitch/product_downloads - обращение к каталогу ftp-сервера.

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

Mailto: Пользователь@почтовый сервер.

Компьютерные вирусы

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

1) рассекречены, т.е. доведены до сведения тех, кому они не были предназначены;

2) частично или полностью изменены вопреки желанию их владельца;

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

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

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

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

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

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

1) ошибки операторов;

2) потери информации, вызванные её неправильным хранением;

3) случайные ошибки, повлёкшие уничтожение или изменение данных;

4) сбои и отказы аппаратных средств;

5) нарушения электропитания;

6) сбои в работе программных средств;

7) случайное заражение системы компьютерными вирусами.

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

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

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

Разновидность вируса, которая распространяется вместе с вложением к электронным письмам, называется почтовым червем (mail worms) . Распространяются эти вирусы по адресам рассылки, указанным в адресной книге пользователя. Некоторые черви способны генерировать текст отправляемого письма и наименование темы, а вирус прикрепляется к письму как вложение. За редким исключением черви не уничтожают локальные данные.

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

1. Среда обитания.
2. Способ заражения.
3. Разрушающие способности.
4. Характеристики алгоритма вирусной программы.

По среде обитания вирусы делятся на загрузочные вирусы, файловые и сетевые.

Загрузочные вирусы инфицируют загрузочный (boot) сектор диска или сектор, в котором расположен системный загрузчик винчестера.

Файловые вирусы заражают файлы с расширением.com, .bat, .exe. Такие вирусы можно писать на языке Visual Basic Application, или в виде скриптов, входящих в HTML страницы (VBScript, Java Script). Их называют сценарными или скриптовыми.

Сетевые вирусы распространяются по компьютерным сетям и могут принудительно выполнять свой код на любом удалённом компьютере.

Возможны комбинированные варианты вирусов.

По способу заражения вирусы делятся на резидентные вирусы и нерезидентные.

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

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

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

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

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

Опасные вирусы вызывают серьёзные нарушения в работе компьютера, уничтожают программы, данные, могут разрушить BIOS.

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

Алгоритмы работы программы вируса можно разделить на следующие разновидности:

1) с использованием стеллс-алгоритмов;

2) с включением самошифрования и полиморфизма;

3) с применением нестандартных приёмов.

Программы-шпионы внедряются через файлы аналогично вирусам.

Часто они сопровождают дистрибутивы полезных программ и устанавливаются на компьютер с соблюдением всех существующих правил. Антишпионские базы данных содержат сведения о более чем 300 Spy Ware.

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

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

За время борьбы с вредоносными программами создано большое количество антивирусных средств. Они значительно различаются и по цене, и по выполняемым функциям. Рассмотрим наиболее интересные с точки зрения индивидуального пользователя антивирусные программы. К наиболее эффективным антивирусным пакетам можно отнести Doctor Web (компания «Диалог-Наука»), антивирус Касперского AVP («Лаборатория Касперского»), Norton AntiVirus (корпорация Symantec), McAfeeVirus Scan (компания Network Associates), Panda Antivirus.

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

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

Мониторы имеют тот же образ действия, что и сканеры. Работают как резидентные программы. Они позволяют избежать запуска заражённых программ и предотвратить распространение вируса. Обычно мониторы устанавливаются в процессе инсталляции антивирусного пакета. Они лечат файл, перемещают заражённые файлы в «карантин» или удаляют согласно начальным настройкам. Мониторы специализируются как файловые, мониторы почтовых программ, мониторы специальных приложений.

Ревизоры изменений выполняют контрольные вычисления, называемые контрольными свёртками (CRC), для файлов, системных секторов и системного реестра. Эти значения сохраняются в базе данных и сравниваются при следующем запуске программы с текущими значениями. Лечение основано на представлении об исходном файле. Любые отклонения от исходного файла выявляются при проверке. Ревизоры не определяют вирусы в новых файлах до определения CRC и не выявляют вирусы в момент появления до заражения файлов компьютера.

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

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

Работа в сети и интенсивное использование Internet-а повышают опасность заражения компьютера. Среди средств сетевой защиты наибольшее внимание уделяется предупредительным средствам, т.е. препятствующим инфицированию компьютера. Они делятся на межсетевые экраны, системы обнаружения атак, сетевые сканеры, «антиспамеры».

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

В состав Windows XP входит персональный брандмауэр ICF (Internet Connection Firewall), предназначенный для защиты отдельного компьютера. Он позволяет настроить параметры защиты для каждого сетевого подключения в отдельности. Для включения функционирования ICF необходимо в меню Пуск выбрать через пункт Настройка/Сетевые подключения нужное сетевое подключение, щёлкнуть на его имени правой кнопкой мыши. В контекстном меню подключения выбрать пункт Свойства . Перейти на вкладку Дополнительно и включить опцию «Защитить моё подключение к Internet-у».

Включённый межсетевой экран проверяет пакеты на соответствие записям в Nat-таблице потоков (Network Address Translation). Пакет пропускается, если задано разрешение. Список разрешений можно открыть через окно настроек на вкладке Параметры . Затем необходимо нажать на кнопку ICMP. В других персональных брандмауэрах можно найти и другие возможности. Например, брандмауэр Agnitum Outpost Firewall (Agnitum Ltd.) контролирует входящий и исходящий трафики на основе правил, заданных заранее или установленных в процессе обучения. Он способен работать в режиме невидимки (Stealth), блокировать загружаемые Web-страницы по HTML коду, блокировать загружаемые Web-сайты по адресам, блокировать активные элементы Web-страниц, такие как сценарии, Java-апплеты, элементы ActivX, запоминать серверы DNS для ускорения запуска Web-страниц при последующем подключении.

Системы обнаружения атак (IDE – Intrusion Detection System ) обнаруживают некорректную деятельность, выраженную в увеличении интенсивности поступления пакетов данных, поступающих извне или циркулирующих в локальной сети. Основная цель таких атак обычно скрыта. Это может быть исчерпание ресурсов, приводящее к тому, что атакуемый компьютер перестаёт обслуживать обычные запросы (DoS – Denied of Service), поиск незащищённых точек входа в систему, анализ сетевого трафика и т.п.

Для обнаружения атак выявляют аномальное поведение (anomaly detection) или злоупотребления (misuse detection), которые определяют в виде шаблонов по описанию в сетевом трафике или журнале регистрации.

В составе брандмауэров присутствуют модули, выполняющие обнаружение атак. Например, в Agnitum Outpost Firewall функционирует модуль Детектор атак, который обнаруживает атаки. Существует, кроме того, ряд специализированных пакетов.

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

«Антиспамеры » фильтруют сообщения, поступающие по электронной почте, для отсечения писем, исходящих с серверов, замеченных в распространении спама.

Тема 2. Работа с браузером

Начало работы в Internet

После установления связи пользовательского компьютера с сетью Internet любым из перечисленных выше способов, для путешествия по Internet необходимо запустить специальную клиентскую программу-проводник. Эти программы называют броузерами (от англ. browse – листать, просматривать) или обозревателями. Наиболее широко распространены броузеры Netscape Communicator , Microsoft Internet Explorer , Opera , Firefox , Mozilla . Эти программы разработаны фирмами-конкурентами, но имеют много общего.

Броузеры позволяют просматривать гипертексты, получаемые из Internet по указанным пользователем адресам. Гипертекст, как было сказано ранее, – это текст, содержащий гиперссылки. Попадая на гиперссылку, указатель мыши превращается в изображение кисти руки человека с вытянутым указательным пальцем.

Гипертекстовое содержимое WWW создается с помощью языка разметки гипертекстовых документов – HTML (HyperText Markup Language).

Окно броузера содержит ряд кнопок, приведённых в Таблице 2.1. Пример окна броузера показан на Рис. 2.2.

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

Таблица 2.1.

Кнопка	Название, назначение
1	«Назад » и «Впере д» – позволяют перемещаться по просмотренным документам.
2	«Обновить » – дает возможность пользователю повторить попытку получения документа.
3	«Домой » – возвращает пользователя на страницу браузера, зарегистрированную как стартовую при загрузке браузера.
4	«Поиск » - открывает стандартное окно в Windows для поиска текстовой строки в текущем документе.
5	«Печать » – позволяет напечатать текущую страницу на принтере.
6	«Избранное » – позволяет перейти к создаваемому пользователем списку адресов.
7	«Журнал » – дает возможность просмотреть список ссылок на те страницы, которые были просмотрены ранее и быстро перейти на любую страницу.
8	«Останов » (или клавиша ESC) – прерывает загрузку документа.

Для изменения начальной страницы необходимо найти страницу, которая станет начальной. Затем вызвать последовательно Меню à Сервис à Свойства обозревателя . В окне Свойства обозревателя щелкнуть по вкладке Общие .В разделе Домашняя страница щелкнуть по кнопке С текущей . Адрес, который был в окне, изменится на адрес отображаемой страницы. Затем нажать кнопку ОК .

Меню любого Web-броузера и, в частности, Internet Explorer-а содержит раздел Справка . При вызове справки Internet Explorer-а появляется диалоговая панель, разделённая на две части. В левой части предусмотрены 3 кнопки: Содержание , Указатель , Поиск . После нажатия на кнопку Содержание появляется список, в котором перечислены все разделы справочного файла.

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

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

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

При необходимости в разделе Меню Вид можно изменить параметры просмотра Web-страницы. При искажении текста необходимо выбрать строку Кодировка . Появится перечень возможных вариантов кодировок. Для русскоязычных страниц выбирается Кириллица (Windows) , для Web-страниц, созданных на других языках, выбираются другие варианты. В строке Размер шрифта можно установить размер шрифта на странице от Самый крупный до Самый мелкий . Строка Во весь экран позволяет убрать панели инструментов и увеличить размер изображения. Строка Просмотр HTML-кода демонстрирует текст страницы в исходном виде (на языке HTML).

Объем Web-страницы (в байтах) определяется в первую очередь графическими и другими мультимедийными элементами. Если страница содержит много таких элементов, то на ее загрузку будет тратиться много времени и расходоваться большой объем трафика. Для уменьшения времени загрузки и экономии объема трафика можно отказаться от загрузки графических элементов. Для этого необходимо в Меню выбрать Свойства обозревателя à Дополнительно . В окне Параметры убрать флажок Отображать рисунки и нажать OK . Аналогично можно отключить загрузку звуковых элементов (убрать флажок Воспроизводить звуки на Веб-страницах ) и видеоклипов (убрать флажок Воспроизводить видео на Веб-страницах ).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9 -rw- 1168 config.text

64016384 bytes total (59600295 bytes free)

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

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

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

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

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

Writing config.text....!!!

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

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

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

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

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

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

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

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

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

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

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

SW1#dir
Directory of flash:/

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

64016384 bytes total (54929840 bytes free)

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

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

telnet

ssh

pop3

smtp

ftp

tftp

Добавить метки

Протоколы Интернет прикладного уровня

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

• 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.

Протокол HTTP

HTTP (HyperText Transfer Protocol - RFC 1945, RFC 2616) - протокол прикладного уровня для передачи гипертекста.

Центральным объектом в HTTP является ресурс , на который указывает URI в запросе клиента. Обычно такими ресурсами являются хранящиеся на сервере файлы. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т. д. Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя изначально данный протокол предназначен для передачи символьной информации. На первый взгляд это может показаться излишней тратой ресурсов. Действительно, данные в символьном виде занимают больше памяти, сообщения создают дополнительную нагрузку на каналы связи, однако подобный формат имеет много преимуществ. Сообщения, передаваемые по сети, удобочитаемы, и, проанализировав полученные данные, системный администратор может легко найти ошибку и устранить ее. При необходимости роль одного из взаимодействующих приложений может выполнять человек, вручную вводя сообщения в требуемом формате.

В отличие от многих других протоколов, HTTP является протоколом без памяти. Это означает, что протокол не хранит информацию о предыдущих запросах клиентов и ответах сервера. Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами. Например, клиентское веб-приложение, посылающее запросы, может отслеживать задержки ответов, а веб-сервер может хранить IP-адреса и заголовки запросов последних клиентов.

Все программное обеспечение для работы с протоколом HTTP разделяется на три основные категории:

• Серверы - поставщики услуг хранения и обработки информации (обработка запросов).
• Клиенты - конечные потребители услуг сервера (отправка запросов).
• Прокси-серверы для поддержки работы транспортных служб.

Основными клиентами являются браузеры например: InternetExplorer, Opera, MozillaFirefox, NetscapeNavigator и другие. Наиболее популярными реализациями веб-серверов являются: InternetInformationServices (IIS), Apache, lighttpd, nginx. Наиболее известные реализации прокси-серверов: Squid, UserGate, Multiproxy, Naviscope.

"Классическая" схема HTTP-сеанса выглядит так.

1. Установление TCP-соединения.
2. Запрос клиента.
3. Ответ сервера.
4. Разрыв TCP-соединения.

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

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

• Строка состояния (иногда для ее обозначения используют также термины строка-статус, или строка запроса).
• Поля заголовка.
• Пустая строка.
• Тело запроса.

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

Рис. 2.1. Структура запроса клиента.

Строка состояния имеет следующий формат:

метод_запроса URL_pecypca версия_протокола_НТТР

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

Метод , указанный в строке состояния, определяет способ воздействия на ресурс, URL которого задан в той же строке. Метод может принимать значения GET, POST, HEAD, PUT, DELETE и т.д. Несмотря на обилие методов, для веб-программиста по-настоящему важны лишь два из них: GET и POST.

• GET. Согласно формальному определению, метод GET предназначается для получения ресурса с указанным URL. Получив запрос GET, сервер должен прочитать указанный ресурс и включить код ресурса в состав ответа клиенту. Ресурс, URL которого передается в составе запроса, не обязательно должен представлять собой HTML-страницу, файл с изображением или другие данные. URL ресурса может указывать на исполняемый код программы, который, при соблюдении определенных условий, должен быть запущен на сервере. В этом случае клиенту возвращается не код программы, а данные, сгенерированные в процессе ее выполнения. Несмотря на то что, по определению, метод GET предназначен для получения информации, он может применяться и в других целях. Метод GET вполне подходит для передачи небольших фрагментов данных на сервер.
• POST. Согласно тому же формальному определению, основное назначение метода POST - передача данных на сервер. Однако, подобно методу GET, метод POST может применяться по-разному и нередко используется для получения информации с сервера. Как и в случае с методом GET, URL, заданный в строке состояния, указывает на конкретный ресурс. Метод POST также может использоваться для запуска процесса.
• Методы HEAD и PUT являются модификациями методов GET и POST.

Версия протокола HTTP, как правило, задается в следующем формате:

HTTP/версия.модификация

Поля заголовка , следующие за строкой состояния, позволяют уточнять запрос, т.е. передавать серверу дополнительную информацию. Поле заголовка имеет следующий формат:

Имя_поля: Значение

Назначение поля определяется его именем, которое отделяется от значения двоеточием.

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

Таблица 2.1. Поля заголовка запроса HTTP.
Поля заголовка HTTP-запроса	Значение
Host	Доменное имя или IP-адрес узла, к которому обращается клиент
Referer	URL документа, который ссылается на ресурс, указанный в строке состояния
From	Адрес электронной почты пользователя, работающего с клиентом
Accept	MIME-типы данных, обрабатываемых клиентом. Это поле может иметь несколько значений, отделяемых одно от другого запятыми. Часто поле заголовка Accept используется для того, чтобы сообщить серверу о том, какие типы графических файлов поддерживает клиент
Accept-Language	Набор двухсимвольных идентификаторов, разделенных запятыми, которые обозначают языки, поддерживаемые клиентом
Accept-Charset	Перечень поддерживаемых наборов символов
Content-Type	MIME-тип данных, содержащихся в теле запроса (если запрос не состоит из одного заголовка)
Content-Length	Число символов, содержащихся в теле запроса (если запрос не состоит из одного заголовка)
Range	Присутствует в том случае, если клиент запрашивает не весь документ, а лишь его часть
Connection	Используется для управления TCP-соединением. Если в поле содержится Close, это означает, что после обработки запроса сервер должен закрыть соединение. Значение Keep-Alive предлагает не закрывать TCP-соединение, чтобы оно могло быть использовано для последующих запросов
User-Agent	Информация о клиенте

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

Ниже представлен пример HTML-запроса, сгенерированного браузером

GET http://oak.oakland.edu/ HTTP/1.0

Connection: Keep-Alive

User-Agent: Mozilla/4.04 (Win95; I)

Host: oak.oakland.edu

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*

Accept-Language: en

Accept-Charset: iso-8859-l,*,utf-8

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

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

• Строка состояния.
• Поля заголовка.
• Пустая строка.
• Тело ответа.

Ответ сервера клиенту начинается со строки состояния, которая имеет следующий формат:

Версия_протокола Код_ответа Пояснительное_сообщение

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

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

HТТР/1.0 200 ОК

Как видно, за версией протокола HTTP 1.0 следует код 200. В этом коде символ 2 означает успешную обработку запроса клиента, а остальные две цифры (00) - номер данного сообщения.

В используемых в настоящее время реализациях протокола HTTP первая цифра не может быть больше 5 и определяет следующие классы ответов.

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

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

Таблица 2.2. Классы кодов ответа сервера.
Код	Расшифровка	Интерпретация
	Continue	Часть запроса принята, и сервер ожидает от клиента продолжения запроса
	OK	Запрос успешно обработан, и в ответе клиента передаются данные, указанные в запросе
	Created	В результате обработки запроса был создан новый ресурс
	Accepted	Запрос принят сервером, но обработка его не окончена. Данный код ответа не гарантирует, что запрос будет обработан без ошибок.
	Partial Content	Сервер возвращает часть ресурса в ответ на запрос, содержавший поле заголовка Range
	Multiple Choice	Запрос указывает более чем на один ресурс. В теле ответа могут содержаться указания на то, как правильно идентифицировать запрашиваемый ресурс
	Moved Permanently	Затребованный ресурс больше не располагается на сервере
	Moved Temporarily	Затребованный ресурс временно изменил свой адрес
	Bad Request	В запросе клиента обнаружена синтаксическая ошибка
	Forbidden	Имеющийся на сервере ресурс недоступен для данного пользователя
	Not Found	Ресурс, указанный клиентом, на сервере отсутствует
	Method Not Allowed	Сервер не поддерживает метод, указанный в запросе
	Internal Server Error	Один из компонентов сервера работает некорректно
	Not Implemented	Функциональных возможностей сервера недостаточно, чтобы выполнить запрос клиента
	Service Unavailable	Служба временно недоступна
	HTTP Version not Supported	Версия HTTP, указанная в запросе, не поддерживается сервером

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

Таблица 2.3. Поля заголовка ответа веб-сервера.
Имя поля	Описание содержимого
Server	Имя и номер версии сервера
Age	Время в секундах, прошедшее с момента создания ресурса
Allow	Список методов, допустимых для данного ресурса
Content-Language	Языки, которые должен поддерживать клиент для того, чтобы корректно отобразить передаваемый ресурс
Content-Type	MIME-тип данных, содержащихся в теле ответа сервера
Content-Length	Число символов, содержащихся в теле ответа сервера
Last-Modified	Дата и время последнего изменения ресурса
Date	Дата и время, определяющие момент генерации ответа
Expires	Дата и время, определяющие момент, после которого информация, переданная клиенту, считается устаревшей
Location	В этом поле указывается реальное расположение ресурса. Оно используется для перенаправления запроса
Cache-Control	Директивы управления кэшированием. Например, no- cache означает, что данные не должны кэшироваться

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

Ниже представлен пример ответа сервера на запрос, приведенный в предыдущем разделе. В теле ответа содержится исходный текст HTML-документа.

Server: Microsoft-IIS/5.1

X-Powered-By: ASP.NET

Content-Type: text/html

Accept-Ranges: bytes

ETag: "b66a667f948c92:8a5"

Content-Length: 426

Operand1:

Operand2:

Operation:

+

-

*

/

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

Поле с именем Content-type может встречаться как в запросе клиента, так и в ответе сервера. В качестве значения этого поля указывается MIME-тип содержимого запроса или ответа. MIME-тип также передается в поле заголовка Accept, присутствующего в запросе.

Спецификация MIME (Multipurpose Internet Mail Extension - многоцелевое почтовое расширение Internet) первоначально была разработана для того, чтобы обеспечить передачу различных форматов данных в составе электронных писем. Однако применение MIME не исчерпывается электронной почтой. Средства MIME успешно используются в WWW и, по сути, стали неотъемлемой частью этой системы.

Стандарт MIME разработан как расширяемая спецификация, в которой подразумевается, что число типов данных будет расти по мере развития форм представления данных. Каждый новый тип в обязательном порядке должен быть зарегистрирован в IANA (Internet Assigned Numbers Authority).

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

В соответствии со спецификацией MIME, для описания формата данных используются тип и подтип . Тип определяет, к какому классу относится формат содержимого HTTP-запроса или HTTP-ответа. Подтип уточняет формат. Тип и подтип отделяются друг от друга косой чертой:

тип/подтип

Поскольку в подавляющем большинстве случаев в ответ на запрос клиента сервер возвращает исходный текст HTML-документа, то в поле Content-type ответа обычно содержится значение text/html. Здесь идентификатор text описывает тип, сообщая, что клиенту передается символьная информация, а идентификатор html описывает подтип, т.е. указывает на то, что последовательность символов, содержащаяся в теле ответа, представляет собой описание документа на языке HTML.

Перечень типов и подтипов MIME достаточно велик. В таблице 2.4 приведены примеры MIME-типов, наиболее часто встречающиеся в заголовках HTML-запросов и ответов.

Таблица 2.4. MIME типы данных.
Тип/подтип	Расширение файла	Описание
application/pdf	.pdf	Документ, предназначенный для обработки Acrobat Reader
application/msexcel	.xls	Документ в формате Microsoft Excel
application/postscript	.ps, .eps	Документ в формате PostScript
application/x-tex	.tex	Документ в формате ТеХ
application/msword	.doc	Документ в формате Microsoft Word
application/rtf	.rtf	Документ в формате RTF, отображаемый с помощью Microsoft Word
image/gif	.gif	Изображение в формате GIF
image/ jpeg	.jpeg, .jpg,	Изображение в формате JPEG
image/tiff	.tiff, .tif	Изображение в формате TIFF
image/x-xbitmap	.xbm	Изображение в формате XBitmap
text/plain	.txt	ASCII-текст
text/html	. html , . htm	Документ в формате HTML
audio/midi	.midi, .mid	Аудиофайл в формате MIDI
audio/x-wav	.wav	Аудиофайл в формате WAV
message/rfc822		Почтовое сообщение
message/news		Сообщение в группы новостей
video /mpeg	.mpeg, .mpg, .mpe	Видеофрагмент в формате MPEG
video/avi	.avi	Видеофрагмент в формате AVI

Для однозначной идентификации ресурсов в сети Веб используются уникальные идентификаторы URL.

Единообразный идентификатор ресурса URI (Uniform Resource Identifier) представляет собой короткую последовательность символов, идентифицирующую абстрактный или физический ресурс. URI не указывает на то, как получить ресурс, а только идентифицирует его. Это дает возможность описывать с помощью RDF (Resource Description Framework) ресурсы, которые не могут быть получены через Интернет (имена, названия и т.п.). Самые известные примеры URI - это URL и URN.

• URL (Uniform Resource Locator) - это URI, который, помимо идентификации ресурса, предоставляет еще и информацию о местонахождении этого ресурса.
• URN (Uniform Resource Name) - это URI, который идентифицирует ресурс в определенном пространстве имен, но, в отличие от URL, URN не указывает на местонахождение этого ресурса.

URL имеет следующую структуру:

<схема>://<логин>:<пароль>@<хост>:<порт>/

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

Общепринятые схемы (протоколы) URL включают протоколы: ftp, http, https, telnet , а также.

Прикладной уровень представляет собой комплекс программных средств, представленных в двух формах: в виде приложений (applications) и программ служб сервиса (services) .

Сопряжение человека с сетью обеспечивают приложения. Широко известны такие приложения этого уровня, как веб-браузеры гипертекстовой информационной службы (World Wide Web – WWW ), которые позволяют людям готовить сообщения для передачи по сети и принимать такие сообщения. Наиболее известными веб-браузерами являются Internet Explorer, Mozilla Firefox, Opera.

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

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

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

Наиболее распространенными протоколами и службами прикладного уровня являются:

• протоколы электронной почты (Simple Mail Transfer Protocol – SMTP, Post Office Protocol – POP , – IMAP );
• протокол передачи гипертекстовой информации, или веб-сервер ( Hypertext Transfer Protocol – HTTP);
• протокол передачи файлов ( File Transfer Protocol – FTP) и простой протокол передачи файлов (Trivial FTP – TFTP );
• система доменных имен (Domain Name System – DNS);
• протоколы удаленного доступа ( Telnet и SSH ), обеспечивающие виртуальное соединение с удаленными сетевыми устройствами;
• протокол динамического назначения адресов узлов (Dynamic Host Configuration Protocol – DHCP ).

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

Существуют две модели построения сети:

1. модель "клиент-сервер";
2. модель соединения равноправных узлов сети ( peer -to- peer ).

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

Согласно модели "клиент-сервер" клиент запрашивает информацию, пересылая запрос выделенному серверу ( upload ), который в ответ на запрос посылает ( download ) файл , принимаемый клиентом. Следовательно, клиент инициирует процесс обмена информацией в среде "клиент- сервер " и получает от сервера требуемую информацию. Главным достоинством модели "клиент- сервер " является централизация управления сетью и обеспечение безопасности.

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

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

При передаче электронной почты и взаимодействии почтовых серверов между собой используется простой протокол передачи почты (Simple Mail Transfer Protocol – SMTP ), у которого номер порта 25. Для получения клиентом сообщения с сервера используется протокол почтового отделения ( Post Office Protocol – POP ) с номером порта 110 или протокол доступа к сообщениям ( Internet Messaging Access Protocol – IMAP ).

Рис. 2.2.

При передаче сообщений между серверами используется Агент передачи почты (Mail Transfer Agent – MTA ). Агент MTA получает сообщения от MUA или от другого MTA и передает их по сети. Агенты MTA применяют протокол SMTP для передачи электронной почты между серверами. Если сообщение из сервера может быть отправлено сразу клиенту локальной сети, то подключается Агент доставки почты (Mail Delivery Agent – MDA ). Агент MDA получает прибывающую почту от MTA и помещает ее в соответствующие почтовые ящики пользователей, используя протокол РОР.

Протокол HTTP

Самым распространенным протоколом прикладного уровня в настоящее время является протокол передачи гипертекстовой информации ( Hypertext Transfer Protocol – HTTP ), который работает в сети Интернет. Его основным приложением является веб-браузер, который отображает данные на веб-страницах, используя текст, графику, звук и видео. Веб- страницы создаются с применением языка разметки гипертекста Hypertext Markup Language (HTML), который определяет местоположения для размещения текста, файлов и объектов, которые должны быть переданы от сервера по сети до веб-браузера. Номер порта протокола HTTP – 80, функционирует совместно с протоколом транспортного уровня TCP.

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

Протокол HTTP характеризуется сравнительно невысоким уровнем безопасности, поскольку передаваемые по сети сообщения не зашифрованы. Для повышения уровня безопасности передачи сообщений через Интернет был разработан протокол HTTP Secure (HTTPS ). В этом протоколе используется процесс криптографирования данных (encryption ) и аутентификации (authentication ), что существенно повышает уровень безопасности. Номер порта протокола HTTPS – 443.

Протоколы передачи файлов FTP и TFTP

Протокол передачи файлов (File Transfer Protocol – FTP) – служба, ориентированная на предварительное соединение ( connection-oriented ), которая взаимодействует с протоколом транспортного уровня TCP. Главная цель протокола FTP состоит в том, чтобы передавать файлы от одного компьютера другому или копировать и перемещать файлы от серверов клиентам и от клиентов серверам. Это является главным отличием от протокола HTTP, который позволяет клиенту "скачивать" файлы с сервера, но не позволяет пересылать файлы на сервер.

Протокол передачи файлов FTP сначала устанавливает соединение между клиентом и сервером, используя команды запроса клиента и ответы сервера. При этом номер порта – 21. Затем производится обмен данными, когда номер порта – 20. Передача данных может производиться в режиме кода ASCII или в двоичном коде. Эти режимы определяют кодирование, используемое для файла данных, которое в модели OSI является задачей представительского (presentation) уровня. После завершения передачи файла соединение для передачи данных заканчивается автоматически. Управление сеансом связи происходит на сеансовом (Session) уровне.

Простой протокол передачи файлов (Trivial File Transfer Protocol – TFTP ) – служба без установления соединения ( connectionless ), которая работает совместно с протоколом транспортного уровня (User Datagram Protocol – UDP ). Протокол TFTP применяется на маршрутизаторах, чтобы передавать файлы конфигурации и операционную систему Cisco IOS , а также для передачи файлов между системами, которые поддерживают TFTP . Протокол TFTP характеризует простота и малый объем программного обеспечения. Он может читать или записывать файлы при соединении с сервером, но не ведет списки и каталоги. Поэтому протокол TFTP работает быстрее, чем протокол FTP.

Система доменных имен DNS

Система доменных имен (Domain Name System – DNS) используется в Интернете для того, чтобы переводить имена сайтов или доменов в числовые значения IP-адреса. Людям легче запомнить доменное имя , например, http://www.cisco.com , чем числовой адрес 198.133.219.25. Кроме того, числовые адреса могут со временем меняться. Например, в настоящее время указанный выше числовой адрес сайта http://www.cisco.com изменен на 72.163.4.161. Поскольку в ряде случаев требуется знание числового адреса, хост может обратиться к DNS-серверу и по имени получить соответствующий адрес. DNS использует распределенный набор серверов разного уровня иерархии, чтобы получить соответствие между именем и числовым адресом.

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

На рис. 2.3 приведен пример выполнения команды nslookup, которая позволяет пользователю вручную запросить адрес DNS-сервера . Команда выполняется в режиме командной строки (Пуск Программы Стандартные Командная строка ). В приведенном примере выполнено четыре команды.