HTTP/2 คืออะไร

6 min readJan 11, 2016

ช่วงนี้หลายๆคนน่าจะเคยได้ยิน HTTP/2 มาพอสมควร วันนี้จะมาอธิบายให้ฟังว่า HTTP/2 เนี่ยจริงแล้วมันคืออะไร ทำงานยังไง ทำไมมันถึงเร็วขึ้น แล้วเราควรจะเปลี่ยนไปใช้มันหรือปล่าว หลังจากอ่าน blog นี้แล้ว น่าจะได้ไอเดียมากพอสมควร ใน blog นี้ผมจะอธิบายให้ลง technical นิดหนึ่ง เพื่อให้คนที่เรียนสายนี้มาเข้าใจมากขึ้น ในขณะเดียวกันคนทั่วไปก็สามารถอ่านข้ามๆได้โดยใช้การเชื่อมโยงทั่วๆไป เมื่ออ่านแล้วจะเห็นว่าหลักการของมันไม่ได้ยากหรืออยู่สูงเอื้อมไม่ถึงขนาดนั้น

ผมอ้างอิงเนื้อหาส่วนใหญ่จาก http2 explained ซึ่งเขียนโดย Daniel Stenberg เนื่องจากเขียนมาได้ครอบคลุมตรงประเด็นหลายจุดและเข้าใจได้ง่าย ทั้งนี้ผมจะเปลี่ยนวิธีอธิบายบางจุดให้ง่ายขึ้น แล้วจะมาวิเคราะห์ข้อดีข้อเสียของ HTTP/2 ต่อหลังจากอธิบายหลักการทำงานแล้วอีกที

ขอเริ่มด้วยปัญหาของ HTTP/1.1 ก่อน เพราะถ้าเราเข้าใจปัญหาของ HTTP/1.1 แล้ว มาอ่านหลักการทำงานของ HTTP/2 เราจะเห็นว่ามันตรงไปตรงมามาก ไม่ได้ยากอะไรเลย ขณะเดียวกัน ถ้าผมพูดหลักการ HTTP/2 เลย หลายคนอาจจะงงว่า เอ๊ะ ไม่มีอะไรนิ ทำไม HTTP/1.1 ไม่ทำ ทำไมต้องเป็น 2 อะไรแบบนี้ แต่ถ้าคนที่เข้าใจปัญหาและหลักการของ HTTP เดิมดีอยู่แล้ว สามารถข้ามไปได้เลยครับ

HTTP/1.1 ในปัจจุบัน

ปัจจุบัน HTTP/1.1 ที่เราใช้กันอยู่แล้วรู้สึกเหมือนว่าไม่มีปัญหาอะไรเนี่ย เบื้องหลังมันมีปัญหาอยู่พอสมควร ซึ่งปัญหาเหล่านี้ เกิดจากยุคสมัยที่เปลี่ยนไป ปริมาณของข้อมูลบนหน้าเว็ปหนึ่งๆมีจำนวนมากขึ้น เราอยากได้อะไรที่มัน portable-mobile มากขึ้น real-time มากยิ่งขึ้น เป็นต้น ปัญหาของ HTTP/1.1 ที่เกิดขึ้นมา ได้แก่

1. โครงสร้างของ HTTP/1.1 ในปัจจุบัน เราทราบว่า HTTP เป็น protocol ดังนั้นโครงสร้างของมันคือข้อตกลงต่างๆที่ร่างเอาไว้ใน RFC นั่นเอง ถ้าเข้าไปนั่งไล่ดูจะพบว่า HTTP/1.1 มันมีรายละเอียดมันมหาศาลมาก ในขณะเดียวกัน features หลายๆตัวที่เคยถูกเขียนขึ้นมาเป็นมาตรฐาน ก็กลับไม่ได้นำไปใช้จริงเพราะมีปัญหาต่างๆในการใช้ ตัวอย่างที่เห็นได้ชัดในกรณีนี้คือ pipelining (ผมจะอธิบายว่าทำไม pipelining จึงมีปัญหาและไม่ใช้กัน ข้างล่าง)

