Apa arti multiplexing di HTTP / 2

Bisakah seseorang menjelaskan multiplexing dalam kaitannya dengan HTTP / 2 dan cara kerjanya?

Sederhananya, multiplexing memungkinkan Browser Anda menjalankan beberapa permintaan sekaligus pada koneksi yang sama dan menerima permintaan kembali dalam urutan apa pun.

Dan sekarang untuk jawaban yang jauh lebih rumit ...

Saat Anda memuat halaman web, ia mengunduh halaman HTML, ia melihatnya membutuhkan beberapa CSS, beberapa JavaScript, memuat gambar ... dll.

Di bawah HTTP / 1.1 Anda hanya dapat mengunduh salah satu dari mereka pada satu waktu di koneksi HTTP / 1.1 Anda. Jadi browser Anda mengunduh HTML, lalu meminta file CSS. Ketika itu dikembalikan itu meminta file JavaScript. Ketika itu dikembalikan, ia meminta file gambar pertama ... dll. HTTP / 1.1 pada dasarnya sinkron - setelah Anda mengirim permintaan, Anda tidak dapat mengaksesnya sampai Anda mendapat tanggapan. Ini berarti sebagian besar waktu browser tidak bekerja terlalu banyak, karena telah menjalankan permintaan, menunggu tanggapan, lalu menjalankan permintaan lain, lalu menunggu tanggapan ... dll. Tentu saja situs kompleks dengan banyak JavaScript memang membutuhkan Browser untuk melakukan banyak pemrosesan, tetapi itu tergantung pada JavaScript yang diunduh jadi, setidaknya untuk permulaan, penundaan yang diwariskan ke HTTP / 1.1 memang menyebabkan masalah. Biasanya server tidak

Jadi salah satu masalah utama di web saat ini adalah latensi jaringan dalam mengirimkan permintaan antara browser dan server. Ini mungkin hanya puluhan atau mungkin ratusan milidetik, yang mungkin tidak terlihat banyak, tetapi mereka bertambah dan seringkali merupakan bagian paling lambat dari penjelajahan web - terutama karena situs web menjadi lebih kompleks dan membutuhkan sumber daya tambahan (seperti yang mereka dapatkan) dan akses Internet semakin meningkat melalui seluler (dengan latensi lebih lambat daripada broadband).

Sebagai contoh, katakanlah ada 10 sumber daya yang halaman web Anda perlukan setelah HTML dimuat sendiri (yang merupakan situs yang sangat kecil menurut standar saat ini karena 100+ sumber daya adalah umum, tetapi kami akan membuatnya tetap sederhana dan melanjutkan dengan ini contoh). Dan katakanlah setiap permintaan membutuhkan waktu 100 md untuk melakukan perjalanan melintasi Internet ke server web dan sebaliknya dan waktu pemrosesan di kedua ujungnya dapat diabaikan (katakanlah 0 untuk contoh ini demi kesederhanaan). Karena Anda harus mengirim setiap sumber daya dan menunggu tanggapan satu per satu, ini akan memakan waktu 10 * 100 md = 1.000 md atau 1 detik untuk mengunduh seluruh situs.

Untuk menyiasati ini, browser biasanya membuka banyak koneksi ke server web (biasanya 6). Ini berarti browser dapat menjalankan beberapa permintaan pada saat yang sama, yang jauh lebih baik, tetapi dengan biaya kerumitan karena harus menyiapkan dan mengelola banyak koneksi (yang berdampak pada browser dan server). Mari lanjutkan contoh sebelumnya dan juga ada 4 koneksi dan, untuk mempermudah, katakanlah semua permintaan sama. Dalam hal ini Anda dapat membagi permintaan di keempat koneksi, jadi dua akan memiliki 3 sumber daya untuk didapatkan, dan dua akan memiliki 2 sumber daya untuk mendapatkan sepuluh sumber daya secara total (3 + 3 + 2 + 2 = 10). Dalam hal kasus terburuk adalah 3 kali putaran atau 300ms = 0,3 detik - peningkatan yang baik, tetapi contoh sederhana ini tidak termasuk biaya pengaturan beberapa koneksi tersebut,

