Протоколы.

IPX / SPX.

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

WebSocket.

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

Чем отличается HTTP от WebSocket?

В отличие от традиционного HTTP, который работает по принципу «запрос-ответ», WebSocket позволяет клиенту и серверу обмениваться данными без необходимости инициировать новые соединения.

Сокеты.

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

Связь.

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

Работа через сеть.

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

Программирование.

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

Типы сокетов.

Существует два основных типа сокетов:

• TCP-сокеты обеспечивают надежную и последовательную передачу данных (например, для веб-сайтов).
• UDP-сокеты быстрее, но менее надежны (например, для потокового видео или онлайн-игр).

UDP.

User Datagram Protocol, о связке которого с протоколом TCP, представляет собой протокол передачи данных, не требующий предварительной установки соединения между хостами. Он быстрый, но часто теряет пакеты данных во время доставки.

FTP.

File Transfer Protocol — надёжный протокол прикладного уровня для передачи файлов. Использует два канала для передачи данных.

• Первый, управляющий процессом передачи, называют командным.
• Второй, передающий информацию — транспортным.

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

RTP.

Real-time Transfer Protocol — транспортный протокол, работающий в реальном времени. Нужен для потоковой передачи аудио- и видеоданных. Умеет передавать данные нескольким получателям одновременно. Чаще всего применяется для передачи голоса в IP-телефонии.

ICMP.

Internet Control Message Protocol — важный протокол, который нужен для слежения за ошибками во взаимодействии устройств. Он диагностирует проблемы и определяет, получены ли данные отправителем. Если нет, протокол ICMP генерирует ошибку для отправки на отправляющее устройство. Данный протокол иногда используется злоумышленниками для сетевых атак путём генерации большого объема ICMP-сообщений.

SMTP.

Simple Mail Transfer Protocol — это сетевой протокол, используемый для передачи электронных писем между почтовыми серверами. Он был разработан в 1982 году и стал стандартом для отправки сообщений в интернете. Протокол SMTP работает по модели «клиент-сервер», где «клиент» — это почтовая программа (например, Outlook или Thunderbird), а «сервер» — это почтовый сервер, который отвечает за отправку и получение сообщений.

NTP.

Network Time Protocol — протокол для синхронизации локальных часов устройства с точным временем в интернете. NTP работает на базе алгоритма Марзулло поверх UDP. За счёт этого удаётся добиться более высокой точности времени и скорости передачи данных.

SSH.

Secure Shell — защищённый протокол прикладного уровня, необходимый для удалённого управления ОС через протокол TCP. В SSH весь трафик шифруется с использованием заданного алгоритма шифрования. Протокол позволяет обрабатывать другие сетевые протоколы передачи, включая аудио- или видеопоток.
Его удобно использовать для удалённого подключения клиента к серверу и работы оттуда.

TCP / IP.

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

DNS.

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

Реальные веб-адреса — неудобные, незапоминающиеся строки, эти строки состоят из чисел, например: 63.245.215.20. Такой набор чисел называется IP-адресом и представляет собой уникальное местоположение в Интернете. Его не очень легко запомнить. Вот поэтому и изобрели DNS. Это специальные сервера, которые связывают веб-адрес, который вводится в браузер (например, «google.com»), с реальным IP-адресом сайта.

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

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

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

• HTTP (HyperText Transfer Protocol) — используется для передачи веб-страниц и других ресурсов в Интернете.
• FTP (File Transfer Protocol) — предназначен для передачи файлов между клиентом и сервером.
• SMTP (Simple Mail Transfer Protocol) — используется для отправки электронной почты.
• DNS (Domain Name System) — отвечает за преобразование доменных имен в IP-адреса.
• SSH (Secure Shell) — обеспечивает безопасный доступ к удалённым системам.

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

HTTP протокол.

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

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

HTTP использует порт 80, HTTPS — порт 443.

SSL / TLS.

Протокол HTTPS работает благодаря сертификату SSL/TLS. Такие сертификаты в интернете — что-то вроде удостоверения личности. С их помощью браузер и домен идентифицируют друг друга и только потом устанавливают защищенное соединение и начинают передавать данные.

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

Протокол HTTPS предназначен для защиты данных пользователей. Эта защита настраивается с помощью SSL-сертификата шифрует данные.

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

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

Шифрование HTTPS происходит при помощи симметричного и асимметричного ключа:

Асимметричный ключ.

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

Симметричный ключ.

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

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

Функция протокола HTTPS.

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

Шифрование HTTPS происходит по алгоритму:

• Браузер запрашивает SSL-сертификат у сайта.
• Сайт предоставляет сертификат и открытый ключ.
• Браузер проверяет SSL-сертификат в центре сертификации.
• Если сертификат подлинный, браузер при помощи ассиметричного ключа (открытый ключ) шифрует сеансовый ключ и отправляет его на сервер.
• Сервер закрытым ключом расшифровывает сеансовый ключ и между браузером и сайтом установлено безопасное соединение по которому передают зашифрованную информацию друг другу.

Открытый ключ.

Браузер и веб-сервер обмениваются данными путем кодирования и декодирования информации с использованием пар открытого и закрытого ключей. Открытый ключ — это криптографический ключ, который веб-сервер предоставляет браузеру в сертификате SSL / TLS. Браузер использует ключ для шифрования информации перед ее отправкой на веб-сервер.

Закрытый ключ.

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

Аутентификация.

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

Цифровая подпись.

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

Что входит в сертификат SSL / TLS?

Сертификат SSL / TLS содержит следующую информацию.

• Доменные имена.
• Центр сертификации.
• Цифровая подпись центра сертификации.
• Дата выпуска.
• Дата истечения срока действия.
• Открытый ключ.
• Версия SSL / TLS.

Какие существуют типы сертификатов SSL / TLS?

Сертификаты SSL / TLS различаются в зависимости от проверки и домена. Сертификаты с разными уровнями проверки классифицируются следующим образом:

• Сертификаты расширенной проверки.
• Сертификаты, подтвержденные организацией.
• Сертификаты, подтвержденные доменом.

Сертификаты SSL / TLS, поддерживающие различные типы доменов:

• Сертификат на один домен.
• Подстановочный сертификат.
• Мультидоменный сертификат.

HTTP 1, 2 и 3.

Причина появления версий 2 и 3 — скорость:

• Скорость загрузки страницы в браузере.
• Скорость установления соединения.
• Скорость обмена данными между сервером и страницей.
• Скорость обмена данными между сервисами / микросервисами.

Что мешает HTTP1 работать быстро, в порядке значимости:

• Блокировка соединения.
• Время на установление соединения.
• Объем обязательных данных.

HTTP1 в HTTP2.

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

Для того чтобы установить шифрованное соединение и обмениваться данными для HTTP1 или HTTP2 нам необходимо сделать от 2х до 3х рукопожатий. Одно рукопожатие для установления TCP соединения, 1 или 2 рукопожатия, в зависимости от версии протокола, для установления шифрованного соединения. Итого 2-3 рукопожатия.

• HTTP1 = кол-во соединений x кол-во рукопожатий / 1-6 x 2-3 = 2-18
• HTTP2 = кол-во рукопожатий / 2-3

HTTP2 в HTTP3 / QUIC.

Проблема блокировки была решена в версии 2 — но только на уровне HTTP протокола. На транспортном уровне TCP она все еще есть в виде обязательного последовательного получения пакетов. Поэтому версию 3 собрали на протоколе UDP, в которой этой особенности нет, и назвали это QUIC.
В третьей версии, поскольку собрали новый протокол QUIC, обо всём хорошо подумали и рукопожатия свели к одному. В один запрос упаковали установление соединения и установление шифрования.
Плюс в версии 3 при разрыве соединения не нужно устанавливать новое, то есть не будет повторных рукопожатий, так как используется уникальный идентификатор соединения.

HTTP3 / QUIC = const 1

HTTP1 в HTTP2 и HTTP3 / QUIC

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

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

HTTP протокол не хранит сущность.

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

Keep-alive.

Постоянное HTTP-соединение, также называемые HTTP

keep-alive или повторное использование соединений HTTP — использование одного TCP-соединения для отправки и получения многократных HTTP-запросов и ответов вместо открытия нового соединения для каждой пары запрос-ответ.

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

Данные, в зависимости от используемого метода передаются от клиента к серверу 2-мя способами. (В заголовке и в теле запроса).

GET.

Получение данных с сервера (например, поиск в google, пролистывание ленты в Instagram, просмотр видео на YouTube). (Происходит работа с имеющимися данными.) При использовании метода GET данные отправляются в URL-адресе, то есть в заголовке запроса. 3 вида заголовков (основные, запроса, ответа).

