«Поиск и заполнение пробелов» для консолидации вашей системы знаний HTTP

предисловие

Объем этого обзора в основном связан с сетевой частью, включая HTTP и т. д. Он также очень полезен для консолидации собственной системы знаний о сети, а также очень полезна дальнейшая оптимизация производительности.

Но это скорее введение, надеюсь оно вам поможет.

Спасибо за вашу поддержку и поддержку🌹🌹🌹, предыдущие статьи разобраны в конце (●'◡'●)

Далее будет разбирать в виде вопросов👇

Расскажите о преимуществах и недостатках протокола HTTP.

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

HTTP-функции

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

Недостатки HTTP

"нет статуса", Иногда необходимо сохранять информацию, такую как системы покупок, информацию о клиентах и т. д. С другой стороны, иногда безгражданство также снижает нагрузку на сеть, например, в индустрии прямых трансляций и т. д. Это все еще разделено в сценарии.
"передача открытого текста", то есть сообщение в протоколе (в основном, относящееся к заголовку) использует не бинарные данные, а текстовую форму. Это раскрывает информацию о сообщениях HTTP для внешнего мира, что удобно для злоумышленников.
"блокировка в начале очереди", когда http открывает длинное соединение, TCP-соединение используется совместно. Когда запрос занимает слишком много времени, другие запросы могут находиться только в состоянии блокировки, что является проблемой блокировки заголовка строки.

Различия между версиями HTTP/1.0 HTTP1.1 HTTP2.0

HTTP 0.9

В 1991 году версия прототипа с плохими функциями, только одна команда GET, поддерживает только текстовое содержимое, эта версия устарела.

HTTP 1.0

Контент можно отправлять в любом формате, что позволяет передавать в Интернет не только текст, но и изображения, видео, бинарники и прочее.
В дополнение к команде GET также представлены команды POST и HEAD.
Изменился формат HTTP-запросов и ответов. Помимо части данных, каждое сообщение должно включать информацию заголовка (HTTP-заголовок) для описания некоторых метаданных.
Используйте только If-Modified-Since и Expires в заголовке в качестве критериев для аннулирования кеша.
Загрузка резюме не поддерживается, то есть каждый раз будут передаваться все страницы и данные.
Обычно к каждому компьютеру можно привязать только один IP, поэтому URL в сообщении запроса не передает имя хоста (имя хоста)

HTTP 1.1

В настоящее время http1.1 является наиболее распространенной версией протокола http.С момента своего выпуска в 1999 г. он по-прежнему остается основной версией протокола http.

Введено постоянное соединение, то есть TCP-соединение не закрывается по умолчанию и может повторно использоваться несколькими запросами без объявления Connection: keep-alive. Продолжительность длительного соединения может быть передана в заголовке запроса.keep-aliveустанавливать
Внедрили механизм конвейерной обработки, то есть в одном и том же TCP-соединении клиент может отправлять несколько запросов, что еще больше повышает эффективность протокола HTTP.
В HTTP 1.1 добавлены заголовки управления кешем, такие как E-tag, If-Unmodified-Since, If-Match, If-None-Match, для управления аннулированием кеша.
Поддерживает возобновляемую загрузку с использованием заголовка запроса.Rangeреализовать.
Используя виртуальную сеть, на физическом сервере может быть несколько виртуальных хостов (многосетевых веб-серверов), и они имеют общий IP-адрес.
Новые методы: PUT, PATCH, OPTIONS, DELETE.

проблема с версией http1.x

В процессе передачи данных весь контент находится в виде простого текста, и ни клиент, ни сервер не могут проверить личность другой стороны и не могут гарантировать безопасность данных.
Версия HTTP/1.1 по умолчанию допускает мультиплексирование TCP-соединений, но в одном и том же TCP-соединении вся передача данных осуществляется последовательно, обычно сервер обрабатывает один ответ, прежде чем продолжить обработку следующего, что приводит к блокировке заголовка строки.
Версия http/1.x поддерживает Keep-alive.Это решение используется для компенсации задержки, вызванной созданием нескольких подключений, но также создает нагрузку на сервер.Кроме того, для сервисов, где постоянно запрашивается один файл , Keep-alive будет чрезвычайно большим ударом по производительности, потому что он удерживает соединение без необходимости долгое время после запроса файла.

