NGHIÊN cứu ẢNH HƯỞNG của lỗi ĐƯỜNG TRUYỀN lên kết nối INTERNET QUA ĐƯỜNG TRUYỀN vệ TINH

1

Mục lục
L ời c ám ơ n



. 1
L ời c am đoa n



. 2
M ục l ụ c



. 3
D anh mục c á c hình vẽ



. 7
Ch ư ơng 1. Đặc t rư ng lỗi c ủ a đ ư ờng t r uyền vệ tin h





.

9
1 .

1. L ịch sử p h át t r iển và ư u nh ư ợc điểm của t r uyền thông vệ tin h





.

9
1 .

1 .

1. L ịch sử p h át t r iển của t r uyền thông vệ tin h





.

9
1 .

1 .

2. Ứng dụng c ủ a t r uyền thông vệ tinh

.

10
1 .

2. Đặc điểm lỗi đ ư ờng t r uyền vệ tinh



. 10
1 .

2 .

1 . C ác số liệu thống kê c ác đ ặ c điểm lỗi đ ư ờng t r uyền vệ tin h





.

10
1 .

2 .

2 . C ác mô hình lỗi t r ên đ ư ờng t r uyền vệ tin h



.

13
1 .

2 .

2 .

1 . M ô hình lỗi đồng đ ều ( Uni f o r m Err or Model )



.

14
1 .

2 .

2 .

2 . M ô hình lỗi Ma r kov hai t r ạng thái (T wo -

sta l e M a r kov Err or Mo d el )

14
1 .

2 .

2 .

3 . M ô hình lỗi Ma r kov hai t r ạng thái cải tiế n





.

15
1 .

2 .

2 .

4 . M ô hình lỗi Ma r kov đa t r ạng thái ( Multi- s tate e rr or mo d el )

.

15
Ch ư ơng 2. Giao th ứ c T CP và c á c c ơ c hế đ i ều khiển tắc nghẽ n





.

17
2 .

1. T ổng quan về g i ao th ứ c T CP



. 17
2 .

1 .

1. T ổng qua n



. 17

2 .

1 .

2. Cấu t r úc gói tin T C P





. 18
2 .

1 .

3. Cơ chế hoạt động c ủ a T C P



. 19
2 .

2. T CP và cơ chế điều khiển t ắc ng h ẽ n





. 21
2 .

2 .

1. Quá t r ình slow - sta r t v à c ongestion avoida n c e





.

21
2 .

2 .

2. Quá t r ình F ast - Ret r a n smi t





. 22
2 .

2 .

3. Quá t r ình F ast - R e cove r y

. 22
2 .

3. Một số ph i ên b ản T CP



. 23
2 .

3 .

1. T CP T ahoe



. 23
2 .

3 .

2. T CP Reno



. 24
2 .

3 .

3. T CP New - Ren o



. 25
2 .

3 .

4. T CP S ACK



. 25
2 .

4. Nh ữ ng vấn đề c ủa T CP t r ong môi t rư ờng mạng không dâ y





.

28
Ch ư ơng 3. Một số ph ư ơng pháp nâng c ao hiệu n ăng T CP t r ong mạng không d â y

.

29
3 .

1. L ink laye r



. 29
3 .

1 .

1. S noo p



. 30
3 .

1 .

2. W T C P



. 31

3 .

1 .

3. Kết luận



. 34
3 .

2. Chia kết nố i



. 35
2
3 .

2 .

1. I ndi r ect T CP (I -

T C P )





. 35

3 .

2 .

2. Kết luận



. 39
3 .

3. Cơ chế c ả nh báo t ư ờng minh E N (E xplicit No f itication )





.

39
3 .

3 .

1. I CMP M e s sag e



. 39
3 .

3 .

2. P h ư ơng pháp thông báo mất dữ l i ệu t ư ờng minh EL N (E xplicit L oss
Noti f ication)



. 40
3 .

3 .

3. P h ư ơng pháp đ ếm s ynd r om e



. 41
3 .

3 .

4. P h ư ơng pháp A CK t h ành phần ( pa r tial A CK )





.

41
3 .

3 .

5. Kết luận



. 42
3 .

4. P h ư ơng pháp E nd to E nd



. 42
3 .

4 .

1. Fr eeze T C P





. 43
3 .

4 .

2. T C P -

W e stwood



. 44
Ch ư ơng 4. Giải p h áp PE P với g i ao th ứ c X CP và thí nghiệm mô phỏn g





.

52
4 .

1 T ổng q u át về T CP với XCP và giải pháp PE P





.

52
4 .

1 .

1 Giới thiệu về T CP



. 52
4 .

1 .

2 G i ao th ứ c X CP



. 53
4 .

1 .

3 Giải pháp sử dụng Pr oxy để nâng c ao hiệu s uất T CP - PEP s (P e rf o r mance
E nhance m ent Pr oxies s olution )



.

54
4 .

2 Giới thiệu bộ phần mềm mô phỏng NS



.

55
4 .

2 .

1 Bộ mô phỏng mạng NS ( Netwo r k S imulato r )





.

55
4 .

2 .

2. S ử dụng phần mềm mô phỏng NS để mô phỏng đ ư ờng t r uyền vệ tin h

.

55
4 .

2 .

3. Cài đặt v ệ tinh và c ác t r ạm m ặt đấ t





.

56
4 .

2 .

4. Kết nối vệ tin h



. 57
4 .

2 .

5. Hỗ t r ợ theo dõi



. 58
4 .

3. Giới th i ệu thiết lập mô phỏng, kết luận v à h ư ớng l àm vi ệ c t r ong t ư ơng l a i





.

60
T ài liệu tham khả o



. 61
3
Danh mục các kí hiệu, các chữ viết tắt
ACK Acknowedgment
AIMD additive increase multiplicative decrease
ARP Address Resolation Protocol
ATM Asynchronous Transfer Mode
BER Bit Error Rate
BS Base Station
BWE Bandwidth Estimate

CWD Current window size
CWND Congestion window
EEM EURAD-Emission
ELN Explicit Loss Notification
EN Explicit Nofitication
FR/FR Fast-Retransmit/ Fast-Recovery
FTP File Transfer Protocol GEO
Geostationary Earth Orbit
GSO Geo-Stationary Earth Orbit
HTTP Hypertext Transfer Protocol
IP Internet Protocol
I-TCP Indirect- TCP
LAN Local Area Network
LEO Low Earth Orbit
MAC Media Access Control
MH Mobile Host
MIMD multiplicative increase multiplicative-decrease
MSR Mobile support router
NET Network
NS Network Simulator
PEP Performance Enhancement Proxy
RTO Retransmit time-out
RTO Retransmit Timeout
RTT Round Trip Time
SACK Selective Acknowedgment options
TCL Tool Command Language
TCP Transmission Control Protocol
UDP User Datagram Protocol
URG User Datagram Protocol
VJCC Van Jacobson Congestion Control

WLAN Wireless Local Area Network
WTCP Wireless Transmission Control Protocol
XCP eXplicit Control protocol
4
ZWA Zero Window Advertisement
ZWP Zero Window Probe
5
Danh mục các hình vẽ
Hình 1 .

1 Mô hình mạng vệ tin h



. 11
Hình 1 .

2 Mô hình lỗi M a r kov h ai t r ạng t h á i



.

14
Hình 1 .

3 Mô hình lỗi M a r kov h ai t r ạng t h ái c ải tiế n

