ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN

CHƯƠNG 3
TẦNG VẬN CHUYỂN
NHẬP MÔN MẠNG MÁY TÍNH

Thực hiện bởi Trường Đại học Công nghệ Thông tin, ĐHQG-HCM
1
A note on the use of these PowerPoint slides:
We’re making these slides freely available to all (faculty, students,
readers). They’re in PowerPoint form so you see the animations;
and can add, modify, and delete slides (including this one) and
slide content to suit your needs. They obviously represent a lot of
work on our part. In return for use, we only ask the following:

▪ If you use these slides (e.g., in a class) that you mention their
source (after all, we’d like people to use our book!)
▪ If you post any slides on a www site, that you note that they
are adapted from (or perhaps identical to) our slides, and note
our copyright of this material.

For a revision history, see the slide note for this page.

Thanks and enjoy! JFK/KWR

All material copyright 1996-2020

J.F Kurose and K.W. Ross, All Rights Reserved Computer Networking:
A Top-Down Approach
8th edition
Jim Kurose, Keith Ross
Pearson, 2020
 Tổng quan
Mục đích:
▪ Hiểu được các nguyên
tắc/cơ chế hoạt động:
• multiplexing, demultiplexing
• reliable data transfer
• flow control
• congestion control
▪ Hiểu các giao thức:
• UDP: connectionless
transport
• TCP: connection-oriented
reliable transport
• TCP congestion control

3
 Nội dung
oCác dịch vụ tầng vận chuyển
oMultiplexing and demultiplexing
oUDP
oNguyên lý truyền tin cậy
oTCP
oTCP - Điều khiển tắc nghẽn
oSự phát triển của các tính năng của tầng vận chuyển

4
 Giao thức và dịch vụ
o Cung cấp “truyền thông luận lý application
transport

(logical communication)” giữa các mobile network

network
data link
physical

tiến trình trên các “host” khác nhau national or global ISP

o Các giao thức vận chuyển hoạt

động trên các thiết bị đầu cuối:
• Bên gửi: chia các “messages – thông local or
regional ISP
điệp” thành các “segments” và chuyển
xuống tầng mạng. home network content
provider
• Bên nhận: ghép các segment thành network datacenter
application
transport
network

messages, chuyển đến tầng ứng dụng. network

data link
physical

o 2 giao thức chính: TCP và UDP enterprise

network

5
 Hoạt động của tầng vận chuyển

Bên gửi:
application ▪ Nhận message từ tầng ứng application
app. msg
dụng (nhận thư)
transport ▪ Xác định giá trị header TThhtransport
app. msg
(thông tin phong bì)
network (IP) ▪ Tạo segment (bỏ thư vào network (IP)
phong bì) link
link
▪ Chuyển segment đến physical
physical
tầng mạng

6
 Transport Layer Actions
Bên nhận:
▪ Nhận segment từ tầng
application mạng application

▪ Kiểm tra giá trị header

transport
app. msg transport
▪ Bỏ header, trích xuất
network (IP) thông điệp của tầng ứng network (IP)
dụng link
link
▪ Chuyển thông điệp đến physical
physical tầng ứng dụng qua socket
Th app. msg

7
 Giao thức tầng vận chuyển
oTCP: Transmission Control Protocol application
transport

▪ Tin cậy, vận chuyển đúng thứ tự mobile network

network
data link
physical
▪ Điều khiển tắc nghẽn national or global ISP

▪ Điều khiển luồng

▪ Thiết lập kết nối
oUDP: User Datagram Protocol
▪ Không tin cậy, truyền nhận không local or
regional ISP
đúng thứ tự
▪ Phần mở rộng của giao thức IP home network content
provider
“best-effort” network datacenter
application

oKhông cung cấp các dịch vụ sau:

network
transport
network

▪ Đảm bảo độ trễ

data link
physical

▪ Đảm bảo băng thông enterprise

network

8
 Nội dung
oCác dịch vụ tầng vận chuyển
oMultiplexing and demultiplexing
oUDP
oNguyên lý truyền tin cậy
oTCP
oTCP - Điều khiển tắc nghẽn
oSự phát triển của các tính năng của tầng vận chuyển

9
 HTTP server
client
application application
HTTP msg
transport

transport network transport

network link network
link physical link
physical physical

10
 HTTP server
client
application application
HTTP msg
transport
Ht HTTP msg

transport network transport

network link network
link physical link
physical physical

11
 HTTP server
client
application application
HTTP msg
transport
Ht HTTP msg

Hnnetwork
Ht HTTP msg transport
transport
network link network
link physical link
physical physical

12
 HTTP server
client
application application

transport

transport network transport

network link network
link physical link
physical physical

Hn Ht HTTP msg

13
 HTTP server
client
application application
HTTP msg
transport
Ht HTTP msg

transport network transport

Hn Hnetwork
t HTTP msg
link network
link physical link
physical physical

14
 HTTP server
client
application application
HTTP msg
transport
Ht HTTP msg

Htransport
t HTTP msg
network transport
network link network
link physical link
physical physical

15
 Q: Làm thế nào mà tầng vận chuyển biết gửi đúng message
tới trình duyệt Firefox thay vì Netflix hoặc Skype?

client
application application
HTTP msg
HTTP msg transport
Ht HTTP msg

transport network transport

network link network
link physical link
physical physical

16
 Multiplexing/demultiplexing

multiplexing tại bên gửi: demultiplexing tại bên nhận:

Nhận dữ liệu từ socket, thêm Sử dụng thông tin trong header
header của tầng vận chuyển để chuyển segment nhận được
đến đúng socket.

application

application P1 P2 application socket

P3 transport P4
process
transport network transport
network link network
link physical link
physical physical

17
 Demultiplexing làm việc thế nào?
o Khi host nhận được một IP
“datagram”
32 bits
▪ Mỗi datagram có địa chỉ IP nguồn và IP source port # dest port #
đích
▪ Mỗi datagram này chứa 1 segment (đơn other header fields
vị dữ liệu của tầng vận chuyển)
o Mỗi segment có port nguồn và port application
đich data
(payload)
▪ “Host” dùng địa chỉ IP & port numbers để
chuyển segment đến đúng socket tương
ứng TCP/UDP segment format

18
 Ví dụ về “connectionless - không kết nối”
