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 packetNAT पार गर्न आवश्यक बाहिरी हेडरहरू थप्नुहोस्
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 भत्ताइतिको फरक छ भने, अंकगणित ठीक छ र सीमाको नाम मात्र गलत राखिएको थियो। एउटा फ्रेम हेडरभन्दा धेरै ठूलो फरकले लिङ्कमा अरू केहीतिर संकेत गर्छ, जस्तै पुनःप्रेषण वा इन्टरफेस साझा गर्ने अर्को प्रवाह। प्याकेटाइजेसन अन्तराल, सुरक्षा सुट र सीमा संख्याकै छेउमा लेख्नुहोस्, किनकि यी तीन नभएको अनुमानलाई अर्को पाठकले मापनका रूपमा उद्धृत गर्छ।