Book CNTT MMT 12 Feb 2012 c2

Giáo trình Mạng máy tính
Khoa Công nghệ thông tin, Trường ĐHKHTN Tp.HCM
1
Chương 2
TẦNG ỨNG DỤNG
Sự ra đời của mạng máy tính xuất phát từ việc người dùng cần các
ứng dụng mạng hỗ trợ trong quá trình lưu trữ, xử lý và truyền thông
thông tin sao cho thuận lợi. Từ đó dẫn đến nhu cầu thiết kế các giao
thức hoạt động trên mạng (còn gọi là giao thức mạng) hỗ trợ các ứng
dụng mạng. Hơn 40 năm qua, nhiều ứng dụng mạng rất hữu ích và
tinh tế được đề xuất và xây dựng thành công. Các ứng dụng này bao
gồm các dịch vụ cổ điển dùng định dạng văn bản, phổ biến vào những
thập niên 70 và 80 như: thư điện tử dùng văn bản, truy cập máy tính từ
xa, truyền tập tin, thảo luận nhóm, chat; các ứng dụng đỉnh giữa thập
niên 90 như World Wide Web (lướt web, tìm kiếm, thương mại điện
tử), và hai ứng dụng đỉnh cao cuối thiên niên kỉ là gửi tin nhắn tức
thời đến danh sách bạn thân, chia sẻ tập tin theo mô hình mạng P2P;
và các ứng dụng về phim và âm thanh thành công khác như: gọi điện
thoại qua Internet, chia sẻ phim, truyền dữ liệu phim, nghe tin vô
tuyến (radio) qua Internet, xem truyền hình qua Internet (IPTV).
Ngoài ra, nhu cầu truy cập băng thông rộng đang tăng cao và việc truy
cập mạng không dây ngày càng trở nên phổ biến ở khắp nơi đòi hỏi
các ứng dụng mạng mới trong tương lai cần được chú ý xây dựng.
Chương này sẽ giới thiệu các khái niệm và cách thức hoạt động của
các ứng dụng mạng. Trước hết là định nghĩa khái niệm “tầng Ứng
dụng” [Application layer], tầng này chứa các dịch vụ mạng sẽ được sử
dụng bởi các ứng dụng mạng, các máy khách và các máy phục vụ, các
tiến trình, và các giao diện tầng Vận chuyển. Chương này sẽ nói sâu
hơn về các dịch vụ mạng bao gồm Web, thư điện tử, DNS, phân phối
tập tin P2P, và gọi điện thoại qua Internet dùng mô hình P2P, ngoài ra
còn đề cập chủ đề phát triển ứng dụng mạng trên hai TCP và UDP.
81
Chương 2. Tầng Ứng dụng
Đặc biệt nghiên cứu socket API và giới thiệu tổng quan các ứng dụng
khách – phục vụ [client – server] dùng ngôn ngữ Java.
Tầng Ứng dụng là điểm xuất phát tốt để nghiên cứu các giao thức
truyền thông. Nhiều ứng dụng sẽ được giới thiệu tiếp theo có hoạt
động dựa trên các giao thức truyền thông này. Các vấn đề được nhắc
đến kĩ hơn trong tầng này cũng sẽ được bàn lần lượt trong các giao
thức truyền thông thuộc tầng Vận chuyển, tầng Mạng và tầng Liên
kết.
I. Các nguyên tắc chung của ứng dụng mạng

Phát triển một ứng dụng mạng có nghĩa là lập trình một chương trình
ứng dụng chạy được trên nhiều hệ cuối khác nhau và phải có khả năng
truyền thông với nhau qua mạng.
Ví dụ 1: ứng dụng web có 2 chương trình riêng biệt truyền thông với
nhau: chương trình khách chạy trên hệ cuối (máy để bàn, máy tính
xách tay, PDA, điện thoại cầm tay, v.v), và chương trình phục vụ cung
cấp dịch vụ sẽ chạy trên máy phục vụ web.
Ví dụ 2: chia sẻ tập tin P2P, có một chương trình trên mỗi máy trạm
cuối trong cộng đồng chia sẻ tập tin. Trong trường hợp này, các
chương trình trên nhiều máy trạm sẽ giống nhau.
Do đó, khi phát triển ứng dụng mới, cần viết phần mềm chạy được
trên nhiều hệ cuối. Phần mềm này có thể được viết bằng bất kì ngôn
ngữ lập trình nào (có thể dùng C, Java, hay Python). Ứng dụng mạng
ở đây không phải là phần mềm chạy được trên các thiết bị mạng như
bộ định tuyến [router] hay bộ chuyển gói tin tầng Liên kết [Link-layer
switch], vì dù muốn viết những phần mềm ứng dụng trên các thiết bị
này cũng không thể. Như trong chương I đã giới thiệu (xem hình I-
24), các thiết bị mạng không hoạt động ở tầng Ứng dụng, thay vào đó
là hoạt động ở các tầng thấp hơn, đặc biệt là ở tầng Mạng và các tầng
bên dưới nữa. Cách thiết kế cơ bản, như trình bày trong hình II-1, vừa
giới hạn phần mềm chạy trên các hệ cuối vừa tạo điều kiện cho việc
triển khai và phát triển một dãy các ứng dụng mạng đa dạng.
82
I.1 Các kiến trúc ứng dụng mạng
Ứng dụng
Vận chuyển
Mạng
Liên kết
Vật lý ISP quốc gia/quốc tế
ĐTDĐ
Mạng di động
Mạng gia đình

ISP địa phương/vùng
Máy tính
Điểm truy cập vô tuyến

Ứng dụng
Vận chuyển
Mạng
Liên kết
Ứng dụng
Vật lý
Vận chuyển
Máy tính Mạng

Liên kết
Vật lý
Điểm truy cập vô tuyến
Máy tính
Mạng doanh nghiệp
Máy tính
Máy tính
Hình II-1: Truyền thông của một ứng dụng mạng giữa các hệ cuối ở tầng
Ứng dụng
Trước khi viết mã phần mềm, lập trình viên cần có bản thiết kế kiến
trúc ứng dụng [application architecture]. Kiến trúc ứng dụng khác với
kiến trúc mạng (ví dụ kiến trúc mạng 5 tầng được thảo luận trong
chương I). Trong nhận thức của người phát triển ứng dụng, kiến trúc
mạng là cố định và cung cấp một tập các dịch vụ cho các ứng dụng.
Mặt khác, kiến trúc ứng dụng được người phát triển ứng dụng thiết
kế nhằm mô tả ứng dụng có cấu trúc như thế nào trên nhiều hệ cuối
83
khác nhau. Trong việc chọn kiến trúc ứng dụng, lập trình viên thường
chọn một trong hai kiến trúc chính là kiến trúc khách-phục vụ [client-
server architecture] hoặc kiến trúc ngang hàng [peer to peer
architecture].
Trong kiến trúc khách-phục vụ, có một hệ cuối luôn luôn hoạt động,
được gọi là máy phục vụ [server], cung cấp các dịch vụ vốn được yêu
cầu từ các hệ cuối khác, được gọi là máy khách [clients]. Máy khách
có thể hoạt động không thường xuyên. Một ví dụ điển hình là ứng
dụng web, trong đó máy phục vụ web luôn hoạt động để nhận các yêu
cầu dịch vụ từ các trình duyệt chạy trên các máy khách. Khi máy phục
vụ web nhận được một yêu cầu về một đối tượng nào đó (chẳng hạn
một tập tin) từ một máy khách, máy phục vụ sẽ phản hồi bằng cách
gửi đối tượng được yêu cầu đến máy khách. Chú ý rằng với kiến trúc
khách – phục vụ, các máy khách không truyền thông với nhau, mà
phải thông qua máy phục vụ; ví dụ trong ứng dụng web, hai trình
duyệt không truyền thông trực tiếp với nhau, mà cả hai trình duyệt này
sẽ truyền thông với máy phục vụ. Tính chất khác của kiến trúc khách
– phục vụ là máy phục vụ có một địa chỉ được biết trước cố định,
được gọi là địa chỉ IP. Vì máy phục vụ có địa chỉ cố định và luôn luôn
hoạt động, máy khách có thể liên lạc với máy phục vụ thường xuyên
bằng cách gửi gói tin đến địa chỉ của máy phục vụ. Một vài ứng dụng
nổi tiếng phổ biến với kiến trúc khách – phục vụ gồm Web, FTP,
Telnet và thư điện tử. Kiến trúc khách – phục vụ được trình bày như
trong hình II.2(a).
Thường trong kiến trúc khách – phục vụ, một máy phục vụ không thể
đáp ứng đồng thời các yêu cầu từ nhiều máy khách. Ví dụ, một trang
mạng xã hội có thể trở nên đình trệ nếu trong hệ thống chỉ có một máy
phục vụ xử lý tất cả các yêu cầu. Vì vậy, một cụm gồm nhiều hệ cuối
– thường được biết đến với tên là trung tâm dữ liệu [Datacenter] –
dùng để tạo ra một máy phục vụ ảo mạnh trong kiến trúc khách – phục
vụ. Các dịch vụ ứng dụng dựa trên kiến trúc khách – phục vụ thường
đòi hỏi một cơ sở hạ tầng mạnh, buộc các nhà cung cấp dịch vụ phải
trang bị, cài đặt, và bảo trì các xưởng máy phục vụ [server farm].
Thêm vào đó, các nhà cung cấp dịch vụ phải trả các chi phí băng
thông và liên kết cho việc gửi và nhận dữ liệu từ mạng Internet. Các
dịch vụ phổ biến như máy tìm kiếm (Google), thương mại điện tử
84
(Amazon, e-Bay), thư điện tử (yahoo mail), mạng xã hội (MySpace,

Facebook), và chia sẻ phim (YouTube) là những dịch vụ có cơ sở hạ
tầng mạnh, tiết kiệm chi phí.
Trong kiến trúc ngang hàng (hoặc kiến trúc P2P), không cần có các
máy phục vụ. Thay vào đó, ứng dụng khai thác truyền thông trực tiếp
giữa các cặp hệ cuối kết nối với nhau, được gọi là các máy ngang
hàng (peer). Các máy ngang hàng không bị sở hữu bởi nhà cung cấp
dịch vụ, mà là các máy tính để bàn hay máy tính xách tay, đa số các
máy tính này được đặt bên trong nhà ở hay các tòa nhà văn phòng. Do
các máy tính ngang hàng truyền thông không thông qua máy phục vụ
nên kiến trúc này gọi là kiến trúc ngang hàng. Nhiều ứng dụng tăng
cường lưu lượng dựa trên kiến trúc P2P bao gồm ứng dụng phân phối
tập tin (BitTorent), chia sẻ tập tin (eMule, LimeWire), điện thoại
Internet (Skype) và IPTV (PPLive). Kiến trúc P2P được mô tả trong
hình II.2(b). Vài ứng dụng có kiến trúc lai đã kết hợp các tính chất của
kiến trúc P2P và kiến trúc khách–chủ. Ví dụ: nhiều ứng dụng gửi tin
nhắn tức thời, các máy phục vụ được dùng để truy vết địa chỉ IP của
người dùng, nhưng các thông điệp người dùng được gửi trực tiếp giữa
các thiết bị người dùng cuối (mà không thông qua các máy phục vụ
trung gian).
Một trong các đặc trưng của kiến trúc P2P là khả năng tự mở rộng. Ví
dụ trong ứng dụng chia sẻ tập tin dùng kiến trúc P2P, mặc dù mỗi máy
ngang hàng phát sinh tải công việc [workload] do yêu cầu các tập tin
từ các máy ngang hàng khác, nó cũng tham gia chia sẻ tập tin với các
máy ngang hàng khác. Và khi có thêm một máy ngang hàng tham gia
chia sẻ/yêu cầu tập tin thì mạng ngang hàng được mở rộng. Các kiến
trúc P2P cũng tiết kiệm chi phí, do không yêu cầu tài nguyên máy
phục vụ và băng thông máy phục vụ. Để giảm chi phí, các nhà cung
cấp dịch vụ (MSN, Yahoo, v.v) đang tập trung vào các kiến trúc P2P
cho các ứng dụng của họ. Tuy nhiên, các ứng dụng P2P gặp phải ba
thách thức chính:
1. Tương thích với nhà cung cấp dịch vụ Internet: đa số các nhà cung
cấp dịch vụ Internet địa phương (gồm cả nhà cung cấp dịch vụ sử
dụng DSL và cáp) đều cung cấp dịch vụ dùng băng thông “bất đối
xứng” (nghĩa là băng thông tải xuống cao hơn tải lên). Nhưng các
85
ứng dụng P2P như chia sẻ tập tin lại thiên về khai thác băng thông
tải lên, điều này tạo ra một áp lực về băng thông đáng kể dồn lên
nhà cung cấp dịch vụ Internet. Do đó, các ứng dụng P2P tương lai
cần thiết kế sao cho dễ dàng tương thích với ISP.
2. Bảo mật: Do bản chất mở và phân tán, các ứng dụng P2P có thể
đặt ra nhiều mục tiêu cần bảo mật.
3. Khuyến khích sử dụng: Sự thành công của các ứng dụng P2P
tương lai cũng phụ thuộc vào việc thuyết phục người dùng tự
nguyện chia sẻ băng thông, khả năng lưu trữ, và tính toán. Do đó,
thiết kế một hệ thống khuyến khích sử dụng cũng là một thách
thức cho kiến trúc P2P.
ISP quốc gia/quốc tế ISP quốc gia/quốc tế
ĐTDĐ ĐTDĐ
Mạng di động Mạng di động
Mạng gia đình Mạng gia đình

ISP địa phương/vùng ISP địa phương/vùng
Máy tính Máy tính
Điểm truy cập vô tuyến Điểm truy cập vô tuyến
Điểm truy cập vô tuyến Điểm truy cập vô tuyến

Mạng doanh nghiệp Mạng doanh nghiệp
Hình II-2: (a) Kiến trúc khách-phục vụ (b) Kiến trúc ngang hàng
I.2 Truyền thông giữa các tiến trình

Trước khi xây dựng một ứng dụng mạng, cần hiểu cách lập trình, chạy
ứng dụng trên nhiều hệ cuối, và truyền thông với nhau như thế nào. Theo
thuật ngữ hệ điều hành, thực sự không phải “chương trình” mà là “tiến
trình” truyền thông với nhau. Một tiến trình [process] có thể được xem
như là một chương trình [program] đang chạy trên một hệ cuối. Các tiến
trình đang chạy trên cùng một hệ cuối có thể truyền thông với nhau, gọi
là truyền thông liên tiến trình [interprocess communication], sử dụng các
qui tắc do hệ điều hành trên hệ cuối qui định.
86
Các tiến trình trên hai hệ cuối khác nhau, truyền thông với nhau bằng
cách trao đổi các thông điệp [message] thông qua mạng. Tiến trình gửi
[sending process] tạo ra và gửi các thông điệp vào mạng; tiến trình nhận
[receiving process] sẽ nhận các thông điệp này và có thể phản hồi bằng
cách gửi các thông điệp theo chiều ngược lại. Hình II.1 minh họa các tiến
trình truyền thông với nhau bằng cách dùng tầng Ứng dụng trong chồng
giao thức gồm năm tầng.
Tiến trình khách và tiến trình phục vụ
Một ứng dụng mạng bao gồm các cặp tiến trình gửi thông điệp cho nhau
thông qua mạng. Ví dụ, trong ứng dụng web, tiến trình của trình duyệt
trao đổi thông điệp với tiến trình phục vụ web. Trong hệ thống chia sẻ tập
tin P2P, một tập tin được truyền từ một tiến trình trên một máy ngang
hàng này đến một tiến trình trên một máy ngang hàng khác. Với mỗi cặp
tiến trình truyền thông, một tiến trình được đánh dấu là tiến trình khách
và một tiến trình được đánh dấu là tiến trình phục vụ. Với ứng dụng
Web, trình duyệt đang chạy là tiến trình khách và trình phục vụ Web
đang chạy là tiến trình phục vụ.Với ứng dụng chia sẻ tập tin P2P, tiến
trình tải tập tin về được gọi là tiến trình khách, và tiến trình cung cấp tập
tin được gọi là tiến trình phục vụ.
Trong một vài ứng dụng, như ứng dụng chia sẻ tập tin nói trên, một tiến
trình có thể vừa là tiến trình khách, vừa là tiến trình chủ. Tiến trình này
có thể thực hiện cả việc gửi đi và tải về các tập tin. Tuy nhiên, khi mô tả
việc truyền thông giữa hai tiến trình, phần còn lại của giáo trình này luôn
phân biệt rõ một tiến trình là khách và tiến trình kia là tiến trình phục vụ.
Tiến trình khách và tiến trình phục vụ được định nghĩa như sau:
Trong một phiên truyền thông giữa một cặp tiến trình, tiến trình khởi
động truyền thông (liên lạc với tiến trình khác lúc đầu phiên) được gọi là
tiến trình khách. Tiến trình chờ được liên lạc để bắt đầu phiên truyền
thông là tiến trình phục vụ.
Trong ứng dụng Web, một tiến trình trình duyệt khởi động liên lạc với
tiến trình phục vụ web; do đó một tiến trình trình duyệt là tiến trình
khách và tiến trình phục vụ web là tiến trình phục vụ. Trong ứng dụng
chia sẻ tập tin P2P, khi tiến trình từ máy ngang hàng A yêu cầu tiến trình
ở máy ngang hàng B gửi một tập tin nào đó, tiến trình từ máy ngang hàng
87
A là tiến trình khách và tiến trình từ máy ngang hàng B là tiến trình phục
vụ. Trong bối cảnh truyền thông giữa hai tiến trình khách – phục vụ,
phần sau của giáo trình này thỉnh thoảng sử dụng các cụm từ “phía
khách” với ngụ ý là “tiến trình khách” và “phía phục vụ” với ngụ ý là
tiến trình phục vụ. Cuối chương này đưa ra một số đoạn trình ứng dụng
mạng đơn giản gồm cả 2 phía khách và chủ nhằm mục đích minh họa.
Giao diện giữa tiến trình và mạng máy tính
Như đã đề cập ở trên, đa số các ứng dụng mạng đều bao gồm các cặp tiến
trình truyền thông, trong đó 2 tiến trình trong một cặp sẽ gửi qua lại các
thông điệp cho nhau. Bất kì thông điệp nào được gửi từ tiến trình này đến
tiến trình khác đều phải đi qua hạ tầng Mạng. Một tiến trình gửi các
thông điệp đi và nhận các thông điệp về từ mạng thông qua một giao diện
phần mềm được gọi là socket. Hãy xem một sự ví von sau đây để hiểu
hơn về các tiến trình và socket. Nếu xem tiến trình là ngôi nhà thì cánh
cửa ra vào của ngôi nhà chính là socket của một tiến trình. Một tiến trình
gửi một thông điệp cho một tiến trình khác, nó đẩy thông điệp ra khỏi
socket của nó (cửa ra). Ở đây tiến trình bên gửi giả định rằng có một hạ
tầng Vận chuyển nối socket của nó và socket của tiến trình bên nhận. Khi
thông điệp đến máy nhận, thông điệp sẽ đi qua socket (cửa vào) của tiến
trình nhận, và tiến trình nhận sẽ tiếp tục xử lý thông điệp nhận được.
Hình II.3 mô tả truyền thông socket giữa hai tiến trình Internet (giả sử
rằng giao thức thức vận chuyển mà hai tiến trình sử dụng là TCP). Như
được mô tả trong hình, socket là giao diện giữa tầng Ứng dụng và tầng
Vận chuyển. Từ này còn được dùng để chỉ đến một Giao diện lập trình
ứng dụng [Application Programming Interface – viết tắt là API], là do
các lập trình viên có thể sử dụng các đối tượng và hàm trong socket API
để xây nên các ứng dụng mạng. Người phát triển ứng dụng có thể điều
khiển mọi thứ ở tầng Ứng dụng của socket, nhưng điều khiển được rất ít
ở mức tầng Vận chuyển. Điều khiển mà người phát triển ứng dụng có thể
làm trên tầng Vận chuyển là (1) lựa chọn giao thức vận chuyển (2) khả
năng thiết đặt lại các thông số tầng Vận chuyển như kích thước lớn nhất
của vùng đệm [maximum buffer size] và kích thước lớn nhất của phân
đoạn [maximum segment size] (sẽ được đề cập đến trong chương III).
Khi người phát triển ứng dụng chọn một giao thức vận chuyển (nếu có
88
thể), ứng dụng sẽ dùng các dịch vụ tầng Vận chuyển mà giao thức đó
cung cấp. Chủ đề socket sẽ được nói chi tiết hơn trong phần VII và VIII.
Hệ cuối Hệ cuối
Được điều
Được điều
khiển bởi
Tiến trình Tiến trình khiển bởi
người phát
người phát
triển ứng dụng
triển ứng dụng
socket socket
Được điều
Được điều
khiển bởi hệ
TCP với các vùng TCP với các vùng khiển bởi hệ
điều hành
đệm và các biến đã đệm và các biến đã điều hành
được xác lập Internet được xác lập
Hình II-3: Các tiến trình ứng dụng, socket, và giao thức vận chuyển bên dưới
I.3 Các dịch vụ tầng Vận chuyển dành cho tầng Ứng dụng
Nhắc lại, socket là giao diện giữa tiến trình ứng dụng và giao thức
tầng Vận chuyển. Ứng dụng thuộc bên gửi sẽ đẩy các thông điệp vào
phía này của socket. Ở phía kia của socket, giao thức tầng Vận chuyển
có trách nhiệm nhận thông điệp và đưa thông điệp đến “cánh cửa
socket” thuộc bên nhận.
Nhiều dạng mạng, bao gồm cả Internet, cung cấp nhiều hơn một giao
thức ở tầng Vận chuyển. Khi xây một ứng dụng mạng, người phát
triển ứng dụng phải chọn một giao thức tầng Vận chuyển để dùng cho
việc vận chuyển thông điệp của ứng dụng. Để chọn được giao thức
thích hợp thì các dịch vụ trong từng giao thức tầng Vận chuyển sẵn có
cần được xem xét. Các dịch vụ tầng Vận chuyển có thể được phân loại
thành 4 tiêu chuẩn xét chọn: truyền dữ liệu đáng tin cậy, thông lượng,
mức độ kịp thời, và bảo mật.
Truyền dữ liệu đáng tin cậy
Như đã được thảo luận trong chương I, các gói tin có thể bị mất khi di
chuyển trên mạng. Ví dụ, một gói tin có thể làm tràn bộ đệm của một
89
bộ định tuyến, hoặc có thể bị hệ cuối hay bộ định tuyến bỏ đi sau khi
phát hiện gói tin nhận được có lỗi. Đối với nhiều ứng dụng, như thư
điện tử, truyền tập tin, truy cập từ xa, truyền tài liệu qua web, và các
ứng dụng tài chính, thì việc mất dữ liệu có thể gây ra hậu quả nghiêm
trọng (với ví dụ ứng dụng tài chính thì hậu quả nghiêm trọng cho cả
hai bên ngân hàng và khách hàng). Do đó, để hỗ trợ các ứng dụng này,
một số công đoạn phải được thực hiện thêm nhằm đảm bảo dữ liệu từ
ứng dụng bên này sẽ được truyền chính xác và hoàn toàn đến đầu ứng
dụng bên kia. Nếu một giao thức đảm bảo được dịch vụ truyền dữ
liệu như vậy thì được cho là giao thức truyền dữ liệu đáng tin cậy.
Một dịch vụ quan trọng mà giao thức tầng Vận chuyển có thể cung
cấp cho một ứng dụng là truyền dữ liệu đáng tin cậy trực tiếp giữa một
tiến trình cho một tiến trình. Khi một giao thức vận chuyển cung cấp
dịch vụ này, tiến trình gửi có thể chuyển dữ liệu đến socket và biết
chắc chắn dữ liệu sẽ đến tiến trình nhận mà không bị lỗi.
Khi giao thức tầng Vận chuyển không cung cấp dịch vụ truyền dữ liệu
đáng tin cậy, dữ liệu được gửi đi có thể không bao giờ đến tiến trình
nhận. Vấn đề này được chấp nhận đối với các ứng dụng dung lỗi
[loss-tolerant], đa số các ứng dụng đa phương tiện như ứng dụng âm
thanh/phim có tính thời gian thực hoặc lưu trữ dữ liệu âm thanh/thời
gian thực có thể bỏ qua cho việc mất chút ít dữ liệu. Trong các ứng
dụng đa phương tiện, dữ liệu bị mất có thể gây ra phiền phức một
chút, xong đó không phải là sự giảm sút chất lượng nghiêm trọng.
Thông lượng
Chương I đã giới thiệu khái niệm về thông lượng, trong bối cảnh
phiên truyền thông giữa hai tiến trình trên một đường mạng, là lượng
dữ liệu (bits) mà tiến trình gửi truyền đến tiến trình nhận trong một
đơn vị thời gian. Do có thể còn có các phiên truyền thông khác cũng
dùng chung đường mạng, và các phiên đó có thể đang truyền dữ liệu
hoặc tạm dừng việc truyền, nên thông lượng của một phiên truyền
thường biến động theo thời gian. Nhận định này dẫn đến một dịch vụ
tự nhiên mà tầng Vận chuyển có thể cung cấp là đảm bảo một mức
thông lượng tối thiểu nào đó. Khi đó, ứng dụng có thể yêu cầu một
dịch vụ đảm bảo thông lượng tối thiểu đạt r bits/giây, và giao thức vận
chuyển đảm bảo rằng thông lượng tối thiểu luôn luôn đạt ít nhất r
90
bits/giây. Một dịch vụ đảm bảo thông lượng tối thiểu như vậy thu hút
nhiều ứng dụng. Ví dụ, nếu ứng dụng điện thoại Internet mã hóa giọng
nói ở tốc độ 32kbps, cần gửi dữ liệu vào mạng và truyền dữ liệu đến
ứng dụng nhận cùng tốc độ này. Nếu giao thức tầng Vận chuyển
không thể cung cấp thông lượng này, ứng dụng cần mã hóa ở tốc độ
thấp hơn (và nhận đủ thông lượng để duy trì tỉ lệ mã hóa thấp hơn
này) hoặc có thể hủy bỏ phiên truyền. Các ứng dụng có yêu cầu về
thông lượng được gọi là ứng dụng nhạy băng thông [bandwidth-
sensitive application]. Nhiều ứng dụng đa phương tiện hiện tại là ứng
dụng nhạy băng thông, mặc dù có vài ứng dụng có thể dùng các kỹ
thuật mã hóa thích nghi để thích ứng với thông lượng sẵn dùng hiện
tại.
Trong khi các ứng dụng nhạy băng thông có các nhu cầu thông lượng
thực tế, thì các ứng dụng thích nghi có thể thích ứng với thông lượng
còn lại. Thư điện tử, truyền tập tin, và web là các ứng dụng thích nghi.
Dĩ nhiên, đường truyền cho phép thông lượng càng cao càng tốt,
nhưng thực tế thì luôn có giới hạn.
Mức độ kịp thời
Giao thức tầng Vận chuyển có thể cung cấp dịch vụ đảm bảo mức độ
kịp thời. Cũng như đảm bảo thông lượng, đảm bảo mức độ kịp thời
cũng có nhiều dạng. Ví dụ về sự đảm bảo mức độ kịp thời: đảm bảo
mỗi bit ứng dụng gửi truyền đến socket gửi, rồi socket gửi truyền sang
cho socket nhận trong vòng 1/10 giây. Một dịch vụ đảm bảo như vậy
có thể dành cho các ứng dụng thời gian thực, như điện thoại Internet,
môi trường ảo, hội thảo truyền hình, và các trò chơi mạng có nhiều
người. Thời gian trì hoãn kéo dài trong khi gọi điện thoại Internet sẽ
gây ra các cuộc điện đàm mất tự nhiên. Trong trò chơi trên mạng
nhiều người hoặc môi trường tương tác ảo, thời gian trì hoãn lâu giữa
hành động yêu cầu và nhận phản hồi từ môi trường (từ phía bên kia
của kết nối) làm ứng dụng ít có cảm giác thực tế hơn. Đối với các ứng
dụng phi thời gian thực, thời gian trì hoãn ít luôn luôn được mong
muốn hơn, nhưng không có ràng buộc chặt chẽ nào được yêu cầu về
thời gian trì hoãn giữa hai bên truyền.
Bảo mật
91
Cuối cùng giao thức tầng Vận chuyển có thể cung cấp cho một ứng
dụng với một hoặc nhiều dịch vụ bảo mật hơn. Ví dụ bên thiết bị gửi,
một giao thức tầng Vận chuyển mã hóa tất cả dữ liệu được tiến trình
gửi truyền đi; và phía thiết bị nhận, giao thức tầng Vận chuyển giải mã
dữ liệu trước khi truyền dữ liệu đến cho tiến trình nhận. Dịch vụ này
cung cấp sự đáng tin cậy giữa hai tiến trình, thậm chí dữ liệu dù bị
quan sát như thế nào đi nữa thì khi truyền giữa hai tiến trình gửi và
nhận thì vẫn an toàn. Giao thức tầng Vận chuyển cũng có thể cung cấp
các dịch vụ bảo mật khác ngoài sự đáng tin cậy, bao gồm đảm bảo
tính toàn vẹn dữ liệu và xác thực hệ cuối.
I.4 Các dịch vụ tầng Vận chuyển do Internet cung cấp
Trong các phần trên, các dịch vụ vận chuyển mà mạng máy tính cung
cấp vừa được xem xét một cách tổng quát. Trong phần này, những
hình thức dịch vụ hỗ trợ cho ứng dụng trên Internet sẽ được xem xét
chi tiết hơn. Internet (tổng quát hơn là mạng TCP/IP) có sẵn hai giao
thức vận chuyển cho ứng dụng mạng là UDP và TCP. Khi người phát
triển ứng dụng tạo một ứng dụng mạng mới chạy trên Internet, một
trong những quyết định đầu tiên là chọn UDP hay TCP. Mỗi giao thức
này hỗ trợ tập các dịch vụ khác nhau cho ứng dụng. Hình II-4 minh
họa các dịch vụ cho vài ứng dụng được chọn.
Dịch vụ TCP
Mô hình dịch vụ TCP bao gồm một dịch vụ hướng kết nối và một dịch
vụ truyền dữ liệu đáng tin cậy. Khi một ứng dụng dùng giao thức TCP
như một giao thức vận chuyển, ứng dụng đó sẽ dùng cả hai dịch vụ
này của giao thức TCP.
• Dịch vụ hướng kết nối (Connection-oriented service). TCP yêu
cầu phía khách và phía phục vụ trao đổi thông tin điều khiển tầng Vận
chuyển cho nhau trước khi các thông điệp tầng Ứng dụng bắt đầu
được trao đổi. Quá trình này gọi là thủ tục bắt tay [handshaking], đánh
động hai phía khách và phục vụ, và cho phép chúng chuẩn bị gửi nhận
các gói tin sau đó. Sau giai đoạn bắt tay, kết nối TCP được hình thành
giữa hai socket của hai tiến trình. Kết nối này có đặc tính là kết nối hai
chiều [full-duplex], nghĩa là hai tiến trình có thể đồng thời gửi thông
điệp cho nhau trên cùng kết nối. Khi ứng dụng kết thúc gửi các thông
92
điệp, nó phải hủy bỏ kết nối. TCP cung cấp dịch vụ “hướng kết nối”,
thay vì là dịch vụ “kết nối”, vì hai tiến trình được liên kết với nhau
theo một lối rất lỏng lẻo. Dịch vụ hướng kết nối sẽ được thảo luận chi
tiết hơn trong chương III.
• Dịch vụ truyền dữ liệu đáng tin cậy. Các tiến trình có thể dựa vào
TCP để truyền các gói dữ liệu chính xác và theo đúng thứ tự. Nghĩa là
khi tiến trình bên gửi truyền một chuỗi byte vào socket, TCP sẽ truyền
chuỗi byte đó đến socket bên nhận, đảm bảo dữ liệu không bị sai khác.
Chấp
nhận lỗi
Loại ứng dụng Băng thông Kịp thời
truyền
dữ liệu
Truyền tập tin Không Thích nghi Không
Thư điện tử Không Thích nghi Không
Dữ liệu web Không Thích nghi (vài kbps) Không
Điện thoại Internet / Âm thanh: vài kbps – 1Mbps Có: hàng

Hội nghị truyền Dung lỗi trăm
hình Phim: 10kpbs – 5Mbps miligiây
Lưu trữ âm thanh/ Có: vài

Dung lỗi Như trên
Phim giây
Có: hàng
Trò chơi tương tác Dung lỗi Vài kbps – 10kbps trăm
miligiây
Gửi thông điệp tức Có và

Không Thích nghi
thời Không
Hình II-4: Các yêu cầu của một số loại ứng dụng mạng tiêu biểu
Ngoài ra, TCP cũng còn có kỹ thuật kiểm soát tắc nghẽn. Dịch vụ này
hướng đến việc kiểm soát trình trạng tắc nghẽn chung trên toàn mạng
Internet, vì lợi ích chung của mạng Internet chứ không phải chỉ vì lợi
ích trực tiếp của cặp tiến trình truyền thông. Kỹ thuật này cảm nhận
mức độ tắc nghẽn mạng và dựa vào đó điều tiết lượng dữ liệu gửi đi.
Như sẽ được đề cập trong chương III, chức năng kiểm soát tắc nghẽn
93
TCP điều tiết dữ liệu trên từng kết nối TCP, nhằm chia sẻ băng thông
một cách công bằng. Việc hạn chế lượng dữ liệu truyền đi có thể ảnh
hưởng nặng nề đến các ứng dụng truyền âm và truyền hình thời gian
thực, vì các ứng dụng này thường có yêu cầu về thông lượng tối thiểu.
Ngoài ra, các ứng dụng thời gian thực có thể chấp nhận dữ liệu bị lỗi
đôi chút và vì vậy không cần đến dịch vụ truyền dữ liệu đáng tin cậy.
Do đó, nhân viên phát triển ứng dụng thường chọn UDP (thay vì TCP)
để viết ứng dụng thời gian thực. Commented [c
Dịch vụ UDP
UDP là giao thức vận chuyển đơn giản, gọn nhẹ, chỉ cung cấp các
dịch vụ tối cần thiết. Do UDP là giao thức phi kết nối
[connectionless], nó không thực hiện thủ tục bắt tay [handshaking]
trước khi hai tiến trình bắt đầu truyền thông. UDP không cung cấp
dịch vụ truyền dữ liệu đáng tin cậy – nghĩa là khi một tiến trình gửi
một thông điệp vào socket bên gửi, UDP không đảm bảo thông điệp sẽ
đến được tiến trình nhận. Ngoài ra, các thông điệp đến được tiến trình
nhận có thể có thứ tự không giống như thứ tự lúc gửi.
UDP không sử dụng cơ chế kiểm soát tắc nghẽn, do đó bên gửi có thể
đẩy dữ liệu xuống tầng dưới (tầng Mạng) với một tốc độ tùy ý. (Tuy
nhiên, thông lượng thật giữa 2 bên có thể nhỏ hơn tốc độ này, do
đường truyền có sự giới hạn về băng thông hoặc do sự tắc nghẽn
mạng). Các ứng dụng thời gian thực thường chấp nhận việc mất mát
“chút ít” dữ liệu, nhưng lại đòi phải cho phép truyền ở một tốc độ tối
thiểu để hoạt động hiệu quả, do đó người phát triển ứng dụng loại này
đôi khi lại chọn UDP, và điều này hoàn toàn đi ngược với cơ chế kiểm
soát kiểm soát tắc nghẽn của TCP. Trên một phương diện khác, do
nhiều tường lửa [firewall] thường được cấu hình để ngăn chặn các gói
tin UDP, nên ngày càng nhiều nhà thiết kế chọn triển khai các ứng
dụng lại này trên nền TCP, thay vì UDP.
Bảo mật TCP
Không phải TCP hay UDP cung cấp mã hóa – dữ liệu do tiến trình gửi
truyền đến socket của nó là dữ liệu sẽ qua mạng đến tiến trình đích.
Do đó, nếu tiến trình gửi truyền một mật khẩu ở dạng văn bản rõ (tức
là không được mã hóa) vào socket của nó, mật khẩu văn bản rõ sẽ đi
94
qua tất cả các liên kết giữa tiến trình gửi và tiến trình nhận, có thể
được tìm thấy và phát hiện ở bất kì liên kết ngăn cản nào. Vì tính
riêng tư (privacy) và các vấn đề bảo mật khác rất cần thiết cho các ứng
dụng mạng, truyền thông Internet vừa phát triển một phần mở rộng
cho TCP được gọi là Secure Sockets Layer (SSL). TCP mở rộng với
SSL không chỉ có đủ các chức năng của một TCP truyền thống mà
còn cung cấp thêm các dịch vụ bảo mật quan trọng cho giao tiếp giữa
tiến trình - tiến trình, bao gồm mã hóa, toàn vẹn dữ liệu, và chứng
thực đầu cuối. SSL không phải là một giao thức vận chuyển Internet
thứ ba, không cùng mức với TCP và UDP, nhưng thay vào đó là sự
mở rộng của TCP, với các mở rộng đang dùng ở tầng Ứng dụng. Đặc
biệt, nếu một ứng dụng muốn dùng các dịch vụ của SSL, nó cần chứa
mã SSL (các thư viện chứa các lớp được tùy chỉnh) trong cả hai bên
ứng dụng chủ và khách. SSL có bộ thư viện socket riêng của nó,
tương tự như bộ thư viện socket TCP. Khi một ứng dụng dùng SSL,
tiến trình gửi chuyển dữ liệu gốc đến SSL socket; SSL bên máy gửi
mã hóa dữ liệu và truyền dữ liệu đã được mã hóa đến socket TCP, tiếp
đó dữ liệu đã mã hóa di chuyển từ socket TCP bên tiến trình gửi lên
Internet và từ Internet đến socket TCP bên tiến trình nhận. Socket
nhận truyền dữ liệu đã mã hóa đến SSL để giải mã. Cuối cùng, SSL
truyền dữ liệu văn bản rõ sau khi giải mã đến tiến trình nhận. SSL
được bàn đến chi tiết hơn trong chương 8.
Các dịch vụ giao thức vận chuyển Internet không cung cấp
Phần trên đã xét đến 4 dịch vụ mà giao thức vận chuyển có thể cung
cấp: truyền dữ liệu đáng tin cậy, thông lượng, mức độ kịp thời, và bảo
mật. Rõ ràng là TCP có cung cấp dịch vụ truyền dữ liệu đáng tin cậy.
Ngoài ra TCP có thể kết hợp với SSL [Secure Sockets Layer]- một mở
rộng ở tầng Ứng dụng, nhằm cung cấp một dịch vụ bảo mật. Trong
mô tả ngắn gọn về TCP và UDP, các dịch vụ về đảm bảo thông lượng
tối thiểu và mức độ kịp thời đã không được đề cập đến, cũng chính là
các dịch vụ không có trong các giao thức vận chuyển Internet này.
Như vậy liệu các ứng dụng cần đảm bảo mức độ kịp thời như điện
thoại Internet không thể chạy được trên Internet? Câu trả lời là
“không” – bằng chứng là Internet đã có các ứng dụng loại này trong
nhiều năm qua. Các ứng dụng này hoạt động khá tốt do chúng được
thiết kế để thích ứng với tình trạng thiếu sự đảm bảo này. Dù vậy,
95
những thiết kế dù thông minh cũng có những hạn chế của nó, một khi
thời gian trì hoãn vượt quá giới hạn, vốn là tình trạng cũng thường xảy
ra trên Internet. Tóm lại, Internet có thể cung cấp dịch vụ thích hợp
cho các ứng dụng như điện thoại Internet, nhưng nó không có một sự
đảm bảo nào về thông lượng tối thiểu hay mức độ kịp thời.
Hình II.5 mô tả các giao thức vận chuyển được các ứng dụng phổ biến
trên Internet sử dụng: thư điện tử, truy cập máy trạm từ xa, Web, và
truyền tập tin; tất cả đều dùng TCP. Các ứng dụng này dùng TCP vì
TCP cung cấp một dịch vụ truyền dữ liệu đáng tin cậy, đảm bảo dữ
liệu sẽ được truyền đến đích. Điện thoại Internet là một ứng dụng điển
hình sử dụng UDP. Mỗi bên của ứng dụng điện thoại Internet cần gửi
gửi dữ liệu qua mạng với tốc độ tối thiểu (xem hình II.4); điều này là
khả thi với UDP hơn là TCP. Cũng vậy, các ứng dụng điện thoại
Internet có khả năng dung lỗi (chấp nhận mất chút ít mất dữ liệu), do
đó chúng không cần đến các dịch vụ truyền dữ liệu đáng tin cậy mà
TCP cung cấp.
Giao thức Giao thức vận chuyển
Ứng dụng
tầng Ứng dụng được dùng
Thư điện tử SMTP [RFC 5321] TCP
Tuy cập từ xa Telnet [RFC 854] TCP
Web HTTP [RFC 2616] TCP
Truyền file FTP [RFC 959] TCP
HTTP (như YouTube),

Truyền hình TCP hoặc UDP
RTP
Điện thoại SIP, RTP, hoặc các giao

UDP
Internet thức tư hữu (như Skype)
Hình II-5: Các ứng dụng Internet phổ biến, các giao thức tầng Ứng dụng và
các giao thức vận chuyển được sử dụng
Đánh địa chỉ các tiến trình
Phần trên vừa trình bày về các dịch vụ vận chuyển giữa hai tiến trình
truyền thông. Nhưng một tiến trình làm sao nhận biết được với một
tiến trình khác mà nó muốn truyền thông, chỉ bằng việc dùng các dịch
96
vụ này? Để xác định tiến trình nhận, hai thông tin cần được làm rõ: (1)
tên hoặc địa chỉ của hệ cuối phía bên nhận, và (2) định danh tiến trình
nhận trên hệ cuối đó.
Trong Internet, hệ cuối được xác định nhờ địa chỉ IP [IP address].
Khái niệm về địa chỉ IP được đề cập chi tiết trong chương IV. Tạm
thời, có thể xem địa chỉ IP có chiều dài 32 bit và có thể dùng để xác
định duy nhất một hệ cuối (Tuy nhiên, trong kỹ thuật NAT sẽ được
nhắc đến trong chương IV, một mình địa chỉ IP là chưa đủ để xác định
địa chỉ một hệ cuối).
Ngoài địa chỉ của hệ cuối bên nhận, hệ cuối bên gửi phải xác định
được tiến trình nào đang chạy trên hệ cuối bên nhận sẽ nhận thông
điệp. Thông tin này cần thiết vì một hệ cuối có thể có nhiều ứng dụng
mạng đang chạy đồng thời. Khái niệm số hiệu cổng [port number]
đưa ra cho mục đích xác định tiến trình. Mỗi ứng dụng phổ biến đều
được gán một ( hoặc vài) số hiệu cổng mặc định. Ví dụ, ứng dụng web
trên máy phục vụ được chỉ định số hiệu cổng là 80, tiến trình thư điện
tử ở máy phục vụ (dùng giao thức SMTP) được chỉ định cổng 25. Có
thể tham khảo danh mục các cổng mặc định dành cho các giao thức
chuẩn trên Internet tại trang web http://www.iana.org. Khi một lập
trình viên tạo một ứng dụng mạng mới, ứng dụng phải được chỉ định
một số hiệu cổng mới. Các số hiệu cổng sẽ được trình bày rõ hơn
trong chương III.
I.5 Các giao thức ở tầng Ứng dụng
Phần trên cho thấy rằng các tiến trình truyền thông với các tiến trình
khác bằng cách gửi thông điệp đến socket của nó. Tuy nhiên, cần phải
làm rõ các thông điệp này có cấu trúc ra sao, ý nghĩa các trường trong
thông điệp, khi nào thì tiến trình gửi thông điệp. Trả lời các câu hỏi
này sẽ dẫn đến địa hạt của các giao thức tầng Ứng dụng. Một giao
thức tầng Ứng dụng định nghĩa cách thức các tiến trình ứng dụng vận
hành trên các hệ cuối khác nhau, trao đổi thông điệp cho nhau. Đặc
biệt, giao thức tầng Ứng dụng định nghĩa:
• Các kiểu thông điệp được trao đổi, chẳng hạn như thông điệp
yêu cầu [request message] và thông điệp phản hồi [response
message].
97
• Cú pháp của các loại thông điệp khác nhau, chẳng hạn như các
trường [fields] trong thông điệp và mô tả mỗi trường.
• Ngữ nghĩa của các trường, nghĩa là ý nghĩa của thông tin chưa
trong trường.
• Quy tắc nhằm xác định thời điểm và cách thức một tiến trình
gửi thông điệp và phản hồi khi nhận được một thông điệp.
Một số giao thức tầng Ứng dụng được mô tả chi tiết trong các RFC, và
do đó chính là các giao thức công cộng. Chẳng hạn, giao thức HTTP
được công bố trong RFC 2616. Nếu một nhân viên phát triển ứng
dụng trình duyệt Web tuân thủ các quy tắc trong RFC 2616 này, trình
duyệt có thể tải về những trang Web từ bất kỳ một máy phục vụ Web
nào cũng tuân thủ RFC đó. Có nhiều giao thức tầng Ứng dụng là giao
thức tư hữu và không có ý định trở thành công hữu. Như các ứng dụng
chia sẻ tập tin theo kiến trúc P2P hiện hành, sử dụng các giao thức tư
hữu.
Cần phân biệt sự khác nhau giữa ứng dụng mạng và giao thức tầng
Ứng dụng. Một giao thức tầng Ứng dụng chỉ là mảnh ghép của một
ứng dụng mạng. Hãy xem vài ví dụ. Web là ứng dụng theo kiến trúc
khách-phục vụ, cho phép người dùng lấy về những tài liệu từ máy
phục vụ Web theo yêu cầu. Các ứng dụng Web bao gồm nhiều thành
phần, gồm một chuẩn về dạng thức tài liệu ( đó là HTML), trình duyệt
Web (như Firefox, hoặc Microsoft Internet Explorer), trình phục vụ
Web (Ví dụ như Apache, hoặc Microsoft Internet Information Server)
và một giao thức tầng Ứng dụng. Một giao thức tầng Ứng dụng của
Web như HTTP, định nghĩa dạng thức và thứ tự qua lại của các thông
điệp giữa trình duyệt Web và trình phục vụ Web. Do đó, HTTP chỉ là
một mảnh ghép (mặc dù là mảnh ghép quan trọng) của ứng dụng Web.
Một ví dụ khác, một ứng dụng thư điện tử cũng có nhiều thành phần,
bao gồm trình phục vụ thư [mail server] quản lý các hòm thư của
người dùng; trình đọc thư [mail reader] cho phép người dùng đọc và
soạn thư; một tiêu chuẩn định nghĩa cấu trúc các thư điện tử; và các
giao thức tầng Ứng dụng định nghĩa cách thức trao đổi các thư điện tử
giữa các trình phục vụ thư, giữa trình phục vụ thư và trình đọc thư,
cũng như cách thức thông dịch các thành phần trên một thư điện tử
(như phần header). Giao thức tầng Ứng dụng chính yếu của thư điện
98
tử là SMTP (Simple Mail Transfer Protocol, RFC 5321), cũng là một

mảnh ghép quan trọng cũa ứng dụng thư điện tử mà thôi.
I.6 Các ứng dụng sẽ được giới thiệu trong chương này
Các ứng dụng mới trên Internet, cả tư hữu và công hữu, được phát
triển hàng ngày. Thay vì khảo sát một số lượng lớn các ứng dụng
Internet, chương này chỉ tập trung ở một số ít các ứng dụng được sử
dụng nhiều và quan trọng. Chương này sẽ đề cập đến năm ứng dụng
quan trọng: Web, truyền tập tin, thư điện tử, dịch vụ danh bạ
[directoty services] và các ứng dụng P2P. Web sẽ được khảo sát trước
tiên, không chỉ vì nó là loại hình ứng dụng quá phổ biến, mà còn vì
tính đơn giản, dễ hiểu của giao thức tầng Ứng dụng của Web là
HTTP. Sau đó, ứng dụng truyền tập tin FTP sẽ được xem xét, do nó
có một sự tương phản so với HTTP. Kế đến sẽ là thư điện tử, một loại
ứng dụng được sử dụng nhiều nhất trên Internet. Thư điện tử hơi phức
tạp hơn Web, theo nghĩa là nó không phải sử dụng một, mà là nhiều
giao thức tầng Ứng dụng. Sau thư điện tử là DNS, giao thức cung cấp
một dịch vụ danh bạ trên Internet. Hầu hết người dùng đều không làm
việc trực tiếp với DNS, mà gián tiếp thông qua các ứng dụng khác
(như Web, truyền tập tin, thư điện tử). DNS minh họa một cách ngoạn
mục cách thức cài đặt một phần chức năng quan trọng của mạng lõi
(dịch từ tên sang địa chỉ) ở tầng Ứng dụng. Sau dùng, chương này sẽ
đề cập đến một số ứng dụng P2P, gồm ứng dụng phân phối tập tin, cơ
sở dữ liệu phân bố và điện thoại IP.
II. Web và giao thức HTTP

Trước những năm đầu thập niên 1990, giới nghiên cứu, giáo dục, và
sinh viên chủ yếu sử dụng Internet để truy cập vào các thiết bị từ xa,
truyền tập tin, nhận và gửi tin tức hoặc thư điện tử. Mặc dù các ứng
dụng này khá đắc dụng, nhưng Internet vẫn ít được bên ngoài biết đến.
Từ năm 1991, một ứng dụng mới xuất hiện, gọi là World Wide Web.
Web là ứng dụng Internet đầu tiên thu hút sự quan tâm công chúng.
Nó đã thay đổi một cách sâu sắc và vẫn đang tiếp tục thay đổi, cách
thức con người tương tác với bên trong và bên ngoài môi trường làm
việc của họ. Nó đã nâng Internet trở thành mạng dữ liệu quan trọng
nhất trong số nhiều mạng dữ liệu.
99
Có lẽ điểm hấp dẫn nhất của Web đáp ứng theo yêu cầu. Người dùng
nhận được cái họ cần, vào thời điểm họ muốn. Điểm này không giống
như vô tuyến truyền thanh hay vô tuyến truyền hình, vốn bắt người ta
muốn thu thanh hoặc thu hình thì phải bắt đài vào lúc chương trình
được phát, và chỉ nhận được nội dung nhà đài phát. Ngoài tính sẵn
sàng đáp ứng theo yêu cầu, Web còn có nhiều đặc tính nổi trội khác
làm người ta yêu thích. Mọi người đều có thể xuất bản thông tin lên
Web với chi phí rất thấp. Nhờ vào các máy tìm kiếm [search engines]
và các siêu liên kết [hyperlink], người ta có thể “đi lại” trên một “đại
dương” Web mênh mông rộng lớn. Các đối tượng đồ họa trên Web
kích thích các giác quan của người ta. Các mẫu nhập, Java applets, và
nhiều thứ khác khác giúp người dùng tương tác với các trang web.
Ngoài ra, web còn cung cấp danh mục truy cập đến một lượng lớn các
tài liệu âm thanh, phim ảnh được trữ sẵn, gọi chung là các tài liệu đa
phương tiện [multimedia], và người dùng có thể truy cập đến chúng
khi có yêu cầu.
II.1 Tổng quan về HTTP
HyperText Transfer Protocol (HTTP), giao thức tầng Ứng dụng của
Web, là thành phần trung tâm của Web. Được mô tả trong RFC1945
và RFC 2616, HTTP được triển khai ở hai chương trình: chương trình
khách và chương trình phục vụ. Chương trình khách và chương trình
phục vụ chạy trên các hệ cuối khác nhau, truyền thông với nhau bằng
cách trao đổi các thông điệp định dạng HTTP. HTTP định nghĩa cấu
trúc của các thông điệp này, và cách thức mà máy phục vụ và máy
khách sẽ trao đổi thông điệp với nhau. Trước khi giải thích chi tiết về
giao thức HTTP, chúng ta cần xem qua các thuật ngữ Web.
Trang web [web page, còn gọi là tài liệu Web] bao gồm nhiều đối
tượng [objects]. Đơn giản, một đối tượng được chứa trong một tập tin
– như tập tin định dạng HTML, tập tin ảnh định dạng JPEG, tập tin
chứa Java Applet, hay tập tin chứa một đoạn phim – tập tin này có thể
được định vị bằng một URL [viết tắt của Universal Resource
Locator]. Đa số các trang web bao gồm một tập tin HTML cơ sở và
tham chiếu đến nhiều đối tượng. Ví dụ, nếu một trang web chứa văn
bản định dạng HTML và năm ảnh định dạng JPEG, thì trang web này
gồm sáu đối tượng: tập tin HTML cơ sở và năm tập tin ảnh. Tập tin
100
HTML cơ sở tham chiếu đến các đối tượng khác bằng các địa chỉ
URL đến các đối tượng. Mỗi địa chỉ URL có hai thành phần: tên của
máy tính chứa đối tượng và đường dẫn của đối tượng. Ví dụ, địa chỉ
URL:
http://www.someSchool.edu/someDepartment/picture.gif
có www.someSchool.edu là tên thiết bị chủ và /someDepartment/ là
đường dẫn đến thư mục chứa tập tin ảnh picture.gif. Do các trình
duyệt web [Web browsers] (như Internet Explorer và Firefox) hoạt
động phía “khách” của giao thức HTTP, trong ngữ cảnh của web, các
thuật ngữ “trình duyệt” và “chương trình khách” sẽ được dùng thay
đổi luân phiên. Các trình phục vụ web [Web servers] cung cấp chức
năng “phục vụ” của giao thức HTTP, chứa các đối tượng web, mỗi đối
tượng có thể định vị bằng một địa chỉ URL. Apache và Microsoft
Internet Information Server (IIS) là hai trình phục vụ web khá phổ
biến hiện nay.
HTTP định nghĩa cách thức các trình duyệt web yêu cầu các trang
web từ trình phục vụ web và cách thức trình phục vụ web truyền các
trang web về cho các trình duyệt web. Sự tương tác giữa chương trình
khách và chương trình phục vụ sẽ được nói chi tiết sau, nhưng ý tổng
quát được minh họa trong hình II-6. Khi một người dùng yêu cầu một
trang web (ví dụ như khi nhấn chọn một siêu liên kết), trình duyệt gửi
các thông điệp yêu cầu [request messages] (yêu cầu các đối tượng
thuộc trang web) đến trình phục vụ. Trình phục vụ nhận thông điệp
yêu cầu, xử lý và trả về thông điệp phản hồi [response message] có
chứa các đối tượng được yêu cầu.
Hình 2.6. Mô hình yêu cầu - phản hồi
101
Máy phục vụ Web

[Web server]
Th hản
Th u cầ iệp
ôn hồ
p
Th êu c
yê n g đ
u
gđ i
hồ p
ôn ầu
ản iệ
iệp
ph ng đ
gđ
i
ô
Th
iệp
ô
Máy tính dùng Firefox

Máy tính dùng Internet Explorer
Hình II-6: Quá trình làm việc của HTTP

Giao thức HTTP sử dụng TCP như một giao thức truyền thông nền.
Trước tiên, chương trình khách khởi tạo một kết nối TCP đến trình
phục vụ Web. Khi kết nối TCP đã được thiết lập, tiến trình của
chương trình khách và tiến trình của trình phục vụ Web gửi/nhận dữ
liệu qua/từ kết nối TCP thông qua socket tương ứng ở mỗi tiến trình.
Như đã được mô tả trong mục I, socket phía khách là “cánh cửa” giữa
tiến trình khách và kết nối TCP, còn socket phía phục vụ là “cánh
cửa” giữa tiến trình phục vụ và kết nối TCP đó. Chương trình khách
gửi các thông điệp yêu cầu vào socket của nó và nhận thông điệp phản
hồi cũng từ socket này. Tương tự, trình phục vụ nhận các thông điệp
yêu cầu từ socket của nó và gửi các thông điệp phản hồi đến chính
socket đó. Khi tiến trình khách đã gửi thông điệp vào socket của nó,
thông điệp “rời khỏi vòng tay” của tiến trình khách và “lọt vào tay”
của kết nối TCP. Nhắc lại mục I đã đề cập đến đặc tính TCP cung cấp
một dịch vụ truyền dữ liệu đáng tin cậy cho HTTP. Điều này ngụ ý
rằng mỗi thông điệp yêu cầu được tiến trình khách gửi đến tiến trình
phục vụ được chuyển giao trọn vẹn, chính xác; tương tự, mỗi thông
điệp phản hồi được gửi từ tiến trình phục vụ đến tiến trình khách cũng
được chuyển giao trọn vẹn, chính xác. Rõ ràng, ưu điểm của kiến trúc
phân tầng được thể hiện ở đây, là HTTP không cần quan tâm đến việc
hư mất của dữ liệu hoặc cách TCP phục hồi dữ liệu đã mất hay bố trí
102
lại trật tự các gói tin. Đó là việc của TCP và các giao thức ở các tầng
thấp hơn trong chồng giao thức.
Tiến trình phục vụ gửi các tập tin được yêu cầu đến các tiến trình
khách mà không lưu lại bất kì thông tin trạng thái nào của tiến trình
khách. Nếu một tiến trình khách nào đó yêu cầu nhận cùng một đối
tượng lần thứ hai trong vòng vài giây, thì tiến trình phục vụ không hề
phản đối, mà vẫn gửi lại các đối tượng đó, bởi nó không biết trước đây
nó đã từng làm những gì. Vì tiến trình phục vụ không quản lý bất kỳ
thông tin nào về các tiến trình khách, giao thức HTTP được gọi là một
giao thức phi trạng thái [stateless protocol]. Lưu ý, ứng dụng web có
kiến trúc khách – phục vụ như đã được đề cập đến trong mục I. Do đó
máy phục vụ web phải luôn luôn hoạt động, có một địa chỉ IP cố định,
và phục vụ các yêu cầu đến từ rất nhiều trình duyệt khác nhau.
II.2 Kết nối thường trực và không thường trực
Trong các ứng dụng Internet, tiến trình khách và tiến trình phục vụ
truyền thông với nhau từng chập, trong đó tiến trình khách phát ra một
chuỗi các yêu cầu và tiến trình phục vụ đáp ứng lại các yêu cầu này.
Tùy loại ứng dụng và cách thức ứng dụng được dùng, chuỗi yêu cầu
từ tiến trình khách có thể được thực hiện liên tiếp nhau, định kỳ, hoặc
không liên tục. Khi tương tác khách – phục vụ diễn ra trên nền giao
thức TCP, người phát triển ứng dụng cần đưa ra một quyết định quan
trọng: mỗi cặp yêu cầu/phản hồi sẽ sử dụng một kết nối TCP riêng,
hay tất cả các yêu cầu và phản hồi sẽ sử dụng chung một kết nối TCP.
Theo cách đầu, ứng dụng được cho là dùng kết nối không thường
trực [non-persistent connections], còn theo cách sau thì ứng dụng
được cho là sử dụng kết nối thường trực [persistent connections]. Để
hiểu sâu về điểm thiết kế này, phần sau sẽ khảo sát về những thuận lợi
và bất lợi của cách kết nối trong giao thức HTTP, vốn cho phép dùng
cả hai cách kết nối không thường trực và thường trực. Mặc dù HTTP
sử dụng cách kết nối thường trực như cách mặc định, nhưng các
chương trình khách và phục vụ có thể lựa chọn cách kết nối không
thường trực để thay thế.
HTTP với các kết nối không thường trực
103
Phần này xem xét việc truyền 1 trang Web từ máy phục vụ đến máy
khách, sử dụng kết nối không thường trực. Giả sử có một trang web
cần được truyền từ máy phục vụ đến máy khách, và trang web này
chứa một tập tin HTML và 10 ảnh JPEG, cả 11 đối tượng này cùng
được lưu trên cùng một server. Giả sử trang web cần truy cập có địa
chỉ:
http: //www. someSchool. edu/someDepartment/home. Index
Sau đây là quá trình thực hiện từng bước:
1. Tiến trình khách khởi tạo một kết nối TCP đến máy phục vụ
www.someSchool.edu đang chờ tại cổng 80, đó là số hiệu cổng
mặc định cho ứng dụng web dùng HTTP. Liên kết với kết nối TCP
này là 1 socket ở phía tiến trình phục vụ và 1 socket ở phía tiến
trình khách.
2. Tiến trình khách gửi một thông điệp yêu cầu đến tiến trình phục
vụ qua socket của nó (tức tiến trình khách). Thông điệp yêu cầu
chứa đường dẫn /someDepartment/home.index (chi tiết thông điệp
yêu cầu sẽ được trình bày chi tiết ở bên dưới).
3. Tiến trình phục vụ nhận được thông điệp yêu cầu từ socket của nó,
lấy tập tin /someDepartment/home.index đang được lưu trong
không gian lưu trữ ( trên RAM hoặc trên đĩa cứng), đóng gói tập
tin này vào thông điệp phản hồi, và gửi thông điệp phản hồi đến
tiến trình khách thông qua socket của tiến trình phục vụ.
4. Tiến trình phục vụ yêu cầu TCP đóng kết nối TCP (TCP sẽ đợi
cho đến khi tiến trình khách nhận toàn bộ thông điệp phản hồi).
5. Tiến trình khách nhận thông điệp phản hồi. Kết nối TCP được hủy
bỏ. Thông điệp xác định đối tượng được đóng gói kèm theo nó là
một tập tin HTML. Tiến trình khách tách nội dung HTML từ
thông điệp phản hồi thành tập tin HTML, kiểm tra tập tin HTML
này, và tìm các tham chiếu đến 10 đối tượng ảnh JPEG.
6. Bốn bước đầu được lặp lại cho mỗi đối tượng ảnh JPEG.
Khi trình duyệt nhận được nội dung trang web, sẽ cho hiển thị đến
người dùng. Hai trình duyệt khác loại có thể hiển thị cùng một trang
web hơi khác nhau. HTTP không liên quan đến một trang web được
104
hiển thị như thế nào. Đặc tả HTTP (RFC 1945 và RFC 2616) định
nghĩa giao thức làm việc giữa trình phục vụ HTTP và chương trình
khách.
Các bước trên mình họa cho cách dùng kết nối không thường trực, là
loại kết nối mà TCP sẽ đóng sau khi trình phục vụ gửi xong đối tượng,
nghĩa là kết nối này sẽ không dành cho các đối tượng khác. Lưu ý
rằng mỗi kết nối TCP loại này được dùng cho đúng một thông điệp
yêu cầu và một thông điệp phản hồi. Do đó, trong ví dụ này, khi người
dùng yêu cầu trang web, có 11 kết nối TCP được thiết lập và hủy bỏ.
Trong các bước đã được mô tả ở trên, còn một vấn đề làm rõ là 10 tập
tin JPEG sẽ được truyền trên 10 kết nối TCP nối tiếp nhau, hay có vài
kết nối kết nối TCP song hành. Thực ra người dùng có thể điều chỉnh
cấu hình cho trình duyệt để thiết đặt mức độ cho phép kết nối song
hành. Trong chế độ mặc định, đa số các trình duyệt cho phép mở từ 5
đến 10 kết nối TCP song hành, mỗi một kết nối này xử lý một giao
dịch yêu cầu – phản hồi. Nếu muốn người dùng vẫn có thể thiết đặt số
kết nối song hành tối đa thành 1, nghĩa là các kết nối TCP được thực
hiện nối tiếp nhau. Chương tiếp theo sẽ cho thấy việc dùng các kết nối
song hành giúp rút ngắn thời gian phản hồi.
Trước khi tiếp tục, hãy ước lượng thời gian tiêu tốn từ khi tiến trình
khách gửi yêu cầu cho đến khi nó nhận được toàn bộ tập tin HTML cơ
sở. Gọi RTT (round-trip time) là thời gian mà một gói tin nhỏ đi từ
tiến trình khách đến tiến trình phục vụ và quay ngược lại tiến trình
khách. Như vậy RTT gồm cả thời gian lan truyền tín hiệu, thời gian
xếp hàng chờ tại các bộ định tuyến và các bộ chuyển trung gian, và
thời gian xử lý gói tin (xem lại các khái niệm độ trễ trong phần IV.1
chương I). Xét các sự việc xảy ra khi người dùng nhấn chọn một siêu
liên kết. Như ở hình II-7, trình duyệt khởi tạo một kết nối TCP giữa
nó và máy phục vụ web; quá trình này thực hiện một thủ tục “bắt tay
ba bước” – đó là tiến trình khách gửi một đoạn tin TCP [TCP
segment] nhỏ đến cho tiến trình phục vụ để xin thiết lập kết nối; sau
đó tiến trình phục vụ xác nhận lại (sự cho phép thiết lập kết nối TCP)
bằng một đoạn tin TCP nhỏ khác gửi ngược về tiến trình khách; và
cuối cùng tiến trình khách xác nhận lại (đã biết tin) với tiến trình phục
vụ. Hai bước đầu trong quá trình “bắt tay ba bước” chiếm một RTT.
105
Sau khi hai bước này hoàn tất, tiến trình trình duyệt thực hiện bước
cuối kết hợp với việc gửi một thông điệp yêu cầu của HTTP. Khi
thông điệp yêu cầu đến tiến trình phục vụ, tiến trình phục vụ gửi tập
tin HTML vào kết nối TCP. Lần yêu cầu/phản hồi này của HTTP
chiếm thêm 1 RTT nữa. Tổng thời gian phản hồi là 2 RTT cộng thêm
thời gian tiến trình phục vụ truyền tập tin HTML về tiến trình trình
duyệt.
Máy phục vụ Web

Máy tính khách
[Web server]
Khởi
tạo kế
t nối T
CP
RTT
hận
Xá c n
Thông
điệp y
ê u cầ
u
RTT
yê u cầ u
n được
Thời gian Tập ti
truyền tập tin
Thời gian Thời gian
Hình II-7: Thời gian cần để yêu cầu và nhận tập tin HTML
HTTP với các kết nối thường trực

Các kết nối không thường trực có điểm bất tiện. Bất tiện đầu tiên là
phải thiết lập và duy trì kết nối mới cho mỗi đối tượng được yêu cầu.
Với mỗi kết nối, hệ điều hành phải cấp phát bộ nhớ làm vùng đệm cho
kết nối TCP và bộ nhớ cho các biến của TCP ở cả tiến trình khách và
tiến trình phục vụ. Khi có hàng trăm tiến trình khách đồng thời kết nối
đến tiến trình phục vụ, lượng bộ nhớ cần cấp phát này là một gánh
nặng đáng kể đối với máy phục vụ web. Bất tiện thứ hai là mỗi đối
tượng làm tiêu tốn hai RTT, một RTT cho thiết lập kết nối TCP và
một RTT cho yêu cầu và nhận lại đối tượng.
106
Với cách kết nối thường trực, tiến trình phục vụ vẫn giữ lại kết nối
TCP sau khi gửi xong thông điệp phản hồi. Các thông điệp yêu cầu và
phản hồi tiếp đến của cùng cặp tiến trình khách và phục vụ này sẽ
được gửi trên chính kết nối này. Cụ thể toàn bộ trang web (ở ví dụ
trên, một tập tin HTML và 10 tập tin ảnh) có thể được gửi trên một kết
nối TCP thường trực. Còn hơn như thế, nếu có nhiều trang web trên
một máy phục vụ cần được gửi đến cùng một tiến trình khách thì có
thể sử dụng cùng một kết nối TCP thường trực. Ở phía tiến trình
khách, các thông điệp yêu cầu có thể được phát ra hàng loạt, mà
không cần phải nghỉ chờ phản hồi của các yêu cầu đã phát ra trước đó
(lối này gọi là pipelining). Thông thường, tiến trình phục vụ sẽ quyết
định đóng kết nối TCP một khi kết nối đó không được sử dụng trong
một khoảng thời gian nhất định (có thể thiết đặt thông số khoảng thời
gian này cho trình phục vụ web). Mặc định, HTTP sử dụng cách kết
nối thường trực kết hợp với lối phát ra thông điệp yêu cầu hàng loạt
mà không cần đợi phản hồi.
II.3 Dạng thức thông điệp HTTP
Đặc tả HTTP [RFC 2616] bao gồm các định nghĩa của định dạng
thông điệp HTTP. Có 2 loại thông điệp HTTP, thông điệp yêu cầu và
thông điệp phản hồi, đã được nhắc đến ở phần trên.
Thông điệp yêu cầu
Bên dưới là thông điệp yêu cầu điển hình:
GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Host: close
User-agent: Mozilla/4.0
Accept-language: fr
Xem xét cụ thể một thông điệp yêu cầu sẽ làm sáng tỏ được nhiều
điều. Trước tiên, thông điệp trên được viết dưới dạng văn bản mã
ASCII, nhờ đó mà những ai có kiến thức thông thường về máy tính
đều có thể hiểu được. Kế đến, thông điệp trên gồm 5 dòng, mỗi dòng
kết thúc bằng dấu hiệu xuống dòng và về đầu dòng. Dòng cuối cùng
có thêm một dấu hiệu xuống dòng và về đầu dòng. Mặc dù thông điệp
107
trên có năm dòng, nhưng tổng quát thì một thông điệp yêu cầu có thể
có nhiều dòng hơn hoặc cũng có thể chỉ có một dòng. Dòng đầu của
thông điệp yêu cầu được gọi là dòng yêu cầu [request line]; các dòng
tiếp theo được gọi là dòng tham số [header line]. Dòng yêu cầu có 3
trường [fields]: method (phương thức), URL (đường dẫn đến đối
tượng), và Version (phiên bản HTTP). Trường method có thể nhận
một trong các phương thức khác nhau, bao gồm GET, POST, HEAD,
PUT và DELETE. Phần lớn các thông điệp yêu cầu dùng phương thức
GET. Phương thức GET được dùng khi trình duyệt yêu cầu đối tượng,
và đối tượng được yêu cầu chỉ định rõ trong trường URL. Trong ví dụ
này, trình duyệt đang yêu cầu đối tượng /somedir/page.html. Trường
HTTP version cho biết số hiệu phiên bản của giao thức HTTP mà
trình duyệt có hỗ trợ (HTTP/1.1)
Xem các dòng tham số trong ví dụ trên. Các dòng tham số “Host:
www.someschool.edu” cho biết tên của máy phục vụ chứa đối tượng
được yêu cầu. Dòng này có thể được người dùng cho là không cần
thiết vì đã có kết nối TCP đến máy phục vụ rồi. Tuy nhiên, như trong
phần II.5 sẽ đề cập, thông tin này cần thiết cho kỹ thuật Web proxy
cache. Với dòng Connection: close, trình duyệt báo cho tiến trình
phục vụ rằng nó không muốn sử dụng kết nối thường trực, và yêu cầu
trình phục vụ đóng kết nối sau khi phản hồi. Dòng User-agent: cho
biết loại trình duyệt đang gửi yêu cầu đến máy phục vụ, trong ví dụ
này là Mozilla/4.0 (một trình duyệt của Netscape). Dòng tham số này
cần thiết để máy phục vụ có thể gửi đúng phiên bản của đối tượng
được yêu cầu. Cuối cùng, dòng Accept-language:fr cho biết người
dùng muốn nhận một phiên bản tiếng Pháp của đối tượng, nếu như có
một phiên bản như vậy tồn tại trong máy phục vụ; còn nếu không thì
máy phục vụ sẽ gửi phiên bản mặc định.
Ví dụ ở hình II-8, định dạng tổng quát của một thông điệp yêu cầu. Ví
dụ trước tuân thủ theo định dạng trên. Theo sau các dòng tham số (và
dấu xuống dòng và về đầu dòng) là “phần thân thông điệp” [entity
body]. Với phương thức GET, phần thân thông điệp để trống, nhưng
với phương thức POST thì phần này được sử dụng để chứa các tham
số do người sử dụng đưa vào.
108
Chương trình khách thường sử dụng phương thức POST cho trường
hợp muốn người dùng nhập dữ liệu tham số vào một mẫu [form], như
trường hợp người dùng đưa vào từ khóa [keyword] cho một trang tìm
kiếm như Google.com. Cũng như thông điệp GET, thông điệp POST
cũng yêu cầu trang web từ máy phục vụ, nhưng các nội dung cụ thể
của trang web phụ thuộc vào những gì người dùng nhập vào mẫu. Khi
đó phần thân thông điệp POST chứa nội dung người dùng đã nhập.
Dòng yêu cầu method sp URL sp Version cr lf

header field name sp value cr lf
Dòng tham số
Dòng trống cr lf
Phần thân thông điệp
Hình II-8: Định dạng tổng quát của thông điệp yêu cầu
Như đã đề cập, trình khách dùng thông điệp GET để yêu cầu trang
web từ máy phục vụ, cũng như thông điệp POST. Tuy nhiên, dữ liệu
tham số do người dùng đưa vào mẫu, sẽ được ghép vào trường URL
của thông điệp, thay vì đặt ở phần thân thông điệp như trường hợp
POST. Chẳng hạn, nếu một mẫu dùng phương thức GET, có hai
trường, và dữ liệu đầu vào hai trường là “monkeys” và “bananas”, thì
URL sẽ có cấu trúc là www.somesite.com/animalsearch?
monkeys&bananas. Trong khi lướt web, hãy lưu ý các URL có chứa
các tham số thì thuộc về loại này.
Phương thức HEAD tương tự như phương thức GET. Khi một máy
phục vụ nhận một yêu cầu với loại phương thức HEAD, sẽ trả về một
thông điệp phản hồi nhưng không kèm theo các đối tượng được yêu
cầu. Lập trình viên thường dùng phương thức HEAD để gỡ rối
[debug] chương trình.
Phương thức PUT thường dùng trong các ứng dụng xuất bản nội dung
web. Phương thức này cho phép người dùng tải lên một đối tượng đến
một nơi cụ thể (thư mục) ở máy phục vụ web. Phương thức PUT cũng
được các ứng dụng dùng để tải lên các đối tượng đến máy phục vụ
109
web. Phương thức DELETE cho phép người dùng, hoặc ứng dụng,
xóa đi một đối tượng trên máy phục vụ web.
Thông điệp phản hồi HTTP
Với thông điệp yêu cầu đã nêu trong ví dụ trên, dưới đây là một ví dụ
về thông điệp phản hồi mà máy phục vụ web gửi về trình duyệt:
HTTP/1.1 200 OK
Connection: close
Date: Sat, 07 Jul 2007 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Sun, 6 May 2007 09:23:24 GMT
Content-Length: 6821
Content-Type: text/html
(data data data data data ...)
Thông điệp trên gồm có 3 phần: bắt đầu bằng một dòng trạng thái
[status line], sáu dòng mô tả [header line], và cuối là phần thân thông
điệp [entity body]. Phần thân thông điệp chứa nội dung đối tượng
được yêu cầu (ở ví dụ trên là “data data data data data…”). Dòng
trạng thái có 3 trường: version (phiên bản), status code (mã trạng
thái), và phrase (thông báo tình trạng phản hồi từ phía tiến trình phục
vụ). Trong ví dụ này, dòng trạng thái cho biết tiến trình phục vụ đang
dùng phiên bản HTTP/1.1 và tình trạng phản hồi là OK (có nghĩa là
tiến trình phục vụ đã tìm thấy và đang gửi đối tượng được yêu cầu).
Tiến trình phục vụ dùng dòng Connection: close để báo cho tiến trình
khách rằng nó sẽ đóng kết nối TCP sau khi gửi thông điệp. Dòng
Date: cho biết thời điểm tiến trình phục vụ tạo thông điệp phản hồi và
gửi đi. Lưu ý là đây không phải thời điểm đối tượng được tạo và được
cập nhật lần sau cùng; đó là thời điểm tiến trình phục vụ lấy đối tượng
từ hệ thống tập tin, chèn đối tượng vào thông điệp phản hồi, và gửi
thông điệp phản hồi về cho tiến trình khách. Dòng Server: cho biết
thông điệp được phát sinh bởi trình phục vụ Web Apache; dòng này
cũng tương tự như dòng User-agent: trong thông điệp yêu cầu. Dòng
Last-Modified: cho biết thời điểm đối tượng được tạo ra hoặc được
cập nhật lần sau cùng. Dòng Last-Modified: cần thiết cho việc trữ đối
tượng vào bộ nhớ cache, cả trong trường hợp bộ nhớ cache tại chính
máy khách lẫn trường hợp cache cho mạng. Dòng Content-Length:
110
cho biết kích thước đối tượng được gửi (tính theo byte). Dòng
Content-Type: cho biết loại đối tượng trong phần thân thông điệp là
văn bản HTML (loại đối tượng được xét qua dòng Content-Type: chứ
không phải bằng tên mở rộng của tập tin). Hình II.9 mô tả định dạng
tổng quát của một thông điệp phản hồi. Định dạng của thông điệp
phản hồi đã nêu trong ví dụ trên hoàn toàn phù hợp với định dạng tổng
quát này.
Nói thêm về hai trường status code và phrase. Mỗi giá trị của status
code là một mã trạng thái, được liên kết với một cụm từ thông báo
tình trạng phản hồi từ phía tiến trình phục vụ (pharse). Một số mã
trạng thái và cụm từ cụm từ thông báo tình trạng phản hồi thường
thấy:
• 200 OK: thông điệp yêu cầu hợp lệ và thông tin yêu cầu được trả về
trong thông điệp phản hồi
• 301 Moved Permanently: Đối tượng được yêu cầu đã được chuyển
đi nơi khác; URL mới được chỉ định trong dòng Location: của
thông điệp phản hồi. Chương trình khách tự động chuyển hướng
truy cập vào URL mới.
Dòng yêu cầu version sp status code sp phrase cr lf

Dòng mô tả
Dòng trống cr lf
Phần thân thông điệp
Hình II-9: Định dạng tổng quát của thông điệp phản hồi
• 400 Bad Request: Đây là mã lỗi trong trường hợp tiến trình phục vụ
không hiểu được thông điệp yêu cầu.
• 404 Not Found: Tài liệu yêu cầu không tìm thấy trên máy phục vụ.
• 505 HTTP Version Not Supported: Phiên bản giao thức HTTP trong
thông điệp yêu cầu không được máy phục vụ hỗ trợ.
111
Để có thể xem một thông điệp phản hồi, có thể trình telnet để truy cập
đến một máy phục vụ web tương ứng. Sau đó tạo ra một thông điệp
yêu cầu theo định dạng ở Hình II-8, bằng cách gõ từ bàn phím tại dấu
đợi lệnh của telnet. Ví dụ:
telnet cis.poly.edu 80
GET /-ross/ HTTP/1.1

Host: cis.poly.edu
Nhớ xuống dòng 2 lần sau khi gõ xong dòng header cuối cùng. Khi đó
máy tính sẽ tạo ra một kết nối TCP đến máy cis.poly.edu tại cổng 80
và gửi một thông điệp yêu cầu đến máy phục vụ. Một thông điệp trả
lời bao gồm tập tin định dạng HTML trang chủ của giáo sư Ross. Nếu
chỉ muốn thấy các dòng của thông điệp phản hồi nhưng không cần
nhận đối tượng thì hãy thay thế phương thức GET bằng phương thức
HEAD. Cuối cùng, thay /-ross/ bằng /-banana/ và quan sát loại thông
điệp phản hồi nhận được.
Phần trên đã đề cập đến một số dòng tham số của thông điệp yêu cầu
và dòng mô tả của thông điệp phản hồi. Thực ra thì HTTP đặc tả nhiều
dòng tham số/mô tả hơn thế, và chúng có thể được chính các trình
duyệt, máy phục vụ web cũng như các máy phục vụ cache sử dụng.
Trong phần II.5, khi nói về kỹ thuật Web caching, một số dòng tham
số/mô tả nữa sẽ được đề cập.
Trình duyệt quyết định những dòng tham số nào cần được đưa vào
thông điệp yêu cầu? Máy phục vụ Web quyết định dòng mô tả nào cần
được đưa vào thông điệp phản hồi? Thực tế thì trình duyệt phát sinh ra
các dòng tham số nào, phụ thuộc vào loại trình duyệt và phiên bản (ví
dụ, một trình duyệt HTTP/1.0 không phát sinh ra những dòng tham số
của phiên bản 1.1), phụ thuộc vào cấu hình của trình duyệt (ví dụ,
ngôn ngữ ưa dùng), cũng như phụ thuộc vào việc trình duyệt có sẵn
một phiên bản đối tượng yêu cầu được lưu trong cache nhưng lỗi thời
hay không. Với các máy phục vụ web thì cũng tương tự, phụ thuộc
vào: sản phẩm trình phục vụ web, phiên bản, và cấu hình phần mềm;
tất cả các yếu tố này đều ảnh hưởng đến các dòng mô tả trong các
thông điệp phản hồi.
112
II.4 Cookies
Máy phục vụ HTTP thuộc dạng phi trạng thái (stateless). Điểm này
giúp đơn giản hóa việc thiết kế máy phục vụ và cho phép các kỹ sư
phát triển các máy phục vụ web có hiệu năng cao có thể xử lý hàng
ngàn kết nối TCP cùng lúc. Tuy nhiên, điều mong muốn là trang web
có thể định danh được người dùng, vì máy phục vụ muốn hạn chế truy
cập người dùng và có thể cung cấp nội dung cho người dùng như một
chức năng liên quan đến định danh người dùng. Để đạt được các mục
đích này, HTTP dùng cookies. Cookies được định nghĩa trong RFC
2965, cho phép các trang truy vết người dùng. Đa số các trang web
thương mại ngày nay đều dùng cookie.
Như được mô tả trong hình 2.10, cookie có 4 thành phần: (1) các dòng
header trong thông điệp HTTP phản hồi; (2) dòng header trong thông
điệp HTTP yêu cầu; (3) tập tin cookie được giữ trên hệ cuối của người
dùng và được trình duyệt của người dùng quản lý; (4) một cơ sở dữ
liệu nhỏ kèm chung với trang web. Hình 2.10 sau đây là một ví dụ mô
tả cách hoạt động của cookie.
113
Hình 2.10. Giữ trạng thái người dùng với cookie

Giả sử Susan luôn truy cập vào web bằng cách dùng trình duyệt IE
(Internet Explorer) từ máy tính để bàn tại nhà cô ấy, Susan truy cập
vào trang Amazon.com lần đầu, và Susan cũng đã truy cập vào trang
eBay trước đây. Khi yêu cầu đến máy phục vụ web Amazon, máy
phục vụ tạo một số định danh duy nhất và đăng kí một vùng nhớ trên
cơ sở dữ liệu chứa số định danh đó. Máy phục vụ web Amazon phản
hồi đến trình duyệt của Susan bằng một thông điệp HTTP phản hồi có
một dòng header là Set-cookie: chứa số định danh này. Ví dụ:
Khi trình duyệt của Susan nhận thông điệp HTTP phản hồi sẽ đọc
được header Set-cookie:. Khi đó trình duyệt thêm một dòng vào
tập tin cookie đặc biệt mà nó quản lý. Dòng này gồm tên của máy
114
phục vụ (hostname) và số định danh trong header Set-cookie:. tập

tin cookie này có một chỉ mục cho trang eBay, vì Susan đã từng
truy cập trước đây. Khi Susan tiếp tục duyệt trang Amazon, mỗi
lần cô ấy yêu cầu một trang web, trình duyệt sẽ tìm trong tập tin
cookie của Susan, trích ra số định danh của trang web này, và đặt
dòng header Set-cookie: gồm số định danh này trong thông điệp
HTTP yêu cầu. Đặc biệt, tất cả thông điệp HTTP yêu cầu gửi đến
máy phục vụ Amazon sẽ gồm dòng header này:
Set-cookie: 1678
Bằng cách này, máy phục vụ Amazon có thể truy vết hành động
của Susan trên trang Amazon. Mặt dù trang web Amazon không
cần biết tên của Susan, chỉ cần biết chính xác trang nào người
dùng 1678 đang truy cập, theo thứ tự nào và ở thời gian nào.
Amazon dùng cookie để cung cấp dịch vụ giỏ hàng – Amazon
lưu giữ một danh sách tất cả các sản phẩm có khuynh hướng mua
của Susan, để cô ấy có thể thanh toán chung tất cả ở cuối phiên.
Nếu Susan trở về trang Amazon vào một tuần sau đó, trình duyệt
của Susan tiếp tục đặt dòng header Cookie:1678 vào trong các
thông điệp HTTP yêu cầu. Amazon cũng giới thiệu các sản phẩm
cho Susan dựa trên các trang mà Susan từng truy cập trên
Amazon. Nếu Susan đã đăng kí tài khoản với Amazon – gồm họ
tên, địa chỉ email, địa chỉ nhà, và thông tin thẻ tín dụng –
Amazon có thể đưa thông tin này vào cở sở dữ liệu của Amazon,
và liên kết tên của Susan với số định danh của cô ấy (và tất cả các
trang mà Susan đã truy cập trước đây). Đây là cách mà Amazon
và các trang web thương mại điện tử khác cung cấp gọi là “on-
click shopping”. Khi Susan chọn mua một món hàng trong lần
truy cập tiếp theo, Susan không cần điền lại tên của mình, cũng
như thông tin thẻ tín dụng hay địa chỉ nữa.
Như vậy, cookie có thể được dùng để định danh người dùng. Lần đầu
khi truy cập trang web, người dùng có thể cung cấp một định danh
người dùng (có thể là tên). Trong những phiên tiếp theo, trình duyệt sẽ
truyền dòng header cookie đến máy phục vụ, gọi là xác định người
dùng với máy phục vụ. Các cookie vì thế mà có thể được dùng để tạo
một lớp phiên người dùng trên đỉnh của giao thức HTTP phi trạng
115
thái. Ví dụ, khi người dùng đăng nhập vào ứng dụng web thư điện tử
(như hotmail), trình duyệt gửi thông tin cookie đến máy phục vụ, cho
phép máy phục vụ định danh người dùng thông qua phiên người dùng
với ứng dụng.
Mặc dù các cookie thường giúp người dùng đơn giản hóa việc mua
sắm trên Internet, nhưng người ta vẫn đang tranh cãi vì cookie có thể
làm ảnh hưởng đến tính riêng tư (privacy) của người dùng. Việc dùng
kết hợp các cookie và thông tin tài khoản người dùng, một trang web
có thể biết nhiều thông tin về người dùng và có khả năng bán thông tin
này cho một nhóm người thứ 3 (the third party).
II.5 Web Caching
Một web cache – còn được gọi là một máy phục vụ proxy – là một
thực thể mạng thỏa các yêu cầu HTTP đại diện cho máy phục vụ web.
Web cache có bộ nhớ lưu trữ riêng và giữ các bản sao của những đối
tượng được yêu cầu gần đây trong bộ nhớ này. Như trong hình 2.11,
trình duyệt của người dùng có thể được cấu hình để tất cả các thông
điệp HTTP yêu cầu của người dùng đầu tiên được định hướng đến
Web cache. Khi trình duyệt được cấu hình, mỗi trình duyệt yêu cầu
một đối tượng định hướng đến Web cache. Như trong ví dụ, giả sử
một trình duyệt đang yêu cầu đối tượng
http://www.someschool.edu/campus.gif:
1. Trình duyệt thiết lập một kết nối TCP đến Web cache và gửi thông
điệp HTTP yêu cầu về một đối tượng đến Web cache.
2. Web cache kiểm tra xem có một bản sao nào của đối tượng đang
được lưu trữ cục bộ không? Nếu có thì Web cache sẽ đưa đối
tượng này vào trong thông điệp HTTP phản hồi và gửi nó đến
trình duyệt khách.
3. Nếu Web cache không có đối tượng, Web cache mở một kết nối
TCP đến máy phục vụ là www.someschool.edu. Web cache gửi
tiếp HTTP yêu cầu về đối tượng vào kết nối TCP giữa Web cache
và máy phục vụ. Sau khi nhận yêu cầu, máy phục vụ sẽ tìm và
nhúng đối tượng vào thông điệp HTTP phản hồi rồi gửi đến Web
cache.
116
4. Khi Web cache nhận đối tượng, nó lưu trữ bản sao vào vùng nhớ
lưu trữ cục bộ và gửi kèm một bản sao (bên trong thông điệp
HTTP phản hồi) đến trình duyệt khách (trên kết nối TCP giữa
trình duyệt khách và Web cache).
Hình 2.11. Các máy khách đang yêu cầu các đối tượng thông qua Web cache
Vai trò của cache vừa là máy phục vụ vừa là máy khách cùng lúc. Khi
nó nhận yêu cầu từ trình duyệt và gửi phản hồi đến trình duyệt thì vai
trò khi đó là máy phục vụ. Khi nó gửi yêu cầu đến máy phục vụ và
nhận phản hồi từ máy phục vụ thì vai trò khi đó là máy khách.
Điển hình một Web cache được mua và cài đặt bởi ISP. Ví dụ, một
trường đại học có thể cài đặt cache trong mạng khuôn viên đại học và
cấu hình tất cả các trình duyệt trong khuôn viên đại học hướng đến
cache. Hoặc một ISP như AOL có thể cài đặt một hoặc nhiều cache
hơn trong mạng của nó và cấu hình trước các trình duyệt của nó
hướng đến các cache đã được cài đặt.
Hai nguyên nhân để triển khai web cache:
1 – Web cache có thể giảm thời gian phản hồi cho một yêu cầu
của máy khách, đặc biệt nếu băng thông giữa máy khách và máy phục
117
vụ ít hơn nhiều so với băng thông giữa máy khách và cache. Nếu
thường có một kết nối tốc độ cao giữa máy khách và cache, và nếu
cache có đối tượng được yêu cầu, thì cache sẽ có thể giao đối tượng
đó một cách nhanh chóng đến máy khách.
2 – Web cache có thể giảm lưu lượng trên một liên kết truy cập từ
tổ chức (như công ty, trường học) đến Internet. Với cách giảm lưu
lượng thì tổ chức không cần phải nâng cấp băng thông, do đó giảm
được chi phí. Ngoài ra, Web cache có thể giúp giảm tiêu thụ băng
thông web trên Internet, làm tăng cường hiệu năng cho tất cả các ứng
dụng.
Hình 2.12. Cổ chai giữa mạng của một tổ chức và Internet

Để hiểu sâu hơn về ưu điểm của cache, xét ví dụ trong hình 2.12. Hình
này cho thấy 2 mạng – mạng tổ chức (institutional network) và
Internet (pulic network). Mạng tổ chức là một mạng cục bộ (LAN) tốc
độ cao. Một bộ định tuyến (router) trong mạng tổ chức và một bộ định
tuyến trong Internet được kết nối với nhau qua đường truyền 15Mbps.
118
Các máy phục vụ được lắp vào mạng Internet và được đặt tại mọi nơi
trên thế giới. Giả sử kích thước đối tượng yêu cầu trung bình là 1 Mbit
và tỉ lệ yêu cầu trung bình từ các trình duyệt của tổ chức đến các máy
phục vụ là 15 yêu cầu trong 1 giây. Các thông điệp yêu cầu HTTP nhỏ
không đáng kể và không chiếm nhiều băng thông trên mạng hoặc
trong liên kết (từ bộ định tuyến của tổ chức đến bộ định tuyến
Internet). Và cũng giả sử rằng thời gian từ khi bộ định tuyến phía
Internet của liên kết trong hình 2.12 chuyển tiếp thông điệp HTTP yêu
cầu (trong một gói IP) đến khi nhận được phản hồi (trong nhiều gói
IP) là trung bình 2 giây. Thời gian này được gọi là độ trì hoãn Internet
(Internet delay). Tổng thời gian phản hồi (thời gian từ khi trình duyệt
yêu cầu một đối tượng đến khi nhận được đối tượng) là tổng độ trì
hoãn LAN, độ trì hoãn truy cập (giữa 2 bộ định tuyến) và độ trì hoãn
Internet. Cường độ lưu thông trên mạng LAN (xem phần 1.4.2) là:
(15 yêu cầu/giây) * (1 Mbits/yêu cầu) / (100 Mbps) = 0.15
Trong khi cường độ lưu thông trên liên kết truy cập (từ bộ định tuyến
Internet đến bộ định tuyến tổ chức) là:
(15 yêu cầu/giây)* (1 Mbits/yêu cầu) / (15 Mbps) = 1
Cường độ lưu thông trên mạng LAN là 0.15, khoảng 1/10 của milli-
giây; do đó, có thể bỏ qua độ trì hoãn LAN. Như trong 1.4.2, cường
độ lưu thông tiếp cận đến 1 (trường hợp liên kết truy cập trong hình
2.12), độ trì hoãn trên đường truyền trở nên rất lớn và tăng không có
chặn trên. Dẫn đến thời gian phản hồi các yêu cầu trung bình tăng theo
từng phút, điều này là không thể chấp nhận đối với người dùng của tổ
chức. Thay đổi một vài chỗ như sau:
Một giải pháp là tăng tỉ lệ truy cập từ 15Mbps lên 100Mbps. Cách này
sẽ làm cho cường độ lưu thông trên liên kết sẽ giảm xuống 0.15, thay
đổi các độ trì hoãn giữa hai bộ định tuyến. Khi đó, tổng thời gian phản
hồi là 2 giây, cũng chính là độ trì hoãn Internet. Giải pháp này cũng có
nghĩa là tổ chức phải nâng cấp đường truyền của nó từ 15Mpbs lên
100Mpbs.
119
Hình 2.13. Thêm cache vào mạng tổ chức

Xem xét giải pháp không nâng cấp đường truyền mà cài đặt một web
cache trong mạng tổ chức. Giải pháp này được mô tả trong hình 2.13.
Tỉ lệ Hit – tỉ lệ các yêu cầu cache có thể phản hồi – thực tế nằm trong
khoảng từ 0.2 đến 0.7. Giả sử cache cung cấp 1 tỉ lệ Hit là 0.4 cho tổ
chức. Vì các máy khách và cache được kết nối cùng mạng LAN tốc độ
cao, nên 40% yêu cầu sẽ được đáp ứng ngay lập tức, trong vòng 10ms
bởi cache. Mặc dù, 60% yêu cầu đối tượng còn lại sẽ được đáp ứng
thông qua đường truyền liên kết. Cường độ lưu thông trên đường
truyền giảm từ 1.0 xuống 0.6. Điển hình cường độ lưu thông ít hơn 0.8
tương ứng với độ trì hoãn nhỏ, một phần mười của mili giây, trên
đường truyền 15Mbps. Độ trì hoãn này không đáng kể so với 2s của
độ trì hoãn Internet.
Với các xem xét trên thì độ trì hoãn trung bình là:
0.4 * (0.01 giây) + 0.6 * (2.01 giây)
120
lớn hơn một chút so với 1.2 giây. Do đó, giải pháp thứ 2 cung cấp thời
gian phản hồi thậm chí ít hơn giải pháp đầu tiên, và nó không yêu cầu
tổ chức cập nhật đường truyền lên Internet. Chắc chắn tổ chức phải
mua và cài đặt một Web cache. Nhưng chi phí này vẫn thấp – nhiều
cache dùng phần mềm miền công chạy trên các PC rẻ tiền.
II.6 Cập nhật trang Web có điều kiện
Mặc dù dùng cache có thể giảm thời gian phản hồi người dùng, nhưng
một vấn đề mới được đề ra là bản sao của một đối tượng bên trong
cache có thể đã cũ. Mặt khác, đối tượng lưu trong máy phục vụ web
có thể được bổ sung sau khi lưu bản sao trên cache. Thuận lợi là
HTTP có một kỹ thuật cho phép cache xác nhận đối tượng của nó đã
được cập nhật. Kỹ thuật này được gọi là GET có điều kiện. Một thông
điệp yêu cầu HTTP được gọi là thông điệp GET có điều kiện nếu: (1)
thông điệp yêu cầu dùng phương thức GET và (2) thông điệp yêu cầu
có dòng header If-modified-since. Xét ví dụ sau:
1 – Một proxy cache thay cho trình duyệt yêu cầu gửi một thông
điệp yêu cầu đến máy phục vụ web:
GET /fruit/kiwi.gif HTTP/1.1
Host: www.exotiquecuisine.com
2 – Máy phục vụ web gửi một thông điệp phản hồi với đối tượng
được yêu cầu đến cache:
HTTP/1.1 200 OK
Date: Sat, 7 Jul 2007 15:39:29
Last-Modified: Wed, 4 Jul 2007 09:23:24
Content-Type: image/gif
(data data data data data ...)
Cache chuyển đối tượng đến trình duyệt yêu cầu, đồng thời lưu
lại đối tượng lên vùng nhớ cục bộ. Cache cũng lưu thời gian bổ
sung gần nhất cùng với đối tượng.
121
3 – Một tuần sau đó, một trình duyệt khác yêu cầu cùng đối tượng
thông qua cache, và đối tượng vẫn còn lưu trong cache. Vì đối
tượng này vừa được cập nhật trên máy phục vụ web một tuần
qua, cache phải kiểm tra cập nhật bằng cách dùng một lệnh GET
có điều kiện. Cụ thể cache sẽ gửi:
GET /fruit/kiwi.gif HTTP/1.1
Host: www.exotiquecuisine.com
If-modified-since: Wed, 4 Jul 2007 09:23:24
Lưu ý giá trị của dòng header If-modified-since: chính xác là giá
trị của dòng header Last-modified: đã được gửi đến máy phục vụ
một tuần trước đây. Lệnh GET có điều kiện đang yêu cầu máy
phục vụ gửi đối tượng nếu đối tượng vừa được bổ sung sau một
ngày tháng cụ thể nào đó được yêu cầu xác nhận nhu trong ví dụ
trên là đối tượng vừa được bổ sung kể từ ngày 04/07/2007 lúc
09:23:24.
4 – Máy phục vụ web gửi một thông điệp đến cache:
HTTP/1.1 304 Not Modified
Date: Sat, 14 Jul 2007 15:39:29
(empty entity body)
Trong thông điệp phản hồi đến lệnh GET có điều kiện, máy phục
vụ web vẫn gửi thông điệp phản hồi nhưng không thêm đối tượng
được yêu cầu vào thông điệp phản hồi. Thêm đối tượng được yêu
cầu sẽ làm tốn băng thông và làm tăng thời gian phản hồi người
dùng, đặc biệt nếu đối tượng đó lớn. Thông điệp phản hồi cuối
cùng nếu có dòng “304 Not Modified” trong dòng trạng thái, sẽ
yêu cầu cache có thể tiếp tục dùng và gửi các bản sao của đối
tượng đến trình duyệt yêu cầu.
III. Giao thức truyền file: FTP

Trong phiên truyền FTP, người dùng đang dùng một máy tính mạng
cục bộ và muốn truyền các tập tin đến hoặc lấy các tập tin từ một máy
tính mạng xa. Để người dùng truy cập vào một tài khoản từ xa, người
122
dùng phải cung cấp định danh người dùng và mật khẩu. Sau khi cung
cấp các thông tin phân quyền, người dùng truyền các tập tin từ hệ
thống tập tin cục bộ đến hệ thống tập tin ở xa và ngược lại. Như trong
hình 2.14, người dùng tương tác với FTP thông qua một đại lý người
dùng FTP (FTP user agent). Người dùng đầu tiên cung cấp tên máy
tính mạng từ xa, tạo tiến trình FTP khách trên máy tính cục bộ để thiết
lập một kết nối đến tiến trình FTP chủ trên máy tính ở xa. Người dùng
kế tiếp sẽ cung cấp định danh người dùng và mật khẩu, được gửi
thông qua kết nối TCP như một phần của các lệnh FTP. Khi máy phục
vụ kiểm tra phân quyền người dùng xong, người dùng sao chép ra một
hoặc nhiều hơn một các tập tin trên hệ thống tập tin cục bộ vào hệ
thống tập tin từ xa (hoặc ngược lại).
Hình 2.14. FTP di chuyển các tập tin giữa các hệ thống cục bộ và từ xa
HTTP và FTP là hai giao thức truyền tập tin và có nhiều đặc điểm
chung, cả hai đều chạy trên đỉnh của TCP. Tuy nhiên, hai giao thức
tầng Ứng dụng này cũng có một số điểm khác biệt rõ rệt. Điểm khác
biệt nhất là FTP dùng hai kết nối TCP song song, để truyền tập tin,
một kết nối điều khiển (control connection) và một kết nối dữ liệu
(data connection).
Hình 2.15. Các kết nối điều khiển và dữ liệu
123
Kết nối điều khiển được dùng để gửi thông tin điều khiền giữa hai
máy tính mạng – thông tin như định danh người dùng, mật khẩu, các
lệnh để chuyển thư từ xa, và các lệnh để chép tập tin lên (lệnh “put”)
và lệnh để lấy tập tin về (lệnh “get”). Kết nối dữ liệu thường được
dùng để gửi tập tin. Vì FTP dùng một kết nối điều khiển riêng biệt,
nên FTP thường được gọi là gửi thông tin điều khiển ngoài băng thông
(out-of-band). Trong chương 7, giao thức RTSP (Real Time
Streaming Protocol) được dùng cho điều khiển việc truyền dữ liệu đa
phương tiện liên tục như âm thanh, phim, và cũng gửi thông tin điều
khiển ngoài băng thông. HTTP gửi yêu cầu và phản hồi vào cùng kết
nối TCP mà kết nối này cũng dùng để chuyển tải dữ liệu. Do đó,
HTTP được gọi là gửi thông tin điều khiển trên băng thông (in-band).
Trong phần tiếp theo, SMTP là một giao thức chính truyền thông thư
điện tử, cũng gửi thông tin điều khiển trên băng thông. Các kết nối
điều khiển và dữ liệu FTP được minh họa trong hình 2.15.
Khi một người dùng bắt đầu một phiên FTP với một máy tính từ xa,
FTP khách (phía người dùng) khởi tạo một kết nối TCP đến phía FTP
chủ (một máy tính ở xa) qua cổng 21. FTP khách gửi định danh người
dùng và mật khẩu trên kênh truyền điều khiển này. FTP khách cũng
gửi trên kênh truyền điều khiển các lệnh đổi thư mục từ xa. Khi máy
phục vụ nhận một lệnh truyền tập tin trên kênh truyền điều khiển (với
một máy tính từ xa), máy phục vụ khởi tạo một kênh truyền dữ liệu
TCP đến máy khách. FTP gửi chính xác một tập tin trên kênh truyền
dữ liệu và sau đó là đóng kênh truyền dữ liệu này. Trong suốt phiên
truyền, nếu người dùng muốn truyền một tập tin khác, FTP mở một
kênh truyền dữ liệu khác. Do đó, với FTP, kênh truyền điều khiển vẫn
mở trong suốt phiên truyền của người dùng, nhưng kênh truyền dữ
liệu mới được tạo cho mỗi tập tin được truyền trong một phiên truyền
(kênh truyền dữ liệu là không thường trực).
Thông qua một phiên truyền, máy phục vụ FTP phải duy trì trạng thái
(state) về người dùng (user). Cụ thể, máy phục vụ phải kết hợp kênh
truyền điều khiển với một tài khoản người dùng cụ thể, và máy phục
vụ phải truy vết thư mục hiện hành của người dùng khi người dùng
duyệt cây thư mục trên máy tính ở xa. Truy vết thông tin trạng thái
cho mỗi phiên người dùng ràng buộc tổng số phiên truyền mà FTP có
thể quản lý đồng thời.
124
Các lệnh và phản hồi FTP

Các lệnh từ máy khách đến máy phục vụ và các phản hồi từ máy phục
vụ đến máy khách được gửi thông qua kênh truyền điều khiển dưới
định dạng mã ASCII 7-bit. Do đó cũng như lệnh của HTTP, con người
có thể đọc được các lệnh của FTP. Để phân loại các câu lệnh, một mã
xuống dòng và lùi về đầu dòng sẽ kết thúc mỗi dòng. Mỗi lệnh bao
gồm 4 kí tự ASCII viết hoa, vài câu lệnh với các thông số tùy chọn.
Sau đây là các câu lệnh FTP phổ biến:
- USER username: gửi định danh người dùng cho máy phục vụ
- PASS password: gửi mật khẩu đến máy phục vụ
- LIST: yêu cầu máy phục vụ gửi lại danh sách tất cả các tập tin
trong thư mục hiện hành từ xa. Danh sách các tập tin được gửi qua
một kết nối dữ liệu (mới và không thường trực) hơn là gửi qua kết
nối điều khiển.
- RETR filename: lấy về một tập tin từ thư mục hiện hành của máy
tính từ xa. Lệnh này làm cho máy tính từ xa khởi động kết nối dữ
liệu và gửi tập tin được yêu cầu thông qua kênh truyền dữ liệu.
- STOR filename: thường lưu trữ một tập tin lên thư mục hiện hành
của máy tính từ xa
Có một mối quan hệ một–một giữa câu lệnh người dùng gửi và lệnh
FTP gửi thông qua kết nối điều khiển. Mỗi lệnh sẽ nhận được một
phản hồi gửi từ máy phục vụ đến máy khách. Các phản hồi gồm một
số có 3 chữ số kèm theo sau là một thông điệp tùy chọn. Cấu trúc
này tương đương với mã trạng thái và đoạn mô tả trạng thái của
thông điệp HTTP phản hồi. Các dạng phản hồi FTP như sau:
- 331 Username OK, password required (Username thỏa, yêu cầu
gửi mật khẩu)
- 125 Data connection already open; transfer starting (Kết nối
truyền dữ liệu được tạo thành công, bắt đầu truyền dữ liệu)
- 425 Can't open data connection (không thể mở kết nối truyền dữ
liệu)
- 452 Error writing file (Lỗi ghi tập tin)
125
Các lệnh và thông điệp phản hồi khác của FTP tham khảo thêm trong
RFC 959.
IV. Thư điện tử và Internet

Thư điện tử là ứng dụng phổ biến nhất trong thời kì đầu tiên của
Internet [Segaller 1998], và trở nên ngày càng hoàn thiện và mạnh hơn
qua nhiều năm. Thư điện tử vẫn còn là một trong những ứng dụng
quan trọng nhất và được sử dụng nhiều nhất hiện nay.
So với một lá thư gửi thông thường qua đường bưu điện cần có ràng
buộc thời gian gửi và thời gian giao thư, thì một thư điện tử là một
phương tiện truyền thông bất đồng bộ – người ta gửi và đọc các thông
điệp vào thời điểm thuận lợi cho họ, mà không cần tương thích thời
gian biểu với bất kì ai. Nhưng ngược lại với thư qua đường bưu điện,
thư điện tử nhanh, dễ phân phối, và không tốn nhiều chi phí. Thư điện
tử hiện đại có nhiều nét đặc trưng thuận lợi như: dùng các danh sách
thư, thông điệp thư điện tử và thư rác có thể được gửi đến hàng ngàn
người nhận cùng một lúc. Các thông điệp thư điện tử hiện đại còn
gồm các dữ liệu đính kèm (attachment), các siêu liên kết (hyperlink),
các văn bản định dạng HTML, và hình ảnh.
Hình 2.16 mô tả tổng quan hệ thống thư Internet. Hình gồm 3 thành
phần chính: user agent (ứng dụng giao diện mail phía người dùng,
thỉnh thoảng được gọi là mail reader), máy phục vụ mail, và giao thức
truyền thông SMTP (Simple Mail Transfer Protocol). Các thành phần
này trong ngữ cảnh người gửi là Alice, gửi một thông điệp thư điện tử
đến người nhận là Bob. User agent cho phép người dùng đọc, gửi lại,
chuyển tiếp, lưu trữ, và soạn thảo thông điệp. Khi Alice soạn thông
điệp xong, user agent của Alice gửi thông điệp đến máy phục vụ mail,
thông điệp sẽ được đặt trong hàng đợi thông điệp đi ra. Khi Bob muốn
đọc một thông điệp, user agent của Bob sẽ lấy thông điệp từ hộp thư
của Bob trên máy phục vụ mail. Cuối những năm 1990, user agent có
giao diện đồ họa người dùng (GUI – Graphical User Interface) trở nên
phổ biến, cho phép người dùng xem và soạn các thông điệp đa phương
tiện. Hiện nay Outlook của Microsoft, Apple Mail, và Mozilla
Thunderbird nằm trong số các user agent GUI phổ biến dùng cho thư
điện tử. Cũng có nhiều giao diện thư điện tử người dùng dựa trên văn
126
bản dùng trong miền công cộng (public domain) (như mail, pine và
elm) cũng như giao diện web.
Hình 2.16. Mô hình tổng quát hệ thống thư điện tử Internet

Các máy phục vụ mail tạo nên phần lõi cho cơ sở hạ tầng thư điện tử.
Mỗi người nhận mail như Bob sẽ có một hộp thư (mailbox) đặt trên
một trong các máy phục vụ mail. Hộp thư của Bob quản lý và duy trì
các thông điệp gửi đến anh ta. Một thông điệp mail bắt đầu quá trình
di chuyển của nó từ user agent của người gửi, đi đến máy phục vụ
mail của người gửi, rồi đến máy phục vụ mail của người nhận, và vào
hộp thư của người nhận. Khi Bob muốn truy cập các thông điệp trong
hộp thư của mình, máy phục vụ mail chứa hộp thư của Bob sẽ chứng
thực Bob (với tên người dùng và mật khẩu). Máy phục vụ mail của
Alice phải giải quyết các thất bại trong liên lạc và truyền thông với
máy phục vụ mail của Bob. Nếu máy phục vụ mail của Alice không
thể phân phối thư đến máy phục vụ mail của Bob, máy phục vụ mail
127
của Alice sẽ đưa thông điệp vào hàng đợi thông điệp và cố gắng
truyền thông điệp đi sau đó. Việc gửi thư lại thường được thực hiện
trong vòng 30 phút, nếu không thành công sau vài ngày, máy phục vụ
sẽ gỡ bỏ thông điệp và báo cho người gửi (Alice) biết bằng một thông
điệp thư điện tử.
SMTP là một giao thức tầng Ứng dụng đối với thư điện tử Internet.
Nó dùng dịch vụ truyền dữ liệu đáng tin cậy của TCP để truyền thư từ
máy phục vụ mail của người gửi đến máy phục vụ mail của người
nhận. Như với đa số các giao thức tầng Ứng dụng, SMTP cũng có hai
phía: phía máy khách kích hoạt máy phục vụ mail của người gửi, phía
máy phục vụ kích hoạt máy phục vụ mail của người nhận. Cả hai bên
SMTP khách và SMTP chủ hoạt động trên mọi máy phục vụ mail: khi
một máy phục vụ mail gửi một thư đến các máy phục vụ mail khác, nó
làm việc như một SMTP khách, và khi một máy phục vụ mail nhận
một thư từ các máy phục vụ mail, nó làm việc như một SMTP chủ.
IV.1 Giao thức SMTP
SMTP, được định nghĩa trong RFC 5321, là trung tâm của thư điện tử
Internet. Như được đề cập ở trên, SMTP truyền các thông điệp mail từ
các máy phục vụ mail của người gửi đến các máy phục vụ mail của
người nhận. SMTP lâu đời hơn HTTP rất nhiều (RFC dành cho SMTP
đầu tiên được đưa ra năm 1982, và SMTP ra đời không lâu trước đó).
Mặc dù SMTP có nhiều ưu điểm, được thấy qua việc SMTP là duy
nhất và phổ biến trên Internet, nhưng đó vẫn là một kỹ thuật đã lâu đời
với một số các tính năng cũ kĩ như hạn chế trong phần thân mail
(không chỉ phần đầu mail) của tất cả các thông điệp mail là dạng mã
ASCII 7 bit. Giới hạn này được biết đến vào đầu những năm 1980 khi
dung lượng truyền rất ít và không ai có thể đính kèm các tập tin lớn
hay các tập tin hình ảnh âm thanh hay phim lớn. Nhưng ngày nay,
trong kỷ nguyên phương tiện truyền thông, giới hạn mã ASCII 7 bit là
một khuyết điểm lớn – yêu cầu dữ liệu nhị phân chuyển mã thành mã
ASCII trước khi gửi bằng giao thức SMTP; và yêu cầu các thông điệp
ASCII tương ứng giải mã ngược lại nhị phân sau khi truyền. Ở phần
2.2 có đề cập việc HTTP không yêu cầu dữ liệu đa phương tiện
chuyển thành mã ASCII khi truyền đi.
128
Sau đây là ví dụ minh họa cho hoạt động của giao thức SMTP. Giả sử
Alice muốn gửi cho Bob một thông điệp mã ASCII đơn giản:
1 – Alice mở user agent lên, cung cấp địa chỉ mail của Bob (ví
dụ: bob@someschool.edu), soạn một thông điệp, và dùng user
agent để gửi thông điệp
Hình 2.17. Alice gửi thông điệp cho Bob

2 – User agent của Alice gửi thông điệp đến máy phục vụ mail
của cô ấy, tiếp theo là thông điệp đó được đặt vào một hàng đợi
thông điệp.
3 – SMTP khách chạy trên máy phục vụ mail của Alice thấy có
thông điệp trong hàng đợi thông điệp. Nó sẽ mở kết nối TCP đến
SMTP chủ hoạt động trên máy phục vụ mail của Bob.
4 – Sau bắt tay SMTP đầu tiên, SMTP khách gửi thông điệp của
Alice vào kết nối TCP.
5 – Trên máy phục vụ mail của Bob, SMTP chủ nhận được thông
điệp. Máy phục vụ mail của Bob kế đó đặt thông điệp vào hộp
thư của Bob.
6 – Bob mở user agent của mình lên để đọc thông điệp khi anh ta
có thời gian rảnh.
Dòng sự kiện được tóm tắt trong hình 2.17.
SMTP không dùng các máy phục vụ mail trung gian, thậm chí khi hai
máy phục vụ mail ở hai nơi thật xa nhau trên trái đất này. Giả sử máy
phục vụ mail của Alice ở Hồng Kông và máy phục vụ mail của Bob ở
đường Louis. Nếu máy phục vụ mail của Bob ngừng hoạt động, thông
129
điệp còn lưu trữ trên máy phục vụ mail của Alice và đợi cho những
lần thử mới – thông điệp không bị chuyển đến một máy phục vụ mail
trung gian nào cả.
SMTP truyền một thông điệp từ máy phục vụ mail gửi đến máy phục
vụ mail nhận. Đầu tiên, máy phục vụ mail gửi thiết lập kết nối TCP
qua cổng 25 đến SMTP chủ (máy phục vụ mail nhận). Nếu máy phục
vụ không hoạt động nữa, máy khách cố gắng gửi lại. Khi kết nối được
thiết lập, máy phục vụ và máy khách sẽ thực hiện bắt tay ở tầng Ứng
dụng – như con người vẫn thường hay giới thiệu họ trước khi trao đổi
thông tin với nhau.
SMTP khách và SMTP chủ tự giới thiệu trước khi truyền thông tin.
Trong suốt quá trình bắt tay SMTP, SMTP khách cho biết địa chỉ thư
điện tử của người gửi (người muốn tạo thông điệp) và địa chỉ thư điện
tử của người nhận. Khi SMTP chủ và khách hoàn tất việc giới thiệu
với nhau, máy khách gửi thông điệp. SMTP khách có thể dùng dịch vụ
truyền dữ liệu đáng tin cậy của TCP để gửi thông điệp đến máy phục
vụ mà không bị lỗi. Máy khách có thể lặp lại tiến trình này trên cùng
kết nối TCP nếu có thông điệp khác cần gửi đến máy phục vụ mail,
nếu không còn thông điệp nào cần gửi, máy khách sẽ yêu cầu đóng kết
nối TCP.
Ví dụ sau mô tả trao đổi thông điệp giữa máy khách SMTP (C) và
máy phục vụ SMTP (S). Tên của máy khách là crepes.fr và tên của
máy phục vụ là hamburger.edu. Các dòng bắt đầu với C: do máy
khách gửi đến socket TCP của nó, và các dòng bắt đầu với S: do máy
phục vụ gửi đến socket TCP của nó. Quá trình trao đổi thông điệp sau
diễn ra ngay khi kết nối TCP vừa được thiết lập:
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <alice@crepes.fr>
S: 250 alice@crepes.fr ... Sender ok
C: RCPT TO: <bob@hamburger.edu<
S: 250 bob@hamburger.edu ... Recipient ok
130
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection
Trong ví dụ trên, máy khách gửi thông điệp “Do you kie ketchup?
How about pickles?” từ máy khách mail crepes.fr đến máy phục vụ
mail hamburger.edu. Máy khách đưa ra 5 lệnh: HELO (viết tắt của
HELLO), MAIL FROM, RCPT TO, DATA, và QUIT. Máy khách
cũng gửi một dòng đơn gồm một dấu chấm duy nhất cho biết là đã kết
thúc thông điệp đến máy phục vụ. Máy phục vụ phản hồi lại từng câu
lệnh của máy khách, với mỗi câu trả lời có mã trả lời và lời giải thích
(tùy chọn). Lưu ý là SMTP dùng các kết nối thường trực: nếu máy
phục vụ mail gửi muốn truyền nhiều thông điệp đến cùng máy phục
vụ mail nhận thì máy phục vụ mail gửi có thể gửi tất cả thông điệp
trên cùng kết nối TCP. Với mỗi thông điệp, máy khách bắt đầu tiến
trình với một dòng mới MAIL FROM: crepes.fr, kết thúc thông điệp
là dấu “.”, và gửi lệnh QUIT chỉ sau khi tất cả các thông điệp đã được
gửi.
Nên dùng Telnet để đối thoại trực tiếp với SMTP chủ, bằng cách dùng
lệnh:
telnet serverName 25
với serverName là tên của máy phục vụ mail cục bộ. Một kết nối TCP
đơn giản được thiết lập giữa máy cục bộ và máy phục vụ mail. Sau khi
gửi dòng này, máy khách sẽ nhận được mã 220 từ máy phục vụ. Kế
tiếp là các lệnh HELO, MAIL FROM, RCPT TO, DATA, “.”, và
QUIT.
IV.2 So sánh với HTTP
So sánh SMTP và HTTP. Cả hai giao thức được dùng để truyền tập tin
từ máy này sang máy khác. HTTP truyền các tập tin (đối tượng) từ
131
máy phục vụ web đến máy khách web (trình duyệt); SMTP truyền các
tập tin (thông điệp thư điện tử) từ máy phục vụ mail này đến máy
phục vụ mail khác. Khi truyền các tập tin, cả hai giao thức HTTP
thường trực và SMTP dùng các kết nối thường trực. Do đó, hai giao
thức này có nhiều đặc điểm chung. Tuy nhiên, có các khác biệt rõ rệt.
Đầu tiên là HTTP dùng một giao thức kéo (pull protocol), có nghĩa là
một số người dùng tải thông tin lên máy phục vụ web, và các người
dùng HTTP kéo thông tin từ máy phục vụ về vào những thời điểm
thuận lợi. Đặc biệt, kết nối TCP được khởi tạo bởi máy muốn nhận tập
tin. Mặt khác, SMTP lại là giao thứ đẩy (push protocol), có nghĩa là
máy phục vụ mail đẩy các tập tin đến máy phục vụ mail nhận. Đặc
biệt, kết nối TCP được khởi tạo bởi máy muốn gửi tập tin.
Điểm khác biệt thứ hai là SMTP yêu cầu từng thông điệp, gồm phần
thân của mỗi thông điệp, là dạng mã văn bản ASCII 7 bit. Nếu thông
điệp chứa các kí tự không phải là mã văn bản ASCII 7 bit (như tiếng
Pháp có phiên âm) hay có chứa dữ liệu nhị phân (như tập tin ảnh), thì
thông điệp phải mã hóa thành mã ASCII 7 bit. Dữ liệu HTTP không
bắt buộc hạn chế này.
Khác biệt thứ ba là một tài liệu chứa văn bản và hình ảnh (cùng với
vài loại dữ liệu đa phương tiện khác) được xử lý như thế nào. Như đã
giới thiệu trong phần 2.2, HTTP đóng gói mỗi đối tượng vào một
thông điệp phản hồi định dạng HTTP riêng của nó. Mail Internet đặt
tất cả các đối tượng của thông điệp vào một thông điệp và mã hóa
thành mã ASCII 7 bit.
IV.3 Khuôn dạng Mail message và MINE
Khi Alice viết một lá thư thông thường cho Bob, cô ấy gộp tất cả các
thông tin header vào đỉnh lá thư, như địa chỉ của Bob, địa chỉ trả về
của cô ấy, và ngày tháng viết thư. Tương tự, khi một thông điệp thư
điện tử được gửi từ người này đến người khác, một header chứa thông
tin được yêu cầu trước phần thân thông điệp. Thông tin này gồm các
dòng header như được định nghĩa trong RFC 5322. Các dòng header
và phần thân thông điệp được phân biệt bởi một dòng trống. RFC
5322 có định dạng chính xác cho các dòng header và ý nghĩa của các
dòng header này. Cũng như HTTP, mỗi dòng header có thể đọc được,
132
chứa từ khóa theo sau đó là dấu «:» và một giá trị. Vài từ khóa là bắt
buộc và một vài từ khác là tùy chọn. Mỗi header phải có dòng From:
và To:, một header có thể có dòng Subject: cũng như một số dòng
header tùy chọn khác. Các dòng header này khác với các lệnh của
SMTP trong phần 2.4.1. Các câu lệnh đó là một phần của giao thức
bắt tay SMTP; các dòng header trong phần này là một phần của thông
điệp thư điện tử.
Ví dụ về một header thông điệp điển hình:
From: alice@crepes.fr
To: bob@hamburger.edu
Subject: Searching for the meaning of life.
Sau phần header thông điệp là một dòng trống, rồi đến phần thân
thông điệp (dạng mã ASCII). Có thể dùng lệnh telnet để gửi thông
điệp đến máy phục vụ mail, thông điệp gồm các dòng header, có dòng
header Subject:, lệnh telnet như sau :
telnet serverName 25
IV.4 Các giao thức truy cập Mail
Khi SMTP phát thông điệp từ máy phục vụ mail của Alice đến máy
phục vụ mail của Bob, thông điệp đặt trong hộp thư của Bob. Bob đọc
thư bằng cách đăng nhập vào máy phục vụ và kích hoạt công cụ đọc
thư trên máy phục vụ đó. Đến đầu những thập niên 90 thì đây vẫn còn
là các bước chuẩn cho việc đọc một lá thư điện tử. Nhưng ngày nay,
việc truy cập thư điện tử dùng kiến trúc khách – phục vụ đã giúp
người dùng đọc thư điện tử với chương trình khách hoạt động trên hệ
cuối (như máy tính văn phòng, máy tính xách tay, hay PDA). Bằng
cách kích hoạt trình duyệt trên máy cục bộ, người dùng có thể dùng
nhiều tính năng gồm cả việc xem các thông điệp và tập tin đính kèm
đa phương tiện.
Bob (người nhận) kích hoạt user agent trên máy tính cục bộ của anh
ta, cũng mặc định xem đó là máy phục vụ mail của Bob. Với hướng
tiếp cận này, máy phục vụ mail của Alice sẽ nói chuyện trực tiếp với
PC của Bob. Tuy nhiên, có một vấn đề đặt ra với hướng tiếp cận này.
Máy phục vụ mail quản lý các hộp thư và kích hoạt SMTP khách và
133
SMTP chủ. Nếu máy phục vụ mail của Bob cũng nằm trên PC cục bộ
của anh ấy, thì PC của Bob có thể ở chế độ luôn hoạt động và kết nối
với Internet, để nhận thư mới có thể đến bất cứ khi nào, việc này là
phi thực tế cho nhiều người dùng Internet. Thay vào đó, một người
dùng điển hình chạy một user agent trên PC cục bộ nhưng truy cập
vào hộp thư lưu trữ trên một máy phục vụ mail chia sẻ luôn hoạt động.
Máy phục vụ mail này được chia sẻ với nhiều người dùng khác và
được quản lý bởi ISP của người dùng (như trường học hay công ty).
Xem đường đi của một thông điệp thư điện tử khi được gửi từ Alice
đến Bob. Và thông điệp điện tử này cần đến được máy phục vụ mail
của Bob. Điều này thực sự có thể thực hiện được bằng cách dùng giao
thức SMTP, SMTP được thiết kế cho việc đẩy thư điện tử từ một máy
trên mạng này đến một máy trên mạng khác. Tuy nhiên, user agent
của người dùng điển hình không nói chuyện trực tiếp với máy phục vụ
mail của người nhận. Thay vào đó, như trong hình 2.18, user agent
của người dùng dùng SMTP để đẩy thông điệp thư điện tử vào trong
máy phục vụ mail của cô ấy, kế tiếp máy phục vụ mail của cô ấy sẽ
dùng SMTP (như một SMTP khách) để chuyển thông điệp thư điện tử
đến máy phục vụ mail của Bob. Quá trình này phải trải qua 2 bước
như vậy, vì user agent của Alice không có bất kì yêu cầu nào đến một
máy phục vụ mail không hoạt động của người nhận, nên khi Alice đặt
một thư điện tử cần gửi trong máy phục vụ mail của cô ta, nếu như
máy phục vụ mail của người nhận không hoạt động hoặc có sự cố thì
thư điện tử Alice muốn gửi vẫn còn lưu trữ trên máy phục vụ mail của
Alice và máy phục vụ mail của Alice sẽ cố gắng lặp lại việc gửi thông
điệp đến máy phục vụ mail của Bob cứ mỗi 30 phút cho đến khi máy
phục vụ mail của Bob hoạt động. RFC mô tả SMTP có định nghĩa các
câu lệnh SMTP có thể được dùng để chuyển tiếp một thông điệp sẽ đi
qua nhiều máy phục vụ SMTP.
Một người nhận thư như Bob, dùng user agent trên máy PC cục bộ
của anh ta, lấy thông điệp của anh ta trong máy phục vụ mail trong
phạm vi ISP của Bob như thế nào? User agent của Bob không thể
dùng SMTP để lấy thông điệp vì việc lấy thông điệp là hành động kéo,
trong khi SMTP là một giao thức đẩy. Vậy giao thức nào sẽ hỗ trợ cho
việc lấy thư từ máy phục vụ mail của Bob về máy tính cục bộ của anh
ta. Hiện giờ có một số giao thức truy cập thư điện tử phổ biến như
134
POP3 (Post Office Protocol – Version 3), IMAP (Internet Mail Access
Protocol) và HTTP.
Hình 2.18. cung cấp bảng tóm tắt các giao thức dùng trong mail
Internet: SMTP được dùng cho truyền thư từ máy phục vụ mail của
người gửi đến máy phục vụ mail của người nhận; SMTP cũng được
dùng để chuyển mail từ user agent của người gửi đến máy phục vụ
mail của người gửi. Một giao thức truy cập mail, như POP3, được
dùng để truyền mail từ máy phục vụ mail của người nhận đến user
agent của người nhận.
Hình 2.18. Giao thức thư điện tử và các thực thể truyền thông
POP3
POP3 là một giao thức truy cập mail đơn giản. Được định nghĩa trong
RFC 1939. Vì giao thức đơn giản, các chức năng của nó cũng khá giới
hạn. POP3 bắt đầu khi user agent (máy khách) mở kết nối TCP đến
máy phục vụ mail (máy phục vụ) trên cổng 110. Với kết nối TCP
được thiết lập, POP3 hoạt động qua 3 giai đoạn: phân quyền, giao
dịch, và cập nhật. Trong suốt giai đoạn một (phân quyền) user agent
gửi username và mật khẩu để chứng thực người dùng. Trong giai đoạn
hai (giao dịch) user agent nhận thông điệp; cũng trong giai đoạn này,
user agent có thể đánh dấu thông điệp cần xóa, gỡ bỏ các dấu xóa, và
thống kê thư. Giai đoạn ba (cập nhật) diễn ra sau khi máy khách gửi
câu lệnh QUIT, kết thúc phiên POP3, lúc này máy phục vụ mail sẽ
xóa các thông điệp được đánh dấu là xóa.
Trong giao dịch POP3, user agent gửi các câu lệnh, máy phục vụ trả
lời mỗi yêu cầu. Có hai cách trả lời có thể: +OK cho biết là câu lệnh
trước đó chính xác, hoặc –ERR cho biết câu lệnh trước đó không
chính xác.
135
Giai đoạn phân quyền có 2 câu lệnh: user <username> và pass <mật
khẩu>. Để minh họa 2 câu lệnh này, dùng telnet trực tiếp đến máy
phục vụ POP3 qua cổng 110, và gửi các câu lệnh. Giả sử mailServer
là tên máy phục vụ mail của bạn:
telnet mailServer 110
+OK POP3 server ready
user bob
+OK
pass hungry
+OK user successfully logged on
Nếu câu lệnh gõ sai, máy phục vụ POP3 sẽ gửi lại thông báo –ERR.
Trong giai đoạn giao dịch, user agent dùng giao thức POP3 thường
được cấu hình bởi người dùng để “tải về và xóa” hoặc “tải về và giữ
lại”. Chuỗi lệnh được gửi bởi user agent POP3 phụ thuộc vào dạng
nào trong 2 dạng hoạt động trên của người dùng. Trong dạng “tải về
và xóa” user agent sẽ gửi các lệnh LIST, RETR, và DELE. Ví dụ,
người dùng có 2 thông điệp trong hộp thư. Trong đoạn đối thoại bên
dưới, C: là user agent và S: là máy phục vụ mail. Giao dịch diễn ra
như sau:
C: list
S: 1 498
S: 2 912
S: .
C: retr 1
S: (blah blah ….
S: ……………..
S: …. blah blah)
S: .
C: dele 1
C: retr 2
S: (blah blah ….
136
S: ……………..
S: ……………..
S: ….. blah blah)
S: .
C: dele 2
C: quit
S: +0K P0P3 server signing off
Theo ví dụ trên, đầu tiên user agent dùng lệnh LIST để yêu cầu máy
phục vụ mail liệt kê các thông điệp và kích thước của các thông điệp
được lưu trữ. Các dòng tiếp theo là user agent dùng lệnh RETR và
DELE để lấy và xóa đi từng thông điệp từ máy phục vụ. Sau giai đoạn
phân quyền, user agent dùng 4 câu lệnh: LIST, RETR, DELE, và
QUIT. Cú pháp của các lệnh này được định nghĩa trong RFC 1939.
Sau khi xử lý câu lệnh QUIT, máy phục vụ POP3 thêm vào giai đoạn
cập nhật và bỏ đi thông điệp 1 hoặc 2 từ hộp thư.
Một vấn đề với dạng “tải về và xóa” là người nhận (Bob) có thể di
chuyển và truy cập vào các thông điệp thư của anh ta từ nhiều máy, ví
dụ như từ máy tính văn phòng, từ máy tính ở nhà và máy tính di động.
Dạng “tải về và xóa” phân các thông điệp thư của Bob trên 3 máy, nếu
như Bob đầu tiên đọc thông điệp trên máy tính văn phòng, anh ấy sẽ
không thể đọc lại thư trên máy tính xách tay ở nhà sau đó vào buổi tối.
Trong kiểu “tải về và giữ lại”, user agent để lại các thông điệp trên
máy phục vụ mail sau khi tải về. Trong trường hợp này thì Bob có thể
đọc lại thư từ các máy khác nhau; anh ấy có thể truy cập một thư từ
nơi làm việc hoặc truy cập lại ở nhà trong tuần.
Trong suốt phiên truyền POP3 giữa user agent và máy phục vụ mail,
máy phục vụ POP3 bảo quản các thông tin trạng thái, đặc biệt, nó truy
vết thông điệp người dùng nào vừa được đánh dấu xóa. Tuy nhiên,
máy phục vụ POP3 không lưu vết trạng thái người dùng qua các phiên
làm việc POP3, việc thiếu thông tin trạng thái này qua các phiên làm
việc giúp đơn giản hóa việc cài đặt máy phục vụ POP3.
IMAP
137
Với việc truy cập POP3, khi Bob tải các thư của anh ấy về máy tính
cục bộ, anh ấy tạo các thư mục thư và chép các thư đã tải về vào các
thư mục. Bob kế đó có thể xóa các thư, chép các thư qua các thư mục
khác và tìm thư (theo tên hay chủ đề). Nhưng với lược đồ này, các thư
mục và các thư trên máy tính cục bộ sẽ làm phát sinh một vấn đề cho
người dùng thường thay đổi máy truy cập, họ thích có một thư mục
phân cấp trên máy phục vụ từ xa để có thể truy cập đến từ bất kì máy
tính nào. Điều này không thể dùng POP3 để giải quyết, giao thức
POP3 không cung cấp bất kì phương tiện nào cho người dùng để tạo
các thư mục từ xa và chỉ định thư đến các thư mục.
Để giải quyết vấn đề này và các vấn đề khác, giao thức IMAP, được
định nghĩa trong RFC 3501 và được chú ý đầu tư. Giống như POP3,
IMAP là một giao thức truy cập thư, nhưng có nhiều đặc trưng hơn
POP3, và cũng phức tạp hơn, nên việc cài đặt trên hai bên máy phục
vụ và máy khách cũng phức tạp hơn.
Một máy phục vụ IMAP liên kết mỗi thư với một thư mục; khi một
thư đầu tiên đến máy phục vụ, nó sẽ được đưa vào thư mục hộp thư
của người nhận. Người nhận có thể di chuyển thư đến thư mục mới
tạo, đọc thư, xóa thư, v.v. Giao thức IMAP cung cấp các câu lệnh cho
phép người dùng tạo thư mục và chép thư từ thư mục này đến thư mục
khác. IMAP cũng cung cấp các câu lệnh cho phép người dùng tìm các
thư mục từ xa thỏa các tiêu chuẩn cụ thể. Không giống như POP3,
một máy phục vụ IMAP bảo quản thông tin trạng thái người dùng qua
các phiên IMAP, ví dụ tên của thư mục và thông điệp nào liên quan
đến thư mục nào.
Một nét đặc trưng quan trọng khác của IMAP là có câu lệnh cho phép
user agent lấy các thành phần của thư. Ví dụ, một user agent có thể lấy
được header của thư hay chỉ một phần của nhiều thư MIME nhiều
phần. Đặc trưng này hữu ích khi có một kết nối băng thông thấp giữa
user agent và máy phục vụ mail. Với kết nối băng thông thấp, người
dùng có thể không muốn tải về tất cả các thư trong hộp thư, đặc biệt là
tránh những thư dài như chứa các tập tin âm thanh và hình ảnh.
Thư điện tử dùng web
138
Ngày càng nhiều người dùng ngày nay gửi và nhận thư điện tử thông
qua trình duyệt. Hotmail đề xuất truy cập thư dùng web vào giữa thập
niên 90, và ngày nay thì đã có nhiều dịch vụ thư điện tử dùng web như
Yahoo, Google cũng như dịch vụ mail của một số trường học và tổ
chức lớn. Với dịch vụ này, user agent là trình duyệt web thông
thường, và người dùng truyền thông với hộp thư từ xa qua giao thức
HTTP. Khi người nhận, Bob, muốn đọc thư trong hộp thư của anh ta,
thư điện tử được gửi từ máy phục vụ mail của Bob đến trình duyệt của
Bob dùng giao thức HTTP hơn là dùng POP3 và IMAP. Khi người
gửi, Alice, muốn gửi thư điện tử từ trình duyệt đến máy phục vụ mail
của cô ấy dùng HTTP hơn là SMTP. Máy phục vụ mail của Alice vẫn
gửi thư đến và nhận thư từ các máy phục vụ mail khác dùng SMTP.
V. Dịch vụ DNS
Con người có thể được định danh bằng nhiều cách, như: định danh
bằng họ tên trong giấy khai sinh, số bảo hiểm xã hội, số hiệu bằng lái
xe. Mặc dù các con số này có thể định danh được cho một người duy
nhất, nhưng trong một trường hợp cụ thể nào đó thì con số này thực sự
sẽ có ý nghĩa hơn. Ví dụ, các máy tính ở IRS hay dùng các con số bảo
hiểm xã hội có độ dài cố định hơn là họ tên khai sinh. Mặt khác, nhiều
người thích dùng tên khai sinh dễ nhớ hơn là các con số bảo hiểm xã
hội.
Con người có thể được định danh bằng nhiều cách, các máy tính trên
Internet cũng vậy. Một định danh cho một máy tính là tên của máy
tính đó (hostname). Các tên máy tính như cnn.com, www.yahoo.com,
gaia.cs.umass.edu và cis.poly.edu dễ nhớ nên cũng thích hợp với con
người hơn. Tuy nhiên, các tên máy tính cung cấp ít thông tin về vị trí
trên Internet của một máy tính mạng. Ngoài ra, vì tên máy tính mạng
có thể chứa các kí tự chữ và số với độ dài khác nhau, khó để xử lý bởi
các bộ định tuyến. Do đó các máy tính mạng được định danh bằng
một thứ khác, gọi là địa chỉ IP (IP address).
Địa chỉ IP sẽ được trình bày một cách chi tiết trong chương 4. Một địa
chỉ IP gồm 4 bytes và có cấu trúc phân cấp nghiêm ngặt. Địa chỉ IP sẽ
có dạng như thế này 121.7.106.83, mỗi dấu chấm “.” phân chia 1 byte
có giá trị theo hệ thập phân từ 0 đến 255. Một địa chỉ IP là phân cấp vì
139
khi xem địa chỉ IP từ trái sang phải, sẽ có nhiều thông tin cụ thể hơn
về nơi máy tính mạng được đặt trên Internet (ở mạng nào). Tương tự
như khi chúng ta quét qua địa chỉ bưu điện từ dưới lên trên, chúng ta
có nhiều thông tin hơn về người trong địa chỉ nhà.
V.1 Các dịch vụ được DNS cung cấp
Có 2 cách để định danh một máy tính mạng: tên máy tính mạng và địa
chỉ IP. Con người thích các định danh máy tính mạng dễ nhớ, trong
khi các bộ định tuyến muốn các địa chỉ IP có cấu trúc phân cấp chiều
dài cố định. Để thỏa các mong muốn này, cần có một dịch vụ thư mục
(directory service) dịch tên máy tính mạng thành địa chỉ IP. Đây là
nhiệm vụ chính của hệ thống tên miền (DNS – Domain Name System)
của Internet. DNS là (1) một cơ sở dữ liệu phân tán được cài đặt với
hệ thống phân cấp của các máy phục vụ DNS và (2) một giao thức
tầng Ứng dụng cho phép các máy tính mạng truy vấn cơ sở dữ liệu
phân tán. Các máy phục vụ DNS thường là máy UNIX dùng phần
mềm BIND (Berkeley Internet Name Domain). Giao thức DNS chạy
trên giao thức UDP và dùng cổng 53.
DNS được dùng bởi các giao thức tầng Ứng dụng khác gồm HTTP,
SMTP, và FTP để chuyển các tên máy tính thành địa chỉ IP. Ví dụ xét
kết quả khi trình duyệt (HTTP khách) chạy trên máy tính của người
dùng, yêu cầu truy cập trang www.someschool.edu/index.html. Để
máy tính người dùng có thể gửi thông điệp yêu cầu HTTP đến máy
phục vụ web www.someschool.edu, máy tính người dùng đầu tiên phải
lấy được địa chỉ IP của www.someschool.edu, như sau:
1. Máy tính người dùng chạy ứng dụng DNS khách
2. Trình duyệt trích tên máy tính mạng, www.someschool.edu, từ
URL và gửi đến ứng dụng DNS khách
3. DNS khách gửi câu truy vấn chứa tên máy tính đến DNS chủ
4. DNS khách nhận phản hồi, gồm địa chỉ IP của tên máy tính
5. Khi trình duyệt nhận địa chỉ IP từ DNS, nó khởi tạo một kết nối
TCP đến tiến trình máy phục vụ HTTP tại cổng 80 trên máy có địa
chỉ IP đó
140
DNS thêm một thời gian đợi đến các ứng dụng Internet dùng nó. Địa
chỉ IP tương ứng thường được lưu vào máy phục vụ DNS gần nhất,
giúp giảm lưu thông truy cập mạng DNS cũng như thời gian truy cập
DNS trung bình.
DNS cung cấp vài dịch vụ quan trọng khác ngoài dịch vụ chuyển tên
máy thành các địa chỉ IP:
- Đặt bí danh cho máy tính mạng (Host aliasing): Một máy tính
mạng với tên phức tạp có thể có một hoặc nhiều tên bí danh khác.
Ví dụ một tên máy tính là relay1.west-coast.enter-prise.com có thể
có 2 bí danh là: enterprise.com và www.enterprise.com. Trong đó,
relay1.west-coast.enter-prise.com được gọi là tên máy tính mạng
gốc (canonical hostname). Các bí danh dễ nhớ hơn các tên máy
tính mạng gốc.
- Đặt bí danh cho máy phục vụ mail (Mail server aliasing): Địa
chỉ thư điện tử cũng có yêu cầu sao cho dễ nhớ. Ví dụ Bob có một
tài khoản Hotmail, địa chỉ thư điện tử của Bob có thể đơn giản là
bob@hotmail.com. Tuy nhiên, tên máy tính mạng của máy phục
vụ Hotmail phức tạp hơn và ít dễ nhớ hơn tên đơn giản là
hotmail.com (ví dụ, tên máy tính mạng gốc là relay1.west-
coast.hotmail.com). Ứng dụng mail kích hoạt DNS để lấy tên máy
tính mạng gốc của tên bí danh hay địa chỉ IP của máy tính mạng.
Thật ra, bảng MX cho phép máy phục vụ mail của công ty và máy
phục vụ web có tên bí danh giống nhau; ví dụ máy phục vụ web
của công ty và máy phục vụ mail của công ty có thể đều được gọi
là enterprise.com
- Phân tán tải (Load distribution): DNS cũng được dùng để thực
hiện phân tán tải giữa các máy phục vụ, như các máy phục vụ
web. Các trang có nhiều truy cập như cnn.com, được nhân bảng
trên nhiều máy phục vụ, với mỗi máy phục vụ chạy trên hệ cuối
khác và có địa chỉ IP khác. Đối với các máy phục vụ web nhân
bảng, một tập các địa chỉ IP được liên kết đến tên máy tính mạng
gốc. Cơ sở dữ liệu DNS chứa tập địa chỉ IP này. Khi các máy
khách gửi một truy vấn DNS cho một tên được ánh xạ bởi một tập
địa chỉ, máy phục vụ phản hồi với toàn bộ tập địa chỉ IP, nhưng
xoay vòng thứ tự địa chỉ trong mỗi lần phản hồi. Vì một máy
141
khách cụ thể gửi một thông điệp yêu cầu HTTP đến một địa chỉ IP
được liệt kê trong tập, sự xoay vòng của DNS phân tán lưu thông
giữa các máy phục vụ nhân bảng, sự xoay vòng của DNS cũng
được dùng cho thư điện tử để nhiều máy phục vụ mail có thể có
cùng bí danh. Gần đây, các công ty phân tán nội dung như Akamai
vừa dùng DNS theo các cách phức tạp hơn để cung cấp sự phân
tán nội dung web (xem trang 7).
DNS được đặc tả trong RFC 1034 và RFC 1035, và có thêm một số
RFC bổ sung. Đây là một hệ thống phức tạp, trong phạm vi sách giáo
khoa này chỉ bàn đến các khía cạnh đặc trưng chính yếu của hoạt động
DNS.
V.2 Cách thức DNS làm việc
Giả sử một ứng dụng nào đó (như trình duyệt web hay công cụ đọc
mail) chạy trên máy người dùng cần dịch tên máy tính thành địa chỉ
IP. Ứng dụng sẽ kích hoạt DNS khách, đặc tả tên máy tính mạng cần
dịch. (Trên nhiều máy tính UNIX, gethostname() là hàm ứng dụng
dùng để yêu cầu thực hiện việc chuyển đổi này). DNS trên máy người
dùng gửi một thông điệp truy vấn lên mạng. Tất cả các thông điệp
DNS truy vấn và phản hồi được gửi bằng gói UDP qua cổng 53. Sau
một thời gian trì hoãn, trong khoảng từ vài mili giây đến vài giây,
DNS trên máy người dùng nhận một thông điệp DNS phản hồi cung
cấp ánh xạ mong muốn. Ánh xạ này được truyền đến ứng dụng đang
được kích hoạt. Do đó, đối với ứng dụng thì DNS là một hộp đen cung
cấp một dịch vụ chuyển đổi trực tiếp và đơn giản. Nhưng sự thật về
việc thực hiện dịch vụ của hộp đen này thì phức tạp, bao gồm vấn đề
có nhiều máy phục vụ DNS được phân tán trên toàn cầu, cũng như
vấn đề về giao thức tầng Ứng dụng đặc tả các máy phục vụ DNS và
các máy tính mạng truy vấn truyền thông.
Một thiết kế đơn giản cho DNS gồm một máy phục vụ DNS chứa tất
cả các ánh xạ. Trong thiết kế tập trung này, các máy khách đơn giản
hướng tất cả các câu truy vấn đến máy phục vụ DNS đơn, và máy
phục vụ DNS phản hồi trực tiếp đến các máy khách truy vấn. Mặc dù
sự đơn giản trong thiết kế này thật hấp dẫn, nhưng nó không thích hợp
142
với Internet ngày nay với số máy tính mạng tăng trưởng quá nhanh.
Vấn đề với thiết kế tập trung gồm:
- Điểm duy nhất thất bại sẽ ảnh hưởng đến toàn hệ thống (a single
point of failure): Nếu máy phục vụ DNS ngừng hoạt động, toàn bộ
Internet cũng sẽ ngừng hoạt động.
- Vấn đề lưu lượng (traffic volumn): Vấn đề này phát sinh do một
máy phục vụ DNS đơn phải xử lý tất cả các truy vấn DNS (đối với
tất cả các thông điệp yêu cầu HTTP và các thư điện tử phát sinh từ
hàng triệu máy tính mạng).
- Cơ sở dữ liệu tập trung ở xa (Distant centralized database): Một
máy phục vụ DNS thường không ở gần với các máy khách đang
thực hiện truy vấn. Ví dụ như một máy phục vụ DNS đơn được đặt
ở thành phố New York, tất cả câu truy vấn từ Úc phải đi đến phía
bên kia trái đất để yêu cầu dịch vụ sẽ có thể đi qua các kênh truyền
chậm và tắc nghẽn. Vấn đề này dẫn đến các khoảng thời gian trì
hoãn đáng kể.
- Bảo trì (maintenance): Máy phục vụ DNS đơn giữ các bảng dữ liệu
ánh xạ cho tất cả các máy tính mạng Internet. Không chỉ cơ sở dữ
liệu tập trung này khổng lồ mà nó còn thường xuyên được cập nhật
đến các thông tin của mọi máy tính mạng mới.
Một cơ sở dữ liệu tập trung trên máy phục vụ DNS đơn khá đơn giản
và không thể mở rộng phạm vi. Do đó DNS được thiết kế phân tán.
Thực ra DNS là một ví dụ hoàn hảo cho mô hình cơ sở dữ liệu phân
tán được cài đặt trên Internet.
Một cơ sở dữ liệu phân cấp và phân tán
Để giải quyết các vấn đề liên quan khả năng mở rộng phạm vi, DNS
dùng nhiều máy phục vụ, được tổ chức thành kiểu phân cấp và được
phân tán quanh thế giới. Không có máy phục vụ DNS đơn nào chứa
tất cả ánh xạ dành cho toàn bộ máy tính mạng trên Internet. Thay vào
đó, ánh xạ được phân tán qua các máy phục vụ DNS. Có 3 loại máy
phục vụ DNS – máy phục vụ DNS gốc (root DNS servers), máy phục
vụ DNS mức đỉnh (Top-level domain DNS server), máy phục vụ DNS
thẩm quyền (authoritative DNS server) – được tổ chức thành một cây
143
phân cấp như trong hình 2.19. Giả sử một máy DNS khách muốn xác
định địa chỉ IP của máy tính có tên www.amazon.com. Máy khách
đầu tiên liên lạc với các máy phục vụ gốc, trả về địa chỉ IP của các
máy phục vụ TLD cho tên miền com. Máy khách liên lạc với một
trong số các máy phục vụ TLD này để nhận về địa chỉ IP của máy
phục vụ thẩm quyền cho amazon.com. Cuối cùng, máy khách liên lạc
với một trong các máy phục vụ thẩm quyền cho amazon.com để nhận
về địa chỉ IP của tên máy tính www.amazon.com.
Hình 2.19. Thành phần của kiến trúc phân cấp các máy phục vụ DNS
- Các máy phục vụ DNS gốc: Trên Internet có 13 máy phục vụ
DNS gốc (dán nhãn từ A đến M), đa số được đặt ở Bắc Mỹ. Tháng
10/2006 sơ đồ các máy phục vụ DNS gốc được vẽ như hình 2.20.
Mặc dù chúng ta tham chiếu đến một trong 13 máy phục vụ DNS
gốc giống như đó chỉ là một máy phục vụ đơn, và mỗi “máy phục
vụ” như vậy thực chất là một cụm các máy phục vụ nhân bảng vì
hai mục đích bảo mật và tính sẵn dùng.
144
Hình 2.20. Các máy phục vụ DNS gốc năm 2009 (tên, tổ chức, vị trí)
- Các máy phục vụ mức đỉnh: Các máy phục vụ này chịu trách
nhiệm cho các miền mức cao nhất như .com, .org, .net, .edu, và
.gov, và tất cả các tên miền mức đỉnh tầm quốc gia như .uk, .fr,
.ca, và .jp. Ví dụ như: công ty Network Solutions bảo quản các
máy phục vụ TLD cho tên miền mức đỉnh .com, và công ty
Educause bảo quản các máy phục vụ TLD cho tên miền mức đỉnh
edu.
- Các máy phục vụ DNS thẩm quyền: Mỗi tổ chức với các máy tính
mạng truy cập công cộng (như các máy phục vụ web và các máy
phục vụ mail) trên Internet cung cấp các bảng DNS truy cập công
cộng ánh xạ tên của các máy tính mạng này với các địa chỉ IP.
Một máy phục vụ DNS thẩm quyền của tổ chức chứa các bảng
DNS này. Một tổ chức có thể chọn cài đặt máy phục vụ DNS thẩm
quyền để giữ các bảng ánh xạ, nhưng cũng có thể thuê một máy
phục vụ DNS thẩm quyền của một nhà cung cấp dịch vụ nào đó để
lưu các bảng ánh xạ này. Đa số các trường học và các công ty lớn
cài đặt và bảo trì các máy phục vụ DNS thẩm quyền chính và phụ
của riêng họ.
145
Các máy phục vụ gốc, máy phục vụ mức đỉnh và máy phục vụ DNS
thẩm quyền thuộc hệ thống phân cấp các máy phục vụ DNS như trong
hình 2.19. Có một loại máy phục vụ DNS khác nữa được gọi là máy
phục vụ DNS cục bộ (local DNS server). Một máy phục vụ DNS cục
bộ không thuộc vào hệ thống phân cấp máy phục vụ nghiêm ngặt
nhưng lại đóng vai trò quan trọng trong kiến trúc DNS. Mỗi ISP (như
đại học, một ban học thuật, một công ty, hay một ISP của người dùng
thường) có một máy phục vụ DNS cục bộ (cũng có tên là default
name server). Khi một máy tính mạng kết nối đến ISP, ISP cung cấp
cho máy tính mạng các địa chỉ IP của một hoặc nhiều máy phục vụ
DNS cục bộ (cụ thể là thông qua DHCP, được trình bày chi tiết trong
chương 4). Có thể xác định được địa chỉ IP của máy phục vụ DNS cục
bộ bằng cách truy cập vào trạng thái mạng trong Windows hay UNIX.
Một máy phục vụ DNS cục bộ của máy tính mạng cụ thể được đặt
“gần” với các máy tính mạng. Với ISP của tổ chức, máy phục vụ DNS
cục bộ có thể cùng mạng LAN với máy tính mạng; với ISP của người
dùng thường là bộ định tuyến. Khi một máy tính mạng thực hiện truy
vấn DNS, câu truy vấn được gửi đến máy phục vụ DNS cục bộ, hoạt
động như một proxy, chuyển câu truy vấn đến hệ thống phân cấp máy
phục vụ DNS.
Ví dụ, giả sử cis.poly.edu muốn có địa chỉ IP của gaia.cs.umass.edu.
Giả sử máy phục vụ DNS cục bộ của Polytechnic được gọi là
dns.poly.edu và một máy phục vụ DNS thẩm quyền cho
gaia.cs.umass.edu được gọi là dns.umass.edu. Như trong hình 2.21,
máy tính mạng cis.poly.edu đầu tiên gửi thông điệp truy vấn DNS đến
máy phục vụ DNS cục bộ dns.poly.edu. Thông điệp truy vấn chứa tên
máy tính mạng là gaia.cs.umass.edu. Máy phục vụ DNS cục bộ
chuyển thông điệp truy vấn đến máy phục vụ DNS gốc. Máy phục vụ
DNS gốc xét đuôi edu trong tên máy và trả về danh sách các địa chỉ IP
của các máy phục vụ DNS TLD quản lý edu. Máy phục vụ DNS cục
bộ gửi lại thông điệp truy vấn đến một trong các máy phục vụ DNS
TLD. Máy phục vụ TLD sẽ lấy phần đuôi umass.edu và phản hồi địa
chỉ IP của máy phục vụ DNS thẩm quyền của trường đại học
Massachusetts có tên là dns.umass.edu. Cuối cùng máy phục vụ DNS
cục bộ gửi lại thông điệp truy vấn trực tiếp đến dns.umass.edu và nhận
về địa chỉ IP của gaia.cs.umass.edu. Trong ví dụ này, để lấy được ánh
146
xạ tên của máy tính mạng, 8 thông điệp DNS được gửi: 4 thông điệp
truy vấn và 4 thông điệp trả lời.
Trong ví dụ này giả sử máy phục vụ TLD biết máy phục vụ thẩm
quyền quản lý tên máy tính mạng. Nói chung cách này không phải
luôn luôn đúng. Có thể máy phục vụ TLD chỉ biết các máy phục vụ
DNS trung gian và các máy phục vụ trung gian này biết được máy
phục vụ DNS thẩm quyền cho tên máy tính mạng. Ví dụ, giả sử Đại
học Massachusetts có một máy phục vụ DNS dành cho đại học là
dns.umass.edu.
Thêm giả thuyết là mỗi khoa ở đại học Massachusetts có máy phục vụ
DNS riêng, và mỗi máy phục vụ DNS thẩm quyền này chịu trách
nhiệm quản lý tên của tất cả các máy tính mạng trong khoa. Trường
hợp này thì các máy phục vụ DNS trung gian như dns.umass.edu nhận
một câu truy vấn tên của một máy tính mạng với tên máy tính mạng
kết thúc là cs.umass.edu sẽ trả về cho dns.poly.edu địa chỉ IP của
dns.cs.umass.edu. Máy phục vụ DNS cục bộ dns.poly.edu gửi truy vấn
đến máy phục vụ DNS thẩm quyền, trả lại ánh xạ mong muốn đến
máy phục vụ DNS cục bộ, rồi tiếp tục trả ánh xạ về máy phục vụ đang
yêu cầu. Tổng cộng có 10 thông điệp DNS được gửi.
Ví dụ trong hình 2.21 dùng các câu truy vấn đệ qui (recursive queries)
và các câu truy vấn tuần tự (iterative queries). Câu truy vấn được gửi
từ cis.poly.edu đến dns.poly.edu là một câu truy vấn đệ qui, vì câu truy
vấn gửi đến hỏi dns.poly.edu để lấy về ánh xạ và dns.poly.edu lại
dùng tiếp 3 câu truy vấn liên tục để có được ánh xạ đó. Theo lý thuyết,
bất kì câu truy vấn DNS nào có thể là tuần tự hoặc đệ qui. Ví dụ, hình
2.22 cho thấy chuỗi truy vấn DNS với tất cả các truy vấn là tuần tự.
Trong thực tế, các câu truy vấn điển hình theo mẫu trong hình 2.21:
câu truy vấn từ máy đang yêu cầu đến máy phục vụ DNS cục bộ của
nó là đệ qui, và các câu truy vấn còn lại là tuần tự.
147
Hình 2.21. Tương tác giữa các máy phục vụ DNS khác nhau
DNS caching
DNS khai thác DNS caching để làm tăng hiệu năng và giảm số thông
điệp DNS. Trong chuỗi truy vấn, khi một máy phục vụ DNS nhận một
phản hồi DNS (chứa ánh xạ từ tên máy tính mạng đến một địa chỉ IP),
nó có thể ghi nhớ ánh xạ trong bộ nhớ cục bộ. Ví dụ, trong hình 2.21,
mỗi lần máy phục vụ DNS cục bộ dns.poly.edu nhận một phản hồi từ
một máy phục vụ DNS nào đó, nó có thể lưu lại thông tin này. Nếu tên
máy tính mạng hay địa chỉ IP được lưu lại trên máy phục vụ DNS rồi,
thì câu truy vấn khác gửi đến hỏi máy phục vụ DNS hỏi địa chỉ IP của
một tên được lưu trên máy phục vụ DNS rồi thì máy phục vụ DNS có
thể cung cấp địa chỉ IP ngay lập tức, thậm chí nếu nó phả là máy phục
vụ DNS thẩm quyền quản lý tên máy tính mạng. Vì các máy tính
mạng và ánh xạ giữa tên máy tính mạng và địa chỉ IP không thường
trực, các máy phục vụ DNS có thể bỏ thông tin được lưu sau một chu
kì thời gian (thường là 2 ngày).
148
Ví dụ, giả sử máy tính mạng apricot.poly.edu truy vấn dns.poly.edu về

địa chỉ IP của cnn.com. Giả sử vài giờ sau đó, một máy tính mạng Đại
học Polytechnic có tên kiwi.poly.fr cũng có truy vấn tương tự với
dns.poly.edu. Vì thông tin sau khi trả lời truy vấn cho máy tính thứ
nhất đã được lưu lại nên máy phục vụ DNS cục bộ có thể trả về địa
chỉ IP của cnn.com cho máy tính thứ hai ngay lập tức, mà không cần
truy vấn đến bất kì máy phục vụ DNS nào khác. Một máy phục vụ
DNS cục bộ cũng có thể lưu địa chỉ IP của các máy phục vụ TLD, cho
phép các máy phục vụ DNS cục bộ bỏ qua việc truy vấn đến các máy
phục vụ DNS gốc.
Hình 2.22. Các câu truy vấn đệ qui trong DNS
149
V.3 Các mẩu tin DNS và các messages

Các máy phục vụ DNS cài đặt các cơ sở dữ liệu DNS phân tán gồm
các bảng tài nguyên (RR – Resource Record), bao gồm các RR cung
cấp ánh xạ tên máy tính mạng – địa chỉ IP. Mỗi thông điệp phản hồi
DNS mang một hay nhiều RR. Một RR gồm 4 phần chứa các trường
sau :
(Name, Value, Type, TTL)
TTL (time to live) là thời gian tồn tại của các RR; ra quyết định RR có
nên được xóa khỏi bộ nhớ không. Trong ví dụ RR bên dưới, bỏ qua
TTL, Name và Value phụ thuộc vào Type :
- Nếu Type=A thì Name là tên máy tính mạng và Value là địa chỉ IP
ứng với tên máy tính mạng. Do đó, kiểu RR là A cung cấp một
ánh xạ tên máy tính mạng – địa chỉ IP, ví dụ RR
(relayl.bar.foo.com, 145.37.93.126, A) có kiểu RR là A
- Nếu Type=NS thì Name là miền (domain) (như foo.com) và Value
là tên máy tính mạng của máy phục vụ DNS thẩm quyền để tìm
địa chỉ IP tương ứng với các máy tính mạng trong miền. RR này
dùng cho định tuyến các truy vấn trong chuỗi truy vấn. Ví dụ RR
là (foo.com, dns.foo.com, NS) là RR có kiểu NS
- Nếu Type=CNAME thì Value là tên máy phục vụ mạng gốc với bí
danh trong trường Name. RR này có thể cung cấp cho các máy
tính mạng đang truy vấn biết tên gốc ứng với tên của máy tính
mạng. Ví dụ : RR (foo.com, relay1.bar.foo.com, CNAME) là RR
kiểu CNAME
- Nếu Type=MX thì Value là tên gốc của máy phục vụ mail có bí
danh là Name. Ví dụ: (foo.com, mail.bar.foo.com, MX) là RR kiểu
MX. RR kiểu MX cho phép các tên máy tính mạng của các máy
phục vụ mail có các bí danh đơn giản. Dùng RR kiểu MX, các
công ty có thể dùng cùng một bí danh cho máy phục vụ mail và
một trong các máy phục vụ khác của nó (như máy phục vụ web).
Để lấy được tên gốc cho máy phục vụ mail, một DNS khách gửi
RR truy vấn kiểu MX ; và để lấy tên gốc cho máy phục vụ khác,
DNS khách truy vấn RR kiểu CNAME.
150
Nếu máy phục vụ DNS có thẩm quyền cho một tên máy tính mạng cụ
thể thì máy phục vụ DNS sẽ chứa một RR kiểu A tương ứng với tên
máy tính mạng (thậm chí nếu máy phục vụ DNS không có thẩm
quyền, nó cũng có thể chứa RR kiểu A trong bộ nhớ của nó). Nếu máy
phục vụ không có thẩm quyền ứng với một tên máy tính mạng, nó sẽ
chứa RR kiểu NS cho miền của tên máy tính mạng, nó cũng chứa RR
kiểu A cung cấp địa chỉ IP của máy phục vụ DNS trong giá trị Value
của RR kiểu NS. Ví dụ, giả sử có một máy phục vụ TLD không có
thẩm quyền đối với máy tính mạng gaia.cs.umass.edu. Máy phục vụ
này chứa một RR kiểu NS cho miền của gaia.cs.umass.edu là
(umass.edu, dns.umass.edu, NS). Máy phục vụ TLD edu cũng chứa
một RR kiểu A ánh xạ máy phục vụ DNS dns.umass.edu đến một địa
chỉ IP, ví dụ như (dns.umass.edu, 128.119.40.111, A).
Các thông điệp DNS
Có 2 loại thông điệp DNS. Cả 2 thông điệp truy vấn và trả lời có cùng
định dạng, như trong hình 2.23. Ngữ nghĩa của các trường trong thông
điệp DNS như sau :
- 12 byte đầu tiên là phần header, chứa các trường. Trường đầu là
một số 16 bit dùng để định danh câu truy vấn. Định danh
(Identifier) này được chép vào thông điệp trả lời, cho phép máy
khách chọn các câu trả lời nhận được nào khớp với các câu truy
vấn đã gửi. Có các cờ (flag) trong trường cờ. Một cờ truy vấn/trả
lời (query/reply flag) 1 bit cho biết thông điệp đó là truy vấn (cờ
tắt, giá trị là 0), hay trả lời (cờ bật, giá trị là 1). Một cờ thẩm quyền
(authoritative flag) 1 bit được đặt trong thông điệp trả lời khi máy
phục vụ DNS là máy phục vụ thẩm quyền cho một tên được truy
vấn. Một cờ đệ qui (recursion-desired flag) 1 bit được đặt khi máy
khách (máy tính mạng hay máy phục vụ DNS) muốn máy phục vụ
DNS thực hiện câu truy vấn đệ qui khi máy phục vụ DNS không
có RR thích hợp. Một trường đánh dấu có hỗ trợ đệ qui (recursion
available) 1 bit được đặt trong một thông điệp trả lời nếu như máy
phục vụ DNS hỗ trợ đệ qui. Trong phần header, cũng có 4 trường.
Các trường này mô tả số lần xuất hiện của 4 loại dữ liệu theo sau
phần header.
151
Hình 2.23. Định dạng thông điệp DNS

- Phần câu hỏi (question section) chứa thông tin về truy vấn đang
thực hiện. Phần này gồm (1) trường tên chứa tên đang được truy
vấn, và (2) trường kiểu cho biết kiểu câu hỏi đang được hỏi – ví
dụ : một địa chỉ của một máy tính mạng liên quan đến một tên
(Loại A) hay máy phục vụ mail liên quan đến một tên nào (loại
MX)
- Trong trả lời từ máy phục vụ DNS, phần trả lời (answer section)
chứa RR tương ứng với tên được truy vấn lúc đầu. Mỗi RR có một
kiểu Type (A, NS, CNAME và MX), Value, và TTL. Một trả lời
có thể trả về nhiều RR trong câu trả lời, vì một tên máy tính mạng
có thể có nhiều địa chỉ IP (ví dụ các máy phục vụ web nhân bảng)
- Phần phân quyền (authority section) chứa các RR của các máy
phục vụ thẩm quyền khác.
- Phần bổ sung (additional section) chứa các RR khác giúp câu trả
lời rõ hơn. Ví dụ, trường trả lời trong thông điệp trả lời một truy
vấn MX chứa một RR cung cấp tên máy tính mạng gốc của một
152
máy phục vụ mail. Phần bổ sung chứa RR kiểu A cung cấp địa chỉ
IP của tên máy tính mạng gốc của một máy phục vụ mail.
Để gửi thông điệp truy vấn DNS trực tiếp từ máy tính mạng đến máy
phục vụ DNS dùng trình nslookup sẵn có trên đa số hệ điều hành
Windows và UNIX. Ví dụ, từ máy tính mạng dùng Windows, mở hộp
thoại Command Prompt và kích hoạt chương trình nslookup đơn giản
bằng cách gõ « nslookup ». Sau khi kích hoạt nslookup, gửi câu truy
vấn DNS đến máy phục vụ DNS (gốc, TLD hay thẩm quyền). Sau khi
nhận thông điệp trả lời từ máy phục vụ DNS, nslookup sẽ xuất ra các
RR khi phản hồi (dưới định dạng con người có thể đọc).
Chèn các RR vào trong cơ sở dữ liệu DNS
Giả sử công ty Network Utopia vừa thành lập. Việc đầu tiên là đăng kí
tên miền networkutopia.com tại đại lý tên miền (registrar). Đây là tổ
chức thương mại để xác nhận tên miền là duy nhất, thêm tên miền vào
cơ sở dữ liệu DNS và thu phí các dịch vụ cung cấp cho khách hàng.
Trước năm 1999, một tổ chức duy nhất là Network Solutions độc
quyền trong việc cung cấp tên miền .com, .net, và .org. Hiện nay có
rất nhiều nhà cung cấp tên miền cạnh tranh khách hàng với nhau, và
ICANN (Internet Corporation for Assigned Names and Numbers) ủy
nhiệm cho các đại lý tên miền. Danh sách đại lý tên miền sẵn có tại
trang http://www.internic.net.
Khi đăng kí tên miền networkutopia.com với một đại lý tên miền nào
đó, khách hàng cần cung cấp với đại lý các thông tin như tên và các
địa chỉ IP của các máy phục vụ DNS chính và phụ thẩm quyền. Giả sử
tên vá địa chỉ IP là dns1.networkutopia.com, dns2.networkutopia.com,
212.212.212.1 và 212.212.212.2. Với mỗi máy phục vụ DNS, một đại
lý tên miền cần chắc chắn RR loại NS và A được thêm vào các máy
phục vụ TLD com. Cụ thể, với máy phục vụ thẩm quyền chính cho
networkutopia.com, đại lý tên miền sẽ thêm 2 RR sau vào hệ thống
DNS :
dns 1. networkutopia. com, dns2 . networkutopia. com,
212.212.212.1, and 212 .212 . 212 . 2.
(networkutopia.com, dnsl.networkutopia.com, NS)
(dnsl.networkutopia.com, 212.212.212.1, A)
153
RR kiểu A dành cho máy phục vụ web www.networkutopia.com và

RR kiểu MX cho máy phục vụ mail mail.networkutopia.com được
thêm vào các máy phục vụ DNS thẩm quyền. (Cho đến gần đây, nội
dung của máy phục vụ DNS được cấu hình tĩnh, ví dụ, từ một tập tin
cấu hình được tạo bởi bộ phận quản lý hệ thống. Sau đó, một tùy chọn
UPDATE vừa được thêm vào giao thức DNS cho phép dữ liệu tự
động được thêm hay xóa từ cơ sở dữ liệu thông qua các thông điệp
DNS [RFC 2136] và [RFC 3007] đặc tả chức năng cập nhật DNS tự
động).
Khi tất cả các bước này hoàn tất, mọi nhân viên có thể truy cập trang
web và gửi thư điện tử cho các nhân viên khác trong công ty. Ngoài
ra, giả sử Alice ở Úc muốn xem trang web www.networkutopia.com.
Máy của cô ta đầu tiên gửi truy vấn DNS đến máy phục vụ DNS cục
bộ. Máy phục vụ DNS cục bộ kế tiếp sẽ liên lạc với máy phục vụ TLD
com. (Máy phục vụ DNS cục bộ cũng liên lạc với máy phục vụ DNS
gốc nếu như địa chỉ của máy phục vụ com TLD không lưu lại). Máy
phục vụ TLD này chứa RR kiểu NS và A như liệt kê ở trên, vì đại lý
tên miền chèn các RR này vào tất cả các máy phục vụ TLD com. Máy
phục vụ TLD com gửi phản hồi về cho máy phục vụ DNS cục bộ của
Alice, với câu truy vấn chứa 2 RR. Máy phục vụ DNS cục bộ kế tiếp
gửi một câu lệnh truy vấn đến 212.212.212.1, yêu cầu RR kiểu A
tương ứng với www.networkutopia.com. RR này cung cấp địa chỉ IP
cho máy phục vụ web mong muốn 212.212.71.4, máy phục vụ DNS
cục bộ trả ngược lại về cho máy tính của Alice. Trình duyệt của Alice
có thể khởi tạo kết nối TCP đến máy tính 212.212.71.4 và gửi yêu cầu
HTTP trên đường truyền.
VI. Các ứng dụng P2P

Các ứng dụng được thảo luận trong chương này như Web, thư điện tử
và DNS đều dùng kiến trúc khách – phục vụ dựa vào các máy phục vụ
cơ sở hạ tầng luôn luôn hoạt động. Phần 2.1.1 với kiến trúc khách –
phục vụ rất ít (hoặc không có) dựa vào các máy phục vụ luôn hoạt
động. Thay vào đó, các cặp máy tính mạng kết nối không liên tục, gọi
là máy tính ngang hàng (peer), sẽ truyền thông trực tiếp với nhau. Các
máy tính ngang hàng không thuộc quyền sở hữu của nhà cung cấp
154
dịch vụ mà đó có thể là máy tính để bàn hoặc máy tính xách tay được
điều khiển bởi người dùng.
Trong phần này sẽ khảo sát lần lượt các ứng dụng khác nhau đặc biệt
thích hợp cho các thiết kế P2P. Ứng dụng đầu tiên là phân phối tập tin,
phân phối một tập tin từ nguồn duy nhất đến nhiều máy tính ngang
hàng, cho thấy được tính khả năng qui mô phạm vi của kiến trúc. Ứng
dụng thứ 2 là phân tán cơ sở dữ liệu trên một mạng các máy tính
ngang hàng. Trong ứng dụng này, một khái niệm mới được giới thiệu
là bảng băm phân tán (DHT – Distributed Hash Table). Ví dụ thứ ba
là Skype, một ứng dụng điện thoại P2P qua Internet.
VI.1 Bài toán Phân bố tệp theo lối P2P
Với bài toán phân tán một tập tin lớn từ một máy phục vụ đơn cho
nhiều máy tính mạng (còn gọi là máy ngang hàng). Ví dụ tập tin đó là
phiên bản mới của hệ điều hành Linux, một tập tin phần mềm hệ điều
hành hiện tại hay ứng dụng, một tập tin nhạc MP3, hay một tập tin
phim MPEG. Trong phân tán tập tin khách – phục vụ, máy phục vụ
phải gửi một bản sao của tập tin đến các máy tính mạng – chiếm một
không gian lớn trên máy phục vụ và tiêu thụ một lượng lớn băng
thông máy phục vụ. Trong phân tán tập tin P2P, mỗi máy ngang hàng
có thể phân tán lại bất kì một phần của tập tin mà nó vừa nhận đến bất
kì máy tính ngang hàng nào, do đó sẽ hỗ trợ máy phục vụ trong tiến
trình phân tán. Giao thức phân tán tập tin P2P phổ biến nhất là
BitTorrent. Đầu tiên được phát triển bởi Bram Cohen, hiện tại có
nhiều máy khách BitTorrent độc lập tuân theo giao thức BitTorrent.
Trong phần này, khả năng tự mở rộng phạm vi của các kiến trúc P2P
trong ngữ cảnh phân tán tập tin được xem xét. Các nét đặc trưng và
đặc điểm quan trọng nhất cũng được nhấn mạnh.
Tính khả năng mở rộng của các kiến trúc P2P
So sánh kiến trúc khách – phục vụ với kiến trúc P2P, và mô tả tính tự
mở rộng của P2P, xét một mô hình đơn giản về phân tán một tập tin
cho một tập hợp cố định gồm các máy tính ngang hàng với cả hai loại
kiến trúc. Hình 2.24, máy phục vụ và các máy ngang hàng được kết
nối Internet với các kênh truyền. Kí hiệu tỉ lệ gửi dữ liệu đi của kênh
truyền của máy phục vụ là us, tỉ lệ tải lên của kênh truyền của máy
155
ngang hàng thứ i là ui, và tỉ lệ tải xuống của kênh truyền của máy
ngang hàng thứ i là di. Kích thước của tập tin được phân tán (theo đơn
vị bits) là F và số máy khách ngang hàng muốn chứa bảng sao của tập
tin tổng cộng là N. Thời gian phân tán (distribution time) là thời gian
chuyển bảng sao của tập tin phân tán đến N máy tính ngang hàng.
Theo thời gian phân tán được phân tích bên dưới (với cả hai loại kiến
trúc khách – phục vụ và P2P), giả sử lõi Internet có băng thông dư, mô
tả là tất cả các đường cổ chai đều dùng cho truy cập mạng. Ngoài ra,
giả sử máy phục vụ và các máy khách không tham gia vào bất kì ứng
dụng mạng nào khác, để tất cả băng thông truy cập dùng để tải lên và
tải xuống có thể dùng toàn bộ cho việc phân tán tập tin.
Hình 2.24. Mô tả vấn đề trong phân tán tập tin

Trước hết cần xác định thời gian phân tán cho kiến trúc khách – phục
vụ, kí hiệu là Dcs. Trong kiến trúc khách – phục vụ, không có máy tính
ngang hàng nào hỗ trợ trong phân tán tập tin.
- Máy phục vụ phải chuyển một bảng sao của tập tin cho mỗi máy
tính ngang hàng trong tổng số N máy tính ngang hàng. Do đó, máy
phục vụ phải chuyển NF bit tổng cộng. Vì tỉ lệ gửi đi của máy
phục vụ là us, thời gian để phân tán tập tin phải ít nhất là NF/us.
- Đặt dmin là tỉ lệ tải xuống thấp nhất của máy tính ngang hàng với
dmin = min{d1, d2, …, dN}. Máy tính ngang hàng với tỉ lệ tải xuống
156
thấp nhất không thể đạt được F bit của tập tin trong vòng ít hơn
F/dmin giây. Do đó, thời gian phân tán tối thiểu ít nhất là F/dmin.
Đặt hai kết quả quan sát trên, chúng ta có:
NF F
Dcs  max{ , } (2.0)
us d min
Chặn dưới của thời gian phân tán tối thiểu cho kiến trúc khách – phục
vụ là:
NF F
Dcs = max{ , } (2.1)
us d min
Từ công thức (2.1), giả sử N đủ lớn, thời gian phân tán khách – phục
vụ là NF/us. Do đó, thời gian phân tán tăng tuyến tính theo số máy
khách ngang hàng N. Ví dụ, nếu số máy tính ngang hàng từ một tuần
đến tuần tiếp theo tăng từ một ngàn lên một triệu, thời gian được yêu
cầu để phân tán tập tin đến tất cả các máy tính ngang hàng sẽ tăng
thêm gấp một ngàn.
Phân tích tương tự cho kiến trúc P2P, mỗi máy khách ngang hàng có
thể hỗ trợ máy phục vụ trong phân tán tập tin. Đặc biệt, khi một máy
tính ngang hàng nhận dữ liệu tập tin nào đó, nó có thể dùng khối
lượng truyền dữ liệu đi của riêng mình để phân tán lại dữ liệu đến các
máy tính ngang hàng khác. Tính thời gian phân tán của kiến trúc P2P
phức tạp hơn kiến trúc khách – phục vụ, vì thời gian phân tán phụ
thuộc vào mỗi máy khách ngang hàng phân tán các phần của tập tin
đến các máy khách ngang hàng khác như thế nào. Để tính được thời
gian phân tán này, trước hết chúng ta cần có những quan sát sau:
- Bắt đầu quá trình phân tán, chỉ máy phục vụ có tập tin. Để gửi tập
tin này vào cộng đồng các máy tính ngang hàng, máy phục vụ phải
gửi mỗi bit của tập tin ít nhất một lần vào đường truyền của nó.
Do đó, thời gian phân tán tối thiểu ít nhất là F/us. (Không giống
kiến trúc khách – phục vụ, một bit được gửi một lần từ máy phục
vụ không thể được gửi lại lần nữa, khi các máy tính ngang hàng
phân tán lại bit đó giữa chúng với nhau).
157
- Như với kiến trúc khách – phục vụ, máy tính ngang hàng với tỉ lệ
tải về thấp nhất không thể lấy về tất cả F bit của tập tin ít hơn
F/dmin giây. Do đó thời gian phân tán tối thiểu là ít nhất F/dmin.
- Tổng dung lượng truyền đi của hệ thống bằng tỉ lệ tải lên bằng
tổng của tỉ lệ tải lên của máy phục vụ cộng với tỉ lệ truyền đi của
mỗi máy khách ngang hàng, đó là utotal=us+u1+…+uN. Hệ thống
phải truyền (tải lên) F bit đến mỗi máy tính ngang hang trong tổng
số N máy tính ngang hàng. Do đó, thời gian phân tán tối thiểu
cũng là NF/(us+u1+…+uN)
Thời gian phân tán tối thiểu cho P2P kí hiệu là DP2P:
F F NF
DP 2 P  max{ , , N
} (2.2)
us +  ui
us d min
i =1
Công thức 2.2 cung cấp giá trị chặn dưới cho thời gian phân tán tối
thiểu của kiến trúc P2P. Nếu mỗi máy tính ngang hàng phân tán lại
một bit ngay khi nó nhận được bit đó. Thực tế, các phần của tập tin
được phân tán lại nhiều hơn từng bit riêng lẻ. Do đó, chặn dưới từ
công thức 2.2 như thời gian phân tán tối thiểu:
F F NF
DP 2 P = max{ , , N
} (2.3)
us +  ui
us d min
i =1
Hình 2.25 so sánh thời gian phân tán tối thiểu của các kiến trúc khách
– phục vụ và P2P, giả sử tất cả các máy tính ngang hàng có cùng tỉ lệ
truyền dữ liệu đi u. Trong hình 2.25, chúng ta có tập các giá trị F/u=1
giờ, us=10u, và dmin≥us. Do đó, một máy tính ngang hàng có thể
truyền toàn bộ tập tin trong 1 giờ, tỉ lệ truyền của máy phục vụ là 10
lần tỉ lệ truyền của máy tính ngang hàng, và các tỉ lệ truyền máy tính
ngang hàng đủ lớn để đạt hiệu quả. Trong hình 2.25, xem kiến trúc
khách – phục vụ, thời gian phân tán tăng theo tuyến tính và không có
giá trị chặn khi số máy tính ngang hàng tăng. Tuy nhiên, với kiến trúc
P2P, thời gian phân tán tối thiểu không chỉ luôn ít hơn thời gian phân
tán của kiến trúc khách – phục vụ; mà còn ít hơn 1 giờ cho số máy
tính ngang hàng N bất kì nào. Do đó, các ứng dụng với kiến trúc P2P
158
có thể tự mở rộng kích thước mạng. Khả năng mở rộng kích thước
mạng là một chuỗi các máy tính ngang hàng đang là máy phân tán lại
cũng như sử dụng các bit.
Hình 2.25. Thời gian phân tán cho kiến trúc khách – phục vụ và P2P
BitTorrent
Là một giao thức P2P phổ biến cho sự phân tán tập tin. Tập hợp tất cả
máy tính ngang hàng tham gia vào phân tán một tập tin cụ thể được
gọi là torrent. Các máy tính ngang hàng trong torrent tải về các đoạn
tập tin có kích thước bằng nhau từ các máy tính ngang hàng khác, kích
thước điển hình là 256KB. Khi một máy tính ngang hàng đầu tiên
tham gia vào torrent sẽ không có một đoạn tập tin nào. Theo thời gian
máy tính đó sẽ tích lũy ngày càng nhiều các đoạn tập tin. Trong khi
máy tính tải về các đoạn tập tin thì cũng sẽ truyền các đoạn tập tin đến
các máy tính ngang hàng khác. Khi một máy tính ngang hàng có toàn
bộ tập tin, nó sẽ rời khỏi torrent và sau đó vào lại torrent, hoặc cũng sẽ
ở lại trong torrent ở bất kì thời gian nào cùng với một tập con các
đoạn tập tin nó có.
Vì BitTorrent là một giao thức và là một hệ thống phức tạp. Mỗi
torrent có một nút (node) cơ sở hạ tầng được gọi là tracker. Khi một
159
máy tính ngang hàng tham gia vào một torrent, nó đăng kí với tracker
và thông báo cho tracker theo chu kì khi vẫn còn ở trong torrent.
Tracker lưu trữ dấu vết của các máy tính ngang hàng tham gia vào
torrent. Với một torrent có thể có ít hơn 10 hoặc nhiều hơn 1000 máy
tính ngang hàng tham gia vào ở bất kì thời điểm nào.
Trong hình 2.26, khi một máy tính ngang hàng mới, Alice, tham gia
vào torrent, tracker ngẫu nhiên chọn một tập con các máy tính ngang
hàng (khoảng 50) từ tập các máy tính ngang hàng đang tham gia, và
gửi các địa chỉ IP của 50 máy tính ngang hàng này đến cho Alice. Xử
lý danh sách xác máy tính ngang hàng này, Alice cố gắng thiết lập các
kết nối TCP song song với tất cả các máy tính ngang hàng trong danh
sách này. Gọi các máy tính ngang hàng mà Alice thiết lập các kết nối
TCP thành công là các máy láng giềng (neighboring peers) (trong hình
2.26, máy của Alice chỉ có 3 máy láng giềng. Thông thường thì Alice
có thể có nhiều máy láng giềng hơn). Theo thời gian, vài máy tính
ngang hàng có thể ngưng kết nối và các máy tính ngang hàng khác sẽ
thiết lập kết nối TCP với Alice. Số máy láng giềng sẽ thay đổi theo
thời gian.
Ở bất kì thời điểm đã cho nào, mỗi máy tính ngang hàng sẽ có một tập
con các đoạn tập tin, với các máy tính ngang hàng khác nhau có các
tập con khác nhau. Theo chu kì, Alice sẽ yêu cầu mỗi máy tính láng
giềng (dựa trên kết nối TCP) danh sách các đoạn tập tin mà các máy
tính đó có. Nếu Alice có L láng giềng khác nhau, Alice sẽ có L danh
sách các đoạn tập tin. Với tri thức này, Alice sẽ gửi các yêu cầu (một
lần nữa dựa trên các kết nối TCP) các đoạn tập tin mà Alice chưa có.
Vì vậy ở bất kì thời điểm nào cho trước, Alice sẽ có đoạn các tập tin
và sẽ biết những đoạn tập tin nào láng giềng của Alice có. Với thông
tin này, Alice sẽ có hai quyết định quan trọng để thực hiện. Đầu tiên là
những đoạn tập tin nào Alice yêu cầu trước hết từ láng giềng của
Alice? Thứ hai là Alice sẽ yêu cầu các đoạn tập tin đến láng giềng nào
của cô ấy? Để quyết định yêu cầu đoạn tập tin nào, Alice dùng một kĩ
thuật gọi là Rarest First. Ý tưởng là quyết định từ trong số các đoạn
tập tin mà Alice không có, các đoạn tập tin hiếm nhất trong số các
láng giềng của Alice (các đoạn tập tin có các bản sao được lặp lại ít
nhất trong số các láng giềng của cô ấy) và kế đó yêu cầu các đoạn tập
160
tin hiếm nhất này trước. Theo thái độ này, các đoạn tập tin hiếm nhất
sẽ được phân tán lại nhanh hơn, nhằm cân bằng số bản sao của mỗi
đoạn tập tin trong torrent.
Hình 2.26. Phân tán tập tin với BitTorrent

Quyết định xem những yêu cầu nào mà cô ấy phản hồi, BitTorrent
dùng một thuật toán thương mại thông minh. Ý tưởng cơ bản là Alice
đặt quyền ưu tiên đến láng giềng của mình hiện đang cung cấp dữ liệu
của cô ta với tỉ lệ cao nhất. Đặc biệt, với mỗi láng giềng, Alice liên tục
đo tỉ lệ mà cô ta nhận các bit và xác định 4 máy ngang hàng đang gửi
các bit đến cho cô ta với tỉ lệ cao nhất. Kế đó Alice trao đổi bằng cách
gửi các đoạn tập tin cùng đến bốn máy tính ngang hàng này. Mỗi 10
giây, Alice tính lại tỉ lệ và bổ sung vào tập 4 máy ngang hàng. Trong
BitTorrent Lingo, 4 máy ngang hàng này được gọi là không tắc nghẽn
(unchoked). Quan trọng là 30 giây, cô ấy cũng lấy thêm một máy láng
giềng ngẫu nhiên và gửi cho máy đó các đoạn tập tin. Chúng ta gọi
máy tính được chọn ngẫu nhiên là Bob. Trong BitTorrent Lingo, Bob
một cách lạc quan mà nói là không tắc nghẽn. Vì Alice đang gửi dữ
liệu đến Bob, cô ta có thể trở thành một trong bốn máy tải của Bob,
trong đó Bob bắt đầu gửi dữ liệu đến Alice. Nếu tỉ lệ Bob gửi dữ liệu
đến Alice là đủ cao, Bob kế đó có thể thay phiên trở thành một trong
161
bốn máy tải dữ liệu của Alice. Nói cách khác, cứ 30 giây là Alice chọn
ngẫu nhiên một máy đối tác thương mại mới và bắt đầu giao dịch
thương mại với đối tác đó. Nếu hai máy tính ngang hàng thích hợp với
giao dịch thương mại thì chúng được đặt vào bốn danh sách và tiếp
tục giao dịch thương mại với nhau đến khi một trong các máy ngang
hàng tìm thấy một đối tác tốt hơn. Kết quả là các máy tính ngang hàng
có thể tải dữ liệu lên ở các tỉ lệ tương thích để tìm thấy nhau. Việc
chọn lựa ngẫu nhiên láng giềng cũng cho phép các máy tính ngang
hàng mới lấy các đoạn tập tin, để các máy tính này có thể dữ liệu để
giao dịch. Tất cả các máy ngang hàng láng giềng khác bên cạnh năm
máy ngang hàng này (4 máy ngang hàng đầu và 1 máy thăm dò) được
gọi là tắc nghẽn (choked), các máy này không nhận bất kì đoạn tập tin
từ Alice. BitTorrent có nhiều kĩ thuật không được thảo luận ở phạm vi
sách giáo khoa này, bao gồm các mãnh (các đoạn tập tin nhỏ), đường
ống truyền, chọn lựa ngẫu nhiên, kiểu kết thúc.
VI.2 Kỹ thuật DHT
Một phần quan trọng của nhiều ứng dụng P2P và các ứng dụng phân
tán khác là chỉ mục (một cơ sở dữ liệu đơn giản), hỗ trợ các chức năng
tìm kiếm và cập nhật. Khi cơ sở dữ liệu này được phân tán, các máy
tính ngang hàng có thể thực hiện việc lưu bộ nhớ nội dung và định
tuyến tỉ mỉ các câu truy vấn trong số đó. Vì chỉ mục và tìm kiếm
thông tin là một thành phần quan trọng trong những hệ thống như vậy,
trong phần này sẽ mô tả tổng quan kĩ thuật tìm kiếm và chỉ mục phổ
biến, các bảng băm được phân tán (DHT – Distributed Hash Tables).
Xem xét một cơ sở dữ liệu đơn giản được phân tán trên nhiều máy
ngang hàng (có thể là hàng triệu) hỗ trợ truy vấn và chỉ mục đơn giản.
Thông tin được lưu trữ trong cơ sở dữ liệu bao gồm cặp (khóa, giá trị).
Ví dụ, các khóa có thể là tên (tên của phim, tập bài hát, và phần mềm)
và các giá trị có thể các địa chỉ IP của máy mà phần dữ liệu được lưu
trữ; trong trường hợp này, một ví dụ về cặp khóa – giá trị là (Led
Zeppelin IV, 203.17.123.38). Các máy ngang hàng truy vấn cơ sở dữ
liệu bằng cách cung cấp khóa: Nếu có các cặp (khóa, giá trị) trong cơ
sở dữ liệu thích hợp với giá trị khóa, cơ sở dữ liệu trả về các cặp thích
hợp về cho máy ngang hàng truy vấn. Ví dụ, nếu cơ sở dữ liệu lưu trữ
các số an toàn xã hội và các tên người liên quan, một máy ngang hàng
162
có thể truy vấn một số an toàn xã hội cụ thể, và cơ sở dữ liệu trả về tên
của người có số an toàn xã hội cần truy vấn đó. Các máy tính ngang
hàng cũng có thể chèn các cặp (khóa, giá trị) mới vào trong cơ cở dữ
liệu.
Xây dựng một cơ sở dữ liệu theo kiến trúc khách – phục vụ để lưu tất
cả các cặp (khóa, giá trị) trong một máy phục vụ trung tâm. Cách tiếp
cận tập trung này được dùng trong những hệ thống P2P trước đây như
Napster. Nhưng vấn đề quan trọng thử thách hơn nhưng cũng thú vị
hơn là trong một hệ thống phân tán bao gồm hàng triệu máy ngang
hàng kết nối với nhau mà không có trung tâm thẩm quyền. Trong một
hệ thống P2P, để phân tán các cặp (khóa, giá trị) cho tất cả các máy
ngang hàng, để mỗi máy ngang hàng chỉ có thể chứa một tập con nhỏ
của toàn bộ các cặp (khóa, giá trị). Cách tiếp cận Naïve trong việc xây
dựng một cơ sở dữ liệu P2P như vậy là (1) phân tán ngẫu nhiên các
cặp (khóa, giá trị) cho các máy ngang hàng và (2) mỗi máy ngang
hàng duy trì một danh sách các địa chỉ IP của tất cả các máy ngang
hàng tham gia. Máy ngang hàng truy vấn có thể gửi một truy vấn đến
tất cả các máy ngang hàng, và các máy ngang hàng chứa các cặp
(khóa, giá trị) nếu thấy khớp khóa có thể trả lại các cặp kết quả của
nó. Một tiếp cận như vậy hoàn toàn không thể mở rộng phạm vi, mỗi
máy phải truy vết tất cả các máy ngang hàng khác (có thể là hàng
triệu) và, thậm chí tệ hơn nếu mỗi truy vấn đều phải gửi đến tất cả các
máy ngang hàng.
Để mô tả một tiếp cận với thiết kế một cơ sở dữ liệu P2P. Mỗi máy
ngang hàng được chỉ định một định danh là một số nguyên trong miền
[0, 2n-1] với n là một số cố định. Ghi chú mỗi máy ngang hàng có một
định danh như vậy có thể được mô tả như một số n bit. Mỗi khóa là
một số nguyên thuộc cùng miền. Một người đọc tinh mắt có thể quan
sát được các khóa ví dụ trước đây (số an toàn xã hội và tên nội dung)
không phải là các số nguyên. Để tạo các số nguyên ngoài các khóa
này, cần dùng một hàm băm ánh xạ mỗi khóa (số an toàn xã hội) đến
một số nguyên thuộc miền [0, 2n-1]. Một hàm băm là một hàm có
quan hệ nhiều – một cho hai tập đầu vào khác nhau có thể cùng tập
đầu ra (số nguyên), nhưng khả năng có cùng tập đầu ra là cực kì nhỏ.
Hàm băm giả sử là công khai cho tất cả các máy ngang hàng trong hệ
thống. Khi tham chiếu đến “khóa” có nghĩa là đang tham chiếu đến
163
mã băm của giá trị khóa nguồn. Ví dụ nếu như khóa nguồn là “Led
Zeppelin IV”, khóa sẽ là số nguyên tương ứng với mã băm của “Led
Zeppelin IV”. Mã băm của các khóa được dùng nhiều hơn là bản thân
các khóa, cơ sở dữ liệu phân tán được tham chiếu như một bảng băm
được phân tán (DHT).
Xét vấn đề lưu trữ các cặp (khóa, giá trị) trong DHT. Vấn đề chính là
định nghĩa một luật cho việc chỉ định các khóa cho các máy ngang
hàng. Mỗi máy ngang hàng có một định danh số nguyên và mỗi khóa
cũng là một số nguyên trong cùng miền giá trị, một tiếp cận tự nhiên
là chỉ định mỗi cặp (khóa, giá trị) cho máy ngang hàng có định danh là
gần giống với khóa nhất. Để cài đặt một giao thức như vậy, chúng ta
cần định nghĩa như thế nào là “gần nhất”. Máy gần nhất là máy có
định danh là kề sau gần nhất của giá trị của khóa (immediate
successor of the key). Giả sử n=4 để tất cả các định danh của máy
ngang hàng và khóa trong khoảng [0, 15]. Có 8 máy ngang hàng trong
hệ thống với định danh 1, 3, 4, 5, 8, 10, 12, 15. Muốn lưu trữ cặp
khóa-giá trị (11, Jognny Wu) vào một trong 8 máy ngang hàng. Máy
có định danh 12 là máy kề sau gần nhất của khóa giá trị 11, do đó cặp
(11, Johnny Wu) lưu trên máy 12. Nếu như khóa chính xác bằng một
trong các định danh của máy ngang hàng, lưu trữ cặp (khóa – giá trị)
trên máy tính đó, và nếu khóa lớn hơn tất cả các định danh máy tính
thì chia dư giá trị đó cho 2n, sau đó lưu trữ cặp (khóa – giá trị) trong
máy tính có định danh nhỏ nhất.
Giả sử một máy ngang hàng, Alice, muốn chèn một cặp (khóa, giá trị)
vào DHT. Theo như khái niệm, Alice đầu tiên xác định máy tính có
định danh kề sau gần với giá trị khóa nhất, kế đó cô ấy gửi một thông
điệp cho máy tính ngang hàng đó, hướng dẫn máy tính đó lưu trữ cặp
(khóa, giá trị). Alice xác định máy tính kề sau gần với khóa bằng
cách: Alice truy vết tất cả máy tính ngang hàng trong hệ thống (các ID
của máy tính ngang hàng và các địa chỉ IP liên quan), Alice một cách
cục bộ có thể xác định máy tính gần nhất. Với tiếp cận như vậy yêu
cầu mỗi máy tính lưu vết tất cả các máy ngang hàng khách trong DHT
– điều này hoàn toàn không khả thi cho một hệ thống qui mô lớn với
hàng triệu máy ngang hàng như vậy.
DHT tròn (Circular DHT)
164
Để giải quyết vấn đề chu trình, xếp các máy ngang hàng vào trong
một hình tròn. Theo cách sắp xếp này, mỗi máy ngang hàng chỉ lưu
vết máy kề sau nó (thực hiện phép chia dư cho 2n). Ví dụ với một hình
tròn như hình 2.27 (a). Trong ví dụ, n là 4 và có cùng 8 máy ngang
hàng từ ví dụ trước. Mỗi máy ngang hàng chỉ nhận biết được máy kề
sau nó, ví dụ máy 5 biết được địa chỉ IP và định danh của máy 8
nhưng không cần thiết biết bất kì gì về những máy khác cũng trong
DHT.
Hình 2.27. (a) DHT hình tròn. Máy tính 3 muốn xác định máy tính lưu khóa
11. (b) Một DHT hình tròn với các biểu tượng mũi tên có hướng.
Sự sắp xếp vòng tròn này của các máy tính ngang hàng là một trường
hợp đặc biệt của mạng overlay. Trong một mạng overlay, các máy
tính tạo nên một mạng logic trừu tượng hình thành trên mạng vật lý
(mạng underlay) chứa các kết nối vật lý, bộ định tuyến, và máy tính
ngang hàng. Các kết nối trong một mạng overlay không phải là kết nối
vật lý, chỉ là các kết nối ảo giữa các cặp máy ngang hàng. Trong mạng
overlay ở hình 2.27 (a), có 8 máy ngang hàng và 8 liên kết overlay;
trong mạng overlay ở hình 2.27 (b) có 8 máy tính ngang hàng và 16
liên kết overlay. Một liên kết overlay đơn điển hình dùng nhiều liên
kết vật lý và nhiều bộ định tuyến vật lý thuộc mạng underlay.
Dùng overlay tròn như trong hình 2.27(a), giả sử máy 3 muốn xác
định máy nào trong DHT chịu trách nhiệm quản lý khóa 11 (ví dụ cần
165
chèn hay truy vấn cặp khóa-giá trị). Dùng overlay tròn, máy nguồn
(máy 3) tạo một thông điệp hỏi: “Ai chịu trách nhiệm cho khóa 11?”
và gửi thông điệp này đến máy kề sau nó là máy 4. Bất cứ khi nào một
máy nhận một thông điệp như vậy (có thể biết định danh của máy kề
sau nó) nó có thể xách định nó có chịu trách nhiệm (và là máy gần
nhất) cho khóa trong câu hỏi đó không. Nếu một máy ngang hàng
không chịu trách nhiệm về khóa đó, đơn giản nó sẽ gửi thông điệp đến
cho máy kề sau nó. Do đó, ví dụ, khi máy 4 nhận thông điệp yêu cầu
khóa 11, nó xác định rằng nó không chịu trách nhiệm về khóa đó (vì
máy kề sau nó là máy gần khóa nhất), nên nó chỉ đưa thông điệp đến
máy kề sau nó là máy 5. Tiến trình này tiếp tục cho đến khi thông điệp
đến máy 12 và máy 12 xác định nó là máy tính kề sau nhất của khóa
11. Tại thời điểm này, máy 12 có thể gửi thông điệp ngược lại cho
máy nguồn (máy 3) ra dấu hiệu nó là máy chịu trách nhiệm về khóa
11.
DHT tròn cung cấp một giải pháp tốt cho việc giảm khối lượng thông
tin overlay mà mỗi máy tính phải quản lý. Đặc biệt là mỗi máy chỉ
nhận biết hai máy ngang hàng khác, máy kề sau nó nhất và máy kề
trước nó nhất. (Mặc định, máy ngang hàng nhận biết được máy kề
trước nó, vì máy kề trước có thể gửi thông điệp cho nó). Mặc dù mỗi
máy ngang hàng chỉ nhận biết được hai máy láng giềng của nó, để tìm
nút chịu trách nhiệm cho khóa (trong trường hợp xấu nhất), tất cả N
nút trong DHT sẽ chuyển tiếp thông điệp quanh vòng tròn; trung bình
N/2 thông điệp được gửi.
Do đó, trong thiết kế một DHT, có sự thỏa thuận giữa số máy láng
giềng mà một máy phải truy vết và số thông điệp mà DHT cần để gửi
giải quyết một câu truy vấn đơn. Một mặt, nếu mỗi máy ngang hàng
truy vết tất cả các máy ngang hàng khác (overlay dạng lưới), thì chỉ
một thông điệp được gửi cho một câu truy vấn, nhưng mỗi máy ngang
hàng phải lưu vết N máy ngang hàng khác. Mặt khác, với DHT tròn,
mỗi máy ngang hàng chỉ nhận biết hai máy ngang hàng, nhưng N/2
thông điệp được gửi trung bình cho mỗi câu truy vấn. Thiết kế DHT
có thể được chỉnh sửa để số máy láng giềng của một máy cũng như số
thông điệp của một truy vấn được giữ ở con số có thể chấp nhận được.
Mỗi lần thiết kế lại như thế phải dùng đến mạng overlay tròn làm nền,
và phải thêm “các biểu tượng mũi tên có hướng” để mỗi máy không
166
chỉ truy vết máy kề sau nó nhất, mà còn truy vết đến tập nhỏ các máy
tính có biểu tượng mũi tên trỏ đến. Ví dụ về một DHT tròn như vậy
với vài biểu tượng như trong hình 2.27(b). Các biểu tượng mũi tên có
hướng được dùng để định tuyến nhanh các thông điệp truy vấn. Đặc
biệt, khi một máy nhận một thông điệp đang truy vấn một khóa, nó sẽ
chuyển tiếp thông điệp đến máy láng giềng (máy láng giền kề sau
hoặc một trong những láng giền có biểu tượng mũi tên trỏ đến) gần
với khóa nhất. Do đó, hình 2.27(b), khi máy 4 nhận thông điệp yêu
cầu khóa 11, nó xác định máy gần nhất với khóa (trong số các láng
giềng của nó) là máy láng giềng 10 có mũi tên trỏ đến và kế đó
chuyển tiếp thông điệp trực tiếp đến máy 10. Rõ ràng các biểu tượng
mụi tên có thể giảm đi số thông điệp được dùng để xử lý một câu truy
vấn.
Câu hỏi tiếp theo là “Có bao nhiêu máy láng giềng có biểu tượng mà
mỗi máy tính ngang hàng nên có?”, và “những máy tính ngang hàng
nào nên có các máy láng giềng có biểu tượng này?” Câu hỏi này vừa
nhận sự chú ý quan trọng trong cộng đồng nghiên cứu. DHT có thể
được thiết kế để cả hai số láng giềng của mỗi máy cũng như số thông
điệp cho mỗi truy vấn là O(logN) với N là số máy ngang hàng. Các
thiết kế như vậy đang tranh cãi làm sao để thỏa hiệp được giữa các
giải pháp dùng các đồ hình overlay lưới và tròn.
Peer Churn
Trong các hệ thống P2P, một máy có thể kết nối hoặc ngưng kết nối
mà không cần báo trước. Do đó, khi thiết kế một DHT, chúng ta cũng
phải quan tâm về việc bảo trì mạng overlay DHT. Để có được bức
tranh toàn cục hiểu được vấn đề này hoàn thành như thế nào, chúng ta
cần xem xét lại DHT dạng tròn trong hình 2.27(a). Để kiểm soát được
peer churn, mỗi máy cần truy vết (có thể qua địa chỉ IP) máy kề sau
thứ nhất và thứ hai; ví dụ, máy 4 truy vết máy 5 và 8. Mỗi máy cũng
có thể xác nhận theo chu kì rằng hai máy kề sau còn hoạt động (ví dụ,
bằng cách gửi các thông điệp ping theo chu kì đến chúng và yêu cầu
phản hồi). Cũng xét xem một DHT được bảo trì như thế nào khi có
một máy ngang hàng đột ngột rời khỏi mạng. Ví dụ, giả sử máy 5
trong hình 2.27 (a) đột ngột ngừng kết nối. Trong trường hợp này, hai
máy ngang hàng (4 và 3) đứng sau máy 5 biết máy 5 rời khỏi, vì máy
167
5 không còn phản hồi các thông điệp ping nữa. Máy 4 và 3 do đó cần
cập nhật lại thông tin trạng thái các máy kề trước nó. Quá trình cập
nhật lại thông tin trạng thái của máy 4 như sau:
1 – Máy 4 thay thế máy kề trước đầu tiên của nó (máy 5) với máy
kề sau thứ 2 của nó (máy 8)
2 – Máy 4 kế đó hỏi máy kề sau đầu tiên mới (máy 8) về định
danh và địa chỉ IP của máy kề sau nhất của máy 8 (máy 10). Máy
4 ghi nhận máy 10 là máy kề sau thứ 2 của nó.
Xét các vấn đề xảy ra khi một máy tính ngang hàng tham gia vào
DHT. Giả sử một máy có định danh 13 tham gia vào DHT, và ở thời
điểm tham gia vào DHT máy 13 chỉ biết sự tồn tại của máy 1 trong
DHT. Máy 13 đầu tiên gửi 1 thông điệp đến máy 1 và hỏi “máy kề
trước và kề sau của máy 13 là máy nào?”. Thông điệp này sẽ chuyển
tiếp trong DHT đến khi nó gặp máy 12 là máy nhận ra rằng nó sẽ
đứng kề trước máy 13 và máy kề sau hiện tại của máy 12 là máy 15 sẽ
là máy kề sau của máy 13. Kế đó, máy 12 gửi thông tin máy kề trước
và máy kề sau cho máy 13. Máy 13 hiện giờ có thể tham gia vào DHT
bằng cách ghi nhận máy 15 là máy kề sau của nó và bằng cách thông
báo cho máy 12 rằng máy 12 nên đổi máy kề sau nhất của máy 12
thành máy 13.
Các DHT vừa được dùng rộng rãi trong thực tế. Ví dụ, BitTorrent
dùng Kademlia DHT để tạo một máy truy vết phân tán. Trong
BitTorrent, khóa là định danh torrent và giá trị là các địa chỉ IP của tất
cả các máy ngang hàng hiện tại đang tham gia vào torrent. Theo trạng
thái này, bằng cách truy vấn DHT với định danh torrent, một máy
BitTorrent mới đến có thể xác định máy chịu trách nhiệm về định
danh của mình. Sau khi tìm thấy máy tính chịu trách nhiệm, máy tính
vừa đến có thể gửi truy vấn yêu cầu về danh sách các máy tính ngang
hàng khác trong torrent. Các DHT cũng dùng cho hệ thống chia sẻ tập
tin eMule cho việc định vị các nội dung trên các máy tính ngang hàng.
VI.3 Điển cứu: Skype
Skype là một ứng dụng P2P phổ biến, khoảng 7 đến 8 triệu người
thường kết nối skype ở bất kì thời gian nào. Ngoài việc cung cấp dịch
vụ điện thoại qua mạng Internet máy tính – máy tính, Skype hỗ trợ
168
dịch vụ điện thoại qua mạng máy tính – điện thoại, dịch vụ điện thoại
– máy tính, và dịch vụ hội thảo truyền dữ liệu phim máy tính – máy
tính. Được thành lập từ các cá nhân cũng là người đã tạo ra FastTrack
và Kazaa, Skype được mua bởi eBay năm 2005 với giá 2.6 tỉ đô la.
Skype dùng các kỹ thuật P2P theo nhiều cách sáng tạo mới khác nhau,
thể hiện việc dùng P2P được dùng trong các ứng dụng phân tán nội
dung và chia sẻ tập tin. Như với các thông điệp gửi nhanh, điện thoại
Internet máy tính – máy tính là P2P, trung tâm của ứng dụng là các
cặp người dùng (máy tính ngang hàng) truyền thông với nhau theo
thời gian thực. Nhưng Skype cũng dùng các kỹ thuật P2P cho 2 chức
năng quan trọng khác, cho vị trí người dùng và cho truyền thông
NAT.
Không chỉ các giao thức của Skype là độc quyền mà tất cả các dữ liệu
truyền thông dạng gói (gói tiếng nói và gói điều khiển) đều được mã
hóa. Tuy nhiên, từ trang web Skype và một số nghiên cứu đo đạc, các
nhà nghiên cứu khoa học hiểu được cách Skype làm việc như thế nào.
Như với FastTrack, các nút trong Skype được tổ chức thành một mạng
overlay có phân cấp, với mỗi máy tính ngang hàng được phân loại như
là siêu máy ngang hàng (super peer) hay máy ngang hàng thường
(ordinary peer). Skype bao gồm một chỉ mục ánh xạ các tên người
dùng Skype đến các địa chỉ IP hiện tại (và số hiệu cổng). Chỉ mục này
được phân tán trên các siêu máy tính. Khi Alice muốn gọi cho Bob,
máy khách Skype tìm chỉ mục được phân tán để xác định xem địa chỉ
IP hiện tại của Bob. Vì giao thức Skype là độc quyền, nên chưa rõ là
các ánh xạ chỉ mục được tổ chức trên các siêu máy tính ngang hàng
như thế nào, mặc dù vài dạng tổ chức DHT rất có thể dùng.
Các kỹ thuật P2P cũng được dùng trong trung chuyển Skype (Skype
relays), có ích cho việc thiết lập cuộc gọi giữa các máy tính mạng
trong mạng gia đình (home network). Nhiều cấu hình mạng gia đình
cung cấp truy cập đến Internet thông qua bộ định tuyến (điển hình là
bộ định tuyến không dây). Các bộ định tuyến này thực sự còn bao
gồm NAT (Network Address Translator). NAT có thể ngăn chặn một
máy tính từ bên ngoài mạng gia đình thiết lập kết nối đến một máy
tính bên trong mạng gia đình. Nếu cả hai người gọi dùng Skype có cấu
hình NAT, thì có một vấn đề - cả hai đều không thể nhận một cuộc gọi
169
bắt đầu từ một máy tính khác, làm cuộc gọi dường như không thể thực
hiện. Cách dùng các siêu máy tính ngang hàng và trung chuyển giải
quyết được vấn đề này khá tốt.
Giả sử Alice đăng nhập, cô ấy được chỉ định một siêu máy tính không
dùng NAT. Alice có thể khởi động một phiên đến siêu máy tính ngang
hàng của cô ta bởi vì NAT của cô ta chỉ không cho phép các phiên
được khởi động từ bên ngoài mạng gia đình của Alice. Điều này cho
phép Alice và siêu máy tính của cô ấy trao đổi các thông điệp điều
khiển trên phiên truyền này. Việc tương tự xảy ra cho Bob khi Bob
đăng nhập. Hiện tại, khi Alice muốn gọi cho Bob, cô ấy thông báo cho
siêu máy tính của cô ấy, cũng là máy sẽ tiếp tục thông báo cho siêu
máy tính của Bob biết, và siêu máy tính của Bob đến lượt thông báo
cho Bob cuộc gọi đang đến của Alice. Nếu Bob chấp nhận cuộc gọi,
hai siêu máy tính chọn siêu máy tính thứ ba không có cấu hình NAT –
là nút trung chuyển – công việc của nút trung chuyển này sẽ là chuyển
tiếp dữ liệu giữa Alice và Bob. Các siêu máy tính của Alice và Bob
hướng dẫn cho Alice và Bob cách khởi tạo phiên truyền với cách dùng
chuyển tiếp (relay).
Alice gửi các gói dữ liệu tiếng nói đến nút trung chuyển trên kết nối
Alice – nút trung chuyển (được khởi tạo bởi Alice), và nút trung
chuyển kế đó sẽ chuyển tiếp các gói tin này qua kết nối nút trung
chuyển – Bob (được khởi tạo bởi Bob); các gói từ Bob đến Alice cũng
đi qua trên cùng hai kết nối này theo hướng ngược lại. Như vậy Bob
và Alice đã có kết nối điểm – điểm theo yêu cầu thậm chí không bên
nào có thể chấp nhận phiên truyền xuất phát từ bên ngoài mạng LAN
của nó. Việc dùng các nút trung chuyển này minh họa các thiết kế hệ
thống P2P ngày càng tinh tế, ở đó các máy ngang hàng cung cấp các
dịch vụ lõi hệ thống cho các máy tính ngang hàng khác (dịch vụ index
và trung chuyển) trong khi cùng thời điểm bản thân họ dùng dịch vụ
người dùng cuối (ví dụ như tải tập tin, điện thoại Internet dùng IP)
đang được cung cấp bởi hệ thống P2P.
Skype vừa là một ứng dụng Internet thành công, có hàng chục triệu
người dùng. Việc chấp nhận dùng Skype nhanh và rộng rãi, cũng như
chia sẻ tập tin P2P, Web, và gửi tin nhắn nhanh trước đó, đều có thiết
kế mang kiến trúc tổng quan của Internet, thiết kế có thể phát triển
170
trên 30 năm tới nữa. Các dịch vụ mạng hỗ trợ cho các ứng dụng
Internet – như truyền tải gói phi kết nối (UDP), truyền tải gói đáng tin
cậy hướng kết nối (TCP), giao diện socket, đánh địa chỉ, và phân giải
tên miền (DNS), và nhiều dịch vụ khác – vừa được chứng minh là đủ
cho hàng ngàn ứng dụng được phát triển. Vì các ứng dụng này tất cả
vừa được phân lớp trên đỉnh của 4 tầng thấp của chồng giao thức
Internet, chúng bao gồm việc phát triển hệ thống khách – phục vụ
cũng như phần mềm P2P được dùng ở các hệ cuối. Điều này cho phép
các ứng dụng này được triển khai và chấp nhận nhanh chóng.
VII. Lập trình Socket với TCP

Trong phần này các chương trình ứng dụng được viết dùng TCP, phần
tiếp theo sẽ dùng UDP.
Nhắc lại trong phần 2.1 rằng có nhiều ứng dụng mạng bao gồm hai
chương trình là chương trình khách và chương trình phục vụ, ở bên
trong hai hệ cuối khác nhau. Khi hai chương trình này được kích hoạt,
một tiến trình khách và một tiến trình phục vụ được tạo và các tiến
trình này truyền thông với nhau bằng cách đọc và viết đến các socket.
Khi tạo một ứng dụng mạng, công việc chính của người viết chương
trình là viết mã cho các chương trình khách và chủ.
Có 2 loại chương trình mạng. Một loại là cách cài đặt một chuẩn giao
thức được định nghĩa trong một RFC. Như cài đặt này, chương trình
khách và chủ phải thực hiện theo các luật được soạn ra trong RFC. Ví
dụ, chương trình khách có thể là một cài đặt bên phía khách của giao
thức FTP, như được mô tả trong phần 2.3 và được định nghĩa hoàn
toàn trong RFC 959; tương tự, chương trình phục vụ có thể là một cài
đặt phần máy phục vụ của giao thức FTP chủ, cũng được định nghĩa
tuyệt đối trong RFC 959. Nếu lập trình viên viết chương trình khách
và một lập trình viên khác viết chương trình phục vụ, cả hai đều cẩn
thận tuân theo các luật của RFC, thì 2 chương trình sẽ có thể phối hợp
hoạt động. Thực ra, nhiều ứng dụng mạng ngày nay cải tiến truyền
thông giữa chương trình khách và chủ vừa được viết bởi các lập trình
viên độc lập – ví dụ, một trình duyệt Firefox truyền thông với máy
phục vụ Apache Web, hoặc một FTP khách trên một PC tải một tập
tin lên máy phục vụ FTP Linux. Khi một chương trình khách hay chủ
171
cài đặt một giao thức được định nghĩa trong RFC, nó nên dùng số hiệu
cổng liên quan đến giao thức. (Các số hiệu cổng được mô tả tóm tắt
trong phần 2.1. Chúng được mô tả chi tiết hơn trong chương 3).
Loại ứng dụng mạng khác là ứng dụng mạng độc quyền. Trong trường
hợp này, giao thức tầng Ứng dụng được dùng bởi chương trình khách
và chủ không tuân theo bất kì RFC nào. Một lập trình viên (hoặc một
đội ngũ phát triển phần mềm) viết cả hai chương trình khách và chủ.
Nhưng vì mã chương trình không cài đặt một giao thức miền công,
các lập trình viên độc lập khác sẽ không thể phát triển mã để truyền
thông với ứng dụng. Khi phát triển một ứng dụng độc quyền, lập trình
viên phải cẩn thận không dùng một trong các số hiệu chung được định
nghĩa trong RFC.
Trong phần này và phần tiếp theo, chúng ta kiểm tra các vấn đề khóa
trong việc phát triển một ứng dụng khách – phục vụ độc quyền. Trong
giai đoạn phát triển, một trong các quyết định mà lập trình viên phải
làm là ứng dụng nào chạy trên TCP hay UDP. Nhắc lại TCP là hướng
kết nối và cung cấp một kênh chuỗi byte đáng tin cậy thông qua đó
các luồng dữ liệu sẽ di chuyển giữa hai hệ thống đầu cuối. UDP là phi
kết nối và gửi các gói dữ liệu từ hệ cuối này đến hệ cuối khác, mà
không có bất kì đảm bảo nào trong phân phối.
Trong phần này, một hệ thống khách đơn giản chạy trên TCP sẽ được
giới thiệu. Phần tiếp theo, một ứng dụng khách đơn giản chạy trên
UDP sẽ được giới thiệu. Cả hai ứng dụng TCP và UDP đều dùng Java.
Cũng có thể viết code dùng C hay C++ hoặc ngôn ngữ khác.
2.7.1. Lập trình socket dùng TCP
Nhắc lại phần 2.1 các tiến trình chạy trên các máy tính khác nhau và
truyền thông với nhau bằng cách gửi thông điệp vào các socket. Mỗi
tiến trình xem như là một ngôi nhà và socket của tiến trình giống như
cánh cửa chính của ngôi nhà. Như trong hình 2.28. socket là cánh cửa
giữa tiến trình ứng dụng và TCP. Người viết ứng dụng điều khiển mọi
thứ phía socket client ở tầng Ứng dụng; tuy nhiên, chỉ có thể điều
khiển một ít ở tần truyền tải (lập trình viên ứng dụng có thể sửa đổi
các thông số TCP, như kích thước kích thước tối đa của vùng đệm và
kích thước tối đa của phân đoạn)
172
Hình 2.28. Các tiến trình truyền thông với nhau qua các socket TCP
Về sự tương tác giữa chương trình khách và chủ. Máy khách có công
việc khởi tạo liên lạc với máy phục vụ. Để máy phục vụ có thể phản
hồi với liên lạc ban đầu của máy khách thì máy phục vụ phải luôn sẵn
sàng. Việc này có 2 nghĩa: thứ 1 là chương trình phục vụ không thể
“bất động” (“dormant”) vì nó cần phải chạy một tiến trình trước khi
máy khách cố gắng khởi tạo liên lạc, thứ 2 chương trình phục vụ phải
có một loại cửa chính nào đó – chính xác hơn là một socket – socket
sẽ nhận các liên lạc từ tiến trình khách đang chạy trên một máy tính
mạng bất kì nào. Dùng hình ảnh nhà/cửa chính tương ứng với tiến
trình/socket, thỉnh thoảng hành động liên lạc ban đầu của máy khách
được xem như là hành động “gõ cửa” một ngôi nhà.
Với tiến trình phục vụ đang chạy, tiến trình khách có thể khởi tạo kết
nối TCP đến máy phục vụ. Việc này được thực hiện trên chương trình
khách bằng cách tạo socket. Khi máy khách tạo socket của nó, nó sẽ
đặc tả địa chỉ của tiến trình phục vụ, cũng chính là địa chỉ IP của máy
phục vụ và số hiệu cổng của tiến trình phục vụ. Khi socket vừa được
tạo trên chương trình khách, TCP trên máy khách bắt đầu thực hiện
bắt tay ba lần và thiết lập một kết nối TCP với máy phục vụ. Bắt tay
ba lần xảy ra ở tầng Vận chuyển, hoàn toàn trong suốt với chương
trình khách và chủ.
Trong quá trình bắt tay ba lần, tiến trình khách “gõ cửa” của ngôi nhà
tiến trình phục vụ. Khi máy phục vụ “nghe” tiếng gõ cửa, nó tạo một
cánh cửa mới – chính xác hơn là một socket mới – dành riêng cho
173
máy khách gõ cửa đó. Trong ví dụ bên dưới, cánh cửa này là đối
tượng ServerSocket mà chúng ta gọi là welcomeSocket. Khi máy
khách gõ cửa, chương trình kích hoạt hành động chấp nhận qua
phương thức accept() của welcomeSocket, tạo ra một cửa mới cho
máy khách. Cuối giai đoạn bắt tay, một kết nối TCP tồn tại giữa
socket của máy khách và socket mới của máy phục vụ. Do đó chúng
tôi tham chiếu đến socket mới, độc quyền như socket kết nối của máy
phục vụ.
Từ viễn cảnh của ứng dụng, kết nối TCP là một đường ống ảo trực
tiếp giữa socket của máy khách và socket kết nối của máy phục vụ.
Tiến trình khách có thể gửi các byte bất kì vào trong socket của nó, và
TCP phải đảm bảo rằng tiến trình phục vụ sẽ nhận (thông qua socket
kết nối) mỗi byte theo đúng thứ tự được gửi. Do đó TCP cung cấp một
dịch vụ chuỗi byte đáng tin cậy giữa tiến trình khách và chủ. Ngoài ra,
vì người ta có thể đi vào và đi ra cùng một cánh cửa, nên tiến trình
khách không chỉ gửi đến mà còn nhận các byte từ socket của nó;
tương tự, tiến trình phục vụ không chỉ nhận mà còn gửi các byte qua
socket kết nối. Việc này được minh họa trong hình 2.29. Vì các socket
đóng vai trò trung tâm trong các ứng dụng khách/chủ, việc phát triển
ứng dụng khách/chủ cũng được xem như lập trình socket.
Chuỗi (stream) là một dãy tuần tự các kí tự đi vào hoặc ra từ một tiến
trình. Chuỗi gồm có chuỗi vào (input stream) và chuỗi ra (output
stream) của một tiến trình. Nếu chuỗi là một chuỗi vào, nó được gán
đến nguồn vào của tiến trình, như thiết bị nhập chuẩn (bàn phím) hay
socket mà dữ liệu từ Internet sẽ đi vào. Nếu chuỗi là một chuỗi ra thì
nó sẽ được dán vào tài nguyên ra của tiến trình, như thiết bị đầu ra
chuẩn (màn hình) hay socket mà luồng dữ liệu từ đó sẽ đi vào Internet.
174
Hình 2.29. Socket khách, socket “welcoming”, và socket kết nối
2.7.2 Ví dụ về ứng dụng khách chủ dùng ngôn ngữ lập trình Java
Ứng dụng khách – phục vụ đơn giản mô tả chương trình socket cho cả
hai giao thức TCP và UDP.
1. Máy khách đọc một dòng từ thiết bị nhập chuẩn (bàn phím)
và gửi dòng kí tự ra khỏi socket của nó đến máy phục vụ
2. Máy phục vụ đọc dòng kí tự nhận về từ socket kết nối
3. Máy phục vụ chuyển toàn bộ dòng kí tự sang định dạng chữ
cái hoa
4. Máy phục vụ gửi dòng được bổ sung ra khỏi socket kết nối
của nó đến máy khách
5. Máy khách đọc dòng được bổ sung từ socket của nó và in
dòng đó ra thiết bị xuất chuẩn của nó (màn hình).
Hình 2.30 mô tả hành động chính liên quan đến socket của máy khách
và máy phục vụ.
175
Cặp chương trình khách – phục vụ của một ứng dụng được cài đặt
dùng TCP. Chương trình khách được đặt tên là TCPClient.java và
chương trình phục vụ được đặt tên là TCPServer.java.
Hình 2.30. Ứng dụng khách – phục vụ, dùng dịch vụ tầng vận tải hướng kết nối
Khi hai chương trình được biên dịch trên máy tính mạng, chương trình
phục vụ đầu tiên được kích hoạt ở máy phục vụ, tạo một tiến trình
phục vụ trên máy phục vụ. Như được bàn ở trên, tiến trình phục vụ
đợi tiến trình khách liên lạc.
Trong ví dụ khi chương trình khách được kích hoạt, một tiến trình
được tạo ở máy khách, và tiến trình này liên lạc với máy phục vụ và
thiết lập một kết nối TCP. Người dùng trên máy khách kế đó có thể
dùng ứng dụng để gửi một dòng và nhận một dòng chữ in hoa.
176
Chương trình TCPClient.java chứa phần mã chương trình phía máy

khách của ứng dụng:
import j ava. io. * ;
import j ava. net. *;
class TCPClient {
public static void main(String argv[]) throws Exception
{
String sentence;
String modifiedSentence;
BufferedReader inFromUser = new BufferedReader( new
InputStreamReader(System-in));
Socket clientSocket = new Socket("hostname", 6789);
DataOutputStream outToServer = new
DataOutputStream(clientSocket.getOutputStream());
BufferedReader inFromServer = new BufferedReader(new
InputStreamReader(clientSocket.getlnputstream()));
sentence = inFromUser.readLine();
outToServer.writeBytes(sentence + '\n');
modifiedSentence = inFromServer.readLine();
System.out.println("FROM SERVER: " + modifiedSentence);
clientSocket.close();
}
}
Chương trình TCPClient tạo ba chuỗi và một socket, như trong hình
2.31. Socket có tên là clientSocket. Chuỗi inFromUser là một chuỗi
đầu vào chương trình; nó được dán vào thiết bị đầu vào chuẩn (bàn
phím). Khi người dùng gõ các kí tự trên bàn phím, các kí tự sẽ đi theo
luồng vào chuỗi inFromUser. Chuỗi inFromServer là một chuỗi đầu
vào khác vào chương trình; nó được dán vào socket. Các kí tự vào
mạng theo luồng vào chuỗi inFromServer. Cuối cùng, chuỗi
outToServer là một chuỗi đầu ra từ chương trình; cũng được dán vào
177
socket. Các kí tự mà máy khách gửi vào mạng vào trong chuỗi
outToServer.
Hình 2.31. TCPclient có 3 chuỗi kí tự lưu chuyển

java.io và java.net là các gói Java. Gói java.io chứa các lớp hỗ trợ
nhập xuất chuỗi. Đặc biệt, gói java.io chứa các lớp BufferedReader và
DataOutputStream là các lớp chương trình dùng để tạo ra ba chuỗi
được mô tả phần trên. Gói java.net cung cấp các lớp hỗ trợ mạng. Đặc
biệt nó chứa các lớp Socket và ServerSocket. Đối tượng clientSocket
của chương trình này được dẫn xuất từ lớp Socket.
class TCPClient {
public static void main(String argv[]) throws Exception
{…. }
}
178
Dòng thứ 3 là bắt đầu một khối định nghĩa lớp. Từ khóa class bắt đầu
định nghĩa lớp cho lớp có tên TCPClient. Một lớp chứa các biến và
các phương thức. Các biến và các phương thức của lớp được đóng
ngoặc nhọn cho biết bắt đầu và kết thúc khối định nghĩa lớp. Lớp
TCPClient không có các biến kiểu lớp và có duy nhất một phương
thức main(). Các phương thức tương tự với các hàm hay thủ tục trong
ngôn ngữ C; phương thức main() trong ngôn ngữ Java tương tự hàm
main() trong ngôn ngữ C và C++. Khi trình biên dịch Java kích hoạt
ứng dụng, sẽ bắt đầu gọi phương thức main(). Phương thức main() kế
đó gọi tất cả các phương thức khác yêu cầu chạy ứng dụng. Với việc
giới thiệu với lập trình socket bằng ngôn ngữ Java này, bỏ qua các từ
khóa public, static, void, main và throws Exceptions.
String sentence;
String modifiedSentence;
Hai dòng trên khai báo các đối tượng kiểu String. Đối tượng sentence
có kiểu string là chuỗi có nội dung nhập từ người dùng và được gửi
đến máy phục vụ. Đối tượng modifiedSentence kiểu string nhận từ
server và gửi đến thiết bị xuất chuẩn.
BufferedReader inFromUser = new BufferedReader(
new InputStreamReader(System.in));
Dòng trên tạo ra đối tượng chuỗi inFromUser loại BufferedReader.
Chuỗi đầu vào được khởi động với System.in và dán chuỗi vào thiết bị
nhập chuẩn. Câu lệnh cho phép máy khách đọc văn bản từ bàn phím
của nó
Socket clientSocket = new Socket("hostname", 6789);
Dòng trên tạo đối tượng clientSocket có kiểu Socket. Nó cũng khởi
tạo kết nối TCP giữa máy khách và máy phục vụ. Chuỗi “hostname”
phải được thay thế bởi tên máy của máy phục vụ (ví dụ:
“apple.poly.edu”). Trước khi kết nối TCP thực sự được khởi tạo, máy
khách thực hiện việc tìm địa chỉ IP từ tên máy bằng cách dùng dịch vụ
DNS. Con số 6789 là số hiệu cổng. Có thể dùng một con số khác,
nhưng phải chắc chắn là phải giống con số hiệu cổng của tiến trình
179
phục vụ. Như đã trình bày trước đây, địa chỉ IP của máy cùng với số
hiệu cổng của ứng dụng định danh được tiến trình phục vụ.
DataOutputStream outToServer =
new DataOutputStream(clientSocket.getOutputStream());
BufferedReader inFromServer =
new BufferedReader(new inputStreamReader(
clientSocket.getlnputstream()));
Hai dòng trên tạo các đối tượng chuỗi được dán đến socket. Chuỗi
outToServer cung cấp chuỗi đầu ra của tiến trình đến socket. Chuỗi
inFromServer cung cấp chuỗi đầu vào của tiến trình từ socket (xem
hình 2.31)
sentence = inFromUser.readLine();
Dòng này thay thế dòng được nhập bởi người dùng vào sentence kiểu
chuỗi. Chuỗi sentence tiếp tục gom các kí tự đến khi người dùng kết
thúc dòng bằng phím xuống dòng. Dòng này được gửi đến thiết bị
nhập chuẩn thông qua chuỗi inFromUser vào trong chuỗi sentence.
outToServer.writeBytes(sentence + '\n');
Dòng ở trên gửi chuỗi sentence thêm mã xuống dòng vào chuỗi
outToServer. Chuỗi sentence sau khi được thêm sẽ di chuyển đến
socket của máy khách và vào ống truyền TCP. Máy khách sẽ đợi để
nhận các kí tự từ máy phục vụ.
modifiedSentence = inFromServer.readLine();
Khi các kí tự đến từ máy phục vụ, chúng sẽ thông qua chuỗi
inFromServer và đi vào chuỗi modifiedSentence tiếp tục tích lũy các
kí tự vào chuỗi modifiedSentence đến khi dòng kí tự được kết thúc với
kí tự xuống dòng lùi đầu dòng.
System.out.println("FROM SERVER " + modifiedSentence);
Dòng trên in ra màn hình chuỗi modifiedSentence được trả về bởi máy
phục vụ
180
Dòng cuối đóng các socket và đóng kết nối TCP giữa máy khách và
máy phục vụ. TCP bên máy khách gửi một thông điệp TCP đến TCP
bên máy phục vụ (xem phần 3.5)
TCPServer.java
import j ava.io.*;
import j ava.net.*;
class TCPServer {
public static void main(String argv[]) throws Exception {
String clientSentence;
String capitalizedSentence;
ServerSocket welcomeSocket = new ServerSocket(6789);
while(true) {
Socket connectionSocket = welcomeSocket.accept();
BufferedReader inFromClient =
new BufferedReader(new InputStreamReader(
connectionSocket.getlnputstream()));
DataOutputStream outToClient = new
DataOutputStream(connectionSocket.getOutputStrearn());
clientSentence = inFromClient.readLine();
capitalizedSentence = clientSentence.toUpperCase() + '\n';
outToClient.writeBytes(capitalizedSentence);
}
}
}
TCPServer có nhiều điểm tương tự với TCPClient. Do đó phần này sẽ
không nhận xét sự giống nhau hay tương tự với các câu lệnh trong
TCPClient.java. Dòng đầu tiên trong TCPServer thì hơi khác từ
TCPClient:
181
ServerSocket welcomeSocket = new ServerSocket(6789);

Dòng này tạo đối tượng welcomeSocket, là một loại ServerSocket. Đối
tượng welcomeServer là loại cánh cửa lắng nghe tiếng gõ từ client nào
đó. Socket welcomeSocket lắng nghe ở cổng 6789. Dòng tiếp theo là
Dòng này tạo một socket mới connectionSocket, khi một máy
khách nào đó gõ cửa welcomeSocket. Socket này cũng có số hiệu cổng
là 6789. TCP thiết lập một đường ống ảo trực tiếp giữa clientSocket
bên máy khách và connectionSocket bên máy phục vụ. Máy khách và
máy phục vụ kế đó gửi các byte cho nhau qua đường ống, và tất cả các
byte được gửi đến bên kia theo thứ tự. Khi connectionSocket được
thiết lập, máy phục vụ tiếp tục lắng nghe các yêu cầu dùng ứng dụng
từ các máy khách khác qua welcomeSocket. (Phiên bản chương trình
này không hỗ trợ lắng nghe nhiều yêu cầu kết nối, nhưng người đọc
có thể bổ sung mã chương trình thành nhiều tiểu trình để thực hiện
công việc này). Chương trình tạo nhiều đối tượng chuỗi, tương ứng
với các đối tượng chuỗi được tạo trong clientSocket. Xét:
capitalizedSentence = clientSentence.toUpperCase() + '\n';
Dòng lệnh này là trung tâm của ứng dụng. Dòng gửi từ máy khách,
đổi thành chữ hoa, và thêm mã xuống dòng lùi về đầu dòng. Nó dùng
phương thức toUpperCase(). Tất cả các dòng lệnh khác trong chương
trình dùng cho việc truyền thông với máy khách. Để kiểm tra hoạt
động của cặp chương trình này, cần cài đặt và biên dịch
TCPClient.java trên một máy tính và TCPServer.java trên một máy
khác. Tên máy phục vụ phải chính xác trong TCPClient.java. Thực thi
lớp TCPServer.class, chương trình máy phục vụ sẽ được biên dịch
thành tiến trình phục vụ (thường dùng từ “máy phục vụ” thay thế cho
“tiến trình máy phục vụ”). Việc này tạo một tiến trình trên máy phục
vụ và dừng nó cho đến khi có một máy khách nào đó liên lạc. Kế đó
TCPClient.class được thực thi, chương trình client được biên dịch
thành tiến trình khách (thường gọi “máy khách” thay thế cho “tiến
trình khách”). Một tiến trình bên máy khách và thiết lập kết nối TCP
giữa tiến trình khách và chủ. Cuối cùng, dùng ứng dụng, người dùng
gõ một câu kết thúc là xuống dòng lùi đầu dòng.
182
VIII. Lập trình Socket với UDP

Trong phần trước khi hai tiến trình truyền thông với nhau qua TCP,
nếu có đường ống giữa hai tiến trình. Đường ống này tồn tại đến khi
một trong hai tiến trình đóng nó lại. Khi một trong hai tiến trình muốn
gửi vài byte đến tiến trình khác, nó đơn giản chèn các byte vào đường
ống. Tiến trình gửi không dán địa chỉ đích vào các byte vì đường ống
được kết nối logic đến đích. Ngoài ra, đường ống cung cấp một kênh
dùng chuỗi byte đáng tin cậy – chuỗi byte được nhận bởi tiến trình
nhận chính xác là chuỗi byte mà tiến trình gửi chèn vào trong đường
ống.
UDP cho phép hai (hay nhiều hơn) các tiến trình chạy trên các máy
tính mạng khác nhau để truyền thông với nhau. Tuy nhiên, UDP khác
với TCP theo nhiều cách cơ bản. Đầu tiên, UDP là một dịch vụ phi kết
nối – không có giai đoạn bắt tay khởi tạo trong suốt quá trình một
đường ống thiết lập giữa hai tiến trình. Vì UDP không dùng đường
ống, khi một tiến trình muốn gửi một nhóm byte đến tiến trình khác,
tiến trình gửi phải dán địa chỉ của tiến trình đích đến nhóm byte này.
Và việc này được thực hiện cho mỗi nhóm byte mà tiến trình gửi gửi
đi. Tương tự, xét một nhóm 20 người đón 5 chiếc taxi đến cùng một
đích đến; khi người vào taxi, mỗi tài xế taxi được yêu cầu riêng lẻ các
đích đến. Do đó, UDP được xem tương tự với dịch vụ taxi. Địa chỉ
đích là một cặp gồm địa chỉ IP của máy đích và số hiệu cổng của tiến
trình đích. Nhóm gồm các byte thông tin cùng với địa chỉ IP đích và
số hiệu cổng kí hiệu là “gói” (packet). UDP cung cấp một mô hình
dịch vụ hướng thông điệp không đáng tin cậy, nó cố gắng truyền các
nhóm byte đến đích. Đó là hướng thông điệp vì gửi theo các nhóm
byte được gửi từ bên gửi và sẽ truyền đến bên đích dưới dạng nhóm
byte. Nó ngược lại với ngữ nghĩa của chuỗi byte TCP. Dịch vụ UDP
không đảm bảo rằng nhóm byte thực sự được giao đến đích. Dịch vụ
UDP do đó ngược lại (theo vài khía cạnh nào đó) với mô hình dịch vụ
chuỗi byte đáng tin cậy của TCP.
Sau khi tạo gói dữ liệu, tiến trình gửi đẩy gói vào mạng đến socket
gửi. Ở đầu bên kia của socket gửi, có một chiếc taxi đang đợi gói tin.
Chiếc taxi chở gói tin theo hướng địa chỉ đích của gói. Tuy nhiên,
chiếc taxi không đảm bảo nó sẽ giao gói tín đến đích cuối cùng –
183
chiếc taxi có thể bị hỏng hóc hoặc chịu các vấn đề không thấy trước
khác. Nói cách khác, UDP cung cấp dịch vụ vận tải không đáng tin
cậy đến các tiến trình truyền thông của nó – nó không đảm bảo một
gói sẽ chạm đến đích cuối cùng.
Trong phần này, lập trình socket sẽ được hướng dẫn bằng cách cài đặt
lại cùng ứng dụng với phần trước, nhưng bây giờ là thiết kế trên UDP.
Mã chương trình dùng UDP sẽ khác với mã chương trình dùng TCP.
Đặc biệt (1) không có bắt tay ban đầu giữa hai tiến trình và do đó
không cần welcomeSocket, (2) không có chuỗi nào dán vào socket, (3)
các máy tính mạng gửi tạo các gói bằng cách dán địa chỉ IP đích và số
hiệu cổng vào mỗi nhóm byte nó gửi đi, và (4) tiến trình nhận phải sắp
xếp các gói nhận được để nhận được tất cả các byte thông tin của gói.
1 – Máy khách đọc một dòng từ thiết bị nhập chuẩn (bàn phím)
và gửi dòng này vào socket của nó để đi đến máy phục vụ
2 – Máy phục vụ đọc dòng dữ liệu này từ socket của nó
3 – Máy phục vụ chuyển dòng này thành kí tự hoa
4 – Máy phục vụ gửi dòng được bổ sung thông tin ra socket của
nó để truyền đến máy khách
5 – Máy khách đọc dòng bổ sung thông tin từ socket của nó và in
dòng này lên thiết bị xuất chuẩn (màn hình)
Hình 2.32 làm nổi bật hành động chính liên quan đến socket của máy
khách và máy phục vụ truyền thông với nhau thông qua dịch vụ truyền
tải phi kết nối (UDP)
184
Hình 2.32. Ứng dụng khách – phục vụ dùng các dịch vụ truyền tải phi kết nối
Mã chương trình tập tin UDPClienl.java

import java.io.*;
import j ava.net.*;
class UDPClient {
public static void main(String args[]) throws Exception
{
BufferedReader inFromUser = new BufferedReader(
new InputStreamReader(System.in));
DatagramSocket clientSocket = new DatagramSocket();
InetAddress IPAddress = InetAddress.getByName("hostname");
byte[] sendData = new byte[1024];
byte[] receiveData = new byte[1024];
185
String sentence = inFromUser.readLine();

sendData = sentence.getBytes();
DatagramPacket sendPacket = new DatagramPacket(
sendData, sendData.length, IPAddress, 9876);
clientSocket.send(sendPacket);
DatagramPacket receivePacket =
new DatagramPacket(receiveData, receiveData.length);
clientSocket.receive(receivePacket);
String modifiedSentence = new String(receivePacket.getData());
System.out.printIn("FROM SERVER:" + modifiedSentence);
}
}
Chương trình UDPClient.java thiết lập một chuỗi và một socket, như
trong hình 2.33. Socket được gọi là clientSocket, và nó là một dạng
DatagramSocket. Ghi chú UDP dùng một loại socket khác TCP ở phía
máy khách. Với UDP máy khách dùng một DatagramSocket trong khi
với TCP máy khách dùng một Socket. Chuỗi inFromUser là một chuỗi
đầu vào đến chương trình; nó được dán vào thiết bị nhập chuẩn (bàn
phím), cũng có một chuỗi tương tự trong phiên bản TCP chương trình
của chúng ta. Khi người dùng gõ các kí tự trên bàn phím, các kí tự
theo luồng đi vào chuỗi inFromUser. Ngược với TCP, không có chuỗi
nào (nhập hay xuất) được dán vào socket. Thay vì truyền các byte đến
chuỗi được dán vào đối tượng Socket, UDP sẽ đẩy các gói đơn đến đối
tượng DatagramSocket.
DatagramSocket clientSocket = new DatagramSocket();
Dòng này tạo đối tượng clientSocket có kiểu là DatagramSocket.
Khác với TCPClient.java, dòng này không khởi tạo kết nối TCP. Cụ
thể, máy khách không liên lạc với máy phục vụ bằng cách kích hoạt
dòng này. Do nguyên nhân này nên hàm thiết lập DatagramSocket()
không dùng tên máy hay số hiệu cổng như các thông số. Tương tự với
hình ảnh cửa chính – đường ống, việc thực thi dòng trên tạo một cánh
186
cửa cho tiến trình khách nhưng không tạo đường ống giữa hai tiến
trình.
InetAddress IPAddress = InetAddress.getByName("hostname");
Hình 2.33. UDPClient có một chuỗi; socket nhận các gói từ tiến trình và
phân phối các gói đến tiến trình.
Để gửi các byte đến tiến trình đích, cần địa chỉ của tiến trình. Thành
phần của địa chỉ này là địa chỉ IP của máy đích. Dòng mã trên kích
hoạt việc tìm kiếm địa chỉ IP từ tên máy tính thông qua dịch vụ DNS.
DNS vừa được kích hoạt bởi phiên bản máy khách TCP, dù nó được
làm không tường minh hơn tường mình. Phương thức getByName()
lấy một thông số tên máy tính của máy phục vụ và trả về địa chỉ IP
của cùng máy phục vụ. Nó thay địa chỉ này vào IPAddress của
InetAddress
187

Các mảng byte sendData và receiveData sẽ giữ dữ liệu máy khách gửi
và nhận một cách tương ứng.
sendData = sentence.getBytes();
Dòng ở trên thực hiện việc chuyển kiểu dữ liệu. Nó nhận vào chuỗi
sentence và đổi tên lại thành sendData, là một mảng các byte.
DatagramPacket sendPacket = new DatagramPacket (
sendData, sendData.length, IPAddress, 9876);
Dòng này thiết lập gói sendPacket mà máy khách sẽ đẩy vào mạng từ
socket của nó. Gói này bao gồm dữ liệu chứa trong gói sendData,
chiều dài dữ liệu này, địa chỉ IP của máy phục vụ, và số hiệu cổng của
ứng dụng (đặt là 9876). Lưu ý sendPacket có kiểu DatagramPacket.
clientSocket. send (sendPacket);
Dòng trên phương thức send() của đối tượng clientSocket lấy gói vừa
được thiết lập và đẩy nó vào mạng thông qua clientSocket. Một lần
nữa, chú ý là UDP gửi dòng kí tự theo cách khác TCP. TCP đơn giản
chèn chuỗi kí tự vào một chuỗi, kết nối trực tiếp đến máy phục vụ.
UDP tạo một gói bao gồm địa chỉ của máy phục vụ. Sau khi gửi gói
tin, máy khách đợi nhận gói tin từ máy phục vụ.
Trong dòng trên trong khi đợi gói từ máy phục vụ, máy khách tạo một
nơi giữ gói tin receivePacket, một đối tượng kiểu DatagramPacket.
clientSocket. receive (receivePacket);
Máy khách dừng đến khi nhận được một gói tin; khi nó nhận một gói,
nó đặt gói đó vào receivePacket.
String modifiedSentence = new String(receivePacket.getData());
Dòng trên rút ra dữ liệu từ receivePacket và thực hiện chuyển kiểu dữ
liệu, chuyển một mảng byte thành chuỗi modifiedSentence.
System.out.println("FROM SERVER:" + modifiedSentence);
188
Dòng này giống trong TCPClient, thực hiện việc in chuỗi

modifiedSentence ra màn hình của máy khách.
Dòng cuối đóng socket. Vì UDP là phi kết nối, dòng này không phải
yêu cầu máy khách gửi một thông điệp tầng vận tải đến máy phục vụ
(ngược với TCPClient)
Mã chương trình tập tin UDPScrvcr.java
import java.io.*;
import java.net.*;
class UDPServer
{
public static void main(String args[]) throws Exception
{
DatagramSocket serverSocket = new
DatagramSocket(9876);
while(true)
{
serverSocket.receive(receivePacket);
String sentence = new String(receivePacket.getData());
InetAddress IPAddress = receivePacket.getAddress();
int port = receivePacket.getPort();
String capitalizedSentence = sentence.toUpperCase();
189
sendData = capitalizedSentence.getBytes();
DatagramPacket sendPacket = new DatagramPacket(sendData,
sendData.length, IPAddress, port);
serverSocket.send(sendPacket);
}
}
}
Chương trình UDPServer.java thiết lập một socket, như trong hình
2.34. Socket được gọi là serverSocket. Đó là một đối tượng kiểu
DatagramSocket, cũng là một socket phía máy khách của ứng dụng.
Một lần nữa, không có chuỗi nào được dán vào socket.
Hình 2.34. UDPServer không có chuỗi nào; socket nhận gói từ tiến trình và
phân phối gói đến tiến trình
Các dòng này khác với TCPServer.java
190
DatagramSocket serverSocket = new DatagramSocket(9876);

Dòng trên thiết lập DatagramSocket serverSocket có cổng 9876.
Tất cả dữ liệu được gửi và nhận sẽ đi qua socket này. Vì UDP là phi
tuyến, không tạo socket mới và tiếp tục lắng nghe các yêu cầu kết nối
mới, như được thực hiện trong TCPServer.java. Nếu nhiều máy khách
truy cập ứng dụng này, họ sẽ gửi các gói vào cánh cửa duy nhất
serverSocket.
String sentence = new String(receivePacket.getData());
InetAddress IPAddress = receivePacket.getAddress();
int port = receivePacket.getPort();
Ba dòng trên mô tả gói tin đến từ máy khách. Dòng đầu thực hiện
trích dữ liệu từ gói và đặt dữ liệu vào chuỗi sentence, nó tương tự như
dòng mã chương trình trong UDPClient. Dòng thứ 2 trích địa chỉ IP;
dòng thứ 3 trích số hiệu cổng, được chọn bởi máy khách và khác số
hiệu cổng của máy phục vụ 9876. Thật cần thiết để máy phục vụ có
địa chỉ (địa chỉ IP và số hiệu cổng) của máy khách, để có thể gửi
sentence được chuyển thành chuỗi kí tự in hoa ngược về máy khách.
Để kiểm tra ứng dụng, cài đặt và biên dịch chương trình
UDPClient.java trên một máy và UDPServer.java trên một máy khác.
Tiếp theo kích hoạt 2 chương trình trên các máy tính ngang hàng có
kết nối mạng. Không giống với TCP, đầu tiên kích hoạt máy khách và
kế tiếp là kích hoạt máy phục vụ. Do tiến trình khách không thử khởi
tạo kết nối đến máy phục vụ khi chương trình khách được kích hoạt.
Khi kích hoạt hai chương trình khách và chủ rồi, dùng ứng dụng gõ
một dòng kí tự bên phía máy khách.
IX. Tóm lược

Trong chương này đã giới thiệu:
- Các khái niệm và cài đặt của các ứng dụng mạng
- Kiến trúc khách – phục vụ phổ biến được dùng nhiều trong các
ứng dụng Internet như HTTP, FTP, SMTP, POP3 và DNS.
191
- Các giao thức trong tầng Ứng dụng trên dùng đến trong các ứng
dụng như Web, truyền tập tin, thư điện tử, và DNS chi tiết hơn.
- Kiến trúc P2P được dùng trong một số ứng dụng.
- Thư viện Socket API được dùng để xây dựng nên các ứng dụng
mạng.
- Việc dùng socket cho các dịch vụ truyền tải hệ cuối – hệ cuối
hướng kết nối (TCP) và phi kết nối (UDP).
Trong phần 2.1 các mô hình dịch vụ mà TCP và UDP hỗ trợ cho các
ứng dụng dùng. Các mô hình dịch vụ này cũng được chi tiết hơn khi
các ứng dụng đơn giản được phát triển trên giao thức TCP và UDP
trong phần 2.7 và 2.8. Tuy nhiên, chương này ít nói đến TCP và UDP
cung cấp các mô hình dịch vụ này như thế nào. Trong chương tiếp
theo các dịch vụ tần vận tải sẽ được xem xét kĩ hơn.
192
Chương 3
TẦNG VẬN CHUYỂN
Chương này sẽ khảo sát tầng vận chuyển trong mô hình OSI, một
trong những tầng quan trọng trong một kiến trúc mạng. Tầng vận
chuyển đóng vai trò quan trọng trong quá trình truyền dữ liệu là cung
cấp các dịch vụ truyền dữ liệu giữa các ứng dụng đang chạy trên các
host khác nhau. Chương này trình bày các nguyên lý trong tầng vận
chuyển và khảo sát việc áp dụng các nguyên lý này trong một số giao
thức, đặc biệt là các giao thức đang hoạt động trong mạng Internet
như TCP, UDP.
Trước tiên, dựa trên mối tương quan giữa tầng vận chuyển và tầng
mạng, một chức năng quan trọng của tầng vận chuyển là mở rộng dịch
vụ truyền dữ liệu giữa hai hệ thống đầu cuối (end system) của tầng
mạng thành dịch vụ truyền dữ liệu giữa hai ứng dụng chạy trên các hệ
thống đầu cuối. Điều này sẽ được thể hiện qua giao thức phi kết nối
hoạt động trong mạng Internet, giao thức UDP.
Tiếp theo, chương này cũng khảo sát các nguyên lý để giải quyết bài
toán cơ bản trong mạng: làm thế nào để các thực thể có thể truyền
thông đáng tin cậy thông qua đường truyền có khả năng xảy ra lỗi bit
hay mất gói. Các kỹ thuật mà các giao thức tầng vận chuyển dùng để
giải quyết bài toán này được trình bày thông qua các tình huống với
độ phức tạp tăng dần. Đồng thời, chương này cũng minh hoạ giao thức
TCP, một giao thức tầng vận chuyển hướng kết nối trong Internet, áp
dụng các nguyên lý này như thế nào.
Và phần cuối của chương này sẽ trình bày vấn đề cơ bản quan trọng
thứ hai trong mạng máy tính: kiểm soát tốc độ truyền dữ liệu của các
thực thể tại tầng vận chuyển như thế nào để tránh hay phục hồi tắc
193
Chương 3. Tầng Vận chuyển
nghẽn trong mạng. Chúng ta sẽ xem xét nguyên nhân và hệ quả của
hiện tượng tắc nghẽn thông qua các kỹ thuật kiểm soát tắc nghẽn tổng
quát. Sau đó, chúng ta sẽ tìm hiểu cơ chế kiểm soát tắc nghẽn trong
TCP để hiểu rõ hơn về vấn đề này.
I. Giới thiệu và các dịch vụ ở tầng Vận chuyển

Chương 1 và chương 2 đã giới thiệu sơ nét về vai trò cũng như các
dịch vụ của tầng vận chuyển. Trong phần này, chúng ta sẽ nhắc lại
một số vấn đề cơ bản trong tầng vận chuyển.
Một giao thức tại tầng vận chuyển cung cấp một kết nối logic (logic
communication) giữa các ứng dụng chạy trên các host khác nhau. Kết
nối logic này thiên về hướng ứng dụng vì trong thực tế các host mà
ứng dụng chạy trên đó có thể nối trực tiếp với nhau hoặc có thể kết nối
với nhau qua nhiều bộ định tuyến (router) và qua nhiều loại liên kết
khác nhau. Các ứng dụng truyền thông điệp cho nhau qua kết nối logic
được cung cấp bởi tầng vận chuyển mà không cần phải lo lắng về hạ
tầng vật lý dùng để truyền tải thông điệp. Hình 3.1 là một ví dụ minh
hoạ cho một kết nối logic.
Trong hình 3.1, các giao thức tầng vận chuyển được cài đặt tại các hệ
thống đầu cuối (end system), không phải tại các bộ định tuyến. Tại
bên gởi, tầng vận chuyển đóng gói thông điệp nhận được từ các ứng
dụng nguồn thành gói tin tại tầng vận chuyển, được gọi là các phân
đoạn (segment). Các thông điệp từ các ứng dụng có thể bị phân thành
nhiều phân mảnh nhỏ và sau đó được thêm header của giao thức tầng
vận chuyển để tạo thành các phân đoạn. Sau đó, tầng vận chuyển
chuyển các phân đoạn này xuống tầng mạng. Tại tầng mạng, các phân
đoạn được đóng gói thành các gói tin tầng mạng và chuyển đến bên
nhận. Lưu ý rằng, bộ định tuyến tại tầng mạng chỉ xử lý thông tin
thêm vào tại tầng mạng của gói tin chứ không thao tác trên các thông
tin tầng vận chuyển. Tại bên nhận, tầng mạng rút trích các phân đoạn
từ các gói tin và chuyển lên cho tầng vận chuyển. Tầng vận chuyển xử
lý các phân đoạn nhận được từ tầng mạng và sẵn sàng chuyển thông
điệp trong các phân đoạn đó lên tầng ứng dụng.
194
Hình 3.1 Tầng vận chuyển cung cấp kết nối logic cho các tiến trình
ứng dụng
Tầng vận chuyển có thể cung cấp một hay nhiều giao thức tầng vận
chuyển cho các ứng dụng mạng. Ví dụ, tầng vận chuyển trong Internet
cung cấp hai giao thức TCP và UDP. Mỗi giao thức này cung cấp một
dịch vụ khác nhau cho các ứng dụng mạng.
I.1 Quan hệ giữa tầng Vận chuyển và tầng Ứng dụng
Trong mô hình OSI, tầng vận chuyển nằm ngay bên trên tầng mạng.
Trong khi giao thức tầng vận chuyển cung cấp các kết nối logic giữa
các ứng dụng chạy trên các host khác nhau, giao thức tầng mạng cung
cấp kết nối logic giữa các host khác nhau. Sự khác biệt giữa hai tầng
này không nhiều tuy nhiên rất quan trọng. Trong phần này, chúng ta
195
sẽ phân tích sự khác biệt này thông qua một ví dụ gởi thư giữa các
nhân viên trong hai chi nhánh của một công ty.
Xét hai chi nhánh của một công ty A, một chi nhánh ở Hồ Chí Minh
và một chi nhánh ở Hà Nội. Trong mỗi chi nhánh có 12 người. Nhân
viên trong hai chi nhánh cần phải liên lạc với nhau để trao đổi công
việc hàng tuần. Giả sử, họ liên lạc với nhau bằng cách gởi thư hàng
tuần thông qua bưu điện bằng các bức thư riêng. Như vậy, mỗi chi
nhánh sẽ gởi đi 144 bức thư mỗi tuần. An và Bình là hai nhân viên
phụ trách việc nhận thư từ bưu điện và phân phát thư cho các nhân
viên tại chi nhánh Hồ Chí Minh và Hà Nội. Khi An nhận một bức thư
từ bưu điện, An phân phát bức thư đó cho nhân viên tại chi nhánh Hồ
Chí Minh và nhận thư từ các nhân viên của chi nhánh này chuyển cho
bưu điện. Bình cũng làm công việc tương tự tại chi nhánh Hà Nội.
Trong ví dụ gởi thư ở trên, bưu điện cung cấp một kết nối logic giữa
hai chi nhánh: chuyển các bức thư từ chi nhánh này đến chi nhánh
khác. Còn An và Bình cung cấp kết nối logic giữa các nhân viên: nhận
thư từ các nhân viên gởi cho bưu điện và chuyển thư cho các nhân
viên khi nhận được thư từ bưu điện. Đối với các nhân viên, An và
Bình đóng vai trò cung cấp dịch vụ gởi thư mặc dù họ chỉ tham gia
một phần vào quá trình gởi thư. Trong ví dụ này:
Thông điệp tầng ứng dụng = bức thư
ứng dụng = nhân viên
host (hệ thống đầu cuối) = chi nhánh
giao thức tầng vận chuyển = An và Bình
giao thức tầng mạng = bưu điện
Tiếp tục với ví dụ này, An và Bình chỉ thực hiện nhiệm vụ tại chi
nhánh của mình. Họ không tham gia vào quá trình sắp xếp thư tại các
bưu điện trung gian hay chuyển thư từ bưu điện này sang bưu điện
khác. Tương tự, giao thức tầng vận chuyển chỉ thực thi tại các hệ
thống đầu cuối. Trong một hệ thống đầu cuối, giao thức tầng vận
chuyển thực hiện nhận các thông điệp từ các ứng dụng và chuyển cho
tầng mạng và ngược lại, không quan tâm các thông điệp truyền đi như
196
thế nào trong mạng. Như ví dụ trong hình 3.1, các bộ định tuyến trung
gian không xử lý thông tin được thêm vào tại tầng vận chuyển.
Trong ví dụ gởi thư trên, giả sử rằng khi An và Bình nghỉ hè, công ty
giao công việc nhận và phân phát thư cho San và Hằng. Tuy nhiên,
San và Hằng không có kinh nghiệm trong việc nhận và phân phát thư
và không thực hiện giống như An và Bình đã làm. San và Hằng nhận
và phân phát thư không thường xuyên và thường làm lạc mất thư. Do
đó, San và Hằng không cung cấp cùng tập các dịch vụ như An và Bình
đã cung cấp. Tương tự như vậy, mạng máy tính cũng cung cấp nhiều
giao thức tầng vận chuyển và mỗi giao thức cung cấp dịch vụ khác
nhau cho tầng ứng dụng.
Những dịch vụ mà An và Bình cung cấp phụ thuộc các dịch vụ do bưu
điện cung cấp. Ví dụ, nếu bưu điện không cung cấp dịch vụ đảm bảo
việc gửi thư giữa hai địa điểm trong một thời gian nhất định (ví dụ tối
đa ba ngày) thì An và Bình không thể đảm bảo thời gian phân phát thư
cho nhân viên tối đa là bao nhiêu ngày. Tương tự, dịch vụ tầng vận
chuyển cung cấp cũng bị phụ thuộc bởi các dịch vụ do tầng mạng
cung cấp. Nếu các giao thức tầng mạng không đảm bảo băng thông và
độ trễ khi gởi gói tin giữa hai nút mạng thì các giao thức tầng vận
chuyển cũng không thể đảm bảo các ràng buộc đó khi truyền các
thông điệp giữa các ứng dụng.
Tuy nhiên, các giao thức tầng vận chuyển có thể cung cấp các dịch vụ
cần thiết cho dù các giao thức ở tầng mạng không cung cấp dịch vụ
tương ứng. Ví dụ, giao thức tầng vận chuyển TCP có thể cung cấp
dịch vụ truyền dữ liệu đáng tin cậy cho các ứng dụng mặc dù giao
thức tầng bên dưới cung cấp dịch vụ truyền dữ liệu không đáng tin cậy
(mất gói, lỗi dữ liệu, dữ liệu trùng). Một ví dụ khác, giao thức SSL có
thể mã hoá dữ liệu để đảm bảo người tấn công không thể đọc được các
thông điệp tầng ứng dụng khi không có quyền mặc dù giao thức tầng
mạng không đảm bảo tính bảo mật cho các gói tin tầng vận chuyển.
I.2 Tổng quan về tầng Vận chuyển trong Internet
Internet và các mạng TCP/IP nói chung cung cấp hai giao thức tầng
vận chuyển khác biệt cho các ứng dụng mạng. Một là giao thức UDP
(User Datagram Protocol), cung cấp dịch vụ phi kết nối và không
197
đáng tin cậy cho các ứng dụng mạng. Hai là giao thức TCP
(Transmission Control Protocol), cung cấp dịch vụ hướng kết nối và
đáng tin cậy cho các ứng dụng mạng. Khi thiết kế một ứng dụng
mạng, người thiết kế ứng dụng phải chọn một trong hai giao thức này
để truyền dữ liệu tại tầng vận chuyển. Như đã trình bày trong mục VII
và mục VIII, chương 2, người thiết kế ứng dụng phải chọn sử dụng
giao thức TCP hay UDP khi tạo socket để truyền dữ liệu.
Để đơn giản thuật ngữ dùng trong chương này, trong ngữ cảnh
Internet, thuật ngữ gói tin TCP (TCP packet) sẽ được dùng thay cho
thuật ngữ phân đoạn TCP (TCP segment), và thuật ngữ gói dữ liệu
(datagram) được dùng thay cho phân đoạn UDP (UDP segment).
Trước khi trình bày chi tiết giao thức TCP và UDP, chúng ta sẽ khảo
sát sơ lược về tầng mạng (chi tiết về tầng mạng xem chương 4). Giao
thức tầng mạng IP (Internet Protocol) cung cấp một kênh truyền dữ
liệu ở mức logic giữa các host. Giao thức IP hoạt động theo mô hình
nỗ lực truyền dữ liệu (best-effort delivery). Điều này có nghĩa là giao
thức IP “cố gắng” chuyển các gói tin giữa các host nhưng không đảm
bảo điều gì. Trong thực tế, giao thức IP không đảm bảo việc truyền
các gói tin, không đảm bảo các gói tin đến đúng thứ tự và không đảm
bảo tính toàn vẹn của các gói tin. Do đó, giao thức IP được xem là một
dịch vụ không đáng tin cậy. Và lưu ý rằng, mỗi host có một địa chỉ
tầng mạng, gọi là địa chỉ IP (chi tiết xem chương 4).
Tiếp theo, chúng ta sẽ tóm tắt mô hình dịch vụ mà giao thức TCP và
UDP cung cấp. Nhiệm vụ cơ bản của TCP và UDP là mở rộng dịch vụ
truyền dữ liệu của IP đến hai hệ đầu cuối (end system) để cung cấp
dịch vụ truyền dữ liệu giữa các tiến trình chạy trên các hệ đầu cuối.
Quá trình mở rộng dịch vụ truyền dữ liệu giữa host với host thành
truyền dữ liệu giữa tiến trình với tiến trình được gọi là dồn kênh và
phân kênh tại tầng vận chuyển (chi tiết xem tại mục II của chương
này). Giao thức TCP và UDP cũng cung cấp việc kiểm tra tính toàn
vẹn của dữ liệu bằng cách thêm vào trường kiểm tra lỗi trong header
của các phân đoạn. Giao thức UDP chỉ cung cấp hai dịch vụ truyền dữ
liệu giữa tiến trình với tiến trình và kiểm tra lỗi. Do đó giao thức UDP
cũng là một giao thức không đáng tin cậy, không đảm bảo dữ liệu đến
được đích đến (chi tiết xem tại mục III trong chương này).
198
Ngược lại, giao thức TCP cung cấp các dịch vụ truyền thống cho các
ứng dụng mạng: truyền dữ liệu đáng tin cậy. Bằng việc sử dụng cơ
chế kiểm soát luồng (flow control), số thứ tự (sequence number), báo
nhận (acknowledgement), đồng hồ (timer), giao thức TCP đảm bảo dữ
liệu gởi từ bên gởi đến bên nhận chính xác và đúng thứ tự. Do đó,
giao thức TCP chuyển dịch vụ truyền dữ liệu không đáng tin cậy của
giao thức IP thành dịch vụ truyền dữ liệu đáng tin cậy giữa các tiến
trình. Bên cạnh đó, TCP cũng cung cấp cơ chế kiểm soát tắc nghẽn
(congestion control). Dịch vụ kiểm soát tắc nghẽn không là một dịch
vụ cung cấp cho ứng dụng mà hướng đến cung cấp cho toàn Internet.
Hay nói cách khác, cơ chế kiểm soát tắc nghẽn TCP ngăn chặn một
kết nối TCP bất kỳ làm tràn ngập các liên kết và các bộ định tuyến
(router) giữa các host đang liên lạc với nhau một lượng lớn lưu lượng
mạng. TCP cố gắng chia sẻ băng thông cho mỗi kết nối đi qua các liên
kết bị tắc nghẽn là như nhau. Điều này được thực hiện bằng cách điều
chỉnh tốc độ gởi dữ liệu tại bên gởi của một kết nối TCP thường
xuyên. Nói cách khác, luồng dữ liệu của giao thức UDP là không điều
chỉnh. Một ứng dụng sử dụng giao thức UDP tại tầng vận chuyển có
thể gởi dữ liệu với bất kỳ tốc độ nào nó muốn và gởi bao lâu cũng
được.
Một giao thức cung cấp dịch vụ truyền dữ liệu đáng tin cậy và kiểm
soát tắc nghẽn có độ phức tạp nhất định. Chi tiết nguyên lý truyền dữ
liệu đáng tin cậy, kiểm soát tắc nghẽn và giao thức TCP sẽ được trình
bày trong các mục từ IV đến VIII. Đồng thời chúng ta cũng xét mối
tương quan giữa các nguyên lý cơ bản và giao thức TCP. Trước hết,
chúng ta sẽ xem xét nguyên lý truyền dữ liệu sau đó thảo luận giao
thức TCP đặc tả cơ chế truyền dữ liệu đáng tin cậy như thế nào.
II. Dồn kênh [Multiplexing] và Phân kênh [demultiplexing]

Dồn kênh và phân kênh tại tầng vận chuyển là một mở rộng của dịch
vụ truyền dữ liệu giữa host với host của tầng mạng thành truyền dữ
liệu giữa các ứng dụng chạy trên các host. Để phần này độc lập, chúng
ta sẽ thảo luận dịch vụ cơ bản tầng vận chuyển trong ngữ cảnh
Internet. Tuy nhiên, lưu ý rằng dịch vụ dồn kênh và phân kênh là một
dịch vụ cần thiết cho tất cả các mạng máy tính.
199
Tại host nhận, tầng vận chuyển chỉ nhận các phân đoạn từ tầng mạng.
Tầng vận chuyển có trách nhiệm truyền dữ liệu trong các phân đoạn
này đến tiến trình ứng dụng tương ứng đang chạy trên host đó.
Ví dụ, máy tính của bạn đang tải một trang web, mở một kết nối FTP
và hai phiên Telnet. Trong trường hợp này, máy tính của bạn có bốn
tiến trình ứng dụng đang chạy: 2 tiến trình Telnet, 1 tiến trình FTP, và
1 tiến trình HTTP. Khi tầng vận chuyển trong máy của bạn nhận dữ
liệu từ tầng mạng, nó có trách nhiệm chuyển dữ liệu đó đến một trong
4 tiến trình này. Mà mỗi tiến trình có thể có một hay nhiều socket,
cánh cửa để truyền dữ liệu từ tiến trình đến tầng mạng và ngược lại
(mục VII và VIII, chương 2). Vì thế, như hình 3.2, tầng vận chuyển tại
host nhận không thật sự chuyển dữ liệu trực tiếp đến một tiến trình mà
chuyển dữ liệu đến socket trung gian. Mỗi host nhận luôn có ít nhất
một socket, mỗi socket có 1 định danh duy nhất (unique identifier).
Định dạng của một định danh phụ thuộc vào socket đó là socket TCP
hay UDP.
Tiếp theo, chúng ta sẽ khảo sát cách thức host nhận chuyển dữ liệu
trong một phân đoạn tầng vận chuyển tới một socket tương ứng. Mỗi
phân đoạn tầng vận chuyển có tập các trường dữ liệu để phục vụ cho
mục đích này. Tại bên nhận, tầng vận chuyển thực thi các trường này
để xác định socket nhận và sau đó chuyển trực tiếp phân đoạn đến
socket đó. Công việc chuyển phân đoạn tầng vận chuyển về đúng
socket được gọi là phân kênh (demultiplexing). Công việc thu thập
các đoạn dữ liệu (data chunk) tại bên gởi từ các socket khác nhau,
đóng gói thành từng phân đoạn với thông tin header của giao thức
tầng vận chuyển và chuyển các phân đoạn này xuống tầng mạng được
gọi là dồn kênh (multiplexing). Thông tin header được thêm vào tại
bên gởi được dùng cho giai đoạn phân kênh tại bên nhận.
Như ví dụ hình 3.2, tầng vận chuyển trong host B phải phân kênh các
phân đoạn nhận từ tầng mạng đến tiến trình P1 và P2 bằng cách
chuyển dữ liệu trong các phân đoạn nhận được đến socket tương ứng.
Tầng vận chuyển trong host B phải thu thập dữ liệu từ các socket này,
đóng gói thành các phân đoạn và chuyển các phân đoạn này xuống
tầng mạng.
200
Một ví dụ khác về phân kênh là ví dụ gởi thư trong mục I.1. Mỗi nhân
viên được định danh bởi tên của người đó. Khi Bình nhận thư từ bưu
điện, Bình thực hiện phân kênh bằng cách xem ai là người nhận thư và
sau đó chuyển thư đến đúng nhân viên đó. An thực hiện dồn kênh khi
thu thập thư từ các nhân viên trong chi nhánh Hà Nội và chuyển cho
bưu điện.
Hình 3.2. Dồn kênh và phân kênh tại tầng vận chuyển (note: ghi chú
tên các máy là A, V và C)
Tiếp theo, chúng ta sẽ khảo sát các chức năng này hoạt động như thế
nào trong một host. Như đã thảo luận ở trên, chức năng dồn kênh đòi
hỏi (1) mỗi socket phải có một định danh duy nhất và (2) mỗi phân
đoạn phải có một số trường đặc biệt chỉ định socket nào sẽ nhận phân
đoạn đó. Những trường này là cổng (port) nguồn và cổng đích đến,
như minh hoạ hình 3.3 (phân đoạn TCP và UDP còn có thêm những
trường thông tin khác). Cổng, port, là một con số 16 bit, có giá trị từ 0
đến 65535. Trong đó, cổng có giá trị từ 0 đến 1023, được gọi là cổng
phổ biến1 (well-known port number), bị giới hạn sử dụng; nghĩa là các
cổng này được dành riêng cho các giao thức ứng dụng phổ biến như
HTTP (cổng 80), FTP (cổng 21), và DNS (cổng 53). Khi chúng ta
phát triển một ứng dụng mới, chúng ta phải gán cho ứng dụng một
cổng.
1
Tham khảo danh sách các cổng phổ biến trong RFC 1700 và được cập nhật tại trang web
http://www.iana.org (RFC 3232)
201
Hình 3.3. Trường cổng nguồn (src_port) và cổng đích đến (dest_port)
trong một phân đoạn tầng vận chuyển
Như vậy, tầng vận chuyển có thể cài đặt chức năng phân kênh bằng
cách: mỗi socket có một định danh duy nhất, cổng, và khi một host
nhận một phân đoạn, tầng vận chuyển kiểm tra trường cổng đích đến
trong phân đoạn và chuyển trực tiếp phân đoạn đó đến socket tương
ứng. Sau đó, dữ liệu trong phân đoạn được chuyển đến tiến trình
tương ứng thông qua socket. Giao thức UDP áp dụng qui trình này.
Tuy nhiên, chức năng dồn kênh và phân kênh trong giao thức TCP thì
phức tạp hơn.
Dồn kênh và phân kênh phi kết nối
Quay lại mục VIII chương 2, một chương trình Java chạy trong một
host có thể tạo một socket UDP bằng dòng lệnh
DatagramSocket mySocket = new DatagramSocket();
Khi một socket UDP được tạo bằng cách này, tầng vận chuyển tự
động ấn định giá trị cổng cho socket. Trong thực tế, tầng vận chuyển
ấn định một cổng có giá trị từ 1024 đến 65535 mà không bị sử dụng
bởi socket nào trong host. Tương tự, một chương trình Java cũng có
thể tạo một socket UDP bằng dòng lệnh:
DatagramSocket mySocket = new DatagramSocket(19157);
Trong trường hợp này, ứng dụng ấn định một cổng cụ thể, 19157, cho
socket UDP. Nếu người phát triển ứng dụng cài đặt một ứng dụng
server của một giao thức phổ biến, người đó phải ấn định cổng phổ
202
biến tương ứng. Về cơ bản, các ứng dụng khách (client) nên để tầng
vận chuyển ấn định cổng tự động (và trong suốt) cho các socket, trong
khi các ứng dụng chủ (server) ấn định một cổng cố định.
Giả sử, một tiến trình trong host A dùng cổng UDP 19157, muốn gởi
dữ liệu tới một tiến trình dùng cổng UDP 46428 trong host B. Tầng
vận chuyển trong host A tạo một phân đoạn bao gồm dữ liệu tầng ứng
dụng, cổng nguồn 19157, cổng đích đến 46428 và một số thông tin
khác (xem chi tiết tại mục III.1). Sau đó, tầng vận chuyển chuyển
phân đoạn kết quả đến tầng mạng. Tầng mạng đóng gói phân đoạn đó
trong một gói tin IP và nỗ lực truyền phân đoạn này đến host nhận.
Nếu phân đoạn đến host B, tầng vận chuyển tại bên nhận sử dụng
trường cổng đích đến trong phân đoạn (46428) để chuyển nó đến
socket có cổng 46428. Lưu ý, host B có thể chạy nhiều tiến trình cùng
lúc và mỗi tiến trình có một socket UDP với 1 cổng tương ứng. Khi
phân đoạn UDP đến từ mạng, host B chuyển (phân kênh) trực tiếp mỗi
phân đoạn đến socket tương ứng sử dụng trường cổng đích đến.
Một điều quan trọng là một socket UDP được định danh bằng một bộ
hai thông tin gồm địa chỉ IP đích đến và cổng đích đến. Như vậy, nếu
hai phân đoạn UDP có địa chỉ IP nguồn hoặc cổng nguồn khác nhau
nhưng có cùng địa chỉ IP đích đến và cổng đích đến thì đều được
chuyển đến cùng tiến trình đích đến thông qua cùng socket đích đến.
Vậy câu hỏi đặt ra là thông tin cổng nguồn đóng vai trò gì ? Như ví dụ
trong hình 3.4, trong phân đoạn A-B, cổng nguồn đóng vai trò như
một địa chỉ trả về. Khi B muốn gởi một phân đoạn ngược lại cho A,
cổng đích đến trong phân đoạn B-A được lấy từ cổng nguồn trong
phân đoạn A-B (địa chỉ trả về đầy đủ bao gồm địa chỉ IP của A và
cổng nguồn). Với ví dụ trong mục VIII của chương 2, trong
UDPServer.java, ứng dụng chủ sử dụng cổng nguồn từ phân đoạn
nhận được từ ứng dụng khách làm cổng đích đến để tạo phân đoạn
mới khi gởi dữ liệu về cho ứng dụng khách.
203
Hình 3.4. Chuyển đổi cổng nguồn và cổng đích đến

Dồn kênh và phân kênh hướng kết nối
Để hiểu cơ chế dồn kênh trong TCP, chúng ta sẽ khảo sát socket TCP
và khởi tạo một kết nối TCP. Một sự khác biệt giữa socket TCP và
UDP là socket TCP sử dụng định danh bằng bộ bốn thông tin: địa chỉ
IP nguồn, cổng nguồn, địa chỉ IP đích đến, cổng đích đến. Do đó, khi
một host nhận một phân đoạn từ tầng mạng, host sử dụng cả bốn
thông tin này để chuyển (phân kênh) phân đoạn đó về socket tương
ứng. Ngược với UDP, hai phân đoạn TCP khác nhau IP nguồn hoặc
cổng nguồn sẽ được chuyển đến hai socket khác nhau. Để hiểu rõ hơn,
chúng ta xem lại ví dụ lập trình một ứng dụng TCP khách – chủ trong
mục VII, chương 2:
• Ứng dụng TCP chủ có một “socket mời” (welcomeSocket) để
chờ yêu cầu mở kết nối từ các TCP khách (hình 2.29) với cổng
là 6789.
• Ứng dụng TCP khách phát sinh một phân đoạn khởi tạo kết
nối bằng dòng lệnh:
Socket clientSocket = new Socket(“Tên Máy Chủ”, 6789);
• Yêu cầu mở một kết nối là một phân đoạn TCP với cổng đích
đến 6789 và bật bit khởi tạo kết nối trong header TCP (chi tiết
204
trong mục V). Phân đoạn khởi tạo kết nối cũng chứa cổng
nguồn được chọn tại ứng dụng khách. Dòng lệnh ở trên cũng
nhằm tạo ra một socket TCP cho tiến trình khách để tiến trình
này có thể truyền dữ liệu thông qua socket này.
• Khi hệ điều hành của máy tính chạy tiến trình chủ nhận một
phân đoạn yêu cầu khởi tạo kết nối với cổng đích đến 6789, nó
tìm tiến trình chủ đang chờ chấp nhận kết nối trên cổng 6789.
Sau đó, tiến trình chủ tạo mới một socket để quản lý cho kết
nối này.
• Tương tự, tầng vận chuyển tại máy chủ cũng xem xét bốn giá
trị sau trong phân đoạn yêu cầu khởi tạo kết nối: (1) cổng
nguồn, (2) địa chỉ IP của host nguồn, (3) cổng đích đến và (4)
địa chỉ IP đích đến. Socket mới tạo được định danh bằng bốn
thông tin này. Tất cả các phân đoạn đến có cổng nguồn, địa chỉ
IP nguồn, cổng đích đến và địa chỉ IP đích đến bằng với bốn
giá trị này sẽ được phân kênh về socket này. Từ lúc này, kết
nối TCP được thiết lập, tiến trình khách và chủ có thể gởi dữ
liệu cho nhau.
Máy chủ có thể hỗ trợ nhiều socket TCP đồng thời, mỗi socket đi kèm
cùng với một tiến trình và được định định danh bằng bộ bốn thông tin.
Khi một phân đoạn TCP đến một host, tất cả bốn trường dữ liệu (cổng
nguồn, địa chỉ IP nguồn, cổng đích đến và địa chỉ IP đích đến) được
sử dụng để chuyển trực tiếp (phân kênh) phân đoạn về socket tương
ứng.
205
Hình 3.5. Hai client dùng cùng cổng đích đến (80) để liên lạc cùng
ứng dụng Webserver
Xét ví dụ trong hình 3.5, host C khởi tạo hai phiên HTTP đến máy chủ
B, host A khởi tạo một phiên HTTP đến máy chủ B. Host A, host C và
server B có địa chỉ IP lần lượt là A, C và B. Host C ấn định hai cổng
khác nhau 26145 và 7532 cho hai kết nối HTTP. Do A chọn cổng độc
lập với C, A ấn định cổng 26145 cho kết nối HTTP trên máy A. Mặc
dù vậy, máy chủ B vẫn có thể phân kênh được cho dù hai kết nối có
cùng cổng nguồn bởi vì hai kết nối khác nhau địa chỉ IP nguồn.
Tiến trình Web chủ (web server) và TCP
Chúng ta khảo sát một host chạy tiến trình Web chủ (ví dụ Aapche
Web server) trên cổng 80. Khi các tiến trình khách (các trình duyệt,
browser) gởi các phân đoạn đến máy chủ, tất cả các phân đoạn đều có
cổng đích đến là 80. Đặc biệt, cả phân đoạn khởi tạo kết nối và phân
đoạn mang yêu cầu HTTP đều có cổng đích đến là 80. Như mô tả ở
trên, máy chủ sẽ phân biệt các phân đoạn từ các máy khách khác nhau
bằng cách dùng thông tin cổng nguồn và địa chỉ IP nguồn.
206
Hình 3.5 thể hiện một máy web chủ phát sinh một tiến trình mới cho
mỗi kết nối. Mỗi tiến trình được tạo ra sở hữu một socket kết nối riêng
và các gói tin yêu cầu hay phản hồi HTTP giữa máy khách và máy
chủ được truyền qua kết nối này. Tuy nhiên, không phải lúc nào tương
quan một một giữa các socket kết nối và tiến trình. Trong thực tế, các
ứng dụng web chủ ngày nay thường sử dụng một tiến trình và tạo ra
một tiểu trình mới cho một kết nối mới (ví dụ lập trình web chủ trong
chương 2 dùng kỹ thuật này). Một máy chủ như vậy có thể chấp nhận
nhiều kết nối tại bất kỳ thời điểm nào trong cùng một tiến trình.
Nếu máy khách và máy chủ sử dụng HTTP bền bỉ, khi máy khách và
máy chủ tạo một kết nối thì máy chủ và máy khách trao đổi các thông
điệp HTTP thông qua cùng socket. Tuy nhiên, nếu máy khách và máy
chủ sử dụng HTTP không bền bỉ, máy khách và máy chủ phải tạo kết
nối TCP cho mỗi cặp thông điệp yêu cầu và phản hồi, vì thế một
socket mới được tạo và đóng ngay sau đó cho mỗi cặp thông điệp yêu
cầu và phản hồi. Điều này dẫn đến web server luôn bận rộn với việc
tạo và đóng socket và có thể ảnh hưởng đến năng lực hoạt động của
server.
III. Giao thức vận chuyển phi kết nối UDP

Trong phần này, chúng ta sẽ khảo sát chi tiết giao thức UDP để trả lời
cho câu hỏi: UDP hoạt động như thế nào và thực hiện điều gì? Trước
khi đi vào chi biết, bạn nên xem lại mục I và VIII của chương 2 về
tổng quan mô hình dịch vụ UDP và cách lập trình sử dụng giao thức
UDP.
Trong phần này, chúng ta giả sử rằng chúng ta đang xem xét việc thiết
kế một giao thức vận chuyển khung sườn (bare-bone). Đặc biệt, chúng
ta cần xem xét hai quá trình: (1) bên gởi tiếp nhận thông điệp từ tiến
trình ứng dụng và chuyển trực tiếp chúng xuống tầng mạng; (2) bên
nhận nhận các thông điệp đến từ tầng mạng và chuyển trực tiếp chúng
đến tiến trình ứng dụng. Như đã trình bày trong phần trước, tầng vận
chuyển cần phải cung cấp tối thiểu dịch vụ dồn kênh và phân kênh để
chuyển dữ liệu giữa tầng mạng và tiến trình ứng dụng tương ứng.
207
Giao thức UDP, được định nghĩa trong tài liệu RFC 768, chỉ cung cấp
những dịch vụ tối thiểu mà tầng vận chuyển phải thực hiện. Giao thức
UDP chỉ thực hiện chức năng dồn kênh, phân kênh và kiểm tra lỗi.
Trong trường hợp, người phát triển ứng dụng chọn giao thức UDP
thay cho giao thức TCP thì ứng dụng gần như trao đổi trực tiếp với IP.
Giao thức UDP nhận thông điệp từ tiến trình ứng dụng, thêm thông tin
cổng nguồn, cổng đích đến phục vụ cho dịch vụ dồn kênh và phân
kênh và thêm hai trường dữ liệu nhỏ nữa rồi chuyển phân đoạn kết
quả xuống tầng mạng. Tầng mạng đóng gói phân đoạn tầng vận
chuyển trong một gói tin IP sau đó nỗ lực để chuyển phân đoạn đến
host nhận. Khi phân đoạn đến host nhận, giao thức UDP sử dụng
thông tin cổng đích đến để phân phối dữ liệu trong phân đoạn đến
đúng tiến trình ứng dụng. Và giao thức UDP không sử dụng cơ chế
bắt tay (handshaking) giữa bên nhận và bên gởi trước khi truyền phân
đoạn. Do đó, giao thức UDP được gọi là giao thức phi kết nối
(connectionless).
Giao thức DNS là một ví dụ cho giao thức tầng ứng dụng sử dụng
giao thức UDP ở tầng vận chuyển. Khi ứng dụng DNS muốn thực
hiện một câu truy vấn, nó tạo một thông điệp truy vấn DNS và chuyển
thông điệp cho giao thức UDP. Không cần thực hiện cơ chế bắt tay
với thực thể UDP đang chạy trên hệ thống đích đến, UDP bên gởi
thêm thông tin header vào thông điệp và chuyển phân đoạn kết quả
cho tầng mạng. Tầng mạng đóng gói thành một gói tin IP và gởi cho
máy chủ quản lý tên miền (name server). Ứng dụng DNS tại host truy
vấn chờ nhận trả lời cho câu truy vấn của nó. Nếu không nhận được
câu trả lời (điều này có thể xảy ra do tầng mạng làm mất câu truy vấn
hoặc câu trả lời), nó thử gởi câu truy vấn cho một máy chủ quản lý tên
miền khác hoặc báo không nhận được câu trả lời về ứng dụng.
Câu hỏi đặt ra là vì sao các ứng dụng vẫn chọn giao thức UDP thay
cho TCP? TCP có được chọn nhiều hơn khi TCP cung cấp dịch vụ
truyền dữ liệu đáng tin cậy trong khi UDP thì không? Câu trả lời là
không. Nhiều ứng dụng thích hợp dùng UDP hơn vì các lý do sau:
• Điều khiển ở mức ứng dụng: dữ liệu nào đã gởi và gởi khi
nào? Với UDP, khi ứng dụng chuyển dữ liệu cho UDP, UDP
đóng gói dữ liệu trong một phân đoạn và ngay lập tức chuyển
208
phân đoạn đó xuống tầng mạng. Ngược lại, do TCP sử dụng cơ

chế kiểm soát tắc nghẽn, TCP kìm hãm tốc độ gởi của bên gởi
khi có một hay nhiều liên kết giữa bên gởi và bên nhận xảy ra
tình trạng tắc nghẽn. TCP cũng gởi lại các phân đoạn cho đến
khi nhận được báo nhận cho phân đoạn đó từ bên nhận mà
không quan tâm thời gian gởi kéo dài trong bao lâu. Mặt khác,
các ứng dụng thời gian thực thường đòi hỏi tốc độ gởi dữ liệu
thấp, không chấp nhận độ trễ cao và chấp nhận mất mát dữ
liệu, do đó dịch vụ theo mô hình TCP không đáp ứng được các
yêu cầu này. Do đó, các ứng dụng này có thể sử dụng giao
thức UDP và cài đặt thêm một số chức năng hỗ trợ.
• Phi kết nối: TCP sử dụng cơ chế bắt tay 3 bước trước khi bắt
đầu truyền dữ liệu. Trong khi, UDP thì không cần thực hiện
bất kỳ thao tác nào. Vì thế UDP không bị tốn thêm chi phí độ
trễ cho việc thiết lập kết nối. Đây chính là một nguyên nhân vì
sao giao thức DNS không sử dụng TCP mà sử dụng UDP.
HTTP sử dụng TCP bởi vì tính tin cậy là cần thiết cho dữ liệu
dạng văn bản của một trang web. Và như đã thảo luận ở mục II
chương 2, độ trễ khi thiết lập kết nối TCP chiếm phần lớn
trong độ trễ khi tải một tài liệu web.
• Phi trạng thái: TCP quản lý trạng thái kết nối tại các hệ thống
đầu cuối. Trạng thái này bao gồm: bộ đệm gởi và nhận dữ liệu,
tham số kiểm soát tắc nghẽn, tham số số thứ tự (sequence
number) và báo nhận (acknowledgement number), chi tiết xem
mục V. Ngược lại, UDP không quản lý trạng thái kết nối và
không theo dõi các tham số này. Do đó, một ứng dụng chủ có
thể chủ động hỗ trợ được nhiều chương trình khách hơn nếu
chọn UDP.
• Kích thước header nhỏ. Phần header của mỗi phân đoạn TCP
chiếm 20 bytes trong khi UDP chỉ cần dùng 8 bytes.
Bảng 3.6 liệt kê danh sách các ứng dụng phổ biến và giao thức tầng
vận chuyển tương ứng. Các ứng dụng Thư điện tử, Truy cập từ xa,
Web, Truyền file chạy trên TCP. Các ứng dụng này có nhu cầu truyền
209
dữ liệu đáng tin cậy của giao thức TCP. Ngược lại, một số ứng dụng
quan trọng vẫn sử dụng UDP thay vì TCP. UDP được sử dụng trong
giao thức định tuyến RIP để cập nhật thông tin trong bảng định tuyến
(chi tiết xem mục VI.1 chương 4). RIP gởi thông tin cập nhật theo
định kỳ (ví dụ 5 phút một lần) do đó cho dù thông tin cập nhật có bị
mất mát thì chúng vẫn có thể được phục hồi bằng thông tin cập nhật
sau đó. Vì thế sẽ không xảy ra tình trạng mất mát thông tin và thông
tin bị lỗi thời. UDP cũng được sử dụng trong giao thức quản trị mạng
SNMP. UDP được sử dụng trong giao thức này bởi vì các ứng dụng
quản trị mạng thường phải hoạt động trong tình trạng mạng bị quá tải,
do đó việc truyền dữ liệu đáng tin cậy và kiểm soát tắc nghẽn khó có
thể đạt được. Tương tự, giao thức DNS cũng sử dụng UDP để giảm độ
trễ thiết lập kết nối.
Như ví dụ trong bảng 3.6, giao thức TCP và UDP đều được sử dụng
trong các ứng dụng đa phương tiện (multimedia) như điện thoại
Internet, hội thảo video thời gian thực, video và audio luồng. Các ứng
dụng này đều có khả năng chấp nhận mất một ít gói tin do đó việc
truyền dữ liệu đáng tin cậy không là một điều kiện quan trọng để ứng
dụng hoạt động tốt. Hơn nữa, các ứng dụng thời gian thực như điện
thoại Internet và hội thảo video phản ứng không tốt với cơ chế điều
kiển tắc nghẽn. Do đó, người phát triển ứng dụng đa phương tiện
thường chọn UDP thay vì TCP. Tuy nhiên, người phát triển ứng dụng
đa phương tiện theo luồng (streaming media) cũng đang chú ý đến
việc sử dụng TCP. Ví dụ, [Sripanidkulchai 2004] cho thấy gần 75%
các ứng dụng luồng trực tuyến và theo yêu cầu (on-demand and live
streaming) sử dụng TCP. Khi tỉ lệ mất gói trong mạng thấp và một số
tổ chức ngăn chặn gói tin UDP vì lý do bảo mật, các nhà phát triển
ứng dụng chú ý nhiều đến TCP hơn khi phát triển ứng dụng.
Ứng dụng Giao thức Giao thức

tầng ứng dụng tầng vận chuyển
Thư điện tử SMTP TCP
Truy cập từ xa telnet TCP
210
Web HTTP TCP

Truyền file FTP TCP
Máy chủ quản lý NFS UDP
tập tin từ xa
Multimedia luồng Tuỳ người cài đặt TCP hoặc UDP
Điện thoại Internet Tuỳ người cài đặt TCP hoặc UDP
(internet
telephony)
Quản trị mạng SNMP UDP
Giao thức định RIP UDP
tuyến
Phân giải tên miền DNS UDP
Bảng 3.6. Các ứng dụng phổ biến trên Internet và giao thức tầng vận
chuyển tương ứng.
Mặc dù vậy, việc sử dụng UDP trong các ứng dụng đa phương tiện
vẫn là một vấn đề đang tranh cãi. Như đã trình bày ở trên, UDP không
có cơ chế kiểm soát tắc nghẽn. Nhưng cơ chế kiểm soát tắc nghẽn cần
thiết để ngăn chặn mạng rơi vào trạng thái tắc nghẽn (trạng thái mà
hầu như các công việc có ích không được hoàn tất). Nếu mọi người
trong mạng đều muốn khởi tạo các luồng tốc độ cao mà không sử
dụng bất kỳ một cơ chế kiểm soát tắc nghẽn nào thì sẽ xảy ra tình
trạng có rất nhiều gói tin tràn qua bộ định tuyến dẫn đến rất ít gói tin
UDP có thể truyền thành công từ nguồn đến đích đến. Hơn nữa, tỉ lệ
mất gói cao gây ra bởi bên gởi UDP không kiểm soát được dẫn đến
các bên gởi TCP cũng giảm tỉ lệ gởi rất nhanh. Vì thế, việc thiếu cơ
chế kiểm soát tắc nghẽn trong UDP dẫn đến tỉ lệ mất gói cao giữa bên
gởi và bên nhận UDP và làm văng ra các kết nối TCP – đây là một
vấn đề rất nghiêm trọng [Floyd 1999]. Nhiều nhà nghiên cứu đã đề
xuất một cơ chế mới để bắt buộc tất cả các nguồn gởi, kể cả nguồn gởi
211
UDP, phải thực hiện cơ chế kiểm soát tắc nghẽn thích hợp [.Mahdavi
1997; Floyd 2000; Kohler 2006: RFC 4340].
Một điểm cần lưu ý là một ứng dụng sử dụng UDP có thể truyền dữ
liệu đáng tin cậy nếu như ứng dụng tự xây dựng cơ chế này (ví dụ tự
gởi thông điệp báo nhận và gởi lại khi phát hiện mất thông tin).
Nhưng, điều này không quan trọng để người phát triển ứng dụng phải
bận rộn với việc dò lỗi trong thời gian dài. Hơn nữa, việc xây dựng cơ
chế truyền dữ liệu đáng tin cậy trong ứng dụng cho phép ứng dụng tự
kiểm soát và tự liên lạc tin cậy với nhau mà không bị ràng buộc bởi tỉ
lệ gởi được qui định trong cơ chế kiểm soát tắc nghẽn của TCP.
III.1 Cấu trúc một phân đoạn UDP
Cấu trúc một phân đoạn UDP được trình bày trong hình 3.7. Trong đó,
trường checksum quyết định các bit dữ liệu trong phân đoạn UDP có
bị thay đổi hay không (do nhiễu trong các liên kết hoặc trong khi lưu
trú tại các bộ định tuyến) khi nó di chuyển từ nguồn đến đích đến.
UDP tại bên gởi thực hiện phép bù 1 trên tổng của tất cả các số 16 bits
trong phân đoạn (nếu trong quá trình tính tổng bị tràn, bit tràn được
mang xuống cộng tiếp). Kết quả này được gán cho trường checksum
trong phân đoạn UDP. Chi tiết cách cài đặt checksum hiệu quả có thể
tham khảo trong RFC 1071. Bên dưới là một ví dụ đơn giản về cách
tính checksum với 3 số 16 bits:
0110011001100000
0101010101010101
1000111100001100
Kết quả khi tính tổng 2 số đầu tiên:

0110011001100000
0101010101010101
1011101110110101
212
Kết quả tính tổng của số thứ 3 với tổng 2 số đầu tiên
1011101110110101
1000111100001100
0100101011000010
Lần tính tổng cuối cùng bị tràn số (kết quả phép cộng:
10100101011000001), do đó chúng ta tiếp tục cộng bit tràn (bit 1 cao
nhất) với phần còn lại (0100101011000001) để được giá trị tổng cuối
cùng. Và giá trị bù 1 của tổng 0100101011000010 là
1011010100111101, đây chính là giá trị checksum. Nếu như gói tin
không có lỗi, thì giá trị tổng (kể cả checksum) tại bên nhận là
1111111111111111; ngược lại nếu có bit 0 xuất hiện trong tổng tại
bên nhận thì gói tin có lỗi.
Hình 3.7. Cấu trúc phân đoạn UDP

Vì sao UDP cũng sử dụng checksum trong khi nhiều giao thức tầng
liên kết (kể cả giao thức phổ biến là Ethernet) đã cung cấp cơ chế
kiểm tra lỗi? Một nguyên nhân là do không có gì đảm bảo rằng tất cả
các liên kết (link) từ bên gởi đến bên nhận luôn luôn cung cấp cơ chế
kiểm tra lỗi. Hơn nữa, nếu như các phân đoạn không bị lỗi khi truyền
qua các liên kết, thì lỗi bit cũng có thể xảy ra khi phân đoạn được lưu
trữ trong bộ nhớ của các bộ định tuyến. Do đó, với giả thiết hoặc lỗi
213
xảy ra trên các liên kết hoặc lỗi xảy ra khi lưu trữ trong bộ nhớ của bộ
định tuyến, UDP phải cung cấp cơ chế kiểm ra lỗi tại tầng vận chuyển.
Bởi vì giả định rằng IP chạy trên bất kỳ giao thức tầng 2, tầng vận
chuyển cung cấp cơ chế kiểm tra lỗi là một điều cần thiết. Tuy nhiên,
UDP cung cấp cơ chế kiểm tra lỗi nhưng lại không cung cấp bất kỳ cơ
chế nào để khắc phục khi có lỗi xuất hiện. Một số phiên bản cài đặt
của UDP chỉ đơn giản huỷ bỏ các phân đoạn bị hư; một số phiên bản
khác thì vẫn chuyển cho ứng dụng kèm theo một cảnh báo.
IV. Các nguyên lý truyền dữ liệu đáng tin cậy

Trong phần này, chúng ta sẽ thảo luận tổng quan về vấn đề truyền dữ
liệu đáng tin cậy. Bởi vì, vấn đề truyền dữ liệu đáng tin cậy không chỉ
xuất hiện trong tầng vận chuyển mà còn xuất hiện trong tầng liên kết
dữ liệu và tầng ứng dụng. Sau đó, chúng ta sẽ khảo sát chi tiết giao
thức TCP để tìm hiểu xem TCP khai thác các nguyên lý truyền dữ liệu
đáng tin cậy như thế nào.
Chúng ta dùng mô hình trong hình 3.8 để khảo sát bài toán truyền dữ
liệu đáng tin cậy. Dịch vụ trừu tượng (service abstraction) cung cấp
cho các thực thể ở tầng trên một kênh truyền đáng tin cậy. Dữ liệu
truyền trên kênh truyền đáng tin cậy này không bị lỗi bit (bit 0 bị đổi
thành bit 1 hoặc bit 1 bị đổi thành bit 0) hay bị mất gói và được truyền
đúng thứ tự như đã gởi.
Một giao thức truyền dữ liệu đáng tin cậy phải cài đặt một dịch vụ
trừu tượng như thế. Điều này khó bởi vì tầng bên dưới giao thức
truyền dữ liệu đáng tin cậy có thể không đáng tin cậy. Ví dụ, giao thức
TCP là một giao thức truyền dữ liệu đáng tin cậy được cài đặt trên
giao thức tầng mạng không đáng tin cậy IP.
214
Hình 3.8. Truyền dữ liệu đáng tin cậy: mô hình dịch vụ và cài đặt dịch
vụ
Trong phần này, chúng ta sẽ phát triển dần giao thức bên gởi và bên
nhận để khảo sát mức độ gia tăng độ phức tạp của kênh truyền bên
dưới. Hình 3.8b minh hoạ các thể hiện (interface) cho giao thức truyền
dữ liệu. Bên gởi của giao thức truyền dữ liệu sẽ được kích hoạt từ tầng
trên thông qua lời gọi hàm rdt_send(). Nó sẽ truyền dữ liệu đi để
chuyển lên tầng trên tại bên nhận. Bên nhận, hàm rdt_rcv() sẽ được
gọi khi một gói tin đến từ kênh truyền của bên nhận. Giao thức truyền
dữ liệu đáng tin cậy chuyển dữ liệu lên tầng trên bằng cách gọi hàm
deliver_data().
Trong phần này, chúng ta chỉ xem xét việc truyền dữ liệu đơn hướng
(unidirectional data transfer). Nghĩa là, dữ liệu chỉ truyền một chiều từ
bên gởi sang bên nhận. Trường hợp truyền dữ liệu song hướng
(bidirectional data transfer, duplex) thì không phức tạp hơn nhiều, tuy
nhiên cách giải thích cần điều chỉnh cho phù hợp.
215
IV.1 Xây dựng giao thức truyền dữ liệu đáng tin cậy
Truyền dữ liệu đáng tin cậy qua kênh truyền lý tưởng: rdt1.0
Đầu tiên, chúng ta xem xét trường hợp đơn giản nhất: kênh truyền bên
dưới tuyệt đối tin cậy (không xuất hiện lỗi bit và không bị mất gói). Vì
thế giao thức rdt1.0 được xem là một thử nghiệm. Trong nghi thức
rdt1.0, trạng thái (finite-state-machine, viết tắt FSM) cho bên gởi và
bên nhận được thể hiện trong hình 3.9. Trạng thái trong hình 3.9a và
3.9b lần lượt định nghĩa hành vi của bên gởi và bên nhận theo thứ tự.
Lưu ý rằng, các trạng thái bên gởi và bên nhận hoàn toàn riêng biệt
nhau. Mỗi bên gởi và bên nhận trong nghi thức rdt1.0 chỉ có duy nhất
một trạng thái, thể hiện bằng hình tròn trong hình 3.9. Hình mũi tên
thể hiện sự chuyển tiếp từ trạng thái này sang trạng thái khác và sự
kiện gây ra sự chuyển tiếp được thể hiện bằng các nhãn phía trên
đường gạch ngang trên hình mũi tên và hành động sẽ thực thi sau đó
xuất hiện bên dưới đường gạch ngang. Ký hiệu ^ thể hiện không có
hành động nào xảy ra hoặc không có sự kiện nào xảy ra. Trạng thái
khởi tạo thể hiện bằng hình mũi tên không liền nét.
Tại bên gởi, rdt chỉ đơn giản nhận dữ liệu từ tầng trên với sự kiện
rdt_send(data) rồi tạo một gói tin chứa dữ liệu data (packet =
make_pkt(data)) và gởi gói tin xuống kênh truyền (udt_send(packet)).
Thực tế, sự kiện rdt_send(data) là kết quả của lời gọi hàm từ ứng dụng
tầng trên.
Tại bên nhận, rdt nhận gói tin từ kênh truyền bên dưới bằng sự kiện
rdt_rcv(packet), lấy dữ liệu data từ gói tin (extract(packet, data)) và
chuyển dữ liệu lên tầng trên (deliver_data(data)). Thực tế, sự kiện
rdt_rcv(packet) là kết quả của lời gọi hàm từ giao thức tầng dưới.
Trong giao thức đơn giản này, không có sự khác biệt giữa hai đơn vị
dữ liệu: data và packet. Bên cạnh đó, luồng gói tin truyền từ bên gởi
đến bên nhận với một kênh truyền lý tưởng nên bên nhận không cần
phải cung cấp bất kỳ thông tin phản hồi cho bên gởi bởi vì dữ liệu
không bị sai lệch. Lưu ý, chúng ta giả sử rằng bên nhận có thể nhận
dữ liệu bằng tốc độ bên gởi. Vì thế, bên nhận không cần phải gởi yêu
cầu bên gởi giảm tốc độ gởi dữ liệu.
216
Hình 3.9. Rdt 1.0 – một giao thức cho một kênh truyền đáng tin cậy
Truyền dữ liệu đáng tin cậy qua kênh truyền có lỗi bit: rdt2.0
Một mô hình gần thực tế hơn với kênh truyền có thể làm sai lệch
thông tin các bit dữ liệu của gói tin. Về cơ bản, bit lỗi thường xuất
hiện khi gói tin truyền lên đường truyền, di chuyển trên đường truyền
hoặc lưu trữ trong bộ đệm. Trong trường hợp này, chúng ta giả sử
rằng các gói tin vẫn đến đúng thứ tự như đã gởi cho dù các bit dữ liệu
có bị lỗi hay không.
Trước khi phát triển một giao thức truyền đáng tin cậy qua kênh
truyền như thế, chúng ta sẽ xét xem con người khắc phục lỗi này như
thế nào. Xét trường hợp, hai người A và B gọi điện cho nhau. B nhận
một thông điệp dài từ A. B sẽ nói “ừ” sau khi B nghe hết, hiểu và ghi
nhớ một câu. Nếu B nghe không rõ, B sẽ yêu cầu A “lặp lại” câu đó.
Trong ví dụ này, giao thức trao đổi giữa A và B dùng cả hai thông
điệp “ừ” (báo nhận tích cực – positive acknowledgment - ACK) và
“lặp lại” (báo nhận tiêu cực – negative acknowledgment - NAK). Cả
hai thông điệp điều khiển này cho phép người nghe phản hồi cho
người nói biết rằng họ đã nhận được thông tin chính xác hoặc yêu cầu
gởi lại khi thông tin không chính xác. Trong thiết lập của mạng máy
tính, giao thức truyền dữ liệu đáng tin cậy cũng dựa trên cơ chế truyền
217
lại như thế, được gọi là giao thức Tự động yêu cầu lặp lại (ARQ –
Automatic Repeat reQuest).
Về cơ bản, một giao thức ARQ cần có ba chức năng sau để kiểm soát
lỗi bit:
• Phát hiện lỗi: cho phép bên nhận phát hiện khi nào gói tin nhận
bị lỗi bit. Phương pháp checksum mà UDP sử dụng là một ví
dụ (một số phương pháp khác sẽ được trình bày trong chương
5).
• Báo nhận từ bên nhận: do bên gởi và bên nhận thực thi tại hai
điểm đầu cuối khác nhau nên chỉ có một cách để bên gởi biết
được thông tin của bên nhận là bên nhận dùng một cơ chế báo
nhận cho bên gởi rõ ràng. Báo nhận tích cực (ACK) – “ừ” và
báo nhận tiêu cực (NAK) – “lặp lại” trong ngữ cảnh trao đổi
thông điệp ở trên là một ví dụ. Giao thức rdt2.0 sẽ dùng gói tin
ACK và NAK tương tự như vậy để bên nhận gởi về cho bên
gởi. Theo lý thuyết, gói tin báo nhận này chỉ cần 1 bit: 1 nghĩa
là ACK và 0 nghĩa là NAK.
• Gởi lại: bên gởi sẽ gởi lại gói tin bị phát hiện có lỗi bit tại bên
nhận.
Hình 3.10 biểu diễn các trạng thái FSM của giao thức rdt2.0, một giao
thức truyền dữ liệu có các chức năng phát hiện lỗi, báo nhận tích cực
và báo nhận tiêu cực.
Bên gởi của rdt2.0 có hai trạng thái như hình 3.10a. Ở trạng thái bên
tay trái, bên gởi đang chờ dữ liệu từ tầng trên. Khi sự kiện
rdt_send(data) xảy ra, bên gởi sẽ tạo một gói tin sndpkt chứa dữ liệu
này cùng với checksum của gói tin, sau đó gởi gói tin này bằng thao
tác udt_send(sndpkt). Với trạng thái bên tay phải, bên gởi đang chờ
nhận gói tin ACK hay NAK từ bên nhận. Nếu bên gởi nhận được gói
tin ACK (với sự kiện rdt_rcv(rcv_pkt) && isACK(rcvpkt) trong hình
3.10), bên gởi biết rằng bên nhận đã nhận được dữ liệu chính xác và
trở về trạng thái chờ nhận dữ liệu từ tầng trên ban đầu. Ngược lại,
trong trường hợp bên gởi nhận được gói tin NAK từ bên nhận (với sự
kiện rdt_rcv(rcv_pkt) && isNAK(rcvpkt) trong hình 3.10), bên gởi sẽ
gởi lại gói tin cuối cùng đã gởi và chờ báo nhận cho gói tin này. Lưu ý
218
rằng, khi bên gởi ở trạng thái chờ nhận gói tin ACK hay NAK, bên
gởi không thể nhận dữ liệu từ tầng trên, nghĩa là sự kiện rdt_send()
không xuất hiện. Sự kiện rdt_send() chỉ xuất hiện sau khi bên gởi đã
nhận được báo nhận từ bên nhận và chuyển sang trạng thái khác. Vì
thế, bên gởi sẽ không gởi dữ liệu mới cho đến khi biết chắc chắn rằng
bên nhận đã nhận chính xác gói tin hiện hành. Do đó, giao thức rdt2.0
còn được gọi là giao thức “dừng và chờ” (stop and wait).
Hình 3.10. Rdt2.0 – một giao thức cho kênh truyền có lỗi bit
Bên nhận trong giao thức rdt2.0 vẫn chỉ có một trạng thái như hình
3.10b. Khi có một gói tin đến, bên nhận gởi cho bên gởi gói tin báo
nhận ACK hay NAK phụ thuộc vào gói tin nhận được có lỗi bit hay
không. Trong hình 3.10, dấu hiệu rdt_rcv(rcvpkt) && corrupt(rcvpkt)
tương ứng sự kiện bên nhận nhận được một gói tin và phát hiện gói tin
có lỗi bit.
219
Bằng cơ chế này, rdt2.0 có thể truyền dữ liệu đáng tin cậy qua kênh
truyền có lỗi bit. Tuy nhiên, giao thức rdt2.0 vẫn còn một lỗ hổng: gói
tin ACK và NAK có thể bị lỗi bit. Một giải pháp tối thiểu mà chúng ta
có thể dùng là thêm thông tin checksum vào gói tin ACK và NAK.
Vấn đề đặt ra là giao thức rdt2.0 giải quyết như thế nào khi lỗi xảy ra
trên gói báo nhận ACK và NAK. Trong trường hợp này, bên gởi sẽ
không biết được bên nhận nhận được thông tin gởi cuối cùng chính
xác hay không.
Chúng ta xét ba giải pháp sau để giải quyết khi gói tin báo nhận ACK
hoặc NAK bị lỗi:
• Giải pháp 1: trong ngữ cảnh trao đổi thông điệp giữa A và B ở
trên, nếu A không hiểu B nói “uh” hay “lặp lại”, A có thể hỏi
lại “anh đã nói gì?” (định nghĩa một loại thông điệp mới cho
giao thức). Tuy nhiên, nếu B lại không nghe rõ, B lại hỏi A
“anh đã nói gì?”. Và A cũng có thể không nghe được câu báo
nhận này. Rõ ràng, trong trường hợp này, chúng ta gặp một
tình huống khó khăn hơn.
• Giải pháp 2: bên gởi thêm thông tin vào gói tin gởi đi để bên
nhận có thể phục hồi lại dữ liệu nếu như phát hiện có lỗi bit
xảy ra trong gói tin nhận được. Giải pháp này có thể giải quyết
được vấn đề này cho các kênh truyền đảm bảo không bị mất
gói.
• Giải pháp 3: bên gởi chỉ đơn giản gởi lại gói tin cuối cùng nếu
nhận được gói tin báo nhận ACK hay NAK bị lỗi. Tuy nhiên,
kênh truyền giữa bên gởi và bên nhận xuất hiện gói tin trùng.
Vấn đề khó cơ bản khi giải quyết gói tin trùng là bên nhận
không biết gói tin báo nhận ACK hay NAK đã được bên gởi
nhận chính xác hay không nên bên nhận không biết gói tin mới
đến là gói tin mới hay gói tin được truyền lại.
Một giải pháp đơn giản để giải quyết vấn đề này (và được tích hợp
trong hầu hết các giao thức truyền dữ liệu đang tồn tại, kể cả TCP) là
bên gởi thêm một trường thông tin mới vào gói tin: số thứ tự
(sequence number) của gói tin dữ liệu. Bên nhận chỉ cần kiểm tra
trường số thứ tự này để quyết định gói tin nhận là gói tin mới hay gói
220
tin được truyền lại. Trong trường hợp này, giao thức dừng-và-chờ chỉ
cần dùng 1 bit cho trường số thứ tự. Bên nhận biết được gói tin nhận
là gói tin mới (số thứ tự của gói tin nhận khác số thứ tự của gói tin
nhận được trước đó) hay gói tin được truyền lại (số thứ tự của gói tin
nhận bằng số thứ tự của gói tin nhận được trước đó). Bởi vì chúng ta
giả định kênh truyền không bị mất gói, gói tin ACK và NAK không
cần bổ sung số thứ tự của gói tin đang phản hồi. Bên nhận tự biết gói
tin ACK hay NAK mới đến là gói tin tin phản hồi cho gói tin vừa gởi.
Hình 3.11. Bên gởi của giao thức rdt2.1

Hình 3.11 và 3.12 lần lượt biểu diễn trạng thái FSM của bên gởi và
bên nhận giao thức rdt2.1. Số trạng thái mỗi bên đều gấp 2 lần số
trạng thái trước đây. Bởi vì mỗi bên phải ghi nhớ số thứ tự của gói tin
đang gởi (bên gởi) và đang mong chờ (bên nhận) là 0 hay 1. Các hành
động trong mỗi trạng thái với số thứ tự là 0 hay 1 là như nhau, chỉ
khác nhau số thứ tự của gói tin đang xử lý.
Giao thức rdt2.1 sử dụng cả hai gói tin báo nhận tích cực và tiêu cực
để bên nhận gởi phản hồi cho bên gởi. Khi bên nhận nhận một gói tin
không đúng thứ tự, bên nhận gởi một báo nhận tích cực, ACK, cho gói
221
tin mà nó nhận. Ngược lại khi nhận một gói tin có lỗi, bên nhận gởi
một báo nhận tiêu cực, NAK.
Hình 3.12. Bên nhận của rdt2.1

Chúng ta có thể thay thế gói tin NAK bằng gói tin ACK cho gói tin
cuối cùng nhận chính xác. Trong trường hợp này, khi bên gởi nhận 2
gói tin ACK cho cùng gói tin đã gởi (nhận ACK trùng), bên gởi biết
rằng bên nhận đã nhận không chính xác gói tin sau gói tin được ACK
hai lần. Giao thức truyền dữ liệu đáng tin cậy trên kênh truyền có lỗi
bit mà không dùng NAK là rdt2.2, hình 3.13 và 3.14. Một thay đổi
nhỏ giữa rdt2.1 và rdt2.2 là bên nhận phải thêm số thứ tự của gói tin
đang được phản hồi trong thông điệp ACK và bên gởi phải kiểm tra số
thứ tự của gói tin đang được ACK trong gói tin ACK.
Truyền dữ liệu đáng tin cậu qua kênh truyền bị mất gói và lỗi bit:
rdt3.0
Bây giờ chúng ta giả sử rằng kênh truyền ngoài bị lỗi bit còn bị mất
gói (một sự kiện không phổ biến trong mạng máy tính ngày nay, kể cả
Internet). Hai vấn đề cần được giải quyết thêm trong giao thức: (1)
làm thế nào để phát hiện mất gói và (2) làm gì khi có hiện tượng mất
gói xảy ra. Việc sử dụng checksum, số thứ tự, gói tin ACK, và gởi lại
gói tin (kỹ thuật sử dụng trong rdt2.2) có thể giải quyết vấn đề thứ hai.
Với vấn đề đầu tiên, chúng ta cần phải thêm một cơ chế mới vào giao
thức.
222
Hình 3.13. Bên gởi của giao thức rdt2.2

Có nhiều giải pháp có thể giải quyết được vấn đề mất gói tin. Ở đây
chúng ta sẽ đặt giải pháp phát hiện và phục hồi mất gói tại bên gởi.
Giả sử rằng, bên gởi gởi một gói tin và gói tin đó hoặc gói tin phản hồi
của gói tin đó bị mất. Cho dù xảy ra trường hợp nào, bên gởi không
nhận được phản hồi từ bên nhận. Bên gởi sẽ chờ phản hồi một khoảng
thời gian đủ lâu để chắc chắn rằng gói tin đã bị mất, nó sẽ gởi lại gói
tin đó. Tuy nhiên, bên gởi phải chờ bao lâu để biết chắc rằng gói tin đã
bị mất? Rõ ràng, bên gởi phải chờ một khoảng thời gian ít nhất bằng
thời gian trễ một vòng (round trip delay) giữa bên gởi và bên nhận
cùng với thời gian xử lý tại bên nhận. Tuy nhiên, rất khó để ước lượng
thời gian trễ lớn nhất trong một mạng. Giao thức nên phục hồi việc
mất gói càng sớm càng tốt, việc đợi đến hết thời gian trễ lớn nhất có
thể quá lâu để khởi tạo phục hồi lỗi. Vì thế, trong thực tế, bên gởi
chọn chờ trong một khoảng thời gian (mặc dù có thể chưa xảy ra hiện
tượng mất gói), nếu trong khoảng thời gian này bên gởi vẫn chưa nhận
được gói tin phản hồi, bên gởi sẽ gởi lại gói tin. Nếu độ trễ một gói tin
lớn, bên gởi có thể gởi lại gói tin trong khi gói tin đó hay gói tin phản
hồi cho gói tin đó không bị mất. Nghĩa là có thể xảy ra hiện tượng
trùng gói tin ACK trong kênh truyền giữa bên gởi và bên nhận. Và
giao thức rdt2.2 đã có đủ các chức năng để kiểm soát được vấn đề
này: số thứ tự trong gói tin ACK.
223
Hình 3.14. Bên nhận giao thức rdt2.2

Với bên gởi, giải pháp truyền lại là một giải pháp có thể giải quyết
được nhiều vấn đề. Bên gởi không cần biết gói tin hay gói tin ACK
cho gói tin bị mất hay độ trễ của các gói tin này lớn, bên gởi chỉ gởi
lại gói tin cho tất cả các trường hợp. Việc cài đặt cơ chế truyền lại dựa
trên thời gian đòi hỏi phải có một bộ đếm thời gian ngược có thể ngắt
bên gởi sau khi hết một khoảng thời gian cho trước. Bên gởi có thể (1)
bật đồng hồ cho mỗi gói tin đã gởi (hoặc là gói tin đầu tiên hoặc gói
tin truyền lại), (2) phản hồi mỗi khi đồng hồ ngắt (thực thi hành động
tương ứng) và (3) dừng bộ đếm thời gian.
Hình 3.15 minh hoạ trạng thái bên nhận giao thức rdt3.0, một giao
thức truyền dữ liệu đáng tin cậy qua kênh truyền có lỗi bit và mất gói.
Hình 3.16 minh hoạ giao thức xử lý như thế nào khi không xảy ra mất
gói hay gói tin bị trễ cũng như khi có mất gói. Trong hình 3.16b-d,
ngoặc vuông tại bên gởi chỉ định thời gian được thiết lập và hết thời
gian chờ (timeout). Bởi vì số thứ tự của gói tin thay đổi giữa 0 và 1,
giao thức rdt3.0 đôi khi được biết như một giao thức thay đổi bit.
Tóm lại, các yếu tố quan trọng của giao thức truyền dữ liệu đáng tin
cậy là checksum, số thứ tự, bộ đếm thời gian và gói tin báo nhận tích
224
cực, ACK và tiêu cực, NAK. Mỗi yếu tố đóng một vai trò quan trọng
và cần thiết trong giao thức.
Hình 3.15. Bên gởi rdt3.0

IV.2 Các giao thức truyền dữ liệu đáng tin cậy Pipelined
Giao thức rdt3.0 là một giao thức đúng chức năng, nhưng nó hoạt
động không hiệu quả đặc biệt trong môi trường mạng tốc độ cao.
Nguyên nhân chủ yếu là do giao thức rdt3.0 là một giao thức dừng và
chờ.
Xét ví dụ truyền dữ liệu giữa hai host, một ở Khoa Công nghệ thông
tin và một ở Khoa Toán tin thuộc Trường ĐH KHTN Tp. HCM như
hình 3.17. Thời gian trễ một vòng trên đường truyền giữa hai điểm
đầu cuối, RTT, tương đương 30ms. Giả sử rằng, hai điểm đầu cuối nối
với nhau bằng một kênh truyền với tốc độ truyền, R = 1Gbps (109
bps). Kích thước một gói tin, L= 1000 bytes (8000 bits) bao gồm cả
các trường header và dữ liệu. Thời gian truyền gói tin lên đường
truyền, Dtrans, là:
225
L 8000 bits
D = = = 8microgiây
trans
R 10 9 bps
Hình 3.16. Thao tác của rdt3.0, một giao thức trao đổi bit
226
Hình 3.17. So sánh giao thức “dừng và chờ” và giao thức pipelined
Hình 3.18a cho thấy rằng với giao thức “dừng và chờ”, nếu bên gởi
bắt đầu gởi một gói tin tại thời điểm t = 0, sau đó tại thời điểm t = 8
microseconds, bit cuối cùng mới vào kênh truyền tại bên gởi. Và
khoảng 15ms để gói tin di chuyển từ bên gởi đến bên nhận, bit cuối
cùng của gói tin đến được bên nhận tại thời điểm t = RTT/2 + L/R =
15.008ms. Để đơn giản, chúng ta giả sử rằng gói tin ACK cực kỳ nhỏ
để bỏ qua thời gian truyền gói tin ACK lên đường truyền và bên nhận
gởi ngay gói tin ACK khi bit cuối cùng của gói tin đến bên nhận. Gói
tin ACK đến bên gởi tại thời điểm t = RTT + L/R = 30.008ms. Đến
thời điểm này, bên gởi mới có thể truyền tiếp gói tin mới. Vì thế,
trong 30.008ms, bên gởi chỉ gởi 0.008ms. Nếu chúng ta định nghĩa
hàm tối ưu hoá kênh truyền cho bên gởi bằng tỷ lệ thời gian bên gởi
thật sự dùng để gởi gói các bit dữ liệu lên kênh truyền thì dựa trên
phân tích hình 3.18a, giao thức “dừng và chờ” tối ưu bên gởi kém
hơn, Usender:
L/ R 0.008
U = = = 0.00027
sender
RTT + L / R 30.008
Điều này cho thấy rằng bên gởi chỉ thật sự bận rộn trong vòng 2.7%
của 1% thời gian. Hay nói cách khác, bên gởi chỉ có thể gởi 1000bytes
trong 30.008ms và hiệu quả sử dụng băng thông là 267kbps mặc dù
tốc độ đường truyền là 1Gbps. Đây là một ví dụ sinh động về sự giới
hạn của một giao thức như thế nào so với khả năng của phần cứng
mạng bên dưới. Tương tự vậy, chúng ta cũng gặp các nút cổ chai do
thời gian xử lý của các giao thức tầng dưới tại bên gởi và bên nhận, độ
227
trễ do hàng đợi và xử lý tại các bộ định tuyến trung gian. Tất cả các
yếu tố này đều là nguyên nhân gây ra độ trễ cao và làm giảm hiệu
năng của hệ thống.
Hình 3.18. Gởi bằng giao thức “dừng và chờ” và pipelined
228
Giải pháp cho bài toán hiệu năng trong trường hợp này đơn giản: thay
vì sử dụng cơ chế “dừng và chờ”, bên gởi được phép gởi nhiều gói tin
mà không chờ nhận gói tin báo nhận như hình 3.17b. Hình 3.18b cho
thấy rằng nếu bên gởi được phép gởi 3 gói trước khi được báo nhận từ
bên nhận thì bên gởi sẽ đạt tối ưu hơn gấp 3 lần. Do các gói tin đang
truyền giữa bên gởi và bên nhận có thể hình dung như đang đổ vào
một ống dẫn, nên kỹ thuật này được gọi là ống dẫn (pipelining). Kỹ
thuật ống dẫn kéo theo một số hệ quả sau cho giao thức truyền dữ liệu
đáng tin cậy:
• Tăng dãy số thứ tự: bởi vì mỗi gói tin phải có một số thứ tự
duy nhất và cùng lúc có nhiều gói tin được truyền nhưng chưa
được báo nhận từ bên nhận
• Bên gởi và bên nhận phải có bộ đệm có thể chứa nhiều hơn
một gói tin. Tối thiểu, bên gởi phải có bộ đệm để chứa các gói
tin đã gởi nhưng chưa được báo nhận. Việc lưu tạm các gói tin
đã nhận đúng tại bên nhận cũng cần thiết.
• Dãy số thứ tự cần và yêu cầu lưu tạm trong bộ đệm sẽ phụ
thuộc vào cách xử lý gói tin bị mất, bị lỗi hay độ trễ lớn. Hai
giải pháp cơ bản mà kỹ thuật ống dẫn dùng để phục hồi lỗi là:
Quay lui (Go-Back-N) và gởi lại có chọn (selective repeat)
IV.3 Giao thức quay lui (Go-Back-N)
Trong giao thức quay lui (Go-Back-N, GBN), bên gởi được phép gởi
nhiều gói tin mà không cần chờ báo nhận nhưng không được vượt quá
một ngưỡng cho phép N.
Hình 3.19. Số thứ tự trong giao thức quay lui (GBN) từ phía gởi
229
Hình 3.19 biểu diễn dãy số thứ tự trong giao thức quay lui từ phía gởi.
Số thứ tự cơ sở, base, được định nghĩa là số thứ tự của gói tin cũ nhất
đã được báo nhận và số thứ tự tiếp theo, nextSeq, là số thứ tự nhỏ nhất
chưa dùng (nghĩa là số thứ tự của gói tin tiếp theo sẽ gởi). Số thứ tự
trong khoảng giá trị [0, base-1] tương ứng với các gói tin đã gởi và đã
nhận được báo nhận. Số thứ tự trong khoảng giá trị [base, nextSeq-1]
tương tứng các gói tin đã gởi nhưng chưa được báo nhận. Số thứ tự
trong khoảng [nextSeq, base+N-1] có thể dùng cho các gói tin có thể
gởi ngay khi nhận dữ liệu từ tầng trên. Cuối cùng, các số thứ tự lớn
hơn base+N không thể dùng cho đến khi một gói tin chưa được báo
nhận trong ống dẫn (cụ thể, gói tin có số thứ tự bằng base) được báo
nhận.
Trong hình 3.19, dãy các số thứ tự cho phép gởi nhưng chưa được báo
nhận được xem như một cửa sổ (window) với kích thước là N. Khi
giao thức hoạt động, cửa sổ này sẽ trượt dọc theo miền giá trị của số
thứ tự. Do đó, N thường được gọi là kích thước cửa sổ và giao thức
quay lui còn được xem như giao thức trượt cửa sổ. Vì sao chúng ta
cần giới hạn số gói tin được phép gởi khi chưa báo nhận là N? Một
nguyên nhân là do cơ chế kiểm soát luồng, chi tiết xem mục V. Còn
một lý do khác nữa sẽ được trình bày trong phần giới thiệu cơ chế
kiểm soát tắc nghẽn của giao thức TCP, mục VII.
Hình 3.20. Mở rộng trạng thái của bên gởi GBN
230
Trong thực tế, số thứ tự của gói tin được đóng gói trong một trường có
kích thước cố định trong phần header của gói tin. Gọi k là số bit trong
trường số thứ tự, số thứ tự của gói tin nằm trong khoảng [0, 2k-1].
Hình 3.20 và 3.21 mở rộng trạng thái của bên gởi và bên nhận của
giao thức quay lui có dùng gói tin ACK và không dùng gói tin NAK.
Chúng ta xem các trạng thái này như một mở rộng bởi vì chúng ta đã
thêm một số tham số: base, nextSeq và một số thao tác dựa trên các
tham số này.
Hình 3.21. Mở rộng trạng thái của bên nhận giao thức quay lui
Bên gởi giao thức quay lui phải hồi đáp cho ba sự kiện xảy ra:
• Gọi hàm từ tầng trên. Khi hàm rdt_send() được gọi từ tầng
trên, trước tiên bên gởi phải kiểm tra xem cửa sổ đầy hay
không (nghĩa là đã quá N gói tin đã gởi nhưng chưa được báo
nhận). Nếu cửa sổ chưa đầy, bên gởi tạo một gói tin và gởi nó
đi, đồng thời cập nhật lại giá trị các tham số. Ngược lại, cửa sổ
đầy, bên gởi chỉ thực hiện thao tác đơn giản là trả dữ liệu
ngược về tầng trên. Tầng trên sẽ gọi lại hàm rdt_send() sau đó.
• Nhận gói tin báo nhận ACK. Trong giao thức quay lui, gói tin
ACK với số thứ tự N mang ý nghĩa báo nhận tổng hợp
(cumulative acknowledgment). Nghĩa là, tất cả các gói tin có
231
số thứ tự nhỏ hơn hay bằng N đã được bên nhận nhận chính
xác.
• Hết thời gian chờ, timeout. Tên gọi của giao thức là quay lui
xuất phát từ thái độ của bên gởi trong trường hợp mất gói hay
độ trễ lớn. Giống giao thức “dừng và chờ”, bộ đếm thời gian
cũng được dùng để khắc phục lỗi khi mất gói tin dữ liệu hay
gói báo nhận. Nếu hết thời gian chờ, bên gởi sẽ gởi lại tất cả
các gói tin đã gởi mà chưa được báo nhận. Bên gởi trong hình
3.20 chỉ sử dụng một bộ đếm thời gian cho gói tin đã gởi lâu
nhất mà chưa được báo nhận. Nếu bên gởi nhận được gói tin
ACK và trong cửa sổ còn gói tin đã gởi nhưng chưa được báo
nhận thì bộ đếm thời gian sẽ được khởi tạo lại; ngược lại, dừng
bộ đếm thời gian.
Hành động của bên nhận thì đơn giản. Nếu bên nhận nhận một gói tin
có số thứ tự N đúng và đúng thứ tự (gói tin được chuyển lên tầng trên
trước đó có số thứ tự là N-1), bên nhận gởi một gói tin báo nhận ACK
cho gói tin N và chuyển phần dữ liệu của gói tin này lên tầng trên.
Ngược lại, bên nhận huỷ gói tin và gởi về gói tin ACK cho gói tin đã
nhận đúng gần nhất. Lưu ý rằng các gói tin được chuyển lên tầng trên
một lần tại một thời điểm cho nên khi gói tin k được nhận và chuyển
lên tầng trên thì đồng nghĩa với việc các gói tin có số thứ tự nhỏ hơn k
cũng đã chuyển lên tầng trên. Vì thế, giao thức quay lui dùng báo
nhận tổng hợp là một điều tự nhiên.
Trong giao thức quay lui, bên nhận huỷ các gói tin không đúng thứ tự.
Điều này có gây lãng phí hay không khi huỷ các gói tin nhận đúng
nhưng bị sai thứ tự? Chúng ta sẽ xét lại nguyên lý hoạt động của giao
thức quay lui để trả lời cho câu hỏi này: bên nhận chuyển gói tin nhận
được đúng thứ tự lên tầng trên, bên gởi gởi lại các gói tin đã gởi
nhưng chưa được báo nhận. Xét trường hợp, bên nhận đang mong chờ
gói tin N, nhưng nhận được gói tin N+1. Nếu bên nhận lưu tạm gói tin
N+1 vào bộ đệm để khi nhận được gói N sẽ chuyển gói tin này lên
tầng trên. Tuy nhiên, nếu gói tin N bị mất, cả hai gói tin N và N+1 đều
được bên gởi gởi lại. Vì thế, việc bên nhận lưu tạm gói tin N+1 là
không cần thiết. Thuận lợi của giải pháp này là đơn giản cho bên
nhận: bên nhận không cần tốn bộ đệm để lưu tạm các gói tin không
232
đúng thứ tự. Vì thế, trong khi bên gởi phải quản lý miền số thứ tự
trong cửa sổ và tham số số thứ tự tiếp theo nextSeq trong cửa sổ, bên
nhận chỉ quản lý một thông tin duy nhất là số thứ tự của gói tin tiếp
theo mà nó đang mong chờ. Giá trị này là tham số expectedSeqNum
trong hình 3.21. Tất nhiên, một bất lợi của việc huỷ gói tin nhận đúng
là bên gởi phải gởi lại nhiều lần nếu như gói tin gởi lại bị lỗi (bị mất
gói hay lỗi bit).
Hình 3.22. Một minh hoạ giao thức quay lui với kích thước cửa sổ
trượt là 4
233
Hình 3.22 là một ví dụ cho giao thức quay lui với kích thước cửa sổ
bằng 4. Trong ví dụ này, bên gởi gởi các gói tin có số thứ tự từ 0 đến 3
và phải dừng lại chờ cho đến khi có một gói tin được báo nhận. Khi
nhận được một gói tin ACK (ví dụ ACK0 và ACK1), cửa sổ sẽ trượt
sang gói tin mới (gói tin 4 và 5). Với bên nhận, gói tin 2 bị mất do đó
gói tin 3, 4, và 5 được xem là gói tin không đúng thứ tự và bị huỷ.
Nhìn chung, giao thức quay lui sử dụng hầu hết các kỹ thuật mà giao
thức TCP sẽ dùng: số thứ tự, báo nhận tổng hợp, checksum, thời gian
chờ và gởi lại gói tin.
IV.4 Giao thức gởi lại có chọn (Selective Repeat)
Giao thức quay lui cho phép bên gởi có thể “đổ đầy ống dẫn” với các
gói tin như hình 3.17 để tối ưu việc sử dụng kênh truyền. Tuy nhiên,
giao thức quay lui vẫn gặp phải vấn đề về hiệu năng. Trong thực tế,
khi kích thước cửa sổ trượt và độ trễ gói tin lớn, có thể có nhiều gói
tin nằm trong ống dẫn. Và khi có một gói tin bị lỗi, giao thức quay lui
phải truyền lại một lượng lớn các gói tin không cần thiết và gây ra
lãng phí. Khi xác suất xảy ra lỗi trên kênh truyền tăng, ống dẫn bị tràn
ngập các gói tin truyền lại không cần thiết. Quay lại với ví dụ trao đổi
giữa A và B qua điện thoại ban đầu, cứ mỗi lần có một từ bị lỗi,
khoảng 1000 từ (cửa sổ có 1000 từ đang chờ báo nhận) phải được lặp
lại. Và cuộc thảo luận sẽ bị chậm lại bởi các từ bị lặp lại này.
Như tên gọi của giao thức, giao thức gởi lại có chọn tránh việc gởi lại
không cần thiết bằng cách bên gởi chỉ gởi lại các gói tin bị nghi ngờ
có lỗi (do lỗi bit hoặc mất gói) tại bên nhận. Việc gởi lại riêng rẽ khi
cần đòi hỏi bên nhận phải gởi báo nhận riêng cho từng gói tin. Một
cửa sổ có kích thước N cũng được dùng để giới hạn số gói tin được
phép gởi khi chưa được báo nhận nằm trong ống dẫn. Tuy nhiên,
không giống như giao thức quay lui, bên gởi chỉ nhận gói ACK cho
một vài gói tin trong cửa sổ. Hình 3.23 minh họa vùng số thứ tự bên
gởi của giao thức gởi lại có chọn. Hình 3.24 thể hiện chi tiết các hành
động khác nhau của bên gởi khi có một sự kiện xảy ra.
234
Hình 3.23. Miền số thứ tự của bên gởi và bên nhận trong giao thức gởi
lại có chọn
1. Nhận dữ liệu từ tầng trên. Khi nhận dữ liệu từ tầng trên, bên gởi
kiểm tra số thứ tự sẵn sàng tiếp theo cho gói tin. Nếu số thứ tự này
nằm trong vùng cửa sổ của bên gởi, dữ liệu được đóng gói lại và
gởi đi; ngược lại, nó được lưu tạm trong bộ đệm hoặc gởi trả
ngược lại cho tầng trên như giao thức quay lui.
2. Hết thời gian chờ (timeout). Bộ đếm thời gian cũng được sử dụng
để đánh dấu hiện tượng mất gói.Tuy nhiên, mỗi gói sẽ có một bộ
đếm thời gian logic riêng, bởi vì chỉ gởi lại duy nhất một gói tin
khi hết thời gian chờ của nó. Một đồng hồ vật lý được sử dụng để
làm vai trò cho nhiều bộ đếm thời gian logic [Varghese 1997]
3. Nhận gói tin ACK. Khi nhận một gói tin ACK, bên gởi đánh dấu
gói tin đã được nhận. Nếu số tứ tự của gói tin bằng send_base, cửa
sổ bên gởi sẽ trượt đến gói tin chưa được báo nhận có số thứ tự
235
nhỏ nhất. Khi đó, nếu có gói tin chưa được gởi nằm trong cửa sổ,
bên gởi sẽ gởi các gói tin này.
Hình 3.24
Bên nhận của giao thức gởi lại có chọn sẽ gởi báo nhận cho gói tin
nhận đúng cho dù đúng thứ tự hay không. Các gói tin nhận không
đúng thứ tự sẽ được lưu trong bộ đệm cho đến khi các gói tin bị thiếu
(các gói tin có số thứ tự nhỏ hơn) được nhận và khi đó, các gói tin
đúng thứ tự sẽ được chuyển lên tầng trên. Hình 3.25 minh họa các
hành động của bên nhận khi có một sự kiện xảy ra. Hình 3.26 là một
ví dụ cho giao thức gởi lại có chọn khi có hiện tượng mất gói xảy ra.
Lưu ý rằng, bên nhận lưu vào bộ đệm gói tin 3, 4, 5 và chuyển chúng
cùng gói tin 2 lên tầng trên khi nhận được gói tin 2.
Một điều cần lưu ý là ở bước 2 trong hình 3.25, bên nhận gởi lại báo
nhận (thay vì bỏ qua) cho gói tin đã nhận rồi có số thứ tự bất kỳ nhỏ
hơn giá trị base hiện hành. Với vùng số thứ tự của bên gởi và bên
nhận như hình 3.23, nếu gói tin ACK cho gói tin có số thứ tự
send_base từ bên nhận không đến được bên gởi, bên gởi sẽ gởi lại gói
tin send_base, mặc dù chúng ta thấy rằng bên nhận đã nhận gói tin này
rồi. Nếu bên nhận không gởi báo nhận cho gói tin gởi lại này thì cửa
sổ bên nhận sẽ không bao giờ dịch chuyển. Ví dụ này minh họa một
mặt quan trọng của giao thức gởi lại có chọn. Bên gởi và bên nhận sẽ
không luôn luôn đồng nhất gói nào đã nhận đúng gói nào đã nhận sai.
Đối với giao thức gởi lại có chọn, điều này có nghĩa là bên gởi và bên
nhận sẽ không luôn luôn khớp với nhau.
1. Nhận gói tin có số thứ tự nằm trong khoảng [rcv_base,
rcv_base+N-1] đúng. Trong trường hợp này, gói tin nhận được
nằm trong cửa sổ bên nhận, bên nhận sẽ gởi một báo nhận cho gói
tin này cho bên gởi. Nếu gói tin này không trùng với các gói tin đã
nhận trước đó, gói tin này sẽ được lưu trong bộ đệm. Nếu gói tin
nằm ở đầu cửa sổ (số thứ tự của gói tin bằng với tham số rcv_base,
hình 3.22), gói tin này và các gói tin đã lưu trong bộ đệm trước đó
mà có số thứ tự liên tục được chuyển lên tầng trên. Khi đó, cửa sổ
sẽ trượt bằng với số gói tin đã chuyển lên tầng trên. Như ví dụ
trong hình 3.26, khi bên nhận nhận gói tin 2 thì bên nhận chuyển
236
gói tin 2, 3, 4, và 5 lên tầng trên và cửa sổ trượt sang số thứ tự 6.

2. Nhận gói tin có số thứ tự nằm trong khoảng [rcv_base-N,
rcv_base-1] đúng. Bên gởi vẫn gởi lại gói tin báo nhận mặc dù gói
tin này đã được gởi trước đó.
3. Ngược lại. Bỏ qua các gói tin này.
Hình 3.25
Hình 3.26. Xử lý của giao thức gởi lại có chọn
237
V. Giao thức vận chuyển hướng kết nối: TCP

Chúng ta đã khảo sát nguyên lý của truyền dữ liệu đáng tin cậy ở phần
trước, trong phần này chúng ta sẽ khảo khát giao thức TCP, một giao
thức hướng kết nối và đáng tin cậy ở tầng vận chuyển trong mạng
Internet. Và để cung cấp một kênh truyền đáng tin cậy, TCP cũng sử
dụng các nguyên lý đã thảo luận trong phần trước: phát hiện lỗi, gởi
lại, thông báo tổng hợp, bộ đếm thời gian và các trường số thứ tự.
Giao thức TCP được định nghĩa trong RFC793, RFC1323, RFC2018
và RFC2581.
V.1 Kết nối TCP
Giao thức TCP được gọi là giao thức hướng kết nối bởi vì trước khi
tiến trình ứng dụng gởi dữ liệu cho một tiến trình khác thì cả hai tiến
trình này phải thực hiện “bắt tay” với nhau. Nghĩa là, chúng phải gởi
một số phân đoạn cho nhau trước để khởi tạo một số tham số cho quá
trình truyền dữ liệu. Như một phần cúa quá trình khởi tạo kết nối
TCP, cả hai phía của kết nối TCP đều khởi tạo các biến trạng thái
tương ứng với kết nối đó.
Một kết nối TCP không là một mạch đầu cuối TDM hay FDM như
trong chuyển mạch mạch. Nó cũng không là một mạch ảo như trạng
thái kết nối trong hệ thống hai đầu cuối. Bởi vì TCP chỉ chạy trên các
trạm đầu cuối và không thực thi tại các thành phần mạng trung gian
(bộ định tuyến, bộ chuyển mạch tầng liên kết (link-layer switch)), các
thành phần mạng trung gian không quản lý trạng thái kết nối TCP.
Thật ra, các bộ định tuyến trung gian hoàn toàn không quan tâm đến
các kết nối TCP; chúng chỉ nhìn thấy các gói tin chứ không phải các
kết nối.
Một kết nối TCP cung cấp dịch vụ hai chiều (full-duplex): nếu một kết
nối TCP giữa hai tiến trình A và B trên hai máy khác nhau, tại cùng
một thời điểm ứng dụng có thể gởi dữ liệu đến B và B cũng có thể gởi
dữ liệu đến A. Một kết nối TCP cũng là một kết nối điểm đến điểm
(point-to-point), nghĩa là có một bên gởi và một bên nhận. Do đó, khi
gởi dữ liệu từ một điểm đến nhiều điểm(multicast) thì không thể dùng
TCP.
238
Chúng ta sẽ khảo sát xem một kết nối TCP được thiết lập như thế nào.
Giả sử tiến trình A đang chạy trên một máy muốn khởi tạo một kết nối
đến tiến trình B trên máy khác. Tiến trình khởi tạo kết nối được gọi là
tiến trình khách; tiến trình còn lại được gọi là tiến trình chủ. Tiến trình
tầng ứng dụng đầu tiên thông báo cho tầng vận chuyển máy khách
rằng nó muốn thiết lập một kết nối tới tiến trình ở máy chủ. Tầng vận
chuyển trong máy khách tiến hành thiết lập một kết nối TCP với TCP
trong máy chủ. Phần cuối của mục này, chúng ta sẽ thảo luận chi tiết
thủ tục thiếp lập kết nối. Ở đây, chúng ta chỉ cần biết rằng đầu tiên
máy khách gởi một gói tin TCP đặc biệt; máy chủ cũng phản hồi bằng
một gói tin TCP đặc biệt và cuối cùng máy khách gởi lại một gói tin
TCP đặc biệt thứ ba. Hai gói tin đầu thì không có dữ liệu, gói thứ ba
có thể chứa dữ liệu. Bởi vì có ba gói tin được gởi giữa hai máy do đó
thủ tục thiết lập kết nối này được xem như là một thao tác bắt tay ba
bước (three-way handshake).
Khi kết nối TCP đã được thiết lập, hai tiến trình ở tầng ứng dụng có
thể gởi dữ liệu cho nhau. Xét việc gởi dữ liệu từ tiến trình khách sang
tiến trình chủ. Tiến trình khách chuyển một luồng dữ liệu thông qua
socket (cách cửa của tiến trình) như mô tả trong mục VII chương 2.
Khi dữ liệu đã qua cánh cửa socket, dữ liệu thuộc kiểm soát của TCP
đang chạy trong máy khách. Như minh họa hình 3.28, TCP chuyển
trực tiếp dữ liệu này đến bộ đệm gởi của kết nối, là một trong những
bộ đệm được thiết lập trong quá trình bắt tay ba bước. TCP sẽ lấy các
đoạn dữ liệu từ bộ đệm để gởi từ từ. Một điều thú vị là trong tài liệu
RFC 793 không đề cập khi nào TCP nên gởi dữ liệu lưu trong bộ
đệm, theo thống kê thì TCP nên “gởi dữ liệu trong các gói tin khi nào
tiện”. Lượng dữ liệu tối đa có thể lấy và đặt trong một gói tin bị giới
hạn bởi tham số kích thước gói tin tối đa (maximum segment size,
MSS). Giá trị MSS cơ bản thiết lập bằng kích thước gói tin lớn nhất
trong tầng liên kết dữ liệu có thể gởi được tại máy gởi cục bộ (được
gọi là đơn vị truyền lớn nhất, maximum transmission unit, MTU).
MSS đảm bảo rằng một gói tin TCP (sau khi được đóng gói trong gói
tin IP) sẽ vừa đủ gói tin tầng liên kết dữ liệu. Giá trị phổ biến của
MTU là 1460 byte, 536 byte và 512 byte. Có nhiều giải pháp tính giá
trị MTU trên đường đi được đề xuất – gói tin tầng liên kết dữ liệu lớn
nhất có thể gởi qua được tất cả các liên kết từ nguồn đến đích đến
239
[RFC 1191] - và gán giá trị MSS bằng giá trị MTU. Lưu ý rằng MSS
là lượng dữ liệu lớn nhất tầng ứng dụng có thể gởi xuống chứ không
phải kích thước lớn nhất của gói tin TCP kể cả header.
TCP kết hợp mỗi đoạn dữ liệu cùng với một header TCP tạo thành
một phân đoạn mới được gọi là phân đoạn TCP. Các gói tin này được
chuyển xuống tầng mạng, nơi mà chúng được đóng gói trong các gói
tin IP riêng lẻ. Sau đó, các gói tin IP được gởi xuống mạng. Khi TCP
nhận một gói tin tại bên còn lại của kết nối, dữ liệu của gói tin được
đặt trong bộ đệm nhận của kết nối như hình 3.28. Sau đó, tầng ứng
dụng đọc luồng dữ liệu từ bộ đệm này. Mỗi bên của một kết nối đều
có bộ đệm gởi và bộ đệm nhận của riêng nó.
Hình 3.28. Bộ đệm gởi và nhận của TCP

Tóm lại, một kết nối TCP bao gồm các bộ đệm, các tham số, một kết
nối socket tới một tiến trình trong máy và một tập khác gồm các bộ
đệm, tham số và kết nối socket tới một tiến trình trong máy khác. Như
đã trình bày ở trên, không có bộ đệm hay tham số nào để xác định kết
nối trong các thành phần mạng (bộ định tuyến, bộ chuyển mạch
(switch) và bộ khếch đại tín hiệu) giữa các máy.
V.2 Cấu trúc gói tin TCP
Gói tin TCP gồm các trường header và trường dữ liệu. Trường dữ liệu
chứa một đoạn dữ liệu tầng ứng dụng. Như đã trình bày, tham số MSS
giới hạn kích thước tối đa của trường dữ liệu. Khi TCP gởi một tập tin
lớn, ví dụ một hình ảnh trên một trang web, nó sẽ chia tập tin thành nhiều
240
đoạn dữ liệu có kích thước bằng MSS (trừ đoạn dữ liệu cuối cùng thường
nhỏ hơn MSS). Tuy nhiên, một số ứng dụng tương tác, ví dụ ứng dụng
Telnet, thường truyền dữ liệu có kích thước nhỏ hơn MSS, ví dụ như gói
tin đăng nhập từ xa của ứng dụng Telnet thường chỉ có 1 byte dữ liệu.
Bởi vì kích thước header của TCP cơ bản có 20 bytes (nhiều hơn UDP 12
bytes), phân đoạn gởi bởi ứng dụng Telnet thường có kích thước là 21
bytes.
Hình 3.29. Cấu trúc gói tin TCP

Hình 3.29 biểu diễn cấu trúc gói tin TCP và bảng 3.7 mô tả chi tiết các
trường header của gói tin TCP. Giống như UDP, header chứa thông tin
cổng nguồn và cổng đích đến để phục vụ cho quá trình dồn kênh/phân
kênh dữ liệu từ/đến tầng ứng dụng. Và header của TCP cũng chứa trường
checksum. Header của một gói tin TCP gồm các trường như sau:
Trường Kích Mô tả
thước
Cổng nguồn 16 bit Cổng của tiến trình bên gởi
241
SrcPort #
Cổng đích đến 16 bit Cổng của tiến trình bên nhận
DestPort#
Số thứ tự 32 bit Số thứ tự byte đầu tiên của trường
dữ liệu trong luồng byte gởi.
Seq#
Được sử dụng để cài đặt dịch vụ
truyền dữ liệu đáng tin cậy
Số báo nhận 32 bit Số thứ tự của byte tiếp theo mà
ACK# bên gởi gói tin muốn nhận từ bên
nhận gói tin
Được sử dụng để cài đặt dịch vụ
truyền dữ liệu đáng tin cậy
Kích thước header 4 bit Số từ (32 bit) trong header, nghĩa
là giá trị này gấp bốn lần số byte
Header length
trong header
Để dành 6 bit Không dùng, khởi tạo bằng 0
Unused
Cờ 6 bit Chỉ định loại thông tin trong gói
Flag tin
Bit Cờ Ý nghĩa khi bit cờ bật
(giá trị bằng 1)
URG Cờ khẩn
Gói tin này cần truyền
khẩn và giá trị Urgent
Data Pointer có ý
nghĩa
ACK Cờ báo nhận
Gói tin này có chứa
242
thông tin báo nhận và

giá trị trong trường Số
báo nhận có ý nghĩa
PSH Cờ đẩy
Dữ liệu trong gói tin
này cần chuyển lên
tầng ứng dụng ngay
lập tức
RST Cờ thiết lập lại
Bên gởi gặp sự cố và
muốn thiết lập lại kết
nối
SYN Cờ đồng bộ
Gói tin này yêu cầu
đồng bộ số thứ tự và
thiết lập kết nối.
Trường Số thứ tự chứa
số thứ tự khởi tạo của
bên gởi
FIN Cờ kết thúc
Gói tin yêu cầu đóng
kết nối
Kích thước cửa sổ nhận 16 bit Số byte trống trong bộ đệm nhận
dữ liệu của bên gởi gói tin
Receive window
Được sử dụng trong kiểm soát
luồng
Checksum 16 bit Tính toàn bộ gói tin TCP
Con trỏ khẩn 16 bit Dùng kết hợp với cờ Khẩn.
Trường này chứa số thứ tự của
243
Urgent pointer byte khẩn cuối cùng

Tuỳ chọn Tuỳ chọn cho giao thức TCP. Mỗi
tuỳ chọn gồm ba thông tin <loại,
Option
kích thước, dữ liệu>. Nếu kích
thước phần tuỳ chọn không là bội
số của 4 byte, thì TCP sẽ chèn
thêm 1 số bit độn.
Dữ liệu Dữ liệu được truyền trong gói tin
Data
Số thứ tự (Seq#) và số báo nhận (ACK#)

Hai trường quan trọng trong header của gói tin TCP là trường số thứ tự,
Seq#, và số báo nhận, ACK#. Hai trường này là một phần quan trọng của
dịch vụ truyền dữ liệu đáng tin cậy của TCP.
TCP xem dữ liệu như là chuỗi các byte không cấu trúc nhưng có thứ tự.
TCP dùng số thứ tự để phản ánh số thứ tự của những byte đã gởi và chưa
gởi. Và trường số thứ tự (sequence number, Seq#) trong một gói tin là
số thứ tự của byte đầu tiên của trường dữ liệu của gói tin trong chuỗi
đó. Ví dụ, giả sử rằng một tiến trình P1 trong máy A muốn gởi tập tin có
kích thước 500000 byte đến tiến trình P2 trong máy B thông qua một kết
nối TCP. Và giả sử rằng giá trị MSS của kết nối TCP là 1000 byte và
byte đầu tiên trong chuỗi dữ liệu được đánh số là 0. Như minh hoạ trong
hình 3.30, TCP tạo 500 gói tin cho chuỗi dữ liệu của tập tin. Trường số
thứ tự của gói tin TCP đầu tiên được gán bằng 0, gói tin thứ hai là 1000,
thứ ba là 2000 và tương tự như vậy.
244
Hình 3.30. Chia tập tin dữ liệu thành các gói tin TCP
Trường số báo nhận (acknowledgment number, ACK#) thì phức tạp hơn
trường số thứ tự. Và TCP là một giao thức hai chiều (full-duplex), nghĩa
là máy A có thể nhận dữ liệu từ máy B trong khi nó gởi dữ liệu cho máy
B. Mỗi gói tin đến từ máy B có một số thứ tự trong luồng dữ liệu từ B
đến A. Máy A gán giá trị trường số báo nhận trong gói tin A gởi cho B là
số thứ tự của byte tiếp theo mà A đang mong chờ nhận từ B. Ví dụ, A
nhận tất cả các byte có số thứ tự từ 0 đến 535 từ B và A gởi một gói tin
cho B. A đang mong chờ byte thứ 536 và tất cả các dữ liệu còn lại trong
chuỗi dữ liệu gởi tại B. A gán trường số báo nhận trong gói tin mà A gởi
cho B là 536.
Một ví dụ khác, giả sử A nhận một gói tin từ B gồm các byte có số thứ tự
từ 0 đến 535 và một gói khác có số thứ tự từ 900 đến 1000. Vì một số lý
do gì đó, A chưa nhận được các byte có số thứ tự từ 536 đến 899. Trong
ví dụ này, máy A vẫn đợi byte có số thứ tự 536. Vì thế, số báo nhận trong
gói tin tiếp theo A gởi cho B có giá trị là 536. Bởi vì TCP chỉ báo nhận
byte bị thiếu đầu tiên trong chuỗi, TCP cũng được xem là một giao thức
cung cấp cơ chế báo nhận tổng hợp.
Chúng ta khảo sát một ví dụ khác để thấy một vấn đề quan trọng nhưng
nhỏ. Máy A nhận gói tin thứ ba (byte từ 900 đến 1000) trước khi nhận
gói tin thứ hai (byte từ 536 đến 899). Vì thế, gói tin thứ ba là gói tin đến
không đúng thứ tự. Một vấn đề nhỏ đặt ra là: một máy sẽ làm gì khi nhận
các gói tin không đúng thứ tự trong một kết nối TCP? Thật thú vị là tài
liệu RFC về TCP không đề xuất bất kỳ luật nào và để quyền quyết định
cho người cài đặt giao thức TCP. Chúng ta có hai lựa chọn: (1) bên nhận
huỷ gói tin ngay lập tức hoặc (2) vẫn giữ các gói tin không đúng thứ tự
245
và chờ các byte còn thiếu để lấp vào vùng thiếu. Rõ ràng lựa chọn thứ 2
phức tạp hơn trong lĩnh vực băng thông mạng và là giải pháp được chọn
trong thực tế.
Trong hình 3.30, chúng ta giả sử rằng số thứ tự được khởi tạo bằng 0.
Nhưng thực tế, cả hai bên gởi và nhận của kết nối TCP đều khởi tạo ngẫu
nhiên số thứ tự này. Điều này giúp làm giảm tối thiểu xác suất mà một
gói tin vẫn còn tồn tại trong mạng từ một kết nối từ trước và đã ngắt kết
nối rồi bị lấy nhầm bởi một kết nối sau đó giữa hai máy giống nhau
[Sunshine 1978].
Telnet: ví dụ minh hoạ cho số thứ tự và số báo nhận
Telnet, được định nghĩa trong RFC 854, là một giao thức tầng ứng dụng
phổ biến được dùng cho đăng nhập từ xa (lưu ý rằng, nhiều người dùng
thích sử dụng ssh hơn là telnet bởi vì dữ liệu được gởi trong một kết nối
telnet (kể cả mật khẩu của người dùng) đều không được mã hoá đã tạo ra
một điểm yếu đối với hình thức tấn công nghe lén, eavesdropping attack).
Telnet chạy trên giao thức TCP và được thiết kế để hai máy bất kỳ trao
đổi với nhau. Không giống như các ứng dụng truyền một khối các dữ liệu
đã thảo luận trong chương 2, Telnet là một ứng dụng tương tác.
Giả sử máy A khởi tạo một kết nối telnet với máy B. Do máy A là máy
khởi tạo kết nối nên gọi là máy khách (client), còn B là máy chủ (server).
Mỗi ký tự do người dùng tại máy khách gõ vào sẽ được gởi đến máy ở xa
(remote host); máy ở xa sẽ gởi ngược lại bản sao của mỗi ký tự (sẽ được
hiển thị lên màn hình). Cơ chế “gởi ngược” này được dùng để đảm bảo
rằng các ký tự thấy trên màn hình đã được nhận và xử lý tại bên nhận. Vì
thế, mỗi ký tự truyền trên mạng hai lần giữa thời điểm người dùng nhấn
phím và thời điểm ký tự đó hiển thị lên màn hình của người dùng.
Giả sử rằng, người dùng gõ ký tự ‘C’ và uống 1 ngụm café. Chúng ta sẽ
khảo sát các gói tin TCP gởi giữa máy khách và máy chủ. Như hình 3.31,
giả sử rằng số thứ tự bắt đầu là 42 và 79 cho máy khách và máy chủ. Nhớ
rằng trường số thứ tự là số thứ tự của byte đầu tiên trong trường dữ liệu.
Vì thế, gói tin đầu tiên gởi từ máy khách có số thứ tự là 42 và gởi từ máy
chủ là 79. Và trường số báo nhận là số thứ tự của byte tiếp theo mà máy
gởi gói tin đang chờ nhận. Sau khi thiết lập kết nối TCP và trước khi bất
246
kỳ gói tin nào gởi, máy khách mong chờ byte có số thứ tự là 79 và máy
chủ mong chờ byte 42.
Hình 3.31. Số thứ tự và số báo nhận cho một ứng dụng Telnet đơn giản
thông qua TCP
Như minh hoạ trong hình 3.31, có 3 gói tin được gởi. Gói tin đầu tiên gởi
từ máy khách chứa một byte ASCII của ký tự ‘C’ trong trường dữ liệu.
Gói tin đầu tiên này có giá trị trường số thứ tự là 42 và trường báo nhận
là 79 (do máy khách chưa nhận bất kỳ dữ liệu nào từ máy chủ). Gói tin
thứ hai được gởi từ máy chủ phục vụ hai mục đích. Thứ nhất là (1) báo
nhận dữ liệu mà máy chủ đã nhận bằng cách gán trường số báo nhận là
43 (máy chủ báo cho máy khách là máy chủ đã nhận đến byte thứ 42 và
đang mong chờ byte thứ 43). Thứ hai là (2) gởi ngược lại ký tự ‘C’. Vì
thế, trường dữ liệu gói tin thứ hai gồm 1 byte là giá trị ASCII của ký tự
‘C’. Gói tin này cũng có giá trị số thứ tự là 79. Lưu ý rằng, báo nhận cho
dữ liệu từ máy khách đến máy chủ được tích hợp trong gói tin từ máy
247
chủ đến máy khách. Báo nhận này được gọi là piggybacked trên gói tin
dữ liệu từ máy chủ đến máy khách.
Gói tin thứ ba được gởi từ máy khách đến máy chủ. Mục đích đơn giản
của gói tin này là để thông báo đã nhận dữ liệu gởi từ máy chủ. Gói tin
này không chứa dữ liệu. Trường số báo nhận trong gói tin là 80 bởi vì
máy khách đã nhận các byte đến số thứ tự 79 và nó đang mong chờ byte
thứ 80. Bạn có thể nghĩ rằng là dư thừa khi gói tin này cũng có số thứ tự
trong khi nó không có byte dữ liệu nào. Nhưng bởi vì TCP có trường số
thứ tự nên gói tin cần có một số thứ tự nào đó.
V.3 Ước lượng thời gian trễ một vòng (RTT) và thời gian chờ
(Timeout)
Cũng giống như các giao thức rdt trong mục V, TCP sử dụng cơ chế thời
gian chờ và truyền lại để khắc phục lỗi mất gói. Mặc dù vấn đề này có lẽ
đơn giản nhưng chúng ta gặp một khó khăn nhỏ khi cài đặt cơ chế này
trong một giao thức thực tế, TCP. Có lẽ một câu hỏi rõ ràng nhất là
khoảng thời gian chờ là bao lâu là hợp lý? Rõ ràng, thời gian chờ nên lớn
hơn thời gian trễ một vòng của kết nối (round-trip time, RTT) chính là
thời gian gói tin được gởi đến khi nhận được báo nhận. Ngược lại, chúng
ta sẽ truyền lại gói tin đó, mà đáng lẽ là không cần. Nhưng lớn hơn bao
nhiêu? Làm sao chúng ta ước lượng được thời gian trễ một vòng RTT tại
thời điểm ban đầu? Bộ đếm thời gian nên thiết lập riêng cho mỗi gói tin
hay cho mọi gói tin chưa được báo nhận? Có quá nhiều câu hỏi được đặt
ra. Mọi thảo luận trong phần này dựa trên giao thức TCP trong [Jacobson
1988] và tài liệu được IETF khuyến cáo cho việc quản lý bộ đếm thời
gian của TCP [RFC 2988].
Ước lượng thời gian trễ một vòng (Round-Trip Time - RTT)
Để ước lượng thời gian trễ một vòng RTT giữa bên gởi và bên nhận, TCP
định nghĩa thêm một tham số RTT mẫu, đặt là RTT_Mau. Một RTT mẫu
cho một gói tin là khoảng thời gian khi gói tin được gởi (gởi xuống IP)
đến khi nhận gói báo nhận cho gói tin đó. Thay vì đo giá trị RTT_Mau
cho mỗi gói tin, hầu hết các cài đặt TCP đều lấy giá trị RTT_Mau tại một
thời điểm. Nghĩa là tại một thời điểm bất kỳ, giá trị RTT_Mau đang được
ước lượng chỉ cho một trong những gói tin đã gởi nhưng chưa được báo
248
nhận dẫn đến mỗi gói tin có một giá trị RTT_Mau xấp xỉ mới. Và TCP
không tính giá trị RTT_Mau cho một gói tin truyền lại.
Rõ ràng, giá trị RTT_Mau sẽ thay đổi từ gói tin này đến gói tin khác do
sự tắc nghẽn tại các bộ định tuyến và sự thay đổi tải mạng trên hệ thống.
Do sự thay đổi này, không có một giá trị RTT_Mau điển hình. Để ước
lượng một giá trị RTT_Mau điển hình, TCP sử dụng RTT_Mau trung
bình, được gọi là RTT_UocLuong. TCP tính giá trị RTT_UocLuong theo
công thức sau:
RTT_UocLuong = (1- )*RTT_UocLuong + *RTT_Mau
Theo RFC 2988, giá trị  nên chọn bằng 0.125 = 1/8, và khi đó công
thức trên được viết lại như sau:
RTT_UocLuong = 0.875*RTT_UocLuong + 0.125*RTT_Mau
Lưu ý rằng giá trị RTT_UocLuong là giá trị trung bình của các giá trị
RTT_Mau. Và một điều hiển nhiên, càng nhiều mẫu lân cận phản ánh tốt
hơn tình trạng tắc nghẽn hiện thời của mạng. Trong thống kê, giá trị
trung bình này được gọi là giá trị trung bình thay đổi theo trọng số hàm
mũ (Exponetial Weighted Moving Average, EWMA). Từ “hàm mũ” xuất
hiện trong EWMA bởi vì trọng số của giá trị RTT_Mau cho trước giảm
theo hàm mũ nhanh như quá trình cập nhật.
Hình 3.32 biểu diễn giá trị RTT_Mau và RTT_UocLuong với  = 0.125
cho một kết nối TCP giữa máy gaia.cs.umass.edu (ở Amherst,
Massachusetts) và fantasia.eurecom.fr (ở phía nam nước Pháp). Rõ ràng
sự thay đổi giá trị RTT_Mau được làm mượt khi sử dụng giá trị
RTT_UocLuong.
Hơn nữa, để ước lượng giá trị RTT, chúng ta cũng cần có một phép đo sự
biến thiên của RTT. RFC 2988 định nghĩa hàm biến thiên của RTT,
DevRTT, như một ước lượng giá trị chênh lệch giữa RTT_Mau và
RTT_UocLuong.
DevRTT = (1-)*DevRTT + *|RTT_Mau – RTT_UocLuong|
Lưu ý rằng DevRTT là một EWMA của sự chênh lệch giữa RTT_Mau và
RTT_UocLuong. Nếu giá trị RTT_Mau dao động nhỏ, DevRTT sẽ nhỏ;
ngược lại, DevRTT sẽ lớn. Giá trị  nên dùng là 0.25.
249
Hình 3.32. Giá trị RTT_Mau và RTT_UocLuong

Thiết lập và quản lý khoảng thời gian chờ
Cho trước giá trị RTT_UocLuong và DevRTT, câu hỏi đặt ra là thiết lập
khoảng thời gian chờ bao nhiêu? Rõ ràng, khoảng thời gian chờ nên lớn
hơn hay bằng RTT_UocLuong; ngược lại TCP phải gởi lại các gói tin
không cần thiết. Nhưng khoảng thời gian chờ không nên lớn hơn quá
nhiều so với RTT_UocLuong; ngược lại, khi một gói tin bị mất, TCP sẽ
không gởi lại gói tin đó nhanh dẫn đến làm trễ việc gởi một lượng lớn dữ
liệu. Vì thế, khoảng thời gian chờ nên gán bằng RTT_UocLuong cộng
với một biên độ. Giá trị biên độ nên lớn khi giá trị RTT_Mau biến động
nhiều và ngược lại. Do đó, TCP sử dụng thêm giá trị DevRTT để quyết
định khoảng thời gian chờ trước khi gởi lại:
ThoiGianCho = RTT_UocLuong + 4*DevRTT
V.4 Truyền dữ liệu đáng tin cậy trong TCP
Lưu ý rằng dịch vụ tầng mạng trong Internet là dịch vụ không đáng tin
cậy. Giao thức IP không đảm bảo việc phân phát gói tin IP, không đảm
bảo phân phát đúng thứ tự và không đảm bảo tính toàn vẹn dữ liệu trong
gói tin. Với dịch vụ IP, gói tin có thể làm tràn bộ đệm của các bộ định
250
tuyến và không bao giờ đến được đích đến, gói tin có thể đến đích đến
không đúng thứ tự và giá trị các bit trong gói tin có thể bị lỗi (0 thành 1
hoặc 1 thành 0). Bởi vì các gói tin tầng vận chuyển được truyền qua
mạng bằng các gói tin IP nên các gói tin tầng vận chuyển có thể cũng gặp
phải các vấn đề này.
TCP xây dựng dịch vụ truyền dữ liệu đáng tin cậy trên nền dịch vụ không
đáng tin cậy và nỗ lực hết mình của IP. Dịch vụ truyền dữ liệu đáng tin
cậy của TCP đảm bảo rằng luồng dữ liệu mà tiến trình đọc từ bộ đệm
nhận dữ liệu của TCP là không lỗi, không có lỗ hỏng, không bị trùng lắp
và đúng thứ tự. Nghĩa là luồng dữ liệu nhận ở bên nhận giống hoàn toàn
luồng dữ liệu đã gởi ở bên gởi.
Trong các kỹ thuật truyền dữ liệu đáng tin cậy trước đây, chúng ta dễ
dàng chấp nhận với giả sử rằng sử dụng bộ đếm thời gian riêng cho mỗi
gói tin đã gởi nhưng chưa được báo nhận. Điều này là lý tưởng trong lý
thuyết, tuy nhiên trong thực tế chúng ta cần phải xem xét đến tổng chi
phí quản lý các bộ đếm thời gian. Vì thế, cơ chế quản lý bộ đếm thời gian
được khuyên dùng trong TCP là chỉ sử dụng một bộ đếm thời gian đơn
cho dù có nhiều gói tin đã gởi nhưng chưa được báo nhận.
Chúng ta sẽ thảo luận cơ chế TCP cung cấp dịch vụ truyền dữ liệu đáng
tin cậy theo hai bước tăng dần. Đầu tiên, chúng ta khảo sát một mô tả
đơn giản nhất: bên gởi chỉ sử dụng khoảng thời gian chờ để khôi phục
các gói tin bị mất. Sau đó, chúng ta khảo sát một trường hợp phức tạp
hơn là dùng báo nhận trùng để thay thế khoảng thời gian chờ. Để đơn
giản, chúng ta giả sử dữ liệu chỉ truyền theo một chiều từ máy A đến máy
B và máy A cần gởi một tập tin có kích thước lớn.
Hình 3.33 minh hoạ trường hợp đơn giản nhất của bên gởi TCP. Có ba sự
kiện chính liên quan đến việc truyền và truyền lại dữ liệu ở bên gởi TCP:
(1) nhận dữ liệu từ tầng ứng dụng, (2) hết thời gian chờ, và (3) nhận gói
báo nhận. Với sự kiện đầu tiên, nhận dữ liệu từ tầng ứng dụng, TCP đóng
gói dữ liệu trong một gói tin và chuyển gói tin đó xuống IP. Lưu ý rằng,
mỗi gói tin có chứa số thứ tự của byte dữ liệu đầu tiên trong luồng dữ
liệu gởi và bộ đếm thời gian bắt đầu bật khi gởi một gói tin nếu như chưa
bật cho các gói tin khác. TCP thiết lập khoảng thời gian hết hạn cho bộ
đếm thời gian bằng với khoảng thời gian chờ (được tính từ hai giá trị
RTT_UocLuong và DevRTT).
251
/*giả sử bên gởi không bị ràng buộc bởi cơ chế kiểm soát tắt nghẽn và kiểm soát
luồng của TCP, kích thước của dữ liệu từ tầng trên gởi xuống nhỏ hơn MSS và chỉ
truyền theo 1 chiều*/
NextSeqNum = InitialSeqNumber
SendBase = InitialSeqNumber
Loop (vô tận) {
Switch (sự kiện)
Sự kiện: nhận dữ liệu từ tầng trên
Tạo phân đoạn TCP với số thứ tự là NextSeqNum
If (chưa bật bộ đếm thời gian)
Bật bộ đếm thời gian
Chuyển phân đoạn cho tầng mạng
NextSeqNum += chiều dài (dữ liệu)
Break;
Sự kiện: hết thời gian chờ
Gởi lại gói tin đã gởi nhưng chưa được ACK với số thứ
tự nhỏ nhất
Break;
Sự kiện: Nhận gói tin ACK với trường ACK# là y
If (y > SendBase) {
SendBase = y;
Nếu còn gói tin đã gởi nhưng chưa được ACK
}
Break;
} /* kết thúc lặp vô tận */
Hình 3.33. Trường hợp đơn giản của Bên gởi TCP
252
Sự kiện thứ hai là hết thời gian chờ. TCP phản ứng với sự kiện này bằng
hành động gởi lại gói tin gây ra sự kiện hết thời gian chờ. Sau đó, TCP
bật lại bộ đếm thời gian.
Sự kiện thứ ba mà bên gởi TCP phải xử lý là nhận gói tin báo nhận ACK
trùng từ bên nhận. Khi đó, TCP so sánh giá trị trường số báo nhận,
ACK#, y với giá trị sendBase của nó. Biến trạng thái sendBase là số thứ
tự của byte cũ nhất đã gởi nhưng chưa được báo nhận. Như đã trình bày
ở trên, TCP sử dụng cơ chế báo nhận tổng hợp vì thế gói báo nhận có số
báo nhận là y nghĩa là các byte có số thứ tự nhỏ hơn y đã được nhận. Nếu
y > sendBase, thì gói báo nhận ACK dùng để thông báo cho một hay
nhiều gói tin chưa được báo nhận trước đó. Vì thế, bên gởi cập nhật giá
trị sendBase của nó và bật lại bộ đếm thời gian nếu trong cửa sổ trượt vẫn
còn gói tin đã gởi nhưng chưa được báo nhận.
Một vài trường hợp thú vị
Ở trên là một phiên bản đơn giản nhất của TCP về việc cung cấp dịch vụ
truyền dữ liệu đáng tin cậy. Tuy nhiên phiên bản này vẫn còn một vài
vấn đề nhỏ. Để hiểu rõ giao thức TCP hoạt động như thế nào, chúng ta sẽ
khảo sát một vài trường hợp đơn giản.
253
Hình 3.34. Gởi lại vì mất gói báo nhận

Hình 3.34 mô tả trường hợp đầu tiên, trong đó máy A gởi một gói tin đến
máy B. Giả sử, gói tin này có số thứ tự là 92 và có 8 byte dữ liệu. Sau khi
gởi gói tin này, máy A chờ một gói tin từ B với số báo nhận là 100. Mặc
dù B nhận được gói tin từ A gởi đến nhưng gói tin báo nhận từ B gởi đi
bị mất. Trong trường hợp này, sự kiện hết thời gian chờ xảy ra và A gởi
lại gói tin trước đó đã gởi. Tất nhiên khi B nhận được gói tin gởi lại này,
nó quan sát thấy rằng số thứ tự của gói tin đã được nhận rồi. Vì thế, B
huỷ những byte trong gói tin gởi lại này.
254
Hình 3.35. Gói tin 100 không được gởi lại

Trường hợp thứ hai như hình 3.35, máy A gởi hai gói tin đến máy B. Gói
tin đầu tiên có số thứ tự là 92 và 8 byte dữ liệu; gói thứ hai có số thứ tự là
100 và 20 byte dữ liệu. Giả sử rằng cả hai gói tin đến B đều không bị lỗi
và B gởi báo nhận riêng cho mỗi gói tin. Gói báo nhận đầu tiên có số báo
nhận là 100; gói báo nhận thứ hai có số báo nhận là 120. Và giả sử rằng
không gói báo nhận nào đến A trước khi hết thời gian chờ tại A. Khi xảy
ra sự kiện hết thời gian chờ, A gởi lại gói tin đầu tiên với số thứ tự là 92
và bật lại bộ đếm thời gian. Ngay khi gói báo nhận cho gói tin thứ hai
đến trước khi hết thời gian chờ, gói tin thứ hai không bị gởi lại.
255
Hình 3.36. Báo nhận tổng hợp tránh việc gởi lại gói tin đầu tiên.
Trong trường hợp cuối cùng trong hình 3.36, A cũng gởi 2 gói tin như
trường hợp thứ hai. Gói báo nhận cho gói đầu tiên bị mất nhưng trước khi
hết thời gian chờ tại A, A nhận gói báo nhận có số báo nhận là 120. Và A
biết rằng B đã nhận được tất cả các byte dữ liệu đến byte thứ 119 vì thế
A không phải gởi lại bất kỳ gói tin nào.
Gấp đôi khoảng thời gian chờ

Chúng ta thảo luận một thay đổi nhỏ mà hầu hết các cài đặt TCP triển
khai. Đầu tiên là liên quan đến khoảng thời gian chờ sau một lần hết thời
gian chờ. Trong thay đổi này, bất cứ khi nào sự kiện hết thời gian chờ
xuất hiện, TCP gởi lại gói tin đã gởi nhưng chưa được báo nhận với số
thứ tự nhỏ nhất. Nhưng mỗi lần gởi lại, TCP gán thời gian chờ gấp đôi
thời gian chờ trước đó thay vì tính từ tham số RTT_UocLuong và
DevRTT. Ví dụ, giả sử khoảng thời gian chờ cho gói tin cũ nhất đã gởi
256
nhưng chưa được báo nhận là 0.75 giây. Khi lần đầu tiên hết thời gian
chờ, TCP sẽ gởi lại gói này và gán thời gian chờ là 1.5 giây. Nếu sau 1.5
giây lại xuất hiện sự kiện hết thời gian chờ, TCP gởi lại lần nữa gói tin
này và gán thời gian chờ là 3.0 giây. Vì thế thời gian chờ tăng theo hàm
số mũ sau mỗi lần gởi lại. Tuy nhiên, thời gian chờ khi xảy ra một sự
kiện khác (nhận dữ liệu từ tầng trên hoặc nhận gói báo nhận) thì được
tính dựa trên giá trị RTT_UocLuong và DevRTT gần nhất.
Giải pháp này như một cơ chế kiểm soát tắc nghẽn đơn giản (cơ chế kiểm
soát tắc nghẽn phức tạp hơn sẽ được trình bày trong mục VII). Sự kiện
hết thời gian chờ được xem như một nguyên nhân gây ra tắc nghẽn: có
quá nhiều gói tin đến một hay nhiều hàng đợi của bộ định tuyến trên
đường đi giữa nguồn và đích đến dẫn đến gói tin có độ trễ cao hoặc bị
huỷ. Mỗi khi tắc nghẽn, nếu nguồn vẫn tiếp tục gởi lại đều đặn thì tình
trạng tắc nghẽn càng tệ hơn. Thay vì vậy, TCP hành động lịch sự hơn là
tăng khoảng thời gian chờ mỗi khi gởi lại gói tin.
Gởi lại nhanh

Vấn đề đặt ra là khoảng thời gian chờ có thể lâu hơn khi gởi lại gói tin do
hết thời gian chờ. Khi một gói tin bị mất, thời gian chờ tăng lên để trì
hoãn việc gởi lại gói tin bị mất, do đó, làm tăng độ trễ của gói tin. Rất
may là TCP có thể phát hiện mất gói nhanh khi chưa hết thời gian chờ
bằng gói tin báo nhận trùng. Gói tin báo nhận trùng là một báo nhận cho
một gói tin mà bên gởi đã nhận được báo nhận trước đó. Để hiểu rõ phản
ứng của bên gởi với sự kiện nhận báo nhận trùng, trước hết chúng ta tìm
hiểu vì sao bên nhận gởi báo nhận trùng. Bảng 3.2 tổng hợp chính sách
phát sinh gói báo nhận tại bên nhận của TCP (RFC 1122, RFC 2581).
Khi bên nhận TCP nhận một gói tin với số thứ tự lớn hơn số thứ tự nó
đang mong chờ, nó phát hiện có một khoảng trống trong luồng dữ liệu –
nghĩa là thiếu dữ liệu. Khoảng trống này có thể là do mất gói hoặc đảo
lộn thứ tự gói tin trong mạng. Bởi vì TCP không dùng báo nhận tiêu cực,
nên bên nhận không thể gởi báo nhận tiêu cực cho bên gởi. Thay vào đó,
bên nhận chỉ đơn giản báo nhận lại gói tin cuối cùng nhận đúng thứ tự
(phát sinh gói tin báo nhận trùng). Bảng 3.2 mô tả các hành động của bên
nhận khi có một sự kiện xảy ra với điều kiện bên nhận không huỷ các gói
tin không đúng thứ tự.
257
Sự kiện Hành động bên nhận

Nhận gói tin đúng thứ tự. Tất cả Trì hoãn báo nhận. Chờ thêm một
các gói tin trước đó đã được báo gói tin mới đúng thứ tự đến trong
nhận 500 ms. Nếu không nhận thêm gói
tin đúng thứ tự nào trong khoảng
thời gian này thì gởi báo nhận
Nhận gói tin đúng thứ tự. Một gói Ngay lập tức gởi báo nhận tổng
tin đúng thứ tự khác cũng đang chờ hợp cho cả hai gói tin đúng thứ tự
gởi báo nhận
Nhận gói tin có số thứ tự lớn hơn Ngay lập tức gởi báo nhận trùng để
số thứ tự mong chờ. Gói tin đến chỉ định số thứ tự của byte dữ liệu
không đúng thứ tự và xuất hiện đang mong chờ
khoảng trống trong luồng dữ liệu
Nhận gói tin lắp được là một phần Ngay lập tức gởi báo nhận cho biết
hay hay tất cả khoảng trống dữ liệu gói tin bắt đầu vị trí thấp nhất của
khoảng trống
Bảng 3.2. Phát sinh báo nhận của TCP (RFC 1122, RFC 2581)
Bởi vì bên gởi luôn gởi nhiều gói tin cho bên nhận. Nếu một gói tin bị
mất thì sẽ có rất nhiều gói tin báo nhận trùng. Nếu bên gởi TCP nhận
được 3 gói tin báo nhận trùng cho cùng dữ liệu, điều này chỉ ra rằng gói
tin sau gói tin được báo nhận 3 lần đã bị mất. Do đó, trong trường hợp
TCP nhận 3 gói tin báo nhận trùng, bên gởi TCP sẽ thực hiện gởi lại
nhanh (RFC 2581): gởi lại gói tin bị mất trước khi hết thời gian chờ. Một
ví dụ minh hoạ cho trường hợp này thể hiện trong hình 3.37, trong đó gói
tin thứ hai bị mất sau đó được gởi lại trước khi hết thời gian chờ. Với cơ
chế gởi lại nhanh của TCP, đoạn chương trình mã giả sau thay cho sự
kiện nhận gói tin trong hình 3.33.
Sự kiện: Nhận ACK, với trường ACK# = y
If (y > SendBase)
{
SendBase = y
258
If (còn gói tin chưa được báo nhận)

}
Else // nhận ACK trùng
{
Tăng số gói tin ACK trùng cho y
If (số gói tin ACK trùng cho y ==3)
// gởi lại nhanh
Gởi lại gói tin có số thứ tự bằng y
}
break
Hình 3.37. Gởi lại nhanh: gởi lại các gói tin bị mất trước khi hết thời gian
chờ.
Như đã lưu ý trước đây, có rất nhiều vấn đề nhỏ xuất hiện khi cơ chế gởi
lại và hết thời gian chờ được cài đặt trong một giao thức thực tế như
TCP. Thủ tục ở trên chỉ là một trường hợp và đây là kết quả của hơn 15
năm làm thực nghiệm với bộ đếm thời gian.
259
Quay lui hay Gởi lại có chọn

Một câu hỏi đặt ra là TCP là: một giao thức quay lui hay gởi lại có chọn?
TCP sử dụng báo nhận tổng hợp cho các gói tin được nhận chính xác; tuy
nhiên các gói tin không đúng thứ tự không được báo nhận riêng. Do đó,
như hình 3.33 (và hình 3.19), bên gởi TCP chỉ cần quản lý số thứ tự nhỏ
nhất của gói tin đã gởi nhưng chưa được báo nhận (SendBase) và số thứ
tự của byte tiếp theo được gởi (NextSeqNum). Trong trường hợp này,
TCP giống như một giao thức quay lui. Nhưng có nhiều điểm khác biệt
rõ rệt giữa TCP và giao thức quay lui. Nhiều cài đặt TCP sẽ lưu tạm
những gói tin đã nhận đúng nhưng không đúng thứ tự (Stevens 1994).
Như vậy, việc gì sẽ xảy ra khi bên gởi gởi một loạt các gói tin 1, 2, 3, …,
N và các gói tin này đến bên nhận đúng và đúng thứ tự; tuy nhiên gói báo
nhận cho gói tin n < N bị mất, còn N – 1 báo nhận còn lại đến được bên
gởi trước khi hết thời gian chờ. Trong ví dụ này, giao thức quay lui
không chỉ gởi lại gói tin n mà còn gởi lại các gói tin n+1, n+2, …, N.
Ngược lại, TCP thậm chí sẽ không gởi lại gói tin n nếu gói báo nhận n+1
đến bên gởi trước khi hết thời gian chờ của gói tin n.
Một thay đổi cho TCP, được gọi là báo nhận có chọn (selective
acknowledgment), RFC 2018, cho phép bên nhận báo nhận các gói tin
không đúng thứ tự có chọn lọc thay vì báo nhận tổng hợp cho gói tin cuối
cùng nhận đúng và đúng thứ tự. Khi kết hợp với việc gởi lại có chọn, bỏ
qua việc gởi lại gói tin đã được báo nhận có chọn rồi. Khi đó, về cơ bản
TCP giống giao thức gởi lại có chọn. Vì thế, cơ chế phục hồi lỗi của TCP
là một giải pháp kết hợp giữa quay lui và gởi lại có chọn.
V.5 Kiểm soát luồng (flow control)
Như đã trình bày ở trên, các máy tại mỗi đầu của kết nối TCP có một bộ
đệm nhận dữ liệu cho kết nối đó. Khi TCP nhận dữ liệu không bị lỗi và
đúng thứ tự, nó đưa dữ liệu này vào bộ đệm nhận. Tiến trình của ứng
dụng tương ứng sẽ đọc dữ liệu từ bộ đệm này nhưng không nhất thiết
phải tại thời điểm dữ liệu đến. Thật vậy, ứng dụng nhận có thể bận rộn
với các công việc khác nên không đọc dữ liệu ngay khi dữ liệu đến. Nếu
ứng dụng đọc dữ liệu chậm, bên gởi sẽ dễ làm tràn bộ đệm nhận bởi vì
gởi quá nhiều dữ liệu với tốc độ nhanh.
260
TCP cung cấp dịch vụ kiểm soát luồng để hạn chế xác suất bên gởi làm
tràn bộ đệm bên nhận. Vì thế, kiểm soát luồng như là một dịch vụ so
khớp tốc độ: so khớp tốc độ gởi dữ liệu của bên gởi và tốc độ đọc dữ liệu
của ứng dụng bên nhận. Như đã trình bày trước đây, một bên gởi TCP có
thể góp phần làm tắc nghẽn trong mạng IP và cơ chế kiểm soát vấn đề
này ở bên gởi là kiểm soát tắc nghẽn (xem chi tiết mục VI và VII). Mặc
dù, nguồn gốc của cơ chế kiểm soát luồng và tắc nghẽn là như nhau (đều
là xuất phát từ bên gởi), nhưng rõ ràng chúng xuất phát từ các lý do khác
nhau. Trong phần này, chúng ta sẽ thảo luận xem TCP cung cấp dịch vụ
kiểm soát luồng như thế nào. Và chúng ta giả sử rằng TCP hủy bỏ các
gói tin không đúng thứ tự.
Để cung cấp cơ chế kiểm soát luồng, bên gởi TCP duy trì một tham số
gọi là cửa sổ nhận (receive window). Cửa số nhận được sử dụng để bên
gởi biết bộ đệm bên nhận còn trống bao nhiêu. Bởi vì TCP là giao thức
truyền hai chiều (full duplex), mỗi bên đều duy trì một tham số cửa sổ
nhận riêng. Chúng ta sẽ khảo sát của sổ nhận trong ngữ cảnh truyền tập
tin. Giả sử A gởi cho B một tập tin có kích thước lớn qua một kết nối
TCP. B cấp một bộ đệm nhận cho kết nối này với kích thước
Bodem_Nhan. Từ đây, tiến trình ứng dụng tại B đọc dữ liệu từ bộ đệm
này. Chúng ta định nghĩa thêm các tham số sau:
• ByteDocCuoi: số thứ tự byte cuối cùng của luồng dữ liệu trong bộ
đệm được đọc bởi tiến trình ứng dụng trong B
• ByteNhanCuoi: số thứ tự byte cuối cùng của luồng dữ liệu đến B
và được đặt vào bộ đệm nhận
Bởi vì TCP không cho phép làm tràn bộ đệm, chúng ta phải có:
ByteNhanCuoi – ByteDocCuoi ≤ Bodem_Nhan
Cửa sổ nhận (CuaSoNhan) là kích thước còn trống trong bộ đệm:
CuaSoNhan = Bodem_Nhan – [ByteNhanCuoi - ByteDocCuoi]
Bởi vì kích thước còn trống này thay đổi theo thời gian do đó tham số
CuaSoNhan là động. Biến CuaSo_Nhan được minh họa trong hình
3.38.
261
Hình 3.38. Cửa sổ nhận (CuaSoNhan) va bộ đệm nhận (BoDemNhan)

Và kết nối sử dụng tham số CuaSoNhan như thế nào để cung cấp dịch vụ
kiểm soát luồng? Máy B nói cho máy A biết bộ đệm của kết nối tại B còn
bao nhiêu bằng cách đặt giá trị của tham số CuaSo_Nhan vào trường Cửa
sổ nhận trong mỗi gói tin gởi đến A. Ban đầu, B gán giá trị CuaSoNhan
bằng với Bodem_Nhan. Lưu ý rằng để thực hiện điều này, B phải theo
dõi một số tham số của kết nối.
Tương tự, máy A cũng phải theo dõi hai tham số: ByteGoiCuoi và
ByteBaoNhanCuoi. Lưu ý rằng sự khác biệt giữa hai tham số này là:
ByteGoiCuoi – ByteBaoNhanCuoi là lượng dữ liệu đã gởi nhưng chưa
được báo nhận. Để đảm bảo không làm tràn bộ đệm, A phải giữ lượng dữ
liệu đã gởi nhưng chưa được báo nhận nhỏ hơn CuaSoNhan. Vì thế, A
phải đảm bảo lượng dữ liệu trên kết nối là
ByteGoiCuoi – ByteBaoNhanCuoi ≤ CuaSoNhan
Một vấn đề kỹ thuật khác phát sinh trong mô hình này. Giả sử rằng bộ
đệm nhận tại B đầy nghĩa là CuaSoNhan = 0. Sau khi B thông báo
CuaSoNhan = 0 đến A, giả sử rằng B không có dữ liệu gởi đến A. Bây
giờ chúng ta khảo sát xem chuyện gì sẽ xảy ra. Khi tiến trình ứng dụng
tại B đọc hết dữ liệu trong bộ đệm (bộ đệm rỗng), TCP không gởi gói tin
mới với giá trị CuaSoNhan mới đến A; thật vậy, TCP gởi một gói tin đến
A chỉ khi nó có dữ liệu để gởi hoặc khi cần gởi báo nhận cho A. Vì thế,
A sẽ không bao giờ được thông báo bộ đệm nhận ở B còn chỗ trống – A
khóa toàn bộ dữ liệu và không gởi dữ liệu nữa. Để giải quyết vấn đề này,
262
đặc tả của TCP yêu cầu A tiếp tục gởi các gói tin với 1 byte dữ liệu đến B
khi cửa sổ nhận tại B bằng 0. Các gói tin này sẽ được báo nhận bởi bên
nhận. Và cuối cùng khi bộ đệm rỗng thì gói tin báo nhận chứa trường cửa
sổ nhận khác 0.
Và một điều lưu ý rằng, UDP không cung cấp dịch vụ kiểm soát luồng.
Chúng ta có thể khảo sát một số gói tin UDP từ một tiến trình ở máy A
đến 1 tiến trình khác ở máy B để hiểu rõ vấn đề này. Với một cài đặt
UDP cơ bản, UDP sẽ đưa gói tin vào bộ đệm không bị giới hạn của
socket tương ứng. Tiến trình sẽ đọc toàn bộ gói tin từ bộ đệm này trong
một lần. Nếu tốc độ đọc dữ liệu chậm, bộ đệm sẽ bị tràn và gói tin bị hủy.
V.6 Quản lý kết nối
Trong phần này chúng ta sẽ khảo sát chi tiết cách thức TCP thiết lập và
hủy kết nối như thế nào. Mặc dù vấn đề này có vẻ không đặc biệt nhưng
quan trọng bởi vì việc thiết lập kết nối TCP làm tăng độ trễ đáng kể (vì
dụ, khi chúng ta lướt web). Hơn nữa, có nhiều tấn công mạng thông
dụng, kể cả tấn công làm tràn SYN, khám phá những điểm yếu trong việc
quản lý kết nối TCP. Trước tiên, chúng ta sẽ khảo sát xem TCP thiết lập
một kết nối như thế nào. Giả sử một tiến trình đang chạy trên một máy
(máy khách) muốn khởi tạo kết nối với một tiến trình khác đang chạy
trên máy khác (máy chủ). Tiến trình máy khách đầu tiên thông báo với
TCP máy khách rằng nó muốn thiết lập một kết nối tới tiến trình trong
máy chủ. TCP trong máy khách tiến hành thiết lập một kết nối TCP với
TCP trong máy chủ bằng các bước sau:
• Bước 1:đầu tiên, TCP máy khách gởi một gói tin TCP đặc biệt
đến TCP máy chủ. Gói tin này không chứa dữ liệu. Nhưng cờ
SYN trong trường cờ trong header của gói tin (hình 3.29) bật lên
1. Do đó, gói tin này còn được gọi là gói tin SYN. Thêm vào đó,
máy khách phát sinh ngẫu nhiên một số thứ tự khởi tạo
(client_isn) và đặt vào trường số thứ tự (Seq#) trong gói tin khởi
tạo TCP SYN. Gói tin này được đóng gói trong một gói tin IP và
gởi đến máy chủ. Việc khởi tạo ngẫu nhiên số thứ tự để đảm bảo
tính an toàn bảo mật được trình bày chi tiết trong CERT 2001-09.
• Bước 2: Khi gói tin IP chứa gói tin TCP SYN đến máy chủ, máy
chủ rút trích gói tin TCP SYN và xác định các tham số và bộ đệm
263
cho kết nối, sau đó gởi một gói tin đồng ý mở kết nối tới TCP
khách. Gói tin này cũng không chứa dữ liệu. Tuy nhiên, nó chứa
ba thông tin quan trọng trong header của gói tin: (1) bit SYN
trong trường cờ bật, (2) trường số báo nhận (ACK#) được gán
bằng client_isn+1, và (3) máy chủ cũng khởi tạo ngẫu nhiên số
thứ tự khởi tạo server_isn và gán vào trường số thứ tự. Gói tin
đồng ý mở kết nối này nói rằng “tôi đã nhận gói tin SYN mở kết
nối của anh với số thứ tự khởi tạo của anh là client_isn. Tôi đồng
ý thiết lập kết nối này. Số thứ tự khởi tạo của tôi là server_isn.”
Và gói tin này còn được gọi là gói tin SYNACK.
• Bước 3: Khi nhận gói tin SYNACK, máy khách cũng xác định
các tham số và bộ đệm cho kết nối. Sau đó, máy khách cũng gởi
cho máy chủ một gói tin khác để báo nhận cho gói tin đồng ý mở
kết nối c3a máy chủ. Trong header của gói tin này, trường số báo
nhận cũng được gán bằng server_isn+1, cờ SYN gán bằng 0 bởi
vì kết nối đã được thiết lập. Máy khách có thể gởi kèm dữ liệu
trong gói tin này.
Khi ba bước này hoàn tất, máy chủ và máy khách có thể gởi các gói
tin chứa dữ liệu cho nhau. Trong các gói tin dữ liệu này, bit SYN
trong trường cờ được gán bằng 0. Quá trình thiết lập kết nối bằng cách
gởi ba gói tin được minh họa bằng hình 3.39. Do đó, quá trình này còn
được gỏi là bắt tay ba bước (three-way handshake).
264
Hình 3.39. Thao tác bắt tay ba bước của TCP

Khi một trong hai tiến trình trong kết nối TCP muốn đóng kết nối, tiến
trình đó sẽ thực hiện thủ tục đóng kết nối. Và khi kết nối đã đóng, các
tài nguyên của kết nối (bộ đệm và các tham số) sẽ được giải phóng.
Giả sử tiến trình khách là tiến trình chủ động yêu cầu đóng kết nối như
hình 3.40. Khi đó, TCP khách gởi một gói tin đặc biệt đến tiến trình
máy chủ. Trong gói tin này, cờ FIN trong trường cờ (hình 3.29) bật
lên. Khi máy chủ nhận gói tin này, máy chủ gởi cho máy khách gói tin
báo nhận. Sau đó, máy chủ gởi gói tin đóng kết nối của nó (cờ FIN bật
lên 1). Cuối cùng, máy khách báo nhận cho gói tin đóng kết nối của
máy chủ. Tại thời điểm này, tất cả các tài nguyên ở hai máy đều được
giải phóng.
265
Hình 3.40. Quá trình đóng một kết nối TCP

Trong suốt thời gian sống của kết nối TCP, giao thức TCP chạy trong
mỗi máy chuyển đổi qua các trạng thái khác nhau. Hình 3.41 minh
họa chuỗi các trạng thái TCP cơ bản của TCP máy khách. TCP máy
khách bắt đầu bằng trạng thái ĐÓNG. Ứng dụng máy khách khởi tạo
một kết nối TCP mới. Khi đó, TCP máy khách gởi gói tin SYN đến
TCP máy chủ. Sau khi gởi gói tin SYN, TCP máy khách chuyển sang
trạng thái SYN_SENT. Ở trạng thái SYN_SENT, TCP máy khách chờ
nhận gói tin SYNACK từ TCP máy chủ. Khi đã nhận được gói tin
này, TCP máy khách chuyển sang trạng thái ESTABLISHED. Khi ở
trạng thái ESTABLISHED, TCP máy khách có thể gởi và nhận các
gói tin TCP có chứa dữ liệu của ứng dụng.
Giả sử rằng ứng dụng máy khách muốn đóng kết nối (lưu ý rằng máy
chủ cũng có thể chủ động thực hiện đóng kết nối). Khi đó, TCP máy
khách gởi gói tin FIN đến TCP máy chủ và chuyển sang trạng thái
FIN_WAIT_1. Trong trạng thái này, TCP máy khách chờ nhận gói tin
266
báo nhận từ máy chủ. Khi nó nhận được gói tin này, TCP máy khách
chuyển sang trạng thái FIN_WAIT_2. Trong trại thái FIN_WAIT_2,
TCP máy khách chờ nhận gói tin FIN từ máy chủ. Và khi nhận được
gói tin FIN này, máy khách gởi gói tin báo nhận cho gói tin này đến
máy chủ và chuyển sang trạng thái TIME_WAIT. Trạng thái
TIME_WAIT cho phép TCP máy khách gởi lại báo nhận cuối cùng
trong trường hợp báo nhận ACK bị mất. Thời gian ở trạng thái
TIME_WAIT được cài đặt độc lập nhưng nó có các giá trị cơ bản như
30 giây, 1 phút, 2 phút. Sau khi chờ, kết nối được đóng hoàn toàn và
tất cả các tài nguyên ở máy khách (kể cả tham số cổng) được giải
phóng.
Tương tự, hình 3.42 minh họa chuỗi các trạng thái TCP cơ bản của
TCP máy chủ và giả sử rằng máy khách chủ động đóng kết nối. Trong
hai sơ đồ này, chúng tôi chỉ mô tả một kết nối TCP được thiết lập và
đóng cơ bản như thế nào. Chúng tôi không mô tả chuyện gì sẽ xỷ ra
trong các tình huống bất thường nào, ví dụ cả hai phía kết nối muốn
đóng kết nối cùng lúc. Chi tiết những vấn đề này, bạn có thể tham
khảo trong quyển sách của Steven 1994.
Ở trên thảo luận dựa trên giả thiết rằng cả máy chủ và máy khách đã
chuẩn bị để liên lạc với nhau, ví dụ máy chủ đang lắng nghe kết nối
trên cổng mà máy khách gởi gói tin SYN. Chúng ta sẽ khảo sát xem
chuyện gì sẽ xảy ra khi TCP nhận một gói tin có chỉ số cổng và địa chỉ
IP nguồn không khớp với bất kỳ socket nào đang chạy trong máy. Ví
dụ, giả sử một máy nhận một gói tin TCP SYN với chỉ số cổng đích
đến là 80 nhưng máy đó không chấp nhận kết nối đến cổng 80 (nghĩa
là máy đó không có dịch vụ Web đang chạy trên cổng 80). Sau đó,
máy đó sẽ gởi một gói tin reset đặc biệt đến máy nguồn. Gói tin TCP
này có cờ RST bằng 1. Vì thế, khi một máy tính gởi một gói tin reset,
nó muốn nói với máy nguồn rằng “Tôi không có một socket cho gói
tin đó. Vui lòng gởi lại gói tin khác”. Khi một máy nhận một gói tin
UDP có chì số cổng đích đến không khớp với bất kỳ socket UDP nào
đang chạy, máy đó sẽ gởi một gói tin ICMP đặc biệt (chi tiết xem
trong Chương 4).
267
Hình 3.41. Sơ đồ trạng thái cơ bản của một TCP khách
Hình 3.42. Sơ đồ trạng thái cơ bản của một TCP máy chủ
268
VI. Các nguyên lý kiểm soát tắc nghẽn.

Trong pphần trước, chúng ta đã khảo sát các nguyên lý và cơ chế cài đặt
cụ thể của TCP để cung cấp dịch vụ truyền dữ liệu đáng tin cậy trong
trường hợp mất gói. Trong thực tế, việc mất gói về cơ bản là kết quả của
việc tràn bộ đệm tại các bộ định tuyến khi mạng bị tắc nghẽn. Vì thế việc
gởi lại gói tin chỉ xử lý dấu hiệu tắc nghẽn mạng (mất gói tại tầng vận
chuyển) nhưng không xử lý được nguyên nhân xảy ra tắc nghẽn: có quá
nhiều nguồn gởi dữ liệu với tốc độ cao. Để xử lý nguyên nhân tắc nghẽn,
cơ chế cần phải thực hiện tại bên gởi.
Trong phần này, chúng ta sẽ khảo sát bài toán điều khiển tắc nghẽn trong
ngữ cảnh chung. Chúng ta xem xét vì sao tắc nghẽn là một điều xấu và
tắc nghẽn mạng được thể hiện như thế nào trong hiệu năng nhận của ứng
dụng tầng trên và một số giải pháp để tránh hoặc là xử lý tắc nghẽn
mạng. Sau đó chúng ta sẽ thảo luận cơ chế điều khiển tắc nghẽn trong
dịch vụ Avaiable Bit-Rate (ABR) trong mạng truyềnnbất đối xứng
(Asynchronous Transfer Mode – ATM).
VI.1 Nguyên nhân và hậu quả của sự tắc nghẽn
Chúng ta sẽ tiếp cận bài toán tắc nghẽn mạng bằng cách khảo sát ba
trường hợp có xảy ra tắc nghẽn phức tạp. Trong mỗi trường hợp, chúng
ta sẽ xem xét vì sao tắc nghẽn xảy ra và hậu quả của tắc nghẽn (sử dụng
tài nguyên không tối ưu và hiệu năng nhận ở phía đầu cuối). Chúng ta
chưa xét đến việc phòng tránh và xử lý tắc nghẽn như thế nào mà chỉ
quan tâm vấn đề đơn giản hơn là chuyện gì xảy ra khi một máy tăng tốc
độ truyền dữ liệu và mạng bị tắc nghẽn.
Trường hợp 1: hai nguồn gởi, một bộ định tuyến với bộ đệm vô hạn
Đầu tiên chúng ta sẽ khảo sát trường hợp đơn giản nhất: hai máy A và B
đều có một kết nối chia sẻ cùng một máy giữa nguồn và đích đến. như
hình 3.43.
Giả sử rằng ứng dụng trongmáy A đang gởi dữ liệu vào kết nối (chuyển
dữ liệu đến giao thức tầng vận chuyển bằng socket) với tốc độ trung bình
in bytes/giây. Dữ liệu này gởi xuống socket chỉ một lần. Giao thức tầng
vận chuyển bên dưới thì đơn giản. Dữ liệu được đóng gói và gởi; không
có phục hồi lỗi (ví dụ như gởi lại gói tin), kiểm soát luồng hay điều khiển
269
tắc nghẽn. Bỏ qua lượng thông tin header thêm vào ở tầng vận chuyển và
tầng bên dưới, tốc độ tại máy A gởi đến bộ định tuyến với tốc độ in
bytes/giây. Máy B thực hiện đơn giản hơn và giả sử rằng B cũng gởi dữ
liệu với tốc độ in bytes/giây. Gói tin gởi từ A và B đi ngang qua bộ định
tuyến và cùng chia một liên kết đi ra có băng thông R. Bộ định tuyến có
bộ đệm cho phép nó lưu trữ các gói tin đến khi tốc độ gói tin đến vượt
quá khả năng của liên kết đi ra. Trong tình huống đầu tiên này, giả sử
rằng kích thước bộ đệm trong bộ định tuyến có giới hạn.
Hình 3.43. Trường hợp tắc nghẽn 1: hai kết nối cùng chia sẻ chung một
hop trung gian với bộ đệm không giới hạn
Hình 3.44 biểu diễn đồ thị hiệu năng của kết nối của máy A trong tình
huống đầu tiên này. Đồ thì bên tay trái biểu diễn thông lượng cho mỗi kết
nối (số byte trong một giây tại bên nhận) như là một hàm của tốc độ gởi.
Với tốc độ gởi từ 0 đến R/2, thông lượng tại bên nhện bằng với tốc độ
gởi; nghĩa là bên nhận nhận được mọi thứ gởi từ bên gởi với độ trễ hữu
hạn. Tuy nhiên, khi tốc độ gởi lớn hơn R/2, thì thông lượng chỉ đạt R/2.
Chặn trên của thông lượng này như là một kết quả của việc chia sẻ liên
kết giữa hai kết nối. Đơn giản là vì liên kết này không thể chuyển các gói
tin đến bên nhận với một tốc độ ổn định lớn hơn R/2. Cho dù máy A và B
thiết lập tốc độ gởi lớn bao nhiêu thì chúng sẽ không bao giờ đạt được
thông lượng lớn hơn R/2. Mỗi kết nối đạt được thông lượng là R/2 cũng
là một điều tốt bởi vì đã tối ưu tối đa khả năng của liên kết trong việc
truyền các gói tin đến đích đến.
270
Đồ thị bên tay phải trong hình 3.44 biểu diễn kết quả của việc tận dụng
gần tối đa khả năng của liên kết. Khi tốc độ gởi tiến gần R/2 (từ bên trái),
thì độ trễ trung bình càng lớn. Khi tốc độ gởi đạt R/2, số lượng gói tin
trung bình nằm trong hàng đợi của bộ định tuyến là vô tận và độ trễ trung
bình giữa nguồn và đích đến cũng trở nên vô hạn (giả sử rằng các kết nối
thao tác với tốc độ này trong khoảng thời gian vô hạn và các bộ đệm có
kích thước không giới hạn). Vì thế, khi việc thông lượng tổng hợp càng
đạt gần R - một thông lượng lý tưởng, độ trễ càng xa với độ trễ lý tưởng.
Thậm chí, trong trường hợp lý tưởng này, chúng ta nhận ra một chi phí
của việc tắc nghẽn: độ trễ của gói tin trong hàng đợi càng lớn thì tốc độ
gói tin đến càng đạt gần khả năng của liên kết.
Hình 3.44. Trường hợp tắc nghẽn 1: Thông lượng và độ trễ theo tốc độ
gởi
Trường hợp 2: hai nguồn gởi, một bộ định tuyến với bộ đệm hữu hạn
Trong trường hợp này thay đổi một chút so với trường hợp 1 (hình 3.45):
bộ đệm tại các bộ định tuyến hữu hạn và các kết nối là đáng tin cậy. Với
bộ đệm hữu hạn, gói tin đến sẽ bị huỷ khi bộ đệm đã đầy. Và khi đó, bên
gởi sẽ gởi lại gói tin đó.
Bởi vì gói tin có thể được gởi lại, nên thuật ngữ tốc độ gởi cần được xem
xét cẩn trọng. Gọi:
271
• in byte/giây là tốc độ gởi dữ liệu gốc của tầng ứng dụng xuống
socket.
• byte/giây là tốc độ gởi dữ liệu (kể cả dữ liệu gốc và dữ liệu
truyền lại) của tầng vận chuyển xuống mạng. còn được xem là
tải mạng.
Hình 3.45. Trường hợp 2: hai máy (có gởi lại) và một bộ định tuyến với
bộ đệm hữu hạn
Trong trường hợp 2, hiệu năng phụ thuộc chủ yếu vào việc truyền lại
thực hiện như thế nào. Đầu tiên, chúng ta khảo sát trường hợp không
thực là máy A có thể biết bộ đệm tại bộ định tuyến rỗng hay không và chỉ
gởi dữ liệu khi bộ đệm rỗng. Trong trường hợp này, hiện tượng mất gói
không xảy ra do đó và thông lượng của kết nối bằng in.
Trường hợp này biểu diễn trong hình 3.46a. Từ góc độ thông lượng, hiệu
năng đạt được là lý tưởng: mọi thứ gởi đi đều nhận được. Lưu ý rằng, tốc
độ gởi trung bình trong trường hợp này không vượt quá R/2 bởi vì mất
gói không xảy ra.
Tiếp theo, chúng ta xét trường hợp thật hơn: bên gởi chỉ gởi lại gói tin
khi biết chắc rằng gói tin đó đã bị mất (bên gởi gán thời gian chờ đủ lâu
để chắc rằng gói tin chưa được báo nhận đã mất). Hiệu năng trong trường
272
hợp này được biểu diễn trong hình 3.46b. Để hiểu rõ chuyện gì đang xảy
ra, chúng ta sẽ xét trường hợp tải mạng bằng R/2. Theo hình 3.46b,
khi tải mạng đạt R/2, tốc độ tầng ứng dụng gởi dữ liệu là R/3. Do đó,
trong 0.5R lượng dữ liệu gởi xuống mạng thì có 0.333R là dữ liệu gốc và
0.166R là dữ liệu gởi lại. Đây chính là một chi phí cho tắc nghẽn: bên gởi
phải gởi lại dữ liệu để bù lại dữ liệu bị mất do tràn bộ đệm.
Cuối cùng, chúng ta sẽ xét trường hợp bên gởi hết thời gian chờ sớm và
gởi lại gói tin bị chờ trong hàng đợi nhưng chưa chắc bị mất. Trong
trường hợp này, dữ liệu gốc và dữ liệu gởi lại có thể đến được bên nhận.
Và một điều hiển nhiên bên nhận chỉ nhận gói tin này một lần và huỷ các
gói tin gởi lại. Do đó, việc bộ định tuyến gởi lại các gói tin này là một
lãng phí. Bộ định tuyến có thể thực hiện tốt hơn nếu sử dụng băng thông
này để truyền gói tin khác. Vì vậy đây chính là một chi phí khác của tắc
nghẽn: việc bên gởi gởi lại gói tin không cần thiết khi độ trễ cao có thể
làm cho bộ định tuyến sử dụng băng thông để chuyển các gói tin không
cần thiết. Hình 3.46c biểu diễn thông lượng so với tải mạng với giả định
mỗi gói tin được bộ định tuyến chuyển tiếp hai lần. Bởi vì mỗi gói tin
được chuyển tiếp hai lần, thông lượng sẽ đạt tương đương R/4 khi tải
mạng đạt R/2.
Hình 3.46. Trường hợp 2: hiệu năng với bộ đệm hữu hạn
Trường hợp 3: bốn nguồn gởi, các bộ định tuyến với bộ đệm hữu hạn
và truyền qua nhiều trung gian
Trong trường hợp tắc nghẽn cuối cùng này có bốn máy gởi gói tin, mỗi
gói tin đi qua hai trung gian như hình 3.47. Giả sử rằng mỗi máy sử dụng
cơ chế thời gian chờ và gởi lại để cài đặt dịch vụ truyền dữ liệu đáng tin
273
cậy và có cùng giá trị in và các liên kết của các bộ định tuyến có băng
thông R byte/giây.
Hình 3.47. Bốn nguồn gởi, các bộ định tuyến có bộ đệm hữu hạn và
truyền qua nhiều trung gian.
Kết nối từ máy A đến máy C đi ngang qua bộ định tuyến R1 và R2. Kết
nối A – C chia sẻ bộ định tuyến R1 với kết nối D – B và chia sẻ R2 với
kết nối B - D. Với tốc độ gởi in cực nhỏ thì hiếm khi xảy ra tràn bộ đệm,
do đó thông lượng xấp xỉ với tải mạng. Với giá trị in lớn hơn một chút,
thông lượng tăng lên tương ứng bởi vì có nhiều dữ liệu gốc được gởi
xuống mạng và được chuyển đến đích đến và cũng ít khi xảy ra tràn bộ
đệm. Vì thế, với giá trị trị in nhỏ, tăng trị in nghĩa là tăng trị out.
Chúng ta sẽ xem xét trường hợp trị in (và cả ) cực kỳ lớn. Lưu lượng
của kết nối A – C đến R2 (sau đó R2 chuyển tiếp đến R1) có tốc độ đến
274
R2 in gần bằng R (băng thông giữa R1 và R2). Nếu của các kết nối
(kể cả kết nối B – D) cực kỳ lớn, tốc độ đến của luồng dữ liệu B – D tại
R2 có thể lớn hơn tốc độ đến của A – C. Bởi vì luồng dữ liệu A – C và B
– D cùng tranh nhau bộ đệm tại R2, lượng dữ liệu của luồng A – C đi qua
R2 thành công (không mất gói cho dù tràn bộ đệm) càng nhỏ khi tải của
luồng B – D càng lớn. Khi tải của luồng B – D tiến tới vô cực thì bộ đệm
trống của R2 bị lấp đầy bởi các gói tin B – D và thông lượng của kết nối
A – C tại R2 tiến về 0. Điều này cho thấy sự cân nhắc lựa chọn giữa
thông lượng với tải mạng như hình 3.48.
Hình 3.48. Hiệu năng trong trường với bộ đệm hữu hạn và nhiều trung
gian
Lý do dẫn đến việc giảm thông lượng khi tăng tải mạng một cách rõ ràng
là lượng công việc lãng phí được thực hiện. Trong trường hợp luồng dữ
liệu lớn như trên, bất kỳ gói tin nào bị huỷ tại bộ định tuyến thứ hai thì
việc chuyển tiếp gói tin tại bộ định tuyến thứ nhất xem như lãng phí.
Mạng có thể tốt hơn (càng chính xác càng tệ) nếu bộ định tuyến đầu tiên
huỷ các gói tin đó và quay về trạng thái nhàn rỗi. Và càng đạt được lợi
hơn khi bộ định tuyến đầu tiên sử dụng băng thông để chuyển tiếp gói tin
khác. Ví dụ, bộ định tuyến có thể sử dụng một thuật toán chọn gói tin để
chuyển tiếp và gán cho mỗi gói tin một độ ưu tiên. Và trong trường hợp
này, một chi phí nữa cho việc huỷ gói tin do tắc nghẽn là lãng phí đường
truyền từ bên gởi đến nơi gói tin bị huỷ.
275
VI.2 Các cách tiếp cận chống tắc nghẽn

Trong mục VII, chúng ta sẽ khảo sát giải pháp chống tắc nghẽn chi tiết
trong giao thức TCP. Trong mục này, chúng tôi trình bày hai giải pháp
tổng quát kiểm soát tắc nghẽn được dùng trong thực tế và được thảo luận
trong các kiến trúc mạng và các giao thức kiểm soát tắc nghẽn sử dụng
các giải pháp này.
Ở mức tổng quát nhất, chúng ta có thể phân biệt giữa các giải pháp kiểm
soát tắc nghẽn bằng việc tầng mạng có hỗ trợ tầng vận chuyển kiểm soát
tắc nghẽn hay không:
• Kiểm soát tắc nghẽn đầu cuối (end-to-end): trong giải pháp này,
tầng mạng không hỗ trợ tầng vận chuyển kiểm soát tắc
nghẽn.Thật chí, để pháp hiện tắc nghẽn xảy ra trong mạng, hệ
thống đầu cuối phải quan sát hành vi mạng (ví dụ gói tin mất hay
bị trễ). TCP sử dụng giải pháp này (chi tiết xem mục VII) để
kiểm soát tắc nghẽn bởi vì tầng IP không phản hồi với hệ thống
đầu cuối về tình trạng tắc nghẽn mạng. Gói tin TCP mất (do hết
thời gian chờ hay báo nhận trùng) được xem là một dấu hiệu của
hiện tượng tắc nghẽn và TCP giảm giá trị của tham số cửa sổ
nhận. Một số đề xuất kiểm soát tắc nghẽn của TCP tăng thời gian
trễ một vòng cũng đồng nghĩa với việc tăng tắc nghẽn.
• Kiểm soát tắc nghẽn với sự hỗ trợ của tầng mạng: các thành phần
trong tầng mạng (ví dụ: bộ định tuyến) phản hồi với bên gởi
trạng thái tắc nghẽn trong mạng. Việc phản hồi này chỉ đơn giản
là gởi một bit chỉ định tắc nghẽn xuống đường truyền. Giải pháp
này được sử dụng trong kiến trúc IBM SNA (Schwartz 1982) và
DEC DECnet (Jain 1989, Ramakrishnan 1990) trước đây và gần
đây được đề xuất cho mạng TCP/IP (Floyd TCP 1994, RFC
3168) và được đề xuất cho kiểm soát tắc nghẽn ABR trong ATM.
Đối với giải pháp có sự hỗ trợ của tầng mạng, thông tin tắc nghẽn về
cơ bản được tầng mạng phản hồi cho bên gởi bằng một trong hai cách
trình bày trong hình 3.49. Cách phản hồi trực tiếp được gởi trực tiếp
từ bộ định tuyến đến bên gởi bằng gói tin tắc nghẽn (choked packet)
để nói rằng “tôi đã bị tắc nghẽn”. Với cách thứ hai, bộ định tuyến
đánh dấu hay cập nhật một trường trong gói tin từ bên gởi đến bên
276
nhận để chỉ định tắc nghẽn. Khi nhận gói tin đã được đánh dấu tắc
nghẽn, bên nhận thông báo cho bên gởi tắc nghẽn xảy ra. Và giải pháp
này mất thời gian trễ ít nhất một vòng.
Hình 3.49. Hai cách phản hồi thông tin tắc nghẽn mạng.
VI.3 Một ví dụ về kiểm soát tắc nghẽn có sự hỗ trợ của tầng
Mạng: Kiểm soát tắc nghẽn trong ATM ABR
Mục này mô tả tóm tắt thuật toán kiểm soát tắc nghẽn dùng trong ATM
ABR – một giao thức sử dụng giải pháp có sự hỗ trợ của tầng mạng. Lưu
ý rằng chúng tôi không mô tả chi tiết kiến trúc của ATM mà chỉ chứng
minh sự khác biệt giải pháp này với giải pháp trong giao thức TCP.
Chúng tôi trình bày một chút về kiến trúc của ATM để hiểu rõ giao thức
kiểm soát tắc nghẽn ABR.
Về cơ bản, ATM dùng giải pháp hướng kết nối mạch ảo (virtual curcuit,
VC) để chuyển tiếp các gói tin. Như đã trình bày trong chương 1, với giải
pháp chuyển tiếp gói tin này, mỗi thiết bị chuyển tiếp trên đường đi từ
nguồn đến đích đến đều quản lý trạng thái của mạch ảo nối giữa nguồn
và đích đến. Trạng thái này cho phép các thiết bị chuyển tiếp truy vết
hành vi của từng người gởi (ví dụ như tốc độ gởi) và có những hành động
kiểm soát tắc nghẽn cụ thể (như là gởi tín hiệu đến bên gởi giảm tốc độ
gởi khi tắc nghẽn mạng). Trạng thái này giúp cho ATM thích hợp với
việc dùng giải pháp có sự hỗ trợ của tầng mạng.
277
ABR được thiết kế như một dịch vụ truyền dữ liệu linh hoạt. Khi tải
mạng thấp, dịch vụ ABR tận dụng băng thông trống, khi mạng bị tắc
nghẽn, ABR giảm tốc độ gởi đến tốc độ tối thiểu. Chi tiết về kiểm soát
tắc nghẽn trong ATM ABR được giới thiệu trong Jain 1996.
Hình 3.50 minh hoạ mô hình kiểm soát tắc nghẽn ATM ABR. Trong
phần này, chúng ta điều chỉnh một số thuật ngữ trong ATM như: thiết bị
chuyển tiếp thay cho bộ định tuyến, khối (cell) thay cho gói tin (packet).
Với dịch vụ ABR, các khối dữ liệu được truyền từ nguồn đến đích đến
thông qua các thiết bị chuyển tiếp trung gian. Xen kẽ các khối dữ liệu là
các khối quản lý tài nguyên (resource-management cells, RM cells). Các
khối quản lý tài nguyên này có thể được dùng để thu thập thông tin tắc
nghẽn giữa các máy và thiết bị chuyển tiếp. Khi một khối quản lý tài
nguyên đến đích đến nó sẽ được gởi ngược trở lại bên gởi (có thể đích
đến thay đổi thông tin trong khối này). Một thiết bị chuyển tiếp cũng có
thể phát sinh khối quản lý tài nguyên này và gởi trực tiếp cho nguồn gởi.
Vì thế, khối quản lý tài nguyên có thể dùng để phản hồi trực tiếp hay
phản hồi thông qua bên nhận như hình 3.50.
Hình 3.50. Mô hình dịch vụ kiểm soát tắc nghẽn ATM ABR
Kiểm soát tắc nghẽn ATM ABR là một giải pháp dựa trên tốc độ. Nghĩa
là, bên gởi phải tính toán một tốc độ tối đa có thể gởi dữ liệu và điều
chỉnh. ABR cung cấp ba cơ chế báo hiệu thông tin tắc nghẽn từ thiết bị
chuyển tiếp đến bên nhận:
278
• Bit EFCI. Mỗi khối dữ liệu chứa một bit chỉ định tắc nghẽn EFCI
(Explicit Forward Congestion Indication). Thiết bị chuyển tiếp
trong mạng bị tắc nghẽn sẽ gán bit EFCI bằng 1 để báo hiệu tắc
nghẽn đến máy đích đến. Đích đến phải kiểm tra bit EFCI trong
mỗi khối dữ liệu nó nhận được. Khi đích đến nhận một khối quản
lý tài nguyên, nó sẽ gán bit CI (Congestion Indication) trong khối
quản lý tài nguyên là 1 nếu bit EFCI trong các khối dữ liệu mà nó
vừa nhận được đều là 1. Sau đó, đích đến sẽ gởi khối quản lý tài
nguyên này ngược lại cho bên gởi. Bằng cách sử dụng các bit
EFCI và CI trong các khối, bên gởi có thể được thông báo tình
trạng tắc nghẽn tại các thiết bị chuyển tiếp trong mạng.
• Bit CI và NI. Như đã trình bày ở trên, các khối quản lý tài nguyên
được gởi xen kẽ các khối dữ liệu. Tỉ lệ xen kẽ khối quản lý tài
nguyên là tham số có thể thay đổi và mặc định là 1:32 (cứ 32 khối
dữ liệu có 1 khối quản lý tài nguyên). Các khối quản lý tài nguyên
có một bit chỉ định tắc nghẽn CI và bit không tăng NI (No
Increase). Các thiết bị chuyển tiếp trong mạng tắc nghẽn có thể
thay đổi giá trị của các bit này. Cụ thể, thiết bị chuyển tiếp gán bit
NI là 1 khi mạng có dấu hiệu tắc nghẽn và gán bit CI là 1 khi
mạng bị tắc nghẽn. Khi máy đích đến nhận một khối quản lý tài
nguyên, nó sẽ gởi khối này ngược lại bên gởi với giá trị các bit CI
và NI không thay đổi (trừ trường hợp đích đến gán bit CI là 1
theo cơ chế bit EFCI đã mô tả ở trên)
• Gán ER. Mỗi khối quản lý tài nguyên cũng chứa một trường tốc
độ ER (explicit rate) có kích thước là 2 byte. Một thiết bị chuyển
tiếp bị tắc nghẽn có thể có tốc độ nhỏ hơn trường ER trong khối
quản lý tài nguyên đi qua nó. Trong trường hợp này, trường ER sẽ
được gán bằng tốc độ có thể gởi nhỏ nhất trong tất cả các thiết bị
chuyển tiếp từ bên gởi đến bên nhận.
Nguồn gởi ATM ABR sẽ điều chỉnh tốc độ gởi dữ liệu bằng một hàm
theo giá trị của CI, NI và ER trong khối quản lý tài nguyên trả về. Chi
tiết xem trong tài liệu Jain 1996.
279
VII. Kiểm soát tắc nghẽn trong TCP

Trong phần này, chúng ta sẽ khảo sát chi tiết cơ chế kiểm soát tắc nghẽn
trong TCP. Như đã trình bày trong mục V, TCP cung cấp một dịch vụ
truyền tải đáng tin cậy giữa hai tiến trình chạy trên hai máy khác nhau.
Một thành phần quan trọng nữa của TCP là cơ chế kiểm soát tắc nghẽn.
Như đã trình bày, TCP sử dụng cơ chế kiểm soát tắc nghẽn đầu cuối
(end-to-end) bởi vì tầng IP không cung cấp cơ chế phản hồi thông tin tắc
nghẽn cho hệ thống đầu cuối.
Giải pháp mà TCP sử dụng là mỗi bên gởi giới hạn tốc độ gởi dữ liệu lên
một kết nối. Nếu bên gởi TCP nhận ra ít tắc nghẽn trên đường đi từ nó
đến đích đến, bên gởi TCP tăng tốc độ gởi dữ liệu; ngược lại nếu có dấu
hiệu tắc nghẽn thì nó giảm tốc độ. Tuy nhiên giải pháp này đưa ra ba câu
hỏi. Thứ nhất, bên gởi TCP giới hạn tốc độ gởi lên một kết nối như thế
nào? Thứ hai, bên gởi phát hiện tắc nghẽn trên đường đi giữa nó với đích
đến như thế nào? Và cuối cùng là bên gởi sử dụng thuật toán nào để thay
đổi tốc độ gởi dữ liệu như một hàm phát hiện tắc nghẽn?
Đầu tiên, chúng ta sẽ khảo sát xem bên gởi TCP giới hạn tốc độ gởi dữ
liệu lên kết nối của nó như thế nào. Trong mục V, chúng ta đã biết mỗi
bên của một kết nối TCP bao gồm một bộ đệm nhận, một bộ đệm gởi, và
một vài tham số (ByteNhanCuoi, CuaSoNhan…). Cơ chế kiểm soát tắc
nghẽn thực thi tại bên gởi TCP lưu thêm một tham số nữa là cửa sổ tắc
nghẽn (congestion window). Cửa sổ tắc nghẽn, ký hiệu là cstn, tạo ra một
ràng buộc về tốc độ bên gởi gởi dữ liệu xuống mạng. Đặc biệt, lượng dữ
liệu chưa được báo nhận tại bên gỡi được được vượt quá giá trị nhỏ nhất
của cửa sổ tắc nghẽn và cửa sổ nhận:
ByteGoiCuoi – ByteBaoNhanCuoi  min (CuaSoNhan, cstn)
Để tập trung vào điều khiển tắc nghẽn, giả sử rằng bộ đệm nhận lớn để
bỏ qua ràng buộc cửa sổ nhận, và do đó lượng dữ liệu chưa được báo
nhận chỉ còn phụ thuộc vào cửa sổ tắc nghẽn. Đồng thời, giả sử bên gởi
luôn luôn có dữ liệu để gởi và tất cả các gói tin trong cửa sổ tắc nghẽn đã
gởi.
Những ràng buộc ở trên giới hạn lượng dữ liệu chưa được báo nhận tại
bên gởi và vì thế gián tiếp giới hạn tốc độ gởi. Để hiểu rõ vấn đề này,
chúng ta sẽ khảo sát một kết nối mà mất gói và độ trễ gởi dữ liệu không
280
đáng kể. Tại thời điểm bắt đầu mỗi RTT, ràng buộc này cho phép bên gởi
gởi cstn bytes dữ liệu xuống kết nối; và tại thời điểm kết thúc RTT, bên
gởi nhận báo nhận cho dữ liệu đó. Vì thế, tốc độ gởi của bên gởi là
cstn/RTT byte/giây. Bằng việc điều chỉnh tham số cstn, bên gởi có thể
điều chỉnh tốc độ gởi dữ liệu xuống kết nối.
Tiếp theo, chúng ta xét xem bên gởi TCP phát hiện tắc nghẽn giữa nó với
đích đến như thế nào. Định nghĩa “sự kiện mất gói” tại bên gởi TCP xuất
hiện khi hết thời gian chờ hoặc nhận 3 gói tin báo nhận ACK trùng từ
bên nhận. Khi xảy ra tắc nghẽn nặng, một hay nhiều bộ định tuyến dọc
đường đi của gói tin bị tràn bộ đệm làm cho gói tin TCP bị huỷ. Do đó,
gây ra hiện tượng mất gói tại bên gởi (do hết thời gian chờ hoặc nhận gói
tin báo nhận trùng).
Bây giờ chúng ta sẽ khảo sát trường hợp tối ưu hơn khi không có tắc
nghẽn mạng: không xảy ra mất gói. Trong trường hợp này, bên gởi TCP
sẽ nhận được báo nhận cho các gói tin chưa được báo nhận trước đó. Và
đây là một dấu hiệu tốt cho bên gởi TCP rằng các gói tin đã gởi thành
công đến đích đến. Khi đó, bên gởi TCP sẽ tăng kích thước cửa sổ tắc
nghẽn (đồng nghĩa tăng tốc độ gởi). Nếu các gói tin báo nhận đến với tốc
độ chậm (ví dụ khi đường đi từ bên gởi đến bên nhận có độ trễ cao hoặc
có băng thông thấp) thì cửa sổ tắc nghẽn cũng tăng chậm
Thuật toán điều khiển tắc nghẽn của TCP

Thuật toán này được mô tả đầu tiên trong Jacobson 1988 và được chuẩn
hóa trong RFC 2581. Thuật toán gồm ba thành phần chính: (1) khởi động
chậm (slow start), (2) tránh tắc nghẽn (congestion avoidance) và (3) phục
hồi lỗi nhanh (fast recovery). Khởi động chậm và tránh tắc nghẽn là hai
thành phần bắt buộc của TCP. Chúng khác nhau ở chỗ tăng giá trị cstn
như thế nào khi nhận các gói báo nhận: giai đoạn khởi động chậm tăng
giá trị cstn nhanh hơn. Thành phần phục hồi lỗi không là thành phần bắt
buộc đối với bên gởi TCP.
Khởi động chậm (slow start)
Khi một kết nối TCP được thiết lập, tiến trình ứng dụng tại bên gởi bắt
đầu ghi dữ liệu xuống bộ đệm TCP của bên gởi. TCP chia khối dữ liệu
281
thành từng đoạn dữ liệu với kích thước bằng với giá trị MSS và đóng gói
thành các gói tin TCP; sau đó đưa các gói tin này xuống tầng mạng để
truyền đi trên mạng. TCP điều chỉnh giá trị cstn mỗi khi gởi một gói tin
xuống mạng. Ban đầu, TCP khởi tạo giá trị cstn bằng 1 MSS (do đó tốc
độ gởi là MSS/RTT byte/giây). TCP tăng giá trị cstn 1 MSS mỗi khi gởi
gói tin và được báo nhận trước khi hết thời gian chờ.
Ví dụ trong hình 3.51, đầu tiên TCP gởi một gói tin xuống mạng và chờ
nhận báo nhận. Khi gói tin báo nhận cho gói tin đầu tiên này đến trước
khi hết thời gian chờ, bên gởi TCP tăng cstn lên 1 MSS và gởi xuống
đường truyền 2 gói tin với kích thước tối đa. Nếu báo nhận cho hai gói
tin này lại đến trước khi hết thời gian chờ, TCP tiếp tục tăng 1 MSS cho
mỗi gói tin báo nhận (cstn tăng thành 4 MSS) và tiếp tục gởi 4 gói tin
xuống đường truyền. Kết quả là, trong giai đoạn này, tốc độ gởi tăng gấp
đôi sau mỗi RTT. Vì thế, tốc độ gởi ban đầu nhỏ nhưng tăng lên theo
hàm mũ trong pha khởi động chậm.
Hình 3.51
Quá trình tăng tốc độ gởi theo hàm mũ này tiếp diễn khi (1) cstn nhỏ hơn
một ngưỡng cho phép (ssthresh, slow start threshold) và (2) các gói báo
nhận đến trước khi hết thời gian chờ. Đầu tiên, nếu xuất hiện mất gói do
hết thời gian chờ, TCP gán giá trị cstn = 1 và bắt đầu lại pha khởi động
chậm. Đồng thời, gán giá trị ssthresh bằng ½ giá trị cstn khi phát hiện tắc
nghẽn. Và một khi, giá trị cstn bằng với ssthresh, pha khởi động chậm kết
thúc và chuyển sang pha tránh tắc nghẽn. Thứ hai, khi TCP nhận 3 gói tin
báo nhận trùng, TCP thực hiện pha phục hồi lỗi. Sơ đồ 3.52 mô tả sơ đồ
trạng thái và các hành vi kiểm soát tắc nghẽn của TCP.
Hình 3.52
Tránh tắc nghẽn (congestion avoidance)
Trong giai đoạn tránh tắc nghẽn, giá trị của tham số cwnd xấp xỉ phân
nửa giá trị của nó khi có dấu hiệu tắc nghẽn lần cuối. Vì thế, thay vì tăng
giá trị cwnd gấp đôi sau mỗi RTT, TCP điều chỉnh bằng một giải pháp
thận trọng hơn: tăng một MSS sau mỗi RTT (RFC 2581). Điều này có
282
thể thực hiện bằng nhiều cách. Một giải pháp chung mà bên gởi TCP
tăng giá trị cwnd MSS byte mỗi khi nhận được một báo nhận mới. Ví dụ,
nếu MSS = 14600 byte và cwnd = 14600 byte, sau đó gởi 10 gói tin trong
1 RTT. Mỗi khi nhận được báo nhận ACK (giả sử một ACK cho một gói
tin), giá trị cwnd được tăng 1/10 MSS, do đó, sau 1 RTT, giá trị cwnd sẽ
được tăng 1 MSS.
Nhưng khi nào việc tăng tuyến tính trong giai đoạn này kết thúc? Thuật
toán tránh tắc nghẽn cũng thực hiện giống vậy khi xuất hiện sự kiện hết
thời gian chờ. Bởi vì trong giai đoạn khởi động chậm: giá trị cwnd được
gán bằng 1 MSS và giá trị ssthresh bị giảm một nữa khi xuất hiện mất
gói. Tuy nhiên, sự kiện trùng ACK cũng được xem là một hiện tượng mất
gói. Trong trường hợp này, mạng vẫn tiếp tục chuyển các gói tin từ bên
gởi đến bên nhận. Vì thế, hành vi của TCP cho sự kiện mất gói này ít
quyết liệt hơn khi xuất hiện sự kiện mất gói do hết thời gian chờ: TCP
giảm ½ giá trị của cwnd và cập nhật giá trị ssthresh bằng ½ giá trị cwnd.
Lúc này TCP chuyển sang giai đoạn phục hồi nhanh.
Phục hồi nhanh (fast recovery)
Việc cwnd được tăng 1 MSS cho mỗi lần nhận ACK trùng cho các gói
tin bị mất làm cho TCP chuyển sang trạng thái phục hồi nhanh. Thậm
chí, khi một gói tin ACK cho gói tin bị mất đến bên gởi, TCP chuyển
sang trạng thái tắc nghẽn sau khi giảm giá trị cwnd. Nếu sự kiện hết thời
gian chờ xuất hiện, TCP chuyển từ trạng thái phục hồi nhanh sang trạng
thái khởi động chậm sau khi thực hiện giống như trong trạng thái khởi
động chậm và tránh tắc nghẽn: giá trị cwnd được gán bằng 1 MSS và giá
trị ssthresh được gán bằng một nửa giá trị cwnd khi xảy ra mất gói.
Giai đoạn phục hồi nhanh là một giai đoạn khuyến khích chứ không bắt
buộc. Một số phiên bản trước đây của TCP, TCP Tahoe, gán cửa sổ tắc
nghẽn bằng 1 MSS và chuyển sang trạng thái khởi động chậm không
điều kiện khi xảy ra mất gói do hết thời gian chờ hoặc do nhận gói tin ba
ACK trùng. Phiên bản mới hơn của TCP, TCP Reno, có tích hợp giai
đoạn phục hồi nhanh.
Hình 3.53 minh hoạ cho sự cải tiến của cửa sổ tắc nghẽn TCP cho cả
TCP Tahoe và TCP Reno. Trong hình này, giá trị ngưỡng ssthresh được
khởi tạo bằng 8 MSS. Trong 8 vòng truyền dữ liệu đầu tiên, hành động
283
của Tahoe và Reno giống nhau. Cửa sổ tắc nghẽn tăng theo hàm mũ
trong suốt giai đoạn khởi động chậm và chạm đến giá trị ngưỡng tại vòng
truyền dữ liệu thứ tư. Sau đó, cửa sổ tắc nghẽn tăng tuyến tính cho đến
khi nhận ba ACK trùng chỉ sau khi vòng truyền dữ liệu thứ 8. Lưu ý rằng
cửa sổ tắc nghẽn là 12MSS khi xảy ra mất gói. Sau đó, giá trị của
ssthresh được gán bằng ½cwnd = 6MSS. Với TCP Reno, giá trị cửa sổ
tắc nghẽn được gán bằng 6MSS và sau đó tăng tuyến tính. Với TCP
Tahoe, cửa sổ tắc nghẽn được gán bằng 1MSS và tăng theo hàm mũ cho
đến khi đạt giá trị ssthresh và tại đó nó sẽ tăng tuyến tính.
Hình 3.53
Hình 3.52 mô tả các trạng thái của TCP trong thuật toán kiểm soát tắc
nghẽn: khởi động chậm (slow start), tránh tắc nghẽn (congestion
avoidance) và phục hồi nhanh (fast recovery). Sơ đồ cũng mô tả khi nào
truyền gói tin mới hay truyền lại gói tin. Mặc dù việc phân biệt giữa kiểm
soát lỗi hay gởi lại và kiểm soát tắc nghẽn trong TCP là quan trọng, việc
hai cơ chế này kết nối với nhau như thế nào cũng là một điều quan trọng.
TCP trong tương lai
Kiểm soát tắc nghẽn trong TCP được cải tiến qua nhiều năm và vẫn đang
được tiếp tục cải tiến. Cơ chế kiểm soát tắc nghẽn tóm tắt trong TCP
được trình bày trong RFC 2581 vào những năm cuối 1990, và thảo luận
về các phát triển thêm cơ chế kiểm soát tắc nghẽn của TCP trong Floyd
2001. Điều tốt cho Internet khi các kết nối TCP được mang trong luồng
dữ liệu của SMTP, FTP, Telnet thì không nhất thiết tốt cho HTTP trong
Internet ngày nay hoặc cho Internet trong tương lai với các dịch vụ mà
chúng ta vẫn đang mơ đến.
Nhu cầu cải tiến TCP có thể được minh hoạt bằng cách xem xét các kết
nối TCP tốc độ cao dùng cho các ứng dụng tính toán lưới (grid-
computing) (Foster 2002). Ví dụ, xét kết nối TCP với kích thước mỗi gói
tin là 1500 byte và RTT là 100ms và tốc độ truyền dữ liệu truyền trên kết
nối này là 10Gbps. Theo RFC 3649, để đạt được thông lượng 10Gbps,
kích thước cửa sổ tắc nghẽn trung bình là 83.333 gói tin. Đây là 1 con số
284
rất lớn do đó chúng ta cần xem xét đến trường hợp một trong 83.333 gói
tin này mất. Và chuyện gì sẽ xảy ra khi mất gói? Hay tìm một cách khác:
tỉ lệ gói tin bị mất là bao nhiêu để vẫn đạt được thông lượng 10Gbps?
Một hàm tính thông lượng từ tỉ lệ mất gói (L), thời gian 1 vòng (RTT), và
kích thước gói tin tối đa (MSS) như sau:
Theo công thức này, để đạt được thông lượng 10Gbps, thuật toán kiểm
soát tắc nghẽn trong TCP ngày nay có thể cho phép xác suất mất gói của
từng gói tin là 2.10-10 (hay trong 5,000,000,000 gói tin chỉ có thể có 1
gói tin bị mất). Do đó, nhiều nhà nghiên cứu đề xuất phiên bản mới của
TCP cho môi trường truyền tốc độ cao như thế như Jin 2004, RFC 3649,
Kelly 2003, Ha 2008.
Tính công bằng
Xét k kết nối TCP giữa các điểm đầu cuối khác nhau và cùng đi qua một
liên kết chung với tốc độ truyền là R bps. Và giả sử rằng mỗi kết nối đều
có nhu cầu truyền một tập tin lớn và không có luồng dữ liệu UDP nào đi
qua liên kết chung. Cơ chế kiểm soát tắc nghẽn được xem là công bằng
nếu tốc độ truyền trung bình của mỗi kết nối là R/k.
Xét một trường hợp đơn giản là hai kết nối TCP cùng chia sẻ một liên kết
với tốc độ truyền là R bps như hình 3.54. Giả sử hai kết nối có cùng RTT
và MSS (để khi chúng có cùng kích thước cửa sổ tắc nghẽn thì có cùng
thông lượng) và cần gởi một lượng lớn dữ liệu; đồng thời không có kết
nối TCP nào hay luồng dữ liệu UDP chia sẻ liên kết chung này. Và
chúng ta bỏ qua giai đoạn khởi động chậm và giả sử các kết nối luôn ở
trong giai đoạn tránh tắc nghẽn.
Hình 3.54 (3.55 sách)

Hình 3.55 thể hiện thông lượng của hai kết nối TCP. Nếu TCP chia sẻ
liên kết với băng thông bằng nhau cho các kết nối, thông lượng tập trung
xung quanh đường 45o so với gốc. Và một điều lý tưởng là tổng thông
lượng của hai kết nối TCP bằng R. Vì thế, mục tiêu là đạt được thông
285
lượng rơi vào những điểm gần điểm giao giữa đường chia sẻ băng thông
bằng nhau và đường tối ưu băng thông đầy đủ như hình 3.55.
Hình 3.55
Giả sử rằng kích thước cửa sổ tắc nghẽn của TCP được cho trước, thông
lượng của kết nối 1 và 2 được thể hiện ở điểm A trong hình 3.55. Bởi vì,
tổng băng thông giữa hai kết nối nhỏ hơn R, không xảy ra mất gói và cả
hai kết nối sẽ tăng kích thước cửa sổ tắc nghẽn của chúng 1 MSS mỗi
RTT như mô tả trong thuật toán kiểm soát tắc nghẽn của TCP. Vì thế,
tổng thông lượng của hai kết nối tập trung xung quanh đường 45o và bắt
đầu từ điểm A. Thậm chí, tổng băng thông của hai kết nối có thể lớn hơn
R và có thể xảy ra mất gói. Giả sử rằng, hiện tượng mất gói của kết nối 1
và 2 xảy ra khi thông lượng đạt đến điểm B. Cả hai kết nối giảm kích
thước cửa sổ tắc nghẽn một nữa. Và kết quả là thông lượng đạt đến điểm
C theo chiều hướng giảm một nữa từ điểm B đến điểm gốc ban đầu. Vì
tổng thông lượng của hai kết nối nhỏ hơn R tại điểm C nên cả hai kết nối
tăng thông lượng dọc theo đường 45o và bắt đầu tại điểm C. Và khi đó
hiện tượng mất gói lại xảy ra tại điểm D, cả hai kết nối lại giảm kích
thước cửa sổ tắc nghẽn một nữa và cứ thế tiếp tục. Như vậy, băng thông
của hai kết nối dao động xung quanh đường chia sẻ băng thông bằng
nhau.
Trong trường hợp lý tưởng, chúng ta giả sử rằng các kết nối chia sẻ
chung một liên kết, có cùng RTT và nối giữa các cặp đầu cuối khác nhau.
Trong thực tế, những điều kiện này không thoả, các ứng dụng khách –
chủ có thể đạt băng thông không bằng nhau trên liên kết chia sẻ. Trong
thực tế, khi có nhiều kết nối chia sẻ cùng một liên kết, các kết nối có
RTT càng nhỏ càng có thể chiếm dụng được băng thông còn trống tại
liên kết đó nhanh hơn và vì thế đạt được thông lượng cao hơn các kết nối
có RTT lớn hơn (Lakshman 1997).
Tính công bằng và UDP
Nhiều ứng dụng đa phương tiện (multimedia application) như điện thoại
Internet, hội thảo video, thường không chạy trên nền TCP do chúng
không muốn tốc độ truyền bị giảm ngay cả khi mạng bị tắc nghẽn. Do đó,
các ứng dụng này chạy trên nền giao thức UDP, một giao thức không tích
hợp kiểm soát tắc nghẽn. Khi chạy trên nền UDP, ứng dụng có thể đưa
286
audio và video của chúng xuống mạng với tốc độ hằng số ngay cả khi
mất gói thay vì phải giảm tốc độ để công bằng tại các thời điểm có tắc
nghẽn hay mất gói. Theo TCP, các ứng dụng đa phương tiện chạy trên
nền UDP thì không công bằng – chúng không hợp tác với các kết nối
khác hoặc điều chỉnh tốc độ truyền tương ứng. Bởi vì kiểm soát tắc
nghẽn trong TCP sẽ giảm tốc độ truyền khi xảy ra tắc nghẽn, trong khi
UDP không thực hiện như vậy và có thể lấn áp luồng dữ liệu TCP. Do
đó, một bài toán ngày nay cần nghiên cứu là cải tiến thuật toán kiểm soát
tắc nghẽn cho Internet để ngăn chặn luồng dữ liệu UDP làm tê liệt
Internet (Floyd 1999, Floyd 2000, Kohler 2006).
Tính công bằng và kết nối TCP song song
Tuy nhiên, cho dù chúng ta có thể kiểm soát luồng dữ liệu UDP để đảm
bảo tính công bằng thì vấn đề này vẫn chưa được giải quyết triệt để. Bởi
vì, không có gì có thể ngăn cản các ứng dụng TCP sử dụng các kết nối
song song. Ví dụ, các trình duyệt web thường sử dụng các kết nối TCP
song song để truyền nhiều đối tượng trong một trang web. Khi một ứng
dụng sử dụng nhiều kết nối TCP song song, nó sẽ chiếm băng thông
nhiều hơn trên liên kết chia sẻ. Như một ví dụ, xét một liên kết có tốc độ
R bps hỗ trợ cho 9 ứng dụng khách – chủ, với mỗi ứng dụng sử dụng một
kết nối TCP. Nếu có thêm một ứng dụng sử dụng một kết nối TCP nữa,
mỗi ứng dụng chiếm một băng thông xấp xỉ R/10. Nhưng nếu ứng dụng
mới sử dụng 11 kết nối TCP song song, ứng dụng mới chiếm một tốc độ
lớn hơn R/2 và gây ra sự không công bằng. Bởi vì luồng dữ liệu web tràn
ngập khắp Internet, nên có nhiều kết nối song song là phổ biến.
287
Chương 4. Tầng Mạng
Chương 4
TẦNG MẠNG
Như đã được thảo luận ở chương trước, tầng Vận chuyển cung cấp các
kiểu truyền thông giữa tiến trình với tiến trình bằng việc sử dụng các
dịch vụ truyền thông host-đến-host của tầng Mạng mà không biết thực
sự các dịch vụ của tầng Mạng được cài đặt như thế nào. Vì vậy chúng
ta có thể băn khoăn rằng, điều gì đã xảy ra ở các dịch vụ truyền thông
host-đến-host tại tầng Mạng?
Chương này tìm hiểu về cách tầng Mạng triển khai dịch vụ truyền
thông host-đến-host. Chúng ta sẽ thấy rằng, không giống như tầng
Vận chuyển, tầng Mạng được triển khai ở mỗi host và các bộ định
tuyến trong hệ thống mạng. Vì vậy, các giao thức tầng Mạng là các
giao thức được xem như có nhiều thách thức nhất và thú vị nhất trong
chồng giao thức mạng.
Tầng Mạng cũng là một trong những tầng phức tạp nhất trong chồng
giao thức mạng, vì vậy có rất nhiều vấn đề để tìm hiểu. Chương này sẽ
tìm hiểu tổng quan tầng Mạng và các dịch vụ nó cung cấp. Hai cách
tiếp cận về cấu trúc việc phân phối các gói tin ở tầng Mạng là mô hình
gói dữ liệu (datagram model) và mô hình mạch ảo (virtual circuit
model) mà đã được đề cập ở Chương 1. Ngoài ra, vai trò quan trọng
của địa chỉ trong việc phân phối gói tin tới host đích cũng được nói
đến.
Chương này cũng tìm hiểu sự khác biệt cơ bản giữa chức năng chuyển
tiếp (forwarding) và chức năng định tuyến(routing) của tầng Mạng.
Chuyển tiếp liên quan đến việc chuyển một gói tin từ một liên kết đi
vào (incoming link) ra một một liên kết đi ra (outgoing link) bên trong
một bộ định tuyến. Định tuyến liên quan đến việc tất cả các bộ định
288
tuyến trên mạng tập hợp các thông tin tương tác qua lại thông qua các
giao thức định tuyến để xác định các con đường đi tốt mà gói tin được
chuyển đi từ nguồn tới đích.
Để hiểu hơn về việc chuyển tiếp gói tin, chương này tìm hiểu kiến trúc
phần cứng và cách tổ chức của một bộ định tuyến. Sau đó, việc
chuyển tiếp gói tin trên mạng Internet cùng với giao thức Internet
Protocol (IP) được tìm hiểu. Chúng ta sẽ xem xét việc định địa chỉ tại
tầng Mạng và định dạng gói tin IPv4. Chúng ta cũng sẽ tìm hiểu việc
phân giải địa chỉ mạng (NAT), phân mảnh gói tin, giao thức thông
điệp điều khiển Internet (ICMP) và IPv4.
Tiếp theo, chúng ta sẽ quan tâm tới chức năng định tuyến tại tầng
Mạng. Chúng ta sẽ thấy rằng công việc của giải thuật định tuyến là
xác định các con đường đi tốt từ nơi gửi đến nơi nhận. Đầu tiên,
chúng ta sẽ tìm hiểu lí thuyết về các giải thuật định tuyến, tập trung
vào hai lớp thuật giải quan trọng nhất: trạng thái liên kết (link-state)
và vectơ khoảng cách (distance vector). Khi độ phức tạp của các giải
thuật định tuyến ngày càng tăng bởi số lượng các bộ định tuyến trên
mạng tăng, các cách tiếp cận định tuyến phân cấp sẽ được chú ý. Sau
đó, chúng ta sẽ tìm hiểu làm thế nào các vấn đề lí thuyết ở trên được
triển khai trong thực tế khi chúng ta tìm hiểu các giao thức định tuyến
bên trong một hệ thống tự trị (autonomous system) trên Internet (RIP,
OSPF, IS-IS) và giao thức định tuyến giữa các hệ thống tự trị, BGP.
Chương này kết thúc với một thảo luận về định tuyến broadcast và
multicast.
I. Giới thiệu
Hình 4.1 mô tả một mạng đơn giản với hai host, H1 và H2 và vài bộ
định tuyến trên con đường giữa H1 và H2. Giả sử H1 đang gửi dữ liệu
cho H2, hãy xem xét vai trò của tầng Mạng ở các host và các bộ định
tuyến này. Tầng Mạng tại H1 nhận phân đoạn dữ liệu (segment) từ
tầng Vận chuyển gửi xuống, đóng gói mỗi phân đoạn thành gói tin
tầng Mạng (datagram) sau đó gửi gói gói tin này cho bộ định tuyến kề
với nó, R1. Tại host nhận, H2, tầng Mạng nhận các gói tin từ bộ định
tuyến kề với nó R2, phân tách thành các gói tin tầng Vận chuyển và
phân phối các gói tin thu được này cho tầng Vận chuyển tại H2. Vai
289
trò chính của các bộ định tuyến là chuyển các gói tin từ các liên kết
đầu vào ra các liên kết đầu ra. Lưu ý rằng các bộ định tuyến trong
hình 4.1 được trình bày với chồng giao thức mạng đã bị cắt bớt, không
có các tầng cao hơn tầng Mạng bởi vì bộ định tuyến không chạy các
ứng dụng và các giao thức tầng Vận chuyển như đã được đề cập ở
Chương 2 và Chương 3.
ISP quốc gia/

quốc tê
Mạng di động
Tầng mạng
Tầng liên kết
Hệ thống cuối H1 Tầng vật lí
Tầng ứng dụng Mạng gia đình

Bộ định tuyến R1
Tầng vận chuyển
Tầng mạng ISP địa
Tầng mạng
phương/vùng
Tầng liên kết
Tầng liên kết Tầng mạng
Tầng vật lí
Tầng vật lí Tầng liên kết
Bộ định tuyến R2 Tầng vật lí
Tầng mạng
Tầng liên kết
Tầng vật lí
Hệ thống cuối H2
Tầng ứng dụng
Tầng vận chuyển
Tầng mạng
Mạng công ty Tầng liên kết
Tầng vật lí
Hình 4.1 – Tầng Mạng
290
I.1 Chuyển tiếp và định tuyến

Vai trò của tầng Mạng khá đơn giản: chuyển các gói tin từ một host
gửi đến một host nhận. Để làm được điều này, hai chức năng quan
trọng của tầng Mạng là:
▪ Chuyển tiếp: Khi một gói tin đến một liên kết đầu vào của một
bộ định tuyến, bộ định tuyến phải chuyển gói tin tới liên kết đầu
ra tương ứng. Ví dụ, khi một gói tin đến từ host H1 đến bộ định
tuyến R1 phải được chuyển đến bộ định tuyến tiếp theo trên con
đường đến H2. Trong phần 4.3, chúng ta sẽ tìm hiểu sâu hơn về
một bộ định tuyến xác định làm thế nào một gói tin được chuyển
tiếp từ một liên kết đầu vào tại một bộ định tuyến ra một liên kết
đầu ra.
▪ Định tuyến: Tầng Mạng phải xác định đường lộ trình hay đường
đi của gói tin từ nơi gửi đến nơi nhận. Các giải thuật tính toán các
con đường này được xem như các giải thuật định tuyến. Một giải
thuật định tuyến sẽ xác định đường đi từ nguồn tới đích, ví dụ,
con đường mà các gói tin đi từ H1 đến H2.
Thuật ngữ chuyển tiếp và định tuyến thường được hoán chuyển qua
lại bởi nhiều người khi thảo luận về tầng Mạng. Chúng ta sẽ sử dụng
những thuật ngữ này chính xác hơn trong cuốn sách này. Chuyển tiếp
đề cập đến hành động cục bộ tại mỗi bộ định tuyến cho việc chuyển
gói tin từ một cổng liên kết đầu vào sang một cổng liên kết đầu ra
thích hợp. Định tuyến đề cập đến việc xác định con đường đầu cuối-
đầu cuối (end to end) mà gói tin sẽ đi qua từ nguồn tới đích trên phạm
vi một hệ thống mạng rộng lớn. Tương tự như việc đi du lịch, chúng ta
hãy xem xét cuộc hành trình từ TPHCM đến Hà Nội được thực hiện
bởi khách du lịch của chúng ta trong phần 1.3.2. Suốt cuộc hành trình Commented [m
này, lái xe đi qua nhiều ngã rẽ để đến Hà Nội. Chúng ta có thể nghĩ về
việc chuyển tiếp như qui trình của việc đi qua một một ngã rẽ: một xe
vào một ngã rẽ từ một đường và xác định đường nào sẽ đi tiếp theo để
qua ngã rẽ này. Chúng ta có thể nghĩ tới việc định tuyến như qui trình
của việc lập kế hoạch cho cuộc hành trình từ TPHCM đến Hà Nội:
trước khi đi, lái xe phải sử dụng bản đồ để lựa chọn các đường có thể
đi, và mỗi đường gồm nhiều đoạn đường nối với nhau tại các ngã rẽ.
291
Mỗi bộ định tuyến đều có một bảng chuyển tiếp. Một bộ định tuyến
chuyển tiếp một gói tin bằng cách xác định một trường trong phần đầu
của gói tin đến và sử dụng giá trị này để tìm kiếm trong bảng chuyển
tiếp của bộ định tuyến. Kết quả từ bảng chuyển tiếp cho biết cổng giao
tiếp đầu ra (outgoing link interface) bộ định tuyến mà gói tin sẽ được
chuyển qua. Dựa vào giao thức tầng Mạng, giá trị này trong phần đầu
của gói tin có thể là địa chỉ đích của gói tin hay một dấu hiệu của kết
nối gói tin thuộc về. Hình 4.2 là một ví dụ. Trong hình 4.2, một gói tin
với giá trị một trường phần đầu là 0111 đến một bộ định tuyến. Bộ
định tuyến sử dụng giá trị này trong việc tìm kiếm trong bảng chuyển
tiếp và xác định cổng đầu ra để chuyển gói tin đi là cổng 2. Sau đó, bộ
định tuyến sẽ chuyển gói tin ra cổng 2 một cách cục bộ. Trong phần
4.3, chúng ta sẽ tìm hiểu sâu bên trong một bộ định tuyến và tìm hiểu
chức năng chuyển tiếp kĩ hơn.
Giao thức định tuyến
Bảng chuyển tiếp cục bộ

Phần đầu Cổng ra
0100 3
0101 2
0111 2
1001 1
Giá trị trong phần

đầu gói tin đến
1
0111
2
3
Hình 4.2 – Các giao thức định tuyến xác định các giá trị lưu trong bảng
chuyển tiếp
292
Chúng ta có thể băn khoăn rằng các bảng chuyển tiếp tại các bộ định
tuyến được cấu hình bằng cách nào. Đây là một vấn đề cốt lõi có thể
làm rõ sự nhập nhằng giữa định tuyến và chuyển tiếp. Như được trình
bày trong hình 4.2, các giải thuật định tuyến xác địch các giá trị sẽ
được ghi vào bảng chuyển tiếp của các bộ định tuyến. Giải thuật định
tuyến có thể tập trung (ví dụ, giải thuật thực thi ở một nơi tập trung và
gửi thông tin định tuyến cho các bộ định tuyến khác) hoặc phân tán (ví
dụ, một phần của giải thuật định tuyến phân tán được chạy ở mỗi bộ
định tuyến). Trong trường hợp như vậy, một bộ định tuyến nhận các
thông điệp của giao thức định tuyến, các thông điệp này sẽ được sử
dụng để cấu hình bảng chuyển tiếp của nó. Sự khác nhau của chức
năng chuyển tiếp và định tuyến có thể được minh họa kĩ hơn bằng
việc, xem xét trường hợp của một mạng mà tất cả các bảng chuyển
tiếp được cấu hình trực tiếp bởi người quản trị mạng tại các bộ định
tuyến. Trong trường hợp này, không cần bất kì giao thức định tuyến
nào. Dĩ nhiên, người quản trị ở các hệ thống cần tương tác với
nhauđảm bảo các bảng chuyển tiếp được cấu hình đúng để các gói tin
có thể đến đúng đích mong muốn. Tuy nhiên, việc người quản trị cấu
hình tĩnh như vậy có thể dễ dẫn tới bị lỗi hơn và phản ứng chậm với
những thay đổi trong mạng hơn một giao thức định tuyến. Vì vậy, rất
may mắn khi tất cả các mạng đều có chức năng chuyển tiếp và chức
năng định tuyến.
Khi chúng ta thảo luận vấn đề liên quan đến thuật ngữ, hai thuật ngữ
đề cập ở trên thường được sử dụng hoán đổi qua lại nhưng chúng ta sẽ
sử dụng chúng cẩn thận hơn. Chúng ta dành riêng thuật ngữ bộ
chuyển gói (packet switch) để nói đến các thiết bị chuyển mạch gói
(packet-switching) nói chung dùng chuyển gói tin từ một liên kết đầu
vào ra một liên kết đầu ra dựa vào giá trị trong một trường trong phần
đầu của gói tin. Vài bộ chuyển gói, gọi là bộ chuyển tại tầng Liên kết
(link layer switches - được trình bày ở chương 5) quyết định chuyển
tiếp dựa vào giá trị của trường ở tầng Liên kết. Các bộ chuyển gói
khác, gọi là bộ định tuyến quyết định chuyển tiếp gói tin của nó dựa
trên giá trị của trường ở tầng Mạng. Bởi vì trong chương này, phần
chúng ta tập trung là tầng Mạng, chúng ta sử dụng thuật ngữ bộ định
tuyến thay cho bộ chuyển gói. Chúng ta thậm chí sẽ sử dụng thuật ngữ
bộ định tuyến khi nói về các bộ chuyển gói trong mạng mạng ảo.
293
Thiết lập kết nối

Tầng Mạng có hai chức năng quan trọng, chuyển tiếp và định tuyến.
Tuy nhiên, chúng ta sẽ sớm thấy rằng một số mạng máy tính có một
chức năng quan trọng thứ ba là thiết lập kết nối. Nhắc lại giao thức
TCP, giao thức thực hiện bắt tay 3 bước trước khi dữ liệu được truyền
từ nơi gửi tới nơi nhận. Với việc bắt tay 3 bước, thiết bị gửi (sender)
và thiết bị nhận (receiver) có thể thiết lập thông tin trạng thái cần thiết
(ví dụ số thứ tự và kích thước cửa sổ điều khiển luồng ban đầu).
Tương tự, vài kiến trúc tầng Mạng, ví dụ ATM và frame relay, yêu
cầu các bộ định tuyến trên con đường đã chọn trước từ nguồn tới đích
bắt tay với nhau để thiết lập trạng thái trước khi các gói dữ liệu tầng
Mạng trong kết nối nguồn-đích bắt đầu được chuyển đi. Trong tầng
Mạng, quá trình này được gọi là thiết lập kết nối. Chúng ta sẽ tìm hiểu
việc thiết lập kết nối ở phần 4.2
I.2 Mô hình dịch vụ mạng
Trước khi đi sâu vào tầng Mạng, hãy nhìn rộng hơn và xem xét các
loại dịch vụ khác nhau mà tầng Mạng cung cấp. Khi tầng Vận chuyển
tại host gửi chuyển một gói tin xuống tầng Mạng, tầng Vận chuyển có
thể biết được làm cách nào tầng Mạng có thể chuyển gói tin đến đích?
Khi nhiều gói tin được gửi, các gói tin này sẽ được đưa lên tầng vần
chuyển tại nơi nhận theo đúng thứ tự mà nó được gửi hay không?
Thời gian giữa hai lần gửi gói tin liên tiếp có giống với thời gian nhận
giữa hai gói tin liên tiếp? Mạng có cung cấp bất kì phản hồi nào về
việc tắc nghẽn trên mạng? Các câu trả lời cho các câu hỏi này và
những câu hỏi khác được xác định bởi mô hình dịch vụ được cung cấp
bởi tầng Mạng. Mô hình dịch vụ tầng Mạng (network service model)
định nghĩa các đặc tính của việc vận chuyển đầu cuối – đến – đầu cuối
(end– to –end) của các gói tin từ hệ thống đầu cuối gửi (sending
systems) đến hệ thống đầu cuối nhận (receiving systems).
Hãy xem một số dịch vụ mà tầng Mạng có thể cung cấp. Tại host gửi,
khi tầng Vận chuyển chuyển gói tin xuống tầng Mạng, một số dịch vụ
có thể cung cấp bởi tầng Mạng bao gồm:
▪ Đảm bảo việc phân phối – Dịch vụ này đảm bảo rằng gói tin sẽ
đến đúng đích của nó.
294
▪ Đảm bảo việc phân phối trong khoảng thời gian nào đó – Dịch
vụ này không những đảm bảo việc phân phối gói tin mà còn đảm
bảo việc phân phối này trong một khoảng thời gian định trước (ví
dụ, 100 msec)
Hơn nữa, các dịch vụ sau có thể cung cấp cho các luồng gói tin (flows
of packet) giữa một nguồn và đích:
▪ Phân phối gói tin đúng thứ tự: Dịch vụ này đảm bảo gói tin đến
đích theo đúng thứ tự nó được gửi đi.
▪ Đảm bảo jitter lớn nhất: Dịch vụ này đảm bảo thời gian giữa 2
lần truyền gói tin liên tiếp nhau tại nơi gửi bằng với thời gian giữa
2 lần nhận tại nơi nhận (hoặc việc sai khác này không nhiều hơn
giá trị cho trước)
▪ Các dịch vụ bảo mật: Sử dụng một khóa phiên bảo mật chỉ được
biết bởi nguồn và đích, tầng Mạng ở host nguồn và đích có thể mã
hóa phần dữ liệu của tất cả các gói tin được gửi đến đích. Tầng
Mạng tại host đích sẽ giải mã phần dữ liệu đó. Với dịch vụ này,
tính riêng tư sẽ được cung cấp cho các gói tin tầng Vận chuyển
(TCP và UDP) giữa các host nguồn và đích. Ngoài tính riêng tư,
tầng Mạng còn có thể cung cấp các dịch vụ toàn vẹn dữ liệu và
các dịch vụ chứng thực nguồn.
Đây chỉ là một phần của danh sách các dịch vụ mà tầng Mạng có thể
cung cấp – có rất nhiều dịch vụ khác mà không được đề cập ở đây.
Bảng 4.1 – Các mô hình dịch vụ Internet, ATM CBR và ABR
295
Tầng Mạng của Internet cung cấp một dịch vụ đơn, được biết như là
“nỗ lực tối đa”. Từ bảng 4.1, chúng ta có thể thấy rằng “nỗ lực tối đa”
có nghĩa là không dịch vụ nào cả. Với dịch vụ “nỗ lực tối đa”, thời
gian giữa các gói tin không được đảm bảo, gói tin không được đảm
bảo sẽ đến đích đúng thứ tự hay thậm chí không đảm bảo gói tin có
thể đến được đúng đích. Tuy nhiên, cũng có một số lí do cho dịch vụ
tầng Mạng của Internet lại như vậy.
Có một số kiến trúc mạng khác đã định nghĩa và triển khai các mô
hình dịch vụ tốt hơn dịch vụ nỗ lực tối đa của Internet. Ví dụ, kiến
trúc mạng ATM cung cấp nhiều mô hình dịch vụ khác nhau, điều này
có nghĩa các kết nối khác nhau có thể được cung cấp các lớp dịch vụ
khác nhau trong cùng một mạng. Việc thảo luận về làm thế nào một
mạng ATM cung cấp được các dịch vụ như vậy nằm ngoài phạm vi
sách này, mục tiêu của chúng ta chỉ lưu ý rằng có nhiều mô hình dịch
vụ khác ngoài dịch vụ “nỗ lực tối đa” của Internet. Hai mô hình dịch
vụ quan trọng của ATM là dịch vụ đảm bảo tốc độ truyền không đổi
(constant bit rate -CBR) và dịch vụ tốc độ bít sẵn có (available bit rate
service – ABR).
▪ Dịch vụ ATM đảm bảo tốc độ truyền không đổi (Constant bit
rate -CBR): Đây là mô hình dịch vụ ATM đầu tiên được chuẩn
hóa bởi các công ty điện thoại. Dịch vụ CBR rất thích hợp cho
việc chuyển các dữ liệu thời gian thực, dữ liệu âm thanh và hình
ảnh cần truyền với tốc độ không đổi. Mục tiêu của CBR khá đơn
giản: cung cấp một luồng dữ liệu với một đường ống ảo như một
kết nối với một băng thông cố định dành riêng giữa host gửi và
host nhận. Với dịch vụ CBR, một luồng các tế bào (cell) ATM
được mang trên mạng có thể đảm bảo độ trễ, độ sai khác trong độ
trễ đầu cuối – đầu cuối của tế bào (gọi là jitter) và tỉ lệ của các tế
bào bị mất hoặc phân phối trễ nhỏ hơn một giá trị cho trước nào
đó. Những giá trị này được thỏa thuận trước giữa host gửi và
mạng ATM khi kết nối CBR được thiết lập lần đầu.
▪ Dịch vụ truyền với tốc độ sẵn có (Available bit rate - ABR):
Trong khi mạng Internet cung cấp dịch vụ gọi là nỗ lực tối đa,
ABR của ATM có thể xem như một dịch vụ tốt hơn. Cũng giống
như mô hình dịch vụ mạng Internet, các tế bào có thể bị mất khi
sử dụng dịch vụ ABR. Tuy nhiên, không giống như Internet, các
296
tế bào không thể được sắp xếp lại thứ tự (mặc dù chúng có thể
mất) và một tốc độ truyền tế bào tối thiếu (MCR) được bảo đảm
cho kết nối sử dụng dịch vụ ABR. Nếu mạng có đủ tài nguyên tại
một thời điểm nào đó, thiết bị gửi có thể cho phép gửi các tế bào
với tốc độ cao hơn tốc độ MCR. Ngoài ra, như chúng ta đã thấy
trong phần 3.6, dịch vụ ABR có thể cung cấp phản hồi cho nơi
gửi để điều khiển tốc độ của nó nằm trong khoảng MCR và tốc độ
tế bào cao nhất có thể.
II. Mạng gói dữ liệu và mạng mạch ảo

Ở chương 3, tầng Vận chuyển có thể cung cấp cho các ứng dụng dịch
vụ không kết nối và dịch vụ hướng kết nối. Ví dụ, tầng Vận chuyển
của Internet cung cấp cho ứng dụng sử dụng 1 trong 2 dịch vụ: UDP,
dịch vụ không kết nối; hay TCP, dịch vụ hướng kết nối. Tương tự tầng
Vận chuyển, tầng Mạng cũng cung cấp dịch vụ kết nối và dịch vụ
không kết nối. Các dịch vụ kết nối và không kết nối tầng Mạng cũng
giống như các dịch vụ hướng kết nối và không kết nối của tầng Vận
chuyển. Ví dụ, dịch vụ kết nối tầng Mạng cũng thực hiện việc bắt tay
giữa nguồn và đích và dịch vụ không kết nối tầng Mạng không thực
hiện việc bắt tay nào cả.
Mặc dù các dịch vụ kết nối và không kết nối tầng Mạng giống với các
dịch vụ hướng kết nối và không kết nối của tầng Vận chuyển, chúng
cũng có những khác nhau chủ yếu:
▪ Trong tầng Mạng, các dịch vụ này là các dịch vụ host-đến-host
được cung cấp bởi các tầng Mạng cho tầng Vận chuyển. Trong
tầng Vận chuyển, các dịch vụ này là các dịch vụ tiến trình-đến-
tiến trình cung cấp bởi tầng Vận chuyển cho tầng Ứng dụng.
▪ Trong phần lớn các kết trúc mạng phổ biến hiện nay (Internet,
ATM, frame relay…), tầng Mạng chỉ có thể hoặc cung cấp dịch
vụ không kết nối host-đến-host hoặc dịch vụ kết nối host-đến-
host, và không thể cung cấp cả hai. Các mạng máy tính chỉ cung
cấp một dịch vụ kết nối tại tầng Mạng gọi là mạng mạch ảo; các
mạng máy tính chỉ cung cấp một dịch vụ không kết nối tại tầng
Mạng gọi là các mạng gói dữ liệu.
297
▪ Việc triển khai của dịch vụ hướng kết nối tại tầng vần chuyện và
dịch vụ kết nối tại tầng Mạng cũng khác nhau. Chúng ta thấy rằng
ở chương trước, dịch vụ hướng kết nối tầng Vận chuyển được
triển khai ở mạng biên trong các hệ thống đầu cuối; và chúng ta
sẽ thấy rằng dịch vụ kết nối tầng Mạng được triển khai tại các bộ
định tuyến trong phần lõi của mạng cũng như tại các hệ thống đầu
cuối.
Các mạng mạch ảo và mạng dữ liệu là hai lớp mạng chủ yếu của mạng
máy tính. Chúng sử dụng thông tin khác nhau cho việc quyết định
chuyển tiếp các gói tin.
II.1 Mạng mạch ảo
Chúng ta đã biết rằng Internet là một mạng gói dữ liệu. Tuy nhiên,
nhiều kiến trúc mạng khác - bao gồm ATM và frame relay - là các
mạng mạch ảo, và vì vậy sử dụng các kết nối tại tầng Mạng. Các kết
nối này được gọi là các mạch ảo (VC). Hãy xem một mạch ảo được
triển khai trong một mạng máy tính như thế nào.
Một mạch ảo bao gồm (1) một con đường (đó là một loạt các liên kết
và bộ định tuyến) giữa các host nguồn và đích, (2) số hiệu mạch ảo
(VC) - một con số cho mỗi liên kết trên đường đó, và (3) các dòng
trong bảng chuyển tiếp tại mỗi bộ định tuyến trên con đường đó. Một
gói tin thuộc vào một mạch ảo sẽ mang một số hiệu mạch ảo trong
phần đầu của nó. Bởi vì mạch ảo có thể có số hiệu mạch ảo khác nhau
ở mỗi liên kết, mỗi bộ định tuyến tại giao của các đường mạng phải
thay thế số hiệu mạch ảo của mỗi gói tin đến với một số mạch ảo mới.
Số hiệu mạch ảo này được lưu giữ trong bảng chuyển tiếp.
Để minh họa cho khái niệm này, hãy xem hệ thống mạng ở hình 4.3.
Những con số cạnh các liên kết của R1 ở hình 4.3 là các số hiệu của
các giao diện liên kết. Giả sử rằng host A yêu cầu mạng thiết lập một
mạch ảo giữa nó và Host B. Giả sử mạng chọn đường A – R1 – R2- B
và gán số hiệu mạch ảo 12, 22, và 32 cho 3 đường liên kết trên con
đường cho mạch ảo này. Trong trường hợp này, khi một gói tin trong
mạch ảo này rời khỏi R1, số hiệu mạch ảo của nó là 22 và khi nó rời
R2, giá trị này là 32.
298
Hình 4.3 – Một mạng mạch ảo đơn giản

Làm thế nào bộ định tuyến thay thế số hiệu mạch ảo cho một gói tin đi
qua bộ định tuyến? Đối với một mạng mạch ảo, bảng chuyển tiếp tại
mỗi bộ định tuyến chứa một bảng chuyển đổi số hiệu mạch ảo; ví dụ,
bảng chuyển tiếp tại R1 như sau:
Khi một mạch ảo mới được thiết lập đi qua bộ định tuyến, một dòng
mới được thêm vào trong bảng chuyển tiếp của bộ định tuyến đó.
Tương tự, khi một mạch ảo kết thúc, các dòng tương ứng trong mỗi
bảng tại các bộ định tuyến trên con đường đi của nó được loại bỏ.
Chúng ta có thể băn khoăn rằng tại sao một gói tin không giữ cùng số
hiệu mạch ảo tại mỗi liên kết trên đường đi của nó. Câu trả lời như
sau: Thứ nhất, việc thay thế số hiệu mạch ảo trong các liên kết giảm
kích thước của trường VC trong phần đầu gói tin. Thứ 2, quan trọng
hơn, việc thiết lập VC sẽ đơn giản hơn khi cho phép các số hiệu VC
khác nhau cho các liên kết trên con đường của mạch ảo. Cụ thể, với
299
nhiều số hiệu VC, mỗi liên kết trên con đường có thể chọn một số
hiệu VC độc lập với các số hiệu VC được chọn tại các liên kết khác
trên cùng con đường. Nếu một số hiệu VC chung được yêu cầu cho
các liên kết trên cùng con đường, các bộ định tuyến có thể phải
chuyển và xử lí một số thông điệp để thống nhất số hiệu VC chung để
sử dụng cho một kết nối.
Trong mạng VC, các bộ định tuyến mạng phải duy trì thông tin trạng
thái kết nối cho các kết nối đi qua hoặc xuất phát từ nó. Cụ thể hơn,
mỗi lần một kết nối được thiết lập qua một bộ định tuyến, một dòng
kết nối mới được thêm vào bảng chuyển tiếp của bộ định tuyến; và
mỗi lần một kết nối kết thúc, một dòng phải được xóa đi. Chú ý rằng
thậm chí nếu không có việc chuyển đổi các số hiệu VC, thông tin
trạng thái kết nối kết hợp các số hiệu VC với số hiệu cổng ra vẫn cần
duy trì. Vấn đề một bộ định tuyến có duy trì thông tin trạng thái kết
nối cho mỗi kết nối đi ra hay không là một vấn đề chủ yếu– điều này
sẽ được lặp lại trong sách này.
Có 3 pha phân biệt trong một mạch ảo:
▪ Thiết lập mạch ảo: Trong pha thiết lập, tầng Vận chuyển ở nơi
gửi liên lạc với tầng Mạng, chỉ định địa chỉ của nơi nhận và chờ
cho mạng thiết lập mạch ảo. Tầng Mạng xác định đường đi giữa
nơi gửi và nơi nhận, đó là một loạt các đường liên kết và các bộ
định tuyến mà tất cả gói tin của mạch ảo sẽ đi qua. Tầng Mạng
cũng xác định các số hiệu mạch ảo cho mỗi liên kết. Cuối cùng,
tầng Mạng thêm các dòng vào bảng chuyển tiếp trong các bộ định
tuyến trên đường đi đó. Suốt quá trình thiết lập mạch ảo, tầng
Mạng cũng có thể dành riêng các tài nguyên (ví dụ băng thông)
trên đường đi của mạch ảo.
▪ Chuyển dữ liệu: Như hình 4.4, khi một mạch ảo được thiết lập,
các gói tin bắt đầu được truyền trên mạch ảo này.
▪ Kết thúc mạch ảo: Mạch ảo được kết thúc khi thiết bị gửi hoặc
thiết bị nhận thông báo với tầng Mạng nó muốn kết thúc mạch ảo.
Tầng Mạng sẽ thông báo cho hệ cuối ở phía bên kia yêu cầu việc
kết thúc và cập nhật bảng chuyển tiếp trong mỗi bộ định tuyến
trên đường đi của mạch ảo để thông báo mạch ảo không còn tồn
tại nữa.
300
Có một sự khác biệt quan trong giữa việc thiết lập mạch ảo tại tầng
Mạng với việc thiết lập kết nối tại tầng Vận chuyển (ví dụ, bắt tay 3
bước mà đã học ở chương 3). Việc thiết lập kết nối tại tầng Vận
chuyển bao liên quan đến hai hệ thống đầu cuối. Trong quá trình thiết
lập kết nối ở tầng Vận chuyển chỉ có 2 hệ thống đầu cuối xác định các
tham số của kết nối tầng Vận chuyển (ví dụ, số thứ tự khởi tạo hay
kích thước cửa sổ điều khiển luồng). Mặc dù hai hệ thống đầu cuối
biết về kết nối tầng vận chuyện, các bộ định tuyến trong mạng hoàn
toàn không biết về điều này. Ngược lại, với một mạch ảo tầng Mạng,
các bộ định tuyến trên con đường giữa hai hệ cuối đều có liên quan
trong việc thiết lập mạch ảo, và mỗi bộ định tuyến đều biết về các
mạch ảo mà đi qua nó.
4. Cuộc gọi được
Tầng ứng dụng thiết lập 3. Chấp nhận Tầng ứng dụng
cuộc gọi
5. Dữ liệu
Tầng vận chuyển 6. Nhận dữ Tầng vận chuyển
truyền đi
liệu
Tầng mạng Tầng mạng
Tầng liên kết Tầng liên kết
Tầng vật lí Tầng vật lí

1. Khởi tạo cuộc
2. Cuộc gọi đến
gọi
Hình 4.4 - Thiết lập mạch ảo

Thông điệp mà các hệ cuối gửi vào mạng để khởi tạo hay kết nối một
mạch ảo, và các thông điệp được chuyển giữa các bộ định tuyến để
thiết lập mạch ảo (để thay đổi trạng thái kết nối trong mỗi bảng trạng
thái tại bộ định tuyến) được gọi là các giao thức báo hiệu. Việc thiết
lập mạch ảo được chỉ ra ở hình 4.4. Chúng ta sẽ không tìm hiểu các
giao thức báo hiệu mạch ảo trong cuốn sách này.
301
II.2 Mạng dữ liệu

Trong mạng gói dữ liệu, mỗi lần một hệ cuối muốn gửi một gói tin, hệ
cuối sẽ thêm vào gói tin địa chỉ của hệ cuối nguồn và địa chỉ của hệ
cuối đích sau đó đẩy gói tin đi trên mạng. Như hình 4.5, điều này
được thực hiện mà không có bất kì thiết lập mạch ảo nào. Các bộ định
tuyến trong mạng gói dữ liệu không duy trì bất kì thông tin trạng thái
nào về các mạch ảo (bởi vì không có bất kì mạch ảo nào).
Tầng ứng dụng Tầng ứng dụng
Tầng vận chuyển Tầng vận chuyển
Tầng mạng Tầng mạng

2. Receive
1. Send data
Tầng liên kết data Tầng liên kết
Tầng vật lí Tầng vật lí
Hình 4.5 – Mạng dữ liệu

Khi một gói tin được truyền từ nguồn tới đích, nó sẽ đi qua một loạt
các bộ địch tuyến. Mỗi bộ định tuyến này sử dụng địa chỉ đích của gói
tin để chuyển gói tin đi. Cụ thể hơn, mỗi bộ định tuyến có một bảng
chuyển tiếp chứa ánh xạ các địa chỉ đích tới các cổng liên kết; khi một
gói tin đến một bộ định tuyến, bộ định tuyến sử dụng địa chỉ đích của
gói tin để tìm kiếm cổng liên kết đầu ra thích hợp trong bảng chuyển
tiếp. Bộ định tuyến sau đó sẽ chuyển gói tin ra cổng liên kết đầu ra đó.
Để tìm hiểu sâu hơn quá trình tìm kiếm, hãy xem một ví dụ sau. Giả
sử tất cả địa chỉ đích là 32 bit. Một cài đặt theo kiểu vét cạn của bảng
chuyển tiếp sẽ có một dòng cho mỗi địa chỉ đích. Bởi vì có khả năng
có hơn 4 tỉ địa chỉ đích, lựa chọn này sẽ dẫn tới mỗi bộ định tuyến sẽ
chứa một bảng chuyển tiếp rất lớn.
302
Giả sử rằng bộ định tuyến có 4 liên kết, được đánh số từ 0 tới 3, và

các gói tin được chuyển tiếp ra các cổng liên kết như sau:
Rõ ràng, với ví dụ này, không cần thiết để có 4 tỉ dòng trong bảng

chuyển tiếp của bộ định tuyến. Ví dụ, chúng ta có thể có bảng chuyển
tiếp như sau chỉ với 4 dòng:
Với cách biểu diễn như vậy, bộ định tuyến chỉ kiểm tra tiếp đầu ngữ
(prefix) của địa chỉ đích của gói tin với các dòng trong bảng chuyển
tiếp; nếu nếu tìm thấy, bộ định tuyến chuyển gói tin tới cổng ra tương
ứng với dòng đó. Ví dụ, giả sử địa chỉ đích của gói tin là 11001000
00010111 00010110 10100001; bởi vì 21 bit tiếp đầu ngữ của địa chỉ
này trùng với dòng đầu tiên trong bảng chuyển tiếp, bộ dịnh tuyến
chuyển gói tin ra cổng liên kết 0. Nếu một tiếp đầu ngữ không trùng
với bất kì dòng nào trong 3 dòng đầu tiên, bộ định tuyến sẽ chuyển gói
tin ra cổng liên kết 3. Mặc dù, điều này hợp lí nhưng vẫn có vấn đề
quan trọng ở đây. Chúng ta lưu ý rằng có khả năng một địa chỉ đích có
thể trùng với nhiều hơn một dòng. Ví dụ, 24 bit đầu tiên của địa chỉ
11001000 00010111 00011000 10101010 trùng với dòng thứ 2 trong
bảng và 21 bit đầu của địa chỉ trùng với dòng thứ 3 trong bảng. Khi có
303
nhiều dòng trùng, bộ định tuyến sẽ chọn dòng trùng có tiếp đầu ngữ
dài nhất (longest prefix matching) trong bảng chuyển tiếp và chuyển
gói tin ra cổng tương ứng với dòng có tiếp đầu ngữ dài nhất đó.
Mặc dù các bộ định tuyến trong các mạng gói dữ liệu không duy trì
thông tin trạng thái kết nối nào, các bộ định tuyến này duy trì thông tin
trạng thái chuyển tiếp trong các bảng chuyển tiếp của nó. Tuy nhiên,
thông tin trạng thái này thay đổi tương đối chậm. Thật vậy, trong
mạng gói dữ liệu, các bảng chuyển tiếp được thay đổi bởi các giao
thức định tuyến với việc cập nhật bảng chuyển tiếp 1 đến 5 phút một
lần. Trong mạng mạch ảo, một bảng chuyển tiếp tại một bộ định tuyến
chỉ được thay đổi khi nào có một kết nối mới được thiết lập qua bộ
định tuyến hoặc khi có một kết nối qua bộ định tuyến kết thúc.
Bởi vì bảng chuyển tiếp trong mạng gói dữ liệu có thể thay đổi bất kì
lúc nào, một loạt các gói tin được gửi từ một hệ cuối tới hệ cuối khác
có thể đi nhiều đường khác nhau và có thể đến đích không đúng thức
tự.
II.3 Nguồn gốc của mạng mạch ảo và mạng dữ liệu
Sự phát triển của mạng gói dữ liệu và mạng mạch ảo cho chúng ta biết
nguồn gốc của nó. Ý niệm mạnh ảo như là một nguyên lí tổ chức
trung tâm có nguồn gốc từ mạng điện thoại với việc sử dụng các mạch
thật. Với việc các cuộc gọi và các trạng thái cho từng cuộc gọi được
duy trì tại mỗi bộ định tuyến trong mạng, người ta cho rằng một mạng
mạch ảo phức tạp hơn so với mạng gói dữ liệu. Mạng điện thoại có độ
phức tạp cao bởi vì chúng đang nối nhiều thiết bị đầu cuối với nhau, ví
dụ các điện thoại quay số.
Ngược lại, mạng Internet là một mạng gói dữ liệu, phát triển từ sự cần
thiết của việc kết nối các máy tính lại với nhau. Bởi vì các thiết bị hệ
thống đầu cuối phức tạp hơn, các kiến trúc Internet được chọn để cung
cấp các mô hình dịch vụ mạng càng đơn giản càng tốt. Như chúng ta
đã thấy ở chương 2, chương 3, các chức năng như truyền tin cậy, kiểm
soát tắc nghẽn…được triển khai ở các tầng cao hơn ở các hệ thống đầu
cuối. Điều này ngược với mô hình của mạng điện thoại với những hệ
quả lí thú sau:
304
▪ Khi mô hình dịch vụ mạng của Internet chỉ xây dưng việc đảm
bảo dịch vụ rất nhỏ, Internet đã đưa ra các yêu cầu nhỏ nhất cho
tầng Mạng. Điều này giúp cho các mạng sử dụng các công nghệ
tầng Liên kết dữ liệu khác nhau (ví dụ vệ tinh, Ethernet…), có tốc
độ truyền và các đặc tính mất mát dữ liệu khác nhau có thể kết
nối dễ dàng hơn.
▪ Như được trình bày ở chương 2, các ứng dụng như email, web, và
thậm chí các dịch vụ quan trọng của mạng như DNS được triển
khai ở các máy tính (các server) tại phần biên của mạng. Khả
năng để thêm các dịch vụ mới đơn giản bằng việc đưa host này
vào mạng và định nghĩa một giao thức mới tầng Ứng dụng (ví dụ
HTTP) cho phép những ứng dụng mới như Web được triển khai
trên Internet trong khoảng thời gian ngắn.
III. Bên trong bộ định tuyến

Đến thời điểm này, chúng ta đã hiểu được tổng quan các chức năng và
các dịch vụ của tầng Mạng, bây giờ hãy xem xét chức năng chuyển
tiếp của tầng Mạng – chức năng chuyển gói tin từ các liên kết đầu vào
của một bộ định tuyến ra các liên kết đầu ra. Chúng ta đã có một cái
nhìn sơ khởi một số vấn đề chuyển tiếp ở phần 4.2, đó là việc định địa
chỉ và chọn lựa tiếp đầu ngữ dài nhất. Trong phần này, chúng ta sẽ tìm
hiểu kiến trúc của bộ định tuyến để chuyển các gói tin từ các liên kết
đầu vào ra các liên kết đầu ra. Ở đây, các thuật ngữ được sử dụng
trong việc chuyển gói tin là chuyển tiếp (forwarding) và chuyển (
switching) thường được sử dụng qua lại bởi các nhà nghiên cứu mạng
máy tính và những người làm trên môi trường thực tế; chúng ta sẽ sử
dụng cả hai thuật ngữ này trong cuốn sách này.
Một cái nhìn tổng quan đối với kiến trúc bộ định tuyến nói chung
được chỉ ra ở Hình 4.6. Bốn phần của một bộ định tuyến bao gồm:
▪ Các ngõ vào (input ports): Các ngõ vào thực hiện các chức năng
ở tầng vật lí (hộp trái nhất của ngõ vào và hộp phải nhất của ngõ ra ở
Hình 4.6) với việc kết thúc một liên kết vật lí đầu vào đi vào một bộ
định tuyến. Nó cũng thực hiện các chức năng tầng Liên kết (hộp
chính giữa trong các ngõ vào và ngõ ra) cần thiết để liên lạc với các
chức năng tầng Liên kết tại đầu bên kia của liên kết. Nó cũng thực
305
hiện chức năng tìm kiếm và chuyển tiếp (hộp phải nhất của ngõ vào
và hộp trái nhất của ngõ ra) để một gói tin được chuyển vào bộ
chuyển (switching fabric) của bộ định tuyến ra khỏi tại ngõ ra thích
hợp. Các gói tin điều khiển (ví dụ, các gói tin mang các thông tin
định tuyến) được chuyển từ một ngõ vào đến bộ xử lí định tuyến.
Trong thực tế, nhiều ngõ được gom lại với nhau thành một line card
đơn bên trong một bộ định tuyến.
Ngõ vào Ngõ ra
Bộ
Ngõ vào chuyển Ngõ ra
Bộ xử lí
định tuyến
Hình 4.6 – Kiến trúc bộ định tuyến
▪ Bộ chuyển (Switch fabric): Bộ chuyển kết nối các cổng vào của
bộ định tuyến với các cổng ra. Bộ chuyển là một mạng lưới nằm bên
trong một bộ định tuyến mạng.
▪ Các ngõ ra (output port): Một ngõ ra chứa các gói dữ liệu được
chuyển tới nó thông qua bộ chuyển và sau đó chuyển gói tin ra liên
kết đầu ra. Vì vậy, các ngõ ra thực hiện chức năng tầng Liên kết dữ
liệu và tầng vật lí ngược với ngõ vào.
▪ Bộ xử lí định tuyến (routing processor): Bộ xử lí định tuyến
thực thi các giao thức định tuyến, duy trì thông tin định tuyến và bảng
chuyển tiếp; thực hiện các chức năng quản lí mạng bên trong bộ định
tuyến.
Trong các phần tiếp theo, chúng ta sẽ tìm hiểu các cổng vào, bộ
chuyển và các cổng ra chi tiết hơn.
306
III.1 Ngõ vào

Một cái nhìn chi tiết chức năng cổng vào được đưa ra ở hình 4.7. Như
được thảo luận ở trên, chức năng kết thúc line của ngõ vào và việc xử
lí liên kết dữ liệu thực hiện các chức năng tầng vật lí và tầng Liên kết
dữ liệu cho một liên kết đơn đi vào bộ định tuyến. Phần tìm
kiếm/chuyển tiếp trong ngõ vào là phần cốt lõi của chức năng chuyển
tiếp của bộ định tuyến. Nhiều bộ định tuyến xác định ngõ ra cho một
gói tin, ngõ mà một gói tin sẽ chuyển đến thông qua bộ chuyển. Việc
lựa chọn ngõ ra được thực biện bởi việc sử dụng thông tin chứa trong
bảng chuyển tiếp. Mặc dù bảng chuyển tiếp được tính toán bởi bộ xử
lí định tuyến, một bản sao chép của bảng chuyển tiếp thường được lưu
trữ tại mỗi ngõ vào và được cập nhật khi cần thiết bởi các bộ xử lí
định tuyến. Với việc sao chép này, quyết định chuyển tiếp gói tin có
thể thực hiện cục bộ tại mỗi ngõ vào mà không cần phải hỏi bộ xử lí
định tuyến trung tâm. Việc chuyển tiếp một cách phân tán như vậy
tránh việc thắt cổ chai khi xử lí chuyển tiếp tại bộ xử lí định tuyến.
Trong các bộ định tuyến với khả năng xử lí có giới hạn tại ngõ vào,
các ngõ vào có thể chỉ đơn giản chuyển gói tin đó tới bộ xử lí định
tuyến trung tâm, bộ xử lí này sau đó sẽ thực hiện việc tìm kiếm trong
bảng chuyển tiếp và chuyển gói tin tới ngõ ra thích hợp. Đây là một
cách tiếp cận được thực hiện khi một máy trạm hay các máy phục vụ
phục vụ như một bộ định tuyến; ở đây, bộ xử lí định tuyến là các CPU
của máy trạm, và các ngõ vào là các card mạng.
Khi bảng chuyển tiếp đã được xây dựng, việc tìm kiếm trong bảng thì
khá đơn giản, chúng ta chỉ tìm hết bảng chuyển tiếp để tìm tiếp đầu
ngữ có độ dài dài nhất, như được đề cập ở Phần 4.2.2. Tuy nhiên,
trong thực tế, việc triển khai có đôi chút khác biệt.
Tìm kiếm, chuyển tiếp,

Xử lí tầng liên kết dữ đưa vào hàng đợi
Kết thúc line liệu (giao thức, đóng Bộ chuyển
gói)
Hình 4.7 – Xử lí ngõ vào
307
Có lẽ yếu tố phức tạp quan trọng nhất là các bộ định tuyến ở lõi
(backbone routers) phải hoạt động với tốc độ cao, thực hiện hàng triệu
phép tìm kiếm một giây. Vì thế, điều mong muốn là việc xử lí ngõ vào
có thể xử lí với tốc độ line (line speed) với thời gian thực hiện tìm
kiếm được thực hiện nhỏ hơn thời gian cần thiết để nhận gói tin tại
ngõ vào. Trong trường hợp này, việc xử lí đầu vào của một gói tin
nhận được có thể được hoàn thành trước khi việc nhận gói tin tiếp
theo được hoàn tất. Để có một í tưởng cho các yêu cầu về hiệu năng
đối với việc tìm kiếm, hãy xem rằng một liên kết 0C-48 chạy ở tốc độ
2.5Gbps. Với các gói tin có chiều dài 256 byte, điều này có nghĩa là
tốc độ tìm kiếm xấp xỉ 1 triệu tìm kiếm/giây.
Bởi vì các liên kết ngày nay hoạt động với tốc độ cao, việc tìm kiếm
tuần tự một bảng chuyển tiếp lớn là không khả thi. Một kĩ thuật hợp lí
hơn là lưu trữ bảng chuyển tiếp trong một cấu trúc dữ liệu cây. Mỗi
mức của cây có thể xem như một bit trong địa chỉ đích. Để tìm một
địa chỉ đích, chỉ đơn giản bắt đầu tại gốc của cây. Nếu địa chỉ bit đầu
tiên là 0, thì cây bên trái sẽ chứa dòng trong bảng chuyển tiếp tiếp cho
địa chỉ đích, ngược lại, sẽ là cây bên phải. Cây con thích hợp sau đó sẽ
được đi qua sử dụng các bit địa chỉ còn lại – nếu bit tiếp theo là 0, cây
con bên trái của cây con bên trái ban đầu được chọn; ngược lại, cây
con bên phải của cây con ban đầu được chọn. Với cách này, bộ định
tuyến có thể tìm kiếm trong bảng chuyển tiếp trong N bước, với N là
số lượng các bit trong địa chỉ.
Tuy nhiên, thậm chí với N=32 bước, tốc độ tìm kiếm sử dụng kĩ thuật
tìm nhị phân không đủ nhanh cho các yêu cầu định tuyến trong các
mạng lõi ngày nay. Vì vây, một số kĩ thuật khác được nghiên cứu để
tăng tốc độ tìm kiếm. Content addressable memories (CAMs) cho
phép một địa chỉ 32 bit được biểu diễn trong CAM, bảng này sẽ trả về
nội dung của thông tin trong bảng chuyển tiếp cho địa chỉ đó trong
khoảng thời gian không thay đổi. Các dòng bộ định tuyến của Cisco
8500 có 64K CAM cho mỗi cổng vào.
Một kĩ thuật khác để tăng tốc quá trình tìm kiếm là lưu trữ các thông
tin vừa mới truy cập trong bảng chuyển tiếp trong một bộ đệm. Ở đây,
vấn đề là kích thước của bộ đệm là bao nhiêu thì đủ. Những cấu trúc
dữ liệu nhanh cho phép các dòng bảng chuyển tiếp có thể tìm được
308
trong log(N) bước, hoặc các kĩ thuật nén các bảng chuyển tiếp được
đề xuất.
Một khi ngõ ra cho một gói tin được xác định thông qua tìm kiếm, gói
tin có thể chuyển vào bộ chuyển. Tuy nhiên, một gói tin có thể tạm
thời bị khóa và không thể vào bộ chuyển vì các gói tin từ các ngõ vào
khác đang sử dụng bộ chuyển. Một gói tin bị khóa phải nằm ở hàng
đợi của ngõ vào và sau đó được lập lịch để vào bộ chuyển sau đó.
Chúng ta sẽ xem xét kĩ hơn về việc khóa các gói tin, thực hiện xếp
hàng (queing) và lập lịch của các gói tin bên trong một bộ định tuyến
trong phần 4.3.4
III.2 Cơ cấu chuyển mạch
Bộ chuyển nằm tại phần trung tâm một bộ định tuyến. Thông qua bộ
chuyển, gói tin sẽ thực sự được chuyển từ một ngõ vào ra một ngõ ra.
Việc chuyển gói tin được thực hiện bởi một số cách, được thể hiện ở
hình 4.8
▪ Chuyển thông qua bộ nhớ(memory). Các bộ định tuyến đơn giản
nhất, xuất hiện sớm nhất thường là các máy tính truyền thống, với
việc chuyển từ ngõ vào ra ngõ ra được thực hiện dưới dưới sự
điều khiển của CPU (bộ xử lí định tuyến). Các ngõ vào và ngõ ra
hoạt động như là các thiết bị I/O truyền thống trong một hệ điều
hành truyền thống. Một ngõ vào với một gói tin đến đầu tiên phát
tín hiệu cho bộ xử lí định tuyến thông qua một ngắt. Gói tin sau
đó được sao chép từ ngõ vào vào bộ nhớ của bộ xử lí. Bộ xử lí
định tuyến sau đó bóc tách địa chỉ đích từ phần đầu gói tin, tìm
kiếm ngõ ra thích hợp trong bảng chuyển tiếp và sao chép một
bảng ra bộ đệm của ngõ ra. Chú ý rằng nếu với băng thông bộ
nhớ mà B gói tin có thể ghi vào hay đọc ra trong 1 giây, thì thông
lượng chuyển tiếp tổng cộng (tốc độ tổng cộng mà các gói tin
được chuyển từ các ngõ vào ra các ngõ ra) phải nhỏ hơn B/2.
Nhiều bộ định tuyến hiện đại cũng chuyển thông qua bộ nhớ. Tuy
nhiên, một sự khác biệt lớn với các bộ định tuyến trước đây là
việc tìm kiếm của địa chỉ đích và việc lưu trữ các gói tin vào vị trí
bộ nhớ thích hợp được thực hiện bởi các bộ xử lí trên các line
card vào. Trong một số cách, các bộ định tuyến chuyển thông
309
qua bộ nhớ trông giống như các bộ xử lí chia sẻ bộ nhớ, với việc
bộ xử lí trên một line card chuyển gói tin vào bộ nhớ của ngõ ra
thích hợp. Các switch dòng Catalyst 8500 của Cisco chuyển gói
tin thông qua một bộ nhớ chia sẻ.
Memory Crossbar A
A X
B Y B
Memory
C Z C
Bus
A X X Y Z
B Y
C Z
Hình 4.8 – 3 kĩ thuật chuyển mạch

▪ Chuyển thông qua bus – Trong cách tiếp cận này, các ngõ vào
chuyển một gói tin trực tiếp ra ngõ ra trên một bus chia sẻ mà
không có sự can thiệp của bộ xử lí định tuyến (lưu ý rằng khi
chuyển thông qua bộ nhớ, gói tin phải đi qua bus hệ thống đến/đi
từ bộ nhớ.) Mặc định bộ xử lí định tuyến không liên quan trong
việc chuyển bus, và chỉ có một gói tin tại một thời điểm được
chuyển lên bus. Một gói tin đến một ngõ vào và nhận thấy bus
đang bận sẽ bị khóa và được đặt tại hàng đợi của ngõ vào. Bởi vì
mỗi gói tin phải đi qua bus đơn, băng thông chuyển của bộ định
tuyến bị giới hạn bởi tốc độ bus.
310
Với các bus ngày nay có thể có băng thông trên 1Gbps, việc
chuyển qua một bus thường hiệu quả cho các bộ định tuyến hoạt
động trong các mạng truy cập và mạng công ty (ví dụ, mạng cục
bộ và mạng các tổ chức). Chuyển dựa vào bus được triển khai ở
một số sản phẩm bộ định tuyến hiện giờ, gồm Cisco 5600, bộ
định tuyến chuyển các gói tin trên một bus với 32Gbps back-
plane
▪ Chuyển thông qua mạng liên kết nối. Có một cách để có thể vượt
qua sự giới hạn băng thông của một bus đơn, chia sẻ là sử dụng
nhiều mạng liên kết nối phức tạp, như những mạng kết nối được
sử dụng trong quá khứ để liên kết các bộ xử lí thành kiến trúc
máy tính với nhiều bộ xử lí. Một crossbar switch là một mạng
liên kết nối bao gồm 2n bus liên kết n ngõ vào với n ngõ ra được
chỉ ra ở Hình 4.8. Một gói tin đến một ngõ vào đi theo bus dọc
gắn với ngõ vào đến khi nó cắt với bus đứng dẫn đến ngõ ra mong
muốn. Nếu bus đứng dẫn tới ngõ ra đang trống, gói tin được
chuyển ra ngõ ra. Nếu bus đứng đang được sử dụng để chuyển
gói tin từ ngõ vào khác tới cùng ngõ ra, gói tin đến sẽ bị khóa và
phải nằm ở hàng đợi của ngõ vào. Các switch Cisco họ 12000 sử
dụng mạng liên kết nối, cung cấp tới 60Gbps cho bộ chuyển
(switching fabric). Một xu hướng trong thiết kết mạng liên kết nối
là phân mảnh một gói tin IP có chiều dài có thể thay đổi thành các
tế bào có chiều dài không đổi, sau đó gán nhãn và chuyển các tế
bào có chiều dài không đổi thông qua mạng liên kết nối. Các tế
bào sau đó được gắn lại thành các gói tin gốc tại ngõ ra. Các tế
bào có chiều dài cố dịnh và các nhãn bên trong có thể khá đơn
giản và tăng tốc việc chuyển gói tin thông qua mạng liên kết nối.
III.3 Ngõ ra
Việc xử lí các ngõ ra, được chỉ ra ở hình 4.9, lấy các gói tin được lưu
ở bộ nhớ của ngõ ra và chuyển ra liên kết đầu ra. Việc xử lí giao thức
tầng Liên kết dữ liệu và việc kết thúc line là ở phía liên kết bên gửi -
và chức năng tầng vật lí mà tương tác với ngõ vào ở phía bên kia của
liên kết đầu ra, như được thảo luận ở phần 4.3.1. Chức năng quản lí
hàng đợi và bộ đệm là cần thiết khi bộ chuyển phân phối các gói tin
tới ngõ ra với tốc độ lớn hơn tốc độ liên kết ra.
311
Đợi ở hàng đợi(quản

Xử lí liên kết dữ
lí bộ đệm)
Bộ chuyển liệu(giao thức, đóng Kết thúc line
gói)
Hình 4.9 - Xử lí ở ngõ ra
III.4 Việc xếp hàng gói tin trong bộ định tuyến

Nếu nhìn vào chức năng ngõ vào, ngõ ra và cấu hình ở hình 4.8,
chúng ta sẽ thấy rằng việc các gói tin được đưa vào hàng đợi có thể
được thực hiện tại cả các ngõ vào và các ngõ ra. Cần phải xem xét các
hàng đợi này chi tiết bởi khi các hàng đợi này lớn, không gian bộ đệm
của bộ định tuyến dần dần bị chiếm hết và gói tin sẽ bị mất. Nhớ lại
những thảo luận trước đây, chúng ta đã nói rằng các gói tin bị mất bên
trong mạng hoặc tại bộ định tuyến. Nó chính là ở đây, tại các hàng đợi
này bên trong bộ định tuyến, nơi các gói tin như vậy bị rớt (drop) và
mất (lost). Vị trí thực tế của việc mất gói tin (ở hàng đợi ngõ vào hay
hàng đợi ngõ ra) sẽ tùy thuộc vào tải của lưu lượng mạng, tốc độ
tương đối của bộ chuyển và tốc độ line, như được thảo luận ở dưới.
Giả sử tốc độ line vào, line ra là lí tưởng và có n ngõ vào và n ngõ ra.
Định nghĩa tốc độ bộ chuyển (switching fabric speed) là tốc độ mà
bộ chuyển có thể di chuyển các gói tin từ các ngõ vào ra các ngõ ra.
Nếu tốc độ của bộ chuyển nhanh hơn ít nhất n lần tốc độ line vào thì
không cần phải đợi tại các cổng vào. Bởi vì thậm chí trong trường hợp
xấu nhất, tất cả n line vào đều đang nhận gói tin, bộ chuyển cũng sẽ có
thể chuyển n gói tin từ ngõ vào ra ngõ ra đồng thời. Nhưng điều gì xảy
ra tại các ngõ ra? Chúng ta vẫn giả sử rằng bộ chuyển có tốc độ nhanh
hơn ít nhất n lần tốc độ line. Trong trường hợp tệ nhất, các gói tin đến
tại một trong số n ngõ vào sẽ cùng đi ra cùng ngõ ra. Trong trường
hợp này n gói tin sẽ đến tại ngõ ra này. Bởi vì ngõ ra chỉ có thể
312
chuyển một gói tin tại một đơn vị thời gian, n gói đến sẽ phải đợi để
được chuyển ra liên kết đầu ra. Sau đó n gói tin nữa đến trong khoảng
thời gian từng gói tin một trong n gói tin nằm trong hàng đợi được
chuyển đi. Dần dần, số lượng gói tin nằm trong hàng đợi có thể đủ lớn
để làm cạn kiệt không gian bộ nhớ của cổng ra, trong trường hợp này,
các gói tin sẽ bị rớt.
Đi ra ngõ ra tại thời điểm t
Bộ chuyển
Đơn vị thời gian tiếp theo
Bộ chuyển
Hình 4.10 – Xếp hàng ở ngõ ra

Việc đợi tại ngõ ra được minh họa ở Hình 4.10. Tại thời điểm t, một
gói tin đến một trong những ngõ vào, và đích ra là ngõ ra trên cùng
nhất. Giả sử các tốc độ line là như nhau và một bộ chuyển có tốc độ
gấp 3 lần tốc độ line, một đơn vị thời gian sau đó, tất cả 3 gói tin ban
đầu được chuyển đến ngõ ra và được đưa vào hàng đơi chờ để được
chuyển đi. Trong đơn vị thời gian tiếp theo, một trong 3 gói tin này sẽ
được chuyển ra liên kết đầu ra.
313
Trong ví dụ trên, 2 gói tin mới đến tại phía vào của bộ chuyển, một
trong những gói tin này đi ra ngõ ngoài trên nhất.
Chúng ta hiểu rằng việc tồn tại bộ đệm của bộ định tuyến là cần thiết,
câu hỏi được đặt ra là bộ đệm (buffering) bao nhiêu là đủ. Trong nhiều
năm, qui luật cho kích thước của bộ đệm là số lượng của buffering (B)
nên bằng với thời gian RTT trung bình nhân với khả năng của đường
liên kết (C). Vì vậy, một liên kết 10Gbps với một RTT là 250 msec sẽ
cần một số lượng bộ đệm là B=RTTxC=2.5Gbps. Tuy nhiên, các
nghiên cứu về mặt lí thuyết và thí nghiệm hiện tại đề nghị rằng khi có
số lượng N luồng TCP đi qua một liên kết, kích thước bộ đệm cần là
B=RTT*C/
Sau khi gói tin nằm trong hàng đợi tại ngõ ra và bắt đầu được xử lí,
một bộ lập lịch gói tin tại ngõ ra phải chọn gói tin trong số các gói tin
nằm trong hàng đợi. Việc lựa chọn này có thể thực hiện đơn giản, như
đến trước phục vụ trước (First-come-First-Server – FCFS) hay các lập
lịch phức tạp khác như hàng đợi cân bằng có trọng số ( Weighted Fair
Queuing -WFQ), chính sách lập lịch chia sẻ liên kết đầu ra công bằng
cho tất các kết nối cuối-đến-cuối khác nhau mà có gói tin nằm trong
hàng đợi. Lập lịch gói tin đóng một vai trò quan trọng trong việc cung
cấp việc đảm bảo chất lượng dịch vụ.
Trong trường hợp nếu không có đủ bộ nhớ cho việc đưa một gói tin
đến vào bộ đệm, một quyết định phải được đưa ra để hoặc rớt (drop)
gói tin đến (chính sách gọi là rớt ở đuôi drop-tail) hoặc loại bỏ một
trong những gói tin trong hàng đợi để chừa chỗ trống cho gói tin mới
đến. Trong vài trường hợp, nó có thể làm rớt (drop) trước các gói tin
trước khi bộ đệm bị đầy để cung cấp một tín hiệu nghẽn cho nơi gửi.
Một trong những giải thuật được nghiên cứu và triển khai rộng rãi là
phát hiện sớm ngẫu nhiên (Radom Early Detection -RED). Với RED,
một trọng số trung bình được duy trì cho kích thước của hàng đợi.
Nếu kích thước hàng đợi trung bình nhỏ hơn một giá trị nhỏ nhất,
minth, khi một gói tin đến, gói tin được chấp nhận vào hàng đợi.
Ngược lại, nếu hàng đợi đầy hoặc kích thước hàng đợi trung bình lớn
hơn giá trị lớn nhất, maxth, thì khi một gói tin đến, gói tin sẽ bị đánh
dấu hoặc bị rớt. Cuối cùng, nếu gói tin đến khi kích thước hàng đợi
trung bình thuộc khoảng minth và maxth, gói tin sẽ bị đánh dấu hoặc
314
bị rớt với một xác xuất là hàm của kích thước hàng đợi trung bình,
minth và maxth. Một số lượng các hàm xác suất đánh dấu/rớt được đề
xuất, và các phiên bản khác của RED được mô hình hóa, mô phỏng và
/hoặc được triển khai.
Nếu bộ chuyển không đủ nhanh để chuyển tất cả các gói tin đến thông
qua nó, việc phải đợi tại các ngõ vào có thể xảy ra, các gói tin phải
vào các hàng đợi ngõ vào để chờ tới lượt của nó để được chuyển qua
bộ chuyển để ra ngõ ra. Để minh hoạt một kết quả quan trọng của
hàng đợi này, hãy xem một bộ chuyển dạng crossbar và giả sử rằng
1) tốc độ các liên kết là như nhau, (2) một gói tin có thể được chuyển
từ một ngõ vào ra một ngõ ra nào đó trong cùng thời gian mà nó lấy
một gói tin để được nhận tại một ngõ vào, và (3) gói tin được di
chuyển từ một ngõ vào nào đó ra hàng đợi ngõ ra mong muốn theo
kiểu FCFS. Nhiều gói tin có thể được chuyển song song, miễn là các
ngõ ra của nó là khác nhau. Tuy nhiên, nếu 2 gói tin đến trước 2 hàng
đợi vào có cùng hàng đợi đi ra, thì một trong những gói tin này sẽ phải
bị khóa và chờ trong hàng đợi vào –bởi bộ chuyển có thể chỉ chuyển
một gói tin cho một ngõ ra tại một thời điểm.
Hình 4.11 cho một ví dụ mà 2 gói tin màu đen) tới trước các hàng đợi
vào của nó và có cùng ngõ ra phía trên bên phải. Giả sử rằng bộ
chuyển chọn gói tin phía trước của hàng đợi phía trên bên trái để
chuyển. Trong trường hợp này, gói tin ở hàng đợi phía dưới bên trái
phải chờ. Nhưng không chỉ các gói tin màu đen này chờ, gói tin màu
xanh trắng nằm trong hàng đợi phía sau gói tin đó ở hàng đợi phía
dưới bên trái cũng phải chờ, cho dù không có nội dung nào cho ngõ ra
chính giữa bên phải ( đích của gói tin xanh). Hiện tượng này được biết
như là khóa đầu đường dây (head-of-the-line blocking - HOL) trong
một bộ chuyển có hàng đợi ngõ vào – gói tin đợi ở hàng đợi ngõ vào
phải chờ cho việc chuyển qua bộ chuyển( mặc dù ngõ ra là trống) bởi
vì nó bị khóa bởi các gói tin khác tại đầu của dòng. Bởi vì HOL
bloking, hàng đợi vào có thể sẽ tăng tới chiều dài không giới hạn được
(dưới các giả thuyết nào đó rằng) ngay khi tốc độ gói tin đến trên liên
kết vào đạt tới 58 phần trăm khả năng của nó.
315
Tại thời điểm t

Gói màu đen được chuyển
Bộ chuyển
Gói tin màu xanh bị khóa đầu ra
Bộ chuyển
Ghi chú:
Đi ra ngõ ra cao nhất Đi ra ngõ ra chính giữa Đi ra ngõ ra thấp nhất
Hình 4.11 - Khóa đầu ra một hàng đợi ngõ vào
IV. Giao thức IP

Các thảo luận của về vấn đề chuyển tiếp và định địa chỉ tầng Mạng tới
thời điểm này không đề cập cụ thể về một mạng máy tính nào cả.
Trong phần này, chúng ta sẽ quan tâm đến việc chuyển tiếp và định
địa chỉ được thực hiện trên mạng Internet. Chúng ta sẽ nhận thấy rằng
định địa chỉ Internet và chuyển tiếp là các thành phần quan trọng của
giao thức Internet(IP). Có hai phiên bản của IP hiện đang được sử
dụng. Đầu tiên, chúng ta sẽ khảo sát giao thức IP phiên bản được triển
khai rộng rãi là phiên bản 4, thường được biết đến với tên IPv4 [RFC
791]. Chúng ta sẽ khảo sát IP phiên bản 6 [RFC 2460; RFC 4291],
được đưa ra để thay thế IPv4, vào cuối phần này.
316
Nhưng trước khi đi vào IP, hãy xem xét xem những thành phần nào
cấu tạo nên tầng Mạng của Internet.
Như trong hình 4.12, lớp mạng của Internet có ba thành phần chính.
Thành phần đầu tiên là giao thức IP, chủ đề của phần này. Thành phần
chính tiếp theo là thành phần định tuyến, thành phần xác định đường
đi của gói dữ liệu từ nguồn đến đích. Chúng ta đã đề cập trước đó rằng
những giao thức định tuyến sẽ tính toán ra những bảng chuyển tiếp
được sử dụng để chuyển tiếp các gói tin trong mạng. Chúng ta sẽ
nghiên cứu giao thức định tuyến của Internet ở phần 4.6.
Tầng vận chuyển: TCP, UDP
Giao thức IP
Giao thức định tuyến
• Qui ước về địa chỉ
• Lựa chọn đường
• Định dạng gói tin
• RIP, OSPF, BGP
• Qui ước xử lí gói tin
Tầng mạng
Bảng chuyển
tiếp
Giao thức ICMP

• Thông báo lỗi
• “Báo hiệu” bộ định tuyến
Tầng liên kết
Tầng vật lí
Hình 4.12 – Tầng Mạng

Thành phần cuối cùng của tầng Mạng là một phương tiện để báo lỗi
các gói dữ liệu và trả lời thông tin tầng Mạng nào đó.
Chúng ta cũng sẽ tìm hiểu khái quát giao thức thông báo lỗi và thông
báo thông tin của tầng Mạng Internet, Giao thức điều khiển thông điệp
Internet (ICMP), trong phần 4.4.3.
IV.1 Khuôn dạng gói tin của IP
Nhắc lại, gói tin của lớp mạng được xem như là một gói dữ liệu
(datagram). Chúng ta bắt đầu nghiên cứu về IP bằng việc xem xét
317
tổng quan về cú pháp và ngữ nghĩa của gói dữ liệu IPv4. Chúng ta có
thể nghĩ rằng không có gì khô khan hơn cú pháp và ngữ nghĩa của các
bit của một gói tin. Tuy nhiên, gói dữ liệu đóng vai trò trung tâm trong
Internet – mỗi một sinh viên cũng như chuyên gia mạng cần phải biết,
thấu hiểu và thành thạo nó. Định dạng của gói dữ liệu IPv4 được biểu
diễn như trên hình 4.13. Các trường chính của gói dữ liệu IPv4 bao
gồm:
▪ Version number. Thể hiện bằng 4 bit cho biết phiên bản giao
thức IP của gói dữ liệu. Bằng cách nhìn vào số hiệu của phiên
bản, bộ định tuyến có thể hiểu được phần còn lại của gói dữ liệu
IP như thế nào. Những phiên bản khác nhau của IP sử dụng
những định dạng gói dữ liệu khác nhau. Định dạng của gói dữ
liệu cho phiên bản hiện tại của IP, IPv4, được thể hiện ở hình
4.13. Định dạng của gói dữ liệu cho phiên bản mới của IP, IPv6,
được thảo luận vào cuối phần này.
▪ Header length. Vì gói dữ liệu IPv4 có thể chứa nhiều các tùy
chọn khác nhau (được đưa vào trong phần đầu của gói dữ liệu
IPv4), 4 bit này cần đến để xác định xem gói dữ liệu bắt đầu từ
đâu. Hầu hết các gói dữ liệu IP không chứa các tùy chọn, do đó
một gói dữ liệu IP bình thường sẽ có phần đầu là 20 byte.
▪ Type of service. Các bit loại dịch vụ bên trong phần đầu của gói
dữ liệu IPv4 cho phép phân biệt nhiều kiểu gói dữ liệu IP (ví dụ
gói dữ liệu yêu cầu độ trễ thấp, băng thông cao hay tính tin cậy).
Ví dụ, việc phân biệt được giữa gói dữ liệu thời gian thật (được
sử dụng bên trong các ứng dụng thoại IP) với các lưu lượng
không thời gian thật (như FTP) là rất hữu ích. Mức độ chi tiết của
dịch vụ được cung cấp là một vấn đề liên quan tới chính sách
được xác định bởi các nhà quản trị các bộ định tuyến..
▪ Datagram length. Đây là tổng độ dài của gói dữ liệu (phần đầu
và phần dữ liệu) được tính bằng byte. Vì trường này dài 16 bit do
đó kích thước tối đa của gói dữ liệu IP trên lý thuyết là 65535
byte. Dù vậy, rất ít gói dữ liệu nào có kích thước lớn hơn 1500
byte.
▪ Identifier, flags, fragmentation offset. Ba trường này liên quan
đến vấn đề phân mảnh IP, một chủ đề sẽ được đi sâu ở phần sau.
318
Tuy nhiên, phiên bản sau của IP, IPv6 không cho phép phân
mảnh tại các bộ định tuyến.
▪ Time-to-live. Trường time to live được đưa vào để đảm bảo các
gói dữ liệu trong mạng không bị lặp lại vô tận. Trường này được
giảm đi một mỗi khi gói dữ liệu được xử lý bởi bộ định tuyến.
Nếu trường TTL về 0, thì gói dữ liệu phải bị hủy.
32 bits
Header
Version Type of service Datagram length (bytes)
Length
16-bit identifier Flags 13-bit-Fragmentation offset
Time-to-live Upper-layer protocol Header checksum
32 – bit Source IP address
32 – bit Destination IP address
Option (if any)
Data
Hình 4.13 – Khuôn dạng gói tin IPv4
▪ Protocol. Trường này được sử dụng khi mà một gói dữ liệu IP

đến được đích cuối cùng. Giá trị của turờng này chỉ ra giao thức
cụ thể của tầng Vận chuyển, nơi mà thông tin của gói dữ liệu IP
này được chuyển đến. Ví dụ, giá trị trường bằng 6 cho biết dữ liệu
được chuyển cho TCP, trong khi giá trị bằng 17 cho biết dữ liệu
được chuyển cho UDP. Lưu ý rằng chỉ số của giao thức trong gói
dữ liệu IP khác với trường chỉ số cổng trong gói tin tại tầng Vận
chuyển. Chỉ số giao thức dùng để gắn kết tầng Mạng với tầng
Vận chuyển lại với nhau trong khi chỉ số cổng gắn kết tầng Vận
chuyển và tầng Ứng dụng lại với nhau. Chúng ta sẽ thấy trong
319
Chương 5 rằng gói tin của lớp liên kết cũng có một trường đặc
biệt kết nối với tầng Mạng.
▪ Header checksum. Header checksum giúp cho bộ định tuyến
phát hiện những bit lỗi trong một gói dữ liệu IP nhận được.
Header checksum được tính bằng cách lấy mỗi 2 byte trong phần
đầu gói tin như một con số và cộng những con số này lại sử dụng
phép tính bù một. Như được thảo luận trong phần 3.3, phép bù 1
của tổng này được biết như là Internet checksum và được lưu trữ
trong trường checksum. Một bộ định tuyến tính toán header
checksum cho mỗi gói dữ liệu IP nhận được và biết được lỗi nếu
như giá trị checksum trong phần đầu của gói dữ liệu không bằng
với giá trị checksum tính toán được. Bộ định tuyến sẽ bỏ những
gói dữ liệu bị lỗi. Lưu ý là checksum phải được tính và lưu trữ lại
tại mỗi bộ định tuyến, vì trường TTL và các tùy chọn khác có thể
thay đổi. Một câu hỏi thú vị thường được đưa ra là tại sao TCP/IP
lại thực hiện việc kiểm lỗi tại cả lớp mạng và lớp vận chuyển? Có
nhiều lý giải cho sự lặp lại này. Đầu tiên, lưu ý rằng chỉ phần đầu
gói tin IP của được kiểm tra tại tầng IP, trong khi checksum của
TCP/UDP được tính toán dựa trên toàn bộ gói tin TCP/UDP. Thứ
hai, TCP/UDP và IP không nhất thiết phải cùng thuộc về cùng
một chồng giao thức. Về lí thuyết TCP có thể chạy trên một giao
thức khác (ví dụ ATM) và IP có thể mang dữ liệu mà không phải
chuyển qua cho TCP/UDP.
▪ Source and destination IP addresses. Khi một nguồn tạo ra một
gói dữ liệu, nó thêm vào địa chỉ IP của nó vào trong trường địa
chỉ IP nguồn và thêm vào địa chỉ của đích đến vào trường địa chỉ
IP đích. Thông thường host nguồn xác địch địa chỉ đích thông qua
truy vấn DNS, như đã thảo luận ở chương 2. Chúng ta sẽ thảo
luận về việc định địa chỉ IP chi tiết hơn ở phần 4.4.2
▪ Options. Các trường tùy chọn làm cho phần đầu gói dữ liệu IP
được mở rộng thêm. Các tùy chọn hiếm khi được sử dụng, lí do là
việc tiết kiệm chi phí cho việc xử lí phần đầu của gói dữ liệu. Tuy
nhiên, sự tồn tại của các tùy chọn khiến cho việc xử lí phức tạp
hơn - vì phần đầu của gói dữ liệu có chiều dài thay đổi được,
người ta không thể xác định được vị trí mà trường dữ liệu bắt đầu.
Hơn nữa, vì một số gói dữ liệu có thể yêu cầu xử lí các tùy chọn,
320
còn một số khác thì không cần, thời gian cần để xử lý một gói dữ
liệu IP tại bộ định tuyến có thể khác nhau nhiều. Những vấn đề
này trở nên đặc biệt quan trọng trong xử lý các gói tin IP trong
các bộ định tuyến yêu cầu hiệu năng cao. Vì những lý do trên, các
tùy chọn IP được bỏ đi trong phần đầu của IPv6, điều này được
thảo luận tại phần 4.4.4.
▪ Data. Đây được xem là trường quan trọng nhất của gói dữ liệu.
Trong hầu hết các trường hợp, trường dữ liệu của gói dữ liệu IP
chứa gói tin của tầng Vận chuyển (TCP hoặc UDP) để được
chuyển đến đích. Tuy nhiên, trường dữ liệu có thể chứa các loại
dữ liệu khác, như các thông điệp ICMP (được thảo luận tại phần
4.4.3).
Lưu ý rằng gói dữ liệu IP chứa tổng cộng 20 byte cho phần đầu (giả
sử không có tùy chọn nào). Nếu gói dữ liệu chứa gói tin ở tầng TCP,
thì mỗi gói dữ liệu (không phân mảnh) chứa tổng cộng 40 byte cho
phần đầu (20 byte cho phần đầu IP và 20 byte cho phần đầu TCP)
cùng với thông tin của lớp ứng dụng.
IV.1.1 Phân mảnh gói dữ liệu IP
Chúng ta sẽ thấy trong Chương 5 rằng không phải tất cả các giao thức
tầng Liên kết đều có thể mang các gói tin ở tầng Mạng với cùng kích
thước. Một vài giao thức có thể mang theo các gói dữ liệu lớn, trong
khi số khác chỉ có thể mang các gói tin nhỏ. Ví dụ, các khung tin
(frame) Ethernet chỉ có thể mang theo 1500 byte dữ liệu, trong khi
khung tin cho các liên kết mạng diện rộng chỉ có thể mang theo không
đến 576 byte. Lượng dữ liệu tối đa mà một khung tin của tầng Liên
kết có thể mang được gọi là đơn vị truyền dẫn tối đa (maximum
transmission unit – MTU). Bởi vì mỗi gói dữ liệu IP được đóng gói
bên trong khung tin của tầng Liên kết để truyền đi từ một bộ định
tuyến sang một bộ định tuyến khác, MTU của giao thức của tầng Liên
kết đặt ra một giới hạn cứng (hard limit) cho chiều dài của gói dữ liệu
IP. Giới hạn cứng cho chiều dài này của gói dữ liệu IP không phải là
vấn đề lớn. Vấn đề ở chỗ mỗi một liên kết của bộ định tuyến giữa bên
truyền và nhận có thể dùng các giao thức tầng Liên kết khác nhau, và
mỗi một giao thức này có thể có các MTU khác nhau.
321
Để hiểu được vấn đề chuyển tiếp tốt hơn, hãy tưởng tượng chúng ta là
bộ định tuyến nối với vài liên kết, mỗi một liên kết sử dụng một giao
thức tầng Liên kết khác nhau với các MTU khác nhau. Giả sử sau khi
nhận được một gói dữ liệu IP từ một liên kết, chúng ta kiểm tra bảng
chuyển tiếp để xác định liên kết đầu ra là gì, và nhận thấy rằng liên kết
đầu ra này có MTU nhỏ hơn chiều dài của gói dữ liệu IP. Làm thế nào
để chúng ta nén gói dữ liệu IP quá cỡ này lại để đưa vào trường dữ
liệu của khung tin tầng Liên kết?. Giải pháp là phân mảnh dữ liệu
trong gói dữ liệu IP thành hai hay nhiều gói dữ liệu IP nhỏ hơn, sau đó
đóng gói từng gói dữ liệu IP nhỏ hơn này vào các khung tin tầng Liên
kết riêng biệt và gửi những khung tin này qua liên kết đầu ra. Mỗi một
gói dữ liệu nhỏ hơn này được gọi là một mảnh dữ liệu (fragment).
Các mảnh dữ liệu cần được ghép lại trước khi chúng đến được tầng
Vận chuyển tại đích. Thật ra, cả TCP và UDP đều mong đợi nhận
được những gói tin hoàn chỉnh và không phân mảnh từ lớp mạng. Các
nhà thiết kế của IPv4 nghĩ rằng việc ghép các gói dữ liệu tại bộ định
tuyến sẽ làm tăng độ phức tạp cho giao thức và làm giảm hiệu năng
của bộ định tuyến. Với tư tưởng mong muốn giữ cho phần lõi của
mạng đơn giản, các nhà thiết kế IPv4 quyết định để việc gắn các mảnh
dữ liệu được thực hiện bởi các hệ thống đầu cuối hơn bởi các bộ định
tuyến mạng.
Khi một máy tính ở đích nhận được một chuỗi các gói dữ liệu đến từ
cùng một nguồn, nó cần phải xác định xem những gói dữ liệu này là
những mảnh nhỏ của gói dữ liệu lớn hơn hay không. Nếu một vài gói
dữ liệu là những mảnh dữ liệu, nó cần xác định xem là nó đã nhận
được mảnh cuối cùng chưa và những mảnh dữ liệu đã nhận được phải
được nối lại như thế nào để tạo thành gói dữ liệu gốc ban đầu. Để cho
máy tính ở đích làm được việc lắp ráp này, các nhà thiết kế IP (phiên
bản 4) đặt các trường identification, flag và fragmentation offset trong
phần đầu của gói dữ liệu IP. Khi một gói dữ liệu được tạo ra, bên host
gửi sẽ đóng dấu vào gói dữ liệu đó chỉ số định danh cũng như các địa
chỉ nguồn và đích. Sau đó host gửi sẽ tăng dần chỉ số định danh cho
mỗi gói dữ liệu mà nó gửi. Khi một bộ định tuyến cần phân mảnh một
gói dữ liệu, mỗi một gói dữ liệu kết quả (là một fragment) được đóng
dấu bằng địa chỉ nguồn, đích và chỉ số định danh của gói dữ liệu ban
đầu. Khi ở đích nhận được một chuỗi các gói dữ liệu gửi đi từ cùng
322
một host, nó sẽ khảo sát các số định danh của các gói dữ liệu và xác
định xem các gói dữ liệu này thật sự có phải là các mảnh dữ liệu của
cùng một gói dữ liệu lớn hơn hay không. Bởi vì IP là một dịch vụ
không tin cậy, một hoặc nhiều mảnh dữ liệu có khả năng không bao
giờ đến được đích. Vì lý do này, để đảm bảo cho host ở đích có thể
chắc chắn đã nhận được mảnh dữ liệu cuối cùng của gói dữ liệu ban
đầu, mảnh dữ liệu cuối cùng này sẽ có bit flag là 0, trong khi các
mảnh dữ liệu khác sẽ có bit flag là 1. Hơn nữa, để cho host ở đích xác
định là một gói dữ liệu có bị thiếu hay không (và để lắp ghép chúng
theo đúng thứ tự), trường offset được sử dụng để cho biết vị trí của
fragment này trong gói dữ liệu IP ban đầu.
Phân mảnh
Vào: Một gói tin lớn 4000 byte
Ra: 3 gói tin nhỏ hơn
MTU 1500 byte
Gắn lại
Vào: 3 gói tin nhỏ
Ra: 1 gói tin lớn (4000 byte)
Hình 4.14 – Phân mảnh gói tin và gắn lại

Hình 4.14 là một ví dụ. Một gói dữ liệu 4000 byte (20 byte cho phần
đầu gói IP cộng với 3980 byte của phần dữ liệu (payload) ) đến một
bộ định tuyến và phải được chuyển tiếp ra một liên kết có MTU là
1500 byte. Điều này có nghĩa là 3980 byte dữ liệu trong gói dữ liệu
ban đầu phải được chia thành 3 mảnh dữ liệu (mỗi mỗi mảnh là một
gói dữ liệu IP). Giả sử gói dữ liệu ban đầu được đóng dấu với chỉ số
định danh là 777. Các đặc điểm của 3 mảnh dữ liệu này được thể hiện
ở bảng 4.2. Các giá trị trong bảng 4.2 thể hiện yêu cầu rằng lượng dữ
323
liệu ban đầu trong tất cả mảnh dữ liệu ngoại trừ mảnh dữ liệu cuối là
bội của 8 byte, và giá trị offset được xác định theo đơn vị từng khúc 8
byte (8-byte chunk).
Tại đích, phần dữ liệu của gói dữ liệu được chuyển đến tầng Vận
chuyển chỉ sau khi lớp IP đã tái tạo lại hoàn toàn gói dữ liệu IP ban
đầu. Nếu một hoặc nhiều mảnh dữ liệu không đến được đích thì gói
dữ liệu không hoàn chỉnh sẽ bị bỏ đi và không được chuyển đến tầng
Vận chuyển. Tuy nhiên, như đã biết ở chương trước, nếu TCP được
sử dụng trong tầng Vận chuyển, TCP sẽ phục hồi việc mất mảnh dữ
liệu này bằng cách truyền lại dữ liệu trong gói dữ liệu ban đầu.
Bảng 4.2 – Phân mảnh gói tin IP

Chúng ta vừa biết được rằng việc phân mảnh IP đóng vai trò quan
trọng gắn kết nhiều công nghệ khác nhau ở tầng Liên kết. Nhưng việc
phân mảnh cũng có cái giá của nó. Đầu tiên nó làm phức tạp hóa bộ
định tuyến và các hệ cuối khi gói tin cần phải được phân mảnh và gắn
lại. Hơn nữa việc phân mảnh có thể bị lợi dụng để thực hiện các tấn
công DoS nguy hiểm khi mà kẻ tấn công gửi một chuỗi các mảnh dữ
liệu kì quái và không lường trước được. Một ví dụ điển hình là tấn
công Jolt2, khi mà kẻ tấn công gửi một luồng các mảnh dữ liệu nhỏ
đến host mục tiêu, không có một mảnh dữ liệu nào có offset là 0. Mục
tiêu của cuộc tấn công là phá vỡ nổ lực gắn lại các gói dữ liệu. Một
trường hợp khai thác lỗ hỗng khác là gửi những mảnh dữ liệu với các
có giá trị offset được thiết lập để cho các mảnh dữ liệu không được
sắp xếp đúng. Các hệ điều hành yếu không biết phải làm gì với các
324
mảnh dữ liệu bị trùng lấp có thể sẽ bị sụp đổ. Khi chúng ta đến cuối
phần này, một phiên bản mới của giao thức IP, IPv6, đã loại bỏ việc
phân mảnh, xử lý các gói tin IP hợp lý hơn và làm cho IP khó bị tấn
công hơn.
IV.2 Địa chỉ IPv4
Phần này chúng ta sẽ tìm hiểu về địa chỉ IPv4. Mặc dù chúng ta có thể
nghĩ rằng việc định địa chỉ có lẽ là một chủ đề đơn giản và nhàm chán,
tuy nhiên chủ đề về địa chỉ Internet không chỉ là một chủ đề lý thú, mà
còn là một phần quan trọng của Internet.
Trước khi thảo luận về việc định địa chỉ IP, chúng ta cần biết cách các
host và các bộ định tuyến kết nối vào mạng như thế nào. Một host
thường chỉ có một liên kết đơn đến mạng; khi một IP trong host muốn
gửi đi một gói dữ liệu, nó sẽ được thực hiện trên liên kết này. Ranh
giới giữa host và liên kết vật lý được gọi là giao diện (interface). Bây
giờ hãy xem xét một bộ định tuyến và các giao diện của nó. Bởi vì
công việc của một bộ định tuyến là nhận một gói dữ liệu từ một liên
kết và chuyển tiếp gói dữ liệu đó đến một số liên kết nào khác, một bộ
định tuyến cần phải có hai hoặc nhiều liên kết được kết nối. Bởi vì
mỗi host và bộ định tuyến có khả năng gửi và nhận các gói dữ liệu IP,
giao thức IP yêu cầu mỗi host và interface của bộ định tuyến phải có
địa chỉ IP của riêng nó. Do đó, về mặt kỹ thuật địa chỉ IP được gắn
cho một interface, hơn là cho một host hay bộ định tuyến chứa
interface đó.
Mỗi một địa chỉ IP có độ dài 32 bit (tương đương 4 byte) và vì vậy có
tổng cộng 232 địa chỉ IP có thể có. Bằng cách xấp xỉ 210 với 103 ta có
thể thấy được có khoảng 4 tỷ địa chỉ IP có thể có. Những địa chỉ này
được viết dưới dạng các số thập phân được ngăn cách bởi dấu
chấm (dotted-decimal notation), trong đó mỗi byte của địa chỉ được
viết dưới dạng thập phân và được cách biệt với các byte khác bằng
một dấu chấm trong địa chỉ. Ví dụ, xem xét địa chỉ IP sau:
193.32.216.9. Phần 193 tương đương với 8 bit đầu của địa chỉ; phần
32 tương được với 8 bit tiếp theo, và tiếp tục. Do đó địa chỉ
193.32.216.9 nếu viết dưới ký pháp nhị phân sẽ như sau:
11000001 00100000 11011000 00001001
325
Mỗi một interface trên mỗi host và trên bộ định tuyến trên mạng
Internet toàn cầu phải có một địa chỉ IP độc nhất (ngoại trừ các
interface hoạt động với NAT, sẽ được thảo luận vào cuối phần này).
Các địa chỉ này không thể được chọn lựa bằng cách chọn đại. Một
phần của địa chỉ IP của một interface sẽ được xác định bởi mạng con
(subnet) mà nó kết nối đến.
Hình 4.15 cung cấp một ví dụ về địa chỉ IP và các interface. Trong
hình này, một bộ định tuyến (với ba interface) được sử dụng để liên
kết 7 host. Xem xét kỹ các địa chỉ IP được gán cho host và các
interface của bộ định tuyến; có có vài thứ cần phải lưu ý. Ba host ở
phần phía trên bên trái trong hình 4.15 và interface của bộ định tuyến
mà chúng kết nối đến đều có địa chỉ IP dạng 223.1.1.xxx. Như vậy,
chúng có cùng 24 bit bên trái trong địa chỉ IP. Bốn interface đồng thời
cũng kết nối với nhau bởi một mạng không chứa bộ định tuyến (ví dụ,
mạng này có thể là mạng Ethernet LAN, trong trường hợp các
interface được kết nối với nhau bởi một Ethernet hub hoặc Ethernet
switch; xem thêm ở chương 5.)
Hình 4.15 – Địa chỉ IP và các mạng con
326
Trong thuật ngữ IP, mạng này kết nối ba interface của các host và một
interface của bộ định tuyến lại với nhau để tạo thành một mạng con
(subnet) [RFC 950]. (Một mạng con cũng được gọi là mạng IP hoặc
đơn giản là mạng). Địa chỉ IP được gán cho mạng này: 223.1.1.0/24,
trong đó phần /24, đôi lúc được biết đến như là mặt nạ mạng con
(subnet mask) cho biết phần bên trái nhất 24 bit của 32 bit này là địa
chỉ mạng con. Do đó mạng con 223.1.1.0/24 bao gồm ba interface của
host (223.1.1.1, 223.1.1.2, 223.1.1.3) và một interface của bộ định
tuyến (223.1.1.4). Mọi host khác được nối vào mạng con này đều phải
có địa chỉ dạng 223.1.1.xxx. Có hai mạng con khác trong hình 4.15:
mạng 223.1.2.0/24 và mạng con 223.1.3.0/24. Hình 4.16 thể hiện ba
mạng con IP được giới thiệu trong hình 4.15.
Định nghĩa về mạng con trong IP không giới hạn trong các phần mạng
(segment) của Ethernet kết nối nhiều host đến các interface của bộ
định tuyến. Hãy xem thêm hình 4.17, thể hiện 3 bộ định tuyến kết nối
với nhau bằng các liên kết điểm-điểm. Mỗi bộ định tuyến có ba
interface, một interface cho mỗi kết nối điểm-đến-điểm, một cho liên
kết quảng bá (broadcast) kết nối trực tiếp bộ định tuyến đến một cặp
host. Có những mạng con nào trong này? Có ba mạng con,
223.1.1.0/24, 223.1.2.0/24 và 223.1.3.0/24, tương tự như những mạng
con đã gặp trong hình 4.15. Nhưng chú ý rằng có thêm ba mạng con
khác trong ví dụ này: 223.1.9.0/24 dùng để kết nối các bộ định tuyến
R1 và R2; một mạng con khác 223.1.8.0/24 để kết nối các bộ định
tuyến R2 và R3; và mạng con thứ ba 223.1.7.0/24 để kết nối bộ định
tuyến R3 và R1.
Trong hệ thống kết nối các host và bộ định tuyến chung, chúng ta cần
sử dụng phương pháp sau để định nghĩa các mạng con trong hệ thống
Để xác định các mạng con, tháo các interface ra khỏi host hoặc
bộ định tuyến của nó, tạo ra những mạng cô lập với những
interface là điểm kết thúc của các mạng cô lập đó. Mỗi một mạng
cô lập này được gọi là mạng con.
Nếu áp dụng phương pháp này cho hệ thống trong hình 4.17, chúng ta
sẽ có 6 mạng con.
327
Hình 4.16 – Địa chỉ các mạng con

Từ thảo luận trên, có một điều rõ ràng là một tổ chức (như một công
ty hoặc một tổ chức học thuật) với nhiều nhánh mạng (segment)
Ethernet và các liên kết điểm-đến-điểm sẽ có nhiều mạng con, với tất
cả các thiết bị trên một mạng con có cùng một địa chỉ mạng con. Trên
lý thuyết, các mạng con khác nhau sẽ có địa chỉ mạng con khác khác
nhau. Tuy nhiên, trên thực tế thì các địa chỉ của mạng con có nhiều
điểm chung. Để hiểu thêm, hãy xem cách mà địa chỉ được xử lý trên
mạng Internet toàn cầu.
Hình 4.17 – Ba bộ định tuyến liên kết với 6 mạng con
328
Phương thức gán địa chỉ của Internet là Classless Interdomain

Routing (CIDR – đọc là cider) [RFC 4632]. CIDR khái quát hóa việc
định địa chỉ của mạng con. Với địa chỉ mạng con, địa chỉ IP 32 bit
được chia làm hai phần và có dạng a.b.c.d/x, trong đó x cho biết số bit
trong phần đầu tiên của địa chỉ.
Phần x bit là phần quan trọng nhất của địa chỉ a.b.c.d/x, thường được
biết đến là tiếp đầu ngữ (prefix) (hoặc prefix của mạng) của địa chỉ.
Một tổ chức được cấp phát một khối địa chỉ liên tục, đó là một dãy các
địa chỉ với tiếp đầu ngữ giống nhau. Trong trường hợp này, địa chỉ IP
của các thiết bị bên trong tổ chức sẽ có cùng tiếp đầu ngữ.
Tổ chức 0
200.23.16.0/23
Tổ chức 1 “gửi cho tôi với địa chỉ bắt

200.23.18.0/23 đầu 200.23.16.0/20”
Fly By Night ISP

Tổ chức 2
200.23.20.0/23
Internet
Tổ chức 77 “gửi cho tôi với địa chỉ bắt

200.23.30.0/23 đầu 199.31.0.0/16”
ISPs-R-Us
Hình 4.18 – Địa chỉ phân cấp và việc liên kết các đường đi
329
Tổ chức 0
200.23.16.0/23
Tổ chức 2 “Gửi cho tôi với địa chỉ bắt

200.23.20.0/23 đầu 200.23.16.0/20”
Fly ByNight-ISP
Tổ chức 7
200.23.30.0/23
Internet
“Gửi cho tôi với địa chỉ bắt
Tổ chức 1
đầu 199.31.0.0/16 hoặc
200.23.18.0/23 200.23.18.0/23”
ISPs-R-Us
Hình 4.18 – ISP –R- US có đường chi tiết hơn

Khi đến phần giao thức định tuyến BGP của Internet trong phần 4.6,
chúng ta sẽ thấy chỉ có duy nhất x bit tiếp đầu ngữ này được xem xét
bởi bộ định tuyến bên ngoài mạng của tổ chức. Nghĩa là, khi một bộ
định tuyến bên ngoài tổ chức chuyển tiếp một gói dữ liệu có địa chỉ
đích là bên trong tổ chức, chỉ có x bit đầu của địa chỉ được xem xét
đến. Điều này làm giảm đáng kể kích thước của bảng chuyển tiếp
trong những bộ định tuyến này, vì một dòng đơn dưới dạng a.b.c.d/x
sẽ mang lại hiệu quả trong việc chuyển tiếp các gói tin đến bất kì đích
đến nào trong tổ chức.
Phần 32-x bit còn lại của địa chỉ được dùng đến để phân biệt giữa các
thiết bị trong tổ chức, chúng đều có chung tiếp đầu ngữ. Những bit
này được xem xét đến khi những gói tin được chuyển tiếp tại các bộ
định tuyến bên trong tổ chức. Những bit ở thứ tự thấp hơn này có thể
330
(hoặc không thể) có cấu trúc mạng con riêng, như đã thảo luận bên
trên. Ví dụ, cho biết rằng 21 bit đầu tiên của địa chỉ đã qua CIDR
a.b.c.d/21 diễn tả tiếp đầu ngữ của mạng của một tổ chức và giống
như các địa chỉ IP của các thiết bị khác trong tổ chức. 11 bit còn lại sẽ
xác định các host cụ thể trong tổ chức. Cấu trúc bên trong của tổ chức
có thể là 11 bit bên phải nhất được sử dụng cho mạng con bên trong tổ
chức, như đã thảo luận ở trên. Ví dụ, a.b.c.d/24 có thể chỉ đến một
mạng con cụ thể bên trong tổ chức.
Trước khi CIDR được sử dụng, một bộ phận mạng của địa chỉ IP bị
giới hạn ở 8, 16, hoặc 24 bit chiều dài, một sơ đồ địa chỉ biết đến với
tên classful addressing, khi các mạng con với 8, 16, 24 bit địa chỉ
biết đến như là mạng lớp A, B, và C. Yêu cầu của phần mạng con của
địa chỉ IP phải có chính xác độ dài là 1,2 hoặc 3 byte trở nên là một
vấn đề cho việc hỗ trợ sự phát triển nhanh chóng của các tổ chức với
các mạng con kích thước vừa và nhỏ. Một mạng con lớp C (/24) có
thể chứa đến 28 – 2 = 254 host (2 trong số 28 = 256 địa chỉ đựa để
dành cho mục đích đặc biệt) – là quá nhỏ so với nhiều tổ chức. Mặt
khác, mạng con lớp B (/16), có khả năng hỗ trợ 65,634 host, thì lại
quá nhiều. Thông qua classful addressing, một tổ chức với, giả sử
2000 host, sẽ được cấp phát các địa chỉ mạng con lớp B(/16). Điều
này dẫn đến sự suy kiệt của không gian địa chỉ lớp B và tận dụng kém
không gian địa chỉ. Ví dụ, một tổ chức sử dụng địa chỉ lớp B cho 2000
host với một không gian địa chỉ lên đến 65,634 địa chỉ, như vậy là bỏ
phí 63000 địa chỉ không thể dùng cho tổ chức khác được.
Thật là thiếu sót nếu không đề cập đến một loại khác của địa chỉ IP,
đó là địa chỉ broadcast 255.255.255.255. Khi một host gửi một gói dữ
liệu tới địa chỉ đích 255.255.255.255 thì gói tin đó sẽ được chuyển đến
tất cả mọi host trong cùng mạng con. Bộ định tuyến có tùy chọn để
chuyển tiếp gói tin đến các mạng con lân cận (mặc dù thông thường sẽ
không làm vậy).
Sau khi đã nghiên cứu chi tiết địa chỉ IP, chúng ta cần biết làm cách
nào mà host và mạng con lấy được địa chỉ. Hãy bắt đầu bằng việc xem
xét cách mà một tổ chức lấy được khối địa chỉ cho các thiết bị của nó,
và sau đó xem xét cách mà một thiết bị (như là một host) được gán
một địa chỉ từ bên trong khối các địa chỉ của tổ chức.
331
Nhận khối địa chỉ

Để thu nhận một khối các địa chỉ IP để sử dụng trong mạng con của tố
chức, một nhà quản trị mạng đầu tiên có thể phải liên hệ với ISP, nơi
có thể cung cấp những địa chỉ từ một khối địa chỉ lớn hơn mà ISP này
đã được cung cấp. Ví dụ, một ISP có thể đã được cung cấp khối địa
chỉ 200.23.16.0/20. Đến lượt ISP này chia khối địa chỉ này thành 8
khối địa chỉ liên tục có cùng kích thước và chia những khối này cho
tối đa tám tổ chức được hỗ trợ bởi ISP này, như thể hiện ở bên dưới
(Chúng tôi đã gạch dưới những phần của mạng con trong những địa
chỉ này)
ISP 200.23.16.0/20 11001000 00010111 00010000 00000000
Tổ chức 0 200.23.16.0/23 11001000 00010111 00010000 00000000
Tổ chức 1 200.23.18.0/23 11001000 00010111 00010010 00000000
Tổ chức 2 200.23.20.0/23 11001000 00010111 00010100 00000000
…
Tổ chức 7 200.23.23.0/23 11001000 00010111 00011110 00000000
Trong khi thu nhận tập các địa chỉ này từ ISP là một cách để lấy một
khối các địa chỉ, đây không phải là cách duy nhất. Dễ dàng thấy được
là phải có một cách khác nữa để bản thân ISP có thể lấy được khối các
địa chỉ. Có hay không một tổ chức toàn cầu nào có trách nhiệm tuyệt
đối trên việc quản lý các không gian địa chỉ IP và cấp phát các khối
địa chỉ cho các ISP và các tổ chức khác? Thật ra là có! Các địa chỉ IP
được quản lý dưới quyền của Internet Corporation for Assigned
Names and Numbers (ICANN). Chức năng của tổ chức phi lợi nhuận
ICANN không chỉ cấp phát các địa chỉ IP mà con quản lý các máy
phục vụ gốc DNS. Nó còn có nhiệm vụ gán các tên miền và giải quyết
các tranh chấp tên miền. ICANN cấp phát các địa chỉ cho các tổ chức
đăng ký Internet vùng (ví dụ như ARIN, RIPE, APNIC và LACNIC,
chúng cùng nhau tạo thành Tổ chức hỗ trợ địa chỉ (Address
Supporting Organization) của ICANN) và giải quyết việc cấp phát
vàquản lý các địa chỉ trong vùng của chúng.
332
Cấp địa chỉ của một Host: Giao thức Cấu hình Host Động
(Dynamic Host Configuration Protocol)
Khi một tổ chức thu nhận được một khối các địa chỉ, tổ chức đó có thể
gán cho từng host và các interface của bộ định tuyến một địa chỉ IP
riêng biệt. Người quản trị hệ thống sẽ cấu hình bằng tay địa chỉ IP cho
bộ định tuyến (thường là làm từ xa với một công cụ quản trị mạng).
Địa chỉ của host cũng có thể được cấu hình bằng tay, nhưng nhiệm vụ
này thường được giao cho Dynamic Host Configuration Protocol
(DHCP) [RFC 2131]. DHCP cho phép một host thu nhận (hoặc được
cấp phát) địa chỉ IP một cách tự động. Người quản trị mạng có thể cấu
hình DHCP sao cho một host sẽ nhận được cùng một địa chỉ IP mỗi
khi nó kết nối đến mạng, hoặc là một host sẽ được gán một địa chỉ IP
tạm, khác nhau mỗi lần mà host này kết nối đến mạng. Để đảm nhận
nhiệm vụ trên địa chỉ IP, DHCP còn cho phép một host biết được các
thông tin thêm, như là mặt nạ mạng con, địa chỉ của bộ định tuyến ngõ
ra( được gọi là gateway), và địa chỉ của máy phục vụ DNS cục bộ.
Bởi vì DHCP giúp tự động hóa các vấn đề liên quan đến mạng trong
việc kết nối một host vào mạng, nó thường được gọi là giao thức
cắm-và-chạy (plug-and-play protocol). Khả năng này rất thu hút nhà
quản trị mạng, người mà thường phải làm những thao tác này một
cách thủ công. DHCP cũng được sử dụng rộng rãi trong các mạng
Internet gia đình và mạng LAN không dây, nơi mà các host gia nhập
và rời khỏi mạng khá thường xuyên. Ví dụ như một sinh viên cầm một
cái laptop từ phòng trong ký túc xá đến thư viện hay lớp học. Có khả
năng mỗi một nơi sinh viên này sẽ phải kết nối đến một mạng con
khác nhau và sẽ có một địa chỉ IP khác nhau. Trong trường hợp này
thì dùng DHCP sẽ rất lý tưởng, khi mà có nhiều người dùng ra vào, và
những địa chỉ chỉ cần trong một khoảng thời gian giới hạn. DHCP
cũng hữu dụng cho các mạng truy cập ISP dân dụng. Ví dụ như một
ISP dân dụng có 2000 khách hàng, nhưng chỉ có không quá 400 khách
hàng lên mạng trong cùng một thời gian. Trong trường hợp này, thay
vì cần một khối 2048 địa chỉ, một máy phục vụ DHCP mà cấp phát
địa chỉ động chỉ cần một khối 512 địa chỉ (ví dụ một khối có dạng
a.b.c.d/23). Khi host tham gia hay rồi ra khỏi, máy phục vụ DHCP sẽ
cần phải cập nhật danh sách các địa chỉ IP có thể dùng. Mỗi lần một
host gia nhập, máy phục vụ DHCP sẽ cấp phát một địa chỉ trong danh
333
sách các địa chỉ có thể sử dụng, và mỗi khi host này rời khỏi thì địa
chỉ của nó sẽ được khôi phục trong danh sách.
DHCP là một giao thức khách – phục vụ (client-server protocol). Một
máy trạm là một host mới đến đang muốn lấy các thông tin cấu hình
mạng bao gồm cá địa chỉ IP cho chính nó. Trong trường hợp đơn giản
này, mỗi một mạng con sẽ có một máy phục vụ DHCP. Nếu không có
máy phục vụ nào được giới thiệu trong mạng con, phải cần đến một
bộ điều phối các gói tin DHCP (DHCP relay agent - thường là một bộ
định tuyến) biết địa chỉ của máy phục vụ DHCP cho mạng đó. Hình
4.20 cho thấy một máy phục vụ DHCP thuộc mạng con 223.1.2/24 với
một bộ định tuyến làm nhiệm vụ như một bộ điều phối cho các máy
trạm khác đến thuộc mạng con 223.1.1/24 và 223.1.3/24. Trong thảo
luận bên dưới, giả sử một có máy phục vụ DHCP hoạt động trên mạng
con này.
DHCP
Server
223.1.2.5
223.1.2.1
223.1.1.1
223.1.1.4 223.1.2.9
223.1.1.2 223.1.3.27
DCHP Client
đến
223.1.2.2
223.1.1.3
223.1.3.1 223.1.3.2
Hình 4.20 – DHCP Server - Client
334
Đối với một host mới đến, giao thức DHCP sẽ xử lý qua bốn bước,
như trong hình 4.21 cho mạng được thiết lập như trong hình 4.20. Bốn
bước đó là:
Máy chủ DHCP :
Máy khách đến
223.1.2.5
DHCP DISCOVER
Src :0.0.0.0. 68
Dest : 255.255.255.255.67 DHCP OFFER
DCHPDISCOVER
Yiaddr : 0.0.0.0 Src :223.1.2.5.67
Transaction ID : 654 Dest : 255.255.255.255.68
DCHPOFFER
Yiaddr : 223.1.2.4
DHCP REQUEST Transaction ID : 654
Src :223.1.2.5.68 DHCP server ID : 223.1.2.5
Dest : 255.255.255.255.67 Lifetime : 3600 secs
DCHPREQUEST
Yiaddr : 223.1.2.4
Transaction ID : 655
DHCP server ID : 223.1.2.5
DHCP ACK
Lifetime : 3600 secs Src :223.1.2.5.67
Dest : 255.255.255.255.68
DCHPACK
Yiaddr : 223.1.2.4
Transaction ID : 655
DHCP server ID : 223.1.2.5
Lifetime : 3600 secs
Thời gian Thời gian
Hình 4.21 – Tương tác giữa DHCP khách và chủ

▪ Tìm kiếm máy phục vụ DHCP. Nhiệm vụ đầu tiên của một host
mới đến là tìm máy phục vụ DHCP để giao tiếp. Công việc này
được thực hiện thông qua thông điệp tìm kiếm DHCP (DHCP
Discover Message) mà một máy trạm gửi trong gói tin UDP đến
cổng 67. Gói tin UDP được đóng gói trong một gói dữ liệu IP.
Nhưng phải gửi gói dữ liệu này cho ai? Host thậm chí còn chưa
biết địa chỉ IP của mạng mà nó gắn vào cũng như địa chỉ của máy
phục vụ DHCP cho mạng này. Do đó, máy trạm DHCP sẽ tạo ra
một gói dữ liệu IP chứa thông điệp tìm kiếm DHCP của nó với
địa chỉ đích là 255.255.255.255 và địa chỉ nguồn của host này là
335
0.0.0.0. Máy trạm DHCP sẽ chuyển gói dữ liệu IP này đến tầng
Liên kết, sau đó sẽ quảng bá khung tin này rộng rãi đến tất cả các
nút mạng nằm trong mạng con này.
▪ Máy phục vụ DHCP đề nghị. Một máy phục vụ DHCP nhận được
thông điệp tìm kiếm DHCP sẽ trả lời lại cho máy trạm bằng một
thông điệp đề nghị DHCP (DHCP Offer message) được tửi đến
toàn bộ các nút trong mạng con này, và sử dụng địa chỉ IP
broadcast là 255.255.255.255. Bởi vì trên mạng con có thể có vài
máy phục vụ DHCP, máy trạm có thể gặp phải tình huống không
tránh khỏi là phải chọn giữa nhiều lời đề nghị. Mỗi đề nghị sẽ bao
gồm ID của giao tác của thông điệp tìm kiếm nhận được, địa chỉ
IP dự định sẽ cấp cho máy trạm, mặt nạ mạng con, và một thời
gian thuê của địa chỉ IP – khoảng thời gian mà một địa chỉ IP
còn sử dụng được. Thường thì máy phục vụ sẽ đặt thời gian cho
thuê này vào khoảng vài giờ cho đến vài ngày.
▪ Yêu cầu DHCP. Máy trạm mới đến sẽ phải lựa chọn trong số một
hay nhiều các lời đề nghị và trả lời lại cho lời đề nghị nào mà nó
chọn với thông điệp yêu cầu DHCP (DHCP Request message)
gửi đi các tham số cấu hình.
▪ DHCP ACK. Máy phục vụ trả lời thông điệp yêu cầu DHCP bằng
một thông điệp DHCP ACK (DHCP ACK message), xác nhận
các tham số được yêu cầu.
Khi máy trạm nhận được DHCP ACK, tương tác đã được hoàn tất và
máy trạm có thể sử dụng địa chỉ IP do DHCP cấp phát trong thời gian
cho thuê. Bởi vì một máy trạm có thể muốn sử dụng địa chỉ của nó lâu
hơn thời gian hết hạn, DHCP cũng cung cấp một cơ chế cho phép một
máy trạm có thể làm mới lại thời gian thuê cho một địa chỉ IP.
Tầm quan trọng của khả năng cắm-chạy của DHCP là rất rõ ràng tuy
khả năng địa chỉ IP của một host có thể cấu hình bằng tay. Hãy xem
xét một sinh viên di chuyển từ lớp học đến thư viện đến phòng trong
ký túc xá với một laptop, gia nhập vào một mạng con, và do đó thu
nhận được địa chỉ IP mới tại mỗi vị trí. Thật không thể tưởng tượng
được một quản trị hệ thống sẽ phải cấu hình lại cho mỗi laptop tại mỗi
vị trí, và chỉ có một số sinh viên (ngoại trừ những sinh viên học ngành
mạng!) là thành thạo các thao tác cấu hình laptop của họ bằng tay.
Tuy nhiên, xét trên khía cạnh di động, DHCP cũng có một số nhược
336
điểm. Vì một địa chỉ IP mới được tiếp nhận từ DHCP mỗi lần mà một
nút kết nối đến một mạng con mới, một kết nối TCP đến một ứng
dụng từ xa không thể được duy trì khi nút di động di chuyển giữa các
mạng con.
Network Address Translation (NAT)
Với những thảo luận vừa rồi, chúng ta đã biết rõ một thiết bị có khả
năng chạy giao thức IP cần phải có một địa chỉ IP. Với sự phát triển
các mạng con của văn phòng nhỏ, văn phòng tại nhà (SOHO) dẫn đến
việc có khi nào một SOHO muốn thiết lập một mạng LAN để có thể
kết nối nhiều máy, một dãy các địa chỉ cần được cấp phát từ ISP có
thể phân phát hết cho tất cả các máy của SOHO. Nếu như mạng con
này phát triển lớn hơn (ví dụ, những đứa trẻ trong nhà không chỉ có
máy tính riêng của chúng mà còn có PDA cầm tay, điện thoại IP, và
máy Game Boys nối mạng được chẳng hạn) một khối các địa chỉ lớn
hơn phải được cấp phát. Nhưng sẽ ra sao nếu một ISP đã cấp phát hết
các địa chỉ liên tiếp của mạng SOHO này? Một người chủ nhà muốn
(hoặc nên) biết cách nào để quản lý các địa chỉ IP? May mắn thay có
một cách tiếp cận đơn giản hơn để cấp phát địa chỉ trong những tình
huống như vừa rồi: phân giải địa chỉ mạng (Network Address
Translation) (NAT) [RFC 2663; RFC 3022].
Hình 4.22 cho thấy hoạt động của một bộ định tuyến đã bật NAT. Bộ
định tuyến này đã bật chức năng NAT, nằm bên trong gia đình, có một
cổng giao diện là một phần của mạng gia đình ở bên phải trong hình
4.22. Địa chỉ trong mạng gia đình này giống như những gì đã thấy ở
trên – cả bốn interface trong mạng gia đình này có cùng chung địa chỉ
mạng con là 10.0.0/24. Không gian địa chỉ 10.0.0.0/8 là một trong ba
phần của không gian địa chỉ IP được dành riêng trong [RFC 1918] để
dùng cho mạng riêng hoặc một vùng của các đại chỉ riêng, như là
mạng gia đình trong hình 4.22. Một vùng với các địa chỉ riêng được
nói đến như là một mạng mà các địa chỉ của nó chỉ có ý nghĩa đối với
các thiết bị trong mạng đó. Để biết xem tại sao việc này lại quan trọng
đến vậy, hãy xem xét đến sự thật là có đến hàng trăm ngàn các mạng
gia đình, đều cũng sử dụng chung một không gian địa chỉ 10.0.0.0/24.
Các thiết bị với một mạng gia đình có thể gửi các gói tin cho nhau sử
dụng địa chỉ 10.0.0.0/24. Dù vậy, các gói tin được chuyển tiếp ra
337
ngoài ngoài mạng gia đình đến Internet toàn cầu không thể sử dụng
những địa chỉ này (cho cả địa chỉ nguồn và đích) bởi vì ở ngoài kia
cũng có hàng trăm ngàn các mạng sử dụng khối địa chỉ này. Nhưng
nếu địa chỉ của mạng riêng chỉ có ý nghĩa đối với những gì bên trong
mạng, thì làm thế nào việc định địa chỉ được giải quyết khi mà gói tin
được gửi và nhận từ Internet toàn cầu, nơi mà các địa chỉ cần phải là
độc nhất? Câu trả lời nằm ở việc hiểu được NAT.
Một bộ định tuyến đã bật chế độ NAT không giống như một bộ định
tuyến ở thế giới bên ngoài. Thay vào đó bộ định tuyến bật chế độ
NAT này hoạt động với thế giới bên ngoài như là một thiết bị đơn lẻ
với một địa chỉ IP đơn. Trong hình 4.22, tất cả mọi liên lạc đi từ bộ
định tuyến nhà đến Internet đều của địa chỉ IP nguồn là 138.76.29.7 và
tất cả mọi liên lạc đi vào bộ định tuyến nhà phải có địa chỉ đích là
138.76.29.7. Thực chất là bộ định tuyến đã bật NAT này giấu đi chi
tiết của mạng ở nhà đối với thế giới bên ngoài (có thể thắc mắc là
những máy tính trong mạng nhà lấy được địa chỉ của nó ở đâu và bộ
định tuyến lấy được địa chỉ IP đơn của nó ở đâu. Thông thường thì
câu trả lời là DHCP! Bộ định tuyến lấy địa chỉ từ máy phục vụ DHCP
của ISP, và bộ định tuyến chạy một máy phục vụ DHCP để cung cấp
địa chỉ cho các máy với địa chỉ trong không gian địa chỉ của mạng nhà
được điều khiển bởi bộ định tuyến DHCP đã được bật NAT.)
338
Hình 4.22 – Phân giải địa chỉ mạng

Nếu tất cả các gói dữ liệu đến bộ định tuyến bật chế độ NAT từ WAN
có cùng địa chỉ IP đích (đặc biệt là những interface WAN của bộ định
tuyến bật chế độ NAT), thì làm cách nào bộ định tuyến biết host bên
trong nào nó cần chuyển gói dữ liệu đến? Cách giải quyết là sử dụng
bảng phân giải NAT tại bộ định tuyến bật chế độ NAT, và bao gồm
trong bảng đó bao gồm các số hiệu cổng cũng như địa chỉ IP.
Xem xét ví dụ trong hình 4.22. Giả sử một người dùng trong mạng
nhà với địa chỉ host 10.0.0.1 yêu cầu một trang web trên một máy
phục vụ web nào đó (cổng 80) với địa chỉ 128.119.49.186. Host
10.0.0.1 gán số hiệu cổng nguồn 3345 và gửi gói dữ liệu đến LAN. Bộ
định tuyến NAT nhận được gói dữ liệu này, phát sinh một chỉ số cổng
nguồn mới 5001 cho gói dữ liệu, thay thế địa chỉ IP nguồn với địa chỉ
IP nguồn phía WAN 138.76.29.7 của nó, và thay thế số cổng nguồn
ban đầu 3345 với số cổng nguồn mới 5001. Khi phát sinh ra một số
cổng nguồn mới, bộ định tuyến NAT có thể lựa chọn bất kìa số cổng
nguồn nào mà hiện đang không có bên trong bảng phân giải NAT
(Lưu ý bởi vì trường số cổng dài 16 bit, giao thức NAT có thể hỗ trợ
lên đến 60000 kết nối với một địa chỉ IP đơn phía WAN cho bộ định
tuyến!). NAT trong bộ định tuyến đồng thời cũng thêm vào một dòng
trong bảng phân giải NAT của nó. Máy phục vụ web không biết rằng
gói dữ liệu mới đến với yêu cầu HTTP này đã bị thay đổi bởi bộ định
tuyến NAT, trả lời lại bằng một gói dữ liệu mà có địa chỉ đích là một
địa chỉ IP của bộ định tuyến NAT, và có số cổng đích là 5001. Khi mà
gói dữ liệu này đến được bộ định tuyến NAT, bộ định tuyến sẽ tìm
kiếm trong bảng phân giải NAT sử dụng địa chỉ IP đích và số cổng
đích để nhận được địa chỉ IP phù hợp (10.0.0.1) và số cổng đích
(3345) cho trình duyệt tại mạng nhà. Bộ định tuyến sau đó sẽ thay thế
địa chỉ đích và chỉ số cổng đích của gói dữ liệu và chuyển tiếp gói dữ
liệu này đến mạng nhà.
NAT đã được triển khai rộng rãi trong những năm gần đây nhưng
cũng chịu nhiều chỉ trích bởi cộng đồng IETF. Đầu tiên, họ tranh cãi
rằng, các chỉ số cổng được sử dụng trong xử lý địa chỉ, không phải
cho việc định địa chỉ địa chỉ của host. (Sự xung đột này có thể tạo nên
vấn đề cho máy phục vụ chạy trên mạng gia đình, vì như đã biết trong
339
chương 2, xử lý của máy phục vụ phải đợi những yêu cầu tới nó với số
cổng đã được biết rõ.) Thứ hai là các bộ định tuyến được dùng để xử
lý các gói tin chỉ đến tầng thứ 3. Thứ ba là giao thức NAT xung đột
với khái niệm cuối-đến-cuối, nghĩa là host nên giao tiếp trực tiếp với
nhau, các nút mạng trung gian không chỉnh sửa địa chỉ IP và số hiệu
cổng. Và thứ tư là nên sử dụng IPv6 (xem phần 4.4.4) để giải quyết
vấn đề cạn kiệt địa chỉ IP, hơn là cố gắng sửa chữa nó với một giải
pháp như là NAT. Nhưng có thích hay không thì NAT cũng đã trờ
thành một thành phần quan trọng của Internet.
Một vấn đề lớn nữa của NAT là nó ảnh hưởng đến các ứng dụng P2P
bao gồm các ứng dụng chia sẻ file P2P và các ứng dụng âm thanh P2P
trên nền IP. Nhắc lại trong Chương 2, trong một ứng dụng P2P, bất cứ
bên tham gia (máy ngang hàng) Peer A nào cũng có thể khởi tạo một
kết nối TCP đến bất kỳ một bên tham gia Peer B nào khác. Vấn đề là
nếu Peer B nằm sau NAT thì nó không thể đóng vai trò như một máy
phục vụ và chấp nhận các kết nối TCP. Trong trường hợp này, Peer A
cần liên hệ với Peer B trước thông qua một Peer C trung gian, không
nằm sau một NAT và có một kết nối TCP đến B. Peer A sau đó sẽ yêu
cầu Peer B thông qua Peer C để khởi tạo một kết nối TCP trực tiếp về
Peer A. Khi mà kết nối P2P TCP trực tiếp này được thiết lập giữa Peer
A và B, thì chúng có thể trao đổi thông điệp hoặc file. Các làm này,
gọi là đảo ngược kết nối, thực chất được sử dụng bởi nhiều ứng dụng
P2P cho NAT traversal. Nếu cả Peer A và Peer B đều nằm sau NAT
của nó, thì tình huống sẽ trở nên phức tạp hơn nhưng cũng có thể giải
quyết bằng cách dùng các ứng dụng trung gian, như Skye đã được tìm
hiểu ở Chương 2.
UPnP
NAT traversal được cung cấp ngày càng nhiều bởi Universal
Plug and Play (UPnP), là một giao thức cho phép một host có thể tìm
kiếm và cấu hình một NAT gần đó. UPnP yêu cầu cả host và NAT
phải tương thích với UPnP. Với UPnP, một ứng dụng chạy trên một
host có thể yêu cầu một ánh xạ NAT giữa địa chỉ IP riêng, chỉ số
cổng riêng và địa chỉ IP công cộng, số chỉ cổng công cộng cho một
vài số cổng công cộng được yêu cầu. Nếu NAT đồng ý yêu cầu và tạo
ra một ánh xạ, những nút mạng từ bên ngoài có thể khởi tạo các kết
340
nối TCP đến (địa chỉ IP công cộng, số cổng công cộng). Hơn nữa,
UPnP để cho các ứng dụng biết được các giá trị của (địa chỉ IP công
cộng, chỉ số cổng công cộng), để các ứng dụng có thể quảng cáo ra thế
giới bên ngoài.
Ví dụ giả sử một host nằm bên trong một NAT đã bật UPnP, có địa
chỉ riêng là 10.0.0.1 và đang chạy BitTorrent ở cổng 3345. Giả sử địa
chỉ IP công cộng của NAT là 138.76.29.7. Ứng dụng BitTorrent mong
muốn có thể chấp nhận các kết nối từ các host khác để nó có thể trao
đổi dữ liệu với chúng. Cuối cùng, ứng dụng BitTorrent trong host trên
hỏi NAT để tạo ra một ánh xạ (10.0.0.1, 3345) sang (138.76.29.7,
5001). (Sổ cổng công cộng 5001 được chọn bởi ứng dụng.) Ứng dụng
BitTorrent trong host trên cũng có thể đã quảng cáo đến máy phục vụ
theo dõi (tracker) của nó rằng nó đang chạy tại (138.76.29.7, 5001).
Với cách này, một host bên ngoài chạy BitTorrent có thể liên hệ với
tracker và biết được ứng dụng BitTorrent của host trên đang chạy ở
(138.76.29.7, 5001). Host bên ngoài này gửi một gói tin TCP SYN
đến (138.76.29.7, 5001). Khi NAT nhận được gói tin SYN, nó sẽ thay
đổi địa chỉ IP đích và chỉ số cổng trong gói tin thành (10.0.0.1, 3345)
và chuyển tiếp gói tin thông qua NAT.
Tóm lại, UPnP cho phép các host bên ngoài có thể khởi tạo các phiên
giao tiếp đến các host nằm bên trong NAT, sử dụng TCP hoặc UDP.
NAT từ lâu đã là kẻ thù của các ứng dụng P2P; UPnP cung cấp một
giải pháp hiệu quả và nhanh chóng NAT traversal có thể như là một vị
cứu tinh.
IV.3 Giao thức ICMP
Nhắc lại, lớp mạng của Internet có ba thành phần chính: giao thức IP
đã được thảo luận ở các phần trước, các giao thức định tuyến Internet
(bao gồm RIP, OSPF, và BGP) sẽ được khảo sát ở phần 4.6; và ICMP,
chủ đề chính của phần này.
ICMP [RFC 792] được sử dụng bởi các host và bộ định tuyến để trao
đổi thông tin tầng Mạng với nhau. ICMP được sử dụng chủ yếu để
báo cáo lỗi. Ví dụ, khi sử dụng một phiên Telnet, FTP hay HTTP,
chúng ta có thể gặp phải thông báo lỗi như “Destination network
unreachable”. Thông báo lỗi này có nguồn gốc từ ICMP. Ở một vài
341
trường hợp, một bộ định tuyến chạy giao thức IP không thể tìm thấy
đường dẫn đến host được yêu cầu trong ứng dụng Telnet, FTP, hay
HTTP. Khi đó bộ định tuyến sẽ tạo ra và gửi đi thông điệp dạng ICMP
dạng 3 đến host gửi để thông báo lỗi.
ICMP thường được xem là một phần của IP nhưng về mặt kiến trúc nó
nằm ngay phía trên IP và thông điệp ICMP được chứa trong các gói
dữ liệu IP. Nghĩa là các thông điệp ICMP được mang đi dưới dạng
phần dữ liệu của gói tin IP như là các dữ liệu của TCP hoặc UDP.
Tương tự, khi một host nhận được một gói dữ liệu IP với ICMP như là
một giao thức lớp trên, nó phân tách nội dung của gói dữ liệu thành
ICMP, cũng như cách nó phân tách nội dung gói dữ liệu thành TCP
hay UDP.
Kiểu ICMP Mã Diễn giải
0 0 Echo reply (để ping)

3 0 không đến được mạng đích
3 1 không đến được host đích
3 2 không đến được giao thức
đích
3 3 không đến được cổng đích
3 6 không biết mạng đích
3 7 không biết host đích
4 0 nguồn bị tắt (điều khiển quá
tải)
8 0 yêu cầu lặp lại
9 0 quảng bá bộ định tuyến
10 0 Tìm kiếm bộ định tuyến
11 0 TTL hết hạn
12 0 IP header bị lỗi
Hình 4.23 – Các loại ICMP
342
Các thông điệp ICMP có một kiểu và một trường mã, chứa phần đầu
và 8 byte đầu tiên của gói dữ liệu IP dẫn đến thông điệp ICMP được
tạo ra ngay từ đầu (để cho bên gửi xác định gói dữ liệu nào gây ra lỗi).
Việc chọn lựa kiểu thông điệp ICMP được thể hiện ở hình 4.23. Lưu ý
rằng các thông điệp ICMP được sử dụng không chỉ cho các điểu kiện
thông báo lỗi.
Chương trình ping nổi tiếng gửi một thông điệp ICMP kiểu 8 mã 0
đến một host nào đó. Host ở đích, khi nhận được gói tin yêu cầu (echo
request), gửi lại một gói tin trả lời (echo reply) ICMP kiểu 0 mã 0.
Một thông điệp ICMP thú vị khác là thông điệp ICMP hạn chế nguồn
(ICMP source quench message). Thông điệp này hiếm khi được sử
dụng trong thực tế. Mục tiêu của nó là để điều khiển tắt nghẽn, cho
phép một bộ định tuyến bị tắt nghẽn gửi một thông điệp ICMP cho
một host để ra lệnh cho host đó giảm tốc độ truyền. Chúng ta đã thấy
trong Chương 3 rằng TCP có các kĩ thuật điều khiển tắt nghẽn của nó
mà hoạt động ở tầng Vận chuyển mà không sử dụng các phản hồi của
tầng Mạng như gói tin ICMP.
Trong Chương 1 chúng ta đã giới thiệu chương trình Traceroute cho
phép lần theo vết một đường đi từ một host đến bất kì host nào trên
thế giới. Thật thú vị, Traceroute cũng được triển khai với các thông
điệp ICMP. Để xác định được tên và địa chỉ của các bộ định tuyến
giữa nguồn và đích, Traceroute ở tại nguồn gửi đi một loạt các gói dữ
liệu IP gốc đến đích. Mỗi một gói dữ liệu này chứa một gói dữ liệu
UDP (UDP segment) với một chỉ số cổng UDP. Gói dữ liệu đầu tiên
trong các gói này có TTL là 1, gói tiếp theo là 2, gói tiếp theo nữa là 3
và tiếp tục. Phía nguồn cũng bắt đầu một đồng hồ đếm thời gian
(timer) cho mỗi một gói dữ liệu. Khi gói dữ liệu thứ n đến được bộ
định tuyến thứ n, bộ định tuyến này quan sát được rằng TTL của gói
dữ liệu đã hết hạn. Dựa vào các luật của giao thức IP, bộ định tuyến sẽ
bỏ gói dữ liệu này và gửi một thông điệp cảnh báo ICMP đến nguồn
(kiểu 11 mã 0). Thông điệp cảnh báo này bao gồm cả tên của bộ định
tuyến và địa chỉ IP của nó. Khi thông điệp ICMP này về lại được
nguồn, nguồn sẽ tính toán được thời gian đi một vòng (round-trip
time) dựa vào đồng hồ đếm thời gian cũng như tên và địa chỉ IP của
bộ định tuyến thứ n từ thông điệp ICMP này.
343
Làm cách nào mà một nguồn Traceroute biết được khi nào phải ngừng
gửi các gói dữ liệu UDP. Nhớ rằng nguồn sẽ tăng trường TTL lên 1
cho mỗi gói dữ liệu mà nó gửi. Do đó một trong các gói dữ liệu sẽ tìm
được cách đến được host đích. Bởi vì gói dữ liệu này chứa gói dữ liệu
UDP với một chỉ số cổng, host đích sẽ gửi một thông điệp cổng không
đến được ICMP (dạng 3 mã 3) ngược về cho nguồn. Khi một host
nguồn nhận được một thông điệp ICMP cụ thể, nó sẽ biết được nó
không cần gửi bất cứ gói tin thăm dò nào nữa (Chương trình
Traceroute chuẩn thật sự gửi ba gói tin với cùng TTL; do đó đầu ra
của Traceroute cung cấp ba kết quả cho mỗi TTL.)
Với cách làm này, host ở nguồn biết được số hiệu và định danh của bộ
định tuyến nằm giữa nó và host đích và thời gian đi và về giữa hai
host này. Lưu ý rằng chương trình Traceroute ở máy trạm phải có khả
năng hướng dẫn hệ điều hành sinh ra các UDP gói dữ liệu với giá trị
TTL cụ thể và phải có khả năng nhận được báo cáo từ hệ điều hành
khi một thông điệp ICMP đến.
IV.4 Giao thức IPv6
Vào đầu những năm 90, tổ chức IETF (Internet Engineering Task
Force) bắt đầu nỗ lực phát triển giao thức sau giao thức IPv4. Lí do
chính cho việc này là họ nhận thấy không gian địa chỉ IP 32 bit sẽ sớm
sử dụng hết với những mạng con mới và những nút IP được kết nối
Internet (và được cấp phát địa chỉ IP duy nhất) tăng với một tốc độ
chóng mặt. Để đáp ứng cho nhu cầu có một không gian địa chỉ IP lớn,
một giao thức IP mới, IPv6, được phát triển. Các nhà thiết kế IPv6 lợi
dụng cơ hội này để chỉnh sửa nhiều vấn đề của IPv4, dựa vào kinh
nghiệm vận hành tích lũy lâu nay với IPv4.
Thời điểm mà các địa chỉ IPv4 hoàn toàn được cấp phát hết (và do đó
không còn một mạng con nào có thể nối lên Internet) là một chủ đề
đáng tranh cãi. Dự đoán của hai nhà lãnh đạo của nhóm làm việc
Address Lifetime Expectations của IETF là những địa chỉ sẽ hết sạch
vào những năm 2008 và 2018. Vào năm 1996, American Registry for
Internet Numbers( ARIN) báo cáo rằng tất cả các địa chỉ IPv4 lớp A
đã được cấp phát hết, 62% địa chỉ lớp B và 37% địa chỉ lớp C đã được
cấp phát. Mặc dù những ước lượng và những con số này cho thấy rằng
344
vẫn còn một khoảng thời gian lâu nữa đến khi mà địa chỉ IPv4 hoàn
toàn cạn kiệt, người ta cũng nhận ra cần phải có khoảng thời gian
đáng kể để triển khai một công nghệ mới trên một quy mô lớn, điều
đó đã dẫn tới sự ra đời của IPv6.
Định dạng của gói dữ liệu IPv6
Định dạng của gói dữ liệu IPv6 được chỉ ra trong hình 4.24. Những
thay đổi quan trọng nhất được giới thiệu trong IPv6 được biết trong
định dạng gói dữ liệu:
▪ Khả năng mở rộng địa chỉ. IPv6 tăng kích thước của địa chỉ IP từ
32 bit lên 128 bit. Điều này đảm bảo thế giới không hết địa chỉ IP.
Bây giờ mỗi một hạt cát trên Trái đất cũng có thể có địa chỉ IP
được. Ngoài địa chỉ unicast và multicast, IPv6 giới thiệu một loại
địa chỉ mới, gọi là anycast address, cho phép một gói dữ liệu có
thể được chuyển đến một host bất kỳ nào trong nhóm các host
(Chức năng này có thể được sử dụng, ví dụ, để gửi một HTTP
GET đến một số các site mà chứa tài liệu nào đó)
▪ Một phần đầu 40 byte hợp lý. Như đã thảo luận bên trên, một số
các trường của IPv4 bị bỏ đi hoặc không cần thiết. Kết quả của độ
dài 40 byte cố định của một phần đầu cho phép xử lý một gói dữ
liệu IP nhanh hơn. Một mã hóa các tùy chọn mới cho phép xử lý
các tùy chọn linh hoạt hơn.
32 bits
Version Traffic Class Flow Label
Payload length Next hdr Hop limit
Source address
(128 bits)
Destination address
(128 bits)
Data
Hình 4.24 – Khuôn dạng gói dữ liệu IPv6
345
▪ Đánh nhãn luồng và độ ưu tiên luồng. IPv6 đưa ra một khái niệm
về một luồng (flow). RFC 1752 và RFC 2460 cho biết rằng điều
này cho phép “đánh nhãn các gói tin thuộc các luồng cụ thể cho
những yêu cầu xử lí đặc biệt của nơi gửi, như là chất lượng dịch
vụ không mặc định hay dịch vụ thời gian thật.” Ví dụ việc chuyển
phát âm thanh và hình ảnh được xem như là một luồng. Mặt khác,
những ứng dụng truyền thống hơn, như là trao đổi file hay email,
sẽ có thể không được xem như là những luồng. Có thể những lưu
lượng được mang bởi các người dùng với độ ưu tiên cao hơn (ví
dụ người trả tiền để được cung cấp dịch vụ tốt hơn) được cũng
được xem như là một luồng. Có một điều rõ ràng là các nhà thiết
kế IPv6 đã thấy trước nhu cầu cần phải phân biệt giữa các luồng
ngay cả khi ý nghĩ của một luồng vẫn chưa được thống nhất. Phần
đầu của IPv6 cũng có trường loại lưu lượng 8 bit. Trường này,
giống trường TOS của IPv4, có thể được dùng để tạo ra ưu tiên
cho một số gói dữ liệu nhất định trong một luồng, hoặc có thể
dùng nó để tạo ra ưu tiên cho một số ứng dụng nhất định (ví dụ,
ICMP) hơn những gói dữ liệu hay ứng dụng khác (ví dụ, tin tức
mạng).
Như đã lưu ý ở trên, bảng so sánh giữa hình 4.24 và hình 4.13 cho
thấy một kiến trúc hợp lý và đơn giản hơn của gói dữ liệu Ipv6.
Những trường sau được định nghĩa trong IPv6:
▪ Version. Trường 4 bit này cho biết số của phiên bản IP. Không gì
ngạc nhiên khi IPv6 sẽ mang giá trị 6 trong trường này. Lưu ý
rằng dù cho giá trị trường này là 4 cũng không tạo thành một IPv4
gói dữ liệu có giá trị. (Nếu làm được thì cuộc đời sẽ đơn giản hơn
nhiều – hãy xem những thảo luận về sự chuyển dịch từ IPv4 sang
IPv6.)
▪ Traffic class. Trường 8 bit này tương tự như trường TOS đã gặp ở
IPv4.
▪ Flow label. Như thảo luận ở trên, trường 20 bit này được dùng để
định danh một luồng gói dữ liệu.
▪ Payload length. Trường 16 bit này là một số nguyên không dấu
cho biết số byte mà một gói dữ liệu IPv6 chiếm theo sau 40 byte
phần đầu của nó.
346
▪ Next header. Trường này cho biết giao thức tầng Vận chuyển mà
nội dung của gói dữ liệu này được chuyển đến (ví dụ đến TCP
hay UDP). Trường này sử dụng các giá trị giống với trường giao
thức trong Ipv4
▪ Hop limit. Gía trị của trường này sẽ giảm đi một mỗi lần một bộ
định tuyến chuyển tiếp gói dữ liệu. Nếu giá trị này chạm đến 0,
gói dữ liệu sẽ bị hủy.
▪ Source and destination addresses. Những định dạng khác nhau
của địa chỉ IPv6 128 bit được miêu tả trong RFC 4291.
▪ Data. Đây là phần dữ liệu của gói dữ liệu IPv6. Khi một gói dữ
liệu đến được đích của nó, phần này sẽ được tách ra khỏi gói dữ
liệu IP và chuyển cho giao thức được chỉ định ở trường next
header.
Thảo luận ở trên cho thấy mục đích của những trường trong gói dữ
liệu IPv6. So sánh định dạng gói dữ liệu IPv6 trong hình 4.24 với gói
dữ liệu IPv4 trong hình 4.13, chúng ta thấy rằng một số trường không
còn tồn tại trong IPv6 nữa:
▪ Fragmentation/Reassembly. IPv6 không cho phép việc phân
mảnh và gắn lại tại các bộ định tuyến trung gian; những hoạt
động này có thể được thực hiện chỉ tại nguồn và đích. Nếu một
gói dữ liệu IPv6 nhận được bởi một bộ định tuyến quá lớn để có
thể chuyển tiếp qua liên kết đầu ra, bộ định tuyến chỉ việc đơn
giản là bỏ gói dữ liệu đó và gửi một thông điệp lỗi ICMP (xem
bên dưới) trở về lại cho phía gửi. Phía gửi sẽ gửi lại dữ liệu sử
dụng gói dữ liệu IP nhỏ hơn. Phân mảnh và lắp ghép là một hoạt
động tốn nhiều thời gian; xóa bỏ chức năng này đi khỏi bộ định
tuyến và đặt nó trong hệ cuối sẽ làm tăng đáng kể thời gian
chuyển tiếp IP trong mạng.
▪ Header checksum. Bởi vì các giao thức tầng Vận chuyển (ví dụ
TCP và UDP) và tầng Liên kết dữ liệu (ví dụ Ethernet) trong các
tầng của Internet thực hiện việc kiểm tra checksum, các nhà thiết
kế IP đã thấy chức năng này là dư thừa do đó nó có thể được bỏ
đi. Một lần nữa, yêu cầu xử lý nhanh các gói tin IP là vấn đề cốt
lõi. Nhớ lại thảo luận trước đây về IPv4 trong phần 4.4.1, phần
đầu gói tin IPv4 chứa trường TTL (tương tự trường hop limit của
IPv6), việc kiểm tra checksum trên phần đầu của gói tin IPv4 phải
347
thực hiện mỗi lần tại mỗi bộ định tuyến. Giống như phân mảnh và
lắp ráp, đây cũng là một hoạt động tốn kém của IPv4.
▪ Options. Trường tùy chọn không còn là một phần của phần đầu
gói tin IP chuẩn nữa. Mặc dù vậy nó không bị bỏ đi hoàn toàn.
Thay vào đó trường tùy chọn là một trong những phần đầu tiếp
theo (next header) được trỏ đến từ trong phần đầu của gói tin
IPv6. Nghĩa là chỉ những phần đầu của giao thức TCP hay UDP
có thể là phần đầu tiếp theo trong một gói tin IP, và trường tùy
chọn cũng vậy. Sự tháo bỏ trường tùy chọn này làm cho chiều dài
phần đầu IP có độ dài cố định 40 byte.
Nhắc lại từ thảo luận trước đó ở phần 4.4.3 rằng giao thức ICMP được
sử dụng bởi các nút IP để thông báo tình trạng lỗi và cung cấp một số
thông tin giới hạn (ví dụ, echo reply cho thông điệp ping) đến hệ cuối.
Phiên bản mới của ICMP đã được định nghĩa trong IPv6 RFC 4443.
Ngoài việc sắp xếp lại các định nghĩa loại và mã ICMP đã tồn tại,
ICMPv6 còn thêm những loại và mã mới cần cho các chức năng mới
của IPv6. Chúng bao gồm kiểu “gói tin quá lớn”, và mã lỗi “tùy chọn
IPv6 không thể nhận ra được”. Ngoài ra ICMPv6 còn gộp chức năng
của Internet Group Management Protocol (IGMP) mà chúng ta sẽ
nghiên cứu ở phần 4.7. IGMP được sử dụng để quản lý sự gia nhập
hoặc rời khỏi những nhóm multicast của một host, một giao thức tách
biệt khỏi ICMP trong IPv4.
Chuyển từ IPv4 sang IPv6
Tới thời điểm này, chúng ta đã biết các chi tiết kỹ thuật của Ipv6, hãy
nói đến vấn đề thực tế hơn: Làm cách nào mà mạng Internet công
cộng đang sử dung IPv4 có thể chuyển sang IPv6? Vấn đề ở chỗ trong
khi các hệ thống có khả năng xử lý IPv6 có thể tương thích ngược,
nghĩa là có thể gửi, định tuyến và nhận các IPv4 gói dữ liệu, thì các hệ
thống trên IPv4 đã được triển khai sẵn không có khả năng xử lý các
IPv6 gói dữ liệu. Có một vài giải pháp cho vấn đề này.
Một giải pháp là có thể khai báo một ngày cờ (flag day) – một thời
điểm mà tất cả mọi máy Internet đều được tắt và nâng cấp từ IPv4
sang IPv6. Lần chuyển dịch công nghệ lớn gần nhất (từ NCP sang
TCP cho các dịch vụ vận chuyển đáng tin cậy) xảy ra gần 25 năm về
trước. Ngay cả những ngày đó [RFC 801] khi mà Internet vẫn còn nhỏ
348
và được quản trị bằng một nhóm nhỏ những “pháp sư”, thì việc có
một ngày cờ như vậy là không thể. Nó có thể kéo theo hàng trăm triệu
máy và các nhà quản trị mạng, người sử dụng liên quan đến. RFC
4213 diễn tả hai hướng tiếp cận (có thể sử dụng riêng lẻ hoặc chung)
để tích hợp các host và bộ định tuyến IPv6 bên trong thế giới IPv4
(với mục tiêu lâu dài là tất cả một nút IPv4 đều được chuyển qua
IPv6).
Có thể một trong những cách trực tiếp nhất để đưa vào các nút có khả
năng xử lý IPv6 là cách tiếp cận dual-stack, khi mà những nút IPv6
được cài đặt IPv4 hoàn chỉnh. Những nút như thế được biết đến như
nút IPv6/IPv4 trong RFC 4213, có khả năng gửi và nhận cả IPv4 và
IPv6 gói dữ liệu. Khi xử lý với nút IPv4 thì nút IPv6/IPv4 có thể sử
dụng IPv4 gói dữ liệu, khi xử lý với nút IPv6 thì nút IPv6/IPv4 có thể
sử dụng IPv6 gói dữ liệu. Những nút IPv6/IPv4 phải vừa có địa chỉ
IPv6 lẫn IPv4. Nó còn phải quyết định được xem một nút khác có thể
xử lý IPv6 hay chỉ IPv4 mà thôi. Vấn đề này có thể giải quyết bằng
cách sử dụng DNS (xem chương 2), nó có thể trả về địa chỉ IPv6 nếu
tên của nút được phân giải có thể xử lý IPv6, không thì nó trả về địa
chỉ IPv4. Dĩ nhiên nếu nút đưa ra yêu cầu DNS chỉ có thể xử lý IPv4,
thì DNS chỉ trả về địa chỉ IPv4 mà thôi.
Trong cách tiếp cận dual-stack, nếu bên gửi hay bên nhận chỉ có khả
năng xử lý IPv4, một gói dữ liệu IPv4 phải được sử dụng. Kết quả là
không thể có chuyện hai nút có khả năng xử lý IPv6 lại gửi những
IPv4 gói dữ liệu cho nhau. Điều này được thể hiện ở hình 4.25. Giả sử
Nút A có khả năng xử lý IPv6 và muốn gửi gói dữ liệu IP cho Nút F,
cũng có khả năng xử lý IPv6. Nút A và B có thể trao đổi IPv6 gói dữ
liệu. Nhưng Nút B phải tạo IPv4 gói dữ liệu để gửi cho C. Chắc chắn
rằng trường dữ liệu của IPv6 gói dữ liệu có thể được sao chép vào
trường dữ liệu của IPv4 gói dữ liệu và ánh xạ địa chỉ thích có thể được
thực hiện. Mặc dù vậy, để thực hiện việc chuyển đổi từ IPv6 sang
IPv4, những trường cụ thể chỉ có trong IPv6 gói dữ liệu (ví dụ trường
định danh flow) không có tương ứng bên IPv4. Thông tin trong những
trường này sẽ bị mất. Do đó, ngay cả khi E và F có thể trao đổi IPv6
gói dữ liệu với nhau, IPv4 gói dữ liệu đến được E từ D vẫn không
chứa toàn bộ các trường trong gói dữ liệu IPv6 ban đầu gửi từ A.
349
Một hướng tiếp cận khác, cũng được thảo luận trong RDC 4213, là
thiết lập đường ống (tunneling). Thiết lập đường ống có thể giải
quyết vấn đề được vấn đề ở trên khi cho phép, ví dụ, E nhận gói dữ
liệu IPv6 có nguồn gốc từ A. Ý tưởng cơ bản của thiết lập đường ống
như sau. Giả sử hai nút IPv6 (ví dụ B và E trong hình 4.25) muốn hoạt
động với nhau sử dụng gói dữ liệu IPv6 nhưng lại kết nối với nhau
thông qua bộ định tuyến IPv4. Chúng ta gọi tập hợp các bộ định tuyến
IPv4 nằm giữa hai bộ định tuyến IPv6 là một đường ống (tunnel), như
minh họa ở hình 4.26. Với cách làm như vậy, một nút IPv6 ở phía gửi
của một đường ống (ví dụ B), lấy toàn bộ IPv6 gói dữ liệu và đặt nó
bên trong trường dữ liệu của IPv4 gói dữ liệu. Gói dữ liệu này sau đó
được dẫn địa chỉ đến nút IPv6 ở phía nhận của đường ống (ví dụ E) và
gửi đến nút đầu tiên trong đường ống (ví dụ C). Các bộ định tuyến
IPv4 nằm giữa trong đường ống định tuyến IPv4 gói dữ liệu này giữa
chúng với nhau, cũng như bất kỳ gói dữ liệu nào khác, may mắn là
chúng không biết là gói dữ liệu này chứa bên trong đó toàn bộ gói dữ
liệu IPv6. Nút IPv6 ở phía nhận của đường ống sẽ nhận được gói dữ
liệu IPv4, và xác định được rằng gói dữ liệu IPv4 này chứa một gói dữ
liệu IPv6 bên trong nó, sau đó gói dữ liệu IPv6 này được bóc ra, và
định tuyến gói dữ liệu IPv6 này đi như thể nó nhận được gói dữ liệu
này ở một nút IPv6 lân cận kết nối trực tiếp đến nó.
Hình 4.25 – Cách tiếp cận dual-stack
350
Hình 4.26 – Thiết lập đường ống

Chúng ta kết thúc phần này bằng lưu ý rằng khi việc sử dụng IPv6 bắt
đầu chậm nhưng tốc độ này ngày càng gia tăng. Tổ chức Office of
Management and Budget (OBM) đã chuyển toàn bộ bộ định tuyến chủ
yếu trong mạng của chính phủ Mỹ để có thể xử lý IPv6 vào giữa năm
2008. Sự phát triển mạnh mẽ của các thiết bị như điện thoại IP hay các
thiết bị khác thúc đẩy cho sự triển khai IPv6. Chương trình Third
Generation Partnership của Châu Âu đã chỉ định IPv6 là khuôn mẫu
địa chỉ chuẩn cho di động đa phương tiện. Ngay cả khi IPv6 chưa
được triển khai rộng rãi trong mười năm đầu tiên trong tuổi đời non
trẻ của nó, một viễn cảnh tốt hơn được vẽ ra. Ngày nay hệ thống số
điện thoại cần vài thập niên để đạt được địa vị của nó, nhưng đã ở vị
trí đó gần nửa thế kỷ và không có dấu hiệu gì suy tàn. Tương tự, có lẽ
phải mất thời gian để IPv6 triển khai đầy đủ, nhưng nó sẽ ở vị trí đó
trong một thời gian rất dài sau đó. Brian Carpenter, cựu chủ tịch của
Internet Architecture Board và là tác giả của một vài RFC liên quan
đến IPv6 cho hay “Tôi luôn nhìn thấy điều này là một quá trình 15
351
năm kể từ năm 1995”. Vào ngày mà Carpenter nói điều này, chúng ta
đã tiến gần đến ¾ thời gian đó.
Một bài học quan trọng mà chúng ta học được từ kinh nghiệm IPv6 là
rất khó để thay đổi các giao thức tầng Mạng mạng. Kể từ những năm
đầu 1990, hàng loạt các giao thức mới của tầng Mạng được đồn thổi
như là một cuộc cách mạng mới của Internet, nhưng hầu hết các giao
thức này đều có những giới hạn để sử dụng ngày nay. Các giao thức
này bao gồm cả IPv6, giao thức multicast (xem phần 4.7) và các giao
thức dành riêng tài nguyên. Thật sự, việc giới thiệu những giao thức
mới tầng Mạng như là thay nền móng của một căn nhà, rất khó thực
hiện nếu không muốn nói là phải tháo rời cả căn nhà ra hoặc ít nhất là
phải di dời cư dân trong nhà. Mặt khác, Internet đã chứng kiến sự triển
khai nhanh chóng của những giao thức mới ở lớp ứng dụng. Một ví dụ
cổ điển là Web, tin nhắn tức thời và chia sẻ file P2P. Những ví dụ
khác bao gồm âm thanh và video streaming và game phân tán. Giới
thiệu các giao thức mới ở tầng Ứng dụng giống như thêm vào những
lớp sơn mới cho ngôi nhà – một việc khá dễ làm, nếu bạn chọn màu
sắc bắt mắt thì hàng xóm sẽ bắt chước bạn. Tóm lại, trong tương lai
chúng ta mong chờ sẽ thấy những thay đổi trong tầng Mạng của
Internet, nhưng những thay đổi này sẽ xảy ra chậm hơn rất nhiều so
với những thay đổi trong tầng Ứng dụng.
IV.5 Giới thiệu sơ lược về bảo mật IP
Phần 4.4.3 đã trình bày chi tiết về IPv4, bao gồm những dịch vụ mà nó
cung cấp và cách cài đặt những dịch vụ này. Trong khi đọc qua phần
đó, chúng ta có thể thấy là không có bất kì đề cập đến dịch vụ bảo mật
nào. Thật ra IPv4 được thiết kế vào những năm 1970 khi mà Internet
được sử dụng chủ yếu giữa các nhà nghiên cứu mạng tin tưởng và có
quen biết nhau. Lúc bấy giờ, tạo ra một mạng máy tính kết nối nhiều
công nghệ lớp liên kết đã là một thử thách, chứ chưa nói đến vấn đề
bảo mật.
Nhưng bảo mật đã trở thành một mối quan tâm lớn ngày nay, các nhà
nghiên cứu Internet đã tìm cách thiết kết các giao thức tầng Mạng mới
mà có thể cung cấp các loại dịch vụ bảo mật khác nhau. Một trong
những giao thức này là IPSec, giao thức bảo mật tầng Mạng phổ biến
352
nhất và được triển khai rộng rãi trong các mạng riêng ảo (Virtual
Private Networks-VPN).
IPSec được thiết kế để tương thích ngược với IPv4 và IPv6. Cụ thể, để
có thể biết được những lợi ích mà IPSec đem lại, chúng ta không cần
phải thay đổi chồng giao thức trong tất cả các bộ định tuyến và host
trên Internet. Ví dụ, sử dung chế độ vận chuyển (transport mode - một
trong hai chế độ của IPSec), nếu hai host muốn giao tiếp một cách bảo
mật, IPSec chỉ cần phải có ở hai host này. Tất cả các bộ định tuyến và
host khác có thể tiếp tục sử dụng IPv4.
Cụ thể hơn, chúng ta tập trung vào chế độ vận chuyển của IPsec.
Trong chế độ này, hai host đầu tiên phải thiết lập ra một phiên IPSec
giữa chúng (do đó IPSec là hướng kết nối). Với phiên này, tất cả mọi
gói dữ liệu TCP và UDP được gửi giữa hai host sẽ được cung cấp các
dịch vụ bảo mật của IPSec. Ở phía gửi, tầng Vận chuyển chuyển một
gói dữ liệu đến IPSec. IPSec sau đó sẽ mã hóa gói dữ liệu này, thêm
vào các trường bảo mật cho gói dữ liệu và đóng gói kết quả vào một
gói dữ liệu IP thông thường. Host gửi sẽ gửi những gói dữ liệu này lên
Internet, và vận chuyển nó đến host đích. Ở đó IPSec sẽ giải mã
những gói dữ liệu này và chuyển những gói dữ liệu không bị mã hóa
thu được đến tầng Vận chuyển.
Các dịch vụ cung cấp bởi một phiên IPSec bao gồm:
▪ Thống nhất các tham số bảo mật. Cơ chế cho phép hai host liên
hệ với nhau có thể thống nhất các khóa và thuật toán mã hóa.
▪ Mã hóa dữ liệu gói dữ liệu IP. Khi host gửi nhận được một gói dữ
liệu từ lớp vận chuyển, IPSec sẽ mã hóa dữ liệu. Dữ liệu chỉ có
thể được giải mã bởi IPSec tại host nhận.
▪ Toàn vẹn dữ liệu. IPSec cho phép host nhận kiểm tra được những
trường của phần đầu của gói dữ liệu và dữ liệu mã hóa có bị thay
đổi hay không khi gói dữ liệu được định tuyến từ nguồn đến đích.
▪ Chứng thực nguồn. Khi một host nhận được một gói dữ liệu
IPSec từ một nguồn tin cậy, host đó đảm bảo rằng địa chỉ IP
nguồn trong gói dữ liệu chính là địa chỉ thật sự của gói dữ liệu.
Khi hai host thiết lập được một phiên IPSec giữa chúng, tất cả mọi gói
dữ liệu TCP và UDP gửi giữa chúng đều được mã hóa và chứng thực.
353
Vì vậy, IPSec cung cấp một lớp bên ngoài, bảo mật tất cả các giao tiếp
giữa hai host cho tất cả các ứng dụng mạng bên trong.
Một công ty có thể sử dụng IPSec để giao tiếp một cách bảo mật trên
mạng Internet công cộng không bảo mật. Ví dụ, một công ty có nhiều
những người bán hàng phải thường xuyên di chuyển, mỗi người có
một máy tính xách tay của công ty. Giả sử những người này thường
cần phải lấy những thông tin nhạy cảm của công ty (ví dụ, giá và
thông tin hàng) được lưu tại máy phục vụ của trụ sở công ty. Nhiều
người còn cho rằng các người này có gửi những tài liệu nhạy cảm cho
nhau. Vậy thì điều này được thực hiện như thế nào với IPsec? Có thể
tưởng tượng là chúng ta cài đặt IPsec tại máy phục vụ và tất cả các
laptop của các nhân viên bán hàng. Với IPsec ở các host này, bất cứ
khi nào một nhân viên giao tiếp với máy phục vụ hoặc với nhân viên
khác thì phiên trao đổi này sẽ được bảo mật.
V. Các thuật toán định tuyến

Tới thời điểm này, chúng ta chủ yếu nghiên cứu về chức năng chuyển
tiếp của tầng Mạng. Chúng ta đã biết được rằng khi một gói dữ liệu
đến bộ định tuyến, bộ định tuyến sẽ tìm kiếm trong bảng chuyển tiếp
và xác định giao diện liên kết (link interface) mà gói tin sẽ được
chuyển qua. Chúng ta cũng đã được tìm hiểu các thuật toán định tuyến
hoạt động tại các bộ định tuyến mạng, trao đổi và tính toán các thông
tin được sử dụng để cấu hình các bảng chuyển tiếp này. Sự tác động
lẫn nhau giữa những thuật toán định tuyến và các bảng chuyển tiếp đã
được chỉ ra ở phần 4.2. Bây giờ, chúng ta sẽ chuyển sang chú ý đến
chủ đề chính khác trong chương này, cụ thể là, chức năng định tuyến
quan trọng của tầng Mạng. Cho dù tầng Mạng cung cấp dịch vụ dữ
liệu (trong trường hợp các gói dữ liệu khác nhau giữa một cặp nguồn-
đích nhất định có thể sử dụng các tuyến khác nhau) hay một dịch vụ
mạch ảo (trong trường hợp tất cả gói dữ liệu giữa một điểm nguồn –
đích nhất định sẽ đi theo con đường nhất định), tầng Mạng phải xác
con đường mà gói tin phải đi từ nơi gửi (sender) đến nơi nhận
(receiver). Chúng ta sẽ thấy rằng công việc định tuyến là xác định
đường đi tốt từ nơi gửi đến nơi nhận thông qua mạng lưới các bộ định
tuyến.
354
Thường thì một host được gắn trực tiếp vào một bộ định tuyến, bộ
định tuyến mặc định (default router) cho host (còn được gọi là bộ định
tuyến đầu tiên mà host sẽ đi qua). Bất cứ khi nào một host gửi một gói
dữ liệu, gói dữ liệu được chuyển cho bộ định tuyến mặc định của nó.
Chúng ta xem bộ định tuyến mặc định của host nguồn như là bộ định
tuyến nguồn và bộ định tuyến mặc định của host đích như bộ định
tuyến đích. Vấn đề của việc định tuyến một gói dữ liệu từ host nguồn
đến host đích rõ ràng là vấn đề định tuyến gói dữ liệu từ bộ định tuyến
nguồn đến bộ định tuyến đích, đó là trọng tâm của phần này.
Mục đích của thuật toán định tuyến chỉ đơn giản là: với một tập các bộ
định tuyến biết trước và các liên kết kết nối các bộ định tuyến, một
thuật toán định tuyến tìm đường đi “tốt” từ bộ định tuyến nguồn đến
bộ định tuyến đích. Thường thì đường đi tốt là đường có chi phí nhỏ
nhất. Tuy nhiên, chúng ta sẽ thấy rằng trong thực tế, những mối quan
tâm trong thế giới thực như các vấn đề về chính sách( ví dụ, một quy
tắc như “ bộ định tuyến x, thuộc cơ quan Y, không nên chuyển tiếp bất
cứ gói dữ liệu nào từ mạng thuộc sở hữu của cơ quan Z”) cũng làm
phức tạp các thuật toán vốn đơn giản về mặt khái niệm, các thuật toán
mà lí thuyết của nó được áp dụng cho định tuyến trên mạng ngày nay.
Một đồ thị được sử dụng để công thức hóa các vấn đề định tuyến.
Nhắc lại một đồ thị G = (N, E) là một tập N nút và một tập E cạnh,
mỗi cạnh là một cặp nút trong tập N. Trong ngữ cảnh của định tuyến
tầng Mạng, các nút trong đồ thị đại diện cho bộ định tuyến – điểm mà
tại đó các quyết định chuyển tiếp các gói dữ liệu được thực hiện và
cạnh nối các điểm sẽ đại diện cho các liên kết vật lý giữa các bộ định
tuyến. Một đồ thị biểu thị cho một mạng máy tính được thể hiện trong
hình 4.27.
Như đã trình bày ở Hình 4.27, một cạnh cũng có giá trị đại diện cho
chi phí của nó. Điển hình, chi phí của một cạnh cho biết khoảng cách
vật lý của liên kết tương ứng (ví dụ một đường vượt đại dương sẽ có
chi phí cao hơn là một đường ngắn trên mặt đất), tốc độ đường truyền
đường truyền đó. Đối với mục đích của chúng ta, chúng ta có thể dễ
dàng lấy chi phí của một cạnh cho trước và không lo lắng về cách xác
định chúng như thế nào. Cho cạnh bấy kì (x,y) trong E, cho rằng
c(x,y) là độ dài cạnh giữa 2 điểm x và y. Nếu cặp (x,y) không thuộc E,
355
ta đặt (x,y)=∞. Chúng ta cũng chỉ xem xét các đồ thị vô hướng (đồ thị
mà cạnh của nó không có hướng nào), vì vậy cạnh (x,y) giống cạnh
(y,x) và c(x,y)=c(y,x). Điểm y được gọi là láng giếng của điểm x nếu
(x,y) thuộc E.
Hình 4.27 - Mô hình đồ thị của một mạng máy tính

Giả sử các chi phí được gán cho các cạnh trên đồ thị, mục tiêu của
thuật toán định tuyến là xác định được đường đi có chi phí ngắn nhất
giữa các nguồn và các đích. Để làm vấn đề thêm chuẩn xác, nhắc lại
một đường đi trong đồ thị G=(N,E) là thứ tự các điểm (x1,x2,..,xp)
mà mỗi cặp (x1,x2),(x2,x3)…(xp-1,xp) là các cạnh trong E. Chi phí
của của đường đi (x1,x2,…,xp) là tổng chi phí nhỏ nhất của độ dài các
hướng đi theo các cạnh, đó là c(x1,x2)+c(x2,x3)+…+c(xp-1,xp). Cho
hai nút x, y bất kì, có rất nhiều đường đi giữa hai nút và mỗi đường đi
có một chi phí. Một hay nhiều trong các đường này sẽ là đường có chi
phí nhỏ nhất. Vấn đề đường đi có chi phí ngắn nhất vì vậy đã rõ ràng:
Tìm đường đi giữa nguồn và đích mà có chi phí là nhỏ nhất. Ví dụ
Hình 4.27, đường đi có chi phí ngắn nhất giữa nút nguồn u và nút đích
w là (u,x,y,w) với chi phí đường đi là 3. Lưu ý rằng nếu tất cả các
cạnh đồ thị có cùng chi phí, đường có chi phí thấp nhất cũng là đường
ngắn nhất (đó là, đường với số lượng đường liên kết nhỏ nhất giữa
nguồn và đích). Như một bài tập đơn giản, thử tìm đường có chi phí
nhỏ nhất từ nút u tới nút z trên Hình 4.27 và trình bày cách làm thế
356
nào để tính ra con đường đó. Nếu giống như hầu hết mọi người, chúng
ta tìm được con đường từ u tới z bằng việc nhìn vào hình 4.27, tìm
một đường từ u tới z và đôi khi thuyết phục chính chúng ta rằng
đường được chọn là đường ngắn nhất trong số các khả năng có thể.
Kiểu tính toán như vậy là một ví dụ của giải thuật định tuyến tập
trung- giải thuật định tuyến được chạy ở một vị trí với thông tin đầy
đủ về hệ thống mạng. Nói một cách rộng hơn, một cách mà chúng ta
có thể phân loại các giao thức định tuyến là xem thử, nó là toàn cục
hay phân tán.
▪ Một giao thức định tuyến toàn cục tính toán con đường với chi
phí ngắn nhất giữa một nguồn và một đích sử dụng sự hiểu biết
đầy đủ về hệ thống mạng. Đó là, giải thuật nhận các kết nối giữa
các tất cả các nút và tất cả các chi phí đường liên kết trên mạng
như các tham số đầu vào. Điều này có thể yêu cầu các giao thức
định tuyến đôi khi phải lấy các thông tin này trước khi thực hiện
việc tính toán. Việc tính toán có thể được chạy tại một nơi (giải
thuật định tuyến toàn cục tập trung) hay được nhân bản ở nhiều
nơi. Tuy nhiên, đặc tính riêng biệt chính ở đây là một giải thuật
toàn cục có toàn bộ thông tin kết nối và các chi phí các liên kết.
Trên thực tế, giải thuật với thông tin trạng thái toàn cục được đề
cập như các giao thức định tuyến trạng thái đường liên kết, bởi vì
giải thuật phải biết được chi phí của mỗi đường liên kết trong
mạng. Chúng ta sẽ nghiên cứu các giải thuật trạng thái đường liên
kết trong phần 4.5.1.
▪ Trong một giải thuật định tuyến phân toán, việc tính toán
đường đi với chi phí nhỏ nhất được thực hiện một cách lặp đi lặp
lại và phân tán. Không có một nút nào có toàn bộ thông tin về các
chi phí của các đường liên kết trong mạng. Thay vào đó, mỗi nút
bắt đầu với các chi phí của các đường liên kết mà nó gắn trực
tiếp. Sau đó, thông qua các qui trình lặp đi lặp lại của việc tính
toán và chuyển đổi thông tin với các nút láng giềng, một nút dần
dần tính toán ra đường con đường có chi phí ngắn nhất tới một
đích hay một tập các đích. Giải thuật định tuyến phân cấp mà
chúng ta sẽ nghiên cứu trong phần 4.52 được gọi là giải thuật
vector khoảng cách (distance vector), bởi vì mỗi nút duy trì một
357
vector ước lượng chi phí (khoảng cách) tới tất cả các nút trong
mạng.
Một cách thứ hai để phân loại các giao thức định tuyến là xem thử nó
động hay tĩnh. Trong các giao thức định tuyến tĩnh, các đường đi thay
đổi rất chậm, thường là kết quả của sự can thiệp từ con người (ví dụ,
con người cấu hình bằng tay bảng chuyển tiếp). Các giải thuật định
tuyến động thay đổi các con đường định tuyến mỗi khi các lưu lượng
mạng hay cấu trúc mạng thay đổi. Một giải thuật định tuyến động có
thể chạy định kì hoặc khi có sự thay đổi về cấu trúc hay chi phí đường
liên kết của mạng. Trong khi các giao thức định tuyến động phản ứng
với các thay đổi trên mạng tốt hơn, chúng cũng gặp một số vấn đề như
vòng lặp định tuyến và sự dao động ở các đường.
Cách thứ ba để phân loại các giao thức định tuyến là xem thử các giao
thức này có nhạy với tải (load-sensitive) hay không nhạy với tải
(load-insensitive). Trong giải thuật nhạy với tải, các chi phí liên kết
thay đổi tự động tương ứng với các mức nghẽn mạng hiện tại ở các
liên kết. Nếu một liên kết mà hiện tại bị nghẽn, giải thuật định tuyến
sẽ có khuynh hướng chọn các con đường khác con đường nghẽn đó.
Trong khi các giải thuật định tuyến mạng APARNET ban đầu là nhạy
với tải (load-sensitive), có một số khó khăn gặp phải khi triển khai các
giải thuật này. Các giải thuật định tuyến Internet ngày nay (như RIP,
OSPF và BGP) là không nhạy với tải (load-insensitive), khi chi phí
của đường liên kết không liên quan tới mức nghẽn mạng hiện tại.
V.1 Các thuật toán trạng thái đường liên kết
Nhắc lại trong một giao thức định tuyến trạng thái đường liên kết
(Link state – LS), cấu trúc mạng và chi phí các đường liên kết được
biết và là tham số đầu vào cho các giải thuật LS. Trong thực tế, điều
này được thực hiện bằng cách mỗi nút quảng bá các gói tin trạng thái
đường liên kết cho các nút khác trong mạng, với mỗi gói tin trạng thái
liên kết chứa các định danh và các chi phí của các liên kết nó gắn trực
tiếp. Trong thực tế (ví dụ, với giao thức định tuyến OSPF của Internet,
được thảo luận trong phần 4.6.1) điều này được thực hiện bằng giải
thuật quảng bá trạng thái đường liên kết. Chúng ta sẽ tìm hiểu các giải
thuật quảng bá trong phần 4.7. Kết quả của việc quảng bá của các nút
358
mạng là tất cả các nút có một cái nhìn giống nhau và hoàn chỉnh về
cấu trúc mạng. Mỗi nút sau đó có thể chạy giải thuật LS và tính toán
các đường đi ngắn nhất giống như ở các nút khác.
Giao thức định tuyến trạng thái liên kết mà chúng ta trình bày dưới
đây được biết như là thuật toán Dijkstra; tên của người phát minh ra
nó. Giải thuật Dijkstra tính toán con đường ngắn nhất từ một nút
nguồn (chúng ta sẽ đề cập như là u) đến tất cả các nút khác trong
mạng. Giải thuật Dijkstra là giải thuật lặp đi lặp lại và có thuộc tính là
sau khi giải thuật lặp lại lần thứ k, các đường đi chi phí ngắn nhất đến
k nút được biết đến, và trong số các đường có chi phí nhỏ nhất tới tất
cả nút đích, k đường này sẽ có k chi phí nhỏ nhất. Chúng ta có một số
định nghĩa sau:
▪ D(v): chi phí của đường có chi phí nhỏ nhất từ nút nguồn tới đích
v sau quá trình lặp lại của giải thuật này.
▪ p(v): nút trước (láng giềng của v) trên con đường ngắn nhất hiện
tại từ nguồn v.
▪ N’: một phần các nút; v trong N’ nếu đường ngắn nhất từ nguồn
tới v đã được biết.
Giải thuật định tuyến toàn cục bao gồm một bước khởi tạo ban đầu,
sau đó là một vòng lặp. Số lần của vòng lặp được thực thi bằng với số
lượng nút trong mạng. Khi kết thúc, thuật toán sẽ tính toán được con
đường ngắn nhất từ nút nguồn u tới mỗi nút trên mạng.
Giải thuật LS cho nút nguồn u
1 Khởi tạo
2 N’ = { u }
3 Với nút v bất kì
4 Nếu v là láng giềng của u
5 Thì D(v) = c(u,v)
6 Ngược lại D(v) = ∞
7
8 Lặp cho đến khi N’=N
9 Tìm w không trong N’ mà D(w) có giá trị nhỏ nhất đến nút
359
10 trong N’
11 Cập nhật D(v) cho mỗi láng giềng v của w mà không nằm trong N’:
12 D(v) = ( D(v), D(w) + c(w,v))
Ví dụ, hãy xem mạng trong hình 4.27 và tính toán con đường ngắn
nhất từ u tới tất cả các đích có khả năng. Bảng tóm tắt của việc tính
toán giải thuật định tuyến được chỉ ra ở Bảng 4.3, nơi mỗi dòng trong
bảng cho biết giá trị của các biến của giải thuật định tuyến tại mỗi thời
điểm kết thúc của việc lặp. Hãy xem chi tiết vài bước đầu tiên:
▪ Trong bước khởi tạo, các chi phí đường đi ngắn nhất được biết
hiện tại từ u tới các láng giềng kết nối trực tiếp với nó v, x và w
được khởi tạo là 2, 1 và 5. Chú ý chi phí tới w được thiết lập là 5
(mặc dù chúng ta sẽ sớm thấy rằng có đường có chi phí ngắn hơn)
vì đây là chi phí của liên kết kết nối trực tiếp từ u tới w. Các chi
phí đến y và z được thiết lập là ∞ bởi vì chúng không kết nối trực
tiếp tới u.
Bảng 4.3 – Chạy giao thức LS trên mạng hình 4.27
▪ Ở vòng lặp đầu tiên, chúng ta nhìn trong số những nút này chưa
có nút nào được thêm vào tập N’ và thấy rằng nút với chi phí nhỏ
nhất là kết quả của vòng lặp trước khi nó kết thúc. Đó là nút x,
với chi phí là 1, và vì vậy x được thêm vào N’. Dòng 12 của giải
thuật LS sau đó được thực hiện để cập nhật D(v) cho tất cả các
nút v, kết quả được ra ở dòng 2 (bước 1) trong bảng 4.3. Chi phí
của con đường tới v thì không đổi. Chi phí của con đường tới w
(chi phí này bằng 5 khi kết thúc quá trình khởi tạo) thông qua nút
x được tìm thấy có chi phí là 4. Vì vậy, con đường có chi phí nhỏ
hơn này được lựa chọn và nút đứng trước w trong con đường
360
ngắn nhất từ u được thiết lập là x. Tương tự như vậy, chi phí đến
y (thông qua x ) được tính là 2 và bảng được cập nhật lần nữa.
▪ Ở vòng lặp thứ 2, nút v và y được tìm thấy có đường đi có chi phí
nhỏ nhất (2), chúng ta kết thúc vòng lặp và đưa y vào tập N’, N’
bây giờ chứa u, x và y. Chi phí cho các nút còn lại chưa có trong
N’, đó là nút v, w và z được cập nhật qua dòng 12 của giao thức
LS, kết quả của chúng được chỉ ra ở dòng 3 trong bảng 4.3
▪ …..và tiếp tục.
Khi thuật toán LS kết thúc, chúng ta biết được nút trước nó của mỗi
nút trên con đường đi ngắn nhất từ nút nguồn Với mỗi nút trước, ta lại
có nút trước của nó, vì vậy chúng ta có thể xây dựng một đường đi
hoàn chỉnh từ nguồn cho tới mọi đích. Các bảng chuyển tiếp trong
một nút, ví dụ là u, có thể được xây dựng từ những thông tin này, ví
dụ lưu trữ đối với mỗi đích đến, nút kế tiếp trên đường đi có chi phí
ngắn nhất từ u tới đích. Hình 4.28 chỉ kết quả các đường đi ngắn nhất
và bảng chuyển tiếp ở nút u cho mạng ở Hình 4.27
Hình 4.28 –Đường có chi phí nhỏ nhất và bảng chuyến tiếp tại u
Độ phức tạp tính toán của thuật toán này là gì? Đó là cho n nút(không
tính nút nguồn), bao nhiêu phép tính toán có thể hoàn thành trong
trường hợp xấu nhất để tìm đường đi ngắn nhất từ nguồn tới đích. Lần
lặp lại thứ nhất, chúng ta cần tìm kiếm thông qua n nút để xác định
được nút, w, không ở trong N mà có chi phí nhỏ nhất. Lần lặp thứ 2,
chúng ta cần kiểm tra n-1 nút để xác định chi phí nhỏ nhất. Lần lặp
361
thứ 3 là n-2 nút và cứ thể tiếp tục. Nói chung, tổng số các nút cần tìm
kiếm thông qua các lần lặp là n(n+1)/2, và vì vậy chúng ta nói độ phức
tạp của thuật toán với n nút là O(n2). ( một cài đặt khác phức tạp hơn
của giải thuật này, sử dụng cấu trúc dữ liệu heap có thể tìm thấy giá
trị nhỏ nhất ở dòng 9 trong thời gian logarit hơn là thời gian tuần tự, vì
vậy giảm độ phức tạp của thuật toán)
Trước khi hoàn thành sự thảo luận về thuật toán LS, chúng ta hãy xem
xét về các vấn đề có thể nảy sinh. Hình 4.29 cho biết một cấu trúc
mạng đơn giản nơi có chi phí các đường liên kết bằng với tải trên mỗi
liên kết. Trong ví dụ này, các chi phí liên kết có thể không cân đối: đó
là c(u,v) bằng c(v,u) chỉ khi tải thực trên cả 2 hướng của liên kết (u,v)
là như nhau. Trong ví dụ này, nút z bắt đầu một đơn vị của lưu lượng
có đích đến w, nút x cũng bắt đầu một đơn vị của lưu lượng có đích
đến w, và nút y cũng bắt đầu một lưu lượng mạng bằng e có đích đến
là w. Định tuyến ban đầu được chỉ ra ở Hình 4.29(a) với chi phí liên
kết tương ứng với một lượng lưu lượng được mang.
Khi thuật toán LS chạy tới bước kế tiếp, nút y xác định (dựa vào chi
phí liên kết đã được chỉ trong hình 4.29(a)) đường đi theo chiều kim
đồng hồ tới w có chi phí là 1, trong khi đường đi theo chiều ngược
kim đồng hồ tới w (đã được sử dụng) có chi phí là 1+e. Vì vậy, đường
đi ngắn nhất của y tới w là đường cùng chiều kim đồng đồ. Một cách
tương tự, nút x xác định đường đi ngắn nhất mới tới w cũng là đường
cùng chiều kim đồng hồ, kết quả được chỉ ra ở Hình 4.29(b). Khi thuật
toán LS chạy tới bước kế tiếp, nút x,y và z đều phát hiện đường đi có
chi phí là 0 tới w theo hướng chiều ngược kim đồng hồ, và tất cả đều
đều hướng tất cả lưu lượng của nó theo các đường ngược chiều kim
đồng hồ. Lần kế tiếp thuật toán LS được chạy và x,y,z tất cả sau đó
hướng lưu lượng của nó hướng kim đồng hồ.
Chúng ta có thể làm gì để ngăn ngừa sự dao động đó, sự dao động có
thể xảy ra ở bất kì thuật toán nào, không chỉ ở thuật toán LS. Một giải
pháp có thể được sử dụng đó là các chi phí liên kết không phụ thuộc
vào lượng lưu lượng mạng -một giải pháp không thể chấp nhận được
khi một mục tiêu của định tuyến là tránh sự tắt nghẽn cao độ ở các
liên kết. Một giải pháp khác là đảm bảo tất cả các bộ định tuyến không
cùng chạy thuật toán LS trong cùng một thời điểm. Đây có vẻ là một
362
giải pháp có lý hơn, bởi vì chúng ta có thể hi vọng là thậm chí nếu
định tuyến thuật toán LS hoạt động trong cùng 1 chu kì, các thể hiện
thực thi của thuật toán có thể không giống nhau ở mỗi nút. Tuy nhiên,
những nhà nghiên cứu đã thấy được rằng định tuyến trong Internet có
thể tự đồng bộ hóa lẫn nhau. Mặc dù các bộ định tuyến bắt đầu thực
thi với cùng chu kì nhưng với các khoảng thời gian khác nhau, thể
hiện thực thi của giải thuật dần dần đồng bộ tại các bộ định tuyến. Một
cách để tránh sự tự đồng bộ hóa như thế là cho mỗi bộ định tuyến
ngẫu nhiên thời gian nó gửi ra các thông tin quảng bá đường liên kết.
Hình 4.29 – Dao động trong định tuyến nhạy với nghẽn
363
Chúng ta đã tìm hiểu về thuật toán LS, hãy tìm hiểu một thuật toán
khác mà được sử dụng rộng rãi ngày nay - thuật toán định tuyến
vector khoảng cách.
V.2 Các thuật toán vecto khoảng cách
Ngược lại với thuật toán LS-thuật toán dùng thông tin toàn cục, thuật
toán vector khoảng cách là thuật toán lặp đi lặp lại, bất đồng bộ, và
phân tán. Nó phân tán bởi mỗi nút nhận thông tin từ một hoặc nhiều
láng giềng nối trực tiếp với nó, thực hiện phép tính toán và sau đó
phân phối kết quả phép tính đó cho các láng giềng. Nó lặp đi lặp lại ở
chỗ tiến trình này tiếp tục đến khi không đến khi nào không còn thông
tin trao đổi giữa các láng giềng. Giải thuật không đồng bộ bởi nó
không yêu cầu tất cả các nút hoạt động trong bước nhảy thời gian
(lockstep) với các nút khác. Chúng ta có thể thấy giải thuật không
đồng bộ, lặp đi lặp lại, tự kết thúc, phân tán hấp dẫn nhiều hơn so với
giải thuật tập trung.
Trước khi trình bày giải thuật DV, chúng ta cần thảo luận một mối
quan hệ quan trọng mà tồn tại trong các chi phí của các đường có chi
phí nhỏ nhất. Cho dx(y) là chi phí của đường ngắn nhất từ nút x tới
nút y. Khi đó, các chi phí nhỏ nhất liên quan bởi công thức Bellman-
Ford,
dx(y)=minv{c(x,v)+dv(y)}
với minv trong công thức được chọn từ tất cả các láng giềng của x.
Công thức Bellman-Ford khá dễ hiểu. Thật vậy, sau khi đi từ x tới v,
sau đó nếu chúng ta chọn con đường có chi phí nhỏ nhất từ v đến y,
chi phí con đường nhỏ nhất từ x sẽ là c(x,v)+ d(v). Bởi vì chúng ta
phải bắt đầu bằng việc đi đến vài láng giềng v, chi phí nhỏ nhất từ x
tới y là nhỏ nhất của c(x, v) + dv(y) lấy từ tất cả các láng giềng v.
Đối với những người có thể hoài nghi về tính xác thực của công thức
này, hãy kiểm tra nó với nút nguồn là u và nút đích là z ở hình 4.27.
Nút nguồn u có 3 láng giềng: nút v, x và w. Bằng việc đi theo các
đường khác nhau trên đồ thị, dễ thấy rằng dv(z)=5, dx(z)=3 và dw(z)=3.
Đặt các giá trị này vào công thức 4.1, cùng với các chi phí c(u,v)=2,
c(u,x)=1 và c(u,w)=5, cho giá trị du(z)=min{2+5,5+3,1+3}=4, điều
364
này rõ ràng đúng và giống với giải thuật Dijsktra đã cho chúng ta ở
cùng sơ đồ mạng.
Công thức Bellman-Ford có tầm quan trong thực tế đáng kể. Cụ thể,
giải pháp của công thức Bellman-Ford cung cấp các dòng trong bảng
chuyển tiếp của nút x. Để thấy điều này, cho v* là nút láng giềng bất
kì mà đạt được nhỏ nhất trong công thức 4.1. Sau đó, nếu nút x muốn
gửi một gói dữ liệu đến nút y trên con đường có chi phí ngắn nhất, đầu
tiên nó phải chuyển gói tin tới nút v*. Vì vậy, bảng chuyển tiếp của
nút x chỉ định nút v* như là bộ định tuyến tiếp theo cho con đường
đến đích y. Một đóng góp khác mang tích thực tế quan trọng của
Bellman-Ford là nó đề nghị hình thức cho giao tiếp giữa láng giềng
với láng giềng mà sẽ được thực hiện trong giải thuật DV.
Ý tưởng cơ bản như sau. Mỗi nút x bắt đầu với Dx(y), một ước lượng
chi phí của đường có chi phí ngắn nhất từ chính nó tới nút y, đối với
tất cả các nút trong N. Cho D = [Dx(y): y trong N] là vectơ khoảng của
của nút x, vectơ của ước lượng chi phí từ x tới các nút y trong N. Với
giải thuật DV, mỗi nút x duy trì các thông tin định tuyến sau:
▪ Đối với mỗi láng giềng v, chi phí c(x,v) từ x tới láng giếng nối
trực tiếp, v
▪ Vectơ khoảng cách của nút x, là Dx = [Dx(y): y trong N], chứa chi
phí ước lượng của x tới tất cả đích của nó, y, trong N.
▪ Các vectơ khoảng cách của mỗi láng giềng của nó, đó là D =
[Dv(y): y trong N] cho mỗi láng giềng v của x.
Trong các giải thuật bất đồng bộ, phân tán, từ thời điểm này tới thời
điểm khác, mỗi nút gửi một bảng sao chép của vectơ khoảng cách của
nó tới các láng giềng của nó. Khi một nút x nhận một vectơ khoảng
cách mới từ bất kì láng giềng v nào của nó, nó lưu vectơ khoảng cách
của v, và sử dụng công thức Bellman-Ford để cập nhật lại vectơ
khoảng cách của nó như sau:
Dx(y) = minv{c(x,v) + Dv(y)}
Nếu vectơ khoảng cách của nút x thay đổi sau khi bước cập nhật này
thực hiện, nút x sau đó sẽ gửi bảng vectơ khoảng cách cập nhật của nó
cho các láng giềng của nó, các láng giềng này cũng sẽ cập nhật các
vectơ khoảng cách của nó. Rất kì diệu, ngay khi tất cả các nút tiếp tục
365
chuyển các vectơ khoảng cách của nó trong cơ chế bất đồng bộ, mỗi
ước lượng chi phí Dx(y) hội tụ tới dx(y), chi phí thật sự của đường
ngắn nhất từ nút x tới nút y.
Giải thuật vectơ khoảng cách
Tại mỗi nút, x:
1 Khởi tạo
2 Đối với tất cả các đích y trong N:
3 Dx(y) = c(x,y) /*nếu y không là láng giềng, c(x,y)=vc*/
4 Đối với mỗi láng giềng w
5 Dw(y) = ? cho tất cả các đích y trong N
6 Đối với mỗi láng giềng w
7 Gửi vecto khoảng cách Dx=[ Dx(y):y trongN ] đến w
8
9 Lặp vô tận
10 Chờ (đến khi nhận thấy chi phí đến láng giềng w thay đổi
11 hoặc khi nhận được một vecto khoảng cách từ láng giềng w)
12
13 Đối với mỗi y trong N:
14 Dx(y) = minv{c(x,v) + Dv(y)}
15
16 Nếu Dx(y) đã thay đổi đối với bất kì đích y
17 Gửi vecto khoảng cách Dx = [Dx(y): y trong N] đến tất cả các
láng giềng
18
Trong giải thuật DV, một nút x cập nhật ước lượng vectơ khoảng cách
của nó khi nó nhận thấy có sự thay đổi chi phí của một trong những
liên kết kết nối trực tiếp với nó hay nhận được một cập nhật vectơ
khoảng cách từ các láng giềng. Tuy nhiên để cập nhật bảng chuyển
tiếp của nó đối với một đích y nào đó, điều mà nút x thực sự cần biết
366
không những khoảng cách tới y mà còn nút láng giềng v*(y), bộ định
tuyến tiếp theo trên con đường ngắn nhất tới y. Như chúng ta mong
chờ, bộ định tuyến tiếp theo v*(y) là láng giềng v mà đạt được nhỏ
nhất ở dòng 14 của giải thuật DV. Vì vậy, ở dòng 13, 14, đối với mỗi
đích y, nút x cũng các định v*(y) và cập nhật bảng chuyển tiếp của nó
cho đích y.
Nhắc lại rằng giải thuật LS là một giải thuật toàn cục khi nó yêu cầu
mỗi nút phải có một sơ đồ hoàn tất của mạng trước khi chạy thuật toán
Dijkstra. Thuật giải DV là một thuật giải phân tán và không sử dụng
các thông tin toàn cục như vậy. Thật ra, thông tin một nút có chỉ là các
chi phí của các liên kết mà kết nối trực tiếp với nó và thông tin nó
nhận được từ các láng giềng. Mỗi nút chờ cho một cập nhật từ bất kì
láng giềng ( dòng 10-11), tính toán vecto khoảng cách mới khi nhận
một cập nhật (dòng 14), và phân phối các vecto khoảng cách mới cho
các láng giềng của nó ( dòng 16-17). Các giải thuật loại DV được sử
dụng trong rất nhiều giao thức định tuyến trong thực tế, bao gồm các
giao thức RIP và BGP trên Internet, ISO IDRP, Novell IPX và mạng
ARPAnet ban đầu.
Hình 4.30 minh hoạ hoạt động của giải thuật DV trong mạng đơn giản
với 3 nút. Cách hoạt động của giải thuật này được minh họa trong một
cách đồng bộ, khi tất cả các nút đồng thời nhận các vectơ khoảng cách
từ các láng giềng của nó, tính toán các vectơ khoảng cách mới và
thông báo cho các láng giềng nếu vectơ khoảng cách của nó thay đổi.
Sau khi tìm hiểu ví dụ này, chúng ta có thể tự thuyết phục rằng giải
thuật cũng hoạt động đúng trong cách không đồng bộ, với việc mỗi
nút tính toán và cập nhật, phát sinh xảy ra ở mọi lúc.
Cột trái nhất của hình trên cho thấy ba bảng định tuyến ban đầu của 3
nút. Ví dụ, bảng ở góc trên bên trái là bảng định tuyến ban đầu của nút
x. Trong một bảng định tuyến, mỗi một dòng là một vectơ khoảng
cách, chính xác hơn, mỗi bộ định tuyến của nút bao gồm vectơ khoảng
của nó và các láng giềng của nó. Vì vậy, dòng đầu tiên trong bảng
định tuyến ban đầu của nút x là Dx=[Dx(x),Dx(y),Dz(z)]=[0,2,7].
Dòng thứ 2 và thứ 3 trong bảng này là các vectơ khoảng cách mới
nhận được từ nút y và nút z. Bởi vì lúc ban đầu nút x không nhận được
367
bất kì thông tin nào từ nút y và nút z, các dòng thứ 2 và thứ 3 được
khởi tạo là vô hạn.
Hình 4.30 – Giải thuật vectơ khoảng cách

Sau khi khởi tạo, mỗi nút gửi vectơ khoảng cách của nó cho hai láng
giềng của nó. Điều này được minh họa ở hình 4.30 bằng mũi tên từ
cột đầu tiên tới cột thứ 2 của bảng trên. Ví dụ, nút x gửi vecto khoảng
cách của nó Dx=[0,2,7] tới cả nút y và nút z. Sau khi nhận được bảng
cập nhật, mỗi nút tính toán lại vectơ khoảng cách của nó. Ví dụ, nút
tính:
Dx(x) = 0
Dx(y) = min{c(x,y)+Dy(y),c(x,z) + Dz(y)}= min {2+0,7+1}=2
368
Dx(z) = min{c(x,y)+Dy(z),c(x,z) + Dz(z)} = min {2+1,7+0}=3

Vì vậy, cột thứ hai hiển thị vectơ khoảng cách mới của nút cùng với
các vectơ khoảng cách vừa nhận được từ các láng giềng của nó đối với
mỗi nút. Lưu ý rằng, ví dụ ước lượng của nút x cho chi phí ngắn nhất
đến nút z, Dx(z) thay đổi từ 7 thành 3. Cũng chú ý rằng đối với nút x,
láng giềng y đạt được nhỏ nhất ở dòng 14 của giải thuật DV, vì vậy tại
thời điểm này của giải thuật, chúng ta có tại nút x, v*(y)=y và
v*(z)=z.
Sau khi các nút tính toán lại vectơ khoảng cách, chúng lại gửi lại các
bảng vectơ khoảng cách đã được cập nhật cho các láng giềng của
nó(nếu có sự thay đổi). Điều này được minh họa ở hình 4.30 bởi mũi
tên từ cột thứ 2 của bảng đến cột thứ 3. Lưu ý rằng chỉ các nút x và z
gửi các cập nhật: vectơ khoảng cách của nút y không thay đổi vì vậy
nút y không gửi bảng cập nhật. Sau khi nhận các thông tin tin cập
nhật, các nút tính toán lại vectơ khoảng cách và cập nhật lại các bảng
định tuyến của nó, các bảng được chỉ ra ở cột thứ 3.
Qui trình nhận các vectơ khoảng cách cập nhật từ các láng giềng, tính
toán lại các dòng trong bảng định tuyến và thông báo cho các láng
giềng về sự thay đổi chi phí được thực hiện cho đến khi không có
thông điệp nào được gửi. Tại lúc này, bởi vì không có thông tin cập
nhật nào được gửi, không có việc tính toán bảng chuyển tiếp nào xảy
ra nữa và giải thuật sẽ vào trạng ổn định, đó là, tất cả các nút sẽ tiến
hành chờ như trong dòng 10-11 của giải thuật DV. Giải thuật vẫn ở
trong trạng thái ổn định cho đến khi có một sự thay đổi chi phí đường
liên kết, sẽ được thảo luận tiếp theo.
Giải thuật vector khoảng cách: Chi phí liên kết thay đổi và đường
liên kết bị lỗi
Khi một nút chạy giải thuật DV phát hiện một sự thay đổi của chi phí
đường liên kết từ chính nó hay từ một láng giềng (dòng 10-11), nó cập
nhật vectơ khoảng cách nếu có sự thay đổi về chi phí đường đi ngắn
nhất và thông báo cho các láng giềng của nó (dòng 16,17) các vectơ
khoảng cách mới. Hình 4.31(a) minh hoạ một kịch bản mà chi phí liên
kết từ y đến x thay đổi từ 4 xuống 1. Chúng ta chỉ tập trung ở đây các
369
dòng khoảng cách của y và z đến đích x. Giải thuật DV làm cho các
sự kiện sau xảy ra:
- Tại thời điểm t0, y phát hiện thay đổi chi phí liên kết, nó cập nhật
vectơ khoảng cách của nó và thông báo cho các láng giềng về sự
thay đổi này
- Tại thời điểm t1, z nhận cập nhật từ y và cập nhật bảng của nó. Nó
tính toán lại chi phí nhỏ nhất mới tới x và gửi vectơ khoảng cách
mới tới các láng giềng của nó
- Tại thời điểm t2, y nhận cập nhập của z và cập nhật bảng khoảng
cách của nó, các chi phí nhỏ nhất của y không đổi và vì vậy y
không gửi bất kì thông điệp nào đến z. Giải thuật đi vào trạng thái
ổn định.
Vì vậy, chỉ có 2 việc lặp đi lặp lại được yêu cầu đối với giải thuật DV
để đạt trạng thái ổn định. Các thông tin tốt về việc giảm chi phí giữa x
và y được truyền nhanh trên mạng.
Bây giờ, hãy xem điều gì xảy ra khi chi phí một liên kết tăng. Giả sử
rằng, chi phí liên kết giữa và y tăng từ 4 lên 60, như được chỉ ra ở
Hình 4.31(b).
1. Trước khi chi phí liên kết thay đổi, Dy(x) = 4, Dy(z) = 1, Dz (y)=1
và Dz(x)=5. Tại thời điểm t0, y phát hiện rằng có sự thay đổi chi
phí liên kết, y tính toán đường đi có chi phí nhỏ nhất mới đến x
với chi phí
Dy(x) = min {c(y,x) + Dx(x), c(y,z)+Dz(x)} = min {60+0,1+5} = 6
60
1
y y
1 1
4
4
50 50
z x z
x
a b
Hình 4.31 – Chi phí các liên kết thay đổi
370
Tuy nhiên, với cái nhìn toàn cục đối với mạng, chúng ta có thể
nhận ra rằng chi phí mới qua z là sai. Nhưng nút y chỉ có thông
tin là chi phí kết nối trực tiếp của nó tới x là 60 và z đã thông báo
với y rằng z có thể đến x với chi phí là 5. Để đến x, y phải đi qua
z, với mong chờ z có thể đến x với chi phí là 5. Như vậy, chúng ta
có một vòng lặp định tuyến (routing loop) – để đến x, y hướng
con đường đi qua z và z hướng con đường qua y. Một vòng lặp
như vậy gọi là một hố đen (black hole).
2. Khi nút y tính toán chi phí nhỏ nhất tới x, nó thông báo z thông
tin vecto khoảng cách mới của nó tại t1.
3. Ở một số trường hợp sau t1, z nhận cập nhập vecto khoảng cách
mới của y chỉ ra rằng chi phí nhỏ nhất của y tới x là 6. z biết nó
có thể đến y với một chi phí là 1 và vì vậy tính toán chi phí nhỏ
nhất mới đến x là Dz(x)=min{50+0,1+6}=7. Bởi vì chi phí nhỏ
nhất của z đến x tăng, nó sẽ thông báo cho y vecto khoảng cách
mới của nó tại t2.
4. Cũng giống như vậy, sau khi nhận được vecto khoảng cách mới
của z, y xác định Dy(x) = 8 và gửi z vector khoảng cách của nó, z
sau đó xac định Dz(x)=9 và gửi y vecto khoảng cách của nó, và
tiếp tục…
Qui trình này tiếp tục bao lâu nữa? Chúng ta có thể nghĩ rằng vòng lặp
sẽ thực hiện 44 vòng lặp (thông điệp chuyển giữa y và z) cho đến khi
z dần dần tính được chi phí của đường của nó thông qua y lớn hơn 50.
Tại thời điểm này, z sẽ xác định rằng đường đi với chi phí ngắn nhất
của nó đến x là đi qua kết nối trực tiếp của nó đến x. y sau đó sẽ đi
đến x qua z. Kết quả của thông tin xấu về việc tăng chi phí đường liên
kết thực sự đi chậm. Điều gì xảy ra nếu chi phí liên kết c(y,x) thay đổi
từ 4 lên 10000 và chi phí c(z,x) lên 9,999. Bởi vì những kịch bản như
vậy, vấn đề mà chúng ta đang thấy đôi khi được xem như là vấn đề
đếm đến vô hạn (count – to – infinitive).
Giao thức định tuyến vecto khoảng cách: việc thêm poisoned reverse
Kịch bản vòng lặp vừa được đề cập có thể tránh bằng việc sử dụng
một kĩ thuật gọi là poison reverse. Ý tưởng khá đơn giản, nếu z đến x
thông qua y, thì z sẽ quảng bá đến y rằng khoảng cách của nó tới x là
vô hạn, Dz(x)=∞( mặc dù z biết Dz(x)=5)). Z sẽ tiếp tục thông báo
371
điều đó cho y khi nó hướng con đường đến x qua y. Bởi vì y tin rằng z
không có đường nào tới x, y sẽ không bao giờ cố gắng đến x qua z,
khi đó z tiếp tục đến x qua y.
Bây giờ hãy xem làm cách nào poison reverse có thể giải quyết vấn đề
vòng lặp mà chúng ta đã gặp trước đây ở hình 4.31(b). Như kết quả
của poison reverse, bảng khoảng cách của y chỉ Dz(x)=∞. Khi chi phí
của liên kết (x,y) thay đổi từ 4 lên 60 tại thời điểm t0, y cập nhật bảng
của nó và tiếp tục chuyển qua x, mặc dù chi phí cao hơn, và thông báo
cho z chi phí mới của nó tới x là Dy(x)=60. Sau khi nhận được cập
nhật tại t1, z lập tức chuyển đường của nó đến x qua liên kết trực tiếp
(z, x) với chi phí là 50. Bởi vì đây là đường mới có chi phí nhỏ nhất
đến x, và bởi vì không còn đường nào nữa chuyển qua y, z thông báo
cho y rằng Dz(x) = 50 tại t2. Sau khi nhận được cập nhật từ z, y cập
nhật bảng khoảng cách của nó với Dy(x) = 51. Cũng vậy, bởi vì z bây
giờ trên con đường có chi phí ngắn nhất đến x của y, y làm độc
(poison) con đường ngược lại từ z đến x bằng việc thông báo z tại thời
điểm t3 rằng Dy(x)=vô cùng.
Poision reverse có thể giải quyết được vấn đề đếm đến vô hạn nói
chung hay không? Nó không thể. Chúng ta có thể thấy rằng các vòng
lặp bao gồm 3 hay nhiều nút sẽ không thể được phát hiện bởi kĩ thuật
poisoned reverse.
So sánh giữa các giải thuật LS và DV
Các giải thuật DV và LS có các tiếp cận bổ sung cho việc định tuyến
tính toán. Trong giải thuật DV, mỗi nút chỉ nói chuyện với các láng
giềng kết nối trực tiếp của nó, nhưng nó cũng cung cấp cho các láng
giềng của nó các ước lượng chi phí nhỏ nhất từ nó cho tới tất cả các
nút mà nó biết trên mạng. Trong giải thuật LS, mỗi nút nói chuyện với
tất cả các nút khác, nhưng chỉ nói cho chúng về các chi phí của các
đường liên kết trực tiếp với nó. Chúng ta hãy kết luận việc tìm hiểu
giải thuật LS và DV với một so sánh nhanh về một vài thuộc tính của
nó. Nhắc lại N là một tập các nút (bộ định tuyến) và E là một tập các
cạnh (các đường liên kết).
▪ Độ phức tạp thông điệp. Chúng ta đã thấy rằng LS yêu cầu mỗi
nút biết chi phí của mỗi liên kết trong mạng. Điều này yêu cầu
372
O(|N||E|) thông điệp được gửi. Tương tự, khi chi phí một liên kết
thay đổi, chi phí liên kết phải được gửi cho tất cả các nút. Giải
thuật DV yêu cầu thông điệp chỉ chuyển giữa các láng giềng kết
nối trực tiếp với nó. Chúng ta cũng thấy rằng thời gian cần cho
giải thuật hội tụ phụ thuộc vào nhiều yếu tố. Khi chi phí liên kết
thay đổi, DV sẽ truyền kết của của chi phí liên kết thay đổi đó nếu
chi phí liên kết mới này làm thay đổi đường đi có chi phí ngắn
nhất cho các nút mà gắn trực tiếp với nó.
▪ Tốc độ hội tụ.Chúng ta thấy rằng việc cài đặt của chúng ta cho LS
có độ phức tạp là O(|N|2) yêu cầu O(|N| |E|) thông điệp. Giải thuật
DV có thể hội tụ chậm hơn và có thể có vòng lặp định tuyến trong
khi giải thuật đang hội tụ. DV cũng phải gặp vấn đề đếm đến vô
hạn.
▪ Độ vững mạnh (Robustness): Điều xảy ra nếu một bộ định tuyến
bị lỗi, hoạt động sai hoặc bị phá hoại. Dưới LS, một bộ định
tuyến có thể quảng bá các chi phí không đúng của nó cho các liên
kết trực tiếp với nó. Một nút cũng có thể hủy bất kì gói tin nào nó
nhận được như một phần của quảng bá LS. Nhưng một nút LS chỉ
đang tính toán các bảng chuyển tiếp cho chính nó, các nút khác
cũng thực hiện công việc như vậy cho chính nó. Điều này có
nghĩa rằng việc tính toán đường đi là riêng lẻ dưới LS, vì vậy
cung cấp độ vững vàng cho hệ thống. Dưới DV, một nút chỉ có
thể quảng bá các đường có chi phí ngắn nhất bị sai đến bất kìa
hoặc tất cả các đích. Tổng quát hơn, chúng ta lưu ý rằng, tại mỗi
lần lặp lại, việc tính toán của một nút trong DV được chuyển cho
các láng giềng của nó và sau đó được chuyển cho láng giềng của
láng giềng ở lần lặp tiếp theo. Đối với việc này, một tính toán sai
lệch của một nút có thể truyền đi toàn mạng dưới DV.
Một số giải thuật định tuyến khác
Các giải thuật LS và DV chúng ta đã nghiên cứu không chỉ là các giao
thức được sử dụng trong thực tế, về cơ bản, đây chỉ là các giao thức
định tuyến được sử dụng trong thực tế ngày nay trên Internet. Tuy
nhiên, có rất nhiều giải thuật định tuyến được đề xuất bởi các nhà
khoa học trong 30 năm qua, từ các giải thuật đơn giản nhất tới các giải
thuật rất phức tạp. Một lớp rộng lớn của các giải thuật định tuyến là
dựa vào việc xem lưu lượng dữ liệu như các luồng dữ liệu giữa các
373
nguồn và đích trong một mạng. Trong cách tiếp cận này, vấn đề định
tuyến có thể được toán học hóa bằng cách công thức hóa các vấn đề
tối ưu về lưu lượng được biết như vấn đề luồng trong mạng. Ngoài ra,
các tập giải thuật định tuyến khác chưa được đề cập ở đây được thừa
kết từ mạng điện thoại. Các giải thuật định tuyến chuyển mạch mạch
này gây chú ý cho mạng dữ liệu chuyển mạch gói trong trường hợp
các tài nguyên trên từng liên kết (ví dụ, bộ đệm, ỏ một phần của băng
thông..) được dành riêng cho mỗi kết nối mà được định tuyến đi trên
liên kết đó. Trong khi việc công thức hóa các vấn đề định tuyến có thể
khác với công thức định tuyến chi phí nhỏ nhất chúng ta đã tìm hiểu
trong chương này, cũng có một số lượng các giao thức giống như vậy,
ít nhất là giải thuật tìm đường.
V.3 Định tuyến theo cấu trúc phân cấp
Trong tìm hiểu của chúng ta về các giải thuật LS và DV, chúng ta đã
xem mạng đơn giản như một tập các bộ định tuyến kết nối với nhau.
Một bộ định tuyến không thể phân biệt với bộ định tuyến khác khi tất
cả các bộ định tuyến thực thi các giải thuật định tuyến giống nhau để
tính các đường đi trên toàn mạng. Trong thực tế, mô hình này và cái
nhìn của nó đối với một tập hợp lớn các bộ định tuyến cùng thực thi
một giao thức định tuyến thì khá đơn giản bởi 2 lí do quan trọng:
▪ Phạm vi: Khi số lượng bộ định tuyến càng lớn, chi phí cho việc
tính toán, lưu trữ, giao tiếp thông tin định tuyến ngày càng tăng
lên. Mạng Internet ngày nay gồm hàng trăm triệu các host. Việc
lưu trữ thông tin của mỗi host này yêu cầu một số lượng lớn bộ
nhớ. Chi phí cho việc quảng bá các cập nhật LS trong tất cả các
bộ định tuyến trên mạng Internet sẽ tốn hết băng thông và không
còn để gửi các gói tin. Một giải thuật định tuyến DV lặp đi lặp lại
trong một số lượng lớn các bộ định tuyến như thế sẽ không bao
giờ hội tụ được. Rõ ràng, vài thứ phải được thực hiện để giảm độ
phức tạp của việc tính toán các đường đi trong các mạng rộng lớn
như mạng Internet.
▪ Quyền tự trị: Mặc dù các nhà khoa học mong muốn bỏ qua các
vấn đề như việc các công ty mong muốn chạy các bộ định tuyến
của họ theo cách họ mốn (ví dụ, chạy giải thuật định tuyến nào họ
chọn) hoặc muốn ẩn đi những đặc điểm của mạng tổ chức bên
374
trong đối với thế giới bên ngoài, đây là những xem xét quan
trọng. Lí tưởng là một tổ chức nên có thể chạy và quản trị hệ
thống mạng của họ như họ muốn, trong khi vẫn có thể kết nối với
các mạng bên ngoài.
Cả hai vấn đề này có thể được giải quyết bởi việc đưa các bộ tuyến
của tổ chức vào các vùng tự trị, với mỗi vùng tự trị bao gồm một
nhóm các bộ định tuyến được vận hành dưới sự điều khiển quản trị
chung (ví dụ, hoạt động bởi cùng ISP hoặc cùng thuộc mạng của công
ty). Các bộ định tuyến cùng AS sẽ chạy cùng giải thuật định tuyến và
có thông tin của nhau – giống như mô hình lí tường mà chúng ta đã đề
cập ở phần trước. Giải thuật định tuyến chạy bên trong một hệ thống
tự trị được gọi là một giao thức định tuyến bên trong vùng tự trị. Dĩ
nhiên, các AS cần kết nối lại với nhau, và vì vậy một hay nhiều bộ
định tuyến trong một AS sẽ có thêm nhiệm vụ chuyển gói tin đến đích
ngoài AS, các bộ định tuyến này được gọi là các bộ định tuyến cổng
(gateway routers)
Hình 4.32 cung cấp một ví dụ đơn giản với 3 AS: AS1, AS2 và AS3.
Trong hình này, các dòng đậm biểu diễn các liên kết trực tiếp giữa các
cặp của bộ định tuyến. Các đường mỏng đi từ bộ định tuyến biểu diễn
các mạng con mà kết nối trực tiếp đến bộ định tuyến. AS1 có 4 bộ
định tuyến 1a, 1b, 1c và 1d chạy giao thức định tuyến bên trong AS.
Vì vậy, mỗi bộ định tuyến này biết cách chuyển gói tin theo đường tối
ưu đến các đích bên trong AS1. Giống như vậy, các vùng tự trị AS2
và AS3 có 3 bộ định tuyến. Lưu ý rằng các giải thuật định tuyến bên
trong AS chạy ở các AS1, AS2, AS3 là không giống nhau. Cũng lưu ý
rằng các bộ định tuyến 1b, 1c, 2a và 3a là các bộ định tuyến cổng.
Chúng ta đã hiểu rõ cách các bộ định tuyến bên trong một AS xác
định các con đường đi cho các cặp nguồn-đích nằm trong AS như thế
nào. Tuy nhiên, làm thế nào một bộ định tuyến bên trong AS biết cách
để định tuyến một gói tin đến một đích nằm ngoài AS. Rất dễ để trả
lời câu hỏi này nếu AS chỉ có một bộ định tuyến cổng kết nối với một
AS khác. Trong trường này, bởi vì các giải thuật định tuyến trong một
AS xác định con đường ngắn nhất từ mỗi bộ định tuyến bên trong đến
bộ định tuyến cổng, mỗi bộ định tuyến bên trong biết cách để chuyển
các gói tin đi. Bộ định tuyến cổng, khi nhận được gói tin, chuyển gói
375
tin đó theo đường liên kết đi ra ngoài AS. AS khác trên đường liên kết
sẽ có trách nhiệm cho việc định tuyến gói tin tới đích cuối cùng của
nó. Ví dụ, giả sử bộ định tuyến 2b trong hình 4.32 nhận một gói tin
mà đích là bên ngoài AS2. Bộ định tuyến 2b sẽ chuyển gói tin đến bộ
định tuyến 2a hoặc 2c, khi được chỉ định bởi bảng chuyển tiếp trong
bộ định tuyến 2b, bảng chuyển tiếp được cấu hình bởi giao thức định
tuyến bên trong AS của AS2. Gói tin sẽ dần dần đến được bộ định
tuyến cổng 2a, sau đó sẽ chuyển tới 1b. Khi gói tin rời 2a, công việc
của AS2 là hoàn tất với gói tin này.
Hình 4.32 – Ví dụ về các hệ thống tự trị kết nối với nhau

Vì thế, vấn đề là đơn giản khi AS nguồn chỉ có một liên kết ra một AS
bên ngoài. Nhưng nếu AS nguồn có 2 hay nhiều liên kết ra AS bên
ngoài thì sao? Nếu vậy, vấn đề của việc biết chuyển gói tin đi đâu trở
nên là một vấn đề đầy thách thức. Ví dụ, hãy xem bộ định tuyến trong
AS1 và giả sử nó nhận một gói tin mà đích của nó bên ngoài AS. Bộ
định tuyến rõ ràng nên chuyển gói tin tới một trong 2 bộ định tuyến
cổng của nó, 1b hoặc 1c, nhưng chuyển cho cái nào?. Để giải quyết
vấn đề này, AS1 cần (1) biết các đích nào có thể đến được qua AS2 và
đích nào có thể đến được qua As3 và (2) chuyển các thông tin có thể
đến được này cho tất cả các bộ định tuyến bên trong AS1, để mỗi bộ
376
định tuyến có thể cấu hình bảng chuyển tiếp của nó để có thể đến
được các đích bên ngoài AS. Hai nhiệm vụ này, lấy các thông tin có
thể đến được từ các AS láng giềng và chuyển các thông tin có thể đến
được này cho các bộ định tuyến bên trong AS được thực hiện bởi các
giao thức định tuyến giữa các AS. Bởi vì giải thuật định tuyến giữa
các AS liên quan đến việc giao tiếp giữa 2 AS, việc giao tiếp giữa 2
AS phải được chạy trên cùng một giao thức định tuyến giữa các AS.
Thật vậy, trên Internet, các AS chạy cùng chung giải thuật định tuyến
giữa các AS, gọi là BGP4, giao thức sẽ được thảo luận ở phần tiếp
theo. Như hình 4.32, mỗi bộ định tuyến nhận thông tin từ một giao
thức định tuyến bên trong AS và một giao thức định tuyến giữa các
AS và sử dụng thông tin của 2 giao thức này để cấu hình bảng chuyển
tiếp của nó.
Ví dụ, xem một mạng con x, và giả sử AS1 học từ các giao thức định
tuyến giữa các AS rằng mạng con x có thể đến được từ AS3 nhưng
không thể đến được từ AS2. AS1 khi đó sẽ chuyển thông tin này cho
các bộ định tuyến của nó. Khi bộ định tuyến 1d học rằng x có thể đến
được từ AS3, và vì vậy bộ định tuyến cổng là 1c, nó xác định, từ
những thông tin cung cấp bởi giao thức định tuyến bên trong AS giao
tiếp cổng bộ định tuyến mà nằm trên đường đi có chi phí nhỏ nhất từ
1d đến bộ định tuyến cổng 1c. Giả sử đây là giao tiếp cổng 1. Bộ định
tuyến 1d sau đó có thể thêm dòng (x,1) vào trong bảng chuyển tiếp
của nó (ví dụ này, và một số khác trình bày ở phần này là các vấn đề
đang thực sự diễn ra trên mạng Internet. Trong phần tiếp theo, chúng
ta sẽ tìm hiểu chi tiết hơn khi đề cập tới BGP).
Sử dụng ví dụ ở trên, bây giờ giả sử AS2 và AS3 kết nối đến các AS
khác, điều này không được thể hiện ở trong hình vẽ. Giả sử rằng AS1
học từ giao thức định tuyến giữa các AS rằng mạng con x có thể đến
được từ AS2, qua bộ định tuyến cổng 1b và từ AS3, qua bộ định tuyến
cổng 1c. AS1 sau đó sẽ chuyển thông tin này cho các bộ định tuyến
của nó, bao gồm bộ định tuyến 1d. Để cấu hình bảng chuyển tiếp của
nó, 1d sẽ phải xác định bộ định tuyến cổng nào, 1b hay 1c mà nó nên
chuyển gói tin đến đích là mạng con x. Một cách tiếp cận thường được
triển khai trong thực tế là sử dụng định tuyến quả táo nóng (hot-potato
routing). Trong giải thuật định tuyến quả táo nóng, AS loại bỏ các gói
tin (quả táo nóng) nhanh nhất có thể. Điều này được thực hiện bởi việc
377
một bộ định tuyến gửi gói tin tới bộ định tuyến cổng mà có chi phí từ
bộ định tuyến đến bộ định tuyến cổng nhỏ nhất trong số tất cả các bộ
định tuyến cổng mà có đường tới đích. Trong ngữ cảnh của ví dụ hiện
tại, giao thức định tuyến quả táo nóng chạy trong 1d sẽ sử dụng thông
tin từ giao thức định tuyến bên trong AS để xác định các chi phí
đường đi tới 1b và 1c, và sau đó chọn con đường có chi phí nhỏ nhất.
Khi đường được chọn, bộ định tuyến 1d thêm vào một dòng cho mạng
con x trong bảng chuyển tiếp của nó. Hình 4.33 tóm gọn các hành
động được thực hiện tại bộ định tuyến 1d để thêm một dòng mới cho
mạng con x trong bảng chuyển tiếp.
Khi một AS học về một đích từ một AS láng giềng, AS có thể quảng
bá thông tin định tuyến này cho các AS láng giềng khác của nó. Ví dụ,
giả sử AS1 học từ AS2 rằng mạng x có thể đến được qua AS1. AS1
sau đó có thể thông báo cho AS3 rằng x có thể đến được qua AS1.
Trong cách này, nếu AS3 cần định tuyến một gói tin đến đích x, AS3
sẽ chuyển gói tin đến AS1, AS1 sau đó sẽ chuyển cho AS2. Chúng ta
sẽ thấy trong thảo luận về BGP, một AS khá linh động trong việc
quyết định đích nào nó sẽ quảng bá cho các AS láng giềng của nó.
Đây là một quyết định liên quan tới chính sách, thường phụ thuộc vào
các vấn đề liên quan đến kinh tế hơn là kĩ thuật.
Sử dụng thông tin

Xác định từ bảng
Học từ các giao thức định tuyến từ các
Định tuyến quả táo chuyển tiếp giao diện
định tuyến rằng mạng giao thức định tuyến
nóng: Chọn bộ định l dẫn đến bộ định
con x có thể đến bên trong AS để xác
tuyến cổng có chi phí tuyến cổng có chi phí
được qua nhiều bộ định các đường đi
nhỏ nhất nhỏ nhất. Đưa (x,l)
định tuyến cổng ngắn nhất cho mỗi bộ
vào bảng chuyến tiếp
định tuyến cổng
Hình 4.33 – Các bước trong việc thêm một đích AS bên ngoài vào bảng
chuyển tiếp của bộ định tuyến
Nhắc lại phần 1.5, mạng Internet bao gồm các nhà cung cấp dịch vụ
kết nối với nhau. Vậy, mối quan hệ giữa các nhà cung cấp dịch vụ các
AS là thế nào? Chúng ta có thể nghĩ rằng các bộ định tuyến bên trong
một ISP và các đường liên kết kết nối giữa chúng tạo nên một AS đơn.
378
Mặc dù đây là một trường hợp thường xảy ra, nhiều nhà cung cấp dịch
vụ chia mạng của họ thành nhiều AS. Ví dụ, với các ISP cấp 1 sử
dụng một AS cho toàn mạng của nó; các ISP khác chia ISP thành 10
các AS nối với nhau.
Tóm lại, các vấn đề phạm vi và sự tự trị được giải quyết bởi việc định
nghĩa các hệ thống tự trị. Bên trong một AS, tất cả các bộ định tuyến
cùng chạy giao thức định tuyến bên trong AS. Giữa các AS này cùng
chạy chung giao thức định tuyến giữa các AS. Vấn đề của phạm vi
được giải quyết bởi vì một bộ định tuyến bên trong AS chỉ cần biết
các bộ định tuyến bên trong AS của nó. Vấn đề của sự tự trị được giải
quyết bởi vì một tổ chức có thể chạy bất kì giao thức định tuyến bên
trong AS nào họ chọn. Tuy nhiên, mỗi cặp kết nối AS cần chạy chung
giao thức định tuyến giữa các AS để có thể chuyển các thông tin có
thể đến được qua nhau.
Trong các phần sau, chúng ta sẽ tìm hiểu 2 giao thức định tuyến bên
trong AS (RIP và OSPF) và giao thức định tuyến giữa các AS với
nhau (BGP) mà được sử dụng rộng rãi trên Internet ngày nay.
VI. Định tuyến trên Internet

Sau khi tìm hiểu về địa chỉ trên Internet và giao thức IP, giờ đây
chúng ta sẽ quan tâm tới các giao thức định tuyến của Internet; các
giao thức với mục tiêu xác định con đường để chuyển gói tin đi từ
nguồn tới đích. Chúng ta sẽ nhận ra rằng các giao thức định tuyến trên
Internet bao hàm nhiều nguyên lí chúng ta đã học trước đó ở chương
này. Các cách tiếp cận trạng thái liên kết và vector khoảng cách đã
được tìm hiểu ở phần 4.5.1 và 4.5.2, khái niệm về một vùng tự trị
được xem xét trong phần 4.5.3 là các phần cơ bản để giải thích các
giao thức định tuyến được thực hiện như thế nào trên mạng Internet
ngày nay.
Quay lại phần 4.5.3, một vùng tự trị là tập hợp các bộ định tuyến với
cùng các chính sách quản trị và quản lí kĩ thuật, và giữa chúng chạy
cùng giao thức định tuyến. Mỗi AS chứa nhiều mạng con (subnet)
379
VI.1 Định tuyến nội vùng: RIP

Một giao thức định tuyến bên trong một vùng tự trị (intra-AS) thường
được sử dụng xác định làm cách nào việc định tuyến được thực hiện
trong một vùng tự trị (AS). Các giao thức định tuyến bên trong vùng
tự trị được xem như các giao thức bên trong (interior gateway
protocols). Về mặt lịch sử, hai giao thức định tuyến được sử dụng
rộng rãi cho việc định tuyến trong một vùng tự trị trên Internet là:
Routing Information Protocol (RIP) và Open Shortest Path First
(OSPF). Có một giao thức định tuyến gần giống với OSPF là giao
thức IS-IS. Chúng ta sẽ thảo luận RIP trước và sau đó sẽ xem xét
OSPF sau.
RIP là một trong các giao thức định tuyến bên trong một vùng tự trị
trên Internet đầu tiên và vẫn được sử dụng rộng rãi ngày nay. Nguồn
gốc và tên gọi của nó bắt nguồn từ kiến trúc Xerox Network Sysem
(XNS0). Sự phát triển rộng rãi của nó một phần bởi nó được đưa vào
phiên bản BSP của UNIX hỗ trợ TCP/IP vào năm 1982. RIP phiên
bản 1 được định nghĩa trong [RFC 1058] và phiên bản 2 được định
nghĩa sau đó trong [RFC 2453]
RIP là một giao thức vectơ khoảng cách hoạt động gần giống với giao
thức vectơ khoảng cách mà chúng ta đã tìm hiểu trong Section 4.5.6.
Phiên bản của RIP trong RFC1058 sử dụng số lượng các hop (hop
count) như là độ đo (metric) để tính chi phí với mỗi liên kết có một
chi phí là 1. Trong giải thuật vector khoảng cách trong Phần 4.5.2, để
cho đơn giản, các chi phí được định nghĩa giữa các cặp của bộ định
tuyến. Trong RIP (hoặc OSPF), các phi chí được xác định từ bộ định
tuyến nguồn đến mạng con đích. RIP sử dụng thuật ngữ “số lượng
hop” như là số lượng các mạng con đi qua trên đường ngắn nhất từ bộ
định tuyến nguồn đến mạng đích, bao gồm cả mạng con đích. Hình
4.34 minh họa một AS với 6 mạng con lá. Bảng trong hình chỉ ra rằng
số lượng của “hop” từ nguồn A tới mỗi mạng con lá.
Chi phí lớn nhất của một con đường được giới hạn là 15, vì vậy giới
hạn việc sử dụng của RIP trong các vùng tự trị ít hơn 15 hop về đường
kính. Quay lại các giao thức vectơ khoảng cách, các bộ định tuyến
chuyển các thông tin khoảng cách cho nhau. Vectơ khoảng cách cho
bất kì một bộ định tuyến nào là ước lượng hiện thời con đường đi
380
ngắn nhất từ bộ định tuyến nguồn tới các mạng con trong vùng tự trị.
Trong RIP, các bảng cập nhật định tuyến được chuyển giữa các láng
giềng xấp xỉ 30s sử dụng các thông điệp RIP phản hồi (RIP response
message). Thông điệp phản hồi được sử dụng bởi một bộ định tuyến
hay host chứa một danh sách tới 25 mạng con đích bên trong AS, cũng
như khoảng cách của nơi gửi tới mỗi các mạng con này. Các thông
điệp đó được biết như các thông điệp quảng bá RIP (RIP
advertisements).
Hình 4.34 – Số lượng hop từ nguồn bộ định tuyến A đến các mạng con
Hình 4.35 – Một phần của một hệ thống tự trị

Hãy xem một ví dụ đơn giản về việc cách các thông điệp quảng bá
RIP hoạt động. Xem một phần của một AS được chỉ ra ở hình 4.35.
Trong hình này, các đường kết nối giữa các bộ định tuyến biểu thị các
mạng con. Chỉ các bộ định tuyến (A,B,C,D) và các mạng (w,x,y,z)
được đánh nhãn. Các đường chấm chấm chỉ rằng AS vẫn còn tiếp tục,
381
vị vậy vùng tự trị này có nhiều bộ định tuyến và các liên kết hơn như
trên hình.
Mỗi bộ định tuyến duy trì một bảng RIP được biết như là bảng định
tuyến (routing table). Bảng định tuyến của bộ định tuyến bao gồm cả
vectơ khoảng cách của bộ định tuyến và bảng chuyển tiếp của của bộ
định tuyến. Hình 4.36 minh họa bảng định tuyến cho bộ định tuyến D.
Chú ý rằng bảng định tuyến có 3 cột. Cột đầu tiên được dành cho
mạng con đích, cột thứ 2 chỉ ra bộ định tuyến kế tiếp trong con đường
ngắn nhất tới mạng con đích, và cột thứ 3 chỉ rằng số lượng hop (số
lượng của mạng con mà phải đi qua, bao gồm cả mạng con đích) để
đến mạng con đích trên con đường ngắn nhất. Ở ví dụ này, bảng chỉ ra
rằng để gửi một gói tin từ bộ định tuyến D đến mạng con đích w, gói
tin đầu tiên nên được chuyển đến bộ định tuyến láng giềng A; bảng
cũng chỉ ra rằng mạng đích w là cách 2 hop trên con đường ngắn nhất.
Hình 4.36 – Bảng chuyển tiếp tại bộ định tuyến D trước khi nhật quảng bá
từ bộ định tuyến A
Tương tự như vậy, mạng con z cách 7 hop và qua bộ định tuyến B. Về
nguyên lí, một bảng định tuyến sẽ có một dòng cho mỗi mạng con
trong AS, mặc dù RIP phiên bản 2 cho phép các mạng con có thể kết
hợp các dòng lại sử dụng các kĩ thuật kết hợp đường đi giống như
được trình bày ở phần 4.4. Bảng 4.36, và các bảng tiếp theo chỉ hoàn
thành một phần.
Giả sử rằng 30 giây sau, bộ định tuyến D nhận từ bộ định tuyến A
thông tin quảng bá được chỉ ra ở Hình 4.37. Chú ý rằng thông tin định
tuyến này chính là thông tin bảng định tuyến từ bộ định tuyến A.
382
Thông này chỉ rằng, thực tế mạng con z chỉ cách 4 hop từ bộ định
tuyến A. Bộ định tuyến D khi nhận được thông tin quảng bá này sẽ
nối với thông tin tin này với bảng định tuyến cũ. Thực tế, bộ định
tuyến D đã học rằng có một con đường mới qua bộ định tuyến A tới
mạng con z ngắn hơn con đường thông qua bộ định tuyến B. Vì vậy,
bộ định tuyến D cập nhật thông tin bảng định tuyến để chọn con
đường ngắn nhất ngắn hơn, như được chỉ ra ở hình 4.38. Chúng ta có
thể hỏi rằng, tại sao con đường ngắn nhất tới mạng z vẫn có thể trở
nên ngắn hơn. Có khả năng, giải thuật vectơ khoảng cách không tập
trung vẫn trong đang qui trình hội tụ (xem phần 4.5.2) hoặc có lẽ các
đường liên kết mới và/hoặc các bộ định tuyến được thêm vào AS, vì
vậy dẫn tới việc thay đổi đường ngắn nhất trong AS.
Hãy xem một số khía cạnh hiện thực của RIP. Như đã biết, các bộ
định tuyến RIP chuyển các thông tin quảng bá xấp xỉ mỗi 30 giây.
Hình 4.37 – Quảng bá từ bộ định tuyến A
Hình 4.38 – Bảng định tuyến tại bộ định tuyến D sau khi nhận quảng bá từ
bộ định tuyến A.
383
Nếu một bộ định tuyến không nghe gì từ các láng giềng của nó ít nhất
180 giây, láng giềng đó được xem là không thể kết nối được nữa; lí do
có thể là láng giếng đã không còn hoạt động nữa hoặc đường kết nối
bị đứt. Khi việc này xảy ra, RIP chỉnh sửa bảng định tuyến cục bộ và
truyền bá thông tin này bằng viêc gửi các quảng bá cho các bộ định
tuyến láng giềng của nó (các láng giếng mà còn kết nối với nó). Một
bộ định tuyến cũng có thể yêu câu các thông tin về chi phí của các
láng giềng của nó đến một đích nào đó sử dụng thông điệp yêu cẩu
của RIP. Các bộ định tuyến gửi các thông điệp RIP yêu cầu và RIP
phản hồi cho nhau sử dụng UDP và cổng 520. Gói tin UDP được
mang giữa các bộ định tuyến tuân theo chuẩn gói tin IP. Chúng ta có
thể nghĩ rằng RIP sử dụng giao thưc tầng Vận chuyển (UDP) trên giao
thức tầng Mạng (IP) để thực hiện chức năng của tầng Mạng (giao thức
định tuyến) dường như khá buồn cười. Xem kĩ hơn về cách RIP được
hiện thực sẽ làm rõ vấn đề này.
Hình 4.39 trình bày cách RIP được hiện thực trong một hệ thống
UNIX, ví dụ, một máy UNIX phục vụ như một bộ định tuyến. Một qui
trình gọi là được định tuyến (routed) thực thi RIP, đó là, duy trì bảng
thông tin định tuyến và chuyển các thông điệp với các tiến tiến trình
định tuyến chạy trên các bộ định tuyến láng giềng.
Được định
Được định
tuyến
tuyến
Vận chuyển Vận chuyển

(UDP) (UDP)
Mạng Mạng
Các bảng chuyển tiếp Các bảng chuyển tiếp
(IP) (IP)
Liên kết Liên kết
Vật lí
Vật lí
Hình 4.39 – Cài đặt của RIP
384
Bởi vì RIP được triển khai như một tiến trình ở tầng Ứng dụng, nó có
thể gửi và nhận các thông điệp trên một socket chuẩn sử dụng giao
thức tầng Vận chuyển chuẩn. Như đã nói ở trên, RIP được triển khai
như một giao thưc tầng Ứng dụng chạy trên UDP.
VI.2 Định tuyến nội vùng: OSPF
Giống như RIP, giao thức định tuyến OSPF được sử dụng rất rộng rãi
cho việc định tuyến trong một AS trên mạng Internet. OSPF và họ
hàng của nó, IS-IS, được triển khai ở các ISP cấp cao hơn trong khi
RIP được triển khai ở các ISP cấp dưới và trong hệ thống mạng các
doanh nghiệp lớn. Khái niệm mở trong OSPF chỉ rằng giao thức định
tuyến được sử dụng ở tất cả các thiết bị (đối lập với giao thức EIGRP
chỉ sử dụng cho các thiết bị Cisco). Phiên bản mới nhất của OSPF là
phiên bản 2, được định nghĩa trong RFC2328, là một tài liệu được
công khai.
OSPF được xem như là giao thức đời sau của RIP và có rất nhiều tính
năng cải tiến. Tuy nhiên, về bản chất, OSPF là một giao thức định
tuyến theo trạng thái đường liên kết sử dụng cách làm ngập tràn thông
tin trạng thái liên kết và giải thuật tìm đường ngắn nhất Dijkstra. Với
OSPF, một bộ định tuyến xây dựng một cấu trúc toàn cục của hệ
thống (một đồ thị) của toàn bộ hệ thống tự tri. Bộ định tuyến sau đó sử
dụng giải thuật tìm đường ngắn nhất Dijkstra để xác định một cây có
con đường ngắn nhất tới các mạng con, với nó là một nút gốc. Các chi
phí của từng liên kết được cấu hình bởi người quản trị. Người quản trị
có thể thiết lập chi phí là 1, vì vậy có thể sử dụng việc định tuyến lựa
chọn số lượng hop nhỏ nhất, hoặc sử dụng việc thiết lập các trọng số
các liên kết dựa vào các khả năng của liên kết để có thể làm cho luồng
dữ liệu ít qua các đường liên kết với băng thông kém. OSPF không
đưa ra một chính sách về cách thiết lập trọng số các liên kết (đó là
việc của người quản trị mạng), nhưng sẽ cung cấp các kĩ thuật để xác
định con đường đi với chi phí ngắn nhất cho tập các trọng số liên kết
đã có.
Với OSPF, một bộ định tuyến quảng bá thông tin định tuyến cho tất cả
các bộ định tuyến khác trong vùng tự trị, không chỉ cho các bộ định
tuyến láng giếng. Một bộ định tuyến quảng bá thông tin đường liên
385
kết khi nào có một sự thay đổi trạng thái của liên kết (ví dụ, thay đổi
chi phí hay thay đổi trạng thái hoạt động/không hoạt động). Các bộ
định tuyến cũng quảng bá định kì trạng thái đường liên kết thậm chí
nếu trạng thái đường liên kết không thay đổi. RFC 2328 lưu ý rằng
“việc cập nhật định kì này của việc quảng bá thông tin đường liên kết
thêm tính vững vàng cho giải thuật trạng thái liên kết”. Các quảng bá
OSPF được chứa trong các thông điệp OSPF được mang trong gói tin
IP với một giao thức tầng cao hơn sử dụng cổng 89 cho OSPF. Vì vậy,
giao thức OSPF thực hiện những chức năng như chuyển thông điệp tin
cậy và quảng bá thông tin trạng thái liên kết. Giao thức OSPF cũng
kiểm tra các liên kết có hoạt động đúng hay không (thông qua các
thông điệp HELLO mà được gửi cho các láng giềng) và cho phép một
bộ định tuyến OSPF chứa một cơ sở dữ liệu các trạng thái đường liên
kết của cả hệ thống mạng.
Một ưu điểm của OSPF như sau:
▪ Bảo mật: Việc chuyển thông điệp giữa các bộ định tuyến OSPF
(ví dụ, thông tin cập nhật định tuyến) có thể được xác thực. Với
cơ chế xác thực, chỉ có các bộ định tuyến đáng tin cậy mới có thể
tham gia trong giao thức OSPF trong một AS, vì vậy ngăn ngừa
những phá hoại nguy hiểm từ việc đưa vào các thông tin không
chính xác vào các bảng của bộ định tuyến. Mặc định, gói tin
OSPF giữa các bộ định tuyến không được chứng thực và có thể bị
giả mạo. Hai loại chứng thực có thể cấu hình – loại đơn giản và
loại sử dụng MD5. Với cơ chế chứng thực đơn giản, mật mã
(password) được cấu hình giống nhau tại mỗi bộ định tuyến. Khi
một bộ định tuyến gửi một gói tin OSPF, nó mang theo mật mã
(password) ở chế độ có thể nhìn thấy được. Rõ ràng, phương pháp
chứng thực này không bảo mật cao. Phương thức chứng thực
MD5 dựa vào các khóa bí mật chia sẻ (shared keys) được cấu
hình ở tất cả các bộ định tuyến. Khi mỗi gói tin OSPF được gửi,
bộ định tuyến tính ra một bảng băm MD5 cho nội dụng của gói
tin OSPF gắn với khóa bí mật. Sau đó bộ định tuyến đưa giá trị
kết quả băm vào gói tin OSPF. Bộ định tuyến nhận sử dụng các
khóa được cấu hình trước, sẽ tính toán một bảng băm MD5 của
gói tin và so sánh nó với giá trị băm mà gói tin mang, vì vậy có
thể xác nhận được sự chứng thực của gói tin. Các số thứ tự
386
(sequence number) cũng được sử dụng với chứng thực MD5 để

chống các tấn công theo kiểu replay.
▪ Nhiều đường với chi phí bằng nhau: Khi nhiều đường đến đích
có chi phí bằng nhau, OSPF cho phép nhiều đường có thể sử dụng
để chuyển các gói tin.
▪ Hỗ trợ tích hợp cho định tuyến unicast và định tuyến
multicast: Multicast OSPF [RFC 1584] đưa ra một đặc tả mở
rộng đơn giản cho OSPF để cung cấp định tuyến multicast.
MOSPF sử dụng cơ sử dữ liệu đường liên kết hiện có và thêm vào
một loại quảng bá đường liên kết trong kĩ thuật quảng bá đường
liên kết OSPF hiện thời.
▪ Hỗ trợ phân cấp trong một vùng định tuyến đơn: Có lẽ, ưu
điểm nổi bật nhất trong OSPF là khả năng xây dựng mô hình
phân cấp hệ thống tự trị. Phần 4.5.3 đã xét qua nhiều ưu điểm của
các cấu trúc định tuyến phân cấp. Chúng ta sẽ tìm hiểu việc hiện
thực của định tuyến phân cấp OSPF trong phần còn lại của phần
này.
Một hệ thống tự trị OSPF có thể được cấu hình phân cấp thành nhiều
vùng. Mỗi vùng chạy giao thức định tuyến theo trạng thái đường liên
kết OSPF của nó, với mỗi bộ định tuyến trong một vụng quảng bá
thông tin trạng thái đường liên kết cho tất cả các bộ định tuyến trong
vùng đó. Trong mỗi vùng, một hoặc nhiều các bộ định tuyến biên có
trách nhiệm định tuyến các gói tin bên ngoài vùng. Cuối cùng, một
vùng OSPF trong một AS được cấu hình như là một vùng sương sống
(backbone). Vai trò chính của vùng sương sống này là để chuyển các
luồng dữ liệu giữa các vùng trong AS. Vùng sương sống luôn chứa tất
cả các bộ định tuyến biên nối với các vùng và có thể chứa các bộ định
tuyến không phải là các bộ định tuyến biên. Việc định tuyến giữa các
vùng trong một AS yêu cầu gói tin đầu tiên sẽ được chuyển đến một
bộ định tuyến biên, sau đó được chuyển đi qua vùng sương sống đến
bộ định tuyên biên mà thuộc về vùng đích, và sau đó được chuyển đến
đích cuối cùng.
VI.3 Định tuyến ngoại vùng: BGP
Chúng ta đã tìm hiểu làm thế nào các ISP sử dụng RIP và OSPF để
xác định con đường tốt nhất từ các cặp nguồn – đích bên trong một
387
AS. Bây giờ, chúng ta hãy tìm hiểu xem làm cách nào các cặp đường
đi nguồn- đích có thể mở rộng trên nhiều AS. Giao thức Border
Gateway Protocol phiên bản 4, được đặc tả trong RFC 4271 là một
giao thức định tuyến chính giữa các AS trên mạng Internet hiện nay.
Nó được gọi là BGP4 hay đơn giản chỉ là BGP. Vì là một giao thức
định tuyến giữa các AS, BGP cung cấp cho mỗi AS một cách để:
1. Lấy thông tin các mạng con có thể đến được từ các AS láng
giềng
2. Truyền các thông tin các mạng con có thể đến được đến tất cả
các bộ định tuyến trong AS.
3. Xác định các đường nào là tốt tới các mạng con dựa trên thông
tin có thể đến được và chính sách trên AS.
Quan trọng hơn cả, BGP cho phép mỗi mạng con có thể quảng bá sự
tồn tại của nó cho toàn mạng Internet. Một mạng con sẽ thông báo
“Tôi tồn tại và tôi ở đây”, và BGP sẽ đảm bảo chắc rằng tất cả các AS
trên Internet biết về mạng con này và biết cách đến nó. Nếu không,
mạng con đó sẽ bị cô lập một mình và không được biết trên Internet.
Các vấn đề cơ bản về BGP
BGP rất phức tạp, rất nhiều cuốn sách dành riêng cho chủ đề này và
nhiều vấn đề vẫn chưa được sáng tỏ. Hơn nữa, thậm chí sau khi đọc
các sách về BGP và RFC của nó, chúng ta có thể gặp rất nhiều khó
khăn để hiểu đầy đủ BGP khi không thực hành nó trong nhiều tháng
như một người thiết kế hay quản trị của một ISP cấp cao. Hơn nữa,
bởi vì BGP được xem là giao thức chính cho Internet, về căn bản, nó
là giao thức mà gắn kết lại mọi thứ với nhau – chúng ta cần phải hiểu
ít nhất về cách làm việc của nó như thế nào. Chúng ta sẽ bắt đầu bằng
việc làm cách nào BGP có thể làm việc được sử dụng xét trên mạng
đơn giản mà đã tìm hiểu trước đó ở Hình 4.32.
Trong BGP, các cặp bộ định tuyến chuyển thông tin định tuyến qua lại
sử dụng các kết nối TCP với cổng 179. Các kết nối TCP cho mạng
trong hình 4.32 được chỉ ra trong hình 4.40. Có một kết nối TCP BGP
như vậy cho mỗi liên kết kết nối trực tiếp giữa các bộ định tuyến trong
2 AS khác nhau, vì vậy, trong hình 4.40, có một kết nối TCP giữa bộ
388
định tuyến cổng 3a và 1c và kết nối TCP khác giữa bộ định tuyến
cổng 1b và 2a. Tuy nhiên, cũng có các kết nối TCP BGP giữa các bộ
định tuyến bên trong một AS. Thực tế, hình 4.40 cho thấy các kết nối
TCP cho mỗi cặp của các bộ định tuyến bên trong một AS, tạo ra một
mạng lưới các kết nối TCP bên trong
Hình 4.40 – Các phiên eBGP và iBGP

Đối với mỗi kết nối TCP, hai bộ định tuyến tại cuối của kết nối được
gọi là các bộ định tuyến BGP ngang hang (BGP peer), và kết nối TCP
cùng với các các thông điệp BGP được gửi trên kết nối đó được gọi là
một phiên BGP (BGP session). Hơn nữa, một phiên BGP mở rộng ở 2
AS được gọi là một phiên BGP ngoại vi (external BGP – eBGP
session), và một phiên BGP giữa các bộ định tuyến trong cùng AS gọi
là phiên nội vi BGP(internal BGP – eBGP session). Hình 4.40, các
phiên eBGP được được biểu diễn bằng các dấu chấm dài, các phiên
iBGP được chỉ ra với các dấu chấm ngắn. Chú ý rằng, các dòng chỉ
các phiên BGP trong hình 4.40 không luôn luôn giống với các liên kết
vật lí trong hình 4.32
389
BGP cho phép mỗi AS học các con đường có thể đến được thông qua
các AS láng giềng. Trong BGP, các đích không phải là các host mà là
một tiếp đầu ngữ (prefix) đã được chia nhỏ (CIDR), với mỗi tiếp đầu
ngữ đại diện cho một mạng con hay tập thợp các mạng con. Vì vậy, ví
dụ, giả sử có 4 mạng con bên trong AS2: 138.15.64/24, 138.16.65/24,
138.16.66/24 và 138.16.67/24. AS2 sau đó có thể kết hợp các tiếp đầu
ngữ này cho 4 mạng con trên và sử dụng BGP để quảng bá 1 tiếp đầu
ngữ 138.16.64/22 cho AS1. Một ví dụ khác, giả sử rằng chỉ có 3 mạng
con đầu tiên trong 4 mạng con này trong AS1, và mạng con thứ 4,
138.16.67/24 trong AS2. Khi đó, bởi vì các bộ định tuyến sử dụng
việc ánh xạ với tiếp đầu ngữ dài nhất (longest prefix matching) cho
việc chuyển gói tin, AS3 có thể quảng bá đến AS1 tiếp đầu ngữ chi
tiết hơn 138.16.67 và AS2 có thể vẫn quảng bá đến AS1 tiếp đầu ngữ
đã được kết hợp lại 138.16.64/22
Giờ chúng ta hãy tìm hiểu làm cách nào BGP phân phối các thông tin
tiếp đầu ngữ có thể đến được trên các phiên BGP như trên hình 4.40.
Sử dụng phiên eBGP giữa bộ định tuyến 3a và 1c, AS2 gửi cho AS1
danh sách các tiếp đầu ngữ mà có thể đến được từ AS2, và AS1 gửi
AS3 danh sách các tiếp đầu ngữ mà có thể đến được thông qua bộ
định tuyến 1b và 2a. Khi một bộ định tuyến trong bất kì AS nào nhận
các tiếp đầu ngữ học được từ eBGP, các bộ định tuyến sử dụng các
phiên iBGP để phân phối các tiếp đầu ngữ cho các bộ định tuyến trong
AS đó. Vì vậy, tất cả các bộ định tuyến bên trong AS1 học về các tiếp
đầu ngữ của AS2, bao gồm cả bộ định tuyến 1b. Bộ định tuyến 1b
trong AS1 vì vậy có thể quảng bá lại các tiếp đầu ngữ của AS3 cho
AS2. Khi một bộ định tuyến học một tiếp đầu ngữ mới, nó tạo một
dòng cho tiếp đầu ngữ đó trong bảng chuyển tiếp, như được mô tả
trong phần 4.5.3.
Các thuộc tính đường đi trong BGP
Tới thời điểm này chúng ta đã hiểu cơ bản về BGP, hãy đi vào tìm
hiểu sâu hơn về giao thức này. Trong BGP, một hệ thống tự trị được
định danh bởi một con số hệ thống tự trị toàn cục duy nhất
(autonomous system number - ASN). Về mặt kĩ thuật, không phải moi
AS đều có ASN. Thực tế, một số AS gọi là AS cuối cùng mà chỉ mang
lưu lượng đến và đi từ nó sẽ không có một ASN; chúng ta sẽ bỏ qua
390
các chi tiết về kĩ thuật trong phần thảo luận này để hiểu rõ hơn về
BGP. Các số AS, giống như địa chỉ IP, được gán bởi ICANN.
Khi một bộ định tuyến quảng bá một tiếp đầu ngữ sử dụng một phiên
BGP, nó bao gồm một số thuộc tính BGP của tiếp đầu ngữ. Trong
thuật ngữ BGP, một tiếp đầu ngữ cùng với các thuộc tính của nó gọi là
một đường đi (route). Vì vậy, các BGP peer quảng bá các đường đi
lẫn nhau. Hai thuộc tính quan trọng hơn cả là AS-PATH và NEXT-
HOP:
▪ AS-PATH. Thuộc tính này chứa các AS mà các quảng bá tiếp đầu
ngữ đi qua. Khi một tiếp đầu ngữ được chuyển vào một AS, AS
thêm ASN của nó vào thuộc tính AS-PATH. Ví dụ, xem hình
4.40 và giả sử rằng tiếp đầu ngữ 138.16.64/24 được quảng bá đầu
tiên từ AS2 sang AS1; nếu AS1 quảng bá tiếp đầu ngữ sang AS3,
AS-PATH sẽ là AS2 AS1. Các bộ định tuyến sử dụng thuộc tính
AS-PATH để phát hiện và ngăn các vòng lặp các quảng bá; cụ thể
hơn, nếu một bộ định tuyến thấy chính nó có trong danh sách
đường đi, nó sẽ loại bỏ quảng bá này. Chúng ta sẽ sớm thảo luận,
các bộ định tuyến cũng sử dụng thuộc tính AS-PATH trong việc
lựa chọn đường đi tốt nhất trong số nhiều đường đến cùng một
tiếp đầu ngữ.
▪ Cung cấp một sự liên kết giữa các giao thức định tuyến bên trong
một AS và giữa các AS, NEXT-HOP là một thuộc tính quan
trọng. NEXT-HOP là giao diện (interface) của bộ định tuyến bắt
đầu AS-PATH. Để có thể hiểu sâu hơn thuộc tính này, hãy xem
lại hình 4.40. Xem xét điều gì xảy ra khi bộ định tuyến ngõ ra
(gateway router) 3a trong AS3 quảng bá một đường đi đến bộ
định tuyến ngõ ra 1c trong AS1 sử dụng eBGP. Con đường bao
gồm tiếp đầu ngữ quảng bá, chúng ta gọi là x, và một AS-PATH
cho tiếp đầu ngữ đó. Quảng bá này cũng bao gồm NEXT-HOP,
địa chỉ IP của giao diện bộ định tuyến 3a mà dẫn tới 1c. (Nhớ
rằng một bộ định tuyến có nhiều địa chỉ IP, một địa chỉ IP cho
một giao diện của nó). Bây giờ hay xem điều gì xảy ra khi bộ
định tuyến 1d học về đường này từ iBGP. Sau khi học về đường
này đến x, bộ định tuyến 1d có thể muốn chuyển các gói tin tới x
theo đường này, vì vậy bộ định tuyến 1d có thể muốn đưa dòng
(x,l) trong bảng chuyển tiếp của nó, với l là giao diện của nó bắt
391
đầu con đường đi ngắn nhất từ 1d đến bộ định tuyến 1c. Để xác
định l, 1d cung cấp địa chỉ IP trong thuộc tính NEXT-HOP cho
phần định tuyến bên trong AS của nó. Chú ý rằng, giao thức định
tuyến bên trong AS xác định lộ trình chi phí ngắn nhất đến tất cả
các mạng con có kết nối với các bộ định tuyến trong AS1, bao
gồm cả mạng con giữa liên kết giữa 1c và 3a. Từ lộ trình ngắn
nhất từ 1d đến mạng con 1c-3a, 1d xác định giao diện bộ định
tuyến l để bắt đầu con đường này và thêm dòng (x,l) vào bảng
chuyển tiếp của nó.
Hình 4.41 – Thuộc tính NEXT-HOP trong quảng bá đường đi được

sử dụng để xác định liên kết ngang hàng nào được sử dụng.
▪ Hình 4.41 minh họa tình huống khác mà việc sử dụng AS-PATH
là cần thiết. Trong hình này, AS1 và AS2 kết nối trực tiếp bởi các
liên kết ngang hàng. Một bộ định tuyến trong AS1 có thể học 2
đường khác nhau đến cùng tiếp đầu ngữ x. Hai đường này có thể
392
có cùng AS-PATH tới x, nhưng có thể có các giá trị NEXT-HOP

khác nhau cho các đường ngang hàng khác nhau. Sử dụng các giá
trị AS-PATH và giải thuật định tuyến bên trong AS, bộ định
tuyến có thể xác dịnh chi phí con đường đến mỗi liên kết ngang
hàng, và sau đó sử dụng giải thuật hot-potato (4.5.3) để xác định
cổng giao diện thích hợp.
BGP cũng có các thuộc tính cho phép các bộ định tuyến gán các độ đo
tham chiếu (preference metric) cho các đường, và một thuộc tính chỉ
ra cách tiếp đầu ngữ được đưa vào BGP tại AS gốc. Để hiểu hơn về
các thuộc tính đường, hãy tìm hiểu.
Khi một bộ định ngõ ra tuyến nhận một quảng bá từ bộ định tuyến
khác, nó sử dụng các chính sách đi vào (import policy) để xác định
cho phép hay lọc đường này và có thiết lập một thuộc tính nào đó hay
không ví dụ như các độ đo tham chiếu cho quảng bá này. Chính sách
đi vào có thể lọc một đường đi bởi vì AS có thể không muốn gửi dữ
liệu qua một AS mà nằm trong AS-PATH của đường đi. Bộ định
tuyến cũng có thể lọc con đường bởi vì nó đã biết con đường khác tốt
hơn đến cùng tiếp đầu ngữ.
Lựa chọn đường BGP
Như được thảo luận trước đây trong phần này, BGP sử dụng eBGP và
iBGP để phân phối các con đường cho các bộ định tuyến khác trong
các AS. Từ sự phân phối này, một bộ định tuyến có thể biết về nhiều
hơn một đường đến cùng một tiếp đầu ngữ, vì vậy bộ định tuyến phải
lựa chọn một trong các con đường có khả năng trên. Đầu vào của qui
trình lựa chọn đường này là một tập các đường được học và cho phép
bởi bộ định tuyến. Nếu có hai hay nhiều đường đến cùng tiếp đầu ngữ,
BGP sử dụng các luật để loại bỏ cho đến khi nào chỉ còn lại một
đường
▪ Các con đường được gán với một giá trị tham chiếu cục bộ (local
preference) như một trong những thuộc tính của nó. Tham chiếu
cục bộ của một con đường có thể được thiết lập bởi bộ định tuyến
hoặc có thể học từ một bộ định tuyến khác trong cùng AS. Đây là
một quyết định chính sách dành cho người quản trị mạng của AS.
Các con đường với giá tham chiếu cục bộ cao nhất được lựa chọn.
393
▪ Từ những đường còn lại (cả những đường với cùng giá trị tham
chiếu cục bộ), con đường với AS-PATH ngắn nhất được lựa
chọn. Nếu luật này là luật duy nhất cho việc lựa chọn đường, thì
BGP sẽ sử dụng một thuật giải DV cho việc lựa chọn đường đi
với độ đo khoảng cách sử dụng số lượng các AS đi qua chứ
không phải là số lượng các bộ định tuyến đi qua.
▪ Đối với những đường còn lại (tất cả đường với cùng giá trị tham
chiếu cục bộ hay cùng chiều dài AS-PATH), con đường với bộ
định tuyến NEXT-HOP gần nhất được lựa chọn. Ở đây, gần nhất
có nghĩa là bộ định tuyến có chi phí đường đi thấp nhất xác định
bởi giải thuật bên trong AS. Như được thảo luận ở phần 4.5.3, qui
trình này được gọi là định tuyến quả táo nóng.
Các luật để loại bỏ thậm chí phức tạp hơn nhiều so với mô tả ở trên.
Tuy nhiên, trong cuốn sách này, chúng ta chỉ tìm hiểu những luật lựa
chọn BGP chính.
Chính sách định tuyến
Chúng ta hãy minh họa một số khái niệm cơ bản về chính sách định
tuyến BGP với một ví dụ đơn giản. Hình 4.43 minh họa 6 hệ thống tự
trị kết nối với nhau: A, B, C, W, X và Y. Chú ý là A, B, C, W, X và Y
là các AS, không phải là các bộ định tuyến. Chúng ta hãy giả định
rằng các hệ thống tự trị W, X, và Y là các mạng chỉ có một lối ra và
A, B, C là các mạng cung cấp mạng xương sống (backbone). Chúng ta
cũng giả định rằng A, B và C, tất cả là ngang hàng với nhau và cung
cấp thông tin BGP đầy đủ cho các mạng khách hàng của chúng.
B Ghi chú:
X Mạng nhà cung cấp
W A Mạng khách hàng
C
Y
Hình 4.42 – Kịch bản BGP đơn giản
394
Tất cả lưu lượng mạng đi vào một mạng cuối (stub network) phải
được hướng đích tới mạng đó, và tất cả các lưu lượng mạng đi ra từ
mạng cuối phải xuất phát từ mạng đó. W và Y rõ ràng là các mạng
cuối. X là mạng cuối có nhiều đường ra vì nó kết nối với toàn mạng
qua 2 nhà cung cấp khác nhau. Tuy nhiên, giống như W và Y, chính X
phải là nguồn/đích của tất cả các lưu lương mạng ra/vào X. Nhưng
làm thế nào các hành động của mạng cuối này được thực thi? X sẽ làm
cách nào để ngăn ngừa việc chuyển dữ liệu từ B và C. Điều này có thể
được thực hiện bởi việc điều khiển cách mà các đường BGP được
quảng bá. Thực tế, X sẽ hoạt động như một mạng cuối nếu nó quảng
bá (cho láng giềng B, C của nó) rằng nó không có bất kì con đường
nào đến các mạng khác ngoài chính nó. Khi đó, thậm chí X biết con
đường, ví dụ XCY, để đến mạng Y, nó cũng sẽ không quảng bá con
đường này đến B. Bởi vì B không biết rằng X có con đường tới Y, B
sẽ không bao giờ chuyển lưu lượng có đích là Y hoặc C qua X. Ví dụ
đơn giản này minh họa một chính sách quảng bá có thể được sử dụng
để thực hiện các mối quan hệ định tuyến khách hàng/nhà cung cấp.
Giờ hãy tập trung vào một mạng cung cấp, ví dụ AS B. Giả sử rằng B
đã học (từ A) rằng A có một đường AW đến W. B sau đó có thể cài
đặt con đường BAW vào bảng định tuyến của nó. Rõ ràng, B cũng
muốn quảng bá con đường BAW cho các khách hàng của nó, X, để X
biết rằng nó có thể đến W thông qua B. Nhưng B có nên quảng bá con
đường BAW tới C? Nếu điều này xảy ra, thì C có thể định hướng lưu
lượng đến W qua CBAW. Nếu A, B và C là các nhà cung cấp mạng
xương sống, thì B sẽ cảm thấy rằng nó không việc gì phải chuyển các
lưu lượng giữa A và C. B nghĩ rằng đó là chuyện của A và C để chắc
rằng C có thể hướng đến/ đi từ các khách hàng của A thông qua một
kết nối trực tiếp từ A và C. Hiện tại không có các chuẩn chính thức
nào để quản lí việc các nhà cung cấp dịch vụ xương sống hướng các
đường giữa chúng. Tuy nhiên, một luật mà được sử dụng bởi các nhà
cung cấp dịch vụ thương mại là bất kì lưu lượng mạng nào đi qua một
mạng xương sống của nhà cung cấp dịch phải có nguồn hay có đích là
các khách hàng của nhà cung cấp dịch đó, nếu không lưu lượng sẽ bị
hủy trong mạng ISP. Việc thỏa thuận ngang hàng được đàm phán giữa
các cặp nhà cung cấp dịch vụ với nhau và thường là bí mật.
395
Như đã được trình bày ở trên, BGP là chuẩn chính cho việc định tuyến
giữa các AS cho Internet. Để xem nội dung của các bảng định tuyến
BGP từ các bộ định tuyến trong tier-1 ISP, xem
http://www.routeviews.org. Các bản định tuyến BGP thường chứa
hàng ngàn tiếp đầu ngữ và các thuộc tính tương ứng.
VII. Định tuyến broadcast và multicast

Tới thời điểm này, chúng ta chỉ tập trung vào các giao thức định tuyến
hỗ trợ giao tiếp unicast, một nút nguồn gửi một gói dữ liệu đến một
nút đích đơn. Trong phần này, chúng ta sẽ xem xét các giao thức định
tuyến multicast và broadcast. Trong định tuyến broadcast, tầng Mạng
cung cấp một dịch vụ phân phối một gói dữ liệu gửi từ một nút tới tất
cả các nút trên mạng, định tuyến multicast cho phép một nút nguồn
gửi một bản sao chép của gói tin tới một phần các nút trong mạng.
Trong phần 4.7.1, chúng ta sẽ tìm hiểu lí thuyết các giao thức định
tuyến broadcast và hiện thực của nó trong các giao thức định tuyến.
Chúng ta sẽ tìm hiểu định tuyến multicast trong phần 4.7.2
VII.1 Định tuyến broadcast
Có lẽ, cách đơn giản nhất để thực hiện giao tiếp broadcast là nút gửi
gửi một bản sao chép của gói tin tới mỗi đích, như được chỉ ra ở Hình
4.43. Cho N nút đích, nút nguồn chỉ đơn giản tạo N bản sao của gói Commented [c
tin, ghi địa chỉ của mỗi bản sao chép cho các đích khác nhau và
chuyển N bản sao chép tới N đích sử dụng định tuyến unicast. Cách
tiếp cận N-unicast cho việc broadcast là đơn giản – không cần giao
thức định tuyến lớp mạng mới, chức năng nhân bảng hay chuyển tiếp.
Tuy nhiên, có vài hạn chế cho cách tiếp cận này. Hạn chế đầu tiên là
tính không hiệu quả của nó. Nếu nút nguồn kết nối với tất cả mạng
qua một đường liên kết đơn, thì N bản sao chép của gói tin sẽ chỉ đi
theo đường liên kết này. Rõ ràng sẽ hiệu quả hơn để gửi chỉ một gói
tin trên bộ định tuyến đầu tiên và sau đó nhờ các nút phía bên kia của
bộ định tuyến đầu tiên tạo và chuyển các bản sao chép cần thiết. Vì
vậy, cách tiếp cận này có thể mang lại hiệu quả nhiều hơn cách mà nút
nguồn tạo ra nhiều bản sao chép của gói tin. Ví dụ, trong Hình 4.43
(b), chỉ một bản sao chép của gói tin truyền trên liên kết R1-R2. Gói
396
tin đó được nhân bản tại R2 với một bản sao chép được gửi trên các
liên kết R2-R3 và R2-R4.
Điểm hạn chế tiếp theo của cách truyền unicast N-đường (N-way
unicast) có lẽ đáng chú ý hơn và không kém phần quan trọng. Một giả
định ngầm định của unicast N đường là các thiết bị nhận broadcast và
các địa chỉ của chúng phải được biết bởi thiết bị gửi. Nhưng làm cách
nào để những thông tin này đạt được. Hầu hết, các giao thức khác sẽ
được yêu cầu sử dụng. Điều này sẽ thêm chi phí nhiều hơn, và quan
trong hơn là nó sẽ tăng độ phức tạp cho một giao thức mà ban đầu
trông có vẻ khá đơn giản. Điểm hạn chế cuối cùng của unicast N
đường liên quan đến các mục đích mà broadcast được sử dụng. Trong
phần 4.5, chúng ta đã học rằng các giao thức định tuyến trạng thái
đường liên kết sử dụng broadcast để chuyển các thông tin trạng thái
đường liên kết được sử dụng để tính toán các đường unicast. Rõ ràng,
trong các tình huống broadcast được sử dụng để tạo và cập nhật các
đường unicast, sẽ không khôn ngoan khi tin cậy vào cơ sở hạ tầng
định tuyến unicast để thực thi việc broadcast.
Nhân bản/chuyển gói tin
R1
R1 Nhân bản
R2
Nhân bản
R2
R3
R3 R4 R4
b.
a.
Hình 4.43 – Nhân bản tại nguồn so với nhân bản trong mạng
Bởi một số hạn chế của broadcast theo kiểu N-đường unicast ở trên,
các cách tiếp cận mà chính các nút đóng vai trò chủ động trong việc
nhân bản gói tin, chuyển tiếp gói tin và tính toán các con đường
397
broadcast rõ ràng rất thú vị. Chúng ta sẽ tìm hiểu vài cách tiếp cận như
vậy bên dưới và một lần nữa quay lại khái niệm đồ thị được trình bày
ở phần 4.5. Chúng ta một lần nữa mô hình mạng như một đồ thị,
G=(N,E), với N là tập các nút và tập hợp E các cạnh, với mỗi cạnh là
một cặp các nút trong N. Chúng sẽ sử dụng N cho tập các nút hay kích
thước của đồ thị.
Làm ngập không kiểm soát (Uncontrolled flooding)
Kĩ thuật rõ ràng nhất cho việc thực hiện broadcast là cách tiếp cận tràn
ngập (flooding) bằng việc nút nguồn gửi một bản sao của gói tin cho
tất cả các láng giềng của nó. Khi một nút nhận được một gói tin
broadcast, nó sẽ nhân bản gói tin và chuyển cho các láng giềng ngoại
trừ láng giềng mà nó nhận gói tin đó. Rõ ràng, nếu đồ thị là kết nối Commented [c
(connected), kĩ thuật này sẽ dần dần chuyển một bản sao của gói tin
broadcast tới tất cả các nút trên đồ thị. Mặc dù kĩ thuật này khá đơn
giản nhưng nó cũng có vài điểm yếu: Nếu đồ thị có vòng thì một hoặc
nhiều bản sao của gói tin broadcast sẽ xoay vòng vô hạn. Ví dụ, trong
Hình 4.43, R2 sẽ làm ngập tràn tới R3, R3 sẽ làm ngập tràn tới R4, R4
sẽ làm ngập tràn tới R2, và R2 sẽ lần nữa làm ngập tràn tới R3, và tiếp
tục…Với cách gửi như thế, kết quả là sẽ tạo ra một vòng lặp vô tận
của 2 gói tin broadcast, một theo chiều kim đồng hồ và một theo
ngược kim đồng hồ. Nhưng thậm chí có thể xuất hiện điều tồi tệ hơn:
Khi một nút được kết nối tới 2 hay nhiều nút khác nó sẽ tạo ra và
chuyển nhiều bản sao của gói tin broadcast, mỗi gói tin này sẽ tạo ra
nhiều gói tin khác…và tiếp tục vậy tạo ra bão broadcast. Bão
broadcast, kết quả từ việc nhân bản vô hạn các gói tin broadcast sẽ
dần dần tạo ra quá nhiều gói tin broadcast trong mạng.
Ngập tràn có kiểm soát (Controlled flooding)
Chìa khóa để tránh trường hợp bão broadcast là để cho một nút quyết
định khi nào tràn ngập một gói tin và khi nào không làm tràn ngập gói
tin. Trong thực tế, có một vài cách để thực hiện việc này.
Trong ngập tràn kiểm soát theo số thứ tự (sequence-number-controlled
flooding), một nguồn thêm vào địa chỉ của nó( hay một định danh duy
nhất ) cũng như một số thứ tự broadcast (broadcast sequence number)
vào gói tin broadcast, sau đó gửi gói tin này cho các láng giềng của
398
nó. Mỗi nút duy trì một danh sách các địa chỉ nguồn và số thứ tự của
mỗi gói tin broadcast được được nhận hay được chuyển đi. Khi một
nút nhận một gói tin broadcast, đầu tiên nó kiểm tra xem gói tin có
nằm trong danh sách hay chưa. Nếu có, gói tin sẽ bị hủy, nếu không
gói tin sẽ được nhân bản và chuyển cho các láng giềng của nút đó
(ngoại trừ nút mà nó nhận gói tin). Giao thức Gnutella, được thảo luận
ở Chương 2, sử dụng ngập tràn kiểm soát theo số thứ tự để broadcast
các câu truy vấn trên mạng chồng (overlay) của nó. (Trong Gnutella,
việc nhân bản thông tin và việc chuyển thông tin được thực hiện tại
tầng Ứng dụng hơn là tại tầng Mạng).
Cách tiếp cận thứ hai cho việc tràn ngập có kiểm soát là chuyển gói
tin theo đường ngược lại (reverse path forwarding - RPF), đôi khi
cũng được gọi là broadcast theo đường ngược lại. Ý tưởng bên dưới
RPF khá đơn giản. Khi một bộ định tuyến nhận một gói tin broadcast
với một địa chỉ nguồn cho trước, nó chuyển gói tin ra tất cả các cổng
đầu ra (ngoại trừ cổng mà nó nhận gói tin) chỉ nếu gói tin đến trên một
liên kết mà nằm trên con đường ngắn nhất tới nguồn. Ngược lại, bộ
định tuyến sẽ hủy gói tin đến mà không chuyển đi đâu cả. Các gói tin
như vậy có thể bị hủy bởi bộ định tuyến biết chúng có thể sẽ nhận
hoặc đã nhận một bản sao chép của gói tin này trên đường liên kết
thuộc về con đường ngắn nhất đến nơi gửi. Lưu ý rằng, RPF không sử
dụng định tuyến unicast để chuyển gói tin tới một đích, nó không yêu
cầu rằng một bộ định tuyến biết toàn bộ con đường ngắn nhất từ nó
đến nguồn. RPF chỉ cần biết láng giềng tiếp theo trên con đường ngắn
nhất của nó tới thiết bị gửi, nó sử dụng hiểu biết này chỉ để xác định
có làm tràn ngập hay không một gói tin broadcast nhận được.
Hình 4.44 minh họa RPF. Giả sử rằng các liên kết được vẽ với các
đường đậm cho biết các con đường ngắn nhất từ thiết bị nhận tới
nguồn A. Nút A ban đầu gửi broadcast một gói tin nguồn là A tới nút
C và B. Nút B sẽ chuyển gói tin nguồn là A mà nó nhận được từ A
(bởi vì A nằm trên con đường ngắn nhất tới A) tới cả C và D. B sẽ hủy
gói bất kì gói tin có nguồn là A nó nhận được từ bất kì nút nào khác
(ví dụ, từ bộ định tuyến C hay D). Giờ chúng ta hãy xem nút C, nút sẽ
nhận một gói tin nguồn là A trực tiếp từ A cũng như từ B. Bởi vì B
không nằm trên đường ngắn nhất của C tới A, C sẽ hủy bất kì gói tin
có nguồn là A mà nó nhận từ B. Nói cách khác, khi C, khi C nhận
399
được một gói tin nguồn là A trực tiếp từ A, nó sẽ chuyển gói tin tới
nút B, E, và F.
F E
G
Ghi chú:
Gói tin sẽ được chuyển
Gói tin không được chuyển về phía bộ định tuyến
Hình 4.44 – Chuyển theo đường ngược lại

Broadcast theo cây mở rộng (Spanning-Tree Broadcast) Commented [c
Khi kĩ thuật ngập tràn kiểm soát theo số thứ tự và RPF có thể tránh
được các bão broadcast, chúng không thể tránh hoàn toàn sự tồn tại
của các gói tin broadcast dư thừa. Ví dụ, trong hình 4.45, nút B, C, D,
E và F nhận một hay hai gói tin dư thừa. Lí tưởng nhất, mỗi nút nên
chỉ nhận một bản sao của gói tin broadcast. Hãy nhìn cây bao gồm các
nút nối trực tiếp bởi các đường đậm trong hình 4.45, chúng ta có thể
thấy rằng nếu các gói tin broadcast được chuyển chỉ trên các đường
trong cây này, tất cả các nút sẽ nhận được chính xác một bản sao của
gói tin broadcast, chính xác giải pháp mà chúng ta đang tìm kiếm. Cây
này là một ví dụ của cây mở rộng – một cây mà chứa mọi nút trên một
đồ thị. Một cây mở rộng của đồ thị G=(N,E) là một đồ thị G’ = (N,E’)
mà E’ là tập con của E, G’ là đồ thị liên tục (connected), G’ không
chứa vòng và G’ chứa tất cả các nút gốc trong G. Nếu mỗi đường liên
kết có một chi phí và chi phí của một cây là tổng của chi phí các
đường liên kết, thì chi phí của một cây mở rộng là giá trị nhỏ nhất của
tất cả các cây mở rộng của đồ thị và được gọi là cây mở rộng nhỏ
nhất.
400
Vì vậy, một cách tiếp cận khác để cung cấp broadcast là cho các nút
mạng xây dựng một cây mở rộng. Khi một nút nguồn muốn gửi một
gói tin broadcast, nó gửi gói tin ra các đường thuộc cây mở rộng. Một
nút nhận một gói tin quảng bá sẽ chuyển gói tin đó cho tất cả các láng
giềng của nó trong cây mở rộng (ngoại trừ láng giềng mà nó nhận
được gói tin đó). Cây mở rộng không chỉ loại bỏ được các gói tin
broadcast dư thừa mà có thể được sử dụng bởi bất kì nút nào để bắt
đầu một broadcast, như được chỉ ra ở hình 4.45 (a) và 4.45( b). Chú ý
rằng một nút không cần biết toàn bộ cây, nó chỉ cần biết láng giềng
nào của nó trong đồ thị G là các láng giềng cây mở rộng.
A
A
B B
C C
D D
F E E
G F
G
a. Broadcast khởi tạo ở A b. Broadcast khởi tạo ở D
Hình 4.45 – Broadcast với cây mở rộng

Độ phức tạp chính liên quan tới cách tiếp cận cây mở rộng là việc tạo
và duy trì của cây mở rộng. Rất nhiều giải thuật cây mở rộng phân tán
được phát triển. Chúng ta chỉ xem một giải thuật đơn giản ở đây.
Trong cách tiếp cận dựa vào trung tâm (center-based approach) để xây
dựng một cây mở rộng, một nút trung tâm được định nghĩa. Các nút
sau đó truyền unicast các thông điệp tham gia vào cây (tree-join) đến
nút trung tâm. Một thông điệp tham gia vào cây sử dụng định tuyến
unicast để chuyển đến trung tâm cho đến khi nó nhận tại một nút mà
401
đã thuộc vào cây mở rộng hay đến trung tâm. Trong trường hợp khác,
con đường mà thông điệp gia nhập cây đi qua định nghĩa nhánh của
cây mở rộng giữa nút cạnh mà khởi tạo thông điệp gia nhập cây và
trung tâm. Người ta có thể nghĩ con đường mới này như được gép vào
cây cây mở rộng hiện tại.
Hình 4.46 minh họa quá trình xây dựng của cây dựa vào trung tâm.
Giả sử rằng nút E được lựa chọn như là trung tâm của cây. Giả sử rằng
nút F đầu tiên tham gia vào cây và chuyển thông điệp gia nhập cây
đến E. Đường liên kết EF trở trở thành cây mở rộng đầu tiên. Nút B
sau đó tham gia vào cây mở rộng bằng gửi thông điệp tham gia vào
cây của nó tới E. Giả sử rằng con đường đến E từ B đi qua D. Trong
trường hợp này, thông điệp tham gia cây sẽ làm cho con đường BDE
trở thành một nhánh trong cây mở rộng. Nút A sau đó tham gia vào
cây mở rộng bằng chuyển thông điệp tham gia cây của nó về E. Nếu
đường unicast của A đến E đi qua B, thì vì B đã tham gia vào cây mở
rộng, việc thông điệp tham gia cây đi qua B từ A sẽ làm cho đường
AB trở thành nhánh trong cây.
A A
3
B B
C C
4
2
D D
E 5
F E
1 G F
G
a. Các bước xây dựng cây mở rộng b. Cây mở rộng sau khi xây dựng
Hình 4.46 – Việc xây cây mở rộng dựa vào trung tâm
Nút C tham gia vào cây mở rộng bằng việc chuyển thông điệp tham
gia cây trực tiếp đến E. Cuối cùng, bởi vì giải thuật định tuyến unicast
cho biết từ G đến E phải qua D, khi G gửi thông điệp tham gia cây đến
E, và đường GD là một nhánh của cây mở rộng tại nút D.
402
Giải thuật broadcast trong thực tế

Các giải thuật broadcast được sử dụng trong thực tế ở tầng Ứng dụng
và tầng Mạng. Gnutella sử dụng broadcast ở tầng Ứng dụng để
broadcast các truy vấn nội dung cho các Gnutella ngang hàng. Ở đây,
một liên kết giữa hai tiến trình ngang hàng tầng Ứng dụng trong mạng
Gunetlla sử dụng một kết nối TCP. Gnutella sử dung một hình thức
làm ngập tràn số thứ tự có kiểm soát với một định danh 16 bit và 16
bit dữ liệu (payload) mô tả (dùng định danh loại thông điệp Gnutella)
được sử dụng để phát hiện có hay không truy vấn broadcast nhận được
đã được nhận, nhân bản hay chuyển đi. Gnutella cũng sử dụng một
trường Time-to-live (TTL) để giới hạn số lượng các hop một truy vấn
được chuyển qua. Khi tiến trình Gnutell nhận và nhân bản một truy
vấn, nó giảm trường TTL trước khi chuyển truy vấn đi. Vì vây, kĩ
thuật làm ngập tràn của Gnutella thỉnh thoảng được xem như kĩ thuật
làm ngập tràn giới hạn phạm vi (limited-scope flooding).
Một hình thức của làm ngập tràn có kiểm soát số thứ tự cũng được sử
dụng để quảng bá các thông tin quảng bá đường liên kết (LSAs) trong
giải thuật định tuyến OSPF và IS-IS. OSPF sử dụng một số thứ tự 32
bít và một trường age 16 bit để nhận dạng LSAs. Nhắc lại, một nút
OSPF quảng bá các LSA cho các liên kết trực tiếp với nó định kì khi
chi phí một liên kết đến một láng giềng thay đổi, hoặc khi một liên kết
bị hỏng hoặc phục hồi lại. Các số thứ tự LSA được sử dụng để phát
hiện các gói LSA bị trùng, nhưng cũng phục vụ một chức năng quan
trọng trong OSPF. Với việc làm ngập tràn, có khả năng một LSA phát
sinh bởi nguồn tại thời điểm t đến sau một LSA mới hơn mà phát sinh
bởi cùng nguồn tại thời gian t+x. Các số thứ tự sử dụng bởi nút nguồn
cho phép một LSA cũ hơn phân biệt với một LSA mới hơn. Trường
age phục vụ mục đích giống như trường TTL. Giá trị trường age đầu
tiên được thiết lập là zero và tăng dần tại mỗi hop mà nó làm ngập
tràn, và cũng được tăng khi nó nằm trong bộ nhớ bộ định tuyến chờ để
làm ngập tràn. Mặc dù chúng ta chỉ mô tả ngắn gọn giải thuật làm
ngập LSA ở đây, chúng ta lưu ý rằng việc thiết kế các giao thức
broadcast LSA có thể có nhiều mưu mẹo hơn. [RFC 789] mô tả một
tình tiết mà các gói tin LSA được chuyển tiếp không đúng bởi 2 bộ
định tuyến bị lỗi chức năng có thể làm cho một phiên bản trước đây
của giải thuật tràn ngập LSA làm sụp toàn bộ mạng ARPAnet.
403
VII.2 Định tuyến multicast

Chúng ta tìm hiểu ở phần trước với dịch vụ broadcast, gói tin được gửi
tới mọi nút trên mạng. Trong phần này, chúng ta sẽ tìm hiểu dịch vụ
multicast, dịch vụ mà một gói tin multicast được chuyển đến chỉ một
phần của các nút mạng. Một số các ứng dụng mạng yêu cầu việc
chuyển gói tin từ một hoặc nhiều thiết bị gửi đến một nhóm các thiết
bị nhận. Những ứng dụng này bao gồm việc chuyển một phần dữ liệu
(ví dụ, chuyển phần dữ liệu nâng cấp phần mềm từ nhà phát triển
phầm mềm đến các người sử dụng cần nâng cấp), chuyển các
audio/video liên tục (ví dụ, chuyển audio, video và text của một bải
giảng trực tuyến cho một nhóm người nghe), các ứng dụng chia sẻ dữ
liệu ( ví dụ, hội nghị truyền thông mà được chia sẻ trong số các người
tham gia phân tán..)…
Trong giao tiếp multicast, chúng ta phải đối mặt với 2 vấn đề: làm sao
để biết được các thiết bị nhận của gói tin multicast và làm thế nào để
định địa chỉ gói tin được gửi đến các thiết bị nhận này. Trong trường
hợp của giao tiếp unicast, địa chỉ IP đích của thiết bị nhận được mang
trong mỗi gói tin IP và nhận diện một thiết bị nhận duy nhất; trong
trường hợp broadcast, tất cả các nút cần nhận gói tin, vì thế không cần
các địa chỉ đích. Như trong trường hợp của multicast, chúng ta có
nhiều thiết bị nhận. Có hợp lí hay không khi mỗi gói tin multicast
mang địa chỉ IP của tất cả các thiết bị nhận? Trong khi cách tiếp cận
này có thể làm việc với một số lượng nhỏ thiết bị nhận nhưng không
hiệu quả trong trường hợp có hàng trăm hay hàng ngàn thiết bị nhận,
khi số lượng thông tin địa chỉ trong gói tin có thể vượt qua số lượng
dữ liệu có thể mang trong trường dữ liệu (payload) của gói tin. Sự
định danh rõ ràng của các thiết bị nhận bởi thiết bị gửi cũng yêu cầu
thiết bị gửi biết được định danh và địa chỉ của tất cả các thiết bị nhận.
Với những lí do trên, kiến trúc mạng Internet (và các kiến trúc mạng
khác như ATM), một gói tin multicast được gán địa chỉ sử dụng địa
chỉ vô hướng (address indirection). Đó là một định danh duy nhất
được sử dụng cho một nhóm của thiết bị nhận, và một bản sao của gói
tin được gửi cho định danh duy nhất này được chuyển tới các thiết bị
nhận multicast nằm trong nhóm đó. Trên Intenrnet, định danh đại diện
một nhóm của thiết bị nhận là địa chỉ IP multicast lớp D. Nhóm các
404
thiết bị nhận có địa chỉ chỉ lớp D được xem như là nhóm multicast.
Nhóm multicast được minh họa ở hình 4.47. Ở đây, 4 host cùng trong
một nhóm multicast có địa chỉ 226.17.30.197 và sẽ nhận tất cả các gói
tin mà có địa chỉ đích là địa chỉ mulicast đó. Khó khăn mà chúng ta
phải gặp là mỗi host có một địa chỉ IP unicast duy nhất mà độc lập với
địa chỉ của nhóm multicast mà nó tham gia.
Trong khi việc mô tả nhóm multicast khá đơn giản, có nhiều câu hỏi
được đặt ra cho các host. Làm thế nào một nhóm bắt đầu và kết thúc?
Địa chỉ nhóm được chọn khi nào? Làm thế nào một host mới được
thêm vào nhóm? Bất kì thiết bị nào cũng có thể tham gia vào nhóm
hay sao? Các thành viên của nhóm nhận biết định danh của các thành
viên khác trong nhóm như là một phần của giao thức tầng Mạng hay
không?
128.59.16.20
128.34.108.63
128.119.40.186 Nhóm Mcast

226.17.30.197
128.34.108.60
Key :
Bộ định tuyến nằm trong nhóm
Bộ định tuyến không nằm trong nhóm
Hình 4.47 – Nhóm multicast: Gói dữ liệu gửi tới nhóm sẽ được gửi cho tất
cả các thành viên của nhóm
Làm thế nào các nút mạng có thể làm việc với nhau để chuyển các gói
tin multicast cho cho các thành viên trong nhóm?. Đối với mạng
405
Internet, câu trả lời cho tất cả các câu hỏi trên được trình bày trong
Internet Group Management Protocol [RFC 3376]. Vì thế, chúng ta
hãy xem ngắn gọn IGMP và trở lại với các câu hỏi rộng hơn này sau.
Giao thức Internet Group Management
Giao thức IGMP phiên bản 3 hoạt động giữa một host và bộ định
tuyến gắn trực tiếp với nó (chúng ta có thể nghĩ rằng bộ định tuyến kết
nối trực tiếp như là bộ định tuyến ở hop đầu tiên mà một host sẽ thấy
trên con đường đến bất kì host nào bên ngoài mạng cục bộ của nó, hay
là bộ định tuyến hop cuối cùng trên con đường tới host đó) như được
chỉ ra ở Hình 4.48.
IGMP
IGMP IGMP
Định tuyến multicast
mạng WAN
IGMP
Hình 4.48 – Hai thành phần của multicast tầng Mạng trên Internet:
IGMP và các giao thức định tuyến multicast.
Hình 4.48 chỉ 3 bộ định tuyến multicast, mỗi bộ định tuyến kết nối
trực tiếp với các host của qua các cổng ra cục bộ. Các cổng cục bộ này
được kết nối tới một LAN như trong ví dụ, và trong khi mỗi LAN này
có nhiều host, một số host này sẽ thuộc vào một nhóm multicast cho
trước tại một thời điểm nào đó. IGMP cung cấp các cách thức cho một
host để thông báo bộ định tuyến nó kết nối rằng một ứng dụng chạy
trên host đó muốn tham gia vào một nhóm multicast nào đó. Giả sử sử
phạm vi tương tác IGMP được giới hạn cho một host và bộ định tuyến
kết nối với nó, và giao thức khác rõ ràng được yêu cầu phối hợp với
406
các bộ định tuyến multicast (bao gồm bộ định tuyến kết nối trực tiếp)
trên Internet, để các gói tin multcast được chuyển tới đích của nó.
Chức năng này được thực hiện bởi các giao thức định tuyến multicast
ở tầng Mạng, như giao thức mà chúng ta sẽ tìm hiểu ngắn gọn.
Multicast tầng Mạng trên Internet vì vậy bao gồm 2 thành phần phụ:
IGMP và các giao thức định tuyến multicast.
IGMP có 3 loại thông điệp. Giống như ICMP, các thông điệp IGMP
được mang (đóng gói) bên trong một gói tin IP, với chỉ số IP protocol
là 2. Thông điệp membership_query được gửi bởi một bộ định tuyến
cho tất cả các host kết nối với cổng của nó (ví dụ, tất cả các host trong
một mạng cục bộ) để xác định tập các nhóm multicast được tham gia
bởi các host trên cổng đó. Các host trả lời thông điệp
membership_query với một thông điệp IGMP mebership_report. Các
thông điệp membership_query cũng có thể được phát sinh bởi một
host khi một ứng dụng lần đầu tham gia vào nhóm multicast mà không
chờ thông điệp membership_query từ bộ định tuyến.
Loại cuối cùng của thông điệp IGMP là thông điệp leave_group. Tuy
nhiên, thông điệp này là không bắt buộc. Nhưng nếu nó không bắt
buộc, làm thế nào bộ định tuyến phát hiện một host đã rời khỏi một
nhóm multicast. Câu trả lời cho câu hỏi này là bộ định tuyến cho rằng
một host không có trong nhóm multicast nữa nếu nó không phải hồi
thông điệp membership_query với địa chỉ nhóm cho trước. Đây là một
ví dụ cho thứ mà thỉnh thoảng được gọi là trạng thái mềm (soft state)
trong một giao thức Internet. Trong một giao thức trạng thái mềm,
trạng thái (trong trường hợp này của IGMP, 2 host tham gia vào một
nhóm multicast cho trước) bị xóa bởi một sự kiện hết thời gian định
trước(timeout) (trong trường hợp này, thông qua thông điệp
membership_query định kì từ bộ định tuyến) nếu nó không được làm
mới ( trong trường hợp này, bởi thông điệp membership_report từ một
host).
Giải thuật định tuyến Multicast
Vấn đề định tuyến multicast được minh họa ở Hình 4.49. Các host
tham gia vào nhóm multicast được tô màu, bộ định tuyến gắn trực tiếp
vào nó cũng được tô màu. Như trong hình 4.49, chỉ một phần của các
bộ định tuyến (những bộ định tuyến với các host gắn trực tiếp mà
407
tham gia vào nhóm multicast) thật sự cần nhận dữ liệu multicast.
Trong hình 4.49, chỉ các bộ định tuyến A, B, E và F cần nhận dữ liệu
multicast. Bởi vì không có host nào gắn trực tiếp vào bộ định tuyến D
tham gia vào nhóm multicast và bởi vì C không có host nào gắn trực
tiếp, C và D đều không cần nhận dữ liệu nhóm multicast. Mục đích
của định tuyến multicast là để tìm ra một cây với các liên kết kết nối
tất cả các bộ định tuyến mà các host thuộc về nhóm multicast kết nối
với nó. Các gói tin multicast sẽ được định tuyến theo cây này từ thiết
bị gửi đến các host thuộc về cây multicast. Dĩ nhiên, cây có thể chứa
các bộ định tuyến không gắn trực tiếp tới các host thuộc về nhóm
multicast (ví dụ, trong hình 4.49, không thể kết nối các bộ định tuyến
A, B, E và F trong một cây mà không cần bộ định tuyến C hay D).
Trên thực tế, hai cách tiếp cận có thể thực hiện để xác định cây định
tuyến multicast, hai cách tiếp cận này đều đã được nghiên cứu trong
ngữ cảnh của định tuyến broadcast, vì thế chúng ta chỉ đề cập chúng
lướt qua ở đây. Hai cách tiếp cận này khác nhau trong cách xây dựng
một cây chia sẻ nhóm cho tất cả các host gửi được sử dụng để phân
phối dữ liệu, hay một cây định tuyến dựa vào nguồn được xây dựng
cho mỗi host gửi.
▪ Định tuyến multicast sử dụng cây chia sẻ nhóm. Tương tự trong
trường hợp broadcast dựa trên cây mở rộng, định tuyến multicast
trên một cây chia sẻ nhóm dựa vào việc xây dựng một cây gồm
các định tuyến biên với các host kết nối thuộc vào nhóm
multicast. Trong thực tế, cách tiếp cận dựa vào trung tâm được sử
dụng cho cây định tuyến multicast, với các bộ định tuyến biên và
các host kết nối thuộc nhóm multicast gửi các thông điệp tham
gia có địa chỉ là địa chỉ trung tâm. Như trong trường hợp
broadcast, một thông điệp tham gia được chuyển đi sử dụng định
tuyến unicast về phía trung tâm cho đến khi nó đến được một bộ
định tuyến đã thuộc về cây multicast hoặc đến trung tâm. Tất cả
các bộ định tuyến trên con đường mà thông điệp tham gia đi qua
sau đó sẽ chuyển các gói tin multicast được nhận đến bộ định
tuyến biên mà có tham gia multicast. Một câu hỏi quan trọng cho
định tuyến multicast cây dựa trên trung tâm là qui trình sử dụng
để lựa chọn trung tâm là như thế nào.
408
F E
Hình 4.49 – Các host multicast, các bộ định tuyến nó kết nối và các bộ định
tuyến khác.
▪ Định tuyến multicast sử dụng cây dựa trên nguồn. Trong khi giải
thuật multicast cây chia sẻ nhóm xây dựng một cây định tuyến
chia sẻ để định tuyến các gói tin từ tất cả các thiết bị gửi, cách
tiếp cận thứ 2 xây dựng một cây định tuyến multicast cho mỗi
nguồn trong nhóm multicast. Trên thực tế, một giải thuật RPF
(với nút nguồn x) được sử dụng để xây dựng một cây chuyển tiếp
multicast cho các gói tin multicast mà bắt đầu tại x. Giải thuật
broadcast RPF chúng ta đã tìm hiểu trước đó yêu cầu một ít thay
đổi để sử dụng cho multicast. Để xem tại sao, hãy xem bộ định
tuyến D trong hình 4.50. Với broadcast RPF, nó sẽ chuyển các
gói tin đến bộ định tuyến G, thậm chí G không có các host nào
kết nối mà tham gia vào nhóm multicast. Trong khi điều này thì
không phải quá tệ trong trường hợp này khi D chỉ có một bộ định
tuyến mà nó gửi gói tin cho (downstream), G, hình dung rằng
409
điều gì sẽ xảy ra nếu có hàng ngàn bộ định tuyến downstream từ

D. Mỗi bộ định tuyến này sẽ nhận các gói tin multicast không
mong muốn. Giải pháp cho vấn đề nhận các gói multicast không
mong muốn với RPF được xem như là rút gọn (prunning). Một bộ
định tuyến multicast nhận các gói tin multicast và không có host
nào gắn trực tiếp mà đã tham gia vào nhóm đó sẽ gửi một thông
điệp rút gọn cho các bộ định tuyến đã gửi cho nó (upstream) .
Nếu một bộ định tuyến nhận các thông điệp rút gọn từ tất cả các
bộ định tuyến downstream của nó từ một cổng, nó loại bỏ cổng
kết nối đó ra khỏi danh sách các cổng để chuyển gói multicast.
Định tuyến multicast trên Internet.
Giải thuật định tuyến multicast đầu tiên được sử dụng trên Internet là
Distance Vector Multicast Routing Protocol (DVMRP). DVMRP triển
khai các cây dựa vào nguồn với việc chuyển theo đường ngược lại
(reverse path forwarding) và prunning. Hiện nay, giao thức định tuyến
multicast được sử dụng rộng rãi nhất trên Internet là Protocol-
Independent Multicast (PIM), giao thức đã đưa ra hai chế độ phân
phối multicast. Trong chế độ dày đặc (dense mode), các thành viên
nhóm multicast có mật độ cao, nhiều hay hầu hết các bộ định tuyến
trong vùng này đều liên quan trong việc định tuyến các gói tin
multicast. Kĩ thuật PIM ở chế độ dày đặc là một kĩ thuật chuyển theo
đường ngược lại làm ngập tràn và rút gọn (flood-and-prune reverse
path forwarding) giống như DVMRP.
Trong chế độ thưa (sparse mode), số lượng của bộ định tuyến kết nối
với các thành viên nhóm thì khá nhỏ so với tổng số lượng của bộ định
tuyến; các thành viên nhóm phân tán rộng rãi. Chế độ thưa của PIM sử
dụng các điểm giao để thiết lập cây phân tán multicast. Trong
multicast sử dụng cây dựa trên nguồn(source specific multicast -
SSM), chỉ một thiết bị gửi được cho phép để gửi dữ liệu đến cây
multicast, và việc duy trì và xây dựng cây được xem là khá đơn giản.
Bởi PIM và DVMP được sử dụng bên trong một vùng, người quản lí
mạng có thể cấu hình các bộ định tuyến multicast IP bên trong một
vùng, giống cách mà các giao thức định tuyến unicast như RIP, IS-IS
và OSPF được cấu hình. Nhưng điều gì xảy ra nếu các đường
multicast giữa các vùng khác nhau. Có một giao thức multicast tương
410
tự như giao thức giữa các vùng BGP? Câu trả lời là có. [RFC4271]
mở rộng BGP để cho phép nó mang các thông tin định tuyến cho các
giao thức khác, bao gồm thông tin multicast. Multicast Source
Discovery Protocol (MSDP) [ RFC3618] có thể được sử dụng để kết
nối các điểm giao với nhau trong các vùng PIM có chế độ rời rạc khác
nhau.
S : Nguồn
B
C
D
F E
G
Ghi chú :
Gói tin sẽ được chuyển
Gói tin không được chuyển về phía bộ định tuyến
Hình 4.50 – Chuyển theo đường ngược lại – trường hợp multicast
Chúng ta hãy kết thúc thảo luận về multicast IP bằng việc lưu ý rằng
multicast IP hiện nay đã được sử dụng rộng rãi. Ở Anh, BBC hứa hẹn
bản dùng thử của việc phân phối nội dung qua multicast IP. Cùng thời
điểm đó, multicast mức ứng dụng, như chúng ta thấy với PPLive ở
chương 2 và trong các hệ thống ngang hàng khác như End System
Multicast cung cấp phân phối nội dung multicast trong số các ngang
hàng sử dụng các giao thức multicast tầng Ứng dụng hơn là tầng
Mạng.
411
Các dịch vụ multicast sẽ được triển khai ở tầng Mạng (trong phần lõi
của mạng) hay trên tầng Ứng dụng (tại biên của mạng) trong tương
lai? Trong khi việc phân phối nội dung thông qua mạng ngang hàng
khá phát triển hiện nay đã làm nghiêng cán cân đối cho multicast tầng
Ứng dụng ít nhất trong tương lai gần, việc phát triển IP multicast vẫn
được duy trì, và đôi khi, trong cuộc đua, người đi với sự chậm rãi và
vững chắc là người chiến thắng.
VIII. Tóm lược

Trong chương này, chúng ta đã tìm hiểu về tầng Mạng. Chúng ta đã
hiểu được rằng tầng Mạng bao gồm các host và các bộ định tuyến
trong mạng. Bởi vì điều này, các giao thức tầng Mạng là các giao thức
có nhiều thách thức nhất trong chồng giao thức mạng.
Chúng ta đã hiểu rằng một bộ định tuyến có thể cần phải xử lí hàng
triệu luồng dữ liệu giữa các cặp nguồn – đích tại một thời điểm. Để
cho phép một bộ định tuyến xử lí số lượng lớn các luồng dữ liệu như
vậy, các nhà thiết kế mạng đã nghiên cứu nhiều năm để làm cho
nhiệm vụ của bộ định tuyến đơn giản nhất có thể. Nhiều phương pháp
được thực hiện để giúp cho công việc của bộ định tuyến dễ dàng hơn,
bao gồm sử dụng mạng dữ liệu thay cho mạng chuyển mạch, sử dụng
phần đầu gói tin có kích thước cố định (ví dụ IPv6), loại bỏ phân
mảnh và chỉ cung cấp duy nhất dịch vụ nỗ lực tối đa.
Trong chương này chúng ta cũng đã tìm hiểu những nguyên lí cơ bản
của các giao thức định tuyến. Chúng ta cũng thấy rằng có 2 cách tiếp
cận chính: tiếp cận tập trung, cách tiếp cận mà mỗi nút có một sơ đồ
mạng và áp dụng các giải thuật tìm đường ngắn nhất để tìm đường đi
riêng rẽ, và cách tiếp cận phân tán, cách tiếp cận mà mỗi nút chỉ biết
được một phần của cấu trúc mạng, và các nút này phải liên lạc với
nhau để chuyển các gói tin đi theo con đường ngắn nhất. Chúng ta
cũng tìm hiểu làm cách nào để giải quyết vấn đề về phạm vi đối với
các mạng lớn bằng việc chia mạng ra nhiều vùng quản trị riêng.
Chúng ta cũng đã tìm hiểu các giao thức định tuyến được sử dụng
rộng rãi ngày nay OSPF, RIP và BGP và một số giải thuật định tuyến
trong định tuyến broadcast và multicast.
412
Chương 5. Tầng Liên kết và mạng cục bộ
Chương 5
TẦNG LIÊN KẾT
& MẠNG CỤC BỘ
Trong chương trình bày về tầng Mạng, chúng ta đã tìm hiểu về quá
trình liên lạc giữa hai thiết bị đầu cuối. Theo như hình 5.1 mô tả, dữ
liệu di chuyển qua nhiều đường liên kết dữ liệu liên tiếp, bắt đầu từ
máy nguồn - máy phát dữ liệu, đi qua các thiết bị định tuyến trung
gian và kết thúc tại máy đích - máy nhận dữ liệu. Ở đây, chúng ta qui
ước gọi một kết nối trực tiếp giữa các thiết bị liền kề là một đường
liên kết dữ liệu.
Theo kiến trúc mô hình phân tầng, tầng Liên kết sẽ cung cấp các dịch
vụ truyền thông cho tầng Mạng, điều khiển việc truyền dữ liệu trên
các đường liên kết nối các thiết bị liền kề. Ở chương này, chúng ta sẽ
phải trả lời một số câu hỏi quan trọng, ví dụ như cách thức một gói tin
ở tầng Mạng (packet) được đóng gói thành các gói tin ở tầng Liên kết
(frame) và truyền đi, liệu tầng Liên kết có cung cấp dịch vụ truyền tin
đáng tin cậy giữa hai thiết bị, ứng với các đường liên kết có tính chất
khác nhau có cần thiết phải có các giao thức truyền tải khác nhau hay
không?
Ở tầng Liên kết, có hai môi trường truyền dẫn cơ bản: môi trường
truyền dẫn quảng bá (broadcast) và môi trường điểm nối điểm (point-
to-point). Môi trường truyền dẫn quảng bá thường được thấy trong các
mạng cục bộ (LAN), mạng cục bộ không dây (wireless LAN), mạng
vệ tinh và mạng truyền dẫn kết hợp giữa cáp quang – cáp đồng trục
(HFC – fiber-coaxial cable). Trong mạng quảng bá, nhiều thiết bị sẽ
cùng kết nối vào chung một kênh truyền; điều này đòi hỏi tầng Liên
kết phải đóng vai trò điều khiển truy cập kênh truyền nhằm điều phối
414
quá trình truyền tin và tránh việc xảy ra xung đột khi có nhiều thiết bị
truyền tín hiệu cùng lúc. Môi trường truyền điểm nối điểm thường sử
dụng trong quá trình truyền tin giữa hai thiết bị định tuyến hoặc trong
kết nối dạng quay số (dial up) giữa khách hàng và nhà cung cấp dịch
vụ. Với dạng môi trường này, quá trình điều khiển việc truy cập kênh
truyền thường không phức tạp, tuy nhiên tầng Liên kết vẫn phải đảm
nhận các chức năng quan trọng như đóng gói dữ liệu, cung cấp khả
năng truyền tin đáng tin cậy, phát hiện lỗi và điều khiển luồng.
ISP quốc gia/ quốc tế
Mạng di động
Tầng mạng
Tầng liên
T kết
Tầng vật lý
Tần ứng dụng Tầng mạng
Tầng vận Tầng liên kết
chuyển Mạng gia đình
Tầng vật lý
Tầng mạng Tầng mạng ISP
Tầng liên kết địa phương/
Tầng liên
T kết
Tầng vật lý Tầng vật lý
vùng
Tầng mạng
Tầng liên kết
Tầng vật lý
Tầng mạng
Tầng liên kết
Tầng vật lý
Tần ứng dụng

Tầng vận
chuyển
Tầng mạng
Tầng liên kết
Tầng vật lý
Mạng công ty
Hình 5.1 Tầng Liên Kết
415
Ở những phần sau, chúng ta sẽ cùng nghiên cứu về một số giao thức
khác nhau trong tầng Liên kết. Chúng ta sẽ tập trung vào giao thức
Ethernet, là giao thức được sử dụng chính trong các mạng cục bộ có
dây. Ngoài ra, chúng ta sẽ tìm hiểu giao thức PPP, là giao thức được
sử dụng trong các mô hình mạng quay số.
I. Giới thiệu và các dịch vụ tầng Liên kết

Chúng ta sẽ cùng qui ước gọi chung các máy tính và thiết bị định
tuyến tham gia vào quá trình truyền thông là các nút mạng (node), vì
thật sự sẽ không có sự khác biệt nhiều trong hoạt động ở tầng Liên kết
giữa hai loại thiết bị này. Nhắc lại, chúng ta gọi một kết nối trực tiếp
giữa các thiết bị liền kề là một đường liên kết. Dữ liệu sẽ được lần
lượt truyền qua các đường liên kết trên suốt đoạn đường di chuyển từ
thiết bị nguồn đến thiết bị đích. Trên mỗi đường liên kết, thiết bị
truyền tin sẽ đóng gói dữ liệu nhận ở tầng Mạng thành các gói tin đặc
trưng ở tầng Liên kết, được gọi là frame, và truyền các gói tin này lên
đường truyền. Thiết bị nhận sẽ nhận các gói tin này, khôi phục dữ liệu
và chuyển lên các tầng bên trên xử lý.
I.1 Các dịch vụ tầng Liên kết cung cấp
Vai trò của tầng Liên kết là vận chuyển dữ liệu trên các đường liên kết
cụ thể. Các giao thức ở tầng Liên kết định nghĩa định dạng dữ liệu của
các gói tin trao đổi giữa các nút trên kênh truyền, cũng như các hành
động tương ứng của các nút khi cần gửi hoặc nhận được các gói tin
này. Như đã đề cập ở chương đầu tiên, các gói tin trao đổi trên các
đường liên kết được gọi là các frame, và thông thường trong mỗi
frame sẽ chứa một gói tin của tầng Mạng (được gọi là packet). Các
hành động khi cần gửi hoặc nhận được một gói tin bao gồm việc kiểm
tra lỗi, truyền lại gói tin, điều khiển luồng và điều khiển truy cập ngẫu
nhiên. Một số ví dụ về các giao thức ở tầng Liên kết có thể kể đến là
Ethernet, 802.11 dùng cho mạng cục bộ không dây (thường được gọi
là Wifi), token ring và giao thức PPP.
Trong khi vai trò của tầng Mạng là truyền dữ liệu của tầng Vận
chuyển từ thiết bị gửi đến thiết bị nhận, tầng Liên kết đảm nhận vai trò
truyền dữ liệu của tầng Mạng giữa các nút trên một đường liên kết.
416
Trong quá trình truyền dữ liệu giữa thiết bị nguồn và đích, nếu dữ liệu
đi qua các đường liên kết các đặc điểm khác nhau, thì tại mỗi đường
liên kết quá trình truyền dữ liệu sẽ do một giao thức liên kết khác nhau
phụ trách. Ví dụ, nếu dữ liệu có thể được vận chuyển bằng giao thức
Ethernet trên đường liên kết đầu tiên, được chuyển bởi giao thức PPP
trên các đường liên kết trung gian và cuối cùng được vận chuyển bởi
giao thức 802.11g trên đường liên kết không dây để đến nút mạng
đích. Các giao thức ở tầng Liên kết khác nhau hoàn toàn có thể cung
cấp các dịch vụ khác nhau, ví dụ một vài giao thức sẽ hỗ trợ dịch vụ
truyền dẫn đáng tin cậy trong khi một vài giao thức không hỗ trợ. Vì
vậy, tầng Mạng phải được thiết kế sao cho vẫn có thể đảm bảo được
việc truyền dữ liệu thành công giữa thiết bị gửi và thiết bị nhận, bất
chấp sự khác nhau giữa các giao thức ở tầng Liên kết trên suốt đường
truyền.
Để có thể hiểu rõ hơn về các khái niệm ở tầng Liên kết, chúng ta có
thể xem xét một ví dụ gần tương tự trong lãnh vực vận tải. Chúng ta
xét trường hợp có một công ty du lịch muốn thiết kế một chuyến du
lịch cho khách hàng đi từ thành phố Hồ Chí Minh đến thị trấn Sapa,
thuộc thành phố Lào Cai. Đầu tiên, công ty sẽ sắp xếp cho du khách di
chuyển bằng máy bay từ thành phố Hồ Chí Minh đến sân bay Nội Bài
tại Hà Nội. Tiếp đến, hành khách sẽ di chuyển bằng xe ô tô từ sân bay
Nội Bài để đến ga Hà Nội. Tại đây, các hành khách sẽ di chuyển bằng
tàu lửa để đến ga trung tâm Lào Cai. Cuối cùng, các du khách sẽ lại
tiếp tục đi ô tô từ Lào Cai đến đích tại Sapa. Mỗi đoạn đường kể trên
có thể xem là một đường liên kết nối giữa hai địa điểm liền kề, kết
hợp lại để hình thành nên hành trình di chuyển từ thành phố Hồ Chí
Minh đến Sapa. Công ty du lịch đóng vai trò là một giao thức định
tuyến, quyết định lộ trình phù hợp nhất cho du khách, du khách sẽ
đóng vai trò các gói tin trên đường truyền. Các phương tiện truyền dẫn
khác nhau như máy bay, xe ô tô, tàu hỏa … đóng vai trò các giao thức
ở tầng Liên kết, chịu trách nhiệm vận chuyển “dữ liệu” trên từng
đường liên kết cụ thể.
Mặc dù vai trò chung của tầng Liên kết là vận chuyển dữ liệu giữa các
nút liền kề trên từng đường liên kết, tùy theo mỗi giao thức được sử
dụng có thể cung cấp các dịch vụ khác nhau. Nhìn chung, các dịch vụ
có thể được cung cấp tại tầng Liên kết gồm có:
417
• Đóng gói dữ liệu (framing): Hầu như mọi giao thức ở tầng Liên
kết đều đóng gói một gói tin ở tầng Mạng thành một gói tin ở tầng
Liên kết - gọi là frame - trước khi chuyển đi trên kênh truyền.
Một gói tin ở tầng Liên kết gồm có phần dữ liệu và nhiều thành
phần cấu tạo nên header (phần đầu của gói tin). Các giao thức
khác nhau sẽ qui định các cấu trúc gói tin khác nhau, cấu trúc gói
tin của một số giao thức cơ bản sẽ được giới thiệu ở những phần
sau. Để đơn giản, trong chương này khi đề cấp đến gói tin mà
không cung cấp thêm thông tin nào khác, độc giả có thể hiểu gói
tin là một frame ở tầng Liên kết.
• Truy cập kênh truyền: Một giao thức điều khiển truy cập kênh
truyền (MAC – Media Access Control) qui định các luật về việc
truyền một gói tin vào kênh truyền.Với các giao thức dạng điểm
nối điểm, trong môi trường chỉ có một thiết bị truyền duy nhất ở
một đầu và một thiết bị nhận duy nhất ở đầu còn lại thì mọi
chuyện khá đơn giản, thiết bị có thể truyền dữ liệu bất kỳ lúc nào
kênh truyền không bị chiếm dụng. Vấn đề phức tạp hơn với môi
trường quảng bá, khi có nhiều thiết bị cùng sử dụng chung một
kênh truyền chia sẻ - thường phải áp dụng các cơ chế điều khiển
đa truy cập. Trong trường hợp này, giao thức điều khiển truy cập
sẽ đóng vai trò điều phối quá trình truyền tin giữa các nút mạng
để tránh bị xung đột. Chi tiết về giao thức điều khiển truy cập sẽ
được trình bày ở các phần sau
• Truyền dữ liệu đáng tin cậy: Khi tầng Liên kết cung cấp dịch vụ
truyền dữ liệu đáng tin cậy, các gói tin ở tầng Mạng sẽ được đảm
bảo truyền đến đích không bị lỗi. Tương tự như dịch vụ TCP ở
tầng Vận chuyển cung cấp khả năng truyền dữ liệu đáng tin cậy,
các giao thức ở tầng Liên kết đảm bảo tín tin cậy nhờ quá trình
xác nhận (acknowledgement) và truyền lại (retransmission). Dịch
vụ truyền dữ liệu đáng tin cậy thường được sử dụng trong các
đường truyền có khả năng xảy ra lỗi cao, ví dụ như đường truyền
không dây, nhằm cung cấp khả năng sửa lỗi ngay tại các đường
418
liên kết cục bộ, thay vì phải đợi đến thiết bị đích mới kiểm tra lỗi
tại tầng Vận chuyển hoặc tầng Ứng dụng. Tuy nhiên, dịch vụ
truyền dữ liệu đáng tin cậy lại có thể gây nên những gánh nặng
không cần thiết trên những đường truyền có tỉ lệ lỗi rất thấp, ví dụ
như đường truyền cáp quang, cáp đồng trục hoặc cáp xoắn đôi. Vì
lí do trên, nhiều kênh truyền có dây không áp dụng các dịch vụ
truyền dữ liệu đáng tin cậy.
• Điều khiển luồng: Mỗi nút mạng trên kênh truyền có một bộ nhớ
đệm hữu hạn để xử lý các gói tin nhận được. Vấn đề có thể phát
sinh khi trong một khoảng thời gian, một nút mạng phải nhận một
khối lượng gói tin vượt quá năng lực xử lý hiện tại. Nếu không có
cơ chế điều khiển luồng, bộ đệm có thể bị tràn và các gói tin sẽ bị
mất. Tương tự như tại tầng Vận chuyển, tầng Liên kết cung cấp
dịch vụ điều khiển luồng nhằm ngăn chặn việc một nút mạng gửi
các gói tin với tốc độ nhanh hơn khả năng xử lý của nút nhận.
• Phát hiện lỗi: Nút mạng nhận có thể bị nhầm lẫn khi nhận định
một bit dữ liệu mang giá trị 0 trong khi thực sự bit này được
truyền với giá trị 1, hoặc ngược lại. Việc nhầm lẫn này thường do
nguyên nhân suy hao tín hiệu hoặc do nhiễu trên đường truyền.
Việc xử lý các gói tin khi dữ liệu bị sai lệch là không cần thiết, do
đó rất nhiều giao thức ở tầng Liên kết cung cấp các dịch vụ để
phát hiện lỗi xảy ra trên đường truyền. Việc này thực hiện được
nhờ bên gửi dữ liệu sẽ chèn thêm một số thông tin kiểm soát lỗi
trong gói tin kèm theo dữ liệu thật sự cần truyền, nút mạng đích
sẽ dựa vào các thông tin gửi kèm thêm này để phát hiện lỗi.
Chúng ta có thể nhớ lại tầng Vận chuyển và tầng Mạng cũng cung
cấp dịch vụ phát hiện lỗi thông qua Internet checksum. Quá trình
phát hiện lỗi tại tầng Liên kết phức tạp hơn và thường được cài
đặt tại phần cứng thiết bị.
• Sửa lỗi: Quá trình sửa lỗi thường tương tự với phát hiện lỗi, tuy
nhiên nút mạng nhận ngoài việc phát hiện có lỗi trong quá trình
truyền tin còn có thể định vị được vị trí xảy ra lỗi và khôi phục lại
419
dữ liệu gốc ban đầu. Một vài giao thức chỉ cài đặt dịch vụ sửa lỗi
này cho phần header thay vì cho toàn bộ nội dung gói tin. Các kỹ
thuật phát hiện và sửa lỗi sẽ được trình bày ở mục II
• Truyền thông song công và bán song công: Với phương pháp
truyền tin song công (full duplex), các nút mạng tại hai đầu
đường truyền có thể cùng lúc phát tín hiệu. Với phương pháp
truyền tin bán song công (half duplex), một nút mạng không thể
vừa gửi và nhận dữ liệu cùng lúc.
Có thể nhận thấy, rất nhiều dịch vụ tại tầng Liên kết khá tương đồng
với các dịch vụ được cung cấp tại tầng Vận chuyển. Ví dụ như cả tầng
Liên kết và tầng Vận chuyển đều cung cấp khả năng truyền tin đáng
tin cậy. Mặc dù phương pháp để đảm bảo việc truyền dữ liệu đáng tin
cậy tại hai tầng là tương tự nhau, về bản chất dịch vụ tại hai tầng này
có chức năng khác nhau. Dịch vụ tại tầng Vận chuyển bảo đảm vận
chuyển dữ liệu đáng tin cậy giữa một tiến trình tại thiết bị gửi và một
tiến trình tại thiết bị nhận, trong khi đó dịch vụ tại tầng Liên kết đảm
bảo truyền tin đáng tin cậy giữa hai nút mạng trên một đường liên kết.
Tương tự, cả tầng Vận chuyển và tầng Liên kết đều cung cấp dịch vụ
điều khiển luồng và phát hiện lỗi, tuy nhiên dịch vụ điều khiển luồng
tại tầng Vận chuyển áp dụng giữa các tiến trình trên thiết bị gửi và
thiết bị nhận, dịch vụ tại tầng Liên kết áp dụng cho hai nút mạng liền
kề.
I.2 Cài đặt tầng Liên kết
Trước khi tiếp tục phân tích các đặc điểm của tầng Liên kết, chúng ta
sẽ tìm hiểu tầng Liên kết được cài đặt tại đâu trên một thiết bị đầu
cuối. Liệu tầng Liên kết có được cài đặt trên một card hoặc chip riêng,
tầng này sẽ giao tiếp với các linh kiện phần cứng khác và hệ điều hành
trên máy tính như thế nào?
Hình 5.2 thể hiện cấu trúc thông thường của một máy tính. Phần lớn
của tầng Liên kết được cài đặt trong bộ giao tiếp mạng, thường được
gọi là NIC (Network Interface Card). Thành phần chính của bộ giao
tiếp mạng này là bộ điều khiển liên kết (link-layer controller), đây là
một chip chuyên dụng có cài đặt sẵn các dịch vụ của tầng Liên kết
420
như đóng gói dữ liệu, điều khiển luồng, phát hiện lỗi … Như vậy,
phần lớn các chức năng của tầng Liên kết được cài đặt ở mức phần
cứng.
Máy tính
Ứng dụng
Vận chuyển CPU Bộ nhớ
Mạng
Liên kết
Bus của thiết bị

(ví dụ như PCI)
Bộ điều
Liên kết khiển
Vật lý
Bộ giao tiếp mạng

Truyền tín
hiệu vật lý
Hình 5.2: Bộ giao tiếp mạng: mối liên hệ với các thành phần khác
trong máy tính
Tại nơi gửi, bộ điều khiển nhận một gói tin đã được lưu sẵn trong bộ
nhớ của máy tính bởi các giao thức ở tầng trên, đóng gói thành một
gói tin ở tầng Liên kết và chuyển gói tin lên kênh truyền theo sự điều
phối của giao thức điều khiển truy cập. Tại nơi nhận, bộ điều khiển
nhận hoàn toàn một gói tin từ kênh truyền, khôi phục thành gói tin
nguyên gốc ở tầng Mạng. Nếu tầng Liên kết thực hiện tính năng phát
hiện lỗi, bộ điều khiển tại nút gửi tín hiệu sẽ thêm các bit kiểm lỗi vào
phần header và bộ điều khiển tại nút nhận sẽ thực hiện nhiệm vụ kiểm
tra lỗi dựa vào các bit này. Nếu tầng Liên kết thực hiện tính năng điều
khiển luồng, bộ điều khiển tại nút gửi và nhận dữ liệu sẽ trao đổi các
thông tin kiểm soát luồng, nhờ đó bên gửi sẽ truyền với tốc độ mà bên
nhận có thể xử lý được.
Hình 5.2 cho thấy, bộ giao tiếp mạng được gắn trực tiếp vào bus của
máy tính thông qua cổng giao tiếp PCI hoặc PCI/X như các thiết bị
421
nhập xuất thông thường khác, tuy nhiên trong một số máy tính ngày
nay, bộ giao tiếp mạng được tích hợp sẵn vào bản mạch chủ của máy
tính. Mặc dù phần lớn các tính năng của tầng Liên kết được cài đặt
trên phần cứng của bộ giao tiếp mạng, một phần của tầng Liên kết
được cài đặt ở mức phần mềm và sẽ thực thi tại CPU của máy tính.
Những tính năng của tầng Liên kết được cài đặt ở mức phần mềm
thường là những tính năng ở mức cao, ví dụ như các tính năng nhận
gói tin từ tầng Mạng, gắn thêm thông tin địa chỉ ở tầng Liên kết vào
gói tin và kích hoạt bộ điều khiển tại phần cừng. Tại nút nhận dữ liệu,
các tính năng cài đặt tại phần mềm sẽ xử lý các ngắt (interrupts) của
bộ điều khiển (ví dụ như các ngắt phát sinh khi nhận được một hoặc
nhiều gói tin), đảm nhận việc xử lý các lỗi phát sinh và chuyển gói tin
lên tầng Mạng. Như vậy, tầng Liên kết được cài đặt kết hợp ở mức
phần cứng và phần mềm, tầng này là nơi phối hợp các xử lý tại mức
phần cứng và phần mềm trong kiến trúc phân tầng của hệ thống mạng.
Hình 5.3 thể hiện bộ giao tiếp mạng trong quá trình gửi và nhận dữ
liệu. Các tính năng chính của tầng Liên kết được cài đặt tại bộ điều
khiển, bộ giao tiếp mạng là nơi sẽ gửi và nhận trực tiếp gói tin từ
đường truyền. Nhiều nghiên cứu đã tìm cách đưa thêm nhiều tính
năng ở các tầng cao hơn vào bộ giao tiếp mạng. Ví dụ như bộ điều
khiển 8254x của hãng Intel có thể tính toán giá trị TCP/UDP
checksum và IP checksum ở mức phần cứng. Thiết kế này dường như
đã đi ngược lại nguyên tắc thiết kế phân tầng, tuy nhiên ưu điểm của
nó là đẩy nhanh tốc độ tính toán các giá trị checksum nhờ tận dụng
phần cứng thay vì tính toán trên phần mềm. Chính đặc điểm này đã
khuyến khích việc một số thiết kế bộ giao tiếp mạng vi phạm các
nguyên tắc thiết kế phân tầng.
Dữ liệu
Đường truyền
Gói tin
Bộ giao tiếp Bộ giao tiếp

mạng mạng
Giao thức tầng liên kết
422
Hình 5.3: Liên lạc giữa các bộ giao tiếp mạng: gói tin ở tầng Mạng
được bọc bên trong một gói tin ở tầng Liên kết
II. Kỹ thuật phát hiện và sửa lỗi

Tầng Liên kết thường cung cấp dịch vụ phát hiện lỗi và sửa lỗi ở mức
độ bit - hỗ trợ việc phát hiện và phục hồi các chuỗi bit bị sai trong quá
trình truyền tin giữa các nút mạng liền kề trên kênh truyền. Trong
phần này, chúng ta sẽ tìm hiểu một số kỹ thuật đơn giản giúp phát
hiện các chuỗi bit bị truyền sai, và trong một vài trường hợp giúp sửa
các lỗi sai này. Mục đích chính của phần này là trình bày ngắn gọn,
trực quan về phương pháp hoạt động cũng như cách áp dụng của các
kỹ thuật này vào tầng Liên kết.
Hình 5.4 mô tả phương pháp hoạt động của các kỹ thuật phát hiện và
sửa lỗi. Tại nút mạng gửi, gọi D là dữ liệu cần gửi đi, EDC (Error
detection-correction) là các bit dùng để phát hiện và sửa lỗi sai sẽ
được gửi kèm với dữ liệu D. Thông thường, phần dữ liệu D cần được
bảo đảm tính đúng đắn không chỉ bao gồm gói tin được chuyển xuống
từ tầng Mạng mà còn bao gồm cả các thông tin về địa chỉ, thông tin về
số thứ tự và các thông tin header khác được bổ sung bởi tầng Liên kết.
Cả phần dữ liệu D và phần kiểm lỗi EDC sẽ được kết hợp thành một
gói tin ở tầng Liên kết và truyền đi trên kênh truyền. Tại nút mạng
đích, một chuỗi các bit bao gồm cả phần dữ liệu D’ và phần kiểm tra
lỗi EDC’ sẽ được nhận. Lưu ý là dữ liệu thật sự nhận gồm D’ và
EDC’ có thể sai khác so với dữ liệu D và EDC ban đầu do những lỗi
có thể gặp trên đường truyền.
Nhiệm vụ của nút mạng nhận là phải xác định dữ liệu D’ có trùng
khớp với dữ liệu D ban đầu hay không, việc xác định này có thể dựa
vào D’ và EDC’ nhận được. Hình 5.4 mô tả vắn tắt các bước được tiến
hành tại nút nhận, quá trình phát hiện và sửa lỗi này giúp cho nút nhận
phát hiện được các sai sót phát sinh trong quá trình truyền tin. Tuy
nhiên tùy vào phương pháp kiểm tra sẽ có những trường hợp truyền
tin bị lỗi nhưng hệ thống không phát hiện được, mỗi phương pháp
kiểm tra sẽ có những ưu và khuyết điểm riêng. Mục đích của người
thiết kế hệ thống là lựa chọn phương pháp kiểm tra sao cho tỉ lệ không
phát hiện được các lỗi sai là rất nhỏ. Thông thường, các phương pháp
423
kiểm tra và sửa lỗi càng phức tạp, yêu cầu thực hiện nhiều phép tính
cũng như lượng thông tin gửi kèm để kiểm tra lỗi càng lớn thì tỉ lệ
không phát hiện được lỗi sai sẽ càng nhỏ.
Gói tin Gói tin
Đ
Hᵢ
Tất cả các
bits của D’ S
đúng?
Phát hiện lỗi
d bits dữ liệu
D EDC D’ EDC’
Đường truyền có thể bị lỗi
Hình 5.4: Kịch bản phát hiện lỗi và sửa lỗi

Ở phần này, chúng ta sẽ tìm hiểu ba phương pháp khác nhau để phát
hiện lỗi sai trên đường truyền: kiểm tra parity (thường dùng để minh
họa tư tưởng chính của việc phát hiện và sửa lỗi), kiểm tra checksum
(thường được sử dụng ở tầng Vận chuyển nhiều hơn) và phương pháp
kiểm tra mã dư vòng CRC (cyclic redundancy check) thường được cài
đặt ở tầng Liên kết tại các bộ giao tiếp mạng.
II.1 Kiểm chẵn
Phương pháp kiểm tra sử dụng một bit parity có thể là phương pháp
đơn giản nhất để phát hiện lỗi sai. Trong hình 5.5, chúng ta gọi phần
dữ liệu cần chuyển đi là D bao gồm d bit. Trong mô hình kiểm tra
parity chẵn, nút gửi sẽ thêm vào một bit, gọi là bit parity, có giá trị sao
424
cho tổng số bit 1 trong số d + 1 bit (d bit phần dữ liệu và 1 bit kiểm
parity) là một số chẵn. Trong mô hình kiểm tra parity lẻ, giá trị của bit
parity được chọn sao cho tổng số bit 1 sẽ là một số lẻ. Hình 5.5 mô tả
một trường hợp kiểm tra parity chẵn, bit parity được lưu trữ ở một
trường riêng ở phần cuối.
Bit kiểm lỗi

d bits dữ liệu parity
0111000110101011 1
Hình 5.5: Phương pháp kiểm lỗi dựa vào parity chẵn
Tại nút nhận dữ liệu, quá trình kiểm tra khi sử dụng một bit parity
cũng khá đơn giản. Nút nhận sẽ đếm tổng tất cả các bit 1 trong số d +
1 bit nhận được. Với mô hình parity chẵn, nếu tổng số bit 1 nhận
được là một số lẻ thì nút nhận có thể kết luận ít nhất một bit đã bị
truyền sai. Nói chính xác hơn, đã có một số lượng lẻ các bit đã bị
truyền sai trên kênh truyền.
Tuy nhiên, nếu số lượng bit bị truyền sai là một số chẵn thì chuyện gì
sẽ xảy ra? Trong trường hợp này, phương pháp kiểm tra parity chẵn
không phát hiện được lỗi sai. Nếu tỉ lệ lỗi bit thấp và tỉ lệ bị lỗi giữa
hai bit liên tiếp là hoàn toàn độc lập với nhau, tỉ lệ lỗi của một chuỗi
các bit liên tiếp nhau trong quá trình truyền tin sẽ là rất thấp. Trong
trường hợp này, việc sử dụng phương pháp kiểm tra parity một bit là
tương đối đảm bảo. Tuy nhiên, các phép đo đạc đã chỉ ra rằng tỉ lệ bị
lỗi của các bit liên tiếp không độc lập với nhau, khi có hiện tượng lỗi
trên đường truyền thường sẽ kéo theo một chuỗi các bit liên tiếp nhau.
Khi xảy ra hiện tượng lỗi trên chuỗi các bit, tỉ lệ không phát hiện được
lỗi sai của phương pháp parity một bit có thể lên đến 50%. Do đó,
trong thực tế thường các phương pháp phức tạp hơn sẽ được sử dụng
để phát hiện lỗi. Tuy nhiên, trước khi chuyển sang nghiên cứu các
phương pháp khác, chúng ta sẽ tìm hiểu một phiên bản cải tiến của
425
phương pháp parity một bit nhằm tìm hiểu khái niệm sửa lỗi tại tầng
Liên kết.
Hình 5.6 mô tả phương pháp sửa lỗi trên đường truyền sử dụng parity
hai chiều. Dữ liệu D gồm d bits được chia thành i dòng và j cột. Giá trị
parity bit được tính toán cho từng dòng và từng cột trong mảng, kết
quả chúng ta sẽ có tổng cộng i + j + 1 bit dùng để kiểm soát lỗi.
Giả sử có một bit trong số d bit dữ liệu bị lỗi trong quá trình truyền
tin. Với mô hình parity hai chiều, bit kiểm tra lỗi tại dòng và cột chứa
bit dữ liệu lỗi sẽ bị sai. Do đó, nút nhận dữ liệu không chỉ phát hiện
được có lỗi sai trong trường hợp này mà còn có thể xác định được vị
trí bit bị lỗi, là giao điểm của dòng và cột phát hiện được giá trị parity
sai. Nút nhận dữ liệu chỉ cần thay đổi giá trị của bit này (từ 0 thành 1
và ngược lại) sẽ sửa được lỗi sai và khôi phục giá trị gốc ban đầu. Mặc
dù chúng ta chỉ quan tâm đến sai sót xảy ra trong d bit ở phần dữ liệu,
phương pháp này cũng có thể sửa được trường hợp một lỗi sai xảy ra
ở chính các bit parity. Sử dụng parity hai chiều có thể phát hiện được
(nhưng không sửa được) trường hợp có hai bit bị lỗi trong gói tin.
Khả năng vừa phát hiện và sửa lỗi tại nơi nhận được gọi là FEC
(forward error correction). Việc áp dụng các kỹ thuật FEC vào truyền
thông giúp bên nhận có thể ngay lập tức sửa được lỗi sai mà không
cần phải mất khoảng thời gian chờ thông tin được gửi lại, đây là một
đặc điểm quan trọng áp dụng trong các ứng dụng thời gian thực hoặc
trong các môi trường mạng có thời gian chờ phát lại dữ liệu cao.
P
d
ò
n
g
a
r
i
t
…
Parity cột
… … … …
…
426
Không bị lỗi Sửa được một lỗi
1 0 1 0 1 1 1 0 1 0 1 1
1 1 1 1 0 0 1 0 1 1 0 0
0 1 1 1 0 1 0 1 1 1 0 1
0 0 1 0 1 0 0 0 1 0 1 0
Hình 5.6: Phương pháp kiểm lỗi parity 2 chiều

II.2 Kiểm tổng (checksum)
Trong phương pháp checksum, đoạn dữ liệu dài d bit như trong hình
5.5 sẽ được xem như là một dãy các số nguyên dài k bit. Một phương
pháp tính checksum đơn giản là tính tổng tất cả các số nguyên k bit
này và sử dụng tổng này như thành phần kiểm tra lỗi. Phương pháp
Internet checksum được dựa trên hướng tiếp cận này, dữ liệu được
xem như là dãy các số nguyên 16 bit và được đem đi tính tổng. Giá trị
bù 1 của tổng này sẽ được xem như giá trị Internet checksum và tích
hợp gửi kèm trong phần header của gói tin. Nút nhận sẽ kiểm tra giá
trị checksum bằng cách tính giá trị bù 1 của tổng tất cả các dữ liệu
nhận được (bao gồm cả checksum nhận được từ nút gửi), và kiểm tra
xem tất cả các bit của giá trị này có phải đều bằng 1 hay không. Nếu
tồn tại bất cứ bit nào có giá trị bằng 0, có thể xác định đã có lỗi xảy ra
trên đường truyền. Tài liệu RFC 1071 mô tả và thảo luận các vấn đề
về giải thuật tính Internet checksum và cách thức cài đặt chi tiết.
Trong giao thức TCP và UDP, trường Internet checksum được tính
dựa trên tất cả các trường khác (bao gồm phần header và phần dữ
liệu). Trong giao thức IP, trường checksum được tính dựa vào phần IP
header (vì bản thân dữ liệu UDP và TCP bên trong đã được tính
checksum).
427
Phương pháp tính checksum chỉ thêm vào gói tin một lượng thông tin
rất ít, ví dụ như checksum trong TCP và UDP chỉ thêm vào 16 bit.
Tuy nhiên, phương pháp này cung cấp khả năng chống sai sót yếu hơn
so với phương pháp CRC thường dùng tại tầng Liên kết và được trình
bày ở phần sau. Câu hỏi đặt ra là tại sao checksum được dùng ở tầng
Vận chuyển trong khi CRC được dùng ở tầng Liên kết? Tầng Vận
chuyển được cài đặt tại phần mềm của thiết bị, tích hợp như một phần
của hệ điều hành, do đó phương pháp kiểm tra lỗi cần phải đơn giản
và hoạt động nhanh. Ngược lại, quá trình kiểm tra lỗi của tầng Liên
kết được cài đặt trên thiết bị phần cứng do đó có thể sử dụng các
phương pháp phức tạp hơn.
II.3 Kiểm dư vòng (CRC)
Phương pháp phát hiện lỗi dựa vào mã dư vòng (cyclic redundancy
check – CRC) được sử dụng phổ biến trong lãnh vực mạng máy tính.
CRC còn được gọi là mã đa thức (polynomial codes), bởi vì chúng ta
có thể xem một chuỗi bit được gửi đi là một hàm đa thức với các giá
trị hệ số là 1 hoặc 0 và có thể áp dụng các phép toán đa thức lên chuỗi
bit này.
d bits r bits
D: Dữ liệu cần gửi R: CRC bits Mô hình bit
D . 2ʳ XOR R Biểu diễn theo toán học
Hình 5.7: Phương pháp kiểm lỗi CRC

Phương pháp CRC hoạt động như sau: Xét một đoạn dữ liệu D dài d
bit, là giá trị mà nút gửi muốn truyền đi. Trước tiên, nút nhận và nút
gửi phải cùng thống nhất một chuỗi giá trị dài r + 1 bit, được gọi là
hàm sinh (generator) và ký hiệu là G. Hàm sinh G phải có giá trị bit
ngoài cùng bên trái (bit có nghĩa cao nhất) là 1. Ý tưởng chính của
phương pháp CRC được minh họa trong hình 5.7. Với một đoạn dữ
liệu D cần truyền, nút gửi sẽ phải đính kèm thêm một giá trị R dài r bit
để gửi đi sao cho đoạn dữ liệu tổng hợp dài d + r bit này phải chia hết
cho hàm sinh G (số dư bằng 0) trong phép chia modulo-2. Tại nơi
nhận, đoạn dữ liệu gồm d + r bit này cho G (phép chia modulo-2), nếu
428
số dư khác 0 thì đã có lỗi xảy ra trên đường truyền, ngược lại nếu số
dư bằng 0 thì dữ liệu nhận được chính xác.
Tất cả các phép toán áp dụng trong CRC đều là các phép toán modulo-
2 và không “vay mượn” hay “nhớ” thêm giá trị trong phép toán trừ.
Điều này nghĩa là trong môi trường modulo-2, phép toán cộng và trừ
là như nhau và cả hai cũng sẽ cho ra cùng giá trị với phép toán XOR.
Xét ví dụ:
1011 XOR 0101 = 1110
1001 XOR 1101 = 0100
Như vây, chúng ta cũng sẽ có:
1011 - 0101 = 1110
1001 - 1101 = 0100
Phép toán nhân và chia sẽ tương tự như trong hệ nhị phân thông
thường, trừ việc các phép toán cộng và trừ cũng không “vay mượn”
hoặc “nhớ” thêm giá trị. Tương tự như trong hệ nhị phân, nhân với giá
trị 2k sẽ dịch giá trị chuỗi bi sang trái k vị trí. Như vậy, khi cho trước
giá trị D và R, giá trị D.2r XOR R sẽ hình thành chuỗi dài d + r bit như
trong hình 5.7
Vấn đề được đặt ra, làm thế nào để tính giá trị R tại nút gửi dữ liệu?
Vì chuỗi d + r bit chia hết cho hàm sinh G, phải tồn tại giá trị n sao
cho:
D.2r XOR R = nG
Nếu chúng ta thực hiện phép toán XOR (trong trường modulo-2,
không “nhớ” hay “vay mượn” giá trị) với R cho cả 2 phía của biểu
thức, sẽ được:
D.2r = nG XOR R
Biểu thức này cho thấy nếu chúng ta thực hiện phép toán chia D.2r cho
G, số dư của phép chia chính là giá trị R. Như vậy, giá trị R có thể
được tính bằng cách:
429
R = số dư
Hình 5.8 mô tả phép tính chia trong trường hợp D = 101110, d = 6, G

= 1001 và r = 3. Giá trị dữ liệu gửi đi gồm 9 bit lúc này sẽ là 101110
011. Các bạn có thể tự thực hiện lại các phép toán này và có thể kiểm
tra điều kiện D.2r = 101011.G XOR R
G 101011
1001 101110000
1001
101
000
D
1010
1001
110
000
1100
1001
1010
1001
011
R
Hình 5.8: Một ví dụ về phương pháp CRC

Các chuẩn quốc tế đã định nghĩa sẵn hàm sinh G dài 8, 12, 16 và 32
bit. Hàm sinh CRC-32 dài 32 bit thường được sử dụng trong các giao
thức liên kết của tổ chức IEEE, có giá trị:
G CRC-32 = 1000000100110000010001110110110111
Phương pháp CRC có thể phát hiện được chuỗi bit liên tiếp bị lỗi dài
ít hơn r + 1 bit. Với một số giả định bổ sung, chuỗi bit lỗi dài hơn r +
1 bit có thể được phát hiện với xác suất 1 – 0.5r. Ngoài ra, tất cả các
chuẩn CRC đều có thể phát hiện ra chuỗi bit lỗi có chiều dài bất kỳ là
một số lẻ.
430
III. Các giao thức đa truy

Như đã đề cập ở đầu chương, có hai dạng đường liên kết chính là
điểm nối điểm (point-to-point) và quảng bá (broadcast). Đường điểm
nối điểm gồm một thiết bị gửi ở một đầu và một thiết bị nhận ở đầu
còn lại của kênh truyền. Hai giao thức dành riêng cho đường điểm nối
điểm là PPP và HDLC sẽ được đề cập ở những phần nội dung sau ở
chương này. Dạng đường kết nối thứ nhì là quảng bá bao gồm nhiều
thiết bị gửi và nhận chia sẻ chung một kênh truyền. Thuật ngữ quảng
bá được sử dụng vì khi một nút mạng gửi một gói tin vào kênh truyền,
gói tin này sẽ được gửi đến tất cả các nút mạng khác trên kênh truyền
đó. Mạng Ethernet và mạng LAN không dây là hai ví dụ phổ biến nhất
của môi trường quảng bá. Trong phần này, chúng ta sẽ cùng tìm hiểu
một vấn đề cơ bản của môi trường quảng bá: làm cách nào để phối
hợp hoạt động giữa nhiều nút mạng gửi và nhận chung trên một kênh
truyền – hay còn được gọi là vấn đề điều khiển đa truy cập. Mạng
quảng bá thường được áp dụng trong các mạng LAN, các nút mạng
thường được tập trung trong cùng một tòa nhà hoặc khuôn viên của
một tổ chức, vì vậy chúng ta cũng sẽ đề cập đến vấn đề điều khiển đa
truy cập ở cuối mục này.
Chúng ta phần nào đều quen thuộc với khái niệm quảng bá, dịch vụ
phát thanh và truyền hình đã sử dụng kỹ thuật này từ khi chúng được
sử dụng rộng rãi. Tuy nhiên, mạng truyền hình truyền thống sử dụng
kỹ thuật quảng bá một chiều (chỉ có một nút mạng phát và nhiều nút
mạng nhận), trong khi đó mọi nút mạng trong môi trường mạng máy
tính đều có thể phát và nhận tín hiệu. Một ví dụ gần gũi hơn với chúng
ta là mô hình một phòng họp, khi nhiều người cùng tập trung để lắng
nghe và trao đổi ý kiến. Một ví dụ khác là mô hình một lớp học, khi
giáo viên và các sinh viên cùng chia sẻ chung một môi trường giao
tiếp dạng quảng bá. Vấn đề cần giải quyết là quyết định xem ai là
người được phát phát biểu (hoặc truyền dữ liệu vào kênh truyền) tại
một thời điểm nhất định. Trong giao tiếp hàng ngày, chúng ta thường
tuân thủ các qui luật sau:
“Mọi người đều có cơ hội để được nói”
“Đừng phát biểu cho đến khi bạn được yêu cầu”
431
“Đừng độc thoại trong suốt cuộc hội thoại”

“Giơ tay lên nếu bạn có ý kiến phát biểu”
“Đừng chen ngang khi người khác đang phát biểu”
“Đừng ngủ gục khi người khác đang phát biểu”
Môi trường chia sẻ có dây Môi trường chia sẻ không dây
(Ethernet…) (Wifi…)
Mạng vệ tinh Buổi tiệc liên hoan
Blah, Blah, Blah
ZZ ZZ
Hình 5.9 Các loại môi trường khác nhau

Tương tự, mạng máy tính cũng đặt ra các giao thức điều khiển đa truy
cập để quản lý việc truyền dữ liệu vào kênh truyền của các nút mạng.
Như biểu diễn trong hình 5.9, các giao thức điều khiển đa truy cập có
thể được áp dụng trong nhiều môi trường truyền khác nhau, bao gồm
các mạng LAN có dây và không dây, các mạng vệ tinh. Thực chất các
nút mạng truy cập thông qua các bộ giao tiếp mạng, nhưng để đơn
giản hóa vấn đề chúng ta xem các nút mạng chính là các thiết bị gửi
và nhận dữ liệu từ kênh truyền. Trong thực tế, hàng trăm hoặc thậm
432
chí hàng ngàn nút mạng có thể trao đổi dữ liệu trên chung một kênh
truyền quảng bá.
Bởi vì tất cả các nút mạng đều có thể phát tín hiệu, sẽ có trường hợp
hai hoặc nhiều hơn các nút mạng phát dữ liệu cùng một thời điểm. Khi
điều này xả ra, tất cả các nút mạng sẽ nhận được dữ liệu của nhiều gói
tin đan xen lẫn nhau, gọi là hiện tượng xung đột các gói tin. Khi đó,
các nút mạng sẽ không thể phân biệt được một bit dữ liệu nhận được
là của gói tin nào, do đó không thể nhận được hoàn chỉnh bất kỳ gói
tin nào cả, dẫn đến tất cả các gói tin đều bị “mất” và gây nên sự hao
phí băng thông trên kênh truyền quảng bá. Trường hợp kênh truyền
càng có nhiều nút mạng thì hiện tượng xung đột càng dễ xảy ra và
lượng băng thông hao phí càng lớn.
Vai trò điều phối việc truyền dữ liệu trên môi trường quảng bá sẽ
được giao cho các giao thức điều khiển đa truy cập. Trong hơn 40 năm
qua, đã có hàng ngàn công trình nghiên cứu và hàng trăm các luận văn
tiến sĩ nghiên cứu về các giao thức này. Với việc ra đời của các môi
trường truy cập kiểu mới, đặc biệt là các môi trường không dây, việc
nghiên cứu về các giao thức điều khiển đa truy cập càng được chú
trọng.
Chúng ta có thể phân chia các giao thức điều khiển đa truy cập vào ba
hạng mục khác nhau: các giao thức chia sẻ kênh truyền, các giao thức
truy cập ngẫu nhiên và các giao thức truy cập luân phiên lấy lượt (luân
phiên).
Một cách lý tưởng, các giao thức điều khiển đa truy cập khi áp dụng
trên kênh truyền dùng chung có băng thông R bps phải thỏa các tính
chất:
• Khi chỉ có một nút mạng truyền tín hiệu, nút mạng đó phải đạt
được thông lượng R bps
• Khi có M nút mạng truyền tín hiệu, mỗi nút mạng phải đạt thông
lượng R/M bps. Không nhất thiết mỗi nút mạng phải đạt thông
lượng R/M bps tại mọi thời điểm, tuy nhiên xét trong một khoảng
thời gian đủ dài, thông lượng trung bình mỗi nút mạng phải đạt
R/M bps.
433
• Giao thức phải hoạt động theo cơ chế không tập trung, nghĩa là
không có một nút mạng chịu trách nhiệm quản lý các nút mạng
khác, dẫn đến nguy cơ ngừng hoạt động của hệ thống khi nút
mạng này bị lỗi.
• Giao thức phải đơn giản, không quá tốn kém trong việc cài đặt
III.1 Các giao thức chia kênh truyền

TDM – chia sẻ kênh theo thời gian (time-division multiplexing) và
FDM – chia sẻ kênh theo tần số (frequency-division multiplexing) là
hai giải pháp thường được sử dụng trong nhóm giao thức chia sẻ kênh
truyền.
Giả sử chúng ta xem xét trường hợp có N thiết bị chia sẻ chung một
kênh truyền có tốc độ truyền tải R bps. Phương pháp TDM chia thời
gian sử dụng kênh truyền thành những khung thời gian (time frames)
và tiếp tục chia đều mỗi khung thời gian này thành N khe thời gian
(time slots). Mỗi khe thời gian được chia cho một thiết bị trong số N
thiết bị truyền dẫn. Mỗi khi một thiết bị có nhu cầu truyền phát một
gói tin, thiết bị sẽ truyền dữ liệu trong khe thời gian được cấp cho
mình. Thông thường, khe thời gian được lựa chọn đủ để truyền hết dữ
liệu của một gói tin. Hình 5-10 minh họa giao thức TDM với 4 thiết
bị. Trong hình minh họa 4 khung thời gian (frame), mỗi khung được
chia nhỏ thành 4 khe thời gian (slot), mỗi khe thời gian được dành
riêng cho mỗi thiết bị.
434
FDM
4 KHz.
.
.
.
.
.
Link
.
.
4 KHz.
TDM
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
Khe thời gian

Khung thời gian
Hình 5.10: Ví dụ về FDM và TDM trong trường hợp có 4 nút mạng
TDM có một số lợi điểm rõ rệt như triệt tiêu hiện tượng xung đột tín
hiệu, chia sẻ kênh truyền công bằng với các nút mạng: Mỗi nút mạng
được cấp cho khả năng truyền tải R/N bps trong suốt khe thời gian của
mình. Tuy nhiên, TDM có hai nhược điểm tương đối rõ rệt. Khi nút
mạng chỉ có khả năng truyền tối đa với tốc độ R/N bps cho dù đó là
nút mạng duy nhất có nhu cầu truyền dữ liệu trên kênh truyền. Nhược
điểm thứ nhì, một nút mạng luôn luôn phải đợi đến lượt mình để được
truyền dữ liệu cho dù các nút mạng khác không có nhu cầu truyền dữ
liệu.
Trong khi TDM chia sẻ kênh truyền theo thời gian, kỹ thuật FDM chia
một kênh truyền tốc độ R bps thành N kênh truyền với giải tần khác
nhau, mỗi kênh truyền có băng thông R/N bps và chia mỗi kênh
truyền cho một nút mạng trong số N nút mạng có nhu cầu sử dụng
kênh truyền. FDM có chung những đặc điểm với kỹ thuật TDM như
triệt tiêu hiện tượng xung đột dữ liệu, chia sẻ kênh truyền công bằng
giữa các nút mạng. Tuy nhiên, những nhược điểm của TDM, như việc
một nút mạng bị giới hạn sử dụng tối đa kênh truyền có băng thông
R/N ngay cả khi đó là nút duy nhất có nhu cầu truyền dữ liệu vẫn còn
tồn tại.
435
Kỹ thuật thứ ba thường gặp là kỹ thuật chia sẻ kênh truyền theo mã

(CDMA – code division multiple access). Trong khi TDM và FDM
chia sẻ kênh truyền theo tần số hoặc các khe thời gian, CDMA gán
cho mỗi nút mạng một mã số riêng. Nếu các mã số này được lựa chọn
cẩn thận, các mạng CDMA sẽ hỗ trợ nhiều nút mạng gửi dữ liệu cùng
lúc và các nút mạng đích vẫn nhận được dữ liệu chính xác (nếu biết
trước mã của thiết bị phát) bất chấp việc đan xen giữa các tín hiệu
phát đồng thời. Kỹ thuật CDMA đã được áp dụng trong quân sự trong
một khoảng thời gian dài và ngày nay áp dụng rộng rãi trong dân sự,
đặc biệt trong các mạng điện thoại di động.
III.2 Các giao thức truy cập ngẫu nhiên

Nhóm giao thức thường được sử dụng để khai thác môi trường truyền
dẫn chia sẻ (shared-media) là nhóm giao thức truy xuất ngẫu nhiên.
Trong loại giao thức này, mỗi nút mạng khi truyền dữ liệu sẽ sử dụng
toàn bộ băng thông của đường truyền, ở đây là R bps. Khi có xung đột
xảy ra, mỗi nút mạng bị ảnh hưởng bởi quá trình xung đột sẽ liên tục
truyền lại toàn bộ gói tin cho đến khi có thể hoàn tất việc truyền dữ
liệu mà không gặp xung đột. Tuy nhiên, khi một nút mạng gặp tình
trạng xung đột dữ liệu, không nhất thiết nút mạng đó phải truyền lại
dữ liệu ngay lập tức mà sẽ chờ một khoảng thời gian ngẫu nhiêu trước
khi bắt đầu việc truyền lại. Mỗi nút mạng sẽ lựa riêng một khoảng thời
gian chờ ngẫu nhiên cho mình. Vì lý do khoảng thời gian được chọn
độc lập tại mỗi nút mạng, sẽ có trường hợp một nút mạng chọn
khoảng thời gian chờ đủ lớn để các nút khác có thể hoàn tất việc
truyền dữ liệu và không xảy ra xung đột.
Đã có rất nhiều giải pháp được đề xuất trong nhóm các giao thức truy
cập ngẫu nhiên, trong tài liệu sẽ giới thiệu một số giao thức phổ biến
như ALOHA và carrier sense multiple access (CSMA). Trong đó, giao
thức CSMA là giao thức được sử dụng rộng rãi trong các mạng
Ethernet được trình bày ở phần sau.
Slotted ALOHA
436
ALOHA là một trong những giao thức đơn giản trong nhóm các giao
thức truy cập ngẫu nhiên. Để tìm hiểu giao thức Slotted ALOHA,
chúng ta chấp nhận một số giả định sau:
• Mỗi gói tin gồm chính xác L bits
• Thời gian truy cập được chia thành những khe thời gian có kích
thước L/R giây, đây là thời gian cần thiết để truyền hết một gói
tin.
• Mỗi nút mạng chỉ truyền dữ liệu tại thời điểm bắt đầu một khe
thời gian
• Các nút mạng đều có cơ chế đồng bộ với nhau, điều này giúp các
nút biết chính xác thời điểm bắt đầu một khe thời gian.
• Nếu có hai hoặc nhiều gói tin bị xung đột, tất cả các nút mạng đều
nhận biết xung đột này trước khi một khe thời gian kết thúc.
Gọi p là một xác suất, nghĩa là một số từ 0 đến 1. Hoạt động của giao
thức Slotted ALOHA có thể được mô tả như sau:
• Khi có gói tin cần truyền, nút mạng sẽ đợi cho đến bắt đầu một
khe thời gian mới và truyền toàn bộ gói tin trong khe thời gian đó.
• Nếu không có xung đột xảy ra, nút mạng xem như đã truyền
thành công gói tin và không cần xem xét việc truyền lại dữ liệu.
• Nếu có xung đột xảy ra, nút mạng sẽ phát hiện được xung đột
trước khi khe thời gian kết thúc. Nút mạng sẽ truyền lại gói tin ở
các khe thời gian kế tiếp với xác suất p cho đến khi có thể truyền
thành công.
Để hiểu rõ luật thứ 3, ta tưởng tượng mỗi khi có xung đột xảy ra mỗi
nút mạng sẽ phát sinh một số ngẫu nhiên từ 0 đến 1. Nếu số này nhỏ
hơn hoặc bằng số p, nút sẽ truyền lại gói tin ngược lại nếu số phát sinh
lớn hơn p nút mạng sẽ không truyền lại ở ngay khe thời gian kế tiếp
và tiếp tục việc phát sinh số ngẫu nhiên ở các khe thời gian sau đó.
Mỗi nút mạng sẽ phát sinh số ngẫu nhiên hoàn toàn độc lập với nhau.
Giao thức Slotted ALOHA có nhiều ưu điểm: Ngược lại với giao thức
TDM và FDM, Slotted ALOHA cho phép một nút mạng được truyền
437
với tốc độ tối đa R bps khi đó là nút mạng duy nhất sử dụng kênh
truyền. Giao thức Slotted ALOHA đòi hỏi các nút mạng phải đồng bộ
với nhau để nhận biết thời gian bắt đầu và kết thúc các khe thời gian.
Chúng ta sẽ đánh giá hiệu năng của giao thức Slotted ALOHA khi có
N nút mạng sử dụng chung kênh truyền. Khi có nhiều nút mạng, sẽ có
nhiều khe thời gian có nhiều nút mạng cùng truyền dữ liệu dẫn đến
xung đột, ngược lại cũng có nhiều khe thời gian sẽ không có bất kỳ
nút mạng nào truyền dẫn vì giá trị xác suất ngẫu nhiên. Khe thời gian
hiệu dụng (successful slot) là khe thời gian chỉ có duy nhất một nút
mạng truyền dữ liệu.
Bằng nghiên cứu xác suất, người ta đã chứng minh hiệu năng của giao
thức Slotted ALOHA trong trường hợp có N nút mạng là Np(1-p)N-1.
Khi số lượng nút mạng nhiều, giá trị N tiến đến vô cực sẽ cho hiệu
năng tối đa của hệ thống đạt 1/e=0.37, nghĩa là khi có nhiều nút mạng
tham gia thì số lượng khe thời gian hiệu năng tối đa là 37%. Nghĩa là
với một hệ thống mạng 100Mbps, khi xét trên thời gian dài thông
lượng hệ thống chỉ đạt khoảng 37Mbps.
Nút 1 1 1 1 1
Nút 2 2 2 2
Nút 3 3 3 3
C E C S E C E S S
Hình 5.11: Slotted ALOHA với 3 nút mạng

C: collision slot – khe thời gian có xung đột ; S: successful slot – khe
thời gian truyền thành công; E: empty slot – khe thời gian không có
truyền dẫn
ALOHA
438
Giao thức Slotted ALOHA có một yêu cầu là tất cả các nút mạng đều
phải được đồng bộ để nhận biết thời điểm bắt đầu một khe thời gian,
trong khi đó giao thức ALOHA thuần túy không cần chia thành những
khe thời gian và không cần có một cơ chế quản lý tập trung để đồng
bộ các nút mạng. Trong giao thức ALOHA, khi một gói tin được
chuyển xuống tầng Data Link, nút mạng sẽ ngay lập tức truyền toàn
bộ gói tin vào kênh truyền dùng chung. Nếu có xung đột phát sinh, nút
mạng sẽ ngay lập tức (sau khi hoàn tất việc truyền gói tin bị xung đột)
truyền lại gói tin với xác suất p. Nếu không truyền lại ngay, nút mạng
sẽ đợi một khoảng thời gian bằng với thời gian cần để truyền hết gói
tin. Sau đó ngay lập tức truyền lại gói tin này với xác suất p, với xác
suất 1-p còn lại sẽ tiếp tục đợi thêm một khoảng thời gian đủ để truyền
hết gói tin rồi sau đó mới truyền lại.
Sẽ trùng lắp với phần Sẽ trùng lắp với phần
đầu gói tin của nút i sau gói tin của nút i
Gói tin của nút i
Thời gian
t0 - 1 t0 t0 + 1
Hình 5.12: Sự đan xen trong khi truyền dữ liệu của giao thức ALOHA
thuần túy
Để xác định được hiệu năng tối đa của giao thức ALOHA thuần túy,
chúng ta sẽ tập trung vào một nút mạng riêng lẻ. Chúng ta cũng sẽ đặt
ra các giả định như khi nghiên cứu Slotted ALOHA, và xem thời gian
cần để truyền một gói tin là một đơn vị thời gian. Tại một thời điểm
bất kỳ, xác suất để một nút mạng truyền dữ liệu là p. Giả sử nút mạng
bắt đầu truyền gói tin tại thời điểm t0. Trong hình 5.12 chúng ta thấy,
để gửi thành công gói tin này, không một nút mạng nào khác được
phép bắt đầu truyền tin trong khoảng thời gian [t0-1,t0], vì bất kỳ sự
truyền tin nào trong thời điểm này sẽ gây chồng lấp lên phần đầu gói
439
tin của nút mạng i. Xác suất để tất cả các nút mạng khác đều không
truyền tin trong khoảng thời gian này là (1-p)N-1. Tương tự, không một
nút mạng nào khác được phép bắt đầu truyền dữ liệu khi nút mạng i
đang truyền, vì các tín hiệu sẽ chồng lắp lên phần cuối của gói tin
đang truyền. Xác suất để các nút mạng khác không truyền trong
khoảng thời gian này cũng là (1-p)N-1. Như vậy, xác suất để nút mạng i
có thể truyền thành công gói tin là p(1-p)2(N-1). Bằng cách tính giới hạn
như khi nghiên cứu Slotted ALOHA, khi giá trị N tiến đến vô cực hiệu
năng tối đa của hệ thống sẽ là , bằng phân nửa của giao thức Slotted
ALOHA. Đây là giá phải trả khi sử dụng giao thức đơn giản, không
cần đồng bộ giữa các nút mạng.
Carrier Sense Multiple Access
Trong cả hai phương pháp Slotted ALOHA và ALOHA thuần túy,
việc quyết định một nút mạng có được phép truyền dữ liệu hay không
hoàn toàn độc lập với các nút mạng khác trong cùng kênh truyền. Cụ
thể hơn, một nút mạng sẽ truyền tin vào kênh truyền và không quan
tâm đến việc có một nút mạng khác cũng đang truyền tin hay không,
ngoài ra nút mạng sẽ không ngừng truyền dữ liệu nếu bị một nút mạng
khác chen ngang. Có thể hình dung giống như trong một buổi hội
thảo, giao thức ALOHA hoạt động như một diễn giả thô lỗ liên tục
phát biểu bất chấp có người khác đang nói hay không. Rõ ràng, việc
truyền tin khi có một thiết bị khác đang truyền sẽ dẫn đến hiện tượng
hao phí băng thông trên kênh truyền.
Trong giao tiếp hàng ngày, con người chúng ta thường tuân thủ 2 qui
định sau đây:
• Lắng nghe trước khi phát biểu: Nếu có người nào khác đang nói,
chúng ta không chen ngang mà phải đợi đến khi họ kết thúc.
Trong mạng máy tính, điều này được gọi là lắng nghe đường
truyền - carrier sense, một nút mạng phải lắng nghe và đợi cho
kênh truyền trống trước khi bắt đầu phát tín hiệu.
• Nếu khi chúng ta đang nói, có một người khác chen ngang ngay
lập tức ngừng phát biểu. Trong mạng máy tính, điều này được gọi
440
là phát hiện xung đột - collision dectection: một nút mạng đang
truyền phát tín hiệu nếu phát hiện có nút mạng khác cũng truyền
tín hiệu sẽ ngay lập tức dừng việc truyền và thực hiện một vài
bước tính toán để quyết định thời điểm truyền lại dữ liệu.
Hai qui luật trên cũng chính là nguyên tắc chính của các giao thức
trong họ CSMA (carrier sense multiple access) và CSMA/CD (CSMA
và collision detection). Có rất nhiều giao thức theo hướng tiếp cận
CSMA và CSMA/CD đã được đề xuất. Chúng ta sẽ tìm hiểu chi tiết
về cách hoạt động của giao thức CSMA/CD áp dụng trong mạng
Ethernet ở mục 5.5. Ở phần này, chúng ta sẽ tìm hiểu những đặc điểm
chính và quan trọng nhất của họ giao thức CSMA và CSMA/CD.
Câu hỏi đầu tiên được đặt ra là nếu mội nút mạng đều lắng nghe kênh
truyền trước khi truyền dữ liệu, tại sao hiện tượng xung đột lại có thể
xảy ra? Câu trả lời có thể được minh họa bằng cách sử dụng một lược
đồ thời gian. Hình 5.13 minh họa một lược đồ thời gian gồm 4 nút
mạng (A, B, C và D) cùng kết nối vào một kênh truyền dạng bus. Trục
nang minh họa vị trí từng nút trong kênh truyền, trục dọc minh họa
thời gian.
Tại thời điểm t0, nút mạng B nhận thấy kênh truyền rỗi, không có nút
mạng nào đang truyền dữ liệu. Do đó, nút B bắt đầu truyền, dữ liệu sẽ
lan truyền theo cả 2 hướng trên kênh truyền. Trục dọc thời gian mô tả
khoảng thời gian cần thiết để các bit từ B lan đến các điểm khác nhau
trên kênh truyền (vận tốc lan truyền bit đạt gần bằng vận tốc ánh
sáng). Tại thời điểm t1 (t1>t0), nút D cần truyền một gói tin. Mặc dù tại
thời điểm t1 này, nút mạng B vẫn đang truyền dữ liệu nhưng các tín
hiệu vẫn chưa đến được điểm D, và D sẽ vẫn cảm nhận được là kênh
truyền rỗi. Theo nguyên lý CSMA, nút mạng D bắt đầu truyền dữ liệu.
Sau đó một khoảng thời gian, dữ liệu từ truyền đến D và phát sinh
xung đột. Theo hình 5.13, chúng ta có thể nhận thấy thời gian lan
truyền dữ liệu (propagation delay) trên kênh truyền – là thời gian cần
thiết để tín hiệu đi từ một điểm đến một điểm khác trên kênh truyền -
ảnh hưởng rất lớn đến việc phát hiện xung đột sớm và quyết định đến
hiệu năng của việc điều khiển đa truy cập. Thời gian lan truyền càng
441
dài, khả năng một nút mạng không phát hiện được một nút mạng khác
đang truyền dữ liệu càng cao.
Trong hình 5.13, các nút mạng không thực hiện theo cơ chế phát hiện
xung đột (collision detection), cả nút mạng B và D vẫn tiếp tục truyền
gói tin mặc dù đã có hiện tượng xung đột. Khi một nút mạng cài đặt
cơ chế phát hiện xung đột, nó sẽ ngưng việc truyền dữ liệu ngay khi
phát hiện thấy một nút mạng khác cũng đang truyền dữ liệu. Hình
5.14 minh họa hoàn cảnh tương tự hình 5.13, nhưng ở đây các nút
mạng ngừng việc truyền dữ liệu sau một khoảng thời gian ngắn khi
phát hiện thấy xung đột. Việc cài đặt cơ chế phát hiện xung đột giúp
một nút mạng không truyền đi các dữ liệu vô ích trên đường truyền, từ
đó sẽ tăng hiệu năng sử dụng kênh truyền. Mạng Ethernet trình bày ở
mục 5.5 sử dụng cơ chế CSMA kết hợp phát hiện xung đột.
Space
A B C D
t0
t1
Time Time
Hình 5.13: Lược đồ không gian – thời gian của hai nút mạng gây xung
đột dữ liệu trong cơ chế CSMA
442
III.3 Các giao thức lấy lượt

Có hai thuộc tính được những nhà thiết kế mong muốn trong việc thiết
kế các giao thức chia sẻ đường truyền: (1) Nếu chỉ có một nút mạng
trên kênh truyền, nút mạng đó sẽ đạt thông lượng R bps; (2) Nếu có N
nút mạng trên kênh truyền, mỗi nút mạng sẽ có thông lượng xấp xỉ
R/N bps. Các giao thức như ALOHA, CSMA chỉ đạt được yêu cầu (1)
nhưng chưa thỏa mãn được yêu cầu (2). Nhóm giao thức truy cập
kênh truyền luân phiên được đề ra để đáp ứng cả 2 yêu cầu này của
việc thiết kế. Có khá nhiều giải pháp được đề xuất trong nhóm các
giao thức dạng này, ở đây xin giới thiệu về 2 giao thức phổ biến là
giao thức polling và giao thức chuyển thẻ bài (token-passing).
A B C D
t0
t1
Collision detect/
abort time
Time Time
443
Hình 5.14: Cơ chế CSMA kết hợp phát hiện xung đột
Giao thức polling

Giao thức polling đòi hỏi phải có một nút mạng được chỉ định là nút
master. Nút mạng master sẽ điều khiển lần lượt mọi node theo mô
hình round robin. Đầu tiên nút master sẽ gửi một thông điệp cho nút 1,
thông báo số lượng gói tin tối đa nút mạng 1 có thể truyền. Sau khi nút
mạng 1 đã truyền được một số lượng gói tin (trong khoảng từ 0 đến số
lượng gói tin tối đa), nút master sẽ liên hệ với nút 2, báo cho nút 2 biết
số lượng gói tin tối đa nút 2 có thể truyền (nút master có thể phát hiện
việc một nút mạng đã truyền hết các gói tin bằng cách phát hiện không
còn tín hiệu trên đường truyền). Quá trình tiếp tục như vậy, nút master
sẽ lần lượt liên hệ và điều khiển tất cả các nút mạng. Giao thức polling
triệt tiêu hiện tượng xung đột dữ liệu và không gây xuất hiện các khe
thời gian trống (không có dữ liệu) trong các giao thức truy xuất ngẫu
nhiên. Do đó giao thức này cho hiệu năng cao hơn các giao thức đề
cập trước. Tuy nhiên loại giao thức này vẫn có một số điểm yếu: điểm
yếu đầu tiên là thời gian trễ trong quá trình điều khiển, cụ thể là thời
gian cần để báo cho một nút mạng biết nó có quyền phát tín hiệu. Ví
dụ nếu chỉ có một nút mạng tham gia quá trình truyền, nút mạng này
sẽ không đạt được thông lượng tối đa R bps vì sau khi truyền được
một số lượng frame nhất định sẽ bị nút master yêu cầu ngừng để điều
khiển các nút mạng khác dù các nút mạng này không có nhu cầu
truyền tín hiệu. Điểm yếu thứ 2 đó là sự lệ thuộc vào nút mạng master,
nếu nút mạng này bị hỏng sẽ dẫn đến tê liệt toàn bộ kênh truyền.
Giao thức chuyển thẻ bài
Giao thức thứ 2 là giao thức chuyển thẻ bài token-passing. Trong giao
thức này không xuất hiện nút mạng master. Một gói tin điều khiển có
kích thước nhỏ, được gọi là thẻ bài (token) sẽ được luân chuyển lần
lượt giữa các nút mạng theo thứ tự nhất định, ví dụ nút mạng 1 sẽ
chuyển thẻ bài cho nút 2, nút 2 chuyển cho nút 3 và nút mạng N sẽ
chuyển ngược lại cho nút 1. Khi một nút mạng giữ thẻ bài, nút mạng
này sẽ giữ thẻ bài nếu có nhu cầu truyền dữ liệu, nếu không có nhu
cầu nút mạng sẽ chuyển ngay thẻ bài cho nút kế tiếp. Khi giữ thẻ bài,
nút mạng được phép truyền tối đa một số lượng gói tin qui định trước,
sau khi truyền xong sẽ chuyển thẻ bài cho nút kế tiếp. Giao thức
444
chuyển thẻ bài cho thông lượng mạng cao và không bị phụ thuộc vào
bất kỳ điều khiển tập trung nào. Tuy nhiên giao thức này cũng có
những điểm yếu: Nếu một nút mạng bị lỗi thì toàn bộ kênh truyền có
thể ngưng hoạt động, hoặc nếu một út mạng không trả thẻ bài khi đã
truyền xong dữ liệu cũng sẽ gây ngưng trệ toàn bộ kênh truyền.
III.4 Mạng cục bộ
Các giao thức điều khiển đa truy cập thường được áp dụng trong nhiều
môi trường phát song quảng bá khác nhau. Các giao thức này được sử
dụng trong môi trường mạng không dây, vệ tinh,… là loại mạng mà
các nút đều phát tín hiệu sử dụng chung một phổ tần số. Các giao thức
này hiện đang được sử dụng trong kênh truyền tải hướng lên
(upstream channel) cho mạng cáp truy cập Internet và được sử dụng
rộng rãi trong các mạng cục bộ (LAN).
Mạng LAN là mô hình mạng mà các máy tính được tập trung trong
cùng một vùng địa lý, ví dụ như một tòa nhà hay khuôn viên của một
trường đại học. Khi một người dùng kết nối mạng Internet từ một
trường đại học, kết nối này sẽ theo mạng LAN đến các router ngoại
biên và sau đó truyền lên Internet, được minh họa trong hình 5.15.
Tốc độ truyền dữ liệu R trong phần lớn các mạng LAN là rất cao. Kể
cả ngay trong giai đoạn những năm 1980, mạng LAN 10 Mbps là khá
phổ biến, ngày nay mạng lạn 100 Mbps và 1 Gbps được sử dụng phổ
biến, mạng LAN 10 Gbps cũng đã xuất hiện.
Web Server
User
hosts Router
Internet
LAN
445
Hình 5.15: Các máy tính kết nối Internet thông qua mạng LAN, trong
đó các máy tính và bộ định tuyến kết nối chung trên một kênh truyền
quảng bá.
Vào những năm 1980 và đầu những năm 1990, tồn tại song song hai
kỹ thuật mạng LAN phổ biến. Mô hình mạng thứ nhất được gọi là
Ethernet LAN (còn được gọi là mạng LAN chuẩn IEEE 802.3), dựa
trên kỹ thuật truy cập ngẫu nhiên. Mô hình mạng thứ nhì là mô hình
mạng sử dụng cơ chế chuyển thẻ bài, gồm có mạng token ring (còn
được gọi là mạng chuẩn IEEE 802.5) và mạng FDDI (fiber distributed
data interface). Chúng ta sẽ trao đổi kỹ hơn về mạng Ethernet ở phần
sau, do đó ở phần này sẽ tập trung chính vào mạng theo mô hình
chuyển thẻ bài. Tuy nhiên phần giới thiệu về mạng chuyển thẻ bài
cũng sẽ khá vắn tắt, vì dưới áp lực cạnh tranh của mạng Ethernet, mô
hình mạng này ngày nay hầu như đã không được sử dụng nữa.
Trong môi trường mạng chuyển thẻ bài, chúng ta có N nút mạng (gồm
cả máy tính và router) kết nối với nhau trong một mạng cục bộ thành
một hình vòng tròn bởi các kết nối trực tiếp. Tùy theo đồ hình mạng
cụ thể sẽ qui định thứ tự các nút mạng trong việc chuyển thẻ bài. Khi
một nút mạng nhận được thẻ bài, nút mạng này được phép gửi gói tin
lên đường truyền, gói tin sẽ lần lượt chuyển khắp vòng và hình thành
nên một môi trường mạng quảng bá “ảo”. Khi gói tin được chuyển lần
lượt theo vòng sẽ đến được nút mạng đích. Khi gói tin quay trở về nút
mạng nguồn, gói tin sẽ được gỡ bỏ khỏi vòng. Mạng FDDI được thiết
kế cho các mạng có kích thước lớn hơn mạng LAN truyền thống, ví
dụ như các mạng thành thị (MAN – metropolitan are networks). Với
các mạng trải dài trên vài km như FDDI, sẽ rất bất tiện nếu đợi đến
khi gói tin quay trở về nút mạng nguồn mới bị loại bỏ. FDDI qui định
nút mạng đích sẽ là nút mạng loại bỏ gói tin ra khỏi vòng. Vì vậy, khắt
khe mà nói FDDI không phải là một môi trường mạng quảng bá, vì
không phải mọi nút mạng đều nhận được mọi gói tin trên mạng.
IV. Đánh địa chỉ tầng Link

Nút mạng, bao gồm máy tính và bộ định tuyến, đều có địa chỉ tại tầng
Liên kết. Bên cạnh đó, các nút mạng cũng có địa chỉ tại tầng Mạng.
Câu hỏi đặt ra là tại sao phải tồn tại song song địa chỉ ở cả tầng Mạng
446
và tầng Liên kết? Trong phần này, bên cạnh việc tìm hiểu cấu trúc địa
chỉ tại tầng Liên kết chúng ta sẽ trả lời câu hỏi tại sao các địa chỉ này
là hữu ích và không thể thiếu. Phần này cũng sẽ giới thiệu về giao
thức ARP (Address Resolution Protocol) đảm nhận vai trò phân giải
một địa chỉ IP ở tầng Mạng thành địa chỉ tại tầng Liên kết.
IV.1 Địa chỉ MAC

Nói chính xác hơn, không phải một nút mạng mà là bộ giao tiếp mạng
trên nút sẽ mang một địa chỉ tại tầng Liên kết. Hình 5.16 mô tả địa chỉ
tại tầng Liên kết của các máy tính trong một mạng cục bộ, các địa chỉ
này thường được gọi là địa chỉ LAN, địa chỉ vật lý hoặc địa chỉ MAC.
Bởi vì địa chỉ MAC được sử dụng phổ biến nhất, ở những phần sau
chúng ta qui ước tên gọi địa chỉ MAC để nói về địa chỉ ở tầng Liên
kết. Trong hầu hết các mạng LAN (gồm mạng Ethernet cũng như các
mạng không dây 802.11), địa chỉ MAC dài 6 byte và có thể mang tối
đa 248 giá trị khác nhau. Như được thể hiện trong hình 5.16, các giá trị
địa chỉ MAC thường được diễn tả dưới hạng số thập lục phân, mỗi
byte địa chỉ được viết dưới dạng hai số thập lục. Mặc dù, địa chỉ MAC
được qui định cố định cho mỗi bộ giao tiếp mạng, hoàn toàn có thể
dùng phần mềm để thay đổi địa chỉ này. Tuy nhiên, trong phần này
chúng ta xem như địa chỉ MAC của một bộ giao tiếp là không thể thay
đổi.
447
1A – 23 – F9 – CD – 06 – 9B
5C – 66 – AB – 90 – 75 – B1 88 – B2 – 2F – 54 – 1A – 0F
49 – BD – D2 – C7 – 56 – 2A
Hình 5.16: Mỗi bộ giao tiếp mạng kết nối vào mạng LAN sử dụng
một địa chỉ MAC riêng biệt
Một tính chất quan trọng của địa chỉ MAC là không tồn tại bất kỳ hai
bộ giao tiếp nào có trùng địa chỉ. Điều này hoàn toàn có thể đạt được
mặc dù có rất nhiều nhà sản xuất khác nhau thuộc nhiều quốc gia khác
nhau tham gia sản xuất bộ giao tiếp mạng. Tổ chức IEEE là tổ chức
chịu trách nhiệm quản lý không gian địa chỉ MAC. Mỗi một công ty
khi muốn tham gia sản xuất bộ giao tiếp mạng đều phải mua một vùng
không gian gồm 224 địa chỉ từ IEEE. Để làm được điều này, IEEE chia
địa chỉ MAC làm hai phần, phần đầu gồm 24 bit đầu, gọi là OUI
(Organizationally Unique Identifier) dùng để định danh cho các nhà
sản xuất khác nhau. Mỗi nhà sản xuất sẽ có số OUI khác nhau, nhà
sản xuất được phép sử dụng vùng 24 bit còn lại để định danh cho các
bộ giao tiếp mạng được họ sản xuất.
Địa chỉ MAC có cấu trúc phẳng (khác với các cấu trúc phân cấp) và sẽ
không thay đổi bất chấp vị trí thật sự của bộ giao tiếp mạng. Điều này
có nghĩa, bộ giao tiếp mạng của một máy tính xách tay dù có di
chuyển đến nhiều nơi khác nhau nhưng vẫn luôn giữ nguyên địa chỉ
MAC. Xin nhắc lại, điều này hoàn toàn trái ngược với địa chỉ IP. Địa
chỉ IP là một địa chỉ có cấu trúc phân cấp (gồm địa chỉ đường mạng
448
và địa chỉ máy tính), địa chỉ này sẽ thay đổi khi thiết bị gia nhập vào
các đường mạng khác nhau. Trong cuộc sống, địa chỉ MAC có thể
xem như số chứng minh thư của một cá nhân và địa chỉ IP xem như
địa chỉ nhà của cá nhân đó. Trong suốt quá trình hoạt động của người
này, địa chỉ nhà có thể liên tục thay đổi nhưng số chứng minh thư thì
vẫn cố định. Trong cuộc sống, một người cần thiết phải có cả số
chứng minh thư và địa chỉ nhà. Cũng như vậy, việc một máy tính có
cả địa chỉ IP và địa chỉ MAC là điều cần thiết.
Khi một bộ giao tiếp muốn gửi dữ liệu cho một bộ giao tiếp khác, bộ
giao tiếp nguồn phải chèn thông tin địa chỉ MAC đích đến vào gói tin
rồi truyền gói tin vào mạng LAN. Nếu mạng LAN hoạt động theo cơ
chế quảng bá (mạng không dây 802.11 và một số mô hình mạng
Ethernet), tất cả các bộ giao tiếp mạng sẽ đều nhận được và xử lý gói
tin. Mỗi bộ giao tiếp mạng lúc này sẽ kiểm tra địa chỉ MAC đích trong
gói tin có trùng khớp với địa chỉ MAC của chính nó hay không. Nếu
trùng khớp, bộ giao tiếp mạng sẽ tách thông tin gói tin của tầng Mạng
và chuyển thông tin này cho các tầng bên trên xử lý (thông qua các
ngắt – interrupt). Nếu địa chỉ không trung khớp, bộ giao tiếp đơn
thuần hủy gói tin và không chuyển nội dung lên các tầng trên. Như
vậy, chỉ có nút mạng đích trong nhánh mạng sẽ bị ngắt và xử lý gói
tin.
Tuy nhiên, trong một số trường hợp nút mạng gửi sẽ muốn tất cả các
nút mạng khác xử lý thông tin mà nó gửi đi. Trường hợp này, nút
mạng gửi sẽ sử dụng địa chỉ MAC dạng quảng bá để điền vào phần
địa chỉ MAC đích của gói tin. Với mô hình mạng LAN sử dụng địa
chỉ MAC dài 6 byte (ví dụ như mạng Ethernet và chuyển thẻ bài), địa
chỉ quảng bá sẽ là chuỗi 48 bit giá trị 1 (viết dưới dạng thập lục sẽ à
FF-FF-FF-FF-FF-FF).
IV.2 Giao thức phân giải địa chỉ (ARP)
Bởi vì tồn tại song song cả địa chỉ ở tầng Mạng (ví dụ như địa chỉ IP)
và địa chỉ ở tầng Liên kết (ví dụ như địa chỉ MAC), chúng ta có nhu
cầu cần phân giải giữa hai địa chỉ này. Trong mạng Internet, giao thức
ARP sẽ đảm nhận vai trò này.
449
Để hiểu rõ hơn vai trò của giao thức ARP, chúng ta xem xét mô hình
mạng ở hình 5.17. Trong mô hình này, mỗi máy tính sẽ có một địa chỉ
IP và bộ giao tiếp mạng trên máy tính sẽ có một địa chỉ MAC phân
biệt. Như thường lệ, địa chỉ IP được viết dưới dạng các số thập nhân,
địa chỉ MAC được thể hiện dưới dạng thập lục. Giả sử máy tính có IP
222.222.222.220 muốn gửi một gói tin IP đến máy 222.222.222.222.
Trong ví dụ này, cả máy tính nguồn và đích đều nằm trong cùng một
đường mạng. Để gửi gói tin, nút mạng nguồn không chỉ cần biết thông
tin địa chỉ IP mà còn cần phải điền cả địa chỉ MAC của nút mạng đích
vào phần header của gói tin tại tầng Liên kết.
1A – 23 – F9 – CD – 06 – 9B
IP: 222.222.222.220
5C – 66 – AB – 90 – 75 – B1 88 – B2 – 2F – 54 – 1A – 0F
IP: 222.222.222.221
IP: 222.222.222.223
49 – BD – D2 – C7 – 56 – 2A
IP: 222.222.222.222
Hình 5.17: Mỗi nút mạng sẽ có một địa chỉ IP, mỗi bộ giao tiếp sẽ có
một địa chỉ MAC
Câu hỏi đặt ra, làm thế nào nút mạng nguồn có thể biết được địa chỉ
MAC của nút mạng đích khi chỉ biết địa chỉ IP của nút này là
222.222.222.222? Để giải quyết được nhu cầu đó, nút mạng sử dụng
giao thức ARP. Mô-đun đảm nhận vai trò ARP tại nút nguồn sẽ nhận
giá trị đầu vào là địa chỉ IP của nút mạng đích và trả về kết quả là địa
chỉ MAC của nút mạng này. Trong ví dụ trên, nút mạng nguồn sẽ
cung cấp cho mô-đun ARP giá trị địa chỉ IP 222.222.222.222 và nhận
về kết quả địa chỉ MAC 49-BD-D2-C7-56-2A tương ứng.
450
Như vậy, vai trò của giao thức ARP là phân giải địa chỉ IP thành địa
chỉ MAC. Vai trò này cũng gần tương tự như vai trò của giao thức
DNS, nhằm phân giải tên miền thành địa chỉ IP. Tuy nhiên, có sự khác
nhau rất lớn trong cách thức hoạt động của hai giao thức này. Giao
thức DNS phân giải tên miền cho các máy trên toàn mạng Internet,
trong khi đó ARP chỉ có khả năng phân giải được cho các máy tính
trong cùng một đường mạng.
Cơ chế hoạt động của giao thức ARP là như thế nào? Mỗi nút mạng
(máy tính hoặc bộ định tuyến) đều có một bảng ARP trong bộ nhớ.
Bảng này sẽ chứa thông tin ánh xạ giữa địa chỉ IP và địa chỉ MAC.
Hình 5.18 cho thấy hình ảnh tượng trưng của bảng ARP tại máy tính
222.222.222.220. Bảng ARP cũng chứa trường thông tin time-to-live
(TTL – thời gian sống), để biểu thị khi nào dòng ánh xạ tương ứng sẽ
bị xóa khỏi bảng ARP. Lưu ý rằng bảng ARP có thể không chứa hết
thông tin của tất cả các nút mạng trong cùng đường mạng đó, một vài
nút mạng có thông tin đã hết hạn và bị xóa khỏi bảng, hoặc thông tin
của một vài nút mạng khác thậm chí chưa bao giờ được đưa vào bảng.
Thời gian hết hạn thông thường của một dòng trong bảng ARP thông
thường là 20 phút.
Địa chỉ IP Địa chỉ MAC TTL
222.222.222.221 88-B2-2F-54-1A-0F 13:45:00
222.222.222.223 5C-66-AB-90-75-B1 13:52:00
Hình 5.18 Hình ảnh bảng ARP ở nút mạng 222.222.222.220
Giả sử nút mạng 222.222.222.220 muốn gửi thông tin đến một nút
mạng khác trong cùng đường mạng. Trước hết, nó sẽ kiểm tra trong
bảng ARP đã có thông tin về nút mạng cần liên lạc hay chưa, nếu có
sẽ dùng thông tin địa chỉ MAC trong bảng này để điền vào gói tin.
Nếu thông tin về nút mạng đích chưa có trong bảng ARP, nút mạng
gửi sẽ dùng giao thức ARP để phân giải và tìm địa chỉ MAC. Đầu
tiên, nút mạng nguồn sẽ khởi tạo một gói tin đặc biệt, gọi là gói tin
ARP. Gói tin ARP này gồm có một vài trường khác nhau, trong đó
gồm địa chỉ IP, địa chỉ MAC của nút mạng nguồn và đích. Cả gói tin
truy vấn và hồi đáp ARP đều có chung một cấu trúc. Vai trò của gói
451
tin truy vấn ARP là để truy vấn tất cả các nút mạng khác trong đường
mạng để tìm ra địa chỉ MAC ứng với một địa chỉ IP tương ứng.
Trong ví dụ trên, nút mạng 222.222.222.220 sẽ gửi gói tin truy vấn
ARP sử dụng địa chỉ MAC đích là địa chỉ dạng quảng bá. Để dễ hình
dung, gói tin truy vấn ARP giống như một người cầm loa phát ra câu
hỏi giữa một giảng đường lớn: “Số chứng minh thư của người ở địa
chỉ nhà 10 đường Trần Hưng Đạo, Quận 5 là bao nhiêu?” Gói tin truy
vấn ARP vì sử dụng địa chỉ broadcast nên sẽ đến được mọi nút mạng
khác trong cùng đường mạng, các bộ giao tiếp mạng này khi nhận
được sẽ chuyển gói tin cho mô-đun ARP trên thiết bị để xử lý. Mỗi
nút sẽ tự kiểm tra địa chỉ IP của mình có trùng với địa chỉ IP của gói
tin truy vấn ARP hay không, nút mạng duy nhất có địa chỉ trùng sẽ
gửi trả cho máy truy vấn một gói tin hồi đáp ARP. Gói tin hồi đáp
ARP sẽ dùng địa chỉ MAC đích là địa chỉ MAC của nút đã truy vấn,
do đó sẽ trả về đúng nút mạng đã đặt câu hỏi. Gói tin này chứa thông
tin địa chỉ MAC của máy hồi đáp, thông tin này sẽ được đưa vào bảng
ARP của nút mạng đã hỏi. Do đó, nút mạng 222.222.222.220 lúc này
đã đủ thông tin để cấu thành gói tin ở tầng Liên kết và liên lạc với nút
mạng 222.222.222.222.
Gói tin truy vấn ARP sẽ sử dụng cơ chế truyền thông broadcast, gói
tin hồi đáp là một gói tin theo cơ chế giao tiếp giữa hai nút mạng
thông thường. Cơ chế ARP hoạt động hoàn toàn độc lập, không cần sự
can thiệp của người quản trị mạng. Nếu một nút mạng bị ngắt ra khỏi
đường mạng, thông tin về nó sẽ bị xóa khỏi bảng ARP của các nút
khác trong cùng đường mạng.
Sinh viên thường đặt câu hỏi, như vậy ARP thật sự là một giao thức ở
tầng Mạng hay tầng Liên kết? Giao thức này có thể được xem như
hoạt động tại ranh giới của tầng Mạng và tầng Liên kết, vì trong thông
tin của gói tin ARP chứa cả thông tin địa chỉ ở cả hai tầng này.
Gửi một gói tin đến nút mạng ở bên ngoài đường mạng
Chúng ta đã nắm rõ cơ chế hoạt động của ARP khi một nút mạng
muốn liên lạc với một nút mạng khác trong cùng một đường mạng.
Tuy nhiên, khi nút mạng muốn liên lạc với một nút mạng ở bên ngoài
đường mạng đang xét (vượt qua ranh giới của bộ định tuyến), mọi
452
chuyện sẽ phức tạp hơn. Chúng ta xem xét mô hình ở hình 5.19 làm ví
dụ.
74 – 29 – 9C – E8 – FF – 55 88 – B2 – 2F – 54 – 1A – 0F
IP: 222.222.222.221
IP: 111.111.111.111 IP: 111.111.111.110
E6 – E9 – 00 – 17 – BB – 4B
CC – 49 – DE – D0 – AB – 7D 49 – BD – D2 – C7 – 56 – 2A
IP: 222.222.222.222
IP: 111.111.111.112 1A – 23 – F9 – CD – 06 – 9B
IP: 222.222.222.220
Hình 5.19: Hai mạng con kết nối thông qua một bộ định tuyến
Trong mô hình này tồn tại hai loại nút mạng khác nhau: máy tính và
bộ định tuyến. Mỗi máy tính có chính xác một địa chỉ IP và một địa
chỉ MAC gắn với bộ giao tiếp mạng. Bộ định tuyến sẽ có nhiều cổng
giao tiếp, mỗi cổng giao tiếp sẽ có một địa chỉ IP khác nhau. Ngoài ra,
tại mỗi cổng giao tiếp của thiết bị định tuyến sẽ là một bộ giao tiếp
mạng, có một mô-đun ARP để hoạt động riêng. Trong hình 5.19, bộ
định tuyến sẽ có hai cổng, hai bộ giao tiếp mạng, hai địa chỉ IP và hai
mô-đun ARP và dĩ nhiên, mỗi bộ giao tiếp mạng sẽ có một địa chỉ
MAC.
Đường mạng thứ nhất có địa chỉ 111.111.111.0/24 và đường mạng thứ
nhì có địa chỉ 222.222.222.0/24. Giả sử tình huống nút mạng
111.111.111.111 tại đường mạng thứ nhất cần gửi thông tin cho nút
mạng 222.222.222.222 ở đường mạng thứ nhì. Nút mạng nguồn sẽ
chuyển gói tin cần gửi xuống cho bộ giao tiếp mạng. Ở đây, bộ giao
tiếp mạng tại nút nguồn sẽ dùng địa chỉ MAC đích nào để điền vào
gói tin? Một vài người sẽ nghĩ rằng, nên điền địa chỉ MAC của má
tính 222.222.222.222, cụ thể ở đây là 49-BD-D2-C7-56-2A vào phần
địa chỉ đích của gói tin. Tuy nhiên, nhận định này hoàn toàn thiếu
chính xác. Nếu nút mạng nguồn sử dụng địa chỉ MAC này, không một
nút mạng nào khác ở đường mạng thứ nhất sẽ xử lý gói tin, đơn giản
vì không một nút mạng nào có địa chỉ này.
Nếu chúng ta nhìn vào mô hình 5.19, gói tin nếu muốn đến được
đường mạng thứ nhì, trước hết phải được gửi đến cổng
453
111.111.111.110 của thiết bị định tuyến, đây cũng chính là địa chỉ
default gateway của tất cả các nút mạng trong đường mạng thứ nhất.
Như vậy, địa chỉ MAC đích đúng đắn trong trường hợp này phải là địa
chỉ MAC của cổng 111.111.111.110 trên thiết bị định tuyến, mang giá
trị E6-E9-00-17-BB-4B. Tuy nhiên, làm thế nào để nút mạng nguồn
có thể lấy được địa chỉ MAC này? Dĩ nhiên là sử dụng cơ chế ARP,
với địa chỉ IP đầu vào là địa chỉ IP của default gateway. Khi đã có
được địa chỉ MAC của thiết bị định tuyến, nút mạng nguồn tạo gói tin
có địa chỉ MAC đích là địa chỉ này và gửi vào đường truyền. Thiết bị
định tuyến nhận được gói tin này, có địa chỉ đích đến ở tầng Liên kết
là địa chỉ của nó nên sẽ chuyển gói tin lên tầng Mạng của thiết bị để
xử lý. Tại đây, thiết bị router dựa vào địa chỉ IP đích của gói tin (trong
trường hợp này là 222.222.222.222) để lựa chọn chuyển gói tin sang
cổng thích hợp. Sử dụng bảng định tuyến, bộ định tuyến quyết định sẽ
chuyển gói tin ra khỏi cổng có địa chỉ 222.222.222.220 để đi đến nút
mạng đích. Tầng Mạng tại thiết bị định tuyến sẽ chuyển gói tin đến bộ
giao tiếp mạng đang được gắn vào đường mạng thứ nhì. Lần này, bộ
giao tiếp sẽ sử dụng địa chỉ MAC đích là địa chỉ 49-BD-D2-C7-56-2A
của nút mạng đích, và dĩ nhiên giá trị này cũng thu được nhờ sử dụng
giao thức ARP.
V. Ethernet
Ethernet là loại mạng LAN thông dụng nhất ngày nay. Vào khoảng
những năm 1980-1990, Ethernet gặp sự cạnh tranh gay gắt của nhiều
kỹ thuật mạng LAN khác nhau, bao gồm token-ring, FDDI, ATM.
Tuy nhiên, từ khi ra đời vào khoảng những năm giữa thập niên 1970,
Ethernet đã liên tục phát triển và đã chiếm được ưu thế tuyệt đối ngày
nay.
Có rất nhiều nguyên nhân dẫn đến sự thành công của mạng Ethernet.
Đầu tiên, Ethernet là mạng LAN tốc độ cao đầu tiên được triển khai.
Vì sự phát triển sớm của kỹ thuật này, rất nhiều người quản trị mạng
đã quen thuộc với những đặc tính và ưu điểm của Ethernet và dẫn đến
tâm lý không muốn chuyển sang những kỹ thuật mạng khác. Lý do
thứ nhì là những kỹ thuật khác như token ring, FDDI và ATM quá
phức tạp và đòi hỏi nhiều chi phí hơn Ethernet, điều này càng gia tăng
454
tâm lý không muốn thay đổi của những người quản trị. Lý do quan
trọng để chuyển sang những kỹ thuật mạng LAN khác (ví dụ FDDI và
ATM) là những kỹ thuật này thường cho tốc độ hoạt động cao hơn
Ethernet, tuy nhiên mạng Ethernet không ngừng phát triển và đạt được
tốc độ truyền dữ liệu ngang bằng hoặc thậm chí cao hơn những kỹ
thuật ra đời sau. Mạng Ethernet sử dụng switch ra đời vào đầu những
năm 1990 đã nâng cao đáng kể hiệu năng của mạng Ethernet. Lý do
cuối cùng là nhờ sợ phổ biến của mạng Ethernet, các trang thiết bị
phần cứng phục vụ cho kỹ thuật mạng này được sản xuất hàng loạt và
cho giá thành rất rẻ.
Mạng Ethernet nguyên gốc được phát minh vào giữa những năm 1970
bởi Bob Metcalfe và David Boggs. Nguyên gốc, mạng Ethernet sử
dụng một cáp đồng trục dạng bus để kết nối các nút mạng. Đồ hình
dạng bus được sử dụng suốt những năm 1980 và cho đến giữa những
năm 1990. Đồ hình dạng bus hoạt động theo mô hình mạng LAN
quảng bá, mỗi gói tin đều được chuyển đến tất cả các nút trong mạng.
Đến cuối những năm 1990, hầu hết các tổ chức và trường đại học đã
chuyển sang dùng mạng Ethernet dạng hình sao (star) sử dụng thiết bị
Hub. Hình 5.20 mô tả một mạng Ethernet trong đó tất cả các nút mạng
(máy tính và thiết bị định tuyến) kết nối vào một hub sử dụng cáp
xoắn đôi. Hub là một thiết bị vật lý thao tác trên các bit vật lý thay vì
trên các gói tin. Khi một bit, có thể có giá trị 0 hoặc 1, được truyền
đến một cổng trên hub, thiết bị hub tái tạo lại bit này, khuếch đại tín
hiệu điện và truyền giá trị bit này ra tất cả các cổng còn lại trên hub.
Vì vậy, mô hình mạng Ethernet sử dụng hub thật sự cũng là một mạng
quảng bá, mỗi khi hub nhận được một bit ở một cổng, nó ngay lập tức
nhân bản và gửi bit này ra mọi cổng còn lại. Nếu hub cùng lúc nhận
được tín hiệu ở hai cổng khác nhau, hiện tượng xung đột tín hiệu xảy
ra và các nút mạng bị xung đột phải truyền lại dữ liệu.
455
Nút mạng
Bộ giao tiếp mạng
Hai cặp cáp xoắn

bằng đồng
Ghi chú:
Hub
Hình 5.20: Đồ hình dạng sao cho mạng Ethernet: các nút mạng kết nối
vào một Hub trung tâm
Vào đầu những năm 2000, mạng Ethernet lại có thêm một bước phát
triển mạnh mẽ. Mạng Ethernet tiếp tục sử dụng đồ hình dạng hình sao,
tuy nhiên thiết bị hub bị thay thế bởi thiết bị switch. Chúng ta sẽ cùng
tìm hiểu sâu về thiết bị switch ở phần sau trong chương này. Tuy
nhiên, có thể nói ngắn gọn thiết bị switch không chỉ giúp hỗ trợ loại
bỏ hiện tượng xung đột tín hiệu mà còn giúp hỗ trợ cơ chế lưu và
chuyển tiếp (store-and-forward) trong mạng. Tuy nhiên, khác với thiết
bị định tuyến hoạt động ở tầng 3, thiết bị switch hoạt động ở tầng 2
trong mô hình phân lớp.
V.1 Cấu trúc gói tin Ethernet
Cấu trúc của một gói tin Ethernet được mô tả trong hình 5.21. Để
cùng nghiên cứu về gói tin Ethernet trong một hoàn cảnh thực tế, hãy
thử tưởng tượng một máy tính đang gửi gói tin IP cho một máy khác
và cả hai máy đều trong cùng một đường mạng. Mặc dù trong ví dụ
này, chúng ta minh hoặc gói tin Ethernet chứa một gói tin IP, tuy
456
nhiên gói tin Ethernet có thể mang dữ liệu của các giao thức tầng
Mạng khác. Giả sử nút mạng gửi A có địa chỉ MAC AA-AA-AA-AA-
AA-AA và nút mạng nhận B có địa chỉ MAC BB-BB-BB-BB-BB-
BB. Nút mạng A bọc gói tin IP bởi gói tin Ethernet và gửi gói tin
Ethernet xuống tầng vật lý. Bộ giao tiếp mạng tại nút B nhận gói tin,
rút trích thông tin gói tin IP và chuyển gói tin lên tầng Mạng. Thông
qua ví dụ này, chúng ta xem xét nội dung các trường của gói tin
Ethernet như minh họa ở hình 5.21
Dest. Source
Preamble Data CRC
Address Address
Type
Hình 5.21: Cấu trúc gói tin Ethernet

• Trường Data (từ 46 đến 1500 byte): Trường này chứa nội dung
gói tin IP. Kích thước truyền tải tối đa (MTU – Maximum
transmission unit) của mạng Ethernet là 1500 byte. Nghĩa là nếu
gói tin IP có kích thước vượt quá 1500 byte, gói tin IP sẽ bị chia
thành nhiều gói nhỏ như đã mô tả ở chương 4. Kích thước tối
thiểu của trường data là 46 byte. Nếu gói tin IP có kích thước nhỏ
hơn 46 byte, sẽ có một số dữ liệu được độn thêm vào gói tin IP.
Khi gói tin được chuyển lên tầng Mạng sẽ bao gồm luôn cả các
dữ liệu độn, tầng Mạng sẽ dựa vào kích thước gói tin IP ở phần
header để loại bỏ phần độn.
• Trường địa chỉ đích (6 byte): Trường này chứa địa chỉ MAC của
nút mạng đích, cụ thể ở đây là BB-BB-BB-BB-BB-BB. Khi nút
mạng đích B nhận được gói tin Ethernet, nó sẽ kiểm tra nếu địa
chỉ MAC là địa chỉ của chính nó hoặc địa chỉ quảng bá, nó sẽ
chuyển gói tin lên trên cho tầng Mạng xử lý, ngược lại nút B sẽ
hủy gói tin.
• Trường địa chỉ nguồn (6 byte): Trường này chứa địa chỉ MAC
của nút mạng nguồn, cụ thể ở đây là AA-AA-AA-AA-AA-AA
457
• Trường Type (2 byte): Trường này giúp mạng Ethernet phân biệt
được gói tin của các giao thức tầng Mạng khác nhau. Chúng ta
cần ghi nhớ, máy tính có thể sử dụng các giao thức ở tầng Mạng
khác với giao thức IP. Trong thực tế, một máy tính cùng lúc có
thể sử dụng nhiều giao thức khác nhau ở tầng Mạng cho những
ứng dụng khác nhau. Vì lý do này, khi nút mạng B nhận được gói
tin Ethernet, nút B sẽ dựa vào giá trị của trường này để quyết định
sẽ chuyển gói tin cho giao thức nào ở tầng Mạng xử lý. IP và các
giao thức khác (Novell IPX hoặc AppleTalk) đều sử dụng những
số khác nhau và được qui định trước. Ngay cả giao thức ARP
được trình bày ở phần trước cũng có một con số được qui định
riêng, ví dụ nếu trường Type của gói tin Ethernet chứa giá trị
0806 (hệ thập lục) gói tin sẽ được giao cho mô-đun ARP xử lý.
Việc sử dụng trường Type giúp nhiều giao thức tầng Mạng khác
nhau có thể cùng sử dụng mạng Ethernet để truyền dữ liệu.
• Trường CRC (4 byte): Mục đích trường này để chứa mã kiểm lỗi
CRC nhằm phát hiện các lỗi trong quá trình truyền tin.
• Trường Preamble (8 byte): Gói tin Ethernet bắt đầu bằng 8 byte
gọi là Preamble. Mỗi byte trong số 7 byte đầu tiên đều mang giá
trị 10101010, byte cuối cùng mang giá trị 10101011. Bảy byte
đầu tiên mang ý nghĩa “đánh thức” bộ giao tiếp mạng đích và
đồng bộ hóa đồng hồ của bộ giao tiếp này với bộ giao tiếp nguồn.
Vì sao phải có quá trình đồng bộ đồng hồ? Giả sử một nút mạng
A muốn truyền dữ liệu với tốc độ 10 Mbps, 100 Mbps hoặc 1
Gbps, tùy vào môi trường mạng Ethernet khác nhau. Tuy nhiên,
không điều gì là tuyệt đối hoàn hảo, bộ giao tiếp tại máy A không
thể nào truyền dữ liệu với tốc độ tuyệt đối chính xác như vậy, sẽ
luôn có một sự xê dịch nhỏ trong tốc độ truyền và dĩ nhiên các
nút mạng đích không biết trước được độ xê dịch này. Dựa vào giá
trị đã biết trước trong 7 byte dữ liệu đầu tiên của trường
Premable, nút mạng đích sẽ căn chỉnh đồng hồ để nhận được dữ
liệu chính xác nhất. Giá trị hai bit sau cùng của phần preamble
458
(hai giá trị 1 liên tiếp) báo cho nút mạng đích biết ngay sau đây sẽ
là phần nội dung quan trọng.
Mạng Ethernet dùng phương pháp truyền dữ liệu dạng baseband, bộ

giao tiếp mạng gửi trực tiếp tín hiệu số (digital) vào đường truyền. Bộ
giao tiếp không cần phải chuyển tín hiệu số sang một dạng tín hiệu
khác trước khi truyền, như trong trường hợp ADSL và một số mạng
sử dụng modem cáp. Rất nhiều kỹ thuật Ethernet (ví dụ như 10BASE-
T) sử dụng cơ chế mã hóa Manchester, minh họa trong hình 5.22. Với
kỹ thuật Manchester, mỗi bit đều bao gồm một lần thay đổi tín hiệu:
bit 1 gồm một lần thay tín hiệu từ cao xuống thấp, bit 0 gồm một lần
đổi tín hiệu từ thấp lên cao. Lý do sử dụng kỹ thuật Manchester vì
đồng hồ giữa bên gửi và bên nhận không thật sự được đồng bộ một
cách hoàn hảo. Bằng cách tạo nên một sự thay đổi tại giữa chu kỳ bit,
thiết bị nhận có thể đồng bộ đồng hồ với thiết bị gửi. Khi đồng hộ tại
bên nhận đã được đồng bộ, thiết bị nhận có thể phân tách ra được từng
bit và nhận biết được bit đó là bit 1 hoặc bit 0. Kỹ thuật mã hóa
Manchester được xem như là một kỹ thuật ở tầng vật lý hơn là ở tầng
Liên kết, tuy nhiên ở đây chúng ta đề cập đến vì kỹ thuật này được
dùng rất nhiều trong mạng Ethernet.
Chuỗi bit 1 0 0 0 1 0 0 1 1 1 1
Chuỗi bit
mã hóa
nhị phân
Mã hóa
Manchester
Thời gian
Hình 5.22: Kỹ thuật mã hóa Manchester

Tất cả các kỹ thuật mạng Ethernet đều chỉ cung cấp dịch vụ phi kết
nối (connectionless) cho tầng Mạng bên trên. Khi nút mạng A muốn
gửi dữ liệu cho nút mạng B, nút mạng A chỉ đơn thuần gửi gói tin vào
459
đường truyền Ethernet mà không cần phải thực hiện quá trình khởi tạo
kết nối trước. Mặt khác, mạng Ethernet không cung cấp cơ chế truyền
thông đáng tin cậy cho tầng Mạng bên trên. Khi nút mạng B nhận
được gói tin, nút mạng sẽ thực hiện kiểm tra lỗi sử dụng cơ chế CRC,
tuy nhiên nút mạng này sẽ không gửi hồi đáp cho nút mạng A biết liệu
gói tin có bị lỗi hay không, nếu gói tin bị lỗi nút mạng B chỉ đơn thuần
hủy bỏ gói tin. Nút mạng A dĩ nhiên sẽ không có cách biết được quá
trình gửi gói tin cho nút mạng B có thành công hay không. Việc
không cài đặt dịch vụ truyền tin đáng tin cậy ở tầng Liên kết giúp
mạng Ethernet trở nên đơn giản và có chi phí thấp. Tuy nhiên, điều
này dẫn đến việc luồng dữ liệu gửi lên cho tầng Mạng có thể sẽ có
những khoảng hổng. Việc ứng dụng tại nút mạng B có bị ảnh hưởng
bởi các khoảng hổng này hay không tùy thuộc vào giao thức ở tầng
Liên kết mà ứng dụng sử dụng. Nếu ứng dụng sử dụng giao thức
UDP, dĩ nhiên sẽ bị ảnh hưởng bởi những khoảng hổng này. Ngược
lại, nếu sử dụng TCP, các gói tin bị hủy sẽ được nút mạng A truyền lại
và đến nơi đầy đủ. Trong trường hợp này, có thể nói Ethernet đã thực
sự truyền lại dữ liệu, tuy nhiên chính bản thân giao thức Ethernet sẽ
không ý thức được dữ liệu nó đang truyền thật sự là các dữ liệu mới
hay là các dữ liệu được truyền lại.
V.2 CSMA/CD: Giao thức đa truy của Ethernet
Khi các nút mạng kết nối vào một thiết bị hub, như trong hình 5.20 thì
mạng Ethernet hoạt động như một môi trường quảng bá. Một gói tin
trên mạng sẽ được chuyển đến tất cả các tất cả các bộ giao tiếp mạng
trên môi trường mạng đó. Vì vậy, mạng Ethernet sử dụng cơ chế
CSMA/CD để điều khiển đa truy cập. Như đã trình bày ở mục 5.3, cơ
chế CSMA/CD qui định:
1. Một bộ giao tiếp có thể truyền dữ liệu bất kỳ thời điểm nào,
không tồn tại khái niệm khe thời gian
2. Một bộ giao tiếp sẽ không truyền dữ liệu nếu nhận biết được rằng
có một bộ giao tiếp khác đang truyền tin (cơ chế cảm nhận kênh
truyền)
460
3. Một bộ giao tiếp sẽ ngừng ngay việc truyền dữ liệu nếu nó nhận
biết được một bộ giao tiếp khác cũng đang truyền dữ liệu vào
cùng thời điểm (cơ chế chống xung đột)
4. Trước khi bắt đầu truyền lại dữ liệu, bộ giao tiếp sẽ đợi một
khoảng thời gian ngẫu nhiên, thời gian chờ này thông thường sẽ
nhỏ hơn thời gian cần thiết để truyền một gói tin
Các qui định này giúp CSMA/CD hoạt động hiệu quả hơn nhiều lần
cơ chế slotted ALOHA trong mạng LAN. Trong thực tế, nếu độ trễ
trong việc lan truyền dữ liệu giữa các nút mạng là khá nhỏ, cơ chế
CSMA/CD có thể giúp mạng Ethernet đạt đến hiệu năng gần như
100%. Cần lưu ý rằng qui định thứ hai và thứ ba trong số các qui định
trên đòi hỏi một bộ giao tiếp mạng phải đạt được hai yêu cầu, (1):
nhận biết được các nút mạng khác đang truyền dữ liệu, (2): nhận biết
được khi có hiện tượng xung đột xảy ra. Các bộ giao tiếp mạng
Ethernet thực hiện hai công việc này nhờ đo đạc mức điện thế trước
và trong quá trình truyền.
Mỗi bộ giao tiếp mạng phải có khả năng đảm nhận cơ chế CSMA/CD
mà không cần phối hợp trực tiếp với bất kỳ bộ giao tiếp mạng nào
khác. Tại mỗi bộ giao tiếp mạng, cơ chế CSMA/CD hoạt động cụ thể
như sau:
1. Bộ giao tiếp nhận gói tin từ tầng Mạng, đóng gói vào gói tin
Ethernet và sau đó đưa gói tin này vào bộ nhớ đệm
2. Nếu bộ giao tiếp cảm nhận được kênh truyền đang rỗi (không có
tín hiệu truyền trong một khoảng thời gian tương đương để truyền
96 bit) nó sẽ bắt đầu truyền tín hiệu. Nếu kênh truyền đang bận,
bộ giao tiếp sẽ tiếp tục chờ cho đến khi không còn tín hiệu trên
kênh truyền (và cộng thêm thời gian 96 bit) để bắt đầu truyền dữ
liệu.
3. Khi đang truyền, bộ giao tiếp sẽ lắng nghe tín hiệu truyền từ các
bộ giao tiếp khác. Nếu bộ giao tiếp có thể truyền hoàn tất gói tin
mà không cảm nhận được tín hiệu truyền từ các bộ giao tiếp khác,
bộ giao tiếp xem như hoàn tất quá trình truyền tin.
461
4. Nếu nhận thấy tín hiệu từ các bộ giao tiếp khác khi đang truyền
dữ liệu, bộ giao tiếp sẽ ngừng việc truyền dữ liệu và phát ra xung
tín hiệu jam dài 48 bit để cảnh báo.
5. Sau khi ngừng truyền dữ liệu, bộ giao tiếp sẽ bắt đầu qui trình
exponential backoff. Khi truyền một gói tin, nếu đã bị xung đột
đến lần thứ n với gói tin đó, bộ giao tiếp sẽ chờ một khoảng thời
gian K trong khoảng {0,1,2,…,2m -1} với m = minimum(n,10).
Bộ giao tiếp sẽ chờ một khoảng thời gian (K * 512 khoảng thời
gian truyền một bit) và trở lại bước 2.
Mục đích của việc gửi tín hiệu jam là để báo hiệu cho các bộ giao tiếp
mạng khác về hiện tượng xung đột đang diễn ra trên mạng. Giả sử nút
mạng A bắt đầu truyền tín hiệu, trước khi gói tin đến được nút mạng B
thì nút B cũng bắt đầu truyền. Như vậy, nút B chỉ kịp truyền vài bit dữ
liệu trước khi nó buộc phải ngưng. Những bit này sẽ đến được nút A
nhưng chưa tạo đủ năng lượng để nút A nhận biết được xung đột tín
hiệu. Để bảo đảm nút mạng A sẽ nhận biết được hiện tượng xung đột,
nút mạng B sẽ truyền một chuỗi jam dài 48 bit báo hiệu.
Kế tiếp chúng ta sẽ bàn về thuật toán exponential backoff. Điều lưu ý
đầu tiên là thời gian cần để truyền một bit là rất nhỏ, đối với mạng 10
Mbps thời gian này tương ứng 0.1 micro giây. Giả sử một bộ giao tiếp
mạng đang truyền một gói tin ở lần thứ nhất và khi đang truyền thì
gặp hiện tượng xung đột. Bộ giao tiếp sẽ chọn K = 0 với xác suất 0.5
và K = 1 với xác suất 0.5. Nếu bộ giao tiếp chọn K = 0, bộ giao tiếp sẽ
ngay lập tức quay trở lại bước số 2 sau khi đã phát đi tín hiệu jam.
Nếu bộ giao tiếp chọn K = 1, nó sẽ đợi khoảng 51.2 micro giây trước
khi quay trở về bước số 2. Sau khi bị xung đột lần 2, K có thể được
chọn từ các số {0,1,2,3} các xác suất bằng nhau. Sau lần xung đột thứ
3, K có thể được chọn từ các số {0,1,2,3,4,5,6,7} với xác suất bằng
nhau. Sau 10 lần hoặc nhiều hơn xung đột, K có thể được chọn từ các
số {0,1,2,…,1023} với cùng xác suất. Như vậy, kích thước của tập
hợp số K tăng theo hàm mũ cùng với số lần xung đột (cho đến khi n =
10). Vì lý do này, thuật toán backoff của mạng Ethernet được gọi là
thuật toán backoff theo số mũ (exponential backoff).
462
Mạng Ethernet cũng qui định khoảng cách tối đa giữa 2 nút mạng. Giá
trị tối đa này đảm bảo nếu nút mạng A lựa chọn số K nhỏ hơn tất cả
hơn tất cả các nút mạng tham gia vào hiện tượng xung đột, nút mạng
K sẽ có thể truyền được dữ liệu mà không gặp lại hiện tượng xung
đột.
Tại sao lại sử dụng thuật toán backoff dạng số mũ? Khi một nút mạng
gặp xung đột, nút mạng này sẽ không biết có bao nhiêu nút mạng khác
tham gia tạo nên sự xung đột này. Trong trường hợp có nhiều nút
mạng tạo nên sự xung đột, việc có nhiều giá trị K để lựa chọn sẽ giúp
nút mạng có nhiều cơ hội để truyền được tín hiệu hơn. Việc tăng dần
số giá trị K mỗi khi gặp xung đột nhằm đáp ứng nhu cầu này.
Hiệu năng của mạng Ethernet
Khi chỉ có một nút mạng truyền tin, nút mạng này sẽ có thể đạt được
tốc độ tối đa của mạng Ethernet (ví dụ như 10 Mbps, 100 Mbps, 1
Gbps). Tuy nhiên, nếu có nhiều nút mạng cùng truyền tin, hiệu năng
của mạng Ethernet sẽ giảm xuống rõ rệt. Chúng ta định nghĩa giá trị
hiệu năng của mạng Ethernet (xét trong một khoảng thời gian đủ dài)
là nghịch đảo thời gian truyền một gói tin trên kênh truyền mà không
gặp hiện tượng xung đột khi trên kênh truyền có nhiều nút mạng và
mỗi nút mạng đều có nhiều gói tin để gửi. Để mô hình hóa được đại
lượng này, chúng ta qui định dprop là thời gian tối đa cần thiết để tín
hiệu truyền đi được giữa 2 nút cách xa nhau nhất trong mạng, dtrans là
thời gian để truyền gói tin có kích thước tối đa trong mạng Ethernet
(khoảng 1.2 mili giây đối với mạng 10 Mbps). Việc chứng minh hiệu
năng của mạng Ethernet không nằm trong phạm vi của sách này, ở
đây chúng tôi chỉ đưa ra công thức cụ thể:
Hiệu năng =
Từ công thức này, chúng ta nhận thấy nếu dprop tiến đến 0, hiệu năng
của mạng tiến đến 1. Điều này hoàn toàn hợp lý với nhận định trước
đó, khi thời gian truyền tải giữa hai nút mạng là 0 thì nút mạng gây
xung đột sẽ ngừng truyền tin ngay lập tức, không gây lãng phí kênh
truyền. Tương tự, nếu dtrans rất lớn, hiệu năng mạng sẽ đạt đến 1. Điều
này cũng có thể giải thích được, nếu một gói tin rất lớn sẽ chiếm dụng
463
toàn bộ kênh truyền trong một khoảng thời gian dài, kênh truyền sẽ
luôn hoạt động và đạt hiệu năng cao.
V.3 Công nghệ Ethernet
Ethernet bao gồm nhiều kỹ thuật kết nối mạng LAN với các tên gọi
khác nhau như 10BASE-T, 10BASE-2, 100BASE-T, 1000BASE-LX
và 10GBASE-T… Các kỹ thuật Ethernet này đã được chuẩn hóa và
đặt tên bởi nhóm làm việc IEEE 802.3. Các tên gọi này đều có chung
một qui định, phần đầu tiên cho biết tốc độ của kỹ thuật mạng, ví dụ
như 10, 1000, 1000 hoặc 10G tượng trưng cho mạng 10 Megabit (một
giây), 100 Megabit, Gigabit hoặc 10 Gigabit. Từ khóa “BASE” cho
biết đây là công nghệ baseband, trong đó hạ tầng vật lý chỉ vận
chuyển duy nhất dữ liệu của mạng Ethernet, hầu như tất cả các mạng
Ethernet đều hoạt động theo chuẩn baseband. Phần cuối cùng của tên
gọi cho biết về môi trường vật lý được sử dụng. Ethernet qui định các
giao thức ở cả tầng Liên kết và vật lý, tại tầng vật lý có thể sử dụng
nhiều môi trường cáp khác nhau như cáp đồng trục, cáp xoắn đôi và
cáp quang. Thông thường, chữ cái “T” cho biết kỹ thuật này sử dụng
cáp xoắn đôi.
Ban đầu, mạng Ethernet thường hoạt động dựa trên một nhánh mạng
cáp đồng trục. Các mạng 10BASE-2 và 10BASE-5 là các kỹ thuật
mạng đạt đến tốc độ 10Mbps sử dụng cáp đồng trục và có chiều dài
tối đa lần lượt là 185m và 500m. Để hoạt động được trên các nhánh
mạng dài hơn, thiết bị repeater, là một thiết bị khôi phục và khuếch
đại tín hiệu ở tầng vật lý được sử dụng. Mạng Ethernet cáp đồng trục
là ví dụ minh họa rõ ràng nhất về hình ảnh của môi trường mạng
quảng bá, mỗi một gói tin sẽ được gửi đến tất cả các bộ giao tiếp
mạng trong cùng nhánh mạng.
Mạng Ethernet đã trải qua nhiều thay đổi trong suốt quá trình phát
triển, trong hầu hết các mạng Ethernet ngày nay, các nút mạng sẽ kết
nối trực tiếp vào một thiết bị switch trung tâm sử dụng cáp xoắn đôi
hoặc cáp quang, theo như hình 5.23
Trong những năm giữa thập kỷ 1990, mạng Ethernet đạt được tốc độ
100Mbps, cao gấp 10 lần tốc độ của các mạng Ethernet 10Mbps ban
đầu. Ở các mạng này, giao thức điều khiển truy cập kênh truyền và
464
cấu trúc gói tin được giữ nguyên, tuy nhiên hạ tầng vật lý bên dưới có
sự thay đổi đáng kể, sử dụng cáp xoắn đôi (100BASE-T) hoặc cáp
quang (100BASE-FX, 100BASE-SX, 100BASE-BX). Hình 5.24 minh
họa các kỹ thuật mạng này. Mạng cáp xoắn thường chỉ hỗ trợ khoảng
cách tối đa 100m giữa hai thiết bị, trong khi mạng cáp quang có thể hỗ
trợ khoảng cách tối đa lên đến vài km.
Mạng Gigabit Ethernet là sự mở rộng của mạng 10 Mbps và 100
Mbps. Hỗ trợ tốc độ tối đa lên đến 1000 Mbps, tuy nhiên mạng
Gigabit Ethernet vẫn hoàn toàn tương thích với các thiết bị Ethernet
được sử dụng rộng rãi trước đó. Mạng Gigabit Ethernet được đặt mã
hiệu 802.3z, có các đặc tính sau:
• Sử dụng cấu trúc gói tin như đã qui định ở hình 5.21 và hoàn toàn
tương thích với các chuẩn 10BASE-T VÀ 100BASE-T. Điều này
giúp việc tích hợp mạng Gigabit Ethernet vào các mô hình mạng
sẵn có tương đối dễ dàng.
E
D
F
Switch
A
C
Hình 5.23: Một thiết bị switch kết nối 6 nút mạng
465
• Hỗ trợ các đường kết nối theo kiểu điểm nối điểm lẫn quảng bá.
Kênh truyền kiểu điểm nối điểm là các kênh truyền sử dụng trong
mạng switch, kênh truyền quảng bá là các kênh truyền sử dụng
hub. Trong thuật ngữ của mạng Gigabit Ethernet, thiết bị hub
được gọi là buffered distributor.
• Sử dụng giao thức CSMA/CD trong các kênh truyền quảng bá.
Tuy nhiên, để đạt được hiệu năng chấp nhận được, khoảng cách
tối đa giữa hai nút mạng được qui định rất thấp.
• Cho phép hoạt động theo cơ chế song công (full – duplex) với tốc
độ 1000 Mbps trên các đường truyền điểm nối điểm.
Ứng dụng Giao thức MAC và cấu trúc gói tin

Vận chuyển
Mạng 100BASE-TX 100BASE-T2 100BASE-FX
Liên kết
100BASE-T4 100BASE-SX 100BASE-BX
Vật lý
Hình 5.24: Các chuẩn mạng Ethernet 100 Mpbs: dùng chung giao thức
tầng Liên kết trên các hạ tầng vật lý khác nhau
Ban đầu chỉ hoạt động dựa trên cáp quang, tuy nhiên ngày nay mạng
Gigabit Ethernet đã có thể được triển khai trên các mạng sử dụng cáp
xoắn UTP Cat 5. Mạng 10 Gbps (10GBASE-T) được chuẩn hóa vào
năm 2007 thậm chí đã đẩy tốc độ hoạt động của mạng Ethernet lên
một mức cao hơn.
Nhìn chung, mạng Ethernet đã trải qua nhiều thế hệ khác nhau, tốc độ
thậm chí được nâng cao hàng ngàn lần so với các mạng ban đầu. Khi
sử dụng thiết bị hub, các kênh truyền hoạt động theo cơ chế quảng bá
và cẩn phải có một giao thức thực hiện việc điều khiển truy cập đường
truyền (CSMA/CD). Tuy nhiên, trong mô hình mạng sử dụng Switch,
sử dụng cơ chế store-and-forward, các nút mạng có thể truyền dữ liệu
bất cứ khi nào có nhu cầu mà không gây ảnh hưởng đến thiết bị khác,
trong mạng này cơ chế điều khiển truy cập là không thật sự cần thiết.
466
Tuy nhiên, cần lưu ý có một điều hầu như không thay đổi trong suốt
hơn 30 năm qua ở các mạng Ethernet, đó là cấu trúc của gói tin.
VI. Thiết bị Switch ở tầng Link

Như được minh họa trong hình 5.25, mạng Ethernet ngày nay sử dụng
đồ hình dạng sao, kết nối vào một thiết bị Switch tại vị trí trung tâm.
Ở phần này, chúng ta sẽ cùng tìm hiểu về vai trò và cơ chế hoạt động
của thiết bị switch.
Dĩ nhiên vai trò chính của thiết bị switch là nhận một gói tin tại cổng
đầu vào và chuyển các gói tin đó ra các cổng đầu ra. Thiết bị switch
hoạt động trong suốt đối với các nút mạng, một nút mạng sẽ gửi dữ
liệu trực tiếp đến các nút mạng khác mà không hề biết có sự tồn tại
của thiết bị switch trong mạng. Tại một thời điểm, lưu lượng dữ liệu
được chuyển đến một cổng ra của thiết bị switch có thể vượt quá băng
thông của đường mạng tại cổng, vì vậy tại các cổng ra của switch đều
có bộ nhớ đệm.
Web
server
Ra mạng
Internet
1 Gbps Mail
1 Gbps server
6 5
4 1 Gbps
1
2 3
100 Mbps 100 Mbps 100 Mbps

(quang) (quang) (quang)
Hỗn hợp 10 Mbps,

100 Mbps, 1 Gbps,
Sử dụng cáp Cat 5
... ... ...
Khoa Vật Lý Khoa CNTT Khoa Toán
Hình 5.25: Mạng của một học viện kết nối sử dụng hub, switch và bộ
định tuyến
467
VI.1 Chuyển tiếp và lọc gói tin

Tính năng lọc (filtering) trên switch quyết định sẽ chuyển gói tin ra
một cổng nào đó hoặc hủy gói tin này. Tính năng chuyển tiếp
(forwarding) sẽ xác định cổng ra của một gói tin và làm nhiệm vụ
chuyển gói tin ra khỏi cổng đó. Tính năng lọc và chuyển tiếp hoạt
động dựa trên bảng dữ liệu switch table. Bảng dữ liệu này bao gồm (1)
địa chỉ MAC của các nút mạng, (2) số hiệu cổng trên switch nối với
từng nút mạng và (3) thời điểm mà thông tin về nút mạng được ghi
vào bảng. Một ví dụ về bảng switch table của mô hình mạng 5.25
được mô tả trong hình 5.26. Bảng dữ liệu switch giúp switch chuyển
các gói tin đến đúng đích dựa trên địa chỉ MAC.
Địa chỉ MAC Cổng Thời gian
62-FE-F7-11-89-A3 1 9:32
7C-BA-B2-B4-91-10 3 9:36
…. …. ….
Hình 5.26: Một phần bảng switch table của thiết bị switch ở vị trí cao
nhất trong hình 5.25
Để hiểu rõ hơn cơ chế hoạt động của cơ chế lọc và chuyển tiếp, chúng
ta tưởng tượng một gói tin có địa chỉ đích DD-DD-DD-DD-DD-DD
được truyền đến cổng x trên switch. Thiết bị switch sẽ tra cứu thông
tin trên bảng switch table về địa chỉ MAC này, có ba khả năng có thể
xảy ra:
• Không có thông tin về địa chỉ DD-DD-DD-DD-DD-DD trong
bảng. Trong trường hợp này, switch sẽ chuyển một bản sao của
gói tin ra khỏi mọi cổng của nó, trừ cổng x đã nhận gói tin. Nói
một cách khác, nếu không có thông tin về địa chỉ đích của gói tin,
switch quảng bá gói tin này.
• Đã có thông tin về địa chỉ MAC DD-DD-DD-DD-DD-DD và địa
chỉ này trỏ về đúng cổng x. Trong trường hợp này, tính năng lọc
trên switch quyết định sẽ hủy gói tin vì gói tin này đến từ cùng
468
một nhánh mạng với nút mạng nhận và nút mạng này chắc chắn
đã có cơ hội nhận được gói tin, không cần thiết bị switch phải
chuyển tiếp.
• Đã có thông tin về địa chỉ MAC DD-DD-DD-DD-DD-DD và địa
chỉ này trỏ về đúng cổng y≠x. Trường hợp này, switch sẽ chuyển
gói tin ra khỏi cổng y để đến được nút mạng đích. Switch thực
hiện thao tác chuyển gói tin bằng cách đưa gói tin vào bộ nhớ
đệm của cổng y.
Chúng ta sẽ áp dụng các qui luật này vào mô hình mạng ở hình 5.25
và bảng dữ liệu switch tại hình 5.26. Giả sử một gói tin được có địa
chỉ đích 62-FE-F7-11-89-A3 được truyền đến switch tại cổng số 1.
Switch sẽ tra cứu thông tin và phát hiện địa chỉ đích này được gắn với
cổng số 1, do đó switch quyết định sẽ hủy gói tin và không chuyến
tiếp gói tin này. Giả sử cũng chính gói tin này, nhưng được truyền đến
switch từ cổng số 2. Lúc này, switch sẽ đặt gói tin vào bộ nhớ đệm
của cổng số 1 để chuyển đi. Điều này cho thấy khi switch có đầy đủ
thông tin về nút mạng đích, dữ liệu sẽ được chuyển đi đến đúng nhánh
mạng đó và không được quảng bá trên toàn kênh truyền.
Câu hỏi đặt ra ở đây là làm cách nào switch có thể tự xây dựng được
bảng switch table để hoạt động?
VI.2 Tự học
Thiết bị switch có khả năng tự xây dựng nên bảng dữ liệu switch table
mà không cần sự can thiệp của người quản trị hay một giao thức được
thiết kế riêng. Tính năng này được gọi là khả năng tự học của thiết bị
switch. Tính năng này hoạt động như sau:
• Ban đầu, thiết bị switch được khởi động và bảng switch table còn
trống.
• Với mỗi gói tin nhận được tại một cổng, thiết bị switch lưu vào
bảng (1) giá trị MAC nguồn của gói tin, (2) cổng mà theo đó gói
tin được truyền đến switch, (3) thời gian hiện tại. Bằng cách này,
thiết bị switch lưu trữ lại được nút mạng cụ thể được nối với cổng
469
cụ thể nào trên switch. Nếu tất cả các nút mạng lần lượt gửi dữ
liệu, switch sẽ biết được vị trí của tất cả các nút mạng này.
• Nếu sau một khoảng thời gian định trước (aging time), switch
không nhận được dữ liệu từ một nút mạng cụ thể, switch sẽ xóa
thông tin về nút mạng ra khỏi bảng. Bằng cách này, nếu một máy
tính bị thay thế bởi một máy tính khác, địa chỉ MAC của máy tính
mới sẽ thay thế cho địa chỉ của máy tính cũ.
Xem xét các luật này ứng với mô hình mạng ở hình 5.25 và bảng
switch table tại hình 5.26. Giả sử tại thời điểm 9:39 một gói tin có địa
chỉ nguồn 01-12-23-34-45-56 được truyền đến cổng 2 trên switch và
địa chỉ nguồn này chưa tồn tại trong bảng. Ngay lập tức, địa chỉ này
được thêm vào bảng theo như hình 5.27
Địa chỉ MAC Cổng Thời gian
01-12-23-34-45-56 2 9:39
62-FE-F7-11-89-A3 1 9:32
7C-BA-B2-B4-91-10 3 9:36
…. …. ….
Hình 5.27: Switch học được vị trí của nút mạng 01-12-23-43-45-56
Tiếp tục với ví dụ trên, giả sử thời gian aging trong bảng switch là 60
phút và không có gói tin nào từ nút mạng 62-FE-F7-11-89-A3 gửi đến
switch trong khoảng thời gian 9:32 đến 10:32. Tại thời điểm 10:32,
switch sẽ gỡ bỏ địa chỉ này ra khỏi bảng.
Switch được xem như một thiết bị plug-and-play bởi vì có thể hoạt
động mà không cần có bất kỳ sự can thiệp nào từ người quản trị mạng.
Người quản trị đơn thuần chỉ cần kết nối các thiết bị với switch thông
qua cáp kết nối mà không cần phải cấu hình hay thiết lập bảng switch
table trên thiết bị switch. Switch hoạt động ở cơ chế song công, nghĩa
là các nút mạng và bản thân thiết bị switch có thể gửi dữ liệu cùng lúc
mà không gây xung đột.
470
VI.3 Các đặc tính của Link-layer switching

Ở phần này chúng ta xem xét và tổng hợp lại các đặc tính chính của
thiết bị switch. Sử dụng mô hình mạng LAN như trong hình 5.24,
chúng ta xác định các ưu điểm khi dùng mạng switch thay cho sử
dụng đồ hình dạng bus hoặc sử dụng thiết bị hub:
• Loại trừ xung đột: Trong mạng sử dụng switch (và không sử dụng
hub) sẽ không còn có các băng thông hao phí do hiện tượng xung
đột.Thiết bị switch sẽ lưu gói tin ở bộ đệm và không bao giờ
chuyển nhiều hơn một gói tin và một nhánh mạng tại một thời
điểm. Tương tự như bộ định tuyến, băng thông của một thiết bị
switch là tổng băng thông của tất cả các cổng trên switch. Switch
hoạt động hiệu quả hơn rất nhiều lần so với mô hình mạng quảng
bá.
• Các đường kết nối không đồng nhất: thiết bị switch “cô lập” các
đường liên kết với nhau, do đó các đường liên kết có thể hoạt
động với các tốc độ khác nhau và sử dụng các môi trường khác
nhau. Ví dụ như trong hình 5.23, nút mạng A có thể kết nối vào
mạng 10BASE-T sử dụng cáp đồng, mặt khác nút mạng B có thể
kết nối vào mạng 100BASE-TX sử dụng cáp quang, nút mạng C
có thể kết nối vào mạng 1 Gbps 1000BASE-T dùng cáp đồng.
Thiết bị switch là một thiết bị lý tưởng để thiết lập các mạng mới
tích hợp với các môi trường mạng sẵn có.
Dễ quản lý: Bên cạnh việc tăng cường an ninh mạng (vì gói tin chỉ
chuyển đến đúng nhánh mạng cần thiết, khó khăn trong việc “nghe
trộm” trên mạng), switch còn giúp cho việc quản lý mạng trở nên dễ
dàng hơn. Giả sử một bộ giao tiếp mạng bị hỏng và liên tục gửi gói tin
ra môi trường, switch có thể nhận biết được hiện tượng này và ngắt
nút mạng ra khỏi mạng chung. Với tính năng này, người quản trị
mạng không cần thiết phải thức dậy lúc nửa đêm, quay trở lại văn
phòng để giải quyết sự cố. Tương tự, việc một cáp mạng bị đứt chỉ
gây gián đoạn đến chính nút mạng kết nối đến switch sử dụng đoạn
cáp mạng đó, không gây ảnh hưởng đến các nút mạng khác. Với đồ
471
hình mạng hình bus sử dụng cáp đồng trục, rất nhiều quản trị mạng
phải bỏ nhiều giờ chỉ để xác định vị trí đứt của cáp bởi chỉ một điểm
bị đứt sẽ ảnh hưởng đến toàn hệ thống.
VI.4 So sánh switch và router
Như đã đề cập ở chương 4, bộ định là một thiết bị đóng vai trò lưu trữ
và chuyển tiếp (store-and-forward) các gói tin dựa trên địa chỉ ở tầng
Mạng. Thiết bị switch cũng đóng vai trò lưu trữ và chuyển tiếp, tuy
nhiên hoạt động dựa trên địa chỉ MAC ở tầng Liên kết. Do đó, chúng
ta có thể nói thiết bị định tuyến hoạt động ở tầng 3, còn thiết bị switch
hoạt động ở tầng 2.
Mặc dù thiết bị switch và định tuyến hoàn toàn khác nhau, khi thiết kế
một hệ thống mạng các nhà quản trị luôn luôn phải có sự cân nhắc lựa
chọn giữa hai thiết bị này để làm thiết bị tập trung kết nối. Ví dụ như
ở mô hình ở hình 5.25, người quản trị hoàn toàn có thể sử dụng một
thiết bị định tuyến thay thế cho thiết bị switch để nối các nhánh mạng
phòng ban với các máy phục vụ và thiết bị gateway. Bộ định tuyến
hoàn toàn có thể đóng vai trò kết nối các nhánh mạng và loại trừ hiện
tượng xung đột trên mạng. Như vậy, đâu là ưu và khuyết điểm khi lựa
chọn thiết bị switch hay bộ định tuyến đảm nhận vai trò kết nối các
thiết bị khác?
Switch Bộ định tuyến
Tầng ứng dụng Tầng ứng dụng
Tầng vận chuyển Tầng vận chuyển
Tầng mạng Tầng mạng Tầng mạng
Tầng liên kết Tầng liên kết Tầng liên kết Tầng liên kết
Tầng vật lý Tầng vật lý Tầng vật lý Tầng vật lý
472
Hình 5.28: Cơ chế xử lý gói tin tại máy tính, switch và bộ định tuyến
Trước hết, hãy cùng xem xét ưu và khuyết điểm của thiết bị switch.
Trước hết, switch là một thiết bị có thể làm việc hoàn toàn tự động,
không cần có sự can thiệp của người quản trị mạng. Thiết bị switch có
tốc độ làm việc nhanh hơn bộ định tuyến, như hình 5.28 minh họa
chúng ta thấy switch chỉ xử lý gói tin ở tầng 2 trong khi đó bộ định
tuyến phải chuyển gói tin lên tầng 3 để xử lý. Mô hình mạng sử dụng
switch sẽ không tận dụng được các đường kết nối dự phòng giữa các
switch với nhau, mặc định các kết nối dư thừa sẽ bị ngắt theo qui định
của giao thức spanning-tree. Tuy nhiên, trong một môi trường gồm
nhiều nút mạng gắn vào switch, các nút sẽ phải duy trì một bảng ARP
có kích thước rất lớn và các gói tin quảng bá sẽ xuất hiện với tần suất
lớn và gây chậm hoạt động của hệ thống mạng. Bản thân thiết bị
switch cũng không ngăn chặn được hiện tượng “bão” gói tin quảng bá
(broadcast storm), nếu một nút mạng bị lỗi và liên tục phát sinh các
gói tin quảng bá sẽ gây giảm hiệu năng của hệ thống mạng một cách
nghiêm trọng.
Kế tiếp chúng ta sẽ xem xét các ưu và nhược điểm của bộ định tuyến.
Bởi vì địa chỉ ở tầng Mạng có cấu trúc phân lớp (không phải cấu trúc
phẳng như địa chỉ MAC), các gói tin thường sẽ không di chuyển liên
tục qua lại giữa các bộ định tuyến, dù có nhiều đường kết nối dự
phòng giữa các bộ định tuyến này. Các gói tin sẽ luôn luôn được vận
chuyển trên các đường đi tối ưu, nhờ cơ chế hoạt động dựa trên các
bảng định tuyến. Các bộ định tuyến không bị hạn chế trong phạm vi
một spanning-tree và việc sử dụng bộ định tuyến cho phép xây dựng
các hệ thống mạng Internet có nhiều dạng đồ hình mạng khác nhau, ví
dụ như có nhiều đường kết nối dự phòng giữa châu Âu và châu Á. Các
bộ định tuyến mặc định có chức năng hạn chế hiện tượng “bão” gói tin
quảng bá, các gói tin quảng bá từ nhánh mạng này của bộ định tuyến
không thể lan truyền sang nhánh mạng khác. Tuy nhiên, có thể xem
nhược điểm lớn nhất của bộ định tuyến là chúng không phải là thiết bị
dạng plug-and-play. Các bộ định tuyến cần phải được đặt địa chỉ IP
cho các cổng trước khi có thể hoạt động được, ngoài ra các giao thức
định tuyến cũng cần phải được người quản trị cấu hình trên thiết bị.
Ngoài ra, thời gian xử lý mỗi gói tin của bộ định tuyến nhìn chung cao
473
hơn rất nhiều so với switch vì các gói tin cần phải được chuyển lên
tầng 3 để xử lý.
Hub Bộ định tuyến Switch
Cô lập dữ liệu Không Có Có
Plug and play Có Không Có
Tìm đường đi ngắn Không Có Không
nhất
Bảng 5.1: So sánh tính năng cơ bản giữa các thiết bị
Cả thiết bị switch và các bộ định tuyến đều có những ưu và nhược
điểm nhất định (như tóm tắt trong bảng 5.1), như vậy khi nào chúng ta
nên sử dụng switch, khi nào nên sử dụng bộ định tuyến? Thông
thường, chúng ta xem các hệ thống mạng nhỏ là các hệ thống chỉ gồm
vài nhánh mạng và vài trăm nút mạng. Sử dụng switch hoàn toàn có
thể đáp ứng đầy đủ nhu cầu của các mạng này, vì switch vừa có khả
năng phân vùng dữ liệu và cung cấp băng thông kết nối cao giữa các
thiết bị mà không đòi hỏi bất kỳ thao tác cấu hình địa chỉ IP nào cả.
Trong các mạng gồm hàng ngàn thiết bị kết nối với nhau cần sử dụng
các bộ định tuyến, vì bộ định tuyến cho phép phân vùng dữ liệu tốt
hơn, ngăn chặn các gói tin quảng bá giữa các vùng để đảm bảo hiệu
năng của hệ thống.
VI.5 VLAN
Các mạng nội bộ ngày nay (như được thể hiện trong hình 5.25)
thường được thiết kế theo phân lớp, mỗi một phòng ban đều có một
mạng con kết nối với nhau sử dụng switch. Các switch này sẽ kết nối
đến các switch của phòng ban khác để hình thành nên một mạng LAN
lớn và có cấu trúc. Thiết kế này thoạt nhìn có vẻ khá hoàn hảo, tuy
nhiên trong thực tế sẽ gặp các vấn đề sau:
Thiếu cơ chế “cô lập” dữ liệu: Mặc dù đã có thiết kế phân lớp để cô
lập các dữ liệu nội bộ vào chung một thiết bị switch, các gói tin quảng
bá (ví dụ như ARP, DHCP hoặc các gói tin có địa chỉ đích chưa được
học bởi switch) sẽ lan truyền đi khắp hệ thống mạng. Việc hạn chế
474
phạm vi của các gói tin quảng bá sẽ giúp nâng cao rõ rệt hiệu năng của
hệ thống mạng. Ngoài ra, việc hạn chế phạm vi của các gói tin quảng
bá cũng sẽ góp phần nâng cao hơn tính bảo mật và riêng tư của mạng.
Giả sử một nhánh mạng bao gồm các cán bộ điều hành, quản lý và
một nhánh mạng gồm các nhân viên làm thời vụ đang chạy các
chương trình bắt gói tin trên mạng (ví dụ như Wireshark), người quản
trị sẽ không bao giờ muốn gói tin từ nhánh mạng của nhân viên quản
lý được chuyển đến nhánh mạng của các nhân viên làm thời vụ này.
Việc cô lập dữ liệu này có thể thực hiện được nếu sử dụng một bộ
định tuyến thay cho thiết bị switch ở hình 5.25. Tuy nhiên, chúng ta sẽ
được biết việc cô lập này hoàn toàn có thể thực hiện được bằng cách
sử dụng các thiết bị switch ở tầng 2.
1 9 15
2 4 8 10 16
Sinh viên Giáo viên

(VLAN cổng 2-8) (VLAN cổng 9-15)
Hình 5.29: Một thiết bị switch hỗ trợ hai VLAN

Sử dụng các switch không hiệu quả: Nếu thay vì chỉ có 3 phòng ban,
công ty có 10 phòng ban, như vậy cần phải sử dụng 10 thiết bị switch
để nối các phòng ban. Nếu mỗi phòng ban có qui mô nhỏ, giả sử như
10 người, một thiết bị switch có 96 cổng có thể đủ để dùng, tuy nhiên
475
việc sử dụng duy nhất một thiết bị switch sẽ không đảm bảo được cơ
chế cô lập dữ liệu.
Quản lý người dùng: Nếu một nhân viên thay đổi phòng ban, cáp vật
lý phải được thay đổi để nối nhân viên này vào đúng thiết bị switch
mới như trong hình 5.25. Việc một nhân viên thuộc cùng lúc nhiều
phòng ban khiến việc quản lý càng trở nên khó khăn.
Tuy nhiên, tất cả các vấn đề nêu ra ở đây đều có thể giải quyết được
bởi một thiết bị switch có hỗ trợ công nghệ mạng LAN ảo (VLAN -
Virtual Local Area Network)
Công nghệ VLAN trên switch cho phép thiết lập nhiều mạng LAN ảo
trên cùng một hạ tầng vật lý của một mạng LAN thông thường. Các
máy tính trong cùng một VLAN có thể trao đổi được với nhau như thể
chúng cùng nối với nhau vào thiết bị switch. Với kỹ thuật phân chia
VLAN theo cổng, các cổng trên một switch có thể được gom thành
nhiều nhóm khác nhau bởi người quản trị mạng. Mỗi một nhóm sẽ
hình thành nên một mạng LAN ảo và một broadcast domain (miền
quảng bá) khác nhau. Nghĩa là gói tin quảng bá từ một cổng chỉ có thể
đến được các cổng khác trong cùng một VLAN, không đến được các
cổng thuộc VLAN khác (cho dù có ở trên cùng một switch).
Hình 5.29 minh họa một switch gồm 16 cổng. Cổng 2 – 8 thuộc cùng
VLAN SV, cổng 9 – 15 thuộc về VLAN GV (cổng 1 và 16 không
được gán vào VLAN). Mô hình VLAN này giải quyết được tất cả các
khó khăn đã nêu ở phần trên – gói tin của VLAN GV và SV được cô
lập và không liên hệ với nhau, hai thiết bị switch trong hình 5.25 có
thể gom lại thành duy nhất một thiết bị switch, nếu người dùng tại
cổng số 8 chuyển từ vai trò SV sang GV, người quản trị có thể cấu
hình lại để cổng này gia nhập VLAN GV. Chúng ta đều có thể thấy sự
dễ dàng trong việc quản lý nhờ sử dụng kỹ thuật VLAN: bằng cách sử
dụng các công cụ quản lý switch người quản trị sẽ chỉ định một cổng
cụ thể tham gia vào VLAN nào đó (các cổng không được chỉ định sẽ
thuộc về VLAN mặc định), một bảng ánh xạ giữa cổng – VLAN sẽ
được switch tạo lập và quản lý, phần cứng trên thiết bị switch sẽ chỉ
chuyển gói tin giữa các cổng thuộc cùng một VLAN.
476
Tuy nhiên, bằng cách đưa vào khái niệm cô lập dữ liệu giữa các
VLAN, chúng ta lại gặp phải một khó khăn mới. Nếu có nhu cầu trao
đổi thông tin giữa nhóm người dùng GV và SV thì phải làm thế nào?
Một phương án giải quyết là kết nối switch này vào một cổng của bộ
định tuyến, sau đó khai báo cổng này trên switch thuộc về cả hai
VLAN GV và SV (ví dụ như sử dụng cổng 1 trong hình 5.29). Trong
trường hợp này, mặc dù cả VLAN GV và SV đều sử dụng chung một
switch vật lý, theo mô hình logic chúng ta có thể xem mỗi VLAN có
một thiết bị switch riêng kết nối vào bộ định tuyến. Nếu một gói tin
muốn chuyển từ VLAN GV sang SV, trước hết gói tin sẽ từ VLAN
GV chuyển đến bộ định tuyến, sau đó bộ định tuyến sẽ chuyển ngược
gói tin vào VLAN SV để đến được máy đích. Rất nhiều hãng sản xuất
đã xây dựng các sản phẩm switch hỗ trợ VLAN và đảm nhận luôn vai
trò của một bộ định tuyến, do đó sử dụng một bộ định tuyến riêng đôi
khi không cần thiết.
Quay trở lại mô hình 5.25, giả sử chúng ta có thêm một tòa nhà mới.
Tòa nhà này cũng sẽ có các giáo viên (GV) và sinh viên (SV) cùng
làm việc. Mỗi người dùng đều có nhu cầu kết nối Internet và phải
được đặt vào đúng VLAN của mình. Hình 5.30 minh họa thêm một
thiết bị switch có 8 cổng, mỗi cổng tùy theo nhu cầu sẽ được đặt vào
VLAN GV hoặc SV. Tuy nhiên, làm thế nào để kết nối hai thiết bị
switch này với nhau? Giải pháp đơn giản nhất là khai báo trên mỗi
switch một cổng thuộc về VLAN GV và kết nối hai cổng này với nhau
(tương tự cho VLAN SV), như minh họa trong hình 5.30 (a). Tuy
nhiên, giải pháp này khó triển khai khi có nhiều VLAN được khai báo
trên các switch vì với N VLAN đòi hỏi phải có N kết nối giữa hai
switch.
Một giải pháp có khả năng mở rộng hơn là sử dụng một cổng đặc biệt,
gọi là cổng VLAN trunking. Như minh họa trong hình 5.30(b), trên
mỗi switch ta có thể định nghĩa các cổng đặc biệt (ví dụ như cổng 1 và
cổng 16 chưa sử dụng) trở thành cổng trunk để kết nối hai switch.
Cồng trunk là cổng tham gia vào tất cả các VLAN, do đó các gói tin
dù gửi đến bất kỳ VLAN nào cũng sẽ được nhân bản và chuyển đến
cổng trunk và chuyển đến switch bên cạnh. Tuy nhiên, làm thế nào để
thiết bị switch nhận biết được một gói tin đang được chuyển trên port
trunk là gói tin thuộc về VLAN nào? Tổ chức IEEE định nghĩa thêm
477
một cấu trúc gói tin Ethernet đặc biệt, gọi là 802.1Q, để dùng cho các
gói tin chuyển trên cổng trunk. Như minh họa trong hình 5.31, gói tin
802.1Q là một gói tin Ethernet thông thường, tuy nhiên có thêm
trường VLAN tag dài 4 byte được thêm vào phần header của gói tin
để cho biết VLAN mà gói tin này thuộc về. Trường VLAN tag này sẽ
được thêm gán thêm bởi thiết bị switch gửi dữ liệu vào đường trunk,
được đọc và gỡ ra khỏi gói tin bởi switch nhận dữ liệu trên đường
trunk. Trường VLAN tag gồm phần Tag Protocol Identifier (TPID)
dài 2 byte (có giá trị cố định là 0x81-00) và trường Tag Control
Information dài 2 byte, trường này bao gồm trường VLAN idendifier
dài 12 bit cho biết mã hiệu VLAN mà gói tin thuộc về, trường priority
dài 3 bit có chức năng tương tự trường TOS trong gói tin IP.
1 1
16 8
a.
Liên kết
1 9 15 trunk 1 3 5 7
2 4 8 10 16 2 4 6 8
Sinh viên Giáo viên

Sinh viên Giáo viên (VLAN cổng 2,3,6) (VLAN cổng 4,5,7)
b. (VLAN cổng 2-8) (VLAN cổng 9-15)
Hình 5.30: Kết nối hai thiết bị switch được cấu hình với hai VLAN
(a): Sử dụng 2 sợi cáp (b): sử dụng một cáp dạng trunk
Type
Dest. Source
Preamble Data CRC
address address
Type
Dest. Source
Preamble Data CRC
address address
Recomputed
Tag Control Information CRT
Tag Protocol Identifier
478
Hình 5.31: Cấu trúc gói tin Ethernet có bổ sung thêm thông tin VLAN
theo chuẩn 802.1q
Trong suốt phần này chúng ta chỉ mô tả khá khái quát về kỹ thuật
VLAN cấu hình dựa vào các cổng. Còn có khá nhiều phương pháp để
định nghĩa VLAN như dựa vào địa chỉ MAC, khi một thiết bị gắn vào
switch, tùy thuộc vào địa chỉ MAC của thiết bị mà cổng trên switch sẽ
được gắn vào VLAN tương ứng. VLAN còn có thể định nghĩa tùy
thuộc vào giao thức mà máy tính sử dụng (IPv4, IPv6, hoặc
AppleTalk). Tuy nhiên, các phương pháp này không được đề cập
trong giáo trình.
VII. PPP: giao thức điểm -điểm

Hầu hết các lý thuyết chúng ta nghiên cứu cho đến thời điểm này là
giao thức cho các kênh truyền quảng bá. Trong phần này chúng ta sẽ
bàn đến một giao thức tầng Liên kết phục cho các kênh truyền điểm
nối điểm, đó là giao thức PPP. PPP thường được sử dụng trên các
đường mạng quay số (dial-up) kết nối giữa khách hàng và nhà cung
cấp, do đó ngày nay đây cũng là giao thức được sử dụng rộng rãi nhất
tại tầng Liên kết. Một giao thức điểm nối điểm khác ở tầng Liên kết
cũng được sử dụng phổ biến là giao thức HDLC (high-level data link
control), tuy nhiên chúng ta không đề cập đến HDLC trong sách này.
Giao thức PPP có cơ chế làm việc đơn giản hơn, và thông qua giao
thức này chúng ta sẽ đề cập đến các thuộc tính quan trọng của các
giao thức điểm nối điểm tại tầng Liên kết.
Giao thức PPP hoạt động trên đường liên kết dạng điểm nối điểm, là
dạng kênh truyền kết nối trực tiếp hai nút mạng ở hai đầu với nhau.
PPP có thể hoạt động trên các đường dây dạng quay số (như đường
56K sử dụng modem), đường SONET/SDH, các kết nối X.25 và các
kết nối ISDN. Như đã đề cập ở trên, PPP thường được lựa chọn cho
các đường quay số kết nối giữa khách hàng và các nhà cung cấp dịch
vụ.
Trước khi đi sâu chi tiết vào giao thức PPP, chúng ta tìm hiểu các yêu
cầu của tổ chức IETF đề ra khi thiết kế giao thức này:
479
• Cấu trúc gói tin: Giao thức PPP phải có khả năng nhận một gói
tin ở tầng Mạng và đóng gói vào bên trong một gói tin PPP ở tầng
Liên kết. Phải bảo đảm nút mạng nhận có khả năng nhận diện
được điểm bắt đầu và kết thúc của gói tin PPP cũng như gói tin ở
tầng Mạng được gói bên trong.
• Độ trong suốt: Giao thức PPP không được phép đặt ra bất kỳ ràng
buộc nào với dữ liệu bên trong gói tin ở tầng Mạng (kể cả phần
dữ liệu và header). Nghĩa là, giao thức PPP không được phép
ngăn cấm việc sử dụng một mô hình chuỗi bit cụ thể nào đó ở
tầng Mạng. Chúng ta sẽ trao đổi kỹ hơn nội dung này ở phần byte
stuffing
• Đa giao thức ở tầng Mạng: Giao thức PPP phải hỗ trợ được cùng
lúc nhiều loại giao thức khác nhau ở tầng Mạng (ví dụ như IP,
DECnet …) trên cùng một kết nối vật lý ở cùng một thời điểm.
Điều này tương tự như giao thức IP phải hỗ trợ nhiều giao thức ở
tầng Vận chuyển (ví dụ như TCP, UDP) trên cùng một kết nối
giữa hai nút mạng. Điều này yêu cầu giao thức PPP phải có
trường Type trong cấu trúc gói tin hoặc một cơ chế tương tự để có
thể phân biệt được các giao thức khác nhau ở tầng Mạng.
• Nhiều dạng đường liên kết: Giao thức PPP phải có khả năng hoạt
động trên nhiều dạng đường liên kết khác nhau, bao gồm đường
serial (truyền từng bit dữ liệu trên một hướng), đường parallel
(truyền nhiều bit cùng lúc), đường đồng bộ (truyền dữ liệu xung
đồng hồ kèm theo với dữ liệu thật sự), đường bất đồng bộ, các
đường tốc độ thấp hoặc cao, đường tín hiệu điện hoặc cáp quang
…
• Phát hiện lỗi: Thiết bị nhận gói tin PPP phải phát hiện được các
lỗi truyền dữ liệu trong gói tin.
• Duy trì kết nối (connection liveness): Giao thức PPP phải có khả
năng phát hiện các lỗi tại tầng Liên kết (ví dụ như lỗi không thể
480
truyền được dữ liệu từ nút mạng nguồn đến nút mạng đích trên
kênh truyền) và thông báo các lỗi này lên tầng Mạng.
• Thương thuyết về địa chỉ tầng Mạng: PPP phải cung cấp cơ chế
cho phép tầng Mạng (ví dụ như giao thức IP) nhận biết được hoặc
cấu hình được địa chỉ của thiết bị ở hai đầu kênh truyền.
• Đơn giản: PPP còn phải đáp ứng được rất nhiều các yêu cầu khác
không đề cập ở đây. Trong số các yêu cầu đó, yêu cầu quan trọng
nhất là sự đơn giản. Tuy nhiên, đây là một yêu cầu rất khó khăn
đối với một giao thức phải đảm trách nhiều yêu cầu như PPP.
Tuy nhiên, sau đây là các yêu cầu không được đề ra khi thiết kế giao
thức PPP:
• Sửa lỗi: PPP chỉ được thiết kế để phát hiện lỗi sai mà không cần
phải có khả năng sửa các lỗi này
• Điều khiển luồng: Thiết bị nhận PPP được yêu cầu sẽ nhận dữ
liệu với tốc độ mà kênh truyền vật lý cho phép. Nếu các tầng
Mạng bên trên không có khả năng nhận dữ liệu ở tốc độ này, các
tầng này phải tự đảm trách chức năng hủy gói tin và thông báo để
bên gửi giảm tốc độ mà không cần đến sự can thiệp của PPP.
• Đánh số thứ tự: PPP không được yêu cầu phải chuyển dữ liệu
đến nơi nhận theo đúng thứ tự đã gửi đi. Đặc điểm này tương đối
tương thích với giao thức IP (cũng không đòi hỏi yêu cầu dữ liệu
phải được chuyển đến nơi đúng thức tự), tuy nhiên sẽ có nhiều
giao thức khác hoạt động bên trên PPP đòi hỏi việc truyền thông
đúng thứ tự.
• Kênh truyền đa điểm (multipoint): PPP được thiết kế chỉ để làm
việc trên các kênh truyền chỉ gồm một nút gửi và một nút nhận.
Một số giao thức liên kết khác (ví dụ như HDLC), có thể hoạt
động trên cả những kênh truyền có nhiều thiết bị nhận (gần giống
mô hình mạng Ethernet).
Cấu trúc gói tin PPP
481
Chiều dài
1 1 1 1 or 2 thay đổi 2 or 4 1
01111110 11111111 00000011 Protocol Info Check 01111110
Flag Address Control Flag
Hình 5.32: Cấu trúc gói tin PPP

Hình 5.32 minh họa cấu trúc một gói tin PPP (dựa trên cấu trúc gói tin
của giao thức HDLC ra đời trước). Cấu trúc này bao gồm các phần:
• Cờ hiệu (Flag): Mỗi gói tin PPP sẽ bắt đầu và kết thúc bởi một
byte cờ hiệu có giá trị 01111110.
• Address: Giá trị của trường này luôn luôn là 11111111
• Control: Giá trị của trường này luôn là 00000011. Bởi vì trường
địa chỉ và điều khiển luôn luôn có giá trị cố định, chúng ta có thể
đặt câu hỏi tại sao cần có các trường này. Trong thiết kế giao thức
PPP, các trường này có thể mang các giá trị khác và được dùng
cho các mục đích tương lai (tại thời điểm thiết kế). Tuy nhiên,
đến này các trường này vẫn chưa được sử dụng cho các mục đích
khác. Mặt khác, vì các trường này đều mang giá trị cố định, giao
thức PPP cho phép nút mạng gửi không gửi kèm các trường này
trong gói tin, tiết kiệm được 2 byte khi truyền tin.
• Protocol: Trường này cho biết phần dữ liệu bên trong của PPP là
gói tin của giao thức mạng nào. Khi nhận được gói tin, nút mạng
đích dựa vào giá trị này để chuyển gói tin lên đúng giao thức tầng
Mạng để xử lý. Trường này được định nghĩa có chiều dài 16 bit,
với số hiệu cho giao thức IP là 0x21, AppleTalk là 0x29, DECnet
là 0x27.
• Information: Đây là nội dung của gói tin ở tầng Mạng được bọc
bên trong gói tin PPP. Giá trị tối đa mặc định của phần này là
1500 byte, tuy nhiên giá trị này có thể được thương thuyết và thay
đổi trong quá trình cấu hình kênh truyền PPP lần đầu tiên.
482
• Checksum: Trường này dùng để phát hiện lỗi gói tin trong quá
trình truyền. Trường này sử dụng mã CRC dài 2 hoặc 4 byte, theo
qui định của chuẩn HDLC.
Byte Stuffing
Để kết thúc phần trình bày về cấu trúc gói tin PPP, chúng ta sẽ bàn về
vấn đề phát sinh khi một giao thức ở tầng Mạng gửi một byte dữ liệu
trùng với giá trị byte cờ hiệu được PPP định sẵn nhằm đánh dấu phần
bắt đầu và kết thúc của một gói tin. Ví dụ, byte cờ hiệu có giá trị
01111110 và nếu chúng ta cần truyền chính giá trị này trong phần dữ
liệu thì phải làm thế nào? Liệu nút mạng nhận gói tin PPP có nhầm lẫn
byte dữ liệu này là byte đánh dấu phần kết thúc của một gói tin hay
không?
Một hướng giải quyết đơn giản là cấm các giao thức bên trên gửi các
byte dữ liệu trùng với byte cờ hiệu dùng để đánh dấu. Tuy nhiên, như
đã nói ở trên giao thức PPP phải đảm bảo tính trong suốt với các giao
thức tầng trên, do đó yêu cầu này là không khả thi. Một kỹ thuật để
giải quyết vấn đề này mà PPP cũng như nhiều giao thức khác sử dụng
là kỹ thuật độn byte (byte stuffing)
PPP định nghĩa một byte mang ý nghĩa đặc biệt, gọi là byte escape, có
giá trị 01111101. Nếu chuỗi bit có giá trị trùng với byte cờ hiệu
01111110 xuất hiện tại bất kỳ nơi nào trong gói tin (trừ tại chính vị trí
cờ hiệu), PPP sẽ chèn byte escape này vào trước đoạn giá trị đó. Nghĩa
là PPP đã chèn thêm một byte escape vào kênh truyền, ngay trước giá
trị byte 01111110 để báo hiệu đoạn dữ liệu 01111110 theo sau không
mang ý nghĩa cờ hiệu mà chỉ là dữ liệu đơn thuần. Khi nút mạng đích
nhận được giá trị byte độn 01111101 ở phía trước byte 01111110, nút
mạng này dĩ nhiên sẽ loại bỏ phần byte độn và khôi phục dữ liệu gốc.
Ngoài ra, nếu giá trị của byte escape xuất hiện trong phần dữ liệu của
gói tin, byte này cũng phải được độn trước bởi chính một byte escape
khác. Khi nút mạng đích nhận được chỉ một byte có giá trị trùng với
byte escape, nút mạng đích biết rằng đây chỉ là một byte đã được chèn
thêm bởi bên gửi. Nếu hai byte escape đi liền nhau, nghĩa là tại điểm
này trong dữ liệu gốc sẽ có một byte có giá trị trùng với byte escape.
Hình 5.33 minh họa phương pháp chèn byte được sử dụng bởi PPP
483
(Thực sự, ngoài việc chèn thêm byte escape vào trước phần dữ liệu
trùng với giá trị cờ hiệu hoặc byte escape, phần dữ liệu này sẽ được
PPP thực hiện phép toán XOR với giá trị 0x20 trước khi gửi vào
đường truyền. Tuy nhiên phần này chúng tôi không đề cập đến để đơn
giản hơn cho người đọc.)
b5 b1
b4 b2
01111110 01111110
b2 b4
b1 b5
PPP PPP
b5 b4 01111110 01111101 b2 b1
Hình 5.33: Byte stuffing

Ngoài ra, trong PPP còn có giao thức điều khiển đường liên kết (LCP
– link control protocol) đảm nhận vai trò khởi tạo, duy trì, và ngắt các
đường kết nối PPP. Tuy nhiên, LCP không được đề cập chi tiết trong
phần này của giáo trình.
VIII. Ảo hóa tầng Link: Mạng xem như tầng Link

Trước khi kết thúc chương, chúng ta sẽ cùng xem lại khái niệm
“đường liên kết” được đề cập đến xuyên suốt trong chương này. Ở
phần đầu chương, chúng ta xem xét đường liên kết là một đường dây
vật lý kết nối giữa hai nút mạng, như được minh họa trong hình 5.2.
Khi nghiên cứu về các giao thức điều khiển đa truy cập (hình 5.9),
chúng ta nhận thấy môi trường truyền dẫn lúc này không chỉ bó hẹp
trong các đường dây hữu tuyến mà còn mở rộng sang sóng radio và
một số môi trường vô tuyến khác. Khái niệm “đường liên kết” lúc này
có thể hiểu rộng là kênh truyền, không đơn thuần là các đường dây vật
lý. Ở phần tìm hiểu về mạng Ethernet, chúng ta đã nhận thấy môi
trường kết nối giữa các nút mạng lúc này là các hạ tầng phức tạp sử
dụng thiết bị switch. Mặc dù môi trường truyền dẫn có thay đổi, một
484
máy tính có thể duy trì quan niệm môi trường kết nối đơn giản chỉ là
một kênh truyền nối giữa hai hoặc nhiều máy tính với nhau. Ví dụ như
trong môi trường Ethernet, một máy tính không thật sự biết rằng nó
được kết nối trực tiếp với một máy tính khác, hay thông qua một thiết
bị switch, hoặc sử dụng VLAN.
Trong phần 5.7, chúng ta được biết giao thức PPP thường dduojc dùng
trong các đường quay số để kết nối trực tiếp hai nút mạng. Trong
trường hợp này, đường kết nối giữa hai máy tính thực chất là mạng
điện thoại quay số, bản thân mạng này sẽ có các giao thức được qui
định riêng, sử dụng các thiết bị switch, các thiết bị kết nối, các kiểu tín
hiệu dành riêng cho mạng viễn thông. Tuy nhiên, đứng trên góc nhìn ở
tầng Liên kết trong mạng Internet, kết nối thông qua mạng quay số
này có thể xem như một “đường dây” đơn giản. Trong trường hợp
này, mạng Internet đã phần nào “ảo hóa” mạng điện thoại quay số,
xem mạng này đơn thuần như một công nghệ ở tầng Liên kết để kết
nối hai máy tính trên môi trường Internet.
Trong phần nội dung này, chúng ta sẽ nghiên cứu về các mạng MPLS
(Multiprotocol Label Switching). Không giống như các mạng chuyển
mạch mạch dùng trong mạng điện thoại, MPLS là một mạng dựa trên
kỹ thuật chuyển mạch gói và dựa trên khái niệm mạch ảo (virtual –
circuit). Mạng MPLS định nghĩa các cấu trúc gói tin và phương pháp
chuyển tin riêng biệt. Đứng trên góc nhìn của mạng Internet, có thể
xem MPLS tương tự như khái niệm mạng điện thoại hoặc mạng
Ethernet sử dụng switch, đều là các kỹ thuật nhằm kết nối các thiết bị
có địa chỉ IP. Do đó, trong phần tìm hiểu này chúng ta sẽ xem MPLS
như một giao thức ở tầng Liên kết. Frame-relay và ATM cũng là các
kỹ thuật hỗ trợ kết nối các thiết bị IP, tuy nhiên đây là các kỹ thuật đã
ra đời từ khá lâu và không được tập trung đề cập trong giáo trình này.
Multiprotocol Lable Switching (MPLS)
MPLS được phát triển dựa trên nhiều kỹ thuật khác nhau nhằm tăng
tốc độ chuyển tiếp gói tin của các bộ định tuyến, bằng cách áp dụng
kỹ thuật chuyển tiếp sử dụng các nhãn có kích thước cố định, đây là
kỹ thuật thường được dùng trong các mạng chuyển mạch ảo.
485
Mục đích chính không phải nhằm loại bỏ kỹ thuật chuyển tiếp gói tin
dựa trên địa chỉ IP đích sẵn có trong các gói tin, mà chỉ nhằm cung
cấp thêm cho các bộ định tuyến khả năng chuyển tiếp gói tin dựa trên
một nhãn có kích thước cố định (thay thế cho địa chỉ IP đích) trong
những hoàn cảnh khả thi. Ngoài ra, kỹ thuật này hoạt động kết hợp với
giao thức IP, sử dụng lại địa chỉ IP và các giao thức định tuyến sẵn có.
Trước hết, chúng ta cùng tìm hiểu về cấu trúc gói tin của giao thức
MPLS. Hình 5.34 mô tả một gói tin được chuyển qua một kết nối PPP
hoặc Ethernet đã được chèn thêm một header của giao thức MPLS ở
giữa phần header ở tầng 2 (giao thức PPP hoặc Ethernet) và header ở
tầng 3 (giao thức IP). Tài liệu RFC 3032 định nghĩa cấu trúc header
MPLS áp dụng cho các đường kết nối PPP và Ethernet, cấu trúc
header MPLS áp dụng cho mạng ATM hoặc mạng Frame-relay được
định nghĩa trong một số tài liệu RFC có liên quan khác. Trong số các
trường của header MPLS, chúng ta có thể thấy các nhãn (labels) được
định nghĩa. Các nhãn này đóng vai trò định danh cho các mạch ảo,
như đã đề cập ở phần 4.2.1. Ngoài ra trong header còn có phần 3 bit
dành riêng, chưa sử dụng, một bit S nhằm để đánh dấu nhãn cuối cùng
trong danh sách chồng các nhãn sử dụng trong MPLS và một trường
time-to-live.
PPP or Ethernet
MPLS header IP header Remainder of link-layer frame
header
Label Exp S TTL
Hình 5.34: Header MPLS chen giữa phần header của tầng 2 và tầng 3
Một điều dĩ nhiên là các gói tin MPLS chỉ có thể được trao đổi bởi các
bộ định tuyến có hỗ trợ tính năng MPLS, các bộ định tuyến thông
thường sẽ không xử lý được gói tin này vì phần MPLS header đã chen
và thay thế vị trí của IP header thông thường. Các bộ định tuyến hỗ trợ
tính năng MPLS được gọi là các lable-switched router, các bộ định
tuyến này chuyển tiếp gói tin MPLS bằng các tra cứu các mã dựa vào
bảng chuyển tiếp (forwarding table) và xuất gói tin ra cổng được qui
định trong bảng. Như vậy, các bộ định tuyến hỗ trợ MPLS sẽ không
486
cần phải bóc tách gói tin IP để tra cứu trong bảng định tuyến (theo luật
so khớp dài nhất). Tuy nhiên, làm thế nào để một bộ định tuyến biết
được các bộ định tuyến láng giềng cũng hỗ trợ MPLS, và làm thế nào
xác định được nhãn MPLS liên kết với một đường mạng IP cụ thể? Để
giải quyết được các vấn đề này, các bộ định tuyến hỗ trợ MPLS cần
phải liên lạc và trao đổi thông tin với nhau.
Trong ví dụ ở hình 5.35, các bộ định tuyến từ R1 đến R4 đều hỗ trợ
MPLS. R5 và R6 là các bộ định tuyến thông thường. R1 sẽ thông báo
cho R2 và R3 rằng R1 có thông tin để đi đến thiết bị A, và nếu nhận
được gói tin có nhãn là 6 R1 sẽ chuyển gói tin này đến đích A. R3 sẽ
báo cho R4 biết R3 có thể chuyển gói tin đến đích A và D, và các gói
tin MPLS nếu có nhãn là 10 và 12 sẽ được chuyển đến đích A và D
tương ứng. R2 sẽ thông báo cho R4 biết R2 có khả năng chuyển gói
tin đến đích A, nếu nhận được gói tin MPLS với nhãn là 8 thì R2 sẽ
chuyển gói tin đến đích này. Lúc này R4 sẽ có hai con đường khác
nhau để đi đến đích A: thông qua cổng 0 và sử dụng nhãn MPLS 10
để gửi đi, thông qua cổng 1 và sử dụng nhãn MPLS 8 để gửi đi. Xét
trên một bức tranh rộng, các thiết bị hỗ trợ IP R5, R6, A và D kết nối
với nhau thông qua một mạng MPLS (tạo bởi các thiết bị từ R1 đến
R4) tương tự như việc một mạng thiết bị switch hoặc một mạng ATM
có thể được sử dụng để kết nối các thiết bị IP. Cũng tương tự như
mạng cục bộ hoặc mạng ATM, các thiết bị R1, R2, R3, R4 chuyển
tiếp gói tin mà không cần sử dụng đến thông tin IP header của gói tin.
Ở phần trình bày trên, chúng ta không đề cập đến giao thức mà các bộ
định tuyến hỗ trợ MPLS sử dụng để trao đổi với nhau, nội dung này
không nằm trong phạm vi trình bày của giáo trình. Độc giả quan tâm
có thể tìm hiểu tài liệu RFC 3209.
Nội dung được nhấn mạnh ở đây là các bộ định tuyến hỗ trợ MPLS
chuyển tiếp các gói tin dựa trên nhãn mà không cần phải dựa vào địa
chỉ IP đích. Tuy nhiên, thế mạnh của giao thức MPLS không hẳn chỉ
là khả năng tăng tốc độ chuyển tiếp gói tin mà là các khả năng mới do
MPLS cung cấp trong việc quản lý luồng dữ liệu. Trong ví dụ trên,
chúng ta thấy R4 có hai đường khác nhau để đi đến đích A. Nếu việc
chuyển tiếp dữ liệu dựa hoàn toàn vào địa chỉ IP đích của gói tin, các
giao thức định tuyến được trình bày ở chương 4 sẽ chỉ lựa chọn sử
487
dụng một đường duy nhất có chi phí thấp hơn hơn. MPLS sẽ cho phép
sử dụng đường truyền còn lại, bên cạnh đường truyền có chi phí thấp
nhất – thông qua việc sử dụng các nhãn MPLS khác nhau cho các gói
tin. Kỹ thuật này được gọi là Traffic Engineering (TE) sử dụng MPLS.
Kỹ thuật này cho phép các người quản trị sử dụng thêm các đường
truyền không được các giao thức định tuyến lựa chọn, cho phép một
số luồng dữ liệu đi theo một hướng và một số luồng dữ liệu đi theo
một hướng khác (vì nhiều lý do như các chính sách tự qui định, nâng
cao hiệu năng, …)
Nhãn Nhãn Nhãn Nhãn
Đích Cổng ra Đích Cổng ra
đầu vào đầu ra đầu vào đầu ra
10 A 0 10 6 A 1
12 D 0 12 9 D 0
8 A 1
R6
0 0
D
1 1
R4 R3
0 0
R5 A
R2 R1
Nhãn Nhãn
Đích Cổng ra Nhãn Nhãn Đích Cổng ra
đầu vào đầu ra
đầu vào đầu ra
8 6 A 0 6 _ A 0
Hình 5.35: Cơ chế chuyển gói tin của MPLS

Ngoài ra, MPLS còn có thể được sử dụng vào nhiều mục đích khác.
MPLS cho phép chuyển nhanh một luồng dữ liệu sang một con đường
khác đã được qui định trước ngay khi con đường chính bị lỗi. Ngoài
ra, MPLS còn được áp dụng trong kỹ thuật thiết lập các đường mạng
riêng ảo (VPN), cho phép dữ liệu riêng của người dùng từ nhiều
đường mạng cục bộ khác nhau vận chuyển chung trên môi trường
mạng Internet, trong đó các nhãn MPLS sẽ được dùng để đánh dấu và
phân biệt các luồng dữ liệu từ các mạng cục bộ khác nhau của người
dùng nhằm giải quyết hiện tượng trùng lặp tài nguyên và địa chỉ của
các mạng này.
488
Phần trình bày về MPLS của chúng tôi khá ngắn gọn, tuy nhiên chúng
tôi khuyến khích độc giả nên đọc thêm các tài liệu về MPLS đã được
giới thiệu ở phần trên. MPLS nhanh chóng trở thành một công cụ cực
kỳ hữu ích trên môi trường mạng Internet ngày nay.
IX. Phối hợp các giao thức trong 1 kịch bản truy cập Web
Chúng ta đã tìm hiểu về tầng Liên kết ở chương này và tầng Mạng,
tầng Vận chuyển ở các chương trước đó. Đến đây, có thể xem hành
trình tìm hiểu các tầng của bộ giao thức đã hoàn tất. Ở phần này,
chúng ta sẽ cùng tổng kết lại vai trò và nguyên lý hoạt động của các
giao thức đã tìm hiểu thông qua một ví dụ thực tế trong cuộc sống
hàng ngày – duyệt một trang web.
DNS server của
abc.net
68.87.71.226
Mạng trường
68.80.2.0/24
00:16:D3:23:68:8A
68.85.2.101
14-17
18-24
1-7
8-13
Mạng tổ chức abc.net

68.80.0.0/13
00:22:6B:45:1F:1B
68.85.2.1
Mạng của Google

64.233.160.0/19
Web server của

Google
64.233.169.105
Hình 5.36
Hình 5.36 mô tả lại mô hình chúng ta cùng nghiên cứu: sinh viên An,
kết nối máy tính xách tay vào mạng Ethernet ở trường và truy cập
489
trang web (giả sử như www.google.com). Như chúng ta đã biết, có rất

nhiều công việc diễn ra âm thầm bên dưới tác vụ duyệt web này.
Bước khởi đầu: DHCP, UDP, IP và Ethernet
Giả sử sinh viên An kết nối máy tính vào thiết bị Ethernet switch, thiết
bị switch này sau đó lại kết nối vào bộ định tuyến như trong hình 5.36.
Bộ định tuyến tại trường sẽ kết nối đến nhà cung cấp dịch vụ (ISP),
giả sử là abc.net. Trong ví dụ này, abc.net sẽ cung cấp dịch vụ DNS
cho trường học, do đó máy phục vụ DNS sẽ nằm tại nhà cung cấp dịch
vụ mà không đặt tại trường. Chúng ta giả định dịch vụ DHCP được
cài đặt trên bộ định tuyến tại trường.
Khi An cắm máy tính của anh ta vào mạng, anh ta sẽ không thể làm
được gì khi chưa có địa chỉ IP. Do đó, tác vụ đầu tiên sẽ là giao tác xin
địa chỉ IP thông qua giao thức DHCP:
1. Hệ điều hành trên máy của An phát sinh gói tin DHCP request và
gửi gói tin này thông qua giao thức UDP từ port 68 trên máy
khách đến port 67 trên máy phục vụ DHCP. Gói tin UDP này sẽ
được bọc bên trong một gói tin IP, với địa chỉ IP đích là địa chỉ
quảng bá (255.255.255.255) và địa chỉ IP nguồn là 0.0.0.0, bởi vì
máy của An vẫn chưa có địa chỉ.
2. Gói tin IP chứa thông điệp DHCP request sẽ được bọc bên trong
một gói tin Ethernet (mục 5.5.1). Gói tin Ethernet này sẽ có địa
chỉ MAC đích FF:FF:FF:FF:FF:FF và sẽ được gửi đến mọi thiết
bị kết nối với switch (bao gồm cả máy phục vụ DHCP), địa chỉ
MAC nguồn của gói tin sẽ là địa chỉ MAC của bộ giao tiếp mạng
trên máy của An 00:16:D3:23:68:8A.
3. Gói tin Ethernet chứa thông điệp DHCP request sẽ được gửi đến
switch, switch sẽ nhân bản và gửi gói tin đến mọi cổng còn lại,
bao gồm cả cổng nối đến bộ định tuyến.
4. Bộ định tuyến nhận được gói tin Ethernet chứa gói tin DHCP
request tại cổng có địa chỉ MAC 00:22:6B:45:1F:1B. Gói tin IP
sẽ được rút trích ra từ gói tin Ethernet. Vì địa chỉ đích của gói tin
IP là địa chỉ dạng quảng bá, nội dung gói tin IP (chính là gói tin
490
UDP bên trong) sẽ được chuyển cho giao thức UDP tại tầng Vận
chuyển xử lý. Tại tầng Vận chuyển, gói tin DHCP request sẽ
được tách ra và gửi cho dịch vụ DHCP tại tầng Ứng dụng.
5. Gỉa sử dịch vụ DHCP trên bộ định tuyến có khả năng cung cấp
địa chỉ trong khối 68.85.2.0/24. Trong ví dụ trên, tất cả các địa
chỉ IP sử dụng trong trường đều nằm trong khối địa chỉ của công
ty abc.net quản lý. Giả sử máy phục vụ DHCP cung cấp địa chỉ
68.85.2.101 cho máy của An. Máy phục vụ DHCP tạo thông điệp
DHCP ACK chứa địa chỉ IP, địa chỉ IP của máy phục vụ DNS
(68.87.71.226), địa chỉ IP của thiết bị default gateway (68.85.2.1)
và subnet mask (/24). Gói tin DHCP sẽ được bọc bên trong một
gói tin UDP, và lại được bọc bên trong gói tin IP. Cuối cùng gói
tin IP sẽ được bọc bên trong gói tin Ethernet. Gói tin Ethernet sẽ
có địa chỉ MAC nguồn là địa chỉ của cổng trên bộ định tuyến
hướng vào mạng cục bộ (00:22:6B:45:1F:1B) và địa chỉ MAC
đích là địa chỉ máy của An (00:16:D3:23:68:8A).
6. Gói tin Ethernet chứa thông điệp DHCP ACK sẽ được gửi dưới
dạng unicast từ bộ định tuyến về switch. Switch có tính năng tự
học (mục 5.6.2) và trước đó đã nhận được gói tin DHCP request
từ máy của An, do đó switch sẽ chuyển gói tin ACK này về đúng
cổng kết nối với máy tính của An.
7. Máy tính của An nhận được gói tin Ethernet chứa thông điệp
DHCP ACK, tách nội dung gói tin IP ra khỏi gói tin Ethernet,
tách nội dung gói UDP ra khỏi gói IP và cuối cùng tách nội dung
thông điệp DHCP ACK ra khỏi gói tin UDP. Ứng dụng DHCP
trên máy An sẽ ghi nhận địa chỉ IP và địa chỉ IP của máy phục vụ
DNS. Máy tính của An cũng sẽ ghi nhận địa chỉ default gateway
vào bảng IP forwarding (mục 4.1), mọi trao đổi ra khỏi mạng nội
bộ 68.85.2.0/24 sẽ được gửi đến thiết bị default gateway này. Tại
thời điểm này, máy tính của An đã có đủ thông tin và sẵn sàng
liên lạc để lấy nội dung trang web. (Ở đây cần trình bày rõ hơn:
491
thật sự chỉ có 2 bước cuối cùng trong các bước về dịch vụ DHCP
trình bày ở chương 4 là thật sự cần thiết).
Dịch vụ DNS và ARP

Khi An gõ vào địa chỉ trang web www.google.com vào trình duyệt,
hàng loạt các sự kiện sẽ diễn ra trước khi máy của An có thể liên lạc
đến máy phục vụ chứa trang web này. Trình duyệt web trên máy của
An trước tiên sẽ tạo một TCP socket (mục 2.7) và dùng socket này để
gửi đi thông điệp HTTP request (mục 2.2) đến máy phục vụ
www.google.com. Tuy nhiên, để tạo được socket kết nối, máy của An
cần phải biết địa chỉ IP của máy phục vụ này. Như đã trình bày ở mục
2.5, giao thức DNS sẽ được sử dụng để phân giải địa chỉ tên miền
thành địa chỉ IP.
8. Hệ điều hành trên máy của An sẽ gửi thông điệp truy vấn DNS
(DNS query - mục 2.5.3), đưa chuỗi “www.google.com” vào
phần nội dung câu hỏi của thông điệp. Thông điệp DNS này sẽ
được đặt vào một gói tin UDP, port đích là 53 (của dịch vụ DNS).
Gói tin UDP này sẽ được đặt vào trong gói tin IP có địa chỉ đích
68.87.71.226 (địa chỉ của DNS server cung cấp qua gói tin DHCP
ACK), và địa chỉ nguồn 68.85.2.201.
9. Máy tính của An sẽ đặt gói tin chứa thông điệp DNS vào một gói
tin Ethernet. Gói tin này sẽ có địa chỉ MAC đích là địa chỉ MAC
của thiết bị default gateway (vì gửi ra mạng ngoài). Tuy nhiên,
máy tính của An chỉ biết được địa chỉ IP của default gateway
(68.85.2.1) thông qua DHCP mà chưa biết được địa chỉ MAC. Để
lấy được địa chỉ MAC cần thiết, máy tính phải sử dụng giao thức
ARP.
10. Máy tính của An sẽ tạo gói tin truy vấn ARP có địa chỉ IP đích là
68.85.2.1 (của default gateway), đặt gói tin ARP này vào mạng
Ethernet với địa chỉ MAC đích dạng quảng bá (FF: FF: FF: FF:
FF: FF) và gửi đến switch, switch sẽ gửi gói tin đến mọi cổng,
bao gồm cổng nối với bộ định tuyến.
492
11. Thiết bị gateway nhận được gói tin chứa thông điệp truy vấn ARP
từ cổng nối với mạng nội bộ của trường, kiểm tra thấy địa chỉ IP
đích của gói tin trùng với địa chỉ của một cổng của thiết bị. Do
đó, thiết bị gateway sẽ phát sinh gói tin hồi đáp ARP (ARP reply),
báo hiệu địa chỉ MAC của nó là 00:22:6B:45:1F:1B tương ứng
với địa chỉ IP 68.85.2.1. Gói tin ARP reply được bọc trong gói tin
Ethernet có địa chỉ MAC đích là 00:16:D3:23:68:8A (máy tính
của An) và gửi về switch, switch sẽ chuyển gói tin đến máy của
An.
12. Máy tính của An nhận được gói tin chứa thông điệp ARP reply và
sẽ lấy được địa chỉ MAC của thiết bị gateway.
13. Máy tính của An lúc này đã có thể điền địa chỉ MAC đích vào gói
tin truy vấn DNS và gửi đến thiết bị gateway. Lưu ý rằng, địa chỉ
IP đích của gói tin này sẽ là 68.87.71.126 (của máy phục vụ
DNS), trong khi địa chỉ MAC đích sẽ là 00:22:6B:45:1F:1B – địa
chỉ của thiết bị gateway. Gói tin đến switch và sẽ được chuyển
đến thiết bị gateway.
Quá trình định tuyến đề đến máy phục vụ DNS

14. Bộ định tuyến nhận được gói tin và sẽ rút trích gói tin IP chứa
thông điệp truy vấn DNS. Bộ định tuyến xem xét địa chỉ IP đích
của gói tin (68.87.71.226), dựa vào bảng định tuyến sẽ quyết định
chuyển gói tin đến bộ định tuyến ngoài cùng bên trái do tổ chức
abc.net quản lý (hình 5.36). Gói tin IP sẽ được gói bên trong một
gói tin ở tầng Liên kết có cấu trúc phù hợp với đường liên kết nối
giữa hai bộ định tuyến và chuyển đi.
15. Bộ định tuyến ngoài cùng bên trái của tổ chức abc.net nhận được
gói tin, tách nội dung gói tin IP, kiểm tra địa chỉ IP đích
(68.87.71.226) và lựa chọn cổng ra cho gói tin dựa vào bảng định
tuyến (được xây dựng bởi các giao thức RIP, OSPF, IS-IS, BGP
trình bày ở mục 4.6) để chuyển được đến máy phục vụ DNS.
493
16. Gói tin chứa thông điệp truy vấn DNS sẽ đến được máy phục vụ
DNS. Máy phục vụ phân tích thông điệp, tìm thông tin về máy
phục vụ www.google.com trong cơ sở dữ liệu (mục 2.5) và tìm
thấy mẫu tin chứa địa chỉ IP 64.233.169.105 ứng với máy
www.google.com này (thực chất dữ liệu thật sự được cung cấp
bởi máy phục vụ DNS quản lý miền google.com, và được máy
phục vụ DNS tại abc.net lưu trữ lại). Máy phục vụ DNS sẽ tạo
thông điệp DNS reply, bọc bên trong gói tin UDP để phản hồi.
Gói tin phàn hồi này lại được bọc trong gói tin IP có địa chỉ đích
là máy của An (68.85.2.101). Gói tin này sẽ được các bộ định
tuyến trả về mạng LAN của trường và được thiết bị switch gửi về
cho máy của An.
17. Máy của An đọc thông điệp và sẽ lấy được địa chỉ IP của máy
phục vụ web www.google.com
Liên lạc giữa trình duyệt và máy phục vụ Web thông qua TCP và
HTTP
18. Sau khi đã có địa chỉ của máy phục vụ web, máy của An sẽ tạo
một TCP socket (mục 2.7) và gửi thông điệp HTTP GET (mục
2.2.3) đến máy phục vụ web này. Khi tạo TCP socket, trước hết
giao thức TCP trên máy của An phải thực hiện quá trình bắt tay
ba bước (mục 3.5.6) để khởi tạo kết nối với máy phục vụ
www.google.com. Máy của An trước hết khởi tạo gói tin TCP
SYN đến port 80 (dịch vụ HTTP), đặt gói tin TCP này bên trong
một gói tin IP có địa chỉ đích 64.233.169.105 (www.google.com),
đặt gói tin IP bên trong một gói tin có địa chỉ MAC
00:22:6B:45:1F:1B (thiết bị gateway) và gửi đến switch.
19. Các bộ định tuyến của trường, của abc.net và tổ chức Google sẽ
phối hợp với nhau và gửi gói tin TCP SYN này đến được máy
phục vụ www.google.com như ở các bước 14-16.
20. Khi gói tin TCP SYN đến được máy www.google.com, gói tin
TCP được tách ra và gửi đến dịch vụ HTTP tại port 80. Một
494
socket sẽ được tạo trên máy phục vụ web để kết nối với máy của
An, một gói tin TCP SYNACK (mục 3.5.6) sẽ được phát sinh,
bọc bên trong gói tin IP, gói tin tầng Liên kết và gửi về thiết bị
gateway nối với máy phục vụ web để chuyển đến máy của An.
21. Gói tin TCP SYNACK sẽ theo các bộ định tuyến của Google,
abc.net, của trường và về đến máy của An. Gói tin này sẽ được
chuyển đến socket tạo ra ở bước 18, socket này sẽ được đưa vào
trạng thái “đã kết nối”.
22. Socket trên máy của An đã sẵn sàng để gửi dữ liệu đến máy
www.google.com. Trình duyệt trên máy của An sẽ phát sinh
thông điệp HTTP GET (mục 2.2.3) chứa địa chỉ URL của trang
web. Thông điệp HTTP GET sẽ được ghi vào socket, gói tin GET
sẽ trở thành dữ liệu của giao thức TCP. Gói tin TCP được bọc vào
các gói tin IP, Ethernet và chuyển đến máy phục vụ
www.google.com như trình bày ở các bước 18-20
23. Dịch vụ HTTP trên máy phục vụ www.google.com sẽ đọc thông
điệp HTTP GET từ socket TCP, tạo thông điệp HTTP response
(mục 2.2), đưa nội dung trang web vào phần body của gói tin
HTTP response và ghi dữ liệu này xuống socket.
24. Gói tin chứa thông điệp HTTP response sẽ được chuyển qua các
bộ định tuyến của Google, abc.net, của nhà trường và về đến máy
của An. Trình duyệt sẽ đọc nội dung trang web từ gói tin thông
qua socket TCP, lấy nội dung html và thể hiện trang web lên màn
hình.
Ví dụ này bao gồm hoạt động của rất nhiều giao thức mạng khác
nhau, trải đều qua các tầng của hệ thống mạng. Tuy nhiên, để đơn giản
chúng tôi đã không đề cập đến các vấn đề như NAT, mạng không dây
trong nhà trường, các giao thức bảo mật và mã hóa.
495
X. Tóm lược
Trong chương này chúng ta đã cùng tìm hiểu về tầng Liên kết và các
tính năng, dịch vụ và giao thức của tầng này.
Dịch vụ cơ bản của tầng Liên kết là vận chuyển gói tin của tầng Mạng
từ một nút mạng (máy tính hoặc bộ định tuyến) đến một nút mạng liền
kề. Tầng Liên kết đóng gói một gói tin của tầng Mạng (packet) vào
một gói tin của tầng Liên kết (frame) trước khi chuyển lên kênh
truyền. Các giao thức khác nhau tại tầng Liên kết sẽ cung cấp các dịch
vụ truyền dữ liệu rất khác nhau như truyền dữ liệu đáng tin cậy, phát
hiện và sửa lỗi, điều khiển luồng, song công – bán song công. Lý do
của sự khác biệt này là do tầng Liên kết phải hoạt động trên rất nhiều
môi trường truyền dẫn khác nhau: cáp quang, cáp đồng, sóng radio, vệ
tinh …
Trong số những dịch vụ và giao thức tại tầng Liên kết, chúng ta đã tìm
hiểu về các kỹ thuật phát hiện và sửa lỗi, các phương pháp điều khiển
đa truy cập, địa chỉ tại tầng Liên kết, VLAN, nguyên tắc hoạt động
của thiết bị Hub và Switch. Về nguyên tắc phát hiện và sửa lỗi, chúng
ta đã tìm hiểu làm thế nào bằng cách them vào một số thông tin bổ
sung có thể giúp phát hiện hoặc đôi khi sửa được các bit bị truyền lỗi
trên kênh truyền. Chúng ta đã tìm hiểu phương pháp kiểm lỗi sử dụng
parity, checksum và mã CRC. Về các phương pháp điều khiển đa truy
cập, chúng ta đã tìm hiểu FDM, TDM, cơ chế ALOHA, CSMA/CD và
phương pháp chuyển thẻ bài. Chúng ta cũng đã tìm hiểu cơ chế địa chỉ
sử dụng tại tầng Liên kết, được sử dụng trong trường hợp có nhiều
thiết bị cùng liên kết trên một kênh truyền quảng bá. Cơ chế ARP
phục vụ cho việc phân giải địa chỉ cũng đã được trình bày trong
chương này.
Chúng ta cũng đã tìm hiểu chi tiết về hai giao thức được sử dụng rộng
rãi tại tầng Liên kết là Ethernet và PPP. Ngoài ra, chương này đã trình
bày giao thức MPLS và cách thức các thiết bị sử dụng MPLS liên kết
với các bộ định tuyến sử dụng IP.
Phần cuối cùng có thể xem như tổng kết kiến thức của cả các chương
trước đó, chúng ta xem xét việc kết hợp các giao thức khác nhau vào
496
quá trình trao đổi dữ liệu của máy tính khi truy cập một trang web: xin
địa chỉ, phân giải địa chỉ tên miền, kết nối HTTP.
Phần nghiên cứu về các tầng trong hệ thống mạng máy tính có thể
xem như đã tương đối đầy đủ. Dĩ nhiên, bên dưới tầng Liên kết còn có
tầng vật lý. Tuy nhiên các kiến thức của tầng này thường được trình
bày ở các môn học khác (như môn Truyền Thông Kỹ Thuật Số chẳng
hạn) thay vì được trình bày chi tiết trong môn Mạng Máy Tính.
497
Nuts and Bolts: Chi tiết cơ bản

Network Edge: Các thành phần ở biên của mạng/biên mạng
Network Core: Các thành phần ở phần lõi của mạng/mạng lõi
Delay: Độ trễ
Throughtput: Thông lượng
Packet-switched Networks: Mạng chuyển mạch gói
Circuit-switched Networks: Mạng chuyển mạch mạch
end system: hệ thống đầu cuối/ hệ cuối
498

Book CNTT MMT 12 Feb 2012 c2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Book CNTT MMT 12 Feb 2012 c2

Uploaded by

Copyright:

Available Formats

Giáo trình Mạng máy tính

Khoa Công nghệ thông tin, Trường ĐHKHTN Tp.HCM

I. Các nguyên tắc chung của ứng dụng mạng

I.1 Các kiến trúc ứng dụng mạng

Mạng gia đình

Điểm truy cập vô tuyến

Máy tính Mạng

(Amazon, e-Bay), thư điện tử (yahoo mail), mạng xã hội (MySpace,

Mạng gia đình Mạng gia đình

Điểm truy cập vô tuyến Điểm truy cập vô tuyến

Máy tính Máy tính

Điểm truy cập vô tuyến Điểm truy cập vô tuyến

Máy tính Máy tính

I.2 Truyền thông giữa các tiến trình

Truyền tập tin Không Thích nghi Không

Thư điện tử Không Thích nghi Không

Dữ liệu web Không Thích nghi (vài kbps) Không

Điện thoại Internet / Âm thanh: vài kbps – 1Mbps Có: hàng

Lưu trữ âm thanh/ Có: vài

Gửi thông điệp tức Có và

Thư điện tử SMTP [RFC 5321] TCP

Tuy cập từ xa Telnet [RFC 854] TCP

Web HTTP [RFC 2616] TCP

Truyền file FTP [RFC 959] TCP

HTTP (như YouTube),

Điện thoại SIP, RTP, hoặc các giao

tử là SMTP (Simple Mail Transfer Protocol, RFC 5321), cũng là một

II. Web và giao thức HTTP

Hình 2.6. Mô hình yêu cầu - phản hồi

Máy phục vụ Web

Máy tính dùng Firefox

Hình II-6: Quá trình làm việc của HTTP

Máy phục vụ Web

Thời gian Thời gian

HTTP với các kết nối thường trực

Dòng yêu cầu method sp URL sp Version cr lf

Dòng yêu cầu version sp status code sp phrase cr lf

GET /-ross/ HTTP/1.1

Hình 2.10. Giữ trạng thái người dùng với cookie

phục vụ (hostname) và số định danh trong header Set-cookie:. tập

Hình 2.12. Cổ chai giữa mạng của một tổ chức và Internet

Hình 2.13. Thêm cache vào mạng tổ chức

III. Giao thức truyền file: FTP

Hình 2.15. Các kết nối điều khiển và dữ liệu

Các lệnh và phản hồi FTP

IV. Thư điện tử và Internet

Hình 2.16. Mô hình tổng quát hệ thống thư điện tử Internet

Hình 2.17. Alice gửi thông điệp cho Bob

Ví dụ, giả sử máy tính mạng apricot.poly.edu truy vấn dns.poly.edu về

Hình 2.22. Các câu truy vấn đệ qui trong DNS

V.3 Các mẩu tin DNS và các messages

Hình 2.23. Định dạng thông điệp DNS

RR kiểu A dành cho máy phục vụ web www.networkutopia.com và

VI. Các ứng dụng P2P

Hình 2.24. Mô tả vấn đề trong phân tán tập tin

Hình 2.26. Phân tán tập tin với BitTorrent

VII. Lập trình Socket với TCP

Hình 2.29. Socket khách, socket “welcoming”, và socket kết nối

Chương trình TCPClient.java chứa phần mã chương trình phía máy

Hình 2.31. TCPclient có 3 chuỗi kí tự lưu chuyển

ServerSocket welcomeSocket = new ServerSocket(6789);

VIII. Lập trình Socket với UDP

Mã chương trình tập tin UDPClienl.java