DEV Community

Cover image for HTTP/3 (QUIC) คืออะไร: ความสำคัญและผลกระทบต่อ API ของคุณ
Thanawat Wongchai
Thanawat Wongchai

Posted on Originally published at apidog.com

HTTP/3 (QUIC) คืออะไร: ความสำคัญและผลกระทบต่อ API ของคุณ

HTTP/3 และ QUIC: สิ่งที่นักพัฒนา API ต้องรู้และวิธีตรวจสอบ

คำขอ HTTP ทุกรายการที่ API ให้บริการทำงานอยู่บน Transport layer ซึ่งนักพัฒนาส่วนใหญ่มักไม่เห็น ตลอด 25 ปีที่ผ่านมา คำตอบคือ TCP จากนั้น Google จึงพัฒนา QUIC บน UDP และ IETF ทำให้เป็นมาตรฐาน HTTP/3 ซึ่งเป็น HTTP เวอร์ชันที่ออกแบบมาให้ทำงานบน QUIC

ลองใช้ Apidog วันนี้

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

สิ่งที่ไม่เปลี่ยนคือคำขอ การตอบกลับ รหัสสถานะ และ JSON payload ยังคงมีหน้าตาเหมือนเดิมบน HTTP/1.1, HTTP/2 และ HTTP/3 เครื่องมืออย่าง Apidog ยังคงใช้ทดสอบและแก้ไขจุดบกพร่องที่ API layer ได้ ไม่ว่าโครงสร้างพื้นฐานจะเลือกใช้ Transport เวอร์ชันใดก็ตาม หากคุณอ่านบทความ HTTP/2 คืออะไรและวิธีการทดสอบ HTTP/2 API แล้ว บทความนี้คือภาคต่อ

QUIC คืออะไร?

QUIC เป็น Transport protocol ที่กำหนดมาตรฐานไว้ใน RFC 9000 โดยทำงานบน UDP แทน TCP และสร้างความสามารถที่ TCP เคยมีให้ขึ้นมาใหม่ใน user space ได้แก่ ความน่าเชื่อถือ การจัดลำดับ และการควบคุมความแออัด นอกจากนี้ยังออกแบบให้ทำงานแยกตามสตรีม พร้อมการเข้ารหัสตั้งแต่แพ็กเก็ตแรก

การตัดสินใจออกแบบหลักของ QUIC มี 4 ข้อ:

ทำงานบน UDP

TCP ฝังอยู่ในเคอร์เนลของระบบปฏิบัติการและ middlebox ทั่วอินเทอร์เน็ต ทำให้การพัฒนาต่อทำได้ยาก UDP เป็นเพียงซองจดหมายบาง ๆ ที่ไม่รับประกันการส่งมอบ ดังนั้น QUIC จึงสร้าง reliability layer ของตัวเอง และสามารถปรับปรุงผ่านการอัปเดตไลบรารีโดยไม่ต้องรออัปเกรดระบบปฏิบัติการ

มี TLS 1.3 ในตัว

TCP ต้องทำ TCP handshake ให้เสร็จก่อน แล้วจึงทำ TLS handshake แยกต่างหาก QUIC รวมขั้นตอนเหล่านี้ไว้ใน transport handshake เดียว ทำให้การเชื่อมต่อปลอดภัยใหม่พร้อมใช้งานได้หลังจาก round trip เดียว และไม่มี QUIC ที่ไม่ได้เข้ารหัส

สตรีมทำงานแยกจากกัน

การเชื่อมต่อ QUIC รองรับหลายสตรีม แต่ละสตรีมมีการส่งมอบข้อมูลอย่างอิสระ หากแพ็กเก็ตสูญหาย จะกระทบเฉพาะสตรีมที่แพ็กเก็ตนั้นเป็นสมาชิก ไม่หยุดสตรีมอื่น นี่คือวิธีแก้ปัญหา transport-level head-of-line (HOL) blocking ของ TCP

รองรับการย้ายเครือข่าย

