HTTP-протокол

---

прошлое

• Серия интервьюеров (1): Как реализовать глубокое клонирование
• Серия интервьюеров (2): Реализация шины событий
• Серия интервьюеров (3): Реализация внешней маршрутизации
• Серия интервьюеров (4): Преимущества двустороннего связывания на основе перехвата данных прокси
• Серия интервью (5): Почему вы используете интерфейсный фреймворк
• Interviewer Series (6): Вы когда-нибудь писали «Универсальные интерфейсные компоненты»?
• Серия интервьюеров (7): Поговорим о Вавилоне
• Серия интервьюеров (8): Как реализовать «неизменную структуру данных», подчеркнутую React?

---

Каковы методы http?

• HTTP1.0 определяет три метода запроса: методы GET, POST и HEAD.
• HTTP1.1 добавил пять новых методов запроса: OPTIONS, PUT, DELETE, TRACE и CONNECT.

Что именно делают эти методы?

• GET: обычно используется для запроса сервера на отправку некоторых ресурсов.
• HEAD: Информация о заголовке запрошенного ресурса, и эти заголовки такие же, как те, которые возвращаются при запросе метода HTTP GET. Один из сценариев использования этого метода запроса — получить размер большого файла перед его загрузкой, а затем решить, следует ли чтобы загрузить его, чтобы сэкономить ресурсы пропускной способности
• OPTIONS: используется для получения параметров связи, поддерживаемых целевым ресурсом.
• POST: отправить данные на сервер
• PUT: используется для добавления ресурса или замены представления целевого ресурса полезной нагрузкой в ​​запросе.
• DELETE: используется для удаления указанного ресурса
• PATCH: используется для частичного изменения ресурсов.
• CONNECT: зарезервировано в протоколе HTTP/1.1 для прокси-серверов, которые могут изменять подключения к каналам.
• TRACE: повторить запрос, полученный сервером, в основном для тестирования или диагностики

В чем разница между GET и POST?

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

И PUT, и POST отправляют новые ресурсы на сервер, в чем разница?

Разница между методами PUT и POST заключается в том, что метод PUT является идемпотентным: вызов его один или несколько раз подряд имеет тот же эффект (без побочных эффектов), в то время как метод POST не является идемпотентным.

В дополнение к этому есть еще одно отличие: обычно URI PUT указывает на конкретный отдельный ресурс, а POST может указывать на набор ресурсов.

Например, мы разрабатываем систему блогов, когда мы хотим создать статью, мы часто используемPOST https://www.jianshu.com/articles, семантика этого запроса заключается в создании новой статьи в коллекции статей ресурсов. Если мы отправим этот запрос несколько раз, будет создано несколько статей, что не является идемпотентным.

а такжеPUT https://www.jianshu.com/articles/820357430Семантика заключается в обновлении ресурсов в соответствующей статье (например, изменение имени автора и т. д.). Этот URI указывает на один ресурс и является идемпотентным. Например, если вы замените «Энди Лау» на «Цай Сюкун», сколько раз вы отправите его, он будет изменен на «Цай Сюкунь».

ps: "POST означает создание ресурсов, PUT означает обновление ресурсов" неверно, оба могут создавать ресурсы, принципиальное различие заключается в идемпотентности

И PUT, и PATCH отправляют измененные ресурсы на сервер, в чем разница?

И PUT, и PATCH являются ресурсами обновления, а PATCH используется для локального обновления известных ресурсов.

Например, у нас есть адрес статьиhttps://www.jianshu.com/articles/820357430, этот артикль может быть выражен как:

article = {
    author: 'dxy',
    creationDate: '2019-6-12',
    content: '我写文章像蔡徐坤',
    id: 820357430
}

Когда мы хотим изменить автора статьи, мы можем отправить напрямуюPUT https://www.jianshu.com/articles/820357430, данные в это время должны быть:

{
    author:'蔡徐坤',
    creationDate: '2019-6-12',
    content: '我写文章像蔡徐坤',
    id: 820357430
}

Этот метод модификации прямой перезаписи ресурсов должен использовать put, но если вы чувствуете, что каждый раз так много бесполезной информации, вы можете отправитьPATCH https://www.jianshu.com/articles/820357430, на этот раз нужно только:

{
    author:'蔡徐坤',
}

На что похоже сообщение HTTP-запроса?

Сообщение запроса состоит из 4 частей:

• строка запроса
• заголовок запроса
• пустая строка
• тело запроса

• Строка запроса включает: поле метода запроса, поле URL и поле версии протокола HTTP. Они разделены пробелами. Например, GET /index.html HTTP/1.1.
• Заголовок запроса: Заголовок запроса состоит из пар ключевое слово/значение, по одной паре в строке, а ключевое слово и значение разделяются английским двоеточием ":"

1. User-Agent: тип браузера, выполнившего запрос.
2. Принять: список типов контента, распознаваемых клиентом.
3. Хост: запрошенное имя хоста, несколько доменных имен могут использовать один и тот же IP-адрес, то есть виртуальный хост.

• Тело запроса: данные, передаваемые запросами, такими как post put

Как выглядит ответное сообщение HTTP?

Сообщение запроса состоит из 4 частей:

• строка ответа
• заголовок ответа
• пустая строка
• тело ответа

• Строка ответа: Состоит из версии протокола, кода состояния и фразы причины для кода состояния, например.HTTP/1.1 200 OK.
• Заголовок ответа: радикальная композиция ответа
• Тело ответа: данные ответа сервера.

Давайте поговорим о радикалах HTTP?

Контента много, ориентируйтесь на контент с пометкой "✨"

Общие поля заголовка: заголовки, используемые как сообщением запроса, так и сообщением ответа.

• Кэш управления кешем ✨
• Управление подключением подключения, пошаговый заголовок ✨
• Обновление Обновление до других протоколов
• Информация о прокси-сервере
• Написание уведомлений об ошибках и предупреждений
• Transfor-Encoding Формат кодирования передачи тела сообщения ✨
• Список заголовков в конце сообщения трейлера
• Инструкция сообщения прагмы
• Дата Дата создания сообщения

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

• Примите типы мультимедиа, которые может обрабатывать клиент или прокси ✨
• Accept-Encoding отдает приоритет формату кодирования, который может быть обработан
• Accept-Language отдает приоритет обрабатываемому естественному языку
• Accept-Charset отдает приоритет набору символов, который может быть обработан
• Тег объекта сравнения If-Match (ETage) ✨
• If-None-Match сравнивает теги сущностей (ETage) в отличие от If-Match ✨
• If-Modified-Since Сравните время обновления ресурса (Last-Modified)✨
• If-Unmodified-Since сравнивает время обновления ресурса (Last-Modified), в отличие от If-Modified-Since ✨
• If-Rnages Отправить запрос диапазона байтов объекта, когда ресурс не обновлен
• Запрос диапазона байтов на сущность диапазона ✨
• Информация для веб-аутентификации авторизации ✨
• Прокси-авторизация Прокси-сервер требует информацию веб-аутентификации
• Хост Сервер, на котором находится запрошенный ресурс ✨
• С адреса электронной почты пользователя
• Информация о клиентской программе User-Agent ✨
• Max-Forwrads максимальное количество переходов
• Приоритет TE Transfer Coding
• Реферер запрашивает исходный URL
• Expect ожидает определенного поведения от сервера

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

• Accept-Ranges Допустимый диапазон байтов
• Возраст Вычисляет время, прошедшее с момента создания ресурса.
• URI местоположения для перенаправления клиента на ✨
• изменить информацию кеша прокси-сервера
• ETag — это строка, которая может представлять уникальный ресурс ресурса ✨
• Сервер WWW-Authenticate требует аутентификационную информацию от клиента.
• Proxy-Authenticate Прокси-сервер требует аутентификационную информацию от клиента
• Информация о сервере сервера ✨
• Поле заголовка Retry-After, используемое с кодом состояния 503, указывающее время следующего запроса к серверу.

