Каковы различия в протоколе между версиями WebSockets?
Есть ли какая-либо сумма в разнице в протоколах между различными черновиками WebSockets?
Уровни поддержки браузера по-прежнему повсюду, поэтому недостаточно просто рассмотреть RFC.
Очевидно, что версия Sec-WebSocket изменяется, и я знаю, что ранний формат был совершенно радикальным. Однако я имею в виду более тонкие изменения в протоколе. Например, hybi-10 (v8) в обрамлении предполагает, что длина расширенной полезной нагрузки сохраняется как 16/63, а не 16/64 в RFC 6455 (v13).
Итак: есть ли сводка изменений где-нибудь?
В качестве альтернативы (если мы проигнорируем самые ранние черновики и номера версий), является ли это тот случай, когда протокол по существу тот же, и что черновики в основном являются исправлениями к тексту спецификации?
Ответы
Ответ 1
Wikipedia WebSocket перечисляет, какие браузеры поддерживают какой протокол.
Кроме того, IETF предоставляет инструмент сравнения, который может использоваться для сравнения любых двух спецификаций черновиков RFC. Например, чтобы сравнить проекты 15 и 17 WebSocket, перейдите сюда:
Откорректируйте адреса url1 и url2, чтобы получить diff для произвольных версий. Обратите внимание, что это покажет, что текстовые отличия от спецификации и большие изменения спецификации часто происходят без соответствующих различий в проводе. Я предлагаю выполнить поиск разностей для раздела "Обзор протокола" и раздела "Базовый базовый протокол", который показывает сводку заголовка и схему кадрирования соответственно.
Самая большая разница в проводном протоколе между Hixie-76/HyBi-00 (HyBi-00 была всего лишь копией Hixie-76 для запуска новой серии), а остальная часть серии HyBi начиналась с HyBi-04 ( HyBi-17 стал IETF RFC 6455). Некоторые из основных изменений серии Hixie серии HyBi:
- В протоколе Hixie-76 существовало своеобразное хеш-рукопожатие, которое произошло после заголовков рукопожатия, но до фактических кадров данных.
- В Hixie-76 фреймы были префиксны с 0x00 и суффикс с 0xff. Невозможно определить длину кадра, кроме как путем приема/буферизации до конца кадра. В серии HyBi (после HyBi-00) длина кадра является частью заголовка префикса /, и суффикса нет.
- Серия HyBi поддерживает как текстовые, так и двоичные данные UTF-8 в полезной нагрузке (Hixie поддерживает только UTF-8). Это указывается и код операции в заголовке фрейма.
Ответ 2
Чтобы добавить конкретное изменение; в Sec-WebSocketVersion
<= 8, начало координат находится в Sec-WebSocket-Origin
; однако в 13 это изменяется на заголовок Origin
. Это специально изменяет между hybi-10 и hybi-11, которые являются версиями версии "8". Также обратите внимание, что в hixie-76/hybi-00 это Origin
, поэтому он выглядит как от Origin
до Sec-WebSocket-Origin
, а затем обратно на Origin
.
Ответ 3
Я не знаю, что многие версии протокола находятся в настоящее время. У меня есть сервер websocket, который поддерживает Hixie-76 и hybi-10 до 17 (только изменения в Sec-WebSocket-Version), который работает против Safari (desktop + iOS), Firefox и Chrome.
(Старший) Hixie-76 полезен для общения с устройствами iOS, по крайней мере.
hybi-10, по сути, одинаковы. Я предположил, что ваш пример расширенной полезной нагрузки, объявленной как 63 бит в hybi-10, был опечаткой и был одним из многих небольших исправлений, сделанных при быстром перемещении черновиков от 10 до 17.
Позже: отредактировано, чтобы показать, что некоторые версии Safari используют Hixie-76