OpenVPN mengirim multicast ke setiap klien, bukan ke pelanggan

"Mendukung multicast" menjawab pertanyaan protokol dan membiarkan pertanyaan kapasitas tidak tersentuh. Yang penting secara operasional adalah berapa banyak salinan yang dikirim server untuk satu paket grup dan tunnel mana yang membawanya. Satu aplikasi berlangganan yang menerima aliran hanya membuktikan pengiriman berhasil di suatu tempat. Itu tidak membuktikan klien yang tidak berkepentingan terbebas dari bandwidth.

Tiga pertanyaan di dalam satu klaim fitur

Keanggotaan grup menanyakan apakah penerima bergabung dengan grup. Pengiriman lewat tunnel menanyakan apakah paket melewati tunnel sama sekali. Kebijakan replikasi menanyakan berapa salinan yang dibuat server dan kepada siapa. Pernyataan vendor bisa benar untuk yang pertama dan diam soal yang ketiga, dan di situlah biayanya.

Pisahkan keduanya saat Anda mengukur ukuran tautan. Hanya pertanyaan ketiga yang menetapkan anggaran keluar di sisi server.

Apa yang dilakukan server ruang pengguna dengan paket grup

Di server ruang pengguna tradisional OpenVPN 2.6, paket broadcast atau multicast yang datang diklasifikasikan di jalur masukan TUN/TAP dan diserahkan ke rutin penyebaran broadcast alih-alih pencarian per grup. Rutin itu menelusuri instans klien, melewati pengirim dan setiap instans yang dihentikan, menerapkan pemeriksaan VLAN di tempat yang dikonfigurasi, dan mengantrekan salinan untuk setiap klien yang tersisa. Tidak ada langkah dalam loop itu yang menanyakan tabel keanggotaan. Itu replikasi gaya broadcast, dan itulah seluruh mekanismenya.

Perlakukan ini sebagai sifat jalur kode itu, bukan hukum universal. Jalur data yang dipercepat, implementasi lain, dan versi berbeda dapat berperilaku lain, dan tidak satu pun dari ini menjadikan TAP syarat atau perbaikan.

Anggarkan salinan sebelum mengukur apa pun

Ambil laju muatan dan kalikan dengan jumlah klien yang memenuhi syarat. Aliran yang mengirim satu megabit per detik ke dua puluh klien menghasilkan dua puluh megabit per detik muatan yang meninggalkan server, sebelum enkapsulasi, pengiriman ulang, dan biaya tambahan per klien. Aritmetika itu adalah anggaran, bukan pengukuran penerapan Anda.

ip -s link show tun0

Baca penghitung byte transmisi sebelum dan sesudah interval tetap dengan satu pengirim yang diketahui aktif. Bagi dengan interval dan bandingkan dengan laju muatan dikalikan jumlah klien. Angka yang mendekati laju satu aliran berarti replikasi terbatas cakupannya; angka yang mendekati laju terkali berarti setiap klien menerima salinan.

Penghitung juga mencakup lalu lintas tunnel Anda sendiri, jadi jaga jendela uji tetap pendek dan host tetap tenang. Presisi kalah penting dari orde besaran, dan hanya itu yang Anda butuhkan untuk membedakan satu salinan dari dua puluh.

Uji dua klien yang menuntaskan pertanyaan cakupan

Hubungkan satu klien yang seharusnya menerima aliran dan klien kedua yang tidak. Jalankan pengirim, lalu amati penghitung tunnel klien kedua untuk interval yang sama. Pertumbuhan pada klien kedua adalah bukti langsung replikasi lebar, apa pun kata daftar fitur.

Saring tangkapan ke alamat grup agar Anda tidak membaca lalu lintas yang tidak terkait, dan batasi ke antarmuka tunnel. Menangkap antarmuka fisik pada host yang sibuk menghasilkan berkas yang tidak bisa ditafsirkan siapa pun dan mungkin menyimpan data pengguna yang tidak ingin Anda kumpulkan.

Lalu balikkan peran. Jika hasilnya mengikuti penerima dan bukan grup, Anda melihat sesuatu yang sadar keanggotaan, dan asumsi sebelumnya salah untuk keuntungan Anda.

Memilih desain terbatas alih-alih mencabut batasan

Ketika penyebaran terlalu lebar, perbaikannya adalah pengaturan distribusi terbatas yang didukung, bukan menghapus semua kontrol yang Anda miliki. Pilihannya termasuk mendekatkan titik distribusi ke penerima, memakai model langganan khusus sumber yang membawa identitas sumber sekaligus grup, atau memecah aliran agar situs yang tidak berkepentingan tidak pernah berada di batas distribusi yang sama.

Jaga identitas sumber dan grup tetap terpisah dari fakta telanjang bahwa tujuan adalah multicast. Penerima yang mengenali grup tetapi bukan sumbernya adalah pelanggan berbeda dari yang meminta kanal tertentu. Mencampur keduanya membuat perencanaan kapasitas berikutnya menjadi dugaan.

Model kanal multicast khusus sumber adalah rujukan untuk pembedaan itu. Desain mana pun yang Anda pilih, catat himpunan peer yang memenuhi syarat, pemilik replikasi, dan penghitung yang akan Anda baca lain kali; catatan itulah yang mengubah kejutan bandwidth menjadi biaya yang diketahui.