Apakah browser berbasis teks mengurangi lalu lintas jaringan?

27

Apakah peramban berbasis teks seperti lynx , tautan dan elink mengkonsumsi bandwidth lebih sedikit daripada peramban berbasis GUI (yaitu, Firefox, Chrome dll.)?

Saya menduga tidak ada pengurangan lalu lintas.
Dasar Pemikiran: Saya pikir browser berbasis teks mengunduh seluruh halaman seperti yang ditawarkan oleh server. Segala pelurusan atau pengurangan widget halaman dilakukan secara lokal.

Mungkin ada beberapa pengurangan lalu lintas, karena sebagian besar peramban berbasis teks tidak akan menjalankan skrip halaman atau SWF yang dapat menyebabkan lebih banyak lalu lintas.

networking terminal browser gui user-interface Paulb
sumber
19
Atau sebenarnya mengunduh gambar ..
Journeyman Geek
4
Pikirkan dalam hal mengharapkan tiga atau lebih pesanan pengurangan besar.
user2338816
1
@ user2338816 Ya, mungkin ada perbedaan tiga urutan besarnya. Coba YouTube! [Menambahkan nanti:] Ups, itu tiga lagi!
Volker Siegel
3
@ user2338816 tiga urutan besarnya tidak akan mungkin. Misalnya, untuk halaman khusus ini dokumen html asli adalah sekitar 10% dari seluruh sumber yang dapat diunduh mengabaikan caching, jadi hanya satu urutan besarnya; dan banyak item kelas berat (perpustakaan javascript, gambar besar, dll) berhasil di-cache, sering digunakan kembali di banyak halaman dan karenanya sangat jarang diunduh, sehingga ukurannya tidak benar-benar mewakili pengaruhnya terhadap total lalu lintas jaringan.
Peteris
1
@Peteris 3 mungkin agak tinggi, tetapi 2 tentu tidak. Katakanlah 10% yang Anda perhatikan di sini adalah sama di sebagian besar situs reguler. Lalu, perhitungkan bahwa lalu lintas video berjumlah 78% dari semua lalu lintas video. Ini berarti untuk sisa 22% dari lalu lintas, kita dapat mengharapkan 2,2% menjadi teks. Sekarang, ini adalah matematika serbet, tetapi 2 urutan besarnya tampaknya berada di tempat itu.
corsiKa

Jawaban:

53

Server web tidak mengirim "seluruh situs web", tetapi dokumen yang diminta browser.

Misalnya ketika Anda mengakses https://www.google.com/ server kueri browser untuk dokumen tersebut https://www.google.com/. Server memproses permintaan dan mengirimkan kembali beberapa kode HTML.

Kemudian browser memeriksa apa yang telah dikirim server. Dalam hal ini adalah halaman web HTML, jadi mem-parsing dokumen dan mencari skrip yang direferensikan, stylesheet, gambar, font dll.

Pada tahap ini browser telah selesai mengunduh dokumen itu, tetapi masih belum mengunduh dokumen referensi. Itu dapat memilih untuk melakukannya atau melewati mereka. Peramban biasa akan mencoba mengunduh semua dokumen yang dirujuk untuk pengalaman menonton terbaik. Jika Anda memiliki pemblokir iklan (seperti Adblock) atau plugin privasi (Ghostery, NoScript), itu mungkin memblokir beberapa sumber juga.

Kemudian browser mengunduh dokumen yang direferensikan satu per satu, setiap kali meminta server secara eksplisit untuk satu sumber daya. Dalam contoh Google kami, browser akan menemukan referensi berikut, hanya untuk menyebutkan beberapa di antaranya:

(file aktual mungkin berbeda untuk pengguna, browser, dan sesi berbeda dan dapat berubah seiring waktu)

Peramban berbasis teks tidak mengunduh gambar, file Flash, video HTML5 dll. Sehingga mereka mengunduh lebih sedikit data.

