BaiGiang C3

Mạng máy tính
Bộ môn Kỹ thuật máy tính và Mạng

Khoa Công nghệ Thông tin
Đại học Sư phạm Hà Nội
1-1
Chương 3: Tầng giao vận
Mục đích:
Hiểu các nguyên tắc Học về giao thức tầng giao
bên trong dịch vụ của vận trong Internet:
tầng giao vận: UDP: không hướng kết nối
Multiplexing/Demultiple TCP: hướng kết nối
xing Điều khiển tắc nghẽn của
Truyền dữ liệu tin cậy TCP
Điều khiển luồng
Điều khiển tắc nghẽn
1-2
3.1 Các dịch vụ tầng 3.5 Dịch vụ hướng kết
giao vận nối: TCP
3.2 Multiplexing và Cấu trúc segment
demultiplexing Truyền dữ liệu tin cậy
3.3 Dịch vụ không
Quản lý kết nối
hướng kết nối: UDP
3.4 Các nguyên tắc của
truyền dữ liệu tin cậy điều khiển tắc nghẽn
3.7 Điều khiển tắc nghẽn
của TCP
1-3
Các giao thức và dịch vụ tầng giao vận
Cung cấp truyền thông lô-gíc application
transport
giữa các tiến trình ứng dụng network
data link
chạy trên các host khác nhau physical
network
data link
network physical
Các giao thức giao vận chạy data link
physical
trên các hệ thống cuối network
data link
Bên gửi: chia các bản tin physical network
data link
ứng dụng thành các physical
segment, chuyển tới tầng network

data link
mạng physical
Bên nhận: ghép các application

transport
segment thành bản tin, network
data link
chuyển lên tầng ứng dụng physical
Nhiều hơn một giao thức giao

vận cho ứng dụng
Internet: TCP và UDP
1-4
Tầng giao vận và tầng mạng
Tầng mạng: truyền thông lô- Tương tự hộ gia đình:
gíc giữa các host 12 đứa trẻ gửi thư cho 12 đứa
Tầng giao vận: truyền thông trẻ
lô-gíc giữa các tiến trình Các tiến trình = các đứa trẻ
dựa trên dịch vụ của tầng Các bản tin ứng dụng = các
mạng bức thư
host = nhà
Giao thức giao vận = Ann
và Bill
Giao thức tầng mạng = dịch
vụ chuyển thư
1-5
Các giao thức tầng giao vận của Internet
Truyền tin cậy, có thứ tự application

transport
(TCP) network
data link network
physical data link
Điều khiển tắc nghẽn network physical
data link
Điều khiển luồng physical
network
Thiết lập kết nối data link
physical network
data link
Truyền không có thứ tự, physical
không tin cậy: UDP network

data link
physical
Các dịch vụ không có:

application
Đảm bảo độ trễ transport
network
data link
Đảm bảo băng thông physical
1-6
của TCP
1-7
Multiplexing/demultiplexing
Demultiplexing tại host nhận: Multiplexing tại host gửi:
Thu thập dữ liệu từ các socket,
Chuyển các segment đã nhận
đóng gói dữ liệu bởi header
tới đúng socket
(sau đó sẽ dùng để
demultiplexing)
= socket = tiến trình
application P3 P1
P1 application P2 P4 application
transport transport transport
network network network
link link link
physical physical physical
host 2 host 3
host 1
1-8
Thực hiện demultiplexing
Host nhận gói dữ liệu IP
Mỗi gói dữ liệu có địa chỉ IP 32 bits
nguồn, địa chỉ IP đích
source port # dest port #
Mỗi gói dữ liệu mang một
segment của tầng giao vận
Mỗi segment có giá trị cổng Các trường header
nguồn và cổng đích (giá trị
cổng cố định cho các kiểu
ứng dụng cụ thể) Dữ liệu ứng dụng
Host sử dụng địa chỉ IP và giá (bản tin)
trị cổng để chuyển segment tới
socket thích hợp
Định dạng TCP/UDP segment
1-9
của TCP
1-10
UDP: User Datagram Protocol [RFC 768]
Dịch vụ “best effort”, UDP
segment có thể: Tại sao có UDP?
mất Không thiết lập kết nối (thiết
chuyển không theo thứ lập có thể tăng độ trễ)
tự đến ứng dụng Đơn giản: không có trạng
Không hướng kết nối: thái kết nối tại bên gửi, bên
Không có bắt tay giữa nhận
bên gửi và bên nhận Header của segment nhỏ
Mỗi UDP segment được Không điều khiển tắc nghẽn:
điều khiển độc lập UDP có thể gửi ra với tốc độ
mong muốn
1-11
UDP (tiếp)
Thường sử dụng cho các
ứng dụng đa phương tiện 32 bits
truyền dòng source port # dest port #
Length tính
Chấp nhận mất gói
theo byte của length checksum
Nhạy cảm với tốc độ UDP
Ứng dụng khác sử segment,
dụng UDP bao gồm
header
DNS

SNMP
dữ liệu
Truyền tin cậy qua UDP:
của ứng dụng
thêm sự tin cậy tại tầng ứng (bản tin)
dụng
Khôi phục lỗi do ứng
dụng cụ thể Định dạng của UDP segment
1-12
UDP checksum
Mục đích: phát hiện lỗi trong segment đã truyền
Bên gửi: Bên nhận:
Đối xử với nội dung các Tính toán checksum của
segment như chuỗi các số segment nhận được
nguyên 16 bít Kiểm tra xem checksum đã
checksum: cộng (tổng bù tính có bằng giá trị trường
của 1) của nội dung checksum:
segment KHÔNG BẰNG– Phát hiện
Phía gửi đặt giá trị có lỗi
checksum trong trường BẰNG – không phát hiện ra
checksum của UDP lỗi. Nhưng có thể có lỗi?
1-13
Ví dụ Checksum
Chú ý
Khi cộng các số, giá trị bít nhớ cần thêm vào kết
quả
Ví dụ: cộng hai số nguyên 16 bít
1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
Tổng 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
1-14
của TCP
1-15
Các nguyên tắc của truyền dữ liệu tin cậy
Tầm quan trọng của tầng liên kết dữ liệu, tầng giao vận, tầng
ứng dụng
(a) Dịch vụ cung cấp (b) Cài đặt dịch vụ
Đặc điểm của kênh truyền không tin cậy xác định sự phức tạp
của giao thức truyền dữ liệu tin cậy (rdt)
1-16
Truyền dữ liệu tin cậy
rdt_send(): được gọi bởi tầng trên. deliver_data(): được gọi bởi rdt
Dữ liệu đã chuyển được chuyển tới để truyền dữ liệu lên tầng trên
tầng trên của bên nhận
Bên gửi Bên nhận
udt_send(): gọi bởi rdt, để rdt_rcv(): gọi khi gói tin đến phía
truyền gói tin qua kênh không bên nhận
tin cậy tới bên nhận
1-17
Sử dụng máy trạng thái hữu hạn (FSM) để xử lý
bên nhận và bên gửi
Sự kiện gây ra chuyển trạng thái

