Chrome เพิ่มการรองรับการทดลองสำหรับโปรโตคอล HTTP/3

สู่การทดลองสร้าง Chrome Canary เพิ่ม รองรับโปรโตคอล HTTP/3 ซึ่งใช้โปรแกรมเสริมเพื่อเปิดใช้งาน HTTP เพื่อทำงานบนโปรโตคอล QUIC โปรโตคอล QUIC นั้นถูกเพิ่มลงในเบราว์เซอร์เมื่อห้าปีที่แล้ว และตั้งแต่นั้นมาก็ถูกนำมาใช้เพื่อเพิ่มประสิทธิภาพการทำงานกับบริการของ Google ในขณะเดียวกัน เวอร์ชัน QUIC จาก Google ที่ใช้ใน Chrome ก็มีรายละเอียดบางอย่างแตกต่างจากเวอร์ชันนั้น ข้อมูลจำเพาะ IETF แต่ตอนนี้การใช้งานได้รับการซิงโครไนซ์แล้ว

HTTP/3 ทำให้การใช้ QUIC เป็นการขนส่งสำหรับ HTTP/2 เป็นมาตรฐาน เพื่อเปิดใช้งานตัวเลือก HTTP/3 และ QUIC จาก 23 ร่าง ข้อกำหนด IETF กำหนดให้ Chrome เปิดตัวด้วยตัวเลือก "-enable-quic -quic-version=h3-23" จากนั้นเมื่อเปิดไซต์ทดสอบ รวดเร็ว.หิน:4433 ในโหมดการตรวจสอบเครือข่ายในเครื่องมือสำหรับนักพัฒนา กิจกรรม HTTP/3 จะแสดงเป็น “http/2+quic/99”

จำได้ว่าโปรโตคอล QUIC (การเชื่อมต่ออินเทอร์เน็ต UDP ด่วน) ได้รับการพัฒนาโดย Google ตั้งแต่ปี 2013 เป็นทางเลือกแทนการรวม TCP+TLS สำหรับเว็บ แก้ไขปัญหาเกี่ยวกับการตั้งค่าที่ยาวนานและเวลาการเจรจาสำหรับการเชื่อมต่อใน TCP และขจัดความล่าช้าเมื่อแพ็กเก็ตสูญหายระหว่างการถ่ายโอนข้อมูล QUIC เป็นส่วนขยายของโปรโตคอล UDP ที่รองรับมัลติเพล็กซ์ของการเชื่อมต่อหลายรายการ และมีวิธีการเข้ารหัสที่เทียบเท่ากับ TLS/SSL โปรโตคอลที่เป็นปัญหาได้รวมเข้ากับโครงสร้างพื้นฐานเซิร์ฟเวอร์ของ Google แล้ว และเป็นส่วนหนึ่งของ Chrome กำหนด เพื่อรวมไว้ใน Firefox และถูกใช้อย่างแข็งขันเพื่อให้บริการตามคำขอของลูกค้าบนเซิร์ฟเวอร์ของ Google

หลัก คุณสมบัติ ด่วน:

• ความปลอดภัยสูงคล้ายกับ TLS (โดยพื้นฐานแล้ว QUIC ให้ความสามารถในการใช้ TLS ผ่าน UDP)
• การควบคุมความสมบูรณ์ของโฟลว์ ป้องกันการสูญเสียแพ็กเก็ต
• ความสามารถในการสร้างการเชื่อมต่อได้ทันที (0-RTT ในกรณีประมาณ 75% สามารถส่งข้อมูลได้ทันทีหลังจากส่งแพ็กเก็ตการตั้งค่าการเชื่อมต่อ) และให้ความล่าช้าน้อยที่สุดระหว่างการส่งคำขอและรับการตอบกลับ (RTT, Round Trip Time)
• ไม่ใช้หมายเลขลำดับเดียวกันเมื่อส่งแพ็กเก็ตอีกครั้ง ซึ่งหลีกเลี่ยงความคลุมเครือในการระบุแพ็กเก็ตที่ได้รับและกำจัดการหมดเวลา
• การสูญเสียแพ็กเก็ตส่งผลต่อการส่งกระแสข้อมูลที่เกี่ยวข้องเท่านั้นและไม่ได้หยุดการส่งข้อมูลในสตรีมแบบขนานที่ส่งผ่านการเชื่อมต่อปัจจุบัน
• คุณสมบัติการแก้ไขข้อผิดพลาดที่ลดความล่าช้าเนื่องจากการส่งสัญญาณซ้ำของแพ็กเก็ตที่สูญหาย การใช้รหัสแก้ไขข้อผิดพลาดพิเศษในระดับแพ็กเก็ตเพื่อลดสถานการณ์ที่ต้องส่งข้อมูลแพ็กเก็ตที่สูญหายอีกครั้ง
• ขอบเขตของบล็อกการเข้ารหัสนั้นสอดคล้องกับขอบเขตของแพ็กเก็ต QUIC ซึ่งช่วยลดผลกระทบของการสูญเสียของแพ็กเก็ตในการถอดรหัสเนื้อหาของแพ็กเก็ตที่ตามมา
• ไม่มีปัญหากับการบล็อกคิว TCP
• รองรับตัวระบุการเชื่อมต่อ ซึ่งช่วยลดเวลาที่ใช้ในการสร้างการเชื่อมต่อใหม่สำหรับไคลเอนต์มือถือ
• ความเป็นไปได้ในการเชื่อมต่อกลไกการควบคุมความแออัดของการเชื่อมต่อขั้นสูง
• ใช้เทคนิคการพยากรณ์ปริมาณงานต่อทิศทางเพื่อให้แน่ใจว่าแพ็กเก็ตจะถูกส่งในอัตราที่เหมาะสม เพื่อป้องกันไม่ให้แพ็กเก็ตหนาแน่นและทำให้แพ็กเก็ตสูญหาย
• รับรู้ได้ การเจริญเติบโต ประสิทธิภาพและปริมาณงานเมื่อเทียบกับ TCP สำหรับบริการวิดีโอ เช่น YouTube นั้น QUIC แสดงให้เห็นว่าสามารถลดการตอบกลับเมื่อดูวิดีโอได้ 30%

ที่มา: opennet.ru