BÀI GIẢNG MẠNG LƯỚI TRUYÊN THÔNG

ENSC 427: MẠNG TRUYỀN THÔNG
So sánh TCP với "UTP" để chuyển BitTorrent
Tóm tắt
Torrent là một giao thức tầng ứng dụng dùng để chuyển các tệp ngang hàng và hiện được
triển khai trên TCP chuẩn trong hầu hết các ứng dụng hỗ trợ nó [1]. Hiện tại, khách hàng
BitTorrent phổ biến, uTorrent, đã bắt đầu thử nghiệm một phiên bản mới sẽ hỗ trợ một
giao thức được gọi là "uTP", một dịch vụ vận tải đáng tin cậy được triển khai trên UDP
sẽ chuyển dữ liệu ứng dụng BitTorrent giữa các máy khách hỗ trợ giao thức uTP [2]. Mục
tiêu đã nêu của thay đổi này nhằm giảm thiểu chất lượng gián đoạn dịch vụ đối với các
ứng dụng khác đang chạy trên kết nối internet của người dùng bằng cách cho phép
BitTorrent kiểm soát trực tiếp các tham số kiểm soát tắc nghẽn thường được thực hiện bởi
TCP. Dự án này mô phỏng hoạt động của BitTorrent trên mạng, sử dụng cả việc triển khai
chuẩn và uTP, và kiểm tra sự thay đổi trong giao thức ảnh hưởng đến chất lượng dịch vụ
cho việc truyền BitTorrent và một ứng dụng (VoIP) khác đang chạy trên cùng một mạng.
1. Giới thiệu:
Giao thức BitTorrent là một giao thức mức ứng dụng phổ biến cho phép một nhóm khách
hàng, được hỗ trợ bởi một máy chủ điều phối được gọi là bộ theo dõi, để tạo mạng ngang
hàng trên internet với mục đích chuyển một tệp hoặc tập hợp các tệp. Một mô tả ngắn
gọn về hoạt động của giao thức sau [1]:
- Một máy khách BitTorrent là một máy tính đang chạy một ứng dụng hỗ trợ giao
thức BitTorrent. Khách hàng có thể có tất cả, một số hoặc không có phần nào của
(các) tệp cho mạng BitTorrent cụ thể mà nó sẽ tham gia.
- Máy khách tải xuống tệp .torrent, thường từ máy chủ qua HTTP. Tệp này chứa
thông tin về bộ theo dõi và trên (các) tệp sẽ được chuyển qua mạng BitTorrent cụ
thể.
- Sử dụng thông tin trong tệp .torrent, máy khách kết nối với bộ theo dõi, thông báo
cho người theo dõi rằng nó (sử dụng ID ngang hàng, địa chỉ IP và cổng) được
tham gia vào mạng BitTorrent cụ thể này và nhận danh sách (trong ID ngang hàng,
IP và cổng) của các ứng dụng khách khác. Điều này xảy ra không chỉ khi tham gia
torrent, mà còn định kỳ (thường là 15 phút mặc định nhưng có thể được điều chỉnh
bằng tay trong ứng dụng khách uTorrent) trong khi máy khách là một phần của

mạng BitTorrent.
- Khách hàng kết nối với các đồng nghiệp khác thông qua TCP và trao đổi thư phù
hợp với đặc tả giao thức BitTorrent, có thể bao gồm các phần của tệp đang được
gửi từ một trong các đồng nghiệp này sang một tệp khác.
Điều quan trọng cần lưu ý là việc tải xuống tệp .torrent chỉ xảy ra một lần và các kết nối
tới trình theo dõi xảy ra không thường xuyên và cả hai đều liên quan đến việc khách hàng
tải xuống một lượng thông tin rất khiêm tốn (hàng chục KB). Trong khi mô hình hóa quá
trình các theo dõi có thể là quan trọng để hiểu cách cấu trúc liên kết mạng BitTorrent thay
đổi theo giờ, nó tương đối không quan trọng để đánh giá Quality of Service (QoS), vì
điều này sẽ được xác định chủ yếu bằng cách chuyển dữ liệu xảy ra giữa bất kỳ kịch bản
nào xảy ra được kết nối tại một thời điểm nhất định. Vì vậy, với mục đích của các mô


