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

Размещено на http://www.allbest.ru/

Содержание

сетевой протокол стек получатель

Введение

1. Классификация протоколов передачи данных. Модель OSI

2. Описание основных протоколов передачи данных

Заключение

Список использованных источников



Введение

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

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



1. Классификация протоколов передачи данных. Модель OSI

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

Сетевая модель OSI (англ. open systems interconnection basic reference model -- базовая эталонная модель взаимодействия открытых систем, сокр. ЭМВОС; 1978 г) -- сетевая модель стека сетевых протоколов OSI/ISO (ГОСТ Р ИСО/МЭК 7498-1-99). OSI расшифровывается как Open System Interconnection (взаимодействие открытых систем). Польза открытой системы перед закрытой заключается в том, что устройства, созданные в соответствии с требованиями открытости, могут свободно взаимодействовать между собой независимо от того, кто их произвел. Спецификации и стандарты, по которым построены эти устройства, общедоступны.

В литературе наиболее часто принято начинать описание уровней модели OSI с 7-го уровня, называемого прикладным, на котором пользовательские приложения обращаются к сети. Модель OSI заканчивается 1-м уровнем -- физическим, на котором определены стандарты, предъявляемые независимыми производителями к средам передачи данных:

тип передающей среды (медный кабель, оптоволокно, радиоэфир и др.),

тип модуляции сигнала,

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

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

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

Рисунок 1. Процесс передачи данных по модели OSI



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

Уровень процессов и приложений

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

В качестве примеров протоколов седьмого уровня можно привести широко-применяемые в сети Интернет следующие протоколы: HTTP (Hypertext Transfer Protocol) - протокол передачи страниц в сети Интернет, FTP (File Transfer Protocol) - протокол передачи данных, SMTP (Simple Mail Transfer Protocol) - протокол передачи электронной почты.

Уровень представлений

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

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

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

Другой функцией, выполняемой на уровне представлений, является шифрование данных, которое применяется в тех случаях, когда необходимо защитить передаваемую информацию от приема несанкционированными получателями. Чтобы решить эту задачу, процессы и коды, находящиеся на уровне представлений, должны выполнить преобразование данных. На этом уровне существуют и другие подпрограммы, которые сжимают тексты и преобразовывают графические изображения в битовые потоки, так что они могут передаваться по сети. Примером протокола, обеспечивающим секретный обмен по сети, является уровень защищённых сокетов (англ. Secure Sockets Layer -- SSL).

Сеансовый уровень

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

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

Примером протоколов сеансового уровня является протокол сеансового уровня стека протоколов OSI, который известен как X.235 или ISO 8327. В случае потери соединения этот протокол может попытаться его восстановить. Если соединение не используется длительное время, то протокол сеансового уровня может его закрыть и открыть заново. Он позволяет производить передачу в дуплексном или в полудуплексном режимах и обеспечивает наличие контрольных точек в потоке обмена сообщениями.

Другими примерами реализации сеансового уровня являются Zone Information Protocol (ZIP) - протокол AppleTalk, обеспечивающий согласованность процесса связывания по имени, а также протокол управления сеансом (англ. Session Control Protocol (SCP)) - протокол уровня сеанса IV стадии проекта разработки стека протоколов DECnet.

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

4-й уровень сетевой модели OSI предназначен для доставки данных. При этом не важно, какие данные передаются, откуда и куда, то есть он предоставляет сам механизм передачи. Блоки данных он разделяет на фрагменты, размер которых зависит от протокола, короткие объединяет в один, а длинные разбивает. Примеры протоколов транспортного уровня: TCP, UDP, SCTP, RTP.

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

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

Сетевой уровень

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

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

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

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

Канальный уровень

Канальный уровень сетевой модели OSI, предназначенный для передачи данных узлам, находящимся в том же сегменте локальной сети. Также может использоваться для обнаружения и если возможно исправления ошибок возникших на физическом уровне. Примерами протоколов работающих на канальном уровне являются Ethernet для локальных сетей (многоузловой), Point-to-Point Protocol (PPP), HDLC и ADCCP для подключений точка-точка (двухузловой).

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

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

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

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

Физический уровень

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

На этом уровне работают сетевые платы, сетевые концентраторы, сетевые коммутаторы, модемы, повторители (ретрансляторы) сигнала, медиаконверторы.

