Tcp против udp или будущее сетевых протоколов

Методы протокола

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


Сервер может применять какие угодно методы. Для сервера или клиента нет методов являющихся обязательными. Если сервер не смог определить метод указанный клиентом, то он должен возвратить статус 501 – «Not Implemented». Если сервер определил метод, но его нельзя применить к конкретному ресурсу, то будет возвращено сообщение содержащее код 405 — «Method Not Allowed».

Во всех этих случаях сервер должен включить в ответное сообщение заголовок «Allow». Список включает в себя поддерживаемые методы. Все серверы обязаны поддерживать минимально методы GET и HEAD.

GET — применяется для запроса содержимого указанного источника. При помощи метода также можно начать какой-нибудь процесс. При этом в тело сообщения ответа нужно включить сведения о ходе реализации процесса. Клиент имеет возможность передать параметры исполнения запроса в URL целевого ресурса сразу после символа «?»: GET/path/resource?

HEAD – применяется аналогично методу GET. Отличие заключается в том, что в ответе сервера нет тела. Запрос HEAD как правило используется для извлечения метаданных, проверки существования ресурса, то есть валидация URL. Также этот запрос нужен для того, чтобы узнать, было ли изменение ресурса с момента предыдущего обращения. Еще одним часто используемым методом является метод POST.

Рекомендации по использованию HTTPS

Используйте надежные сертификаты безопасности

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

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

Используйте переадресацию 301 на стороне сервера

Перенаправляйте пользователей и поисковые системы на страницу с поддержкой HTTPS или ресурс с переадресацией 301 на стороне сервера для адресов HTTP.

Убедитесь, что страницы HTTPS можно сканировать и индексировать

  • Не запрещайте посредством файлов robots.txt сканировать и индексировать страницы HTTPS.
  • Не размещайте на страницах HTTPS метатеги .
  • Чтобы проверить, могут ли страницы быть просканированы, воспользуйтесь инструментом проверки URL.

Используйте технологию HSTS

На сайтах, использующих протокол HTTPS, рекомендуется применять технологию HSTS (HTTP Strict Transport Security). В этом случае браузер будет запрашивать страницы HTTPS, даже если пользователь введет в адресной строке. а Google будет предоставлять в результатах поиска только защищенные URL. Все это снижает вероятность показа пользователям незащищенного содержания.

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

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

  1. Выполните переход на HTTPS, не включая HSTS.
  2. Активируйте отправку заголовков HSTS с минимальным значением директивы max-age. Отслеживайте объем трафика пользователей и других клиентов, а также эффективность зависимых объектов, например объявлений.
  3. Постепенно увеличивайте значение max-age в заголовках HSTS.
  4. Если HSTS не затрудняет пользователям и поисковым системам просмотр веб-страниц, то сайт можно добавить в список предварительной загрузки. Большинство популярных браузеров использует этот список, чтобы проверять, защищен ли тот или иной сайт.

Включите предварительную загрузку HSTS

Чтобы повысить скорость загрузки и уровень безопасности страниц HTTPS, можно активировать . Также изучите требования на сайте hstspreload.org.

Распространенные проблемы

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

Описание Действие
Просроченные сертификаты. Вовремя обновляйте сертификаты.
В сертификате неправильно указано название сайта. Убедитесь, что вы получили сертификат для всех имен хостов, которые обслуживают ваш сайт. Предположим, в сертификате указан только хост www.example.com. Пользователь, который попытается перейти на example.com (без префикса «www.»), не попадет туда из-за несоответствия сертификата.
Не поддерживается указание имени сервера (). Ваш веб-сервер должен поддерживать SNI. Также рекомендуйте посетителям использовать поддерживаемые браузеры. SNI поддерживают все . Для поддержки устаревших браузеров вам понадобится выделенный IP-адрес.
Проблемы сканирования. Не блокируйте сканирование своего сайта HTTPS с помощью файла .
Проблемы индексирования. По возможности разрешите поисковым системам индексировать ваши страницы. Старайтесь не использовать метатег .
Старые версии протоколов. Старые версии протоколов уязвимы. Используйте последние версии библиотек TLS и протоколов.
Совмещение защищенных и незащищенных элементов. В страницы HTTPS можно встраивать только контент, который передается по протоколу HTTPS.
Разное содержание на страницах HTTP и HTTPS. Содержание на страницах HTTP и HTTPS должно быть идентичным.
Ошибки кода статуса HTTP на страницах с HTTPS. Убедитесь, что ваш сайт возвращает правильный код статуса HTTP. Например, для доступных страниц используется код , а для несуществующих ‒ или .

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

Структура протокола

Запрос

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

Request            = Request-Line	
                          *( generalheader	
                          | requestheader	
                          | entityheader )	
                          CRLF	
                          

Отклик

После получения и интерпретации сообщения-запроса, сервер реагирует, посылая HTTP сообщение отклик.

