გადაცემის მაქსიმალური ერთეული (MTU)
კომპიუტერულ ქსელში, ტერმინი Maximum Transmission Unit (MTU) აღნიშნავს უმსხვილესი PDU- ს ზომას (ბაიტებში), რომელიც საკომუნიკაციო პროტოკოლის მოცემულ ფენას შეუძლია გაიაროს შემდგომ. MTU პარამეტრები ჩვეულებრივ ჩნდება საკომუნიკაციო ინტერფეისთან (NIC, სერიული პორტი და სხვა). MTU შეიძლება დაფიქსირდეს სტანდარტებით (როგორც ეს ხდება Ethernet– ის შემთხვევაში) ან გადაწყდეს კავშირის დროს (როგორც წესი ხდება წერტილოვანი სერიული ბმულების შემთხვევაში). უფრო მაღალი MTU მოაქვს უფრო მეტ ეფექტურობას, რადგან თითოეული პაკეტი ატარებს მეტ მომხმარებლის მონაცემებს, ხოლო პროტოკოლის ხარჯები, როგორიცაა სათაურები ან თითოეული პაკეტის შეფერხება რჩება ფიქსირებული, ხოლო უფრო მაღალი ეფექტურობა ნიშნავს მცირე პროტოკოლის გამტარუნარიანობის უმნიშვნელო გაუმჯობესებას. თუმცა, დიდ პაკეტებს შეუძლიათ გარკვეული დროით დაიკავონ ნელი ბმული, რაც იწვევს პაკეტების შემდგომ უფრო დიდ შეფერხებებს და გაზრდის ჩამორჩენას და მინიმალურ დაგვიანებას. მაგალითად, 1500 ბაიტიანი პაკეტი, ყველაზე დიდი დაშვებული Ethernet– ის მიერ ქსელის ფენაში (და შესაბამისად ინტერნეტის უმეტესი ნაწილი), დააკავშირებს 14.4k მოდემს დაახლოებით ერთი წამით.
გზა MTU აღმოჩენა
ინტერნეტ პროტოკოლი განსაზღვრავს ინტერნეტის გადაცემის ბილიკის "გზას MTU", როგორც ყველაზე მცირე MTU წყაროს და დანიშნულების ადგილს შორის არსებული "ბილიკის" IP IP- დან. სხვა სიტყვებით რომ ვთქვათ, გზა MTU არის ყველაზე დიდი პაკეტის ზომა, რომელიც გადის ამ გზაზე, დანაწევრების გარეშე.
RFC 1191 აღწერს ”გზას MTU აღმოჩენას”, ტექნიკას, რომელიც განსაზღვრავს MTU ბილიკს ორ IP მასპინძელს შორის. იგი მუშაობს DF (ნუ ფრაგმენტირებული) პარამეტრის დაყენებით გამავალი პაკეტების IP სათაურებში. გზის გასწვრივ ნებისმიერი მოწყობილობა, რომლის MTU უფრო მცირეა პაკეტზე, ჩამოაგდებს ასეთ პაკეტებს და გამოაგზავნის ICMP შეტყობინებას "Destination Unreachable (Datagram Too Big)", რომელიც შეიცავს MTU- ს, რაც საშუალებას მისცემს წყაროს მასპინძელს სათანადოდ შეამციროს სავარაუდო გზა MTU. პროცესი მეორდება მანამ, სანამ MTU არ იქნება საკმარისად პატარა, რათა გაიაროს მთელი გზა ფრაგმენტაციის გარეშე.
სამწუხაროდ, ქსელების რაოდენობის ზრდა აქვეითებს ICMP ტრაფიკს (მაგ. სერვისზე უარის თქმის შეტევების თავიდან ასაცილებლად), რაც ხელს უშლის MTU აღმოჩენის მუშაობას. ხშირად გამოვლენილია ასეთი დაბლოკვა იმ შემთხვევებში, როდესაც კავშირი მუშაობს დაბალი მოცულობის მონაცემებზე, მაგრამ გათიშულია როგორც კი მასპინძელი გაგზავნის მონაცემთა დიდ ბლოკს ერთდროულად. მაგალითად, IRC– სთან დაკავშირების კლიენტმა შეიძლება დაინახოს პინგის შეტყობინება, მაგრამ ამის შემდეგ პასუხი არ მიიღოს. ეს იმიტომ ხდება, რომ მისასალმებელი შეტყობინებების დიდი ნაკრები იგზავნება პაკეტებში უფრო დიდი ვიდრე რეალური MTU. ასევე, IP ქსელში, წყარო წყაროს მისამართიდან დანიშნულების მისამართამდე ხშირად იცვლება დინამიურად, სხვადასხვა მოვლენის საპასუხოდ (დატვირთვის დაბალანსება, შეშუპება, შედეგები და ა.შ.)-ამან შეიძლება გამოიწვიოს MTU ბილიკის შეცვლა (ზოგჯერ განმეორებითი) გადაცემის დროს, რამაც შეიძლება გამოიწვიოს პაკეტის შემდგომი წვეთები, სანამ მასპინძელი აღმოაჩენს ახალ უსაფრთხო MTU- ს.
Ethernet LAN– ების უმეტესობა იყენებს MTU– ს 1500 ბაიტს (თანამედროვე LAN– ებს შეუძლიათ გამოიყენონ Jumbo ჩარჩოები, რაც იძლევა MTU– ს 9000 ბაიტამდე), თუმცა სასაზღვრო პროტოკოლები, როგორიცაა PPPoE, შეამცირებს ამას. ეს იწვევს გზას MTU აღმოჩენის ძალაში შესაძლო შედეგის გამო, რომ ზოგიერთი საიტი ცუდად კონფიგურირებული ბუხრის უკან მიუწვდომელია. შეიძლება ვინმემ იმუშაოს ამაზე, იმისდა მიხედვით, თუ რომელი ქსელის ნაწილს აკონტროლებს; მაგალითად, შეგიძლიათ შეცვალოთ MSS (სეგმენტის მაქსიმალური ზომა) საწყის პაკეტში, რომელიც ადგენს TCP კავშირს ბუხართან.
ეს პრობლემა უფრო ხშირად ჩნდება Windows Vista– ს დანერგვის შემდეგ, რომელიც წარმოგიდგენთ „შემდეგი თაობის TCP/IP სტეკს“. ეს ახორციელებს „მიიღეთ ფანჯრის ავტომატური რეგულირება, რომელიც მუდმივად განსაზღვრავს ფანჯრის მიღების ოპტიმალურ ზომას გამტარუნარიანობის შეფერხების პროდუქტისა და აპლიკაციის მიღების სიჩქარის გაზომვით და არეგულირებს მიღების მაქსიმალური ფანჯრის ზომას ქსელის პირობების შეცვლის საფუძველზე.“ [2] აღმოჩნდა, რომ ეს ვერ მოხერხდა ძველ მარშრუტიზატორებთან და ბუხრებთან ერთად, რომლებიც სხვა ოპერაციულ სისტემებთან მუშაობდნენ. ის ყველაზე ხშირად ჩანს ADSL მარშრუტიზატორებში და მისი გამოსწორება ხშირად შესაძლებელია firmware- ის განახლებით.
ბანკომატის ხერხემალი, MTU რეგულირების მაგალითი
ზოგჯერ მიზანშეწონილია ეფექტურობის თვალსაზრისით ხელოვნურად გამოცხადდეს შემცირებული MTU პროგრამულ უზრუნველყოფაში ჭეშმარიტი მაქსიმალური დასაშვები სიგრძის ქვემოთ. ამის მაგალითია შემთხვევა, როდესაც IP ტრაფიკი გადადის ბანკომატების (ასინქრონული გადაცემის რეჟიმი) ქსელში. ზოგიერთი პროვაიდერი, განსაკუთრებით სატელეფონო კავშირის მქონე პირები, იყენებენ ბანკომატებს თავიანთ შიდა ხერხემალურ ქსელში.
ოპტიმალური ეფექტურობისას ბანკომატის გამოყენება მიიღწევა მაშინ, როდესაც პაკეტის სიგრძე 48 ბაიტის ჯერადია. ეს იმიტომ ხდება, რომ ბანკომატი იგზავნება როგორც ფიქსირებული სიგრძის პაკეტების ნაკადი (ცნობილია როგორც "უჯრედები"), რომელთაგან თითოეულს შეუძლია დატვირთოს მომხმარებლის მონაცემების 48 ბაიტი და 5 ბაიტი ოვერჰედის ჯამში, თითო უჯრედზე 53 ბაიტი. ამრიგად, გადაცემული მონაცემთა სიგრძის მთლიანი სიგრძეა 53 * n უჯრედის ბაიტი, სადაც ncells = საჭირო უჯრედების რაოდენობა = INT ((დატვირთვა_ სიგრძე+47)/48). ასე რომ, უარეს შემთხვევაში, სადაც მთლიანი სიგრძე = (48*n+1) ბაიტი, ერთი დამატებითი უჯრედი არის საჭირო დატვირთვის ერთი ბოლო ბაიტის გადასაცემად, საბოლოო უჯრედი ეღირება დამატებით 53 გადაცემული ბაიტი, რომელთაგან 47 შევსებულია. ამ მიზეზით, პროგრამულად შემცირებული MTU– ს ხელოვნურად გამოცხადება მაქსიმალურად გაზრდის პროტოკოლის ეფექტურობას ბანკომატების ფენაში, რაც შესაძლებელს გახდის ბანკომატის AAL5 მთლიანი დატვირთვის სიგრძის 48 ბაიტის გამრავლებას.
მაგალითად, 31 მთლიანად შევსებული ბანკომატის უჯრედი ატარებს დატვირთვას 31*48 = 1488 ბაიტი. ვიღებთ 1488 -ის ამ მაჩვენებელს და გამოვაკლებთ მის ხარჯებს ყველა შესაბამისი უმაღლესი პროტოკოლით, ჩვენ შეგვიძლია მივიღოთ შემოთავაზებული მნიშვნელობა ხელოვნურად შემცირებული ოპტიმალური MTU– სთვის. იმ შემთხვევაში, როდესაც მომხმარებელი ჩვეულებრივ აგზავნის 1500 ბაიტიან პაკეტს, 1489 - დან 1536 ბაიტს შორის გაგზავნა მოითხოვს დამატებით ფიქსირებულ ღირებულებას გადაცემული 53 ბაიტის სახით, ერთი დამატებითი ბანკომატის უჯრედის სახით.
მაგალითად, IP– ზე DSL კავშირების გამოყენებით PPPoA/VC-MUX, კვლავ ირჩევთ 31 ბანკომატის უჯრედების შევსებას, როგორც ადრე, ჩვენ ვიღებთ სასურველ ოპტიმალურად შემცირებულ MTU ფიგურას 1478 = 31*48-10, 10 ბაიტის ოვერჰედის გათვალისწინებით. Point-to-Point პროტოკოლის ოვერჰედის 2 ბაიტი და AAL5 ზედნადები 8 ბაიტი. ეს იძლევა ჯამურ ღირებულებას 31*53 = 1643 ბაიტი გადაცემული ბანკომატით 1478 ბაიტიანი პაკეტიდან გადატანილი PPPoA. იმ შემთხვევაში, თუ IP გაგზავნილია ADSL– ით PPPoA– ს გამოყენებით, 1478 ციფრი იქნება IP პაკეტის მთლიანი სიგრძე IP სათაურების ჩათვლით. ამ მაგალითში 1478 წლის თვითდასაქმებული შემცირებული MTU– ს დაცვა, განსხვავებით 1500 პაკეტის IP პაკეტების გაგზავნისგან, ზოგავს 53 ბაიტს თითო პაკეტზე ბანკომატის ფენაზე, IP პაკეტების სიგრძის 22 ბაიტი შემცირებით.
მაქსიმალური MTU PPPoE/DSL კავშირებისთვის არის 1492, RFC 2516: 6 ბაიტი არის PPPoE სათაური, ტოვებს საკმარის ადგილს 1488 ბაიტიანი დატვირთვისთვის, ან 31 სრული ბანკომატის უჯრედისთვის.
და ბოლოს: MTU– ს სტანდარტული მნიშვნელობა უნდა იყოს 1492 .... ხოლო დათვალიერების პრობლემების ან MSN კავშირის პრობლემების შემთხვევაში ის უნდა შემცირდეს 1422 და 1420 მნიშვნელობამდე.
ცნობისთვის: Wikipedia
საუკეთესო სურვილებით
გამარჯობა, გმადლობთ სასარგებლო სტატიისთვის