Функции физического уровня реализуются на всех устройствах, подключенных к сети. Со стороны компьютера функции физического уровня выполняются сетевым адаптером или последовательным портом. К физическому уровню относятся физические, электрические и механические интерфейсы между двумя системами. Физический уровень определяет такие свойства среды сети передачи данных как оптоволокно, витая пара, коаксиальный кабель, спутниковый канал передачи данных и т. п. Стандартными типами сетевых интерфейсов, относящимися к физическому уровню, являются: V.35, RS-232C, RJ-11, RJ-45, разъёмы AUI и BNC.

2. Описание основных протоколов передачи данных

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

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

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



Таблица 1. Структура IP пакета

Поле	Описание
Source IP-address	(IP-адрес отправителя) Отправитель пакета
Destination IP-address	(IP-адрес получателя) Получатель пакета
Protocol (Протокол)	TCP или UDP
Checksum (Контрольная сумма)	Значение для проверки целостности пакета
TTL (Time to Live, время жизни пакета)	Определяет, сколько секунд дейтаграмма может находиться в сети. Предотвращает бесконечное блуждание пакетов в сети. Значение TTL автоматически уменьшается на одну или более секунд при проходе через каждый маршрутизатор сети
Version Версия протокола IP -- 4 или 6.	Шестая версия протокола IP рассматривается в гл. 8 (4 бита)
Header Length (Длина заголовка)	Минимальный размер заголовка -- 20 байт (4 бита)
Type of Service (Тип обслуживания)	Обозначение требуемого для этого пакета качества обслуживания при доставке через маршрутизаторы IP-сети. Здесь определяются приоритет, задержки, пропускная способность. (8 бит)
Total Length (Общая длина)	Длина дейтаграммы IP-протокола (16 бит)
Identification (Идентификация)	Идентификатор пакета. Если пакет фрагментирован (разбит на части), то все фрагменты имеют одинаковый идентификатор (16 бит)
Fragmentation Flags (Фрагментационные флаги)	3 бита для флагов фрагментации и 2 бита для текущего использования
Fragmentation Offset (Смещение фрагмента)	Указывает на положение фрагментов относительно начала поля данных IP-пакета. Если фрагментации нет, смещение равно 0x0 (13 бит)
Options and Padding (Опции и заполнение)	Опции

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

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

Таблица 2. Структура TCP пакета

Поле	Описание
Source port (Порт отправителя)	Порт TCP узла-отправителя
Destination Port (Порт получателя)	Порт TCP узла-получателя
Sequence Number (Порядковый номер)	Номер последовательности пакетов
Acknowledgement Number (Номер подтверждения)	Порядковый номер байта, который локальный узел рассчитывает получить следующим
Data Length (Длина данных)	Длина TCP- пакета
Reserved (Зарезервировано)	Зарезервировано для будущего использования
Flags (Флаги)	Описание содержимого сегмента
Window (Окно)	Показывает доступное место в окне протокола TCP
Checksum (Контрольная сумма)	Значение для проверки целостности пакета
Urgent Pointer (Указатель срочности)	При отправке срочных данных (поле Flags) в этом поле задается граница области срочных данных

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

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

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

Части доменного имени записываются через точку. Слово "домен имен" здесь понимается как некая совокупность имен, у которых совпадают старшие составные части. Например, пусть старшая часть доменного имени будет ".ru" (на деле самая старшая часть всех доменных имен Интернета - это точка ".", но она обычно не принимается во внимание). Все имена узлов, у которых их старшая часть будет ".ru", образуют один домен имен (в данном случае - это пространство доменных имен русского интернета). Это, например, всем известные yandex.ru, rambler.ru и так далее.

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

Говоря о разрешении имен относительно пары "IP-адрес - доменное имя", следует отметить, что разрешения требует и связка адресов "физический адрес - IP адрес". Эта задача возложена на протокол стека TCP/IP, называемый ARP. Эта аббревиатура означает Address Resolution Protocol -- то есть протокол, который занимается определением физического адреса узла по его IP-адресу.

Стек протоколов IPX/SPX

IPX/SPX сегодня относится к семейству малоиспользуемых протоколов. Рассмотрим общую структуру протоколов стека IPX/SPX.

Физический и канальный уровень этого стека совпадает со стеком TCP/IP, то есть стек IPX/SPX может работать в тех же Ethernet-сетях, на том же оборудовании, сетевых картах и кабелях. Различия начинаются на сетевом уровне.

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