phỏng của dự án này, sự nhấn mạnh được đặt vào mô hình hóa quy trình chuyển giao
ngang hàng.
Việc kiểm soát luồng cho dữ liệu ngang hàng ngang được cung cấp bởi giao thức
BitTorrent tương đối thô sơ. Mỗi kết nối mà một khách hàng duy trì với một peer có thể ở
trạng thái “bị nghẹt thở” hoặc “không được cho phép”. Nếu peer A đặt kết nối của nó tới
peer B trong trạng thái unchoked (bằng cách gửi thông báo thích hợp), và nó "quan tâm"
trong việc nhận dữ liệu, peer B sẽ gửi các phần ngang hàng. Nếu không, nếu kết nối bị
“nghẹt thở”, sẽ không xảy ra việc chuyển. Trạng thái nghẹt thở của mỗi người ngang
nhau được thay đổi nhiều nhất sau mỗi 10 giây.
Trong khi phương pháp này đủ để đảm bảo rằng việc gửi các phần tử của khách hàng đến
các kịch bản khác không gây ra nhiều tắc nghẽn để giảm tốc độ tải xuống, nó không cung
cấp đủ quyền kiểm soát để cho phép tồn tại đồng thời với các ứng dụng khác trên máy
khách máy vi tính. Ví dụ, duyệt web qua HTTP thường gặp phải sự chậm trễ đáng kể nếu
BitTorrent cũng đang được sử dụng trên cùng một máy khách. Để giảm bớt những vấn đề
này, một số ứng dụng BitTorrent cung cấp một phương tiện để điều chỉnh việc truyền dữ
liệu đến và đi bằng cách giới hạn nó tới một tốc độ số cụ thể. Bằng cách chọn tỷ lệ hơi
thấp hơn khả năng kết nối của máy tính đó với internet, có thể giảm thiểu sự gián đoạn

cho các ứng dụng khác trên máy tính khách.
Thật không may, phương pháp này có nhiều hạn chế. Thứ nhất, nó sẽ tận dụng tối đa kết
nối khi không có ứng dụng nào khác đang chuyển dữ liệu, và sẽ dẫn đến sự xuống cấp
QoS mà các ứng dụng khác chuyển quá nhiều. Ngoài ra, khả năng kết nối internet của
người dùng có thể thay đổi theo thời gian do tính chất chung của tài nguyên trên nhiều
kết nối internet gia đình; tuy nhiên, phương pháp giới hạn tốc độ tĩnh không cung cấp
phương tiện để điều chỉnh động cho các điều kiện thay đổi này.
Như một câu trả lời cho những thiếu sót này, máy khách BitTorrent “uTorrent” đã thực
hiện một giao thức được gọi là “uTP” [2]. Trong uTP, các gói UDP (thay vì TCP) được sử
dụng để truyền dữ liệu giữa các máy ngang hàng và chuyển giao đáng tin cậy theo kết
nối, cũng như kiểm soát tắc nghẽn, được thực hiện bởi lớp ứng dụng. Bằng cách di
chuyển các tính năng này vào lớp ứng dụng, các nhà phát triển uTorrent hy vọng tối đa
hóa tốc độ truyền dữ liệu BitTorrent tốt hơn đồng thời giảm thiểu sự gián đoạn QoS cho
các ứng dụng khác có thể đang chạy trên máy khách [3].
Mục đích của dự án này là phân tích và so sánh QoS với BitTorrent và một ứng dụng ví
dụ (VoIP) trong hai kịch bản: Một sử dụng một phiên bản mô phỏng của giao thức
BitTorrent và một phiên bản sử dụng mô phỏng uTP. So sánh này của QoS sẽ cung cấp
một cái nhìn sâu sắc về những lợi thế và bất lợi của UTP.
2. Tạo mô hình OPNET:
2.1 Cấu trúc mạng:
Giao thức uTP có một số khác biệt lớn so với việc thực hiện thông thường của BitTorrent
[3]. Thứ nhất, giao thức truyền tải được thay thế bằng UDP, tuy nhiên để cung cấp theo
yêu cầu của ứng dụng BitTorrent, một giao thức trung gian trong lớp ứng dụng được yêu
cầu. Giao thức mức ứng dụng này là định hướng kết nối và cung cấp khả năng truyền tải
có khả năng truyền tải được bằng lưu lượng BitTorrent. Sự kết hợp của UDP và giao thức
tầng ứng dụng này, được đề cập đến trong báo cáo này là “giả TCP”, tạo thành một ngăn


