Bài giảng Mạng máy tính - Chương 3: Tầng giao vận

1-1
Mạng máy tính
Bộ môn Kỹ thuật máy tính và Mạng
Khoa Công nghệ Thông tin
Đại học Sư phạm Hà Nội
1-2
Chương 3: Tầng giao vận
Mục đích:
‰ Hiểu các nguyên tắc
bên trong dịch vụ của
tầng giao vận:
 Multiplexing/Demultiple
xing
 Truyền dữ liệu tin cậy
 Điều khiển luồng
 Điều khiển tắc nghẽn
‰ Học về giao thức tầng giao
vận trong Internet:
 UDP: không hướng kết nối
 TCP: hướng kết nối
 Điều khiển tắc nghẽn của
TCP
1-3
Chương 3: Tầng giao vận
‰ 3.1 Các dịch vụ tầng
giao vận
‰ 3.2 Multiplexing và
demultiplexing
‰ 3.3 Dịch vụ không
hướng kết nối: UDP
‰ 3.4 Các nguyên tắc của
truyền dữ liệu tin cậy
‰ 3.5 Dịch vụ hướng kết 
nối: TCP
 Cấu trúc segment
 Truyền dữ liệu tin cậy
 Điều khiển luồng
 Quản lý kết nối
‰ 3.6 Các nguyên tắc của 
điều khiển tắc nghẽn
‰ 3.7 Điều khiển tắc nghẽn 
của TCP
1-4
Các giao thức và dịch vụ tầng giao vận
‰ Cung cấp truyền thông lô-gíc 
giữa các tiến trình ứng dụng 
chạy trên các host khác nhau
‰ Các giao thức giao vận chạy 
trên các hệ thống cuối
 Bên gửi: chia các bản tin 
ứng dụng thành các 
segment, chuyển tới tầng 
mạng
 Bên nhận: ghép các
segment thành bản tin, 
chuyển lên tầng ứng dụng
‰ Nhiều hơn một giao thức giao 
vận cho ứng dụng
 Internet: TCP và UDP
application
transport
network
data link
physical
application
transport
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physicalnetwork
data link
physical
1-5
Tầng giao vận và tầng mạng
‰ Tầng mạng: truyền thông lô-
gíc giữa các host
‰ Tầng giao vận: truyền thông
lô-gíc giữa các tiến trình
 dựa trên dịch vụ của tầng
mạng
Tương tự hộ gia đình:
12 đứa trẻ gửi thư cho 12 đứa
trẻ
‰ Các tiến trình = các đứa trẻ
‰ Các bản tin ứng dụng = các
bức thư
‰ host = nhà
‰ Giao thức giao vận = Ann 
và Bill
‰ Giao thức tầng mạng = dịch
vụ chuyển thư
1-6
Các giao thức tầng giao vận của Internet 
‰ Truyền tin cậy, có thứ tự
(TCP)
 Điều khiển tắc nghẽn
 Điều khiển luồng
 Thiết lập kết nối
‰ Truyền không có thứ tự, 
không tin cậy: UDP
‰ Các dịch vụ không có: 
 Đảm bảo độ trễ
 Đảm bảo băng thông
application
transport
network
data link
physical
application
transport
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physicalnetwork
data link
physical
1-7
Chương 3: Tầng giao vận
‰ 3.1 Các dịch vụ tầng
giao vận
‰ 3.2 Multiplexing và
demultiplexing
‰ 3.3 Dịch vụ không
hướng kết nối: UDP
‰ 3.4 Các nguyên tắc của
truyền dữ liệu tin cậy
‰ 3.5 Dịch vụ hướng kết
nối: TCP
 Cấu trúc segment
 Truyền dữ liệu tin cậy
 Điều khiển luồng
 Quản lý kết nối
‰ 3.6 Các nguyên tắc của
điều khiển tắc nghẽn
‰ 3.7 Điều khiển tắc nghẽn
của TCP
1-8
Multiplexing/demultiplexing
application
transport
network
link
physical
P1 application
transport
network
link
physical
application
transport
network
link
physical
P2P3 P4P1
host 1 host 2 host 3
= tiến trình= socket
Chuyển các segment đã nhận
tới đúng socket
Demultiplexing tại host nhận:
Thu thập dữ liệu từ các socket,
đóng gói dữ liệu bởi header 
(sau đó sẽ dùng để
demultiplexing)
Multiplexing tại host gửi:
1-9
Thực hiện demultiplexing
‰ Host nhận gói dữ liệu IP 
 Mỗi gói dữ liệu có địa chỉ IP 
nguồn, địa chỉ IP đích
 Mỗi gói dữ liệu mang một
segment của tầng giao vận
 Mỗi segment có giá trị cổng
nguồn và cổng đích (giá trị
cổng cố định cho các kiểu
ứng dụng cụ thể)
‰ Host sử dụng địa chỉ IP và giá
trị cổng để chuyển segment tới
socket thích hợp
source port # dest port #
32 bits
Dữ liệu ứng dụng
(bản tin)
Các trường header 
Định dạng TCP/UDP segment
1-10
Chương 3: Tầng giao vận
‰ 3.1 Các dịch vụ tầng
giao vận
‰ 3.2 Multiplexing và
demultiplexing
‰ 3.3 Dịch vụ không
hướng kết nối: UDP
‰ 3.4 Các nguyên tắc của
truyền dữ liệu tin cậy
‰ 3.5 Dịch vụ hướng kết
nối: TCP
 Cấu trúc segment
 Truyền dữ liệu tin cậy
 Điều khiển luồng
 Quản lý kết nối
