Основной процесс браузера предварительного контента
Браузер является многопроцессорным, в основном делится на:
- Основной процесс браузера: есть только один, который в основном управляет созданием страницы, удалением, управлением сетевыми ресурсами, загрузкой и т. д.
- Процесс стороннего подключаемого модуля: процесс для каждого типа подключаемого модуля, создаваемый только при использовании подключаемого модуля.
- Процесс GPU: максимум один, для 3D-рисования и т. д.
- Процесс рендеринга браузера (ядро браузера): каждая страница TAB соответствует процессу, который не влияет друг на друга.
Часть 1. Введите URL-адрес и проанализируйте его.
Здесь мы учитываем только то, что ввод является строкой структуры URL. Если это не строка структуры URL, для поиска строки будет использоваться поисковая система браузера по умолчанию.
Состав URL-адресов
URL-адреса в основном协议
,主机
,端口
,路径
,查询参数
,锚点
6 частей!
Разобрать URL
После ввода URL-адреса браузер проанализирует протокол, хост, порт, путь и другую информацию и создаст HTTP-запрос.
- Прежде чем браузер отправит запрос, в соответствии с заголовком запроса
expires
а такжеcache-control
Определите, сработала ли стратегия сильного кэширования (в том числе, истек ли срок ее действия).Если это сработает, ресурс будет получен непосредственно из кэша, и запрос не будет отправлен. Если нет попадания, переходите к следующему шагу. - Если сильное правило кеша не выполняется, браузер отправит запрос в соответствии с заголовком запроса.
If-Modified-Since
а такжеIf-None-Match
Определяет, произошло ли попадание в кэш согласования, и если да, то получает ресурс непосредственно из кэша. Если нет попадания, переходите к следующему шагу. - Если первые два шага не выполнены, ресурс берется напрямую с сервера.
HSTS
Из соображений безопасности HSTS используется, чтобы заставить клиентов использовать HTTPS для доступа к страницам. Видеть:Чего вы не знаете о HSTS. Когда все ваши веб-сайты используют HTTPS и соответствуют его спецификациям безопасности, вы можете подать заявку на добавление в список HSTS.После этого, если пользователи посещают ваш сайт без протокола HTTPS, браузеры будут перенаправлены на HTTPS. Независимо от того, есть ли совпадение, пришло время начать поиск DNS.
кеш браузера
Сильный кеш
Принудительное кэширование — это процесс поиска в кеше браузера результата запроса и принятия решения о том, использовать ли кешированный результат в соответствии с правилами кэширования результата. Strong cache делится на два типаExpires
а такжеCache-Control
Expires
- Версия: HTTP/1.0
- Источник: существует в заголовке ответа, возвращаемом сервером
- Синтаксис: Истекает: ср, 22 ноября 2019 г., 08:41:00 по Гринвичу.
- Недостаток: время сервера и время браузера могут не совпадать, что приводит к сбою.
Cache-Control
- Версия: HTTP/1.1
- Источник: заголовки ответов и заголовки запросов.
- Синтаксис: Cache-Control:max-age=3600
- Недостаток: время когда-нибудь закончится
Заголовок запроса:
Имя поля | иллюстрировать |
---|---|
no-cache | Скажите (прокси) серверу, чтобы он не использовал кеш напрямую, и попросите сделать запрос на исходный сервер. |
no-store | Ничего не сохраняется в кэше или во временных интернет-файлах |
max-age=delta-seconds | Сообщите серверу, что клиент хочет получить ресурс, который не старше дельта-секунд секунд. |
max-stale[=delta-seconds] | Сообщите (прокси) серверу, что клиент готов получить ресурс, превышающий время кеша. Если определено значение дельта-секунд, это будет дельта-секунды, если нет, это будет любое избыточное время. |
min-fresh=delta-seconds | Сообщите (прокси) серверу, что клиент желает получить ресурс, который был обновлен менее чем за дельта-секунды. |
no-transform | Сообщите (прокси) серверу, что клиент хочет получить ресурс, данные объекта которого не были преобразованы (например, сжаты). |
noly-if-cached | Сообщите (прокси) серверу, что клиент хочет получить кешированный контент (если есть) без отправки запроса на исходный сервер. |
cache-extension | Пользовательское значение расширения, если сервер не распознает это значение, оно будет проигнорировано. |
Заголовок ответа:
Имя поля | иллюстрировать |
---|---|
public | Указывает, что ресурс должен кэшироваться при любых обстоятельствах (даже если требуется HTTP-аутентификация). |
Private=[field-name] | Указывает, что все или часть возвращенного сообщения (если указано имя поля, данные поля имени поля) открыты только для некоторых пользователей (общий пользователь, указанный сервером, например, прокси-сервером) для кэширования, и другие пользователи не могут кэшировать эти данные |
no-cache | Не используйте кеш напрямую, требуя (проверки свежести) запроса на сервер |
no-store | Таким образом, ни один контент не сохраняется в кеше или во временных интернет-файлах. |
no-transform | Скажите клиенту не вносить никаких изменений в данные объекта при кэшировании файла. |
noly-if-cached | Сообщите (прокси) серверу, что клиент хочет получить кешированный контент (если есть) без отправки запроса на исходный сервер. |
must-revalidate | Текущий ресурс должен быть отправлен на сервер исходного метода для проверки запроса, если запрос да, он вернет 504 (не кеш на прокси-сервере). |
proxy-revalidate | Аналогично обязательной повторной проверке, но может использоваться только для общих кешей (например, прокси-серверов). |
max-age=delta-seconds | Сообщите клиенту, что ресурс свежий в течение дельта-секунд, не делая запрос на сервер. |
s-maxage=delta-seconds | То же, что и max-age, но применяется только к общим кешам (например, прокси) |
cache-extension | Пользовательское значение расширения, если сервер не распознает это значение, оно будет проигнорировано. |
Пример:
// server.js
const http = require('http')
const fs = require('fs')
http.createServer(function (request, response) {
console.log('request come', request.url)
if (request.url === '/') {
const html = fs.readFileSync('test.html', 'utf8')
response.writeHead(200, {
'Content-Type': 'text/html'
})
response.end(html)
}
if (request.url === '/script.js') {
response.writeHead(200, {
'Content-Type': 'text/javascript',
'Cache-Control': 'max-age=20,public' // 缓存20s 多个值用逗号分开
})
response.end('console.log("script loaded")')
}
}).listen(8888)
console.log('server listening on 8888')
// test.html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta http-equiv="X-UA-Compatible" content="ie=edge">
<title>Document</title>
</head>
<body>
</body>
<script src="/script.js"></script>
</html>
Согласовать кеш
Согласование кеша — это процесс, в котором браузер инициирует запрос с идентификатором кеша на сервер после принудительного отказа кеша, и сервер решает, использовать ли кеш в соответствии с идентификатором кеша.
MockLast-Modified
if (request.url === '/index.js') {
const filePath = path.join(__dirname, request.url); // 拼接当前脚本文件地址
const stat = fs.statSync(filePath); // 获取当前脚本状态
const mtime = stat.mtime.toGMTString() // 文件的最后修改时间
const requestMtime = request.headers['if-modified-since']; // 来自浏览器传递的值
console.log(stat);
console.log(mtime, requestMtime);
// 走协商缓存
if (mtime === requestMtime) {
response.statusCode = 304;
response.end();
return;
}
// 协商缓存失效,重新读取数据设置 Last-Modified 响应头
console.log('协商缓存 Last-Modified 失效');
response.writeHead(200, {
'Content-Type': 'text/javascript',
'Last-Modified': mtime,
});
const readStream = fs.createReadStream(filePath);
readStream.pipe(response);
}
Имитация ETag
if (request.url === '/index.js') {
const filePath = path.join(__dirname, request.url); // 拼接当前脚本文件地址
const buffer = fs.readFileSync(filePath); // 获取当前脚本状态
const fileMd5 = md5(buffer); // 文件的 md5 值
const noneMatch = request.headers['if-none-match']; // 来自浏览器端传递的值
if (noneMatch === fileMd5) {
response.statusCode = 304;
response.end();
return;
}
console.log('Etag 缓存失效');
response.writeHead(200, {
'Content-Type': 'text/javascript',
'Cache-Control': 'max-age=0',
'ETag': fileMd5,
});
const readStream = fs.createReadStream(filePath);
readStream.pipe(response);
}
Last-Modified (заголовок ответа), If-Modified-Since (заголовок запроса)
После того, как браузер отправит запрос на сервер в первый раз, сервер добавит это поле в заголовок ответа.
После того, как браузер получит его, если он запросит снова, он будет перенесен в заголовок запроса.If-Modified-Since
Поле, значение этого поля — время последней модификации, отправленное сервером.
Сервер получает заголовок запросаIf-Modified-Since
После поля оно фактически будет соответствовать времени последней модификации ресурса на этом сервере.Last-Modified
Напротив, спросите сервер, был ли ресурс обновлен после даты, и если есть обновление, новый ресурс будет отправлен обратно.
Но если вы откроете файл кеша локально, это вызоветLast-Modified
модифицируется, поэтому вHTTP / 1.1
ПоявилсяETag
.
ETag (заголовок ответа), If-None-Match (заголовок запроса)
ETag
Это уникальный идентификатор, генерируемый сервером для файла в соответствии с содержимым текущего файла.Поскольку содержимое в нем изменяется, это значение будет меняться. Сервер отправляет это значение в браузер через заголовок ответа.
Когда браузер получит значение ETag, он будет использовать это значение в качестве следующего запроса.If-None-Match
Содержимое этого поля помещается в заголовок запроса и отправляется на сервер.
Если поддерживаются оба метода, сервер отдаст приоритет ETag.
место хранения
- Service Worker
Service Worker
Это независимый поток, работающий за браузером, и обычно его можно использовать для реализации функции кэширования. использоватьService Worker
, транспортный протокол должен бытьHTTPS
. потому чтоService Worker
Это связано с перехватом запросов, поэтому его необходимо использоватьHTTPS
соглашение об обеспечении безопасности.Service Worker
Кэш отличается от других встроенных механизмов кеширования в браузерах, он позволяет нам свободно контролировать, какие файлы кешируются, как сопоставлять кеш, как читать кеш, и кеш является постоянным.
Service Worker
Реализация функции кеша обычно делится на три шага: во-первых, вам нужно зарегистрироватьсяService Worker
, то слушайтеinstall
После того, как событие вы сможете кэшировать необходимые файлы, это может быть существование кэша в следующий раз, когда пользователь запрашивает доступ путем перехвата запросов, кэшированных, то файлы кэша можно прочитать напрямую или запросить данные.
когдаService Worker
Когда кеш не попал, нам нужно вызватьfetch
функция для получения данных. То есть, если мы неService Worker
При попадании в кеш данные будут искаться в соответствии с приоритетом поиска в кеше. Но то ли мы изMemory Cache
получаем ли мы данные из сетевого запроса или из сетевого запроса, браузер покажет, что мы изService Worker
контент, полученный от .
- Memory Cache
Memory Cache
То есть кеш в памяти, в основном включал в себя ресурсы, которые были захвачены на текущей странице, такие как стиль, скрипты, изображения и т. Д., которые были загружены на странице. Данные чтения в памяти определенно быстрее, чем диск, хотя кэш памяти эффективен, но непрерывность кэша короткая, она будет выделена, поскольку процесс выпускается. Как только мы выключаем вкладку, кэш в памяти выпущен.
Итак, поскольку кеш памяти настолько эффективен, можем ли мы хранить все данные в памяти? Это невозможно. Память в компьютере должна быть намного меньше емкости жесткого диска.Операционная система должна тщательно рассчитывать использование памяти, поэтому памяти, которую мы можем использовать, должно быть немного.
Следует отметить, что memcache не заботится о заголовках кэша HTTP, возвращаемых для ресурса, когда он кэширует ресурс.
Cache-Control
Каково значение, и соответствие ресурсов не только совпадает с URL-адресом, но также можетContent-Type
, CORS и другие функции для проверки.
- Disk Cache
Disk Cache
То есть кеш хранится на жестком диске, скорость чтения медленнее, но все можно хранить на диске, по сравнению сMemory Cache
Выигрывает в емкости и своевременности хранения.
- Push Cache
Push Cache
(push-кеш) даHTTP/2
Содержимое кеша будет использоваться только в том случае, если ни один из трех вышеперечисленных кешей не попал. Он существует только в сеансе (Session) и освобождается после завершения сеанса, а время кэширования также очень короткое, всего около 5 минут в браузере Chrome, и он строго не реализует инструкции кэширования в заголовке HTTP.
- Все ресурсы могут быть отправлены и кэшированы, но
Edge
а такжеSafari
Поддержка браузера относительно плохая - можно толкнуть
no-cache
а такжеno-store
ресурс - Как только соединение закрыто,
Push Cache
был выпущен - Несколько страниц могут использовать один и тот же
HTTP/2
соединение, вы можете использовать тот жеPush Cache
. В основном это зависит от реализации браузера.По соображениям производительности некоторые браузеры используют одно и то же HTTP-соединение для одного и того же доменного имени, но с разными вкладками. -
Push Cache
Кэш можно использовать только один раз - Браузеры могут отказаться принимать push-уведомления ресурсов, которые уже существуют.
- Вы можете использовать ресурсы для других доменных имен
Разрешение доменного имени DNS
Прежде чем инициировать HTTP-запрос, браузер должен сначала получить IP-адрес веб-страницы, к которой мы хотим получить доступ, и браузер отправит пакет UDP на сервер разрешения доменных имен DNS.
рекурсивный запрос
Все наши браузеры, операционные системы и маршрутизаторы кэшируют IP-адреса, соответствующие некоторым URL-адресам, которые в совокупности называются кэшами DNS. Это сделано для ускорения разрешения DNS, чтобы не было необходимости каждый раз запрашивать корневой сервер имен.
итеративный запрос
Итеративный метод запроса заключается в том, что локальный DNS-сервер не запрашивает другие серверы сам по себе, а возвращает клиенту IP-адрес сервера, который может разрешить доменное имя, и клиент будет продолжать запрашивать эти серверы до тех пор, пока запрос не будет найден. .Местоположение, итерация только помогут найти нужный сервер, а потом сказать, что я сейчас занят, вы можете найти его сами.
Балансировка нагрузки DNS
DNS также играет роль в балансировке нагрузки.Сейчас многие веб-сайты имеют несколько серверов.Когда на веб-сайте слишком много трафика, если все запросы выполняются на одном и том же сервере, сервер может выйти из строя.Это используется в настоящее время.Технология балансировки нагрузки DNS , когда веб-сайт имеет несколько адресов серверов, при ответе на DNS-запросы DNS-сервер будет возвращать разные результаты разрешения для каждого запроса, то есть возвращать разные IP-адреса, чтобы прямой доступ к другому серверу для достижения цели Балансировка нагрузки. Например, он может основываться на загрузке каждой машины или географическом удалении машины от пользователя и т. д.
Предварительное разрешение DNS
Для крупных веб-сайтов, когда имеется несколько различных серверных ресурсов, можно использовать предварительное разрешение DNS для предварительного разрешения и уменьшения зависаний страниц.
Часть II Соединение TCP/IP: трехстороннее рукопожатие
многоуровневое сетевое протоколирование
протокол TCP/IP
TCP (Протокол управления передачей) Протокол управления передачей. Протокол TCP/IP объединяет прикладной уровень, уровень представления и сеансовый уровень в прикладной уровень, физический уровень и канальный уровень в уровень сетевого интерфейса.
Протокол TCP/IP относится не только к двум протоколам TCP и IP, но также относится к набору протоколов, состоящих из FTP, SMTP, TCP, UDP, IP, ARP и других протоколов.
трехстороннее рукопожатие
Клиент и сервер должны создать HTTP-запрос и вернуть проект.TCP connection
(по инициативе клиента),http
Нет понятия соединения, это просто запрос и ответ. И запросы, и ответы являются пакетами, и канал передачи между нимиTCP connection
.
Битовый код — это бит флага tcp, и существует 6 видов знаков:
- SYN (синхронное установление соединения)
- ACK (подтверждение подтверждения)
- ПШ (нажимная передача)
- FIN (конец конца)
- RST (сброс)
- УРГ (неотложная помощь)
Первое рукопожатие: хост A отправляет битовый кодSYN=1
, случайно генерируетсяSeq number=1234567
пакеты на сервер, хост B поSYN=1
Я знаю, A требует установления онлайн-соединения; (первое рукопожатие, инициированное браузером, сообщает серверу, что я хочу отправить запрос)
Второе рукопожатие: хост B должен подтвердить онлайн-информацию после получения запроса и отправить его на Aack number=(主机A的seq+1)
,SUN=1,ACK=1234567 + 1
, случайно сгенерированныйSeq=7654321
Пакет; (второе рукопожатие, инициированное сервером, сообщает браузеру, что я готов принять, можно быстро отправить)
Третье рукопожатие: Хост А проверяет после полученияack number
Правильно ли, то есть первым отправленнымseq number+1
, и биткодSYN
Будь то 1, если это правильно, хост А отправит его сноваack number=(主机B的seq+1)
,ack=7654321 + 1
, хост B подтверждает после его полученияSeq
значение сACK=7654321+ 1
Соединение установлено успешно; (третье рукопожатие, отправленное браузером, скажите серверу, я отправлю его немедленно, готов его принять)
Всегда спрашивайте: зачем вам три рукопожатия, а не два? На самом деле это связано с особенностями самого TCP.надежная передачарешенный. Для надежной передачи между клиентом и сервером необходимоподтвердить оба
接收
а также发送
способность. Первое рукопожатие может подтвердить обслуживание клиентов发送能力
, второе рукопожатие, серверSYN=1,Seq=Y
только что подтвердил发送能力
,ACK=X+1
только что подтвердил接收能力
, так что третье рукопожатие может подтвердить接收能力
. В противном случае возможна потеря пакетов.
Нужно ли третье рукопожатие?
Представьте, что если вы используете двустороннее рукопожатие, произойдет следующая ситуация: Если клиент отправляет запрос на подключение, но не получает подтверждения, поскольку пакет запроса на подключение потерян, клиент повторно передает запрос на подключение. Позже было получено подтверждение, и соединение было установлено. После завершения передачи данных соединение разрывается, а клиент отправляет всего два сегмента запроса на соединение, первый из которых потерян, а второй доходит до сервера, но первый потерянный сегмент находится только в некоторых узлах сети. застрял в течение длительного времени, и сервер задерживается до определенного времени после разрыва соединения.В это время сервер ошибочно думает, что клиент отправил новый запрос на соединение, поэтому он отправляет клиенту сегмент подтверждения, согласие Для установления соединения не используется трехстороннее рукопожатие.Пока сервер отправляет подтверждение, устанавливается новое соединение.В это время клиент игнорирует подтверждение, отправленное сервером, и не отправляет данные.Сервер ждет, пока клиент отправит данные, тратя ресурсы. .
Что такое очередь полусоединений?
После того, как сервер впервые получит SYN клиента, он будет находиться в состоянии SYN_RCVD. В это время две стороны не полностью установили свое соединение. Сервер поместит соединение запроса в этом состоянии в очередь, которую мы вызвать эту очередь.
Конечно, существует и полная очередь соединений, то есть трехстороннее рукопожатие завершено, и установленное соединение будет помещено в полную очередь соединений. Если очередь заполнена, может произойти потеря пакетов.
Вот еще немного о количестве повторных передач SYN-ACK: После отправки сервером пакета SYN-ACK, если он не получил пакет подтверждения клиента, сервер повторно передает его в первый раз, ждет некоторое время и не получает пакет подтверждения клиента и выполняет вторую повторную передачу. Если количество повторных передач превышает максимальное количество повторных передач, заданное системой, система удаляет информацию о соединении из очереди полусоединений.
Обратите внимание, что время ожидания для каждой повторной передачи не обязательно одинаково и обычно увеличивается экспоненциально, например, время интервала составляет 1 с, 2 с, 4 с, 8 с…
Установлен ли ISN?
Когда конец отправляет свой SYN для установления соединения, он выбирает начальный порядковый номер для соединения. ISN со временем меняются, поэтому каждое соединение будет иметь свой ISN. ISN можно рассматривать как 32-битный счетчик, который увеличивается на 1 каждые 4 мс. Цель выбора порядкового номера таким образом состоит в том, чтобы предотвратить передачу задержанного в сети пакета в более позднее время, что привело бы к его неправильной интерпретации одной стороной соединения.
Одной из важных функций трехэтапного рукопожатия является то, что клиент и сервер обмениваются ISN (начальным порядковым номером), чтобы другая сторона знала, как собирать данные в соответствии с порядковым номером при следующем получении данных. Если ISN фиксирован, злоумышленнику легко угадать последующие номера подтверждения, поэтому ISN генерируется динамически.
Могут ли данные передаваться во время трехэтапного рукопожатия?
Фактически, во время третьего рукопожатия данные могут передаваться. Однако первое и второе рукопожатия не могут передавать данные.
Почему это?Вы можете придумать вопрос.Если первое рукопожатие может нести данные, если кто-то хочет злонамеренно атаковать сервер, он каждый раз будет помещать много данных в сообщение SYN при первом рукопожатии. Поскольку злоумышленник просто игнорирует нормальные возможности сервера по приему и отправке, а затем лихорадочно повторяет пакеты SYN, это заставит сервер тратить много времени и памяти на получение этих пакетов.
То есть первое рукопожатие не может поставить данные, одна из простых причин в том, что оно делает сервер более уязвимым для атаки. В третий раз клиент уже находится в состоянии ESTABLISHED. Для клиента он установил соединение и уже знает, что возможности сервера по приему и отправке в норме, так что ничего страшного в переносе данных нет.
Синхронная атака?
Ресурсы на стороне сервера выделяются во время двустороннего рукопожатия, а ресурсы на стороне клиента выделяются после завершения трехстороннего рукопожатия, поэтому сервер уязвим для атак SYN-флудинга. Атака SYN означает, что клиент подделывает большое количество несуществующих IP-адресов за короткий промежуток времени и непрерывно отправляет SYN-пакеты на сервер, сервер отвечает на пакет подтверждения и ждет подтверждения от клиента. исходный адрес не существует, сервер должен постоянно повторять передачу, пока не истечет тайм-аут. , эти поддельные SYN-пакеты будут занимать несвязанную очередь в течение длительного времени, в результате чего обычные SYN-запросы будут отбрасываться, поскольку очередь заполнена, вызывая перегрузку сети или даже системный паралич. SYN-атака — типичная DoS/DDoS-атака.
Очень удобно обнаруживать SYN-атаки, когда вы видите большое количество полусоединенных состояний на сервере, особенно IP-адрес источника является случайным, вы можете в принципе сделать вывод, что это SYN-атака. В Linux/Unix вы можете использовать встроенную команду netstats для обнаружения SYN-атак.
netstat -n -p TCP | grep SYN_RECV
Общие методы защиты от SYN-атак следующие:
- Сократите время ожидания SYN
- Увеличьте максимальное количество полусоединений
- Фильтр защиты шлюза
- Технология файлов cookie SYN
Третья часть HTTP-запроса
История развития HTTP
HTTP/0.9
- Есть только одна команда GET
- Тип ответа: Только гипертекст
- Нет заголовка и другой информации для описания данных
- Сервер закрывает TCP-соединение после отправки
HTTP/1.0
- Добавлено много команд (пост HESD)
-
Увеличивать
status code
а такжеheader
- Поддержка нескольких символов, мультичастотная передача прав, кеш и т. Д.
- Ответ: больше не ограничивается гипертекстом (заголовок Content-Type обеспечивает возможность передачи файлов, отличных от HTML, таких как сценарии, стили или медиафайлы)
HTTP/1.1
- Постоянное соединение. Трёхстороннее рукопожатие TCP происходит один раз до того, как будет установлено какое-либо соединение. Наконец, когда все данные отправлены, сервер отправляет сообщение о том, что больше не будет данных для отправки клиенту, после чего клиент закроет соединение (отключит TCP).
-
Поддерживаемые методы:
GET
,HEAD
,POST
,PUT
,DELETE
,TRACE
,OPTIONS
- Значительная оптимизация производительности и улучшения функций, передача по частям, сжатие/распаковка, согласование кэширования контента, виртуальный хостинг (с несколькими доменами для хостов с одним IP-адресом), более быстрые ответы и дополнительная экономия за счет увеличения пропускной способности кэширования.
HTTP2
- Все данные передаются в двоичном виде. HTTP1.x основан на тексте и не может гарантировать надежность, HTTP2.0 определенно использует новый двоичный формат, который удобен и надежен.
- Отправка нескольких запросов в одном и том же соединении больше не должна выполняться последовательно.
- Функции повышения эффективности, такие как сжатие заголовков и push-уведомления.
HTTP3
- QUIC «Быстрые UDP-соединения с Интернетом»
Основное улучшение HTTP3 находится на транспортном уровне. На транспортном уровне больше не будет тех тяжелых TCP-соединений, о которых я упоминал ранее. Теперь все пойдет по UDP.
Особенности HTTP-протокола
-
Поддерживается клиент/серверный режим.
-
Когда простой и быстрый клиент запрашивает услугу с сервера, ему нужно только передать метод запроса и путь. Обычно используемые методы запроса — GET, HEAD и POST. Каждый метод определяет другой тип контакта между клиентом и сервером. Поскольку протокол HTTP прост, размер программы сервера HTTP невелик, поэтому скорость связи очень высока.
-
Гибкость: HTTP позволяет передавать объекты данных любого типа. Передаваемый тип помечен Content-Type (Content-Type — это идентификатор, используемый в HTTP-пакетах для представления типа контента).
-
Без установления соединения: Значение без установления соединения заключается в ограничении обработки только одного запроса на соединение. После того, как сервер обработает запрос клиента и получит ответ клиента, он отключится. Таким образом можно сэкономить время передачи.
-
Без сохранения состояния: протокол HTTP является протоколом без сохранения состояния. Без сохранения состояния означает, что протокол не имеет памяти для обработки транзакций. Отсутствие состояния означает, что если предыдущая информация требуется для последующей обработки, она должна быть передана повторно, что может привести к увеличению объема данных, передаваемых за соединение. С другой стороны, сервер быстрее отвечает, когда ему не нужна предыдущая информация.
HTTP3 теперь самый быстрый!
HTTP-сообщение
Сообщение запроса:
Ответное сообщение:
Связь между каждым протоколом и протоколом HTTP
- Служба DNS: преобразование доменных имен в соответствующие IP-адреса
- Протокол HTTP: создание сообщения HTTP-запроса для целевого веб-сервера.
- Протокол TCP: разделите сообщение запроса на несколько сегментов в соответствии с порядковым номером.
- IP-протокол: поиск адреса другой стороны и передача во время передачи
- Протокол TCP: результат обработки сообщения запроса реорганизуется в исходном порядке в соответствии с порядковым номером, а результат обработки запроса также отправляется обратно пользователю с использованием протокола TCP/IP.
- TCP — это базовый протокол связи, который определяет спецификацию методов передачи данных и соединения;
- HTTP — это протокол прикладного уровня, определяющий спецификацию содержания передаваемых данных;
- Данные в протоколе HTTP передаются с использованием протокола TCP, поэтому поддержка HTTP также должна поддерживать TCP.
Есть еще много вещей о HTTP, я поставил Zhang в концеБольшая фотография.
HTTPS
Добавление уровня TLS (Transport Layer Security) или SSL (Secure Sockets Layer) к HTTP представляет собой протокол HTTPS.
HTTPS по умолчанию работает на порту 443 протокола TCP, и его рабочий процесс обычно выглядит следующим образом:
- Трехсторонняя синхронизация рукопожатия TCP
- Цифровой сертификат сервера проверки клиентов
- Алгоритм DH согласовывает ключ алгоритма симметричного шифрования и ключ алгоритма хеширования.
- Согласование безопасного зашифрованного туннеля SSL завершено
- Веб-страницы передаются в зашифрованном виде, зашифрованном с помощью согласованного алгоритма симметричного шифрования и ключа для обеспечения конфиденциальности данных; согласованный алгоритм хеширования используется для защиты целостности данных, чтобы гарантировать, что данные не будут подделаны.
- Клиент отправляет на сервер
Client Hello
Сообщение, которое содержит версию протокола, алгоритм шифрования, алгоритм сжатия и случайное число, сгенерированное клиентом, поддерживаемое клиентом; - После получения сервером информации о версии протокола, поддерживаемой клиентом, алгоритм шифрования;
- отправить клиенту
Server Hello
сообщение и нести выбранную конкретную версию протокола, метод шифрования, идентификатор сеанса и случайное число, сгенерированное сервером; - отправить клиенту
Certificate
Сообщение, то есть цепочка сертификатов сервера, содержащая такую информацию, как имя домена, эмитент и период действия, поддерживаемый сертификатом; - отправить клиенту
Server Key Exchange
Сообщение, пройти открытый ключ и подпись и другую информацию; - Отправить сообщение клиенту необязательно
Certificate Request
, проверьте сертификат клиента; - отправить клиенту
Server Hello Done
сообщение для уведомления сервера о том, что вся необходимая информация отправлена;
- отправить клиенту
- После того, как клиент получает такую информацию, как версия протокола, метод шифрования, идентификатор сеанса и сертификат сервера, он проверяет сертификат сервера;
- отправить на сервер
Client Key Exchange
Сообщение содержит случайную строку, зашифрованную открытым ключом сервера, то есть предварительным мастер-ключом (Pre Master Secret
); - отправить на сервер
Change Cipher Spec
сообщение, уведомляющее сервер о том, что сегмент данных, стоящий за ним, будет зашифрован для передачи; - отправить на сервер
Finished
сообщение, содержащее зашифрованную информацию о рукопожатии;
- отправить на сервер
- сервер получает
Change Cipher Spec
а такжеFinished
После сообщения;- отправить клиенту
Change Cipher Spec
сообщение, информирующее клиента о том, что сегмент данных, стоящий за ним, будет зашифрован для передачи; - отправить клиенту
Finished
сообщение, подтверждающееFinished
сообщение и завершите рукопожатие TLS;
- отправить клиенту
Ключом к рукопожатию TLS является использование случайной строки, сгенерированной двойной генерацией связи, и открытого ключа сертификата сервера для создания симметричного ключа, согласованного обеими сторонами, чтобы обе стороны могли использовать этот симметричный ключ для шифрования. данные сообщения в последующих передачах данных, чтобы предотвратить мониторинг и атаки посредника, а также обеспечить безопасность связи.
HTTPS-соединение требует 7 рукопожатий, 3 TCP + 4 TLS.
Часть 4. Сервер обрабатывает запрос и возвращает HTTP-сообщение.
На каждом сервере будет установлено приложение, обрабатывающее запрос - веб-сервер. Общие продукты веб-сервера включаютapache
,nginx
,IIS
илиLighttpd
Ждать.
HTTP-запросы обычно можно разделить на две категории: статические ресурсы и динамические ресурсы.
Чтобы запросить доступ к статическим ресурсам, просто перейдите на сервер напрямую по URL-адресу, чтобы найти его.
Чтобы запросить динамические ресурсы, веб-сервер должен делегировать различные запросы программам на сервере, которые обрабатывают соответствующие запросы (например, сценарии CGI, сценарии JSP, сервлеты, сценарии ASP, серверный JavaScript или некоторые другие серверные технологии). , и т.д.), а затем вернуть результат фоновой обработки программы в качестве ответа и отправить его клиенту.
Сервер обрабатывает запросы тремя основными способами:
- Первый заключается в использовании одного потока для обработки всех запросов, причем одновременно может обрабатываться только один запрос, но производительность при этом очень низкая.
- Второй: назначает поток на каждый запрос, но когда соединений и запросов много, процессор сервера будет перегружен.
- Третий — использовать мультиплексный ввод-вывод для обработки, например, мониторинга всех ссылок через epoll, и выделять пространство для обработки при изменении статуса ссылки.
Часть 5 Браузерный рендеринг страницы
DOM-дерево
байт → символ → токен → узел → объектная модель.
<!DOCTYPE html>
<html>
<head>
<meta name="viewport" content="width=device-width,initial-scale=1">
<link href="style.css" rel="stylesheet">
<title>Critical Path</title>
</head>
<body>
<p>Hello <span>web performance</span> students!</p>
<div><img src="awesome-photo.jpg"></div>
</body>
</html>
- Преобразование: Браузер считывает необработанные байты HTML с диска или из сети и преобразует их в отдельные символы в соответствии с указанной кодировкой файла (например, UTF-8).
- Токенизация: Браузеры преобразуют строки в различные токены, указанные в стандарте W3C HTML5, такие как "", "" и другие строки, заключенные в угловые скобки. Каждый токен имеет особое значение и набор правил.
- Лексический анализ: выпущенные токены преобразуются в «объекты», которые определяют их свойства и правила.
- Построение DOM: наконец, поскольку HTML-теги определяют отношения между различными тегами (некоторые теги содержатся внутри других), созданные объекты связываются в древовидной структуре данных, которая также фиксирует отношения родитель-потомок, определенные в исходном теге. Отношение элементов: объект HTML. является родителем объекта тела, тело является родителем объекта абзаца и так далее.
Объектная модель CSS (CSSOM)
body { font-size: 16px }
p { font-weight: bold }
span { color: red }
p span { display: none }
img { float: right }
Дерево компоновки
- Дерево DOM объединяется с деревом CSSOM для формирования дерева рендеринга.
- Дерево рендеринга содержит только узлы, необходимые для рендеринга веб-страницы.
- Макет вычисляет точное положение и размер каждого объекта.
- Последним шагом является рисование, в котором используется окончательное дерево рендеринга для рендеринга пикселей на экране.
оказывать
Процесс рендеринга:
- После получения DOM он делится на несколько слоев.
- Вычислить результаты стиля для узлов каждого слоя (Пересчитать стиль - пересчет стиля)
- Генерировать графику и позиции для каждого узла (макет — перестановка, перекомпоновка)
- Нарисуйте и заполните каждый узел растровым изображением слоя (Paint--redraw)
- Слои загружаются в GPU как текстуры.
- Объедините несколько слоев на странице, чтобы создать окончательное изображение на экране (композитные слои — реорганизация слоев).
Создать слои
<div class="position_">position</div>
<div class="box_3d">3d变换</div>
<div class="will-change">will-change</div>
<div class="transform"></div>
<iframe src="https://www.baidu.com"></iframe>
div {width: 100px;height: 100px;}
.position_ {background: pink;position: fixed;z-index: 20;}
.box_3d {background: red;transform: translate3d(100px,30px,10px);}
.will-change {background: #f12312;will-change: transform;}
.transform {background: #302912;transform: skew(30deg, 20deg);}
Просмотр слоев в хроме.Если Слои не открыты, откройте его, как показано ниже:
Зная о существовании слоя, мы можем вручную открыть слой, добавив
transform: translateZ(0)
Таким образом, стоимость оплавления и перерисовки невелика, а эффективность значительно повышается. Но не злоупотребляйте этим свойством, иначе сильно увеличится потребление памяти. - Включить ускорение графического процессора.
Перекомпоновать и перекрасить
- перерисовать
Когда изменение стиля элемента на странице не влияет на его положение в потоке документа (например: цвет, цвет фона, видимость и т. д.), браузер присвоит элементу новый стиль и перекрасит его. , процесс, называемый перекрашиванием окрашенных.
- переплавка
Когда размер, структура или некоторые свойства некоторых или всех элементов в дереве рендеринга изменяются, процесс, в котором браузер повторно рендерит часть или весь документ, называется перекомпоновкой.
Оплавление неизбежно вызовет перерисовку, а перерисовка не обязательно приведет к оплавлению.
Вызывает обратный поток:
- первый рендер страницы
- Изменился размер окна браузера
- Изменение размера или положения элемента
- Изменения содержимого элемента (количество текста или размер изображения и т. д.)
- Изменение размера шрифта элемента
- Добавить или удалить видимые элементы DOM
- Активировать псевдоклассы CSS (например: :hover )
- запрашивать определенные свойства или вызывать определенные методы
Свойства и методы, вызывающие перекомпоновку:
- clientWidth, clientHeight, clientTop, clientLeft
- offsetWidth, offsetHeight, offsetTop, offsetLeft
- scrollWidth, scrollHeight, scrollTop, scrollLeft
- прокруткаIntoView(), прокруткаIntoViewIfNeeded()
- getComputedStyle()
- getBoundingClientRect()
- scrollTo()
Как уменьшить обратный поток
- css
- Избегайте использования макета таблицы;
- Измените классы, насколько это возможно, в самом конце дерева DOM;
- Избегайте установки нескольких слоев встроенных стилей;
- Примените эффект анимации к элементу, чей атрибут position является абсолютным или фиксированным;
- Избегайте использования выражений CSS (например, calc() ).
- JS
- Чтобы избежать частых манипуляций со стилями, лучше за один раз переписать атрибут стиля или определить список стилей как класс и одновременно изменить атрибут класса.
- Чтобы избежать частых манипуляций с DOM, создайте documentFragment, примените к нему все манипуляции с DOM и, наконец, добавьте его в документ.
- Вы также можете сначала установить display: none для элемента и отобразить его после завершения операции. Поскольку операции DOM над элементами со свойством display, равным none, не вызовут перекомпоновку и перерисовку.
- Избегайте частого чтения свойств, которые вызовут перекомпоновку/перерисовку, и если вам действительно нужно использовать их несколько раз, кэшируйте их в переменной.
- Используйте абсолютное позиционирование для элементов со сложной анимацией, чтобы они не попадали в поток документа, иначе это вызовет частые перекомпоновки родительских и последующих элементов.
Часть 6. Отключение: TCP прерывается четыре раза
- В начале обе стороны находятся в установленном состоянии, если клиент первым инициирует запрос на завершение работы.
- Первая волна: клиент отправляет сообщение FIN, и в сообщении указывается порядковый номер. В этот момент клиент находится в состоянии FIN_WAIT1.
- Вторая волна: после того, как сервер получит FIN, он отправит сообщение ACK и использует значение серийного номера клиента + 1 в качестве значения серийного номера сообщения ACK, указывая, что сообщение клиента было получено. серверная часть в состоянии CLOSE_WAIT
- Третья волна: Если сервер тоже хочет отключиться, как и первая волна клиента, отправьте сообщение FIN и укажите серийный номер. В это время сервер находится в состоянии LAST_ACK.
- Требуется некоторое время, чтобы гарантировать, что сервер войдет в состояние CLOSED после получения собственного сообщения ACK.После того, как сервер получит сообщение ACK, он закроет соединение и будет находиться в состоянии CLOSED.
Зачем нужно махать четыре раза?
Потому что, когда сервер получает сообщение с запросом на соединение SYN от клиента, он может напрямую отправить сообщение SYN+ACK. Сообщение ACK используется для ответа, а сообщение SYN используется для синхронизации. Однако, когда соединение закрыто, когда сервер получает сообщение FIN, он, скорее всего, не закроет SOCKET немедленно, поэтому он может сначала ответить только сообщением ACK, сообщая клиенту: «Я получил отправленное вами сообщение FIN». Я могу отправить сообщение FIN только до тех пор, пока все сообщения на моем сервере не будут отправлены, поэтому я не могу отправить его вместе. Итак, требуется четыре волны.
Почему клиент не закрывается сразу после отправки ACK, а ждет некоторое время перед закрытием?
После того, как клиент получает от сервера сегмент освобождения соединения, он отправляет сегмент подтверждения (ACK=1, seq=u+1, ack=w+1), и клиент переходит в состояние TIME_WAIT (время ожидания). В это время TCP не освобождается, и клиент переходит в состояние CLOSED только после того, как время, установленное таймером ожидания, равно 2MSL. Если вы не дождетесь, клиент убежит.Когда на сервере еще много пакетов данных для отправки клиенту и он все еще в пути, если порт клиента в это время как раз занят новым приложением, он будет получать бесполезные данные.пакет, что приводит к путанице пакетов.
Почему состояние TIME_WAIT должно пройти через 2MSL (максимальное время существования сообщения), прежде чем вернуться в состояние CLOSE?
Теоретически, после отправки всех четырех пакетов можно сразу войти в состояние CLOSE, но сеть может оказаться ненадежной, и последний ACK может быть потерян. Таким образом, состояние TIME_WAIT используется для повторной отправки сообщений ACK, которые могут быть потеряны. 1 MSL гарантирует, что последнее сообщение ACK стороны, которая активно закрывает раздачи после четырех волн, может, наконец, достичь противоположного конца; 1 MSL гарантирует, что сообщение FIN, повторно переданное одноранговым узлом без получения ACK, может быть доставлено.
О HTTP
Если вам нужны большие изображения высокой четкости или файлы Xmind, вы можете отправить личное сообщение lian x
Стоя на плечах гигантов
Отдаю должное старшим здесь, нашел много информации, если есть упущения, прошу меня простить. Если в тексте есть ошибки, пожалуйста, вовремя указывайте на них, спасибо!
Разберитесь с HTTP3 за 5 минут Эта статья берет вас, чтобы понять HTTPS Что именно происходит от ввода URL до представления страницы? Что именно происходит от ввода URL до представления страницы? Весь процесс запроса URL в браузере Классические вопросы для фронтенд-интервью: что происходит от ввода URL до загрузки страницы? Кеша браузера достаточно, чтобы прочитать эту статью Поток от ввода URL до браузера, отображающего страницу Что происходит после того, как браузер вводит URL-адрес и нажимает клавишу ввода (сверхподробная версия) Разница между TCP и Http!Я все понимаю, не путайте! Почему HTTPS нужно 7 рукопожатий и 9-кратная задержка Визуализировать построение дерева, компоновку и рисунок Подробный процесс рендеринга в браузере: перерисовка, перестановка и компоновка — это лишь верхушка айсберга. Механизм рендеринга в браузере и Reflow (перекомпоновывать, перекомпоновывать) и Repaint (перекрашивать) Спросите меня принцип рендеринга браузера Chrome (6000 слов длинный текст) В браузере перерисовывать слои и переставлять (подробно) и как оптимизировать для производительности HTTP Notes 1: Web Fundamentals and Simple HTTP Protocol Графические картинки HTTP-21 четко упорядочивают HTTP HTTP3 Эта статья поможет вам понять HTTPS Принцип работы браузера и практика