Nghiên cứu giải pháp mạng ngang hàng cho hệ thống truyền hình theo yêu cầu

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ
*





CAO LÊ MẠNH HÀ





NGHIÊN CỨU GIẢI PHÁP MẠNG NGANG HÀNG
CHO HỆ THỐNG TRUYỀN HÌNH THEO YÊU CẦU



LUẬN VĂN THẠC SĨ

Hà Nội - 2009
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ
*




CAO LÊ MẠNH HÀ




NGHIÊN CỨU GIẢI PHÁP MẠNG NGANG HÀNG
CHO HỆ THỐNG TRUYỀN HÌNH THEO YÊU CẦU




Ngành: Công nghệ Thông tin
Chuyên ngành: Truyền dữ liệu và mạng máy tính
Mã số: 60 48 15

LUẬN VĂN THẠC SĨ



NGƢỜI HƢỚNG DẪN KHOA HỌC: PGS.TS. Nguyễn Văn Tam









Hà Nội - 2009

1
MỤC LỤC

MỞ ĐẦU 7

CHƢƠNG 1 – TỔNG QUAN 9
1.1. Khái quát về truyền hình theo yêu cầu 9
1.2. Truyền hình theo yêu cầu dựa trên mô hình tập trung 12
1.2.1. Những hạn chế của mô hình tập trung 12
1.2.1.a. Cách tiếp cận dựa trên Unicast 12
1.2.1.b. Cách tiếp cận dựa trên Multicast 15
1.2.2. Một số hệ thống VoD hiện nay 18

1.3. Truyền hình theo yêu cầu dựa trên mạng ngang hàng 21
1.3.1. Khái quát về mạng ngang hàng 22
1.3.2. Phân loại mạng ngang hàng 24
1.3.2.a. Phân loại theo cấu trúc liên kết 24
1.3.2.b. Phân loại theo phương thức tìm kiếm 25
1.3.3. Mô hình VoD ngang hàng: những tiềm năng và thách thức 30
1.3.4. Giới thiệu một số hệ thống VoD ngang hàng 30
1.3.4.a. GnuStream 32
1.3.4.b. P2Cast 32
1.3.4.c. BiToS 34
1.4. Nhận xét - đánh giá 36

CHƢƠNG 2 – HỆ THỐNG GIẢI PHÁP PPVoD 39
2.1. Tổng quan hệ thống 39
2.1.1. Ý tưởng xây dựng 39
2.1.2. Các thành phần hệ thống 41
2.1.3. Hoạt động của hệ thống 42
2.2. Cơ chế quản lý chỉ mục 49
2.2.1. Tổ chức chỉ mục 49
2.2.2. Cập nhật chỉ mục 51
2.3. Phân phối và lƣu đệm dữ liệu 52
2.4. Tạo dòng truyền tải video streaming 53

2
2.4.1. Lựa chọn các peer cung cấp 53
2.4.2. Giải thuật lập lịch 55
2.4.3. Đánh giá độ phức tạp giải thuật 60
2.4.4. Thiết lập phiên streaming 60
2.5. Vấn đề bảo mật hệ thống 61

CHƢƠNG 3 - MÔ PHỎNG VÀ ĐÁNH GIÁ HIỆU NĂNG 65
3.1. Các tham số và kịch bản mô phỏng 65
3.2. Kết quả mô phỏng 67
3.2.1. Khả năng đáp ứng của hệ thống 67
3.2.2. Lưu lượng tải truy cập server 69
3.2.3. Tác động của băng thông video server 70
3.2.4. Mức độ cộng tác giữa các peer 71
3.2.5. Thời gian khởi tạo bộ đệm 72
3.2.6. Các kích thước mạng khác nhau 73

CHƢƠNG 4 – MỘT MÔ HÌNH ỨNG DỤNG CHO IPTV 74
4.1. Tình hình phát triển dịch vụ IPTV tại Việt Nam 74
4.2. Tổ chức hệ thống cung cấp dịch vụ VoD 76
4.3. Khả năng triển khai và ứng dụng 78

KẾT LUẬN 80

TÀI LIỆU THAM KHẢO 82

3

DANH MỤC CÁC TỪ VIẾT TẮT

 ALMT (Application Level Multicast Tree): Cây multicast tầng ứng dụng
 BGP (Border Gateway Protocol): Giao thức tìm đường nòng cốt trên Internet
 C/S (Client/Server): Mô hình Khách/Chủ
 CBR (Constant bit rate): Tốc độ bit không đổi
 CDN (Content Distribution Network): Mạng phân phối nội dung
 DHT (Distributed Hash Table): Bảng băm phân tán
 IPTV (Internet Protocol Television): Phương thức truyền hình qua mạng Internet

 ISP (Internet Service Provider): Nhà cung cấp dịch vụ Internet
 LRU (Least Recently Used): Chiến lược chọn thành phần ít được sử dụng nhất
trong bộ nhớ
 P2P (Peer-to-Peer): Mạng đồng đẳng, mạng ngang hàng
 RTT (Round Trip Time): Thời gian trễ trọn vòng (của gói tin/tín hiệu)
 STB (Set-top Box): Hộp chuyển đổi tín hiệu Tivi
 VoD (Video on Demand): Truyền hình/video theo yêu cầu




4
DANH MỤC HÌNH VẼ

Hình 1.1-1: Mô hình vật lý của một hệ thống VoD 10
Hình 1.1-2: Mô hình quảng bá tập trung 11
Hình 1.1-3: Mô hình quảng bá phi tập trung 11
Hình 1.2.1.a-1: Phân phối media theo cách tiếp cận Client/Server 13
Hình 1.2.1.a-2: Phân phối media theo cách tiếp cận dựa trên proxy 14
Hình 1.2.1.a-3: Phân phối media sử dụng mạng CDN 15
Hình 1.2.1.b-1: Kỹ thuật Batching sử dụng 3 kênh server, 16
bắt đầu sau từng đợt 20 phút. 16
Hình 1.2.1.b-2: Kỹ thuật Patching (unicast) 17
Hình 1.2.1.b-3: Phân phối media sử dụng kỹ thuật multicast tầng mạng 18
Hình 1.2.1.b-4: Phân phối media sử dụng kỹ thuật multicast tầng ứng dụng 18
Hình 1.2.2-1: Ảnh chụp màn hình CNN Pipeline 19
Hình 1.2.2-2: Ảnh chụp màn hình YouTube 20
Hình 1.2.2-3: Ảnh chụp màn hình Uitzending Gemist 21
Hình 1.3-1: Thống kê lưu lượng mạng toàn cầu của CacheLogic năm 2006 22
Hình 1.3.1-1: Kiến trúc Peer-to-Peer 23

