HTTP/3 คืออะไร
ค̶น̶เ̶ร̶า̶ ̶h̶y̶p̶e̶ ̶อ̶ะ̶ไ̶ร̶แ̶ล̶̶้ว̶ต̶̶้อ̶ง̶ ̶h̶y̶p̶e̶ ̶ใ̶ห̶̶้ส̶̶ุด
บังเอิญได้ไปเจอ HTTP/3 Explained ของเทพ Daniel Stenberg (เจ้าของ cURL) เข้าพอดี บวกกับเนื้อหา HTTP/3 นั้นยังมีน้อย ส่วนใหญ่เป็น draft จึงเหมาะที่จะมาเขียนอธิบาย โดยจะเสนอไอเดียภาพรวมให้เข้าใจว่า HTTP/3 นั้นคืออะไร แปลกแค่ไหน ต้องเตรียมพร้อมอย่างไรบ้างครับ
Prerequisites
ตัว HTTP/3 เองนั้นมีเนื้อหาไม่มาก แต่ใช้ความรู้พื้นฐานอื่น ๆ สูง จึงควรจะต้องมีความเข้าใจในเนื้อหาข้างล่างก่อนอ่านอันนี้ครับ ทั้งนี้ผมก็เคยเขียนบทความภาษาไทยให้กับทั้ง HTTP/2 และ QUIC ให้อ่านได้ง่ายอยู่แล้ว
- พื้นฐาน TCP/IP networking
- พื้นฐานการทำงาน HTTP
- HTTP/2 หรือ https://daniel.haxx.se/http2/
- QUIC — ทั้งนี้ก็ยังแนะนำให้อ่านอ้างอิงด้วยเช่นกัน [1] มีการวิเคราะห์เชิง network หลายตัวที่ผมไม่ได้พูดถึง เช่น idea Ossification, User space เป็นต้น
History
QUIC ถูกเริ่มพัฒนามาตั้งแต่ปี 2012 และถูกใช้ publicly โดย Google ตั้งแต่ปี 2013 ทั้งนี้เพิ่งเริ่มถูกนำมาพยายามทำให้เป็น standard โดย IETF ในปลายปี 2016
ระหว่างที่พยายามทำ standard ก็มีมุมมองต่อ QUIC ที่แตกต่างจาก Google หลายด้าน เช่น
- QUIC มันน่าจะ support protocol อื่นๆด้วย (มากกว่าแค่ HTTP)
- น่าจะใช้ TLS1.3 มากกว่า custom crypto (ของ Google) นะ
ดังนั้นเพื่อให้รองรับมากกว่าแค่ HTTP ทาง IETF จึงแบ่ง QUIC architecture ออกเป็น 2 ส่วน คือ
- transport QUIC
- HTTP over QUIC (ย่อว่า hq)
การแบ่งออกเป็น 2 ส่วนนี้ ทำให้ QUIC ของ IETF นั้นแตกต่างจากของ Google พอสมควร ทั้งนี้เราควรยึด standard ที่กำลังจะออกมาของ IETF เป็นหลักนะครับ แม้แต่ Google เองก็พยายามค่อยๆปรับให้เข้ากับ standard ที่กำลังจะออกมาด้วยเช่นกัน แต่เอาจริง ๆ คือ ผมก็ไม่เคยอ่าน standard Google นะ :S
ในปลายปี 2018 IETF meeting #103 ที่กรุงเทพนี่เอง HTTP over QUIC ถูกเปลี่ยนชื่อเป็น HTTP/3
What is HTTP/3
อย่างที่ได้เกรินไปแล้ว HTTP/3 มันมาจาก HTTP over QUIC แปลตรงๆ มันก็คือการนำ HTTP protocol มา transport ผ่าน QUIC นั่นเอง โดยไอเดียหลายๆอย่างจะคล้ายกับ HTTP/2 มาก คือเป็นการแก้การ transport HTTP over network ให้มีความ effective มากขึ้นนั่นเอง ส่วน HTTP paradigms, concepts, headers, body, request, response, verbs, cookies, caching จะยังคงเหมือนเดิมทุกประการ
การเปลี่ยนจาก over TCP มาเป็น over QUIC ก็จะทำให้ได้รับประโยชน์ทุกอย่างจาก QUIC แต่ในขณะเดียวกันก็จะได้รับผลเสียจาก QUIC ด้วยครับ ตรงไปตรงมา ตัว QUIC เองก็มี draft ของตัวเองอยู่แล้วจึงทำให้ draft นี้ไม่ได้หนาแบบ draft อื่น ๆ แน่นอนว่าการเปลี่ยนจาก over TCP มาเป็น over QUIC นั้นต้องมีการแก้ไข เราจึงไม่สามารถเอา HTTP/2 มา over QUIC เฉยๆได้ นั่นคือที่มาของ draft HTTP/3 อันนี้ครับที่จะอธิบายว่าเราจะเอา HTTP มาอยู่บน QUIC ได้อย่างไร ต้องเพิ่มลดอะไรบ้าง
ความแตกต่างในการย้าย HTTP/2 มา HTTP/3 นั้นได้แก่
Initial connection
ไอเดียนี้ผมเคยเกริ่นให้ใน QUIC ไปแล้วครับ สำหรับการเชื่อมต่อครั้งแรก browser จะทำการเปิด connection TLS ปกติก่อน (ซึ่งคาดว่าจะเป็น HTTP/2) ในการทำ handshake แล้วจึงค่อยดู server support จาก response header (Alt-srv) อีกที ดังนั้นจึงไม่เสียเวลาอะไร ต่อให้อีกฝั่งไม่ support ก็ตาม
QUIC streams and HTTP/3
ตรงนี้คือจุดสำคัญ HTTP/3 ไม่ได้เอา HTTP/2 มาวางบน QUIC แต่เป็นการ revise ใหม่อีกที HTTP/3 มองว่าควรที่จะใช้ streams ของ QUIC ทีเดียวเลย ไม่ซ้ำซ้อน และที่สำคัญ ได้ performance ที่ดีกว่าด้วย คือไม่มี head-of-line blocking ทั้งบนชั้น application และ transport อีกทั้งยังมีจำนวน streams ที่สูงกว่า HTTP/2 มาก
TLDR; HTTP/3 บอกว่าให้เปลี่ยน HTTP/2 multiplexing มาใช้ QUIC multiplexing แทน
ทั้งนี้ข้อดีมาพร้อมข้อเสีย streams ของ QUIC เนี่ย จะ guarantee order เฉพาะใน streams เส้นเดียวกันเท่านั้น ไม่ได้มีการไปพิจารณา order ของ streams อื่น ให้ทำการ maps QUIC stream เข้ากับ HTTP transaction หรือ connection context เอา
When HTTP headers and data are sent over QUIC, the QUIC layer handles most of the stream management. HTTP does not need to do any separate multiplexing when using QUIC - data sent over a QUIC stream always maps to a particular HTTP transaction or connection context.ปล. ผมไม่ชอบคำว่า does not need to do เลย เพราะมันกำกวมว่า ใช้ก็ได้ ไม่ใช้ก็ได้ น่าจะใช้ศัพท์ MUST/SHOULD/SHOULD NOT ตาม RFC standard นะ :/
HTTP/2 Features and Settings
แต่ในขณะเดียวกัน ก็ไม่ได้โยน features ของ HTTP/2 ทิ้งไปทั้งหมด ใน document มีการอธิบายการ map features, frames, flags ต่างๆ และบางตัวที่เอาออก (แต่ bit ถูก reserved ไว้สำหรับ compatibility) เช่น
- stream number — ไม่จำเป็นต้องมี เพราะ frame อยู่บน stream อยู่แล้ว
- variable-maximum-length — เอาออก ใช้ QUIC multiplexing แทน
- END_STREAM flag — เอาออก ใช้ feature ของ QUIC
- HTTP/2 prioritization — ไปใช้ HTTP/3 PRIORITY frame บน control stream
นอกจากนี้ HTTP/2 SETTINGS หลายๆตัว ก็ถูก QUIC transport parameters เข้ามาแทนที่แทน ซึ่ง HTTP option ทุกตัวยังคงมีค่าเหมือนใน HTTP/2 อยู่
และเนื่องจาก HTTP/3 นั้นใช้ streams ของ QUIC แล้ว จึงไม่สามารถใช้ header compression — HPACK ของ HTTP/2 ตามปกติได้ ก็มีการนำเสนอ algorithm ตัวใหม่ชื่อ QPACK ด้วย
สำหรับคนที่อยากรู้ลึกกว่านี้ (ซึ่งเริ่มอ่านยากละ) แนะนำให้เข้าไปอ่าน draft เองเลยครับ (ใช่ผมไล่ 555) [2][3][4]
มีอะไรดีกว่า HTTP/2 ?
ก็มี QUIC ไงคับ 555 ลองกลับไปอ่านบทความ QUIC ของผมดูนะครับ — เช่น ลด latency handshake, พัฒนา congestion control, ลด head of line blocking, etc.
มีอะไรแย่กว่า HTTP/2 ?
ก็มี QUIC นั่นอีกแหละครับ 555 — พูดจริง เช่น การเปลี่ยน TCP เป็น UDP อาจจะทำให้ถูก block ได้ง่าย เป็นต้น
สรุป
จะเห็นว่าจริงๆ มันก็ไม่ได้เยอะอะไร สำหรับคนที่รู้ QUIC อยู่แล้ว (จากบทความก่อนของผม) อันนี้มันก็คือการพยายามร่าง standard ให้ถูกต้องว่าจะเอา HTTP มาอยู่บน QUIC ได้อย่างไรนั่นเอง
ส่วนตัวเห็นว่าการเปลี่ยนชื่อจาก HTTP over QUIC มาเป็น HTTP/3 นั้นก็ถือว่าถูกต้องแล้ว เพราะ HTTP over QUIC นั้นสร้างความกำกวมขึ้นมาว่าเป็น HTTP/1.1 หรือ HTTP/2 กันแน่ ? โดยที่ในความเป็นจริง มันไม่ใช่ทั้ง HTTP/1.1 และ HTTP/2 แต่เป็น version ใหม่จริงๆ ที่ถูกเขียน standard มาเพื่อ QUIC เท่านั้น
ปัจจุบันจากอ้างอิง [1] ยังไม่มี web server หรือ browser หลักตัวไหน implement อันนี้เสร็จเลยแม้แต่ตัวเดียวครับ แต่จากมุมมองผม ยังเป็นเพราะว่า versioning กับ standard นั้นยังไม่ stable พอที่คนจะเอาไปใช้ หรืออ่านให้เข้าใจได้โดยง่าย จึงยังรอเวลากันอยู่ครับ แต่จากความพยายามที่จะรักษา compatibility ต่าง ๆ ของ HTTP/2 เช่น รักษา frame structure ไว้ ผมคิดว่าน่าจะปรับให้ support ได้ไม่ยากมากและไม่น่าจะมีปัญหาจาก infrastructure ตรงกลางต่าง ๆ ครับ
- Feb 12, 2019 -
References
[1] https://http3-explained.haxx.se/en/
[2] https://tools.ietf.org/html/draft-ietf-quic-http-18
[3] https://tools.ietf.org/html/draft-ietf-quic-tls-18
[4] https://tools.ietf.org/html/draft-ietf-quic-qpack-06
[5] https://medium.com/@DarkDrag0nite/http-2-%E0%B8%84%E0%B8%B7%E0%B8%AD%E0%B8%AD%E0%B8%B0%E0%B9%84%E0%B8%A3-331b3e7b5866
[6] https://medium.com/@DarkDrag0nite/quic-protocol-0-rtt-connection-magic-%E0%B8%AB%E0%B8%A3%E0%B8%B7%E0%B8%AD-design-%E0%B8%A1%E0%B8%B5%E0%B8%AD%E0%B8%A2%E0%B8%B9%E0%B9%88%E0%B9%81%E0%B8%84%E0%B9%88%E0%B8%99%E0%B8%B5%E0%B9%89%E0%B8%AB%E0%B8%A3%E0%B8%B7%E0%B8%AD%E0%B8%A1%E0%B8%B5%E0%B8%82%E0%B8%AD%E0%B8%87%E0%B8%94%E0%B8%B5%E0%B8%AD%E0%B8%B7%E0%B9%88%E0%B8%99%E0%B9%86%E0%B8%94%E0%B9%89%E0%B8%A7%E0%B8%A2-9832c41ddc6a
* [3][4] ไม่ได้ถูกใช้ในบทความนี้ ใส่มาเผื่ออยากอ่าน ส่วน version ผมอ้างอิงจากวันที่เขียน ผู้อ่านควรตรวจสอบความใหม่ก่อนอ่านเองนะครับ
