Real-Time Streaming Systems (WebRTC + Live Data) · 课时

ICE 候选项与连接性

探索 ICE 候选项、它们如何表示网络地址，以及 ICE 如何帮助查找点对点连接的最佳路径。

ICE 候选项与连接性 是 CoddyKit 上的免费 Real-Time Streaming Systems (WebRTC + Live Data) 课时。这是第 3 节课，共 4 节。你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。这是 Real-Time Streaming Systems (WebRTC + Live Data) 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 Real-Time Streaming Systems (WebRTC + Live Data) 课程共包含 4 节课。

本课时的部分内容尚未翻译，以英文显示。

ICE: The Connectivity Finder

ICE stands for Interactive Connectivity Establishment. It's a crucial framework in WebRTC that helps establish direct connections between peers, even when they are behind tricky networks like NATs or firewalls.

Think of ICE as a smart detective. It finds all possible routes for two people to talk directly and then picks the best one.

Overcoming Network Barriers

Many devices connect to the internet through routers that use NAT (Network Address Translation) or have firewalls. These act like security guards, often blocking direct incoming connections.

NAT: Hides private network IPs behind a single public IP.
Firewalls: Block unauthorized access.

Without ICE, establishing a direct peer-to-peer connection in such environments would be nearly impossible.

What Are ICE Candidates?

An ICE Candidate is essentially a potential network address and port where a peer can be reached. Each peer collects multiple candidates representing different ways it can communicate.

These candidates are like different phone numbers or addresses you might have: your home number, your work number, a friend's number where you can be reached, etc. ICE tries them all.

Types of ICE Candidates

There are three main types of ICE candidates:

Host Candidates: These are the peer's actual local IP addresses. They work best for direct connections within the same local network.
Server Reflexive Candidates: Obtained from a STUN server. This is your public IP address and port as seen by an external server, helping peers behind NATs find each other.
Relayed Candidates: Obtained from a TURN server. If direct connection isn't possible, a TURN server relays all traffic. This is the last resort.

Gathering Candidates: The Process

When a WebRTC connection is initiated, each peer's browser (the WebRTC agent) starts collecting ICE candidates. It actively queries the local network, STUN servers, and potentially TURN servers to find all possible communication paths.

This collection process happens continuously in the background as the RTCPeerConnection is being set up.

Code: Listening for Candidates

In JavaScript, you listen for icecandidate events on your RTCPeerConnection object to get these candidates. Each event provides a new candidate to share with the remote peer via your signaling server.

const pc = new RTCPeerConnection();

pc.onicecandidate = (event) => {
  if (event.candidate) {
    console.log("New ICE candidate found:");
    console.log(event.candidate.candidate);
    // Send this candidate to the remote peer via signaling server
  } else {
    console.log("ICE candidate gathering complete.");
  }
};

console.log("Listening for ICE candidates...");
// Note: This snippet requires a full browser WebRTC context to run
// and produce actual candidates. It's for demonstration.

Exchanging Candidates: Signaling

Once candidates are gathered, they must be exchanged between the two peers. This happens through your signaling server, the same server used to exchange SDP offers and answers.

Each peer sends its collected candidates to the signaling server.
The signaling server forwards these candidates to the other peer.

This process is often called "trickle ICE" because candidates are sent as they are found, rather than waiting for all of them.

The Connectivity Check

After exchanging candidates, ICE begins its connectivity checks. Both peers try to establish connections using every possible pair of local and remote candidates. This involves sending small "STUN binding requests" to test reachability.

ICE then prioritizes and selects the most efficient and reliable path. It prefers direct host connections, then STUN-relayed public IPs, and finally TURN-relayed connections.

Quick Check: ICE Candidate Types

Which type of ICE candidate is obtained with the help of a STUN server to reveal a peer's public IP address?

Recap: ICE in Action

In this lesson, you learned about ICE Candidates and how they enable WebRTC to establish peer-to-peer connections across diverse networks.

ICE candidates are potential network addresses.
They come in types: Host, Server Reflexive (STUN), and Relayed (TURN).
Peers gather and exchange these candidates via a signaling server.
ICE then performs connectivity checks to find the best possible path for direct communication.

ICE is the unsung hero ensuring your real-time calls find a way through the internet's complexities!

常见问题解答

「ICE 候选项与连接性」课时是免费的吗？

是的 — 「ICE 候选项与连接性」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 Real-Time Streaming Systems (WebRTC + Live Data) 课程的其余内容，请升级到 CoddyKit PRO。 Real-Time Streaming Systems (WebRTC + Live Data) 课程共包含 4 节课。

「ICE 候选项与连接性」这节课中我会学到什么？

探索 ICE 候选项、它们如何表示网络地址，以及 ICE 如何帮助查找点对点连接的最佳路径。你通过在浏览器中直接运行的动手代码来练习 Real-Time Streaming Systems (WebRTC + Live Data)，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 Real-Time Streaming Systems (WebRTC + Live Data) 需要有经验吗？

无需任何先前经验。CoddyKit 上的 Real-Time Streaming Systems (WebRTC + Live Data) 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。这是第 3 节课，共 4 节。

「ICE 候选项与连接性」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 Real-Time Streaming Systems (WebRTC + Live Data) 课中编写并运行代码吗？

能。每节 Real-Time Streaming Systems (WebRTC + Live Data) 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

← 返回 Real-Time Streaming Systems (WebRTC + Live Data)