Hình 1.3.2.a-1: Phân tán một video a) theo dây truyền, 25
b) theo dạng cây và c) theo swarm đối với 7 peer. 25
Hình 1.3.2.b-1: Phân loại các mô hình mạng ngang hàng 26
Hình 1.3.2.b-2: Tiến trình tìm kiếm và trao đổi dữ liệu trong mạng Naspter. 26
Hình 1.3.2.b-3: Tiến trình tìm kiếm và trao đổi dữ liệu trong mạng Gnutella. 27
Hình 1.3.2.b-4: Tiến trình tìm kiếm và trao đổi dữ liệu trong mạng KaZaa. 28
Hình 1.3.4.b-1: Giải thuật tiếp nhận Client của P2Cast 33
Hình 1.3.4.c-1: Cơ chế hoạt động của BiTos. 34
Hình 1.3.4.c-2: Cơ chế chọn mảnh của BiTos. 35
Hình 2.1.3-1: Minh họa kiến trúc hệ thống 42
Hình 2.1.3-2: Minh họa cơ chế trao đổi giữa Client và Web server. 43
Hình 2.1.3-3: Minh họa cơ chế trao đổi giữa Client và Tracker. 43
Hình 2.1.3-4: Minh họa cơ chế trao đổi giữa peer gửi yêu cầu và peer cung cấp. 44
Hình 2.1.3-5: Một ví dụ về cách thức kết hợp băng thông từ các peer cung cấp 45
Hình 2.1.3-6: Giải thuật thực hiện của hệ thống 48

5
Hình 2.2.2-1: Ví dụ minh họa cách thức tổ chức phân cụm 50
Hình 2.4.2-1: Các giải thuật Round Robin và Bandwidth Proportion 57
Hình 2.4.2-2: Giải thuật đề xuất 58
Hình 2.4.2-2: Minh họa việc gán 8 block cho 3 supplier sử dụng các giải thuật 59
Round Robin, Bandwidth Proportion và Estimate Time 59
Hình 2.5-1: Một peer bị tấn công chuyển tiếp nội dung ô nhiễm 62
cho các peer khác trong mạng 62
Hình 3.1.2-1: Các kiểu tần suất truy cập khác nhau đã được áp dụng 66
trong các mô phỏng 66
Hình 3.2.1-1: Kết quả mô phỏng khả năng đáp ứng của hệ thống 69
với các tần suất truy cập khác nhau. 69
Hình 3.2.2-1: Lưu lượng tải truy cập server ứng với 72
các tần suất truy cập khác nhau. 70

Hình 3.2.3-1: Tác động của băng thông server đối với hiệu năng của hệ thống. 71
Hình 3.2.4-1: Số lượng peer được phục vụ đồng thời trong hệ thống 71
ứng với các mức độ cộng tác khác nhau giữa các peer. 72
Hình 3.2.4-1: Lưu lượng tải truy cập server 72
ứng với các mức độ cộng tác khác nhau giữa các peer. 72
Hình 3.2.5-1: Thời gian khởi tạo bộ đệm ứng với các giải thuật RR, BP và ET 73
Hình 3.2.6-1: Khả năng phục vụ của hệ thống 73
ứng với các kích thước mạng khác nhau. 73
Hình 4.1-1: Ảnh chụp màn hình iTV, lấy từ địa chỉ www.iTV.vn 74
Hình 4.1-2: Tốc độ truyền dữ liệu IPTV và các công nghệ DSL 75
Hình 4.2-1: Cấu trúc giải pháp cung cấp dịch vụ VoD 77


6
DANH MỤC BẢNG BIỂU

Bảng 1-1: So sánh ưu, nhược điểm của các mô hình 29
Bảng 2-1: Các ký hiệu được sử dụng trong giải thuật 46

7
MỞ ĐẦU

Sự phổ biến của Internet băng thông rộng đã mở ra giai đoạn phát triển bùng nổ
của các ứng dụng truyền thông đa phương tiện (multimedia streaming). Sức hấp dẫn
của các ứng dụng này (đặc biệt là trong lĩnh vực giải trí) đã khiến cho số lượng người
dùng tăng lên nhanh chóng. Tuy nhiên, theo xu thế phát triển thì không chỉ có số lượng
người dùng ngày càng nhiều mà nhu cầu về chất lượng cũng ngày càng cao đòi hỏi
băng thông phục vụ của các hệ thống ngày càng lớn. Với cách tiếp cận của hầu hết các
hệ thống hiện nay đều dựa trên mô hình Client/Server (sử dụng một vài server lưu trữ
dữ liệu phục vụ cho tất cả các client) thì với đặc điểm tiêu tốn băng thông của các ứng

dụng multimedia streaming đã khiến cho các server luôn có nguy cơ bị quá tải. Đặc
biệt là các hệ thống truyền hình theo yêu cầu (Video on demand - VoD), có số lượng
người xem rất lớn, lượng chương trình phong phú, tiêu tốn lượng lớn băng thông mạng
và cần nhiều dung lượng lưu trữ. Nhận thấy hạn chế này, giải pháp quảng bá video dựa
trên IP multicast đã được đề xuất. Mặc dù xuất hiện từ những năm 90 và đã tốn kém
rất nhiều nỗ lực đầu tư - nghiên cứu nhưng đến nay do sự triển khai không đồng đều
của các nhà cung cấp dịch vụ khác nhau đã khiến cho công nghệ multicast không được
phổ biến. Để đạt được hiệu năng mong muốn, nhiều công ty lớn đã phải chấp nhận các
giải pháp như proxy-base hoặc mạng phân phối nội dung CDN có chi phí thuê bao rất
tốn kém. Nhưng khi số lượng người dùng ngày càng tăng dẫn đến chi phí cho hệ thống
ngày càng nhiều lại là một sự cản trở cho các mục tiêu thương mại. Việc xây dựng một
hệ thống VoD đạt được hiệu quả trên quy mô nhưng tiết kiệm về mặt chi phí vẫn là
điều mà các nhà cung cấp dịch vụ truyền hình qua mạng hiện nay đang hướng tới.
Tuy mới nổi lên trong những năm gần đây nhưng công nghệ mạng ngang hàng
Peer-to-Peer (P2P) đã thu hút được rất nhiều sự quan tâm chú ý. Nhờ việc cho phép
các peer phục vụ lẫn nhau và tận dụng hiệu quả các tài nguyên dư thừa của hệ thống
nên giải pháp P2P đã khắc phục được những hạn chế của kiến trúc Client/Server. Công
nghệ này không chỉ cho phép hệ thống đáp ứng được lượng lớn truy cập tăng đột biến
mà còn có khả năng mở rộng quy mô (scalability). Hơn nữa giải pháp P2P không cần
đến bất kỳ một yêu cầu đặc biệt nào về phần cứng mạng nên rất dễ triển khai. Những
đầu tư và nghiên cứu cho Peer-to-Peer ngày một nhiều đã dẫn đến kết quả là các ứng
dụng P2P ngày càng phổ biến, trong số đó có thể kể ra các ứng dụng chia sẻ file
(BitTorrent, uTorrent, eMule), các ứng dụng hội thoại qua mạng VoIP (Skype)….
Mặc dù vậy, cho đến nay việc xây dựng các ứng dụng quảng bá video dựa trên mạng
ngang hàng như video on-demand vẫn còn đang gặp nhiều khó khăn - thách thức. Khó
khăn chủ yếu xuất phát từ những nhược điểm của mạng ngang hàng như mức độ tham
gia đóng góp tài nguyên của các peer không đồng đều, các peer có thể tham gia hoặc
ngắt kết nối khỏi hệ thống vào thời điểm bất kỳ Trong khi đó ứng dụng VoD lại là
loại ứng dụng yêu cầu hiệu năng thời gian thực và băng thông lớn. Điều này đã khiến
cho việc xây dựng các ứng dụng VoD dựa trên mạng ngang hàng trở nên phức tạp hơn