2. ขนาดของ transfer size (จำนวน data ที่ต้องมีการ transfer ใน 1 หน้าเว็ป) กับจำนวน object (จำนวนครั้งที่ต้อง request) นั้นเพิ่มขึ้นตลอดเวลา 20 ปีที่ผ่านมา (HTTP/1.1 ประกาศปี 1999)

3. ตัว HTTP/1.1 เองค่อนข้าง sensitive กับ RTT (round trip time) มาก คือหาก RTT เพิ่มขึ้นเล็กน้อย จะเกิดปัญหา latency ในการโหลดหน้าเว็ปเพิ่มขึ้นมา

4. Head of line blocking (HOLB) อาจจะฟังดูแปลกๆ ให้จินตนาการว่าซื้อของใน supermarket แล้วกำลังจะจ่ายตัง เราซื้อแค่น้ำเปล่าขวดเดียว พอต่อแถวเสร็จ พี่คนข้างหน้าเราล้วงของออกมากองโตล้นเคาทเตอร์เลย อันนี้เป็นการสูญเสีย performance อย่างเห็นได้ชัด ทั้งนี้ HTTP/1.1 ไม่สามารถสลับลำดับได้ และการเปิดแถวใหม่ (new connection) ก็ใช้เวลาและ resource ของเครื่องจำนวนมากเช่นกัน

ปัญหาของ Pipelining ใน HTTP/1.1 และวิธีแก้ไข

เหตุผลที่ปัจจุบันไม่ใช้ pipelining ใน HTTP/1.1 นอกจากปัญหาข้อ 4 แล้ว ยังมีปัญหาเรื่องการ implement ที่ยากลำบาก และมีข้อจำกัดอยู่จำนวนมาก (มากๆๆๆ) ในการใช้ pipelining โดยไม่ให้เกิดข้อผิดพลาดอีกด้วย ทั้งนี้มาจากหลักการของ HTTP/1.1 เองที่เป็นแบบ stateless คือ request อะไรไป จะรอจนกว่าจะได้ response อันนั้นตอบกลับมา สลับที่ไม่ได้ ฟังดูง่าย แต่เพราะความง่ายเกินของมันทำให้มีปัญหา วิธีการป้องกันปัญหาของ pipelining บางอย่าง เช่น

ส่วนหนึ่งของ Practical Consideration of pipelining จาก RFC2616-sec8

A client wishing to send a non-idempotent request SHOULD wait to send that request until it has received the response status for the previous request.

จะเห็นว่า request ที่ทำให้ data เปลี่ยนแปลง ควรรอจนกว่า request อันเก่าจะส่งกลับมา ไหนจะเรื่อง out-of-order ที่อาจจะทำให้มีปัญหาข้อมูลสลับกัน (จากการเป็น stateless) ถ้าพยายามแก้ไขปัญหาข้างต้นก็จะเกิด head-of-line-blocking เหมือนเดิม ซึ่งกรณีใช้ pipeline ใน HTTP/1.1 นั้นกับกรณีที่ไม่ใช้ ความเร็วก็แทบไม่ต่างกันเลย features นี้จึงเป็นแค่ history สำหรับ HTTP/1.1 ไป

ในปัจจุบันเราแก้ไข RTT ด้วยวิธีอื่นๆแทน เช่น

