TCP-over-TCP ทำให้ VPN ช้าได้อย่างไร

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

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

ทบทวนสั้น ๆ เรื่อง TCP กับ UDP

ทั้ง TCP และ UDP ส่งข้อมูลระหว่างคอมพิวเตอร์สองเครื่อง แต่สัญญาไว้ไม่เหมือนกัน

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

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

อะไรผิดพลาด ช่างซ่อมสองทีมสำหรับแพ็กเก็ตที่เสียตัวเดียว

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

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

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

ผลคือการทับซ้อนกัน

1. ชั้นนอกยังซ่อมการสูญหายครั้งแรกอยู่
2. ชั้นในประกาศแล้วว่าข้อมูลหายและส่งสำเนา
3. สำเนานั้นเข้าคิวของชั้นนอก ตามหลังแพ็กเก็ตที่กำลังซ่อมนั่นเอง
4. อุโมงค์จึงแบกข้อมูลซ้ำที่ไม่มีใครต้องการ
5. ชั้นในเห็นความล่าช้าและการตอบรับซ้ำ จึงลดหน้าต่างการส่งลงอีก

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

ลำดับเวลาตัวอย่าง

สมมติลิงก์ปานกลางที่เวลาไปกลับ 60 มิลลิวินาที อุโมงค์กำลังพาการดาวน์โหลด และมีแพ็กเก็ตหายหนึ่งตัว

เวลา	อุโมงค์ชั้นนอก (TCP)	การเชื่อมต่อชั้นใน (TCP)
0 ms	แพ็กเก็ตที่ 7 ของอุโมงค์หาย	ส่งข้อมูลเป็นสายต่อเนื่อง
60 ms	แพ็กเก็ต 8, 9 และ 10 มาถึงแต่ถูกกักไว้	รอการตอบรับ
120 ms	ผู้รับส่งสัญญาณว่ามีช่องว่าง	การตอบรับมาช้า
200 ms	ชั้นนอกส่งแพ็กเก็ต 7 ซ้ำ	ตัวจับเวลาหมด ชั้นในส่งข้อมูลซ้ำ
260 ms	แพ็กเก็ต 7 ถึง 10 ถูกปล่อยพร้อมกัน	ชั้นในเห็นการพุ่งกะทันหันและข้อมูลซ้ำ
300 ms	สำเนาของชั้นในมาถึงตามหลังฉบับแรก	หน้าต่างของชั้นในถูกลดครึ่งไปแล้ว

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

ทำไมอุโมงค์ UDP จึงเลี่ยงปัญหานี้

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

การออกแบบใหม่ไปไกลกว่านั้น การขนส่ง QUIC ที่กำหนดใน RFC 9000 วิ่งบน UDP และมีการกู้คืนจากการสูญหายในตัว เป็นเหตุผลที่แนวทาง IP-in-HTTP บางแบบ เช่น Proxying IP in HTTP พาอุโมงค์ผ่าน HTTP/3 ได้โดยไม่ต้องซ้อน TCP สองชั้น คุณไม่จำเป็นต้องรู้รายละเอียด ประเด็นคืออุตสาหกรรมตั้งใจถอยออกจาก TCP-in-TCP

ทำไมอุโมงค์ TCP ยังมีอยู่

ถ้าอึดอัดขนาดนี้ ทำไมยังมีให้ใช้ เพราะมันแก้ปัญหาอีกแบบ

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

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

สังเกตอาการ

ปัญหา TCP-over-TCP ไม่ค่อยประกาศตัว รูปแบบเหล่านี้ชวนสงสัย โดยเฉพาะเมื่อเกิดบนเครือข่ายที่ไม่ดีและดีขึ้นบนเครือข่ายที่ดี

• ปริมาณงานดูดีในการทดสอบสั้น ๆ แต่ตกฮวบในการถ่ายโอนยาว
• ความเร็วแกว่งเป็นฟันเลื่อยมีช่วงราบยาว
• หน้าเว็บค้างหลายวินาทีแล้วโหลดทุกอย่างพร้อมกัน
• งานโต้ตอบ เช่นพิมพ์ในเชลล์ระยะไกล หน่วงเป็นช่วง ๆ
• ปัญหาแย่กว่ามากบน Wi-Fi หรือเน็ตมือถือเมื่อเทียบกับสายแลน
• เวลา ping ไปยังเซิร์ฟเวอร์ VPN ดูปกติ แต่การถ่ายโอนจริงแย่
• อุปกรณ์เดียวกันเร็วกว่าบนเครือข่ายอื่นหรือในโหมดอื่น

หากปัญหาคือช้าสม่ำเสมอมากกว่าการหยุดชะงัก ให้เริ่มที่ทำไม VPN จึงช้า เพราะสาเหตุง่าย ๆ เช่นระยะทางหรือเซิร์ฟเวอร์ที่ยุ่งพบบ่อยกว่า TCP-over-TCP มาก

ทดสอบโดยไม่ต้องใช้เครื่องมือพิเศษ

บนโทรศัพท์ส่วนใหญ่คุณตรวจภายในอุโมงค์ไม่ได้ แต่ทำการเปรียบเทียบแบบควบคุมได้

ขั้นที่ 1 ทำให้เครือข่ายแข็งแรงก่อน ping เราเตอร์ 100 ครั้ง (Windows ping -n 100, macOS หรือ Linux ping -c 100) หากพบการสูญหาย ให้แก้ก่อน เพราะการสูญหายคือตัวกระตุ้นปัญหา

ขั้นที่ 2 บันทึกค่าพื้นฐานตอนไม่มี VPN ดาวน์โหลดไฟล์สาธารณะขนาดใหญ่ หรือทดสอบความเร็ว แล้วจดเวลาและความนิ่งของความเร็ว

ขั้นที่ 3 ทดสอบเดิมตอนมี VPN เทียบทั้งตัวเลขและรูปทรง เส้นเรียบที่ต่ำลงเล็กน้อยคือภาระของอุโมงค์ตามปกติ เส้นหยักที่มีการหยุดคือรูปแบบที่น่าสงสัย

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

ขั้นที่ 5 ตรวจโหมดที่แอปใช้ หากแอปแสดงชนิดการเชื่อมต่อ ให้จดว่าเป็น TCP หรือ UDP หากไม่แสดง อย่าเดา กับ XPASS คุณใช้แอป VPNclient ฟรีและรายละเอียดในหน้า My Pass ของคุณ ให้คงค่าเริ่มต้นของแอปไว้เว้นแต่ฝ่ายสนับสนุนแนะนำ

ขั้นที่ 6 ลองตำแหน่งอื่น เซิร์ฟเวอร์อื่นอาจให้เส้นทางที่สะอาดกว่า ซึ่งลดการสูญหายและลดผลกระทบ

วิธีลดความเสียหายในทางปฏิบัติ

1. ลดแพ็กเก็ตหายที่ต้นทาง ใช้สายแลน ขยับเข้าใกล้เราเตอร์ เลือก 5 GHz และหยุดการอัปโหลดหนัก ๆ การสูญหายคือตัวกระตุ้น กำจัดมันก็ตัดความเจ็บปวดส่วนใหญ่
2. เลือก UDP เมื่อเครือข่ายและแอปอนุญาต เป็นค่าเริ่มต้นของการออกแบบอุโมงค์สมัยใหม่จำนวนมาก สลับเมื่อแอปเปิดให้เลือกอย่างชัดเจนเท่านั้น
3. ใช้ตำแหน่งที่ใกล้กว่า เวลาไปกลับสั้นลงหมายถึงตัวจับเวลาหมดเร็วขึ้นและฟื้นเร็วขึ้น
4. รักษา MTU ให้เหมาะสม แพ็กเก็ตใหญ่เกินอาจเพิ่มการสูญหายและการแบ่งชิ้นซ้ำเติมปัญหา ดูวิธีหาค่า MTU ที่เหมาะสมสำหรับวิธีวัด
5. หลีกเลี่ยงการซ้อนอุโมงค์ การรัน VPN ซ้อน VPN อีกตัว หรือผ่านพร็อกซีที่ใช้ TCP ด้วย ทำให้ชั้นเพิ่มเป็นทวีคูณ
6. เชื่อมต่อใหม่หลังหยุดชะงักนาน เซสชันใหม่ล้างตัวจับเวลาที่พองโต
7. ตรวจหาซอฟต์แวร์ที่ชนกัน เช่นชุดความปลอดภัยที่ตรวจหรือพร็อกซีทราฟฟิก

ถ้าเครือข่ายของคุณอนุญาตเฉพาะ TCP และคุณยังต้องใช้ VPN ให้ยอมรับความช้าบางส่วน การลดภาระ เช่นหยุดดาวน์โหลดขนาดใหญ่ ทำให้ทนได้มากขึ้น

ข้อจำกัดและข้อควรระวัง

• VPN ช้าทุกตัวไม่ได้เจอเรื่องนี้ ระยะทาง ภาระเซิร์ฟเวอร์ อุปกรณ์อ่อนแอ และการจำกัดความเร็วของผู้ให้บริการพบบ่อยกว่ามาก
• TCP สมัยใหม่ฉลาดกว่าภาพในตำรา การปรับแต่ง การควบคุมจังหวะ และการกู้คืนที่ดีขึ้นลดผลร้ายที่สุดลง ความเสียหายจึงต่างกันตามระบบปฏิบัติการ
• ผลิตภัณฑ์อุโมงค์บางตัวลดปัญหา ด้วยกลเม็ดของตัวเอง เช่นบัฟเฟอร์เล็กหรือความน่าเชื่อถือแบบกำหนดเอง ผลต่างกันตามการใช้งานจริง
• คุณอาจไม่เห็นการขนส่งเสมอไป หลายแอปซ่อนไว้ อย่าสันนิษฐานสาเหตุโดยไม่มีหลักฐาน
• อุโมงค์ TCP ไม่ได้ไม่ปลอดภัย ปัญหาคือประสิทธิภาพ ไม่ใช่ความปลอดภัย การเข้ารหัสเป็นคุณสมบัติแยกต่างหาก อธิบายในโพรโทคอล VPN คืออะไร
• อย่าเปลี่ยนการตั้งค่าเพื่อเลี่ยงกฎของเครือข่าย หากที่ทำงานหรือโรงเรียนจำกัดทราฟฟิก ให้ถามเจ้าของ

ข้อผิดพลาดที่พบบ่อย

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

สรุป

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

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