CN2019 Chapter3 Transport Layer (VIE Final)

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

KHOA CÔNG NGHỆ THÔNG TIN
Môn học (3TC):

MẠNG MÁY TÍNH
Lớp INT 2209-4&5&6 (K62 CNTT)
Chương 3 Lớp giao vận
PGS. TS. Nguyễn Đình Việt

Hà nội – 2019
Chapter 3
Transport Layer
A note on the use of these ppt slides:

We’re making these slides freely available to all (faculty, students, readers). Computer
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. Networking: A Top
They obviously represent a lot of work on our part. In return for use, we only
ask the following: Down Approach
 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!)
6th edition
 If you post any slides on a www site, that you note that they are adapted Jim Kurose, Keith Ross
from (or perhaps identical to) our slides, and note our copyright of this
material.
Addison-Wesley
March 2012
Thanks and enjoy! JFK/KWR
All material copyright 1996-2013

J.F Kurose and K.W. Ross, All Rights Reserved
3-2
Chương 3: Lớp giao vận (vận chuyển)
Mục tiêu nghiên cứu:

 Hiểu các nguyên tắc  Nắm vững các giao thức
đằng sau các dịch vụ giao vận Internet:
của lớp giao vận:  UDP: vận chuyển không
hướng nối (connectionless)
 Dồn kênh (multiplexing),
phân kênh (demultiplexing)  TCP: vận chuyển tin cậy và
hướng nối (connection-
 reliable data transfer
oriented)
 flow control
 Điều khiển tắc nghẽn của
 congestion control TCP (congestion control)
Mạng máy tính, Chương 3 Lớp giao vận, HK2 2018-2019. PGS. TS. Nguyễn Đình Việt 3-3
Chương 3: Các nội dung chính
3.1 Giới thiệu và các dịch vụ 3.5 Vận chuyển hướng kết nối:
lớp vận chuyển TCP
 3.1.1 Mối quan hệ giữa lớp  Cấu trúc của segment (gói tin
vận chuyển và lớp mạng tầng vận chuyển)
 3.1.2 Khái quát về lớp vận  Truyền dữ liệu tin cậy
chuyển của Internet  Điều khiển lưu lượng (flow
3.2 Dồn kênh và phân kênh control)
(multiplexing and  Quản lý kết nối (connection
demultiplexing) management)
3.3 Vận chuyển không hướng 3.6 Các nguyên tắc của điều khiển
nối: UDP tắc nghẽn
3.4 Các nguyên tắc của việc 3.7 Điều khiển tắc nghẽn của TCP
truyền dữ liệu tin cậy
3.1 Giới thiệu và các dịch vụ lớp vận chuyển
Các dịch vụ vận chuyển và giao thức
application
 Cung cấp sự truyền thông lô-gic transport
network
giữa các tiến trình ứng dụng data link
physical
chạy trên các host khác nhau
 Các giao thức vận chuyển chạy
trên các end systems
 Bên gửi: chia các bản tin của ứng
dụng thành các phân đoạn -
segments, rồi chuyển chúng xuống
lớp mạng
 Bên nhận: ghép các phân đoạn
thành các bản tin, rồi chuyển cho application
transport
lớp ứng dụng network
data link
 Có sẵn hơn một giao thức vận physical
chuyển dành cho các ứng dụng

 Internet: TCP và UDP
3.1.1 Mối quan hệ giữa lớp vận chuyển và lớp mạng
 Network layer: truyền Tương tự việc gia đình:

thông lô-gic giữa các 12 đứa trẻ nhà Ann gửi các
hosts bức thư cho 12 đứa trẻ của
nhà Bill:
 Transport layer:  Hosts = houses
truyền thông lô-gic  Processes = kids
giữa các tiến trình  App messages = các bức thư
 Dựa vào và nâng cao trong phong bì
các dịch vụ của lớp  Transport protocol = Ann và Bill,
những người chuyển và chia thư
mạng
cho những đứa trẻ trong mỗi gia
đình
 Network-layer protocol = dịch vụ
bưu điện
3-6
Mạng máy tính, Chương 3 Lớp giao vận, HK2 2018-2019. PGS. TS. Nguyễn Đình Việt
3.1.2 Khái quát về lớp vận chuyển của Internet
 TCP: Tin cậy, phân phát đúng thứ

application
tự (in-order delivery) transport
network
 Điều khiển tắc nghẽn (congestion data link
physical
control) network
network data link
 Điều khiển lưu lượng/luồng (flow data link
physical
physical
network
control) data link
physical
 Thiết lập kết nối (connection setup)
network
 UDP: không tin cậy (unreliable), data link
physical
phân phát không đúng thứ tự network
data link
(unordered delivery) physical
network
 Mở rộng không đáng kể dịch vụ vận data link
physical
application
transport
chuyển kiểu “cố gắng tối đa” của IP network
data link network
physical data link
(no-frills extension) physical
 Các dịch vụ không có:

 Đảm bảo (guarantees) về độ trễ
 Đảm bảo về dải thông
3.2 Dồn kênh và phân kênh  Cấu trúc của segment (gói tin
(multiplexing and tầng vận chuyển)
demultiplexing)  Truyền dữ liệu tin cậy
 Điều khiển lưu lượng (flow
3.3 Vận chuyển không hướng control)
nối: UDP  Quản lý kết nối (connection
3.4 Các nguyên tắc của việc management)
truyền dữ liệu tin cậy 3.6 Các nguyên tắc của điều khiển
tắc nghẽn
3.7 Điều khiển tắc nghẽn của TCP
3.2 Dồn kênh và phân kênh
Việc dồn kênh tại sender: Việc phân kênh tại receiver:
Xử lý (handle) dữ liệu từ nhiều Sử dụng thông tin của header để
sockets, bổ sung transport header (sẽ phân phát các segments nhận
được dùng cho việc phân kênh) được tới đúng socket
application
application P1 P2 application socket

P3 transport P4
process
transport network transport
network link network
link physical link
physical physical
… 3.2 Dồn kênh và phân kênh
Việc phân kênh thực hiện ntn
 Host nhận IP datagrams

32 bits
 Mỗi datagram có địa chỉ IP nguồn,
địa chỉ IP đích source port # dest port #
 Mỗi datagram mang một phân
đoạn (segment) của tầng vận other header fields
chuyển
 Mỗi segment có số cổng (port
number) của nguồn và đích application
 Host sử dụng các địa chỉ IP & data
(payload)
port numbers để gửi (direct)
segment tới socket thích hợp
TCP/UDP segment format
Việc phân kênh không hướng nối (Connectionless demultiplexing)
 Nhắc lại: socket được tạo ra  Nhắc lại: Khi tạo ra

có host-local port #: datagram để gửi vào UDP
DatagramSocket mySocket1 socket, phải chỉ rõ:
= new DatagramSocket(12534);  Địa chỉ IP đích
 Số cổng đích
 Khi host nhận được UDP Các IP datagrams có cùng

segment: dest. port #, nhưng địa chỉ
 Kiểm tra destination port IP nguồn khác nhau
# trong segment và/hoặc số cổng nguồn sẽ
được gửi (directed) đến
 Gửi UDP segment đến cùng socket tại đích
socket có số port # đó
Thí dụ về phân kênh không hướng nối
DatagramSocket
DatagramSocket serverSocket = new
DatagramSocket DatagramSocket
mySocket2 = new mySocket1 = new
DatagramSocket (6428); DatagramSocket
(9157); application
(5775);
application application
P1
P3 P4
transport
transport transport
network
link physical link
physical physical
source port: 6428 source port: ?

dest port: 9157 dest port: ?
source port: 9157 source port: ?

dest port: 6428 dest port: ?
Phân kênh hướng nối (Connection-oriented demux)
 TCP socket được chỉ rõ  Server host có thể hỗ trợ

