BÀI TẬP TRÊN LỚP

MÔN HỌC: HỆ PHÂN TÁN

CHƯƠNG 2: TIẾN TRÌNH VÀ TRAO ĐỔI THÔNG TIN TRONG HPT
HỌ TÊN SV: Đỗ Minh Hiếu MSSV: 20194558
MÃ LỚP: 139288 MÃ HỌC PHẦN: IT4612

Câu hỏi 1: Có cần thiết phải giới hạn số lượng các luồng trong một tiến trình server?
Trả lời: Có, việc giới hạn số lượng các luồng trong một tiến trình server là cần thiết để tránh quá
tải hệ thống. Nếu không có giới hạn, nhiều yêu cầu từ client có thể đồng thời được gửi đến server,
và server cố gắng xử lý tất cả các yêu cầu này đồng thời sẽ làm cho hệ thống quá tải và dẫn đến
các vấn đề về hiệu suất. Thêm vào đó, nếu quá nhiều luồng được khởi tạo, nó có thể dẫn đến sự
cạnh tranh tài nguyên giữa các luồng, gây ra sự cố hoặc khó khăn trong quản lý và theo dõi các
luồng.

Vì vậy, giới hạn số lượng các luồng trong một tiến trình server là cần thiết để đảm bảo hiệu suất
tối ưu và sự ổn định của hệ thống. Tuy nhiên, việc đưa ra số lượng luồng cụ thể phụ thuộc vào
nhiều yếu tố như khả năng xử lý của máy chủ, loại ứng dụng, tải của hệ thống và các yêu cầu kết
nối cụ thể.
Câu hỏi 2: Có nên chỉ gắn một luồng đơn duy nhất với một tiến trình nhẹ?
Trả lời: Có thể gắn một hoặc nhiều luồng với một tiến trình nhẹ tùy thuộc vào yêu cầu của ứng
dụng. Nếu ứng dụng chỉ thực hiện một tác vụ đơn giản và không yêu cầu tính đồng bộ giữa các
tác vụ thì chỉ cần sử dụng một luồng. Tuy nhiên, nếu ứng dụng phải thực hiện nhiều tác vụ cùng
một lúc hoặc yêu cầu tính đồng bộ giữa các tác vụ thì cần sử dụng nhiều luồng để đảm bảo hiệu
suất và tính đáp ứng của hệ thống.
Câu hỏi 3: Có nên chỉ có một tiến trình nhẹ đơn gắn với 1 tiến trình?
Trả lời: Không nhất thiết phải chỉ có một tiến trình nhẹ đơn gắn với một tiến trình. Trong một hệ
thống lớn, thường có hàng trăm hoặc thậm chí hàng ngàn tiến trình và có thể cần nhiều tiến trình
nhẹ để xử lý các tác vụ đồng thời trong mỗi tiến trình. Tuy nhiên, việc thiết kế một số lượng lớn
các tiến trình nhẹ cũng có thể dẫn đến vấn đề hiệu suất, bởi vì mỗi tiến trình đều cần phải được lên
lịch độc lập và được quản lý bởi hệ điều hành. Do đó, việc thiết kế số lượng các tiến trình nhẹ phù
hợp cần phải cân nhắc kỹ lưỡng để đảm bảo hiệu suất và độ ổn định của hệ thống.
Câu hỏi 4: Bài toán này yêu cầu bạn so sánh thời gian đọc một tệp (file) của một máy chủ tập tin
(file server) đơn luồng và một máy chủ đa luồng. Phải mất tổng cộng 15 ms để nhận 1 yêu cầu
(request) và thực hiện quá trình xử lý, giả định rằng các dữ liệu cần thiết nằm ở bộ nhớ đệm trong
bộ nhớ chính. Nếu cần thiết phải thực hiện một thao tác truy cập ổ đĩa thì cần thêm 75 ms, biết
rằng việc phải thực hiện thao tác này có xắc suất là 1/3. Hỏi máy chủ có thể nhận bao nhiêu yêu
cầu/giây trong 2 trường hợp: máy chủ là đơn luồng và máy chủ là đa luồng (ngoài luồng nhận và
xử lý request, sẽ có thêm 1 luồng để truy cập ổ đĩa nếu cần thiết)? Giải thích.
Trả lời:
Để tính toán được số yêu cầu/giây mà máy chủ có thể nhận, ta cần tính thời gian xử lý của từng
yêu cầu.
 • Với máy chủ đơn luồng: thời gian xử lý của mỗi yêu cầu bằng 15 ms (không có thao tác
truy cập ổ đĩa) hoặc 90 ms (khi có thao tác truy cập ổ đĩa với xác suất là 1/3). Vậy, số yêu
cầu/giây tối đa mà máy chủ đơn luồng có thể nhận được là:
• Khi không có thao tác truy cập ổ đĩa: 1000ms/15ms = 66.67 yêu cầu/giây.
• Khi có thao tác truy cập ổ đĩa: (1000ms/90ms) * (2/3) = 24 yêu cầu/giây.
• Với máy chủ đa luồng: thời gian xử lý của mỗi yêu cầu bằng 15 ms (không có thao tác
truy cập ổ đĩa) hoặc 90 ms (khi có thao tác truy cập ổ đĩa với xác suất là 1/3) + 15 ms
(thời gian cho luồng truy cập ổ đĩa). Vậy, số yêu cầu/giây tối đa mà máy chủ đa luồng có
thể nhận được là:
• Khi không có thao tác truy cập ổ đĩa: 1000ms/15ms = 66.67 yêu cầu/giây.
• Khi có thao tác truy cập ổ đĩa: (1000ms/120ms) * (2/3) = 16.67 yêu cầu/giây.
Như vậy, trong trường hợp này, máy chủ đơn luồng có thể nhận được số yêu cầu/giây lớn hơn so
với máy chủ đa luồng khi có thao tác truy cập ổ đĩa. Tuy nhiên, với máy chủ đa luồng, một luồng
sẽ chịu trách nhiệm cho việc truy cập ổ đĩa, giúp giảm thiểu tác động đến luồng nhận và xử lý
request, đảm bảo tính ổn định và tránh tình trạng bị treo hoặc chậm hơn do tác động của thao tác
truy cập ổ đĩa.

Câu hỏi 5: Hệ thống X chỉ định máy của user chưa server, trong khi các ứng dụng lại được coi như
client. Điều đó có vô lý không? Giải thích.
Trả lời:
Không có gì vô lý khi hệ thống X chỉ định máy của user chứa server trong khi các ứng dụng lại
được coi như client. Trong kiến trúc mạng phân tán, một máy tính có thể đồng thời hoạt động
như một server và một client, tùy thuộc vào vai trò của nó trong mỗi kết nối. Một máy tính có thể
chạy nhiều ứng dụng khác nhau, mỗi ứng dụng lại có thể đóng vai trò là client hoặc server tùy
thuộc vào tác vụ nó đang thực hiện và loại dịch vụ nó cần truy cập. Do đó, việc máy của user
chứa server trong khi các ứng dụng lại được coi như client là hoàn toàn bình thường và phù hợp
với kiến trúc mạng phân tán.
Câu hỏi 6: Giao thức thiết kế cho hệ thống X gặp phải vấn đề về tính mở rộng. Chỉ ra các giải pháp
để giải quyết vấn đề đó?
Trả lời:
Vấn đề về tính mở rộng trong giao thức thiết kế cho hệ thống X có thể là do hạn chế về khả năng
mở rộng của giao thức, hạn chế về khả năng mở rộng của thiết kế phần mềm hoặc do sự cố hệ
thống.
Các giải pháp để giải quyết vấn đề đó bao gồm:
1. Tăng tính mở rộng của giao thức: Thiết kế giao thức sao cho nó có khả năng mở rộng tốt
hơn. Điều này có thể đòi hỏi sự thay đổi của giao thức hiện tại hoặc xây dựng một giao
thức mới với tính mở rộng tốt hơn.
2. Tăng tính mở rộng của thiết kế phần mềm: Thiết kế phần mềm của hệ thống cần được tối
ưu hóa để đảm bảo tính mở rộng tốt hơn. Điều này có thể bao gồm phân tán hóa ứng
dụng, tách các chức năng thành các dịch vụ độc lập hoặc triển khai các phương pháp mở
rộng khác.
 3. Xử lý các sự cố hệ thống: Đôi khi, vấn đề về tính mở rộng của hệ thống X có thể là do
các sự cố hệ thống khác như tắc nghẽn mạng hoặc giới hạn tài nguyên. Giải quyết các sự
cố hệ thống sẽ giúp cải thiện tính mở rộng của hệ thống X.
4. Sử dụng các công nghệ mới: Các công nghệ mới như Cloud Computing, Docker hoặc
Kubernetes cung cấp các giải pháp mở rộng tốt hơn cho các hệ thống phân tán, cho phép
triển khai và quản lý ứng dụng dễ dàng hơn. Sử dụng các công nghệ này có thể giúp cải
thiện tính mở rộng của hệ thống X.

Câu hỏi 7: Với việc xây dựng một server đồng thời, hãy so sánh việc server này tạo một luồng mới
và tạo một tiến trình mới khi nhận được yêu cầu từ phía client.
Trả lời:
Khi xây dựng một server đồng thời, sử dụng luồng hoặc tiến trình đều có thể thực hiện được.
Tuy nhiên, sự lựa chọn giữa việc tạo một luồng mới và tạo một tiến trình mới sẽ ảnh hưởng đến
hiệu năng của hệ thống. Dưới đây là một số điểm khác nhau giữa việc tạo luồng và tạo tiến trình:
1. Tài nguyên hệ thống: Việc tạo một tiến trình mới yêu cầu tài nguyên hệ thống lớn hơn so
với việc tạo một luồng mới. Mỗi tiến trình đều có một bộ nhớ độc lập, trong khi các
luồng trong cùng một tiến trình chia sẻ cùng một bộ nhớ.
2. Hiệu năng: Việc tạo một luồng mới có thể nhanh hơn so với việc tạo một tiến trình mới
do việc tạo luồng không yêu cầu thêm bộ nhớ hoặc phân vùng mới như việc tạo tiến
trình.
3. Đồng bộ: Trong một tiến trình, các luồng chia sẻ cùng một bộ nhớ và có thể dễ dàng
truyền tải dữ liệu giữa các luồng. Tuy nhiên, trong các tiến trình khác nhau, cần sử dụng
các cơ chế đồng bộ hóa để truyền tải dữ liệu giữa chúng.
Do đó, trong trường hợp xây dựng một server đồng thời, việc sử dụng luồng có thể là một giải
pháp tốt hơn để tối ưu hóa hiệu năng và sử dụng tài nguyên hệ thống. Tuy nhiên, trong một số
trường hợp cần sử dụng nhiều tiến trình để đảm bảo tính độc lập và an toàn của hệ thống.

Câu hỏi 8: Nếu bây giờ một webserver tổ chức lưu lại thông tin về địa chỉ IP của client và trang
web client đó vừa truy cập. Khi có 1 client kết nối với server đó, server sẽ tra xem trong bảng
thông tin, nếu tìm thấy thì sẽ gửi nội dung trang web đó cho client. Server này là có trạng thái
(stateful) hay không trạng thái (stateless)?
Trả lời:
Server này là có trạng thái (stateful), vì nó phải lưu trữ thông tin của client (địa chỉ IP và trang
web truy cập) để có thể sử dụng cho các yêu cầu tiếp theo từ client.
Câu hỏi 9: So sánh Docker và Virtual Machine.
Trả lời:
Docker và Virtual Machine (VM) đều là các công nghệ ảo hóa cho phép chạy nhiều hệ điều hành
và ứng dụng trên cùng một máy chủ vật lý. Tuy nhiên, cả hai công nghệ có những điểm khác
nhau sau:
1. Khác về mức độ ảo hóa: Docker chạy trực tiếp trên hệ điều hành của máy chủ vật lý,
trong khi đó VM tạo ra một môi trường ảo để chạy hệ điều hành và ứng dụng.
2. Khác về tài nguyên: Khi sử dụng Docker, các container sẽ sử dụng cùng một hạt nhân
(kernel) của hệ điều hành của máy chủ, giúp giảm sử dụng tài nguyên hệ thống so với
 VM, mỗi VM sẽ sử dụng tài nguyên riêng biệt (bao gồm bộ nhớ, bộ vi xử lý, thiết bị đầu
cuối, v.v.)
3. Khác về thời gian khởi động: Docker khởi động nhanh hơn so với VM, do Docker sử
dụng chung kernel của máy chủ vật lý. Trong khi đó, việc khởi động một VM có thể mất
vài phút để tạo và khởi động hệ điều hành.
4. Khác về quản lý: Với Docker, quản lý container có thể được thực hiện thông qua các lệnh
docker command line, trong khi đó quản lý VM yêu cầu sử dụng phần mềm quản lý ảo
hóa như VirtualBox hoặc VMware.
5. Khác về ứng dụng: Docker phù hợp với các ứng dụng microservice, trong khi đó VM
thường được sử dụng để cung cấp môi trường ảo cho các ứng dụng truyền thống.
Tóm lại, Docker và VM đều là các công nghệ ảo hóa, tuy nhiên, chúng có những điểm khác nhau
về mức độ ảo hóa, tài nguyên, thời gian khởi động, quản lý và ứng dụng.

Câu hỏi 10: Trong các giao thức phân tầng, mỗi tầng sẽ có một header riêng. Vậy có nên triển
khai một hệ thống mà tất cả các header của các tầng đưa chung vào một phần (gọi là header chung),
gắn vào đầu mỗi thông điệp để có thể xử lý chung? Giải thích.
Trả lời:
Không nên triển khai một hệ thống với header chung như vậy vì các header ở mỗi tầng được
thiết kế để chứa thông tin đặc trưng của tầng đó. Việc đưa các header này vào một header chung
sẽ làm cho việc xử lý trở nên khó khăn và không hiệu quả.
Mỗi header ở mỗi tầng chứa các thông tin quan trọng cần thiết để các thiết bị mạng và các ứng
dụng có thể hiểu và xử lý thông điệp đó. Các header đóng vai trò quan trọng trong việc định
tuyến, kiểm soát lỗi, xác thực và quản lý tài nguyên trong mạng. Nếu đưa tất cả các header vào
một header chung, sẽ làm cho thông điệp trở nên không rõ ràng và khó hiểu, đồng thời cũng làm
tăng độ phức tạp trong việc xử lý và quản lý thông điệp.
Do đó, việc tách riêng các header ở mỗi tầng là cần thiết để đảm bảo tính hiệu quả và hiệu suất
cho các giao thức phân tầng.

Câu hỏi 11: Xét 1 thủ tục incr với 2 tham số nguyên. Thủ tục làm nhiệm vụ là cộng 1 đơn vị vào
mỗi tham số. Bây giờ xét trường hợp chúng ta gọi thủ tục đó với cùng một biến, ví dụ incr(i, i).
Nếu biến i được khởi tạo giá trị 0, vậy giá trị của i sẽ là bao nhiêu sau khi gọi thủ tục này trong 2
trường hợp sau:
- Lời gọi tham chiếu
- Phương pháp sao chép-phục hồi được sử dụng.
Trả lời:
• Trong trường hợp lời gọi tham chiếu, tham số i sẽ truyền địa chỉ của biến i vào thủ tục.
Khi thủ tục được gọi, giá trị của biến i sẽ được tăng lên 1 và được lưu trữ lại tại địa chỉ
mà biến i đang trỏ đến. Do đó, sau khi gọi thủ tục incr(i, i), giá trị của biến i sẽ là 2.
• Trong phương pháp sao chép-phục hồi, tham số i được sao chép vào một biến tạm thời
trong thủ tục incr. Khi thủ tục được gọi, giá trị của biến tạm thời này được tăng lên 1,
nhưng giá trị này không được lưu trữ lại cho biến i gốc. Thay vào đó, sau khi thủ tục incr
hoàn thành, giá trị của biến tạm thời sẽ được sao chép trở lại vào biến i gốc. Do đó, sau
khi gọi thủ tục incr(i, i), giá trị của biến i sẽ là 1.
Câu hỏi 12: Một kết nối socket cần 4 thông tin nào? Tại sao phải cần đủ 4 thông tin đó?
Trả lời:
Một kết nối socket cần 4 thông tin sau:
1. Địa chỉ IP nguồn (source IP): địa chỉ IP của máy gửi gói tin.
2. Cổng nguồn (source port): số hiệu của cổng trên máy gửi gói tin.
3. Địa chỉ IP đích (destination IP): địa chỉ IP của máy nhận gói tin.
4. Cổng đích (destination port): số hiệu của cổng trên máy nhận gói tin.
Các thông tin này cùng nhau tạo thành một địa chỉ socket duy nhất để xác định một kết nối giữa
hai máy tính trên mạng.

Việc cần đủ 4 thông tin này để tạo kết nối là vì trên một máy tính có thể có nhiều ứng dụng đang
lắng nghe trên các cổng khác nhau. Điều này có nghĩa là cùng một địa chỉ IP có thể liên kết với
nhiều cổng khác nhau trên cùng một máy tính. Do đó, việc chỉ định địa chỉ IP mà không đủ
thông tin về cổng đích có thể dẫn đến việc truyền đến một ứng dụng không đúng. Tương tự, chỉ
cung cấp địa chỉ IP và cổng đích mà không có thông tin về địa chỉ IP nguồn và cổng nguồn cũng
không đủ để xác định một kết nối socket.

Câu hỏi 13: Tại sao giao thức yêu cầu-trả lời (request-reply) lại được coi là đồng bộ và tin cậy?
Trả lời:
Giao thức yêu cầu-trả lời được coi là đồng bộ và tin cậy vì khi một bên gửi yêu cầu (request) tới
bên nhận, nó sẽ đợi cho đến khi nhận được phản hồi (reply) từ bên nhận trước khi thực hiện các
hoạt động tiếp theo. Khi bên nhận nhận được yêu cầu, nó sẽ phản hồi lại cho bên gửi với một câu
trả lời hợp lệ hoặc một mã lỗi nếu yêu cầu không được thực hiện thành công.

Giao thức yêu cầu-trả lời cũng được coi là tin cậy bởi vì nó sử dụng cơ chế xác nhận
(acknowledgement) để đảm bảo rằng tất cả các yêu cầu và phản hồi được truyền đến đúng địa chỉ
và không bị mất trong quá trình truyền. Cơ chế xác nhận này cho phép bên gửi yêu cầu biết được
khi nào phản hồi đã được gửi về thành công và khi nào nó cần gửi lại yêu cầu.

Tóm lại, giao thức yêu cầu-trả lời được coi là đồng bộ và tin cậy bởi vì nó đảm bảo rằng tất cả
các yêu cầu và phản hồi được xử lý đúng thứ tự và không bị mất trong quá trình truyền.
Câu hỏi 14: Hai vấn đề chính đối với giao thức RPC là gì?
Trả lời:
Hai vấn đề chính đối với giao thức RPC (Remote Procedure Call) là đảm bảo tính nhất quán và
đảm bảo tính tin cậy.

Vấn đề đầu tiên là đảm bảo tính nhất quán. Vì RPC cho phép các ứng dụng chạy trên các nền
tảng khác nhau giao tiếp với nhau, vì vậy việc đảm bảo tính nhất quán giữa các nền tảng khác
nhau là rất quan trọng. Điều này đặc biệt khó khăn khi các hệ thống có nhiều điểm kết nối
(multiple endpoints), ví dụ như trong một hệ thống phân tán có nhiều server. Khi một yêu cầu
được gửi đến một server nhất định, việc đảm bảo rằng tất cả các server khác trong hệ thống cũng
đang thực hiện cùng một thao tác là rất quan trọng để đảm bảo tính nhất quán.
Vấn đề thứ hai là đảm bảo tính tin cậy. RPC phải đảm bảo rằng yêu cầu được gửi từ client đến
server và kết quả được trả về từ server đến client đúng và không bị mất mát. Điều này đặc biệt
quan trọng trong các hệ thống phân tán, nơi mà yêu cầu có thể được gửi qua một mạng không
đáng tin cậy và truyền qua nhiều nút trung gian trước khi đến đích. Vì vậy, RPC cần sử dụng các
cơ chế như xác thực (authentication), mã hóa (encryption) và kiểm soát lỗi (error control) để đảm
bảo tính tin cậy.
Câu hỏi 15: Vấn đề đối với truyền tham biến trong RPC là gì? Còn đồi với truyền tham chiếu?
Giải pháp đưa ra là gì?
Trả lời:
• Vấn đề đối với truyền tham biến trong RPC là khi tham số được truyền bằng giá trị, một
bản sao của giá trị được truyền sang phía máy chủ, do đó bất kỳ thay đổi nào đối với
tham số trên phía máy chủ đều không ảnh hưởng đến tham số gốc trên phía khách hàng.
Điều này có thể dẫn đến sự không đồng bộ giữa dữ liệu trên máy khách và máy chủ.

• Với truyền tham chiếu, tham số được truyền qua tham chiếu và bất kỳ thay đổi nào đối
với tham số trên phía máy chủ đều ảnh hưởng đến tham số gốc trên phía khách hàng. Tuy
nhiên, việc truyền tham chiếu có thể dẫn đến một số vấn đề như xung đột tham chiếu, vấn
đề bảo mật và hiệu suất.

• Một giải pháp để giải quyết vấn đề này là sử dụng truyền tham biến thông qua con trỏ
hoặc tham số con trỏ, thay vì truyền tham chiếu. Truyền tham số thông qua con trỏ cho
phép phía máy chủ có thể thực hiện thay đổi trực tiếp đối với dữ liệu của tham số, giống
như truyền tham chiếu, mà không gây ra các vấn đề về xung đột tham chiếu. Tuy nhiên,
điều này đòi hỏi kỹ năng lập trình cao và sự quản lý chặt chẽ hơn về bộ nhớ để tránh các
vấn đề bảo mật và hiệu suất.
Câu hỏi 16: So sánh RMI và RPC. Nhược điểm của RMI so với RPC là gì?
Trả lời:
RMI (Remote Method Invocation) và RPC (Remote Procedure Call) đều là các công nghệ dùng
để gọi các phương thức từ một remote server.
Tuy nhiên, có một số khác biệt chính giữa RMI và RPC:
1. Ngôn ngữ: RMI hỗ trợ Java, trong khi RPC có thể sử dụng trong nhiều ngôn ngữ khác
nhau.
2. Hệ điều hành: RMI chỉ hoạt động trên các hệ thống Java, trong khi RPC có thể hoạt động
trên nhiều hệ thống khác nhau.
3. Cách thức gọi: RPC gọi trực tiếp phương thức từ remote server, trong khi RMI sử dụng
Java RMI Registry để tìm kiếm các remote object.
4. Kiểm soát: RMI cung cấp các tính năng kiểm soát như quản lý đối tượng, định dạng dữ
liệu và đăng ký đối tượng, trong khi RPC không có tính năng kiểm soát tương tự.
Tuy nhiên, RMI có một số nhược điểm so với RPC:
1. Hiệu suất: RMI chậm hơn RPC vì nó sử dụng một số đặc tính Java như serialization và
garbage collection.
2. Phân cấp: RMI yêu cầu phải tuân thủ một số quy tắc về kiến trúc phân cấp trong khi RPC
không yêu cầu điều này.
 3. Sự phức tạp: RMI có cấu trúc phức tạp hơn RPC, do đó yêu cầu có nhiều kiến thức về
