Знания, связанные с сетями, — это то, что должен иметь каждый фронтенд-инженер. Многие друзья, которые занимаются интерфейсом, систематически не изучали компьютерную сеть и контент, связанный с http. Без создания общей системы знаний будет ощущение, что вы отвечаете на вопросы от одной остановки до конца.Каждая точка знаний примерно знает ответ на вопрос, но это всегда неопределенно, не говоря уже о том, что происходит. В этой статье систематически сортируются сетевые знания, тесно связанные с внешним интерфейсом. (Это резюме моего собственного обучения, заметки, которые я разобрал и поделился с вами)

Демонстрации кода в этой статье организованы в«Маленькая красота Node.js»:

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

Должен:

Каково содержимое http-пакетов?
Каковы важные части заголовка протокола HTTP, код состояния HTTP?
Что такое коды состояния HTTP?
Что такое сильный кеш? Что такое слабый кеш?
Каков текущий механизм кэширования браузера? Как настроить HTTP-кеш?
Какие методы HTTP вы знаете? В чем разница между POST и PUT?
Как сжимать данные (ZLIB), Gzip, какая степень сжатия, будут ли сжиматься заголовки запросов?
Междоменный, почему JS ограничивает междоменный? Как разрешить междоменный доступ?

Основание:

Какие причины влияют на скорость интернета? Каковы основные причины потери сетевых пакетов?
Каковы пятиуровневые эталонные модели сетевой архитектуры? Каковы отношения между ними?
Мы часто слышим о сообщениях, сегментах (пакетах), дейтаграммах, фреймах и пакетах, как они связаны?
Ajax может отправлять http-запросы, как это связано с http?
Какую проблему решает HTTP1.0 до http1.1?
Каковы особенности http2?
Почему http1.1 блокирует начало очереди?
Связь SSL и TLS? Как реализован протокол HTTPS?

Дополнительные уроки и дополнения: (обновляется медленно)

Каковы наиболее часто используемые протоколы транспортного уровня? Каковы характеристики TCP и UDP?
Объясните трехстороннее рукопожатие TCP и четырехстороннюю волну?
Почему TCP может быть узким местом сетевого взаимодействия? Как решить блокировку заголовка очереди TCP?
Почему новый QUIC от Google основан на UDP?
Какие новые функции появились в QUIC и какие проблемы он решает?

Это должно быть связано с протоколом http, который наиболее тесно связан с интерфейсной работой. Но если нет сетевого фундамента, это как замок в небе. Совокупность знаний не может быть установлена. Поэтому в этой статье будут собраны необходимые знания и основа, что является содержанием глав 1-5 этой статьи.

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

В этой статье узел будет использоваться в качестве демонстрации кода, а соответствующий код находится на github. Для студентов с плохой базой узлов я организовал весь код в этой главе в учебный документ по узлам.«Маленькая красота Node.js». В каждом разделе будут упражнения для закрепления обзора, и я буду добавлять их постепенно.

1 Основы сети

Начнем с первого вопроса: когда браузер обращается к www.jd.com, мы все знаем, что браузер отправляет http-запрос на сервер и отправляет сообщение с запросом на сервер. Итак, позвольте мне кратко проанализировать процесс.

1.1 Доставка пакетов

Браузер сгенерирует http-сообщение (сообщение) на основе протокола http, а затем разделит сообщение на разные группы (пакеты). отправили на маршрут. Маршрут сначала кэшируется, а затем перенаправляется на следующий маршрут в соответствии с таблицей маршрутизации, пока не достигнет сервера.

客户端 ---> 路由--->路由.......----> 路由--->服务器

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

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

(1) Основные вопросы (от "Ali Technology Eyes")

使用一辆卡车运输n块装满数据的1TB硬盘，以80km/h速度行驶1000km将数据运送到目的地，
卡车至少运送多少块硬盘才能使传输速率超过1000Gbit/s？

