Một số giao thức truyền thông thời gian thực và ứng dụng xây dựng hệ thống truyền hình trực tuyến đa điểm trên mạng internet

Số hóa bởi Trung tâm Học liệu – ĐHTN http://www.lrc.tnu.edu.vn TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN&TRUYỀN THÔNG LÊ ANH VIỆT MỘT SỐ GIAO THỨC TRUYỀN THÔNG THỜI GIAN THỰC VÀ ỨNG DỤNG XÂY

Trang 1

Số hóa bởi Trung tâm Học liệu – ĐHTN http://www.lrc.tnu.edu.vn

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN&TRUYỀN THÔNG

LÊ ANH VIỆT

MỘT SỐ GIAO THỨC TRUYỀN THÔNG THỜI GIAN THỰC

VÀ ỨNG DỤNG XÂY DỰNG HỆ THỐNG TRUYỀN HÌNH TRỰC

TUYẾN ĐA ĐIỂM TRÊN MẠNG INTERNET

LUẬN VĂN THẠC SĨ CHUYÊN NGÀNH KHOA HOC MÁY TÍNH

Thái Nguyên - 2015

Trang 2

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN&TRUYỀN THÔNG

LÊ ANH VIỆT

MỘT SỐ GIAO THỨC TRUYỀN THÔNG THỜI GIAN THỰC

VÀ ỨNG DỤNG XÂY DỰNG HỆ THỐNG TRUYỀN HÌNH TRỰC

TUYẾN ĐA ĐIỂM TRÊN MẠNG INTERNET

Chuyên ngành: Khoa học máy tính

Mã số chuyên nghành: 60 48 0101

LUẬN VĂN THẠC SĨ CHUYÊN NGÀNH KHOA HOC MÁY TÍNH

NGƯỜI HƯỚNG DẪN KHOA HỌC

TS Phạm Ngọc Lãng

Thái Nguyên - 2015

Trang 3

LỜI CAM ĐOAN

Tôi xin cam đoan :

1 Những nội dung trong luận văn này là do tôi thực hiện dưới sự hướng dẫn trực tiếp của TS Phạm Ngọc Lãng

2 Mọi tham khảo dùng trong luận văn đều được trích dẫn rõ ràng tên tác giả, tên công trình, thời gian, địa điểm công bố

3 Mọi sao chép không hợp lệ, vi phạm quy chế đào tạo, hay gian trá, tôi xin chịu hoàn toàn trách nhiệm

Học viên

Lê Anh Việt

Trang 4

LỜI CẢM ƠN

Trước hết tôi xin gửi lời cảm ơn sâu sắc nhất tới người hướng dẫn tôi, thầy giáo TS Phạm Ngọc Lãng – Viện Hàn lâm Khoa học và Công nghệ Việt Nam, người đã định hướng đề tài và tận tình hướng dẫn, chỉ bảo trong suốt quá trình thực hiện luận văn cao học

Tôi xin gửi lời cảm ơn tới các thầy cô đã giảng dạy tôi trong suốt quá trình nghiên cứu, học tập, các thầy cô trong ban chủ nhiệm lớp CHK12G, những người rất quan tâm tới lớp, giúp tôi và các bạn có được kết quả như ngày hôm nay Sau cùng, tôi xin dành tình cảm đặc biệt và biết ơn tới gia đình, người thân của tôi, những người đã ủng hộ, khuyến khích tôi rất nhiều trong quá trình học tập cũng như quá trình thực hiện luận văn này

Thái Nguyên, tháng 5 năm 2015

Lê Anh Việt

Trang 5

MỤC LỤC LỜI CAM ĐOAN I LỜI CẢM ƠN II MỤC LỤC III DANH MỤC CÁC KÝ HIỆU, CHỮ VIẾT TẮT VI DANH MỤC HÌNH VẼ VÀ ĐỒ THỊ VIII

PHẦN MỞ ĐẦU 1

CHƯƠNG 1 TỔNG QUAN VỀ HỆ THỐNG TRUYỀN HÌNH TRỰC TUYẾN 1

1.1 HỆ THỐNG TRUYỀN HÌNH TRỰC TUYẾN 1

1.1.1 Hội nghị truyền hình 1

1.1.2 Những vấn đề cơ bản của việc truyền thông tin âm thanh và hình ảnh 1

1.1.3 Các kênh có thể dùng cho hội nghị truyền hình 2

1.1.4 Công nghệ truyền thông đa phương tiện thời gian thực 3

1.2 ĐẢM BẢO CHẤT LƯỢNG TRUYỀN HÌNH TRÊN MẠNG 4

1.2.1 Khái niệm QoS 4

1.2.2 Yêu cầu QoS cho truyền thông đa phương tiện 5

1.2.3 Đặc điểm vận chuyển lưu lượng kiểu “Cố gắng tối đa” 6

1.2.4 Băng thông 9

1.2.5 Độ trễ và biến thiên độ trễ 9

1.2.6 Tỉ lệ mất mát gói tin 10

1.2.7 Một số tham số khác 11

CHƯƠNG 2 MỘT SỐ GIAO THỨC TRUYỀN THÔNG THỜI GIAN THỰC 13

2.1 GIAO THỨC STREAMING 13

2.1.1 Giới thiệu chung 13

2.1.2 Kiến trúc hệ thống streaming thời gian thực 14

Trang 6

2.1.3 Phân lớp giao thức trong hệ thống streaming thời gian thực 17

2.2 GIAO THỨC RTP 19

2.2.1 Cấu trúc của header của RTP 20

2.2.2 Ghép kênh RTP 25

2.2.3 Mở rộng Header cho RTP 25

2.3 GIAO THỨC RTCP 26

2.3.1 Giao thức điều khiển luồng RTCP 26

2.3.2 Quá trình truyền và nhận gói tin RTCP 28

2.4 GIAO THỨC RTSP 29

2.5 MỐI QUAN HỆ GIỮA RTSP, RTP VÀ RTCP 32

2.6 CHUẨN H323 33

2.6.1 Chồng giao thức H.323 34

2.6.2 Các thành phần trong hệ thống H.323 34

2.7 GIAO THỨC RTMP 38

2.7.1 Giới thiệu 38

2.7.2 Nguyên tắc hoạt động 39

2.7.3 Quá trình bắt tay 39

2.7.4 Tiêu đề RTMP 43

CHƯƠNG 3 CÀI ĐẶT VÀ XÂY DỰNG HỆ THỐNG TRUYỀN THÔNG TRỰC TUYẾN ĐA ĐIỂM QUA MẠNG INTERNET 45

3.1 ỨNG DỤNG CÔNG NGHỆ STREAMING XÂY DỰNG CHƯƠNG TRÌNH TRUYỀN HÌNH TRỰC TIẾP ĐA ĐIỂM 45

3.2 PHÂN TÍCH YÊU CẦU HỆ THỐNG 52

3.2.1 Phân tích nhu cầu 52

3.2.2 Đặc tả các yêu cầu hệ thống 53

3.3.3 Đặc tả chức năng 53

Trang 7

3.3 THIẾT KẾ QUÁ TRÌNH TRUYỀN THÔNG TIN SỬ DỤNG CÔNG

NGHỆ STREAMING 54

3.4 THIẾT KẾ CHỨC NĂNG ĐA PHƯƠNG TIỆN THỜI GIAN THỰC 55

3.5 THIẾT KẾ VAI TRÒ GIỮA CÁC THÀNH VIÊN TRONG QUÁ TRÌNH TẬP HUẤN 57

3.6 MỘT SỐ KẾT QUẢ 58

3.6.1 Quản lý người dùng 58

3.6.2 Phân hệ truyền dữ liệu đa phương tiện thời gian thực qua mạng IP 58

3.6.3 Phân hệ nhận dữ liệu đa phương tiện thời gian thực qua mạng IP 59

3.6.3 Phân hệ kết nối camera HD với mạng 60

3.7 TÍNH BẢO MẬT 62

KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 64

TÀI LIỆU THAM KHẢO 64

Trang 8

DANH MỤC CÁC KÝ HIỆU, CHỮ VIẾT TẮT

công cộng

thời gian thực

Trang 9

Media

Trang 10

DANH MỤC HÌNH VẼ VÀ ĐỒ THỊ

Hình 1: Mô hình chung về hệ thống streaming thời gian thực 15

Hình 2: Kiến trúc chung hệ thống video streaming 15

Hình 3: Mối quan hệ giữa các giao thức trong hệ thống video streaming 18

Hình 4: Cấu trúc header của RTP 20

Hình 5: Khởi tạo phiên 22

Hình 6 : Phân mảnh dữ liệu 23

Hình 7: Mở rộng header của RTP 26

Hình 8: Cấu trúc RTCP 27

Hình 9: Nhóm gói (compound packets) 28

