Giải thích chi tiết và ứng dụng thực tế của STUN/TURN/TURNS/SFU trong WebRTC

Ngày 12 tháng 4 năm 2025

mục lục

WebRTC là gì?

WebRTC (Web Real-Time Communication) là một công nghệ mở cho phép giao tiếp âm thanh, video và dữ liệu theo thời gian thực giữa các trình duyệt. Công nghệ này đang được các công ty như Google chuẩn hóa, vì nó cho phép giao tiếp P2P chỉ bằng API JavaScript, mà không cần thêm plugin hoặc phần mềm nào khác.

WebRTC bao gồm ba thành phần chính sau:

getUser MediaMột API thu thập dữ liệu âm thanh và video từ các thiết bị như máy ảnh và micro.
Kết nối RTCPeer: Một API cốt lõi thiết lập liên lạc giữa các thiết bị ngang hàng và trao đổi phương tiện truyền thông và dữ liệu.
Kênh dữ liệu RTCMột kênh dữ liệu có thể được sử dụng để truyền tải tập tin, trò chuyện và nhiều hơn nữa.

Các API này cho phép phát triển nhiều ứng dụng thời gian thực, chẳng hạn như cuộc gọi video, hội nghị âm thanh và chia sẻ tệp. Tuy nhiên, giao tiếp thực tế liên quan đến việc vượt qua NAT và các vấn đề về tường lửa, do đó việc hiểu và triển khai các công nghệ vượt qua NAT như STUN/TURN/TURNS là rất cần thiết.

Sự khác biệt và vai trò của STUN, TURN và TURNS

Để đạt được kết nối ngang hàng ổn định với WebRTC, cơ chế xuyên NAT là rất cần thiết. Ở đây, chúng ta sẽ giải thích chi tiết sự khác biệt về kỹ thuật, các kịch bản sử dụng, ưu điểm và nhược điểm của STUN, TURN và TURNS, những công nghệ tiêu biểu.

STUN chủ yếu là một giao thức được sử dụng để xác định địa chỉ IP bên ngoài của một thiết bị trong môi trường NAT, trong khi TURN là một giao thức hoạt động như một máy chủ chuyển tiếp khi không thể thiết lập kết nối trực tiếp. Mặt khác, TURNS mã hóa giao tiếp TURN bằng TLS và sử dụng cùng cổng 443 với HTTPS, cho phép giao tiếp dưới các tường lửa nghiêm ngặt như trong mạng doanh nghiệp.

Bằng cách hiểu rõ đặc điểm của từng phương pháp và sử dụng chúng một cách phù hợp, bạn có thể nâng cao tỷ lệ thành công và chất lượng giao tiếp WebRTC.

Vai trò và đặc điểm của STUN (UDP)

STUN (Session Traversal Utilities for NAT) là một ứng dụng khách.Địa chỉ IP và cổng bên ngoàiĐây là một giao thức đơn giản để tìm ra địa chỉ IP của bạn. Ví dụ, nếu máy tính của bạn nằm sau NAT, nó không biết địa chỉ IP toàn cầu của chính nó, nhưng nó có thể lấy được "địa chỉ IP và cổng nhìn từ bên ngoài" bằng cách truy vấn máy chủ STUN.

Máy chủ STUN hoạt động như một bản sao, trả về thông tin nguồn của yêu cầu nhận được chính xác như ban đầu. Kết quả là, máy khách có thể biết được địa chỉ IP toàn cầu của chính nó và số cổng được NAT gán (một ứng cử viên Server Reflexive).

Giao tiếp STUN thường sử dụng UDP, với cổng mặc định là 3478 (UDP/3478). Vì chỉ yêu cầu giao tiếp UDP nhẹ và một lần duy nhất, nên nó có chi phí và độ trễ thấp, và hầu như không gây tải cho máy chủ. Do đó, trong môi trường cho phép giao tiếp UDP, STUN là phương pháp đầu tiên được thử để vượt qua NAT.

Các tình huống sử dụng STUN

STUN hiệu quả trong môi trường cần thiết phải vượt qua NAT nhưng bản thân giao tiếp UDP không bị chặn, chẳng hạn như mạng gia đình và kết nối di động. Nếu các máy khách có thể lấy được địa chỉ IP và cổng bên ngoài của nhau bằng STUN, chúng có thể thiết lập giao tiếp trực tiếp (ngang hàng). Vì đường truyền là trực tiếp, độ trễ thấp và chất lượng có thể được duy trì ở mức cao. Ngoài ra, vì máy chủ chỉ hỗ trợ trao đổi thông tin IP, chi phí có thể được giữ ở mức rất thấp. Ví dụ, trong các trò chơi trực tuyến hoặc cuộc gọi video, nếu cả hai thiết bị đều nằm trên NAT tương đối mở, STUN là đủ để thiết lập kết nối ngang hàng.

Những hạn chế và nhược điểm của STUN

STUN chỉ đơn thuần là một phương tiện để "tìm địa chỉ IP bên ngoài của chính mình", và tùy thuộc vào loại NAT và các ràng buộc của tường lửa, việc thiết lập kết nối chỉ bằng STUN có thể không khả thi. Đặc biệt, trong môi trường NAT đối xứng hoặc tường lửa nghiêm ngặt, các gói tin từ phía bên kia có thể không đến được địa chỉ nhận được thông qua STUN, khiến việc liên lạc trở nên bất khả thi.

