Saya perlu beberapa saluran dupleks antara dua host. Ada sejumlah keuntungan untuk membangun hanya satu koneksi TCP. Tapi saya ragu multiplexing akan menyebabkan beberapa masalah yang tak terhindarkan. Apakah itu akan merusak kinerja atau meningkatkan latensi secara signifikan? Dan bagaimana dengan penggunaan memori dan penggunaan CPU? Apakah ada saran atau peringatan yang ingin Anda berikan?
Jawaban:
TLDR: Kelemahan utama yang mungkin Anda perhatikan ketika multiplexing beberapa saluran di atas TCP (jika Anda melakukannya dengan benar) adalah latensi yang meningkat karena pemblokiran head-of-line antara saluran.
Konsekuensi: Jika Anda tidak peduli dengan latensi, Anda seharusnya baik-baik saja.
Di sisi lain menggunakan koneksi TCP tunggal “berarti lebih sedikit persaingan dengan aliran lain dan koneksi yang berumur panjang, yang pada gilirannya mengarah pada pemanfaatan yang lebih baik dari kapasitas jaringan yang tersedia” .
Jika Anda multiplex banyak saluran di atas aliran TCP yang sama, saluran tersebut mungkin mengalami pemblokiran head-of-line :
Head-of-line blocking (HOL) dapat terjadi ketika protokol transport menawarkan layanan yang dipesan atau dipesan sebagian: Jika segmen hilang, pesan berikutnya harus menunggu pengiriman ulang yang berhasil dalam antrian penerima dan dengan demikian ditunda.
Ketika Anda multiplex beberapa stream di atas TCP Anda mendapatkan HOL antara saluran .
Jika saluran A telah mengisi buffer pengiriman TCP, Anda harus menunggu sebelum semua data ini diterima sebelum data baru saluran B dapat secara efektif ditransmisikan ke lapisan aplikasi jarak jauh.
Lihat "Multiplexing di atas TCP" untuk detail lebih lanjut tentang saluran multiplexing di atas TCP dan diskusi tentang hackernews .
Contoh khas dari ini adalah SSH. SSH dapat melipatgandakan banyak saluran (lihat ControlMaster, ControlPathdan ControlPersistdi OpenSSH). Menggunakan ini mengurangi biaya inisialisasi sesi SSH baru (latensi awal) tetapi transfer berat pada satu saluran biasanya meningkatkan latensi / interaktivitas yang lain (yang tidak terjadi jika Anda menggunakan beberapa aliran TCP): jika Anda menggunakan interaktif sesi dan mulai memilah-milah transfer file besar melalui saluran yang sama, sesi Anda akan mulai menjadi jauh lebih sedikit interaktif.
HTTP / 2 menggunakan multiplexing dari permintaan / tanggapan melalui TCP untuk memperbaiki pemblokiran HOL. Fitur ini diiklankan di banyak artikel dan makalah tentang HTTP / 2. The HTTP / 2 RFC klaim:
HTTP / 1.1 menambahkan pipelining permintaan, tetapi ini hanya menjawab sebagian konkurensi permintaan dan masih menderita pemblokiran head-of-line.
[...]
Protokol yang dihasilkan lebih ramah ke jaringan karena koneksi TCP lebih sedikit dapat digunakan dibandingkan dengan HTTP / 1.x. Ini berarti lebih sedikit persaingan dengan aliran lain dan koneksi yang lebih lama, yang pada gilirannya mengarah pada pemanfaatan kapasitas jaringan yang tersedia dengan lebih baik.
Namun yang tidak dibahas adalah bahwa pemblokiran HOL tidak sepenuhnya diselesaikan. HTTP / 2 melalui TCP masih menderita ) dari pemblokiran HOL tingkat-TCP .
Ini dibahas dalam artikel LWN ini tentang QUIC:
HTTP / 2 dirancang untuk mengatasi masalah ini menggunakan beberapa "aliran" yang dibangun ke dalam satu koneksi . [...] itu menciptakan masalah baru: hilangnya satu paket akan menghentikan transmisi semua aliran sekaligus, menciptakan masalah latensi baru. Varian ini pada masalah head-of-line-blocking dibangun ke dalam TCP itu sendiri dan tidak dapat diperbaiki dengan lebih banyak tweak pada level HTTP.
Itulah salah satu fitur pembeda dari SCTP (multistreaming), Anda dapat memiliki beberapa stream independen dalam asosiasi SCTP yang sama dan setiap stream tidak memblokir yang lain.
Lihat SSH melalui SCTP - Mengoptimalkan Protokol Multi-Saluran dengan Menyesuaikannya ke SCTP untuk efek menggunakan SCTP untuk menghindari pemblokiran HOL lintas-saluran di SSH:
SCTP hanya mempertahankan urutan pesan dalam aliran tunggal untuk mengurangi efek yang dikenal sebagai pemblokiran head-of-line. Jika pesan hilang, pesan berikutnya harus ditunda sampai pesan yang hilang dikirim ulang untuk mempertahankan pesanan. Karena hanya pesan dari aliran yang sama yang harus ditunda, jumlah pesan yang terpengaruh setelah kerugian berkurang.
[...]
Dengan memetakan saluran SSH ke aliran SCTP, manfaat multi-streaming tersedia untuk SSH, yang merupakan mitigasi pemblokiran head-of-line .
SCTP tidak selalu mudah digunakan (karena ketersediaan OS, interaksi middlebox, dll.). Kemungkinan adalah untuk mengimplementasikannya di atas UDP di userspace .
Contoh lain, adalah protokol QUIC eksperimental yang digunakan untuk multiplexing HTTP melalui UDP (karena multiplexing beberapa stream di atas TCP sebagai HTTP / 2 tidak mengalami pemblokiran HOL ):
QUIC adalah transportasi baru yang mengurangi latensi dibandingkan dengan TCP. Di permukaan, QUIC sangat mirip dengan TCP + TLS + HTTP / 2 diimplementasikan pada UDP.
[...]
Multiplexing tanpa head of line blocking
Protokol QUIC Google: memindahkan web dari TCP ke UDP menyajikan gambaran umum yang baik tentang pemblokiran QUIC dan HOL ketika multiplexing saluran di atas TCP.
Presentasi baru-baru ini mengklaim bahwa HTTP over QUIC meningkatkan latensi tetapi bahwa peningkatan pemblokiran HOL adalah "manfaat lebih kecil":
0-RTT, Lebih dari 50% peningkatan latensi
[...]
Lebih sedikit transmisi berbasis timeout meningkatkan latensi ekor [...]
Lainnya, manfaat lebih kecil, misalnya pemblokiran head of line
Perhatikan bahwa sementara QUIC digambarkan sebagai "sangat mirip dengan TCP + TLS + HTTP / 2 diimplementasikan pada UDP" itu sebenarnya merupakan transportasi tujuan umum yang dapat digunakan secara independen dari HTTP / 2 dan mungkin sesuai dengan kebutuhan Anda.
Catatan: HTTP / QUIC si akan distandarisasi sebagai HTTP / 3 .
Saya akan mengatakan Anda perlu membaca Panduan ZeroMQ , pola yang diberikannya dengan alasan dan kekurangan adalah bacaan penting.
Tetapi jika tidak, tidak ada masalah dengan memutuskan saluran jaringan dari pengiriman data aplikasi Anda. Anda harus mengambil muxing dan demuxing paket data yang dikirim (dan saya akan merekomendasikan arsitektur berbasis paket di sini, bukan streaming data dalam aliran kontinu) dan buffering mereka di setiap ujung.
Seharusnya ada sedikit dampak sebaliknya, Anda mungkin perlu lebih banyak memori - tetapi hanya sedikit - untuk buffer data, dan sedikit lebih banyak CPU karena Anda menangani lebih banyak kode untuk mengunci dan mengurai paket, tetapi tidak ada yang signifikan. (kecuali jika Anda menulis sesuatu yang spesialis yang memerlukan throughput besar dan kinerja sangat penting).
Ya, saya telah membangun sistem basis data klien-server menggunakan prinsip ini dengan tepat.
Saluran digandakan ke satu koneksi TCP yang masing-masing mengirim paket data, yang kemudian dibagi ke masing-masing penerima di ujung lainnya.
Hogging koneksi oleh satu saluran acak dilakukan oleh pengirim koneksi TCP melakukan seleksi round-robin yang paketnya akan dikirim dari antara saluran yang memiliki data siap untuk dikirim.
Untuk menangani kasus satu saluran memutuskan untuk mengirim paket 1GB dan mengunci semua orang, pengirim dapat memilih untuk membagi paket menjadi potongan-potongan dan hanya mengirim satu potongan sebelum memberikan saluran lain giliran. Pada sisi penerima, pemasangan kembali potongan-potongan ke dalam sebuah paket dilakukan sebelum penerima melihat paket tersebut.