CHƢƠNG 2 GIẢI PHÁP KỸ THUẬT WEBRTC
2.2. LỊCH SỬ PHÁT TRIỂN
Trong lịch sử, truyền thông RTC chỉ đƣợc dùng trong các doanh nghiệp. Nó sử dụng cơng nghệ truyền tải audio và video rất phức tạp với những ràng buộc hết sức chặt chẽ và chi phí lắp đặt rất cao. Một số sản phẩm của một số hãng khi đó đã hỗ trợ giao tiếp RTC nhƣ Google với Google Talk, Yahoo với Yahoo Messenger, Microsoft với Skype…. Một trong những thách thức lớn nhất cho các trang web là cho phép con ngƣời giao tiếp thơng qua giọng nói và video: giao tiếp thời gian thực hay RTC - Real Time Communication [9].
Ý tƣởng phát triển WebRTC đƣợc đƣa ra bởi nhóm phát triển Google Hangouts từ năm 2009. Vào thời gian đó, để truyền tải video, hình ảnh trên web, ngƣời sử dụng phải cài đặt Flash và các plugin . Đến Năm 2010, Google mua lại hai công ty là On2 và Global IP Solutions (GIPS). Sau đó họ chuyển các cơng nghệ liên quan đến RTC của hai công ty này thành mã nguồn mở và kết hợp với IETF và W3C để đƣa ra WebRTC vào năm 2011. Tháng 6/2011, đƣợc đánh dấu là thời gian bộ mã nguồn mỡ API của chuẩn WebRTC chính thức đƣợc giới thiệu rộng rãi, cung cấp miễn phí, xây dựng trên nền web [11].
2.3. KIẾN TRÚC VÀ PHƢƠNG THỨC HOẠT ĐỘNG CỦA WEBRTC 2.3.1. Kiến trúc WebRTC
Hình 2.2 dƣới đây thể hiện kiến trúc bên trong của WebRTC. Chúng ta thấy có hai tầng riêng biệt trong WebRTC [6]:
1. Các nhà phát triển trình duyệt web (nhƣ Google Chrome hoặc Mozilla Firefox) sẽ quan tâm đến các WebRTC C ++ API cho kết nối peer-to- peer và các API cho audio, video và vào/ra mạng theo ý của họ.
2. Các nhà phát triển ứng dụng web sẽ quan tâm đến các web API.
Hình 2.2. Mơ hình kiến trúc WebRTC
Để có thể tích hợp các ứng dụng thời gian thực vào web, các browser phải thêm vào các khối chức năng hỗ trợ dành cho WebRTC:
Voice/video engine: Dùng để thu nhận âm thanh và hình ảnh từ thiết bị ngoại vi (microphone, camera), điều chế mã hố âm thanh và hình ảnh dựa trên các chuẩn mã hoá cơ bản trƣớc khi truyền. Các chuẩn mã hoá cơ bản
dành cho voice và video bao gồm: Opus, iSac, iLBC <voice>, VP8, H263, H264 (video).
Transport: cũng cấp chức năng kết nối với các thành phần khác cùng tham gia trong WebRTC (STUN, TURN, ICE ...).
Session management: đóng vai trị điều khiển hoạt động của ứng dụng.
Application Programming Interface - API: cung cấp các hàm cơ bản để các nhà phát triển có thể sử dụng. API ở đây có thể xét nằm trên hai mức cơ bản: API dành cho Browser developer và API dành cho Front end developer.
2.3.2. Phƣơng thức hoạt động
Trong mơ hình hoạt động truyền thống của web, mơ hình client - server đƣợc sử dụng khá là phổ biến khi mà server sẽ đảm nhiệm tất cả bao gồm: điều khiển, truyền dữ liệu, security.... Tuy nhiên, nếu áp dụng mơ hình này vào trong các ứng dụng thời gian thực sẽ ảnh hƣớng tới hiệu năng hoạt động của ứng dụng vì các lý do sau:
Khối lƣợng dữ liệu trao đổi giữa các client là cực kỳ lớn. Chuẩn mã hoá voice OPUS có bitrate dao động từ 6 Kbps cho tới 510 Kbps. Nếu dữ liệu này truyền trực tiếp tới server để server truyền tải tới client thì sẽ xảy ra việc quá tải không chỉ dành cho server mà cho cả hệ thống mạng.
Chất lƣợng dịch vụ (Quality of service - QoS). Trong QoS dành cho các ứng dụng thời gian thực, có hai tham số cực kỳ quan trọng cần đƣợc giảm thiểu tối đa là delay (trễ client) và jitter (trễ giữa các gói tin). Việc phải truyền tải toàn bộ dữ liệu tới server sẽ gia tăng rủi do trong delay và jitter.
Do đó, các ứng dụng thời gian thực đòi hỏi một mơ hình khác có thể đáp ứng đƣợc hai u cầu trên, đó là mơ hình Peer-to-Peer (P2P). Trong mơ hình này, dữ liệu truyền tải đƣợc chia ra làm hai loại: dữ liệu điều khiển, báo
hiệu (Signalling) và dữ liệu nội dung (Data stream). Các máy client thƣờng sẽ giao tiếp với server để gửi/nhận các tín hiệu điều khiển và sau đó sẽ truyền nhận trực tiếp dữ liệu với các client khác.
Hình 2.3. Kênh báo hiệu trong WebRTC
Lấy một ví dụ đơn giản về Video chat sử dụng WebRTC:
1. Caller và Callee khi bắt đầu sử dụng ứng dụng phải gửi các tín hiệu về ứng dụng mà mình đang sử dụng tới server (session description).
2. Caller gọi: Caller request tới server để đăng ký một cuộc gọi với Callee, server sẽ trả về cho Caller địa chỉ IP của Callee cùng với port ứng dụng hiện tại của Callee.
3. Callee sẽ nhận một bản tin của server báo về một cuộc gọi từ phía caller
4. Caller bắt đầu truyền dữ liệu từ phía mình trực tiếp sang Callee. 5. Caller/callee ngắt kết nối: thông báo về server và dừng truyền dữ liệu.
Tuy nhiên, trên thực tế, các peer đều sử dụng các địa chỉ IP private (thuộc các dải: 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8) và sử dụng cơ chế NAT để kết nối internet, do đó việc kết nối trực tiếp giữa các peer sẽ gặp khó khăn nếu sử dụng dải mạng nội bộ. Do đó, chúng ta phải có cơ chế hỗ trợ phân giải sang địa chỉ IP public.
Hình 2.4. Máy chủ STUN
Để tiết kiệm địa chỉ IP, rất nhiều các nhà điều hành mạng sử dụng cơ chế NAT để chuyển đổi từ địa chỉ IP mạng nội bộ sang địa chỉ IP Public. Về cơ bản địa chỉ IP sẽ đƣợc chuyển đổi nhƣ sau : IP private <-> IP public: port.
Trong đó port ở đây là các cổng ứng dụng nằm trên firewall hay router. Điều này giúp cho nhiều địa chỉ IP nội bộ có thể sử dụng chung IP public. STUN server sẽ đóng vai trị trung gian giúp cho các peer có thể lấy đƣợc địa chỉ của peer khác. Hiện nay, google đã xây dựng một số STUN server hỗ trợ hồn tồn miễn phí nhƣ stun:stun.l.google.com:19302.
Hình 2.5. TURN server và STUN server
Trong mơ hình OSI, tại lớp vận chuyển (Transport layer) có hai giao thức nổi tiếng là TCP và UDP. Trong khi UDP cung cấp khả năng vận chuyển nhanh nhất có thể thì TCP lại đảm bảo truyền tin cậy. Hầu hết trong các ứng dụng thời gian thực, tín hiệu điều khiển sẽ sử dụng TCP trong khi dữ liệu sẽ truyền bằng UDP. Tuy nhiên, UDP không phải là cơ chế truyền tin cậy, dễ làm tăng số lƣợng các gói tin bị mất, do vậy đôi khi TCP đƣợc ƣu tiên sử dụng.
Trong mơ hình peer-to-peer, dữ liệu thay vì đƣợc gửi trực tiếp tới các peer thì các peer sẽ gửi dữ liệu tới các TURN server và TURN server sẽ đóng vai trị trung gian vận chuyển gói tin. Điều này nâng cao không những chất lƣợng dịch vụ của ứng dụng mà cịn đảm bảo an tồn thông tin khi truyền dẫn.
2.4. CÁC GIAO THỨC MẠNG TRUYỀN THÔNG THỜI GIAN THỰC
Đầu tiên, một điểm then chốt của truyền tải dữ liệu thời gian thực là giao thức mạng sử dụng để truyền tải nó tới ngƣời dùng khác. WebRTC sử
dụng giao thức UDP để truyền tín hiệu, dữ liệu đi. Trong WebRTC các ứng dụng chia sẻ audio và video đƣợc thiết kế với mục đích làm giảm thiểu khả năng mất mát gói tin liên tục trong một thời gian dài. Các cơng cụ mã hóa gói tin audio và video có thể thêm, hay bổ sung những phần gói tin bị thiếu, bị mất trong q trình truyền tải, một phần dữ liệu nhỏ. Nhƣ vậy, các ứng dụng phải sử dụng logic để phục hồi các dữ liệu bị mất hay bị trì hỗn.
Hình 2.6. Ngăn xếp giao thức WebRTC
Yêu cầu tính tức thời quan trọng hơn độ tin cậy nên đó là lý do chính tại sao giao thức UDP là một giao thức truyền thông tốt để truyền các dữ liệu thời gian thực trong WebRTC. TCP cũng đƣợc sử dụng bởi tính đáng tin cậy và đúng tuần tự của nó, nếu gói tin trung gian bị mất trong quá trình truyền, dữ liệu sẽ đƣợc truyền lại với cơ chế hạn chế tắc nghẽn đƣờng truyền.
UDP là nền tảng trong giao tiếp thời gian thực trong trình duyệt nhƣng để đáp ứng tất cả các yêu cầu khắt khe của WebRTC, trình duyệt cũng cần rất nhiều giao thức giao vận và dịch vụ khác hỗ trợ nó. Hình 2.8 mơ tả ngăn xếp các giao thức và dịch vụ hỗ trợ trình duyệt trong WebRTC, trong đó:
ICE
ICE là một giao thức đƣợc tiêu chuẩn hóa bởi IETF (RFC- 5245) [2]. Giao thức ICE đƣợc dùng để thiết lập phiên media dựa trên UDP đi qua NAT một cách nhanh nhất.
Cũng giống nhƣ các hệ thống VoIP, WebRTC bị cản trở khi tạo kết nối peer-to-peer bởi tƣờng lửa và NAT. WebRTC sử dụng giao thức ICE để tạo kênh giao tiếp giữa các peer nhờ STUN và TURN server [12]. ICE cố gắng tìm ra con đƣờng tốt nhất để kết nối giữa các peer, nó thử tất cả các khả năng có thể kết nối một cách song song và lựa chọn một con đƣờng kết nối hiệu quả nhất. Đầu tiên, ICE thử kết nối trực tiếp giữa hai peer bằng cách sử dụng địa chỉ thu đƣợc từ hệ điều hành và card mạng của thiết bị; nếu thất bại (có thể do thiết bị ở đằng sau một NAT), ICE lấy địa chỉ bên ngoài của thiết bị bằng cách sử dụng một máy chủ STUN, và nếu không thành công, lƣu lƣợng mạng đƣợc chuyển qua một máy chủ chuyển tiếp TURN server.
ICE đƣợc chạy vào lúc bắt đầu của một phiên trƣớc khi thiết lập phiên SRTP giữa các trình duyệt.
STUN
STUN (Session Traversal Utilities for NAT) là một giao thức mạng cho phép các máy khách tìm ra địa chỉ cơng khai của mình, loại NAT mà chúng đang đứng sau và cổng phía Internet đƣợc NAT gắn liền với cổng nội bộ nào đó. Thơng tin này đƣợc sử dụng để thiết lập giao tiếp UDP giữa 2 host mà đều nằm sau NAT router. Giao thức STUN đƣợc định nghĩa trong RFC 5389 [13]. Trong WebRTC, một STUN client đƣợc xây dựng sẵn trong user agent của trình duyệt, và các máy chủ web sẽ chạy một máy chủ STUN. Gói tin kiểm tra STUN đƣợc gửi trƣớc khi thiết lập phiên để cho phép trình duyệt biết nếu nó đang ở đằng sau một NAT và để khám phá các địa chỉ ánh xạ và cổng của nó. Thơng tin này sau đó đƣợc sử dụng để xây dựng các địa chỉ ứng cử viên trong kỹ thuật ICE "hole punching". STUN có thể đƣợc vận chuyển qua UDP, TCP, hoặc TLS [1].
TURN
media cho các trƣờng hợp mà ICE "hole punching" thất bại. Trong WebRTC, các user agent trong trình duyệt sẽ bao gồm một TURN client, và một máy chủ web sẽ cung cấp một máy chủ TURN. Trình duyệt yêu cầu một địa chỉ IP công cộng và số cổng nhƣ một địa chỉ chuyển tiếp vận chuyển từ máy chủ TURN. Địa chỉ này sau đó đƣợc bao gồm nhƣ là một địa chỉ ứng cử viên trong ICE "hole punching". TURN cũng có thể đƣợc sử dụng để đi qua tƣờng lửa [7].
TURN có thể đƣợc sử dụng để thiết lập địa chỉ vận chuyển chuyển tiếp sử dụng UDP, TCP, hoặc TLS. Tuy nhiên, thông tin liên lạc giữa các máy chủ TURN và TURN client (thông qua NAT) luôn luôn là UDP.
SCTP và SRTP
Giao thức quan trọng nhất đƣợc sử dụng bởi WebRTC là RTP. WebRTC chỉ sử dụng phiên bản an toàn của RTP gọi là SRTP [2]. SRTP là giao thức đƣợc sử dụng để vận chuyển và mang các gói tin audio và video media giữa các WebRTC client. Các gói tin media chứa các audio hoặc các khung hình video đƣợc số hóa đƣợc tạo ra bởi một microphone hoặc máy ảnh hoặc ứng dụng, và đƣợc dựng lại bởi loa hoặc màn hình hiển thị. Một thiết lập thành công một kết nối peer, cùng với việc hoàn thành trao đổi một cặp offer/answer sẽ dẫn đến một kết nối SRTP đƣợc thiết lập giữa các trình duyệt hoặc một trình duyệt và một máy chủ, và trao đổi thơng tin media.
SRTP cung cấp thông tin cần thiết để vận chuyển thành cơng và dựng hình thơng tin media: các codec (coder/decoder đƣợc sử dụng để lấy mẫu và nén audio hoặc video), nguồn của các media (nguồn đồng bộ hóa hoặc SSRC), một dấu thời gian, số thứ tự (để phát hiện mất các gói dữ liệu), và các thông tin khác cần thiết để phát lại. Đối với dữ liệu không phải là audio hoặc video, SRTP không đƣợc sử dụng. Thay vào đó, một cuộc gọi đến API RTCDataChannel sẽ dẫn đến một kênh dữ liệu đƣợc mở ra giữa các trình duyệt cho phép bất kỳ định dạng dữ liệu đƣợc trao đổi.
SDP
Mô tả phiên WebRTC đƣợc mô tả bằng cách sử dụng SDP. Một mô tả phiên SDP (mã hóa nhƣ là một đối tƣợng RTCSessionDescription) đƣợc sử dụng để mô tả các đặc điểm media của kết nối peer [7]. Có một danh sách dài và phức tạp của thông tin cần phải đƣợc trao đổi giữa hai đầu của phiên SRTP để chúng có thể giao tiếp. Lời gọi API đến RTCPeerConnection sẽ cho kết quả là một mô tả phiên SDP, một tập định dạng dữ liệu theo cách đặc biệt, đƣợc tạo ra bởi các trình duyệt và truy cập bằng cách sử dụng JavaScript bởi các ứng dụng web. Một ứng dụng muốn có kiểm sốt media chặt chẽ hơn có thể thay đổi các mô tả phiên trƣớc khi chia sẻ nó với trình duyệt khác. Khi các thay đổi đƣợc thực hiện cho một kết nối peer, điều này sẽ dẫn đến thay đổi mô tả phiên mà hai bên sẽ trao đổi. Điều này đƣợc gọi là một trao đổi offer/answer. Bất kỳ nhà phát triển nào có nhu cầu kiểm sốt các phiên media chi tiết hơn cần phải hiểu về SDP.
Cả SRTP và SDP là hai giao thức đƣợc chuẩn hóa bởi IETF và đƣợc sử dụng rộng rãi bởi các thiết bị và dịch vụ truyền thông trên Internet, chẳng hạn nhƣ điện thoại VoIP, hội nghị truyền hình và các thiết bị hợp tác khác. Kết quả là, thông tin liên lạc giữa một trong những thiết bị và một WebRTC client là có thể đƣợc. Tuy nhiên, rất ít các thiết bị VoIP hoặc video hiện nay hỗ trợ đầy đủ các khả năng và các giao thức của WebRTC. Các thiết bị này sẽ cần phải đƣợc nâng cấp để hỗ trợ các giao thức mới, hoặc một chức năng gateway đƣợc sử dụng giữa WebRTC client và VoIP hoặc video client để làm việc chuyển đổi.
TLS
TLS (các phiên bản cũ đƣợc gọi là SSL - Secure Sockets Layer), là một lớp chèn giữa TCP và các ứng dụng cung cấp các dịch vụ bảo mật và xác thực. Bảo mật đƣợc cung cấp bằng cách mã hóa các gói tin. Xác thực đƣợc
cung cấp bằng cách sử dụng giấy chứng nhận kỹ thuật số. Duyệt web an toàn ngày nay (HTTPS) chỉ sử dụng vận chuyển TLS. WebRTC có thể tận dụng lợi thế của TLS cho báo hiệu và bảo mật giao diện ngƣời dùng. Ngồi ra cịn có một phiên bản của TLS chạy trên UDP, đƣợc gọi là DTLS - Datagram TLS, và một phiên bản có thể đƣợc sử dụng để tạo ra các khóa cho SRTP đƣợc gọi là DTLS-SRTP [1].
DTLS
DTLS là một phiên bản của TLS chạy trên UDP, nó cung cấp tính bảo mật và xác thực tƣơng tự nhƣ trong TLS. UDP đi qua NAT dễ dàng hơn và có thể phù hợp hơn cho các ứng dụng peer-to-peer.
ICE, STUN và TURN server rất cần thiết để thiết lập và duy trì kết nối ngang hàng giữa các trình duyệt. Giao thức DTLS đƣợc thiết kế sử dụng trong WebRTC để ngăn chặn việc nghe trộm, giả mạo, để đảm bảo tất cả các dữ liệu đƣợc truyền giữa các peer trong kết nối peer-to-peer. Và SCTP, SRTP đƣợc sử dụng để ghép các luồng khác nhau, điều khiển tắc nghẽn và kiểm soát lƣu lƣợng. Hai giao thức này cung cấp một số tính năng dịch vụ giống với TCP và UDP cụ thể đó là một thơng điệp định hƣớng nhƣ UDP và đảm bảo tin cậy, trong chuỗi truyền tải thông tin với sự điểu khiển tắc nghẽn nhƣ TCP. Do đó, nó là bổ sung khác cho UDP cho việc truyền tin, dữ liệu audio – video [10].
WebRTC sử dụng giao thức UDP ở tầng giao vận bởi cho rằng độ trễ và tức thời là rất quan trọng. UDP không cung cấp sự tin cậy và thứ tự truyền