Смотреть что такое "Протоколы прикладного уровня" в других словарях.

Основные протоколы и сервисы компьютерной сети Internet

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

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

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

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

Протокол UDP (User Datagram Protocol – протокол транспортного уровня) работает на том же уровне, но применяется в том случае, когда требования к надёжности передачи данных менее жёсткие (в отличие от протокола ТСР не обеспечивает безошибочной передачи пакета). Поскольку оба этих протокола в известной степени представляют собой единое целое, как правило, говорят о протоколах TCP/IP.

TCP дробит информацию на несколько частей, присваивает каждой части номер, по которому данные впоследствии соединяются воедино, добавляет к ней «служебную» информацию и укладывает всё это в отдельный «IP-конверт». Далее этот «конверт» отправляется по Сети – Internet обрабатывает IP-информацию. Размер передаваемых в Internet TCP/IP-пакетов составляет, как правило, от 1 до 1500 байт, что связано с техническими характеристиками Сети.

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

Следует отметить также, что при отправке информационных пакетов протокол TCP требует от компьютера-получателя подтверждения приёма информации. Это организуется путём создания временных задержек при приёме-передаче – тайм-аутов, или ожиданий. Тем временем отправитель продолжает пересылать данные. Образуется некий объём уже переданных, но ещё не подтверждённых данных. Иными словами, TCP организует двунаправленный обмен информацией, что обеспечивает более высокую скорость её трансляции.

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

Системы, использующие протоколы не TCP/IP подключаются к Internet через шлюзы.

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

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

К наиболее важным прикладным протоколам относятся:

протокол удалённого управления Telnet ;

протокол передачи файлов FTP ;

протокол передачи гипертекста HTTP ;

протоколы для работы с электронной почтой:

SMTP (Simple Mail Transfer Protocol),

POP (Post Office Protocol),

IMAP (Internet Message Access Protocol),

MIME ((Multiperposal Internet Mail Exchange).

На этом уровне работает система адресации доменных имён DNS, отвечающая за преобразование числовых IP – адресов в имена.

Telnet – протокол удалённого доступа. Даёт возможность абоненту работать в полном объёме на любом компьютере сети Internet, т.е. запускать программы, менять режим работы и т.д.

FTP (File Transfer Protocol) – протокол передачи файлов. Архивы являются одним из основных информационных ресурсов Internet. Фактически, это распределённый депозитарий текстов, программ, фильмов, фотографий, аудио записей и прочей информации, хранящейся в виде файлов на различных компьютерах во всем мире. FTP даёт возможность соединять компьютеры между собой и передавать по сети файлы с одного компьютера на другой. Компьютеры, на которых находится информация для передачи по протоколу FTP, называются FTP-серверами.

Программы FTP стали частью отдельного сервиса Internet. FTP настраивается таким образом, что соединение с ним может происходить не только под именем пользователя, но и под условным именем anonymous (аноним). Тогда становится доступна не вся файловая система компьютера, а некоторый набор файлов на сервере, которые составляют содержимое сервера anonymous FTP – публичного файлового архива.

Web-документы создаются с помощью гипертекстового языка описания документов HTML (Hypertext Markup Language), построенного на базе метаязыка SGML (Structured Generalized Markup Language – структурный универсальной язык разметки, стандарт ISO-8879 1986 года), который, в свою очередь, основан на языке GML (Generalized Markup Language, стандарт ISO c 1984 г.). Для создания конкретных прикладных наборов тегов было введено понятие «SGML-приложение». Так, популярный сегодня язык HTML является SGML-приложением.

HTML-документы могут содержать несколько уровней заголовков, абзацы, списки и их пункты, графику, Web-формы и гипертекстовые ссылки. При щелчке мышью по гипертекстовой ссылке выводится пользователю другой документ. Таким образом, эта ссылка содержит «указатель» на документ, который становится доступным при нажатии кнопки мыши. Такой указатель носит название унифицированного указателя ресурса – URL (Uniform Resource Locator) – фактически это адрес документа в Internet. Указатели URL обычно описывают транспортный протокол документа (например, HTTP или FTP) и имя хост-компьютера, на котором он находится. Кроме того, указатели URL могут включать в себя маршрут доступа к документу на данном компьютере. Эти маршруты указываются в конце строки URL.

С целью специализаций по разработке и стандартизаций Web-технологий в 1994 г. изобретателем Web Тимом Бернерсом-Ли (Tim Bemers-Lee) был основан Консорциумом W3C (WWW Consortium) при Лаборатории компьютерных наук Массачусетского технологического института США (MIT Laboratory for Computer Science) с участием ЦЕРНа (CERN) при поддержке агентства министерства обороны США DARPA (Department Advanced Research Projects Agency) и Европейской комиссии.

В апреле 1995 г. французский исследовательский институт информатики и автоматики INRIA (Institute National de Recherche et en Automatique) стал европейским базовым центром (хостом) для деятельности W3C.

В 1996 г. такие же функции взял на себя японский университет Keio University Shonan Fujisawa. В настоящее время консорциум объединяет более 400 различных организаций-членов, включая изготовителей продуктов ИТ, поставщиков ИТ- услуг и информационных контентов, корпоративных пользователей, исследовательские лаборатории, организации стандартизации, госбюджетные структуры – всех, кто готов работать для достижения стабильности в развитии Web-технологии.

В частности, долгосрочными целями консорциума W3C являются:

Обеспечение универсального доступа (Universal Access) каждому пользователю к технологиям и ресурсам Internet, учитывая различия людей в культуре, образовании, способностях, материальных возможностях, с учётом их физических ограничений.

Разработка программного обеспечения Web , позволяющего взаимодействовать с Internet на смысловом или семантическом уровне (Semantic Web).

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

Консорциум W3C концентрирует свои усилия на решении следующих задач:

исследование перспектив развития и использования Web-технологий, формирование требований Web-сообщества к информационному пространству и его инфраструктуре;

реализация Web-технологий, удовлетворяющих требованиям Web-сообщества;

стандартизация Web-технологий посредством разработки спецификаций в виде Рекомендаций («Recommendations»), описывающих строительные модули Web.

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

Процесс разработки и стандартизации спецификаций Web-технологий (W3C process), организован таким образом, чтобы обеспечить:

независимость от поставщиков (вендоров) технологий (Vendor neutrality);

выполнение принципов общедоступности и консенсуса для спецификаций на протяжении их жизненного цикла;

координацию усилий с другими организациями стандартизации и консорциумами (в первую очередь, с IETF (Internet Engineering Task Force), the WAP Forum (Wireless Application Protocols Forum), the Unicode Consortium, the Web3D Consortium, а также рядом комитетов ISO (International Standard Organization).

В 1996 г. Консорциумом W3C была утверждена рекомендованная спецификация CSS (Cascading Style Sheets – каскадные листы стилей), основанная на DSSSL (Document Style Semantics and Specification Language – язык для определения семантики стиля документов SGML). Каскадные листы стилей отделены от содержания Web-страниц для того, чтобы не мешать внутренней логики логической разметки документов. В основе технологии CSS лежит концепция разграничения содержания и представления. Полное разделение содержимого и его представления обеспечивает гарантированную текстуальную доступность материалов сайта, созданного с применением рекомендаций CSS, консорциумома W3C, в любых браузерах.

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

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

Transitional – переходный, намного более «либеральный»;

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

Фрейм (Frame) или область – самостоятельный фрагмент HTML-страницы, обладающий всеми её свойствами.

Развитием HTML 4 стал «расширяемый» (eXtensible) язык разметки гипертекста – XHTML 1.0, реализующий концепцию модуляризации и полностью упраздняющий типы документов Transitional и Frameset, который получает всё большее распространение.

HTTP (Hypertext Transfer Protocol) – это протокол передачи гипертекста, позволяющий Web-браузерам обращаться к файлам на любом Web-сервере. В Internet применяются стандарты, позволяющие «публиковать» информацию – размещать её на хост-узлах, где с ней могут работать другие пользователи. Система компьютеров, публикующих такую информацию, называется World Wide Web, а протокол, составляющий основу Web протоколом передачи гипертекста. Если TCP/IP даёт возможность пользователям обращаться к хост-узлам Internet, то HTTP обеспечивает их доступ к документам World Wide Web.

HTTP позволяет реализовать в рамках обмена данными набор методов доступа, базирующихся на спецификации универсального идентификатора ресурсов URI (Universal Resource Identifier), применяемого в форме универсального локатора ресурсов URL (Universe Resource Locator) или универсального имени ресурса (Universal Resource Name). Сообщения по сети при использовании протокола HTTP передаются в формате, схожим с форматом сообщений MIME с поддержкой графики, аудио- и видеофайлов. HTTP используется для взаимодействия программ-клиентов с программами-шлюзами, разрешающими доступ к ресурсам электронной почты Internet (SMTP, Simple Mail Transfer Protocol), спискам новостей (NNTP, Network News Transfer Protocol), файловым архивам (FTP, File Transfer Protocol), информационно-поисковым системам Gopher и Wais. Протокол разработан для доступа к этим ресурсам посредством промежуточных программ-серверов (proxy), которые позволяют передавать информацию между различными информационными службами без потерь. Протокол реализует принцип «запрос/ответ». Запрашивающая программа- клиент инициирует взаимодействие с отвечающей программой-сервером, и посылает запрос, включающий в себя метод доступа, адрес URI, версию протокола, сообщение с модификаторами типа передаваемой информации, информацию клиента, и содержимое сообщения клиента. Сервер отвечает строкой состояния, включающей версию протокола и код возврата, за которой следует сообщение. Данное сообщение содержит информацию сервера, метаинформацию и содержимое сообщения. Понятно, что в принципе, одна и та же программа может выступать и в роли сервера и в роли клиента (так собственно и происходит при использовании proxy-серверов).

Система WWW (World Wide Web, переводится как «мировая паутина»), разработана в крупнейшем Европейском центре ядерных исследований, расположенном в Женеве, Швейцария. При разработке WWW была поставлена цель создания гипертекстовой системы сетевого взаимодействия, которая доступным для непрофессионалов образом может связывать друг с другом пользователей, компьютеры и данные. Отличительной чертой WWW является ориентация на практически произвольные сетевые протоколы и на работу с документами неограниченной сложности и произвольной природы. Информация большой компании, которая обычно рассредоточена по всему миру, может быть опутана «паутиной» WWW так, что географически разделённые пользователи без особых усилий получают её, не покидая своих рабочих мест. Цель эта была достигнута, и сейчас WWW интенсивно используется для информационного обмена. WWW работает по технологии «клиент/серверы».

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

Распределённая информационная гипертекстовая система WWW включает технологии:

язык гипертекстовой разметки документов HTML (HyperText Markup Language);

универсальный способ адресации ресурсов в сети URL (Universal Resource Locator);

протокол обмена гипертекстовой информацией HTTP (HyperText Transfer Protocol);

универсальный интерфейс шлюзов CGI (Common Gateway Interface).

Спецификация CGI (Common Gateway Interface) – составляющая технологии WWW – это стандарт интерфейса (связи) внешней прикладной программы с информационным сервером типа HTTP, Web сервер. Обычно гипертекстовые документы, извлекаемые из WWW серверов, содержат статические данные. С помощью CGI можно создавать CGI- программы, называемые шлюзами, которые во взаимодействии с такими прикладными системами, как система управления базой данных, электронная таблица, деловая графика и др., смогут выдать на экран пользователя динамическую информацию. CGI была специально разработана для расширения возможностей WWW за счёт подключения всевозможного внешнего программного обеспечения. Такой подход логично продолжал принцип публичности и простоты разработки и наращивания возможностей WWW. При реализации CGI очень важное место заняли методы доступа, описанные в HTTP.

На стандартах коммуникации и доступа информации основываются другие стандарты, такие как протокол электронной почты SMTP (Simple Mail Transfer Protocol). SMTP даёт возможность подключенным к Internet пользователям и хост-узлам обмениваться электронной почтой. Благодаря этому и другим стандартам можно передавать электронную почту из одного места в другое, причём не только сообщения, но и программы, графику, звук, видео и другие типы данных.

Стандарт MIME (Multipurpose Internet Mail Extensions, расширение почты Internet для различных целей) был разработан для того, чтобы обеспечить в Internet передачу данных, которые, кроме текста (в формате ASCII), поддерживают графику, аудио- и видеофайлы. Базовый протокол передачи электронной почты в Интернете, SMTP, допускает только 7-битные сообщения в кодировке ASCII. Это ограничивает электронную почту в Интернете сообщениями, которые при передаче содержат только символы, достаточные, чтобы писать на небольшом числе языков, в основном на английском.Другие языки, основанные на латинскомалфавите,часто включают диакритические знаки,не поддерживаемые в 7-битномASCII, а значит, текст на этих языках нельзя корректно отображать в стандартной электронной почте. MIME определяет механизмы для отправки разного рода информации с помощью электронной почты, включая текст на языках, отличных от английского, для которых используются символьные кодировки, отличные от ASCII, помимо этого, 8-битный бинарный контент, такой как картинки, музыка, фильмы и программы. MIME является также фундаментальным компонентом коммуникационных протоколов, таких как HTTP, которым нужно, чтобы данные передавались в контексте сообщений подобных e-mail, даже если данные реально не являются e-mail.

Отображение в и из MIME-формата в основном делается автоматически e-mail-клиентом или почтовыми серверами при посылке и получении электронных сообщений по Internet (SMTP/MIME).

Адресация и подключение в сети Internet . IP-адрес часто называют адресом Internet , он имеет длину 32 двоичных разряда и обычно записывается побайтно в виде четырех десятизначных идентификаторов, или октетов , разделённых точками, например, 136.203.91.0. Поскольку в десятичной форме один байт может принимать значения от 0 до 255, то все адреса Internet располагаются в диапазоне от 0.0.0.0 до 255.255.255.255, при этом в зависимости от типа (размеров) подсети используется 5 классов левого октета. Три из них: А, B, C – отражают группирование сетей по их мощности (по количеству узлов или подсетей, которые могут входить в сеть).

Четвёртый класс адресов (класс D) используется особо и не служит адресации конкретных сетей, а используется для обращения одновременно к группе адресов групповой адресации компьютеров, начиная с адреса 224.Х.Х.Х. Адреса класса Е пока не используются.

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

Рисунок 1. Определения класса

Значения поля идентификатора класса для каждого из пяти классов приведены на рисунке 2.

Адреса первых трех классов предназначены для адресации отдельных узлов (компьютеров и др. устройств). Структурно они состоят из трех частей (см. рисунок 3):

идентификатора класса;

номер сети;

номер узла.

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

Номер узла – число, определяющее узел сети. Для узлов одной сети, определяемой номером сети IP-адреса, должна соблюдаться уникальность номеров узлов. Разрядность номера узла также определяется классом, которому принадлежит IP-адрес.

Рисунок 2. Значения поля идентификатора класса

Рисунок 3 - Структура адреса первых трех классов (А, D, C)

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

Таблица 1. Сета класса A

Таким образом, сетей данного класса всего может быть 127 (на самом деле их меньше за счёт особо используемых адресов), однако, количество узлов в каждой из таких сетей может быть очень большим, поскольку на их адресацию отводится 24 двоичных разряда (16 777 216 различных кодов).

Для сетей класса B (см. таблицу 2) на адресацию собственно сетей используется два байта с фиксированными двумя первыми битами так, чтобы адреса этого класса не перекрывали адреса сети класса A.

Сетей этого класса существенно больше, поскольку на их адреса выделено 14 двоичных разрядов (16 384 различных кода), однако узлов в каждой из таких сетей меньше, хотя ещё достаточно много (16 двоичных разрядов – 65 536 различных кодов).

Таблица 2. Сети класса B

Для сетей класса C (см. таблицу 3) на адресацию собственно сети используется три байта с фиксированными тремя первыми битами, чтобы адреса этого класса не перекрывали адреса сетей класса A и B.

Таблица 7.4 - Сети класса С

Сетей класса C достаточно много, поскольку на их адресацию выделен 21 двоичный разряд (2 097 152 различных кода), однако на адресацию узлов при этом остаётся всего 8 двоичных разрядов (256 различных кодов, но фактически адресов не более 254, поскольку коды нулевой и единичный не используются).

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

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

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

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

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

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

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

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

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

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

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

Книги

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

TCP/IP – Transmission Control Protocol / Internet Protocol (Протокол Управления Передачей Данных / Межсетевой Протокол ). Стек TCP / IP – совокупность протоколов организации взаимодействия между структурами и программными компонентами сети; представляет собой программно реализованный набор протоколов межсетевого взаимодействия.

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

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

III -й решает задачу обеспечения надежной передачи данных между источником и адресатом.

IV -й объединяет все сетевые службы и услуги, предоставляемые сетью польз-лю.

В TCP/IP достаточно хорошо развит первый уровень, соответствующий 1 и 2 уровням OSI. Второй уровень TCP/IP – IP. Также присутствует ICMP – протокол управляющих сообщений сети. IP не гарантирует надежной передачи данных. Основная задача – выбор наилучшего маршрута. Решение этой задачи IP перекладывает на RIP и OSPF протоколы. Третий уровень – TCP, основная функция – надежность и правильность доставки данных. Также используется UDP, в нем каждый пакет передается независимо. Надежность доставки данных не гарантируется, т.к. не устанавливается связь заранее. Обычно по UDP передаются данные, не критичные к надежности. 4 уровень – набор служб и услуг, предлагаемых пользователю.

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

1) Telnet – протокол удаленного доступа (эмуляция терминала). Обеспечивает подключение пользователя за неинтеллектуальным терминалом (используется крайне редко)

2) FTP – протокол передачи данных

