เบราว์เซอร์ทำงานอย่างไร

 (howbrowserswork.com)
67 คะแนน โดย GN⁺ 2026-01-06 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • คู่มือการเรียนรู้แบบอินเทอร์แอ็กทีฟ ที่สร้างขึ้นเพื่อช่วยให้วิศวกรเว็บและผู้ใช้ทั่วไปเข้าใจ หลักการทำงานภายในของเบราว์เซอร์ ได้อย่างเป็นธรรมชาติ
  • แสดงภาพแต่ละขั้นตอนตั้งแต่การป้อนในแถบที่อยู่ไปจนถึง การสร้างคำขอ HTTP, การแก้ชื่อ DNS, การเชื่อมต่อ TCP, การแยกวิเคราะห์ HTML, การสร้าง DOM, ไปจนถึงเรนเดอริงไปป์ไลน์
  • แต่ละขั้นประกอบด้วย ตัวอย่างที่สามารถพิมพ์หรือปรับแต่งได้ด้วยตัวเอง ทำให้ทดลองและสัมผัสกระบวนการสื่อสารผ่านเครือข่ายและการเรนเดอร์ได้จริง
  • แสดงให้เห็นอย่างชัดเจนถึง บทบาทของ DOM และความแตกต่างของขั้นตอน Layout–Paint–Composite พร้อมให้ตรวจสอบองค์ประกอบที่มีผลต่อประสิทธิภาพได้ด้วยภาพ
  • เป็น สื่อการเรียนรู้ที่ช่วยทำความเข้าใจแนวคิดสำคัญอย่างเป็นระบบ สำหรับนักพัฒนาที่ต้องการเรียนรู้โครงสร้างของเบราว์เซอร์หรือเข้าใจการปรับแต่งประสิทธิภาพเว็บ

ภาพรวม

  • คู่มือนี้สร้างขึ้นสำหรับผู้ที่ใช้งานเว็บทุกวันแต่ ยังไม่เข้าใจชัดเจนว่าเบราว์เซอร์ทำงานอย่างไร
    • ช่วยเติมเต็มข้อจำกัดของสื่อเดิมที่มักจะเทคนิคจ๋าเกินไปหรือผิวเผินเกินไป
    • ออกแบบมาให้เรียนรู้รายละเอียดทางเทคนิคได้อย่างเป็นธรรมชาติผ่าน ตัวอย่างอินเทอร์แอ็กทีฟขนาดเล็ก
  • มีการละรายละเอียดอย่างเวอร์ชัน HTTP, SSL/TLS และการทำงานเชิงลึกของ DNS โดย เน้นเฉพาะแนวคิดหลักให้กระชับ
  • โปรเจกต์นี้เผยแพร่เป็น โอเพนซอร์ส และสามารถเสนอแนวทางปรับปรุงผ่าน GitHub ได้

เบราว์เซอร์และ URL

  • ทุกสตริงที่ผู้ใช้ป้อนในแถบที่อยู่จะถูกแปลงภายในเป็น รูปแบบ URL
  • หลังจากกด Enter จะมี อินเทอร์เฟซสำหรับทดลองใช้งาน ที่ให้ตรวจสอบกระบวนการแปลงได้โดยตรง

การแปลง URL เป็นคำขอ HTTP

  • เมื่อเบราว์เซอร์ยืนยัน URL ที่จะเข้าถึงอย่างถูกต้อง แล้ว ก็จะส่ง คำขอ HTTP ไปยังเซิร์ฟเวอร์
  • ตัวอย่างเฮดเดอร์ของคำขอมีดังนี้ 
    Host: example.com
Accept: text/html
  • เฮดเดอร์ Host ทำหน้าที่เป็น ตัวระบุเซิร์ฟเวอร์ ที่จะส่งคำขอไปถึง

การแก้ที่อยู่เซิร์ฟเวอร์ (DNS)

  • เบราว์เซอร์ไม่สามารถใช้ ชื่อโดเมน อย่าง example.com ได้โดยตรง
    • ต้องแปลงเป็น ที่อยู่ IP ผ่านระบบ DNS ก่อน จึงจะสื่อสารกับเซิร์ฟเวอร์ได้
  • เมื่อป้อนโดเมนในช่องป้อนข้อมูล จะสามารถดู ผลลัพธ์ของการแก้ DNS (ที่อยู่ IP) ได้

การตั้งค่าการเชื่อมต่อ TCP

  • หลังจากได้ IP จาก DNS แล้ว เบราว์เซอร์จะใช้ โปรโตคอล TCP เพื่อสร้างการเชื่อมต่อกับเซิร์ฟเวอร์อย่างเชื่อถือได้
  • การเชื่อมต่อถูกสร้างขึ้นผ่านกระบวนการ 3-way handshake
    1. SYN: ไคลเอนต์ขอเชื่อมต่อ
    2. SYN-ACK: เซิร์ฟเวอร์ตอบกลับและยืนยัน
    3. ACK: ไคลเอนต์ยืนยันขั้นสุดท้าย
  • TCP ช่วยคงการสื่อสารที่เสถียรด้วย การรับประกันลำดับข้อมูลและการส่งซ้ำ
  • สามารถทดลอง ความเสถียรของการส่งข้อมูล ได้ด้วยการตัดเครือข่ายหรือปรับแต่งแพ็กเก็ต

