Selvfølgelig, jo mindre overhead, jo bedre resultater vil være. Imidlertid, er det to måter å oppnå dette effektivitet i et pakke. Den første er å gjøre topptekstene mindre i en absolutt forstand. Den andre er å bruke større pakker, noe som gjør den overliggende mindre bare i forhold til dataene.

For å forstå den første kategorien, mener at overskriftene i en typisk pakke for hver protokoll, for eksempel Ethernet, IP, UDP (User Datagram Protocol) og RTP (Real Time Transport Protocol) overskrifter, kan være mye mindre, men dette vil gå på bekostning av fleksibilitet og funksjonalitet. For eksempel, hvis vi ikke brukte en byte av hver pakke på type tjeneste, ville våre nettverk være litt romsligere, men vi ville miste muligheten til å klassifisere pakker basert på differensierte tjenester Kode Point eller IP-presedens.

En av de mest vanlige ting folk gjør for å bedre kobling effektivitet ved å redusere hodestørrelsen kalles IP header komprimering, spesifisert i RFC1144 og RFC2509. Du har kanskje lagt merke til denne funksjonen på mange eksterne nettverksklienter. For eksempel, i Microsoft Windows, er det litt i boksen i dialogboksen hvor du konfigurere Point-to-Point Protocol (PPP).

En lignende metode, men en mer passende for VoIP, er RFC2508, som angir Compressed Real Time Protocol (CRTP). Denne protokollen er enkel å konfigurere, mister ikke funksjonalitet, og forbedrer dramatisk effektivitet på en link. Den gjør dette ved å ta IP header (20 bytes), UDP header (8 bytes) og RTP header (12 bytes), som til sammen skaper en 40 byte header, og erstatte dem med et enkelt header som ofte bare to 4 byte. Gitt at taletrafikk er vanligvis et stort antall meget små pakker, bruker CRTP (forutsatt at VoIP bruker RTP) kan enkelt klippe båndbredde behov i halvparten på PPP-koblinger.

som ble nevnt tidligere, den andre metode for å oppnå kobling effektivitet er å endre størrelsen på pakkene for å inkludere mer data pr spissen. For å forklare hvordan dette fungerer, la oss vurdere to filoverføringer der vi sender en million byte fil. For enkelhets skyld vil vi late som vår transfer program etterlater oss med en 40-byte spissen. I det første tilfellet, la oss bruke Ethernet minimum rammestørrelse på 64 bytes, og i den andre, vil vi bruke maksimalt 1518 byte.

64 bytes totalt - 40 byte overhead = 24 byte data per pakke for den første overføringen 1518 bytes totalt - 40 overhead = 1478 byte med data per pakke for andre overførings

1.000.000 byte data /24 bytes per pakke = 41,666 pakker i den første overføringen 1.000.000 byte data /1478 bytes per pakke = 676 pakker i andre overførings

41,666 pakker x 40 byte = 1,666,640 byte overhead for første overføringen 676 pakker x 40 bytes = 27,040 byte av overhead for den andre overførings

Således tar den første overførings 2,666,640 byte, og er 62% overhead, mens den andre overførings setter 1,027,040 bytes på viren og er 3% overhead.

Disse grunnleggende beregninger er det grunnleggende bak den andre kategorien av nettverks innovasjoner. Fordelen i effektivitet for store pakker er åpenbare og har blitt normen. Men nå har vi andre programmer som kommer inn i nettverket som trenger å redusere forsinkelsen heller enn å maksimere gjennomstrømming. Så vi trenger en løsning som lar oss har adresse effektivitet og lav forsinkelse og jitter. Den vanligste av disse løsningene er fragmentering og interleaving.

Konseptet bak fragmentering og innfellingen er enkel. Fordi det er upraktisk å gjøre alle pakkene samme størrelse, og vi kan ikke ha store pakker forsinke vår stemme pakker på trege WAN-koblinger, vil vi bryte opp disse store datapakker på linken lag og spleise talepakkene i mellom dem.

Det første du bør forstå om denne prosessen er at fragmentering og innfellingen er helt lokale til en datalink, i motsetning til IP fragmentering. Det vil si, når en pakke blir fragmentert på nettverkslaget, ved hjelp av fragmentering biter i IP header, pakken forblir fragmentert på tvers av alle sine hopp til alle fragmentene nå målet, hvor mottakeren er ansvarlig for reassembling fragmentene. I stedet, i et data-link layer fragmentering, slik som Frame Relay s FRF.12, er pakken fragmentert som det er plassert inn i en permanent virtuell krets (PVC) og settes sammen igjen av ruteren på den andre siden av den PVC som det er fjernet .

Neste, fragmentering og interleaving vil ikke gjøre deg mye bra uten kvaliteten på tjenesten. Du må klassifisere talepakkene som høyere prioritet enn fragmenter av data. Ellers vil mye av fragmenter fortsatt sendes i forkant av stemmen din og du vil være verre enn du startet.

Sist, vet at fragmentering og innfellings legge litt forsinkelse å redusere mye jitter. Den ekstra behandlingstid å fragmentere, flette og montere er relativt konstant, og heldigvis, er sannsynligvis ikke merkbar for brukere. Forstyrrelser, som er forsinkelsen til en håndfull av pakker, forårsaket av en lang ventetid mens en datapakke blir overbelaste et WAN-koblingen, er mye mer merkbar for brukerne. Med andre ord, hvis problemet er at alle pakkene har for mye forsinkelse, så fragmentering og innfellingen er nok ikke løsningen du leter etter.

Ikke gå glipp av! Lær mer om alle våre konferansemøtene og høyttalere: http://www.networkingdecisions.com/html/ci_sessions.htm