Hơn nữa, trong một số mạng doanh nghiệp, bản thân giao tiếp UDP có thể bị chặn, trong trường hợp đó yêu cầu STUN sẽ không được gửi đi. Tóm lại, STUN là một cơ chế để "xác định xem giao tiếp trực tiếp có khả thi hay không", và nó không hoạt động trong môi trường mà giao tiếp trực tiếp là không thể về mặt vật lý. Do đó, STUN được sử dụng trong giai đoạn đầu tiên của quá trình thu thập ứng viên trong ICE (được mô tả sau), và nếu STUN không đủ, nó được thiết kế để chuyển sang TURN, sẽ được mô tả sau.

Vai trò và đặc điểm của TURN (UDP)

TURN (Traversal Using Relays around NAT) là một giao thức hoạt động như một máy chủ chuyển tiếp khi không thể giao tiếp trực tiếp thông qua STUN. Máy chủ TURN hoạt động như một điểm chuyển tiếp có thể truy cập toàn cầu, đóng vai trò trung gian giữa máy khách và đối tác truyền thông để chuyển tiếp các gói dữ liệu. Máy khách kết nối với máy chủ TURN và nhận được địa chỉ IP và cổng chuyển tiếp được gọi là ứng viên chuyển tiếp. Từ đó, dữ liệu và phương tiện được trao đổi với bên kia thông qua máy chủ TURN đó.

Giao thức TURN thường sử dụng giao thức UDP để giao tiếp, vì vậy, miễn là UDP khả dụng, nó có thể chuyển tiếp các gói dữ liệu đa phương tiện theo cách rất gần với giao tiếp trực tiếp. Theo mặc định, nó chấp nhận giao thức TURN trên cổng 3478 (UDP), giống như STUN. Ngay cả khi số cổng UDP bị hạn chế bởi chính sách tường lửa, TURN vẫn có thể chạy trên một cổng được cho phép, chẳng hạn như UDP/443. Miễn là UDP khả dụng, nó có thể cung cấp khả năng chuyển tiếp thời gian thực tốt hơn so với TCP.

Các kịch bản sử dụng TURN

Việc chuyển tiếp thông tin là rất cần thiết khi không thể thiết lập được kết nối trực tiếp với bên kia. Ví dụ:Điều này có thể xảy ra khi một hoặc cả hai bên đều nằm sau tường lửa nghiêm ngặt của công ty, hoặc khi việc xuyên tường lửa UDP thất bại giữa các NAT đối xứng.Trong môi trường như vậy, việc liên lạc là không thể nếu không thông qua máy chủ TURN, do đó TURN đóng vai trò là tuyến phòng thủ cuối cùng.

WebRTC hướng đến việc tất cả các bên tham gia có thể giao tiếp trực tiếp, nhưng nếu điều này không thể thực hiện được, quá trình giao tiếp có thể tiếp tục bằng cách chuyển sang sử dụng giao thức TURN. Trong thực tế hoạt động, chiến lược phổ biến là trước tiên thử kết nối trực tiếp bằng STUN, và chỉ chuyển sang chuyển tiếp TURN nếu kết nối đó thất bại. Ví dụ, trong một cuộc họp video qua mạng nội bộ công ty, nếu các bên không thể giao tiếp trực tiếp, quá trình giao tiếp sẽ tự động chuyển sang thông qua máy chủ TURN, cho phép người dùng tiếp tục cuộc trò chuyện mà không hề hay biết.

Lợi ích của TURN

Ưu điểm lớn nhất là độ tin cậy. Trong bất kỳ môi trường NAT hoặc tường lửa nào, miễn là có thể thiết lập liên lạc từ máy khách đến máy chủ TURN, thì cuối cùng có thể đạt được giao tiếp ngang hàng. Ngoài ra, vì TURN là phần mở rộng của giao thức STUN, nên một máy chủ duy nhất (như coturn, sẽ được thảo luận sau) có thể xử lý cả yêu cầu STUN và TURN. Sau khi kết nối được thiết lập, dữ liệu đa phương tiện tiếp theo được truyền tải dưới dạng luồng, vì vậy từ góc nhìn của người dùng, quá trình giao tiếp diễn ra liền mạch với độ trễ rất nhỏ.

Nhược điểm của TURN

Nhược điểm lớn nhất là mức tiêu thụ tài nguyên và độ trễ. Với TURN, tất cả dữ liệu âm thanh và video đều đi qua máy chủ, đòi hỏi một lượng băng thông và sức mạnh xử lý đáng kể ở phía máy chủ. Ví dụ, giả sử một cuộc gọi video trực tiếp tiêu thụ 1 Mbps băng thông một chiều, một phép tính đơn giản cho thấy 1000 người dùng đồng thời sẽ cần băng thông chuyển tiếp là 1 Gbps. Do đó, chi phí vận hành của máy chủ TURN rất cao, và các dịch vụ quy mô lớn cần nhiều máy chủ chuyển tiếp TURN để mở rộng quy mô.

Hơn nữa, đường truyền thông tin dài hơn làm tăng độ trễ, dẫn đến hiện tượng chậm trễ về thời gian và giảm chất lượng video và âm thanh. Ngoài ra, TURN không hoàn toàn là giao thức ngang hàng (peer-to-peer) như STUN, khiến nó kém an toàn hơn một chút (mặc dù các máy chủ TURN thường chỉ chuyển tiếp các gói RTP/datagram không được mã hóa và không giải thích nội dung của chúng).

Nhìn chung, TURN chỉ nên được sử dụng khi cần thiết. Trên thực tế, nhiều giao tiếp WebRTC có thể được kết nối trực tiếp bằng STUN, và số liệu thống kê của Google cho thấy khoảng 861 cuộc gọi TP3T được hoàn tất mà không cần chuyển tiếp (ngang hàng). Chỉ có khoảng 141 trường hợp TP3T còn lại yêu cầu TURN, và điều quan trọng là phải chuẩn bị sẵn cơ sở hạ tầng TURN cho 141 trường hợp TP3T đó.

