เหตุใด HTTP/3 จึงได้รับการรองรับอย่างแพร่หลาย แต่แทบไม่ถูกใช้งานจริง

 (httptoolkit.com)
2 คะแนน โดย GN⁺ 2025-03-18 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • HTTP/3 ถูกพัฒนามาตั้งแต่ปี 2016 และ QUIC ซึ่งเป็นโปรโตคอลพื้นฐานถูกนำมาใช้ครั้งแรกโดย Google ในปี 2013
  • ปัจจุบันได้กลายเป็นมาตรฐานแล้ว และได้รับการรองรับอย่างกว้างขวางดังนี้
    • รองรับในเบราว์เซอร์ 95%
    • 32% ของคำขอ HTTP บน Cloudflare ใช้ HTTP/3
    • 35% ของเว็บไซต์แสดงการรองรับ HTTP/3 (ผ่าน alt-svc หรือ DNS)
  • อย่างไรก็ตาม ไลบรารีมาตรฐานของภาษาหลักยังขาดการรองรับ QUIC และ HTTP/3
    • ไม่ถูกรวมอยู่ในไลบรารีมาตรฐานของ Node.js, Go, Rust, Python, Ruby เป็นต้น
    • Curl เพิ่งเพิ่มการรองรับ HTTP/3 เมื่อไม่นานนี้ แต่ยังอยู่ในสถานะทดลองและปิดไว้โดยค่าเริ่มต้น
    • Nginx ซึ่งเป็นเซิร์ฟเวอร์ยอดนิยมยังรองรับแบบทดลองและปิดไว้โดยค่าเริ่มต้น
    • Apache ไม่มีแผนรองรับ HTTP/3
    • Ingress-Nginx ของ Kubernetes ล้มเลิกแผนรองรับ HTTP/3

ความจำเป็นหลัง HTTP/1.1

  • HTTP/3 มีประโยชน์กับทราฟฟิกของเว็บเบราว์เซอร์และ CDN ที่มี latency สูง
  • ประโยชน์หลักที่ HTTP/2 และ HTTP/3 มอบให้:
    • multiplexing ช่วยลดเวลาในการรอการตอบกลับ
    • การบีบอัด HTTP header ช่วยลดทราฟฟิก (ใช้ HPACK, QPACK)
    • bidirectional streaming ทำให้แลกเปลี่ยนข้อมูลแบบเรียลไทม์ระหว่างไคลเอนต์และเซิร์ฟเวอร์ได้
    • การจัดลำดับความสำคัญ ช่วยให้ประมวลผลคำขอสำคัญก่อน
  • ประโยชน์เพิ่มเติมของ HTTP/3:
    • การจัดการสตรีมแบบอิสระ ทำให้ packet loss ไม่ส่งผลต่อสตรีมอื่น
    • 0-RTT TLS handshake ช่วยให้เริ่มต้นการเชื่อมต่อได้เร็วขึ้น
    • connection migration ทำให้คงการเชื่อมต่อไว้ได้เมื่อ IP address เปลี่ยน
    • การควบคุมความหนาแน่นของเครือข่ายที่ดีขึ้น ช่วยเพิ่มประสิทธิภาพและความเสถียร

ผลด้านประสิทธิภาพของ HTTP/3

  • ผล benchmark ของ RequestMetric:
    • HTTP/3 ให้ความเร็วในการตอบสนองดีกว่า HTTP/1.1 และ HTTP/2
  • กรณีใช้งานจริงของ Fastly:
    • เวลาไปถึงไบต์แรกบน HTTP/3 ลดลง 18%

ปัญหาการรองรับ HTTP/3 ที่ยังไม่เพียงพอ

  • แม้ HTTP/3 จะได้รับการรองรับอย่างกว้างขวางในเบราว์เซอร์และ CDN แต่สำหรับนักพัฒนาทั่วไปยังใช้งานได้ยาก
  • ปัจจุบันเว็บทราฟฟิกมีอยู่ 2 ประเภท:
    • เว็บแบบ hyperscale: อิงกับเบราว์เซอร์หลักและเซิร์ฟเวอร์ขนาดใหญ่ (Google, Meta, Amazon เป็นต้น)
    • เว็บแบบ long tail: อิงกับเซิร์ฟเวอร์และไคลเอนต์ขนาดเล็กถึงกลาง (backend API, mobile app, IoT เป็นต้น)
  • ความแตกต่างสำคัญ:
    • ทราฟฟิกแบบ long tail คิดเป็น 67% ของทราฟฟิกทั้งหมด
    • hyperscale พัฒนาและนำไปใช้ได้เร็ว ส่วน long tail มีข้อจำกัดด้านทรัพยากรและให้ความสำคัญกับความเสถียรเป็นหลัก
    • พึ่งพาเครื่องมือโอเพนซอร์สมาก

ปัญหา OpenSSL กับ QUIC

  • OpenSSL เป็นรากฐานของเครื่องมือเครือข่ายโอเพนซอร์สส่วนใหญ่
  • BoringSSL เปิดตัว API ที่รองรับ QUIC ในปี 2018 แต่ OpenSSL กลับนำเสนอ QUIC API ของตนเอง
  • ปัญหาหลัก:
    • ไม่เข้ากันกับ implementation เดิมที่อิง BoringSSL
    • Curl และภาษาหลักต่าง ๆ เปลี่ยน dependency จาก OpenSSL ได้ยาก
    • Node.js เคยพิจารณาใช้ BoringSSL แทน OpenSSL แต่ไม่เกิดขึ้นจริง

