предисловие

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

Основы сети

Уровни TCP/IP

Некоторые люди делят систему TCP/IP на четыре уровня, а некоторые — на пять.В разных книгах используются разные методы разделения. Разница между уровнем 5 и уровнем 4 заключается в том, что уровень канала передачи данных и физический уровень уровня 5 соответствуют уровню сетевого интерфейса уровня 4. Оба правильны, не нужно путать, просто узнайте их. Если он разделен по протоколу, то физический уровень отдельно делить не надо, ведь физический уровень не имеет протокола. В этой статье используется четырехуровневая структура.

имя	эффект
прикладной уровень	Такие протоколы, как HTTP, FTP и DNS, расположены на этом уровне и используются для предоставления услуг приложений пользователям.
транспортный уровень	Основными протоколами этого уровня являются протоколы TCP и UDP, которые обеспечивают функции сквозной связи для объектов прикладного уровня.
Сетевой уровень	Ядром этого уровня является протокол IP, который определяет путь к компьютеру другой стороны и передает пакет данных другой стороне. Протоколы ARP и RARP также расположены на этом уровне.
слой сетевого интерфейса	Отвечает за получение пакетов IP-данных и их отправку по сети или получение физических кадров из сети, извлечение пакетов IP-данных и передачу их на сетевой уровень. Распространенными протоколами на этом уровне являются Ethernet 802.3 и Token Ring 802.5.

Транспортный поток связи TCP/IP

При общении с семейством протоколов TCP/IP связь с другой стороной осуществляется в многоуровневом порядке. Отправитель снимается с прикладного уровня, а принимающая сторона поднимается со следующего уровня. Когда передающий конец передается между слоем и слоем, первый слой будет помещен в первый слой. И наоборот, когда принимающая сторона передает данные в уровне и уровне, соответствующая информация заголовка будет удаляться каждый раз на один уровень.

Трехстороннее рукопожатие протокола TCP

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

Отправитель сначала отправит другой стороне пакет данных с флагом SYN. После того, как принимающая сторона получит его, она возвращает пакет данных с флагом SYN/ACK для передачи подтверждающей информации. Наконец, отправитель отправляет обратно пакет данных с флагом ACK, что означает окончание «рукопожатия».

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

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

Анализ сценария:В этой сцене друг А — клиент, а друг Б — сервер. Теперь такой вопрос, как сделать так, чтобы Друзья А и Друзья Б смогли успешно вернуть мыльную любовь года? С точки зрения друга А, я должен убедиться, что друг Б находится на другой стороне моего телефона. С точки зрения друга Б я должен убедиться, что друг А находится на другой стороне моего телефона. Только когда обе стороны могут быть уверены, что другой конец телефона является другой стороной, эти мыльные отношения могут быть восстановлены. Далее мы анализируем трехстороннее рукопожатие в этом измерении.

Первое рукопожатие:Jiyou A набрала номер телефона и сказала: «Привет, это Jiyou B?» (Это похоже на отправку пакета данных с флагом SYN на сервер от клиента). Когда выдается это предложение, Друг А не может быть уверен, что другая сторона — это Друг Б, и точно так же Друг Б не может быть уверен, что другая сторона — Друг А.

Второе рукопожатие:Jiyou B подняла трубку и сказала: «Я Jiyou B, а вы кто?» (это похоже на то, как сервер возвращает пакет данных с флагом SYN/ACK для подтверждения информации). Как только это предложение отправлено, основной друг A может определить, что другая сторона является основным другом B, но в это время основной друг B не может определить, что другая сторона является основным другом A.

Третье рукопожатие:Jiyou A подтвердила, что на другом конце провода была Jiyou B, и была очень взволнована, и ответила: «Разве вы меня не знаете? Я Jiyou A» (это похоже на отправку данных с флагом ACK из отправитель. сумка). Как только это предложение будет отправлено, Jiyou B может подтвердить, что на другом конце телефона находится Jiyou A, основываясь на этом предложении. В этот момент обе стороны A и B могут подтвердить друг друга в качестве другой стороны. Выполните условия, чтобы восстановить мыльные отношения, вы можете начать восстанавливать базовую дружбу.

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

1. Клиент — отправитель, а сервер — получатель.

2. Сервер является отправителем, а клиент — получателем.

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

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

Второй разрыв:После того, как сервер получает сегмент FIN от клиента, он возвращает сегмент ACK и соглашается на запрос клиента на отключение. В этот момент сервер переходит в состояние CLOSE-WAIT, ожидая, пока клиент закроет соединение. Когда клиент получает сегмент ACK, возвращенный с сервера, клиент закрывает соединение для отправки данных на сервер, и в это время клиент переходит в состояние FIN_WAIT_2.

Третий разрыв:После отключения соединения от клиента к серверу сервер отправляет клиенту FIN-сегмент с запросом на отключение соединения от сервера к клиенту. В это время сервер переходит в состояние LAST_ACK и ожидает подтверждения от клиента.

Четвертый разрыв:После того, как клиент получает сообщение FIN от сервера, он возвращает сегмент ACK, чтобы согласиться с запросом на закрытие соединения. В этот момент клиент входит в состояние TIME_WAIT. После того, как сервер получает сегмент ACK от клиента, он закрывает соединение, по которому сервер отправляет данные клиенту, и сервер переходит в состояние CLOSED. И клиент в это время все еще находится в состоянии ожидания, так как же клиент может также войти в состояние ЗАКРЫТО? Очень просто, после того как клиент подождет два раза MSL, он автоматически перейдет в состояние CLOSED.