На прикладном уровне стека IPX/SPX расположены протоколы SAP и NSP. Эти протоколы могут работать с протоколом IPX непосредственно, без привлечения SPX. Концептуальное отличие IPX/SPX от TCP/IP состоит в том, что первый изначально разрабатывался для применения в небольших локальных сетях, а второй был обобщением опыта создания глобальных сетей. Поэтому по прошествии времени интерес общества к этим стекам протоколов менялся.

Адрес узла в стеке IPX/SPX складывается из четырехбайтового номера сети, шестибайтового номера узла и двухбайтового номера сокета. Посмотрите на табл. 2.3, где схематично изображен такой адрес.

Таблица 3. Структура адреса IPX/SPX

Номер сети	Номер узла	Номер сокета
4 байта	6 байт	2 байта

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

Номер сети в IPX/SPX имеет фиксированный размер, а TCP/IP позволяет пользоваться масками подсетей. В результате мы получаем потенциально более быструю (особенно на медленных ПК 80-90-х годов), чем в TCP/IP, реализацию сетевых функций, но за скорость приходится расплачиваться универсальностью. Если TCP/IP гарантированно будет работать в сетью с любой физической архитектурой, то с IPX/SPX могут возникнуть проблемы. (Эти проблемы не коснутся нас с вами, строителей небольших локальных сетей). Так же, как и TCP/IP, протокол IPX/SPX позволяет осуществлять маршрутизацию пакетов между сетями.

Протокол NetBIOS

Протокол NetBIOS был создан для работы в локальных сетях. Система NetBIOS предназначена для персональных ЭВМ типа IBM/PC в качестве интерфейса, независящего от фирмы-производителя. NetBIOS использует в качестве транспортных протоколов TCP и UDP. Описание NetBIOS содержится в документе IBM 6322916 "Technical Reference PC Network".

Пакет NetBIOS создан для использования группой ЭВМ, поддерживает как режим сессий (работа через соединение), так и режим дейтограмм (без установления соединения). 16-и символьные имена объектов в netbios распределяются динамически. NetBIOS имеет собственную dns, которая может взаимодействовать с интернетовской. Имя объекта при работе с NetBIOS не может начинаться с символа *.

Приложения могут через NetBIOS найти нужные им ресурсы, установить связь и послать или получить информацию. NetBIOS использует для службы имен порт - 137, для службы дейтограмм - порт 138, а для сессий - порт 139.

Любая сессия начинается с NetBIOS -запроса, задания ip-адреса и определения tcp-порта удаленного объекта, далее следует обмен NetBIOS -сообщениями, после чего сессия закрывается. Сессия осуществляет обмен информацией между двумя NetBIOS -приложениями. Длина сообщения лежит в пределах от 0 до 131071 байт. Допустимо одновременное осуществление нескольких сессий между двумя объектами.

При организации IP-транспорта через NetBIOS IP-дейтограмма вкладывается в NetBIOS -пакет. Информационный обмен происходит в этом случае без установления связи между объектами. Имена Netbios должны содержать в себе IP-адреса. Так часть NetBIOS -адреса может иметь вид, ip.**.**.**.**, где IP указывает на тип операции (IP через NetBIOS), а **.**.**.** - ip-адрес. Система NetBIOS имеет собственную систему команд (call, listen, hang up, send, receive, session status, reset, cancel, adapter status, unlink, remote program load) и примитивов для работы с дейтограммами (send datagram, send broadcast datagram, receive datagram, receive broadcast datagram). Все оконечные узлы NetBIOS делятся на три типа:

Широковещательные ("b") узлы;

узлы точка-точка ("p");

узлы смешанного типа ("m").

IP-адрес может ассоциироваться с одним из указанных типов. B-узлы устанавливают связь со своим партнером посредством широковещательных запросов. P- и M-узлы для этой цели используют netbios сервер имен (NBNS) и сервер распределения дейтограмм (NBDD).