Hình 10: Quá trình truyền và nhận gói tin RTCP giữa nơi gửi và nơi nhận của công nghệ streaming thời gian thực 29

Hình 11: Minh họa quá trình hoạt động của giao thức RTSP 30

Hình 12: Minh họa về vị trí của các giao thức truyền thông streaming thời gian thực trong kiến trúc phân tầng của mạng IP 32

Hình 13: Chồng giao thức H.323 34

Hình 14: Cấu trúc hệ thống H323 35

Hình 15: Thiết bị đầu cuối H.323 (H.323 Terminal) 36

Hình 16: RTMP ở chế độ tiêu chuẩn 39

Hình 17: RTMP ở chế độ đường hầm 39

Hình 18: C0 và S0 bít 40

Hình 21: Hình vẽ trực quan sự bắt tay 42

Hình 22: Tiêu đề RTMP 12 byte 43

Hình 23: Một số giá trị trong trường Content Type 44

Hình 24: Giao diện chương trình truyền thông đa phương tiện thời gian thực đơn giản sử dụng công nghệ streaming trong ActionScript của Adobe 47

Hình 25: Giao diện chương trình trước khi chạy 50

Trang 11

Hình 26: Giao diện chương trình sau khi chạy 50 Hình 27: Biểu đồ trình tự quá trình truyền thông sử dụng công nghệ Streaming thời gian thực cho chương trình ứng dụng 55 Hình 28: Biểu đồ trình tự quá trình truyền thông sử dụng công nghệ Streaming thời gian thực 56 Hình 29: Vai trò giữa các thành viên trong quá trình tập huấn của hệ thống truyền thông đa phương tiện thời gian thực qua mạng IP 57 Hình 30: Giao diện thống kê danh sách người dùng 58 Hình 31: Quá trình truyền dữ liệu đa phương tiện từ phía clients tới streaming server 59 Hình 32: Quá trình nhận dữ liệu đa phương tiện từ streaming server về clients 60 Hình 33: a) Sơ đồ kết nối Camera HD với ứng dụng; b) kết quả kết nối camera

HD với ứng dụng 61

Trang 12

PHẦN MỞ ĐẦU

Ngày nay, với sự phát triển mạnh mẽ của lĩnh vực CNTT&TT, hạ tầng mạng viễn thông đã tạo thuận lợi cho nhà khoa học nghiên cứu và triển khai nhiều ứng dụng truyền thông trên mạng Internet cho cộng đồng như PPlive, Sopcast, Skype, IPTV, MobileTV, đặc biệt là hệ thống truyền hình trực tuyến đang ngày càng được ứng dụng phổ biến và đem lại lợi ích to lớn cho xã hội

Hệ thống truyền hình trực tuyến được xây dựng dựa trên nền tảng giao thức truyền thông thời gian thực cho phép dữ liệu như hình ảnh, âm thanh, video và văn bản được truyền trực tuyến giữa người dùng ở vị trí khác nhau qua mạng Interent Nhờ đó, người dùng không nhất thiết phải gặp nhau trực tiếp mà vẫn có thể trao đổi với nhau không chỉ bằng văn bản, âm thanh mà còn hình ảnh và video theo thời gian thực Với lợi ích to lớn như vậy, hệ thống truyền hình trực tuyến đang ngày càng được ứng dụng rộng rãi trong nhiều lĩnh vực như giáo dục,

y tế, truyền hình và hành chính công

Tuy nhiên, với đặc điểm của mạng Internet là băng thông không ổn định, dẫn đến tốc truyền tải dữ liệu thay đổi ngẫu nhiên trong cùng một ứng dụng truyền thông khi hoạt động trên mạng Internet Đối với hệ thống truyền hình trực tuyến thì điều này sẽ dẫn đến những vấn đề như mất đồng bộ dữ liệu hình ảnh và

âm thanh, hình ảnh bị giật và âm thanh đứt quãng cho hệ thống truyền hình trực tuyến trên mạng Bởi vậy, chủ đề nghiên cứu về giao thức truyền thông thời gian thực luôn được cộng đồng khoa học quan tâm nghiên cứu nhằm cải tiến để khắc phục những nhược điểm trên cho hệ thống truyền hình trực tuyến trên mạng [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]

Chính vì vậy, việc nghiên cứu một số giao thức truyền thông thời gian thực như H323, RTP (Real Time Protocol), RTCP (Real-time Transport Control Protocol), RTMP (Real Time Messaging Protocol) nhằm nắm vững phương pháp,

cơ chế liên kết truyền thông của những giao thức này và ứng dụng xây dựng hệ thống truyền hình trực tuyến đa điểm trên mạng Internet là chủ đề nghiên cứu có

ý nghĩa khoa học và thực tiễn [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22]

Trang 13

CHƯƠNG 1 TỔNG QUAN VỀ HỆ THỐNG TRUYỀN HÌNH

với phần mềm tương ứng

tính hoặc là qua các kênh liên kết điện thoại số.[1]

1.1.2 Những vấn đề cơ bản của việc truyền thông tin âm thanh và hình ảnh

Để truyền thông tin âm thanh và hình ảnh cần phải giải quyết 2 vấn đề: Vấn đề thứ nhất là kênh kết nối dùng để truyền thông tin phải có độ cao Các kênh điện thoại thông thường hoàn toàn tích hợp để truyền tín hiệu âm thanh, nhưng không đảm bảo truyền ảnh có chất lượng được (ở đây thực sự có nhiều cách giải quyết các hệ thống nén chia kênh, nhưng chúng không phải lúc nào cũng ứng dụng được Hiện nay có lẽ hiếm các cơ quan nào mà các máy tính không nối mạng Một mạng như vậy hoàn toàn thích hợp để tổ chức hội nghị truyền hình chất lượng cao

Vấn đề thứ hai là vấn đề biến luồng thông tin âm thanh và hình ảnh nghĩa

là mã hoá dữ liệu truyền đi và giải mã dữ liệu nhận được Vấn đề là trong hội nghị truyền hình đã sử dụng những thuật toán đặc biệt và rất hiệu quả nén hàng chục và hiện nay là hàng trăm lần Có thể nói rằng truyền đi không phải chính

Trang 14

các tín hiệu âm thanh và hình ảnh mà chỉ là những tham số quan trọng nhất của chúng để khôi phục tín hiệu ở đầu nhận với chất lượng cao được Nếu như máy

vi tính không kịp xử lý luồng tín hiệu thì sẽ có những ảnh bị bỏ qua và lỗi ở kênh xuất v.v

Để giải quyết các vấn đề trên cần có các bản vi mạch đặc biệt vì:

Các thuật toán chế biến tín hiệu rất đòi hỏi đến tài nguyên của hệ thống tính toán Mặc dù có những giải quyết hoàn toàn bằng phần mềm, nhưng chúng yêu cầu rất lớn đối với tài nguyên hạ tầng cơ sở của hệ thống xử lý Kết quả là với cả những máy tính cá nhân rất hiện đại cũng làm chậm rất đáng kể sự hoạt động của các thiết bị liên quan và chất lượng liên kết hình ảnh yêu cầu cũng rất khó đạt được Thực tế toàn cầu phải chấp nhận giải pháp là sử dụng các thiết bị chuyên dụng (các bo mạch đặc biệt: bộ mã hoá - giải mã (code), chúng được cắm vào một rãnh dự trữ trên bo mạch chính của máy PC) Các bộ code nén các tín niệu và giải mã nó để cho kênh kết nối (tương ứng là giải nén và giải mã ở phía bên nhận) [20]

1.1.3 Các kênh có thể dùng cho hội nghị truyền hình

Sơ đồ hệ thống (cổ điển) thực hiện hội nghị truyền hình được hiểu là sự liên kết giữa các đầu cuối bằng các đường ISDN (Mạng số với sự kết hợp các tiện ích) Việc sử dụng các kênh ISDN cũng như các mạng khác với việc đảm bảo chất lượng kênh nối được chỉ dẫn bằng hàng loạt các khuyến nghị H.320 đã được chế tác bởi ITU-T Tuy nhiên thời gian không dừng tại một chổ, mấy năm gần đây việc truyền bá rộng rãi hơn cả là hội nghị truyền hình sử dụng mạng IP như là mạng nội bộ vừa có ý nghĩa của mạng phân vùng lãnh thổ vừa có tính toàn cầu Khuyến thị tương ứng là chuẩn H.323 cho hội nghị truyền hình bằng mạng

IP đã được ITU-T đưa ra cuối năm 1996 Nói chung có thể nói thực tế đến nay hội nghị truyền hình có thể sử dụng bất kỳ kênh kết nối nào với một thông lượng

đủ lớn [22]

Trang 15

1.1.4 Công nghệ truyền thông đa phương tiện thời gian thực

Trong những năm qua, công nghệ truyền thông đa phương tiện thời gian thực luôn được quan tâm và đang ngày càng phát triển về chất lượng dịch vụ (QoS) [2] nên đã tạo thuận lợi cho các nhà phát triển phần mềm xây dựng sản phẩm truyền thông đa phương tiện đa đạng và phong phú như IPTV, Videophone, Voicemail, Multimedia SMS [11] và VoD Bởi vậy, hiện nay có nhiều công nghệ cho phép chúng ta xây dựng hệ thống truyền thông đa phương tiện thời gian thực như công nghệ H323, công nghệ Silverlight, công nghệ Streaming và công nghệ Socket Trong đó, công nghệ Streaming thời gian thực đang được quan tâm và ứng dụng phổ biến Công nghệ Socket: Socket là kỹ thuật lập trình cơ bản nhất được phát triển bởi đại học California, Hoa Kỳ Socket được hiểu như là giao diện kết nối giữa lớp ứng dụng với lớp truyền thông TCP/UPD Nhà phát triển sử dụng socket để thực hiện việc truyền thông dữ liệu qua giao diện này Bởi vậy, quá trình xử lý dữ liệu trước khi gửi đi sẽ được xử lý trực tiếp Hiện nay, Socket được phát triển phổ biến trong nhiều môi trường lập trình như Java, Net

Công nghệ H323 [9]: Công nghệ này là một chuẩn quốc tế phục vụ cho việc hội thoại trên mạng được phát triển bởi Hiệp hội viễn thông quốc tế - ITU Công nghệ này cho phép truyền thông dữ liệu đa phương tiện thời gian thực qua mạng IP, với đầy đủ các hỗ trợ cho các nhà phát triển và tính tương thích hệ thống cao

Công nghệ Silverlight: Công nghệ này được phát triển và đóng gói thành plug-in bởi Microsoft Với đặc điểm là độc lập với đa nền tảng và trình duyệt, công nghệ Silverlight cung cấp mô hình lập trình mềm dẻo và đồng nhất trên nhiều môi trường như Internet Explorer, Firefox, Safari và các ngôn ngữ khác nhau như Ajax, Python, Ruby, Net

Công nghệ Streaming: Công nghệ streaming là một kỹ thuật để chuyển dữ liệu được xử lý như một dòng ổn định và liên tục dựa trên cách thức phát lại dữ liệu đa phương tiện được lưu trữ trên các máy chủ trên mạng tới người dùng khi muốn xem dữ liệu đa phương tiện đó mà không cần tải dữ liệu đa phương tiện đó

Trang 16

về trên máy tính của mình Công nghệ Streaming được ứng dụng rộng rãi để phát triển hệ thống truyền thông đa phương tiện trực tuyến

1.2 ĐẢM BẢO CHẤT LƯỢNG TRUYỀN HÌNH TRÊN MẠNG

1.2.1 Khái niệm QoS

Chất lượng dịch vụ là một vấn đề khó định nghĩa chính xác và theo cách định lượng, bởi vì nhìn từ các góc độ khác nhau người ta có thể có quan điểm về chất lượng dịch vụ khác nhau Ví dụ, với người sử dụng dịch vụ thoại, chất lượng dịch vụ cung cấp tốt nhất khi thoại được rõ ràng, tức là chúng ta cần phải đảm bảo tốt về giá trị tham số trễ, biến thiên độ trễ và giá trị tham số mất gói tin với một tỉ lệ tổn thất nào đó có thể chấp nhận được Nhưng đối với khách hàng là người sử dụng trong truyền số liệu ở ngân hàng thì điều tối quan trọng là độ tin cậy, có thể chấp nhận trễ lớn, biến thiên độ trễ lớn nhưng thông số mất gói tin, độ bảo mật kém thì không thể chấp nhận được

Từ góc nhìn của nhà cung cấp dịch vụ mạng, công việc đảm bảo QoS cho các dịch vụ mà họ cung cấp cho người sử dụng là thực hiện các biện pháp để duy trì các mức QoS theo nhu cầu, với cơ sở hạ tầng mạng hiện có, thõa mãn các tiêu chuẩn như độ tin cây, tính bảo mật và băng thông với thời gian trễ chấp nhận được

Với các dịch vụ đa phương tiện chất lượng cao như nghe nhạc, xem phim trực tuyến, VoIP, được truyền trên mạng thì quá trình phát và nhận theo thời gian thực đòi hỏi phải triển khai một mạng có hỗ trợ việc đảm bảo chất lượng dịch vụ ATM là một giao thức được thiết kế để có thể triển khai thực hiện đảm bảo chất lượng dịch vụ ở nhiều mức Việc triển khai chất lượng dịch vụ sử dụng mạng IP đòi hỏi phái có thêm một số dịch vụ như giành trước tài nguyên, sử dụng giao thức truyền thông, cho phép băng thông có thể được đăng ký để giành trên những thiết bị mạng trung gian như bộ định tuyến

Với những phân tích nêu trên, có thể định nghĩa chất lượng dịch vụ dựa trên hai quan điểm sau: chất lượng dịch vụ theo quan điểm đánh giá của người sử

Trang 17

dụng cuối và chất lượng dịch vụ theo quan điểm mạng Đối với người sử dụng, chính là sự thõa mãn về chất lượng dịch vụ hoặc một ứng dụng mà người đó thuê bao Ví dụ: dịch vụ điện thoại, video hoặc truyền dữ liệu, truyền hình vệ tinh Với quan điểm mạng, thuật ngữ chất lượng dịch vụ là các cơ chế, công cụ đảm báo cho các mức dịch vụ khác nhau thõa mãn các tiêu chuẩn như độ tin cậy, tính bảo mật cao, băng thông đủ lớn với thời gian trễ cần thiết cho một ứng dụng đặc biệt nào đó

Thông thường, mạng thường phải truyền tải nhiều loại gói tin với các yêu cầu về hiệu năng là khác nhau Có thể loại gói tin đó là rất quan trọng trong dịch

vụ này nhưng lại không quá quan trọng trong dịch vụ khác Vì thể một cơ chế đảm báo chất lượng dịch vụ được triển khai trong một mạng phải xem xét đến sự xung đột các yêu cầu về hiệu năng và cân bằng các yếu tố khác nhau để đạt được

sự kết hợp tốt nhất giữa chúng [1]

1.2.2 Yêu cầu QoS cho truyền thông đa phương tiện

Ban đầu khi xây dựng mạng Internet, yêu cầu chất lượng dịch vụ cho các ứng dụng chưa được chú trọng Vì vậy toàn bộ hệ thống mạng Internet bấy giờ hoạt động đựa trên nguyên tắc “cố gắng tối đa - best effort“ Thời kỳ đó, trong các gói tin IP người ta sử dụng 4 bít để mô tả loại dịch vụ và 3 bít để cung cấp khả năng xử lý ưu tiên cho các gói tin Chúng không đủ để đáp ứng các yêu cầu của hệ thống Internet ngày nay với các dịch vụ phát triển mạnh như âm thanh, hình ảnh, đa phương tiện, Có rất nhiều vấn đề có thể xảy ra đối với các gói tin khi chúng di chuyển từ nguồn đến đích như:

gói tin truyền trên đường truyền

định tuyến để được chuyển tiếp hoặc phát lại do bị mất Các dữ liệu trong dạng âm thanh bị ảnh hưởng nhiều bởi vấn đề này

mạng sẽ bị ảnh hưởng xấu do tác động của các yếu tố chủ yếu nêu trên

Trang 18

Từ góc nhìn của các dịch vụ vận chuyển đầu cuối- đầu cuối, tỷ lệ tổn thất gói tin tổng cộng bao gồm tỷ lệ tổn thất trên mạng và tỷ lệ tổn thất do hủy gói tại

bộ đệm bên nhận do gói tin đến trễ quá giới hạn chấp nhận được Độ trễ tổng quát bao gồm trễ truyền qua mạng và trễ bộ đệm, gây nên do thời gian lưu gói tin tại bộ đệm được tái tạo (tại bên nhận) Ngoài tỷ lệ tổn thất gói tin và độ trễ tổng quát, chất lượng tín hiệu thu nhận còn phụ thuộc vào các chuẩn CODEC, giải thuật bù tổn thất gói tin và các phương thức điều khiển lịch trình tái tạo gói tin của bộ đệm tái tạo tại đầu nhận

1.2.3 Đặc điểm vận chuyển lưu lượng kiểu “Cố gắng tối đa”

Giao thức IP cung cấp dịch vụ cố gắng tối đa, nghĩa là nó cố gắng chuyển mỗi datagram từ nguồn đến đích một cách nhanh nhất có thể Tuy nhiên nó không đảm bảo độ trễ cũng như biến thiễn trễ của các gói tin Mặt khác TCP và UDP đều chạy trên IP, chúng cũng không đảm bảo về mặt độ trễ cho các gói tin TCP truyền tin cậy nhưng việc áp dụng cơ chế này dẫn đến việc phải phát lại các gói tin bị mất cho đến khi thành công, vì vậy có thể gây ra độ trễ rất lớn; ngoài ra việc áp dụng cơ chế cửa sổ trượt có kích thước thay đổi cũng dẫn đến jitter lớn UDP không sử dụng cơ chế biên nhận do đó không tin cậy

Đặc điểm vận chuyển kiểu “cố gắng tối đa” của các giao thức nói trên không thích hợp cho sự phát triển các ứng dụng đa phương tiện trên Internet Tuy nhiên, chúng đã được sử dụng phổ biến trên Internet ngay từ khi Internet mới hình thành, do đó để truyền thông đa phương tiện trên Internet người ta đã và đang áp dụng giải pháp thực tế là sửa đổi và cải tiến chúng chứ không thay thế bằng các giao thức hoàn toàn mới

Cho đến nay, các ứng dụng truyền thông đa phương tiện sử dụng các giải pháp này đã làm tăng chất lượng dịch vụ lên đáng kể, song vẫn còn nhiều hạn chế, đòi hỏi tiếp tục được nghiên cứu, cải tiến Chẳng hạn đối với các ứng dụng truyền âm thanh/hình ảnh được lưu trữ trước thì độ trễ trung bình trong khoảng

từ 5-10s là chấp nhận được, tuy nhiên ở những thời điểm tắc nghẽn thì độ trễ có thể tăng đến mức không chấp nhận được Đối với các ứng dụng truyền thông đa

Trang 19

phương tiện thời gian thực kiểu có tương tác, yêu cầu về độ trễ và biên thiên trễ còn cao hơn nữa, do đó các yêu cầu này thường không được đáp ứng

Người ta đã đề xuất và áp dụng một số biện pháp để cải thiện chất lượng của các ứng dụng truyền thông đa phương tiện, như sau:

- Cơ chế loại bỏ biến thiên trễ ở phía nhận;

- Khôi phục các gói tin bị mất tại phía nhận;

- Nén dữ liệu âm thanh/hình ảnh;

- Sử dụng giao thức RTP ở tầng giao vận

Dưới đây là những hạn chế của dịch vụ cố gắng tối đa:

a) Tỉ lệ mất mát gói tin có thể rất lớn khi xảy ra tắc nghẽn