При использовании методов POST, PUT, DELETE данные отправляются на сервер в теле запроса. Для того чтобы скрыть от посторонних глаз и защитить данные. Данные передаются в формате JSON. 4 вида заголовка (основные, запроса, ответа и тело запроса).

POST.

Создать новые данные (например, отправка сообщений в vk, записать историю в Instagram, добавить комментарий под видео в YouTube).

PUT.

Обновить данные или создать новые, если таких не существует (например, изменить логин в Instagram, отредактировать отправленное сообщение vk).

PATCH.

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

Отличие PUT от PATCH.

В REST API методы PUT и PATCH имеют разные семантики и, соответственно, разные подходы к идемпотентности:

PUT.

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

Идемпотентность: многократное выполнение одного и того же PUT-запроса приведет к одному и тому же состоянию ресурса. Если повторно отправить PUT-запрос с теми же данными, то состояние ресурса не изменится после первого запроса.

PATCH.

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

Идемпотентность: PATCH тоже может быть идемпотентным (например, если одно и то же поле обновляется одним и тем же значением), но не всегда. Если, например, отправляется запрос, который увеличивает счетчик, то каждое повторное выполнение будет изменять состояние ресурса, и в этом случае PATCH не будет идемпотентным.

Резюмируя:

• PUT всегда идемпотентен, так как полное представление ресурса заменяет его текущее состояние.
• PATCH может быть идемпотентен, но это зависит от логики изменения.

Идемпотентность.

Идемпотентность — это свойство операций, при котором повторное выполнение одной и той же операции не приводит к изменению результата после первого выполнения, независимо от количества повторений. В контексте RESTful API идемпотентность означет, что выполнение одного и того же

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

Почему метод POST не идемпотентный?

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

DELETE.

Удалить данные (например, удалить пост из Instagram, удалить сообщение vk, удалить видео с канала на YouTube).

HEAD.

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

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

OPTIONS.

Используется для описания параметров соединения с целевым ресурсом. Клиент может указать особый URL для обработки метода OPTIONS, или * (звёздочку) чтобы указать весь сервер целиком.

Заголовки HTTP протокола.

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

Заголовки сгруппированы следующим образом:

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

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

• General (рус. Общий) — передается url, метод, статус код, удаленный адрес, политика рефералов.
• Response Headers (рус. Заголовки ответа) — только для ответов от сервера.
• Request Headers (рус. Заголовки запроса) — используются только в запросах клиента.

Использование.

• Контроль кэширования. Заголовки HTTP могут указывать, должны ли браузеры кэшировать ресурс и на какой период времени. Это позволяет уменьшить количество запросов к серверу и ускорить загрузку страниц.
• Аутентификация. HTTP заголовки могут использоваться для передачи информации об аутентификации, такой как токен доступа или логин и пароль. Это позволяет защитить ресурсы, доступ к которым должен быть ограничен.
• Управление сеансом. Здесь заголовки HTTP могут указывать, должны ли браузеры сохранять данные о сеансе и как долго они должны храниться. Это может быть использовано для создания персонализированных сеансов для каждого пользователя.
• Определение типа контента. В этом случае HTTP заголовки могут указывать тип контента, который возвращается сервером, например, HTML, изображение или документ PDF. Это помогает браузеру правильно отображать контент и обрабатывать его соответствующим образом.

Заголовки.

• User-Agent — позволяет серверу идентифицировать браузер или другое приложение, которое отправляет запрос на сервер.
• Content-Type — указывает тип контента, возвращаемого сервером, например, текст, HTML, JSON, изображение и т.д.
• Content-Length — указывает размер содержимого ответа в байтах.
• Cache-Control — позволяет определить, должен ли браузер кэшировать ответ и на какой период времени.
• Accept — позволяет клиенту указать типы контента, которые он готов принять от сервера.
• Authorization — используется для передачи информации об аутентификации, например, токен доступа или логин и пароль.
• User-Cache-Control — позволяет клиенту управлять кэшированием ответа на стороне браузера.

Статус код.

Показывает результат того или иного запроса.

Список всех ответов.

1xx: Informational (информационные):

• [100 Continue] («продолжайте»).
• [101 Switching Protocols] («переключение протоколов»).
• [102 Processing] («идёт обработка»).
• [103 Early Hints] («ранняя метаинформация»).