‰ 3.6 Các nguyên tắc của
điều khiển tắc nghẽn
‰ 3.7 Điều khiển tắc nghẽn
của TCP
1-11
UDP: User Datagram Protocol [RFC 768]
‰ Dịch vụ “best effort”, UDP 
segment có thể:
 mất
 chuyển không theo thứ
tự đến ứng dụng
‰ Không hướng kết nối:
 Không có bắt tay giữa
bên gửi và bên nhận
 Mỗi UDP segment được
điều khiển độc lập
Tại sao có UDP?
‰ Không thiết lập kết nối (thiết
lập có thể tăng độ trễ)
‰ Đơn giản: không có trạng
thái kết nối tại bên gửi, bên
nhận
‰ Header của segment nhỏ
‰ Không điều khiển tắc nghẽn: 
UDP có thể gửi ra với tốc độ
mong muốn
1-12
UDP (tiếp)
‰ Thường sử dụng cho các
ứng dụng đa phương tiện
truyền dòng
 Chấp nhận mất gói
 Nhạy cảm với tốc độ
‰ Ứng dụng khác sử
dụng UDP
 DNS
 SNMP
‰ Truyền tin cậy qua UDP: 
thêm sự tin cậy tại tầng ứng
dụng
 Khôi phục lỗi do ứng
dụng cụ thể
source port # dest port #
32 bits
dữ liệu
của ứng dụng
(bản tin)
Định dạng của UDP segment
length checksum
Length tính
theo byte của
UDP 
segment,
bao gồm
header
1-13
UDP checksum
Bên gửi:
‰ Đối xử với nội dung các
segment như chuỗi các số
nguyên 16 bít
‰ checksum: cộng (tổng bù
của 1) của nội dung 
segment
‰ Phía gửi đặt giá trị
checksum trong trường
checksum của UDP
Bên nhận:
‰ Tính toán checksum của
segment nhận được
‰ Kiểm tra xem checksum đã
tính có bằng giá trị trường
checksum:
 KHÔNG BẰNG– Phát hiện
có lỗi
 BẰNG – không phát hiện ra
lỗi. Nhưng có thể có lỗi?
Mục đích: phát hiện lỗi trong segment đã truyền
1-14
Ví dụ Checksum
‰ Chú ý
 Khi cộng các số, giá trị bít nhớ cần thêm vào kết
quả
‰ Ví dụ: cộng hai số nguyên 16 bít
1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
Tổng
checksum
1-15
Chương 3: Tầng giao vận
‰ 3.1 Các dịch vụ tầng
giao vận
‰ 3.2 Multiplexing và
demultiplexing
‰ 3.3 Dịch vụ không
hướng kết nối: UDP
‰ 3.4 Các nguyên tắc của
truyền dữ liệu tin cậy
‰ 3.5 Dịch vụ hướng kết
nối: TCP
 Cấu trúc segment
 Truyền dữ liệu tin cậy
 Điều khiển luồng
 Quản lý kết nối
‰ 3.6 Các nguyên tắc của
điều khiển tắc nghẽn
‰ 3.7 Điều khiển tắc nghẽn
của TCP
1-16
Các nguyên tắc của truyền dữ liệu tin cậy
‰ Tầm quan trọng của tầng liên kết dữ liệu, tầng giao vận, tầng
ứng dụng
‰ Đặc điểm của kênh truyền không tin cậy xác định sự phức tạp
của giao thức truyền dữ liệu tin cậy (rdt)
(a) Dịch vụ cung cấp (b) Cài đặt dịch vụ
1-17
Truyền dữ liệu tin cậy
Bên gửi Bên nhận
rdt_send(): được gọi bởi tầng trên. 
Dữ liệu đã chuyển được chuyển tới
tầng trên của bên nhận
udt_send(): gọi bởi rdt, để
truyền gói tin qua kênh không
tin cậy tới bên nhận
rdt_rcv(): gọi khi gói tin đến phía
bên nhận
deliver_data(): được gọi bởi rdt
để truyền dữ liệu lên tầng trên
1-18
Truyền dữ liệu tin cậy
‰ Sử dụng máy trạng thái hữu hạn (FSM) để xử lý
bên nhận và bên gửi
state
1
state
2
Sự kiện gây ra chuyển trạng thái
Hành động khi chuyển trạng thái
state: khi trong 1 trạng
thái, trạng thái tiếp
theo là duy nhất đối
với 1 sự kiện
sự kiện
hành động
1-19
rdt1.0: Truyền tin cậy qua kênh tin cậy
‰ Tầng dưới là truyền tin cậy
 Không có lỗi bít
 Không mất gói tin
‰ FSM của bên gửi và bên nhận:
 Bên gửi chuyển dữ liệu xuống kênh phía dưới
 Bên nhận đọc dữ liệu từ kênh bên dưới
Đợi cuộc
gọi từ
phía trên packet = make_pkt(data)
udt_send(packet)
rdt_send(data)
extract (packet,data)
deliver_data(data)
đợi cuộc
gọi từ
phía dưới
rdt_rcv(packet)
Bên gửi Bên nhận
1-20
Rdt2.0: kênh có lỗi bít
‰ Kênh phía dưới có thể có lỗi
 checksum để phát hiện lỗi
‰ Cách khôi phục lỗi
 Báo nhận (ACK): bên nhận chỉ rõ cho bên gửi gói tin nhận