HTTP / 2 memungkinkan Anda mengirim beberapa permintaan secara bersamaankoneksi - jadi Anda tidak perlu membuka banyak koneksi seperti di atas. Jadi browser Anda dapat berkata "Beri saya file CSS ini. Beri file JavaScript itu. Beri gambar1.jpg. Beri gambar2.jpg ... Dll." untuk sepenuhnya memanfaatkan satu koneksi tunggal. Ini memiliki manfaat kinerja yang jelas karena tidak menunda pengiriman permintaan tersebut menunggu koneksi gratis. Semua permintaan ini berjalan melalui Internet ke server secara (hampir) paralel. Server merespons masing-masing, dan kemudian mereka mulai kembali. Bahkan itu bahkan lebih kuat dari itu karena server web dapat meresponsnya dalam urutan apa pun dan mengirim kembali file dalam urutan yang berbeda, atau bahkan memecah setiap file yang diminta menjadi beberapa bagian dan mencampurkan file bersama-sama.kepala masalah pemblokiran baris ). Browser web kemudian ditugaskan untuk menyatukan kembali semua bagian. Dalam kasus terbaik (dengan asumsi tidak ada batasan bandwidth - lihat di bawah), jika semua 10 permintaan dijalankan cukup banyak sekaligus secara paralel, dan dijawab oleh server dengan segera, ini berarti Anda pada dasarnya memiliki satu perjalanan pulang pergi atau 100ms atau 0,1 detik, untuk unduh semua 10 sumber. Dan ini tidak memiliki kelemahan yang dimiliki banyak koneksi untuk HTTP / 1.1! Ini juga jauh lebih dapat diskalakan karena sumber daya di setiap situs web berkembang (saat ini browser membuka hingga 6 koneksi paralel di bawah HTTP / 1.1 tetapi haruskah itu berkembang seiring situs menjadi lebih kompleks?).

Diagram ini menunjukkan perbedaannya, dan ada juga versi animasinya .

Catatan: HTTP / 1.1 memang memiliki konsep pipelining yang juga memungkinkan beberapa permintaan dikirim sekaligus. Namun mereka masih harus dikembalikan agar diminta, secara keseluruhan, jadi tidak ada yang sebagus HTTP / 2, meskipun secara konseptual serupa. Belum lagi fakta ini sangat kurang didukung oleh browser dan server sehingga jarang digunakan.

Satu hal yang disorot dalam komentar di bawah ini adalah bagaimana bandwidth memengaruhi kami di sini. Tentu saja koneksi Internet Anda dibatasi oleh seberapa banyak Anda dapat mendownload dan HTTP / 2 tidak mengatasinya. Jadi, jika 10 sumber daya yang dibahas dalam contoh di atas semuanya adalah gambar dengan kualitas cetak yang sangat besar, maka pengunduhannya masih lambat. Namun, untuk kebanyakan browser web, bandwidth bukanlah masalah daripada latensi. Jadi jika sepuluh sumber daya itu adalah item kecil (terutama sumber daya teks seperti CSS dan JavaScript yang dapat di-gzip menjadi kecil), seperti yang sangat umum di situs web, maka bandwidth sebenarnya bukan masalah - itu adalah volume sumber daya yang sering kali menjadi masalah dan HTTP / 2 tampaknya mengatasinya. Ini juga mengapa penggabungan digunakan di HTTP / 1.1 sebagai solusi lain, jadi misalnya semua CSS sering digabungkan menjadi satu file:anti-pola di bawah HTTP / 2 - meskipun ada argumen yang melarang menghapusnya sepenuhnya juga).

Sebagai contoh dunia nyata: asumsikan Anda harus memesan 10 item dari toko untuk dikirim ke rumah:

• HTTP / 1.1 dengan satu koneksi berarti Anda harus memesannya satu per satu dan Anda tidak dapat memesan item berikutnya hingga yang terakhir tiba. Anda bisa mengerti bahwa butuh berminggu-minggu untuk menyelesaikan semuanya.

• HTTP / 1.1 dengan banyak koneksi berarti Anda dapat memiliki sejumlah (terbatas) pesanan independen kapan saja di mana saja.