答案：5625
解析：这个问题可以简化成两种方案在相同时间内两种方案要传输相同的数据量。
卡车的时间为： 1000km ÷ 80Km = 12.5h
在相同时间内网络传输的数据量为： 12.5h * 3600s/h * 1000Gbit/s ÷ 8b/B = 5625000GB.
那么卡车需要运输相同的运算量，5625000GB  ÷ 1000GB  =  5625块。
总结：带宽：在链路上的传输速率（bit/sec 即 bps）
      bit(位)  // 1 Byte = 8 bit

Расширение: Итак, давайте проанализируем время доставки сейчас

现在有一个5Mbits的报文，在宽带是1Mbps,从客户端C1 发送到 服务器h2，经过路由器A，B。忽略其他影响。

C1---> A ----> B ---- h2

一次报文交换交付时间: 

C1---> A : 5Mbits ／ 1Mbps = 5s
A ---> B : 5Mbits ／ 1Mbps = 5s
B --->h2 : 5Mbits ／ 1Mbps = 5s
共15s

如果分成5000组 ， 那么每个包是1bits。

H1---> A : 1bits ／ 1Mbps = 1ms  

当第1个到达时A时需要1ms，第2个已经出发
当第2个已经到A时，第1个已经到达B
当第5000个到达A时，第4999个到底B，其余都到达。这时候用时5s
当第5000个到达h2时，就用时，5秒零2毫秒。

最后总结一下：
-  报文：M bits
-  链路宽带：R bps
-  路由器数：n 
-  分组长度：L bits

-  一次报文交换交付时间   : T = (n+1) * (M / R)
-  分组交换报文交付时间：T = M / R + nL/R

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

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

задержка в очереди: Например, когда первый прибывший пакет прибывает в А, если до него уже прибыли какие-то другие пакеты клиента, то он будет ждать во многих очередях. Время, проведенное в очереди, называется задержкой очереди.
Задержка обработки узла: после прибытия очереди узел A выполнит некоторую обработку пакета.Это время обработки называется задержкой обработки узла, которая обычно очень мала и составляет миллисекунды.
Задержка распространения: После запуска A распространение от A к B по каналу все еще должно пройти определенное физическое расстояние, но скорость передачи очень высока, обычно в 0,7 раза больше скорости света, и используемое время называется задержкой распространения.
потеря пакетов: если множество клиентов отправляют пакеты данных узлу А одновременно, после того, как кэш узла А будет заполнен, следующие пакеты данных будут отброшены. И это основная причина потери пакетов.

Вопрос: Теперь, когда у нас есть общее представление об этом процессе, через какие конкретные процессы мы проходим?

1.2 Сетевая архитектура

Давайте сначала посмотрим на эталонную модель 70%, объясненную OSI.

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

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

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

прикладной уровень:

Браузер формирует заголовок и тело сообщения по протоколу http
Кодируйте, шифруйте и сжимайте параллельные сообщения.
После инкапсуляции данные передаются на следующий уровень, который мы называем PUD.сообщение

транспортный уровень:

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

Сетевой уровень:

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

связующий слой:

После того, как сетевой уровень примет каждый сегмент, он добавит свою собственную информацию о протоколе в соответствии с протоколом IP.
Основные функции этой информации протокола: физическая адресация (MAC-адрес), управление потоком, контроль ошибок и контроль доступа.
После инкапсуляции данные передаются на следующий уровень, который мы называем PUD.Рамка

физический слой:

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

Итак, теперь мы знаем, что каждый отправленный HTTP-запрос является запросом и ответом для прикладного уровня. Прикладной уровень перемещается туда и обратно только один раз. Но нижележащий транспортный уровень должен разделить все сообщение на множество групп и затем передать его следующему уровню.Знаменитые три ссылки TCP относятся к транспортному уровню. Поэтому для запроса и ответа на прикладном уровне ссылка может занять много времени. Каждый пакет должен иметь протокол каждого уровня, невозможно иметь только верхний уровень без нижнего. Пакет данных, о котором мы часто говорим, должен быть сегментом (пакетом), который обрабатывается и, наконец, превращается в биты для передачи по каналу.