thành công
 Báo lỗi (NAK): bên nhận chỉ rõ cho bên gửi gói tin có lỗi
 Bên nhận truyền lại gói tin nếu nhận NAK
‰ Cơ chế rdt2.0:
 Phát hiện lỗi
 Phản hồi cho bên nhận: bản tin điều khiển (ACK, NAK: bên
nhận -> bên gửi)
1-21
rdt2.0: Máy trạng thái
Đợi cuộc
gọi từ trên
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
rdt_rcv(rcvpkt) && 
notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
udt_send(NAK)
rdt_rcv(rcvpkt) && 
corrupt(rcvpkt)
Đợi ACK 
hoặc
NAK
Đợi cuộc
gọi từ phía
dướiBên gửi
Bên nhận
rdt_send(data)
1-22
rdt2.0: Trường hợp không lỗi
đợi cuộc
gọi từ phía
trên
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
rdt_rcv(rcvpkt) && 
notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
udt_send(NAK)
rdt_rcv(rcvpkt) && 
corrupt(rcvpkt)
đợi ACK 
hoặc
NAK
đợi cuộc
gọi từ phía
dưới
rdt_send(data)
Λ
1-23
rdt2.0: Trường hợp có lỗi
đợi cuộc
gọi từ phía
trên
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
rdt_rcv(rcvpkt) && 
notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && isACK(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
udt_send(NAK)
rdt_rcv(rcvpkt) && 
corrupt(rcvpkt)
đợi ACK 
hoặc
NAK
đợi cuộc
gọi từ phía
dưới
rdt_send(data)
Λ
1-24
rdt2.1: Bên gửi, điều khiển ACK/NAK lỗi
đợi cuộc
gọi 0 từ
trên
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_send(data)
đợi ACK 
hoặc NAK 
0 udt_send(sndpkt)
rdt_rcv(rcvpkt) && 
( corrupt(rcvpkt) ||
isNAK(rcvpkt) )
sndpkt = make_pkt(1, data, checksum)
udt_send(sndpkt)
rdt_send(data)
rdt_rcv(rcvpkt) 
&& notcorrupt(rcvpkt) 
&& isACK(rcvpkt) 
udt_send(sndpkt)
rdt_rcv(rcvpkt) && 
( corrupt(rcvpkt) ||
isNAK(rcvpkt) )
rdt_rcv(rcvpkt) 
&& notcorrupt(rcvpkt) 
&& isACK(rcvpkt)
đợi cuộc
gọi 1 từ
trên
đợi ACK 
hoặc NAK 
1
Λ
1-25
rdt2.1: Bên nhận, điều khiển ACK/NAK lỗi
đợi 0 
từ dưới
sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && 
not corrupt(rcvpkt) &&
has_seq0(rcvpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) 
&& has_seq1(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
đợi 1 
từ dưới
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) 
&& has_seq0(rcvpkt) 
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && 
not corrupt(rcvpkt) &&
has_seq1(rcvpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt)
1-26
rdt2.1
Bên gửi:
‰ seq # được thêm vào
gói tin
‰ Hai seq. #’s (0,1)
‰ Phải kiểm tra nếu
ACK/NAK đã nhận có
lỗi
‰ Hai lần -> ổn định
Bên nhận:
‰ Phải kiểm tra gói tin đã
nhận có lặp không
 Trạng thái chỉ định pkt
seq # mong đợi là 0 hay 
1
1-27
rdt2.2: Giao thức NAK-free
‰ Tương tự rdt2.1, chỉ sử dụng ACK
‰ Thay vì NAK, bên nhận phải gửi ACK cho pkt cuối đã
nhận OK
‰ ACK lặp tại bên nhận sẽ như xử lý như nhận NAK: 
truyền lại pkt hiện tại
1-28
rdt2.2: Phân mảnh tại bên gửi và bên nhận
đợi cuộc
gọi 0 từ
trên
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_send(data)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && 
( corrupt(rcvpkt) ||
isACK(rcvpkt,1) )
rdt_rcv(rcvpkt) 
&& notcorrupt(rcvpkt) 
&& isACK(rcvpkt,0)
đợi ACK
0
FSM bên gửi
đợi 0 
từ dưới
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) 
&& has_seq1(rcvpkt) 
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK1, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && 
(corrupt(rcvpkt) ||
has_seq1(rcvpkt))
udt_send(sndpkt)
FSM bên nhận
L
1-29
rdt3.0: kênh có lỗi và mất gói
Giả sử: kênh phía dưới có
thể mất gói (dữ liệu
hoặc ACK)
 checksum, seq. #, ACK, 
truyền lại là không đủ
Cách tiếp cận: bên nhận đợi
ACK một thời gian
‰ Truyền lại nếu không có ACK 
nhận tại thời điểm này
‰ Nếu gói tin (hoặc ACK) trễ
(không mất):
 Truyền lại -> lặp, sử dụng
seq# để giải quyết
 Bên nhận phải gán seq # 