HTTP 2.0

二进制分帧Это полный двоичный протокол, информация заголовка и тело данных являются двоичными и вместе называются «фреймами»: информационный кадр заголовка и кадр данных.
头部压缩Появится версия HTTP 1.1"User-Agent, Cookie, Accept, Сервер, Диапазон"Другие поля могут занимать сотни или даже тысячи байтов, тогда как Body часто занимает всего несколько десятков байт, поэтому заголовок необъективен. Использование HTTP 2.0HPACKалгоритм сжатия.
多路复用Мультиплексирование TCP-соединений, в соединении и клиент, и браузер могут отправлять несколько запросов или ответов одновременно, и не нужно последовательно переписываться один к одному, что решает проблему блокировки заголовка строки .
服务器推送Позволяет серверу активно отправлять ресурсы клиенту без запроса, т. е. проталкивать сервером.
请求优先级Вы можете установить приоритет фрейма данных, позволить серверу сначала обрабатывать важные ресурсы и оптимизировать взаимодействие с пользователем.

Расскажите о своем понимании HTTP/2

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

Появится версия HTTP 1.1"User-Agent, Cookie, Accept, Сервер, Диапазон"Другие поля могут занимать сотни или даже тысячи байтов, тогда как Body часто занимает всего несколько десятков байт, поэтому заголовок необъективен.

Использование HTTP 2.0HPACKалгоритм сжатия.

Затем мы смотрим наHPACKАлгоритм это 👇

Из приведенного выше видно, что она похожа на таблицу индексов, и каждая таблица индексов соответствует значению. Например, индекс равен 2, что соответствует информации заголовка метода в заголовке. В этом случае при передаче соответствующий заголовок не передается. Для информации заголовка, которая появилась ранее, просто передайте индекс"показатель"(Например, 1, 2,...) могут быть переданы другой стороне, и другая сторона может получить таблицу поиска индекса.

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

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

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

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

HTTP2 в:

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

пуш сервера

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

По сравнению с преимуществами http/1.1👇

Push-ресурсы могут быть общими для разных страниц
Сервер может нажимать ресурсы по приоритету
Клиенты могут кэшировать выталкиваемые ресурсы
Клиенты могут отклонять отправленные ресурсы

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

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

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

Между клиентом и сервером обе стороны могут отправлять друг другу двоичные кадры, например"двунаправленная последовательность передачи", называется流, поэтому HTTP/2 использует потоки для представления передачи нескольких кадров данных по TCP-соединению, что является концепцией мультиплексирования.

Как заказать двоичный кадр, собранный в соответствующее сообщение?

Так называемый out-of-order означает, что потоки с разными идентификаторами идут не по порядку, а кадры с одинаковым идентификатором потока передаются по порядку.
После получения двоичного кадра получатель собирает тот же идентификатор потока в полное сообщение запроса и сообщение ответа.
В бинарном фрейме есть несколько полей, которые управляют优先级а также流量控制Таким образом, вы можете установить приоритет фрейма данных, позволить серверу обрабатывать важные ресурсы и оптимизировать взаимодействие с пользователем.

Введите общие коды состояния HTTP

RFC указывает, что код состояния HTTP"три цифры", первая цифра определяет категорию ответа, которая делится на пять категорий:

"1xx": указывает, что запрос принят и требует продолжения обработки.
"2xx": Указывает статус успеха.
"3xx": статус перенаправления.
"4xx": Ошибка клиента.
"5xx": Ошибка на стороне сервера.

1xx информационный класс

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

2xx успех