TCP ผูกการเชื่อมต่อกับ IP address และ port เมื่อเปลี่ยนเครือข่าย เช่น เดินออกจาก Wi-Fi แล้วสลับไปใช้ 5G การเชื่อมต่อจะหลุด QUIC ใช้ Connection ID แทน จึงย้ายไปยังเครือข่ายใหม่และรักษาสถานะเชิงตรรกะเดิมไว้ได้ โดยไม่ต้องเชื่อมต่อหรือ handshake ใหม่

HTTP/3 ซึ่งกำหนดไว้ใน RFC 9114 คือการแมป HTTP semantics เข้ากับ QUIC streams เมธอด เฮดเดอร์ และรหัสสถานะยังเหมือนเดิม สิ่งที่เปลี่ยนคือรูปแบบการสื่อสารและ Transport layer

HTTP/3 เทียบกับ HTTP/2: สิ่งที่เปลี่ยนในทางปฏิบัติ

HTTP/2 เพิ่ม multiplexing ทำให้คำขอหลายรายการใช้ TCP connection เดียวกันได้ แทนการเข้าคิวหรือเปิดซ็อกเก็ตขนานหลายรายการ แต่ยังมีข้อจำกัดจาก TCP

TCP รับประกันการส่งมอบ byte stream เดียวตามลำดับ หากแพ็กเก็ตหนึ่งสูญหาย TCP จะกักไบต์ทั้งหมดที่ตามมาไว้จนกว่าจะได้รับการส่งซ้ำ แม้ไบต์เหล่านั้นจะเป็นของ HTTP/2 stream อื่นก็ตาม แพ็กเก็ตที่หายเพียงหนึ่งแพ็กเก็ตจึงอาจทำให้คำขอ 20 รายการบน connection เดียวกันหยุดพร้อมกันได้ นี่คือ transport-level HOL blocking และบนเครือข่ายที่สูญเสียแพ็กเก็ต HTTP/2 อาจช้ากว่า HTTP/1.1 ที่ใช้หลาย connection

HTTP/3 แยกคำขอแต่ละรายการไปยัง QUIC stream ของตัวเอง หากแพ็กเก็ตของ stream 5 หาย stream 6–24 ยังทำงานต่อได้ Multiplexing จึงทำงานได้ตามที่ HTTP/2 ตั้งใจไว้โดยไม่ถูกจำกัดด้วย byte stream เดียวของ TCP

คุณสมบัติ HTTP/2 over TCP + TLS 1.3 HTTP/3 over QUIC
ตั้งค่า connection ใหม่ 2 round trips (TCP + TLS) 1 round trip
กลับมาเชื่อมต่ออีกครั้ง 1 round trip 0 round trips (0-RTT)
ผลกระทบจากแพ็กเก็ตสูญหาย บล็อกทุกสตรีม บล็อกเฉพาะสตรีมเดียว
เปลี่ยนเครือข่าย (Wi-Fi เป็น 5G) หลุดและเชื่อมต่อใหม่ทั้งหมด ย้าย connection และทำงานต่อ
การเข้ารหัส แยกเป็นอีกเลเยอร์และเป็นทางเลือกในทางทฤษฎี บังคับและมี TLS 1.3 ในตัว

ระวัง 0-RTT

เมื่อไคลเอนต์เชื่อมต่อกับเซิร์ฟเวอร์ที่เคยรู้จัก QUIC อนุญาตให้ส่ง application data ในแพ็กเก็ตแรกก่อน handshake เสร็จ ช่วยลด latency ได้มาก แต่ข้อมูล 0-RTT อาจถูกดักจับและ replay โดยผู้โจมตี

เซิร์ฟเวอร์จึงควรยอมรับเฉพาะคำขอแบบ idempotent ใน 0-RTT:

  • Replay คำขอ GET โดยทั่วไปไม่เป็นอันตราย
  • Replay คำขอ POST ที่เรียกเก็บเงินจากบัตรเครดิตไม่ปลอดภัย

หากเปิดใช้ 0-RTT ที่ Edge ให้ยกเว้น API ที่ไม่ใช่ idempotent หรือยืนยันว่า CDN จัดการเรื่องนี้ให้แล้ว

HTTP/3 มีผลต่อ API อย่างไร?

การอัปเกรดโปรโตคอลมีคุณค่าเมื่อวัดผลได้ ต่อไปนี้คือกรณีที่ HTTP/3 ช่วยและกรณีที่ไม่ช่วย