Open new connection เพื่อให้สามารถส่งข้อมูลใกล้เคียงกับ pipelining ให้ได้มากที่สุด เราก็เปิดหลายๆแถวดิ ปัจจุบันจำนวน connection ที่รองรับส่วนใหญ่ค่าอยู่ประมาณ 6–8 connections แล้วแต่ค่า config ของ server และ browser ที่ใช้
Spriting คือการรวมรูปเล็กๆมากๆ เข้าเป็นรูปใหญ่ 1 รูป แล้วให้ javascript หรือ CSS ปลายทางในการตัดรูปออกมาอีกทีหนึง วิธีนี้จะลดจำนวนการ transfer ลงได้ ให้เหลือการส่งเพียงครั้งเดียว แต่ถ้าหากใช้แค่รูปสองรูปล่ะ หากใช้วิธีนี้ รูปใหญ่ๆก็ถูกส่งมาอยู่ดี วิธีที่คล้ายๆกันคือ Inlining ของรูป และ Concatenation ของไฟล์ js
Sharding คือการแบ่งเก็บข้อมูลไว้หลายๆ server อันนี้เพราะ max_connection ระหว่าง client-server ที่ระบุทั่วไปอยู่ประมาณ 6–8 ดังนั้น ถ้าใช้หลายๆ server ก็จะเพิ่มประมาณ connection ที่สามารถใช้ได้ หลายคนน่าจะเคยเห็นอะไรแบบรูปข้างล่างมาบ้าง เช่น img1.someweb.com img2.someweb.com
ยังมีวิธีแก้อีกหลายแบบที่ลด bandwidth (ไม่ได้ลด RTT) เช่น การ compress ข้อมูลก่อนส่ง ลด header และอื่นๆอีกมาก

Sharding From HTTP2-Explained (Edited to reduce image size)

จากการแก้ปัญหาข้างต้น เราจะเห็นว่าเป็นการแก้ปัญหาเฉพาะหน้า ซึ่งหลายได้ผลที่น่าพึงพอใจ (ความเร็วโหลดเพิ่มขึ้น) แต่ถ้าเราพิจารณาจะเห็นว่า การแก้ปัญหาเหล่านั้น ไม่ใช่การแก้ปัญหาที่ต้นเหตุเลย ยิ่งนับวัน วิธีการแก้จะเพิ่มขึ้น ต่างคนต่างแก้ มาตรฐานน้อยลง ความกำกวมเพิ่มขึ้น ความ simplicity ของมันลดลง ล้วนแล้วแต่จะทำให้เกิดปัญหาขึ้น จึงเป็นที่มาที่กลุ่ม IETF พิจารณาสร้าง HTTP/2

กำเนิด HTTP/2

กลุ่ม IETF จึงได้ร่างโครงสร้าง HTTP/2 และปรับแต่งจนสมบูรณ์ โดยยึดเอาพื้นฐานจาก SPDY ของ Google (ป๋ากรูอีกแล้ว โหดขิงๆ) ซึ่งได้พิสูจน์แล้วว่าหลักการนั้นสามารถลด latency time ได้จริงๆ หลักการที่เห็นได้ชัดที่สุดของ HTTP/2 (ซึ่ง SPDY ก็มี) เห็นจะเป็น Multiplexing ซึ่งเปรียบเสมือนการ pipelining นั่นเอง

หลักการต่างๆของ HTTP/2

หลักการที่สำคัญมากคือ HTTP/2 นั้นไม่ได้แก้ไขการเรียกใช้งาน HTTP ที่มีอยู่แล้ว เรื่อง high-level ยังคงเหมือนเดิมเราสามารถใช้ get post method status header field (เกือบทั้งหมด) ได้ตามปกติ เพียงแต่ HTTP/2 นั้นเป็นการวางฐานของการส่งข้อมูล HTTP ใหม่ (ระดับ transfer) ให้ดีขึ้นกว่าเดิม ดังนั้น code ของ web ต่างๆยังคงเขียนได้เหมือนเดิมไม่ต้องเปลี่ยนแปลง (compatibility เป็นเรื่องปกติที่ต้องพิจารณาในการร่าง protocol ใหม่อยู่แล้ว)

Multiplexed streams

