Http

Ростелеком, крупнейший в РФ оператор широкополосного доступа, обслуживающий около 13 млн абонентов, без лишней огласки ввёл в строй систему подстановки своих рекламных баннеров в незашифрованный HTTP-трафик абонентов. Так как подставляемые в транзитный трафик JavaScriopt-блоки включали обфусцированный код и обращение к не аффилированным с Ростелекомом сомнительным сайтам (p.analytic.press, d.d1tracker.ru, dmd.digitaltarget.ru), вначале возникло подозрение на компрометацию оборудования провайдера и внедрение вредоносного ПО во внутридомовой маршрутизатор. Но после отправки претензии представители Ростелекома указали на то, что подстановка рекламы осуществляется в рамках действующего с 10 февраля сервиса показа баннерной рекламы абонентам.

Показ рекламы осуществляется через баннерную сеть mail.ru, а перемещения отслеживаются через d1tracker.ru (обработчик размещён в облаке Amazon). В коде также фигурируют обращения к домену analytic.press, который зарегистрирован в конце декабря. Как правило, отображается либо полноэкранная реклама, перекрывающее всё содержимое страницы, либо в верхнюю часть страниц добавляется баннер. В большинстве случаев размещаемые блоки выглядят как размещение назойливой рекламы самими сайтами и абонент не догадывается, что на деле реклама подставлена провайдером. Рекламируются всевозможные услуги сторонних компаний (не связанных с Ростелекомом), вплоть до продажи фонариков. Пример подставляемого кода можно изучить в данном архиве. Часть кода обфусцирована и загружается динамически, поэтому без детального анализа трудно судить, подставляют они только рекламу или выполняют какие-то иные действия на стороне клиентского браузера.

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

(c) opennet

Опубликованы результаты изучения производительности различных методов извлечения коллекции ресурсов, используя для обращения к серверу протоколы HTTP/1.1, HTTP/2 и HTTP/2 + Server Push. В исследовании также оценено влияние на производительность нахождение запрашиваемых данных к кэше браузера и манипуляции ресурсами на уровне логики работы приложения (сведение ресурсов в единый JSON-блок).

Тестирование производительности выполнения 25 запросов показало в целом предсказуемые результаты - заметное отставание запроса через HTTP/1.1 при пустом кэше и лидирование отдачи ресурсов одним блоком (тесты с меткой "compound"). Производительность Firefox и Chrome была примерно на одном уровне, но наличие данных в кэше не привело к ожидаемому росту эффективности

Но в тесте на обработку 500 запросов всплыло заметное отставание Chrome от Firefox при передаче большого числа запросов и отставание Firefox от Chrome при применении механизма Server Push и в ситуации использования HTTP/2 при наличия большей части данных в браузерном кэше. Chrome показал более эффективную работу с кэшем, а Firefox более эффективную обработку внешних запросов.

По итогам тестов сделан вывод, что HTTP/2 позволяет достаточно эффективно обрабатывать раздельные запросы большой коллекции ресурсов. Отличия производительности простых схем раздельной отдачи ресурсов от методов, в которых ресурсы агрегируются в один блок, не столь существенны, чтобы оправдать значительное усложнение логики обработки на стороне приложения и сервера. Агрегирование имеет смысл только в ситуациях, в которых производительность имеет наивысший приоритет. Когда важнее упрощение логики и простой API, имеет смысл использовать раздельную обработку ресурсов.

Другим выводом является то, что браузерный кэш при использовании HTTP/2 не оказывает значительного влияния на производительность обработки запросов (полное выполнение 501 запроса оказалось медленнее выполнения 51 запроса при 90% наполнении кэша всего в 1.2 раза в Firefox и 2.3 раза в Chrome). Использование Server Push не показало существенной выгоды в Firefox, но оказалось эффективным при загрузке большого числа ресурсов в Chrome. Авторы исследования также отметили, что оптимизация серверной части оказывает более существенное влияние на производительность, чем оптимизация выполняемого в браузере клиентского кода.

"Заработался" - это когда, глядя на часы, видишь HTTP-ошибку