IPsec सुरंग से एक G.729 पैकेट की गिनती
एक हल किया गया G.729 उदाहरण दिखाता है कि पेलोड, RTP, ESP और Ethernet फ़्रेमिंग कैसे जुड़ते हैं, और वही कॉल हर सीमा पर अलग बैंडविड्थ क्यों लेती है।
IPsec पर आवाज़ को कोडेक बिटरेट के रूप में बताया जाता है, और वह आंकड़ा कोडेक की अपनी सीमा को छोड़कर हर सीमा पर गलत है। ऑडियो 8 kbit/s है, उसे ढोने वाला पैकेट बड़ा है, ESP लपेट और भी बड़ा है, और Ethernet फ़्रेम ऐसी फ़्रेमिंग जोड़ता है जो सुरंग पर लिए गए किसी कैप्चर में कभी नहीं दिखती। किसी बताए गए प्रारूप से एक पैकेट गिनना ही यह जानने का एकमात्र तरीका है कि भौतिक लिंक को वास्तव में क्या ढोना है। नीचे की चर्चा यह केवल एक दिशा के लिए करती है, और यहां हर आंकड़ा अंकगणित है, माप नहीं।
कोडेक के आंकड़े से नहीं, पैकेटाइज़ेशन के चयन से शुरू करें
एक कोडेक तालिका पेलोड दर देती है और कुछ नहीं: G.729 8 kbit/s देता है, जो हर 30 ms पर 30 बाइट ऑडियो है। यह हेडर, सुरक्षा या फ़्रेमिंग के बारे में कुछ नहीं कहती, और परिणाम पर यही तीन हावी होते हैं। अंतराल एक नीति-निर्णय है जिस पर दोनों सिरों को सहमत होना है, इसलिए इसे पहले चुनें और घोषित करें, क्योंकि हर बाद का आंकड़ा उसी एक निर्णय पर टिका है।
यह उदाहरण 30 ms का उपयोग करता है, इसलिए पैकेट दर 33.3 प्रति सेकंड है। यह 12 बाइट का RTP हेडर, 8 बाइट का UDP हेडर और विकल्पों के बिना 20 बाइट का भीतरी IPv4 हेडर मानता है, और कोई SRTP, हेडर संपीड़न या ट्रैफ़िक-प्रवाह-गोपनीयता पैडिंग नहीं; कोई भी बदलाव बजट को भी खिसका देता है, इसलिए मान्यताएं उत्तर के साथ ही रखी जानी चाहिए।
भीतरी हेडर जोड़ें, फिर ESP लपेट
अनुप्रयोग पेलोड सहित RTP सहित UDP सहित IP भेजता है, जो इस पैकेटाइज़ेशन पर 70 बाइट है। वह भीतरी प्रवाह 18.7 kbit/s बैठता है, जो कोडेक दर से पहले ही दोगुने से अधिक है, क्योंकि पैकेट का अधिकांश हिस्सा ऑडियो नहीं, हेडर बनाते हैं। उन बाइटों में से कोई भी आवाज़ नहीं है; वे पता देने और क्रम देने की कीमत हैं। सुरंग के ऊपर लिया गया कैप्चर ठीक यही आंकड़ा दिखाता है, और लोग यही आंकड़ा तब उद्धृत करते हैं जब कहते हैं कि कॉल छोटी है।
यह वह आंकड़ा भी है जो कभी तार तक नहीं पहुंचता। ESP सुरंग मोड 8 बाइट का SPI और क्रम संख्या, AES-GCM के लिए 8 बाइट का स्पष्ट IV, 2 बाइट का ट्रेलर और 16 बाइट की प्रमाणीकरण टैग जोड़ता है। 70 बाइट का पेलोड सहित ट्रेलर 72 पर पहुंचता है, जो चार बाइट के संरेखण को पहले ही पूरा करता है, इसलिए यहां अतिरिक्त पैडिंग की ज़रूरत नहीं है।RFC 4106 GCM के IV और टैग के आकार तय करता है, और दोनों अंकगणित में हैं, पाद-टिप्पणी में नहीं:
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 लपेट के बाहर 20 बाइट का बाहरी IPv4 हेडर और NAT पार करने के लिए 8 बाइट का UDP हेडर है, इसलिए पैकेट 132 बाइट हो जाता है। UDP एनकैप्सुलेशन इसलिए है क्योंकि पैकेट को सहभागियों के बीच के अनुवादक उपकरण से बचना होता है, और यह संरक्षित पेलोड को छुए बिना बाहरी आकार बदल देता है। प्रति सेकंड 33.3 पैकेट पर, 132 बाइट लगभग 35.2 kbit/s है, यानी कोडेक की नाममात्र दर की लगभग चार गुनी।
न टैग और न IV को छोटा करने के लिए अनुमान से हटाया जा सकता है, क्योंकि दोनों उसी का हिस्सा हैं जो लिंक वास्तव में ढोएगा। जो अनुमान इन्हें छोड़ देता है, वह ऐसा पैकेट बताता है जिसे प्राप्तकर्ता अस्वीकार कर देता। यही बात ट्रेलर पर भी लागू है, जो संरक्षित क्षेत्र के भीतर पेलोड की सीमा और अगले हेडर को चिह्नित करने के लिए है।
आंकड़ा उद्धृत करने से पहले सीमा का नाम दें
बाहरी IP आंकड़ा अब भी Ethernet फ़्रेमिंग को छोड़ता है। टैग वाला या बिना टैग वाला एक्सेस लिंक 14 बाइट का MAC हेडर और 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 भत्ते के बराबर भिन्न हों, तो अंकगणित सही है और केवल सीमा का नाम गलत रखा गया था। एक फ़्रेम हेडर से कहीं बड़ा अंतर लिंक पर कुछ और ओर संकेत करता है, जैसे पुनःप्रेषण या इंटरफ़ेस साझा करता दूसरा प्रवाह। पैकेटाइज़ेशन अंतराल, सुरक्षा सूट और सीमा को आंकड़े के साथ लिखें, क्योंकि इन तीन के बिना अनुमान को अगला पाठक माप के रूप में उद्धृत करता है।