Giải thích và thực hành kỹ lưỡng về 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 thoại, video và dữ liệu thời gian thực giữa các trình duyệt. Nó đang được nhiều công ty chuẩn hóa, bao gồm cả Google, như một cơ chế cho phép giao tiếp P2P chỉ sử dụng JavaScript API mà không cần thêm plug-in hoặc phần mềm.

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

lấyUserMedia: Một API để thu thập âm thanh và video từ các thiết bị như máy ảnh và micrô.
Kết nối RTCPeer: Một API cốt lõi để thiết lập giao tiếp giữa các đối tác và trao đổi phương tiện và dữ liệu.
Kênh dữ liệu RTC: Kênh dữ liệu có thể được sử dụng để gửi tệp, trò chuyện, v.v.

Các API này cho phép phát triển nhiều ứng dụng thời gian thực như cuộc gọi video, hội nghị âm thanh, chia sẻ tệp, v.v. Tuy nhiên, trong truyền thông thực tế, có những vấn đề với NAT traversal và tường lửa, do đó, điều cần thiết là phải hiểu và triển khai các công nghệ NAT traversal như STUN/TURN/TURNS.

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ế chuyển đổi NAT là điều cần thiết. Bài viết này sẽ giải thích chi tiết về sự khác biệt về mặt kỹ thuật, các tình huống sử dụng và ưu điểm cũng như nhược điểm của các công nghệ tiêu biểu STUN, TURN và TURNS.

STUN là giao thức được sử dụng chủ yếu để tìm địa chỉ bên ngoài của một người trong môi trường NAT, trong khi TURN là giao thức hoạt động như một máy chủ chuyển tiếp khi không thể 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 số cổng 443 như HTTPS, giúp có thể giao tiếp sau tường lửa nghiêm ngặt như mạng công ty.

Bằng cách hiểu được đặc điểm của từng loại và sử dụng chúng một cách hợp lý, bạn có thể tăng tỷ lệ thành công và chất lượng của truyền thông WebRTC.

Vai trò và tính năng của STUN (UDP)

STUN (Tiện ích truyền tải phiên cho NAT) là một giao thức cho phép khách hàngĐịa chỉ IP và cổng bên ngoàiĐây là một giao thức đơn giản để biết địa chỉ IP của PC. Ví dụ, nếu PC nằm sau NAT, nó không biết địa chỉ IP toàn cục của riêng mình, nhưng nó có thể lấy được "địa chỉ IP của riêng mình: cổng khi 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 như hiện tại. Do đó, máy khách có thể biết địa chỉ IP toàn cầu của riêng mình và số cổng được NAT (Ứng viên phản xạ máy chủ) chỉ định.

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

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

Nó có hiệu quả trong các môi trường cần phải chuyển 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à đường dây di động. Nếu STUN có thể lấy được IP:port bên ngoài của nhau, các máy khách có thể thiết lập giao tiếp trực tiếp (ngang hàng) với nhau. Vì đường truyền giao tiếp là trực tiếp nên ít bị trễ hơn 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 nên chi phí đượ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 ở trong NAT tương đối mở, STUN đủ để cho phép kết nối ngang hàng.

Hạn chế và nhược điểm của STUN

STUN chỉ là một phương tiện để "tìm địa chỉ bên ngoài của riêng bạn", và tùy thuộc vào loại NAT và các hạn chế của tường lửa, có thể không thể kết nối chỉ bằng cách này. Đặ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ừ bên kia có thể không đến được địa chỉ mà STUN thu được, khiến việc giao tiếp trở nên bất khả thi.

Ngoài ra, bản thân giao tiếp UDP có thể bị chặn trên mạng công ty, trong trường hợp đó các yêu cầu STUN không đến được thiết bị. 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à không hoạt động trong các môi trường mà giao tiếp trực tiếp là không thể về mặt vật lý. Vì lý do này, STUN được sử dụng trong ICE (được mô tả bên dưới) để có được các ứng viên cho giai đoạn đầu tiên và được thiết kế để quay lại TURN (được mô tả bên dưới) nếu STUN không đủ.

