ดาวน์โหลดใหญ่กับ VPN: เลือกเส้นทางที่คำขอ

“ส่งดาวน์โหลดใหญ่ไปรอบ VPN และเก็บคำตอบเล็กไว้บนนั้น” ฟังดูเหมือนนโยบายการกำหนดเส้นทาง แต่ไม่ใช่ เราเตอร์ตัดสินใจด้วยข้อมูลที่พร้อมใช้ในขณะนั้น: ที่อยู่ พอร์ต โปรโตคอล เครื่องหมาย firewall กระแสที่ระบุได้ ขนาดสุดท้ายของคำตอบไม่อยู่ในชุดนั้น เพราะยังมาไม่ถึง และเมื่อเราเตอร์วัดไบต์ได้ มันก็กำลังขนส่งอยู่แล้ว หากต้องการสั่งตามงาน การตัดสินใจต้องย้ายไปยังจุดที่รู้จักงาน และรายการตรวจสอบด้านล่างคือวิธีดูว่าการออกแบบของคุณมีจุดนั้นหรือไม่

ทำไมเราเตอร์จึงวัดคำตอบไม่ได้

ในขณะที่แพ็กเก็ตต้องการเส้นทาง เราเตอร์เห็นแพ็กเก็ตแรก ๆ ของกระแสอย่างมาก มันบอกได้ว่าใครคุยกับใคร ด้วยโปรโตคอลใด ด้วยเครื่องหมายใด และมีไบต์ผ่านไปแล้วกี่ไบต์ ไบต์ที่ผ่านมาแล้วอธิบายอดีต ขนาดของคำตอบเป็นคุณสมบัติของคำตอบที่ยังไม่ถูกสร้าง และสำหรับคำตอบแบบแบ่งส่วนหรือสตรีมมิ่ง อาจไม่มีทางรู้ล่วงหน้าเลย

แม้แต่เมทาดาทาของโปรโตคอลเองก็อ่อนกว่าที่เห็น HTTP ยอมให้คำตอบที่ไม่ประกาศความยาวก่อนเนื้อหา และการกระทำของผู้ใช้ครั้งเดียวอาจสร้างคำขอจำนวนมากซึ่งต้นทุนรวมไม่เหมือนค่าเฮดเดอร์ใดเลย การถือว่าเฮดเดอร์คือขนาดของงานเป็นข้อผิดพลาดในการสร้างแบบจำลองก่อนจะเป็นข้อผิดพลาดในการกำหนดเส้นทาง

การตรวจ 1: มีจุดตัดสินใจที่เลือกเส้นทางได้หรือไม่

ระบุองค์ประกอบที่จะทำการเลือก แล้วบอกว่ามันรู้อะไรในขณะเลือก โปรแกรมอัปเดตที่ดึงจากชุดโฮสต์ที่มีเอกสารกำกับรู้จุดประสงค์ของตนก่อนเริ่มการถ่ายโอน บริการดาวน์โหลดที่ตรวจเมทาดาทาแล้วเปิดคำขอรู้งานก่อนการเชื่อมต่อจะเกิด proxy ที่ร่วมมือสามารถใช้นโยบายระดับคำขอหรือแคชคำตอบโดยไม่แสร้งว่าเป็นเราเตอร์

ถ้าคำตอบคือ “เกตเวย์” รายการตรวจสอบก็ล้มเหลวแล้ว เกตเวย์สามารถจำแนกกระแสที่รู้จักตามปลายทาง เครื่องหมาย หรือส่วนของไคลเอนต์ แล้วส่งไปตามเส้นทางที่กำหนดตั้งแต่แพ็กเก็ตแรก ซึ่งมักพอสำหรับโปรแกรมอัปเดตที่อนุมัติแล้ว และไม่เคยพอสำหรับขนาดคำตอบที่ไม่รู้

การตรวจ 2: เมทาดาทาบอกอะไรคุณจริง ๆ

การสั่งที่รู้แอปพลิเคชันดีได้เท่ากับฟิลด์ที่มันอ่าน กฎความยาวคำตอบใน ความหมายของ HTTP ยอมให้กรณีที่ความยาวไม่พร้อมใช้ตอนเริ่มต้น และการเข้ารหัสเนื้อหาทำให้จำนวนไบต์ที่ถ่ายโอนต่างจากขนาดตัวแทนอยู่แล้ว นโยบายที่เปลี่ยนเส้นทางเมื่อเฮดเดอร์ข้ามเกณฑ์จึงทำงานไม่สม่ำเสมอ และส่วนใหญ่เกิดกับการถ่ายโอนขนาดใหญ่ที่มันควรจับได้พอดี

สิ่งที่เมทาดาทาแอปพลิเคชันรองรับได้คือการตัดสินใจเกี่ยวกับงาน: เวิร์กโฟลว์นี้เป็นการซิงก์จำนวนมาก อันนี้เป็นแบบโต้ตอบ อันนี้คือการอัปเดตซอฟต์แวร์จากแหล่งที่รู้จัก นั่นคือนโยบายที่เขียนด้วยภาษาของเจตนา และเสถียรพอจะทดสอบได้ “คำตอบนี้จะใหญ่กว่าสี่สิบเมกะไบต์” ไม่ใช่นโยบายแบบนั้น

การตรวจ 3: กระแสมีอยู่แล้วหรือไม่

การกำหนดเส้นทางเปลี่ยนได้สำหรับกระแสโดยไม่เปลี่ยนอัตลักษณ์ของการเชื่อมต่อ และความต่างนี้ควรถือให้ตรง การเชื่อมต่อ TCP ระบุได้ด้วยที่อยู่และพอร์ตของปลายทั้งสอง และแพ็กเก็ตอาจไปคนละเส้นทางหากตารางเส้นทางเปลี่ยนใต้มัน สิ่งที่เปลี่ยนแบบมองไม่เห็นไม่ได้คือสถานะการแปลที่อยู่เครือข่าย: การย้ายทราฟฟิกไปทางออกอื่นมักเปลี่ยนทูเพิลต้นทางสาธารณะ และปลายทางไกลจะเห็นคู่ต่างที่ไม่ตรงกับสถานะ

conntrack -L -p tcp --dport 443 | head -5
ip route get 203.0.113.10
ss -tn state established dst 203.0.113.10

ดังนั้นกฎปฏิบัติคือ การย้ายกลางการเชื่อมต่อจากทางออกหนึ่งไปอีกทางหนึ่งเป็นความสัมพันธ์ใหม่ ไม่ใช่การโยกย้าย หากการออกแบบต้องการให้การเชื่อมต่อเดิมดำเนินต่อ ต้องตัดสินใจก่อน SYN แรก และไม่มีกฎแพ็กเก็ตใดที่เพิ่มทีหลังจะสร้างมันขึ้นมาใหม่ได้อย่างสะอาด

การตรวจ 4: ความต้องการจริงคือความหน่วง ไม่ใช่ทางออกหรือไม่

คำขอ “ส่งทราฟฟิกจำนวนมากไปที่อื่น” เป็นจำนวนมากแท้จริงแล้วคือข้อร้องเรียนว่าการถ่ายโอนขนาดใหญ่ทำให้งานโต้ตอบรู้สึกช้า นั่นคือปัญหาเรื่องการจัดตาราง และมีคำตอบด้านการจัดตาราง: คิวที่เป็นธรรมหรือนโยบายแบนด์วิดท์ที่รองรับบนเส้นทางเดิมป้องกันไม่ให้กระแสจำนวนมากทำให้ข้อความแชตอดอยาก โดยไม่ย้ายทั้งสองอย่าง

tc qdisc replace dev eth0 root cake bandwidth 100mbit

การจัดการกับอาการแบบนี้ทำให้การตัดสินใจเรื่องทางออกอยู่ที่นี่นโยบายความปลอดภัยวางไว้ และย้อนกลับได้ด้วยคำสั่งเดียว การเปลี่ยนทางออกสำหรับทราฟฟิกทั้งคลาสเป็นการเปลี่ยนนโยบายที่มีผลต่อการยืนยันตัวตน การบันทึก และกฎการเข้าถึง ดังนั้นจึงไม่ควรเป็นเครื่องมือแรกเมื่อมีข้อร้องเรียนเรื่องความหน่วง

หากความต้องการคือทางออกอินเทอร์เน็ตอื่นจริง ๆ ให้พูดแบบนั้นและนำไปใช้ที่ขอบเขตที่รองรับ: การเชื่อมต่อใหม่จากเวิร์กโฟลว์ที่อนุมัติ หรือแอปพลิเคชันที่เปิดคำขอของตนผ่านทางออกที่เลือก จากนั้นบันทึกว่างานใดใช้ทางออกใด เพื่อให้คนถัดไปไม่ต้องอนุมานจากตารางเส้นทาง

เก็บรายการตรวจสอบไว้ในบันทึกการเปลี่ยนแปลง: จุดตัดสินใจ ฟิลด์หรืองานที่ขับเคลื่อนมัน กระแสมีอยู่แล้วหรือไม่ และอาการที่วัดได้คือความหน่วงหรือทางออก สี่คำถาม และนโยบายที่ตอบทั้งสี่ข้อคือสิ่งที่คุณใช้งานได้ ไม่ใช่ปกป้อง