ประสิทธิภาพ TLS: QUIC และ HTTP/3

HTTP/2 รวมช่องข้อมูลหลายช่องไว้ในการเชื่อมต่อ TCP เดียว จึงแก้ปัญหาการปิดกั้นที่หัวแถวต่อการเชื่อมต่อของ HTTP/1.1 ได้ อย่างไรก็ตาม TCP เองทำให้เกิดการปิดกั้นที่หัวแถวในชั้นขนส่ง หากส่วนข้อมูล TCP หนึ่งส่วนสูญหาย ข้อมูลทั้งหมดที่อยู่ถัดไปในคิวจะต้องรอการส่งซ้ำ ทำให้ช่องข้อมูล HTTP/2 ทั้งหมดถูกปิดกั้นพร้อมกัน การสูญเสียแพ็กเก็ต 1% อาจทำให้ประสิทธิภาพของ HTTP/2 แย่กว่า HTTP/1.1 ที่ใช้การเชื่อมต่อหลายชุด QUIC (การเชื่อมต่ออินเทอร์เน็ตผ่าน UDP แบบรวดเร็ว) แก้ปัญหานี้ด้วยการใช้ช่องข้อมูลหลายช่องบน UDP โดยการกู้คืนข้อมูลที่สูญหายในระดับช่องข้อมูลจะไม่ปิดกั้นช่องข้อมูลอื่น

QUIC เป็นโพรโทคอลชั้นขนส่งที่สร้างบน UDP พัฒนาโดย Google (2012-2015) และทำให้เป็นมาตรฐานโดย IETF ในเอกสาร RFC 9000 (2021) QUIC ผสาน TLS 1.3 เข้ากับชั้นขนส่ง จึงไม่มีการจับมือ TLS แยกต่างหากบน QUIC แต่ TLS ถูกรวมอยู่ในกระบวนการจับมือของ QUIC เอง QUIC มีความสามารถดังนี้: ช่องข้อมูลหลายช่องที่ไม่เกิดการปิดกั้นที่หัวแถว การย้ายการเชื่อมต่อ (รักษาการเชื่อมต่อไว้เมื่อเปลี่ยนเครือข่าย เช่น จาก WiFi เป็น LTE) การสร้างการเชื่อมต่อแบบ 0-RTT สำหรับการเชื่อมต่อซ้ำ และการตรวจจับข้อมูลสูญหายกับการควบคุมความแออัดในตัว HTTP/3 (RFC 9114) คือความหมายของ HTTP ที่ทำงานบนช่องข้อมูล QUIC

การจับมือ QUIC รวมการสร้างการเชื่อมต่อเข้ากับการเจรจา TLS ในการส่งชุดแรก (0 RTT ตามศัพท์ของ QUIC) ไคลเอ็นต์จะส่งแพ็กเก็ตเริ่มต้นที่มี TLS ClientHello เซิร์ฟเวอร์ตอบกลับด้วยแพ็กเก็ตเริ่มต้นของตนเอง (ServerHello) พร้อมแพ็กเก็ตจับมือที่มีส่วนขยายที่เข้ารหัส ใบรับรอง และข้อความเสร็จสิ้น จากนั้นไคลเอ็นต์จะส่งข้อความเสร็จสิ้นของการจับมือ และพร้อมส่งข้อมูลแอปพลิเคชัน นี่คือการจับมือแบบ 1-RTT สำหรับการเชื่อมต่อแบบ 0-RTT ไคลเอ็นต์จะส่งแพ็กเก็ต 0-RTT ซึ่งเป็นข้อมูลแอปพลิเคชันไปพร้อมกับ ClientHello โดยใช้กุญแจที่สร้างจากความลับสำหรับการกลับมาใช้เซสชันเดิม ซึ่งทำให้เซสชันที่เก็บไว้สามารถเชื่อมต่อได้โดยไม่ต้องเดินทางไปกลับเพิ่มเติม