bởi bộ 4 (4-tuple): nhiều TCP sockets đồng
 source IP address thời:
 source port number  Mỗi socket được chỉ rõ bởi
 dest IP address bộ 4 của riêng nó
 dest port number  Web servers có các
 Phân kênh (demux): sockets khác nhau cho
người nhận sử dụng tất mỗi client đang kết nối
cả 4 giá trị để gửi với nó
(direct) segment đến  HTTP không kiên trì (non-
persistent) sẽ có socket
socket thích hợp khác cho mỗi request
Thí dụ về phân kênh hướng nối (Connection-oriented demux)
application
application P4 P5 P6 application
P3 P2 P3
transport
transport transport
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
Ba segments, đều được gửi đến địa chỉ IP: B,
dest port: 80 chúng được phân kênh tới các socket khác nhau
… Thí dụ về phân kênh hướng nối (Connection-oriented demux)
threaded server
application
P4
P3 P2 P3
transport
transport transport
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
(Stop CT4, CT5, 27-28/3/2019 )
 3.3.1 Cấu trúc gói tin UDP management)
(UDP Segment Structure)
 3.3.2 Tổng kiểm tra UDP
3.6 Các nguyên tắc của điều khiển
(UDP Checksum) tắc nghẽn
3.4 Các nguyên tắc của việc 3.7 Điều khiển tắc nghẽn của TCP
3.3 Vận chuyển không hướng nối: UDP
Giao thức bản tin người dùng UDP (User Datagram Protocol [RFC 768])
 Là giao thức vận chuyển  Việc sử dụng UDP:

Internet đơn giản nhất (“bare  Cho các ứng dụng streaming
bones”), không có đặc điểm gì multimedia (thứ lỗi (loss
“đáng giá” tolerant), nhậy cảm với tốc độ)
 Cung cấp dịch vụ “best effort”,  DNS (Domain Name System):
UDP segments có thể bị:
hệ thống tên miền
 Mất (lost)
 SNMP (Simple Network
 Phân phát không đúng thứ tự
cho ứng dụng (app) Management Protocol): Giao
thức quản lý mạng đơn giản
 Không hướng nối
(connectionless):  Việc truyền tin cậy bằng UDP:
 Không có việc bắt tay  Bổ sung tính tin cậy tại lớp ứng
(handshaking) giữa các bên gửi dụng
và nhận UDP
 Khôi phục (vì có) lỗi bằng các
 Mỗi UDP segment được xử lý
(handled) độc lập với các ứng dụng chuyên dụng!
segment khác
3.3.1 Cấu trúc gói tin UDP (UDP Segment Structure)
UDP: segment header
length, in bytes of
32 bits UDP segment,
source port # dest port # including header
length checksum
Tại sao lại phải có UDP?
 Không cần thiết lập kết nối
application (làm tăng thêm trễ)
data  Đơn giản: không cần trạng
(payload) thái kết nối ở bên sender và
bên receiver
 Kích thước header nhỏ
 Không có điều khiển tắc
Khuôn dạng gói tin UDP nghẽn: UDP có thể tăng vọt
(UDP segment format) (tốc độ truyền) theo mong
muốn
3.3.2 Tổng kiểm tra UDP (UDP Checksum)
Mục đích (goal): phát hiện lỗi - “errors” (thí dụ: các bit bị lật 0
thành 1 hoặc ngược lại) trong segment được truyền
Sender: Receiver:
 Coi nội dung của  Tính checksum của segment
segment, bao gồm cả các nhận được
trường của header như
một dãy các số nguyên  Kiểm tra xem nếu checksum
16-bit nó tính được bằng giá trị
trong trường checksum:
 Checksum: cộng (one’s
complement sum) nội  NO – lỗi bị phát hiện
dung của segment  YES – không phát hiện ra
 Sender đưa giá trị lỗi. Tuy nhiên có thể vẫn
checksum vào trường có lỗi? More later ….
checksum của gói tin
UDP
… 3.3.2 Tổng kiểm tra UDP (UDP Checksum)
Thí dụ về Internet checksum
Thí dụ: cộng hai số 16 bit

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
sum 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
checksum 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
Chú ý: Khi cộng hai số, số nhớ (carryout) từ việc cộng các
bit bậc cao nhất cần được cộng vào kết quả (nghĩa là lại cộng
vào bit bậc 0 của kết quả)
3.4 Các nguyên tắc của việc management)
truyền dữ liệu tin cậy 3.6 Các nguyên tắc của điều khiển
 3.4.1 Việc xây dựng giao thức tắc nghẽn
truyền tin cậy
 3.4.2 Các giao thức truyền dữ
liệu tin cậy kiểu đường ống
 3.4.3 Go-Back-N (GBN)
 3.4.4 Phát lại có chọn lọc –
SR (Selective Repeat)
3.4 Các nguyên tắc của việc truyền dữ liệu tin cậy
 Là quan trọng đối với các lớp ứng dụng, vận chuyển và
liên kết (link)
 Trong danh sách Top-10 các chủ đề networking quan trọng!
 Các đặc tính của kênh không tin cậy sẽ quyết định (determine) độ phức tạp
của giao thức truyền dữ liệu tin cậy – rdt (reliable data transfer protocol)
… 3.4 Các nguyên tắc của việc truyền dữ liệu tin cậy
liên kết (link)
… 3.4 Các nguyên tắc của việc truyền dữ liệu tin cậy
liên kết (link)
Reliable data transfer: getting started
rdt_send(): được gọi từ bên trên, (thí deliver_data(): được gọi bởi rdt
dụ: bởi app.). Dữ liệu được chuyển đến để để phân phát dữ liệu đến lớp bên trên
phân phát tới lớp bên trên của receiver
send receive
side side
udt_send(): Được gọi bởi rdt, rdt_rcv(): được gọi khi packet đến bên
để truyền packet qua nhận (rcv-side) của kênh (channel)
Kênh không tin cậy đến receiver
3.4.1 Việc xây dựng giao thức truyền tin cậy
Reliable data transfer: getting started
Chúng ta sẽ:
 Phát triển dần dần bên sender, bên receiver của giao thức rdt (reliable data
transfer protocol)
 Chỉ xem xét (trường hợp) truyền dữ liệu theo một chiều
 Tuy nhiên, thông tin điều khiển sẽ đi theo cả hai chiều!
 Sử dụng máy trạng thái hữu hạn (FSM) để đặc tả sender, receiver
Sự kiện (event) gây ra
sự chuyển trạng thái (state)
Các hành động được thực hiện (actions taken)

khi có sự chuyển trạng thái
state: Khi ở “state” này,
state tiếp theo được xác state state
event
định một cách duy nhất 1 2
bởi sự kiện tiếp theo actions
3.4.1 Việc xây dựng giao thức truyền tin cậy
rdt1.0: reliable transfer over a perfectly reliable channel
 Kênh truyền bên dưới tin cậy hoàn toàn

 Không có lỗi bit (no bit errors)
 Không có sự mất mất gói tin (no loss of packets)
 Hai máy trạng thái hữu hạn FSMs cho sender, receiver:
 Sender gửi dữ liệu vào kênh truyền bên dưới
 Receiver đọc dữ liệu từ kênh truyền bên dưới
Wait for rdt_send(data) Wait for rdt_rcv(packet)

call from call from extract (packet,data)
above packet = make_pkt(data) below deliver_data(data)
udt_send(packet)
sender receiver
rdt2.0: Kênh truyền có lỗi bit
 Kênh truyền bên dưới có thể đảo (flip) các bits trong
packet
 checksum để phát hiện các lỗi bit
 Câu hỏi đặt ra là: Làm thế nào khôi phục được khỏi
lỗi:
Làm thế nào mà con người có thể khôi phục từ

(data bị) “errors” trong khi đang nói chuyện?
rdt2.0: channel with bit errors
 Kênh truyền bên dưới có thể đảo (flip) các bits trong
packet
 checksum để phát hiện các lỗi bit
 Câu hỏi đặt ra là: Làm thế nào khôi phục được khỏi
