CCNA's notes

Trình bày chi tiết các vấn đề được nêu trong đề bài và các vấn đề có liên quan:
Transport layer:
I. Nhiệm vụ, các dịch vụ trong lớp transport layer. (elements of transport protocol)
II. Thành phần của Transport protocol.
1. Giải phóng liên kết (communication release).
2. Điều khiển luồng và đệm (Flow control & buffering)
3. Ghép kênh (Multiplexing )
4. Phục hồi sự cố (Crash Recovery)
I. Nhiệm vụ của Transport layer:
Quá trình truyền dữ liệu giữa các người dùng đầu cuối, cung cấp dịch vụ truyền tin tin
cậy đối với các dịch vụ lớp trên. Tầng giao vận cũng kiểm soát độ tin cậy của liên kết đang sử
dụng bằng các phương thức điều khiển luồng , phân mảnh/ ghép mảnh và kiểm soát lỗi. Một số
giao thức đã có các trạng thái xác định và có hướng kết nối.
* Các mục đích chính của lớp Transport layer:
- Theo dõi các kết nối của từng ứng dụng từ nguồn đến đích.
Bất cứ host nào cũng đều sử dụng rất nhiều ứng dụng qua mạng. từng ứng dụng này có
thể tương tác với một hoặc nhiều ứng dụng ở các host khác. Lớp transport có nhiệm vụ duy trì
nhiều luồng kết nối giữa các ứng dụng này.
Cho rằng 1 máy tính kết nối đến mạng internet đồng thời nhận và gửi email và thông điệp
chat, duyệt web, thực hiện thoại IP. Từng ứng dụng này gửi và nhận dữ liệu qua mạng cùng thời
điểm. Tuy nhiên dữ liệu thoại không gửi qua các trình duyệt web, và chữ trong các trình duyệt
instant message không xuất hiện trong email.
- Phân mảnh dữ liệu, đánh số thứ tự từng mảnh.
Lớp giao vận chia nhỏ dữ liệu ra thành nhiều mẩu nhỏ được gọi là các segments. Quá
trình này bao gồm quá trình đóng gói các mẩu dữ liệu. Từng headers của phần dữ liệu từ lớp
application được gán tại lớp transport sẽ chỉ ra dữ liệu này thuộc loại ứng dụng nào.Việc phân
mảnh dữ liệu thành nhiều mảnh nhỏ trước khi truyền giúp cho host có thể truyền nhiều dữ liệu
của nhiều ứng dụng trong 1 thời điểm qua mạng WAN. Trong khi nếu không phân mảnh dữ liệu
và truyền thì chỉ chạy được 1 số lượng nhất định các ứng dụng được truyền đi.
- Ghép lại các mảnh thành luồng của dữ liệu cho ứng dụng tương ứng.
Do dữ liệu được phân mảnh và truyền qua rất nhiều tuyến đường nên thứ tự đến của các

mảnh dữ liệu tại đích là rất khác nhau. Bằng việc đánh số và số thứ tự các mảnh, lớp giao vận
đảm bảo cho các dữ liệu này sẽ được khôi phục lại theo đúng thứ tự tại đích.
Tại host nhận dữ liệu, các mảnh dữ liệu này được ghép lại theo đúng thứ tự rồi chuyển
lên lớp application.
Giao thức tại lớp transport diễn tả cách thức thông tin header ở lớp giao vận được dùng
để ghép lại các mảnh theo thứ tự trước khi đi lên xử lý ở lớp application.
- Phân biệt các ứng dụng khác nhau.
Để dữ liệu đến được đúng ứng dụng cần thiết , tầng giao vận phải có 1 cơ chế phân biệt
được các ứng dụng ở đích. Trong mô hình TCP/IP cơ chế này được gọi là port. Từng phần mềm
nếu muốn truy cập vào mạng internet đều được gán một số port duy nhất ở host. Số port này
được sử dụng trong header của lớp giao vận để chỉ ra ứng dụng của mẩu dữ liệu tương ứng.
Tại lớp giao vận, từng nhóm các mẩu dữ liệu đi từ ứng dụng nguồn đến ứng dụng đích
được gọi là “thoại” ( conversation giữa các ứng dụng nguồn và đích). Việc chia nhỏ dữ liệu ra
thành nhiều đơn vị truyền dẫn , cách thức truyền các phần này từ nguồn đến đích, muốn thực
hiện được cần nhiều quá trình ghép nối các dạng dữ liệu.
Tầng giao vận là liên kết giữa tầng ứng dụng và các tầng dưới chịu trách nhiệm cho việc
truyền dẫn trong mạng internet. Tầng giao vận cho phép dữ liệu từ các conversations khác nhau
xuống các lớp thấp hơn dưới dạng các bản tin có thể quản lý được. Các bản tin này sau cùng sẽ
được ghép nối để truyền dẫn qua nhiều thiết bị truyền thông trung giãn.

- Điều khiển luồng
Vì tài nguyên của đường truyền internet là rất có hạn nên 1 khi mà đường truyền trung
gian bị quá tải, một số giao thức có thể yêu cầu gửi các ứng dụng với tốc độ thấp hơn để đảm bảo
lưu lượng của các luồng dữ liệu. Điều này thực hiện được do lớp giao vận điều khiển 1 lượng lớn
các dữ liệu truyền từ nguồn dưới dạng nhóm. Điều khiển luồng có thể chống việc mất gói dữ liệu
trong mạng và tránh việc phải truyền lại.
- Hỗ trợ khôi phục lỗi.
Lớp giao vận cho phép truyền lại các mẩu tin bị lỗi trong lúc truyền phát bị mất. 1 ví dụ
điển hình là các ứng dụng sử dụng TCP ( WEB, mail …) .
- Khởi tạo pha.

