ข่าวเทคนิคที่น่าสนใจในช่วงไม่นานนี้คือ Cloudflare, Chrome, Firefox ร่วมมือกันรองรับ HTTP/3 หรือที่เราเคยรู้จักกันในชื่อ QUIC ที่กูเกิลเคยเสนอมาตั้งแต่ปี 2015
หลายคนอาจสงสัยว่าแล้ว HTTP/1, HTTP/2 (หรือ SPDY) และ HTTP/3 (QUIC) แตกต่างกันอย่างไร บทความนี้จะอธิบายวิวัฒนาการของเทคโนโลยี HTTP ให้เข้าใจกันแบบง่ายๆ ครับ
โพรโทคอล 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
ขั้นตอนการเจรจา (handshake) ที่เรื่องมากนี้ถูกเรียกว่า slow start เป็นผลให้ HTTP ทำงานช้ากว่าที่ควรจะเป็น ในปี 1997 จึงมีการพัฒนาโพรโทคอลเวอร์ชัน HTTP/1.1 ที่แก้ปัญหานี้ไป (บางส่วน)
ของใหม่ที่เพิ่มมาใน HTTP/1.1 คือเทคนิค "keep alive" (บ้างก็เรียก persistent connection) หรือการเปิดช่องทางการสื่อสารระหว่างไคลเอนต์กับเซิร์ฟเวอร์ทิ้งไว้หลังส่งข้อมูลเสร็จแล้ว เพื่อว่าหากมีการเรียกข้อมูลซ้ำอีกครั้ง (เช่น กดเปลี่ยนหน้าเพจหรือรีโหลดเพจ) จะได้ส่งข้อมูลผ่านท่อเดิม โดยไม่ต้องมาเริ่มเจรจากันใหม่อีกครั้ง
ภาพจาก Wikipedia
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/2 ดูจะแก้ปัญหาสำคัญของการส่งข้อมูลผ่าน HTTP ไปทั้งหมดแล้ว แต่ก็ยังมีข้อจำกัดอยู่ที่ระดับเลเยอร์ต่ำลงไป นั่นคือการส่งข้อมูลแบบ TCP (Transmission Control Protocol)
สมาชิก Blognone ที่เคยเรียนวิชาด้านเน็ตเวิร์คมาบ้าง คงพอทราบความแตกต่างของ TCP และ UDP (User Datagram Protocol) ถึงเรื่องความน่าเชื่อถือ (reliability) ของวิธีการส่งข้อมูลทั้งสองแบบ
อย่างที่เขียนไปข้างต้นว่าเว็บยุคหลังมีชนิดของข้อมูลเพิ่มขึ้นจากในอดีตมาก เช่น รูปภาพ คลิปวิดีโอ ฯลฯ แต่เมื่อเราส่งทุกอย่างผ่านโพรโทคอล 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 ในโลกจริงยังถือว่าเพิ่งเริ่มต้น ขณะที่เขียนบทความนี้
ภาพประกอบทั้งหมดที่ระบุว่ามาจาก Cloudflare มาจาก Cloudflare Blog