Вы заметили, что мы говорим не о слое представления и уровне сеанса? потому что

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

1.3 Канальный уровень и физический уровень

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

Мы знаем, что физическая адресация (MAC-адрес) хоста, к которому осуществляется доступ, будет добавлена на канальном уровне, поэтому, если сетевой кабель подключен к нескольким компьютерам, он будет отправлен на каждый компьютер, преобразованный обратно в кадры на физическом уровне. слой и обнаружил, что если это не так, Mac-адрес целевого компьютера не будет обрабатываться. Пока не найдете компьютер с целевым Mac-адресом. Здесь используется протокол MAC.

1.4 Сетевой уровень и канальный уровень

Так как же канальный уровень узнает Mac-адрес целевой машины?

На сетевом уровне мы знаем IP для доступа к серверу.Сначала операционная система определит, является ли это локальным IP.Если нет, то он будет отправлен на шлюз. При запуске операционной системы для нее будет настроен IP-адрес по протоколу DHCP и IP-адрес шлюза по умолчанию 192.168.1.1. Операционная система будет вещать, кто 192.168.1.1? Шлюз ответит на него, я, это Mac-адрес. Итак, мы знаем Mac адрес. Протокол, который передает MAC-адрес в широковещательном режиме, называется протоколом ARP.

Шлюз часто представляет собой маршрутизатор, который знает, как добраться до определенного IP-адреса.Это называется таблицей маршрутизации. Таким образом, он выводит дейтаграмму из кадра, видит IP, на который вы хотите перейти, и подсказывает, в какую сторону вам следует идти и какой маршрут найти. Затем Mac-адрес этого маршрута записывается в инкапсулированном фрейме канального уровня.

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

(Проверочный вопрос 1) Неопределенный вариант Семиуровневый сетевой протокол (из письменных тестовых вопросов Jingdong Autumn Recruitment 2018)

用浏览器访问www.jd.com时，可能使用到的协议有？
A MAC
B HTTP
C SMTP
D ARP
E RTSP

答案：A B D
解析：所以在第一题中 HTTP是在应用层用的协议 。
     MAC和ARP是在数据链路层用和网络层用到的协议。
     而同样的应用层协议SMTP是邮件传输协议,RTSP是实时流传输协议。
     在访问www.jd.com的时候，我们用不到。

2 прикладной слой

2.1 Протокол прикладного уровня

Прикладной уровень основан на протоколе транспортного уровня. Распространенными протоколами транспортного уровня являются TCP и UDP.

На основе TCP: HTTP (протокол передачи гипертекста), FTP (протокол передачи файлов), SMTP (протокол передачи почты)
На основе UDP: DNS (система доменных имен) и недавнего появления QUIC (протокол транспортного уровня Интернета с малой задержкой от Google)

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

2.2 URL: Унифицированный указатель ресурсов

Синтаксис:

协议://用户名:密码@子域名.域名.顶级域名:端口号/目录/文件名.文件后缀?参数=值#标志

http://username:password@host:80/directory/file.html?query#ref
ftp://username:password@host:21/directory/file.html
news://news.newsgroup.com.hk

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

Если в параметре есть !,%,&,/,?,= и другие незападноевропейские символы, необходимо использовать метод encode для предварительной обработки URL-адреса.

decode декодирует в обычную строку
кодировать обычную строковую кодировку, закодированное имя очень длинное (application/x-www-form-urlencoded строка MIME)

2.3 Демонстрация кода

Функция прикладного уровня заключается в завершении обмена сообщениями между клиентом и сервером.

Браузер отправляет http запрос: будут введены ip службы и порт
Номер порта, который сервер прослушивает и на который отвечает при получении запроса.

Узел демонстрации кода для создания TCP-сервера

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

Здесь нас не интересуют подробности TCP, мы поговорим о транспортном уровне.

Вопрос: Получив общее представление о протоколе прикладного уровня, давайте подробно изучим протокол http.

3 HTTP-протокол:

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

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

3.1 HTTP-сообщение

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

Сообщение на стороне запроса называется сообщением запроса.
Сообщение на стороне отклика называется ответным сообщением

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

let responseDataTpl = `HTTP/1.1 200 OK
Connection:keep-alive
Date: ${new Date()}
Content-Length: 12
Content-Type: text/plain

Hello world!
`;

Между заголовком сообщения и телом сообщения должна быть пустая строка (CR+LF: возврат каретки + перевод строки)
Заголовок сообщения: информация, полученная при обработке запросов и ответов (различная информация, указанная выше).
Тело сообщения: есть все необходимые ресурсы (например, возвращенное текстовое сообщение «Привет, мир»).

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

Общее поле заголовка (Общее): поле, используемое как пакетами запросов, так и пакетами ответов.
Заголовок запроса: заголовок, используемый сообщением запроса.
Заголовок ответа: заголовок, используемый ответным сообщением.
Заголовок сущности: поля с информацией о сущности

Таким образом, в сети Chrome заголовок будет отображаться как:

General
Response Headers
Requse Headers

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

Мы обнаружили, что в приведенном выше TCP-сервере очень проблематично каждый раз писать ответное сообщение, соответствующее формату протокола http.Почему бы нам не инкапсулировать его? Да, поэтому в следующем случае мы используем инкапсулированный модуль HTTP.

Демонстрация кода: создайте HTTP-сервер с узлом

Мы видим в коде 'Content-Type', его роль заключается в указании формата контента.

Вопрос: Теперь вы меняете фактический код состояния на 400 и обнаруживаете, что страница по-прежнему доступна в обычном режиме. Это собственно то, что вы и бэкенд заказывали по стандарту, так какие же стандарты?

3.2 Коды состояния HTTP

Код состояния HTTP: клиент отправляет запрос на сервер с описанием состояния запроса. Состав кода состояния: состоит из 3 цифр и фразы причины, такой как (200 OK и 206 Partial Content)

Первая цифра обозначает категорию:

-  1XX :  信息性状态码（接收请求正在处理）
-  2XX :  成功状态码（请求正常处理完毕）
-  3XX :  重定向状态码（需要进行附加操作以完成请求）
-  4XX :  客户端错误状态码（服务器无法处理请求）
-  5XX :  服务端错误状态码（服务器处理请求出错）

Таким образом, код состояния представляет собой соглашение о состоянии внешнего и внутреннего взаимодействия.В принципе, если соблюдается определение категории кода состояния, изменение кода состояния, определенного в RFC2616, не проблема. или создать его самостоятельно.

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

- 200 OK ：请求被正常处理返回 200 OK，这也是我们最常见的啦
- 204 No Content :请求处理成功但是没有资源返回，就是报文中没有报文主体
- 206 Partial Content :客户端进行范围请求，就是请求资源一部分，服务器返回请求这部分（Content-Range）

- 301 Moved Permanently:永久重定向（资源的URL已经更新）
- 302 Found :临时重定向（资源的URI已经临时定位到其他位置了）
- 303 See Other: 对应的资源存在另一URL，资源的URL已经更新，是否按新的去访问
- 304 Not Modified:客户端发附带条件的请求，服务端允许请求访问资源，但没有满足条件
- 307 Temporary Redirect: 也是临时重定向

- 400 Bad Request : 请求报文中存在语法错误
- 401 Unauthorized : 需要有HTTP认证
- 403 Forbidden : 请求访问的资源被服务器拒绝了
- 404 Not Found : 服务器上没有找到资源
- 500 Internal Server Error: 服务器执行请求时出错
- 503 Service Unavailable : 服务器处于超负载，正在进行停机维护

Демонстрация кода: полная маршрутизация узла с модулем URL-пути