3) SMTP – протокол передачи электронной почты

4) POP3 – почтовый протокол

5) DNS – протокол доменных имен. Устанавливает соответствие символьный адрес – IP адрес.

6) HTTP – протокол передачи гипер текста

7) Kerberos – протокол защиты информации в сетях. Отвечает за пароли и ключи.

Telnet

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

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

File Transfer Protocol (FTP), Trivial File Transfer Protocol (TFTP) и Network File System (NFS)

Стек TCP/IP содержит три протокола для передачи файлов : File Transfer Protocol (FTP), Trivial File Transfer Protocol (TFTP) и Network File System (NFS). Самым распространенным протоколом является FTP, поскольку именно его чаще всего выбирают для передачи файлов пользователи Интернета. С помощью FTP можно, работая на компьютере в одном городе, подключиться к хост- компьютеру, расположенному в другом городе, и скачать один или несколько файлов. (При этом, конечно, нужно знать имя учетной записи и пароль для удаленного хоста.) Пользователи Интернета нередко с помощью FTP скачивают различные файлы (например, сетевые драйверы или обновления системы).

FTP – это приложение, позволяющее с помощью протокола TCP передать данные от одного удаленного устройства к другому. Как и в протоколе Telnet, заголовок FTP и соответствующие данные инкапсулируются в поле полезной нагрузки пакета TCP. Преимущество FTP по сравнению с протоколами TFTP и NFS заключается в том, что FTP использует два TCP-порта: 20 и 21. Порт 21 – это управляющий порт для команд FTP, которые определяют способ передачи данных. Например, команда get служит для получения файла, а команда put используется для пересылки файла некоторому хосту. FTP поддерживает передачу двоичных или текстовых (ASCII) файлов, Для чего применяются команды binary и ascii. Порт 20 служит только для Передачи данных, задаваемых командами FTP.

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