• HTTP / 1.1 dengan pipelining berarti Anda dapat meminta 10 item satu demi satu tanpa menunggu, tetapi kemudian semuanya tiba dalam urutan tertentu yang Anda minta. Dan jika satu item sudah habis maka Anda harus menunggunya sebelum Anda mendapatkan item yang Anda pesan setelah itu - bahkan jika barang-barang selanjutnya itu sebenarnya tersedia! Ini sedikit lebih baik tetapi masih mengalami penundaan, dan katakanlah sebagian besar toko tidak mendukung cara pemesanan ini.

• HTTP / 2 berarti Anda dapat memesan item Anda dalam urutan tertentu - tanpa penundaan (mirip dengan di atas). Toko akan mengirimkannya jika sudah siap, jadi mereka mungkin datang dengan urutan yang berbeda dari yang Anda minta, dan mereka bahkan mungkin membagi barang sehingga beberapa bagian dari pesanan itu tiba lebih dulu (jadi lebih baik daripada yang di atas). Pada akhirnya, ini berarti Anda 1) mendapatkan semuanya lebih cepat secara keseluruhan dan 2) dapat mulai mengerjakan setiap item saat barang tersebut tiba ("oh itu tidak sebaik yang saya kira, jadi saya mungkin ingin memesan yang lain juga atau sebagai gantinya" ).

Tentu saja Anda masih dibatasi oleh ukuran van tukang pos Anda (bandwidth) sehingga mereka mungkin harus meninggalkan beberapa paket kembali di kantor penyortiran hingga hari berikutnya jika mereka penuh untuk hari itu, tetapi itu jarang menjadi masalah dibandingkan keterlambatan dalam mengirimkan pesanan secara langsung dan kembali. Sebagian besar penjelajahan web melibatkan pengiriman surat kecil bolak-balik, bukan paket besar.

Semoga membantu.

Jawaban Sederhana ( Sumber ):

Multiplexing berarti browser Anda dapat mengirim beberapa permintaan dan menerima banyak respons "digabungkan" ke dalam satu koneksi TCP. Jadi, beban kerja yang terkait dengan pencarian DNS dan jabat tangan disimpan untuk file yang berasal dari server yang sama.

Jawaban Kompleks / Terperinci:

Lihat jawaban yang diberikan oleh @BazzaDP.

Multiplexing di HTTP 2.0 adalah jenis hubungan antara browser dan server yang menggunakan satu koneksi untuk mengirimkan banyak permintaan dan respons secara paralel, membuat banyak frame individual dalam proses ini.

Multiplexing memisahkan diri dari semantik permintaan-respons yang ketat dan memungkinkan hubungan satu-ke-banyak atau banyak-ke-banyak.

Minta multiplexing

HTTP / 2 dapat mengirim beberapa permintaan data secara paralel melalui satu koneksi TCP. Ini adalah fitur paling canggih dari protokol HTTP / 2 karena memungkinkan Anda mengunduh file web secara asinkron dari satu server. Sebagian besar browser modern membatasi koneksi TCP ke satu server. Tindakan ini mengurangi waktu perjalanan pulang pergi (RTT) tambahan, membuat situs web Anda memuat lebih cepat tanpa pengoptimalan apa pun, dan membuat pemisahan domain tidak diperlukan.

Karena jawaban @Juanma Menendez benar sementara diagramnya membingungkan, saya memutuskan untuk memperbaikinya, mengklarifikasi perbedaan antara multiplexing dan pipelining, pengertian yang sering digabungkan.

Pipelining (HTTP / 1.1)

Beberapa permintaan dikirim melalui koneksi HTTP yang sama . Tanggapan diterima dengan urutan yang sama. Jika tanggapan pertama membutuhkan banyak waktu, tanggapan lain harus mengantri. Mirip dengan pipeling CPU di mana instruksi diambil sementara yang lain sedang didekodekan. Beberapa instruksi dalam penerbangan pada saat yang sama, tetapi urutannya dipertahankan.

Multiplexing (HTTP / 2)

Beberapa permintaan dikirim melalui waktu yang sama koneksi HTTP yang . Tanggapan diterima dalam urutan yang sewenang-wenang. Tidak perlu menunggu respon lambat yang menghalangi orang lain. Mirip dengan eksekusi instruksi out-of-order di CPU modern.

Semoga gambar yang ditingkatkan menjelaskan perbedaannya: