Giới thiệu dự án

Trong kỷ nguyên chuyển đổi số và xu hướng làm việc từ xa (remote/hybrid work) bùng nổ, nhu cầu kết nối liên tục, bảo mật và tức thời trong các tổ chức trở thành yếu tố sống còn. Theo các khảo sát công nghệ doanh nghiệp gần đây, hơn 78% các tổ chức vừa và nhỏ (SMEs) gặp rào cản về chi phí bản quyền và lo ngại rò rỉ dữ liệu khi sử dụng các nền tảng giao tiếp đám mây công cộng bên thứ ba.

Nhiều tổ chức quy mô nhỏ phải đối mặt với các vấn đề cụ thể (pain points):

  • Phụ thuộc vào các ứng dụng nhắn tin thương mại (như Zalo, Telegram, Slack) dẫn đến việc dữ liệu nhạy cảm của doanh nghiệp bị phân tán và khó kiểm soát quyền riêng tư.
  • Chi phí duy trì bản quyền cho các giải pháp họp trực tuyến chuyên dụng (như Zoom Enterprise, Microsoft Teams) quá cao so với ngân sách vận hành của tổ chức nhỏ.
  • Giao diện phức tạp, tích hợp quá nhiều tính năng mạng xã hội gây phân tâm và giảm năng suất làm việc.

Đồ án khóa luận tốt nghiệp "Phần mềm nhắn tin tức thời cho các tổ chức nhỏ" (Instant Messenger for Small Organization) do sinh viên Lâm Phú Sỹ thực hiện dưới sự hướng dẫn của TS. Đỗ Thị Thanh Tuyền tại Trường Đại học Công nghệ Thông tin - ĐHQG-HCM, tập trung giải quyết bài toán giao tiếp nội bộ toàn diện thông qua nền tảng web hiện đại.

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

  1. Xây dựng hệ thống giao tiếp thời gian thực hỗ trợ nhắn tin văn bản, truyền file và quản lý danh bạ nội bộ.
  2. Tích hợp giải pháp gọi thoại (Audio Call), gọi video (Video Call) và chia sẻ màn hình (Screen Sharing) chất lượng cao dựa trên kiến trúc WebRTC Peer-to-Peer (P2P).
  3. Đảm bảo tính bảo mật, toàn vẹn dữ liệu và tối ưu hóa hạ tầng máy chủ với chi phí vận hành tiệm cận mức tối thiểu.

Giải pháp lựa chọn là kiến trúc phân tán kết hợp giữa WebRTC cho truyền tải media thời gian thực độ trễ thấp và RESTful API/WebSocket cho quản lý trạng thái, dữ liệu người dùng. Kết quả kỳ vọng đạt được là một hệ thống web hoạt động ổn định với độ trễ truyền dữ liệu dưới 150ms, hỗ trợ cuộc gọi P2P đạt chuẩn HD và khả năng mở rộng linh hoạt trên nền tảng đám mây Azure. Phạm vi nghiên cứu tập trung vào môi trường trình duyệt web hiện đại, phục vụ các tổ chức có quy mô từ 10 đến 100 nhân sự.

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 giải pháp giao tiếp phổ biến hiện nay cho thấy sự phân hóa rõ rệt giữa ứng dụng đại chúng và ứng dụng doanh nghiệp:

Tiêu chí Telegram Zalo Instant Messenger (Đồ án)
Mô hình triển khai Cloud Server tập trung Cloud Server tập trung On-premise / Private Cloud (Azure)
Kiến trúc cuộc gọi Server Relay / P2P hạn chế Server Relay WebRTC P2P Direct Stream
Kiểm soát dữ liệu Máy chủ Telegram quản lý Máy chủ VNG quản lý Tổ chức toàn quyền làm chủ database
Chia sẻ màn hình Web Yêu cầu app chuyên dụng Hạn chế trên web Tích hợp trực tiếp qua Web API
Chi phí bản quyền Miễn phí/Thu phí Premium Miễn phí/Thu phí OA Tối ưu mã nguồn mở, không phí định kỳ

Áp dụng phương pháp MoSCoW để xác định yêu cầu hệ thống:

  • Must Have (Bắt buộc): Đăng ký/đăng nhập xác thực, nhắn tin 1-1, nhắn tin nhóm, gửi/tải file đính kèm, gọi Audio/Video P2P, chia sẻ màn hình.
  • Should Have (Nên có): Quản lý trạng thái online/offline, cập nhật thông tin cá nhân, danh sách lịch sử cuộc gọi.
  • Could Have (Có thể có): Tìm kiếm tin nhắn nâng cao, bộ lọc âm thanh khi gọi.
  • Won't Have (Chưa thực hiện): Tích hợp ví điện tử, chatbot tự động, mã hóa end-to-end cho lưu trữ tĩnh.

Thách thức kỹ thuật lớn nhất nằm ở kỹ thuật vượt tường lửa (NAT Traversal) khi thiết lập kết nối WebRTC giữa các máy trạm nằm sau các mạng nội bộ (NAT/Firewall) khác nhau.

+-----------------------------------------------------------------------+
|                         SƠ ĐỒ KIẾN TRÚC HỆ THỐNG                     |
+-----------------------------------------------------------------------+
|                                                                       |
|   +-----------------------+              +-----------------------+    |
|   |   Client A (Angular)  |              |   Client B (Angular)  |    |
|   +-----------+-----------+              +-----------+-----------+    |
|               |                                      |                |
|       HTTP /  |  Signaling (Socket.IO/WebSocket)     | HTTP /         |
|       REST    |                                      | REST           |
|               v                                      v                |
|   +------------------------------------------------------+            |
|   |         Signaling Server & Backend Web API           |            |
|   |       (Node.js / ASP.NET Core 8.0 + C# 12)           |            |
|   +--------------------------+---------------------------+            |
|                              |                                        |
|                              v                                        |
|                   +----------------------+                            |
|                   | MS SQL Server 2022   |                            |
|                   +----------------------+                            |
|                                                                       |
|   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -   |
|   Kênh truyền Media trực tiếp (WebRTC Peer-to-Peer Data & Media):     |
|                                                                       |
|   +-----------------------+                      +----------------+   |
|   |   Client A (Peer A)   |<====================>| Client B       |   |
|   +-----------+-----------+   SRTP / VP8 / Opus  +--------+-------+   |
|               ^                                           ^           |
|               |       STUN/TURN Server (NAT Traversal)    |           |
|               +-------------------+-----------------------+           |
|                                   |                                   |
|                                   v                                   |
|                       +----------------------+                        |
|                       | STUN / TURN (Coturn) |                        |
|                       +----------------------+                        |
+-----------------------------------------------------------------------+

Thiết kế hệ thống

Hệ thống được thiết kế theo mô hình phân lớp hiện đại với các thành phần công nghệ xác định:

  • Frontend Client: Angular 17+ (TypeScript), HTML5 Media Capture API, SCSS, RxJS.
  • Signaling Layer: Node.js v20.x kết hợp Socket.IO v4.x quản lý phiên kết nối socket và luân chuyển gói tin SDP/ICE Candidates.
  • Core Backend API: ASP.NET Core 8.0 Web API viết bằng C# xử lý logic nghiệp vụ, quản lý tài khoản và lưu trữ tin nhắn.
  • Database: Microsoft SQL Server 2022 đảm bảo tính nhất quán (ACID) cho dữ liệu quan hệ.
  • Hạ tầng mạng: STUN (Session Traversal Utilities for NAT) và TURN (Traversal Using Relays around NAT) phục vụ kỹ thuật ICE.

Thiết kế cơ sở dữ liệu quan hệ gồm 7 bảng cốt lõi:

  • User (UserID [PK], Username, PasswordHash, FullName, AvatarUrl, CreatedAt)
  • Contact (ContactID [PK], UserID [FK], ContactUserID [FK], Status)
  • Group (GroupID [PK], GroupName, CreatedBy [FK], CreatedAt)
  • GroupUser (GroupUserID [PK], GroupID [FK], UserID [FK], Role)
  • Message (MessageID [PK], SenderID [FK], ReceiverID [FK, nullable], GroupID [FK, nullable], Content, FileType, FileUrl, Timestamp)
  • Call (CallID [PK], CallerID [FK], ReceiverID [FK], StartTime, EndTime, CallType, Status)
  • GroupCall (GroupCallID [PK], GroupID [FK], HostID [FK], StartTime, EndTime, Status)
-- Cấu trúc bảng Message cốt lõi quản lý tin nhắn và file
CREATE TABLE [dbo].[Message] (
    [MessageID] INT IDENTITY(1,1) PRIMARY KEY,
    [SenderID] INT NOT NULL FOREIGN KEY REFERENCES [User]([UserID]),
    [ReceiverID] INT NULL FOREIGN KEY REFERENCES [User]([UserID]),
    [GroupID] INT NULL FOREIGN KEY REFERENCES [Group]([GroupID]),
    [Content] NVARCHAR(MAX) NULL,
    [FileType] VARCHAR(50) NULL,
    [FileUrl] NVARCHAR(500) NULL,
    [Timestamp] DATETIME2 DEFAULT SYSUTCDATETIME()
);

Methodology

Dự án áp dụng mô hình Thác nước cải tiến (Modified Waterfall Model) trong khung thời gian 16 tuần. Mô hình này duy trì tính kỷ luật cao trong việc phân tích yêu cầu nhưng cho phép quay vòng lặp ngắn giữa hai pha Thiết kế - Hiện thực hóa để điều chỉnh các tham số WebRTC theo môi trường mạng thực tế:

  • Tuần 1 - 3: Khảo sát yêu cầu, nghiên cứu lý thuyết WebRTC, WebSocket, lập đặc tả Use Case.
  • Tuần 4 - 6: Thiết kế kiến trúc tổng thể, mô hình thực thể ERD, thiết kế giao diện trên Figma.
  • Tuần 7 - 12: Hiện thực hóa song song Frontend (Angular), Signaling (Node.js/Socket.IO) và Backend API (ASP.NET Core).
  • Tuần 13 - 14: Tích hợp hệ thống, kiểm thử đơn vị (Unit Test) và kiểm thử vượt NAT Traversal.
  • Tuần 15 - 16: Đóng gói, triển khai lên máy chủ Azure và hoàn thiện báo cáo khóa luận.

Implementation và kết quả

Development process

Quá trình phát triển tập trung vào 3 khối kỹ thuật chính: Xử lý Media Streams, Cơ chế Signaling thiết lập cuộc gọi và Đồng bộ tin nhắn tức thời.

// Khởi tạo MediaStream cho Audio/Video và Chia sẻ màn hình
@Injectable({ providedIn: 'root' })
export class MediaService {
  private localStream!: MediaStream;

  async getMediaStream(hasVideo: boolean = true): Promise<MediaStream> {
    const constraints: MediaStreamConstraints = {
      audio: { echoCancellation: true, noiseSuppression: true },
      video: hasVideo ? { width: { ideal: 1280 }, height: { ideal: 720 }, frameRate: { max: 30 } } : false
    };
    this.localStream = await navigator.mediaDevices.getUserMedia(constraints);
    return this.localStream;
  }

  async getScreenStream(): Promise<MediaStream> {
    return await navigator.mediaDevices.getDisplayMedia({
      video: { cursor: 'always' } as MediaTrackConstraints,
      audio: false
    });
  }
}

Trong quá trình thiết lập cuộc gọi P2P, Signaling Server đóng vai trò trung gian chuyển tiếp mô tả phiên truyền thông (Session Description Protocol - SDP) và các ứng viên mạng (ICE Candidates):

// Quá trình thương lượng SDP và thiết lập RTCPeerConnection
async function initiatePeerConnection(peerId: string, isCaller: boolean) {
  const peerConnection = new RTCPeerConnection({
    iceServers: [
      { urls: 'stun:stun.l.google.com:19302' },
      { urls: 'turn:turn.domain.com:3478', username: 'user', credential: 'password' }
    ]
  });

  localStream.getTracks().forEach(track => peerConnection.addTrack(track, localStream));

  peerConnection.onicecandidate = (event) => {
    if (event.candidate) {
      socket.emit('ice-candidate', { target: peerId, candidate: event.candidate });
    }
  };

  peerConnection.ontrack = (event) => {
    remoteVideoElement.srcObject = event.streams[0];
  };

  if (isCaller) {
    const offer = await peerConnection.createOffer();
    await peerConnection.setLocalDescription(offer);
    socket.emit('offer-sdp', { target: peerId, sdp: offer });
  }
}

// ASP.NET Core Controller xử lý truyền nhận file tin nhắn
[ApiController]
[Route("api/[controller]")]
public class MessageController : ControllerBase
{
    private readonly IMessageRepository _repo;
    public MessageController(IMessageRepository repo) => _repo = repo;

    [HttpPost("send-file")]
    [Authorize]
    public async Task<IActionResult> SendFile([FromForm] FileUploadDto dto)
    {
        if (dto.File == null || dto.File.Length == 0)
            return BadRequest("File không hợp lệ.");

        var savedPath = await _repo.SaveFileAsync(dto.File);
        var message = new Message {
            SenderID = dto.SenderId,
            ReceiverID = dto.ReceiverId,
            GroupID = dto.GroupId,
            FileType = Path.GetExtension(dto.File.FileName),
            FileUrl = savedPath,
            Timestamp = DateTime.UtcNow
        };
        await _repo.InsertMessageAsync(message);
        return Ok(message);
    }
}

Testing và validation

Quá trình kiểm thử được tiến hành nghiêm ngặt qua 13 Use Case chức năng chính trên 4 môi trường mạng khác nhau (LAN, Full Cone NAT, Restricted Cone NAT, Symmetric NAT):

Kịch bản kiểm thử Mô tả chi tiết Tỷ lệ thành công Thời gian phản hồi / Độ trễ
Xác thực & Kết nối Đăng ký, Đăng nhập, Duy trì Socket Handshake 100% (50/50 testcases) < 85ms
Nhắn tin & Gửi File Tin nhắn 1-1, Tin nhắn nhóm, tải file < 25MB 100% (100/100 testcases) < 120ms
P2P Audio/Video Call Thiết lập SDP Offer/Answer, trao đổi Media 98% (49/50 cuộc gọi) 65ms - 130ms (P2P)
Screen Sharing Đổi luồng MediaStream sang DisplayMedia 100% (30/30 lần thử) Độ trễ khung hình < 150ms
NAT Traversal (STUN) Kết nối giữa 2 mạng khác dải IP (Full/Restricted) 96% Khởi tạo kết nối < 1.8s
Relay Fallback (TURN) Kết nối qua Symmetric NAT 100% Khởi tạo kết nối < 2.5s

Kết quả đạt được

Hệ thống đã hoàn thành 100% các tính năng đề ra ban đầu:

  • Giao diện người dùng trên Angular trực quan, thời gian tải trang đầu (First Contentful Paint) đạt 1.1s.
  • Hỗ trợ cuộc gọi video P2P chuẩn 720p 30fps với mức tiêu thụ CPU phía máy trạm duy trì dưới 18% trên vi xử lý Intel Core i5 thế hệ 11.
  • Khả năng truyền file ổn định với dung lượng hỗ trợ tối đa 50MB/file.
  • Đánh giá từ 20 người dùng thử nghiệm nội bộ cho kết quả độ hài lòng (CSAT) đạt 4.7/5.0.

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

  1. Tối ưu hóa kiến trúc truyền tải dữ liệu đa phương tiện: Thay vì đẩy toàn bộ băng thông video/audio qua server trung tâm như các hệ thống họp trực tuyến truyền thống (tốn kém tài nguyên máy chủ theo cấp số nhân $\mathcal{O}(N)$), đồ án ứng dụng giải pháp WebRTC P2P giúp dữ liệu truyền trực tiếp giữa các trình duyệt. Điều này giúp giảm tải băng thông máy chủ tới hơn 75%.
  2. Cơ chế Hybrid Signaling tinh gọn: Kết hợp sức mạnh điều phối sự kiện theo thời gian thực của Node.js (Socket.IO) với hệ thống lưu trữ nghiệp vụ bền vững trên ASP.NET Core 8.0, mang lại hiệu năng cao và dễ bảo trì.
  3. Thuật toán xử lý NAT linh hoạt: Triển khai cơ chế phân giải kết nối tương tác (Interactive Connectivity Establishment - ICE) tự động dò tìm cấu hình tối ưu (ưu tiên STUN cho kết nối trực tiếp, tự động fallback sang TURN khi gặp Symmetric NAT) giúp tỷ lệ kết nối cuộc gọi thành công đạt 98%.
  4. Đóng góp học thuật và ứng dụng: Đồ án cung cấp một tài liệu kỹ thuật chi tiết về cách thức triển khai WebRTC và ICE Framework trong hệ sinh thái .NET & Angular, làm nền tảng tham khảo giá trị cho sinh viên ngành Kỹ thuật Phần mềm.

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

Kịch bản ứng dụng thực tế

  • Doanh nghiệp vừa và nhỏ (SMEs): Thiết lập mạng lưới liên lạc nội bộ an toàn, chia sẻ tài liệu công việc và họp nhanh hàng ngày mà không phát sinh chi phí hàng tháng.
  • Trường học / Trung tâm đào tạo: Cung cấp kênh trao đổi học tập trực tiếp giữa giảng viên và sinh viên, hỗ trợ chia sẻ màn hình giảng dạy trực tuyến.
  • Các tổ chức có yêu cầu bảo mật cao: Dễ dàng đóng gói và triển khai hệ thống trong mạng nội bộ (On-premise Intranet) hoàn toàn cô lập với Internet công cộng.

Chiến lược triển khai và Phân tích chi phí (ROI)

Triển khai trên nền tảng đám mây Microsoft Azure:

  • App Service (B1 Basic Tier): Chạy Backend ASP.NET Core Web API & Node.js Signaling.
  • Azure SQL Database (Serverless General Purpose): Tối ưu chi phí theo lượng tài nguyên sử dụng thực tế.
  • Azure Blob Storage: Lưu trữ file đính kèm và hình ảnh đại diện.
+-------------------------------------------------------------------------+
|                  BẢNG SO SÁNH CHI PHÍ VẬN HÀNH (100 USER)               |
+------------------------------------+------------------------------------+
| Giải pháp thương mại (SaaS)        | Instant Messenger (Triển khai riêng)|
+------------------------------------+------------------------------------+
| - Slack/MS Teams: $6 - $12.5/user  | - Azure App Service + DB: ~$25/tháng|
| - Tổng: $600 - $1250 / tháng       | - STUN/TURN Data Bandwidth: ~$15   |
|                                    | - Tổng: ~$40 / tháng               |
+------------------------------------+------------------------------------+
| => TIẾT KIỆM HƠN 90% CHI PHÍ VẬN HÀNH HÀNG NĂM CHO DOANH NGHIỆP         |
+-------------------------------------------------------------------------+

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

Hạn chế kỹ thuật

  • Mesh Topology trong gọi nhóm: Kiến trúc WebRTC Full Mesh thuần túy tiêu tốn băng thông đường truyền tải lên (uplink) của máy trạm khi số lượng người tham gia gọi nhóm vượt quá 4-5 người.
  • Phụ thuộc vào trình duyệt: Yêu cầu trình duyệt của người dùng cuối phải hỗ trợ đầy đủ tiêu chuẩn WebRTC 1.0 và Web API MediaDevices (Chrome 23+, Firefox 22+, Edge 79+).
  • Chưa có bộ nhớ đệm Offline: Tin nhắn chưa được lưu tạm cục bộ qua IndexedDB khi máy trạm mất kết nối Internet đột ngột.

Hướng phát triển trong tương lai

  1. Nâng cấp kiến trúc SFU/MCU: Tích hợp Selective Forwarding Unit (như Mediasoup hoặc Janus WebRTC Gateway) để hỗ trợ cuộc gọi nhóm quy mô 30 - 50 người mà không làm nghẽn băng thông máy trạm.
  2. Mã hóa đầu cuối E2EE (End-to-End Encryption): Ứng dụng giao thức Signal Protocol hoặc Olm/Megolm để mã hóa tin nhắn văn bản trước khi lưu vào SQL Server.
  3. Phát triển ứng dụng di động đa nền tảng: Sử dụng Flutter hoặc React Native tái sử dụng tầng Core WebRTC API để phát hành trên iOS và Android.

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

  • Sinh viên & Học viên CNTT: Nguồn tài liệu thực tế toàn diện để học tập kiến trúc WebRTC, cơ chế hoạt động của NAT/STUN/TURN và cách thức lập trình ứng dụng Full-stack với .NET Core và Angular.
  • Lập trình viên (Developers): Nắm bắt các mẫu thiết kế (Design Patterns), cách viết Clean Code khi quản lý các luồng dữ liệu bất đồng bộ RxJS và kỹ thuật xử lý WebSocket trong môi trường phân tán.
  • Doanh nghiệp & Tổ chức nhỏ: Sở hữu giải pháp liên lạc độc lập, loại bỏ rủi ro rò rỉ dữ liệu, tiết kiệm hơn 90% chi phí phần mềm hàng tháng.
  • Nhà nghiên cứu (Researchers): Dữ liệu thực nghiệm về hiệu năng WebRTC P2P và các phân tích chuyên sâu về kỹ thuật Hole Punching qua các cấu hình NAT khác nhau.

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

1. Yêu cầu cấu hình phần cứng tối thiểu để triển khai hệ thống là gì?

Máy chủ triển khai chỉ cần cấu hình tối thiểu 1 vCPU, 2GB RAM (như gói Azure B1s hoặc máy chủ vật lý chạy Linux/Windows Server). Phía người dùng chỉ cần thiết bị có trình duyệt web hiện đại (Google Chrome, Microsoft Edge, Mozilla Firefox) và thiết bị thu âm thanh/hình ảnh cơ bản.

2. Khi gặp Symmetric NAT (NAT đối xứng), cuộc gọi WebRTC có bị gián đoạn không?

Không. Hệ thống đã tích hợp sẵn cơ chế ICE Candidate fallback sang máy chủ TURN (Traversal Using Relays around NAT). Khi hai máy trạm đều ở sau Symmetric NAT không thể thiết lập kết nối P2P trực tiếp, luồng media sẽ được mã hóa và chuyển tiếp an toàn qua TURN Server.

3. Hệ thống có thể tích hợp với cơ sở dữ liệu nhân sự có sẵn của doanh nghiệp không?

Hoàn toàn có thể. Tầng backend ASP.NET Core được thiết kế theo kiến trúc Repository Pattern và RESTful API chuẩn mực, cho phép dễ dàng cấu hình kết nối tới LDAP, Active Directory hoặc cơ sở dữ liệu nhân sự hiện có qua giao thức OAuth2 / Single Sign-On (SSO).

4. Chi phí bảo trì và vận hành hệ thống định kỳ bao gồm những gì?

Chi phí chính gồm tiền thuê hạ tầng đám mây (Cloud Hosting) hoặc tiền điện/mạng cho máy chủ On-premise, cùng với phí duy trì tên miền (Domain) và chứng chỉ bảo mật SSL/TLS (có thể sử dụng Let's Encrypt miễn phí).

5. Khả năng mở rộng (Scalability) của hệ thống khi số lượng nhân viên tăng lên?

Backend ASP.NET Core được thiết kế Stateless nên có thể scale-out đa phiên bản dễ dàng thông qua bộ cân bằng tải (Load Balancer). Tầng Signaling Socket.IO có thể scale ngang bằng cách sử dụng Redis Adapter để đồng bộ kết nối giữa nhiều máy chủ node.

Kết luận

Đồ án "Phần mềm nhắn tin tức thời cho các tổ chức nhỏ" của tác giả Lâm Phú Sỹ đã giải quyết thành công bài toán xây dựng một nền tảng giao tiếp thời gian thực độc lập, an toàn và tối ưu chi phí. Bằng việc kết hợp hài hòa giữa các công nghệ hàng đầu hiện nay gồm WebRTC, Angular, ASP.NET Core và MS SQL Server, hệ thống chứng minh được tính khả thi vượt trội và hiệu năng ổn định qua các bài kiểm thử thực tế.

Giải pháp không chỉ hoàn thiện về mặt học thuật trong khuôn khổ một khóa luận tốt nghiệp ngành Kỹ thuật Phần mềm mà còn mang lại giá trị ứng dụng thực tiễn cao cho cộng đồng doanh nghiệp nhỏ. Đây là tiền đề vững chắc để tiếp tục mở rộng thêm các tính năng nâng cao như kiến trúc SFU cho hội nghị truyền hình quy mô lớn và mã hóa đầu cuối trong tương lai gần.