TFTP – это файловый протокол стека TCP/IP, предназначенный для таких задач, как передача с некоторого сервера файлов, обеспечивающих загрузку бездисковой рабочей станции. Протокол TFTP не устанавливает соединений и ориентирован на пересылку небольших файлов в тех случаях, когда появление коммуникационных ошибок не является критичным и нет особых требований к безопасности. Отсутствие соединений при работе TFTP объясняется тем, что он функционирует поверх протокола UDP (через UDP-порт 69), а не с использованием TCP. Это означает, что в процессе передачи данных отсутствуют подтверждения пакетов или не задействованы службы с установлением

соединений, гарантирующие успешную доставку пакетов в пункт назначения.

Simple Mail Transfer Protocol (SMTP)

Протокол Simple Mail Transfer Protocol (SMTP) предназначен для передачи сообщений электронной почты между сетевыми системами. С помощью этого протокола системы UNIX, OpenVMS, Windows и Novell NetWare могут пересылать электронную почту поверх протокола TCP. SMTP можно рассматривать как альтернативу протоколу FTP при передаче файла от одного компьютера к другому. При работе с SMTP не нужно знать имя учетной записи и пароль для удаленной системы. Все, что нужно, – это адрес электронной почты принимающего узла. SMTP может пересылать только текстовые файлы, поэтому файлы в других форматах должны быть конвертированы в текстовый вид, только после этого их можно поместить в SМТР-сообщение.

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

