Как сделать свой протокол передачи данных

Добавил пользователь Валентин П.
Обновлено: 05.10.2024

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

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

Основные сетевые термины

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

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

Уровни сетей и модель OSI

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

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

Модель OSI

Так сложилось исторически, что когда дело доходит до уровней работы сетей, используется модель OSI или Open Systems Interconnect. Она выделяет семь уровней:

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

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

Модель протоколов TCP/IP

Модель TCP/IP, еще известная как набор основных протоколов интернета, позволяет представить себе уровни работы сети более просто. Здесь есть только четыре уровня и они повторяют уровни OSI:

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

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

Основные протоколы интернета

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

Есть еще очень много других протоколов, но мы рассмотрели только сетевые протоколы, которые больше всего важны. Это даст вам общие понятия того, как работает сеть и интернет в целом.

Выводы

В этой статье мы рассмотрели основы сетей и протоколов, которые используются для организации их работы. Конечно, этого совсем недостаточно, чтобы понять все, но теперь у вас есть определенная база и вы знаете как различные компоненты взаимодействуют друг с другом. Это поможет вам понимать другие статьи и документацию. Если вас серьезно заинтересовали основы сети интернет, то тут не хватит нескольких статей. Вам нужна книга. Обратите внимание на Камер Д. Сети TCP/IP. Принципы, протоколы и структура. В свое время я ее прочитал и мне очень понравилось.

На завершение видео про модель OSI:

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

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

Сердцевиной веб-общения является запрос, который отправляется через Единый указатель ресурсов (URL). Я уверен, что вы уже знаете, что такое URL адрес, однако для полноты картины, решил всё-таки сказать пару слов. Структура URL очень проста и состоит из следующих компонентов:

Методы

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

POST: используется для создания нового ресурса. POST запрос обычно содержит в себе всю нужную информацию для создания нового ресурса.

PUT: обновить текущий ресурс. PUT запрос содержит обновляемые данные.

DELETE: служит для удаления существующего ресурса.

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

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

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

Коды состояния

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

3xx: Перенаправление

301 Moved Permanently: ресурс теперь можно найти по другому URL адресу.
303 See Other: ресурс временно можно найти по другому URL адресу. Заголовок Location содержит временный URL.
304 Not Modified: сервер определяет, что ресурс не был изменён и клиенту нужно задействовать закэшированную версию ответа. Для проверки идентичности информации используется ETag (хэш Сущности - Enttity Tag);

4xx: Клиентские ошибки

5xx: Ошибки сервера

Ряд кодов, которые используются для определения ошибки сервера при обработке запроса. Самый распространённый: 500 Internal Server Error. Другие варианты:

501 Not Implemented: сервер не поддерживает запрашиваемую функциональность.
503 Service Unavailable: это может случиться, если на сервере произошла ошибка или он перегружен. Обычно в этом случае, сервер не отвечает, а время, данное на ответ, истекает.

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

Общие заголовки

Вот несколько видов заголовков, которые используются как в запросах, так и в ответах:

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

Заголовок via используется в запросе типа TRACE, и обновляется всеми прокси-серверами.

Заголовок Pragma используется для перечисления собственных заголовков. К примеру, Pragma: no-cache - это то же самое, что Cache-Control: no-cache. Подробнее об этом поговорим во второй части.

Заголовок Date используется для хранения даты и времени запроса/ответа.

Заголовок Upgrade используется для изменения протокола.

Заголовки сущностей

В заголовках сущностей передаётся мета-информация контента:

Заголовок Expires содержит время и дату истечения сущности. Значение “never expires” означает время + 1 код с текущего момента. Last-Modified содержит время и дату последнего изменения сущности.

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

Формат запроса

Запрос выглядит примерно так:

Список возможных заголовков запроса:

В заголовке Accept определяется поддерживаемые mime типы, язык, кодировку символов. Заголовки From, Host, Referer и User-Agent содержат информацию о клиенте. Префиксы If- предназначены для создания условий. Если условие не прошло, то возникнет ошибка 304 Not Modified.

Формат ответа

Формат ответа отличается только статусом и рядом заголовков. Статус выглядит так:

Обычный статус выглядит примерно так:

Заголовки ответа могут быть следующими:

Наиболее часто используемый - это Chrome Developers Tools:

Если говорить об отладчике, можно воспользоваться Fiddler:

Передав объект настроек (settings), а также воспользовавшись функцией обратного вызова beforeSend, мы можем задать заголовки запроса, с помощью метода setRequestHeader().

Прочитать объект jqXHR можно с помощью метода jqXHR.getResponseHeader().

Если хотите обработать статус запроса, то это можно сделать так:

5 последних уроков рубрики "Разное"

Как выбрать хороший хостинг для своего сайта?

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

Как разместить свой сайт на хостинге? Правильно выбранный хороший хостинг - это будущее Ваших сайтов

Разработка веб-сайтов с помощью онлайн платформы Wrike

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

20 ресурсов для прототипирования

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

Топ 10 бесплатных хостингов

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