Разница между URI и URL

Когда дело доходит до URL и URI, это действительно глупые крысы, которые не могли бы сказать Тигра, там должно быть много мелких партнеров, которые запутают их. URL называется унифицированным указателем ресурса, а URI называется универсальным идентификатором ресурса. Хотя оба имени похожи, но различие между ними действительно довольно простое. URL и URI можно сравнить с нашим почтовым адресом и почтовым индексом. URL-адрес превышает диапазон URI. У Taobao, например, https://www.taobao.com/ этот домен является URL-адресом, а адрес каждого элемента представляет собой URI.

Во многих инструментах AJAX именем параметра адреса является url, например, метод $.ajax в jquery использует url, но мы должны убедиться, что адрес HTTP-запроса является URI, а не URL. # Простой протокол HTTP

Метод HTTP-запроса

имя	описывать	Минимальная поддерживаемая версия протокола
GET	Запрос ресурса на сервере.	1.0
POST	Отправьте данные указанному ресурсу для обработки запроса, и данные будут включены в тело запроса.	1.0
HEAD	Используется для подтверждения правильности URI, а также даты и времени обновления ресурса, возвращает не тело сообщения, а только заголовок сообщения.	1.0
PUT	Он используется для передачи файлов, помещения содержимого файла в тело сообщения и его сохранения в месте, указанном URI.	1.1
DELETE	В отличие от PUT, URI запроса удаляет указанный ресурс.	1.1
OPTIONS	Запросите методы, поддерживаемые для ресурса, указанного URI запроса.	1.1
TRACE	Используется для отслеживания путей. При отправке запроса в поле заголовка Max-Forwards будет указано значение, которое уменьшается на 1 после прохождения каждого сервера. Когда значение равно 0, передача останавливается и принимается последний ответ сервера.	1.1
CONNECT	Он используется для установления туннеля при обмене данными с прокси-сервером и реализации TCP-соединения с протоколом туннелирования.	1.1

HTTP-протокол 1.1

постоянное соединение

В версии 1.0 TCP-соединение отключалось для каждого HTTP-соединения. Стоимость новых TCP-соединений высока, а частое открытие и закрытие значительно увеличивает накладные расходы и влияет на производительность. Итак, в версии 1.1 был введен метод постоянного подключения. Его характеристика заключается в том, что ни одна из сторон явно не предлагает отключиться, а состояние TCP-соединения сохраняется.

трубопроводный механизм

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

Добавить поле HOST

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

Кодирование групповой передачи

В версии 1.1 существует несколько ответов в одном TCP-соединении. Как отличить, какому ответу соответствует пакет, становится проблемой. Появился в версии 1.1Content-LengthВ этом поле отмечается длина данных этого ответа.

Например:Content-Length: 2333
Сообщите клиенту, что длина данных этого ответа составляет 2333 байта, а следующие байты не относятся к этому ответу.

В использованииContent-LengthПредпосылкой является знание всей длины данных. Следовательно, когда блок данных сгенерирован, он не может быть передан клиенту немедленно, и его нельзя отправить до тех пор, пока не будут сгенерированы все данные. Время ожидания между ними обязательно повлияет на производительность. Чтобы устранить этот недостаток, в версии 1.1 было предложено решение «кодирование передачи блоков», в заголовке ответа будет поле Transfer-Encoding, которое сообщает клиенту, что этот ответ состоит из неопределенного количества блоков данных. , и каждый непустой блок данных имеет шестнадцатеричное значение, обозначающее их длину. Наконец, блок данных длиной 0 используется для указания того, что данные этого ответа были отправлены.

Добавьте код состояния 100

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

HTTP-протокол 2.0

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

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

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

Мультиплексирование позволяет одновременно отправлять несколько сообщений типа «запрос-ответ» по одному TCP-соединению. В протоколе HTTP/1.1 клиент имеет определенное количество запросов на одно и то же доменное имя одновременно. Запросы, превышающие лимит, будут заблокированы. В ответ на эту ситуацию в версии 2.0 принят механизм мультиплексирования, и несколько сообщений запрос-ответ могут быть инициированы через одно соединение HTTP/2, поэтому нет необходимости полагаться на несколько соединений TCP.

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

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

Пуш сервера

В версиях до 2.0 сервер был пассивной стороной, и сервер мог отправлять ресурсы только тогда, когда клиент отправлял запрос. В протоколе 2.0 сервер может активно отправлять ресурсы клиенту. Например, когда клиент запрашивает html, необходимые в нем js и css не требуют, чтобы клиент анализировал html, а затем запрашивал это содержимое.Сервер может отправить его вместе, когда клиент запрашивает html.

Использование файлов cookie для управления состоянием

HTTP — это протокол без сохранения состояния, то есть он не управляет состоянием предыдущих запросов и ответов. Другими словами, этот запрос не может быть обработан на основе предыдущего состояния. Например, если мы посещаем веб-страницу, требующую подтверждения входа, если мы не управляем ее статусом входа после входа в систему, нам нужно снова входить в систему каждый раз, когда мы запрашиваем новую страницу. Это плохой опыт. Чтобы решить эту проблему, была введена технология Cookie.

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

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

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