Stream แปลตรงๆตัวคือเส้นสาย มันคือสายที่ใช้ในการ transfer ข้อมูลภายใน connection อีกที โดยหนึ่ง TCP connection สามารถมีได้หลาย HTTP/2 streams แต่ละ stream สามารถส่งข้อมูลแบบ bi-directional ได้ สร้างได้ ปิดได้ อีกทั้งยังมีระบบ flow control สำหรับควบคุมปริมาณข้อมูลในแต่ละ stream อีกด้วย พูดถึงขนาดนี้ หลายคนจินตนาการว่ามันคือ mini-connection ใน TCP connection อีกทีก็ไม่ผิดครับ ตัวผมเองก็ชอบเปรียบเทียบเป็นท่อส่งข้อมูล ซึ่ง idea จะประมาณภาพข้างล่างครับ เราสามารถลด connections 3 อันให้เหลือ connection เพียงอันเดียว แล้วให้ข้างในเป็น 3 streams แทน

แต่ในความเป็นจริง เราไม่ได้แบ่ง stream ชัดเจนแบบเป็นสายขนาดนั้น ตัวอย่างความเป็นจริง จะประมาณรูปรถไฟข้างล่าง เราแบ่งโดยใช้ stream_id เป็นตัวกำกับเพิ่มเข้าไป ก็เพียงพอแล้วที่จะบอกได้ว่าข้อมูลเป็นของสายไหน เหมือนแปะชื่อติดไว้ที่โบกี้แต่ละอัน ดังภาพข้างล่าง ซึ่งแก้ปัญหา pipelining, HOLB ได้อย่างดีเยี่ยมเลย แม้จะฟังดูตรงไปตรงมา แต่ feature นี้ไม่สามารถถูกเพิ่มหรือแก้ไขใน HTTP/1.1 ได้ เนื่องจากเป็นการเปลี่ยนพื้นฐานของ HTTP/1.1 เลย

มาถึงตรงนี้ จะเห็นว่ามันก็จะไม่มีปัญหา out-of-order หรือ head-of-line blocking แบบ HTTP/1.1 ละ เพราะแต่ละโบกี้นั้นมีติดป้ายชื่ออยู่แล้ว ตอน server ตอบ ก็แค่ระบุว่าตอบของอันไหนอยู่เท่านั้น สลับที่ได้ ไม่มีปัญหา

รถไฟ 2 ขบวน (เปรียบเสมือน 2 connections) From HTTP2-Explained

รวมเป็นขบวนเดียว (1 connection) แล้วติดป้ายชื่อระบุ stream เอา (stream_id) From HTTP2-Explained

ข้อดีอื่นๆของการลด TCP connection นั้น ทำให้การเชื่อมต่อต่างๆเกิดขึ้นได้เร็วขึ้นด้วย เพราะใช้เพียง connection เดียวก็เพียงพอ หากเว็บมีการเข้ารหัส (HTTPS) กระบวนการแลกเปลี่ยนคีย์ก็เกิดขึ้นเพียงครั้งเดียวด้วยซึ่งประหยัดเวลาและ CPU เครื่องไปได้ ข้อดีอื่นๆในการ develop web ได้แก่ การยกเลิก domain sharding, image spriting, การรวม CSS และ javascript ไปได้ (และสมควรยกเลิกด้วย)

2. Binary Protocol ปรับค่าต่างๆให้อยู่ในรูปของ binary คือ options ต่างๆจะไม่อยู่ในรูปที่คนอ่านได้อีกต่อไป แต่จะอยู่ในรูปของ 0 1 ที่เป็น computer-friendly แทน (ถ้า HTTP/1.1 จะอ่านออกเลย เช่น GET /index.php HTTP/1.1 etc)

ข้อดีคือ คอมพิวเตอร์สามารถจัดการข้อมูลต่างๆได้เร็วขึ้นมาก การ framing จะทำได้ง่ายและมีขนาดคงที่ ปริมาณ bandwidth ลดลง แต่ข้อเสียคือ ไม่สามารถให้คน monitor แบบปกติได้ จำเป็นต้องใช้ tool ในการช่วย เช่น wireshark

3. Header Compression เนื่องจาก header ของ HTTP นั้นมีค่าซ้ำซ้อนบ่อยครั้งมาก และมีแนวโน้มที่จะมีขนาดใหญ่ขึ้นเรื่อยๆ เช่น cookie ดังนั้นจึงสร้างมาตรฐานการบีบอัดข้อมูลขึ้นมา ชื่อ HPACK (หาอ่านได้จาก RFC7541)ซึ่ง HTTP/2 จะใช้การบีบอัดข้อมูลนี้โดยอัตโนมัติ ผู้ใช้ไม่ต้องกังวลปัญหาต่างๆ ว่าจะ config อะไรยังไง

ข้อดีจะทำให้ bandwidth นั้นลดลงไป (ขึ้นกับว่า header เปลี่ยนมากน้อยขนาดไหน) สำหรับ response จาก server นั้น bandwidth จะลดลงเป็น % ไม่มากเท่าไร (เพราะข้อมูลมีขนาดใหญ่กว่า header มาก) แต่สำหรับ request ที่ client ส่งมา จะลดลงไปอีกมาก (ได้มากถึง 70% ของขนาด header)

4. Prioritization สามารถปรับลำดับความสำคัญของแต่ละ stream ได้ ซึ่งช่วยให้การโหลดหน้าเว็ปเพื่อใช้งานได้ใช้เวลาน้อยลง เพราะโหลดสิ่งที่สำคัญให้ขึ้นมาใช้งานได้ก่อน และสิ่งสำคัญน้อยกว่าทีหลัง

5. Server Push เป็น feature ของ HTTP/2 คือการที่ server ส่งข้อมูลอันอื่น มาพร้อมกับข้อมูลที่ client ขอเลย นึกภาพว่า client ขอภาพ A ไปยัง server แล้ว server ทำการส่งภาพ A กลับไป ในขณะเดียวกัน server รู้ว่ามันขอ A แล้วเดี๋ยวมันจะต้องขอ B ต่อแน่ๆ จึงทำการแนบภาพ B ไปพร้อมกับภาพ A ด้วย ข้อดีคือลด RTT ไปได้สูงมาก (ลดเวลาที่ client ต้องมาถามขอ B ใหม่) feature ค่อนข้างน่าสนใจมากเลยทีเดียว ข้อเสียคือ เว็บแต่ละเว็บ จะต้องทำการตั้งค่าด้วยตัวเอง เพราะแต่ละเว็บมีการใช้ข้อมูลไม่เหมือนกัน

6. (ไม่เชิง feature) HTTP/2 ในปัจจุบัน แม้ใน RFC จะระบุว่าข้อมูลขณะส่งไม่จำเป็นต้องมีการเข้ารหัส แต่ browser ทุกตัวในปัจจุบัน (ไม่นับ curl/nghttp2) รองรับ HTTP/2 เฉพาะเว็ปที่มีการเข้ารหัสเท่านั้น

การทดลอง

ผมแนะนำ link ให้ไปอ่านผลการทดลองเรื่องความเร็วระหว่าง HTTP/1.1 SPDY และ HTTP/2 (ผมไม่ได้ทำการทดลองเอง จึงแนะนำให้อ่านจากต้นฉบับเลย)

https://blog.httpwatch.com/2015/01/16/a-simple-performance-comparison-of-https-spdy-and-http2/

http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7179400&newsearch=true&queryText=http%2F2

https://blogs.dropbox.com/tech/2016/05/enabling-http2-for-dropbox-web-services-experiences-and-observations/

ซึ่งจากการทดลองแล้ว เกือบทุกกรณี HTTP/2 ได้ผลที่ดีกว่า HTTP/1.1 อย่างเห็นได้ชัด อีกทั้งสามารถลดการใช้ connection sharding concatenation spriting และการ implement แบบอื่นๆใน HTTP/1.1 ลงได้มาก เป็นการปรับทุกอย่างให้กลับสู่มาตรฐาน และความ simplicity อีกครั้ง เย้ๆ ต่อไปเราไม่ต้องคิดอะไรให้วุ่นวายในการจัดการเรื่องความเร็วอีก