lỗi:
 Biên nhận (đúng) - acknowledgements (ACKs): receiver chỉ
ra một cách rõ ràng cho bên sender rằng pkt được nhận OK
 Biên nhận (sai) negative acknowledgements (NAKs):
receiver chỉ ra một cách rõ ràng cho bên sender rằng pkt có
errors
 Sender truyền lại pkt khi nhận được NAK
 Các cơ chế mới trong rdt2.0 (beyond rdt1.0):
 Phát hiện lỗi (error detection)
 Phản hồi (feedback): bên nhận gửi control msgs (ACK,
NAK) tới bên gửi
rdt2.0: đặc tả FSM
Giao thức với kênh truyền có lỗi
rdt_send(data)
sndpkt = make_pkt(data, checksum) receiver
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for Wait for rdt_rcv(rcvpkt) &&
call from ACK or udt_send(sndpkt) corrupt(rcvpkt)
above NAK
udt_send(NAK)
rdt_rcv(rcvpkt) && isACK(rcvpkt)

Wait for

call from
sender below
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
rdt2.0: operation with no errors
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
above NAK
udt_send(NAK)

Wait for
 call from
below
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
deliver_data(data)
udt_send(ACK)
rdt2.0: error scenario
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
above NAK
udt_send(NAK)

Wait for
 call from
below
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
deliver_data(data)
udt_send(ACK)
rdt2.0 có một thiếu sót chết người! (Stop CT4,5, 3, 4/4/2019)
Điều gì sẽ xảy ra nếu gói Xử lý (gói tin) lặp:

tin ACK/NAK bị hỏng  Sender phát lại pkt hiện
(corrupted)? thời nếu (gói) ACK/NAK
 Sender không biết điều gì bị hỏng
xảy ra tại receiver!  Sender thêm sequence
 Ngay việc phát lại cũng number vào mỗi pkt
không được: có thể phát  Receiver loại bỏ pkt lặp
lặp (packet)
stop and wait (S&W)

Sender gửi đi 1 packet,
rồi chờ phản hồi từ bên
nhận
rdt2.1: sender, handles garbled ACK/NAKs
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt) rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
Wait for Wait for
ACK or
isNAK(rcvpkt) )
call 0 from
NAK 0 udt_send(sndpkt)
above
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt) && notcorrupt(rcvpkt)
&& isACK(rcvpkt)


Wait for Wait for
ACK or call 1 from
rdt_rcv(rcvpkt) && NAK 1 above
isNAK(rcvpkt) ) rdt_send(data)
udt_send(sndpkt) sndpkt = make_pkt(1, data, checksum)

udt_send(sndpkt)
rdt2.1: receiver, handles garbled ACK/NAKs
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

&& has_seq0(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum) sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
Wait for Wait for
rdt_rcv(rcvpkt) && 0 from 1 from rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) && below below not corrupt(rcvpkt) &&
has_seq1(rcvpkt) has_seq0(rcvpkt)
sndpkt = make_pkt(ACK, chksum) sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
&& has_seq1(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt2.1: Thảo luận (discussion)
Sender: Receiver:
 Bổ sung trường seq # vào pkt  Phải kiểm tra packet nhận
 Hai số seq. #’s (0,1) sẽ là đủ. được có phải là lặp hay không
Tại sao?  Trạng thái (state) chỉ ra giá trị
 Phải kiểm tra gói tin seq# được chờ đợi là 0 hay là 1
ACK/NAK nhận được có bị  Chú ý: receiver không thể biết
hỏng không được gói tin ACK/NAK cuối
 Số trạng thái gấp đôi (twice cùng bên sender có nhận được
as many states) đúng hay không
 Trạng thái (state) phải “nhớ”
pkt “mong chờ” cần phải có seq
# là 0 hay là 1
rdt2.2: Một giao thức không dùng NAK (NAK-free)
 Chức năng tương tự như rdt2.1, bằng cách chỉ sử dụng

ACKs
 Thay cho NAK, bên receiver gửi ACK cho pkt cuối
cùng nó nhận được đúng (biên nhận tích lũy –
accumulative acknowledgement)
 Receiver phải chỉ rõ seq# của pkt được ACKed
 ACK lặp (duplicate ACK) tại sender dẫn đến hành
động như gặp NAK: phát lại pkt hiện thời
rdt2.2: sender, receiver fragments
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt) rdt_rcv(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) || 
has_seq1(rcvpkt)) Wait for receiver FSM
0 from
udt_send(sndpkt) below fragment
&& has_seq1(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK1, chksum)
udt_send(sndpkt)
rdt3.0: Các kênh có lỗi và mất mát (errors and loss)
Giả thiết mới: Kênh Cách giải quyết (approach):

truyền bên dưới cũng sender chờ ACK một khoảng
có thể làm mất gói tin thời gian “hợp lý”
(data, ACKs)  Phátlại nếu không nhận được
 checksum, seq. #, ACK trong khoảng thời gian này
ACKs, retransmissions  Nếu pkt (or ACK) chỉ bị trễ (chứ
có thể giúp giải quyết không mất):
vấn đề … nhưng không  Việc phát lại là lặp, tuy nhiên seq#
đủ giúp xử lý vấn đề này
 Receiver phải chỉ rõ seq# của pkt
được ACKed
 Cần có đồng hồ đếm lùi
(countdown timer)
rdt3.0 sender
rdt_send(data)
rdt_rcv(rcvpkt) &&
sndpkt = make_pkt(0, data, checksum) ( corrupt(rcvpkt) ||
udt_send(sndpkt) isACK(rcvpkt,1) )
rdt_rcv(rcvpkt) start_timer 
 Wait for Wait
for timeout
call 0 from
ACK0 udt_send(sndpkt)
above
start_timer
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt,1) && notcorrupt(rcvpkt)
stop_timer && isACK(rcvpkt,0)
stop_timer
Wait Wait for
timeout for call 1 from
udt_send(sndpkt) ACK1 above
start_timer rdt_rcv(rcvpkt)
rdt_send(data) 
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) || sndpkt = make_pkt(1, data, checksum)
isACK(rcvpkt,0) ) udt_send(sndpkt)
start_timer

rdt3.0 trong quá trình hoạt động (in action)
sender receiver sender receiver

send pkt0 pkt0 send pkt0 pkt0
rcv pkt0 rcv pkt0
ack0 send ack0 ack0 send ack0
rcv ack0 rcv ack0
send pkt1 pkt1 send pkt1 pkt1
rcv pkt1 X
ack1 send ack1 loss
rcv ack1
send pkt0 pkt0
rcv pkt0 timeout
ack0 send ack0 resend pkt1 pkt1
rcv pkt1
ack1 send ack1
rcv ack1
send pkt0 pkt0
(a) no packet loss rcv pkt0
ack0 send ack0
(b) packet loss

rdt3.0 trong quá trình hoạt động (in action)
sender receiver
sender receiver send pkt0 pkt0
send pkt0 pkt0 rcv pkt0
send ack0
rcv pkt0 ack0
send ack0 rcv ack0
ack0 send pkt1 pkt1
rcv ack0 rcv pkt1
send pkt1 pkt1
send ack1
rcv pkt1 ack1
ack1 send ack1
X
loss timeout
resend pkt1 pkt1
rcv pkt1
timeout
resend pkt1 pkt1 rcv ack1 (detect duplicate)
rcv pkt1 send pkt0
pkt0
send ack1
(detect duplicate) ack1
ack1 send ack1 rcv ack1 rcv pkt0
rcv ack1 send pkt0
ack0 send ack0
send pkt0 pkt0 pkt0
rcv pkt0
rcv pkt0 ack0 (detect duplicate)
ack0 send ack0 send ack0
(c) ACK loss (d) premature timeout/ delayed ACK
Hiệu suất (Performance) của rdt3.0 (Stop CT3, 2/4/2019)
 rdt3.0 là đúng đắn, nhưng hiệu suất là kém (stinks)

 Thí dụ: 1 Gbps link, 15 ms prop. delay, 8000 bit packet:
L 8000 bits
Dtrans = R = = 8 microsecs
109 bits/sec
 U sender: hệ số sử dụng (utilization) – phần thời gian mà
sender bận gửi (busy sending)
U L/R .008
sender = = = 0.00027
RTT + L / R 30.008
 Nếu RTT=30 msec, 1 pkt kích thước 1KB:

 Mặc dù truyền đi 1 pkt chỉ mất 8 ms (Dtrans)
 Nhưng chỉ được gửi đi mỗi 30 msec: 33kB/sec throughput trên đường
truyền 1 Gbps
 Giao thức mạng hạn chế việc sử dụng tài nguyên vật lý!
rdt3.0: Hoạt động của giao thức stop-and-wait
sender receiver
Bit đầu của pkt được truyền, t = 0

Bit cuối của pkt được truyền, t = L / R
Bit đầu của pkt đến

RTT Bit cuối của pkt đến, gửi ACK
ACK đến, gửi pkt tiếp theo,

t = RTT + L / R
U L/R .008
sender = = = 0.00027
RTT + L / R 30.008
Giao thức kiểu đường ống (Pipelined protocols)
Pipelining: sender gửi liên tiếp nhiều pkts “in-flight” (trên đường
truyền), mà chưa có biên nhận
 Miền số seq# phải được tăng lên
 Cần việc nhớ đệm (buffering) tại sender and/or receiver
 Hai dạng tổng quát của giao thức kiểu đường ống: Go-Back-N
(GbN; GBN), Selective Repeat (SR)
Pipelining: increased utilization
sender receiver
Bit đầu của pkt được truyền, t = 0
Bit cuối được truyền, t = L / R
Bit đầu của pkt đến

RTT Bit cuối của pkt đến, gửi ACK
Bit cuối của pkt thứ 2 đến, gửi ACK
Bit cuối của pkt thứ 3 đến, gửi ACK
ACK đến, gửi pkt tiếp theo,
t = RTT + L / R
Tạo đường ống 3-pkt làm tăng

độ sử dụng (utilization) lên 3 lần!
U 3L / R .0024
sender = = = 0.00081
RTT + L / R 30.008
Pipelined protocols: overview
Go-back-N (GbN, GBN): Selective Repeat (SR):

 Sender có thể có đến N pkts chưa  Sender có thể có đến N pkts chưa
được biên nhận trong đường ống được biên nhận trong đường ống
 Receiver chỉ gửi biên nhận tích  Rcvr gửi biên nhận riêng rẽ
lũy - cumulative ack (individual ack) cho từng packet
 Biên nhận tích lũy: giải thích
 Không biên nhận pkt nếu có
khoảng trống (gap) STT pkt
 Sender duy trì đồng hồ cho mỗi pkt
 Sender có đồng hồ (timer) cho
còn chưa được biên nhận
pkt cũ nhất còn chưa được biên
nhận  Khi đồng hồ hết hạn (expires), thì
chỉ phát lại pkt chưa được biên nhận
 Khi đồng hồ hết hạn (expires), thì
phát lại tất cả các pkts chưa được
biên nhận
 Chú ý: đồng hồ đếm lùi, về đến 0
là hết hạn.
Go-Back-N: sender
 Trường seq# trong header của pkt dài k-bit
 “window” of up to N, consecutive unack’ed pkts allowed
 ACK(n): biên nhận tất cả pkts cho đến (kể cả) pkt có seq# = n -“cumulative
ACK”
 Có thể nhận được các biên nhận lặp (see receiver)
 Timer cho pkt cũ nhất đang ở trên đường truyền (in-flight)
 timeout(n): Truyền lại pkt thứ n và các pkt có seq# lớn hơn n trong cửa sổ
GBN: sender extended FSM
rdt_send(data)
if (nextseqnum < base+N) {
sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum)
udt_send(sndpkt[nextseqnum])
if (base == nextseqnum)
start_timer
nextseqnum++
}
 else
refuse_data(data)
base=1
nextseqnum=1
timeout
start_timer
Wait
udt_send(sndpkt[base])
rdt_rcv(rcvpkt) udt_send(sndpkt[base+1])
&& corrupt(rcvpkt) …
udt_send(sndpkt[nextseqnum-1])
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
base = getacknum(rcvpkt)+1
If (base == nextseqnum)
stop_timer
else
start_timer
GBN: receiver extended FSM
default
udt_send(sndpkt) rdt_rcv(rcvpkt)
&& notcurrupt(rcvpkt)
 && hasseqnum(rcvpkt,expectedseqnum)
expectedseqnum=1 Wait extract(rcvpkt, data)
sndpkt = deliver_data(data)
make_pkt(expectedseqnum, ACK, chksum) sndpkt = make_pkt(expectedseqnum, ACK, chksum)
udt_send(sndpkt)
expectedseqnum++
ACK-only: bao giờ cũng gửi ACK cho pkt đã nhận đúng có seq#
lớn nhất đúng thứ tự (in-order)
 Có thể làm sinh ra duplicate ACKs
 Chỉ cần nhớ seq# mong đợi (expectedseqnum)
 Pkt không đúng thứ tự:
 Loại bỏ: không cần nhớ đệm (buffering) tại bên nhận!
 Biên nhận lại (re-ACK) pkt có seq# cao nhất đúng thứ tự
Thí dụ về GBN đang hoạt động (GBN in action)
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
Selective repeat
 Receiver biên nhận riêng rẽ tất cả các pkts được nhận

đúng
 Nhớ đệm các pkts nếu cần, để cuối cùng (eventual) sẽ phân