Vai trò và đặc điểm của TURNS (TLS qua TCP/443)

TURNS là viết tắt của "TURN over TLS," là một phương pháp mã hóa thông tin liên lạc chuyển tiếp sử dụng giao thức TURN với TLS (Transport Layer Security).Giao tiếp TURN được bảo vệ bằng TLS (HTTPS)Nó thường được phục vụ trên cổng TCP 443.Vì cổng 443 trùng với số cổng của HTTPS, nên nó dễ dàng vượt qua tường lửa của doanh nghiệp hơn, đây là một lợi thế vì nó giúp dễ dàng bỏ qua máy chủ proxy và kiểm duyệt.。

Ví dụ, trong mạng nội bộ của một công ty, chỉ có cổng 80 và 443 được cho phép giao tiếp bên ngoài. Ngay cả trong trường hợp đó, máy chủ TURN sử dụng giao tiếp TLS trên cổng 443 vẫn rất có khả năng hoạt động bình thường. Thêm vào đó, vì được mã hóa bằng TLS, nội dung giao tiếp ít có khả năng bị bên thứ ba chặn bắt và đảm bảo an toàn.

Trong WebRTC, các cài đặt""urls": "turns:turnserver:443""Tương tự như trong lược đồ URIlượt:Bằng cách chọn tùy chọn này, bạn có thể sử dụng máy chủ TURN được mã hóa TLS này.

các kịch bản sử dụng TURNS

Trong giao tiếp WebRTC dưới những hạn chế nghiêm ngặt, chẳng hạn như trong mạng nội bộ doanh nghiệp, TURNS rất hữu ích khi tất cả các phương thức khác đều bị chặn. Ngay cả trong môi trường mà tất cả các cổng UDP và TCP nói chung đều bị chặn, nhiều chính sách vẫn cho phép giao tiếp nếu nó được xử lý giống như giao tiếp HTTPS, khiến việc bật TURN trên cổng TLS 443 trở thành giải pháp cuối cùng thiết thực.

Nó cũng được sử dụng trong các trường hợp một số cổng bị đóng trên mạng Wi-Fi công cộng, hoặc khi phía máy khách chỉ có thể thực hiện giao tiếp TLS. Tóm lại,Trước tiên, hãy thử UDP, nếu không được thì thử TCP, và nếu vẫn không thành công, hãy thử TLS trên cổng 443.Đây được coi là giai đoạn cuối cùng của một quá trình chuyển đổi dần dần.

Lợi ích của việc xoay vòng

Ưu điểm lớn nhất là khả năng chống lại tường lửa cao. Giao tiếp được mã hóa TLS rất khó phân biệt với HTTPS thông thường, làm tăng khả năng vượt qua ngay cả các bộ lọc nghiêm ngặt. Đặc biệt khi triển khai hệ thống hội nghị trực tuyến trong một công ty, cần phải cho phép kết nối từ mạng nội bộ ra bên ngoài, và giao tiếp TCP/443 TLS dễ được chấp nhận hơn từ góc độ chính sách bảo mật. Hơn nữa, vì nó được mã hóa, tính bảo mật của giao tiếp với máy chủ chuyển tiếp được đảm bảo (tuy nhiên, nội dung, chẳng hạn như video, thường đã được mã hóa ở lớp WebRTC).

Nhược điểm của lượt chơi

Nhược điểm lớn nhất là sự suy giảm hiệu năng. Bên cạnh độ trễ và tải trọng của chính TURN, còn có thêm chi phí phát sinh từ TLS và TCP. TCP có cơ chế truyền lại hoạt động khi các gói tin bị mất để đảm bảo truyền tải đáng tin cậy, nhưng nó không phù hợp với phương tiện truyền thông thời gian thực, và nếu xảy ra mất mát, video và âm thanh có thể không phát mượt mà.

Hơn nữa, TCP dễ bị tắc nghẽn đầu hàng do cơ chế điều khiển thứ tự gói tin.So với UDP, độ trễ (dao động) cũng tăng lên.Hơn nữa, tải CPU từ quá trình mã hóa và giải mã TLS cũng được cộng thêm. Kết quả là, theo báo cáo, độ trễ bổ sung từ 50ms trở lên xảy ra trong các phép đo thực tế, gây ra hiện tượng giật lag đáng kể cho người dùng. Đặc biệt, trong các cuộc gọi video, độ trễ tăng lên này có thể làm gián đoạn nhịp độ cuộc trò chuyện và làm cho sự sai lệch về thời gian trở nên rõ rệt hơn.

Do đó, mặc dù TURNS có thể được coi là "giải pháp cuối cùng" về mặt chất lượng, nhưng nó cũng là một cứu cánh đáng tin cậy trong những tình huống không còn lựa chọn nào khác ngoài việc đảm bảo thiết lập được liên lạc.

Trong những năm gần đây, một phương pháp tiếp cận mới (TURN over QUIC) đã được xem xét, hoạt động trên cổng UDP 443 và sử dụng DTLS/QUIC thay vì TLS, nhưng nó vẫn đang trong giai đoạn tiêu chuẩn hóa và chưa phổ biến.

Luồng giao tiếp khi UDP STUN không khả dụng

Bài viết này giải thích từng bước cách thức xử lý ICE của WebRTC diễn ra khi STUN qua UDP không khả dụng. Chúng ta sẽ xem xét cách thức đàm phán ICE chuyển sang phương án dự phòng trong trường hợp UDP bị chặn hoàn toàn, chẳng hạn như trên mạng doanh nghiệp.