Dynamic Host Configuration Protocol (DHCP)

Протокол Dynamic Host Configuration Protocol (DHCP ) (Протокол динамически конфигурации хоста) позволяет автоматически назначать в сети 1Р-адреса с помощью DHCP-сервера. Когда новый компьютер, настроенный на работу с DHCP, подключается к сети, он обращается к DHCP-серверу, который выделяет (сдает в аренду) компьютеру IP-адрес, передавая его посредством протокола DHCP. Длительность аренды устанавливается на DHCP-сервере сетевым администратором.

Address Resolution Protocol (ARP)

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

Address Resolution Protocol (ARP) (Протокол разрешения адресов) позволяет передающему узлу получить МАС-адреса выбранного принимающего узла перед отправкой пакетов. Если исходному узлу нужен некоторый МАС-адрес, то он посылает широковещательный ARP-фрейм, содержащий свой собственный МАС-адрес и IP-адрес требуемого принимающего узла. Принимающий узел отправляет обратно пакет ARP-ответа, содержащий свой МАС-адрес. Вспомогательным протоколом является Reverse Address Resolution Protocol (RARP) (Протокол обратного разрешения имен), с помощью которого сетевой узел может определить свой собственный IP-адрес. Например, RARP используется бездисковыми рабочими станциями, которые не могут узнать свои адреса иначе как выполнив RARP-запрос к своему хост-серверу. Кроме того, RARP используется некоторыми приложениями для определения IP-адреса того компьютера, на котором он выполняются.

