นับแพ็กเก็ต G.729 หนึ่งแพ็กเก็ตผ่านอุโมงค์ IPsec
ตัวอย่าง G.729 ที่คำนวณแล้วแสดงให้เห็นว่าเพย์โหลด RTP ESP และการใส่กรอบ Ethernet รวมกันอย่างไร และทำไมการโทรเดียวกันจึงกินแบนด์วิดท์ต่างกันในแต่ละขอบเขต
เสียงผ่าน IPsec มักถูกอ้างเป็นบิตเรตของตัวเข้ารหัส และตัวเลขนั้นผิดในทุกขอบเขตยกเว้นขอบเขตของตัวเข้ารหัสเอง เสียงคือ 8 kbit/s แพ็กเก็ตที่บรรทุกมันมีขนาดใหญ่กว่า เปลือก ESP ใหญ่กว่านั้นอีก และกรอบ Ethernet เพิ่มการใส่กรอบที่การดักจับบนอุโมงค์ไม่เคยแสดง การนับแพ็กเก็ตหนึ่งจากรูปแบบที่ระบุไว้เป็นวิธีเดียวที่จะรู้ว่าลิงก์กายภาพต้องบรรทุกอะไรจริง ๆ การวิเคราะห์ด้านล่างทำเช่นนั้นเพียงทิศทางเดียว และทุกตัวเลขที่นี่คือเลขคณิต ไม่ใช่การวัด
เริ่มจากทางเลือกในการแบ่งแพ็กเก็ต ไม่ใช่จากตัวเลขของตัวเข้ารหัส
ตารางตัวเข้ารหัสให้อัตราเพย์โหลดเท่านั้น: G.729 ให้ 8 kbit/s ซึ่งคือ 30 ไบต์ของเสียงทุก 30 ms ตารางไม่ได้บอกอะไรเกี่ยวกับส่วนหัว การป้องกัน หรือการใส่กรอบ และสามสิ่งนั้นเป็นตัวกำหนดผลลัพธ์ ช่วงเวลาเป็นทางเลือกเชิงนโยบายที่ทั้งสองฝ่ายต้องตกลงกัน ดังนั้นเลือกมันก่อนและระบุไว้ เพราะทุกตัวเลขหลังจากนั้นขึ้นอยู่กับการตัดสินใจครั้งเดียวนั้น
ตัวอย่างนี้ใช้ 30 ms ดังนั้นอัตราแพ็กเก็ตคือ 33.3 ต่อวินาที สมมติว่ามีส่วนหัว RTP 12 ไบต์ ส่วนหัว UDP 8 ไบต์ และส่วนหัว IPv4 ภายใน 20 ไบต์โดยไม่มีตัวเลือก และไม่มี SRTP การบีบอัดส่วนหัว หรือการเติมเพื่อความลับของกระแสทราฟฟิก การเปลี่ยนแปลงใด ๆ ก็เลื่อนงบประมาณไปด้วย จึงต้องวางสมมติฐานไว้ข้างคำตอบ
เพิ่มส่วนหัวภายใน แล้วจึงเพิ่มเปลือก ESP
แอปพลิเคชันส่งเพย์โหลดบวก RTP บวก UDP บวก IP ซึ่งในการแบ่งแพ็กเก็ตนี้คือ 70 ไบต์ กระแสภายในนั้นออกมาเป็น 18.7 kbit/s มากกว่าสองเท่าของอัตราตัวเข้ารหัสแล้ว เพราะส่วนหัวไม่ใช่เสียงเป็นสัดส่วนใหญ่ของแพ็กเก็ต ไม่มีไบต์ใดเป็นเสียงเลย มันคือราคาของการกำหนดที่อยู่และการจัดลำดับ การดักจับที่ทำเหนืออุโมงค์แสดงตัวเลขนี้พอดี และเป็นตัวเลขที่ผู้คนอ้างถึงเมื่อบอกว่าการโทรมีขนาดเล็ก
มันยังเป็นตัวเลขที่ไม่เคยไปถึงสายไฟ โหมดอุโมงค์ ESP เพิ่ม SPI และหมายเลขลำดับ 8 ไบต์ IV แบบชัดแจ้ง 8 ไบต์สำหรับ AES-GCM ส่วนท้าย 2 ไบต์ และแท็กการพิสูจน์ตัวตน 16 ไบต์ เพย์โหลด 70 ไบต์บวกส่วนท้ายตกที่ 72 ซึ่งสอดคล้องการจัดแนวสี่ไบต์อยู่แล้ว จึงไม่ต้องเติมเพิ่มเติมตรงนี้RFC 4106 กำหนดขนาดของ IV และแท็กของ GCM และทั้งสองอยู่ในเลขคณิต ไม่ใช่ในเชิงอรรถ:
30 payload, G.729 at 30 ms
12 RTP
8 UDP
20 inner IPv4
--
70 inner IP packet
8 ESP SPI and sequence
8 explicit IV
2 pad length and next header
16 authentication tag
--
104 ESP packetเพิ่มส่วนหัวภายนอกที่การผ่าน NAT ต้องการ
นอกเปลือก ESP มีส่วนหัว IPv4 ภายนอก 20 ไบต์และส่วนหัว UDP 8 ไบต์สำหรับการผ่าน NAT ดังนั้นแพ็กเก็ตกลายเป็น 132 ไบต์ การห่อหุ้ม UDP มีอยู่เพราะแพ็กเก็ตต้องผ่านอุปกรณ์แปลที่อยู่ระหว่างคู่สนทนา และมันเปลี่ยนรูปร่างภายนอกโดยไม่แตะเพย์โหลดที่ป้องกันไว้ ที่ 33.3 แพ็กเก็ตต่อวินาที 132 ไบต์คือประมาณ 35.2 kbit/s หรือราวสี่เท่าของอัตราระบุของตัวเข้ารหัส
ทั้งแท็กและ IV ไม่สามารถตัดออกจากการประมาณเพื่อทำให้เล็กลงได้ เพราะทั้งสองเป็นส่วนหนึ่งของสิ่งที่ลิงก์จะบรรทุกจริง การประมาณที่ละเว้นมันอธิบายแพ็กเก็ตที่ผู้รับจะปฏิเสธ เช่นเดียวกันกับส่วนท้าย ซึ่งมีอยู่เพื่อทำเครื่องหมายขอบเขตของเพย์โหลดและส่วนหัวถัดไปภายในพื้นที่ที่ป้องกัน
ตั้งชื่อขอบเขตก่อนอ้างตัวเลข
ตัวเลข IP ภายนอกยังคงไม่รวมการใส่กรอบ Ethernet ลิงก์การเข้าถึงที่มีแท็กหรือไม่มีแท็กเพิ่มส่วนหัว MAC 14 ไบต์และลำดับตรวจสอบกรอบ 4 ไบต์ ทำให้กรอบเป็น 150 ไบต์ ซึ่งเป็นขนาดที่พอร์ตสวิตช์นับ ที่อัตราแพ็กเก็ตเดียวกันนั่นคือ 40 kbit/s ห้าเท่าของอัตราตัวเข้ารหัส และความต่างไม่ใช่ความสูญเปล่าแต่เป็นต้นทุนของการขนส่ง
| Boundary | Packet size | Rate at 33.3 packets/s | What it counts |
|---|---|---|---|
| Codec payload | 30 bytes | 8.0 kbit/s | The audio alone |
| Inner IP packet | 70 bytes | 18.7 kbit/s | Application headers included |
| Outer IP packet | 132 bytes | 35.2 kbit/s | ESP and NAT-T included |
| Ethernet frame | 150 bytes | 40.0 kbit/s | Link framing included |
ตัวเลข 40 kbit/s ยังคงไม่รวมคำนำ ช่องว่างระหว่างกรอบ แท็ก VLAN การห่อหุ้มของผู้ให้บริการ RTCP การส่งสัญญาณ และเสียงที่เดินทางไปอีกทาง มันเป็นการประมาณต่อทิศทาง ไม่ใช่การจองลิงก์ และการอ้างเป็นเช่นนั้นจะเกินจริงในสิ่งที่ลิงก์ต้องจองในที่หนึ่งขณะที่ประเมินต่ำในอีกที่หนึ่ง การดักจับบนโฮสต์อาจพลาดการใส่กรอบที่ลิงก์เพิ่มด้วย ดังนั้น จึงต้องตั้งชื่อขอบเขตข้างตัวเลข และนั่นคือเหตุผลที่ตารางขอบเขตมีประโยชน์กว่าตัวเลขพาดหัวเดียว จองแยกสำหรับทิศทางที่คุณไม่ได้นับ
ตรวจสอบเลขคณิตกับอินเทอร์เฟซ
ก่อนจะเชื่อการประมาณ ให้เทียบกับสิ่งที่อินเทอร์เฟซรายงานสำหรับจำนวนแพ็กเก็ตที่รู้แน่ ดักจับบนอินเทอร์เฟซกายภาพไม่ใช่อุปกรณ์อุโมงค์ เพื่อให้การใส่กรอบที่คุณพยายามคิดรวมอยู่ด้วย และคาดหวังความคลาดเคลื่อนเล็กน้อยไม่ใช่ความตรงกันสมบูรณ์
sudo tcpdump -ni eth0 -c 50 'udp port 4500'
ip -s link show eth0การดักจับยืนยันขนาดแพ็กเก็ตภายนอก ขณะที่ตัวนับอินเทอร์เฟซแสดงอัตรารวมการใส่กรอบ ถ้าทั้งสองต่างกันประมาณส่วนเผื่อ Ethernet เลขคณิตก็ถูกและมีเพียงขอบเขตที่ตั้งชื่อผิด ความต่างที่ใหญ่กว่าส่วนหัวกรอบหนึ่งส่วนหัวมากชี้ไปที่อย่างอื่นบนลิงก์ เช่น การส่งซ้ำหรือกระแสอื่นที่ใช้ร่วมอินเทอร์เฟซ เขียนช่วงการแบ่งแพ็กเก็ต ชุดการป้องกัน และขอบเขตไว้ข้างตัวเลข เพราะการประมาณที่ไม่มีสามสิ่งนั้นจะถูกอ้างเป็นการวัดโดยผู้อ่านคนถัดไป