В настоящее время разработана улучшенная версия протокола NetBIOS - NetBeui (NetBios extended user interface). Этот новый протокол используется операционными системами LAN manager, LAN server, Windows for Workgroups и Windows NT, а по своей функции занимает нишу протоколов TCP/IP, охватывая связной, сетевой и транспортный уровни. Здесь стандартизован формат пакетов NetBios, добавлены некоторые новые функции. Netbuei базируется на протоколе OSI LLC2, вводит стандарт на формат кадра netbios (NDF) и использует NetBios в качестве интерфейса высокого уровня. Протокол обладает высоким быстродействием и служит для объединения небольших локальных сетей (20-200 ЭВМ) друг с другом или с главной ЭВМ. Этот протокол соответствует связному, сетевому и транспортному уровню модели OSI. В новых версиях NetBuei (3.0 и выше) снято ограничение на число одновременных сессий (254). Среди ограничений NetBuei следует назвать отсутствие внутренней маршрутизации и серьезные ограничения при работе в региональных сетях. По этой причине netbuei рекомендуется для локальных сетей (здесь они предпочтительнее других протоколов), а для внешних связей использовать, например, TCP/IP.

Протокол HTTP

HTTP (Hypertext Transfer Protokol) - протокол прикладного уровня, предназначен для распределения и управления информационными системами, реализующими механизм гипертекстовых ссылок. Он является основным объектно-ориентированным протоколом, который может решать задачи управления обменом между серверами и объектами распределенных систем, используя их методы запросов. Основным направлением развития HTTP является определение типа и способов представления данных; применение систем, независимых от способа передачи данных.

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

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

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

Метод GET изменяется на "условный GET", если сообщение запроса включает в себя поле заголовка "If-Modified-Since". В ответ на условный GET, тело запрашиваемого ресурса передается только, если он изменялся после даты принципе, одна и та же программа может выступать и в роли сервера и в, указанной в заголовке "If-Modified-Since". Алгоритм определения этого включает в себя следующие случаи:

Если код статуса ответа на запрос будет отличаться от "200 OK", или дата, указанная в поле заголовка "If-Modified-Since" некорректна, ответ будет идентичен ответу на обычный запрос GET.

Если после указанной даты ресурс изменялся, ответ будет также идентичен ответу на обычный запрос GET.

Если ресурс не изменялся после указанной даты, сервер вернет код статуса "304 Not Modified".

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

Метод HEAD аналогичен методу GET, за исключением того, что в ответе сервер не возвращает Тело- Ответа. Метаинформация, содержащаяся в HTTP заголовках ответа на запрос HEAD, должна быть идентична информации HTTP заголовков ответа на запрос GET. Данный метод может использоваться для получения метаинформации о ресурсе без передачи по сети самого ресурса. Метод "Условный HEAD", аналогичный условному GET, не определен.

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

Аннотация существующих ресурсов

Добавление сообщений в группы новостей, почтовые списки или подобные группы статей

Доставка блоков данных процессам, обрабатывающим данные

Расширение баз данных через операцию добавления

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

Клиент может предложить URI для идентификации нового ресурса, включив в запрос заголовок "URI". Тем не менее, сервер должен рассматривать этот URI только как совет и может сохранить тело запроса под другим URI или вообще без него.

Если в результате обработки запроса POST был создан новый ресурс, ответ должен иметь код статуса, равный "201 Created", и содержать URI нового ресурса.

Метод PUT запрашивает сервер о сохранении Тело-Запроса под URI, равным URI-Запроса. Если URI-Запроса ссылается на уже существующий ресурс, Тело-Запроса должно рассматриваться как модифицированная версия данного ресурса. Если ресурс, на который ссылается URI-Запроса не существует, и данный URI может рассматриваться как описание для нового ресурса, сервер может создать ресурс с данным URI. Если был создан новый ресурс, сервер должен информировать направившего запрос клиента через ответ с кодом статуса "201 Created". Если существующий ресурс был модифицирован, должен быть послан ответ "200 OK", для информирования клиента об успешном завершении операции. Если ресурс с указанным URI не может быть создан или модифицирован, должно быть послано соответствующее сообщение об ошибке.

Фундаментальное различие между методами POST и PUT заключается в различном значении поля URI-Запроса. Для метода POST данный URI указывает ресурс, который будет управлять информацией, содержащейся в теле запроса, как неким придатком. Ресурс может быть обрабатывающим данные процессом, шлюзом в какой-нибудь другой протокол, или отдельным ресурсом, допускающим аннотации. В противоположность этому, URI для запроса PUT идентифицирует информацию, содержащуюся в Содержание-Запроса. Использующий запрос PUT точно знает какой URI он собирается использовать, и получатель запроса не должен пытаться применить этот запрос к какому-нибудь другому ресурсу.

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