Response	= Status-Line	; Раздел 5.1
*( general-header	; Раздел 3.5
| response-header	; Раздел 5.2
| entity-header )	; Раздел 6.1
CRLF	
	; Раздел 6.2

Отправив HTTP-запрос серверу, клиент ожидает ответа. HTTP-ответ выглядит в целом аналогично запросу: статусная строка, список заголовков и тело ответа.

HTTP/1.1 200 OK
Server: nginx/0.5.35
Date: Tue, 22 Apr 2008 10:18:08 GMT
Content-Type: text/plain; charset=utf-8
Connection: close
Last-Modified: Fri, 30 Nov 2007 12:46:53 GMT
ETag: ``27e74f-43-4750063d''
Accept-Ranges: bytes
Content-Length: 34

User-agent: *
Disallow: /people

Объект и соединение

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


Структура ресурса и объекта

Постоянное HTTP соединение имеет много преимуществ:

  • При открытии и закрытии TCP соединений можно сэкономить время CPU и память, занимаемую управляющими блоками протокола TCP.
  • HTTP запросы и отклики могут при установлении связи буферизоваться (pipelining), образуя очередь. Буферизация позволяет клиенту выполнять множественные запросы, не ожидая каждый раз отклика на запрос, используя одно соединение TCP более эффективно и с меньшими потерями времени.
  • Перегрузка сети уменьшается за счет сокращения числа пакетов, сопряженных с открытием и закрытием TCP соединений, предоставляя достаточно времени для детектирования состояния перегрузки.
  • HTTP может функционировать более эффективно, так как сообщения об ошибках могут доставляться без потери TCP связи.Клиенты, использующие будущие версии HTTP, могут испытывать новые возможности, взаимодействуя со старым сервером, они могут после неудачи попробовать старую семантику. HTTP реализациям следует пользоваться постоянными соединениями.

Клиенты

Первоначально протокол HTTP разрабатывался для доступа к гипертекстовым документам Всемирной паутины. Поэтому основными реализациями клиентов являются браузеры (агенты пользователя). Для просмотра сохранённого содержимого сайтов на компьютере без соединения с Интернетом были придуманы офлайн-браузеры. При нестабильном соединении для загрузки больших файлов используются Менеджеры закачек. Они позволяют в любое время докачать указанные файлы после потери соединения с веб-сервером. Виртуальные атласы тоже используют HTTP.

Функциональность

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

HTTP следует заданному циклу всякий раз, когда посылает запрос:

  1. Браузер запросит HTML-страницу. Затем сервер возвращает HTML-файл с хоста.1
  2. Браузер запросит таблицу стилей. Затем сервер возвращает файл CSS.
  3. Браузер запрашивает изображение в формате JPG. Сервер возвращает файл JPG.
  4. Браузер запросит код JavaScript (язык программирования). После этого сервер возвращает JS-файл.
  5. Браузер запрашивает различные формы данных. Сервер возвращает данные в виде XML или JSON файлов.

Обслуживание соединения со стороны сервера

В основном сервер прослушивает входящие сообщения и обрабатывает их по мере поступления запросов. Операции сервера включают в себя:

  • создание сокета для начала прослушивания 80-го (или другого) порта,
  • получение запроса и анализ сообщения,
  • обработку ответа,
  • установку заголовка ответа,
  • отправку ответа клиенту,

прерывание соединение, если возникло сообщение: Connection: close.

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

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

PPP протокол был разработан на основе HDLC и дополнен некоторыми возможностями[какими?], которые до этого встречались только в проприетарных протоколах.

Автоматическая настройка

Link Control Protocol (LCP) обеспечивает автоматическую настройку интерфейсов на каждом конце (например, установка размера пакетов) и опционально проводит аутентификацию. Протокол LCP работает поверх PPP, то есть начальная PPP связь должна быть до работы LCP.

Другим вариантом аутентификации через PPP является Extensible Authentication Protocol (EAP).

После того, как соединение было установлено, поверх него может быть настроена дополнительная сеть. Обычно используется Internet Protocol Control Protocol (IPCP), хотя Internetwork Packet Exchange Control Protocol (IPXCP) и AppleTalk Control Protocol (ATCP) были когда-то популярны. Internet Protocol Version 6 Control Protocol (IPv6CP) получит большее распространение в будущем, когда IPv6 заменит IPv4 как основной протокол сетевого уровня.

Многопротокольная поддержка

PPP позволяет работать нескольким протоколам сетевого уровня на одном канале связи. Другими словами, внутри одного PPP-соединения могут передаваться потоки данных различных сетевых протоколов (IP, Novell IPX и т. д.), а также данные протоколов канального уровня локальной сети. Для каждого сетевого протокола используется Network Control Protocol (NCP), который его конфигурирует (согласовывает некоторые параметры протокола).

PPP NCP обеспечивает процесс создания соединения через PPP, инициирует и настраивает различные протоколы сетевого уровня такие как IP, IPX или AppleTalk.

