[Основные] Принципы и применение протоколов HTTP и TCP/IP

предисловие

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

Контур

• что происходит, когда вы посещаете веб-страницу
• Классическая сетевая пятислойная модель
• URI, URL и URN
• Набор протоколов TCP/IP
• TCP-соединение
• Трехстороннее рукопожатие TCP и четырехсторонняя волна
• Определение HTTP
• История развития HTTP
• Состав HTTP-сообщения
• HTTP-согласование данных
• длинное HTTP-соединение
• HTTP-кеш
• Политика одинакового происхождения браузера
• Схема оптимизации производительности HTTP

что происходит, когда вы посещаете веб-страницу

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

Первый шаг — найти IP-адрес сервера.

Когда пользователь вводит URL-адрес и нажимает клавишу ввода, браузер получает доменное имя. В реальном процессе коммуникации браузеру нужноIPадрес. чтобы достичьIPадрес, браузер выполнит следующие операции, обычно мы используем браузер, чтобы найти соответствующий адрес через доменное имяIPповедение называетсяDNSРазбор.

1. Найдите локальный кеш вашего браузера
2. Найдите жесткий дискhostфайл, есть ли запись этого доменного имени иIPотношения отображения
3. Я действительно не мог его найти, поэтому мне пришлось обратиться к провайдеру доменного имени, чтобы проверить его через сетевую ссылку.

Второй шаг — установить соединение TCP/IP.

1. Браузер получает соответствующий серверIP, будет соответствоватьIPсервер отправленTCPЗапрос на подключение.
2. Ответ сервера на получение запроса после того, как обе стороны неоднократно подтвердили установлениеTCP 双向连接.

От клиента, инициирующего запрос на соединение, доTCPУстановление соединения, процесс, называемый三次握手.

Если запрос HTTPS, также необходимоTCPподключиться, затем пройтиSSLилиTLSОбеспечить зашифрованную обработку данных, проверку личности другой стороны и целостности данных для обеспечения безопасности передачи данных.

Третий шаг — запросить ресурсы

1. TCPПосле создания соединения браузер начинает отправлять официальнуюHTTPзапрошенный пакет.
2. Сервер принимает запрос, анализирует запрос и возвращает пакет данных, требуемый клиентом после обработки данных.

Четвертый шаг, рендеринг в браузере

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

Пятый шаг, кеш браузера

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

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

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

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

Слой приложений:

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

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

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

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

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

канальный уровень

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

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

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

URI, URL и URN

дляURLВ принципе мы с ним знакомы, ноURIа такжеURNможет меньше осознавать,URI,URLа такжеURN— это стандартный способ идентификации, поиска и именования ресурсов в Интернете.

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

URI

• Унифицированный идентификатор ресурса, Унифицированный идентификатор ресурса, называемыйURI.
• У каждого веб-сервера есть одинURIИдентификатор, который является уникальным в мире для идентификации и локализации информационных ресурсов, ресурсной информации сURIПосле идентификации доступ к ресурсу возможен через фиксированный адрес в сети Интернет.
• Он имеет две формы: URN (унифицированное имя ресурса), URL (унифицированный указатель ресурса), что означаетURLа такжеURNявляется его подмножеством.

URL

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

полныйURLСлева направо он содержит следующие разделы:

1. schemaИдентифицирует протокол доступа, на котором основан этот адрес ресурса, например:HTTPа такжеFTP.
2. user informationИнформация о пользователе идентифицируется (если ресурс требует аутентификации информации о пользователе), но, как правило, текущая аутентификация не использует этот метод, во-первых, очень хлопотно вводить, а во-вторых, небезопасно.
3. hostИнформация о домене, идентифицирующая ресурс, которая может быть именем домена илиIP, функция этого блока — найти адрес физического сервера, на котором хранится ресурс.
4. portНомер порта, физический сервер, открывая разные порты, может одновременно запускать несколько веб-серверов, файлы ресурсов будут развернуты в определенном месте веб-сервера, а номер порта используется для определения местонахождения веб-сервера, на котором находится ресурс. существует.
5. pathПуть или маршрут, на веб-сервере есть много каталогов.Как правило, путь используется для поиска каталога, в котором хранятся файлы ресурсов. Поскольку многие веб-приложения сейчас очень большие, этот путь не обязательно является адресом каталога, но также может быть адресом запроса файла статического ресурса, указанного веб-сервером.
6. queryстрока запроса, обычно используемая дляGETЗапрос, передать параметры запроса.
7. fragmentФрагменты, хэши или привязки в основном используются для позиционирования интерфейсных документов или в качестве средства управления переходами маршрутизации во время внешнего рендеринга.

