Phân phối tệp ngang hàng (Peer-to-Peer) trên Internet

Các ứng dụng được mô tả trong bài viết này bao gồm Web, e-mail, và DNS đều sử dụng kiến trúc client-server, phụ thuộc nhiều vào các máy chủ hạ tầng luôn hoạt động. Ở bài viết Tổng quan về tầng Ứng dụng trong mô hình TCP/IP, mình đã sơ lược về kiến trúc phân phối tệp ngang hàng P2P (peer-to-peer). Với kiến trúc này, sự phụ thuộc vào các máy chủ hạ tầng luôn hoạt động là rất ít (hoặc không có). Thay vào đó, các cặp máy chủ kết nối gián đoạn, được gọi là các “peer“, giao tiếp trực tiếp với nhau. Các peer này không thuộc sở hữu của nhà cung cấp dịch vụ, mà thay vào đó là các máy tính cá nhân (PC), laptop và điện thoại thông minh do người dùng điều khiển.

Trong phần này, chúng ta sẽ xem xét một ứng dụng P2P rất tự nhiên, đó là phân phối một tệp lớn từ một máy chủ đến một số lượng lớn các máy chủ khác (được gọi là các peer). Tệp này có thể là file ISO, file máy ảo, hoặc video MPEG. Trong phương pháp phân phối tệp kiểu client-server, máy chủ phải gửi một bản sao của tệp đến từng peer, gây ra một gánh nặng lớn cho máy chủ và tiêu tốn một lượng lớn băng thông của máy chủ. Trong phân phối tệp kiểu P2P, mỗi peer có thể phân phối lại bất kỳ phần nào của tệp mà nó đã nhận cho các peer khác, nhờ đó hỗ trợ máy chủ trong quá trình phân phối.

Tính đến năm 2020, giao thức phân phối tệp ngang hàng P2P phổ biến nhất là BitTorrent. Ban đầu được phát triển bởi Bram Cohen, hiện nay có rất nhiều khách hàng BitTorrent độc lập khác nhau tuân theo giao thức BitTorrent, tương tự như có nhiều trình duyệt Web tuân theo giao thức HTTP. Trong phần này, chúng ta sẽ đầu tiên xem xét khả năng tự mở rộng của các kiến trúc P2P trong bối cảnh phân phối tệp.

Sự linh hoạt của kiến trúc phân phối tệp ngang hàng P2P

Để so sánh các kiến trúc client-server với kiến trúc peer-to-peer (P2P) và minh họa khả năng tự mở rộng của phân phối tệp ngang hàng, ta sẽ xét đến một mô hình định lượng đơn giản để phân phối một tệp đến một tập hợp các peer cố định cho cả hai loại kiến trúc. Như thể hiện trong hình dưới, máy chủ và các peer đều kết nối với Internet thông qua các liên kết truy cập. Gọi tốc độ tải lên của liên kết truy cập của máy chủ là u_s​, tốc độ tải lên của liên kết truy cập của peer thứ iii là u_i​, và tốc độ tải xuống của liên kết truy cập của peer thứ i là d_i​. Cũng gọi kích thước của tệp cần phân phối (tính bằng bit) là F và số lượng các peer muốn nhận bản sao của tệp là N. Thời gian phân phối là thời gian cần thiết để gửi bản sao của tệp đến tất cả N peer.

Trong phân tích về thời gian phân phối dưới đây, cho cả kiến trúc client-server và P2P, chúng ta giả định đơn giản tất cả các nút nghẽn đều nằm ở các mạng truy cập. Chúng ta cũng giả định rằng máy chủ và các client không tham gia vào bất kỳ ứng dụng mạng nào khác, do đó tất cả băng thông tải lên và tải xuống của chúng có thể được dành hoàn toàn cho việc phân phối tệp này.

Xác định thời gian phân phối cho kiến trúc client-server, ký hiệu là D_cs​. Trong kiến trúc client-server, không có peer nào hỗ trợ phân phối tệp. Chúng ta có thể rút ra một số nhận xét sau:

• Máy chủ phải truyền một bản sao của tệp đến mỗi peer trong số N peer. Do đó, máy chủ phải truyền tổng cộng NF bit. Vì tốc độ tải lên của máy chủ là u_s​, thời gian phân phối tệp tối thiểu phải là NF/u_s​.
• Gọi d_min là tốc độ tải xuống của peer có tốc độ tải xuống thấp nhất, tức là d_min=min⁡{d₁,d₂,…,d_N}. Peer có tốc độ tải xuống thấp nhất không thể nhận được toàn bộ F bit của tệp trong thời gian ít hơn F/d_min giây. Do đó, thời gian phân phối tối thiểu là ít nhất F/d_min.

Kết hợp hai nhận xét này, chúng ta có thể rút ra thời gian phân phối tối thiểu cho kiến trúc client-server.

Điều này cung cấp một giới hạn dưới cho thời gian phân phối tối thiểu của kiến trúc client-server. Coi giới hạn dưới mà này là thời gian phân phối thực tế, tức là:

Chúng ta thấy từ phương trình trên rằng đối với N đủ lớn, thời gian phân phối trong kiến trúc client-server được cho bởi NF/u_s. Do đó, thời gian phân phối tăng theo tỷ lệ tuyến tính với số lượng peer N. Vì vậy, ví dụ, nếu số lượng peer từ tuần này sang tuần khác tăng lên gấp một nghìn lần, từ một nghìn lên một triệu, thì thời gian cần thiết để phân phối tệp cho tất cả các peer sẽ tăng lên gấp 1.000 lần.

Bây giờ, chúng ta sẽ tiến hành phân tích tương tự cho kiến trúc P2P, nơi mỗi peer có thể hỗ trợ máy chủ trong việc phân phối tệp. Cụ thể, khi một peer nhận được một số dữ liệu tệp, nó có thể sử dụng khả năng tải lên của mình để phân phối lại dữ liệu cho các peer khác. Việc tính toán thời gian phân phối cho kiến trúc P2P phức tạp hơn so với kiến trúc client-server, vì thời gian phân phối phụ thuộc vào cách mỗi peer phân phối các phần của tệp cho các peer khác. Tuy nhiên, một biểu thức đơn giản cho thời gian phân phối tối thiểu có thể được đưa ra [Kumar 2006]. Để làm được điều này, trước tiên chúng ta sẽ đưa ra một số nhận xét sau:

• Ban đầu của quá trình phân phối, chỉ máy chủ có tệp. Để đưa tệp này tới các peers, máy chủ phải gửi mỗi bit của tệp ít nhất một lần vào liên kết truy cập của nó. Do đó, thời gian phân phối tối thiểu là ít nhất F/us. (Không giống như mô hình client-server, một bit được gửi một lần bởi máy chủ có thể không cần phải gửi lại bởi máy chủ, vì các peers có thể phân phối lại bit đó giữa chúng.)
• Giống như kiến trúc client-server, peers có tốc độ tải xuống thấp nhất không thể nhận tất cả F bit của tệp trong thời gian ít hơn F/d_min giây. Do đó, thời gian phân phối tối thiểu là ít nhất F/d_min.
• Cuối cùng, nhận thấy rằng tổng băng thông tải lên của toàn bộ hệ thống bằng với tốc độ tải lên của máy chủ cộng với tốc độ tải lên của từng peer, tức là u_total = u_s + u₁ + … + u_N. Hệ thống phải cung cấp (tải lên) F bit cho mỗi peer trong số N peers, từ đó cung cấp tổng cộng NF bit. Điều này không thể thực hiện ở tốc độ nhanh hơn u_total. Do đó, thời gian phân phối tối thiểu cũng ít nhất là NF/(u_s + u₁ + … + u_N).

Kết hợp ba quan sát này lại, chúng ta thu được thời gian phân phối tối thiểu cho mô hình P2P, được ký hiệu là D_P2P.

Phương trình trên cung cấp một giới hạn dưới cho thời gian phân phối tối thiểu của kiến trúc P2P. Nếu chúng ta tưởng tượng rằng mỗi peer có thể phân phối lại một bit ngay khi nó nhận được bit đó, thì sẽ có một phương án phân phối lại có thể đạt được giới hạn dưới này.

Hìnhdưới so sánh thời gian phân phối tối thiểu cho kiến trúc client-server và P2P, giả sử rằng tất cả các peer có cùng tốc độ tải lên là u. Chúng ta đã đặt F/u = 1 giờ, u_s = 10u và d_min ≥ u_s. Do đó, một peer có thể truyền toàn bộ file trong một giờ, tốc độ truyền của máy chủ lớn gấp 10 lần tốc độ tải lên của peer, và (để đơn giản hóa) tốc độ tải xuống của các peer được đặt đủ lớn để không ảnh hưởng. Chúng ta thấy từ hình trên rằng đối với kiến trúc client-server, thời gian phân phối tăng tuyến tính và không có giới hạn khi số lượng peer tăng lên. Tuy nhiên, đối với kiến trúc P2P, thời gian phân phối tối thiểu không chỉ luôn nhỏ hơn thời gian phân phối của kiến trúc client-server mà còn nhỏ hơn một giờ đối với bất kỳ số lượng peer N nào. Vì vậy, các ứng dụng sử dụng kiến trúc P2P có khả năng tự mở rộng. Tính mở rộng này là hệ quả trực tiếp của việc các peer vừa là nhà phân phối lại vừa là người tiêu thụ các bit.

BitTorrent

BitTorrent là một giao thức P2P (peer-to-peer) phổ biến dùng để phân phối tệp tin [Chao 2011]. Trong thuật ngữ của BitTorrent, tập hợp tất cả các máy ngang hàng (peers) tham gia vào việc phân phối một tệp tin cụ thể được gọi là một torrent. Các máy ngang hàng trong một torrent sẽ tải về các phần (chunk) có kích thước bằng nhau của tệp tin từ những máy ngang hàng khác, với kích thước phần điển hình là 256 KB. Khi một máy ngang hàng lần đầu tham gia vào torrent, nó chưa có phần nào của tệp. Theo thời gian, máy sẽ tích lũy dần các phần tệp tin. Trong quá trình tải xuống các phần, máy cũng sẽ tải lên các phần cho các máy ngang hàng khác. Khi một máy ngang hàng đã tải xong toàn bộ tệp tin, nó có thể (một cách ích kỷ) rời khỏi torrent, hoặc (một cách vị tha) tiếp tục ở lại torrent để tải lên các phần cho những máy ngang hàng khác. Ngoài ra, bất kỳ máy ngang hàng nào cũng có thể rời khỏi torrent tại bất kỳ thời điểm nào khi chỉ mới có một số phần của tệp và có thể tham gia lại torrent sau đó.

Hãy cùng xem xét kỹ hơn cách thức hoạt động của BitTorrent. Vì BitTorrent là một giao thức và hệ thống khá phức tạp, chúng ta sẽ chỉ mô tả các cơ chế quan trọng nhất, bỏ qua một số chi tiết nhỏ để dễ hình dung tổng thể. Mỗi torrent có một nút hạ tầng được gọi là tracker. Khi một máy ngang hàng (peer) tham gia vào một torrent, nó sẽ đăng ký với tracker và định kỳ thông báo cho tracker rằng nó vẫn đang tham gia torrent. Bằng cách này, tracker sẽ theo dõi các máy ngang hàng đang tham gia vào torrent. Một torrent có thể có ít hơn mười hoặc nhiều hơn một nghìn máy ngang hàng tham gia tại bất kỳ thời điểm nào.

Khi một người dùng mới, chẳng hạn như Alice, tham gia vào một torrent, cô sẽ kết nối với một tracker — một máy chủ theo dõi các máy ngang hàng (peers) đang tham gia. Tracker sẽ cung cấp cho Alice một danh sách các peer ngẫu nhiên để bắt đầu quá trình trao đổi dữ liệu. Tại bất kỳ thời điểm nào, mỗi peer sẽ chỉ có một số phần nhất định của tệp tin, và nhiệm vụ của họ là trao đổi các phần mà họ thiếu.

Khi đã kết nối với một số peer, Alice sẽ yêu cầu danh sách các phần tệp mà từng người trong số họ sở hữu. Với thông tin này, Alice sẽ áp dụng chiến lược rarest first (ưu tiên phần hiếm nhất). Chiến lược này giúp Alice ưu tiên tải về những phần mà ít peer có nhất, nhằm đảm bảo rằng các phần hiếm được phân phối đều đặn trong cộng đồng, giúp tăng khả năng có sẵn của mỗi phần tệp trên toàn bộ mạng torrent. Đồng thời, Alice cũng phải quyết định gửi các phần mà mình đã tải về cho ai. BitTorrent sử dụng một cơ chế trao đổi ưu tiên (choked/unchoked) thông minh để tối ưu hóa tốc độ chia sẻ. Alice sẽ đo lường tốc độ tải lên của các peer đang cung cấp dữ liệu cho cô, sau đó chọn ra 4 peer có tốc độ tải lên cao nhất để ưu tiên chia sẻ lại dữ liệu. Những peer này được gọi là unchoked, tức là không bị giới hạn băng thông từ phía Alice. Cứ mỗi 10 giây, Alice sẽ tính toán lại tốc độ của các peer này và có thể thay đổi nhóm ưu tiên tùy theo hiệu suất.

Ngoài 4 peer ưu tiên này, cứ mỗi 30 giây, Alice sẽ chọn ngẫu nhiên một peer khác (gọi là optimistically unchoked) để thử trao đổi dữ liệu. Đây là một cách giúp các peer mới hoặc các peer chưa có nhiều phần tệp có cơ hội nhận được dữ liệu. Nếu quá trình trao đổi diễn ra suôn sẻ và tốc độ truyền tải đủ cao, các peer này có thể được đưa vào danh sách ưu tiên của nhau, giúp tăng khả năng trao đổi dữ liệu hiệu quả hơn.

Cơ chế này giúp đảm bảo rằng những peer có khả năng tải lên tốt sẽ tìm thấy nhau và cùng chia sẻ dữ liệu nhanh hơn. Đồng thời, việc chọn ngẫu nhiên một peer mới mỗi 30 giây cũng giúp những người tham gia mới dễ dàng hơn trong việc nhận dữ liệu ban đầu để họ có thể bắt đầu chia sẻ lại cho người khác. Các cơ chế thông minh như rarest first, choked/unchoked, và optimistic unchoking giúp BitTorrent trở thành một hệ thống chia sẻ tệp tin hiệu quả, cân bằng tải giữa các người dùng và tối ưu hóa tốc độ tải xuống cho tất cả các peer trong mạng.

Khi nói đến mạng P2P, ngoài việc chia sẻ tệp tin như trong BitTorrent, còn có một ứng dụng quan trọng khác được sử dụng rộng rãi, đó là Distributed Hash Table (DHT). DHT là một dạng cơ sở dữ liệu phân tán, trong đó các bản ghi dữ liệu được lưu trữ và phân phối trên các máy ngang hàng (peer) trong hệ thống P2P. Đây là một cách tổ chức và quản lý dữ liệu hiệu quả, giúp truy vấn thông tin nhanh chóng mà không cần một máy chủ trung tâm.

Trong BitTorrent, DHT đóng vai trò quan trọng trong việc giúp các peer tìm thấy nhau mà không cần đến một tracker truyền thống. Mỗi peer trong hệ thống DHT sẽ lưu trữ một phần nhỏ của bảng băm, cho phép nó tìm kiếm thông tin và định vị các peer khác một cách hiệu quả. DHT đã được nghiên cứu và phát triển rộng rãi, trở thành một phần không thể thiếu trong các ứng dụng P2P hiện đại, nhờ vào khả năng mở rộng tốt và khả năng hoạt động mà không phụ thuộc vào máy chủ trung tâm.

Bạn có thể tìm hiểu thêm về DHT qua các tài liệu và video hướng dẫn trên các trang web liên quan, giúp bạn hiểu rõ hơn về cách mà công nghệ này hoạt động và hỗ trợ các ứng dụng P2P như BitTorrent.