ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN THỊ HẠT 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
LUẬN VĂN THẠC SĨ

Ngành:
Công nghệ thông tin
Chuyên Ngành:
Truyền dữ liệu và mạng máy tính
Mã số:
604815 LUẬN VĂN THẠC SĨ NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS.TS Nguyễn Đình Việt Hà Nội - 2011

Hà Nội - 2011

Mục lục
Lời cám ơn 1
Lời cam đoan 2

3.1.1. Snoop 30
3.1.2. WTCP 31
3.1.3. Kết luận 34
3.2. Chia kết nối 35
3
3.2.1. Indirect TCP (I-TCP) 35
3.2.2. Kết luận 39
3.3. Cơ chế cảnh báo tường minh EN (Explicit Nofitication) 39
3.3.1. ICMP Message 39
3.3.2. Phương pháp thông báo mất dữ liệu tường minh ELN (Explicit Loss
Notification) 40
3.3.3. Phương pháp đếm syndrome 41
3.3.4. Phương pháp ACK thành phần (partial ACK) 41
3.3.5. Kết luận 42
3.4. Phương pháp End to End 42
3.4.1. Freeze TCP 43
3.4.2. TCP-Westwood 44
Chương 4. Giải pháp PEP với giao thức XCP và thí nghiệm mô phỏng 52
4.1 Tổng quát về TCP với XCP và giải pháp PEP 52
4.1.1 Giới thiệu về TCP 52
4.1.2 Giao thức XCP 53
4.1.3 Giải pháp sử dụng Proxy để nâng cao hiệu suất TCP - PEPs (Performance
Enhancement Proxies solution) 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 (Network Simulator) 55
4.2.2. Sử dụng phần mềm mô phỏng NS để mô phỏng đường truyền vệ tinh 55
4.2.3. Cài đặt vệ tinh và các trạm mặt đất 56
4.2.4. Kết nối vệ tinh 57
4.2.5. Hỗ trợ theo dõi 58
4.3. Giới thiệu thiết lập mô phỏng, kết luận và hướng làm việc trong tương lai 60

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
5
ZWA Zero Window Advertisement
ZWP Zero Window Probe
6
Danh mục các hình vẽ
Hình 1.1 Mô hình mạng vệ tinh 11
Hình 1.2 Mô hình lỗi Markov hai trạng thái 14
Hình 1.3 Mô hình lỗi Markov hai trạng thái cải tiến 15
Hình 2.1 Gói số liệu TCP với phần tiêu đề giả 18
Hình 2.2 Cấu trúc gói số liệu TCP 19
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 20
Hình 2.4 Cơ chế quản lý gửi dữ liệu theo cửa sổ của TCP 20
Hình 2.5 Quá trình slowstart và congestion avoidnce 22

Hình 4.3 Cấu trúc tập vết thông thường của NS 58
7
Hình 4.4 Mô hình mô phỏng 60
8
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

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

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.

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

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

đú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.
17
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ề

o RST = 1: Tái khởi tạo kết nối.
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.
18
� 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

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
20
(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:

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