QUIC ใช้ระดับการเข้ารหัสที่แตกต่างกันสี่ระดับ ซึ่งสอดคล้องกับช่วงต่าง ๆ ของลำดับการสร้างกุญแจ TLS ได้แก่ ระดับเริ่มต้น (AEAD ที่สร้างจาก QUIC โดยใช้กุญแจค่าคงที่ที่ทราบกันอยู่ ให้ความถูกต้องครบถ้วนของข้อมูล แต่ไม่รักษาความลับจากผู้โจมตีที่มีความสามารถสูง) ระดับจับมือ (สร้างจาก TLS handshake_secret ให้การรักษาความลับแก่ข้อความการจับมือ TLS) ระดับ 0-RTT (สร้างจาก early_secret ของเซสชันก่อนหน้า ใช้เข้ารหัสข้อมูลแอปพลิเคชันแบบ 0-RTT) และระดับ 1-RTT (สร้างจาก TLS master_secret ใช้เข้ารหัสข้อมูลแอปพลิเคชันทั้งหมด) ส่วนหัว QUIC ถูกเข้ารหัสเพียงบางส่วน หมายเลขแพ็กเก็ตและข้อมูลบรรทุกถูกเข้ารหัส แต่ข้อมูลการกำหนดเส้นทางบางส่วน เช่น Connection ID ยังคงมองเห็นได้สำหรับตัวกระจายโหลด

การเชื่อมต่อ QUIC ระบุด้วย Connection ID (CID) แทนชุดค่าทั้งสี่ (IP ต้นทาง พอร์ตต้นทาง IP ปลายทาง พอร์ตปลายทาง) ทำให้การเชื่อมต่ออยู่ต่อได้เมื่อเครือข่ายเปลี่ยนแปลง เมื่อไคลเอ็นต์มือถือเปลี่ยนจาก WiFi เป็น LTE ที่อยู่ IP จะเปลี่ยน แต่ CID ยังคงเดิม ไคลเอ็นต์จะส่งเฟรม PATH_CHALLENGE บนเส้นทางใหม่ และเซิร์ฟเวอร์จะตอบกลับด้วย PATH_RESPONSE เพื่อยืนยันที่อยู่ใหม่ การเชื่อมต่อจึงดำเนินต่อได้อย่างราบรื่นโดยไม่ต้องเจรจาใหม่ TCP รองรับสิ่งนี้ไม่ได้ เนื่องจากการเชื่อมต่อ TCP ผูกกับชุดค่าทั้งสี่ และต้องสร้างใหม่เมื่อเครือข่ายเปลี่ยน ซึ่งจำเป็นต้องจับมือ TLS ใหม่ การย้ายการเชื่อมต่อของ QUIC ช่วยเพิ่มประสิทธิภาพที่ผู้ใช้มือถือรับรู้ได้อย่างมาก

HTTP/3 จับคู่ความหมายของ HTTP เข้ากับช่องข้อมูล QUIC แต่ละคู่คำขอและการตอบกลับ HTTP จะใช้ช่องข้อมูล QUIC แบบสองทิศทางแยกกัน ช่องข้อมูล QUIC ทำงานเป็นอิสระต่อกัน การสูญหายบนช่องข้อมูล 3 จะไม่ปิดกั้นช่องข้อมูล 7 HTTP/3 ใช้ QPACK สำหรับการบีบอัดส่วนหัว โดยมาแทนที่ HPACK ของ HTTP/2 และ QPACK ได้รับการออกแบบใหม่ให้ทำงานได้โดยไม่ต้องส่งข้อมูลตามลำดับ ช่องควบคุมแบบทิศทางเดียวโดยเฉพาะสองช่องใช้ส่งการตั้งค่าและคำสั่งของตัวถอดรหัสกับตัวเข้ารหัส การส่งข้อมูลล่วงหน้าจากเซิร์ฟเวอร์ใน HTTP/3 ใช้ช่องข้อมูลสำหรับการส่งข้อมูลล่วงหน้า ซึ่งเป็นช่องข้อมูลทิศทางเดียว ผลโดยรวมคือ HTTP/3 มีประสิทธิภาพเหนือกว่า HTTP/2 อย่างเด่นชัดที่สุดเมื่อเกิดการสูญเสียแพ็กเก็ต เช่น บนเครือข่ายมือถือหรือเส้นทางที่แออัด ซึ่งเป็นสภาวะที่การปิดกั้นที่หัวแถวของ TCP สร้างความเสียหายมากที่สุด