.

15
Hình 2 .

1 Gói s ố liệu T CP với p h ần tiêu đề gi ả





.

18
Hình 2 .

2 Cấu t r úc gói số liệu T CP



. 19
Hình 2 .

3 P h ư ơng th ứ c bắt tay b a b ư ớc- th i ết lập kết nối, c hấm d ứ t ph i ên làm việ c

.

20
Hình 2 .

4 Cơ chế quản lý g ử i dữ liệu theo c ử a s ổ c ủ a T C P





.

20
Hình 2 .

5 Quá t r ình slows t a r t và cong e stion avoid n c e





.

22
Hình 2 .

6 Quá t r ình F ast - Ret r a n smi t

. 23
Hình 2 .

7 Lư u đổ giải th u ật sl o wsta r t



. 23
Hình 2 .

8 Lư u đồ chi tiết T C P -

T ah o e

.

. 24
Hình 2 .

9 Lư u đồ điểu khiển T C P -

R en o



.

25
Hình 2 .

10 P h ư ơng th ứ c hoạt động S AC K



.

26
Hình 2 .

11 Option thông báo cơ c h ế điều khiển S AC K





.

26
Hình 2 .

12 Option thông tin S ACK



. 26
Hình 2 .

13 Q u á t r ình khai báo sử dụng S AC K





. 27
Hình 3 .

1 Lư ợc đồ p h ân loại c á c g i ải pháp tối ư u h ó a T CP t r ong môi t rư ờng không dâ y

. .

29
Hình 3 .

2 Mô hình mạng không d ây với BS đóng vai t r ò S noo p





.

30
Hình 3 .

3 Lư u đồ S noop xử lý n h ận dữ liệu từ F H tại B S

.

31
Hình 3 .

4 Lư u đồ S noop xử lý khi nhận ACK từ M H t ại B S





.

31
Hình 3 .

5 Mô hình xử lý W T C P





. 31
Hình 3 .

6 Lư u đồ W T CP xử lý khi nhận dữ liệ u

.

32
Hình 3 .

7 Lư u đồ W T CP chu y ển tiếp gó i

. 33
Hình 3 .

8 Lư u đồ W T CP xử lý khi nhận AC K



.

34
Hình 3 .

9 Mô hình ch i a kết nối



. 35
Hình 3 .

10 Mô hình I -

T C P



. 36
Hình 3 .

11 BS đóng vai t r ò như Pr oxy t r ong I-T C P





.

36
Hình 3 .

12 Quá t r ình xử lý chu y ển vùng ( hando ff ) c ủa I-T C P





.

37
Hình 3 .

13 C á c b ư ớc th ự c hiện t r ong quá t r ình hando f f của I -

T C P



.

39
Hình 3 .

14 Mô hình xử lý A CK t h ành phầ n



.

42
Hình 3 .

15 Qui t r ình xử lý fr eeze T C P





. 43
Hình 3 .

16 Lư u đồ g i ải thuật T C P W tính s ố l ư ợng s egment đ ư ợc x ác nhậ n

.

46
Hình 3 .

17 Lư u đồ giải th u ật T C P W xử lý N du p ACKs tổng q u á t





.

47
Hình 3 .

18 Lư u đồ giải th u ật T C P W xử lý 3- dupAC K s th ự c nghiệ m





.

48
Hình 3 .

19 Lư u đồ giải th u ật T C P W xử lý timeout tổng quá t





.

49
Hình 3 .

20 Lư u đồ giải th u ật T C P W xử lý timeout th ự c nghiệ m





.

50
Hình 4 .

1 Cấu t r úc c ủa bộ mô phỏng N S -2



.

55
Hình 4 .

2 C á c thành phần chính c ủa mạng v ệ tin h





.

57
Hình 4 .

3 Cấu t r úc tập vết thông th ư ờng c ủa N S



.

58
6
Hình 4 .

4 Mô hình mô phỏn g



. 60
7
Chương 1. Đặc trưng lỗi của đường truyền vệ tinh
1.1. Lịch sử phát triển và ưu nhược điểm của truyền thông vệ tinh

1.1.1. Lịch sử phát triển của truyền thông vệ tinh
Người đầu tiên đã nghĩ ra vệ tinh nhân tạo dùng cho truyền thông là nhà viết
truyện khoa học giả tưởng Arthur C. Clarke vào năm 1945. Ông đã nghiên cứu về cách
phóng các vệ tinh, quỹ đạo của chúng và nhiều khía cạnh khác cho việc thành lập một hệ
thống vệ tinh nhân tạo bao phủ thế giới. Ông cũng đề xuất việc sử dụng 3 vệ tinh địa tĩnh
(geostationary) cho một hệ thống viễn thông, đủ để phủ sóng cho toàn bộ Trái Đất. Vệ
tinh nhân tạo đầu tiên là SPUTNIK 1 được Liên bang Xô viết phóng lên ngày 4 tháng 10
năm 1957 đã chứng minh cho ý tưởng của Arthur C. Clarke. Sự kiện này là một là động
lực thúc đẩy lớn lao đối với truyền thông vệ tinh của cả thế giới. Về mặt công nghệ,
SPUTNIK không thể so sánh được với các vệ tinh hiện đại ngày nay. Nó chỉ đơn thuần
phát ra các tín hiệu radio “bíp bíp” một cách đều đặn. Thế nhưng, đó quả thực là một
bước tiến to lớn của con người trong việc chinh phục không gian. Chỉ ba năm sau vào
năm 1960, vệ tinh ECHO của Mĩ trở thành vệ tinh truyền thông thực thụ đầu tiên của
nhân loại với khả năng tiếp nhận và phản hồi lại các tín hiệu radio. Tiếp theo ECHO, vệ
tinh địa tĩnh đầu tiên SYNCOM ra đời năm 1963 với ưu điểm lớn nhất là giữ được vị trí
tương đối cố định so với mặt đất. Khả năng tuyệt vời này đặt nền tảng cho việc phủ sóng
các chương trình thời sự toàn nước Mĩ tại thời đó.
Sau đó, hàng loạt các vệ tinh thương mại được đưa lên quỹ đạo như INTELSAT-1,
vệ tinh nặng 68 kg này cung cấp 240 kênh điện thoại song công tương đương với một
kênh truyền hình. Vệ tinh INTELSAT-2 và INTELSAT-3 với số kênh thoại lên tới 1200
kênh. Tới năm 1976 ra đời của MARISAT cung cấp dịch vụ truyền thông cho các phương
tiện giao thông đường thủy, từ đó người ta thấy các ăng-ten parabol bắt đầu xuất hiện trên
tầu thuyền, giúp các tầu thuyền có thể liên lạc thường xuyên với nhau và liên lạc với đất
liền trong các hành trình khắp nơi trên thế giới. Hệ thống điện thoại vệ tinh di động đầu
tiên, INMARSAT-A, được giới thiệu vào năm 1982. Sáu năm sau là INMARSAT-C. Đến
năm 1993, các hệ thống điện thoại vệ tinh được số hóa toàn bộ. Năm 1998 đánh dấu thế
hệ truyền thông vệ tinh mới với sự ra đời của các tổ hợp vệ tinh Iridium, đây là dự án đầy
tham vọng của Motorola nhằm xây dựng một hệ thống vệ tinh thông tin di động phủ sóng
khắp toàn cầu. Ban đầu dự án Iridium được thiết kế bao gồm 77 vệ tinh tạo thành một
mạng lưới mà khi hoàn thành sẽ cho phép 2 điểm bất kỳ trên trái đất có thể liên lạc được

