Protokol QUIC pisan pikaresepeun pikeun ditonton, naha urang resep nyerat ngeunaan éta. Tapi upami publikasi sateuacana ngeunaan QUIC langkung seueur tina sajarah (sajarah lokal, upami anjeun resep) alam sareng hardware, ayeuna kami resep nyebarkeun tarjamahan tina jinis anu béda - urang bakal ngobrol ngeunaan aplikasi nyata protokol dina 2019. Leuwih ti éta, urang teu ngawangkong ngeunaan infrastruktur leutik dumasar kana nu disebut garasi, tapi ngeunaan Uber, nu ngoperasikeun ampir sakuliah dunya. Kumaha insinyur perusahaan nyandak kaputusan pikeun ngagunakeun QUIC dina produksi, kumaha aranjeunna ngalaksanakeun tés sareng naon anu aranjeunna tingali saatos ngagulung dina produksi - di handap potongan.
Gambar tiasa diklik. Senang maca!
Uber ngagaduhan skala global, nyaéta 600 kota anu aya, anu masing-masing aplikasina ngandelkeun Internét nirkabel tina langkung ti 4500 operator sélulér. Pamaké ngaharepkeun aplikasi éta henteu ngan gancang, tapi sacara real waktos - pikeun ngahontal ieu, aplikasi Uber peryogi latency anu rendah sareng sambungan anu tiasa dipercaya. Alas, tapi tumpukan henteu saé dina jaringan nirkabel anu dinamis sareng rawan kaleungitan. Urang sadar yén dina hal ieu, kinerja low langsung patali jeung palaksanaan TCP dina kernels sistem operasi.
Pikeun ngajawab masalah, urang nerapkeun , protokol multiplexing channel modern nu mere kami kontrol leuwih kinerja protokol angkutan. Ayeuna grup gawé standardizes QUIC salaku .
Saatos uji éksténsif, kami nyimpulkeun yén ngalaksanakeun QUIC dina aplikasi kami bakal ngahasilkeun latensi buntut anu langkung handap dibandingkeun TCP. Kami ningali pangurangan dina kisaran 10-30% pikeun lalu lintas HTTPS dina aplikasi supir sareng panumpang. QUIC ogé masihan kami kontrol tungtung-ka-tungtung kana bungkusan pangguna.
Dina artikel ieu, urang bagikeun pangalaman urang dina ngaoptimalkeun TCP pikeun aplikasi Uber ngagunakeun tumpukan nu ngarojong QUIC.
Téknologi panganyarna: TCP
Kiwari, TCP mangrupikeun protokol angkutan anu paling sering dianggo pikeun ngirim lalu lintas HTTPS dina Internét. TCP nyayogikeun aliran bait anu tiasa dipercaya, ku kituna ngatasi kamacetan jaringan sareng karugian lapisan tautan. Panggunaan TCP sacara luas pikeun lalu lintas HTTPS disababkeun ku ayana ubiquity baheula (ampir unggal OS ngandung TCP), kasadiaan dina kalolobaan infrastruktur (sapertos penyeimbang beban, proxy HTTPS sareng CDN), sareng fungsionalitas out-of-the-box anu sayogi. dina ampir sabagéan ageung platform sareng jaringan.
Seuseueurna pangguna nganggo aplikasi kami dina perjalanan, sareng latensi buntut TCP teu aya caket kana tungtutan lalu lintas HTTPS sacara real-time. Kantun nempatkeun, pamaké di sakuliah dunya geus ngalaman ieu - Gambar 1 nembongkeun reureuh di kota utama:
Gambar 1: Latensi buntut béda-béda di kota-kota utama Uber.
Sanajan latency dina jaringan India jeung Brasil leuwih luhur batan di AS jeung Inggris, latency buntut nyata leuwih luhur ti latency rata. Sareng ieu leres bahkan pikeun AS sareng Inggris.
TCP leuwih kinerja hawa
TCP dijieun pikeun maké kabel jaringan, nyaeta, kalawan tekenan kana Tumbu kacida bisa diprediksi. Tapi, nirkabel jaringan boga ciri jeung kasusah sorangan. Kahiji, jaringan nirkabel rentan karugian kusabab gangguan sareng atenuasi sinyal. Contona, jaringan Wi-Fi sénsitip kana gelombang mikro, bluetooth sareng gelombang radio anu sanés. Jaringan sélulér kakurangan tina leungitna sinyal () alatan pantulan/nyerep sinyal ku objék jeung wangunan, kitu ogé ti ti tatangga . Ieu ngakibatkeun leuwih signifikan (4-10 kali) jeung leuwih rupa-rupa sarta leungitna pakét dibandingkeun sambungan kabel.
Pikeun merangan fluctuations rubakpita jeung karugian, jaringan sélulér ilaharna ngagunakeun panyangga badag pikeun bursts lalulintas. Ieu bisa ngakibatkeun antrian kaleuleuwihan, nu hartina reureuh leuwih panjang. Mindeng pisan TCP ngarawat antrian ieu salaku runtah alatan hiji timeout nambahan, jadi TCP condong relay sahingga ngeusian panyangga. Masalah ieu katelah (), sareng ieu pisan Internét modern.
Tungtungna, kinerja jaringan sélulér béda-béda dumasar pamawa, daérah, sareng waktos. Dina Gambar 2, urang ngumpulkeun median reureuh lalulintas HTTPS sakuliah sél dina rentang 2-kilométer. Data dikumpulkeun pikeun dua operator sélulér utama di Cirebon, India. Sakumaha anjeun tiasa tingali, kinerja beda-beda ti sél ka sél. Ogé, produktivitas hiji operator béda ti produktivitas kadua. Hal ieu dipangaruhan ku faktor-faktor sapertos pola éntri jaringan anu merhatikeun waktos sareng lokasi, mobilitas pangguna, ogé infrastruktur jaringan kalayan ngitung kapadetan menara sareng rasio jinis jaringan (LTE, 3G, jsb.).
Gambar 2. Tunda maké radius 2 km sabagé conto. Cirebon, India.
Ogé, kinerja jaringan sélulér béda-béda dina waktosna. Gambar 3 nembongkeun latency median ku poé dina saminggu. Kami ogé ningali bédana dina skala anu langkung alit, dina sadinten sareng jam.
angka 3. reureuh buntut bisa rupa-rupa nyata antara poé, tapi pikeun operator sarua.
Sadayana di luhur nyababkeun kinerja TCP teu epektip dina jaringan nirkabel. Nanging, sateuacan milarian alternatip pikeun TCP, kami hoyong ngembangkeun pamahaman anu tepat dina hal-hal ieu:
- Naha TCP mangrupikeun penjahat utama tukangeun latén buntut dina aplikasi kami?
- Naha jaringan modéren gaduh telat babak-trip (RTT) anu signifikan sareng variatif?
- Naon dampak RTT sareng karugian dina kinerja TCP?
Analisis Performance TCP
Pikeun ngartos kumaha urang nganalisa kinerja TCP, hayu urang tingali kumaha TCP mindahkeun data tina pangirim ka panarima. Kahiji, pangirim nyieun sambungan TCP, ngajalankeun tilu arah : Pangirim ngirim pakét SYN, ngantosan pakét SYN-ACK ti panarima, lajeng ngirim pakét ACK. Hiji tambahan kadua jeung katilu lolos spent ngadegkeun sambungan TCP. Panarima ngaku resi unggal pakét (ACK) pikeun mastikeun pangiriman anu dipercaya.
Upami pakét atanapi ACK leungit, pangirim ngirimkeun deui saatos waktosna (RTO, ). RTO diitung dinamis dumasar kana rupa-rupa faktor, saperti ekspektasi reureuh RTT antara pangirim jeung panarima.
angka 4. bursa Packet leuwih TCP / TLS ngawengku mékanisme retransmission.
Pikeun nangtukeun kumaha TCP dipigawé dina aplikasi urang, urang ngawas pakét TCP ngagunakeun salila saminggu dina lalulintas tempur datang ti server ujung India. Kami teras nganalisis sambungan TCP nganggo . Salaku tambahan, kami nyiptakeun aplikasi Android anu ngirimkeun lalu lintas anu ditiru ka server uji, niru lalu lintas nyata sabisa-bisa. Smartphone sareng aplikasi ieu disebarkeun ka sababaraha karyawan, anu ngumpulkeun log salami sababaraha dinten.
Hasil duanana percobaan éta konsisten saling. Urang nempo latencies RTT tinggi; nilai buntut ampir 6 kali leuwih luhur ti nilai median; rata arithmetic of reureuh leuwih ti 1 detik. Seueur sambungan anu leungit, nyababkeun TCP ngirimkeun deui 3,5% tina sadaya pakét. Di daérah anu rame sapertos bandara sareng stasion karéta, urang ningali karugian 7%. Hasil ieu matak ragu kana hikmah konvensional anu dianggo dina jaringan sélulér nyata ngurangan karugian dina tingkat angkutan. Di handap ieu hasil tés tina aplikasi "simulator":
métrik jaringan
Éta nilai
RTT, milidetik [50%,75%, 95%,99%]
[350, 425, 725, 2300]
RTT divergénsi, detik
Rata-rata ~1,2 s
Leungitna pakét dina sambungan anu teu stabil
Rata-rata ~3.5% (7% di daérah anu kabeuratan)
Ampir satengah tina sambungan ieu miboga sahanteuna hiji leungitna pakét, lolobana aranjeunna SYN na SYN-ACK pakét. Paling palaksanaan TCP ngagunakeun nilai RTO 1 detik pikeun pakét SYN, nu naek éksponénsial pikeun karugian saterusna. Waktos ngamuat aplikasi tiasa ningkat kusabab TCP nyandak waktos langkung lami pikeun ngadamel sambungan.
Dina kasus pakét data, nilai RTO anu luhur pisan ngirangan panggunaan jaringan anu kapaké ku ayana karugian saheulaanan dina jaringan nirkabel. Kami mendakan yén rata-rata waktos pangiriman deui kirang langkung 1 detik kalayan jeda buntut ampir 30 detik. Latensi tinggi ieu dina tingkat TCP nyababkeun waktosna HTTPS sareng pamundut ulang, salajengna ningkatkeun latency sareng inefficiency jaringan.
Nalika persentil ka-75 tina RTT anu diukur sakitar 425 mdet, persentil ka-75 pikeun TCP ampir 3 detik. Ieu nunjukkeun yén karugian nyababkeun TCP nyandak 7-10 pas pikeun suksés ngirimkeun data. Ieu tiasa janten akibat tina itungan RTO anu teu cekap, henteu mampuh TCP pikeun gancang ngabales karugian dina jandela jeung inefficiency tina algoritma kontrol kamacetan, nu teu ngabedakeun antara karugian nirkabel jeung karugian alatan kamacetan jaringan. Di handap ieu hasil tés leungitna TCP:
TCP pakét leungitna statistik
ajen
Persentase sambungan kalayan sahenteuna 1 pakét leungitna
45%
Persentase sambungan sareng karugian salami setelan sambungan
30%
Persentase sambungan jeung karugian salila bursa data
76%
Distribusi telat dina retransmission, detik [50%, 75%, 95%,99%] [1, 2.8, 15, 28]
Distribusi jumlah retransmissions pikeun hiji pakét atawa bagéan TCP
[1,3,6,7]
Aplikasi tina QUIC
Asalna dikembangkeun ku Google, QUIC mangrupikeun protokol angkutan modern multi-threaded anu dijalankeun di luhur UDP. Ayeuna QUIC aya dina (Kami parantos nyerat yén aya, saolah-olah, dua vérsi QUIC, panasaran – kira-kira. penerjemah). Ditémbongkeun saperti dina Gambar 5, QUIC disimpen dina HTTP / 3 (dina kanyataanana, HTTP / 2 on luhureun QUIC nyaeta HTTP / 3, nu ayeuna keur intensif standardized). Éta sawaréh ngagentos lapisan HTTPS sareng TCP ku ngagunakeun UDP pikeun ngabentuk pakét. QUIC ngan ukur ngadukung transfer data anu aman sabab TLS parantos diwangun kana QUIC.
Gambar 5: QUIC dijalankeun dina HTTP / 3, ngagentos TLS, anu sateuacana dijalankeun dina HTTP / 2.
Di handap ieu mangrupikeun alesan anu ngayakinkeun kami pikeun ngagunakeun QUIC pikeun amplifikasi TCP:
- 0-RTT ngadegkeun sambungan. QUIC ngamungkinkeun pamakéan deui otorisasina tina sambungan saméméhna, ngurangan jumlah sasalaman kaamanan. Dina mangsa nu bakal datang bakal ngarojong 0-RTT, tapi sasalaman TCP tilu arah masih bakal diperlukeun.
- nungkulan blocking HoL. HTTP/2 ngagunakeun hiji sambungan TCP per klien pikeun ngaronjatkeun kinerja, tapi ieu bisa ngakibatkeun HoL (head-of-line) blocking. QUIC nyederhanakeun multiplexing sareng ngirimkeun pamundut ka aplikasi sacara mandiri.
- kontrol kamacetan. QUIC resides dina lapisan aplikasi, sahingga leuwih gampang pikeun ngapdet algoritma angkutan utama nu ngatur ngirim dumasar kana parameter jaringan (jumlah karugian atawa RTT). Paling palaksanaan TCP ngagunakeun algoritma , nu teu optimal pikeun lalulintas latency-sénsitip. Algoritma anu nembe dikembangkeun sapertos , leuwih akurat model jaringan jeung ngaoptimalkeun latency. QUIC ngamungkinkeun anjeun ngagunakeun BBR sareng ngapdet algoritma ieu nalika dianggo. .
- replenishment tina karugian. QUIC nelepon dua TLPs () saméméh RTO dipicu - sanajan karugian pisan noticeable. Ieu béda ti palaksanaan TCP. TLP ngirimkeun deui utamina pakét anu terakhir (atanapi anu énggal, upami aya) pikeun memicu replenishment gancang. Nanganan telat buntut hususna kapaké pikeun cara Uber ngoperasikeun jaringanna, nyaéta pikeun mindahkeun data anu pondok, sporadis, sareng sénsitip latency.
- ACK dioptimalkeun. Kusabab unggal pakét gaduh nomer sekuen anu unik, teu aya masalah pakét nalika aranjeunna dikirimkeun deui. pakét ACK ogé ngandung waktu pikeun ngolah pakét jeung ngahasilkeun hiji ACK di sisi klien. Fitur ieu mastikeun yén QUIC ngitung RTT langkung akurat. ACK di QUIC ngarojong nepi ka 256 pita , nulungan pangirim jadi leuwih tahan banting kana pakét shuffling tur ngagunakeun pangsaeutikna bait dina prosés. ACK selektif () dina TCP teu ngajawab masalah ieu dina sakabeh kasus.
- migrasi sambungan. Sambungan QUIC diidentipikasi ku ID 64-bit, janten upami klien ngarobih alamat IP, ID sambungan anu lami tiasa dianggo dina alamat IP énggal tanpa gangguan. Ieu mangrupikeun prakték anu umum pisan pikeun aplikasi sélulér dimana pangguna ngalih antara Wi-Fi sareng sambungan sélulér.
Alternatif pikeun QUIC
Kami nganggap pendekatan alternatif pikeun ngarengsekeun masalah sateuacan milih QUIC.
Hal kahiji anu urang usahakeun nyaéta nyebarkeun TPC PoPs (Points of Presence) pikeun ngeureunkeun sambungan TCP anu langkung caket ka pangguna. Intina, PoPs ngeureunkeun sambungan TCP sareng alat sélulér anu langkung caket kana jaringan sélulér sareng proksi lalu lintas deui ka infrastruktur aslina. Ku terminating TCP ngadeukeutan, urang berpotensi ngurangan RTT tur mastikeun yén TCP leuwih responsif kana lingkungan nirkabel dinamis. Nanging, percobaan kami nunjukkeun yén kalolobaan RTT sareng karugian asalna tina jaringan sélulér sareng panggunaan PoP henteu masihan perbaikan kinerja anu signifikan.
Urang ogé nempo tuning parameter TCP. Nyetél tumpukan TCP dina pangladén ujung hétérogén urang hésé sabab TCP gaduh palaksanaan anu béda-béda dina vérsi OS anu béda. Hese pikeun nerapkeun ieu sareng nguji konfigurasi jaringan anu béda. Ngonpigurasikeun TCP langsung dina alat sélulér teu mungkin kusabab kurangna idin. Anu langkung penting, fitur sapertos sambungan 0-RTT sareng prediksi RTT anu ningkat penting pisan pikeun arsitéktur protokol, sareng ku kituna henteu mungkin pikeun ngahontal kauntungan anu signifikan ku cara nyetél TCP nyalira.
Tungtungna, kami dievaluasi sababaraha protokol basis UDP anu troubleshoot video streaming-urang hayang ningali lamun protokol ieu bakal mantuan dina kasus urang. Hanjakalna, aranjeunna parah kakurangan dina seueur setélan kaamanan, sareng ogé peryogi sambungan TCP tambahan pikeun metadata sareng inpormasi kontrol.
Panaliti kami nunjukkeun yén QUIC mangrupikeun hiji-hijina protokol anu tiasa ngabantosan masalah lalu lintas Internét, bari tumut kana kaamanan sareng kinerja.
Integrasi QUIC kana platform
Pikeun suksés napelkeun QUIC jeung ningkatkeun kinerja aplikasi dina lingkungan konektipitas goréng, urang ngaganti tumpukan heubeul (HTTP/2 leuwih TLS/TCP) jeung protokol QUIC. Kami nganggo perpustakaan jaringan ti , nu ngandung aslina, versi Google tina protokol - gQUIC. Palaksanaan ieu ogé terus ditingkatkeun pikeun nuturkeun spésifikasi IETF panganyarna.
Urang mimiti ngahijikeun Cronet kana aplikasi Android urang pikeun nambihan dukungan pikeun QUIC. Integrasi dilaksanakeun ku cara pikeun ngirangan biaya migrasi sabisa-bisa. Gantina sagemblengna ngaganti tumpukan jejaring heubeul nu dipaké perpustakaan , kami geus terpadu Cronet UNDER kerangka API OkHttp. Ku ngalakukeun integrasi ku cara ieu, urang ngahindarkeun parobihan kana telepon jaringan urang (anu dianggo ku ) dina tingkat API.
Sarupa jeung pendekatan pikeun alat Android, urang nerapkeun Cronet kana aplikasi Uber dina ios, intercepting lalulintas HTTP tina jaringan. ngagunakeun . Abstraksi ieu, disayogikeun ku Yayasan ios, nanganan data URL khusus protokol sareng mastikeun yén urang tiasa ngahijikeun Cronet kana aplikasi ios urang tanpa biaya migrasi anu signifikan.
Ngarengsekeun QUIC dina Google Cloud Balancers
Di sisi backend, parantosan QUIC disayogikeun ku infrastruktur balancing Google Cloud Load, anu ngagunakeun headers dina respon pikeun ngarojong QUIC. Sacara umum, balancer nambihan lulugu alt-svc ka unggal pamundut HTTP, sarta ieu geus validates rojongan QUIC pikeun domain nu. Nalika klien Cronet nampi réspon HTTP sareng lulugu ieu, éta ngagunakeun QUIC pikeun pamundut HTTP anu salajengna ka domain éta. Sakali balancer ngalengkepan QUIC, infrastruktur urang eksplisit ngirimkeun aksi ieu ngaliwatan HTTP2/TCP ka puseur data urang.
Performance: Hasil
Kinerja kaluaran mangrupikeun alesan utama pikeun milarian protokol anu langkung saé. Pikeun dimimitian ku, urang dijieun stand kalawan pikeun manggihan kumaha QUIC bakal kalakuanana dina propil jaringan béda. Pikeun nguji kinerja QUIC dina jaringan dunya nyata, urang ngajalankeun ékspérimén bari nyetir sabudeureun New Delhi ngagunakeun lalulintas jaringan emulated sarupa pisan jeung panggero HTTP dina aplikasi panumpang.
Ékspérimén 1
Alat pikeun percobaan:
- nguji alat Android kalawan OkHttp na Cronet tumpukan pikeun mastikeun yén kami ngidinan lalulintas HTTPS leuwih TCP jeung QUIC mungguh;
- server emulation basis Java nu ngirimkeun tipe sarua headers HTTPS dina réspon jeung beban alat klien pikeun nampa requests ti aranjeunna;
- proxy awan anu lokasina fisik deukeut ka India pikeun ngeureunkeun sambungan TCP jeung QUIC. Sedengkeun pikeun terminasi TCP kami ngagunakeun proxy sabalikna on , hese neangan proxy sabalikna open source pikeun QUIC. Kami ngawangun proxy sabalikna pikeun QUIC sorangan nganggo tumpukan QUIC dasar tina Chromium sareng kana kromium salaku open source.
Gambar 6. TCP vs QUIC jalan test suite diwangun ku alat Android kalawan OkHttp na Cronet, proxy awan pikeun terminating sambungan, sarta server emulation.
Ékspérimén 2
Nalika Google dijieun QUIC sadia kalawan , kami nganggo inventaris anu sami, tapi kalayan hiji modifikasi: tinimbang NGINX, kami nyandak Google load balancers pikeun ngeureunkeun sambungan TCP sareng QUIC tina alat-alat, ogé pikeun rute lalu lintas HTTPS ka server emulation. Balancers disebarkeun di sakuliah dunya, tapi nganggo server PoP pangdeukeutna ka alat (hatur nuhun kana geolocation).
Gambar 7. Dina percobaan kadua, urang hayang ngabandingkeun latency parantosan TCP jeung QUIC: ngagunakeun Google Cloud sarta ngagunakeun proxy awan urang.
Hasilna, sababaraha wahyu ngantosan urang:
- terminasi via PoP ningkat kinerja TCP. Kusabab balancers ngeureunkeun sambungan TCP ngadeukeutan ka pamaké sarta pohara dioptimalkeun, ieu ngakibatkeun RTT handap, nu ngaronjatkeun kinerja TCP. Sareng sanaos QUIC kirang kapangaruhan, éta tetep langkung saé TCP dina hal ngirangan latency buntut (ku 10-30 persen).
- buntutna kapangaruhan . Sanaos proksi QUIC kami langkung tebih tina alat (sakitar 50 ms latensi langkung luhur) tibatan penyeimbang beban Google, éta nyayogikeun kinerja anu sami - pangurangan 15% dina latency versus pangurangan 20% dina persentil ka-99 pikeun TCP. Ieu nunjukkeun yén transisi mil panungtungan nyaéta bottleneck dina jaringan.
Gambar 8: Hasil tina dua percobaan nunjukkeun yén QUIC sacara signifikan ngaleuwihan TCP.
lalulintas ngempur
Diideuan ku ékspérimén, kami parantos ngalaksanakeun dukungan QUIC dina aplikasi Android sareng ios kami. Kami ngalaksanakeun tés A/B pikeun nangtukeun dampak QUIC di kota tempat Uber beroperasi. Sacara umum, urang ningali pangurangan anu signifikan dina telat buntut dina dua daérah, operator telekomunikasi sareng jinis jaringan.
Grafik di handap ieu nunjukkeun paningkatan persentase buntut (95 sareng 99 persentil) dumasar kana daérah makro sareng jinis jaringan anu béda - LTE, 3G, 2G.
Angka 9. Dina tés perang, QUIC ngaleuwihan TCP dina hal latency.
Ngan ukur maju
Panginten ieu mangrupikeun awal - sékrési QUIC kana produksi parantos nyayogikeun kasempetan anu luar biasa pikeun ningkatkeun kinerja aplikasi dina jaringan anu stabil sareng teu stabil, nyaéta:
Ngaronjatkeun cakupan
Saatos nganalisa kinerja protokol dina lalu lintas nyata, kami ningali yén sakitar 80% sesi parantos suksés ngagunakeun QUIC pikeun всех requests, bari 15% tina sesi dipaké kombinasi QUIC na TCP. Urang nganggap yén kombinasi téh alatan perpustakaan Cronet timeouting deui TCP, sabab teu bisa ngabedakeun antara gagal UDP nyata jeung kaayaan jaringan goréng. Kami ayeuna nuju milarian solusi pikeun masalah ieu nalika urang ngusahakeun palaksanaan QUIC salajengna.
optimasi QUIC
Lalu lintas tina aplikasi sélulér sénsitip latency, tapi henteu sénsitip bandwidth. Ogé, aplikasi urang utamana dipaké dina jaringan sélulér. Dumasar kana ékspérimén, latén buntut masih luhur sanajan ngagunakeun proksi pikeun ngeureunkeun TCP sareng QUIC caket sareng pangguna. Kami aktip milarian cara pikeun ningkatkeun manajemén kamacetan sareng ningkatkeun efisiensi algoritma pamulihan leungitna QUIC.
Kalayan ieu sareng sababaraha perbaikan anu sanés, kami ngarencanakeun pikeun ningkatkeun pangalaman pangguna henteu paduli jaringan sareng daérah, ngajantenkeun angkutan pakét anu gampang sareng lancar langkung diaksés di sakumna dunya.
sumber: www.habr.com