Vai trò và tính năng của TURN (UDP)

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

TURN cũng thường giao tiếp bằng UDP, vì vậy miễn là UDP được sử dụng, nó có thể chuyển tiếp các gói phương tiện theo cách tương tự như giao tiếp trực tiếp. Theo mặc định, giao thức TURN được chấp nhận 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 cũng có thể chạy trên một cổng được phép như UDP/443. Miễn là UDP được sử dụng, việc chuyển tiếp với hiệu suất thời gian thực cao hơn TCP là có thể.

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

TURN là cần thiết khi không thể thiết lập kết nối trực tiếp. Ví dụ,Đây là trường hợp khi một hoặc cả hai bên đều nằm sau tường lửa doanh nghiệp nghiêm ngặt hoặc khi cả hai bên đều có NAT đối xứng và việc đục lỗ UDP không thành công.Trong môi trường như vậy, không thể giao tiếp nếu không chuyển tiếp qua máy chủ TURN, do đó TURN hoạt động như một giải pháp cuối cùng.

WebRTC hướng đến mục tiêu tất cả các đối tác có thể giao tiếp trực tiếp, nhưng ngay cả khi điều này không thể thực hiện được, bản thân giao tiếp vẫn có thể tiếp tục bằng cách quay lại TURN. Trong hoạt động thực tế, chiến lược chung là trước tiên hãy thử kết nối trực tiếp với STUN và chỉ chuyển sang chuyển tiếp TURN nếu không thành công. Ví dụ, trong hội nghị truyền hình qua mạng nội bộ, nếu hai bên không thể giao tiếp trực tiếp với nhau, giao tiếp sẽ tự động chuyển sang giao tiếp qua máy chủ TURN, cho phép người dùng tiếp tục cuộc trò chuyện mà thậm chí không nhận ra.

Lợi ích của TURN

Ưu điểm lớn nhất là độ tin cậy. Bất kể bạn đang ở trong môi trường NAT hay tường lửa nào, miễn là có thể thiết lập được giao tiếp 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 STUN về mặt giao thức, nên một triển khai máy chủ duy nhất (như coturn, được mô tả bên dưới) có thể xử lý cả yêu cầu STUN và TURN. Sau khi kết nối được thiết lập, phương tiện tiếp theo được chuyển tiếp dưới dạng luồng, do đó, theo quan điểm của người dùng, giao tiếp diễn ra liền mạch, ngoại trừ một số độ trễ.

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

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

Ngoài ra, đường truyền càng dài thì độ trễ càng lớn, dẫn đến độ trễ thời gian và chất lượng video và âm thanh giảm. Hơn nữa, so với giao tiếp ngang hàng sử dụng STUN, giao tiếp qua TURN không hoàn toàn ngang hàng, do đó tính bảo mật kém hơn một chút (mặc dù máy chủ TURN thường chỉ chuyển tiếp RTP/datagram không được mã hóa và không giải thích nội dung).

Nhìn chung, TURN chỉ nên được sử dụng khi cần thiết. Trên thực tế, hầu hết các 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 tổng cộng có khoảng 861 cuộc gọi TP3T được thiết lập mà không cần chuyển tiếp (ngang hàng). Chỉ có 141 TP3T còn lại yêu cầu TURN, nhưng điều quan trọng là phải có cơ sở hạ tầng TURN cho 141 TP3T đó.

Vai trò và tính năng của TURNS (TLS qua TCP/443)

TURNS là viết tắt của "TURN over TLS" và là giao thức mã hóa truyền thông chuyển tiếp bằng giao thức TURN với TLS (Bảo mật lớp truyền tải).Giao tiếp TURN được bảo mật bằng TLS (HTTPS)và thường phục vụ trên cổng TCP 443.Cổng 443 có cùng số cổng với HTTPS, do đó, nó có thể dễ dàng vượt qua tường lửa của công ty và dễ dàng tránh được proxy và kiểm duyệt..

Ví dụ, mạng nội bộ của công ty chỉ có thể cho phép truyền thông bên ngoài qua cổng 80 và 443, nhưng ngay cả trong trường hợp đó, vẫn có khả năng cao là truyền thông có thể thực hiện được nếu máy chủ TURN sử dụng truyền thông TLS trên cổng 443. Ngoài ra, vì truyền thông được mã hóa bằng TLS nên chúng an toàn và bên thứ ba khó có thể chặn được.

Trong WebRTC, các thiết lập"url": "lượt quay:máy chủ lượt quay:443"Trong lược đồ URI:lượt:Bạn có thể sử dụng máy chủ TURN được mã hóa TLS này bằng cách chỉ định

Các cảnh sử dụng TURNS

TURNS hữu ích cho giao tiếp WebRTC trong các môi trường bị hạn chế chặt chẽ như mạng công ty, nơi mọi phương tiện khác đều bị chặn. Ngay cả trong các môi trường mà tất cả các cổng UDP và TCP chung đều bị chặn, vẫn có nhiều chính sách cho phép giao tiếp theo cùng cách như giao tiếp HTTPS, do đó, TURN trên cổng TLS 443 thực sự là giải pháp cuối cùng.

Nó cũng được sử dụng trong trường hợp một số cổng nhất định bị đóng trên mạng LAN không dây công cộng hoặc khi chỉ có thể giao tiếp TLS ở phía máy khách.Đầu tiên là UDP, nếu không được thì là TCP, nếu không được thì là TLS tới 443"Nó được định vị là giai đoạn cuối cùng của quá trình suy thoái dần dần.

Lợi ích của TURNS

