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