//写入Cookie
function setCookie(cname, cvalue, exdays) {  
    var d = new Date();  
    d.setTime(d.getTime() + (exdays*24*60*60*1000));  
    var expires = "expires="+d.toUTCString();  
    document.cookie = cname + "=" + cvalue + "; " + expires;  
}  
//读取Cookie
function getCookie(cname) {  
    var name = cname + "=";  
    var ca = document.cookie.split(';');  
    for(var i=0; i<ca.length; i++) {  
        var c = ca[i];  
        while (c.charAt(0)==' ') c = c.substring(1);  
        if (c.indexOf(name) != -1) return c.substring(name.length, c.length);  
    }  
    return "";  
}
//清除cookie    
function clearCookie(name) {    
    setCookie(name, "", -1);    
}     

HTTP-информация в HTTP-пакетах

Структура HTTP-сообщения

Информация, используемая для взаимодействия по протоколу HTTP, называется HTTP-сообщением. HTTP-сообщение на запрашивающей стороне (клиентской стороне) называется сообщением запроса, а на отвечающей стороне (серверной стороне) — ответным сообщением. Само HTTP-сообщение представляет собой строковый текст, состоящий из нескольких строк (с CR+LF в качестве новой строки) данных. Сообщения HTTP можно условно разделить на две части: строка запроса/строка ответа, заголовок сообщения и тело сообщения. Они разделены изначально появившейся пустой строкой (CR+LF). Что касается заголовка сообщения, это то, что нам нужно освоить.У нас будет больше места для объяснения позже в статье, которая рассматривается здесь.

Строка запроса сообщения запроса в основном состоит из трех частей: метод запроса, адрес URI и номер версии протокола HTTP.

Например:

POST https://segmentfault.com/api/article/draft/save HTTP/1.1

Строка ответа ответного сообщения в основном состоит из трех частей: номер версии протокола HTTP, код состояния HTTP и описание состояния.

Например:

HTTP/1.1 200 OK

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

Кодирование контента для передачи со сжатием

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

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

Часто используемые форматы кодирования контента:

• gzip
• compress
• deflate
• identity

Кодирование групповой передачи для разделенной отправки

Мы говорили об этом, когда в этой статье представляли версию 1.1 протокола http. Вы можете снова объединить следующую картинку, чтобы понять весь процесс.

Коллекция составных объектов, которые отправляют различные данные

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

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

Коллекция составных объектов содержит следующие объекты:

• multipart/form-data

  Используется при загрузке файлов из веб-форм

• multipart/byterangesКод состояния 206 используется, когда ответное сообщение содержит несколько диапазонов содержимого. Например:

content-type:multipart/form-data; boundary=WebKitFormBoundary5V53Jp7BUFBGzu9B

// 注：boundary指定划分多部分对象集合的起止符

--WebKitFormBoundary5V53Jp7BUFBGzu9B
Content-Disposition: form-data; name="image"; filename="表二：价值观评分表.numbers"
Content-Type: application/x-iwork-keynote-sffnumbers


--WebKitFormBoundary5V53Jp7BUFBGzu9B--


//开始的标记：--WebKitFormBoundary5V53Jp7BUFBGzu9B 
//结束的标记：--WebKitFormBoundary5V53Jp7BUFBGzu9B-- 

Запрос диапазона для получения частичного контента

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

При выполнении запроса диапазона первое поле Range используется для указания диапазона байтов ресурса.

1.Range:bytes=5001-10000          5001~10000字节
2.Range:bytes=5001-               从5001字节之后全部的内容
3.Range:bytes=-3000,5000-7000     从0~3000字节和5000~7000字节的多重范围

Для этого запроса диапазона мы сказали выше, что ответ вернет код состояния 206. Когда запрос диапазона делается для нескольких диапазонов, ответ будет использовать поле заголовкаContent-Type:multipart/byteranges.

Согласование контента возвращает наиболее подходящий контент

На волне глобализации родилось большое количество международных компаний, таких как всемирно известный видео-сайт YOUTUBE, на который каждый день заходят пользователи сети со всего мира. Таким образом, возникает проблема.В разных странах разные языки.Невозможно, чтобы YOUTUBE был одинаковым для всех и использовал английский язык.Тогда это не соответствует имиджу такой известной международной компании. Таким образом, для YOUTUBE это невозможно, но как сделать так, чтобы пользователи сети в разных странах могли переписываться с веб-сайтами на разных языках? Чтобы решить эту проблему, появился механизм согласования контента. Если язык, установленный браузером, который мы используем, — упрощенный китайский, то когда мы посещаем YOUTUBE, веб-страница, отображаемая для нас, — упрощенный китайский и так далее.

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

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

• Accept
• Accept-Charset
• Accept-Encoding
• Accept-Language
• Content-Language

Существует три типа методов согласования контента:

• управляемое сервером согласование(Способ согласования контента сервером)
• переговоры с участием клиента(способ согласования контента выполняется клиентом)
• прозрачные переговоры(Метод согласования контента на стороне сервера и на стороне клиента соответственно)

Код состояния HTTP возвращаемого результата

Код состояния отвечает за описание возвращаемого результата запроса, когда клиент отправляет запрос на сервер. С помощью кода состояния пользователь может узнать, был ли запрос нормально обработан на стороне сервера или произошла ошибка. Здесь мы перечисляем общие коды состояния HTTP, другие, кто заинтересован, могут проверить их. Здесь мы прикрепляем адрес полного кода состояния HTTP: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status

1XX

100 Продолжить (продолжить)

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

101 протокол переключения

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

2XX

200 ОК (успех)

Указывает, что запрос, отправленный от клиента, нормально обрабатывается на стороне сервера.

204 Нет контента

