предисловие
Первоначально эта статья была заметкой, которую я сделал год назад, когда читал «Иллюстрированный HTTP», но после того, как я ее закончил, я положил ее в угол папки и оставил в покое. Некоторое время назад, когда я занимался проектом, я столкнулся с проблемой с кодом состояния, поэтому я взял его и пролистал, заодно сделал некоторые изменения на исходной основе и добавил кое-что про HTTPs. Эта статья в основном является кратким изложением относительно важных знаний о HTTP.Если вы хотите хорошо изучить HTTP, вам все равно необходимо прочитать «Иллюстрированное руководство по HTTP» или «Авторитетное руководство по HTTP», чтобы создать относительно полную систему знаний. В конце концов, вы угадали, я легендарный хедлайнер, но надеюсь, что эта статья хоть немного вам пригодится, 2333.
1. Краткий обзор HTTP (из MDN)
Протокол передачи гипертекста (HTTP) — это протокол прикладного уровня для передачи гипермедиа-документов, таких как HTML. Он предназначен для связи между веб-браузерами и веб-серверами, но может использоваться и для других целей. HTTP следует классической модели клиент-сервер, когда клиент открывает соединение для выполнения запроса, а затем ожидает получения ответа на стороне сервера. HTTP — это протокол без сохранения состояния, что означает, что сервер не сохраняет никаких данных (состояния) между двумя запросами. Хотя обычно он основан на уровне TCP/IP, его можно использовать на любом надежном транспортном уровне.
2. URL-адреса и URI
Мы часто сталкиваемся с URL (унифицированным указателем ресурсов), который представляет собой строковый адрес, который мы используем для доступа в Интернет. URI относительно незнаком для нас, и его название — унифицированный идентификатор ресурса (URI). Рассмотрим их конкретные отличия:
- URI: универсальный идентификатор ресурса. Универсальный идентификатор ресурса, идентификатор ресурса, это абстрактный идентификатор ресурса, который может быть относительным или абсолютным.
- URL-адрес: единое местоположение ресурса. Унифицированный указатель ресурса, который одновременно является идентификатором ресурса, но указывает, как найти ресурс «Найти». Поскольку он указывает информацию о местоположении, он должен быть абсолютным.
(Относительный адрес, о котором мы обычно говорим, на самом деле относится только к другому абсолютному адресу)
2.1 URL
Основной формат URL-адреса следующий:
schema://host[:port#]/path/.../[?query-string][#anchor]
| Формат | значимость |
|---|---|
| scheme | Указывает протокол, используемый нижним уровнем (например, http, https, ftp). |
| host | IP-адрес или доменное имя HTTP-сервера. |
| port# | Порт HTTP-сервера по умолчанию — 80, в этом случае номер порта можно не указывать. Если используется другой порт, его необходимо указать. |
| path | Путь доступа к ресурсу. |
| query-string | Данные отправляются на http-сервер. |
| anchor- | якорь |
3. HTTP-сообщение
3.1 Формат HTTP-сообщения
Формат сообщения HTTP в основном делится на заголовок сообщения и тело сообщения:
Пустая строка используется для того, чтобы отличить заголовок сообщения от тела сообщения, и состоит из возврата каретки и перевода строки.
И сообщение-запрос, и сообщение-ответ должны иметь заголовок сообщения, а в теле сообщения не должно быть некоторых сообщений-запросов. Общий формат сообщения запроса следующий:
Формат ответного сообщения следующий:
Ниже приведено содержимое HTTP-сообщения Google Chrome, где заголовки запроса описывают содержимое заголовка сообщения запроса, а заголовки ответа описывают содержимое заголовка ответного сообщения:
Среди наиболее распространенных свойств можно выделить следующие:
- URL, адрес http доступа
- метод запроса, метод запроса сообщения
- код состояния, код состояния и фраза состояния
- Принять кодировку, контент-кодирование
- Подключение, подключение
- Файл cookie, добавленное содержимое файла cookie
- Хост, целевой хост
- User-Agent, информация о клиентском браузере
- Set-Cookie, укажите, что вы хотите сохранить в куки
Далее поговорим о роли этих свойств
3.2 Метод HTTP-запроса (метод запроса) — GET и POST
Есть много способов отправить HTTP, но наиболее распространенными являются POST и GET.
-
GET: метод GET можно использовать для запроса доступа к ресурсу, указанному в URL-адресе. Указанный ресурс анализируется сервером и возвращает содержимое ответа. Проще говоря, если запрошенный ресурс является текстом, он будет возвращен как есть.
-
POST: метод POST можно использовать для передачи тела объекта.
Основные различия между ними заключаются в следующем:
- разные цели
Для получения информации используются как POST, так и GET, но метод GET представляет собой только запрос и не оказывает никакого влияния на содержимое на сервере; содержимое каждого GET одинаково. POST часто используется для отправки определенного контента для некоторых операций модификации.
- другой размер
Поскольку разные браузеры имеют определенные ограничения на длину URL-адреса, поскольку метод GET помещается в заголовок URL-адреса, он, естественно, следует за первым, но конкретный размер зависит от браузера. Метод POST помещает содержимое в содержимое сообщения, поэтому, пока содержимое сообщения не ограничено, его размер не ограничен.
- разная безопасность
Выше также сказано, что GET добавляется непосредственно в конец URL-адреса, и содержимое можно увидеть непосредственно в URL-адресе. POST размещается внутри сообщения, и пользователь не может его видеть напрямую.
Как правило, GET используется для получения определенного контента, а POST используется для отправки определенного запроса данных.С точки зрения сценариев использования контент, зарегистрированный обычным пользователем, является частным, и для его сохранения следует использовать метод POST. private Когда на контент нужно быстро ответить, используется GET.
3.3 код состояния
Код состояния обычно представляет собой то, что сервер сообщает клиенту. Он классифицируется следующим образом:
| код состояния | имея в виду |
|---|---|
| 1** | Сервер получает запрос и требует от запрашивающей стороны продолжить операцию. |
| 2** | Success, операция успешно получена и обработана |
| 3** | Перенаправление, дальнейшие действия, необходимые для выполнения запроса |
| 4** | Ошибка клиента, запрос содержит синтаксическую ошибку или запрос не может быть выполнен |
| 5** | Ошибка сервера, сервер обнаружил ошибку при обработке запроса |
Общие коды состояния:
- 200 Обычный успех OK
GET: запрошенный ресурс будет возвращен в качестве ответа. Ответ будет содержать описание или результат операции. POST: возвращает результат обработки соответствующего запроса.
- 204 Запрос был успешно обработан, и ничего не было возвращено No Content
Указывает, что запрос, полученный сервером, обработан, но серверу не нужно возвращать ответ. Например, если клиент является браузером, страница, отображаемая браузером, не будет обновляться.
- 206 Partial Content
Частичный запрос GET успешно обработан
- 301 Moved Permanently
Запрошенная веб-страница была окончательно перемещена в новое место, постоянное перенаправление
- 302 Found
Веб-сайт временно перенаправлен и временно недоступен (для протокола, проверяется)
- 303 See Other
Этот код состояния указывает, что для ресурса, соответствующего запросу, существует другой URI, и указывает, что для получения запрошенного ресурса необходимо использовать метод GET. В отличие от 302, 302 не изменит метод последнего запроса.
- 304 Not Modified
Если к нему нельзя получить доступ и он возвращает то же самое, что и в прошлый раз, это означает, что ресурс не был изменен, и он по-прежнему такой же, как и при последнем доступе.
- 307 Temporary Redirect
Временное перенаправление похоже на 302 и 303. Разница в том, что оно не указывает, какой метод клиент должен использовать для запроса.
- 400 Bad Request
Указывает, что в клиенте произошла синтаксическая ошибка, из-за которой сервер не смог понять запрос. Клиенту необходимо изменить содержимое запроса и снова отправить запрос.
- 401 Unauthorized
т. е. у пользователя нет необходимых учетных данных. Этот код состояния указывает, что текущий запрос требует аутентификации пользователя.
- 403 Forbidden
Сервер понял запрос, но отказался его выполнять.
- 404 Not Found
Сервер не может найти запрошенную веб-страницу.
- 500 Internal Server Error
Сервер обнаружил ошибку и не смог выполнить запрос.
- 503 Service Unavailable
В настоящее время сервер не может обрабатывать запросы из-за временного обслуживания или перегрузки сервера. Эта ситуация временная.
3.4 Кодирование контента Принять кодирование
Поскольку содержимое некоторых пакетов слишком велико, для сокращения времени передачи HTTP предпримет некоторые меры сжатия.Например, в приведенной выше информации о пакете Accept-Encoding определяет формат кодирования содержимого gzip.
В общем, форматы кодирования контента следующие:
- gzip: формат сжатия GNU
- сжатие: стандартный формат сжатия для систем UNIX.
- deflate: это формат сжатия без потерь, который использует как кодировку LZ77, так и кодировку Хаффмана.
- личность: без сжатия
3.5 Постоянство - соединение
При обычной отправке HTTP нам нужно установить TCP-соединение, а затем отправить сообщение:
Если вам нужно отправлять HTTP-пакеты каждый раз, когда вам нужно пройти вышеописанный процесс, то, несомненно, будет тратиться много времени на процесс установления и разрыва соединений, поэтому HTTP использует атрибут соединения для указания метода соединения. Когда он становится активным, устанавливается постоянное соединение. Таким образом, вам не нужно разрывать соединение каждый раз, когда соединение устанавливается:
(В HTTP1.1 соединение по умолчанию включает поддержку активности)
3.6 HTTP без сохранения состояния — файлы cookie
Поскольку HTTP является протоколом без сохранения состояния, это связано с тем, что веб-сервер должен сталкиваться с одновременным доступом многих браузеров.Чтобы улучшить возможности обработки веб-сервером для одновременного доступа, при разработке протокола HTTP веб-сервер должен отправлять HTTP пакеты ответа и документы не сохраняют никакой информации о состоянии запрашивающего процесса веб-браузера, тем самым снижая нагрузку на серверную сторону, в то время как без сохранения состояния также снижает накладные расходы HTTP-запросов.
Однако, когда в некоторых сценариях необходимо постоянно помнить информацию о пользователе, безгражданство, очевидно, не может удовлетворить потребности, поэтому HTTP предоставляет файлы cookie для решения этой проблемы.Технология файлов cookie контролирует состояние клиента, записывая информацию о файлах cookie в запрос и соответствующий сообщение. . Файл cookie уведомляет клиента о сохранении файла cookie в соответствии с информацией поля заголовка, называемой set-cookie, в соответствующем сообщении, отправленном с сервера. Когда клиент отправит запрос на сервер в следующий раз, клиент автоматически добавит значение cookie в заголовок запроса и отправит его. Запрос без файлов cookie:
Запрос при сохранении файла cookie:
Проще говоря, файл cookie — это содержимое, определяемое сервером и сохраняемое в браузере клиента. Таким образом, каждый раз, когда вы добавляете информацию о пользователе, запрос автоматически добавляет соответствующий контент в файл cookie.
(Если вас интересует хранение данных на стороне браузера, вы можете прочитать эту статью:: поговорим о распространенных решениях для хранения данных на стороне браузера.)
3.7 Запрос объема
В некоторых сценариях, когда мы используем пакеты HTTP для запроса больших изображений, процесс загрузки может быть очень медленным. (Например, некоторые веб-сайты с фотографиями). В это время мы обнаружим, что некоторые изображения загружаются по частям. Это должно установить длину HTTP-запроса для загрузки ресурса по частям. Вы можете указать свой собственный HTTP-запрос, используя атрибут Range в сообщении запроса и атрибут Content-Type в ответном сообщении.
3.8 Сводка заголовков сообщений
(изображение перенесено с: http://www.cnblogs.com/xing901022/p/4311987.html)
4. HTTP-метод
HTTP поддерживает несколько различных команд запроса, которые называются методами HTTP. Каждый Каждое сообщение HTTP-запроса содержит метод. Этот метод сообщает серверу, какое действие выполнить (получить веб-страницу, запустить программу-шлюз, удалить файл и т. д.). В следующей таблице приведены некоторые распространенные методы HTTP:
| HTTP-метод | описывать |
|---|---|
| GET | Отправить именованный ресурс с сервера на клиент |
| PUT | Хранить данные от клиентов в именованном ресурсе сервера |
| DELETE | Удалить именованный ресурс с сервера |
| POST | Отправка клиентских данных в приложение шлюза сервера |
| HEAD | Отправлять заголовки HTTP только в ответах именованных ресурсов |
(GET и POST обсуждались выше и здесь обсуждаться не будут)
4.1, PUT передать файлы
Метод PUT используется для передачи файлов, как и загрузка Weng Jian по протоколу FTP, который требует, чтобы содержимое файла было включено в тему сообщения запроса, а затем сохранено в месте, указанном URI запроса. Поскольку метод PUT не имеет механизма аутентификации, любой может загружать файлы, и существуют проблемы с безопасностью, поэтому этот метод не подходит для обычных веб-сайтов.
4.2, УДАЛИТЬ удалить файлы
Метод DELETE используется для удаления файлов, что является противоположностью put.Метод DELETE удаляет указанный ресурс в соответствии с URL-адресом запроса. Суть его та же, что и у метода PUT без механизма проверки, поэтому рекомендуется меньше использовать метод DELETE.
4.3 HEAD получает заголовок сообщения
Метод HEAD аналогичен методу GET, за исключением того, что он не возвращает основную часть сообщения и обычно используется для подтверждения правильности url, а также даты и времени обновления ресурса.
5.HTTPS
5.1 Что такое HTTPS
HTTPS (полное название: Hyper Text Transfer Protocol over Secure Socket Layer) – это защищенный канал HTTP. Короче говоря, это безопасная версия HTTP, то есть добавление слоя SSL в HTTP. Краеугольным камнем безопасности HTTPS является SSL, поэтому шифрование Детали требуют SSL. Сейчас он широко используется, например, GitHub, Alipay, Nuggets и т. д.
5.2 Зачем нужен HTTPS
Это связано с тем, что HTTP имеет несколько недостатков:
- При передаче используется открытый текст, который, очевидно, будет перехвачен правонарушителями для совершения каких-то темных дел.
- Механизм аутентификации отсутствует, поэтому мы можем подделать некоторый HTTP-доступ, что, очевидно, вызывает некоторые проблемы. Например, типичным примером является Jmeter, который подделывает множество URL-адресов HTTP, а затем проводит стресс-тестирование, что является своего рода DOS-атакой.
- Целостность сообщения не может быть проверена, например, HTTP-сообщение было перехвачено и изменено злоумышленником, но сервер не может его проверить.
5.3 Различия между HTTP и HTTPS
Именно из-за этих недостатков в HTTPS были внесены следующие изменения:
- HTTP — это передача открытого текста, HTTPS шифруется с помощью SSL\TLS;
- Номер порта — 80 для HTTP и 443 для HTTPS;
- HTTPS необходимо подать заявку на сертификат от ЦС.Как правило, бесплатных сертификатов очень мало, и они должны быть платными;
- - Соединения HTTP просты и не имеют состояния. Протокол HTTPS состоит из SSL+HTTP; сетевой протокол, построенный на основе протокола, может выполнять зашифрованную передачу и аутентификацию личности, что является более безопасным, чем протокол HTTP.
5.4 Дефекты HTTPS
Можно сказать, что по сравнению с HTTP, HTTPS — это святой Сейя в золотых доспехах, трансформировавшийся Ультрачеловек и уснувший Когоро Мори, что не только повышает безопасность, но и повышает силу. Но у HTTPS есть и недостатки:
- Скорость связи замедлена, из-за необходимости шифрования приходится еще несколько круговых обходов для рукопожатия;
- Увеличение нагрузки на машину пользователя. (Возможно, вы не поверите, когда скажете это. Когда наша школа вечером, сайт, использующий протокол HTTPS, практически недоступен.)
6. HTTP-аутентификация
Некоторые веб-сайты требуют, чтобы пользователь вошел в систему, чтобы получить личную информацию пользователя для следующей операции, поэтому вам необходимо знать эти сообщения в любое время, но вы не должны каждый раз просить пользователя вводить пароль пользователя, что заставит пользователя чувствую себя очень неудобно, поэтому HTTP также поставляется с функцией аутентификации Методы аутентификации в основном следующие:
6.1 БАЗОВАЯ сертификация
Среди них сертификация BASIC является самой простой сертификацией, и общий процесс выглядит следующим образом:
- Клиент обращается к URL-адресу.
- Сервер возвращает код состояния 401, предлагая пользователю ввести имя пользователя и пароль.
- Пользователь вводит имя пользователя и пароль, которые передаются посредством кодировки BASE64.
- Сервер аутентифицирован и возвращает код состояния 200.
Но у него есть следующие недостатки:
- Только через кодировку BASE64, на самом деле это относится к передаче открытого текста, и безопасность не высока
- Некоторые браузеры не поддерживают выход
6.2 Дайджест-сертификация
Именно из-за слабости BASIC-аутентификации DIGEST-аутентификация стала доступна начиная с HTTP/1.1. DIGEST-аутентификация также использует метод запроса/ответа, но не отправляет пароли напрямую в виде открытого текста, как BASIC-аутентификация.
6.3 Сертификация SSL (более распространенная)
Аутентификация клиента SSL — это способ завершить аутентификацию с помощью клиентских сертификатов HTTPS. При аутентификации сертификата клиента сервер может подтвердить, что доступ осуществляется от вошедшего в систему клиента.
Шаги для аутентификации клиента SSL:
- Когда сервер получает запрос на ресурс, который необходимо аутентифицировать, сервер отправляет сообщение CertificateRequest, чтобы запросить у клиента предоставление сертификата клиента.
- Клиент отправляет информацию о сертификате клиента на сервер в форме сообщения сертификата клиента.
- Сервер может получить открытый ключ клиента в сертификате только после того, как сертификат клиента прошел проверку, а затем начать зашифрованную связь HTTPS.
Веб-сайты с высокими требованиями к безопасности, такие как Alipay и онлайн-банкинг, должны загружать цифровой сертификат при входе в систему. Этот цифровой сертификат является своего рода проверкой SSL-клиента. Но его недостатки также очевидны, его нужно скачивать вручную, что будет очень хлопотно для все более ленивых пользователей сети (в том числе и для меня).
6.4 Аутентификация формы (наиболее часто используемая)
Последний метод аутентификации является наиболее распространенным, мы можем аутентифицироваться через cookie или сеанс.
Сочетание управления сессиями и использования файлов cookie
Как я упоминал ранее, HTTP является протоколом без сохранения состояния и не может реализовывать управление состоянием, отсюда и файлы cookie. Мы можем использовать файлы cookie для управления сеансом (сеансом), чтобы компенсировать функцию управления состоянием, которой нет в протоколе HTTP.
Шаги аутентификации:
- Клиент помещает идентификатор пользователя, пароль и другую связанную информацию в сущность сообщения, а затем отправляет ее на сервер, обычно в форме запроса POST.
- Сервер выдает идентификатор сеанса для идентификации пользователя. Аутентификация выполняется путем проверки информации для входа, отправленной клиентом, а статус аутентификации пользователя привязывается к идентификатору сеанса и записывается на сервере.
- После того, как клиент получит идентификатор сеанса, он будет сохранен локально в виде файла cookie. В следующий раз, когда запрос будет отправлен на сервер, браузер автоматически отправит файл cookie, и идентификатор сеанса будет отправлен на сервер соответственно. Сервер идентифицирует пользователя и его статус аутентификации, проверяя полученный идентификатор сеанса, после чего пользователь может выполнять определенные операции.
Использованная литература:
- «Иллюстрированный HTTP»
- https://juejin.cn/post/6844903504046211079
- http://www.cnblogs.com/xing901022/p/4309840.html