mySocket =
socket(AF_INET,SOCK_DGRAM)
mySocket.bind(myaddr,6428);
mySocket = mySocket =
socket(AF_INET,SOCK_STREAM) socket(AF_INET,SOCK_STREAM)
mySocket.bind(myaddr,9157); mySocket.bind(myaddr,5775);
application
application application
P1
P3 P4
transport
transport transport
network
network link network
link physical link
physical physical

B D
source port: 6428 source port: ?
dest port: 9157 dest port: ?

A C
source port: 9157 source port: ?
dest port: 6428 dest port: ?

19
 Hướng kết nối
o TCP socket được xác định o Server có thể hỗ trợ nhiều
bởi 4-tuple (4 thông tin TCP socket cùng lúc:
chính): : ▪ Mỗi socket được xác định bởi 4
▪ source IP address thông tin
▪ source port number ▪ Mỗi socket tương ứng với một
client đang kết nối với nó
▪ dest IP address
▪ dest port number
o demux: bên nhận sử dụng cả
4 thông tin chính để chuyển
segment đến đúng socket

20
 Ví dụ về “hướng kết nối”

application
application P4 P5 P6 application
P1 P2 P3
transport
transport transport
network
network link network
link physical link
physical server: IP physical
address B

host: IP source IP,port: B,80 host: IP

address A dest IP,port: A,9157 source IP,port: C,5775 address C
dest IP,port: B,80
source IP,port: A,9157
dest IP, port: B,80
source IP,port: C,9157
dest IP,port: B,80
Three segments, all destined to IP address: B,
dest port: 80 are demultiplexed to different sockets
21
 Tổng kết về Multiplexing, demultiplexing
o Multiplexing, demultiplexing: dựa trên giá trị trong header của
segment, datagram
▪ UDP: demultiplexing chỉ sử dụng destination port number
▪ TCP: demultiplexing sử dụng 4 thông tin: source and destination IP
addresses, and port numbers
o Multiplexing/demultiplexing hoạt động ở tất cả các tầng

22
 Nội dung
oCác dịch vụ tầng vận chuyển
oMultiplexing and demultiplexing
oUDP
oNguyên lý truyền tin cậy
oTCP
oTCP - Điều khiển tắc nghẽn
oSự phát triển của các tính năng của tầng vận chuyển

23
 UDP: User Datagram Protocol
o Một giao thức đơn giản
o Cung cấp dịch vụ “best effort”
▪ Segment có thể mất
▪ Segment có thể đến không đúng
thứ tự
o “connectionless”:
▪ Không có bước thiết lập kết nối
▪ Mỗi segment được xử lý độc
lập
24
Tại sao vẫn dùng UDP?
o Không có bước thiết lập kết
nối (bước này làm tăng độ
trễ)
o Đơn giản: không lưu trữ
trạng thái kết nối
o Header nhỏ gọn
o Không điều khiển tắc nghẽn
▪ Segment đi nhanh nhất có
thể
 UDP: User Datagram Protocol
o UDP được sử dụng bởi:
▪ streaming multimedia apps (loss tolerant, rate sensitive)
▪ DNS
▪ SNMP
▪ HTTP/3
o Nếu cần truyền tin cậy qua UDP(e.g., HTTP/3):
▪ Thêm xử lý tin cậy ở tầng ứng dụng
▪ Thêm điều khiển tắc nghẽn ở tầng ứng dụng

25
 UDP: User Datagram Protocol [RFC 768]

26
 UDP: Hoạt động

SNMP client SNMP server

application application

transport transport
(UDP) (UDP)

network (IP) network (IP)

link link

physical physical

27
 UDP: Hoạt động

Bên gửi: SNMP server

SNMP client
application ▪ Nhận message từ tầng application
SNMP msg
ứng dụng
transport transport
▪ Xác định giá trị header UDP
UDPhh SNMP msg
(UDP) (UDP)
▪ Tạo segment network (IP)
network (IP)
link ▪ Chuyển segment đến link
tầng mạng physical
physical

28
 UDP: Hoạt động

Bên nhận:
SNMP client SNMP server
▪ Nhận segment từ tầng
application mạng application
▪ Kiểm tra lỗi với giá trị transport
transport checksum
SNMP msg
(UDP) (UDP)
▪ Bỏ header, lấy
network
UDP h SNMP(IP)
msg messages network (IP)

link ▪ Chuyển message đến link

physical tầng ứng dụng qua physical

socket

29
 UDP header

32 bits
source port # dest port #
length checksum

application length, chiều dài tính

data theo byte của segment,
(payload) bao gồm cả header

UDP segment format Dữ liệu tầng ứng dụng

30
 UDP checksum

Mục tiêu: phát hiện lỗi trong quá trình truyền (các bit bị lỗi, từ 0 thành 1 hoặc
ngược lại)
1st number 2nd number sum

Gửi: 5 6 11

Nhận: 4 6 11

receiver-computed sender-computed
checksum
= checksum (as received)

31
 Internet checksum
o Mục tiêu: phát hiện lỗi trong quá trình truyền (các bit bị lỗi, từ 0 thành
1 hoặc ngược lại)
sender:
oChia nội dung của segment
(bao gồm các trường tiêu
đề UDP và địa chỉ IP) dưới
dạng chuỗi 16 bit
ochecksum: Tính tổng bù 1
(one’s complement sum)
oĐặt kết quả vào phần UDP
checksum trong header
32
receiver:
oTính checksum của segment nhận
được
oSo sánh kết quả tính được và nội
dung phần checksum
▪ Không bằng nhau – có lỗi
▪ Bằng nhau – không phát hiện lỗi.
Tuy nhiên….
 Internet checksum: ví dụ
o Ví dụ: cộng 2 chuỗi 16-bit

1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

sum 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
checksum 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

Note: nếu kết quả là 17 bits, lấy bit cuối cùng bên trái cộng vào kết quả.

33
 Internet checksum: điểm yếu!
o Ví dụ: cộng 2 chuỗi 16-bit
0 1
1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 0
1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 Khi có 2 bit bị
thay đổi,
sum 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 checksum không
thay đổi
checksum 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

34
 Tổng kết: UDP
o Giao thức đơn giản:
▪ Segment có thể bị mất, sai thứ tự
▪ “Best-effort”: gửi và hy vọng có kết quả tốt nhất
o UDP vẫn có điểm cộng:
▪ Không có quá trình thiết lập kết nối
▪ Có checksum để kiểm tra lỗi
o Các tính năng bổ sung thì đưa lên tầng ứng dụng (e.g., HTTP/3)

