Please enable JavaScript.
Coggle requires JavaScript to display documents.
CHƯƠNG 3 — TẦNG VẬN CHUYỂN (TRANSPORT LAYER) - Coggle Diagram
CHƯƠNG 3 — TẦNG VẬN CHUYỂN (TRANSPORT LAYER)
CÁC DỊCH VỤ TẦNG VẬN CHUYỂN ⭐ [PDF 3–8]
1.1. Mục tiêu và phạm vi [PDF 3–5]
Logical communication — truyền thông luận lý giữa các process trên host khác nhau
Các giao thức tầng vận chuyển hoạt động ở hệ thống đầu cuối
Hai giao thức chính — TCP và UDP
Mối quan hệ — Application → Transport → Network (IP)
1.2. Hoạt động tại bên gửi [PDF 5–6]
B1 — Nhận message từ tầng ứng dụng
B2 — Xác định thông tin transport header
B3 — Ghép header + application message → segment
B4 — Chuyển segment xuống tầng mạng
1.3. Hoạt động tại bên nhận [PDF 5,7]
B1 — Nhận segment từ tầng mạng
B2 — Kiểm tra giá trị header
B3 — Bỏ header, trích xuất application message
B4 — Chuyển message đến socket tương ứng
1.4. Dịch vụ TCP [PDF 8]
Transmission Control Protocol
Tin cậy (reliable)
Truyền đúng thứ tự
Điều khiển luồng (flow control)
Thiết lập kết nối (connection-oriented)
1.5. Dịch vụ UDP [PDF 8]
User Datagram Protocol
Best effort trên IP
Không đảm bảo tin cậy
Không đảm bảo thứ tự nhận dữ liệu
Không kết nối (connectionless)
1.6. Giới hạn của dịch vụ [PDF 8]
Không đảm bảo độ trễ
Không đảm bảo băng thông
1.7. ⚠ Dễ nhầm
Logical communication khác đường truyền vật lý trực tiếp
TCP/UDP vận chuyển giữa process; IP chuyển datagram giữa host
Key takeaway
Tầng vận chuyển nối logic các process trên hệ thống đầu cuối
Bên gửi tạo segment; bên nhận tách segment và giao đúng socket
TCP tin cậy; UDP best-effort
MULTIPLEXING VÀ DEMULTIPLEXING ⭐ [PDF 10–22]
2.1. Vấn đề định danh process [PDF 10–16]
Ví dụ — Firefox, Netflix, Skype trên cùng host
Mục tiêu — phân biệt socket nhận đúng message
IP datagram chứa transport segment
Segment chứa source port và destination port
2.2. Multiplexing — bên gửi [PDF 17]
B1 — Nhận dữ liệu từ nhiều socket
B2 — Thêm transport header
B3 — Chuyển segment xuống tầng mạng
2.3. Demultiplexing — bên nhận [PDF 17–18]
B1 — Nhận IP datagram
B2 — Lấy thông tin IP và transport header
B3 — Dựa vào header để chọn socket
B4 — Chuyển dữ liệu đến socket phù hợp
2.4. Trường định danh [PDF 18]
Source IP address
Destination IP address
Source port number
Destination port number
Sơ đồ header — source port | destination port | other fields | payload
2.5. UDP demultiplexing — Connectionless [PDF 19,22]
Căn cứ chính — destination port number
Các datagram có cùng destination port → cùng UDP socket (trong ví dụ)
Mỗi datagram vẫn mang source/destination IP và port
Ví dụ source port 9157 → destination port 6428
Ví dụ chiều ngược source port 6428 → destination port 9157
2.6. TCP demultiplexing — Connection-oriented [PDF 20–22]
TCP connection socket — 4-tuple
Source IP address
Source port number
Destination IP address
Destination port number
Dựa vào cả 4 giá trị để chọn socket
Một TCP server hỗ trợ nhiều connection socket
Nhiều client cùng truy cập server port 80 → socket riêng
2.7. So sánh UDP vs TCP demux ⭐ [PDF 22]
UDP — destination port number
TCP — source/destination IP + source/destination port
Multiplexing/demultiplexing cũng tồn tại ở các tầng khác
2.8. Socket trong sơ đồ cũ [PDF 17–22]
Socket — điểm giao tiếp giữa transport và application process
TCP client: connect() — minh họa kết nối ở PDF 98
TCP server: accept() — minh họa nhận kết nối ở PDF 98
UDP: socket(AF_INET, SOCK_DGRAM) — ví dụ PDF 19
TCP: socket(AF_INET, SOCK_STREAM) — ví dụ PDF 19,98
2.9. Giữ dấu vết từ sơ đồ Coggle gốc — ngoài phần được slide xác nhận
⚠ Danh sách port dịch vụ — Không thấy nội dung này trong tài liệu đã cung cấp.
Coggle gốc — DNS: UDP/TCP 53
Coggle gốc — FTP: TCP 20, 21
Coggle gốc — HTTP: TCP 80
Coggle gốc — HTTPS: TCP 443
Coggle gốc — SMTP: TCP 25
⚠ Các lệnh Socket UDP send/receive trong Coggle gốc — Không thấy nội dung này trong tài liệu đã cung cấp.
Chỉ đối chiếu được socket(AF_INET, SOCK_DGRAM) và bind() ở slide 19
⚠ Dễ nhầm
UDP không chọn socket theo 4-tuple như TCP
Cùng server port TCP không có nghĩa cùng connection socket
Key takeaway
Multiplexing gom thông điệp từ nhiều socket tại bên gửi
Demultiplexing giao đúng socket tại bên nhận
UDP dùng destination port; TCP dùng 4-tuple
UDP — USER DATAGRAM PROTOCOL ⭐ [PDF 24–35]
3.1. Khái niệm / RFC [PDF 24,26]
User Datagram Protocol — RFC 768
Giao thức vận chuyển đơn giản
Best effort — không cam kết giao thành công
Segment có thể mất hoặc sai thứ tự
3.2. Connectionless [PDF 24]
Không có bước thiết lập kết nối
Không lưu trạng thái kết nối
Mỗi segment xử lý độc lập
3.3. Vì sao vẫn dùng UDP? [PDF 24]
Bỏ qua độ trễ thiết lập kết nối
Header nhỏ gọn
Cơ chế đơn giản
Có thể gửi segment ngay khi có thể
Không điều khiển tắc nghẽn tại UDP — đặc điểm được nêu trên slide
3.4. Ứng dụng dùng UDP [PDF 25]
Streaming multimedia apps — loss tolerant, rate sensitive
DNS
SNMP
HTTP/3
Nếu cần truyền tin cậy — bổ sung thêm xử lý tin cậy tại tầng ứng dụng
Nếu cần truyền tin cậy — bổ sung thêm điều khiển tắc nghẽn ở tầng ứng dụng (theo slide)
3.5. Hoạt động UDP — hình SNMP Client/Server [PDF 27–29]
Sender — nhận SNMP message từ Application
Sender — xác định UDP header
Sender — tạo UDP segment
Sender — gửi xuống IP
Receiver — nhận segment từ IP
Receiver — kiểm tra checksum
Receiver — bỏ UDP header và lấy message
Receiver — chuyển qua socket lên Application
3.6. UDP header ⭐ [PDF 30]
Tổng chiều rộng mỗi hàng — 32 bits
Source port number — 16 bits
Destination port number — 16 bits
Length — chiều dài UDP segment gồm header và data
Checksum — phát hiện lỗi bit
Payload — application data
3.7. UDP checksum ⭐ [PDF 31–34]
Mục tiêu — phát hiện lỗi bit (0 ↔ 1)
Sender — chia dữ liệu dùng tính checksum thành các từ 16 bit
Sender — tính tổng bù 1 (one’s complement sum)
Sender — ghi giá trị checksum vào UDP header
Receiver — tính checksum từ segment nhận
Receiver — so sánh checksum
Khác nhau → phát hiện lỗi
Bằng nhau → không phát hiện lỗi; không khẳng định không có lỗi
Công thức / thao tác — one’s complement sum
Cộng các từ 16 bit
Nếu có bit nhớ thứ 17 → cộng vòng về 16 bit thấp (wraparound)
Lấy bù 1 của tổng → checksum
Ví dụ PDF 33 — hai chuỗi 16-bit
1110011001100110
1101010101010101
Sum — 1011101110111100
Checksum — 0100010001000011
⚠ Điểm yếu — hai lỗi bit bù trừ có thể không thay đổi checksum
3.8. Tổng kết UDP [PDF 35]
Đơn giản, connectionless, best effort
Có checksum kiểm tra lỗi
Tính năng nâng cao có thể xử lý ở tầng ứng dụng
Key takeaway
UDP không thiết lập kết nối, không đảm bảo tin cậy hoặc thứ tự
UDP header gồm 4 trường 16-bit
Checksum chỉ phát hiện được một số lỗi; không tuyệt đối
NGUYÊN LÝ TRUYỀN TIN CẬY — RELIABLE DATA TRANSFER ⭐ [PDF 37–79]
4.1. Mục tiêu / mô hình [PDF 37–40]
Tầng ứng dụng nhìn thấy reliable channel
Triển khai rdt qua unreliable channel
Kênh có thể gây lỗi bit, mất gói, đảo thứ tự
Hai phía không tự biết trạng thái của nhau
Chỉ trao đổi trạng thái thông qua message
Sử dụng FSM — Finite State Machine
4.2. Giao diện RDT [PDF 41]
rdt_send(data) — Application gọi để yêu cầu gửi
udt_send(packet) — RDT gửi qua kênh không tin cậy
rdt_rcv(packet) — báo RDT có packet nhận về
deliver_data(data) — chuyển dữ liệu lên tầng ứng dụng
4.3. RDT1.0 — kênh hoàn toàn tin cậy [PDF 44–45]
Điều kiện — không lỗi và không mất packet
Sender B1 — rdt_send(data)
Sender B2 — make_pkt(data)
Sender B3 — udt_send(packet)
Receiver B1 — rdt_rcv(packet)
Receiver B2 — extract(packet,data)
Receiver B3 — deliver_data(data)
4.4. RDT2.0 — kênh gây lỗi bit [PDF 46–50]
Vấn đề — packet có thể corrupt
Checksum — phát hiện lỗi
ACK — xác nhận nhận thành công
NAK — thông báo lỗi
Sender — nhận ACK → chuyển packet tiếp
Sender — nhận NAK → gửi lại packet
Receiver — corrupt → gửi NAK
Receiver — not corrupt → giao data và gửi ACK
Giới hạn — ACK/NAK cũng có thể bị lỗi
4.5. RDT2.1 — xử lý ACK/NAK lỗi [PDF 51–54]
Vấn đề RDT2.0 — ACK lỗi có thể gây gửi lại và giao data trùng
Giải pháp — đánh số packet 0,1
Sender — gửi pkt0, đợi ACK0
ACK0 lỗi → gửi lại pkt0
Receiver — phát hiện pkt0 trùng nhờ sequence number
Receiver — không giao dữ liệu trùng lên Application
ACK0 hợp lệ → gửi pkt1
Luân phiên sequence number {0,1}
4.6. RDT2.2 — không dùng NAK [PDF 55–58]
Tính năng giống RDT2.1
Chỉ dùng ACK
Receiver — gửi ACK cho packet cuối nhận đúng
ACK chứa sequence number đã xác nhận
Sender — nhận duplicate ACK → gửi lại packet chưa xác nhận
Mục tiêu — thay NAK bằng duplicate ACK
4.7. RDT3.0 — packet/ACK có thể mất [PDF 59–63]
Vấn đề — mất data packet hoặc ACK
Có thể đã có checksum, sequence number và ACK
Thêm bộ định thì (timer)
Sender — gửi packet, khởi động timer
ACK hợp lệ trước timeout → chuyển packet kế
Timeout → gửi lại packet chưa được ACK
ACK chỉ bị trễ → có thể gửi lại trùng
Sequence number → phát hiện và xử lý packet trùng
Stop-and-wait — gửi một packet rồi đợi ACK
4.8. Công thức hiệu suất Stop-and-Wait ⭐ [PDF 64–66]
D_trans = L/R
L — số bit trong packet
R — tốc độ truyền link (bit/s)
U_sender = (L/R) / (RTT + L/R)
U_sender — phần thời gian sender thực sự truyền
RTT — thời gian khứ hồi
Điều kiện — mô hình stop-and-wait trong slide
Ví dụ — L=8000 bit; R=1 Gbps; trễ lan truyền một chiều 15 ms
Kết quả — L/R = 8 microseconds
Kết quả — RTT ≈ 30 ms; U_sender ≈ 0.00027
Kết luận — stop-and-wait có utilization thấp
4.9. Pipelining ⭐ [PDF 69–70]
Gửi nhiều packet liên tiếp trước khi nhận ACK
Sequence numbers tăng theo các packet
Có buffer tại sender hoặc receiver
Ví dụ 3 packet — U_sender ≈ 3(L/R)/(RTT+L/R)
Ví dụ trong slide — U_sender ≈ 0.00081
Hiệu suất tăng khoảng 3 lần so với ví dụ stop-and-wait
4.10. Go-Back-N (GBN) ⭐ [PDF 71–72]
Sender window tối đa N packet chưa cần ACK
k-bit sequence number trong header
Cumulative ACK — ACK(n) xác nhận tới packet n
Timer cho packet lâu nhất chưa ACK
Timeout(n) → gửi lại packet n và các packet sau trong window
Receiver — packet đúng thứ tự → ACK packet đúng thứ tự cao nhất
Receiver — packet sai thứ tự → có thể bỏ / buffer tùy triển khai
Receiver — gửi lại ACK cho packet đúng thứ tự cao nhất
Ví dụ cửa sổ N=4 [PDF 73]
B1 — gửi pkt0, pkt1, pkt2, pkt3
B2 — pkt2 bị mất
B3 — pkt3, pkt4, pkt5 đến sai thứ tự
B4 — receiver loại bỏ, gửi lại ACK1 trong ví dụ
B5 — pkt2 timeout
B6 — sender gửi lại pkt2, pkt3, pkt4, pkt5
B7 — receiver nhận và giao đúng thứ tự
4.11. Selective Repeat (SR) ⭐ [PDF 75–79]
Sender có window kích thước N
Receiver gửi ACK cho từng packet nhận đúng
Receiver buffer packet đến sai thứ tự
Timer riêng cho packet chưa được ACK
Timeout(n) → chỉ gửi lại packet n
Sender — ACK(n) đánh dấu packet n đã nhận
Sender — dịch window khi gói đầu window đã ACK
Receiver trong window — ACK, buffer nếu out-of-order
Receiver đủ packet liên tiếp — deliver và dịch window
Receiver nhận gói thuộc window trước — ACK lại
Ví dụ cửa sổ N=4 [PDF 78]
B1 — sender gửi pkt0–pkt3
B2 — pkt2 mất; receiver ACK0, ACK1
B3 — pkt3–pkt5 tới → ACK riêng và buffer
B4 — timeout pkt2 → chỉ retransmit pkt2
B5 — nhận pkt2 → deliver pkt2–pkt5 theo thứ tự
⚠ Vấn đề sequence number wraparound [PDF 77]
Ví dụ sequence number {0,1,2,3}, window=3
Trường hợp packet cũ bị chậm → dễ nhầm với packet mới
Cần phân biệt window nhận và chu kỳ số thứ tự
4.12. Đối chiếu Go-Back-N vs Selective Repeat ⭐
ACK — GBN tích lũy; SR từng packet
Out-of-order — GBN ví dụ bỏ gói; SR lưu buffer
Timeout — GBN gửi lại nhiều gói; SR chỉ gửi gói lỗi
Buffer receiver — SR cần buffer packet sai thứ tự
⚠ Dễ nhầm
ACK bị lỗi khác data packet bị mất
rdt2.1 dùng số thứ tự để tránh giao data trùng
RDT3.0 không đồng nghĩa đã có pipelining
Timeout GBN khác Timeout SR
Key takeaway
RDT tiến hóa theo lỗi: bit error → ACK/NAK lỗi → packet loss
Stop-and-wait đơn giản nhưng utilization kém; pipelining cải thiện
GBN retransmit từ gói mất; SR retransmit gói mất riêng lẻ
TCP — TRANSMISSION CONTROL PROTOCOL ⭐ [PDF 79–101]
5.1. Tổng quan TCP [PDF 82]
RFCs — 793, 1122, 2018, 5681, 7323
Point-to-point — 1 sender và 1 receiver trên kết nối
Reliable — truyền tin cậy
Ordered byte stream — đúng thứ tự theo byte
Full duplex — hai chiều cùng một kết nối
Connection-oriented — handshake thiết lập/đóng
Cumulative ACKs
Pipelining theo cửa sổ
MSS — Maximum Segment Size
Flow-controlled — tránh tràn buffer bên nhận
5.2. TCP Segment Header ⭐ [PDF 83]
Source port #; Destination port #
Sequence number
Acknowledgement number
Header length (headlen)
Flags — ACK; URG; PSH; RST; SYN; FIN
Receive window
Checksum
Urgent data pointer
Options — độ dài thay đổi
Header tối thiểu 20 bytes — theo sơ đồ 5 hàng × 32 bits
Application data — variable-length payload
Sequence number đếm byte, không đếm segment
5.3. TCP Reliable Data Transfer ⭐ [PDF 84]
Sequence number — xác định thứ tự byte
ACK number — byte kế tiếp receiver muốn nhận
Segment lỗi checksum → bị loại bỏ
Segment mất → truyền lại sau timeout
5.4. Sequence Number và ACK [PDF 86–87]
Ví dụ message = 9000 bytes
MSS tối đa theo ví dụ = 2000 bytes
Chia thành 5 segment (2000,2000,2000,2000,1000)
Seq 0, length 2000 → ACK 2000
Seq 2000, length 2000 → ACK 4000
Seq 4000, length 2000 → ACK 6000
Seq 6000, length 2000 → ACK 8000
Seq 8000, length 1000 → ACK 9000
Ví dụ duplex — Host A Seq=42, ACK=79, data 30B
Ví dụ duplex — Host B Seq=79, ACK=72, data 50B
Ví dụ duplex — Host A Seq=72, ACK=129
5.5. RTT và Timeout ⭐ [PDF 88–90]
SampleRTT — thời gian gửi segment tới khi nhận ACK
Không tính SampleRTT từ segment được truyền lại
RTT thay đổi theo thời gian
Timeout quá ngắn → retransmission không cần thiết
Timeout quá dài → phản ứng chậm với segment mất
Công thức EstimatedRTT
EstimatedRTT = (1−α) × EstimatedRTT + α × SampleRTT
EWMA — Exponential Weighted Moving Average
α = 0.125 (giá trị tiêu biểu)
Công thức DevRTT
DevRTT = (1−β) × DevRTT + β × |SampleRTT − EstimatedRTT|
β = 0.25 (giá trị tiêu biểu)
Công thức TimeoutInterval
TimeoutInterval = EstimatedRTT + 4 × DevRTT
DevRTT — biên độ an toàn (safety margin)
5.6. TCP Sender — các sự kiện [PDF 91]
Nhận data từ Application — tạo segment
Seq — số thứ tự byte đầu của segment
Nếu timer chưa chạy → khởi động
Timeout — retransmit segment bị timeout
Timeout — bắt đầu tính lại thời gian
Nhận ACK của dữ liệu chưa ACK — cập nhật trạng thái
Nhận ACK mới — tính lại thời gian cho segment chưa ACK
5.7. TCP Receiver — ACK Generation ⭐ [PDF 92]
Đúng thứ tự, đã ACK hết trước đó — chờ tối đa 500 ms
Nếu không có segment tiếp theo — gửi ACK
Có segment kế tiếp đang chờ ACK — ACK tích lũy cho hai segment
Nhận out-of-order cao hơn expected — gửi duplicate ACK ngay
Nhận gói lấp khoảng trống — ACK ngay cho segment có thứ tự thấp nhất trong khoảng bị trống
5.8. TCP Retransmission ⭐ [PDF 93–95]
Mất ACK — timeout có thể gây retransmission
Cumulative ACK mới có thể bao phủ ACK cũ bị mất
Truyền lại do timeout
Fast Retransmit — nhận 3 duplicate ACK
3 duplicate ACK → gửi lại segment bị nghi mất, không chờ timeout
Đây là cơ chế reliability, không phải mục Congestion Control bị loại
5.9. TCP Flow Control — điều khiển luồng ⭐ [PDF 96–100]
Vấn đề — tốc độ nhận từ mạng lớn hơn tốc độ App lấy từ buffer
Receiver buffer có nguy cơ tràn
Receive window — rwnd
Receiver quảng bá phần buffer còn trống qua rwnd
Sender giới hạn dữ liệu chưa ACK theo rwnd đã quảng bá
Mục tiêu — không gửi quá nhanh làm tràn buffer của receiver
⚠ Flow control bảo vệ receiver buffer
5.10. TCP Connection Management ⭐ [PDF 101–102]
Trước truyền data phải handshake
Mục tiêu — hai phía xác nhận sẵn sàng
Đồng ý tham số kết nối (initial seq numbers)
3-way handshake
B1 — Client SYN=1, Seq=x
B2 — Server SYN=1, Seq=y, ACK=1, ACKnum=x+1
B3 — Client ACK=1, ACKnum=y+1
Sau handshake — hai phía vào ESTAB
Ví dụ socket API tại hình [PDF 102]
Server — socket(AF_INET, SOCK_STREAM)
Server — bind() → listen() → accept()
Client — socket(AF_INET, SOCK_STREAM) → connect()
5.11. TCP Connection Termination ⭐ [PDF 108–109]
Mỗi phía đóng chiều gửi của mình
FIN bit = 1 — yêu cầu đóng chiều gửi
Nhận FIN → đáp ACK
Có thể gộp ACK với FIN
Có thể trao đổi FIN đồng thời
Ví dụ đóng kết nối theo sơ đồ
B1 — Client FIN=1, Seq=x
B2 — Server ACK=1, ACKnum=x+1
B3 — Server FIN=1, Seq=y
B4 — Client ACK=1, ACKnum=y+1
Client — FIN_WAIT_1 → FIN_WAIT_2 → TIMED_WAIT → CLOSED
Server — CLOSE_WAIT → LAST_ACK → CLOSED
TIMED_WAIT — chờ 2 × maximum segment lifetime
5.12. ⚠ Dễ nhầm
Sequence number đếm byte; không đếm segment
ACK number là byte tiếp theo mong đợi
Fast Retransmit thuộc TCP reliable transfer
Flow control thuộc mục TCP; không loại bỏ
SYN/SYN-ACK/ACK thiết lập; FIN/ACK đóng kết nối
Key takeaway
TCP reliable, in-order, full-duplex và hướng kết nối
Seq/ACK + retransmission xử lý mất/lỗi; rwnd xử lý flow control
Kết nối TCP được thiết lập qua 3-way handshake và đóng bằng FIN/ACK
SỰ PHÁT TRIỂN TÍNH NĂNG TẦNG VẬN CHUYỂN [PDF 115–120]
6.1. Evolving Transport-Layer Functionality [PDF 115]
TCP và UDP — giao thức vận chuyển chính trong khoảng 40 năm
Các kiểu ứng dụng mới có các thử thách khác nhau
Long, fat pipes — nhiều packet in flight; loss làm ngưng pipeline
Wireless networks — nhiễu đường truyền và mobility
Long-delay links — RTT rất dài
Data center networks — nhạy độ trễ
Background traffic flows — ưu tiên thấp
Chuyển tính năng transport lên application trên UDP
Ví dụ — HTTP/3 sử dụng QUIC
6.2. QUIC — Quick UDP Internet Connections ⭐ [PDF 116]
Application-layer protocol chạy trên UDP
Mục tiêu — cải thiện hiệu năng HTTP
Ví dụ triển khai — Google servers, Chrome, YouTube mobile app
Sơ đồ chồng giao thức trong slide
HTTP/2 over TCP (cùng TLS)
HTTP/3 / QUIC over UDP / IP
6.3. QUIC Multiplexed Streams [PDF 117]
Nhiều application-level streams trên một QUIC connection
Mỗi stream có xử lý reliable data transfer riêng
Security cho kết nối
Có điều khiển tắc nghẽn chung giữa các stream — chỉ nhắc theo slide
Kết nối và trạng thái bảo mật được thiết lập nhanh
6.4. Connection Establishment [PDF 118]
TCP + TLS — hai chuỗi handshake nối tiếp trong sơ đồ
QUIC — một handshake trong sơ đồ
QUIC khởi tạo connection + authentication + encryption state
Giảm chi phí thiết lập so với minh họa TCP + TLS
6.5. Streams và HOL Blocking [PDF 119]
Sơ đồ HTTP/1.1 — lỗi làm chậm dữ liệu phía sau
Sơ đồ QUIC streams — xử lý các stream song song
Một stream gặp lỗi không chặn tiến trình phục hồi stream khác trong hình
6.6. Tổng kết Chương 3 [PDF 120]
Multiplexing và Demultiplexing
Reliable Data Transfer
Flow Control
UDP và TCP
Phần tiếp theo — Network Layer
Key takeaway
QUIC vận hành ở Application trên UDP theo slide
QUIC có nhiều stream và gộp bước thiết lập trạng thái
Phạm vi đã loại — không triển khai TCP Congestion Control