Tải bản đầy đủ - 0 (trang)
CHƯƠNG 2. CƠ SỞ LÝ THUYẾT

CHƯƠNG 2. CƠ SỞ LÝ THUYẾT

Tải bản đầy đủ - 0trang

Một số lợi ích của WebRTC :

• Miễn phí: WebRTC là một dự án mã nguồn mở được được Google giới thiệu







trong năm 2011. Mục đích của Google là cung cấp một công cụ truyền thông thời

gian thực dựa trên tiêu chuẩn là miễn phí và có sẵn trên tất cả các trình duyệt.

Hỗ trợ mọi nền tảng thiết bị: Bất kì trình trình duyệt nào với hệ điều hành bất kì







có thể tạo trực tiếp một real-time voice hoặc video kết nối tới thiết bị WebRTC

khác.Lập trình viên có thể viết các đoạn mã HTML làm việc với máy tính hoặc

thiết bị di động.

An tồn trong voice và video [2]: WebRTC sử dụng giao thức SRTP (Secure







Real Time Communication) nhằm mục đích mã hóa và xác thực dữ liệu

media.Điều này tránh được việc nghe trộm khi người dùng thực hiện các tác vụ

media như là video hay voice.

Không Plugins : Như đề cập ở trên WebRTC cần phải cài các plugin của bên thức







ba để sử dụng các ứng dụng đa phương tiện.Việc làm làm cho ứng dụng đa phương

tiện còn phải phụ thuộc vào các nền tàng khác nhau.Với WebRTC thì khơng cần

quan tâm đến vấn đề này.

Dễ sử dụng: Có thể tích hợp các tính năng của WebRTC trong các dịch vụ web







bằng cách sử dụng JavaScript APIs,những Framework có sẵn.

Thích ứng với các điều kiện mạng khác nhau [2]:WebRTC hỗ trợ việc thương

lượng với nhiều kiểu media và các thiết bị đầu cuối khác nhau. Điều này các ứng

dụng tương tác video hoặc gọi thoại của chúng ta sử dụng băng thông hiệu quả

hơn.Các APIs WebRTC và signaling có thể thỏa thuận kích thức và định dạng cho

môi thiết bị đầu cuối.



2.1.3. Các giao thức trong WebRTC

Do các đặc điểm cần thời gian thực cao hơn tính tin cậy, giao thức UDP được sử dụng

trong WebRTC là giao thức vận chuyển.Nhưng để thỏa mãn yêu cầu của trình duyệt phải hỗ

trợ giao thức và dịch vụ ở lớp khác nữa.Về cơ bản các giao thức chính sử dụng trong

WebRTC được thể hiện ở hình dưới:



Hình 2.1 Protocol stack trong WebRTC [3]



13



SRTP

SRTP (Secure Real Time Protocol) [4] được sử dụng để mã hóa và chuyển các gói tin

media giữa các WebRTC client.Sau khi thiết lập thành công PeerConnection,kết nối SRTP sẽ

được thiết lập giữa các trình duyệt và máy chủ.Với dữ liệu non-audio hay video, SRTP không

được sử dụng, thay vào đó là SCTP.

SCTP

WebRTC sử dụng SCTP (Stream Control Tranmission Protocol) [5] để truyền dữ liệu

non-media giữa các peer. Giao thức SCTP là giao thức vận chuyển tương tự như TCP và

UDP,có thể chạy trực tiếp trên giao thức IP. SCTP được lựa chọn do có những tính năng tốt

của TCP và UDP như message-oriented transmission, khả năng cấu hình tùy biến tính tin cậy

và thứ tự gói tin, có cơ chế quản lý lưu lượng và chống nghẽn.

DTLS

Datagram Transport Layer Security- DTLS [6] giao thức này cung cấp tính năng bảo

mật và tồn vẹn dữ liệu. Tất cả các dữ liệu truyền P2P đều được bảo mật sử dụng DTLS.

STUN

NAT [7] cung cấp một địa chỉ IP để sử dụng trong mạng nội bộ. Nhưng địa chỉ này

