MỞ ĐẦU Ngày nay,tổ chức các buổi hội nghị trực tuyến là một nhu cầu cấp thiếthiện nay đặc biệt trước diễn biến phức tạp của đại dịch toàn cầu covid-19làm hạn chế việc gặp mặt trực tiếp h
Giới thiệu
Tổng quan
Trong bối cảnh xã hội ngày càng phát triển, đời sống mỗi con người đều phát triển mạnh mẽ, các nhu cầu về dịch vụ cũng được nâng cao qua thời gian.
Trong đó, nhu cầu về việc liên lạc - tương tác với nhau ngày được chú ý và phát triển mạnh mẽ Theo lịch sử trước năm 1878, con người chủ yếu liên lạc ở khoảng cách xa với nhau chủ yếu dựa vào bồ câu, và vận chuyển thư bằng người tuy nhiên phương pháp này rất tốn thời gian và không đảm bảo Sau năm 1878, chiếc điên thoại đầu tiên ra đời cho phép truyền âm thanh ở khoảng cách xa với tốc độ và độ chính xác cao hơn, và đặt nền móng cho việc liên lạc sau này.
Hiện này, theo dòng thời gian ta đã có thể thực hiện một cuộc gọi cách nữa vòng Trát Đất rất dễ dàng Tuy nhiên nhu cầu lại đc nâng lên một tầm cao mới, mọi người đều muốn quan sát theo dõi cuộc sống hằng ngày của người mà họ yêu thương qua những video trực tiếp , để có thế thấu hiểu hơn về đối phương Tổ chức các buổi hội nghị trực tuyến là một nhu cầu cấp thiết hiện nay đặc biệt trước diễn biến phức tạp của đại dịch toàn cầu covid-19 làm hạn chế việc gặp mặt trực tiếp hoặc tập trung đông người Ở đây, chúng em đang nghiên cứu về WebRTC, là một web API được phát triển bởi World Wide Web Consortium, khả năng hỗ trợ trình duyệt giao tiếp với nhau thông qua VideoCall để tạo nên một ứng dụng cho phép thực hiện các cuộc gọi video
Phương pháp, kết quả
Tìm hiểu WebRTC là gì? Cách thức nó hoạt động như thế nào Liên kết ra sao với ngôn ngữ lập trình React.
Chuẩn bị môi trường làm làm việc bao gồm các thiết bị cần thiết để phục vụ cho việc lập trình Lên kế hoạch làm việc cho từng giai đoạn làm việc để đảm bảo tiến độ dự án.
Kết quả Đối với một ứng dụng web thì giao diện là môt phần quan trọng không thua kém chức năng cho nên kết quả của đề tài lần này sẽ bào gồm:
Giao diện thân thiện,thuận tiện, sẵn sàng tương tác hỗ trợ người dùng khi ứng dụng – hệ thống gặp vấn đề.
Đảm bào khả năng VideoCall luôn sẵn sàng hoạt động
Cấu trúc đồ án
Tìm hiểu phương pháp WebRTC
Hạn chế và lợi ích của phương pháp
Phân tích thiết kệ hệ thống và triển khai:
Nói rõ đến cách thức hoạt động của phương pháp được chọn
Xây dựng mô hình hoạt động của ứng dụng.
Tiến hành lập trình ứng dụng
Kết luận và hướng phát triển:
Tổng kết những gì đã đạt được qua quá trình xây dựng ứng dụng
Nêu ra những hạn chế tồn tại chưa được giải quyết
Định ra hướng phát triển, khắc phục những hạn chế tồn tại nêu ra trước đó
GIỚI THIỆU VỀ WEBRTC
WebRTC là gì?
Hiểu một cách đơn giản hơn về WebRTC thì nó không chỉ là một sản phẩm hay một hàm API duy nhất Nó là cả một tập hợp rất nhiều các hàm có thể được lập trình viên sử dụng cho nhiều mục đích khác nhau Có hàm chỉ để làm những việc đơn giản như đòi quyền truy cập vào webcam và microphone của máy tính, có hàm phức tạp hơn thì để thiết lập kết nối giữa hai người dùng với nhau, có hàm còn dùng để chia sẻ màn hình với người khác Và rồi có hàm để hai người gọi video cho nhau, cũng là chức năng "nổi tiếng" nhất của WebRTC tính đến thời điểm hiện tại.
Tuy nhiên, tất cả mọi hàm lập trình nằm trong bộ API có một điểm chung vô cùng quan trọng: chúng thực thi hầu hết các tác vụ theo thời gian thực Đó là lý do vì sao chữ Real-Time xuất hiện trong cái tên của bộ hàm này Và nó không chỉ được dùng cho việc gọi video giữa hai trình duyệt mà người ta còn có thể làm nhiều chuyện khác, miễn là chuyện đó có liên quan đến việc làm cho hai hoặc nhiều người dùng liên lạc với nhau.
Lợi ích của WebRTC
Giảm giá thành: chi phí triển khai và hỗ trợ IT thấp vì không cần cài đặt phần mềm client đặc biệt nào phía client.
Không Plugins: trước đây phải sử dụng Flash, Java Applets và các giải pháp khác để xây dựng ứng dụng web tương tác đa phương tiện, phải download và cài đặt các plugin của bên thứ ba để có thể sử dụng nội dung đa phương tiện, ngoài ra còn phải lưu ý đến những giải pháp/plugin cho các hệ điều hành và nền tảng (platform) khác nhau Với WebRTC thì không cần quan tâm đến vấn đề này nữa.
Truyền thông P2P: trong đa phần các trường hợp, truyền thông được thiết lập trực tiếp giữa trình duyệt, không cần có những điểm trung gian.
Dễ sử dụng: có thể dễ dàng tích hợp tính năng WebRTC trong dịch vụ web/trang web bằng cách sử dụng JavaScript APIs, những framework đã có sẵn.
Một giải pháp cho mọi nền tảng: không cần phát triển những phiên bản dịch vụ web cho những nền tảng khác nhau (Windows, Android, IOS…)
Mã mở và miễn phí: WebRTC được Google đưa thành dự án mã nguồn mở, và được hỗ trợ bởi những công ty quốc tế như Mozilla, Google và Opera, thêm cộng đồng trên thế giới có thể phát hiện những lỗi mới và giải quyết nhanh chóng hoàn toàn miễn phí
Built-in security: WebRTC quy định mọi dữ liệu truyền P2P đều được bảo mật và mã hóa.
WebRTC dùng để làm gì ?
WebRTC cung cấp khả năng đa phương tiện một cách mạnh mẽ cho Web, bao gồm hỗ trợ âm thanh, video, trao đổi tệp Kết nối giữa các peer có thể được thực hiện mà không yêu cầu một trình điều khiển đặc biệt hoặc plugin nào và nó có thể thực hiện mà không cần bất kỳ máy chủ trung gian nào.
Kết nối giữa 2 peer được tạo nên và đại diện bởi interface RTCPeerConnection Một khi kết nối được thiết lập và mở thì các luồng truyền thông (MediaStreams) hoặc kênh dữ liệu (RTCDataChannels) có thể được thêm vào kết nối.
Các luồng truyền thông có thể bao gồm một số lượng bất kỳ các track của thông tin đa phương tiện Tracks được đại diện bởi đối tượng dựa vào interface MediaStreamTrack có thể chứa một số loại dữ liệu truyền thông bao gồm âm thanh, video, văn bản Hầu hết các luồng bao gồm ít nhất một bản âm thanh và có thể cũng là video, cũng có thể được sử dụng để gửi và nhận đa phương tiện truyền thông trực tiếp hoặc thông tin đa phương tiện được lưu trữ.
Một trong những trang web được biết đến khá nhiều trong giới lập trình viên WebRTC đó là Appear.in ra mắt hồi năm 2012 Dịch vụ này hỗ trợ người dùng tạo một phòng chat video cực kì nhanh chóng chỉ bằng cách dùng Chrome hoặc Firefox gốc, không cần phải cài thêm bất kì một plugin nào Thậm chí người ta còn không cần phải đăng nhập hay tạo tài khoản như các app chat video hiện nay.
Nói tóm lại, WebRTC có thể được sử dụng cho nhiều mục đích, từ việc truyền tải video, âm thanh cho đến gửi dữ liệu theo thời gian thực giữa hai hoặc nhiều thiết bị với nhau mà không nhất thiết phải đi qua server trung gian Điều này giúp giảm độ trễ trong việc truyền tải, giảm độ phức tạp khi phát triển ứng dụng cũng như giảm chi phí vận hành (vì không phải trả tiền thuê server, tiền điện, tiền bảo dưỡng ), kéo theo đó giá bán dịch vụ nếu có thì cũng sẽ thấp hơn.
Giao tiếp Peer-To-Peer
Để có thể giao tiếp lẫn nhau thông qua trình duyệt web, mỗi trình duyệt của user phải thực hiện những bước sau đây:
Đồng ý để bắt đầu giao tiếp
Biết cách xác định vị trí của đối tượng
Vượt qua an ninh và tưởng lửa bảo vệ
Chuyển giao tất cả các giao tiếp đa phương tiện theo real-time
Một trong số những thách thức lớn nhất liên quan đến các giao tiếp P2P dựa trên trình duyệt là làm sao để biết vị trí & thiết lập 1 kết nối socket mạng
(network socket connection) với 1 trình duyệt khác để vận chuyển dữ liệu 2 chiều Ta sẽ xem xét những khó khăn liên quan đến việc thiết lập kết nối này.
Khi web app của bạn cần dữ liệu hoặc tài nguyên, nó sẽ lấy về từ các server.Tuy nhiên, nếu bạn muốn tạo ra 1 ứng dụng video chat chẳng hạn, bằng cách kết nối trực tiếp đến trình duyệt của người khác - thì đây là vấn đề, vì bạn không biết địa chỉ bởi vì trình duyệt của người kia không phải là 1 web server Vì vậy để có thể thiết lập 1 kết nối P2P ta cần rất nhiều thứ.
Tường lửa và NAT Traversal
Thường thì máy tính của bạn không không có địa chỉ IP public tĩnh Lý do là máy tính của bạn phải núp đằng sau tường lửa và thiết bị NAT (Network access translation - Bộ phiên dịch truy cập mạng).
Thiết bị NAT sẽ dịch địa chỉ IP cá nhân từ bên trong tường lửa thành địa chỉ
IP công khai (public-facing IP) Ta cần các thiết bị NAT để bảo mật và giải quyết sự giới hạn của IPv4 đối với những địa chỉ IP công khai sẵn có Đó là lý do tại sao webapp không nên giả định rằng thiết bị hiện tại có 1 địa chỉ IP public tĩnh.
Cùng tìm hiểu 1 chút về cách hoạt động của các thiết bị NAT Nếu như bạn đang ở trong môi trường công cộng và kết nối vào mạng WiFi, máy tính của bạn sẽ được gán 1 địa chỉ IP mà nó chỉ tồn tại đằng sau NAT Giả sử IP là 172.0.23.4, tuy nhiên, với thế giới bên ngoài, địa chỉ IP của bạn có thể mang giá trị khác, ví dụ 164.53.27.98 Vì vậy, thế giới bên ngoài sẽ thấy các request của bạn đến từ địa chỉ 164.53.27.98 nhưng thiết bị NAT sẽ đảm bảo các response cho những request (được gửi từ máy của bạn) sẽ trả về đúng chỗ là 172.0.23.4 Ơn trời các bảng ánh xạ (mapping table) Lưu ý rằng ngoài địa chỉ
IP thì cổng (port) cũng là điều kiện cần thiết cho các giao tiếp mạng.
Do có sự tham gia của các thiết bị NAT, trình duyệt của bạn cần tìm được địa chỉ IP của máy tính có trình duyệt mà bạn muốn giao tiếp.
Đến đây thì ta lại phải nhờ đến các server STUN (Session Traversal Utilities for NAT - Tiện ích truyền tải theo phiên cho NAT) và TURN (Traversal Using Relays around NAT - Truyền tải sử dụng điểm chuyển tiếp vòng quanh NAT). Để các công nghệ WebRTC hoạt động được, đầu tiên thì 1 request hỏi địa chỉ
IP public của bạn sẽ được gửi đến server STUN Bạn cứ nghĩ theo hướng kiểu như máy tính đang tạo truy vấn đến 1 server từ xa để hỏi về địa chỉ IP mà server đó nhận câu truy vấn là bao nhiêu Server từ xa sẽ trả về địa chỉ IP mà nó thấy Nói ngắn gọn là máy tính của bạn “hỏi” 1 server từ xa địa chỉ IP của chính máy bạn là bao nhiêu.
Giả sử tiến trình này hoạt động bình thường và bạn nhận được địa chỉ IP public của mình cũng như số port, bạn sẽ có thể nói với những peer ngang hàng khác làm thế nào để kết nối trực tiếp đến bạn Những peer này cũng có thể làm cùng 1 việc là sử dụng STUN & server TURN và nói cho bạn biết nên liên lạc đến địa chỉ nào.
Signaling, Sessions
Quá trình khám phá thông tin mạng được mô tả ở trên chỉ là 1 phần của chủ đề về Signaling to bự hơn nhiều, trong trường hợp của WebRTC thì phần signaling này dựa trên 1 chuẩn JSEP (Javascript Session Establishment Protocol - Giao thức thiết lập phiên của Javascript) Signaling bao gồm cả khám phá mạng (network discovery) và NAT Traversal, tạo và quản lý phiên, bảo mật giao tiếp, siêu dữ liệu (metadata) và phối hợp khả năng của media, xử lý lỗi.
Để kết nối có thể hoạt động, peer thu được những điều kiện về local media cho metadata (ví dụ: những khả năng về kích thước và kiểu codec) và gom góp các địa chỉ mạng có thể có cho host của ứng dụng Cơ chế signaling dùng để truyền tới/lui những thông tin quan trọng này không được định nghĩa trong API của WebRTC.
Signaling không được quy định bởi chuẩn WebRTC và nó không được triển khai bằng API của nó để cho phép sử dụng một cách linh động các công nghệ và giao thức cần thiết Các WebRTC developer sẽ đối phó với signaling và server xử lý signaling Phần đàm phán và thiết lập khởi tạo phiên xảy ra khi dùng 1 giao thức signaling/giao tiếp được đặc tả trong các giao tiếp đa phương tiện Giao thức này cũng chịu trách nhiệm cho việc điều hành các quy định trong đó phiên được quản lý và hủy bỏ.
Một trong số các giao thức như vậy có tên là Session Initiation Protocol (SIP
- Giao thức khởi tạo phiên) Lưu ý rằng do sự linh động của WebRTC signaling, SIP không phải là giao thức signaling duy nhất có thể dùng Giao thức signaling được chọn phải hoạt động với 1 giao thức ở tầng ứng dụng gọi là Session Description Protocol (SDP - Giao thức mô tả phiên), giao thức này được sử dụng trong trường hợp của WebRTC Tất cả các metadata đa phương tiện cụ thể được truyền đi bằng giao thức SDP này.
Bất kỳ peer nào (ví dụ: app tận dụng WebRTC) thử giao tiếp với 1 peer khác đều sinh ra 1 tập các ứng viên giao thức Interactive Connectivity Establishment (ICE - Thiết lập kết nối tương tác) Những ứng viên này biểu diễn 1 bộ kết hợp của địa chỉ IP, port, giao thức giao vận được dùng Lưu ý rằng 1 máy tính có thể có nhiều giao diện mạng (không dây, có dây, vân vân), vì thế có thể được gán nhiều địa chỉ IP cho mỗi giao diện.
Hình 1 Sơ đồ về sự trao đổi giữa 2 peer qua các tín hiệu, phiên và giao thức
WebRTC’s protocols
Giao thức quan trọng nhất mà WebRTC sử dụng là Secure Real-time Transport Protocol, hay SRTP [17] SRTP đượ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 hoặ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.
WebRTC sử dụng SCTP - Stream Control Transmission Protocol [15] để truyền các 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 Tuy nhiên trong WebRTC, SCTP chạy trên DTLS trên UDP SCTP được lựa chọn do có những tính năng tốt nhấ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.
WebRTC sử dụng Session Description Protocol, SDP [18], được encode trong đối tượng RTCSessionDescription, để mô tả đặc tính media của hai đầu trong kết nối P2P như loại media đề truyền/nhận (audio, video, application data), network transports, loại codecs sử dụng và cấu hình, thông tin băng thông, và các thông tin metadata khác.Thông điệp SDP được trao đổi qua máy chủ báo hiệu hay còn gọi là được trao đổi qua kênh báo hiệu Máy chủ báo hiệu có trách nhiệm gửi và nhận tất cả thông điệp đến tất cả các peers mà mong muốn kết nối đến peer khác Mặc dù SDP là định dạng dữ liệu dùng để trao đổi, thống nhất thông số giữa kết nối Peer- to-Peer, nhưng do WebRTC không ràng buộc cho các SDP “offer” và
“answer” giao tiếp như nào, nên nó không được thể hiện ở hình 2.7 ở trên.
Tuy nhiên, mô hình offer/answer được thiết kế tuân thủ theo RFC3264 [24].
Datagram Transport Layer Security- DTLS [16] dựa trên giao thức TLS, cung cấp tính bảo mật và toàn vẹn dữ liệu truyền giữa các ứng dụng tương tự TLS [19] Tuy nhiên, WebRTC sử dụng DTLS do nó chạy trên giao thức UDP thích hợp với việc vượt NAT cho các ứng dụng P2P Tất cả các dữ liệu truyền P2P đều được bảo mật sử dụng DTLS Cụ thể hơn, DTLS được sử dụng trong việc thống nhất khóa bảo mật cho việc mã hóa dữ liệu media và trong việc bảo mật sự vận chuyển dữ liệu ứng dụng Mặc dù cung cấp tính mã hóa, tính toàn vẹn, nhưng phần xác thực trong WebRTC được gán cho ứng dụng.
Session Traversal Utilities for NAT, STUN [14]: là giao thức giúp cho việc vượt NAT trong quá trình thiết lập kết nối Trong WebRTC, một STUN client sẽ được xây dựng trong User Agent của trình duyệt để kết nối đến STUN server ngoài Internet.STUN server thực thi nhiệm vụ khá đơn giản, kiểm tra thông tin địa chỉ IP, port của request đến từ ứng dụng sau NAT, sau đó trả thông tin đó về dưới dạng response, nói cách khác là STUN giúp ứng dụng biết địa chỉ IP, cổng của nó sử dụng khi đi ra Internet STUN có thể được vận chuyển trên UDP, TCP hoặc TLS
Trong đa số các trường hợp thì chỉ cần sử dụng STUN trong việc thiết lập kết nối P2P, trừ trường hợp một peer đứng sau symmetric NAT, một peer đứng sau Symmetric NAT hoặc port-restricted NAT Trường hợp này quá trình hole punching [20] sẽ không thành công, cần phải sử dụng đến TURN - Traversal Using Relays around NAT [21].
Traversal Using Relays around NAT, TURN, là một mở rộng (extension) của giao thức STUN, cung cấp media relay cho tình huống thực hiện hole punching không thành công Trong WebRTC, User Agent của trình duyệt sẽ bao gồm một TURN client TURN server được cung cấp trên Internet qua các nhà cung cấp dịch vụ, hoặc có thể cài đặt trong mạng doanh nghiệp Giao thức UDP được sử dụng để giao tiếp giữa TURN client và TURN server qua NAT Cổng UDP mặc định cho TURN là 3478 Trên thực tế TURN server thường là STUN server có bổ sung tính năng relay TURN server thì có chức năng STUN, nhưng không phải mọi STUN server đều có chức năng TURN.
Interactive Communication Establishment, hay ICE [13] là giao thức rất quan trọng trong WebRTC, có hai chức năng chính: cho phép WebRTC client trao đổi media qua thiết bị có thực hiện NAT và cung cấp sự xác minh việc chấp thuận giao tiếp giữa client, giúp gói tin media chỉ được gửi đến trình duyệt mà đang đợi dữ liệu Một ứng dụng web độc hại có thể lừa trình duyệt gửi dữ liệu media đến một host trên Internet mà không phải là thành phần muốn giao tiếp Kiểu tấn công này là tấn công từ chối dịch vụ DOS (Denial of Service), và ICE thành công trong việc ngăn ngừa điều này vì dữ liệu media không bao giờ được gửi trừ khi quá trình trao đổi ICE kết thúc thành công.ICE sử dụng kỹ thuật hole punching [20], kỹ thuật được tiên phong bởi các game thủ chơi online, những người cần trao đổi gói tin trực tiếp giữa các PCs cho dù giữa chúng có NAT Hole punching là kỹ thuật cho phép “đục lỗ” qua thiết bị NAT để thiết lập kết nối trực tiếp giữa ứng dụng ngay cả khi cả hai đầu ứng dụng đều nằm sau NAT.Để hole punching thành công cần thỏa mãn một số các yêu cầu:
- Hai trình duyệt muốn thiết lập kết nối trực tiếp phải gửi gói hole punching cùng thời điểm Nhờ vậy cả hai trình duyệt mới nhận ra session cần thiết lập và biết các địa chỉ để gửi gói tin Gói tin hole punching là gói tin IP thông thường được gửi để kiểm tra có đến được địa chỉ đích (sau NATs) không
- Hai trình duyệt phải biết càng nhiều địa chỉ IP mà có thể sử dụng để kết nối đến peer càng tốt Các địa chỉ này các địa chỉ nội bộ (trong NAT), địa chỉ public (ngoài NAT) và địa chỉ relay.
- Cả hai trình duyệt phải kết nối đến được địa chỉ IP Public của media relay.
- Dòng đối xứng phải được sử dụng Lưu lượng UDP phải xuất hiện để hoạt động tương tự cách của kết nối TCP
Yêu cầu đầu tiên thỏa mãn khi sử dụng máy chủ web để điều phối quá trình hole punching, bởi máy chủ web biết có nhu cầu mong muốn thiết lập giữa hai trình duyệt,do đó nó đảm bảo việc hai trình duyệt bắt đầu quá trình hole punching cùng thời điểm ở mức tương đối Yêu cầu thứ 2 được thỏa mãn bằng cách dùng STUN Server Yêu cầu thứ 3 được thỏa mãn khi dùng TURN Server Trình duyệt ưu tiên truy vấn đến STUN server trước để khởi động quá trình hole punching, sau đó mới truy vấn đến TURN server để lấy địa chỉ media relay Địa chỉ media relay là địa chỉ public, giúp chuyển tiếp gói tin đến và đi từ trình duyệt thiết lập địa chỉ relay Địa chỉ này sau đó sẽ được thêm vào danh sách địa chỉ ứng viên (Địa chỉ ứng viên gồm địa chỉ IP và cổng UDP) Yêu cầu 4 được đáp ứng bởi trình duyệt gửi media từ cùng 1 cổng UDP mà trình duyệt sử dụng để lắng nghe media đến Điều này làm cho
2 phiên một chiều RTP trên UDP xuất hiện với NAT như là một phiên RTP hai chiều.
Trong đa số các trường hợp thì hole puching thành công, kết nối peer-to-peer được thiết lập, luồng media không relay qua máy chủ Luồng media chỉ relay qua máy chủ khi mọi đường media đều thiết lập không thành công.
Quy trình hoạt động của ICE: Để thiết lập được đường định tuyến giữa các peer, WebRTC, cụ thể là đối tượng PeerConnection có một ICE agent cho nhiều nhiệm vụ như thu thập thông tin địa chỉ ứng viên, kiểm tra kết nối giữa các peer, gửi các thông tin keepalives.
Media server
WebRTC là một tập hợp các giao thức, cơ chế và API cung cấp trình duyệt và ứng dụng di động với Real-Time Communications (RTC) thông qua kết nối peer-to-peer Nó đã được hình thành như một công nghệ cho phép trình duyệt để giao tiếp trực tiếp mà không cần qua trung gian của bất kỳ loại cơ sở hạ tầng nào Tuy nhiên, mô hình này chỉ đủ để tạo các ứng dụng web cơ bản; các tính năng như liên lạc nhóm, ghi dòng phương tiện, phương tiện truyền thông phát sóng, hoặc chuyển mã phương tiện rất khó thực hiện Vì lý do này, nhiều ứng dụng yêu cầu một máy chủ phương tiện trung gian.
Về mặt khái niệm, WebRTC media servers chỉ là một phần mềm trung gian đa phương tiện, nơi lưu lượng phương tiện truyền thông đi qua khi di chuyển từ nguồn đến đích.
Media servers có khả năng xử lý các luồng phương tiện đến và cung cấp các kết quả khác nhau, chẳng hạn như:
Group Communications: Phân phối giữa một số người nhận luồng phương tiện mà một người ngang hàng tạo ra, tức là hoạt động như một đơn vị nhiều hội nghị (NGÀY MCU).
Mixing: Chuyển đổi một số luồng đến thành một luồng tổng hợp duy nhất.
Transcoding: Thích ứng nhanh chóng các codec và định dạng giữa các máy khách không tương thích.
Recording: Lưu trữ một cách liên tục các phương tiện truyền thông trao đổi giữa các đồng nghiệp.
Các API của WebRTC
Có 3 mục phân loại API chính trong WebRTC:
Media Capture and Streams (luồng media và chụp media): cho phép bạn truy xuất vào các thiết bị đầu vào, chẳng hạn như microphone hay web camera API cho phép bạn lấy 1 luồng media từ các thiết bị đó.
RTCPeerConnection - dùng những API này, bạn có thể gửi theo thời gian thực 1 luồng âm thanh & hình ảnh đã bắt được thông qua internet đến 1 endpoint WebRTC khác Bạn có thể tạo ra kết nối giữa máy local và peer từ xa Nó cũng cung cấp các phương thức để kết nối đến 1 peer từ xa, duy trì và kiểm soát kết nối & đóng kết nối 1 khi ta không cần đến nó nữa.
RTCDataChannel - API này cho phép bạn truyền dữ liệu tùy ý Mỗi kênh dữ liệu được liên kết với 1 RTCPeerConnection.
CÁC BƯỚC TẠO RA WEBRTC
Bắt đầu với Media devices
Khi phát triển cho web, tiêu chuẩn WebRTC cung cấp các API để truy cập máy ảnh và micro được kết nối với máy tính hoặc điện thoại thông minh Các thiết bị này thường được gọi là Thiết bị Phương tiện và có thể được truy cập bằng JavaScript thông qua đối tượng navigator.mediaDevices, đối tượng này thực thi MediaDevices giao diện Từ đối tượng này, chúng ta có thể liệt kê tất cả các thiết bị được kết nối, lắng nghe các thay đổi của thiết bị (khi thiết bị được kết nối hoặc ngắt kết nối) và mở một thiết bị để lấy Media Stream.
Cách phổ biến nhất được sử dụng là thông qua hàm getUserMedia(), hàm này trả về một lời hứa sẽ giải quyết thành một MediaStream cho các thiết bị phương tiện phù hợp Hàm này nhận một đối tượng MediaStreamConstraints xác định các yêu cầu mà chúng ta có Ví dụ, để chỉ cần mở micrô và máy ảnh mặc định, chúng tôi sẽ làm như sau.
Lệnh gọi tới getUserMedia()sẽ kích hoạt một yêu cầu quyền Nếu người dùng chấp nhận quyền, lời hứa sẽ được giải quyết bằng một MediaStream đoạn video và một đoạn âm thanh Nếu quyền bị từ chối, một
PermissionDeniedError sẽ được ném Trong trường hợp không có thiết bị phù hợp nào được kết nối, một NotFoundError sẽ được ném ra.
Truy vấn thiết bị phương tiện
Trong một ứng dụng phức tạp hơn, rất có thể chúng tôi sẽ muốn kiểm tra tất cả các máy ảnh và micrô được kết nối và cung cấp phản hồi thích hợp cho người dùng Điều này có thể được thực hiện bằng cách gọi hàm enumerateDevices() Điều này sẽ trả về một lời hứa phân giải thành một mảng MediaDevicesInfo mô tả từng thiết bị phương tiện đã biết Chúng tôi có thể sử dụng điều này để trình bày giao diện người dùng cho người dùng để họ chọn giao diện người dùng họ thích Mỗi MediaDevicesInfochứa một thuộc tính được đặt tên kindvới giá trị audioinput, audiooutputhoặc videoinput, nêu rõ là loại thiết bị phương tiện truyền thông.
Lắng nghe các thay đổi của thiết bị
Hầu hết các máy tính đều hỗ trợ cắm nhiều thiết bị khác nhau trong thời gian chạy Đó có thể là một webcam được kết nối bằng USB, tai nghe Bluetooth hoặc một bộ loa ngoài Để hỗ trợ đúng cách này, ứng dụng web phải lắng nghe những thay đổi của thiết bị phương tiện Điều này có thể được thực hiện bằng cách thêm một người nghe navigator.mediaDevices cho devicechange sự kiện.
Ràng buộc về phương tiện
Đối tượng ràng buộc, phải triển khai MediaStreamConstraints giao diện, mà chúng ta chuyển vào dưới dạng tham số để getUserMedia() cho phép chúng ta mở một thiết bị phương tiện phù hợp với một yêu cầu nhất định Yêu cầu này có thể được xác định rất lỏng lẻo (âm thanh và / hoặc video), hoặc rất cụ thể (độ phân giải máy ảnh tối thiểu hoặc ID thiết bị chính xác) Các ứng dụng sử dụng getUserMedia() API trước tiên nên kiểm tra các thiết bị hiện có và sau đó chỉ định một ràng buộc phù hợp với thiết bị chính xác bằng cách sử dụng deviceId ràng buộc Các thiết bị cũng sẽ được cấu hình theo các ràng buộc nếu có thể Chúng tôi có thể bật tính năng khử tiếng vọng trên micrô hoặc đặt chiều rộng và chiều cao cụ thể hoặc tối thiểu của video từ máy ảnh.
Sau khi thiết bị phương tiện đã được mở và chúng tôi có MediaStreamsẵn, chúng tôi có thể gán thiết bị đó cho phần tử video hoặc âm thanh để phát trực tuyến cục bộ.
HTML cần thiết cho một phần tử video điển hình được sử dụng getUserMedia() thường sẽ có các thuộc tính autoplayvà playsinline Các autoplay thuộc tính sẽ gây ra con suối mới giao cho nguyên tố này để chơi tự động Các playsinlinethuộc tính cho phép video để chơi inline, thay vì chỉ trên toàn màn hình, trên các trình duyệt di động nào đó Nó cũng được khuyến nghị sử dụng controls="false"cho các luồng trực tiếp, trừ khi người dùng có thể tạm dừng chúng.
Nắm bắt phương tiện và các ràng buộc
Phần phương tiện của WebRTC bao gồm cách truy cập vào phần cứng có khả năng thu video và âm thanh, chẳng hạn như máy ảnh và micrô, cũng như cách hoạt động của các luồng phương tiện Nó cũng bao gồm phương tiện hiển thị, đó là cách một ứng dụng có thể thực hiện chụp màn hình.
Tất cả các camera và micrô được trình duyệt hỗ trợ đều được truy cập và quản lý thông qua navigator.mediaDevicesđối tượng Các ứng dụng có thể truy xuất danh sách thiết bị được kết nối hiện tại và cũng có thể lắng nghe các thay đổi, vì nhiều máy ảnh và microhpones kết nối qua USB và có thể được kết nối và ngắt kết nối trong vòng đời của ứng dụng Vì trạng thái của thiết bị media có thể thay đổi bất kỳ lúc nào, nên các ứng dụng nên đăng ký các thay đổi của thiết bị để xử lý các thay đổi đúng cách.
Khi truy cập vào các thiết bị media, bạn nên cung cấp các ràng buộc chi tiết nhất có thể Mặc dù có thể mở máy ảnh và micrô mặc định với một hạn chế đơn giản, nhưng nó có thể cung cấp một luồng phương tiện khác xa mức tối ưu nhất cho ứng dụng.
Các ràng buộc cụ thể được xác định trong một MediaTrackConstraintđối tượng, một cho âm thanh và một cho video Các thuộc tính trong đối tượng này là các loại ConstraintLong, ConstraintBoolean, ConstraintDoublehoặc ConstraintDOMString Đây có thể là một giá trị cụ thể (ví dụ: một số, boolean hoặc chuỗi), một phạm vi ( LongRangehoặc DoubleRangevới giá trị nhỏ nhất và lớn nhất) hoặc một đối tượng với một idealhoặc một exactđịnh nghĩa Đối với một giá trị cụ thể, trình duyệt sẽ cố gắng chọn thứ gì đó càng gần càng tốt Đối với một phạm vi, giá trị tốt nhất trong phạm vi đó sẽ được sử dụng Khi exactđược chỉ định, chỉ các luồng phương tiện khớp chính xác với ràng buộc đó mới được trả về.Để xác định cấu hình thực tế mà một bản nhạc nhất định của luồng phương tiện có, chúng ta có thể gọi cấu hình MediaStreamTrack.getSettings()trả về MediaTrackSettingshiện đang được áp dụng.
Cũng có thể cập nhật các ràng buộc của bản nhạc từ thiết bị đa phương tiện mà chúng tôi đã mở, bằng cách gọi applyConstraints()trên bản nhạc Điều này cho phép ứng dụng định cấu hình lại thiết bị phương tiện mà trước tiên không phải đóng luồng hiện có.
Một ứng dụng muốn có thể thực hiện quay và chụp màn hình phải sử dụng API phương tiện hiển thị Hàm getDisplayMedia()(một phần của hàm navigator.mediaDevicesnày tương tự getUserMedia()và được sử dụng cho mục đích mở nội dung của màn hình (hoặc một phần của nó, chẳng hạn như cửa sổ) Hàm trả về MediaStreamhoạt động giống như khi sử dụng getUserMedia() Các ràng buộc cho getDisplayMedia()khác với các ràng buộc được sử dụng cho đầu vào video hoặc âm thanh thông thường.
A MediaStream đại diện cho một luồng nội dung đa phương tiện, bao gồm các bản nhạc ( MediaStreamTrack) âm thanh và video Bạn có thể truy xuất tất cả các bản nhạc từ đó MediaStreambằng cách gọi
MediaStream.getTracks(), thao tác này trả về một mảng MediaStreamTrack đối tượng.
A MediaStreamTrackcó một thuộc tính là audio hoặc video, cho biết loại phương tiện mà nó đại diện Mỗi bản nhạc có thể bị tắt tiếng bằng cách chuyển đổi thuộc tính của nó enabled Một bản nhạc có thuộc tính Boolean remotecho biết nó có được lấy nguồn bởi a RTCPeerConnectionvà đến từ một đồng đẳng từ xa hay không.
Bắt đầu với Peer-connection
Kết nối ngang hàng là một phần của thông số kỹ thuật WebRTC đề cập đến việc kết nối hai ứng dụng trên các máy tính khác nhau để giao tiếp bằng giao thức ngang hàng Giao tiếp giữa các đồng nghiệp có thể là video, âm thanh hoặc dữ liệu nhị phân tùy ý (đối với các ứng dụng khách hỗ trợ RTCDataChannelAPI) Để khám phá cách hai máy khách có thể kết nối, cả hai máy khách cần cung cấp cấu hình Máy chủ ICE Đây là máy chủ STUN hoặc máy chủ TURN và vai trò của chúng là cung cấp các ứng viên ICE cho mỗi máy khách, sau đó được chuyển đến máy ngang hàng từ xa Việc chuyển các ứng viên ICE này thường được gọi là báo hiệu.
Đặc tả WebRTC bao gồm các API để giao tiếp với Máy chủ ICE (Thiết lập Kết nối Internet), nhưng thành phần báo hiệu không phải là một phần của nó. Báo hiệu là cần thiết để hai đồng nghiệp chia sẻ cách họ nên kết nối Thông thường điều này được giải quyết thông qua API Web dựa trên HTTP thông thường (tức là dịch vụ REST hoặc cơ chế RPC khác) nơi các ứng dụng web có thể chuyển tiếp thông tin cần thiết trước khi kết nối ngang hàng được bắt đầu.
Đoạn mã sau cho thấy cách dịch vụ báo hiệu hư cấu này có thể được sử dụng để gửi và nhận tin nhắn không đồng bộ Điều này sẽ được sử dụng trong các ví dụ còn lại trong hướng dẫn này khi cần thiết.
// Set up an asynchronous communication channel that will be
// used during the peer connection setup const signalingChannel = new SignalingChannel(remoteClientId); signalingChannel.addEventListener('message', message => {
// New message from remote client received
// Send an asynchronous message to the remote client signalingChannel.send('Hello!');
Báo hiệu có thể được thực hiện theo nhiều cách khác nhau và đặc tả WebRTC không thích bất kỳ giải pháp cụ thể nào.
Khởi tạo kết nối ngang hàng
Mỗi kết nối ngang hàng được xử lý bởi một RTCPeerConnectionđối tượng. Hàm tạo cho lớp này nhận một RTCConfigurationđối tượng duy nhất làm tham số của nó Đối tượng này xác định cách kết nối ngang hàng được thiết lập và phải chứa thông tin về các máy chủ ICE để sử dụng.
Sau khi RTCPeerConnection được tạo, chúng tôi cần tạo một phiếu mua hàng hoặc câu trả lời SDP, tùy thuộc vào việc chúng tôi là đồng nghiệp đang gọi hay nhận Sau khi đề nghị hoặc câu trả lời SDP được tạo, nó phải được gửi đến đồng đẳng từ xa thông qua một kênh khác Việc chuyển các đối tượng SDP đến các đối tượng từ xa được gọi là báo hiệu và không được quy định trong đặc tả WebRTC.
Để bắt đầu thiết lập kết nối ngang hàng từ phía gọi, chúng tôi tạo một RTCPeerConnectionđối tượng và sau đó gọi createOffer()để tạo một RTCSessionDescriptionđối tượng Mô tả phiên này được đặt làm mô tả cục bộ bằng cách sử dụng setLocalDescription()và sau đó được gửi qua kênh báo hiệu của chúng tôi tới phía nhận Chúng tôi cũng thiết lập một bộ lắng nghe kênh tín hiệu của chúng tôi khi nhận được câu trả lời cho mô tả phiên được cung cấp của chúng tôi từ phía bên nhận. async function makeCall() { const configuration = {'iceServers': [{'urls': 'stun:stun.l.google.com:19302'}]} const peerConnection = new RTCPeerConnection(configuration); signalingChannel.addEventListener('message', async message => { if (message.answer) { const remoteDesc = new RTCSessionDescription(message.answer); await peerConnection.setRemoteDescription(remoteDesc);
}); const offer = await peerConnection.createOffer(); await peerConnection.setLocalDescription(offer); signalingChannel.send({'offer': offer});
Ở phía bên nhận, chúng tôi chờ một đề nghị đến trước khi chúng tôi tạo RTCPeerConnectionphiên bản của mình Khi điều đó được thực hiện, chúng tôi đặt ưu đãi nhận được bằng cách sử dụng setRemoteDescription() Tiếp theo, chúng tôi gọi createAnswer()để tạo câu trả lời cho ưu đãi đã nhận Câu trả lời này được đặt làm mô tả cục bộ bằng cách sử dụng setLocalDescription()và sau đó được gửi đến bên gọi qua máy chủ báo hiệu của chúng tôi. const peerConnection = new RTCPeerConnection(configuration); signalingChannel.addEventListener('message', async message => { if (message.offer) { peerConnection.setRemoteDescription(new RTCSessionDescription(message.offer)); const answer = await peerConnection.createAnswer(); await peerConnection.setLocalDescription(answer); signalingChannel.send({'answer': answer});
Một khi hai đồng đẳng đã đặt cả mô tả phiên cục bộ và từ xa, họ biết khả năng của đồng đẳng từ xa Điều này không có nghĩa là kết nối giữa các đồng nghiệp đã sẵn sàng Để làm được điều này, chúng ta cần thu thập các ứng viên ICE ở mỗi đồng nghiệp và chuyển (qua kênh tín hiệu) cho đồng đẳng khác. Ứng viên ICE
Trước khi hai đồng nghiệp có thể giao tiếp bằng WebRTC, chúng cần trao đổi thông tin kết nối Vì các điều kiện mạng có thể thay đổi tùy thuộc vào một số yếu tố, một dịch vụ bên ngoài thường được sử dụng để phát hiện các ứng cử viên có thể kết nối với một mạng ngang hàng Dịch vụ này được gọi là ICE và đang sử dụng máy chủ STUN hoặc TURN STUN là viết tắt của Session Traversal Utilities cho NAT, và thường được sử dụng gián tiếp trong hầu hết các ứng dụng WebRTC.
TURN (Traversal using Relay NAT) là giải pháp tiên tiến hơn kết hợp các giao thức STUN và hầu hết các dịch vụ dựa trên WebRTC thương mại sử dụng máy chủ TURN để thiết lập kết nối giữa các đồng nghiệp API WebRTC hỗ trợ trực tiếp cả STUN và TURN, và nó được tập hợp theo thuật ngữ đầy đủ hơn là Thiết lập Kết nối Internet Khi tạo kết nối WebRTC, chúng tôi thường cung cấp một hoặc một số máy chủ ICE trong cấu hình cho RTCPeerConnectionđối tượng.
Khi một RTCPeerConnection đối tượng được tạo, khung cơ bản sử dụng các máy chủ ICE được cung cấp để thu thập các ứng cử viên cho việc thiết lập kết nối (các ứng viên ICE) Sự kiện icegatheringstatechangetrên RTCPeerConnectioncác tín hiệu trong những gì nhà nước thu thập ICE là ( new, gatheringhoặc complete).
Mặc dù một đồng nghiệp có thể đợi cho đến khi quá trình thu thập ICE hoàn tất, nhưng việc sử dụng kỹ thuật "băng nhỏ giọt" và truyền từng ứng viên ICE đến đồng đẳng từ xa sẽ hiệu quả hơn nhiều khi nó được phát hiện Điều này sẽ làm giảm đáng kể thời gian thiết lập cho kết nối ngang hàng và cho phép bắt đầu cuộc gọi điện video với ít độ trễ hơn Để thu thập các ứng cử viên ICE, chỉ cần thêm một người nghe cho icecandidate sự kiện Phần RTCPeerConnectionIceEventphát ra trên bộ lắng nghe đó sẽ chứa thuộc tính đại diện cho một ứng cử viên mới sẽ được gửi đến đồng đẳng từ xa.
Khi các ứng viên ICE đang được nhận, chúng ta nên hy vọng trạng thái cho kết nối ngang hàng của chúng ta cuối cùng sẽ thay đổi thành trạng thái được kết nối Để phát hiện điều này, chúng tôi thêm một người nghe vào RTCPeerConnection nơi chúng tôi lắng nghe các connectionstatechange sự kiện.
Bắt đầu với Media Stream
Sau khi RTCPeerConnectionkết nối với một đồng đẳng từ xa, có thể truyền âm thanh và video giữa chúng Đây là điểm mà chúng tôi kết nối luồng mà chúng tôi nhận được getUserMedia()với RTCPeerConnection. Một luồng phương tiện bao gồm ít nhất một bản nhạc phương tiện và những bản nhạc này được thêm riêng vào thời RTCPeerConnectionđiểm chúng ta muốn truyền phương tiện đó đến đồng đẳng từ xa.
const localStream = await getUserMedia({vide: true, audio: true});
const peerConnection = new RTCPeerConnection(iceConfig);
Các tuyến đường có thể được thêm vào RTCPeerConnectiontrước khi nó được kết nối với một đồng đẳng từ xa, vì vậy, bạn nên thực hiện thiết lập này càng sớm càng tốt thay vì đợi kết nối hoàn tất.
Thêm tuyến đường từ xa
Để nhận các bản nhạc từ xa đã được thêm vào bởi người ngang hàng khác, chúng tôi đăng ký một người nghe trên bản RTCPeerConnectionlắng nghe cục bộ cho tracksự kiện Vì quá trình phát lại được thực hiện trên một MediaStreamđối tượng, trước tiên chúng tôi tạo một thể hiện trống mà sau đó chúng tôi điền các bản nhạc từ đồng đẳng từ xa khi chúng tôi nhận được chúng.
const remoteVideo = document.querySelector('#remoteVideo');
peerConnection.addEventListener('track', async (event) => {
remoteStream.addTrack(event.track, remoteStream);
Kênh dữ liệu
Tiêu chuẩn WebRTC cũng bao gồm một API để gửi dữ liệu tùy ý qua a RTCPeerConnection Điều này được thực hiện bằng cách gọi createDataChannel()một RTCPeerConnectionđối tượng, đối tượng này sẽ trả về một RTCDataChannelđối tượng. const peerConnection = new RTCPeerConnection(configuration); const dataChannel = peerConnection.createDataChannel();
Đồng đẳng từ xa có thể nhận các kênh dữ liệu bằng cách lắng nghe datachannel sự kiện trên RTCPeerConnectionđối tượng Sự kiện nhận được thuộc loại RTCDataChannelEventvà chứa thuộc channeltính đại diện cho sựRTCDataChannelkết nối giữa các đồng nghiệp. const peerConnection = new RTCPeerConnection(configuration); peerConnection.addEventListener('datachannel', event => { const dataChannel = event.channel;
Mở và đóng sự kiện
Trước khi một kênh dữ liệu có thể được sử dụng để gửi dữ liệu, máy khách cần đợi cho đến khi nó được mở Điều này được thực hiện bằng cách lắng nghe opensự kiện Tương tự như vậy, có một closesự kiện xảy ra khi một trong hai bên đóng kênh. const messageBox = document.querySelector('#messageBox'); const sendButton = document.querySelector('#sendButton'); const peerConnection = new RTCPeerConnection(configuration); const dataChannel = peerConnection.createDataChannel();
// Enable textarea and button when opened dataChannel.addEventListener('open', event => { messageBox.disabled = false; messageBox.focus(); sendButton.disabled = false;
// Disable input when closed dataChannel.addEventListener('close', event => { messageBox.disabled = false; sendButton.disabled = false;
Gửi tin nhắn trên a RTCDataChannelđược thực hiện bằng cách gọi send()hàm với dữ liệu mà chúng ta muốn gửi Các datatham số cho hàm này có thể là một chuỗi, một Blob, một ArrayBufferhoặc và ArrayBufferView. const messageBox = document.querySelector('#messageBox'); const sendButton = document.querySelector('#sendButton');
// Send a simple text message when we click the button sendButton.addEventListener('click', event => { const message = messageBox.textContent; dataChannel.send(message);
}) Đồng đẳng từ xa sẽ nhận được tin nhắn được gửi trên a RTCDataChannelbằng cách lắng nghe messagesự kiện. const incomingMessages = document.querySelector('#incomingMessages'); const peerConnection = new RTCPeerConnection(configuration); const dataChannel = peerConnection.createDataChannel();
// Append new messages to the box of incoming messages dataChannel.addEventListener('message', event => { const message = event.data; incomingMessages.textContent += message + '\n';
TURN máy chủ
Đối với hầu hết các ứng dụng WebRTC để hoạt động, một máy chủ được yêu cầu để chuyển tiếp lưu lượng giữa các máy ngang hàng, vì một ổ cắm trực tiếp thường không thể thực hiện được giữa các máy khách (trừ khi chúng nằm trên cùng một mạng cục bộ) Cách phổ biến để giải quyết vấn đề này là sử dụng máy chủ TURN Thuật ngữ này là viết tắt của Traversal using Relay NAT, và nó là một giao thức để chuyển tiếp lưu lượng mạng.
Hiện tại có một số tùy chọn cho máy chủ TURN có sẵn trực tuyến, cả dưới dạng ứng dụng tự lưu trữ (như dự án COTURN mã nguồn mở) và dưới dạng dịch vụ được cung cấp trên đám mây.
Sau khi bạn có một máy chủ TURN trực tuyến, tất cả những gì bạn cần là RTCConfigurationứng dụng khách của bạn có thể sử dụng nó Đoạn mã sau minh họa cấu hình mẫu cho RTCPeerConnectionmáy chủ TURN có tên máy chủ my-turn-server.mycompany.comvà đang chạy trên cổng 19403 Đối tượng cấu hình cũng hỗ trợ các thuộc tính usernamevà credentialsđể đảm bảo quyền truy cập vào máy chủ Đây là những yêu cầu bắt buộc khi kết nối với máy chủ TURN. const iceConfiguration = { iceServers: [
{ urls: 'turn:my-turn-server.mycompany.com:19403', username: 'optional-username', credentials: 'auth-token'
} const peerConnection = new RTCPeerConnection(iceConfiguration);
Phân tích thiết kế hệ thống
Mô hình tổng quan của WebRTC
Cho phép truyền thông thời gian thực trong trình duyệt là một cam kết đầy tham vọng, và có lẽ là một trong những bổ sung quan trọng nhất cho nền tảng web từ khi được hình thành cho đến nay Với kết quả là kiến trúc WebRTC bao gồm rất nhiều tiêu chuẩn, giao thức và API mới để cho nó hoạt động:
Tổ chức W3C chịu trách nhiệm định nghĩa các APIs mới của WebRTC cho trình duyệt.
Tổ chức IETF chịu trách nhiệm định nghĩa các giao thức, định dạng dữ liệu, bảo mật và các khía cạnh cần thiết khác để cho phép truyền thông peer-to-peer trong trình duyệt.
Hình đưới đây mô tả kiến trúc tổng thể của WebRTC.Khối màu nhạt hơn gọi là "chức năng truyền thông thời gian thực của trình duyệt" Chức năng này tương tác với các ứng dụng web sử dụng các API tiêu chuẩn của WebRTC và nó giao tiếp với hệ điều hành thông qua trình duyệt.
Hình 5 Kiến trúc tổng thể của WebRTC
Kiến trúc WebRTC
Kiến trúc web cổ điển dựa trên mô hình client-server, trong đó trình duyệt gửi yêu cầu HTTP đến máy chủ để lấy nội dung, máy chủ trả lời, gửi nội dung về cho trình duyệt dưới dạng HTML, thường kèm theo JavaScript và CascadingStyle Sheets (CSS) Trong trường hợp đơn giản thì khi máy chủ web trả lời yêu cầu từ client bằng thông tin text, hình ảnh hay thông tin khác như client mong muốn Trong trường hợp phức tạp hơn, máy chủ gửi JavaScript để chạy ở phía trình duyệt, tương tác với với trình duyệt qua các JavaScript APIs chuẩn và tương tác với người dùng qua thao tác lựa chọn, click…trên giao diện người dùng Trình duyệt trao đổi thông tin với máy chủ bằng giao hức HTTP trên TCP hoặc WebSockets trên TCP.
WebRTC mở rộng ngữ nghĩa client-server bởi mô hình truyền thông Peer-to- Peer giữa các trình duyệt, thêm máy chủ báo hiệu và thành phần chức năng truyền thông thời gian thực (Real Time Communication hay RTC) của trình duyệt Ứng dụng với WebRTC (thường viết bằng HTML5 và JavaScript) tương tác với trình duyệt qua những WebRTC APIs đang được chuẩn hóa, cho phép nó khai thác hợp lý và điều khiển chức năng thời gian thực của trình duyệt Ứng dụng web với WebRTC cũng tương tác với trình duyệt sử dụng cả những APIs chuẩn hóa khác một cách chủ động (như truy vấn khả năng trình duyệt) hoặc bị động (như tiếp nhận thông báo khởi tạo bởi trình duyệt) Vì thế, WebRTC APIs phải cung cấp tập phong phú chức năng, như chức năng quản lý kết nối (connection management), thống nhất khả năng encoding/decoding, chức năng điều khiển media (media control), hỗ trợ vượt NAT và tường lửa…
Hình cho thấy mô hình trình duyệt và vai trò của các chức năng truyền thông thời gian thực Khối màu sáng là chức năng truyền thông thời gian thực (Real Time Communication – RTC) của trình duyệt Do tính chất riêng và yêu cầu của truyền thông thời gian thực nên việc chuẩn hóa khối này là không đơn giản, hiện tại vẫn đang trong quá trình bàn thảo Các chức năng RTC tương tác với các ứng dụng web sử dụng các APIs chuẩn Nó giao tiếp với các hệ điều hành bằng cách sử dụng trình duyệt
Khía cạnh mới của WebRTC là sự tương tác xảy ra từ trình duyệt đến trình duyệt, gọi là một kết nối Peer-to-Peer (P2P Connection) khi chức năng RTC trong một trình duyệt giao tiếp với chức năng RTC trong một trình duyệt khác tiếp sử dụng giao thức chuẩn trên dây (on-the-wire) hoặc giao tiếp với ứng dụng VoIP, ứng dụng Video Trong khi lưu lượng web sử dụng giao thức TCP để vận chuyển, giao thức trên dây giữa các trình duyệt có thể sử dụng giao thức vận chuyển khác như UDP Khía cạnh mới như nêu ở trên là cần thêm máy chủ báo hiệu (Signaling Server), là máy chủ cung cấp kênh truyền báo hiệu giữa trình duyệt và đầu kia của kết nối Peer Trong WebRTC thì trình duyệt có khả năng truy cập vào phần cứng hệ thống tầng dưới để lấy audio, video đơn giản qua các APIs Các dòng audio, video được xử lý để gia tăng chất lượng, tính đồng bộ, và “output bitrate” được điều chỉnh cho phù hợp với sự tăng giảm của băng thông, độ trễ giữa các client Ở đầu xa, quá trình xử lý diễn ra ngược lại, client phải giải mã dòng media thời gian thực, có khả năng điều chỉnh jiter và độ trễ mạng Dù việc lấy và xử lý audio và video là vấn đề phức tạp, nhưng WebRTC đã mang đến những “engine” audio, video đầy đủ tính năng để thực hiện.
Trong kiến trúc WebRTC có 3 lớp API:
APIs cho nhà lập trình web: lớp này chứa tất cả các APIs mà nhà lập trình web cần, bao gồm các đối tượng chính là RTCPeerConnection,
APIs cho nhà phát triển trình duyệt sử dụng.
Overridable API: nhà phát triển trình duyệt có thể thay đổi, phát triển APIs
Thành phần video engine là framework xử lý chuỗi video từ camera đến mạng và từ mạng ra màn hình Trong đó, video codec sử dụng VP8 (một dạng nén video mở, miễn phí sở hữu bởi Google và tạo ra bởi On2 Technologies) và VP9, hỗ trợ tính năng Video jitter buffer để giúp ẩn đi những ảnh hưởng của jitter và việc mất gói trong chất lượng video tổng thể, hỗ trợ nâng cao chất lượng ảnh như khử nhiễu ảnh được chụp từ webcam.
Thành phần audio engine là framework xử lý chuỗi audio từ card âm thanh đến mạng Thành phần này sử dụng codec iSAC (internet Speech AudioCodec) /iLBC (Internet Low Bitrate Codec)/Opus [12] Nó sử dụng bộ đệm jitter động, thuật toán giấu lỗi để ẩn những ảnh hưởng của jitter mạng và mất gói tin, giúp giảm độ trễ tối đa mà vẫn giữ được chất lượng voice cao nhất.Trong framework sử dụng Acoustic Echo Canceler, phần mềm dựa trên thành phần xử lý tín hiệu giúp loại bỏ âm vọng trong thời gian thực và sử dụngNoise Reduction, phần mềm dựa trên thành phần xử lý tín hiệu giúp loại bỏ những tiếng ồn nền thường gắn với VoIP (hiss, fan noise).Trong kiến trúc này,thành phần vận chuyển/quản lý phiên rất quan trọng, cho phép thiết lập và quản lý kết nối P2P qua các loại mạng khác nhau.
Demo sản phẩm
Ở đề tài giao tiếp 1-1 bằng webRTC này, nhóm em sử dụng môi trường Nodejs, socket.io để kết nối giữa server và client.
Sau khi chạy bằng lệnh npm start, ứng dụng sẽ chạy trên localhost với port
3000, sau đó trình duyệt sẽ mở camera và micro của thiết bị lên, và khung video sẽ hiển thị ở bên trái.
Sau khi copy đường dẫn và mở ở một tab khác (đều là chrome vì khi sử dụng trình duyệt khác thì camera của thiết bị sẽ không cùng sử dụng cho cả 2 trình duyệt) thì 2 trình duyệt đã kết nối với nhau và khung hình thu được của trình duyệt kia sẽ được hiển thị bên phải.
Vì đề tài này là giao tiếp 1-1 nên khi có 1 trình duyệt khác sử dụng đường dẫn trên, sẽ nhận được thông báo là hết phiên và không kết nối được.
Có thể thay đổi bộ lọc ảnh của camera ( old school, B&W, Bracula,…), và có thể thay đổi sang chế độ nền tối.