ทั้งนี้ มีกรณีที่น่าสนใจจากการทดลอง มีกรณีหนึ่งที่ทำให้ HTTP/2 นั้นได้ผลลัพธ์ที่แย่กว่า HTTP/1.1 (จาก paper “Is HTTP/2 really faster than HTTP/1.1?”) คือกรณีที่ระหว่างการ transfer นั้นเกิด loss ขึ้น (เกิดบ่อยบน mobile) กลับกลายเป็นว่า HTTP/1.1 นั้นทำงานได้ดีกว่าซะงั้น เราจะไปพูดเรื่องนี้ในการวิเคราะห์ต่อไป

วิเคราะห์ HTTP/2

การวิเคราะห์หลายอย่างตรงนี้ หลังจากได้อ่านแหล่งอ้างอิงหลายๆแหล่ง บางส่วนของการวิเคราะห์ก็แหล่งอ้างอิงให้คำตอบแล้ว แต่บางส่วนผมก็คิดต่อยอดเองด้วย ดังนั้นหากพบส่วนไหนผิดพลาดหรือไม่เหมาะสม สามารถคุยกันต่อได้ครับ

เหตุผลที่มีกรณี HTTP/2 แย่กว่า HTTP/1.1 (ระดับ technical ผู้อ่านทั่วไปข้ามไปได้ครับ)

ไม่ทิ้งให้สงสัยนาน ตอบเลยละกัน เหตุผลเพราะว่า กรณีที่เกิด loss ขึ้น ในระดับ TCP นั้นมี congestion control algorithm อยู่แล้ว มันจะทำการปรับลดปริมาณข้อมูลที่ส่งได้ลง แต่เห้ยยย ความแตกต่างระหว่าง HTTP/1.1 กับ HTTP/2 คือ HTTP/1.1 มันใช้หลาย connections หากเกิด loss ก็แค่ connection อันที่เกิดลดลง อันที่เหลือทำงานต่อตามปกติ ในขณะที่ HTTP/2 มันใช้แค่ connection เดียวแล้ว stream ด้านในเต็มไปหมด นอกจากโอกาสเกิด loss ก็สูงแล้ว (ก็ข้อมูลทุกอย่างส่งผ่าน connection เดียวอะ) พอเกิด loss ที ทุก stream ก็ถูกควบคุมโดย TCP congestion control อีกที มันจึงลดแบบฮวบๆนั่นเอง

อันนี้ไม่ใช่เพราะ HTTP/2 ออกแบบมาไม่ดีนะครับ ที่จริงแล้วกลับถูกต้องด้วยซ้ำ เพราะ congestion control ที่ดีควรตั้งให้ลดปริมาณการส่งข้อมูลลงเมื่อเกิด loss แต่อันเดิมเราเล่นไป abuse สร้าง connection เข้าไป 40 อัน (ทั้งๆที่ client-server คุยกันอยู่แค่ 2 คน) มันส่งผลให้ congestion control ของ TCP เองทำงานไม่มีประสิทธิภาพด้วย ซึ่งตอนนี้ก็สมเหตุสมผลแล้ว ทั้งนี้ไม่ได้แปลว่าหากกรณี loss สูงไม่ควรใช้ HTTP/2 นะครับ แต่มันแปลว่า กรณีที่มี loss สูงแน่ๆ (เช่น Ad-hoc) เราควรเลือกใช้ HTTP/2 over “something else” ที่ไม่ใช่ TCP แทน ส่วนอนาคตจะมีการแก้ไข TCP ให้ดีขึ้นอีกหรือไม่ ก็ต้องรอดูกันต่อไป

HTTP/2 ในปัจจุบัน

