IP มัลติแคสต์ (IP multicast ) คือวิธีการส่งดาตาแกรมโปรโตคอลอินเทอร์เน็ต (IP) ไปยังกลุ่มผู้รับที่สนใจในการส่งครั้งเดียว เป็นรูปแบบมัลติแคสต์ เฉพาะของ IP และใช้สำหรับการสตรีมมีเดียและแอปพลิเคชันเครือข่ายอื่นๆ โดยใช้บล็อกที่อยู่มัลติแคสต์ที่สงวนไว้เป็น พิเศษในIPv4และIPv6

โปรโตคอลที่เกี่ยวข้องกับ IP มัลติแคสต์ ได้แก่Internet Group Management Protocol (IGMP) , Protocol Independent Multicast (IPMP ) และMulticast VLAN Registration (VLAN ) IGMP snoopingใช้ในการจัดการทราฟฟิก IP มัลติแคสต์บนเครือ ข่ายเลเยอร์ 2

IP multicast ได้รับการอธิบายไว้ในRFC  1112 IP multicast ได้รับการกำหนดมาตรฐานครั้งแรกในปี 1986 ^{[ 1 ]}ข้อกำหนดได้รับการขยายเพิ่มเติมในRFC  4604เพื่อรวมการจัดการกลุ่ม และในRFC  5771เพื่อรวมที่อยู่ที่มีขอบเขตการบริหารจัดการ

IP มัลติแคสต์เป็นเทคนิคสำหรับ การสื่อสารแบบเรียลไทม์ จากหนึ่งไปยังหลายและจากหลายไปยังหลายผ่านโครงสร้างพื้นฐาน IP ในเครือข่าย เทคนิคนี้สามารถรองรับผู้รับจำนวนมากได้โดยไม่จำเป็นต้องทราบตัวตนของผู้รับหรือจำนวนผู้รับล่วงหน้า มัลติแคสต์ใช้โครงสร้างพื้นฐานเครือข่ายอย่างมีประสิทธิภาพโดยที่ผู้ส่งต้องส่งแพ็กเก็ตเพียงครั้งเดียวเท่านั้น แม้ว่าจะต้องส่งไปยังผู้รับจำนวนมากก็ตาม โหนดในเครือข่าย (โดยทั่วไปคือสวิตช์เครือข่ายและเราเตอร์ ) จะทำหน้าที่คัดลอกแพ็กเก็ตเพื่อให้ส่งไปยังผู้รับหลายราย ทำให้ข้อความถูกส่งผ่านแต่ละลิงก์ของเครือข่ายเพียงครั้งเดียวเท่านั้น

โปรโตคอล เลเยอร์การขนส่งที่ใช้การกำหนดแอดเดรสแบบมัลติแคสต์ที่พบบ่อยที่สุด คือ User Datagram Protocol (UDP) โดยธรรมชาติแล้ว UDP ไม่น่าเชื่อถือ – ข้อความอาจสูญหายหรือส่งไม่เรียงลำดับ โปรโตคอล มัลติแคสต์ที่น่าเชื่อถือกว่าเช่นPragmatic General Multicast (PGM) ได้รับการพัฒนาขึ้นเพื่อเพิ่มการตรวจจับการสูญหายและการส่งซ้ำบนมัลติแคสต์ IP

แนวคิดหลักในการมัลติแคสต์ IP ได้แก่ ที่อยู่กลุ่มมัลติแคสต์ IP ^{[ 2 ]}ต้นไม้กระจายมัลติแคสต์ และการสร้างต้นไม้ที่ขับเคลื่อนโดยผู้รับ^{[ 3 ]}

ที่อยู่กลุ่มมัลติแคสต์ IP ถูกใช้โดยแหล่งที่มาและผู้รับเพื่อส่งและรับข้อความมัลติแคสต์ แหล่งที่มาใช้ที่อยู่กลุ่มเป็นที่อยู่ปลายทาง IP ในแพ็กเก็ตข้อมูล ผู้รับใช้ที่อยู่กลุ่มนี้เพื่อแจ้งให้เครือข่ายทราบว่าพวกเขาสนใจที่จะรับแพ็กเก็ตที่ส่งไปยังกลุ่มนั้น ตัวอย่างเช่น หากเนื้อหาบางอย่างเกี่ยวข้องกับกลุ่ม239.1.1.1แหล่งที่มาจะส่งแพ็กเก็ตข้อมูลที่มีปลายทางเป็น239.1.1.1ผู้รับสำหรับเนื้อหานั้นจะแจ้งให้เครือข่ายทราบว่าพวกเขาสนใจที่จะรับแพ็กเก็ตข้อมูลที่ส่งไปยังกลุ่ม239.1.1.1ผู้รับ จะ เข้าร่วม239.1.1.1โปรโตคอลที่ผู้รับใช้ในการเข้าร่วมกลุ่มโดยทั่วไปเรียกว่าInternet Group Management Protocol (IGMP) ^{[ 4 ]}

ด้วยโปรโตคอลการกำหนดเส้นทางที่ใช้โครงสร้างต้นไม้ร่วมกัน เมื่อผู้รับเข้าร่วมกลุ่มมัลติแคสต์ IP เฉพาะกลุ่มใดกลุ่มหนึ่งแล้ว โครงสร้างต้นไม้การกระจายมัลติแคสต์จะถูกสร้างขึ้นสำหรับกลุ่มนั้น โปรโตคอลที่ใช้กันอย่างแพร่หลายที่สุดคือProtocol Independent Multicast (PIM) PIM จะสร้างโครงสร้างต้นไม้การกระจายมัลติแคสต์เพื่อให้แพ็กเก็ตข้อมูลจากผู้ส่งไปยังกลุ่มมัลติแคสต์ไปถึงผู้รับทั้งหมดที่เข้าร่วมกลุ่มนั้น PIM มีหลายรูปแบบ ได้แก่Sparse Mode (SM), Dense Mode (DM), source-specific multicast (SSM) และ Bidirectional Mode (Bidir หรือ Sparse-Dense Mode, SDM) ในบรรดารูปแบบเหล่านี้ PIM-SM เป็นรูปแบบที่ใช้กันอย่างแพร่หลายที่สุดในปี 2006 ส่วน SSM และ Bidir เป็นรูปแบบที่เรียบง่ายและปรับขนาดได้ ซึ่งพัฒนาขึ้นในภายหลังและกำลังได้รับความนิยมมากขึ้น

