LTS: Hầu hết những người duyệt Web hiện nay đều đang
sử dụng có chủ ý hoặc vô thức các bộ đệm Web. Các bộ đệm
Web này giúp giảm độ trễ trao đổi thông tin giữa máy khách và máy chủ Web, giảm
tải cho hệ thống máy chủ và giảm lưu lượng thông tin trên mạng. Các hướng dẫn
dưới đây về bộ đệm Web được lược dịch từ tài liệu “Caching Tutorial”
của tác giả Mark Nottingham tại địa chỉ
www.mnot.net/cache_docs/. Tài liệu
này không nhằm đưa ra chỉ dẫn sử dụng bộ đệm cho người dùng cuối mà cung cấp
thông tin sâu về hoạt động của bộ đệm Web và phương thức mà các nhà thiết kế và
quản trị Web có thể áp dụng để tận dụng tối đa những ưu điểm của hệ thống này.
Bộ đệm Web là gì?
Bộ đệm Web (Web cache) nằm ở vị trí giữa các máy chủ Web và máy khách, có nhiệm
vụ theo dõi các luồng thông tin đi vào và lưu trữ lại một bản sao của các dữ
liệu đó. Các dữ liệu ở đây có thể là trang HTML, các bức ảnh hoặc tập tin,...
Sau đó, khi có yêu cầu tới cùng địa chỉ URL, bộ đệm Web sẽ gửi lại các dữ liệu
mà nó đã lưu thay vì gửi yêu cầu tới máy chủ Web một lần nữa.
Có 2 lý do chính để sử dụng bộ đệm Web:
Giảm độ trễ: do các yêu cầu có thể được đáp ứng ngay từ bộ đệm thay vì được
gửi tới máy chủ, thời gian để lấy và hiển thị các nội dung thông tin sẽ được rút
ngắn đáng kể, từ đó sẽ làm cho Web có khả năng đáp ứng nhanh hơn.
Giảm lưu lượng mạng: do các thông tin được sử dụng lại, lượng băng thông máy
khách sử dụng sẽ giảm đi. Điều này sẽ giúp khách hàng tiết kiệm chi phí khi sử
dụng cách tính cước theo lưu lượng, đồng thời cũng giúp giảm đòi hỏi về mức băng
thông.
Các loại bộ đệm Web
Bộ đệm trình duyệt
Nếu bạn đã từng xem xét hộp thoại tuỳ biến của bất kỳ trình duyệt Web hiện đại
nào (như Internet Explorer, Safari, hay Mozilla) bạn sẽ thấy có thiết đặt về bộ
đệm. Thiết lập này cho phép bạn dành riêng một phần của ổ cứng máy tính để lưu
trữ các thông tin mà bạn đã xem. Bộ đệm trình duyệt hoạt động theo một nguyên
tắc khá đơn giản: nó sẽ thực hiện các công việc kiểm tra nhằm đảm bảo các thông
tin luôn mới.
Bộ đệm này đặc biệt hữu ích khi người dùng ấn phím quay lui (back) hoặc nhấn vào
một liên kết tới trang mà họ vừa xem. Cũng tương tự như vậy, khi bạn sử dụng các
bức ảnh có chức năng điều hướng trên trang, chúng sẽ được cung cấp từ bộ đệm
trình duyệt gần như tức thời.
Bộ đệm proxy
Bộ đệm Web proxy cũng hoạt động với nguyên tắc tương tự, nhưng ở quy mô lớn hơn.
Mỗi proxy phục vụ hàng trăm tới hàng nghìn người dùng theo cùng cách như vậy.
Các công ty lớn hoặc các ISP thường thiết lập proxy trong các thiết bị tường lửa
hoặc như một thiết bị độc lập.
Do bộ đệm proxy không phải là thành phần của máy khách cũng như máy chủ, các
thông tin được yêu cầu cần được định tuyến qua đó. Một trong các cách để thực
hiện điều đó là sử dụng thiết lập về proxy của trình duyệt để cấu hình thủ công
proxy nào sẽ được sử dụng. Một cách khác là sử dụng proxy loại chặn
(interception proxy). Interception proxy được các lớp mạng dưới tự động tái định
hướng các yêu cầu web tới mà không cần can thiệp từ phía máy khách.
Bộ đệm proxy là dạng bộ đệm dùng chung, trong đó không chỉ có một người sử dụng
mà thường có số lượng lớn người dùng. Trong môi trường đó, do các nội dung được
nhiều người quan tâm được sử dụng lại rất nhiều lần, thời gian trễ và lưu lượng
mạng giảm đi đáng kể.
Bộ đệm gateway
Bộ đệm gateway cũng hoạt động ở lớp trung gian, nhưng thay vì được triển khai
bởi các nhà quản trị mạng nhằm giảm băng thông, chúng thường được triển khai bởi
những người quản lý Website với mục đích tăng tính khả mở, tính tin cậy và hiệu
năng của Website.
Các yêu cầu thông tin Web có thể được định hướng tới bộ đệm gateway theo một số
cách, nhưng thường thì các thiết bị cân bằng tải được sử dụng nhằm giúp các máy
khách tương tác với các gateway giống như với các máy chủ.
Các mạng phân phối nội dung (Content delivery networks – CDNs) phân phối các nội
dung trên toàn Internet đã được lưu đệm tại gateway và bán lại nội dụng đệm đó
cho các Website muốn sử dụng. Speedera (www.speedera.com)
và Akamai (www.akamai.com)
là các ví dụ về mạng phân phối nội dung.
Bài viết này tập trung chủ yếu vào bộ đệm trình duyệt và bộ đệm proxy, dù vậy,
một số phần nội dung vẫn thích hợp với ai quan tâm tới bộ đệm phía gateway.
Bộ đệm Web có tốt cho website không?
Bộ đệm Web là một trong những công nghệ gây ra nhiều hiểu nhầm nhất trên
Internet. Các nhà quản trị Web thường rất sợ mất quyền điều khiển website của
mình. Lý do là bộ đệm proxy khiến người sử dụng trở nên “ẩn” đối với họ, và do
đó họ rất khó để biết rằng ai đang sử dụng website của mình.
Một vấn đề khác cũng đáng quan tâm, đó là các bộ đệm có thể đưa đến các thông
tin đã hết hạn, không còn hiện hữu. Bài viết này sẽ giới thiệu cách cấu hình máy
chủ để điều khiển phương thức đệm các nội dung của bạn.
Trái lại, nếu bạn lập kế hoạch tốt, các bộ đệm có thể giúp website của bạn được
tải nhanh hơn, và cũng giúp giảm tải cho máy chủ và kết nối Internet của bạn. Sự
khác biệt là rất đáng kể: một website khó lưu đệm có thể mất tới vài giây để
tải, trong khi đó website tận dụng được các ưu thế của bộ đệm có khả năng xuất
hiện gần như tức thời. Người dùng sẽ đánh giá cao các website có tốc độ tải
nhanh và thường xuyên quay trở lại hơn.
Bạn hãy nghĩ tới một hình ảnh sau: rất nhiều công ty Internet lớn đã chi hàng
triệu đô la để xây dựng các trung tâm máy chủ lớn trên khắp thế giới để nhân bản
nội dung ở nhiều nơi, qua đó nhắm tới mục đích tăng tốc độ truy nhập tối đa cho
người sử dụng. Thế nhưng, các bộ đệm có thể thực hiện công việc tương tự như vậy
cho bạn, hơn nữa bộ đệm lại ở gần phía máy khách hơn. Và tuyệt vời hơn cả là bạn
không phải chả bất kỳ chi phí nào cho việc sử dụng các bộ đệm do nó nằm ở phía
máy khách.
Các bộ đệm Web làm việc như thế nào?
Tất cả các bộ đệm đều có một tập quy tắc dùng để xác định khi nào sẽ đưa ra các
nội dung đã lưu trong bộ đệm. Một số trong các quy tắc đó được thiết lập ở mức
giao thức (HTTP 1.0 và HTTP 1.1), một số khác lại được thiết lập bởi người quản
trị bộ đệm, người quản trị có thể là người dùng của bộ đệm trình duyệt hay người
quản trị proxy.
Tuy vậy, nhìn chung có những quy tắc chung phải theo:
-
Nếu phần tiêu đề của nội dung phản hồi cho biết bộ đệm không lưu giữ nội
dung này, bộ đệm sẽ tuân thủ đúng như vậy.
-
Nếu nội dung phản hồi không chứa thông tin xác nhận tính hợp lệ (chứa
ETag hoặc Last-Modified trong tiêu đề), nội dung đó sẽ
được xem là không lưu đệm được.
-
Nếu nội dung phản hồi được xác thực hoặc dưới dạng bảo mật, nội dung đó sẽ
không được lưu đệm.
-
Nội dung trong bộ đệm được coi là mới, nghĩa là có thể gửi
tới người sử dụng mà không cần đối chiếu lại với máy chủ gốc, nếu:
-
Nếu phần tiêu đề có chứa thời gian hết hiệu lực hoặc các điều khiển thời
gian tồn tại, nội dung sẽ được coi là mới trong khoảng thời gian đó.
-
Nếu bộ đệm trình duyệt đã từng lưu nội dung thông tin đó và được thiết
lập kiểm tra mỗi phiên một lần.
-
Nếu bộ đệm proxy đã từng lưu nội dung thông tin đó và thời điểm thay đổi
cuối của nội dung thông tin đã khá lâu.
-
Nếu nội dung thông tin đã hết hạn, máy chủ gốc sẽ được yêu cầu xác nhận lại
thông tin, hoặc thông báo cho bộ đệm biết bản sao đang lưu vẫn còn hoạt động
tốt.
Tính mới và xác nhận là những thông tin quan
trọng nhất cho phép bộ đệm làm việc với các nội dung thông tin. Các nội dung
thông tin mới sẽ được bộ đệm phục vụ gần như tức thì, trong khi đó các nội dung
thông được xác nhận giúp tránh gửi lại toàn bộ nội dung một lần nữa khi mà các
nội dung đó không có gì thay đổi.
Điều khiển bộ đệm như thế nào?
Có một số công cụ mà các nhà thiết kế và quản trị Web có thể sử dụng để tinh
chỉnh phương thức các bộ đệm sẽ tương tác với website của mình. Làm được điều
này đòi hỏi bạn phải thay đổi một chút các thiết lập của máy chủ.
Các thẻ meta HTML và các tiêu đề HTTP
Những người soạn thảo HTML có thể đặt một số thẻ trong phần < head > để mô tả
các thuộc tính của tài liệu. Các thẻ tự định nghĩa này (thẻ meta) thường được sử
dụng để đánh dấu tài liệu đó là không cho phép lưu đệm, hoặc nhằm thiết lập thời
gian hết hiệu lực của tài liệu.
Các thẻ meta rất dễ sử dụng nhưng không mấy hiệu quả do nó chỉ được một số ít
các bộ đệm trình duyệt lưu tâm, và không được các bộ đệm proxy sử dụng. Trong
khi việc đặt một thẻ meta no-cache vào các trang web là rất đơn giản, điều đó
lại không đảm bảo phần lưu của trang web luôn mới.
Trái lại, các tiêu đề HTTP cho phép bạn thực hiện rất nhiều quyền điều khiển đối
với việc lưu trữ các nội dung thông tin trên bộ đệm trình duyệt cũng như bộ đệm
proxy. Các điều khiển này không nhìn thấy được trong mã HTML và thường được sinh
bởi máy chủ Web. Tuy vậy, bạn vẫn có thể điều khiển được chúng ở một số mức độ
nhất định, tuỳ thuộc vào máy chủ Web mà bạn đang sử dụng. Trong phần dưới đây
bạn sẽ thấy các tiêu đề HTTP có ích như thế nào và làm thế nào để sử dụng chúng
cho website của bạn.
Các tiêu đề HTTP được máy chủ gửi đi trước phần mã HTML và chỉ được nhìn thấy
bởi trình duyệt và một số bộ đệm trung gian. Một tiêu đề phản hồi HTTP 1.1 điển
hình có dạng như sau:
HTTP/1.1 200 OK
Date: Fri, 30 Oct 1998 13:19:41 GMT
Server: Apache/1.3.3 (Unix)
Cache-Control: max-age=3600, must-revalidate
Expires: Fri, 30 Oct 1998 14:19:41 GMT
Last-Modified: Mon, 29 Jun 1998 02:28:12 GMT
ETag: "3e86-410-3596fbbc"
Content-Length: 1040
Content-Type: text/html
Phần mã HTML sẽ đi theo sau phần tiêu đề này, được phân cách bởi một dòng trống.
Tiêu đề HTML Pragma
Khá nhiều người tin rằng việc gán một tiêu đề HTTP Pragma: no-cache
sẽ thiết lập cho một nội dung trở thành không được lưu đệm.. Tuy vậy điều này
không hoàn toàn đúng, trong đặc tả HTTP không có bất kỳ hướng dẫn nào về các
tiêu đề Pragma phản hồi, trong khi đó, các tiêu đề Pragma yêu cầu (là các tiêu
đề mà trình duyệt gửi tới máy chủ) lại có được đề cập tới. Chỉ có một số ít bộ
đệm để tâm tới tiêu đề này, đối với phần lớn các bộ đệm còn lại thì tiêu đề này
không tạo ra bất kỳ hiệu ứng nào. Do vậy, bạn có thể sử dụng các tiêu đề dưới
đây để thay thế.
Điều khiển độ mới tài liệu với tiêu đề HTTP Expires
Tiêu đề HTTP Expires là phương tiện cơ bản đề điều khiển quá
trình lưu đệm, nó thông báo cho tất cả các bộ đệm biết thời gian nội dung thông
tin được coi là mới sẽ kéo dài tới khi nào. Sau khoảng thời gian đó, các bộ đệm
luôn kiểm tra lại với máy chủ gốc để xem có thay đổi nào không. Trên lý thuyết,
tiêu đề Expires được hỗ trợ bởi mọi bộ đệm.
Hầu hết các máy chủ Web cho phép bạn thiết lập tiêu đề Expires
phản hồi theo một số cách khác nhau. Thông thường, máy chủ Web sẽ cho phép thiết
lập thời gian hết hạn là một giá trị tuyệt đối, hoặc là thời gian tương đối dựa
trên lần truy cập cuối, hoặc thời gian tương đối dựa trên thời điểm thay đổi
cuối cùng của tài liệu trên máy chủ.
Các tiêu đề Expires đặc biệt hữu ích đối với các ảnh tương đối
cố định trên website như thanh định vị hay các nút ấn. Do các ảnh này không
thường xuyên thay đổi, bạn có thể thiết đặt thời gian hết hạn khá dài cho chúng.
Điều này sẽ làm cho tốc độ đáp ứng của website tăng lên rất nhiều. Tiêu đề này
cũng có ích đối với việc điều khiển lưu đệm một trang thường xuyên có thay đổi.
Ví dụ, nếu bạn cập nhật trang tin tức mỗi ngày một lần vào lúc 6 giờ sáng, bạn
có thể thiết lập để trang tin hết hạn vào thời điểm đó, từ đó các bộ đệm sẽ biết
được khi nào cần tải về một bản sao mới mà không cần người dùng phải ấn nút “Nạp
lại” (Reload) trên trình duyệt.
Giá trị hợp lệ duy nhất cho tiêu đề Expires là giá trị dạng ngày
tháng theo đặc tả của HTTP, tất cả các dạng dữ liệu khác sẽ được diễn dịch thành
thời gian trong quá khứ, và do đó nội dung thông tin sẽ không được lưu đệm. Cũng
cần lưu ý rằng, thời gian theo đặc tả HTTP là dưới dạng giờ chuẩn căn cứ theo
kinh tuyến Greenwich (giờ GMT), chứ không phải thời gian theo địa phương.
Ví dụ:
Expires: Fri, 30 Oct 1998 14:19:41 GMT
Mặc dù tiêu đề Expires khá hữu ích, nó vẫn có một số hạn chế
nhất định. Trước hết, do liên quan tới ngày tháng, đồng hồ trên máy chủ Web và
trên các bộ đệm phải được đồng bộ với nhau; nếu các đồng hồ này có chênh lệch
thời gian, kết quả trộng đợi có thể sẽ không đạt được, và bộ đệm có khả năng bị
nhầm lẫn khi đánh giá một tài liệu là mới.
Một vấn đề nữa đối với tiêu đề Expires là người ta rất dễ quên
rằng mình đã đặt thời gian hết hạn cho tài liệu. Nếu bạn quên cập nhật thời gian
hết hạn cho tài liệu trước khi gửi đi, mọi yêu cầu tài liệu sẽ không được đáp
ứng bởi các bộ đệm mà bị gửi trả về máy chủ Web, tạo ra độ trễ và làm tăng tải
hệ thống.
Tiêu đề HTTP Cache-Control
Phiên bản HTTP 1.1 giới thiệu một loại tiêu đề mới là tiêu đề
Cache-Control phản hồi nhằm giúp các nhà thiết kế Web có nhiều khả năng điều
khiển hơn đối với nội dung và nhằm giải quyết một số hạn chế của tiêu đề
Expires.
Các tiêu đề HTTP Cache-Control phản hồi hữu ích bao gồm:
max-age=[số giây] – Chỉ ra khoảng thời gian tính bằng giây mà một nội dung
được coi là mới.
s-maxage=[số giây] – tương tự như max-age, ngoại trừ việc nó chỉ được áp
dụng cho các bộ đệm dùng chung (ví dụ bộ đệm proxy)
public – đánh dấu một phản hồi có xác thực là được phép lưu đệm, thông
thường, nếu có yêu cầu xác thực HTTP, phản hồi được thiết lập mặc định là không
cho phép lưu đệm.
no-cache – bắt buộc các bộ đệm phải gửi yêu cầu về máy chủ gốc để xác nhận
trước khi phân phối bản lưu đệm. Điều này rất hữu ích nhằm đảm bảo quá trình xác
thực người dùng, hoặc đảm bảo tính mới của tài liệu, mà không phải hy sinh toàn
bộ các ưu điểm của bộ đệm.
no-store – chỉ thị cho các bộ đệm không lưu giữ bản sao của nội dung thông
tin trong bất kỳ hoàn cảnh nào.
must-revalidate – thông báo cho bộ đệm biết có thể sử dụng nội dung phản hồi
này cho các lần yêu cầu sau. Nhưng nếu nội dung phản hồi đã cũ, bộ đệm phải tái
xác nhận lại với máy chủ gốc.
proxy-revalidate – tương tự như must-revalidate, ngoại trừ việc nó chỉ được
áp dụng cho các bộ đệm proxy.
Ví dụ:
Cache-Control: max-age=3600, must-revalidate
Xác nhận và các Chỉ thị xác nhận
Trong phần trên, chúng ta đã nói về việc trao đổi các xác nhận giữa máy chủ và
bộ đệm khi một nội dung có thay đổi. Bằng cách đó, khi bộ đệm không chắc chắn về
tính mới của một nội dung, nó vẫn tránh được việc tải lại toàn bộ nội dung khi
nó đã lưu một bản sao của chính nội dung đó lúc trước.
Các chỉ thị xác nhận có vai trò rất quan trọng; nếu trong thông tin phản hồi
không chứa chỉ thị xác nhận nào và cũng không có các thông tin về độ mới, các bộ
đệm sẽ không lưu lại thông tin đó.
Chỉ thị xác nhận phổ biến nhất là thời gian cập nhật cuối cùng của tài liệu được
lưu trong tiêu đề Last-Modified. Khi bộ đệm lưu một nội dung có
tiêu đề Last-Modifed đi kèm, nó có thể sử dụng tiêu đề này để
hỏi máy chủ xem nội dung đó đã có thay đổi từ lần lưu cuối hay không.
HTTP 1.1 đưa ra một loại chỉ thị xác nhận mới là ETag.
ETag là định danh duy nhất được sinh bởi máy chủ vày thay đổi đối với mỗi
nội dung. Do máy chủ điều khiển việc sinh các ETag, bộ đệm có
thể so sánh ETag của tài liệu mới nhất với tài liệu mà nó đã
lưu.
Hầu hết các bộ đệm sử dụng thời gian trong Last-Modified để xác
định một nội dung có mới hay không; xác nhận bằng ETag cũng dần
trở nên phổ biến. Hầu hết các máy chủ web hiện đại đều sinh tự động cả tiêu đề
ETag và Last-Modified làm chỉ thị xác nhận cho các nội dung
tĩnh. Tuy vậy, không đủ thông tin về các nội dung động (như CGI, ASP và các
trang cở sở dữ liệu) để sinh tự động các tiêu đề này.
Thủ thuật xây dựng website hỗ trợ bộ đệm
Bên cạnh sử dụng tính mới và xác nhận, có một số
phương thức khác nhằm làm cho website của bạn thân thiện hơn với các bộ đệm.
Sử dụng các địa chỉ nhất quán – đây là quy tắc vàng trong lưu đệm. Nếu bạn
cung cấp cùng một nội dung tại những trang khác nhau, cho những người dùng khác
nhau, nó phải có cùng một địa chỉ. Đây là cách dễ nhất đồng thời hiệu quả nhất
để làm cho webiste của bạn thân thiện với các bộ đệm. Ví dụ, nếu bạn sử dụng
“/index.htm” trong mã HTML để chỉ liên kết tới trang chủ, hãy luôn làm như vậy.
Sử dụng thư viện hình ảnh chung – thư viện hình ảnh và các thành phần khác
phải được dùng chung. Các trang khác nhau sẽ cùng tham chiếu tới thư viện hình
ảnh này.
Giúp bộ đệm lưu các hình ảnh và các trang không thường xuyên thay đổi bằng
cách sử dụng tiêu đề Cache-Control: max-age có giá trị lớn.
Giúp bộ đệm nhận biết các trang thường xuyên thay đổi bằng cách chỉ định
max-age hoặc thời gian hiệu lực thích hợp.
Khi một tài nguyên (đặc biệt là các tệp tin) thay đổi, hãy đổi tên của nó.
Bằng cách này, bạn có thể đặt một thời gian hiệu lực lớn mà vẫn đảm bảo cung cấp
đúng phiên bản cần thiết. Chỉ các trang có liên kết tới các tài nguyên này cần
thiết lập thời gian hiệu lực ngắn.
Không thay đổi các tập tin không cần thiết. Nếu bạn thay đổi các tập tin
không cần thiết, chúng sẽ có thời gian Last-Modified không chính
xác. Do đó, khi cập nhật website, không nên sao chép toàn bộ website, mà chỉ nên
sao chép các tập tin có thay đổi.
Chỉ sử dụng cookie khi cần thiết – cookie rất khó lưu đệm, và thường không
phải cần thiết trong mọi tình huống. Nếu nhất thiết phải dùng cookie, hãy hạn
chế nó trong phạm vi các trang động mà thôi.
Giảm thiểu việc sử dụng SSL – do các trang mã hoá không được lưu bởi các bộ
đệm dùng chung, chỉ nên sử dụng SSL khi cần thiết.
Viết các đoạn mã hỗ trợ bỗ đệm
Theo mặc định, các mã lệnh kịch bản (script) thường không tự động trả về các chỉ
thị xác nhận (tiêu đề phản hồi Last-Modified hay
ETag) hoặc thông tin làm tươi (Expires hay
Cache-Control). Trong khi một số script là thực sự động (với nghĩa tạo ra
nội dung phản hồi khác nhau với các yêu cầu khác nhau), nhiều script như máy tìm
kiếm hoặc các website hướng cơ sở dữ liệu có thể thu được lợi ích thông qua việc
sử dụng bộ đệm.
Thông thường, nếu một script tạo ra một phản hồi mà phản hồi đó có thể tái sử
dụng cho cùng một yêu cầu như vậy nhưng được gửi sau một thời gian nhất định
(thời gian này có thể là vài phút hay vài ngày), thì script đó nên được lưu đệm.
Nếu kết quả của script thay đổi chỉ phụ thuộc vào địa chỉ URL, nó cũng nên lưu
đệm. Nếu kết quả đó phụ thuộc vào cookie hay các thông tin xác thực, hoặc các
tiêu chí khác, gần như chắc chắn là script đó không thể lưu đệm.
Cách tốt nhất để làm cho script thân thiện với bộ đệm (cũng đồng nghĩa với việc
thực thi nhanh hơn) là xuất nội dung kết quả của nó ra một tập tin tĩnh mỗi khi
có thay đổi. Từ đó, máy chủ Web xem tập tin tĩnh này như những trang web khác,
tự động sinh và sử dụng các chỉ thị xác nhận, và quá trình lưu đệm sẽ trở nên
đơn giản hơn. Hãy ghi nhớ chỉ ghi lại tập tin tĩnh khi cần để thời gian
Last-Modified không bị thay đổi một cách không cần thiết.
Một cách khác giúp script được lưu đệm là thiết đặt các tiêu đề liên quan tới
thời gian tồn tại của tài liệu. Mặc dù điều này có thể thực hiện được với
Expires, nhưng có lẽ cách tốt nhất là sử dụng Cache-Control:
max-age để đặt thông tin là mới trong một khoảng thời gian nhất định.
Nếu không thể thực hiện các phương pháp trên, cần viết các script để tự sinh chỉ
thị xác nhận, và phản hồi lại các yêu cầu If-Modified-Since hay
If-None-Match. Điều này có thể thực hiện được thông qua phân tích các tiêu
đề HTTP.
Một số thủ thuật khác:
Không sử dụng phương thức POST, trừ khi cần thiết. Phản hồi của các yêu cầu
dùng phương thức POST thường không được lưu bởi hầu hết các bộ đệm. Nếu thông
tin được gửi sử dụng phương thức GET, các bộ đệm sẽ lưu thông tin đó lại để sử
dụng về sau.
Không gắn các thông tin liên quan tới người dùng vào URL trừ khi nội dung
được yêu cầu liên hệ chặt chẽ với người dùng.
Sinh tiêu đề phản hồi Content-Length. Khá dễ để thực hiện điều này, nó cho
phép phản hồi của script được thực hiện trên một kết nối cố định. Điều này đảm
bảo cho máy khách yêu cầu nhiều nội dung trên cùng một kết nối TCP/IP thay vì
thiết lập một kết nối mới cho mỗi yêu cầu, kết quả là website của bạn sẽ hoạt
động nhanh lên khá nhiều./.
Anh Dũng
(Theo “Caching Tutorial for Web Authors and Webmasters”
http://www.mnot.net/cache_docs/
If you put 1.8 Volt e.g. at the lines 4 and 10, that LED (dot) will lit, the trick of multiplexing is to scan the columns (5) and set the data on the rows (7) (or visa-versa), the multiplex-frequency must be greater than approx. 40Hz else you will see the flickering of the LEDs to much (take about 5 msec per column, thats about 25 msec for one frame)
The scanning goes as follows, first set the rows data on the 7 rows e.g. 1010010, then activate (0 or 1 -> depends on which type CA = common cathode, or CC = common anode) the first column, now these LEDs (dots) will lit, wait 5 msec, then switch the column off, now load the next rows data, and set the second column on, wait 5 msecs again, and switch it off again, if you repeat this sequence very fast, you will see the data (character data) appear on the display (refresh frequency 40 - 70Hz is ok, don't take twice or half the artificial light-frequency of 50/60 Hz)
The rows data comes e.g. from the EEPROM or flash memory of the AVR, you can also take an external EEPROM/flash IC, the ATtiny2313 has 128 bytes EEPROM and 2k of flash memory, what you can do is put the character data (ASCII) into the flash memory (read below for more details) Next the test-diagram:
The 74HC595 is an 8-bit shift-register IC, with this IC you can shift 8 bits to the outputs with only 3 wires, that are Data (Ds), and 2 shift inputs (SHcp, STcp), connect like the diagram. How does the 74HC595 works? First shift the 8 bits into the stages with SHcp, then shift the stages to the outputs with STcp, this causes the outputs to switch in one go, with e.g. a 74HCT164 you can only shift the bits into the outputs, the advantage of the 74HC595 is the storage register. Don't forget that multiplexing causes the LEDs only lit up for a fraction, so if you want the same intensity you must put more current through them, this diagram is for practice and programming, wants you have it working you can put transistors and resistors on. Here I put the letter R on the display as you can see, using a little breadboard: (next: How the scrolling is done...)
How to scroll a character accross the display ? The trick is to build one character on the display by scanning the columns very fast, and let say each 20 times (20 frames) scroll it one position to the left, this will give the effect of a walking text accross the dot-matrix display. So first build one frame, repeat this 20 times, and after that, read the data one address later, if you do this 5 times (5 columns) the character scroll from right to left from the display. (the refresh goes so fast that your brain can't keep up, and what you see is the R scrolling over the display) Btw, I will take five 74HC595's shiftregisters IC's, that are 5 x 8 bit = 40 bits / 5 columns = 8 dot-matrix displays, making it a nice tiny message sign.
What I am going to do is putting ASCII data (thats 128 x 5 bytes = 640 bytes) into the 2k flash memory of the ATtiny2313, then I have 704 words left for my program, that can really be a huge program!, because I used only 69 lines (69 instructions) of program so far, and that scrolls characters fluently accross the dot-matrix display. I made the program so that you can set the scroll-speed, from 0 - 255, so 256 speeds, 25 fps (frames/second) is a nice speed. On one of my pages (this page) I am using a 2-bit Gray code rotary encoder, with this encoder I will make an edit function in the software, so you can edit messages, without a keyboard, this save space, this type of rotary encoder has a push-function in the shaft, so e.g. after you select a character you can store that in memory
