Теоретически: возможно / возможно обслуживать статический контент через веб-сокеты?

Question

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

Мой вопрос довольно теоретический, но мне интересно, возможно ли это сейчас или когда-нибудь можно будет обслуживать статические файлы через веб-сокет? Учитывая, что веб-сокеты представляют собой постоянное соединение клиента (веб-браузера) с сервером, имеет смысл использовать веб-сокеты для обслуживания некоторого, если не всего статического содержимого, поскольку это будет просто одно соединение, а не многие.

Чтобы уточнить немного.

Я понимаю, что моя формулировка о соединениях была неверной, как указано Грегом ниже. Но из того, что я понимаю, причина того, что CDN были созданы и используются до сих пор, заключается в том, чтобы решить проблему с браузерами и / или серверами, имеющими жесткое ограничение на количество одновременных загрузок, как только вы достигнете этого ограничения, ваши запросы будут поставлены в очередь, таким образом добавляя к время загрузки страницы. Мне известно, что они также были созданы для предоставления запросов без файлов cookie. Поэтому на самом деле мой вопрос должен звучать так: «Можно ли использовать веб-сокеты вместо CDN?»

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

Answer 1

Это определенно возможно, но есть несколько причин, по которым вы, вероятно, не хотите использовать это для статических ресурсов:

• Вам нужен как минимум один ресурс, который статически доставляется по стандартному механизму HTTP, что означает, что вам нужно что-то, способное в любом случае обслуживать статические ресурсы. Как правило, вы хотите отделить Javascript от вашего HTML, что будет означать другую статическую нагрузку. Или вы можете запутаться и поместить код WebSocket на встроенную главную страницу, но вам все еще лучше.
• Невозможно открыть соединения WebSocket, пока не запустится скрипт на странице. Установление соединения WebSocket добавляет некоторую начальную задержку.
• Большинство браузеров будут загружать не конфликтующие статические ресурсы параллельно (некоторые старые браузеры имеют жесткое ограничение на количество параллельных соединений, но они все еще имеют некоторую параллелизацию). Вы можете открыть несколько соединений WebSocket для разных статических ресурсов, но для надежного и эффективного выполнения этого потребуется много усилий. Браузеры уже решили большинство из этих проблем для статических ресурсов.
• Каждое соединение WebSocket является транспортом с гарантированным заказом на основе сообщений. В сочетании с сериализованным характером выполнения Javascript это фактически означает, что вы получаете возможность обрабатывать одно сообщение WebSocket за раз. Вы можете использовать Web Workers, чтобы иметь возможность обрабатывать более одного соединения WebSocket параллельно, но основной сценарий рендеринга все равно будет сериализован для этих соединений. Вы, безусловно, можете сделать это эффективным, но, опять же, это не тривиальная проблема, и браузеры уже решили многие из этих статических проблем с загрузкой ресурсов.
• Многие веб-серверы поддерживают gziping-ресурсы перед их доставкой. У WebSocket пока нет поддержки сжатия (это обсуждается как расширение в рабочей группе). Это означает, что если вы хотите сжать свои ресурсы через WebSocket, вам придется сделать это в Javascript, что увеличит задержку.

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

Answer 2

Этот ответ на самом деле не отвечает на ваш вопрос о веб-сокетах, но может сделать его устаревшим:

Технология следующего поколения, которая должна решить проблему передачи нескольких ресурсов по одному соединению, - SPDY , которая в настоящее время является кандидатом на HTTP 2.0. Он имеет рабочие реализации в Chrome и Firefox и уже имеет некоторую экспериментальную поддержку на стороне сервера, такую ​​как Google и Twitter.