การทำงานของ IP multicast ไม่จำเป็นต้องมีแหล่งที่มาที่ใช้งานอยู่เพื่อทราบเกี่ยวกับผู้รับของกลุ่ม การสร้างโครงสร้างต้นไม้ multicast นั้นขับเคลื่อนโดยผู้รับและเริ่มต้นโดยโหนดเครือข่ายที่อยู่ใกล้กับผู้รับ IP multicast สามารถขยายขนาดไปยังประชากรผู้รับจำนวนมากได้Dave Clark สถาปนิกอินเทอร์เน็ตได้อธิบายโมเดล IP multicast ไว้ว่า "คุณใส่แพ็กเก็ตเข้าไปที่ปลายด้านหนึ่ง และเครือข่ายจะร่วมมือกันเพื่อส่งมอบให้กับทุกคนที่ร้องขอ" ^{[ 5 ]}

IP multicast สร้างข้อมูลสถานะสำหรับแต่ละโครงสร้างการกระจาย multicast ในเครือข่าย หากเราเตอร์เป็นส่วนหนึ่งของโครงสร้าง multicast 1000 โครงสร้าง ก็จะมีรายการการกำหนดเส้นทางและการส่งต่อ multicast 1000 รายการ ในทางกลับกัน เราเตอร์ multicast ไม่จำเป็นต้องรู้วิธีเข้าถึงโครงสร้าง multicast อื่นๆ ทั้งหมดในอินเทอร์เน็ต มันจำเป็นต้องรู้เฉพาะโครงสร้าง multicast ที่มีตัวรับปลายทางอยู่เท่านั้น นี่เป็นกุญแจสำคัญในการขยายขนาดบริการที่ใช้ที่อยู่ multicast ในทางตรงกันข้าม เราเตอร์ unicast จำเป็นต้องรู้วิธีเข้าถึงที่อยู่ unicast อื่นๆ ทั้งหมดในอินเทอร์เน็ต แม้ว่าจะทำเช่นนั้นโดยใช้เพียงเส้นทางเริ่มต้นก็ตาม ด้วยเหตุนี้ การรวมกลุ่มจึงเป็นกุญแจสำคัญในการขยายขนาดการกำหนดเส้นทาง unicast นอกจากนี้ ยังมีเราเตอร์หลักที่เก็บเส้นทางหลายแสนเส้นทางเนื่องจากมีตารางการกำหนดเส้นทาง อินเทอร์เน็ตอยู่ ภายใน

แต่ละโฮสต์ที่ต้องการเป็นสมาชิกผู้รับของกลุ่มมัลติแคสต์ (เช่น รับข้อมูลที่ตรงกับที่อยู่มัลติแคสต์เฉพาะ) จะต้องใช้ IGMP ในการเข้าร่วม เราเตอร์ที่อยู่ติดกันก็ใช้โปรโตคอลนี้ในการสื่อสารเช่นกัน

ในการกำหนดเส้นทางแบบยูนิแคสต์ (Unicast Routing) เราเตอร์แต่ละตัวจะตรวจสอบที่อยู่ปลายทางของแพ็กเก็ตขาเข้าและค้นหาปลายทางในตารางเพื่อพิจารณาว่าควรใช้อินเทอร์เฟซใดเพื่อให้แพ็กเก็ตนั้นเข้าใกล้ปลายทางมากขึ้น ที่อยู่ต้นทางไม่เกี่ยวข้องกับเราเตอร์ อย่างไรก็ตาม ในการกำหนดเส้นทางแบบมัลติแคสต์ (Multicast Routing) ที่อยู่ต้นทาง (ซึ่งเป็นที่อยู่ยูนิแคสต์แบบง่าย) จะถูกใช้เพื่อกำหนดทิศทางของกระแสข้อมูล ต้นทางของทราฟฟิกมัลติแคสต์ถือเป็นต้นทาง เราเตอร์จะพิจารณาว่าอินเทอร์เฟซปลายทางใดเป็นปลายทางสำหรับกลุ่มมัลติแคสต์นี้ (ที่อยู่ปลายทาง) และส่งแพ็กเก็ตออกไปผ่านอินเทอร์เฟซที่เหมาะสม คำว่า การส่งต่อ แบบย้อนกลับ (Reverse-path forwarding)ใช้เพื่ออธิบายแนวคิดของการกำหนดเส้นทางแพ็กเก็ตออกจากต้นทาง แทนที่จะไปยังปลายทาง

อาจเกิดข้อผิดพลาดหลายประการหากแพ็กเก็ตที่ตั้งใจส่งแบบยูนิคาสต์ถูกส่งไปยังที่อยู่มัลติคาสต์โดยไม่ได้ตั้งใจ โดยเฉพาะอย่างยิ่ง การส่งแพ็กเก็ต ICMP ไปยังที่อยู่มัลติคาสต์นั้นถูกนำมาใช้ในบริบทของการโจมตีแบบ DoSเพื่อเพิ่มจำนวนแพ็กเก็ต

ในเครือข่ายท้องถิ่น การส่งข้อมูลแบบมัลติแคสต์จะถูกควบคุมโดย IGMP (บน เครือข่าย IPv4 ) และMLD (บน เครือข่าย IPv6 ) ภายในโดเมนการกำหนดเส้นทางจะ ใช้ PIMหรือMOSPF และระหว่างโดเมนการกำหนดเส้นทาง จะใช้โปรโตคอลการกำหนดเส้นทางมัลติแคส ต์ ระหว่างโดเมน เช่นMBGP

ต่อไปนี้คือโปรโตคอลการส่งและกำหนดเส้นทางทั่วไปที่ใช้สำหรับการกระจายแบบมัลติแคสต์:

• โปรโตคอลการจัดการกลุ่มอินเทอร์เน็ต (IGMP)
• มัลติแคสต์ที่ไม่ขึ้นกับโปรโตคอล (PIM)
• โปรโตคอลการกำหนดเส้นทางมัลติแคสต์แบบเวกเตอร์ระยะทาง (DVMRP)
• Multicast Open Shortest Path First (MOSPF)
• BGP แบบมัลติแคสต์ (MBGP)
• โปรโตคอลการค้นหาแหล่งที่มาแบบมัลติแค สต์ (MSDP)
• การค้นหาผู้ฟังมัลติแคสต์ (MLD)
• โปรโตคอลการลงทะเบียนมัลติแคสต์ GARP (GMRP)

แพ็กเก็ตแบบ Unicast จะถูกส่งไปยังผู้รับที่ระบุบนซับเน็ต Ethernet หรือIEEE 802.3 โดยการตั้ง ค่าที่อยู่ MACเลเยอร์ 2 เฉพาะบนที่อยู่แพ็กเก็ต Ethernet ส่วนแพ็กเก็ตแบบ Broadcast จะใช้ที่อยู่ MAC แบบ Broadcast ในรูปแบบ FF:FF:FF:FF:FF: FF

แพ็กเก็ตมัลติแคสต์ IPv4จะถูกส่งโดยใช้ช่วงที่อยู่ MAC ของอีเธอร์เน็ต01:00:5E:00:00:00ถึง01:00:5E:7F:FF:FF (โดย มี OUIเป็นของIANA ) ช่วงนี้มีพื้นที่ที่อยู่ 23 บิตที่ใช้งานได้ อ็อกเท็ตแรก (01) ประกอบด้วยบิตบรอดแคสต์/มัลติแคสต์ บิต 23 บิตล่างของที่อยู่ IP มัลติแคสต์ 28 บิตจะถูกแมปไปยังพื้นที่ที่อยู่อีเธอร์เน็ต 23 บิตที่ใช้งานได้ ซึ่งหมายความว่ามีความกำกวมในการส่งแพ็กเก็ต หากโฮสต์สองเครื่องบนซับเน็ตเดียวกันสมัครรับกลุ่มมัลติแคสต์ที่แตกต่างกันซึ่งที่อยู่แตกต่างกันเพียง 5 บิตแรก แพ็กเก็ตอีเธอร์เน็ตสำหรับทั้งสองกลุ่มมัลติแคสต์จะถูกส่งไปยังโฮสต์ทั้งสอง ทำให้ซอฟต์แวร์เครือข่ายในโฮสต์ต้องทิ้งแพ็กเก็ตที่ไม่ต้องการ^{[ 6 ]}

สำหรับที่อยู่มัลติแคสต์ IPv6ที่อยู่ MAC ของอีเธอร์เน็ตจะถูกสร้างขึ้นโดยการนำอ็อกเท็ตลำดับต่ำสี่ตัวมา OR กับ MAC 33:33:00:00:00:00ดังนั้น ตัวอย่างเช่น ที่อยู่ IPv6 ff02:dead:beef::1:3จะถูกแมปไปยังที่อยู่ MAC ของอีเธอร์เน็ต33:33:00:01:00:03 [ ^{7 ] หาก} สวิตช์ไม่เข้าใจที่อยู่มัลติแคสต์ สวิตช์จะส่งทราฟฟิกนั้นไปยังสมาชิกทั้งหมดของ LAN ในกรณีนี้ การ์ดเครือข่ายของระบบ (หรือระบบปฏิบัติการ) จะต้องกรองแพ็กเก็ตที่ส่งไปยังกลุ่มมัลติแคสต์ที่ไม่ได้สมัครรับข้อมูล

มีสวิตช์ที่คอยรับฟังข้อมูล IGMP และเก็บรักษาตารางสถานะว่าระบบเครือข่ายใดบ้างที่สมัครรับข้อมูลกลุ่มมัลติแคสต์ที่กำหนดไว้ จากนั้นจะใช้ตารางนี้ในการส่งต่อข้อมูลที่มุ่งไปยังกลุ่มที่กำหนดไปยังโฮสต์ (พอร์ต) จำนวนจำกัดเท่านั้น กระบวนการรับฟังข้อมูล IGMP นี้เรียกว่าIGMP snooping

นอกจากนี้ สวิตช์บางตัวที่มีความสามารถระดับเลเยอร์ 3 ยังสามารถทำหน้าที่เป็น IGMP querier ได้อีกด้วย ในเครือข่ายที่ไม่มีเราเตอร์ทำหน้าที่เป็นเราเตอร์มัลติแคสต์ สวิตช์ที่เปิดใช้งาน IGMP snooping querier สามารถใช้สร้างข้อความ IGMP ที่จำเป็นเพื่อให้ผู้ใช้สมัครรับข้อมูลมัลติแคสต์ได้

เครือข่ายไร้สาย 802.11ใช้ช่วงที่อยู่ MAC เดียวกันกับอีเธอร์เน็ตแบบมีสายเพื่อแมปที่อยู่ IP มัลติแคสต์ อย่างไรก็ตาม เครือข่ายไร้สาย 802.11 จัดการทราฟฟิกมัลติแคสต์แตกต่างกัน ขึ้นอยู่กับการกำหนดค่าข้อความบ่งชี้การส่งทราฟฟิก (DTIM) และ การตั้งค่า ช่วงเวลาบีคอนหากไม่มีสถานีใดในชุดบริการพื้นฐานอยู่ในโหมดประหยัดพลังงาน แพ็กเก็ตมัลติแคสต์จะถูกส่งทันทีเมื่อมาถึง หากมีสถานีอย่างน้อยหนึ่งสถานีอยู่ในโหมดประหยัดพลังงาน จุดเชื่อมต่อจะส่งทราฟฟิกมัลติแคสต์หลังจากช่วงเวลา DTIM แต่ละช่วงเท่านั้น และส่งด้วยอัตราที่รองรับอัตราใดอัตราหนึ่งในชุดอัตราพื้นฐาน ในจุดเชื่อมต่อไร้สายส่วนใหญ่ การกำหนดค่าเริ่มต้นสำหรับช่วงเวลานี้คือ 102.4 มิลลิวินาที (ช่วงเวลาบีคอน = 100 มิลลิวินาที, DTIM = 1) หรือ 204.8 มิลลิวินาที (ช่วงเวลาบีคอน = 100 มิลลิวินาที, DTIM = 2) และอัตราการส่งคือ1 เมกะบิต/วินาทีหรือ6 เมกะบิต/วินาทีขึ้นอยู่กับย่านความถี่ที่ใช้งานและโหมดการป้องกัน สามารถปรับการตั้งค่า DTIM และช่วงเวลาบีคอนเพื่อปรับปรุงประสิทธิภาพมัลติแคสต์ในเครือข่ายไร้สายได้^{[ 8 ]}

ต่างจากอีเธอร์เน็ต การรับส่งข้อมูลส่วนใหญ่ใน 802.11 จะถูกส่งอย่างน่าเชื่อถือโดยใช้ ACK และ NACK เพื่อป้องกันการรบกวนทางวิทยุที่ไม่ก่อให้เกิดการสูญเสียแพ็กเก็ต ที่สูงเกินไป อย่างไรก็ตาม แพ็กเก็ตมัลติแคสต์จะถูกส่งเพียงครั้งเดียวและไม่ได้รับการยืนยัน ดังนั้นจึงมีอัตราการสูญเสียที่สูงกว่ามาก มีวิธีการต่างๆ ในการจัดการกับปัญหานี้ เช่น การเลือกที่จะส่งข้อมูลมัลติแคสต์แบบยูนิแคสต์ซ้ำๆ ไปยังไคลเอนต์แต่ละราย หรือการขอ ACK จากไคลเอนต์แต่ละราย^{[ 9 ]}บางวิธีต้องการเพียงการแก้ไขที่จุดเชื่อมต่อ และได้รับการสนับสนุนในอุปกรณ์ระดับองค์กรบางประเภท ในขณะที่การปรับปรุงอื่นๆ จะต้องมีการแก้ไขที่ไคลเอนต์ ดังนั้นจึงยังไม่ได้รับการนำไปใช้อย่างแพร่หลาย

IP มัลติแคสต์เป็นวิธีการสื่อสารทางอินเทอร์เน็ตที่สามารถส่งแพ็กเก็ตข้อมูลเดียวจากผู้ส่งไปยังกลุ่มผู้รับได้ เทคนิคการทำซ้ำนั้นขึ้นอยู่กับสื่อที่ใช้ในการส่งข้อมูล การส่งข้อมูลมัลติแคสต์บนสื่อกระจายเสียงโดยธรรมชาติ เช่น อีเธอร์เน็ตหรือลิงก์ดาวเทียม จะทำให้แพ็กเก็ตข้อมูลถูกส่งไปยังผู้รับทั้งหมดที่เชื่อมต่อกับสื่อนั้นโดยตรงโดยอัตโนมัติ ในทางตรงกันข้าม การส่งข้อมูลมัลติแคสต์บนสื่อแบบจุดต่อจุดหรือจุดต่อหลายจุด จำเป็นต้องทำซ้ำแพ็กเก็ตสำหรับแต่ละลิงก์ กระบวนการทำซ้ำควรเกิดขึ้นอย่างเหมาะสมโดยการสร้างโครงสร้างต้นไม้กระจายภายในเครือข่าย แพ็กเก็ตสามารถทำซ้ำได้ที่แต่ละสาขาในต้นไม้ ซึ่งจะช่วยลดความจำเป็นที่ผู้ส่งจะต้องทำซ้ำแพ็กเก็ตหนึ่งครั้งสำหรับผู้รับแต่ละราย

การใช้IPsecเป็นลิงก์การสื่อสารจำเป็นต้องสร้างการเชื่อมต่อแบบจุดต่อจุด โดยปกติแล้ว ความปลอดภัยจะจำเป็นตั้งแต่ผู้ส่งไปจนถึงผู้รับ ซึ่งหมายความว่าผู้ส่งจะต้องทำสำเนาแพ็กเก็ตในแต่ละการเชื่อมต่อที่ปลอดภัย – หนึ่งสำเนาสำหรับผู้รับแต่ละราย เมื่อจำนวนผู้รับเพิ่มขึ้น ผู้ส่งจะต้องปรับขนาดโดยการทำสำเนาแพ็กเก็ตไปยังผู้รับแต่ละราย ภาระการประมวลผลที่เกิดขึ้นกับผู้ส่งอาจสูง ซึ่งจำกัดความสามารถในการปรับขนาดของผู้ส่ง จึงจำเป็นต้องมีวิธีการใหม่ในการส่งข้อมูลแบบมัลติแคสต์อย่างปลอดภัย และวิธีการนี้เรียกว่า Secure Multicast หรือ Multicast Security

