Постоянные восходящие соединения в стиле кометы - PullRequest
Новая
       22

Постоянные восходящие соединения в стиле кометы

4 голосов
/ 12 февраля 2011

Есть много способов иметь постоянные нисходящие соединения. Например, вы можете использовать скрытый iframe; или сложная модель XHR, которая использует onreadystate для передачи частичной информации через ваше приложение при поддержании соединения. Тем не менее, я не смог найти способ сделать постоянный апстрим в том же духе.

Если вы используете Connection: Keep-Alive в своих восходящих вызовах, то вы фактически не разрываете соединение и не перестраиваете каждый раз; это хорошо. Вы могли бы даже тогда закодировать свои восходящие нажатия в GET запросе, который возвратил бы пустой документ

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

Если нет другого способа сделать это.

Вот несколько теорий о том, как будет выглядеть решение такого типа;

  • Возможно, возможность отправить поток mixed/multipart на сервер с граничными условиями.
  • Возможно, возможность выполнять частичную передачу, причем каждый последующий чанк является новыми данными.

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

У кого-нибудь есть понимание этого? Спасибо.

~ Крис.

1 Ответ

2 голосов
/ 12 февраля 2013

Единственный способ сделать «истинную» двунаправленную связь в веб-браузере - использовать WebSockets. Это их главное преимущество - вы можете осуществлять как восходящую, так и нисходящую связь без использования HTTP.

Если ваше нисходящее соединение доставляется с длинным опросом, тогда ваше восходящее соединение будет обычными старыми HTTP-запросами.

Однако, если у вас много запросов, я бы подумал, пытаетесь ли вы оптимизировать что-то, что на самом деле не нуждается в оптимизации. Даже самые маленькие из доступных сегодня серверов более чем способны обрабатывать тысячи HTTP-запросов в секунду. А поскольку большинство клиентских приложений реального времени прослушивают больше, чем отправляют, их быстрая запись в нисходящие соединения действительно повлияет на производительность сервера. С другой стороны, если вы используете «Connection: Keep-Alive», чтобы избежать накладных расходов на установку / разрыв сокета, большинство приложений увидят незначительное преимущество в производительности, перейдя на WebSockets.

(я работаю в компании, которая строит WebSync .)

...