Здесь следует отметить, чтоURLотличается от URL-адресов.URLОн не только содержит адрес ресурса веб-страницы, но также включает гипертекстовые ресурсы, такие как изображения и видео, необходимые для создания веб-страницы, а также адреса ресурсов, такие как css js. URL-адрес по существуIPБолее избирательное сопоставление адресов вDNSПосле синтаксического анализа первое, что получает браузер, — это html-документ.URLАдрес, согласно синтаксическому анализу HTML-документа браузером, продолжает проходить через другие файлы ресурсов на веб-странице.URLПолучите соответствующий файл ресурсов.

URN

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

Набор протоколов TCP/IP

TCPУстановление соединения является обязательным шагом в успешной сетевой коммуникации, поэтомуTCP/IPЭто также стало очень важным пунктом знаний.

TCP/IPПротокол (Transmission Control Protocol/Internet Protocol) — это не простой протокол, а набор специальных протоколов, в том числе: TCP, IP, UDP, ARP и т. д. Они называются подпротоколами. Среди этих соглашений наиболее важным и известным являетсяTCPа такжеIP. Поэтому мы привыкли называть все семейство протоколовTCP/IP.

• IP-протокол
  • IPПротоколы делают Интернет сетью, позволяющей соединять разные типы компьютеров и разные операционные системы.
  • IPадресIPУнифицированный формат адреса, предоставляемый протоколом, он назначает логический адрес каждой сети и каждому хосту в Интернете, который эквивалентен временному имени этой машины, и другие машины могут найти его по этому имени, а затем могут устанавливать соединения. друг с другом общаться и общаться.
• TCP-протокол
  • TCPПротокол представляет собой полнодуплексный протокол, ориентированный на соединение, поэтому и клиент, и сервер могутTCPПолучать и отправлять данные пиру по каналу соединения.
  • TCPв сравнении сUDPЕго преимущество заключается в стабильности передачи: перед передачей данных необходимо установить соединение через трехстороннее рукопожатие, в процессе передачи данных необходимо убедиться, что данные передаются на противоположный конец упорядоченным и полным образом.
  • TCPв сравнении сUDPНедостатком является его сложность, установление и отключение соединения являются относительно большими затратами на производительность, и как только процесс передачи данных зависает, последующие данные должны ждать отправки предыдущих данных, прежде чем последующие данные смогут продолжить передачу.
  • Поддерживается каждым серверомTCPКоличество подключений ограничено, что также делаетTCPСвязи становятся дефицитным ресурсом, который нельзя тратить впустую.
• UDP-протокол
  • UDPПротокол не требует установления соединения и не требует установления соединения перед передачей данных.
  • UDPРабота заключается только в обработке пакетов, и она не отвечает за упорядоченную доставку на противоположный конец без потерь, поэтому она склонна к потере пакетов.
  • UDPПоддерживает не только режим передачи «один к одному», но также поддерживает режимы «один ко многим», «многие ко многим» и «многие к одному», то естьUPDОбеспечивает функции одноадресной, многоадресной и широковещательной передачи.
  • UDPв сравнении сTCPПреимущество в том, что он легкий, эффективный и гибкий, его нужно использовать в некоторых сценариях с высокими требованиями к приложениям реального времени.UDP, такие как прямая трансляция, видеоконференция, LOL и другие боевые игры в реальном времени.
  • UDPв сравнении сTCPНедостатком является его ненадежность и нестабильность.

TCP-соединение

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

в различныхHTTPВ версии протокола этоTCPМеханизм создания и сохранения каналов подключения также отличается.

• существуетHTTP1.0в, каждый разHTTPзапросы создадутTCPсоединение, после отправки запроса и ответа сервера, этоTCPСоединение автоматически разрывается.
• существуетHTTP1.1, вы можете установить вручнуюConnection： keep-aliveзаголовок запроса на созданиеTCPпостоянные соединения, несколькоHTTPЗапросы могут совместно использоватьTCPсоединять. ноTCPСоединение блокируется в начале очереди, то есть несколько запросов ставятся в очередь на отправку.По истечении времени ожидания запроса последующие запросы могут быть только заблокированы.
• существуетHTTP2, используется мультиплексирование каналов, поэтомуTCPСоединения поддерживают одновременные запросы, то есть несколько запросов могут выполняться параллельно в одном соединении в одно и то же время. Определенная задача запроса занимает много времени и не повлияет на нормальное выполнение других соединений, поэтому большинство запросов могут использоватьTCPподключение без создания новогоTCPКанал соединения не только экономит накладные расходы на трехстороннее рукопожатие, но и экономит обслуживание сервера.TCPСтоимость порта.

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

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

Совет: ОACK,FIN,SYNЗначение кодов состояния

1. ACKОн используется для подтверждения, что означает уведомление другой стороны о том, что я получил сообщение от вас.
2. FINИспользуется для завершения, это означает сообщить другой стороне, что моя сторона закончилась, все данные отправлены, последующего вывода нет, и соединение запрошено на разрыв.
3. SYNОн используется для синхронизации и установления соединения, что означает информирование другой стороны о том, что я запрашиваю синхронное соединение.

