Chapter 3 v8.2

Chương 3
Lớp vận chuyển

Lưu ý khi sử dụng các slide PowerPoint này:
Chúng tôi đang cung cấp miễn phí những slide này cho tất cả mọi người
(giảng viên, sinh viên, độc giả). Chúng ở dạng PowerPoint nên bạn có
thể nhìn thấy các hình ảnh động; và có thể thêm, sửa đổi, xóa các slide
(bao gồm cả slide này) và nội dung slide phù hợp với nhu cầu của bạn.
Họ rõ ràng đại diện cho rất nhiều công việc từ phía chúng tôi. Đổi lại
việc sử dụng, chúng tôi chỉ yêu cầu như sau:
 Nếu bạn sử dụng các slide này (ví dụ: trong lớp học) mà bạn đề cập
đến nguồn của chúng (xét cho cùng, chúng tôi muốn mọi người sử
dụng sách của chúng tôi!)
 Nếu bạn đăng bất kỳ trang trình bày nào lên trang web www, bạn
phải lưu ý rằng chúng được phỏng theo (hoặc có thể giống hệt) các
trang trình bày của chúng tôi và lưu ý bản quyền của chúng tôi đối
Mạng máy tính: Cách tiếp
với tài liệu này. cận từ trên xuống
Để biết lịch sử sửa đổi, hãy xem ghi chú slide cho trang này. Phiên bản
thứ
8 Jim Kurose, Keith Ross
Cảm ơn và tận hưởng! JFK/KWR Pearson, 2020
Tất cả bản quyền tài liệu 1996-2023 Lớp vận chuyển: 3-1
Lớp vận chuyển: tổng quan
Mục tiêu của chúng tôi:
 hiểu các nguyên tắc đằng  tìm hiểu về các giao thức lớp
sau các dịch vụ của lớp truyền tải Internet:
vận chuyển: • UDP: vận chuyển không kết nối
• ghép kênh, phân kênh • TCP: truyền tải đáng tin cậy hướng
• truyền dữ liệu đáng tin cậy kết nối
• Kiểm soát lưu lượng • Kiểm soát tắc nghẽn TCP
• điều khiển tắc nghẽn
Lớp vận chuyển: 3-2

Lớp vận chuyển: lộ trình
 Dịch vụ tầng vận chuyển
 Ghép kênh và phân kênh
 Vận chuyển không kết nối: UDP
 Nguyên tắc truyền dữ liệu đáng tin
cậy
 Vận chuyển hướng kết nối: TCP
 Nguyên tắc kiểm soát tắc nghẽn
 Kiểm soát tắc nghẽn TCP
 Sự phát triển của chức năng tầng
vận chuyển
Dịch vụ và giao thức vận chuyển
ứng dụng
chuyên
 cung cấp giao tiếp logic giữa các tiến mạng điện thoại
chở
mạngdi động
Liên kết dữ
trình ứng dụng chạy trên các máy liệu

thuộc vật
ISP quốc gia hoặc toàn cầu
vận
chủ khác nhau
chất
chu
 Các hành động của giao thức vận
yển
chuyển trong hệ thống cuối:
đ ầu
ISP địa
cuố
• người gửi: chia tin nhắn ứng dụng thành phương
i
hoặc khu
các phân đoạn , chuyển đến lớp mạng
hợ
vực
p lý
mạng trong nhà nội dung
• người nhận: tập hợp lại các phân đoạn các nhà cung cấp
thành tin nhắn, chuyển đến lớp ứng dụng mạng trung tâm dữ liệu
ứng dụng
mạng
chuyên
chở
 hai giao thức truyền tải có sẵn cho mạng

Liên kết dữ
các ứng dụng Internet

liệu
thuộc vật
doanh nghiệp chất
mạng
• TCP, UDP
Các dịch vụ và giao thức của lớp vận chuyển so với lớp mạng
sự tương tự của hộ gia đình:

12 đứa trẻ nhà Ann gửi thư cho
12 đứa trẻ nhà Bill:
 chủ nhà = nhà
 quy trình = trẻ em
 tin nhắn ứng dụng = thư trong
phong bì
 giao thức vận chuyển = Ann và Bill
chuyển sang anh chị em nội bộ
 giao thức lớp mạng = dịch vụ bưu
chính

Các dịch vụ và giao thức của lớp vận chuyển so với lớp mạng
sự tương tự của hộ gia đình:

 lớp vận chuyển : giao tiếp
giữa các tiến trình 12 đứa trẻ nhà Ann gửi thư cho
12 đứa trẻ nhà Bill:
• dựa vào, tăng cường, các dịch
 chủ nhà = nhà
vụ lớp mạng
 quy trình = trẻ em
 tin nhắn ứng dụng = thư trong
phong bì
 lớp mạng: giao tiếp giữa các
 giao thức vận chuyển = Ann và Bill
máy chủ chuyển sang anh chị em nội bộ
 giao thức lớp mạng = dịch vụ bưu
chính

Hành động của lớp vận chuyển
Người gửi:
ứng dụng  được truyền một thông ứngứng dụng.
dụng
báo lớp ứng dụng tin nhắn
chuyên chở
 xác định giá trị trường tiêu Quần ứng dụng.
Quầnchuyên
què
què
đề phân đoạn tin

chởnhắn
mạng (IP)
 tạo phân đoạn mạng (IP)
liên kết
 chuyển phân đoạn tới IP liên kết
thuộc vật chất thuộc vật

chất

Hành động của lớp vận chuyển
Người nhận:
ứng dụng  nhận phân đoạn từ IP ứng dụng
 kiểm tra giá trị tiêu đề
ứng dụng.
chuyên chở  trích xuất thông báo lớp chuyên
tin nhắn ứng dụng chở
mạng (IP)  phân kênh tin nhắn tới ứng mạng (IP)
liên kết dụng thông qua socket liên kết

Quần ứng dụng.
què
chất
tin nhắn

Hai giao thức truyền tải Internet chính
ứng dụng
chuyên
 TCP: Giao thức điều khiển truyền dẫn mạng điện thoại
chở
mạngdi động
Liên kết dữ
• giao hàng đúng hẹn, đáng tin cậy liệu
thuộc vật
ISP quốc gia hoặc toàn cầu
vận
chất
chu
• Kiểm soát lưu lượng
yển
• kết nối cập nhật
đ ầu
 UDP: Giao thức gói dữ liệu người dùng ISP địa
cuố
phương
i
hoặc khu
• giao hàng không đáng tin cậy, không theo thứ
hợ
vực
p lý
mạng trong nhà nội dung
tự các nhà cung cấp
mạng
• tiện ích mở rộng dễ dàng của IP “nỗ lực tối đa” trung tâm dữ liệu
ứng dụng
mạng
chuyên
 dịch vụ không có sẵn: chở

mạng
Liên kết dữ
• đảm bảo sự chậm trễ liệu
thuộc vật
doanh nghiệp chất
• đảm bảo băng thông mạng

Chương 3: lộ trình
cậy
vận chuyển
Ghép kênh/phân kênh
ghép kênh với tư cách tách kênh như máy thu:
là
xửngười gửi:từ nhiều
lý dữ liệu sử dụng thông tin tiêu đề để phân phối
ổ cắm, thêm tiêu đề truyền tải (sau đã nhận được các phân đoạn để sửa
này được sử dụng để phân kênh) ổ cắm
ứng dụng
ứng dụng P1 P2 ứng dụng ổ cắm

P3 chuyên chở P4
quá trình
chuyên chở mạng chuyên chở
mạng liên kết mạng
liên kết thuộc vật chất liên kết
thuộc vật chất thuộc vật chất

máy chủ HTTP
khách hàng
ứng dụng ứng dụng
Thông
điệp
Ht
chuyên _ chở
Thông
HTTP
điệp
h nHtmạng
_ Thông
chuyên chở HTTP chuyên chở
điệp
h nHt mạng
_ Thông
liênHTTP
kết mạng
điệp thuộc vật chất
liên kết
HTTP liên kết
h nHt _ Thông
điệp
HTTP
Câu hỏi: Làm thế nào lớp vận chuyển biết gửi tin nhắn đến quy
trình trình duyệt Firefox thay vì quy trình Netflix hoặc quy trình
Skype?
khách hàng
Thông
Thông điệp
Ht
chuyên chở
_ Thông
điệp HTTP
điệp
HTTP
chuyên chở mạngHTTP chuyên chở

?
khử ghép kênh

ứng dụng
? chuyên chở
khử ghép kênh

Tách kênh
ghép kênh
ứng dụng
chuyên chở
ghép kênh
Ghép kênh
hoạt động như thế nào
 máy chủ nhận được gói dữ liệu 32 bit
IP cổng nguồn # cảng đích #
• mỗi datagram có địa chỉ IP
nguồn, địa chỉ IP đích các trường tiêu đề khác
• mỗi datagram mang một phân
đoạn lớp vận chuyển
ứng dụng
• mỗi đoạn có số cổng nguồn, cổng dữ liệu
đích (khối hàng)
 máy chủ sử dụng địa chỉ IP và
số cổng để hướng phân đoạn Định dạng phân đoạn TCP/UDP
đến ổ cắm thích hợp
Phân kênh không kết nối
Nhớ lại: khi máy chủ nhận được phân
 khi tạo ổ cắm, phải chỉ định đoạn UDP :
cổng cục bộ trên máy chủ #: • kiểm tra cổng đích # trong
phân đoạn
DatagramSocket mySocket1 =
DatagramSocket mới( 12534 ); • hướng phân đoạn UDP tới ổ
cắm có cổng đó #
 khi tạo datagram để gửi vào
socket UDP phải chỉ định
Các gói dữ liệu IP/UDP có cùng
• địa chỉ IP đích đích. # cổng, nhưng các địa chỉ IP
• cổng đích # nguồn và/hoặc số cổng nguồn
khác nhau sẽ được chuyển hướng
đến cùng một ổ cắm tại máy chủ
nhận Lớp vận chuyển: 3-23
Phân kênh không kết nối: một ví dụ
mySocket = ổ
cắm(AF_INET,SOCK_DGRAM)
mySocket.bind(myaddr, 6428 );
mySocket = ổ mySocket = ổ
cắm(AF_INET,SOCK_STREAM) cắm(AF_INET,SOCK_STREAM)
mySocket.bind(myaddr, 9157 ); mySocket.bind(myaddr, 5775 );
ứng dụng
ứng dụng P1 ứng dụng
P3 P4
chuyên chở
chuyên chở chuyên chở
mạng
B D
cổng nguồn: 6428 cổng nguồn: ?
cảng đích: 9157 cổng đích: ?
MỘT C
cổng nguồn: 9157 cổng nguồn: ?
cảng đích: 6428 cổng đích: ?
Phân kênh hướng kết nối
 Ổ cắm TCP được xác  máy chủ có thể hỗ trợ
định bởi 4- tuple: nhiều ổ cắm TCP đồng
• Nguồn Địa chỉ IP thời:
• số cổng nguồn • mỗi ổ cắm được xác định
• địa chỉ IP đích bởi 4 bộ riêng của nó
• số cổng đích • mỗi ổ cắm được liên kết với
một máy khách kết nối khác
 demux: bộ thu sử dụng nhau
