# Chuyển file qua WebRTC hoạt động như thế nào

Source: https://help.strongfolder.com/vi/guides/how-webrtc-file-transfer-works/
Updated: 2026-11-05

> Chuyển file qua WebRTC diễn ra theo ba giai đoạn. Máy chủ signaling giới thiệu hai trình duyệt với nhau; STUN và ICE tìm đường mạng xuyên qua router gia đình (NAT), và chuyển sang máy chủ chuyển tiếp TURN nếu không có đường trực tiếp; sau đó các trình duyệt mở một kênh dữ liệu được mã hóa DTLS và truyền file theo từng mảnh, trực tiếp hoặc qua máy chủ chuyển tiếp, mà không lưu lại.

Chuyển file qua WebRTC cho phép hai trình duyệt gửi file cho nhau mà không cần tải lên
kho lưu trữ cloud. Nghe thì đơn giản, nhưng internet vốn không được xây dựng để hai máy tính gia đình
gọi trực tiếp cho nhau. Hướng dẫn này đi qua những gì thực sự diễn ra — signaling, NAT,
STUN, ICE, TURN, DTLS và kênh dữ liệu — bằng ngôn ngữ dễ hiểu, lấy StrongFolder làm
ví dụ.

**Key facts**

- **WebRTC** là chuẩn của trình duyệt cho kết nối trực tiếp, có mã hóa giữa hai thiết bị; các công cụ chuyển file dùng **kênh dữ liệu** của nó.
- **Signaling** giới thiệu các trình duyệt với nhau; **STUN** và **ICE** tìm đường xuyên qua router (**NAT**); **máy chủ chuyển tiếp TURN** chuyển lưu lượng khi không có đường trực tiếp.
- **Mã hóa:** mọi kênh dữ liệu đều dùng **DTLS** — WebRTC không có chế độ không mã hóa.
- StrongFolder dùng PeerJS trên nền WebRTC, một máy chủ signaling của StrongFolder, các máy chủ STUN công khai (kể cả của Google) và các máy chủ chuyển tiếp TURN riêng. File không bao giờ được tải lên hay lưu trên máy chủ của StrongFolder.
- File được truyền theo từng mảnh từ ổ đĩa người gửi sang ổ đĩa người nhận; người gửi phải luôn trực tuyến.

## WebRTC là gì?

