Wiki source code of 24.05. Laikspiedoga opcija

Last modified by Valdis Vītoliņš on 2018/01/15 21:44
Show last authors
1 = 24.05. Laikspiedoga opcija =
2
3 Laikspiedoga opcija ļauj sūtītājam ievietot laikspiedoga vērtību ikvienā segmentā. Saņēmējs atspoguļo šo vērtību //apstiprinājumā//, ļaujot sūtītājam aprēķināt //aprites laiku// (RTT) katram saņemtam apstiprinājumam. (Mēs šeit sakām "katram saņemtam apstiprinājumam (ACK'am)", nevis "katram segmentam", jo TCP parasti apstiprina vairākus segmentus ar vienu ACK'u.) Daudzas esošās implementācijas mēra vienīgi RTT uz visu logu, kas ir pietiekami logiem, kuri satur astoņus segmentus. Lielāki logu izmēri tomēr prasa labākus RTT aprēķinus.
4
5 RFC 1323 3.1.nodaļa izklāsta signālu apstrādes iemeslus, lai prasītu labākus RTT novērtējumus lielākiem logiem. Galvenokārt RTT tiek mērīts, //iztverot// datu signālu (datu segmentus) zemākā frekvencē (vienreiz uz visu logu). Tas ievieš atsauces nevis uz īsto RTT, bet uz RTT novērtējumu. Tad, ja logā ir tikai astoņi segmenti, iztvēruma biežums ir viena astotā daļa no datu biežuma, kas ir izturami. Savukārt, ja ir 100 segmenti uz vienu logu, tad iztvēruma biežums ir 1/100 no datu biežuma. Tas var izraisīt RTT novērtējumu neprecizitātes, kas noved pie nevajadzīgas //atkalsūtīšanas//. Ja segments pazūd, kļūst vēl sliktāk.
6
7 {{velocity filter="none"}}
8 {{html clean="false" wiki="true"}}
9 #picref("f_18_20.gif", "18.20.attēls") parādīja laikspiedoga opcijas formātu. Sūtītājs novieto 32 bitu vērtību pirmajā laukā, un saņēmējs atbalso to savā atbildes laukā. TCP sākumposmi, kuri satur šo opciju pieaugs no parastajiem 20 baitiem līdz 32 baitiem.
10 <p/>
11 Laikspiedogs ir monotoni pieaugoša vērtība. Tā kā saņēmējs atbalso to, ko tas ir saņēmis, saņēmējam ir vienalga, kādas ir laikspiedoga mērvienības. Šī opcija neprasa nekāda veida pulksteņu sinhronizāciju starp abām mītnēm. RFC 1323 ieteic, laikspiedoga vērtību palielināt par 1 ik pēc 1ms vai ik pēc 1s (vai arī izvēlēties kādu citu mērvienību, kas ir starp milisekundi un sekundi).
12 <p/>
13 4.4BSD palielina laikspiedoga skaitītāju ik pēc 500 milisekundēm un šo laikspiedoga pulksteni //nomet// uz 0 pēc atsāknēšanas.
14 <p/>
15 #picref("f_24_7.gif", "24.7.attēlā"), ja aplūkojam laikspiedogu 1.segmentā un laikspiedogu 11.segmentā, starpība (89 vienības), pieņemot 500 ms uz vienību, atbilst laika atstarpei 44.5 sekundes.
16 <p/>
17 Šīs opcijas norādīšana savienojuma veidošanas brīdī tiek apstrādāta tāpat kā loga mērogošanas opcija iepriekšējā nodaļā. Savienojuma gals, kurš veic //aktīvo atvēršanu// norāda opciju savā SYN. Tikai tad, ja tas saņem šo opciju SYN segmentā, kas sūtīts no otra gala, šo opciju var sūtīt arī turpmākos segmentos.
18 <p/>
19 Esam redzējuši, ka saņemošajam TCP nav jāapstiprina katrs datu segments, kuru tas saņem. Daudzas implementācijas sūta ACK'u uz katru otro datu segmentu. Ja saņēmējs sūta ACK'u, kas apstiprina uzreiz divus saņemtus datu segmentus, kuru no abiem saņemtajiem laikspiedogiem būtu jāsūta atpakaļ atbildē, norādot laikspiedoga atbalsi?
20 <p/>
21 Lai samazinātu uzturamo stāvokli abos galos, katram savienojumam tiek uzturēta tikai viena laikspiedoga vērtība. Algoritms, ar kuru izvēlas, kad //pārlabot// šo vērtību ir vienkāršs:
22
23 1. TCP fiksē laikspiedoga vērtību, kuru sūtīt nākamajā ACK'ā (mainīgais, ko sauc ##tsrecent##) un apstiprinājuma virknes numuru no pēdējā ACKa, kas tika nosūtīts (mainīgais, ko sauc ##lastack##). Šis virknes numurs ir nākamais virknes numurs, kuru sagaida saņēmējs.
24 1. Kad ierodas kārtējais segments, ja šis segments satur baitu, kura numurs ir ##lastack##, tad laikspiedoga vērtību no segmenta noglabā ##tsrecent##.
25 1. Allaž, nosūtot laikspiedoga opciju, ##tsrecent## tiek izmantots kā laikspiedoga atbalss vērtība, un virknes numura lauks tiek noglabāts mainīgajā ##lastack##.
26 <p/>
27 Algoritms apstrādā sekojošus divus gadījumus:
28 <p/>
29 <ol>
30 <li>Ja saņēmējs aizkavēja ACK'us, atbalss laikspiedoga vērtība atbildīs agrākajam no apstiprināmajiem segmentiem.
31 Piemēram, ja ierodas divi segmenti, kuri satur attiecīgi baitus 1-1024 un 1025-2048 kuriem abiem ir laikspiedoga opcija un saņēmējs apstiprina tos abus ar ACK 2049, tad laikspiedogs šajā ACK'ā būs vērtība no pirmā segmenta, kurš saturēja baitus 1-1024. Tas ir pareizi, jo sūtītājam ir jāaprēķina //atkalsūtīšanas// //noildze//, ņemot vērā aizkavētos ACK'us.
32 </li>
33 <li>Ja saņemtais segments ir loga iekšienē bet ārpus virknes numuru secības (netieši norādot, ka iepriekšējais segments ir pazudis), tad gadījumā, ja šis pazudušais segments tiek saņemts, tiks atbalsots tieši pazudušā segmenta laikspiedogs, nevis laikspiedogs segmentam, kurš pienāca ārpus numuru secības.
34 Piemēram, pieņemsim, ka trīs segmenti, katrs pa 1024 baitiem, tiek saņemti sekojošā kārtībā: 1.segments ar baitiem 1-1024, 3.segments ar baitiem 2049-3072, un visbeidzot 2.segments ar baitiem 1025-2048. ACK'i, ko sūta atpakaļ būs ACK 1025 ar laikspiedogu no 1.segmenta (normāls ACK's gaidītajiem datiem), vēl viens ACK 1025 ar laikspiedogu no 1.segmenta (ACK'a dublikāts atbildot uz loga iekšienē bet ārpus virknes numuriem saņemtu segmentu), visbeidzot 3073 ar laikspiedogu no 2.segmenta (nevis no pēdējā - 3.segmenta). Tas izraisa RTT //paaugstinātu novērtējumu//, kad segmenti pazūd, kas ir labāk nekā //pazemināts novērtējums//. Turklāt, ja pēdējais ACK's saturētu laikspiedogu no 3.segmenta, tas varētu ietvert laiku, kas vajadzīgs atkārtota ACK'a atgriešanai un 2.segmenta atkalsūtīšanai, vai arī tas var iekļaut laiku sūtītāja atkalsūtīšanas noildzei, kas nozīmē 2.segmenta //izbeigšanos//. Abos gadījumos 3.segmenta laikspiedoga atbalsošana varētu radīt tendenciozitāti sūtītāja RTT aprēķinos.</li>
35 </ol>
36 {{/html}}
37 {{/velocity}}
38
39 Lai gan laikspiedoga opcija ļauj veikt labākus //aprites laika// (RTT) aprēķinus, tas arī dod iespēju saņēmējam izvairīties no veciem segmentiem un sākt nepareizi uzskatīt tos par daļu no eksistējošiem datu segmentiem. Nākošā nodaļa to apraksta.