Wiki source code of 24. TCP veiktspēja

Last modified by Valdis Vītoliņš on 2018/01/15 21:44
Show last authors
1 = 24. TCP veiktspēja =
2
3 == 24.01 Ievads ==
4
5 TCP ir daudzus gadus darbojies //datu posmos//, kas ir no 1200 bit/s iezvanpieejas SLIP līdz Ethernet'am. 1980.tajos gados un 1990.to gadu sākumā Ethernet'i bija dominējošais datu posmu veids. Lai gan TCP strādā pareizi arī ātrumos, kas pārsniedz Ethernet'u (T3 telefona līnijās, FDDI un gigabitu tīklos, piemēram), daži TCP ierobežojumi parādās pie šādiem lielākiem ātrumiem.
6
7 Šajā nodaļā aplūkosim dažas TCP modifikācijas, kas ļauj iegūt maksimālu //caurlaidspēju// pie lieliem ātrumiem. Vispirms apskatīsim maršruta MTU atklāšanas mehānismu, ko esam redzējuši šajā grāmatā arī agrāk. Tomēr šoreiz koncentrēsimies uz to, kā tas darbojas ar TCP. Tas bieži ļauj TCP izmantot MTU lielāku par 536 ne-lokāliem savienojumiem, palielinot to caurlaidspēju.
8
9 Mēs pēc tam aplūkojam //garas resnās trubas//, t.i. tīklus, kuriem ir liels //joslas platuma// reizinājums ar //aizturi// un TCP ierobežojumiem, kas ir atrodami šajos tīklos. Aprakstītas divas jaunas TCP opcijas, kas nodarbojas ar garām resnām trubām - loga mēroga opcija (lai palielinātu TCP maksimālo logu virs 65535 baitiem) un //laikpunkta// opciju. Šī otrā opcija ļauj TCP veikt precīzākus RTT mērījumus datu segmentiem un arī dod aizsardzību pret //virkņu numuru aptīšanos//, kas var parādīties pie lieliem ātrumiem. Šīs divas opcijas ir definētas RFC 1323 [Jacobson, Braden, and Borman 1992].
10
11 Aplūkojam arī piedāvāto T/TCP protokolu - TCP modifikāciju datu transakcijām. Transakciju mehānisms komunikācijām nozīmē klienta pieprasījumu, kam seko servera atbilde. Tā ir izplatīta paradigma klienta-servera aprēķiniem. T/TCP mērķis ir samazināt starp abiem galiem apmainīto segmentu skaitu, izvairoties no trīspusējā rokasspiediena un četriem segmentiem, kas parasti vajadzīgi lai aizvērtu savienojumu. Tādā veidā klients saņem servera atbildi vienā RTT plus laiks, kas nepieciešams pieprasījuma apstrādei.
12
13 Kas ir interesanti par šīm jaunajām opcijām - maršruta MTU atklāšanu, loga mēroga opciju, laikpunkta opciju un T/TCP - tās visas ir //atpakaļsavietojamas// ar līdzšinējām TCP implementācijām. Jaunākas sistēmas, kuras ietver šīs opcijas var sadarboties ar vecākām implementācijām. Atskaitot papildu lauku ICMP ziņojumā, ko var lietot maršruta MTU atklāšanā, šīm jaunajām opcijām jābūt implementātām tikai abos komunikācijas galos, kas vēlas gūt no tā labumu. Beigsim šo nodaļu aplūkojot nesen publicētus datus saistībā ar TCP veiktspēju.
14
15 == Vingrinājumi ==
16
17 {{velocity filter="none"}}
18 {{html clean="false" wiki="true"}}
19 * **24.1** Ko nozīmē, ka sistēma nosūta SYN sākuma segmentu ar loga mēroga faktoru 0?
20 * **24.2** Ja ##bsdi## mītne #picref("f_24_7.gif", "24.7.attēlā") atbalstītu loga mēroga opciju, kāda ir sagaidāmā vērtība 16-bitu loga izmēra laukam TCP sākumposmā no ##vangogh## 3.segmentā? Līdzīgi, ja šo opciju lietotu otrajam savienojumam šajā attēlā, kāds būtu reklamētais logs 13.segmentā?
21 * **24.3** Tai vietā, lai fiksētu loga mēroga faktoru, kad izveido konekciju, vai loga mēroga opcija varētu būt definēta, lai parādītos arī, kad mainās mēroga faktors?
22 * **24.4** Pie kāda datu sūtīšanas ātruma //virknes numuru aptīšanās// kļūst par problēmu, pieņemot, ka MSL ir 2 minūtes?
23 * **24.5** PAWS ir definēts darbam ar tikai vienu savienojumu. Kādas izmaiņas būtu jāveic TCP protokolā, lai PAWS izmantotu kā aizstājēju 2MSL gaidīšanai (##TIME_WAIT## stāvoklim)?
24 * **24.6** Mūsu piemērā [[24.4.nodaļas>>24_04]] beigās, kādēļ mūsu ##sock## programma izvadīja saņemtā bufera izmēru pirms nākamās rindiņas (ar IP adresēm un portu numuriem)?
25 * **24.7** Atkārtot aprēķinus caurlaidībai [[24.8.nodaļā>>24_08]], pieņemot, ka MSS ir 1024.
26 * **24.8** Kā laikpunkta opcija ietekmē Karn'a algoritmu ([[21.03.nodaļa>>21_03]])?
27 * **24.9** Ja TCP sūta datus ar SYN segmentu, ko ģenerē "active open" (neizmantojot paplašinājumus, ko aprakstījām [[24.07.nodaļā>>24_07]]), ko saņemošais TCP dara ar šiem datiem?
28 * **24.10** [[24.07.nodaļā>>24_07]] teicām, ka bez T/TCP paplašinājumiem, pat ja "active open" tiek nosūtīts ar datiem un FIN, klienta aizture, saņemot servera atbildi, joprojām ir divreiz lielāka par RTT un SPT summu. Parādīt segmentus, kas to parāda.
29 * **24.11** Atkārtot aprēķinus no [[18.14.vingrinājuma>>18]], pieņemot, ka ir T/TCP atbalsts un Bērlija implementācijai radniecīgās sistēmas atbalsta minimālo RTO vienādu ar 0.5 sekundēm.
30 * **24.12** Ja mēs implementējam T/TCP un mēram transakcijas laiku starp divām mītnēm, ar ko to var salīdzināt, lai novērtētu efektivitāti?
31 {{/html}}
32 {{/velocity}}