cho các peer khác trong mạng
Phương thức tấn công cụ thể như sau, polluter đăng nhập vào hệ thống và gửi các yêu cầu xem video để được tracker đưa vào trong peerlist của video tương ứng. Sau đó polluter cũng download về một số segment để lấy các thông số nhằm tạo ra các segment giả. Những peer xem video sau polluter (gọi là các receiver) gửi yêu cầu tới server sẽ nhận được peerlist trong đó có chứa địa chỉ của polluter. Khi nhận được truy vấn tìm kiếm phân mảnh của receiver gửi cho các thành viên trong trong peerlist thì polluter luôn gửi thông báo trả lời là có phân mảnh cần tìm. Bởi vì receiver không biết nên vẫn lập lịch download các block từ polluter như bình thường. Thay vì gửi các block hợp lệ cho receiver thì polluter sẽ gửi các block giả mạo. Mỗi receiver nhận được sẽ kết hợp các block ô nhiễm cùng với các block bình thường vào trong bộ đệm của chương trình media player. Kết quả là chất lượng hình ảnh video render tại receiver bị suy giảm. Nguy hiểm hơn nữa là các block ô nhiễm xuất phát từ một máy tính tấn công như vậy không chỉ tác động tới một peer đơn lẻ, khi mà peer bị tấn công lại chuyển tiếp các block nhận được cho các peer khác, và các peer khác đến lượt mình lại chuyển tiếp các block cho những peer khác nữa, cứ như thế, nội dung bị ô nhiễm hoàn toàn có khả năng lan ra toàn bộ hệ thống. Nếu như lượng dữ liệu bị ô nhiễm là đáng kể thì người dùng có thể cảm thấy chán nản và ngừng sử dụng dịch vụ.
Về mặt giải pháp, đối với các hình thức tấn công như DoS, replay attack … hiện nay cũng đã có nhiều cách thức chống lại các hình thức tấn công này. Trong khuôn khổ luận văn này, tác giả chỉ tập trung vào nghiên cứu và lựa chọn giải pháp cho hình thức tấn công ô nhiễm để có thể áp dụng vào hệ thống của mình.
Peer Peer Polluter Peer Peer Peer (Relay) Peer Peer
Đã có một số cơ chế phòng chống hình thức tấn công ô nhiễm bao gồm:
Lập danh sách đen (Blacklisting): xác định tất cả các peer đã bị ô nhiễm và cho vào blacklist. Việc xác định các peer này có thể theo phương thức tập trung hoặc phân tán. Đó có thể là các peer tấn công hoặc peer chuyển tiếp các dữ liệu ô nhiễm. Các peer nằm trong blacklist sẽ bị loại ra khỏi peerlist của tracker để cho các peer khác không phải nhận dữ liệu từ những peer lây nhiễm. Tuy nhiên việc xác định và cách ly các peer ô nhiễm là điều không dễ dàng.
Mã hóa thông báo (traffic encryption): nếu như tất cả các thông báo trong hệ thống đều được mã hóa thì sẽ khó cho những kẻ tấn công (attacker) xác định được cấu trúc của thông báo. Điều này sẽ ngăn chặn attacker chèn các thông báo giả vào trong hệ thống, chẳng hạn như các thông báo có chứa dữ liệu ô nhiễm. Dĩ nhiên, ý tưởng này chỉ thực hiện được đối với các hệ thống không sử dụng mã nguồn mở. Để thực hiện mã hóa thông báo, cần phải sử dụng các cặp khóa công khai trao đổi giữa các peer. Tuy nhiên trong một môi trường biến động như mạng ngang hàng (các peer thường xuyên thiết lập kết nối và ngắt kết nối) thì việc phải liên tục sinh ra các khóa là điều không khả thi.
Kiểm tra mã băm (hash verifycation): trước khi bắt đầu phiên streaming mỗi peer sẽ nhận được một file chứa mã băm tất cả các block của video từ tracker (tương tự như hệ thống của BitTorrent). Khi peer nhận được segment đầy đủ từ các peer khác nó sẽ so sánh mã băm của block nhận được với mã băm tương ứng trong file chứa mã băm để kiểm tra tính toàn vẹn của dữ liệu. Những block hợp lệ mới được phép chuyển tiếp cho các peer khác. Tuy nhiên, vì file chứa mã băm của tất cả các block có thể có kích thước đáng kể và khi hệ thống có một số lượng lớn các peer tham gia thì việc đồng thời tải các file chứa mã băm có thể gây quá tải cho tracker.
Ký phân đoạn (segment signing): trong kỹ thuật này, các thông tin xác thực được gửi cùng với các block. Thông tin xác thực được cung cấp bởi server hoặc thông qua chính hệ thống mạng ngang hàng và được truyền dưới dạng các stream độc lập hoặc đính kèm với các block.
Có ba kỹ thuật ký phân đoạn bao gồm:
- Ký toàn bộ (sign-all): mỗi block được ký riêng rẽ tại server, chữ ký (cũng chính là thông tin xác thực) được gắn vào block và phân phối cho các receiver. Mỗi receiver nhận được block và chữ ký tương ứng (từng cặp một) sẽ kiểm tra tính toàn vẹn của block này. Block chỉ được phép playback và chuyển tiếp cho các peer khác nếu như block được kiểm tra là hợp lệ. Hạn chế của cách tiếp cận này là chi phí tính toán cao. Đối với một video có m block thì server cần phải tạo ra cũng như receiver cần phải kiểm tra m chữ ký.
- Ký nối tiếp (Signature Amortization): kỹ thuật ký nối tiếp được đề xuất nhằm giảm tổng chi phí tính toán cho kỹ thuật ký toàn bộ (sign-all), ban đầu kỹ thuật này được thiết kế dành cho IP multicast. Trong kỹ thuật này, segment được chia nhỏ thành các block sao cho chỉ cần một thao tác ký cho mỗi segment. Tuy nhiên, mỗi block có thể
được kiểm tra một cách độc lập. Để đạt được điều này thì chi phí băng thông lại phải lớn hơn đôi chút so với phương pháp ký toàn bộ.
- Ký và sửa lỗi (sign-and-correct): Ban đầu server băm (hash) mỗi block của segment một cách độc lập sau đó ký một lần cho phần gộp của tất cả các mã băm này. Mã băm cùng với chữ ký (thông tin xác thực) sau đó được sử dụng để tính toán mã sửa lỗi Reed-Solomon (RS). Server sau đó gửi đi mỗi block kèm theo thông tin sửa lỗi. Khi nhận được các block này receiver dựa vào thông tin sửa lỗi để khôi phục thông tin xác thực và sử dụng thông tin xác thực để kiểm tra tính hợp lệ của block nhận được. Phương pháp Ký và sửa lỗi có chi phí băng thông thấp hơn so với phương pháp Ký nối tiếp.
Như vậy, có 4 giải pháp chống lại hình thức tấn công ô nhiễm bao gồm: lập danh sách đen (blacklisting), mã hóa thông báo (traffic encryption), kiểm tra mã băm (hash verification) và ký phân đoạn (segment-signing). Căn cứ vào những phân tích nêu trên có thể kết luận rằng ký phân đoạn là phương pháp thích hợp và tối ưu nhất (cả về băng thông lẫn chi phí tính toán) và có thể áp dụng vào trong mô hình đề xuất.
CHƢƠNG 3 - MÔ PHỎNG VÀ ĐÁNH GIÁ HIỆU NĂNG
Để đánh giá hiệu quả của mô hình đề xuất chúng tôi đã tiến hành một tập các mô phỏng thử nghiệm bao gồm: thử nghiệm khả năng đáp ứng của hệ thống, lưu lượng tải truy cập server, thời gian khởi tạo bộ đệm của peer gửi yêu cầu, ảnh hưởng của băng thông server cũng như mức độ cộng tác giữa các peer đối với hiệu năng của hệ thống. Các thử nghiệm được tiến hành với các tần suất yêu cầu truy cập cũng như mức độ đóng góp tài nguyên khác nhau của các peer. Trong một số thử nghiệm chúng tôi cũng so sánh kết quả đạt được với hệ thống Client/Server để khẳng định tính hiệu quả của hệ thống đề xuất PPVoD. Chương trình mô phỏng được viết bằng ngôn ngữ C++ chạy trên môi trường Windows.
3.1. Các tham số và kịch bản mô phỏng
Dưới đây là các tham số cố định được sử dụng trong tất cả các mô phỏng thử nghiệm:
Mô phỏng được thực hiện trong khoảng thời gian 120 phút, tổng cộng có 50 video được được đưa vào trong hệ thống, mỗi video được gán một videoID khác nhau, có độ dài 60 phút và tốc độ phát hình không đổi (CBR) 512Kbps. Các video được chia thành 30 segment, mỗi segment có độ dài 2 phút và kích thước khoảng 7.5MB. Để thực hiện truyền tải và trao đổi giữa các peer thì mỗi segment lại được chia nhỏ thành các block, mỗi block có kích thước 512Kb (bằng độ dài của 1 giây video), như vậy một segment gồm có 120 block. Mỗi receiver sẽ chọn ra từ 3 đến 8 peer cung cấp (supplying peer) tùy thuộc vào băng thông upload của các peer trong peerlist nhận được. Các giá trị α, β của hàm Pot được chọn lần lượt là α = 0.4 và β = 0.6 để ưu tiên chọn các peer ở gần hơn.
Mỗi peer đóng góp băng thông trong phạm vi từ 64Kbps đến 1.5Mbps và bộ nhớ lưu trữ từ 2 segment (15MB) đến 20 segment (150MB). Mỗi peer gửi yêu cầu đều có khả năng mở tới 10 kết nối đồng thời với các peer khác và có đủ băng thông download tối thiểu 512Kbps để tải về các video segment ở tốc độ phát hình đầy đủ. Việc lưu đệm phân mảnh tại các peer đều thực hiện theo cơ chế LRU (Least Recently Used).
Video server có băng thông truy cập từ 20-40Mbps (tùy theo từng mô phỏng) và bộ nhớ lưu trữ 300GB (lưu được khoảng 500 file video).
Hệ thống Client/Server đối sánh sử dụng server có cấu hình tương đương với video server.
Mô phỏng được thực hiện theo kịch bản như sau:
Ban đầu video server đưa các file video vào trong hệ thống. Các peer đăng nhập hệ thống và gửi yêu cầu xem video bất kỳ cho server. Mỗi peer chỉ gửi một lần, một yêu cầu truy cập. Các kiểu tần suất truy cập sử dụng trong mô phỏng bao gồm:
- Tần suất truy cập ngẫu nhiên (random rate arrivals): trong mỗi phút có từ 0 đến 10 yêu cầu truy cập. Số lượng truy cập trong mỗi phút được phân phối theo xác suất ngẫu nhiên, tính trung bình vào khoảng 5 yêu cầu truy cập/phút.
- Tần suất truy cập không đổi (constant rate arrivals): theo chu kỳ 12 giây lại có một peer gửi yêu cầu tham gia hệ thống (5 yêu cầu truy cập/phút), như vậy sau 120 phút có 600 peer gửi yêu cầu tham gia.
- Tần suất truy cập tăng đột biến (flash crowd arrivals): ban đầu các peer gửi yêu cầu truy cập ở mức 5 yêu cầu/phút, sau đó đột ngột tăng lên 40 yêu cầu/phút (trong khoảng thời gian từ phút thứ 81 đến phút thứ 100) rồi trở lại mức bình thường (5 yêu cầu/phút), tổng cộng trong vòng 120 phút có 1300 peer gửi yêu cầu.
0 5 10 15 20 25 30 35 40 45 0 20 40 60 80 100 120 Thời gian (phút) T ần su ất tr uy cậ p (số tr uy cậ p/ ph út )
(a) Tần suất truy cập không đổi (constant rate arrivals)
0 5 10 15 20 25 30 35 40 45 0 20 40 60 80 100 120 Thời gian (phút) Tầ n su ất t ru y cậ p (s ố tr uy c ập /p hú t)
(b) Tần suất truy cập tăng đột biến (flash crowd arrivals)
0 2 4 6 8 10 12 0 10 20 30 40 50 60 70 80 90 100 110 120 Thời gian (phút) T ần s uấ t t ru y cậ p (s ố tru y cậ p/ ph út )
(c) Tần suất truy cập ngẫu nhiên (random rate arrivals)