ลดต้นทุนการตั้งค่า connection

บน mobile client ที่มี RTT 60 ms การตั้งค่า TCP + TLS ใช้เวลาประมาณ 120 ms ก่อนส่งคำขอ API แรก HTTP/3 ลดเวลานี้เหลือประมาณ 60 ms และเกือบศูนย์เมื่อกลับมาเชื่อมต่ออีกครั้ง

ประโยชน์จะเห็นชัดกับ:

  • Mobile app ที่เปิด connection ใหม่บ่อย
  • Cold start
  • Background wakeup
  • Short-lived session

ในทางกลับกัน server-to-server integration ที่มี connection pool พร้อมใช้งานอยู่แล้วจะเฉลี่ยต้นทุน handshake ออกไปจนแทบไม่เห็นความแตกต่าง

ลด connection drop บนมือถือ

ลองนึกภาพผู้ใช้เริ่มคำขอผ่าน Wi-Fi ในสำนักงาน แล้วเดินไปที่ลิฟต์จนโทรศัพท์เปลี่ยนไปใช้เครือข่ายมือถือ

ด้วย TCP คำขอที่กำลังทำงานจะล้มเหลว และ retry logic จะต้องเริ่ม connection ใหม่ทั้งหมด ด้วย QUIC connection จะติดตามอุปกรณ์ไปยังเครือข่ายใหม่ ทำให้:

  • Timeout ใน client log ลดลง
  • คำขอที่เขียนข้อมูลไม่สมบูรณ์ลดลง
  • ไม่ต้องทำ handshake ใหม่ทุกครั้งที่เครือข่ายเปลี่ยน

Multiplexing โดยไม่หยุดทั้ง connection

การแก้ HOL blocking มีประโยชน์มากเมื่อไคลเอนต์ส่งคำขอพร้อมกันจำนวนมาก เช่น:

  • Dashboard ที่โหลด widget 15 ตัว
  • Sync engine ที่ส่งการอัปเดตเป็นชุด

บนเครือข่ายสะอาด HTTP/2 และ HTTP/3 ทำงานใกล้เคียงกัน แต่เมื่อมี packet loss 1–2% เช่น Wi-Fi ในงานประชุมหรือเครือข่ายมือถือใต้ดิน HTTP/3 จะรักษาความเป็นอิสระของคำขอแบบขนานไว้ได้ ขณะที่ HTTP/2 อาจทำให้ทุกคำขอหยุดพร้อมกัน

gRPC ส่วนใหญ่ยังใช้ HTTP/2

gRPC ผูกกับ HTTP/2 โดยการออกแบบ เพราะอาศัย HTTP/2 framing และ trailers ระบบนิเวศของ gRPC ยังไม่มีมาตรฐานการแมปกับ HTTP/3 และ implementation หลักใน Go, Java, Python และ Node ยังไม่ได้รวมการรองรับนี้

.NET Kestrel ให้บริการ gRPC ผ่าน HTTP/3 ได้ในลักษณะทดลอง แต่ถือเป็นข้อยกเว้น หากสถาปัตยกรรมของคุณพึ่งพา gRPC และ HTTP/2 เพื่อประสิทธิภาพ API ภายใน ยังไม่จำเป็นต้องวางแผนย้ายไป HTTP/3 ในปีนี้

Streaming และ real-time traffic

Server-Sent Events (SSE) ทำงานบน HTTP/3 ได้โดยไม่ต้องเปลี่ยนแปลง เพราะเป็น HTTP response แบบ long-lived ทั่วไป

WebSockets ซับซ้อนกว่า การอัปเกรด WebSocket เดิมออกแบบมาสำหรับ TCP ส่วนทางเลือกบน HTTP/3 เช่น WebSocket ที่กำหนดใน RFC 9220 และ WebTransport API ยังรองรับไม่สมบูรณ์ หากกำลังพิจารณา WebSockets เทียบกับ plain HTTP สำหรับฟีเจอร์ real-time อย่าใช้ HTTP/3 เป็นปัจจัยหลักในการตัดสินใจตอนนี้

เมื่อ HTTP/3 อาจไม่ช่วย

