Trang này được dịch bởi Cloud Translation API.

Tăng cường tính bảo mật và quyền riêng tư bằng cách phân vùng bộ nhớ đệm

Eiji Kitamura

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 sau này đối với cùng một dữ liệu được phân phát nhanh hơn. Ví dụ: tài nguyên được lưu vào bộ nhớ đệm từ mạng có thể tránh được việc phải trả về 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 tìm nạp từ mạng vào bộ nhớ đệm và dùng các URL tài nguyên tương ứng làm khoá bộ nhớ đệm. (Khoá bộ nhớ đệm dùng để xác định tài nguyên được 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 ba ngữ cảnh khác nhau:

Khoá bộ nhớ đệm: https://x.example/doge.png — **Khoá bộ nhớ đệm**: { `https://x.example/doge.png` }

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). Hình ảnh được yêu cầu từ mạng và được lưu vào bộ nhớ đệm bằng cách sử dụng https://x.example/doge.png làm khoá.

Người dùng này truy cập một trang khác (https://b.example). Trang này yêu cầu cùng một hình ảnh (https://x.example/doge.png). Trình duyệt kiểm tra Bộ nhớ đệm HTTP để xem liệu đã lưu tài nguyên này vào bộ nhớ đệm hay chưa, sử dụng URL hình ảnh làm khoá. Trình duyệt sẽ tìm thấy kết quả trùng khớp trong Bộ nhớ đệm, vì vậy, trình duyệt sẽ sử dụng phiên bản tài nguyên được lưu vào bộ nhớ đệm.

Không quan trọng nếu hình ảnh được tải từ bên trong iframe. 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), trình duyệt vẫn có thể tải hình ảnh từ bộ nhớ đệm vì khoá bộ nhớ đệm giống nhau trên tất cả các trang.

Cơ chế này đã hoạt động tốt từ khía cạnh 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 thấy rằng trình duyệt đã truy cập vào cùng một tài nguyên trước đây, điều này khiến trình duyệt gặp phải các cuộc tấn công bảo mật và bảo vệ quyền riêng tư, chẳng hạn như:

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 thuần tập trang web cụ thể hay không.
Tấn công tìm kiếm trên nhiều trang web: Đối thủ 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" 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ữ các 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 một "Khoá tách biệt mạng" mới ngoài URL tài nguyên. Khoá cách ly mạng bao gồm trang web cấp cao nhất và trang web khung hiện tại.

Hãy 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:

Khoá bộ nhớ đệm { https://a.example, https://a.example, https://x.example/doge.png} — **Khoá bộ nhớ đệm**: { `https://a.example`, `https://a.example`, `https://x.example/doge.png` }

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 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 hình 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 sẽ giống nhau.)

Cùng một người dùng truy cập 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, vì khoá không khớp nên sẽ không phải là lượt truy cập bộ nhớ đệm.

Hình ảnh được yêu cầu từ mạng và lưu vào bộ nhớ đệm bằng cách sử dụ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á.

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 vào 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 trong khung cấp cao nhất.

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á bao gồm https://a.example, https://c.example và 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, qua đó nhúng iframe (https://c.example:8080) để yêu cầu hình ảnh.

Vì khoá được tạo dựa trên "giaothuc://eTLD+1", nên các miền con và số cổng sẽ bị bỏ qua. Do đó, xảy ra lượt truy cập bộ nhớ đệm.

Đ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), qua đó nhúng một iframe khác (https://c.example), mà cuối cùng sẽ yêu cầu hình ảnh.

Do khoá được lấy từ khung hình cao nhất (https://a.example) và khung ngay lập tức 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 của tôi chưa? Làm cách nào để kiểm tra?

Chúng tôi sẽ ra mắt tính năng này đến cuối năm 2020. Cách kiểm tra xem phiên bản Chrome của bạn đã hỗ trợ tính năng này hay chưa:

Mở chrome://net-export/ rồi nhấn vào Start Logging to Disk (Bắt đầu ghi nhật ký vào ổ đĩa).
Chỉ định vị trí 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ý).
Đi đến https://netlog-viewer.appspot.com/#import.
Nhấn 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 trang đó, hãy tìm SplitCacheByNetworkIsolationKey. Nếu đứng sau Experiment_[****], thì tính năng phân vùng bộ nhớ đệm HTTP sẽ được bật trên Chrome của bạn. Nếu theo sau là Control_[****] hoặc Default_[****], thì thuộc tính này sẽ không được bật.

Làm cách nào để kiểm tra 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 một cờ dòng lệnh: --enable-features=SplitCacheByNetworkIsolationKey. Làm theo hướng dẫn trong bài viết Chạy Chromium với 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ì để phản hồi thay đổi này không?

Đây không phải là một thay đổi có thể gây lỗi, nhưng có thể khiến một số dịch vụ web phải cân nhắc đến hiệu suất.

Ví dụ: những trang phân phát lượng lớn tài nguyên có thể lưu vào bộ nhớ đệm với mức độ cao 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ụ đó có thể phụ thuộc nhiều hơn vào các dịch vụ đó.

(Có một đề xuất hỗ trợ các thư viện dùng chung theo cách bảo đảm quyền riêng tư gọi là Thư viện chia sẻ trên web (video trình bày). Tuy nhiên, chúng tôi vẫn đang xem xét đề xuất này.)

Thay đổi hành vi này 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 (Nội dung đầu tiên hiển thị) là không đáng kể (~0,3%) và tỷ lệ tổng số byte được tải qua mạng tăng khoảng 4%. Bạn có thể tìm hiểu thêm về tác động đối với hiệu suất trong tài liệu giải thích về phân vùng bộ nhớ đệm HTTP.

Số liệu này có được chuẩn hoá không? Các trình duyệt khác có hoạt động theo cách khác không?

"Phân vùng bộ nhớ đệm HTTP" được chuẩn hoá trong quy cách 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://eTLD+1
Safari: Sử dụng eTLD+1 cấp cao nhất
Firefox: Lập kế hoạch triển khai với schema://eTLD+1 cấp cao nhất và cân nhắc việc đưa khoá thứ hai vào như Chrome

Cách tìm nạp từ worker được xử lý?

Các nhân viên chuyên trách sử dụng cùng một khoá với khung hiện tại của họ. Trình chạy dịch vụ và worker dùng chung phức tạp hơn vì chúng có thể được chia sẻ giữa nhiều trang web cấp cao nhất. Giải pháp cho những người này hiện đang được thảo luận.