35
 Nội dung
oCác dịch vụ tầng vận chuyển
oMultiplexing and demultiplexing
oUDP
oNguyên lý truyền tin cậy
oTCP
oTCP - Điều khiển tắc nghẽn
oSự phát triển của các tính năng của tầng vận chuyển

36
 Nguyên lý truyền tin cậy

sending receiving
process process
application data data
transport
reliable channel

Tổng quát dịch vụ truyền tin cậy

37
 Principles of reliable data transfer

sending receiving sending receiving

process process process process
application data data application data data
transport transport
reliable channel
sender-side of receiver-side
reliable service abstraction reliable data of reliable data
transfer protocol transfer protocol

transport
network
unreliable channel

Triển khai cụ thể của dịch vụ truyền tin cậy

38
 Principles of reliable data transfer

sending receiving
process process
application data data
transport

sender-side of receiver-side
Độ phức tạp của giao thức reliable data of reliable data
transfer protocol transfer protocol
truyền dữ liệu đáng tin cậy sẽ
phụ thuộc (mạnh mẽ) vào các transport
đặc điểm của kênh không đáng network
unreliable channel
tin cậy (mất, hỏng, sắp xếp lại dữ
liệu?) Triển khai cụ thể của dịch vụ truyền tin cậy

39
 Principles of reliable data transfer

sending receiving
process process
application data data
transport

sender-side of receiver-side
o Bên gửi, bên nhận không biết reliable data of reliable data
transfer protocol transfer protocol
“trạng thái” của nhau, ví dụ: đã
nhận được thông điệp chưa? transport
▪ trừ khi được liên lạc qua network
unreliable channel
các thông điệp

Triển khai cụ thể của dịch vụ truyền tin cậy

40
 Reliable data transfer protocol (rdt): interfaces

rdt_send(): được gọi bởi tầng ứng

deliver_data(): được gọi bởi rdt để
dụng). Chuyển dữ liệu cần truyền
chuyển dữ liệu đến tầng cao hơn
đến tầng Ứng dụng bên nhận

sending receiving
process process
rdt_send() data data
deliver_data()

sender-side data receiver-side

implementation of implementation of
rdt reliable data packet rdt reliable data
transfer protocol transfer protocol
udt_send() Header data Header data rdt_rcv()

udt_send(): được gọi bởi rdt,
để truyền các gói trên kênh
không tin cậy đến nơi nhận
41
unreliable channel
rdt_rcv(): được gọi khi gói dữ
Bi-directional communication over liệu đến kênh của bên nhận
unreliable channel
 Truyền dữ liệu tin cậy: bắt đầu
Chúng ta sẽ:
o Từng bước phát triển truyền dữ liệu tin cậy (rdt) bên phía người gửi và
nhận
o Chỉ xem xét việc truyền dữ liệu theo một chiều (bên gửi đến bên nhận)
o Sử dụng finite state machines (FSM) để xác định bên gửi và nhận
Sự kiện gây chuyển trạng thái
Các hành động được thực hiện khi
chuyển trạng thái
Trạng thái: khi ở “trạng
thái” này thì trạng trạng
trạng
thái kế tiếp được xác thái Sự kiện thái 2
định duy nhất bởi sự 1
Các hành động
kiện kế tiếp

42
 Tổng quan

RDT1.0
RDT2.0
RDT2.1
RDT2.2
RDT3.0
43
 Truyền dữ liệu tin cậy

• Kênh truyền tin cậy hoàn

RDT1.0 toàn

44
 rdt1.0 - Truyền dữ liệu tin cậy hoàn toàn

chờ gọi rdt_send(data) chờ gọi rdt_rcv(packet)

từ tầng từ tầng extract (packet,data)
trên packet = make_pkt(data) dưới deliver_data(data)
udt_send(packet)

bên gửi bên nhận

45
 Truyền dữ liệu tin cậy

• Kênh truyền tin cậy hoàn

RDT1.0 toàn

RDT2.0 • Vấn đề: Kênh truyền có lỗi

46
 rdt2.0: Kênh truyền xảy ra lỗi
o Kênh cơ bản có thể đảo các bit trong packet
▪ checksum để kiểm tra các lỗi
o Câu hỏi: làm sao khôi phục các lỗi:
▪ acknowledgements (ACKs): bên nhận báo bên gửi là gói tin đã được
nhận thành công.
▪ negative acknowledgements (NAKs): bên nhận báo bên gửi là gói tin đã
bị lỗi
▪ Bên gửi sẽ gửi lại gói tin nếu nhận được NAK
o Cơ chế mới trong rdt2.0:
▪ Phát hiện lỗi
▪ Phản hồi từ bên nhận: ACK,NAK từ bên nhận gửi lại cho bên gửi

Làm thế nào để con người phục hồi

“lỗi” trong cuộc trò chuyện?
47
 rdt2.0: Kênh truyền xảy ra lỗi

bên gửi bên nhận

Gửi pkt pkt
Nhận pkt
ack Gửi ack
Nhận ack
Gửi pkt pkt
Nhận pkt, pkt lỗi
nak Gửi nak
Nhận nak
Gửi lại pkt pkt
Nhận pkt
ack Gửi ack

48
 rdt2.0: hoạt động khi không lỗi
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Chờ gọi Chờ ACK rdt_rcv(rcvpkt) &&
từ tầng hoặc udt_send(sndpkt) corrupt(rcvpkt)
trên NAK
udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Chờ gọi
L từ tầng
dưới

rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)

49
 rdt2.0: hoạt động khi có lỗi
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Chờ gọi Chờ ACK rdt_rcv(rcvpkt) &&
từ tầng hoặc udt_send(sndpkt) corrupt(rcvpkt)
trên NAK
udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Chờ gọi
L từ tầng
dưới

rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)

50
 Truyền dữ liệu tin cậy
• Kênh truyền tin cậy hoàn
RDT1.0 toàn

• Vấn đề: Kênh truyền có lỗi

RDT2.0 • Giải quyết: ACK và NAK

RDT2.1 • Vấn đề: ACK/NAK lỗi

51
 rdt2.0 có lỗ hổng nghiêm trọng!

a b c a a b
Trùng
bên gửi bên nhận
Gửi pkt a
Nhận pkt
Nhận ack, ack lỗi ack Gửi ack
Gửi lại pkt a
Nhận pkt
ack Gửi ack
Nhận ack
Gửi pkt b
Nhận pkt
ack Gửi ack

