DNS server có thẩm quyền có thể trả lại địa chỉ của nhiều server sao lưu tới các DNS server bên client. DNS server bên client có thể sử dụng lần lượt các địa chỉ đó trong mô hình robin để định tuyến các yêu cầu từ các client khác nhau về cùng một nội dung tới các server sao lưu khác nhau. Kỹ thuật này làm tăng độ tin cậy và cân bằng tải trong mạng CDN. Mô hình nhiều DNS server tham gia vào một quá trình phân giải DNS có thể được sử dụng để phân phối các quyết định phức tạp hơn từ một DNS server tới nhiều DNS server chuyên dụng khác. Điều này có thể được thực hiện bằng cách định hướng quyền của miền mức tiếp theo tới DNS server khác sử dụng các bản ghi NS hoặc các bản ghi CNAME (Canoniacal Name). Nhiều DNS server vật lý kết hợp định tuyến yêu cầu phân giải DNS sẽ chuyển tới một trong số DNS server này, có thể là DNS server gần nhất đối với DNS server biên client. Sau khi nhận được gói này, DNS server biết được rằng nó là gần nhất và có thể sử dụng thông tin đó để tạo ra quyết định định tuyến.
2.3.2.1.1. Đáp ứng đơn
Theo cách này, server DNS có quyền đối với toàn bộ miền DNS hoặc các miền con. DNS server gửi trả lại địa chỉ IP của server sao lưu tốt nhất trong bản ghi A tới DNS server yêu cầu. Địa chỉ IP của server sao lưu là đia chỉ IP ảo của tập các server sao lưu tốt nhất đối với DNS server yêu cầu.
2.3.2.1.2. Đa đáp ứng
Theo cách này, server DNS gửi trả lại nhiều đáp ứng như là các bản ghi A về các server sao lưu. Thứ tự các bản ghi được gửi trả lại có thể được sử dụng để định hướng nhiều client sử dụng chung một server DNS phía client.
2.3.2.1.3. Phân giải nhiều mức
Theo cách này, nhiều server DNS định tuyến yêu cầu có liên quan đến một quá trình phân giải DNS. Lý do chính của việc sử dụng nhiều server định tuyến DNS trong một quá trình phân giải DNS là cho phép phân phối các quyết định khá phức tạp từ server DNS đơn tới các server định tuyến yêu cầu DNS. Các kỹ thuật phổ biến nhất để nhiều server DNS cùng tham gia vào một hoạt động phân giải DNS là sử dụng các bản ghi NS và CNAME.
Định hướng bằng cách sử dụng bản ghi NS
DNS server có thể sử dụng các bản ghi NS để định hướng quyền của miền tiếp theo tới server định tuyến yêu cầu DNS khác. Kỹ thuật này cho phép nhiều DNS server tham gia vào quá trình phân giải tên miền. Vídụ, DNS server phía client phân giải a.b.example.com. Server có quyền đối với miền này có thể là server NS định tuyến yêu cầu. Trong trường hợp này, DNS server có thể gửi trả lại một tập các bản ghi A hoặc có thể định hướng hoạt động phân giải yêu cầu a.b.example.com tới DNS server có quyền đối với example.com sử dụng các bản ghi NS.
Một hạn chế của việc sử dụng các bản ghi NS là số các server DNS định tuyến yêu cầu là hạn chế bởi số các vùng trong tên DNS. Hạn chế thứ hai là DNS server cuối cùng sẽ xác định thời gian sống của toàn bộ quá trình phân giải. Về cơ bản, DNS server cuối cùng có thể gửi trả lại bản ghi NS. Client đó sẽ sử dụng bản ghi NS để phân giải các yêu cầu sau này cho tới khi nó hết hiệu lực. Một hạn chế nữa đó là tạo thêm trễ trong quá trình phân giải yêu cầu do sử dụng nhiều DNS server.
Định hướng sử dụng bản ghi CNAME
Trong trường hợp này, DNS server định tuyến yêu cầu gửi trả lại một bản ghi CNAME để định hướng sự phân giải tới miền hoàn toàn mới. Về nguyên lý, miền mới này có thể sử dụng một tập các DNS server mới.
Nhược điểm của phương pháp này là tăng thêm chi phí cho việc phân giải tên miền mới. Nhưng ưu điểm chính của nó là số các DNS server độc lập với định dạng của tên miền.
2.3.2.1.4. Phương pháp quảng bá tùy ý
Quảng bá tùy ý là một dịch vụ giữa các mạng, thích hợp với các tình trạng mà máy chủ, ứng dụng hoặc người sử dụng yêu cầu xác định vị trí một host có khả năng hỗ trợ dịch vụ riêng biệt, nhưng nếu một số server không hỗ trợ dịch vụ này, thì không cần để ý chi tiết xem server nào được sử dụng. Khi sử dụng dịch vụ quảng bá tùy ý, một host truyền gói tin về một địa chỉ quảng bá tùy ý và các mạng chịu trách nhiệm cung cấp một phương pháp phân phát gói tin đó tới ít nhất một, và tốt nhất là chỉ một, trong số các server chấp nhận các gói dữ liệu địa chỉ quảng bá tùy ý đó.
Động cơ thúc đẩy để sử dụng quảng bá tùy ý đó là làm đơn giản hóa đáng kể quả trình tìm kiếm một server thích hợp. Ví dụ, các user thay vì hỏi một danh sách các server và được kết nối tới một server gần nhất. Bằng cách sử dụng anycast, không lâu nữa các thiết bị phân giải DNS sẽ được định cấu hình với các địa chỉ IP của các server, chứ không phải gửi câu hỏi địa chỉ anycast tới DNS đã biết.
Hơn nữa, để kết hợp được sự đánh giá và sự đổi hướng, DNS server có thể thông báo một địa chỉ quảng bá tùy ý như là địa chỉ IP của nó. Địa chỉ giống nhau này được các server DNS vật lý sử dụng. Trong trường hợp này, DNS server gần với DNS server phía client nhất dưới dạng định tuyến OSPF và BGP, sẽ nhận các gói chứa trong yêu cầu phân giải DNS. Server này có thể sử dụng thông tin nhận được để tạo một quyết định định tuyến yêu cầu.
Các nhược điểm của phương pháp này là:
DNS server có thể không là server gần nhất về mặt định tuyến tới client.
Điển hình là, các giao thức định tuyến không nhạy cảm với tải. Do đó, server gần nhất có thể không phải là server có trễ mạng nhỏ nhất.
Tải của server không được xem xét trong suốt quá trình định tuyến.
2.3.2.1.5. Mã hóa đối tượng
Do chỉ có các tên DNS là hiện hữu trong suốt quá trình định tuyến yêu cầu theo DNS, nên có một số giải pháp mã hóa kiểu đối tượng hoặc thông tin tương tự thành tên DNS. Có thể biến đổi từ việc phân chia đơn giản các đối tượng dựa trên kiểu đối tượng (như là images.a.b.example.com và streaming.a.b.example.com) thành một sơ đồ phức tạp trong đó tên miền chứa một nhận dạng duy nhất của một đối tượng duy nhất. Ưu điểm của phương pháp này là thông tin về đối tượng là khả dụng tại thời gian phân giải. Nhưng nhược điểm của nó là DNS server phía client phải thực hiện nhiều phân giải để đạt được một trang web đơn, như vậy làm tăng trễ lên chứ không phải làm giảm trễ đi.
2.3.2.1.6. Hạn chế của định tuyến yêu cầu theo DNS
Một số hạn chế của các kỹ thuật định tuyến yêu cầu dựa trên DNS được trình bày dưới đây:
DNS chỉ cho phép phân giải tại mức miền. Tuy nhiên, hệ thống phân giải yêu cầu lý tưởng sẽ phục vụ các yêu cầu tại mức đối tượng.
Trong hệ thống định tuyến yêu cầu DNS, các server có thể được yêu cầu để
đáp lại các mục DNS với các giá trị TTL ngắn. Sự đáp trở lại này có thể làm tăng khối lượng các yêu cầu tới các DNS server.
Một số DNS khi thực thi không tuân theo các chuẩn DNS. Ví dụ, nhiều quá
trình thực thi DNS không giữ đúng trường DNS TTL.
Hệ thống định tuyến yêu cầu DNS chỉ dựa trên việc nhận biết DNS server
của client, khi các địa chỉ của client không được đặt trong các yêu cầu DNS.
Điều này làm hạn chế khả năng xác định trạng thái của client của hệ thống
định tuyến yêu cầu.
Các user của cùng một DNS server phía client sẽ được định hướng tới cùng
một tập các địa chỉ IP trong suốt khoảng thời gian sống TTL.
2.3.2.2. Định tuyến yêu cầu lớp truyền tải
Định tuyến yêu cầu dựa trên lớp truyền tải được sử dụng để đạt được định tuyến yêu cầu mức cao hơn và tốt hơn sau khi mức đầu tiên được thực hiện, đó là mức định tuyến yêu cầu dựa trên DNS. Nó sử dụng các thông tin như là địa chỉ IP của client và số cổng sẵn có trong gói dữ liệu đầu tiên từ client, trong quá trình định tuyến yêu cầu và chuyển phiên này tới server sao lưu phù hợp hơn.
Theo cách này, hệ thống định tuyến yêu cầu sẽ kiểm tra thông tin khả dụng trong gói dữ liệu đầu tiên của các yêu cầu của client để tạo ra các quyết định lựa chọn server sao lựu. Việc kiểm tra các yêu cầu của client cung cấp dữ liệu về địa chỉ IP của client, thông tin về cổng, và giao thức lớp 4. Dữ liệu thu được nào có thể được sử dụng kết hợp với các chính sách xác định user và các tham số khác để quyết định lựa chọn server sao lưu phù hợp nhất có thể đáp ứng yêu cầu của client.
Nhìn chung, định tuyến yêu cầu lớp truyền tải có thể kết hợp với các kỹ thuật định tuyến dựa theo DNS. Như đã trình bày ở trên, các phương pháp định tuyến con gắn với địa chỉ IP của DNS server của client. Do đó, các phương pháp dựa trên DNS có thể được sử dụng như là bước đầu tiên trong việc quyết định server sao lưu phù hợp của hệ thống định tuyến yêu cầu lớp truyền tải.
2.3.2.3. Định tuyến yêu cầu lớp ứng dụng
Các hệ thống định tuyến yêu cầu lớp ứng dụng thực hiện xem xét sâu hơn các gói dữ liệu của client trừ tiêu đề của lớp truyền tải. Xem xét kỹ hơn các gói dữ liệu của client cho phép định tuyến yêu cầu của từng đối tượng riêng lẻ. Quá trình này có thể được thực hiện ngay tại thời điểm có yêu cầu đối tượng. Việc đưa ra các địa chỉ IP của client kết hợp với việc nhận biết tốt hơn về đối tượng được yêu cầu cho phép các hệ thống định tuyến yêu cầu lớp ứng dụng cung cấp sự điều khiển tốt hơn để lựa chọn server sao lưu tốt nhất.
2.3.2.3.1. Kiểm tra Header
Định tuyến yêu cầu dựa trên URL
Các giao thức lớp ứng dụng như là HTTP và RTSP mô tả nội dung được yêu cầu bằng các URL của nó. Trong nhiều trường hợp, thông tin này đủ để tạo thành nội dung đó và định hướng yêu cầu một cách phù hợp. Trong hầu hết các trường hợp, thông tin đó có thể đủ để tạo ra quyết định định tuyến yêu cầu chỉ bằng cách kiểm tra tiền tố hoặc hậu tố của URL.
Định hướng theo mã ứng dụng 302
Theo phương pháp này, yêu cầu của client trước tiên được chuyển sang một server sao lưu ảo. Sau đó, server sao lưu này sẽ gửi trả lại một mã ứng dụng cụ thể như là 302 (trong trường hợp của HTTP hoặc RTSP) để định hướng client tới nút phân phối thực.
Kỹ thuật này có khả năng thực thi dễ dàng. Tuy nhiên, trở ngại chính của phương pháp này là làm tăng trễ do phải gửi bản tin đổi hướng ngược trở lại client.
Kỹ thuật In-Path Element
Theo kỹ thuật này, một phần tử In-Path hiện diện trong mạng có các đường của chuyển tiếp các yêu cầu của client. Phần tử in-path kiểm tra các yêu cầu nội dung của client và thực hiện tới nút phân phối thích hợp và chuyển tiếp các yêu cầu của client. Nói chung, đường phản hồi sẽ đi qua phần tử in-path kiểm tra các yêu cầu nội dung của client và thực hiện các quyết định định tuyến yêu cầu. Sau đó, phần tử này sẽ ghép kết nối của client tới nút phân phối thích hợp và chuyển tiếp các yêu cầu của client. Nói chung, đường phản hồi sẽ đi qua phần tử in-path. Tuy nhiên, có thể sắp đặt để phản hồi trực tiếp bằng cách chuyển thông tin biên dịch địa chỉ tới server sao lưu hoặc nút phân phối nhờ một số cách thức riêng.
Định tuyến yêu cầu dựa vào tiêu đề
Kỹ thuật này bao gồm các thao tác sử dụng HTTP như là Cookie, Language, và User-Agent, để lựa chọn server sao lưu.
Các Cookie có thể được sử dụng để nhận biết customer hoặc phiên trang web. Định tuyến yêu cầu dựa trên Cookie cung cấp cách phân biệt dịch vụ nội dung dựa trên client. Phương pháp này hoạt động với điều kiện là các Cookie thuộc về client. Tiêu đề Language có thể được sử dụng để định hướng lưu lượng tới nút phân phối language cụ thể. User-agent header giúp nhận biết các kiểu thiết bị client. Ví dụ, voice-browser, PDA, hoặc cell phone có thể chỉ ra kiểu nút phân phối mà có nội dung chuyên dụng để xử lý yêu cầu nội dung của client.
2.3.2.3.2. Kỹ thuật chỉnh sửa nội dung (Content Modification)
Kỹ thuật này cho phép nhà cung cấp nội dung điều khiển trực tiếp các quyết định định tuyến yêu cầu. Về cơ bản, nhà cung cấp nội dung có thể trao đổi trực tiếp với server sao lưu tốt nhất của client. Các quyết định về lựa chọn server sao lưu tốt nhất được tạo ra dựa trên mỗi đối tượng hoặc phụ thuộc vào một số tham số. Kỹ thuật này gọi là URL rewriting.
Các kỹ thuật chỉnh sửa nội dung phải không can thiệp vào các khái niệm về kiến trúc của Internet. Và phải đảm bảo rằng công việc chỉnh sửa nội dung được thực hiện theo cách phù hợp với RFC 3238.
Các kiểu URL rewriting cơ bản được trình bày dưới đây.
A-priori URL rewriting
Theo phương pháp này, nhà cung cấp nội dung ghi lại các URL trước khi nội dung được định vị trên origin server. Trong trường hợp này, việc ghi lại các URL có thể được thực hiện bằng nhân công hoặc sử dụng các công cụ phần mềm mà có khả năng phân tách nội dung và thay thế các URL.
Một mình A-priori URL rewriting không cho phép xét đến định tuyến yêu cầu cho client. Tuy nhiên, nó có thể được sử dụng kết hợp với hệ thống định tuyến yêu cầu dựa trên DNS để định hướng các câu hỏi liên quan đến DNS vào không gian tên miền của nhà cung cấp dịch vụ. Định tuyến yêu cầu động dựa trên các đặc tính của client được thực hiện nhờ sử dụng DNS.
URL rewriting theo yêu cầu
URL rewriting theo yêu cầu hay URL rewriting động, thay đổi nội dung khi yêu cầu của client đi đến origin server. Tại thời điểm này, đặc tính của client được nhận biết và có thể được xét đến khi rewriting các embedded URL. Đặc biệt là tự động hóa quá trình xác định theo yêu cầu, server sao lưu nào sẽ phục vụ yêu cầu của client tốt nhất. Sau đó, các embedded URL có thể được ghi lại để định hướng client tới server sao lưu tốt nhất chứ không phải tới origin server. [2,9]
2.3.2.4. Kết hợp nhiều kỹ thuật định tuyến yêu
Trong nhiều trường hợp có thể sử dụng kết hợp nhiều kỹ thuật định tuyến khác nhau để đạt được nhiều thuận lợi hơn là sử dụng một kỹ thuật. Dưới đây đưa ra một ví dụ về sự kết hợp giữa các kỹ thuật định tuyến.
Vấn đề cơ bản của định tuyến yêu cầu DNS là sự phân giải, chỉ cho phép phân giải ở mức miền. Định hướng đối với mỗi đối tượng không dễ gì đạt được. Tuy nhiên, nếu sử dụng kỹ thuật sửa đổi nội dung kết hợp với kỹ thuật định tuyến yêu cầu DNS thì có thể khắc phục được vấn đề này. Đối với kỹ thuật sửa đổi nội dung, các đối tượng khác nhau trên cùng một origin server có thể được ghi lại tại các vùng tên miền khác nhau. Sử dụng định tuyến yêu cầu DNS, các yêu cầu đối với các đối tượng này có thể được định hướng động tới các server sao lưu khác nhau.
2.3.3. Kết nối giữa các hệ thống định tuyến yêu cầu
Trong một mạng CDN, hệ thống định tuyến yêu cầu được sử dụng để định tuyến các yêu cầu của client tới các server sao lưu trong mạng đó. Tuy nhiên, khi hệ thống định tuyến yêu cầu được liên kết với các hệ thống ngang cấp trong các mạng CDN khác, bộ