การวัดประสิทธิภาพของ QUIC และ HTTP/3 ในโลกจริงให้ผลแตกต่างกันตามสภาพเครือข่าย บนเครือข่ายคุณภาพสูง (เวลาแฝงต่ำและการสูญเสียแพ็กเก็ตต่ำ) HTTP/3 กับ HTTP/2 มีประสิทธิภาพใกล้เคียงกัน และค่าใช้จ่ายของ QUIC เช่น ส่วนหัวที่ใหญ่ขึ้นกับค่าใช้จ่ายในการประมวลผล UDP อาจทำให้ HTTP/3 ช้าลงเล็กน้อยด้วยซ้ำ บนเครือข่ายที่มีการสูญเสียแพ็กเก็ต (> 1% ซึ่งพบได้ทั่วไปบนเครือข่ายมือถือและดาวเทียม) HTTP/3 มีประสิทธิภาพเหนือกว่า HTTP/2 อย่างมาก Google รายงานว่าการเปลี่ยนไปใช้ QUIC ลดการหยุดบัฟเฟอร์แล้วโหลดใหม่ใน YouTube ได้ 7-8% Facebook (Meta) รายงานว่าเวลาแฝงของคำขอสำหรับฟีด Instagram ผ่าน QUIC ดีขึ้น 7-15% ผลลัพธ์ที่เห็นได้ชัดที่สุดอยู่ที่เวลาแฝงส่วนปลาย (p95, p99) ซึ่งการหยุดชะงักจากการส่ง TCP ซ้ำส่งผลกระทบมากที่สุด

การกระจายโหลด QUIC ซับซ้อนกว่า TCP เนื่องจาก QUIC ใช้ UDP และตัวกระจายโหลด UDP แบบไร้สถานะไม่สามารถรักษาความผูกพันของการเชื่อมต่อได้ เอกสารร่าง draft-ietf-quic-load-balancers ของ IETF กำหนดแนวทางหนึ่งไว้ว่า เซิร์ฟเวอร์จะเข้ารหัสข้อมูลการกำหนดเส้นทางไว้ใน Connection ID เพื่อให้ตัวกระจายโหลดส่งแพ็กเก็ตจากการเชื่อมต่อเดียวกันไปยังเซิร์ฟเวอร์เครื่องเดิมได้ โดยไม่ต้องติดตามสถานะของการเชื่อมต่อแต่ละรายการ Connection ID จะมีรหัสเซิร์ฟเวอร์ที่เข้ารหัสโดยใช้กุญแจร่วมระหว่างตัวกระจายโหลดกับเซิร์ฟเวอร์ Cloudflare, Fastly และ Nginx นำแนวทางนี้ไปใช้ในรูปแบบต่าง ๆ การทะลุผ่าน NAT เป็นข้อกังวลอีกประการหนึ่ง เนื่องจากการเชื่อมต่อ QUIC ต้องอยู่ต่อได้เมื่อ NAT ผูกที่อยู่ใหม่ ซึ่งจัดการโดยกลไกการย้ายการเชื่อมต่อ

เครือข่ายส่งเนื้อหารายใหญ่ได้นำ QUIC และ HTTP/3 ไปใช้งานในระดับใหญ่ Cloudflare ให้บริการ HTTP/3 ตั้งแต่ปี 2019 และรายงานว่าประมาณ 20% ของทราฟฟิกใช้ QUIC ในกรณีที่ทั้งไคลเอ็นต์และเซิร์ฟเวอร์รองรับ Fastly, Akamai และ AWS CloudFront รองรับ HTTP/3 ที่จุดให้บริการขอบเครือข่าย โครงสร้างพื้นฐานของ Google เอง ได้แก่ Search, YouTube และ Gmail ใช้ QUIC ภายในมาตั้งแต่ปี 2013 และเปิดให้ใช้งาน HTTP/3 ต่อสาธารณะ การนำไปใช้ในเครือข่ายส่งเนื้อหาได้รับประโยชน์จากการกลับมาใช้เซสชันแบบ 0-RTT ของ QUIC ผู้เยี่ยมชมซ้ำสามารถสร้างการเชื่อมต่อได้เร็วขึ้น และการย้ายการเชื่อมต่อช่วยเพิ่มประสิทธิภาพสำหรับผู้ใช้มือถือที่เคลื่อนย้ายระหว่างจุดเชื่อมต่อขณะรับเนื้อหา