52
 rdt2.1 bên gửi, xử lý các ACK/NAK bị hỏng

a b c a ab Trùng

bên gửi bên nhận

Gửi pkt0 pkt0
Nhận pkt0
ack0 Gửi ack0
Nhận ack0, ack0 lỗi
Gửi lại pkt0 pkt0
Nhận pkt0
ack0 Gửi ack0
Nhận ack0
Gửi pkt1 pkt1
Nhận pkt1
ack1 Gửi ack1

53
 rdt2.1 bên gửi, xử lý các ACK/NAK bị hỏng

a b c a a b a b c a ab

bên gửi bên nhận bên gửi bên nhận

Gửi pkt Gửi pkt0 pkt0
a
Nhận pkt Nhận pkt0
Gửi ack ack0 Gửi ack0
Nhận ack, ack lỗi ack Nhận ack0, ack0 lỗi
Gửi lại pkt a Gửi lại pkt0 pkt0
Nhận pkt0
Nhận pkt
Gửi ack ack0 Gửi ack0
Nhận ack
ack Nhận ack0
Gửi pkt b Gửi pkt1 pkt1
Nhận pkt1
Nhận pkt
ack Gửi ack ack1 Gửi ack1

54
 Truyền dữ liệu tin cậy

RDT1.0 • Kênh truyền tin cậy hoàn toàn

• Vấn đề: Kênh truyền có lỗi

RDT2.0 • Giải quyết: ACK và NAK

• Vấn đề: ACK/NAK lỗi

RDT2.1 • Giải quyết: Đánh số gói tin {0,1}

RDT2.2

57
 rdt2.2: một giao thức không cần NAK
o Chức năng giống như rdt2.1, chỉ dùng các ACK
o Thay cho NAK, bên nhận gởi ACK cho gói cuối cùng được nhận
thành công
▪ Bên nhận phải ghi rõ số thứ tự của gói vừa được ACK
o ACK bị trùng tại bên gửi dẫn tới kết quả giống như hành động
của NAK: truyền lại gói vừa rồi

58
 rdt2.2: một giao thức không cần NAK

bên gửi bên nhận

Gửi pkt0 pkt0 bên gửi bên nhận
Nhận pkt0
Gửi pkt0 pkt0
ack0 Gửi ack0 Nhận pkt0
Nhận ack0
Gửi pkt1 pkt1 ack0 Gửi ack0
Nhận pkt1, pkt1 lỗi Nhận ack0
nak1 Gửi ack1 Gửi pkt1 pkt1 Nhận pkt1, pkt1 lỗi
Nhận nak1
Gửi pkt1 pkt1 ack0 Gửi ack0
Nhận pkt1 Nhận ack0
ack1 Gửi ack1 Gửi pkt1 pkt1
Nhận pkt1
ack1 Gửi ack1

59
 rdt2.2: các phần bên nhận và gửi
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
Wait for Wait for
ACK isACK(rcvpkt,1) )
call 0 from
above 0 udt_send(sndpkt)
sender FSM
fragment rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && && isACK(rcvpkt,0)
(corrupt(rcvpkt) || L
has_seq1(rcvpkt)) Wait for receiver FSM
0 from
udt_send(sndpkt) below fragment
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK1, chksum)
udt_send(sndpkt)
60
 Truyền dữ liệu tin cậy

RDT1.0 • Kênh truyền tin cậy hoàn toàn

• Vấn đề: Kênh truyền có lỗi

RDT2.0 • Giải quyết: ACK và NAK

• Vấn đề: ACK/NAK lỗi

RDT2.1 • Giải quyết: Đánh số gói tin {0,1}

RDT2.2 • Không cần NAK

RDT3. • Vấn đề: Mất gói tin

0
61
 rdt3.0: các kênh với lỗi và mất mát
Cách tiếp cận: bên gửi chờ ACK Giả định mới: kênh truyền cũng
trong khoảng thời gian “hợp lý” có thể làm mất gói (dữ liệu,
oTruyền lại nếu không nhận các ACK)
được ACK trong khoảng thời ▪ checksum, số thứ tự, các ACK,
gian này việc truyền lại sẽ hỗ trợ… nhưng
oNếu gói (hoặc ACK) chỉ trễ không đủ
(không mất):
▪ Việc truyền lại sẽ gây trùng,
nhưng số thứ tự đã xử lý trường
hợp này
▪ Bên nhận phải xác định số thứ tự
của gói vừa gửi ACK
oYêu cầu bộ định thì (timer)

62
 Hoạt động của rdt3.0

bên gửi bên nhận bên gửi bên nhận

Gửi pkt0 pkt0 Gửi pkt0 pkt0
Nhận pkt0 Nhận pkt0
ack0 Gửi ack0 ack0 Gửi ack0
Nhận ack0 Nhận ack0
Gửi pkt1 pkt1 Nhận pkt1 pkt1
Nhận pkt1 X
ack1 Nhận ack1 loss
Nhận ack1
Nhận pkt0 pkt0
Gửi pkt0 timeout
ack0 Nhận ack0 Gửi lại pkt1 pkt1
Nhận pkt1
ack1 Gửi ack1
Nhận ack1
Gửi pkt0 pkt0
(a) Không mất mát Nhận pkt0
ack0 Gửi ack0

(b) Mất gói

63
 Hoạt động của rdt3.0
bên gửi bên nhận
bên gửi bên nhận Gửi pkt0 pkt0
Gửi pkt0 pkt0 Nhận pkt0
Gửi ack0
Nhận pkt0 ack0
Gửi ack0 Nhận ack0
ack0 Gửi pkt1 pkt1
Nhận ack0 Nhận pkt1
Gửi pkt1 pkt1
Gửi ack1
Nhận pkt1 ack1
ack1 Gửi ack1
X
loss timeout
resend pkt1 pkt1
Nhận pkt1
timeout
Gửi lại pkt1 pkt1 rcv ack1 (phát hiện trùng)
Nhận pkt1 send pkt0
pkt0
Gửi ack1
(phát hiện trùng gói) ack1
ack1 Gửi ack1 rcv ack1 Nhận pkt0
Nhận ack1 send pkt0
ack0 Gửi ack0
Gửi pkt0 pkt0 pkt0
Nhận pkt0
Nhận pkt0 ack0 (phát hiện trùng)
ack0 Gửi ack0 Gửi ack0

(c) Mất ACK (d) Thời gian chờ quá ngắn / delayed ACK

64
 Tổng kết về Truyền dữ liệu tin cậy
• Kênh truyền tin cậy hoàn
RDT1.0 toàn

• Vấn đề: Kênh truyền có lỗi

RDT2.0 • Giải quyết: ACK và NAK
• Vấn đề: ACK/NAK lỗi
RDT2.1 • Giải quyết: Đánh số gói tin
{0,1}

RDT2.2 • Không cần NAK

• Vấn đề: Mất gói tin

RDT3.0 • Giải quyết: Thêm biến timer

65
 Hiệu suất của rdt3.0 (stop-and-wait)

o U sender: utilization – tỉ lệ thời gian truyền của bên gửi

o Ví dụ: 1 Gbps link, truyền một gói tin 8000 bit trên kênh truyền
có độ trễ lan truyền 15 ms

• Thời gian truyền gói tin đến kênh truyền:

L 8000 bits
Dtrans = R = 9 = 8 microsecs
10 bits/sec

66
 rdt3.0: hoạt động stop-and-wait
sender receiver
first packet bit transmitted, t = 0

first packet bit arrives

RTT last packet bit arrives, send ACK

ACK arrives, send next

packet, t = RTT + L / R

67
 rdt3.0: hoạt động stop-and-wait
sender receiver

L/R L/R
Usender=
RTT + L / R
.008 RTT
=
30.008
= 0.00027

o Hiệu suất giao thức rdt 3.0 kém

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

68
 rdt3.0: hoạt động giao thức “pipelined”
pipelining: bên gửi gửi nhiều packet cùng một lúc mà không cần
chờ ACK
▪ Dãy số thứ tự phải được tăng lên
▪ Đưa vào bộ đệm tại bên gửi hoặc bên nhận

69
 Pipelining: tăng hiệu suất
sender receiver
first packet bit transmitted, t = 0
last bit transmitted, t = L / R

first packet bit arrives

RTT last packet bit arrives, send ACK
last bit of 2nd packet arrives, send ACK
last bit of 3rd packet arrives, send ACK
ACK arrives, send next
packet, t = RTT + L / R
Gửi 3 gói tin cùng lúc
thì hiệu suất tăng 3 lần!

U 3L / R .0024
sender = = = 0.00081
RTT + L / R 30.008

70
 Go-Back-N: bên gửi
o Bên gửi: gửi tối đa N packets liên tiếp mà không cần chờ ACK
(“window”)
▪ k-bit seq # in pkt header

▪ Khi nhận ACK(n) => ACK cho tất cả các packet đã gửi tính tới gói tin có
seq là n (cumulative ACK – ACK tích lũy)
▪ Tính timer cho packet gửi sớm nhất nhưng chưa được ACK
▪ timeout(n): gửi lại tất cả các packet trong “window” từ vị trí (n)
71
 Go-Back-N: bên nhận
o Nhận packet đúng thứ tự: gửi ACK tương ứng với packet đúng thứ tự có
STT cao nhất
o Nhận packet không đúng thứ tụ:
▪ Có thể hủy hoặc đưa vào buffer: tùy vào cách triển khai
▪ Gửi lại ACK tương ứng với packet đúng thứ tự có số TT cao nhất

Receiver view of sequence number space:

received and ACKed

… … Out-of-order: received but not ACKed

rcv_base
Not received

72
 Go-Back-N: các hành động
sender window (N=4) sender receiver
012345678 send pkt0
012345678 send pkt1
012345678 send pkt2 receive pkt0, send ack0
012345678 send pkt3 Xloss receive pkt1, send ack1
(wait)
receive pkt3, discard,
012345678 rcv ack0, send pkt4 (re)send ack1
012345678 rcv ack1, send pkt5 receive pkt4, discard,
(re)send ack1
ignore duplicate ACK receive pkt5, discard,
(re)send ack1
pkt 2 timeout
012345678 send pkt2
012345678 send pkt3
012345678 send pkt4 rcv pkt2, deliver, send ack2
012345678 send pkt5 rcv pkt3, deliver, send ack3
rcv pkt4, deliver, send ack4
rcv pkt5, deliver, send ack5

73
 Go-Back-N in action

74
 Selective repeat
o Bên nhận gửi ACK cho từng packet nhận thành công (cơ chế buffer tại
bên gửi)
o Bên gửi bật cơ chế timeout/gửi lại các packet không được ACK
o Cơ chế window tại bên gửi
o Cho phép gửi liên tiếp N packet có số thứ tự tăng dần
o Giới hạn số packet được gửi nhưng không được ACKs

75
 Selective repeat

76
 Selective repeat: bên gửi và bên nhận
Bên gửi Bên nhận
Dữ liệu từ tầng trên: Gói tin trong [rcvbase, rcvbase+N-1]
▪ Nếu vẫn còn số TT trong window ▪ Gửi ACK(n)
thì gửi gói tin ▪ Không đúng thứ tụ: buffer

timeout(n): ▪ Đúng thứ tự: chuyển tiếp (cả các

packet được bufer) , dịch chuyển
▪ Gửi lại packet, thiết lập laim timer window lên vị trí kế tiếp
ACK(n) trong [sendbase,sendbase+N- Gói tin trong [rcvbase-N,rcvbase-1]
1]: ▪ ACK(n)

▪ Đánh dấu packet n được nhận

Khác:
▪ Loại bỏ
▪ Nếu n là nhỏ nhất trong các gói
tin không được ACK, dịch
chuyển window lên vị trí kế tiếp

77
 Selective Repeat: các hành động
sender window (N=4) sender receiver
012345678 send pkt0
012345678 send pkt1
012345678 send pkt2 receive pkt0, send ack0
012345678 send pkt3 Xloss receive pkt1, send ack1
(wait)
receive pkt3, buffer,
012345678 rcv ack0, send pkt4 send ack3
012345678 rcv ack1, send pkt5
receive pkt4, buffer,
record ack3 arrived send ack4
receive pkt5, buffer,
pkt 2 timeout send ack5
012345678 send pkt2
012345678 (but not 3,4,5)
012345678 rcv pkt2; deliver pkt2,
012345678 pkt3, pkt4, pkt5; send ack2

Q: what happens when ack2 arrives?

78
 Selective repeat: vấn đề
example:
▪ seq #s: 0, 1, 2, 3 (base 4 counting)
▪ window size=3

sender window receiver window 0123012 pkt0

(after receipt) (after receipt)
0123012 pkt1 0123012

0123012 pkt0 0123012 pkt2 X 0123012

0123012 pkt1 0123012 X 0123012

pkt2
X
0123012 0123012 timeout
0123012 retransmit pkt0
0123012 pkt3 0123012 pkt0
X will accept packet
0123012 with seq number 0
pkt0 will accept packet
with seq number 0

(b) oops!
(a) no problem

79
 Nội dung
oCác dịch vụ tầng vận chuyển
oMultiplexing and demultiplexing
oUDP
oNguyên lý truyền tin cậy
oTCP
oTCP - Điều khiển tắc nghẽn
oSự phát triển của các tính năng của tầng vận chuyển

81
 TCP: tổng quan RFCs: 793,1122, 2018, 5681, 7323

o point-to-point: o ACKs tích lũy

▪ 1 bên gửi, 1 bên nhận o Cơ chế pipelining:
o Tin cậy, dữ liệu đúng thứ ▪ Điều khiển tắc nghẽn và điều khiển
tự theo byte luồng với “window size”

o“full duplex data”: o Hướng kết nối:

▪ Luồng dữ liệu 2 chiều trong
cùng một kết nối
▪ MSS: maximum segment
size (độ dài tối đa của 1
segment)
▪ handshaking (trao đổi các thông điệp
thiết lập và đóng kết nối)
o “flow controlled”:
▪ Bên gửi không gửi nhiều làm quá tải
bên nhận

82
 Cấu trúc của TCP segment
32 bits

source port # dest port # segment seq #: counting

ACK: seq # of next expected sequence number bytes of data into bytestream
byte; A bit: this is an ACK (not segments!)
acknowledgement number
head not
length (of TCP header) len used C EUAP R SF receive window flow control: # bytes
Internet checksum checksum Urg data pointer receiver willing to accept

options (variable length)

C, E: congestion notification
TCP options
application data sent by
RST, SYN, FIN: connection data application into
management (variable length) TCP socket

83
 TCP: Reliable data transfer
oTruyền theo thứ tự: Sequence number, ACK
oTruyền lại:
▪ Segment lỗi: ACK
▪ Segment bị mất: timeout

84
 TCP sequence numbers, ACKs: ví dụ
o Thông điệp tầng ứng dụng: 9000 bytes (byte #0 -> byte #8999)
o Mỗi segment chứa tối đa 2000 bytes
o => 5 2000-byte segments
0->1999 2000->3999 4000->5999 6000->7999 8000->8999

Sender - Sequence number Receiver ACK

Seq = 0, length = 2000B I receive until #1999, I
ACK = 2000
You need byte want byte from #2000
from 2000, I’ll S = 2000, length = 2000B ACK = 4000
send you from
#2000 S = 4000, length = 2000B
ACK = 6000
S = 6000, length = 2000B
ACK = 8000
S = 8000, length = 1000B ACK = 9000

86
 TCP sequence numbers, ACKs

Host A Host B

Send 30B
Seq=42, ACK=79, data = 30B
host ACKs 30B, send 50B

Seq=79, ACK=72, data = 50B

host ACKs 50B
Seq=72, ACK=129

87
 TCP round trip time, timeout
Q: TCP xác định thời gian
timeout thế nào?
▪ Phải lâu hơn RTT, nhưng RTT
khác nhau sau mỗi lần gửi!
▪ Nếu quá ngắn: gửi lại không cần
thiết
▪ Nếu quá lâu: chậm phản ứng
với việc mất segment
88
Q: Làm thế nào để dự đoán
RTT?
▪ SampleRTT:đo thời gian truyền
segment cho đến khi nhận được
ACK
• Bỏ qua việc truyền lại
▪ SampleRTT sẽ khác nhau với
mỗi lần đo
• Tính trung bình nhiều lần đo chứ
không chỉ dựa vào lần đo hiện tại
 TCP round trip time, timeout
EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT
▪ Cơ chế EWMA: exponential weighted moving average
▪ Sự ảnh hưởng của các lần đo trước sẽ giảm theo 
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
▪ Giá trị tiêu biểu:  = 0.125 350

RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

RTT (milliseconds)
300

250

RTT (milliseconds)
200

sampleRTT
150

EstimatedRTT

100
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)
time (seconds)
SampleRTT Estimated RTT
89
 TCP round trip time, timeout

▪ Khoảng timeout: EstimatedRTT cộng với “safety margin” – biên độ an

toàn”

TimeoutInterval = EstimatedRTT + 4*DevRTT

estimated RTT “safety margin”

▪ DevRTT: EWMA of SampleRTT deviation from EstimatedRTT:

DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT|
(typically,  = 0.25)

* Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/
90
 TCP Sender (tinh giản)
Sự kiện: Nhận dữ liệu từ tầng
ứng dụng
oTạo segment với STT seq #
oseq #: STT của byte đầu
tiên trong segment
oBắt đầu tính thời gian với
segment cũ nhất
91
Sự kiện: timeout
o Gửi lại segment bị timeout
o Bắt đầu tính lại thời gian
Sự kiện: nhận được ACK
oNếu ACK xác nhận cho các
segment chưa được ACK
▪ Cập nhật trạng thái
▪ Tính lại thời gian với các
segment chưa được ACK
 TCP Receiver: ACK generation [RFC 5681]

Sự kiện tại bên nhận Hành động

Nhận được segment đúng với Chờ segment kế tiếp trong 500ms,
STT đang chờ. Tất cả segment nếu không nhận được thì sẽ ACK.
trước đó đã được ACK.

Nhận được segment đúng với Gửi ACK tích lũy để ACK cho 2
STT đang chờ, một segment segment.
chưa được ACK.

Nhận được segment không Gửi ACK trùng ngay lập tức, để chỉ
đúng thứ tự (STT cao hơn). cho bên gửi biết đang chờ segment
nào.

Nhận được segment trong ACK ngay lập tức cho segment có thứ
khoảng bị trống (giữa STT đang tự thấp nhất trong khoảng bị trống
chờ và STT nhận được trước
đó).
92
 TCP: các trường hợp truyền lại
Host A Host B Host A Host B

SendBase=92
Seq=92, 8 bytes of data Seq=92, 8 bytes of data

Seq=100, 20 bytes of data

timeout

timeout
ACK=100
X
ACK=100
ACK=120

Seq=92, 8 bytes of data Seq=92, 8

SendBase=100 bytes of data send cumulative
SendBase=120 ACK for 120
ACK=100
ACK=120

SendBase=120

Mất ACK timeout

93
 TCP: các trường hợp truyền lại
Host A Host B

Seq=92, 8 bytes of data

Seq=100, 20 bytes of data

ACK=100
X
ACK=120

Seq=120, 15 bytes of data

ACK tích lũy

94
 TCP: truyền lại nhanh
Host A Host B
TCP: truyền lại nhanh
Khi bên gửi nhận được 3 ACK
yêu cầu cùng segment, bên
gửi gửi lại segment được yêu
cầu mà không cần chờ X
timeout.

timeout
Việc nhận 3 ACK trùng lặp cho biết
đã nhận được 3 segment sau một Seq=100, 20 bytes of data
segment bị thiếu – có khả năng bị
mất phân đoạn.
=> Truyền lại!

95
 TCP: flow control – điều khiển luồng
application
Q: Điều gì xảy ra nếu tầng Application removing
process

mạng truyền dữ liệu nhanh data from TCP socket

buffers
hơn tầng ứng dụng xóa dữ TCP socket
liệu khỏi bộ đệm của socket? receiver buffers

TCP
code
Network layer
delivering IP datagram
payload into TCP
IP
socket buffers
code

from sender

receiver protocol stack

96
 TCP: điều khiển luồng
application
Q: Điều gì xảy ra nếu tầng Application removing
process

mạng truyền dữ liệu nhanh data from TCP socket

buffers
hơn tầng ứng dụng xóa dữ TCP socket
liệu khỏi bộ đệm của socket? receiver buffers

TCP
code

receive window
flow control: # bytes
receiver willing to accept IP
code

from sender

receiver protocol stack

97
 TCP: điều khiển luồng
application
Q: Điều gì xảy ra nếu tầng Application removing
process

mạng truyền dữ liệu nhanh data from TCP socket

buffers
hơn tầng ứng dụng xóa dữ TCP socket
liệu khỏi bộ đệm của socket? receiver buffers

TCP
code
flow control
bên nhận kiểm soát bên gửi, vì
vậy bên gửi sẽ không làm tràn IP
bộ đệm của bên nhận bằng cách code
truyền quá nhiều, quá nhanh
from sender

receiver protocol stack

98
 TCP: điều khiển luồng
o Bên gửi thông báo bộ đệm trống bằng thông tin rwnd trong TCP header
o Bên gửi giới hạn lượng dữ liệu được gửi khi nhận được rwnd để đảm bảo
bên nhận không bị quá tải to application process

RcvBuffer buffered data

rwnd free buffer space

TCP segment payloads

TCP receiver-side buffering

99
 TCP: điều khiển luồng
o Bên gửi thông báo bộ đệm trống bằng flow control: # bytes receiver willing to accept
thông tin rwnd trong TCP header
o Bên gửi giới hạn lượng dữ liệu được
gửi khi nhận được rwnd để đảm bảo
bên nhận không bị quá tải receive window

TCP segment format

100
 TCP: quản lý kết nối
