The Evolution of HTTP Protocols
A journey through the evolution of HTTP, from the simple document protocol of HTTP/0.9 to the modern QUIC-powered HTTP/3.
What Is HTTP?
HTTP (Hypertext Transfer Protocol) ဆိုတာ Client နဲ့ Server ကြား Data တွေ အပြန်အလှန် ပေးပို့ဆက်သွယ်နိုင်ဖို့ သတ်မှတ်ထားတဲ့ Protocol ဖြစ်ပါတယ်။ ရိုးရှင်းတဲ့ Request-Response Model နည်းလမ်းအတိုင်း အလုပ်လုပ်ပေမဲ့ Web ရဲ့ လိုအပ်ချက်တွေ တစ်နေ့ထက်တစ်နေ့ ပိုမိုကြီးမားလာတာနဲ့အမျှ Performance, Reliability နဲ့ Scalability တွေ တိုးတက်လာစေဖို့အတွက် HTTP ရဲ့ အောက်ခြေ Transport စနစ်တွေဟာ ဆယ်စုနှစ်ချီ သိသိသာသာ ပြောင်းလဲလာခဲ့ပါတယ်။
HTTP/1.1: Persistent Connections
HTTP/1.1 မှာ Persistent Connections စနစ်ကို စတင်မိတ်ဆက်ခဲ့ပြီး Resource တစ်ခုချင်းစီအတွက် Connection အသစ် အမြဲဖွင့်စရာမလိုဘဲ ချိတ်ဆက်ပြီးသား TCP Connection ကိုပဲ ပြန်လည်အသုံးပြု (Reuse) နိုင်စေခဲ့ပါတယ်။ ဒါပေမဲ့ Images, JavaScript, CSS နဲ့ Fonts စတဲ့ Resources ရာနဲ့ချီ ပါဝင်လာတဲ့ ခေတ်သစ် Websites တွေအတွက် Browser တွေက Loading Speed မြန်အောင် Multiple TCP Connections တွေကို အပြိုင်ဖွင့်သုံးလာရတဲ့အတွက် Network နဲ့ Server ပေါ်မှာ Overhead အလွန်များလာခဲ့ပါတယ်။
HTTP/2: Multiplexing
HTTP/2 မှာတော့ Binary Framing, Header Compression, Stream Prioritization နဲ့ အဓိက အပြောင်းအလဲဖြစ်တဲ့ Multiplexing စနစ်ကို ထည့်သွင်းပေးခဲ့ပါတယ်။ Streams အများအပြားကို Single TCP Connection တစ်ခုတည်းပေါ်ကနေ အပြိုင် (Simultaneously) ပို့ဆောင်နိုင်စေခဲ့ပေမဲ့ TCP ရဲ့ အစဉ်လိုက် ပို့ဆောင်ရတဲ့ (Ordered Delivery) သဘောတရားကြောင့် Packet Loss တစ်ခုခု ဖြစ်ပေါ်ခဲ့ရင် တခြား Streams တွေပါ စောင့်ဆိုင်းရတဲ့ Transport-level Head-of-line Blocking ပြဿနာ ကြုံတွေ့ရပါတယ်။
HTTP/3: The QUIC Revolution
HTTP/3 မှာတော့ TCP အစား UDP ပေါ်မှာ အလုပ်လုပ်တဲ့ QUIC Protocol ကို ပြောင်းလဲအသုံးပြုခဲ့ပြီး Reliability, Encryption နဲ့ Congestion Control တွေကိုလည်း အပြည့်အဝ ထိန်းသိမ်းပေးထားပါတယ်။ QUIC ရဲ့ အဓိက အားသာချက်ကတော့ Streams တွေကို သီးခြားစီ (Independent) ကိုင်တွယ်နိုင်တာကြောင့် Stream တစ်ခုမှာ Packet Loss ဖြစ်ရင်တောင် တခြား Streams တွေ ပိတ်ဆို့မသွားဘဲ ဆက်လက်အလုပ်လုပ်နိုင်သလို Wi-Fi နဲ့ Mobile Data အကြား ကူးပြောင်းရာမှာလည်း Connection ပြန်စစရာမလိုဘဲ ချောမွေ့စွာ ဆက်လက်ချိတ်ဆက်ထားနိုင်တာ ဖြစ်ပါတယ်။
What Does This Mean for Developers?
Developers တွေအနေနဲ့ HTTP/3 အတွက် Application Code တွေကို ပြန်ရေးစရာမလိုဘဲ fetch() စတဲ့ Standard Code တွေနဲ့ပဲ ဆက်လက်ရေးသားနိုင်ကာ Browser နဲ့ Server တို့က သင့်တော်တဲ့ Version ကို Auto-negotiate လုပ်ပေးသွားမှာ ဖြစ်ပါတယ်။ ဒါပေမဲ့ HTTP/3 သုံးရုံနဲ့ Application က အလိုအလျောက် မြန်ဆန်သွားမှာ မဟုတ်ဘဲ Overall Performance ဆိုတာ Database Optimization, API Design, Caching, CDN Usage, Server Performance နဲ့ Frontend Optimization စတဲ့ Stack တစ်ခုလုံးရဲ့ Layer တိုင်းပေါ်မှာ မူတည်နေပါတယ်။
Final Thoughts
HTTP/1.1 ကနေ HTTP/2 နဲ့ HTTP/3 အထိ ဆင့်ကဲပြောင်းလဲလာမှုဟာ နည်းပညာဆိုင်ရာ ကန့်သတ်ချက်တွေကို မျိုးဆက်တစ်ခုချင်းစီအလိုက် အဆင့်မြှင့်တင် ဖြေရှင်းလာခဲ့ပုံကို ထင်ရှားစွာ ဖော်ပြနေပါတယ်။ ရိုးရှင်းတဲ့ fetch() Call တစ်ခုရဲ့ နောက်ကွယ်မှာ အင်တာနက်ကို ပိုမိုမြန်ဆန်၊ စိတ်ချရပြီး Scalable ဖြစ်စေဖို့ ဆယ်စုနှစ်ချီ တည်ဆောက်ခဲ့ရတဲ့ Network Engineering နက်နဲမှုတွေ ပါဝင်နေပြီး ခေတ်သစ် Performance ဆိုတာ နည်းပညာတစ်ခုတည်းကြောင့် မဟုတ်ဘဲ System ရဲ့ Layer တိုင်းကို တိုးတက်အောင် လုပ်ဆောင်ခြင်းမှသာ ရရှိနိုင်တာ ဖြစ်ပါတယ်။