อธิบายโพรโทคอล HTTP/3 แตกต่างจาก HTTP/1, HTTP/2, SPDY, QUIC อย่างไร

ข่าวเทคนิคที่น่าสนใจในช่วงไม่นานนี้คือ Cloudflare, Chrome, Firefox ร่วมมือกันรองรับ HTTP/3 หรือที่เราเคยรู้จักกันในชื่อ QUIC ที่กูเกิลเคยเสนอมาตั้งแต่ปี 2015

หลายคนอาจสงสัยว่าแล้ว HTTP/1, HTTP/2 (หรือ SPDY) และ HTTP/3 (QUIC) แตกต่างกันอย่างไร บทความนี้จะอธิบายวิวัฒนาการของเทคโนโลยี HTTP ให้เข้าใจกันแบบง่ายๆ ครับ



HTTP/1.0


โพรโทคอล HTTP/1.0 เกิดมาในยุคแรกๆ ของเว็บที่สร้างโดย Tim Berners-Lee และเพื่อนร่วมงานอีกจำนวนหนึ่ง โดยออกเป็นสเปกกลางในปี 1996 ซึ่งถือเป็นจุดเริ่มต้นของ HTTP ในปัจจุบัน

หลักการสำคัญของ HTTP คือเป็นการกำหนดวิธีการสื่อสารระหว่างเซิร์ฟเวอร์กับไคลเอนต์ ว่าจะส่งข้อมูลกันอย่างไร โดยเป็นการสื่อสารอยู่บนชั้นของโพรโทคอลเครือข่าย TCP อีกทีหนึ่ง

HTTP ยุคแรกเป็นการสื่อสารแบบไม่เข้ารหัส (unencrypted) โดยหลังจากนั้นไม่นานก็มีทีมงานของ Netscape สร้างโพรโทคอลสื่อสารแบบเข้ารหัส Secure Sockets Layer หรือ SSL ขึ้นมาใช้งานคู่กัน ซึ่งปัจจุบันมันเปลี่ยนชื่อเป็น Transport Layer Security (TLS) มาตั้งแต่ปี 1999

ภาพด้านล่างคือวิธีการทำงานของ HTTP/1.0 แบบเข้ารหัสด้วย TLS ซึ่งเราจะเห็นว่ากว่าสองฝั่งจะเจรจาเพื่อส่งข้อมูลกันสำเร็จ มีกระบวนการที่ "เยอะ" มากก่อนเริ่มส่งตัวข้อมูลจริงๆ (HTTP Response)



ภาพจาก Cloudflare

HTTP/1.1


ขั้นตอนการเจรจา (handshake) ที่เรื่องมากนี้ถูกเรียกว่า slow start เป็นผลให้ HTTP ทำงานช้ากว่าที่ควรจะเป็น ในปี 1997 จึงมีการพัฒนาโพรโทคอลเวอร์ชัน HTTP/1.1 ที่แก้ปัญหานี้ไป (บางส่วน)

ของใหม่ที่เพิ่มมาใน HTTP/1.1 คือเทคนิค "keep alive" (บ้างก็เรียก persistent connection) หรือการเปิดช่องทางการสื่อสารระหว่างไคลเอนต์กับเซิร์ฟเวอร์ทิ้งไว้หลังส่งข้อมูลเสร็จแล้ว เพื่อว่าหากมีการเรียกข้อมูลซ้ำอีกครั้ง (เช่น กดเปลี่ยนหน้าเพจหรือรีโหลดเพจ) จะได้ส่งข้อมูลผ่านท่อเดิม โดยไม่ต้องมาเริ่มเจรจากันใหม่อีกครั้ง



ภาพจาก Wikipedia

HTTP/2


HTTP/1.1 อยู่กับเรามานานถึง 18 ปี วงการเว็บพัฒนาไปจากเดิมมาก สิ่งสำคัญคือ HTTP/1.1 เกิดขึ้นในยุคที่เว็บเพจมีขนาดเล็กเพียงไม่กี่กิโลไบต์ มีรูปภาพเพียงเล็กน้อย แต่เว็บในช่วงหลังเพิ่มไฟล์ประเภทใหม่ๆ เข้ามาอีกหลายอย่าง ทั้งรูปภาพที่มีจำนวนและขนาดเยอะขึ้น, ไฟล์ประเภท CSS และ JavaScript ที่มักมีอีกหลายไฟล์

จำนวนไฟล์ที่มากขึ้นทำให้การส่งข้อมูลจากเซิร์ฟเวอร์มายังไคลเอนต์ แต่โพรโทคอล HTTP/1.1 อนุญาตให้เราส่งข้อมูลได้ครั้งละ 1 ไฟล์เท่านั้น การดาวน์โหลดจึงต้องต่อคิวกันเพื่อให้ดาวน์โหลดไฟล์ได้ครบตามต้องการ

เบราว์เซอร์จึงแก้ปัญหาด้วยการเปิดการเชื่อมต่อพร้อมกันหลายๆ อันเพื่อดาวน์โหลดไฟล์ขนานกันไป ซึ่งก็มีข้อเสียคือต้องมีกระบวนการเจรจาเริ่มส่งข้อมูลกันทุกครั้งไป ไม่ได้ใช้ประโยชน์จากการเปิดท่อค้างไว้ (keep-alive) อย่างที่ควรจะเป็น