phát đúng thứ tự cho lớp bên trên
 Sender chỉ gửi lại pkts mà nó không nhận được ACK
 Sender timer cho từng pkt chưa được biên nhận
 Sender window
 Chứa N pkts có seq# liên tiếp (N consecutive seq #’s)
 Hạn chế số pkts đã gửi (seq#s of sent), số pkts chưa được
biên nhận (unACKed pkts)
Selective repeat: sender, receiver windows
Selective repeat
Sender Receiver
Nhận data từ (tầng) trên: pkt n in [rcvbase, rcvbase+N-1]
 Nếu có seq# trong cửa sổ để  Gửi ACK(n)
dùng, thì gửi pkt  Nếu pkt n là không đúng thứ tự:
timeout(n): nhớ đệm (buffer)
 Gửi lại pkt n, restart timer  Nếu pkt n là đúng thứ tự: thì
phân phát (cũng phân phát cả
ACK(n) in [sendbase,sendbase+N]: các pkts đang được nhớ đệm
 Đánh dấu pkt n là đã được nhận nếu đúng thứ tự), tăng (sàn) cửa
 if n là số nhỏ nhất trong các pkt sổ lên đến seq# của pkt còn
chưa được biên nhận, thì tăng chưa được biên nhận kế tiếp
sàn (base) cửa sổ lên đến seq# pkt n in [rcvbase-N,rcvbase-1]
còn chưa được biên nhận kế  ACK(n)
tiếp
otherwise:
 Lờ đi (ignore)
Thí dụ về SR đang hoạt động (Selective repeat in action)
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,
send ack4
record ack3 arrived receive pkt5, buffer,
send ack5
pkt 2 timeout
012345678 send pkt2
012345678 record ack4 arrived
012345678 rcv pkt2; deliver pkt2,
record ack5 arrived
012345678 pkt3, pkt4, pkt5; send ack2
Q: điều gì xảy ra khi ack2 đến?
sender window receiver window
Selective repeat: (after receipt) (after receipt)
tình thế khó xử (dilemma) 0123012 pkt0

0123012 pkt1 0123012
0123012 pkt2 0123012
Thí dụ: 0123012
0123012 pkt3
 seq #’s: 0, 1, 2, 3 X
0123012
 window size=3 pkt0 will accept packet
with seq number 0
 receiver sees no (a) no problem
difference in two receiver can’t see sender side.
scenarios! receiver behavior identical in both cases!
 duplicate data something’s (very) wrong!
accepted as new in (b) 0123012 pkt0
0123012 pkt1 0123012
Q: what relationship 0123012 pkt2 0123012
between seq # size X 0123012
and window size to X

timeout
avoid problem in (b)? retransmit pkt0 X
0123012 pkt0
will accept packet
with seq number 0
(b) oops!
3.2 Dồn kênh và phân kênh  3.5.1 Kết nối TCP
(multiplexing and  3.5.2 Cấu trúc của segment
demultiplexing)  3.5.3 Ước lượng thời gian khứ
hồi và Timeout
3.3 Vận chuyển không hướng
 3.5.4 Truyền dữ liệu tin cậy
nối: UDP
 3.5.5 Điều khiển lưu lượng
3.4 Các nguyên tắc của việc  3.5.6 Quản lý kết nối
tắc nghẽn
3.5.1 Kết nối TCP (Stop CT4,5, 3, 4/4/2019)
TCP: Overview RFCs: 793,1122,1323, 2018, 2581
 Truyền điểm-điểm  Truyền dữ liệu song công (full

(Point-to-point): duplex data):
 Một sender, một receiver  Luồng dữ liệu đi theo 2 hướng trong
cùng một kết nối (connection)
 Truyền dòng byte tin
 MSS: Maximum Segment Size (?)
cậy, đúng thứ tự:
 Không có “ranh giới của  Hướng nối (connection-oriented):
message”  Việc bắt tay - handshaking (trao đổi
các bản tin điều khiển) là khởi đầu
 Truyền kiểu đường ống
trạng thái của sender/receiver trước
(pipelined): khi trao đổi dữ liệu
 Cơ chế điều khiển lưu
 Điều khiển lưu lượng (flow
lượng và điều khiển tắc
nghẽn thiết lập kích thước controlled):
cửa sổ  Để sender không làm ngập lụt
receiver
3.5.2 Cấu trúc của TCP segment
32 bits
URG: urgent data counting
(generally not used) source port # dest port #
by bytes
sequence number of data
ACK: ACK #
valid acknowledgement number (not segments!)
head not
PSH: push data now len used
UAP R S F receive window
(generally not used) # bytes
checksum Urg data pointer
rcvr willing
RST, SYN, FIN: to accept
options (variable length)
connection estab
(setup, teardown
commands)
application
Internet data
checksum (variable length)
(as in UDP)
TCP seq. numbers, ACKs
Sequence numbers: outgoing segment from sender
 STT byte trong dòng byte được source port # dest port #
truyền; STT này là của byte đầu tiên sequence number
trong trường data của segment. acknowledgement number
rwnd
 STT của byte đầu tiên trong dòng checksum urg pointer
byte – ISN (Initial Sequence
window size
Number) được chọn ngẫu nhiên, N
trong giai đoạn thiết lập kết nối.
Acknowledgements:
 Seq# của byte chờ nhận sender sequence number space
 Biên nhận kiểu tích lũy (cumulative)
sent sent, not- usable not
Q: Bên receiver xử lý các ACKed yet ACKed but not usable
(“in- yet sent
segments không đúng thứ tự flight”)
ntn? incoming segment to sender
 A: Đặc tả TCP không nói về điều source port # dest port #
sequence number
này, để cho người thực hiện acknowledgement number
(implementor) tự quyết. A rwnd
checksum urg pointer
TCP seq. numbers, ACKs
Host A Host B
User
types
‘C’ Seq=42, ACK=79, data = ‘C’
host ACKs
receipt of
‘C’, echoes
Seq=79, ACK=43, data = ‘C’ back ‘C’
host ACKs
receipt
of echoed
‘C’ Seq=43, ACK=80
Một kịch bản Telnet đơn giản

(simple telnet scenario)
3.5.3 Ước lượng thời gian khứ hồi và Timeout
(TCP round trip time, timeout)
Q: Thiết lập giá trị TCP Q: Ước lượng RTT ntn?

timeout ntn?  SampleRTT (lấy mẫu RTT):
 Dài hơn RTT Thời gian đo được từ khi
 Nhưng RTT lại thay đổi truyền segment đến khi nhận
 Nếu quá ngắn: timeout được ACK
vội vã (premature), phát  Không tính các lần truyền lại
(ignore retransmissions)
lại không cần thiết
 SampleRTT có thể thay đổi,
 Nếu quá dài: phản ứng
cần RTT được ước lượng
chậm đối với việc mất
“trơn” (smooth) hơn
segment
 Tính trung bình trong một vài
lần đo RTT gần nhất, chứ không
chỉ SampleRTT hiện thời.
… 3.5.3 Ước lượng thời gian khứ hồi và Timeout
EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT
 Trung bình động có trọng số theo hàm mũ (exponential weighted
moving average)
 Ảnh hưởng của mẫu cũ (past sample) giảm theo hàm mũ nhanh chóng
 Giá trị điển hình của  = 0.125 (=1/8d = 0.001b)
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
350
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
300
RTT (ms)
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 (seconds)
time (seconnds)
SampleRTT Estimated RTT
… 3.5.3 Ước lượng thời gian khứ hồi và Timeout
 Khoảng thời gian timeout (timeout interval): EstimatedRTT +

“biên an toàn” (safety margin)
 Thăng giáng của EstimatedRTT lớn hơn  biên an toàn lớn hơn
 Ước lượng độ lệch của SampleRTT so với EstimatedRTT:
DevRTT = (1-)*DevRTT +
*|SampleRTT-EstimatedRTT|
(typically,  = 0.25) (=0.01b)
TimeoutInterval = EstimatedRTT + 4*DevRTT
estimated RTT “safety margin”
hồi và Timeout
nối: UDP
tắc nghẽn
3.5.4 Truyền dữ liệu tin cậy
 TCP tạo ra dịch vụ vận chuyển

tin cậy (rdt) dựa trên dịch vụ
(vận chuyển) không tin cậy
của IP
 Các segment được truyền kiểu Đầu tiên hãy xem xét trường
đường ống (pipelined segments) hợp bên gửi TCP được đơn
 Biên nhận tích lũy giản hóa (simplified TCP
 Dùng chỉ một đồng hồ phát lại sender):
 Việc phát lại được gây ra  Bỏ qua các biên nhận lặp
(triggered) bởi:  Bỏ qua việc điều khiển lưu
lượng, điều khiển tắc nghẽn
 Sự kiện hết giờ (timeout events)
 Biên nhận lặp (duplicate acks)
… 3.5.4 Truyền dữ liệu tin cậy
Các sự kiện tại bên gửi TCP (TCP sender events):
Dữ liệu nhận từ app: Khi hết hạn (timeout):

 Tạo segment với seq#  Truyền lại segment đã gây ra
 Bắt đầu chạy timer nếu nó timeout
chưa chạy  Restart timer
 Coi timer là cho segment chưa Khi có biên nhận:
được biên nhận cũ nhất
 Khoảng thời gian hết hạn:  Nếu ack biên nhận cho các
TimeOutInterval segments đã được biên nhận
rồi:
 Cập nhật seq# của segment sẽ
được biên nhận
 Bắt đầu chạy timer nếu vẫn còn
có segments chưa được biên
nhận
Bên gửi TCP (đơn giản hóa):
data received from application above

create segment, seq. #: NextSeqNum
pass segment to IP (i.e., “send”)
NextSeqNum = NextSeqNum + length(data)
if (timer currently not running)
 start timer
NextSeqNum = InitialSeqNum wait
SendBase = InitialSeqNum for
event timeout
retransmit not-yet-acked segment
with smallest seq. #
start timer
ACK received, with ACK field value y
if (y > SendBase) {
SendBase = y
/* SendBase–1: last cumulatively ACKed byte */
if (there are currently not-yet-acked segments)
start timer
else stop timer
}
TCP: Các kịch bản truyền lại (retransmission scenarios)
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
SendBase=120
ACK=100
ACK=120
SendBase=120
lost ACK scenario premature timeout
… TCP: Các kịch bản truyền lại (retransmission scenarios)
Host A Host B

timeout
ACK=100
X
ACK=120
cumulative ACK
Việc sinh gói tin biên nhận TCP [RFC 1122, RFC 2581]
Sự kiện tại receiver Hành động của TCP receiver

Sự đến của segment đúng thứ tự với Trì hoãn việc biên nhận. Chờ đến 500ms
seq# mong đợi. Tất cả data cho đến Xem có segment kế tiếp gửi đi không để kết
seq# mong đợi đã được biên nhận hợp biên nhận. Nếu không có, gửi ACK
Sự đến của segment đúng thứ tự với Ngay lập tức gửi 1 biên nhận tích lũy, biên nhận
seq# mong đợi. Có một segment cho tất cả các segment đã nhận đúng thứ tự
khác chưa được biên nhận (ACK
pending)
Sự đến của segment không đúng thứ Ngay lập tức gửi duplicate ACK,
tự với seq# cao hơn giá trị mong đợi. Chỉ ra seq# của byte mong đợi kế tiếp
Khoảng trống seq# được phát hiện
(Gap detected)
Sự đến của segment mà nó lấp đầy Ngay lập tức gửi ACK, với điều kiện là segment
một phần hoặc toàn bộ khoảng trống bắt đầu (starts) ở mép thấp của khoảng trống
(at lower end of gap)
Truyền lại nhanh của TCP (TCP fast retransmit)
 Thời gian time-out TCP fast retransmit

thường tương đối dài:
 Thời gian trễ dài trước Nếu sender nhận được 3
khi gửi lại pkt bị mất ACKs cho cùng một
 Phát hiện các segments segment (“triple duplicate
bị mất qua duplicate ACKs”), thì gửi lại segment
ACKs. còn chưa được ack với số
seq# nhỏ nhất
 Sender thường gửi nhiều
segments liên tiếp) back-  Nhiều khả năng là segment
to-back) chưa được ack bị mất, vì
vậy không đợi timeout
 Nếu segment bị mất,