200 OK означает, что запрос от клиента был правильно запрошен на сервере.
204 Нет содержимого, что указывает на то, что запрос был выполнен успешно, но ресурсы не могут быть возвращены.
206 Partial Content, этот код состояния указывает, что клиент сделал запрос диапазона, и сервер успешно выполнил эту часть запроса GET. Ответное сообщение содержит"Content-Range"Содержимое объекта для указанной области.

3xx редирект

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

Когда возвращаются коды состояния ответа 301, 302, 303, почти все браузеры меняют POST на GET и удаляют тело в сообщении запроса, а затем запрос будет автоматически отправлен снова. Стандарты 301 и 302 запрещают менять метод POST на метод GET, но на практике это сделают все.

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

400 неверный запрос, в сообщении запроса есть синтаксическая ошибка.
401 неавторизованный, указывающий, что для отправленного запроса требуется информация аутентификации через HTTP-аутентификацию.
403 запрещено, указывающее на то, что доступ к запрошенному ресурсу был запрещен сервером.
404 not found, указывающий на то, что запрошенный ресурс не найден на сервере.
405 Method Not Allowed, сервер запрещает использование этого метода, клиент может просмотреть методы доступа, разрешенные сервером через метод options, следующим образом 👇

Access-Control-Allow-Methods →GET,HEAD,PUT,PATCH,POST,DELETE

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

500 внутренняя ошибка сервера, указывающая на то, что при выполнении запроса произошла ошибка на стороне сервера.
502 Bad Gateway, сам сервер в норме, есть проблема при доступе, конкретную ошибку не знаем.
Служба 503 недоступна, что указывает на то, что сервер временно перегружен или отключен на техническое обслуживание и не может обрабатывать запросы.

Как работает DNS

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

"Давайте посмотрим на процесс запроса через картинку."👇

Эта картинка очень наглядно демонстрирует, как DNS запрашивает локальный DNS-сервер."Как правило, отправка запроса на локальный DNS-сервер является рекурсивным запросом."

Процесс, когда локальный DNS-сервер запрашивает другие серверы доменных имен, представляет собой итеративный процесс запроса👇

Рекурсивные и итерационные запросы

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

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

Кэш DNS

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

DNS для балансировки нагрузки

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

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

Например 👇

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

Суммировать

Система доменных имен DNS — это протокол прикладного уровня, работающий поверх протокола UDP и использующий порт 43.
Процесс запроса, локальный запрос — это рекурсивный запрос, который, в свою очередь, кэшируется браузером.—>>локальный файл hosts—>>Локальный преобразователь DNS—>>локальный DNS-сервер—>>Другие запросы к серверу имен. Следующий процесс является итеративным процессом.
Рекурсивный запрос Вообще говоря, достаточно отправить запрос один раз, а итеративный процесс требует от пользователя отправки нескольких запросов.

Почему DNS использует протокол UDP в качестве протокола транспортного уровня?

"Основная причина, по которой DNS использует протокол UDP в качестве протокола транспортного уровня, заключается в том, чтобы избежать задержки соединения, вызванной использованием протокола TCP."

Чтобы получить IP-адрес доменного имени, часто запрашивается несколько серверов доменных имен.Если используется протокол TCP, для каждого запроса будет задержка соединения, что делает службу DNS очень медленной.
Большинство запросов на адресные запросы отправляются, когда браузер запрашивает страницу, из-за чего веб-страница будет слишком долго ждать.

Введите Connection: keep-alive

Что такое Keep-alive

Мы знаем, что протокол HTTP принимает режим «запрос-ответ».При использовании обычного режима, то есть режима без поддержки активности, каждый запрос/ответ клиент и сервер должны создавать новое соединение и отключаться сразу после завершения (HTTP протокол без установления соединения);

При использовании режима Keep-Alive (также известного как постоянное соединение, повторное использование соединения) функция Keep-Alive поддерживает связь между клиентом и сервером. функция позволяет избежать установления или повторного установления соединения.

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

Создание технологии. Википедия):

Как открыть клиент

В протоколе HTTP/1.0 он отключен по умолчанию, и вам нужно добавить «Connection: Keep-Alive» в заголовок http, чтобы включить Keep-Alive;

