OpenVPN ส่ง multicast ไปยังไคลเอนต์ทุกเครื่อง ไม่ใช่ผู้สมัครรับข้อมูล
เซิร์ฟเวอร์ในพื้นที่ผู้ใช้คัดลอกแพ็กเก็ตกลุ่มต่อไคลเอนต์ ไม่ใช่ต่อผู้สมัครรับข้อมูล ตั้งงบประมาณการกระจาย พิสูจน์ด้วยตัวนับอุโมงค์ แล้วจึงจำกัดขอบเขตการออกแบบ
"รองรับ multicast" ตอบคำถามด้านโปรโตคอลและปล่อยคำถามด้านความจุไว้ไม่แตะต้อง สิ่งที่สำคัญในเชิงปฏิบัติคือเซิร์ฟเวอร์ส่งสำเนากี่ชุดต่อแพ็กเก็ตกลุ่มหนึ่งชุด และอุโมงค์ใดเป็นตัวขนส่ง แอปพลิเคชันที่สมัครรับข้อมูลหนึ่งตัวซึ่งได้รับสตรีมพิสูจน์เพียงว่าการส่งมอบทำงานได้ที่ใดที่หนึ่งเท่านั้น ไม่ได้พิสูจน์ว่าไคลเอนต์ที่ไม่สนใจนั้นประหยัดแบนด์วิดท์ไปแล้ว
สามคำถามภายในข้ออ้างเรื่องฟีเจอร์เดียว
การเป็นสมาชิกกลุ่มถามว่าเครื่องรับเข้าร่วมกลุ่มหรือไม่ การส่งผ่านอุโมงค์ถามว่าแพ็กเก็ตผ่านอุโมงค์จริงหรือไม่ นโยบายการทำสำเนาถามว่าเซิร์ฟเวอร์สร้างสำเนากี่ชุดและให้ใคร คำกล่าวอ้างของผู้ขายอาจเป็นจริงในข้อแรกและเงียบในข้อที่สาม และนั่นคือที่ที่ต้นทุนอยู่
แยกทั้งสามออกจากกันเมื่อคุณประมาณขนาดลิงก์ มีเพียงคำถามที่สามเท่านั้นที่กำหนดงบประมาณขาออกฝั่งเซิร์ฟเวอร์
เซิร์ฟเวอร์พื้นที่ผู้ใช้ทำอะไรกับแพ็กเก็ตกลุ่ม
ในเซิร์ฟเวอร์พื้นที่ผู้ใช้แบบเดิมของ OpenVPN 2.6 แพ็กเก็ต broadcast หรือ multicast ที่เข้ามาจะถูกจำแนกในเส้นทางขาเข้า TUN/TAP และถูกส่งต่อไปยังรูทีนการกระจายแบบ broadcast แทนการค้นหาตามกลุ่ม รูทีนนั้นไล่ผ่านอินสแตนซ์ไคลเอนต์ ข้ามผู้ส่งและอินสแตนซ์ที่หยุดไว้ ใช้การตรวจสอบ VLAN ในจุดที่มีการกำหนดค่า และจัดสำเนาเข้าคิวให้ไคลเอนต์ที่เหลือแต่ละราย ไม่มีขั้นตอนใดในลูปนั้นสอบถามตารางสมาชิกภาพ นี่คือการทำสำเนาแบบ broadcast และนั่นคือกลไกทั้งหมด
มองสิ่งนี้เป็นคุณสมบัติของเส้นทางโค้ดนั้น ไม่ใช่กฎสากล เส้นทางข้อมูลที่เร่งความเร็ว การใช้งานอื่น และเวอร์ชันที่ต่างกันอาจทำงานต่างออกไป และไม่มีสิ่งใดทำให้ TAP เป็นข้อกำหนดหรือการซ่อมแซม
ตั้งงบประมาณสำเนาก่อนจะวัดสิ่งใด
นำอัตราเพย์โหลดมาคูณกับจำนวนไคลเอนต์ที่เข้าเกณฑ์ สตรีมที่ส่งหนึ่งเมกะบิตต่อวินาทีไปยังไคลเอนต์ยี่สิบรายสร้างเพย์โหลดยี่สิบเมกะบิตต่อวินาทีที่ออกจากเซิร์ฟเวอร์ ก่อนการห่อหุ้ม การส่งซ้ำ และค่าใช้จ่ายใด ๆ ต่อไคลเอนต์ การคำนวณนั้นคืองบประมาณ ไม่ใช่การวัดการติดตั้งของคุณ
ip -s link show tun0อ่านตัวนับไบต์ส่งก่อนและหลังช่วงเวลาคงที่โดยมีผู้ส่งที่รู้จักหนึ่งรายทำงานอยู่ หารด้วยช่วงเวลาและเปรียบเทียบกับอัตราเพย์โหลดคูณจำนวนไคลเอนต์ ตัวเลขใกล้เคียงอัตราของสตรีมเดียวหมายความว่าการทำสำเนาถูกจำกัดขอบเขต ตัวเลขใกล้เคียงอัตราที่คูณแล้วหมายความว่าไคลเอนต์ทุกรายได้รับสำเนา
ตัวนับยังรวมทราฟฟิกอุโมงค์ของคุณเองด้วย ดังนั้นให้ช่วงทดสอบสั้นและโฮสต์เงียบในเวลาอื่น ความแม่นยำสำคัญน้อยกว่าอันดับของขนาด และนั่นคือทั้งหมดที่คุณต้องใช้เพื่อแยกสำเนาหนึ่งชุดออกจากยี่สิบชุด
การทดสอบด้วยไคลเอนต์สองเครื่องที่ชี้ขาดคำถามเรื่องขอบเขต
เชื่อมต่อไคลเอนต์หนึ่งรายที่ควรได้รับสตรีมและอีกรายที่ไม่ควร เริ่มผู้ส่ง แล้วดูตัวนับอุโมงค์ของไคลเอนต์รายที่สองในช่วงเวลาเดียวกัน การเติบโตที่ไคลเอนต์รายที่สองเป็นหลักฐานโดยตรงของการทำสำเนาแบบกว้าง ไม่ว่ารายการฟีเจอร์จะกล่าวอย่างไร
กรองการดักจับไปที่ที่อยู่กลุ่มเพื่อไม่ให้อ่านทราฟฟิกที่ไม่เกี่ยวข้อง และจำกัดไว้ที่อินเทอร์เฟซอุโมงค์ การดักจับอินเทอร์เฟซกายภาพบนโฮสต์ที่ยุ่งจะได้ไฟล์ที่ไม่มีใครตีความได้ และอาจเก็บข้อมูลผู้ใช้ที่คุณไม่ได้ตั้งใจจะเก็บ
จากนั้นสลับบทบาท หากผลลัพธ์เป็นไปตามเครื่องรับมากกว่ากลุ่ม แสดงว่าคุณกำลังดูสิ่งที่คำนึงถึงสมาชิกภาพ และสมมติฐานเดิมผิดไปในทางที่เป็นประโยชน์กับคุณ
เลือกการออกแบบที่จำกัดขอบเขตแทนการถอนข้อจำกัด
เมื่อการกระจายกว้างเกินไป วิธีแก้คือการจัดการกระจายแบบจำกัดขอบเขตที่ได้รับการสนับสนุน ไม่ใช่การลบการควบคุมทุกอย่างที่คุณมี ทางเลือกได้แก่การย้ายจุดกระจายให้ใกล้เครื่องรับมากขึ้น การใช้รูปแบบการสมัครรับข้อมูลเฉพาะแหล่งที่พาทั้งข้อมูลระบุแหล่งและกลุ่ม หรือการแบ่งสตรีมเพื่อให้ไซต์ที่ไม่สนใจไม่อยู่บนขอบเขตการกระจายเดียวกันเลย
แยกข้อมูลระบุแหล่งและกลุ่มออกจากข้อเท็จจริงเปล่า ๆ ที่ว่าปลายทางเป็น multicast เครื่องรับที่รู้จักกลุ่มแต่ไม่รู้จักแหล่งคือผู้สมัครรับข้อมูลที่ต่างจากผู้ที่ขอช่องเฉพาะ การผสมทั้งสองเข้าด้วยกันทำให้การวางแผนความจุในภายหลังเป็นการเดา
แบบจำลองช่อง multicast เฉพาะแหล่งเป็นข้อมูลอ้างอิงสำหรับความแตกต่างนั้น ไม่ว่าคุณจะเลือกการออกแบบใด ให้จดชุดเพียร์ที่เข้าเกณฑ์ ผู้รับผิดชอบการทำสำเนา และตัวนับที่คุณจะอ่านในครั้งหน้า บันทึกนั้นคือสิ่งที่เปลี่ยนความประหลาดใจเรื่องแบนด์วิดท์ให้เป็นต้นทุนที่รู้ล่วงหน้า