Какую технологию использует Google Диск для получения обновлений в реальном времени?

Какую технологию использует Google Диск в режиме реального времени?

Когда я печатаю документ Google Диск, к которому обращаются несколько пользователей, на вкладке "Инструменты разработчика Chrome" отображается, что нет веб-узлов.

Я вижу, что два наиболее часто встречающихся типа вызова AJAX имеют либо "bind?" или "сохранить?" в URL. "спасти?" Запросы POST выполняются каждый раз, когда я печатаю, что делает нормальный AJAX для отправки обновлений на сервер.

Когда другой пользователь вводит, последнее "bind?" Вызов GET остается открытым, и объем данных, передаваемых по этому соединению, увеличивается. Периодически "bind?" Закрываются, а новые открываются, и логика, по-видимому, является некоторой функцией продолжительности и размера данных.

Это не длительный опрос, поскольку, когда сервер отправляет обновления, он не выполняет ответ.

Это не похоже на события, отправленные сервером, поскольку тип содержимого является "text/plain" вместо "text/stream".

Есть ли имя для Google? Если да, то как я могу попытаться это реализовать?

Инструменты Chrome Dev - редактирование документа на Google Диске

Ответ 1

Существует ли название для решения Google для обновлений в режиме реального времени на диске (например, "длинный опрос" или "сокеты")?

У него не было названия до сих пор. Я назову это "не опросить", чтобы сравнить с опросом и длинным опросом.

При опросе клиент периодически отправляет запросы на новые данные.

При длительном опросе клиент запрашивает данные, а сервер обрабатывает запрос, заканчивая ответ обновлениями при наличии обновлений.

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

Как я могу попробовать реализовать это?

Чтобы клиент отправлял обновления на сервер: это можно сделать с помощью обычных процедур POST.

Чтобы клиент подписался на обновления с сервера:

  • Клиент отправляет GET для потока обновлений, а затем начинает читать тело ответа до его завершения.

    Объекты XHR могут отправлять события progress до завершения запроса. (Частичный) ответ доступен с помощью xhr.responseText. ~~ Там нет простого способа следить за прогресс с fetch еще (май 2016 г.). ~~ При использовании fetch можно наблюдать за прогресс по потребляя res.body ReadableStream.

  • Клиент должен инициировать новый запрос, когда текущий запрос заканчивается.

Сервер должен:

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

По моему мнению, отсутствие опроса кажется более продолжительным, чем длительный, хотя я не слишком много с ним играл. Длинный опрос вызывает компромисс между задержкой и размером сообщения (учитывая постоянную частоту обновлений), компромиссный опрос не требуется. Другим недостатком длинного опроса является то, что он может привести к множеству HTTP-запросов, каждый раз оплачивая HTTP-издержки.

Без опроса большое преимущество по сравнению с WebSockets состоит в том, что опросы не поддерживаются каждым браузером, хотя поддержка WebSocket довольно хорошая - IE10+.