1. Первое рукопожатие: клиент отправляет серверу запрос на подключениеSYNСегмент сообщения содержит свой начальный порядковый номер передачи данных.После отправки запроса клиент входит вSYN-SENTусловие.
2. Второе рукопожатие: после того, как сервер получит сегмент запроса на подключение, если он согласен на подключение,отправитACKа такжеSYNОтвет информации о сообщении, ответ также будет содержать свой собственный начальный порядковый номер передачи данных.(Во время отключенных «Четырех волн»,ACKа такжеSYNЭти два сообщения отправляются независимо как два ответа, поэтому будет четыре взмаха рук), и сервер войдет после завершения отправки.SYN-RECEIVEDусловие.
3. Третье рукопожатие: когда клиент получает ответ о согласии на подключение, он также отправляет подтверждающее сообщение на сервер. После того, как клиент отправляет этот сегмент, он входитESTABLISHEDсостояние, сервер также входит после получения этого ответаESTABLISHEDСтатус, в настоящее время соединение установлено успешно.

Один из вопросов, который могут задать во время собеседования: зачем нужно трехстороннее рукопожатие, если связь можно определить двумя рукопожатиями? Потому что из-за многих неконтролируемых факторов, таких как сетевые причины, это может привести к тому, что первый запрос поступит на сервер через долгое время.В это время клиент долго ждал ответа, а ранее инициированный запрос истекло время ожидания, и клиент отказался от него Drop больше не продолжает охранять монитор. Однако через долгое время сервер получил брошенный отложенный запрос и запустил новый, инициируя ответ.TCPПодключитесь к порту и ждите там клиента. Сервер может поддерживатьTCPСоединения ограничены, и эта пустая бесполезная ссылка будет тратить ресурсы на сервере. Итак, сервер отправляетSYNа такжеACKПосле ответа необходимо получить повторное подтверждение от клиента, прежде чем соединение между двумя сторонами может быть официально установлено. Трехстороннее рукопожатие позволяет избежать проблемы дополнительных накладных расходов на сервер из-за задержки в сети.

помахал четыре раза

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

1. Первая волна: клиент считает, что все данные на его стороне были отправлены, поэтому он отправляетFINИспользуется для закрытия передачи данных от клиента к серверу.После завершения передачи клиент входит вFIN_WAIT_1условие.
2. Вторая волна: сервер получает сообщение, отправленное клиентомFINПозже прикладному уровню будет предложено разорвать TCP-соединение и отправитьACKДля клиента это означает, что он получил запрос на освобождение от клиента и больше не будет принимать данные, отправленные клиентом.CLOSE_WAITположение дел.
3. Третья волна: Если на сервере все еще есть данные, которые не были отправлены в это время, он может продолжить отправку.После отправки сервер также отправит сообщение об освобождении соединения.FINЗапрос используется для закрытия передачи данных от сервера к клиенту, после чего сервер входитLAST_ACKусловие.
4. Четвертая волна: клиент получает серверFINПосле запроса отправить последнийACKна сервер, затем введитеTIME_WAIT_2состояние, это состояние будет длиться 2MSL (максимальное время жизни сегмента, которое относится к времени, в течение которого сегмент сохраняется в сети, тайм-аут будет отброшен) время, если в течение этого периода времени от сервера не будет запроса на повторную передачу, клиент войтиCLOSEDСтатус.После того как сервер получит ответное сообщение, он также войдетCLOSEDсостоянии, процесс четырехкратного махания руками завершен, и обе стороны официально разъединены.

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

1. Клиент: Здравствуйте, я в порядке.
2. Сервер: О, ты в порядке? Я знаю, я не в порядке, подожди минутку.
3. Сервер: Хорошо, теперь я тоже в порядке.
4. Клиент: Да, в этот раз я хорошо провел время, мы договоримся о встрече в следующий раз.

Некоторые интервьюеры могут спросить, почему три рукопожатия для установления соединения и четыре раза для отключения? Это связано с тем, что в процессе установления соединения сервер получает клиента, но запрос на соединение устанавливается.SYNПосле сообщения,ACKа такжеSYNПоместите его в сообщение и отправьте клиенту. Когда соединение закрыто, сервер получает клиентскийFINСообщение просто означает, что клиент больше не отправляет данные, но все еще может получать данные, а на сервере могут быть еще данные, которые не были отправлены, поэтому они не могут быть отправлены немедленно.FINсообщение, может быть отправлено только первымACKСообщение сначала отвечает клиенту, и только после подтверждения того, что все данные были отправлены на его собственной стороне, будет отправлено.FIN. Итак, при отключении серверACKа такжеFINКак правило, они отправляются отдельно, что приводит к тому, что для отключения требуется на одну операцию отправки больше, чем для запроса подключения.

Определение HTTP

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