xếp giao thức mới chuyển dữ liệu BitTorrent theo một cách mới lạ. Phương pháp chuyển
giao mới này là so sánh uTP. Các ngăn xếp giao thức có thể được thấy bên dưới trong

Hình 1.

Hình 1: Ngăn xếp giao thức cho BitTorrent chuẩn và uTP
Sự khác biệt chính mà uTP so với TCP là các quy tắc cho kiểm soát tắc nghẽn được tinh
chỉnh để cố gắng mô phỏng mục tiêu thiết kế của việc cải thiện QoS trong mạng. [3] Để
mô hình hóa một mạng lưới BitTorrent ngang hàng một cách thích hợp, một mô hình
OPNET được tạo ra với cả máy khách và máy chủ để mô phỏng các seeders (các peer chỉ
tải lên các peer khác) và leechers (các peer có thể tải lên và download đồng nghiệp). Mô
hình này bao gồm một mạng lưới trường với một đám mây IP, 5 mạng con máy chủ được
đặt trước với "S" và 5 mạng con khách hàng được đặt trước bằng "C". Các mạng con này
được kết nối với đám mây IP thông qua các dòng T1, khả năng của một đường T1 (~
1,5MBps), theo kinh nghiệm của các tác giả, tương tự như khả năng kết nối DSL . Mặc
dù các kịch bản BitTorrent được kết nối trên quy mô toàn cầu, chúng tôi đã chọn so sánh
các giao thức trên mạng lưới nhỏ hơn, trong khuôn viên trường, lưu ý rằng đây không


phải là mạng lưới trường học mà là mạng trên phạm vi toàn khuôn viên trường. Mạng
lưới khuôn viên tổng thể được thể hiện trong Hình 2.

Hình 2: Mạng Campus
Các mạng con của khách hàng bao gồm ba máy trạm được gắn vào một bộ định tuyến
thông qua các đường Ethernet 100Base-T, sau đó router được gắn vào đường T1 được kết
nối với đám mây IP. Các máy trạm này hoạt động như các leechers trên mạng BitTorrent.
Trong một mạng BitTorrent thực tế, các máy trạm này sẽ tải lên và tải xuống đồng thời,
nhưng do các hạn chế với các ứng dụng tùy chỉnh trong OPNET, các trạm được mô hình
hóa như chỉ tải xuống. Các lý do cho việc này được thảo luận bên dưới.


Hình 3: Client Subnet
Mạng con máy chủ bao gồm một máy chủ duy nhất được kết nối với một bộ định tuyến

thông qua kết nối 100Base-TEthernet, sau đó kết nối với đám mây IP. Máy chủ này chỉ
tải lên dữ liệu lên mạng và như vậy gần giống với một trình tạo giống BitTorrent thực tế.
Máy chủ mạng con được hiển thị trong Hình 4.

Hình 4: Server Subnet
Số lượng khách hàng và máy chủ được chọn để đại diện cho số lượng người tham gia và
leechers một cách điển hình. Khi torrent bắt đầu, chỉ có một nguồi tham gia hiện diện.
Leechers sau đó sẽ tham gia và khi họ hoàn thành tải về của họ, họ sẽ hành động như
seeders. Một số kịch bản cũng sẽ rời khỏi mạng BitTorrent theo thứ tự đã hoàn thành để
tránh tải quá nhiều dữ liệu. Khi torrent trở nên hoàn thiện hơn, tỷ lệ của các người tham


