เว็บไซต์ทำงานอย่างไร — ตั้งแต่พิมพ์ URL จนหน้าเว็บปรากฏ

ทุกครั้งที่เราพิมพ์ชื่อเว็บแล้วกด Enter หน้าเว็บก็ขึ้นมาภายในไม่กี่วินาที ดูเหมือนง่าย แต่เบื้องหลังมีขั้นตอนที่ทำงานประสานกันหลายอย่าง บทความนี้จะพาไล่ทีละขั้นแบบที่คนไม่มีพื้นฐานก็ตามได้ และคนที่เขียนโค้ดอยู่แล้วก็จะเห็นภาพรวมชัดขึ้น

ผมสอนวิชาการเขียนเว็บมาหลายปี และพบว่านักเรียนที่เข้าใจ "ภาพรวม" ตรงนี้ก่อน จะเรียนเรื่องอื่นได้เร็วกว่ามาก เพราะรู้ว่าโค้ดที่ตัวเองเขียนไปอยู่ตรงไหนของกระบวนการ

ขั้นที่ 1 เบราว์เซอร์อ่าน URL ของเราก่อน

URL ไม่ใช่ข้อความก้อนเดียว แต่ประกอบด้วยหลายส่วนที่เบราว์เซอร์แยกออกจากกัน ลองดูตัวอย่างนี้

https://pansaa.com/blog/how-websites-work
└─┬─┘   └────┬────┘└─────────┬─────────┘
  │          │               │
โปรโตคอล   ชื่อโฮสต์        เส้นทาง

• โปรโตคอล บอกว่าจะคุยกันด้วยกติกาไหน https คือ HTTP ที่เข้ารหัสแล้ว
• ชื่อโฮสต์ คือชื่อเครื่องปลายทางที่เราอยากคุยด้วย
• เส้นทาง บอกว่าต้องการหน้าไหนในเครื่องนั้น

โครงสร้างนี้เป็นมาตรฐานสากลที่กำหนดไว้ใน RFC 3986 ขององค์กร IETF ไม่ใช่กติกาที่แต่ละเบราว์เซอร์คิดขึ้นเอง ทุกเบราว์เซอร์ในโลกจึงอ่าน URL เหมือนกันหมด

ขั้นที่ 2 DNS แปลชื่อเว็บให้เป็นหมายเลข

คอมพิวเตอร์บนอินเทอร์เน็ตไม่ได้เรียกหากันด้วยชื่อ แต่ใช้หมายเลขที่เรียกว่า IP address เช่น 145.79.30.103 การแปลงจากชื่อเป็นหมายเลขนี้คืองานของระบบ DNS

เปรียบเทียบง่าย ๆ DNS ก็คือสมุดโทรศัพท์ เรารู้จักชื่อคน แต่โทรศัพท์ต้องการเบอร์

สิ่งที่หลายคนไม่รู้คือ การถามชื่อหนึ่งครั้งไม่ได้ถามที่เดียว แต่ไล่ถามเป็นลำดับชั้น

1. เบราว์เซอร์ดูในหน่วยความจำตัวเองก่อนว่าเพิ่งถามไปหรือเปล่า
2. ถ้าไม่มี ถามระบบปฏิบัติการของเครื่อง
3. ถ้ายังไม่มี ส่งต่อไปยังเซิร์ฟเวอร์ DNS ของผู้ให้บริการอินเทอร์เน็ต
4. เซิร์ฟเวอร์นั้นจะไล่ถามต่อไปจนถึงเซิร์ฟเวอร์ที่ถือข้อมูลจริงของโดเมนนั้น

ทุกชั้นจะ "จำ" คำตอบไว้ชั่วคราวตามเวลาที่กำหนด (เรียกว่า TTL) การเปลี่ยนโดเมนไปชี้เซิร์ฟเวอร์ใหม่จึงไม่เห็นผลทันทีทั่วโลก ต้องรอให้ของเก่าหมดอายุก่อน นี่คือเหตุผลที่ช่างมักบอกว่า "รอ DNS อัปเดตสัก 24 ชั่วโมง"

ขั้นที่ 3 สร้างการเชื่อมต่อ และเข้ารหัสด้วย TLS

เมื่อรู้หมายเลขปลายทางแล้ว เบราว์เซอร์จะเปิดการเชื่อมต่อไปยังเซิร์ฟเวอร์ ขั้นตอนนี้เรียกว่า TCP handshake คือการทักทายกันสามจังหวะเพื่อยืนยันว่าทั้งสองฝ่ายพร้อมรับส่งข้อมูลจริง

ถ้าเป็น https จะมีอีกขั้นตามมาคือ TLS handshake ซึ่งทำสองอย่างพร้อมกัน

• ยืนยันตัวตน ว่าเซิร์ฟเวอร์ที่เราคุยด้วยเป็นเจ้าของโดเมนนั้นจริง ไม่ใช่คนกลางที่แอบสวมรอย
• ตกลงกุญแจเข้ารหัส เพื่อให้ข้อมูลที่ส่งกันระหว่างทางอ่านไม่ออกถ้ามีคนดักจับ

มาตรฐานปัจจุบันคือ TLS 1.3 ตาม RFC 8446 ซึ่งเร็วกว่ารุ่นก่อนเพราะลดจำนวนรอบการทักทายลง

นี่คือเหตุผลที่เว็บที่รับข้อมูลผู้ใช้ เช่น หน้าเข้าสู่ระบบหรือหน้าชำระเงิน ต้องเป็น https เสมอ ถ้าเป็น http ธรรมดา รหัสผ่านที่ผู้ใช้พิมพ์จะวิ่งผ่านเครือข่ายในรูปข้อความที่อ่านออกได้