khơng được sử dụng bên ngồi mạng. Khơng biết địa chỉ cơng khai sẽ khơng có cách nào để

hai Peer có thể tương tác. Để giải quyết vấn đề đó WebRTC sử dụng STUN (Session Traversal

Utilities for NAT) [8]. STUN server tồn tại trên mạng internet và chỉ có nhiệm vụ duy nhất là

kiểm tra địa chỉ IP và cổng của yêu cầu vừa đến và gửi trở lại IP và cổng đó.Các ứng dụng sử

dụng STUN server để cung cấp IP và cổng công khai từ internet. Từ đó một WebRTC peer có

thể tự lấy được địa chỉ IP và cổng cơng khai và đưa nó cho các peer khác thơng qua cơ chế

signaling (tìm hiểu ở phần 2.1.4).Hình bên dưới mơ tả về cách làm việc của STUN server:



Hình 2.2 Mơ tả cách thức hoạt động của STUN

Trong đa số trường hợp chỉ cần dùng STUN để thiết lập kết nối P2P , trừ trường hợp

Peer đứng sau symmetric NAT hoặc post-restricted NAT. Trường hợp này sẽ không thành

công, cần phải sử dụng đến TURN được giới thiệu tiếp theo



14



TURN

Traversal Using Relays around NAT (TURN) [9]. Được xây dựng nhằm vượt qua

symmetric NAT bằng cách mở một kết nối tới TURN server và đáp lại tất cả thông tin thông

qua server này (dữ liệu audio/video/data streaming giữa các peer, không phải signaling

data).Turn server làm được điều này vì nó có một public địa chỉ, vì thế nó có thể liên lạc với

các peer thậm chí peer có tường lửa hoặc proxy đứng sau. Hình dưới mơ tả hoạt động của

TURN server.



Hình 2.3 Mơ tả cách thức hoạt động của TURN

SDP

Session Description Protocol [10] là một chuẩn mô tả các thông số của mỗi kết nối

như là độ phân giải, định dạng, codecs, mã hóa… Điều này làm cho mỗi peer có thể hiểu nhau

khi dữ liệu được truyền. Đây thực chất là meta-data miêu tả nội dung chứ không phải là dữ

liệu media.

ICE

Interactive Connectivity Establishment [11] là một chuẩn được sử dụng để thiết lập kết

nối giữa các các peer trên internet.Mặc dù WebRTC là kết nối trực tiếp Peer-to-Peer, nhưng

thực tế nó vẫn gặp phải vấn đề NAT (Network Address Translation) gây khó khăn khi kết

nối.ICE sẽ cố gắng thiết lập kết nối bằng cách tìm đường đi tốt nhất cho kết nối.Bằng cách

thử hết các khả năng song song nhau, ICE có thể chọn ra được lựa chọn hiệu quả nhất cho kết

nối. Đầu tiên ICE cố gắng kết nối sử dụng địa chỉ host lấy được từ hệ điều hành hoặc card

mạng. Nếu thất bại nó sẽ lấy địa chỉ IP public thơng qua STUN server.Nếu vẫn thất bại, lưu

lượng được gửi thông qua TURN server. Các cách để kết nối này được gọi là “candidate”,

cách thức trao đổi sẽ được mô tả ở các phần bên sau.



2.1.4. Một số kiến trúc của hệ thống WebRTC

Kiến trúc của một ứng dụng web cơ bản khá đơn giản.Vận chuyển thông tin giữa

browser và web server chúng ta sử dụng HTTP chạy trên giao thức TCP hoặc có thể nâng cao



15



hơn là trên Websocket. Thơng tin được đặt trong các đoạn mã Hyper-Text Markup Language,

HTML. Các đoạn mã này có thể bao gồm Javascript và Cascading Style Sheets (CSS).

Trường hợp phổ biến là browser gửi một yêu cầu HTTP tới webserver, tiếp đó server sẽ xử lý

yêu cầu mà browser cung cấp và đáp lại yêu cầu đó tới browser. Trong một số trường hợp

phức tạp khác là server gửi server gửi Javascript chạy trên browser.Server sẽ tương tác với

browser thơng qua APIs còn lại người dùng sẽ tương tác với browser thông qua các sự kiện.

Browser trao đổi thông tin với server thông qua HTTP mở hoặc WebSocket .



Hình 2.4 Kiến trúc của hệ thống web truyền thống



WebRTC có sự khác biệt với mơ hình truyền thống là sử dụng P2P giữa các trình

duyệt. Mặc dù sử dụng mơ hình P2P xong cái ứng dụng WebRTC vẫn cần một server đứng

trung gian để có trao đổi các thơng tin cần thiết để hai trình duyệt có thể kết nối với nhau.

Server này được gọi là signaling server, nó cần phải là một với chức năng thời gian thực (Real

Time Communication hay RTC).Ngoài ra WebRTC cũng cung cấp cấp một số APIs để tương

tác cũng như tận dụng khả năng của các trình duyệt.Hình mơ tả kiến trúc của đơn giản

WebRTC



16



Hình 2.5 Kiến trúc phổ biến của hệ thống WebRTC

WebRTC không giới hạn kết nối giữa hai người dùng. Chúng ta có khả năng kết nối từ

một người dùng đến nhiều người dùng khác.Hình mơ tả có nhiều hơn hai peer được kết nối

với nhau.



Hình 2.6 Minh họa hệ thống WebRTC khi có nhiều người dùng kết nối với nhau

Như ta thấy ở hình trên, bất cứ khi nào ta muốn kết nối tới một user khác ta cần tạo

peer thêm peer để kết nối với hai bên. Theo hình 2.6, như ta thấy ở trên mỗi peer sẽ có 2

luồng kết nối.Chúng ta cho là khi ta có 10 peer kết nối với nhau với một, chúng ta kiểm tra là

mỗi peer kết nối mất khoảng 500kbps, nếu vậy 10 kết nối sẽ tốn chi phí là gần 5mbps. Nếu ta

sử dụng mạng ADSL với băng tần 3mbps, chúng ta không thể kết nối đến tận 10 peer. Thêm

vào đó với sự phát triển về công nghệ như hiện nay, việc tăng trải nghiệm của người dùng khi



17



thực hiện các kết nối là điều cần thiết (ví dụ như là ứng dụng Computer Vision hay AR trong

việc stream video…).Với giới hạn về thiết bị hiện nay thật khó để các kết nối có thể thực hiện

những điều trên. Với nhu cầu đó, người ta đưa ra một ý tưởng là có một server riêng, server

này có trách nhiệm trung gian chuyển/nhận các luồng dữ liệu tới các peer. Với điều này các

peer chỉ cần nhận/truyền stream từ server đó. Điều này làm giảm gánh nặng cho bên phía

người dùng bên bị giới hạn bởi thiết bị của mình (như là thiết bị di động, trình duyệt web…),

nhất là khi có rất nhiều peer kết nối với nhau.Server này được gọi là media server, hình dưới

minh hóa kiến trúc của hệ thống WebRTC khi thêm media server.



Hình 2.7 Kiến trúc đơn giản của WebRTC khi thêm vào Media Server

Với việc thêm vào Media Server ta thấy rõ sự giảm tải giữa các peer kết nối. Mỗi peer

bây giờ chỉ cần giữ kết nối tới một Media Server. Điều này giải quyết được vấn đề đề cập đến

trước đó với 10 peer kết nối.Và với thời đại công nghệ phát triển như hiện nay, việc tăng trải

nghiệm cho người dùng là một rất cần thiết và quan trọng.Vì thế với một server riêng biệt

chúng ta có nhiều sức mạnh hơn trong việc thực hiện các tác vụ video nâng cao tăng tương tác

với người dùng.Hiện tại thì có hai loại Media Server phổ biến được dùng là MCU và SFU.



18



MCU

Multipoint Controller Unit là một kiểu chiến lược cho phép tối ưu việc nhiều peer kết

nối với nhau.Với MCU thay vì các peer được thiết lập kết nối với tất cả các peer khác,nó chỉ

cần thiết lập kết nối với một media server trung gian. Media server này có trách nghiệm

nhận/chuyển tới các peer khác.Dưới đây hình minh họa của MCU:



Hình 2.8 Minh họa cách thức hoạt động của mơ hình MCU

Bảng 2.1 Thống kê số peer và các luồng stream tham gia khi thực hiện theo mô hình MCU

Streams/ngườ

Tổng cộng

Người dùng

i dùng

n

2

2n

Với một media server ở giữa ta có thể nhận thấy sự giảm phụ thuộc vào các peer kết nối

với nhau.Về cơ bản MCU nhận tất cả stream từ tất cả các peer, giải mã các stream này và sau

đó tạo một layout trộn lẫn tất cả các stream này. Cuối cùng nó giải mã và gửi đến tất cả các

peer khác. Ưu điểm của MCU là đơn giản và tránh được vấn đề về hiệu suất khi có nhiều peer

kết nối.Nhưng một điều ta có thể nhận thấy ở đây là MCU trộn lẫn các luồng stream với nhau,

điều này dẫn đến việc chúng ta khó có thể có được những luồng stream nguyên dạng ban đầu

( có thể chất lượng video kém hơn) hoặc có một vài độ trễ khi sử dụng. Một điều không tránh

khỏi là thêm một server đứng giữa rất tốn kém. Bên cạnh đó media server phải mã hóa và giải

mã lên tốn khá nhiều tài nguyên hệ thống như băng thông,CPU.

SFU

Một cách tiếp cận khác ở đây là Select Forwarding Unit (SFU). Tương tự như MCU có

một server trung gian ở giữa, nhưng SFU có phần cải tiến hơn. Thay vì phải xử lý nhiều cơng



19



đoạn như giải mã, trơn, sau đó giải mã, SFU đơn giản chỉ giải mã và gửi tới các peer khác khi

người dùng gửi một luồng stream tới.Việc này làm làm cho các luồng stream có thể chất

lượng tốt hơn do khơng phải trộn như media server.Và độ trễ thấp hơn khi không phải trải qua

nhiều giai đoạn như MCU. Hình dưới mơ tả SFU:



Hình 2.9 Mơ tả cách thức hoạt động của mơ hình SFU

Bảng 2.2 Bảng thống kê các peer và luồng stream tham gia khi hoạt động theo mơ mình SFU

Người

dùng

n



Streams/ngư

ời dùng

n



Tổng cộng

n2



2.2. Một số media server có sẵn

Như đã đề cập đến ở trên một media server là rất cần cho việc quản lý các luồng stream

một cách hiệu quả.Nhưng vấn đề đặt ra ở đây là xây dựng một media server rất phức tạp và

đòi hỏi tốc độ cao xử lý.Vì thế cần phải sử dụng một số ngơn ngữ bậc thấp và rất khó để cho

lập trình viên có thể xây dựng.Từ nhu cầu đó chúng ta có được một số open source giúp cho

việc xây dựng một hệ thống WebRTC trở lên hiểu quả và dễ dàng. Một trong sốc các media

server có thể thấy ở bẳng dưới đây bao gồm Intel Collaboration Suite for WebRTC (Intel CS

for WebRTC), Janus WebRTC gateway, Jitsi VideoBridge, Lincode, MediaSoup, Kurento

Media Server…



20



Bảng 2.3. Danh sách các media server có sẵn

Tên

Mơ tả

Intel CS for WebRTC Được hình thành dưới sự hợp tác giữa Intel và South Korean

[12]

telecommunication (SK telecom ). Họ hỗ trợ bao gồm client

SDKs (JS/ Android/ IOS / Windows), server SDKs (SFU/

MCU/ SIP Gateway). Cũng đồng nghĩa với việc có mọi thức

cần cho một ứng dụng media và được đóng goi sẵn. Media

Server này cũng được xây dựng dựa trên Licode (giới thiệu ở

dưới ).Một số đặc tính nó như:

• Hiệu năng cao, VP8 [13] , VP9 [14], H.264 [15] và HEVC

[16] thời gian thực với Intel HD Graphics.

• Phân tán, dễ dàng mở rộng, MCU server.

• Trộn HD video stream hiệu quả để tích kiệm băng thơng và

pin cho thiết bị mobile

• Có cơ chế điều khiển QoS thơng minh và thích ứng với các

mơi trường mạng khác nhau.

Janus WebRTC gateway Janus là một WebRTC server và được phát triển bởi Meetecho.

[17]

Nó bao gồm tất cả các chức năng cần thiết mà một WebRTC

Media Server cần như là tương tác và trao đổi JSON với

browers, đáp lại RTP/RTCP và các tin nhắn giữa phía browers

và server. Browsers có thể tương tác với Junus media server để

sử dụng các chức năng của nó ví dụ như hội nghị video, cuộc

gọi video trực tuyến, SIP gateways… Nó cũng được xây dựng

dựa trên libsrtp và libnice sử dụng Slack ( được xây dựng dựa

trên C).

Jitsi VideoBridge [18]



Jitsi Videobridge là một thành phần của XMPP server.Nó cho

phép thực hiện cuộc gọi video nhóm hiệu suất cao.Jitsi cũng là

một SFU và được viết bằng Java. Đây là một open source với

nhiều đặc tính như:

• Tính linh hoạt : vì là open source, lập trình viên có thể mở

rộng các đặc tính cho ứng dụng của mình.

• Khả năng mở rộng: Khơng cần server cấu hình cao, thậm trí

cả một CPU thấp cũng có thể sử dụng được.

• Dễ dàng điều khiển: Có thể được điều khiển thông qua một

số giao thức phổ biến như HTTPS hoặc REST…

• Chất lượng tốt: Với việc chỉ gửi trả lại các luồng video mà

khơng cần trộn nó vào. Jitsi có đưa ra các luồng stream với

chất lượng.

• Khả năng bảo mật: Được mã hóa với DTLS/SRTP.



Licode [19]



Licode là một WebRTC media server được xây dựng dựa trên

WebRTC.Khởi đâu lincode định hướng xây dựng là MCU, sau

này mở rộng như là SFU. Licode được thực thi dựa vào C+

+.Một số đặc tính nổi bật của lincode như:

• Tương tác thời gian thực với các ứng dụng đa phương tiện.

• Khơng chỉ tích hợp trong các ứng dụng web mà còn trên



21



nhiều thiết bị khác nhau.

• Tương thích với cloud và tính mở rộng hiệu quả.

MediaSoup [20]

Được biết đến như là phiên bảo mới nhất của dự án tăng khẳ

năng của SFU. Được xây dựng. Được xây dựng bằng C (sử

dụng libuv) bọc với các đoạn mã Javascipt.Nhờ thiết kế theo

SFU, MediaSoup cho ra hiệu năng tốt hơn và ít độ trễ

hơn.Thêm vào đó mang theo khả năng mở rộng cao.Các đặc

tính của mediasoup gồm:

• Được bóc bởi javascipt (ECMAScript) một ngôn ngữ phổ

biến nhất cho cho ứng dụng web.Lập trình viên có thể dễ

dàng điều khiển nó.

• Có thể tạo ra nhiều cuộc gọi hội hội thảo trực tuyến với

nhiều user tham gia.

• Hỗ trợ TCP và UDP trên các giao thức ICE /DTLS/ RTP/

RTCP

Kurento Media Server Tương tự những cái đã giới thiệu trước đây là một WebRTC

[21]

media server. KMS được thực thi bằng C++ sử dụng thư viện

Gstreamer vì thế KMS xử lý được rất nhiều tác vụ video nâng

cao nhưng xử lý luồng một cách linh hoạt, hỗ trợ thực tế ảo

tăng cường (AR), phân tích và nhận diện trên video…Kurento

cũng đưa ra tập hợp các API (hỗ trợ Java/Javascript/Nodejs) và

giao thức để lập trình viên có thể tương tác với KMS một cách

đơn giản nhất. Một số đặc tính nổi bật của KMS:

• Có hỗ trợ các giao thức truyền trực tuyến như là HTTP, RTP

và WebRTC.

• Hỗ trợ cả hai MCU,SFU

• Xử lý các tác vụ nâng cao như Computer Vision, AR

• Thiết kế kurento phù hợp để tích hợp vào mơi trường cloud

như là PaaS (Platform as a Service )

• Lập trình viên không cần biết về độ phức tạp bên trong

Kurento Media Server. Tất cả các ứng dụng có thể được

thực hiện bởi bất cứ cơng nghệ hoặc framework nào lập

trình viên muốn, từ client tới server.Từ browsers tới cloud

services

• Tự động chuyển mã các luồng media được hỗ trợ bởi

Gstreamer như là VP8, H.263,H.264, G.711 …



Bảng 2.4 Tóm lượt các đặc tính được hỗ trọ của các media server trên

Tên

Intel CS for WebRTC

Junus WebRTC gateway

Jitsi VideoBridge

Licode

MediaSoup

Kurento Media Server



SF

U















MC

U



















Audi

o























Video



22



OpenSourc

e













License

free

GPL v3

Apache 2

MIT

ISC

Apache 2



2.3 Các gói thư viện trong kurento

Như đã được đề cập trước đó kurento mang đầy đủ các tính năng mà một ứng dụng media cần.Về

cơ bản kurento cung cấp đầy đủ các gói thư viện và các giao thức cho lập trình viên sử dụng (hỗ

trợ hai ngơn ngữ phổ biến là java/javascript) như là Kurento API, Kurento Protocol, Kurento API,

Kurento Utils JS, Kurento Modules.



2.3.1. Kurento API

Gói thư viện này được kurento xây dựng nhằm mục đích hỗ trợ việc điều khiển KMS

cách dễ dàng nhất.Bằng cách đưa ra cách API, chúng ta có thể tương tác với KMS thơng qua

các ngôn ngữ bậc cao như javascript hay java.Kurento đưa ra một số API có thể kể đến ở đây

như như Media Elements, Media Pipeline, Endpoint, Filter, Hub



2.3.2 Media Element

Là tập hợp các thành phần có một chức năng cụ thể nào đó được kurento cung cấp.

Lợi ích khi sử dụng nó là lập trình viên sẽ khơng cần biết nó được xử lý cụ thể như nào.Nhìn

chung một các media element đều có khẳ năng nhận/gửi dữ liệu media từ các media element

khác.Kurento phân loại thành bốn nhóm thành phần chính như là Endpoint, Filters, Hubs,

Output Endpoints … các thành phần cụ thể được miêu tả ở bảng dưới.

Bảng 2. 5 Danh sách các media element trên KMS [22]

Tên thành phần

Endpoints



Mơ tả

Nhìn chung thành phần này có khả năng nhận dữ liệu

/đưa dữ liệu media theo nhiều tài nguyên khác nhau như

là file, từ mạng và có trực tiếp từ ảnh chụp từ camera

hoặc các thiết bị phần cứng khác.Một số Endpoint có

thể kể đến là:

• WebRtcEndpoint: Endpoint này cung cấp luồng

media thơng qua web.Nó có hai khả năng nhận và

xuất các luồng media.Được xây dựng dựa trên công

nghệ WebRTC nhằm mục đích tương tác với trình

duyệt web.

• RtcEndpoint: Cũng có khả năng nhận và xuất các

luồng media.Endpoint này cung cấp tương tác với

các peer khác hai chiều thông qua giao thức RTP

(Real Time Communications). Nó sử dụng SDP để

trao đổi các thông số cần thiết để thực hiện media

giữa các peer.

• HttpPostEndpoint: có khả năng nhận các luồng

media bằng cách sử dụng yêu cầu HTTP POST (ví

dụ như upload file…).

• PlayerEndpoint: Nhận nội dung từ file hệ thống

như là HTTP URL hoặc RTSP URL và đưa nó vào

trong media pipeline.

• RecordEndpoint: Cung cấp các chức năng phục vụ



23



Tài liệu bạn tìm kiếm đã sẵn sàng tải về

CHƯƠNG 2. CƠ SỞ LÝ THUYẾT

Tải bản đầy đủ ngay(0 tr)

×