Какая разница между WebSocket и обычной связью сокетов?

Ответ 1

webSockets и обычные сокеты - это не одно и то же. WebSocket запускается через обычный сокет, но он запускает свою собственную схему подключения, схему безопасности и протокол кадрирования поверх обычного сокета, и обе конечные точки должны следовать этим дополнительным шагам для соединения, которое даже должно быть выполнено. Здесь вы можете увидеть протокол webSocket: http://tools.ietf.org/html/rfc6455

Самое большое различие сразу состоит в том, что ВСЕ соединения webSocket начинаются с HTTP-запроса от клиента к серверу. Клиент отправляет HTTP-запрос на тот же самый сервер и порт, который открыт для обычной веб-связи (по умолчанию порт 80, но если веб-сервер работает на другом порту, тогда связь с WebSocket будет следовать за ним на этом другом порту), Клиент устанавливает несколько настраиваемых заголовков, наиболее важным из которых является заголовок, который указывает, что клиент хочет "обновить" протокол webSocket. Кроме того, обе стороны обмениваются некоторыми ключами безопасности. Если сервер согласен с "обновлением", то оба клиента и сервер переключают протокол, передаваемый через этот исходный сокет из HTTP в webSocket, и теперь используется протокол кадрирования webSocket.

Кроме того, исходный HTTP-запрос может содержать в нем путь запроса, чтобы указать "подцель" для запроса webSocket. Это позволяет запускать всевозможные запросы WebSocket для всех с тем же сервером и портом.

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

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

Вы можете увидеть отличную сводку о том, как здесь запускается соединение через WebSocket: https://developer.mozilla.org/en-US/docs/WebSockets/Writing_WebSocket_servers.

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

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

Здесь пример исходного HTTP-запроса для инициирования соединения webSocket:

GET /chat HTTP/1.1
Host: example.com:8000
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

И ответ сервера:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

И пример кадра данных:

0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len |    Extended payload length    |
|I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
|N|V|V|V|       |S|             |   (if payload len==126/127)   |
| |1|2|3|       |K|             |                               |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
|     Extended payload length continued, if payload len == 127  |
+ - - - - - - - - - - - - - - - +-------------------------------+
|                               |Masking-key, if MASK set to 1  |
+-------------------------------+-------------------------------+
| Masking-key (continued)       |          Payload Data         |
+-------------------------------- - - - - - - - - - - - - - - - +
:                     Payload Data continued ...                :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|                     Payload Data continued ...                |
+---------------------------------------------------------------+

Ответ 2

Нет, WebSockets - это больше, чем просто сокеты. Они используют протокол кадрирования, который требует рукопожатия, а затем обменивается сообщениями, маскируемыми XORint с 32-разрядным случайным числом. Для получения дополнительной информации прочитайте RFC, который их стандартизирует.

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

Относительно портов: по умолчанию WebSocket подключается к порту 80, но API может получать любой порт. Клиентский порт рандомизирован, как и в большинстве протоколов на основе протокола TCP/IP.

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