Текстовые браузеры уменьшают сетевой трафик?

Используют ли текстовые браузеры, такие как lynx , links и elinks, меньшую пропускную способность, чем браузер с графическим интерфейсом (например, Firefox, Chrome и т. Д.)?

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

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

— Paulb
источник

Или на самом деле скачать изображения ..

— Путешественник Geek

Думайте с точки зрения ожидания сокращения на три или более порядка .

— user2338816

@ user2338816 Да, разница может быть на три порядка. Попробуйте YouTube! [Добавление позже:] Ой, это еще три!

— Фолькер Сигел

@ user2338816 три порядка вряд ли. Например, для этой конкретной страницы исходный HTML-документ составляет около 10% от всех загружаемых источников без учета кэширования, так что это всего лишь один порядок величины; и многие тяжелые элементы (библиотеки javascript, большие изображения и т. д.) успешно кэшируются, часто используются на многих страницах и, следовательно, загружаются очень редко, поэтому их размер не отражает их влияния на общий сетевой трафик.

— Петерис

@Peteris 3 может быть немного выше, но 2, конечно, нет. Скажем, 10%, которые вы здесь заметили, одинаковы для большинства обычных сайтов. Затем примите во внимание, что видео трафик составляет 78% всего видео трафика. Это означает, что для оставшейся части 22% трафика мы можем ожидать, что 2,2% будет текстовым. Теперь это математика для салфеток, но, похоже, 2 порядка.

— CorsiKa,

Ответы:

Веб-сервер отправляет не весь сайт, а документы, запрашиваемые браузерами.

Например, при доступе к https://www.google.com/ браузер запрашивает документ на сервере https://www.google.com/. Сервер обрабатывает запрос и отправляет обратно некоторый HTML-код.

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

На этом этапе браузер завершил загрузку этого документа, но все еще не загрузил ссылочные документы. Он может сделать это или пропустить их. Обычные браузеры будут пытаться загрузить все ссылочные документы для лучшего просмотра. Если у вас есть блокировщик рекламы (например, Adblock) или плагин конфиденциальности (Ghostery, NoScript), он также может блокировать некоторые ресурсы.

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

https://www.google.com/images/srpr/logo11w.png (логотип Google)
https://www.google.com/textinputassistant/tia.png (значок клавиатуры)
https://ssl.gstatic.com/gb/images/i1_3d265689.png (некоторые комбинированные изображения, трюк, используемый для уменьшения количества запросов браузера)

^{(фактические файлы могут отличаться для разных пользователей, браузеров и сеансов и могут меняться со временем)}

Текстовые браузеры не загружают изображения, файлы Flash, видео HTML5 и т. Д., Поэтому они загружают меньше данных.

@NathanOsman делает хорошее замечание в комментариях: иногда небольшие изображения встраиваются непосредственно в документы HTML, и в таких случаях их нельзя избежать. Это еще один прием, используемый для уменьшения количества запросов. Однако они очень малы, в противном случае накладные расходы на кодирование двоичного файла в base64 слишком велики. На Google.com таких изображений немного: ( кодированный base64 размер / декодированный размер )

Значок клавиатуры 19 × 11 (106 B / 76 B)
Значок микрофона 28 × 38 (334 B / 248 B)
Прозрачный GIF размером 1 × 1 px (62 B / 43 B), который отображается на вкладке « Ресурсы Chrome Dev Tools », но я не смог найти его в источнике - возможно, позже был добавлен с помощью JavaScript
Поврежденный файл GIF размером 1 × 1 пиксель, который появляется дважды (34 B / 23 B). Его цель для меня загадка.

— gronostaj
источник

Мне понравилась ссылка на объединенные изображения - это ловкий трюк.

— prateek61

@ prateek61 Все основные сайты используют его; это на самом деле техника, заимствованная из видеоигр. :) На самом деле, многие веб-разработчики даже называют его « спрайтами CSS » или аналогичными (в Amazon это называется «спрайтами», но я не знаю, насколько распространен этот вариант).

— пушистый

Ну, почти - возможно встроить изображения непосредственно в HTML, используя схему URI данных ( data:).

— Натан Осман

Да, если вы готовы пожертвовать большей частью контента в Интернете, вы можете уменьшить пропускную способность. Кажется логичным ... Давайте не будем забывать, что 78% интернета - это видео-трафик ...

— corsiKa

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

Я провел некоторое базовое тестирование с tcpdump, пытаясь получить эту страницу IANA ( http://www.iana.org/domains/reserved ) как с lynx, так и с wget, и вот мои результаты (только команды HTTP, я могу предоставить остальное если нужно).

lynx http://www.iana.org/domains/reserved

  4   0.072774 xx.xx.xx.xx -> 192.0.32.8   HTTP GET /domains/reserved HTTP/1.0
 10   0.146971   192.0.32.8 -> xx.xx.xx.xx HTTP HTTP/1.1 200 OK  (text/html)

wget -p http://www.iana.org/domains/reserved

  4   0.072139 xx.xx.xx.xx -> 192.0.32.8   HTTP GET /domains/reserved HTTP/1.0
 22   0.145905   192.0.32.8 -> xx.xx.xx.xx HTTP HTTP/1.1 200 OK  (text/html)
 28   0.219381 xx.xx.xx.xx -> 192.0.32.8   HTTP GET /robots.txt HTTP/1.0
 30   0.291877   192.0.32.8 -> xx.xx.xx.xx HTTP HTTP/1.1 200 OK  (text/plain)
 32   0.292550 xx.xx.xx.xx -> 192.0.32.8   HTTP GET /_css/2013.1/screen.css HTTP/1.0
 94   0.440388   192.0.32.8 -> xx.xx.xx.xx HTTP HTTP/1.1 200 OK  (text/css)
100   0.514652 xx.xx.xx.xx -> 192.0.32.8   HTTP GET /_css/2013.1/print.css HTTP/1.0
132   0.660071   192.0.32.8 -> xx.xx.xx.xx HTTP HTTP/1.1 200 OK  (text/css)
138   0.733546 xx.xx.xx.xx -> 192.0.32.8   HTTP GET /_img/bookmark_icon.ico HTTP/1.0
154   0.878227   192.0.32.8 -> xx.xx.xx.xx HTTP HTTP/1.1 200 OK  (application/octet-stream)
160   0.950713 xx.xx.xx.xx -> 192.0.32.8   HTTP GET /_js/2013.1/jquery.js HTTP/1.0
277   1.172095   192.0.32.8 -> xx.xx.xx.xx HTTP HTTP/1.1 200 OK  (application/x-javascript)
283   1.244571 xx.xx.xx.xx -> 192.0.32.8   HTTP GET /_js/2013.1/iana.js HTTP/1.0
285   1.317059   192.0.32.8 -> xx.xx.xx.xx HTTP HTTP/1.1 200 OK
287   1.317609 xx.xx.xx.xx -> 192.0.32.8   HTTP GET /_img/2013.1/iana-logo-header.svg HTTP/1.0
332   1.464356   192.0.32.8 -> xx.xx.xx.xx HTTP/XML HTTP/1.1 200 OK
337   1.536749 xx.xx.xx.xx -> 192.0.32.8   HTTP GET /_img/2013.1/icann-logo.svg HTTP/1.0
348   1.610449   192.0.32.8 -> xx.xx.xx.xx HTTP/XML HTTP/1.1 200 OK
353   1.682727 xx.xx.xx.xx -> 192.0.32.8   HTTP GET /_css/2013.1/fonts/OpenSans-Light.ttf HTTP/1.0
658   2.552776   192.0.32.8 -> xx.xx.xx.xx HTTP HTTP/1.1 200 OK  (application/octet-stream)
663   2.625015 xx.xx.xx.xx -> 192.0.32.8   HTTP GET /_css/2013.1/fonts/OpenSans-Regular.ttf HTTP/1.0
926   3.063537   192.0.32.8 -> xx.xx.xx.xx HTTP HTTP/1.1 200 OK  (application/octet-stream)
932   3.135931 xx.xx.xx.xx -> 192.0.32.8   HTTP GET /_css/2013.1/fonts/OpenSans-Semibold.ttf HTTP/1.0
1216   3.573481   192.0.32.8 -> xx.xx.xx.xx HTTP HTTP/1.1 200 OK  (application/octet-stream)
1222   3.645984 xx.xx.xx.xx -> 192.0.32.8   HTTP GET /_css/2013.1/fonts/OpenSans-Bold.ttf HTTP/1.0
1500   4.012966   192.0.32.8 -> xx.xx.xx.xx HTTP HTTP/1.1 200 OK  (application/octet-stream)
1506   4.085693 xx.xx.xx.xx -> 192.0.32.8   HTTP GET /_css/2013.1/fonts/Inconsolata.otf HTTP/1.0
1584   4.304016   192.0.32.8 -> xx.xx.xx.xx HTTP HTTP/1.1 200 OK  (application/octet-stream)
1589   4.376612 xx.xx.xx.xx -> 192.0.32.8   HTTP GET /_img/2011.1/icons/icon_alert.png HTTP/1.0
1592   4.449311   192.0.32.8 -> xx.xx.xx.xx HTTP HTTP/1.1 200 OK  (PNG)
1594   4.449930 xx.xx.xx.xx -> 192.0.32.8   HTTP GET /_img/2013.1/iana-logo-homepage.png HTTP/1.0
1627   4.596125   192.0.32.8 -> xx.xx.xx.xx HTTP HTTP/1.1 200 OK  (PNG)
1633   4.668596 xx.xx.xx.xx -> 192.0.32.8   HTTP GET /_img/2013.1/iana-logo-homepage@2x.png HTTP/1.0
1704   4.895581   192.0.32.8 -> xx.xx.xx.xx HTTP HTTP/1.1 200 OK  (PNG)
1710   4.968097 xx.xx.xx.xx -> 192.0.32.8   HTTP GET /_css/2011.1/fonts/OpenSans-Light.ttf HTTP/1.0
1982   5.364584   192.0.32.8 -> xx.xx.xx.xx HTTP HTTP/1.1 200 OK  (application/octet-stream)
1988   5.438091 xx.xx.xx.xx -> 192.0.32.8   HTTP GET /_css/2011.1/fonts/OpenSans-Regular.ttf HTTP/1.0
2243   5.830353   192.0.32.8 -> xx.xx.xx.xx HTTP HTTP/1.1 200 OK  (application/octet-stream)
2249   5.902861 xx.xx.xx.xx -> 192.0.32.8   HTTP GET /_css/2011.1/fonts/OpenSans-SemiBold.ttf HTTP/1.0
2259   5.976674   192.0.32.8 -> xx.xx.xx.xx HTTP HTTP/1.1 404 NOT FOUND  (text/html)
2263   6.047876 xx.xx.xx.xx -> 192.0.32.8   HTTP GET /_css/2011.1/fonts/OpenSans-Bold.ttf HTTP/1.0
2533   6.415590   192.0.32.8 -> xx.xx.xx.xx HTTP HTTP/1.1 200 OK  (application/octet-stream)
2539   6.487909 xx.xx.xx.xx -> 192.0.32.8   HTTP GET /_css/2011.1/fonts/Inconsolata.otf HTTP/1.0
2616   6.720477   192.0.32.8 -> xx.xx.xx.xx HTTP HTTP/1.1 200 OK  (application/octet-stream)

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

— prateek61
источник

Я не думаю, что wgetможно считать браузером. Лучше попробуй с elinksчем-нибудь подобным.

— Даркхогг

Поэтому я использовал wgetпросто для демонстрации всех HTTP-запросов и ответов, которые будут сделаны. -pПараметр определяется следующим образом : -p, --page-requisites get all images, etc. needed to display HTML page.. Я не хотел использовать настоящий GUI-браузер, так как они, как правило, делают другие запросы, которые я не хотел отфильтровывать.

— prateek61

Мне также нравится этот ответ. Проверка Wget была интересной.

— Полб

Я думаю, что текстовые браузеры значительно уменьшат объем передаваемых данных, поскольку они не будут запрашивать все эти раздутые изображения, видео и интерактивные материалы с высоким разрешением Web 2.0 (Flash и другие).

Я предлагаю вам просто проверить это, настроив правило IPtables, которое будет подсчитывать количество трафика, попадающего в конкретное правило IPtables.

Например, создайте правило для порта 80 + 443 с подсчетом трафика и просматривайте веб-страницы с помощью обычного браузера, сбрасывайте счетчик IPtables и делайте то же самое с текстовым браузером.

Имейте в виду, что вы не можете сравнивать оба прогона на 100%, потому что динамический веб-контент (реклама и прочее) может варьироваться в зависимости от доступа.

— Себастьян Брабец
источник