Clinfowiki
| Piecu slāņu TCP/IP modelis |
|---|
| Lietojumslānis |
| Transporta slānis |
| Tīkla slānis |
| Datu posma slānis |
| Fizikālais slānis |
IPv4 jeb Interneta protokols, versija 4 (angļu: Internet Protocol version 4)[1] ir interneta protokola 4. versija un pirmā tā plaši lietotā versija. IPv4 ir dominējošais tīkla slāņa protokols internetā. Otrs tīkla slāņa protokols, kuru lieto internetā, ir IPv6. IPv4 ir definēts RFC 791 (1981 gada septembrī), aizvietojot iepriekšējā protokola aprakstu RFC 760 (1980 gada janvārī). IP negarantē pakešu nogādi līdz galam, paketes var pienākt sajauktā secībā, dublēties vai pazust. Šīs problēmas risina transporta slāņa protokoli (TCP un daļēji UDP). Galvenā IP funkcija ir nodrošināt unikālu globālu datoru adresāciju, lai nodrošinātu, ka divi datori, kas sazinās caur internetu varētu viennozīmīgi identificēt viens otru.
Adresācija
IPv4 lieto 32 bitu (4 baitu) garas adreses, kas nozīmē to, ka adresācijas telpā ir 4 294 967 296 unikālas adreses. Daļa no šīm adresēm ir rezervētas īpašiem mērķiem (privātiem tīkliem (~18 miljoni), multicast (~1 miljons)). Tas samazina lietojamo adrešu skaitu. Tā, kā pieejamo adrešu skaits samazinās, tās kaut kad beigsies. Plaša NAT izplatība, gan šo laiku ir nobīdījusi tālāk. Šis ierobežojums bija viens no galvenajiem iemesliem IPv6 izstrādes sākšanai.
Adrešu attēlojums
Parasti IPv4 adreses (IP adreses) norāda formā a.b.c.d, kur a, b, c, d - skaitļi robežās no 0 līdz 255. Tā, kā adrese būtībā ir 32 bitu skaitlis, to var norādīt arī vienā gabalā. Šādu formātu parasti lieto programmu iekšienē.
Iedalījums (allocation)
Sākotnēji IP adresi sadalīja 2 daļās:
- Tīkla adrese (Network id) - pirmie 8 biti
- Datora adrese (Host id) - pēdējie 24 biti
Šādā veidā bija iespējami tikai 256 neatkarīgi tīkli un ātri bija skaidrs, ka tas ir par maz.
Pēc tam nodefinēja vairākas tīklu klases ar dažādiem tīkla adreses (un attiecīgi datora adreses) garumiem. Tika nodefinētas 5 klases (A, B, C, D un E), no kurām reāli lietojamas bija pirmās 3:
- A - 8biti tīkla adrese un 24 biti datora adrese, iespējami 256 tīkli ar ~16 miljoniem datoru katrā;(A klases adreses galvenokārt ir paredzēti izmantošanai ar vairākiem ļoti lieliem tīkliem, jo tie nodrošina tikai 7 bitus tīkla adreses laukam)
- B - 16 biti tīkla adrese un 16 biti datora adrese, iespējami ~65500 tīkli ar ~65500 datoriem katrā;(B klases adreses izdala 14 bitus tīkla adreses laukam un 16 bitus resursdatora adreses laukam. Šī adrešu klase nodrošina labu kompromisu starp tīkla un resursdatora adreses telpu.)
- C - 24 biti tīkla adrese un 8 biti datora adrese, iespējami ~16 miljoni tīkli ar 256 datoriem katrā.(C klases adreses izdala 22 bitus tīkla adreses laukam. Taču C klases adreses nodrošina tikai 8 bitus resursdatora adreses laukam, tāpēc resursdatoru skaits vienā tīklā var kļūt par ierobežojošu faktoru.)
D klasi bija paredzēts lietot multicast vajadzībām,(D klases adreses tiek rezervētas grupām ar vairākpunktu adresāciju (saskaņā ar oficiālu dokumentu RFC 1112). D klases adresēs četri augstākās kārtas biti tiek uzstādīti uz vērtībām 1,1,1 un 0.) un E klase bija rezervēta. Šī metode arī ar laiku vairs nebija optimāla, jo bija iespējami tikai šie 3 tīklu izmēri, piem. ja bija jāpieslēdz datortīklu ar 70000 datoriem, nācās ņemt A klases tīklu un vairāk kā 99,5 % adrešu atstāt neizmantotas un neizmantojamas citiem.
Ap 1993. gadu šīs 3 klases aizstāja ar CIDR shēmu, kur galvenā atšķirība ir tāda, ka tīkla adrese un datora adrese var būt ar jebkādu garumu (32 bitu robežās). Šī metode ļauj sadalīt A, B un C klases tīklus mazākos tīklos un samazināt adrešu zudumus. To ieviesa tāpēc, ka lietojot A un B klases tīklus, adreses sāka beigties jau 20. gadsimta 90. gadu sākumā. CIDR tīkla adreses bieži vien norāda formātā a.b.c.d/n, kur n ir bitu skaits tīkla adresē, jo n ir mazāks, jo lielāks tīkls. Tīklā lietojamās datoru adreses sākas no norādītā skaitļa (piem. 192.168.122.0/23 tīklā datoriem var būt adreses no 192.168.122.0 (reāli 1) līdz 192.168.123.255 (reāli 254)). Operētājsistēmām parasti norāda IP adresi un tīkla masku (subnet mask), kur tīkla maska ir tādā pašā formātā kā IP adrese, tikai visi tīkla adreses daļas biti ir 1. Iepriekšapskatītajā piemērā tīkla maska būtu 255.255.128.0
Adrešu iedalījums nav patvaļīgs jo adreses satur maršrutēšanas informāciju (routing), par datora atrašanās vietu tīklā. Internetā lietotās IP adreses iedala un iedalījumu uzrauga IANA un tās apakšorganizācijas (Eiropai un tuvajiem austrumiem (arī Latvijai) šī organizācija ir RIPE), kas tālāk adreses iedala interneta provaideriem, kuri tālāk tās iedala atsevišķiem lietotājiem.
| CIDR adrešu bloks | Apraksts | attiecīgais rfc |
|---|---|---|
| 0.0.0.0/8 | Esošais tīkls (lietojams tikai source adresēs) | RFC 1700 |
| 10.0.0.0/8 | Privātie tīkli | RFC 1918 |
| 14.0.0.0/8 | Public data networks | RFC 1700 |
| 127.0.0.0/8 | localhost | RFC 3330 |
| 128.0.0.0/16 | Rezervēti (IANA) | RFC 3330 |
| 169.254.0.0/16 | zeroconf | RFC 3927 |
| 172.16.0.0/12 | Privātie tīkli | RFC 1918 |
| 191.255.0.0/16 | Rezervēti (IANA) | RFC 3330 |
| 192.0.0.0/24 | Rezervēti (IANA) | RFC 3330 |
| 192.0.2.0/24 | Dokumentācijai un piemēriem | RFC 3330 |
| 192.88.99.0/24 | IPv6 uz IPv4 relay | RFC 3068 |
| 192.168.0.0/16 | Privātie tīkli | RFC 1918 |
| 198.18.0.0/15 | Network benchmark tests | RFC 2544 |
| 223.255.255.0/24 | Rezervēti (IANA) | RFC 3330 |
| 224.0.0.0/4 | Multicast (Bijušais D klases tīkls) | RFC 3171 |
| 240.0.0.0/4 | Rezervēti (Bijušais E klases tīkls) | RFC 1700 |
| 255.255.255.255 | Broadcast |
Privātie tīkli
No visām iespējamajām IPv4 adresēm 4 apglabali ir rezervēti privātajiem tīkliem. Šie apgabali nav tieši maršrutējami ārpus attiecīgā tīkla un tie datori nevar tieši sazināties ar internetu (bet caur NAT var).
| Nosaukums | IP adrešu apgabals | IP adrešu skaits | klases apraksts | lielākais CIDR bloks |
|---|---|---|---|---|
| 24-bitu bloks | 10.0.0.0 — 10.255.255.255 | 16 777 216 | 1 A klases bloks | 10.0.0.0/8 |
| 20-bitu bloks | 172.16.0.0 — 172.31.255.255 | 1 048 576 | 16 secīgi B klases bloki | 172.16.0.0/12 |
| 16-bitu bloks | 192.168.0.0 — 192.168.255.255 | 65 536 | 1 B klases bloks | 192.168.0.0/16 |
| 16-bitu bloks | 169.254.0.0 — 169.254.255.255 | 65 536 | 1 B klases bloks | 169.254.0.0/16 |
No šajiem te 169.254.0.0/16 bloku lieto arī zeroconf vajadzībām, tas ir ja datoram nav norādīta IP adrese un tas nespēj sazināties ar DHCP serveri, tiek paņemta nejauša adrese no šī bloka. Windowā zeroconf ir pieejams sākot ar windows 2000.
Atcilpa (Localhost)
- Galvenais raksts localhost
Papildus privātajiem tīkliem, IP adrešu apgabals 127.0.0.0 — 127.255.255.255 (127.0.0.0/8) ir rezervēts atcilpas localhost komunikācijām. Šī adresēm nevajadzētu parādīties nevienā reālā tīklā un IP paketēm, kas nosūtītas uz kādu no šīm adresēm nevajadzētu pamest datoru, no kura tās nosūtītas.
Domēnu vārdu sistēma
- Galvenais raksts DNS (protokols)
Lielāko daļu adrešu internetā pazīst nevis pēc to cipariskajām IP adresēm, bet gan pēc domēnu vārdiem (lv.wikipedia.org, www.draugiem.lv). IP adrešu maršrutizācija caur tīklu nav saistīta ar šiem vārdiem, tāpēc nepieciešams pārveidot vārdus par IP adresēm. To veic DNS. Tāpat kā CIDR adresācija, DNS arī ir hierarhisks. Eksistē arī reversīvais DNS, kas no dotās IP adreses mēģina iegūt tai atbilstošo domēna vārdu, taču tas bieži vien nedarbojas.
IP adrešu izbeigšanās
Sākotnējās IP adrešu iedalīšanas shēmas bija visai neefektīvas (taču tur varēja lietot primitīvus maršrutētājus (router), jo varēja iztikt ar maziem daudzumiem atmiņas. Augot internetam adreses sāka beigties. Sākumā ieviesa klašu tīklus (A, B un C klases tīkli), bet tas ilgi nepalīdzēja un nācās iet vēl tālāk un ieviest CIDR. Šis progress palielināja prasības galveno rūteru atmiņas ietilpībai. Tā, kā interneta lietotāju (pieslēgumu) skaits pieaug un palielinās pastāvīgo pieslēgumu skaits (kur IP adrese ir aizņemta 24/7/356), brīvo IP adrešu skaits samazinās.
Galīgais risinājums šai problēmai droši vien būs pilnīga pāreja uz IPv6, jo tur ir garākas adreses. Vēl dažas lietas, kas novilcina IPv4 adrešu izbeigšanos ir:
- NAT
- DHCP
- Privāto tīklu lietošana
- Uz domēnu vārdiem bāzēts virtuālais hostings (serveriem (no vienas IP adreses atver dažādas interneta lapas, atkarībā no lietotā DNS vārda))
- Stingrāka IP adrešu iedalīšanas kontrole
Daļu no tiem var apvienot. 2007. gada maijā saskaņā ar dažādām prognozēm uzskatīja, ka IPv4 adreses izbeigsies kaut kad starp 2010. gada martu un maiju.
NAT
- Galvenais raksts NAT
Viena no metodēm, kā uzlabot esošo adrešu lietošanas efektivitāti un drošību ir lietot NAT (network address translation). Šajā gadījumā vienu ārējo adresi uzliek rūterim un iekšējā tīklā lieto privātās adreses. NAT pārraksta izejošo un ienākošo IP pakešu headerus (adreses un portus). TCP gadījumā NAT seko līdzi savienojumiem. UDP gadījumā no ārpuses ienākošās paketes pārsūta uz iekšējās adreses source portu. NAT, pēc definīcijas, bloķē visas ienākošās komunikācijas. Ja augšējā līmeņa protokols IP adrešu datus ievieto paketes datu apgabalā, NAT vai nu nedarbojas, vai arī tam vajag protokola specifisku paplašinājumu.
Virtuālie privātie tīkli
Interneta maršrutētāji ignorē privātās adreses, tāpēc lai savienotu tīklus, kas lieto šādas adreses lieto VPN (virtual private network).
VPN ievieto pārsūtāmā tīkla paketi ārējā tīkla paketē kā datus. VPN var lietot ne tikai IP, bet arī jebkuru tīkla slāņa protokolu. Pirms ievietošanas (enkapsulācijas), datu paketi var nošifrēt. Otrā galā pēc tam izvelk sākotnējo paketi. Parasti VPN darbojas caur UDP vai GRE protokoliem.
ARP
- Galvenias raksts ARP
IP ir tīkla slāņa protokols. Tā sasaisti ar kanāla slāņa adresēm nodrošina ARP (address resolution protocol) protokols. ARP iegūst datus par attālināto sistēmu MAC adresēm zinot IP adreses.
RARP/DHCP
- Galvenais raksts DHCP
RARP (reverse address resolution protocol) bija protokols, kas darbojās pretējā virzienā kā ARP. RARP - (Reversais adreses noteikšanas protokols), kuri dinamiski nosaka fizikālo (aparatūras) adrešu atbilstību IP adresēm un otrādi. ARP izmanto apraides paziņojumus aparatūras adreses noteikšanai (MAC slānis), kura atbilst konkrētai IP tīkla slāņa adresei. ARP protokolam ir pietiekoši universāls, lai ļautu izmantot IP ar praktiski jebkuru vides pieejas mehānisma tipu. RARP izmanto apraides paziņojumus IP adreses noteikšanai, kura saistīta ar konkrēto aparatūras adresi. RARP ir īpaši nozīmīgs mezgliem, kuriem nav diska un kuri var nezināt savu IP adresi, kad tie tiek sākotnēji iedarbināti. RARP paļaujas uz RARP servera esamību ar tabulas ierakstiem, kuri attēlo MAC apakšslāņa adreses IP adresēs. Vēlāk tika izstrādāta funkcionāli paplašināta jaunāka versija DHCP (dynamic host configuration protocol). Šie visi protokoli iegūst esošās sistēmas IP adresi (kura līdz tam nav zināma), zinot tās MAC adresi. DHCP galvenokārt lieto lai datoriem nebūtu IP adreses jānorāda katram atsevišķi.
Pakešu struktūra
IP pakete sastāv no divām daļām: galvenes (header) un datiem.
Galvene
Galvene (header) sastāv no 13 laukiem, no kuriem 12 ir obligāti.
| + | Bits 0—3 | 4—7 | 8—15 | 16—18 | 19—31 | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | Versija | Galvenes garums | Type of Service (tagad DiffServ un ECN) |
Kopējais garums | ||||||||||||||||||||||||||||
| 32 | Identification | Flags | Fragment Offset | |||||||||||||||||||||||||||||
| 64 | Time to Live | Protokols | Galvenes kontrolsumma | |||||||||||||||||||||||||||||
| 96 | Source Address | |||||||||||||||||||||||||||||||
| 128 | Destination Address | |||||||||||||||||||||||||||||||
| 160 | Options | |||||||||||||||||||||||||||||||
| 160 vai 192+ |
Dati | |||||||||||||||||||||||||||||||
- Versija - pirmais headera lauks IP paketē satur datus par protokola versiju. IPv4 gadījumā tā lauka vērtība vienmēr ir 4.
- Galvenes garums (internet header length (IHL)) - Šis lauks apraksta 32 bitu vārdu skaitu galvenē (header). Minimālais garums ir 5 (pirmie 12 lauki aizņem 5*32=160 bitus). Options lauka garums var būt mainīgs. Šis ir 4 bitu lauks un tā maksimālā vērtība var būt 15, tāpēc galvenes (header) maksimālais garums var būt 480 biti
- type of service (TOS) - sākotnējā variantā šis lauks bija paredzēts lai noteiktu vai svarīgāk ir paketi nosūtīt pēc iespējas ātrāk (low delay) vai arī pēc iespējas drošāk (high reliability), ja ir izvēle. Rūteri lielākoties šo lauku ignorē. Ir bijuši mēģinājumi šo lauku lietot citiem mērķiem (Diffserv un ECN). Diffserv ir apmēram analoga funkcionalitāte sākotnējam mērķim. ECN dažreiz lieto lai noteiktu savienojuma caurlaidību, ja abi galapunkti to atbalsta. (kaut kas līdzīgs ir iebūvēts jau TCP) Šīs tehnoloģijas jebkurā gadījumā netiek plaši lietotas.
- Kopējais garums - šis 16 bitu lauks definē visas paketes izmēru (baitos). Minimālais paketes izmērs ir 20 baiti (pirmie 12 galvenes (header) lauki). Datoriem ir jāspēj saņemt vismaz 576 baitus garas paketes, parasti var vairāk. Maksimālais paketes izmērs var būt 65535 baiti. Bieži vien apakšējā līmeņa protokoli izvirza tālākas prasības maksimālajam paketes izmēram un paketi ir jāfragmentē. (piem. ethernet paketes izmērs ir 1500 baiti).
- Identification - šis lauks viennozīmīgi identificē paketi. To galvenokārt lieto lai identificētu fragmentētas paketes fragmentus. (tiem tas būs vienāds)
- Flags - tas ir 3 bitu lauks, kuru lieto lai kontrolētu fragmentāciju, šo bitu funkcijas ir:
- Rezervēts, tam jābūt 0.
- Nefragmentēt (don't fragment)(DF)
- Vēl ir fragmenti (more fragments)(MF)
- Ja DF ir aktīvs un paketei ir nepieciešama fragmentācija, lai to varētu pārsūtīt tālāk, paketi izmet un atpakaļ aizsūta kļūdas paziņojumu. Šo lieto lai sūtītu paketes uz datoriem, kas nespēj sagremot fragmentāciju (lielākoties boot rom, lādējot operētājsistēmu no tīkla)
- Ja MF ir aktīvs, tad tas nozīmē ka pakete ir bijusi fragmentēta un šis nav pēdējais fragments. Nefragmentēta pakete vienmēr ir pēdējais fragments, tāpēc tai MF nav aktīvs.
- Fragment offset - fragmentētām paketēm šis lauks satur informāciju par paketes sākuma attālumu (blokos pa 8 baitiem) no nefragmentētās paketes sākuma.
- Time to live (TTL) jeb dzīvlaiks - 8 bitu lauks radīts lai novērstu kļūdainu pakešu bezgalīgu cirkulāciju tīklos. Šis lauks nosaka paketes dzīves laiku sekundēs, bet ja paketes apstrādes laiks ir mazāks par sekundi, tad tas ir jāsamazina par 1. Mūsdienās pakešu nosūtīšana starp maršrutētājiem gandrīz vai nekad nebūs ilgāka par sekundi, tāpēc praktiski šī lauka vērtība izsaka lēkumu skaitu (Hop Count). Attiecīgais IPv6 galvenes lauks ir Hop Limit un izsaka lēkumu skaitu, tāpēc šajā versijā nepastāv pretrunas starp lauka nosaukumu un tā lietojumu. Katrs maršrutētājs, kam pakete iet cauri, samazina šī lauka vērtību par 1. Maršrutētājs, kurā TTL samazinās līdz 0, paketi izmet. Traceroute (tracert) utilītprogramma izmanto šo lauku maršruta noteikšanai līdz adresātam. Maršruta noteikšana notiek pakāpeniski vairākos soļos. Vispirms tiek sūtīta ICMP protokola pakete adresātam ar TTL lauka vērtību 1. Pirmais maršrutētājs samazina TTL lauka vērtību līdz 0, izmet paketi tad nosūta ziņojumu sākotnējās paketes nosūtītājam. No atbildes Traceroute utilītprogramma uzzina pirmā maršrutētāja adresi un paketes nosūtīšanas laiku. Nākamajā solī TTL lauks tiek palielināts līdz 2 un tiek noskaidroti dati par otro maršrutētāju. Šo secību atkārto kamēr pakete sasniedz adresātu. Tādā veidā tiek iegūta informācija par viesiem maršrutētājiem maršrutā līdz adresātam.
- Protokols - šis lauks definē datu daļā ievietoto transporta slāņa protokolu. Šis ir 8 bitu lauks.
- Galvenes kontrolsumma - šo 16 bitu lauku lieto lai pārbaudītu vai galvene (header) nav izmainījusies pārsūtīšanas laikā. Ja kontrolsumma neatbilst, paketi izmet. Datu atbilstību pārbauda attiecīgie transporta slāņa protokoli. Tā, kā katrā rūterī mainās TTL un ir iespējama fragmentācija, šo lauku nākas pārrēķināt katrā rūterī.
- Source address - nosūtītāja IP adrese. Ja paketi nākas izmest, uz turieni nosūta kļūdas paziņojumu. Šī var nebūt nosūtītāja adrese, ja lieto NAT.
- Destination address - saņēmēja IP adrese. Uz turieni paketi mēģina piegādāt.
- Options - šo lauku lieto ļoti reti.
Dati
Datu daļa nav daļa no galvenes (header) un tai neaprēķina IP kontrolsummu. Datu daļas saturs var būt jebkurš transporta slāņa protokols, tas ir norādīts galvenes protokola laukā. Daži izplatītākie protokoli (un tiem atbilstošie numuri, kurus lieto protokola laukā) ir:
Fragmentācija
Lai IP labāk darbotos heterogēnos tīklos (ar dažādiem MTU (maximum transmission unit)), tam pielika fragmentāciju. Fragmentācija ir vajadzīga, kad paketes izmērs ir lielāks par lietojamā tīkla MTU. Piem. ethernet MTU parasti ir 1500 baiti, IP galvene (header) aizņem 20 baitus, IP datiem atstājot 1480 baitus, šādā veidā maksimālā izmēra IP paketei (65535 baiti datu) vajag 45 paketes (65535/1480 = 44,28). Tīkla slānī fragmentācija ir efektīvāka kā augšējo un apakšējo līmeņu slāņos.
Kad ierīce (rūteris) saņem IP paketi pārsūtīšanai tālāk, tas nolasa destination address un pēc tās izvēlas izejošo interfeisu. Katram tīkla interfeisam (parasti tīkla karte, bet var būt arī PPP interfeisi) ir zināms tā MTU, kas nosaka maksimālo vienā piegājienā nosūtāmo datu izmēru. Ja MTU ir mazāks kā ienākošā pakete, paketi ir jāfragmentē. Rūteris pēc tam sadala ienākošos datus paketēs, kur katra ir vienāda vai mazāka par izejošā interfeisa MTU (kopā ar galveni). Katru segmentu tad ieliek atsevišķā paketē, ar sekojošām izmaiņām:
- Kopējā garuma laukā ieliek attiecīgā segmenta garumu,
- MF (more fragments) flagu uzliek uz 1 visiem segmentiem, izņemot pēdējo,
- Norāda fragment offsetu, atbilstoši segmenta sākuma attālumam no sākotnējās paketes sākuma.
Piem. ja IP galvene ir 20 baiti un ethernet MTU ir 1500, tad fragmentu offseti būs 0, (1480/8) = 185, 2960/8) = 370, (4440/8) = 555, (5920/8) = 740, utt. Ja MTU-galvenes garums nedalās ar 8, tad paketes izmērs var būt mazāks par MTU. (šie zudumi ir 4 baiti vai mazāk).
Ja kādā no tālākajiem rūteriem MTU (maximum transmission unit) samazinās vēl vairāk, fragmentus nākas fragmentēt vēl tālāk. Fragmentus savieno kopā tikai beigās, saņēmēja datorā. Fragmentācija parasti notiek rūteros pa ceļam, lai arī ar dažiem protokoliem (ICMP) var notikt jau nosūtītāja datorā.
Piem. ja 4500 baitus datu ievieto vienkāršā IP paketē (kopējais garums (dati + galvene) 4520) un pārsūta caur savienojumu ar MTU 2500, tad to safragmentēs 2 fragmentos:
| # | Kopējais garums | More fragments (MF) aktīvs? |
Fragmenta offsets | |
|---|---|---|---|---|
| Galvene | Dati | |||
| 1 | 2500 | jā | 0 | |
| 20 | 2480 | |||
| 2 | 2040 | nē | 310 | |
| 20 | 2020 | |||
Ja nākamajā rūterī MTU samazināsies līdz 1500, katru fragmentu būs jāsadala vēl 2 gabalos:
| # | Kopējais garums | More fragments (MF) aktīvs? |
Fragmenta offsets | |
|---|---|---|---|---|
| Galvene | Dati | |||
| 1 | 1500 | jā | 0 | |
| 20 | 1480 | |||
| 2 | 1020 | jā | 185 | |
| 20 | 1000 | |||
| 3 | 1500 | jā | 310 | |
| 20 | 1480 | |||
| 4 | 560 | nē | 495 | |
| 20 | 540 | |||
Kopējais datu daudzums nemainās: 1480 + 1000 + 1480 + 540 = 4500 un pēdējais fragments + offsets 3960 + 540 = 4500 ir arī kopējais garums. 3. un 4. fragments šeit tikai iegūti no sākotnējā 2. fragmenta. Tad, kad routerim ir jāfragmentē pēdējo fragmentu, tas uzliek MF aktīvi visiem fragmentiem, izņemot pēdējo (šajā gadījumā 3.) (fragmentējot jebkuru iepriekšējo fragmentu, tie jau visiem ir MF aktīvs).
Kad saņēmējdators saņem IP paketi, kurai ir spēkā jebkurš no šiem kritērijiem:
- MF ir aktīvs
- fragment offset lauks nav 0
tad saņēmējs zin, ka pakete ir fragments. Saņēmējs tad saglabā datus ar identifikācijas lauku, fragment offset un aktīvu MF. Kad saņēmējs saņem fragmentu bez aktīva MF, ir zināms sākotnējās paketes garums. (fragment offset + data length). Tad, kad ir pieejami visi fragmenti, datus var sakārtot sākotnējā secībā un pakete ir saņemta veiksmīgi.
Atsauces
- ↑ «Latvijas Nacionālais terminoloģijas portāls - IPv4». termini.gov.lv.
|
