Mozilla ได้ประกาศความตั้งใจที่จะเริ่มเฟสใน HTTP/3 และ QUIC ด้วยการเปิดตัว Firefox 88 ซึ่งมีกำหนดในวันที่ 19 เมษายน (เดิมทีคาดว่าจะวางจำหน่ายในวันที่ 20 เมษายน แต่เมื่อพิจารณาจากกำหนดการแล้ว จะถูกเลื่อนไปหนึ่งวัน) . การสนับสนุน HTTP/3 จะเปิดใช้งานสำหรับผู้ใช้เพียงไม่กี่เปอร์เซ็นต์ในตอนแรก และจะเผยแพร่ให้กับทุกคนภายในสิ้นเดือนพฤษภาคม ยกเว้นปัญหาที่ไม่คาดคิด ในเวอร์ชันกลางคืนและเวอร์ชันเบต้า HTTP/3 จะถูกเปิดใช้งานตามค่าเริ่มต้นเมื่อปลายเดือนมีนาคม
ให้เราระลึกว่าการใช้งาน HTTP/3 ใน Firefox ขึ้นอยู่กับโครงการ neqo ที่พัฒนาโดย Mozilla ซึ่งจัดให้มีการใช้งานไคลเอ็นต์และเซิร์ฟเวอร์สำหรับโปรโตคอล QUIC รหัสส่วนประกอบสำหรับการสนับสนุน HTTP/3 และ QUIC เขียนด้วยภาษา Rust หากต้องการควบคุมว่าจะเปิดใช้งาน HTTP/3 หรือไม่ about:config จะมีตัวเลือก “network.http.http3.enabled” จากซอฟต์แวร์ไคลเอ็นต์ ยังมีการเพิ่มการสนับสนุนการทดลองสำหรับ HTTP/3 ลงใน Chrome และ Curl และสำหรับเซิร์ฟเวอร์นั้น มีให้บริการใน nginx เช่นเดียวกับในรูปแบบของโมดูล nginx และเซิร์ฟเวอร์ทดสอบจาก Cloudflare ทางด้านเว็บไซต์ มีการรองรับ HTTP/3 บนเซิร์ฟเวอร์ Google และ Facebook อยู่แล้ว
โปรโตคอล HTTP/3 ยังอยู่ในขั้นตอนข้อกำหนดฉบับร่างและยังไม่ได้รับการรับรองมาตรฐานโดย IETF อย่างสมบูรณ์ HTTP/3 ต้องการการสนับสนุนไคลเอนต์และเซิร์ฟเวอร์สำหรับเวอร์ชันเดียวกันของมาตรฐานร่าง QUIC และ HTTP/3 ซึ่งระบุไว้ในส่วนหัว Alt-Svc (Firefox รองรับร่างข้อมูลจำเพาะ 27 ถึง 32)
HTTP/3 กำหนดการใช้โปรโตคอล QUIC เป็นการส่งข้อมูลสำหรับ HTTP/2 โปรโตคอล QUIC (การเชื่อมต่ออินเทอร์เน็ต UDP ด่วน) ได้รับการพัฒนาโดย Google ตั้งแต่ปี 2013 โดยเป็นทางเลือกแทนชุด TCP+TLS สำหรับเว็บ แก้ปัญหาการตั้งค่าที่ยาวนานและเวลาการเจรจาต่อรองสำหรับการเชื่อมต่อใน TCP และขจัดความล่าช้าเมื่อแพ็กเก็ตสูญหายระหว่างข้อมูล โอนย้าย. QUIC เป็นส่วนขยายของโปรโตคอล UDP ที่รองรับมัลติเพล็กซ์ของการเชื่อมต่อหลายรายการ และมีวิธีการเข้ารหัสที่เทียบเท่ากับ TLS/SSL ในระหว่างการพัฒนามาตรฐาน IETF มีการเปลี่ยนแปลงโปรโตคอล ซึ่งนำไปสู่การเกิดขึ้นของสาขาคู่ขนานสองสาขา สาขาหนึ่งสำหรับ HTTP/3 และสาขาที่สองรองรับโดย Google (Chrome รองรับทั้งสองตัวเลือก)
คุณสมบัติที่สำคัญของ QUIC:
- ความปลอดภัยสูงคล้ายกับ TLS (โดยพื้นฐานแล้ว QUIC ให้ความสามารถในการใช้ TLS ผ่าน UDP)
- การควบคุมความสมบูรณ์ของโฟลว์ ป้องกันการสูญเสียแพ็กเก็ต
- ความสามารถในการสร้างการเชื่อมต่อได้ทันที (0-RTT ในกรณีประมาณ 75% สามารถส่งข้อมูลได้ทันทีหลังจากส่งแพ็กเก็ตการตั้งค่าการเชื่อมต่อ) และให้ความล่าช้าน้อยที่สุดระหว่างการส่งคำขอและรับการตอบกลับ (RTT, Round Trip Time)
- การใช้หมายเลขลำดับที่แตกต่างกันเมื่อส่งแพ็กเก็ตอีกครั้ง ซึ่งหลีกเลี่ยงความคลุมเครือในการระบุแพ็กเก็ตที่ได้รับและกำจัดการหมดเวลา
- การสูญเสียแพ็กเก็ตส่งผลต่อการส่งกระแสข้อมูลที่เกี่ยวข้องเท่านั้นและไม่ได้หยุดการส่งข้อมูลในสตรีมแบบขนานที่ส่งผ่านการเชื่อมต่อปัจจุบัน
- คุณสมบัติการแก้ไขข้อผิดพลาดที่ลดความล่าช้าเนื่องจากการส่งสัญญาณซ้ำของแพ็กเก็ตที่สูญหาย การใช้รหัสแก้ไขข้อผิดพลาดพิเศษในระดับแพ็กเก็ตเพื่อลดสถานการณ์ที่ต้องส่งข้อมูลแพ็กเก็ตที่สูญหายอีกครั้ง
- ขอบเขตของบล็อกการเข้ารหัสนั้นสอดคล้องกับขอบเขตของแพ็กเก็ต QUIC ซึ่งช่วยลดผลกระทบของการสูญเสียของแพ็กเก็ตในการถอดรหัสเนื้อหาของแพ็กเก็ตที่ตามมา
- ไม่มีปัญหากับการบล็อกคิว TCP
- รองรับตัวระบุการเชื่อมต่อ ซึ่งช่วยลดเวลาที่ใช้ในการสร้างการเชื่อมต่อใหม่สำหรับไคลเอนต์มือถือ
- ความเป็นไปได้ในการเชื่อมต่อกลไกการควบคุมความแออัดของการเชื่อมต่อขั้นสูง
- ใช้เทคนิคการพยากรณ์ปริมาณงานต่อทิศทางเพื่อให้แน่ใจว่าแพ็กเก็ตจะถูกส่งในอัตราที่เหมาะสม เพื่อป้องกันไม่ให้แพ็กเก็ตหนาแน่นและทำให้แพ็กเก็ตสูญหาย
- ประสิทธิภาพและปริมาณงานเพิ่มขึ้นอย่างมากเมื่อเทียบกับ TCP สำหรับบริการวิดีโอ เช่น YouTube นั้น QUIC แสดงให้เห็นว่าสามารถลดการตอบกลับเมื่อดูวิดีโอได้ 30%
ที่มา: opennet.ru