WebRTC (Web Real-Time Communication) là một công nghệ mã nguồn mở được thiết kế để cho phép trình duyệt và các ứng dụng web thực hiện giao tiếp thời gian thực như truyền tải âm thanh, video và dữ liệu mà không cần sử dụng bất kỳ plugin hoặc phần mềm trung gian nào. Các ứng dụng phổ biến để đến là chia sẻ tệp tin, gọi video trực tuyến, chơi game trực tuyến, hỗ trợ từ xa. Bài viết này mô tả cơ bản cách thức chia sẻ tệp giữa hai người với nhau thông qua WebRTC.
Các khái niệm/thành phần cơ bản:
- SDP (Session Description Protocol): Tạm hiểu là phiên của mỗi kết nối, hai máy thông báo và nhận nhau qua SDP
- ICE (Interactive Connectivity Establishment): Thông tin đường truyền để hai máy gửi và nhận dữ liệu. ICE có thể sử dụng nhiều loại địa chỉ IP như địa chỉ nội bộ (LAN), địa chỉ công khai (WAN), và các giải pháp như STUN/TURN server (máy chủ trung gian phân phát dữ liệu)
- Offer/Answer: Đề nghị và phản hồi. Một bên gửi đề nghị chứa SDP và bên kia sẽ phản hồi lại cũng chứa SDP
- Data Channel: Kênh truyền dữ liệu trong WebRTC.
- Signaling Server: Máy chủ giúp hai máy (sau đây sẽ gọi là peer) gửi và nhận các thông tin cho nhau trước khi truyền dữ liệu. Sau khi nhận được thông tin và thiết lập xong kết nối dữ liệu truyền trực tiếp với nhau chứ không phải gửi lên đây.
Một số khái niệm khác nếu cần bạn có thể tìm hiểu thêm, trong phạm vi này chúng ta chưa cần hiểu: STUN Server, TURN Server, DTLS, SRTP.
Quy trình hoạt động cơ bản của WebRTC
Giả sử Peer A là bên gửi, Peer B là bên nhận thì quy trình cơ bản như sau:
- Peer A khởi tạo RTC Peer Connection, sau đó từ RTC Peer Connection vừa rồi tạo ra DataChannel để truyền dữ liệu
- Lắng nghe các sự kiện onicecandidate để lấy ICE Candidate gửi cho Peer B. Quá trình này độc lập và xảy ra sau khi Data Channel được tạo ở bước 1.
- Lắng nghe sự kiện onopen của data channel, khi sự kiện này xảy ra thì thực hiện gửi dữ liệu
- Peer A khởi tạo offer để lấy SDP, gắn SDP vào RTC Peer Connection ở bước 1 đồng thời gửi offer kèm theo SDP cho Peer B.
- Peer B khi nhận được offer sẽ mở kết nối RTC Peer Connection, gắn SDP của bên Peer A vào, tạo answer để lấy SDP của Peer B và gửi answer kèm SDP của peer B về cho A.
- Peer B sau khi mở RTC Peer Connection cũng tương tự ở bước 2 lắng nghe các sự kiện onicecandidate để lấy ICE Candidate gửi cho Peer A. Quá trình này cũng độc lập, nhìn chung bên A và bên B truyền nhận với nhau ICE Candidate này. Khi nhận được ICE Candidate thì add nó vào cái RTC Peer Connection đã mở.
- Peer B lắng nghe sự kiện onDataChannel > onopen để bắt đầu nhận dữ liệu.
- Peer A nhận được answer thì lấy SDP của B gắn vào RTC Peer Connection của mình. Trong thực tế đến đây thì ICE Candidate của 2 bên đã truyền và nhận cho nhau xong. Và đủ điều kiện SDP + ICE Candidate thì DataChannel của bên A bắt đầu mở, bên A sẽ xử lý tiếp tại bước 3 còn bên B xử lý tiếp ở bước 7.
Bạn có thể tưởng tượng qua sơ đồ này:
Trong quy trình bên trên có các hành động Peer A gửi cho Peer B và ngược lại. Trong thực tế nếu viết code test trên cùng 1 Tab web, mỗi RTC Peer Connection được gán vào 1 biến thì chỉ cần dùng tên biến đại diện để gửi và nhận (gán giá trị). Còn nếu 2 tab khác nhau, 2 trình duyệt khác nhau hoặc là 2 máy khác nhau thì các peer không thể gửi và nhận như vậy được mà phải gửi lên 1 server nào đó, sau đó server đó mới chuyển lại cho peer còn lại. Server này gọi là Signaling server.
Code và các vấn đề liên quan sẽ viết tiếp ở phần 2, nếu bạn quan tâm xin mời để lại bình luận