HTTPПротокол — это аббревиатура от Hyper Text Transfer Protocol (Протокол передачи гипертекста), который обычно работает наTCPВыше, через браузер и сервер для взаимодействия данных, предусмотрена передача гипертекста (текст, изображения, видео и т. д.). То есть,HTTPПротокол определяет правила, которым необходимо следовать при передаче гипертекста.

1. HTTPПротоколы не имеют состояния. Это означает, что клиент и сервер не могут узнать информацию о текущем состоянии друг друга.HTTPСам запрос не содержит никакого хранилища состояния. Но на практике клиент и сервер должны требовать государственной аутентификации и взаимодействия, поэтому введениеCookie, используемый для хранения некоторой информации о состоянии текущего браузера, каждый раз через независимыйHTTPЗапрос отправляется и принимается для решения этой проблемы.
2. HTTPзапросы не зависят друг от друга.HTTPКаждый из них представляет собой самостоятельный индивидуальный запрос.В большинстве случаев, когда клиент запрашивает веб-страницу, это не является успешным запросом.Сначала отвечает сервер.HTMLстранице, и после того, как браузер получит ответ, он обнаружит, что страница также ссылается на другие ресурсы, такие как файлы CSS, JS, изображения и т. д., и также автоматически отправитHTTPЗапросите доступ к этим необходимым ресурсам.
3. HTTPпротокол, основанный наTCPпротокол.HTTPЦелью протокола является указание формата и поведения взаимодействия данных при передаче данных клиента и сервера, и он не несет ответственности за детали передачи данных.TCPосуществленный. Используемая в настоящее время версия является постоянным соединением по умолчанию, т. е. несколько раз.HTTPзапрос на использованиеTCPсоединять.

Уведомление:HTTPзапрос иTCPСвязи не те,HTTPвTCPЗапрос передачи инициирован на основе соединения, в том жеTCPПод каналом соединения вы можете отправить несколькоHTTPЗапрос, например, это отношения между шоссе и автомобилем.

История развития HTTP

HTTP версии 0.9

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

HTTP версии 1.0

• Добавлено много команд,HEAD,POST,PUT,DELETEЖдать.
• Добавленstatus codeкод состояния иheaderзаголовки запросов и ответов.
• Добавлена ​​поддержка нескольких кодировок, многокомпонентная отправка, разрешения, кэширование и многое другое.
• можно включить черезConnection： keep-aliveуказать использованиеTCPДлинное соединение

HTTP 1.1 (в настоящее время широко используется)

• Постоянные подключения поддерживаются по умолчанию
• По умолчанию поддерживается PersistentConnection, который по умолчанию включен.Connection： keep-alive.
• Поддерживает конвейерную обработку запросов, т.е.TCPМожно отправить несколько соединенийHTTPзапрос и ответ.
• повысилсяhostполя заголовка запроса, черезhostСинтаксический анализ позволяет запускать несколько программных служб на одном физическом сервере, что значительно повышает эффективность использования сервера. токnginxОбратный прокси основан наHTTPв заголовке запросаhostразличать разные запросы, чтобы проксировать эти запросы к разным программным службам на одном сервере.

HTTP 2.0

• HTTP1.xПашин основан на тексте и имеет анализ недостатков; покаHTTP2.0Вместо этого напрямую используйте метод бинарного синтаксического анализа.HTTP 1.XРазбор строк более эффективен и надежен.
• HTTP2.0Все данные передаются в «кадрах», поэтому больше не нужно последовательно возвращать несколько запросов, отправленных по одному и тому же соединению, и можно обеспечить параллельную передачу данных.
• HTTP2.0Информация заголовка сжатия используется для оптимизации объема передаваемых данных.HTTP1.xЗаголовки запроса несут много информации, и каждый раз их приходится отправлять повторно,HTTP2.0использоватьencoderЧтобы уменьшить размер заголовка запроса, который необходимо передать, каждая сторона связи кэширует копию.header fieldsТаблица не только позволяет избежать повторной передачи, но и уменьшает размер передаваемой информации.
• HTTP2.0недавно добавленныйserver push(server push), сервер может активно инициировать отправку некоторых данных. Например, когда сервер получает сообщение от браузераHTMLОдновременно с запросом он может активно передавать клиенту соответствующие файлы ресурсов (js/css) и отправлять их параллельно для повышения эффективности передачи и рендеринга веб-страницы.
• В настоящее время, если вы хотите использоватьHTTP2нужно использовать в первую очередьHTTPSНа этой основе можно использоватьHTTP2

HTTP 2.0в сравнении сHTTP 1Самое интуитивно понятное улучшение производительности загрузки изображений, которое вы можете увидетьHTTP 2Официальная демонстрация повышения производительности

HTTPS