Simple Network Management Protocol (SNMP) (Простой протокол сетевого управления) позволяет администраторам сети непрерывно следить за активностью сети. Протокол SNMP был разработан в 1980-х годах для того, чтобы снабдить стек TCP/IP механизмом, альтернативным стандарту OSI на управление сетями – протоколу Common Management Interface Protocol (CMIP) (Протокол общей управляющей информации). Хотя протокол SNMP был создан для стека TCP/IP, он соответствует эталонной модели OSI. Большинство производителей предпочли использовать SNMP, а не CMIP, что объясняется большой популярностью протоколов TCP/IP, а также простотой SNMP. Протокол SNMP поддерживают многие сотни сетевых устройств, включая файловые серверы, карты сетевых адаптеров, маршрутизаторы, повторители, мосты, коммутаторы и концентраторы. В сравнении с этим, протокол CMIP применяется компанией IBM в некоторых сетях с маркерным кольцом, однако во многих других сетях он не встречается.

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

Начинаем разговор про протоколы верхнего уровня. Я не просто так назвал тему «Протоколы верхнего уровня», а не «Протоколы верхних уровней». Так как разбираем мы этот уровень по стеку 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»), как на картинке ниже

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мы поговорили про 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

Есть еще один файл в каждой ОС, который тесно связан с 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 адресами: создавать отдельные пулы для каждой подсети, выдавать адреса в аренду, резервировать адреса и многое другое.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. И пишем следующее.

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

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

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

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

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

