• If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.
Xin chào ! Nếu đây là lần đầu tiên bạn đến với diễn đàn, xin vui lòng danh ra một phút bấm vào đây để đăng kí và tham gia thảo luận cùng VnPro.

Announcement

Collapse
No announcement yet.

Web Caching trong active network

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Web Caching trong active network

    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
    Email : vnpro@vnpro.org
    ---------------------------------------------------------------------------------------------------------------
Trung Tâm Tin Học VnPro
149/1D Ung Văn Khiêm P25 Q.Bình thạnh TPHCM
Tel : (08) 35124257 (5 lines)
Fax: (08) 35124314

Home page: http://www.vnpro.vn
Support Forum: http://www.vnpro.org
- Chuyên đào tạo quản trị mạng và hạ tầng Internet
- Phát hành sách chuyên môn
- Tư vấn và tuyển dụng nhân sự IT
- Tư vấn thiết kế và hỗ trợ kỹ thuật hệ thống mạng

Network channel: http://www.dancisco.com
Blog: http://www.vnpro.org/blog

  • #2
    (tt)

    Vì yêu cầu trong suốt LC server phải có khả năng truy cập vào những yêu cầu không phải cho nó, để có thể kiểm soát được các yêu cầu được gửi từ client đến server. Khi yeu cầu được đọc bởi LC server thì nó có thể xử lý theo 2 cách khác nhau tuỳ thuộc vào giao thức giao tiếp giữa client và server. Nếu giao thức đó là phi kết nối (connectionless) thì yêu cầu có thể được forward thẳng đến server gốc. Còn nếu giao thức đó là hướng kết nối thì LC server phải duy trì thông tin về trạng thái của kết nối khi kết nối giữa client và server gốc được thiết lập trước khi yêu cầu được gửi bởi client. Ngoài ra, LC server phải có thể can thiệp vào yêu cầu. Khi client cố thiết lập một kết nối đến server gốc, thì LC server sẽ kiểm soát kết nối và hoàn tất quá trình bắt tay 3 bước, và do kết nối đến server gốc được thiết lập bởi LC server nên các response sẽ được gửi trực tiếp đến nó.

    7.3.2.2. Xử lý các yêu cầu

    Thông tin đạt được từ việc kiểm soát các yêu cầu và trả lời trên mạng có thể được sử dụng để báo cho client biết là một object được yêu cầu có đã được cache ở một client khác hay không. Tùy thuộc vào loại giao thức giao tiếp và các thuộc tính của các client trong mạng, thì nhiệm vụ này có thể được xử lý khác nhau.

    Mặc dù LC phải hoạt động một cách trong suốt với client và server thì giao thức giao tiếp của các client có thể sẽ không thể xử lý một trả lời với nội dung khác với object được yêu cầu. Nghĩa là LC server không thể luôn luôn trả lời một yêu cầu bằng một redirect đến nơi mà nó có thể tìm thấy object đó. Ngoài ra, thông tin thu được ở LC server có thể sẽ vô ích nếu các object trong mạng cục bộ không thể được truy cập. Sau đây, ta sẽ giả sử rằng các client có thể được mở rộng với một dịch vụ cho phép các host khác truy cập vào các object được cache cục bộ của nó. Tuỳ thuộc vào độ linh hoạt được yeu cầu từ client, thì dịch vụ có thể chỉ l1 một “add-on” đơn giản được cài vào trong client. Một giải pháp tạm thời là sử dụng một file-server làm cache khi số client cung cấp dịch vụ caching không đủ. Giả sử một client bình thường yêu cầu một object mà LC server biết là nó đang nằm ở một trong cố các active client.



    Hình 7. 5 Quá trình gửi yêu cầu từ client

    7.4. Bài toán và vấn đề liên quan:


    Khi Internet ngày càng phát triển, thì các luồng traffic web ngày càng tăng lên với một tốc độ chóng mặt, vấn đề đặt ra là làm sao để tăng hiệu suất của web và giảm các web traffic trên các liên kết WAN. Giải pháp là sử dụng các kỹ thuật caching để có thể tăng được hiệu suất.
    Chúng ta sử dụng caching vì 3 mục đích sau: giảm độ trễ của các yêu cầu của client, tải trên các web server sẽ được giảm xuống, và việc sử dụng băng thông trên mạng WAN được giảm xuống (như đã trình bày ở trên). Các nỗ lực trước đây đã tăng hiệu suất của client nhằm tránh việc truyền dư thừa (caching ở phía client, transparent caching như đã trình bày ở trên) và hướng dẫn lại các yêu cầu qua một agent cục bộ để cải thiện việc cân bằng tải (proxy caching).

    Để cải thiện hơn nữa việc caching, việc cần thiết là làm sao để chia sẻ thông tin giữa các cache ở những vị trí khác nhau trong mạng. Bài toán chính là: làm cách nào để xác định vị trí của một bản sao của tài liệu bằng cách tìm kiếm qua các cache, và cách nào để phân phát các tài liệu đến những cache cho những yêu cầu trong tương lai. Cả 2 vấn đề có thể được giải quyết bằng kỹ thuật định tuyến các yêu cầu và trả lời web qua một mạng chia sẽ của các cache. Vì hiệu suất có mối liên hệ với mô hình mạng nằm bên dưới, nên sẽ tự nhiên hơn nếu kết hợp việc tìm cache với việc định tuyến gói tin. Điều này tương phản với các hệ thống hiện tại là xây dựng một mô hình chồng lấp các cache node. Có thể tăng hiệu suất bằng cách bỏ qua overhead của các tầng và sự duy trì các packet ở tầng network. Chiến lược đơn giản này cũng có thể đạt được bằng cách sử dụng các đường tìm cache có hiệu quả về cost với cùng một cách như các multicast route dựa trên các đường ngắn nhất như PIM, được xem là khả thi trong thực tế.

    Bài toán mà ta giải quyết ở đây là làm cách nào để kiểm soát việc tìm kiếm cache một cách tổng thể và việc thay thế các đường với một dịch vụ mạng mới có thể kết hợp giữa định tuyến và caching. Bên cạch đó, bài toán này không hoàn toàn phù hợp với một dịch vụ ANTS gốc. Vì các cache node yêu cầu một lượng lớn lưu trữ (thường được cung cấp bởi các dĩa) và khả năng hỗ trợ các kết nối tin cậy. Thay vào đó, ta giả sử rằng các cache node sẽ được kết hợp vào cấu trúc mạng ở những điểm được chọn, như ở những liên kết truy cập, ISP, và các điểm trao đổi. Điều này đã xảy ra ngày nay rồi. Bài toán phải được giải quyết và phải thiết kế một dịch vụ có thể tận dụng được những lợi ích của những cache này như là một phần của một dịch vụ mạng mới.

    7.5. Thiết kế dịch vụ:

    Để cung cấp một dịch vụ caching, thì ta phải thiết kế 2 chức năng chính: phải có cách nào cho những yêu cầu web có thể xác định những đối tượng trong các cache có khoảng cách về đường đi ngắn hơn đường mà nó phải theo để đến server. Và ở chiều ngược lại thì cũng phải có cách nào cho những web response truyền những đối tượng đến cùng những cache này để chúng có thể phục vụ cho những yêu cầu tương tự trong tương lai. Việc thiết kế cho những kỹ thuật này phải thỏa mãn 2 mục đích.
    Đầu tiên, ảnh hưởng của nó đến hiệu suất của mạng hiện tại phải là nhỏ nhất. Điều này có thể đạt được bằng cách xác định những xử lý của mạng chỉ cho các gói tin yêu cầu và phản hồi giúp thiết lập các kết nối truyền dữ liệu chứ không phải chính việc truyền dữ liệu, nghĩa là chỉ cho những gói tin truyền tín hiệu. Sau đó, việc truyền dữ liệu sẽ được xử lý ở tốc độ toàn bộ mà không cần thêm những xử lý ở bên trong mạng. Chiến lược này tương phản với những sản phẩm hiện tại, trong đó, việc tương thích ngược yêu cầu rằng tất cả packet được xử lý ở mỗi router đã được sửa đổi.
    Thứ hai, những ảnh hưởng đến độ tin cậy của web phải là nhỏ nhất. Sự hư hỏng của cache hay các acitve node không nên ảnh hưởng đến sự sẵn sàng của một đối tượng web. Điều này có thể đạt được bằng cách sử dụng default routing (sẽ định tuyến quanh các node bị trục trặc) và có một cặp cache/active node hoạt động phối hợp với nhau. Trong ANTS, dịch vụ tạo thành sẽ có 4 loại capsule cùng phối hợp hoạt động, mỗi loại sẽ xây dựng code group của chính chúng:

    • Bind capsule được trao đổi giữa cache và active node tương ứng của nó để đồng bộ hóa các trạng thái của chúng.
    • Query capsule được các client gửi đến server. Khi đi trên đường, chúng sẽ gặp các cache có một bản sao của tài liệu mà chúng đang yêu cầu, lúc đó chúng sẽ hướng sang hướng khác.
    • Redirect capsule khởi tạo một kết nối giữa server (hay upstream cache) và một client (hay một downstream cache) vì mục đích truyền một tài liệu và redirect các yêu cầu tiếp theo.
    • Activate capsule sẽ ngắt kết nối giữa client (hay downstream cache) và server (hay upstream cache) ngay khi việc truyền dữ liệu đã hoànn tất và trạng thái redirection đã được thiết lập.

    Bên cạnh đó, những gói tin bình thường không yêu cầu những xử lý đặc biệt sẽ được trao đổi giữa downstream cache và client để truyền các trang web. Để mô tả việc xử lý mạng của mỗi loại capsule một cách đầy đủ hơn, ta sẽ xét trường hợp sau. Nó dựa trên việc tổ chức các chức năng caching trong mạng thành các cache và các active node. Mỗi cache node được kết hợp với các active node trong các phần của mạng mà nó phục vụ. Mỗi active node tương ứng sẽ duy trì một bảng các nội dung cache trong soft-store của nó. Nó sử dụng bảng này để quyết định có chuyển hướng các yêu cầu web cho cache node ra khỏi đường ngắn nhất đến server hay không.
    Trước khi một cache có thể được sử dụng bởi dịch vụ web caching của ANTS thì nó phải thiết lập liên hệ với những active node ở gần với nó. Điều này được thực hiện với bind capsule. Mục đích của nó là ràng buộc cache và active node thành một đơn vị đơn để hoạt động.



    Hình 7. 6 Bind capsule processing

    Và sau đây là mã giả của nó:
    public boolean bound; // latched the active node
    public long epoch; // web cache generation
    public int interval; // binding timeout
    public boolean evaluate(Node n) {
    // continue until we reach the active node or the cache
    if (n.getAddress() != getDst()) return n.routeForNode(this, getDst());
    if (!bound) {
    // bind node to cache by entering its details in the soft-store
    Object[] binding = new Object[2];
    binding[0] = new Long(epoch);
    binding[1] = new Integer(getSrc());
    n.getCache().put("CACHE", binding, 3*interval);
    // now alter capsule and return to cache for synchronization
    setDst(getSrc());
    bound = true;
    if (n.getAddress() != getDst()) return n.routeForNode(this, getDst());
    }
    // we are back at the cache
    return n.deliverToApp(this, dpt);
    }
    Email : vnpro@vnpro.org
    ---------------------------------------------------------------------------------------------------------------
    Trung Tâm Tin Học VnPro
    149/1D Ung Văn Khiêm P25 Q.Bình thạnh TPHCM
    Tel : (08) 35124257 (5 lines)
    Fax: (08) 35124314

    Home page: http://www.vnpro.vn
    Support Forum: http://www.vnpro.org
    - Chuyên đào tạo quản trị mạng và hạ tầng Internet
    - Phát hành sách chuyên môn
    - Tư vấn và tuyển dụng nhân sự IT
    - Tư vấn thiết kế và hỗ trợ kỹ thuật hệ thống mạng

    Network channel: http://www.dancisco.com
    Blog: http://www.vnpro.org/blog

    Comment

    • Working...
      X