Last modified by Valdis Vītoliņš on 2018/01/15 21:44
Show last authors
1 = 24.07. T/TCP - TCP paplašinājums transakcijām =
2
3 TCP nodrošina //virtuālas ķēdes// transporta servisu. TCP konekcijas dzīvescikls sastāv no trim atsevišķām fāzēm - izveidošana, //datu nosūtīšana// un //izbeigšana//. Lietotnes, piemēram attālinātais login's un failu nosūtīšana ir piemēroti virtuālas ķēdes servisam.
4
5 Citas lietotnes tomēr ir veidotas transakciju servisa lietošanai. Transakcija ir klienta pieprasījums, kam seko servera atbilde ar sekojošām īpatnībām:
6
7 1. Savienojuma izveidošanai un izbeigšanai lietoto virstēriņu vajag ierobežot. Kad vien iespējams, nosūta vienu pieprasījuma paketi un saņem vienu atbildes paketi.
8 1. Latentumu jānoved uz RTT+SPT, kur RTT ir //aprites laiks// un SPT ir //servera apstrādes laiks// pieprasījuma apstrādei.
9 1. Serverim ir jāpamana atkārtoti pieprasījumi un nevajag atkārtoti izpildīt //transakciju//, kad ienāk atkārtots pieprasījums. (Izvairīšanās no atkārtojuma nozīmē, ka serveris neapstrādā pieprasījumu atkal. Serveris atsūta agrāk noglabātu atbildi atbilstoši šim ziņojumam.)
10
11 Viena lietotne, ko esam jau redzējuši lietojam šī veida servisu ir //Domēnvārdu Sistēma// ([[14.nodaļa>>14]]), lai gan DNS nerūpējas par īpašu apiešanos ar atkārtotiem pieprasījumiem.
12
13 Mūsdienās lietotņu projektējumā var izvēlēties starp TCP un UDP. TCP piedāvā pārāk daudz iespēju priekš transakcijām, savukārt UDP piedāvā nepietiekami daudz. Parasti lietotnes būvē, izmantojot UDP (lai izvairītos no TCP savienojumu virstēriņa), bet daudzas vēlamās īpašības (//dinamiska noildze// un //atkalsūtīšana//, //pārblīves novēršana//, u.c.) tiek programmēti lietotnē, kur tie jāizgudro ikreiz no jauna.
14
15 Labāks risinājums ir piedāvāt transporta slāni, kurš nodrošina efektīvu transakciju apstrādi. Transakciju protokols, ko aprakstām šajā nodaļā, ir T/TCP. Mūsu apraksts balstīts uz tā definīciju RFC 1379 [Braden 1992b] un [Braden 1992c].
16
17 Vairumam TCP savienojumu vajadzīgi 7 segmenti, lai atvērtu un slēgtu savienojumu (sk. {{velocity filter="none"}}{{html clean="false" wiki="true"}}#picref("f_18_13.gif", "18.13.attēlu"){{/html}}{{/velocity}}). Tiek pievienoti vēl trēs segmenti: viensar pieprasījumu, otrs ar atbildi un ACK iepriekšējam pieprasījumam un trešais - ar ACK atbildei. Ja papildu vadības biti tiek pievienoti segmentiem (t.i. pirmais segments satur SYN klienta pieprasījumu un FIN - klients tomēr redz minimālo virstēriņu kā divkāršs RTT un SPT. (Sūtīt SYN kopā ar datiem un FIN ir likumīgi; cits jautājums - vai pašreizējās TCP implementācijas to pareizi apstrādā.
18
19 Cita problēma ar TCP ir ##TIME_WAIT## stāvoklis un tam vajadzīgais 2MSL gaidīšanas laiks. Kā parādīts [[18.14.vingrinājumā>>18]], tas ierobežo transakciju biežumu starp divām mītnēm līdz apmēram 268 reizēm sekundē.
20
21 Divas modifikācijas, kas nepieciešamas TCP'am, lai apstrādātu transakcijas, ir iespēja izvairīties no //trīskāršā rokasspiediena// un saīsināt ##TIME_WAIT## stāvokli. T/TCP izvairās no trīskāršā rokasspiediena, izmantojot paātrinātu savienojuma atvēršanu:
22
23 1. Algoritms piešķir 32-bitu savienojuma skaitītāja (CC) vērtību savienojumiem, ko tas atver, vai nu aktīvi vai pasīvi. Mītnes CC vērtību piešķir no globāla skaitītāja, ko palielina par 1 katru reizi, kad to lieto.
24 1. Katrs segments starp divām mītnēm, kas izmanto T/TCP, ietver jaunu TCP opciju, ko sauc CC. Šai opcijai ir garums 6 baiti un tā satur sūtītāja 32-bitu CC vērtību attiecīgajam savienojumam.
25 1. Mītne uztur kešu katrai citai mītnei ar pēdējo CC vērtību, kas saņemta pieņemamā SYN segmentā no šīs mītnes.
26 1. Kad saņem CC opciju uz sākotnējo SYN, saņēmējs salīdzina vērtību ar iekešoto vērtību no šī sūtītāja. Ja saņemtais CC ir lielāks nekā iekešotais CC, tad SYN ir jauns un jebkurus datus šajā segmentā padod saņemošajai lietotnei (serverim). Šādu savienojumu sauc par //pussinhronizētu//. Ja saņemtais CC nav lielāks kā iekešotais CC, vai ja saņemošajai mītnei vispār nav iekešots CC priekš šī klienta, tad tiek veikts normāls //trīskāršs rokasspiediens// ar šo klientu.
27 1. SYN, ACK segments atbildot uz sākotnējo SYN atbalso saņemto CC vērtību citā jaunā opcijā, ko sauc CCECHO.
28 1. CC vērtība kādā ne-SYN segmentā nosaka un noraida jebkādus atkārtojošos segmentus no tā paša savienojuma agrākām inkarnācijām.
29
30 //Paātrinātā atvēršana// izvairās no nepieciešamības pēc //trīskāršā rokasspiediena//, izņemot gadījumus, kad vai nu klients vai serveris ir pēc avārijas atsāknēti. Tam ir sava maksa - serverim jāatceras pēdējais CC, kas saņemts no katra klienta.
31
32 ##TIME_WAIT## stāvoklis ir saīsināts, dinamiski rēķinot ##TIME_WAIT##, balstoties uz izmērīto RTT starp divām mītnēm. ##TIME_WAIT## //aizkavējums// tiek uzstādīts 8 reizes RTO, atkalsūtīšanas noildzes vērtība ([[21.3.nodaļa>>21_03]]).
33
34 Izmantojot šīs īpašības, minimālā transakciju virkne ir trīs segmentu apmaiņa:
35
36 1. **Klients serverim:** ar aktīvo savienojuma atvēršanu: klienta SYN, klienta dati (pieprasījums), klienta-FIN un klienta CC. Kad servera TCP ar pasīvo atvēršanu saņem šo segmentu, ja klienta CC ir lielāks nekā iekešotais CC šai klienta mītnei, tad klienta datus padod servera lietotnei, kura apstrādā šo pieprasījumu.
37 1. **Serveris klientam:** servera SYN, servera dati (atbilde), servera FIN, ACK uz klienta FIN, servera CC un CCECHO priekš klienta CC. Tā kā TCP apstiprinājumi ir kumulatīvi, šis ACK uz klienta FIN apstiprina vienlaikus klienta SYN, datus un FIN. Kad klienta TCP saņem šo segmentu, tas padod atbildi klienta lietotnei.
38 1. **Klients serverim:** ACK uz servera FIN, kas apstiprina servera SYN, datus un FIN. Klienta atbildes laiks uz tā pieprasījumu ir RTT plus SPT.
39
40 Ir daudzas smalkas nianses saistībā ar šīs TCP opcijas implementāciju, kas ir aplūkotas literatūras atsaucēs. Piedāvājam īsu kopsavilkumu:
41
42 * Servera SYN, ACK (otrais segments) ir jāaizkavē, lai ļautu servera lietotnes atbildei būt tajā iekļautai. (Parastam TCP protokolam ACK uz SYN netiek aizkavēts.) Tas nedrīkst aizkavēties pārāk ilgi, jo citādi klientam iestāsies noildze un viņš sūtīs pieprasījumu vēlreiz.
43 * Pieprasījumam var būt nepieciešami vairāki segmenti, bet serverim jāvar tikt galā ar šo segmentu iespējamo ierašanos nepareizā secībā. (Parasti, ja dati atnāk pirms SYN, tad šos datus izmet un ģenerē //atstatījumu//. Savukārt T/TCP gadījumā šie nepareizajā secībā ienākušie dati toties ir jāsakrāj rindā.)
44 * API ir jāļauj servera procesam sūtīt datus un aizvērt konekciju vienā operācijā, lai ļautu otrā segmenta FIN'am uzrāpties mugurā atbildei. (Parasta TCP gadījumā lietotne uzrakstītu atbildi, novedot pie datu segmenta nosūtīšanas un pēc tam aizvērtu savienojumu, kas novestu pie FIN nosūtīšanas.)
45 * Klients sūta datus pirmajā segmentā pirms MSS paziņojuma no servera saņemšanas. Lai izvairītos no klienta ierobežošanas ar MSS=536, MSS dotajai mītnei ir jākešo kopā ar tās CC vērtību.
46 * Klients arī sūta datus serverim, nesaņemot //loga reklāmu// no servera. T/TCP ierosina noklusēto loga izmēru - 4096 baitus, un arī iekešot //pārblīves// slieksni attiecīgajam serverim.
47 * Ar minimālo trīs segmentu apmaiņu ir tikai viens RTT, ko var izmērīt katrā virzienā. Turklāt klienta izmērītais RTT ietver servera apstrādes laiku. Tas nozīmē, ka arī nogludināta RTT vērtība un tās //dispersija// arī ir jākešo priekš šī servera, līdzīgi kā aprakstījām [[21.09.nodaļā>>21_09]].
48
49 T/TCP pievilcīgā īpašība ir tā, ka esošam protokolam pielietojot minimālu skaitu izmaiņu, tas ļauj //atpakaļsavietojamību// ar esošajām implementācijām. Tas arī savās interesēs izmanto esošās TCP protokola inženiertehniskās īpašības (dinamiska noildze un atkalsūtīšana, pārblīves novēršana, u.c.) tai vietā, lai liktu aplikācijai nodarboties ar šīm lietām.
50
51 Alternatīvs transakciju protokols ir VMTP - //Daudzveidīgais Ziņojumu Transakciju Protokols//. Tas aprakstīts RFC 1045 [Cheriton 1988]. Atšķirībā no T/TCP, kas ir neliels izmaiņu kopums esošam protokolam, VMTP ir pilns transporta slānis, kurš izmanto IP. VMTP veic kļūdu noteikšanu, atkalsūtīšanu un dublikātu novēršanu. Tas arī atbalsta multiraides saziņu.