Сервер успешно обработал запрос, но возвращенное ответное сообщение не содержит содержимого сущности. Например, на странице есть тег a, а его атрибут href имеет значение http-204.html. При нажатии на тег a в обычных условиях будет выполнен переход на http-204.html. Однако, если код ответа http-204.html равен 204, страница не переходит и остается на текущей странице.

206 Частичный контент (некоторый контент)

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

3XX

301 Перемещено навсегда

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

302 Найдено (временное перенаправление)

Этот код состояния указывает, что запрошенному ресурсу временно назначен новый URI. Поскольку такие перенаправления являются временными, клиент ДОЛЖЕН продолжать отправлять будущие запросы на исходный адрес. Точно так же новый URI, назначенный на этот раз, также отмечается в поле заголовка местоположения ответного сообщения.

303 См. Другое

Этот код состояния указывает, что ответ на текущий запрос можно найти по другому URI, и клиент должен использовать GET для доступа к этому ресурсу. Здесь следует отметить, что 303 четко указывает, что его необходимо получить с помощью метода GET. Как и выше, новый URI, назначенный на этот раз, также отмечается в поле заголовка местоположения ответного сообщения.

304 Не изменено

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

307 Временное перенаправление

Значение 302 Found такое же. Почему появляется 307? Готовность заключается в том, что хотя стандарт 303 запрещает превращать POST в GET, реальная ситуация часто имеет место, и 307 будет строго соблюдать стандарт и не превратит POST в GET. Было бы полезно в перенаправлениях POST.

4XX

ошибка 400, неверный запрос

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

401 Неавторизованный

Этот код состояния указывает, что текущий запрос требует аутентификации пользователя. Ответ ДОЛЖЕН содержать заголовок WWW-Authenticate, соответствующий запрошенному ресурсу, чтобы запросить информацию у пользователя.

403 Запрещено

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

404 Не Найдено

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

405 Метод не разрешен

Этот код состояния указывает, что метод запроса, указанный в строке запроса, не может использоваться для запроса соответствующего ресурса. Ответное сообщение ДОЛЖНО возвращать заголовок Allow, указывающий список методов запроса, которые может принять текущий ресурс.

5XX

внутренняя ошибка сервера 500

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

503 Служба Недоступна

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

HTTP-заголовок

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

В первую очередь нам необходимо определить состав заголовка сообщения.Заголовок сообщения может быть заголовком запроса (request header) и заголовком ответа (response header). Среди них заголовок запроса может быть разделен на поля заголовка запроса, поля общего заголовка, поля заголовка объекта и другие расширенные поля заголовка, а заголовок ответа может быть разделен на поля заголовка ответа, поля общего заголовка, поля заголовка объекта и другие поля. расширенные поля заголовка. Из вышеизложенного мы можем получить:

Заголовок сообщения = поле заголовка запроса/поле заголовка ответа + общее поле заголовка + поле заголовка объекта + другие поля заголовка расширения

Далее мы начнем с четырех частей: поля заголовка запроса, поля заголовка ответа, общего поля заголовка и поля заголовка объекта.Поскольку полей слишком много, мы выбираем для объяснения только наиболее распространенные поля заголовка. Полную версию HTTP-заголовка можете посмотреть сами, а адрес прилагается: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers ##Поля заголовка запроса

Accept

Это поле используется для указания того, какие типы информации принимает клиент.

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8

в предыдущем примереq=Чтобы дополнительно представить значение веса, используйте (;) разделять. Диапазон значений q составляет 0~1 (с точностью до 3 знаков после запятой), а 1 является максимальным значением. Если значение веса q не указано, вес по умолчанию равен q=1,0. Кроме того, вы можете использовать (*) в качестве подстановочного знака для указания любого типа информации.

Accept-Charset

Это поле используется для указания набора символов, принимаемого клиентом.

Accept-Charset:iso-8859-15,unicode-1-1;q=0.8

q здесь согласуется с эффектом q Accept и не будет здесь повторяться. Подстановочные знаки (*) также согласованы.

Accept-Encoding

Используется для указания кодировки содержимого, приемлемой для клиента.

Accept-encoding:gzip, deflate;q=0.9, br

Здесь q также может использоваться для представления его приоритета, который совпадает с Accept. Кроме того, подстановочные знаки (*) также непротиворечивы.

Accept-Language

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

Accept-Language:zh-CN,zh;q=0.9,en;q=0.8

Значение веса q такое же, как и у Accept, и подстановочный знак (*) такой же.

Authorization

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

Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

Expect

Используется для указания желаемого условия и указания серверу корректно обрабатывать запрос только в том случае, если желаемое условие выполнено. HTTP/1.1 указывает только одно условие ожидания, а именно:

Expect: 100-continue

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

From

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

From: webmaster@example.org

Host

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

Host: developer.cdn.mozilla.net

If-Match

Все поля заголовка запроса в форме If-xxx являются условными запросами. После того, как сервер получит условный запрос, он выполнит запрос только в том случае, если посчитает, что указанное условие истинно.

Если-Match, он укажет серверу сопоставить значение ETag, используемое ресурсом.Сервер сравнит значение поля If-Match со значением ETag ресурса.Только когда они совпадают, запрос будет казнен. При сравнении ETag используется сильный алгоритм сравнения, то есть два файла могут считаться одинаковыми только в том случае, если каждый байт является одинаковым. Префикс ETag с W/ указывает на то, что можно использовать относительно свободный алгоритм.

If-None-Match — полная противоположность If-Match.