thường sẽ có nhiều
duplicate ACKs.
… Truyền lại nhanh của TCP (TCP fast retransmit)
Host A Host B

X
ACK=100
timeout
ACK=100
ACK=100
ACK=100
fast retransmit after sender

receipt of triple duplicate ACK
hồi và Timeout
nối: UDP
tắc nghẽn
3.5.4 Truyền dữ liệu tin cậy
Điều khiển lưu lượng của TCP (TCP flow control)
application
Ứng dụng có thể loại bỏ process
(remove) dữ liệu khỏi
application
TCP socket buffers ….
TCP socket OS
receiver buffers
… chậm hơn so với TCP
receiver đang phân phát
(sender is sending) TCP
code
flow control IP
code
receiver điều khiển sender, sao
cho sender không làm tràn bộ
đệm của receiver bằng việc
truyền quá nhiều, quá nhanh from sender
receiver protocol stack
… Điều khiển lưu lượng của TCP (TCP flow control)
 Receiver “quảng cáo”

(advertises) không gian bộ đệm
trống (free buffer space) bằng to application process
cách thêm giá trị rwnd trong
TCP header của các segments
mà receiver gửi cho sender RcvBuffer buffered data
 Kích thước RcvBuffer được
thiết lập (size) thông qua tùy
chọn socket (giá trị ngầm định
rwnd free buffer space
điển hình là 4096 bytes)
 Nhiều hệ điều hành điều chỉnh
tự động RcvBuffer TCP segment payloads
 Sender hạn chế lượng dữ liệu
còn chưa được ack (“in-flight”) receiver-side buffering
theo giá trị rwnd của receiver
 Đảm bảo bộ đệm bên nhận
không bị tràn
hồi và Timeout
nối: UDP
tắc nghẽn
3.5.6 Quản lý kết nối (Connection Management)
Trước khi trao đổi dữ liệu, sender/receiver “bắt tay” (handshake):

 Đồng ý thiết lập kết nối (mỗi bên biết sự bằng lòng (willing) của bên kia về
việc thiết lập kết nối)
 Đồng ý về các tham số kết nối
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 welcomeSocket.accept();
number");
… 3.5.6 Quản lý kết nối
Sự bằng lòng thiết lập kết nối (Agreeing to establish a connection)
2-way handshake:
Q: Liệu 2-way handshake
có luôn làm việc (được)
Let’s talk
trên mạng?
ESTAB  Độ trễ thay đổi
OK
ESTAB  Các messages được truyền
lại (e.g. req_conn(x)) do có
sự mất message
 Sắp xếp lại message
choose x
req_conn(x)
 Mỗi bên không “nhìn thấy “
ESTAB (see) bên kia
acc_conn(x)
ESTAB
Sự bằng lòng thiết lập kết nối (Agreeing to establish a connection)
Kịch bản 2-way handshake thất bại:
choose x choose x
req_conn(x) req_conn(x)
ESTAB ESTAB
retransmit acc_conn(x) retransmit acc_conn(x)
req_conn(x) req_conn(x)
ESTAB ESTAB
data(x+1) accept
req_conn(x)
retransmit data(x+1)
data(x+1)
connection connection
client x completes server x completes server
client
terminates forgets x terminates forgets x
req_conn(x)
ESTAB ESTAB
data(x+1) accept
half open connection! data(x+1)
(no client!)
Bắt tay 3-bước của TCP (TCP 3-way handshake)
client state server state

LISTEN 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
Bắt tay 3-bước của TCP: FSM
closed
Socket connectionSocket =
welcomeSocket.accept();
 Socket clientSocket =