của gói tin được ACK
‰ Đòi hỏi bộ đếm thời gian
ngược
1-30
rdt3.0 Bên gửi
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
start_timer
rdt_send(data)
đợi
ACK 0
rdt_rcv(rcvpkt) && 
( corrupt(rcvpkt) ||
isACK(rcvpkt,1) )
đợi cuộc gọi
1 từ trên
sndpkt = make_pkt(1, data, checksum)
udt_send(sndpkt)
start_timer
rdt_send(data)
rdt_rcv(rcvpkt) 
&& notcorrupt(rcvpkt) 
&& isACK(rcvpkt,0)
rdt_rcv(rcvpkt) && 
( corrupt(rcvpkt) ||
isACK(rcvpkt,0) )
rdt_rcv(rcvpkt) 
&& notcorrupt(rcvpkt) 
&& isACK(rcvpkt,1)
stop_timer
stop_timer
udt_send(sndpkt)
start_timer
timeout
udt_send(sndpkt)
start_timer
timeout
rdt_rcv(rcvpkt)
đợi cuộc gọi 
0 từ trên
đợi
ACK 1
Λ
rdt_rcv(rcvpkt)
Λ
Λ
Λ
1-31
rdt3.0
(a) Không mất gói (b) Mất gói
1-32
rdt3.0
(c) Mất ACK (c) Timeout
1-33
Hiệu năng của rdt3.0
‰ Hiệu năng của rdt3.0 bị ảnh hưởng
‰ Ví dụ: đường truyền 1 Gbps, lan truyền 15 ms, gói tin 1KB:
T transmit =
8kb/pkt
10**9 b/sec = 8 microsec
 U sender: sự sử dụng – thời gian bên gửi bận gửi
 1KB pkt trong mỗi 30 msec -> 33kB/sec thông lượng qua đường
truyền 1 Gbps
 Giao thức mạng hạn chế sử dụng tài nguyên vật lý!
U 
sender = 
.008
30.008 
= 0.00027 L / R 
RTT + L / R 
=
L (độ dài gói tin, bit)
R (tốc độ truyền, bps) =
1-34
rdt3.0: Hoạt động stop-and-wait 
gói tin đầu tiên được truyền, t = 0
Bên gửi Bên nhận
RTT
gói tin cuối cùng truyền, t = L / R
bít của gói tin đầu tiên đến
bít của gói tin cuối cùng đến, 
gửi ACK
ACK đến, gửi gói tin tiếp, 
t = RTT + L / R
U 
sender =
.008 
30.008 
= 0.00027 L / R 
RTT + L / R 
=
1-35
Các giao thức Pipeline
Pipeline: Bên gửi cho phép nhiều, tới các gói tin được
ack
 Dải giá trị sequence phải tăng
 Vùng đệm tại bên gửi và bên nhận
‰ Hai hình thức chung của các giao thức pipeline: go-
Back-N, selective repeat
1-36
Pipelining: Tăng hiệu quả sử dụng
Bít gói tin đầu tiên được truyền, 
t = 0
Bên gửi Bên nhận
RTT 
Bít cuối cùng được truyền
t = L / R
Bít gói tin đầu tiên đến
Bít gói tin cuối cùng đến, gửi ACK
ACK đến, gửi gói tin tiếp theo,
t = RTT + L / R
Bít cuối cùng của gói tin thứ 2 đến, gửi
ACK
Bít cuối cùng của gói tin 3 đến, gửi ACK
U 
sender =
.024
30.008 
= 0.0008 3 * L / R 
RTT + L / R 
=
Tăng hiệu quả sử
dụng lên 3 lần
1-37
Go-Back-N
Bên gửi:
‰ k-bit seq # trong pkt header
‰ “window” N, cho phép các gói tin không ack liên tiếp
‰ ACK(n): ACK mọi gói tin tới seq # n - “ACK tích lũy”
 Có thể nhầm ACK lặp
‰ Thời gian cho mỗi gói tin
‰ timeout(n): truyền lại gói tin n và tất cả gói tin seq# lớn hơn n trong
cửa sổ
‰ Lý do phải giới hạn N: điều khiển luồng, điều khiển tắc nghẽn
1-38
GBN: FSM mở rộng của bên gửi
đợi start_timerudt_send(sndpkt[base])
udt_send(sndpkt[base+1])
udt_send(sndpkt[nextseqnum-1])
timeout
rdt_send(data)
if (nextseqnum < base+N) {
sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum)
udt_send(sndpkt[nextseqnum])
if (base == nextseqnum) /* pkt chưa được ack đầu tiên */
start_timer
nextseqnum++
}
else
refuse_data(data)
base = getacknum(rcvpkt)+ ... 
hướng kết nối: UDP
‰ 3.4 Các nguyên tắc của
truyền dữ liệu tin cậy
‰ 3.5 Dịch vụ hướng kết
nối: TCP
 Cấu trúc segment
 Truyền dữ liệu tin cậy
 Điều khiển luồng
 Quản lý kết nối
‰ 3.6 Các nguyên tắc của
điều khiển tắc nghẽn
‰ 3.7 Điều khiển tắc nghẽn
của TCP
1-65
Quản lý kết nối của TCP
Thiết lập kết nối:
Nhắc lại: Bên gửi, bên nhận
của TCP thiết lập kết nối
trước khi trao đổi dữ liệu
‰ Khởi tạo giá trị:
 seq. #
 buffer, thông tin điều
