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?).
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.
Penjelasan yang luar biasa. Contoh adalah apa yang saya butuhkan untuk mendapatkan ini. Jadi di HTTP / 1.1, ada pemborosan waktu antara menunggu respons datang dan mengirim permintaan berikutnya. HTTP / 2 memperbaiki ini. Terima kasih.
pengguna3448600
1
Tapi menurutku kasar. Bisa saja meminta saya untuk menambahkan sepotong bandwidth - yang dengan senang hati saya lakukan dan akan lakukan setelah kita menyelesaikan diskusi ini. Namun IMHO Bandwidth bukanlah masalah besar untuk penjelajahan web (setidaknya di dunia barat) - latensi adalah masalah besar. Dan HTTP / 2 meningkatkan latensi. Sebagian besar situs web terdiri dari banyak sumber daya kecil dan bahkan jika Anda memiliki bandwidth untuk mengunduhnya (seperti yang sering dilakukan orang), itu akan lambat karena latensi jaringan. Bandwidth menjadi lebih menjadi masalah untuk sumber daya yang besar. Saya setuju bahwa situs web dengan gambar besar dan sumber daya lain mungkin masih mencapai batas bandwidth.
Barry Pollard
1
HTTP tidak boleh digunakan untuk memaksakan pemesanan - karena HTTP tidak menawarkan jaminan seperti itu. Dengan HTTP / 2 Anda dapat menyarankan prioritas pengiriman, tetapi bukan pesanan. Juga jika salah satu aset JavaScript Anda di-cache, tetapi yang lainnya tidak, HTTP tidak dapat memengaruhi bahkan prioritasnya. Sebaliknya, Anda harus menggunakan pengurutan dalam HTML ditambah dengan penggunaan async atau defer yang sesuai ( growwiththeweb.com/2014/02/async-vs-defer-attributes.html ), atau pustaka seperti require.js.
Barry Pollard
1
Penjelasan yang bagus. Terima kasih!
hmacias
2
Itu karena HTTP / 1.1 adalah aliran teks dan HTTP / 2 berbasis paket - mereka disebut bingkai di HTTP / 2 daripada paket. Jadi di HTTP / 2 setiap frame dapat diberi tag ke aliran yang memungkinkan interleaving frame. Dalam HTTP / 1.1 tidak ada konsep seperti itu hanya serangkaian baris teks untuk header dan kemudian badan. Detail lebih lanjut di sini: stackoverflow.com/questions/58498116/…
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.
ini dapat dicapai dengan menggunakan pipelining juga di http 1.1. Tujuan utama dari multiplexing di HTTP2 adalah untuk tidak menunggu respon secara teratur
Dhairya Lakhera
4
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.
Contoh Multiplexing HTTP / 2 Anda tidak benar-benar menampilkan multiplexing. Skenario dalam diagram Anda menunjukkan pipelining HTTP yang diperkenalkan di HTTP / 1.1.
ich5003
@ ich5003 Ini adalah Multiplexing karena menggunakan satu koneksi. Tetapi juga benar bahwa kasus pengiriman beberapa respons hanya untuk satu permintaan tidak terwakili di sana.
Juanma Menendez
1
apa yang saya coba katakan, bahwa skenario yang ditunjukkan di atas juga dapat dicapai hanya dengan menggunakan pipelining HTTP.
ich5003
Saya yakin sumber kebingungan di sini adalah urutan permintaan / respons dalam diagram di sebelah kanan - mereka menampilkan kasus khusus multiplexing di HTTP / 2 yang juga dapat dicapai dengan pipelining di HTTP / 1.1. Jika urutan respons dalam diagram berbeda dari urutan permintaan, tidak akan terjadi kebingungan.
raik
4
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:
Jawaban:
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.
sumber
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.
sumber
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.
sumber
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.
sumber
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:
sumber