Lớp giao vận tạo ra các kết nối có định hướng bằng cách khởi tạo pha giữa các ứng dụng.
Các kết nối này chuẩn bị cho các ứng dụng để sẵn sang kết nối với các ứng dụng khác trước khi
truyền dữ liệu. Trong những phiên này, dữ liệu cho kết nối giữa 2 ứng dụng được quản lý sát sao.
* Các dịch vụ trong lớp giao vận:
1. Lý thuyết: (xét theo mô hình tham chiếu OSI)
a. Dịch vụ cho các lớp trên:
Mục đích cuối cùng của lớp transport là cung cấp năng suất cao, độ tin cậy, hiệu quả về
cost của các gói tin trên đường đi cho người dùng. Để đạt được mục đích này, lớp giao vận được
sử dụng các dịch vụ mà lớp network mang lại. Các phần cứng và phần mềm của tầng giao vận
còn được gọi là các thực thể giao vận ( transport entity). Các thực thể lớp giao vận nằm ở hạt
nhân của hệ điều hành, trong 1 process riêng biệt của người dùng, nằm trong các gói thư viện
liên kết với các ứng dụng ở lớp network hoặc hình thành trong card mạng. Mối quan hệ về mặt
logic giữa các lớp application, transport , network được minh họa trong hình sau.
Có 2 loại network service, connection-oriented và connectionless. Tương ứng với nó
cũng có 2 loại transport service. Trong nhiều trường hợp, kết nối connection-oriented có 3 pha:
khởi tạo, truyền dữ liệu, giải phóng kết nối. Gán địa chỉ và điều khiển luồng là giống nhau trong
cả 2 lớp. Hơn nữa, dịch vụ lớp giao vận connectionless cũng tương tự như connectionless ở lớp
network.
Câu hỏi được đặt ra ở đây là : nếu tầng transport giống tầng network thì vì sao vẫn cần 2
tầng khác nhau? Tại sao không gộp lại thành 1 tầng? Câu trả lời là code của tầng transport chạy
chủ yếu vào máy tính của người dùng. Nhưng code ở lớp network thì chạy trên router là chính.
Chuyện gì sẽ xảy ra nếu lớp network cung cấp thiếu các dịch vụ? Điều đó có thể dẫn tới việc mất
gói thường xuyên? Chuyện gì xảy ra nếu router bị hỏng liên tục?
Người dùng không có cách nào để kiểm soát tầng network nên không thể xử lý được vấn
đề của việc thiếu thốn các dịch vụ cần thiết bằng cách sử dụng các routers chất lượng cao hơn
hoặc hỗ trợ thêm các biện pháp xử lý lỗi ở lớp data link. Khả năng duy nhất là đặt trên lớp
network 1 lớp khác có thể làm tăng cường chất lượng dịch vụ. Ví dụ như trong kết nối có định
hướng, thực thể lớp giao vận được thông báo giữa đường rằng kết nối đã bị gián đoạn. Vì không
có chỉ dẫn nào cho trạng thái của dữ liệu hiện tại, một kết nối mới rất có khả năng được khởi tạo
đến các thực thể lớp giao vận ở nơi khác trên mạng. Trên kết nối mới này, thực thể lớp giao vận

ở nơi khác gửi truy hồi hỏi peer dữ liệu nào đã đến, dữ liệu nào chưa, và có thể truyền lại những
phần dữ liệu chưa đến đích.
Về bản chất, sự tồn tại của lớp transport làm cho các dịch vụ ở tầng giao vận tạo độ tin
cậy cao hơn các dịch vụ ở các lớp dưới. Các gói bị mất hoặc bị phân mảnh có thể phát hiện được
và bù trừ bởi tầng giao vận. Hơn nữa, các dịch vụ nguyên thủy của lớp giao vận có thể thực thi
bằng cách gọi các thủ tục thư viện. Điều này khiến chúng độc lập với các dịch vụ nguyên thủy
của lớp network. Các dịch vụ rất đa dạng tùy vào kiểu kết nối mạng. Bằng việc ẩn những dịch vụ
lớp network dưới những thiết lập ở lớp transport , việc thay đổi 1 số dịch vụ mạng chỉ đơn giản
là thay đổi các thủ tục trong thư viện bằng dịch vụ tương đương nhưng khác underlying service.
Nhờ có lớp giao vận mà các lập trình viên có thể code theo nhữn thiết lập ban đầu nhất
định và những chương trình này hoạt động giống nhau trên nhiều thiết bị, không quan trọng việc
khác subnet interface hoặc truyền tin không tin cậy. Nói 1 cách khác, lớp giao vận đóng vai trò
cô lập các lớp trên với công nghệ, thiết kế, sự dở dang của subnet.
Vì lý do này người ta thường chia các tầng ra thành 2 nhóm: 4 lớp trên là transport
service user (dịch vụ của người dùng) còn 4 lớp dưới là transport service provider ( dịch vụ thuộc
về nhà cung cấp). Sự khác biệt giữa nhà cung cấp và người dùng là tác động quan trọng cần phải
tính toán đến trong khi thiết kế và đặt lớp giao vận trong vị trí chủ chốt cần quan tâm.
b. Các dịch vụ căn bản của tầng giao vận:
Để cho phép người dùng can thiệp vào các dịch vụ ở tầng giao vận, một số chương trình
được phát triển ví dụ như transport service interface được phát triển. Trong phần này chúng ta
tìm hiểu 1 dịch vụ lớp transport cơ bản đề nắm được các ứng dụng.
Các dịch vụ lớp transport gần giống như các dịch vụ lớp network nhưng vẫn có nhiều
điểm khác biệt quan trọng. Network service dùng để mô hình hóa các dịch vụ được cung cấp bởi
mạng thật. Trên thực tế việc truyền gói tin qua mạng luôn xảy ra hiện tượng mất gói, do đó nhìn
chung các network service thường hạn chế về độ tin cậy.
Các dịch vụ kết nối có định hướng (connection-oriented) có độ tin cậy cao là nhờ khả
năng hỗ trợ xử lý các tổn thất trên đường truyền (đương nhiên sẽ xảy ra) như acknowledgement,
congestion, lost packet… và che giấu chúng trong các ứng dụng của người dùng. Do đó người
dùng có thể xem như các dòng bit là không có lỗi.
Tầng giao vận cũng hỗ trợ các dịch vụ cho kết nối không tin cậy (connectionless service).

Sự khác biệt thứ 2 giữa transport service và network service là network service được sử
dụng bởi các thực thể của tầng giao vận. Dưới đây là 1 số các dịch vụ sơ khai của lớp transport.
Những dịch vụ này cho phép người dùng khởi tạo, giải phóng kết nối cho các ứng dụng
chạy trên các thiết bị cá nhân.
Dưới đây là một số ví dụ về các dịch vụ của lớp transport , ta xem xét 2 mô hình client
server với 2 kiểu kết nối TCP và UDP. Các dịch vụ của lớp transport được tóm gọn trong 1 khái
niệm rất tổng quát: SOCKET.
I. MÔ HÌNH TCP CLIENT-SERVER
Mô hình TCP Client-Server
1. Phía Server:
 Hàmsocket(): socket(int domain, int type, int protocol)
 Ý nghĩa: Gọi socket descriptor mà ta muốn sử dụng
 Tham số:
int domain: Kiểu socket nào đang cần được sử dụng. domain có thể lấy các giá trị
PF_INET cho IPv4 / PF_INET6 cho IPv6 hoặc AF_INET cho IPv4/ AF_INET6 cho IPv6.
AF_INET = address family chỉ ra tập hợp những giao thức có chung định dạng địa chỉ, trong khi
đó PF_INET là tập hợp những giao thức có cùng kiến trúc. Thông thường AF_INET và
PF_INET có thể thay thế nhau.
int type: cách thức truyền tin được sử dụng. tham số này có thể là SOCK_STREAM nếu
ta muốn sử dụng truyền tin TCP; SOCK_DGRAM nếu ta muốn sử dụng truyền tin UDP; bên
cạnh đó còn có SOCK_SEQPACKET để thiết lập truyền tin tin cậy với các bản tin UDP;
SOCK_RAW cho internal network interface.
int protocol: giao thức được sử dụng để truyền tin. Trường này có thể nhận 1 trong số các
giá trị sau:
IPPROTO_TCP nếu muốn sử dụng giao thức truyền tin TCP.
IPPROTO_UDP nếu muốn sử dụng giao thức truyền tin UCP.
IPPROTO_SCTP nếu muốn sử dụng giao thức truyền tin SCTP.
0 nếu muốn chương trình tự động chọn giao thức phù hợp với kiểu truyền tin tương ứng.
Ngoài ra có thể sử dụng hàm getprotobyname() để tìm giá trị gán phù hợp cho giao thức
trong trường này.

 Giá trị trả về:
Socket descriptor được dùng nếu thành công.
Trả về giá trị -1 nếu lỗi.
 Hàmbind(): bind(int sockfd,struct sockaddr * my_addr, socklen_t addrlen)
 Ý nghĩa: Gán IP và port cho socket.
 Tham số:
sockfd: socket descriptor trả về từ hàm socket() vừa gọi ở trên. Với từng IP và port , giao
thức ta có thể có những socket descriptor khác nhau và có thể bind vào các socket khác
nhau.
*my_addr: con trỏ trỏ đến struct địa chỉ tương ứng của socket. Struct địa chỉ của socket
gồm 3 trường cơ bản là address family, IP , port và phải được biểu diễn theo cấu trúc big endian
(network byte ordering).
addrlen: chiều dài của cấu trúc sockaddr tương ứng.
 Giá trị trả về:
Trả về giá trị 0 nếu thành công.
Trả về giá trị -1 nếu lỗi
 Hàm listen(): listen(int sockfd, int backlog);
 Ý nghĩa: thiết lập socket ở chế độ listen- lắng nghe các kết nối đến.
 Tham số:
sockfd: socket descriptor được gọi từ hàm socket() , cũng là file descriptor ta muốn lắng
nghe cho những client nào.
backlog: Số kết nối chưa được giải quyết tối đa có thể listen. Nếu số kết nối vượt quá
backlog , kernel sẽ từ chối các kết nối đó.
 Giá trị trả về:
Trả về giá trị 0 nếu thành công.
Trả về giá trị -1 nếu lỗi
 Hàm accept(): accept(int s,struct sockaddr *addr, socklen_t *addrlen)
 Ý nghĩa: Chấp nhận kết nối mới ở listening socket. Accept được gọi khi bên
client thực hiện hàm connect().
 Tham số:

s: socket descriptor listening được gọi ở hàm socket();
*addr: con trỏ trỏ đến cấu trúc địa chỉ của client đang muốn khởi tạo kết nối đến server.
addrlen: chiều dài cấu trúc địa chỉ của remote client đang muốn khởi tạo kết nối đến
server.
 Giá trị trả về:
Trả về connected socket descriptor mới nếu thành công.
Trả về giá trị -1 nếu bị lỗi.
 Hàm send(): send(int s,const void *buf,size_t len, int flags);
 Ý nghĩa: Thường được sử dụng cho TCP socket. Send sẽ gửi dữ liệu qua socket
đến địa chỉ đích đã tạo kết nối ở trên.
 Tham số:
s: file descriptor được trả về từ hàm accept() Client sẽ trao đổi thông tin với server qua
file descriptor này.
*buf: con trỏ trỏ đến vùng nhớ cần được gửi đến client. Server sẽ gửi đi nội dung của con
trỏ này đến client tương ứng.
len: Số các bytes được gửi đi ở vùng nhớ được chỉ ra bởi con trỏ *buf ở trên.
flags: chỉ ra thông tin về cách thức dữ liệu sẽ được gửi đi qua mạng. Trường flags =0 nếu
muốn gửi dữ liệu theo cách thông thường. Ngoài ra còn có một số kiểu dữ liệu khác như sau:
MSG_OOB Gửi out-of-band data – dữ liệu sử dụng để kiểm soát hệ thống, duy trì kết
nối giữa 2 bên. Dữ liệu loại này có quyền ưu tiên hơn những dữ liệu bình
thường. Receiver sẽ nhận ngay lập tức mà không bắt dữ liệu loại này nằm
trong hàng đợi.
MSG_DONTROUTE Không gửi dữ liệu loại này qua router, chỉ giữ nó trong mạng LAN (dữ liệu
mang tính cục bộ)
MSG_DONTWAIT Gửi dữ liệu bất chấp việc outbound traffic bị cản trở.
MSG_NOSIGNAL Ngăn không cho tín hiệu SIGPIPE (chỉ thị socket này đã bị block ở remote
side) xuất hiện, gửi dữ liệu đến client mặc dù client không còn thực hiện
hàm recv().
 Giá trị trả về:
Số bytes đã được gửi đi thật sự.

Trả về giá trị -1 nếu bị lỗi.
 Hàm recv(): recv(int s , void const *buf, size_t len,int flags)
 Ý nghĩa: Nhận dữ liệu qua socket.
 Tham số:
s: socket descriptor đang kết nối đến client tương ứng.
*buf: con trỏ chỉ vào vùng nhớ chứa dữ liệu nhận được từ client.
len: chiều dài vùng nhớ để nhận dữ liệu từ client.
flags: cờ điều khiển thông tin về dữ liệu nhận. Có thể có một trong số các giá trị sau:
MSG_OOB : dữ liệu out of band dùng để trao đổi thông tin duy trì kết nối giữa 2 điểm
đầu cuối.
MSG_PEEK: dự đoán trước thông tin sẽ nhận được tại recv().
MSG_WAITALL: hàm recv() sẽ không trả về giá trị cho đến khi nhận đủ dữ liệu như đã
khai báo trong biến chiều dài “len”.
 Giá trị trả về:
Số bytes thực sự nhận được nếu thành công. Số bytes có thể ít hơn số bytes yêu cầu trong
trường “len” đã khai báo.
(-1) nếu lỗi.
Trên thực tế hoàn toàn có thể sử dụng 2 hàm read() write() để đọc và ghi dữ liệu lên socket
tương ứng nhưng có thể thấy những hạn chế của 2 hàm read() write() là:
+Không chỉ ra được file descriptor đang sử dụng nếu như server đang kết nối đến nhiều
client.
+Không hỗ trợ các định dạng bản tin đặc biệt như là out-of-band data dùng để thiết lập và
thông báo các trạng thái của kết nối khi có thay đổi trong topology.
 Hàmclose(): close(int s);
 Ý nghĩa: đóng socket tương ứng sau khi đã sử dụng.
 Tham số: s là file descriptor đang kết nối đến client mà ta vừa trao đổi bản tin xong.
 Giá trị trả về:
Nếu remote side gọi hàm send() , remote side sẽ nhận được tín hiệu SIGPIPE và hàm
send ở remote side sẽ trả về giá trị (-1)= báo lỗi.
Nếu remote side gọi hàm recv(),close() sẽ trả về giá trị 0.

2. Phía Client:
Ngoài một số hàm bên phía server, thì bên client sẽ có thêm hàm connect()
Hàmconnect():
connect(int sockfd, const struct sockaddr *serv_addr, socklen_t addrlen);
Ý nghĩa: kết nốt client đến server thông qua socket vừa được khởi tạo.
Tham số:
sockfd: giá trị đại diện cho file descriptor được sử dụng để kết nối đến server.
*serv_addr: Con trỏ trỏ đến cấu trúc lưu trữ thông tin về server address. Những
thông tin cơ bản về cấu trúc địa chỉ socket gồm Address family, IP và port (thông thường
sử dụng IPv4).
addrlen: chiều dài của cấu trúc địa chỉ socket của server lưu trữ tại client.
Giá trị trả về:
Trả về file socket descriptor nếu thành công
Trả về giá trị -1 nếu có lỗi xảy ra
II. MÔ HÌNH UDP CLIENT-SERVER
 Hàm sendto(): sendto(int s, void *msg, int len, unsigned flags, struct sockaddr *to, int
tolen )
 Ý nghĩa: Thường được sử dụng cho UDP socket. sendto() sẽ gửi dữ liệu qua
socket đến địa chỉ đích đã tạo kết nối ở trên.
 Tham số:
s: file descriptor được trả về từ hàm accept() Client sẽ trao đổi thông tin với server qua
file descriptor này.
*msg: con trỏ trỏ đến vùng nhớ cần được gửi đến client. Server sẽ gửi đi nội dung của
con trỏ này đến client tương ứng.
len: Số các bytes được gửi đi ở vùng nhớ được chỉ ra bởi con trỏ *msg ở trên.
flags: chỉ ra thông tin về cách thức dữ liệu sẽ được gửi đi qua mạng. Trường flags =0 nếu
muốn gửi dữ liệu theo cách thông thường. Ngoài ra còn có một số kiểu dữ liệu khác như sau:
MSG_OOB Gửi out-of-band data – dữ liệu sử dụng để kiểm soát hệ thống, duy trì kết
nối giữa 2 bên. Dữ liệu loại này có quyền ưu tiên hơn những dữ liệu bình
thường. Receiver sẽ nhận ngay lập tức mà không bắt dữ liệu loại này nằm

trong hàng đợi.
MSG_DONTROUTE Không gửi dữ liệu loại này qua router, chỉ giữ nó trong mạng LAN (dữ liệu
mang tính cục bộ)
MSG_DONTWAIT Gửi dữ liệu bất chấp việc outbound traffic bị cản trở.
MSG_NOSIGNAL Ngăn không cho tín hiệu SIGPIPE (chỉ thị socket này đã bị block ở remote
side) xuất hiện, gửi dữ liệu đến client mặc dù client không còn thực hiện
hàm recv().
sockaddr *to: con trỏ trỏ tới cấu trúc thông tin địa chỉ bên nhận
*tolen: độ dài của biến cấu trúc to
 Giá trị trả về:
Số bytes đã được gửi đi thật sự.
Trả về giá trị -1 nếu bị lỗi
 Hàm recvfrom(): recvfrom(int s, void *buf, int len, unsigned flags, struct sockaddr
*from, int *fromlen)
 Ý nghĩa: Nhận dữ liệu qua socket.
 Tham số:
s: socket descriptor đang kết nối đến client tương ứng.
*buf: con trỏ chỉ vào vùng nhớ chứa dữ liệu nhận được từ client.
len: chiều dài vùng nhớ để nhận dữ liệu từ client.
flags: cờ điều khiển thông tin về dữ liệu nhận. Có thể có một trong số các giá trị sau:
MSG_OOB : dữ liệu out of band dùng để trao đổi thông tin duy trì kết nối giữa 2 điểm
đầu cuối.
MSG_PEEK: dự đoán trước thông tin sẽ nhận được tại recvfrom().
MSG_WAITALL: hàm recvfrom() sẽ không trả về giá trị cho đến khi nhận đủ dữ liệu như
đã khai báo trong biến chiều dài “len”.
sockaddr *from: con trỏ trỏ dến cấu trúc thông tin địa chỉ bên gửi
*fromlen: độ dài của biến cấu trúc from
 Giá trị trả về:
Số bytes thực sự gửi đi nếu thành công. Số bytes có thể ít hơn số bytes yêu cầu trong trường
“len” đã khai báo.

Trả về giá trị -1 nếu lỗi.
Nhận xét:
Ta thấy trong mô hình UDP client-server qua trình thiết lập kết nối và trao đổi dữ liệu có
khác so với ở mô hình TCP. Trong mô hình UDP đã bỏ đi các quá trình listen(), accept(),
connect(). Chính vì điều này đã làm cho giao thức UDP là một giao thức truyền thông không tin
cậy.

II. Các thành phần của lớp giao vận (elements of
transport protocols):
1. Khái niệm về TPDU – Transport Protocol Data Unit:
TPDU là bản tin trao đổi giữa các thực thể của lớp giao vận. Do đó TPDU được chứa
trong gói (packet)chứa thông tin dùng để trao đổi ở lớp network. Các gói này lại được đóng trong
các khung (frame) bởi lớp Data Link. Khi mà gói tin đến, các khung được lớp Data link phân
tích, gỡ bỏ khung và đẩy gói trong khung lên các thực thể ở lớp network. Lớp network lại xử lý
các header ở gói, gỡ bỏ header của network và đẩy lên các thực thể ở lớp transport.
Nhìn lại ví dụ ở mô hình client –ser ver trên ta thấy khi gọi hàm connect() sẽ tạo ra yêu
cầu kết nối TPDU được gửi đến server. Khi bản tin TPDU đến, các thực thể lớp transport kiểm
tra để thấy rằng server đang ở trạng thái block do hàm listen() được thực thi. Các thực thể ở lớp
giao vận này sau đó sẽ mở server và gửi bản tin TPDU chấp nhận kết nối lại client. Khi client
nhận được TPDU, client được khai thông và kết nối được khởi tạo.
Dữ liệu bây giờ có thể được trao đổi thông qua 2 hàm send() và receive(). Trong dạng mô
hình đơn giản nhất, các nhóm dịch vụ block do hàm receive() để đợi các nhóm khác thực hiện
hàm send(). Khi TPDU đến, phía nhận unblock, xử lý TPDU và phản hồi lại client. Chừng nào
mà 2 phía còn kiểm soát xem đến lượt bên nào gửi, quá trình này vẫn diễn ra ổn định.
Tại lớp transport, dữ liệu truyền theo 1 hướng thậm chí có thể phức tạp hơn nhiều so với
lớp network. Mọi gói tin được gửi đều phải có xác nhận (acknowledgement). Các gói tin mang
bản tin điều khiển TPDU cũng phải được xác nhận trực tiếp hoặc gián tiếp. Sự xác nhận này
được kiểm soát bởi các thực thể ở lớp giao vận, sử dụng các giao thức ở lớp network, và không
hiện hữu với người dùng. Các thực thể lớp giao vận cũng phải chú ý đến bộ đếm thời gian và quá
trình truyền lại. Dưới góc nhìn của người dùng, quá trình kết nối như thể là 1 ống ảo kết nối giữa

các thiết bị đầu cuối với các dòng bit di chuyển có độ tin cậy cao. Khả năng che giấu cơ chế phức
tạp này có thể coi là thế mạnh trong việc chia các giao thức ra thành các lớp.
Khi kết nối không cần nữa, nó phải được giải phóng để khôi phục không gian giữa 2 thực
thể ở lớp giao vận. Ngắt kết nối có 2 kiểu : đối xứng và bất đối xứng. Trong ngắt kết nối bất đối
xứng, người dùng ở tầng giao vận ở bên nào cũng có thể sử dụng phương thức disconnect().
DISCONNECT TPDU sẽ được gửi đến các thực thể của lớp giao vận ở đầu bên kia. Theo đó kết
nối sẽ được giải phóng.
Trong các loại ngắt kết nối đối xứng, từng chiều được đóng lần lượt và độc lập. Khi 1 bên
gọi hàm disconnect() điều đó có nghĩa là không còn dữ liệu được gửi đi nhưng vẫn có thể nhận
được dữ liệu từ partner. Kết nối chỉ thực sự được giải phóng khi mà cả 2 bên đều hoàn thành việc
gọi hàm disconnect().
Hình sau mô tả biểu đồ khối của việc khởi tạo kết nối và giải phóng kết nối. Quá trình
truyền được khởi tạo bởi việc thực thi các nguyên hàm (Primitive) hoặc có gói tin đến. Để đơn
giản ta giả sử các bản tin TPDU được xác nhận 1 cách riêng rẽ và quá trình ngắt kết nối là đối
xứng. Client sẽ gửi kết nối đến trước.

2. Gán địa chỉ (addressing):
Khi 1 quy trình của 1 ứng dụng muốn kết nối đến 1 quy trình của 1 ứng dụng khác, nó
phải chỉ được ra ứng dụng nào muốn kết nối đến. ( Với connectionless phải chỉ ra gói tin được
gửi từ đâu) Phương thức thông thường được sử dụng để đánh địa chỉ lớp giao vận là ports. Trong
mạng ATM, khái niệm TSAP ( Transport Service Access Point) Điểm đầu cuối tương tự ở lớp
network được gọi là NSAP (Network Service Access Point). Địa chỉ IP là 1 ví dụ của NSAP.
Hình dưới đây diễn tả mối quan hệ giữa NSAP, TSAP và sự liên kết ở lớp giao vận.
Trong các application process, cả 2 phía server và client có thể gán chúng vào TSAP để khởi tạo
kết nối đến TSAP từ xa. Những kết nối này chạy NSAP ở từng host. Mục đích của TSAP là trong
một số mạng, từng máy tính chỉ có 1 NSAP, do đó port là một cách dùng để phân biệt giữa các
quá trình truyền tin đến cùng 1 người dùng đầu cuối chỉ có 1 NSAP.
Một kịch bản có thể xảy ra cho kết nối ở tầng giao vận như sau:
1. Tại 1 thời điểm trong ngày, process server (tiến trình của server) của host 2 gán chính
nó vào TSAP 1522 để đợi các kết nối đến. Cách server gán TSAP tùy thuộc vào hệ điều hành của

thiết bị. Gọi hàm listen() là 1 trong số những cách để gán TSAP hay được dùng.
2. Application process ( tiến trình của ứng dụng) tại host 1 muốn biết về thời điểm nêu
trên, do đó nó thực hiện yêu cầu kết nối, đòi hỏi phải có TSAP 1208 là giá trị nguồn và TSAP
1522 là giá trị đích. Hành động này sau cùng là kết quả của quá trình kết nối ở lớp giao vận được
khởi tạo giữa 2 tiến trình ứng dụng của 2 host.
3. Tiến trình ứng dụng gửi ra yêu cầu về thời gian.
4. Tiến trình thời gian bên server sẽ phản hồi với thời gian hiện tại được yêu cầu.
5. Kết nối ở lớp giao vận được khởi tạo.
Lưu ý là có thể có các servers khác trên host 2 được gán với các TSAP khác và đợi các
kết nối tới qua cùng một NSAP.
Câu hỏi được đặt ra là làm thế nào tiến trình người dùng tại host 1 biết được là thời điểm
trong ngày của server (dữ liệu cần truyền) được gán vào TSAP 1522? Một khả năng có thể xảy ra
là thời gian trong ngày của server đã được gán chính nó với TSAP 1522 trong nhiều năm và tất
cả người dùng internet đều phải nắm được nó.Theo mô hình này, các dịch vụ mà có TSAP ổn
định đều được liệt kê trong danh sách các nơi thông dụng.Ví dụ như /etc/services file của hệ điều
hành nhân UNIX, liệt kê servers nào được gán cố định cho port nào.
Trong khi các địa chỉ TSAP hoạt động ổn định với những dịch vụ chủ yếu (như WEB
server), tiến trình người dùng, thông thường khởi tạo kết nối đến các tiến trình người dùng khác
trong một khoảng thời gian ngắn và không có các TSAP thông dụng. Hơn nữa, nếu có nhiều tiến
trình server có thể tham gia kết nối, khả năng một số rất hiếm khi được sử dụng là rất cao. Điều
này sẽ dẫn đến việc lãng phí tài nguyên để có từng tiến trình độc lập được kích hoạt và lắng nghe
các TSAP ổn định. Do đó cần 1 biện pháp để tối ưu hóa việc sử dụng địa chỉ.
Hình dưới mô tả 1 quá trình đơn giản với giao thức khởi tạo kết nối. Thay vì mọi server
lắng nghe các TSAP thông dụng, từng thiết bị đều muốn đưa ra 1 dịch vụ cho người dùng từ xa
có một server xử lý riêng, hoạt động như 1 proxy để giảm tải cho server. Server xử lý này sẽ lắng
nghe một số các port trong cùng 1 thời điểm, đợi các yêu cầu kết nối. Người dùng có nhu cầu
đến kết nối bắt đầu bằng việc gửi yêu cầu CONNECT, chỉ ra địa chỉ TSAP của dịch vụ muốn kết
nối đến. Nếu không có server nào đợi yêu cầu này, yêu cầu sẽ kết nối đến server xử lý theo hình
vẽ.
Sau khi nhận yêu cầu đến, process server sẽ sinh ra server được yêu cầu kết nối, cho phép

kế thừa các kết nối đang tồn tại với người dùng. Server mới sẽ xử lý công việc được yêu cầu,
trong khi process server quay lại việc tiếp tục lắng nghe kết nối mới như trong hình b.

3. Khởi tạo kết nối:
Để đảm bảo kết nối được khởi tạo đúng quy cách và tránh tối đa các lỗi, Tomlinson
(1975) giới thiệu “cơ chế bắt tay 3 bước” (three-way handshake). Kiểu khởi tạo kết nối này
không yêu cầu 2 phía bắt đầu gửi cùng số thứ tự của gói tin (sequence number), do đó nó có thể
được dùng với các phương thức đồng bộ nhiều hơn là sử dụng 1 đồng hồ đếm chung. Thủ tục
thông thường được thể hiện trong hình dưới đây trong trường hợp host 1 khởi tạo kết nối: Host 1
chọn số thứ tự x, gửi CONNECTION REQUEST TPDU bao gồm số thứ tự đó đến host 2. Host 2
phản hồi với bản tin ACK TPDU xác nhận x và gửi lại thứ tự khởi tạo y của nó. Sau cùng host 1
xác nhận thứ tự y của host 2 trong bản tin TPDU đầu tiên mà host 1 gửi.
Trong hình b, bản tin TPDU đầu tiên bị trễ đã sao chép CONNECTION REQUEST từ kết
nối cũ. TPDU này đến host 2 mà không cần host 1 biết. Host 2 phản hồi lại host 1 bằng việc gửi
trả lại bản tin ACK TPDU để xác nhận việc host 1 cần kết nối đến host 2 để tạo kết nối mới. Khi
host 1 từ chối yêu cầu của host 2 để tạo kết nối mới, host 2 biết là đã nhận được bản tin bị delay
từ trước và hủy kết nối.
Trong trường hợp xấu hơn khi mà cả 2 CONNECTION REQUEST và ACK đều bị delay.
Trường hợp này được thể hiện trong hình c. Như ví dụ 2 host 2 nhận được CONNECTION
REQUEST bị delay và trả lời lại bản tin đó. Tại thời điểm này host 2 gửi yêu cầu sang host 1 sử
dụng sequence khởi tạo y và ACK x. Ngay sau đó khi mà TPDU bị trễ thứ 2 đến host 2 thì bản
tin ACK 1 của trễ CONECTION REQUEST đầu tiên đã bị từ chối. Do đó việc có nhiều TPDUs
đến cũng không ảnh hưởng mấy đến kiến trúc của mạng.
3. Giải phóng kết nối. (connection release)
Giải phóng kết nối đơn giản hơn việc thiết lập kết nối. tuy nhiên vẫn có những khó khăn
không lường trước được trong việc giải phóng kết nối. Như đã nói ở phần trên, ta có 2 cách để
giải phóng các kết nối: đối xứng và bất đối xứng. Giải phóng kết nối kiểu bất đối xứng là cách
mà hệ thống điện thoại hoạt động: khi 1 bên bị treo thì kết nối bị ngắt. Giải phóng kết nối kiểu
đối xứng giống như ngắt 2 kết nối 1 chiều và từng kết nối 1 chiều phải được ngắt riêng lẻ.
Ngắt kết nối bất đối xứng một cách đột ngột có thể gây ra mất dữ liệu. Xem xét kịch bản

dưới đây: Sau khi kết nối được khởi tạo, host 1 gửi TPDU sang host 2. Host 1 gửi tiếp 1 TPDU
khác. Không may host 2 thực hiện hàm DISCONNECT trước thời điểm mà TPDU đến. Kết quả
là kết nối được giải phóng và dữ liệu bị mất.
Do đó cần có 1 cơ chế tinh vi hơn để ngắt các kết nối.Ngắt kết nối có đối xứng được sử
dụng.Với kiểu này, 1 host vẫn có thể nhận dữ liệu sau khi đã gửi DISCONNECT TPDU.
Phương thức giải phóng kết nối đối xứng hoạt động trên nguyên tắc khi từng quá trình
biết rõ lượng dữ liệu cần gửi và thời điểm gửi.Tuy nhiên phương pháp này lại không phải lúc nào
cũng hoạt động hiệu quả.Vẫn có những lỗi khá phổ biến làm cho kiểu ngắt kết nối này không
phù hợp. vì lý do này, để kết thúc người ta đã phát triển cơ chế “bắt tay 4 bước” ( four way
handshake ) cho việc giải phóng kết nối.
Trong hình a ta thấy đây là trường hợp bình thường khi host 1 gửi bản tin DR
( DISCONNECTION REQUEST) TPDU để bắt đầu quá trình giải phóng kết nối. Khi đến nơi,
thiết bị thu gửi lại DR TPDU, bắt đầu timer để đề phòng trong trường hợp DR bị thất lạc trên
đường truyền không tới được đích. Khi DR từ host 2 về host 1, host 1 sẽ gửi lại bản tin ACK
TPDU đến host 2 và giải phóng kết nối. sau cùng khi ACK từ host 1 đến được host 2 thì bên
nhận cũng giải phóng kết nối. Quá trình giải phóng kết nối là quá trình các thực thể ở lớp giao
vận gỡ bỏ thông tin về kết nối trong bảng các kết nối hiện tại, đồng thời báo hiệu cho người
dùng. Quá trình này khác với việc transport user sử dụng hàm DISCONNECT.
Nếu ACK TPDU cuối cùng bị mất như trường hợp b, các trạng thái sẽ được giữ nguyên
đến khi quá thời gian quy định của timer, kết nối sẽ bị ngắt.
Xét trường hợp mà bản tin DR thứ 2 bị mất. Người dùng muốn ngắt kết nối sẽ không
nhận được phản hồi như ý muốn. Khi đó host 1 phải bắt đầu lại quá trình 4 way handshake, tức
là gửi lại bản tin DR TPDU như lúc đầu và quá trình diễn ra như trong hình a.
Tình huống cuối cùng giống như hình c. Sự khác biệt ở chỗ tất cả các nỗ lực truyền DR
đều thất bại do việc mất gói TPDU. Sau n lần thử lại, phía người gửi sẽ không gửi thêm 1 bản tin
DR nào nữa và giải phóng kết nối. Trong khi đó phía nhận sẽ rơi vào trạng thái time out và cũng
giải phóng kết nối.
Như vậy về mặt lý thuyết giao thức này gần như đã đáp ứng đủ các yêu cầu trong việc
giải phóng đường truyền. Vể mặt lý thuyết còn trường hợp quá trình giải phóng kết nối thất bại
do mất tất cả các bản tin TPDU trong n lần thử. Như vậy phía còn lại sẽ không biết là kết nối đã

bị hủy bỏ. Trường hợp này người ta gọi là kết nối nửa mở “ half-open connection”. Biện pháp
đơn giản hơn cả để khắc phục tình huống này là ta cần thiết lập 1 giao thức mà tại đó nếu thiết bị
không nhận được bản tin TPDU trong 1 khoảng thời gian nhất định, kết nối sẽ tự động bị loại bỏ.
Do đó nếu 1 bên đã disconnect thì bên còn lại cũng sẽ tự động hủy bỏ kết nối và disconnect. Nếu
biện pháp này được áp dụng, mỗi thực thể ở lớp giao vận phải có bộ đếm để dừng và phát lại khi
mà TPDU được gửi đến. Khi đã đến thời gian quy định mà vẫn chưa nhận được TPDU thì kết
nối tự động hủy bỏ.
( 3 way handshake, 4 way handshake theo kiểu ccna???)
4. Điều khiển luồng và đệm ( flow control & buffering):
Trước hết hãy xem xét kết nối được tạo ra trong khi đang được sử dụng như thế nào? Một
trong số những vấn đề quan trọng đó là điều khiển luồng. Cũng giống như phương pháp điều
khiển luồng ở tầng data link, sliding window và một số cơ chế tương tự được sử dụng. Tuy nhiên
điểm khác biệt lớn nhất khiến cho việc áp dụng các cơ chế điều khiển luồng ở data link layer vào
transport layer đó là router chỉ có số lượng kết nối ít, còn người dùng thì có rất nhiều loại kết nối.
Trong giao thức ở data link, các khung được đệm ở cả 2 phía gửi và nhận. Phía gửi phải
đệm khung ra trước khi nó được gửi hoặc truyền lại. Nếu mạng hỗ trợ datagram service, các thực
thể ở lớp giao vận của phía gửi cũng phải được gửi. Nếu phía nhận biết được phía gửi đệm tất cả
các TPDU cho đến khi nó được xác nhận, thiết bị nhận sẽ không dành các bộ đệm cho một số
loại kết nối. Phía thiết bị nhận duy trì 1 lượng bộ đệm xác định cho các kết nối của chúng. Khi
bản tin TPDU đến, bộ đệm sẽ được cấp phát động cho bản tin đó. Nếu có bộ đệm cấp phát được,
TPDU sẽ được chấp nhận. Nếu không sẽ bị hủy bỏ. Trong trường hợp bên gửi đang chuẩn bị cho
quá trình phát lại bản tin TPDU do lỗi mạng, không có thiệt hại nào đáng kể sẽ xảy ra do phía
nhận hủy bỏ bản tin TPDU. Phía gửi chỉ cần chờ bản tin ACK.
Nhìn chung, nếu các dịch vụ mạng là không tin cậy, phía gửi phải đệm các bản tin TPDU
trước khi gửi. Tuy nhiên với các dịch vụ mạng có độ tin cậy cao, việc làm cho tương thích giữa
bên phát và bên thu là có thể. Nói 1 cách khác, nếu sender luôn biết là receiver luôn có bộ đệm,
sender sẽ không cần phải copy các bản tin TPDU mà nó đã gửi nữa. Tuy nhiên nếu receiver
không chắc có thể chấp nhận bản tin TPDU, sender bắt buộc phải đệm nó. Trong các trường hợp
sau sẽ đề cập rõ hơn về việc sender không tin tưởng các bản tin ACK TPDU do hcunsg chỉ có y
nghĩa trong việc xác nhận bản tin TPDU đã đến chứ không phải bản tin TPDU được xác nhận.

Trong trường hợp mà receiver chấp nhận việc đệm dữ liệu trước khi xử lý, câu hỏi mới
được đặt ra là kích thước bộ đệm như thế nào là phù hợp? Nếu tất cả các bản tin TPDU gần như
là cùng kích thước, ta có thể xếp 1 nhóm các bộ đệm với kích cỡ xác định, 1 TPDU cho 1 bộ
đệm. Tuy nhiên nếu kích thước của TPDU thay đổi, từ vài đến vài nghìn kí tự, chắc chắn sẽ có
lỗi trong quá trình truyền nhận bản tin. Nếu phân bố các bộ đệm cho từng TPDU theo TPDU to
nhất thì nhiều tài nguyên sẽ bị lãng phí khi những bản tin TPDU có kích thước bé đến. Nếu kích
thước của bộ đệm quá bé so với các bản tin TPDU, nhiều bộ đệm có thể được sử dụng cho TPDU
dài dẫn đến quá trình quản lý các bản tin TPDU qua các bộ đệm rất phức tạp.
Sử dụng bộ đệm có kích thước thay đổi là một phương án khác cho vấn đề bộ đệm. Lợi
ích cụ thể ở đây là tài nguyên bộ nhớ sẽ được sử dụng rất hiệu quả. Cái giá phải trả cho việc
thuận lợi trong kiểm soát tài nguyên bộ đệm là thuật toán tính toán khá phức tạp. Một khả năng
nữa có thể xảy ra là sử dụng bộ đệm vòng. Phương pháp này cũng tận dụng bộ nhớ của máy tính
tốt, đảm bảo tất cả các kết nối truyền nhiều dữ liệu, và không phù hợp cho các kết nối truyền ít
dữ liệu.
Kiểu đệm giữa nguồn và đích tùy vào loại kết nối được sử dụng trên đường truyền. Cho
loại đường truyền bandwidth thấp , tính phụt thấp, ví dụ như đường truyền được tạo ra bởi việc
thực thi các dòng lệnh, sẽ tốt hơn nếu không sử dụng đệm mà thu chúng tự động tại phía thu. Khi
mà sender không rõ rằng receiver có thể đệm được không, sender phải lưu lại bản copy cua
TPDU cho đến khi nhận được xác nhận từ phía receiver. Ngoài ra, đối với đường truyền truyền
file hoặc các dịch vụ cần bandwidth cao, Khả năng đệm toàn bộ khung cửa sổ trước khi gửi là tốt
nhất cho sender. Việc này cho phép dữ liệu truyền đi với tốc độ cao nhất. Nhìn chung với các
luồng dữ liệu băng thông chậm và chập chờn, cách tốt nhất là đệm tại sender; còn với các luồng
dữ liệu bandwidth cao, tốt nhất là đệm tại receiver.
Do các kết nối mở và đóng và loại lưu lượng thay đổi, senders và receivers cần phải có cơ
chế cấp phát bộ đệm 1 cách linh hoạt. Theo đó, các giao thức ở lớp transport cho phép gửi đến
các host yêu cầu cấp phát bộ đệm tại receiver. Bộ đệm có thể được phân bố tại từng kết nối một
cách chọn lọc cho tất cả các kết nối giữa 2 host. Thay vào đó, receiver ( còn gọi là nơi chứa bộ
đệm) có thể nói với sender rằng đã có x bộ đệm sẵn sàng để truyền dữ liệu. Nếu số kết nối tăng
lên, việc thay đổi chính sách phân bố bộ đệm là cần thiết để đảm bảo cho hệ thống hoạt động ổn
định.

Một cách thông dụng để quản lý việc cấp phát động các bộ đệm là tách rời việc đệm khỏi
việc xác nhận, đối lập với sliding window. Quản lý bộ đệm động, nói một cách khác là cửa sổ có
kích thước thay đổi được. Ban đầu sender yêu cầu 1 số các bộ đệm nhất định tùy theo nhu cầu
cần thiết. Receiver sau đó sẽ chấp nhận yêu cầu của sender với số lượng tối đa nó có thể. Mỗi khi
sender gửi TPDU, sender sẽ giảm số lượng bộ đệm phân bố cho dữ liệu xuống 1, dừng cùng lúc
khi số bộ đệm phân bố =0. Receiver sau đó sẽ gửi các bản tin ACK và sự phân bố bộ đệm theo
lưu lượng ngược lại.
Hình dưới đây mô tả việc quản lý cửa sổ động hoạt động như thế nào.
Cho rằng thông tin về phân bố bộ đệm di chuyển trên nhiều bản tin TPDU khác nhau và
nó không bị đẩy về theo luồng ngược lại.
1- Lúc đầu, A muốn 8 bộ đệm nhưng chỉ được chấp nhận 4 bộ đệm so với 8 bộ đệm yêu cầu.
3 4 5- A gửi 3 bản tin TPDU trong đó có một bản tin bị mất.
6 -Bản tin TPDU thứ 6 xác nhận lại tất cả các TPDU trước ( truyền từ B) bao gồm số thứ tự của
ACK =1. Sau khi nhận được bản tin ACK từ B, A giải phóng bộ đệm chứa m0 m1 m2… và
thông báo với A rằng A được quyền gửi thêm 3 TPDU nữa bắt đầu trên 1 ( VD TPDU 2 3 4)
7 8- A đã gửi 2 ( không biết mất trên đường truyền) nên A tiếp tục gửi 3 ,4.
- Chờ cấp phát bộ đệm cho 3,4. A đã hết bộ đệm được cấp phát-> phải chờ.
9 - Timeout => truyền lại m2
10 - B xác nhận lại tất cả các bản tin TPDU , ACK =4. Từ chối A tiếp tục
Vẫn có những lỗi với việc cấp phát bộ đệm có khả năng phát sinh trong quá trình truyền
tin không tin cậy nếu mất kiểm soát TPDU. Xem xét bước thứ 16, B cấp phát nhiều bộ đệm hơn
A nhưng bản tin TPDU không được cấp phát bộ đệm. Khi mà việc kiểm soát TPDU không theo
thứ tự hoặc bị time out, A sẽ bị khóa kết nối. Để tránh hiện tượng này, từng host nên gửi các bản
tin TPDU điều khiển bao gồm sự phản hồi và trạng thái đệm trên từng kết nối.
Sự hạn chế của mức dữ liệu được gửi phụ thuộc vào không gian bộ đệm có thể cấp phát
được tại receiver. Ngoài ra nếu không gian bộ đệm không hạn chế tốc độ luồng tối đa thì vẫn có
những nguyên nhân khác ảnh hưởng đến như băng thông của đường truyền. Nếu các router lân
cận có khả năng truyền x gói / giây và có k đường bị fail giữa các host thì các host đó không thể
trao đổi nhiều hơn kx bản tin TPDU / giây, bất chấp việc không gian bộ đệm dành cho các gói
này tại receiver như thế nào đi nữa. Nếu sender cố đẩy các gói tin này đi thì mạng sẽ bị tắc nghẽn

do vượt quá khả năng.
Cái chúng ta cần ở đây là cơ chế dựa trên khả năng tải của đường truyền chứ không hẳn
là cơ chế điều khiển dựa trên không gian của bộ đệm. Rõ ràng là cơ chế điều khiển luồng phải
được chấp nhận tại sender để ngăn chặn hiện tượng có quá nhiều bản tin TPDU không được xác
nhận đến tại 1 thời điểm. Belsnes ( 1975) đề xuất phương pháp sử dụng cơ chế cửa sổ trượt mà
sender có thể điều khiển động sao cho phù hợp với khả năng của đường truyền. Nếu đường
truyền có khả năng xử lý được c bản tin TPDU/ giây và chu kỳ ( bao gồm thời gian truyền , trễ
lan truyền, thời gian nằm trong hàng đợi, khả năng xử lý tại receiver , và trả về bản tin ACK) là
r; thì cửa sổ trượt tại sender là cr. Với cửa sổ như thế này thì đường truyền luôn hoạt động như
cái ống đầy. Bất cứ sự suy giảm nào trong hoạt động của hệ thống mạng đều làm hỏng đường
truyền.