Chúng ta xem xét một UDP segment được tạo ra bởi ứng dụng một điện thoại Internet Nó được đóng gói trong một IP datagram và IP datagram được chuyển tới phía nhận Datagram được truyền trên mạng qua các bộ đệm trong các

Bộ định tuyến Nếu một trong các bộ đệm của Bộ định tuyến đã đầy thì datagram

sẽ không được nhận vào Trong trường hợp này, IP datagram bị loại bỏ và coi như bị mất, không tới được phía nhận

Sự mất mát gói tin có thể được loại bỏ bằng cách gửi gói tin bằng TCP TCP có cơ chế biên nhận nên sẽ truyền lại các gói tin bị mất Tuy nhiên, cơ chế truyền lại nói chung là không thể chấp nhận được đối với ứng dụng thời gian thực như là điện thoại Internet bởi vì nó làm tăng độ trễ Hơn nữa, theo cơ chế điều khiển tắc nghẽn trong TCP, sau khi mất gói tin, tốc độ phát tại phía gửi có thể giảm tới mức thấp nhất, điều này ảnh hưởng nghiêm trọng tới chất lượng âm thanh tại phía nhận Vì thế hầu hết các ứng dụng điện thoại Internet đều chạy trên UDP và không thực hiện truyền lại các gói tin bị mất Trên thực tế, tỉ lệ mất gói tin từ 1% tới 20% là có thể chấp nhận được, phụ thuộc vào cách âm thanh được nén sau đó được truyền đi và phụ thuộc vào cách che đậy sự mất gói tin của phía nhận như thế nào Cơ chế sửa lỗi FEC có thể được dùng để che đậy sự mất gói tin Tuy nhiên, nếu đường truyền giữa bên gửi và bên nhận bị tắc nghẽn trầm

Trang 20

trọng, tỉ lệ mất gói tin vượt quá 10-20%, khi đó sẽ không có cách nào đạt được chất lượng âm thanh mong muốn Đây là hạn chế của dịch vụ cố gắng tối đa

b) Độ trễ toàn trình có thể vượt quá giới hạn chấp nhận được

Độ trễ toàn trình (đầu cuối đến đầu cuối) là tổng của thời gian xử lý và chờ trong hàng đợi của các Bộ định tuyến dọc theo đường truyền từ người gửi đến người nhận, thời gian truyền và thời gian xử lý của phía nhận Với các ứng dụng tương tác thời gian thực như điện thoại Internet, độ trễ toàn trình nhỏ hơn 150ms được coi là không có vấn đề gì (giác quan con người không cảm nhận được sự khác biệt), độ trễ từ 150-400ms là có thể được chấp nhận được, độ trễ lớn hơn 400ms là quá lớn, không thể chấp nhận được Phía nhận của ứng dụng điện thoại Internet sẽ không nhận bất kì gói tin nào đến trễ hơn một ngưỡng nhất định, ví dụ 400ms Do đó, các gói tin đến trễ hơn ngưỡng trên thì coi như là mất

c) Biến thiên trễ là không thể tránh khỏi và làm giảm chất lượng âm

thanh

Một trong những thành phần tạo nên độ trễ toàn trình là thời gian chờ ngẫu nhiên ở hàng đợi của Bộ định tuyến Do thời gian chờ ngẫu nhiên này, độ trễ toàn trình có thể thay đổi đối với từng gói tin, sự biến đổi này được gọi là biến thiên trễ Ví dụ: Xét 2 gói tin được sinh ra liên tiếp nhau trong một đoạn của ứng dụng điện thoại Internet Phía gửi phát gói tin thứ 2 sau gói tin đầu 20ms Nhưng tại bên nhận, khoảng thời gian giữa 2 lần nhận 2 gói tin đó có thể lớn hơn hoặc nhỏ hơn 20ms Chúng ta có thể thấy rõ hơn như sau: Giả sử gói tin đầu tiên tới khi hàng đợi Bộ định tuyến hầu như là rỗng, nó sẽ được truyền đi ngay, nhưng trước khi gói tin thứ hai tới thì một lượng lớn gói tin từ các nguồn khác đổ về làm đầy hàng đợi, gói tin thứ hai này được xếp vào cuối hàng đợi và phải chờ một khoảng thời gian nhất định trước khi được chuyển tiếp Như vậy rõ ràng hai gói tin sẽ đến đích trong khoảng thời gian lớn hơn 20ms (có thể lên tới vài giây hoặc nhiều hơn) Ngược lại, giả sử gói tin đầu tới cuối hàng đợi (hàng đợi lúc đó hầu như rất đầy), gói tin thứ 2 tới hàng đợi đó và ngay sau gói tin thứ nhất Khi đó độ lệch thời gian hai gói đến đích sẽ nhỏ hơn 20ms

Trang 21

Nếu phía nhận bỏ qua biến thiên trễ và chạy ngay đoạn âm thanh ngay khi nhận được, kết quả chất lượng âm thanh sẽ rất kém Có thể loại bỏ biến thiên trễ bằng các cách sau: Đánh số số tuần tự các gói tin, gán nhãn thời gian cho các gói tin, tạm dừng chạy.[3]

1.2.4 Băng thông

Băng thông biểu thị tốc độ truyền dữ liệu cực đại có thể đạt được giữa hai điểm kết nối hay là số lượng bít trên giây mà mạng sãn sàng cung cấp cho các ứng dụng Nếu có băng thông đủ lớn thì các vấn đền như nghẽn mạch, kỹ thuật lập lịch, phân loại, trễ chúng ta không phải quan tâm, nhưng điều này khó xảy

ra vì băng thông của mạng là có giới hạn Khi được sử dụng như một tham số của QoS, băng thông là yếu tố tối thiểu mà một ứng dụng cần có để hoạt động được, thí dụ như thoại PCM 64 kb/s cần băng thông là 64 kb/s

- Trễ hàng đợi: là thời gian gói tin phải qua trong một hàng đợi để được truyền đi trong một liên kết khác, hay thời gian cần thiết phải đợi để thực hiện quyết định định tuyến trong Bộ định tuyến Nó có thể bằng 0 hoặc rất lớn tùy thuộc vào số gói tin có trong hàng đợi và tốc độ xử lý

mang dữ liệu

tuyến khác, hay thời gian được yêu cầu để xử lý các gói đã đến trong một

Trang 22

nút Ví dụ, thời gian để kiểm tra tiêu đề gói tin và các định nút tiếp theo để gửi đi

- Trễ truyền dẫn: là thời gian để truyền tất cả các bít trong gói qua liên kết, trễ truyền được xác định thực tế trên băng thông liên kết

Các ứng dụng truyền thông đa phương tiện đòi hỏi độ trễ các gói tin nằm trong khoảng cho phép, được quy định bởi một ngưỡng cụ thể

b) Biến thiên độ trễ

Biến thiên độ trễ sự khác biệt về độ trễ của các gói khác nhau trong cùng một dòng lưu lượng Nguyên nhân chủ yếu gây ra hiện tượng biến thiên trễ do sự sai khác trong thời gian xếp hàng của các gói liên tiếp nhau trong một hàng gây

ra Biến thiên trễ là yếu tố ảnh hưởng đến QoS của truyền thông đa phương tiện,

tỷ lệ nghịch với QoS của truyền thông đa phương tiện

Trong các ứng dụng truyền thông đa phương tiện như Điện thoại internet hoặc yêu cầu của ẩm thanh, biến thiên trễ có thể được hạn chế bằng cách thực hiện kết hợp ba kỹ thuật: đánh số thứ tự các gói tin (sequence number) Người gửi đặt một đánh số thứ tự gói tin vào mỗi gói tin và có tăng giá trị này lên mỗi khi một gói tin mới được tạo ra, nhờ vậy người nhận có thể dùng đánh số thứ tự gói tin để khôi phục thứ tự đúng của các gói tin nhận được

Timestamp (dấu thời gian) tương tự như đánh số thứ tự gói tin, người gửi đánh dấu mỗi gói tin, dấu mang thông tin về thời gian mà gói tin đó được sinh ra

Để lấy được thứ tự đúng của các gói tin từ đánh số thứ tự các gói tin và dấu thời gian, người nhận cần nhận tất cả các gói tin theo thứ tự Playout delay (phát sóng trễ) được sử dụng cho mục đích này Phát lại trễ (playout delay) phải đủ dài để nhận được hầu hét các gói tin trước thời điểm chúng được sử dụng Phát lại trễ được chia làm hai loại: cố định hoặc có thể thay đổi trong thời gian hội thảo

1.2.6 Tỉ lệ mất mát gói tin

Tỉ lệ mất gói tin là tỉ số của số lượng gói tin bị mất trên tổng số gói tin đưa vào mạng trong quá trình truyền Mất gói tin thường do hai nguyên nhân chính: gói tin bị loại bỏ do mạng bị tắc nghẽn và do bị lỗi trên đường truyền Với truyền

Trang 23

thông đa phương tiện, tỉ lệ mất gói tin từ 10 – 20% có thể chấp nhận được, phụ thuộc vào tín hiệu được mã hóa và được che giấu ở phía nhận như thế nào Tuy nhiên, trong trường hợp tắc nghẽn nghiêm trọng, sự mất mát gói tin vượt quá 20%, tín hiệu ở phía đầu nhận là khó chấp nhận ví dụ như âm thanh bị ngắt quãng thậm chí không nghe được Tỉ lệ mất gói tin cao làm tăng độ trễ và biến thiên trễ

Truyền thoại và video rất nhạy cảm với việc mất gói tin, việc truyền lại gói của TCP thường không phù hợp vì khi phát hiện có sự mất gói tin, thực thể gửi TCP sẽ giảm tốc độ gửi xuống mức tối thiểu, có thể dẫn đến đứt đoạn tiếng nói Vì thế hầu hết các ứng dụng truyền thông đa phương tiện không chạy trên TCP mà lại sử dụng UDP, trong đó không có các cơ chế điều khiển tắc nghẽn và khắc phục lỗi như trong TCP

1.2.7 Một số tham số khác

a) Tính sãn sàng- độ tin cậy

Để xác định độ ổn định của hệ thống người ta thường xác định độ khả dụng của hệ thống, nhìn từ khía cạnh mạng thì nó chính là độ tin cậy của hệ thống Độ khả dụng của mạng càng cao nghĩa là độ tin cậy của mạng càng lớn và

độ ổn định của hệ thống càng lớn Độ khả dụng của mạng thường được tính trên

cở sở thời gian ngừng hoạt động và tổng thời gian hoạt động Ví dụ, độ khả dụng của các hệ thống chuyển mạch gói hiện nay là 99,995% thì thời gian ngừng hoạt động trong một năm vào khoảng 26 phút

b) Bảo mật

Bảo mật là một thông số mới trong danh sách QoS, nhưng lại là một thông

số quan trọng Thực tế, trong một số trường hợp độ bảo mật có thể được xét ngay sau băng thông Gần đây, do sự đe dọa thường xuyên của các tin tặc và sự lan tràn của vi rút trên mạng Internet toàn cầu đã làm cho bảo mật trở thành một trong các vấn đề hàng đầu

Hầu hết các công trình và chính sách bảo mật đều liên quan tới tính riêng

tư, sự tin cậy và xác thực khách và chủ Các công cụ và chính sách bảo mật

Trang 24

thường được gắn với các phương pháp mật mã (gồm cả mã hóa và giải mã) Các phương pháp mật mã cùng được sử dụng trên mạng cho việc xác thực, nhưng các phương pháp này thường không liên quan đến giải mã Hiện nay, giao thức bảo mật chính thức cho mạng IP là IPSec - Ipsecurity hỗ trợ bảo mật trong thương mại điện tử trên mạng Internet và ngăn ngừa gian lận trong môi trường truyền hình trực tuyến

Một bít trong môi trường loại dịch vụ (ToS) trong phần tiêu đề gói IP được đặt riêng cho ứng dụng đề bảo mật khi chuyển mạch gói Tuy nhiên, có một vấn đề thực tế là không có sự thống nhất giữa các nhà sản xuất bộ định tuyến khi sử dụng trường ToS

Người sử dụng và ứng dụng có thể thêm phần bảo mật của riêng mình vào mạng và thực tế cách này đã được thực hiện trong nhiều năm Nếu có bảo mật thì thường dưới dạng một mật khẩu truy nhập vào mạng Một thông số QoS bảo mật điển hình hiện nay là “Mã hóa và xác thực đòi hỏi trên tất cả các luồng lưu lượng ” Vì vậy khi truyền dữ liệu đã được mã hóa, kết nối chỉ cần xác thực để ngăn gian lận [12]

Trang 25

CHƯƠNG 2 MỘT SỐ GIAO THỨC TRUYỀN THÔNG

THỜI GIAN THỰC

2.1 GIAO THỨC STREAMING

2.1.1 Giới thiệu chung

Trong xã hội hiện đại, hệ thống truyền thông đa phương tiện qua mạng IP

sẽ trở thành một phần thiết yếu trong cuộc sống Hệ thống truyền thông này sẽ tạo thuận lợi và kinh tế to lớn cho cộng đồng trong việc nhiều lĩnh vực như giáo dục, quản lý và các dịch vụ giá trị gia tăng không chỉ trên các máy tính mà trên

cả thiết bị cầm tay Bởi vậy, công nghệ truyền thông đa phương tiện được nghiên cứu rất rộng rãi và phát triển đa dạng, trong đó công nghệ streaming đang được ứng dụng phổ biến trong nhiều lĩnh vực như giáo dục, y tế, quản lý công, giải trí

và dịch vụ giá trị gia tăng

Công nghệ Streaming cho phép các máy chủ truyền dữ liệu đa phương tiện hay dữ liệu video tới phía người dùng qua mạng IP ngay cả trong trường hợp mạng có tốc độ thấp (28.8 Kps) dựa trên việc chia nhỏ gói tin rồi gửi tới bộ đệm máy tính người dùng trước khi được phát và đồng thời tiếp tục nhận dữ liệu còn lại trong quá trình phát dữ liệu trước đó, quá trình này gọi là quá trình buffering

Công nghệ streaming được chia ra làm hai loại là Streaming video theo yêu cầu (Streaming video on demand) và Video streaming thời gian thực (Live video streaming) Video theo yêu cầu tức là các video đã được lưu trữ trên máy chủ đa phương tiện từ trước, dựa theo yêu cầu của người dùng thì hệ thống truyền dữ liệu video đó tới máy người dùng dựa trên công nghệ streaming, cũng như đáp ứng các yêu cầu của người trong quá trình xem như tua, dừng hoặc nhảy qua đoạn khác của video đó Các ứng dụng sử dụng video theo yêu cầu phổ biến như hiện nay là Youtube, Veoh và Vimeo Video streaming thời gian thực tức là

dữ liệu đa phương tiện từ máy thu (camera, microphone, TV,…) được gửi tới máy chủ đa phương tiện theo thời gian thực, và đồng thời thì máy chủ đa phương tiện truyền dữ liệu vừa nhận được đó tới máy người dùng cũng theo thời gian

Trang 26

thực Dữ liệu này không cho phép người dùng tua, dừng hoặc chuyển sang đoạn khác, nhưng máy chủ có thể thực hiện việc lưu trữ lại dữ liệu này theo yêu cầu của nhà quản lý để cung cấp video này theo yêu cầu của người dùng sau này Bởi vậy, công nghệ streaming video thời gian thực thường được ứng dụng cho hệ thống trực tuyến thời gian thực như sản phẩm của SenViet, MEGO Livestreaming, dịch vụ IPTV và Youtube

Trong những năm qua, một số giao thức streaming được nghiên cứu, xây dựng và phát triển bởi doanh nghiệp và cộng đồng Internet Với các công ty thì đưa ra các giải pháp streaming để phát triển giao thức streaming riêng họ để phục

vụ cho sản phẩm của mình mà không phổ biến, hoặc họ xây dựng môi trường lập trình sử dụng giao thức đó cho phép chúng ta phát triển ứng dụng đa phương tiện của riêng mình, chẳng hạn Microsoft dịch vụ MMS để dùng trong Windows Media RealNetworks phát triển giao thức RDT để triển khai giải pháp của mình, hay RTMP của Adobe Bên cạnh đó, cộng đồng Internet phát triển các chuẩn mở cho công nghệ streaming để cộng đồng phát triển những ứng dụng truyền thông

đa phương tiện dựa trên công nghệ streaming Các chuẩn này bao gồm giao thức RTSP, RTP, RTCP, RTMP Trong nghiên cứu của đề tài chủ yếu tập trung nghiên cứu về video streaming thời gian thực để phục vụ cho việc phát triển hệ thống truyền hình trực tuyến

2.1.2 Kiến trúc hệ thống streaming thời gian thực

Qua hình 1, Hệ thống streaming gồm hai thành phần chính là Streaming server và clients Hệ thống này được kết nối với nhau thông qua mạng IP như Internet hoặc 3G

Trong đó:

Streaming server: Đóng vai trò là một máy chủ cung cấp dung lượng lưu trữ dữ liệu của hệ thống (video, văn bản, âm thanh…), hệ thống nền và các chương trình của nhà cung cấp dịch vụ cho người dùng

Trang 27

Hình 1: Mô hình chung về hệ thống streaming thời gian thực

Clients: Là máy của người dùng để truy cập vào hệ thống streaming thời gian thực qua mạng IP Tùy theo chức năng của hệ thống mà cho phép người dùng có thể kết nối với các thiết bị ngoài như Camera, hay TV để cung cấp dữ liệu trực tuyến từ một hay nhiều nguồn khác nhau

Để mô tả rõ hơn về các thành phần trong hệ thống streaming thời gian thực, hình dưới đây đã trình bày về kiến trúc chung hệ thống video streaming như sau:

Hình 2: Kiến trúc chung hệ thống video streaming

Trang 28

Từ hình 2, Chúng ta rằng một hệ thống video streaming cũng gồm 2 thành phần chính trong quá trình video streaming của hệ thống đó là:

Máy chủ streaming: Máy chủ streaming thực hiện việc quản lý dữ liệu lưu trữ, quản lý chất lượng dịch vụ và chứa đựng các giao thức truyền thông Dữ liệu lưu trữ được nén lại để giảm kích thước gói tin, cũng như việc bảo mật Dữ liệu này có thể là video, audio, văn bản hoặc được lấy trực tiếp từ các thiết bị thu như camera, TV Trong quá trình truyền thông, máy chủ streaming thực hiện việc kiểm soát dữ liệu nhằm đảm bảo thích ứng được những thay đổi về tài nguyên trong quá trình hoạt động của hệ thống đó như việc kiểm soát lỗi, nâng cao chất lượng dữ liệu Đồng thời, máy chủ streaming cũng thực hiện nhiệm vụ quan trọng đó là xử lý dữ liệu đảm bảo sự ràng buộc về thời gian, trễ dữ liệu, các hoạt động tương tác với người dùng Bên cạnh đó, giao thức truyền thông được cài đặt trên máy chủ streaming để thực hiện việc truyền thông qua mạng IP Ngoài các giao thức trên mạng IP thì máy chủ streaming được tích hợp các giao thức phục

vụ cho hệ thống streaming đó là RTP, RTSP, RTCP, RTMP

Clients: Dữ liệu nhận được phía clients thông qua giao thức của hệ thống streaming được gửi tới thành phần quản lý chất lượng dịch vụ nhằm đảm bảo chất lượng dữ liệu cho hệ thống streaming phía người dùng Sau đó, dữ liệu này

sẽ được giải nén, giải mã để hiển thị lên thiết bị đầu cuối của người dùng Một vai trò quan trọng phía mà hệ thống phía clients thực hiện là đồng bộ dữ liệu âm thanh, hình ảnh Bên cạnh đó, các giao thức truyền thông cho streaming được cài đặt trên clients để đảm bảo quá trình truyền thông giữa clients với máy chủ streaming được trong suốt

Qua đó, chúng ta kiến trúc hệ thống video streaming được xây dựng theo theo kiến trúc client/server Tức là máy chủ đóng vai trò quản lý dữ liệu, xử lý và thực hiện giao tiếp với các clients Tùy theo chức năng yêu cầu mà mữ liệu sẽ được server quản lý gửi tới từng clients hay tất cả clients đang tham gia vào hệ thống streaming này

Trang 29

Đối với hệ thống video streaming thời gian thực thì ngoài việc nhận dữ liệu từ máy chủ streaming thì clients còn có thể thực hiện việc truyền dữ liệu thời gian thực của mình (video, audio, văn bản) tới máy chủ để máy chủ streaming thực hiện việc phân phối dữ liệu này theo yêu cầu của người dùng

Như vậy, hoạt động của hệ thống video streamng thời gian thực được mô

tả như sau:

- Tại phía clients, sau khi đã thực hiện việc kết nối với máy chủ streaming, người dùng thông qua giao diện hệ thống sẽ thực hiện việc lựa chọn các chức năng và đưa ra các yêu cầu Các yêu cầu này sẽ được gửi tới máy chủ streaming Dữ liệu đa phương tiện của clients sẽ được gửi tới máy chủ streaming

- Tại phía máy chủ streaming, nó sẽ thực hiện việc xử lý các yêu cầu của người dùng, cũng như dữ liệu để đưa ra đáp ứng phù hợp Đồng thời, máy chủ có thể tiếp nhận dữ liệu từ các clients còn lại khác đang hoạt động mạng Tiếp theo, máy chủ streaming gửi dữ liệu tới phía clients theo cơ chế streaming của hệ thống

- Tại phía clients, dữ liệu được truyền từ máy chủ streaming sẽ tới bộ đệm

và được xử lý đồng bộ để hiển thị tại phía người dùng thông qua chương trình clients được cài trên máy của người dùng [1]

2.1.3 Phân lớp giao thức trong hệ thống streaming thời gian thực

Hiện nay, bên cạnh việc kế thừa một số giao thức Internet, cộng đồng Interent đã phát triển một số giao thức cho hệ thống video streaming Tùy theo chức năng của các giao thức, các giao thức liên quan đến hệ thống video streaming được chia ra thành ba loại sau:

Giao thức lớp mạng: Các giao thức lớp này cung cấp dịch vụ mạng cơ bản như hỗ trợ về định tuyến cho gói tin của hệ thống video streaming Tức là toàn hệ thống video streming sẽ kế thừa lớp IP của mạng IP

Giao thức lớp vận chuyển: Các giao thức tại tầng này cung cấp chức năng truyền thông cho hệ thống video streaming Bên cạnh việc sử dụng giao thức

Trang 30

TCP, UDP thì hệ thống video streaming còn sử dụng giao thức RTCP và RTP để cho quá trình truyền thông streaming

Giao thức lớp điều khiển phiên: Hệ thống video streaming sử dụng giao thức RTSP thực hiện việc xác định thông điệp, cũng như các thủ tục để thực hiện điều khiển truyền thông dữ liệu đa phương tiện trong quá trình thiết lập phiên truyền

Hình 3: Mối quan hệ giữa các giao thức trong hệ thống video streaming

Minh họa như hình 3 ở trên làm rõ về mối quan hệ của các giao thức trong

ba lớp này

Qua hình 3, Chúng ta thấy rằng tại phía gửi, dữ liệu được nén lại và gửi tới lớp RTP để thực hiện việc đóng gói Gói tin này được bổ sung thông tin để cung cấp về thời gian, số thứ tự, thông tin đồng bộ Các dòng gói tin này sẽ được tiếp tục gửi tới lớp TCP/UDP Để kiểm soát các gói tin này các gói tin của RTCP, RTSP được ghép với gói tin của RTP tại lớp TCP/UPD Tiếp theo, gói tin này được gửi tới lớp IP trên mạng IP Tại phía người nhận, dữ liệu ngược lại tức là từ tầng dưới lên tầng trên của mạng IP, như từ lớp IP lên lớp TCP/UDP Quá trình bóc tách các thông tin về đồng bộ, thứ tự, thời gian để thực hiện việc hiện thị tới thiết bị đầu cuối của người dùng như TV, loa [22]

Trang 31

2.2 GIAO THỨC RTP

RTP (Realtime Transport Protocol) cung cấp những chức năng truyền tải đầu cuối đến đầu cuối phù hợp cho những ứng dụng truyền dữ liệu thời gian thực thông qua dịch vụ multicast hoặc unicast RTP không dành trước băng thông và cũng không đảm bảo chất lượng dịch vụ (QoS) cho dịch vụ thời gian thực Việc truyền tải dữ liệu được tăng thêm nhờ sử dụng giao thức điểu khiển (RTCP) để quan sát việc phân phát dữ liệu có thể ứng dụng cho những mạng mulcast lớn, và

để cung cấp những chức năng nhận dạng và điều khiển RTP và RTCP được thiết

kế độc lập với nền tảng của lớp transport và network Nhưng thông thường các ứng dụng chạy giao thức RTP ở bên trên giao thức UDP để sử dụng các dịch vụ ghép kênh (multiplexing) và kiểm tra tổng (checksum) của dịch vụ này; cả hai giao thức RTP và UDP tạo nên một phần chức năng của giao thức tầng giao vận Tuy nhiên RTP cũng có thể được sử dụng với những giao thức khác của tầng mạng và tầng giao vận bên dưới miễn là các giao thức này cung cấp được các dịch vụ mà RTP đòi hỏi Giao thức RTP hỗ trợ việc truyền dữ liệu tới nhiều đích

sử dụng phân bố dữ liệu multicast nếu như khả năng này được tầng mạng hoạt động bên dưới nó cung cấp

Một điều cần lưu ý là bản thân RTP không cung cấp một cơ chế nào đảm bảo việc phân phát kịp thời dữ liệu tới các trạm mà nó dựa trên các dịch vụ của tầng thấp hơn để thực hiện điều này RTP cũng không đảm bảo việc truyền các gói theo đúng thứ tự Tuy nhiên số thứ tự trong RTP header cho phép bên thu xây dựng lại thứ tự đúng của các gói bên phát Giao thức hỗ trợ việc sử dụng bộ trộn (Mixer) và bộ chuyển đổi (translator) ở mức RTP Có 2 chuẩn RTP là RTP 1889 phát hành vào năm 1996 và RTP 3550 được phát hành năm 2003 Chúng không khác nhau về định dạng gói tin, chỉ khác về nguyên tắc và thuật toán quản trị việc giao thức được sử dụng ra sao Một sự thay đổi lớn nhất là tăng the scalable timer algorithm cho việc tính toán khi gửi những gói RTSP theo trật tự để giảm sự truyền phát khi vượt quá tốc độ truyền phát vì nhiều thành viên tham gia vào một phiên cùng một lúc

Trang 32

2.2.1 Cấu trúc của header của RTP

Hình 4: Cấu trúc header của RTP

Các trường trong tiêu đề RTP : Version( V ) : 2 bít Trường này xác định phiên bản của RTP: Padding( P ) : 1 bít

Nếu trường padding được thiếp lập lên 1, thì gói dữ liệu chứa thêm một hay nhiều bộ 8 bít dữ liệu mở rộng Nó không phải là một phần của gói dữ liệu 8 bít cuối của phần dữ liệu bổ sung chứa tổng số octets nên bỏ qua, bao gồm chính

nó Dữ liệu bổ sung thường không được sử dụng, nhưng nó lại cần thiết trong những thuật toán mã hóa với kích thước của gói dữ liệu là cố định hoặc cần thiết cho việc mang đi nhiều gói RTP trong một đơn vị dữ liệu giao thức lớp dưới

a) Extension( X ) : 1 bít

RTP cho phép một phần header mở rộng được báo hiệu bằng bít X trong header RTP Khi bít X được đặt là 1, sau phần header cố định của RTP và trước phần dữ liệu của gói sẽ có một header mở rộng với định dạng riêng, chiều dài của header này không cố định nhưng đều bắt đầu bằng 16 bít chỉ kiểu và 16 bít chỉ chiều dài (không bao gồm 32 bít này), cho phép các ứng dụng có thể loại bỏ nếu không đọc được thông tin trong header này

Header mở rộng này được cung cấp khi ứng dụng cần nhiều thông tin hơn những gì có trong header cố định của RTP Chúng rất ít khi được sử dụng Thông

Trang 33

thường thay vì sử dụng header mở rộng, chúng ta sẽ lưu các thông tin bổ sung bên trong phần dữ liệu của gói như là một header của phần dữ liệu

b) CSRC count( CC ) : 4 bít

Trường CSRC count chứa số lượng CSRC theo sau header

c) Marker( M ) : 1 bít

Bít đánh dấu Marker trong header của RTP được sử dụng để đánh dấu các

sự kiện trong một luồng media, giá trị của nó quyết định bởi đặc tả RTP và định dạng media được sử dụng

Đối với các luồng dữ liệu audio sử dụng đặc tả RTP cho dữ liệu audio và video với cấu hình tối thiểu, bít Marker được đặt là 1 khi gói đầu tiên được gửi sau một khoảng lặng, còn lại được đặt là 0 Bít Marker được đặt là 1 là dấu hiệu cho các ứng dụng biểt được lúc nào nên điều chỉnh thời lượng chơi bởi một chút thay đổi trong độ dài khoảng lặng thường người nghe khó nhận ra

Đối với các luồng dữ liệu video sử dụng đặc tả RTP cho dữ liệu audio và video với cấu hình tối thiểu, bít Marker được đặt là 1 khi đó là gói cuối cùng chứa dữ liệu của một frame video, các gói khác được đặt bằng 0 Bít Marker được đặt là 1 là dấu hiệu cho các ứng dụng biết thời điểm nào bắt đầu giải mã frame đó thay vì chờ đợi một gói có timestamp khác (cũng là một cách nhận biết)

để xác định dữ liệu đầy đủ cho một frame

Trong mọi trường hợp, bít Marker chỉ là dấu hiệu cho các ứng dụng Với luồng audio, thông thường có thể nhận biết điểm kết thúc của một khoảng lặng nhờ mối quan hệ giữa sequence number và timestamp thay đổi Điểm bắt đầu của một frame video có thể được phát hiện bởi sự thay đổi timestamp Một ứng dụng

có thể sử dụng các nhận biết này để hoạt động tốt nhưng làm giảm khả năng thi hành nếu gói chứa bít Marker bị mất

d) Payload type (PT) : 7 bít

Chỉ định loại media nào được truyền đi trong các gói RTP Các ứng dụng bên nhận kiểm tra trường này để quyết định cách thức xử lý dữ liệu

Trang 34

Tất cả các định dạng dữ liệu đều được đăng ký theo chuẩn MIME (MIME type registration) Các định dạng mới hơn được định nghĩa trong đặc tả của chúng; Một nhóm đăng ký cho các định dạng cũ hơn đang được phát triển

Hình 5: Khởi tạo phiên

Dù kiểu dữ liệu được chỉ định là tĩnh hay động, điều cần thiết là phải mô

tả được phiên hiện thời tới ứng dụng sao cho ứng dụng đó hiểu được những loại

dữ liệu nào đang được sử dụng Một trong các giao thức dùng để mô tả phiên đó

là SDP (Session Description Protocol) Một ví dụ về một bản ghi SDP như hình 5

Ví dụ trên mô tả 2 phiên RTP, audio được gửi loopback 127.0.0.1 qua cổng 1230, Time-To-Live là 127, video được gửi tới cùng nhóm multicast nói trên qua cổng 1232 Cả audio và video đều sử dụng giao thức RTP/AVP làm giao thức chuyển vận Audio được mã hóa dạng MPEGA, còn video được mã hóa theo chuẩn H.264

e) Sequence number : 16 bít

Là số không dấu 16 bít dùng để phân biệt các gói,và được dùng để sắp xếp gói theo đúng trật tự ở phía thu và phát hiện mất gói Tuy nhiên nó không được dùng để đặt lịch playout của các gói tin

Giá trị của số thứ tự được khởi đầu ngẫu nhiên để tăng tính bảo mật của dòng dữ liệu (khó cho các cuộc tấn công khi không biết phiên bắt đầu từ gói nào)

Trang 35

Giá trị của số thứ tự tăng lên 1 sau mỗi gói và khi giá trị của số thứ tự tăng tới giá trị tối đa (65535) thì trở về 0 Và giá trị của số thứ tự tăng đều liên tục không nhảy lại phía sau trừ trường hợp quay vòng (wrap-around)

Tùy theo ứng dụng người ta có thể dùng thêm số thứ tự mở rộng theo công thức sau: extended_sequence_number = sequence_number + (65535 * wrap_around_count)

Nhãn thời gian không phải là duy nhất trong 1 phiên, 2 gói dữ liệu khi có cùng nhãn thời gian có nghĩa là chúng có cùng thời gian lấy mẫu Cụ thể hơn, trong trường hợp truyền 1 khung video có kích thước lớn, khung sẽ chia thành các mảnh nhỏ hơn và được đóng trong các gói có số thứ tự khác nhau nhưng có cùng nhãn thời gian

Hình 6 : Phân mảnh dữ liệu

RTP

header Payload header Payload

data

Timestamp Nén frame đa phương tiện

Frame nguyên bản với timestamp

Mảnh khung phù hợp với mạng MTU Mỗi mảnh có nhãn thời gian

Tạo ra các gói RTP Nhãn thời gian tạo thành một phần tiêu đề và thêm payload header mô tả mảnh

Trang 36

g) SSRC

Được sử dụng để đi ̣nh danh các bên tham gia trong mô ̣t phiên RTP Giá tri ̣

củ a nó chỉ có ý nghĩa trong mô ̣t phiên và được ánh xạ tới một định danh phiên (long-lived canonical name) CNAME thông qua giao thức điều khiển RTCP

SSRC là một số nguyên 32 bít có giá trị ngẫu nhiên được chọn bởi các bên tham gia khi tham gia vào phiên Bởi SSRC được chọn ngẫu nhiên từ phía host

đô ̣t kiểu như vâ ̣y có thể được phát hiê ̣n khi mô ̣t ứng du ̣ng nhâ ̣n được một gói từ

một bên tham gia khác có số SSRC trùng với số SSRC của nó, phương pháp phát hiện xung đột này đảm bảo SSRC là duy nhất cho mỗi bên tham gia trong một phiên

Tất cả các gói có cùng SSRC tạo, bên nhận cần phải nhóm các gói theo SSRC để thực hiện quá trình playback Nếu một bên tham gia nào đó tạo ra nhiều luồng media trong một phiên RTP thì với mỗi luồng sẽ phải có một số SSRC khác nhau để các bên nhận có thể phân biệt gói nào thuộc luồng nào

h) CSRC

Trong các trường hợp thông thường, các gói RTP được tạo ra chỉ bởi một nguồn duy nhất, nhưng khi có nhiều luồng RTP đi qua một bộ mixer hoặc translator, các dữ liệu từ nhiều nguồn này có thể được góp vào một gói RTP Trong danh sách CSRC chứa thông tin của các bên tham gia có dữ liệu nằm trong gói RTP nhưng không chứa các thông tin liên quan đến thời gian và đồng bộ Mỗi mã nhận dạng nguồn là một số nguyên 32 bít mang thông tin chính là SSRC của bên tham gia có dữ liệu nằm trong gói Chiều dài của danh sách CSRC được chỉ định trong trường CC của RTP Header

Các gói chứa danh sách CSRC được tạo ra bởi bộ RTP Mixer, khi nhận được một gói chứa danh sách CSRC, các số SSRC sẽ được sử dụng để nhóm các gói và xử lý một cách bình thường và mỗi CSRC được thêm vào danh sách các bên tham gia đã biết Mỗi bên tham gia xác định bởi một CSRC sẽ có một luồng giao thức điều khiển gói RTP tương ứng mang đầy đủ thông tin về bên tham gia

Trang 37

2.2.2 Ghép kênh RTP

Trong RTP, việc ghép kênh được cấp bởi địa chỉ lớp transport đích (địa chỉ lớp mạng và port) chúng khác nhau cho mỗi phiên RTP Ví dụ, cuộc hội thảo gồm audio và video media được mã hóa riêng biệt, mỗi môi trường nên được mang vào phiên RTP riêng với địa đích riêng

Những dòng audio và video riêng không nên mang trên một phiên RTP đơn lẻ và được phân kênh dựa vào trường Payload type hoặc SSRC Các gói xen

kẽ với những loại thiết bị sử dụng RTP khác nhau nhưng có cùng SSRC sẽ tạo ra nhiều vấn đề :

1 Nếu 2 dòng audio cùng dùng chung một phiên RTP và cùng giá trị SSRC,

và khi 1 trong số chúng thay đổi mã hóa và có định dạng RTP payload type khác nhau, sẽ không có cách nào để xác định dòng nào đã thay đổi mã

2 Một SSRC được định nghĩa để xác định sequence number và thời gian của mỗi dòng riêng Việc xen kẽ nhiều loại payload type có timing space khác nhau (nếu tốc độ của đồng hồ khác nhau) và sequence number khác nhau để tính loại này mất gói

3 RTP sender và receiver reports có thể chỉ miêu tả 1 một timing và sequence number space trên một SSRC và không mang trường payload type

4 RTP mixer sẽ không có khả năng kết hợp những dòng xen kẽ không hợp nhau vào thành một luồng

Việc sử dụng một SSRC cho mỗi môi trường nhưng gửi chúng trong cùng

1 phiên RTP giống nhau sẽ tránh được 3 vấn đề đầu tiên nhưng không tránh được

2 vấn đề cuối cùng

2.2.3 Mở rộng Header cho RTP

Một phương thức mở rộng cho phép những thực thi riêng thí nghiệm với những chức năng định dạng payload độc lập mới yêu cầu thông tin thêm vào để được mang đi trong gói dữ liệu header của RTP Phương thức này được thiết kế,

Trang 38

do vậy phần header mở rộng này cũng có thể bị bỏ qua bởi những thực thi tương tác khác không được mở rộng

Hình 7: Mở rộng header của RTP

Nếu bít X trong header của RTP là 1, một đoạn header mở rộng có chiều dài không cố định phải được gắn vào cuối của header RTP, sau danh sách CSRC Header mở rộng trường 16 bít chứa tổng số lượng từ 32 bít trong phần mở rộng, trừ 4 octet của header mở rộng Chỉ có những header mở rộng đơn mới được gắn tới cuối của header RTP Để cho phép những thực thi tương tác nhiều thành phần tới mỗi thí nghiệm độc lập với những header mở rộng khác nhau, hoặc có phép một thực thi riêng thí nghiệm với nhiều hơn một loại header mở rộng, thì 16 bít đầu của header mở rộng để mở cho những thông số riêng [6], [7], [14], [21]

2.3 GIAO THỨC RTCP

2.3.1 Giao thức điều khiển luồng RTCP

Giao thức điều khiển RTCP gửi các thông tin phản hồi từ bên nhận một cách tuần hoàn, các thông tin đó bao gồm phản hồi về chất lượng, xác nhận các bên tham gia, thông tin mô tả nguồn, cảnh báo về sự thay đổi về các thành viên trong phiên, và các thông tin về đồng bộ các luồng Cấu trúc của gói điều khiển RTP được thể hiện trong Hình 8

Trang 39

Hình 8: Cấu trúc RTCP

a) Version (V): 2 bít

Kích thước 2 bít luôn có giá trị bằng 2 thể hiện phiên bản của RTP Do hiện chưa có kế hoạch cho việc phát triển các phiên bản tiếp theo và các phiên bản cũ không còn sử dụng rộng rãi Thường được sử dụng để kiểm tra tính hợp lệ của gói

b) Padding (P): 1 bít

Bít P được đặt bằng 1 khi có một hay nhiều octet được bổ sung vào cuối gói, octet cuối cùng lưu thông tin về số lượng octet được bổ sung Mục đích sử dụng tương tự như trong gói RTP Sử dụng sai bít P có thể gây ảnh hưởng tới hoạt động của giao thức RTCP

c) Item count (IC): 5 bít

Một số kiểu gói RTCP chứa một danh sách các phần tử Trường này được

sử dụng để chỉ số lượng phần tử được đặt trong gói Số phần tử tối đa là 31, nếu cần hơn 31 phần tử thì cần tạo ra nhiều gói RTCP IC có thể bằng 0, nghĩa là gói không chứa phần tử nào Các kiểu gói không sử dụng đến số lượng phần tử có thể dùng trường này vào mục đích khác

d) Thể loại của gói (PT): 8 bít

Chỉ định kiểu thông tin chứa trong gói Có 5 kiểu gói chuẩn được định nghĩa trong đặc tả của RTP Các kiểu khác có thể được định nghĩa trong tương lai

e) Chiều dài (length): 16 bít

Định dạng
Số trang	79
Dung lượng	1,98 MB