คำขอ HTTP ทุกรายการที่ API ของคุณให้บริการอยู่บนชั้น Transport ที่นักพัฒนาส่วนใหญ่ไม่เคยนึกถึง ตลอด 25 ปีที่ผ่านมา คำตอบคือ TCP จากนั้น Google ก็เบื่อหน่ายกับการรอให้ TCP พัฒนาขึ้น จึงสร้างโปรโตคอล QUIC ขึ้นบน UDP และ IETF ก็ทำให้เป็นมาตรฐาน HTTP/3 คือ HTTP เวอร์ชันที่สร้างขึ้นเพื่อทำงานบน QUIC
นั่นฟังดูเหมือนงานวางท่อ และส่วนใหญ่ก็เป็นเช่นนั้น แต่งานวางท่อนี้จะเปลี่ยนความเร็วในการเชื่อมต่อ API ของคุณ วิธีการทำงานบนเครือข่ายมือถือที่ไม่เสถียร และวิธีที่คำขอแบบขนานใช้การเชื่อมต่อร่วมกัน หากคุณออกแบบหรือใช้งาน API คุณควรรู้ว่าอะไรเปลี่ยนไป อะไรไม่ได้เปลี่ยน และจะตรวจสอบได้อย่างไรว่าเอนด์พอยต์ของคุณรองรับอะไรในวันนี้
สิ่งหนึ่งที่ยังคงไม่เปลี่ยนแปลงตลอดทั้งหมดนี้คือ: คำขอ การตอบกลับ รหัสสถานะ และเพย์โหลด JSON ของคุณจะดูเหมือนกันบน HTTP/1.1, HTTP/2 และ HTTP/3 เครื่องมืออย่าง Apidog ทดสอบและแก้ไขจุดบกพร่องที่เลเยอร์ API ดังนั้นทุกสิ่งที่คุณตรวจสอบเกี่ยวกับพฤติกรรมของเอนด์พอยต์จึงยังคงเป็นจริง ไม่ว่าโครงสร้างพื้นฐานของคุณจะเจรจาใช้ Transport เวอร์ชันใดก็ตาม หากคุณได้อ่านบทความเกี่ยวกับ HTTP/2 คืออะไรและวิธีการทดสอบ HTTP/2 API ของเราแล้ว บทความนี้จะสานต่อจากบทความนั้น
โปรโตคอล QUIC คืออะไร?
QUIC เป็นโปรโตคอล Transport ที่ได้รับการกำหนดมาตรฐานใน RFC 9000 ทำงานบน UDP แทนที่จะเป็น TCP และสร้างคุณสมบัติที่ TCP มีให้ (ความน่าเชื่อถือ, การจัดลำดับ, การควบคุมความแออัด) ขึ้นมาใหม่ใน user space, ต่อสตรีม, พร้อมกับการเข้ารหัสที่ถูกฝังมาตั้งแต่แพ็กเก็ตแรก
การตัดสินใจออกแบบสี่ข้อที่กำหนด QUIC:
ทำงานบน UDP TCP ถูกนำไปใช้งานในเคอร์เนลของระบบปฏิบัติการและ middleboxes ทั่วอินเทอร์เน็ต ซึ่งทำให้แทบเป็นไปไม่ได้ที่จะพัฒนาต่อ UDP เป็นเพียงซองจดหมายบางๆ ที่ไม่มีการรับประกันการส่งมอบ ดังนั้น QUIC จึงสร้างเลเยอร์ความน่าเชื่อถือของตัวเองขึ้นมา และสามารถส่งมอบการปรับปรุงเป็นการอัปเดตไลบรารีแทนการอัปเกรด OS
TLS 1.3 ถูกสร้างขึ้นมาในตัว ไม่ได้ถูกติดตั้งเพิ่ม กับ TCP คุณจะต้องทำ TCP handshake ให้เสร็จสิ้น จากนั้นจึงทำ TLS handshake แยกต่างหาก QUIC รวมสิ่งเหล่านี้เข้าด้วยกัน การตั้งค่าการเข้ารหัสจะเกิดขึ้นภายใน transport handshake เอง ดังนั้นการเชื่อมต่อที่ปลอดภัยใหม่จึงพร้อมใช้งานหลังจาก round trip เพียงครั้งเดียว ไม่มีสิ่งใดที่เรียกว่า QUIC ที่ไม่ได้เข้ารหัส
สตรีมเป็นอิสระต่อกัน การเชื่อมต่อ QUIC รองรับหลายสตรีม และแต่ละสตรีมจะถูกส่งมอบอย่างอิสระ แพ็กเก็ตที่สูญหายจะทำให้สตรีมที่เป็นของมันเท่านั้นหยุดชะงัก นี่คือวิธีแก้ไขปัญหา head-of-line blocking ของ TCP ซึ่งเราจะกล่าวถึงในอีกสักครู่
การเชื่อมต่อยังคงอยู่รอดแม้เครือข่ายเปลี่ยนแปลง TCP ระบุการเชื่อมต่อด้วยที่อยู่ IP และพอร์ต หากมีการเปลี่ยนแปลงสิ่งใดสิ่งหนึ่ง (เดินออกจากระยะ Wi-Fi, สลับไปใช้ 5G) การเชื่อมต่อจะหลุด QUIC ระบุการเชื่อมต่อด้วย Connection ID แทน ดังนั้นไคลเอนต์จึงสามารถย้ายไปยังเครือข่ายใหม่และรักษาสภาพการเชื่อมต่อเชิงตรรกะเดิมไว้ได้ ไม่ต้องเชื่อมต่อใหม่ ไม่ต้อง handshake ใหม่
HTTP/3 ซึ่งกำหนดไว้ใน RFC 9114 คือการจับคู่ความหมายของ HTTP เข้ากับ QUIC streams เมธอดเดิม, เฮดเดอร์เดิม, รหัสสถานะเดิม รูปแบบการสื่อสารต่างกัน, Transport ต่างกัน
HTTP/3 เทียบกับ HTTP/2: อะไรที่เปลี่ยนไปในทางปฏิบัติ
HTTP/2 เป็นก้าวสำคัญที่เหนือกว่า HTTP/1.1 โดยนำเสนอ Multiplexing ทำให้คำขอหลายรายการสามารถใช้การเชื่อมต่อ TCP เดียวกันได้ แทนที่จะต้องเข้าคิวหรือเปิดซ็อกเก็ตแบบขนานหกซ็อกเก็ต แต่ก็ยังคงใช้ TCP เป็นพื้นฐาน ซึ่งสร้างปัญหาที่ HTTP/2 ไม่สามารถแก้ไขได้ด้วยตัวเอง
TCP รับประกันการส่งมอบไบต์สตรีมเดียวตามลำดับ เมื่อแพ็กเก็ตหนึ่งหายไป TCP จะกักไบต์ทุกไบต์ที่ตามมาไว้จนกว่าการส่งซ้ำจะมาถึง แม้กระทั่งไบต์ที่เป็นของ HTTP/2 สตรีมที่ไม่เกี่ยวข้องโดยสิ้นเชิง แพ็กเก็ตที่หายไปหนึ่งแพ็กเก็ตสามารถทำให้คำขอทั้ง 20 รายการที่ Multiplexing อยู่บนการเชื่อมต่อหยุดชะงักได้ นั่นคือ head-of-line blocking ระดับ Transport และบนเครือข่ายที่มีการสูญหายของแพ็กเก็ต มันอาจทำให้ HTTP/2 ช้ากว่า HTTP/1.1 ที่มีการเชื่อมต่อหลายรายการ
HTTP/3 กำจัดไบต์สตรีมที่ใช้ร่วมกันออกไป คำขอแต่ละรายการจะถูกแมปไปยัง QUIC stream ของตัวเองพร้อมกับการจัดลำดับการส่งมอบของตัวเอง หากแพ็กเก็ตที่บรรทุกสตรีม 5 หายไป สตรีม 6 ถึง 24 ก็ยังคงทำงานต่อไป Multiplexing ในที่สุดก็ทำงานได้ตามที่แผนภาพ HTTP/2 เคยอ้างไว้เสมอ
การคำนวณการจับมือ (handshake) ก็เปลี่ยนไปเช่นกัน:
| HTTP/2 over TCP+TLS 1.3 | HTTP/3 over QUIC | |
|---|---|---|
| การตั้งค่าการเชื่อมต่อใหม่ | 2 round trips (TCP + TLS) | 1 round trip |
| การเชื่อมต่อที่กลับมาใช้งาน | 1 round trip | 0 round trips (0-RTT) |
| ผลกระทบจากแพ็กเก็ตที่สูญหาย | บล็อกทุกสตรีม | บล็อกเพียงหนึ่งสตรีม |
| การเปลี่ยนเครือข่าย (Wi-Fi เป็น 5G) | การเชื่อมต่อหลุด, เชื่อมต่อใหม่ทั้งหมด | การเชื่อมต่อย้ายข้อมูล, ทำงานต่อเนื่อง |
| การเข้ารหัส | เป็นทางเลือกในทางทฤษฎี, เลเยอร์แยกต่างหาก | บังคับ, มี TLS 1.3 ในตัว |
แถว 0-RTT ควรมีข้อควรระวัง เมื่อไคลเอนต์เชื่อมต่อใหม่ไปยังเซิร์ฟเวอร์ที่เคยเห็นมาก่อน QUIC จะอนุญาตให้ส่งข้อมูลแอปพลิเคชันในแพ็กเก็ตแรก ก่อนที่การจับมือจะเสร็จสิ้น ซึ่งยอดเยี่ยมสำหรับ Latency แต่ข้อมูล 0-RTT สามารถถูกดักจับและเล่นซ้ำโดยผู้โจมตีได้ ดังนั้นเซิร์ฟเวอร์จะต้องยอมรับเฉพาะคำขอแบบ idempotent ใน 0-RTT เท่านั้น การเล่นซ้ำคำขอ GET นั้นไม่เป็นอันตราย แต่การเล่นซ้ำคำขอ POST ที่เรียกเก็บเงินจากบัตรเครดิตนั้นไม่ปลอดภัย หากคุณเปิดใช้งาน 0-RTT ที่ Edge ของคุณ โปรดตรวจสอบให้แน่ใจว่าได้ยกเว้นการเรียกใช้ API ที่ไม่ใช่ idempotent หรือยืนยันว่า CDN ของคุณดำเนินการนี้ให้คุณแล้ว
HTTP/3 มีความหมายอย่างไรต่อ API ของคุณ
การอัปเกรดโปรโตคอลจะมีความสำคัญก็ต่อเมื่อมันเปลี่ยนแปลงบางสิ่งที่คุณสามารถวัดผลได้ นี่คือสิ่งที่ HTTP/3 สร้างความแตกต่างให้กับทราฟฟิก API และสิ่งที่ไม่สร้างความแตกต่าง
การตั้งค่าการเชื่อมต่อทำได้ถูกลง
ไคลเอนต์มือถือทั่วไปที่เชื่อมต่อ 60 ms RTT จะใช้เวลาประมาณ 120 ms ในการตั้งค่า TCP+TLS ก่อนที่คำขอ API แรกจะออกจากอุปกรณ์ด้วยซ้ำ HTTP/3 ลดเวลาดังกล่าวลงเหลือประมาณ 60 ms และเกือบเป็นศูนย์เมื่อกลับมาใช้งานอีกครั้ง สำหรับ API ที่เรียกใช้จากแอปพลิเคชันมือถือที่เปิดการเชื่อมต่อใหม่บ่อยครั้ง (เช่น cold starts, background wakeups, short-lived sessions) การประหยัดเวลาจะเกิดขึ้นกับคำขอแรกเหล่านั้นทุกครั้ง สำหรับการรวมระบบแบบ server-to-server ที่มีการรักษา connection pool ที่พร้อมใช้งานอยู่แล้ว การจับมือจะถูกเฉลี่ยออกไปจนไม่มีนัยสำคัญ และคุณจะไม่สังเกตเห็นอะไรเลย
ไคลเอนต์มือถือจะหยุดการหลุดการเชื่อมต่อ
Connection migration เป็นฟีเจอร์ที่สำคัญที่ซ่อนอยู่สำหรับทีม API ผู้ใช้เริ่มคำขอผ่าน Wi-Fi ในสำนักงาน เดินไปยังลิฟต์ และโทรศัพท์ก็เปลี่ยนไปใช้เครือข่ายมือถือ ด้วย TCP คำขอที่กำลังดำเนินการอยู่จะล้มเหลว และ retry logic ฝั่งไคลเอนต์ของคุณ (คุณมี retry logic ใช่ไหม?) ก็จะเริ่มทำงานด้วยการเชื่อมต่อใหม่ทั้งหมด ด้วย QUIC การเชื่อมต่อจะติดตามอุปกรณ์ไปยังเครือข่ายใหม่ ข้อผิดพลาด Timeout ในบันทึกของไคลเอนต์ของคุณจะน้อยลง และมีการเขียนข้อมูลที่ไม่สมบูรณ์ให้ต้องพิจารณาน้อยลง
Multiplexing โดยไม่มีโหมดความล้มเหลว
สำหรับ REST API การแก้ไขปัญหา HOL blocking มีความสำคัญที่สุดเมื่อไคลเอนต์ส่งคำขอจำนวนมากพร้อมกัน: แดชบอร์ดที่ดึงข้อมูลวิดเจ็ต 15 ตัว, เอ็นจิ้นซิงค์ที่ผลักดันการอัปเดตเป็นชุด บนเครือข่ายที่สะอาด HTTP/2 และ HTTP/3 ทำงานได้ใกล้เคียงกัน หากเพิ่มการสูญหายของแพ็กเก็ต 1-2% (เช่น Wi-Fi ในการประชุมที่มีผู้คนพลุกพล่าน, เครือข่ายมือถือใต้ดิน) HTTP/3 จะรักษาคำขอแบบขนานให้เป็นอิสระต่อกัน ในขณะที่ HTTP/2 จะทำให้คำขอทั้งหมดหยุดชะงักพร้อมกัน
gRPC ส่วนใหญ่ยังคงอยู่บน HTTP/2 ในตอนนี้
gRPC ผูกติดอยู่กับ HTTP/2 โดยการออกแบบ; ข้อตกลงการสื่อสารของมันขึ้นอยู่กับ HTTP/2 framing และ trailers ระบบนิเวศของ gRPC ยังไม่ได้กำหนดมาตรฐานการแมป HTTP/3 และการใช้งานหลักๆ (Go, Java, Python, Node) ก็ยังไม่ได้รวมเข้ามา เซิร์ฟเวอร์ Kestrel ของ .NET สามารถให้บริการ gRPC ผ่าน HTTP/3 เป็นความสามารถเชิงทดลอง แต่ให้ถือว่าเป็นข้อยกเว้น หากสถาปัตยกรรมของคุณพึ่งพา gRPC และ HTTP/2 เพื่อประสิทธิภาพ API ภายใน การย้ายไป HTTP/3 ไม่ใช่สิ่งที่คุณต้องวางแผนในปีนี้
การสตรีมและทราฟฟิกแบบเรียลไทม์
Server-Sent Events ทำงานบน HTTP/3 โดยไม่เปลี่ยนแปลง เนื่องจาก SSE เป็นการตอบกลับ HTTP แบบ long-lived ทั่วไป ส่วน WebSockets ซับซ้อนกว่า: การอัปเกรด WebSocket ได้รับการออกแบบมาสำหรับ TCP และ HTTP/3 ที่เทียบเท่ากัน (RFC 9220 รวมถึง WebTransport API ที่กำลังเกิดขึ้น) ยังมีการรองรับที่ไม่สมบูรณ์ หากคุณกำลังพิจารณา WebSockets เทียบกับ plain HTTP สำหรับฟีเจอร์เรียลไทม์ การพร้อมใช้งานของ HTTP/3 ไม่ควรเป็นตัวขับเคลื่อนการตัดสินใจในตอนนี้
ส่วนที่เป็นจริง: เมื่อ HTTP/3 อาจไม่ช่วยอะไร
ปัญหา Latency ของ API ส่วนใหญ่ไม่เกี่ยวข้องกับโปรโตคอล Transport หากเอนด์พอยต์ของคุณใช้เวลา 400 ms เนื่องจากการคิวรีฐานข้อมูลที่ไม่ได้ทำ Index, HTTP/3 จะส่งมอบการตอบสนองที่ช้าเหล่านั้นได้เร็วขึ้น 60 ms การทำ Caching, การออกแบบ Payload, การคิวรีแบบ N+1 และการนำ Connection กลับมาใช้ใหม่เป็นปัจจัยหลักที่ส่งผลต่อประสิทธิภาพของ API ในโลกแห่งความเป็นจริง และคุณควรแก้ไขสิ่งเหล่านี้ให้หมดก่อนที่จะนึกถึง Transport การทดสอบประสิทธิภาพ API ที่มีโครงสร้างที่ดี API performance testing pass มักจะให้ผลลัพธ์ที่ดีกว่าการอัปเกรดโปรโตคอลถึง 10 เท่า
HTTP/3 เปล่งประกายในเงื่อนไขเฉพาะ:
- ลิงก์ที่มี Latency สูง ซึ่งการลดจำนวน round trip เป็นการประหยัดเวลาที่คงที่
- เครือข่ายที่มีการสูญหายของแพ็กเก็ต ซึ่งการกำจัด HOL blocking ช่วยเพิ่มประสิทธิภาพ
- ไคลเอนต์มือถือที่เปลี่ยนเครือข่ายระหว่างเซสชัน
- การเชื่อมต่อระยะสั้นจำนวนมาก แทนที่จะเป็นการเชื่อมต่อระยะยาวไม่กี่ครั้ง
สำหรับ JSON API ทั่วไปที่ถูกใช้งานโดยเซิร์ฟเวอร์ในภูมิภาคเดียวกันบนเครือข่ายที่เชื่อถือได้ ความแตกต่างสามารถวัดผลได้ในการทดสอบเกณฑ์มาตรฐาน แต่ผู้ใช้ไม่สามารถรับรู้ได้ ข้อสังเกตเชิงปฏิบัติอีกสองประการ: พอร์ต UDP 443 ถูกบล็อกในเครือข่ายองค์กรบางแห่ง (ไคลเอนต์จะเปลี่ยนกลับไปใช้ HTTP/2 โดยอัตโนมัติ ดังนั้นจึงไม่มีอะไรเสียหาย) และการเข้ารหัสใน user-space ของ QUIC ในปัจจุบันใช้ทรัพยากร CPU ของเซิร์ฟเวอร์ต่อการเชื่อมต่อมากกว่า TCP ที่ปรับแต่งใน kernel
การสนับสนุนปัจจุบัน: ใครใช้ HTTP/3 ในวันนี้
การนำไปใช้งานก้าวหน้ากว่าที่นักพัฒนาแบ็กเอนด์ส่วนใหญ่คาดการณ์ไว้:
- เบราว์เซอร์: Chrome, Edge, Firefox และ Safari ล้วนมาพร้อมกับ HTTP/3 ที่เปิดใช้งานโดยค่าเริ่มต้น
- CDN และ Edge: Cloudflare, Fastly, Akamai และ CloudFront รองรับ; บน Cloudflare สามารถเปิด/ปิดได้ สำหรับทีมส่วนใหญ่ นี่คือแนวทางปฏิบัติจริง: หยุด HTTP/3 ที่ Edge, และใช้ HTTP/1.1 หรือ HTTP/2 จาก Edge ไปยัง Origin
- เซิร์ฟเวอร์: Nginx เพิ่ม HTTP/3 ในรุ่น 1.25 โดยมี
listen 443 quic;เป็นฟีเจอร์ทดลอง Caddy เปิดใช้งานโดยค่าเริ่มต้น LiteSpeed และ HAProxy รองรับ Apache httpd ไม่รองรับ - รันไทม์: Node.js ไม่มีเซิร์ฟเวอร์ HTTP/3 ในตัวที่เสถียร ซึ่งเป็นอีกเหตุผลหนึ่งที่การสิ้นสุดที่ Edge เป็นการใช้งานที่พบบ่อย
- curl: รองรับด้วยแฟล็ก
--http3เมื่อคอมไพล์โดยใช้ TLS stack ที่รองรับ HTTP/3; ดู เอกสาร HTTP/3 ของ curl สำหรับว่าบิลด์ใดบ้างที่รวมไว้
วิธีตรวจสอบว่า API ของคุณรองรับ HTTP/3 หรือไม่
การค้นพบทำงานผ่านเฮดเดอร์การตอบกลับ Alt-Svc เซิร์ฟเวอร์ที่โฆษณา HTTP/3 จะตอบกลับคำขอแรกของคุณ (HTTP/2) ด้วยบางอย่างเช่น:
alt-svc: h3=":443"; ma=86400
นั่นบอกไคลเอนต์ว่า: บริการเดียวกันนี้สามารถใช้งานได้ผ่าน HTTP/3 บนพอร์ต UDP 443 เป็นเวลา 24 ชั่วโมงข้างหน้า ตรวจสอบได้ด้วย curl:
curl -sI https://www.cloudflare.com | grep -i alt-svc
# alt-svc: h3=":443"; ma=86400
หากต้องการส่งคำขอผ่าน HTTP/3 โดยตรง (ต้องใช้ curl build ที่เปิดใช้งาน HTTP/3):
curl --http3 -I https://cloudflare-quic.com
# HTTP/3 200
บรรทัดสถานะจะรายงาน HTTP/3 แทนที่จะเป็น HTTP/2 ใน Chrome DevTools ให้เปิดแท็บ Network, คลิกขวาที่ส่วนหัวคอลัมน์, เปิดใช้งานคอลัมน์ Protocol และมองหา h3 ถัดจากการเรียก API ของคุณ ในสภาพแวดล้อมจริง ให้เพิ่มโปรโตคอลที่เจรจาได้ลงใน Access log ของคุณ; การแบ่งระหว่างทราฟฟิก h2 และ h3 จะบอกคุณว่าไคลเอนต์ของคุณได้รับประโยชน์มากน้อยเพียงใด
ในขณะที่คุณกำลังตรวจสอบ Transport ก็ควรตรวจสอบพฤติกรรมด้วย ชี้ Apidog ไปยังเอนด์พอยต์เดียวกันและยืนยันรหัสสถานะ, สกีมาการตอบกลับ และงบประมาณ Latency การได้เปรียบระดับ Transport นั้นไร้ค่าหากสัญญา API ภายใต้มีการเสียหาย และการตรวจสอบสัญญาคือชั้นที่คุณไม่สามารถใช้การเปลี่ยนแปลงโปรโตคอลมาช่วยได้ ดาวน์โหลด Apidog ฟรีและรันชุดทดสอบเดียวกันก่อนและหลังที่คุณเปิดใช้งาน HTTP/3 ที่ Edge ของคุณ; ความแตกต่างของเวลาตอบสนองบนเครือข่ายมือถือคือคำตอบที่แท้จริงของคุณ ไม่ใช่แค่พาดหัวข่าวการทดสอบเกณฑ์มาตรฐาน
คำถามที่พบบ่อย (FAQ)
HTTP/3 เร็วกว่า HTTP/2 หรือไม่?
บนเครือข่ายที่สะอาด มี Latency ต่ำ: แทบจะไม่แตกต่างกัน บนเครือข่ายที่มีการสูญหายของแพ็กเก็ตหรือ Latency สูง: ใช่ มักจะเห็นได้ชัดเจน เพราะ HTTP/3 ช่วยลด round trip ของการจับมือ และแพ็กเก็ตที่หายไปเพียงแพ็กเก็ตเดียวจะไม่ทำให้คำขอ multiplexed ทั้งหมดหยุดชะงักอีกต่อไป วัดผลด้วยโปรไฟล์ทราฟฟิกของคุณเองก่อนที่จะอ้างถึงข้อดีนี้ และจำไว้ว่า HTTP/2 ยังคงยอดเยี่ยมอยู่; หากคุณพบข้อผิดพลาดในการเชื่อมต่อ มักจะเป็นปัญหาที่ชั้น TLS เช่น ปัญหา SSLV3_ALERT_HANDSHAKE_FAILURE มากกว่าข้อจำกัดของโปรโตคอล
HTTP/3 ใช้ TCP หรือไม่?
ไม่ HTTP/3 ทำงานบน QUIC ซึ่งทำงานบน UDP โดยปกติแล้วจะใช้พอร์ต 443 QUIC สร้างความน่าเชื่อถือ, การจัดลำดับ และการควบคุมความแออัดที่ TCP เคยมีให้ขึ้นมาใหม่ แต่ทำเป็นรายสตรีมและใน user space หาก UDP 443 ถูกบล็อกบนเครือข่าย ไคลเอนต์จะเปลี่ยนกลับไปใช้ HTTP/2 ผ่าน TCP โดยอัตโนมัติ
ฉันต้องเปลี่ยนโค้ด API เพื่อรองรับ HTTP/3 หรือไม่?
แทบจะไม่เคยเลย ความหมายของ HTTP ไม่เปลี่ยนแปลง: เมธอดเดิม, เฮดเดอร์เดิม, รหัสสถานะเดิม และบอดี้เดิม งานส่วนใหญ่จะอยู่ที่โครงสร้างพื้นฐาน (การเปิดใช้งานที่ CDN, Load balancer หรือเซิร์ฟเวอร์ของคุณ) บวกกับการตรวจสอบการออกแบบหนึ่งข้อ: ตรวจสอบให้แน่ใจว่าข้อมูลเริ่มต้น 0-RTT ถูกจำกัดไว้สำหรับคำขอแบบ idempotent เท่านั้น
ฉันสามารถใช้ gRPC ผ่าน HTTP/3 ได้หรือไม่?
ส่วนใหญ่แล้วยังไม่ได้ในตอนนี้ รูปแบบการสื่อสารของ gRPC ผูกติดอยู่กับ HTTP/2 และไลบรารี gRPC หลักๆ ยังไม่รวม Transport ของ HTTP/3 .NET มีการรองรับเชิงทดลอง รักษาบริการ gRPC ไว้บน HTTP/2 และนำ HTTP/3 มาใช้ในส่วนที่ให้ผลตอบแทนก่อน: เอนด์พอยต์ REST ที่เป็นสาธารณะ, ที่หันหน้าเข้าหาเบราว์เซอร์ และที่หันหน้าเข้าหาอุปกรณ์มือถือ