Взрыв! 4D текст побеждает HTTP, жду вас на ByteDance!

интервью
Взрыв! 4D текст побеждает HTTP, жду вас на ByteDance!

Эта статья будет делиться из следующих аспектов. К ним относятся история разработки HTTP, механизм прокси-сервера кэширования HTTP, часто используемые веб-атаки, идентификация трафика HTTP и HTTPS, рекомендации по инструментам для изучения сетевых протоколов, часто задаваемые вопросы на собеседованиях по HTTP и HTTPS и т. д. ps (если вам нужен pdf с каталогом, напишите мне)

提纲
контур

В 1989 году Тим Бернерс-Ли предложил в своей статье, что документы с гиперссылками можно создавать в Интернете, и сделал три замечания.

URI: универсальный идентификатор ресурса. Уникальный идентификатор для Интернета

HTML: гипертекстовый документ

HTTP: протокол передачи текста для передачи гипертекста

1 Где находится HTTP-приложение

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

HTTP应用场景
Сценарии HTTP-приложений

2 Что такое HTTP

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

超文本传输协议
Протокол передачи гипертекста

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

"Передача" требует общения в процессе передачи. Общение может быть общением один-к-одному или общением один-ко-многим (согласование контента). В любом случае количество людей, участвующих в общении, > 1, и мы постараюсь все сделать быстрее и лучше, чтобы выполнить соответствующие задания.

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

三方协议
Трехстороннее соглашение

3 разные версии HTTP

HTTP/0.9

В то время сетевые ресурсы были ограничены, а версия 0.9 была относительно простой, она была в текстовом формате и была настроена только на чтение, поэтому в то время для получения HTML-документов с сервера можно было использовать только метод «Получить». , и ответ будет закрыт. Как показано ниже

GET /Mysite.html

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

<HTML>
Hello world
</HTML>
HTTP/1.0

На данный момент процесс запроса HTTP/0.9 выглядит следующим образом.

  • HTTP прикладного уровня построен поверх TCP транспортного уровня и использует характеристики надежности TCP, первое трехстороннее рукопожатие для установления соединения.

  • Клиент запрашивает установку соединения (в настоящее время только GET)

  • Сервер отвечает на запрос, и данные возвращаются клиенту в виде потока символов ASCII.

  • Передача завершена, отключитесь.

HTTP 0.9
HTTP 0.9

HTTP1.0

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

  • Раньше был только метод Get, а теперь добавлены методы Post (добавить параметры) и Head

  • Добавьте номер версии протокола и добавьте тип обработки файла

  • Добавьте HTTP-заголовок, чтобы сделать HTTP-запросы более гибкими.

  • Увеличьте код состояния ответа, чтобы отметить причину ошибки.

  • Обеспечивает интернационализацию (разные языки) поддержку

Типичный процесс запроса

GET /image.html HTTP/1.0
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64)

200 OK
Date: Tue, 17 Nov 2020 09:15:31 GMT
Content-Type: text/html
<HTML> 
一个包含图片的页面
  <IMG SRC="/image.gif">
</HTML>

Процесс связи HTTP1.0

HTTP1.0
HTTP1.0

HTTP /1.1

1995 год был необычным: Netscape и Microsoft начали войну браузеров, и все хотели быть главными. В 1999 году был выпущен HTTP/1.1 и стал стандартом, который был записан в RFC, думая, что в будущем, будь то шлюз или приложение, пока вы хотите использовать HTTP, вы должны соблюдать этот стандарт. .

  • Продолжайте добавлять такие методы, как PUT

  • Разрешить постоянные подключения

По мере того, как файл становится больше, а информация, такая как изображения, становится все более и более сложной, если процесс установления соединения и отключения каждый раз, когда файл загружается и загружается, будет увеличивать много накладных расходов. По этой причине предлагаются постоянные соединения, то есть TCP-соединение может иметь несколько HTTP-запросов. Конечно, постоянные соединения необязательны.Если вы планируете закрытие, вам нужно только использовать Connection:close для закрытия. Длинное соединение показано на рисунке ниже.