Connection: keep-alive

Keep-Alive включен по умолчанию в http 1.1 и будет закрыт, если будет добавлено «Соединение: закрыть».

Connection: close

В настоящее время большинство браузеров используют протокол http1.1, а это означает, что запрос на подключение Keep-Alive будет инициирован по умолчанию, поэтому возможность выполнения полного соединения Keep-Alive зависит от настроек сервера.

Знакомство со стратегиями кэширования HTTP

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

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

Давайте разбираться👇

Сильный кеш

Сильное кэширование двух связанных полей,"Expires","Cache-Control".

"Сильный кеш разделен на два случая, один для отправки HTTP-запросов, а другой не нужно отправлять."

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

Версия HTTP1.0 с использованием Expires, HTTP1.1 с использованием Cache-Control

Expires

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

Expires:Mon, 29 Jun 2020 11:10:23 GMT

Указывает, что этот ресурс доступен в 2020 году.7月29日11:10:23Когда он истечет, запрос будет повторно инициирован на сервер, когда он истечет.

С этим подходом есть проблема:"Время сервера и время браузера могут не совпадать", поэтому HTTP1.1 предлагает вместо него новое поле.

Cache-Control

В версии HTTP 1.1 используется это поле Время, используемое в этом поле, является временем истечения срока действия, которое соответствует max-age.

Cache-Control:max-age=6000

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

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

будь осторожен:

Когда Expires и Cache-Control существуют одновременно, Cache-Control имеет приоритет.
Конечно, когда ресурс кеша недействителен, то есть сильный кеш не попал, то входим в кеш согласования👇

Согласовать кеш

После того, как сильный кеш недействителен, браузер переносит ответ缓存TagЧтобы отправить запрос на сервер, сервер решает, использовать ли кеш согласно соответствующему тегу.

Существует два типа кэша:"Last-Modified"а также"ETag". У обоих есть свои преимущества, и нет такого понятия, как одно над другим.绝对的优势, который отличается от сильного кеша двумя упомянутыми выше тегами.

Last-Modified

Это поле представляет"Последнее изменение". После того, как браузер отправит запрос на сервер в первый раз, сервер добавит это поле в заголовок ответа.

После того, как браузер получит его,"Если запросить повторно", будет перенесено в заголовок запросаIf-Modified-SinceПоле, значение этого поля — время последней модификации, отправленное сервером.

Сервер получает заголовок запросаIf-Modified-SinceПосле поля оно фактически будет соответствовать该资源的最后修改时间В сравнении:

Если это значение в заголовке запроса меньше, чем время последнего изменения, пришло время обновить. Возврат нового ресурса аналогичен обычному процессу ответа на HTTP-запрос.
В противном случае верните 304, указав браузеру использовать кеш напрямую.

ETag

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

Когда браузер получает значение ETag, он будет использовать это значение в качестве следующего запроса."If-None-Match"Содержимое этого поля отправляется на сервер.

сервер получает"If-None-Match"После этого он будет следить за ресурсом на сервере"ETag"Сравнить 👇.

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

Сравните два

представление,Last-Modifiedлучше чемETag,Last-ModifiedМоменты времени записываются иEtagСоответствующее хэш-значение должно быть сгенерировано в соответствии с алгоритмом MD5 файла.
точность,ETagлучше чемLast-Modified.ETagМаркируйте ресурсы в соответствии с их содержимым, чтобы можно было точно отслеживать изменения ресурсов.Last-ModifiedВ некоторых сценах невозможно точно уловить изменения, например👇
- Отредактируйте файл ресурса, но содержимое файла не изменяется, он также приведет к пропущению кэша.
- Последние модифицированные способны воспринимать единицу времени в считанные секунды, если файл много раз изменился за одну секунду, на этот раз последнее модифицировано и не отражает изменение.

наконец,"Если оба метода поддерживаются, сервер отдаст приоритетETag".

Расположение кеша

Далее, если мы рассмотрим использование кеша, где находится кеш?