o trước khi trao đổi dữ liệu, bên gửi/bên nhận “handshake – bắt tay”:
▪ đồng ý thiết lập kết nối (mỗi bên đều biết bên kia sẵn sàng thiết lập kết nối)
▪ đồng ý về các thông số kết nối (ví dụ: bắt đầu từ seq #s)

application application

connection state: ESTAB connection state: ESTAB

connection variables: connection Variables:
seq # client-to-server seq # client-to-server
server-to-client server-to-client
rcvBuffer size rcvBuffer size
at server,client at server,client

network network

Socket clientSocket = Socket connectionSocket =

newSocket("hostname","port number"); welcomeSocket.accept();
101
 TCP 3-way handshake: bắt tay 3 bước
Server state
serverSocket = socket(AF_INET,SOCK_STREAM)
Client state serverSocket.bind((‘’,serverPort))
serverSocket.listen(1)
clientSocket = socket(AF_INET, SOCK_STREAM) connectionSocket, addr = serverSocket.accept()
LISTEN
clientSocket.connect((serverName,serverPort)) LISTEN
choose init seq num, x
send TCP SYN msg
SYNSENT SYNbit=1, Seq=x
choose init seq num, y
send TCP SYNACK
msg, acking SYN SYN RCVD
SYNbit=1, Seq=y
ACKbit=1; ACKnum=x+1
received SYNACK(x)
ESTAB indicates server is live;
send ACK for SYNACK;
this segment may contain ACKbit=1, ACKnum=y+1
client-to-server data
received ACK(y)
indicates client is live
ESTAB

102
 Ví dụ thực tế

1. On belay?

2. Belay on.
3. Climbing.

107
 Đóng kết nối
o Client, server đóng kết nối cho mỗi bên
▪ Gửi TCP segment có FIN bit = 1
o Phản hồi khi nhận segment có FIN với ACK
o Khi nhận FIN, ACK có thể kết hợp với FIN của nó
▪ có thể xử lý các trao đổi FIN đồng thời

108
 Đóng kết nối

client state server state

ESTAB ESTAB
clientSocket.close()
FIN_WAIT_1 can no longer FINbit=1, seq=x
send but can
receive data CLOSE_WAIT
ACKbit=1; ACKnum=x+1
can still
FIN_WAIT_2 wait for server send data
close

LAST_ACK
FINbit=1, seq=y
TIMED_WAIT can no longer
send data
ACKbit=1; ACKnum=y+1
timed wait
for 2*max CLOSED
segment lifetime

CLOSED

109
 Nội dung
oCác dịch vụ tầng vận chuyển
oMultiplexing and demultiplexing
oUDP
oNguyên lý truyền tin cậy
oTCP
oTCP - Điều khiển tắc nghẽn
oSự phát triển của các tính năng của tầng vận chuyển

110
 Quản lý tắc nghẽn của TCP: AIMD
o Cách tiếp cận: bên gửi liên tục tăng tốc độ truyền cho đến khi việc mất gói
tin sảy ra (tắc nghẽn – congestion), sau đó giảm tốc độ truyền dựa trên sự
kiên mất.

Tăng cấp số cộng Giảm cấp số nhân

Tăng tốc độ gửi lên 1 MSS cho Giảm tốc độ gửi 1 nửa khi mất
đến khi phát hiện sự mất mát mát sảy ra t
TCP sender Sending rate

AIMD : thăm dò
băng thông

111 time
 TCP: Điều khiển tắc nghẽn
o Ký hiệu
▪ Cwnd(n) - congestion windows: số segment được gửi trong
cùng một window
▪ Ssthresh (slowstart threshold): ngưỡng kết thúc giai đoạn
slowstart và chuyển sang congestion avoidance

112
 TCP slow start
o khi bắt đầu, tăng tốc độ theo cấp số nhân Host A Host B
cho đến khi xảy ra sự kiện mất đầu tiên :
▪ Ban đầu cwnd = 1 MSS
▪ Nhân đôi cwnd sau mỗi RTT

RTT
▪ được thực hiện bằng cách tăng cwnd cho
mỗi ACK nhận được

Tóm tắt: tốc độ ban đầu

chậm, nhưng tăng nhanh theo
cấp số nhân time

113
 TCP: từ slow start đến congestion avoidance
o Q: khi nào nên tăng theo cấp số nhân chuyển sang tuyến tính?

oA:
▪ Ssthresh: ngưỡng kết thúc
Slowstart
▪ Khi sự kiện mất sảy ra,
ssthresh bằng 1/2 giá trị của
cwnd trước khi sảy ra mất mát

* Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/

114
 TCP: Điều khiển tắc nghẽn – Các giai đoạn

Congestion Fast
Slowstart
Avoidance Recovery
3ACK:
cwnd(n) = cwnd(n) =
cwnd(n)=
cwnd(n-1)x2 cwnd(n-1)+1
cwnd(n-1)/2+3

Timeout:
cwnd(n)=1

115
 TCP: Điều khiển tắc nghẽn – Chuyển giai đoạn

Slow Start

Receive 3
Cwnd>=ssthresh
duplicate
ACKs Timeout

Receive 3 duplicate ACKs Congestion Avoidance

Fast Recovery

Receive new ACK

116
 Tổng kết
New
New ACK!
ACK! new ACK
duplicate ACK
dupACKcount++ new ACK .
cwnd = cwnd + MSS (MSS/cwnd)
dupACKcount = 0
cwnd = cwnd+MSS transmit new segment(s), as allowed
dupACKcount = 0
L transmit new segment(s), as allowed
cwnd = 1 MSS
ssthresh = 64 KB cwnd > ssthresh
dupACKcount = 0
slow L congestion
start timeout avoidance
ssthresh = cwnd/2
cwnd = 1 MSS duplicate ACK
timeout dupACKcount = 0 dupACKcount++
ssthresh = cwnd/2 retransmit missing segment
cwnd = 1 MSS
dupACKcount = 0
retransmit missing segment New
timeout
ACK!
ssthresh = cwnd/2
cwnd = 1 New ACK
dupACKcount = 0
cwnd = ssthresh dupACKcount == 3
dupACKcount == 3 retransmit missing segment dupACKcount = 0
ssthresh= cwnd/2 ssthresh= cwnd/2
cwnd = ssthresh + 3 cwnd = ssthresh + 3
retransmit missing segment retransmit missing segment
fast
recovery
duplicate ACK
cwnd = cwnd + MSS
transmit new segment(s), as allowed

117
 Nội dung
oCác dịch vụ tầng vận chuyển
oMultiplexing and demultiplexing
oUDP
oNguyên lý truyền tin cậy
oTCP
oTCP - Điều khiển tắc nghẽn
oSự phát triển của các tính năng của tầng vận chuyển

118
 Evolving transport-layer functionality
o TCP, UDP: principal transport protocols for 40 years
o different “flavors” of TCP developed, for specific scenarios:

Scenario
Long, fat pipes (large data
transfers)
Wireless networks
Long-delay links
Data center networks
Background traffic flows
Challenges
Many packets “in flight”; loss shuts down
pipeline
Loss due to noisy wireless links, mobility;
TCP treat this as congestion loss
Extremely long RTTs
Latency sensitive
Low priority, “background” TCP flows

▪ moving transport–layer functions to application layer, on top of UDP

• HTTP/3: QUIC
119
 QUIC: Quick UDP Internet Connections
o application-layer protocol, on top of UDP
▪ increase performance of HTTP
▪ deployed on many Google servers, apps (Chrome, mobile YouTube
app)

HTTP/2 HTTP/2 (slimmed)

Application HTTP/3
TLS QUIC

Transport TCP UDP

Network IP IP

HTTP/2 over TCP HTTP/2 over QUIC over UDP

120
 QUIC: Quick UDP Internet Connections
o multiple application-level “streams” multiplexed over single QUIC
connection
▪ separate reliable data transfer, security
▪ common congestion control
• error and congestion control: “Readers familiar with TCP’s loss
detection and congestion control will find algorithms here that parallel
well-known TCP ones.” [from QUIC specification]
• connection establishment: reliability, congestion control,
authentication, encryption, state established in one RTT

adopts approaches we’ve studied in this chapter for

connection establishment, error control, congestion control

121
 QUIC: Connection establishment

TCP handshake
(transport layer) QUIC handshake

data
TLS handshake
(security)
data

TCP (reliability, congestion control QUIC: reliability, congestion control,

state) + TLS (authentication, crypto authentication, crypto state
state)
▪ 1 handshake
▪ 2 serial handshakes

122
 QUIC: streams: parallelism, no HOL blocking

HTTP HTTP
GET GET HTTP
GET
HTTP HTTP
application

GET GET
HTTP
GET QUIC QUIC QUIC QUIC QUIC QUIC
encrypt encrypt encrypt encrypt encrypt encrypt
QUIC QUIC QUIC QUIC QUIC QUIC
TLS encryption TLS encryption RDT RDT RDT RDT
error!
RDT RDT

QUIC Cong. Cont. QUIC Cong. Cont.

TCP RDT TCP
error! RDT
transport

TCP Cong. Contr. TCP Cong. Contr. UDP UDP

(a) HTTP 1.1 (b) HTTP/2 with QUIC: no HOL blocking

123
 Chương 3: Tổng kết
▪ Các nguyên lý của tầng vận Tiếp theo:
chuyển: ▪ Tầng network
• multiplexing, demultiplexing
• Truyền tin cậy
• Điều khiển luồng
• Điều khiển tắc nghẽn
• UDP
• TCP

124