tất cả bốn giá trị (4-
tuple) để chuyển đoạn
tới ổ cắm thích hợp
Phân kênh hướng kết nối: ví dụ
ứng dụng
ứng dụng P4 P5 P6 ứng dụng
P1 P2 P3
chuyên chở
chuyên chở chuyên chở
mạng
thuộc vật chất máy chủ: thuộc vật chất
địa chỉ IP
B
máy chủ: IP nguồn, cổng: B,80 máy chủ:

địa chỉ IP IP đích, cổng: A,9157 IP nguồn, cổng: C,5775 địa chỉ IP
A IP đích, cổng: B,80 C
IP nguồn, cổng: A,9157
IP đích, cổng: B,80
IP nguồn, cổng: C,9157
IP đích, cổng: B,80
Ba phân đoạn, tất cả đều có đích đến là địa chỉ IP: B,
cổng đích: 80 được phân kênh thành các cổng khác ổ cắm
Bản tóm tắt
 Ghép kênh, phân kênh: dựa trên các giá trị trường tiêu đề phân
đoạn, datagram
 UDP: phân kênh bằng số cổng đích (chỉ)
 TCP: phân kênh bằng cách sử dụng 4 bộ: địa chỉ IP nguồn và
đích cũng như số cổng
 Ghép kênh/phân kênh xảy ra ở tất cả các lớp

cậy
vận chuyển
UDP: Giao thức gói dữ liệu người dùng
 Giao thức truyền tải Internet Tại sao có UDP?
“không rườm rà”, “xương cốt”  không thiết lập kết nối (có
 dịch vụ “nỗ lực tốt nhất”, các thể thêm độ trễ RTT)
phân đoạn UDP có thể là:  đơn giản: không có trạng
thái kết nối ở người gửi,
• mất
người nhận
• giao hàng không theo thứ tự  kích thước tiêu đề nhỏ
cho ứng dụng
 không kết nối:  không kiểm soát tắc nghẽn
 UDP có thể nổ tung nhanh
• không bắt tay giữa người gửi và như mong muốn!
người nhận UDP  có thể hoạt động khi đối mặt
• mỗi phân đoạn UDP được xử lý với tắc nghẽn
độc lập với các phân đoạn khác
UDP: Giao thức gói dữ liệu người dùng
 Sử dụng UDP:
 phát trực tuyến các ứng dụng đa phương tiện (có khả năng chịu mất
mát, nhạy cảm với tốc độ)
 DNS
 SNMP
 HTTP/3
 nếu cần truyền tải đáng tin cậy qua UDP (ví dụ: HTTP/3):
 thêm độ tin cậy cần thiết ở lớp ứng dụng
 thêm kiểm soát tắc nghẽn ở lớp ứng dụng

UDP: Giao thức gói dữ liệu người dùng [RFC 768]

UDP: Hành động của lớp vận chuyển
ứng dụng khách SNMP máy chủ SNMP
chuyên chở chuyên

(UDP) chở
(UDP)
mạng (IP) mạng (IP)
liên kết liên kết

chất


Hành động của người gửi
ứng dụng UDP:
 được truyền một thông ứngtindụng
nhắn
báo lớp ứng dụng SNMP
chuyên chở  xác định giá trị trường tiêu UDP chuyên
UDPgiờgiờ tin nhắn
(UDP) đề phân đoạn UDP chở
SNMP
 tạo phân đoạn UDP (UDP)
mạng (IP) mạng (IP)
liên kết
 chuyển phân đoạn tới IP liên kết

chất


Hành động của người
ứng dụng nhận UDP:
 nhận phân đoạn từ IP ứng dụng
 kiểm tra giá trị tiêu đề
chuyên chở chuyên
tin nhắn tổng kiểm tra UDP
(UDP)  trích xuất thông báo lớp chở
SNMP
ứng dụng (UDP)
mạng
UDP (IP)
giờtin nhắn
mạng (IP)
SNMP  phân kênh tin nhắn tới ứng
liên kết dụng thông qua socket liên kết

chất

Đầu phân đoạn UDP
32 bit
cổng nguồn # cảng đích #
chiều dài tổng kiểm tra
ứng dụng độ dài, tính bằng

dữ liệu byte của phân đoạn
(khối hàng) UDP, bao gồm cả tiêu
đề
dữ liệu đến/từ lớp

Định dạng phân đoạn UDP ứng dụng

Tổng kiểm tra UDP
Mục tiêu: phát hiện lỗi ( tức là các bit bị đảo lộn) trong đoạn được
truyền
số thứ 1 số thứ 2 Tổng
Đã truyền: 5 6 11
Đã nhận: 4 6 11
máy thu tính toán

tổng kiểm tra
= người gửi tính toán
tổng kiểm tra (như đã nhận)

Tổng kiểm tra Internet
Mục tiêu: phát hiện lỗi ( tức là các bit bị đảo lộn) trong đoạn được
truyền
người gửi: người nhận :
 xử lý nội dung của phân  tính toán tổng kiểm tra phân đoạn
đoạn UDP (bao gồm các trường đã nhận
tiêu đề UDP và địa chỉ IP) dưới
dạng chuỗi số nguyên 16 bit  kiểm tra xem tổng kiểm tra được
 tổng kiểm tra: phép cộng tính toán có bằng giá trị trường
( tổng phần bù của một người) tổng kiểm tra hay không:
của nội dung phân đoạn • không bằng - phát hiện lỗi
 giá trị tổng kiểm tra được • bằng nhau - không phát hiện thấy lỗi.
đưa vào trường tổng kiểm Nhưng dù sao cũng có thể có lỗi? Trễ
tra UDP hơn ….
Tổng kiểm tra Internet: một ví dụ
ví dụ: cộng hai số nguyên 16 bit
1110011001100110
1101010101010101
quấn quanh 11011101110111011
Tổng 1011101110111100
tổng kiểm tra 0100010001000011
Lưu ý: khi cộng số, cần thêm phần mang về từ bit có ý nghĩa nhất vào kết quả
* Xem các bài tập tương tác trực tuyến để biết thêm ví dụ: h ttp://gaia.cs.umass.edu/kurose_ross/interactive/
Tổng kiểm tra Internet: bảo vệ yếu!
ví dụ: cộng hai số nguyên 16 bit
01
1110011001100110 10
1101010101010101
quấn quanh 11011101110111011 Mặc dù các số đã
thay đổi (lật bit),
Tổng 1011101110111100 tổng kiểm tra
không thay đổi!
tổng kiểm tra 0100010001000011

Tóm tắt : UDP
 Giao thức “không rườm rà”:
• các phân đoạn có thể bị mất, được giao không theo thứ tự
• dịch vụ nỗ lực tốt nhất: “gửi và hy vọng điều tốt nhất”
 UDP có ưu điểm của nó:
• không cần thiết lập/bắt tay (không phát sinh RTT)
• có thể hoạt động khi dịch vụ mạng bị xâm phạm
• giúp với độ tin cậy (tổng kiểm tra)
 xây dựng chức năng bổ sung trên UDP trong lớp ứng dụng (ví dụ:
HTTP/3)
cậy
vận chuyển
Nguyên tắc truyền dữ liệu đáng tin cậy
quá trình quá trình

gửi tiếp nhận
ứng dụng dữ dữ
chuyên chở liệu liệu
kênh đáng tin cậy
trừu tượng hóa dịch vụ

đáng tin cậy

quá trình quá trình quá trình quá trình

gửi tiếp nhận gửi tiếp nhận
ứng dụng dữ dữ ứng dụng dữ dữ
chuyên chở liệu liệu chuyên chở liệu liệu
kênh đáng tin cậy
phía người gửi phía người nhận
trừu tượng hóa dịch vụ giao thức truyền của giao thức
dữ liệu đáng tin truyền dữ liệu
đáng tin cậy cậy đáng tin cậy
chuyên chở
mạng
kênh không đáng tin cậy
triển khai dịch vụ đáng tin cậy


gửi tiếp nhận

Độ phức tạp của giao thức giao thức truyền
dữ liệu đáng tin
của giao thức
truyền dữ liệu
truyền dữ liệu đáng tin cậy sẽ cậy đáng tin cậy
phụ thuộc (rất nhiều) vào đặc chuyên chở

mạng
điểm của kênh không đáng tin kênh không đáng tin cậy
cậy (mất, hỏng, sắp xếp lại dữ
liệu?)

gửi tiếp nhận

giao thức truyền của giao thức
Người gửi, người nhận không dữ liệu đáng tin truyền dữ liệu
biết “trạng thái” của nhau, ví dụ cậy đáng tin cậy
đã nhận được tin nhắn chưa? chuyên chở

mạng
 trừ khi được liên lạc qua tin kênh không đáng tin cậy
nhắn

Giao thức truyền dữ liệu đáng tin cậy (rdt): giao diện
rdt_send(): được gọi từ phía Deliver_data(): được gọi bởi
trên, (ví dụ: bằng ứng dụng.). rdt để chuyển dữ liệu lên lớp
Dữ liệu được truyền để phân trên
phối đến lớp trên của người quá trình quá trình
nhận gửi tiếp nhận
rdt_send() dữ dữ
liệu liệu cung cấp_data()
phía người gửi dữ liệu phía người nhận

thực hiện giao thức thực hiện giao thức
truyền dữ liệu gói truyền dữ liệu
đáng tin cậy rdt đáng tin cậy rdt
udt_send() tiêu đề dữ tiêu đề dữ rdt_rcv()

liệu liệu
kênh không đáng tin cậy
udt_send(): được gọi bởi rdt rdt_rcv(): được gọi khi gói đến
để chuyển gói qua Giao tiếp hai chiều qua kênh không phía người nhận của kênh
kênh tới máy thu không đáng đáng tin cậy
tin cậy Lớp vận chuyển: 3-46
Truyền dữ liệu đáng tin cậy: bắt đầu
Chúng tôi sẽ:
 từng bước phát triển phía gửi, phía nhận của giao thức truyền dữ liệu
đáng tin cậy ( rdt )
 chỉ xem xét việc truyền dữ liệu một chiều
• nhưng thông tin điều khiển sẽ chảy theo cả hai hướng!
 sử dụng máy trạng thái hữu hạn (FSM) để chỉ định người gửi, người nhận
sự kiện gây ra sự chuyển trạng thái
hành động được thực hiện khi chuyển đổi trạng thái
trạng thái: khi ở “ trạng thái
” này , trạng thái tiếp tình tình trạng
theo được xác định duy trạn sự kiện
nhất bởi sự kiện tiếp 2
g hành động
theo
1
rdt1.0: truyền đáng tin cậy qua kênh đáng tin cậy
 kênh cơ bản hoàn toàn đáng tin cậy
• không có lỗi chút nào
• không bị mất gói
 riêng biệt cho người gửi, người nhận:

• người gửi gửi dữ liệu vào kênh cơ bản
• người nhận đọc dữ liệu từ kênh cơ bản
Chờ cuộc rdt_send(dữ liệu) Chờ cuộc rdt_rcv(gói)

người gửi gọi từ gói = make_pkt(dữ liệu) người nhận gọi từ bên trích xuất (gói, dữ liệu)
phía trên udt_send(gói) dưới cung cấp_data(dữ liệu)