Расположение кеша браузера можно разделить на четыре типа, приоритет выстроен от высокого к низкому👇

Service Worker
Memory Cache
Disk Cache
Push Cache

Service Worker

Этот сценарий приложения, такой как PWA, основан на идее Web Worker.Поскольку он отделен от формы браузера, он не может получить прямой доступ к DOM. Он может выполнять такие функции, как:离线缓存,消息推送а также网络代理,в离线缓存то есть"Service Worker Cache".

Memory Cache

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

Disk Cache

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

Disk Cache VS Memory Cache

Сравнение двух, основная стратегия👇

Если скорость использования контента высока, файл сначала попадет на диск

Файлы JS и CSS большего размера будут размещены непосредственно на диске и наоборот.

Push Cache

Push cache, это последняя линия защиты в браузере, этоHTTP/2Содержание. Я не знаю подробностей, но вы можете узнать, если вам интересно.

Суммировать

Сначала проверьтеCache-Control, попробуйте, чтобы узнать, доступен ли сильный кеш
Если доступно, используйте напрямую
В противном случае войдите в кеш согласования, отправьте HTTP-запрос, и сервер передастIf-Modified-SinceилиIf-None-MatchПоле для проверки обновления ресурса
Обновление ресурса, возврат ресурса и код состояния 200.
В противном случае вернитесь к 304 и прямо сообщите браузеру, чтобы он сразу переходил к ресурсу из кеша.

Расскажите мне о методе HTTP-запроса?

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

http/1.1Указаны следующие методы запроса (обратите внимание, что все они пишутся с заглавной буквы):

GET: запрос на получение ресурса, указанного Request-URI.
POST: добавить новые данные к ресурсу, указанному Request-URI.
HEAD: Заголовок ответного сообщения для запроса на получение ресурса, идентифицированного Request-URI.
PUT: Запросить сервер сохранить ресурс и использовать Request-URI в качестве его идентификатора (изменить данные).
УДАЛИТЬ: запросить у сервера удаление соответствующего идентифицированного ресурса.
TRACE: запросите у сервера отправку полученной информации о запросе, в основном для тестирования или диагностики.
CONNECT: установить туннель подключения для прокси-сервера
ВАРИАНТЫ: Перечислите методы запросов, которые можно выполнять с ресурсами для междоменных запросов.

Разговор о разнице между GET и POST

По сути, это просто семантическая разница: GET используется для получения ресурсов, а POST — для отправки ресурсов.

Если вы хотите притвориться, обратитесь к https://zhuanlan.zhihu.com/p/22536382

Конкретные отличия 👇

С точки зрения кэширования браузер будет активно кэшировать после GET-запроса, в то время как POST не может по умолчанию.
С точки зрения параметров GET-запросы обычно размещаются в URL-адресе, поэтому они небезопасны POST-запросы размещаются в теле запроса, что относительно безопасно, но то же самое верно и в случае захвата пакетов.
С точки зрения кодирования запросы GET могут быть закодированы только в URL-адресе и могут принимать только коды ASCII, в то время как POST поддерживает больше типов кодирования и не ограничивает типы данных.
Запросы GET являются идемпотентными, а запросы POST — нет.Идемпотентность относится к отправке запросов M и N (оба разные и оба больше 1), а состояние ресурсов на сервере согласовано.
Запрос GET отправляет сообщение запроса одновременно. Запрос POST обычно делится на два пакета данных TCP. Часть заголовка отправляется первой. Если сервер отвечает 100 (продолжение), то часть тела отправляется.

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

В чем польза метода опционов?

Запрос на опции с головой подобной, но также для общей производительности клиента для просмотра сервера.
Этот метод запрашивает у сервера возврат всех методов HTTP-запросов, поддерживаемых ресурсом. Этот метод заменяет имя ресурса на «*» и отправляет запрос OPTIONS на сервер, чтобы проверить, нормально ли работает сервер.
Когда объект JS XMLHttpRequest выполняет междоменное совместное использование ресурсов CORS, для сложных запросов метод OPTIONS используется для отправки запроса анализа, чтобы определить, есть ли доступ к указанному ресурсу.

