OpenVPN บน TCP: rto_min ไม่แก้การบล็อกที่หัวคิว

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

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

อาการ: ทุกอย่างหยุดพร้อมกัน

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

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

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

สตรีมไบต์ชั้นนอกหนึ่งเดียว บทสนทนาชั้นในมากมาย

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

นี่คือการบล็อกที่หัวคิวภายในหนึ่งการเชื่อมต่อ และไม่จำเป็นให้ทั้งสองแอปพลิเคชันใช้การเชื่อมต่อชั้นในร่วมกันมันใช้ชั้นนอกร่วมกัน ซึ่งเพียงพอ

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

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

ทำไมไทม์เมอร์ชั้นในที่ยาวขึ้นจึงช่วยไม่ได้

การยกเวลาหมดอายุการส่งซ้ำขั้นต่ำบนเส้นทางด้วย rto_min จะเลื่อนการส่งซ้ำตามไทม์เมอร์สำหรับทราฟฟิก TCP ที่สร้างในเครื่องซึ่งใช้เส้นทางนั้นมันเป็นปุ่มจริงที่มีผลจริง และจัดการกับปัญหาอันดับสองมากกว่าอันดับแรก

ip route show
ip route show cache 2>/dev/null | head
ss -tin dst 10.70.0.1

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

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

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

tcp-nodelay ทำอะไรและไม่ทำอะไร

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

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

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

จะเปรียบเทียบการขนส่งอย่างเป็นธรรมได้อย่างไร

หากผู้ให้บริการอนุญาตและมีทั้งสองบริการ ให้ เปรียบเทียบบริการ UDP และบริการ TCP ที่บรรทุกภาระงานเดียวกัน บนเส้นทางเข้าถึงเดียวกันไปยังเซิร์ฟเวอร์เดียวกันการเปลี่ยนประเทศ ผู้ให้บริการ หรือรุ่นเซิร์ฟเวอร์ระหว่างการทดสอบสองครั้งจะนำตัวแปรที่ครอบงำผลลัพธ์เข้ามา

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

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

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