rdt2.0: kênh có lỗi bit
 kênh cơ bản có thể lật các bit trong gói
• tổng kiểm tra (ví dụ: tổng kiểm tra Internet) để phát hiện lỗi bit
 câu hỏi: làm thế nào để phục hồi sau lỗi?
Con người khắc phục “ lỗi” trong cuộc trò chuyện bằng cách nào?

rdt2.0: kênh có lỗi bit
 kênh cơ bản có thể lật các bit trong gói
• tổng kiểm tra để phát hiện lỗi bit
 câu hỏi: làm thế nào để phục hồi sau lỗi?
• xác nhận (ACK): người nhận thông báo rõ ràng với người gửi rằng gói
đã nhận được OK
• phản hồi phủ định (NAK): người nhận thông báo rõ ràng với người gửi
rằng gói hàng có lỗi
• người gửi truyền lại gói tin khi nhận được NAK
dừng lại và chờ

người
đợi gửi gửi một gói, sau đó đợi phản hồi của người nhận
rdt2.0: Thông số kỹ thuật FSM
rdt_send(dữ liệu)
snkpkt = make_pkt(dữ liệu, tổng kiểm
tra)
udt_send(sndpkt) rdt_rcv(rcvpkt) &&
Chờ cuộc Đợi ACK isNAK(rcvpkt)
người gửi gọi từ phía hoặc udt_send(sndpkt) rdt_rcv(rcvpkt) && bị hỏng(rcvpkt)
trên NAK
udt_send(NAK)
rdt_rcv(rcvpkt) && isACK(rcvpkt)

Chờ cuộc
L gọi từ bên người nhận
dưới
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

trích xuất (rcvpkt, dữ
liệu)
cung cấp_data(dữ
liệu)
udt_send(ACK)
rdt2.0: Đặc tả FSM
tra)
isNAK(rcvpkt)
trên NAK
udt_send(NAK)

Chờ cuộc
dưới
Lưu ý: “trạng thái” của người nhận (người nhận có

nhận được tin nhắn của tôi chính xác không?)
người gửi không biết trừ khi được truyền đạt bằng liệu)
cách nào đó từ người nhận đến người gửi cung cấp_data(dữ
liệu)
 đó là lý do tại sao chúng ta cần một giao thức! udt_send(ACK)
rdt2.0: hoạt động không có lỗi
tra)
trên NAK
udt_send(NAK)

Chờ cuộc
dưới

liệu)
liệu)
udt_send(ACK)
rdt2.0: kịch bản gói bị hỏng
tra)
trên NAK
udt_send(NAK)

Chờ cuộc
dưới

liệu)
liệu)
udt_send(ACK)
rdt2.0 có một lỗ hổng chết người!
điều gì xảy ra nếu ACK/NAK bị xử lý trùng lặp :
hỏng ?  người gửi truyền lại gói hiện tại
 người gửi không biết chuyện gì đã nếu ACK/NAK bị hỏng
xảy ra ở người nhận!
 người gửi thêm số thứ tự vào
 không thể truyền lại: có thể trùng mỗi gói
lặp
 người nhận loại bỏ (không gửi)
gói trùng lặp
dừng lại và chờ đợi
người gửi gửi một gói, sau đó đợi
phản hồi của người nhận
rdt2.1: người gửi, xử lý ACK/NAK bị cắt xén
sndpkt = make_pkt(0, dữ liệu, tổng
kiểm tra) rdt_rcv(rcvpkt) && (hỏng(rcvpkt)
udt_send(sndpkt) ||
Đợi cuộc Đợi ACK isNAK(rcvpkt) )
gọi 0 từ hoặc NAK
0 udt_send(sndpkt)
phía trên
rdt_rcv(rcvpkt)
rdt_rcv(rcvpkt)
&& không bị hỏng(rcvpkt) &&
&& không bị hỏng(rcvpkt)
isACK(rcvpkt)
&& isACK(rcvpkt)
L
L
Đợi ACK Chờ
hoặc NAK gọi 1 từ
rdt_rcv(rcvpkt) 1 trên
&& (hỏng(rcvpkt) ||
isNAK(rcvpkt) ) rdt_send(dữ liệu)
udt_send(sndpkt) sndpkt = make_pkt(1, dữ liệu, tổng

kiểm tra)
udt_send(sndpkt)