ปัญหา latency ของ API ส่วนใหญ่ไม่ได้เกิดจาก Transport หากเอนด์พอยต์ใช้เวลา 400 ms เพราะ query ฐานข้อมูลที่ไม่มี index HTTP/3 จะลดเวลาเชื่อมต่อได้ประมาณ 60 ms แต่ไม่ได้ทำให้ query เร็วขึ้น

ควรแก้ปัจจัยเหล่านี้ก่อน:

  • Caching
  • Payload design
  • N+1 query
  • Connection reuse
  • Query ที่ไม่มีประสิทธิภาพ

การทำ API performance testing pass อย่างเป็นระบบมักให้ผลลัพธ์ดีกว่าการอัปเกรดโปรโตคอลหลายเท่า บางกรณีอาจดีกว่าถึง 10 เท่า

HTTP/3 เหมาะเป็นพิเศษกับ:

  • ลิงก์ที่มี latency สูง ซึ่งการลด round trip ช่วยประหยัดเวลาแบบคงที่
  • เครือข่ายที่มี packet loss ซึ่งการกำจัด HOL blocking ช่วยเพิ่ม throughput
  • Mobile client ที่เปลี่ยนเครือข่ายระหว่าง session
  • การเชื่อมต่อระยะสั้นจำนวนมาก แทนการเชื่อมต่อระยะยาวไม่กี่ครั้ง

สำหรับ JSON API ทั่วไปที่ใช้งานโดยเซิร์ฟเวอร์ในภูมิภาคเดียวกันบนเครือข่ายที่เสถียร ความแตกต่างอาจวัดได้ใน benchmark แต่ผู้ใช้อาจไม่รู้สึก

ข้อควรพิจารณาเพิ่มเติม:

  • เครือข่ายองค์กรบางแห่งบล็อก UDP 443 แต่ไคลเอนต์จะ fallback ไป HTTP/2 อัตโนมัติ จึงไม่ทำให้บริการเสียหาย
  • QUIC เข้ารหัสใน user space และปัจจุบันอาจใช้ CPU ต่อ connection มากกว่า TCP ที่ปรับแต่งใน kernel

การรองรับ HTTP/3 ในปัจจุบัน

การรองรับ HTTP/3 ก้าวหน้าไปมาก:

  • เบราว์เซอร์: Chrome, Edge, Firefox และ Safari เปิดใช้ HTTP/3 เป็นค่าเริ่มต้น
  • CDN และ Edge: Cloudflare, Fastly, Akamai และ CloudFront รองรับ HTTP/3 โดย Cloudflare สามารถเปิดหรือปิดได้ สำหรับทีมส่วนใหญ่ แนวทางที่ใช้งานจริงคือ terminate HTTP/3 ที่ Edge แล้วใช้ HTTP/1.1 หรือ HTTP/2 ระหว่าง Edge กับ Origin
  • เซิร์ฟเวอร์: Nginx รองรับ HTTP/3 ตั้งแต่รุ่น 1.25 ผ่าน listen 443 quic แต่ยังเป็นฟีเจอร์ทดลอง Caddy เปิดใช้งานเป็นค่าเริ่มต้น ส่วน LiteSpeed และ HAProxy รองรับ ขณะที่ Apache httpd ยังไม่รองรับ
  • Runtime: Node.js ยังไม่มี HTTP/3 server ในตัวที่เสถียร จึงเป็นอีกเหตุผลที่หลายระบบเลือก terminate ที่ Edge
  • curl: รองรับผ่านแฟล็ก --http3 เมื่อคอมไพล์ด้วย TLS stack ที่รองรับ HTTP/3 ดู เอกสาร HTTP/3 ของ curl เพื่อดู build ที่รองรับ

วิธีตรวจสอบว่า API รองรับ HTTP/3 หรือไม่

การค้นพบ HTTP/3 ทำงานผ่าน response header Alt-Svc เซิร์ฟเวอร์ที่โฆษณา HTTP/3 อาจตอบคำขอแรกผ่าน HTTP/2 ด้วย header เช่น:

alt-svc: h3=":443"; ma=86400
Enter fullscreen mode Exit fullscreen mode

header นี้บอกไคลเอนต์ว่า service เดียวกันพร้อมให้ใช้ผ่าน HTTP/3 บน UDP port 443 เป็นเวลา 24 ชั่วโมง

ตรวจสอบด้วย curl:

curl -sI https://www.cloudflare.com | grep -i alt-svc
# alt-svc: h3=":443"; ma=86400
Enter fullscreen mode Exit fullscreen mode

ส่งคำขอผ่าน HTTP/3 โดยตรงได้ดังนี้ โดยต้องใช้ curl build ที่เปิดใช้ HTTP/3:

curl --http3 -I https://cloudflare-quic.com
# HTTP/3 200
Enter fullscreen mode Exit fullscreen mode

บรรทัดสถานะควรรายงาน HTTP/3 แทน HTTP/2

ใน Chrome DevTools:

  1. เปิดแท็บ Network
  2. คลิกขวาที่ส่วนหัวคอลัมน์
  3. เปิดคอลัมน์ Protocol
  4. มองหา h3 ถัดจากคำขอ API

ใน production ควรบันทึก negotiated protocol ใน access log แล้วเปรียบเทียบสัดส่วนทราฟฟิก h2 และ h3 เพื่อดูว่าไคลเอนต์ได้รับประโยชน์มากเพียงใด

ระหว่างตรวจสอบ Transport ให้ตรวจสอบ API behavior ไปพร้อมกันด้วย ใช้ Apidog ชี้ไปยังเอนด์พอยต์เดียวกัน แล้วตรวจสอบ:

  • Status code
  • Response schema
  • Latency budget
  • Contract ของ API

ประโยชน์จาก Transport layer จะไม่มีค่า หาก API contract ด้านบนเสียหาย คุณสามารถ ดาวน์โหลด Apidog ได้ฟรี แล้วรันชุดทดสอบเดียวกันก่อนและหลังเปิด HTTP/3 ที่ Edge ความแตกต่างของ response time บนเครือข่ายมือถือคือคำตอบที่แท้จริงสำหรับระบบของคุณ ไม่ใช่เพียงผลจาก benchmark

คำถามที่พบบ่อย

HTTP/3 เรรวัดผลด้วย traffic profile ของระบบคุณเอง และอย่าลืมว่า HTTP/2 ยังทำงานได้ดี หากพบ connection error มักเกี่ยวข้องกับ TLS เช่น ปัญหา SSLV3_ALERT_HANDSHAKE_FAILURE มากกว่าจะเป็นข้อจำกัดของ HTTP/2

HTTP/3 ใช้ TCP หรือไม่?

ไม่ HTTP/3 ทำงานบน QUIC ซึ่งทำงานบน UDP และโดยทั่วไปใช้ port 443 QUIC สร้าง reliability, ordering และ congestion control ขึ้นใหม่ใน user space และแยกตามสตรีม

หาก UDP 443 ถูกบล็อก ไคลเอนต์จะ fallback ไปใช้ HTTP/2 ผ่าน TCP โดยอัตโนมัติ

ต้องเปลี่ยนโค้ด API เพื่อรองรับ HTTP/3 หรือไม่?

แทบไม่ต้องเปลี่ยน HTTP semantics ยังคงเหมือนเดิม ทั้งเมธอด เฮดเดอร์ รหัสสถานะ และ body งานส่วนใหญ่คือการเปิดใช้ HTTP/3 ที่ CDN, load balancer หรือเซิร์ฟเวอร์

สิ่งที่ต้องตรวจสอบคือ 0-RTT ต้องจำกัดไว้เฉพาะคำขอแบบ idempotent

ใช้ gRPC ผ่าน HTTP/3 ได้หรือไม่?

ส่วนใหญ่ยังไม่ได้ในตอนนี้ gRPC ผูกกับ HTTP/2 และไลบรารีหลักยังไม่รองรับ HTTP/3 อย่างสมบูรณ์ .NET มีการรองรับเชิงทดลอง

แนวทางที่เหมาะสมคือคง gRPC ไว้บน HTTP/2 และนำ HTTP/3 ไปใช้ก่อนกับ:

  • Public REST endpoints
  • API ที่ให้บริการเบราว์เซอร์
  • API สำหรับอุปกรณ์มือถือ

Top comments (0)