Поля Entiy Header: Используйте заголовок для сущности части сообщения запроса и ответного сообщения.

• Разрешить ресурс поддерживает метод HTTP-запроса
• Язык ресурса сущности Content-Language
• Формат кодирования объекта Content-Encoding
• Размер объекта Content-Length (байты)
• Тип носителя объекта Content-Type
• Дайджест сообщения сущности Content-MD5
• Content-Location заменяет yri ресурса
• Расположение тела объекта Content-Rnages возвращается
• Ресурс Last-Modified Ресурс, измененный последним ✨
• Ресурс с истекшим сроком действия для тела объекта Expires ✨

Что такое коды состояния HTTP?

2ХХ успехов

• 200 OK, что говорит о том, что запрос, отправленный от клиента, корректно обрабатывается на стороне сервера ✨
• 201 Created Запрос выполнен, и новый ресурс создан в соответствии с потребностями запроса
• 202 ACCEPTED запрос принят, но не выполнен, не гарантирует выполнения запроса
• 204 Нет содержимого, что указывает на то, что запрос выполнен успешно, но ответное сообщение не содержит основной части сущности
• 206 Частичный контент, сделайте запрос диапазона ✨

3XX редирект

• 301 перемещен навсегда, постоянное перенаправление, указывающее, что ресурсу был присвоен новый URL-адрес
• 302 найдено, временное перенаправление, указывающее на то, что ресурсу временно присвоен новый URL ✨
• 303 см. другое, что указывает на то, что для ресурса существует другой URL-адрес, и для получения ресурса следует использовать метод GET.
• 304 не изменено, указывающее на то, что сервер разрешает доступ к ресурсу, но запрос не соответствует условиям из-за возникновения
• 307 временное перенаправление, временное перенаправление, имеет то же значение, что и 302

4XX Ошибка клиента

• 400 неверный запрос, в сообщении запроса есть синтаксическая ошибка ✨
• 401 неавторизованный, что указывает на то, что для отправленного запроса требуется аутентификационная информация, прошедшая HTTP-аутентификацию ✨
• 403 Запрещено, что указывает на то, что доступ к запрошенному ресурсу был отклонен сервером ✨
• 404 не найден, указывая на то, что запрошенный ресурс не был найден на сервере ✨
• 408 Время ожидания запроса истекло, время ожидания запроса клиента истекло
• 409 Конфликт, запрошенный ресурс может вызвать конфликт

5ХХ ошибка сервера

• 500 внутренняя ошибка сервера, указывающая на то, что при выполнении запроса произошла ошибка на стороне сервера ✨
• 501 Not Implemented Запрос выходит за рамки возможностей сервера, например, сервер не поддерживает функцию, требуемую текущим запросом, или запрос представляет собой метод, который сервер не поддерживает
• Служба 503 недоступна, что указывает на то, что сервер временно перегружен или отключен на техническое обслуживание и не может обрабатывать запросы.
• 505 HTTP-версия не поддерживается Сервер не поддерживает или отказывается поддерживать версию HTTP, используемую в запросе

Такая же разница между редиректом 307, 303, 302?

302 — это код состояния протокола http1.0.В версии http1.1 вышло два 303 и 307, чтобы уточнить код состояния 302.

303 четко указывает, что клиент должен использовать метод get для получения ресурсов, и он перенаправит запрос POST в запрос GET. 307 будет следовать стандартам браузера и не изменится от поста к получению.

Что делает HTTP keep-alive?

