Sinkronisasyon ng Orasan sa mga Application — esensya, mga protocol, at implementasyon

Ano ang sinkronisasyon ng orasan?

Sinkronisasyon ng orasan (Clock Sync) — ay ang mekanismo ng pagtutugma ng panloob na orasan ng device sa sangguniang oras na UTC (Universal Coordinated Time). Kung walang sinkronisasyon, ang quartz oscillator sa mobile device ay unti-unting lumilihis — ang drift ay 1–10 segundo bawat araw depende sa temperatura at kalidad ng mga component. Ang sinkronisasyon ay nagko-compensate sa drift na ito sa pamamagitan ng pagkuha ng tumpak na oras mula sa mga external na source: NTP server sa internet, GPS satellite, o cellular base station. Sa ideal na sitwasyon, ang device ay dapat mag-sync bawat 4–6 na oras upang mapanatili ang katumpakan sa loob ng 1 segundo.

Orasan ng hardware at software

Sa mobile device mayroong dalawang uri ng orasan: hardware (RTC, Real-Time Clock) na may hiwalay na power mula sa baterya — patuloy na gumagana kahit naka-off ang device, at software (system time) na pinamamahalaan ng operating system. Sa pagsisimula ng device, ang system time ay initialise mula sa RTC, pagkatapos ay pinapanatili sa pamamagitan ng interrupts ng clock generator. Ang NTP synchronization ay nagwawasto ng system time, at sa ilang kaso — isinusulat ang correction sa RTC din. Sa Android, ang access sa hardware RTC ay limitado — hindi ito mababago ng mga application nang walang root access.

Bakit kailangan ang sinkronisasyon ng oras sa mga mobile application

Maraming aspeto ng paggana ng mobile application ay kritikal na nakadepende sa tumpak na system time. Ang SSL certificate ay may validity period: kung sa device ang oras ay nakatakda bago ang petsa ng pag-isyu ng certificate o pagkatapos ng petsa ng expiration nito, ang HTTPS connection ay mabblock. Ang OAuth token at JWT authentication ay gumagamit ng timestamp para suriin ang validity — ang desinkronisasyon ay humahantong sa maling pagtanggi ng awtorisasyon. Ang push notification ay naka-iskedyul batay sa oras, at kung ang orasan ay lumihis, ang user ay makakatanggap ng notification sa maling oras o hindi talaga makakatanggap.

Mga bunga ng desinkronisasyon

Ang seguridad ng mga application ay naghihirap din dahil sa maling oras: time-based encryption (time-based OTP), event log na may maling timestamp, maling paggana ng rate-limiting sa server side (binablock ng server ang "future" na mga request). Ayon sa OWASP Mobile Top 10 (2024), ang kawalan ng tiwala sa system time ay nasa kategorya ng hindi sapat na seguridad ng platform. Ang mga developer ay pinapayuhan na laging suriin ang oras sa server, hindi lamang umasa sa client clock. Kung ang pagkakaiba ay lumampas sa threshold (inirerekomendang 5 segundo), dapat i-block ng application ang mga kritikal na operasyon hanggang sa mag-sync.

Mga protocol ng sinkronisasyon: NTP at SNTP

Ang mga pangunahing protocol para sa sinkronisasyon ng orasan — NTP at ang pinadaling bersyon nito na SNTP. NTP (RFC 5905) — kumpletong protocol na may filtering ng server, analysis ng drift, at PLL correction. Ginagamit sa mga server at network equipment. SNTP (RFC 4330) — magaan na bersyon para sa client device na hindi nangangailangan ng patuloy na sinkronisasyon. Ang SNTP client ay nagpapadala ng request, tumatanggap ng response, at nagtatakda ng oras nang walang history analysis. Sa mga mobile device, SNTP ang ginagamit — ang built-in na Android Google Time Service (GTS) ay nagsi-sync sa pamamagitan ng SNTP sa mga server na time.google.com.

Mga karagdagang pamamaraan ng sinkronisasyon

Bukod sa NTP/SNTP, ang sinkronisasyon ng oras sa mga mobile device ay posible sa pamamagitan ng GPS receiver (katumpakan hanggang 10 ns sa ideal na kondisyon) at cellular network (sa pamamagitan ng NITZ — Network Identity and Time Zone). Ang GPS ay nagbibigay ng maximum na katumpakan, ngunit gumagana lamang sa labas at kumokonsumo ng maraming enerhiya. Ang NITZ ay awtomatikong ibinibigay ng cellular operator sa pag-register sa network, ngunit hindi lahat ng operator ay sumusuporta dito. Gumagamit ang Android ng kombinasyon ng lahat ng pamamaraan: GTS (SNTP) bilang priyoridad, NITZ bilang backup, at GPS para sa mga application na nangangailangan ng mataas na katumpakan.

Mga problema sa sinkronisasyon sa mga distributed system

Sa mga distributed system — kapag ang server at client ay nasa magkaibang device — ang sinkronisasyon ng orasan ay humaharap sa mga pangunahing limitasyon. Ang network latency ay ginagawang imposible ang tiyak na pagtukoy ng eksaktong oras sa client: kung ang packet ay tumagal ng 200 ms, ang oras sa server sa sandali ng pagpapadala ng request at pagtanggap ng response ay iba na. Nilulutas ng NTP ang problemang ito sa pamamagitan ng RTT measurement at statistical processing, ngunit para sa mga distributed transaction (hal. bank transfer) ito ay hindi sapat — ginagamit ang logical clock (Lamport timestamp) o vector clock.