2xx: Success (успешно):

• [200 OK] («хорошо»).
• [201 Created] («создано»).
• [202 Accepted] («принято»).
• [203 Non-Authoritative Information] («информация не авторитетна»).
• [204 No Content] («нет содержимого»).
• [205 Reset Content] («сбросить содержимое»).
• [206 Partial Content] («частичное содержимое»).
• [207 Multi-Status] («многостатусный»).
• [208 Already Reported] («уже сообщалось»).
• [226 IM Used] («использовано IM»).

3xx: Redirection (перенаправление):

• [300 Multiple Choices] («множество выборов»).
• [301 Moved Permanently] («перемещено навсегда»).
• [302 Found] («найдено»).
• [303 See Other] («смотреть другое»).
• [304 Not Modified] («не изменялось»).
• [305 Use Proxy] («использовать прокси»).
• [306 Зарезервировано] (код использовался только в ранних спецификациях).
• [307 Temporary Redirect] («временное перенаправление»).
• [308 Permanent Redirect] («постоянное перенаправление»).

4xx: Client Error (ошибка клиента):

• [400 Bad Request] («неправильный, некорректный запрос»).
• [401 Unauthorized] («не авторизован»).
• [402 Payment Required] («необходима оплата») — зарезервировано для использования в будущем.
• [403 Forbidden] («запрещено (не уполномочен)»).
• [404 Not Found] («не найдено»).
• [405 Method Not Allowed] («метод не поддерживается»).
• [406 Not Acceptable] («неприемлемо»).
• [407 Proxy Authentication Required] («необходима аутентификация прокси»).
• [408 Request Timeout] («истекло время ожидания»).
• [409 Conflict] («конфликт»).
• [410 Gone] («удалён»).
• [411 Length Required] («необходима длина»).
• [412 Precondition Failed] («условие ложно»).
• [413 Payload Too Large] («полезная нагрузка слишком велика»).
• [414 URI Too Long] («URI слишком длинный»).
• [415 Unsupported Media Type] («неподдерживаемый тип данных»).
• [416 Range Not Satisfiable] («диапазон не достижим»).
• [417 Expectation Failed] («ожидание не оправдалось»).
• [418 I’m a teapot] («я — чайник»).
• [419 Authentication Timeout (not in RFC 2616)] («обычно ошибка проверки CSRF»).
• [421 Misdirected Request].
• [422 Unprocessable Entity] («необрабатываемый экземпляр»).
• [423 Locked] («заблокировано»).
• [424 Failed Dependency] («невыполненная зависимость»).
• [425 Too Early] («слишком рано»).
• [426 Upgrade Required] («необходимо обновление»).
• [428 Precondition Required] («необходимо предусловие»).
• [429 Too Many Requests] («слишком много запросов»).
• [431 Request Header Fields Too Large] («поля заголовка запроса слишком большие»).
• [449 Retry With] («повторить с»).
• [451 Unavailable For Legal Reasons] («недоступно по юридическим причинам»).
• [499 Client Closed Request] (клиент закрыл соединение).

5xx: Server Error (ошибка сервера):

• [500 Internal Server Error] («внутренняя ошибка сервера»).
• [501 Not Implemented] («не реализовано»).
• [502 Bad Gateway] («плохой, ошибочный шлюз»).
• [503 Service Unavailable] («сервис недоступен»).
• [504 Gateway Timeout] («шлюз не отвечает»).
• [505 HTTP Version Not Supported] («версия HTTP не поддерживается»).
• [506 Variant Also Negotiates] («вариант тоже проводит согласование»).
• [507 Insufficient Storage] («переполнение хранилища»).
• [508 Loop Detected] («обнаружено бесконечное перенаправление»).
• [509 Bandwidth Limit Exceeded] («исчерпана пропускная ширина канала»).
• [510 Not Extended] («не расширено»).
• [511 Network Authentication Required] («требуется сетевая аутентификация»).
• [520 Unknown Error] («неизвестная ошибка»).
• [521 Web Server Is Down] («веб-сервер не работает»).
• [522 Connection Timed Out] («соединение не отвечает»).
• [523 Origin Is Unreachable] («источник недоступен»).
• [524 A Timeout Occurred] («время ожидания истекло»).
• [525 SSL Handshake Failed] («квитирование SSL не удалось»).
• [526 Invalid SSL Certificate] («недействительный сертификат SSL»).