Метод LINK устанавливает взаимосвязи между существующим ресурсом, указанным в URI-Запроса, и другими существующими ресурсами. Отличие метода LINK от остальных методов, допускающих установление ссылок между документами, заключается в том, что метод LINK не позволяет передавать в запросе Тело-Запроса, и в том, что в результате работы данного метода не создаются новые ресурсы.

Метод UNLINK удаляет одну или более ссылочных взаимосвязей для ресурса, указанного в URI- Запроса. Эти взаимосвязи могут быть установлены с помощью метода LINK или какого-нибудь другого метода, поддерживающего заголовок "Link". Удаление ссылки на ресурс не означает, что ресурс прекращает существование или становится недоступным для будущих ссылок.

Пример http запроса с использованием метода GET:

GET /index.php HTTP/1.1

Host: example.com

User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5

Accept: text/html

Connection: close

Ответ Веб-сервера:

HTTP/1.0 200 OK

Server: nginx/0.6.31

Content-Language: ru

Content-Type: text/html; charset=utf-8

Content-Length: 1234

Connection: close

...HTML-СТРАНИЦА ...

Протокол SMTP

Основная задача протокола SMTP (Simple Mail Transfer Protocol) заключается в том, чтобы обеспечивать передачу электронных сообщений (почту). Для работы через протокол SMTP клиент создаёт TCP соединение с сервером через порт 25. Затем клиент и SMTP сервер обмениваются информацией пока соединение не будет закрыто или прервано. Основной процедурой в SMTP является передача почты (Mail Procedure). Далее идут процедуры перенаправления почты (Mail Forwarding), проверка имён почтового ящика и вывод списков почтовых групп. Самой первой процедурой является открытие канала передачи, а последней - его закрытие.

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

HELO <SP> <domain> <CRLF>

MAIL <SP> FROM:<reverse-path> <CRLF>

RCPT <SP> TO:<forward-path> <CRLF>

DATA <CRLF>

RSET <CRLF>

SEND <SP> FROM:<reverse-path> <CRLF>

SOML <SP> FROM:<reverse-path> <CRLF>

SAML <SP> FROM:<reverse-path> <CRLF>

VRFY <SP> <string> <CRLF>

EXPN <SP> <string> <CRLF>

HELP <SP> <string> <CRLF>

NOOP <CRLF>

QUIT <CRLF>

Основные методы протокола SMTP:

SEND - используется вместо команды MAIL и указыает, что почта должна быть доставлена на терминал пользователя.

SOML, SAML - комбинации команд SEND или MAIL, SEND и MAIL соответственно.

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

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

EXPN - просит сервер подтвердить, что переданный аргумент - это список почтовой группы, и если так, то сервер выводит членов этой группы.

HELP - запрашивает у сервера полезную помощь о переданной в качестве аргумента команде.

NOOP - на вызов этой команды сервер должен положительно ответить. NOOP ничего не делает и никак не влияет на указанные до этого данные.



Заключениe

В данном реферате были рассмотрены основные протоколы, использующиеся в процессе обмена информацией во всемирной сети интернет. Для классификации протоколов использовалась семиуровневая модель OSI (open systems interconnection). Приведено описание всех уровней модели, объяснено взаимодействие протоколов различных уровней модели между собой.

В качестве примеров используемых протоколов были описаны технологические стеки TCP/IP, IPX/SPX, NetBIOS. Поскольку, наиболее популярными сервисами интернета являются веб сайты и электронная почта, в реферате было подробно описаны основополагающими протоколы HTTP и SMTP. Был рассмотрены примеры сообщений и описаны методы, данных протоколов.



Список использованных источников

1. Олифер, Б. Компьютерные сети. / В. Олифер, Н. Олифер. - СПб.: Питер, 2008. - 957 с.

2. Руководство по технологиям объединенных сетей, 4-е издание.: Пер. с англ. -- М.: Издательский дом «Вильяме», 2005. -- 1040 с.

3. Электронная академия [Электронный ресурс]. - 2013. - Режим доступа: http://dic.academic.ru/. - Дата доступа: 28.11.2013.

4. HTTP // Библиотека онлайн [Электронный ресурс]. - 2013. - Режим доступа: http://citforum.ru/internet/services/services0308.shtml- Дата доступа: 28.11.2013.

Размещено на Allbest.ru