Hành động khi chuyển trạng thái
state: khi trong 1 trạng
thái, trạng thái tiếp state state
1 sự kiện
theo là duy nhất đối 2
với 1 sự kiện hành động
1-18
rdt1.0: Truyền tin cậy qua kênh tin cậy
Tầng dưới là truyền tin cậy
Không có lỗi bít
Không mất gói tin
FSM của bên gửi và bên nhận:
Bên gửi chuyển dữ liệu xuống kênh phía dưới
Bên nhận đọc dữ liệu từ kênh bên dưới
Đợi cuộc rdt_send(data) đợi cuộc rdt_rcv(packet)

gọi từ gọi từ extract (packet,data)
phía trên packet = make_pkt(data) phía dưới deliver_data(data)
udt_send(packet)
1-19
Rdt2.0: kênh có lỗi bít
Kênh phía dưới có thể có lỗi
checksum để phát hiện lỗi
Cách khôi phục lỗi
Báo nhận (ACK): bên nhận chỉ rõ cho bên gửi gói tin nhận
thành công
Báo lỗi (NAK): bên nhận chỉ rõ cho bên gửi gói tin có lỗi
Bên nhận truyền lại gói tin nếu nhận NAK
Cơ chế rdt2.0:
Phát hiện lỗi
Phản hồi cho bên nhận: bản tin điều khiển (ACK, NAK: bên
nhận -> bên gửi)
1-20
rdt2.0: Máy trạng thái
rdt_send(data)
snkpkt = make_pkt(data, checksum) Bên nhận
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Đợi cuộc Đợi ACK rdt_rcv(rcvpkt) &&
gọi từ trên hoặc udt_send(sndpkt) corrupt(rcvpkt)
NAK
udt_send(NAK)
rdt_rcv(rcvpkt) && isACK(rcvpkt)

Đợi cuộc
gọi từ phía
dưới
Bên gửi
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
1-21
rdt2.0: Trường hợp không lỗi
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
đợi cuộc đợi ACK rdt_rcv(rcvpkt) &&
gọi từ phía hoặc udt_send(sndpkt) corrupt(rcvpkt)
trên NAK
udt_send(NAK)

đợi cuộc
Λ gọi từ phía
dưới
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
deliver_data(data)
udt_send(ACK)
1-22
rdt2.0: Trường hợp có lỗi
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
đợi cuộc đợi ACK rdt_rcv(rcvpkt) &&
gọi từ phía hoặc udt_send(sndpkt) corrupt(rcvpkt)
trên NAK
udt_send(NAK)

đợi cuộc
Λ gọi từ phía
dưới
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
deliver_data(data)
udt_send(ACK)
1-23
rdt2.1: Bên gửi, điều khiển ACK/NAK lỗi
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt) rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
đợi cuộc đợi ACK
hoặc NAK
isNAK(rcvpkt) )
gọi 0 từ
0 udt_send(sndpkt)
trên
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt) && notcorrupt(rcvpkt)
&& isACK(rcvpkt)
Λ
đợi ACK đợi cuộc
hoặc NAK gọi 1 từ
rdt_rcv(rcvpkt) && 1 trên
isNAK(rcvpkt) ) rdt_send(data)
udt_send(sndpkt) sndpkt = make_pkt(1, data, checksum)

udt_send(sndpkt)
1-24
rdt2.1: Bên nhận, điều khiển ACK/NAK lỗi
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)
đợi 0 đợi 1
rdt_rcv(rcvpkt) && từ dưới từ dưới rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) && 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)
1-25
rdt2.1
Bên gửi: Bên nhận:
seq # được thêm vào Phải kiểm tra gói tin đã
gói tin nhận có lặp không
Hai seq. #’s (0,1) Trạng thái chỉ định pkt
seq # mong đợi là 0 hay
Phải kiểm tra nếu 1
ACK/NAK đã nhận có
lỗi
Hai lần -> ổn định
1-26
rdt2.2: Giao thức NAK-free
Tương tự rdt2.1, chỉ sử dụng ACK

Thay vì NAK, bên nhận phải gửi ACK cho pkt cuối đã
nhận OK
ACK lặp tại bên nhận sẽ như xử lý như nhận NAK:
truyền lại pkt hiện tại
1-27
rdt2.2: Phân mảnh tại bên gửi và bên nhận
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt) rdt_rcv(rcvpkt) &&
đợi cuộc đợi ACK
0 isACK(rcvpkt,1) )
gọi 0 từ
trên udt_send(sndpkt)
FSM bên gửi
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && && isACK(rcvpkt,0)
(corrupt(rcvpkt) || L
has_seq1(rcvpkt)) đợi 0 FSM bên nhận
từ dưới
udt_send(sndpkt)

&& has_seq1(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK1, chksum)
udt_send(sndpkt) 1-28
rdt3.0: kênh có lỗi và mất gói
Giả sử: kênh phía dưới có Cách tiếp cận: bên nhận đợi
thể mất gói (dữ liệu ACK một thời gian
hoặc ACK) Truyền lại nếu không có ACK
checksum, seq. #, ACK, nhận tại thời điểm này
truyền lại là không đủ Nếu gói tin (hoặc ACK) trễ
(không mất):
Truyền lại -> lặp, sử dụng
seq# để giải quyết
Bên nhận phải gán seq #
của gói tin được ACK
Đòi hỏi bộ đếm thời gian
ngược
1-29
rdt3.0 Bên gửi
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 Λ
Λ đợi cuộc gọi đợi
ACK 0 timeout
0 từ trên
udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt,1) && notcorrupt(rcvpkt)
stop_timer && isACK(rcvpkt,0)
stop_timer
đợi đợi cuộc gọi
timeout ACK 1 1 từ trên
udt_send(sndpkt)
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
Λ
1-30
rdt3.0
(a) Không mất gói (b) Mất gói
1-31
rdt3.0
(c) Mất ACK (c) Timeout
1-32
Hiệu năng của rdt3.0
Hiệu năng của rdt3.0 bị ảnh hưởng