rdt2.1: bộ thu, xử lý các ACK/NAK bị cắt xén
&& has_seq0(rcvpkt)
trích xuất (rcvpkt, dữ liệu)
cung cấp_data(dữ liệu)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && (hỏng(rcvpkt) rdt_rcv(rcvpkt) && (hỏng(rcvpkt)
sndpkt = make_pkt(NAK, chksum) sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
Chờ Chờ
rdt_rcv(rcvpkt) && 0 từ 1 từ rdt_rcv(rcvpkt) &&
không bị hỏng (rcvpkt) && dưới dưới không bị hỏng (rcvpkt) &&
has_seq1(rcvpkt) lên lên has_seq0(rcvpkt)
sndpkt = make_pkt(ACK, chksum) sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
&& has_seq1(rcvpkt)

sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)

rdt2.1: thảo luận
người gửi: người nhận:
 seq # đã được thêm vào gói  phải kiểm tra xem gói nhận
 hai phần tiếp theo. # s (0,1) là được có trùng lặp không
đủ. Tại sao? • trạng thái cho biết pkt seq #
được mong đợi là 0 hay 1
 phải kiểm tra xem ACK/NAK
 lưu ý: người nhận không thể
nhận được có bị hỏng không
biết liệu ACK/NAK cuối cùng
 gấp đôi số tiểu bang của nó có được người gửi
• trạng thái phải “ ghi nhớ” liệu gói nhận hay không
tin “mong đợi” có số thứ tự là 0
hay 1

rdt2.2: giao thức không có NAK
 chức năng tương tự như rdt2.1, chỉ sử dụng ACK
 thay vì NAK, người nhận gửi ACK cho gói cuối cùng đã nhận
được OK
• người nhận phải bao gồm rõ ràng số seq của gói đang được ACK
 ACK trùng lặp ở người gửi dẫn đến hành động tương tự như
NAK: truyền lại gói hiện tại
hư chúng ta sẽ thấy, TCP sử dụng phương pháp này để không có NAK

rdt2.2: mảnh gửi, mảnh nhận
rdt_send(dữ
liệu) = make_pkt(0, dữ liệu, tổng
sndpkt
kiểm tra) rdt_rcv(rcvpkt) &&
udt_send(sndpkt) (hỏng(rcvpkt) ||
Đợi cuộc Đợi ACK
0 isACK(rcvpkt,1) )
gọi 0 từ
phía trên udt_send(sndpkt)
FSM người gửi
miếng rdt_rcv(rcvpkt)
&& không bị
rdt_rcv(rcvpkt) && hỏng(rcvpkt)
(hỏng(rcvpkt) || && isACK(rcvpkt,0)
L
has_seq1(rcvpkt)) Chờ nhận FSM
0 từ
udt_send(sndpkt) dưới miếng
lên
&& has_seq1(rcvpkt)
sndpkt = make_pkt(ACK1, chksum)
udt_send(sndpkt) Lớp vận chuyển: 3-60
rdt3.0: kênh bị lỗi và mất
Giả định kênh mới: kênh cơ bản cũng có thể mất các gói (dữ
liệu, ACK)
• tổng kiểm tra, số thứ tự, ACK, truyền lại sẽ giúp ích… nhưng chưa
đủ
Hỏi: Con người xử lý các từ bị mất từ người

gửi đến người nhận trong cuộc trò
chuyện như thế nào ?
rdt3.0: kênh bị lỗi và mất
Tiếp cận: người gửi đợi khoảng thời gian “hợp lý” cho ACK
 truyền lại nếu không nhận được ACK trong thời gian này
 nếu gói tin (hoặc ACK) chỉ bị trì hoãn (không bị mất):
• việc truyền lại sẽ bị trùng lặp, nhưng seq # s đã xử lý việc này rồi!
• người nhận phải chỉ định số thứ tự của gói được ACK
 sử dụng đồng hồ đếm ngược để ngắt sau khoảng thời gian “hợp
lý”
hết giờ

người gửi rdt3.0
sndpkt = make_pkt(0, dữ liệu, tổng kiểm tra)
udt_send(sndpkt)
thời gian bắt đầu
Chờ Đợi
gọi 0 từ trên ACK0
cao
rdt_rcv(rcvpkt)
&& không bị rdt_rcv(rcvpkt)
hỏng(rcvpkt) && không bị
&& isACK(rcvpkt,1)
stop_timer hỏng(rcvpkt)
&& isACK(rcvpkt,0)
stop_timer
Đợi Chờ
ACK1 gọi 1 từ trên
sndpkt = make_pkt(1, dữ liệu, tổng kiểm
tra)
udt_send(sndpkt)

người gửi rdt3.0
rdt_rcv(rcvpkt) &&
sndpkt = make_pkt(0, dữ liệu, tổng kiểm tra)(hỏng(rcvpkt) ||
udt_send(sndpkt) isACK(rcvpkt,1) )
rdt_rcv(rcvpkt) thời gian bắt đầu L
L Chờ Đợi
ACK0 hết giờ
gọi 0 từ trên
udt_send(sndpkt)
cao
rdt_rcv(rcvpkt)
&& không bị rdt_rcv(rcvpkt)
hỏng(rcvpkt) && không bị
&& isACK(rcvpkt,1)
stop_timer hỏng(rcvpkt)
&& isACK(rcvpkt,0)
stop_timer
Đợi Chờ
hết giờ ACK1 gọi 1 từ trên
udt_send(sndpkt)
thời gian bắt đầu rdt_rcv(rcvpkt)
rdt_send(dữ liệu) L
rdt_rcv(rcvpkt) &&
(hỏng(rcvpkt) || sndpkt = make_pkt(1, dữ liệu, tổng kiểm
isACK(rcvpkt,0) ) tra)
udt_send(sndpkt)
L thời gian bắt đầu

rdt3.0 đang hoạt động
người gửi người nhận người gửi người nhận
gửi gói0 pkt0 gửi gói0 pkt0
rcv pkt0 rcv pkt0
ack0 gửi ack0 ack0 gửi ack0
rcv ack0 rcv ack0
gửi gói 1 gói 1 gửi gói 1 gói 1
rcv pkt1 X
sự mất mát
ack1 gửi ack1
rcv ack1
gửi gói0 pkt0
rcv pkt0 hết giờ
ack0 gửi ack0 gửi lại gói 1 gói 1
rcv pkt1
ack1 gửi ack1
rcv ack1
gửi gói0 pkt0
(a) không mất mát rcv pkt0
ack0 gửi ack0
(b) mất gói

rdt3.0 đang hoạt động
người gửi người nhận
người gửi người nhận gửi gói0
pkt0
rcv pkt0
gửi gói0 pkt0 gửi ack0
ack0
rcv pkt0 rcv ack0
ack0 gửi ack0 gửi gói 1 gói
rcv ack0 1 rcv pkt1
gửi gói 1 gói gửi ack1
1 rcv pkt1 ack1
ack1 gửi ack1
X hết giờ
sự mất mát gửi lại gói 1
gói 1 rcv pkt1
hết giờ
gửi lại gói 1 gói 1
rcv pkt1 rcv ack1 (phát hiện trùng lặp)
gửi gói0 pkt0 gửi ack1
(phát hiện trùng lặp)
ack1 gửi ack1 ack1 rcv pkt0
rcv ack1 rcv ack1 gửi ack0
gửi gói0 pkt0 (phớt lờ) ack0
rcv pkt0
ack0 gửi ack0 gói
1
(c) Mất ACK (d) hết thời gian sớm/ ACK bị trì hoãn
Hiệu suất của rdt3.0 (dừng và chờ)
 Người gửi U : mức sử dụng – phần thời gian người gửi bận gửi
 ví dụ: liên kết 1 Gbps, prop 15 ms. độ trễ, gói 8000 bit
• Thời gian truyền gói tin vào kênh:
L 8000 bit
D chuyển đổi = R = = 8 micro giây
10 9 bit/giây

rdt3.0: hoạt động dừng và chờ
người người
gửi nhận
Bit gói đầu tiên được truyền, t = 0
bit gói đầu tiên đến

RTT bit gói cuối cùng đến, gửi ACK
ACK đến, gửi tiếp theo

gói tin, t = RTT + L/R

rdt3.0: hoạt động dừng và chờ
người người
gửi nhận
L/R trái/
bạn là người= gửi phải
RTT+ Trái/R
.008 RTT
=
30.008
= 0,00027
 hiệu suất giao thức rdt 3.0 quá tệ!

 Giao thức giới hạn hiệu suất của cơ sở hạ tầng (kênh) cơ bản

rdt3.0: hoạt động của giao thức đường ống
đường ống: người gửi cho phép nhiều gói, “ trong chuyến bay”, chưa
được xác nhận
• phạm vi số thứ tự phải được tăng lên
• lưu vào bộ đệm ở người gửi và/hoặc người nhận

Đường ống: tăng cường sử dụng
người người
Bit gói đầu tiên được truyền, t = gửi nhận
bit cuối cùng được truyền 0
đi, t = L/R
bit gói đầu tiên đến

RTT bit gói cuối cùng đến, gửi ACK
bit cuối cùng của gói thứ 2 đến, gửi ACK
bit cuối cùng của gói thứ 3 đến, gửi ACK
ACK đến, gửi tiếp theo
gói tin, t = RTT + L/R
Tăng đường ống 3 gói
sử dụng theo hệ số 3!
U 3L / R .0024
sender = = = 0.00081
RTT + L / R 30.008

Go-Back-N: người gửi
 người gửi: “cửa sổ” lên tới N, các gói được truyền liên tiếp nhưng không
được ACK
• k-bit seq # trong tiêu đề pkt
 ACK tích lũy: ACK( n ): ACK tất cả các gói đến, bao gồm cả seq # n
• khi nhận ACK( n ): di chuyển cửa sổ về phía trước để bắt đầu tại n+1
 hẹn giờ cho gói tin cũ nhất trên chuyến bay
 timeout(n): truyền lại gói n và tất cả các gói có thứ tự cao hơn trong cửa sổ
Go-Back-N: máy thu
 Chỉ ACK: luôn gửi ACK cho gói được nhận chính xác cho đến nay, với
số thứ tự cao nhất
• có thể tạo ra các ACK trùng lặp
• chỉ cần nhớ RCv_base
 khi nhận được gói tin không theo thứ tự:
• có thể loại bỏ (không đệm) hoặc đệm: một quyết định thực hiện
• gói lại ACK có số thứ tự cao nhất
Chế độ xem của người nhận về không gian số thứ tự:
đã nhận và ACK
… … Không theo thứ tự: đã nhận nhưng chưa được ACK
rcv_base
Không nhận
Quay lại-N đang hoạt động
cửa sổ người gửi (N=4) người gửi người nhận
012345678 gửi gói0
012345678 gửi gói 1
gửi gói 2 nhận pkt0, gửi ack0
012345678
gửi gói 3 sựXmất mát nhận pkt1, gửi ack1
012345678
(Chờ đợi)
nhận pkt3, loại bỏ,
012345678 RCv ack0, gửi pkt4 (lại)gửi ack1
012345678 RCv ack1, gửi pkt5 nhận pkt4, loại bỏ,
(lại)gửi ack1
bỏ qua ACK trùng lặp nhận gói tin 5, loại bỏ,
(lại)gửi ack1
gói 2 hết thời gian chờ
012345678 gửi gói 2
012345678 gửi gói 3
012345678 gửi gói 4 RCv pkt2, giao hàng, gửi ack2
012345678 gửi gói 5 RCv pkt3, giao hàng, gửi ack3
RCv pkt4, giao hàng, gửi ack4
RCv pkt5, giao hàng, gửi ack5

Lặp lại có chọn lọc: cách tiếp cận
 đường ống : nhiều gói tin trong chuyến bay
 người nhận ACK riêng lẻ tất cả các gói nhận được chính xác
• đệm các gói, nếu cần, để phân phối theo thứ tự lên lớp trên
 người gửi:
• duy trì (về mặt khái niệm) bộ đếm thời gian cho mỗi gói không được ACK
• hết thời gian chờ: truyền lại gói chưa ACK duy nhất được liên kết với
thời gian chờ
• duy trì (về mặt khái niệm) “cửa sổ” trên N seq # s liên tiếp
• giới hạn các gói “đang bay” được sắp xếp theo đường dẫn nằm trong
cửa sổ này
Lặp lại có chọn lọc: cửa sổ người gửi, người nhận

Lặp lại có chọn lọc: người gửi và người nhận
người gửi người nhận
dữ liệu từ trên: gói n trong [ rcvbase, rcvbase+N-1]
 nếu seq # có sẵn tiếp theo trong  gửi ACK( n )
cửa sổ, hãy gửi gói  không theo thứ tự: bộ đệm
hết thời gian ( n ):  theo thứ tự: phân phối (cũng
 gửi lại gói n , khởi động lại bộ đếm phân phối các gói được lưu vào bộ
thời gian đệm, theo thứ tự), chuyển cửa sổ
sang gói chưa nhận được tiếp
ACK( n ) trong [ sendbase,sendbase+N- theo
1]:
gói n trong [rcvbase-N,rcvbase-1]
 đánh dấu gói n là đã nhận
 ACK( n )
 nếu n gói không được ACK nhỏ
nhất, chuyển cơ sở cửa sổ sang
nếu không thì:
seq # không được ACK tiếp theo  phớt lờ
Hành động lặp lại có chọn lọc
cửa sổ người gửi (N=4) người gửi người nhận
012345678 gửi gói0
012345678 gửi gói 1
012345678 gửi gói 2 nhận pkt0, gửi ack0
012345678 gửi gói 3 sựXmất mát nhận pkt1, gửi ack1
(Chờ đợi)
nhận pkt3, đệm ,
012345678 RCv ack0, gửi pkt4 gửi ack3
012345678 RCv ack1, gửi pkt5
nhận pkt4, bộ đệm,
bản ghi ack3 đã đến gửi ack4
nhận pkt5, bộ đệm,
gói 2 hết thời gian chờ gửi ack5
012345678 gửi gói 2
012345678 (nhưng không phải 3,4,5)
012345678 RCv pkt2; giao gói pkt2,
012345678 pkt3, pkt4, pkt5; gửi ack2
Q: Điều gì xảy ra khi ack2 xuất hiện?

cửa sổ nhận
Lặp lại có chọn lọc:

cửa sổ người gửi
(sau khi nhận) (sau khi nhận)
pkt0
một vấn đề nan giải!

0123012
0123012 gói 1 0123012
0123012 pkt2 0123012
0123012
ví dụ: 0123012 pkt3
X
0123012
 seq #s : 0, 1, 2, 3 (đếm cơ số 4) pkt0 sẽ chấp nhận gói
với số thứ tự 0
 kích thước cửa sổ=3 (a) không có vấn đề gì
0123012 pkt0
0123012 gói 1 0123012
0123012 pkt2 X 0123012
X 0123012
X
hết giờ
truyền lại gói tin0
0123012 pkt0
sẽ chấp nhận gói
(b) ôi!
cửa sổ nhận
Lặp lại có chọn lọc:

cửa sổ người gửi
(sau khi nhận) (sau khi nhận)
pkt0
một vấn đề nan giải!

0123012
0123012 gói 1 0123012
0123012 pkt2 0123012
0123012
ví dụ: 0123012 pkt3
X
 seq #s : 0, 1, 2, 3 (đếm cơ số 4)  người nhậnpkt0
0123012
không nhìn thấy với số thứ tự 0
 kích thước cửa sổ=3 (a) không có vấngửi
phía người đề gì
 hành vi của
người nhận
giống hệt nhau
0trong
1 2 3 0 1cả
2 hai
pkt0
0trường
1 2 3 0 1 2hợp!
Câu hỏi: Cần có mối quan hệ nào  0có
1 2điều
gói 1
3 0 1 2gì đó
pkt2
0123012
X
giữa kích thước chuỗi # và kích
0123012
(rất) không ổn! X 0123012
thước cửa sổ để tránh sự cố hết giờ
X
trong kịch bản (b)? truyền lại gói tin0
0123012 pkt0
(b) ôi!
cậy
• cấu trúc phân khúc
• truyền dữ liệu đáng tin cậy
• quản lý kết nối
 Kiểm soát tắc nghẽn TCP Lớp vận chuyển: 3-81
TCP: tổng quan RFC: 793.1122, 2018, 5681, 7323
 điểm tới điểm :  ACK tích lũy
• một người gửi, một người nhận 
đường ống:
 đáng tin cậy, theo thứ tự byte • Điều khiển tắc nghẽn và luồng
steam: TCP đặt kích thước cửa sổ
• không có “ ranh giới tin nhắn”
 hướng kết nối:
 dữ liệu song công hoàn toàn:
• bắt tay (trao đổi tin nhắn điều
• luồng dữ liệu hai chiều trong cùng
khiển) khởi tạo trạng thái người
một kết nối
gửi, người nhận trước khi trao đổi
• MSS: kích thước phân khúc tối đa
dữ liệu
 kiểm soát dòng chảy:
• người gửi sẽ không lấn át người
nhận Lớp vận chuyển: 3-82
Cấu trúc phân đoạn TCP
32 bit
cổng nguồn # cảng đích # Seq #: đếm byte dữ liệu vào

ACK: seq # của byte dự kiến số thứ tự dòng byte (không phải phân
tiếp theo; Một chút: đây là đoạn!)
ACK số xác nhận
độ dài (của tiêu đề TCP) cái đầukhông
đã sử dụng
len MỘTP
C Ebạn RSF cửa sổ nhận kiểm soát luồng: # byte
Tổng kiểm tra Internet tổng kiểm tra Con trỏ dữ liệu khẩn cấp người nhận sẵn sàng chấp
nhận
tùy chọn (độ dài thay
C, E: thông báo tắc nghẽn đổi)
Tùy chọn
ứng dụng dữ liệu được
RST, SYN, FIN: quản lý kết dữ liệu ứng dụng gửi
nối (chiều dài thay đổi) vào ổ cắm TCP

Số thứ tự TCP, ACK
phân đoạn gửi đi từ người gửi
Số thứ tự: cổng nguồn # cảng đích #
số thứ tự
• luồng byte “ số” của byte đầu số xác nhận
tiên trong dữ liệu của phân tổng kiểm tra