คำขอและการตอบกลับ HTTP

  • หลังจากเชื่อมต่อ TCP แล้ว เบราว์เซอร์จะ ส่งคำขอ HTTP และเซิร์ฟเวอร์จะ ส่งการตอบกลับ HTTP กลับมา
  • มีการ แสดงภาพการเคลื่อนที่ของคำขอและการตอบกลับ ทำให้สังเกตการไหลของแพ็กเก็ตได้
  • เมื่อการตอบกลับมาถึง เบราว์เซอร์จะแยก เฮดเดอร์และเนื้อหา แล้วเริ่มเรนเดอร์ HTML

การแยกวิเคราะห์ HTML และการสร้าง DOM tree

  • เบราว์เซอร์จะส่งไบต์ของ HTML ไปยัง parser เพื่อสร้าง DOM tree
  • เมื่อป้อน HTML ตัวอย่าง จะสามารถเห็นภาพกระบวนการที่แท็กอย่าง <h1>, <p> ถูกแปลงเป็น DOM node ได้อย่างชัดเจน
  • การแยกวิเคราะห์เกิดขึ้นแบบ streaming จึงสามารถสร้างโหนดได้แม้เอกสารจะมายังไม่ครบทั้งหมด
  • เมื่อพบแท็ก <script> การแยกวิเคราะห์จะหยุดชั่วคราวเพื่อรันสคริปต์
  • DOM ที่เสร็จสมบูรณ์จะรวมกับ CSS เพื่อสร้าง render tree

ความสำคัญของ DOM

  • DOM (Document Object Model) คือโมเดลเอกสารภายในหน่วยความจำของเบราว์เซอร์ และเป็น
    โครงสร้างหลักที่ HTML parser, CSS selector engine และ JavaScript runtime ใช้ร่วมกัน
  • การเปลี่ยนแปลง DOM จะสะท้อนทันทีไปยัง layout, style และการโต้ตอบของผู้ใช้
  • มี ฟีเจอร์พรีวิว ที่จะแสดงการเปลี่ยนแปลงของ DOM แบบเรียลไทม์เมื่อแก้ไขโค้ด JavaScript

Layout, Paint, Composite

  • เมื่อ DOM และ CSS พร้อมแล้ว เบราว์เซอร์จะเริ่ม rendering pipeline
    • Layout(Reflow) : คำนวณขนาดและตำแหน่งขององค์ประกอบ
    • Paint: เติมพิกเซล
    • Composite: รวมเลเยอร์บน GPU
  • การเปลี่ยนสีจะรันเฉพาะ Paint ใหม่อีกครั้ง แต่การเปลี่ยนขนาดจะ ต้องรันทั้ง Layout และ Paint ใหม่
  • สามารถคลิกเพื่อตรวจสอบได้ว่าแต่ละขั้นมีการรันใหม่หรือไม่
  • แสดงให้เห็นด้วยภาพว่า หน้าเว็บที่มีการคำนวณ Layout มากจะเรนเดอร์ช้า

สรุป

  • เป็น คู่มือที่ให้เรียนรู้ผ่านการลงมือสัมผัสจริง ครบตั้งแต่การป้อนที่อยู่จนถึงการเรนเดอร์
  • เมื่อทำครบทุกขั้นตอน จะสามารถสร้าง mental model ที่ชัดเจนเกี่ยวกับหลักการทำงานของเบราว์เซอร์ ได้
  • โปรเจกต์นี้เป็น โอเพนซอร์ส และสามารถเสนอการปรับปรุงผ่าน issue หรือ Pull Request บน GitHub ได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-01-06