В ранней версии HTTP/1.0 соединение создавалось для каждого HTTP-запроса, и процесс создания соединения требовал затрат ресурсов и времени, чтобы уменьшить потребление ресурсов и сократить время отклика, необходимо было повторно использовать соединения. В более поздних версиях HTTP/1.0 и HTTP/1.1 был введен механизм повторного использования соединений, то есть добавление Connection: keep-alive в заголовок http-запроса, чтобы указать другой стороне не закрывать запрос после завершения ответа, и мы воспользуемся этим запросом в следующий раз. Продолжайте общаться. Протокол предусматривает, что если HTTP/1.0 хочет поддерживать длительное соединение, вам необходимо добавить Connection: keep-alive в заголовок запроса.

Преимущества Keep-Alive:

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

Зачем нам HTTPS, когда у нас есть HTTP?

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

Как защищен HTTPS?

Процесс более сложный, мы должны сначала понять две концепции

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

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

Асимметричное шифрование:

1. закрытый ключ + открытый ключ = пара ключей
2. То есть данные, зашифрованные закрытым ключом, могут быть расшифрованы только соответствующим открытым ключом, а данные, зашифрованные открытым ключом, могут быть расшифрованы только соответствующим закрытым ключом.
3. Поскольку обе стороны в общении имеют набор своих собственных пар ключей, обе стороны будут отправлять свои открытые ключи другой стороне перед общением.
4. Затем другая сторона берет этот открытый ключ для шифрования данных и отвечает другой стороне.Когда другая сторона достигает другой стороны, другая сторона расшифровывает их своим собственным закрытым ключом.

Хотя асимметричное шифрование более безопасно, проблема в том, что оно очень медленное и влияет на производительность.

решение:

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

В этот момент возникает другая проблема, проблема посредника:

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

Поэтому в настоящее время требуется безопасный сторонний сертификат (CA) для подтверждения подлинности личности и предотвращения атак «человек посередине».

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

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

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

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

В это время безопасность связи может быть гарантирована в наибольшей степени.

Каковы преимущества и особенности HTTP2 по сравнению с HTTP1.x?

Бинарное кадрирование

Кадр: Наименьшая единица передачи данных HTTP/2.Сообщение: Относится к логическому сообщению HTTP в HTTP/2. Например, запросы и ответы и т. д., сообщение состоит из одного или нескольких кадров.

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

HTTP/2 передает данные в двоичном формате, а не в текстовом формате HTTP 1.x, а двоичный протокол более эффективен для анализа.

пуш сервера

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

Сервер может активно пушить, а клиент вправе выбирать, получать его или нет. Если ресурс, переданный сервером, был кэширован браузером, браузер может отклонить его, отправив кадр RST_STREAM. Active push также соответствует политике того же источника, и сервер не будет небрежно передавать сторонние ресурсы клиенту.

сжатие заголовка

HTTP/1.x постоянно содержит редко меняющиеся длинные заголовки в запросах и ответах, что создает дополнительную нагрузку на сеть.

• HTTP/2 использует «таблицу заголовков» на стороне клиента и сервера для отслеживания и хранения ранее отправленных пар ключ-значение, больше не отправляя каждый запрос и ответ для одних и тех же данных.
• Таблица заголовков всегда существует во время соединения HTTP/2 и постепенно обновляется клиентом и сервером;
• Каждая новая пара ключ-значение заголовка либо добавляется в конец текущей таблицы, либо заменяет предыдущее значение в таблице.

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

мультиплексирование

В HTTP 1.x, если вы хотите делать несколько запросов одновременно, вы должны использовать несколько TCP-соединений, а для управления ресурсами браузер также имеет ограничение в 6-8 запросов TCP-соединений для одного доменного имени.

В HTTP2:

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

Дальнейшее чтение:Возможности HTTP/2 и их производительность в практических приложениях

---

todo

• Каков весь процесс https?
• Какова стратегия кэширования для http? продолжение следует. .

---

Ссылаться на:

• Графический HTTP
• Полное руководство по HTTP