Máy khách gửi truy vấn IP bên ngoài (UDP/3478) đến máy chủ STUN:
Các ứng dụng khách WebRTC (trình duyệt)Máy chủ băngMột yêu cầu ràng buộc (yêu cầu xác minh địa chỉ bên ngoài) được gửi qua cổng UDP 3478 đến máy chủ STUN được chỉ định. Đây là giai đoạn đầu tiên của quá trình thu thập ứng viên ICE, và nếu thành công, máy chủ sẽ trả về địa chỉ IP toàn cầu và số cổng của chính nó, và được thêm vào danh sách ứng viên với tư cách là Ứng viên phản xạ máy chủ (ứng viên srflx).
Các gói tin UDP bị tường lửa chặn và không nhận được phản hồi.
Trong trường hợp này, giao tiếp UDP không thể kết nối ra bên ngoài do cài đặt tường lửa mạng. Do đó, các yêu cầu gửi đến máy chủ STUN không đến được máy chủ hoặc phản hồi không được trả về cho máy khách. Kết quả là, máy khách không thể thực hiện được yêu cầu.Không thể nhận phản hồi STUNDo đó, không thể xác định địa chỉ IP bên ngoài. Trình quản lý kết nối (ICE agent) chờ phản hồi trong một khoảng thời gian nhất định, nhưng sau đó hết thời gian chờ. Từ góc nhìn của người dùng, quá trình kết nối vẫn đang diễn ra và không có thông báo lỗi nào được hiển thị, nhưng trên thực tế...Thu thập ứng viên thất bạiĐang trong quá trình thực hiện.
Kiểm tra kết nối trực tiếp ICE thất bại vì không tìm thấy ứng viên Server Reflexive nào:
Thông thường, nếu STUN thành công, máy khách sẽ có một ứng viên máy chủ (địa chỉ IP cục bộ của nó) cũng như một ứng viên phản xạ máy chủ (địa chỉ IP toàn cầu của nó), và sẽ thực hiện kiểm tra kết nối bằng cách kết hợp nó với một ứng viên tương tự trên thiết bị đầu cuối ở xa. Tuy nhiên, nếu STUN thất bại và không có ứng viên IP toàn cầu,Số lượng ứng viên cho các kết nối trực tiếp giữa người dùng với nhau là cực kỳ hạn chế.Điều này thường xảy ra. Ví dụ, nếu cả hai bên chỉ có địa chỉ IP riêng, họ sẽ không thể kết nối với nhau. Kết quả là, ICE sẽ xác định rằng "không thể kết nối trực tiếp". Nếu máy chủ ICE (TURN) chưa được cấu hình, toàn bộ quá trình ICE sẽ được coi là thất bại ở giai đoạn này và kết nối WebRTC sẽ không được thiết lập (bảng điều khiển dành cho nhà phát triển sẽ hiển thị...).ICE đã thất bạiやTrạng thái kết nối ICE: thất bạiCác lỗi như sau sẽ được hiển thị.
Đang cố gắng lấy ứng viên chuyển tiếp TURN (qua TCP/TLS/443):
Ngay cả khi STUN không thể trực tiếp tìm được ứng viên,Máy chủ băngNếu máy chủ TURN được chỉ định, tác nhân ICE sẽTiếp theo có nghĩa làChúng ta hãy tiếp tục. Trong trường hợp này, UDP không hoạt động, vì vậy máy khách sẽ cố gắng kết nối với máy chủ TURN bằng TCP hoặc TLS (ví dụ).lượt:turn.example.com:443Nếu được cấu hình, quá trình bắt tay TLS sẽ bắt đầu. May mắn thay, tường lửa cho phép giao tiếp HTTPS trên TCP 443, do đó kết nối TLS TURN đã thành công. Máy khách sẽ lấy được địa chỉ chuyển tiếp trên máy chủ TURN để chuyển tiếp.Ứng viên tiếp sứcỨng viên chuyển tiếp được xác định. Đây là "điểm đến ứng viên ảo để liên lạc thông qua máy chủ TURN". Mặt khác, đối tác liên lạc (phía bên kia) cũng sẽ nhận được một ứng viên chuyển tiếp, hoặc nếu mạng ổn định, họ sẽ có ứng viên trực tiếp hoặc ứng viên STUN ngay từ đầu. Trong mọi trường hợp, nếu ít nhất một bên có ứng viên chuyển tiếp, bên kia có thể thử kết nối với máy chủ TURN đó.
Thiết lập kết nối ICE (hoặc lỗi cuối cùng) thông qua bộ chuyển tiếp:
Khi cả hai bên đều nhận được các ứng viên chuyển tiếp khả dụng (trong ví dụ này, các ứng viên chuyển tiếp cho một hoặc cả hai bên), ICE sẽ sử dụng chúng để thực hiện kiểm tra kết nối. Vì việc giao tiếp thông qua máy chủ TURN có thể được chuyển tiếp sau khi thiết lập được thỏa thuận với máy chủ, một kênh đa phương tiện sẽ được mở ngay cả khi lưu lượng UDP trực tiếp không thể truyền giữa các bên. Điều này cho phép người dùng bắt đầu giao tiếp video và âm thanh. Sau khi kết nối được thiết lập, mặc dù có chi phí phát sinh do TCP qua TLS, cuộc trò chuyện vẫn có thể diễn ra. Ngược lại, nếu điều này cũng thất bại (ví dụ: nếu máy chủ proxy của công ty phát hiện và chặn giao tiếp TLS không phải HTTP, hoặc nếu xác thực với máy chủ TURN thất bại), thì ICE sẽ thất bại hoàn toàn và kết nối bị hủy bỏ. Ứng dụng phải phát hiện tình huống này và thông báo cho người dùng bằng một thông báo như "Không thể thiết lập kết nối."