Для правильной работы пакета NetX Web HTTP требуется установить NetX Duo 5.10 или более поздней версии. Кроме того, должен быть создан экземпляр IP, для которого включено использование протокола TCP. Для поддержки HTTPS также необходимо установить NetX Secure TLS 5.11 или более поздней версии (см. следующий раздел). Этот процесс показан в демонстрационном файле в разделе "Пример небольшой системы" главы 2.

Для правильной работы протокола HTTPS на основе пакета NetX Web HTTP требуется, чтобы были установлены NetX Duo 5.10 или более поздней версии и NetX Secure TLS 5.11 или более поздней версии. Кроме того, должен быть создан экземпляр IP, для которого включено использование протокола TCP для работы с протоколом TLS. Сеанс TLS необходимо будет инициализировать с помощью соответствующих криптографических процедур и сертификата доверенного ЦС. Кроме того, потребуется выделить пространство для сертификатов, которые будут предоставляться удаленными узлами сервера во время подтверждения TLS. Этот процесс показан в демонстрационном файле в разделе "Пример небольшой системы HTTPS" главы 2.

Дополнительные сведения о параметрах конфигурации TLS см. в документации по NetX Secure.

HTM (или HTML): HTML-файлы (HTML);
TXT: открытый текст ASCII;
GIF: двоичное изображение GIF;
XBM: двоичное изображение Xbitmap.

Когда нужна проверка подлинности? HTTP-сервер самостоятельно решает, требуется ли проверка подлинности для запрошенного ресурса. Если проверка подлинности нужна, но в запросе от клиента нет необходимых данных проверки подлинности, то клиенту возвращается ответ "HTTP/1.1 401 Unauthorized" с указанием требуемого типа проверки подлинности. Ожидается, что клиент в этом случае сформирует новый запрос с правильными данными проверки подлинности.

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

Определены следующие типы запроса:

HTTP-сервер поддерживает обратный вызов для запроса ограничений по возрасту и датам для определенного ресурса в приложении HTTP. Эти сведения позволяют определить, будет ли HTTP-сервер отправлять всю страницу клиенту по запросу GET. Если в запросе клиента нет строки "if modified since" (если изменено позднее) или это значение не совпадает с датой "last modified" (последнее изменение), полученной в обратном вызове запроса сведений из кэша, то клиенту отправляется вся страница.

Дополнительные сведения об использовании этих служб можно найти в главе 3 "Описание служб HTTP".

NetX Web HTTP соответствует требованиям документов RFC 1945 "Hypertext Transfer Protocol/1.0" (Протокол передачи гипертекста, версия 1.0), RFC 2616 "Hypertext Transfer Protocol/1.1" (Протокол передачи гипертекста, версия 1.1), RFC 2581 "TCP Congestion Control" (Контроль перегрузки TCP), RFC 1122 "Requirements for Internet Hosts" (Требования к Интернет-узлам) и других связанных с ними документов RFC.

HTTP означает Hypertext Transfer Protocol (* протокол прикладного уровня для "переговоров" о доставке Web-сервером документа Web-браузеру. НТТР служит также для передачи XML-файлов, VoiceXML , WML , потокового видео и аудио. Обычно использует порт 80, а в качестве протокола транспортного уровня - TCP . Основной протокол WWW , определённый в RFC 1945 (НТТР 1.0), 2068 и 2616 (НТТР 1.1), с помощью которого HTML-документы пересылаются по Интернету от узла к узлу. НТТР поддерживает постоянные (передача многих объектов) и непостоянные соединения (передача одного объекта веб-документа за сеанс обмена между клиентом и сервером), а также два метода идентификации пользователей: авторизацию и объекты (файлы) cookie. Здесь и далее прим. пер.). Это протокол уровня приложений без запоминания состояния (* stateless; не предусматривает сохранения информации о сессии пользователя; каждая передача данных рассматривается как новая сессия) для общения распределенных информационных систем; также является основой современной Всемирной паутины. Являясь веб-разработчиками, мы все должны иметь четкое представление об этом протоколе.

Хотя я упомяну некоторые детали насчет заголовков, за исчерпывающим описанием вам лучше будет обратиться к RFC (RFC 2616). Я буду ссылаться на определенные части документа RFC на протяжении статьи.

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

URL-адреса

Методы

Также в их распоряжении имеются прокси для отладки веб-приложений, например, Fiddler (* работает с трафиком между вашим компьютером и удаленным сервером и позволяет просматривать и менять его) (для Windows) и Charles Proxy (для OSX).

Эти методы запроса перечислены ниже:

GET: для получения существующего ресурса. В URL-адресе содержится вся необходимая информация для определения местонахождения и возвращения ресурса сервером.
POST: для создания нового ресурса. Запросы по методу POST обычно содержат данные для создания нового ресурса.
PUT:для обновления существующего ресурса. В содержимом могут находиться обновленные данные для ресурса.
DELETE:для удаления существующего ресурса.

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

Коды состояния (* значение, возвращаемой процедурой или функцией, показывающее состояние устройства или процесса)

1xx: Информация о процессе передачи

2xx: Информация об успешном принятии и обработке запроса клиента

3xx: Перенаправление

