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

ENSC 427: MẠNG TRUYỀN THÔNGSo 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 ch

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