Tác giả:
+ Lê Anh Đức
+ Ngô Tự Nhiên
7.1. Các đặc tính của Web traffic
Khi người dùng yêu cầu một tài liệu xác định, thì cái trả về không chỉ bao gồm cái tài liệu gốc, mà còn có các đối tượng được nhúng vào trong tài liệu đó. Để có thể dễ dàng phân biệt các đối tượng khác nhau thì mỗi đối tượng sẽ là loại sử dụng một mime-type, ví dụ: image/gif cho một hình ảnh ở định dạng gif. Ngày nay khi web được sử dụng ngày càng nhiều cho mục đích thương mại thì các trang web sẽ chứa nhiều các đối tượng đa phương tiện.
Hình 7. 1 Minh họa Caching
Do đó, không chỉ cache các tài liệu mà còn cache các đối tượng được nhúng trong đó. Trong thực tế, khi nhìn vào các mime-type của các đối tượng được yêu cầu, sự phân tích các HTTP traffic ở một web server chỉ ra rằng có khoảng 67% các file là ở dạng JPEG hay GIF, cùng với các trang HTML thì đây là 3 loại mime-type phổ biến nhất.
Khi phân tích thêm thì ta thấy kích thước file trung bình của một trang HTML được yêu cầu và các GIF image là: 5.6 Kb và 4.1Kb, và của JPEG là: 12.8Kb. Cache có thể ưu tiên hoá việc cache các đối tượng web sẽ tùy thuộc vào mime-type của nó, kích thước hay một số đặc tính khác có thể được tìm thấy ở những đối tượng được yêu cầu thường xuyên.
Hình 7. 2 Đồ thị thể hiện ưu tiên giữa các đối tượng cache
Trước khi trình bày vầ cách mà caching được triển khai trong mạng internet ngày nay thì phần sau sẽ trình bày cách mà giao thức HTTP hỗ trợ caching như thế nào.
7.2. Caching được hỗ trợ trong HTTP
Mặc dù caching có thể được giới thiệu vào các môi trường mà không gây bất kỳ sự thay đổi nào cho giao thức chạy bên dưới, nhưng khi caching được thêm vào thì một giao thức sẽ có tác động đến sự giao tiếp giữa client và server.
Trong HTTP phiên bản 1.0, chỉ có 1 phần nhỏ có thể hỗ trợ caching cùng với một số các chỉ dẫn đơn giản để xác định đối tượng nào sẽ không được cache. Do đó, HTTP/1.1 ra đời, trong phiên bản này thì yeu cầu caching được mô tả trực tiếp và nó hỗ trợ nhiều chức năng caching hơn qua các trường caching trong header.
Vì các yêu cầu các đối tượng với các thông tin động hay những thông tin riêng tư, các cache không phải lúc nào cũng cho phép lưu các đối tượng vào cache. Các đối tượng động như các yêu cầu người dùng cung cấp các thông số hay các yêu cầu chỉ vào một đoạn script sẽ không được cache. Vì những trã lời không đảm bảo là giống nhau qua mỗi lần yêu cầu. Hay các đối tượng được đánh dấu là riêng tư sẽ không được cache vì lý do bảo mật, vì chúng có thể chứa các thông tin xác thực hay chỉ có thể truy cập được qua việc xác thực. Một cache phải có khả năng biết được response nào có thể được cho phép cache bằng cách phân tích trạng thái code của response. HTTP sẽ chứa một danh sách các status code tương ứng với các response mà chúng có thể được cache, và những response này được gọi là cachable.
Một đối tượng khi cache sẽ có thêm một thông số là thời gian expire. Thông tin này có thể được sử dụng để xác định khi nào thì một đối tượng trong cache có thể đã cũ, do đó có thể giảm số lần yêu cầu đối tượng đến server gốc. Bên cạnh đó, các giá trị validator được sử dụng kết hợp với các yêu cầu để xác định xem một đối tượng được yêu cầu có mới hơn cái đang được lưu trong cache hay không. Cả hai giá trị này đều giúp giảm traffic trên mạng.
Nếu một trường Expire được cung cấp bởi một response thì giá trị ngày sẽ giúp xác định khi nào thì đối tượng đó được xem như đã cũ. Sau khoảng thời gian đó, thì đối tượng sẽ không được sử dụng để trả lời cho những yêu cầu nữa trừ khi chúng được làm mới lại. Tuy nhiên trong một số trường hợp khi client cho phép những đối tượng cũ được truyền thì cache có thể truyền. Expire date cũng được xem như là TTL. Để làm mới lại đối tượng thì cache phải kiểm tra server gốc. Lúc đó nó sẽ gửi lệnh GET với một trường được gọi là cache validator đến server gốc. Khi một server gửi response nó sẽ gắn thêm một validator vào đó, cái này sẽ được lưu cùng với object trong cache. Khi client cần kiểm tra server để lấy một đối tượng được update thì validator sẽ được gửi cùng với yêu cầu có điều kiện và server sẽ kiểm tra validator. Một validator thường được sử dụng là trường Last-Modified. Để làm mới một đối tượng trong cache thì yêu cầu có điều kiện có thể chứa trường If-Modified-Since với giá trị của trường Last-Modified. Server sẽ response cho yêu cầu đó với một status code đặc biệt là “Not Modified” hay nó sẽ trả về toàn bộ đối tượng đó. Validator này chỉ được hỗ trợ trong HTTP/1.0.
Về cơ bản, thì các chỉ thị kiểm soát có thể được phân loại thành 4 nhóm, có thể được client hay server gốc sử dụng:
• Các hạn chế xem cái gì có thể cache. (chỉ server là được sử dụng)
• Các hạn chế xem cái gì có thể được lưu.
• Các kỹ thuật expire.
• Làm mới lại cache.
Sau đây là lược đồ của một cache server khi nhận được một yêu cầu từ một client:
Mặc dù caching có thể được giới thiệu vào các môi trường mà không gây bất kỳ sự thay đổi nào cho giao thức chạy bên dưới, nhưng khi caching được thêm vào thì một giao thức sẽ có tác động đến sự giao tiếp giữa client và server.
Trong HTTP phiên bản 1.0, chỉ có 1 phần nhỏ có thể hỗ trợ caching cùng với một số các chỉ dẫn đơn giản để xác định đối tượng nào sẽ không được cache. Do đó, HTTP/1.1 ra đời, trong phiên bản này thì yeu cầu caching được mô tả trực tiếp và nó hỗ trợ nhiều chức năng caching hơn qua các trường caching trong header.
Vì các yêu cầu các đối tượng với các thông tin động hay những thông tin riêng tư, các cache không phải lúc nào cũng cho phép lưu các đối tượng vào cache. Các đối tượng động như các yêu cầu người dùng cung cấp các thông số hay các yêu cầu chỉ vào một đoạn script sẽ không được cache. Vì những trã lời không đảm bảo là giống nhau qua mỗi lần yêu cầu. Hay các đối tượng được đánh dấu là riêng tư sẽ không được cache vì lý do bảo mật, vì chúng có thể chứa các thông tin xác thực hay chỉ có thể truy cập được qua việc xác thực. Một cache phải có khả năng biết được response nào có thể được cho phép cache bằng cách phân tích trạng thái code của response. HTTP sẽ chứa một danh sách các status code tương ứng với các response mà chúng có thể được cache, và những response này được gọi là cachable.
Một đối tượng khi cache sẽ có thêm một thông số là thời gian expire. Thông tin này có thể được sử dụng để xác định khi nào thì một đối tượng trong cache có thể đã cũ, do đó có thể giảm số lần yêu cầu đối tượng đến server gốc. Bên cạnh đó, các giá trị validator được sử dụng kết hợp với các yêu cầu để xác định xem một đối tượng được yêu cầu có mới hơn cái đang được lưu trong cache hay không. Cả hai giá trị này đều giúp giảm traffic trên mạng.
Nếu một trường Expire được cung cấp bởi một response thì giá trị ngày sẽ giúp xác định khi nào thì đối tượng đó được xem như đã cũ. Sau khoảng thời gian đó, thì đối tượng sẽ không được sử dụng để trả lời cho những yêu cầu nữa trừ khi chúng được làm mới lại. Tuy nhiên trong một số trường hợp khi client cho phép những đối tượng cũ được truyền thì cache có thể truyền. Expire date cũng được xem như là TTL. Để làm mới lại đối tượng thì cache phải kiểm tra server gốc. Lúc đó nó sẽ gửi lệnh GET với một trường được gọi là cache validator đến server gốc. Khi một server gửi response nó sẽ gắn thêm một validator vào đó, cái này sẽ được lưu cùng với object trong cache. Khi client cần kiểm tra server để lấy một đối tượng được update thì validator sẽ được gửi cùng với yêu cầu có điều kiện và server sẽ kiểm tra validator. Một validator thường được sử dụng là trường Last-Modified. Để làm mới một đối tượng trong cache thì yêu cầu có điều kiện có thể chứa trường If-Modified-Since với giá trị của trường Last-Modified. Server sẽ response cho yêu cầu đó với một status code đặc biệt là “Not Modified” hay nó sẽ trả về toàn bộ đối tượng đó. Validator này chỉ được hỗ trợ trong HTTP/1.0.
Về cơ bản, thì các chỉ thị kiểm soát có thể được phân loại thành 4 nhóm, có thể được client hay server gốc sử dụng:
• Các hạn chế xem cái gì có thể cache. (chỉ server là được sử dụng)
• Các hạn chế xem cái gì có thể được lưu.
• Các kỹ thuật expire.
• Làm mới lại cache.
Sau đây là lược đồ của một cache server khi nhận được một yêu cầu từ một client:
Hình 7. 3 Lược đồ cache server khi nhận được một yêu cầu từ một client.
7.3. Location caching
Thuật ngữ “Location caching” được đề cập đến một cách ngắn gọn như là cách để kiểm soát và caching thông tin về các đối tượng trên mạng.
7.3.1. Động cơ:
Ý tưởng của location caching được thúc đẩy từ ý tưởng là có thể kiểm soát network traffic từ client đến server một cách trong suốt, và do đó có thể xác định được object nào có thể được cache bởi các client trong mạng cục bộ. Nếu một client đang yêu cầu một object, thì location caching có thể can thiệp vào yêu cầu đó và thực hiện hành động phù hợp để client có thể lấy được object đó từ mạng cục bộ.
7.3.2 Nguyên lý của Location Cachine:
Host chạy kỹ thuật LC sẽ được gọi là “LC server”. Trách nhiệm của server này được chia làm 2 nhiệm vụ tách biệt: nó phải có khả năng kiểm soát các object trong mạng cục bộ một cách trong suốt, và nó phải có khả năng xử lý các yêu cầu của client một cách thông minh.
7.3.2.1. Kiểm soát
LC server phải trong suốt với client và nó phải có khả năng kiểm soát tất cả các yêu cầu và trả lời trên mạng. Khi một client gửi một yêu cầu đến một server thì yêu cầu sẽ được đọc bởi LC server và khi response được gửi về cho client bởi server gốc thì LC server phải cache thông tin như ID của object và ID của client.
Hình 7. 4 Minh họa cho Location Cache Server
+ Lê Anh Đức
+ Ngô Tự Nhiên
7.1. Các đặc tính của Web traffic
Khi người dùng yêu cầu một tài liệu xác định, thì cái trả về không chỉ bao gồm cái tài liệu gốc, mà còn có các đối tượng được nhúng vào trong tài liệu đó. Để có thể dễ dàng phân biệt các đối tượng khác nhau thì mỗi đối tượng sẽ là loại sử dụng một mime-type, ví dụ: image/gif cho một hình ảnh ở định dạng gif. Ngày nay khi web được sử dụng ngày càng nhiều cho mục đích thương mại thì các trang web sẽ chứa nhiều các đối tượng đa phương tiện.
Hình 7. 1 Minh họa Caching
Do đó, không chỉ cache các tài liệu mà còn cache các đối tượng được nhúng trong đó. Trong thực tế, khi nhìn vào các mime-type của các đối tượng được yêu cầu, sự phân tích các HTTP traffic ở một web server chỉ ra rằng có khoảng 67% các file là ở dạng JPEG hay GIF, cùng với các trang HTML thì đây là 3 loại mime-type phổ biến nhất.
Khi phân tích thêm thì ta thấy kích thước file trung bình của một trang HTML được yêu cầu và các GIF image là: 5.6 Kb và 4.1Kb, và của JPEG là: 12.8Kb. Cache có thể ưu tiên hoá việc cache các đối tượng web sẽ tùy thuộc vào mime-type của nó, kích thước hay một số đặc tính khác có thể được tìm thấy ở những đối tượng được yêu cầu thường xuyên.
Hình 7. 2 Đồ thị thể hiện ưu tiên giữa các đối tượng cache
Trước khi trình bày vầ cách mà caching được triển khai trong mạng internet ngày nay thì phần sau sẽ trình bày cách mà giao thức HTTP hỗ trợ caching như thế nào.
7.2. Caching được hỗ trợ trong HTTP
Mặc dù caching có thể được giới thiệu vào các môi trường mà không gây bất kỳ sự thay đổi nào cho giao thức chạy bên dưới, nhưng khi caching được thêm vào thì một giao thức sẽ có tác động đến sự giao tiếp giữa client và server.
Trong HTTP phiên bản 1.0, chỉ có 1 phần nhỏ có thể hỗ trợ caching cùng với một số các chỉ dẫn đơn giản để xác định đối tượng nào sẽ không được cache. Do đó, HTTP/1.1 ra đời, trong phiên bản này thì yeu cầu caching được mô tả trực tiếp và nó hỗ trợ nhiều chức năng caching hơn qua các trường caching trong header.
Vì các yêu cầu các đối tượng với các thông tin động hay những thông tin riêng tư, các cache không phải lúc nào cũng cho phép lưu các đối tượng vào cache. Các đối tượng động như các yêu cầu người dùng cung cấp các thông số hay các yêu cầu chỉ vào một đoạn script sẽ không được cache. Vì những trã lời không đảm bảo là giống nhau qua mỗi lần yêu cầu. Hay các đối tượng được đánh dấu là riêng tư sẽ không được cache vì lý do bảo mật, vì chúng có thể chứa các thông tin xác thực hay chỉ có thể truy cập được qua việc xác thực. Một cache phải có khả năng biết được response nào có thể được cho phép cache bằng cách phân tích trạng thái code của response. HTTP sẽ chứa một danh sách các status code tương ứng với các response mà chúng có thể được cache, và những response này được gọi là cachable.
Một đối tượng khi cache sẽ có thêm một thông số là thời gian expire. Thông tin này có thể được sử dụng để xác định khi nào thì một đối tượng trong cache có thể đã cũ, do đó có thể giảm số lần yêu cầu đối tượng đến server gốc. Bên cạnh đó, các giá trị validator được sử dụng kết hợp với các yêu cầu để xác định xem một đối tượng được yêu cầu có mới hơn cái đang được lưu trong cache hay không. Cả hai giá trị này đều giúp giảm traffic trên mạng.
Nếu một trường Expire được cung cấp bởi một response thì giá trị ngày sẽ giúp xác định khi nào thì đối tượng đó được xem như đã cũ. Sau khoảng thời gian đó, thì đối tượng sẽ không được sử dụng để trả lời cho những yêu cầu nữa trừ khi chúng được làm mới lại. Tuy nhiên trong một số trường hợp khi client cho phép những đối tượng cũ được truyền thì cache có thể truyền. Expire date cũng được xem như là TTL. Để làm mới lại đối tượng thì cache phải kiểm tra server gốc. Lúc đó nó sẽ gửi lệnh GET với một trường được gọi là cache validator đến server gốc. Khi một server gửi response nó sẽ gắn thêm một validator vào đó, cái này sẽ được lưu cùng với object trong cache. Khi client cần kiểm tra server để lấy một đối tượng được update thì validator sẽ được gửi cùng với yêu cầu có điều kiện và server sẽ kiểm tra validator. Một validator thường được sử dụng là trường Last-Modified. Để làm mới một đối tượng trong cache thì yêu cầu có điều kiện có thể chứa trường If-Modified-Since với giá trị của trường Last-Modified. Server sẽ response cho yêu cầu đó với một status code đặc biệt là “Not Modified” hay nó sẽ trả về toàn bộ đối tượng đó. Validator này chỉ được hỗ trợ trong HTTP/1.0.
Về cơ bản, thì các chỉ thị kiểm soát có thể được phân loại thành 4 nhóm, có thể được client hay server gốc sử dụng:
• Các hạn chế xem cái gì có thể cache. (chỉ server là được sử dụng)
• Các hạn chế xem cái gì có thể được lưu.
• Các kỹ thuật expire.
• Làm mới lại cache.
Sau đây là lược đồ của một cache server khi nhận được một yêu cầu từ một client:
Mặc dù caching có thể được giới thiệu vào các môi trường mà không gây bất kỳ sự thay đổi nào cho giao thức chạy bên dưới, nhưng khi caching được thêm vào thì một giao thức sẽ có tác động đến sự giao tiếp giữa client và server.
Trong HTTP phiên bản 1.0, chỉ có 1 phần nhỏ có thể hỗ trợ caching cùng với một số các chỉ dẫn đơn giản để xác định đối tượng nào sẽ không được cache. Do đó, HTTP/1.1 ra đời, trong phiên bản này thì yeu cầu caching được mô tả trực tiếp và nó hỗ trợ nhiều chức năng caching hơn qua các trường caching trong header.
Vì các yêu cầu các đối tượng với các thông tin động hay những thông tin riêng tư, các cache không phải lúc nào cũng cho phép lưu các đối tượng vào cache. Các đối tượng động như các yêu cầu người dùng cung cấp các thông số hay các yêu cầu chỉ vào một đoạn script sẽ không được cache. Vì những trã lời không đảm bảo là giống nhau qua mỗi lần yêu cầu. Hay các đối tượng được đánh dấu là riêng tư sẽ không được cache vì lý do bảo mật, vì chúng có thể chứa các thông tin xác thực hay chỉ có thể truy cập được qua việc xác thực. Một cache phải có khả năng biết được response nào có thể được cho phép cache bằng cách phân tích trạng thái code của response. HTTP sẽ chứa một danh sách các status code tương ứng với các response mà chúng có thể được cache, và những response này được gọi là cachable.
Một đối tượng khi cache sẽ có thêm một thông số là thời gian expire. Thông tin này có thể được sử dụng để xác định khi nào thì một đối tượng trong cache có thể đã cũ, do đó có thể giảm số lần yêu cầu đối tượng đến server gốc. Bên cạnh đó, các giá trị validator được sử dụng kết hợp với các yêu cầu để xác định xem một đối tượng được yêu cầu có mới hơn cái đang được lưu trong cache hay không. Cả hai giá trị này đều giúp giảm traffic trên mạng.
Nếu một trường Expire được cung cấp bởi một response thì giá trị ngày sẽ giúp xác định khi nào thì đối tượng đó được xem như đã cũ. Sau khoảng thời gian đó, thì đối tượng sẽ không được sử dụng để trả lời cho những yêu cầu nữa trừ khi chúng được làm mới lại. Tuy nhiên trong một số trường hợp khi client cho phép những đối tượng cũ được truyền thì cache có thể truyền. Expire date cũng được xem như là TTL. Để làm mới lại đối tượng thì cache phải kiểm tra server gốc. Lúc đó nó sẽ gửi lệnh GET với một trường được gọi là cache validator đến server gốc. Khi một server gửi response nó sẽ gắn thêm một validator vào đó, cái này sẽ được lưu cùng với object trong cache. Khi client cần kiểm tra server để lấy một đối tượng được update thì validator sẽ được gửi cùng với yêu cầu có điều kiện và server sẽ kiểm tra validator. Một validator thường được sử dụng là trường Last-Modified. Để làm mới một đối tượng trong cache thì yêu cầu có điều kiện có thể chứa trường If-Modified-Since với giá trị của trường Last-Modified. Server sẽ response cho yêu cầu đó với một status code đặc biệt là “Not Modified” hay nó sẽ trả về toàn bộ đối tượng đó. Validator này chỉ được hỗ trợ trong HTTP/1.0.
Về cơ bản, thì các chỉ thị kiểm soát có thể được phân loại thành 4 nhóm, có thể được client hay server gốc sử dụng:
• Các hạn chế xem cái gì có thể cache. (chỉ server là được sử dụng)
• Các hạn chế xem cái gì có thể được lưu.
• Các kỹ thuật expire.
• Làm mới lại cache.
Sau đây là lược đồ của một cache server khi nhận được một yêu cầu từ một client:
Hình 7. 3 Lược đồ cache server khi nhận được một yêu cầu từ một client.
7.3. Location caching
Thuật ngữ “Location caching” được đề cập đến một cách ngắn gọn như là cách để kiểm soát và caching thông tin về các đối tượng trên mạng.
7.3.1. Động cơ:
Ý tưởng của location caching được thúc đẩy từ ý tưởng là có thể kiểm soát network traffic từ client đến server một cách trong suốt, và do đó có thể xác định được object nào có thể được cache bởi các client trong mạng cục bộ. Nếu một client đang yêu cầu một object, thì location caching có thể can thiệp vào yêu cầu đó và thực hiện hành động phù hợp để client có thể lấy được object đó từ mạng cục bộ.
7.3.2 Nguyên lý của Location Cachine:
Host chạy kỹ thuật LC sẽ được gọi là “LC server”. Trách nhiệm của server này được chia làm 2 nhiệm vụ tách biệt: nó phải có khả năng kiểm soát các object trong mạng cục bộ một cách trong suốt, và nó phải có khả năng xử lý các yêu cầu của client một cách thông minh.
7.3.2.1. Kiểm soát
LC server phải trong suốt với client và nó phải có khả năng kiểm soát tất cả các yêu cầu và trả lời trên mạng. Khi một client gửi một yêu cầu đến một server thì yêu cầu sẽ được đọc bởi LC server và khi response được gửi về cho client bởi server gốc thì LC server phải cache thông tin như ID của object và ID của client.
Hình 7. 4 Minh họa cho Location Cache Server
Comment