Phần trên mô tả quá trình đàm phán ICE trong môi trường khó khăn khi giao thức UDP không khả dụng. Tóm lại, hệ thống sẽ thử các máy chủ ứng cử viên theo thứ tự "máy chủ → STUN → TURN", và nếu không có máy chủ nào hoạt động, kết nối sẽ thất bại. Điều quan trọng là các nhà phát triển phải hiểu hành vi này và ít nhất phải bao gồm máy chủ TURN/TURNS trong danh sách máy chủ ICE để đảm bảo rằng có thể thiết lập liên lạc ngay cả trong trường hợp xấu nhất. Hơn nữa, khi nhận được yêu cầu từ người dùng, cần phải khắc phục sự cố, chẳng hạn như suy luận các vấn đề về môi trường mạng (ví dụ: chặn UDP) từ thông tin như "ICE thất bại" và kiểm tra xem có cài đặt máy chủ TURN nào bị thiếu hay không.

Xây dựng và cấu hình máy chủ STUN/TURN/TURNS bằng coturn.

Nếu bạn đang thiết lập máy chủ STUN/TURN của riêng mình, hãy sử dụng một giải pháp mã nguồn mở. coturnViệc sử dụng Coturn khá phổ biến. Coturn là một máy chủ hỗ trợ cả STUN và TURN, và cũng có thể hỗ trợ TURNS (TLS) tùy thuộc vào cấu hình. Ở đây, chúng ta sẽ giải thích quy trình và các điểm cấu hình để cài đặt Coturn trên máy chủ Linux và xây dựng một máy chủ cung cấp STUN/TURN/TURNS. Ngoài ra, các tệp cấu hình điển hình (turnserver.confTôi cũng sẽ đưa ra một ví dụ về điều này.

Cài đặt và các thiết lập cơ bản

cài đặt

Trong trường hợp của Ubuntu hoặc Debian,căn hộBạn có thể cài đặt gói coturn từ đây. Ví dụ, bạn có thể cài đặt và cấu hình để nó tự động khởi động bằng lệnh sau.

# Ubuntu/Debianの場合
sudo apt-get install coturn
sudo sed -i 's/#TURNSERVER_ENABLED=1/TURNSERVER_ENABLED=1/' /etc/default/coturn
sudo systemctl enable --now coturn

Các bước trên sẽ khởi động máy chủ coturn dưới dạng tiến trình nền. Theo mặc định, tệp cấu hình /etc/turnserver.conf Bây giờ chúng ta sẽ tải tập tin lên, rồi tiến hành chỉnh sửa (nhớ tạo bản sao lưu trước khi chỉnh sửa).

Cài đặt cơ bản

turnserver.confBây giờ, chúng ta hãy thiết lập các mục sau.

tên miền và tên máy chủ: Đây là tên miền hoặc mã định danh của máy chủ TURN. Nó có thể được sử dụng trong quá trình xác thực máy khách WebRTC, nhưng nói chung, bất kỳ chuỗi ký tự nào cũng được chấp nhận. Ví dụ: realm=example.com，tên máy chủ=example.com。
cổng nghe: Đây là số cổng UDP mà TURN và STUN sử dụng để lắng nghe. Cổng mặc định là 3478.địa chỉ IP đang ngheBạn cũng có thể liên kết với một card mạng cụ thể, nhưng thông thường0.0.0.0Chúng tôi chấp nhận mọi yêu cầu.
cổng lắng nghe tls: Đây là số cổng TCP để lắng nghe giao thức TLS (TURNS). Thông thường, cổng 443 hoặc 5349 được chỉ định. Ví dụ: tls-listening-port=443。
tự động ip: Nếu máy chủ nằm sau NAT, hãy chỉ định địa chỉ IP toàn cầu của chính nó (điều này cho phép máy chủ nhận biết sự tương ứng giữa địa chỉ IP nội bộ và bên ngoài). Điều này không cần thiết đối với các máy chủ có địa chỉ IP toàn cầu trực tiếp.
Phương thức xác thực: Giao thức TURN của WebRTC sử dụng xác thực dài hạn (Long-Term Credentials).lt-cred-mechKích hoạt Cơ chế Chứng chỉ Dài hạn.người dùng = tên người dùng:mật khẩuHãy thiết lập tên người dùng và mật khẩu của bạn theo định dạng sau:sử dụng bí mật xác thựcXác thực động được thực hiện bằng cách sử dụng (phương pháp sau là xác thực dựa trên mã thông báo, có hiệu quả trong việc cải thiện bảo mật, nhưng ở đây chúng ta sẽ sử dụng xác thực người dùng tĩnh đơn giản làm ví dụ).
Cài đặt nhật ký: Để khắc phục sự cốtệp nhật kýTiếp theo, đường dẫn đến tệp nhật ký đã được chỉ định.GeorgeBạn nên bật tính năng ghi nhật ký chi tiết.

Cài đặt tường lửa

Về phía máy chủ, đối với lệnh STUN/TURN, cần thực hiện các lệnh này.Cổng UDP 3478và đối với TURN/TLSCổng TCP 443Bạn cần mở cổng (hoặc 5349). Ngoài ra, vì TURN relay sử dụng cổng UDP 10000-20000 theo mặc định, bạn cũng cần mở dải cổng này trên máy chủ (nếu cần).cổng nhỏとcổng tối đa(Phạm vi có thể được thay đổi.)

Các thông tin sau đây phản ánh các thiết lập cơ bản đã đề cập ở trên./etc/turnserver.confĐây là một ví dụ.

# TURNサーバの名称とレルム（ドメイン）
realm=example.com
server-name=example.com

# ネットワーク設定
listening-ip=0.0.0.0           # すべてのIPアドレスで待受
external-ip=203.0.113.10       # サーバのグローバルIP（必要な場合）

# ポート設定
listening-port=3478            # STUN/TURN用 UDPポート
tls-listening-port=443         # TLS用 TCPポート (443番)
min-port=10000                 # 中継に使用するポート範囲（下限）
max-port=20000                 # 中継に使用するポート範囲（上限）

# ログ設定
log-file=/var/log/turnserver.log
verbose                        # 詳細ログを有効化
fingerprint                    # パケットにfingerprint属性を付与

# 認証設定（長期認証方式）
lt-cred-mech                   # 長期認証を有効化
user=webrtcuser:secretpass123  # ユーザ名:パスワード を設定

# TLS/SSL証明書の指定
cert=/etc/letsencrypt/live/example.com/fullchain.pem   # サーバ証明書
pkey=/etc/letsencrypt/live/example.com/privkey.pem     # 秘密鍵

Trong phần trên, miềnví dụ.comTôi đã nhận được chứng chỉ Let's Encrypt và đang sử dụng nó để cấu hình TLS.lt-cred-mechKích hoạt xác thực dài hạn.người dùngĐiều này thiết lập xác thực đơn giản bằng tên người dùng và mật khẩu. Trong thực tế sử dụng...sử dụng bí mật xác thựcとbí mật xác thực tĩnhMặc dù nên sử dụng phương pháp dựa trên mã thông báo để cấp chứng chỉ tạm thời, chúng tôi sẽ bỏ qua phần giải thích đó ở đây.

Các biện pháp phòng ngừa khi sử dụng TLS

Khi chạy Coturn trên cổng 443, bạn cần cẩn thận về quyền truy cập cổng trong môi trường Linux. Các cổng dưới 1024 được gọi là cổng đặc quyền và thường không thể mở nếu không có quyền root. Gói coturn của Ubuntu mặc định làngười phục vụVì lệnh này do người dùng thực thi, nên cổng 443 không thể được liên kết trực tiếp. Để khắc phục vấn đề này,/etc/default/coturnThay đổi người dùng thực thi thành root.mũ đặtYêu cầungười phục vụtệp thực thidịch vụ liên kết mạngCó nhiều cách để cấp quyền. Ví dụ, trong trường hợp sau,sudo setcap cap_net_bind_service=+ep /usr/bin/turnserverViệc thực hiện thao tác này sẽ cho phép người dùng không phải root liên kết với các cổng có số hiệu thấp. Ngoài ra, hãy chỉ định đường dẫn chính xác cho tệp chứng chỉ (cert/pkey) và thiết lập quyền truy cập tệp sao cho người dùng coturn có thể đọc được. Sau khi thay đổi các thiết lập...sudo systemctl restart coturnKhởi động lại dịch vụ và kiểm tra nhật ký xem có lỗi nào không.

Kiểm tra hoạt động

Sau khi máy chủ Coturn khởi động, chúng ta sẽ thực hiện một bài kiểm tra sử dụng máy khách STUN để xác minh hoạt động của nó, và sau đó thử thiết lập kết nối ICE từ một ứng dụng WebRTC trong trình duyệt.stunclientyêu cầu(apt-get install stun-client(Có thể được triển khai bằng)stunclient <địa chỉ IP máy chủ> 3478Thực hiện theo cách này sẽ cho phép bạn kiểm tra xem có thể lấy được địa chỉ IP bên ngoài hay không. Ngoài ra, trong trình duyệt, các ứng viên ICE sẽ được liệt kê trong nhật ký công cụ dành cho nhà phát triển.srflix(Ứng viên phản xạ máy chủ) vàrơleVui lòng kiểm tra xem bạn đã nhận được ứng viên chưa. Nếu không được, hãy khắc phục sự cố ở các điểm sau.

Kiểm tra xem các cổng cần thiết đã được mở trong cài đặt tường lửa của máy chủ (iptables hoặc nhóm bảo mật đám mây) chưa.
Kiểm tra xem URI, cổng và thông tin xác thực chính xác đã được cấu hình trong cài đặt máy chủ ICE phía máy khách chưa (được mô tả ở phần sau).
turnserver.confのvương quốcHãy đảm bảo các thiết lập khớp với xác thực của máy khách (điều này thường không phải là vấn đề trong WebRTC dựa trên trình duyệt vì nó tự động gán miền, nhưng hãy cẩn thận với các triển khai tùy chỉnh).
nhật ký coturn (/var/log/turnserver.log) Kiểm tra xem có lỗi xác thực nào không (NGƯỜI DÙNG SAICác lỗi như trên cho thấy sự không khớp giữa tên người dùng và mật khẩu.

Nếu các thiết lập trên là chính xác, máy chủ STUN/TURN/TURNS của riêng bạn sẽ hoạt động, cho phép hỗ trợ kết nối WebRTC trong nhiều môi trường mạng khác nhau.

Ví dụ về cấu hình máy chủ ICE trong ứng dụng khách WebRTC (JavaScript)

Để thực sự sử dụng máy chủ STUN/TURN mà chúng ta vừa xây dựng ở phía ứng dụng WebRTC (trình duyệt),Cấu hình máy chủ ICEViệc này đã được thực hiện. Trong API WebRTC JavaScript,Kết nối RTCPeerKhi tạo cấu hình, bạn có thể chỉ định danh sách các máy chủ STUN/TURN. Tiếp theo, chúng ta sẽ trình bày một ví dụ mã cụ thể chỉ định tất cả các máy chủ STUN/TURN và giải thích ý nghĩa của nó.

Trước tiên, hãy tạo một đối tượng cấu hình cho máy chủ ICE. Sử dụng tên miền của máy chủ của bạn.turn.example.com(Thay thế nếu cần) STUN không yêu cầu xác thực, vì vậy chỉ cần chỉ định URI, trong khi TURN/TURNS yêu cầu xác thực, do đó tên người dùng và mật khẩu cũng được chỉ định.

const iceConfig = {
  iceServers: [
    // 1. STUNサーバ（UDP/3478）
    { urls: 'stun:turn.example.com:3478' },
    // 2. TURNサーバ（UDP/443経由）
    { urls: 'turn:turn.example.com:443?transport=udp', username: 'webrtcuser', credential: 'secretpass123' },
    // 3. TURNサーバ（TCP/443 + TLS = TURNS）
    { urls: 'turns:turn.example.com:443', username: 'webrtcuser', credential: 'secretpass123' }
  ]
};
const pc = new RTCPeerConnection(iceConfig);

Những điều nêu trênMáy chủ băngMảng này có ba phần tử được chỉ định.

STUN: stun:turn.example.com:3478
Tham số này chỉ định địa chỉ máy chủ STUN của riêng bạn (nếu bỏ qua cổng, cổng 3478 sẽ được sử dụng). STUN được sử dụng để phát hiện tấn công NAT và truy xuất ứng viên, và trình duyệt trước tiên sẽ cố gắng truy vấn máy chủ này qua UDP để lấy các ứng viên Server Reflexive.
QUAY (UDP): turn:turn.example.com:443?transport=udp
Máy chủ TURN của riêng tôiCổng UDP 443Đây là thiết lập cần sử dụng. Thông tin xác thực là tên người dùng bạn đã thiết lập trong coturn trước đó.webrtcuservà mật khẩumật khẩu bí mật123Điều này chỉ định tham số truy vấn.?transport=udpBằng cách thêm tùy chọn này, hệ thống sẽ cố gắng thiết lập kết nối TURN bằng giao thức UDP (nếu không được chỉ định, trình duyệt sẽ thử UDP trước, và nếu thất bại, nó cũng sẽ thử TCP). Cài đặt này đảm bảo rằng ngay cả khi kết nối trực tiếp qua STUN thất bại, vẫn tìm thấy một ứng viên chuyển tiếp TURN trên cổng UDP 443 (ứng viên chuyển tiếp).
TURN (TLS/TCP): lượt:turn.example.com:443
TURN sử dụng TLSĐây là cấu hình máy chủ TURNS. Ở đây cũng có tên người dùng và mật khẩu được chỉ định. Trình duyệt thiết lập kết nối TLS đến mục này trên cổng TCP 443 và truy xuất ứng viên chuyển tiếp TURN. Đây là ứng viên chuyển tiếp dự phòng; ngay cả khi giao tiếp UDP hoàn toàn không thể thực hiện được, sự hiện diện của ứng viên này vẫn mang lại hy vọng thiết lập được liên lạc.

Kết nối RTCPeerKhi các thông tin này được tạo ra, hệ thống sẽ lần lượt cố gắng kết nối đến các máy chủ ICE được chỉ định và thu thập các ứng viên. Đầu tiên, tác nhân ICE thu thập các ứng viên STUN (srflx), sau đó đồng thời thu thập các ứng viên TURN (relay). Thuật toán ICE sau đó kết hợp các ứng viên này, thực hiện kiểm tra kết nối và chọn đường dẫn tối ưu. Các nhà phát triển không cần phải biết thêm bất kỳ quy trình nào khác.

điểm: Như đã mô tả ở trênChuẩn bị nhiều phương án.Điều đó rất quan trọng. Ví dụ:choáng váng:Nếu bạn chỉ định TURN, trong môi trường chặn UDP, sẽ không tìm thấy ứng viên nào và kết nối sẽ thất bại. Tương tự, việc chỉ định TURN (UDP) cũng sẽ thất bại trong môi trường chỉ cho phép TCP. Do đó, nếu có thể,xoay:とlượt:Việc bao gồm cả hai trên máy chủ ICE cung cấp tính dự phòng, đảm bảo ít nhất một ứng viên hợp lệ được tìm thấy trong bất kỳ môi trường nào (tất nhiên, máy chủ TURN cũng phải hỗ trợ cả UDP và TCP/TLS). Máy khách (trình duyệt) sẽ tự động chọn một đường dẫn khả dụng, vì vậy thứ tự của danh sách không phải là vấn đề chính. Nếu có gì khác biệt,Chính sách vận chuyển băngをrơleTrừ khi có quy định khác, trình duyệt ưu tiên các kết nối trực tiếp, vì vậy việc thêm mục STUN sẽ ngăn chặn việc sử dụng máy chủ TURN một cách không cần thiết. Ngoài ra, việc bao gồm các máy chủ không liên quan (chẳng hạn như các địa chỉ không tồn tại) trong danh sách máy chủ ICE có thể gây ra sự chậm trễ do hết thời gian chờ, vì vậy tốt nhất chỉ nên bao gồm những máy chủ chắc chắn hoạt động.

Cuối cùng, hãy chạy ứng dụng WebRTC với các thiết lập này và kiểm tra trạng thái kết nối. Sử dụng công cụ dành cho nhà phát triển của trình duyệt...peerConnection.getStats()Sử dụng, hoặcchrome://webrtc-internals(Trong Chrome) Bạn có thể kiểm tra ICE Candidate và trạng thái kết nối. Nếu hoạt động như mong đợi, nó sẽ tự động chuyển sang kết nối trực tiếp (P2P) trong môi trường có UDP và sang kết nối TURN/TLS trong môi trường không có UDP.

Sự khác biệt giữa SFU và TURN

Việc chuyển tiếp WebRTC được chia rộng rãi thành "TURN" và "SFU", nhưng vai trò, cấu hình và cách sử dụng của chúng khác nhau đáng kể. Phần này tóm tắt những khác biệt kỹ thuật giữa chúng.

TURN: Một máy chuyển tiếp như một giải pháp thay thế cho kết nối ngang hàng (peer-to-peer)

TURN (Traversal Using Relays around NAT) là một máy chủ chuyển tiếp phụ trợ được sử dụng trong môi trường không thể thực hiện giao tiếp WebRTC P2P. Về cơ bản, khi STUN không hoạt động do NAT hoặc tường lửa, máy chủ TURN sẽ chặn các gói dữ liệu giữa các thiết bị ngang hàng và chuyển tiếp chúng. Vì mỗi thiết bị ngang hàng gửi luồng dữ liệu riêng lẻ đến đối tác giao tiếp tương ứng, cấu hình vẫn là dạng mạng lưới (mesh), và TURN hoạt động như một "bộ phận thay thế".

bố cụcMỗi người dùng truyền dữ liệu cho nhau thông qua một trạm chuyển tiếp (về cơ bản là một mạng lưới dạng lưới).
Khả năng mở rộngMức tải thấp (tải trọng tăng khi số người tăng)
Nội dung chương trình phát sóngChỉ thực hiện chuyển tiếp gói dữ liệu đơn giản; không thực hiện phân tích hoặc tối ưu hóa phương tiện truyền thông.

SFU: Chuyển tiếp hiệu quả cho các cuộc gọi nhiều người tham gia

Bộ chuyển tiếp chọn lọc (SFU) là một máy chủ chuyển tiếp thông minh được sử dụng trong các cuộc hội nghị trực tuyến nhiều người tham gia.Mỗi máy khách gửi một luồng dữ liệu đến SFU, sau đó SFU sẽ chọn lọc và chuyển tiếp luồng dữ liệu đó đến các bên tham gia khác.Nó cũng có thể thực hiện các quy trình như phát hiện người nói, điều chỉnh chất lượng hình ảnh và tối ưu hóa độ trễ, cho phép phát sóng hiệu suất cao và có khả năng mở rộng.

bố cụcCấu hình hình sao, trong đó mỗi máy khách kết nối với SFU bằng một kết nối duy nhất.
Khả năng mở rộngMức độ ưu tiên cao (Chỉ gửi một tin nhắn ngay cả khi số lượng người tham gia tăng lên)
Nội dung chương trình phát sóngĐiều này cho phép kiểm soát điểm đến của quá trình chuyển dữ liệu và tối ưu hóa phương tiện truyền thông.

Bảng so sánh giữa TURN và SFU

Đặc trưng	XOAY	SFU
Mục đích	Các phương pháp thay thế khi không thể thực hiện NAT traversal.	Giao tiếp thời gian thực với nhiều người
Cấu hình truyền thông	Mesh (gửi riêng cho từng người nhận)	Cấu hình hình sao (truyền đơn)
Chức năng rơle	Một rơle đơn giản (trong suốt)	Có thể lựa chọn chuyển giao và tối ưu hóa.
Khả năng mở rộng	thấp	đắt
Kiểm soát phương tiện	không có	Có (ví dụ: phát hiện người nói, điều chỉnh độ phân giải)

TURN chỉ đơn thuần là "giải pháp cuối cùng được sử dụng khi không thể thực hiện giao tiếp P2P", và về cấu hình, nó là một máy chủ chuyển tiếp bổ sung cho mạng lưới P2P. Mặt khác,SFU là một kiến trúc chuyển tiếp được thiết kế ngay từ đầu để hoạt động hiệu quả cho các cuộc gọi nhiều người tham gia.Vì vai trò của chúng về cơ bản là khác nhau, điều quan trọng là phải thiết kế chúng sao cho không gây nhầm lẫn.

bản tóm tắt

Bài viết này cung cấp giải thích chi tiết về sự khác biệt kỹ thuật và cách sử dụng STUN, TURN và TURNS dành cho người dùng WebRTC từ trung cấp đến nâng cao, cũng như cách xây dựng máy chủ sử dụng coturn, kèm theo các ví dụ mã và cách ICE hoạt động trong môi trường mạng phức tạp.

STUNNó có dung lượng nhỏ nhưng vẫn cho phép giao tiếp trực tiếp trong môi trường NAT.XOAYNó trở thành một phương tiện thiết yếu để thiết lập liên lạc ngay cả trong những tình huống khó khăn.QUAYBằng cách kết hợp các yếu tố này, việc sử dụng WebRTC trở nên khả thi ngay cả trong các môi trường chuyên biệt như trong nội bộ công ty.

Mỗi phương pháp đều có ưu điểm và nhược điểm riêng, vì vậy lý tưởng nhất là bạn nên kết nối trực tiếp bằng STUN bất cứ khi nào có thể và chỉ sử dụng chuyển tiếp TURN khi thực sự cần thiết. Trong quá trình phát triển ứng dụng WebRTC thực tế, bằng cách cung cấp nhiều đường dẫn như mô tả ở đây trong cài đặt máy chủ ICE, và bằng cách cấu hình và vận hành coturn đúng cách ở phía máy chủ, bạn có thể cung cấp khả năng liên lạc thời gian thực ổn định trong nhiều môi trường mạng khác nhau.

WebRTC là một lĩnh vực phức tạp, kết hợp các API của trình duyệt và công nghệ mạng, nhưng việc hiểu rõ cơ chế STUN/TURN và ICE là điều cần thiết để tạo ra các ứng dụng đáng tin cậy.

Tôi khuyến khích bạn sử dụng thông tin trong bài viết này để giải quyết thách thức vượt NAT trong sản phẩm của mình. Điều này sẽ cho phép người dùng tận hưởng khả năng giao tiếp liền mạch mà không hề nhận ra, nhờ vào quá trình xử lý kết nối được thiết kế thông minh diễn ra ngầm phía sau.

URLをコピーしました!