ორი აღმავალი არხი, მაგრამ ერთი გვირაბი: გადართვა, განაწილება თუ გაერთიანება
მარცხისას გადართვა, ნაკადების მიხედვით განაწილება და ერთი ნაკადის გაერთიანება სამი სხვადასხვა დაპირებაა. ორი ნაგულისხმევი მარშრუტი პირველს გაძლევთ, დანარჩენ ორს კი არა.
ორმა ინტერნეტ ხაზმა შეიძლება VPN უფრო ხელმისაწვდომი გახადოს და ზოგიერთი დატვირთვისთვის უფრო სწრაფიც, მაგრამ მექანიზმი წყვეტს, ამ ორიდან რომელი მოხდება. ორი ნაგულისხმევი მარშრუტის მქონე მარშრუტიზატორი გაერთიანებული არ არის, და ათასობით შიდა კავშირის მატარებელი გვირაბი კვლავ ერთი გარე ნაკადია. დაპირების პირველად დასახელება განსხვავებაა პროექტსა და ძვირ იმედგაცრუებას შორის. ქვემოთ მოცემული ცხრილი ყოფს ვარიანტებს იმის მიხედვით, თუ რა სჭირდება თითოეულს შორეულ ბოლოში და რას უშვებს ბმულის დაკარგვა გადაცემას.
სამი დაპირება, და მხოლოდ ერთს სჭირდება პარტნიორი
მარცხისას გადართვა ინახავს გზას ხელმისაწვდომს, როცა სასურველი ბმული ქრება. ნაკადის ჰეშით განაწილება დამოუკიდებელ ნაკადებს ორივე აღმავალ არხზე აფანტავს. ერთი ნაკადის გაერთიანება ერთ გადაცემას საშუალებას აძლევს ერთდროულად გამოიყენოს ორივე ბმული. ეს სხვადასხვა მოთხოვნის მქონე სხვადასხვა პროდუქტია, და მხოლოდ უკანასკნელს სჭირდება თქვენი მარშრუტიზატორის გარეთ რაღაცის თანამშრომლობა.
| Mechanism | Far-end requirement | Effect on one transfer | What breaks under a link loss |
|---|---|---|---|
| Packet-spraying overlay | A cooperating endpoint that reassembles the stream | Packets can spread across both links | Reordering and buffering on the surviving path; its own recovery logic decides what continues |
| MPTCP subflows | A peer or proxy that accepts subflows | Subflows can share one connection | Surviving subflows continue if the peer keeps them alive |
| Flow-hash balancing | Nothing new; the existing tunnel endpoint is enough | One outer flow still follows one link | Flows hashed onto the dead link move; established sessions break |
| Link failover | Nothing new | One path at a time; the second link sits idle | The session stalls or restarts on the other link |
ამ ცხრილში არაფერია მეორე ხაზის ყიდვის მიზეზი. ის აკეთებს სხვა რამეს: ხელს უშლის გადართვის პროექტის შეფასებას ისე, თითქოს გაერთიანება იყოს.
რატომ ჩანს გვირაბი მარშრუტიზატორისთვის ერთ ნაკადად
დატვირთვის გამანაწილებელი მარშრუტიზატორი ჰეშავს წყაროსა და დანიშნულების მისამართებს პორტებთან ერთად, შემდეგ მთელ ნაკადს აგზავნის იქ, სადაც ჰეში მიუთითებს. VPN გვირაბი მარშრუტიზატორის თვალსაზრისით ერთი ასეთი ნაკადია, რაც არ უნდა მუშაობდეს მის შიგნით. შიდა კავშირები არასდროს აღწევენ ჰეშის გადაწყვეტილებამდე, რადგან გარე სათაურმა უკვე განსაზღვრა გზა. ამიტომ მეორე აღმავალ არხს შეუძლია გააორმაგოს საერთო სიმძლავრე ბევრი მომხმარებლისთვის და არაფერი შეცვალოს ერთი მომხმარებლის დიდ გადაცემაში.
ორ ცალკეულ გვირაბს შეუძლია ორი კანდიდატი მოგცეთ, მაგრამ მათ მაინც სჭირდებათ განზრახ პოლიტიკა, რომელიც ტრაფიკს ანაწილებს და პასუხებს იმ გზაზე ინახავს, რომელმაც მოთხოვნა გაატარა. ასიმეტრიული მარშრუტიზაცია ამ ნაბიჯის გამოტოვების ჩვეულებრივი შედეგია. მინიმუმია პოლიტიკა, რომელიც ასახელებს ნაკადს, სასურველ ბმულს და სარეზერვო ბმულს.
Ethernet-ის გაერთიანება არ გადაკვეთს დაუკავშირებელ პროვაიდერებს, რადგან შორეულმა ბოლომ უნდა მიიღოს მონაწილეობა აგრეგაციის პროტოკოლში. ორ ინტერნეტ პროვაიდერს შორის გაერთიანება კვლევითი პროექტია, თუ არ არსებობს თანამშრომლობითი ბოლო წერტილი.
რა სჭირდება მრავალგზა TCP-ს ორივე ბოლოში
Linux-ის Multipath TCP დოკუმენტაცია აღწერს ერთ კავშირს კუთვნილ რამდენიმე ქვენაკადს. ერთ ბოლოში ბირთვის მხარდაჭერა თავისთავად არაფერს ცვლის, რადგან პარტნიორმაც უნდა მიიღოს ეს ქვენაკადები. შორეულ მხარეს პროქსი მეორე ჩვეულებრივი გზაა, და ის ხდება კომპონენტი საკუთარი სიმძლავრითა და ხელმისაწვდომობით, რომლებიც უნდა დაიგეგმოს. იგივე ლოგიკა გამორიცხავს მარტივ პასუხს WireGuard-ისთვის, რომლის ტრანსპორტი UDP-ია: MPTCP ზრდის TCP ქვენაკადებს და ვერ გააერთიანებს ამ გვირაბს პროექტში სხვა რამის გარეშე.
შეამოწმეთ, ჩართულია თუ არა ბირთვის ფუნქცია, სანამ მის გარშემო დააპროექტებთ, რადგან ბევრი დისტრიბუტივი მას გამორთულს აწვდის. ეს სამი ბრძანება ამას წუთში გიპასუხებთ.
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits showაირჩიეთ დატვირთვის მიხედვით, არა ბროშურის
თუ დატვირთვა ბევრი დამოუკიდებელი სესიაა, ნაკადის ჰეშით განაწილებას შეუძლია სიმძლავრის დამატება შორეული ბოლოს თანამშრომლობის გარეშე. თუ ერთი დიდი გადაცემაა, მხოლოდ აგრეგაციის პროექტი დაეხმარება, და მას თანამშრომლობითი პარტნიორი სჭირდება. თუ მოთხოვნაა, რომ სამუშაო გაგრძელდეს ბმულის სიკვდილისას, პასუხი გადართვაა და ერთი გადაცემის გამტარუნარიანობას მნიშვნელობა არ აქვს.
ჩაწერეთ მოთხოვნა ერთ წინადადებაში ზმნით: ერთი სარეზერვო ასლი ორჯერ უფრო სწრაფად სრულდება, ან ჩამოვარდნილი ბმული სესიას არ ამთავრებს. ბუნდოვანი მიზნები წარმოქმნის პროექტებს, რომლებსაც ვერავინ მიიღებს ან უარყოფს. შემდეგ გადაწყვიტეთ, რა შეიძლება იყოს შორეული ბოლო, რადგან ყველაზე იაფი ვარიანტი ხშირად ისაა, რომელიც იქ არაფერ ახალს არ მოითხოვს. ეს შეზღუდვა შლის ბროშურის კლაიმების უმეტესობას პირველ შეხვედრამდე.
შეინახეთ სამი დაპირება ცალ-ცალკე მოთხოვნების დოკუმენტში. პროექტი, რომელიც სამივეს აცხადებს, ჩვეულებრივ ერთს აწვდის და დანარჩენებს ჩუმად ვარაუდობს. შემდეგი ნაწილი ამოწმებს, რომელი მიეწოდება სინამდვილეში.
გამოსცადეთ ერთი გადაცემა და ბევრი, შემდეგ გამორთეთ ბმული
შეადარეთ ერთი უწყვეტი გადაცემა იმავე დანიშნულებისკენ რამდენიმე პარალელურ გადაცემას, და ჩაწერეთ დანაკარგი, შეყოვნება და თითოეული ბმულის გამოყენება. მოგება მხოლოდ პარალელური სესიებით ნაკადების განაწილებაზე მიუთითებს, არა ერთი ნაკადის გაერთიანებაზე. ცალკე გამოსცადეთ ერთი აღმავალი არხის დაკარგვა, რადგან სიმძლავრე, სანამ ორივე ბმული მუშაობს, არაფერს ამბობს დამკვიდრებული სესიის გადართვაზე. ჩაწერეთ მარშრუტი, სოკეტი და ხელახალი გაგზავნის მთვლელები ყოველი ტესტის წინ და შემდეგ.
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5როცა ერთადერთი გადაცემა კვლავ ერთ აღმავალ არხს იყენებს, პროექტი აკეთებს ზუსტად იმას, რასაც ნაკადის ჰეში გულისხმობს. როცა პარალელური გადაცემები ორივეზე ნაწილდება, განაწილება მუშაობს და გაერთიანება არა. ჩაწერეთ, სამი დაპირებიდან რომელს იცავს პროექტი სინამდვილეში, და სიმძლავრის შემდეგი საუბარი მტკიცებულებებიდან დაიწყება, არა გამყიდველის კლაიმიდან.