TCP caurlaidspējas griestu izpratne
Tīkla veiktspēju bieži vien kļūdaini vērtē tikai pēc tā nominālā savienojuma ātruma. Reālajā pasaulē viena TCP plūsma saskaras ar trim neatkarīgiem griestiem, un faktiskā pārraides ātruma noteikšanā vienmēr uzvar zemākais no tiem. Šie trīs ierobežojošie faktori ir savienojuma kapacitāte, saņemšanas logs un pakešu zudumi.
Kalkulators aprēķina katru no šiem griestiem, lai identificētu aktīvo vājo vietu. Rezultātos tiek attēlota "Paredzamā TCP caurlaidspēja" kopā ar dinamisko norādi "ierobežo ‹constraint›", kur kā ierobežotājs tiek identificēta "savienojuma kapacitāte", "saņemšanas logs" vai "pakešu zudumi".
- Savienojuma kapacitāte pēc virsizdevumiem: Fiziskā slāņa ātrums nekad nav pilnībā pieejams lietotāja datiem. Protokolu virsizdevumi (Ethernet, IP un TCP galvenes) patērē daļu no joslas platuma.
- Saņemšanas logs: TCP ir plūsmas kontroles mehānisms, kas neļauj sūtītājam pārslogot uztvērēja buferi. Ja saņemšanas logs ir pārāk mazs attiecībā pret ceļa aizturi, sūtītājam ir jāgaida apstiprinājumi, pirms sūtīt nākamos datus.
- Pakešu zudumi: TCP uztver pakešu zudumus kā tīkla sastrēguma signālu un nekavējoties samazina sūtīšanas ātrumu. Pat niecīgs zudumu procents var dramatiski samazināt caurlaidspēju neatkarīgi no fiziskā savienojuma ātruma.
Joslas platuma un aiztures reizinājums (BDP)
Lai pilnībā noslogotu tīkla ceļu, sūtītājam ir jāspēj nosūtīt pietiekami daudz datu, lai aizpildītu visu "cauruli" starp abiem punktiem, pirms tiek saņemts pirmais apstiprinājums. Šo nepieciešamo datu apjomu sauc par joslas platuma un aiztures reizinājumu (BDP).
BDP tiek aprēķināts, reizinot savienojuma ātrumu ar paketes aprites laiku (RTT):
BDP = ātrums × RTT = ‹rate› × ‹rtt› = ‹bdp› = ‹bytes›
Ja uztveršanas logs ir mazāks par BDP, sūtītājs būs spiests dīkstāvēt, gaidot apstiprinājumus, un savienojums netiks pilnībā izmantots. Kalkulators parāda šo sakarību ar parametru "Logs ceļa aizpildīšanai", kas tiek atvasināts kā Logs ceļa aizpildīšanai = BDP ÷ 8 = ‹bdp› → ‹window›.
TCP loga mērogošana (RFC 7323)
Sākotnējā TCP specifikācijā maksimālais saņemšanas loga izmērs bija ierobežots līdz 16 bitiem, kas atbilst 65 535 baitiem. Mūsdienu ātrajos tīklos ar lielu aizturi (tā sauktajos LFN jeb Long-Fat Networks) šāds loga izmērs ir nepietiekams.
Lai pārvarētu šo ierobežojumu, standarts RFC 7323 definē TCP loga mērogošanas opciju, kas ļauj saskaņot loga izmēru līdz pat 1 073 725 440 baitiem (aptuveni 1 GB). Kalkulators analizē ievadītos datus un izvada atbilstošus paziņojumus:
- Ja ceļa aizpildīšanai nepieciešamais logs pārsniedz 65 535 baitus, parādās paziņojums: "Šī ceļa aizpildīšanai nepieciešams
‹window›logs — tas pārsniedz 65,535 baitu nemērogoto maksimumu, tāpēc abām pusēm ir jāvienojas par TCP loga mērogošanu (RFC 7323)." - Ja nepieciešamais logs pārsniedz absolūto TCP mērogošanas robežu, tiek parādīts brīdinājums: "Šī ceļa aizpildīšanai nepieciešams
‹window›— tas pārsniedz lielāko logu, par ko TCP var vienoties (1,073,725,440 baiti). Viena plūsma šajā ceļā nekad nevar pārsniegt‹value›." - Ja lietotājs ir manuāli ierobežojis uztveršanas logu, rīks var ieteikt: "Uztveršanas loga palielināšana līdz
‹window›ļautu šai pārsūtīšanai sasniegt līdz‹value›."
Pakešu zudumu ietekme un Mathis modelis
Kad tīklā rodas pakešu zudumi, TCP caurlaidspējas griestus nosaka Mathis formula. Šis modelis matemātiski apraksta, kā TCP sastrēgumu kontroles algoritmi reaģē uz zudumiem:
Zudumu griesti (Mathis) = MSS ÷ RTT ÷ √p = ‹mss› ÷ ‹rtt› ÷ √‹p› = ‹value›
Šeit MSS ir maksimālais segmenta izmērs (lietderīgās slodzes baiti paketē), RTT ir paketes aprites laiks, bet p ir vidējā pakešu zudumu varbūtība.
Mathis modelis pieņem, ka pakešu zudumi ir vienmērīgi sadalīti un neatkarīgi. Tas saglabā uzticamību tikai tad, ja zudumu līmenis nepārsniedz aptuveni 1%. Ja ievadītais zudumu procents pārsniedz šo robežu, kalkulators parāda brīdinājumu: "Zudumi virs 1% ir ārpus Mathis modeļa uzticamā diapazona — uztveriet zudumu griestus kā optimistisku novērtējumu."
Protokola virsizdevumi un efektivitāte
Katrs pārsūtītais datu segments tiek iekapsulēts vairākos protokolu slāņos. Standarta Ethernet tīklā katrai paketei tiek pievienoti 78 baiti papildu slodzes (40 baiti TCP/IP galvenēm un 38 baiti fiziskā slāņa un kadru virsizdevumiem).
Kalkulators aprēķina protokola efektivitāti, pamatojoties uz lietotāja norādīto MSS vērtību:
Protokola efektivitāte = MSS ÷ (MSS + 78 B) = ‹mss› ÷ ‹frame› = ‹eff› (40 B pakešu galvenes + 38 B fiziskajā slānī)
Pēc tam tiek noteikti teorētiskie savienojuma griesti pēc virsizdevumu atskaitīšanas:
Savienojuma griesti = ātrums × efektivitāte = ‹rate› × ‹eff› = ‹value›
Decimālās un binārās mērvienības
Biežs pārpratumu cēlonis tīkla analīzē ir atšķirības starp mērvienību sistēmām. Tīkla aparatūra un šis kalkulators izmanto decimālo sistēmu (kur 1 kbit = 1000 bitu, 1 MB = 1 000 000 baitu). Turpretī operētājsistēmas un failu pārvaldnieki parasti mēra failu izmērus binārajā sistēmā (kur 1 KiB = 1024 baiti, 1 MiB = 1 048 576 baiti). Tāpēc failu pārvaldniekā redzamais "100 MB" fails patiesībā ir 100 MiB jeb aptuveni 104,86 decimālie megabaiti, un tā pārsūtīšana prasīs par aptuveni 5% ilgāku laiku.
Datu apstrāde un privātums
Kalkulators ir izstrādāts tā, lai nodrošinātu pilnīgu datu konfidencialitāti. Katra lietotāja ievadītā vērtība tiek aprēķināta lokāli tīmekļa pārlūkprogrammā — nekādi dati netiek sūtīti uz ārējiem serveriem.
Biežāk uzdotie jautājumi (FAQ)
Kas ir joslas platuma un aiztures reizinājums (BDP), un kāpēc tas nosaka loga izmēru?
BDP — savienojuma ātrums × paketes aprites laiks — ir datu apjoms, kas jebkurā brīdī atrodas ceļā. TCP vienlaikus var būt ne vairāk kā viens neapstiprināts logs, tādēļ logs, kas ir mazāks par BDP, atstāj kanālu daļēji tukšu: pie 100 Mbit/s ar 50 ms RTT kanāls satur 625 kB, un 65,535 baitu logs aizpilda tikko desmito daļu no tā. Tāpēc ātriem, gariem ceļiem ir nepieciešama TCP loga mērogošana (RFC 7323), kas palielina saskaņojamo maksimumu no 65,535 baitiem līdz aptuveni 1 GB.
Kāpēc mana pārraide ir lēnāka par savienojuma ātrumu, par kuru es maksāju?
Viena TCP plūsma saskaras ar trim neatkarīgiem griestiem, un zemākais no tiem uzvar. Protokola pieskaitāmās izmaksas samazina pašu savienojumu par aptuveni 5% — standarta Ethernet kadrs pārnes 1,460 lietderīgās slodzes baitus no 1,538 baitiem fiziskajā slānī. Saņemšanas logs ierobežo caurlaidspēju līdz logs ÷ RTT, tāpēc klasiskais 65,535 baitu logs ierobežo 50 ms ceļu līdz aptuveni 10.5 Mbit/s neatkarīgi no tā, cik ātrs ir savienojums. Savukārt zudumi to ierobežo līdz (MSS ÷ RTT) ÷ √zudumi. Augstāk redzamais rezultāts norāda, kuri griesti ir noteicošie jūsu ievadītajiem skaitļiem.
Kā pakešu zudumi ierobežo TCP caurlaidspēju?
TCP uztver zudumus kā sastrēgumu un pie katra zudumu gadījuma samazina savu sūtīšanas ātrumu uz pusi, tāpēc pat niecīgi zudumu procenti ir būtiski ātriem ceļem. Mathis modelis aplēš griestus kā (MSS ÷ RTT) ÷ √p — pie 0.01% zudumiem 50 ms ceļā ar 1,460 baitu MSS tas ir aptuveni 23 Mbit/s neatkarīgi no savienojuma ātruma. Modelis pieņem vienmērīgi sadalītus, neatkarīgus zudumu gadījumus; ja zudumi ir mazāki par aptuveni 1%, tas labi atbilst realitātei, bet kaskādes veida zudumu gadījumā tas ir optimistisks.
Vai megabaiti šeit ir tādi paši kā manā failu pārvaldniekā?
Ne gluži. Šajā lapā tiek izmantotas decimālās mērvienības, kas ir tīklu veidošanas konvencija: 1 kbit = 1,000 biti un 1 MB = 1,000,000 baitu. Lielākā daļa failu pārvaldnieku skaita mērvienībās, kuru pamatā ir 1024, bieži vien kļūdaini apzīmējot tās kā MB — tur “100 MB” fails parasti ir 100 MiB ≈ 104.86 decimālie MB, tāpēc tā pārsūtīšana prasa par aptuveni 5% ilgāku laiku, nekā liecina decimālais skaitlis. Ievadiet šeit 104.86 MB, lai tas precīzi sakristu.