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ụ.
WebRTC là gì?
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 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 (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:
- 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.
- 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.
- 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. 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: "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 (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 (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ữ.
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.
Miễn phí · ngay trên trình duyệt · không cần đăng ký
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 và Bảo mật và quyền riêng tư.
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.
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 và StrongFolder hoạt động như thế nào.