Мы часто видим плавающие всплывающие окна или рекламу на некоторых веб-страницах, а иногда даже видим эту спам-рекламу на веб-страницах, которые мы написали.Однако разработчики явно не это написали, а такая ненужная информация Как она попала вверх? Основная причина кроется в различных прокси-сервисах, когда мы инициируемHTTPЗапрос не передается напрямую на целевой сервер, и в течение этого периода он будет проходить через уровни прокси-сервисов.Мы обычно используемnginx, И вDNSВсе операторы широкополосного доступа, которые должны быть переданы в процессе синтаксического анализа, являются прокси-сервисами. из-заHTTPПри использовании незашифрованных строк для передачи данных эти данные могут быть легко прочитаны или даже изменены промежуточной службой, после чего промежуточная служба получает оригинал.HTMLДанные, в него несложно вставить небольшую рекламу.

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

HTTPSЭто на самом деле расширенная версия.HTTP 1.1Следует отметить несколько моментов:

1. HTTPSсоглашение должноCAПодать заявку на сертификат, вообще бесплатных сертификатов очень мало, и нужно платить пошлину
2. HTTPПротокол работает наTCPВыше весь передаваемый контент в открытом виде,HTTPSдействующийSSL/TLSнад,SSL/TLSдействующийTCPВыше весь передаваемый контент шифруется.
3. HTTPа такжеHTTPSОн использует совершенно другой метод подключения и использует другие порты.80, последний443.
4. HTTPSЭто может эффективно предотвратить угон носителя и решить большую проблему защиты от угона.

Состав HTTP-сообщения

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

первая строка

Первая строка не принадлежитHttp Headers, который содержит:

1. HTTP Method(GET,POST,PUT,DELETEд.), разныеHTTP Methodимеют разные значения.

   HTTP Method	соответственно
   GET	Обычно используется для получения ресурсов сервера
   POST	Обычно используется для передачи тела объекта
   PUT	Обычно используется для передачи файлов
   DELETE	для удаления файлов
   HEAD	Он используется для получения заголовка сообщения и не возвращает тело сообщения.
   OPTIONS	Метод, используемый в предварительном запросе для запроса поддержки ресурсов URI запроса.

   HTTP MethodТолькоHTTPНорма, продвигаемая протоколом, напримерESLint, вы можете следовать или не следовать, то, что они делают, по сути то же самое, но семантика более явная.

2. URLАдрес запрошенного ресурса, этот адрес будет содержать только запрошенный адрес маршрутизации.

3. версия протокола,HTTP 1.0 / HTTP 1.1 / HTTP 2.

4. Код состояния возврата HTTP(указывается в первой строке ответного сообщения)

   HTTPОпределено 40 стандартных кодов состояния, которые можно использовать для передачи результатов клиентских запросов.Коды состояния делятся на следующие пять категорий.Информацию о возвращаемых кодах состояния для каждого сегмента см.Код HTTP-ответа:

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

HTTP-заголовки

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

основной корпус

предмет, то естьHTTP body,HTTP HeaderСообщение и основное сообщение разделяются пустой строкой + перевод строки.HTTP bodyНекоторая конкретная деловая информация запроса обычно помещается в

HTTP-согласование данных

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

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

• AcceptПоле заголовка запроса, указывающее ожидаемый тип данных
• Accept-EncodingПоле заголовка запроса указывает метод кодирования, в котором должны быть переданы нужные данные. Оно часто используется для ограничения метода сжатия данных сервером. Этот метод используется в стандартном сжатии GZIP, оптимизированном для размера пакета JS-файла.
• Accept-LanguageПоле заголовка запроса указывает желаемый тип языка данных: китайский, английский или другие языки.Это поле заголовка обычно добавляется браузером автоматически.
• User-AgentПоле заголовка запроса указывает информацию о браузере этого запроса.Сервер может выбирать страницы с различной совместимостью для возврата пользователю на основе этой информации или вести статистику по информации о браузере пользователя, операционной системе и другим данным.
• Content-TypeПоле заголовка ответа в заголовке запросаAcceptПоле может указывать несколько допустимых форматов данных, и сервер в конечном итоге вернет формат данных клиенту.
• Content-EncodingПоле заголовка ответа, соответствующееAccept-Encoding
• Content-LanguageПоле заголовка ответа, соответствующееAccept-Language

длинное HTTP-соединение

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

существуетHTTP 1.0введен вConnectionполе заголовка, которое разрешено устанавливатьKeep-AliveилиCloseчтобы решить, следует ли повторно использовать TCP-соединение или закрыть его сразу после завершения запроса. пока вHTTP 1.1По умолчанию оба конца будут включать это поле по умолчанию, то есть поддержка по умолчаниюHTTPдолгая связь.

нужно знать, это:Connection: Keep-AliveОба конца должны быть включены одновременно, чтобы начатьHTTPдолгое соединение, если какой-либо сегмент установлен вручнуюConnectionдляClose, длинное соединение не может быть обнаружено, так как установление и сохранение TCP-соединения — это интерактивный процесс с двумя терминалами.