@NathanOsman memberikan komentar yang baik: Terkadang gambar kecil tertanam langsung dalam dokumen HTML dan dalam kasus itu, pengunduhan tidak dapat dihindari. Ini adalah trik lain yang digunakan untuk mengurangi jumlah permintaan. Mereka sangat kecil, jika tidak, overhead pengkodean file biner di base64 terlalu besar. Ada beberapa gambar seperti itu di Google.com: ( ukuran base64 disandikan / didekodekan )

  • Ikon keyboard 19 × 11 (106 B / 76 B)
  • Ikon mikrofon 28 × 38 (334 B / 248 B)
  • 1 × 1 px GIF transparan (62 B / 43 B) yang muncul di tab Sumber Daya Alat Chrome Dev , tetapi saya tidak dapat menemukannya di sumber - mungkin ditambahkan kemudian dengan JavaScript
  • 1 × 1 px file GIF rusak yang muncul dua kali (34 B / 23 B). Tujuannya adalah sebuah misteri bagi saya.
gronostaj
sumber
1
Saya menyukai tautan gambar gabungan - itu adalah trik yang rapi.
prateek61
12
@ prateek61 Semua situs web utama menggunakannya; itu sebenarnya teknik yang dipinjam dari video game. :) Sebenarnya, banyak pengembang web bahkan menyebutnya " CSS sprite " atau sejenisnya (di Amazon itu disebut "spriting" tapi saya tidak tahu seberapa umum variasi itu).
lembut
3
Yah, hampir - dimungkinkan untuk menyematkan gambar langsung dalam HTML menggunakan skema URI data ( data:).
Nathan Osman
Ya, jika Anda rela mengorbankan sebagian besar konten internet, Anda dapat mengurangi bandwidth. Tampak logis ... Jangan lupa bahwa 78% dari internet adalah lalu lintas video ...
corsiKa
25

Saya akan curiga mereka melakukannya. Saya tidak percaya bahwa browser berbasis teks akan (secara default) bahkan mengunduh sumber daya seperti gambar atau entitas eksternal, seperti font (jika diperlukan), skrip, dll.

Saya melakukan beberapa pengujian dasar dengan tcpdump mencoba mendapatkan halaman IANA ini ( http://www.iana.org/domains/reserved ) dengan kedua lynx dan kemudian wget, dan ini adalah hasil saya (hanya perintah HTTP, saya dapat memberikan sisanya) jika diperlukan).

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/[email protected] 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)

Jadi saya menyadari ini bukan tes yang bagus karena wgetdapat mengunduh sumber daya yang mungkin tidak diunduh peramban, tetapi contoh yang menurut saya berlaku - ada banyak permintaan lagi yang diperlukan untuk membuat konten di peramban GUI. Dengan demikian, itu browser GUI umumnya akan menyebabkan lebih banyak lalu lintas jaringan daripada browser berbasis teks.

prateek61
sumber
Saya tidak berpikir wgetdapat dianggap sebagai browser. Lebih baik coba elinksatau yang serupa.
Darkhogg
Jadi saya wgethanya menggunakan untuk menunjukkan semua permintaan dan tanggapan HTTP yang akan dibuat. The -pparameter didefinisikan sebagai berikut: -p, --page-requisites get all images, etc. needed to display HTML page.. Saya tidak ingin menggunakan browser GUI yang sebenarnya karena mereka cenderung membuat permintaan lain yang tidak ingin saya filter.
prateek61
3
Saya suka jawaban ini juga. Pemeriksaan wget menarik.
Paulb
1

Saya pikir Peramban berbasis teks akan mengurangi jumlah data yang ditransfer secara signifikan karena mereka tidak akan meminta semua Gambar 2.0, Video beresolusi tinggi, Video, dan hal-hal interaktif tinggi yang membengkak (Flash dan lainnya).

Saya sarankan Anda hanya menguji ini dengan Menyiapkan Aturan IPtables yang akan Menghitung jumlah lalu lintas yang memukul aturan IPtables tertentu.

Misalnya, buat aturan untuk port 80 + 443 dengan penghitungan lalu lintas dan jelajahi web dengan peramban normal, setel ulang Penghitung tabel dan lakukan hal yang sama dengan peramban berbasis teks.

Perlu diingat bahwa Anda tidak dapat membandingkan keduanya berjalan 100% karena konten web dinamis (iklan dan barang-barang) dapat bervariasi pada setiap Akses.

Sebastian Brabetz
sumber