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)
Ứng dụng sử dụng Port
HTTP: TCP 80
HTTPS: TCP 443
FTP: TCP 20,21
SMTP: TCP 25
DNS: UDP/TCP 53
Các dịch vụ và giao thức
Các dịch vụ
Cung cấp
truyền thông logic
(logical communication hay còn gọi là kết nối ảo) giũa các tiến trình khác nhau chạy trên Host
Các giao thức
Send side
Chia nhỏ các thông điệp ứng dụng thành các segment, sau đó chuyển các segment cho tầng Mạng
Receive side
tái kết hợp giữa các segment thành các thông điệp, các thông điệp này chuyển lên tầng Ứng dụng
Giao thức tầng Vận chuyển trên Internet
TCP
(tin cậy truyền theo thứ tự)
Điều khiển luồng
Thiết lập kết nối
Điều khiển tắc nghẽn
UDP
(Không tin cậy , truyền không theo thứ tự
Không rườm rà
"best effort"
Không có dịch vụ
Đảm bảo độ trễ
Đảm bảo băng thông
Khác nhau giữa
Transport Layer AND Network Layer
Netword Layer
Truyền thông logic giữa các Host
Transport Layer
Truyền thông logic giữa các tiến trình,
Dựa trên dịch vụ của tầng Network
Multiplexing/Demultiplexing
Multiplexing
(Nhập lại cùng với nhau để gửi ra)
Xử lý dữ liệu từ nhiều socket, thêm thông tin header về tầng Vận chuyển vào segment (được sử dụng sau cho demultiplexing)
Demultiplexing
(Khi tới nơi tôi sẽ tách ra)
sử dụng thông tin trong header để chuyển segment vừa nhận vào đúng socket
Host nhận các gói dữ liệu (datagram) IP
Mỗi gói dữ liệu mang một segment tầng Vận chuyển
Mỗi segment có số port nguồn và đích
Mỗi gói dữ liệu có địa chỉ IP nguồn và đích
Host dùng các địa chỉ IP và số port để gửi segment đến socket thích hợp
UDP (User Datagram Protocol)
giao thức tầng Vận chuyển: đơn giản, bare bones
Các segment UDP có thế
Mất mát
Vận chuyển không theo thứ tự đến ứng dụng đích
Connectionless (phi kết nối)
Mỗi segment UDP được xử lý độc lập
Không bắt tay giữa bên nhận và gửi UDP
Ứng dụng
Các ứng dụng đa phương trực tuyến (chịu mất mát (loss tolerant), cần tốc độ (rate sensitive))
SNMP (Simple Network Management Protocol)
DNS (Demain Name System)
Tại sao có UDP
Đơn giản: Không trạng thái kết nối tại nơi gửi và nhận
Kích thước header nhỏ
Không thiết lập kết nối (có thể gây ra độ trễ)
Không điều khiển tắc nghẽn: UDP có thể gửi dữ liệu nhanh như mong muốn
UDP Checksum
Mục tiêu: Dò tìm "các lỗi " (các bit cờ được bật) trong các segment đã được truyền
BÊN GỬI (SEND)
Xét nội dung của segment, bao gồm các trường của header, là chuỗi các số nguyên 16-bit
checksum: tổng bù 1 của các chuỗi số 16 bit trong nội dung segment
Bên gửi đặt giá trị chẹcksum vào trường checksum UDP
BÊN NHẬN (RECEIVE)
Tính toán checksum của segment đã nhận
Kiểm tra giá trị trên đó bằng với giá trị trong trường checksum hay không
NO: có lỗi xảy ra
YES: không có lỗi xảy ra
Truyền dữ liệu tin cậy (reliable data transfer)
rdt_receive: được gọi khi gói dữ liệu đến kênh của bên nhận
deliver_data: được gọi bởi rdt để chuyển dữ liệu đến tầng cao hơn
utd_send: được gọi bởi rdt , để truyền các gói trên kênh không tin cậy đên nơi nhận
rdt_send: được gọi bằng tầng app, chuyển dữ liệu cần truyền đến tầng app bên nhận
FSM
: finite state machines : dùng để xác định bên gửi và bên nhận
Nguyên lý truyền tin cậy
rdt 2.1
Vấn đề ACK/ NAK bị lỗi
Giair quyết: Đánh số {0,1} để tránh bị trùng dữ liệu
Bên gửi
Số thứ tự (Seq#) được thêm vào packet. 2 số thứ tự là 0 or 1 là đủ
Phải kiểm tra xem có hay không gói ACK/NAK bị hỏng
Số trạng thái tăng lên 2 lần: trạng thái "Nhớ" xem packet "Mong đợi" có số thứ tự là 0 hay 1
Bên nhận
Phải kiểm tra gói vừa nhận có bị trùng hay không
Trạng thái chỉ rõ có hay không 0 or 1 lá số thứ tự của gói đc mong đợi
Chú ý
có thể bên nhận không thể biết ACK/NAK vừa rồi có được bên gửi nhận tốt hay không
rdt 2.2
Bỏ gói NAK chỉ dùng gói ACK
Thay cho NAK, bên nhận gửi ACK cho gói cuối cùng được nhận thành công
Bên nhận phải ghi rõ số thứ tự của gói vừa được ACK
ACK bị trùng tại bên gửi dẫn tới kết quả giống như hành động của NAK: truyền lại gói vừa rồi
rdt 2.0
Vấn đề : dữ liệu lỗi
có thể bị đảo các bit trong packet=> checksum để kiểm tra các lỗi
Giải quyết : ACK / NAK
ACK: Acknowledgements
Bên nhận thông báo cho bên gửi rằng pacjket được nhận thành công
NAK: Negative acknowledgements
Bên nhận thông báo bên gửi rằng packet đã bị lỗi
Cơ chế mới của rdt 2.0
Phát hiện lỗi
Phản hồi : các thông điệp điều khiển (ACK/NAK) từ bên nhận đến bên gửi
rdt 3.0
Vấn đề: Mất dữ liệu
giải quyết: Thêm biến Timer
Bên gửi chờ ACK trong khoảng thời gian "hợp lý"
Truyền lại nếu không nhận được ACK nếu không nhận được trong khoảng thời gian này
Nếu gói (or ACK) bị trễ không mất
Việc truyền lại sẽ gây trùng , nhưng số thứ tự đã xử lý trường hợp này
Bên nhận phải xác định số thứ tự của gói vừa gửi ACK
Yêu cầu bộ định thì đếm lùi
rdt 1.0
Tin cậy hoàn toàn
không có bit lỗi
không mất mát gói
Các FSMs riêng biệt
Bên gửi gửi dữ liệu vào kênh cơ bản
Bên nhận đọc dữ liệu từ kênh cơ bản
Giao thức Pipelined:Truyền nhiều gói tin cùng 1 lúc
pipelining: bên gửi cho phép gửi nhiều gói đồng thời, không cần chờ báo xác nhận ACK
Go-Back-N
Mất ACK: Không ảnh hưởng nếu đã nhận ACk lớn hơn
Mất gói: sẽ gửi lại từ gói tin bị mất
https://media.pearsoncmg.com/aw/ecs_kurose_compnetwork_7/cw/content/interactiveanimations/go-back-n-protocol/index.html
Selective Repeat
Mất ACK: gửi lại gói tin bị mất ACK đó
Mất gói: chỉ gửi lại gói bị mất
https://media.pearsoncmg.com/aw/ecs_kurose_compnetwork_7/cw/content/interactiveanimations/selective-repeat-protocol/index.html
TCP
point-to-point
one sender
one receiver
Tin cậy và theo thứ tự
pipelined
điều khiển luồng và tắc nghẽn của TCP thông qua việc thiết kế kích thước cửa sổ (window size)
Dữ liệu full duplex
Luồng dữ liệu đi 2 chiều trong cùng 1 kết nối
MSS: maximum segment size : kích thước tối đa của gói tin
Hướng kết nối
Bắt tay (handsharking) trao đổi control messages, khởi tạo bên gửi và nhận trước khi trao đổi dữ liệu
Điều khiển luồng
Bên gửi sẽ không làm tràn bộ đệm bên nhận
slide 58
Sequence number
Không tính theo packet mà tính theo byte steam
Dòng byte "đánh số" byte đầu tiên trong dữ liệu của segment
Acknowledgement number
Đếm bằng bytes data không bằng segment
Số thứ tự của byte kế tiếp được mong đợi từ phía bên kia , ACK tích lũy
TRUYỀN DỮ LIỆU TIN CẬY
TCP tạo dịch vụ rdt trên dịch vụ không tin cậy của IP
Các đoạn (segment) được truyền thông qua kiến trúc đường ống.
Các ack tích lũy
TCP dùng một bộ đếm thời gian truyền lại
Việc truyền lại được kích hoạt bởi:
Sự kiện timeout
Các ack bị trùng
Lúc đầu khảo sát TCP đơn giản ở bên gửi:
Bỏ qua các ack bị trùng
Bỏ qua điều khiển luồng và điều khiển tắc nghẽn
TCP các sự kiện bên gửi
Dữ liệu được nhận từ ứng dụng
Tạo segment với số thứ tự
Số thứ tự là số thứ tự của byte dữ liệu đầu tiên trong segment
Khởi động bộ đếm thời gian nếu chưa chạy
Xem bộ định thì như là đối với segment sớm nhất không được ACK
Khoảng thời gian hết hạn:
TimeOutInterval
Timeout
Gửi lại segment nào gây ra timeout
Khởi động lại bộ đếm thời gian
Nhận ack
Nếu xác nhận cho các segment không được xác nhận trước đó
Cập nhật những gì được biết là đã được nhận thành công
Khởi động lại bộ định thì nếu có các segment vẫn chưa được thông báo nhận thành công
Sự phát sinh TCP ACK
TCP truyền tải nhanh
Chu kỳ time-out thường tương đối dài: Độ trễ dài trước khi gởi lại gói bị mất
Phát hiện các segment bị mất thông qua các ACKs trùng.
Bên gửi thường gửi nhiều segment song song
Nếu segment bị mất, thì sẽ có khả năng có nhiều ACK trùng.
TCP điều khiển luồng
Bên nhận "thông báo" không gian bộ nhớ đệm còn trống bằng cách thêm giá trị
rwnd
trong TCP header của các segment từ bên nhận đến bên gửi
Kích thước của RcvBuffer được thiết đặt thông qua các tùy chọn của socket (thông thường mắc định là 4096 byte)
Nhiều hệ điều hành tự động điều chỉnh
RcvBuffer
Bên gửi giới hạn khối lượng dữ liệu gửi mà không cần ACK bằng giá trị rwnd của bên nhận
Bảo đảm bộ đệm bên nhận sẽ không bị tràn
Quản lý kết nối
Trước khi trao đổi dữ liệu, bên gửi và nhận "bắt tay nhau"
Đồng ý thiết lập kết nối (mỗi bên biết bên kia sẵn sàng để thiết lập kết nối)
Đồng ý các thông số kết nối
TCP đóng kết nối
Mỗi bên client và server sẽ đóng kết nối bên phía của nó: Gởi TCP segment với FIN bit = 1
Phản hồi bằng ACK cho FIN vừa được nhận: Khi nhận FIN, ACk có thể được kết hợp với FIN của nó.
Các trao đổi FIN đồng thời có thể được sử dụng.
Điều khiển tắc nghẽn
TCP slow start
Khi kết nối bắt đầu, tăng tốc độ theo cấp số nhân cho đến sự kiện mất gói đầu tiên xảy ra:
initially
cwnd
= 1 MSS
Gấp đôi
cwnd
cho mỗi RTT
Được thực hiện bằng cách tăng cwnd cho mỗi ACK nhận được
Tóm lại
: tốc độ ban đầu chậm, nhưng nó sẽ tăng lên theo cấp số nhân
Phát hiện, phản ứng khi mất gói
Mất gói được chỉ ra ở timeout:
cwnd
được thiết lập 1 MSS.
Sau đó kích thước cửa sổ sẽ tăng theo cấp số nhân (như trong slow start) đến ngưỡng, sau đó sẽ tăng tuyến tính.
Mất gói được xác định bởi 3 ACK trùng nhau:
TCP RENO
Các ACK trùng lặp chỉ ra mạng vẫn có khả năng truyền.
cwnd
bị cắt một nửa sau đó tăng theo tuyến tính.
TCP TAHOE luôn luôn thiết lặp
cwnd
bằng 1 (timeout hoặc 3 ACK trùng nhau)
TÓM TẮT
Slow start
cwnd(n) = cwnd(n-1) * 2
ssthresh (ngưỡng ngưng slow start)
Congestion Avoidance
cwnd(n) = cwnd (n-1) + 1
Mất gói tin
Timeout
Tính lại ssthresh = cwnd/2
cwnd = 1
3ACK trùng
Fast recovery
Tính lại ssthresh = cwnd/2
cwnd = cwnd/2 (+3)