If-Match

If-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d"
If-Match: W/"67ab43", "54ed21", "7892dd"
If-Match: *

If-None-Match

If-None-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d"
If-None-Match: W/"67ab43", "54ed21", "7892dd"
If-None-Match: *

If-Modified-Since/If-Unmodified-Since

If-Modified-Since сервер вернет ресурс с кодом состояния 200 только в том случае, если содержимое запрошенного ресурса было изменено после даты и времени, указанных If-Modified-Since. Если не изменено, верните ответ 304 без тела сообщения, но со временем последнего изменения в заголовке Last-Modified.

If-Unmodified-Since, противоположный If-Modified-Since

If-Modified-Since

If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT

If-Unmodified-Since

If-Unmodified-Since: Wed, 21 Oct 2015 07:28:00 GMT

If-Range

Это поле используется в сочетании с полем Range.Когда условия в значении поля If-Range удовлетворяются, поле заголовка Range вступает в силу.В то же время сервер отвечает кодом состояния 206 (частичное содержимое) и возвращает содержимое, указанное в поле Range. В противном случае, если он не удовлетворен, сервер вернет код состояния 200 и вернет полный запрошенный ресурс.

If-Range: Wed, 21 Oct 2015 07:28:00 GMT

Max-Forwards

Когда мы говорили о методе TRACE ранее, мы говорили о поле Max-Forwards. При общении по протоколу HTTP запросы могут проходить через несколько прокси-серверов. По пути, если прокси-сервер по какой-то причине не может переслать запрос, мы не знаем, какой прокси-сервер вышел из строя посередине. После того, как поле Max-Forwards установлено, Max-Forwards будет уменьшаться на 1 при каждом прохождении через прокси-сервер.По достижении 0 переадресация не будет выполняться, но ответ будет возвращен напрямую. Таким образом, мы можем легко выяснить, какой прокси-сервер является проблемой.

Proxy-Authorization

Функция этого поля такая же, как и у Авторизации, разница между ними в том, что Прокси-Авторизация используется для аутентификации между клиентом и прокси-сервером, а Авторизация используется для аутентификации между клиентом и сервером.

Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

Range

Это поле используется для запросов диапазона, которые получают только некоторые ресурсы, а поле Range указывает его диапазон. Код состояния 206 (частично) возвращается при успешной обработке запроса диапазона. Если указанный диапазон выходит за пределы, возвращается код состояния 416 Range Not Satisfiable. Если область действительна, но не обработана успешно, будет возвращен код состояния 200, и все ресурсы получат ответ.

Range: bytes=200-1000, 2000-6576, 19000-

Referer

Адрес исходной страницы текущей запрошенной страницы означает, что доступ к текущей странице осуществляется по ссылке на этой исходной странице.

Referer: https://developer.mozilla.org/en-US/docs/Web/JavaScript

TE

Это поле используется для указания серверу кодировки передачи и относительного приоритета, при котором клиент может обработать ответ. Не путайте здесь с Accept-Encoding, TE предназначен для кодирования передачи, а Accept-Encoding — для кодирования содержимого.

TE: trailers, deflate;q=0.5

User-Agent

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

User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36
Name

поля заголовка ответа

Accept-Ranges

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

Accept-Ranges: bytes   //范围请求单位为bytes
Accept-Ranges: none    //不支持范围请求

Age

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

Age:600

ETag

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

Etag:"33a64df551425fcc55e4d42a148795d9f25f89d4"  //无论实体发生多么细微的变化都会改变其值。

ETag: W/"0815"  //只有资源发生了根本改变，产生差异时才改变ETag值。字段值最开始处附加W/

Location

Указывает адрес, на который необходимо перенаправить страницу, обычно имеет смысл только в ответах с кодом ответа 3xx.

Location:http//www.haimaiche.com/index.html

Retry-After

Сообщает клиенту, как скоро запрос должен быть отправлен снова. В основном используется с ответами 503 Service Unreachable или 3XX Redirect. Значением может быть конкретная дата и время или количество секунд, прошедших с момента создания ответа.

Retry-After: Wed, 21 Oct 2015 07:28:00 GMT
Retry-After: 120

Server

Содержит информацию о программном обеспечении, используемом сервером.

Server: Apache/2.4.1 (Unix)

Vary

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

Vary:Accept-Language

аннотация:Когда прокси-сервер получает запрос с полем заголовка Vary, указывающим ресурс, если значение используемого поля Accept-Language такое же, он возвращает ответ непосредственно из кэша. Напротив, вам необходимо получить ресурс с исходного сервера, прежде чем возвращать его в качестве ответа.

WWW-Authenticate

Определяет, какой метод проверки подлинности используется для подключения к ресурсу.

WWW-Authenticate: Basic realm="Access to the staging site"

Общие поля заголовка

Cache-Control

Задает директиву, управляющую поведением кэша. Команды можно выбирать несколько раз, разделяя их знаком «,» посередине.

Cache-Control: no-cache, no-store, must-revalidate

команда запроса кэша

инструкция	параметр	иллюстрировать
no-cache	без	Принудительная повторная аутентификация на исходном сервере
no-store	без	Не кэширует содержимое запроса или ответа
no-transform	без	Прокси не может изменить тип носителя
only-if-cached	без	Получить ресурс из кеша
max-age=	требуется	Максимальное значение возраста ответа
max-stale[=]	можно опустить	Принимать просроченные ответы
min-fresh=	требуется	Ожидайте, что ответ в течение указанного времени все еще будет действительным