长连接
Длинное соединение
  • Форсировать заголовок хоста

Мы знаем, что в системе электронной коммерции трафик часто увеличивается из-за рекламных акций, и чтобы уменьшить трафик, одним из методов является добавление кеша или добавление сервера. Если нагрузка на один сервер слишком велика, база данных может быть подбазой и подтаблицей. То же самое верно и для методов «разделяй и властвуй» в алгоритмах структур данных. Затем в HTTP по той же причине, если файл слишком большой, большой файл разбивается на маленькие блоки файлов и отправляется.

HTTP /2

С появлением HTTP/1.1 за последние несколько лет появилось большое количество отличных интернет-компаний.Развитие идет слишком быстро, но эти моменты в HTTP1.1 подверглись критике.

  • Причина 1 TCP идет с медленным стартом

Как следует из названия, «медленный старт» прогрессирует от 0 до 1. Автомобиль не взлетит сразу по нажатию кнопки, а медленно настроится на подходящую скорость. Разве это не мило? Почему это вызывает проблемы с производительностью. Мы знаем, что на странице есть статические данные, динамические страницы и множество небольших файлов, которые будут напрямую инициировать запросы во время процесса загрузки, что приведет к тому, что слишком много запросов будут проходить медленный процесс запуска и занимать слишком много времени.

  • Причина 2. Несколько TCP-соединений конкурируют за полосу пропускания.

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

  • Причина 3 Блокировка головки

Блокировка, в сетевом программировании, мы используем асинхронные методы и методы мультиплексирования (epoll), чтобы попытаться заставить процессор меньше ждать и выполнять больше работы. В HTTP 1.1, хотя все используют TCP-канал, первый запрос не завершается, а второй запрос блокируется ожиданием, что означает, что данные не могут быть отправлены и получены одновременно. Тогда веб-страница имеет много файлов данных, если вы можете отправлять запросы одновременно, чтобы на некоторые файлы данных можно было ответить и предварительно обработать, что значительно задействует пропускную способность и ресурсы процессора. На основе этих факторов появился HTTP2.

Как решить блокировку головы?

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

В это время количество пользователей * количество одновременных пользователей (верхний предел 6-8) имеет хороший эффект, но скорость интернета слишком высокая, вокзал такой большой, а окон так много , что мне делать, построить новую железнодорожную станцию ​​для обхода (в большинстве городов есть восточная станция и западная станция). Это называется «шардинг домена» и использует несколько доменных имен, указывающих на один и тот же сервер.

HTTP/3

HTTP/2 кажется идеальным, но Google Wheel не уверен.Когда другие люди изучают HTTP/2, они думают о QUIC. Что такого удивительного в QUIC?

QUIC — это протокол, разработанный Google, который основан на UDP и имеет те же характеристики надежности, что и TCP. Имеет двоичное кадрирование данных приложения, такое как HTTP/2. Есть две основные проблемы, которые он решает.

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

  2. Соединение сохраняется при переключении сетей. Wi-Fi и 3G/4G часто нужно переключать туда и обратно. Протокол на основе TCP изменит IP-адрес из-за переключения сети. Благодаря протоколу QUIC на основе UDP своевременное переключение также может восстановить предыдущее соединение с сервером.

4 Подробное объяснение сообщений HTTP

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

报文层次结构
иерархия сообщений
GET /article/12 HTTP/1.1
Host: www.xxx.cn
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.106 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Cookie: SESSION=so9nlsvenminor5abs65sh9dsa
HTTP/1.1 200 OK
Server: nginx
Date: Sun, 17 May 2020 17:04:29 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: blade-2.0.6-BETA
Content-Encoding: gzip

сообщение запроса

请求报文
сообщение запроса

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

Начальная строка: основная информация, описывающая запрос или ответ.

