เมื่อเร็ว ๆ นี้ IETF (Internet Engineering Task Force) ซึ่งพัฒนาโปรโตคอลและสถาปัตยกรรมของอินเทอร์เน็ต ทำให้เป็นที่รู้จัก ข่าวที่ เสร็จสิ้นการก่อตัวของ RFC สำหรับโปรโตคอล HTTP/3.0 และเผยแพร่ข้อกำหนดที่เกี่ยวข้องภายใต้ตัวระบุ RFC 9114 และ RFC 9204
ข้อมูลจำเพาะ HTTP/3.0 ได้รับสถานะ “มาตรฐานที่เสนอ” หลังจากนั้นงานจะเริ่มให้ RFC มีสถานะของร่างมาตรฐาน (Draft Standard) ซึ่งจริง ๆ แล้วหมายถึงการรักษาเสถียรภาพของโปรโตคอลอย่างสมบูรณ์และคำนึงถึงความคิดเห็นทั้งหมดที่ทำ
โปรโตคอล HTTP/3 กำหนดการใช้โปรโตคอล QUIC (การเชื่อมต่ออินเทอร์เน็ต UDP ด่วน) เป็นการขนส่งสำหรับ HTTP/2 QUIC เป็นปลั๊กอินของโปรโตคอล UDP ที่รองรับการเชื่อมต่อแบบมัลติเพล็กซ์และมีวิธีการเข้ารหัสที่เทียบเท่ากับ TLS/SSL
โปรโตคอลถูกสร้างขึ้นในปี 2013 โดย Google เป็นทางเลือกแทน TCP + TLS สำหรับเว็บ ซึ่งช่วยแก้ปัญหาการตั้งค่าการเชื่อมต่อที่ยาวนานและเวลาในการเจรจาใน TCP และขจัดความล่าช้าเนื่องจากแพ็กเก็ตสูญหายระหว่างการถ่ายโอนข้อมูล
ปัจจุบัน รองรับ QUIC และ HTTP/3.0 แล้วในเบราว์เซอร์ทั้งหมด เว็บไซต์ยอดนิยม ทางฝั่งเซิร์ฟเวอร์ การใช้งาน HTTP/3 นั้นมีให้สำหรับ nginx (ในสาขาที่แยกจากกันและเป็นโมดูลที่แยกจากกัน), Caddy , IIS และ LiteSpeed HTTP/3 ยังได้รับการสนับสนุนโดยเครือข่ายการจัดส่งเนื้อหาของ Cloudflare
คุณสมบัติหลักของ QUIC:
- ความปลอดภัยสูง คล้ายกับ TLS (อันที่จริง QUIC ให้ความสามารถในการใช้ TLS บน UDP)
- การควบคุมความสมบูรณ์ของการส่งเพื่อป้องกันการสูญหายของแพ็กเก็ต
- ความสามารถในการสร้างการเชื่อมต่อทันทีและทำให้เกิดความล่าช้าน้อยที่สุดระหว่างการส่งคำขอและรับการตอบกลับ (RTT, เวลาไปกลับ)
- ใช้หมายเลขลำดับอื่นเมื่อส่งแพ็กเก็ตอีกครั้ง ช่วยให้คุณหลีกเลี่ยงความกำกวมเมื่อกำหนดแพ็กเก็ตที่ได้รับและกำจัดการหมดเวลา
- การสูญเสียแพ็กเก็ตจะส่งผลต่อการส่งเฉพาะสตรีมที่เชื่อมโยงกับแพ็กเก็ตและไม่ได้หยุดการส่งข้อมูลในสตรีมที่ส่งแบบขนานผ่านการเชื่อมต่อปัจจุบัน
- เครื่องมือแก้ไขข้อผิดพลาดที่ลดความล่าช้าเนื่องจากการส่งข้อมูลซ้ำของแพ็กเก็ตที่สูญหาย การใช้รหัสแก้ไขข้อผิดพลาดระดับแพ็กเก็ตพิเศษเพื่อลดสถานการณ์ที่ต้องส่งข้อมูลแพ็กเก็ตที่สูญหายอีกครั้ง
- ขอบเขตบล็อกการเข้ารหัสสอดคล้องกับขอบเขตแพ็กเก็ต QUIC ซึ่งช่วยลดผลกระทบของการสูญเสียแพ็กเก็ตในการถอดรหัสเนื้อหาของแพ็กเก็ตที่ตามมา
- ไม่มีปัญหากับการบล็อกคิว TCP
- รองรับการระบุการเชื่อมต่อเพื่อลดเวลาในการเชื่อมต่อใหม่สำหรับไคลเอนต์มือถือ
- ความเป็นไปได้ในการเชื่อมต่อกลไกขั้นสูงสำหรับการควบคุมการโอเวอร์โหลดการเชื่อมต่อ
- ใช้เทคนิคการคาดคะเนแบนด์วิดธ์ในแต่ละทิศทางเพื่อให้แน่ใจว่าอัตราการส่งต่อแพ็กเก็ตจะเหมาะสมที่สุด หลีกเลี่ยงสภาวะความแออัดที่แพ็กเก็ตสูญหาย
- ประสิทธิภาพที่โดดเด่นและประสิทธิภาพที่เพิ่มขึ้นเหนือ TCP สำหรับบริการวิดีโอเช่น YouTube QUIC ช่วยลดการดำเนินการบัฟเฟอร์วิดีโอลง 30%
นอกจากนี้ ในเวลาเดียวกัน เวอร์ชันที่อัปเดตของข้อกำหนดสำหรับโปรโตคอล HTTP/1.1 (RFC 9112) และ HTTP/2.0 (RFC 9113) ก็ได้รับการเผยแพร่ ตลอดจนเอกสารที่กำหนดความหมายของคำขอ HTTP (RFC) 9110) และส่วนหัวควบคุมการแคช HTTP (RFC 9111)
จากการเปลี่ยนแปลงใน ข้อมูลจำเพาะ HTTP/1.1 คุณสามารถสังเกตเห็นการแบน จากการใช้อักขระขึ้นบรรทัดใหม่แยกกัน (CR) นอกกายกับเนื้อหากล่าวคือ ในองค์ประกอบโปรโตคอล สามารถใช้อักขระ CR ร่วมกับอักขระขึ้นบรรทัดใหม่ (CRLF) เท่านั้น
El อัลกอริทึมเค้าโครงคำขอที่กระจัดกระจายได้รับการปรับปรุง เพื่อลดความซับซ้อนในการแยกฟิลด์และส่วนที่แนบมาด้วยส่วนหัว เพิ่มแนวทางในการจัดการเนื้อหาที่คลุมเครือเพื่อบล็อกการโจมตีคลาส "HTTP Request Smuggling" ที่สามารถบุกรุกเนื้อหาของคำขอของผู้ใช้รายอื่นในโฟลว์ระหว่างส่วนหน้าและส่วนหลัง
การปรับปรุงข้อกำหนด HTTP/2.0 กำหนดการสนับสนุน TLS 1.3 อย่างชัดเจน รูปแบบการจัดลำดับความสำคัญที่เลิกใช้แล้วและฟิลด์ส่วนหัวที่เกี่ยวข้องและกลไกการอัปเดต เลิกใช้การเชื่อมต่อ HTTP/1.1 แล้ว
สุดท้ายนี้ หากสนใจอยากทราบข้อมูลเพิ่มเติม สามารถเข้าไปดูรายละเอียดใน ลิงค์ต่อไปนี้