директива ответа кеша

инструкция	параметр	иллюстрировать
no-cache	без	Валидность должна быть подтверждена перед кэшированием
no-store	без	Не кэширует содержимое запроса или ответа
no-transform	без	Прокси не может изменить тип носителя
public	без	Кэш, который может обслуживать ответы любой стороне
private	без	Возвращать ответы только определенным пользователям
must-revalidate	без	Можно кэшировать, но необходимо подтвердить с исходным сервером
proxy-revalidate	без	Промежуточный кеш-сервер требуется для повторного подтверждения достоверности кэшированного ответа.
max-age=	требуется	Максимальное значение возраста ответа
s-maxage=	требуется	Максимальное значение возраста для ответов сервера общедоступного кэша

Connection

Определяет, будет ли закрыто сетевое соединение после завершения текущей транзакции. После протокола Http 1.1 по умолчанию используется поддержка активности (постоянное соединение), а 1.0 — закрытие (непостоянное соединение).

Connection: keep-alive
Connection: close

Date

Указывает дату и время создания HTTP-сообщения.

Date: Wed, 21 Oct 2015 07:28:00 GMT

Pragma

Для обратной совместимости с кэш-серверами, поддерживающими только протокол HTTP/1.0.

Pragma: no-cache   //唯一形式

Trailer

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

HTTP/1.1 200 OK 
Content-Type: text/plain
... 
Transfer-Encoding: chunked
Trailer: Expires
...(报文主体)...
0
Expires: Wed, 21 Oct 2015 07:28:00 GMT

В приведенном выше примере использования значение указанного поля заголовка Trailer равно Expires, а поле заголовка Expires появляется после тела сообщения (после нулевой длины блока).

Transfer-Encoding

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

Transfer-Encoding: chunked

Via

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

Via: 1.0 fred, 1.1 p.example.net

Warning

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

Warning: <警告码> <警告的主机:端口号> <警告为别把> [<日期时间（可选）>]
Warning: 112 gw.hacker.jp:8080  "cache down" " Wed, 21 Oct 2015 07:28:00 GMT"

Таблица кодов предупреждений

код предупреждения	Содержание предупреждения	иллюстрировать
110	Response is Stale	Срок действия ответа, предоставленного кэш-сервером, истек (установленное время истечения срока действия истекло).
111	Revalidation Failed	Проверка ответа не удалась, так как сервер недоступен.
112	Disconnected Operation	Кэш-сервер отключен.
113	Heuristic Expiration	Если сервер кеша использует эвристику, установите срок действия кеша на 24 часа и отправьте ответ, когда он старше 24 часов.
199	Miscellaneous Warning	Произвольное предупреждающее сообщение.
214	Transformation Applied	Добавляется прокси-сервером, если он выполняет какие-либо преобразования в возвращенной презентации, такие как изменение кодировки контента, типа мультимедиа и т. д.
299	Miscellaneous Warning	Проверка ответа не удалась, так как сервер недоступен.

поле заголовка сущности

Allow

Сообщите клиенту, какие методы HTTP поддерживает ресурс.

Allow: GET, POST, HEAD

Content-Encoding

Кодирование содержимого для информирования части тела сущности клиент-сервер о выбранной части.

Content-Encoding: gzip

Content-Language

Сообщите клиенту о естественном языке, используемом телом сущности.

Content-Language: zh-CN

Content-Length

Указывает размер основного тела объекта в байтах.

Content-Length:15000

Content-Location

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

Content-Location:http://www.hacker.jp/index.html

Content-Range

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

Content-Range: bytes 200-1000/67589

Content-Type

Указывает тип носителя объекта в теле объекта.

Content-Type: text/html; charset=utf-8

Expires

Сообщите клиенту дату истечения срока действия ресурса. После того, как кэш-сервер получит ответ с полем заголовка Expires, копия ответа будет храниться до времени, указанного в Expires. Вместо этого кеш-сервер будет запрашивать ресурс у исходного сервера. Expires будет игнорироваться, если Cache-Control указывает директиву max-age или s-maxage.

Expires: Thu, 01 Dec 1994 16:00:00 GMT

Last-Modified

Указывает окончательное время модификации ресурса.

Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT

Другие поля заголовка расширения

Set-Cookie

Используется для отправки файлов cookie с сервера клиенту.

Set-Cookie: id=a3fWa;Domain=somecompany.co.uk; Path=/ Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

• Домен:Указывает имя хоста, на который могут быть отправлены файлы cookie.
• Дорожка:Ограничьте путь, по которому могут быть отправлены файлы cookie
• Истекает:Укажите дату истечения срока действия файла cookie
• Максимальный возраст:Через сколько секунд истечет срок действия файла cookie
• Безопасный:Файлы cookie отправляются только для защищенной связи HTTPS.
• Только HTTP:заставить js не получать куки

Cookie

Содержит файл cookie, ранее предоставленный сервером через заголовок Set-Cookie и сохраненный на клиенте.

Cookie: PHPSESSID=298zf09hf012fh2; csrftoken=u32t4o3tb3gg43; _gat=1;

DNT

в заголовке HTTP-запроса. Полное название — «Не отслеживать». Указывает метод отказа от отслеживания с помощью целевой рекламы.

DNT:0;//同意目标站点追踪用户个人信息。
DNT:1;//不同意目标站点追踪用户个人信息。

X-Frame-Options

В основном находится в заголовке ответа HTTP и используется для управления отображением содержимого веб-сайта в теге Frame других веб-сайтов. Его основная цель — предотвратить атаки кликджекинга.

