สิ่งที่เกิดขึ้นในการนำทาง
นี่คือส่วนที่ 2 ของซีรีส์บล็อก 4 ส่วนที่กล่าวถึงการทำงานภายในของ Chrome ในโพสต์ก่อนหน้า เราดูว่ากระบวนการและชุดข้อความต่างๆ จัดการกับส่วนต่างๆ ของเบราว์เซอร์อย่างไร ในโพสต์นี้ เราจะเจาะลึกเกี่ยวกับการสื่อสาร แต่ละกระบวนการและชุดข้อความในการแสดงเว็บไซต์
มาดูกรณีการใช้งานง่ายๆ อย่างการท่องเว็บกัน คือคุณพิมพ์ URL ลงในเบราว์เซอร์ จากนั้นเบราว์เซอร์จะดึงข้อมูลจากอินเทอร์เน็ตและแสดงหน้าเว็บ ในโพสต์นี้ เราจะเน้นไปที่ส่วนที่ผู้ใช้ ขอเว็บไซต์ และเบราว์เซอร์เตรียมที่จะแสดงหน้าเว็บ หรือที่เรียกว่าการนำทาง
เริ่มต้นด้วยกระบวนการของเบราว์เซอร์
ตามที่ได้กล่าวไปในส่วนที่ 1: CPU, GPU, หน่วยความจำ และสถาปัตยกรรมการประมวลผลแบบหลายด้าน ทุกอย่างนอกแท็บจะได้รับการจัดการโดยกระบวนการของเบราว์เซอร์ กระบวนการของเบราว์เซอร์มีเทรด เช่น เธรด UI ที่ดึงปุ่มและช่องป้อนข้อมูลของเบราว์เซอร์ เธรดเครือข่ายที่จัดการกับสแต็กเครือข่ายเพื่อรับข้อมูลจากอินเทอร์เน็ต เธรดพื้นที่เก็บข้อมูลที่ควบคุมการเข้าถึงไฟล์ และอื่นๆ เมื่อคุณพิมพ์ URL ลงในแถบที่อยู่ อินพุตของคุณจะได้รับการจัดการโดยเธรด UI ของกระบวนการของเบราว์เซอร์
การนำทางที่เรียบง่าย
ขั้นตอนที่ 1: การจัดการกับอินพุต
เมื่อผู้ใช้เริ่มพิมพ์ลงในแถบที่อยู่ สิ่งแรกที่เธรด UI จะถามคือ "นี่เป็น คำค้นหาหรือ URL ใช่ไหม" ใน Chrome แถบที่อยู่เป็นช่องป้อนข้อมูลการค้นหาด้วย ดังนั้นชุด UI จึงต้องแยกวิเคราะห์และตัดสินใจว่าจะส่งคุณไปยังเครื่องมือค้นหาหรือไปยังเว็บไซต์ที่คุณขอ
ขั้นตอนที่ 2: เริ่มการนำทาง
เมื่อผู้ใช้กดปุ่ม Enter ชุดข้อความ UI จะเริ่มต้นการเรียกเครือข่ายเพื่อรับเนื้อหาเว็บไซต์ ไอคอนหมุนของการโหลดจะปรากฏที่มุมของแท็บ และเธรดของเครือข่ายจะผ่านโปรโตคอลที่เหมาะสม เช่น การค้นหา DNS และสร้างการเชื่อมต่อ TLS สำหรับคำขอ
ในขั้นตอนนี้ เทรดเครือข่ายอาจได้รับส่วนหัวการเปลี่ยนเส้นทางเซิร์ฟเวอร์ เช่น HTTP 301 ในกรณีนี้ เทรดเครือข่ายจะสื่อสารกับเธรด UI ที่เซิร์ฟเวอร์ขอเปลี่ยนเส้นทาง จากนั้นระบบจะเริ่มคำขอ URL อีกรายการหนึ่ง
ขั้นตอนที่ 3: อ่านคำตอบ
เมื่อเนื้อหาการตอบสนอง (เพย์โหลด) เริ่มเข้ามา เทรดเครือข่ายจะดู 2-3 ไบต์แรกของสตรีมหากจำเป็น ส่วนหัว Content-Type ของการตอบกลับควรระบุว่าเป็นประเภทข้อมูลใด แต่เนื่องจากข้อมูลอาจขาดหายไปหรือไม่ถูกต้อง ระบบจึงทำการดักจับประเภท MIME ที่นี่ นี่คือ "ธุรกิจหลอกลวง" ตามที่ได้แสดงความคิดเห็นไว้ในซอร์สโค้ด คุณสามารถอ่านความคิดเห็นเพื่อดูว่าเบราว์เซอร์ต่างๆ จัดการกับคู่ประเภทเนื้อหา/เพย์โหลดอย่างไร
หากการตอบกลับเป็นไฟล์ HTML ขั้นตอนต่อไปคือส่งข้อมูลไปยังกระบวนการของตัวแสดงผล แต่หากเป็นไฟล์ ZIP หรือไฟล์อื่น แสดงว่าเป็นคำขอดาวน์โหลด ผู้ใช้จึงต้องส่งข้อมูลไปยัง Download Manager
รวมถึงยังมีการตรวจสอบ SafeBrowsing อีกด้วย หากโดเมนและข้อมูลการตอบกลับดูเหมือนจะตรงกับเว็บไซต์อันตรายที่ทราบ การแจ้งเตือนเทรดเครือข่ายจะแสดงหน้าคำเตือน นอกจากนี้ การตรวจสอบCCการCปลดล็อก (C) ขั้นต้นจะเกิดขึ้นเพื่อให้แน่ใจว่าข้อมูลข้ามเว็บไซต์ที่มีความละเอียดอ่อนไม่ส่งไปยังกระบวนการแสดงผลC
ขั้นตอนที่ 4: ค้นหากระบวนการของโหมดแสดงภาพ
เมื่อตรวจสอบทั้งหมดเสร็จแล้วและเทรดเครือข่ายมั่นใจว่าเบราว์เซอร์ควรไปยังเว็บไซต์ที่ขอ เทรดเครือข่ายจะแจ้งเทรด UI ว่าข้อมูลพร้อมแล้ว จากนั้นเธรด UI จะหากระบวนการ แสดงผลเพื่อแสดงผลหน้าเว็บต่อไป
เนื่องจากคำขอเครือข่ายอาจใช้เวลาหลายร้อยมิลลิวินาทีในการตอบกลับ จึงมีการใช้การเพิ่มประสิทธิภาพเพื่อเพิ่มความเร็วให้กระบวนการนี้ เมื่อเธรด UI ส่งคำขอ URL ไปยังเทรดเครือข่ายในขั้นตอนที่ 2 ระบบจะรู้ว่ากำลังไปยังเว็บไซต์ใด เธรด UI จะพยายามค้นหาหรือเริ่มกระบวนการแสดงภาพในเชิงรุกควบคู่ไปกับคำขอของเครือข่าย วิธีนี้จะทำให้กระบวนการของโหมดแสดงภาพอยู่ในตำแหน่งสแตนด์บายอยู่แล้วเมื่อเทรดเครือข่ายได้รับข้อมูล หากการทำงานทั้งหมดเป็นไปตามที่คาดไว้ กระบวนการสแตนด์บายนี้อาจไม่นำมาใช้หากการนำทางเปลี่ยนเส้นทางข้ามเว็บไซต์ ซึ่งในกรณีนี้อาจต้องใช้กระบวนการอื่น
ขั้นตอนที่ 5: คอมมิตการนำทาง
ตอนนี้ข้อมูลและกระบวนการของโหมดแสดงภาพพร้อมแล้ว จะมีการส่ง IPC จากกระบวนการของเบราว์เซอร์ไปยังกระบวนการของผู้แสดงผลเพื่อยืนยันการนำทาง นอกจากนี้ยังส่งผ่านสตรีมข้อมูลเพื่อให้กระบวนการ แสดงผลรับข้อมูล HTML ต่อไปได้ เมื่อกระบวนการของเบราว์เซอร์ได้ยินคำยืนยันว่าคอมมิตเกิดขึ้นในกระบวนการแสดงผล การนำทางจะเสร็จสมบูรณ์และขั้นตอนการโหลดเอกสารจะเริ่มต้นขึ้น
ณ จุดนี้ แถบที่อยู่จะได้รับการอัปเดต และสัญญาณบอกสถานะความปลอดภัยและ UI การตั้งค่าเว็บไซต์จะแสดงข้อมูลเว็บไซต์ของหน้าเว็บใหม่ ประวัติเซสชันของแท็บจะได้รับการอัปเดต เพื่อให้ปุ่มย้อนกลับ/ไปข้างหน้าสามารถเลื่อนดูในเว็บไซต์ที่เข้าชมได้ เพื่ออำนวยความสะดวกในการกู้คืนแท็บ/เซสชันเมื่อคุณปิดแท็บหรือหน้าต่าง ประวัติเซสชันจะถูกเก็บไว้ในดิสก์
ขั้นตอนเพิ่มเติม: การโหลดครั้งแรกเสร็จสมบูรณ์แล้ว
เมื่อคอมมิตการนำทางแล้ว กระบวนการของโหมดแสดงภาพจะดำเนินการโหลดทรัพยากรและแสดงหน้าเว็บ เราจะอธิบายรายละเอียดของสิ่งที่เกิดขึ้นในขั้นตอนนี้ในข้อความถัดไป เมื่อโหมดแสดงภาพ "สิ้นสุด" การประมวลผลแล้ว จะมีการส่ง IPC กลับไปยังกระบวนการของเบราว์เซอร์ (กล่าวคือหลังจากที่เหตุการณ์ onload ทั้งหมดเริ่มทำงานบนทุกเฟรมในหน้าและดำเนินการเสร็จสิ้นแล้ว) ณ จุดนี้ เธรด UI จะหยุดไอคอนหมุนของการโหลดบนแท็บ
ผมพูดว่า "สิ้นสุด" เพราะ JavaScript ฝั่งไคลเอ็นต์ยังสามารถโหลด ทรัพยากรเพิ่มเติมและแสดงมุมมองใหม่หลังจากจุดนี้ได้
การนำทางไปยังเว็บไซต์อื่น
การนำทางง่ายๆ เสร็จสมบูรณ์ แต่ถ้าผู้ใช้ใส่ URL ที่ต่างกันลงในแถบที่อยู่อีกครั้ง
จะเกิดอะไรขึ้น กระบวนการของเบราว์เซอร์จะผ่านขั้นตอนเดียวกันเพื่อไปยังเว็บไซต์อื่น
แต่ก่อนที่จะทำเช่นนั้นได้ คุณต้องตรวจสอบกับเว็บไซต์ที่แสดงผลอยู่ในปัจจุบันว่าสนใจเหตุการณ์ beforeunload หรือไม่
beforeunload สามารถสร้างการแจ้งเตือน "ออกจากเว็บไซต์นี้ใช่ไหม" เมื่อพยายามออกจากหน้าหรือปิดแท็บ
ทุกอย่างที่อยู่ภายในแท็บซึ่งรวมถึงโค้ด JavaScript จะได้รับการจัดการโดยกระบวนการแสดงผล
ดังนั้นกระบวนการของเบราว์เซอร์จึงต้องตรวจสอบกระบวนการแสดงผลปัจจุบันเมื่อมีคำขอการนำทางใหม่เข้ามา
หากการนำทางเริ่มต้นขึ้นจากกระบวนการของโหมดแสดงภาพ (เช่น ผู้ใช้คลิกลิงก์ หรือ JavaScript ฝั่งไคลเอ็นต์เรียกใช้ window.location = "https://newsite.com") กระบวนการของโหมดแสดงภาพจะตรวจสอบตัวแฮนเดิล beforeunload ก่อน จากนั้น จะเข้าสู่กระบวนการเดียวกับ
การไปยังส่วนต่างๆ ของกระบวนการของเบราว์เซอร์ ความแตกต่างเพียงอย่างเดียวคือคำขอการนำทางจะเริ่มต้นจาก
กระบวนการแสดงผลไปยังกระบวนการของเบราว์เซอร์
เมื่อมีการสร้างการนำทางใหม่ในเว็บไซต์อื่นซึ่งต่างจากเว็บไซต์ที่แสดงผลอยู่ ระบบจะเรียกใช้กระบวนการแสดงผลแยกต่างหากเพื่อจัดการการนำทางใหม่ ในขณะที่กระบวนการแสดงผลปัจจุบันจะคำนึงถึงการจัดการเหตุการณ์อย่างเช่น unload ดูข้อมูลเพิ่มเติมได้ที่ภาพรวมของสถานะวงจรของหน้าเว็บ และวิธีเชื่อมโยงเหตุการณ์ด้วย Page Lifecycle API
ในกรณีของ Service Worker
การเปลี่ยนแปลงล่าสุดอย่างหนึ่งในกระบวนการนำทางนี้คือการเปิดตัวโปรแกรมทำงานของบริการ โปรแกรมทำงานของบริการเป็นวิธีการเขียนพร็อกซีเครือข่ายในโค้ดแอปพลิเคชันของคุณ ซึ่งทำให้นักพัฒนาเว็บสามารถควบคุมสิ่งที่จะแคชในระบบได้มากขึ้นและเวลาในการรับข้อมูลใหม่จากเครือข่าย หากมีการตั้งค่า Service Worker ให้โหลดหน้าเว็บจากแคช ก็ไม่จำเป็นต้องขอข้อมูลจากเครือข่าย
ส่วนสำคัญที่ต้องจำไว้คือ Service Worker คือโค้ด JavaScript ที่ทำงานในกระบวนการของโหมดแสดงภาพ แต่เมื่อมีคำขอการนำทางเข้ามา กระบวนการของเบราว์เซอร์จะรู้ได้อย่างไรว่าเว็บไซต์มี Service Worker
เมื่อลงทะเบียน Service Worker แล้ว ระบบจะเก็บขอบเขตของ Service Worker ไว้เป็นข้อมูลอ้างอิง (อ่านเพิ่มเติมเกี่ยวกับขอบเขตในบทความวงจรการทำงานของ Service Worker นี้) เมื่อมีการไปยังส่วนต่างๆ เทรดเครือข่ายจะตรวจสอบโดเมนกับขอบเขต Service Worker ที่ลงทะเบียนไว้ หากโปรแกรมทำงานของบริการลงทะเบียนสำหรับ URL นั้น เทรด UI จะค้นหากระบวนการของโหมดแสดงภาพเพื่อเรียกใช้งานโค้ด Service Worker โปรแกรมทำงานของบริการอาจโหลดข้อมูลจากแคช ทำให้ไม่จำเป็นต้องขอข้อมูลจากเครือข่าย หรืออาจขอทรัพยากรใหม่จากเครือข่าย
การโหลดการนำทางล่วงหน้า
คุณสามารถดูข้อมูลไป-กลับนี้ระหว่างกระบวนการของเบราว์เซอร์กับกระบวนการแสดงผลอาจทำให้เกิดความล่าช้า หากโปรแกรมทำงานของบริการตัดสินใจขอข้อมูลจากเครือข่ายในที่สุด การโหลดการนำทางล่วงหน้าเป็นกลไกในการเพิ่มความเร็วให้กระบวนการนี้โดยการโหลดทรัพยากรควบคู่ไปกับการเริ่มการทำงานของ Service Worker ซึ่งจะทำเครื่องหมายคำขอเหล่านี้ด้วยส่วนหัว ซึ่งทำให้เซิร์ฟเวอร์ตัดสินใจที่จะส่งเนื้อหาอื่นสำหรับคำขอเหล่านี้ได้ เช่น ข้อมูลที่อัปเดตแทนที่จะส่งเป็นเอกสารทั้งฉบับ
สรุป
ในโพสต์นี้ เราพูดถึงสิ่งที่เกิดขึ้นระหว่างการนำทางและโค้ดเว็บแอปพลิเคชัน เช่น ส่วนหัวการตอบกลับและ JavaScript ฝั่งไคลเอ็นต์โต้ตอบกับเบราว์เซอร์ การรู้ขั้นตอนที่เบราว์เซอร์ใช้เพื่อดูข้อมูลจากเครือข่ายทำให้เข้าใจได้ง่ายขึ้นว่าเหตุใด API อย่างการโหลดล่วงหน้าสำหรับการนำทางจึงได้รับการพัฒนาขึ้น ในโพสต์ถัดไป เราจะเจาะลึกเกี่ยวกับวิธีที่เบราว์เซอร์ประเมิน HTML/CSS/JavaScript ของเราในการแสดงผลหน้าเว็บ
คุณชอบโพสต์นี้ไหม หากคุณมีคำถามหรือคำแนะนำสำหรับโพสต์ในอนาคต เรายินดีรับฟังความคิดเห็นจากคุณในส่วนความคิดเห็นด้านล่างหรือ @kosamari บน Twitter