gia với leechers có thể ổn định từ 0,25 đến 0,5, hoặc nói cách khác là 2 đến 4 leechers
cho mỗi seeder. Mô hình OPNET bao gồm 3 leecher cho mỗi seeder để leecher tỷ lệ
0.33.Các công việc khác liên quan đến mạng p2p trong OPNET cho thấy một kiến trúc
tương tự nhưng ở một mức độ phức tạp hơn so với nhiều ứng dụng khác nhau với lưu
lượng p2p.
2.2.Application Profiles và định nghĩa:
Có hai ứng dụng được sử dụng trong phân tích uTP: FTP và VoIP. FTP đã được chọn để
mô hình hóa hành vi của việc chuyển tập tin từ một seeder sang một leecher. Một hạn chế
là lưu lượng FTP gần như hoàn toàn một chiều từ các máy chủ đến máy khách, và do đó
không đại diện cho hành vi hoàn chỉnh của BitTorrent nơi hai kịch bản có thể trao đổi dữ
liệu hai chiều. Trong khi hành vi này có thể đã được mô hình hóa với một ứng dụng tùy
chỉnh, thì có những vấn đề triển khai đáng kể mà cuối cùng đã sử dụng các ứng dụng tùy
chỉnh không khả thi. VoIP đã được sử dụng như một ứng dụng “đồng tồn tại” để mô hình
hóa các hiệu ứng trên các ứng dụng QoS khác mà việc truyền dữ liệu BitTorrent bằng
TCP thông thường và với UTP. Mô tả ứng dụng FTP được hiển thị bên dưới trong Hình 5.

Hình 5: Định nghĩa ứng dụng (chi tiết FTP)
Truyền tệp FTP này gửi một tệp 100Mb một lần trong toàn bộ quá trình mô phỏng nhằm

mang lại hiệu quả sử dụng mạng cho một điểm bão hòa. Mỗi seeder và leecher sử dụng


định nghĩa FTP này. Thời gian yêu cầu liên tiếp được đặt thành một giờ để đảm bảo mô
phỏng kết thúc trước khi một tệp khác được gửi. Điều này cho phép quan sát một tập tin
được chuyển cho mỗi nhóm seeder / leecher, s2 và c2 mạng con tương tác với nhau khi
máy chủ trong s2 cung cấp tệp 100Mb cho ba máy khách trong mạng con thứ hai. Điều
tương tự cũng xảy ra với s3, c3 mạng con như vậy.

Hình 6: Định nghĩa ứng dụng (các chi tiết VoIP)
Các chi tiết ứng dụng VoIP đều được giữ cho các tham số mặc định của chúng vì không
cần thêm sự phức tạp nào. Chỉ có một cuộc gọi VoIP, giữa S0 và C00, hoạt động trong
kịch bản này, và thống kê cho lưu lượng truy cập FTP và lưu lượng VoIP được thu thập
riêng cho cặp máy khách-máy chủ này.
Thiết lập mạng này đã hình thành kịch bản cơ bản, nơi lưu lượng VoIP truyền giữa hai
kịch bản cũng là một phần của mạng BitTorrent.
Kịch bản này sau đó được nhân bản và sửa đổi để tạo ra một kịch bản thứ hai đại diện
cho uTP. Để đại diện cho hai kịch bản với những thay đổi uTP, S0 và C00 đã thay đổi


thông số TCP của họ. Dưới đây là hình 7 mô tả các thay đổi uTP mới đã được thực hiện
cho hai kịch bản.

Hình 7: Các thay đổi được thực hiện đối với TCP để mô hình hóa UTP
Trong khi mô phỏng một giao thức truyền qua UDP sử dụng TCP được sửa đổi lúc đầu có
vẻ lạ, điều quan trọng cần nhớ là uTP có giao thức mức ứng dụng hoạt động theo cách
tương tự như TCP. Vì UDP không kiểm soát tắc nghẽn, và kiểm soát tắc nghẽn là trọng
tâm của dự án này, mô phỏng uTP sử dụng lưu lượng UDP chung không phải là một tùy
chọn. Thay vào đó, ngăn xếp giả TCP / UDP được mô phỏng bằng TCP với các tham số
đã sửa đổi.

2.2.1.Segment Size:
Kích thước phân đoạn tối đa (MSS) là số lượng dữ liệu lớn nhất (tính bằng byte) mà thiết
bị truyền thông có thể xử lý trong một TCP và IPv4 đơn lẻ, MSS được tính bằng cách sử
dụng đơn vị truyền tải tối đa (MTU) của Ethernet và kích thước tiêu đề của cả TCP và