การออกแบบของ QUIC ที่ใช้ UDP ทำให้เกิดข้อควรพิจารณาด้านความปลอดภัยเฉพาะประการ การโจมตีขยายปริมาณ: ผู้โจมตีสามารถปลอมแปลง IP ต้นทางและส่งแพ็กเก็ตเริ่มต้นขนาดเล็ก ทำให้เซิร์ฟเวอร์ส่งการตอบกลับการจับมือขนาดใหญ่ไปยังผู้เสียหาย QUIC ลดความเสี่ยงนี้ด้วยการจำกัดการตอบกลับของเซิร์ฟเวอร์ไว้ที่ไม่เกิน 3 เท่าของข้อมูลที่ได้รับ จนกว่าการตรวจสอบที่อยู่จะเสร็จสิ้นผ่านกลไก RETRY การทำให้การเชื่อมต่อท่วม: เซิร์ฟเวอร์ QUIC ต้องจำกัดอัตราความพยายามสร้างการเชื่อมต่อใหม่จาก IP เดียวกัน การโจมตีการเจรจาเวอร์ชันป้องกันได้ด้วยการรวมเวอร์ชันไว้ในการจับมือที่ได้รับการปกป้องด้วยการเข้ารหัส การเข้ารหัสในตัวของ QUIC ทำให้อุปกรณ์ตรวจสอบไม่สามารถวิเคราะห์ข้อมูลบรรทุกของ QUIC ได้ เว้นแต่อุปกรณ์นั้นจะอยู่บนเส้นทางเดียวกับเซิร์ฟเวอร์และมีใบรับรองเซิร์ฟเวอร์ ซึ่งช่วยเพิ่มความเป็นส่วนตัวเมื่อเทียบกับทราฟฟิก TCP ที่ตรวจสอบได้

การนำ HTTP/3 ไปใช้งานจำเป็นต้องมี: (1) เซิร์ฟเวอร์ที่รองรับ QUIC เช่น nginx 1.25+, Caddy, HAProxy 2.6+, LiteSpeed หรือการรองรับในระดับแอปพลิเคชันผ่านไลบรารี quic-go, aioquic และ ngtcp2 (2) เปิดพอร์ต UDP 443 บนไฟร์วอลล์ เนื่องจากไฟร์วอลล์ขององค์กรหลายแห่งบล็อก UDP 443 ทำให้ QUIC เปลี่ยนไปใช้ TCP/TLS เป็นทางเลือกสำรอง (3) ประกาศการรองรับ HTTP/3 ผ่านส่วนหัวการตอบกลับ Alt-Svc: Alt-Svc: h3=":443"; ma=86400 เพื่อกระตุ้นไคลเอ็นต์ HTTP/2 ให้อัปเกรด (4) ตัวกระจายโหลดที่เข้าใจ QUIC หรือการส่งผ่าน UDP ระดับ L4 (5) การตรวจติดตามตัวชี้วัดเฉพาะของ QUIC เช่น เหตุการณ์การย้ายการเชื่อมต่อ อัตราการยอมรับ 0-RTT และอัตราการเปลี่ยนไปใช้โพรโทคอลสำรอง การทยอยเปิดใช้งานโดยมี HTTPS เป็นทางเลือกสำรองจะไม่สร้างความแตกต่างแก่ไคลเอ็นต์ที่ไม่รองรับ QUIC

QUIC แก้ปัญหาการปิดกั้นที่หัวแถวซึ่งส่งผลต่อ HTTP/2 ที่ทำงานบน TCP ได้อย่างไร

QUIC ผสาน TLS 1.3 เข้ากับชั้นขนส่งบน UDP จึงกำจัดการปิดกั้นที่หัวแถวของ TCP ด้วยการกู้คืนข้อมูลสูญหายแยกกันในแต่ละช่องข้อมูล Connection ID ช่วยให้ย้ายการเชื่อมต่อข้ามการเปลี่ยนแปลงของเครือข่ายได้โดยไม่ต้องเจรจาใหม่ HTTP/3 จับคู่ HTTP เข้ากับช่องข้อมูล QUIC โดยใช้ QPACK สำหรับการบีบอัดส่วนหัว การกลับมาใช้การเชื่อมต่อแบบ 0-RTT จะนำความลับของเซสชัน TLS กลับมาใช้ QUIC มีประสิทธิภาพเหนือกว่า HTTP/2 อย่างเด่นชัดที่สุดเมื่อเกิดการสูญเสียแพ็กเก็ต เช่น บนเครือข่ายมือถือหรือเครือข่ายที่แออัด การกระจายโหลด QUIC จำเป็นต้องเข้ารหัสข้อมูลการกำหนดเส้นทางของเซิร์ฟเวอร์ไว้ใน Connection ID การนำไปใช้งานจำเป็นต้องเปิด UDP 443 มีเซิร์ฟเวอร์ที่รองรับ QUIC และใช้ส่วนหัว Alt-Svc เพื่อประกาศโพรโทคอล