Java và kiến trúc hệ thống phân tán.
Tóm lại, cả hai công nghệ đều có ưu điểm và nhược điểm của riêng mình, tùy thuộc vào nhu cầu
của ứng dụng và môi trường triển khai để lựa chọn công nghệ phù hợp.

Câu hỏi 17: Hàm listen được sử dụng bởi TCP server có tham số là backlog. Giải thích ý nghĩa
tham số đó.
Trả lời:
Tham số backlog của hàm listen trong TCP server là một giá trị nguyên, xác định số lượng kết
nối đang chờ được xử lý bởi server. Nó đại diện cho kích thước của hàng đợi yêu cầu kết nối
đang chờ được phục vụ.

Khi một kết nối được thiết lập tới server, nó được đưa vào hàng đợi, nơi nó đợi cho đến khi
server sẵn sàng để xử lý nó. Nếu hàng đợi đã đầy, thì các kết nối mới sẽ bị từ chối cho đến khi
một số kết nối trong hàng đợi được xử lý hoặc bị hủy.

Do đó, giá trị backlog được sử dụng để xác định số lượng tối đa của các kết nối đang chờ được
xử lý bởi server. Nếu số lượng kết nối trong hàng đợi vượt quá giá trị này, các kết nối mới sẽ bị
từ chối.

Tùy thuộc vào hệ thống và các yêu cầu kết nối cụ thể, giá trị của backlog có thể được điều chỉnh
để tối ưu hóa hiệu suất và đáp ứng yêu cầu của hệ thống.

Câu hỏi 18: Trong trao đổi thông tin hướng dòng, những cơ chế thực thi QoS được thực hiện ở
tầng nào? Giải thích. Trình bày một số cơ chế thực thi QoS để chứng minh điều đó.
Trả lời:
Trong trao đổi thông tin hướng dòng, cơ chế thực thi QoS (Quality of Service) thường được thực
hiện ở tầng mạng (Network Layer) và tầng vận chuyển (Transport Layer).
Ở tầng mạng, một số cơ chế thực thi QoS bao gồm:
• DiffServ (Differentiated Services): là một cơ chế phân loại dịch vụ trên mạng, cho phép
các gói tin được đánh dấu ưu tiên khác nhau để đảm bảo chất lượng truyền tải của các dịch
vụ trên mạng.
• MPLS (Multiprotocol Label Switching): là một kỹ thuật định tuyến trên mạng, cho phép
đánh dấu ưu tiên và định tuyến các gói tin trên mạng.
• RSVP (Resource Reservation Protocol): là một giao thức cho phép các thiết bị mạng yêu
cầu các tài nguyên mạng trước khi truyền dữ liệu, để đảm bảo chất lượng truyền tải của các
ứng dụng trên mạng.
Ở tầng vận chuyển, một số cơ chế thực thi QoS bao gồm:
• TCP (Transmission Control Protocol): cung cấp các tính năng như kiểm soát lưu lượng
(flow control) và điều tiết tốc độ truyền dữ liệu (congestion control) để đảm bảo chất lượng
truyền tải của các kết nối TCP.
• UDP (User Datagram Protocol): mặc dù không cung cấp các tính năng QoS, nhưng cho
phép các ứng dụng tự xác định các cơ chế QoS để đảm bảo chất lượng truyền tải của các
gói tin.
Các cơ chế thực thi QoS này giúp đảm bảo chất lượng truyền tải của các dịch vụ trên mạng và đáp
ứng yêu cầu về hiệu suất của các ứng dụng truyền thông.