Расскажите о своем понимании URL

Унифицированный указатель ресурсов, сокращение от Унифицированный указатель ресурсов, часто называемый веб-адресом, является стандартным адресом ресурса в Интернете.

сочинение

Общий формат: схема://хост[:порт]/путь/.../?запрос#якорь

имя	Функция
scheme	Какой протокол использовать при доступе к серверу для ресурсов, например: http, https, FTP и т.д.
host	IP-адрес или доменное имя HTTP-сервера
port	Порт HTTP-сервера по умолчанию — 80, а порт HTTPS — 443. В этом случае номер порта можно не указывать, если используется другой порт, его необходимо указать. Различные порты, вы можете думать о разных приложениях.
path	путь доступа к ресурсу
query-string	данные отправляются на http сервер
anchor	Якорь

Например👇

https://www.baidu.com/s?tn=baidu&bar=&wd=TianTian

В этом URL-адресе https — это протокол, www.baidu.com — доменное имя, порт по умолчанию — 443, а /s — запрошенный путь.tn=baidu&bar=&wd=TianTianэто запрос

Кодировка URL

URL можно использовать толькоНабор символов ASCIIдля отправки через Интернет.
Поскольку URL-адреса часто содержат символы, не входящие в набор ASCII, URL-адреса необходимо преобразовать в допустимый формат ASCII.
Кодировка URL использует «%», за которым следует двузначное шестнадцатеричное число для замены символов, отличных от ASCII.
URL-адрес не может содержать пробелы. Кодирование URL обычно использует + для замены пробелов.

Например👇

天天Преобразование в допустимый формат ASCII%CC%EC%CC%EC

Разговор о блокировке головы

Что такое блокировка очереди?

Для каждого HTTP-запроса эти задачи будут помещены в очередь задач для последовательного выполнения. Если первый запрос задачи будет слишком медленным, последующая обработка запроса будет заблокирована.HTTP队头阻塞вопрос.

Есть решение?👇

одновременные соединения

Мы знаем, что для доменного имени несколько длинных подключений могут быть выделены, поэтому его можно понимать как добавлять очередь задач, то есть задача не заставит задачу блокировать другие задачи в очереди задач.RFC规范Оговаривается, что у клиента может быть максимум 2 одновременных подключения, но на деле получается больше, например, в Chrome — 6.

Шардинг домена

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

Например, какTianTian.com, который можно разделить на множество доменных имен второго уровня, таких какDay1.TianTian.com,Day2.TianTian.com,Day3.TianTian.com, который может эффективно решить проблему блокировки очереди.

Разговор о передаче данных HTTP

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

Данные фиксированной длины

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

Конечно, если используется сжатие Gzip, параметр Content-Length представляет собой длину сжатой передачи.

Что нам еще нужно знать, так это 👇

Если Content-Length существует и действителен, он должен быть точно таким же, как длина передачи содержимого сообщения, то есть, если он слишком короткий, он будет усечен, а если слишком длинный, это вызовет тайм-аут. .
Если используется короткая ссылка, длина передачи сообщения может быть напрямую определена сервером, закрывающим соединение.
Затем в версиях до HTTP/1.0 поле Content-Length было необязательным, потому что как только сервер закрывал соединение, мы могли получить длину передаваемых данных.
В версии HTTP/1.1, если это Keep-alive, приоритет чанков выше, чемContent-Length, Если это не Keep-alive, как в предыдущем случае, Content-Length необязателен.

Как это настроитьContent-Length

Берите пример, чтобы увидеть 👇

const server = require('http').createServer();
server.on('request', (req, res) => {
  if(req.url === '/index') {
   // 设置数据类型
    res.setHeader('Content-Type', 'text/plain');
    res.setHeader('Content-Length', 10);
    res.write("你好，使用的是Content-Length设置传输数据形式");
  }
})

