Điều gì xảy ra trong quá trình đi theo chỉ dẫn
Đây là phần 2 của loạt blog gồm 4 phần về cách hoạt động bên trong Chrome. Trong bài đăng trước, chúng ta đã xem cách các quy trình và luồng xử lý các phần khác nhau của trình duyệt. Trong bài đăng này, chúng tôi đi sâu hơn vào cách mỗi quy trình và luồng giao tiếp với nhau để hiển thị một trang web.
Hãy xem xét một trường hợp sử dụng đơn giản của việc duyệt web: bạn nhập một URL vào trình duyệt, sau đó, trình duyệt sẽ tìm nạp dữ liệu từ Internet và hiển thị một trang. Trong bài đăng này, chúng ta sẽ tập trung vào phần mà người dùng yêu cầu một trang web và trình duyệt chuẩn bị hiển thị một trang – còn được gọi là điều hướng.
Hành trình này bắt đầu từ quá trình xử lý trình duyệt
Như chúng ta đã đề cập trong phần 1: CPU, GPU, Bộ nhớ và kiến trúc đa tiến trình, mọi thứ bên ngoài thẻ đều được quy trình của trình duyệt xử lý. Quy trình trình duyệt có các luồng như luồng giao diện người dùng vẽ các nút và trường nhập của trình duyệt, luồng mạng xử lý ngăn xếp mạng để nhận dữ liệu từ Internet, luồng lưu trữ kiểm soát quyền truy cập vào tệp và nhiều luồng khác. Khi bạn nhập URL vào thanh địa chỉ, hoạt động nhập của bạn sẽ được luồng giao diện người dùng của quy trình trình duyệt xử lý.
Cách thao tác đơn giản
Bước 1: Xử lý thông tin đầu vào
Khi người dùng bắt đầu nhập vào thanh địa chỉ, điều đầu tiên luồng giao diện người dùng hỏi là "Đây là truy vấn tìm kiếm hay URL?". Trong Chrome, thanh địa chỉ cũng là trường nhập dữ liệu tìm kiếm. Do đó, luồng giao diện người dùng cần phân tích cú pháp và quyết định đưa bạn đến công cụ tìm kiếm hay trang web mà bạn yêu cầu.
Bước 2: Bắt đầu đi theo chỉ dẫn
Khi người dùng nhấn Enter, luồng giao diện người dùng sẽ bắt đầu lệnh gọi mạng để nhận nội dung trang web. Vòng quay tải hiển thị ở góc của thẻ và luồng mạng sẽ trải qua các giao thức thích hợp như tra cứu DNS và thiết lập Kết nối TLS cho yêu cầu.
Tại thời điểm này, luồng mạng có thể nhận được tiêu đề chuyển hướng máy chủ như HTTP 301. Trong trường hợp đó, luồng mạng giao tiếp với luồng giao diện người dùng mà máy chủ đang yêu cầu chuyển hướng. Sau đó, một yêu cầu URL khác sẽ được bắt đầu.
Bước 3: Đọc câu trả lời
Sau khi nội dung phản hồi (trọng tải) bắt đầu xuất hiện, luồng mạng sẽ xem xét một vài byte đầu tiên của luồng nếu cần. Tiêu đề Loại nội dung của phản hồi phải cho biết đó là loại dữ liệu nào, nhưng vì tiêu đề này có thể bị thiếu hoặc sai nên quy trình nhận dạng loại MIME được thực hiện ở đây. Đây là một "doanh nghiệp lừa đảo" như đã nhận xét trong mã nguồn. Bạn có thể đọc nhận xét này để xem cách các trình duyệt khác nhau xử lý các cặp loại nội dung/trọng tải.
Nếu phản hồi là tệp HTML, thì bước tiếp theo sẽ là chuyển dữ liệu đến quy trình kết xuất. Tuy nhiên, nếu đó là tệp zip hoặc tệp khác thì đó có nghĩa là đó là một yêu cầu tải xuống, vì vậy, chúng cần chuyển dữ liệu đến trình quản lý tải xuống.
Đây cũng là nơi quy trình kiểm tra SafeBrowsing sẽ diễn ra. Nếu miền và dữ liệu phản hồi có vẻ khớp với một trang web độc hại đã biết, thì chuỗi mạng sẽ hiển thị trang cảnh báo. Ngoài ra, quy trình kiểm tra Cross Origin Read B (CORB) diễn ra để đảm bảo rằng dữ liệu nhạy cảm trên nhiều trang web không được đưa vào quá trình kết xuất.
Bước 4: Tìm quy trình kết xuất đồ hoạ
Sau khi tất cả các bước kiểm tra đã hoàn tất và Luồng mạng chắc chắn rằng trình duyệt sẽ điều hướng đến trang web được yêu cầu, Luồng mạng cho luồng giao diện người dùng biết rằng dữ liệu đã sẵn sàng. Sau đó, luồng giao diện người dùng tìm thấy một quy trình kết xuất để tiếp tục kết xuất trang web.
Vì có thể mất vài trăm mili giây để nhận lại phản hồi, yêu cầu mạng sẽ được áp dụng một tính năng tối ưu hoá để tăng tốc quá trình này. Khi luồng giao diện người dùng gửi yêu cầu URL đến luồng mạng ở bước 2, luồng này đã biết họ đang điều hướng đến trang web nào. Luồng giao diện người dùng cố gắng chủ động tìm hoặc bắt đầu quá trình kết xuất song song với yêu cầu mạng. Bằng cách này, nếu mọi thứ diễn ra như dự kiến, quy trình kết xuất đồ hoạ sẽ ở vị trí chờ khi luồng mạng nhận được dữ liệu. Quy trình chờ này có thể không được sử dụng nếu chế độ điều hướng chuyển hướng trên nhiều trang web. Trong trường hợp này, bạn có thể cần đến một quy trình khác.
Bước 5: Điều hướng xác nhận
Giờ đây, khi dữ liệu và quy trình kết xuất đồ hoạ đã sẵn sàng, một IPC sẽ được gửi từ quy trình của trình duyệt đến quy trình kết xuất để xác nhận điều hướng. Lớp này cũng truyền luồng dữ liệu để quy trình kết xuất có thể tiếp tục nhận dữ liệu HTML. Sau khi quy trình trình duyệt nghe xác nhận rằng cam kết đã xảy ra trong quá trình kết xuất, quá trình điều hướng sẽ hoàn tất và giai đoạn tải tài liệu sẽ bắt đầu.
Tại thời điểm này, thanh địa chỉ đã được cập nhật và chỉ báo bảo mật cũng như giao diện người dùng cài đặt trang web phản ánh thông tin trang web của trang mới. Nhật ký phiên hoạt động cho thẻ này sẽ được cập nhật để các nút tiến/lùi sẽ bước qua trang web vừa được chuyển đến. Để tạo điều kiện khôi phục thẻ/phiên khi bạn đóng một thẻ hoặc cửa sổ, nhật ký phiên sẽ được lưu trữ trên ổ đĩa.
Bước bổ sung: Hoàn tất tải ban đầu
Sau khi bạn xác nhận điều hướng, quy trình kết xuất đồ hoạ sẽ tiếp tục tải tài nguyên và kết xuất trang. Chúng ta sẽ tìm hiểu chi tiết về những gì sẽ xảy ra ở giai đoạn này trong bài đăng tiếp theo. Sau khi quá trình kết xuất "hoàn tất" quá trình kết xuất, trình kết xuất sẽ gửi một IPC trở lại quy trình của trình duyệt (việc này là sau khi tất cả các sự kiện onload đã kích hoạt trên tất cả các khung trong trang và đã thực thi xong). Tại thời điểm này, luồng giao diện người dùng sẽ dừng vòng quay đang tải trên thẻ.
Tôi nói "finishes" (hoàn tất), vì JavaScript phía máy khách vẫn có thể tải tài nguyên bổ sung và hiển thị khung hiển thị mới sau thời điểm này.
Điều hướng đến một trang web khác
Đã hoàn tất thao tác điều hướng đơn giản! Nhưng điều gì sẽ xảy ra nếu người dùng đặt lại URL khác vào
thanh địa chỉ? Quá trình của trình duyệt sẽ trải qua các bước tương tự để điều hướng đến trang web khác.
Tuy nhiên, để có thể làm việc đó, Analytics cần kiểm tra với trang web đang hiển thị xem họ có quan tâm đến sự kiện beforeunload hay không.
beforeunload có thể tạo thông báo "Rời khỏi trang web này?" khi bạn cố gắng rời đi hoặc đóng thẻ.
Quy trình kết xuất sẽ xử lý mọi nội dung trong một thẻ, bao gồm cả mã JavaScript. Vì vậy, quy trình của trình duyệt phải kiểm tra quy trình kết xuất hiện tại khi có yêu cầu điều hướng mới.
Nếu điều hướng được bắt đầu từ quá trình kết xuất (như người dùng nhấp vào một đường liên kết hoặc JavaScript phía máy khách đã chạy window.location = "https://newsite.com"), thì trước tiên, quy trình kết xuất sẽ kiểm tra các trình xử lý beforeunload. Sau đó, trình duyệt này sẽ trải qua chính quy trình giống như quá trình điều hướng của trình duyệt. Điểm khác biệt duy nhất là yêu cầu điều hướng được khởi động từ quy trình kết xuất sang quy trình của trình duyệt.
Khi thao tác điều hướng mới được thực hiện trên một trang web khác với trang web hiện đang kết xuất, một quy trình kết xuất riêng sẽ được gọi để xử lý thao tác điều hướng mới, còn quy trình kết xuất hiện tại sẽ được giữ lại để xử lý các sự kiện như unload. Để biết thêm, hãy xem tổng quan về các trạng thái vòng đời của trang và cách bạn có thể dựa vào các sự kiện bằng API Vòng đời trang.
Trường hợp Service Worker
Một thay đổi gần đây đối với quy trình di chuyển này là giới thiệu về service worker. Trình chạy dịch vụ là một cách để ghi proxy mạng vào mã xử lý ứng dụng của bạn; cho phép các nhà phát triển web có nhiều quyền kiểm soát hơn đối với dữ liệu cần lưu vào bộ nhớ đệm trên máy và thời điểm nhận dữ liệu mới từ mạng. Nếu trình chạy dịch vụ được thiết lập để tải trang từ bộ nhớ đệm, thì bạn không cần yêu cầu dữ liệu từ mạng.
Điều quan trọng cần nhớ là trình chạy dịch vụ là mã JavaScript chạy trong quy trình kết xuất đồ hoạ. Nhưng khi có yêu cầu điều hướng, làm cách nào để quy trình của trình duyệt biết trang web có trình chạy dịch vụ?
Khi một trình chạy dịch vụ được đăng ký, phạm vi của trình chạy dịch vụ sẽ được giữ lại để tham khảo (bạn có thể đọc thêm về phạm vi này trong bài viết Vòng đời của trình chạy dịch vụ này). Khi điều hướng xảy ra, luồng mạng sẽ kiểm tra miền với các phạm vi của trình chạy dịch vụ đã đăng ký, nếu một trình chạy dịch vụ được đăng ký cho URL đó, thì luồng giao diện người dùng sẽ tìm thấy một quy trình kết xuất đồ hoạ để thực thi mã của trình chạy dịch vụ. Trình chạy dịch vụ có thể tải dữ liệu từ bộ nhớ đệm, giúp bạn không cần yêu cầu dữ liệu từ mạng hoặc có thể yêu cầu tài nguyên mới từ mạng.
Tải trước điều hướng
Bạn có thể thấy quá trình xử lý vòng đời này giữa tiến trình trình duyệt và quy trình kết xuất đồ hoạ có thể dẫn đến sự chậm trễ nếu trình chạy dịch vụ quyết định yêu cầu dữ liệu từ mạng. Tải trước điều hướng là một cơ chế giúp tăng tốc quá trình này bằng cách tải tài nguyên song song với quá trình khởi động trình chạy dịch vụ. API này đánh dấu các yêu cầu này bằng một tiêu đề, cho phép các máy chủ quyết định gửi nội dung khác cho các yêu cầu này; ví dụ: chỉ dữ liệu được cập nhật thay vì một tài liệu đầy đủ.
Tóm tắt
Trong bài đăng này, chúng tôi đã xem xét những gì xảy ra trong quá trình điều hướng và cách mã ứng dụng web của bạn, chẳng hạn như tiêu đề phản hồi và JavaScript phía máy khách tương tác với trình duyệt. Khi biết các bước mà trình duyệt phải trải qua để nhận dữ liệu từ mạng, bạn sẽ dễ dàng hiểu được lý do tại sao các API như tải trước tính năng điều hướng lại được phát triển. Trong bài đăng tiếp theo, chúng ta sẽ đi sâu vào cách trình duyệt đánh giá HTML/CSS/JavaScript để hiển thị các trang.
Bạn có thích bài đăng này không? Nếu bạn có bất kỳ câu hỏi hoặc đề xuất nào cho bài đăng trong tương lai, tôi muốn lắng nghe ý kiến của bạn trong phần bình luận bên dưới hoặc @kosamari trên Twitter.