WebRTC là cái hợi gì?
WebRTC là một từ khóa đang nổi như cồn hiện nay, nó được các ông lớn công nghệ dùng sử dụng để làm rất nhiều điều thú vị như IoT(Internet of thing), video p2p, message,... Nhưng chính xác thì WebRTC là gì và bạn có thể sử dụng nó như thế nào để áp dụng vào sản phẩm của bạn một cách tốt hơn nữa thì bài đăng này sẽ là bài đăng đầu tiên trong series WebRTC để giúp bạn hình dung nó là cái hợi gì, và tại sao cần tới nó như vây....
1. WebRTC là gì
Web Real-Time Communication(WebRTC) nó là một mã nguồn mở, và nó mở ra một cách cửa đề truyền thông theo thời gian thực(RTC - Real-Time Com). Ngày xưa khi WebRTC chưa phổ biến, mỗi khi thực hiện Video Call tới một ai đó chúng ta sẽ bị gặp một cảnh tượng là nói xong khoảng 5 - 10s sau người đầu bên kia mới có thể nhận được chúng ta đang nói gì. Để giải quyết vấn đề này các kỹ sư của Google đã ra dự án WebRTC.
WebRTC được Google công bố lần đầu tiên vào tháng 5 năm 2011 như một phương tiện phát triển một bổ giao thức chung để cho phép các ứng dụng RTC chất lượng cao trong các trình duyệt, nền tảng di động và thiết bị IoT. Vào thời điểm ngày trước, Flash là plug-in một phương pháp duy nhất cung cấp giao tiếp thời gian thực tuy nhiên về một số lý do như bảo mật nên hầu hết các tổ trức đã khai tử Flash. Từ đó WebRTC được ra đời và sau những nỗ lực đáng kể, cuộc gọi video giữa các trình duyệt đầu tiên đã được thiết lập giữa Chrome và Firefox. Kể từ đó, sự ủng hộ dành cho WebRTC trong cộng đồng nhà phát triển đã tăng vọt khi ngày càng có nhiều tổ chức bổ sung hỗ. Ngày nay, WebRTC đã có sẵn (ở các mức môi trường khác nhau) trong Chrome, Firefox, Safari, Edge, Android và iOS và là một công cụ phổ biến rộng rãi để gọi điện video.
2. WebRTC APIs
Các thành phần chính của API WebRTC và mỗi thành phần đóng một vài trò duy nhất trong cấu trúc WebRTC:
MediaStream (GetUserMedia):
API MediaStream cung cấp một cách để truy cập máy ảnh và micro của thiết bị bằng JavaScript. Nó kiểm soát nơi luồng dữ liệu đa phương tiện được sử dụng và cung cấp một số quyền kiểm soát đối với các thiết bị di động hoặc máy tính. Nó cũng đưa ra được thông tin về các phần cứng của máy tính có thể chụp và hiển thị phương tiện.
RTCPeerConnection:
Kết nối Peer là cốt lõi của tiêu chuẩn WebRTC. Nó cung cấp một kết nối giữa người với ngươì tham gia mà không cần máy chủ trung gian (ngoại trừ máy chủ Signal). Mỗi người tham gia lấy dữ liệu từ camera có được từ API MediaStream và truyền nó vào kết nối ngang hàng để tạo nguồn cấp dữ liệu âm thanh hoặc video. API PeerConnection có rất nhiều hoạt động ở bên trong. Nó xử lý lượng SDP, triển khai Codec, NAT Traversal, Package Loss, quản lý băng thông và truyền phương tiện.
RTCDataChannel:
API RTCDataChannel được thiết lập để cho phép truyền dữ liệu hai chiều của bất kỳ loại dữ liệu nào - media hoặc cách khác- trực tiếp giữ các máy tham gia. Nó được có thiết kế giống WebSocket, nhưng thay vì dựa vào kết nối TCP tuy đáng tin cậy nhưng độ trễ cao và dễ bị tắc nghẽn, thì kết nối của RTCDataChannel sử dụng các luồng dựa trên UDP với khả năng định cấu hình của giao thức truyền điều khiển luồng (SCTP). Thiết kế này cung cấp khả năng phân phối đáng tin cậy như trong TCP nhưng giảm tắc nghẽn trên mạng như trong UDP.
3. Thiết lập kết nối
Trước khi cuộc gọi video peer-to-peer có thể bắt đầu, kết nối giữa hai máy khách cần được thiết lập. Điều này được thực hiện thông qua Signal(Tín hiệu). Signal không nằm ngoài phạm vi của thông số kỹ thuật WebRTC nhưng là bước quan trọng đầu tiên trong việc thiệt lập kết nối âm thanh/ video.
Signaling
Signaling cho phép hai điểm cuối (người gửi, người nhận hoặc cả hai) trao đổi siêu dữ liệu để điều phối giao tiếp nhằm thiết lập cuộc gọi. Ví dụ: trước khi hai điểm đầu cuối có thể bắt đầu cuộc gọi video, một bên phải gọi cho bên kia và bên được gọi phải trả lời. Luồng thông báo gọi và phản hồi này (còn được gọi là luồng thông báo trả lời đề nghị) chứa các chi tiết quan trọng về luồng sẽ diễn ra - số lượng và loại luồng, cách phương tiện sẽ được mã hóa, v.v - và thường được định dạng sử dụng Giao thức mô tả phiên (SDP), một định dạng tiêu chuẩn được sử dụng bởi nhiều hệ thống trong thế giới thực, bao gồm cả VoIP và WebRTC.
Điều này là cần thiết vì hai lý do:
- Những người tham gia không biết khả năng về ph
- Những người ngang hàng không biết địa chỉ mạng của nhau
NAT Traversal - ICE, TURN and STUN
Khi tín hiệu ban đầu cho kết nối phát trực tuyến đã diễn ra, hai điểm đầu cuối bắt đầu quá trình truyền qua NAT (Network Address Translation). Nhưng NAT chỉ là địa chỉ công khai của một bộ Router nào đó chưa rất nhiều máy tính con bên trong, nên khi sử dụng kết nối ngang hàng chúng ta phải biết kết nối của máy tinh con chứ không phải kết nối thông qua NAT. Vì vậy NAT Tranversal ra đời và là một phương pháp để giải quyết các vấn đề liên quan đến dịch địa chỉ IP.
Trong cuộc gọi video hỗ trợ WebRTC, trừ khi hai điểm đầu cuối cùng nằm trên một mạng cục bộ, sẽ có một hoặc nhiều thiết bị mạng trung gian (bộ định tuyến/ cồng) giữa hai thiết bị này. Có ba đặc điểm kỹ thuật chính được sử dụng trong WebRTC để vượt qua những trở ngại sau:
- Interactive Connectivity Establishment (ICE) - ICE được sử dụng để tìm tất cả các cách để hai máy tính nói chuyện với nhau. Nó có hai vai trò chính, thu thập các ứng viên và kiểm tra khả năng kết nối. Nó đảm bảo rằng nếu có một con đường để hai người giao tiếp, nó sẽ tìm thấy và đảm bảo hiệu quả nhất. Nó sẽ phán đoán xem nên sử dụng STUN hay TURN để truy cập.
- Session Traversal Utilities for NAT (STUN) - STUN là viết tắt của Session Traversal Utilities for NAT và là một phương pháp nhẹ và đơn giản cho NAT Traversal. STUN cho phép máy khách WebRTC tìm ra địa chỉ IP của riêng họ bằng cách đưa ra yêu cầu tới máy chủ STUN.
- Traversal Using Relays around NAT (TURN) - Máy chủ TURN hỗ trợ truyền NAT bằng cách giúp các điểm đầu cuối tìm hiểu về các bộ định tuyến trên mạng cục bộ của chúng, cũng như chuyển tiếp dữ liệu cho một trong các điểm cuối không thể kết nối trực tiếp do các hạn chế của tường lửa.
Codecs
Trước khi gửi phương tiện qua kết nối peer, nó phải được nén. Âm thanh và video thô đơn là có dung lướng rất lớn lớn nên việc gửi sẽ không hiệu quả. Nên trước khi gửi âm thanh, các máy tham ra gửi phải nén âm thanh hoặc video lại. Tương tự như vậy, sau khi nhận âm thanh hoặc video qua kết nối peer, nó phải được giải nén. Bộ giải mã đa phương tiện (coder - decoder) thực hiện chính xác điều này.
WebRTC đã có ba codec audio và hai codec video:
- Audio - PCMU (G.711μ) chạy ở 8,000Hz với một kênh đơn (mono).
- Audio - PCMA (G.711μ) chạy ở 8,000Hz với một kênh đơn (mono).
- Audio - Opus chạy ở 48,000hz với hai kênh (stereo),
- Video - VP8
- Video - H.264/AVC sử dụng Constranied Baseline Profile mức 1.2.
Các codec phương tiện như VP9 và H.265 có thể được thêm vào tiêu chuẩn WebRTC tại một số thời điểm trong tương lai, nhưng hiện tại thì không bắt buộc. Các chuyên gia RTC chẳng hạn như nhóm Frozen Mountain's Professional Services thường có thể thêm hỗ trợ codec tùy chỉnh và tương lai sẽ bổ xung để đáp ứng với bất kỳ yêu cầu nào của khách hàng.
4. Cấu trúc liên kết WebRTC
Cấu trúc liên kết peer-to-peer là kiểu kết nối duy nhất được đề cập trong mô tả WebRTC. Cấu trúc liên kết dựa trên máy chủ có thể giúp giải quyết những nhược điểm này và thường được sử dụng trong WebRTC để truyền phương tiện. Cấu trúc liên kết tốt nhất cho bất kỳ ứng dụng nhất định nào phụ thuộc phần lớn vào các trường hợp sử dụng dự kiến, vì mỗi trường hợp có một bộ lợi ích và nhược điểm riêng
Peer-to peer (Mesh)
Trong cấu trúc peer-to-peer hoặc mạng lưới, mỗi người tham gia trong mọt phiên kết nối trực tiếp với tất cả những người tham gia khác mà không cần sử dụng máy chủ. Loại kết nối này hoàn hảo cho các hội nghị truyền hình nhỏ vì nó có chi phí thấp nhất và dễ thiết lập nhất. Tuy nhiên, khi các hội nghị phát triển, việc duy trì kết nối trực tiếp giữa tất cả những người tham gia trở nên không bền vững vì nó có thể trở nên quá tốn CPU. Vì các kết nối là trực tiếp giữa các người tham, nên cấu trúc liên kết lưới không cho phép thực hiện lưu lại thông tin của cuộc họp ví dụ như bạn muốn lưu cuộc họp video để xem lại sau.
Vì những lý do này, cấu trúc liên kết lưới là tốt nhất cho các ứng dụng đơn giản kết nối 2 đến 3 người tham gia, trong đó độ trễ thấp là quan trọng và nơi không cần quay màn hình.
Ví dụ về các trường hợp sử dụng tiềm năng bao gồm:
- Cuộc gọi video tư vấn Bác sĩ/ Bệnh nhân
- Dịch vụ chăm sóc khách hàng 1-1
Selective Forwarding (SFU)
Trong cấu trúc liên kết chuyển tiếp có chọn lọc, mỗi người tham gia trong một phiên kết nối với một máy chủ hoạt động như một đơn vị chuyển tiếp chọn lọc (SFU). Mỗi người tham gia tải luồng video được mã hóa của họ lên máy chủ. Sau đó, máy chủ sẽ chuyển tiếp các luồng đó đến từng người tham gia khác. Điều này làm giảm độ trễ và cũng cho phép những thứ như chuyển mã, ghi âm tuy nhiên việc tích hợp các máy chủ khác như SIP(Session Initiation Protocol) sẽ khó hơn nhiều trong kết nối peer-to-peer.
Cấu trúc liên kết không phải là không có giới hạn của nó. Mặc dù có một kết nối ngược dòng duy nhất làm cho nó tải lên hiệu quả hơn so với cấu trúc liên kết mesh mà chúng ta đã biết ở trê, nhưng việc có nhiều kết nối xuôi dòng có nghĩa là mỗi máy khách cuối cùng sẽ hết tài nguyên khi có một số lượng người tham gia nhất định hoạt động trong phiên.
Vì những lý do này, cấu trúc liên kết chuyển tiếp có chọn lọc là tốt nhất cho các ứng dụng kết nối 4 đến 10 tham gia, nơi độ trễ thấp là quan trọng hoặc nơi yêu cầu ghi và tính toàn vẹn là rất quan trọng. Cấu trúc liên kết này thường được coi là cân bằng nhất.
Ví dụ về các trường hợp sử dụng tiềm năng bao gồm:
- Bệnh viện
- Dịch vụ khách hàng
Multipoint Control (Mixing)
Trong cấu trúc liên kết điều khiển đa điểm, mỗi người tham gia trong một phiên kết nối với một máy chủ hoạt động như một đơn vị điều kiển đa điểm (MCU). MCU nhận phương tiện từ mỗi người tham gia và giải mã nó, trộn âm thanh và video từ những người tham gia lại với nhau thành một luồng duy nhất, lần lượt được mã hóa và gửi đến từng người tham gia. Điều này yêu cầu sử dụng ít băng thông hơn và CPU thiết bị nhưng nó yêu caàu CPU máy chủ bổ sung để trộn âm thanh/ video thành các luồng đơn lẻ MCU cũng là một lựa chọn tuyệt vời để giải quyết các điều kiện mạng kém vì nó cung cấp mức sử dụng băng thông thấp nhất có thể cho từng người tham gia riêng lẻ.
Vì những lý do này, cấu trúc liên kết điều khiển đa điểm là tốt nhất cho các ứng dụng quy mô lớn kết nối số lượng lớn người tham gia hoặc điều kiện mạng kém hoặc nơi yêu cầu ghi và tính toàn vẹn là rất quan trọng.
Ví dụ về các trường hợp sử dụng tiềm năng bao gồm:
- Phát trên quy mô lớn đồng thời nhiều luồng đầu vào
- Phòng học
- Hội nghị truyền hình với khách hàng ở vùng sau vùng xa hoặc với các thiết bị được hỗ trợ
Hybrid Topology
Các kiến trúc kết hợp cho phép bạn duy trì kết hợp các kiến trúc peer-to-peer, chuyển tiếp chọn lọc và điều khiển đa điểm (mixing). Trong môi trường kết hợp, cấu trúc liên kết có thể thay đổi khi số lượng người tham gia tăng hoặc giảm. Ví dụ: nếu việc ghi là quan trọng, bắt đầu với cấu trúc liên kết chuyển tiếp có chọn lọc và sau đó chuyển sang cấu trúc liên kết điều khiển đa điểm xung quanh số lượng 10 người tham gia có thể có ý nghĩa nhất. Nếu chi phí quan trọng hơn tính toàn vẹn của việc ghi, ứng dụng của bạn có thể bắt đầu với cấu trúc liên kết lưới và chuyển đổi khi cần thiết. Ngăn xếp máy chủ LiveSwwivtch của chúng là một ví dụ tuyệt vời về cấu trúc kết hợp và là một trong số ít các máy chủ đa phương tiện kết hợp trên thị trường hiện nay.
5. Tổng kết
