ICE-kandidater og tilkobling
Utforsk ICE-kandidater, hvordan de representerer nettverksadresser, og hvordan ICE bidrar til å finne den beste banen for en node-til-node-tilkobling.
ICE-kandidater og tilkobling er en gratis leksjon i Sanntidsstrømmesystemer (WebRTC + sanntidsdata) på CoddyKit. Dette er leksjon 3 av 4. Du kan lese hele leksjonen gratis nedenfor – og deretter øve praktisk i nettleseren med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Sanntidsstrømmesystemer (WebRTC + sanntidsdata), og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Sanntidsstrømmesystemer (WebRTC + sanntidsdata) inneholder totalt 4 leksjoner.
ICE: Tilkoblingsfinneren
ICE står for Interactive Connectivity Establishment. Det er et viktig rammeverk i WebRTC som hjelper med å opprette direkte tilkoblinger mellom noder, selv når de er bak utfordrende nettverk som NAT-er eller brannmurer.
Tenk på ICE som en smart detektiv. Den finner alle mulige ruter som to personer kan bruke til å snakke direkte, og velger deretter den beste.
Slik overvinnes nettverksbarrierer
Mange enheter kobler seg til internett gjennom rutere som bruker NAT (Network Address Translation), eller som har brannmurer. Disse fungerer som sikkerhetsvakter og blokkerer ofte direkte innkommende tilkoblinger.
- NAT: Skjuler private nettverks-IP-adresser bak én offentlig IP-adresse.
- Brannmurer: Blokkerer uautorisert tilgang.
Uten ICE ville det vært nesten umulig å opprette en direkte node-til-node-tilkobling i slike miljøer.
Hva er ICE-kandidater?
En ICE-kandidat er i praksis en mulig nettverksadresse og port der en node kan nås. Hver node samler inn flere kandidater som representerer ulike måter den kan kommunisere på.
Disse kandidatene kan sammenlignes med ulike telefonnumre eller adresser du kan ha: hjemmenummeret ditt, jobbnummeret ditt, nummeret til en venn som du kan nås hos, og så videre. ICE prøver dem alle.
Typer ICE-kandidater
Det finnes tre hovedtyper ICE-kandidater:
- Vertskandidater: Nodens faktiske lokale IP-adresser. De fungerer best for direkte tilkoblinger i samme lokale nettverk.
- Serverrefleksive kandidater: Hentes fra en STUN-server. Dette er den offentlige IP-adressen og porten din slik de ses av en ekstern server, og hjelper noder bak NAT med å finne hverandre.
- Relékandidater: Hentes fra en TURN-server. Hvis en direkte tilkobling ikke er mulig, videresender en TURN-server all trafikk. Dette er siste utvei.
Samle inn kandidater: Prosessen
Når en WebRTC-tilkobling startes, begynner nettleseren til hver node (WebRTC-agenten) å samle inn ICE-kandidater. Den undersøker aktivt det lokale nettverket, STUN-servere og eventuelt TURN-servere for å finne alle mulige kommunikasjonsbaner.
Denne innsamlingen skjer kontinuerlig i bakgrunnen mens RTCPeerConnection settes opp.
Kode: Lytt etter kandidater
I JavaScript lytter du etter icecandidate-hendelser på RTCPeerConnection-objektet ditt for å hente disse kandidatene. Hver hendelse gir en ny kandidat som kan deles med den eksterne noden via signaliseringsserveren.
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.Utveksle kandidater: Signalering
Når kandidatene er samlet inn, må de utveksles mellom de to nodene. Dette skjer via signaliseringsserveren din, den samme serveren som brukes til å utveksle SDP-tilbud og -svar.
- Hver node sender de innsamlede kandidatene sine til signaliseringsserveren.
- Signaliseringsserveren videresender kandidatene til den andre noden.
Denne prosessen kalles ofte «trickle ICE», fordi kandidatene sendes etter hvert som de blir funnet, i stedet for å vente til alle er samlet inn.
Tilkoblingskontrollen
Etter at kandidatene er utvekslet, begynner ICE tilkoblingskontrollene. Begge nodene prøver å opprette tilkoblinger ved hjelp av alle mulige par av lokale og eksterne kandidater. Dette innebærer å sende små «STUN binding requests» for å teste om de kan nås.
ICE prioriterer og velger deretter den mest effektive og pålitelige banen. Den foretrekker direkte vertstilkoblinger, deretter offentlige IP-adresser formidlet via STUN, og til slutt tilkoblinger formidlet via TURN.
Rask kontroll: Typer ICE-kandidater
Hvilken type ICE-kandidat hentes ved hjelp av en STUN-server for å avdekke en nodes offentlige IP-adresse?
Oppsummering: ICE i praksis
I denne leksjonen har du lært om ICE-kandidater og hvordan de gjør det mulig for WebRTC å opprette node-til-node-tilkoblinger på tvers av ulike nettverk.
- ICE-kandidater er mulige nettverksadresser.
- De finnes i typene vert, serverrefleksiv (STUN) og relé (TURN).
- Nodene samler inn og utveksler disse kandidatene via en signaliseringsserver.
- ICE utfører deretter tilkoblingskontroller for å finne den best mulige banen for direkte kommunikasjon.
ICE er den ukjente helten som sørger for at sanntidssamtalene dine finner en vei gjennom internetts kompleksitet!
Lær deg Sanntidsstrømmesystemer (WebRTC + sanntidsdata) med en AI-veileder – gratis
Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.
- Kurs
- 12
- Leksjoner
- 48
Ofte stilte spørsmål
Er leksjonen «ICE-kandidater og tilkobling» gratis?
Ja – hele teksten i «ICE-kandidater og tilkobling» er gratis å lese her på nettet. For å øve interaktivt med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt, og for å låse opp resten av Sanntidsstrømmesystemer (WebRTC + sanntidsdata)-kurset, kan du oppgradere til CoddyKit PRO. Kurset i Sanntidsstrømmesystemer (WebRTC + sanntidsdata) inneholder totalt 4 leksjoner.
Hva lærer jeg i «ICE-kandidater og tilkobling»?
Utforsk ICE-kandidater, hvordan de representerer nettverksadresser, og hvordan ICE bidrar til å finne den beste banen for en node-til-node-tilkobling. Du øver på Sanntidsstrømmesystemer (WebRTC + sanntidsdata) med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.
Trenger jeg erfaring for å begynne med Sanntidsstrømmesystemer (WebRTC + sanntidsdata)?
Ingen tidligere erfaring er nødvendig. Sanntidsstrømmesystemer (WebRTC + sanntidsdata) på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 3 av 4.
Hvor lang tid tar leksjonen «ICE-kandidater og tilkobling»?
De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.
Kan jeg skrive og kjøre kode i denne Sanntidsstrømmesystemer (WebRTC + sanntidsdata)-leksjonen?
Ja. Alle Sanntidsstrømmesystemer (WebRTC + sanntidsdata)-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.
Alle leksjonene i dette kurset
- Signaleringsservernes rolle
- SDP: Session Description Protocol
- ICE-kandidater og tilkobling
- Ny forhandling og tilkoblingstilstand