Какой-то способ угадать скорость клиентского соединения

Question

Мне необходимо принять динамическое решение о весе содержимого для отправки клиенту в зависимости от его / ее скорости соединения.

То есть: если клиент использует мобильное устройство с подключением 3G (или более медленным)Я отправляю ему / ей легкий контент.Если он / она использует WiFi или более быстрое соединение, я отправляю ему / ей полный контент.

Я пытался измерить время между перезагрузками, отправляя клиенту заголовок Location: myurl.com (с некоторой информацией оклиент для его идентификации).Это работает в настольных браузерах и некоторых полнофункциональных мобильных браузерах (таких как Obigo), но не работает в мини (прокси) браузерах, таких как Opera Mini или UCWeb.Эти браузеры возвращают время соединения между моим сервером и прокси-сервером, а не мобильным устройством.

То же самое происходит, если я пытаюсь перезагрузить страницу с тегом <meta> или Javascript document.location.

Есть ли какой-нибудь способ обнаружить или измерить скорость клиентского соединения, или он / она использует 3G или WiFi и т. Д., Который работает в мини-браузерах (то есть, что я могу определить медленное соединение через мини-браузер)

Answer 1

Это отличный вопрос. Я не сталкивался с какими-либо методами оценки скорости клиента с помощью браузера. У меня есть идея, хотя; Я не думал об этом больше пары минут, но, надеюсь, это даст вам некоторые идеи. Также, пожалуйста, прости мое многословие:

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

Таким образом, вам может необходимо провести различие между задержкой и пропускной способностью. Предположим, что клиент отправляет временную метку (назовем ее «A») с каждым HTTP-запросом, а сервер просто возвращает его обратно. Затем клиент может вычесть эту возвращенную метку времени из ее текущего времени, чтобы оценить, сколько времени потребовалось для выполнения запроса. Это время включает в себя почти все, включая задержку в сети и время, необходимое серверу для полного получения вашего запроса.

Теперь предположим, что сервер отправляет обратно метку времени «A» сначала в заголовках ответа перед отправкой всего тела ответа. Также предположим, что вы можете постепенно читать ответ сервера (например, неблокирующий ввод-вывод. Для этого есть множество способов.) Это означает, что вы можете получить отраженную временную метку перед чтением ответа сервера. На этом этапе клиентское время «B» минус отметка времени запроса «A» является приблизительным значением вашей задержки. Сохраните это вместе с временем клиента "B".

Как только вы закончили читать ответ, количество данных в теле ответа, разделенное на время нового клиента "C" минус предыдущее время клиента "B", является приблизительным значением вашей пропускной способности. Например, предположим, что C - B = 100 мс, и вы прочитали 100 КБ данных, тогда ваша пропускная способность равна 10 КБ / с.

Еще раз, мобильные клиентские соединения подвержены ошибкам и имеют тенденцию к изменению силы с течением времени. Таким образом, вы, вероятно, не хотите проверять пропускную способность один раз. Фактически, вы также можете измерить пропускную способность каждого ответа и сохранить скользящее среднее пропускной способности клиента. Это снизит вероятность того, что необычно плохая пропускная способность по одному запросу приведет к снижению качества клиента или наоборот.

Если этот метод работает, то все, что вам нужно сделать, это решить, какова политика для определения того, какой контент получает клиент. Например, вы могли бы начать в режиме «низкого качества», а затем, если клиент имеет достаточно хорошую пропускную способность в течение некоторого периода времени, затем обновить их до контента высокого качества. Затем, если их пропускная способность снизится, понизьте их до низкого качества.

РЕДАКТИРОВАТЬ: уточнил некоторые вещи и добавил пример пропускной способности.

Answer 2

Во-первых: использование SSL (HTTPS) позволит избежать много глупостей прокси.Это также остановит такие вещи, как сжатие (что может ускорить загрузку HTML, CSS и т. Д., Но не поможет для уже сжатых данных).

Время загрузки страницы составляет задержка + ( пропускная способность × размер ).Даже если задержка неизвестна, измерение небольшого файла и большого файла может дать вам пропускную способность:

Let L be latency, B be bandwidth, both unknown.
Let t₁ and t₂ be the measured download times.
In this example, the two sizes are 128k and 256k.

t₁ = L + B × 128                             // sure would be nice if SO had Τεχ
t₂ = L + B × 256
t₂ - t₁ = (L + B × 256) - (L + B × 128)
        = L + B × 256 - L - B × 128
        = 256(B) - 128(B)
        = 128(B)

Итак, вы можете увидеть, что если вы разделите разницу во времени на разницу в размерах страниц, вы получитепропускная способность.Выполнение одного измерения может привести к странным результатам из-за непостоянства задержки и пропускной способности.Повторение несколько раз (и выбрасывание выбросов и абсурдных [например, отрицательных] значений) приведет к истинной средней пропускной способности.

Вы можете легко выполнить эти измерения в JavaScript в фоновом режиме, используя любую инфраструктуру AJAX.Получить текущее время, отправить запрос, а не часы, когда ответ получен.Сами запросы должны быть одинакового размера, так что накладные расходы на отправку запросов являются лишь частью задержки.Возможно, вы захотите использовать разные хосты, чтобы победить постоянные соединения.Либо так, либо настройте свой сервер таким образом, чтобы он отказывался от постоянных соединений, но только для ваших тестовых файлов.

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

Answer 3

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

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

Легко проверить, какой браузер используют ваши пользователи.

Тем не менее, вы должны предоставить возможность переключаться между легким весом и полным контентом, потому что ваши догадки могут быть неверными.

Answer 4

Сравните на стороне сервера два запроса от одного и того же клиента.

Как насчет простого ajax-запроса, который запрашивает URL для содержимого?Просто запишите серверную часть времени первого запроса с IP-адресом клиента, сохраните его где-нибудь (файл или база данных), а затем сравните его со временем запроса из клиентского JavaScript-кода и предоставьте URL после сравнения двух раз.произвольное «быстрое» или «медленное» ограничение по времени и предоставление URL-адреса для содержимого с соответствующей скоростью.

Answer 5

Это то, что вы можете обнаружить на стороне клиента? Если вам нужно обойти прокси, вы всегда можете найти тип соединения на стороне клиента и отправить его обратно. Другим способом может быть загрузка файла на стороне клиента через некоторый механизм сценариев, запись байтов в секунду и возврат этой информации на сторону сервера.