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 അനുവാദത്തോളം വ്യത്യാസപ്പെട്ടാൽ, ഗണിതം ശരിയാണ്, അതിർത്തിക്ക് തെറ്റായ പേര് നൽകിയത് മാത്രം. ഒരു ഫ്രെയിം ഹെഡറിനെക്കാൾ വളരെ വലിയ വ്യത്യാസം ലിങ്കിലെ മറ്റൊന്നിലേക്ക് വിരൽ ചൂണ്ടുന്നു, ഉദാഹരണത്തിന് വീണ്ടും അയയ്ക്കലുകൾ അല്ലെങ്കിൽ ഇന്റർഫേസ് പങ്കിടുന്ന മറ്റൊരു പ്രവാഹം. പാക്കറ്റൈസേഷൻ ഇടവേള, സംരക്ഷണ സ്യൂട്ട്, അതിർത്തി എന്നിവ സംഖ്യയ്ക്ക് അരികെ എഴുതുക, കാരണം ഈ മൂന്നും ഇല്ലാത്ത അനുമാനം അടുത്ത വായനക്കാരൻ അളവായി പരാമർശിക്കുന്നു.