Common Protocols
HTTP / HTTPS
เข้าใจพื้นฐาน HTTP และ HTTPS สำหรับผู้เริ่มต้น: ต่างกันอย่างไร, TLS ช่วยเรื่องอะไร, และทำไมเว็บยุคใหม่ต้องใช้ HTTPS
1. ภาพใหญ่ก่อน: HTTP คือภาษากลางของเว็บ
HTTP (HyperText Transfer Protocol) คือข้อตกลงการสื่อสารระหว่างฝั่งผู้ใช้ (Client เช่น Browser, Mobile App) กับฝั่งบริการ (Server) เมื่อผู้ใช้เปิดหน้าเว็บหรือกดปุ่มใด ๆ ระบบจะสร้าง HTTP Request ไปยัง Server และ Server ส่ง HTTP Response กลับมา HTTP เองไม่ได้ผูกกับหน้า HTML อย่างเดียว แต่ใช้ส่งข้อมูลได้หลายรูปแบบ เช่น HTML, JSON, รูปภาพ, ไฟล์, หรือสตรีมข้อมูล
- HTTP คือ Application-Layer Protocol ที่มนุษย์อ่านได้ในระดับข้อความ
- HTTP เป็นรากฐานของเว็บ, API, และระบบสื่อสารระหว่าง service
- HTTP ดั้งเดิมไม่ได้เข้ารหัสข้อมูล จึงเป็นเหตุผลที่ HTTPS สำคัญมาก
2. Request-Response Lifecycle: ตั้งแต่พิมพ์ URL จนหน้าเว็บแสดงผล
- 1) ผู้ใช้พิมพ์ URL แล้ว Browser วิเคราะห์โปรโตคอล (http หรือ https)
- 2) Browser หา IP ของโดเมนผ่าน DNS
- 3) สร้างการเชื่อมต่อเครือข่าย (TCP และอาจมี TLS ถ้าเป็น HTTPS)
- 4) ส่ง HTTP Request (method + path + headers + body ถ้ามี)
- 5) Server ประมวลผลและส่ง HTTP Response กลับมา
- 6) Browser parse response และ render หน้า พร้อมยิง request ย่อยเพิ่ม (CSS/JS/Image)
มองภาพรวมให้เห็นก่อนว่า HTTP ไม่ได้จบแค่ส่งคำขอเดียว แต่มีลูป request-response ต่อเนื่อง
3. Anatomy ของ HTTP Message: Request และ Response มีส่วนประกอบอะไร
HTTP Request มี 3 ส่วนหลัก: Start Line, Headers, Body HTTP Response ก็มีโครงเดียวกัน: Status Line, Headers, Body หัวใจของการ debug เว็บจำนวนมากคือการอ่าน 3 ส่วนนี้ให้คล่อง โดยเฉพาะ headers และ status code
| ส่วน | อยู่ใน Request/Response | ความหมาย |
|---|---|---|
| Start/Status Line | ทั้งคู่ | บอกคำสั่งหลักหรือผลลัพธ์หลัก |
| Headers | ทั้งคู่ | metadata เช่น type, auth, cache, cookie |
| Body | ทั้งคู่ (อาจว่าง) | payload จริง เช่น JSON, HTML, ไฟล์ |
4. HTTP Methods ที่ใช้จริง: ความหมาย + Safe/Idempotent
Method คือคำกริยาของ Request ว่าฝั่ง Client ต้องการทำอะไร การเข้าใจคำว่า Safe และ Idempotent ช่วยออกแบบ API ถูกต้องและลด bug
| Method | ใช้ทำอะไร | Safe | Idempotent |
|---|---|---|---|
| GET | อ่านข้อมูล | ใช่ | ใช่ |
| POST | สร้าง resource/trigger action | ไม่ใช่ | ไม่ใช่โดยทั่วไป |
| PUT | แทนค่าทั้งก้อน | ไม่ใช่ | ใช่ |
| PATCH | แก้บางส่วน | ไม่ใช่ | ขึ้นกับการออกแบบ |
| DELETE | ลบ resource | ไม่ใช่ | ใช่โดยแนวคิด |
| HEAD | ขอเฉพาะ headers | ใช่ | ใช่ |
| OPTIONS | ถามความสามารถ endpoint | ใช่ | ใช่ |
- Safe = เรียกแล้วไม่ควรเปลี่ยน state ฝั่งเซิร์ฟเวอร์
- Idempotent = เรียกซ้ำหลายครั้งแล้วผลสุดท้ายเหมือนเรียกครั้งเดียว
- POST มักไม่ idempotent เพราะส่งซ้ำอาจสร้างข้อมูลซ้ำ
5. Status Codes แบบใช้งานจริง: อ่านแล้ว debug ยังไง
| กลุ่ม | ตัวอย่าง | แปลความหมายเวลาเจอจริง |
|---|---|---|
| 1xx Informational | 101 Switching Protocols | กำลังเปลี่ยนสถานะการสื่อสาร เช่นอัปเกรด protocol |
| 2xx Success | 200, 201, 204 | คำขอสำเร็จ แต่ผลลัพธ์แต่ละรหัสต่างกัน |
| 3xx Redirection | 301, 302, 304 | ต้องเปลี่ยนเส้นทางหรือใช้ cache ที่มีอยู่ |
| 4xx Client Error | 400, 401, 403, 404, 429 | คำขอมีปัญหาฝั่ง client หรือสิทธิ์ไม่พอ |
| 5xx Server Error | 500, 502, 503, 504 | ฝั่ง server/downstream มีปัญหา |
- 1) ดูกลุ่มรหัสก่อน (2xx/4xx/5xx)
- 2) อ่าน response body สำหรับ error detail
- 3) เช็ก request headers/body ว่าตรงสัญญา API หรือไม่
- 4) ถ้า 5xx ให้ไล่ server logs และ upstream dependencies
6. Headers สำคัญที่ต้องรู้: metadata ที่กำหนดพฤติกรรมทั้งระบบ
| Header | ฝั่งที่ใช้บ่อย | หน้าที่ |
|---|---|---|
| Content-Type | Response/Request | บอกชนิดข้อมูล เช่น application/json |
| Accept | Request | บอกชนิดข้อมูลที่ client อยากได้ |
| Authorization | Request | ส่งข้อมูลยืนยันตัวตน เช่น Bearer token |
| Cache-Control | ทั้งคู่ | กำหนดนโยบายแคช |
| Cookie | Request | ส่งค่าคุกกี้กลับไปเซิร์ฟเวอร์ |
| Set-Cookie | Response | ให้ browser เก็บคุกกี้ |
| Origin | Request | บอกต้นทางเพื่อใช้ใน CORS |
| Access-Control-Allow-Origin | Response | บอกว่า origin ไหนขอข้อมูลได้ |
7. HTTP เป็น Stateless แล้วระบบ Login จำเราได้อย่างไร
Stateless แปลว่าแต่ละ request เป็นอิสระจากกัน เซิร์ฟเวอร์ไม่ควรเดาว่าคุณคือใครจาก request ก่อนหน้า ดังนั้นระบบจึงต้องมีวิธีพกบริบท (state) กลับไปกลับมา เช่น cookie, session id, หรือ token
| แนวทาง | เก็บ state ไว้ที่ไหน | จุดเด่น/ข้อควรระวัง |
|---|---|---|
| Session + Cookie | Server (session store) | ควบคุมฝั่ง server ง่าย แต่ต้องจัดการ scaling ของ session |
| JWT Token | Client ถือ token | เหมาะกับ distributed system แต่ต้องออกแบบอายุ/เพิกถอนให้ดี |
| Hybrid | ทั้งสองฝั่ง | ยืดหยุ่นสูงแต่ซับซ้อนกว่า |
- Cookie ไม่ใช่สิ่งไม่ปลอดภัยโดยตัวมันเอง ความปลอดภัยขึ้นกับการตั้งค่า
- สำหรับ session cookie ควรตั้ง Secure, HttpOnly, SameSite ให้เหมาะสม
- หลีกเลี่ยงเก็บข้อมูลลับดิบใน client-side storage
8. Caching และ Conditional Requests: เร็วขึ้นโดยไม่ส่งข้อมูลซ้ำ
Caching คือการเก็บผลตอบกลับบางอย่างไว้ชั่วคราวเพื่อให้ request ครั้งถัดไปเร็วขึ้นและลดภาระ server Conditional request คือการถาม server ว่า "ข้อมูลยังเหมือนเดิมไหม" ก่อนส่ง body ก้อนใหญ่กลับมา
| กลไก | Header ที่เกี่ยวข้อง | ผลลัพธ์ |
|---|---|---|
| Entity Tag | ETag / If-None-Match | ถ้าไม่เปลี่ยนจะได้ 304 Not Modified |
| Last-Modified | Last-Modified / If-Modified-Since | เช็กจากเวลาแก้ล่าสุด |
| Freshness | Cache-Control: max-age | ใช้ cache ได้ทันทีจนหมดอายุ |
9. ปัญหาของ HTTP แบบไม่เข้ารหัส: ความเสี่ยงที่เกิดขึ้นจริง
HTTP อ่านได้ระหว่างทาง จึงเสี่ยงต่อการดักข้อมูลและแก้ไขข้อมูล
- Sniffing: ผู้ไม่หวังดีอ่านข้อความที่วิ่งผ่านเครือข่ายได้
- Tampering: ข้อมูลระหว่างทางถูกแก้ไข เช่น inject script หรือ redirect ปลอม
- MITM (Man-in-the-Middle): มีคนแทรกกลางและปลอมตัวเป็นปลายทาง
- Credential leakage: รหัสผ่านหรือ token ถูกขโมยได้ง่ายขึ้น
10. HTTPS และ TLS Handshake: ขั้นตอนก่อนเริ่มส่งข้อมูลจริง
HTTPS = HTTP ที่วิ่งอยู่บน TLS ก่อนส่ง HTTP request จริงจะมี TLS Handshake เพื่อสร้างช่องทางเข้ารหัสและยืนยันตัวตนเซิร์ฟเวอร์ก่อน
- 1) ClientHello: browser เสนอ TLS version/cipher suites/ข้อมูลเริ่มต้น
- 2) ServerHello: server เลือกชุดที่ใช้ และส่ง certificate
- 3) Client ตรวจ certificate chain และชื่อโดเมนว่าตรงหรือไม่
- 4) ทำ key exchange เพื่อได้ shared session keys
- 5) Finished messages: ยืนยันว่าพร้อมใช้การเข้ารหัสแล้ว
- 6) จากนั้น HTTP request/response ทั้งหมดจะอยู่ในช่องทางเข้ารหัส
Handshake มีเป้าหมาย 3 เรื่อง: confidentiality, integrity, authentication
11. Certificate Chain และความเชื่อถือ: ทำไม browser ถึงเชื่อว่าเว็บนี้ของจริง
| องค์ประกอบ | หน้าที่ | สิ่งที่ browser ตรวจ |
|---|---|---|
| Leaf Certificate | ใบรับรองของโดเมนปลายทาง | โดเมนตรงกับ SAN/CN และยังไม่หมดอายุ |
| Intermediate CA | ตัวกลางออกใบรับรอง | ลายเซ็นถูกต้อง เชื่อมสายโซ่ได้ |
| Root CA | รากความเชื่อถือใน trust store | ต้องเป็น root ที่ระบบเชื่อถือ |
| Revocation signal | สถานะเพิกถอนใบรับรอง | ใช้ OCSP/CRL ตามนโยบายระบบ |
- ถ้าใบรับรองหมดอายุ browser จะเตือนทันที
- ถ้าโดเมนไม่ตรง (hostname mismatch) browser จะมองว่าไม่ปลอดภัย
- การต่ออายุ certificate อัตโนมัติช่วยลด outage จาก cert หมดอายุ
12. HTTP/1.1 vs HTTP/2 vs HTTP/3: ต่างกันอย่างไรในภาพใช้งานจริง
| เวอร์ชัน | พื้นฐานการเชื่อมต่อ | จุดเด่น | ข้อสังเกต |
|---|---|---|---|
| HTTP/1.1 | TCP | เข้าใจง่ายและแพร่หลาย | อาจเกิด head-of-line blocking ระดับ connection |
| HTTP/2 | TCP + binary framing | multiplexing หลาย stream บน connection เดียว | โดยทั่วไปใช้กับ TLS ในงานจริง |
| HTTP/3 | QUIC (บน UDP) | ลด latency บางกรณีและฟื้นตัวจาก packet loss ได้ดีขึ้น | สถาปัตยกรรมต่างจาก TCP-based เดิม |
สำหรับมือใหม่ ให้จำหลักนี้ก่อน: HTTP semantics (method/status/header) ยังคล้ายเดิม แต่ "ชั้นขนส่งและ framing" พัฒนาเพื่อความเร็วและประสบการณ์ใช้งานที่ดีขึ้น
13. Practical Checklist + Recap: สิ่งที่ควรทำในระบบจริง
- 1) บังคับใช้ HTTPS ทุกหน้า และ redirect จาก HTTP -> HTTPS
- 2) ตั้ง HSTS (HTTP Strict Transport Security) เมื่อพร้อม
- 3) ปิด mixed content และโหลด asset ผ่าน HTTPS เท่านั้น
- 4) ใช้ secure cookie flags: Secure, HttpOnly, SameSite
- 5) ตั้ง certificate auto-renew และ monitor วันหมดอายุ
- 6) กำหนด Cache-Control ตามชนิดข้อมูล (static vs sensitive)
- 7) ทำ logging ที่พอ debug ได้โดยไม่ log ข้อมูลลับ
- HTTP คือภาษากลางของเว็บ ส่วน HTTPS คือ HTTP ที่มีเกราะความปลอดภัยด้วย TLS
- เข้าใจ request/response anatomy จะ debug ระบบเว็บได้แม่นขึ้นมาก
- method, status, headers, cache, และ auth คือแกนหลักที่ต้องอ่านให้คล่อง
- TLS handshake และ certificate chain คือรากความเชื่อถือของเว็บยุคใหม่