SYN(x) newSocket("hostname","port
number");
SYNACK(seq=y,ACKnum=x+1)
create new socket for SYN(seq=x)
communication back to client listen
SYN SYN
rcvd sent
SYNACK(seq=y,ACKnum=x+1)
ESTAB ACK(ACKnum=y+1)
ACK(ACKnum=y+1)

TCP: Việc đóng kết nối
 Mỗi bên client và server đóng kết nối của mình

 Gửi TCP segment với cờ (1 bit) FIN = 1
 Đáp lại (respond) với FIN nhận được bằng ACK
 Khi một bên nhận được FIN, nó gửi ACK, ACK này có
thể được kết hợp với FIN của nó
 Việc trao đổi đồng thời FIN có thể xử lý được
… TCP: Việc đó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
hồi và Timeout
nối: UDP
tắc nghẽn
3.6 Các nguyên tắc của điều khiển tắc nghẽn
(Principles of congestion control)
Congestion:
 Nói đơn giản: tắc nghẽn xảy ra khi có quá nhiều nguồn gửi quá
nhiều dữ liệu làm mạng không xử lý được.
(Informally “too many sources sending too much data too fast for network to handle”)
 Điều khiển tắc nghẽn (congestion control) và điều khiển lưu

lượng (flow control) là khác nhau!
 Biểu hiện (manifestations) của tắc nghẽn:
Mất pkts (bộ đệm tại các routers bị tràn)
Độ trễ dài (do việc xếp hàng ở các bộ đệm của router)
 Đây là một trong “top-10” vấn đề cần nghiên cứu!
Nguyên nhân/Giá (causes/costs) của tắc nghẽn: kịch bản 1
original data: in throughput: out

 Có 2 senders, 2 receivers
 Có 1 router, các bộ đệm Host A
là vô hạn (infinite unlimited shared
buffers) output link buffers
 output link capacity: R
 Không có việc truyền lại
Host B
R/2
delay
out
in R/2 in R/2

 Maximum per-connection  Large delays as arrival rate,
throughput: R/2 in, approaches capacity
 Có 1 router, bộ đệm (buffer) hữu hạn

 Sender truyền lại pkt bị timed-out
 application-layer input = application-layer output: in = out
 transport-layer input includes retransmissions : ‘in  in
in : original data

'in: original data, plus out
retransmitted data
Host A
finite shared output

Host B
link buffers
… Nguyên nhân/Giá (causes/costs) của tắc nghẽn: kịch bản 2
R/2
Lý tưởng hóa: bên gửi có
hiểu biết đầy đủ
out
Sender chỉ gửi khi bộ đệm router
có chỗ trống (available)
in R/2

copy 'in: original data, plus out
retransmitted data
A free buffer space!

Host B
link buffers
Lý tưởng hóa: các pkts bị mất đã biết
có thể là bị mất (lost), bị loại bỏ
(dropped) tại router do bộ đệm đã đầy
Sender chỉ gửi lại nếu packet được biết
là bị mất

copy 'in: original data, plus out
retransmitted data
A no buffer space!
Host B
Lý tưởng hóa: các pkts bị mất R/2
đã biết có thể là bị mất (lost),
bị loại bỏ (dropped) tại router when sending at R/2,
do bộ đệm đã đầy some packets are
out
retransmissions but
Sender chỉ gửi lại nếu packet asymptotic goodput
được biết là bị mất is still R/2 (why?)
in R/2

'in: original data, plus out
retransmitted data
Host B
Thực tế: Có (truyền) lặp
R/2
 Các pkts có thể bị mất (lost), bị loại
bỏ (dropped) tại router do bộ đệm when sending at R/2,
đầy some packets are
out
retransmissions
 Sender times out sớm, việc gửi hai including duplicated
bản copy, cả hai đều được phân phát that are delivered!
in R/2
in
timeout
copy 'in out
Host B
Thực tế: Có (truyền) lặp
R/2
 Các pkts có thể bị mất (lost), bị
loại bỏ (dropped) tại router do when sending at R/2,
bộ đệm đầy some packets are
out
retransmissions
 Sender times out sớm, việc gửi including duplicated
hai bản copy, cả hai đều được that are delivered!
phân phát in R/2
“costs” của sự tắc nghẽn:

 Phải làm nhiều việc hơn (retrans) để đạt được một “goodput”
cho trước
 Truyền lại không cần thiết: đường truyền truyền nhiều bản
copy của pkt
 Làm giảm goodput
Q: Điều gì xảy ra khi in and in’ tăng lên ?
 Bốn senders
 Đường truyền đa chặng A: Khi in’ (màu đỏ) tăng lên, tất cả pkts đi
đến (màu blue) tại hàng đợi bên trên bị
(multihop paths)
loại bỏ (dropped), thông lượng của
 Có timeout/retransmit (luồng) blue  0
Host A
in : original data out
Host B
'in: original data, plus
retransmitted data
link buffers
Host D
Host C
C/2
out
in’ C/2
Một cái giá nữa của tắc nghẽn:

 Khi một gói tin bị loại bỏ, mọi dung lượng
(capacity) đường truyền lên dùng cho gói tin đó bị
bỏ phí!
Các cách (approaches) giải quyết vấn đề điều khiển tắc nghẽn
Có 2 cách tiếp cận chính đối với điều khiển tắc nghẽn:
 Điều khiển tắc nghẽn e2e (End-end congestion control)
 Điều khiển tắc nghẽn có sự trợ giúp của mạng: Network-assisted congestion
control
End-end congestion Network-assisted

control: congestion control:
 Không có phản hồi rõ  Routers cung cấp sự phản
ràng (explicit) từ mạng hồi đến các end systems
 Tắc nghẽn được end-  Dùng 1 bit chỉ thị sự tắc
system suy luận từ loss nghẽn (TCP/IP: ECN –
và delay quan sát được Explicit Congestion
 TCP sẽ giải quyết vấn đề Notification, SNA: DECbit)
 Chỉ định một tốc độ gửi
rõ ràng cho TCP
Case study: ATM ABR congestion control (skipped)
Tốc độ bit có sẵn – ABR Tế bào quản lý tài nguyên -

(Available Bit Rate): RM (resource management) cell:
Là “dịch vụ mềm dẻo” Được sender gửi, rải (rắc) vào
(elastic service) các data cells
Nếu đường truyền (path) của Các bits trong RM cell được
người gửi là “nhẹ tải” thiết lập bằng (“network-assisted”)
(underloaded):  NI (No Increase) bit: không tăng
 Sender nên sử dụng dải thông tốc độ (tắc nghẽn nhẹ - mild
có sẵn (available) congestion)
Nếu đường truyền (path) của  CI bit: Congestion Indication
người gửi là tắc nghẽn: RM cells được receiver gửi trở
 Sender bị giảm tốc độ lại cho sender, với các bit nguyên
(throttled) xuống tốc độ được vẹn
đảm bảo tối thiểu (minimum
guaranteed rate)
… Case study: ATM ABR congestion control (skipped)
RM cell data cell
 Trường 2-byte ER (Explicit Rate) trong RM cell

 Các switch bị tắc nghẽn có thể hạ thấp giá trị ER trong cell
 Tốc độ gửi của senders vì vậy là tốc độ cực đại (max) được hỗ trợ trên
đường truyền (path)
 Bit EFCI () trong data cells: được thiết lập bằng 1 trong switch
bị tắc nghẽn
 Nếu data cell đi trước RM cell có bit EFCI set (=1), thì receiver thiết lập
bit CI trong RM cell gửi trả lại
Chương 3: Các nội dung chính (stop T3, 16/4)
hồi và Timeout
nối: UDP
tắc nghẽn
3.7 Điều khiển tắc nghẽn của TCP: AIMD
Tăng theo phép cộng, giảm theo phép nhân (Additive Increase Multiplicative Decrease)
 Các giải quyết (approach): sender tăng tốc độ gửi (window size), vừa thăm
dò (probing) dải thông sử dụng được, cho đến khi xảy ra mất gói tin (nhằm
sử dụng hết dải thông khả dụng)
 AI (Additive Increase): tăng cwnd thêm 1 MSS (Maximum Segment Size) sau
mỗi khoảng thời gian RTT cho đến khi phát hiện sự mất gói tin
 MD (Multiplicative Decrease: giảm cwnd xuống còn một nửa sau sự mất gói tin
additively increase window size …

…. until loss occurs (then cut window in half)
congestion window size
cwnd: TCP sender
AIMD có hành vi
dạng răng cưa:
Thăm dò (probing)
Dải thông
time
3.7 Điều khiển tắc nghẽn của TCP: chi tiết
sender sequence number space

cwnd Tốc độ gửi của TCP:
 Tính thô (roughly):
gửi số byte là cwnd,
last byte last byte chờ ACKs trong RTT,
ACKed sent, not-
yet ACKed
sent
rồi gửi thêm các bytes
(“in-
flight”)
cwnd
rate ~
~ bytes/sec
 Sender giới hạn việc truyền: RTT
LastByteSent- < min{cwnd, rwnd}
LastByteAcked
 cwnd là động (dynamic), là

chức năng tắc nghẽn mạng cảm
nhận được
… 3.7 Điều khiển tắc nghẽn của TCP
Khởi động chậm của TCP (TCP Slow Start - SS)
Host A Host B
 Khi kết nối bắt đầu, tăng tốc độ
truyền theo kiểu hàm mũ cho đến
khi có sự kiện mất gói tin đầu tiên:
 Đầu tiên cwnd = 1 MSS (1 segment)
RTT
 Gấp đôi cwnd sau mỗi RTT
 (Khi có sự mất gói tin thì) kết thúc
việc tăng cwnd theo mỗi ACK nhận
được.
 Chuyển sang thực hiện tránh tắc
nghẽn - CA (Congestion Avoidance)
 Tóm tắt: Tốc độ ban đầu là thấp,
nhưng tăng nhanh theo hàm mũ (cơ
số 2)
time
Việc phát hiện và phản ứng với mất gói tin của TCP
 Mất gói tin (loss) được chỉ ra bởi timeout:

 cwnd thiết lập bằng 1 MSS;
 Sau đó window tăng theo hàm mũ (giống như trong SS) đến ngưỡng
- threshold, sau đó tăng tuyến tính
 Mất gói tin (loss) được chỉ ra bởi 3 duplicate ACKs: TCP
RENO
 Dup ACKs chỉ ra rằng mạng có khả năng phân phát một số segments
 cwnd được cắt giảm còn một nửa window, sau đó tăng tuyến tính
 TCP Tahoe luôn thiết lập cwnd bằng 1 (sau sự kiện timeout hoặc
3 duplicate acks)
Việc chuyển từ SS sang CA của TCP
Q: khi nào nên

chuyển từ tăng
theo hàm mũ sang
tăng tuyến tính?
A: Khi cwnd đạt tới
1/2 giá trị của nó
trước khi timeout.
Thực hiện (Implementation):

 Sử dụng ssthresh có thể
thay đổi
 Khi có sự kiện loss,
ssthresh được đặt bằng
1/2 của cwnd ngay
trước khi có sự kiện loss
Tóm tắt: Điều khiển tắc nghẽn của TCP
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
 transmit new segment(s), as allowed
cwnd = 1 MSS
ssthresh = 64 KB cwnd > ssthresh
dupACKcount = 0 slow  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
Thông lượng (throughput) TCP
 Thông lượng trung bình là hàm của window size, RTT?

 Bỏ qua giai đoạn SS, giả thiết sender luôn có data để gửi
 Ký hiệu W: window size (measured in bytes) khi loss xảy ra
 avg. window size (# in-flight bytes) is ¾ W
 avg. throughput is 3/4W per RTT
3 W
avg TCP thruput = bytes/sec
4 RTT
W/2
Tương lai của TCP: TCP hoạt động trên các “ống” dài và to
(TCP Futures: TCP over “long, fat pipes”)
 Thí dụ: segment có kích thước 1500 bytes, RTT=100ms, muốn

có thông lượng 10 Gbps
 Cần W = 83,333 in-flight segments
 Thông lượng theo xác suất mất segment, L [Mathis 1997]:
1.22 . MSS
TCP throughput =
RTT L
➜ để đạt được thông lượng 10 Gbps, cần tỉ lệ mất (loss rate) L

= 2·10-10 – a very small loss rate!
 Các versions mới của TCP cho đường truyền tốc độ cao
Tính công bằng của TCP (TCP Faireness)
Mục tiêu của tính công bằng: Nếu K phiên (session) TCP
chia sẻ cùng một đường truyền cổ chai (bottleneck link)
có bandwidth là R, mỗi phiên cần có tốc độ truyền trung
bình là R/K
TCP connection 1
bottleneck
router
capacity R
TCP connection 2
Tại sao TCP là công bằng? (Why is TCP Faire?)
Hai phiên cạnh tranh nhau (two competing sessions):

 Additive Increase cho độ dốc là 1, khi thông lượng tăng lên
 Multiplicative Decrease làm giảm thông lượng một cách tỉ lệ
(proportionally)
Đường sử dụng toàn
R  bộ băng thông
Connection 2 throughput
Chia sẻ dải thông bằng nhau
loss: giảm window với hệ số là 2

congestion avoidance: additive increase
loss: giảm window với hệ số là 2
congestion avoidance: additive increase
Connection 1 throughput R
Tính công bằng (bổ sung)
Tính công bằng và UDP Tính công bằng, các kết nối
(Fairness and UDP) TCP song song
Các ứng dụng multimedia (Fairness, parallel TCP connections)
thường không dùng TCP Ứng dụng có thể mở nhiều kết nối
 Vì không muốn tốc độ song song giữa 2 hosts
truyền bị bóp nghẹt do điều
khiển tắc nghẽn Web browsers thường làm việc
Thay vào đó dùng UDP: này

 Gửi audio/video với tốc độ Thí dụ: link có tốc độ R với 9 kết
không đổi, chấp nhận mất nối đang tồn tại:
pkts (tolerate packet loss)  Một ứng dụng mới cần mở 1 kết nối
TCP, sẽ có tốc độ R/10
 Một ứng dụng mới cần mở 11 kết
nối TCP, sẽ có tốc độ R/2 (11/21*R)
Chương 3: Tóm tắt
 Các nguyên lý đằng sau các

dịch vụ lớp giao vận:
 Dồn kênh (multiplexing), phân
kênh (demultiplexing)
 Truyền dữ liệu tin cậy
Next:
 Điều khiển lưu lượng (flow  leaving the network
control) “edge” (application,
 Điều khiển tắc nghẽn (congestion transport layers)
control)
 into the network
 Minh chứng (instantiation), “core”
thực hiện trên Internet
 UDP
 TCP
Q&A
Mạng máy tính, Chương 3 Lớp giao vận, HK2 2018-2019. PGS. TS. Nguyễn Đình Việt Ch3-112

CN2019 Chapter3 Transport Layer (VIE Final)

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

CN2019 Chapter3 Transport Layer (VIE Final)

Uploaded by

Copyright:

Available Formats

ĐẠI HỌC QUỐC GIA HÀ NỘI

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

Môn học (3TC):

PGS. TS. Nguyễn Đình Việt

A note on the use of these ppt slides:

All material copyright 1996-2013

Mục tiêu nghiên cứu:

chuyển dành cho các ứng dụng

 Network layer: truyền Tương tự việc gia đình:

 TCP: Tin cậy, phân phát đúng thứ

 Các dịch vụ không có:

application P1 P2 application socket

 Host nhận IP datagrams

 Nhắc lại: socket được tạo ra  Nhắc lại: Khi tạo ra

 Khi host nhận được UDP Các IP datagrams có cùng

source port: 6428 source port: ?

source port: 9157 source port: ?

 TCP socket được chỉ rõ  Server host có thể hỗ trợ

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

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

 Là giao thức vận chuyển  Việc sử dụng UDP:

Thí dụ: cộng hai số 16 bit

Các hành động được thực hiện (actions taken)

 Kênh truyền bên dưới tin cậy hoàn toàn

Wait for rdt_send(data) Wait for rdt_rcv(packet)

Làm thế nào mà con người có thể khôi phục từ

rdt_rcv(rcvpkt) && isACK(rcvpkt)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Điều gì sẽ xảy ra nếu gói Xử lý (gói tin) lặp:

stop and wait (S&W)

udt_send(sndpkt) sndpkt = make_pkt(1, data, checksum)

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

 Chức năng tương tự như rdt2.1, bằng cách chỉ sử dụng

Giả thiết mới: Kênh Cách giải quyết (approach):

sender receiver sender receiver

(b) packet loss

(c) ACK loss (d) premature timeout/ delayed ACK

 rdt3.0 là đúng đắn, nhưng hiệu suất là kém (stinks)

 Nếu RTT=30 msec, 1 pkt kích thước 1KB:

Bit đầu của pkt được truyền, t = 0

Bit đầu của pkt đến

ACK đến, gửi pkt tiếp theo,

Bit đầu của pkt đến

Tạo đường ống 3-pkt làm tăng

Go-back-N (GbN, GBN): Selective Repeat (SR):

sender window (N=4) sender receiver

 Receiver biên nhận riêng rẽ tất cả các pkts được nhận

sender window (N=4) sender receiver

Q: điều gì xảy ra khi ack2 đến?

tình thế khó xử (dilemma) 0123012 pkt0

and window size to X

 Truyền điểm-điểm  Truyền dữ liệu song công (full

Một kịch bản Telnet đơn giản

Q: Thiết lập giá trị TCP Q: Ước lượng RTT ntn?

SampleRTT Estimated RTT

 Khoảng thời gian timeout (timeout interval): EstimatedRTT +

TimeoutInterval = EstimatedRTT + 4*DevRTT

estimated RTT “safety margin”

 TCP tạo ra dịch vụ vận chuyển

Dữ liệu nhận từ app: Khi hết hạn (timeout):

data received from application above

Host A Host B Host A Host B