Резюме вопросов высокочастотного внешнего интервью "2021" компьютерной сети

Недавно я разобрался с высокочастотными вопросами фронтенд-интервью и поделился ими со всеми, чтобы учиться вместе. Если у вас есть какие-либо вопросы, пожалуйста, поправьте меня!

Статьи из серии вопросов для фронтенд-интервью:

【1】HTML-глава "2021" с высокочастотными вопросами для фронтенд-интервью

【2】Сводка вопросов по высокочастотным фронтенд-интервью «2021» CSS статьи

【3】Глава "2021" о JavaScript, посвященная высокочастотным вопросам для фронтенд-интервью (часть 1)

【4】Резюме статьи JavaScript "2021" о часто задаваемых вопросах на собеседовании (часть 2)

【5】Глава Vue "2021" о часто задаваемых вопросах на собеседовании (часть 1)

【6】Глава Vue "2021" о часто задаваемых вопросах на собеседовании (часть 2)

【7】Сводка вопросов по высокочастотным фронтенд-интервью «2021» React (часть 1)

【8】Сводка вопросов по высокочастотным фронтенд-интервью «2021» React (часть 2)

【9】Резюме вопросов высокочастотного внешнего интервью "2021" компьютерной сети

【10】«2021» высокочастотные вопросы о фронтенд-интервью краткое изложение принципов браузера

【11】Сводка вопросов по оптимизации производительности высокочастотных предварительных интервью «2021»

【12】«2021» Рукописный свод кода высокочастотных вопросов на собеседовании перед интерфейсом

【13】Сводные результаты вывода кода высокочастотных вопросов внешнего интервью «2021»

1. HTTP-протокол

1. Разница между запросами GET и POST

Post и Get — это два метода HTTP-запроса, отличия заключаются в следующем:

• Сценарии применения:Запрос GET — это идемпотентный запрос.Как правило, запрос GET используется в сценариях, которые не влияют на ресурсы сервера, например при запросе ресурсов веб-страницы. Post не является идемпотентным запросом и обычно используется в сценариях, влияющих на ресурсы сервера, например в таких операциях, как регистрация пользователей.
• Следует ли кэшировать:Поскольку эти два сценария приложений различаются, браузеры обычно кэшируют запросы Get, но редко кэшируют запросы Post.
• Формат отправленного сообщения:Сущностная часть сообщения запроса Get пуста, а сущность сообщения запроса Post обычно представляет собой данные, отправляемые на сервер.
• безопасность:Запрос Get может поместить запрошенные параметры в URL-адрес и отправить его на сервер.Этот подход менее безопасен, чем запрос Post, поскольку запрошенный URL-адрес будет сохранен в истории.
• Длина запроса:Из-за ограничения длины URL-адреса браузер будет влиять на длину данных, отправляемых запросом на получение. Это ограничение определяется браузером, а не RFC.
• Тип параметра:Передача параметров post поддерживает больше типов данных.

2. Разница между запросами POST и PUT

• Запрос PUT заключается в отправке данных на сервер для изменения содержимого данных, но он не увеличивает тип данных и т. д., то есть независимо от того, сколько раз выполняется операция PUT, результат не отличается. (Можно понять, что когдаобновить данные)
• Запрос POST предназначен для отправки данных на сервер.Запрос изменит тип данных и других ресурсов, а также создаст новый контент. (можно понимать какСоздать данные)

3. Общие заголовки HTTP-запросов и заголовки ответов

Заголовок HTTP-запроса Общие заголовки запросов:

• Принять: тип контента, который может обрабатывать браузер.
• Accept-Charset: набор символов, который может отображать браузер.
• Accept-Encoding: кодировка сжатия, которую может обрабатывать браузер.
• Accept-Language: язык, установленный браузером в данный момент.
• Соединение: тип соединения между браузером и сервером.
• Файлы cookie: любые файлы cookie, установленные текущей страницей.
• Хост: домен, на котором находится запрашивающая страница.
• Referer: URL-адрес страницы, с которой был сделан запрос.
• User-Agent: строка пользовательского агента браузера.

Заголовок ответов HTTP Общие заголовки ответов:

• Дата: указывает время отправки сообщения, формат описания времени определяется rfc822.
• сервер: имя сервера
• Соединение: тип соединения между браузером и сервером.
• Cache-Control: управление кэшированием HTTP
• content-type: указывает, к какому типу MIME принадлежит следующий документ

Существует четыре общих значения свойства Content-Type:

(1) application/x-www-form-urlencoded: Собственная форма браузера, если атрибут enctype не установлен, данные будут отправлены методом application/x-www-form-urlencoded. Данные, представленные таким образом, помещаются в тело, данные кодируются в виде ключ1=значение1&ключ2=значение2, а ключ и значение перекодируются по URL-адресу.

(2) multipart/form-data: этот метод также является распространенным методом отправки POST, который обычно используется при загрузке файлов в форму.

(3) application/json: тело сообщения сервера представляет собой сериализованную строку JSON.

(4) text/xml: этот метод в основном используется для отправки данных в формате XML.

4. Более или менее код состояния HTTP 304

Для повышения скорости доступа к веб-сайту сервер указывает механизм кэширования для некоторых ранее посещенных страниц, и когда клиент запрашивает эти страницы, сервер определяет, совпадает ли страница с предыдущей по кэшированному Если это то же самое, он сразу вернет 304. В это время клиент вызывает кэшированное содержимое, не загружая его дважды.

Код состояния 304 следует рассматривать не как ошибку, а скорее какС кешемОтвет от сервера.

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

Причины для генерации большего количества кодов состояния 304:

• Цикл обновления страницы длинный или не обновляется
• Чистая статическая страница или заставить генерировать статический html

Слишком много кодов состояния 304 могут вызвать следующие проблемы:

• остановка снимков сайта;
• снижение приема;
• Вес падает.

5. Общие методы HTTP-запросов

• ПОЛУЧИТЬ: получить данные с сервера;
• POST: отправить объект на указанный ресурс, что обычно приводит к модификации ресурсов сервера;
• PUT: загрузить файлы, обновить данные;
• УДАЛИТЬ: удалить объект на сервере;
• HEAD: Получить заголовок сообщения.По сравнению с GET не возвращает тело сообщения;
• ВАРИАНТЫ: Спросите о поддерживаемых методах запросов для междоменных запросов;
• CONNECT: требует установления туннеля при общении с прокси-сервером, используя туннель для TCP-соединения;
• TRACE: эхо запроса, полученного сервером, в основном используется для тестирования или диагностики.

6. Способ запроса OPTIONS и сценарии использования

OPTIONS — это один из методов HTTP-запроса, кроме GET и POST.

Метод OPTIONS используется для запросаRequest-URIПараметры функций, которые идентифицированный ресурс может использовать во время обмена запрос/ответ. С помощью этого метода клиент можетПрежде чем сделать запрос для определенного ресурса, решите, какое действие необходимо для этого ресурса, или поймите производительность сервера.. Ответы на этот метод запроса нельзя кэшировать.

Метод запроса OPTIONSГлавная цельЕсть два:

• Получить все методы HTTP-запроса, поддерживаемые сервером;
• Используется для проверки прав доступа. Например, при выполнении междоменного совместного использования ресурсов CORS для сложных запросов метод OPTIONS используется для отправки запроса на анализ, чтобы определить, есть ли доступ к указанному ресурсу.

7. В чем разница между HTTP 1.0 и HTTP 1.1?

HTTP 1.0 и HTTP 1.1 имеют следующие отличия:

• Связь, http1.0 по умолчанию использует непостоянные соединения, а http1.1 по умолчанию использует постоянные соединения. http1.1 использует постоянные соединения для повторного использования одного и того же TCP-соединения для нескольких http-запросов, чтобы избежать задержки установления соединения каждый раз при использовании непостоянного соединения.
• запрос ресурсов, В http1.0 есть некоторые явления траты полосы пропускания.Например, клиенту нужна только часть объекта, а сервер отправляет объект целиком, и не поддерживает функцию возобновления загрузки, в то время как http1.1 запрашивает Заголовок вводит поле заголовка диапазона, которое позволяет запрашивать только определенную часть ресурса, то есть код возврата 206 (частичный контент), что облегчает свободный выбор разработчиков для полного использования пропускной способности и связи.
• Аспект кэша, В http1.0 If-Modified-Since и Expires в заголовке в основном используются в качестве критериев для оценки кеша, http1.1 вводит больше стратегий управления кешем, таких как Etag, If-Unmodified-Since, If-Match, If -None-Match и другие необязательные заголовки кэша для управления стратегией кэширования.
• В http1.1Добавлено поле хоста, который используется для указания доменного имени сервера. В http1.0 считается, что каждый сервер привязан к уникальному IP-адресу, поэтому URL-адрес в сообщении запроса не передает имя хоста (имя хоста). Но с развитием технологии виртуальных хостов на физическом сервере может существовать несколько виртуальных хостов, и они имеют общий IP-адрес. Следовательно, поле хоста позволяет отправлять запросы на разные веб-сайты на одном сервере.
• По сравнению с http1.0, http1.1 добавил многометод запроса, такие как PUT, HEAD, OPTIONS и т. д.

8. Разница между HTTP 1.1 и HTTP 2.0

• бинарный протокол: HTTP/2 — это бинарный протокол. В HTTP/1.1 информация заголовка сообщения должна быть текстовой (кодировка ASCII), а тело данных может быть текстовым или двоичным. HTTP/2 — это полностью двоичный протокол.Информация заголовка и тело данных являются двоичными и вместе называются «фреймами», которые можно разделить на информационные кадры заголовка и кадры данных. Концепция кадров лежит в основе его мультиплексирования.
• Мультиплексирование:HTTP/2 реализует мультиплексирование, а HTTP/2 по-прежнему мультиплексирует TCP-соединения, но в соединении и клиент, и сервер могут одновременно отправлять несколько запросов или ответов, и их не нужно отправлять по одному, чтобы , что позволяет избежать Решает проблему «заторов в очереди» [1].
• поток данных:HTTP/2 использует концепцию потока данных, поскольку пакеты данных HTTP/2 отправляются не по порядку, а последовательные пакеты данных в одном и том же соединении могут принадлежать разным запросам. Следовательно, пакет должен быть помечен, чтобы указать, какому запросу он принадлежит. HTTP/2 относится ко всем пакетам каждого запроса или ответа как к потоку данных. Каждый поток данных имеет уникальный номер. При отправке пакета данных идентификатор потока данных должен быть помечен, чтобы различать, к какому потоку данных он принадлежит.
• Сжатие заголовка:HTTP/2 реализует сжатие заголовков, а так как протокол HTTP 1.1 не передает состояние, вся информация должна быть прикреплена к каждому запросу. Таким образом, многие поля запроса повторяются, такие как Cookie и User Agent, которые имеют точно такое же содержимое и должны быть прикреплены к каждому запросу, что приведет к трате большого количества полосы пропускания и повлияет на скорость. HTTP/2 оптимизирует это, вводя сжатие заголовков. С одной стороны, информация заголовка сжимается gzip или сжатием и затем отправляется; с другой стороны, клиент и сервер одновременно ведут таблицу информации заголовка, все поля будут храниться в этой таблице, а индекс будет сгенерирован номер, и это же поле в дальнейшем не будет отправляться, отправляется только номер индекса, что увеличивает скорость.
• Пуш сервера:HTTP/2 позволяет серверу активно отправлять ресурсы клиенту без запроса, что называется проталкиванием сервера. Используйте push-уведомление сервера, чтобы заранее передать клиенту необходимые ресурсы, чтобы можно было относительно сократить некоторое время задержки. Здесь следует отметить, что сервер активно проталкивает статические ресурсы по http2, что отличается от WebSocket и проталкивания мгновенных данных клиенту с помощью SSE и других методов.

[1] Начало линии заблокировано:

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

9. Разница между протоколами HTTP и HTTPS

Основные различия между протоколами HTTP и HTTPS заключаются в следующем:

• Для протокола HTTPS требуется сертификат ЦС, который стоит дорого, протоколу HTTP он не нужен;
• Протокол HTTP — это протокол передачи гипертекста, информация передается в виде открытого текста, а HTTPS — это безопасный протокол передачи с шифрованием SSL;
• Используются разные способы подключения, порты тоже разные: порт протокола HTTP — 80, порт протокола HTTPS — 443;
• Соединение по протоколу HTTP очень простое и не имеет состояния; протокол HTTPS — это сетевой протокол, построенный на основе протоколов SSL и HTTP, который может выполнять зашифрованную передачу и аутентификацию и является более безопасным, чем HTTP.

10. Причина ограничения длины URL метода GET

На самом деле спецификация протокола HTTP не ограничивает длину URL-адреса, запрашиваемого методом get, это ограничение ограничено конкретными браузерами и серверами. Ограничение IE на длину URL-адреса составляет 2083 байта (2K+35). Поскольку браузер IE имеет наименьшее допустимое значение длины URL, при разработке, пока URL не превышает 2083 байт, он будет работать во всех браузерах без проблем.

GET的长度值 = URL（2083）- （你的Domain+Path）-2（2是get请求中?=两个字符的长度）

Давайте посмотрим на ограничение длины URL-адреса в методе get в основных браузерах:

• Microsoft Internet Explorer (браузер): Максимальное ограничение URL-адреса Internet Explorer составляет 2083 символа. Если это число превышено, кнопка отправки ничего не делает.
• Firefox (браузер): для браузера Firefox длина URL ограничена 65 536 символами.
• Safari (браузер): максимальная длина URL-адреса ограничена 80 000 символов.
• Opera (браузер): максимальная длина URL-адреса ограничена 190 000 символов.
• Google (chrome): максимальная длина URL-адреса ограничена 8182 символами.

Основные серверы ограничивают длину URL-адреса в методе get:

• Apache (сервер): максимальная допустимая длина URL-адреса составляет 8192 символа.
• Microsoft Internet Information Server (IIS): максимальная допустимая длина URL-адреса составляет 16384 символа.

По приведенным выше данным можно узнать, что длина URL в методе get не превышает 2083 символов, так что все браузеры и серверы могут нормально работать.

11. Что произойдет, если я наберу Google.com в своем браузере и нажму Enter?

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

(2)Решение кэша:Браузер определит, находится ли запрошенный ресурс в кеше.Если запрошенный ресурс находится в кеше и срок его действия не истек, он будет использован напрямую, в противном случае он инициирует новый запрос к серверу.

(3)Разрешение DNS:Следующим шагом является получение IP-адреса доменного имени во входном URL-адресе. Во-первых, он определит, есть ли кэш IP-адреса доменного имени локально. Если да, используйте его. Если нет, инициируйте запрос на локальный DNS-сервер. Локальный DNS-сервер также сначала проверит наличие кэша, если нет, то сначала инициирует запрос к корневому серверу доменных имен, получит адрес ответственного сервера доменных имен верхнего уровня, а затем сделает запрос к сервер доменных имен верхнего уровня, а затем получить адрес ответственного полномочного сервера доменных имен. , а затем инициировать запрос к полномочному серверу доменных имен. После получения IP-адреса доменного имени локальный DNS-сервер возвращает IP-адрес адрес запрашивающему пользователю. Запрос пользователя к локальному DNS-серверу является рекурсивным запросом, а запрос локального DNS-сервера ко всем уровням серверов доменных имен — итеративным запросом.

(4)Получить MAC-адрес:После того, как браузер получит IP-адрес, для передачи данных также необходимо знать MAC-адрес хоста назначения, поскольку прикладной уровень отправляет данные на транспортный уровень, а протокол TCP будет указывать номер исходного порта и номер порта назначения, а затем отправить его на сетевой уровень. Сетевой уровень будет использовать локальный адрес в качестве адреса источника и полученный IP-адрес в качестве адреса назначения. Затем он будет отправлен на уровень канала передачи данных.Передача уровня канала данных должна добавить MAC-адреса обеих сторон к связи.MAC-адрес локальной машины используется в качестве MAC-адреса источника, а MAC-адрес назначения адрес должен быть обработан в соответствии с ситуацией. Сравнивая IP-адрес с маской подсети локального компьютера, можно определить, находится ли он в той же подсети, что и запрашивающий хост.Если он находится в той же подсети, MAC-адрес хоста назначения можно получить с помощью протокол APR.В сети запрос должен быть перенаправлен на шлюз, который будет пересылать его от своего имени.В это время MAC-адрес шлюза также может быть получен через протокол ARP.В это время MAC-адрес адрес узла назначения должен быть адресом шлюза.

(5)Трехстороннее рукопожатие TCP:Ниже приведен процесс трехэтапного рукопожатия для установления соединения TCP. Сначала клиент отправляет на сервер сегмент запроса на соединение SYN и случайный порядковый номер. После получения запроса сервер отправляет на сервер сегмент SYN ACK для подтверждения. запрос на подключение, а также отправить клиенту случайный порядковый номер. После того, как клиент получает ответ подтверждения от сервера, он входит в состояние установления соединения, а также отправляет сегмент подтверждения ACK на сервер.После получения подтверждения сервер также входит в состояние установления соединения, и соединение между устанавливаются две партии.

(6)Рукопожатие HTTPS:Если используется протокол HTTPS, перед связью также выполняется четырехэтапный процесс рукопожатия TLS. Сначала клиент отправляет на сервер номер версии используемого протокола, случайное число и метод шифрования, который можно использовать. После того, как сервер его получит, он подтверждает метод шифрования, а также отправляет клиенту случайное число и собственный цифровой сертификат. После того, как клиент его получает, он сначала проверяет, действителен ли цифровой сертификат.Если он действителен, он генерирует случайное число, шифрует случайное число с помощью открытого ключа в сертификате и отправляет его на сервер.Значение хеша равно для проверки на стороне сервера. После того, как сервер получает его, он расшифровывает данные с помощью собственного закрытого ключа и в то же время отправляет хеш-значение всего предыдущего содержимого клиенту для проверки клиентом. В настоящее время у обеих сторон есть три случайных числа. В соответствии с ранее согласованным методом шифрования используйте эти три случайных числа для создания секретного ключа. Прежде чем две стороны свяжутся, они будут использовать этот секретный ключ для шифрования данных, а затем передать их .

(7)Возвращаемые данные:Когда запрос страницы отправляется на сервер, сервер возвращает html-файл в качестве ответа.После того, как браузер получает ответ, он начинает синтаксический анализ html-файла и запускает процесс рендеринга страницы.

(8)Рендеринг страницы:Браузер сначала строит DOM-дерево на основе html-файла, а затем строит CSSOM-дерево на основе проанализированного css-файла. script вызовет рендеринг страницы. Когда дерево DOM и дерево CSSOM созданы, постройте на их основе дерево рендеринга. После того, как дерево рендеринга построено, оно будет выложено в соответствии с деревом рендеринга. После завершения макета страница наконец отрисовывается с использованием пользовательского интерфейса браузера. На этот раз отображается вся страница.

(9)ПТС махнул четыре раза:Последним шагом является четырехсторонний волновой процесс отключения TCP. Если клиент считает, что передача данных завершена, ему необходимо отправить на сервер запрос на освобождение соединения. После того, как сервер получит запрос на освобождение соединения, он сообщит прикладному уровню о необходимости освободить TCP-соединение. Затем он отправит пакет ACK и войдет в состояние CLOSE_WAIT, что указывает на то, что соединение между клиентом и сервером было разорвано, и данные, отправленные клиентом, больше не принимаются. Но поскольку TCP-соединение является двунаправленным, сервер все равно может отправлять данные клиенту. Если в это время на сервере все еще есть незавершенные данные, он продолжит отправку, а после завершения отправит клиенту запрос на освобождение соединения, после чего сервер перейдет в состояние LAST-ACK. После того, как клиент получает запрос на освобождение, он отправляет серверу подтверждающий ответ, после чего клиент переходит в состояние TIME-WAIT. Это состояние будет длиться 2MSL (максимальное время жизни сегмента, которое относится к времени, в течение которого сегмент сообщения сохраняется в сети, и тайм-аут будет отброшен). войти в состояние ЗАКРЫТО. Когда сервер получает ответ подтверждения, он также переходит в состояние ЗАКРЫТО.

12. Понимание поддержки активности

По умолчанию в HTTP 1.0 создается новое соединение между клиентом и сервером для каждого запроса/ответа и отключается сразу после завершения.короткое соединение. При использовании режима Keep-Alive функция Keep-Alive постоянно поддерживает соединение между клиентом и сервером.При последующем запросе к серверу функция Keep-Alive избегает установления или повторного установления соединения,Длинное соединение. Он используется следующим образом:

• Версия HTTP1.0 не имеет Keep-alive по умолчанию (то есть по умолчанию будет отправляться keep-alive), поэтому для сохранения соединения необходимо вручную настроить отправкуConnection: keep-aliveполе. Если вы хотите отключить поддерживающее соединение, вам необходимо отправитьConnection:closeполе;
• HTTP1.1 предусматривает, что по умолчанию поддерживается длительное соединение, после завершения передачи данных TCP-соединение не разрывается, и данные продолжают передаваться по этому каналу под тем же доменным именем. Если его нужно закрыть, он должен быть отправлен клиентомConnection：closeполе заголовка.

Keep-Aliveпроцесс сборки:

• Клиент отправляет сообщение запроса на сервер, добавляя поле отправки Connection в заголовок.
• Сервер получает запрос и обрабатывает поле Connection
• Сервер отправляет поле Connection:Keep-Alive обратно клиенту
• Клиент получает поле Connection
• Соединение Keep-Alive успешно установлено

Сервер автоматически отключает процесс (т. е. Keep-alive не происходит):

• Клиент просто отправляет контентное сообщение на сервер (не содержит поле Connection)
• Сервер получает запрос и обрабатывает его
• Сервер возвращает запрошенный клиентом ресурс и закрывает соединение
• Клиент получает ресурс, обнаруживает, что поля Connection нет, и отключается.

Процесс отключения по запросу клиента:

• Клиент отправляет Connection:close field на сервер
• Сервер получает запрос и обрабатывает поле подключения
• Сервер повторяет ресурс ответа и отключается
• Клиент получает ресурс и отключается

Включить поддержку активностипреимущество:

• меньшее использование ЦП и памяти (из-за меньшего количества одновременных открытых подключений);
• Разрешить HTTP-конвейерную обработку запросов и ответов;
• Уменьшенный контроль перегрузки (меньше TCP-соединений);
• Уменьшена задержка для последующих запросов (больше не требуется рукопожатие);
• Сообщать об ошибках, не закрывая TCP-соединение;

Включить поддержку активностинедостаток:

• Длительное TCP-соединение может легко привести к недопустимому занятию системных ресурсов и трате системных ресурсов.

13. Какова производительность загрузки HTTP при наличии нескольких изображений на странице?

• существуетHTTP 1Максимальное количество TCP-соединений браузера с доменным именем равно 6, поэтому он будет запрашивать несколько раз. Можно использоватьМногодоменное развертываниерешать. Это может увеличить количество одновременных запросов и ускорить получение изображений страниц.
• существуетHTTP 2В этом случае многие ресурсы могут быть загружены в одно мгновение, поскольку HTTP2 поддерживает мультиплексирование и может отправлять несколько HTTP-запросов в одном TCP-соединении.

14. Каков алгоритм сжатия заголовков HTTP2?

Сжатие заголовков HTTP2 — это алгоритм HPACK. Установите «словарь» на обоих концах клиента и сервера, используйте порядковые номера для представления повторяющихся строк и используйте кодировку Хаффмана для сжатия целых чисел и строк, что может обеспечить высокую степень сжатия от 50% до 90%.

Конкретно:

• Используйте «таблицу заголовков» на стороне клиента и сервера для отслеживания и хранения пар ключ-значение, отправленных ранее, для тех же данных, которые больше не отправляются через каждый запрос и ответ;
• Таблица заголовков всегда существует во время соединения HTTP/2 и постепенно обновляется клиентом и сервером;
• Каждая новая пара ключ-значение заголовка либо добавляется в конец текущей таблицы, либо заменяет предыдущее значение в таблице.

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

15. Как выглядит сообщение HTTP-запроса?

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

• строка запроса
• заголовок запроса
• пустая строка
• тело запроса

в:(1) Строка запроса включает: поле метода запроса, поле URL и поле версии протокола HTTP. Они разделены пробелами. Например, GET /index.html HTTP/1.1. (2) Заголовок запроса: Заголовок запроса состоит из пар ключевое слово/значение, по одной паре в строке, а ключевое слово и значение разделяются английским двоеточием ":"

• User-Agent: Тип браузера, который сгенерировал запрос.
• Принять: список типов контента, распознаваемых клиентом.
• Хост: запрошенное имя хоста, позволяющее нескольким доменным именам использовать один и тот же IP-адрес, то есть виртуальный хост.

(3) Тело запроса: данные, передаваемые запросами, такими как post put

16. Как выглядит ответное сообщение HTTP?

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

• строка ответа
• заголовок ответа
• пустая строка
• тело ответа

• Строка ответа: состоит из версии сетевого протокола, кода состояния и фразы причины для кода состояния, например, HTTP/1.1 200 OK .
• Заголовки ответа: компоненты ответа
• Тело ответа: данные ответа сервера.

17. Преимущества и недостатки протокола HTTP

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

Протокол HTTP имеет следующеепреимущество:

• Поддерживает режим клиент/сервер
• Просто и быстро: когда клиент запрашивает услугу с сервера, ему нужно только передать метод запроса и путь. Из-за простоты HTTP-протокола размер программы HTTP-сервера невелик, поэтому скорость связи очень высока.
• нет соединения: Нет соединения, чтобы ограничить каждое соединение обработкой только одного запроса. После того, как сервер обработает запрос клиента и получит ответ клиента, он разорвет соединение, что может сэкономить время передачи.
• нет статуса: HTTP-протокол — это протокол без сохранения состояния, где состояние относится к контекстной информации процесса связи. Отсутствие состояния означает, что если предыдущая информация требуется для последующей обработки, она должна быть передана повторно, что может привести к увеличению объема данных, передаваемых за одно соединение. С другой стороны, сервер быстрее отвечает, когда ему не нужна предыдущая информация.
• гибкий: HTTP позволяет передавать объекты данных любого типа. Передаваемый тип помечен Content-Type.

Протокол HTTP имеет следующеенедостаток:

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

(1) В сообщении используется открытый текст (не зашифрованный), и содержимое может быть перехвачено; (2) Личность общающейся стороны не проверяется, поэтому она может быть замаскирована; (3) Целостность сообщения не может быть доказана, поэтому оно могло быть подделано;

18. Расскажите что-нибудь о HTTP 3.0

HTTP/3 реализует такие функции, как мультиплексирование потоков данных и надежность передачи, аналогичные TCP на основе протокола UDP, этот набор функций называется протоколом QUIC.

1. Функции управления потоком и надежностью передачи: QUIC добавляет уровень к UDP для обеспечения надежности передачи данных, обеспечивает повторную передачу пакетов, контроль перегрузки и некоторые другие функции TCP.
2. Встроенная функция шифрования TLS: QUIC в настоящее время использует TLS1.3, что снижает количество RTT, затрачиваемых на рукопожатия.
3. Мультиплексирование: в одном и том же физическом соединении может быть несколько независимых логических потоков данных, что реализует раздельную передачу потоков данных и решает проблему блокировки заголовка TCP.

4. Быстрое рукопожатие: поскольку оно основано на UDP, можно использовать 0 ~ 1 RTT для установления соединения.

19. Как насчет производительности протокола HTTP

Протокол HTTP основан на TCP/IP и используетответ на запросрежим связи, поэтому ключ к производительности лежит в этих двух пунктах.

• Длинное соединение

Протокол HTTP имеет два режима соединения: одно — постоянное соединение, а другое — непостоянное соединение. (1) Непостоянное соединение означает, что сервер должен устанавливать и поддерживать новое соединение для каждого запрошенного объекта. (2) При непрерывном соединении TCP-соединение по умолчанию не закрывается и может быть мультиплексировано несколькими запросами. Преимущество использования постоянных соединений заключается в том, что они позволяют избежать времени, необходимого для установления трехэтапного рукопожатия каждый раз, когда устанавливается TCP-соединение.

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

• В HTTP/1.0 каждый раз, когда инициируется запрос, должно создаваться новое TCP-соединение (трехстороннее рукопожатие), и это последовательный запрос, который позволяет безбоязненно устанавливать и отключать TCP-соединение, что увеличивает коммуникационные издержки. В этой версии используется непостоянное соединение, но вы можете добавить Connection: keep-a live, чтобы попросить сервер не закрывать TCP-соединение при запросе.
• предложено в HTTP/1.1Длинное соединениеметод связи, также называемый постоянным соединением. Преимущество этого метода в том, что он снижает дополнительные накладные расходы, вызванные повторным установлением и разрывом TCP-соединений, и снижает нагрузку на серверную сторону. В этой и более поздних версиях по умолчанию используются постоянные соединения. В настоящее время большинство браузеров поддерживают 6 постоянных подключений одновременно для одного и того же домена.

• Передача по трубопроводной сети

HTTP/1.1 использует метод длинного соединения, что делает возможной передачу по конвейерной сети.

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

• варенье в начале очереди

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

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

20. Из каких компонентов состоит URL-адрес

Возьмите следующий URL-адрес в качестве примера:woohoo.aspx fan.com:8080/news/index. …

Как видно из приведенного выше URL-адреса, полный URL-адрес состоит из следующих частей:

• Часть соглашения: протокольная часть URL-адреса — «http:», что означает, что веб-страница использует протокол HTTP. В Интернете могут использоваться различные протоколы, такие как HTTP, FTP и т. д. В данном примере используется протокол HTTP. "//" после "HTTP" является разделителем;
• Часть доменного имени: часть доменного имени URL-адреса "www.aspxfans.com». В URL-адресе IP-адрес также может использоваться как доменное имя.
• Портовая секция: За именем домена следует порт, а «:» используется в качестве разделителя между именем домена и портом. Порт не является обязательной частью URL-адреса. Если часть порта не указана, будет использоваться порт по умолчанию (порт по умолчанию для протокола HTTP — 80, а порт по умолчанию для протокола HTTPS — 443);
• раздел виртуального каталога: От первого "/" после имени домена до последнего "/" это часть виртуального каталога. Виртуальный каталог также не является необходимой частью URL-адреса. Виртуальный каталог в этом примере — «/news/»;
• часть имени файла: От последнего "/" после имени домена до "?", это часть имени файла, если нет "?", он начинается с последнего "/" после имени домена до "#", что файловая часть, Если нет "?" и "#", то от последнего "/" после имени домена до конца - это часть имени файла. Имя файла в этом примере — «index.asp». Часть имени файла не является обязательной частью URL. Если эта часть опущена, используется имя файла по умолчанию;
• анкерная часть: От начала "#" до конца это якорная часть. Якорной частью в этом примере является «имя». Якорная часть также не является обязательной частью URL-адреса;
• Раздел параметров: Часть от "?" до "#" является частью параметра, также известной как часть поиска и часть запроса. Часть параметра в этом примере — «boardID=5&ID=24618&page=1». Параметр может иметь несколько параметров, и в качестве разделителя между параметрами используется «&».

21. Какие заголовки HTTP-запросов связаны с кэшированием

Сильный кеш:

• Expires
• Cache-Control

Согласовать кеш:

• Etag, если не совпадает
• Last-Modified, If-Modified-Since

2. HTTPS-протокол

1. Что такое протокол HTTPS?

Безопасный протокол передачи гипертекста (сокращенно HTTPS) — это протокол передачи для безопасного обмена данными по компьютерным сетям. HTTPS взаимодействует через HTTP, используя SSL/TLS для шифрования пакетов. Основная цель HTTPS — обеспечить аутентификацию серверов веб-сайтов и защитить конфиденциальность и целостность передаваемых данных.Протокол HTTP принимаетпередача открытого текстаинформация существуетподслушивание информации,фальсификация информацииизахват информациириски, в то время как протокол TLS/SSLАутентификация,шифрование информациииПроверка целостностифункции, чтобы избежать таких проблем.

Основная обязанность уровня безопасности состоит в том, чтобыШифрование данных инициированного HTTP-запросаиРасшифровать полученный HTTP-контент.

2. Как работает TLS/SSL

TLS/SSLполное имяПротокол безопасного транспортного уровня(Безопасность транспортного уровня) представляет собой уровень протокола безопасности между TCP и HTTP, не влияет на исходный протокол TCP и протокол HTTP, поэтому использование HTTPS в основном не требует слишком большой модификации страниц HTTP.

Реализация функций TLS/SSL в основном опирается на три основных алгоритма:хэш-функция,Симметричное шифрование,Асимметричное шифрование. Эти три типа алгоритмов работают следующим образом:

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

(1) Хэш-функция

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

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

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

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

Общие алгоритмы симметричного шифрования включают AES-CBC, DES, 3DES, AES-GCM и т. д. Один и тот же ключ может использоваться для шифрования и дешифрования информации. Только путем овладения секретным ключом можно получить информацию и предотвратить подслушивание информации.Способ связи один на один.

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

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

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

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

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

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

3. Что такое цифровой сертификат?

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

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

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

4. Процесс связи HTTPS (рукопожатие)

Процесс связи HTTPS выглядит следующим образом:

1. Клиент инициирует запрос к серверу, и запрос включает номер используемой версии протокола, сгенерированное случайное число и метод шифрования, поддерживаемый клиентом.
2. После того, как сервер получает запрос, он подтверждает метод шифрования, используемый обеими сторонами, и выдает сертификат сервера и случайное число, сгенерированное сервером.
3. После того, как клиент подтвердит, что сертификат сервера действителен, он генерирует новое случайное число, шифрует случайное число с помощью открытого ключа в цифровом сертификате и отправляет его на сервер. А также предоставит хеш-значение всего предыдущего контента для проверки сервером.
4. Сервер использует свой закрытый ключ для расшифровки случайного числа, отправленного клиентом. И предоставьте хеш-значение всего предыдущего контента для проверки клиента.
5. Клиент и сервер используют три предыдущих случайных числа в соответствии с согласованным методом шифрования для создания ключа диалога, который используется в последующих диалогах для шифрования информации.

5. Особенности HTTPS

HTTPSпреимуществоследующее:

• Использование протокола HTTPS может аутентифицировать пользователей и серверы, чтобы гарантировать, что данные отправляются на правильный клиент и сервер;
• Использование протокола HTTPS может выполнять зашифрованную передачу и аутентификацию личности, а связь становится более безопасной, предотвращая кражу и изменение данных в процессе передачи и обеспечивая безопасность данных;
• HTTPS является наиболее безопасным решением в текущей архитектуре, хотя он и не является абсолютно безопасным, но значительно увеличивает стоимость атак типа «человек посередине»;

HTTPSнедостатокследующее:

• HTTPS необходимо выполнять шифрование и дешифрование как на стороне сервера, так и на стороне клиента, что потребляет больше ресурсов сервера и усложняет процесс;
• Фаза рукопожатия протокола HTTPS занимает много времени и увеличивает время загрузки страницы;
• SSL-сертификаты платные, и чем мощнее сертификат, тем выше стоимость;
• Потребление ресурсов на стороне сервера соединения HTTPS намного выше, а поддержка веб-сайтов с немного большим количеством посетителей требует больших инвестиций;
• SSL-сертификат должен быть привязан к IP-адресу, а несколько доменных имен не могут быть привязаны к одному и тому же IP-адресу.

6. HTTPSКак гарантируется безопасность?

Сначала поймите две концепции:

• Симметричное шифрование: то есть обе стороны связи используют один и тот же ключ для шифрования и дешифрования.Хотя симметричное шифрование является простым и имеет хорошую производительность, оно не может решить проблему отправки ключа другой стороне в первый раз, и это легко взломать.Гостевой ключ перехвата.
• Асимметричное шифрование:

1. закрытый ключ + открытый ключ = пара ключей
2. То есть данные, зашифрованные закрытым ключом, могут быть расшифрованы только соответствующим открытым ключом, а данные, зашифрованные открытым ключом, могут быть расшифрованы только соответствующим закрытым ключом.
3. Поскольку обе стороны в общении имеют свои собственные пары ключей, обе стороны будут отправлять свои открытые ключи другой стороне перед общением.
4. Затем другая сторона берет этот открытый ключ для шифрования данных и отвечает другой стороне.Когда другая сторона присутствует, другая сторона расшифровывает их своим собственным закрытым ключом.

Хотя асимметричное шифрование более безопасно, проблема в том, что оно очень медленное и влияет на производительность.

Решение:

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

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

Поэтому в настоящее время требуется безопасный сторонний сертификат (CA), чтобы подтвердить подлинность удостоверения и предотвратить его атаку со стороны посредника. Сертификат включает в себя: эмитента, цель сертификата, открытый ключ пользователя, закрытый ключ пользователя, алгоритм HASH пользователя, время истечения срока действия сертификата и т. д.

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

Цифровая подпись заключается в использовании собственного HASH-алгоритма CA для HASH содержимого сертификата для получения дайджеста, а затем его шифрования с помощью закрытого ключа CA для окончательного формирования цифровой подписи. Когда кто-то отправляет свой сертификат, я использую тот же хеш-алгоритм, чтобы снова создать дайджест сообщения, а затем использую открытый ключ ЦС для расшифровки цифровой подписи, чтобы получить дайджест сообщения, созданный ЦС.Знайте, была ли подделана середина. В это время безопасность связи может быть гарантирована в наибольшей степени.

3. Код состояния HTTP

Типы кодов состояния:

категория	причина	описывать
1xx	Информационная (код информационного статуса)	Принятый запрос обрабатывается
2xx	Успех (код состояния успеха)	Запрос обрабатывается нормально
3xx	Перенаправление (код состояния перенаправления)	Требуется дополнительное действие — завершить запрос
4xx	Ошибка клиента (код состояния ошибки клиента)	Сервер не смог обработать запрос
5xx	Ошибка сервера (код состояния ошибки сервера)	Ошибка обработки запроса сервером

1. 2XX (Код успешного завершения)

Код состояния 2XX указывает на то, что запрос был обработан нормально.

(1) 200 ОК

200 OK указывает, что запрос, отправленный клиентом, был нормально обработан сервером.

(2) 204 Нет содержимого

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

(3) 206 Частичное содержание

Этот код состояния указывает, что клиент сделал запрос диапазона, а сервер выполнил эту часть запроса GET. Ответное сообщение содержит содержимое сущности диапазона, указанного Content-Range.

2. 3XX (код состояния перенаправления перенаправления)

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

(1) 301 Перемещено навсегда

Постоянный редирект.Этот код состояния указывает, что запрошенному ресурсу был назначен новый URI, и URI, указанный ресурсом, следует использовать в будущем. Новый URI будет указан в поле заголовка Location в заголовке ответа HTTP. Если пользователь сохранил исходный URI в качестве закладки, закладка будет повторно сохранена в соответствии с новым URI в Location. В то же время, когда поисковая система сканирует новый контент, она также заменяет старый URL-адрес перенаправленным URL-адресом.

используемые сцены:

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

(2) 302 Найдено

Временная переадресация.Этот код состояния указывает, что запрошенный ресурс выделен новому URI, и есть надежда, что пользователь (на этот раз) сможет использовать новый URI для доступа к ресурсу. Аналогично коду состояния 301 Moved Permanently, но ресурс, представленный 302, не перенаправляется постоянно, а только временно. То есть URI, соответствующий перемещенному ресурсу, может измениться в будущем. Если пользователь сохраняет URI в качестве закладки, но не обновляет закладку, как при появлении кода состояния 301, но по-прежнему сохраняет URI, соответствующий странице, которая вернула код состояния 302. В то же время поисковые системы сканируют новый контент, сохраняя старые URL-адреса. Поскольку сервер возвращает код 302, поисковая система считает новый URL временным.

используемые сцены:

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

(3) 303 См. Другое

Этот код состояния указывает, что, поскольку для ресурса, соответствующего запросу, существует другой URI, для получения запрошенного ресурса следует использовать метод GET. Код состояния 303 и код состояния 302 Found имеют схожие функции, но код состояния 303 ясно указывает, что клиент должен использовать метод GET для получения ресурса.

Код состояния 303 обычно используется в качестве возвращаемого результата операции PUT или POST.Он указывает, что ссылка перенаправления указывает не на недавно загруженный ресурс, а на другую страницу, например страницу подтверждения сообщения или страницу хода загрузки. Метод запроса перенаправленной страницы всегда должен использовать GET.

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

• Когда возвращаются коды состояния ответа 301, 302 и 303, почти все браузеры меняют POST на GET и удаляют тело в сообщении запроса, а затем запрос будет автоматически отправлен снова.
• Стандарты 301 и 302 запрещают менять метод POST на метод GET, но на практике это делают все.

(4) 304 Не изменено

Связан с кешем браузера.Этот код состояния указывает, что когда клиент отправляет условный запрос, сервер разрешает этому запросу доступ к ресурсу, но условие не выполняется. Код состояния 304 возвращается без какой-либо части тела ответа. 304, хотя и относится к категории 3XX, не имеет ничего общего с редиректами.

Условный запрос (условный запрос HTTP): используйте метод Get для запроса, сообщение запроса содержит (if-match,if-none-match,if-modified-since,if-unmodified-since,if-range) в любом заголовке.

Код состояния 304 не является ошибкой, но сообщает клиенту, что кеш есть, и данные в кеше используются напрямую. На страницу возвращается только информация заголовка, а контентная часть отсутствует, что в определенной степени повышает производительность веб-страницы.

(5) 307 Временное перенаправление

307 означает временную переадресацию.Этот код состояния имеет то же значение, что и 302 Found, хотя стандарт 302 запрещает превращение POST в GET, но на практике он все же используется.

307 будет соответствовать стандартам браузера,не меняется с POST на GET. Однако разные браузеры по-прежнему имеют разные ситуации при работе с запросами. Спецификация требует, чтобы браузер продолжал размещать контент по адресу Location. Спецификация требует, чтобы браузер продолжал размещать контент по адресу Location.

3. 4XX (Код ошибки клиента)

Ответ 4XX указывает, что причиной ошибки является клиент.

(1) 400 Неверный запрос

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

(2) 401 Неавторизованный

Этот код состояния указывает, что для отправленного запроса требуется аутентификационная информация, прошедшая HTTP-аутентификацию (BASIC-аутентификация, DIGEST-аутентификация). Если запрос был сделан ранее, это означает, что аутентификация пользователя не удалась.

Ответ, содержащий код 401, ДОЛЖЕН включать заголовок WWW-Authenticate, применимый к запрошенному ресурсу, чтобы запросить информацию о пользователе. Когда браузер впервые получает ответ 401, появится диалоговое окно для аутентификации.

Ошибка 401 возникает, когда:

• 401.1 — Ошибка входа.
• 401.2 — Ошибка входа в систему из-за конфигурации сервера.
• 401.3 — Неавторизовано из-за ограничений ACL на ресурсы.
• 401.4 - Ошибка авторизации фильтра.
• 401.5 - Ошибка авторизации приложения ISAPI/CGI.
• 401.7 — Доступ запрещен политикой авторизации URL на веб-сервере. Этот код ошибки характерен для IIS 6.0.

(3) 403 Запрещено

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

IIS определяет ряд различных ошибок 403, которые указывают на более конкретные причины ошибок:

• 403.1 — Доступ к выполнению запрещен.
• 403.2 - Доступ для чтения запрещен.
• 403.3 - Запрещен доступ на запись.
• 403.4 — требуется SSL.
• 403.5 — требуется SSL 128.
• 403.6 - IP-адрес запрещен.
• 403.7 — требуется сертификат клиента.
• 403.8 — Доступ к сайту запрещен.
• 403.9 - Слишком много пользователей.
• 403.10 - Неверная конфигурация.
• 403.11 - Смена пароля.
• 403.12 - Отказано в доступе к таблице сопоставления.
• 403.13 — Сертификат клиента отозван.
• 403.14 - Листинг каталога отклонен.
• 403.15 — Превышен срок действия клиентской лицензии.
• 403.16 — Сертификат клиента не является доверенным или недействительным.
• 403.17 - Клиентский сертификат истек или еще не действителен
• 403.18 — запрошенный URL-адрес не может быть выполнен в текущем пуле приложений. Этот код ошибки характерен для IIS 6.0.
• 403.19 — невозможно выполнить CGI для клиентов в этом пуле приложений. Этот код ошибки характерен для IIS 6.0.
• 403.20 - Ошибка входа с паспортом. Этот код ошибки характерен для IIS 6.0.

(4) 404 Не найдено

Этот код состояния указывает, что запрошенный ресурс не может быть найден на сервере. Кроме того, его также можно использовать, когда серверная сторона отклоняет запрос и не хочет указывать причину. Ошибка 404 возникает, когда:

• 404.0 — (нет) — файл или каталог не найден.
• 404.1 — веб-сайт недоступен на запрошенном порту.
• 404.2 — Политика блокировки расширений веб-служб заблокировала этот запрос.
• 404.3 — политика сопоставления MIME заблокировала этот запрос.

(5) Метод 405 не разрешен

Этот код состояния указывает, что хотя метод, запрошенный клиентом, может быть распознан сервером, сервер запрещает использование этого метода. GET и HEAD, сервер всегда должен разрешать клиентский доступ. Клиент может проверить методы доступа, разрешенные сервером, с помощью метода OPTIONS (предварительная проверка) следующим образом.

Access-Control-Allow-Methods: GET,HEAD,PUT,PATCH,POST,DELETE

4. 5XX (Server Error код состояния ошибки сервера)

Ответ 5XX указывает на то, что на самом сервере произошла ошибка.

(1) 500 Внутренняя ошибка сервера

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

(2) 502 Плохой шлюз

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

• 502.1 - Время ожидания приложения CGI (Common Gateway Interface) истекло.
• 502.2 - Ошибка приложения CGI (общий интерфейс шлюза).

(3) 503 Служба недоступна

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

используемые сцены:

• Когда сервер отключен для обслуживания, он будет активно отвечать на запрос с кодом 503;
• nginx устанавливает ограничение скорости, если ограничение скорости будет превышено, будет возвращено 503.

(4) 504 Тайм-аут шлюза

Этот код состояния указывает на то, что сервер шлюза или прокси не может получить желаемый ответ в течение заданного времени. Он новичок в HTTP 1.1.

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

5. Резюме

(1) 2XX успеха

• 200 OK, что указывает на корректную обработку запроса от клиента на стороне сервера
• 204 Нет содержимого, что указывает на то, что запрос выполнен успешно, но ответное сообщение не содержит основной части сущности
• 205 Reset Content, указывающий на то, что запрос выполнен успешно, но ответное сообщение не содержит основной части сущности, но отличается от ответа 204 тем, что запрашивающему требуется сбросить содержимое
• 206 Частичный контент, сделайте запрос диапазона

(2) перенаправление 3XX

• 301 MOVED Навсегда, постоянное перенаправление, указывающее, что ресурсам был присвоен новый URL-адрес.
• 302 найдено, временное перенаправление, указывающее на то, что ресурсу временно присвоен новый URL
• 303 см. другое, что указывает на то, что для ресурса существует другой URL-адрес, и для получения ресурса следует использовать метод GET.
• 304 не модифицировано, что свидетельствует о том, что сервер разрешает доступ к ресурсу, но запрос не соответствует условиям из-за возникновения
• 307 временное перенаправление, временное перенаправление, похожее на 302, но ожидает, что клиент сохранит метод запроса без изменений и сделает запрос на новый адрес

(3) Ошибка клиента 4XX

• 400 неверный запрос, в сообщении запроса есть синтаксическая ошибка
• 401 неавторизованный, что указывает на то, что для отправленного запроса требуется информация аутентификации через HTTP-аутентификацию.
• 403 запрещено, что указывает на то, что доступ к запрошенному ресурсу был запрещен сервером
• 404 not found, указывающий на то, что запрошенный ресурс не найден на сервере

(4) Ошибка сервера 5XX

• 500 внутренняя ошибка сервера, указывающая на то, что при выполнении запроса произошла ошибка на стороне сервера
• 501 Not Implemented, указывающий, что сервер не поддерживает функцию, требуемую текущим запросом.
• Служба 503 недоступна, что указывает на то, что сервер временно перегружен или отключен на техническое обслуживание и не может обрабатывать запросы.

6. То же перенаправление,307,303,302разница?

302 — это код состояния протокола http 1.0. В версии http 1.1 были разработаны два 303 и 307 для уточнения кода состояния 302. 303 четко указывает, что клиент должен использовать метод get для получения ресурсов, и он перенаправит запрос POST в запрос GET. 307 будет следовать стандартам браузера и не изменится от поста к получению.

В-четвертых, введение протокола DNS

1. Что такое протокол DNS

концепция: DNS — это аббревиатура от Domain Name System (система доменных имен). Это распределенная база данных иерархических DNS-серверов, протокол прикладного уровня, который определяет, как хосты могут запрашивать эту распределенную базу данных. Это может облегчить людям доступ к Интернету без необходимости запоминать строки IP, которые могут быть напрямую прочитаны машинами.

эффект: доменное имя преобразуется в IP-адрес, клиент отправляет запрос доменного имени на DNS-сервер (у DNS-сервера есть собственный IP-адрес), а DNS-сервер сообщает клиенту IP-адрес веб-сервера.

2. DNS использует протоколы TCP и UDP?

DNS занимает порт 53 и использует протоколы TCP и UDP.(1) Используйте протокол TCP во время региональной передачи

• Вторичный сервер доменных имен будет периодически (обычно через 3 часа) опрашивать первичный сервер доменных имен, чтобы узнать, изменились ли данные. В случае каких-либо изменений будет выполнена передача зоны для синхронизации данных. Передачи зоны используют TCP вместо UDP, потому что объем данных, передаваемых синхронно, намного больше, чем у запроса-ответа.
• TCP — это надежное соединение, гарантирующее точность данных.

(2) Протокол UDP используется для разрешения доменных имен.

• Клиент запрашивает у DNS-сервера доменное имя, и возвращаемый контент обычно не превышает 512 байт, которые могут быть переданы по протоколу UDP. Нет необходимости проходить трехэтапное рукопожатие, поэтому нагрузка на DNS-сервер ниже, а ответ быстрее. Теоретически клиент также может указать использование TCP при запросе DNS-сервера, но на самом деле, когда настроено много DNS-серверов, они поддерживают только пакеты запросов UDP.

3. Полный процесс запроса DNS

Процесс разрешения DNS-сервером доменного имени:

• первый вКэш браузераНайдите соответствующий IP-адрес в
• отправить запрос налокальный DNS-сервер, запрос в кеше локального сервера доменных имен, если найден, вернуть результат поиска напрямую, если нет, перейти к следующему шагу
• локальный DNS-сервер длякорневой сервер именОтправьте запрос, корневой сервер доменных имен вернет адрес сервера доменных имен верхнего уровня запрашиваемого домена.
• локальный DNS-сервер длясервер доменных имен верхнего уровняОтправьте запрос, и сервер, принявший запрос, запрашивает свой собственный кеш.Если есть запись, он возвращает результат запроса.Если записи нет, он возвращает адрес соответствующего авторитетного сервера доменных имен следующего уровня.
• локальный DNS-сервер дляавторитетный сервер именОтправьте запрос, сервер доменных имен вернет соответствующий результат
• Локальный DNS-сервер сохраняет возвращенные результаты в кеше в следующий раз
• Локальный DNS-сервер возвращает результат в браузер

Например, для запросаwww.baidu.comЕсли нет кеша доменного имени, запрос будет отправлен на локальный DNS-сервер.Локальный DNS-сервер определит, есть ли кеш доменного имени.Если нет, то запрос будет отправлен на локальный DNS-сервер Затем на корневой сервер имен отправляется запрос, который возвращает список IP-адресов серверов имен верхнего уровня, отвечающих за домен .com. Затем локальный DNS-сервер отправляет запрос одному из серверов TLD, отвечающих за .com, а сервер TLD, отвечающий за .com, возвращает список IP-адресов авторитетных серверов доменных имен, ответственных за .baidu. Затем локальный DNS-сервер отправляет запрос одному из авторитетных серверов доменных имен, и, наконец, полномочный сервер доменных имен возвращает список IP-адресов, соответствующих именам хостов.

4. Итеративный запрос и рекурсивный запрос

На самом деле разрешение DNS — это процесс, включающий итерационные и рекурсивные запросы.

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

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

5. DNS-записи и сообщения

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

（Name，Value，Type，TTL）

Где TTL — это время жизни записи ресурса, которое определяет, как долго запись ресурса может кэшироваться другими DNS-серверами.

Существует четыре часто используемых значения Type, а именно A, NS, CNAME и MX, Различные значения Type имеют разные значения для соответствующих записей ресурсов:

• Если Type = A, Name — это имя хоста, а Value — IP-адрес, соответствующий имени хоста. Таким образом, запись — это ресурсная запись для A, которая обеспечивает стандартное сопоставление имени хоста с IP-адресом.
• Если Type = NS, Name — это доменное имя, а Value — это имя хоста DNS-сервера, ответственного за доменное имя. Эта запись в основном используется для запроса цепочки DNS, чтобы вернуть информацию о DNS-сервере, который необходимо запросить на следующем уровне.
• Если Type = CNAME, Name — это псевдоним, а Value — каноническое имя хоста для этого хоста. Эта запись используется для возврата запрашиваемому хосту канонического имени хоста, соответствующего имени хоста, тем самым сообщая запрашиваемому хосту запросить IP-адрес этого имени хоста. Основная цель псевдонимов хостов — предоставить простой псевдоним, который легко запомнить, задав несколько сложных имен хостов.
• Если Type = MX, Name — псевдоним почтового сервера, а Value — каноническое имя хоста почтового сервера. Его функция такая же, как и у CNAME, и для устранения недостатка, заключающегося в том, что каноническое имя хоста не способствует памяти.

5. Сетевая модель

1. Семиуровневая модель OSI

ISOЧтобы сделать сетевые приложения более популярными,OSIЭталонная модель.

(1) Прикладной уровень

OSIБлижайший к пользователю уровень в эталонной модели должен предоставлять интерфейс приложения для пользователя компьютера, а также напрямую предоставлять пользователю различные сетевые сервисы. Наши общие протоколы сетевых служб прикладного уровня:HTTP,HTTPS,FTP,POP3,SMTPЖдать.

• В клиенте и на сервере часто бывают запросы данных, и в этот раз используетсяhttp(hyper text transfer protocol)(超文本传输协议)илиhttps, Мы часто используем этот протокол при проектировании интерфейсов данных в бэкенде.
• FTPЭто протокол передачи файлов, в процессе разработки лично я им не занимался, но, думаю, на некоторых ресурсных сайтах, таких как百度网盘``迅雷должен основываться на этом протоколе.
• SMTPдаsimple mail transfer protocol（简单邮件传输协议）. В проекте этот протокол используется в функции входа в систему кода подтверждения электронной почты пользователя.

(2) Уровень представления

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

При разработке проекта для облегчения передачи данных можно использоватьbase64Кодировать и декодировать данные. Если разделить по функциям,base64Он должен работать на уровне представления.

(3) Сеансовый уровень

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

(4) Транспортный уровень

Транспортный уровень устанавливает сквозную связь хоста. Роль транспортного уровня заключается в предоставлении сквозных надежных и прозрачных услуг передачи данных для протоколов верхнего уровня, включая решение таких проблем, как контроль ошибок. и управление потоком. Этот уровень скрывает подробности передачи данных нижнего уровня от верхнего уровня, так что пользователь верхнего уровня видит только надежный путь передачи данных между двумя объектами передачи от хоста к хосту, который может контролироваться и устанавливаться пользователем. Как мы обычно говорим,TCP UDPЭто на этом уровне. Номер порта здесь является "концом".

(5) Сетевой уровень

Этот слой проходитIPАдресация используется для установления соединения между двумя узлами.Для пакетов, отправленных транспортным уровнем источника, выберите соответствующие узлы маршрутизации и коммутации и передайте их на транспортный уровень пункта назначения в соответствии с адресом правильно. обычно говорятIPЭтаж. Этот слой - то, что мы часто говоримIPуровень протокола.IPсоглашениеInternetОсновы. Мы можем понять это так, сетевой уровень определяет маршрут передачи пакета данных, а транспортный уровень определяет способ передачи пакета данных.

(6) Канальный уровень

Биты объединяются в байты, а байты объединяются в кадры, для доступа к среде используются адреса канального уровня (Ethernet использует MAC-адреса) и выполняется обнаружение ошибок. Сравнение между сетевым уровнем и канальным уровнем, из вышеприведенного описания, мы можем понять, что сетевой уровень планирует маршрут передачи пакета данных, а канальный уровень является маршрутом передачи. Однако на канальном уровне также добавлена ​​функция контроля ошибок.

(7) Физический уровень

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

Функции связи семиуровневой модели OSI: одноранговая связьВ одноранговой связи для передачи пакетов данных от источника к получателю каждый уровень модели OSI источника должен взаимодействовать с одноранговым уровнем получателя.Этот метод связи называется одноранговым. коммуникация. В процессе связи каждого уровня используйте для связи собственный протокол этого уровня.

2. Пятиуровневый протокол TCP/IP

TCP/IPпятиуровневый протокол иOSIСоответствующее отношение семиуровневого протокола выглядит следующим образом:

• прикладной уровень: Предоставляет услуги непосредственно процессу приложения. Протокол прикладного уровня определяет правила связи и взаимодействия между прикладными процессами.Различные приложения имеют разные протоколы прикладного уровня, такие как протокол HTTP (сервис World Wide Web), протокол FTP (передача файлов), протокол SMTP (электронная почта), DNS (доменное имя). ) запрос) и т.д.
• транспортный уровень: иногда также переводится как транспортный уровень, который отвечает за предоставление коммуникационных услуг для процессов на двух хостах. На этом уровне есть два основных протокола:
  • Протокол управления передачей (TCP): обеспечивает ориентированные на соединение и надежные услуги передачи данных.Основной единицей передачи данных является сегмент;
  • Протокол пользовательских дейтаграмм (UDP): Предоставляет услугу передачи данных без установления соединения с максимальной эффективностью, но не гарантирует надежность передачи данных.Основной единицей передачи данных является пользовательская дейтаграмма.
• интернет-уровень: иногда также переводится как уровень Интернета, который отвечает за предоставление услуг связи для двух хостов и доставку данных на целевой хост путем выбора соответствующего маршрута.
• канальный уровень: Отвечает за инкапсуляцию IP-датаграмм, передаваемых с сетевого уровня, в кадры и передачу кадров между двумя соседними узлами канала. Каждый кадр содержит данные и необходимую управляющую информацию (например, информацию о синхронизации, адресную информацию, ожидание контроля ошибок).
• физический слой: Убедитесь, что данные могут быть переданы на различных физических носителях, обеспечивая надежную среду для передачи данных.

Как видно из приведенного выше рисунка,TCP/IPкоэффициент моделиOSIМодель более компактна, в нее помещается应用层/表示层/会话层все интегрировано для应用层.

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

такой же,TCP/IPМетод связи пятиуровневого протокола также является одноранговой связью:

6. TCP и UDP

1. Понятие и характеристики TCP и UDP

И TCP, и UDP являются протоколами транспортного уровня, и оба они принадлежат к семейству протоколов TCP/IP:

(1) УДП

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

Его особенности заключаются в следующем:

1) Для без подключения

Прежде всего, UDP не нужно выполнять трехэтапное рукопожатие, чтобы установить соединение, как TCP, перед отправкой данных.Если вы хотите отправить данные, вы можете начать отправку. И это только портер пакетов данных, и он не будет выполнять никаких операций разделения и объединения пакетов данных.

Конкретно:

• На стороне отправителя прикладной уровень передает данные протоколу UDP транспортного уровня. UDP только добавит заголовок UDP к данным для идентификации протокола UDP, а затем передаст его на сетевой уровень.
• На принимающей стороне сетевой уровень передает данные на транспортный уровень, а UDP только удаляет заголовок IP и передает его на прикладной уровень без какой-либо операции сплайсинга.

2) Имеет функции одноадресной, многоадресной и широковещательной передачи

UDP поддерживает не только режим передачи «один к одному», но также поддерживает режимы «один ко многим», «многие ко многим» и «многие к одному», то есть UDP обеспечивает функции одноадресной, многоадресной и широковещательной передачи.

3) ориентированный на сообщение

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

4) Ненадежность

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

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

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

5) Заголовок невелик, и передача пакетов данных очень эффективна.

Заголовок UDP содержит следующие данные:

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

Поэтому заголовок UDP невелик, всего 8 байт, что намного меньше, чем по крайней мере 20 байт TCP, и он очень эффективен при передаче пакетов данных.

(2) TCPПолное название TCP — Transmission Control Protocol, который является ориентированным на соединение, надежным протоколом связи на транспортном уровне на основе потока байтов. TCP — это надежный протокол потоковой передачи, ориентированный на соединение (поток — это непрерывная структура данных).

Он имеет следующие особенности:

1) ориентированный на соединение

Ориентированность на соединение означает, что соединение должно быть установлено на обоих концах перед отправкой данных. Способ установления соединения — «трехстороннее рукопожатие», позволяющее установить надежное соединение. Установление соединения закладывает основу для надежной передачи данных.

2) Поддерживает только одноадресную передачу

Каждое соединение передачи TCP может иметь только две конечные точки, только передачу данных «точка-точка» и не поддерживает методы многоадресной и широковещательной передачи.

3) Ориентирован на поток байтов

В отличие от UDP, TCP не передает пакеты самостоятельно, а передает их потоком байтов без сохранения границ пакета.

4) Надежная передача

Для надежной передачи определение потери пакетов и битовых ошибок зависит от номера сегмента TCP и номера подтверждения. Чтобы обеспечить надежность передачи сообщений, TCP присваивает каждому пакету порядковый номер, а порядковый номер также обеспечивает упорядоченный прием пакетов, передаваемых принимающему объекту. Затем объект-получатель отправляет обратно соответствующее подтверждение (ACK) для успешно полученных байтов; если объект-отправитель не получает подтверждение в течение разумной задержки приема-передачи (RTT), то соответствующие данные (при условии, что они потеряны) будут переданы повторно.

5) Обеспечьте контроль перегрузки

Когда сеть перегружена, TCP может снизить скорость и количество данных, вводимых в сеть, и уменьшить перегрузку.

6) Обеспечить полнодуплексную связь

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

2. Разница между TCP и UDP

	UDP	TCP
подключаться ли	нет соединения	ориентированный на соединение
Это надежно	Ненадежная передача, не используются управление потоком и контроль перегрузки	Надежная передача (порядок и правильность данных) с использованием управления потоком и контролем перегрузки
Количество объектов подключения	Поддержка интерактивного общения «один к одному», «один ко многим», «многие к одному» и «многие ко многим».	общение только один на один
способ передачи	ориентированный на сообщение	байтовый поток
накладные расходы заголовка	Заголовок небольшой, всего 8 байт.	Заголовок минимум 20 байт, максимум 60 байт
Применимая сцена	Идеально подходит для приложений реального времени, таких как видеоконференции, прямые трансляции	Идеально подходит для приложений, требующих надежной передачи, таких как передача файлов

3. Сценарии использования TCP и UDP

• Сценарии применения TCP:Сценарии с относительно низкими требованиями к эффективности, но относительно высокими требованиями к точности. Поскольку во время передачи требуются такие операции, как подтверждение данных, повторная передача и сортировка, эффективность не так высока, как у UDP. Например: передача файлов (высокая точность и высокие требования, но скорость может быть относительно низкой), получение почты, удаленный вход в систему.
• Сценарии применения UDP:Сценарии с относительно высокими требованиями к эффективности и относительно низкими требованиями к точности. Например: QQ-чат, онлайн-видео, VoIP (обмен мгновенными сообщениями, высокие требования к скорости, но случайные прерывания не являются большой проблемой, а механизм ретрансляции здесь вообще не может быть использован), широковещательная связь (трансляция, мультикаст).

4. Почему протокол UDP ненадежен?

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

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

5. Механизм повторной передачи TCP

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

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

6. Механизм управления перегрузкой TCP

Механизм управления перегрузкой TCP в основном включает следующие четыре механизма:

• медленный старт (медленный старт)
• предотвращение перегрузки
• быстрая ретрансляция
• быстрое восстановление

(1) Медленный старт (медленный старт)

• Установите cwnd = 1 в начале отправки (cwnd относится к окну перегрузки)
• Идеи: сначала не отправляйте много данных, а сначала проверьте уровень перегрузки сети и увеличьте размер окна перегрузки от маленького до большого.
• Чтобы предотвратить перегрузку сети, вызванную чрезмерным ростом cwnd, установите порог медленного запуска (переменная состояния ssthresh)
  • Когда cnwd
  • Когда cnwd = ssthresh, можно использовать либо алгоритм медленного старта, либо алгоритм предотвращения перегрузки.
  • Когда cnwd > ssthresh, используйте алгоритм предотвращения перегрузки.

(2) Предотвращение заторов

• Предотвращение перегрузки может быть не в состоянии полностью избежать перегрузки.Это означает, что окно перегрузки управляется линейно на этапе предотвращения перегрузки, так что сеть не подвержена перегрузке.
• Идея: Пусть окно перегрузки cwnd увеличивается медленно, то есть увеличивайте окно управления перегрузкой отправителя на единицу каждый раз, когда истекает время возврата RTT.
• Будь то фаза медленного запуска или фаза предотвращения перегрузки, пока отправитель определяет, что сеть перегружена, порог медленного запуска устанавливается равным половине размера окна отправки при возникновении перегрузки. Затем установите окно перегрузки на 1 и выполните алгоритм медленного запуска. как показано на рисунке:Среди них основанием для суждения о перегрузке сети является отсутствие подтверждения.Хотя отказ в получении подтверждения может быть вызван потерей пакетов по другим причинам, это рассматривается как перегрузка, поскольку ее невозможно определить.

(3) Быстрая ретрансляция

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

(4) Быстрое восстановление

• Когда отправитель получает три последовательных подтверждения, выполняется алгоритм «сокращения умножения», чтобы вдвое уменьшить пороговое значение ssthresh. Но тогда алгоритм медленного старта не выполняется.
• Учитывая, что если сеть перегружена, она не получит несколько дубликатов подтверждений, отправитель теперь думает, что сеть не может быть перегружена. Таким образом, вместо выполнения алгоритма медленного запуска в это время установите cwnd на размер ssthresh, а затем выполните алгоритм предотвращения перегрузки.

7. Механизм управления потоком TCP

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

• Когда соединение установлено, каждый конец соединения выделяет буфер для хранения входящих данных и отправляет размер буфера на другой конец.
• Когда данные поступают, получатель отправляет подтверждение с оставшимся размером буфера. (Размер оставшегося буферного пространства называется окном, а уведомление, указывающее размер окна, называется объявлением окна. Получатель включает объявление окна в каждое отправляемое им подтверждение.)
• Если приложение-получатель может считывать данные так же быстро, как они поступают, получатель будет отправлять положительное объявление окна с каждым подтверждением.
• Если отправитель работает быстрее, чем получатель, полученные данные в конечном итоге заполнят буфер получателя, в результате чего получатель объявит нулевое окно. Когда отправитель получает объявление о нулевом окне, он ДОЛЖЕН прекратить отправку до тех пор, пока получатель повторно не объявит о положительном окне.

8. Надежный транспортный механизм TCP

Надежный механизм передачи TCP основан на протоколе непрерывного ARQ и протоколе скользящего окна.

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

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

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

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

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

(1) Трехстороннее рукопожатие

Трехстороннее рукопожатие (Three-way Handshake) фактически означает, что при установлении TCP-соединения клиенту и серверу необходимо отправить в общей сложности 3 пакета. Основная функция трехэтапного рукопожатия состоит в том, чтобы подтвердить нормальные возможности обеих сторон по приему и отправке и указать свои собственные порядковые номера инициализации для подготовки к последующей надежной передаче. По сути, это подключение к указанному порту сервера, установление TCP-соединения, синхронизация серийных номеров и номеров подтверждения обеих сторон и обмен информацией о размере TCP-окна.

В начале клиент находится в состоянии Closed, а сервер — в состоянии Listen.

• Первое рукопожатие: клиент отправляет сообщение SYN на сервер и указывает порядковый номер инициализации клиента ISN.В это время клиент находится в состоянии SYN_SEND.

Бит синхронизации в заголовке — SYN=1, начальный порядковый номер — seq=x, а сегмент с SYN=1 не может нести данные, но используется порядковый номер.

• Второе рукопожатие: после того, как сервер получит сообщение SYN от клиента, он ответит своим собственным сообщением SYN, а также укажет свой собственный порядковый номер инициализации ISN. При этом в качестве значения ACK будет использоваться ISN + 1 клиента, что указывает на то, что он получил SYN клиента, а сервер находится в состоянии SYN_REVD.

В сегменте подтверждения SYN=1, ACK=1, номер подтверждения ack=x+1, начальный порядковый номер seq=y

• Третье рукопожатие: после того, как клиент получит сообщение SYN, он отправит сообщение ACK. Конечно, он также использует ISN + 1 сервера в качестве значения ACK, указывая, что он получил сообщение SYN сервера. клиент в состоянии ESTABLISHED. После того, как сервер получает сообщение ACK, он также находится в состоянии ESTABLISHED.В это время две стороны установили соединение.

Сегмент подтверждения ACK=1, номер подтверждения ack=y+1, порядковый номер seq=x+1 (изначально seq=x, поэтому второму сегменту требуется +1), сегмент ACK может переносить данные, а не перенос данных не использует порядковые номера .

Так почему три рукопожатия? Ты не можешь сделать это дважды?

• Чтобы подтвердить, что возможности приема и отправки обеих сторон в норме
• Если используются два рукопожатия, произойдет следующее:

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

Проще говоря, это три шага:

• Первое рукопожатие:Клиент отправляет сегмент запроса на соединение на сервер. Этот сегмент содержит свой собственный начальный порядковый номер для передачи данных. После отправки запроса клиент переходит в состояние SYN-SENT.
• Второе рукопожатие:После того, как сервер получит сегмент запроса на соединение, если он согласится на соединение, он отправит ответ, и ответ также будет содержать свой собственный начальный порядковый номер передачи данных.После завершения передачи он войдет в состояние SYN-RECEIVED.
• Третье рукопожатие:При ответе на клиент получает соглашение об соединении, но и отправить на сервер подтверждающее сообщение. Клиентский конец сделал этот сегмент после ввода установленного состояния, сервер принимает этот ответ также после ввода установленного состояния, то соединение установлено.

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

(2) Волна четыре раза

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

• Первая волна: клиент отправит сообщение FIN, в котором будет указан серийный номер. В этот момент клиент находится в состоянии FIN_WAIT1.

То есть отправьте сегмент освобождения соединения (FIN=1, порядковый номер seq=u), снова прекратите отправку данных, активно закройте TCP-соединение, войдите в состояние FIN_WAIT1 (ожидание завершения 1) и дождитесь подтверждения от сервера. .

• Вторая волна: после того, как сервер получит FIN, он отправит сообщение ACK и использует значение серийного номера клиента + 1 в качестве значения серийного номера сообщения ACK, указывая, что сообщение клиента было получено. серверная часть в состоянии CLOSE_WAIT.

То есть после того, как сервер получает сегмент освобождения соединения, он отправляет сегмент подтверждения (ACK=1, номер подтверждения ack=u+1, порядковый номер seq=v), и сервер переходит в состояние CLOSE_WAIT (ожидание закрытия). на этот раз TCP в полузакрытом состоянии освобождает соединение от клиента к серверу. После того, как клиент получает подтверждение от сервера, он переходит в состояние FIN_WAIT2 (ожидание завершения 2) и ожидает сегмента освобождения соединения, отправленного сервером.

• Третья волна: Если сервер тоже хочет отключиться, как и первая волна клиента, отправьте сообщение FIN и укажите серийный номер. В этот момент сервер находится в состоянии LAST_ACK.

То есть у сервера нет данных для отправки клиенту, сервер отправляет сегмент освобождения соединения (FIN=1, ACK=1, порядковый номер seq=w, номер подтверждения ack=u+1), и сервер вводит LAST_ACK (окончательное подтверждение) статус, ожидание подтверждения от клиента.

• Четвертая волна: после того, как клиент получает FIN, он также отправляет сообщение ACK в качестве ответа и использует значение серийного номера сервера + 1 в качестве значения серийного номера своего собственного сообщения ACK. Состояние TIME_WAIT. Требуется некоторое время, чтобы гарантировать, что сервер войдет в состояние CLOSED после получения собственного сообщения ACK.После того, как сервер получит сообщение ACK, он закроет соединение и будет находиться в состоянии CLOSED.

То есть после того, как клиент получает от сервера сегмент освобождения соединения, он отправляет сегмент подтверждения (ACK=1, seq=u+1, ack=w+1), и клиент переходит в состояние TIME_WAIT (время ожидания). В это время TCP не освобождается, и клиент переходит в состояние CLOSED только после того, как время, установленное таймером ожидания, равно 2MSL.

Так зачем же нужно махать четыре раза?

Поскольку сервер получает сообщение запроса SYN-подключения к клиенту, вы можете отправлять пакеты SYN + ACK напрямую. Там, где пакет ACK используется для ответа, сообщение SYN используется для синхронизации. Но когда соединение закрыто, когда сервер получает пакет FIN, он, скорее всего, немедленно закроет сокет, поэтому я могу ответить только на сообщение ACK, сообщив клиенту: «Я получил сообщение fin». Только дождавшись, пока все сообщения на моем сервере будут отправлены, я могу отправить пакет FIN, поэтому я не могу отправить его вместе, поэтому мне нужно четыре раза.

Проще говоря, есть четыре шага:

• Первая волна:Если клиент считает, что передача данных завершена, ему необходимо отправить на сервер запрос на освобождение соединения.
• вторая волна: после того, как сервер получит запрос на освобождение соединения, он сообщит прикладному уровню о необходимости освободить TCP-соединение. Затем он отправит пакет ACK и войдет в состояние CLOSE_WAIT, что указывает на то, что соединение между клиентом и сервером было разорвано, и данные, отправленные клиентом, больше не принимаются. Но поскольку TCP-соединение является двунаправленным, сервер все равно может отправлять данные клиенту.
• Третья волна: Если в это время на сервере все еще есть незавершенные данные, он продолжит отправку, а после завершения отправит клиенту запрос на освобождение соединения, а затем сервер перейдет в состояние LAST-ACK.
• Четвертая волна:После того, как клиент получает запрос на освобождение, он отправляет серверу подтверждающий ответ, после чего клиент переходит в состояние TIME-WAIT. Это состояние будет длиться 2MSL (максимальное время жизни сегмента, которое относится к времени, в течение которого сегмент сообщения сохраняется в сети, и тайм-аут будет отброшен). войти в состояние ЗАКРЫТО. Когда сервер получает ответ подтверждения, он также переходит в состояние ЗАКРЫТО.

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

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

10. Что такое липкие пакеты TCP и как с ними бороться?

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

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

Давайте рассмотрим пример, вызвав send два раза подряд, чтобы отправить два фрагмента данных data1 и data2 соответственно.На принимающей стороне встречаются следующие распространенные ситуации: A. Сначала принимаются данные1, затем принимаются данные2. B. Сначала получить часть данных1, затем получить остальную часть данных1 и все данные2. C. Сначала получены все данные data1 и часть данных data2, а затем получены остальные данные data2. D. Все данные data1 и data2 принимаются одновременно.

Среди них BCD является нашим распространенным случаем липких пакетов.Для решения проблемы липких пакетов, общие решения:

• Время ожидания перед отправкой несколько раз: Вам нужно только немного подождать перед выполнением следующей отправки. Подходит для сценариев с очень низкой частотой взаимодействия. Недостатки также очевидны. Для более частых сценариев эффективность передачи воды слишком низкая, но почти не нужно что-то делать.
• Отключить алгоритм Нэгла: отключить алгоритм Нейгла.В Node.js вы можете использовать метод socket.setNoDelay() для отключения алгоритма Нейгла, чтобы каждая отправка не буферизировалась и не отправлялась напрямую. Этот метод больше подходит для сценариев, когда данные, отправляемые каждый раз, относительно велики (но не так велики, как файл), а частота не особенно высока. Если объем данных, отправляемых каждый раз, относительно невелик, а частота особенно высока, закрытие Nagle полностью обречено на провал. Кроме того, этот метод не подходит для плохих условий сети, потому что алгоритм Nagle представляет собой объединение пакетов на стороне сервера.Если данные TCP не могут быть получены вовремя, это приведет к буферизации нескольких пакетов на стороне клиента и их залипанию. к пакетам. (Если общение происходит в стабильной компьютерной комнате, то эта вероятность относительно мала и ею можно пренебречь)
• Чтобы упаковать/распаковать:Упаковка/распаковка является распространенным решением в отрасли. То есть перед отправкой каждого пакета данных поместите некоторые характеристические данные до/после него, а затем разделите каждый пакет данных в соответствии с характеристическими данными при получении данных.

11. ПочемуudpНе прилипает к сумке?

• Протокол TCP — это протокол, ориентированный на поток, а UDP — протокол, ориентированный на передачу сообщений. Сегмент UDP — это сообщение, и приложение должно извлекать данные в единицах сообщений и не может извлекать ни одного байта данных за раз.
• UDP имеет защищенные границы сообщения, и каждый пакет UDP имеет заголовок сообщения (информация, такая как адрес источника сообщения, порт и т. д.), чтобы принимающая сторона могла легко отличить и обработать его. Протокол передачи передает данные как независимое сообщение в Интернете, и получатель может только получить независимое сообщение. Получатель может получить только один пакет данных, отправленный отправителем за раз.Если размер полученных данных меньше, чем размер данных, отправленных отправителем за один раз, часть данных будет потеряна.Даже если это потерян, получатель не будет получен дважды.

7. Веб-сокет

1. Понимание WebSocket

WebSocket — это браузер и сервер, предоставляемые HTML5.полнодуплексная связьОн относится к протоколу прикладного уровня. Он основан на транспортном протоколе TCP и мультиплексирует канал квитирования HTTP. Браузеру и серверу нужно выполнить только одно рукопожатие, и между ними может быть установлено постоянное соединение, и может выполняться двусторонняя передача данных.

Появление WebSocket устраняет недостатки полудуплексной связи. Его самые большие особенности:Сервер может активно отправлять сообщения клиенту, и клиент также может активно отправлять сообщения серверу.

Принцип веб-сокета: клиент уведомляет сервер WebSocket о событии со всеми идентификаторами получателей (идентификаторами получателей), а сервер уведомляет всех активных клиентов сразу после получения, только тех, чьи идентификаторы находятся в последовательности идентификаторов получателей. Клиент будет обрабатывать это событие. ​

Особенности WebSocket заключаются в следующем:

• Поддержка двусторонней связи, более в режиме реального времени
• Может отправлять текст или бинарные данные''
• На основе протокола TCP реализация сервера относительно проста.
• Формат данных относительно легкий, потери производительности невелики, а связь эффективна.
• Нет ограничений на одно и то же происхождение, клиенты могут связываться с любым сервером
• Идентификатор протокола — ws (или wss, если он зашифрован), а URL-адрес сервера — это URL-адрес.
• Он имеет хорошую совместимость с протоколом HTTP. Порты по умолчанию также 80 и 443, а протокол HTTP используется на этапе рукопожатия, поэтому его нелегко экранировать во время рукопожатия, и он может проходить через различные прокси-серверы HTTP.

Использование Websocket выглядит следующим образом:​

В клиенте:

// 在index.html中直接写WebSocket，设置服务端的端口号为 9999
let ws = new WebSocket('ws://localhost:9999');
// 在客户端与服务端建立连接后触发
ws.onopen = function() {
    console.log("Connection open."); 
    ws.send('hello');
};
// 在服务端给客户端发来消息的时候触发
ws.onmessage = function(res) {
    console.log(res);       // 打印的是MessageEvent对象
    console.log(res.data);  // 打印的是收到的消息
};
// 在客户端与服务端建立关闭后触发
ws.onclose = function(evt) {
  console.log("Connection closed.");
}; 

2. Реализация обмена мгновенными сообщениями: разница между коротким опросом, длинным опросом, SSE и WebSocket?

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

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

Основная идея длинных опросов:Сначала клиент инициирует запрос к серверу.Когда сервер получает запрос от клиента, сервер не отвечает напрямую, а сначала приостанавливает запрос, а затем определяет, были ли обновлены данные сервера. Если есть обновление, оно ответит, если нет данных, оно вернется через определенное время. После обработки информации, возвращенной сервером, клиентский обработчик ответов JavaScript снова отправит запрос и повторно установит соединение. Преимущество длинного опроса по сравнению с коротким опросом заключается в значительном сокращении количества ненужных HTTP-запросов, что по сравнению с ним экономит ресурсы. Недостатком длительного опроса является то, что зависание соединения также может привести к напрасной трате ресурсов.

Основная идея SSE:Сервер использует потоковую информацию для отправки информации на сервер. Строго говоря, протокол http не может позволить серверу активно передавать информацию. Однако существует обходной путь, когда сервер объявляет клиенту, что следующей отправкой является информация о потоке. То есть отправляется не одноразовый пакет, а поток данных, который будет отправляться непрерывно. В это время клиент не будет закрывать соединение и всегда будет ждать новый поток данных, отправленный сервером, например, воспроизведение видео. SSE использует этот механизм для отправки информации в браузер с использованием потоковой информации. Он основан на протоколе http и в настоящее время поддерживается другими браузерами, кроме IE/Edge. По сравнению с двумя предыдущими способами не нужно создавать слишком много http-запросов, что экономит ресурсы.

WebSocketЭто новый протокол, определенный HTML5.В отличие от традиционного протокола http, этот протокол позволяет серверу активно передавать информацию клиенту. Недостатком использования протокола WebSocket является более сложная настройка на стороне сервера. WebSocket — это полнодуплексный протокол, то есть обе стороны связи равноправны и могут отправлять друг другу сообщения, в то время как метод SSE — это односторонняя связь, и только сервер может передавать информацию клиенту. необходимо отправить информацию, она принадлежит следующему HTTP-запросу.

Вышеуказанные четыре протокола связи, первые три основаны на протоколе HTTP.

Для этих четырех протоколов связи с точки зрения производительности:WebSocket > Длинное соединение (SEE) > Длинный опрос > Короткий опросОднако, если мы рассмотрим проблемы совместимости браузеров, порядок будет прямо противоположным:Короткий опрос > Длинный опрос > Длинное соединение (SEE) > WebSocketСледовательно, все же необходимо судить о том, какой метод использовать в соответствии с конкретным сценарием использования.