8
hẳn so với mô hình Client/Server. Mặt khác hầu hết các ứng dụng ngang hàng hiện nay
đều là các ứng dụng miễn phí, còn VoD vốn là một loại hình dịch vụ chủ yếu được
cung cấp bởi các công ty truyền thông hoặc các nhà cung cấp dịch vụ. Việc chuyển đổi
hệ thống sang kiến trúc phân tán Peer-to-Peer mà vẫn duy trì được phương thức quản
lý dịch vụ như kiến trúc tập trung Client/Server là điều không đơn giản. Mục đích của
luận văn “Nghiên cứu giải pháp mạng ngang hàng cho hệ thống truyền hình theo yêu
cầu” là nhằm đưa ra một giải pháp cho vấn đề kể trên.
Ý tưởng chính của giải pháp trong luận văn là xây dựng hệ thống video on
demand dựa trên kiến trúc mạng ngang hàng lai ghép, nhằm kết hợp những ưu điểm
của cả kiến trúc ngang hàng thuần túy và Client/Server. Trong đó server vẫn duy trì
các chức năng quản lý, còn mạng ngang hàng được sử dụng để giảm tải cho server.
Với đặc điểm mang tính phức tạp của bài toán xây dựng hệ thống có nhiều khía
cạnh cần phải xét đến, trong khuôn khổ luận văn của mình, tác giả tập trung vào bốn
nội dung chính:
1 - Xây dựng một cơ chế quản lý chỉ mục nhằm quản lý dữ liệu phân tán và hỗ trợ
các peer tìm kiếm và chia sẻ tài nguyên.
2 - Nghiên cứu cơ chế lưu đệm (caching) để giúp cho việc tìm kiếm và download
của các peer được thuận tiện và tối ưu.
3 - Với đặc tính biến động (dynamic) và hỗn tạp (heterogeneous) của mạng ngang
hàng. Tác giả xây dựng giải thuật lập lịch nhằm kết hợp băng thông từ nhiều peer cung
cấp phục vụ cho một yêu cầu streaming và đảm bảo chất lượng dịch vụ (playback
quality) cho các client.
4 - Thông qua tìm hiểu về vấn đề bảo mật, tác giả đã đánh giá và lựa chọn giải
pháp bảo mật thích hợp cho hệ thống để đối phó với hình thức tấn công ô nhiễm
(pollution attack) là hình thức tấn công đặc trưng đối với các hệ thống media
streaming dựa trên mạng ngang hàng.

 Luận văn có cấu trúc như sau:

Luận văn bao gồm năm chương, Chương 1 tìm hiểu và đánh giá những hạn chế
của các cách tiếp cận dựa trên mô hình tập trung Client/Server, sau đó là tổng quan về
mạng ngang hàng và giới thiệu một số hệ thống VoD dựa trên mạng ngang hàng. Nội
dung Chương 2 tập trung mô tả hệ thống giải pháp PPVoD, phần đầu là tổng quan về
hệ thống, tiếp theo đề cập đến cơ chế quản lý chỉ mục cũng như phương thức lưu đệm
và tìm kiếm các phân đoạn video. Trong chương này tác giả cũng đã đề xuất một giải
thuật lập lịch media streaming, phần cuối chương đề cập đến vấn đề bảo mật cho hệ
thống. Chương 3 trình bày các mô phỏng thử nghiệm đánh giá hiệu năng của hệ thống
PPVoD. Chương 4 đề cập đến một mô hình ứng dụng cho IPTV. Cuối cùng, Chương 5
là kết luận và các định hướng phát triển của đề tài trong tương lai.

9
CHƢƠNG 1 – TỔNG QUAN

1.1. Khái quát về truyền hình theo yêu cầu
Truyền hình theo yêu cầu (Video on demand / VoD) là hệ thống cho phép người
dùng lựa chọn để xem nội dung video theo yêu cầu.
Đây là một công nghệ truyền hình tương tác cho phép những người xem (các thuê
bao) có thể xem trực tiếp hoặc thu lại các chương trình để xem về sau. Một hệ thống
VoD truyền thống, dưới góc độ người dùng có thể bao gồm một TiVi và một hộp
chuyển đổi tín hiệu STB (set-top box). Bên cạnh đó, dịch vụ này còn có thể được cung
cấp qua mạng Internet cho các máy tính gia đình, máy tính xách tay, các dòng điện
thoại cao cấp và các thiết bị giải trí số.
Người dùng có quyền lựa chọn xem video (từ những video clip về tin tức, thể thao,
giải trí trên Internet cho đến các bộ phim đầy đủ có độ nét cao) từ các nhà cung cấp
dịch vụ Internet (ISP) hoặc các công ty truyền hình cáp, trong khi vẫn đang ngồi ở nhà
và có toàn quyền điều khiển việc xem video giống như việc sử dụng một đầu DVD
thông thường, bao gồm các chức năng phát hình (play), tạm dừng (pause), tua nhanh
(fast forward), tua lại (rewind), nhảy qua khung hình trước/sau (skip) .
Phần lớn các dịch vụ video on-demand đều có từ hàng trăm đến hàng nghìn bộ

phim, từ cũ đến mới. Ngoài ra còn có thể có các chương trình TV cho phép người
dùng có thể download về để xem. Thậm chí một vài nhà cung cấp dịch vụ còn lưu toàn
bộ các chương trình TV trong suốt hàng tháng để người dùng có thể xem lại trong một
khoảng thời gian về sau.
Để cung cấp đủ băng thông cho các dịch vụ truyền hình qua mạng, các nhà cung
cấp dịch vụ phải sử dụng các đường truyền xDSL tốc độ cao hoặc các mạng truyền
hình cáp để phân phối nội dung video tới người xem. Ví dụ như công ty AT&T
LightSpeed của Mỹ cũng đã sử dụng các mạng Fiber-to-the-Neighborhood (FTTN).
Kiến trúc của mạng gồm một vài siêu đầu cuối (Super Head End - SHE) quốc gia và
lượng lớn các tổng đài phân phối video địa phương (Video Hub Office - VHO). Các
siêu đầu cuối SHE đóng vai trò là các điểm tập trung cung cấp nội dung video quảng
bá và on-demand trên phạm vi quốc gia. Mỗi tổng đài tập trung VHO đảm nhận phục
vụ một thư viện lớn các video theo yêu cầu và phân phối nội dung thông qua các bộ
chuyển đổi truy cập địa phương (local access switch) tới các khách hàng.
Có hai kiểu hệ thống video on demand bao gồm: streaming video on demand và
download video on demand. Hệ thống streaming VoD cho phép xem phim gần như
trực tiếp. Trong khi đó với hệ thống download VoD bộ phim phải được tải xuống toàn
bộ trước khi có thể bắt đầu xem. Nội dung của luận văn sẽ tập trung chủ yếu vào vấn
đề streaming video on demand.


10

Hình 1.1-1: Mô hình vật lý của một hệ thống VoD

Liên quan đến khái niệm video on-demand còn có các thuật ngữ như live
streaming, progressive download cũng thường gặp trong nhiều tài liệu khác nhau.
Chúng ta phân biệt các thuật ngữ đó như sau:
- Real-time/live streaming: xem video trực tiếp. Có nghĩa là khi những client gửi
yêu cầu xem một video (sau khi đã bắt đầu phát) thì sẽ được xem video từ thời điểm

hiện tại đang phát chứ không phải là từ thời điểm bắt đầu của video.
- Progressive download/video on-demand: xem video từ đầu. Người xem có thể
xem video lựa chọn vào thời gian lựa chọn thích hợp.
Sự phân biệt giữa hình thức live streaming và on-demand streaming đôi khi bị lu
mờ bởi một số phần mềm trên phía client có thể lưu lại một dòng video thời gian thực
và phát lại khi cần thiết. Tuy nhiên đây vẫn được xem là streaming trực tiếp.
Một số thuật ngữ liên quan đến khái niệm bit rate của video cần phải quan tâm bao
gồm:
- Tốc độ bit phát lại (Playback bit rate): Số bit đã được sử dụng mỗi giây cho việc
trình diễn audio và video sau khi đã được mã hóa (nén dữ liệu).
- Tốc độ bit không đổi (Constant bit rate): Video có tốc độ bit không đổi sử dụng cùng
tổng số bit mỗi giây vào mọi thời điểm phát hình.
- Tốc độ bit thay đổi (Variable bit rate): Với video có tốc độ bit thay đổi, tổng số bit
trong mỗi giây có thể khác nhau. Kỹ thuật này cho phép sử dụng nhiều bit mỗi giây
cho các đoạn video hoặc audio phức tạp và ít hơn cho các đoạn video hoặc audio đơn
giản.
Dựa trên công nghệ quảng bá được sử dụng có thể phân chia truyền hình theo yêu
cầu theo hai loại:
- Tập trung hóa (Centralized): Có một server đơn (hoặc một nhóm server) gửi video
cho tất cả các client.

11
- Phi tập trung (Non-centralized): Không có sự phân biệt giữa client và server, các
client chủ động tham gia vào việc gửi video cho các client khác.
Trong cách tiếp cận dựa trên phương thức quảng bá tập trung, server chịu trách
nhiệm lưu trữ, truy xuất và truyền dữ liệu. Mặt khác client chịu trách nhiệm giải mã và
phát hình. Phần còn lại của ứng dụng logic có thể đặt trên client, server hoặc được chia
ra cho cả hai.

Hình 1.1-2: Mô hình quảng bá tập trung

Cách tiếp cận dựa trên phương thức quảng bá phi tập trung sử dụng những giải
pháp dựa trên các mạng ngang hàng (Peer-to-Peer). Đặc điểm của các mạng ngang
hàng là cho phép các peer (đồng đẳng) cộng tác với nhau mà không cần tới một thành
phần trung tâm.
Cũng có cách tiếp cận khác là sự kết hợp của các hệ thống kể trên, hệ thống có
server nhưng vẫn sử dụng các client để làm giảm băng thông yêu cầu đối với server.
Những hệ thống này được gọi là hệ thống lai ghép.

Hình 1.1-3: Mô hình quảng bá phi tập trung

12
1.2. Truyền hình theo yêu cầu dựa trên mô hình tập trung
1.2.1. Những hạn chế của mô hình tập trung
Dựa theo phương thức phân phối dữ liệu, cách tiếp cận theo mô hình tập trung có
thể phân thành hai loại: đơn phát (unicast-base) và đa phát (multicast-base). Những
phân tích dưới đây sẽ làm rõ hơn ý tưởng chính và hạn chế của các cách tiếp cận này.

1.2.1.a. Cách tiếp cận dựa trên Unicast
Trong cách tiếp cận dựa trên unicast một unicast stream được thiết lập cho mỗi
client. Cụ thể là có ba cách tiếp cận sử dụng kết nối unicast cho streaming theo yêu
cầu: tập trung (Centralized), ủy nhiệm (Proxy) và mạng phân phối nội dung (Content
Distribution Networks - CDN).
Tập trung (Centralized). Cách tiếp cận tập trung theo mô hình Client/Server sử
dụng một hoặc nhiều server có cấu hình mạnh, băng thông rộng và bộ nhớ lưu trữ lớn
để phục vụ cho các yêu cầu streaming. Cách tiếp cận này có ưu điểm là dễ triển khai
và quản lý. Tuy nhiên với các ứng dụng đòi hỏi băng thông cao như VoD thì hệ thống
như vậy có thể gặp khó khăn để đạt được thông lượng truyền tải mong muốn. Do
những hạn chế của phương thức phân phối dữ liệu trong hệ thống mạng, bất chấp việc
có sử dụng UDP, TCP hay các giao thức truyền tải nào khác thì VoD server vẫn phải

truyền thông với các client một cách độc lập. Bởi vì các client gửi những yêu cầu cho
những phân đoạn khác nhau của cùng video và thậm chí ngay cả khi có nhiều client
yêu cầu cùng một phân đoạn của video thì có thể lại là tại các thời điểm khác nhau của
nội dung video. Điều này buộc server phải lặp đi lặp lại việc truyền tải cùng một nội
dung dữ liệu giống như truyền các luồng dữ liệu độc lập cho mỗi client, khiến cho hệ
thống bị hạn chế về khả năng mở rộng (scalability). Mặt khác, khi có càng nhiều người
truy cập đồng thời thì chất lượng dịch vụ lại càng giảm do hạn chế về tài nguyên của
server. Còn khi server bị sự cố (single point of failure) thì sẽ dẫn đến ngưng hoạt động
toàn hệ thống. Không những thế, xuất phát từ những hạn chế của cách tiếp cận dựa
trên mô hình tập trung còn làm nảy sinh hai vấn đề khác đó là: chi phí cao và tải nặng
trên đường backbone mạng.
- Chi phí cao xuất phát từ yêu cầu về băng thông và bộ nhớ lưu trữ. Để đánh giá
vấn đề chi phí, hãy xem xét ví dụ: một hệ thống để đạt được khả năng phục vụ 1000
người xem đồng thời, với chất lượng hình ảnh tương đương TV thì cần phải mã hóa
video theo chuẩn MPEG-4 ở bitrate là 1.5Mbps, đòi hỏi dung lượng hệ thống phải đạt
cỡ 1.5Gbps. Để đạt được dung lượng như vậy thì chi phí thuê bao đường truyền cho hệ
thống là khá lớn. Mặt khác, nếu trong hệ thống duy trì một thư viện bao gồm 1000
video (được mã hóa theo chuẩn MPEG-4), với độ dài chừng 2 giờ thì mỗi video cũng
đã có dung lượng xấp xỉ 1.4GB. Dẫn đến dung lượng lưu trữ cần thiết để lưu toàn bộ
các video là vào khoảng 1.4Terabyte. Không những thế, để đáp ứng nhu cầu của người
xem thì theo thời gian số lượng video phải đưa vào hệ thống ngày càng nhiều. Cho dù

13
có sử dụng một hoặc nhiều server để giảm tải thì chi phí triển khai và duy trì hệ thống
cũng rất tốn kém.
- Vấn đề tải nặng trên đường backbone mạng xuất hiện khi có số lượng lớn client
truy cập vào server đồng thời, do phần lớn lưu lượng truyền tải đều phải đi qua mạng
diện rộng WAN. Việc dữ liệu phải truyền qua nhiều chặng (hop) trong mạng cũng dễ
làm xuất hiện khả năng biến thiên độ trễ và tỉ lệ mất mát gói tin cao hơn do hiện tượng
nghẽn mạng có thể xuất hiện bất kỳ lúc nào.

Hình 1.2.1.a-1: Phân phối media theo cách tiếp cận Client/Server

Ủy nhiệm (Proxy). Trong cách tiếp cận dựa trên proxy, các proxy server được đặt
ở gần khu vực có các máy khách (client domain). Đối với những video có kích thước
lớn, proxy có thể lưu đệm (cache) một vài file video nguyên vẹn. Một số kỹ thuật
caching đã được đề xuất cho phép proxy lưu đệm một phần của file video và do đó có
nhiều video được lưu đệm đồng thời. Trong kỹ thuật lưu đệm phần đầu (prefix
caching) [25], proxy lưu một vài khung hình đầu tiên của video để làm giảm thời gian
chờ (startup delay). Trong kỹ thuật lưu đoạn (staging caching) [30], proxy sẽ lưu lại
những phần có tần suất truy cập lớn (bursty portions) và để lại các phần có tần suất
truy cập thấp hơn (smoother) cho server trung tâm. Điều này giúp làm giảm bớt những
yêu cầu ngặt nghèo về băng thông trên các đường truyền mạng WAN. Một tập các
khung hình không liên tục cũng có thể được chọn ra để lưu đệm nhằm thuận tiện cho
các chức năng điều khiển như tua nhanh và tua ngược. Cách tiếp cận proxy và các biến
thể của nó đã giúp tiết kiệm băng thông, giảm thời gian chờ và có biến thiên độ trễ nhỏ.
Mặt hạn chế của cách tiếp cận này là đòi hỏi phải triển khai và quản lý các proxy ở
nhiều địa điểm khác nhau. Việc triển khai các proxy giúp làm tăng năng lực tổng thể
của hệ thống nhưng cũng làm tăng chi phí lên gấp nhiều lần. Mặc dù năng lực của hệ

14
thống được tăng lên nhưng vẫn bị giới hạn bởi sự kết hợp tài nguyên giữa các proxy.
Điều này chỉ giúp chuyển hiện tượng ngẽn cổ chai (bottleneck) từ một điểm trung tâm
sang một vài điểm phân tán chứ không loại bỏ được hoàn toàn.


Hình 1.2.1.a-2: Phân phối media theo cách tiếp cận dựa trên proxy

Mạng phân phối nội dung (Content Distribution Network). Một cách tiếp cận khác

dựa trên unicast là thuê các bên thứ ba (third-party) cung cấp nội dung cho các khách
hàng. Bên thứ ba này là một Mạng phân phối nội dung (Content Delivery Network -
CDN). Các CDN của Akamai và Digital Island được triển khai hàng nghìn máy chủ ở
vùng biên (edge) của Internet. Ví dụ Akamai đã triển khai hơn 10,000 server (Yahoo
hiện nay cũng đang sử dụng mạng của Akamai). Những server này (còn được gọi là
các bộ đệm lưu trữ) đã được cài đặt ở nhiều POP (point of presence) của các nhà cung
cấp dịch vụ Internet (ISP) cỡ lớn (như AT&T và Sprint). Ý tưởng ở đây là đặt nội
dung gần với các client và như vậy dữ liệu sẽ phải truyền qua ít chặng hơn. Mạng
CDN lưu đệm nội dung ở nhiều server và định hướng cho mỗi client truy cập vào
server thích hợp nhất. Hiệu quả về chi phí là vấn đề mấu chốt trong cách tiếp cận này,
đặc biệt là đối với việc phân phối các file lớn như các bộ phim: người điều hành mạng
CDN có thể tính giá cho nhà cung cấp nội dung theo mỗi MB phục vụ. Chi phí phân
phối có thể là chấp nhận được đối với các trang Web tương đối nhỏ như chỉ có các văn
bản với một vài bức ảnh. Tuy nhiên, chi phí này là đáng kể đối với dịch vụ media
streaming bởi vì các file media nhìn chung đều có kích thước lớn.