với nhau. Tên của hệ thống (Iridium) được đặt theo tên của nguyên tố thứ 77 trong bảng
hệ thống tuần hoàn, 77 vệ tinh quay quanh trái đất như 77 electron quay quanh hạt nhân
nguyên tố Iridium. Khi triển khai thực tế, vì lý do kinh tế nên số vệ tinh được tính toán lại
8
và chỉ còn là 66 vệ tinh, tuy nhiên tên của hệ thống vẫn được đặt như ban đầu. Khi đưa
vào vận hành, hệ thống vệ tinh Iridium đã được coi như một thành tựu sáng chói của khoa
học kỹ thuật. Một hệ thống vệ tinh đáng chú ý khác là hệ thống Globalstar, với 48 vệ tinh
cung cấp các kênh truyền thương mại cho thấy sự phát triển thật ấn tượng của truyền
thông vệ tinh chỉ sau hơn 30 năm kể từ ngày ra đời.
1.1.2. Ứng dụng của truyền thông vệ tinh
Hiện nay, vệ tinh được sử dụng trong các lĩnh vực sau:
? Nghiên cứu khoa học: Do có diện tích quan sát rộng nên vệ tinh đã được sử dụng
rộng rãi trong nghiên cứu trái đất, môi trường cũng như dự báo thời tiết. Sử dụng các
công nghệ hiện đại, vệ tinh còn có khả năng nhìn sâu vào trong lòng đất phục vụ các
nghiên cứu địa chất, thăm dò tài nguyên. Ngoài ra, với ưu điểm không bị cản trở bởi
tầng khí quyển, các vệ tinh đã tỏ ra rất hiệu quả trong nghiên cứu thiên văn, vũ trụ.
? Định vị: Các hệ thống định vị và định vị toàn cầu sử dụng vệ tinh đã trở nên phổ
biến
với mọi người và tham gia vào nhiều mặt của đời sống, kinh tế xã hội từ tránh tắc nghẽn
giao thông, định vị trí trên đất liền, trên biển,
? Quân sự: Là một trong những ứng dụng đầu tiên mà loài người nghĩ tới. Vệ tinh
được
sử dụng tham gia các nhiệm vụ trinh sát, chụp ảnh do thám, gây nhiễu, phá hủy hạ tầng
truyền thông đối phương. Bên cạnh đó, thông tin liên lạc trong quân sự sử dụng vệ tinh
cũng tỏ ra an toàn hơn trước sự tấn công bằng các vũ khí thông thường của kẻ thù.
? Thông tin liên lạc: Vệ tinh có điểm ưu việt mà không một hệ thống ăng ten hay
truyền
hình cáp nào có được là bán kính phủ sóng rộng lớn. Chỉ có truyền thông vệ tinh mới phủ
sóng được tới các vùng xa xôi như các hải đảo, các vùng cực, Đối với truyền thông di
động, những ưu điểm của truyền thông vệ tinh được đặc biệt phát huy.

? Làm đường trục cho điện thoại toàn cầu: Ngay từ khi ra đời truyền thông vệ tinh
đã
đóng vai trò quan trọng trong liên lạc toàn cầu, đường truyền vệ tinh có băng thông rộng,
có thể truyền được rất nhiều kênh truyền điện thoại.
? Kết nối tới những vùng xa xôi hẻo lánh: Nhiều khu vực trên thế giới khó có thể
kéo
các đường truyền hữu tuyến tới do các nguyên nhân chủ quan (chính trị, quân sự) cũng
như khách quan (các yếu tố địa lý), khi đó đường truyền vệ tinh là lựa chọn lý tưởng.
? Thông tin di động toàn cầu: thường sử dụng vệ tinh quỹ đạo thấp vì độ trễ nhỏ hơn
so
với vệ tinh địa tĩnh.
1.2. Đặc điểm lỗi đường truyền vệ tinh
1.2.1. Các số liệu thống kê các đặc điểm lỗi đường truyền vệ tinh
9
Tỷ suất lỗi cao: Các hệ thống vệ tinh phát triển từ những vệ tinh truyền thông thế
hệ trước có tỷ suất lỗi bit BER (Bit Error Rate) cao gây ra bởi các chuẩn truyền thông:
10
trung bình là 10
-7
và 10
-4
trong trường hợp xấu nhất. Nguyên nhân là do các chuẩn trên
được tối ưu hóa cho việc truyền tín hiệu âm thanh và hình ảnh analog. Với các kỹ thuật
điều biến và mã hóa mới cùng với vệ tinh có công suất phát cao hơn, tỷ suất lỗi thông
thường sẽ đạt được rất thấp (đạt tới 10
-10
) khi sử dụng vệ tinh địa tĩnh. Đối với các hệ
thống vệ tinh quỹ đạo thấp, tỷ suất lỗi có thể biến động nhưng với các công nghệ hiện đại
các hệ thống này sẽ được phát triển để đạt tới chất lượng truyền cũng như độ ổn định
không thua kém đường truyền cáp quang. Các nguyên nhân gây lỗi là do nhiễu và suy

giảm tín hiệu truyền. Do tín hiệu vệ tinh là sóng điện từ truyền trong không gian nên
thường bị hấp thụ và suy yếu khi đi qua sương mù, mây, và đặc biệt là mưa.
Độ trễ: Do có sự hạn chế về tốc độ truyền và độ cao của các vệ tinh. Các thiết vị
thông tin liên lạc được đặt tại vệ tinh địa tĩnh GSO với độ cao là 36.000km. Ở độ cao đó,
vận tốc góc của vệ tinh bằng vận tốc góc của trái đất quay quanh trục của nó. Do đó mỗi
trạm ở mặt đất luôn có thể nhìn thấy các vệ tinh ở cùng một vị trí trên bầu trời, nghĩa là
các vệ tinh đứng yên so với mặt đất. Thời gian truyền tín hiệu radio giữa 2 trạm mặt đất
qua vệ tinh chuyển tiếp gấp 2 lần thời gian truyền từ trạm mặt đất tới vệ tinh, bằng
239,6ms.
Hình 1.1 Mô hình mạng vệ tinh
Đối với các trạm ở rìa của vùng của các vệ tinh (foot print) khoảng cách là 2*41,576km,
do đó thời gian truyền lớn hơn, bằng 2*279=558 ms (RTT). Ngoài sự trễ truyền, còn có
sự trễ khác, như trễ do phát gói tin lên đường truyền, trễ lan truyền trong mạng mặt đất
và độ trễ hàng đợi trong cổng kết nối vệ tinh. Kênh truyền vệ tinh được chi phối bởi hai
đặc điểm cơ bản như mô tả dưới đây:
Tiếng ồn: Cường độ của tín hiệu vô tuyến giảm theo khoảng cách truyền. Đối với
một liên kết vệ tinh khoảng cách là lớn và do đó tín hiệu sẽ trở nên yếu thậm chí rất yếu
khi đến đích của nó. Kết quả là tỉ số tín hiệu trên bị nhiễu SNR (Signal to Noise Ratio) bị
suy giảm. Một số tần số đặc biệt nhạy cảm với các hiện tượng xảy ra trong khí quyển như
sự suy giảm cường độ tín hiệu do mưa, sương mù Đối với các ứng dụng di động, kênh
vệ tinh đặc biệt nhạy cảm với hiện tượng truyền đa đường, gây ra sai lệch méo tín hiệu.
Tỷ lệ lỗi bit BER cho một liên kết vệ tinh ngày nay là khoảng một lỗi trên 10 triệu bit
(1x10
-7
) hoặc ít hơn. Các kỹ thuật kiểm soát lỗi và mã hóa nâng cao có thể được thêm vào
các dịch vụ truyền thông vệ tinh hiện nay. Tuy nhiên, nhiều hệ thống vệ tinh sẽ tiếp tục có
BER cao hơn so với các hệ thống vệ tinh mới và các kênh truyền trên mặt đất.
11
Băng thông: Tài nguyên phổ tần số radio có giới hạn, do đó chỉ có một số lượng
giới hạn băng thông sẵn có được cấp phép sử dụng cho các hệ thống truyền thông vệ tinh.

