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 để các yêu cầu trong tương lai về 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 truyền dữ liệu đến và đi 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 cùng một phép tính.

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, 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 được lưu vào bộ nhớ đệm.)

Ví dụ sau đây 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 vào một trang (https://a.example) yêu cầu một 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á.

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). 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, sử dụng URL hình ảnh làm khoá. Trình duyệt tìm thấy một 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.

Việc hình ảnh được tải từ bên trong iframe hay không không quan trọng. Nếu người dùng truy cập vào một trang web khác (https://c.example) có 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 giống nhau trên tất cả các trang.

Cơ chế này đã hoạt động hiệu quả từ lâu về hiệu suất. Tuy nhiên, thời gian mà 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 đã truy cập vào cùng một tài nguyên trước đây, khiến trình duyệt dễ bị tấn công về bảo mật và quyền riêng tư, chẳng hạn 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: Kẻ thù có thể phát hiện danh sách 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: Một đối thủ có thể phát hiện xem một chuỗi tuỳ ý có nằm 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ể 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.

Việc 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 được lưu vào bộ nhớ đệm sẽ được khoá bằng "Khoá phân tách 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 để xem 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 vào một trang (https://a.example) yêu cầu một 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à lưu vào bộ nhớ đệm bằng cách sử dụng một bộ dữ liệu 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 là 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 sẽ giống nhau.)

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 hình ảnh này sẽ không được lưu vào 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 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 trong một iframe. Trong trường hợp này, khoá là một bộ chứa 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. (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 bằng 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 một iframe từ https://c.example.

Trong trường hợp này, hình ảnh đượ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 vào https://subdomain.a.example, trang này 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 "scheme://eTLD+1", nên 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.

Điều gì sẽ xảy ra nếu iframe được lồng nhiều lần? Người dùng truy cập vào https://a.example, trang này nhúng một iframe (https://b.example), nhúng một iframe khác (https://c.example) và cuối cùng yêu cầu hình ảnh.

Vì khoá được lấy từ khung trên cùng (https://a.example) và khung tải tài nguyên ngay lập tức (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?

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

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.
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 theo sau là 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ì thuộc tính này sẽ không được bật.

Làm cách nào để kiểm thử tính năng phân vùng Bộ nhớ đệm HTTP trên Chrome?

Để kiểm thử 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 tại phần 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à một nhà phát triển web, tôi có cần làm gì để phản hồi sự thay đổi này không?

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

Ví dụ: những trang web 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ể 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ể sẽ ngày càng phụ thuộc vào các dịch vụ đó.

(Có một đề xuất để bật thư viện dùng chung theo cách bảo đảm quyền riêng tư có tên là Thư viện dùng chung trên web (video trình bày), nhưng đề xuất này vẫn đang được xem xét.)

Thay đổi về 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 (Lần sơn nội dung đầu tiên) là không đáng kể (~0,3%) và tỷ lệ tổng thể của các 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ề việc phân vùng bộ nhớ đệm HTTP.

Phương thức này có được chuẩn hoá không? Các trình duyệt khác có hoạt động khác không?

"Phân vùng bộ nhớ đệm HTTP" được tiêu chuẩn hoá trong thông số kỹ thuật 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 scheme://eTLD+1 và lược đồ khung scheme://eTLD+1
Safari: Sử dụng eTLD+1 cấp cao nhất
Firefox: Đang lên kế hoạch triển khai với giao thức cấp cao nhất://eTLD+1 và cân nhắc việc đưa vào một khoá thứ hai như Chrome

Hoạt động tìm nạp từ worker được xử lý như thế nào?

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