Будучи важным базовым знанием фронтенд-разработки, протокол HTTP является слабой стороной многих разработчиков кода, которые не являются профессионалами в области компьютеров. Автор систематически изучил основное содержание протокола HTTP через книгу «Иллюстрированный HTTP» и цитирует ее, пытаясь использовать более сжатый язык для описания ключевого содержания, которое необходимо освоить протоколу HTTP, чтобы помочь студентам, которые не как чтение книг экономит время.
маленький набросок учителя
- Введение в HTTP-протокол
- HTTP-версия
- HTTP-сообщение
- веб сервер
- HTTPS
- Меры безопасности в Интернете
- резюме
Введение в HTTP-протокол
В статье "Иллюстрированный HTTP" состояние HTTP в сети описывается следующим образом:
Интернет использует протокол под названием HTTP (протокол передачи гипертекста) в качестве спецификации для выполнения ряда операционных процессов от клиента к серверу. Соглашение относится к соглашению правил. Можно сказать, что Интернет построен на протоколе HTTP для связи.
Протокол HTTP определяет, как веб-клиенты запрашивают веб-страницы с веб-серверов и как серверы доставляют веб-страницы клиентам. Протокол HTTP использует модель запрос/ответ. Клиент отправляет сообщение запроса на сервер, и сообщение запроса содержит запрошенный метод, URL-адрес, версию протокола, заголовок запроса и данные запроса. Сервер отвечает строкой состояния, содержащей версию протокола, код успеха или ошибки, информацию о сервере, заголовки ответа и данные ответа.
HTTP — это протокол, который не сохраняет состояние. Это протокол без сохранения состояния. Сам протокол не сохраняет состояние связи между запросами или ответами. Поэтому обе стороны в соединении не могут знать текущую личность и состояние другой стороны. Это также одна из важных причин появления технологии cookie: управление состоянием клиента. Браузер автоматически сохранит файл cookie в соответствии с информацией в поле заголовка Set-Cookie в ответном сообщении, отправленном с сервера. Каждый раз, когда клиент отправляет HTTP-запрос, он будет содержать файл cookie в сообщении запроса в качестве идентификатора для сервера, чтобы идентифицировать статус личности клиента.
Набор протоколов TCP/IP
Чтобы лучше понять протокол HTTP, мы должны сначала понять набор протоколов TCP/IP. Набор протоколов TCP/IP является самым основным протоколом Интернета, а протокол HTTP является его подмножеством. Семейство протоколов TCP/IP делится на следующие четыре уровня в зависимости от уровня (основы сети лучше всего помнить):
- прикладной уровень
Прикладной уровень определяет протокол для связи при предоставлении пользователям сервисов приложений, таких как:
Различные общие протоколы службы приложений предварительно хранятся в наборе протоколов TCP/IP. Например, FTP (протокол передачи файлов, протокол передачи файлов), DNS (система доменных имен, система доменных имен) и протокол HTTP.
Система доменных имен DNS предоставляет доменные имена (например:www.baidu.com) в службу разрешения между IP-адресами (например: 119.75.217.109).
- транспортный уровень
Транспортный уровень соединяется с верхним прикладным уровнем и предоставляет протокол, используемый для передачи данных между двумя компьютерами в сетевом соединении.
На транспортном уровне есть два разных протокола: TCP (протокол управления передачей, протокол управления передачей) и UDP (протокол данных пользователя, протокол данных пользователя).
Протокол TCP является полнодуплексным, то есть отправка данных и получение данных осуществляются синхронно, так же, как когда мы делаем телефонный звонок, мы его одновременно слышим. Протокол TCP имеет три рукопожатия и четыре волны при установлении и разрыве соединения, поэтому он более стабилен и надежен в процессе передачи, но в то же время не так эффективен, как UDP.
Протокол UDP не требует установления соединения, что означает отсутствие необходимости устанавливать соединение перед формальной передачей данных. Протокол UDP не гарантирует упорядоченной доставки без потерь на противоположный конец, а значит, недостаточно стабилен, но из-за этого протокол UDP эффективнее и легче, чем TCP.
- Сетевой уровень
Сетевой уровень определяет маршрут передачи, по которому данные достигают другого компьютера и передаются другой стороне (протокол IP и т. д.).
При передаче с другого компьютера через несколько компьютеров или сетевых устройств функция сетевого уровня заключается в выборе маршрута передачи среди множества вариантов. Как и карта домашнего маршрута, предоставленная Ctrip.
- связующий слой
Он используется для обработки аппаратной части подключения к сети, включая управление операционной системой, драйвером устройства оборудования, сетевой картой (сетевой интерфейсной картой, сетевым адаптером, то есть сетевой картой) и физически видимой частью, такой как как оптоволокно (также включает все средства передачи, такие как разъемы). Объем оборудования находится в рамках уровня канала.
Коммуникационный транспортный поток общего веб-приложения выглядит следующим образом:
Когда отправитель передает данные между уровнями, каждый уровень будет помечен информацией заголовка, к которой принадлежит уровень. Напротив, когда принимающая сторона передает данные между уровнями, соответствующая информация заголовка будет удаляться каждый раз, когда она проходит через уровень.
Введение в последовательные соединения, постоянные соединения, постоянные соединения по каналам, мультиплексирование http/2.0
- Серийное соединение:HTTP имеет особенность без установления соединения, то есть на одно соединение может быть обработан только один запрос, а после получения ответа соединение немедленно разрывается. В версии HTTP/1.0 (называемой последовательным соединением или коротким соединением, коротким опросом) TCP-соединение отключается после каждого HTTP-соединения, поэтому для каждого нового HTTP-запроса необходимо установить новое соединение. Но в текущей ситуации, когда веб-сайт перемещает десятки HTTP-запросов, легко достичь верхнего предела запросов браузера, и для каждого запроса устанавливается новое tcp-соединение (каждый раз происходит три рукопожатия и четыре прощания), что значительно увеличивает затраты на связь.
- Постоянное соединение:Чтобы решить эту проблему, кто-то предложил постоянное соединение (также называемое длинным соединением, длинным опросом). В течение определенного периода времени для HTTP-запросов под одним и тем же доменным именем, пока обе стороны не предлагают отключиться, состояние TCP-соединения будет постоянно поддерживаться, и другие запросы могут повторно использовать этот канал соединения. HTTP/1.1 реализует и по умолчанию устанавливает, что все соединения являются постоянными соединениями, поэтому, когда клиент инициирует несколько HTTP-запросов, это сокращает потери сетевых ресурсов и времени связи, вызванные рукопожатиями TCP. Однако постоянное соединение принимает режим блокировки, и следующий запрос должен ждать до тех пор, пока не будет возвращен последний ответ.
- Потоковые постоянные соединения:Конвейерная обработка может отправить следующий запрос, не дожидаясь возврата ответа, и вернуть ответ по порядку.Современные браузеры не включают конвейерную обработку по умолчанию. (Информация, собранная в этом отношении, ограничена и сказать особо нечего)
- Мультиплексирование HTTP/2.0:Каждый HTTP-запрос имеет идентификатор последовательности, поэтому браузер может одновременно запрашивать несколько запросов.После того, как сервер получит данные, они будут переупорядочены в разные пакеты запросов в соответствии с идентификатором последовательности, не вызывая путаницы в данных (Подробнее см. в этой статье.). Точно так же сервер также может одновременно возвращать несколько ответов браузеру, и браузер переупорядочивает пакеты ответов в соответствии с идентификатором последовательности и классифицирует их в соответствующие запрошенные пакеты ответов после их получения. И все запросы под одним и тем же доменным именем используют одно и то же TCP-соединение, что значительно увеличивает верхний предел параллелизма обработки сервером.
- Веб-сокет:WebSocket — это полнодуплексный протокол для связи между клиентом и сервером, предложенный HTML5. Клиент инициирует запрос. После установления соединения не только клиент может активно отправлять запросы на сервер, но и сервер может активно отправлять информацию на сервер. клиент.
Посмотрите на картинку, чтобы различить три типа ссылок:
Как показано в (а): новое TCP-соединение должно устанавливаться каждый раз, когда последовательное соединение инициирует запрос.
Как показано на (b): постоянное соединение Несколько HTTP-запросов могут повторно использовать одно и то же TCP-соединение, но следующий запрос должен быть сделан после того, как будет возвращен последний ответ.
Как показано на (c): Конвейерное постоянное соединение также может повторно использовать одно и то же соединение tcp и не может ждать, чтобы выдать несколько HTTP-запросов, но ответы должны возвращаться последовательно.
URI
Протокол HTTP использует URI для поиска ресурсов в Интернете. концепция:
- URI (универсальный идентификатор ресурса: универсальный идентификатор ресурса)
- URL-адрес (универсальный указатель ресурсов: универсальный указатель ресурсов)
- URN (универсальное имя ресурса: универсальное имя ресурса).
Лично понимаю, что URI — это общий термин для различных методов представления файла ресурсов. Например, файл a.html может быть представлен либо именем файла a.html, либо путем к файлу.www.baidu.com/a.htmlили даже такой идентификатор, как urn:a:1535-3613 . Их отношения следующие:
HTTP-версия
Более подробные различия между версиями HTTP, автор не талантлив, см.эта статья
HTTP/1.0
Самый ранний http используется только на некоторых более простых веб-страницах и сетевых запросах, поэтому он относительно прост.Каждый раз, когда делается запрос, открывается новая ссылка TCP, и соединение разрывается сразу после получения ответа.
HTTP/1.1
- HTTP/1.1 вводит больше стратегий управления кешем, таких как тег Entity, If-Unmodified-Since, If-Match, If-None-Match и т. д.
- HTTP/1.1 разрешает запросы диапазона, то есть добавление в заголовок запроса
Rangeголова - Сообщения запроса и ответа HTTP/1.1 должны содержать
HostЗаголовок для различения доменных имен разных виртуальных хостов на одном физическом хосте. - HTTP/1.1 по умолчанию включает постоянные соединения, и несколько HTTP-запросов и ответов могут быть отправлены по одному TCP-соединению, что снижает потребление и задержку при установлении и закрытии соединений.
HTTP/2.0
В HTTP/2 есть два очень важных понятия, а именно кадр и поток.Понимание этих двух понятий является предпосылкой для понимания следующего мультиплексирования. Кадр представляет собой наименьшую единицу передачи данных. Каждый кадр имеет идентификатор последовательности, указывающий, к какому потоку принадлежит кадр. Поток — это поток данных, состоящий из нескольких кадров, и каждый поток представляет собой запрос. вотхром расширение, вы можете легко просмотреть версию HTTP-запроса на текущий веб-сайт (после установки, щелкните правой кнопкой мыши щелкните правой кнопкой мыши инструмент разработки Chrome - Network - в заголовке таблицы имени / размера / времени и выберите ProCotol, чтобы просмотреть версию протокола).
- Новый бинарный формат:Синтаксический анализ HTTP/1.x основан на тексте. Парсинг на основе текстовых протоколов имеет естественные недостатки, и существуют различные формы представления текста, должно быть много сценариев, чтобы их можно было рассматривать комплексно. Двоичный, с другой стороны, распознает только комбинации 0 и 1. Основываясь на этом соображении, анализ протокола HTTP/2.0 принимает двоичный формат, который удобен и эффективен.
- Мультиплексирование:HTTP/2.0 поддерживает мультиплексирование, которое представляет собой обновленную версию постоянных соединений HTTP/1.1. Мультиплексирование означает, что в TCP-соединении может быть несколько потоков, то есть может быть отправлено несколько запросов, и сервер может узнать, какому потоку (т.е. запросу) принадлежит кадр через идентификатор в кадре, и восстановить запрос, переупорядочив его. . Мультиплексирование позволяет одновременно инициировать несколько запросов, и каждый запрос и ответ на запрос не должны ждать других запросов или ответов, что позволяет избежать проблемы блокировки заголовка строки. Таким образом, выполнение определенной задачи запроса занимает много времени и не повлияет на нормальное выполнение других соединений, что значительно повышает производительность передачи.
- Сжатие заголовка:Заголовки запроса и ответа HTTP/1.x содержат много информации, и каждый запрос должен быть отправлен повторно.HTTP/2.0 использует кодировщик для уменьшения размера заголовка, который необходимо передать, и обе стороны кэшируют заголовок. fields table Это не только позволяет избежать передачи повторяющихся заголовков, но и уменьшает размер, который необходимо передать.
- Пуш сервера:Нажатие на стороне сервера здесь относится к отправке ресурсов css/js/img, необходимых клиенту, клиенту вместе с index.html, избавляя клиента от повторения запроса (извлечение из кеша).
HTTP/3.0
HTTP/2.0 использует мультиплексирование.В общем случае необходимо использовать только одно TCP-соединение с одним и тем же доменным именем. Но когда в этом соединении происходит потеря пакетов, это приведет к тому, что весь TCP начнет ждать повторной передачи, что приведет к блокировке всех последующих данных. Наоборот, для HTTP/1.0 можно открыть несколько TCP-соединений, но потеря пакетов повлияет только на одно из соединений, а остальные TCP-соединения могут по-прежнему передавать данные в обычном режиме.
Причиной блокировки пакетов является проблема, вызванная базовым TCP-протоколом, но модификация TCP-протокола является нереальной проблемой, напримерtypeof null === 'object'Опять же, изменение этого вопроса может привести к большим проблемам. Поскольку вы не можете быть изменены, другое соглашение заменит вас. Google запустил протокол QUIC на основе протокола UDP и использовал его через HTTP/3.
QUIC основан на UDP, но сам UDP имеет много проблем, таких как нестабильность, поэтому QUIC добавляет множество функций на основе UDP, таких как мультиплексирование, 0-RTT, шифрование с использованием TLS1.3, управление потоком и упорядоченная доставка, повторная передача, и т.п. Есть много преимуществ, см.здесь:
- Избегайте блокировки пакета:Множество потоков пакетов данных, передаваемых по соединению TCP, если возникают проблемы с потоком пакетов передачи, необходимо дождаться повторной передачи пакетов TCP, чтобы продолжить передачу пакетов данных других потоков. Но протокол QUIC основан на UDP, передача данных между разными потоками действительно независима друг от друга, не мешая друг другу, когда поток пакетов данных необходимо повторно передать в проблеме, он не окажет влияния на другие потоки передачи пакетов данных. .
- Быстро перезапустите сеанс:Обычное соединение на основе TCP устанавливается на основе IP, порта и протокола обоих концов. В сценарии переключения сети, например, когда мобильный телефон переключает беспроводную сеть и использует сеть 4G, его собственный IP-адрес будет изменен, что вызовет повторное создание TCP-соединения. Протокол QUIC использует уникальный UUID для маркировки каждого соединения.При изменении сетевой среды, пока UUID остается неизменным, он может продолжать передавать данные без рукопожатия.
HTTP-сообщение
Информация, используемая для взаимодействия по протоколу HTTP, называется HTTP-сообщением. HTTP-пакеты клиента называются пакетами запросов, а HTTP-пакеты сервера называются ответными пакетами.
сообщение запросаОн состоит из строки запроса (метод запроса, версия протокола), заголовка запроса (URI запроса, информация о клиенте и т. д.) и объекта содержимого (информация о пользователе, информация о ресурсах и т. д., которые могут быть пустыми).
ответное сообщениеСостоят из строки состояния (версия протокола, код состояния), заголовка ответа (имя сервера, идентификатор ресурса и т. д.) и объекта содержимого (информация о ресурсе, возвращаемая сервером).
метод запроса
- GET: метод get обычно используется для получения ресурсов сервера.
- POST: метод post обычно используется для передачи тела объекта.
- PUT: метод put обычно используется для передачи файлов
- Удалить: Удалить метод удаления файлов
- Глава: метод головы используется для получения заголовка сообщения, не возвращается к главному корпусу
- ОПЦИИ: метод options используется для опроса метода, поддерживаемого ресурсом URI запроса.
Концепция очень проста и проницательна, и я не совсем понимаю самостоятельную Baidu в сценариях приложений~~
код состояния
Код состояния HTTP указывает на возвращаемый результат клиентского HTTP-запроса, определяет, нормально ли обрабатывается сервер, и указывает на ошибку, возникшую в запросе.
| 2XX | успех (эта серия указывает на то, что запрос был обработан нормально) |
|---|---|
| 200 | ОК, что указывает на то, что запрос, отправленный от клиента, корректно обрабатывается на стороне сервера. |
| 204 | Нет содержимого, что указывает на то, что запрос выполнен успешно, но ответное сообщение не содержит основной части сущности |
| 206 | Частичный контент, запрос диапазона выполнен успешно |
| 3XX | Редирект (указывает, что браузер должен выполнить специальную обработку) |
|---|---|
| 301 | перемещен навсегда, постоянное перенаправление, указывающее, что ресурсу был присвоен новый URL-адрес |
| 302 | найдено временное перенаправление, указывающее на то, что ресурсу временно присвоен новый URL |
| 303 | см. другое, указывающее, что для ресурса существует другой URL, ресурс должен быть получен методом GET (для ответов 301/302/303 почти все браузеры удалят тело сообщения и автоматически сделают повторный запрос с помощью GET) |
| 304 | не изменено, что свидетельствует о том, что сервер разрешает доступ к ресурсу, но запрос не соответствует условиям (не связан с перенаправлением) |
| 307 | временное перенаправление, похожее на 302, но ожидает, что клиент сохранит метод запроса без изменений и сделает запрос на новый адрес |
| 4XX | ошибка клиента |
|---|---|
| 400 | неверный запрос, в сообщении запроса есть синтаксическая ошибка |
| 401 | неавторизованный, указывающий, что для отправленного запроса требуется информация аутентификации через HTTP-аутентификацию |
| 403 | Запрещено, указывает, что доступ к запрошенному ресурсу запрещен сервером, и описание причины может быть возвращено в части тела объекта. |
| 404 | не найдено, что указывает на то, что запрошенный ресурс не был найден на сервере |
| 5XX | Ошибка сервера |
|---|---|
| 500 | Внутренняя ошибка сервера, указывающая на то, что при выполнении запроса произошла ошибка на стороне сервера. |
| 501 | Не реализовано, что указывает на то, что сервер не поддерживает функцию, требуемую текущим запросом. |
| 503 | служба недоступна, что указывает на то, что сервер временно перегружен или отключен для обслуживания и не может обрабатывать запросы |
поле заголовка
Ниже приведены имена полей и роли в заголовке запроса и заголовке ответа:
| общий заголовок | Функция (можно использовать как сообщение запроса, так и сообщение ответа) |
|---|---|
| Cache-Control | Управление кэшированием:no-cache(Принудительная повторная аутентификация на сервере),no-store(не делайте никакого кэширования),max-age=111111(ресурсы могут кэшироваться максимальное время в секундах),public(клиент и прокси-сервер могут использовать кеш),private(На прокси-сервере нет кэша) |
| Connection | Браузер, который вы хотите использовать, приоритет типа подключения:keep-alive close(Включение и выключение постоянных подключений) |
| Date | Создать время сообщения |
| Pragma | Используется только для сообщений запроса, клиент просит промежуточный сервер не возвращать кэшированные ресурсы. |
| Via | Информация, связанная с прокси-сервером, каждый раз, когда прокси-сервер проходит через него, будет добавляться соответствующая информация, разделенная запятыми. |
| Transfer-Encoding | Способ кодирования передачи:chunkedПередача по частям |
| Upgrade | Протокол обновления, который должен использовать клиент, должен взаимодействовать сConnection: Upgradeиспользовать вместе:websocket
|
| Warning | Предупреждение о проблемах, связанных с кешем |
| заголовок запроса | Функция (только для сообщения запроса) |
|---|---|
| Accept | Типы носителей, которые могут быть получены правильно:application/json text/plain
|
| Accept-Charset | Наборы символов, которые могут быть правильно получены:unicode-1-1
|
| Accept-Encoding | Список форматов кодирования, которые могут приниматься корректно:gzip deflate
|
| Accept-Language | Список языков, которые можно получить корректно:zh-cn,zh;1=0.9,en,1=0.8
|
| Authorization | Информация для аутентификации клиента:Bearer dSdSdFFlsfdjasd123, обычно используется для хранения токенов |
| Cookie | Информация о файлах cookie, отправленная на сервер |
| Expect | Ожидать указанного поведения от сервера |
| From | Адрес электронной почты запрашивающего |
| Host | Доменное имя сервера, используемое для того, чтобы отличить виртуальный хост от нескольких доменных имен одного сервера, является единственным полем, которое должно быть включено в HTTP/1.1. |
| If-Match | При сравнении тегов ресурсов на обоих концах сервер примет запрос только в том случае, если условие оценки истинно:If-Mach: "123456по сравнению с набором файла сервера |
| If-Modified-Since | Не измененный локальный ресурс возвращает 304 (сравните время) |
| If-None-Match | локальный ресурс без изменений возвращает 304 (флаг сравнения) |
| User-Agent | Информация о клиенте |
| Max-Forwards | Ограничьте количество раз, которые могут быть перенаправлены прокси и шлюзами |
| Proxy-Authorization | Отправить информацию для аутентификации на прокси-сервер |
| Range | запросить часть контента, сотрудничать сIf-Rangeиспользовать |
| Referer | Исходный URI страницы, с которой был отправлен запрос |
| TE | кодирование передачи |
| заголовок ответа | Функция (отвечает за ответное сообщение) |
|---|---|
| Accept-Ranges | Сообщите клиенту, может ли сервер принимать запросы диапазона, даbytes,нетnone
|
| Age | Как долго ресурс находится в кеше прокси |
| ETag | Идентификатор ресурса, идентификатор также изменится при изменении ресурса |
| Location | Клиент перенаправляет на URL |
| Proxy-Authenticate | Отправить информацию для аутентификации на прокси-сервер |
| Server | Имя сервера:Apache Nginx
|
| WWW-Authenticate | Получите схему аутентификации, необходимую для ресурса |
| Set-Cookie | Требуется информация на стороне клиента, которая обычно используется для идентификации пользователя. |
| Заголовок объекта | Функция (дополнительное сообщение запроса или информация, относящаяся к ответному сообщению) |
|---|---|
| Allow | Правильный способ запроса ресурса:GET HEAD POST
|
| Content-Encoding | Формат кодирования контента:gzip deflate
|
| Content-Language | Язык содержания:zh-CN
|
| Content-Length | длина тела запроса (то есть размер тела сущности): |
| Content-Location | Альтернативный адрес для возврата данных |
| Content-MD5 | Контент в зашифрованном формате Base64 Контрольное значение MD5 |
| Content-Range | Диапазон содержимого тела ответа |
| Content-Type | Медиа-тип содержимого (например, 'application/json;charset=UTF-8' отправит предварительный запрос) |
| Expires | Срок годности контента |
| Last_modified | Время последней модификации контента |
В первой части много контента, и достаточно сосредоточиться на запоминании некоторых полей, обычно используемых браузерами:
две просьбы
Когда браузер отправляет запрос CORS (междоменный запрос), он делит запрос на простой запрос и сложный запрос.
В нашей повседневной работе часто используемые простые запросы можно разделить на следующие пункты:
- Запрошенный метод может быть только HEAD, GET, POST
- Нет настраиваемых заголовков запроса
-
Content-TypeТолько такие виды:
text/plain
multipart/form-data
application/x-www-form-urlencoded
сложный запрос:
- ajax-запрос для методов PUT, Delete
- Отправлять запросы ajax в формате JSON (например, данные публикации)
- AJAX запрос с пользовательским заголовком
Если это простой запрос, он будет сначала выполнен, а затем оценен. Процесс выполнения примерно такой:
Браузер определяет, что запрос является запросом CORS, и добавляет поле источника (которое содержит информацию об источнике страницы: протокол, имя домена, порт) ====> Сервер получает соответствующую обработку (по сравнению с источником сервер определяет является ли источник Accept) и вернуть результат браузеру ====> Браузер проверяет, разрешает ли заголовок ответа междоменную информацию ====> Разрешено, тогда это считается ничем. Не разрешено, браузер выдает соответствующее сообщение об ошибке.
Когда возникает сложный запрос, если это запрос CORS, браузер заранее отправляет запрос опции. Такое поведение браузера называется предварительным запросом (обратите внимание, что предварительный запрос не будет выполнен, если он не является запросом между источниками, например обратным прокси-сервером).
веб сервер
Неважно сервер Apache или Nginx, но роль сервера. Сервер можно использовать в качестве исходного сервера или транзитного сервера, и даже несколько веб-сайтов с разными доменными именами могут быть построены на одном сервере.
веб хостинг
Спецификация HTTP/1.1 позволяет одному HTTP-серверу создавать несколько веб-сайтов. Используя функцию виртуального хоста, несколько хостов могут быть виртуализированы на физическом сервере (один IP-адрес), и каждый хост сопоставляется с независимым доменным именем. Таким образом, когда пользователь посещает доменное имяhttp://www.laogeng.com/Система доменных имен DNS преобразует его в IP-адрес, найдет физический сервер по IP, а затем подтвердит соответствующий виртуальный хост через поле HOST в заголовке запроса (теперь вы знаете, почему HOST является обязательным для HTTP/1.1). ).
прокси-сервер
Прокси-сервер является «посредником» между клиентом и сервером, то есть HTTP-запрос перенаправляется на сервер через прокси-сервер, а затем ответ сервера возвращается клиенту. Прокси-сервер можно использовать в качестве кэш-сервера или для сокрытия идентификатора пользователя (прямой прокси-сервер) или идентификатора сервера (обратный прокси-сервер) для повышения безопасности.
-
Так называемый прямой прокси заключается в том, что для получения контента с исходного сервера клиент отправляет запрос на прокси-сервер, иУкажите целевой сервер доступа, а затем прокси-сервер перенаправляет запрос на исходный сервер и возвращает полученный контент клиенту. Следует отметить, что реальный запрашивающий клиент скрыт в прямом прокси-процессе, то есть сервер не знает, кто является официальным запрашивающим клиентом. (Научный Интернет)
-
Так называемый обратный прокси-сервер, клиент отправляет запрос обратному прокси-серверу, обратному прокси-серверу, чтобы определить, где находится запрос после получения запроса, а затем результаты возвращаются клиенту. Также обратите внимание, что в ходе обратного прокси-сервера, скрытого внутреннего информационного сервера, пользователю не нужно знать, какой сервер предоставлять определенные услуги, поскольку обратный прокси-сервер знает, кто хорош, мы можем даже поставить обратные прокси-серверы как настоящее удовольствие. Эта форма прокси часто используется для балансировки нагрузки, например, Nginx — отличный обратный прокси-сервер.
-
Обратный агент для решения междоменных проблем: наш внешний интерфейс часто сталкивается с междоменными проблемами при использовании инструмента формирования шаблонов Vue-CLI, поскольку сам проект запускает локальную службу, необходимую для занятия порта (например,http://localhost:8080), поэтому неизбежно возникнут междоменные проблемы (поскольку локальный сервисный порт и адрес интерфейса сервера имеют разное происхождение). В проектах, которые используют webpack в качестве инструмента сборки, прокси proxyTable часто используется для достижения кросс-доменности (конкретная реализация самостоятельного Baidu). Причина, по которой возникает междоменный доступ, заключается в том, что браузер имеет ограничение политики одного и того же происхождения, но сервер не имеет ограничения политики одного и того же происхождения. Когда наша локальная служба (при условии, что доменное имя: http://localhost:8080) хочет запросить ресурсы целевого сервера (при условии, что доменное имя: http://target.com), мы не запрашиваем напрямую target.com, но вместо этого запрашивает сам локальный сервис http://localhost:8080 (это запрос того же происхождения, междоменного нет), локальная прокси-служба перенаправляет интерфейс на target.com (обратите внимание, что это прямая связь между двумя серверами, а не связь между клиентом и сервером, поэтому между доменами нет), локальная служба получает данные ответа целевого сервера, а затем маскирует их. как локальный сервис через прокси. Возвращаемое значение запроса возвращается клиенту.
Локальная служба инициирует запрос к локальной службе в браузере --> локальный прокси пересылает --> целевой сервер --> данные ответа маскируются под возвращаемое значение запроса локального сервера через прокси --> браузер получает данные с целевого сервера
Конфигурация обратного прокси-сервера vue-cli выглядит следующим образом:
//vue.config.js
......
devServer: {
port: 8080, // 配置端口
open: true, // 项目启动自动开启浏览器
compress: true, // 开启压缩
overlay: { // 设置让浏览器 overlay 同时显示警告和错误
warnings: true,
errors: true
},
// 设置请求反向代理
proxy: {
'/api': { // 要代理的接口的匹配字符
target: process.env.BASE_URL, // 接口域名
secure: false,
changeOrigin: true
}
}
},
......
Следует отметить, что если используется обратный прокси, при настройке axios запросbaseURLДолжен быть установлен в строку'/', иначе прокси не совпадет'/api'привести к сбою прокси.
кеш-сервер
Кэш-сервер относится к технологии, которая хранит сетевой контент, к которому необходимо часто обращаться, на сервере, который находится ближе к пользователю и имеет более высокую скорость доступа для повышения скорости доступа к контенту. Кэш-сервер является промежуточным сервером между браузером и исходным сервером.Браузер сначала инициирует HTTP-запрос к этому промежуточному серверу, а после обработки (например, проверки разрешений, сопоставления кеша и т. д.) запрос перенаправляется на исходный сервер. сервер.
HTTPS
HTTP сам по себе не имеет никакой конфиденциальности, поэтому данные, передаваемые по HTTP, эквивалентны полосам в Интернете в виде открытого текста. Для решения этой проблемы появились различные методы шифрования:
- Симметричное шифрование: уникальный ключ
key1Может использоваться для шифрования и дешифрования. Такое шифрование требует, чтобы обе стороны имели ключkey1, если первый ключ передачи перехвачен третьей стороной, игра окончена. - Асимметричное шифрование: открытый ключ
key3и закрытый ключkey2Оба могут использоваться для соответствующего шифрования и дешифрования, то есть шифрования с помощью открытого ключа и дешифрования с помощью закрытого ключа, или шифрования с помощью закрытого ключа и дешифрования с помощью открытого ключа. Сервер сгенерирует пару ключей. Один закрытый ключ хранится на сервере и известен только вам, а другой является открытым ключом. Открытый ключ может быть свободно выпущен для использования кем угодно. Открытый текст клиента, зашифрованный с помощью открытого ключа, необходимо расшифровать с помощью закрытого ключа. Асимметричные ключи используют разные ключи в процессе шифрования и дешифрования.Шифрование и дешифрование являются асимметричными, поэтому это называется асимметричным шифрованием. По сравнению с шифрованием с симметричным ключом, асимметричное шифрование не требует обмена ключами между клиентом и сервером.Пока закрытый ключ не отправляется ни одному пользователю, даже если открытый ключ перехвачен в Интернете, его нельзя расшифровать, только украсть. открытый ключ бесполезен. - Гибридное шифрование: сервер сначала использует закрытый ключ асимметричного шифрования.
key2ключ шифрования для симметричного шифрованияkey1И передать его клиенту, клиент использует открытый ключ асимметричного шифрованияkey3Расшифровать симметричный ключ шифрованияkey1, обе стороны имеют ключkey1, начать использоватьkey1Зашифрованное общение. Недостаток: посредник может сам сгенерировать открытый ключ асимметричного шифрования, чтобы заменить открытый ключ сервера и отправить его клиенту, а клиент в это время не может проверить достоверность открытого ключа. - SSL: во-первых, вам необходимо подать заявку на сертификат в центре сертификации (сертификат содержит подпись сертификата и открытый ключ сервера).
key3). Когда клиент инициирует HTTP-запрос, сервер отправляет сертификат клиенту. Клиент проверяет подлинность сертификата, а затем расшифровывает открытый ключ сервера.key3, зашифровать самостоятельно сгенерированный симметричный ключ шифрования с помощью открытого ключаkey1И передать его на сервер, и, наконец, использоватьkey1Зашифрованные звонки. Что касается безопасности, поскольку закрытый ключ является институциональным, он позволяет избежать подделки сертификатов третьими лицами. И даже если открытый ключ сервера получен, открытый ключ не может быть расшифрован.key3зашифрованный симметричный ключ шифрованияkey1.
HTTPS основан на протоколе HTTP и обеспечивает зашифрованную обработку данных, аутентификацию личности другой стороны и защиту целостности данных через SSL или TLS (которые можно рассматривать как SSL3.0). Особенности следующие:
- Шифрование контента: используя технологию гибридного шифрования, посредник не может напрямую просматривать контент в виде открытого текста.
- Подтвердить личность: аутентифицировать клиента с помощью сертификата для доступа к собственному серверу.
- Защитите целостность данных: предотвратите олицетворение или фальсификацию передаваемого контента посредниками.
Основные различия между HTTPS и HTTP заключаются в следующем:
- Протокол HTTPS требует сертификата от ЦС (центр сертификации).Как правило, бесплатных сертификатов очень мало, и вам нужно платить комиссию.
- Протокол HTTP работает поверх TCP, весь передаваемый контент представляет собой открытый текст, HTTPS работает поверх SSL/TLS, SSL/TLS работает поверх TCP, и весь передаваемый контент зашифрован.
- HTTP и HTTPS используют совершенно разные методы подключения и используют разные порты: первый — 80, а второй — 443.
- Соединение по http очень простое и без сохранения состояния; протокол HTTPS — это сетевой протокол, созданный на основе протокола HTTP+SSL, который может выполнять зашифрованную передачу и аутентификацию личности, что может эффективно предотвратить угон оператора и решить серьезную проблему защиты от угона. Протокол http является безопасным.
веб-безопасность
XSS-атака
Атака XSS, полное название атаки межсайтового скриптинга, заключается в использовании html для выполнения<script>alert(1)</script>функцию, попробуйте внедрить скрипты на страницу в качестве метода атаки. Существует два типа XSS-атак: один заключается в изменении URL-адреса браузера для внедрения скрипта на страницу, а другой — во внедрении кода скрипта в базу данных через поле ввода. Первый будет автоматически защищаться браузером хрома (но лучше защищать его вручную), а второй требует от нас защиты вручную.Рекомендуется использовать метод защиты с фильтрацией белого списка библиотеки xss:
const xss = require('xss')
let html = xss('<h1 id="title">XSS Demo</h1><script>alert("xss");</script>')
// -> <h1>XSS Demo</h1><script>alert("xss");</script>
CSRF-атака
CSRF на китайском языке называется подделкой межсайтовых запросов. Если у Nuggets есть интерфейс GET для добавления внимания, параметр id является идентификатором подписчика, как показано ниже:
https://juejin.cn
Тогда мне просто нужно написать тег img на одной из моих страниц:
<img src="https://juejin.cn" />
Затем, пока пользователь, вошедший в Nuggets, открывает мою страницу, он будет автоматически подписываться на меня. Даже если он изменен на POST-запрос, за ним может автоматически следовать отправка формы на странице. Атака CSRF — это неявный механизм аутентификации, происходящий из Интернета! Хотя механизм аутентификации в Интернете может гарантировать, что запрос поступает из браузера пользователя, он не может гарантировать, что запрос будет одобрен пользователем. Проблема CSRF-атаки обычно решается сервером, для предотвращения CSRF-атаки можно следовать следующим правилам:
- Запросы Get не используются для изменения данных
- Настройки файлов cookie
HTTP Only - Настройки интерфейса запрещают междоменное
- Запрос сопровождается проверочной информацией, такой как проверочный код или токен.
кликджекинг
Clickjacking — это атака визуального обмана. Злоумышленник встраивает атакуемый веб-сайт в свою веб-страницу через iframe и устанавливает прозрачность iframe, а затем побуждает пользователя действовать на странице.В это время пользователь будет нажимать на прозрачную страницу iframe без Зная это. Будет ли поймана картина yck ┭┮﹏┭┮):
Способ защиты:
Или позвольте серверному боссу решить это, используйте заголовок ответа HTTP -X-Frame-Options.X-Frame-OptionsМожно сказать, что он был создан для решения проблемы кликджекинга и имеет три необязательных значения:
- DENY: Браузер откажет текущей странице в загрузке любой страницы фрейма;
- Sameorigin: Адрес страницы фрейма может быть только страницей под гомологичным доменным именем;
- ALLOW-FROM origin: адрес страницы, с которой разрешена загрузка фрейма;
атака «человек посередине»
Атака «человек посередине» заключается в том, что злоумышленник устанавливает соединение с сервером и клиентом одновременно и заставляет другую сторону думать, что соединение безопасно, но на самом деле весь процесс связи контролируется злоумышленник. Злоумышленник может не только получить коммуникационную информацию обеих сторон, но и изменить коммуникационную информацию. Суть атаки «человек посередине» заключается в вопросах аутентификации и доверия между клиентом и сервером.
Симметричное шифрование, асимметричное шифрование и гибридные технологии шифрования не обеспечивают эффективного предотвращения атак посредника, поскольку посредник может перехватить ключ, передаваемый в первый раз, и украсть день, но клиент или сервер не может этого знать. В качестве окончательного средства предотвращения атак «человек посередине» HTTPS вводит механизм сертификатов для решения проблемы доверия между клиентом и сервером, тем самым эффективно предотвращая атаки «человек посередине».
резюме
Выше приведены знания, связанные с HTTP, которые необходимо освоить переднему интерфейсу. Некоторые знания, ограниченные возможностями, могут быть неясными. Пожалуйста, покритикуйте и исправьте неясные моменты.
Фронт представляет собой огромную тему, хотя и менее требовательный от барьеров для въезда, но его огромное знание людей чувствуют себя бессильными и разочарованными. Как на полпути приличный белый ребенок, я намерен следовать Даниилууказывая(Спасибо) Чтобы изучить внешний интерфейс с нуля, каждый пункт знаний будет суммирован, чтобы углубить мое понимание и облегчить другим консультирование.
Рекомендую прочитать еще одну статью о http протоколеСупер подробное объяснение протокола HTTP, для более подробного объяснения HTTP.