HTTP/3 และ QUIC: ทำความเข้าใจและผลกระทบต่อ API
เจาะลึก HTTP/3 และโปรโตคอล QUIC บน UDP พร้อม 4 ดีไซน์หลักและการเปลี่ยนแปลงความเร็ว ผลกระทบต่อ REST และ gRPC ตามมาตรฐาน RFC 9000 และ 9114
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- HTTP/3 ทำงานบนโปรโตคอล QUIC โดยพัฒนาต่อยอดขึ้นมาจาก UDP
- ช่วยแก้ปัญหา Head-of-line blocking ระดับ Transport ที่เคยเกิดขึ้นใน TCP
- รองรับการย้ายเครือข่ายจาก Wi-Fi ไปยัง 5G ได้ทันทีผ่าน Connection ID
- เหมาะสำหรับ REST API สาธารณะและอุปกรณ์เคลื่อนที่ แต่ gRPC ยังต้องใช้ HTTP/2 ต่อไป
ทุกคำขอ HTTP ที่ให้บริการผ่าน API มักทำงานอยู่บนเลเยอร์ Transport ที่นักพัฒนาส่วนใหญ่มักมองข้าม โดยตลอดช่วง 25 ปีที่ผ่านมา มาตรฐานหลักคือ TCP ก่อนที่ Google จะพัฒนา QUIC ขึ้นมาบน UDP และทาง IETF ได้ผลักดันให้กลายเป็นมาตรฐานสากล ส่งผลให้ HTTP/3 ถูกออกแบบมาให้ทำงานบนโปรโตคอล QUIC นี้โดยเฉพาะ
การเปลี่ยนแปลงดังกล่าวส่งผลโดยตรงต่อความเร็วในการเชื่อมต่อ API ความเสถียรบนเครือข่ายมือถือ และวิธีการที่คำขอแบบขนานใช้ร่วมกัน หากคุณกำลังออกแบบหรือดูแลระบบ API การทำความเข้าใจความเปลี่ยนแปลง สิ่งที่ยังคงเหมือนเดิม และวิธีการตรวจสอบโปรโตคอลของปลายทางจึงเป็นสิ่งสำคัญอย่างยิ่ง
สิ่งที่ไม่เคยเปลี่ยนแปลงเลยใน HTTP/1.1, HTTP/2 และ HTTP/3 คือ Semantics ของ API ซึ่งได้แก่ คำขอ การตอบกลับ รหัสสถานะ Header และ Payload แบบ JSON โดยเครื่องมือต่างๆ เช่น Apidog ยังคงสามารถใช้งานเพื่อทดสอบและดีบักพฤติกรรมของ Endpoint ได้เหมือนเดิมไม่ว่าอินฟราเรดสตรัคเจอร์ของคุณจะเจรจาต่อรองใช้เวอร์ชันใดก็ตาม
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
QUIC คือโปรโตคอล Transport ที่ได้รับการกำหนดมาตรฐานใน RFC 9000 โดยทำงานบน UDP แทน TCP และสร้างฟีเจอร์ความน่าเชื่อถือ การจัดลำดับ รวมถึงการควบคุมความหนาแน่นใน User Space พร้อมทั้งฝังการเข้ารหัส TLS 1.3 มาให้ตั้งแต่แพ็กเก็ตแรก
- แก้ปัญหาการพัฒนา TCP ที่ติดขัดใน Kernel และ Middlebox ด้วยการสร้างเลเยอร์ความน่าเชื่อถือบน UDP
- รวมการจับมือเชื่อมต่อ TCP และ TLS เข้าด้วยกันเพื่อให้พร้อมใช้งานได้ภายใน One Round Trip
- กำจัดปัญหา Head-of-line blocking ด้วยการแยกหลาย Stream ภายในเชื่อมต่อเดียว
- ใช้ Connection ID เพื่อให้สลับเครือข่ายระหว่าง Wi-Fi และ 5G ได้โดยไม่ต้องเริ่มเชื่อมต่อใหม่
การเปลี่ยนผ่านจาก TCP สู่ QUIC และ HTTP/3 ถือเป็นการยกระดับสถาปัตยกรรมเว็บครั้งใหญ่ในรอบหลายทศวรรษ เนื่องจาก TCP ถูกฝังไว้ในระดับระบบปฏิบัติการซึ่งอัปเกรดได้ยาก การย้ายตรรกะการเชื่อมมาไว้ใน User Space ผ่าน QUIC จึงช่วยให้วงจรการพัฒนาเครือข่ายมีความยืดหยุ่นสูงขึ้นอย่างเห็นได้ชัด
ในส่วนของ HTTP/3 ซึ่งระบุไว้ใน RFC 9114 จะทำการแมป Semantics ของ HTTP เข้ากับ Stream ของ QUIC โดยเมธอด Header รหัสสถานะ และ Body จะยังคงเดิม แต่รูปแบบ Wire และ Transport จะแตกต่างออกไปอย่างสิ้นเชิง
"Jika Anda mengaktifkan 0-RTT di edge, pastikan permintaan non-idempoten dikecualikan atau pastikan CDN Anda menangani pembatasan tersebut."
Dev.to
ฟีเจอร์ 0-RTT เป็นอีกจุดที่ต้องระวัง เมื่อไคลเอนต์เชื่อมต่อกลับไปยังเซิร์ฟเวอร์ที่เคยรู้จัก QUIC สามารถส่งข้อมูลแอปพลิเคชันได้ตั้งแต่แพ็กเก็ตแรกก่อนการจับมือจะเสร็จสิ้น แต่เนื่องจากข้อมูลอาจถูกดักจับและเล่นซ้ำได้ เซิร์ฟเวอร์จึงควรยอมรับเฉพาะคำขอแบบ Idempotent เท่านั้น
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น