Имеются следующие три значения:

• DENY: указывает, что страницу нельзя отображать во фрейме, даже если она вложена в страницы с тем же доменным именем.
• SAMEORIGIN: Указывает, что страница может отображаться во фрейме страницы с тем же доменным именем.
• ALLOW-FROM uri: Указывает, что страница может отображаться во фрейме указанного источника.

X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN
X-Frame-Options: ALLOW-FROM http://caibaojian.com/

X-XSS-Protection

При обнаружении атаки с использованием межсайтовых сценариев (XSS) браузер перестанет загружать страницу. Для современных браузеров выбирается более сильная Content-Security-Policy. О политике безопасности контента см. в этой статье г-на Руана Ифэна «Введение в политику безопасности контента».

X-XSS-Protection: 0  //禁止XSS过滤。
X-XSS-Protection: 1  //启用XSS过滤（通常浏览器是默认的）。如果检测到跨站脚本攻击，浏览器将清除页面（删除不安全的部分）。
X-XSS-Protection: 1; mode=block //启用XSS过滤。 如果检测到攻击，浏览器将不会清除页面，而是阻止页面加载。
X-XSS-Protection: 1; report=<reporting-uri> //启用XSS过滤。 如果检测到跨站脚本攻击，浏览器将清除页面并使用CSP report-uri指令的功能发送违规报告。

Подтвердите веб-безопасный HTTPS

Когда дело доходит до HTTPS, я думаю, что все знакомы с ним.Что такое HTTPS?Проще говоря, это безопасная версия HTTP, которая добавляет контроль безопасности на уровне HTTP. Каковы проблемы безопасности HTTP? Как HTTPS обеспечивает безопасность?

Недостатки HTTP

Связь с использованием открытого текста может быть перехвачена

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

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

Неспособность проверить личность связей стороны может привести к подделю

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

Не удалось подтвердить целостность сообщения, возможно, оно было изменено

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

Процесс HTTP-коммуникации

первый шаг:Клиент SSL / TLS отправляет некоторую версию протокола, поддерживаемую клиентом, включает в себя, вспомогательную поддержку шифрования (алгоритм шифрования и длина ключа) пакет к серверу.Шаг 2:Сервер выбирает одну из версий протокола SSL/TLS, поддерживаемых клиентом, и поддерживаемое им шифрование в качестве протокола SSL/TLS и компонентов шифрования, используемых в последующем процессе связи, и информирует об этом клиента в сообщении.третий шаг:Затем сервер отправит другой пакет, содержащий сертификат открытого ключа. Закрытый ключ в паре с открытым ключом остается на самом сервере.четвертый шаг:После того, как клиент получит сертификат открытого ключа, он подтвердит его легитимность агентству, выдавшему цифровой сертификат. Если это допустимо, ключ будет сгенерирован случайным образом в соответствии с компонентом шифрования, согласованным с сервером, и этот ключ будет использоваться для шифрования последующих пакетов. Сгенерированный ключ шифруется открытым ключом, предоставленным сервером, и отправляется на сервер.пятый шаг:После того, как сервер получит зашифрованный ключ от клиента, он расшифрует его с помощью закрытого ключа, который был оставлен в клиенте для получения ключа.пятый шаг:Этот ключ используется для шифрования сообщений между клиентом и сервером.

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

1.Согласование компонентов шифрования 2.Определить ключи шифрования и дешифрования 3.Клиент и сервер начинают обмен сообщениями

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

HTTP-аутентификация + + + зашифрованная защита целостности = https

Во-первых, мы выясним, что новое согласие между HTTPS не является уровнем приложений. Просто часть интерфейса связи HTTP заменяется протоколом SSL или TLS. Оригинальный протокол HTTP непосредственно подключен к протоколу TCP, и HTTPS является HTTP для связи с SSL / TLS и связываться с SSL / TLS и TCP.

шифрование

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

Упомянутый выше асимметричный алгоритм кажется хорошей штукой: для пакетов, передаваемых между сервером и клиентом, недостаточно использовать алгоритм асимметричного шифрования. Причина, по которой HTTPS спроектирован таким образом, заключается в том, что алгоритм асимметричного шифрования выглядит красиво, но его накладные расходы на процессор и память слишком велики. Некоторые люди проводили эксперименты: при одинаковом количестве файлов при шифровании и дешифровании накладные расходы асимметричного алгоритма более чем в 1000 раз превышают затраты симметричного алгоритма. Видно, что этот асимметричный алгоритм имеет многоударную производительность. Проблема производительности, даже если ее можно допустить, фатальным недостатком асимметричных алгоритмов является то, что длина зашифрованного содержимого не может превышать длину открытого ключа.Длина обычно используемого открытого ключа составляет 2048 бит, что составляет 256 байт. , что означает, что зашифрованный пароль Размер файла не может превышать 256 байт. Это слишком жалко.Сейчас картинки в интернете всего несколько килобайт.Это действительно невыносимо. Если вы можете это вынести, то вы действительно диао и проигрываете.

Сертификация

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

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

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

защита целостности