Набор полей заголовка: сообщение с описанием формата ключ-значение

Тело сообщения: Фактическая передача информации, такой как изображения. Попробуйте, как показано ниже

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

HTTP请求方法详解
Подробный метод HTTP-запроса

Расскажите о нескольких очень распространенных методах запроса

Получить: получить ресурсы с сервера. Можно запросить фотографии, видео и т.д.

HEAD: аналогично Get, но ресурс, запрошенный с сервера, не будет возвращать запрошенные данные объекта, будет возвращен только заголовок ответа.

POST/PUT: Соответствует GET, отправка данных на сервер

2 URI

Унифицированный идентификатор ресурса (Uniform Resource Identifier), строго говоря, не равен URL, он содержит URL и URN, но URL настолько известен, что URL="URL". Независимо от разработки, тестовой эксплуатации и обслуживания конфигурация неотделима от URI, поэтому хорошо освойте ее.

Основной целью IP на сетевом уровне является решение задач маршрутизации и адресации. Текущий IP-адрес разделен согласно «.», всего 2 в 32-й степени составляет около 4,2 миллиарда. Это удобнее для компьютеров, но человеку все равно нелегко запомнить.В это время появляется DNS.Он сопоставляет IP-адрес с нашим привычным «redis.org», а доменное имя делит по ., чем выше уровень слева направо. Высокий, с «доменом верхнего уровня» справа. Как показано ниже

域名体系
система доменных имен

Что ж, теперь TCP обеспечивает надежный (отсутствие потери данных) и байтовый поток (целостность данных), а также имеет доменные имена, которые нам удобно запоминать, но ресурсов Интернета тысячи, и мы не знаем, к чему обращаться ( картинки, тексты, видео и т.д.) куча), на этот раз появляется URI (Uniform Resource Identifier), как он выглядит?

URI格式
формат URI

Название протокола: протокол HTTP, в дополнение к ftp и другим протоколам. Сообщает, какой протокол использовать при доступе к ресурсу.

с разделителем: "://"

Имя хоста: отметьте хост в Интернете, который может быть IP-адресом или доменным именем.Если порт не указан, используется порт по умолчанию, например, 80 для HTTP и 443 для HTTPS.

Информация для аутентификации при входе: имя пользователя и пароль при входе на хост (не рекомендуется, сообщайте другим напрямую свою личную информацию)

Имя хоста: это может быть доменное имя или IP.Если номер порта не указан, это порт по умолчанию. Например, порт по умолчанию для HTTP — 80, а порт по умолчанию для HTTPS — 443.

Расположение ресурса: расположение ресурса на хосте с использованием «/» для разделения многоуровневых каталогов, здесь «/en/download.html». Обратите внимание, должно начинаться с «/»

Параметры: Начать с "?", что указывает на дополнительные требования к запросу. Обычно он существует в виде «ключ=значение», и если «ключ=значение» несколько, используйте «&» для подключения.

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

http://nginx.org/en/download.html

file:///E:/Demo/index/

Обратите внимание, что здесь три «///», потому что предшествующий «://» используется в качестве разделителя, а путь к ресурсу начинается с «/».

Поскольку существует так много правил, синтаксический анализ, который должен выполнять получатель, также должен соблюдать правила.Многие пользователи по всему миру используют HTTP, и язык, используемый в каждой стране и регионе, отличается.Чтобы единообразно обрабатывать Это, HTTP вводит кодировку URI.Сравнение методов Простой, преобразуйте все не-ASCII или специальные символы в шестнадцатеричные байтовые значения и добавьте «%» впереди. Например, пробелы преобразуются в «%20», а «Китай» кодируется как «%E4%B8%AD%E5%9B%BD%0A».

3 Тело запроса

ответное сообщение

响应报文
ответное сообщение

Строка состояния - статус ответа сервера

Номер версии: какая версия HTTP используется

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