Ví dụ: đường truyền 1 Gbps, lan truyền 15 ms, gói tin 1KB:
T transmit = L (độ dài gói tin, bit) 8kb/pkt

= = 8 microsec
R (tốc độ truyền, bps) 10**9 b/sec
U L/R .008
= = = 0.00027
sender 30.008
RTT + L / R
U sender: sự sử dụng – thời gian bên gửi bận gửi

1KB pkt trong mỗi 30 msec -> 33kB/sec thông lượng qua đường
truyền 1 Gbps
Giao thức mạng hạn chế sử dụng tài nguyên vật lý!
1-33
rdt3.0: Hoạt động stop-and-wait
gói tin đầu tiên được truyền, t = 0
gói tin cuối cùng truyền, t = L / R
bít của gói tin đầu tiên đến

RTT bít của gói tin cuối cùng đến,
gửi ACK
ACK đến, gửi gói tin tiếp,

t = RTT + L / R
U L/R .008
= = = 0.00027
sender 30.008
RTT + L / R
1-34
Các giao thức Pipeline
Pipeline: Bên gửi cho phép nhiều, tới các gói tin được
ack
Dải giá trị sequence phải tăng
Vùng đệm tại bên gửi và bên nhận
Hai hình thức chung của các giao thức pipeline: go-
Back-N, selective repeat
1-35
Pipelining: Tăng hiệu quả sử dụng
Bít gói tin đầu tiên được truyền,
t=0
Bít cuối cùng được truyền
t=L/R
Bít gói tin đầu tiên đến
RTT Bít gói tin cuối cùng đến, gửi ACK
Bít cuối cùng của gói tin thứ 2 đến, gửi
ACK
ACK đến, gửi gói tin tiếp theo, Bít cuối cùng của gói tin 3 đến, gửi ACK
t = RTT + L / R
Tăng hiệu quả sử
dụng lên 3 lần
U 3*L/R .024
= = = 0.0008
sender 30.008
RTT + L / R
1-36
Go-Back-N
Bên gửi:
k-bit seq # trong pkt header
“window” N, cho phép các gói tin không ack liên tiếp
ACK(n): ACK mọi gói tin tới seq # n - “ACK tích lũy”
Có thể nhầm ACK lặp
Thời gian cho mỗi gói tin
timeout(n): truyền lại gói tin n và tất cả gói tin seq# lớn hơn n trong
cửa sổ
Lý do phải giới hạn N: điều khiển luồng, điều khiển tắc nghẽn 1-37
GBN: FSM mở rộng của bên gửi
rdt_send(data)
if (nextseqnum < base+N) {
sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum)
udt_send(sndpkt[nextseqnum])
if (base == nextseqnum) /* pkt chưa được ack đầu tiên */
start_timer
nextseqnum++
}
Λ else
refuse_data(data)
base=1
nextseqnum=1
timeout
start_timer
đợi
udt_send(sndpkt[base])
rdt_rcv(rcvpkt) udt_send(sndpkt[base+1])
&& corrupt(rcvpkt) …
udt_send(sndpkt[nextseqnum-1])
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
Sử dụng một base = getacknum(rcvpkt)+1
timer cho gói tin If (base == nextseqnum) /* tất cả các pkt đều được ack */
đã gửi và chưa stop_timer
được ack và cũ else /* vẫn còn gói tin chưa được ack */
nhất start_timer 1-38
GBN: FSM mở rộng của bên nhận
default
udt_send(sndpkt) rdt_rcv(rcvpkt)
&& notcurrupt(rcvpkt)
Λ && hasseqnum(rcvpkt,expectedseqnum)
đợi extract(rcvpkt,data)
expectedseqnum=1 deliver_data(data)
sndpkt = sndpkt = make_pkt(expectedseqnum,ACK,chksum)
make_pkt(expectedseqnum,ACK,chksum) udt_send(sndpkt)
expectedseqnum++
ACK: luôn gửi ACK cho gói tin đã nhận đúng với gói tin
đúng thứ tự seq # nhất
Có thể sinh ra ACK lặp
Chỉ cần nhớ expectedseqnum
Gói tin không đúng thứ tự:
Loại bỏ (không đưa vào bộ nhớ đệm)
1-39
GBN
Window size = 4 pkt
1-40
Selective Repeat
Bên nhận ack riêng cho mọi gói tin nhận đúng
Đưa gói tin vào vùng đệm nếu cầu, có thể sắp thứ tự
chuyển lên lớp trên
Bên gửi chỉ gửi lại gói tin khi không nhận ACK
Bộ đếm thời gian bên gửi cho mỗi gói tin không được ACK
Cửa sổ bên nhận
N seq # liên tục
Giới hạn seq #s gửi, gói tin không ACK
1-41
Selective repeat: Cửa sổ bên gửi, bên nhận
1-42
Selective repeat
Dữ liệu từ trên: Gói tin n [rcvbase, rcvbase+N-1]
Nếu có seq # tiếp trong cửa sổ, Gửi ACK(n)
gửi gói tin Không đúng thứ tự: vùng đệm
timeout(n): Đúng thứ tự: chuyển lên (cũng
Gửi lại gói tin n, khởi tạo lại bộ có thể đưa vào vùng đệm, xếp
đếm thời gian thứ tự), cửa sổ chuyển tiếp tới
gói tin đã nhận tiếp
ACK(n) [sendbase,sendbase+N]:
Đánh dấu gói tin n đã nhận pkt n [rcvbase-N,rcvbase-1]
Nếu n gói tin không được ACK
ACK(n)
nhỏ nhất, if n smallest unACKed Nếu không:
pkt, chuyển cơ sở của cửa sổ Bỏ qua
tới seq # không được ACK tiếp
1-43
Selective repeat
1-44
Selective repeat
Ví dụ:
seq #’s: 0, 1, 2, 3
Kích thước cửa sổ=3
Bên nhận thấy không có