คณะทำงานด้านวิศวกรรมอินเทอร์เน็ต ( IETF ) ได้สร้างโปรโตคอลอินเทอร์เน็ต (IP) ใหม่เพื่อส่งข้อมูลมัลติแคสต์อย่างปลอดภัยผ่านเครือข่ายแพ็กเก็ต นิยามของโปรโตคอลนี้ได้รับการพัฒนาในกลุ่มงานด้านความปลอดภัยมัลติแคสต์ และนำไปสู่เอกสารขอความคิดเห็น (RFC) หลายฉบับ ซึ่งปัจจุบันใช้เป็นมาตรฐานสำหรับการรักษาความปลอดภัยของข้อมูลมัลติแคสต์บน IP โปรโตคอลนี้อนุญาตให้ผู้ส่งเข้ารหัสแพ็กเก็ตมัลติแคสต์และส่งต่อไปยังเครือข่ายแพ็กเก็ตบนโครงสร้างการกระจายที่เหมาะสมที่สุด แพ็กเก็ตอาจถูกทำสำเนาในตำแหน่งที่เหมาะสมที่สุดในเครือข่ายและส่งไปยังผู้รับทั้งหมด ผู้รับสามารถถอดรหัสแพ็กเก็ตและส่งต่อในสภาพแวดล้อมเครือข่ายที่ปลอดภัย ผู้ส่งแพ็กเก็ตมัลติแคสต์ไม่รู้จักผู้รับที่เป็นไปได้ ดังนั้นการสร้างคีย์การเข้ารหัสแบบคู่ (หนึ่งคีย์สำหรับผู้รับแต่ละราย) จึงเป็นไปไม่ได้ ผู้ส่งต้องเข้ารหัสแพ็กเก็ตโดยใช้คีย์ร่วมกันที่ผู้รับที่ถูกต้องทั้งหมดใช้ในการถอดรหัสแพ็กเก็ต ความปลอดภัยของระบบขึ้นอยู่กับความสามารถในการควบคุมการแจกจ่ายคีย์เฉพาะให้กับผู้รับที่ถูกต้องเหล่านั้นเท่านั้น ด้วยเหตุนี้ IETF จึงได้สร้าง โปรโตคอล Group Domain of Interpretation (GDOI) ซึ่งกำหนดไว้ใน RFC 6407 โปรโตคอลนี้อนุญาตให้ผู้ส่งและผู้รับเข้าร่วมเซิร์ฟเวอร์คีย์ ซึ่งนโยบายและคีย์จะถูกเข้ารหัสและแจกจ่ายให้กับสมาชิกของกลุ่มมัลติแคสต์ที่ปลอดภัย เซิร์ฟเวอร์คีย์สามารถตรวจสอบและอนุญาตผู้ส่งและผู้รับให้เข้าร่วมกลุ่มเฉพาะ โดยใช้คีย์ร่วมกันในการเข้ารหัสและถอดรหัสข้อมูลระหว่างสมาชิกของกลุ่ม

โดยธรรมชาติแล้ว มัลติแคสต์ไม่ใช่กลไกที่เน้นการเชื่อมต่อ ดังนั้นโปรโตคอลอย่างTCPซึ่งอนุญาตให้ส่งแพ็กเก็ตที่หายไปซ้ำได้ จึงไม่เหมาะสม สำหรับแอปพลิเคชันเช่นการสตรีมเสียงและวิดีโอ แพ็กเก็ตที่หายไปเป็นครั้งคราวไม่ใช่ปัญหา แต่สำหรับการกระจายข้อมูลที่สำคัญ จำเป็นต้องมีกลไกสำหรับการร้องขอการส่งซ้ำ

หนึ่งในแผนการดังกล่าว ซึ่งเสนอโดยซิสโก้ คือ PGM (เดิมชื่อ Pretty Good Multicasting แต่เปลี่ยนชื่อเป็นPragmatic General Multicast ด้วยเหตุผลด้านเครื่องหมายการค้า ) ซึ่งได้รับการบันทึกไว้ใน RFC 3208 ในแผนการนี้ แพ็กเก็ตมัลติแคสต์จะมีหมายเลขลำดับ และเมื่อแพ็กเก็ตหายไป ผู้รับสามารถร้องขอให้ส่งแพ็กเก็ตนั้นซ้ำไปยังสมาชิกอื่น ๆ ในกลุ่มมัลติแคสต์ โดยไม่สนใจข้อมูลทดแทนหากไม่จำเป็น เวอร์ชันที่ขยายเพิ่มเติมคือ PGM-CC พยายามทำให้ IP Multicasting เป็นมิตรกับ TCP มากขึ้นโดยการลดแบนด์วิดท์ของกลุ่มทั้งหมดลงให้เหลือเท่ากับแบนด์วิดท์ที่มีอยู่ของผู้รับที่แย่ที่สุด

แผนงานอื่น ๆ อีกสองแผนที่ได้รับการบันทึกไว้โดยInternet Engineering Task Force (IETF) ได้แก่ โปรโตคอลมาตรฐานNACK-Oriented Reliable Multicast (NORM) ซึ่งได้รับการบันทึกไว้ใน RFC 5740 และ RFC 5401 และโปรโตคอลFile Delivery over Unidirectional Transport (FLUTE) ซึ่งได้รับการบันทึกไว้ใน RFC 6726 มีการใช้งานแบบโอเพนซอร์สและแบบกรรมสิทธิ์สำหรับโปรโตคอลเหล่านี้ นอกจากนี้ยังมีโปรโตคอลอื่น ๆ เช่นScalable Reliable Multicastซึ่งได้รับการกำหนดโดยแหล่งข้อมูลที่หลากหลาย โปรโตคอลเหล่านี้แตกต่างกันในวิธีการตรวจจับข้อผิดพลาด กลไกที่ใช้ในการกู้คืนข้อผิดพลาด ความสามารถในการปรับขนาดของการกู้คืน และแนวคิดพื้นฐานที่เกี่ยวข้องกับความหมายของความน่าเชื่อถือ รายการโปรโตคอลมัลติแคสต์ที่เชื่อถือได้จาก ACM SIGCOMM Multicast Workshop เมื่อวันที่ 27 สิงหาคม 1996 ได้บันทึกแนวทางต่าง ๆ ในการแก้ปัญหานี้ไว้

กลุ่มอิสระต่างๆ เช่น Internet Protocol Multicast Standards Initiative (IPMSI) อ้างว่า การขาดโปรโตคอล IP Multicast ที่ปลอดภัยและเชื่อถือได้ซึ่งสามารถปรับขนาดได้จริง เช่นSecure Multicast for Advanced Repeating of Television (SMART) ที่เสนอไว้ ได้ ขัดขวางการนำ IP multicast มาใช้ในการกำหนดเส้นทางระหว่างโดเมน การขาดระบบที่ได้รับการยอมรับอย่างกว้างขวางซึ่งมีความปลอดภัยในระดับ AES และความน่าเชื่อถือที่ปรับขนาดได้ ทำให้การถ่ายทอดสดสื่อมวลชน เช่น การแข่งขันกีฬา (เช่น ซูเปอร์โบวล์) และ/หรือข่าวสารด่วน ไม่สามารถส่งผ่านทางอินเทอร์เน็ตสาธารณะได้