ความคิดเห็นบน Hacker News

  • ไม่ใช่ทุกเบราว์เซอร์ที่มี DOM มาตั้งแต่แรก
    ในยุคแรกมี WorldWideWeb (Nexus, 1990), Erwise (1992), ViolaWWW (1992), Lynx (1992), NCSA Mosaic (1993), Netscape 1.0 (1994), IE 1.0 (1995) เป็นต้น
    Lynx ยังคงตั้งใจคงสถานะเป็น เบราว์เซอร์แบบไม่มี DOM มาจนถึงทุกวันนี้
    AOL 1.0–2.0 ใช้เอนจินแบบคงที่ (AOLPress) ที่ไม่มีออบเจ็กต์ให้โปรแกรมเข้าไปควบคุมได้
    การโต้ตอบกับ DOM เริ่มทำได้ตั้งแต่ Netscape 2.0 (1995), IE 3.0 (1996), AOL 3.0 (1996), Opera 3.0 (1997)
    หลังจากนั้น Netscape 4.0 (document.layers) และ IE 4.0 (document.all) ก็ใช้โมเดลคนละแบบกัน
    DOM มาตรฐาน ตัวแรกคือ W3C DOM Level 1 (1998) โดย IE 5.0 (1999) รองรับบางส่วน และ Konqueror 2.0 (2000) กับ Netscape 6.0 (2000) เริ่มรองรับครบถ้วน
    Safari 1.0 (2003), Firefox 1.0 (2004), Chrome 1.0 (2008) รองรับ DOM มาตรฐานมาตั้งแต่ต้น และปัจจุบันยึดตาม WHATWG DOM Living Standard

    • เบราว์เซอร์ Dillo ก็ยังคงมี สถาปัตยกรรมแบบไม่มี DOM อยู่เช่นกัน
      เพราะตีความและเรนเดอร์ข้อความ HTML โดยตรง จึงใช้ RAM น้อยมาก
    • อยากถามว่าถ้าจะเขียนว่า “DOM ใน modern browsers” จะแม่นยำกว่าหรือไม่

  • เป็นโปรเจ็กต์ที่ยอดเยี่ยม
    ถ้าเป็นผู้อ่าน HN ก็น่าจะชอบอ่าน High-Performance Browser Networking และ Every Layout ควบคู่กันไปด้วย
    ทั้งสองอย่างเป็นแหล่งข้อมูลชั้นยอดที่เจาะลึกเรื่อง ประสิทธิภาพเว็บและโครงสร้าง CSS

    • HPBN เป็นหนังสือที่เขียนไว้ดีมากจริง ๆ
      บทที่ 4 ทำให้เข้าใจ โครงสร้างเฟรมของ TLS จนสามารถใช้แก้ปัญหา latency ในที่ทำงานเก่าได้
      ส่วนที่พูดถึง trade-off ของการปรับขนาดเฟรม TLS ก็น่าสนใจมาก
      ถึงอาจไม่ได้มีโอกาสใช้บ่อย แต่ก็ทำให้รู้ว่ามีการจูนรายละเอียดระดับเครือข่ายแบบนี้ได้
    • ขอบคุณสำหรับลิงก์ HPBN เป็นข้อมูลที่น่าสนใจมากจริง ๆ

  • เป็นแนวทางที่น่าสนใจ เหมือนได้ลอง browser.engineering โดยไม่ต้องติดตั้งอะไร
    ตอนยกตัวอย่างเบราว์เซอร์กับเซิร์ฟเวอร์ ถ้าเพิ่ม ไอคอนแบบภาพ (เช่น เดสก์ท็อป/เซิร์ฟเวอร์) น่าจะช่วยให้เข้าใจง่ายขึ้น

    • มีแผนจะเพิ่มอีกหลายส่วนและลงรายละเอียดมากขึ้น
      ตอนนี้กำลังรวบรวมฟีดแบ็กอยู่ และข้อเสนอเรื่องไอคอนก็เป็นไอเดียที่ดี น่าจะลองพิจารณาดู

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

    • ตั้งใจละไว้เพื่อให้ยังคงความเรียบง่าย
      ตอนนี้กำลังคิดอยู่ว่าจะเพิ่มบล็อกเหล่านี้อย่างไรโดยไม่ทำให้ซับซ้อนเกินไป

  • เมื่อหน้าต่างเบราว์เซอร์แคบลง (ต่ำกว่า 1170px) มี ปัญหาที่ส่วนสารบัญซ้อนทับขึ้นมาบนเนื้อหา

    • กำลังแก้อยู่

  • น่าจะเกลาตรรกะการ parse URL เพิ่มอีกนิด
    ผู้ใช้ส่วนใหญ่อาจไม่เจอปัญหา แต่เบราว์เซอร์ก็มีการจัดการเป็นพิเศษเมื่อป้อน protocol scheme อื่นนอกเหนือจาก https:// หรือ http://
    น่าจะดีถ้าดักเคสพวกนี้ไว้ด้วย
    อ้างอิง: List of URI schemes

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

  • ค่อนข้างเสียดายที่เกินครึ่งหน้าพูดถึง network request
    ทั้งที่ส่วนซับซ้อนจริง ๆ ของเบราว์เซอร์อยู่ที่ pipeline การ parse และ render

    • มีแผนจะอธิบายส่วนของ rendering engine ให้ละเอียดขึ้น
      ตอนนี้ยังไม่แน่ใจว่าควรลงลึกตรงส่วนไหนบ้าง เลยปล่อยออกมาก่อนแล้วค่อยรับฟีดแบ็ก
    • DOM เองก็นับเป็นส่วนหนึ่งของ rendering pipeline ได้เหมือนกัน

  • อาจเป็นคำถามนอกเรื่อง แต่สงสัยว่าถ้าตัด DNS lookup ออกไปเลย แล้วให้ทำงานด้วย ชื่อโดเมนที่มนุษย์อ่านได้ เท่านั้นจะเป็นอย่างไร

    • ถ้าจะคิดนอกเรื่องยิ่งกว่าเดิม จะเป็นอย่างไรถ้า route กันด้วย Ethernet address แทน IP address
      แนวคิดคือทำให้อินเทอร์เน็ตทั้งระบบกลายเป็นสวิตช์ขนาดมหึมาตัวเดียว
      จำได้ว่าเคยเห็นผู้ก่อตั้ง Tailscale เขียนถึงแนวคิดคล้าย ๆ กันไว้

  • งานเจ๋งมาก