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 . .

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 .
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 )

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 .


. 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 .
.

29
3 .

1. L ink laye r
. 29
3 .

1 .

1. S noo p
. 30
3 .

1 .

2. W T C P
. 31

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 .

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 .



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 .


.

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 .


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
.

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
. 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
.


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 .

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 -

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

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 .

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

? 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

Đ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

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

đượ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]

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ả

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

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

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