(Проверочный вопрос 3) Несколько вариантов кода статуса http (от Ali Technology Eye)

chrome DevTools的Network面板中参看静态资源加载情况，当发现静态资源的HTTP状态码
是___时，需要使用强制刷新以便获得最新版的静态资源？
  A 204
  B 304
  C 403
  D 501

答案：B
解析：304是资源重定向，客户端发附带条件的请求，服务端允许请求访问资源，但没有满足条件
     你是不是还有点蒙呢，别着急httpd的缓存协议里你就会看见它啦。

Вопрос: Мы знаем, что обозначают коды состояния, но в каких случаях они появляются? Давайте учиться один за другим

3.2 Протокол сжатия HTTP

Протокол сжатия HTTP очень прост для понимания, например, если вы хотите загрузить файл 1G своему другу на QQ, это займет 10 минут, вау, скорость сети очень высокая. Но если его сжать, файл становится 300M. Это может занять 3 минуты, чтобы передать его своим друзьям. Тогда вам потребуется 1 минута на сжатие и минуту ему на распаковку. Итак, вы закончили через 5 минут. То же самое.

Заголовок http-запроса: Accept-Encoding: gzip, deflate, br

Это браузер сообщает серверу, какие форматы сжатия я поддерживаю и каков приоритет.

заголовок ответа http: Content-Encoding: gzip

Это сервер сообщает браузеру, какой формат я сжал, пожалуйста, выполните распаковку

Итак, в браузере нам нужно судить о том, какое сжатие поддерживает браузер, на основе Accept-Encoding в заголовке запроса. Затем скажите браузеру после сжатия, что я дал вам, как это выглядит.

Демонстрация кода: 2.5 Сжатие файлов с помощью gzip

3.3 Протокол кэширования HTTP

3.3.1 Сильный кеш

Catche Control: : это общее поле заголовка, которое используется как в отправляемом сообщении, так и в ответном сообщении ранее. Вы можете установить кеш ссылочных ресурсов в файле

Вот простой пример:

  浏览器发访问http://localhost:10080/
  -       '请求报文没带 Cache-Control' 客户端说我要访问首页
  
  服务器返回数据
  -       '响应报文带:Cache-Control : max-age = 604800'  服务器说给你index.html和加载里面资源,并告诉你这些资源一周之内不要不必确认了
  
  浏览器刷新的网页再次访问http://localhost:10080/时
  -        里面的资源就不会再发送请求了,直接从缓存中拿  你会在chrome,network中看到Time是0(from memory catch)

  服务器返回数据
  -       服务器只返回index.html文件


  这时候你强制刷新浏览器(command+shift+R) 
  -       '请求报文带 Catche Contrl：no-cache '客户端说我不要缓存过的数据，我要源服务器的数据
  
 服务器返回数据
  -       服务器返回index.html文件和依赖的资源

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

Демонстрация кода: реализация протокола кэширования браузера

3.3.2 Кэш согласования

Есть два вида:

Первый: If-Modified-Since/Last-Modified

Сервер выдаст время последней модификации Last-Modified. Затем браузер запомнит это время. Когда браузер запрашивает второй раз, он выводит время if-modified-since. Сервер может сравнить, был ли файл изменен после времени if-modified-since. Если он не был изменен, он возвращает 304.

Last-Modified: указывает время последней модификации этого ресурса ответа. Когда веб-сервер отвечает на запрос, он сообщает браузеру, когда последний раз изменялся ресурс.
If-Modified-Since: когда срок действия ресурса истекает (используя максимальный возраст, определенный Cache-Control), обнаруживается, что ресурс имеет объявление Last-Modified, и запрос снова отправляется на веб-сервер с заголовком If --Modified-Since с указанием времени запроса. После того, как веб-сервер получает запрос и обнаруживает наличие заголовка If-Modified-Since, он сравнивается со временем последней модификации запрошенного ресурса. Если время последней модификации более новое, что указывает на то, что ресурс был изменен снова, он ответит всем содержимым ресурса (записанным в теле ответного сообщения), HTTP 200; если время последней модификации устарело, что указывает на то, что ресурс был не был изменен, он ответит HTTP 304 (нет необходимости в теле пакета, сохранение просмотра), сообщая браузеру, что нужно продолжать использовать сохраненный кеш.