แนวโน้มข้างหน้า

  • เมื่อเว็บแบบ hyperscale นำ HTTP/3 มาใช้ ช่องว่างด้านประสิทธิภาพกับเว็บแบบ long tail อาจกว้างขึ้น
  • การขาดการรองรับ HTTP/3 อาจทำให้เกิดปัญหาดังนี้:
    • ตอกย้ำความได้เปรียบด้านความเร็วและความเสถียรของเว็บไซต์ hyperscale
    • หากเฟรมเวิร์กที่อิง HTTP/3 กลายเป็นเรื่องปกติ เว็บแบบ long tail อาจเข้าถึงได้ยาก
    • การไม่รองรับ HTTP/3 อาจถูกใช้เป็นเกณฑ์ในการปิดกั้นไคลเอนต์
  • แนวทางแก้ไข:
    • ต้องแก้ปัญหา QUIC API ของ OpenSSL
    • ต้องพัฒนาเครื่องมือและ adapter ที่เพิ่มความเข้ากันได้กับ implementation ของ QUIC และ HTTP/3 ที่มีอยู่
    • ต้องผลักดันให้เครื่องมือโอเพนซอร์สรองรับ HTTP/3 มากขึ้น

บทสรุป

  • HTTP/3 มอบข้อดีด้านประสิทธิภาพและความเสถียรอย่างชัดเจน แต่ในตอนนี้ยังเป็นสิ่งที่มีเพียงบริษัทระดับ hyperscale เท่านั้นที่ใช้งานได้ง่าย
  • จำเป็นต้องปรับปรุงเครื่องมือและมาตรฐาน เพื่อให้เว็บแบบ long tail ก็สามารถใช้ HTTP/3 ได้ง่ายเช่นกัน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-03-18
ความเห็นจาก Hacker News

  • มีความเห็นว่าหาเครื่องมือโอเพนซอร์สยอดนิยมที่รองรับ HTTP/3 ได้อย่างสมบูรณ์ได้ยาก

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

  • ไลบรารีมาตรฐานของภาษาหลัก ๆ ยังไม่มี QUIC หรือ HTTP/3 รวมมาให้

    • .NET มีการรองรับ HTTP/3 ที่ค่อนข้างดี
    • ทีมพัฒนาส่วนใหญ่ไม่ได้สร้างผลิตภัณฑ์ที่เน้นงานเครือข่ายเป็นหลัก จึงให้ HTTP/3 มีลำดับความสำคัญต่ำ

  • ปัญหาใหญ่ที่สุดของการนำ HTTP/3 ไปใช้งานในวงกว้างคือการเพิ่มพื้นผิวของโค้ดที่อาจมีช่องโหว่

    • จะดีกว่าหากระบบปฏิบัติการมีเลเยอร์ซ็อกเก็ตที่ปลอดภัยและไลบรารี SSL ที่เชื่อมต่อแบบไดนามิกให้
    • สำหรับแอปพลิเคชันฝั่งไคลเอนต์ส่วนใหญ่ ความหน่วงของคำขอเพิ่มขึ้นไม่กี่มิลลิวินาทีไม่ใช่ปัญหาใหญ่

  • การยอมรับ QUIC ที่ล่าช้าเป็นเพราะ OpenSSL ไม่ได้มีองค์ประกอบพื้นฐานที่จำเป็นสำหรับการติดตั้งใช้งาน QUIC แบบเดิม

    • ไม่นานมานี้ OpenSSL 3.5 ได้เริ่มมี API สำหรับ QUIC stack ของบุคคลที่สาม

  • ตอนนี้ HTTP/2 และ HTTP/3 ไม่ได้ถูกมองว่าเป็นโปรโตคอลชั้นแอปพลิเคชันอีกต่อไป แต่ถูกมองในระดับ TCP และ TLS แทน

    • นักพัฒนายังคงใช้ชีวิตอยู่ในโลกของ "plain text HTTP 1.1"

  • nginx ยังไม่มีการรองรับ HTTP/3 ที่พร้อมใช้งานจริงในระดับโปรดักชัน

  • มีการใช้งาน niquests ใน Python และมันรองรับ HTTP/3

    • ระบบนิเวศของ Python ติดอยู่กับแพ็กเกจ requests มานานเพราะแรงเฉื่อย

  • Node.js ได้เผยแพร่อัปเดตเกี่ยวกับสถานะของ QUIC และกำลังเผชิญปัญหาจากการที่ OpenSSL รองรับ API ช้า

  • หากใช้โหลดบาลานเซอร์ของผู้ให้บริการพับลิกคลาวด์ ก็จะใช้ HTTP/3 โดยปริยาย

    • เว็บไซต์ที่ใช้เซิร์ฟเวอร์ของตัวเองจึงไม่ได้รับประโยชน์จาก HTTP/3

  • ทุกโปรเจกต์ล้วนขับเคลื่อนด้วยโอเพนซอร์สและชุมชนในระดับหนึ่ง

    • จึงยังไม่รู้สึกถึงความจำเป็นในการรองรับ HTTP/3 อย่างรวดเร็ว