Меня попросили определить возможность зеркалирования или кэширования веб-сайтов на мобильном сервере в поезде. К сожалению, мне обронили это в последнюю минуту, и я должен дать ответ через день или два, а у меня нет большого опыта в этой области.
Поезд:
Находясь вне зоны действия обслуживания, гости должны иметь возможность продолжать доступ к веб-сайтам, к которым ранее был доступ. Это будут общие веб-сайты, к которым гости могут получить доступ вне поезда, и которые мы не будем контролировать. Также будут веб-сайты, которые автоматически кэшируются или «втягиваются», такие как новости и текущие события, которые не обязательно инициируются гостем.
Я знаю, что мы можем зеркалировать или кэшировать посещенные страницы, но меня беспокоит «среда», в которой мы будем работать.
Будем признательны за любые другие ресурсы, на которые вы можете указать мне.
Спасибо.
Я действительно настроил что-то очень похожее на это раз в год для недельного мероприятия, которое проводится в глуши, так что у меня есть небольшой опыт, которым я могу поделиться.
Во-первых, TL; DR: вы можете это сделать, но это будет работать не так хорошо, как вы (или ваше начальство) могли бы надеяться. Возможно, не стоит беспокоиться, особенно если перерывы кратковременные. Но вы все равно можете захотеть это сделать, чтобы сэкономить полосу пропускания и обеспечить более быстрое подключение к 3G.
Компонент, который вы ищете, - это прозрачный прокси, который перехватывает исходящие HTTP-запросы, которые не были предназначены клиентом для проксирования, и перенаправляет их на прокси-сервер. А кальмар - самый распространенный софт используется для прозрачного проксирования. Это то, что я использую.
Это работает следующим образом: коммутатор или маршрутизатор будет перехватывать пакеты, предназначенные для порта 80 удаленного адреса, и обрабатывать их так, чтобы вместо этого они подключались к прокси. Затем он проверяет свой кеш, и, если кеш отсутствует, он переходит в сеть. Типичный прокси. Я делаю это отвлечение с помощью некоторых простых правил Linux iptables, хотя многие маршрутизаторы и коммутаторы также могут быть настроены для этого.
Для ваших целей вам также потребуется внести некоторые существенные изменения в конфигурацию squid, чтобы переопределить его обработку кеша. В частности, вы захотите заставить его обслуживать устаревший кешированный элемент, когда он не может повторно проверить его в сети. У меня нет конфигурации для этого навскидку, так как это не требуется в моем дизайне, когда я нахожусь в фиксированной точке и имею непрерывное беспроводное обслуживание. Но внимательное чтение документации должно предложить способ сделать это.
Вы также захотите создать несколько пользовательских страниц ошибок Squid, которые относятся к вашей компании и объясняют различные ожидаемые условия выхода из строя.
А теперь о обратной стороне.
Вы вообще не сможете сделать это с помощью HTTPS-запросов. Хотя Squid поддерживает метод перехват HTTPS-запросов как и HTTP-запросы, вы не сможете использовать его, так как для этого потребуется создать центр сертификации и установить сертификат в каждом браузере клиента. Достаточно просто для предприятия, но не то, что вы можете сделать для государственной службы. И даже если бы вы могли, это совсем не удобно, вызовет тревогу в уме любого человека, заботящегося о конфиденциальности, а это незаконно в некоторых странах.
Кроме того, WebSockets, используемые сегодня многими веб-сайтами, почти всегда терпит неудачу когда задействован прозрачный прокси, потому что прокси, выполняя то, что должен делать, искажает запрос на обновление до неузнаваемости. Вы мало что можете с этим поделать, кроме как посоветовать пользователям явно использовать прокси-сервер. В этом случае браузер знает, как форматировать запрос по-другому, используя HTTP CONNECT, чтобы он беспрепятственно проходил через прокси.
Наконец, поговорив с некоторыми людьми, знакомыми с поездками в австралийских поездах, я узнал, что эти отключения иногда могут длиться от 10 до 15 минут. С этим мало что можно сделать; кто-то, просматривающий Интернет в это время, скорее всего, попытается щелкнуть ссылку на сайт, который вы еще не кэшировали, и вам не намного лучше, чем сейчас, хотя, если у вас есть кеш, вы можете хотя бы проинформировать пассажира о ситуации (хотя бы по HTTP). Пока Интернет отключен, пассажирам может быть лучше, если вы посмотрите в окно и попытаетесь обнаружить Налларборскую нимфу.
И немного базовой статистики. В прошлом году сервис использовал 42 ГБ данных и дополнительно обслужил 17 ГБ из кеша. В этом году сервис использовал 87 ГБ данных и обслужил всего 744 МБ из кеша. Это не ошибочный расчет и, насколько я могу судить, ошибка конфигурации. Большая разница между кешированием в прошлом году и в этом году, похоже, заключается в том, что все больше крупных веб-сайтов теперь принудительно используют HTTPS. Например, в прошлом году мне удалось кэшировать некоторые видео с YouTube. В этом году я не смог, потому что теперь они обслуживаются по HTTPS.
По мере того, как все больше и больше веб-сайтов переходят на HTTPS, эта стратегия кэширования с каждым годом становится все менее и менее жизнеспособной, а запуск кеша вообще кажется все более и более бессмысленным.
Я рекомендую вам не беспокоить. Но вы можете настроить его и запустить испытание на одном поезде, а затем измерить результаты.
Вы также можете поэкспериментировать с указанием пользователям явно настраивать прокси, чтобы вы могли обрабатывать HTTPS и WebSockets, хотя, по моему опыту, пользователям сложно понять это правильно. Возможно, вы сможете реализовать WPAD для автоматической настройки некоторых пользователей, но имейте в виду, что устройства Android и iOS не поддерживают ее или плохо поддерживают.
Я думаю, что осуществимость довольно низкая, вы должны рассмотреть следующие вопросы, которые в совокупности, я думаю, исключают возможность «пригодного для использования» или прозрачного автономного зеркала.
Трафик HTTP становится все более распространенным в наши дни, и вы не сможете кэшировать его, не установив сертификат CA на свое устройство, что пользователи должны очень нерешительно делать.
Многие веб-сайты в значительной степени полагаются на HTTP-запросы на стороне клиента (например, AJAX) для работы, и в большинстве случаев сайты стараются изо всех сил избегать кеширования запросов AJAX, добавляя метку времени к URL-адресу, чтобы каждый запрос обрабатывался как уникальный URL-адрес. .
Вы можете в основном исключить любой сайт с отслеживанием состояния (например, для которого требуется вход в систему) - очевидно, что вы не можете кэшировать профиль пользователя X в facebook, если он уже не просматривал его, и даже если они его просмотрели, ценность этих сайтов сильно уменьшится без обновлений в реальном времени. Кроме того, это означает, что поиск в кеше должен зависеть от значения файла cookie, что снижает вероятность попадания на страницу, ранее запрошенную кем-то другим.
Как большинство людей попадают на сайты? Люди редко вводят URL-адреса, обычно они ищут что-то - даже то, URL-адрес которого им известен, например facebook. Было бы сложно попытаться кэшировать сложные результаты поисковой системы, потому что они, вероятно, будут иметь статус (например, если вы выполняете поиск в Google при входе в учетную запись Google, ваши результаты будут другими)
При просмотре веб-страниц, каков процент нового контента по сравнению с контентом, который вы видели раньше? Даже при просмотре сайта, который вы часто посещаете, например Facebook, вы часто переходите на новые страницы и т. Д.
Некоторые сайты теперь используют WebSockets, не зная точных деталей, но я полагаю, что было бы сложно имитировать / воспроизводить взаимодействие WebSockets.
Если у вас есть основания полагать, что ваши пользователи будут посещать один и тот же набор страниц (например, набор документации) большую часть времени, и этот контент не имеет состояния, тогда это может быть осуществимо.