IPv4. Các tiêu đề TCP và IPv4 đều là 20 byte và MSS bằng MTU trừ đi kích thước tiêu
đề của cả IPv4 và TCP được cộng với nhau là 1460 byte [5]. Nếu một phân đoạn dữ liệu
lớn hơn MTU, datagram phải được phân mảnh theo RFC 791 [4]. Trong phiên bản của
uTP đã được phát triển tại thời điểm dự án, kích thước gói được đặt thành 300 byte cố
định, do đó, mô phỏng OPNET này, MSS được đặt thành 300 byte [3].
2.2.2.Fast Recovery:
Tham số khôi phục nhanh đề cập đến thuật toán được thực hiện trong điều kiện tránh tắc
nghẽn khi các gói bị loại bỏ. Khi một gói bị loại bỏ, một ACK trùng lặp được nhận như
trong Hình 8 [7]. Tắc nghẽn sẽ được hủy khi ba ACKS trùng lặp được gửi lại cho người
gửi. Ngưỡng này được biểu thị bằng tham số 'ngưỡng trùng lặp ACK' được hiển thị trong
Hình 7. TCP duy trì cửa sổ nghẽn giới hạn tổng số gói tin không được nhận biết giữa các
thiết bị liên lạc để tránh sự sụp đổ tắc nghẽn. Thông qua một cơ chế được gọi là 'khởi
động chậm', cửa sổ nghẽn được tăng lên sau khi kết nối đã được thực hiện và sau khi hết
thời gian chờ. Đối với mỗi gói được thừa nhận, cửa sổ sẽ tăng lên theo 1xMSS byte. Khi
kích thước cửa sổ này đã tăng trên ngưỡng quy định hoặc khi tắc nghẽn được phát hiện
thông qua ACK trùng lặp, thuật toán tránh tắc nghẽn, chẳng hạn như Reno hoặc New
Reno, bắt đầu ảnh hưởng đến kích thước cửa sổ. Theo mặc định, thuật toán phục hồi
nhanh được sử dụng cho tắc nghẽn Reno [6].

Hình 8: Các gói bị loại bỏ tạo ra các ACKS trùng lặp.
Khi thuật toán Reno bị bắt buộc, cửa sổ nghẽn bị giảm đi một nửa sau khi nhận được ba
ACKS trùng lặp và hệ thống thực hiện ‘truyền lại nhanh’ và đi vào giai đoạn ‘phục hồi
nhanh’ mà gói tin bị bỏ được truyền lại. Nếu ACK cho gói truyền lại này không nhận
được, thời gian chờ xảy ra.

Khi tắc nghẽn xảy ra, cửa sổ nghẽn bị giảm bởi một lượng phụ thuộc vào thuật toán đang
sử dụng. Nếu phương pháp khôi phục nhanh Reno được sử dụng (như trong kịch bản cơ
bản), cửa sổ nghẽn bị giảm đi một nửa. Trong mô phỏng của uTP, các tham số TCP đã
được thay đổi để vô hiệu hóa phục hồi nhanh, do đó hệ thống khởi tạo "truyền lại nhanh"
sau ba ACKS trùng lặp được phát hiện và cửa sổ nghẽn được giảm xuống còn 1 MSS.
Điều này được thực hiện ngay lập tức sau khi nhận được ba ACKS trùng lặp trước khi
chờ thời gian chờ của nó, do đó 'truyền lại nhanh' [8] thay đổi này có nghĩa là cửa sổ
nghẽn sẽ dành nhiều thời gian hơn với giá trị nhỏ hơn trong kịch bản uTP, nên làm cho
TCP (trong kịch bản uTP) ít tích cực hơn về lượng dữ liệu mà nó gửi. Do đó, mô hình
này sẽ tăng cường sự tồn tại đồng thời (QoS nâng cao cho các ứng dụng khác đang chạy
trên máy trạm) mà uTP có ý định đạt được.
2.2.3.Slow-Start Initial Count (MSS):
Ban đầu, thông số TCP, 'số khởi đầu chậm,' được đặt thành 2 theo mặc định. Trong kịch
bản uTP, giá trị này đã giảm xuống còn 1, sao cho cửa sổ nghẽn sẽ bắt đầu với kích thước
nhỏ hơn. Giống như thay đổi trước đó, điều này dẫn đến cửa sổ tắc nghẽn dành nhiều thời
gian hơn ở kích thước nhỏ hơn.
Ba thông số này là những thay đổi đối với TCP mà chúng tôi đã thực hiện để mô phỏng
uTP. Mô hình hóa hành vi của uTP bằng cách sử dụng UDP, như đã giải thích ở trên, dẫn
đến một biểu diễn không chính xác về cách thức hoạt động của giao thức uTP. Bằng cách
giữ TCP làm giao thức truyền tải dịch vụ đáng tin cậy chính trong mô phỏng, các kết quả
mô phỏng phản ánh những gì được quan sát trong thực tế chính xác hơn. Những thay đổi
được thực hiện cho TCP là các hiệu ứng được mô hình hóa cho các giao thức truyền tải
mới và các kết quả của chúng tôi cho thấy những thay đổi hợp lý không hiệu quả của các
ứng dụng khác khi sử dụng giao thức uTP được đánh giá.
3. Kết quả:
Độ trễ gói tin trên mạng được hiển thị trong Hình 9. Sau khi mạng đạt đến trạng thái hoạt
động ổn định, có thể thấy rằng TCP thông thường (được hiển thị bằng màu xanh lam) và
uTP (hiển thị bằng màu đỏ) dẫn đến mức độ trễ trung bình tương tự . Sự khác biệt giữa

