Nhìn chung, việc lưu vào bộ nhớ đệm có thể cải thiện hiệu suất bằng cách lưu trữ dữ liệu. Nhờ đó, các yêu cầu trong tương lai cho cùng một dữ liệu sẽ được phân phát nhanh hơn. Ví dụ: một tài nguyên đã lưu vào bộ nhớ đệm từ mạng có thể tránh được trường hợp truy cập trọn vòng đến máy chủ. Kết quả tính toán được lưu vào bộ nhớ đệm có thể bỏ qua thời gian thực hiện phép tính tương tự.
Trong Chrome, cơ chế bộ nhớ đệm được sử dụng theo nhiều cách và Bộ nhớ đệm HTTP là một ví dụ.
Cách hoạt động hiện tại của Bộ nhớ đệm HTTP của Chrome
Kể từ phiên bản 85, Chrome sẽ lưu các tài nguyên được tìm nạp từ mạng vào bộ nhớ đệm và sử dụng URL tài nguyên tương ứng làm khoá bộ nhớ đệm. (Khoá bộ nhớ đệm được dùng để xác định tài nguyên đã lưu vào bộ nhớ đệm.)
Ví dụ sau minh hoạ cách một hình ảnh được lưu vào bộ nhớ đệm và xử lý trong 3 bối cảnh khác nhau:
https://x.example/doge.png }
Một người dùng truy cập vào một trang (https://a.example) yêu cầu hình ảnh (https://x.example/doge.png). Hình ảnh này được yêu cầu từ mạng và lưu vào bộ nhớ đệm bằng cách sử dụng https://x.example/doge.png làm khoá.
https://x.example/doge.png }
Cùng một người dùng truy cập vào một trang khác (https://b.example) và yêu cầu cùng một hình ảnh (https://x.example/doge.png). Trình duyệt sẽ kiểm tra Bộ nhớ đệm HTTP để xem liệu tài nguyên này đã được lưu vào bộ nhớ đệm hay chưa bằng cách sử dụng URL hình ảnh làm khoá. Trình duyệt tìm thấy kết quả trùng khớp trong Bộ nhớ đệm nên sử dụng phiên bản tài nguyên đã lưu vào bộ nhớ đệm.
https://x.example/doge.png }
Hình ảnh được tải từ bên trong iframe là không cần thiết. Nếu người dùng truy cập vào một trang web khác (https://c.example) bằng iframe (https://d.example) và iframe đó yêu cầu cùng một hình ảnh (https://x.example/doge.png), thì trình duyệt vẫn có thể tải hình ảnh từ bộ nhớ đệm vì khoá bộ nhớ đệm là như nhau trên tất cả các trang.
Cơ chế này đã hoạt động tốt từ góc độ hiệu suất trong một thời gian dài. Tuy nhiên, thời gian một trang web cần để phản hồi các yêu cầu HTTP có thể cho biết rằng trình duyệt từng truy cập vào cùng một tài nguyên. Việc này sẽ khiến trình duyệt gặp phải các cuộc tấn công bảo mật và quyền riêng tư như sau:
- Phát hiện xem người dùng đã truy cập vào một trang web cụ thể hay chưa: Đối thủ có thể phát hiện nhật ký duyệt web của người dùng bằng cách kiểm tra xem bộ nhớ đệm có tài nguyên dành riêng cho một trang web hoặc nhóm trang web cụ thể hay không.
- Tấn công tìm kiếm trên nhiều trang web: Đối thủ cạnh tranh có thể phát hiện xem một chuỗi tuỳ ý có trong kết quả tìm kiếm của người dùng hay không bằng cách kiểm tra xem hình ảnh "không có kết quả tìm kiếm nào" mà một trang web cụ thể sử dụng có nằm trong bộ nhớ đệm của trình duyệt hay không.
- Theo dõi trên nhiều trang web: Bạn có thể sử dụng bộ nhớ đệm để lưu trữ giá trị nhận dạng giống cookie, dưới dạng cơ chế theo dõi trên nhiều trang web.
Để giảm thiểu những rủi ro này, Chrome sẽ phân vùng bộ nhớ đệm HTTP kể từ Chrome 86.
Tính năng phân vùng bộ nhớ đệm sẽ ảnh hưởng như thế nào đến bộ nhớ đệm HTTP của Chrome?
Với tính năng phân vùng bộ nhớ đệm, các tài nguyên đã lưu vào bộ nhớ đệm sẽ được khoá bằng "Khoá cách ly mạng" mới cùng với URL tài nguyên. Khoá cách ly mạng được kết hợp với trang web cấp cao nhất và trang web khung hiện tại.
Xem lại ví dụ trước để biết cách hoạt động của tính năng phân vùng bộ nhớ đệm trong các ngữ cảnh khác nhau:
https://a.example, https://a.example, https://x.example/doge.png }
Một người dùng truy cập một trang (https://a.example) yêu cầu hình ảnh (https://x.example/doge.png). Trong trường hợp này, hình ảnh được yêu cầu từ mạng và được lưu vào bộ nhớ đệm bằng một bộ dữ liệu bao gồm https://a.example (trang web cấp cao nhất), https://a.example (trang web trong khung hiện tại) và https://x.example/doge.png (URL tài nguyên) làm khoá. (Lưu ý rằng khi yêu cầu tài nguyên đến từ khung cấp cao nhất, trang web cấp cao nhất và trang web khung hiện tại trong Khoá cách ly mạng đều giống nhau.)
https://b.example, https://b.example, https://x.example/doge.png }
Cùng một người dùng truy cập vào một trang khác (https://b.example) yêu cầu cùng một hình ảnh (https://x.example/doge.png). Mặc dù cùng một hình ảnh được tải trong ví dụ trước, nhưng vì khoá không khớp, nên sẽ không phải là lượt truy cập vào bộ nhớ đệm.
Hình ảnh được yêu cầu từ mạng và được lưu vào bộ nhớ đệm bằng một bộ dữ liệu bao gồm https://b.example, https://b.example và https://x.example/doge.png làm khoá.
https://a.example, https://a.example, https://x.example/doge.png }
Bây giờ, người dùng quay lại https://a.example, nhưng lần này hình ảnh (https://x.example/doge.png) được nhúng trong một iframe. Trong trường hợp này, khoá là một bộ dữ liệu chứa https://a.example, https://a.example và https://x.example/doge.png và một lượt truy cập vào bộ nhớ đệm sẽ xảy ra. (Xin lưu ý rằng khi trang web cấp cao nhất và iframe là cùng một trang web, bạn có thể sử dụng tài nguyên được lưu vào bộ nhớ đệm với khung cấp cao nhất.
https://a.example, https://c.example, https://x.example/doge.png }
Người dùng quay lại https://a.example, nhưng lần này hình ảnh được lưu trữ trong iframe từ https://c.example.
Trong trường hợp này, hình ảnh sẽ được tải xuống từ mạng vì không có tài nguyên nào trong bộ nhớ đệm khớp với khoá gồm https://a.example, https://c.example và https://x.example/doge.png.
https://a.example, https://c.example, https://x.example/doge.png }
Nếu miền đó chứa miền con hoặc số cổng thì sao? Người dùng truy cập https://subdomain.a.example nhúng một iframe (https://c.example:8080) yêu cầu hình ảnh.
Vì khoá được tạo dựa trên "lược đồ://eTLD+1", nên các miền con và số cổng sẽ bị bỏ qua. Do đó, một lượt truy cập vào bộ nhớ đệm sẽ xảy ra.
https://a.example, https://c.example, https://x.example/doge.png }
Điều gì sẽ xảy ra nếu iframe được lồng nhiều lần? Người dùng truy cập https://a.example, nhúng một iframe (https://b.example) và một iframe khác (https://c.example) mà cuối cùng đã yêu cầu hình ảnh.
Vì khoá được lấy từ khung hình trên cùng (https://a.example) và khung hình tức thì tải tài nguyên (https://c.example), nên một lượt truy cập vào bộ nhớ đệm sẽ xảy ra.
Câu hỏi thường gặp
Tính năng này đã được bật trên Chrome chưa? Làm cách nào để kiểm tra?
Chúng tôi sẽ triển khai tính năng này đến cuối năm 2020. Cách kiểm tra xem phiên bản Chrome đã hỗ trợ hay chưa:
- Mở
chrome://net-export/rồi nhấn vào Start Logging to Disk (Bắt đầu ghi vào ổ đĩa). - Chỉ định nơi lưu tệp nhật ký trên máy tính của bạn.
- Duyệt web trên Chrome trong một phút.
- Quay lại
chrome://net-export/rồi nhấn vào Stop Logging (Dừng ghi nhật ký). - Chuyển đến
https://netlog-viewer.appspot.com/#import. - Nhấn vào Chọn tệp rồi chuyển tệp nhật ký bạn đã lưu.
Bạn sẽ thấy kết quả của tệp nhật ký.
Trên cùng một trang, hãy tìm SplitCacheByNetworkIsolationKey. Nếu đứng trước Experiment_[****], thì tính năng phân vùng bộ nhớ đệm HTTP sẽ được bật trên Chrome. Nếu theo sau là Control_[****] hoặc Default_[****], thì hàm này chưa được bật.
Làm thế nào để kiểm tra tính năng phân vùng bộ nhớ đệm HTTP trên Chrome?
Để kiểm tra tính năng phân vùng bộ nhớ đệm HTTP trên Chrome, bạn cần chạy Chrome bằng cờ dòng lệnh: --enable-features=SplitCacheByNetworkIsolationKey. Làm theo hướng dẫn trong bài viết Chạy Chromium bằng cờ để tìm hiểu cách chạy Chrome bằng cờ dòng lệnh trên nền tảng của bạn.
Là nhà phát triển web, tôi có nên làm gì để đáp ứng sự thay đổi này không?
Đây không phải là một thay đổi có thể gây lỗi, nhưng nó có thể khiến một số dịch vụ web phải cân nhắc về hiệu suất.
Ví dụ: những phân phát một lượng lớn tài nguyên có thể lưu vào bộ nhớ đệm trên nhiều trang web (chẳng hạn như phông chữ và tập lệnh phổ biến) có thể nhận thấy lưu lượng truy cập tăng lên. Ngoài ra, những người sử dụng các dịch vụ như vậy có thể phụ thuộc nhiều hơn vào các dịch vụ đó.
(Có một đề xuất về việc bật các thư viện dùng chung theo cách bảo đảm quyền riêng tư có tên là Thư viện chia sẻ trên web (video trình bày), nhưng đề xuất đó vẫn đang được xem xét.)
Sự thay đổi này về hành vi có tác động gì?
Tỷ lệ bỏ lỡ bộ nhớ đệm tổng thể tăng khoảng 3,6%, các thay đổi đối với FCP (Hiển thị nội dung đầu tiên) rất khiêm tốn (~0,3%) và tổng tỷ lệ byte được tải từ mạng tăng khoảng 4%. Bạn có thể tìm hiểu thêm về tác động đến hiệu suất trong nội dung giải thích về phân vùng bộ nhớ đệm HTTP.
Sự kiện này có được chuẩn hoá không? Các trình duyệt khác có hoạt động khác đi không?
"Phân vùng bộ nhớ đệm HTTP" được tiêu chuẩn hoá trong thông số tìm nạp mặc dù các trình duyệt hoạt động theo cách khác nhau:
- Chrome: Sử dụng lược đồ cấp cao nhất://eTLD+1 và lược đồ khung liên kết://eTLD+1
- Safari: Sử dụng eTLD+1 cấp cao nhất
- Firefox: Lên kế hoạch triển khai với schema://eTLD+1 cấp cao nhất và cân nhắc việc thêm khoá thứ hai như Chrome
Hoạt động tìm nạp từ trình thực thi được xử lý như thế nào?
Trình thực thi chuyên dụng sử dụng cùng một khoá với khung hiện tại. Trình chạy dịch vụ và trình chạy dùng chung phức tạp hơn vì chúng có thể được dùng chung giữa nhiều trang web cấp cao nhất. Giải pháp cho các vấn đề này hiện đang được thảo luận.