ICE候補と接続性
ICE候補がネットワークアドレスをどのように表すか、またICEがピアツーピア接続に最適な経路をどのように見つけるかを学びます。
「ICE候補と接続性」はCoddyKit上の無料Real-Time Streaming Systems (WebRTC + Live Data)レッスンです。 これはレッスン3/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応の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候補と接続性」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応の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)を演習し、24時間対応の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フィードバックを取得できます。ローカル設定は不要です。