HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG
NGUYỄN XUÂN HÙNG

TÌM HIỂU KỸ THUẬT ĐỊNH TUYẾN THEO TÊN MIỀN
TRONG MẠNG CDN
Chuyên ngành: Kỹ thuật điện tử
Mã số: 60.52.70 Người hướng dẫn khoa học: TS NGUYỄN QUÝ SỸ
TÓM TẮT LUẬN VĂN THẠC SĨ
1

TỔNG QUAN VỀ HỆ THỐNG CDN
1.1. Động lực phát triển
Internet đã chứng minh trong quá trình triển khai và hoạt động là nó chỉ phù hợp cho
việc phân phối, truy cập những trang Web tĩnh và thư điện tử đơn giản. Tuy nhiên, Internet
ngày nay và các kiến trúc Intranet kết hợp không có khả năng xử lý lượng truyền thống đa
phương tiện và các dịch vụ nội dung đòi hỏi lưu lượng lớn mà các khách hàng trực tuyến
tìm kiếm ở tốc độ mà họ mong muốn. Các nút cổ chai mạng thường xuyên xảy ra giữa các
nguồn tài nguyên nội dung và người sử dụng cuối. Kể cả việc bổ sung các đường ống nhanh
hơn, các server lớn hơn vẫn không giải quyết được vấn đề. Kết quả là rất nhiều nhà cung
cấp dịch vụ nội dung, các nhà kinh doanh điện tử thương mại, các tổ chức và các doanh
nghiệp phải chịu đựng các server quá tải và truy nhập mạng với tốc độ chậm làm nản lòng
khách hàng, nhân viên.
Giải pháp mạng phân phối nội dung nhằm nâng cao năng lực của mạng. Mục tiêu
chính của CDN là để tránh các vùng tắc nghẽn trong mạng. Nếu lưu lượng giữa người dùng
và máy chủ không đi qua phần mạng bị nghẽn thì có nhiều khả năng là tốc độ truyền dữ liệu
sẽ cao hơn.

Hình 1.1: Mô hình mạng CDN
Trong mạng CDN có nhiều các server thay thế được đặt ở các vị trí khác nhau. Các
server thay thế thường có nội dung như nhau, tuy nhiên khách hàng chỉ có thể kết nối một
số server thay thế phù hợp theo chính sách của nhà cung cấp CDN.
CDN là một mạng nội dung thông minh, nó cung cấp một lớp thông minh ở trên cơ sở hạ

của người sử dụng đến một nút thay thế.
Nhằm đạt hiệu suất hoạt động tốt nhất, yêu cầu phải được chuyển tới nút thay thế gần
nhất. Để làm được điều này mỗi mạng CDN phải duy trì và cập nhật một bảng định tuyến
gồm danh sách các nút mạng và danh sách các client cho từng nút mạng. Nội dung của bảng
3

định tuyến phải được cập nhật sửa đổi cho phù hợp với mức độ tải hiện thời của mạng và
của các nút mạng CDN. Do vậy thành phần thứ ba của giải pháp CDN là việc đánh giá hoạt
động mạng. Ngoài ra còn có các thành phần khác như hệ thống tính cước, quản lý mạng
phân phối nội dung . . . sẽ được trình bày chi tiết các phần sau.
1.3.1. Nút CDN
Mỗi mạng phân phối nội dung bao gồm một số các nút mạng CDN và mỗi nút mạng
CDN lại bao gồm một hoặc nhiều thiết bị. Các nút mạng CDN này bao gồm một nút gốc và
một số nút thay thế. Do mục tiêu cơ bản của CDN là hỗ trợ các ứng dụng truy cập bởi số
lượng lớn khách hàng, nên mỗi nút CDN phải được thiết kế sao cho nó có độ tin cậy cao và
khả năng mở rộng linh hoạt.
1.3.2. Định tuyến yêu cầu của người sử dụng
Cấu trúc của hệ thống định tuyến yêu cầu được chỉ ra trong Hình 1.2. Hình 1.2 thể
hiện khái niệm tổng quan về hệ thống định tuyến yêu cầu, nó bao gồm các thành phần: Trao
đổi cấu hình nội dung CTE (Content Topology Exchang), cơ sở dữ liệu cấu hình nội dung
CTD (Content Topology Database) và tính toán định tuyến (route computation).
Hình 1.2: Cấu trúc hệ thống định tuyến yêu cầu
Bước 1. Tính toán định tuyến: Tính toán để lựa chọn server sao lưu tốt nhất cho các
client dựa trên các thông tin được lưu trữ trong cơ sở dữ liệu cấu hình nội dung, thuật toán
tính toán định tuyến và các cách được định sẵn.
Bước 2. Cơ sở dữ liệu cấu hình nội dung: Dữ liệu cấu hình bao gồm thông tin thông
báo chi tiết nhận được từ các CDN lân cận và các thông số liên quan.

CDN. Quá trình phân phối có thể xảy ra cả khi server sao lưu không nhận được yêu cầu từ
các client, quá trình này được gọi là tìm nạp trước, hoặc có thể xảy ra khi server sao lưu
nhận được yêu cầu của client mà không lưu giữ nội dung được yêu cầu đó, gọi là tìm nạp
theo yêu cầu.

Hình 1.3: Quá trình phân phối nội dung
5 Hình 1.4: Quá trình phân phát nội dung
Quá trình phân phối nội dung thực hiện di chuyển nội dung của các nhà cung cấp nội
dung từ server gốc của nó tới một hoặc nhiều server sao lưu Hình 1.3 . Cần chú ý rằng quá
trình phân phối nội dung khác với phân phát nội dung. Phân phát nội dung là quá trình
chuyển nội dung của các nhà cung cấp nội dung tới các client như trong Hình 1.4.

Hình 1.5: Phân phối nội dung trong một mạng CDN và giữa các mạng CDN ngang cấp
Hình 1.5 mô tả các bước phân phối nội dung trong một mạng CDN và phân phối giữa
các mạng CDN ngang cấp. Sau đây là các bước thực hiện phân phối:
Bước 1: Server gốc cho phép các CDN ngang cấp phân phối nội dung của nó và đặt
nội dung vào hệ thống phân phối ngang cấp của một trong các CDN. Tồn tại hai cách đặt
nội dung:
Đẩy nội dung xuống trước: Nội dung sẽ được sử dụng trong các CDN được đẩy
xuống một cách tích cực.
Kéo nội dung theo yêu cầu: Nội dung được kéo theo yêu cầu từ OS khi có một bộ
đệm bị lỗi tại server sao lưu tại cùng thời gian đối tượng được yêu cầu.
6

Bước 4: Hệ thống phân phối ngang cấp di chuyển nội dung giữa các CDN ngang
cấp. Nó cung cấp thông tin về các vị trí nơi mà nội dung có mặt tới hệ thống định tuyến
ngang cấp. Hệ thống định tuyến ngang cấp thông báo thông tin này tới các mạng CDN

trong ba cách dưới đây:
1. Mạng riêng thứ cấp được biết đến như là mạng bảo mật có thể được thiết lập ở
giữa các mạng CDN khác nhau và được sử dụng cho việc giao tiếp giữa các bên.
2. Mạng riêng ảo (VPN) có thể được thiết lập giữa các bên CDN. Mạng này có thể
được thiết lập trên mạng chung sử dụng các công nghệ bảo mật như là IP-sec. Tất cả các
giao tiếp xảy ra giữa các mạng CDN trên mạng riêng ảo đều được mật mã và được bảo mật
nhờ sử dụng các đường hầm IP-sec.
3. Tất cả các giao tiếp giữa các mạng CDN có thể được mã hóa nhờ sử dụng một giao
thức truyền tải bảo mật như là SSL. Các kết nối được thiết lập giữa các mạng CDN đều
được nhận thực. Tất cả các chương trình giao tiếp giữa các mạng CDN phải sử dụng truyền
tải bảo mật hoặc bảo mật dữ liệu bằng cách mã hóa lớp ứng dụng.
1.4. Các nhà cung cấp CDN trên thế giới
1.5. Các mô hình kinh doanh CDN
1.5.1. Mô hình kinh doanh content-centric và access-centric truyền thống
1.5.2. Mô hình kinh doanh ghép cặp Hoster/CDN
1.5.3. Mô hình kinh doanh ngang cấp P2P
1.6. Các hoạt động chuẩn hoá liên quan đến CDN
1.6.1. Các hoạt động chuẩn hoá trong IETF
1.6.2. Các hoạt động chuẩn hoá ngoài IETF
Architecture integrating Active Directories). NAT được đưa vào để cho phép tái sử dụng địa
chỉ IP. Nó được dùng trong một hệ thống tự trị cho phép các doanh nghiệp tự cấp địa chỉ
độc lập với các ISP. Nó hỗ trợ các multi-homing và chuyển mạch ISP và ghép cặp số lượng
các host với các số lượng địa chỉ được cấp bởi ISP. Nhưng với NAT thì địa chỉ IP chỉ thực
sự có nghĩa với một dải địa chỉ nhất định. Bộ định tuyến NAT yêu cầu có các proxy chuyên
dụng lớp ứng dụng để thực hiện chức năng ứng dụng Internet một cách chính xác. Nó cần
điều chỉnh các đáp ứng DNS truyền qua bộ định tuyến NAT và cập nhật trường checksum
của gói tin, hứa hẹn đảm bảo độ tin cậy và bảo mật xuyên suốt. Tuy nhiên trong NAT, việc
truyền thông giữa dải địa chỉ riêng biệt mà không cần đánh số lại là rất khó. Kỹ thuật
TRIAD rất thích hợp cho định tuyến yêu cầu CDN sử dụng NAT.
2.2.3. Đị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 tin đầ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 đại diện thích hợp hơn.
2.2.4. Định tuyến yêu cầu dựa trên URL
Định tuyến yêu cầu dựa theo URL (URL based) sử dụng URL hoặc các tiền tố URL
của nội dung yêu cầu để đưa ra quyết định định tuyến. Định tuyến yêu cầu dựa theo URL có
hai loại là sử dụng mã định hướng lại 302 và In-path Element (phần tử trong luồng)
Sử dụng mã định hướng lại 302: Mã 302 mang ý nghĩa là dịch chuyển tạm thời: Yêu
cầu đối tượng được tạm thời chuyển sang vị trí mới và được đáp ứng tại đó. Các yêu cầu
trong tương lai của client nên vẫn là như cũ. 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 đại diện “ảo”. Sau đó server đại diện này sẽ gửi trả
lại một mã ứng dụng cụ thể là 302 (đối với giao thức truyền tải là HTTP hoặc RTSP) để
định hướng client tới nút phân phối thực.
In-path Element: Kỹ thuật phần tử trong luồng (In-path Element), một phần tử In-
path hiện diện trong mạng có các đường chuyển tiếp các yêu cầu của client. Phần tử in-path
10


(TTL) trong câu trả lời với một giá trị rất nhỏ (ví dụ như 20 giây).
11

Hình 2.2 thể hiện một quá trình phân giải tên miền theo IP dựa vào DNS. Theo
phương pháp này thì DNS có thẩm quyền sẽ trả về cho khách hàng địa chỉ của server thay
thế phù hợp với yêu cầu.

Hình 2.2: Định tuyến yêu cầu theo IP dựa vào DNS
Các bước định tuyến theo IP dựa vào DNS như sau:
Bước 1: Khách hàng yêu cầu phân giải đệ quy tên miền “google.com” tới DNS local.
Bước 2: Giả sử DNS local không có cache về tên miền này. Sau đó DNS local đi hỏi
root DNS chuyển giao của “google.com”.
Bước 3: DNS root trả lời DNS CDN là DNS chuyển giao “google.com”.
Bước 4 và 5: DNS local đi hỏi tiếp DNS CDN, tại đây DNS CDN có thể dựa vào các
thông tin như IP của DNS local, tải của server thay thế, độ trễ (bằng các phương pháp thăm
dò từ trước) từ đó trả lời cho DNS local hiện tên miền google.com đang được đê bí danh
dưới dạng google.com.vn và có IP là 74.125.128.94.
Bước 6: DNS local trả lại cho khách hàng IP của server thay thế phục vụ khách hàng
tốt nhất là 74.125.128.94.
Bước 7 và 8: Khách hàng yêu cầu nội dung từ 74.125.128.94 và được đáp ứng nội
dung theo yêu cầu.
Như vậy mục đích và yêu cầu của phương pháp định tuyến theo IP dựa trên DNS là
định tuyến client tới server thay thế gần nhất dựa vào sự tương quan IP của server thay thế
12

và client (hoặc các quan hệ khác) sẽ thiết lập một cơ chế trả lời của DNS trong mạng CDN
sao cho ứng với mỗi khách hàng sẽ có một server thay thế gần khách hàng nhất phù hợp để
phục vụ.
2.3.2. Phương pháp định tuyến theo tên miền dựa vào DNS
Khác với phương pháp định tuyến theo IP, khi khách hàng yêu cầu phân giải một tên

giao trên DNS của nhà cung cấp nội dung CDN “24h.com”.
Bước 4. DNS local yêu cầu DNS CDN phân giải tên miền “24h.com”.
Bước 5. DNS CDN dựa vào IP của DNS local phía đầu khách hàng (hoặc IP của
khách hàng nếu khách hàng query trực tiếp tới DNS CDN) và trả lời DNS local bằng 1 tên
miền khác “24h.com.vn”, bằng cách khai báo bản ghi CNAME ứng với từng trường hợp.
Bước 6. DNS local lại tiếp đi hỏi DNS root về tên miền “24h.com.vn”.
Bước 7. DNS Root trả lời cho DNS local là tên miền “24h.com.vn” đang được
chuyển giao trên DNS VNNIC của Việt Nam.
Bước 8. DNS local đi hỏi DNS VNNIC về IP của tên miền “24h.com.vn”.
Bước 9. DNS VNNIC trả lời IP tương ứng với tên miền “24h.com.vn” là
“123.30.129.148”.
Bước 10. DNS local trả về IP tưng ứng với tên miền “24h.com” cho khách hàng.
Bước 11. Khách hàng yêu cầu nội dung từ server thay thế có IP “123.30.129.148”.
Bước 12. Server thay thế cung cấp nội dung cho khách hàng.
Như vậy quá trình từ yêu cầu nội đến cung cấp nội dung phải trải qua 2 lần DNS
local, hoặc máy tính của khách hàng yêu cầu phân giải tên miền do đó làm tăng thời gian
đáp ứng nội dung. Tuy nhiên nó có ưu điểm rất lớn là các server thay thế tại các Quốc gia
khác nhau có thể sử dụng IP động chứ không phải IP tĩnh, do đó làm giảm chi phí thuê Ip
14

tĩnh đồng thời nó còn giúp tiết kiệm tài nguyên IPv4 đang ngày càng cạn kiệt. Các server
thay thế có IP động sẽ hoạt động dựa vào phương pháp DNS động (Dynamic DNS).
Dynamic DNS là phương thức ánh xạ tên miền tới địa chỉ IP có tần xuất thay đổi cao
(do không phải mọi máy tính đều sử dụng địa chỉ IP tĩnh).
Những đối tượng không sử dụng dịch vụ kết nối Internet trực tiếp leased-line với địa chỉ IP
tĩnh mà thuê kết nối Internet gián tiếp dialup hoặc dịch vụ ADSL có địa chỉ IP động, nếu
đăng ký sử dụng Dynamic DNS hoàn toàn có thể tự duy trì máy chủ dịch vụ của mình. Đặc
biệt, các thuê bao ADSL với số lượng ngày càng tăng nhanh sẽ rất hưởng ứng dịch vụ
dynamic DNS bởi vì với dynamic DNS, thuê bao ADSL (thường là các tổ chức) có khả
năng tự duy trì máy chủ dịch vụ (mail, web, ftp…server), không phải thuê dịch vụ mail

cơ sở dữ liệu, tham khảo tại (). Dữ liệu này được gọi là dữ liệu
GeoDNS, khi sử dụng GeoDNS với một script được tạo sẵn ta sẽ thiết lập được 1 danh sách
các access list (danh sách truy nhập) theo IP của tất cả các Quốc gia.
Bind (Berkeley Internet Name Domain) là một chương trình phục vụ DNS trên nền
các hệ thống AIX/BSD/HP-UX/Unix/Linux/VMS Các chức năng của DNS sẽ do bind
quyết định, gồm phân giải tên miền thành IP và ngược lại.
3.2 Mô hình mô phỏng
Trong luận văn chủ yếu đề cập tới kỹ thuật định tuyến theo tên miền dựa vào DNS và
so sánh với kỹ thuật định tuyến theo IP. Với việc phân tích mô hình trong chương 2 (hình 2-
3), giả sử trong mạng CDN của nhà cung cấp 24h.com, có các server thay thế khác nhau
phục vụ… Và các khách hàng ở từng Quốc gia sẽ được yêu cầu định tuyến tới server thay
thế phù hợp.Giả sử các server thay thế sẽ được đăng ký sử dụng IP động để tiết kiệm tài
nguyên IP. Trong mô hình mô phỏng ứng với trường hợp khách hàng ở Việt Nam khi yêu
cầu nội dung từ trang 24h.com sẽ được định tuyến tới hn.24h.com.vn, còn khách hàng ở các
Quốc gia khác sẽ được định tuyến tới hcm.24h.com.vn để giảm tải cho server chính được
đặt ở Hà Nội.
16 Hình 3.1. Mô hình mô phỏng kỹ thuật định tuyến theo tên miền
Theo hình 3.1, ta cần tối thiểu 02 server DNS có IP public. Trong đó một
server làm DNS local của client, 01 server của nhà cung cấp CDN.
- Chuẩn bị server: 02 server (IP : 27.68.242.117 và 27.68.242.121).
- Phần mềm: BIND 9.8.1-P1, Ubuntu 12.04.1. Cài đặt đầy đủ các gói g++, gcc, và
các thư viện liên quan.
- Cơ sở dữ liệu IP trên toàn thế giới GeoDNS (GeoIPCountryCSV.zip), được
download từ trang web của Công ty Maxmind .
Sử dụng script_geo_dns.sh để tạo các access list cho DNS CDN.
root@IPv6:/home/hungnx15# more script_geo_dns.sh
#!/bin/bash

))}'
echo -e "};\n"
done) > GeoIP.acl
rm -f cbe0.csv
echo "DONE"
exit 0
Kết quả chạy script ta được file GeoIP.acl, bao gồm hầu hết các IP trên toàn thế giới,
được phân chia theo các Quốc gia khác nhau.
Để DNS CDN có thể trả về một tên miền khác so với tên miền mà Local DNS yêu
cầu, trong luận văn tôi sử dụng khai báo bản CNAME cho tên miền 24h.com trỏ tới những
tên miền hcm.24h.com.vn và hn.24h.com.vn.
18

3.3. Kết quả mô phỏng
Theo mô hình mô phỏng và yêu cầu định tuyến. Khi khách hàng yêu cầu nội dung từ
nhà cung cấp nội dung CDN 24h.com, thì sẽ được định tuyến theo cơ chế:
 Khách hàng ở Việt Nam được yêu cầu định tuyến đến “hn.24h.com.vn”.
 Khách hàng tại các Quốc gia khác được yêu cầu định tuyến tới
“hcm.24h.com.vn”.
Khách hàng tại nước ngoài (Campuchia) sẽ được định tuyến yêu cầu đến server
hcm.24h.com.vn.
[noc@rtgsyslog ~]$ /sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 00:1E:4F:34:1B:C7
inet addr:117.120.24.67 Bcast:117.120.24.95 Mask:255.255.255.224
//Server có IP tại Campuchia)
[noc@rtgsyslog ~]$ nslookup
> server 27.68.242.117
Default server: 27.68.242.117
Address: 27.68.242.117#53
> www.24h.com
20

KẾT LUẬN
Việc định tuyến theo yêu cầu là rất quan trọng, nó sẽ giúp cho các nhà cung cấp CDN
đáp ứng được nhu cầu ngày càng cao của khách hàng về việc truy nhập các nội dung có
dung lượng lớn như video… bằng cách định tuyến khách hàng tới những server thay thế phù
hợp nhất với khách hàng để phục vụ.
Do hạn chế về mặt thời gian, điều kiện thiết bị và phần mềm, luận văn chưa tiến hành
thực hiện mô phỏng được các kỹ thuật định tuyến dựa vào DNS chuyên dụng hơn như định
tuyến dựa vào tổng hợp các điều kiện: tải của server thay thế, trễ từ khách hàng tới các
server thay thế… Do đó chỉ có được những đầu về kỹ thuật định tuyến dựa vào DNS.
Hiện nay, CDN vẫn đang trong giai đoạn đầu của thời kỳ phát triển và xu hướng phát
triển của nó vẫn còn để mở trong tương lai. Việc nắm bắt các kỹ thuật hiện có liên quan tới
việc tổ chức mạng CDN, định tuyến, cache, cũng như tiến trình tư nhân hoá nội dung và
khai thác dữ liệu là vô cùng quan trọng để có thể đề xuất hay dự đoán về những bước phát
triển tiếp theo của mạng phân phối nội dung.