Осталось проверить работу. Я воспользуюсь командой 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-сервер. Открываем командную строку и пишем

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

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

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

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

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

И последний протокол, который остался - это 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-сервера

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)

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

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

Протоколы транспортного уровня TCP и UDP.

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

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

Протокол UDP более быстр, чем протокол TCP, однако ненадежен.

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

При рассмотрении протоколов транспортного уровня необходимо остановиться на понятиях «порт» и «сокет».

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

Порты нумеруются от 0 до 65535.

Сокет (socket) – это описатель сетевого соединения между двумя сетевыми приложениями, которое включает в себя:

IP-адрес и номер порта локальной машины

IP-адрес и номер порта удаленной машины.

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

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

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

1. Протокол HTTP (Hyper Text Transfer Protocol) – протокол передачи гипертекста, работающий на 80 порту. При этом каждая HTML-страница загружается отдельно, причем соединение между загрузками прерывается и никакой информации о соединении не сохраняется. Это сделано для того, чтобы каждый из пользователей Web-страниц получал информацию «в порядке общей очереди». В противном случае могла бы создаться ситуация, например, когда один пользователь начинает качать страницу с большим содержанием рисунков высокого разрешения, а все остальные ждут, пока он это закончит.

2. Протокол FTP (File Transfer Protocol) – протокол передачи файлов, работающий на 20 и 21 порту. Он предназначен для копирования файлов между компьютерами. Полностью занимает канал, пока не будет получен файл, а далее сохраняет информацию о соединении. При сбое возможна докачка с того места, где произошел сбой.

3. Протоколы STMP, IMAP-4, POP3 – почтовые протоколы (электронная почта), работающие, SMTP – на 25 порту, IMAP-4 – на 143 порту, POP3 – на 110 порту. Отличие данных протоколов состоит в том, что протокол STMP предназначен на доставку почты до конкретного получателя, а протоколы IMAP-4 и POP3 – протоколы взаимодействия пользователя со своим почтовым ящиков на сервере..

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

Однако чаще всего бывает, что почта не доставляется на компьютер каждого отдельного пользователя, обрабатывается централизованно, на отдельном почтовом сервере. В таком случае, каждый пользователь имеет на почтовом сервере свой почтовый ящик. Почта доставляется до сервера по протоколу STMP (конечный получатель – сервер) и перемещается в почтовые ящики пользователей. Затем пользователи подключаются к своим почтовым ящикам по протоколу POP3 или IMAP-4 и забирают почту.

Таким образом, наиболее распространенный вариант работы с почтой для обычного пользователя состоит в следующем: отправка почты по протоколу STMP (на почтовый сервер получателя), получение почты – по протоколу POP3 или IMAP-4 (скачивание почты из почтового ящика на своем почтовом сервере).

4. Протокол TELNET – используется для подключения и управления удаленным компьютером, работает на 23 порту.

После подключения, каждый символ, введенный на локальной машине, обрабатывается так, как если бы он был введен на удаленной машине. Либо может использоваться командный режим – управление удаленной машиной при помощи специальных команд. Фактически TELNET – это протокол эмуляции терминала: при помощи TELNET можно подключиться, например, на 25 порт и вручную набрать все необходимые поля заголовка письма, изменив адрес отправителя (обычно эти поля заполняются автоматически специальными почтовыми программами) и отправить само письмо. Или, например, подключиться на 80 порт и «поиграть» роль Web-браузера Internet Explorer.