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