จะเกิดอะไรขึ้นถ้าไม่ใช้ TCP หรือ UDP?

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

ภาพรวมของอินเทอร์เน็ตโปรโตคอล

• อินเทอร์เน็ตทำงานโดยอาศัยโปรโตคอลหลายชั้นในการส่งต่อข้อมูล
• เมื่อแอปพลิเคชันส่งคำขอ OS จะห่อข้อมูลนั้นด้วยเฮดเดอร์ของเครือข่ายหลายชั้นก่อนส่งออกไป
• ชั้นขนส่ง (Transport Layer): เป็นตำแหน่งของโปรโตคอลอย่าง TCP(6), UDP(17)
• จะเกิดอะไรขึ้นหากแก้ไขฟิลด์ Protocol ใน IP header แล้วใส่ หมายเลขที่ไม่ได้ใช้งาน ลงไป?

การทดลอง #1: ทดสอบโดยตรงบนพีซีของฉัน

วิธีทดลอง

1. นิยาม HDP (โปรโตคอลปลอม): ออกแบบโปรโตคอลชั้นขนส่งใหม่ที่แตกต่างจากโปรโตคอลเดิมโดยสิ้นเชิง
2. สร้างเซิร์ฟเวอร์และไคลเอนต์: พัฒนาโปรแกรมสำหรับรับส่งแพ็กเก็ต
3. ทดสอบ loopback: สังเกตวิธีที่ OS จัดการแพ็กเก็ตภายในตัวเอง

ขั้นตอนการรัน

$ sudo cargo run --bin server  # 서버 실행  
$ fortune | cowsay | sudo cargo run --bin client 127.0.0.1  # 클라이언트 실행  

ผลลัพธ์

• OS จัดการแพ็กเก็ต HDP ได้ตามปกติ และรับกลับมาอีกครั้งผ่านอินเทอร์เฟซ loopback
• มีการทดสอบเพิ่มเติมโดยเปลี่ยนหมายเลข IP protocol
  • 1 (ICMP), 2 (IGMP), 6 (TCP) → เซิร์ฟเวอร์ตรวจไม่พบ
  • 50, 51 (โปรโตคอลที่เกี่ยวข้องกับ IPSec) → ถูกบล็อกตั้งแต่ฝั่งไคลเอนต์ ไม่สามารถส่งได้
  • 256 (เกินช่วงหมายเลข IP protocol) → เกิดข้อผิดพลาดในขั้นตอนเรียก socket()

การวิเคราะห์สาเหตุ

• มีกรณีที่ OS จองหมายเลขโปรโตคอลบางตัวไว้ในระดับระบบและบล็อกไว้
• บน Darwin (macOS ที่อิง BSD) หากตั้งค่า protocol=0 ตอนเรียก socket() แพ็กเก็ตบางส่วนจะถูกกรองอัตโนมัติ
• โปรโตคอลที่เกี่ยวข้องกับ IPSec มีความเป็นไปได้สูงว่าจะถูกบล็อกด้วยเหตุผลด้านความปลอดภัย
• หมายเลขโปรโตคอลของ IPv4 เป็นแบบ 8 บิต จึงใช้ได้เพียง 0~255

การทดลอง #2: ส่งแพ็กเก็ตผ่านอินเทอร์เน็ต

แผนการทดลอง

1. ตั้งค่า DigitalOcean VPS: สร้างสภาพแวดล้อมทดลองบนคลาวด์เซิร์ฟเวอร์ที่แฟรงก์เฟิร์ต ประเทศเยอรมนี
2. ส่งแพ็กเก็ต HDP: ส่งแพ็กเก็ตจากพีซีของฉัน (ซาอุดีอาระเบีย) ไปยังเซิร์ฟเวอร์ DigitalOcean
3. วิเคราะห์การตอบสนองของอุปกรณ์เครือข่าย: ตรวจดูว่าแพ็กเก็ตไปถึงหรือถูกไฟร์วอลล์บล็อก

ผลที่คาดไว้

• แพ็กเก็ต HDP อาจถูกส่งถึงตามปกติ หรืออาจถูกบล็อกโดย ISP บางรายหรือไฟร์วอลล์ของ DigitalOcean

ผลลัพธ์จริง

• มีเพียงแพ็กเก็ตแรกเท่านั้นที่ไปถึง และแพ็กเก็ตหลังจากนั้นถูกบล็อก
• เมื่อตรวจสอบด้วย tcpdump พบว่า:
  • แพ็กเก็ตถูกส่งออกจากพีซีของฉันตามปกติ
  • บนเซิร์ฟเวอร์ DigitalOcean ตรวจพบเพียงแพ็กเก็ตแรกเท่านั้น
  • หลังจากนั้นแพ็กเก็ตถูก บล็อกอยู่ที่ไหนสักแห่ง (NAT, ไฟร์วอลล์, ISP ฯลฯ)

การวิเคราะห์สาเหตุ

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

ทดลองซ้ำบน AWS

• มีการทดลองซ้ำโดยใช้อินสแตนซ์สองเครื่องบน AWS
• ภายในดาต้าเซ็นเตอร์เดียวกัน แพ็กเก็ต HDP รับส่งได้ตามปกติ
• แต่เมื่อส่งผ่านอินเทอร์เน็ต ก็เกิดปัญหาแบบเดียวกับ DigitalOcean คือ มีเพียงแพ็กเก็ตแรกเท่านั้นที่ไปถึง

ประเด็นสำคัญ

• NAT (Network Address Translation): ทำงานบนพื้นฐานของพอร์ต TCP/UDP จึงไม่มีวิธีรองรับโปรโตคอลใหม่อย่าง HDP
• ไฟร์วอลล์/การกรองเครือข่าย: ISP และผู้ให้บริการคลาวด์ส่วนใหญ่ บล็อก IP protocol ที่ไม่ได้รับอนุญาต
• ปัญหาด้านการปรับแต่งของอุปกรณ์เครือข่าย: อุปกรณ์บางชนิดอาจทิ้งแพ็กเก็ตที่ไม่เป็นมาตรฐานทันที

บทสรุป: การใช้ TCP และ UDP ยังคงดีที่สุด

• การติดตั้งใช้งาน network stack ของแต่ละ OS แตกต่างกัน
  • วิธีทำงานของ socket() บน Linux, macOS และ Windows ไม่เหมือนกัน
• ไฟร์วอลล์และอุปกรณ์ NAT บล็อกโปรโตคอลที่ไม่เป็นมาตรฐาน
  • แม้จะทำงานได้ในเครือข่ายส่วนตัว แต่บนอินเทอร์เน็ตแทบเป็นไปไม่ได้
• ไม่มีผลด้านประสิทธิภาพที่ดีขึ้น
  • มีทางเลือกที่ผ่านการพิสูจน์แล้วอยู่ก่อน เช่น QUIC ที่พัฒนาบนพื้นฐานของ UDP
• ควรใช้ TCP/UDP
  • หากใช้ โปรโตคอลมาตรฐาน ระบบจะรองรับ NAT แบบอิงพอร์ต ไฟร์วอลล์ และการเราต์โดยอัตโนมัติ

เอกสารเพิ่มเติม

• ข้อกำหนดโปรโตคอล UDP
• รายการหมายเลข IP protocol
• ความแตกต่างของ Raw socket บนแต่ละแพลตฟอร์ม

[junhochoi]

น่าจะช่วยได้ถ้าลองอ่าน https://www.saturnsoft.net/network/2019/03/21/quic-http3-1/ ด้วยครับ

[secret3056]

จำได้ว่าเมื่อก่อนตอนเล่น StarCraft แบบหลายคนผ่าน Hamachi มี IPX อยู่ด้วย ตอนนั้นก็จำได้ว่าสงสัยมากเลยว่านี่มันคืออะไรกันแน่

[secret3056]

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

[tujuc]

โอ้โห เป็นความพยายามที่ดีนะ...
แม้จะเป็นความพยายามที่ดีในการเขย่ารากฐานของเครือข่าย แต่เพราะอุปกรณ์เครือข่ายทั้งหมดบนโลกนี้มีแต่ที่ออกแบบมาเฉพาะสำหรับ TCP/UDT เท่านั้น...

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

[GN⁺]

ความเห็นจาก Hacker News

• มี SCTP ซึ่งเป็นโปรโตคอลเก่าที่ดีกว่า TCP แต่ไม่ได้ถูกรับไปใช้
  • เพราะฮาร์ดแวร์เครือข่ายบล็อกทุกอย่างที่ไม่ใช่ TCP และ UDP
• ในฐานะคนที่เคยทำโปรโตคอลขนส่งหลายแบบ อุปสรรคใหญ่ที่สุดของการวางเลเยอร์บน IP ไม่ใช่เราเตอร์ WAN แต่เป็นอุปกรณ์ NAT สำหรับผู้บริโภค
  • สำหรับเราเตอร์ Netgear บางรุ่น พบความเสียหายเฉพาะแบบที่ทราฟฟิกยังไปถึงปลายทางได้ แต่ 4 ไบต์แรกถูกเปลี่ยนเป็น 0
  • สงสัยว่านี่ถูกจัดการราวกับเป็น TCP/UDP แต่เส้นทางการแปลจริงไม่ได้ถูกตามไป
• หากไม่ใช้ TCP หรือ UDP การสื่อสารน่าจะทำได้ยาก
  • อินเทอร์เน็ตยึด TCP และ UDP เป็นมาตรฐาน
  • มีอุปกรณ์จำนวนมากที่ไม่สามารถจัดการโปรโตคอลอื่นได้
  • การเปลี่ยนฮาร์ดแวร์อินเทอร์เน็ตทั้งหมดน่าจะใช้เวลานานกว่าการเลิกใช้ IPv4 เสียอีก
  • ต้องมีข้อได้เปรียบอย่างมากของโปรโตคอลใหม่จริง ๆ บริษัทและรัฐบาลทั้งหมดจึงจะยอมลงทุนสูงเพื่อทำรองรับ
• ตอนจบของบทความให้ความรู้สึกเหมือนทิ้งค้างไว้แบบ cliffhanger
  • อยากรู้ว่าทำไมมีเพียงแพ็กเก็ตเดียวของโปรโตคอลแบบกำหนดเองที่ผ่านไปได้ ส่วนที่เหลือกลับถูกทิ้ง
• เคยคิดว่าแพ็กเก็ต TCP/UDP จะถูกส่งโดยสแตกเครือข่ายของ OS ไปยังเฉพาะโปรเซสที่ฟังพอร์ตนั้นอยู่เท่านั้น
  • นี่อาจเป็นฟีเจอร์ด้านความปลอดภัย และโปรเซสที่ไม่มีสิทธิ์อาจฟังบางพอร์ตไม่ได้
  • ไม่คิดว่าโปรเซสอื่นจะสามารถดักจับทราฟฟิกทั้งหมดได้
  • ไม่เคยรู้ว่าสามารถดักจับทราฟฟิกจากโปรโตคอลชั้นขนส่งหลายแบบได้
  • system call ที่เกี่ยวข้องน่าจะต้องใช้สิทธิ์สูง
• สงสัยว่าถ้าวันนี้มีการออกแบบอินเทอร์เน็ตโปรโตคอลและอุปกรณ์เราต์ติงขึ้นใหม่ตั้งแต่ต้น จะออกมาเป็นอย่างไร
  • น่าจะมีแพ็กเก็ตที่ใหญ่กว่ามาก และมีโปรโตคอลพื้นฐานสไตล์ UDP มาแทน HTTP
  • โปรโตคอลสตรีมมิงแบบเรียบง่ายน่าจะมาแทน TCP และรองรับการเล่นวิดีโอ
  • โปรโตคอลทั้งสองนี้น่าจะจัดการทราฟฟิกส่วนใหญ่ได้อย่างมีประสิทธิภาพมากกว่า
• เป็นสมมติฐานแบบ "ถ้าจะประดิษฐ์ล้อขึ้นมาใหม่จะเป็นอย่างไร?"
• ต้องใช้ packet socket
  • เครือข่าย IP ควรส่งต่อทุกอย่างได้ แต่ NAT คือปัญหาหลัก
  • น่าสนใจที่จะลองกับ IPv6
• คงจะใช้โปรโตคอลอื่นจากยุคก่อนที่ TCP/UDP/IP จะครองทุกอย่าง
• ทุกคนคงใช้ UUCP
  • มันเคยทำงานคล้ายกันมาก่อนยุค TCP/UDP