Существует 5 типов кодов состояния.

1××:处于中间状态,还需后续操作
2××:成功收到报文并正确处理

"200 OK"

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

"204 No Content"

Значение этого очень похоже на «200», разница в том, что в заголовке ответа нет данных тела.

"206 Partial Content"

Это основа загрузки блока HTTP или возобновляемой загрузки.Появляется, когда клиент отправляет «запрос диапазона» для запроса некоторых данных ресурса.Это то же самое, что и 200. Сервер успешно обработал запрос, но данные в тело - это не ресурс, целое, а его часть. Код состояния 206 обычно сопровождается полем заголовка «Content-Range», которое указывает конкретный диапазон данных тела в ответном сообщении для подтверждения клиентом, например «Content-Range: bytes 0-99/5000», который означает, что на этот раз извлекаются первые 100 байтов из общего числа 5000 байтов.

3××:重定向到其他资源位置

"301 Moved Permanently"

«Постоянно перенаправлено», что означает, что локально запрошенный ресурс не существует и к нему снова обращаются с новым URI.

«302 найдено»

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

301 и 302 указывают URI, который необходимо перенаправить в поле Location. Самая большая разница между ними заключается в том, что одно является временным изменением, а другое — постоянным изменением. Например, иногда необходимо обновить все веб-сайты до HTTPS, и для этого постоянного изменения необходимо настроить постоянный «301». Иногда при обновлении системы ночью система временно недоступна.Можно настроить временный доступ "302" В это время оптимизация кеша не будет выполняться, а исходный адрес будет доступен на следующий день.

«304 не изменено»

Используется для управления кешем. Он используется для условных запросов, таких как If-Modified-Since, указывающих, что ресурс не был изменен, и может пониматься как «перенаправление в кэшированный файл» (т. е. «перенаправление кэша»).

4××:请求报文有误,服务器无法处理

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

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

«403 Запрещено»

Обратите внимание, что это означает, что сервер запрещает доступ к ресурсу. Такие причины, как деликатные слова, юридические запреты и т. д. Конечно, если у клиента есть четкое понимание, вы можете рассмотреть возможность объяснения причины отказа и возврата.

"404 Не Найдено"

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

"405 Method Not Allowed"

Есть несколько способов получения ресурсов, и мы можем ограничить определенные способы. Например, POST не разрешен, разрешен только GET;

"406 Not Acceptable"

Ресурс клиента не может соответствовать условиям, запрошенным клиентом, например запрашивать китайский язык, но только английский;

"408 Request Timeout"

Время запроса истекло, и сервер слишком долго ждал;

«409 Конфликт»:

Конфликт нескольких запросов, который можно понимать как состояние гонки, когда одновременно работают несколько потоков;

413 Слишком большой объект запроса:

Текст сообщения запроса слишком большой;

414 Request-URI Too Long: слишком большой URI в строке запроса;

429 Too Many Requests: клиент отправил слишком много запросов,
Обычно из-за политики лимита подключений сервера;

431 Поля заголовка запроса слишком велики: определенный символ в заголовке запроса
Сегмент или сумма слишком велики;

5××:服务器错误,服务器对请求出的时候发生内部错误。

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

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

"502 Неверный шлюз"

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

"503 Сервис недоступен"

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

503 - "временный" статус,

Пока занят, услуга будет доступна позже. Поле «Retry-After» в ответном сообщении указывает, через какое время после этого клиент может попытаться отправить запрос еще раз.

4 Тело запроса

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

Особенности поля заголовка

Имена полей не чувствительны к регистру, например, «Хост» также может быть записан как «хост», но первая буква написана заглавной для удобства чтения;

В имени поля не допускаются пробелы, можно использовать дефис "-", но нельзя использовать подчеркивание "_". Например, «имя теста» — допустимое имя поля, а «имя теста» «имя_теста» — неверное имя поля;

За именем поля должно следовать ":" без пробелов, и может быть несколько пробелов перед значением поля после ":";

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