sự khác nhau trong 2
kịch bản
Chuyển không đúng dữ
liệu như mới (a)
Q: Quan hệ giữa kích

thước seq# và kích
thước cửa sổ?
1-45
của TCP
1-46
TCP: Tổng quan RFC: 793, 1122, 1323, 2018, 2581
Point-to-point: Dữ liệu truyền song
Một bên gửi, một bên nhận công:
Tin cậy, có thứ tự Luồng dữ liệu truyền hai
chiều trên cùng một kết
Pipeline: nối
Điều khiển tắc nghẽn và MSS: maximum segment
điều khiển luồng của TCP size
thiết lập giá trị kích thước
cửa sổ Hướng kết nối:
Vùng đệm gửi và nhận Bắt tay (trao đổi các bản
tin điều khiển), bên gửi
khởi đầu
Điều khiển luồng:
application application
socket
writes data reads data
socket
Bên gửi không gửi quá
door
TCP TCP
door khả năng bên nhận
send buffer receive buffer
segment
1-47
Cấu trúc của TCP segment
32 bits
URG: urgent data đếm số byte
(không sử dụng) source port # dest port #
dữ liệu
sequence number (không phải
ACK: ACK #
acknowledgement number segments!)
head not
PSH: push data len used
UAP R S F Receive window
(không sử dụng) # bytes
checksum Urg data pnter
bên nhận
RST, SYN, FIN: muốn nhận
Options (chiều dài thay đổi)
thiết lập kết nối
dữ liệu ứng dụng

Internet (chiều dài thay đổi)
checksum
(như trong UDP)
1-48
TCP seq # và ACK
Seq. #: Host B
Host A
Giá trị của luồng
byte của byte đầu Gõ Seq=4
2 , AC
‘C’ K=79,
tiên trong dữ liệu data =
‘C’
của segment host ACK
đã nhận
ACK: ‘C ’ ‘C’, báo lại
3 , data =
= 4
seq # của byte tiếp =7 9 , ACK ‘C’
Se q
theo mong nhận
ACK tích lũy host ACK đã nhận
‘C’ báo lại
Q: Bên nhận điều khiển Seq=4
3, ACK
=80
các segment không
đúng thứ tự
A: Chuẩn không chỉ
time
rõ, tùy thuộc vào cài
Kịch bản telnet
đặt cụ thể
1-49
RTT và Timeout trong TCP
Q: Thiết lập giá trị Q: Ước lượng RTT?
SampleRTT: đo thời gian từ truyền
timeout của TCP? segment tới khi ACK được nhận
Lớn hơn RTT Bỏ qua truyền lại
RTT thay đổi SampleRTT thay đổi, ước lượng
Quá nhỏ: timeout RTT chính xác hơn
sớm Giá trị trung bình của nhiều giá
trị đo gần đó
Không cần thiết
truyền lại
Quá lớn: xử lý chậm
các segment bị mất
1-50
RTT và timeout trong TCP
EstimatedRTT = (1- α)*EstimatedRTT + α*SampleRTT
Giá trị thường dùng: α = 0.125
1-51
Ví dụ ước lượng RTT
350
300
250
RTT (milliseconds)
200
150
100
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)
SampleRTT Estimated RTT
1-52
RTT và timeout của TCP
Thiết lập timeout
EstimatedRTT cộng giới hạn an toàn
Sự thay đổi lớn của EstimatedRTT -> giá trị lề an toàn lớn
Ước lượng SampleRTT kế thừa từ EstimatedRTT:
DevRTT = (1-β)*DevRTT +
β*|SampleRTT-EstimatedRTT|
(thường, β = 0.25)
Rồi thiết lập timeout:

TimeoutInterval = EstimatedRTT + 4*DevRTT
1-53
của TCP
1-54
Truyền dữ liệu tin cậy của TCP
TCP tạo dịch vụ rdt trên Truyền lại khi:
dịch vụ không tin cậy Có sự kiện timeout
của IP Lặp ack
Pipelined segment Xét trường hợp bên
ACK tích lũy gửi:
Bỏ qua điều khiển luồng,
điều khiển tắc nghẽn
1-55
Các sự kiện của bên gửi TCP
Nhận dữ liệu từ ứng dụng: Timeout:
Tạo segment với seq # Truyền lại segment bị quá
seq # là giá trị luồng byte hạn
của byte đầu tiên trong Tính timeout interval cho
segment segment truyền lại
Khởi tạo bộ đếm thời gian Khởi tạo lại bộ đếm thời gian
Chuyển segment tới IP Nhận Ack:
Tính NextSeqNum Nếu segment trước đó chưa
được ACK
Cập nhật để biết đã ack
Nếu segment trước đó đã
ACK
Tăng bộ đếm ACK lặp, lặp 3
lần thì truyền lại
1-56
NextSeqNum = InitialSeqNum
SendBase = InitialSeqNum
loop (forever) {
switch(event) Bên gửi
event: Nhận được dữ liệu từ tầng ứng dụng
Tạo TCP segment với giá trị sequence NextSeqNum
Khởi động timer cho segment NextSegNum
TCP
Chuyển segment tới IP (đơn giản)
NextSeqNum = NextSeqNum + length(data)
event: timer quá hạn cho segment có sequence number = y Giải thích:
Truyền lại segment có sequence number = y
• SendBase-1: byte
Tính timeout interval cho segment y
Khởi động timer cho segment y được ack tích lũy
cuối
event: Nhận được ACK, giá trị của trường ACK: y Ví dụ:
if (y > SendBase) { • SendBase-1 = 71;
Bỏ timer của tất cả các segment có sequence number y= 73, rcvr
<y muốn 73+ ;
SendBase = y y > SendBase,
} else { /* ACK lặp */
vì thế dữ liệu mới
Tăng số ACK lặp của segment y
if (số lần ACK lặp của segment y == 3) {
được ack
Truyền lại segment với sequence number = y
Khởi động timer cho segment y
}
1-57
}
TCP: Kịch bản truyền lại
Host A Host B
Host A Host B
Seq=9
2 , 8 byt
Seq=9 es dữ
2 , 8 byt Seq= liệu
Seq=92 timeout
es dữ 1 00, 2
liệu 0 byt
es dữ
liệu
timeout
C K =100 10
0
A
C K=
K = 120
X A AC
mất Seq=9
2 , 8 byt
Seq=9 Sendbase e s dữ
liệu
2 , 8 byt
e s dữ = 100
Seq=92 timeout
liệu
SendBase
= 120 0
= 12
A CK
=100
AC K
SendBase
= 100 SendBase
= 120 timeout sớm
thời gian
thời gian Kịch bản không truyền lại
Kịch bản mất ACK segment khi ACK đến trước
timeout 1-58
Kịch bản truyền lại
Host A Host B
Seq=9
2 , 8 byt
es da
ta
Seq=1 K =100
timeout
0 A C
0, 20
bytes
data
X
mất
SendBase C K =120
A
= 120
thời gian
Kịch bản ACK tích lũy
1-59
Truyền dữ liệu tin cậy của TCP:
GBN hay Selective Repeat
Giống GBN:
ACK tích lũy
Bên gửi của TCP chỉ cần duy trì
Sequence number nhỏ nhất của gói tin đã gửi, chưa được ack
(sendbase)
Sequence number của byte tiếp theo sẽ gửi (nextseqnum)
Khác GBN:
Timeout của segment có sequence number là n chỉ gửi
lại segment n
RFC 2018 - TCP Selective Acknowledgment Options
1-60
của TCP
1-61
Điều khiển luồng TCP
Bên gửi không gửi làm tràn
Bên nhận của kết nối vùng đệm bên nhận: truyền quá
TCP có buffer nhận: nhiều, quá nhanh
Dịch vụ tương ứng tốc

độ: tương ứng tốc độ
gửi với tốc độ bên nhận
1-62
Điều khiển luồng của TCP
Bên nhận thông tin về
không gian còn thừa
trong giá trị của
RcvWindow trong
segment
(Giả sử bên nhận bỏ segment Bên gửi hạn chế dữ liệu
không đúng thứ tự) chưa ACK theo
RcvWindow
Không gian còn thừa trong
Đảm bảo buffer nhận
buffer không bị tràn
= RcvWindow LastByteSent -
= RcvBuffer-(LastByteRcvd – LastByteAcked <=
LastByteRead) RcvWindow
RcvWindow = 0 ?
1-63
của TCP
1-64
Quản lý kết nối của TCP
Thiết lập kết nối: Bắt tay 3 đường:
Nhắc lại: Bên gửi, bên nhận Bước 1: Client gửi TCP SYN
của TCP thiết lập kết nối segment tới server
trước khi trao đổi dữ liệu Chỉ định seq # ban đầu
Khởi tạo giá trị: Không có dữ liệu
seq. #
Bước 2: Server nhận SYN, trả lời
buffer, thông tin điều với SYNACK segment
khiển luồng (ví dụ:
RcvWindow) Server cấp phát buffer
Client: khởi tạo kết nối Server khởi tạo seq. #

Socket clientSocket = new Bước 3: Client nhận SYNACK, trả
Socket("hostname","port lời bằng ACK segment, có thể
number"); chứa dữ liệu
Server: liên lạc bởi client
Socket connectionSocket =
welcomeSocket.accept();
1-65
Thiết lập kết nối:
client server
Connec
tion req
uest (S
YN =1, seq
=client_
isn)
,
e r_isn
e q =serv
Y N=1, s
( S 1
g ra nted ent_isn+
n cl i
o n nectio ack=
C
ack (S
YN=0
,s
ack=s eq=client_i
erver_ s
isn+1 n+1,
1-66
Đóng kết nối: client server
đóng
client đóng socket: FIN
clientSocket.close();
Bước 1: client gửi TCP FIN AC K

đóng
tới server FIN
Bước 2: server nhận FIN, trả
thời gian đơị

A CK
lời bằng ACK. Đóng kết nối,
gửi FIN
đóng
1-67
Bước 3: client nhận FIN, trả client server

lời bằng ACK. đang
FIN
Thời gian đợi: trả lời đóng
bằng ACK báo đã nhận
FIN AC K
đang
FIN đóng
Bước 4: server, nhận ACK.
Kết nối đóng.
thời gian đợi

A CK
đã đóng
đóng
1-68
Chu kỳ hoạt động

TCP server
Chu kỳ hoạt động

TCP client
1-69
của TCP
1-70
Nguyên tắc điều khiển tắc nghẽn
Tắc nghẽn:
Quá nhiều nguồn gửi quá nhiều dữ liệu nhanh quá
khả năng điều khiển của mạng
Khác điều khiển luồng
Đặc điểm:
Mất gói tin (tràn buffer tại router)
Độ trễ tăng (xếp hàng tại buffer của router)
1-71
Nguyên nhân, tác hại của tắc nghẽn:
Kịch bản 1
Host A lout
lin : original data
Hai đối tượng gửi,
hai đối tượng nhận
Host B unlimited shared
Một router, vùng output link buffers
đệm không giới

hạn
Không truyền lại
Độ trễ lớn khi

xảy ra tắc nghẽn
Tối đa thông
lượng có thể đạt
được
1-72
Kịch bản 2
Một router, vùng đệm giới hạn
Bên gửi truyền lại gói tin mất
Host A lin : dữ liệu ban đầu lout
l'in : dữ liệu ban đầu, dữ liệu

truyền lại
Host B vùng đệm của đường

truyền đầu ra dùng
chung và có giới hạn
1-73
Kịch bản 2
Luôn luôn: λ= λ
in out (tốt)
Truyền lại “hoàn hảo”: truyền lại chỉ khi mất λ > λout
in
Sự truyền lại của gói tin bị trễ (không mất) làm λ lớn hơn (trường
in
hợp hoàn hảo) so với λ
out
R/2 R/2 R/2
R/3
λout
λout
λout
R/4
R/2 R/2 R/2

λin λin λin
a. b. c.
“Tác hại” của tắc nghẽn:
Xử lý nhiều hơn (truyền lại)
Truyền lại không cần thiết: đường truyền mang nhiều bản sao chép
của gói tin 1-74
Kịch bản 3
Bốn đối tượng gửi
Q: Điều gì xảy ra khi λ
in
Nhiều đường
và λ tăng?
timeout/truyền lại in
λin : dữ liệu ban đầu
Host A λout
λ'in : dữ liệu ban đầu, và
dữ liệu truyền lại
vùng đệm của đường
truyền ra dùng chung
và có giới hạn
Host B
1-75
Kịch bản 3
H λ
o
o
s
u
t
A t
H
o
s
t
B
Tác hại khác của tắc nghẽn:

Khi gói tin bị loại bỏ, khả năng truyền đường lên sử
dụng cho gói tin đó đã lãng phí
1-76
Các cách tiếp cận
để điều khiển tắc nghẽn
Hai cách tiếp cận chính để điều khiển tắc nghẽn:
Điều khiển tắc nghẽn Điều khiển tắc nghẽn với

cuối-cuối: sự giúp đỡ của mạng:
Không có phản hồi chính Router cung cấp phản hồi tới
thức từ mạng hệ thống cuối
Tắc nghẽn suy ra từ hệ Một bít chỉ ra tắc nghẽn
thống cuối theo dõi mất gói (SNA, DECbit, TCP/IP,
và độ trễ ECN, ATM)
Cách tiếp cận sử dụng bởi Chỉ rõ tốc độ bên gửi nên
TCP gửi
1-77
Trường hợp nghiên cứu:
Điều khiển tắc nghẽn ATM ABR
ABR: Available Bit Rate: RM cell (Resource
“Dịch vụ co dãn” Management):
Nếu đường đi của bên gửi Được gửi bởi bên gửi, rải rác
chưa đến giới hạn tải: cùng với cell dữ liệu
Bên gửi nên sử dụng Các bít trong RM cell do switch
băng thông khả dụng thiết lập (có sự tham gia của
Nếu đường đi của bên gửi mạng)
bị tắc nghẽn: NI bit: không tăng tốc độ (tắc
Bên gửi điều chỉnh tốc nghẽn nhẹ)
độ đảm bảo tối thiểu CI bit: tắc nghẽn
RM cell trả về cho bên gửi bởi
bên nhận với các bít không thay
đổi
1-78
Trường hợp nghiên cứu:
Điều khiển tắc nghẽn ATM ABR
Hai byte ER (Explicit Rate) trong RM cell

Switch tắc nghẽn có thể giảm giá trị ER trong cell
Vì vậy, tốc độ gửi của bên gửi tối thiểu tốc độ hỗ trợ trên đường
Bít EFCI trong cell dữ liệu: đặt bằng 1 trong switch bị tắc nghẽn
Nếu cell dữ liệu, trước cell RM, có EFCI thiết lập, bên gửi thiết lập bít
CI trong cell RM trả về
1-79
của TCP
1-80
Điều khiển tắc nghẽn của TCP
Điều khiển end-end (không có hỗ trợ Cách bên gửi nhận biết sự tắc
của mạng) nghẽn?
Bên gửi giới hạn truyền: Sự kiện mất gói = timeout
LastByteSent-LastByteAcked hoặc lặp lại 3 ack
≤ CongWin Bên gửi TCP giảm tốc độ
LastByteSent - LastByteAcked <= min{CongWin, (CongWin) sau sự kiện mất
RcvWin} gói
Gần đúng, Ba cơ chế:
CongWin AIMD
rate = Bytes/sec slow start
RTT
Không thay đổi sau sự kiện
CongWin thay đổi động, chức năng timeout
nhận biết sự tắc nghẽn của mạng
1-81
TCP AIMD
Giảm cấp số nhân: Giảm Tăng cấp số cộng: Tăng
CongWin một nửa sau CongWin 1 MSS mỗi
sự kiện mất gói RTT khi không có sự
kiện mất gói
congestion
window
24 Kbytes
16 Kbytes
8 Kbytes
time
Kết nối TCP trong thời gian dài

1-82
TCP Slow Start
Khi kết nối bắt đầu, tăng
Khi kết nối bắt đầu,
CongWin = 1 MSS tốc độ nhanh theo hàm
mũ cho đến khi có sự
Ví dụ: MSS = 500 byte &
RTT = 200 msec kiện mất gói đầu tiên
Tốc độ ban đầu = 20 kbps
Băng thông khả dụng có
thể >> MSS/RTT
Mong muốn nhanh tới tốc
độ đáng kể
1-83
TCP Slow Start (tiếp)
Khi kết nối bắt đầu, Host A Host B
tăng tốc độ hàm mũ tới
khi có sự kiện mất gói 1 segmen
t
RTT
đầu tiên:
Gấp đôi CongWin mỗi 2 segmen
ts
RTT
Thự hiện bằng cách tăng
CongWin cho mọi ACK
nhận được 4 segmen
ts
Tóm lại: tốc độ ban đầu

là chậm nhưng nhanh
chóng tăng theo hàm
mũ time
1-84
Quá trình tinh chỉnh
Triết lý:
Sau 3 ACK lặp lại:
• 3 ACK lặp chỉ rằng khả
CongWin giảm một nửa
năng của mạng chuyển
window tăng tuyến tính một số segment
Nhưng sau sự kiện timeout: • timeout trước 3 ACK lặp
CongWin thay vì thiết là đáng chú ý hơn
lập 1 MSS;
window tăng hàm mũ
Tới ngưỡng thì giảm
tuyến tính
1-85
Quá trình tinh chỉnh (tiếp)
Q: Khi nào tăng theo
số mũ chuyển thành
theo tuyến tính?
A: Khi CongWin có giá
trị bằng 1/2 giá trị
của nó trước khi
timeout.
Thực hiện:
Variable Threshold
Tại sự kiện mất gói,
Threshold đặt bằng ½
CongWin ngay trước sự kiện
mất gói
1-86
Tổng kết: Điều khiển tắc nghẽn của TCP
Khi CongWin nhỏ hơn Threshold, bên gửi trong

pha slow-start, window lớn theo hàm mũ.
Khi CongWin lớn hơn Threshold, bên gửi trong
pha congestion-avoidance, window lớn theo hàm
tuyến tính.
Khi xảy ra lặp 3 ACK, Threshold đặt bằng
CongWin/2 và CongWin đặt bằng Threshold.
Khi timeout xảy ra, Threshold đặt bằng

CongWin/2 và CongWin đặt bằng 1 MSS.
1-87
Điều khiển tắc nghẽn bên gửi của TCP
Sự kiện Trạng thái Hành động bên gửi TCP Giải thích
Nhận ACK Slow Start CongWin = CongWin + MSS, Kết quả bởi gấp đôi CongWin
cho dữ liệu (SS) If (CongWin > Threshold) mỗi RTT
không được Đặt trạng thái thành
ack trước đó “Congestion Avoidance”
Nhận ACK Congestion CongWin = CongWin+MSS * Tăng theo cấp số cộng, tăng
cho dữ liệu Avoidance (MSS/CongWin) CongWin lên 1 MSS mỗi RTT
không được (CA)
ack trước đó
Sự kiện mất SS hoặc CA Threshold = CongWin/2, Nhanh chóng phục hồi, thực
gói phát hiện CongWin = Threshold, hiện tăng cấp số nhân.
bởi 3 ACK lặp Đặt trạng thái thành “Congestion CongWin sẽ không giảm dưới
Avoidance” 1 MSS.
Timeout SS hoặc CA Threshold = CongWin/2, Vào slow start
CongWin = 1 MSS,
Đặt trạng thái thành “Slow Start”
ACK lặp SS hoặc CA Tăng bộ đếm ACK lặp cho CongWin và Threshold không
segment được ack thay đổi
1-88
Thông lượng của TCP
Thông lượng trung bình của TCP từ chức
năng của window size và RTT?
Bỏ qua slow start
Cho W là window size khi xảy ra mất gói.
Khi window là W, thông lượng là W/RTT
Ngay sau mất gói, window giảm tới W/2,
thông lượng W/2RTT.
Thông lượng trung bình: .75 W/RTT
1-89
Tương lai của TCP
Ví dụ: 1500 byte segment, 100ms RTT, muốn 10
Gbps thông lượng
Đòi hỏi window size W = 83,333 segment
Thông lượng theo tốc độ mất gói:
1.22 ⋅ MSS
RTT L
➜ L = 2·10-10
Phiên bản mới của TCP cho tốc độ cao là cần thiết!
1-90
Sự công bằng của TCP
Mục đích của sự công bằng: Nếu K phiên TCP dùng
chung đường truyền thắt nút băng thông R, mỗi
đường nên có tốc độ trung bình là R/K
Kết nối TCP 1
điểm thắt nút

Kết
khả năng R
nối TCP 2
1-91
Lý do TCP công bằng
Hai phiên cạnh tranh:
R Chia sẻ băng thông bằng nhau

Thông lượng của kết nối 2
mất gói: giảm window hệ số 2

tránh tắc nghẽn: tăng cộng
Thông lượng của kết nối 1 R
1-92
Sự công bằng (tiếp)
Sự công bằng và UDP Sự công bằng và các kết nối
Các ứng dụng đa
TCP song song
phương tiện thường Không ngăn chặn ứng dụng
không sử dụng TCP mở song song các kết nối
Không muốn tốc độ giảm giữa 2 host
bởi điều khiển tắc nghẽn Trình duyệt Web thực hiện
Ứng dụng sử dụng như trên
UDP:
Đẩy dữ liệu audio/video
ở tốc độ hằng số, chấp
nhận mất gói
1-93
Mô hình độ trễ
Giả sử một đường truyền giữa
Q: Thời gian để nhận một đối client và server có tốc độ R
tượng từ Web server sau S: MSS (bits)
khi gửi một yêu cầu? O: kích thước đối tượng (bit)
Bỏ qua tắc nghẽn, độ trễ ảnh Không truyền lại (không mất
gói, không lỗi)
hưởng bởi:
Thiết lập kết nối TCP Kích thước cửa sổ:
Độ trễ truyền dữ liệu Cửa sổ tắc nghẽn cố định,
W segment
Cửa số động, mô hình slow
start
1-94
Cửa sổ tắc nghẽn cố định
Trường hợp 1:
WS/R > RTT + S/R: ACK
cho segment đầu tiên
trong cửa sổ
Độ trễ = 2RTT + O/R
1-95
Cửa sổ tắc nghẽn cố định
Trường hợp 2:
WS/R < RTT + S/R: đợi
ACK sau khi gửi lượng dữ
liệu của cửa sổ
Độ trễ = 2RTT + O/R

+ (K-1)[S/R + RTT - WS/R]
1-96
Mô hình độ trễ TCP: Slow Start (1)
Giả sử cửa sổ lớn theo slow start
Độ trễ cho một đối tượng là:

O ⎡ S⎤ S
Latency = 2 RTT + + P ⎢ RTT + ⎥ − ( 2 P − 1)
R ⎣ R⎦ R
Trong đó, P là lượng thời gian TCP rỗi tại server
P = min{Q, K − 1}
- Trong đó, Q là lượng thời gian server rỗi nếu đối tượng kích thước
không giới hạn.
- Và K là số cửa sổ trùm qua đối tượng
1-97
Mô hình độ trễ TCP: Slow Start (2)
Các thành phần trễ: initiate TCP
connection
• 2 RTT để thiết lập kết
nối và yêu cầu request
object
• O/R để truyền đối first window
= S/R
tượng
• thời gian server rỗi vì RTT
second window
slow start = 2S/R
Server rỗi: third window

= 4S/R
P = min{K-1,Q} times
fourth window
Ví dụ: = 8S/R
• O/S = 15 segment
• K = 4 windows
•Q=2
• P = min{K-1,Q} = 2 object
complete
transmission
delivered
time at
Thời gian rỗi của server time at server
P=2 times client
1-98
Mô hình độ trễ TCP (3)
S thời gian khi server bắt đầu
+ RTT = gửi segment tới khi server
R
nhận ack segment
initiate TCP
connection
S
2 k −1 = thời gian để truyền cửa sổ request
object
R first window
thứ k = S/R
+ RTT
⎡S k −1 S ⎤
second window
⎢R + RTT − 2 ⎥ = thời gian rỗi sau = 2S/R
⎣ R⎦ cửa sổ thứ k
third window
= 4S/R
P
O
delay = + 2 RTT + ∑ idleTime p fourth window
= 8S/R
R p =1
P
O S S
= + 2 RTT + ∑ [ + RTT − 2 k −1 ]
R k =1 R R object
complete
transmission
delivered
O S S
= + 2 RTT + P[ RTT + ] − (2 P − 1) time at
time at
server
R R R client
1-99
Mô hình độ trễ TCP (4)
K = số cửa sổ bao đối tượng
Cách tính K?
K = min{k : 20 S + 21 S + L + 2 k −1 S ≥ O}
= min{k : 20 + 21 + L + 2 k −1 ≥ O / S}
O
= min{k : 2 − 1 ≥ }
k
S
O
= min{k : k ≥ log 2 ( + 1)}
S
⎡ O ⎤
= ⎢log 2 ( + 1)⎥
⎢ S ⎥
Tính Q, giá trị rỗi cho đối tượng có kích thước không giới hạn tương tự.
1-
100
Mô hình hóa HTTP
Giả sử trang Web chứa:
1 trang HTML cơ sở (kích thước O bít)
M ảnh (mỗi ảnh kích thước O bít)
Non-persistent HTTP:
M+1 kết nối TCP
Response time = (M+1)O/R + (M+1)2RTT + tổng thời gian rỗi
Persistent HTTP:
2 RTT để yêu cầu và nhận file HTML cơ sở
1 RTT để yêu cầu và nhận M ảnh
Response time = (M+1)O/R + 3RTT + tổng thời gian rỗi
Non-persistent HTTP với X kết nối song song
Giả sử M/X nguyên
1 kết nối TCP cho file cơ sở
M/X tập của các kết nối song song cho ảnh
Response time = (M+1)O/R + (M/X + 1)2RTT + tổng thời gian rỗi
1-
101
Thời gian trả lời HTTP (giây)
RTT = 100 msec, O = 5 Kbytes M=10 và X=5
20
18
16
14
non-persistent
12
10
persistent
8
6
parallel non-
4
persistent
2
0
28 100 1 Mbps 10
Kbps Kbps Mbps
Đối với băng thông thấp, thời gian kết nối và thời gian phản hồi chi phối bởi
thời gian truyền
Persistent connection chỉ mang lại cải tiến thêm qua các kết nối song song
1-
102
Thời gian phản hồi (giây)
RTT =1 sec, O = 5 Kbyte, M=10 and X=5
70
60
50
non-persistent
40
30 persistent
20 parallel non-
10 persistent
0
28 100 1 Mbps 10
Kbps Kbps Mbps
Đối với RTT lớn, thời gian phản hồi chi phối bởi thiết lập kết nối TCP và độ trễ
slow start. Persistent connection đem lại cải tiến quan trọng: đặc biệt trong mạng
delay, bandwidth cao.
1-
103
Chương 3: Tổng kết
Các nguyên tắc bên trong
các dịch vụ tầng giao vận:
multiplexing,
demultiplexing
Điều khiển luồng Tiếp theo:
Điều khiển tắc nghẽn Dừng tìm hiểu phần bên
ngoài của mạng (tầng
Sự thực hiện trong Internet ứng dụng, tầng giao
UDP vận)
TCP Tìm hiểu vào trong lõi
của mạng
1-
104

BaiGiang C3

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

BaiGiang C3

Uploaded by

Copyright:

Available Formats

Mạng máy tính

Bộ môn Kỹ thuật máy tính và Mạng

segment, chuyển tới tầng network

 Bên nhận: ghép các application

 Nhiều hơn một giao thức giao

 Truyền tin cậy, có thứ tự application

không tin cậy: UDP network

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

transport transport transport

network network network

link link link

physical physical physical

Định dạng TCP/UDP segment

(a) Dịch vụ cung cấp (b) Cài đặt dịch vụ

Bên gửi Bên nhận

Sự kiện gây ra chuyển trạng thái

Đợi cuộc rdt_send(data) đợi cuộc rdt_rcv(packet)

Bên gửi Bên nhận

rdt_rcv(rcvpkt) && isACK(rcvpkt)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

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

 Tương tự rdt2.1, chỉ sử dụng ACK

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

(a) Không mất gói (b) Mất gói

(c) Mất ACK (c) Timeout

 Hiệu năng của rdt3.0 bị ảnh hưởng

T transmit = L (độ dài gói tin, bit) 8kb/pkt

 U sender: sự sử dụng – thời gian bên gửi bận gửi

bít của gói tin đầu tiên đến

ACK đến, gửi gói tin tiếp,

Window size = 4 pkt

 Bên nhận thấy không có

Q: Quan hệ giữa kích

dữ liệu ứng dụng

 Giá trị thường dùng: α = 0.125

SampleRTT Estimated RTT

Rồi thiết lập timeout:

 Dịch vụ tương ứng tốc

 Client: khởi tạo kết nối  Server khởi tạo seq. #

Đóng kết nối: client server

Bước 1: client gửi TCP FIN AC K

Bước 2: server nhận FIN, trả

thời gian đơị

Bước 3: client nhận FIN, trả client server

thời gian đợi

Chu kỳ hoạt động

Chu kỳ hoạt động

đệm không giới

 Độ trễ lớn khi

Host A lin : dữ liệu ban đầu lout

l'in : dữ liệu ban đầu, dữ liệu

Host B vùng đệm của đường

R/2 R/2 R/2

Tác hại khác của tắc nghẽn:

Điều khiển tắc nghẽn Điều khiển tắc nghẽn với

 Hai byte ER (Explicit Rate) trong RM cell

Kết nối TCP trong thời gian dài

 Tóm lại: tốc độ ban đầu

 Khi CongWin nhỏ hơn Threshold, bên gửi trong

 Khi timeout xảy ra, Threshold đặt bằng

Kết nối TCP 1

điểm thắt nút

Bên nhận: ghép các application

Nhiều hơn một giao thức giao

Truyền tin cậy, có thứ tự application

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

Tương tự rdt2.1, chỉ sử dụng ACK

Hiệu năng của rdt3.0 bị ảnh hưởng

U sender: sự sử dụng – thời gian bên gửi bận gửi

Bên nhận thấy không có

Giá trị thường dùng: α = 0.125

Dịch vụ tương ứng tốc

Client: khởi tạo kết nối Server khởi tạo seq. #

Độ trễ lớn khi

Hai byte ER (Explicit Rate) trong RM cell

Tóm lại: tốc độ ban đầu

Khi CongWin nhỏ hơn Threshold, bên gửi trong

Khi timeout xảy ra, Threshold đặt bằng