server.listen(3000, () => {
  console.log("成功启动--TinaTian");
})

данные переменной длины

Сейчас наиболее используемой версией является HTTP/1.1 для завершения передачи данных, в состоянии Keep-alive, когда данные переменной длины, нам нужно установить новое поле заголовка👇

Transfer-Encoding: chunked

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

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

Итак, давайте смоделируем это👇

const server = require('http').createServer();
server.on('request', (req, res) => {
  if(req.url === '/index') {
   // 设置数据类型
    res.setHeader('Content-Type', 'text/html; charset=utf8');
    res.setHeader('Content-Length', 10);
    res.setHeader('Transfer-Encoding', 'chunked');
    
    res.write("你好，使用的是Transfer-Encoding设置传输数据形式");
    setTimeout(() => {
      res.write("第一次传输数据给您<br/>");
    }, 1000);
    res.write("骚等一下");
    setTimeout(() => {
      res.write("第一次传输数据给您");
      res.end()
    }, 3000);
  }
})

server.listen(3000, () => {
  console.log("成功启动--TinaTian");
})

Выше показан модуль http в nodejs. Заинтересованные партнеры могут попробовать его. Выше — пара HTTP."Данные фиксированной длины"а также"данные переменной длины"Средства обработки во время передачи.

Познакомить с разницей между HTTPS и HTTP

У HTTPS больше концепции безопасности, чем у HTTPS.На самом деле HTTPS не является новым протоколом прикладного уровня.На самом деле это комбинация протоколов HTTP + TLS/SSL, и гарантия безопасности - это именно то, что делает SSL/TLS.

"SSL"

Уровень защищенных гнезд

"TLS"

(Безопасность транспортного уровня, Безопасность транспортного уровня)

Текущая основная версия — TLS/1.2.Предыдущие версии TLS1.0 и TLS1.1 считаются небезопасными и будут полностью удалены в ближайшем будущем.

"HTTPS — это HTTP со слоем SSL".

Итак, каковы различия?

HTTP — это протокол передачи открытого текста, а протокол HTTPS — это сетевой протокол, созданный на основе протокола SSL + HTTP для зашифрованной передачи и аутентификации личности, который является более безопасным, чем протокол HTTP.
HTTPS более безопасен, чем HTTP, более удобен для поисковых систем и выгоден для SEO.Google и Baidu сначала индексируют HTTPS-страницы.
Стандартный порт HTTPS 443, стандартный порт HTTP 80.
HTTPS требует SSL-сертификата, а HTTP — нет.

Думаю, достаточно запомнить следующие две основные функции HTTPS👇

Шифровать данные и устанавливать канал защиты информации для обеспечения безопасности данных при передаче;
Реальная аутентификация веб-серверов.

Введение в то, как работает HTTPS

Из предыдущего раздела мы можем понимать HTTPS как"HTTPS = HTTP + SSL/TLS"

Функциональная реализация TLS/SSL в основном опирается на три основных алгоритма:散列函数,对称加密а также非对称加密, который использует асимметричное шифрование для реализации аутентификации личности и согласования ключа.Алгоритм симметричного шифрования использует согласованный ключ для шифрования данных и проверяет целостность информации на основе хэш-функции.

Симметричное шифрование

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

"Вопрос один:"WWW Всемирная паутина имеет много клиентов, невозможно зашифровать информацию ключом А, что очень неразумно, поэтому решение - использовать один клиент для шифрования одним ключом.

"Вопрос второй:"Поскольку разные клиенты используют разные ключи, то"Как ключ для симметричного шифрования передается?"Тогда единственным решением является"Один конец генерирует секретный ключ и передает его другому концу через HTTP.", то это создаст новые проблемы.

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

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

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

Судя по приведенному выше анализу, симметричное шифрование мешает, тогда давайте рассмотрим асимметричное шифрование. Используемый алгоритм — RSA, поэтому он также будет встречаться в некоторых статьях."Традиционное рукопожатие RSA", исходя из текущей основной версии TLS — 1.2, поэтому следующее прочесывание"Процесс рукопожатия TLS/1.2".

