Network
Fundamentals
Client vs Server
เข้าใจบทบาทของ Client และ Server แบบอ่านง่ายเชิงบทความ พร้อม flow การสื่อสารจริงที่ใช้ในเว็บและแอปสมัยใหม่
1. Core Idea: Client และ Server คือใคร
Client คือฝั่งที่ "ขอ" ข้อมูลหรือบริการ เช่น Browser, Mobile App, หรือ Desktop App Server คือฝั่งที่ "ให้" ข้อมูลหรือบริการตาม request ที่เข้ามา เวลาใช้งานเว็บจริง เราไม่ได้คุยกับหน้าเว็บอย่างเดียว แต่กำลังคุยกับระบบ client-server ตลอดเวลา
- Client ส่ง request
- Server รับ request แล้วประมวลผล
- Server ส่ง response กลับไปให้ client แสดงผล
2. Mental Model: ลูกค้ากับร้านบริการ
ลองเปรียบเทียบง่าย ๆ: - Client เหมือนลูกค้าที่เดินเข้าร้านและสั่งเมนู - Server เหมือนครัวและพนักงานที่รับออเดอร์, ทำงาน, แล้วส่งผลลัพธ์กลับ ลูกค้าไม่จำเป็นต้องรู้วิธีทำอาหารทุกขั้น แต่ต้องส่งคำสั่งให้ถูกแบบ ฝั่งครัวต้องจัดการงานหลายออเดอร์พร้อมกันให้ทันเวลา
Client มีหน้าที่ขอและแสดงผล ส่วน Server มีหน้าที่ประมวลผลและตอบกลับ
3. Rule / Definition: ตารางเปรียบเทียบ Client vs Server
| หัวข้อ | Client | Server |
|---|---|---|
| บทบาท | ร้องขอข้อมูล/บริการ | ให้ข้อมูล/บริการตามคำขอ |
| ตำแหน่งที่รัน | อุปกรณ์ผู้ใช้ | เครื่องเซิร์ฟเวอร์หรือคลาวด์ |
| หน้าที่หลัก | UI, interaction, ส่ง request | Business logic, auth, data access |
| วงจรชีวิต | เปิด/ปิดตามผู้ใช้ | ทำงานต่อเนื่องเพื่อรอคำขอ |
| การสเกล | ตามจำนวนผู้ใช้รายบุคคล | ต้องรองรับผู้ใช้จำนวนมากพร้อมกัน |
4. Worked Example: เปิดหน้าเว็บหนึ่งหน้าเกิดอะไรขึ้น
- 1) ผู้ใช้พิมพ์ URL ใน browser (client)
- 2) Browser ส่ง HTTP request ไปยัง server
- 3) Server ตรวจเส้นทาง ตรวจสิทธิ์ และดึงข้อมูลที่เกี่ยวข้อง
- 4) Server ส่ง response (เช่น HTML/JSON) กลับมา
- 5) Browser รับ response แล้วเรนเดอร์ผลให้ผู้ใช้เห็น
Server เดียวมักต้องจัดการหลาย request พร้อมกัน จึงต้องมีการจัดคิวและควบคุมทรัพยากร
5. Structured Example: Request / Response แบบข้อความ
รูปแบบนี้ช่วยให้เห็นหน้าที่แต่ละฝั่งชัด: ใครเป็นคนขอ และใครเป็นคนตอบ
Client -> Server
GET /api/profile HTTP/1.1
Host: learn.example.com
Authorization: Bearer <token>
Server -> Client
HTTP/1.1 200 OK
Content-Type: application/json
{ "name": "Nina", "role": "developer" }- Client ต้องส่งข้อมูล request ให้ครบตามที่ API ต้องการ
- Server ต้องตอบด้วยรูปแบบที่ client คาดหวัง
- ถ้าสื่อสารไม่ตรงสัญญา (contract) ระบบจะพังแม้โค้ดแต่ละฝั่งทำงานได้เอง
6. Practical Notes: จุดที่มือใหม่มักสับสน
- คิดว่า server = database: จริง ๆ database เป็นเพียงส่วนหนึ่งที่ server อาจเรียกใช้
- สับสน localhost: client localhost กับ server localhost อาจคนละ runtime/port
- คิดว่าเช็กข้อมูลฝั่ง client พอแล้ว: ต้อง validate ซ้ำฝั่ง server เสมอ
- มองว่า request หนึ่งครั้ง = หนึ่งไฟล์เสมอ: จริง ๆ หน้าเดียวอาจมีหลาย API request
7. Recap + สิ่งที่จะเรียนต่อ
- Client คือผู้ร้องขอและแสดงผล ส่วน Server คือผู้ให้บริการและประมวลผล
- การสื่อสารหลักเกิดผ่าน request/response
- ระบบจริงต้องออกแบบสัญญาข้อมูลระหว่าง client-server ให้ชัด
- บทถัดไปจะต่อยอดด้วย IP, Port, Protocol และ Transport