Ưu điểm lớn nhất của nó là khả năng chống tường lửa cao. Giao tiếp được mã hóa TLS khó phân biệt với HTTPS thông thường, do đó có nhiều khả năng vượt qua các bộ lọc nghiêm ngặt. Đặc biệt, khi giới thiệu hệ thống hội nghị truyền hình web cho một công ty, cần phải cho phép các kết nối bên ngoài từ mạng nội bộ, nhưng giao tiếp TLS qua TCP/443 có nhiều khả năng được chấp nhận theo các chính sách bảo mật. Ngoài ra, vì được mã hóa, nên tính bảo mật của giao tiếp với chính máy chủ chuyển tiếp có thể được đảm bảo (*Tuy nhiên, bản thâ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 TURNS

Nhược điểm lớn nhất là hình phạt về hiệu suất. Ngoài độ trễ và tải của bản thân TURN, còn có chi phí chung của TLS và TCP. TCP là một phương tiện truyền tải đáng tin cậy và có cơ chế truyền lại trong trường hợp mất gói tin, 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 mất gói tin, video và âm thanh có thể không được phát một cách mượt mà.

Ngoài ra, TCP dễ bị chặn đầu dòng do thứ tự gói tin,Độ dao động (jitter) cũng tăng so với UDP.Ngoài ra, quá trình mã hóa và giải mã TLS tạo thêm gánh nặng cho CPU. Do đó, có báo cáo rằng độ trễ bổ sung là 50 ms trở lên xảy ra, gây ra độ trễ mà người dùng có thể cảm nhận được. Đặc biệt, trong các hội nghị truyền hình, độ trễ tăng lên này có thể làm chậm nhịp độ cuộc trò chuyện và gây ra sự khác biệt đáng chú ý về thời gian.

Theo cách này, TURNS có thể được coi là phương pháp "cuối cùng" xét về mặt chất lượng, nhưng cũng là giải pháp 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 thiết lập liên lạc.

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

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

Chúng tôi sẽ giải thích từng bước về cách xử lý WebRTC ICE diễn ra khi STUN qua UDP không khả dụng. Hãy giả sử một tình huống UDP bị chặn hoàn toàn, chẳng hạn như trên mạng công ty, và theo dõi cách đàm phán ICE trở lại.

Máy khách gửi truy vấn IP bên ngoài (UDP/3478) đến máy chủ STUN:
Máy khách WebRTC (trình duyệt)Máy chủ băngYêu cầu liên kết (yêu cầu xác minh địa chỉ bên ngoài) được gửi đến máy chủ STUN được chỉ định qua cổng UDP 3478. Đây là bước đầu tiên trong việc thu thập các ứ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 riêng nó và được thêm vào danh sách ứng viên dưới dạng Ứng viên phản xạ máy chủ (ứng viên srflx).
Các gói 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, các thiết lập tường lửa mạng ngăn chặn giao tiếp UDP ra bên ngoài. Do đó, các yêu cầu đến máy chủ STUN không đến được máy chủ hoặc phản hồi không đến được máy khách. Kết quả là, máy kháchKhông nhận được phản hồi STUN, địa chỉ IP bên ngoài không thể biết được. Tác nhân ICE 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ờ. Theo quan điểm của người dùng, kết nối vẫn đang được xử lý và không có thông báo lỗi nào được hiển thị, nhưng trên thực tếKhông thu thập được ứng viênSự việc này hiện đang xảy ra.
Kiểm tra kết nối trực tiếp ICE không thành công vì không có ứng viên Server Reflexive nào khả dụng:
Thông thường, nếu STUN thành công, máy khách có một ứng viên Server Reflexive (IP toàn cầu của bạn) ngoài ứng viên Host (IP cục bộ của bạn) và kiểm tra kết nối bằng cách kết hợp nó với ứng viên tương tự của đối tác đầu xa. Tuy nhiên, nếu không có ứng viên IP toàn cầu do lỗi STUN,Các ứng cử viên cho các kết nối ngang hàng trực tiếp là cực kỳ hạn chếVí dụ, nếu cả hai bên chỉ có địa chỉ IP riêng, họ sẽ không thể liên lạc với nhau ngay cả khi họ cố gắng kết nối. Do đó, ICE sẽ xác định rằng không thể giao tiếp trực tiếp. Nếu máy chủ ICE (TURN) không được cấu hình, toàn bộ ICE sẽ được coi là lỗ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ạihoặcTrạng thái kết nối ICE: không thành côngv.v. sẽ được hiển thị).
Cố gắng lấy ứng viên chuyển tiếp TURN (qua TCP/TLS/443):
Ngay cả khi việc tuyển dụng ứng viên trực tiếp của STUN không thành công,Máy chủ băngNếu máy chủ TURN được chỉ định trongCác bước tiếp theoTrong ví dụ này, vì UDP không khả dụng nên 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: lượt.example.com:443(Nếu được cấu hì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 TURN qua TLS thành công. Máy khách bảo mật địa chỉ chuyển tiếp trên máy chủ TURN,Ứng viên tiếp sứcPhía bên kia sẽ có được các ứng viên chuyển tiếp, là "ứng viên ảo để giao tiếp qua máy chủ TURN". Trong khi đó, phía bên kia (phía từ xa) cũng sẽ có được các ứng viên chuyển tiếp hoặc nếu đó là mạng không có vấn đề, nó sẽ có các ứng viên trực tiếp hoặc ứng viên STUN. Trong mọi trường hợp, nếu ít nhất một bên có các ứng viên chuyển tiếp, phía 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 rơle:
Khi cả hai đối tác đều có ứng viên khả dụng (một hoặc cả hai ứng viên chuyển tiếp trong ví dụ này), ICE sử dụng chúng để kiểm tra kết nối. Khi giao tiếp qua máy chủ TURN được thiết lập với máy chủ, nó có thể được chuyển tiếp, do đó kênh phương tiện được mở ngay cả khi UDP không truyền trực tiếp giữa các đối tác. Điều này cho phép giao tiếp video và âm thanh giữa những người dùng bắt đầu. Sau khi kết nối được thiết lập, có một số chi phí chung dưới dạng TCP qua TLS, nhưng bản thân cuộc trò chuyện vẫn có thể thực hiện được. Ngược lại, nếu cũng có lỗi ở đây (ví dụ: proxy của công ty phát hiện và chặn giao tiếp TLS không phải HTTP hoặc xác thực máy chủ TURN không thành công), thật không may, ICE sẽ không thành công và kết nối sẽ bị hủy bỏ. Ứng dụng cần phát hiện tình huống này và thông báo cho người dùng rằng "không thể kết nối", v.v.

Đây là luồng đàm phán ICE trong môi trường khắc nghiệt mà UDP không thể sử dụng được. Tóm lại, các ứng viên được thử theo thứ tự "Host → STUN → TURN", và nếu không được, kết nối sẽ không thành công. Điều quan trọng là các nhà phát triển phải hiểu được hành vi này và ít nhất phải bao gồm một máy chủ TURN/TURNS trong danh sách máy chủ ICE, để ngay cả trong trường hợp xấu nhất vẫn có khả năng thiết lập được giao tiếp. Ngoài ra, 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 ra sự cố với môi trường mạng (chẳng hạn như chặn UDP) từ thông tin như "ICE không thành công" và kiểm tra xem có thiếu cài đặt máy chủ TURN không.

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

Nếu bạn muốn thiết lập máy chủ STUN/TURN của riêng mình, hãy sử dụng phiên bản mã nguồn mở. coturnNgười ta thường sử dụng coturn. coturn là một triển khai 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ài đặt. Bài viết này giải thích cách cài đặt coturn trên máy chủ Linux và xây dựng máy chủ cung cấp STUN/TURN/TURNS, cũng như các điểm cấu hình. Bài viết cũng giải thích tệp cấu hình thông thường (turnserver.conf) cũng được hiển thị.

Cài đặt và cấu hình cơ bản

cài đặt

Đối với Ubuntu và Debian,thích hợpBạn có thể cài đặt gói coturn từ. Ví dụ, sử dụng lệnh sau để cài đặt và thiết lập để tự động khởi động.

# 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

Điều này sẽ khởi động máy chủ coturn như một daemon. Theo mặc định, nó sẽ chạy tệp cấu hình /etc/turnserver.conf Thao tác này sẽ tải tệp và sau đó bạn có thể chỉnh sửa tệp đó (hãy sao lưu trước khi chỉnh sửa để đảm bảo an toàn).

Cài đặt cơ bản

turnserver.confBây giờ, 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 tên nhận dạng của máy chủ TURN. Nó có thể được sử dụng khi xác thực máy khách WebRTC, nhưng về cơ bản nó có thể là bất kỳ chuỗi nào. Ví dụ: miền=example.com,tên máy chủ=example.com.
cổng lắng nghe: Số cổng UDP để lắng nghe TURN và STUN. Mặc định là 3478.lắng nghe-ipBạn cũng có thể liên kết với một NIC cụ thể với0.0.0.0Chúng tôi chấp nhận tất cả.
cổng lắng nghe tls: Đây là số cổng TCP để lắng nghe TLS (TURNS). Nói chung, 443 hoặc 5349 được chỉ định. Ví dụ: cổng nghe tls=443.
ip ngoài: Nếu máy chủ nằm sau NAT, hãy chỉ định IP toàn cục của riêng nó (điều này cho phép máy chủ nhận ra ánh xạ giữa IP nội bộ và IP bên ngoài). Điều này không cần thiết nếu máy chủ có IP toàn cục trực tiếp.
Phương pháp xác thực: WebRTC sử dụng thông tin xác thực dài hạn cho TURN, vì vậylt-cred-mech(Cơ chế chứng nhận dài hạn) đã được bật.người dùng=tên người dùng:mật khẩuhoặc đặt tên người dùng và mật khẩu theo định dạngsử dụng-xác-thực-bí-mật(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 tôi sẽ trình bày phương pháp 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 tin nhật kýChỉ định đường dẫn tệp nhật ký trongdài dòngBạn có thể muốn bật tính năng ghi nhật ký chi tiết.

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

Ở phía máy chủ, để STUN/TURNCổng UDP 3478và cho TURN/TLSCổng TCP 443(hoặc 5349) phải được mở. Ngoài ra, TURN relay sử dụng phạm vi cổng UDP 10000-20000 theo mặc định, do đó hãy mở phạm vi cổng này trên máy chủ (nếu cần,cổng nhỏ nhấtVàcổng tối đa(Phạm vi có thể được thay đổi với

Dưới đây là một ví dụ phản ánh các thiết lập cơ bản ở trên./etc/turnserver.confSau đâ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     # 秘密鍵

Ở trên, miềnví dụ.comChúng tôi lấy chứng chỉ Let's Encrypt và sử dụng nó cho cài đặt TLS.lt-cred-mechCho phép xác thực dài hạn vớingười sử dụngĐiều này thiết lập xác thực tên người dùng/mật khẩu đơn giản.sử dụng-xác-thực-bí-mậtVàbí mật xác thực tĩnhPhương pháp được khuyến nghị là sử dụng phương pháp dựa trên mã thông báo để cấp thông tin xác thực tạm thời, nhưng chúng tôi sẽ không đi sâu vào vấn đề này ở đây.

Thận trọng 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 của 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ở được nếu không có quyền root. Gói coturn của Ubuntu mặc định làmáy chủ turnserverVì lệnh này được thực thi bởi người dùng nên nó không thể liên kết với cổng 443 theo mặc định./etc/mặc định/coturnThay đổi người dùng đang chạy thành root hoặcnắp đậyVới lệnhmáy chủ turnservervào tập tin thực thidịch vụ liên kết cap_netCó một cách để cấp quyền. Ví dụ, trong trường hợp sau,sudo setcap cap_net_bind_service=+ep /usr/bin/turnserverBằng cách thực hiện lệnh này, ngay cả người dùng không phải root cũng có thể liên kết các cổng có số thấp. Ngoài ra, hãy chỉ định đường dẫn chính xác đến tệp chứng chỉ (cert/pkey) và đặt quyền cho tệp để người dùng coturn có thể đọc được. Sau khi thay đổi cài đặt,sudo systemctl khởi động lại 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 khởi động máy chủ coturn, chúng tôi sẽ thử nghiệm nó bằng cách sử dụng máy khách STUN để kiểm tra hoạt động của nó và cũng thử kết nối với ICE từ ứng dụng WebRTC trên trình duyệt.khách hàngyêu cầu(apt-get cài đặt stun-client(Có sẵn để cài đặt tạistunclient <máy chủ IP> 3478Bạn có thể thử lấy IP bên ngoài của mình bằng cách chạy lệnh sau. Ngoài ra, trong trình duyệt của bạn, 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, vì vậysrflx(Máy chủ phản xạ) ứng viên vàtiếp sứcKiểm tra xem bạn có nhận được ứng viên không. Nếu không, hãy thử các điểm sau để khắc phục sự cố:

Các cổng cần thiết có đượ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) không?
URI, cổng và thông tin xác thực có được thiết lập chính xác trong cài đặt máy chủ ICE phía máy khách (được mô tả bên dưới) không?
turnserver.confcủavương quốcĐảm bảo các thiết lập khớp với xác thực máy khách. (Thông thường, đây không phải là vấn đề trong phiên bản trình duyệt của WebRTC, vì miền được tự động chỉ định, nhưng hãy cẩn thận nếu bạn có triển khai tùy chỉnh.)
nhật ký coturn (/var/log/turnserver.log) và kiểm tra xem có lỗi xác thực không (NGƯỜI DÙNG SAINếu có lỗi như trên thì tên người dùng/mật khẩu không khớp.

Với các thiết lập trên, bạn sẽ có máy chủ STUN/TURN/TURNS của riêng mình và có thể hỗ trợ kết nối WebRTC trong nhiều môi trường mạng khác nhau.

Ví dụ về cài đặt máy chủ ICE cho máy khách WebRTC (JavaScript)

Để thực sự sử dụng máy chủ STUN/TURN mà chúng tôi vừa xây dựng trên ứng dụng WebRTC (trình duyệt),Cài đặt máy chủ ICETrong API WebRTC của JavaScript,Kết nối RTCPeerBạn có thể chỉ định danh sách các máy chủ STUN/TURN khi tạo . Tiếp theo, chúng tôi sẽ trình bày một ví dụ mã cụ thể chỉ định tất cả các máy chủ STUN/TURN/TURNS và giải thích ý nghĩa của nó.

Đầu tiên, tạo đối tượng cấu hình cho máy chủ ICE. Nhập tên miền của máy chủ của bạn.lượt.example.com(Thay thế khi thích hợp). STUN không yêu cầu xác thực, do đó chỉ cần chỉ định URI. 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);

Trên đâyMáy chủ băngMảng này có ba mục.

LÀM CHOẬN: choáng:turn.example.com:3478
Chỉ định địa chỉ máy chủ STUN của riêng bạn (nếu cổng bị bỏ qua, 3478 được sử dụng). STUN được sử dụng để xác định NAT traversal và lấy các ứng viên. Trình duyệt đầu tiên truy vấn máy chủ này qua UDP để lấy các ứng viên Server Reflexive.
LƯỢT (UDP): lượt: lượt.example.com: 443? vận chuyển = udp
Máy chủ TURN của riêng bạnCổng UDP 443Đây là thiết lập được sử dụng. Tên người dùng đã được thiết lập trong coturn trước đó làm thông tin xác thựcngười dùng webrtcuservà mật khẩumật khẩu123Tham số truy vấn đã được chỉ định.?vận chuyển=udp(Nếu không được chỉ định, trình duyệt sẽ thử UDP trước, và nếu không thành công, sẽ thử TCP.) Với thiết lập này, ngay cả khi kết nối trực tiếp sử dụng STUN thông thường không thành công, bạn vẫn có thể nhận được ứng viên cho chuyển tiếp TURN trên cổng UDP 443.
QUAY (TLS/TCP): lượt: lượt.example.com:443
TURN với TLSĐây là thiết lập cho máy chủ TURNS. Tên người dùng và mật khẩu cũng được chỉ định ở đây. Trình duyệt sẽ tạo kết nối TLS đến mục này trên cổng TCP 443 để lấy ứng viên chuyển tiếp TURN. Đây là ứng viên chuyển tiếp cuối cùng và có khả năng thiết lập giao tiếp ngay cả khi giao tiếp qua UDP không thể thực hiện được.

Kết nối RTCPeerKhi tác nhân ICE tạo máy chủ ICE, nó sẽ cố gắng kết nối với các máy chủ ICE được chỉ định theo thứ tự và thu thập các ứng viên. Đầu tiên, tác nhân ICE sẽ lấy các ứng viên STUN (srflx), sau đó lấy các ứng viên TURN (relay) song song. Sau đó, thuật toán ICE sẽ 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 tuyến đường tối ưu. Các nhà phát triển không cần phải biết bất kỳ quy trình nào khác.

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

Cuối cùng, hãy chạy ứng dụng WebRTC với thiết lập này và xác minh trạng thái kết nối.peerConnection.getStats()hoặcchrome://webrtc-internalsBạn có thể kiểm tra ICE Candidate và trạng thái kết nối bằng (Chrome). 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à kết nối qua TURN/TLS trong môi trường khó thực hiện.

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

Chuyển tiếp WebRTC có thể được chia 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ể. Sau đây chúng tôi tóm tắt những khác biệt về mặt kỹ thuật.

TURN: Relay như một giải pháp thay thế cho 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 các môi trường mà giao tiếp P2P WebRTC không thể thực hiện được. Máy chủ TURN hoạt động giữa các đối tác ngang hàng và chuyển tiếp các gói tin khi STUN không hoạt động do NAT hoặc tường lửa. Vì mỗi đối tác ngang hàng gửi một luồng đến từng đối tác giao tiếp riêng lẻ, nên cấu hình là dạng lưới và TURN được định vị là "pinch hitter".

thành phần: Mỗi người dùng truyền đến mọi người dùng khác thông qua một rơle (thực tế là một mạng lưới)
Khả năng mở rộng: Thấp (càng nhiều người thì tải càng cao)
Nội dung phát sóng: Chỉ truyền gói tin đơn giản, không phân tích phương tiện hoặc tối ưu hóa

SFU: Chuyển tiếp hiệu quả cho các cuộc gọi nhiều bên

SFU (Đơn vị chuyển tiếp chọn lọc) là máy chủ chuyển tiếp thông minh được sử dụng trong các hội nghị web có 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ẽ chuyển tiếp luồng dữ liệu đó đến những người tham gia khác một cách có chọn lọc.Nó cũng 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 có khả năng mở rộng và hiệu suất cao.

thành phần: Kiểu sao trong đó mỗi máy khách được kết nối với một SFU
Khả năng mở rộng: Đắt tiền (chỉ có một lần truyền ngay cả khi số lượng người tăng lên)
Nội dung phát sóng: Có thể kiểm soát đích truyền tải và tối ưu hóa phương tiện

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

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

TURN chỉ là giải pháp cuối cùng khi giao tiếp P2P không khả thi và là phương án bổ sung cho mạng lưới P2P.SFU là một kiến trúc chuyển tiếp được thiết kế để có hiệu quả ngay từ đầu cho các cuộc gọi nhiều bên.Vì hai khái niệm này có vai trò khác nhau về cơ bản nên điều quan trọng là không được nhầm lẫn chúng khi thiết kế.

bản tóm tắt

Bài viết này cung cấp lời giải thích chi tiết cho người dùng WebRTC ở trình độ trung cấp đến nâng cao về sự khác biệt kỹ thuật giữa STUN, TURN và TURNS, cũng như thời điểm sử dụng chúng, cách xây dựng máy chủ bằng coturn và một số ví dụ mã, cũng như cách ICE hoạt động trong môi trường mạng khắc nghiệt.

làm choáng vángNó nhẹ và cho phép giao tiếp trực tiếp trong môi trường NAT.XOAYcung cấp đường dây liên lạc trong những tình huống khó khăn; vàLượt quayBằng cách kết hợp những điều này, chúng ta có thể sử dụng WebRTC ngay cả trong những môi trường đặc biệt như trong một công ty.

Mỗi loại đều có ưu 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 với STUN bất cứ khi nào có thể và chỉ sử dụng TURN relay 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 chuẩn bị nhiều tuyến đường trong cài đặt máy chủ ICE như đã giới thiệu ở đây 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 giao tiếp 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 API trình duyệt và công nghệ mạng, nhưng việc hiểu cách STUN/TURN và ICE hoạt động là điều cần thiết để tạo ra các ứng dụng đáng tin cậy.

Chúng tôi hy vọng bạn sẽ sử dụng thông tin trong bài viết này để cố gắng vượt qua thách thức NAT traversal trong sản phẩm của riêng bạn. Bằng cách đó, người dùng của bạn sẽ có thể tận hưởng giao tiếp liền mạch nhờ xử lý kết nối được thiết kế khéo léo ở chế độ nền, thậm chí không nhận ra điều đó.

URLをコピーしました!