Giáo trình Mạng máy tính (Phần 2)

 Internet là dùng số hiệu cổng (port), còn ở trong mạng ATM là AAL-SAP.
Chúng ta sẽ dùng từ chung nhất để định địa chỉ tiến trình là TSAP (Transport Service
Access Point). Tương tự, địa chỉ trong tầng mạng được gọi là NSAP.
Hình H7.3 mô phỏng mối quan hệ giữa NSAP, TSAP và kết nối vận chuyển. Các tiến
trình ứng dụng, cả client và server đều phải gắn vào một TSAP và thiết lập nối kết đến
TSAP khác. Và kết nối này chạy qua cả hai TSAP. Mục tiêu của việc sử dụng các TSAP
195/215
là vì trong một số mạng, mỗi máy tính chỉ có một NSAP, do đó cần phải có cách phân
biệt nhiều điểm cuối mức vận chuyển khi chúng đang chia sẻ một NSAP.
Ví dụ, dàn cảnh một cuộc kết nối mức vận chuyển có thể diễn ra như sau:
1. Một server phục vụ thông tin về thời gian trên host 2 gắn nó vào TSAP 1522 để
chờ một cuộc gọi đến.
2. Một tiến trình ứng dụng chạy trên host 1 muốn biết giờ hiện tại, vì thế nó đưa
ra một yêu cầu nối kết chỉ ra TSAP 1208 là cổng nguồn và TSAP 1522 là cổng
đích. Hành động này dẫn đến một kết nối vận chuyển được thiết lập giữa hai
tiến trình client và server trên hai host 1 và 2.
TSAP, NSAP và kết nối vận chuyển (H 6.3.)
1. Tiến trình client gởi một yêu cầu đến server để hỏi về thời gian.
2. Server trả lời thời gian hiện tại cho client.
3. Kết nối vận chuyển cuối cùng được giải phóng.
Thiết lập nối kết
Việc thiết lập nối kết nghe có vẻ dễ dàng, nhưng khi thực hiện có thể sẽ gặp nhiều rắc
rối. Thoạt nhìn, một phiên thiết lập nối kết sẽ diễn ra như sau: một bên sẽ gởi TPDU yêu
cầu nối kết (Connection Request – CR) đến bên kia, bên kia sẽ gởi một TPDU trả lời
chấp nhận nối kết (Connection Accepted – CA).
Vấn đề phát sinh khi mạng làm mất, tồn trữ quá lâu hay làm trùng lắp các gói tin do hai
thực thể vận chuyển trao đổi qua lại với nhau. Ví dụ một tình huống như sau: tiến trình
1 gởi yêu cầu kết nối đến tiến trình 2, yêu cầu này bị các mạng con trung gian trì hoãn
196/215
do tắc nghẽn. Mãn kỳ, tiến trình 1 gởi lại yêu cầu nối kết, vừa lúc đó yêu cầu nối kết bị
trì hoãn cũng đến tiến trình 2.
Giải thuật thiết lập nối kết phổ biến nhất là giải thuật bắt tay 3 chiều (three-way hand-
shake). Xin xem các tình huống được mô phỏng trong Hình H7.4. Giả sử yêu cầu nối
kết phát sinh ở host 1. Host 1 chọn một số thứ tự là x và đính kèm số đó trong TPDU
CR ( CR (seq=x) ) gởi đến host 2. Host 2 báo nhận ACK ( ACK (seq = y, ACK = x) )
và thông báo số thứ tự khởi đầu của nó là y. Cuối cùng host 1 báo nhận cho host 2 nó
đã biết số thứ tự khởi đầu của host 2 là y bằng TPDU dữ liệu đầu tiên gởi đến host 2 (
DATA (seq=x, ACK=y)).
Bây giờ xét đến tình huống TPDU CR bị trùng lắp. Khi TPDU CR thứ hai đến host 2,
host 2 liền trả lời ACK vì tưởng rằng host 1 muốn thiết lập nối kết khác. Khi host 1 từ
chối cố gắng thiết lập nối kết của host 2, host 2 hiểu rằng nó đã bị lừa bởi CR bị trùng
lắp và sẽ từ bỏ nối kết đó.
Trường hợp xấu nhất là cả hai TPDU CR và ACK của host 1 đều bị trùng lắp. Như trong
ví dụ (b), host 2 nhận được một CR trễ và trả lời cho yêu cầu đó với số thứ tự khởi đầu
y. Giả sử, không may trong trả lời cho yêu cầu CR trước đó, host 2 thông báo số thứ tự
khởi đầu của nó là z. Báo nhận ở chiều thứ ba của host 1 lại bị trễ. Khi host 1 nhận được
báo nhận ACK (seq=y, ACK=x), nó nhận ra rằng thông báo DATA (seq=x, ACK=z)bị
trễ, do đó nó từ bỏ nối kết này.
197/215
Giải phóng nối kết
Việc giải phóng nối kết đơn giản hơn thiết lập nối kết. Tuy nhiên, người ta sẽ còn gặp
nhiều khó khăn không ngờ tới. Bây giờ chúng ta sẽ đề nghị hai kiểu giải phóng nối kết:
dị bộ và đồng bộ. Kiểu dị bộ hoạt động như sau: khi một bên cắt nối kết, kết nối sẽ bị
hủy bỏ (giống như trong hệ thống điện thoại). Kiểu đồng bộ làm việc theo phương thức
ngược lại: khi cả hai đồng ý hủy bỏ nối kết, nối kết mới thực sự được hủy.
Giải phóng nối kết kiểu dị bộ là thô lỗ và có thể dẫn đến mất dữ liệu. Ví dụ tình huống
trong Hình H7.5. Sau khi nối kết thành công, host 1 gởi một gói dữ liệu đến đúng host
2. Sau đó host 1 gởi tiếp một gói dữ liệu khác. Không may, host 2 gởi đi một yêu cầu
cắt nối kết (DISCONNECT) trước khi gói dữ liệu thứ hai đến. Kết quả là kết nối được
giải phóng và dữ liệu bị mất.
198/215
Sự cắt kết nối một cách thô lỗ sẽ dẫn đến mất dữ liệu (H7.5)
Rõ ràng, chúng ta cần một giải pháp hữu hiệu hơn để tránh mất dữ liệu. Một giải pháp
là sử dụng việc giải phóng nối kết đồng bộ, trong đó, mỗi host đều có trách nhiệm trong
việc giải phóng nối kết. Một nút phải tiếp tục nhận dữ liệu sau khi đã gởi đi yêu cầu
giải phóng nối kết (DISCONNECT REQUEST – CR) đến bên đối tác, cho đến khi nhận
được chấp thuận hủy bỏ nối kết của bên đối tác đó. Người ta có thể hình dung giao thức
như sau: đầu tiên host 1 nói: “Tôi xong rồi, anh xong chưa?”. Nếu host 2 trả lời: “Tôi
cũng xong, tạm biệt” thì kết nối coi như được giải phóng an toàn.
Tuy nhiên, giải pháp trên không phải lúc nào cũng chạy đúng. Có một bài toán nổi tiếng
dùng để mô tả vấn đề, được gọi là bài toán “hai sứ quân” (Two army problem).
Bài toán hai sứ quân (H7.6)
Có hai sứ quân đang dàn trận đánh nhau. Quân trắng dàn quân dưới thung lũng, quân
xanh chia thành hai cánh quân chiếm lĩnh hai đỉnh đồi áng ngữ hai bên thung lũng đó.
Chỉ huy của hai cánh quân xanh muốn thông báo và nhất trí với nhau về thời điểm cùng
tấn công quân trắng. Do quân số hai cánh quân xanh cộng lại mới đủ sức thắng quân
trắng, một cánh quân xanh tấn công riêng lẻ sẽ bị quân trắng tiêu diệt.
199/215
Hai cánh quân xanh muốn đồng bộ hóa cuộc tấn công của họ bằng cánh gởi các thông
điệp qua lại. Nhưng những thông điệp đó phải chạy ngang qua thung lũng và có khả
năng bị quân trắng phá hỏng. Câu hỏi ở đây là có giao thức nào đảm bảo sự thắng lợi
của quân xanh hay không?
Giả sử chỉ huy cánh quân xanh số 1 gởi thông điệp đến chỉ huy cánh quân xanh số 2:
“Tôi dự định tấn công vào lúc hoàng hôn ngày 14 tháng 12 năm 2004, có được không?”.
May mắn thay, chỉ huy cánh quân xanh số 2 nhận được thông điệp và trả lời “Đồng ý”.
Vậy cuộc tấn công có chắc xảy ra không? Không chắc, bởi vì chỉ huy cánh quân xanh
số 2 không chắc câu trả lời của anh ta đến được chỉ huy của cánh quân số 1.
Bây giờ ta cải tiến giao thức thêm một bước: cho nó trở thành giao thức ba chiều: Bên
cánh quân số 1 gởi bản hiệp đồng tấn công cho bên cánh quân số 2, bên cánh quân số 2
trả lời đồng ý, bên cánh quân 1 thông báo cho bên 2 nó đã biết được sự đồng ý của bên
2. Thế nhưng nếu thông báo cuối cùng của bên 1 bị mất thì sao? Bên 2 cũng sẽ không
tấn công!
Nếu ta cố cải tiến thành giao thức n chiều đi nữa thì việc hiệp đồng vẫn thất bại nếu
thông báo cuối cùng bị mất.
Ta có thể thấy mối tương đồng giữa bài toán hai sứ quân và giải pháp giải phóng nối
kết. Thay vì hợp đồng tấn công, hai bên hợp đồng hủy nối kết!
Giải pháp cuối cùng là hai bên sử dụng phương pháp hủy nối kết ba chiều cùng với bộ
định thời:
• Bên phát động việc hủy nối kết sẽ bật bộ định thời cho mỗi yêu cầu giải phóng
nối kết của nó, nếu yêu cầu giải phóng nối kết bị mãn kỳ mà chưa nhận được
trả lời của bên đối tác, nó sẽ gởi lại yêu cầu một lần nữa. Nếu yêu cầu hủy nối
kết bị mãn kỳ liên tục N lần, bên phát động sẽ tự ý hủy bỏ nối kết đó.
• Bên đối tác khi nhận được yêu cầu hủy nối kết từ phía phát động, sẽ trả lời chấp
thuận và cũng bật bộ định thời. Nếu mãn kỳ mà trả lời chấp thuận của nó không
có báo trả từ phía phát động, bên đối tác sẽ tự hủy nối kết.
Hình H7.7 sẽ mô phỏng một số tình huống phát sinh trong quá trình hủy nối kết 3 chiều
có sử dụng bộ định thời.
200/215
Một số tình huống hủy nối kết theo phương pháp 3 chiều (H7.7)
Điều khiển thông lượng
Điều khiển thông lượng trong tầng vận chuyển về cơ bản là giống giao thức cửa sổ trượt
trong tầng liên kết dữ liệu, nhưng kích thước cửa sổ của bên gởi và bên nhận là khác
nhau. Mỗi host có thể có quá nhiều kết nối tại một thời điểm, vì thế nó không chắc là
có thể đảm bảo cung cấp đủ số lượng buffer cho mỗi kết nối nhằm thực hiện đúng giao
thức cửa sổ trượt. Cần phải có sơ đồ cung cấp buffer động.
Trước tiên, bên gởi phải gởi đến bên nhận một yêu cầu dành riêng số lượng buffer để
chứa các gói bên gởi gởi đến. Bên nhận cũng phải trả lời cho bên gởi số lượng buffer
tối đa mà nó có thể cung cấp. Mỗi khi báo nhận ACK cho một gói tin có số thứ tự
201/215
SEQ_NUM, bên nhận cũng phải gởi kèm theo thông báo cho bên gởi biết là lượng buffer
còn lại là bao nhiêu để bên gởi không làm ngập bên nhận.
Ví dụ sau sẽ mô phỏng một tình huống trao đổi thông tin giữa hai máy A và B.
Ví dụ một phiên giao dịch giữa hai thực thể tầng vận chuyển (H7.8)
Một vấn đề tiềm tàng trong sơ đồ dùng buffer động là cơ chế hoạt động của nó có thể
dẫn đến deadlock. Ví dụ trong hàng 16, nếu báo nhận của bên B bị
mất, cả hai bên A và B đều rơi vào trạng thái deadlock. Để tránh tình trạng này, nên cho
các host định kỳ gởi các báo nhận và trạng thái buffer lên mọi kết nối vận chuyển của
chúng.
202/215
Chương 8: Các ứng dụng mạng
Dịch vụ tên (DNS)
Dịch vụ tên (DNS)
Cho đến bây giờ, chúng ta vẫn dùng địa chỉ để định danh các host. Trong khi rất thuận
tiện cho việc xử lý của các router, các địa chỉ số không thân thiện với người dùng lắm.
Vì lý do này, các host thường được gán cho một cái tên thân thiện và dịch vụ tên được
sử dụng để ánh xạ từ cái tên thân thiện với người dùng này sang địa chỉ số vốn rất thân
thiện với các router. Dịch vụ như vậy thường là ứng dụng đầu tiên được cài đặt trong
một mạng máy tính do nó cho phép các ứng dụng khác tự do định danh các host bằng
tên thay vì bằng địa chỉ. Dịch vụ tên thường được gọi là phần trung gian (middleware)
vì nó lấp đầy khoảng cách giữa các ứng dụng khác và lớp mạng phía dưới.
Tên host và địa chỉ host khác nhau ở hai điểm quan trọng. Thứ nhất, tên host thường
có độ dài thay đổi và dễ gợi nhớ, vì thế nó giúp người dùng dễ nhớ hơn. Thứ hai, tên
thường không chứa thông tin gì để giúp mạng định vị (chuyển các gói tin đến) host. Địa
chỉ, ngược lại, lại hàm chứa thông tin vạch đường trong đó.
Trước khi đi vào chi tiết cách thức đặt tên cho các host trong mạng như thế nào, chúng
ta đi định nghĩa một số thuật ngữ trước:
• Không gian tên (name space) định nghĩa tập các tên có thể có. Một không gian
tên có thể là phẳng (flat) – một tên không thể được chia thành các thành phần
nhỏ hơn, hoặc phân cấp.
• Hệ thống tên duy trì một tập các ánh xạ (collection of bindings) từ tên sang giá
trị. Giá trị có thể là bất cứ thứ gì chúng ta muốn hệ thống tên trả về khi ta cấp
cho nó một tên để ánh xạ; trong nhiều trường hợp giá trị chính là địa chỉ host.
• Một cơ chế phân giải (resolution mechanism) là một thủ tục mà khi được gọi
với tham số là một tên, sẽ trả về một giá trị tương ứng.
• Một server tên (name server) là một kết quả cài đặt cụ thể của một cơ chế phân
giải luôn sẵn dùng trên mạng và có thể được truy vấn bằng cách gởi đến nó một
thông điệp.
Mạng Internet đã có sẵn một hệ thống đặt tên được phát triển tốt, gọi là hệ thống tên
miền (domain name system – DNS). Vì thế chúng ta sẽ dùng DNS làm cơ sở để thảo
luận về vấn đề đặt tên cho các host.
Khi nguời dùng đưa một tên host đến một ứng dụng (có thể tên host đó là một phần của
một tên hỗn hợp như địa chỉ email chẳng hạn), ứng dụng này sẽ liên hệ với hệ thống
203/215
tên để dịch tên host sang địa chỉ host. Sau đó ứng dụng liền tạo một nối kết đến host đó
thông qua giao thức TCP chẳng hạn. Hiện trạng được mô tả trong hình H8.1.
Tên máy được dịch sang địa chỉ, các số từ 1-5 thể hiện trình tự các bước xử lý (H8.1)
Miền phân cấp
DNS cài đặt không gian tên phân cấp dùng cho các đối tượng trên Internet. Các tên DNS
được xử lý từ phải sang trái, sử dụng các dấu chấm (.) làm ký tự ngăn cách. (Mặc dù các
tên DNS được xử lý từ phải qua trái, người dùng thường đọc chúng từ trái sang phải). Ví
dụ tên miền của một host là mail.cit.ctu.edu.vn. Chú ý rằng các tên miền được sử dụng
để đặt tên các đối tượng trên Internet, không phải chỉ được dùng để đặt tên máy. Ta có
thể mường tượng cấu trúc phân cấp của DNS giống như hình dáng cây. Hình H8.2 là
một ví dụ.
Cây phân cấp tên miền (H8.2)
Có thể thấy rằng, cây phân cấp không quá rộng ở mức đầu tiên. Mỗi quốc gia có một tên
miền, ngoài ra còn có 6 miền lớn khác gồm: edu, com, gov, mil, org và net. Sáu miền
204/215
lớn này nằm ở Mỹ. Những tên miền không chỉ ra tên nước một cách tường minh thì mặc
nhiên là nằm ở Mỹ.
Các server phục vụ tên
Một cấu trúc tên miền phân cấp hoàn chỉnh chỉ tồn tại trong ý niệm. Vậy thì trong thực
tế cấu trúc phân cấp này được cài đặt như thế nào? Bước đầu tiên là chia cấu trúc này
thành các cây con gọi là các vùng (zone). Ví dụ, hình H8.3 chỉ ra cách thức cấu trúc
phân cấp trong hình H8.2 được chia thành các vùng như thế nào.
Cấu trúc miền phân cấp được chia thành các vùng (H8.3)
Mỗi một vùng có thể được xem là đơn vị quản lý một bộ phận của toàn hệ thống phân
cấp. Ví dụ, vùng cao nhất của hệ thống phân cấp được quản lý bởi NIC (Network
Information Center), vùng ctu được quản lý bởi Trường Đại Học Cần Thơ.
Một vùng luôn có mối liên hệ đến các đơn vị cài đặt cơ bản trong DNS - các server tên.
Thông tin chứa trong một vùng được thiết lập tại hai hoặc nhiều server tên. Mỗi server
tên có thể truy xuất được qua mạng Internet. Client gởi yêu cầu đến server tên, server
tên sẽ trả lời cho yêu cầu đó. Câu trả lời đôi khi chứa thông tin cuối cùng mà client cần,
đôi khi lại chứa chỉ điểm đến một server tên khác mà client nên gởi câu hỏi đến đó. Vì
thế, theo cách nhìn thiên về cài đặt, người ta có thể nghĩ về DNS được cài đặt bằng cấu
trúc phân cấp các server tên hơn là bằng cấu trúc phân cấp các miền.
205/215
Cấu trúc phân cấp của các server tên (H8.4)
Để ý rằng mỗi vùng được cài đặt trong hai hoặc nhiều server tên với lý do dự phòng;
nghĩa là nếu một server bị chết sẽ còn các server khác thay thế. Mặt khác, một server tên
cũng có thể được dùng để cài đặt nhiều hơn một vùng.
Mỗi server tên quản lý thông tin về một vùng dưới dạng một tập các mẫu tin tài nguyên
(resource record). Mỗi mẫu tin tài nguyên là một ánh xạ từ tên sang giá trị (name to
value binding), cụ thể hơn là một mẫu tin gồm 5 trường:
(Tên, Giá trị, Kiểu, Lớp, TTL)
Các trường Tên và Giá trị là những gì chúng ta muốn có, ngoài tra trường Kiểu chỉ ra
cách thức mà Giá trị được thông dịch. Chẳng hạn, trường Kiểu = A chỉ ra rằng Giá trị
là một địa chỉ IP. Vì thế các mẫu tin kiểu A sẽ cài đặt kiểu ánh xạ từ tên miền sang địa
chỉ IP. Ví dụ như mẫu tin:
(ns.ctu.edu.vn, 203.162.41.166, A, IN)
chỉ ra rằng địa chỉ IP của host có tên ns.ctu.edu.vn là 203.162.41.166.
Ngoài ra còn có những kiểu khác:
• NS: Trường Giá trị chỉ ra tên miền của máy tính đang chạy dịch vụ tên, và
dịch vụ đó có khả năng thông dịch các tên trong một miền cụ thể.
Ví dụ mẫu tin:
206/215
(ctu.edu.vn, ns.ctu.edu.vn, NS, IN)
chỉ ra rằng server tên của miền ctu.edu.vn có tên là ns.ctu.edu.vn.
• CNAME: Trường Giá trị chỉ ra một cái tên giả của một host nào đó. Kiểu này
được dùng để đặt thêm bí danh cho các host trong miền.
• MX: Trường Giá trị chỉ ra tên miền của host đang chạy chương trình mail
server mà server đó có khả năng tiếp nhận những thông điệp thuộc một miền cụ
thể.
Ví dụ mẫu tin
(ctu.edu.vn, mail.ctu.edu.vn, MX, IN)
chỉ ra rằng host có tên mail.ctu.edu.vn là mail server của miền ctu.edu.vn.
Trường Lớp được sử dụng nhằm cho phép thêm vào những thực thể mạng không do
NIC quản lý. Ngày nay, lớp được sử dụng rộng rãi nhất là loại được Internet sử dụng;
nó được ký hiệu là IN.
Cuối cùng trường TTL chỉ ra mẫu tin tài nguyên này sẽ hợp lệ trong bao lâu. Trường
này được sử dụng bởi những server đang trữ tạm các mẫu tin của server khác; khi trường
TTL hết hạn, các mẫu tin chứa trường TTL hết hạn đó sẽ bị các server xóa khỏi cache
của mình.
Để hiểu rõ hơn cách thức các mẫu tin tài nguyên được thể hiện trong cấu trúc phân cấp,
hãy xem ví dụ được vẽ trong hình H8.3. Để đơn giản hóa vấn đề, chúng ta bỏ qua trường
TTL và cung cấp thông tin tương ứng cho một server tên làm nhiệm vụ quản lý cho một
vùng.
Đầu tiên, server tên gốc (root name server) sẽ chứa một mẫu tin NS cho mỗi server cấp
hai. Nó cũng chứa một mẫu tin A để thông dịch từ một tên server cấp hai sang địa chỉ IP
của nó. Khi được ghép với nhau, hai mẫu tin này cài đặt một cách hiệu quả một con trỏ
từ server gốc đến mỗi server cấp hai của nó.
207/215
Chú ý rằng trên lý thuyết các mẫu tin có thể được dùng để định nghĩa bất kỳ kiểu đối
tượng nào, DNS lại thường được sử dụng để định danh các host và site. DNS không
được dùng để định danh cá nhân con người hoặc các đối tượng khác như tập tin hay
thư mục, việc định danh này được thực hiện trong các hệ thống phục vụ tên khác. Ví dụ
X.500 là hệ thống định danh của ISO được dùng để định danh con người bằng cách cung
cấp thông tin về tên, chức vụ, số điện thoại, địa chỉ, và vân vân. X.500 đã chứng tỏ là
quá phức tạp nên không được hỗ trợ bởi các search engine nổi tiếng hiện nay. Tuy nhiên
nó lại là nguồn gốc phát sinh ra chuẩn LDAP (Lightweight Directory Access Protocol).
LDAP vốn là thành phần con của X.500 được thiết kế để làm phần front-end cho X.500.
Ngày nay LDAP đang trở nên phổ biến nhất là ở cấp độ công ty, tổ chức lớn, đóng vai
trò là hệ thống học và quản lý thông tin về người dùng của nó.
Phương pháp phân tích tên
Với một hệ thống phân cấp các server tên đã trình bày, bây giờ chúng ta đi tìm hiểu cách
thức một khách hàng giao tiếp với các server này để phân tích cho được một tên miền
thành địa chỉ. Giả sử một khách hàng muốn phân tích tên miền www.ctu.edu.vn, đầu
tiên khách hàng này sẽ gởi yêu cầu chứa tên này đến server tên gốc. Server gốc không
thể so khớp tên theo yêu cầu với các tên mà nó chứa, liền trả lời cho khách hàng một
208/215
mẫu tin kiểu NS chứa edu.vn. Server gốc cũng trả về tất cả các mẫu tin có liên quan đến
mẫu tin NS vừa nói, trong đó có mẫu tin kiểu A chứa địa chỉ của dns1.vnnic.vnn.vn.
Khách hàng chưa có thông tin cuối cùng mà nó muốn, tiếp tục gởi yêu cầu đến server
tên tại địa chỉ 203.162.57.105. Server tên thứ hai này lại không thể so khớp tên theo yêu
cầu với các tên mà nó chứa, tiếp tục trả lời cho khách hàng một mẫu tin loại NS chứa
tên ctu.edu.vn cùng với mẫu tin kiểu A tương ứng với tên server là ns.ctu.edu.vn. Khách
hàng lại tiếp tục gởi yêu cầu đến server tên tại địa chỉ 203.162.41.166 và lần này nhận
được câu trả lời cuối cùng có kiểu A cho tên www.ctu.edu.vn.
Ví dụ trên chắc chắn sẽ để lại nhiều câu hỏi về quá trình phân giải tên. Câu hỏi thường
được đặt ra là: Lúc khởi đầu, làm sao khách hàng có thể định vị được server gốc? Đây
là bài toán cơ bản đặt ra cho mọi hệ thống phục vụ tên và câu trả lời là: hệ thống phải tự
thân vận động để có được thông tin về các server gốc! Trong tình huống của hệ thống
DNS, ánh xạ từ tên sang địa chỉ của một hay nhiều server gốc được phổ biến cho mọi
người, nghĩa là ánh xạ đó được loan báo thông qua các phương tiện truyền thông khác
nằm ngoài hệ thống tên.
Tuy nhiên, trong thực tế không phải tất cả khách hàng đều biết về các server gốc. Thay
vào đó, chương trình khách hàng chạy trên mỗi host trong Internet được khởi động
với các địa chỉ lấy từ server tên cục bộ. Ví dụ, tất cả các host trong Khoa Công Nghệ
Thông Tin của Trường Đại Học Cần Thơ đều biết server tên nội bộ đang chạy trên máy
ns.cit.ctu.edu.vn. Đến lượt server tên cục bộ này lại chứa các mẫu tin tài nguyên cho
một hoặc nhiều server gốc của nó, ví dụ:
( . , a.root-servers.net, NS, IN) (a.root-server.net, 198.41.0.4, A, IN)
Trong ví dụ trên, server tên cục bộ có thông tin về một server tên gốc của nó (chú ý miền
gốc được ký hiệu bằng dấu chấm) là a.root-servers.net, địa chỉ IP tương ứng của server
gốc này là 198.41.0.4.
Từ đó, việc phân giải một tên miền bắt đầu từ câu truy vấn của khách hàng đến server
cục bộ. Nếu server cục bộ không có sẵn câu trả lời, nó sẽ gởi câu hỏi đến server từ xa
dùm cho khách hàng. Chuỗi hành động trên có thể được mô tả trong hình H8.5
209/215
Quá trình phân giải tên trong thực tế, các số 1 đến 8 chỉ ra trình tự thực hiện (H8.5)
210/215