Поле в принципе не может повторяться, если только семантика самого поля не допускает этого, например, Set-Cookie.

Тела HTTP часто делятся на эти категории

текст: гипертекстовый текст/html, обычный текстовый текст/обычный

аудио/видео: аудио- и видеоданные

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

изображение: файл изображения. изображение/png и т. д.

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

<1> gzip:

Формат данных, использующий алгоритм deflate для сжатия части данных по умолчанию и в настоящее время

<2> deflate:

deflate — это алгоритм сжатия, усовершенствование кодировки Хаффмана.

<3> br:

br сжимает данные с помощью варианта алгоритма LZ77, кодирования Хаффмана и моделирования текста второго порядка.По сравнению с другими алгоритмами сжатия он имеет более высокую эффективность компрессионного формования.

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

文件拆分
разделить файл

хорошо, "Transer-Encoding:chunked" используется в сообщении, чтобы указать, что основная часть данных передается порциями. Кроме того, в теле есть поле длины содержимого для указания длины тела. Эти два поля не могут сосуществовать. Кроме того, во многих случаях это потоковые данные, а длина содержимого не указывается в теле. время, это, как правило, передача по частям.

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

Каждый блок содержит блоки длины и данных.

Заголовок длины заканчивается на CRLF

Блок данных идет после длины, и последний CRLF заканчивается

Используйте длину 0 для обозначения конца, "0\r\n\r\n"

Мы все еще смотрим на картинку, чтобы углубить впечатление

chunked分块
нарезанный

Блокировка решает некоторые наши проблемы, но иногда мы хотим обрезать передачу. Использование поля «Принять — Диапазоны: байты» предусмотрено в HTTP для явного информирования клиента: «Я поддерживаю запросы диапазона». Итак, что такое диапазон Range?Диапазон начинается с 0. Например, Range: 0-5 читает первые 6 байт.Когда сервер получит этот запрос, как он ответит?

Проверка законности. Например, всего 20 байт, но диапазон запроса: 100-200. В это время он вернет 416 ---- "Ошибка запроса диапазона"

Если диапазон нормальный, возвращается 216, указывая на то, что запрашивается часть знаний о данных.

Серверная сторона добавляет Content-Range к соответствующей инвестиционной стороне в формате "байты x-y/длина".

Стук по доске: Как возобновить передачу с точки останова?

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

Несколько потоков отвечают за разные диапазоны

Одновременно записывайте ход загрузки, даже если она прервана из-за сетевых и других причин, это нормально, Range запрашивает оставшиеся

Теперь, когда мы знаем тип части тела по MIME-TYPE и Encoding-type, следующим шагом будет согласование содержимого. В HTTP Accept используется в теле запроса, чтобы сообщить серверу, какой тип данных ему нужен (какой тип данных я могу обработать), а Content используется в заголовке ответа, чтобы указать, какой тип данных отправляется, как показано на следующий рисунок

Ну и для ровного и дружеского общения и четкого разграничения разных стран и народов. Используйте «тип-подтип» в заголовке HTTP-запроса, обратите внимание, что в настоящее время разделителем является «-». Например, en-GB означает британский английский, а zh-CN означает обычный китайский.Для клиента он использует Accept-Language, чтобы отметить естественный язык, который он может понять, а соответствующий сервер использует Content-Language, чтобы указать использование сущности тип языка данных, как показано на следующем рисунке.

字符集和编码
Набор символов и кодировка

Механизм cookie

HTTP не имеет состояния и памяти. Появление механизма Cookie позволяет ему иметь функцию памяти. Как это реализовано?

Cookie
Cookie

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

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

HTTP-прокси

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

代理
играет роль

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

正向代理与反向代理
Прямой прокси и обратный прокси

Итак, возникает вопрос. Как скрытая личность, прокси-сервер эквивалентен сокрытию реального клиента и сервера. Верно ли это?

5 HTTPS

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

что такое безопасность

安全四要素
Четыре элемента безопасности

конфиденциальность

Держите информацию в тайне и доступной только для доверенных лиц (напоминает мне о тайм-менеджерах).

честность

Содержимое данных не "подделывается" во время передачи. Конфиденциальность хранит данные в секрете, но есть хорошие и плохие стратегии (хак)

Аутентификация

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

неоспоримый

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

HTTPS

HTTP和HTTPS
HTTP и HTTPS

Из приведенного выше рисунка мы знаем, что HTTPS — это не что иное, как добавление уровня TLS между транспортным уровнем и уровнем приложений, который идет в ногу с темпами современной криптографии и делает все возможное для обеспечения безопасности пользователей. Как обычно, воспользуемся wireshark, чтобы посмотреть, как это выглядит.

TLS
TLS

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

TLS组成
TLS-композиция

Протокол рукопожатия SSL:

Относительно трехстороннего рукопожатия

Соглашение о записи

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

Протокол оповещения

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

Изменить протокол спецификации шифра

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

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

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

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

对称加密
Симметричное шифрование

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

При симметричном шифровании отправитель и получатель используют один и тот же ключ. Затем при асимметричном шифровании отправитель и получатель используют разные ключи. Основная проблема, которую он решает, — предотвратить утечку информации в процессе согласования ключей. Например, при симметричном шифровании Xiaolan шифрует отправляемое сообщение, а затем сообщает вам, что пароль 123balala, хорошо.Другим легко украсть пароль, чтобы он был 123balala. Тогда в случае с асимметричным Xiaolan сообщает всем, что пароль 123balala, и для посредника его получить бесполезно, потому что закрытого ключа нет. Следовательно, асимметричные ключи на самом деле в основном решают проблему распределения ключей. Как показано ниже

非对称加密
Асимметричное шифрование

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

Гибридное шифрование

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

混合加密
Гибридное шифрование

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

Резюме

Алгоритм дайджеста можно понимать как специальный «односторонний» алгоритм шифрования, который не имеет ключа и необратим. В нормальных проектах все должны были использовать MD5 и SHA-1. Но SHA-2 используется в TLS.

Предположим, маленький A передает 5000 в маленький C, а маленький A добавляет дайджест SHA-2. Веб-сайт подсчитывает сводки и сравнивает их, если они непротиворечивы, значит, они полны и заслуживают доверия.

摘要可信
Абстрактные достоверные

В настоящее время Сяо Б хочет изменить деньги, предоставленные Сяо А. В настоящее время сводка расчетов на веб-сайте покажет, что они отличаются и ненадежны.

摘要不可信
Аннотация не вызывает доверия

HTTPS-запрос для установления процесса подключения

HTTP握手过程
Процесс рукопожатия HTTP

Уведомление:

  1. Сначала установите процесс связи с помощью асимметричного шифрования
  2. На этапе рукопожатия зачем использовать 3 случайных числа, с одной стороны, чтобы предотвратить угадывание "случайного числа C", с другой стороны, чтобы увеличить случайность сеансового ключа
  3. Проблемы клиента с поддерживаемыми алгоритмами «симметричного/асимметричного шифрования»
  4. Сервер возвращает выбранный алгоритм «симметричного/асимметричного шифрования».
  5. Клиент подтверждает алгоритм
  6. Сервер подтверждает алгоритм

Дальнейшее разделение TLS на основе результатов Wireshak. Трехстороннее рукопожатие TCP устанавливает соединение.В качестве любезности клиент сначала приветствует «Client Hello». Он содержит номер версии клиента, поддерживаемые наборы шифров и случайные числа, как показано на следующем рисунке.

Client Hello
Client Hello

Серверная сторона выражает уважение, отвечает "Server Hello" и одновременно выполняет проверку версии, выдает случайное число (Server Random) и выбирает набор шифров из списка клиентских алгоритмов, причем здесь выбрано "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256".

