Last modified by Valdis Vītoliņš on 2018/01/15 21:44
Show last authors
1 = 06.04. ICMP laikspiedoga pieprasījums un atbilde =
2
3 {{velocity filter="none"}}
4 {{html clean="false" wiki="true"}}
5 {{info}}Linux 2.6 vajadzībām izveidots <a href='/download/GuidesTcpIp/tools/icmptime/'>'icmptime' rīks</a>{{/info}}
6 <p/>
7 ICMP laikspiedoga pieprasījums ļauj vienai sistēmai pavaicāt citai sistēmai pareizu laiku. Ieteicamā atgriežamā vērtība ir milisekunžu skaits kopš pusnakts, Koordinētā universālā laika (UTC). (Vecākas rokasgrāmatas UTC sauc par Griničas vidējo laiku). Patīkamā iezīme šim ICMP ziņojumam ir tā, ka tā nodrošina milisekunžu izšķirtspēju, kamēr dažas citas metodes laika iegūšanai no citas mītnes (piemēram ##rdate## komanda, ko piedāvā dažas UNIX sistēmas) izšķirtspēju dod sekundēs. ICMP laikspiedoga metodes trūkums - tā kā atgrieztais laiks ir kopš pusnakts, izsaucējam pašam ar kādu metodi ir jānosaka pašreizējais laiks. 6.6.attēls parāda ICMP laikspiedoga pieprasījuma un atbildes ziņojuma formātu:
8 <p/>
9 #pic("f_6_6.gif", "500")
10 //6.6.attēls: ICMP laikspiedoga pieprasījuma un atbildes ziņojumi//
11 <p/>
12 Pieprasītājs aizpilda savu sākotnējo laikspiedogu un nosūta ziņojumu. Atbildošā sistēma, kad tā saņem pieprasījumu, aizpilda saņemšanas laikspiedogu, un nosūtīšanas laikspiedogu, kad tā nosūta atbildi. Patiesībā vairumā sistēmu abiem šiem laukiem ir viena un tā pati vērtība. (Visu trīs lauku esamības iemesls ir ļaut sūtītājam aprēķināt laiku pieprasījuma nosūtīšanai un atsevišķi izrēķināt laiku atbildes nosūtīšanai.)
13 <p/>
14 Varam uzrakstīt vienkāršu programmu, ko sauc ##icmptime##, kas sūta ICMP laikspiedoga pieprasījumu uz kādu mītnes datoru un drukā atgriezto atbildi. Vispirms mēģinām to mūsu mazajā internetā:
15
16 {{code language="none"}}
17 sun % icmptime bsdi
18 orig = 83573336, recv = 83573330, xmit = 83573330, rtt = 2 ms
19 difference = -6 ms
20 sun % icmptime bsdi
21 orig = 83577987, recv = 83577980, xmit = 83577980, rtt = 2 ms
22 difference = -7 ms
23 {{/code}}
24
25 Programma drukā trīs laikspiedogus, kas ietverti ICMP ziņojumā - sākuma (originate, orig), saņemšanas (receive, recv) un pārsūtīšanas (transmit, xmit). Kā redzēsim šajā un turpmākajos piemēros, visas mītnes uzstāda saņemšanas un pārsūtīšanas laikposmus uz to pašu vērtību.
26 <p/>
27 Aprēķinām arī //aprites// ceļa laiku (##rtt##), kas ir starpība starp atbildes saņemšanas laiku un pieprasījuma izsūtīšanas laiku. Šī starpība ir saņemšanas brīža laikspiedogs (received timestamp) mīnus sākuma laikspiedogs (originate laikspiedogs. 6.7.attēls parāda attiecības starp šīm vērtībām.
28 <p/>
29 #pic("f_6_7.gif", "500")
30 //6.7.attēls: Attiecības starp vērtībām, ko drukā 'icmptime' programma//
31 {{/html}}
32 {{/velocity}}
33
34 Ja mēs ticam RTT, un pieņemam, ka puse no RTT ir pieprasījuma ceļš, bet otra puse - atbildes ceļš, tad sūtītāja pulksteni vajag izmainīt par starpību mīnus puse no RTT, lai tam būtu tāds pats laiks kā mītnei, kurai sūta pieprasījumu. Iepriekšējā piemērā pulkstenis uz ##bsdi## bija 7 un 8 ms vēlāks nekā pulkstenis uz ##sun##.
35
36 Tā kā laikspiedogu vērtības ir milisekunžu skaits pāri pusnaktij, UTC, tās vienmēr ir mazākas par 86,400,000 (24 x 60 x 60 x 1000). Šos piemērus darbināja īsi pirms 16:00 laika joslā, kas ir 7 stundas vēlāka nekā UTC, tad vērtības tuvu pie 82,800,000 (23.00 stundas) izskatās ticamas
37
38 Ja darbinām šo programmu vairākas reizes uz to pašu mītni ##bsdi##, redzam, ka pēdējais cipars saņemšanas un pārsūtīšanas laikspiedogā vienmēr ir 0. Tas ir tādēļ, ka programmatūras //laidiens// (Versija 0.9.4) nodrošina pulksteni ar 10 ms precizitāti (Šo situāciju sīkāk aprakstīsim [[Pielikumā B>>App_B]].).
39
40 Ja darbinām šo programmu divreiz uz mītni ##svr4## redzam, ka pat trīs jaunāko kārtu cipari ##svr4## laikspiedogos ir vienmēr 0:
41
42 {{code language="none"}}
43 sun % icmptime svr4
44 orig = 83588210, recv = 83588000, xmit = 83588000, rtt = 4 ms
45 difference = -210 ms
46 sun % icmptime svr4
47 orig = 83591547, recv = 83591000, xmit = 83591000, rtt = 4 ms
48 difference = -547 ms
49 {{/code}}
50
51 Kaut kādu iemeslu dēļ ##svr4## nenodrošina nekādu milisekunžu izšķirtspēju, izmantojot ICMP laikspiedogu. Šī neprecizitāte padara aprēķinātās starpības par nederīgām, regulējot pulksteņus līdz milisekunžu vērtībām.
52
53 Ja izmēģinām divas citas mītnes ##140.252.1## apakštīklā, rezultāti parāda, ka viens pulkstenis atšķiras no ##sun## pulksteņa par 3.7 sekundēm, bet otrs - gandrīz par 75 sekundēm:
54
55 {{code language="none"}}
56 sun % icmptime gemini
57 orig = 83601883, recv = 83598140, xmit = 83598140, rtt = 247 ms
58 difference = -3743 ms
59 sun % icmptime aix
60 orig = 83606768, recv = 83532183, xmit = 83532183, rtt = 253 ms
61 difference = -74585 ms
62 {{/code}}
63
64 Cits interesants piemērs ir, sūtot uz maršrutētāja vārteju (Cisco maršrutētāju). Tas parāda, ka tad, ja sistēma atgriež nestandarta laikspiedoga vērtību (kaut ko citu nekā milisekundes kopš UTC pusnakts), tai vajadzētu ieslēgt vecāko bitu 32-bitu laikspiedogā. Mūsu programma to pamana un drukā saņemšanas un nosūtīšanas laikspiedogus leņķiskajās iekavās (pēc vecākā bita izslēgšanas). Gluži tāpat - mēs nevaram aprēķināt atšķirību starp sākuma un saņemšanas laikspiedogiem, jo tie nav izteikti vienās mērvienībās.
65
66 {{code language="none"}}
67 sun % icmptime gateway
68 orig = 83620811, recv = <4871036>, xmit = <4871036>, rtt = 220 ms
69 sun % icmptime gateway
70 orig = 83641007, recv = <4891232>, xmit = <4891232>, rtt = 213 ms
71 {{/code}}
72
73 Ja darbinām savu programmu uz šo mītni vairākas reizes, kļūst redzams, ka atgrieztās vērtības ir ar milisekunžu izšķirtspēju un skaita milisekunžu skaitu kopš kāda atskaites punkta, bet šis atskaites punkts nav UTC pusnakts. (Tas, piemēram, varētu būt skaitītājs, kurš tiek palielināts ik milisekundi kopš maršrutētāja sāknēšanas.).
74
75 Kā beidzamo piemēru mēs salīdzināsim ##sun##'a pulksteni ar sistēmu, kuras pulkstenis ir zināms kā precīzs - NTP stratum 1 serveris. (Par NTP //Tīkla Laika Protokolu// mēs runāsim tālāk).
76
77 {{code language="none"}}
78 sun % icmptime clock.llnl.gov
79 orig = 83662791, recv = 83662919, xmit = 83662919, rtt = 359 ms
80 difference = 128 ms
81 sun % icmptime clock.llnl.gov
82 orig = 83670425, recv = 83670559, xmit = 83670559, rtt = 345 ms
83 difference = 134 ms
84 {{/code}}
85
86 Aprēķinot laika starpību mīnus pusi no RTT, šī izvade norāda, ka pulkstenis uz ##sun##'a visticamāk steidzas par laiku starp 38.5 un 51.5 ms.
87
88 == Alternatīvas ==
89
90 Ir citi veidi, kā iegūt laiku un datumu.
91
92 1. [[1.12.nodaļā>>01_12]] aprakstījām ##daytime## servisu un ##time## servisu. Pirmais atgriež pašreizējo laiku un datumu cilvēkam lasāmā formā, ASCII simbolu virknīti. Varam pārbaudīt šo servisu, izmantojot ##telnet## komandu:
93
94 {{code language="none"}}
95 sun % telnet bsdi daytime
96 Trying 140.252.13.35 ...
97 Connected to bsdi.
98 Escape character is "^]" (3 rindas - Telnet klienta paziņojums)
99 Wed Feb 3 16:38:33 1993 ('daytime' servisa izvade)
100 Connection closed by foreign host. (Telnet klienta paziņojums)
101 {{/code}}
102
103 'time' serveris turpretī atgriež 32-bitu bināru vērtību, kur glabājas sekunžu skaits kopš 1900.g. 1.janvāra, UTC. Lai gan tas ļauj noskaidrot datumu, laika vērtība izteikta sekundēs. (Komanda ##rdate##, ko jau minējām, izmanto šo TCP 'time' servisu)
104
105 1. Nopietni laika mērītāji izmanto //Tīkla Laika Protokolu// (NTP), ko apraksta RFC 1305 [Mills 1992]. Šis protokols izmanto izsmalcinātu tehnoloģiju, lai uzturētu pulksteņus sistēmu grupai LANā vai WANā līdz pat milisekundes precizitātei. Ikviens, kuram interesē precīza laika mērīšana datoros, var izlasīt šo RFC.
106 1. //Atvērtās Programmatūras Fonda// (OSF) //Dalītās Skaitļošanas Vide// (DCE) definē //Dalīto Laika Servisu// (DTS), kas arī nodrošina pulksteņu sinhronizēšanu starp datoriem. [Rosenberg, Kenney, and Fisher 1992] detalizēti apraksta šo servisu.
107 1. Bērklija UNIX'a sistēmas nodrošina //dēmonu// ##timed(8)##, lai sinhrinizētu pulksteņus sistēmām //lokālajā tīklā//. Atšķirībā no NTP un DTS, ##timed## nestrādā //lielizmēra tīklos//.