Шифрования и аутентификации достаточно, чтобы гарантировать, что коммуникационные сообщения не будут видны другим, но наши сообщения могут быть перехвачены и подделаны другими. Например, полное сообщение выглядит так: «Я не хочу, чтобы ты была моей девушкой, я хочу, чтобы ты была моей женой». Это очень романтичное предложение. Если его уничтожить, будет передано только «Я не «Я не хочу, чтобы ты была моей». «Подруга», получатель еще не знает, что эта информация была подделана, тогда произойдет что-то большое, пара попрощается, и хороший брак будет разрушен таким образом. Ради мира во всем мире мы также защищаем целостность сообщений. HTTPS использует алгоритм MAC для обеспечения своей целостности. Отправитель отправляет сообщение со значением MAC, полученным из алгоритма MAC. После того, как получатель получит сообщение, он рассчитает значение MAC в соответствии с ключом и алгоритмом MAC и сравнит его с переданным значением MAC.

Недостатки HTTPS по сравнению с HTTP

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

медленный

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

Высокое потребление ресурсов, таких как ЦП и память

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

попросить денег

Для осуществления связи HTTPS необходим сертификат, который необходимо приобрести в агентстве по сертификации. Орган по сертификации не может предоставить его вам бесплатно, и естественно взимать плату. Первые два приемлемы для безопасности, лично я считаю, что это основная причина, по которой некоторые сайты не используют HTTPS, ведь разговоры о деньгах ранят чувства. Конечно, быть бедным не значит, что нет возможности выжить, всегда есть какие-то великие боги, которые молча спасают нашу группу бедных диаосов, ["Let's Encrypt, бесплатный и простой в использовании HTTPS-сертификат"][ 15]. Кроме того, я сделаю небольшую рекламу для других ["Разместите "Презервативы" на веб-сайте"][16], пожалуйста, запомните мое имя, меня зовут Лэй Фэн!

Аутентификация для подтверждения личности получающего доступ пользователя

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

БАЗОВАЯ сертификация

Процесс 1:Когда ресурс, к которому обращается клиент, требует BASIC-аутентификации, сервер возвращает 401 и добавляет поле заголовка WWW-Authenticate в заголовок ответа, который содержит метод аутентификации (BASIC) и область (сообщает клиенту, что ресурс, к которому осуществляется доступ, принадлежит к серверу во многих областях) В какой области клиента, если область не указана, вместо этого клиент обычно отображает отформатированное имя хоста.)Процесс 2:После того, как клиент получит код состояния 401, он соединит имя пользователя и пароль с двоеточием (:) в соответствии с методом аутентификации (BASIC), указанным WWW-Authenticate в заголовке ответа, затем в кодировке Base64 и, наконец, вставит его в заголовок запроса Поле Авторизация отправляется на сервер.

Возьмите каштан:

用户名：admin  密码：123456

admin:123456    =>  YWRtaW46MTIzNDU2

Authorization: BASIC  YWRtaW46MTIzNDU2

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

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

дайджест сертификация

Процесс 1:Когда ресурс, к которому обращается клиент, требует DIGEST-аутентификации, сервер возвращает 401, заголовок ответа более сложный, чем в базовом режиме, WWW-Authenticate: Digest realm="myTomcat",qop="auth",nonce="xxxxxxxxxxx" , непрозрачный = "хххххххх". Аутентификация qop указывает на метод аутентификации; nonce — случайная строка; значение, указанное непрозрачным сервером, клиент должен вернуть исходное значение.Процесс 2:Браузер открывает диалоговое окно для ввода пользователем имени пользователя и пароля.Браузер выполняет операцию MD5 для комбинации имени пользователя, пароля, значения nonce, метода HTTP-запроса и URI запрошенного ресурса и отправляет расчетная сводная информация на сервер. Заголовок запроса аналогичен следующему: Авторизация: Digest username="xxxxx",realm="myTomcat",qop="auth",nonce="xxxxx",uri="xxxx",cnonce="xxxxxx",nc= 00000001, ответ ="xxxxxxxxx", непрозрачный ="xxxxxxxxx". Где username — это имя пользователя, cnonce — это случайная строка, сгенерированная клиентом, nc — количество раз, которое нужно выполнить аутентификацию, а response — итоговая вычисленная сводка. **Процесс 3:** Веб-контейнер на стороне сервера получает информацию об аутентификации, связанную с заголовком HTTP-сообщения, получает из него имя пользователя и получает соответствующий пароль в соответствии с именем пользователя. Аналогично, для имени пользователя, пароля, одноразового значения , метод HTTP-запроса и запрошенный ресурс URI и другие комбинации используются для операции MD5, а результаты вычислений сравниваются с ответом.Если они согласуются, аутентификация проходит успешно и возвращаются соответствующие ресурсы.

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

SSL-аутентификация клиента

Когда мы упоминали HTTPS ранее, сервер — это сторона, которая отправляет сертификат, а клиент — это сторона, которая принимает сертификат для проверки сертификата. Здесь их роли меняются местами, и генератор ключа вызова находится на стороне сервера, а не на стороне клиента. Обычно не используется отдельно, а используется в сочетании с проверкой формы. Проверка подлинности клиента SSL используется для проверки подлинности клиентского компьютера, а проверка подлинности с помощью форм используется для проверки подлинности человека, сидящего перед компьютером.

Проверка на основе формы

В настоящее время основные веб-сайты используют метод аутентификации с помощью формы. Его принцип очень прост.Клиент отправляет форму с логином и паролем в фон, а фон сгенерирует конкретный SessionId и поместит его в поле заголовка ответа Set-Cookie.После того, как клиент его получит, он будет сохранен в локальном файле cookie. Последующие запросы принесут файл cookie, и сервер идентифицирует пользователя в соответствии с SessionId, хранящимся в файле cookie.

Суммировать

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