В асимметричном шифровании нам нужно прояснить, что👇

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

Основной рабочий процесс

Расчешите, вы можете"Процесс рукопожатия TLS 1.2"Разделено на пять основных шагов👇

Содержание изображения изгребля по волнам

шаг 1)

Клиент инициирует запрос HTTPS для подключения к порту 443. Этот процесс можно понимать как"Процесс запроса открытого ключа".

Шаг 2)

Получив запрос, сервер шифрует его закрытым ключом сторонней организации и отправляет цифровой сертификат (который также можно рассматривать как сертификат открытого ключа) клиенту.

Шаг 3)

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

Шаг (4)

получить его в безопасности"Открытый ключ сервера"После этого клиент Client случайным образом генерирует"Симметричный ключ",использовать"Открытый ключ сервера"(открытый ключ сертификата) зашифровать это"Симметричный ключ", отправлено на сервер.

Шаг (5)

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

Далее можно зашифровать/расшифровать передаваемую информацию с помощью симметричного ключа на примере с рисунка выше👇

Пользователи клиента используют это"Симметричный ключ"Зашифруйте «открытый текст B» и отправьте его на сервер (сервер)
Сервер использует это"Симметричный ключ"Расшифруйте сообщение, чтобы получить открытый текст B.

Далее рассмотрим вопрос,"Что делать, если открытый ключ подделан посредником?"

Следующие фотографии взяты изleocoder

中间人获取公钥 — Посредник получает открытый ключ

"Открытый ключ, который может получить клиент, является поддельным, каково решение?"

сторонняя сертификация

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

В HTTPS через"Сертификат" + "цифровой подписи"Для решения этой проблемы.

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

При этом цифровой сертификат содержит две особо важные сведения 👉"Открытый ключ сайта + ЭЦП"

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

Так как же клиент сравнивает цифровые подписи двух?

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

цифровой подписи

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

Третья партия сертификационного органа является открытой платформой, которая может получить ее.

Если ЭЦП нет, то будут следующие ситуации👇

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

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

"Суммировать"

HTTPS — это зашифрованная передача с использованием протокола SSL/TLS.
Грубый процесс: клиент получает открытый ключ сервера (что правильно), а затем клиент случайным образом генерирует"Симметричный ключ шифрования",использовать"открытый ключ"Зашифровано, передано на сервер, затем сервер расшифрован, чтобы получить"Симметричный ключ", вся последующая информация проходит через этот"Симметричный ключ"Выполните шифрование и дешифрование, чтобы завершить весь процесс HTTPS.
"сторонняя сертификация", самое главное это"цифровой подписи", что позволяет избежать использования полученного открытого ключа в качестве посредника.

Как восстановить разорванное соединение SSL?

Есть два способа восстановить разорванное SSL-соединение: один — использовать идентификатор сеанса, второй — сеансовый билет.

по идентификатору сеанса

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

через сессионный билет

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

Разница между коротким опросом, длинным опросом и WebSocket?

короткий опрос

Основная идея короткого опроса:

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

Достоинства и недостатки 👇

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

долгий опрос

Основная идея длинных опросов:

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

Достоинства и недостатки 👇

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

WebSocket

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

Поговорим о прямом прокси и обратном прокси

прямой прокси

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

обратный прокси

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

Две реализации балансировки нагрузки?

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

Ссылаться на

Я слышал, что «99% людей неправильно понимают разницу между GET и POST в HTTP»? ?
Как понять коды состояния HTTP-ответов?
Коды ответов HTTP | MDN
Графическое кэширование HTTP
После прочтения этого HTTP не проблема поспорить с интервьюером
HTTP keep-alive Две или три вещи
Глубокое понимание того, как работает HTTPS
Посмотрите на графику HTTPS
Опрос, длинный опрос, долгое соединение, веб-сокет
Начало работы с принципами DNS

"❤️ Всем спасибо"

Если вы считаете этот контент полезным:

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