rwnd
con trỏ khẩn cấp
đoạn kích thước cửa sổ

Sự nhìn nhận : N
• seq # của byte tiếp theo

được mong đợi từ phía bên không gian số thứ tự của người gửi
kia đã gửi đã gửi, có thể sử không

• ACK tích lũy đã xác nhận chưa ACK dụng đượccó thể
nhưng sử
Hỏi : cách người nhận xử lý các (“ trên
chuyến bay”) không dụng
phân đoạn không theo thứ tự chưa gửi được
đoạn gửi đi từ máy thu
• Trả lời: Thông số TCP không

cổng nguồn # cảng đích #
số thứ tự
nói, - tùy thuộc vào người số xác nhận

M rwnd
triển khai tổng kiểmỘ
tra con trỏ khẩn cấp
T Lớp vận chuyển: 3-84
Số thứ tự TCP, ACK
Máy chủ A Máy chủ B
Loại người dùng ' C '

Seq=42, ACK=79, dữ liệu = ' C '
Máy chủ nhận ACK của '
C ' , phản hồi lại ' C '
Seq=79, ACK=43, dữ liệu = ' C '
máy chủ nhận
được ACK của
tiếng vang ' C ' Thứ tự=43, ACK=80
kịch bản telnet đơn giản

Thời gian chuyến đi khứ hồi TCP, thời gian chờ
Hỏi: cách đặt giá trị thời gian Hỏi : làm thế nào để ước tính
chờ TCP? RTT?
 dài hơn RTT, nhưng RTT khác  SampleRTT: đo thời gian từ khi
nhau! truyền phân đoạn cho đến khi
 quá ngắn: Hết thời gian chờ nhận được ACK
• bỏ qua việc truyền lại
sớm, truyền lại không cần thiết
 MẫuRTT sẽ thay đổi, muốn RTT
 quá lâu: phản ứng chậm khi mất
ước tính “ mượt mà hơn ”
đoạn
• tính trung bình một số phép đo gần
đây , không chỉ SampleRTT hiện
tại

RTT ước tính = (1-  )*RTT ước tính +  *RTT mẫu
 e số mũ w 8 di chuyển một trung bình (EWMA)
 ảnh hưởng của mẫu trong quá khứ giảm nhanh theo
cấp số nhân RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
 giá trị điển hình:  = 0,125

350
RTT: gaia.cs.umass.edu ĐẾN fantasia.eurecom.fr
300
RTT (mili giây)

250
RTT (milliseconds)
200
mẫuRTT
150
ước tínhRTT
100
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)
thời gian
SampleRTT Estimated RTT
(giây)
 khoảng thời gian chờ: Ước tínhRTT cộng với “ biên độ an toàn”
• sự thay đổi lớn trong EstimatedRTT: muốn có biên độ an toàn lớn hơn
Khoảng thời gian chờ =RTT ước tính +
4*DevRTT
RTT ước tính “ biên độ an toàn ”
 DevRTT : EWMA của độ lệch SampleRTT so với EstimatedRTT :

DevRTT = (1-  )*DevRTT +  *|SampleRTT-EstimatedRTT|
(thông thường,  = 0,25)
Người gửi TCP (đơn giản hóa)
sự kiện: dữ liệu nhận được từ ứng sự kiện: hết thời gian
dụng  truyền lại đoạn gây ra thời
 tạo phân đoạn với seq # gian chờ
 khởi động lại bộ đếm thời gian
 seq # là số luồng byte của byte
dữ liệu đầu tiên trong phân
đoạn sự kiện: Đã nhận được ACK
 bắt đầu hẹn giờ nếu chưa chạy  nếu ACK xác nhận các phân
• nghĩ về bộ đếm thời gian như đối đoạn chưa được ACK trước
với phân đoạn chưa được ACK lâu đó
đời nhất
• cập nhật những gì được biết là
• khoảng thời gian hết hạn:
ACKed
TimeOutInterval
• bắt đầu hẹn giờ nếu vẫn còn các
phân đoạn chưa được ACK
Bộ thu TCP: Tạo ACK [RFC 5681]
Sự kiện tại máy thu Hành động của người nhận TCP
sự xuất hiện của phân khúc theo thứ tựACK vớibị trì hoãn. Chờ tới 500ms
số thứ tự dự kiến. Tất cả dữ liệu lên tớicho đoạn tiếp theo. Nếu không có đoạn tiếp theo,
số thứ tự dự kiến đã được ACK gửi ACK
sự xuất hiện của phân khúc theo thứ tựgửi

vớingay lập tức tích lũy duy nhất
số thứ tự dự kiến. Một cái khác ACK, ACK cả hai phân đoạn theo thứ tự
phân đoạn có ACK đang chờ xử lý
sự xuất hiện của phân khúc không theongay

thứ lập
tự tức gửi ACK trùng lặp ,
seq cao hơn mong đợi. # . biểu thị seq. # byte dự kiến tiếp theo
Đã phát hiện thấy khoảng trống
sự xuất hiện của phân khúc đó gửi ACK ngay lập tức, với điều kiện là
đoạn
lấp đầy một phần hoặc hoàn toàn khoảng bắt đầu ở đầu dưới của khoảng cách
trống

TCP: kịch bản truyền lại
Máy chủ A Máy chủ B Máy chủ A Máy chủ B
SendBase=92
Seq=92, 8 byte dữ liệu Seq=92, 8 byte dữ liệu
Seq=100, 20 byte dữ liệu

hết giờ
hết giờ
ACK=100
X
ACK=100
ACK=120
Seq=92, 8 byte dữ liệu Seq=92, 8

SendBase=100 byte dữ liệu gửi tích lũy
SendBase=120 ACK với giá 120
ACK=100
ACK=120
SendBase=120
kịch bản mất ACK hết thời gian sớm

TCP: kịch bản truyền lại

ACK=100
X
ACK=120
ACK tích lũy cho ACK

bị mất trước đó

TCP truyền lại nhanh
TCP truyền lại nhanh
nếu người gửi nhận được 3 ACK
Seq=92
bổ sung cho cùng một dữ liệu (“ Seq=1
, 8 byte
d ữ li ệ u
3 ACK trùng lặp”), hãy gửi lại phân 0 0, 20 b
yte dữ
li ệ u
đoạn không có ACK với số thứ X
tự nhỏ nhất
=100
 có khả năng phân đoạn không ACK
được ACK bị mất, vì vậy đừng đợi =100
hết giờ
ACK
hết thời gian chờ CK =100
A
= 10 0
Việc nhận được ba ACK trùng ACK
lặp cho biết 3 phân đoạn đã Seq=100, 20 byte dữ liệu
nhận được sau một phân đoạn

bị thiếu – có khả năng là phân
đoạn bị mất. Vậy hãy truyền lại!
cậy
• cấu trúc phân khúc
• truyền dữ liệu đáng tin cậy
• quản lý kết nối
 Kiểm soát tắc nghẽn TCP Lớp vận chuyển: 3-94
Kiểm soát luồng TCP
ứng dụng
Câu hỏi: Điều gì xảy ra nếu Ứng dụng xóa dữ liệu
quá trình
lớp mạng phân phối dữ liệu khỏi bộ đệm ổ cắm TCP

nhanh hơn lớp ứng dụng xóa Ổ cắm TCP
dữ liệu khỏi bộ đệm ổ cắm? bộ đệm máy thu
TCP
mã số
Lớp mạng phân phối
tải trọng gói dữ liệu IP
vào bộ đệm ổ cắm TCP
IP
mã số
từ người gửi
ngăn xếp giao thức máy thu

ứng dụng
quá trình

TCP
mã số
Lớp mạng phân phối
tải trọng gói dữ liệu IP
vào bộ đệm ổ cắm TCP
IP
mã số
từ người gửi

ứng dụng
quá trình

TCP
mã số
cửa sổ nhận
kiểm soát luồng: # byte
người nhận sẵn sàng chấp IP
nhận mã số
từ người gửi

ứng dụng
quá trình

TCP
Kiểm soát lưu lượng mã số
người nhận kiểm soát người

gửi, do đó người gửi sẽ không IP
mã số
làm tràn bộ đệm của người
nhận do truyền quá nhiều, quá
nhanh từ người gửi

 Bộ thu TCP “ quảng cáo” không gian bộ
đệm trống trong trường rwnd trong đến quá trình nộp đơn
tiêu đề TCP
• RcvBuffer được đặt thông qua tùy Bộ đệm Rcv dữ liệu đệm
chọn ổ cắm (mặc định điển hình là 4096
byte) rwnd không gian đệm miễn phí
• nhiều hệ điều hành tự động điều chỉnh
RcvBuffer
Tải trọng phân đoạn TCP
 người gửi giới hạn số lượng dữ liệu
không được ACK (“ trong chuyến bay”) Bộ đệm phía máy thu TCP
ở mức nhận được
 đảm bảo bộ đệm nhận sẽ không bị tràn
kiểm soát luồng: # byte người nhận sẵn sàng
chấp nhận
 Bộ thu TCP “ quảng cáo” không gian bộ
đệm trống trong trường rwnd trong
tiêu đề TCP
• RcvBuffer được đặt thông qua tùy cửa sổ nhận
chọn ổ cắm (mặc định điển hình là 4096

byte)
• nhiều hệ điều hành tự động điều chỉnh
RcvBuffer
 người gửi giới hạn số lượng dữ liệu
không được ACK (“ trong chuyến bay”)
ở mức nhận được
Định dạng phân đoạn
 đảm bảo bộ đệm nhận sẽ không bị tràn TCP
