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

LÊ ANH VIỆTMỘ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 T

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

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

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

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ầygiá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ìnhthự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ìnhnghiên cứu, học tập, các thầy cô trong ban chủ nhiệm lớp CHK12G, những ngườirấ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âncủa tôi, những người đã ủng hộ, khuyến khích tôi rất nhiều trong quá trình họctậ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

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.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

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

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

ISP Internet Service Provider Nhà cung cấp dịch vụ Internett

RSVP Resource Revervation Protocol Giao thức dành trước tài nguyên

TCP Transmission Control Protocol Giao thức điều khiển truyền dẫn

UDP User Datagram Protocol Giao thức bản tin người sử dụng

PSTN Public Switched telephone Network Mạng điện thoại chuyển mạch

công cộngISDN Integrated Services Digital Network Mạng số tích hợp đa dịch vụMCU Multipoint Control Unit Hội nghị truyền hình đa điểm

RTP Realtime transport protocol Giao thức truyền tải thời gian thực

RTCP Realtime Transport Control Protocol Giao thức điều khiển truyền tải

thời gian thực

ITU-T Telecommunication Standardization

MMS Microsoft Media Services Dịch vụ đề dùng trong Windows

MediaRDT Real Network Data Transport

SSRC Synchronization Source

SDP Session Description Protocol

MPEG Moving Picture Experts Group

IPv4 Internet Protocol Version 4 Giao thức internet phiên bản 4IPv6 Internet Protocol Version 4 Giao thức internet phiên bản 6FMS Flash Media Server 2.0

PDA Personal Digital Assistant Thiết bị kỹ thuật số hỗ trợ cá nhânIPTV Internet Protocol Television Truyền hình giao thức InternetRTSP Real Time Streaming Protocol

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 19: C1 và S1 bít 40

Hình 20: C2 và S2 bít 41

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

Hình 26: Giao diện chương trình sau khi chạy 50Hì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 55Hì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 56Hì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ềnthông đa phương tiện thời gian thực qua mạng IP 57Hình 30: Giao diện thống kê danh sách người dùng 58Hình 31: Quá trình truyền dữ liệu đa phương tiện từ phía clients tới streaming server 59Hình 32: Quá trình nhận dữ liệu đa phương tiện từ streaming server về clients 60Hì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

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ầngmạng viễn thông đã tạo thuận lợi cho nhà khoa học nghiên cứu và triển khainhiề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ứctruyề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ạngInterent 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ựctuyế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ụngtruyền thông khi hoạt động trên mạng Internet Đối với hệ thống truyền hình trựctuyế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ựctuyến trên mạng Bởi vậy, chủ đề nghiên cứu về giao thức truyền thông thời gianthực luôn được cộng đồng khoa học quan tâm nghiên cứu nhằm cải tiến để khắcphụ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ựcnhư H323, RTP (Real Time Protocol), RTCP (Real-time Transport ControlProtocol), 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]

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

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

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

cá nhân.

Hội nghị truyền hình là công nghệ đa phương tiện cho phép người sửdụng nghe và nhìn thấy nhau, trao đổi dữ liệu và cùng nhau chế biến chúng trongchế độ tương tác nhờ sử dụng những khả năng của máy vi tính đã quen thuộc vớitất cả mọi người Để làm được điều đó nhất thiết phải có hai điều kiện cực kỳquan trọng:

- Trong máy tính của bạn phải cài đặt card liên kết hội nghị truyền hình với phần mềm tương ứng