ที่จริง RFC ของ HTTP/2 ก็ออกมาได้จะเกือบปีแล้ว (May 2015) แต่หลายคนยังไม่รู้สึกด้วยซ้ำว่าเว็ประดับโลกหลายๆเว็ปรอบตัวเปลี่ยนไปใช้ HTTP/2 กันบ้างแล้ว เช่น Google, Twitter, Youtube นอกจากเว็ปใหญ่ๆเริ่มเปลี่ยนแล้ว ถ้าเราเข้าใจหลักการที่อธิบายไปข้างต้น ก็จะเห็นด้วยว่า HTTP/2 มันคืออนาคตที่จะมาแทนที่ HTTP/1.1 แน่ๆ แต่อาจจะใช้เวลาพอสมควรในการปรับการ implement ต่างๆให้ stable ก่อนที่คนทั่วไปจะนำไปใช้

ใน Firefox สร้างเข้าไปที่ Developer Tools -> Network เพื่อดู version ของ HTTP ที่ใช้ได้

เรื่องที่ต้องพิจารณาก่อนเปลี่ยนเป็น HTTP/2

นอกจากเรื่อง stability แล้ว ยังมีเรื่องทีต้องพิจารณาอื่นๆอีกพอสมควร คนที่ implement อาจจะต้องมีความรู้ความเข้าใจใน HTTP/2 ต้องมี tools ที่พร้อมใช้งาน เข้าใจโครงสร้างของ server เดิม และ infrastructure เช่น load balance, router ที่อาจต้องนำมาพิจารณาหรืออัพเดทใหม่ด้วย ยังไปถึงเรื่อง security ต่างๆเช่น IDS IPS รวมถึงการ monitoring ที่อาจจะต้องทำการเปลี่ยนวิธีใหม่ ส่วน prioritization กับ push จะออกมาเป็นแบบไหน ผู้เช่าสามารถปรับได้เองหรือปล่าว เหตุผลเหล่านี้จะเป็นสาเหตุที่ hosting หลายๆที่ยังไม่มีบริการ support HTTP/2 หรือ support เพียงแค่ multiplexing เท่านั้น

หลายคนก็มองว่า ผลลัพธ์ความเร็วที่เกิดจากการปรับเปลี่ยน protocol เนี่ย มันไม่ได้ส่งผลอะไรกับระบบธุรกิจมากมายนัก (ถามจริง มีใครรู้สึกบ้างว่าเห้ย google เปลี่ยนเป็น HTTP/2 แล้ว เร็วกว่าเดิม 0.2 วิ google นี่ดีกว่า bing จริงๆเลยยย…. ไม่มีอะ) ถ้าธุรกิจไม่ได้เป็น worldwide ขนาดใหญ่ หน้าเว็บโตๆรูปเยอะๆ เจ้าของธุรกิจไม่ใช่ computer geek ส่วนใหญ่ก็ยังคงไม่คิดจะเปลี่ยนครับ

แล้วเราควรเปลี่ยนไปใช้หรือไม่ เว็ปประเภทไหนที่จะได้รับประโยชน์จาก HTTP/2 มาก

จากหัวข้อที่แล้ว จัดเต็มซะ บางคนไม่อยากเปลี่ยนเลย ใจเย็นๆนะครับ สภาพแบบนี้ เป็นสภาพของสิ่งที่ถูกนำเข้ามาใหม่อยู่แล้ว เข้าใจยากเข้าถึงยาก แต่ประโยชน์ของมันก็มี เรื่อง multiplexing อย่างเดียวก็ช่วยเพิ่มความเร็วได้ 10–40% แล้ว ทั้งนี้จะนำไปใช้หรือไม่ใช้ ผมคิดว่าให้เริ่มพิจารณาจากเว็ปของตัวเองก่อน