[WebRTC](https://help.strongfolder.com/en/glossary/#webrtc) (Web Real-Time Communication) là bộ API của trình duyệt và
các giao thức mạng, được W3C và IETF chuẩn hóa, cho kết nối thời gian thực giữa các
trình duyệt. Chrome, Edge, Firefox, Safari và Opera đều hỗ trợ. Nó được làm cho cuộc gọi video và
thoại, nhưng cũng có **kênh dữ liệu** truyền mọi loại dữ liệu nhị phân — và file chính xác
là như vậy.

Đặc điểm then chốt: khi kết nối WebRTC đã được thiết lập, dữ liệu đi **giữa hai
đầu**, không vào kho lưu trữ của máy chủ. Đó là điều giúp
[chuyển file P2P trên trình duyệt](https://help.strongfolder.com/en/guides/p2p-file-transfer/) trở nên khả thi.

## Vì sao hai trình duyệt không thể kết nối thẳng với nhau?

Vì hầu như không thiết bị nào có địa chỉ công khai riêng. Laptop của bạn nằm sau router gia đình,
tường lửa văn phòng hoặc mạng của nhà mạng di động. Router thực hiện
[NAT](https://help.strongfolder.com/en/glossary/#nat) (Network Address Translation): nhiều thiết bị riêng chia sẻ một địa chỉ
IP công khai, và router chỉ cho vào lưu lượng trả lời cho thứ gì đó được gửi từ bên trong.

Vì thế, hai trình duyệt gặp ba vấn đề trước khi dữ liệu file có thể đi qua:

1. Chúng không biết **cách liên lạc với nhau** — không bên nào biết bên kia tồn tại.
2. Chúng không biết **địa chỉ công khai của chính mình** — chỉ biết địa chỉ riêng, như 192.168.1.20.
3. Router của chúng có thể **chặn lưu lượng đi vào không được yêu cầu**.

WebRTC giải quyết từng vấn đề bằng một cơ chế riêng.

## Chuyển file qua WebRTC diễn ra từng bước như thế nào?

Đây là toàn bộ quy trình, từ lúc nhấp "chia sẻ" đến byte cuối cùng:

```
 Sender browser                   Servers                      Recipient browser
 ──────────────                   ───────                      ─────────────────
 1. Choose files ──── metadata ──▶ Signaling server
                                        ◀──────── 2. Open link ────────
 3. Offer (SDP) ─────────────────▶ Signaling ──────────────────▶ Answer (SDP)
 4. Ask STUN "how do I look?" ─▶ STUN servers ◀─ Ask STUN "how do I look?"
 5. ICE candidates ◀─────────────▶ Signaling ◀──────────────────▶ ICE candidates
 6. ICE checks: try LAN → direct internet → TURN relay
 7. DTLS handshake ◀════════════ encrypted ═════════════════▶ DTLS handshake
 8. Data channel: file chunks ═══(direct or via TURN relay)══▶ written to disk
```

**Bước 1–2 — Signaling.** Người gửi chọn file; dịch vụ ghi lại siêu dữ liệu cần thiết
cho link. Khi người nhận mở link, cả hai trình duyệt được kết nối với một máy chủ
[signaling](https://help.strongfolder.com/en/glossary/#signaling). WebRTC không quy định signaling hoạt động thế nào;
StrongFolder dùng PeerJS với máy chủ signaling riêng.

**Bước 3 — Đề nghị và trả lời.** Một trình duyệt tạo một **đề nghị (offer)** theo SDP (Session Description
Protocol): "Tôi muốn một kênh dữ liệu, đây là dấu vân tay mã hóa và khả năng của tôi." Bên
kia đáp lại bằng một **trả lời (answer)**. Cả hai đều đi qua máy chủ signaling.

**Bước 4 — STUN.** Mỗi trình duyệt hỏi một máy chủ [STUN](https://help.strongfolder.com/en/glossary/#stun): "bạn thấy tôi đến từ địa chỉ và
cổng nào?" Câu trả lời là địa chỉ công khai của nó theo ánh xạ của router.
Máy chủ STUN xử lý một yêu cầu rất nhỏ và không có dữ liệu file; StrongFolder dùng các máy chủ STUN công khai,
kể cả của Google, và máy chủ riêng.

**Bước 5 — Ứng viên ICE.** Mỗi trình duyệt thu thập các **ứng viên (candidate)** — những cách có thể để liên lạc
với nó: địa chỉ mạng nội bộ (host), địa chỉ công khai từ STUN (server-reflexive) và
một địa chỉ trên máy chủ chuyển tiếp TURN (relayed). Chúng trao đổi ứng viên qua signaling.

**Bước 6 — Kiểm tra kết nối.** [ICE](https://help.strongfolder.com/en/glossary/#ice) (Interactive Connectivity
Establishment) thử các cặp ứng viên và chọn cặp tốt nhất hoạt động được. Nếu cả hai thiết bị
cùng Wi-Fi, đường nội bộ được chọn. Nếu router cho phép, đường internet trực tiếp ("đục
lỗ" — hole punching) được chọn. Nếu không có đường trực tiếp nào hoạt động, đường chuyển tiếp sẽ được dùng.

**Bước 7 — DTLS.** Trước khi có dữ liệu nào được truyền, các trình duyệt thực hiện bắt tay [DTLS](https://help.strongfolder.com/en/glossary/#dtls)
(TLS được điều chỉnh cho UDP) và kiểm tra rằng dấu vân tay chứng chỉ khớp với dấu vân tay trong
đề nghị và trả lời. Từ đây mọi thứ đều được mã hóa.

**Bước 8 — Kênh dữ liệu.** Trên DTLS chạy SCTP, giúp kênh dữ liệu truyền tin cậy,
đúng thứ tự. Trong StrongFolder, trình duyệt người nhận yêu cầu một file, trình duyệt người gửi
đọc file từ ổ đĩa theo từng mảnh và gửi đi, còn người nhận ghi từng mảnh vào
ổ đĩa ngay khi nhận được — nên kể cả file rất lớn cũng không bao giờ phải nằm vừa trong bộ nhớ.

## STUN, TURN, ICE và các thuật ngữ khác nghĩa là gì?

| Thuật ngữ | Chức năng | Thấy dữ liệu file? | Tiêu chuẩn |
|---|---|---|---|
| Signaling | Chuyển đề nghị, trả lời và ứng viên giữa các trình duyệt | Không | Không được chuẩn hóa (tùy ứng dụng) |
| NAT | Tính năng router chia sẻ một IP công khai cho nhiều thiết bị | — | — |
| STUN | Cho trình duyệt biết địa chỉ và cổng công khai của nó | Không | IETF RFC 8489 |
| ICE | Thu thập ứng viên và chọn đường hoạt động được | Không | IETF RFC 8445 |
| TURN | Chuyển tiếp lưu lượng khi không có đường trực tiếp | Chỉ gói tin đã mã hóa | IETF RFC 8656 |
| DTLS | Mã hóa kết nối (TLS cho UDP) | Mã hóa dữ liệu | IETF RFC 9147 (1.3), RFC 6347 (1.2) |
| Kênh dữ liệu SCTP | Truyền các mảnh tin cậy, đúng thứ tự | Mang dữ liệu (đã mã hóa) | IETF RFC 8831 |

Tất cả được giải thích ngắn gọn trong [bảng thuật ngữ](https://help.strongfolder.com/en/glossary/).

## Khi nào máy chủ chuyển tiếp TURN được dùng, và nó thấy gì?

Máy chủ chuyển tiếp là phương án dự phòng, không phải mặc định. ICE chỉ dùng nó khi không có cặp ứng viên trực tiếp nào
kết nối được — thường là trên các mạng có **NAT đối xứng** (một số nhà mạng di động), **tường lửa
doanh nghiệp** chặn UDP đi ra, hoặc một số VPN.

Nếu không thể kết nối trực tiếp (tường lửa doanh nghiệp nghiêm ngặt, một số mạng di động), luồng dữ liệu đã mã hóa sẽ đi qua máy chủ chuyển tiếp (TURN) của StrongFolder. Máy chủ chuyển tiếp chỉ chuyển dữ liệu đi và không lưu lại.

Máy chủ chuyển tiếp nhận các gói tin đã mã hóa DTLS và chuyển chúng đi. Nó có thể thấy rằng có lưu lượng
đi qua, bao nhiêu và khi nào — không thấy bên trong là gì. Chuyển qua máy chủ chuyển tiếp có thể chậm hơn
chuyển trực tiếp, vì mỗi byte phải đi thêm một chặng qua máy chủ chuyển tiếp. Nếu việc chuyển file
chậm bất thường, hãy thử mạng khác: điểm phát Wi-Fi từ điện thoại hoặc Wi-Fi gia đình thường kết nối
trực tiếp được ở những chỗ mạng văn phòng không làm được.

[Gửi file ngay](https://strongfolder.com)
## Mã hóa WebRTC an toàn đến mức nào?

WebRTC bắt buộc mã hóa: không có cách nào mở kênh dữ liệu không mã hóa.
DTLS dùng các thuật toán mã hóa hiện đại do hai trình duyệt thương lượng, và khóa mới được tạo cho
mỗi kết nối.

Có một lưu ý thẳng thắn áp dụng cho mọi dịch vụ WebRTC. Hai trình duyệt xác minh
nhau thông qua **dấu vân tay** chứng chỉ được trao đổi qua máy chủ
signaling. Do đó bạn tin tưởng rằng signaling của dịch vụ không can thiệp vào chúng. Đó là lý do
StrongFolder mô tả cơ chế bảo vệ của mình là **mã hóa khi truyền** — không phải mã hóa đầu cuối
với khóa do bạn giữ, và không phải "zero-knowledge". Để hiểu rộng hơn
"an toàn" nghĩa là gì, hãy đọc [Chia sẻ file an toàn](https://help.strongfolder.com/en/guides/secure-file-sharing/) và
[Bảo mật và quyền riêng tư](https://help.strongfolder.com/en/security/).

## Vì sao trình duyệt của người gửi phải luôn mở?

Vì trình duyệt của người gửi *chính là* nguồn. Không có bản sao trên máy chủ để dự phòng: kênh
dữ liệu chỉ đọc các mảnh từ ổ đĩa người gửi khi tab đang mở và thiết bị
đang thức. Tab trình duyệt của người gửi phải luôn mở và trực tuyến cho đến khi người nhận tải xong — file đi từ thiết bị của người gửi, không phải từ máy chủ. Cách lên kế hoạch cho điều đó được trình bày trong
[Vì sao người gửi phải trực tuyến](https://help.strongfolder.com/en/guides/why-sender-stays-online/).

## Chuyển file qua WebRTC nhanh đến mức nào?

Không có tốc độ cố định. Mức trần là đoạn chậm nhất trên đường truyền: thường là tốc độ
**tải lên** của người gửi. Theo kinh nghiệm, 1 GB mất khoảng 2,7 phút ở 50 Mbit/s, khoảng 80
giây ở 100 Mbit/s, và chưa đến một phút trên mạng nội bộ nhanh. Thực tế sẽ chậm hơn
các con số này một chút do phần dư của giao thức, tốc độ ổ đĩa và, nếu qua máy chủ chuyển tiếp,
chặng đi thêm. Nhiều người nhận có thể mở cùng một đường link; mỗi người tải trực tiếp từ người gửi. Nhiều lượt tải cùng lúc sẽ chia nhau tốc độ tải lên của người gửi.

## Tóm tắt

Chuyển file qua WebRTC là một cuộc thương lượng ngắn theo sau là một luồng truyền dài, được mã hóa:
signaling giới thiệu các trình duyệt, STUN và ICE tìm đường xuyên qua NAT, TURN chuyển tiếp như
phương án cuối cùng, và các kênh dữ liệu được mã hóa DTLS mang file từ ổ đĩa đến ổ đĩa. Về khía cạnh
thực tế — điều này có ý nghĩa gì với bạn khi là người gửi — hãy bắt đầu với
[Chuyển file P2P trên trình duyệt](https://help.strongfolder.com/en/guides/p2p-file-transfer/) và
[StrongFolder hoạt động như thế nào](https://help.strongfolder.com/en/how-it-works/).

## FAQ

### Kênh dữ liệu WebRTC là gì?

Kênh dữ liệu là phần của WebRTC truyền các byte bất kỳ giữa hai trình duyệt thay vì âm thanh hay video. Nó chạy SCTP trên DTLS trên UDP, nên được mã hóa và có thể cấu hình để truyền tin cậy, đúng thứ tự — đúng điều mà việc chuyển file cần.

### STUN và TURN khác nhau thế nào?

Máy chủ STUN chỉ cho trình duyệt biết địa chỉ công khai của nó trông như thế nào, để hai trình duyệt thử kết nối trực tiếp; không có dữ liệu file nào đi qua nó. Máy chủ TURN là máy chủ chuyển tiếp: khi không có đường trực tiếp nào hoạt động, luồng dữ liệu đã mã hóa đi qua nó. StrongFolder vận hành các máy chủ chuyển tiếp TURN riêng, chỉ chuyển tiếp và không lưu dữ liệu.

### Máy chủ signaling có thấy file của tôi không?

Không. Máy chủ signaling chỉ chuyển các thông điệp kết nối — mô tả phiên và các ứng viên mạng — giữa các trình duyệt. Dữ liệu file đi qua kênh dữ liệu, trực tiếp hoặc qua máy chủ chuyển tiếp TURN.

### Chuyển file qua WebRTC có được mã hóa không?

WebRTC mã hóa mọi kênh dữ liệu bằng DTLS, nên luồng file luôn được mã hóa trong quá trình truyền trên mọi kết nối. WebRTC không cho phép kênh dữ liệu không mã hóa. Khóa do hai trình duyệt thương lượng; dấu vân tay của chúng đi qua signaling, vì vậy đây là mã hóa khi truyền chứ không phải mã hóa đầu cuối với khóa do bạn quản lý.

### Vì sao chuyển file qua WebRTC đôi khi thất bại hoặc chậm?

Thường là do đường mạng: tường lửa nghiêm ngặt hoặc VPN chặn UDP trực tiếp, nên kết nối phải chuyển sang máy chủ chuyển tiếp TURN qua TCP, hoặc hoàn toàn không kết nối được. Hãy thử mạng khác (ví dụ điểm phát Wi-Fi từ điện thoại), tắt VPN, hoặc nhờ bộ phận IT cho phép WebRTC.

### Máy chủ chuyển tiếp TURN có đọc được file của tôi không?

Máy chủ chuyển tiếp chuyển các gói tin đã mã hóa DTLS giữa hai trình duyệt. Nó thấy lưu lượng đã mã hóa, kích thước và thời điểm, không thấy nội dung file, và máy chủ chuyển tiếp của StrongFolder không lưu những gì nó chuyển đi.