- Bạn cần phải có khả năng kết nối với đồng nghiệp hoặc là qua mạng máy 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ềucá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àocũng ứng dụng được Hiện nay có lẽ hiếm các cơ quan nào mà các máy tínhkhô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ộinghị 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àngchụ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

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ủachú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ênhxuấ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ốngtí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úngyê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ấtkhó đạ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ắmvà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ínniệ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íabê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áctiệ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 đảmbả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ămgầ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 IPnhư 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àncầ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 nayhộ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]

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 gianthự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ảnphẩ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ựcnhư 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à giaodiệ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ụ choviệ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 quamạ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ànhplug-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ênnhiều môi trường như Internet Explorer, Firefox, Safari và các ngôn ngữ khácnhau 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 khimuố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 đó

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ượngdị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 đảmbả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ớimộ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à độ tincậ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 chocá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 để duytrì 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êuchuẩ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 phimtrực tuyến, VoIP, được truyền trên mạng thì quá trình phát và nhận theo thờigian 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ượngdịch vụ ATM là một giao thức được thiết kế để có thể triển khai thực hiện đảmbả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ụngmạ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ànhtrê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ựatrên hai quan điểm sau: chất lượng dịch vụ theo quan điểm đánh giá của người sử

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ụ đảmbá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ínhbả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 đặcbiệ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êucầ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ỳ đó, trongcá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ấpkhả năng xử lý ưu tiên cho các gói tin Chúng không đủ để đáp ứng các yêu cầucủ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 tinkhi chúng di chuyển từ nguồn đến đích như:

- Trễ: Do Bộ định tuyến phải tìm kiếm trong bảng định tuyến, do thời giangói tin truyền trên đường truyền

- Biến thiên độ trễ: Chủ yếu do các gói tin phải chờ ở bộ đệm của các Bộđịnh tuyến để được chuyển tiếp hoặc phát lại do bị mất Các dữ liệu trongdạng âm thanh bị ảnh hưởng nhiều bởi vấn đề này

- Mất gói tin: Chủ yếu do tắc nghẽn trong mạng chất lượng truyền tải quamạ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

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ấtgó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ổngquá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 tintạ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ổngquá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ảithuậ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 tincủ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ểnmỗ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ácgó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 raviệ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ênkhông thích hợp cho sự phát triển các ứng dụng đa phương tiện trên Internet Tuynhiên, chúng đã được sử dụng phổ biến trên Internet ngay từ khi Internet mớihì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ảiphá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ạnchế, đò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ụngtruyề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

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ượngcủ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ệnthoại Internet Nó được đóng gói trong một IP datagram và IP datagram đượcchuyể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à coinhư 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 gianthự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 âmthanh 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ênUDP 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óitin từ 1% tới 20% là có thể chấp nhận được, phụ thuộc vào cách âm thanh đượcné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íanhận như thế nào Cơ chế sửa lỗi FEC có thể được dùng để che đậy sự mất góitin 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

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 ứngdụng tương tác thời gian thực như điện thoại Internet, độ trễ toàn trình nhỏ hơn150ms đượ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ếnthiê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 ứngdụng điện thoại Internet Phía gửi phát gói tin thứ 2 sau gói tin đầu 20ms Nhưngtạ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ặcnhỏ hơn 20ms Chúng ta có thể thấy rõ hơn như sau: Giả sử gói tin đầu tiên tớikhi hàng đợi Bộ định tuyến hầu như là rỗng, nó sẽ được truyền đi ngay, nhưngtrướ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ộtkhoảng thời gian nhất định trước khi được chuyển tiếp Như vậy rõ ràng hai góitin 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ặcnhiề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ầunhư 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

Nếu phía nhận bỏ qua biến thiên trễ và chạy ngay đoạn âm thanh ngay khinhậ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óitin, 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ậtlậ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ủaQoS, 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 để đượctruyền đi trong một liên kết khác, hay thời gian cần thiết phải đợi để thựchiện quyết định định tuyến trong Bộ định tuyến Nó có thể bằng 0 hoặc rấtlớn tùy thuộc vào số gói tin có trong hàng đợi và tốc độ xử lý

- Trễ truyền lan: là thời gian cần thiết để môi trường vật lý truyền tín hiệumang dữ liệu

- Trễ chuyển tiếp: là thời gian để chuyển gói tin từ một tuyến này sang mộttuyến khác, hay thời gian được yêu cầu để xử lý các gói đã đến trong một

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ằmtrong 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ùngmộ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 internethoặ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ựchiện kết hợp ba kỹ thuật: đánh số thứ tự các gói tin (sequence number) Ngườigử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ỗikhi 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ờigian, người nhận cần nhận tất cả các gói tin theo thứ tự Playout delay (phát sóngtrễ) đượ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 đưavà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

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 Tuynhiê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ắtquãng thậm chí không nghe được Tỉ lệ mất gói tin cao làm tăng độ trễ và biếnthiê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ạigó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ếngnó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ênTCP 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ụngcủ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 ngaysau 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ự lantrà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ộttrong 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

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ácphươ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ácphương pháp này thường không liên quan đến giải mã Hiện nay, giao thức bảomật chính thức cho mạng IP là IPSec - Ipsecurity hỗ trợ bảo mật trong thươngmại điện tử trên mạng Internet và ngăn ngừa gian lận trong môi trường truyềnhì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ếnkhi 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àomạ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ưulượ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]

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

THỜI GIAN THỰC2.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áodụ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êncứ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ươngtiện hay dữ liệu video tới phía người dùng qua mạng IP ngay cả trong trường hợpmạ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ộ đệmmá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ònlạ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 theoyêu cầu (Streaming video on demand) và Video streaming thời gian thực (Livevideo streaming) Video theo yêu cầu tức là các video đã được lưu trữ trên máychủ đa phương tiện từ trước, dựa theo yêu cầu của người dùng thì hệ thốngtruyền dữ liệu video đó tới máy người dùng dựa trên công nghệ streaming, cũngnhư đáp ứng các yêu cầu của người trong quá trình xem như tua, dừng hoặc nhảyqua đoạn khác của video đó Các ứng dụng sử dụng video theo yêu cầu phổ biếnnhư 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ớimáy chủ đa phương tiện theo thời gian thực, và đồng thời thì máy chủ đa phươngtiệ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

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ạnkhá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ầucủ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ởivậ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, MEGOLivestreaming, 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âydự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ậptrình sử dụng giao thức đó cho phép chúng ta phát triển ứng dụng đa phương tiệncủa riêng mình, chẳng hạn Microsoft dịch vụ MMS để dùng trong WindowsMedia 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ứcRTSP, RTP, RTCP, RTMP Trong nghiên cứu của đề tài chủ yếu tập trungnghiê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à Streamingserver 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ưutrữ dữ liệu của hệ thống (video, văn bản, âm thanh…), hệ thống nền và cácchương trình của nhà cung cấp dịch vụ cho người dùng

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ờigian thực qua mạng IP Tùy theo chức năng của hệ thống mà cho phép ngườidù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 gianthự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

Từ hình 2, Chúng ta rằng một hệ thống video streaming cũng gồm 2 thànhphầ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ưutrữ, 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ệulư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ệunà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ệckiểm soát dữ liệu nhằm đảm bảo thích ứng được những thay đổi về tài nguyêntrong quá trình hoạt động của hệ thống đó như việc kiểm soát lỗi, nâng cao chấtlượng dữ liệu Đồng thời, máy chủ streaming cũng thực hiện nhiệm vụ quantrọ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 đặttrên máy chủ streaming để thực hiện việc truyền thông qua mạng IP Ngoài cácgiao 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ốngstreaming được gửi tới thành phần quản lý chất lượng dịch vụ nhằm đảm bảochấ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ộtvai trò quan trọng phía mà hệ thống phía clients thực hiện là đồng bộ dữ liệu âmthanh, 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 theotheo 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

Đố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ờigian thực của mình (video, audio, văn bản) tới máy chủ để máy chủ streamingthự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ácchứ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áychủ 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ủangười dùng, cũng như dữ liệu để đưa ra đáp ứng phù hợp Đồng thời, máychủ có thể tiếp nhận dữ liệu từ các clients còn lại khác đang hoạt độngmạ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ươngtrì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 đồngInterent đã phát triển một số giao thức cho hệ thống video streaming Tùy theochức năng của các giao thức, các giao thức liên quan đến hệ thống videostreaming đượ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ảnnhư 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ăngtruyền thông cho hệ thống video streaming Bên cạnh việc sử dụng giao thức

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 giaothứ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êntruyề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ửitớ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ẽ đượctiế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ìnhbó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ớithiết bị đầu cuối của người dùng như TV, loa [22]

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ựcthô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ệctruyề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ả haigiao 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ầngmạ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ácdị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 đảmbả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ủatầ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ácgói theo đúng thứ tự Tuy nhiên số thứ tự trong RTP header cho phép bên thu xâydự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 1889phát hành vào năm 1996 và RTP 3550 được phát hành năm 2003 Chúng khôngkhá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ệcgiao thức được sử dụng ra sao Một sự thay đổi lớn nhất là tăng the scalable timeralgorithm 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ộtphiên cùng một lúc

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 địnhphiê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ộthay 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 8bí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 trongnhữ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ếtcho 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 trongheader RTP Khi bít X được đặt là 1, sau phần header cố định của RTP và trướcphầ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ủaheader 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ếukhô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ơnnhững gì có trong header cố định của RTP Chúng rất ít khi được sử dụng Thông

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à địnhdạ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ửisau 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ệucho 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útthay đổ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ùngchứ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ớiluồ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ặngnhờ mối quan hệ giữa sequence number và timestamp thay đổi Điểm bắt đầu củamộ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 thihà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ụngbên nhận kiểm tra trường này để quyết định cách thức xử lý dữ liệu

Tất cả các định dạng dữ liệu đều được đăng ký theo chuẩn MIME (MIMEtype registration) Các định dạng mới hơn được định nghĩa trong đặc tả củachú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 quacổng 1230, Time-To-Live là 127, video được gửi tới cùng nhóm multicast nóitrên qua cổng 1232 Cả audio và video đều sử dụng giao thức RTP/AVP làm giaothức chuyển vận Audio được mã hóa dạng MPEGA, còn video được mã hóatheo 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ếpgói theo đúng trật tự ở phía thu và phát hiện mất gói Tuy nhiên nó không đượcdù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ủadò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)

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ăngtớ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ụckhô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 theocô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ànhcá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

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

header data

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

(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êntham gia khi tham gia vào phiên Bởi SSRC được chọn ngẫu nhiên từ phía hostnên sẽ có thể xảy ra trường hợp 2 bên tham gia có cùng giá trị nay Nhưng xungđôt kiểu như vây co thê đươc phat hiên khi môt ưng dung nhân đươc một goi tưmôt bên tham gia khac co sô SSRC trung vơi số SSRC của nó, phương pháp pháthiện xung đột này đảm bảo SSRC là duy nhất cho mỗi bên tham gia trong mộtphiê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 theoSSRC để thực hiện quá trình playback Nếu một bên tham gia nào đó tạo ra nhiềuluồng media trong một phiên RTP thì với mỗi luồng sẽ phải có một số SSRCkhá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ộtnguồn duy nhất, nhưng khi có nhiều luồng RTP đi qua một bộ mixer hoặctranslator, 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 tronggó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à SSRCcủa bên tham gia có dữ liệu nằm trong gói Chiều dài của danh sách CSRC đượcchỉ đị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ácgó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ácbên tham gia đã biết Mỗi bên tham gia xác định bởi một CSRC sẽ có một luồnggiao thức điều khiển gói RTP tương ứng mang đầy đủ thông tin về bên tham gia

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ảogồm audio và video media được mã hóa riêng biệt, mỗi môi trường nên đượcmang 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 ranhiề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ácnhau, 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 giancủa mỗi dòng riêng Việc xen kẽ nhiều loại payload type có timing space khácnhau (nếu tốc độ của đồng hồ khác nhau) và sequence number khác nhau để tínhloạ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ợpnhau 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ớinhữ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ế,