Демонстрация кода: реализация протокола кэширования браузера

В приведенном выше коде наш сервер не записывает время модификации файла, нам нужно только сравнить его в течение определенного периода времени. мы знаем, как использовать If-modified-since, сервер каждый раз будет записывать время модификации файла. Так что по времени судить не очень хорошо.

Второй: Etag/If-None-Match

Сервер Etag отправит строку, а затем браузер внесет эту строку в if-none-match во втором запросе. В это время сервер может сравнить две строки и, если они совпадают, разрешить браузеру обратиться к кешу для их извлечения.

Etag: когда веб-сервер отвечает на запрос, он сообщает браузеру, что текущий ресурс находится на сервере. Уникальный идентификатор (правила генерации определяются сервером)
If-None-Match: когда срок действия ресурса истекает (используя максимальный возраст, определенный Cache-Control), обнаруживается, что ресурс имеет объявление Etage, и к запросу присоединяется If-None-Match (значение Etag). снова на веб-сервер. После того как веб-сервер получает запрос и обнаруживает наличие заголовка If-None-Match, он сравнивает его с соответствующей контрольной строкой запрошенного ресурса и принимает решение вернуть 200 или 304.

Демонстрация кода: реализация протокола кэширования браузера

Итак, теперь, узнав о двух видах кэшей, вы спросите, если есть оба, как оценивает браузер?

3.3.3 Механизм кэширования браузера

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

(Упражнение 4) HTTP-кеширование неопределенных параметров (из вопросов письменного экзамена Jingdong Autumn Recruitment Questions)

以下哪些是HTTP请求中浏览器缓存机制会用到的协议头？
A Last-Modified 
B Etag
C Referer
D Authorization

答案: A B

3.4 HTTP-методы

Кажется, в последнее время ведутся споры о разнице между post и get. Поскольку все они являются протоколами прикладного уровня, мы могли бы также вернуться к сути и взглянуть на них. Давайте сначала рассмотрим методы http, а затем поговорим о разнице между post и get.

3.4.1 Методы HTTP

ПОЛУЧИТЬ: получить ресурс
POST: передать тело объекта
ПОСТАВИТЬ: передать файл
HEAD: Получить заголовок сообщения
УДАЛИТЬ: удалить файл
ВАРИАНТЫ: Методы поддержки запросов
TRACK: отслеживать путь
ПОДКЛЮЧЕНИЕ: для подключения к прокси-серверу требуется протокол туннелирования.

3.4.2 Разница между GET и POST

Оговаривает ли соглашение вскоре поведение и согласие обеих сторон на прикладном уровне? Итак, давайте взглянем на браузер и сервер соответственно.

Браузер:

GET — это данные запроса, использующие URL или Cookie для передачи параметров. POST — это тело объекта передачи, поэтому параметры будут помещены в тело сообщения.
Данные GET помещаются в URL-адрес, а браузер имеет ограничение на размер URL-адреса, поэтому размер данных ограничен. POST — это тело объекта передачи, поэтому ограничений по размеру нет.
Данные GET помещаются в URL-адрес, поэтому безопасность определенно не высока, поэтому их нельзя использовать для передачи конфиденциальной информации. POST относительно безопасен
GET — это данные запроса, поэтому URL-адрес может идти назад, а POST не отправляет данные (сообщение будет идти назад в chrome).
GET — это запрос, поэтому он будет активно кэшироваться браузером, а POST — для отправки данных, поэтому он не будет установлен, если не будет установлен вручную.

сервер:

get — поместить параметры в URL для обработки
И post запускает событие запроса, отслеживаемое на сервере, сервер может его обработать, влияя на возвращаемый результат.

Если вы не понимаете этого здесь, рекомендуется сначала взглянуть на фактический боевой код в этом разделе:2.6 Реализация протокола кэширования браузера

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

«Самая большая разница между GET и POST заключается в том, что запросы GET являются идемпотентными, а запросы POST — нет. Идемпотентность означает, что однократный и многократный запрос определенного ресурса должен иметь одни и те же побочные эффекты. Проще говоря, это означает, что несколько запросов на тот же URL Запрос должен возвращать тот же результат."

Ответил так много, я не знаю, если вы нашли его. Все поведение браузера основано на относительной реакции этих двух действий. Итак, когда использовать get и когда использовать post?

Пользуйтесь по договору, разве это не все оговорено для вас? Используйте get при запросе данных и post при передаче тел сущностей.

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

4 Браузеры и протоколы

4.1 XHR и АЯКС

Интерфейсным инженерам AJAX слишком знаком, мы знаем, что он используется для отправки http-запросов. Так какое же это имеет отношение к http? Итак, давайте сначала напишем AJAX.

Полное название AJAX — асинхронный JavaScript и XML (асинхронный js и XML). Асинхронный js нам проще понять. Так что же такое XHR?
Полное имя XHR — XMLHttpRequest, то есть HTTP-запрос XML. По сути, это API уровня браузера. С точки зрения непрофессионала, это функция http, которую браузер инкапсулирует для вас.

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

Итак, как мы понимаем, что XHR — это API уровня браузера?

Когда мы находимся на сервере узла, мы знаем, что нам часто нужно манипулировать данными в заголовке запроса, например, выполнять соответствующую обработку в соответствии с механизмом сжатия в заголовке запроса. Но когда мы используем ajax для получения данных во внешнем интерфейсе. Не беспокойтесь о сжатии, потому что XHR — это API уровня браузера. Он скрывает от нас много низкоуровневой обработки, такой как сжатие, кэширование. Другими словами, браузер не открыт для вас, чтобы делать эти вещи.
Подводя итог, на самом деле очень легко понять, что наши веб-страницы работают в браузере, хотя браузер и интеллектуален, но также универсален и не настроен под нас. Это также причина, по которой веб-приложения не так гладки, как нативные приложения. Исходное звуковое приложение можно понимать как (браузер + страница). Веб-приложение предназначено для записи контента в браузере.

Однако браузер, просто отправляющий HTTP-запросы, не может удовлетворить наши повседневные потребности в разработке. Чтобы выполнить больше функций, у нас есть длинный опрос, и браузер также предоставляет API веб-сокета. Это записывает функции, специально связанные с бизнес-сценариями. Если у вас есть возможность, напишите один.

Вопрос: Мы знаем, что браузеры накладывают на нас множество ограничений, так как же это влияет на конкретный бизнес?

4.2 Безопасность браузера и междоменный доступ

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

Тогда у нас есть три общих решения:

jsonp: это замаскировать запрос под тег для запроса. Поскольку тег отправляет запрос самим браузером, на него не распространяется политика того же источника.
Прокси-сервер: Это тоже легко понять.Я отправляю все запросы на прокси-сервер, который не является междоменным.Сервер - это то, что мы говорим, до тех пор, пока данные возвращаются в браузер после обработки.
CORS: Это то, о чем мы в основном говорим сегодня. Поскольку звонок должен быть привязан к звонку, поскольку это ваше ограничение, вы должны дать мне решение. Решение, данное браузером, (CORS)

Метод cors тоже очень прост:

Если браузер обнаружит, что вы пересекли домен, он отправит заголовок запроса Origin с исходным IP: http://localhost:8088
Спросите у сервера, хотите ли вы, чтобы localhost:8088 имел доступ к вашим файлам, и, если браузер согласен, ответьте Access-Control-Allow-Origin: http://localhost:8088 . Указывает, что к этому IP можно получить доступ
Затем сервер инициирует формальный запрос
Если сервер не возвращает браузеру Access-Control-Allow-Origin или не разрешает доступ к этому адресу, браузер сообщит об ошибке междоменного запроса

