Tất cả về CACHING (Được dịch từ cuốn sách: http_the_definitive_guide)

Người dịch: Nguyễn Trường Hận
Tài liệu được dịch từ cuốn sách: http_the_definitive_guide

Chương 7:

CACHING

Bộ nhớ cache trên web là những thiết bị HTTP tự động giữ những bản sao lưu của
các document phổ biến. Khi một web request đến một bộ nhớ cache, nếu một bản sao lưu
local được lưu trữ là hợp lệ, document được phục vụ từ kho lưu trữ cục bộ thay vì từ server
ban đầu.
Caches có những lợi ích như:
-

Làm giảm những data vận chuyển dư, tiết kiệm tiền của bạn trong việc chi trả cho
mạng.


Người dịch: Nguyễn Trường Hận
-

Làm giảm tắc nghẽn mạng. Page tải nhanh hơn mà không cần nhiều bandwdth hơn.

-

Làm giảm sự phụ thuộc vào server. Server trả lời nhanh hơn và tránh bị quá tải.

-

Làm giảm sự khoảng thời gian ngưng trệ (delay), bởi vì page tải chậm hơn từ xa hơn.
Trong chapter này, chúng ta giải thích cache cải thiện hiệu năng và làm giảm chi phí

như thế nào, đo độ hiệu quả của nó như thế nào và nơi nên đặt cache nhằm tối ưu hóa hoạt
động của nó. Chúng ta còn giải thích HTTP giữ các bản sao chép mới lưu trong cache như
thế nào và cache tương tác với những cache và server khác như thế nào?
7.1. Redundant Data Transfers (Vận chuyển dữ liệu dư)
Khi nhiều client truy cập tới một page trên server, server truyền cùng một document
nhiều lần, mỗi lần tới một client. Những byte giống nhau vận chuyển thông qua network
lặp đi lặp lại nhiều lần. Những lần chuyển đi lặp lại như vậy chiếm băng thông nhiều, khiến
quá trình chuyển dữ liệu chậm và quá tải cho web server. Với cache, cache giữ một bản
sao của những response đầu tiên từ server. Request tiếp theo có thể được hoàn thành từ
những bản copy được lưu trữ trước đó, làm giảm sự lãng phí, lưu lượng giống nhau từ cùng
một server.
7.2. Bandwidth Bottlenecks (Nghẽn băng thông)
Cache còn có thể làm giảm tắc nghẽn băng thông. Nhiều network cung cấp băng
thông nhiều hơn cho client local network để truy cập từ xa tới server. Client truy cập tới
server với tốc độ của đường mạng chậm nhất. Nếu một client lấy một bản sao từ cache trên
một mạng LAN nhanh, caching có thể đẩy tăng hiệu năng một cách đặc biệt cho lượng lớn
document.


Người dịch: Nguyễn Trường Hận

Trong hình 7-1, có thể mất đến 30 giây để một user ở San Francisco có thể tải về một
file 5MB từ Atlanta, với tốc độ đường truyển là 1,4Mb trên giây. Nếu document đã được
lưu ở cache ở San Francisco, một người dùng cục bộ có thể lấy document đã sao lưu đó
trong khoảng thời gian vài giây thông qua Ethernet connection chứ không phải là T1
Internet connection.
Bảng 7-1 chỉ ra băng thông có ảnh hường như thế nào đến thời gian truyền data với
một vài tốc độ network khác nhau và một vài kích thước document khác nhau. Băng thông
gây ra một sự chậm trễ đáng chú ý đối với document lớn và tốc độ khác nhau giữa các loại

network khác nhau đáng kể. Một modem có tốc độ 56KB trên giây có thể mất 749 giây để
vận chuyển một file 5MB, trong khi nếu file này được chuyển thông qua một fast Ethernet
LAN chỉ mất vài giây.


Người dịch: Nguyễn Trường Hận

7.3. Flash Crowds
Bộ nhớ đệm đặc biệt quan trọng trong việc chia nhỏ flash crowds. Flash crowds xảy
ra khi một sự kiện đột ngột gây ra nhiều người cùng truy cập tới một document trên web
tại cùng một thời điểm. Kết quả là lưu lượng truy cập giống nhau tăng đột biến có thể gây
ra sự sụp độ của server và network.

7.4. Distance Delays (Khoảng thời gian chậm trễ)
Ngay cả khi băng thông không có vấn đề nào, thì thời gian ngưng trệ cũng có thể
xảy ra. Mỗi router network đều làm chậm trễ lưu lượng internet. Và ngay cả khi không có
nhiều bộ định tuyến giữa client và server, thì sự chậm trễ vẫn có thể xảy ra.


Người dịch: Nguyễn Trường Hận
Khoảng cách trực tiếp từ Boston tới San Francisco khoảng 2700 miles. Trong trường hợp
tốt nhất, với tốc độ của ánh sáng (186.000 miles/sec), một tín hiệu có thể di chuyển từ
Boston tới San Francisco khoảng 15 mili giây và hoàn thành một chuyến đi về mất 30 mili
giây.
Nói một web page chưa 20 hình ảnh nhỏ, tất cả nằm trên một server ở San Francisco. Nếu
mộ tclient ở Boston mở 4 connection song song tới server và giữ connection sống, tốc độ
của ánh sáng đơn gây mất 1/4 giây cho việc download. Nếu server ở Tokyo (cách Boston
6.700 miles), thời gian delay tăng thêm 600mili giây. Các trang web khá phức tạp có thể
phải mất vài giây cho sự chậm trễ bởi tốc độ ánh sáng.

Đặt bộ nhớ cache ở gần phòng máy có thể rút ngắn khoảng cách mà document phải đi từ
ngàn dặm còn hàng chục yard (thước).


Người dịch: Nguyễn Trường Hận
7.5. Hits and Misses
Cache không thể lưu hết tất cả các bản sao của document.
Một vài request đến cache có thể được phục vụ từ một bản sao lưu hợp lệ. Điều này được
gọi là cache hit. Những request khác đến một cache chỉ được chuyển tới server bởi vì bản
sao lưu của tài nguyên mà nó request không hợp lệ, nó được gọi là một cache miss.

Revalidations
Bởi vì nội dung trên server có thể thay đổi, cache phải kiểm tra ngay và sau đó các bản sao
lưu xem liệu nó còn cập nhật với serer không. Những kiểm tra này được gọi là
Revalidations (kiểm tra lại). Để việc kiểm tra lại có hiệu quả, HTTP định nghĩa những
request đặc biệt có thể nhanh chóng kiểm tra nếu nội dung vẫn còn mới mà không tìm nạp
toàn bộ đối tượng từ server.
Một cache có thể kiểm tra lại một bản sao lưu bất cứ khi nào nó muốn và thường xuyên
như nó muốn. Nhưng bởi vì cache thường bao gồm hàng nghìn document và bởi vì băng
thông hạn hẹp, hầu hết các cache kiểm tra lại một bản sao lưu chỉ khi nó được request bởi


Người dịch: Nguyễn Trường Hận
một client và khi bản sao lưu đã đủ cũ để đảm bảo cần 1 sự kiểm tra. Chúng ta sẽ giải thích
HTTP rule cho việc kiểm tra lại trong chapter sau.
Khi một cache cần kiểm tra lại một bản sao lưu được lưu trong cache, nó gửi một request
kiểm tra lại nhỏ tới server. Nếu nội dung không thay đổi, server hồi đáp với một response
nhỏ status code là 304 Not Modified. Ngay khi cache biết được bản copy vẫn còn hợp lệ,
nó đánh dấu bản sao lưu tạm thời còn mới và phục vụ bản sao lưu đó gửi tới client. Điều
này được gọi là một revalidate hit hoặc slow hit. Nó chậm hơn cache thuần túy vì nó còn

phải kiểm tra với server, nhưng nhanh hơn một cache miss vì không một đối tượng dữ liệu
nào phải gửi lại từ server.

HTTP đưa ra cho chúng ta một vài công cụ để kiểm tra lại một đối tượng được lưu trong
cache, nhưng phổ biến nhất là If-Modified-Since header. Khi header này được thêm vào
một GET request, header này nói cho server rằng chỉ gửi đối tượng nếu lần sửa đổi cuối
cùng của nó xảy ra trước khi nó được sao lưu ở cache.
Những điều xảy ra khi một GET request kèm với header If-Modified-Since đến server có
3 trường hợp: Khi nội dung trên server không được sửa đổi, Khi nội dung trên server đã
được thay đổi và khi đối tượng trên server đã bị xóa.
Revalidate hit


Người dịch: Nguyễn Trường Hận
Nếu đối tượng trên server không được sửa đổi, server gửi tới client một response nhỏ với
status code là 304 Not Modified.

Revalidate miss
Nếu đối tượng trên server đã khác với bản được sao lưu trong cache, server gửi tới client
một response với status code 200 OK cùng với nội dung đầy đủ của đối tượng mà client
request.
Object đã bị xóa
Nếu đối tượng trên server đã bị xóa, server gửi lại cho client một response 404 NOT found
và cache xóa bản sao lưu của nó.
Hit Rate (Tỷ lê Hit)
Từng phần của request được phục vụ bởi cache được gọi là cache hit rate (hoặc cache hit
ratio) hoặc đôi khi gọi là document hit rate hoặc document hit ratio. Hit rate nằm trong
khoảng 0 đến 1 nhưng thường xuyên được mô tả như một tỷ lệ phần trăm, 0% có nghĩa là
mọi request đều là miss (phải lấy document trên network), và 100% có nghĩa là mọi request
đều là hit (đã lấy bản sao lưu document trên cahe).

Quản trị viên cache luôn muốn tỷ lệ cache hit là 100%. Thực tế hit rate mà bạn lấy được
dựa trên việc bộ nhớ cache lớn như thế nào. Giống như người dùng thích một bộ nhớ cahe
như thế nào, tần suất những dữ liệu trong cache được thay đổi và cá nhân hóa, và cách


Người dịch: Nguyễn Trường Hận
cache được cấu hình. Hit rate nổi tiếng là khó để dự đoán được, nhưng một hit rate 40%
thì tốt cho cache và các web server hiện nay.
Byte Hit Rate (Tỷ lệ byte hit)
Document hit rate không phải là tất cả, mặc dù bởi vì document không phải tất cả đều có
một kích thước. Một vài đối tượng có kích thước lớn có thể được truy cập ít thường xuyên
hơn nhưng đóng góp nhiều phần cho tổng lưu lượng dữ liệu bởi kích thước của chúng. Vì
lý do này, một vài người thích byte hit rate hơn (đặc biệt là những người phải trả tiền cho
từng byte của lưu lượng)
Byte hit rate biểu thị phần của tất cả những byte đã chuyển đi lấy từ cache. Giá trị này nắm
bắt mức độ truy cập của lưu lượng. Một byte hit rate là 100% có nghĩa mọi byte đều đến
từ cache và không có lưu lượng đi ra ngoài internet.
Document hit rate và byte hit rate đều hữu ích cho việc tính hiệu suất của cache. Document
hit rate mô tả có bao nhiêu giao dịch web được lưu trữ ngoài network. Bởi vì những giao
dịch có một thành phần thời gian cố định có thể thường xuyên lớn (ví dụ cài đặt một TCP
connection tới một server). Nâng cao document hit rate sẽ tối ưu hóa tổng thời gian bị
delay. Byte hit rate mô tả bao nhiều byte được giữ ngoài internet. Nâng cao byte hit rate sẽ
tối ưu hóa việc tiết kiệm băng thông.
Distinguishing Hits and Misses (Phân biệt Hit và Miss)
Không may, HTTP không cung cấp cách để một client nói nếu một response là một
cache hit hay một truy cập vào server. Trong cả 2 trường hợp, response code chỉ là 200 OK
chỉ ra rằng response có một body. Một vài bộ nhớ cache proxy bản thương mại đính kèm
thông tin đến Via header để mô tả những gì đã diễn ra trong cache.
Một cách mà client có thể thường xuyên phát hiện nếu một response đến từ một cache
là dùng header Date. Bằng cách so sánh giá trị của header Date trong response với thời

gian hiện tại, một client có thể thường xuyên phát hiện response bởi giá trị date cũ hơn của
nó. Cách khác để một client có thể phát hiện một cache reponse là sử dụng header Age,
header này nói cho client biết tuổi của response (response đã được tạo ra bao lâu rồi).


Người dịch: Nguyễn Trường Hận
7.6. Cache Topologies
Cacche có thể được chuyên dụng cho một single uer hoặc được chia sẻ giữa hàng
ngàn user. Cache chuyên dụng được gọi là bộ nhớ riêng. Bộ nhớ cache riêng là bộ nhớ
cache cá nhân, bao gồm những page thông dụng cho người dùng đơn. Bộ nhớ cache được
chia sẻ gọi là bộ nhớ cache công khai, bao gồm những page thông dụng trong cộng động
người dùng.

Private caches
Private cache không cần nhiều không gian lưu trữ, vì vậy chúng có thể được tạo ra
nhỏ và rẻ. Trình duyệt web có cache riêng được xây dựng chứa những document thông
dụng nhất được tìm kiếm trong đĩa và bộ nhớ của máy tính cá nhân và cho phép bạn có thể
cấu hình kích thước và cài đặt bộ nhớ cache.
Public Proxy caches
Public cache là các proxy server được chia sẻ đặc biệt gọi là caching proxy server
hoặc proxy caches. Proxy cache phục vụ document từ local cache hoặc kết nối tới server
đại diện cho user. Bởi vì một public cache nhận truy cập từ nhiều người dùng, nó có nhiều
khả năng để loại bỏ lưu lượng truy cập dư.


Người dịch: Nguyễn Trường Hận
Trong hình 7-8, mỗi client đều tạo truy cập mới tới một document “hot” (document
này vẫn chưa chứa trong private cache) Mỗi private cache tìm nạp những document giống
nhau thông qua internet trong cùng một thời điểm. Với một cache public như hình 7-8b,
cache cần tìm nạp đối tượng đó chỉ 1 lần và nó sử dụng những bản sao lưu của đối tượng

đó để chia sẻ tới tất của request của client, làm giảm lưu lượng lưu thông.
Proxy cache tuân thủ theo luật của proxy được mô tả trong chapter 6. Bạn có thể cấu
hình trình duyệt của bạn sử dụng proxy cache bằng tay hoặc cấu hình một proxy bằng file
cấu hình tự động. Bạn còn có thể buộc các request HTTP, thông qua cache mà không cấu
hình trình duyệt của bạn bởi sử dụng chặn proxy.
Proxy Cache Hierarchies (Phân cấp Proxy cache)
Trong thực tế, nó thường có nghĩa triển khai phân cấp cache, nơi mà cache ẩn ở trong
cache nhỏ hơn được chuyển sang cache gốc lớn hơn, dịch vụ lưu lượng còn lại “cất”. Trong
hình 7-9 chỉ ra rằng một cache phân 2 cấp. Ý tưởng là sử dụng những cache nhỏ, rẻ ở gần
client và dần dần lớn hơn, mạnh mẽ hơn lưu trữ hệ thống phân cấp để giữ tài liệu được chia
sẻ bởi nhiều người hơn.
Hầu hết user sẽ lấy cache hit ở gần hơn, level-1 cache. Nếu không cache lớn hơn có
thể xử lí những request của client.


Người dịch: Nguyễn Trường Hận

Cache Meshes, Content Routing, and Peering
Một vài kiến trúc network được xây dựng mạng lưới bộ nhớ cache phức tạp (Cache
Meshes) thay vì bộ nhớ cache phân cấp đơn giản. Proxy cache trong mạng lưới cache nói
chuyện với nhau theo nhiều cách tinh vi hơn, và tạo những quyết định truyền thông cache
động, quyết định mà cache cha lớn hơn thực hiện hoặc quyết định đi thông qua toàn bộ các
cache và tới trực tiếp server. Proxy cache như vậy có thể được mô tả là bộ định tuyến nội
dung, bởi vì chúng tạo những quyết định định tuyến về cách truy cập, quản lí và chuyển
giao nội dung.
Cache được thiết kế để định tuyến nội dung trong mạng lưới cache có thể thực hiện
tất cả mọi việc dưới đây:
-

Chọn giữa một cache cha hoặc server một cách tự động, dựa trên URL

-

Chọn một cache cụ thể một cách tự động, dựa trên URL


Người dịch: Nguyễn Trường Hận
-

Tìm kiếm cache trong khu vực mạng nội bộ một bản sao lưu trước khi đi tới cache
cha.

-

Cho phép những cache khác truy cập tới một phần nội dung cache của nó, nhưng
không cho phép Internet chuyển tiếp thông qua cache của nó.
Có nhiều những mối quan hệ phức tạp giữa cache cho phép tổ chức khác nhau ngang

hàng với nhau, kết nối những cache của chúng vì lợi ích chung. Cache cung cấp sự lựa
chọn ngang hàng hỗ trợ được gọi là sibling caches. Bởi vì HTTP không cung cấp hỗ trợ
sibling caches, người dùng đã mở rộng HTTP với protocol, như là Internet Cache Protocol
(ICP) và HyperText Caching Protocol (HTCP), CHúng ta sẽ thảo luận về những protocol
này trong chapter 20.


Người dịch: Nguyễn Trường Hận

7.7. Cache Processing Steps
Những bộ nhớ cache proxy hiện đại ngày nay thì khá phức tạp. Chúng được xây dựng
để có hiệu xuất cao và hỗ trợ những tính năng cấp cap của HTTP và những công nghệ khác.

Mặc dù có một vài chi tiết phức tạp nhưng hoạt động cơ bản của bộ nhớ cache hầu hết đều
đơn giản. Một tiến trình cache đơn giản cho một HTTP GET message bao gồm 7 bước.
1. Receiving : Cache đọc những request message nhận từ nework
2. Parsing : Cache phân tích những message này, trích xuất thông tin URL và header
3. Lookup: Cache kiểm tra nếu một bản sao ở local hợp lệ và nếu không sẽ tìm nạp bản
sao lưu đó
4. Freshness check: Cache kiêmt tra nếu bản sao lưu dữ liệu còn đủ mới và nếu không
yêu cầu cập nhật từ server.
5. Response creation: Cache tạo một response message với header mới và body nội
dung được lưu trong cache trong body.
6. Sending: Cache gửi những response tới client thông qua nework
7. Logging: (tùy chọn), Cache tạo một log file mô tả quá trình giao dịch.
Step 1: Receiving


Người dịch: Nguyễn Trường Hận
Trong bước 1, Cache phát hiện hoạt động trên một kết nối network và đọc data được
gởi tới. Cache hiệu suất cao đọc dữ liệu đồng thời từ nhiều connection và bắt đầu xử lí giao
dịch trước khi toàn bộ message đến.
Step 2: Parsing
Tiếp theo, Cache phân tích request message thành từng phần và đặt các header vào
một cấu trúc dữ liệu dễ thao tác. Điều này làm nó dễ dàng hơn cho phần mềm caching để
xử lí header.

Step 3: Lookup
Ở bước 3, Cache lấy URL và kiểm tra chúng có bản sao lưu không. Bản sao lưu có
thể được lưu trong bộ nhớtrên đĩa cứng local hoặc ở một nới khác gần máy tính. Cache
chuyên nghiệp sử dụng thuật toán nhanh nhằm mục đích kiểm tra liệu một đối tượng hợp
lệ trên local cache. Nếu một document không hợp lệ trên local, nó có thể được tìm nạp từ
server hoặc proxy cha, hoặc trả về lỗi, dựa trên tình hình và cấu hình.

Đối tượng cache bao gồm body của response của server và header của response
server, vì vậy những header đúng có thể được trả lại trong 1 cahe hit. Đối tượng cache còn


Người dịch: Nguyễn Trường Hận
bao gồm một vài metadata được sử dụng để tính toán đối tượng đã được lưu lại bao lâu
trong cahe, bao nhiêu lần nó được sử dụng, …
Step 4: Freshness Check
HTTP cho phép cache giữ những bản sao lưu document của server một khoảng thời
gian dài. Suốt thời gian này, document được xem như mới và cache có thể phục vụ
document này mà không cần kết nối đến server. Nhưnng một khi bản sao lưu trong cache
đã ở lâu rồi, thì tại liệu này được gọi là “freshness limit”, đối tượng được xem là cũ và
cache ccần kiểm tra lại với server liệu có bất kì document nào được thay đổi không trước
khi trả nó cho client. Những điều phức tạp hơn nữa là bất kì request header nào mà một
client gửi tới cache, có có thể buộc cache kiểm tra lại để tránh xảy ra sự không hợp lệ tài
liệu.
HTTP có một tập rule rất phức tạp cho việc kiểm tra sự mới của document, hơn nữa
là số lượng các option cấu hình hỗ trợ sản phẩm cache lớn và sự cần thiết phải tương thích
với những tiêu chuẩnnon-HTTP freshness.
Step5: Response Creation
Bởi vì chúng ta muốn cache gửi response giống như là response đó đến từ server,
cache sử dụng server response header đã lưu trong cache như điểm bắt đầu cho response
những header. Những tiêu đề cơ sở này được sửa đổi sau đó và được tăng cường bởi cache.
Cache chịu trách nhiệm điều chỉnh header cho khớp với client. Ví dụ, server có thể
trả một response HTTP/1.0, trong khi client sử dụng một HTTP/1.1, trong trường hợp này
cache phải dịch header một cách phù hợp, cache còn chèn thêm những thông tin về độ mới
của document được lưu (Cache-Control, Age, Expries headers) và thường xuyên bao gồm
một Via header nhắc nhở rằng một proxy cache phục vụ request này.
Chú ý rằng cache không nên chỉnh sửa Date header, Date header biểu thị ngày mà đối
tương được tạo ra ở server

Step 6: Sending


Người dịch: Nguyễn Trường Hận
Một khi response header đã sẵn sàng, cache gửi response trả về cho client. Như mọi
proxy, một proxy cần quản lý kết nối với client. Cache hiệu suất caolàm việc chăm chỉ để
gửi dữ liệu một cách hiệu quả, thường xuyên tránh sao chép nội dung docment giữa bộ nhớ
local và bộ đệm I/O network.
Step 7: Logging
Hầu hết cache giữ những log file và số liệu thống kê về tỷ lệ sử dụng cache. Sau mỗi
giao dịch cache hoàn thành, cache cập nhật số liệu thống kê tính toán số cache hit và misses
và chèn một entry vào 1 log file cho biết loại request, URL và điều gì đã xảy ra.
Cache Processing Flowchart
Hình 7-12 cho thấy, trong một mẫu đơn giản, một cache xử lý một request GET một
URL như thế nào.

7.8. Keeping Copies Fresh
Những bản sao lưu cache không phải tất cả đều phù hợp với document trên server.
Sau tất cả, document thay đổi theo thời gian. Báo cáo có thể thay đổi hàng tháng. Báo điện
tử thay đổi hàng ngày. Data thì thay đổi từng giây. Cache sẽ vô ích nếu chúng luôn luôn
phục vụ những data cũ. Cached data cần duy trì tính nhất quán với server.


Người dịch: Nguyễn Trường Hận
HTTP bao gồm những cơ chế đơn giản để giữ cache data đủ nhất quán với server mà
không yêu cầu server nhớ những document mà cache đã sao lưu. HTTP call những cơ chế
đơn giản ấy là document expiration và server revalidation
Document Expiration
HTTP cho phép một server gốc đính kèm một “expiration date” tới mỗi document,
sử dụng các header HTTP đặc biệt là Cache-Control và header Expires (hình 7-13). Như

một ngày hết hạn trên một hộp sữa, những header này quyết định nội dung nên được xem
là mới bao lâu. Cho đến một cache document hết hạn, cache có thể phục vụ bản sao lưu
thường xuyên như nó muốn mà không bao giờ phải liên hệ tới server, trừ khi, dĩ nhiên một
client request bao gồm những header ngăn chặn phục vụ một tài nguyên được lưu ở cache
hoặc hết hạn. Nhưng một document được lưu ở cache hết hạn, cache phải kiểm tra với
server để yêu cầu nếu document đã thay đổi và nếu có thay đổi thì sẽ lấy về một bản sao
lưu mới.
Expiration Dates and Ages
Server chỉ định ngày hết hạn sử dụng HTTP/1.0+ Expires hoặc HTTP/1.1 Cache Control: max-age response headers đi cùng với đoy của response. Expires and CacheControl: max-age header thực hiện những việc đơn giản giống nhau, nhưng Cache-Control
header được ưu ích hơn vì nó sử dụng một thời gian tương đối thay vì một ngày tuyệt đối.
Ngày tuyệt đối phụ thuộc vào đồng hồ máy tính được thiết đặt một cách chính sách.

Server Revalidation (Kiểm tra lại với server)


Người dịch: Nguyễn Trường Hận
Chỉ vì một cache document có ngày hết hạn không có nghĩa là nó thực sự khác với
những document ở trên máy chủ, nó chỉ có nghĩa là đã đến lúc kiểm tra. Điều này được gọi
là “server revalidation” có nghĩa là cache cần hỏi server liệu document có thay đổi không:
-

Nếu revalidation chỉ ra rằng nội dung đã được thay đổi, cache sẽ lấy bản sao lưu mới
của document, lưu nó đè lên document cũ và gửi nó cho client.

-

Nếu revalidation chỉ ra rằng nội dung chưa thay đổi, cache chỉ cần lấy header mới
của nó bao gồm một ngày hết hạn mới và cập nhật vào cache.
Điều này là một hệ thống tốt, cache không phải kiểm tra độ mới của một document

cho mỗi request, nó phải xác nhận lại với server chỉ một lần xem document có hết hạn
không. Điều này tiết kiệm lưu lượng và cung cấp một thời gian response người dùng tốt
hơn mà không phục vụ document cũ.
HTTP protocol yêu cầu một bộ nhớ cache hoạt động đúng đắn để trả về những điều
sau:
-

Một bản sao lưu document được lưu tron cache đủ mới

-

Một bản sao lưu đã được xác nhận lại với server để đảm bảo rằng nó vẫn còn mới.

-

Một error messge nếu server xác nhận lại là down

-

Một bản sao lưu đính kèm với một warning rằng document có thể không đúng.
Revalidation with Conditional Methods
Các phương thức có điều kiện của HTTP làm cho việc xác nhận lại có hiệu quả. HTTP

cho phép một cache gửi một “conditional GET” tới server, yêu cầu server gửi trả về một
body của đối tượng chỉ nếu document khác với bản sao lưu hiện tại trong cache. Trong
cách thức này, việc kiểm tra độ mới và tìm nạp đối tượng được kết hợp thành một GET có
điều kiện. Get có điều kiện được bắt đầu bởi thêm header điều kiện đặc biệt tới GET request
message. Web server trả về đối tượng chỉ nếu điều kiện là đúng. HTTP định nghĩa 5 header
điều kiện request. Trong đó 2 cái là hữu ích nhất cho việc xác nhận lại của cache là IfModified-Since và If-None-Match. Tất cả header điều kiện đều bắt đầu bằng “If”.

Người dịch: Nguyễn Trường Hận

If-Modified-Since: Date Revalidation
Header điều kiên xác nhận lại cache phổ biến nhất đó là If-Modified-Since. Request
này thường được gọi là IMS request. IMS request hướng dẫn một server thực hiện request
chỉ khi tài nguyên đã được thay đổi kể từ một ngày nhất định:
-

Nếu document đã được chỉnh sửa từ một ngày nhất định, IMS điều kiện là đúng và
GET thành công một cách bình thường. Một document mới được trả về cho cache
kèm theo là những header mới, những thông tin khác, một ngày hết hạn mới.

-

Nếu document không được chỉnh sứa kể từ một ngày xác định, điều kiện IMS là sai
và một response nhỏ với status code là 304 Not Modified được trả về cho client mà
không có document body, chỉ có nhữg header cần được cập nhật từ ban đầu cần được
trả về. Ví dụ , Content-Type header không thường xuyển cần được gửi, kể từ khi nó
thôngt thường không được thay đổi. Một ngày hết hạn mới được gửi.
Header IMS làm việc kết hợp với header Last-Modified server trả về. Server đính

kèm ngày cuối cùng chỉnh sửa tới document được phụ vụ. Khi mộ cache muốn kiểm tra lại
một document được lưu trong cache, nó bao gồm một header If-Modified-Since với ngày
mà bản sao lưu cache lần cuối được chỉnh sửa.

Nếu nội dung đã thay đổi trong thời gian chờ đợi, ngày cuối cùng chỉnh sửa sẽ khác
và server sẽ gửi trả về document mới. Nếu không thì server sẽ nhắc nhở rằng ngày cuối
cùng chỉnh sửa của cache document trùng với ngày chỉnh sửa gần nhất của document trên
server và nó sẽ trả về một response 304 Not Modified.

Ví dụ, như hình 7-14, Nếu cache của bạn kiểm tra lại thông báo sale lần thứ 4 tháng
7 của Joe’s Hardware vào ngày 3/7, bạn sẽ nhận được một response 304 Not Modified.


Người dịch: Nguyễn Trường Hận
Nhưng nếu cache của bạn kiểm tra document sau khi sale kết thúc giữa đêm 5/7, cache sẽ
nhận được một document mới, bởi vì nội dung document trên server đã thay đổi.

Chú ý rằng một vài web server không thực hiện IMS như là một phép so sánh ngày
đúng đắn. Thay vào đó, chúng thực hiện một chuỗi trùng với giữa IMS date và lastmodified date. Như vậy, nó sẽ hành động như “Nếu không được chỉnh sửa lần cuối vào
ngày chính xác này” thay vào đó là “Nếu được chỉnh sửa lần cuối vào ngày này”. Thay thế
thực hiện tốt cho sự hết hạn của cache. Khi bạn đang sử dụng last-modified date như một
loại số sê ri, nhưng nếu nó ngăn chặn client từ sử dụng header IMS cho mục đích đúng thời
gian.
If-none-Match: Entity Tag Revalidation
Trong một vài tình huống khi last-modified date kiểm tra lại không đầy đủ:


Người dịch: Nguyễn Trường Hận
Một document có thể được viết một cách định kỳ nhưng thực ra thường xuyên bao
gồm những dữ liệu giống nhau. Ngày chỉnh sửa sẽ thay đổi dù cho nội dung có không thay
đổi.
Một vài document có thể được thay đổi, nhưng chỉ trong những cách không quan
trọng đủ để đảm bảo cache trên toàn thế giới để tải lại dữ liệu (ví dụ: thay đổi chính tả hoặc
nhận xét)
Một vài server không thể xác định chính xác ngày chỉnh sửa cuối cùng của những
page trên server.
Đối với các server phục vụ document thay đổi trong khoảng thời gian phụ, độ chi tiết
trong một giây của các ngày sửa đổi có thể không đầy đủ.
Để giải quyết những vấn đề này, HTTP cho phép bạn so sánh version

Identifiers của document được gọi là entity tags. Entity tags là nhãn tùy ý đính kèm
với document. Chúng có thể bao gồm một serial number hoặc tên version cho document,
hoặc một checksum hoặc vân tay khác của nội dung document.
Khi nhà xuất bản tạo một thay đổi document, anh ta có thẻ thay đổi entity tag của
document để thể hiện version mới này. Cache có thể sau đó sử dụng If-None-Match
conditon header để lấy một bản copy mới của document nếu entity tag đã được thay đổi.
Trong hình 7-15, cache có một document với entity tag “v2.6”. Nó xác nhận lại với
server để hỏi về một đối tượng mới chỉ nếu tag này không còn phù hợp nữa. Trong hình 715, tag vẫn còn phù hợp, vì vậy một 304 Not Modified response được trả lại.


Người dịch: Nguyễn Trường Hận

Nếu entity tag trên server đã thay đổi (có thể là “v3.0”), server sẽ trả về nội dung mới
trong một response OK, kèm với nội dung và new entity tag.
Một vài entity tag có thể bao gồm một header If-None-Match, để nói cho server rằng
cache đã copy đối tượng với enitty tag của nó rồi.

Weak and Strong Validators (Trình xác thực mạnh và yếu)
Cache sử dụng entity tag để xác định liệu cache phiên bản được lưu trong bộ nhớ
cache có cập nhật với máy chủ không. Trong cách này, entity tag và ngày last-modified
đều là trình xác thực của bộ nhớ cache.
Server có thể thỉnh thoảng muốn cho phép thay đổi document không đáng kể mà
không làm mất hiệu lực tất cả các bản sao lưu trong bộ nhớ cache. HTTP/1.1 hỗ trợ “weak
validator”, cái mà cho phép server yêu cầu tương đương “good enough” ngay cả khi nội
dung đã thay đổi một ít.
Xác thực mạnh thay đổi bất kì thời gian nào mà nội dung thay đổi. Xác thực yếu cho
phép một vài nội dung thay đổi nhưng thường thay đổi khi ý nghĩa quan trọng của nội dung
thay đổi. Một vài hoạt động không thể được thực hiện sử dụng xác thực yếu (ví dụ như

Người dịch: Nguyễn Trường Hận
điều kiện tìm nạp partial-range), vì vậy những server nhận dạng trình xác thực yếu với tiền
tố “W/” prefix:

Một entity tag mạng phải thay đổi bất cứ khi nào thay đổi giá trị entity được liên kết
trong bất kì cách nào. Một entity yếu nên thay đổi bất cứ khi nào enitty thay đổi được liên
kết trong một theo ngữ nghĩa.
When to Use Entity Tags and Last-Modified Dates
HTTP/1.1 client phải sử dụng một entity tag validator nếu một server gửi trả lại một
entity tag, Nếu server gửi trả lại chỉ một giá trị Last-modified, client có thể sử dụng
validation If-Modified-Since. Nếu cả một entity tag và một last-modified date là hợp lệ,
cliẻn nên sử dụng cả việc kiểm tra lại, cho phép cả cache HTTP/1.0 và HTTP/1.1 phản hồi
một cách thích đáng.
Sever HTTP/1.1 nên gửi một entity tag validator trừ khi nó không khả thi để tạo một
entity tag validator và nó có thể là một enity tag yếu thay vì một entity tag mạnh. Nếu có
lợi ích cho weak validator. Ngoài ra, nó cón gửi một giá trị last-modified.
Nếu một cache HTTP/1.1 hoặc server nhận một request với cả header điều kiện là fModified-Since và entity tag, nó không được trả về một 304 Not Modified response trừ khi
việc làm như vậy là phù hợp với tất cả header điều kiện trong request.
7.9. Controlling Cachability
HTTP định nghĩa một vài cách để một server chỉ định một document có thể được lưu
trong cache trước khi nó hết hạn bao lâu. Trong thứ tự ưu tiên giảm dần, máy chủ có thể:
Đính kèm một Cache-Control: header no-store vào response
Đính kèm một Cache-Control: header no-cache vào response
Đính kèm một Cache-Control: header must-revalidate vào response
Đính kèm một Cache-Control: header max-age vào response
Đính kèm một header Expires date vào response


Người dịch: Nguyễn Trường Hận
Không đính kèm thông tin hết hạn, cho phép cache xác định ngày hết hạn của riêng

nó.
Phần này mô tả những header cache controlling.
No-Cache and No-Store Response Headers
HTTP/1.1 cung cấp một vài cách để hạn chế bộ nhớ đệm của đối tượng, hoặc phục
vụ đối tượng được lưu trong cach để suy trì sự mới của tài nguyên. Header no-store and
no-cache ngăn chặn cache phân phát các đối tượng được lưu trữ chưa xác minh:

Một response được đánh dấu “no-store” sẽ cấm một cache tạo bản sao lưu của
response. Một cache thường sẽ chuyển tiếp một no-store response tới client và sau đó xóa
đối tượng như một proxy server non-caching.
Một response được đánh dấu “no-cache” có thể được thực sự lưu trữ trong local cache.
Nó không thể được phục vụ từ cache tới client mà không kiểm tra độ mới của tài nguyên
trên server. Một tên tốt hơn cho header này có thể là “do-not-serve-from-cache-withoutrevalidation”
Max-Age Response Headers
The Cache-Control: header max-age cho biết số giây kể từ khi nó đến từ server mà
document có thể được xem như là mới. Đó cũng là một header maxage hoạt động như maxage nhưng chỉ áp dụng cho bộ nhớ cache public.

Server có thể request cache hoặc không lưu vào cache một document hoặc tải lại trên
mỗi truy cập bởi cài đặt age tối đa bằng 0: