HTTP/3 (QUIC) Support

HTTP/3 (เดิมเรียกว่า “HTTP over QUIC”) เป็นเวอร์ชันที่สามของตระกูล Hypertext Transfer Protocol ซึ่งฟีเจอร์นี้จะคล้ายกับ HTTP/2 มากแต่มีข้อดีที่สำคัญบางประการเนื่องจากการเปลี่ยนแปลงวิธีการใช้งานพื้นฐาน กล่าวคือ HTTP/3 สร้างขึ้นบน QUIC transport protocol ซึ่งทำงานบน UDP แทน TCP

ในปัจจุบัน HTTP/3 ได้ให้บริการบางโซลูชันแล้ว (เช่น LiteSpeed ​​และ NGINX) และนำมาใช้โดยแพลตฟอร์มล่าสุดของสแต็คต่อไปนี้:

ด้านล่างนี้ คุณสามารตรวจสอบ:

เงื่อนไขการใช้งาน HTTP/3 ทางเทคนิคเบื้องต้น

เหตุผลหลักในการนำ HTTP/3 ไปใช้คือ HTTP/2 ถึงขีดจำกัดในการปรับปรุงความเร็วเนื่องจาก bottleneck ของ TCP protocol ถึงแม้ว่าจะเชื่อถือได้แต่ round-trip ทั้งหมดที่จำเป็นสำหรับ handshakes การตอบกลับการส่ง การรับประกันการสั่งซื้อและการตรวจสอบของ TCP นั้นถือว่าอ่อนแอและซ้ำซ้อน ด้วยเหตุนี้ส่วนหนึ่งของสแต็ก TCP/IP นั้น TCP ถูกนำไปใช้ใน kernels ของระบบปฏิบัติการ และอุปกรณ์เฟิร์มแวร์ การเปลี่ยนแปลงที่สำคัญกับ TCP นั้นแทบจะเป็นไปไม่ได้เลย

เคล็ดลับ: ด้านล่างนี้เราได้จัดเตรียมตัวอย่างข้อจำกัดบางประการของ TCP:

– การเชื่อมต่อ TCP เดียวสามารถถ่ายโอนข้อมูลผ่านหลายสตรีม; อย่างไรก็ตามการสูญเสียแพ็กเก็ตจะเก็บการเชื่อมต่อทั้งหมด (และสตรีมทั้งหมด) จนกว่า TCP จะส่งแพ็กเก็ตใหม่

– TCP ไม่มี TLS ในตัว ดังนั้นการเชื่อมต่อที่ปลอดภัยจึงต้องการ round-trip เพิ่มเติมทำให้เกิดความล่าช้า

UDP ไม่มีข้อจำกัดดังกล่าวและแพร่หลายพอๆกับ TCP ซึ่งช่วยให้สามารถปรับปรุงได้โดยไม่มีการเปลี่ยนแปลงที่สำคัญในระบบปฏิบัติการและอุปกรณ์เฟิร์มแวร์ที่มีอยู่ ดังนั้น HTTP/3 ได้นำ QUIC transport protocol (ในขั้นต้นพัฒนาโดย Google) ซึ่งอิงตาม UDP จึงมีประโยชน์อย่างมาก อีกทั้งบริษัทชื่อดังอย่าง Google และ Facebook มีการใช้งานอยู่แล้วทำให้ประสิทธิภาพและความน่าเชื่อถือของ QUIC solution ไม่อาจปฏิเสธได้

ฟีเจอร์หลักของ HTTP/3 (QUIC)

การใช้ QUIC เป็นฐานแทน TCP ทำให้สามารถใช้ประโยชน์จาก HTTP/3 ได้มากมายโดยการใช้ QUIC ที่ด้านบนเป็น UDP ช่วยให้มีคุณสมบัติคล้ายกับ TCP ที่ปราศจากจุดปิดกั้น ดังนั้นเราจะสรุปฟีเจอร์เด่นๆของ HTTP/3 เมื่อเทียบกับ HTTP/2 รุ่นก่อน:

  • การปรับปรุงมัลติเพล็กซ์: การสูญเสียแพ็กเก็ตมีผลต่อสตรีมเดียวเท่านั้น (ไม่ใช่ทั้งหมดภายในการเชื่อมต่อเดียวกัน)
  • การตั้งค่าการเชื่อมต่อที่เร็วขึ้น: โปรโตคอลที่จัดการฟีเจอร์ความปลอดภัยด้วยตัวเอง ลดจำนวนของ round-trips สำหรับการสร้างการเชื่อมต่อ (โดยเฉพาะอย่างยิ่งที่เห็นได้ชัดบนเครือข่ายที่การเชื่อมต่อมีดีเลย์นาน เช่น สำหรับผู้ใช้มือถือ)
  • การย้ายการเชื่อมต่อ: การใช้ ID เชื่อมต่อแทน IP ปลายทางช่วยให้มั่นใจได้ว่าการส่งแพ็คเก็ตในกรณีที่มีการสลับเครือข่าย (เช่น การดาวน์โหลดผ่าน HTTP/3 จะดำเนินการเมื่อการเชื่อมต่อ wifi เปลี่ยนเป็นเครือข่ายมือถือ)

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

การทำงานร่วมกับ Ruk-Com Cloud PaaS

การรองรับ HTTP/3 (QUIC) protocol ยังคงอยู่ในขั้นตอนการเริ่มนำไปปฏิบัติ อย่างไรก็ตามมีโซลูชันบางอย่างให้บริการอยู่แล้ว (เช่น LiteSpeed) และกำลังอยู่ในระหว่างการพัฒนาโดยผู้อื่น

  • load balancers
    • LiteSpeed Web ADC: ทุกเวอร์ชัน
    • Varnish: เวอร์ชัน 5.2.x6.x.x ขึ้นไป
    • NGINX: ตั้งแต่เปิดตัว 1.16.1 

  • application servers
    • LLSMP: ทุกเวอร์ชัน
    • LEMP: ตั้งแต่เปิดตัว 1.16.1 
    • NGINX PHP: ตั้งแต่เปิดตัว 1.16.1 สำหรับ PHP เวอร์ชัน 7.2.26, 7.3.13, 7.4.1 ขึ้นไป
    • NGINX Ruby: ตั้งแต่เปิดตัว 1.16.1 สำหรับ Ruby เวอร์ชัน 2.4.9, 2.5.7, 2.6.5, 2.7.0 ขึ้นไป

เพียงสร้าง environment topology ที่มีแอปพลิเคชันเซิร์ฟเวอร์หรือโหลดบาลานเซอร์ที่กล่าวถึงข้างต้น

ในขั้นตอนนี้คุณจะต้องแนบ public IP เพิ่มเติมเพื่อหลีกเลี่ยง Shared Load Balancer และอนุญาตให้ทำงานโดยตรงกับเซิร์ฟเวอร์ผ่าน HTTP/3

หมายเหตุ: สำหรับฝั่ง client ขณะนี้รองรับ HTTP/3 (QUIC) สามารถเปิดใช้งานโดยค่าเริ่มต้นใน Chromium และสามารถกำหนดค่าได้ใน Chrome แต่ใน Firefox browser ยังไม่สามารถใช้งานได้