Physical vs. logical na orasan

Physical clock (wall clock) — ang tunay na UTC time, na nagsi-sync sa pamamagitan ng NTP. Logical clock — mga sequence number ng mga event sa system, hindi nakatali sa physical time. Sa mga distributed system para sa pag-order ng mga event ay kadalasang ginagamit ang vector clock: bawat node ay nag-iimbak ng vector ng mga counter para sa lahat ng node ng cluster. Para sa mga mobile application, sapat na ang physical synchronization na may katumpakan na 1–5 segundo — ito ay nagsisiguro ng tamang paggana ng OAuth, SSL, at push notification. Kung kinakailangan ang mahigpit na pag-order ng mga event (hal. sa real-time chat), idinaragdag ang logical synchronization sa antas ng server.

Implementasyon ng sinkronisasyon ng orasan sa Android

Ang pag-implement ng sinkronisasyon ng orasan sa Android application ay maaaring gawin sa ilang paraan. Ang pinakasimple — kumuha ng server time sa pamamagitan ng REST API: ang server ay nagbabalik ng Unix Timestamp sa body ng response o sa HTTP header na Date. Ang approach na ito ay hindi nangangailangan ng karagdagang library at ginagarantiyang ang oras ay tugma sa server. Ang pangalawang paraan — gumamit ng SNTP client para sa direktang query sa NTP server. Ang pangatlo — umasa sa Android Google Time Service, na awtomatikong nagsi-sync ng system time kung ang device ay konektado sa internet.

Paghahambing ng mga approach para sa Android

Sa mga Android application na may awtorisasyon at financial operations, inirerekomenda ang pinagsamang approach: sa bawat request sa API ay iniimbak ang pagkakaiba sa pagitan ng server time at System.currentTimeMillis(). Ang pagkakaibang ito ay inaaplay sa lahat ng kalkulasyon ng oras sa client, hindi alintana kung ang system clock ay naka-sync o hindi. Ang approach na ito ay tinatawag na clock skew correction at ini-implement sa pamamagitan ng class na nag-iimbak ng huling alam na pagkakaiba sa server. Bukod pa rito, maaaring magpatakbo ng background NTP synchronization bawat 4–6 na oras sa pamamagitan ng WorkManager.

// Pagwawasto ng paglihis ng orasan
class ClockSyncManager {
    private var serverTimeDiff: Long = 0 // serverTime - deviceTime (ms)

    fun updateServerTime(serverTimestampMs: Long) {
        serverTimeDiff = serverTimestampMs - System.currentTimeMillis()
    }

    fun getCorrectedTime(): Long {
        return System.currentTimeMillis() + serverTimeDiff
    }

    fun isSyncValid(maxDiffMs: Long = 5000): Boolean {
        return Math.abs(serverTimeDiff) < maxDiffMs
    }
}

Background synchronization sa pamamagitan ng WorkManager

Para sa pana-panahong background synchronization ng oras sa Android, gamitin ang WorkManager na may PeriodicWorkRequest. Ang synchronization task ay nagsasagawa ng SNTP query o REST API call, tumatanggap ng server time, at nag-a-update ng ClockSyncManager. Ang minimum na interval para sa PeriodicWorkRequest ay 15 minuto, ngunit para sa time synchronization ay sapat na ang 4–6 na oras. Sa panahon ng synchronization, isaalang-alang ang network status — gamitin ang NetworkType.CONNECTED upang maiwasan ang mga hindi kinakailangang request habang roaming. Kung nabigo ang synchronization, panatilihin ang nakaraang correction — ito ay nananatiling valid na may unti-unting bumababang katumpakan.

Awtomatikong sinkronisasyon ng oras sa mga device

Ang mga modernong mobile device ay nag-sync ng oras awtomatiko sa pamamagitan ng mga built-in na serbisyo. Sa Android — Google Time Service (GTS), bahagi ng Google Play Services. Sa iOS — NTP client na naka-embed sa operating system. Ang mga serbisyong ito ay gumagana nang independyente sa mga application at hindi nangangailangan ng karagdagang configuration. Maaaring i-disable ng user ang automatic synchronization sa settings, na lumilikha ng panganib para sa mga application — sa kasong ito, ang developer ay kailangang mag-implement ng sariling synchronization. Inirerekomenda na suriin ang status ng autosync sa pamamagitan ng Settings.Global.getInt(AUTO_TIME) at bigyan ng babala ang user kapag ito ay naka-disable.

Mga rekomendasyon para sa mga developer

Ang pag-asa lamang sa automatic synchronization ay mapanganib — maaaring i-disable ito ng user o nasa zone na walang internet. Pinakamahusay na kasanayan — kunin ang oras mula sa server sa bawat API request at iimbak ang desinkronisasyon sa SharedPreferences o DataStore. Para sa mga kritikal na operasyon (pagbabayad, awtorisasyon, pagpirma ng dokumento) laging suriin ang isSyncValid() bago isagawa. Kung ang desinkronisasyon ay lumampas sa threshold — ipakita sa user ang isang screen na may mungkahi na i-enable ang autosync o maghintay ng synchronization. Para sa mga laro at entertainment application, sapat na ang kumuha ng oras mula sa server sa startup at mag-update bawat oras.