โปรโตคอล IP Multicasting ที่เชื่อถือได้ เช่น PGM และ SMART ยังอยู่ในขั้นตอนการทดลอง โปรโตคอลเดียวที่อยู่ในขั้นตอนการกำหนดมาตรฐานคือ NORM (การแก้ไขมาตรฐานของ RFC 3941 ระบุไว้ใน RFC 5401 และการแก้ไขมาตรฐานของ RFC 3940 ระบุไว้ใน RFC 5740)

เนื่องจากมัลติแคสต์เป็นโหมดการส่งข้อมูลที่แตกต่างจากยูนิแคสต์ ดังนั้นจึงควรใช้เฉพาะโปรโตคอลที่ออกแบบมาสำหรับมัลติแคสต์เท่านั้น โปรโตคอลแอปพลิเคชันที่มีอยู่ส่วนใหญ่ที่ใช้มัลติแคสต์นั้นทำงานอยู่บนโปรโตคอลUser Datagram Protocol (UDP)

ในหลายแอปพลิเคชัน โปรโตคอลการขนส่งแบบเรียลไทม์ (RTP) ถูกใช้สำหรับการจัดเฟรมเนื้อหามัลติมีเดียผ่านมัลติแคสต์โปรโตคอลการจองทรัพยากร (RSVP) อาจถูกใช้สำหรับการจองแบนด์วิดท์ในเครือข่ายที่รองรับการกระจายแบบมัลติแคสต์มัลติแคสต์ DNS (mDNS) สามารถใช้เพื่อแปลงชื่อโดเมนหรือชื่อโฮสต์โดยไม่ต้องใช้เซิร์ฟเวอร์ DNS เฉพาะโดยใช้มัลติแคสต์

IP multicast ถูกใช้งานอย่างแพร่หลายในองค์กรตลาดหลักทรัพย์ เชิง พาณิชย์^{[ 10 ]}และเครือข่ายการส่งมอบเนื้อหามัลติมีเดีย การใช้งาน IP multicast ทั่วไปในองค์กรคือ แอปพลิเคชัน IPTVเช่น การกระจายสัญญาณโทรทัศน์สดและการประชุมบริษัทที่ถ่ายทอดทางโทรทัศน์

ในอุตสาหกรรมการบริการ การส่งสัญญาณแบบ IP multicast กลายเป็นเรื่องปกติสำหรับ การกระจายสัญญาณ IPTVในโรงแรม และในภาคค้าปลีก ปัจจุบัน IP multicast ถูกนำมาใช้กันอย่างแพร่หลายสำหรับการกระจายสัญญาณโทรทัศน์และแอปพลิเคชันโฆษณาวิดีโอ

ผู้ให้บริการทีวีแบบเสียค่าบริการและสถาบันการศึกษาบางแห่งที่มีหอพักนักศึกษาจำนวนมากในวิทยาเขต ได้นำเทคโนโลยี IP multicast มาใช้เพื่อส่งสื่อสตรีมมิ่ง แบบทางเดียว เช่น วิดีโอความเร็วสูง ไปยังกลุ่มผู้รับจำนวนมาก นอกจากนี้ ยังมีการใช้งานการประชุมทางเสียงและวิดีโอโดยใช้เทคโนโลยี multicast บ้างแล้ว แต่การใช้งานเหล่านี้ยังไม่แพร่หลายมากนัก และส่วนใหญ่จะอยู่ในสถาบันวิจัยและการศึกษา ซึ่งมักมีศักยภาพด้านเครือข่ายสูงกว่าในการรองรับความต้องการ การประชุมทางเทคนิคบางงานก็มีการถ่ายทอดผ่าน IP multicast จนกระทั่งเมื่อไม่นานมานี้ การประชุมหลายๆ ครั้งในงาน IETF ก็ใช้ multicast ในการถ่ายทอดเช่นกัน

อีกหนึ่งการใช้งานของมัลติแคสต์ภายในเครือข่ายมหาวิทยาลัยและเครือข่ายเชิงพาณิชย์คือการแจกจ่ายไฟล์ โดยเฉพาะอย่างยิ่งการส่งอิมเมจระบบปฏิบัติการและการอัปเดตไปยังโฮสต์ระยะไกล ข้อได้เปรียบที่สำคัญของอิมเมจบูตแบบมัลติแคสต์เมื่อเทียบกับอิมเมจบูตแบบยูนิแคสต์คือการใช้แบนด์วิดท์เครือข่ายที่ต่ำกว่าอย่างมาก

IP multicast ยังได้รับการนำไปใช้งานในภาคการเงินสำหรับแอปพลิเคชันต่างๆ เช่นระบบแสดงราคาหุ้นและระบบส่งเสียงโหวกเหวก^{[ 11 ]}

ข้อจำกัด ด้านพื้นที่ จัดเก็บข้อมูล ขนาดใหญ่ในเราเตอร์ ทำให้แอปพลิเคชันที่ใช้โครงสร้างข้อมูลแบบต้นไม้จำนวนมากไม่สามารถทำงานได้ขณะใช้ IP มัลติแคสต์ ยก ตัวอย่างเช่น ข้อมูลสถานะการใช้งานที่แต่ละคนจำเป็นต้องเก็บข้อมูลต้นไม้ของผู้ติดตามอย่างน้อยหนึ่งต้น หรืออาจหลายต้น ยังไม่มีกลไกใดที่แสดงให้เห็นแล้วว่าจะช่วยให้โมเดล IP มัลติแคสต์สามารถรองรับผู้ส่งหลายล้านรายและกลุ่มมัลติแคสต์หลายล้านกลุ่มได้ ดังนั้นจึงยังไม่สามารถทำให้แอปพลิเคชันมัลติแคสต์ทั่วไปใช้งานได้อย่างเต็มรูปแบบในขณะนี้

RFC 3170 ( แอปพลิเคชัน IP Multicast: ความท้าทายและแนวทางแก้ไข ) ให้ภาพรวมของปัญหาในการใช้งาน

IP multicasting ได้รับการพัฒนาครั้งแรกโดยSteve Deeringขณะอยู่ที่มหาวิทยาลัยสแตนฟอร์ด ซึ่งเขาได้รับรางวัล IEEE Internet Award ^{[ 12 ]}

MBONE เป็นแนวทางการทดลองระยะยาวในการเปิดใช้งานการส่งข้อมูลแบบมัลติแคสต์ระหว่างไซต์ต่างๆ โดยใช้ท่อส่งข้อมูล แม้ว่า MBONE จะไม่สามารถใช้งานได้อีกต่อไปแล้ว แต่ก็มีความสนใจใหม่ในการส่งข้อมูลแบบมัลติแคสต์ผ่านท่อส่งข้อมูลอีกครั้ง เพื่อให้บริการนี้สามารถใช้งานได้กับผู้ใช้ปลายทางที่หลากหลายมากขึ้น

CastGateเป็นความพยายามของกลุ่มวิจัย ETRO-TELE ที่Vrije Universiteit Brusselในการนำ IP multicast มาใช้บนอินเทอร์เน็ต^{[ 13 ]}

แม้ว่าการส่งแบบมัลติแคสต์จะช่วยให้ผู้ใช้อินเทอร์เน็ตสามารถรับสื่อที่หลากหลายและเนื้อหาอื่นๆ ได้โดยไม่ทำให้เครือข่ายมีภาระมากเกินไป แต่ก็ยังไม่สามารถใช้งานได้สำหรับผู้ใช้อินเทอร์เน็ตส่วนใหญ่ โครงการ CastGate พยายามแก้ไขปัญหานี้โดยอนุญาตให้ผู้ใช้ปลายทางเชื่อมต่อผ่านอุโมงค์ IP ที่กำหนดค่าโดยอัตโนมัติ บนเครือข่ายที่ไม่รองรับ IP มัลติแคสต์โดยธรรมชาติ แนวคิดก็คือ หากผู้ใช้จำนวนมากขึ้นมีความสามารถในการส่งแบบมัลติแคสต์ ผู้ให้บริการเนื้อหาจำนวนมากขึ้นก็จะเห็นประโยชน์ของการสตรีมเนื้อหาผ่านการส่งแบบมัลติแคสต์ ความหวังก็คือ หากผู้ให้บริการเนื้อหาและผู้ใช้จำนวนมากพอใช้บริการนี้ผู้ให้บริการอินเทอร์เน็ต จำนวนมากขึ้น ก็จะเปิดใช้งาน IP มัลติแคสต์ให้กับลูกค้าของตนโดยธรรมชาติ^{[ 13 ]}

CastGate จัดหาซอฟต์แวร์ไคลเอ็นต์สำหรับทั้งMicrosoft WindowsและLinuxเพื่อเชื่อมต่อกับเครือข่ายอุโมงค์ CastGate นอกจากนี้ยังจัดหาเครื่องมือเพื่อเพิ่มเซิร์ฟเวอร์อุโมงค์และเครื่องมือเพื่อรับ การประกาศ Session Announcement Protocolจากเครือข่ายมัลติแคสต์พร้อมสตรีมวิดีโอและเสียง^{[ 14 ]}

โครงการนี้ดูแลเว็บไซต์ตลอดปี 2550 ^{[ 14 ]}

ตั้งแต่ปี 2548 ^{[ 15 ]} BBC เริ่มสนับสนุนให้ ผู้ให้บริการอินเทอร์เน็ตในสหราชอาณาจักรนำบริการที่สามารถระบุที่อยู่แบบมัลติแคสต์มาใช้ในเครือข่ายของตน โดยให้บริการวิทยุ BBC ที่มีคุณภาพสูงกว่า[ ^{16 ] เมื่อ}เทียบกับ บริการที่ระบุที่อยู่ แบบยูนิแคสต์นอกจากนี้ยังได้รับการสนับสนุนจากเครือข่ายวิทยุเชิงพาณิชย์หลายแห่ง รวมถึงBBC , GCap Media , EMAPและVirgin Radio ^{[ 17 ]}

สถานีโทรทัศน์สาธารณะของเยอรมนีARD ^{[ 18 ]}และZDFและเครือข่ายฝรั่งเศส-เยอรมันArteนำเสนอรายการโทรทัศน์แบบมัลติแคสต์บนเครือข่ายหลายแห่งผู้ให้บริการอินเทอร์เน็ตของออสเตรียTelekom Austriaเสนอกล่องรับสัญญาณโทรทัศน์ที่ใช้การกำหนดแอดเดรสแบบมัลติแคสต์เพื่อรับชมรายการโทรทัศน์และวิทยุแก่ลูกค้าสายสมาชิกดิจิทัล (DSL) ใน เยอรมนี T-Home ซึ่งเป็นแบรนด์ของDeutsche Telekomก็ให้บริการที่คล้ายกัน

• คลังเครื่องมือสื่อ (Media Tools Repository) ,สหราชอาณาจักร : UCL, เก็บถาวรจากต้นฉบับเมื่อวันที่ 8 มกราคม 2550– ชุดเครื่องมือสำหรับMBone
• VideoLAN – แอปพลิเคชันสตรีมมิ่งวิดีโอแบบมัลติแคสต์ฟรี
• Xorp , เก็บถาวรจากต้นฉบับเมื่อวันที่ 13 พฤษภาคม 2011 , เรียกดูเมื่อวันที่ 5 กันยายน 2012– เราเตอร์ ซอฟต์แวร์ฟรีที่รองรับมัลติแคสต์ (IGMP, PIM)
• สเคิร์ต– เครื่องมืออย่างง่ายสำหรับจัดการเส้นทางมัลติแคสต์ในเคอร์เนลลินุกซ์
• SSM-ping , NO : Venås, เก็บถาวรจากต้นฉบับเมื่อ 2007-11-26– เครื่องมือสำหรับทดสอบการเชื่อมต่อแบบมัลติแคสต์
• Wilbert, IGMP v3 , Kloosterhof, เก็บถาวรจากต้นฉบับเมื่อ 2007-08-26– การใช้งาน IGMPv3 บนระบบโฮสต์ของ FreeBSD
• Java Reliable Multicast Service , สืบค้นเมื่อ 2012-09-08{{citation}}: CS1 maint: บริการเก็บถาวรที่เลิกใช้แล้ว ( ลิงก์ )- ไลบรารีและบริการสำหรับการสร้างแอปพลิเคชันที่รองรับการส่งข้อมูลแบบมัลติแคสต์
• การนำระบบ PIM มาใช้ มหาวิทยาลัย USC เก็บถาวรจากต้นฉบับเมื่อวันที่ 24 ธันวาคม 2550– การนำโปรโตคอล PIM มาใช้ ซึ่งปัจจุบันล้าสมัยแล้ว
• qpimd – โปรแกรมจัดการข้อมูล PIM สำหรับ Quagga , GNU— โมดูลPIM สำหรับชุด โปรแกรม Quagga Routing Suite
• GateD , Next hop, เก็บถาวรจากต้นฉบับเมื่อ 2007-09-09– การใช้งานโปรโตคอลการกำหนดเส้นทางในระบบ Unix รวมถึงมัลติแคสต์
• รหัส PIM-DM สำหรับ GateDมหาวิทยาลัยโอเรกอน เก็บถาวรจากต้นฉบับเมื่อวันที่ 15 ตุลาคม 2550.
• NORM , NRL, เก็บถาวรจากต้นฉบับเมื่อ 2008-10-07เรียกดูเมื่อ 2008-03-26– ระบบมัลติแคสต์ที่เชื่อถือได้โดยมุ่งเน้นที่ Nack จากห้องปฏิบัติการวิจัยกองทัพเรือสหรัฐฯ พร้อมการใช้งานแบบโอเพนซอร์สด้วยภาษา C++
• ecmh (Easy Cast du Multi Hub) , ถอดออก– โปรแกรมจัดการมัลติแคสต์ IPv6 ช่วยให้สามารถใช้งานมัลติแคสต์ IPv6 ได้โดยไม่ต้องใช้ PIM
• MRD6 – โปรแกรมจัดการเส้นทางมัลติแคสต์ IPv6
• UFTP – FTP ที่เข้ารหัสแบบ UDP พร้อมการส่งแบบมัลติแคสต์
• GStreamer – เฟรมเวิร์กมัลติมีเดียซอฟต์แวร์ฟรี ที่รองรับการสตรีมวิดีโอแบบมัลติแคสต์
• Mcproxy (Multicast Proxy)– พร็อกซี IGMP / MLDที่รองรับส่วนขยายมัลติแคสต์PMIPv6

• โครงสร้างต้นไม้แบบแกนหลัก : ข้อเสนอสำหรับความสามารถในการปรับขนาดของ IP multicast

• Multicast over TCP/IP (Howto), โครงการเอกสารของ Linux, มีนาคม 1998อธิบายเรื่อง Multicast ในเคอร์เนลของ Linux แม้ว่าบางส่วน (โดยเฉพาะโปรแกรม Multicast) จะล้าสมัยและไม่ครอบคลุมซอฟต์แวร์รุ่นใหม่ก็ตาม
• Reliable Multicast Transport (rmt) (working group), IETF, เก็บถาวรจากต้นฉบับเมื่อ 2007-12-03.
• กลุ่มสมาชิก Multicast & Anycast (magma) (กลุ่มทำงาน), IETF, เก็บถาวรจากต้นฉบับเมื่อ 14 ธันวาคม 2550.
• Protocol Independent Multicast (PIM) (working group), IETF, เก็บถาวรจากต้นฉบับเมื่อ 2 ธันวาคม 2550.
• กลุ่มทำงาน Source-Specific Multicast (ssm)ของ IETF จัดเก็บจากต้นฉบับเมื่อวันที่ 27 มกราคม 2550.
• ความปลอดภัยของมัลติแคสต์ (MSEC) (กลุ่มทำงาน) IETF เก็บถาวรจากต้นฉบับเมื่อวันที่ 16 ธันวาคม 2550.
• มัลติแคสต์ , ซ็อกเก็ตรายละเอียด IP
• IP-Ethernet multicast (บทช่วยสอน), CX: ไฟร์วอลล์.
• IP Multicast (วิดีโอ), Cisco.
• "ภาพรวมของวิธีการมัลติแคสต์ที่เชื่อถือได้" การประชุมเชิงปฏิบัติการมัลติแคสต์ ACM SIGCOMMมหาวิทยาลัยแมสซาชูเซตส์ 27 สิงหาคม 1996.
• ฟลอยด์, กรอบงานมัลติแคสต์ที่เชื่อถือได้สำหรับเซสชันขนาดเบาและการจัดเฟรมระดับแอปพลิเคชัน , ICIRเอกสารฉบับนี้ให้คำจำกัดความของ Scalable Reliable Multicast (การส่งข้อมูลแบบมัลติแคสต์ที่ปรับขนาดได้และเชื่อถือได้)
• การวิเคราะห์วิธีการมัลติแคสต์ , วิกิดอท , สืบค้นเมื่อ 2019-05-03.
• Noormohammadpour, Mohammad; Raghavendra, Cauligi S.; Rao, Sriram; Kandula, Srikanth (2017), DCCast: การถ่ายโอนข้อมูลแบบจุดต่อหลายจุดอย่างมีประสิทธิภาพข้ามศูนย์ข้อมูล , USENIX Association, arXiv : 1707.02096 , Bibcode : 2017arXiv170702096N , สืบค้นเมื่อ2019-05-03.
• ภาพรวมของสถาปัตยกรรมการกำหนดเส้นทางมัลติแคสต์บนอินเทอร์เน็ต IETFมกราคม 2551doi : 10.17487 / RFC5110 RFC 5110