Quản lý kết nối TCP
Trước khi trao đổi dữ liệu, người gửi/người nhận “ bắt tay”:
 đồng ý thiết lập kết nối (mỗi bên biết nhau sẵn sàng thiết lập kết nối)
 đồng ý về các tham số kết nối (ví dụ: bắt đầu seq #s)
trạng thái kết nối: ESTAB trạng thái kết nối: ESTAB
biến kết nối: Biến kết nối:
seq # từ máy khách seq # từ máy khách
đến máy chủ đến máy chủ
máy chủ đến máy khách máy chủ đến máy khách
kích thước bộ đệm kích thước bộ đệm
RCv RCv
mạng
tại máy chủ, máy khách tại máymạng
chủ, máy khách
Ổ cắm clientSocket = Kết nối ổ cắmSocket =

newSocket("tên máy chủ","số cổng"); WelcomeSocket.accept();
Đồng ý thiết lập kết nối
Bắt tay 2 chiều:
Hỏi: Bắt tay 2 chiều có luôn hoạt

Hãy nói chuyện động trong mạng không?
ESTAB
ĐƯỢC RỒI  độ trễ thay đổi
ESTAB
 tin nhắn được truyền lại (ví dụ
req_conn(x)) do mất tin nhắn
 sắp xếp lại tin nhắn
chọn x
req_conn(x)  không thể “nhìn thấy” phía bên
acc_conn(x)
ESTAB kia
ESTAB

Kịch bản bắt tay 2 chiều
chọn x
req_conn(x)
ESTAB
acc_conn(x)
ESTAB
dữ liệu(x+1) chấp nhận
dữ
ACK(x+1)
liệu(x+1)
sự liên quan
x hoàn thành
Không có gì!

chọn x
req_conn(x)
ESTAB
truyền lại acc_conn(x)
req_conn(x)
ESTAB
req_conn(x)
sự liên quan
khách x hoàn thành máy chủ
hàng quên x
chấm dứt
ESTAB
acc_conn(x)
Vấn đề: kết nối mở một
nửa! (không có khách
hàng)
chọn x
req_conn(x)
ESTAB
truyền lại acc_conn(x)
req_conn(x)
ESTAB
dữ
truyền lại liệu(x+1)
dữ
liệu(x+1) sự liên quan
x hoàn thành máy chủ
khách
hàng quên x
chấm dứt req_conn(x)
ESTAB
dữ
liệu(x+1)
Vấn đề: trùng lặp dữ
liệu
Bắt tay 3 bước TCP
Trạng thái máy chủ
serverSocket = socket(AF_INET,SOCK_STREAM)
Trạng thái khách hàng serverSocket.bind(('',serverPort))
serverSocket.listen(1)
clientSocket = socket(AF_INET, SOCK_STREAM) ConnectionSocket, addr = serverSocket.accept()
NGHE
clientSocket.connect((serverName,serverPort)) NGHE
chọn số seq ban đầu, x
gửi tin nhắn TCP SYN
ĐỒNG HỒ SYNbit=1, Seq=x
chọn số seq ban đầu, y
gửi ĐỒNG BỘ TCP
SYN RCVD
tin nhắn, đang xác nhận SYN
SYNbit=1, Seq=y
ACKbit=1; ACKnum=x+1
đã nhận được SYNACK(x)
cho biết máy chủ đang hoạt động;
ESTAB
gửi ACK cho ĐỒNG BỘ;
phân đoạn này có thể chứaACKbit=1, ACKnum=y+1
dữ liệu từ máy khách đến máy chủ
đã nhận được ACK(y)
cho biết khách hàng đang hoạt động
ESTAB

Giao thức bắt tay 3 chiều của con người
1. Đang chờ đợi?
2. Hãy chờ đợi.

3. Leo núi.

Đóng kết nối TCP
 máy khách, máy chủ đều đóng phía kết nối của họ
• gửi phân đoạn TCP với bit FIN = 1
 phản hồi FIN đã nhận bằng ACK
• khi nhận FIN, ACK có thể được kết hợp với FIN của chính mình
 trao đổi FIN đồng thời có thể được xử lý

cậy
vận chuyển
Nguyên tắc kiểm soát tắc nghẽn
Sự tắc nghẽn:
 một cách không chính thức: “ quá nhiều nguồn gửi quá nhiều dữ liệu
quá nhanh để mạng có thể xử lý”
 biểu hiện:
• độ trễ dài (xếp hàng trong bộ đệm của bộ định tuyến)
• mất gói (tràn bộ đệm tại bộ định tuyến)
 khác với điều khiển dòng chảy! kiểm soát tắc
 một vấn đề top 10! nghẽn: quá nhiều
người gửi, gửi quá nhanh
kiểm soát luồng: một

người gửi quá nhanh đối với
một người nhận
Nguyên nhân/chi phí tắc nghẽn: kịch bản 1
dữ liệu gốc: l trong thông lượng:
Kịch bản đơn giản nhất: tôi ra ngoài
Máy
 một bộ định tuyến, bộ đệm chủ A
vô hạn bộ đệm liên kết
đầu ra được chia
 Công suấtchảy
hai dòng liên kết đầu vào, sẻ vô hạn
đầu ra: R R R
 không cần truyền lại
Máy
chủ B
tôi ra ngoài
R/2
Q: Điều gì xảy ra khi
trì hoãn
tỷ lệ đến l ở tiến
thông lượng:
tới R/2?
tôi ở trongR/2 tôi ở trongR/2
thông lượng tối đa trên mỗi kết độ trễ lớn như dòng tỷ lệ
nối: R/2 đến tiếp cận năng lực
 một bộ định tuyến, bộ đệm hữu hạn
 người gửi truyền lại gói bị mất, hết thời gian chờ
• Đầu vào của lớp ứng dụng = Đầu ra của lớp ứng dụng: l in = l out
• Đầu vào của lớp vận chuyển bao gồm các lần truyền lại : l ' in tôi ở
trong
Máy chủ tôi ở trong : dữ liệu

A tôi
gốc ' trong : dữ liệu gốc, tôi
cộng với dữ liệu được ra
truyền lại ngoài
R R
bộ đệm liên kết đầu ra
Máy chủ
được chia sẻ hữu
B
hạn Lớp vận chuyển: 3-112
Lý tưởng hóa: kiến thức hoàn hảo
ra ngoài
R/2
 người gửi chỉ gửi khi có bộ đệm của bộ định tuyến
tôi
thông lượng:
Máy chủ tôi ở trong : dữ liệu tôi ở trong
A sao chép tôi
gốc ' trong : dữ liệu gốc, tôi R/2
cộng với dữ liệu được ra
truyền lại ngoài
không gian đệm miễn phí!
R R
Máy chủ
B
Lý tưởng hóa: một số kiến thức hoàn
hảo
 các gói có thể bị mất (rơi vào bộ định tuyến) do
bộ đệm đầy
 người gửi biết khi nào gói bị mất: chỉ gửi lại nếu
gói bị mất
Máy chủ tôi ở trong : dữ liệu
A sao chép tôi
gốc ' trong : dữ liệu gốc,
cộng với dữ liệu được
truyền lại
không có không gian đệm!
R R
Máy chủ
B
Lý tưởng hóa: một số kiến thức hoàn
ra ngoài
R/2
Dung lượng “lãng phí”
hảo do truyền lại
tôi
 các gói có thể bị mất (rơi vào bộ định tuyến) do
thông lượng:
khi gửi ở R/2, một
bộ đệm đầy số gói cần được
 người gửi biết khi nào gói bị mất: chỉ gửi lại nếu truyền lại
gói bị mất
Máy chủ tôi ở trong : dữ liệu tôi ở trong R/2
A tôi
truyền lại
R R
Máy chủ
B
Kịch bản thực tế: không cần thiết trùng
ra ngoài
R/2
lặp Dung lượng “lãng phí”
do truyền lại không
tôi
 các gói có thể bị mất, bị rơi tại bộ định tuyến do cần thiết
thông lượng:
bộ đệm đầy – yêu cầu truyền lại
 nhưng thời gian gửi có thể hết thời gian sớm, số gói được truyền
gửi hai bản sao, cả hai đều được chuyển giao lại, bao gồm cả các
bản sao cần thiết và
Máy chủ tôi ở trong : dữ liệu tôi ở trong
không cần thiết , đã
R/2 được phân phối!
A hsao
ết giờchép
tôi
truyền lại
R R
Máy chủ
B
Kịch bản thực tế: không cần thiết trùng
ra ngoài
R/2
lặp Dung lượng “lãng phí”
do truyền lại không
tôi
 các gói có thể bị mất, bị rơi tại bộ định tuyến do cần thiết
thông lượng:
bộ đệm đầy – yêu cầu truyền lại
 nhưng thời gian gửi có thể hết thời gian sớm, số gói được truyền
gửi hai bản sao, cả hai đều được chuyển giao lại, bao gồm cả các
bản sao cần thiết và
không cần thiết , đã
tôi ở trong R/2 được phân phối!
“chi phí” của tắc nghẽn:

 nhiều công việc hơn (truyền lại) cho thông lượng máy thu nhất định
 truyền lại không cần thiết: liên kết mang nhiều bản sao của một gói
• giảm thông lượng tối đa có thể đạt được

 bốn người gửi Hỏi: chuyện gì xảy ra khi tôi ở trong Và tôi ở '
 đường dẫn nhiều bước nhảy tăng ?
MỘT: như màu đỏ l trong ' tăng lên, tất cả các gói màu
 hết thời gian/truyền lại xanh đến ở hàng đợi trên sẽ bị loại bỏ, thông lượng
màu xanh g 0
Máy tôi ở trong : dữ liệu
chủ A Máy
tôi
gốc '
trong : dữ liệu gốc, chủ B
bộ đệmtruyền
liênlạikết
đầu ra được chia
sẻ hữu hạn
Máy
chủ D
tôi
Máy
ra chủ C
ngoài

R/2
tôi
ngoài
ra
tôi ở ' R/2
một “ chi phí” khác của tắc nghẽn:

 khi gói bị rớt, mọi dung lượng truyền tải ngược dòng và bộ
đệm được sử dụng cho gói đó đều bị lãng phí!

Nguyên nhân/chi phí tắc nghẽn: hiểu biết sâu sắc
 thông lượng không bao giờ có thể vượt
quá khả năng
 độ trễ tăng lên khi công suất tiếp cận
 mất/truyền lại làm giảm thông lượng

hiệu quả
 các bản sao không cần thiết càng làm giảm

thông lượng hiệu quả
 dung lượng truyền tải ngược dòng/bộ đệm
bị lãng phí do các gói bị mất ở hạ lưu
Các phương pháp tiếp cận kiểm soát tắc nghẽn
nghẽn cuối cùng:

 không có phản hồi rõ ràng từ
mạng
 tắc nghẽn được suy ra từ sự ACK
dữ liệu dữ liệu
ACK
mất mát, độ trễ quan sát được
 cách tiếp cận được thực hiện bởi TCP

Các phương pháp tiếp cận kiểm soát tắc nghẽn
Kiểm soát tắc nghẽn được hỗ

trợ bởi mạng: thông tin tắc nghẽn rõ ràng
 bộ định tuyến cung cấp phản hồi
trực tiếp đến các máy chủ dữ liệu dữ liệu
ACK
gửi/nhận với các luồng đi qua bộ ACK
định tuyến bị tắc nghẽn

 có thể chỉ ra mức độ tắc nghẽn
hoặc đặt tốc độ gửi rõ ràng
 Giao thức TCP ECN, ATM, DECbit
cậy
vận chuyển
Kiểm soát tắc nghẽn TCP: AIMD
 Cách tiếp cận: người gửi có thể tăng tốc độ gửi cho đến khi xảy ra
mất gói (tắc nghẽn), sau đó giảm tốc độ gửi khi mất gói
Một chất phụ gia D siêu nhân tăng
tôi tăng
tăng tốc độ gửi thêm 1 kích giảm một nửa tốc độ gửi ở
thước phân đoạn tối đa cho mỗi mỗi sự kiện mất mát
RTT cho đến khi phát hiện mất
dữ liệu
răng cưa AIMD

Người gửi TCP Tốc độ
hành vi: thăm dò

cho băng thông
gửi
thời gian Lớp vận chuyển: 3-124

TCP AIMD: thêm
giảm theo cấp số nhân : tốc độ gửi là
 Giảm một nửa tổn thất được phát hiện bởi ACK trùng lặp ba lần
(TCP Reno)
 Cắt thành 1 MSS (kích thước phân đoạn tối đa) khi phát hiện
mất dữ liệu khi hết thời gian chờ (TCP Tahoe)
Tại sao A I M D ?
 AIMD – một thuật toán phân tán, không đồng bộ – đã được
chứng minh là:
• tối ưu hóa tốc độ dòng chảy tắc nghẽn trên toàn mạng!
• có đặc tính ổn định mong muốn

Kiểm soát tắc nghẽn TCP: chi tiết
không gian số thứ tự của người gửi
cwnd Hành vi gửi TCP:
 đại khái: gửi byte cwnd , đợi
RTT cho ACKS, sau đó gửi
thêm byte
byte cuối cùng
đã xác nhận đã gửi nhưng có sẵn nhưng
tốc độ TCP~~ cwnd byte/giây
chưa được ACK không được sử RTT
(“ trên chuyến bytedụng
cuối cùng
bay”) được gửi
 Người gửi TCP giới hạn việc truyền tải:

LastByteSent- LastByteAcked < cwnd
 cwnd được điều chỉnh linh hoạt để đáp ứng với tình trạng tắc
nghẽn mạng được quan sát (thực hiện kiểm soát tắc nghẽn
TCP)
TCP khởi động chậm
 khi kết nối bắt đầu, hãy
tăng tốc độ theo cấp số
nhân cho đến khi xảy ra sự
một đoạn
RTT
kiện mất kết nối đầu tiên: hai ph â n đ
oạn
• ban đầu cwnd = 1 MSS
• nhân đôi số tiền mỗi RTT
bốn ph ân
• được thực hiện bằng cách đ oạn
tăngtắt:
 tóm cwnd choban
tốc độ mỗi đầu
ACK
nhận được
chậm, nhưng tăng nhanh
theo cấp số nhân thời gian

TCP: từ khởi đầu chậm đến tránh tắc nghẽn
Hỏi: khi nào thì sự gia tăng theo cấp
số nhân nên chuyển sang tuyến
tính? X
Đáp: khi cwnd đạt 1/2 giá trị trước
khi hết thời gian chờ.
Thực hiện:
 biến ssthresh
 trong trường hợp thua lỗ, ssthresh
được đặt thành 1/2 cwnd ngay trước
sự kiện mất mát
Tóm tắt: Kiểm soát tắc nghẽn TCP
Mới
Mới ACK!
ACK! ACK mới
ACK trùng lặp
dupACKcount++ ACK mới .
cwnd = cwnd + MSS (MSS/cwnd)
dupACKcount = 0
cwnd = cwnd+MSS truyền (các) phân đoạn mới, nếu được phép
dupACKcount = 0
L truyền (các) phân đoạn mới, nếu được phép
cwnd = 1 MSS
ssthresh = 64 KB cwnd > ssthresh
dupACKcount = 0
chậm L sự tắc nghẽn
bắt đầu hết giờ tránh né
ssthresh = cwnd/2
cwnd = 1 MSS ACK trùng lặp
hết giờ dupACKcount = 0 dupACKcount++
ssthresh = cwnd/2 truyền lại đoạn bị thiếu
cwnd = 1 MSS
dupACKcount = 0
truyền lại đoạn bị thiếu
hết giờ
Mới
ACK!
ssthresh = cwnd/2
cwnd = 1 ACK mới
dupACKcount = 0
cwnd = ssthresh dupACKcount == 3
dupACKcount == 3 truyền lại đoạn bị thiếu dupACKcount = 0
ssthresh=cwnd/2 ssthresh=cwnd/2
cwnd = ssthresh + 3 cwnd = ssthresh + 3
nhanh
sự hồi phục
ACK trùng lặp
cwnd = cwnd + MSS
truyền (các) phân đoạn mới, nếu được phép

TCP CUBIC
 Có cách nào tốt hơn AIMD để “thăm dò” băng thông có thể sử dụng
 được không?
Cái nhìn sâu sắc/trực giác:
• W max : tốc độ gửi tại đó phát hiện mất mát tắc nghẽn
• tình trạng tắc nghẽn liên kết cổ chai có lẽ (?) chưa thay đổi nhiều
• sau khi cắt giảm một nửa tốc độ/cửa sổ do mất mát, ban đầu tăng dần lên mức W
tối đa nhanh hơn , nhưng sau đó tiếp cận W max chậm hơn
W tối đa TCP cổ điển
TCP CUBIC - thông

W /2 lượng cao hơn trong
tối đa
ví dụ này

TCP CUBIC
 K: thời điểm khi kích thước cửa sổ TCP đạt W max
• Bản thân K có thể điều chỉnh được
 tăng W như là một hàm của lập phương khoảng cách giữa thời gian hiện
tại và K
• tăng lớn hơn khi ở xa K hơn
• tăng nhỏ hơn (thận trọng) khi gần K hơn
 TCP CUBIC mặc W tối đa
định trong Linux,
TCP Reno
TCP phổ biến nhất TCP CUBIC
cho các máy chủ TCP
gửi
Web phổ biến tỷ lệ
thời gian
t0 t1 t2 t3 t4
TCP và “liên kết thắt cổ chai” bị tắc nghẽn
 TCP (cổ điển, CUBIC) tăng tốc độ gửi của TCP cho đến khi xảy ra mất gói
ở đầu ra của một số bộ định tuyến: liên kết thắt cổ chai
nguồn điểm đến

TCP TCP
mạng mạng
thuộc vật thuộc vật
hàng đợi gói hầu như chất chất
không bao giờ trống, đôi
khi tràn gói (mất)
liên kết thắt cổ chai (hầu như luôn bận)

TCP và “liên kết thắt cổ chai” bị tắc nghẽn
 TCP (cổ điển, CUBIC) tăng tốc độ gửi của TCP cho đến khi xảy ra mất gói
ở đầu ra của một số bộ định tuyến: liên kết thắt cổ chai
 hiểu tắc nghẽn: hữu ích để tập trung vào liên kết tắc nghẽn tắc nghẽn
cái nhìn sâu sắc: tăng tốc độ gửi TCP sẽ

nguồn không tăng end-end trong suốt tình điểm đến
trạng tắc nghẽn
TCP TCP
mạng mạng
chất chất
cái nhìn sâu sắc: tăng tốc độ
gửi TCP sẽ tăng RTT đo
được
Mục tiêu: “giữ cho đường ống đầu cuối vừa đầy, nhưng k
RTT đầy hơn”
Kiểm soát
Giữ đường truyền từ người gửi đến người nhận “vừa đủ, nhưng không đầy
hơn”: giữ cho liên kết nút cổ chai bận rộn truyền tải, nhưng tránh độ trễ/bộ
nhớ đệm cao
# byte được gửi
đo trong khoảng
RTT đo được thông lượng = thời gian RTT
RTTcùng
cuối đo được
Cách tiếp cận dựa trên độ trễ:
 RTT tối thiểu - RTT được quan sát tối thiểu (đường dẫn không tắc nghẽn)
 thông lượng không bị tắc nghẽn với cửa sổ tắc nghẽn cwnd là cwnd/RTT phút
nếu thông lượng đo được “rất gần” với thông lượng không bị tắc
nghẽn
tăng cwnd tuyến tính /* vì đường dẫn không bị tắc nghẽn */
ngược lại nếu thông lượng đo được “thấp hơn nhiều” không bị tắc
nghẽn trong suốt Lớp vận chuyển: 3-134
Kiểm soát
 kiểm soát tắc nghẽn mà không gây ra/ép buộc mất mát
 tối đa hóa xuyên suốt (“giữ cho đường ống vừa đầy…” ) trong khi vẫn giữ
độ trễ ở mức thấp (“…nhưng không đầy hơn”)
 một số TCP được triển khai thực hiện cách tiếp cận dựa trên độ trễ
 BBR được triển khai trên mạng đường trục (nội bộ) của Google

Thông báo tắc nghẽn rõ ràng (ECN)
Việc triển khai TCP thường thực hiện kiểm soát tắc nghẽn được mạng hỗ trợ :
 hai bit trong tiêu đề IP (trường ToS) được đánh dấu bởi bộ định tuyến mạng để chỉ tắc nghẽn
• chính sách để xác định việc đánh dấu do nhà điều hành mạng chọn
 chỉ báo tắc nghẽn được vận chuyển đến đích
 đích đặt bit ECE trên phân đoạn ACK để thông báo cho người gửi về tình trạng tắc nghẽn
 liên quan đến cả IP (đánh dấu bit ECN tiêu đề IP) và TCP (đánh dấu bit tiêu đề TCP C,E)
nguồn Phân đoạn TCP ACK

điểm đến
ECE= 1
TCP TCP
mạng mạng
chất chất
ECN=10 ECN= 11
Gói dữ liệu IP
TCP công bằng
Mục tiêu công bằng: nếu K phiên TCP chia sẻ cùng một liên kết thắt cổ
chai của băng thông R thì mỗi phiên phải có tốc độ trung bình là R/K
Kết nối TCP 1
nút cổ chai
Kết nối TCP 2 bộ định tuyến
công suất R

Hỏi: TCP có công bằng không?
Ví dụ: hai phiên TCP cạnh tranh:
 sự gia tăng cộng gộp cho độ dốc bằng 1, vì sự gia tăng xuyên suốt
 giảm nhân làm giảm thông lượng tương ứng
R chia sẻ băng thông bằng nhau

có công bằng không?
Đáp: Có, theo những giả
Thông lượng kết nối 2
mất: giảm cửa sổ theo hệ số 2 định lý tưởng hóa:

tránh tắc nghẽn: tăng phụ gia  cùng RTT
mất: giảm cửa sổ theo hệ số 2
tránh tắc nghẽn: tăng phụ gia
 số phiên cố định chỉ để
tránh tắc nghẽn
Thông lượng kết nối 1 R

Công bằng: tất cả các ứng dụng mạng phải “công bằng”?
Sự công bằng và UDP Tính công bằng, kết nối TCP
 các ứng dụng đa phương tiện song song
thường không sử dụng TCP  ứng dụng có thể mở nhiều kết nối
• không muốn tốc độ được điều song song giữa hai máy chủ
chỉnh bởi kiểm soát tắc nghẽn
 các trình duyệt web thực hiện việc
 thay vào đó hãy sử dụng UDP: này, ví dụ link tốc độ R với 9 kết
• gửi âm thanh/video ở tốc độ nối hiện có:
không đổi, chấp nhận mất gói • ứng dụng mới yêu cầu 1 TCP, đạt tỷ lệ
 không có cảnh sát Internet nào R/10
sử dụng chính sách kiểm soát • ứng dụng mới yêu cầu 11 TCP, nhận
tắc nghẽn được R/2

Lớp vận chuyển: lộ trình
cậy
vận chuyển
Phát triển chức năng của lớp vận chuyển
 TCP, UDP: giao thức truyền tải chính trong 40 năm
 “hương vị” khác nhau của TCP được phát triển cho các tình huống cụ thể:
Kịch bản Thử thách
Ống dài, dày (truyền dữ liệu Nhiều gói “đang bay”; mất mát đóng cửa
lớn) đường ống
Mạng không dây Mất mát do liên kết không dây ồn ào, tính
di động; TCP coi đây là mất mát do tắc
nghẽn
Liên kết có độ trễ dài RTT cực dài
Mạng trung tâm dữ liệu Độ trễ nhạy cảm
Luồng lưu lượng truy cập nền Các luồng TCP “nền” có mức độ ưu tiên
thấp
 di chuyển các chức năng của lớp vận chuyển sang lớp ứng dụng, phía trên UDP
• HTTP/3: QUIC
QUIC: Kết nối Internet UDP nhanh
 giao thức lớp ứng dụng, trên UDP
• tăng hiệu suất của HTTP
• được triển khai trên nhiều máy chủ, ứng dụng của Google (Chrome, ứng dụng
YouTube dành cho thiết bị di động)
HTTP/2 HTTP/2 (rút gọn)

Ứng dụng HTTP/3
TLS NHANH
Chuyên TCP UDP

chở
Mạng IP IP
HTTP/2 qua TCP HTTP/2 qua QUIC qua UDP

QUIC: Kết nối Internet UDP nhanh
áp dụng các phương pháp chúng tôi đã nghiên cứu trong chương
này để thiết lập kết nối, kiểm soát lỗi, kiểm soát tắc nghẽn
• kiểm soát lỗi và tắc nghẽn: “Người đọc quen với tính năng phát hiện
mất mát và kiểm soát tắc nghẽn của TCP sẽ tìm thấy các thuật toán ở
đây tương đương với các thuật toán TCP nổi tiếng.” [từ đặc điểm kỹ thuật QUIC]
• thiết lập kết nối: độ tin cậy, kiểm soát tắc nghẽn, xác thực, mã hóa,
trạng thái được thiết lập trong một RTT
 nhiều “luồng” cấp ứng dụng được ghép kênh trên một kết nối QUIC
• truyền dữ liệu đáng tin cậy riêng biệt, bảo mật
• Kiểm soát tắc nghẽn chung

QUIC: Thiết lập kết nối
Bắt tay TCP

(lớp vận chuyển) Bắt tay NHANH CHÓNG
dữ liệu
Bắt tay TLS
(bảo vệ)
dữ liệu
TCP (độ tin cậy, trạng thái kiểm soát QUIC: độ tin cậy, kiểm soát tắc
tắc nghẽn) + TLS (xác thực, trạng thái nghẽn, xác thực, trạng thái mật mã
mật mã)
 1 cái bắt tay
 2 cái bắt tay nối tiếp

QUIC: luồng: song song, không chặn HOL
HTTP HTTP
LẤY LẤY HTTP
LẤY
ứng dụng
HTTP HTTP
LẤY LẤY
HTTP
LẤY NHAN NHAN NHAN NHAN NHAN NHAN
H H
mã hóa mã hóa
H H H H
mã hóa mã hóa mã hóa
mã hóa mã hóa NHANHNHANHNHANH NHANHNHANH mã hóa
NHANH
RDT RDT RDT lỗi!
RDT RDT RDT
QUIC Công. Tiếp. QUIC Công. Tiếp.

chuyên chở
TCP RDT TCP

lỗi! RDT
TCP Công. Ngược TCP Công. Ngược UDP UDP

lại lại
(a) HTTP 1.1 (b) HTTP/2 với QUIC: không chặn HOL
Chương 3: tóm tắt
 nguyên tắc đằng sau các dịch Tiếp theo:
vụ của lớp vận chuyển:  rời khỏi mạng “cạnh”
• ghép kênh, phân kênh (ứng dụng, lớp vận chuyển)
• truyền dữ liệu đáng tin cậy  vào mạng “ lõi”
 hai chương lớp mạng :
• mặt phẳng dữ liệu
 khởi tạo, triển khai trên • mặt phẳng điều khiển
Internet
• UDP
• TCP

Các slide bổ sung của Chương 3

Go-Back-N: FSM mở rộng của người gửi
if (nextseqnum < base+N) {
sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum)
udt_send(sndpkt[nextseqnum])
nếu (cơ sở == nextseqnum)
số tiếp theo++
}
L khác
từ chối_data(dữ liệu)
cơ sở=1
nextseqnum=1
hết giờ
Chờ udt_send(sndpkt[base])
rdt_rcv(rcvpkt) đợi udt_send(sndpkt[base+1])
&& bị hỏng(rcvpkt) …
udt_send(sndpkt[nextseqnum-
1])
rdt_rcv(rcvpkt) &&
không bị hỏng(rcvpkt)
cơ số = getacknum(rcvpkt)+1
Nếu (cơ sở == nextseqnum)
stop_timer
khác
Go-Back-N: FSM mở rộng của bộ thu
bất kỳ sự kiện nào
khác
udt_send(sndpkt) rdt_rcv(rcvpkt)
&& không bị hỏng(rcvpkt)
L && hasseqnum(rcvpkt,expectedseqnum)
dự kiếnseqnum=1 Chờ trích xuất (rcvpkt, dữ liệu)
sndpkt = đợi cung cấp_data(dữ liệu)
make_pkt(expectedseqnum,ACK,chksum) sndpkt = make_pkt(expectedseqnum,ACK,chksum)
udt_send(sndpkt)
dự kiếnseqnum++
Chỉ ACK: luôn gửi ACK cho gói được nhận chính xác có số thứ tự cao
nhất
• có thể tạo ra các ACK trùng lặp
• chỉ cần nhớ số dự kiến
 gói không theo thứ tự:
• loại bỏ (không đệm): không có bộ đệm máy thu!
• gói lại ACK có số thứ tự cao nhất Lớp vận chuyển: 3-149
Người gửi TCP (đơn giản hóa)
dữ liệu nhận được từ ứng dụng trên
tạo phân đoạn, seq. #: NextSeqNum
chuyển phân đoạn tới IP (tức là “ gửi ” )
NextSeqNum = NextSeqNum + độ dài (dữ liệu)
if (bộ đếm thời gian hiện không chạy)
L bắt đầu hẹn giờ
NextSeqNum = Ban đầuSeqNum Chờ đợi
SendBase = Khởi tạoSeqNum vì
sự kiện hết giờ
truyền lại đoạn chưa được ACK với
seq nhỏ nhất. #
bắt đầu hẹn giờ
Đã nhận được ACK, với giá trị trường ACK y
if (y > SendBase) {
SendBase = y
/* SendBase–1: byte được ACK tích lũy cuối cùng */
if (hiện tại có các phân đoạn chưa được ack)
bắt đầu hẹn giờ
nếu không thì dừng hẹn giờ
}
FSM bắt tay 3 bước TCP
đóng cửa
Kết nối ổ cắmSocket =
WelcomeSocket.accept();
L Ổ cắm clientSocket =
newSocket("tên máy chủ","số cổng");
SYN(x)
ĐỒNG BỘ(seq=y,ACKnum=x+1) SYN(seq=x)
tạo ổ cắm mới để liên lạc lại với khách
hàng
Nghe
SYN
SYN đã gửi
rcvd
ĐỒNG BỘ(seq=y,ACKnum=x+1)
ESTAB
ACK(ACKnum=y+1) ACK(ACKnum=y+1)
L

Đóng kết nối TCP
trạng thái khách hàng trạng thái máy chủ
ESTAB ESTAB
clientSocket.close()
FIN_WAIT_1 không thể dài FINbit=1, seq=x
hơn
gửi nhưng có CLOSE_WAIT
thể ACKbit=1; ACKnum=x+1
nhậnmáy
dữ chủ
liệu có thể còn
FIN_WAIT_2 chờ gửi dữ liệu
đóng
LAST_ACK
FINbit=1, seq=y
TIMED_WAIT không thể dài hơn
gửi dữ liệu
ACKbit=1; ACKnum=y+1
hẹn giờ chờ đợi
cho tối đa 2* ĐÓNG CỬA
vòng đời phân khúc
ĐÓNG CỬA

Thông lượng TCP
 trung bình Thông lượng TCP là chức năng của kích thước cửa sổ, RTT?
• bỏ qua khởi động chậm, giả sử luôn có dữ liệu để gửi
 W: kích thước cửa sổ (được đo bằng byte) nơi xảy ra mất mát
• trung bình kích thước cửa sổ (# byte trong chuyến bay) là ¾ W
• trung bình công suất là 3/4W mỗi RTT
3 W
thông lượng TCP trung bình = byte/giây
4 RTT
W
có/2
TCP qua “ ống dài và béo”
 ví dụ: phân đoạn 1500 byte, RTT 100ms, muốn thông lượng 10 Gbps
 yêu cầu W = 83.333 phân đoạn trên chuyến bay
 thông lượng xét về xác suất mất phân đoạn, L [Mathis 1997]:
1,22 . MSS
Thông lượng TCP =
RTT L
➜ để đạt thông lượng 10 Gbps cần tỷ lệ tổn thất L = 2 · 10 -10 – tỷ lệ tổn
thất rất nhỏ!
 các phiên bản TCP cho các kịch bản dài, tốc độ cao

Chapter 3 v8.2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 3 v8.2

Uploaded by

Copyright:

Available Formats

Chương 3

Lớp vận chuyển

Lớp vận chuyển: 3-2

trình ứng dụng chạy trên các máy liệu

 hai giao thức truyền tải có sẵn cho mạng

các ứng dụng Internet

sự tương tự của hộ gia đình:

Lớp vận chuyển: 3-5

sự tương tự của hộ gia đình:

Lớp vận chuyển: 3-6

đề phân đoạn tin

thuộc vật chất thuộc vật

Lớp vận chuyển: 3-7

liên kết dụng thông qua socket liên kết

thuộc vật chất thuộc vật

Lớp vận chuyển: 3-8

 dịch vụ không có sẵn: chở

Lớp vận chuyển: 3-9

ứng dụng P1 P2 ứng dụng ổ cắm

Lớp vận chuyển: 3-11

Lớp vận chuyển: 3-13

khử ghép kênh

khử ghép kênh

máy chủ: IP nguồn, cổng: B,80 máy chủ:

Lớp vận chuyển: 3-27

Lớp vận chuyển: 3-30

Lớp vận chuyển: 3-31

ứng dụng khách SNMP máy chủ SNMP

ứng dụng ứng dụng

chuyên chở chuyên

liên kết liên kết

thuộc vật chất thuộc vật

Lớp vận chuyển: 3-32

ứng dụng khách SNMP máy chủ SNMP

thuộc vật chất thuộc vật

Lớp vận chuyển: 3-33

ứng dụng khách SNMP máy chủ SNMP

thuộc vật chất thuộc vật

Lớp vận chuyển: 3-34

ứng dụng độ dài, tính bằng

dữ liệu đến/từ lớp

Lớp vận chuyển: 3-35

máy thu tính toán

Lớp vận chuyển: 3-36

Lớp vận chuyển: 3-39

quá trình quá trình

trừu tượng hóa dịch vụ

Lớp vận chuyển: 3-42

quá trình quá trình quá trình quá trình

triển khai dịch vụ đáng tin cậy

Lớp vận chuyển: 3-43

quá trình quá trình

phía người gửi phía người nhận

phụ thuộc (rất nhiều) vào đặc chuyên chở

quá trình quá trình

phía người gửi phía người nhận

đã nhận được tin nhắn chưa? chuyên chở

Lớp vận chuyển: 3-45

phía người gửi dữ liệu phía người nhận

udt_send() tiêu đề dữ tiêu đề dữ rdt_rcv()

 riêng biệt cho người gửi, người nhận:

Chờ cuộc rdt_send(dữ liệu) Chờ cuộc rdt_rcv(gói)

Lớp vận chuyển: 3-48