ขั้นที่ 4 ส่งคำขอ HTTP

พอเชื่อมต่อได้แล้ว เบราว์เซอร์จะส่งคำขอไปบอกว่าต้องการอะไร หน้าตาของคำขอจริง ๆ เป็นข้อความประมาณนี้

GET /blog/how-websites-work HTTP/1.1
Host: pansaa.com
Accept: text/html
Accept-Language: th
User-Agent: Mozilla/5.0 ...

บรรทัดแรกบอก เมธอด ว่าจะทำอะไร ที่ใช้บ่อยคือ

ความหมายของเมธอดเหล่านี้กำหนดไว้ใน RFC 9110 การใช้ให้ตรงความหมายไม่ใช่แค่เรื่องความสวยงามของโค้ด แต่มีผลจริง เช่น เบราว์เซอร์และตัวกลางระหว่างทางจะจำ (cache) ผลของ GET ได้ แต่จะไม่จำผลของ POST

ขั้นที่ 5 เซิร์ฟเวอร์ประมวลผลและตอบกลับ

ฝั่งเซิร์ฟเวอร์จะรับคำขอไปแล้วทำงานตามที่โปรแกรมเมอร์เขียนไว้ โดยทั่วไปคือ

1. ดูว่าเส้นทางที่ขอมาตรงกับหน้าไหน
2. ดึงข้อมูลที่ต้องใช้จากฐานข้อมูล
3. ประกอบข้อมูลเข้ากับแม่แบบหน้าเว็บให้กลายเป็น HTML
4. ส่งกลับไปพร้อมรหัสสถานะ

รหัสสถานะเป็นตัวเลขสามหลักที่บอกผลลัพธ์ กลุ่มที่เจอบ่อยคือ

เวลาที่ใช้ตั้งแต่ส่งคำขอจนได้ไบต์แรกกลับมา เรียกว่า TTFB ซึ่งเป็นตัวชี้วัดสำคัญว่าเซิร์ฟเวอร์และโปรแกรมฝั่งหลังบ้านทำงานเร็วแค่ไหน

ขั้นที่ 6 เบราว์เซอร์แปลง HTML ให้เป็นหน้าเว็บ

สิ่งที่เซิร์ฟเวอร์ส่งกลับมาเป็นแค่ข้อความ ไม่ใช่ภาพหน้าเว็บ เบราว์เซอร์ต้องแปลงเองเป็นลำดับดังนี้

1. อ่าน HTML แล้วสร้าง DOM คือโครงสร้างต้นไม้ของเนื้อหา
2. อ่าน CSS แล้วสร้าง CSSOM คือกฎการแสดงผลทั้งหมด
3. รวมสองอย่างเป็น render tree ว่าอะไรต้องแสดงและหน้าตาแบบไหน
4. คำนวณตำแหน่งและขนาด ของทุกชิ้น (เรียกว่า layout หรือ reflow)
5. วาดลงหน้าจอ

ระหว่างนี้ถ้าเจอ <script> แบบธรรมดา เบราว์เซอร์จะหยุดอ่าน HTML ชั่วคราวเพื่อรันสคริปต์นั้นก่อน เพราะสคริปต์อาจแก้โครงสร้างหน้าได้ นี่คือสาเหตุที่การวางสคริปต์ผิดที่ทำให้หน้าเว็บขึ้นช้าลงอย่างเห็นได้ชัด

ทางแก้คือใส่คำสั่ง defer เพื่อบอกว่าให้โหลดไปพร้อมกันได้แต่ค่อยรันตอนอ่าน HTML เสร็จ หรือใช้ async เมื่อสคริปต์นั้นไม่เกี่ยวกับเนื้อหาหน้า

แล้วทำไมบางเว็บเร็ว บางเว็บช้า

เมื่อเห็นครบทุกขั้นแล้ว จะเข้าใจได้ทันทีว่าความช้าเกิดได้หลายจุด ไม่ใช่แค่ "อินเทอร์เน็ตช้า"

การรู้ว่าปัญหาอยู่ขั้นไหนสำคัญกว่าการเดา เพราะแต่ละขั้นแก้คนละวิธี และการแก้ผิดจุดคือการเสียเวลาเปล่า

สรุป

ทั้งหมดนี้เกิดขึ้นภายในเวลาไม่ถึงวินาทีในเว็บที่ทำมาดี ลำดับที่ควรจำคือ

อ่าน URL → แปลงชื่อเป็นหมายเลขด้วย DNS → เชื่อมต่อและเข้ารหัส → ส่งคำขอ HTTP → เซิร์ฟเวอร์ตอบกลับ → เบราว์เซอร์วาดหน้าจอ

สำหรับผู้ที่กำลังเรียนเขียนเว็บ ลองเปิดเครื่องมือสำหรับนักพัฒนาในเบราว์เซอร์ (กด F12) แล้วดูแท็บ Network ขณะโหลดหน้าเว็บ จะเห็นทุกขั้นที่เล่ามาเกิดขึ้นจริงพร้อมเวลาที่ใช้แต่ละส่วน เป็นวิธีเรียนรู้ที่เห็นภาพที่สุด

และสำหรับเจ้าของธุรกิจ ความเข้าใจตรงนี้ช่วยให้คุยกับผู้รับงานได้ตรงจุดขึ้นมาก เวลาที่เว็บมีปัญหาจะได้อธิบายอาการได้ถูก แทนที่จะบอกแค่ว่า "เว็บช้า"