Конечно, в целях безопасности запросы CORS будут игнорировать учетные данные пользователя, такие как файлы cookie и аутентификация HTTP. Если вы хотите использовать его, также отправьте некоторые параметры в заголовке запроса с Origin. Сервер также говорит браузеру согласиться или не согласиться при первом возвращении.

Демонстрация кода: узел 2.8 обрабатывает междоменный код

5 http разработка

5.1 с HTTP1.0 на http1.1

В HTTP 1.0 при каждой отправке HTTP-запроса устанавливается TCP-соединение, а затем разрывается.

Во времена http1.1 был введен механизм Connection:keep-alive, после того как соединение не разорвано, запрос можно продолжать отправлять.
Но на каждую просьбу приходится первой возвращаться, второй уходить. Позже в браузере появилось конвейерное соединение конвейерной обработки.

В TCP-соединении можно распараллелить несколько HTTP-запросов, и следующий HTTP-запрос инициируется до завершения ответа на предыдущий HTTP-запрос. Это не требует от вас его настройки.Введен Connection:keep-alive, и браузер будет обрабатывать его автоматически. Но есть еще одна проблема, потому что порядок, в котором сервер HTTP1.1 возвращает данные ответа, должен быть таким же, как и порядок, в котором их запрашивает клиент, который требует «первым пришел — первым обслужен». Поэтому легко заставить главу команды заблокировать. То есть, если ваш первый запрос не возвращается, вам придется ждать там.

Итак, основное внимание в этом разделе уделяется тому, что http2 решает проблему блокировки в начале очереди. Но http2 основан на https, так что давайте сначала изучим https

5.2 HTTPS

HTTPS — это улучшение недостаточной безопасности HTTP.Давайте сначала рассмотрим недостатки безопасности HTTP.

сообщение является открытым текстом
Личность корреспондента не установлена
Не удалось подтвердить целостность сообщения

** Итак, HTTS = HTTP + шифрование + аутентификация + защита целостности **

Итак, теперь давайте посмотрим, как шифровать и расшифровывать, не так ли?

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

Теперь мы знаем, что данные шифруются и расшифровываются с помощью закрытого ключа и сертификата. Таким образом, протокол HTTPS заменяет часть интерфейса связи HTTP протоколом SSL. Процесс, о котором мы только что говорили, является содержанием протокола SSL. Он был изобретен Netscape, а затем передан IETF, который разработал TLS (переименованный) на основе SSL.

Демонстрация кода: 3.1 Создание HTTPS-узла сервера

5.2 HTTP2.0

Теперь, наконец, мы подошли к http2. Помните, что мы говорили о блокировке противников http1.1. Эта проблема решена для http2.

(1) Мультиплексирование не следует FIFO.

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

(2) http2 определяет приоритет запроса

Мы можем сделать так, чтобы некоторые важные запросы загружались первыми. Браузер также интеллектуально отображает страницу в соответствии с правилами приоритета, определенными http2.

(3) Сжатие заголовка

Мы знаем, что используем Gzip для сжатия тела сообщения. http2 также сжимает заголовок. Не стоит недооценивать заголовок сообщения, заголовок сообщения общей веб-страницы может составлять 40% сообщения. После сжатия его можно уменьшить примерно на 60%.

(4) С точки зрения производительности добавлен новый уровень двоичного кадрирования. Он также был значительно улучшен. Слой минутной стрелки соответствует http-сообщению. Итак, http/1.1 — это текстовый протокол, а http2 — полностью бинарный протокол.

Далее давайте потренируемся.

В итоге надоело писать. . . Я не думаю, что эта статья завершена. Надпись позади слишком грубая. Я медленно меняюсь. Расширьте и напишите, когда у вас будет время.