Microsoft PPP поддерживает следующие NCP:

  • Internet Protocol Control Protocol (IPCP) для настройки IP.
  • Internetwork Packet Exchange Control Protocol (IPXCP) для настройки IPX.
  • AppleTalk Control Protocol (ATCP) для настройки AppleTalk.
  • NetBIOS Frames Control Protocol (NBFCP) для настройки NetBEUI.

Обнаружение закольцованных связей

PPP обнаруживает закольцованные связи, используя особенность, включающую magic numbers. Когда узел отправляет PPP LCP сообщения, они могут включать в себя магическое число. Если линия закольцована, узел получает сообщение LCP с его собственным магическим числом вместо получения сообщения с магическим числом клиента.

HTTP-заголовки

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

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

Заголовки запросов

К числу наиболее важных HTTP-заголовков, которые можно включать в запросы, но нельзя включать в ответы, относятся:

Заголовок Accept

Это список MIME-типов, принимаемых клиентом, в формате тип/подтип. Элементы списка должны разделяться запятыми:

Accept: text/html, image/gif, */*

Элемент */* указывает, что все типы будут приняты и обработаны клиентом. Если тип запрошенного файла не может быть обработан клиентом, возвращается ошибка HTTP 406 «Not acceptable» (недопустимо).

Заголовок From

Указывает адрес электронной почты в Интернете учетной записи пользователя, под которой работает клиент, направивший запрос:

From: 
Заголовок Referer

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

Referer: http://www.professorweb.ru
Заголовок User-Agent

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

User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.17 (KHTML, like Gecko) 
   Chrome/24.0.1312.56 Safari/537.17

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

Заголовки ответов

В ответы могут включаться следующие заголовки:

Заголовок Content-Type

Используется для указания типа данных, отправляемых получателю или, в случае метода HEAD, тип данных, который был бы отправлен в ответ на запрос GET:

Content-Type: text/html
Заголовок Expires

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

Expires: Fri, 19 Aug 2012 16:00:00 GMT
Заголовок Location

Определяет точное расположение другого ресурса, к которому может быть перенаправлен клиент. Если это значение представляет собой полный URL, сервер возвращает клиенту «redirect» для непосредственного извлечения указанного объекта:

Location: http://www.samplesite.com

Если ссылка на другой файл относится к серверу, должен указываться частичный URL.

Заголовок Server

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

Server: Microsoft-IIS/7.0

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

Несколько заголовков могут включаться как в запрос, так и в ответ, например:

Заголовок Date

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

Date: Tue, 16 Aug 2012 18:12:31 GMT
Заголовок Connection

В НТТР/1.0 мы могли использовать в запросе заголовок Connection, указывая, что хотим сохранить соединение после отправки ответа. Теперь такое поведение принято по умолчанию, и в HTTP/1.1 можно использовать заголовок Connection, чтобы указать, что постоянное соединение не нужно:

Connection: close

Как выглядит процесс покупки/получения сертификата?

Рассмотрим процесс на примере самого простого сертификата с проверкой домена (DV).

Шаг 1. Регистрируемся на сайте центра сертификации или на сайте партнера.


Шаг 2. Выбираем тип сертификата, который нам нужен. Например, сертификат для одного домена с минимальной проверкой (DV).

Шаг 3. Генерируем CSR-запрос на сертификат. CSR (Certificate Signing Request) — это запрос на получение сертификата, который представляет собой текстовый файл, содержащий в закодированном виде информацию об администраторе домена и открытый ключ. Обычно CSR генерируется в процессе заказа SSL-сертификата.

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

Шаг 4. Оплачиваем сертификат (если вы выбрали платный вариант).

Шаг 6. Дожидаемся выпуска сертификата и скачиваем его. 

Шаг 7. Устанавливаете сертификат на сайт, используя файл(ы) сертификата и фаил-ключа, который у вас получился на третьем шаге. Если ваш сайт расположен на обычном хостинге, то лучше предварительно написать в сапорт и уточнить, как правильно установить сертификат. Если у вас свой сервер, то просто передайте все файлы администратору, он сам за 5 минут все установит.

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

А чтобы вам было проще во всем этом разобраться, я записал для вас несколько видеоуроков о том, как получать/покупать SSL-сертификаты. Я рассмотрел три случая.

1. Получение бесплатного SSL-сертификата в центре сертификации StartCom своими силами.

(на данный момент, все сертификаты выпущенные этим центром после 21.10.16 не поддерживаются новыми версиями браузеров Google Chrome и Mozilla Firefox. Лучше пока не использовать этот центр сертификации.)

Это видео на YouTube

Это видео на YouTube

Это видео на YouTube

2. Покупка SSL-сертификата за 470 рублей от топ-центра сертификации Comodo у партнера FirstSSL.

Из этого видео вы узнаете как купить сертификат Comodo PositiveSSL через партнера FirstSSL. Рекомендую этот вариант для важных проектов т.к. здесь вы получаете сертификат от одного из самых надежных центров сертификации.

Это видео на YouTube

Это видео на YouTube

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


С этим читают