สิ่งที่เกิดขึ้นในการนำทาง
นี่เป็นชุดบล็อกส่วนที่ 2 จาก 4 ตอนที่กล่าวถึงการทำงานภายในของ Chrome ในโพสต์ก่อนหน้า เราได้พูดถึงความแตกต่าง กระบวนการและชุดข้อความจะจัดการส่วนต่างๆ ของเบราว์เซอร์ ในโพสต์นี้ เราจะไปเจาะลึกกันว่า แต่ละกระบวนการและเธรดจะสื่อสารกันเพื่อแสดงเว็บไซต์
ลองมาดูกรณีการใช้งานง่ายๆ ของการท่องเว็บกัน โดยพิมพ์ URL ในเบราว์เซอร์ จากนั้นพิมพ์ 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 เสร็จที่นี่ นี่คือ "ธุรกิจที่หลอกลวง" ตามที่แสดงความคิดเห็นไว้ในซอร์สโค้ด คุณอ่านความคิดเห็นเพื่อดูว่าเบราว์เซอร์ต่างๆ จัดการคู่ Content-type/Payload อย่างไร
หากการตอบสนองเป็นไฟล์ HTML ขั้นตอนถัดไปคือการส่งข้อมูลไปยังตัวแสดงผล แต่หากเป็นไฟล์ ZIP หรือไฟล์อื่นๆ แสดงว่าเป็นคำขอดาวน์โหลด พวกเขาต้องส่งข้อมูลไปยัง Download Manager
ซึ่งจะมีการตรวจสอบ SafeBrowsing ด้วย หากโดเมนและข้อมูลการตอบกลับดูเหมือนจะตรงกับเว็บไซต์ที่เป็นอันตรายซึ่งเป็นที่รู้จัก ทำให้เทรดเครือข่าย เพื่อแสดงหน้าคำเตือน นอกจากนี้ การล็อกลบ (CORB) เพื่อตรวจสอบว่ามีความละเอียดอ่อนข้ามเว็บไซต์ ไม่ส่งไปยังกระบวนการแสดงผล
ขั้นตอนที่ 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 เป็นวิธีการเขียน พร็อกซีเครือข่ายในรหัสแอปพลิเคชัน ทำให้นักพัฒนาเว็บ สามารถควบคุมสิ่งที่จะ ไว้ในเครื่องและเมื่อใดที่จะรับข้อมูลใหม่จากเครือข่าย หากมีการตั้งค่าโปรแกรมทำงานของบริการให้โหลดหน้าเว็บ จากแคช คุณไม่จำเป็นต้องขอข้อมูลจากเครือข่าย
สิ่งสำคัญที่ต้องจำไว้คือ Service Worker คือโค้ด JavaScript ที่ทำงานในโหมดแสดงภาพ ขั้นตอนได้ แต่เมื่อมีคำขอการนำทางเข้ามา กระบวนการของเบราว์เซอร์จะรู้ได้อย่างไรว่าไซต์มี Service Worker
เมื่อลงทะเบียน Service Worker แล้ว ขอบเขตของ Service Worker จะเก็บไว้เป็นข้อมูลอ้างอิง (คุณสามารถอ่านเพิ่มเติมเกี่ยวกับขอบเขตได้ใน บทความวงจรของ Service Worker) เมื่อมีการไปยังส่วนต่างๆ เกิดขึ้น เทรดเครือข่ายจะตรวจสอบโดเมนเทียบกับ Service Worker ที่ลงทะเบียนไว้ หากลงทะเบียน Service Worker สำหรับ URL นั้น เทรด UI จะค้นหากระบวนการของโหมดแสดงภาพใน เพื่อเรียกใช้โค้ดโปรแกรมทำงานของบริการ โปรแกรมทำงานของบริการอาจโหลดข้อมูลจากแคช ทำให้ลบ เมื่อต้องขอข้อมูลจากเครือข่าย หรืออาจขอทรัพยากรใหม่จากเครือข่าย
การโหลดการนำทางล่วงหน้า
คุณสามารถดูการเดินทางไป-กลับนี้ระหว่างการประมวลผลของเบราว์เซอร์และกระบวนการแสดงผลอาจส่งผลให้เกิดความล่าช้า หากโปรแกรมทำงานของบริการตัดสินใจขอข้อมูลจากเครือข่าย การโหลดการนำทางล่วงหน้าเป็นกลไกในการเพิ่มความเร็ว โดยโหลดทรัพยากรควบคู่ไปกับการเริ่มต้นโปรแกรมทำงานของบริการ โดยจะทำเครื่องหมายคำขอเหล่านี้ด้วยส่วนหัว ทำให้เซิร์ฟเวอร์สามารถตัดสินใจส่งเนื้อหาที่แตกต่างกันสำหรับ คำขอเหล่านี้ ตัวอย่างเช่น เพิ่งอัปเดตข้อมูลแทนที่จะเป็นเอกสารแบบเต็ม
สรุป
ในโพสต์นี้ เราได้ดูสิ่งที่เกิดขึ้นระหว่างการนำทาง และดูว่าโค้ดเว็บแอปพลิเคชันของคุณ เป็นส่วนหัวการตอบกลับและ JavaScript ฝั่งไคลเอ็นต์จะโต้ตอบกับเบราว์เซอร์ เบราว์เซอร์ทราบขั้นตอน ดึงข้อมูลจากเครือข่ายช่วยให้เข้าใจได้ง่ายขึ้นว่าทำไม API อย่างการนำทาง มีการพัฒนาการโหลดล่วงหน้า ในโพสต์ถัดไป เราจะเจาะลึกวิธีที่เบราว์เซอร์ประเมิน HTML/CSS/JavaScript ในการแสดงผลหน้า
คุณชอบโพสต์นี้ไหม หากคุณมีคำถามหรือข้อเสนอแนะเกี่ยวกับโพสต์ในอนาคต โปรด รับฟังความคิดเห็นของคุณในส่วนความคิดเห็นด้านล่างหรือ @kosamari บน Twitter