Считаем, что задача выделения основного пользовательского запроса, решена. Более подробно об этой задаче можно прочитать в первой статье на тему визуализации HTTP трафика. Как уже было упомянуто существует два подхода к разрешению "второстепенных" запросов. Первый - запустить в браузере "основную" страницу и, перехватывать все запросы в Интернет, отвечая на них данными из трафика. Будем называть такой подход MITM - как и известную одноименную атаку. Второй подход - осуществить разбор страницы, выделить все HTML элементы, ссылающиеся на внешние объекты, найти их в трафике и выполнить реконструкцию страницы, встроив все объекты внутрь HTML с помощью data URI.
Попробуем сравнить оба подхода по ряду критериев с точки зрения их реализации и поддержки.
Качество представления
Так как MITM подход не требует от реализации знаний о процессе построения представления страницы (её рендеринга браузером), качество данного подхода высокое и не зависит от сложности самой страницы. Браузер лучше знает какие данные ему нужно получить и куда их сложить, чтобы сделать правильную отрисовку. Кроме того такой подход позволяет в отличии от реконструкции правильно показать элементы, содержимое которых загружается с помощью сложного javascript кода. Такие технологии набирают популярность с распространением Web-приложений.
Качество же представления подхода реконструкции напрямую зависит от качества реализации. Программист, реализующий данный подход "отвечает" за внешний вид страницы. От его экспертизы в области отрисовки HTML зависит то, как будет выглядеть результат. Подход реконструкции требует постоянной поддержки, так как Интернет бурно развивается, появляются новые методы верстки и программирования frontend.
Форма результата
Результатом работы реконструкции является понятный и простой файл. Его можно сохранить на отчуждаемом носителе, показать на другом компьютере. Это естественно для среднестатистического пользователя. Для него отображаемый браузером URL - это файл в Интернете. В такой парадигме логично, что его можно куда-то сохранить, а потом открыть.
В случае же с MITM подходом результатом будет "картинка", "рендер" полученный браузером. Несмотря на то, что встроенные в браузер средства тоже позволяют "сохранить" страницу. Идеологически это совершенно разные вещи. Результат невозможно получить заранее где-то не на компьютере пользователя.
Сложность реализации
Как уже было сказано выше подход реконструкции требует высокой экспертизы в области представления HTML страниц, верстки и программирования frontend, что делает его реализацию и поддержку крайне сложной. Примерами реализации могут служить разве что проекты по "выкачиванию" порталов из Интернет, такие как curl, Offline Explorer, Teleport Pro и другие.
Реализация MITM напротив, хотя имеет свои подводные камни, понятна и относительно проста. Кроме того имеются проекты с открытым исходным кодом с подобной функциональностью - xplico, различные кеширующие HTTP-proxy.
Реализация реконструкции имеет низкую связность с пользовательским интерфейсом. Этот проект может развиваться практически независимо. MITM же напротив реализуется необходимо тесно с пользовательским интерфейсом - необходимо буквально встраивать код proxy-сервера в код прилоежния, взаимодействующего с пользователем. По сути тот же web-сервер, который отдаёт интерфес должен выступать и proxy-сервером.
Выводы
Оба подхода имеют свои положительные и отрицательные стороны. Принятие конкретного решения невозможно без глубокого анализа требований. Тем не менее сложность реализации и зависимость качества представления от неё перевешивают чашу весов в сторону MITM, не смотря на неочевидность формы полученного результата.
Comments
comments powered by Disqus