Итак, как мы видим локальноTCPКак насчет идентификатора соединения, вы можете открытьChromeинструменты отладки для просмотра:

Как видно на рисунке, есть разныеConnection ID, что означает, что этот запрос на самом деле открывает новыйTCPсоединение, нижняя часть запросаConnection IDодинаковые, представляющие несколькоHTTPЗапрос повторно использует один и тот жеTCPсоединять.

Максимальное количество одновременных TCP-подключений, которое может поддерживать браузер Chrome, равно6, И вHTTP 2.0нижеHTTPверсии запрос блокируется. То есть, как только шесть соединений заполнены, а предыдущий запрос не выполнен, последующий запрос будет заблокирован до тех пор, пока предыдущий запрос не вернется, и последующие запросы могут быть отправлены.

HTTP-кэш

Хотя кэширование HTTP не требуется, часто необходимо повторно использовать кэшированные ресурсы. Однако обычные кэши HTTP могут хранить только ответы GET и ничего не могут делать с ответами других типов. Ключ к кэшированию в основном включаетrequest methodи целевой URI (обычно кэшируются только запросы GET).

стратегия чтения кэша

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

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

• Service Worker
• Memory Cache
• Disk Cache
• сетевой запрос

Service Worker

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

• Сначала поиск в браузере.
• постоянное хранение.
• Вы можете более гибко управлять хранимым содержимым, выбирать файлы для кэширования, определять правила сопоставления маршрутов для кэшированных файлов и т. д.
• Его можно посмотреть по F12 в Chrome, Application -> Cache Storage.

Memory Cache

• memory cacheявляется хранилищем кеша в памяти.
• Быстрое чтение.
• Место для хранения небольшое.
• Время хранения короткое, когда браузерtabСтраница закрывается, а ресурсы памяти освобождаются.
• Если явно указаноCache-Controlдляno-store, браузер не будет использоватьmemory-cache.

Disk Cache

• Disk CacheКэш-память на жестком диске.
• читать медленнее, чемMemory Cache, быстрее сетевых запросов.
• Место для хранения большое.
• постоянное хранение.
• Disk CacheСтрого следоватьHTTPПоля в заголовке для определения возможности кэширования ресурса, аутентификации и т. д.
• Часто слышимые «принудительный кеш», «контрастный кеш» и т.д.Cache-Controlд., попадают в эту категорию.

сетевой запрос

Если ни один из запрошенных файлов ресурсов не соответствует указанной выше политике кэширования, будет инициирован сетевой запрос. После того, как браузер получит ресурс, он добавит новый ресурс в кеш.

Cache-Control

Заголовок Cache-Control, определенный в HTTP/1.1, используется для обозначения поддержки механизма кэширования.Этот атрибут поддерживают как заголовки запросов, так и заголовки ответов. Стратегия кэширования определяется различными значениями, которые она предоставляет. Следует отметить, что сценарии с быстрой сменой данных не подходят для открытияCache-Control.

инструкция	эффект
public	Общедоступный кэш: указывает, что ответ может быть кэширован любым посредником (например, промежуточным прокси, CDN и т. д.).
private	Частный кеш: указывает, что ответ предназначен для одного пользователя, посредник не может кэшировать ответ, и ответ может использоваться только в частном кеше браузера.
max-age	(единица/секунда) Установите время истечения кэша, если он истекает, вам нужно повторно запросить, иначе локальный кеш читается и запрос фактически не отправляется.
s-maxage	(единица/секунда) Переопределить max-age, эффект тот же, действует только на прокси-сервере
max-stale	(единица/секунда) указывает, что этот просроченный кеш используется, даже если срок действия кеша истек
no-store	Отключить кеширование
no-transform	Ресурс не должен быть преобразован или сжат, а заголовки HTTP, такие как Content-Encoding, Content-Range и Content-Type, не могут быть изменены прокси-сервером (иногда, когда ресурс относительно велик, прокси-сервер может выполнять обработку сжатия самостоятельно). , чтобы предотвратить это).
no-cache	Обязательное подтверждение кеша: то есть перед каждым использованием локального кеша нужно запрашивать у сервера проверку недействительности кеша, если срок его действия не истек (примечание: на самом деле возвращает 304), то кеш будет только использовать копию локального кэша.
must-revalidate	Подтверждение проверки кеша: означает, что кеш должен проверить свое состояние, прежде чем рассматривать использование устаревшего ресурса, а кеш с истекшим сроком использования не будет использоваться.
proxy-revalidate	То же, что и must-revalidate, но работает только для общих кэшей (таких как прокси) и игнорируется частными кэшами.

проверка кеша