cipher Suite
cipher Suite

Что здесь означает «TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256»?

Выбор комплекта шифров Эллиптическая кривая плюс RSA, AES, SHA256

Обе стороны подтверждают свою личность с помощью сертификатов. Поскольку локальный сервер использует алгоритм ECDHE, для реализации алгоритма обмена ключами он отправит открытый ключ эллиптической кривой (параметры сервера) вместе с сообщением «Обмен ключами сервера» после отправки сертификата.

Server Key Exchange
Server Key Exchange

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

ServerHelloDone
ServerHelloDone

Затем сервер отвечает «привет, готово», чтобы сообщить, что приветствие завершено.

После приветствия клиент проверяет сертификат. Затем сгенерируйте открытый ключ эллиптической кривой в соответствии с набором шифров и отправьте его на сервер с сообщением «Обмен ключами клиента».

Client Key Exchange
Client Key Exchange

На этом этапе и у клиента, и у сервера есть два параметра для обмена ключами (Client Params, ServerParams), а затем вычисляется новое значение с помощью алгоритма ECDHE, называемого «Pre-Master».

С помощью главного ключа и сеансового ключа клиент отправляет сообщения «Change Cipher Spec» и «Finished» и, наконец, отправляет все сообщения вместе с дайджестом на сервер для проверки.

Сервер также отправляет сообщения «Change Cipher Spec» и «Finished», рукопожатие завершается и начинаются HTTP-запрос и ответ.

4 Предварительное изучение доменных имен

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

Корневой DNS-сервер: управляет серверами доменных имен верхнего уровня и возвращает IP-адреса серверов доменных имен верхнего уровня, такие как «com», «net» и «cn»;

DNS-сервер верхнего уровня: управляйте полномочными серверами доменных имен под их соответствующими доменными именами, такими как
Сервер доменных имен верхнего уровня com может возвращать IP-адрес сервера доменных имен apple.com;

Авторитарный DNS-сервер: управляет IP-адресом узла под собственным доменным именем, например, полномочный DNS-сервер apple.com может возвращать IP-адрес www.apple.com**

6 Обзор функций HTTP

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

1: гибкий и простой в расширении, многие из его полей заголовка настраиваются и расширяются.

2: Широкое применение. Задействованы все поля. «Кроссплатформенный, кросс-языковый»

3: Без гражданства. Нет функции памяти, меньше функций означает меньшее потребление ресурсов. Кроме того, проще построить кластер без состояния и перенаправить запросы на любой сервер через балансировку нагрузки. Недостатком является то, что он не может поддерживать «транзакционные» операции, требующие последовательных шагов. Мы знаем, что протокол TCP имеет 11 состояний, и разные состояния представляют разные значения в процессе связи. Точно так же процессы в операционной системе также имеют различные состояния, такие как выполнение, готовность и активная блокировка. Но HTTP не имеет состояния на протяжении всего процесса. Например, Xiaohua запрашивает у сервера получение видео X, и сервер отправляет его Xiaohua, когда считает, что это возможно. Сяохуа все еще хочет получить видео Y. В это время сервер не будет записывать предыдущее состояние, поэтому неизвестно, совпадают ли два запроса, поэтому Сяохуа должен сообщить серверу свою личность.

4: Открытый текст. Преимущество заключается в том, что он позволяет разработчикам более интуитивно отлаживать с помощью инструмента wireshark. Недостаток в том, что в Интернете полосами нет приватности вообще.

5: Надежная передача. HTTP — это протокол прикладного уровня, основанный на TCP/IP, а TCP — «надежный» транспортный протокол, поэтому HTTP может «надежно» передавать данные в ответах на запросы.