Điều này gây khan hiếm băng thông cho các ứng dụng thương mại khác. Tần số sóng
mang điển hình cho truyền vệ tinh, theo phương thức điểm-tới-điểm là 6GHz (uplink) và
4 GHz (downlink), còn được biết đến với tên gọi là băng tần C, và 14/12 GHz (được gọi
là băng tần Ku). Một dịch vụ đường truyền vệ tinh mới là 30/20 GHz (băng tần Ka) sẽ
xuất hiện trong vài năm tới đây. Các bộ lặp radio vệ tinh cơ bản được biết đến như là các
bộ tiếp sóng (transponder). Băng tần truyền thống C có băng thông thường là 36MHz, đáp
ứng được cho việc truyền một trong những kênh truyền hình màu (hoặc 1.200 kênh thoại).
băng tần Ku thường có dải tần nằm xung quanh rộng 50MHz. Hơn nữa một vệ tinh có thể
mang theo vài chục transponders. Băng thông cho truyền vệ tinh không chỉ bị hạn chế do
giới hạn có thể sử dụng được của nó, mà việc phân bổ cũng bị hạn chế bởi các thỏa thuận
quốc tế để nguồn tài nguyên khan hiếm này có thể sử dụng bởi nhiều ứng dụng khác
nhau. Kênh vệ tinh có một vài điểm khác biệt với kênh mặt đất. Nhưng các đặc điểm này
có thể làm suy giảm hiệu suất của giao thức TCP. Những đặc điểm này bao gồm:
Trễ phản hồi dài: Do sự trễ truyền của một số kênh vệ tinh (ví dụ khoảng 250ms
trên một vệ tinh địa tĩnh) có thể khá lớn, người gửi TCP phải đợi một khoảng thời gian
lớn mới xác định được một gói đã gửi đã được nhận thành công tại điểm đến cuối cùng
hay chưa. Việc chậm trễ này ảnh hưởng lớn đến các ứng dụng như telnet, cũng như một
số thuật toán điều khiển tắc nghẽn TCP.
Độ trễ lớn và băng thông: Tích số của dải thông và độ trễ xác định số lượng dữ
liệu một giao thức có thể gửi đi liên tiếp để sử dụng toàn bộ dung lượng của các kênh sẵn
có. Độ trễ sử dụng ở đây là khoảng thời gian khứ hồi RTT (Round Trip Time) và băng
thông là dung lượng (capacity) của liên kết nút cổ chai trong đường dẫn mạng. Bởi vì độ
trễ trong môi trường vệ tinh là rất lớn, TCP sẽ cần phải duy trì được một số lượng lớn các
gói tin trên đường truyền thì việc sử dụng kênh truyền vệ tinh mới có hiệu quả cao.
Truyền lỗi: Các kênh truyền hình vệ tinh có một tỷ lệ lỗi bit (BER) cao hơn các
kênh truyền trong mạng mặt đất đang được sử dụng phổ biến. Giao thức TCP sử dụng dấu
hiệu về các gói bị hủy bỏ (mất) như là một tín hiệu về sự tắc nghẽn mạng và phản ứng
bằng cách giảm kích cỡ cửa sổ phát để cố gắng giảm bớt tắc nghẽn. Trong trường hợp
không biết nguyên nhân vì sao một gói tin bị hủy bỏ (có thể là do tắc nghẽn). TCP đều
cho rằng là nguyên nhân là do tắc nghẽn và gọi phương thức điều khiển tránh tắc nghẽn

để tránh sự sụp mạng.
Bất đối xứng: Do chi phí là rất lớn nếu sử dụng thiết bị để gửi dữ liệu từ máy tính
của người sử dụng đến vệ tinh, cho nên mạng truyền thông vệ tinh không đối xứng
thường được xây dựng. Ví dụ, một máy tính kết nối với một mạng sử dụng vệ tinh sẽ gửi
tất cả thông tin đi (request) thông qua một liên kết mặt đất (uplink) có tốc độ truyền thấp
(như kênh mô hình quay số) và nhận được lưu lượng cần truy cập qua kênh vệ tinh
12
(downlink) có tốc độ truyền cao. Điều này chính là tính không đối xứng về độ trễ và dải
thông, có thể tác động xấu vào hiệu suất TCP.
Thời gian khứ hồi biến đổi (Variable Round Trip Times): Trong một số mạng vệ
tinh, chẳng hạn như mạng sử dụng vệ tinh quỹ đạo thấp LEO, sự trễ truyền đến và đi từ
các vệ tinh thay đổi liên tục theo thời gian.
Kết nối liên tục: Trong mạng không sử dụng vệ tinh địa tĩnh, kết nối TCP phải
được chuyển giao từ một vệ tinh này tới vệ tinh khác hay từ một trạm mặt đất này tới một
trạm mặt đất khác theo thời gian. Việc này có thể gây ra mất gói tin nếu không được thực
hiện đủ nhanh, khi đó kết nối sẽ bị gián đoạn. Hầu hết các kênh vệ tinh chỉ có một số
trong những đặc điểm trên.
1.2.2. Các mô hình lỗi trên đường truyền vệ tinh
Trong mục này, tôi xin trình bày các vấn đề về mô hình lỗi (Error Model) trong bộ
mô phỏng mạng NS2. Mô hình lỗi mô phỏng các lỗi truyền hoặc mất ở từng mức liên kết
hoặc bằng cách đánh dấu cờ lỗi của gói tin hoặc hủy gói tin tới đích. Trong giả lập, các lỗi
có thể được tạo ra từ một mô hình lỗi đơn giản như tỉ lệ lỗi của gói tin, hoặc phức tạp hơn
từ những mô hình thống kê và những mô hình thực nghiệm. Để hỗ trợ cho những mô hình
mở rộng, đơn vị lỗi có thể sử dụng tỉ lệ lỗi gói tin, tỉ lệ lỗi bit hoặc khoảng thời gian giữa
hai lỗi liên tiếp.
Lớp mô hình lỗi là xuất phát từ lớp cơ sở kết nối. Kết quả là nó được thừa kế một
vài phương thức cho việc tìm kiếm các đối tượng như đích và hủy đích. Nếu hủy đích tồn
tại, nó sẽ nhận một gói tin tạo ra từ mô hình lỗi. Nói cách khác, mô hình lỗi đánh dấu vào
cờ lỗi error_flag trong phần tiêu đề (header) của gói tin, do đó, cho phép các tác nhân
(agents) điều khiển việc loại bỏ gói lỗi. Mô hình lỗi cũng định nghĩa thêm vào phương

thức Tcl để chỉ ra đơn vị của lỗi và chỉ ra các biến ngẫu nhiên để tạo ra các lỗi. Nếu
không chỉ ra, đơn vị lỗi sẽ ở trong các gói tin và biến ngẫu nhiên sẽ được chỉ định là 0
hoặc 1. Dưới đây là một ví dụ đơn giản của việc tạo ra một mô hình lỗi với tỷ lệ lỗi gói tin
là 1%
# tạo ra một loss_module và thiết lập tỷ lệ lỗi gói tin đến 1%:
loss_module [new Error Model]
$loss_module set rate_ 0.01
# Tùy chọn: thiết lập các đơn vị tính lỗi và biến ngẫu nhiên
$loss_module unit pkt ;
# error unit: packets (the default)
$loss_module ranvar [new RandomVariable/Uniform]
# set target for dropped packets
$loss_module drop-target [new Agent/Null]
13
Để tạo mô hình lỗi cho mạng không dây, mỗi node (nút điểm) có thể được thêm
vào một mô hình thống kê cho lỗi cho cả các kênh (đường truyền) ra và kênh vào (đến).
Đặc biệt, mô hình lỗi sẽ nằm giữa tầng MAC và NET nếu các mô đun đã mô tả. Đối với
đường truyền (link) ra, mô đun lỗi sẽ chỉ ra bởi đích của mô đun MAC ở trên trong khi
đối với link vào nó sẽ chỉ ra liên kết bởi đích trên của mô đun NET ở dưới. Và trong mỗi
trường hợp đích của các mô đun lỗi chỉ ra bởi tương ứng cả NET hay MAC. Sự khác biệt
đặt trong hai địa điểm khác nhau là đối với điểm ra tất cả các máy nhận đều nhận được
các gói dữ liệu bị cùng một mức độ sai sót kể từ khi lỗi được xác định trước khi mô đun
của các kênh không dây sao chép gói tin. Mặt khác, các mô đun lỗi đến cho phép người
nhận nhận được các gói tin bị hỏng với mức độ khác nhau của lỗi vì lỗi là tính độc lập
trong mỗi module lỗi.
Việc chèn mô hình lỗi vào đường truyền không dây có thể được thực hiện bằng
cách gọi lệnh node-config với hai lựa chọn là IncommingErrProc và OutgoingErrProc.
Chúng ta có thể sử dụng hai lựa chọn cùng một lúc hoặc mỗi một cách riêng biệt. Ví dụ
một đoạn code TCL đơn giản:
$ns node-config -IncomingErrProc UniformErr -OutgoingErrProc UniformErr

proc UniformErr
set err [new ErrorModel]
$err unit packet
return $err
1.2.2.1. Mô hình lỗi đồng đều (Uniform Error Model)
Đây là mô hình lỗi đơn giản nhất, trong đó lỗi được phân bố đều. Đơn vị tính lỗi có
thể là gói tin, cũng có thể là byte hay bit. Mô hình này có nhược điểm là không phản ánh
được tính bùng nổ của lỗi đường truyền không dây. Chính vì vậy, nó thường chỉ được sử
dụng trong các nghiên cứu nhằm đạt được các kết quả có tính chất định tính.
1.2.2.2. Mô hình lỗi Markov hai trạng thái (Two-stale Markov Error Model)
Hình 1.2 Mô hình lỗi Markov hai trạng thái
Mô hình lỗi Markov hai trạng thái được thể hiện trên hình 1.2 theo mô hình này, đường
truyền có hai trạng thái là tốt - Good và xấu - Bad. Trọng trạng thái Good, tất cả các gói
tin đi qua đường truyền đều không bị lỗi; còn trong trạng thái xấu, tất cả các gói tin đi qua
đường truyền đều bị lỗi. Nếu độ dài trung bình của trạng thái Good là LG (bằng số gói tin
liên tiếp truyền thành công), ở trạng thái Bad là LB (bằng số gói tin liên tiếp truyền bị lỗi)
thì các xác suất chuyển trạng thái được tính như sau:
14
- Xác xuất chuyển từ trạng thái Good sang trạng thái Bad: PGB = 1/LG
- Xác xuất chuyển từ trạng thái Bad sang trạng thái tốt Good: PBG = 1/LB
Các xác suất chuyển là không nhỏ, nhờ tính chất quan trọng này mà trong mô hình, việc
chuyển trạng thái có thể thực hiện đối với từng gói tin. Mô hình lỗi Markov hai trạng thái
mô tả được tính bùng nổ của lỗi đường truyền không dây, chính xác hơn mô hình lỗi đồng
đều; tuy nhiên, mô hình này cũng chưa mô tả được chính xác tất cả các trạng thái lỗi
đường truyền. Do tính đơn giản nên mô hình lỗi Markov hai trạng thái thường được sử
dụng trong nghiên cứu, kể cả nghiên cứu bằng mô phỏng.
1.2.2.3. Mô hình lỗi Markov hai trạng thái cải tiến
Mô hình lỗi Markov hai trạng thái cải tiến được minh họa trên hình 1.3. Mô hình
này có hai trạng thái là tốt- Good và xấu- Bad. Trong trạng thái Good, các gói tin đi qua
đường truyền vẫn có thể bị lỗi với một giá trị trung bình và theo một phân bố nhất định,

được chỉ rõ. Tương tự như vậy, trong trạng thái Bad, không phải 100% gói tin đi qua
đường truyền đều bị lỗi.
Hình 1.3 Mô hình lỗi Markov hai trạng thái cải tiến
Các tham số của mô hình lỗi Markov hai trạng thái cải tiến có ý nghĩa như sau:
là tốc độ đến trung bình của gói số liệu bị lỗi khi đường truyền ở hai trạng thái
tương ứng là Good và Bad, chúng có một phân bố nào đó, thí dụ phân bố đều hoặc phân
bố hàm mũ.
TG và TB là độ dài trung bình của các trạng thái tương ứng Good và Bad. TG và TB tương
tự LG và LB trong mô hình lỗi Markov hai trạng thái, có đơn vị đo là gói tin (nên >=1).
PGB = 1/TG là xác suất chuyển từ trạng thái Good sang trạng thái Bad.
PGG = 1- PGB là xác suất ở lại trạng thái Good.
PBG = 1/TB là xác suất chuyển từ trạng thái Bad sang trạng thái Good.
PBB = 1- PBG là xác suất ở lại trạng thái Bad.
1.2.2.4. Mô hình lỗi Markov đa trạng thái (Multi-state error model)
Mô hình lỗi đa trạng thái thực hiện dựa trên chuyển đổi trạng thái lỗi dựa trên cơ
sở thời gian (time-based). Quá trình chuyển đổi trạng thái lỗi tiếp theo xảy ra vào cuối của
thời kỳ trạng thái lỗi hiện tại. Trạng thái lỗi tiếp theo sau đó được chọn bằng cách sử dụng
ma trận chuyển trạng thái.
15
Để tạo ra một mô hình lỗi nhiều trạng thái, các thông số sau đây cần được cung cấp (như
quy định tại ns / tcl / lib / ns-errmodel.tcl):
States: một dãy các trạng thái (các mô hình lỗi)
Periods: một dãy các thời kỳ trạng thái.
Trans: ma trận chuyển trạng thái.
Transunit: đơn vị tính tỉ lệ lỗi, có thể là một trong các đơn vị: pkt/byte/time.
Sttype: loại chuyển trạng thái, sử dụng thời gian hay pkt
Nstates: số các trạng thái
Start: bắt đầu trạng thái.
Dưới đây là một kịch bản ví dụ đơn giản để tạo ra một mô hình lỗi nhiều trạng thái:
set tmp [new ErrorModel/Uniform 0 pkt]

set tmp1 [new ErrorModel/Uniform .9 pkt]
set tmp2 [new ErrorModel/Uniform .5 pkt]
# Array of states (error models)
set m_states [list $tmp $tmp1 $tmp2]
# Durations for each of the states, tmp, tmp1 and tmp2, respectively
set m_periods [list 0 .0075 .00375]
# Transition state model matrix
set m_transmx { {0.95 0.05 0}
{0 0 1}
{1 0 0}
set m_trunit pkt
# Use time-based transition
set m_sttype time
set m_nstates 3
set m_nstart [lindex $m_states 0]
set em [new ErrorModel/MultiState $m_states $m_periods $m_transmx
$m_trunit $m_sttype $m_nstates $m_nstart]
17
Chương 2. Giao thức TCP và các cơ chế điều khiển tắc nghẽn
2.1. Tổng quan về giao thức TCP
2.1.1. Tổng quan
TCP là giao thức đảm bảo truyền thông tin cậy hướng kết nối - một kết nối ảo được
thiết lập trước khi các thực thể trên hai máy tính trong mạng bắt đầu truyền tin. Giao
thức TCP phức tạp chủ yếu bởi:
? phải quản lý đúng số tuần tự tính theo byte của dòng số
liệu.
? phải tối ưu hóa hiệu suất truyền bằng cách giám sát và điều khiển lưu lượng gửi
tin từ thực thể gửi tới thực thể nhận, đảm bảo tự thích ứng với trạng thái của đường
truyền được chia sẻ với các kết nối khác.
? phải đảm bảo trao đổi số liệu tin cậy và chính xác giữa thực thể cuối của mạng

chính
nhờ các yếu tố sau đây:
o Đối thoại khi thu phát: Mỗi khi gửi một gói số liệu, bên nhận phải thông báo nhận
đúng sau một khoảng thời gian nhất định. Nếu không, gói số liệu được coi là nhận sai
và được phát lại.
o Kiểm tra số liệu thu phát: Số liệu gửi được kiểm tra bằng thuật toán quy định. Các
byte kiểm tra (Checksum) được gửi cùng với số liệu phát và được so sánh với các byte
kiểm tra tính lại khi thu. Trong trường hợp sai lệch, có nghĩa là có lỗi xảy ra trên
đường truyền, thực thể thu thông báo kết quả thu cho thực thể phát và yêu cầu gửi lại.
o Kiểm tra số tuần tự: Vì các gói TCP được truyền thành các gói IP và các gói IP có
thể đến đích không theo thứ tự phát (IP là giao thức không hướng kết nối) nên thực thể
TCP nhận phải lập lại trật tự các gói số liệu thu được, hủy bỏ các gói số liệu trùng lặp
khi cần và chuyển các gói số liệu đó theo đúng trật tự phát cho các ứng dụng.
o Điều khiển lưu lượng: Mỗi thực thể của kết nối TCP đều có một vùng đệm hạn chế.
Thực thể TCP nhận chỉ cho phép thực thể phát gửi một lượng số liệu đủ với vùng đệm
thu của mình. Điều này sẽ ngăn cản thực thể TCP phát truyền quá nhanh, làm tràn
vùng đệm của thực thể TCP thu nhận. Các thực thể ứng dụng sử dụng dịch vụ truyền
dẫn tin cậy của TCP mô tả ở trên để trao đổi số liệu. Chú ý rằng, thực thể ứng dụng và
thực thể TCP có bộ đệm riêng của mình để lưu giữ tạm thời số liệu trong quá trình xử
lý. Cách thức chuyển tiếp số liệu giữa hai bộ đệm trên là yếu tố quyết định hiệu suất
chuyển tiếp số liệu của hệ thống TCP. Số liệu có thể truyền toàn bộ hoặc một phần từ
bộ đệm ứng dụng tới bộ đệm TCP, trước khi quá trình phát được khởi động; số liệu thu
từ kết nối TCP có thể chuyển tiếp tức thời từ bộ đệm thu TCP tới bộ đệm ứng dụng
hoặc chỉ khi tỷ lệ phần bộ đệm bị chiếm dụng so với tổng dung lượng bộ đệm đạt tới
một giá trị nào đó. Các giao thức vận chuyển quy định về cách thức trao đổi số liệu
giữa các thực thể cùng mức chức năng, chứ không quy định việc thực hiện cụ thể như
thế nào.
18
2.1.2. Cấu trúc gói tin TCP
Hình 2.1 Gói số liệu TCP với phần tiêu đề giả

Cấu trúc gói số liệu TCP gồm phần tiêu đề TCP “giả” (Pseudo header TCP) mô
tả trong hình 2.1 và gói số liệu TCP “thực” (TCP Segment) được mô tả trong hình 2.2.
Phần tiêu đề giả cần thiết cho việc xây dựng gói số liệu IP, bao gồm các thông tin về
địa chỉ IP nguồn, địa chỉ IP đích, số liệu thuộc giao thức TCP (trường protocol có giá
trị 0x06) và độ dài của gói TCP thực:
Ý nghĩa của các trường của gói số liệu TCP thực:
? Soure Port: Số hiệu cổng TCP bên
phát.
? Destination Port: Số hiệu cổng TCP bên đích; các số hiệu cổng cùng với địa chỉ
IP nguồn và địa chỉ IP đích trong gói số liệu IP định danh duy nhất hai tiến trình ở
hai đầu kết nối TCP.
? Sequence number: Số tuần tự phát, định danh byte đầu tiên của phần số liệu
thuộc
gói số liệu TCP trong luồng số liệu từ thực thể TCP gửi đến thực thể TCP nhận. Số
tuần tự phát là khoảng cách tương đối của byte đầu tiên phần số liệu với byte đầu tiên
của dòng byte; đó là số không dấu 32 bit, có giá trị nằm trong khoảng từ 0 đến 2
32
-1.
o Nếu ta coi dòng byte là luồng số liệu một chiều từ một ứng dụng này tới ứng dụng
kia thì TCP đánh số tất cả các byte với các giá trị gọi là số tuần tự (sequence number).
o Khi một kết nối được thiết lập trường số tuần tự chứa giá trị khởi tạo ISN (Initial
Sequence Number) được thực thể TCP chọn cho kết nối này. Byte số liệu đầu tiên sẽ
có số tuần tự bằng ISN +1.
? Acknowlegement: Vị trí tương đối của byte cuối cùng đã nhận đúng bởi thực
thể
nhận cộng thêm 1. Giá trị của trường này còn được gọi là số tuần tự thu. Giá trị của
trường này đúng khi bit cờ ACK =1.
? Data Offset: Khoảng cách tương đối của trường số liệu với phần tiêu đề của
TCP
(TCP header) tính theo từ 32 bit. Thông thường trường này có giá trị bằng 5 vì độ dài

thông thường của phần tiêu đề TCP là 20 bytes.
? Reserved: Luôn được đặt là 0, để dùng cho tương
lai.
? FLAGs: Có 6 bit cờ trong phần tiêu đề TCP. Một hay nhiều cờ có thể được thiết
lập tại cùng một thời điểm.
o URG = 1: Thông báo giá trị trường Urgent Pointer đúng.
o ACK = 1: Thông báo giá trị trường Acknowledgment đúng.
o PSH = 1: Thực thể nhận phải chuyển số liệu này cho ứng dụng tức thời.
o RST = 1: Tái khởi tạo kết nối.
19
o SYN = 1: Đồng bộ trường số thứ tự, dùng để thiết lập kết nối TCP.
o FIN = 1: Thông báo thực thể gửi đã kết thúc gửi số liệu.
20
? Windows size: Độ lớn cửa sổ bên thu, quy định tổng số byte số liệu mà thực thể
thu có thể nhận được (đồng nghĩa với độ lớn bộ đệm thu) tính khởi đầu từ giá trị
trường số tuần tự thu (Acknowlegment Number).
? Checksum: tổng kiểm tra, là giá trị bù 1 của tổng các nhóm 16-bit trong phần đầu
và
phần số liệu TCP. Giá trị này tính cả 12 byte tiêu đề giả của TCP.
? Urgent Pointer: Vị trí tương đối của byte trong trường số liệu TCP cần được xử
lý đầu tiên. Giá trị trường này đúng khi bit cờ URG = 1.
? Options: Tuỳ chọn thường được dùng hiện nay là quy định về độ dài lớn nhất
MSS
(Maximum Segment Size) của một gói số liệu TCP; có thể khai báo tuỳ chọn SACK
tại trường này.
? Pad: Độn thêm vào phần tiêu đề, để độ lớn của nó là bội của 4
byte.
? Data: Số liệu của ứng dụng
TCP.
Hình 2.2 Cấu trúc gói số liệu TCP

2.1.3. Cơ chế hoạt động của TCP
Thiết lập kết nối
Kết nối TCP được thiết lập trên cơ sở phương thức bắt tay ba bước. Tiến trình
bắt đầu khi trạm làm việc (Agent A) yêu cầu thiết lập một kết nối TCP bằng cách gửi
một gói TCP với cờ SYN = 1, gọi tắt là gói điều khiển SYN, và giá trị khởi tạo số tuần
tự ISN của mình. Giá trị ISN là số 32 bit và được tăng mỗi khi có một kết nối mới
được yêu cầu tạo ra (giá trị này quay về 0 khi nó đạt tới giá trị 2
32
). Trong gói điều
khiển SYN này còn chứa số hiệu cổng TCP của phần mềm dịch vụ mà tiến trình trạm
làm việc muốn kết nối (bước 1). Mỗi thực thể kết nối TCP đều có một giá trị ISN mới,
số này được tăng theo thời gian. Vì một kết nối TCP mới có thể dùng lại số hiệu cổng
và địa chỉ IP đã được sử dụng trước đó, do đó việc thay đổi giá trị ISN giúp các kết nối
có cùng một địa chỉ kết nối tránh được việc dùng lại các số liệu đã ôi (stale) vẫn còn
đang được truyền trong mạng Internet nhưng thuộc một kết nối cũ.
Hình 2.3 Phương thức bắt tay ba bước - thiết lập kết nối. Sau khi nhận được gói điều
21
khiển SYN và ở trạng thái sẵn sàng chấp nhận kết nối, thực thể TCP nhận của phần
22
mềm dịch vụ (Agent B) gửi lại gói SYN với giá trị ISN của mình, và đặt bit cờ
ACK=1 để thông báo rằng thực thể nhận đã nhận được giá trị ISN của thực thể gửi
(bước 2). Cuối cùng, Agent A trả lời Agent B khi nhận được tín hiệu SYN của Agent
B bằng một ACK cuối cùng, khẳng định đã nhận được giá trị ISN của Agent B. Bằng
cách này, các thực thể TCP trao đổi một cách tin cậy các giá trị ISN của nhau và sẵn
sàng trao đổi số liệu. Chú ý rằng không có gói điều khiển SYN nào trong 3 bước trên
chứa số liệu của thực thể ứng dụng, tất cả các số liệu điều khiển được trao đổi đều nằm
trong phần tiêu đề của gói điều khiển TCP (bước 3).
Chấm dứt phiên làm việc
Để chấm dứt phiên làm việc, thực thể TCP (Agent A trên hình 2.3) gửi yêu cầu chấm
dứt kết nối với cờ FIN cho đối tác truyền thông của nó. Vì kết nối TCP là song công

nên mặc dù nhận được yêu cầu chấm dứt phiên làm việc (mà thực chất là thông báo
hết số liệu để gửi), thực thể đối tác (Agent B trên hình 2.3) vẫn có thể tiếp tục truyền
số liệu cho đến khi không còn số liệu để gửi và thông báo cho thực thể TCP rằng yêu
cầu kết thúc kết nối với cờ FIN của mình. Tóm lại, kết nối TCP chỉ thực sự kết thúc
khi thực thể nhận yêu cầu chấm dứt kết nối gửi trả lại cho thực thể yêu cầu một gói tin
cũng với cờ FIN.
Hình 2.3 Phương thức bắt tay ba bước- thiết lập kết nối, chấm dứt phiên làm việc
Cơ chế điều khiển tránh tắc nghẽn TCP gắn liền với việc điều khiển luồng. TCP xác
lập một cửa sổ cho việc điều khiển. Bằng cách so sánh giá trị cần quan tâm hiện tại với
phạm vị cửa sổ (trong phạm vi, vượt trên hay thấp hơn) để đưa ra các quyết định điều
khiển khác nhau. Giá trị thực hiện tại được gọi là cwnd (current window size).
Hình 2.4 Cơ chế quản lý gửi dữ liệu theo cửa sổ của TCP
Quá trình điều khiển luồng nguyên thủy của TCP chỉ đơn giản chấp nhận mức tối đa
cửa sổ thu và cho phép đầu phát gửi một gói mới khi nhận được ACK từ đầu thu. Điều
này đã gây nên hiện tượng tắc nghẽn. Vào cuối thập niên 80, nó trở thành một vấn đề
thật sự. Từ 1988, Tahoe TCP ra đời đánh dấu một bước khởi đầu cho các giải thuật
điều khiển tắc nghẽn của TCP. Giải thuật tránh tắc nghẽn nguyên thủy của TCP thực
chất bao gồm các thuật toán sau: slow-start (khởi đầu chậm), congestion avoidance
23
(tránh tắc nghẽn) và Fast-Retransmit (truyền lại nhanh). Năm 1990, Reno TCP ra đời
và bổ sung một quá trình xử lý mới được gọi là Fast-Recovery (khôi phục nhanh).
Kể từ khi Tahoe ra đời, bên cạnh giá trị cửa sổ đầu thu (hay còn gọi là cửa sổ quảng bá
đầu thu – awnd), một giá trị cửa sổ khác được định nghĩa cho mục đích điều khiển tắc
nghẽn phía thu, đó là congestion window (cửa sổ điều khiển tắc nghẽn), cwnd, và giá
trị ngưỡng cho quá trình slow-start : sstrhresh (slow-start threshold). Khi đó, cửa sổ
phát , được định nghĩa: w = min (cwnd, awnd).
Mục đích của cwnd là ngăn đầu phát phát quá mức dữ liệu so với khả năng đáp ứng
của đầu thu. Việc điều khiển tắc nghẽn được thực hiện bằng cách thay đổi cwnd.
Trong thực tế, việc thay đổi này được thực hiện khi có gói bị mất. Việc phát hiện mất
gói có thể thông qua time-out hay nhận được duplicate ACKs (nhập các gói ACK

giống nhau) – dupACKs tại đầu phát.
Time-outs: liên kết với mỗi gói là một đồng hồ - timer. Nếu hết thời hiệu (time-out)
mà không nhận được ACKs từ đầu thu, đầu phát sẽ tiến hành gửi lại gói này. Giá trị
của bộ định thời còn được gọi là RTO (Retransmit time-out), được tính dựa trên giá trị
thời gian khứ hồi trung bình RTT (round time-trip). Tuy nhiên giá trị của RTT không
thể biết được trong thực tế, nó được đo thông qua giải thuật Jacobson/Karels.
Duplicate ACKs: khi một gói bị mất, đồng nghĩa với việc đầu thu không nhận được
gói đó. Nó phá vỡ sự tuần tự các gói nhận được ở đầu thu. Lúc này, đầu thu liên tục
gửi ACK với cùng một giá trị để biên nhận cho các gói tin không lỗi đến sau gói tin bị
mất. Đây là căn cứ cho đầu phát biết đã có mất gói.
2.2. TCP và cơ chế điều khiển tắc nghẽn
2.2.1. Quá trình slow-start và congestion avoidance
Trong quá trình slow-start, khi mà kết nối vừa được thiết lập, cwnd được thiết lập giá
trị là 1. Sau mỗi gói “ACK mới” nhận được:
Việc tăng tuyến tính này được tiếp tục cho tới khi có gói bị mất hoặc đạt ngưỡng
ssthresh. Trong trường hợp có gói bị mất, ssthresh = cwnd/2 và cwnd được trả về bằng
1. Trong trường hợp cwnd đạt ngưỡng ssthresh, thực thể gửi TCP chuyển sang quá
trình congestion avoidance. Khi này, thay vì tăng theo hàm mũ cơ số 2, cwnd tăng
tuyến tính: cwnd = cwnd + 1/cwnd. Việc tăng này sẽ tiếp tục cho đến khi có gói bị
mất.
Quá trình slow-start nhằm mục đích “thăm dò” khả năng của đường truyền hiện
tại. Mặc dầu được thiết lập ở mức thấp (cwnd =1), song lại tăng rất nhanh tương tự
như quá trình hiệu chỉnh thô khả năng phát gói. Khi xảy ra tắc nghẽn, quá trình
congestion avoidance lại giống như quá trình hiệu chỉnh tinh, đồng thời, cũng là để
hạn chế tắc nghẽn. Mục đích cuối cùng của cả hai quá trình là đảm bảo việc phát gói ở
mức cao nhất có thể được.
24
Hình 2.5 Quá trình slowstart và congestion avoidnce
2.2.2. Quá trình Fast-Retransmit
Mục đích của Fast-Retransmit là tăng tốc quá trình truyền lại bằng cách cho phép đầu

gửi truyền lại gói bị mất càng sớm càng tốt ngay khi có đủ căn cứ về việc mất gói. Có
nghĩa là thay vì phải chờ đến khi time-out, đầu phát có thể truyền lại ngay khi cần
thiết, đó là khi nhận được liên tiếp 3 biên nhận lặp (dupAcks).
2.2.3. Quá trình Fast-Recovery
Với Tahoe TCP, kết nối luôn trở về quá trình slow-start ngay khi phát hiện mất gói.
Tuy nhiên, nếu như window size lớn và tỉ lệ mất gói là ít khi xảy ra, thì việc đó là
không cần thiết vì hoàn toàn có thể chuyển sang trạng thái congestion avoidance. Mục
đích của Fast-Recovery nhằm thực hiện ý tưởng trên. Trong quá trình Fast-Retransmit,
bên gửi ghi nhận lại gói truyền lại. Sau khi gói đã truyền lại, giá trị của ssthresh và
cwnd sẽ được hiệu chỉnh theo nguyên tắc:
Điều này đồng nghĩa với kết nối sẽ tiếp tục với quá trình congestion avoidance, với giá
trị cửa sổ phát cwnd giảm xuống còn bằng một nửa chứ không phải xuống bằng 1.
25
Hình 2.6 Quá trình Fast-Retransmit
2.3. Một số phiên bản TCP
2.3.1. TCP Tahoe
TCP Tahoe được đề xuất bởi Jacobson, 1988. Tahoe là giải thuật điều khiển tránh tắc
nghẽn đầu tiên, bao gồm 3 giai đoạn: slow-start, congestion avoidance và Fast-
Retransmit. Theo đề xuất ban đầu của Jacobson, TCP Tahoe chỉ xác nhận việc mất gói
thông qua sự kiện hết giờ (time-out) chứ không căn cứ vào lặp dupAcks. Do đó, một
vấn đề nảy sinh với Tahoe là phải chờ một khoảng thời để có thể phát hiện ra việc mất
gói. Điều này khiến Tahoe phản ứng khá chậm chạp với tắc nghẽn. Mặt khác, khi có
một gói bị mất, Tahoe sẽ chờ cho tới khi timeout trong khi đường truyền lại rỗi gây
lãng phí đường truyền. Do đó, một cải tiến của Tahoe là xem việc nhận được ba lần
dupACKs tương ứng với mất gói.
Hình 2.7 Lưu đổ giải thuật slowstart
26
Hình 2.8 Lưu đồ chi tiết TCP-Tahoe
2.3.2. TCP Reno
TCP Reno được cải tiến từ TCP Tahoe (Jacobson 1990). TCP Reno định nghĩa giai

đoạn Fast-Recovery. Giai đoạn này được bắt đầu khi đầu phát nhận được 3 dupACKs.
Lý do không trở về slow-start trong trường hợp này là việc nhận các dupACKs đồng
nghĩa với có tương ứng các gói TCP đã được nhận thành công ở đầu thu. Tức là luồng
dữ liệu vẫn đang được duy trì giữa đầu phát và đầu thu, và TCP không muốn giảm
lượng trên luồng một cách đột ngột khi chuyển về slow-start. Giai đoạn Fast-
Retransmit và Fast-Recovery lúc này được phối hợp thực hiện và gọi chung là FR/FR.
Khi nhận được dupACKs lần thứ 3 liên tục, giá trị ssthresh giảm và bằng một nửa giá
trị cwnd, nhưng không nhỏ hơn 2. Quá trình retransmit được thực thi để truyền lại gói
mất. Đồng thời, cwnd được gán giá trị bằng ssthresh cộng với kích thước 3 segment
(nếu tính theo kích thước) hay cộng với 3 gói (nếu tính theo gói). Việc này gián tiếp
điều khiển cửa sổ phát (w = min(awnd, cwnd)). Với mỗi dupACKs, cwnd lại tăng
thêm một (= 1). Như vậy, tổng quát:
Tương ứng w (cửa sổ phát) cũng sẽ tăng lên 1 lượng n. dupACKs đúng bằng số gói đã
gửi thành công cho tính từ lúc có hiện tượng mất gói. Do đó, luồng phát được duy trì.
Khi có một ACK mới, cwnd được trả về mức ssthresh và bắt đầu quá trình congestion
avoidance