В процессе использования кэша в браузере, чтобы сотрудничать без кэша в Cache-Control, нам также нужен механизм для проверки того, действителен ли кеш. Например, ресурсы сервера обновляются, и клиент должен вовремя обновлять кеш; или ресурсы клиента истекли истек, но ресурсы на сервере все еще старые, и в настоящее время нет необходимости повторно проходить. Проверка кеша используется для решения этих проблем. В HTTP 1.1 мы в основном сосредоточены на следующемLast-Modifiedа такжеETagэти два поля.

Last-Modified

Как следует из названия, это время последней модификации ресурса. Когда клиент обращается к ресурсам сервера, серверLast-ModifiedЗначение возвращается клиенту. После того, как клиент его получит, сервер вернет его при следующей отправке запроса.Last-Modifiedзначение, загруженное вIf-Modified-SinceилиIf-Unmodified-Since, отправленный на сервер для проверки кеша.

Таким образом, сервер может читатьIf-Modified-Since(чаще используется) илиIf-UnModified-Sinceзначение, а местныеLast-Modifiedзначение для сравнения. Если проверка обнаружит, что эти два значения совпадают, это означает, что запрошенный файл ресурса на этот раз не был изменен, тогда сервер сообщит браузеру, что ресурс действителен и может продолжать использоваться, в противном случае последний ресурс нужно использовать.

Взгляните на два изображения ниже:

при запросе сервераscript.js, вы можете видеть, что сервер вернулсяLast-Modified, который записывает время последней модификации ресурса

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

Давайте взглянем на часть кода на стороне сервера:

const http = require('http');
const fs = require('fs');
http.createServer((request, response) => {
   const ifModifiedSince = request.headers['If-Modified-Since'];
   const lastModified = 'Web Aug 19 2019 19:01:15 GMT+0800 (China Standard Time)';
    
   if (request.url === '/') {
       const html = fs.readFileSync('test.html', 'utf-8');
       
       response.writeHead(200, {
           'Content-Type': 'text/html'
       });
       response.end(html);
   }
   if (request.url === '/script.js') {
       const js = fs.readFileSync('script.js', 'utf-8');
       let status = 200;
       // 如果读取到的 If-Modified-Since 和 lastModified 相同，则设置头部 304 表示可使用缓存
       if (ifModifiedSince === lastModified) {
           status = 304;
           response.end('');
       }
       response.writeHead(status, {
           'Content-Type': 'text/javascript',
           'Cache-Control': 'no-cache,max-age=2000',
           'Last-Modified': lastModified
       });
       response.end(js);
   }
});

ETag

EtagЭффект по существу иLast-Modifiedне много отличий. в сравнении сLast-ModifiedСтратегия проверки кэша, использующая дату последнего изменения для сравнения ресурсов на предмет недействительности.ETagчерезподпись данныхсделать более строгую проверку кеша.

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

а такжеLast-Modifiedвести перепискуIf-Modified-Sinceтакой же,ETagтакже будет соответствоватьIf-MatchилиIf-None-Match(If-None-Matchиспользуется чаще), если подпись до и после одинакова, нет необходимости возвращать новое содержимое ресурса.

Разумное использование проверки кеша

Last-Modifiedа такжеETagПросто дает серверу возможность контролировать срок действия кеша, нет необходимости принудительно применять роль кеша и, наконец, определять, использовать ли кеш, или использовать новый файл ресурсов, или нужно указать серверомhttp codeрешать. Для файлов, сохраненных на сервере, есть атрибут даты последнего изменения, при использованииLast-ModifiedВы можете использовать этот допустимый атрибут для проверки кэша данных или ввестиupdatetimeполе для определения конкретной даты модификации, чтобы определить, действителен ли кеш. Как построить сервер, который может разумно использовать кеш, требует дополнительных внутренних знаний и не будет здесь подробно описываться.

Политика одинакового происхождения браузера

Ограничение браузера на одно и то же происхождение: когдабраузерURL доступаПротокол (схема) / порт (порт) / доменное имя (хост), когда какой-либо из трех не соответствует информации о текущем фрагменте URL, возникает междоменная проблема.

текущий адрес	адрес запроса	был ли запрос успешным
www.juejin.com:80	www.juejin.com:80	Междоменный (разные протоколы)
www.juejin.com:80	www.juejin.cn:80	Междоменные (разные доменные имена)
www.juejin.com:80	www.juejin.com:90	Междоменный (разные порты)

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

1. Кроссдоменность — это средство защиты, предоставляемое браузерами., на стороне сервера нет кросс-домена. Вот почему интерфейс больше зависит от режима разработки, в котором интерфейс и сервер разделены.webpack-dev-serverПричина запуска прокси-сервиса для ретрансляции и проксирования бэкэнд-интерфейса в том, что между двумя серверами, взаимодействующими друг с другом, нет междоменного барьера.
2. Междоменный, для XMLHttpRequest нет междоменных ограничений для браузеров для получения статических ресурсов с разных исходных серверов., что такжеJSONPСуть реализации междоменных запросов.
3. В отличие от XMLHttpRequest,Для ресурсов сценария, загруженных через атрибут src, браузер ограничивает разрешения Javascript, чтобы он не мог читать, записывать и возвращать содержимое..
4. Для браузеров, в дополнение к ограничениям политики одного источника, налагаемым DOM, Cookie и XMLHttpRequest, некоторые распространенные подключаемые модули, такие как Flash, Java Applet, Silverlight, Google Gears и т. д., также имеют свои собственные политики управления.

Когда браузер отправляет запрос на сервер в другом домене, запрос действительно может быть отправлен, другой сервер действительно может получить запрос и действительно может дать ответ вашему браузеру, и браузер действительно может получить достоверные данные. Однако если в случае кроссдоменности сервер возвращает данные в заголовке ответаAccess-Control-Allow-OriginПоле, текущее доменное имя не включено в белый список, то браузер будет скрывать данные, возвращаемые сервером, не говоря, а затем броситьAccess-Control-Allow-Originошибка.

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

Access-Control-Allow-Origin

Access-Control-Allow-OriginОпределяет междоменный белый список, разрешенный сервером. Он имеет следующие методы настройки:

1. установить напрямую*Подстановочные знаки просты и грубы, но это эквивалентно полному открытию всех интерфейсных ресурсов сервера для внешнего мира, что небезопасно.
2. Установите указанный домен, напримерAccess-Control-Allow-Origin: https://www.baidu.com, который разрешает междоменный доступ только для запросов из указанного домена.
3. Динамически устанавливается серверной частью.Access-Control-Allow-OriginОграничение состоит в том, чтобы написать только один белый список, но что, если у нас есть несколько доменов, требующих междоменных запросов? В это время сервер может сам поддерживать набор списков белого списка, и когда приходит запрос, можно проверить источник запроса.hostВыполните сравнение белого списка, если он есть в белом списке, поставьте этоAccess-Control-Allow-OriginДинамически настройте его, а затем верните ответ.

Предварительный запрос CORS

Если мы сделаем, как указано выше, и установим толькоAccess-Control-Allow-OriginМожет ли белый список быть полностью беспрепятственным для междоменного доступа? Не совсем. Даже если на удаленной стороне включена проверка подлинности по белому списку доменных имен, некоторые операции все равно требуют дополнительной проверки подлинности.CORS 预请求.

Процесс триггера предварительного запроса

Условия срабатывания для предварительных запросов браузера,заключается в том, чтобы судить, является ли этот запрос простым запросом. Если этот запрос принадлежитсложный запросЗатем, затем перекрестный домен перед отправкой формального запроса, браузер сначала подготовит файл под названиемOPTIONSизHTTP Method, отправлено в качестве предварительного запроса. После того, как сервер передаст предварительный запрос, следующий браузер выполнит формальный запрос данных. Весь процесс запроса фактически представляет собой два запроса: предварительный запрос и последующий фактический запрос данных.

простой запрос

1. Метод запроса может быть толькоGET POST HEAD
2. Поля заголовка запроса позволяют только:
   • Accept
   • Accept-Language
   • Content-Language
   • Content-Type
3. Content-TypeЗначения ограничены:
   • text/plain
   • multipart/form-data
   • application/x-www-form-urlencoded
4. XMLHttpRequestUploadНи у одного из объектов не зарегистрированы прослушиватели событий (просто знайте).
5. не используется в запросеReadableStreamОбъект (просто знайте это).

сложный запрос

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

предварительно запрошенная аутентификация

Так как же сделать предварительный запрос успешно аутентифицированным? Еще нужно, чтобы сервер продолжал помогать устанавливать белый список заголовка запроса:

1. Access-Control-Allow-Headers, который устанавливает разрешенные дополнительные поля заголовка запроса.
2. Access-Control-Allow-Methods, который устанавливает разрешенные дополнительные методы запроса.
3. Access-Control-Max-Age(единица/секунда), указывает, как долго результат предварительного запроса может кэшироваться.В течение этого времени повторно отправленный междоменный запрос не будет предварительно проверяться.

Все больше конкретных политик междоменных ограничений могутНажмите сюда, чтобы увидеть больше

Схема оптимизации производительности HTTP

1. добросовестное использованиеHTTPСтратегия кэширования позволяет избежать дополнительных потерь производительности, вызванных множественными запросами к серверу одного и того же ресурса.
2. использовать как можно большеHTTPДлинное соединение, избегайте перестроения каждый разTCPПотеря времени соединения
3. использовать как можно большеHTTPSдля обеспечения безопасности передачи по сети.
4. можно использоватьHTTP2Чтобы значительно повысить эффективность передачи данных, используйтеserver pushвключиHTTP2функция отправки сервера
5. Клиент открытAccept-EncodingПоддержка сжатия, сервер передает сжатые файлы для уменьшения размера передаваемых данных