6: Протокол прикладного уровня. Существует множество протоколов прикладного уровня, среди которых обычно используется почтовый протокол SMTP, загрузка и выгрузка файлов по ftp, порт по умолчанию 22/23, удаленный вход по SSH (XSHELL). Эти протоколы прикладного уровня слишком специфичны, и HTTP, благодаря сочетанию различных полей заголовков, данных сущностей, встроенного кэширующего прокси-сервера и других функций, можно назвать наследным принцем в сети.

7 HTTP-идентификация (восстановление)

Упомянутая здесь идентификация посредством уровня кода (инкапсуляция libpcap) для реализации идентификации HTTP также может дополнительно отражать многоуровневые характеристики стека протоколов TCP/IP. Давайте сначала посмотрим на память формата заголовка IP.

IP头部
IP-заголовок

Обратите внимание на поле протокола в заголовке, если значение этого поля равно 0x0600, это TCP-пакет. Зная, что это пакет TCP, можно ли определить его как HTTP через порт (80) в заголовке TCP?Нет, во многих случаях для развертывания используются динамические порты. На данный момент об этом можно судить по ключевым словам в HTTP. Если это HTTP, то подтвердите текстовую информацию и метод кодирования через «Content-type», charset и т. д. в поле заголовка и, наконец, используйте алгоритм декодирования для восстановления.

8 Распознавание HTTPS (зашифрованный текст)

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

  • Сбор набора данных

Используя библиотеку Python dpkt (просто pip install dpkt), библиотека dpkt удобна для дизассемблирования каждого уровня протокола, а также может выполнять разделение потока и извлечение признаков. Ниже приведен пример автоматического сбора трафика через безголовый просмотр (ps если вам нужен крупномасштабный сбор трафика, вы можете рассмотреть возможность использования кластера докеров).

Read_pcap
Read_pcap
  • Сгенерируйте npz на основе предложенных функций (фактически метод хранения массива, предоставляемый numpy)
  • Используйте библиотеку skearn с открытым исходным кодом для обучения модели и определения прогнозов, предполагая здесь SVM (используя только параметры по умолчанию)
SVM
SVM
  • Результаты распознавания (умеренная настройка параметров однозначно даст лучшие результаты)
识别结果
Результат распознавания

Тест 9 вопросов HTTP-интервью

Я надеюсь, что после прочтения этой статьи следующие интервью можно убить за секунды?

  • Разница между получением и публикацией

  • Разница между HTTP и HTTPS

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

  • Браузер вводит адрес. Какие шаги вы прошли для отображения страницы?

  • Разница между механизмом файлов cookie и механизмом сеанса:

  • Формат сообщения HTTP-запроса и ответного сообщения

  • 7 шагов полного HTTP-запроса

  • Схема оптимизации HTTP

  • Различия между разными версиями HTTP

  • Преимущества и недостатки HTTP

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

  • Как определить, является ли это http

  • Введение группового кодирования передачи в HTTP 1.1 дает следующие преимущества.

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

  • Распространенные веб-атаки

  • В чем разница между переадресацией на сайте и внешней переадресацией

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

  • Что вы знаете о Http 2.0?

  • Расскажите о принципе 304 кеша

  • Сходства и различия между HTTP и RPC

  • Из транспортного протокола

RPC может быть основан на протоколе TCP или HTTP, но HTTP обычно основан на HTTP.

  • С точки зрения потребления производительности

RPC может реализовать эффективную двоичную передачу на основе бережливости. HTTP в основном реализуется через json, что требует больше времени, чем t'hrift с точки зрения размера байта и сериализации.

  • С точки зрения балансировки нагрузки

RPC в основном поставляется со своей собственной стратегией балансировки нагрузки, в то время как HTTP необходимо настроить с реализацией Nginx.

болтовня

Первая статья может быть такой длинной, и я наконец понимаю, что вам не просто писать статьи. Не хотите быть "белыми проститутками". Пожалуйста, нажмите "Мне нравится" в конце статьи, и давайте " увидеть мир" вместе.

Persist

https://www.chainnews.com/articles/401950499827.htm
https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP