Во-первых, предыстория: от спроса
Требование: «Клиент сканирует QR-код, отображает информацию о параметрах клиента в веб-конце»
Фокус проблемы: веб-приложение в реальном времени, двусторонняя связь между клиентом и сервером в реальном времени.
Во-вторых, традиционное решение?
Опрос: также известен как периодический опрос.
Клиент периодически отправляет запросы на сервер для синхронизации данных с сервером. Типичные сценарии применения:
Технология Ajax, частичное обновление веб-страниц
недостаток:
Пропускная способность и ресурсы ЦП: поскольку клиент регулярно отправляет запросы на сервер, когда на стороне сервера нет обновления данных, клиент по-прежнему отправляет запросы, что приводит к пустой трате пропускной способности и потреблению ЦП на стороне сервера.
В режиме реального времени: во время интервала опроса будет задержка данных
Длинный опрос: улучшения и усовершенствования обычного опроса
Цель: Экономия пропускной способности и снижение потерь сетевого трафика.
Основные:
Оставайтесь подключенными: HTTP-слой, остается подключен, то клиентский сервер получает запрос, если нет обновления данных, соединение поддерживается в течение определенного периода времени;
До тех пор, пока не произойдет обновление данных или тайм-аут соединения, это может уменьшить взаимодействие между недействительным Клиентом и Сервером;
Сохраняя соединение, уменьшая количество запросов и ответов, экономя пропускную способность;
дефект:
Экономия полосы пропускания, ограниченный эффект: часть HEAD пакета данных HTTP имеет большой объем данных (400+ байт), но действительно эффективные данные очень малы (10 байт).Такие пакеты данных периодически передаются в сети, расходуя полосу пропускания. .
В сценарии частых обновлений данных данные в режиме реального времени: когда данные на стороне сервера часто обновляются, сторона сервера должна дождаться поступления следующего запроса, прежде чем отправлять обновленные данные.Задержка между ними составляет до 1,5 x RTT (время приема-передачи)
В случае перегрузки сети время ожидания увеличивается, поскольку соединение необходимо восстановить;
Существенная причина:
Соединение: необходимо повторно установить HTTP-соединения (HTTP 1.1 может только облегчить, не может разделить, полностью решено)
Формат данных: это по-прежнему формат данных прикладного уровня, и данные HTTP HEADER занимают относительно большой объем.
Потоковая передача событий (SSE)
С помощью SSE клиенты могут автоматически получать обновления данных без повторной отправки HTTP-запросов. Как только соединение установлено, «события» автоматически отправляются клиенту. SSE на стороне сервера генерирует и отправляет события в формате Event Stream.
Возможна односторонняя передача данных от сервера к клиенту.
SSE имеет хорошее в реальном времени в режиме реального времени по сравнению с опросом и насколько легко легко.
недостаток:
В случае большого параллелизма сервер может выйти из строя.
SSE поддерживает только одностороннюю отправку событий от сервера к клиенту, и все версии IE (включая Microsoft Edge) не поддерживают SSE. Если вам нужно принудительно поддерживать IE и некоторые мобильные браузеры, вы можете попробовать EventSource Polyfill (по сути, все еще опрашивающий)
3. Что такое веб-сокет?
B/S режим запрос-ответ
В традиционной сети браузер активно отправляет запрос на сервер для получения данных на стороне сервера;
Если вы хотите добиться связи в реальном времени и получать данные с сервера в режиме реального времени, обычно клиент регулярно отправляет HTTP-запросы, а сервер отвечает и возвращает данные;
HTTP-протокол: на основе режима запроса / реагирования, однонаправленной, протокола отсутствия уровня приложений;
Почему протокол HTTP не позволяет серверу активно нажать данные клиенту?
Если серверу разрешено активно передавать данные клиенту, клиент легко подвергается атаке; в частности, рекламодатель будет передавать рекламную информацию клиенту, поэтому односторонняя функция HTTP необходима.
Введение в веб-сокеты
Протокол WebSocket использует код состояния 101 (протокол переключения) протокола HTTP для преобразования протокола и переключается на протокол WebSocket, который сам основан на протоколе Tcp.
Функции:
Между клиентом и сервером технология двусторонней связи, клиент и сервер, может инициировать связь.
это сетевой протокол связи
Построен на основе протокола TCP транспортного уровня.
преимущество:
Экономьте пропускную способность; (HEAD протокола HTTP относительно велик)
Экономия ресурсов ЦП сервера; (метод опроса протокола HTTP, даже если у Сервера нет данных, он должен получить Запрос)
На следующем рисунке показана эффективность веб-приложений в режимах Polling и WebSocket:
4. Соглашение
Прежде всего, WebSocket — это постоянный протокол, в отличие от HTTP, который является непостоянным протоколом. Жизненный цикл HTTP определяется запросом, то есть запросом и ответом, затем в HTTP 1.0 этот HTTP-запрос завершен. HTTP1.1 был улучшен, и вы можете использовать keep-alive для поддержания соединения, но это все еще запрос = ответ, который очень пассивен и не может быть инициирован активно.
Пожать руки
Информация о рукопожатии от клиента:
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13Значение заголовка запроса ключа:
Connection: Upgrade: Указывает, что протокол должен быть обновлен.
Обновление: веб-сокет: указывает, что вы хотите перейти на протокол веб-сокета.
Sec-WebSocket-Version: 13: указывает версию веб-сокета. Если сервер не поддерживает версию, он должен вернуть Sec-WebSocket-Versionheader, который содержит номер версии, поддерживаемой сервером.
Sec-WebSocket-Key: это значение в кодировке Base64, случайно сгенерированное браузером, которое сопоставляется с Sec-WebSocket-Accept в заголовке ответа сервера и используется для проверки сервера для обеспечения базовой защиты, например вредоносное соединение.
Sec_WebSocket-Protocol: определяемая пользователем строка, используемая для различения протоколов, требуемых различными службами по одному и тому же URL-адресу.
Информация о рукопожатии с сервера:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chatЗначение заголовка ответа ключа:
Sec-WebSocket-Accept вычисляется на основе Sec-WebSocket-Key в заголовке клиентского запроса.
Connection и Upgrade по-прежнему указывают, что протокол обновлен до протокола websocket.
разделенный фрейм данных
Наименьшей единицей связи между клиентом WebSocket и сервером является фрейм, который состоит из одного или нескольких фреймов для формирования полного сообщения.
Отправитель: разрежьте сообщение на несколько фреймов и отправьте его на сервер;
Получатель: получает кадры сообщения и повторно собирает связанные кадры в полное сообщение;
Обмен данными
Как только клиент WebSocket и сервер устанавливают соединение, последующие операции основаны на передаче кадров данных.
Каждое сообщение WebSocket может быть разделено на несколько фреймов данных. Когда получатель WebSocket получает кадр данных, он определяет, получил ли он последний кадр сообщения, в соответствии со значением FIN (идентификатор в кадре данных, используемый для определения того, является ли текущий кадр последним кадром сообщения). текущее сообщение) фрейм данных.
Сообщение может быть обработано, когда получен последний кадр сообщения.
Обнаружение сердцебиения
Многие причины вызывают закрытие соединения. Как правило, событие onClose соединения будет инициировано, но когда сеть отключена, событие onclose не будет инициировано. В это время соединение отключено. Клиент отправляет данные ping к серверу через регулярные промежутки времени.Как только сервер проснется, он ответит сигналом pong и в это время может повторно подключиться. Повторное подключение Heartbeat не является опросом, опрос будет продолжаться для установления соединений (множественных подключений), а Heartbeat по-прежнему является текущим соединением, просто продолжайте отправлять сообщения об обнаружении.
закрыть соединение
Как только кадр управления Close отправлен или получен, начинается рукопожатие фазы закрытия веб-сокета.
Закрыть таблицу кодов состояния (причина закрытия)
код состояния |
название |
описывать |
|---|---|---|
0–999 |
Зарезервированный сегмент, не используется. |
|
1000 |
CLOSE_NORMAL |
Закрыта изящно; для какой бы цели она ни создавалась, ссылка успешно выполнила свою задачу. |
1001 |
CLOSE_GOING_AWAY |
Терминал уходит, возможно, из-за ошибки сервера, или из-за того, что браузер отскакивает от страницы, открывшей соединение. |
1002 |
CLOSE_PROTOCOL_ERROR |
Соединение было прервано из-за ошибки протокола. |
1003 |
CLOSE_UNSUPPORTED |
Отключено из-за получения недопустимого типа данных (например, бинарных данных, полученных терминалом, который принимает только текстовые данные). |
1004 |
Зарезервировано, его значение может быть определено в будущем. |
|
1005 |
CLOSE_NO_STATUS |
Зарезервировано Указывает, что ожидаемый код состояния не был получен. |
1006 |
CLOSE_ABNORMAL |
Зарезервировано.Используется, когда соединение закрывается аварийно (т. е. кадр закрытия не отправляется), когда ожидается получение кода состояния. |
1007 |
Unsupported Data |
Отключено из-за получения искаженных данных (например, текстового сообщения, содержащего данные, отличные от UTF-8). |
1008 |
Policy Violation |
Отключено из-за несоответствия данных. Это общий код состояния для сценариев, в которых коды состояния 1003 и 1009 не подходят. |
1009 |
CLOSE_TOO_LARGE |
Отключено из-за полученного слишком большого кадра данных. |
1010 |
Missing Extension |
Клиент ожидал, что сервер согласует одно или несколько расширений, но сервер не обработал это, поэтому клиент отключился. |
1011 |
Internal Error |
Клиент отключен с сервера, поскольку неожиданное условие предотвращает его завершение запроса. |
1012 |
Service Restart |
Сервер отключен из-за перезагрузки. |
1013 |
Try Again Later |
Сервер отключен по временным причинам, например, из-за перегрузки сервера, что приводит к отключению некоторых клиентских подключений. |
1014 |
Зарезервировано стандартом WebSocket для использования в будущем. |
5. Преимущества
По сравнению с протоколом HTTP WebSocket поддерживает постоянные соединения;
Информация заголовка, которой обмениваются сервер и клиент, очень мала, около 2 байтов;
И клиент, и сервер могут активно передавать данные друг с другом, истинным полным дуплексом;
Не создавайте TCP-запросы и часто уничтожайте запросы, уменьшите использование ресурсов пропускной способности сети и одновременно сэкономьте ресурсы сервера;
6. Резюме
WebSocket может быть гибким, простым и эффективным в двунаправленной передаче и проталкивании сообщений, но он не очень полезен в обычном процессе «запрос-ответ», по сравнению с обычными HTTP-запросами он гораздо более хлопотный и даже более сложный, неэффективен. Например, в некоторых сценариях требуется только простой запрос-ответ.Если вы переходите на WebSocket, вам нужно добавить идентификатор запроса RequestId, что увеличивает стоимость. У каждой технологии есть свои преимущества и недостатки, и она может проявлять свои сильные стороны там, где она уместна, и, видя ее несколько преимуществ и продвигая ее во всех направлениях независимо от случая, может быть контрпродуктивно.
7. Практика
1. Блок-схема
2. Внимание
tomcat spring websocket нужен 7.x или новее;
Для функциональной поддержки websocket требуется, чтобы и nginx, и машина имели конфигурацию, поддерживающую протокол websocket;
3. Детали
Инициализация веб-страницы создает уникальный идентификатор для идентификации текущей веб-страницы;
Поместите уникальный идентификатор в URL-адрес QR-кода, чтобы сгенерировать QR-код;
Сторона приложения сканирует и запрашивает услугу, соответствующую QR-коду, при этом запрос содержит уникальный идентификатор веб-страницы и некоторую информацию о параметрах приложения;
Сервер получает запрос, обрабатывает параметры и возвращает его веб-странице с уникальным идентификатором;
Отображение информации об ответе веб-сервера конечной сборки;
4. Рекомендации по внешнему плагину
Автор использует интерфейсную и внутреннюю структуру разделения SpringMVC + React, Вот несколько хороших плагинов для React:
Плагин генерации QR-кода:GitHub.com/shirts/QR-код…
Плагин для файлов cookie:Ууууу. Эта лошадь plus.com/package/hot...
8. Ссылка
Затвердевание .top/Web socket-i...
сегмент fault.com/ah/119000001…
сегмент fault.com/ah/119000001…