SPDY в качестве замены для Websockets?

Прежде всего, я понимаю, что SPDY и Websockets - это не одно и то же, и вы можете запускать Websockets через SPDY, как вы можете, с помощью HTTP и т.д.

Однако - мне интересно, будет ли SPDY жизнеспособной заменой для websockets, если я пытаюсь предоставить API REST (например), который также поддерживает push-сервер (двунаправленные вызовы по одному и тому же соединению).

Мой прототип использует websockets (node + socket.io) и отлично работает. Тем не менее, моя проблема с websockets заключается в том, что мне приходится мечтать о моем собственном протоколе JSON для запросов на маршрутизацию как на сервер, так и с сервера. Я бы предпочел использовать URI и заголовки REST-стиля в запросах, которые лучше подходят для архитектуры REST. SPDY кажется, что это будет поддерживать это лучше.

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

Тем не менее, я не видел много примеров двунаправленных запросов SPDY, кроме нажатия файлов в браузере. Я хотел бы направить события и данные в браузеры, например:

Content-Type: application/json
{
   "id": "ca823f3e233233",
   "name": "Greg Brady"
}

но мне не ясно, как браузер /Javascript может "прослушивать" и реагировать на них, как и с API-интерфейсами WebSocket и socket.io.

Ответ 1

Начните с начала: зачем вы хотите запускать WebSockets через SPDY, а не выполнять обновление HTTP? Если вы обновляете HTTP-соединение с WS, тогда ничто другое не может использовать этот поток TCP - соединение WS может быть бездействующим, но соединение блокируется, тем не менее. С помощью SPDY вы можете мультиплексировать несколько запросов/ответов и соединение с веб-сервером (или даже несколько) по одному и тому же потоку TCP. С практической точки зрения, по состоянию на июль 2012 года WS over SPDY по-прежнему ведется работа, поэтому вам придется ждать использования SPDY для WebSockets - надеюсь, не слишком долго, хотя!

Но пусть предполагается поддержка там... Причина, почему это не ясно, как слушать "SPDY Push" из JavaScript, - это потому, что нет никакого способа сделать это! Вдвинутый ресурс входит в кеш браузеров - ничего больше, не меньше. Если вам необходимо передать данные в ваши обратные вызовы javascript, ответ на это будут WebSockets или Server-Sent Events (SSE).

Итак, все вместе:

HTTP добавляет много накладных расходов для отдельных небольших запросов (заголовков и т.д.).
WebSockets предоставляет вам небольшой служебный канал, но требует выполнения собственной маршрутизации.
SPDY значительно снизит накладные расходы и затраты на небольшие HTTP-запросы (win)
SSE - хорошая, простая альтернатива переносу данных клиенту (который работает сегодня, через SPDY)

Вы можете использовать SPDY + SSE для достижения своих целей, и вся эта связь может работать по одному и тому же каналу TCP. SPDY запрашивает сервер, SSE нажимает с сервера.

Ответ 2

Первые некоторые пояснения:

Базовый протокол WebSocket (IETF 6455) не является многоуровневым onto HTTP. Первоначальное рукопожатие для соединений WebSocket совместимо с HTTP, но как только рукопожатие завершено, протокол представляет собой двунаправленное полнодуплексное соединение с фреймами с очень низкими накладными расходами (часто всего 2 байта на кадр заголовка).
Идея WebSocket по SPDY представляет собой предложение, которое может или не может видеть свет дня. В этом случае WebSocket фактически накладывается на SPDY. Первоначальное соединение/рукопожатие может происходить быстрее из-за характера SPDY в сравнении с HTTP, однако в кадрах данных будет больше накладных расходов, поскольку поля заголовка WebSocket отображаются в заголовки SPDY.

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

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

Ответ 3

Тем не менее, моя проблема с websockets заключается в том, что мне приходится мечтать о себе JSON для запросов на маршрутизацию как на сервер, так и с сервера.

Я написал тонкий слой RPC поверх socket.io, обменивая сетевые вызовы в promises именно по этой причине. Вы можете взглянуть на него здесь.