chúng là uTP dễ bị vỡ và luôn trong thời gian trễ. Có thể là các gói TCP nhỏ hơn sử dụng
kết quả kịch bản uTP trong biến thể này, tuy nhiên, nó không phải là dễ dàng.


Hình 9: Độ trễ gói trên IP Cloud.
Lưu lượng tổng thể nhận được từ một khách hàng được hiển thị trong Hình 10. Như được
hiển thị trên biểu đồ, ít dữ liệu hơn được truyền qua uTP tổng thể, do một số yếu tố. Một
trong những lý do là những thay đổi đối với hành vi tắc nghẽn, điều đó có nghĩa là cửa sổ
nghẽn chiếm nhiều thời gian hơn ở một giá trị nhỏ hơn trong kịch bản uTP. Tuy nhiên,
kích thước gói cũng sẽ đóng một vai trò. Các gói nhỏ hơn nhiều được sử dụng trong kịch
bản uTP sẽ làm giảm thông lượng của dữ liệu, vì các tiêu đề có kích thước cố định, phần
lớn không gian bên trong gói được đưa lên bởi các tiêu đề IP và TCP và do đó tỷ lệ băng
thông lớn hơn là "lãng phí" về chuyển tiêu đề.

Hình 10: Thông lượng lưu lượng TCP


Trình kích hoạt ứng dụng VoIP được hiển thị trong Hình 11. Như có thể thấy, sự tắc
nghẽn tích cực hơn trong kịch bản uTP có nghĩa là kết nối từ máy khách và máy chủ đến
mạng không được nạp nhiều dữ liệu FTP và do đó các gói VOIP có thể được thực hiện
thông qua mạng với tốc độ nhanh hơn.

Hình 11: Ứng dụng VoIP Jitter
Độ trễ từ đầu đến cuối cho ứng dụng VoIP được hiển thị trong Hình 12. Như có thể thấy,
điều khiển tắc nghẽn lại giảm tải trên kết nối máy khách và máy chủ với mạng và do đó
cho phép các gói VoIP được truyền đi chậm trễ hơn.

Hình 12: Ứng dụng VoIP End-to-End Delay

4. Kết luận
Dự án này triển khai phiên bản giao thức uTP rất hạn chế và đơn giản, và độ chính xác
của mô phỏng của UTP rất khó để đánh giá. Cấu trúc liên kết mạng cũng được đơn giản
hóa so với mạng BitTorrent trong thế giới thực. Tuy nhiên, mô phỏng của chúng tôi cho
thấy rằng uTP đã cải thiện thành công cùng tồn tại với các ứng dụng khác. Các gói VoIP
có kinh nghiệm chậm trễ, cũng như jitter chậm trễ, đã giảm đáng kể trong kịch bản uTP.
Theo dự kiến, QoS đã được cải thiện, vì tốc độ truyền dữ liệu BitTorrent giảm đáng kể.
Rõ ràng là từ mô phỏng này, kiểm soát lưu lượng tích cực được cung cấp bởi uTP cao
nhưng nhiều người dùng mạng cải thiện QoS cho các ứng dụng khác đang chạy
BitTorrent có khả năng đáng giá.