หัวข้อ 1 · 15 นาที
เว็บทำงานอย่างไร: client–server, URL และ DNS
นึกภาพก่อน
สั่งอาหารที่ร้าน: เรา (ลูกค้า) บอกพนักงานว่าต้องการอะไร ครัวทำแล้วส่งกลับมา เราไม่เคยเดินเข้าครัวเอง และครัวไม่เคยเดินมาถามเราก่อน ลูกค้าเป็นฝ่ายขอเสมอ ครัวเป็นฝ่ายตอบเสมอ
เว็บทำงานแบบเดียวกัน: browser (client) ส่งคำขอ web server ส่งคำตอบ ภาษาที่ใช้คุยกันคือ HTTP
World Wide Web
World Wide Web คือ information space ที่เอกสารและ resource ต่าง ๆ ถูกระบุด้วย URL เชื่อมโยงกันด้วย hypertext link และเข้าถึงได้ผ่าน internet
องค์ประกอบของเว็บ
| องค์ประกอบ | หน้าที่ |
|---|---|
| Client (web browser) | ส่งคำขอ และแสดงผล |
| Web server | เก็บเอกสาร และตอบคำขอ |
| HTTP | protocol ที่ client กับ server ใช้คุยกัน |
| URL | ที่อยู่ของ resource เช่น http://server.com/document1.html |
| HTML document (+ CSS, JavaScript) | สิ่งที่ถูกส่งกลับมาให้ browser แสดง |
Request และ Response
ซอฟต์แวร์สองตัวสื่อสารกันด้วยรูปแบบเดียว: ฝ่ายหนึ่งส่ง request อีกฝ่ายส่ง response
- ฝ่ายที่ส่ง request เรียกว่า client
- ฝ่ายที่ตอบเรียกว่า server
- ทั้งสองอยู่คนละเครื่อง เชื่อมกันผ่าน internet และคุยกันด้วย HTTP
server ไม่เคยส่งอะไรมาเองโดยไม่มี request ก่อน
URL
https://www.website.com/view/page-one
└─┬──┘ └┬┘ └────┬────┘└─────┬──────┘
protocol │ domain path & page
subdomain
| ส่วน | ตัวอย่าง | บอกอะไร |
|---|---|---|
| Protocol | https:// | วิธีคุยกับ server |
| Subdomain | www. | ส่วนย่อยของ domain |
| Domain | website.com | ชื่อของเว็บไซต์ |
| Path & page | /view/page-one | resource ที่ต้องการบน server นั้น |
จากชื่อเป็น IP address: DNS
คอมพิวเตอร์ติดต่อกันด้วย IP address (เช่น 3.165.82.61) ไม่ใช่ชื่อ แต่คนจำชื่อได้ง่ายกว่า
DNS lookup คือการแปลงชื่อ (www.example.com) เป็น IP address เหมือนเปิดสมุดโทรศัพท์หาเบอร์จากชื่อ
เกิดอะไรขึ้นเมื่อพิมพ์ google.com ใน browser
- พิมพ์ address ในช่อง address bar
- browser ตรวจ cache ก่อน ถ้าไม่พบ (cache miss) ต้องหา IP address
- DNS lookup — คำถามถูกส่งผ่าน DNS server หลายชั้น: root → TLD → authoritative จนได้ IP address
- เปิด TCP connection — กับ HTTP 1.1 client และ server ทำ TCP three-way handshake: SYN → SYN-ACK → ACK
- ส่ง HTTP request — server ตอบกลับด้วยไฟล์ HTML, CSS และ JS
- browser ประมวลผล — parse HTML แล้วสร้างต้นไม้ DOM และ CSSOM
- รัน JavaScript และ render — ผ่านขั้นตอน tokenizer, parser, render tree, layout, painting
- หน้าเว็บปรากฏ บนจอ
ขึ้นต้นด้วย http:// หรือ https:// — ลองเปลี่ยน protocol แล้วดู port
- 1. URL
- 2. cache
- 3. DNS
- 4. TCP
- 5. request
- 6. response
- 7. parse
- 8. render
- 9. ปิด
คำอธิบายทีละขั้น
พิมพ์ URL แล้วกด Enter
ลองใน simulation:
- preset แรกเดินครบทุกขั้นรวม DNS lookup
- เปลี่ยน "IP ของ host นี้" เป็น "มีใน cache" แล้วดูว่าขั้น DNS หายไป
- เปลี่ยน protocol ใน URL ระหว่าง
http://กับhttps://แล้วดู port ที่ TCP ต่อไป
ตัวอย่างไล่ทีละขั้น
โจทย์: แยกส่วนของ https://shop.example.co.th/products/shoes และบอกว่า browser ต้องรู้อะไรก่อนส่ง request ได้
| ส่วน | ค่า |
|---|---|
| protocol | https → ใช้ port 443 |
| subdomain | shop |
| domain | example.co.th |
| path | /products/shoes |
ก่อนส่ง request:
- ต้องรู้ IP address ของ
shop.example.co.th→ ตรวจ cache → ถ้าไม่มีทำ DNS lookup - ต้องมี TCP connection ไปยัง IP นั้นที่ port 443 → three-way handshake
- จึงส่ง HTTP request ที่ขอ path
/products/shoesได้
DNS ใช้เฉพาะส่วนชื่อ host (shop.example.co.th) ส่วน path ไม่เกี่ยวกับ DNS เลย: path ถูกส่งไปใน HTTP request ให้ server ตีความเอง
จุดที่มักพลาด
1. คิดว่า server ส่งข้อมูลมาเองได้
ใน HTTP server ตอบเมื่อมี request เท่านั้น
2. คิดว่า DNS ส่งหน้าเว็บให้
DNS แค่บอก IP address หน้าเว็บมาจาก web server
3. สลับลำดับ DNS กับ TCP
ต้องรู้ IP ก่อน (DNS) จึงเปิด connection ได้ (TCP) แล้วจึงส่ง HTTP
4. สลับลำดับ handshake
SYN → SYN-ACK → ACK (สามข้อความ)
5. คิดว่า path เป็นส่วนของ domain
domain ระบุเครื่อง path ระบุ resource บนเครื่องนั้น
6. คิดว่า internet กับ web คือสิ่งเดียวกัน
web เป็น information space ที่ เข้าถึงผ่าน internet
ที่มา: HTTP for Developer.pdf หน้า 2–8, 12–18, 29–33