Giới thiệu dự án

Thị trường phát sóng trực tuyến (Live Streaming) toàn cầu đã có bước tăng trưởng bùng nổ với tốc độ tăng trưởng kép hàng năm (CAGR) đạt xấp xỉ 21,5%, dự kiến vượt mốc 150 tỷ USD trong giai đoạn 2023–2028. Sự phát triển này thúc đẩy sự chuyển dịch mạnh mẽ từ các phương thức truyền thông thụ động sang tương tác thời gian thực hai chiều trong các lĩnh vực như giáo dục trực tuyến (E-learning), thương mại điện tử (Live Commerce) và giải trí đa phương tiện (Game Streaming).

Tuy nhiên, rào cản kỹ thuật lớn nhất của các nền tảng phát trực tuyến truyền thống nằm ở độ trễ truyền tải (End-to-End Latency). Các giải pháp dựa trên giao thức HTTP Streaming như HLS (HTTP Live Streaming) hay MPEG-DASH có độ trễ dao động từ 10 đến 30 giây, trong khi giao thức RTMP (Real-Time Messaging Protocol) thường có độ trễ từ 3 đến 5 giây và đòi hỏi phần mềm phát sóng chuyên biệt (như OBS Studio) hoặc plugin trình duyệt. Độ trễ cao làm triệt tiêu tính phản hồi tức thì giữa streamer và viewer trong các tình huống như đấu giá trực tiếp, hỏi đáp tương tác hay hội thảo kỹ thuật.

Đề tài "Xây dựng nền tảng streaming trực tuyến" (Building a live streaming platform) do sinh viên Nguyễn Tấn Ngà thực hiện dưới sự hướng dẫn của ThS. Mai Xuân Hùng tại Khoa Hệ thống Thông tin – Trường Đại học Công nghệ Thông tin, ĐHQG-HCM (UIT, 2023) giải quyết bài toán cốt lõi này bằng việc phát triển một hệ thống live streaming trên nền web với độ trễ siêu thấp (Ultra-Low Latency < 500ms) dựa trên công nghệ WebRTC kết hợp hệ sinh thái Spring Boot và ReactJS.

[Camera/Screen] ---> [Browser (WebRTC/SRTP)] ---> [Media/Signaling Server] ---> [Viewer (WebRTC Latency < 500ms)]
                                                         |
                                                [MySQL + Spring Boot API]

Mục tiêu của dự án:

  1. Nghiên cứu sâu cơ chế truyền dữ liệu thời gian thực của giao thức WebRTC (Web Real-Time Communication) và các chuẩn mã hóa đa phương tiện.
  2. Thiết kế và triển khai kiến trúc máy chủ điều phối tín hiệu (Signaling Server) sử dụng Spring Boot và WebSocket hai chiều.
  3. Xây dựng ứng dụng web trực tiếp trên trình duyệt, hỗ trợ streamer phát video từ Webcam hoặc chia sẻ màn hình (Screen Sharing) mà không cần cài đặt bất kỳ plugin hay phần mềm bên thứ ba nào.
  4. Tối ưu hóa hạ tầng định tuyến đa luồng dựa trên mô hình SFU (Selective Forwarding Unit), giảm độ trễ luồng phát xuống dưới 500ms và đảm bảo tính bảo mật với SRTP/DTLS.

Phạm vi và giới hạn:

  • Phạm vi: Hệ thống phục vụ tương tác toàn cầu thông qua trình duyệt web hiện đại (Google Chrome, Mozilla Firefox, Safari, Microsoft Edge), cung cấp đầy đủ chu trình: Đăng ký/Đăng nhập, Khởi tạo phòng phát sóng, Chia sẻ màn hình, Trò chuyện thời gian thực, Theo dõi (Follow), Lưu trữ và xem lại video (VOD), Thống kê số liệu tương tác.
  • Giới hạn: Tập trung vào mô hình định tuyến định hướng mở rộng (SFU/Routing topology); chưa tích hợp tính năng chuyển mã động phân giải cao (Transcoding/ABR - Adaptive Bitrate) ở phía máy chủ đa tầng trên diện rộng.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Khảo sát các nền tảng phổ biến hiện nay như Facebook Live và YouTube Live cho thấy các ưu và nhược điểm rõ rệt về mặt công nghệ:

Tiêu chí Facebook Live / YouTube Live Hệ thống WebRTC đề xuất
Giao thức truyền phát chính RTMPS (Ingest), HLS / DASH (Playback) WebRTC (Ingest & Playback)
Độ trễ trung bình (End-to-End) 3 – 15 giây 300 – 500 ms (Sub-second)
Yêu cầu ứng dụng Streamer Yêu cầu OBS / App chuyên dụng 100% Native Web Browser (HTML5/WebRTC)
Giao thức tương tác (Chat) WebSocket / Long-polling WebSocket (RFC 6455) Full-duplex
Mức độ tiêu thụ tài nguyên máy chủ Rất cao (yêu cầu Transcoding/Segmenting) Tối ưu với cơ chế Selective Forwarding (SFU)
Bảo mật luồng truyền RTMPS (TLS/SSL) SRTP mã hóa phần cứng + DTLS

Ma trận ưu tiên yêu cầu người dùng (MoSCoW):

  • Must Have (Bắt buộc): Truyền phát video/audio trực tiếp từ webcam/màn hình qua trình duyệt; Kênh chat thời gian thực; Xác thực người dùng (JWT/Session); Quản lý phiên live (tạo, cập nhật, đóng phòng).
  • Should Have (Nên có): Ghi lại video phiên phát (VOD); Theo dõi (Follow) streamer; Dashboard phân tích thống kê lượt xem, thời lượng live theo tháng; Xuất dữ liệu ra Excel.
  • Could Have (Có thể có): Chế độ giao diện tối (Dark Mode); Phân loại stream theo danh mục (Category).
  • Won't Have (Chưa thực hiện ở giai đoạn này): Tính năng donate tiền tệ trực tiếp; Hệ thống kiểm duyệt nội dung tự động bằng AI.

Thiết kế hệ thống

1. Kiến trúc tổng thể và cơ chế Topology đa bên

Hệ thống lựa chọn cấu trúc liên kết định tuyến Routing Topology (SFU - Selective Forwarding Unit) thay vì Mesh Topology hay Mixing Topology (MCU):

  • Mesh Topology (Lưới P2P thuần túy): Yêu cầu $N-1$ uplink và $N-1$ downlink cho mỗi client (với $N$ người tham gia). Băng thông phía client tăng theo hàm bậc hai $O(N^2)$, chỉ phù hợp với nhóm 4–6 người.
  • Mixing Topology (MCU): Máy chủ giải mã tất cả các luồng, trộn thành một luồng video duy nhất rồi mã hóa lại. Cách tiếp cận này tiêu tốn CPU máy chủ cực lớn, độ trễ tăng cao và không mở rộng được cho live streaming quy mô lớn.
  • Routing Topology (SFU): Streamer chỉ gửi duy nhất 1 uplink lên máy chủ. Máy chủ SFU đóng vai trò định tuyến các gói tin RTP/SRTP đến các viewers (mỗi viewer 1 downlink) mà không thực hiện giải mã hay trộn khung hình. Giúp tối ưu hóa tài nguyên tính toán của máy chủ, giảm tải CPU đến 70% so với MCU và duy trì độ trễ < 500ms.
                  +-----------------------------------+
                  |        WebRTC SFU Server          |
                  |  - ICE/STUN/TURN Handling         |
                  |  - SRTP/RTP Packet Forwarding     |
                  +-----------------------------------+
                       ^                         |
        Uplink (1 Stream)                  Downlink (N Streams)
                       |                         |
               +---------------+         +---------------+---------------+
               | Streamer      |         | Viewer 1      | Viewer N      |
               | (Chrome/Edge) |         | (Browser)     | (Browser)     |
               +---------------+         +---------------+---------------+

2. Technology Stack chi tiết

+-----------------------------------------------------------------------+
|                            TECHNOLOGY STACK                           |
+-----------------------------------------------------------------------+
|  Frontend Layer  | ReactJS 18.x, WebRTC APIs, Axios, TailwindCSS      |
|  Signaling Layer | Spring WebSocket, STOMP Protocol, SockJS           |
|  Backend Layer   | Java 17, Spring Boot 3.x, Spring Data JPA, Security|
|  Media/Network   | WebRTC 1.0, ICE (RFC 5245), STUN/TURN (Coturn)     |
|  Database Layer  | MySQL 8.0 Community Server                         |
+-----------------------------------------------------------------------+

3. Thiết kế cơ sở dữ liệu quan hệ (Database Schema)

Hệ thống sử dụng cơ sở dữ liệu MySQL chuẩn hóa bậc 3 (3NF) gồm 6 bảng dữ liệu cốt lõi:

-- Schema cấu trúc dữ liệu cốt lõi cho nền tảng Live Streaming
CREATE TABLE Users (
    user_id INT AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(255) NOT NULL UNIQUE,
    email VARCHAR(255) NOT NULL UNIQUE,
    avatar_url VARCHAR(255),
    password VARCHAR(255) NOT NULL,
    isLive BIT NOT NULL DEFAULT 0,
    role VARCHAR(20) NOT NULL DEFAULT 'ROLE_USER'
);

CREATE TABLE Stream (
    stream_id INT AUTO_INCREMENT PRIMARY KEY,
    stream_name VARCHAR(255) NOT NULL,
    description VARCHAR(255),
    status VARCHAR(50) NOT NULL, -- 'LIVE', 'ENDED'
    start_time VARCHAR(255) NOT NULL,
    end_time VARCHAR(255),
    user_id INT NOT NULL,
    CONSTRAINT fk_stream_user FOREIGN KEY (user_id) REFERENCES Users(user_id) ON DELETE CASCADE
);

CREATE TABLE Category (
    category_id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
    description VARCHAR(255)
);

CREATE TABLE Category_Stream (
    stream_id INT NOT NULL,
    category_id INT NOT NULL,
    PRIMARY KEY (stream_id, category_id),
    CONSTRAINT fk_cs_stream FOREIGN KEY (stream_id) REFERENCES Stream(stream_id),
    CONSTRAINT fk_cs_category FOREIGN KEY (category_id) REFERENCES Category(category_id)
);

CREATE TABLE Follow (
    follow_id INT AUTO_INCREMENT PRIMARY KEY,
    follower_id INT NOT NULL,
    following_id INT NOT NULL,
    CONSTRAINT fk_follow_follower FOREIGN KEY (follower_id) REFERENCES Users(user_id),
    CONSTRAINT fk_follow_following FOREIGN KEY (following_id) REFERENCES Users(user_id)
);

CREATE TABLE Record_Video (
    record_id INT AUTO_INCREMENT PRIMARY KEY,
    record_name VARCHAR(255) NOT NULL,
    record_url VARCHAR(255) NOT NULL,
    start_time VARCHAR(255) NOT NULL,
    end_time VARCHAR(255) NOT NULL,
    stream_id INT NOT NULL,
    CONSTRAINT fk_record_stream FOREIGN KEY (stream_id) REFERENCES Stream(stream_id)
);

4. Giao thức Signaling và API Design

WebRTC không quy định giao thức báo hiệu (Signaling). Hệ thống sử dụng WebSocket (RFC 6455) kết hợp Spring STOMP để trao đổi các thông điệp SDP (Session Description Protocol) và ICE Candidates:

  • WS /ws-signaling: Điểm cuối WebSocket phục vụ bắt tay báo hiệu.
  • Topic /topic/stream/{streamId}: Kênh broadcast thông tin SDP Offer/Answer giữa Streamer và Viewers.
  • REST Endpoint POST /api/v1/streams/create: Khởi tạo phiên live và lấy stream identifier.
  • REST Endpoint GET /api/v1/analytics/streamer/{id}: Trả về thống kê tổng hợp (tổng thời lượng, tổng lượt xem, người theo dõi).

Methodology

Dự án áp dụng mô hình phát triển phần mềm linh hoạt (Agile/Scrum) với chu kỳ Sprint 2 tuần/lần, kéo dài trong 16 tuần:

  • Milestone 1 (Tuần 1–4): Khảo sát yêu cầu, nghiên cứu WebRTC RFC và thiết kế kiến trúc hệ thống, xây dựng DB Schema.
  • Milestone 2 (Tuần 5–8): Hiện thực Backend Spring Boot, thiết lập WebSocket Signaling Server và tích hợp máy chủ STUN/TURN.
  • Milestone 3 (Tuần 9–12): Phát triển Frontend ReactJS, cài đặt các WebRTC APIs (getUserMedia, getDisplayMedia, RTCPeerConnection), xây dựng giao diện phòng phát sóng và phòng xem.
  • Milestone 4 (Tuần 13–16): Kiểm thử tích hợp (Integration Testing), đo lường độ trễ mạng, kiểm thử tải nhiều người dùng đồng thời, đóng gói và triển khai.

Implementation và kết quả

Quá trình phát triển và thuật toán cốt lõi

Quy trình thiết lập kết nối WebRTC P2P/SFU trên trình duyệt client được xây dựng theo chuẩn WebRTC 1.0:

1. Thu thập luồng MediaStream (Camera & Screen Share)

Streamer khởi tạo luồng dữ liệu thông qua API navigator.mediaDevices:

// Thu thập luồng âm thanh và hình ảnh từ thiết bị đầu vào của người phát
async function initializeMediaStream(enableScreenShare = false) {
    const constraints = {
        audio: { echoCancellation: true, noiseSuppression: true },
        video: { width: { ideal: 1280 }, height: { ideal: 720 }, frameRate: { ideal: 30 } }
    };
    try {
        let localStream;
        if (enableScreenShare) {
            localStream = await navigator.mediaDevices.getDisplayMedia({ video: true, audio: true });
        } else {
            localStream = await navigator.mediaDevices.getUserMedia(constraints);
        }
        const videoElement = document.querySelector("#localVideo");
        videoElement.srcObject = localStream;
        return localStream;
    } catch (error) {
        console.error("Lỗi khi truy cập thiết bị media:", error);
        throw error;
    }
}

2. Khởi tạo RTCPeerConnection và trao đổi báo hiệu (Signaling Flow)

Quá trình thương lượng phiên (Negotiation) thông qua Spring WebSocket Signaling:

// Thiết lập RTCPeerConnection và trao đổi SDP Offer/Answer
function createPeerConnection(stream, stompClient, streamId, isStreamer) {
    const configuration = {
        iceServers: [
            { urls: "stun:stun.l.google.com:19302" },
            {
                urls: "turn:turn.example.com:3478",
                username: "live_user",
                credential: "secure_password"
            }
        ]
    };
    const peerConnection = new RTCPeerConnection(configuration);

    // Thêm các media track vào kết nối
    if (stream) {
        stream.getTracks().forEach(track => peerConnection.addTrack(track, stream));
    }

    // Thu thập ICE Candidates và gửi qua Signaling Server
    peerConnection.onicecandidate = (event) => {
        if (event.candidate) {
            stompClient.send(`/app/stream/${streamId}/candidate`, {}, JSON.stringify({
                type: 'candidate',
                candidate: event.candidate
            }));
        }
    };

    // Xử lý khi nhận được luồng từ remote peer
    peerConnection.ontrack = (event) => {
        const remoteVideo = document.querySelector("#remoteVideo");
        if (remoteVideo && event.streams[0]) {
            remoteVideo.srcObject = event.streams[0];
        }
    };

    return peerConnection;
}

3. Báo hiệu phía Server với Spring Boot STOMP

// Controller điều phối báo hiệu WebRTC SDP và ICE Candidate
@Controller
public class SignalingController {

    @MessageMapping("/stream/{streamId}/offer")
    @SendTo("/topic/stream/{streamId}")
    public SignalingMessage processOffer(@DestinationVariable Long streamId, SignalingMessage message) {
        // Chuyển tiếp SDP Offer tới viewers trong phòng
        return message;
    }

    @MessageMapping("/stream/{streamId}/candidate")
    @SendTo("/topic/stream/{streamId}")
    public SignalingMessage processCandidate(@DestinationVariable Long streamId, SignalingMessage message) {
        // Chuyển tiếp ICE Candidate phục vụ xuyên NAT/Firewall
        return message;
    }
}

Kiểm thử và đánh giá hiệu năng

Hệ thống được kiểm thử thực tế trên mạng LAN và Internet qua nhiều điều kiện hạ tầng:

+--------------------------------------------------------------------+
|                LATENCY BENCHMARK COMPARISON (ms)                   |
+--------------------------------------------------------------------+
| WebRTC (This Project) : [===] 380 ms                               |
| RTMP Streaming        : [==============================] 3,200 ms   |
| HLS Standard          : [====================================] 12s |
+--------------------------------------------------------------------+
Chỉ số đánh giá Giao thức HLS Giao thức RTMP Hệ thống WebRTC (Đề tài) Mức độ cải thiện
Độ trễ truyền tải (Latency) 10.000 – 15.000 ms 3.000 – 5.000 ms 350 – 480 ms Giảm ~88% so với RTMP, ~96% so với HLS
Độ trễ tin nhắn Chat 1.000 – 2.000 ms 500 – 1.000 ms 45 – 80 ms Tức thì (Real-time Full Duplex)
Tỷ lệ khung hình (FPS) 24 – 30 fps 30 fps 30 – 60 fps (Adaptive) Ổn định, mượt mà
Khả năng vượt NAT/Firewall 100% (HTTP Port 80/443) 85% (RTMP Port 1935) 98.5% (STUN + TURN Relay) Hoạt động tốt sau NAT đối xứng
Tài nguyên Client CPU Thấp (chỉ giải mã) Trung bình (Yêu cầu OBS) Thấp – Trung bình Không cần phần mềm bổ trợ

Đổi mới và đóng góp

  1. Phát trực tiếp không cần plugin (Zero-Plugin Architecture): Loại bỏ hoàn toàn sự phụ thuộc vào các công cụ mã hóa ngoài như OBS Studio hay plugin Flash lỗi thời. Streamer chỉ cần mở trình duyệt, cấp quyền micro/camera hoặc màn hình là có thể phát trực tiếp với độ phân giải HD 720p/1080p.
  2. Tối ưu hóa độ trễ tương tác xuống Sub-second: Nhờ sử dụng giao thức truyền tải UDP/SRTP thay vì TCP/HTTP chunking, độ trễ truyền phát được nén xuống dưới 0.5 giây. Người xem phản hồi trong khung chat có thể nhận câu trả lời ngay lập tức từ streamer, không còn hiện tượng "lệch nhịp" thời gian.
  3. Mô hình định tuyến SFU tiết kiệm tài nguyên: Khác biệt so với mô hình P2P Mesh truyền thống vốn nhanh chóng cạn kiệt băng thông của streamer khi có trên 5 người xem, kiến trúc đề xuất áp dụng giải pháp định tuyến gói tin có khả năng mở rộng phục vụ nhiều người xem cùng lúc mà vẫn đảm bảo streamer chỉ chịu tải 1 luồng upload duy nhất.

Ứng dụng thực tế và triển khai

Tình huống ứng dụng thực tế

  • Đào tạo và thuyết trình từ xa: Giảng viên chia sẻ màn hình slide kết hợp webcam góc màn hình; sinh viên phản hồi, đặt câu hỏi không có độ trễ qua kênh WebSocket.
  • Thương mại điện tử tương tác (Live Shopping): Người bán giới thiệu sản phẩm và tiếp nhận các phiên chốt đơn theo mili-giây, đảm bảo tính công bằng và chính xác khi có nhiều người cùng đặt hàng.
  • Game Streaming & Tech Demo: Hỗ trợ tính năng chia sẻ toàn màn hình hoặc cửa sổ ứng dụng cụ thể với âm thanh hệ thống trực tiếp từ trình duyệt.
                   +--------------------------------------------+
                   |             Nginx Reverse Proxy            |
                   |       (SSL/TLS Termination - HTTPS/WSS)    |
                   +--------------------------------------------+
                                  |              |
                 +----------------+              +----------------+
                 |                                                |
                 v                                                v
    +--------------------------+                    +--------------------------+
    |   ReactJS Client (SPA)   |                    | Spring Boot App (Port:   |
    |   Static Assets Build    |                    | 8080 - REST & WebSocket) |
    +--------------------------+                    +--------------------------+
                                                                  |
                                                                  v
                                                    +--------------------------+
                                                    |  MySQL 8.0 Database      |
                                                    +--------------------------+

Yêu cầu cấu hình hệ thống triển khai:

  • Server: Ubuntu 22.04 LTS, 4 Cores CPU, 8GB RAM, Băng thông mạng tối thiểu 1Gbps.
  • Máy chủ STUN/TURN: Cài đặt Coturn Server mở cổng UDP 3478 và dải cổng Relay 49152–65535.
  • Client: Bất kỳ thiết bị nào cài đặt trình duyệt Chrome 80+, Firefox 75+, Edge 80+ hoặc Safari 13+.

Hạn chế và hướng phát triển

Hạn chế còn tồn tại:

  • Băng thông phía máy chủ khi quy mô lớn: Khi số lượng viewers vượt quá ngưỡng 1.000 kết nối đồng thời trên một node SFU đơn lẻ, băng thông mạng đường truyền ra (outbound) của server có thể trở thành điểm nghẽn.
  • Chưa có Adaptive Bitrate (ABR) đa tầng: Video gửi từ streamer ở mức phân giải nào sẽ được chuyển tiếp trực tiếp ở mức đó; viewer có kết nối mạng yếu có thể bị giật lag nếu streamer phát ở độ phân giải quá cao.

Hướng phát triển tiếp theo:

  1. Tích hợp giải pháp Simulcast / SVC (Scalable Video Coding) ở WebRTC client để streamer gửi đồng thời nhiều tầng chất lượng (1080p, 720p, 360p).
  2. Xây dựng cụm máy chủ SFU dạng phân tán (Clustered SFU Cascading) sử dụng các nền tảng như MediaSoup hoặc Janus Media Server, cho phép mở rộng quy mô lên hàng chục nghìn người xem cùng lúc.
  3. Tích hợp pipeline chuyển đổi tự động luồng WebRTC sang HLS bằng FFmpeg để lưu trữ phục vụ phát lại (VOD) tối ưu hơn.

Đối tượng hưởng lợi

  • Sinh viên & Giảng viên Công nghệ Thông tin: Nguồn tài liệu tham khảo chi tiết, đầy đủ về kiến trúc WebRTC thực chiến, quy trình bắt tay SDP/ICE, và cách xây dựng WebSocket Signaling trên nền Java Spring Boot.
  • Lập trình viên Full-stack: Cung cấp mẫu thiết kế chuẩn (design pattern) cho ứng dụng Real-time Media, cách xử lý đồng thời giữa REST API, WebSocket STOMP và WebRTC Media Stream.
  • Doanh nghiệp vừa và nhỏ (SMEs): Giải pháp xây dựng nền tảng streaming riêng độc lập, bảo mật dữ liệu nội bộ với chi phí hạ tầng thấp, không phải trả phí bản quyền cho các nền tảng thứ ba.

Câu hỏi thường gặp

1. Yêu cầu kỹ thuật tối thiểu để triển khai nền tảng là gì?

Để triển khai đầy đủ, hệ thống cần một máy chủ Linux (Ubuntu/Debian) đã cấu hình Docker, JDK 17, Node.js 18.x, MySQL 8.0 và chứng chỉ SSL/TLS (bắt buộc vì WebRTC getUserMedia chỉ hoạt động trên giao thức HTTPS và localhost). Cần cài đặt thêm Coturn Server để giải quyết bài toán NAT traversal.

2. Làm thế nào để hệ thống vượt qua tường lửa và NAT đối xứng (Symmetric NAT)?

Hệ thống sử dụng cơ chế ICE (Interactive Connectivity Establishment) kết hợp máy chủ STUN để tìm kiếm địa chỉ IP Public. Trong trường hợp client nằm sau mạng NAT đối xứng hoặc tường lửa doanh nghiệp chặn gói tin P2P trực tiếp, máy chủ TURN (Traversal Using Relays around NAT) sẽ đóng vai trò chuyển tiếp toàn bộ luồng dữ liệu media mã hóa qua cổng 3478/443.

3. Tại sao không dùng WebSocket để truyền trực tiếp video thay vì WebRTC?

WebSocket chạy trên nền giao thức TCP, yêu cầu cơ chế kiểm tra lỗi và gửi lại gói tin khi bị mất (retransmission). Khi mạng chập chờn, TCP Head-of-Line Blocking sẽ khiến video bị đóng băng và độ trễ tăng dần liên tục. Ngược lại, WebRTC sử dụng UDP/SRTP, ưu tiên tốc độ thời gian thực, có khả năng bỏ qua các gói tin hỏng để duy trì độ trễ < 500ms.

4. Chi phí vận hành hạ tầng WebRTC so với HLS truyền thống như thế nào?

Chi phí máy chủ tính toán (CPU) của WebRTC SFU thấp hơn đáng kể so với việc phải giải mã/chuyển mã (Transcoding) liên tục cho HLS/DASH. Tuy nhiên, lưu lượng băng thông (Outbound Bandwidth) của SFU tăng tuyến tính theo số lượng người xem. Đối với hệ thống có dưới 1.000 người xem đồng thời cho mỗi phiên, mô hình WebRTC SFU giúp tiết kiệm khoảng 40–50% tổng chi phí vận hành (TCO).

5. Dữ liệu video và chat có được đảm bảo an toàn bảo mật không?

Có. Tất cả luồng media WebRTC đều bắt buộc mã hóa mặc định ở tầng giao vận bằng giao thức SRTP thông qua cơ chế trao đổi khóa DTLS (Datagram Transport Layer Security). Kênh điều khiển WebSocket và API sử dụng mã hóa WSS/HTTPS với chứng chỉ TLS 1.3 và xác thực người dùng bằng thuật toán mã hóa mật khẩu BCrypt.

Kết luận

Đồ án tốt nghiệp "Xây dựng nền tảng streaming trực tuyến" của tác giả Nguyễn Tấn Ngà đã giải quyết bài toán cốt lõi về độ trễ trong truyền thông đa phương tiện trực tuyến. Bằng cách kết hợp sức mạnh của công nghệ WebRTC, máy chủ tín hiệu Spring Boot và giao diện tương tác ReactJS, dự án đã hiện thực hóa thành công một hệ thống live streaming hoàn chỉnh chạy trực tiếp trên nền web với độ trễ tối ưu dưới 500ms.

Nghiên cứu không chỉ hoàn thành toàn diện các yêu cầu kỹ thuật từ kiến trúc cơ sở dữ liệu, quản lý luồng dữ liệu, tính năng chia sẻ màn hình đa chế độ đến thống kê báo cáo chi tiết, mà còn cung cấp cơ sở lý thuyết và thực nghiệm vững chắc cho việc phát triển các giải pháp Real-Time Communications mở rộng trong tương lai. Nền tảng mở ra tiềm năng ứng dụng to lớn trong giáo dục số, hội thảo trực tuyến và thương mại điện tử tương tác cao.