Skip to Content

Wiki source code of 24.03. Garas resnās caurules

Last modified by Valdis Vītoliņš on 2018/01/15 21:44
Hide last authors
Valdis Vītoliņš 1.1 1 = 24.03. Garas resnās caurules =
2
3 [[20.07.nodaļā>>20_07]] parādījām, ka savienojuma //kapacitāte// ir: [[image:capacity.gif]] un nosaucām to par joslas platuma un //aiztures// reizinājumu. To sauc arī par caurules izmēru starp diviem galapunktiem.
4
5 TCP protokola ierobežojumi atklājas, kad šis reizinājums pieaug uz arvien augstākām un augstākām vērtībām. 24.5.attēls parāda dažas vērtības dažādiem tīklu tipiem.
6
7 {{velocity filter="none"}}
8 {{html clean="false" wiki="true"}}
9 #pic("f_24_5.gif", "500")
10 //24.5.attēls: Joslas platuma un aiztures reizinājums dažādiem tīkliem//
11 <p/>
12 Mēs parādām joslas platuma un aiztures reizinājumu baitos, jo tas ir tas, kā mēs parasti mērām buferu izmērus un logu izmērus, kas vajadzīgi katrā galā.
13 <p/>
14 Tīkli ar lieliem joslas platuma un aiztures reizinājumiem tiek saukti par //garajiem/resnajiem tīkliem// (angļu akronīms šiem tīkliem LFN, ko izrunā "elefanti"), un TCP savienojumu, kas darbojas garā/resnā savienojumā sauc par //garu resno cauruli//. Atgriežoties pie #picref("f_20_11.gif", "20.11.attēla") un #picref("f_20_12.gif", "20.12.attēla") cauruli var pastiept horizontālā virzienā (garāks aprites laiks - RTT), vai var pastiept vertikālā virzienā (augstāks joslas platums), vai abos virzienos. Garās resnajās caurulēs sastopamas dažādas problēmas.
15 <p/>
16 <ol>
17 <li>TCP loga izmērs ir 16 bitu lauks TCP sākumposmā, kas ierobežo loga izmēru ar 65535 baitiem. Kā varam redzēt no pēdējās kolonnas #picref("f_24_5.gif", "24.5.attēlā"), jau pašlaik eksistējošie tīkli prasa lielākus logus par šo, lai sasniegtu maksimālu //caurlaidspēju//.
18 The window scale option described in Section 24.4 solves this problem.
19 </li>
20 <li>Pakešu zaudēšana //LFNā// var jūtami samazināt caurlaidību. Ja pazūd kaut viens segments, ātrās //atkalsūtīšanas// un //ātrās atkopšanās// algoritms, ko aprakstījām [[21.7.nodaļā>>21_07]], ir nepieciešams, lai caurulē neapturētu straumi. Bet pat ar šo algoritmu, vairāk nekā vienas paketes zudums viena loga ietvaros parasti aptur straumi. (Ja caurule ir sausa, lēnais starts var plūsmu atjaunot, bet tam nepieciešami vairāki //aprites laiki//.)
21 Selektīvie apstiprinājumi (SACK'i) tika piedāvāti RFC 1072 [Jacobson and Braden 1988] lai tiktu galā ar vairāku pazudušo pakešu problēmu vienā logā. Bet šo funkciju neizmanto RFC 1323, jo autori juta, ka ir jāatrisina vairākas tehniskas problēmas, pirms šo risinājumu iekļaut TCP standartā.
22 </li>
23 <li>[[21.04.nodaļā>>21_04]] redzējām, ka daudzas TCP implementācijas mēra vienīgi aprites laiku uz visu logu. Tās nemēra RTT katram segmentam. Lai darbotos LFN'ā, ir vajadzīgi labāki RTT mērījumi.
24 Laikspiedoga opcija, ko aprakstām [[24.5.nodaļā>>24_05]], ļauj vairākiem segmentiem tikt fiksētiem laikā, ieskaitot atkalsūtīšanas.
25 </li>
26 <li>
27 TCP identificē katru baitu ar 32-bitu bezzīmes virknes numuru. Kas var novērst kāda segmenta novēlotu ierašanos pēc tam, kad savienojums, ar kuru tas saistīts ir aizvērts un starp tām pašām mītnēm un portu numuriem izveidots jauns savienojums? Vispirms atcerēsimies, ka TTL lauks IP sākumposmā uzliek augšējo robežu katras IP datagrammas dzīves laikam - 255 lēcieni vai 255 sekundes, atkarībā no tā, kas iestājas vispirms. [[18.06.nodaļā>>18_06]] definējām //maksimālo segmenta dzīvesilgumu// (MSL) kā implementācijas parametru, ko izmanto, lai šāds scenārijs nebūtu iespējams. Ieteicamā MSL vērtība ir 2 minūtes (2MSL ir 240 sekundes). Bet [[18.06.nodaļā>>18_06]] redzējām, ka daudzas implementācijas izmanto MSL vērtību 30 sekundes.
28 </li>
29 <li>
30 LFN'os parādās vēl cita problēma saistībā ar TCP virknes numuriem. Tā kā virknes numuru apgabals ir galīgs, tas pats virknes numurs tiek //atkalizmantots// pēc 4,294,967,296 baitu pārsūtīšanas. Kas notie, ja segments, kurš satur baitu ar virknes numuru N tiek novēlots tīklā un tad vēlāk parādās, kamēr savienojums vēl pastāv? Šāda problēma pastāv tikai tad, ja tas pats virknes numurs N tiek atkalizmantots viena MSL perioda ietvaros, t.i. ja tīkls ir tik ātrs, ka virknes numuru aptīšanās notiek mazākā laikā nekā MSL. Ethernet'ā ir vajadzīgas gandrīz 60 minūtes, lai pārsūtītu tik daudz datu, tādēļ tas nevar gadīties, bet aptīšanai nepieciešamais laiks samazinās, kad pieaug //caurlaidspēja//: T3 telefonu līnija (45 Mb/sec) aptinas pēc 12 minūtēm, FDDI (100 Mb/sec) pēc 5 minūtēm, un gigabitu tīklā (1000 Mb/sec) jau pēc 34 sekundēm. Problēmu šeit rada nevis //caurlaidspējas// un //kavēšanās// reizinājums, bet pati caurlaidspēja. [[24.06.nodaļā>>24_06]] aprakstīsim veidu, kā ar to strādāt: PAWS algoritms (aizsardzība pret virknes numuru aptīšanos), kas izmanto TCP laikspiedoga opciju.
31 </li>
32 </ol>
33 <p/>
34 4.4BSD satur visas šīs opcijas un algoritmus, ko aplūkosim turpmākajās apakšnodaļās: loga mēroga opciju, laikspiedoga opciju un aizsardzību pret //virknes numuru aptīšanos//. Daudzskaitlīgi piegādātāji arī sāk atbalstīt šīs opcijas.
35
36 == Gigabitu tīkli ==
37
38 Kad tīkli sasniedz gigabitu ātrumus, daudzas lietas izmainās. [Partridge 1994] izklāsta gigabitu tīklus detalizēti. Šeit apskatīsim atšķirības starp //novēlošanos// un //joslas platumu//. [Kleinrock 1992].
39 <p/>
40 Aplūkosim viena miljona baitu faila sūtīšanu pāri ASV, pieņemot, ka ir 30 ms novēlošanos. 24.6.attēls parāda divus scenārijus - augšējā ilustrācija izmanto T1 telefona līniju (1,544,000 b/sec) un apakšējā izmanto 1 Gb/sec tīklu. Laiks ir attēlots uz x-ass, kur sūtītājs ir kreisajā pusē, saņēmējs - labajā pusē un kapacitāte atzīmēta uz y-ass. Iekrāsotais laukums abos attēlos apzīmē vienu miljonu baitu, ko vajag nosūtīt.
41 <p/>
42 #pic("f_24_6.gif", "500")
43 //24.6.attēls: 1MB faila nosūtīšana tīklos ar 30 ms novēlošanos//
44 {{/html}}
45 {{/velocity}}
46
47 24.6.attēls parāda abu tīklu stāvokli pēc 30 ms. Abos tīklos pirmais datu bits sasniedz galamērķi pēc 30 ms (novēlošanās), bet T1 tīkla gadījumā caurules kapacitāte ir tikai 5790 baiti, tādēļ 994,210 baiti joprojām gaida pie sūtītāja. Gigabita tīkla kapacitāte turpretī ir 3,750,000 baiti, tātad viss fails izmanto nedaudz vairak par 25% no caurules. Pēdējais bits šajā failā sasniedz saņēmēju 8 ms pēc pirmā bita.
48
49 Pilnais laiks, lai nosūtītu failu pa T1 tīklu ir 5.211 sekundes. Ja mēs šo pašu uzdevumu risinātu ar palielinātu joslas platumu (T3 tīklu ar ātrumu 45,000,000 b/sec), tad kopējais laiks samazinās līdz 0.208 sekundēm. Palielinot joslas platumu par reizinātāju 29, samazina pārsūtīšanas laiku 25 reizes.
50
51 Gigabita tīkla gadījumā kopējais laiks, lai nosūtītu failu ir 0.038 sekundes: 30 ms novēlošanās plus 8 ms faila //nosūtīšanai//. Pieņemsim, ka varētu divreiz palielināt joslas platumu līdz 2 Gb/sec, tad kopīgo laiku varētu samazināt līdz 0.034 sekundēm: tā pati 30 ms novēlošanās plus 4 ms, lai pārsūtītu failu. Dubultojot joslas platumu, samazina pilno pārsūtīšanas laiku tikai par 10%. Pie gigabitu ātrumiem mūs ierobežo novēlošanās nevis joslas platums.
52
53 Novēlošanos izraisa gaismas ātrums un to nevar samazināt. Konstantās novēlošanās iespaids kļūst vēl sliktāks, ja aplūko paketes, kuras izveido un slēdz konekciju. Gigabitu tīkli izraisīs vairākas tīklošanās problēmas, uz ko jāskatās citādi nekā parasti.