TCP ภายใน SSTP: ทำไมการส่งซ้ำจึงเกิดขึ้นสองครั้ง

คำบอกเล่ามาก่อนโปรโตคอล ถามรอบ ๆ แล้ว SSTP คือตัวที่ช้า ตัวเลือกที่คุณหลีกเลี่ยงเว้นแต่มีบางอย่างบังคับ ภาพลักษณ์นั้นอธิบายความล้มเหลวเพียงโหมดเดียวบนเส้นทางชนิดเดียว

กลไกเป็นเรื่องจริง แต่ก็มีเงื่อนไข ซึ่งภาพลักษณ์ไม่เคยกล่าวถึง

สองสตรีมที่เชื่อถือได้บนเส้นทางเดียว

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

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

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

ผลกระทบเกิดที่ไหนและไม่เกิดที่ไหน

บนเส้นทางที่สะอาด สตรีมภายนอกแทบไม่กู้คืนอะไรเลย ปฏิสัมพันธ์ไม่เคยเกิดขึ้น และ SSTP บรรทุกทราฟฟิกแบบโต้ตอบได้ดีทีเดียว ข้อกล่าวอ้างแบบเหมารวมล้มเหลวตรงจุดนี้เอง

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

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

สิ่งที่อาการมักไม่ใช่

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

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

# outer path quality to the SSTP endpoint
ping -c 50 203.0.113.44 | tail -3
mtr -rwc 50 203.0.113.44

# is the local link saturated while the session stalls?
sar -n DEV 2 5

# retransmissions on the outer connection
ss -tin dst 203.0.113.44

วัดผลขณะที่ปัญหากำลังเกิดขึ้น การบันทึกที่ทำในนาทีที่สุขภาพดีไม่ได้พิสูจน์อะไรเกี่ยวกับลูปที่ทำงานในนาทีที่แย่

การเปรียบเทียบที่ไว้ใจได้

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

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

เปิดการตรวจสอบ TLS ไว้ตลอดเวลา งานด้านประสิทธิภาพไม่ใช่เหตุผลที่จะยอมรับใบรับรองที่ไม่ผ่านการตรวจสอบ หากการหยุดชะงักส่วนใหญ่เกิดขณะลิงก์อัปโหลดอิ่มตัว ให้ดูก่อนการเข้าคิวก่อนโทษชั้นต่าง ๆ