ถ้าเว็ปตัวเองเป็น static web โหลดเยอะ รูปเยอะ เปลี่ยนหน้าเว็ปบ่อยครั้ง อีกทั้งเว็ปมีความสำคัญเชิงธุรกิจ (เช่น img hosting, video hosting, web catalog เยอะๆ เช่น amazon, ebay) การเปลี่ยนมาใช้ จะช่วยเพิ่มความเร็วอย่างเห็นได้ชัดมาก

แต่ขณะเดียวกัน ถ้าเว็ปมีขนาดเล็ก object transfer ไม่เยอะ โต้ตอบผ่านหน้าเดียว ผมคิดว่าโอกาสที่จะได้ใช้ multiplexing นั้นต่ำ การปรับเปลี่ยนตอนนี้ก็จะเห็นว่าไม่คุ้มค่าแน่ๆ ก็รอโอกาสในอนาคตเมื่อค่าใช้จ่ายต่างๆของมันถูกลง

[updated]* แต่ที่สำคัญที่สุด ก่อนจะเปลี่ยนเป็น HTTP/2 เนี่ย ควรเข้าใจก่อนว่ามันทำงานยังไง infrastructure ของ server เดิมเป็นยังไง การ process บน HTTP/1.1 เดิมทำงานยังไง ต้องมีอะไรเปลี่ยนบ้าง ถ้ารู้หมดตามนี้แล้ว จึงค่อยเลือกที่จะเปลี่ยนครับ สิ่งที่ห้ามทำหลังจากเปลี่ยนเป็น HTTP/2 เช่น เปลี่ยนไปใช้ HTTP/2 แต่ยังคงเปิด connection unlimited, sharding กระจุยเหมือนเดิม, spriting ก้อนใหญ่ๆ ผลลัพธ์ที่ออกมา มันจะแย่กว่า HTTP/1.1 ที่ใช้เดิมอยู่ซะอีก (ลองวิเคราะห์กันดูเล่นๆนะครับว่าทำไมมันแย่กว่าเดิม ไม่ยากครับ ลองดูๆ อันนี้มีทดลองมาแล้วด้วยใน paper การทดลองที่ 2 ด้านบน) สำหรับคนที่ยังไม่เข้าใจ หรือทีม IT ยังไม่พร้อม รอไปอีกสักพัก ให้มีกลุ่มที่มา support พวกท่าน ตอนนี้ไปพัฒนา feature อย่างอื่นรอไปก่อน ก็ดูจะเป็นทางเลือกที่คุ้มและ safe กว่ามาก

ถึงแม้ว่าตอนนี้ผมแนะนำว่า ถ้าไม่จำเป็น ยังไม่ต้องเปลี่ยนไปใช้ HTTP/2 หรอก แต่ในความเป็นจริง ผมเชียร์ HTTP/2 นะครับ มันเป็นความก้าวหน้าที่ยิ่งใหญ่อันหนึ่งของวงการ internet เลย ในอนาคต หลังจากทุกอย่าง stable หมดแล้ว มี developer HTTP/2 เยอะขึ้น ค่าใช้จ่ายต่างๆลดลง การเปลี่ยนไปใช้ HTTP/2 ซึ่งใหม่กว่า ดีกว่า มีคน support เยอะกว่าจะเป็นตัวเลือกที่ดีกว่าแน่นอน

ผมไม่ได้หวังว่า คนที่อ่าน blog นี้ของผมเสร็จแล้ว จะต้องกลับบ้านไปเปลี่ยนเป็น server ให้รองรับ HTTP/2 (บ้าไปแล้ว 555) แต่ผมเขียนมาทั้งหมดนี้ หวังว่าคนที่อ่านทุกคนจะเข้าใจ และเตรียมพร้อมที่จะเปลี่ยนไปใช้สิ่งที่ใหม่กว่า เมื่อวันวันนั้นมาถึง จะได้เปลี่ยนอย่างสบายใจ มีความเข้าใจในสิ่งที่เปลี่ยน และใช้งานอย่างถูกต้องครับ