Bộ đệm Web (Web Caching)

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 và Akamai 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 để 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.

PhanNhutThanh(I22A) đã viết: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 và Akamai 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 để 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.

Bạn cho mình hỏi về sự khác biệt giữa 2 phương thức POST và GET là như thế nào được không?

Tuy vấn đề không liên quan tới bài mình post nhiều lắm, nhưng mình cũng trả lời bạn luôn.

Trong lập trình web. Để xử lý việc nhận gửi thông tin từ 1 form của người dùng nhập vào là rất thường xuyên. Chúng ta thường sử dụng 2 phương thức POST và GET. Tuy nhiên lúc nào sử dụng POST, lúc nào sử dụng GET ? Câu hỏi đó tưởng như dễ trả lời nhưng có ai dzam chắc chắn rằng mình đã hiểu rõ hết nó vì có những cái chúng ta thường xuyên dùng 1 cách thói quen, chỉ biết dùng sao cũng chạy cả nên rất ít người hiểu rõ và trả lời được câu hỏi này.
Sau đây là sự giống nhau và khác biệt giữa chúng.

*Giống nhau: Đều gửi dữ liệu tới server để xử lý, sau khi người dùng nhập thông tin vào Form
*Khác nhau:
**POST:Bảo mật hơn GET vì dữ liệu được gửi ngầm, không xuất hiện trên URL
**GET:Dữ liệu được gửi tường minh, chúng ta có thể nhìn thấy trên URL, đây là lý do khiến nó không bảo mật so với POST. Nó còn bị giới hạn số ký tự bởi URL của web browsers.

**GET thực thi nhanh hơn POST vì nhứng dữ liệu gủi đi luôn được Webbrowser cached lại

**Khi dùng phương thức POST thì server luôn thực thi và trả về kết quả cho client, còn phương thức GET ứng với cùng 1 yêu cầu đó webbrowser sẽ xem trong cached có kết quả tương ứng với yêu cầu đó ko và trả về ngay không cần phải thực thi các yêu cầu đó ở phía server

** Đối với những dữ liệu luôn được thay đổi thì chúng ta nên sử dụng phương thức POST, còn dữ liệu ít thay đổi chúng ta dùng phương thức GET để truy xuất và xử lý nhanh hơn.