نگاهی به مرورگر وب مدرن (قسمت 2)

آنچه در ناوبری اتفاق می افتد

این قسمت 2 از یک سری وبلاگ 4 قسمتی است که به عملکردهای داخلی کروم می پردازد. در پست قبلی ، نحوه مدیریت فرآیندها و رشته‌های مختلف با بخش‌های مختلف مرورگر را بررسی کردیم. در این پست، نحوه ارتباط هر فرآیند و رشته برای نمایش یک وب سایت را عمیق تر می کنیم.

بیایید به یک مورد استفاده ساده از مرور وب نگاه کنیم: شما یک URL را در یک مرورگر تایپ می کنید، سپس مرورگر داده ها را از اینترنت واکشی می کند و صفحه ای را نمایش می دهد. در این پست، ما روی قسمتی تمرکز می‌کنیم که کاربر درخواست یک سایت را می‌دهد و مرورگر برای ارائه یک صفحه آماده می‌شود - همچنین به عنوان ناوبری شناخته می‌شود.

با یک فرآیند مرورگر شروع می شود

همانطور که در بخش 1 توضیح دادیم: CPU، GPU، حافظه و معماری چند فرآیندی ، همه چیز خارج از یک برگه توسط فرآیند مرورگر مدیریت می شود. فرآیند مرورگر دارای رشته‌هایی مانند رشته UI است که دکمه‌ها و فیلدهای ورودی مرورگر را می‌کشد، رشته شبکه که با پشته شبکه برای دریافت داده‌ها از اینترنت سروکار دارد، رشته ذخیره‌سازی که دسترسی به فایل‌ها را کنترل می‌کند و موارد دیگر. وقتی URL را در نوار آدرس تایپ می کنید، ورودی شما توسط رشته UI فرآیند مرورگر مدیریت می شود.

یک ناوبری ساده

مرحله 1: مدیریت ورودی

هنگامی که کاربر شروع به تایپ در نوار آدرس می کند، اولین چیزی که رشته UI می پرسد این است که "این یک عبارت جستجو یا URL است؟" در کروم، نوار آدرس نیز یک فیلد ورودی جستجو است، بنابراین رشته رابط کاربری باید تجزیه شود و تصمیم بگیرد که آیا شما را به موتور جستجو ارسال کند یا به سایتی که درخواست کرده‌اید.

مرحله 2: ناوبری را شروع کنید

هنگامی که کاربر اینتر را می‌زند، رشته رابط کاربری یک تماس شبکه را برای دریافت محتوای سایت آغاز می‌کند. در حال بارگذاری اسپینر در گوشه یک برگه نمایش داده می شود و رشته شبکه از طریق پروتکل های مناسب مانند جستجوی DNS و ایجاد اتصال TLS برای درخواست می گذرد.

در این مرحله، رشته شبکه ممکن است یک هدر تغییر مسیر سرور مانند HTTP 301 دریافت کند. در این صورت، رشته شبکه با رشته رابط کاربری که سرور درخواست تغییر مسیر را دارد، ارتباط برقرار می کند. سپس، یک درخواست URL دیگر آغاز خواهد شد.

مرحله 3: پاسخ را بخوانید

هنگامی که بدنه پاسخ (بارگذاری بار) شروع به ورود می کند، رشته شبکه در صورت لزوم به چند بایت اول جریان نگاه می کند. هدر Content-Type پاسخ باید نشان دهد که چه نوع داده ای است، اما از آنجایی که ممکن است گم یا اشتباه باشد، MIME Type Sniffing در اینجا انجام می شود. همانطور که در کد منبع توضیح داده شده است، این یک "کسب و کار دشوار" است. می‌توانید نظر را بخوانید تا ببینید مرورگرهای مختلف چگونه با جفت‌های نوع محتوا/بار پرداختی رفتار می‌کنند.

اگر پاسخ یک فایل HTML باشد، مرحله بعدی ارسال داده ها به فرآیند رندر است، اما اگر یک فایل فشرده یا فایل دیگری باشد، به این معنی است که درخواست دانلود است، بنابراین آنها باید داده ها را به آنها ارسال کنند. مدیریت دانلود.

در اینجا نیز بررسی SafeBrowsing اتفاق می‌افتد. اگر به نظر می رسد دامنه و داده های پاسخ با یک سایت مخرب شناخته شده مطابقت دارند، رشته شبکه هشدار می دهد تا یک صفحه هشدار را نمایش دهد. علاوه بر این، Cross O rigin R ead B locking ( CORB ) بررسی می‌شود تا مطمئن شود داده‌های حساس بین سایتی به فرآیند رندر نمی‌رسند.

مرحله 4: یک فرآیند رندر پیدا کنید

وقتی همه بررسی‌ها انجام شد و Network Thread مطمئن شد که مرورگر باید به سایت درخواستی حرکت کند، رشته Network به رشته UI می‌گوید که داده‌ها آماده است. سپس رشته UI یک فرآیند رندر را برای انجام رندر صفحه وب پیدا می کند.

از آنجایی که درخواست شبکه ممکن است چند صد میلی ثانیه طول بکشد تا پاسخ را بازگرداند، بهینه سازی برای سرعت بخشیدن به این فرآیند اعمال می شود. هنگامی که رشته UI در مرحله 2 درخواست URL را به رشته شبکه ارسال می کند، از قبل می داند که به کدام سایت پیمایش می کند. رشته UI سعی می کند به طور فعال یک فرآیند رندر را به موازات درخواست شبکه پیدا کند یا شروع کند. به این ترتیب، اگر همه چیز همانطور که انتظار می رود پیش برود، یک فرآیند رندر در حال حاضر در حالت آماده به کار است زمانی که رشته شبکه داده را دریافت کرد. اگر پیمایش بین سایتی تغییر مسیر دهد، ممکن است از این فرآیند آماده به کار استفاده نشود، در این صورت ممکن است به فرآیند دیگری نیاز باشد.

مرحله 5: ناوبری را متعهد کنید

اکنون که داده ها و فرآیند رندر آماده است، یک IPC از فرآیند مرورگر به فرآیند رندر ارسال می شود تا ناوبری را انجام دهد. همچنین به جریان داده منتقل می شود تا فرآیند رندر بتواند به دریافت داده های HTML ادامه دهد. هنگامی که فرآیند مرورگر تأیید می‌کند که commit در فرآیند رندر انجام شده است، ناوبری کامل می‌شود و مرحله بارگیری سند آغاز می‌شود.

در این مرحله، نوار آدرس به روز می شود و نشانگر امنیتی و تنظیمات سایت، اطلاعات سایت صفحه جدید را منعکس می کند. تاریخچه جلسه برای برگه به‌روزرسانی می‌شود، بنابراین دکمه‌های برگشت/به جلو از سایتی که به تازگی به آن پیمایش شده است، عبور می‌کنند. برای تسهیل بازیابی برگه/جلسه هنگام بستن برگه یا پنجره، تاریخچه جلسه روی دیسک ذخیره می شود.

مرحله اضافی: بار اولیه کامل شد

پس از انجام ناوبری، فرآیند رندر بارگیری منابع را ادامه می دهد و صفحه را رندر می کند. در پست بعدی به جزئیات اتفاقاتی که در این مرحله می افتد خواهیم پرداخت. هنگامی که فرآیند رندر رندر «پایان» می‌یابد، یک IPC را به فرآیند مرورگر باز می‌فرستد (این پس از آن است که همه رویدادهای onload روی همه فریم‌های صفحه اجرا شده و اجرا به پایان رسیده است). در این مرحله، رشته UI چرخش بارگذاری روی زبانه را متوقف می کند.

من می گویم "پایان"، زیرا جاوا اسکریپت سمت سرویس گیرنده همچنان می تواند منابع اضافی را بارگیری کند و پس از این مرحله نماهای جدید ارائه دهد.

پیمایش به سایت دیگری

ناوبری ساده کامل شد! اما اگر کاربر URL متفاوتی را دوباره در نوار آدرس قرار دهد چه اتفاقی می‌افتد؟ خوب، فرآیند مرورگر مراحل مشابهی را طی می کند تا به سایت های مختلف بروید. اما قبل از اینکه بتواند این کار را انجام دهد، باید با سایت رندر فعلی بررسی کند که آیا به رویداد beforeunload اهمیت می دهد یا خیر.

beforeunload می توانید "این سایت را ترک کنید؟" هنگامی که می خواهید برگه را ببندید یا از آن خارج شوید، هشدار دهید. همه چیز در داخل یک برگه از جمله کد جاوا اسکریپت شما توسط فرآیند رندر کنترل می شود، بنابراین فرآیند مرورگر باید با فرآیند رندر فعلی بررسی شود که درخواست ناوبری جدید وارد شود.

اگر پیمایش از فرآیند رندر آغاز شده باشد (مانند کاربر روی پیوند کلیک کرده یا جاوا اسکریپت سمت کلاینت window.location = "https://newsite.com" را اجرا کرده است)، فرآیند رندر ابتدا beforeunload کنترل کننده ها را بررسی می کند. سپس، همان فرآیندی را طی می کند که ناوبری آغاز شده با فرآیند مرورگر انجام می شود. تنها تفاوت این است که درخواست ناوبری از فرآیند رندر به فرآیند مرورگر آغاز می شود.

هنگامی که پیمایش جدید به سایتی متفاوت از سایتی که در حال حاضر رندر شده است انجام می شود، یک فرآیند رندر جداگانه برای مدیریت پیمایش جدید فراخوانی می شود در حالی که فرآیند رندر فعلی برای مدیریت رویدادهایی مانند unload نگه داشته می شود. برای اطلاعات بیشتر، مروری بر وضعیت‌های چرخه عمر صفحه و نحوه اتصال به رویدادها با صفحه Lifecycle API را ببینید.

در مورد کارگر خدماتی

یکی از تغییرات اخیر در این فرآیند ناوبری، معرفی کارگر خدمات است. Service Worker راهی برای نوشتن پراکسی شبکه در کد برنامه شما است. به توسعه دهندگان وب اجازه می دهد تا کنترل بیشتری بر روی مواردی که به صورت محلی ذخیره کنند و چه زمانی داده های جدید را از شبکه دریافت کنند، داشته باشند. اگر Service Worker برای بارگیری صفحه از حافظه پنهان تنظیم شده باشد، نیازی به درخواست داده از شبکه نیست.

بخش مهمی که باید به خاطر بسپارید این است که سرویس‌کار کد جاوا اسکریپت است که در فرآیند رندر اجرا می‌شود. اما هنگامی که درخواست ناوبری وارد می شود، چگونه یک مرورگر می داند که سایت دارای یک سرویس دهنده است؟

هنگامی که یک کارگر خدماتی ثبت نام می شود، محدوده کارمند خدماتی به عنوان یک مرجع نگهداری می شود (شما می توانید در این مقاله چرخه عمر کارگر خدمات بیشتر در مورد محدوده مطالعه کنید). هنگامی که یک پیمایش اتفاق می افتد، رشته شبکه دامنه را در برابر محدوده های سرویس کار ثبت شده بررسی می کند، اگر یک سرویس دهنده برای آن URL ثبت شده باشد، رشته UI یک فرآیند رندر را برای اجرای کد Service Worker پیدا می کند. سرویس‌کار ممکن است داده‌ها را از حافظه پنهان بارگیری کند و نیاز به درخواست داده از شبکه را از بین ببرد، یا ممکن است منابع جدیدی از شبکه درخواست کند.

پیش بارگیری ناوبری

می‌توانید ببینید این رفت و برگشت بین فرآیند مرورگر و فرآیند ارائه‌دهنده می‌تواند منجر به تأخیر شود، اگر سرویس‌کار در نهایت تصمیم به درخواست داده از شبکه بگیرد. پیش بارگذاری ناوبری مکانیزمی است برای سرعت بخشیدن به این فرآیند با بارگیری منابع به موازات راه اندازی سرویس دهنده. این درخواست ها را با یک هدر مشخص می کند و به سرورها اجازه می دهد که تصمیم بگیرند محتوای متفاوتی برای این درخواست ها ارسال کنند. به عنوان مثال، به جای یک سند کامل، فقط داده ها را به روز کرد.

بسته شدن

در این پست، به آنچه در حین پیمایش اتفاق می‌افتد و نحوه تعامل کد برنامه وب شما مانند هدرهای پاسخ و جاوا اسکریپت سمت کلاینت با مرورگر نگاه کردیم. دانستن مراحلی که مرورگر برای دریافت داده از شبکه طی می کند، درک اینکه چرا API هایی مانند پیش بارگذاری ناوبری ایجاد شده اند را آسان تر می کند. در پست بعدی به بررسی نحوه ارزیابی HTML/CSS/JavaScript ما توسط مرورگر برای رندر صفحات خواهیم پرداخت.

آیا از پست لذت بردید؟ اگر سؤال یا پیشنهادی برای پست آینده دارید، مایلم در بخش نظرات زیر یا @kosamari در توییتر از شما بشنوم.

بعدی: عملکرد درونی یک فرآیند رندر