ერთი 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-ია წამში. ის ვარაუდობს 12 ბაიტიან RTP სათაურს, 8 ბაიტიან UDP სათაურს და ოპციების გარეშე 20 ბაიტიან შიდა IPv4 სათაურს, ასევე SRTP-ის, სათაურის შეკუმშვისა და ტრაფიკის ნაკადის კონფიდენციალურობის შევსების არარსებობას; ნებისმიერი ცვლილება ბიუჯეტსაც ცვლის, ამიტომ ვარაუდები პასუხის გვერდით უნდა იდგეს.
დაამატეთ შიდა სათაურები, შემდეგ ESP გარსი
აპლიკაცია აგზავნის დატვირთვას პლუს RTP პლუს UDP პლუს IP, რაც ამ პაკეტიზაციით 70 ბაიტია. ეს შიდა ნაკადი გამოდის 18.7 kbit/s, უკვე ორჯერ მეტი კოდეკის სიჩქარეზე, რადგან პაკეტის უმეტეს ნაწილს სათაურები ქმნიან და არა აუდიო. არც ერთი ეს ბაიტი ხმა არ არის; ისინი მისამართებისა და რიგითობის ფასია. გვირაბის ზემოთ გაკეთებული ჩაწერა ზუსტად ამ რიცხვს გვიჩვენებს და სწორედ მას ციტირებენ ადამიანები, როცა ამბობენ, რომ ზარი პატარაა.
ეს ის რიცხვიცაა, რომელიც არასოდეს აღწევს მავთულს. ESP გვირაბის რეჟიმი ამატებს 8 ბაიტიან SPI-ს და რიგის ნომერს, 8 ბაიტიან ცხად IV-ს AES-GCM-ისთვის, 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-ის დასაშვებით განსხვავდება, არითმეტიკა სწორია და მხოლოდ საზღვარი დასახელდა არასწორად. ერთი კადრის სათაურზე ბევრად დიდი სხვაობა რგოლზე სხვა რამეზე მიუთითებს, მაგალითად გადაგზავნებზე ან ინტერფეისის გამყოფ სხვა ნაკადზე. ჩაწერეთ პაკეტიზაციის ინტერვალი, დაცვის კრებული და საზღვარი რიცხვის გვერდით, რადგან ამ სამის გარეშე შეფასებას შემდეგი მკითხველი გაზომვად ციტირებს.