khiển luồng (ví dụ: 
RcvWindow)
‰ Client: khởi tạo kết nối
Socket clientSocket = new 
Socket("hostname","port 
number");
‰ Server: liên lạc bởi client
Socket connectionSocket = 
welcomeSocket.accept();
Bắt tay 3 đường:
Bước 1: Client gửi TCP SYN 
segment tới server
 Chỉ định seq # ban đầu
 Không có dữ liệu
Bước 2: Server nhận SYN, trả lời
với SYNACK segment
 Server cấp phát buffer
 Server khởi tạo seq. #
Bước 3: Client nhận SYNACK, trả
lời bằng ACK segment, có thể
chứa dữ liệu
1-66
Quản lý kết nối của TCP
Thiết lập kết nối:
client
Connection request (SYN=1, seq=client_isn)
server
C o n n e
c t i o n g
r a n t e d
 ( S Y N
= 1 , s e
q = s e r
v e r _ i s
n , 
a c k = c
l i e n t _ i
s n + 1
ack (SYN=0, seq=client_isn+1, 
ack=server_isn+1
1-67
Quản lý kết nối của TCP
Đóng kết nối:
client đóng socket:
clientSocket.close();
Bước 1: client gửi TCP FIN 
tới server
Bước 2: server nhận FIN, trả
lời bằng ACK. Đóng kết nối, 
gửi FIN 
client
FIN
server
A C K
ACK
F I N
đóng
đóng
đóng
t
h
ờ
i
g
i
a
n
đ
ơ
ị
1-68
Quản lý kết nối của TCP
Bước 3: client nhận FIN, trả
lời bằng ACK. 
 Thời gian đợi: trả lời
bằng ACK báo đã nhận
FIN
Bước 4: server, nhận ACK. 
Kết nối đóng. 
client
FIN
server
A C K
ACK
F I N
đang
đóng
đang
đóng
đóng
t
h
ờ
i
g
i
a
n
đ
ợ
i
đã đóng
1-69
Quản lý kết nối của TCP
Chu kỳ hoạt động
TCP client
Chu kỳ hoạt động
TCP server
1-70
Chương 3: Tầng giao vận
‰ 3.1 Các dịch vụ tầng
giao vận
‰ 3.2 Multiplexing và
demultiplexing
‰ 3.3 Dịch vụ không
hướng kết nối: UDP
‰ 3.4 Các nguyên tắc của
truyền dữ liệu tin cậy
‰ 3.5 Dịch vụ hướng kết
nối: TCP
 Cấu trúc segment
 Truyền dữ liệu tin cậy
 Điều khiển luồng
 Quản lý kết nối
‰ 3.6 Các nguyên tắc của
điều khiển tắc nghẽn
‰ 3.7 Điều khiển tắc nghẽn
của TCP
1-71
Nguyên tắc điều khiển tắc nghẽn
Tắc nghẽn:
‰ Quá nhiều nguồn gửi quá nhiều dữ liệu nhanh quá
khả năng điều khiển của mạng
‰ Khác điều khiển luồng
‰ Đặc điểm:
Mất gói tin (tràn buffer tại router)
 Độ trễ tăng (xếp hàng tại buffer của router)
1-72
Nguyên nhân, tác hại của tắc nghẽn: 
Kịch bản 1
‰ Hai đối tượng gửi, 
hai đối tượng nhận
‰ Một router, vùng
đệm không giới
hạn
‰ Không truyền lại
‰ Độ trễ lớn khi
xảy ra tắc nghẽn
‰ Tối đa thông
lượng có thể đạt
được
unlimited shared 
output link buffers
Host A
lin : original data
Host B
lout
1-73
Nguyên nhân, tác hại của tắc nghẽn: 
Kịch bản 2
‰ Một router, vùng đệm giới hạn
‰ Bên gửi truyền lại gói tin mất
vùng đệm của đường
truyền đầu ra dùng
chung và có giới hạn
Host A lin : dữ liệu ban đầu
Host B
lout
l'in : dữ liệu ban đầu, dữ liệu
truyền lại
1-74
Nguyên nhân, tác hại của tắc nghẽn: 
Kịch bản 2
‰ Luôn luôn: (tốt)
‰ Truyền lại “hoàn hảo”: truyền lại chỉ khi mất
‰ Sự truyền lại của gói tin bị trễ (không mất) làm lớn hơn (trường
hợp hoàn hảo) so với
λ
in
λout= λ
in
λout>λ
inλout
“Tác hại” của tắc nghẽn:
‰ Xử lý nhiều hơn (truyền lại)
‰ Truyền lại không cần thiết: đường truyền mang nhiều bản sao chép
của gói tin
R/2
R/2λin
λ
o
u
t
b.
R/2
R/2λin
λ
o
u
t
a.
R/2
R/2λin
λ
o
u
t
c.
R/4
R/3
1-75
Nguyên nhân, tác hại của tắc nghẽn: 
Kịch bản 3
‰ Bốn đối tượng gửi
‰ Nhiều đường
‰ timeout/truyền lại
λ
in
Q: Điều gì xảy ra khi
và tăng?λ
in
vùng đệm của đường
truyền ra dùng chung
và có giới hạn
Host A
λin : dữ liệu ban đầu
Host B
λoutλ'in : dữ liệu ban đầu, và
dữ liệu truyền lại
1-76
Nguyên nhân, tác hại của tắc nghẽn: 
Kịch bản 3
Tác hại khác của tắc nghẽn:
‰ Khi gói tin bị loại bỏ, khả năng truyền đường lên sử
dụng cho gói tin đó đã lãng phí
H
o
s
t 
A
H
o
s
t 
B
λ
o
u
t
1-77
Các cách tiếp cận
để điều khiển tắc nghẽn
Điều khiển tắc nghẽn
cuối-cuối:
‰ Không có phản hồi chính
thức từ mạng
‰ Tắc nghẽn suy ra từ hệ
thống cuối theo dõi mất gói
và độ trễ
‰ Cách tiếp cận sử dụng bởi
TCP
Điều khiển tắc nghẽn với
sự giúp đỡ của mạng:
‰ Router cung cấp phản hồi tới
hệ thống cuối
 Một bít chỉ ra tắc nghẽn
(SNA, DECbit, TCP/IP, 
ECN, ATM)
 Chỉ rõ tốc độ bên gửi nên
gửi
Hai cách tiếp cận chính để điều khiển tắc nghẽn:
1-78
Trường hợp nghiên cứu: 
Điều khiển tắc nghẽn ATM ABR 
ABR: Available Bit Rate:
‰ “Dịch vụ co dãn”
‰ Nếu đường đi của bên gửi
chưa đến giới hạn tải: 
 Bên gửi nên sử dụng
băng thông khả dụng
‰ Nếu đường đi của bên gửi
bị tắc nghẽn: 
 Bên gửi điều chỉnh tốc
độ đảm bảo tối thiểu
RM cell (Resource 
Management):
‰ Được gửi bởi bên gửi, rải rác
cùng với cell dữ liệu
‰ Các bít trong RM cell do switch 
thiết lập (có sự tham gia của
mạng)
 NI bit: không tăng tốc độ (tắc
nghẽn nhẹ)
 CI bit: tắc nghẽn
‰ RM cell trả về cho bên gửi bởi
bên nhận với các bít không thay
đổi
1-79
Trường hợp nghiên cứu: 
Điều khiển tắc nghẽn ATM ABR 
‰ Hai byte ER (Explicit Rate) trong RM cell
 Switch tắc nghẽn có thể giảm giá trị ER trong cell
 Vì vậy, tốc độ gửi của bên gửi tối thiểu tốc độ hỗ trợ trên đường
‰ Bít EFCI trong cell dữ liệu: đặt bằng 1 trong switch bị tắc nghẽn
 Nếu cell dữ liệu, trước cell RM, có EFCI thiết lập, bên gửi thiết lập bít
CI trong cell RM trả về
1-80
Chương 3: Tầng giao vận
‰ 3.1 Các dịch vụ tầng
giao vận
‰ 3.2 Multiplexing và
demultiplexing
‰ 3.3 Dịch vụ không
hướng kết nối: UDP
‰ 3.4 Các nguyên tắc của
truyền dữ liệu tin cậy
‰ 3.5 Dịch vụ hướng kết
nối: TCP
 Cấu trúc segment
 Truyền dữ liệu tin cậy
 Điều khiển luồng
 Quản lý kết nối
‰ 3.6 Các nguyên tắc của
điều khiển tắc nghẽn
‰ 3.7 Điều khiển tắc nghẽn
của TCP
1-81
Điều khiển tắc nghẽn của TCP 
‰ Điều khiển end-end (không có hỗ trợ
của mạng)
‰ Bên gửi giới hạn truyền:
LastByteSent-LastByteAcked
≤ CongWin
LastByteSent - LastByteAcked <= min{CongWin, 
RcvWin}
‰ Gần đúng,
‰ CongWin thay đổi động, chức năng
nhận biết sự tắc nghẽn của mạng
Cách bên gửi nhận biết sự tắc
nghẽn?
‰ Sự kiện mất gói = timeout 
hoặc lặp lại 3 ack
‰ Bên gửi TCP giảm tốc độ
(CongWin) sau sự kiện mất
gói
Ba cơ chế:
 AIMD
 slow start
 Không thay đổi sau sự kiện
timeout
rate = CongWin
RTT Bytes/sec
1-82
TCP AIMD
8 Kbytes
16 Kbytes
24 Kbytes
time
congestion
window
Giảm cấp số nhân: Giảm
CongWin một nửa sau
sự kiện mất gói
Tăng cấp số cộng: Tăng
CongWin 1 MSS mỗi
RTT khi không có sự
kiện mất gói
Kết nối TCP trong thời gian dài
1-83
TCP Slow Start
‰ Khi kết nối bắt đầu, 
CongWin = 1 MSS
 Ví dụ: MSS = 500 byte & 
RTT = 200 msec
 Tốc độ ban đầu = 20 kbps
‰ Băng thông khả dụng có
thể >> MSS/RTT
 Mong muốn nhanh tới tốc
độ đáng kể
‰ Khi kết nối bắt đầu, tăng
tốc độ nhanh theo hàm
mũ cho đến khi có sự
kiện mất gói đầu tiên
1-84
TCP Slow Start (tiếp)
‰ Khi kết nối bắt đầu, 
tăng tốc độ hàm mũ tới
khi có sự kiện mất gói
đầu tiên:
 Gấp đôi CongWin mỗi
RTT
 Thự hiện bằng cách tăng
CongWin cho mọi ACK 
nhận được
‰ Tóm lại: tốc độ ban đầu
là chậm nhưng nhanh
chóng tăng theo hàm
mũ
Host A
1 segment
R
T
T
Host B
time
2 segments
4 segments
1-85
Quá trình tinh chỉnh
‰ Sau 3 ACK lặp lại:
 CongWin giảm một nửa
 window tăng tuyến tính
‰ Nhưng sau sự kiện timeout:
 CongWin thay vì thiết
lập 1 MSS; 
 window tăng hàm mũ
 Tới ngưỡng thì giảm
tuyến tính
• 3 ACK lặp chỉ rằng khả
năng của mạng chuyển
một số segment
• timeout trước 3 ACK lặp
là đáng chú ý hơn
Triết lý:
1-86
Quá trình tinh chỉnh (tiếp)
Q: Khi nào tăng theo
số mũ chuyển thành
theo tuyến tính? 
A: Khi CongWin có giá
trị bằng 1/2 giá trị
của nó trước khi
timeout.
Thực hiện:
‰ Variable Threshold 
‰ Tại sự kiện mất gói, 
Threshold đặt bằng ½
CongWin ngay trước sự kiện
mất gói
1-87
Tổng kết: Điều khiển tắc nghẽn của TCP 
‰ Khi CongWin nhỏ hơn Threshold, bên gửi trong
pha slow-start, window lớn theo hàm mũ.
‰ Khi CongWin lớn hơn Threshold, bên gửi trong
pha congestion-avoidance, window lớn theo hàm
tuyến tính.
‰ Khi xảy ra lặp 3 ACK, Threshold đặt bằng
CongWin/2 và CongWin đặt bằng Threshold.
‰ Khi timeout xảy ra, Threshold đặt bằng
CongWin/2 và CongWin đặt bằng 1 MSS.
1-88
Điều khiển tắc nghẽn bên gửi của TCP
Sự kiện Trạng thái Hành động bên gửi TCP Giải thích
Nhận ACK 
cho dữ liệu
không được
ack trước đó
Slow Start 
(SS)
CongWin = CongWin + MSS, 
If (CongWin > Threshold)
Đặt trạng thái thành
“Congestion Avoidance”
Kết quả bởi gấp đôi CongWin
mỗi RTT
Nhận ACK 
cho dữ liệu
không được
ack trước đó
Congestion
Avoidance 
(CA) 
CongWin = CongWin+MSS * 
(MSS/CongWin)
Tăng theo cấp số cộng, tăng
CongWin lên 1 MSS mỗi RTT
Sự kiện mất
gói phát hiện
bởi 3 ACK lặp
SS hoặc CA Threshold = CongWin/2, 
CongWin = Threshold,
Đặt trạng thái thành “Congestion 
Avoidance”
Nhanh chóng phục hồi, thực
hiện tăng cấp số nhân. 
CongWin sẽ không giảm dưới
1 MSS.
Timeout SS hoặc CA Threshold = CongWin/2, 
CongWin = 1 MSS,
Đặt trạng thái thành “Slow Start”
Vào slow start
ACK lặp SS hoặc CA Tăng bộ đếm ACK lặp cho
segment được ack
CongWin và Threshold không
thay đổi
1-89
Thông lượng của TCP
‰ Thông lượng trung bình của TCP từ chức
năng của window size và RTT?
 Bỏ qua slow start
‰Cho W là window size khi xảy ra mất gói.
‰ Khi window là W, thông lượng là W/RTT
‰Ngay sau mất gói, window giảm tới W/2, 
thông lượng W/2RTT. 
‰ Thông lượng trung bình: .75 W/RTT
1-90
Tương lai của TCP
‰ Ví dụ: 1500 byte segment, 100ms RTT, muốn 10 
Gbps thông lượng
‰ Đòi hỏi window size W = 83,333 segment
‰ Thông lượng theo tốc độ mất gói:
‰ ➜ L = 2·10-10 
‰ Phiên bản mới của TCP cho tốc độ cao là cần thiết!
LRTT
MSS⋅22.1
1-91
‰ Mục đích của sự công bằng: Nếu K phiên TCP dùng 
chung đường truyền thắt nút băng thông R, mỗi 
đường nên có tốc độ trung bình là R/K
Kết nối TCP 1
điểm thắt nút
khả năng RKếtnối TCP 2
Sự công bằng của TCP
1-92
Lý do TCP công bằng
Hai phiên cạnh tranh:
R
R
Chia sẻ băng thông bằng nhau
Thông lượng của kết nối 1
T h
ô n
g
l ư
ợ
n g
c ủ
a
k ế
t n
ố i
2
tránh tắc nghẽn: tăng cộng
mất gói: giảm window hệ số 2
1-93
Sự công bằng (tiếp)
Sự công bằng và UDP
‰ Các ứng dụng đa
phương tiện thường
không sử dụng TCP
 Không muốn tốc độ giảm
bởi điều khiển tắc nghẽn
‰ Ứng dụng sử dụng
UDP:
 Đẩy dữ liệu audio/video 
ở tốc độ hằng số, chấp
nhận mất gói
Sự công bằng và các kết nối
TCP song song
‰ Không ngăn chặn ứng dụng
mở song song các kết nối
giữa 2 host
‰ Trình duyệt Web thực hiện
như trên
1-94
Mô hình độ trễ
Q: Thời gian để nhận một đối
tượng từWeb server sau
khi gửi một yêu cầu? 
Bỏ qua tắc nghẽn, độ trễ ảnh
hưởng bởi:
‰ Thiết lập kết nối TCP
‰ Độ trễ truyền dữ liệu
Giả sử một đường truyền giữa
client và server có tốc độ R
‰ S: MSS (bits)
‰ O: kích thước đối tượng (bit)
‰ Không truyền lại (không mất
gói, không lỗi)
Kích thước cửa sổ:
‰ Cửa sổ tắc nghẽn cố định, 
W segment
‰ Cửa số động, mô hình slow 
start
1-95
Cửa sổ tắc nghẽn cố định
Trường hợp 1:
WS/R > RTT + S/R: ACK 
cho segment đầu tiên
trong cửa sổ
Độ trễ = 2RTT + O/R
1-96
Cửa sổ tắc nghẽn cố định
Trường hợp 2:
‰ WS/R < RTT + S/R: đợi
ACK sau khi gửi lượng dữ
liệu của cửa sổ
Độ trễ = 2RTT + O/R
+ (K-1)[S/R + RTT - WS/R]
1-97
Mô hình độ trễ TCP: Slow Start (1)
Giả sử cửa sổ lớn theo slow start
Độ trễ cho một đối tượng là:
R
S
R
SRTTP
R
ORTTLatency P )12(2 −−⎥⎦
⎤⎢⎣
⎡ +++=
Trong đó, P là lượng thời gian TCP rỗi tại server
}1,{min −= KQP
- Trong đó, Q là lượng thời gian server rỗi nếu đối tượng kích thước
không giới hạn.
- Và K là số cửa sổ trùm qua đối tượng
1-98
Mô hình độ trễ TCP: Slow Start (2)
RTT
initiate TCP
connection
request
object
first window
= S/R
second window
= 2S/R
third window
= 4S/R
fourth window
= 8S/R
complete
transmissionobject
delivered
time at
client
time at
server
Ví dụ:
• O/S = 15 segment
• K = 4 windows
• Q = 2
• P = min{K-1,Q} = 2
Thời gian rỗi của server 
P=2 times
Các thành phần trễ:
• 2 RTT để thiết lập kết
nối và yêu cầu
• O/R để truyền đối
tượng
• thời gian server rỗi vì
slow start
Server rỗi: 
P = min{K-1,Q} times
1-99
Mô hình độ trễ TCP (3)
R
S
R
SRTTPRTT
R
O
R
SRTT
R
SRTT
R
O
idleTimeRTT
R
O
P
k
P
k
P
p
p
)12(][2
]2[2
2delay
1
1
1
−−+++=
−+++=
++=
−
=
=
∑
∑
 2 1
R
SRTT
R
S k =⎥⎦
⎤⎢⎣
⎡ −+
+
−
=+ RTT
R
S
2 1 =−
R
Sk
RTT
initiate TCP
connection
request
object
first window
= S/R
second window
= 2S/R
third window
= 4S/R
fourth window
= 8S/R
complete
transmissionobject
delivered
time at
client
time at
server
thời gian khi server bắt đầu
gửi segment tới khi server 
nhận ack segment
thời gian để truyền cửa sổ
thứ k
thời gian rỗi sau
cửa sổ thứ k
1-
100
Mô hình độ trễ TCP (4)
⎥⎥
⎤⎢⎢
⎡ +=
+≥=
≥−=
≥+++=
≥+++=
−
−
)1(log
)}1(log:{min
}12:{min
}/222:{min
}222:{min
2
2
110
110
S
O
S
Okk
S
Ok
SOk
OSSSkK
k
k
k
L
L
Tính Q, giá trị rỗi cho đối tượng có kích thước không giới hạn tương tự.
K = số cửa sổ bao đối tượng
Cách tính K?
1-
101
Mô hình hóa HTTP
‰ Giả sử trang Web chứa:
 1 trang HTML cơ sở (kích thước O bít)
 M ảnh (mỗi ảnh kích thước O bít)
‰ Non-persistent HTTP: 
 M+1 kết nối TCP
 Response time = (M+1)O/R + (M+1)2RTT + tổng thời gian rỗi
‰ Persistent HTTP:
 2 RTT để yêu cầu và nhận file HTML cơ sở
 1 RTT để yêu cầu và nhận M ảnh
 Response time = (M+1)O/R + 3RTT + tổng thời gian rỗi
‰ Non-persistent HTTP với X kết nối song song
 Giả sử M/X nguyên
 1 kết nối TCP cho file cơ sở
 M/X tập của các kết nối song song cho ảnh
 Response time = (M+1)O/R + (M/X + 1)2RTT + tổng thời gian rỗi
1-
102
0
2
4
6
8
10
12
14
16
18
20
28
Kbps
100
Kbps
1 Mbps 10
Mbps
non-persistent
persistent
parallel non-
persistent
Thời gian trả lời HTTP (giây)
RTT = 100 msec, O = 5 Kbytes M=10 và X=5
Đối với băng thông thấp, thời gian kết nối và thời gian phản hồi chi phối bởi
thời gian truyền
Persistent connection chỉ mang lại cải tiến thêm qua các kết nối song song
1-
103
0
10
20
30
40
50
60
70
28
Kbps
100
Kbps
1 Mbps 10
Mbps
non-persistent
persistent
parallel non-
persistent
Thời gian phản hồi (giây)
RTT =1 sec, O = 5 Kbyte, M=10 and X=5
Đối với RTT lớn, thời gian phản hồi chi phối bởi thiết lập kết nối TCP và độ trễ
slow start. Persistent connection đem lại cải tiến quan trọng: đặc biệt trong mạng
delay, bandwidth cao.
1-
104
Chương 3: Tổng kết
‰ Các nguyên tắc bên trong
các dịch vụ tầng giao vận:
multiplexing, 
demultiplexing
 Truyền dữ liệu tin cậy
 Điều khiển luồng
 Điều khiển tắc nghẽn
‰ Sự thực hiện trong Internet
 UDP
 TCP
Tiếp theo:
‰ Dừng tìm hiểu phần bên
ngoài của mạng (tầng
ứng dụng, tầng giao
vận)
‰ Tìm hiểu vào trong lõi
của mạng