Proxy и маршрутизация

Нет предела совершенству.

Оптимизация трафика на уровне прокси имеет несколько ограничений, если верить данным с chrome beta на мобильном телефоне, он смог уменьшить затраты трафика на 65% для сайтов благодаря тому что пропускал трафик через свои сервера и минимизировал его. Недостатков я не заметил, но если верить статистике с httparchive - крупные сайты достигли 77 пунктов в pagespeed - что достаточно не плохо на уровне среднего уровня оптимизации и с сравнение трафика пропущенного с оптимизацией с чистым трафиком покажет достаточно не плохие результаты, подобные двойному уменьшению объёма трафика.

Но все же они тоже не спасут - если присутствует большой объем данных описывающих состояние передающихся на каждый запрос, как противоположность передачи только существенных изменений - никакая оптимизация не поможет, так как если разбить трафик на такие части: 

• анонимные данные, не зависящие от клиента, 
• данные специфичные для клиента, 
• информация о смене состояния. 

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

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

Но идея вида максимально совместного использования инфраструктуры всеми возможными видами использования канала, как например: телевиденье, мобильная связь, интернет, позволяет получить покрытие до 100%. Так как исчезает потребность установки в некоторой малопопулярной местности оборудования (сетевое оборудование, передатчиков) для всех видов связи, устанавливает один, остальные арендуют. Так же изменить принцип работы мобильной сети, когда любой трафик должен пройти до корневого оборудования, вне зависимости где находятся источники этого трафика, чтобы соединение между конечным оборудованием разных видов связи, как частный случай одного, не шло через корневые узлы, а происходило по минимально возможному маршрут, например трафик для голоса и передачи данных обменивался в рамках пары десятков километров, а управляющий трафик шел, как и раньше на корневые узлы. Что позволит получить в достаточно большую теоретическую выгоду, так как данные миновав низкоскоростной канал связи, которым является последняя миля, могут быть централизовано быть проанализированы и пущены кратчайшим путем до получателя.

Уменьшение нагрузки на оптимизирующий прокси

Для уменьшения объёма трафика запрашиваемого с клиента перед/вместо запроса на адрес указанный пользователем делаем запрос на дополнительный информационный сервер с заголовками, характеризующими запрашиваемый контент, но без частей ответственных за привязку к пользователю или сеансу вида исходный адрес и дату последнего обновления или тег с последним обновлением. И если ранее мы уже получали контент с заголовками, четко указывающими на приватность данного контента этот запрос можно не делать. 

Сервер может поступить после этого следующим образом: 

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

Если пользователь согласен с полным проецированием трафика то в первом запросе передаются также приватная информация и контент преимущественно отдается с кеширующей инфраструктуры или зеркал.

Почти идеальный виртуальный CDN

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

Виртуальный - потому что нет его как такового только незримое улучшение каких-то характеристик.

Вот несколько неплохих характеристик виртуального CDN:

• быть посредником между сайтом и конечным пользователем и перепроверять контент, который возвращает сайт пользователю, а действительно ли он поменялся? как поменялся? а можно немного раньше его перезапросить? Может пользователю захочется его загрузить? И заменять все заголовки на правильные полностью зависящие от результата и заголовков клиента;
• выдавать правильный хеш от контента с адресом куда можно еще обратится про этот хеш;
• эта отдельная часть может быть как внутри этого посредника, так и дублироваться на клиенте, где указывается хеш контента, откуда он получен и где еще можно поискать;
• выдавать из каких частей состоит результат, может нам не нужны полный результат, а только его часть, так как все остальное у нас уже есть или у кого-то поближе.

И как результат не весь контент грузится с одного сайта, можно по заголовкам понять может мы это уже откуда-то грузили или можно параллельно погрузить.

CDN, безопасность

​Продолжение предыдущего поста.

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

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

​CDN, общие идеи

Это описание абстрактной реализации, 

не имеющей ничего общего с реальными реализациями.

Сеть доставки контента содержит три уровня: 

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

Общая логика работы: 

• при получения запроса от клиента ближайший узел к клиенту ищет сервер который является наиболее близким к исходному узлу назначения; 
• после нахождения наилучшего пути, узел с первого уровня получает контент с конечного узла и генерирует хеш от данных и другие идентифицирующие контент данные и передает на третий уровень; 
• если у третьего уровня нет подобных данных он запрашивает данные с первого уровня, через второй уровень который может быть пиринговой сетью; 
• все данные при передаче должны быть сжаты и по возможности очищены от не критичных для результата данных, таких как переводы строчек и пробелы. Если возможно то и от описания изображений вида даты создания которые не критичны для пользователя; 
• внутри сети передачи и на конечных узлах данных идентифицируются по описателям характерным для сжатого контента с сохранением изначальных характеристик - для последующей идентификации изменения исходных данных; 
• на узлах первого уровня контент хранится также в исходном в виде - чтобы избежать вероятности коллизий хеш функции и позволяет перепроверять данные, при последующем получении подобных; 
• при новом запросе клиента - делается только дополнительный запрос на первый уровень и если изменений нет, то передается оригинальный заголовок. Данные разбиваются на две части заголовки запроса и контент запроса. Что позволяет кешировать и передавать их отдельно. 

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

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

Для открытой сети: желательно дополнительно передавать дополнительный ключ соединения и если данные потенциально могут быть привязаны к клиенту и не давать пользовательским системам получать доступ без корректного ключа соединения.

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

CDN

​Идея относительно оптимизации обновления кеша в CDN(впрочем как и любого reverse proxy): можно запоминать кроме самого контента и максимального времени хранения с параметрами обновления (хеш и время обновления) еще время за которое контент был получен. И на основе количества запросов к контенту после первого получения делать для топового контента запрос перед окончанием времени хранения, как раз на время получение первого результата, дополнительный запрос для получения обновления контента. Перед этой операцией также анализировать эффективность данного решения: и для быстро генерируемого, контента который генерируется за время сравнимое с временем кеширования или редко запрашиваемого предварительный запросы не делать. Также можно на первый запрос после окончания времени кеширования, но до окончания времени ожидания ответа на изначальный запрос, еще выдавать старый контент, если это время еще в пределах разумного.