предисловие
Расширенный подход автора к интерфейсу с открытым исходным кодом существует уже три года и на данный момент имеет 17 тысяч звезд благодаря любви читателей. На данный момент часть контента немного устарела, поэтому решил пересмотреть контент.
Весь обновленный контент будет собран в«Сухой передний край», заинтересованные читатели могут пойти проверить.
Важное примечание перед чтением:
Эта статья не является энциклопедией, она предназначена только для подготовки обзора интервью, проверки пропусков и заполнения вакансий, углубленного ознакомления с определенной областью знаний и понимания вопросов, связанных с интервью.
Автор всегда выступал за изучение знаний, связанных с вопросами интервью, а не за чистку множества вопросов интервью. Таким образом, эта статья отличается от других вопросов для интервью тем, что она направлена на то, чтобы уточнить общеизвестные моменты в вопросах интервью, а не бросать судьям множество вопросов для интервью.
Вы также можете найти у автораВеб-сайтЧитайте дальше для лучшего опыта!
Компаньон:Склад с 17 тысячами звезд, решите 90% основных вопросов на собеседовании на крупных фабриках.
Сегодняшняя статья начинается с ввода URL-адреса и разговора с вами о фронтенд-инженерах.Контент, связанный с сетью, который необходимо освоить.
Примечание: В процессе ввода URL-адреса и возврата данных потребуется много знаний, связанных с сетью.Автор представит только ту часть, которую должны знать интерфейсные инженеры, а читатели другого контента могут изучить сами.
Когда мы вводим URL-адрес в браузере:www.google.com/, браузер сначала будет искать IP-адрес, соответствующий доменному имени.В конце концов, нам все равно придется использовать IP, чтобы найти адрес другой стороны в конечном общении.Доменное имя - это просто псевдоним, удобный для пользователей помнить.
Так как же найти IP-адрес, соответствующий доменному имени? Далее, позвольте автору представить первую часть контента, с которой мы столкнулись: DNS.
DNS
Роль DNS заключается в запросе определенного IP-адреса через доменное имя.
Поскольку IP имеет комбинацию цифр и английского языка (IPv6), он не способствует человеческой памяти, поэтому появляются доменные имена. Вы можете думать о доменном имени как о псевдониме IP, а DNS должен запрашивать настоящее имя псевдонима.
когда вы хотите получить доступwww.google.com, выполнив следующие действия:
- Локальный клиент инициирует запрос на сервер для запроса IP-адреса.
- Проверьте, есть ли в браузере кэш IP для доменного имени
- Проверьте, есть ли в операционной системе IP-кеш для доменного имени.
- Проверьте, есть ли в файле хоста конфигурация разрешения для доменного имени.
- Если он не был получен в это время, он будет запрошен напрямую, перейдя на корневой сервер DNS.На этом этапе запрос обнаружит ответственного
comЭто доменное имя первого уровня - Затем перейдите на сервер для запроса
google.comэтот домен второго уровня - Следующий запрос
www.google.comАдрес этого доменного имени третьего уровня - возвращается DNS-клиенту и кэшируется
Вышеупомянутый DNS-рекурсивный запрос, а есть еще один вид итеративного запроса, разница в том, что первый выполняется DNS-сервером, настроенным системой, и данные возвращаются клиенту после получения результата, второй сделал клиент.
В настоящее время любопытные читатели могут спросить: когда DNS выполняет разрешение, отправляется ли запрос на эти серверы на основе протокола TCP или UDP?
На самом деле, в текущей сетевой среде полезны оба протокола. Чтобы сделать некоторые запросы с небольшим объемом данных через UDP, вы можете использовать преимущества быстрой работы UDP в это время; когда объем данных большой и вам нужно убедиться, что данные полны и упорядочены, вы выберете использовать TCP для запроса, чтобы обеспечить правильность и целостность данных.
Мы также представим протоколы UDP и TCP в последующем содержании.
Когда браузер получит IP-адрес доменного имени, он немедленно установит соединение с сервером по протоколу TCP. Далее поговорим о содержании протокола TCP.
TCP
Для установления TCP-соединения требуется три рукопожатия:
Первоначально оба конца находятся в ЗАКРЫТОМ состоянии. Перед началом коммуникации обе стороны создадут TCB (структуру данных, которая содержит много контента, требуемого протоколом, и те, кто заинтересован, могут узнать об этом сами). После того, как сервер создал TCB, он переходит в состояние LISTEN и начинает ждать, пока клиент отправит данные.
первое рукопожатие
Клиент отправляет сегмент запроса на подключение (SYN) на сервер. Этот сегмент содержит свой собственный начальный порядковый номер для передачи данных. После отправки запроса клиент переходит в состояние SYN-SENT,xУказывает начальный порядковый номер передачи данных клиента.
второе рукопожатие
После того, как сервер получит сегмент запроса на соединение, если он согласен на соединение, он отправит ответ (ACK + SYN).
третье рукопожатие
Когда клиент получает ответ о согласии на подключение, он также отправляет сообщение подтверждения (ACK) на сервер. После того, как клиент отправляет этот сегмент, он переходит в состояние ESTABLISHED, в состояние ESTABLISHED входит и сервер после получения ответа, в это время соединение успешно установлено.
PS: третье рукопожатие может содержать данные с помощью технологии TCP Fast Open (TFO). Фактически, пока задействован протокол рукопожатия, можно использовать метод, аналогичный TFO: клиент и сервер хранят один и тот же файл cookie, а файл cookie выдается во время следующего рукопожатия, чтобы уменьшить RTT (время возврата запроса). ).
Вот классический вопрос на собеседовании: почему протокол TCP требует трех рукопожатий вместо двух?
Поскольку это необходимо для предотвращения получения сервером недопустимого сегмента запроса на подключение, что может привести к ошибке.
Можно представить следующий сценарий. Клиент отправляет запрос на соединение A, но тайм-аут вызван сетевыми причинами.В это время TCP запустит механизм повторной передачи тайм-аута, чтобы снова отправить запрос на соединение B. В этот момент запрос успешно достигает сервера, и сервер отвечает и устанавливает запрос. Если запрос на соединение A, наконец, поступает на сервер после того, как два конца закрыты, то сервер будет думать, что клиенту необходимо снова установить TCP-соединение, тем самым отвечая на запрос и переходя в состояние ESTABLISHED. В это время клиент фактически находится в состоянии ЗАКРЫТ, что заставит сервер все время ждать, что приведет к пустой трате ресурсов.
PS: при установлении соединения, если какой-либо конец отключен, TCP повторно передаст пакет SYN, как правило, повторяет попытку пять раз и может столкнуться с атакой SYN FLOOD во время установления соединения. В этом случае вы можете уменьшить количество повторных попыток или просто отклонить запрос, если он не может быть обработан.
Когда соединение установлено и запрос выполнен, TCP-соединение не будет разорвано немедленно. Благодаря атрибуту keep-alive в протоколе HTTP 1.1 соединение может сохраняться в течение короткого промежутка времени, способ отключения зависит от настроек сервера или активного закрытия клиента.
После закрытия протокол TCP выполнит четырехстороннее рукопожатие для отключения.
первое рукопожатие
Если Клиент А сообщает, что передача данных завершена, ему необходимо отправить запрос на разъединение на сервер Б.
второе рукопожатие
После того, как B получит запрос на освобождение соединения, он сообщит прикладному уровню о необходимости освободить TCP-соединение. Затем он отправит пакет ACK и войдет в состояние CLOSE_WAIT, указывая на то, что соединение между A и B было разорвано и данные, отправленные A, не будут получены. Но поскольку TCP-соединение является двунаправленным, B все равно может отправлять данные в A.
третье рукопожатие
Если в это время у B все еще есть незаконченные данные, он продолжит отправку, а после завершения отправит запрос на освобождение соединения на A, а затем B войдет в состояние LAST-ACK.
PS: Благодаря технологии отложенного подтверждения (обычно есть ограничение по времени, иначе другая сторона ошибочно подумает, что требуется повторная передача), второе и третье рукопожатия сервера могут быть объединены для задержки отправки ACK-пакета.
четвертое рукопожатие
После получения запроса на освобождение A отправляет ответ с подтверждением B, и в это время A переходит в состояние TIME-WAIT. Это состояние будет длиться 2MSL (максимальное время жизни сегмента, которое относится к времени, в течение которого сегмент сообщения сохраняется в сети, и тайм-аут будет отброшен). ЗАКРЫТОЕ состояние. Когда B получает подтверждение, он также переходит в состояние CLOSED.
Почему A переходит в состояние TIME-WAIT и ждет 2MSL перед переходом в состояние CLOSED?
Чтобы гарантировать, что B может получить подтверждающий ответ от A. Если A напрямую переходит в состояние CLOSED после отправки ответа с подтверждением, если ответ с подтверждением не пришел из-за проблем с сетью, это приведет к тому, что B не будет нормально отключен.
Два типа рукопожатий, используемых для установления и отключения соединений, являются важными знаниями в TCP. Конечно, в дополнение к этому содержанию в TCP есть много вещей, которые нам нужно изучить, например, как протокол TCP реализует упорядоченную и полную передачу данных, что мы скоро узнаем.
протокол ARQ
Во-первых, давайте узнаем, как протокол TCP обеспечивает полную доставку данных. Ведь флуктуации сети и наличие различных неопределенных факторов приведут к потере передачи данных, а раз это происходит, мы должны убедиться, что в протоколе есть механизм повторной передачи. Точно так же, как когда мы загружаем некоторые важные данные в нашем бизнесе, когда мы не получаем ответа или происходит что-то еще, мы повторяем попытку несколько раз.
Протокол ARQ также является протоколом механизма повторной передачи по тайм-ауту. Правильная доставка данных гарантируется с помощью механизмов подтверждения и тайм-аута, включая протоколы ARQ с остановкой и ожиданием и непрерывные протоколы ARQ.
хватит ждать ARQ
нормальный процесс передачи
Пока A отправляет сообщение B, он должен прекратить отправку и запустить таймер, дождаться ответа от одноранговой стороны, отменить таймер и отправить следующее сообщение после получения ответа от одноранговой стороны в течение времени таймера.
когда возникает ошибка
1. Потеря сообщения или ошибка
Потеря пакетов может произойти во время передачи пакетов. В это время, если время, установленное таймером, превышает время, установленное таймером, потерянные данные будут отправляться снова, пока одноранговый узел не ответит, поэтому необходимо каждый раз создавать резервную копию отправленных данных.
Даже если пакет нормально передается на одноранговую сторону, во время передачи в пакете может быть ошибка. В это время одноранговая сторона отбрасывает пакет и ждет повторной передачи со стороны А.
PS: время, установленное общим таймером, будет больше, чем среднее время RTT.
2. Тайм-аут или потеря ACK
Ответы, переданные узлом, также могут быть потеряны или истечены по тайм-ауту. Затем сторона A все равно будет повторно передавать пакет после истечения времени таймера. В это время, когда конец B получает сообщение с тем же порядковым номером, он отбрасывает сообщение и повторно передает ответ до тех пор, пока конец A не отправит сообщение со следующим порядковым номером.
В случае тайм-аута ответ может прийти очень поздно.В это время сторона А будет определять, был ли получен порядковый номер.Если он был получен, ей нужно только отбросить ответ.
Недостатком этого протокола является низкая эффективность передачи: в хорошей сетевой среде каждый раз при отправке сообщения приходится ждать ACK от партнера.
Непрерывный запрос запросов
При непрерывном ARQ отправитель имеет окно отправки и может продолжать отправлять данные в этом окне, не получая ответа, что сокращает время ожидания и повышает эффективность по сравнению с прекращением ожидания протокола ARQ.
Накопленное подтверждение
При непрерывном ARQ получатель будет продолжать получать пакеты. Если это то же самое, что и отправка подтверждения, чтобы прекратить ожидание получения пакета в ARQ, это было бы пустой тратой ресурсов. Путем накопления подтверждений на одно ответное сообщение можно ответить единообразно после получения нескольких сообщений. ACK в сообщении может использоваться, чтобы сообщить отправителю, что все данные до этого порядкового номера были получены, и в следующий раз отправьте данные с этим порядковым номером + 1.
Но у кумулятивного подтверждения есть и недостаток. При непрерывном приеме сообщений может возникнуть ситуация, когда после получения сообщения с порядковым номером 5 сообщение с порядковым номером 6 не получено, а получено сообщение с порядковым номером 7 и выше. В этом случае ACK может ответить только 6, что приведет к повторной отправке данных отправителем.В этом случае это может быть решено Sack, который будет рассмотрен ниже.
раздвижное окно
Понятие окна часто встречается в TCP, например, мы говорили об окне отправки в предыдущем разделе. В TCP окна поддерживаются на обоих концах: окно отправителя и окно получателя соответственно.
Окно отправителя содержит данные, которые были отправлены, но не получили подтверждения, и данные, которые могли быть отправлены, но не отправлены.
Размер окна отправителя определяется оставшимся размером окна получателя. Получатель запишет оставшийся размер текущего окна приема в ответное сообщение, а отправитель установит размер окна отправки в соответствии со значением и текущей перегрузкой сети после получения ответа, поэтому размер окна отправки постоянно меняющийся.
Когда отправитель получит ответное сообщение, он соответствующим образом сдвинет окно.
Эти две картинки должны быть знакомы учащимся, изучившим алгоритм, ведь скользящее окно — тоже своего рода высокочастотная проблема в алгоритме.
Раздвижные окна реализуют управление потоком. Получатель информирует отправителя, сколько данных может быть отправлено через сообщение, чтобы гарантировать, что получатель сможет получить данные вовремя.
Нулевое окно
В процессе отправки пакетов на пире может быть нулевое окно. В этом случае отправитель прекращает отправку данных и запускает постоянный таймер. Таймер будет периодически отправлять запросы узлу, чтобы сообщить узлу размер окна. После определенного количества попыток соединение TCP может быть разорвано.
обработка перегрузок
Обработка перегрузки — очень важный функциональный модуль в TCP.Он главным образом управляет передачей данных с помощью некоторых алгоритмов для предотвращения перегрузки сети.
Обработка перегрузки отличается от управления потоком, которое воздействует на получателя, чтобы гарантировать, что у получателя есть время для приема данных. Первый действует в сети, предотвращая перегрузку сети слишком большим объемом данных и избегая перегрузки сети.
Обработка перегрузки включает четыре алгоритма: медленный старт, предотвращение перегрузки, быстрая повторная передача и быстрое восстановление.
алгоритм медленного старта
Алгоритм медленного старта, как следует из названия, заключается в медленном экспоненциальном расширении окна отправки в начале передачи, чтобы избежать перегрузки сети, вызванной передачей большого объема данных в начале. Например, во время ежедневных загрузок наша скорость загрузки постепенно увеличивается.
Шаги алгоритма медленного старта следующие:
- Соединение изначально устанавливает окно перегрузки (Congestion Window) на 1 MSS (максимальный объем данных для сегмента)
- Умножьте размер окна на два после каждого RTT.
- Экспоненциальный рост, конечно, не безграничен, поэтому есть пороговое ограничение, и когда размер окна больше порога, активируется алгоритм предотвращения перегрузки.
Алгоритм предотвращения перегрузок
Алгоритм предотвращения перегрузки относительно прост: размер окна RTT увеличивается только на единицу каждый раз, когда оно проходит, что позволяет избежать экспоненциального роста и вызвать перегрузку сети, а также медленно регулировать размер до оптимального значения.
Если протокол посчитает, что сеть перегружена в процессе передачи, он немедленно выполнит следующие шаги:
- Установите порог на половину текущего окна перегрузки
- Установите окно перегрузки на 1 MSS
- Запустите алгоритм предотвращения перегрузок
быстрая ретрансляция
Быстрая повторная передача обычно происходит вместе с быстрым восстановлением. Как только пакеты, полученные получателем, выходят из строя, получатель ответит только на последний порядковый номер пакета в правильном порядке (при отсутствии Sack). Если получено три повторных ACK, это означает, что данные, отправленные отправителем, не были получены узлом, и в это время будет запущена быстрая повторная передача. Основной алгоритм такой:
TCP Reno
- Окно перегрузки уменьшено вдвое
- установить порог для текущего окна перегрузки
- Войдите в фазу быстрого восстановления (повторно передайте пакеты, необходимые узлу, и выйдите из этой фазы после получения нового ответа ACK)
- Используйте алгоритмы предотвращения перегрузок
TCP New Ren улучшил быстрое восстановление
TCP New RenoАлгоритм улучшен доTCP RenoОшибки алгоритма. Ранее, если в быстром восстановлении был получен новый пакет ACK, быстрое восстановление будет завершено.
существуетTCP New Reno, отправитель TCP сначала отмечает максимальный порядковый номер сегмента с тремя дубликатами ACK.
Если у меня есть пакет, данные сегмента которого представляют собой десять порядковых номеров от 1 до 10, а пакеты с порядковыми номерами 3 и 7 потеряны, то максимальный порядковый номер сегмента равен 10. Отправитель получит ответ только с порядковым номером ACK, равным 3. В это время сообщение с порядковым номером 3 отправляется повторно, и получатель успешно принимает его и отправляет ответ с порядковым номером ACK 7. В это время TCP знает, что на противоположном конце есть несколько пакетов, которые не были получены, и будет продолжать отправлять сообщение с порядковым номером 7. Получатель успешно получает его и отправляет ответ с порядковым номером ACK 11. В это время, отправитель думает, что получатель сегмента имеет. После успешного приема фаза быстрого восстановления будет завершена.
После разговора о протоколе TCP, давайте поговорим о его родственном протоколе UDP. Поскольку UDP имеет более простые функции, чем TCP, для этого требуется не так много знаний.
UDP
ориентированный на сообщение
UDP — это протокол, ориентированный на сообщения (сообщение можно понимать как сегмент данных). Это означает, что UDP является только средством переноса пакетов и не будет выполнять какие-либо операции разделения и объединения пакетов. Протокол TCP сделает это, ведь порядок пакетов должен быть гарантирован.
Конкретно:
- На стороне отправителя прикладной уровень передает данные протоколу UDP транспортного уровня. UDP только добавит заголовок UDP к данным для идентификации протокола UDP, а затем передаст его на сетевой уровень.
- На принимающей стороне сетевой уровень передает данные на транспортный уровень, а UDP только удаляет заголовок IP и передает его на прикладной уровень без какой-либо операции сплайсинга.
Так как UDP очень просто обрабатывает пакеты, он имеет некоторые недостатки.
ненадежный
- Без установления соединения, что означает, что для связи не требуется устанавливать и отключать соединения.
- Протокол передает любые данные, которые он получает, и не делает резервную копию данных, и не имеет значения, может ли другая сторона получить их или нет.
- Без контроля перегрузки данные всегда отправляются с постоянной скоростью. Даже если сетевые условия плохие, скорость отправки не будет скорректирована. Недостаток этой реализации в том, что она может привести к потере пакетов в случае плохих условий сети, но преимущества также очевидны, и она будет очень полезна в некоторых сценариях с высокими требованиями к реальному времени.
эффективный
Поскольку UDP не так сложен, как TCP, необходимо обеспечить, чтобы данные не терялись и поступали упорядоченно. Таким образом, заголовок заголовка UDP невелик, всего восемь байтов, что намного меньше, чем по крайней мере двадцать байтов TCP, и он очень эффективен при передаче пакетов данных.
Заголовок содержит следующие данные
- Два шестнадцатизначных номера порта, которые являются исходным портом (необязательное поле) и портом назначения.
- Длина всей дейтаграммы
- Контрольная сумма всей дейтаграммы (необязательное поле IPv4), используемая для обнаружения ошибок в информации заголовка и данных.
После разговора о TCP и UDP давайте посмотрим на возможности браузера.www.google.com/Каково последующее действие ссылки после завершения трехэтапного рукопожатия TCP.
Поскольку мы ввели протокол HTTPS, этот протокол можно рассматривать как протокол HTTP плюс протокол безопасности TLS. Следовательно, после завершения TCP-соединения передача на уровне протокола HTTP будет запущена не сразу, а будет запущено рукопожатие протокола TLS.
HTTPS
Наиболее важной частью HTTPS является протокол TLS, поскольку этот протокол обеспечивает безопасность.
TLS
Поскольку необходимо гарантировать безопасность, необходимо использовать технологию шифрования. В TLS используются два метода шифрования: симметричное шифрование и асимметричное шифрование.
Симметричное шифрование:
Симметричное шифрование означает, что обе стороны имеют один и тот же секретный ключ, и обе стороны знают, как шифровать и расшифровывать зашифрованный текст.
Асимметричное шифрование:
Существует открытый ключ и закрытый ключ.Все могут знать открытый ключ, и данные могут быть зашифрованы с помощью открытого ключа, но для расшифровки данных должен использоваться закрытый ключ.Закрытый ключ может быть известен только стороне который распространял открытый ключ.
Процесс рукопожатия TLS выглядит следующим образом:
- Клиент отправляет случайное значение, требуемый протокол и шифрование
- Сервер получает случайное значение клиента, сам генерирует случайное значение и использует соответствующий метод в соответствии с протоколом и методом шифрования, требуемым клиентом для отправки собственного сертификата (если вам нужно проверить сертификат клиента, вы надо объяснить)
- Клиент получает сертификат от сервера и проверяет, действителен ли он.После прохождения проверки будет сгенерировано случайное значение, и случайное значение будет зашифровано открытым ключом сертификата сервера и отправлено на сервер.Если серверу необходимо проверить сертификат клиента, к нему будет прикреплен сертификат
- Сервер получает зашифрованное случайное значение и расшифровывает его с помощью закрытого ключа, чтобы получить третье случайное значение.В это время на обоих концах есть три случайных значения.Ключ может быть сгенерирован в соответствии с ранее согласованным методом шифрования через эти три случайных значения. Следующее сообщение может быть зашифровано и расшифровано с помощью этого ключа.
Из приведенных выше шагов видно, что на этапе рукопожатия TLS обе стороны используют асимметричное шифрование для связи, но поскольку производительность потери асимметричного шифрования выше, чем у симметричного шифрования, при формальной передаче данных обе стороны используют симметричное шифрование для связи. общаться.
PS: Все вышеприведенные описания относятся к рукопожатию протокола TLS 1.2.В протоколе 1.3 требуется только один RTT для установления соединения в первый раз, а для последующего восстановления соединения RTT не требуется. Поэтому, если вы заботитесь о производительности передачи по сети, вам следует выбрать протокол TLS1.3.
Когда TLS завершает рукопожатие, он действительно начинает передавать данные на уровне протокола HTTP.
HTTP
Что касается HTTP-протокола, фронтенд-инженеры в основном понимают общие коды состояния и заголовки, в конце концов, это то, к чему нам часто приходится прикасаться при ежедневном написании кода.
Общие коды состояния
2ХХ успехов
- 200 OK, что указывает на корректную обработку запроса от клиента на стороне сервера
- 204 Нет содержимого, что указывает на то, что запрос выполнен успешно, но ответное сообщение не содержит основной части сущности
- 205 Reset Content, указывающий на то, что запрос выполнен успешно, но ответное сообщение не содержит основной части сущности, но отличается от ответа 204 тем, что запрашивающему требуется сбросить содержимое
- 206 Частичный контент, сделайте запрос диапазона
3XX редирект
- 301 перемещен навсегда, постоянное перенаправление, указывающее, что ресурсу был присвоен новый URL-адрес
- 302 найдено, временное перенаправление, указывающее на то, что ресурсу временно присвоен новый URL
- 303 см. другое, что указывает на то, что для ресурса существует другой URL-адрес, и для получения ресурса следует использовать метод GET.
- 304 не изменено, указывающее на то, что сервер разрешает доступ к ресурсу, но запрос не соответствует условиям из-за возникновения
- 307 временное перенаправление, временное перенаправление, похожее на 302, но ожидает, что клиент сохранит метод запроса без изменений и сделает запрос на новый адрес
4XX Ошибка клиента
- 400 неверный запрос, в сообщении запроса есть синтаксическая ошибка
- 401 неавторизованный, что указывает на то, что для отправленного запроса требуется информация аутентификации через HTTP-аутентификацию.
- 403 запрещено, что указывает на то, что доступ к запрошенному ресурсу был запрещен сервером
- 404 not found, указывающий на то, что запрошенный ресурс не найден на сервере
5ХХ ошибка сервера
- 500 внутренняя ошибка сервера, указывающая на то, что при выполнении запроса произошла ошибка на стороне сервера
- 501 Not Implemented, указывающий, что сервер не поддерживает функцию, требуемую текущим запросом.
- Служба 503 недоступна, что указывает на то, что сервер временно перегружен или отключен на техническое обслуживание и не может обрабатывать запросы.
HTTP-заголовки
| Общее поле | эффект |
|---|---|
| Cache-Control | Управление поведением кеша |
| Connection | Тип подключения, который браузер хочет использовать в первую очередь, например.keep-alive,close
|
| Date | Создать время сообщения |
| Pragma | команда сообщения |
| Via | Информация о прокси-сервере |
| Transfer-Encoding | кодирование передачи |
| Upgrade | Попросите клиента обновить протокол |
| Warning | В содержании могут быть ошибки |
| поле запроса | эффект |
|---|---|
| Accept | Типы носителей, которые могут быть получены правильно |
| Accept-Charset | Набор символов, который может получить правильно |
| Accept-Encoding | Список форматов кодирования, которые могут корректно приниматься |
| Accept-Language | Список языков, которые могут быть получены правильно |
| Expect | Ожидать указанного поведения от сервера |
| From | Адрес электронной почты запрашивающего |
| Host | доменное имя сервера |
| If-Match | Сравнение тегов ресурсов на обоих концах |
| If-Modified-Since | Не измененный локальный ресурс возвращает 304 (сравните время) |
| If-None-Match | локальный ресурс без изменений возвращает 304 (флаг сравнения) |
| User-Agent | Информация о клиенте |
| Max-Forwards | Ограничьте количество раз, которые могут быть перенаправлены прокси и шлюзами |
| Proxy-Authorization | Отправить информацию для аутентификации на прокси-сервер |
| Range | запросить часть чего-либо |
| Referer | Представляет предыдущую страницу, посещенную браузером |
| TE | кодирование передачи |
| поле ответа | эффект |
|---|---|
| Accept-Ranges | поддерживаются ли определенные виды диапазонов |
| Age | Как долго ресурс находится в кеше прокси |
| ETag | Идентификатор ресурса |
| Location | Клиент перенаправляет на URL |
| Proxy-Authenticate | Отправить информацию для аутентификации на прокси-сервер |
| Server | имя сервера |
| WWW-Authenticate | Получите информацию об аутентификации, необходимую для ресурса |
| поле сущности | эффект |
|---|---|
| Allow | Правильный способ запроса ресурсов |
| Content-Encoding | Формат кодирования контента |
| Content-Language | язык содержания |
| Content-Length | длина тела запроса |
| Content-Location | Альтернативный адрес для возврата данных |
| Content-MD5 | Контент в зашифрованном формате Base64 Контрольное значение MD5 |
| Content-Range | Диапазон местоположения контента |
| Content-Type | Медиатип контента |
| Expires | Срок годности контента |
| Last_modified | Время последней модификации контента |
HTTP 2.0
В последних нескольких абзацах поговорим о некоторых новых протоколах, сначала поговорим о HTTP 2.0. Можно сказать, что по сравнению с HTTP 1.1 этот протокол значительно повышает производительность Интернета.
В HTTP 1.1 из соображений производительности мы добавим изображения спрайтов, встроенные маленькие изображения, используем расхождение доменных имен и так далее. Все это потому, что браузер ограничивает количество запросов под одним и тем же доменным именем.Когда странице нужно запросить много ресурсов, блокировка заголовка строки заставит оставшиеся ресурсы ждать, когда будет достигнуто максимальное количество запросов. Запросы не могут быть инициированы, пока другие запросы ресурсов не будут выполнены.
Но в HTTP 2.0 эта проблема сильно оптимизирована, но до сих пор не решена. Поскольку HTTP 2.0 все еще находится в рамках протокола TCP, потребность в TCP для обеспечения правильности данных также вызовет проблему блокировки заголовка строки, поэтому проблема не решена. Однако эта проблема была полностью решена последующим новым протоколом, который мы перечислим ниже.
Давайте сначала почувствуем, насколько HTTP 2.0 быстрее, чем HTTP 1.X. Вы можете пройтисвязьопыт.
В HTTP 1.X из-за блокировки заголовка очереди вы найдете такой запрос
В HTTP 2.0 из-за введения мультиплексирования вы найдете такие запросы:
мультиплексирование
В HTTP 2.0 есть две очень важные концепции: кадр и поток.
Кадр представляет наименьшую единицу данных, и каждый кадр определяет, к какому потоку он принадлежит.Поток — это поток данных, состоящий из нескольких кадров.
Мультиплексирование означает, что в TCP-соединении может быть несколько потоков. Другими словами, можно отправить несколько запросов, и одноранговый узел может узнать, какому запросу принадлежит через идентификатор в кадре. Благодаря этой технологии производительность передачи может быть значительно улучшена.
бинарная передача
Это ядро всех улучшений производительности в HTTP 2.0. В предыдущих версиях HTTP мы передавали данные текстом. В HTTP 2.0 был введен новый механизм кодирования, все передаваемые данные разбиваются и кодируются в двоичные кадры в двоичном формате.
Есть много типов бинарных фреймов.На рисунке выше мы видим, что есть фреймы HEADERS и фреймы DATA.Помимо них есть еще несколько типов.Читатели могут узнать о них, если им интересно.
Сжатие заголовка
В HTTP 1.X мы передаем заголовки в виде текста, и в случае заголовков, содержащих файлы cookie, может потребоваться повторная передача от сотен до тысяч байт каждый раз.
В HTTP 2.0 передаваемый заголовок кодируется с использованием формата сжатия HPACK, что уменьшает размер заголовка. На обоих концах ведутся индексные таблицы для записи появившихся заголовков.Позднее, в процессе передачи, могут быть переданы имена ключей записанных заголовков.После того, как партнер получит данные, соответствующее значение может быть найдено по имени ключа. .
Сервер Push
Этому не нужно учиться, потому что используется слишком мало, Chrome может удалить эту функцию. Подробнее см.Chrome to remove HTTP/2 Push.
QUIC
Это основанный на UDP протокол, разработанный Google, который также является транспортным уровнем и преследует высокие цели и надеется заменить протокол TCP.
- Этот протокол поддерживает мультиплексирование.Хотя HTTP 2.0 также поддерживает мультиплексирование, нижним уровнем по-прежнему является TCP.Из-за механизма повторной передачи TCP, если пакет потерян, он должен оценить потерянный пакет и передать его повторно, блокировка линии.проблема, но UDP не имеет этого механизма
- Реализован собственный протокол шифрования и может достигать 0-RTT через TCP-подобный механизм TFO, что означает, что QUIC может устанавливать безопасное соединение и передавать данные в случае 0-RTT
- Поддержка механизма повторной передачи и исправления ошибок (прямое восстановление), отсутствие необходимости повторной передачи при потере только одного пакета, использование механизма исправления ошибок для восстановления потерянных пакетов
- Механизм исправления ошибок: вычислить значение XOR исходящих данных и отправить пакет отдельно с помощью XOR
- Механизм повторной передачи используется при потере двух и более пакетов, поскольку его невозможно вычислить.
наконец
С сетевыми протоколами связано довольно много контента, автор рассказывает о том, чему должны научиться фронтенд-инженеры. Если вас интересует определенный протокол, вы можете изучить его самостоятельно.
Приведу несколько примеров:
- HTTP 2.0 на самом деле включает в себя много контента, например, различные типы двоичных фреймов и их соответствующие функции.
- HTTP 3.0 — это более новый протокол со многими оптимизациями производительности по сравнению с 2.0.
- QUIC — это протокол с высокой производительностью и функциями TCP. Некоторые производители CDN уже поддерживают включение этой функции в фоновом режиме.
Бросьте несколько учебных вступлений для читателей. Если у вас есть какие-либо сомнения относительно вышеуказанного контента, вы можете поделиться им и учиться вместе.
Вы также можете найти у автораВеб-сайтЧитайте дальше для лучшего опыта!