15

Hình 1.2.1.a-3: Phân phối media sử dụng mạng CDN

1.2.1.b. Cách tiếp cận dựa trên Multicast
Các cách tiếp cận dựa trên multicast đạt được sự tận dụng tài nguyên tối ưu hơn
nhờ việc phục vụ nhiều client trong cùng một stream. Ý tưởng cơ bản là thiết lập một
phiên kết nối multicast đối với các client đã đăng ký. Việc này được thực hiện bằng
cách tạo ra các cây phân phối multicast (Multicast distribution tree). Các cách tiếp cận
dựa trên multicast thực tế phù hợp hơn với hình thức streaming trực tiếp (live
streaming) trong đó các client đã được đồng bộ hóa, nghĩa là tất cả các client nhận
được cùng những phần của stream tại cùng thời điểm. Để khắc phục đặc tính không

đồng bộ của dịch vụ streaming theo yêu cầu, đã có nhiều ý tưởng được đề xuất. Những
ý tưởng chính bao gồm các kỹ thuật batching và patching.

 Batching (xử lý theo đợt)
Đã có một vài giao thức batching nhưng giao thức phát quảng bá so le (staggered
broadcasting) là dạng đơn giản nhất. Giả sử có K kênh server phát quảng bá ở tốc độ
tương đương tốc độ phát hình (giả sử rằng đây là tốc độ phát không đổi CBR). Mỗi
kênh phát quảng bá toàn bộ video và bắt đầu phát vào các thời điểm so le đều nhau
giữa các kênh. Khi đó thời gian chờ lớn nhất của client đối với một video có độ dài S
là S/K.
Nếu một chương trình TV dài 60 phút được phân thành các đợt 20 phút, thì server
sẽ nhóm các client lại như sau:




16

Hình 1.2.1.b-1: Kỹ thuật Batching sử dụng 3 kênh server,
bắt đầu sau từng đợt 20 phút.

Trong ví dụ này, mỗi khi có một client gửi yêu cầu cho server thì server sẽ ghi
nhận lại các yêu cầu này. Nếu có một client gửi yêu cầu vào lúc 7giờ 15 phút thì nó sẽ
phải đợi đến 7 giờ 20 phút trước khi server bắt đầu streaming đến tất cả các client đã
gửi yêu cầu trong suốt 20 phút vừa qua. Một client gửi yêu cầu chậm hơn thời điểm
batching một chút cũng sẽ phải đợi cả 20 phút, còn nếu sớm hơn thì hầu như không
phải đợi.
Một số giao thức batching khác được mô tả chi tiết trong tài liệu [1]. Những giao
thức batching này giảm thời gian chờ của client bằng cách phân biệt giữa các phần
khác nhau của video. Các phân đoạn đầu của video được phát quảng bá thường xuyên

hơn các phân đoạn sau. Thực hiện việc này bằng cách phát quảng bá các phân đoạn
đầu ở tốc độ truyền cao hơn hoặc làm cho các phân đoạn đầu ngắn hơn các phân đoạn
sau. Đối với các giao thức này, để xem được video thì client phải download từ nhiều
kênh server đồng thời. Do đó băng thông của client và bộ nhớ lưu trữ cần thiết phải
cao hơn so với giao thức phát quảng bá so le.

 Patching
Hạn chế của kỹ thuật batching là không thể hỗ trợ dịch vụ VoD thật sự, bắt buộc
client luôn phải đợi một khoảng thời gian nào đó. Để batching cho VoD thật thì có thể
áp dụng kỹ thuật patching.
Giả sử sau khi đã bắt đầu chương trình TV thì có một client tham gia muộn vào
broadcast stream. Tuy nhiên client vẫn cần đến phần của video từ lúc bắt đầu của
broadcast stream cho đến lúc bắt đầu tham gia. Lúc này client sẽ phải thiết lập một kết
nối unicast với server để "vá lại" (patching) nghĩa là lấy các phần còn thiếu của file.
Có hai stream cùng truyền đến client ở tốc độ phát hình đầy đủ: patch stream và batch
:00
:20
:40
(:40, :00]
(:00, :20]
(:20, :40]
Client tham gia
phiên trong
khoảng thời gian:
Thời điểm bắt đầu
chương trình TV
(kéo dài trong 60')

17
stream. Patch stream chỉ kết thúc khi nào client nhận được đầy đủ phần còn thiếu. Kỹ

thuật patching đòi hỏi client phải nhận đồng thời nhiều stream trong thời gian patching.
Điều này có nghĩa là client phải có băng thông vào (inbound bandwidth) ở mức tối
thiểu là gấp đôi streaming rate. Đây là một đòi hỏi khá ngặt nghèo đối với các peer có
băng thông hạn chế trong môi trường mạng hiện nay.


Hình 1.2.1.b-2: Kỹ thuật Patching (unicast)

- Các cây phân phối đa phát (multicast distribution trees) được tạo ở tầng mạng
(network-level) hoặc ở tầng ứng dụng (application-level). Cây multicast tầng mạng
được tạo ra dựa trên các router nội tại trong đó các client được coi là các nút lá của cây.
Multicast tầng mạng tuy hiệu quả nhưng không được triển khai rộng rãi. Do đó hiện
nay multicast tầng mạng không phải là giải pháp khả thi cho việc phân tán nội dung
đến tất cả các client.
- Các kỹ thuật multicast tầng ứng dụng (có trong các mạng NICE, Narada, Zigzag
…) xây dựng một cây phân tán dựa trên các hệ thống cuối. Các giải thuật sử dụng để
xây dựng cây phân tán trong các hệ thống này cũng rất khác nhau. Việc xây dựng cây
phân tán dựa trên các hệ thống cuối là điều hoàn toàn có thể triển khai trên Internet
hiện nay. Tuy nhiên cũng có vấn đề khác nảy sinh, đó là nó có thể làm quá tải một số
hệ thống cuối do năng lực hạn chế của những hệ thống này. Một hệ thống cuối trên
một cây có thể trở thành cha của nhiều hệ thống cuối khác. Ví dụ, trong hình 1.2.1.b-4,
client P1 là cha của các client P2 và P3. Do đó, P1 có thể cung cấp stream cho cả hai
với giả sử rằng P1 có thể hỗ trợ gấp nhiều lần tốc độ streaming. Tuy nhiên trong môi
trường mạng thực, các nút mạng nhìn chung đều có năng lực hạn chế, đặc biệt là băng
thông tải lên (upstream bandwidth). Trong nhiều trường hợp, có những nút mạng thậm
chí không thể cung cấp stream rate đầy đủ cho các nút khác.
Patch
Join
Các tiến trình gửi phân đoạn đầu
và phân đoạn còn lại của video

Tx +1
Tx

18

Hình 1.2.1.b-3: Phân phối media sử dụng kỹ thuật multicast tầng mạng


Hình 1.2.1.b-4: Phân phối media sử dụng kỹ thuật multicast tầng ứng dụng

1.2.2. Một số hệ thống VoD hiện nay
Hiện tại đã có khá nhiều các hệ thống dịch vụ VoD qua mạng Internet và ngày
càng có thêm nhiều hệ thống được phát triển. Phần dưới đây giới thiệu một vài hệ
thống lớn hiện nay, bao gồm CNN Pipeline, YouTube và Uitzending gemist. Tất cả
các hệ thống này đều là hệ thống tập trung.


19
CNN Pipeline
CNN Pipeline [6] là một dịch vụ tin tức video, cung cấp cả dịch vụ truyền hình
theo yêu cầu và truyền hình trực tuyến cho các thuê bao sử dụng máy tính kết nối
Internet băng thông rộng. Người dùng dịch vụ phải đăng ký và trả phí thuê bao tháng
2.95$. Với khoản phí này họ có thể xem hơn 5.000 video theo yêu cầu và bốn kênh
truyền hình trực tiếp. Tuy nhiên dịch vụ chỉ hạn chế ở 43 đất nước trên thế giới. Băng
thông, bộ nhớ lưu trữ và các máy chủ streaming của CNN Pipeline được cung cấp bởi
AOL (thuộc về Time Warner Company) [26]. Mặc dù AOL là một nhà cung cấp dịch
vụ Internet cỡ lớn nhưng đôi khi chất lượng dịch vụ nhận được cũng kém. Thêm vào
đó chất lượng video còn dưới cả chất lượng tiêu chuẩn Tivi [5].
Một trong các lý do khiến cho chất lượng dịch vụ nhận được còn nghèo nàn có thể
vì mặc dù CNN Pipeline là một dịch vụ trả tiền nhưng lại cho phép mọi người truy cập

các kênh streaming trực tiếp (có 4 kênh trực tiếp tương ứng với 4 pipeline). Vấn đề
này còn có thể tăng lên cùng với số lượng người truy cập đồng thời.


Hình 1.2.2-1: Ảnh chụp màn hình CNN Pipeline, lấy từ địa chỉ


YouTube
YouTube là một dịch vụ chia sẻ video miễn phí khá phổ biến hiện nay. Dịch vụ
này cho phép người dùng có thể xem, upload và chia sẻ các video clip bao gồm các
movie clip, TV clip và music video cũng như các video nghiệp dư như videoblogging
và các phim ngắn. Những người dùng không đăng ký dịch vụ vẫn được xem phần lớn
các video, trong khi những người đã đăng ký được quyền upload các video không hạn
chế về số lượng.

20
YouTube sử dụng định dạng Flash Video (flv) của Adobe, mã hóa video với tốc
độ bit thay đổi. Bit rate tổng cộng của audio và video trung bình vào khoảng 300Kbps
(kilobit per second). Audio được lấy mẫu mono (mp3) ở tần số 22.050Hz và độ phân
giải video là 320x240 pixels. Chất lượng dịch vụ vì thế cũng không cao lắm.
Có rất ít các thống kê về số lượng video của Youtube được công bố rộng rãi. Tuy
nhiên, vào tháng 8/2006, tạp chí Wall Street đã tiết lộ thông tin cho biết YouTube hiện
đang nắm giữ khoảng 6.1 triệu video (tiêu tốn 45 Terabyte ổ cứng) với hơn 100 triệu
lượt truy cập mỗi ngày và đã có gần 2.5 tỉ truy cập trong tháng 6/2006. Trung bình mỗi
ngày có khoảng 50,000 video được đưa lên trong tháng 5/2006 và trong tháng 7 con số
này là 65,000 video. Ước tính năm 2007, YouTube đã tiêu thụ lượng băng thông bằng
tổng băng thông của toàn bộ mạng Internet trong năm 2000. Chỉ tính riêng trong tháng
1/2008, đã có gần 79 triệu người xem với trên 3 tỉ truy cập. Chi phí băng thông
YouTube phải trả trong tháng 3/2008 ước tính từ 1-2 triệu đôla mỗi ngày.
Bị Google mua lại vào năm 2006, YouTube đã phải quảng cáo dưới dạng Google

AdSense (quảng cáo theo ngữ cảnh). Các quảng cáo xuất hiện khi đang xem video và
liên quan đến nội dung của trang. Vào thời điểm đầu năm 2008, đơn giá cho một
quảng cáo đặt trên trang chủ YouTube là 175,000 đôla mỗi ngày, các AdSense ở các
trang bên trong có giá 50,000 đôla. Với lượng truy cập như vậy thì tiềm năng từ doanh
thu quảng cáo của YouTube là hết sức to lớn. Tuy nhiên phần chi phí băng thông và
đầu tư cho hệ thống cũng đã ảnh hưởng không nhỏ tới lợi nhuận của công ty. Con số
chính xác về lợi nhuận của YouTube trong năm 2007 không được công bố, còn trong
quí 1 năm 2008 YouTube đã không có lợi nhuận.


Hình 1.2.2-2: Ảnh chụp màn hình YouTube, lấy từ địa chỉ


21

Uitzending gemist
Uitzending Gemist là một dịch vụ miễn phí được cung cấp bởi Dutch Public
Broadcasters. Lợi nhuận thu được từ việc chèn các quảng cáo vào video. Bởi vì
Uitzending Gemist có ít lượng người truy cập đồng thời hơn so với YouTube và CNN
Pipeline cho nên băng thông yêu cầu cũng không cao đến như vậy. Tuy nhiên, khi
ngày càng có nhiều người sử dụng dịch vụ này thì những chi phí đầu tư tốn kém cho
băng thông và máy chủ có thể sẽ là sự cản trở đối với mô hình thương mại hiện tại.


Hình 1.2.2-3: Ảnh chụp màn hình Uitzending Gemist, lấy từ địa chỉ


1.3. Truyền hình theo yêu cầu dựa trên mạng ngang hàng
Theo thống kê của tổ chức CacheLogic vào tháng 6 năm 2004, phần lớn lưu thông
trên mạng Internet thuộc về các ứng dụng ngang hàng (chiếm 62%) và khoảng 2/3 số

file trao đổi qua mạng ngang hàng là file video. Cụ thể là các file video chiếm đến
61,4% tổng số file chia sẻ. Những thống kê không chính thức gần đây còn cho biết,
trong năm 2006 các ứng dụng chia sẻ ngang hàng đã chiếm tới 71% lưu thông Internet.
Trong đó các ứng dụng chia sẻ file BitTorrent và eDonkey giữ vị trí dẫn đầu. Như vậy
có thể dự đoán rằng các dịch vụ mạng ngang hàng và truyền tải video sẽ còn giữ xu thế
thống trị lưu lượng mạng toàn cầu trong nhiều năm tới.

22

Hình 1.3-1: Thống kê lưu lượng mạng toàn cầu của CacheLogic năm 2006,
lấy từ

1.3.1. Khái quát về mạng ngang hàng
Kể từ sau thành công của Napster [19], công nghệ mạng ngang hàng (Peer-to-
Peer) đã nhận được sự quan tâm, chú ý sâu sắc. Mạng ngang hàng ngày càng phát triển
và trở thành công nghệ quan trọng trong nhiều lĩnh vực như tính toán cộng tác và phân
tán cả trên Web và các mạng ad-hoc. Đã có nhiều nỗ lực công nghiệp cho công nghệ
P2P, trong đó có nhóm P2P Working Group do sự chỉ đạo của nhiều đối tác công
nghiệp như Intel, Sun, HP và một vài công ty mới nổi (ngôn ngữ lập trình mã nguồn
mở JXTA cũng là một nỗ lực của Sun). Mặc dù cũng đã có những nghiên cứu hàn lâm
dành cho công nghệ P2P. Tuy nhiên nền tảng của ý tưởng tổ chức các máy tính thành
các đồng đẳng (peer) không phải là mới. Thực ra ban đầu Internet đã được thiết kế
theo phương thức ngang hàng. Các ứng dụng Internet đầu tiên như email, Usenet news
và Telnet có thể được xếp vào nhóm các ứng dụng ngang hàng. Cách thức tổ chức này
khuyến khích việc chia sẻ thông tin trong nghiên cứu và phát triển các lĩnh khoa học,
quân sự bằng cách cho phép gửi các gói dữ liệu giữa hai máy tính bất kỳ. Vì thế mà
mô hình tính toán ngang hàng hiện nay, kể từ lần xuất hiện đầu tiên của Napster vào
tháng 5 năm 1999, có thể được xem như là "một sự phục hưng của mô hình Internet sơ
khai" [15]. Theo Ian Clarke (một sáng lập viên của mạng FreeNet): "P2P là bước tiến
hoá hoàn toàn tự nhiên và hoàn hảo của mạng Internet. Thực tế, P2P đã mang

Internet trở lại nguyên bản theo đúng ý tưởng của những người đầu tiên sáng lập ra
Internet ”.
Có nhiều định nghĩa khác nhau về mạng ngang hàng đã được sử dụng trong cộng
đồng. Peer-to-Peer Working Group định nghĩa P2P là "sự chia sẻ các các dịch vụ và
tài nguyên tính toán thông qua sự trao đổi trực tiếp giữa các hệ thống" [22]. Tác giả
Clay Shirkey thuộc nhóm Accelerator Group đã định nghĩa P2P là "một lớp các ứng
dụng tận dụng lợi thế về các tài nguyên - lưu trữ, chu kỳ, nội dung, sự có mặt của con

23
người – có sẵn ở các vùng biên của Internet" và "các nút mạng ngang hàng phải hoạt
động bên ngoài DNS và có phần quan trọng hoặc toàn bộ quyền tự trị của các server
trung tâm". Tuy nhiên chúng ta có thể kết luận rằng một ứng dụng P2P đặc trưng phải
có một số đặc tính cơ bản: đồng nhất kép (giống cả client lẫn server), chia sẻ tài
nguyên và hoạt động cộng tác. Các nút ngang hàng thường xuyên được kết nối, chúng
cộng tác với nhau trong việc cung cấp tài nguyên và chia sẻ các dịch vụ: một nút đóng
vai trò là client khi nó gửi yêu cầu tài nguyên và đóng vai trò là server khi nó cung cấp
các tài nguyên.


Hình 1.3.1-1: Kiến trúc Peer-to-Peer

Kiến trúc P2P nhìn chung bao gồm ba lớp: lớp ứng dụng, lớp trung gian
(middleware) và lớp mạng. Lớp ứng dụng cung cấp tương tác người dùng cũng như
dịch vụ logic hoặc các giải thuật khác nhau. Lớp trung gian mang lại các thuộc tính
ngang hàng riêng biệt hoặc các đặc trưng đối với mô hình tính toán tổng quát. Nó cung
cấp một giao diện mạng tổng quan cho lớp ứng dụng thông qua việc che phủ và ẩn
giấu các chi tiết liên quan đến truyền thông của tầng vật lý mạng. Hai chức năng thực
tế chủ yếu của lớp này là quản lý tài nguyên và quản lý nhóm. Theo một nghĩa khác,
lớp trung gian này là điểm mấu chốt để phân biệt kiến trúc P2P với các mô hình truyền
thông khác, như là mô hình Client/Server.

Tác giả Dejan S. Milojicic trong cuốn Peer-to-Peer Computing [7] đã tóm lược
những đặc tính mà mô hình mạng ngang hàng có thể đem lại bao gồm:
(1) Chia sẻ chi phí – chi phí có thể được chia sẻ và phân phối cho tất cả các nút mạng
ngang hàng.
(2) Khả năng mở rộng và tính tin cậy – các dịch vụ được cung cấp bởi nhiều nút mạng
ngang hàng tự trị (autonomous peer nodes) vẫn tốt hơn một vài server trung tâm.
(3) Kết hợp tài nguyên – nhiều loại tài nguyên, những tài nguyên ban đầu chỉ có trên
các máy cục bộ, bây giờ có thể được chia sẻ giữa các nút mạng ngang hàng.
(4) Tăng quyền tự trị - tài nguyên tính toán cục bộ có thể được tận dụng tốt hơn.
(5) Bảo mật và ẩn danh – những người dùng có thể ngăn chặn việc thông tin của họ bị
thu lượm bởi một thực thể cá biệt.