404 сообщает, что запрашиваемый ресурс не существует на сервере.

Этот код указывает клиенту, что необходимо будет выполнить дополнительное действие. Самый распространенный вариант – выполнение запроса по другому URL-адресу (* указанному в дополнительном заголовке Location) для получения запрашиваемого ресурса.

301 Moved Permanently (* Постоянно перемещен): запрошенный объект был окончательно перенесен на новый URL.
303 See Other (* Смотреть другой): запрошенный объект временно перенесен на новый URL. Временный URL указывается в заголовке Location ответа.
304 Not Modified (* Не модифицирован): сервер обнаружил, что ресурс не был изменен и клиенту следует использовать копию из кэша. Это реализуется за счет того, что клиент отсылает определенное значение (хэш-значение содержимого) в заголовке ETag (Entity Tag). Сервер сравнивает это значение со своим собственным токеном (* средство идентификации) для запрашиваемого ресурса на наличие изменений.

4xx: Информация об ошибках со стороны клиента

5xx: Информация об ошибках со стороны сервера

501 Not Implemented (* Не реализовано): сервер на данный момент не поддерживает возможностей, необходимых для обработки запроса.
503 Service Unavailable (* Сервис недоступен): сервер не имеет возможности обрабатывать запросы по техническим причинам или перегружен. Обычно сервер даже не будет отвечать, и запрос превысит лимит времени ожидания от сервера (* timeout; истечение времени ожидания события (обычно задается для операций с периферийными устройствами), по которому возникает и обрабатывается, например, ошибочная ситуация (timeout error)).

Общие заголовки

Мы уже знакомы с некоторыми из этих заголовков ( Via и Transfer-Encoding ). Мы рассмотрим Cache-Control и Connection во второй части.

В заголовках с префиксом Accept указываются допустимые для приема клиентом формы информации, язык и набор символов. В From , Host , Referer и User-Agent указываются детали о клиенте, отправившем запрос. Заголовки с префиксом If- используются для придания запросу гибкости, и сервер присылает ответ только тогда, когда заданное условие выполняется. В ином случае присылается ответ 304 Not Modified. Условие может быть задано на основе временной метки или ETag.

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

Число заголовков ответа также довольно ограничено; полный набор представлен ниже:

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

Без сомнений, фаворитом среди веб-разработчиков является инспектор Chrome/Webkit.

Также в их распоряжении имеются прокси для отладки веб-приложений, например, Fiddler (* работает с трафиком между вашим компьютером и удаленным сервером и позволяет просматривать и менять его) для Windows и Charles Proxy для OSX. Мой коллега, Rey Bango, написал замечательную статью на эту тему. Мой коллега, Rey Bango, написал замечательную статью на эту тему.

ExpressJS

Если вы создаете веб-серверы на Node.js, то наверняка уже знакомы с ExpressJS. Прототипом ExpressJS послужил веб-фреймворк для Ruby – Sinatra. Не удивительно, что API ExpressJS подобен его API.

Прочитать фрагменты URL и заголовки запроса.
Добавить заголовки ответа и тело.

ExpressJS как раз предоставляет для этого простой API. Мы не будем рассматривать детали API. Вместо этого я предоставлю вам ссылки на детальную документацию по ExpressJS. Здесь будут перечислены наиболее популярные. Некоторые примеры методов API, связанных с обработкой запросов, приведены ниже:

req.body: для получения тела запроса.
req.query: для получения фрагмента запроса URL.
req.host: для прочтения поля Host заголовка.
req.accepts: для получения допустимых на стороне клиента типов MIME (* многоцелевые расширения почты (почтовой службы) в Интернете; набор стандартов для передачи мультимедийной информации посредством электронной почты).
req.get или req.header: для прочтения любого поля заголовка, переданного в виде аргумента.

Для формирования ответа клиенту ExpressJS предоставляет следующий API:

res.status: для явного указания кода состояния.
res.set: для указания определенного заголовка.
res.send: для отправления HTML, JSON или последовательности октетов.
res.sendFile: для передачи файла клиенту.
res.render: для выполнения шаблона представления Express.
res.redirect: для перенаправления на другой маршрут. Express автоматически добавляет код по умолчанию о перенаправлении 302.

Ruby on Rails

ActionController предоставляет высокоуровневый API для получения URL запроса, обработки результата и перенаправления на другой маршрут. Конечная точка (маршрут) используется для выполнения указанного в нем метода (действия) (* например, если пользователь переходит по /clients/new в вашем приложении для добавления нового клиента, Rails создаст образец ClientsController и вызовет его метод new). Большинство необходимой контекстной (* связанной с конкретным запросом) информации внутри метода становится доступной благодаря объектам request , response и params .

params: предоставляет доступ к параметрам URL и данным, переданным по методу POST.
request: содержит информацию о клиенте, заголовках и URL.
response: используется для установления значений заголовков и кодов состояния.
render: для исполнения шаблонов.
redirect_to: используется для перенаправления к другому методу или на другой URL.

AJAX (* Asynchronous JavaScript And XML – асинхронный JavaScript + XML) jQuery

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

Резюме

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

Читайте также: