อินเทอร์เน็ตทำงานบนโปรโตคอลหลักเพียงไม่กี่ตัว โดยมี TCP และ UDP เป็นตัวหลักที่รับมือกับข้อมูลเกือบทั้งหมดของเรา แต่จะเกิดอะไรขึ้นเมื่อคุณพยายามใช้โปรโตคอลอื่น? การทดลองที่น่าสนใจในการส่งแพ็กเก็ตด้วยโปรโตคอลการขนส่งที่สร้างขึ้นเองผ่านอินเทอร์เน็ตเผยให้เห็นข้อจำกัดที่ซ่อนอยู่ของโครงสร้างพื้นฐานดิจิทัลของเรา และเหตุผลที่การสร้างนวัตกรรมในชั้นการขนส่งกลายเป็นเรื่องที่เป็นไปไม่ได้เกือบจะโดยสิ้นเชิง
การแข็งตัวของโปรโตคอล: ปัญหาที่ซ่อนอยู่ของอินเทอร์เน็ต
อินเทอร์เน็ตกำลังประสบกับภาวะที่เรียกว่าการแข็งตัวของโปรโตคอล - ซึ่งเกิดจากการติดตั้ง middlebox, ไฟร์วอลล์ และอุปกรณ์ NAT อย่างแพร่หลาย ทำให้เราถูกจำกัดให้ใช้เพียง TCP และ UDP สำหรับการขนส่งข้อมูลเท่านั้น ในขณะที่เครือข่าย IP ควรจะส่งต่อโปรโตคอลใดๆ ก็ได้ในทางทฤษฎี แต่ความเป็นจริงนั้นแตกต่างออกไปอย่างมาก ดังที่ผู้แสดงความคิดเห็นคนหนึ่งอธิบายว่า อินเทอร์เน็ตได้มาตรฐานรอบ TCP และ UDP แล้ว มีอุปกรณ์มากเกินไปในเส้นทางส่วนใหญ่ที่ไม่สามารถรองรับโปรโตคอลอื่นได้ การแข็งตัวนี้เกิดขึ้นเพราะผู้ผลิตอุปกรณ์เครือข่ายและผู้ให้บริการปรับแต่งระบบให้เหมาะกับโปรโตคอลที่พวกเขาเห็นบ่อยที่สุด ทำให้ความเข้ากันได้กับสิ่งใหม่หรือแตกต่างถูกทำลายลง
SCTP (Stream Control Transmission Protocol) เป็นตัวอย่างที่ดีของปัญหานี้ แม้ว่าจะมีประสิทธิภาพทางเทคนิคเหนือกว่า TCP ในหลายๆ ด้าน แต่มันแทบจะไม่ถูกใช้งานบนอินเทอร์เน็ตสาธารณะเลย
SCTP น่าสนใจมากเพราะเป็นหนึ่งในเทคโนโลยีหลักที่ทำให้การสื่อสารเป็นไปได้สำหรับคนส่วนใหญ่บนโลก (เนื่องจากระบบเครือข่ายมือถือพึ่งพามันเป็นอย่างมาก) แต่กลับไม่ได้รับการสนับสนุนในอุปกรณ์ผู้บริโภคเกือบทุกชนิด
ในขณะที่ SCTP ขับเคลื่อนโครงสร้างพื้นฐานโทรคมนาคมที่สำคัญภายใน แต่มันไม่สามารถเดินทางผ่านอินเทอร์เน็ตสาธารณะได้อย่างน่าเชื่อถือ ความขัดแย้งนี้ชี้ให้เห็นว่าแม้แต่โปรโตคอลที่ออกแบบมาอย่างดีและได้มาตรฐานก็ยังอาจล้มเหลวในการได้รับการยอมรับเมื่อเผชิญกับความเป็นจริงของวิธีการสร้างและจัดการเครือข่าย
ปัญหาของการตายตัวของโปรโตคอล
- โปรโตคอลที่ล้มเหลว: SCTP (Stream Control Transmission Protocol) - เหนือกว่าทางเทคนิคแต่ไม่สามารถส่งผ่านอินเทอร์เน็ตสาธารณะได้
- ปัญหาของ NAT: ผู้ใช้งานที่อยู่หลัง NAT ถูกจำกัดให้ใช้เฉพาะ TCP/UDP เท่านั้น
- กลยุทธ์การแก้ปัญหา: การสร้างอุโมงค์โปรโตคอลใหม่ภายใน UDP (เช่น QUIC สำหรับ HTTP/3)
- กรณีพิเศษ:
- SCTP ถูกใช้อย่างแพร่หลายในโครงสร้างพื้นฐานของเครือข่ายมือถือภายใน
- WebRTC ทำงานโดยใช้ SCTP ผ่าน DTLS ผ่าน UDP
- โปรโตคอลที่ปรับแต่งเองอาจทำงานได้ระหว่างเซิร์ฟเวอร์ในศูนย์ข้อมูล แต่ล้มเหลวเมื่อใช้งานผ่านอินเทอร์เน็ตสาธารณะ
เหตุผลที่โปรโตคอลที่ปรับแต่งเองล้มเหลว
- อุปกรณ์ตัวกลางจะหยุดโปรโตคอลที่ไม่คุ้นเคย
- อุปกรณ์ NAT ไม่สามารถติดตามสถานะการเชื่อมต่อได้หากไม่มีหมายเลขพอร์ต
- เครื่องมือรักษาความปลอดภัยขององค์กรสูญเสียการมองเห็น
- ไฟร์วอลล์บล็อกแพ็กเก็ตที่ไม่ตรงกับการไหลของข้อมูลที่มีอยู่
NAT: อุปสรรคใหญ่ที่สุดของอินเทอร์เน็ต
อุปกรณ์แปลงที่อยู่เครือข่าย (NAT) เป็นอุปสรรคสำคัญที่สุดต่อนวัตกรรมโปรโตคอล NAT ทำงานโดยการติดตามการเชื่อมต่อโดยใช้ฟิลด์ในชั้นการขนส่ง - โดยเฉพาะหมายเลขพอร์ตในส่วนหัวของ TCP และ UDP เมื่อเผชิญกับโปรโตคอลที่ไม่รู้จักซึ่งไม่มีฟิลด์ที่คุ้นเคยเหล่านี้ อุปกรณ์ NAT ส่วนใหญ่จะใช้ที่อยู่ IP ทั้งหมด (ทำให้ที่อยู่ที่มีอยู่หมดอย่างรวดเร็ว) หรือเพียงแค่ทิ้งแพ็กเก็ตไป
ข้อจำกัดนี้เป็นปัญหาโดยเฉพาะสำหรับผู้ใช้ตามบ้าน ดังที่ผู้แสดงความคิดเห็นคนหนึ่งได้กล่าวไว้ว่า ผู้ใช้ตามบ้านทุกคนอยู่หลัง NAT ในขณะที่คุณสามารถส่งโปรโตคอลใดๆ ระหว่างเซิร์ฟเวอร์ในศูนย์ข้อมูล แต่ผู้ใช้ IPv4 ตามบ้านติดอยู่กับ TCP หรือ UDP เท่านั้น แม้แต่ในการทดลองที่อธิบายในบทความ แพ็กเก็ตที่ใช้โปรโตคอลที่กำหนดเองบางครั้งอาจผ่านไปได้ครั้งเดียว แต่จะถูกทิ้งหลังจากนั้น อาจเป็นเพราะไฟร์วอลล์ไม่สามารถจับคู่กับการไหลของการเชื่อมต่อที่มีอยู่ได้
อนาคต: การทำอุโมงค์โปรโตคอลและ IPv6
เพื่อเอาชนะการแข็งตัว นักออกแบบโปรโตคอลสมัยใหม่ได้นำวิธีการที่เป็นรูปธรรมมาใช้: การทำอุโมงค์โปรโตคอลใหม่ภายใน UDP QUIC ซึ่งขับเคลื่อน HTTP/3 เป็นตัวอย่างของกลยุทธ์นี้ แทนที่จะต่อสู้กับระบบ QUIC ยอมรับ UDP เป็นพื้นฐานและสร้างนวัตกรรมของมันบนนั้น
วิธีการนี้สร้างความตึงเครียดระหว่างนวัตกรรมและความปลอดภัย ผู้ดูแลเครือข่ายมักต่อต้านการพัฒนาเหล่านี้เพราะมันทำลายเครื่องมือความปลอดภัยที่มีอยู่ ดังที่ผู้เชี่ยวชาญด้านเครือข่ายคนหนึ่งอธิบายว่า จากมุมมองด้านความปลอดภัยขององค์กร มันทำลายเครื่องมือมากมาย คุณไม่สามารถถอดรหัส ลายเซ็น IDS/IPS ไม่ทำงาน และคุณสูญเสียการมองเห็นว่าเกิดอะไรขึ้นในเครือข่ายของคุณ
IPv6 ให้ความหวังบางอย่างสำหรับความหลากหลายของโปรโตคอล เนื่องจากมันกำจัดความจำเป็นของ NAT ในหลายๆ สถานการณ์ อย่างไรก็ตาม แม้แต่กับ IPv6 ไฟร์วอลล์และ middlebox ก็ยังอาจบล็อกโปรโตคอลที่ไม่คุ้นเคย การเปลี่ยนไปใช้ IPv6 ยังคงช้าอย่างน่าหงุดหงิด โดยเครือข่ายองค์กรหลายแห่งยังคงพึ่งพาพื้นที่ที่อยู่ IPv4
การทดลองที่อธิบายในบทความยืนยันสิ่งที่วิศวกรเครือข่ายสงสัยมานาน: อินเทอร์เน็ตได้กลายเป็นสภาพแวดล้อมที่มีความเชี่ยวชาญสูงซึ่งปรับให้เหมาะกับโปรโตคอลเพียงไม่กี่ชุด แม้ว่าคุณอาจโชคดีในการส่งแพ็กเก็ตเดียวด้วยโปรโตคอลแปลกๆ แต่การสร้างการสื่อสารที่เชื่อถือได้จำเป็นต้องทำงานภายในข้อจำกัดของสิ่งที่เครือข่ายรองรับจริง ไม่ใช่สิ่งที่มันควรจะรองรับในทางทฤษฎี
สำหรับอนาคตอันใกล้นี้ TCP และ UDP จะยังคงเป็นตัวเลือกการขนส่งที่เป็นไปได้เพียงอย่างเดียวสำหรับการจราจรอินเทอร์เน็ตสาธารณะ โดยนวัตกรรมจะเกิดขึ้นเป็นหลักผ่านการทำอุโมงค์และการซ้อนชั้นมากกว่าผ่านโปรโตคอลการขนส่งใหม่
อ้างอิง: What would happen if we didn't use TCP or UDP?
 |
|---|
| กฎไฟร์วอลล์ที่จำกัดการส่งข้อมูลออกแสดงถึงข้อจำกัดของเครือข่ายต่อนวัตกรรมโปรโตคอล |