ปัญหานี้ถูกแก้ไขในอีกสิบกว่าปีให้หลัง โดยกูเกิลเสนอโพรโทคอลชื่อ SPDY ในปี 2009 (อ่านว่า สปีดดี้) โดยมีเว็บเบราว์เซอร์รายอื่นเข้าร่วมสนับสนุนมากขึ้นเรื่อยๆ และภายหลังก็ผลักดันเป็นมาตรฐาน HTTP/2 ในปี 2012 และ ทำสำเร็จในปี 2015

หลักการสำคัญของ SPDY หรือ HTTP/2 คือการยอมให้การเชื่อมต่อผ่าน HTTP หนึ่งท่อ สามารถส่งไฟล์ได้พร้อมกันหลายไฟล์ (ชื่อทางเทคนิคเรียกว่า stream หรือกระแสน้ำ) ช่วยให้เราเปิดการเชื่อมต่อ HTTP เพียงครั้งเดียวแล้วสบายไปตลอด



ภาพจาก Cloudflare

HTTP/3


มาตรฐาน HTTP/2 ดูจะแก้ปัญหาสำคัญของการส่งข้อมูลผ่าน HTTP ไปทั้งหมดแล้ว แต่ก็ยังมีข้อจำกัดอยู่ที่ระดับเลเยอร์ต่ำลงไป นั่นคือการส่งข้อมูลแบบ TCP (Transmission Control Protocol)

สมาชิก Blognone ที่เคยเรียนวิชาด้านเน็ตเวิร์คมาบ้าง คงพอทราบความแตกต่างของ TCP และ UDP (User Datagram Protocol) ถึงเรื่องความน่าเชื่อถือ (reliability) ของวิธีการส่งข้อมูลทั้งสองแบบ

• TCP น่าเชื่อถือกว่า ข้อมูลไม่หาย แต่ช้ากว่า เพราะต้องยืนยันข้อมูลกลับไปยังต้นทางว่าได้ข้อมูลครบ
• UDP กลับกันคือไม่มีกระบวนการยืนยันข้อมูลกลับไปยังต้นทาง ทำให้การเชื่อมต่อเร็วกว่ามาก

อย่างที่เขียนไปข้างต้นว่าเว็บยุคหลังมีชนิดของข้อมูลเพิ่มขึ้นจากในอดีตมาก เช่น รูปภาพ คลิปวิดีโอ ฯลฯ แต่เมื่อเราส่งทุกอย่างผ่านโพรโทคอล TCP เหมือนกัน อาจไม่ตอบโจทย์ของข้อมูลต่างชนิดกัน (เช่น ข้อมูลประเภทวิดีโออาจยอมให้สูญเสียข้อมูลได้บ้าง)

ในปี 2015 กูเกิล (อีกแล้ว) จึงเสนอโพรโทคอลใหม่ชื่อ QUIC (อ่านว่า "ควิก") ซึ่งเป็นการตั้งชื่อล้อกับ SPDY นั่นเอง



ภาพจาก Google

ชื่อ QUIC ย่อมาจาก Quick UDP Internet Connections ซึ่งจากชื่อเต็มคงพอนึกออกว่ามันเปลี่ยนมาใช้ UDP ช่วยส่งข้อมูลแทน TCP

นอกจากนั้น QUIC ยังปรับแก้ปัญหาเรื่องกระบวนการ handshake ที่ล่าช้าของ HTTP (โดยเฉพาะถ้ารวมการเข้ารหัส TLS อีกชั้น) ด้วยการออกแบบกระบวนการ handshake ใหม่ให้รวม TLS 1.3 มาด้วยเลย (แปลว่า QUIC เข้ารหัสทุกกรณีเสมอ) ผลคือ QUIC ทำงานได้รวดเร็วขึ้นทั้งในขั้นตอนเจรจา (handshake) และการส่งตัวข้อมูลจริงๆ



ภาพจาก Cloudflare

QUIC ถูกเสนอเข้าเป็นมาตรฐาน HTTP/3 ในที่ประชุมของ IETF ซึ่งวนมาจัดที่กรุงเทพเมื่อเดือนพฤศจิกายน 2018 ซึ่งก็สามารถพูดได้เต็มปากว่า HTTP/3 เกิดขึ้นที่กรุงเทพ (สถานที่จัดงานแบบเจาะจงคือ Marriott Marquis Queen’s Park ข้างสวนเบญจกิติ)

สถานะของ HTTP/3 ในโลกจริงยังถือว่าเพิ่งเริ่มต้น ขณะที่เขียนบทความนี้

• Chrome รองรับแล้วที่เวอร์ชัน Canary
• Firefox Nightly จะเริ่มรองรับช่วงปลายปี 2019 นี้
• curl เพิ่งรองรับในฐานะฟีเจอร์ทดลอง (experimental) ต้องดาวน์โหลด curl เวอร์ชันล่าสุดจาก GitHub มาเอง
• ฝั่งเซิร์ฟเวอร์ Cloudflare รองรับผ่านซอฟต์แวร์ที่เขียนเองชื่อ Quiche
• Nginx เพิ่งประกาศวางแผนรองรับ HTTP/3 เมื่อเดือน พ.ค. 2019

ภาพประกอบทั้งหมดที่ระบุว่ามาจาก Cloudflare มาจาก Cloudflare Blog

Topics: HTTPSPDYInternetTCPNetworkIn-Depth