It QUIC-protokol is ekstreem ynteressant om te sjen, dat is de reden dat wy der graach oer skriuwe. Mar as eardere publikaasjes oer QUIC mear fan in histoaryske (lokale skiednis, as jo wolle) aard en hardware wiene, binne wy hjoed bliid om in oersetting fan in oare soart te publisearjen - wy sille prate oer de echte tapassing fan it protokol yn 2019. Boppedat hawwe wy it net oer lytse ynfrastruktuer basearre yn in saneamde garaazje, mar oer Uber, dy't hast oer de hiele wrâld wurket. Hoe't de yngenieurs fan it bedriuw kamen ta it beslút om QUIC yn produksje te brûken, hoe't se de tests útfierden en wat se seagen nei't se it yn 'e produksje útrôle - ûnder de besuniging.
De plaatsjes binne klikber. Genietsje fan it lêzen!
Uber hat in wrâldwide skaal, nammentlik 600 stêden fan oanwêzigens, yn elk wêrfan de applikaasje folslein fertrout op draadloos ynternet fan mear dan 4500 sellulêre operators. Brûkers ferwachtsje dat de app net allinich rap is, mar yn echte tiid - om dit te berikken hat de Uber-app lege latency en in heul betroubere ferbining nedich. Och, mar de steapel docht it net goed yn dynamyske en ferlies-gevoelige draadloze netwurken. Wy realisearre dat yn dit gefal lege prestaasjes direkt relatearre binne oan TCP-ymplemintaasjes yn kernels fan bestjoeringssysteem.
Om it probleem op te lossen, hawwe wy tapast , in moderne kanaal multiplexing protokol dat jout ús mear kontrôle oer de prestaasjes fan it ferfier protokol. Op dit stuit de wurkgroep standardizes QUIC as .
Nei wiidweidige testen konkludearren wy dat it ymplementearjen fan QUIC yn ús applikaasje soe resultearje yn legere sturtlatinsjes yn ferliking mei TCP. Wy observearre in reduksje yn it berik fan 10-30% foar HTTPS-ferkear yn 'e bestjoerder en passazjiersapplikaasjes. QUIC joech ús ek end-to-end kontrôle oer brûkerspakketten.
Yn dit artikel diele wy ús ûnderfining yn it optimalisearjen fan TCP foar Uber-applikaasjes mei in stapel dy't QUIC stipet.
De nijste technology: TCP
Tsjintwurdich is TCP it meast brûkte ferfierprotokol foar it leverjen fan HTTPS-ferkear op it ynternet. TCP soarget foar in betroubere stream fan bytes, dêrmei omgean mei netwurk congestie en keppeling laach ferlies. It wiidferspraat gebrûk fan TCP foar HTTPS-ferkear is te tankjen oan 'e ubiquity fan 'e eardere (hast elk OS befettet TCP), beskikberens op 'e measte ynfrastruktuer (lykas load balancers, HTTPS-proxies en CDN's), en out-of-the-box funksjonaliteit dy't beskikber is op hast de measte platfoarms en netwurken.
De measte brûkers brûke ús app ûnderweis, en TCP-sturtlatinsjes wiene njonken de easken fan ús real-time HTTPS-ferkear. Simply set, brûkers oer de hiele wrâld hawwe dit ûnderfûn - figuer 1 toant fertragingen yn grutte stêden:
Ofbylding 1: Tail latency ferskilt oer de wichtichste stêden fan Uber.
Hoewol't de latency yn Yndiaanske en Braziliaanske netwurken heger wie as yn 'e FS en it Feriene Keninkryk, is de sturtlatinsje signifikant heger as de gemiddelde latency. En dit jildt sels foar de FS en it Feriene Keninkryk.
TCP oer de loft prestaasjes
TCP is makke foar bedrade netwurken, dat is, mei in klam op tige foarsisbere keppelings. Lykwols, wireless netwurken hawwe har eigen skaaimerken en swierrichheden. Earst binne draadloze netwurken gefoelich foar ferlies troch ynterferinsje en sinjaaldemping. Bygelyks, Wi-Fi netwurken binne gefoelich foar mikroweagen, bluetooth en oare radio weagen. Sellulêre netwurken lije oan sinjaalferlies () fanwege refleksje / opname fan it sinjaal troch objekten en gebouwen, likegoed as fan fan oanbuorjende . Dit liedt ta wichtiger (4-10 kear) en mear ferskaat en pakketferlies yn ferliking mei in bedrade ferbining.
Om bânbreedtefluktuaasjes en ferliezen te bestriden, brûke sellulêre netwurken typysk grutte buffers foar ferkearsbursts. Dit kin liede ta tefolle wachtrige, wat langere fertraging betsjut. Hiel faak behannelet TCP dizze wachtrige as in ôffal fanwege in langere time-out, sadat TCP de neiging hat om te relay en dêrmei de buffer te foljen. Dit probleem is bekend as (), en dit is heul moderne ynternet.
Uteinlik ferskille de prestaasjes fan sellulêre netwurken per drager, regio en tiid. Yn figuer 2 sammele wy de mediane fertragingen fan HTTPS-ferkear oer sellen binnen in 2-kilometer berik. Gegevens sammele foar twa grutte sellulêre operators yn Delhi, Yndia. Sa't jo sjen kinne, ferskilt prestaasjes fan sel nei sel. Ek de produktiviteit fan ien operator ferskilt fan de produktiviteit fan de twadde. Dit wurdt beynfloede troch faktoaren lykas netwurkyngongspatroanen dy't rekken hâlde mei tiid en lokaasje, brûkersmobiliteit, lykas netwurkynfrastruktuer mei rekkening mei toerdichte en de ferhâlding fan netwurktypen (LTE, 3G, ensfh.).
figuer 2. Fertragingen mei help fan in 2 km radius as foarbyld. Delhi, Yndia.
Ek fariearje de prestaasjes fan sellulêre netwurken oer de tiid. Figuer 3 toant de mediaan latency per dei fan 'e wike. Wy observearre ek ferskillen op in lytsere skaal, binnen ien dei en oere.
figuer 3. Tail fertraging kin fariearje gâns tusken dagen, mar foar deselde operator.
Al it boppesteande feroarsaket dat TCP-prestaasjes net effektyf binne yn draadloze netwurken. Foardat wy lykwols nei alternativen sochten foar TCP, woene wy in krekt begryp ûntwikkelje oer de folgjende punten:
- is TCP de wichtichste skuldige efter sturtlatinsjes yn ús applikaasjes?
- Hawwe moderne netwurken signifikante en farieare fertragingen foar rûnreis (RTT)?
- Wat is de ynfloed fan RTT en ferlies op TCP-prestaasjes?
TCP Performance Analysis
Om te begripen hoe't wy TCP-prestaasjes analysearren, litte wy efkes sjen hoe't TCP gegevens oerbringt fan in stjoerder nei in ûntfanger. Earst stelt de stjoerder in TCP-ferbining op, dy't in trije-manier útfiert : De stjoerder stjoert in SYN-pakket, wachtet op in SYN-ACK-pakket fan 'e ûntfanger, en stjoert dan in ACK-pakket. In ekstra twadde en tredde pass wurdt bestege oan it oprjochtsjen fan de TCP-ferbining. De ûntfanger erkent ûntfangst fan elk pakket (ACK) om betroubere levering te garandearjen.
As in pakket of ACK ferlern is, stjoert de stjoerder nei in time-out opnij (RTO, ). RTO wurdt dynamysk berekkene op basis fan ferskate faktoaren, lykas de ferwachte RTT-fertraging tusken de stjoerder en de ûntfanger.
figuer 4. Pakket útwikseling oer TCP / TLS befettet in retransmission meganisme.
Om te bepalen hoe't TCP prestearre yn ús applikaasjes, hawwe wy TCP-pakketten kontrolearre mei help fan foar in wike op combat ferkear komt út Yndiaanske râne tsjinners. Wy analysearren doe de TCP-ferbiningen mei . Derneist hawwe wy in Android-applikaasje makke dy't emulearre ferkear nei in testtsjinner stjoert, en it echte ferkear safolle mooglik imitearje. Snoadfoans mei dizze applikaasje waarden ferspraat oan ferskate meiwurkers, dy't logs sammele oer ferskate dagen.
De resultaten fan beide eksperiminten wiene yn oerienstimming mei elkoar. Wy seagen hege RTT latencies; sturtwearden wiene hast 6 kear heger as de mediaanwearde; it aritmetysk gemiddelde fan fertragingen is mear as 1 sekonde. In protte ferbinings wiene ferlies, wêrtroch TCP 3,5% fan alle pakketten opnij stjoerde. Yn oerbelaste gebieten lykas fleanfjilden en treinstasjons seagen wy 7% ferliezen. Dizze resultaten meitsje twifel oer de konvinsjonele wiisheid dy't brûkt wurdt yn sellulêre netwurken signifikant ferminderjen ferliezen op it ferfier nivo. Hjirûnder binne de testresultaten fan 'e "simulator" applikaasje:
Netwurk metrics
Wearden
RTT, millisekonden [50%, 75%, 95%, 99%]
[350, 425, 725, 2300]
RTT diverginsje, sekonden
Gemiddeld ~ 1,2 s
Pakketferlies op ynstabile ferbiningen
Gemiddeld ~3.5% (7% yn oerbelaste gebieten)
Hast de helte fan dizze ferbiningen hie op syn minst ien pakketferlies, de measten fan harren SYN- en SYN-ACK-pakketten. De measte TCP-ymplemintaasjes brûke in RTO-wearde fan 1 sekonde foar SYN-pakketten, dy't eksponentiell ferheget foar folgjende ferliezen. Laadtiden fan applikaasjes kinne tanimme trochdat TCP langer duorret om ferbiningen te meitsjen.
Yn it gefal fan gegevenspakketten ferminderje hege RTO-wearden it nuttige gebrûk fan it netwurk gâns yn 'e oanwêzigens fan transiente ferliezen yn draadloze netwurken. Wy fûnen dat de gemiddelde trochstjoertiid sawat 1 sekonde is mei in sturtfertraging fan hast 30 sekonden. Dizze hege latencies op it TCP-nivo feroarsake HTTPS-timeouts en opnij oanfragen, en fergruttet de netwurklatinsje en ineffisjinsje fierder.
Wylst it 75e percentile fan mjitten RTT sawat 425 ms wie, wie it 75e percentile foar TCP hast 3 sekonden. Dit jout oan dat it ferlies feroarsake hat dat TCP 7-10 passes nimt om gegevens mei súkses te ferstjoeren. Dit kin in gefolch wêze fan ineffisjinte RTO-berekkening, it ûnfermogen fan TCP om fluch te reagearjen op ferlies yn it finster en de ineffisjinsje fan it algoritme foar congestiekontrôle, dy't gjin ûnderskied makket tusken draadloze ferliezen en ferliezen troch netwurkcongestie. Hjirûnder binne de resultaten fan TCP-ferliestests:
TCP pakket ferlies statistiken
wearde
Persintaazje ferbinings mei op syn minst 1 pakketferlies
45%
Persintaazje ferbinings mei ferliezen tidens ferbining opset
30%
Persintaazje ferbinings mei ferlies by gegevensútwikseling
76%
Ferdieling fan fertragingen yn trochstjoering, sekonden [50%, 75%, 95%,99%] [1, 2.8, 15, 28]
Ferdieling fan it oantal retransmissions foar ien pakket of TCP segment
[1,3,6,7]
Tapassing fan QUIC
Oarspronklik ûntwikkele troch Google, QUIC is in multi-threaded modern transportprotokol dat boppe op UDP rint. Op it stuit is QUIC yn (wy hawwe al skreaun dat d'r as it wiene twa ferzjes fan QUIC, nijsgjirrich – ca. oersetter). Lykas sjen litten yn figuer 5, QUIC wurdt pleatst ûnder HTTP / 3 (feitlik, HTTP / 2 boppe op QUIC is HTTP / 3, dat wurdt no yntinsyf standerdisearre). It ferfangt foar in part de HTTPS- en TCP-lagen troch UDP te brûken om pakketten te foarmjen. QUIC stipet allinich feilige gegevensoerdracht, om't TLS folslein yn QUIC ynboud is.
Ofbylding 5: QUIC rint ûnder HTTP/3, ferfangt TLS, dy't earder ûnder HTTP/2 rûn.
Hjirûnder binne de redenen dy't ús oertsjûge om QUIC te brûken foar TCP-fersterking:
- 0-RTT ferbining fêstiging. QUIC lit it wergebrûk fan autorisaasjes fan eardere ferbiningen, it ferminderjen fan it oantal feiligens handshakes. Yn de takomst sil stypje 0-RTT, mar in trije-manier TCP handshake sil noch v re fereaske.
- oerwinning fan HoL blokkearjen. HTTP/2 brûkt ien TCP-ferbining per kliïnt om prestaasjes te ferbetterjen, mar dit kin liede ta blokkearjen fan HoL (head-of-line). QUIC simplifies multiplexing en leveret oanfragen selsstannich oan 'e applikaasje.
- oerlêst kontrôle. QUIC wennet by de applikaasje laach, wêrtroch't it makliker te fernijen de wichtichste ferfier algoritme dat kontrolearret ferstjoeren basearre op netwurk parameters (oantal ferliezen of RTT). De measte TCP-ymplemintaasjes brûke it algoritme , dat is net optimaal foar latency-sensitive ferkear. Koartlyn ûntwikkele algoritmen lykas , krekter model it netwurk en optimalisearjen latency. QUIC lit jo BBR brûke en dit algoritme bywurkje as it wurdt brûkt. .
- replenishment fan ferliezen. QUIC ropt twa TLP's () foardat de RTO wurdt aktivearre - sels as de ferliezen tige merkber binne. Dit is oars as TCP-ymplemintaasjes. TLP ferstjoert benammen it lêste pakket (as it nije, as d'r ien is) opnij om rappe oanfolling te triggerjen. It behanneljen fan sturtfertragingen is benammen nuttich foar de manier wêrop Uber syn netwurk betsjinnet, nammentlik foar koarte, sporadyske en latency-gefoelige gegevensferfier.
- optimalisearre ACK. Sûnt elk pakket hat in unyk folchoarder nûmer, der is gjin probleem pakketten as se opnij ferstjoerd wurde. ACK-pakketten befetsje ek tiid om it pakket te ferwurkjen en in ACK oan 'e kliïntside te generearjen. Dizze funksjes soargje derfoar dat QUIC RTT krekter berekkent. ACK yn QUIC stipet oant 256 bands , helpt de stjoerder mear resistint te wêzen foar pakket-shuffling en minder bytes yn it proses te brûken. Selektyf ACK () yn TCP net oplosse dit probleem yn alle gefallen.
- ferbining migraasje. QUIC-ferbiningen wurde identifisearre troch in 64-bit ID, dus as in kliïnt IP-adressen feroaret, kin de âlde ferbinings-ID sûnder ûnderbrekking wurde brûkt op it nije IP-adres. Dit is in heul gewoane praktyk foar mobile applikaasjes wêr't de brûker skeakelt tusken Wi-Fi en sellulêre ferbiningen.
Alternativen foar QUIC
Wy beskôge alternative oanpak foar it oplossen fan it probleem foardat kiezen QUIC.
It earste ding dat wy besochten wie TPC PoPs (Points of Presence) yn te setten om TCP-ferbiningen tichter by brûkers te beëinigjen. Yn essinsje beëinigje PoP's in TCP-ferbining mei in mobyl apparaat tichter by it sellulêre netwurk en proxy it ferkear werom nei de oarspronklike ynfrastruktuer. Troch TCP tichterby te beëinigjen, kinne wy potinsjeel de RTT ferminderje en soargje dat TCP mear reageart op in dynamyske draadloze omjouwing. Us eksperiminten hawwe lykwols sjen litten dat it grutste part fan 'e RTT en ferlies komt fan sellulêre netwurken en it gebrûk fan PoP's leveret gjin signifikante prestaasjesferbettering.
Wy hawwe ek sjoen nei it ôfstimmen fan TCP-parameters. It ynstellen fan in TCP-stapel op ús heterogene edge-tsjinners wie lestich, om't TCP ferskate ymplemintaasjes hat oer ferskate OS-ferzjes. It wie lestich om dit út te fieren en ferskate netwurkkonfiguraasjes te testen. TCP direkt konfigurearje op mobile apparaten wie net mooglik fanwegen gebrek oan tagongsrjochten. Noch wichtiger, funksjes lykas 0-RTT-ferbiningen en ferbettere RTT-foarsizzing binne kritysk foar de arsjitektuer fan it protokol, en dêrom is it ûnmooglik om signifikante foardielen te berikken troch allinich TCP ôf te stemmen.
Uteinlik evaluearren wy ferskate UDP-basearre protokollen dy't problemen mei fideostreaming oplosse - wy woenen sjen oft dizze protokollen yn ús gefal soene helpe. Spitigernôch, se wiene slim tekoart oan in protte feiligens ynstellings, en ek nedich in ekstra TCP ferbining foar metadata en kontrôle ynformaasje.
Us ûndersyk hat oantoand dat QUIC faaks it ienige protokol is dat kin helpe mei it probleem fan ynternetferkear, wylst se rekken hâlde mei sawol feiligens as prestaasjes.
Yntegraasje fan QUIC yn it platfoarm
Om QUIC mei súkses te ynbêden en applikaasjeprestaasjes te ferbetterjen yn minne ferbiningsomjouwings, hawwe wy de âlde stapel (HTTP / 2 oer TLS / TCP) ferfongen troch it QUIC-protokol. Wy brûkten de netwurkbibleteek fan , dy't de orizjinele Google-ferzje fan it protokol befettet - gQUIC. Dizze ymplemintaasje wurdt ek konstant ferbettere om de lêste IETF-spesifikaasje te folgjen.
Wy yntegrearre Cronet earst yn ús Android-apps om stipe ta te foegjen foar QUIC. Yntegraasje waard útfierd op sa'n wize dat de migraasjekosten safolle mooglik ferminderje. Ynstee fan it folslein ferfangen fan de âlde netwurkstapel dy't de bibleteek brûkte , wy hawwe Cronet UNDER it OkHttp API-ramt yntegrearre. Troch de yntegraasje op dizze manier te dwaan, hawwe wy wizigingen foarkommen oan ús netwurkoproppen (dy't wurde brûkt troch ) op it API-nivo.
Fergelykber mei de oanpak foar Android-apparaten, implementeare wy Cronet yn Uber-apps op iOS, ûnderskeppe HTTP-ferkear fan netwurk mei help fan . Dizze abstraksje, levere troch de iOS Foundation, behannelet protokol-spesifike URL-gegevens en soarget derfoar dat wy Cronet kinne yntegrearje yn ús iOS-applikaasjes sûnder signifikante migraasjekosten.
Foltôgje QUIC op Google Cloud Balancers
Oan 'e efterkant wurdt QUIC-foltôging fersoarge troch de Google Cloud Load-balancing-ynfrastruktuer, dy't brûkt kopteksten yn antwurden om QUIC te stypjen. Yn 't algemien foeget de balancer in alt-svc-header ta oan elk HTTP-fersyk, en dit validearret al QUIC-stipe foar it domein. As in Cronet-kliïnt in HTTP-antwurd ûntfangt mei dizze koptekst, brûkt it QUIC foar folgjende HTTP-oanfragen nei dat domein. Sadree't de balancer de QUIC foltôget, stjoert ús ynfrastruktuer dizze aksje eksplisyt oer HTTP2 / TCP nei ús datasintra.
Prestaasje: Resultaten
Utfierprestaasjes is de wichtichste reden foar ús sykjen nei in better protokol. Om te begjinnen, wy makke in stand mei om út te finen hoe't QUIC sil gedrage ûnder ferskate netwurkprofilen. Om de prestaasjes fan QUIC op echte netwurken te testen, hawwe wy eksperiminten útfierd wylst wy troch New Delhi riden mei emulearre netwurkferkear, heul gelyk oan HTTP-oproppen yn 'e passazjiersapp.
Eksperimint 1
Apparatuer foar it eksperimint:
- test Android-apparaten mei OkHttp- en Cronet-stacks om te soargjen dat wy HTTPS-ferkear oer respektivelik TCP en QUIC tastean;
- in Java-basearre emulaasjetsjinner dy't itselde type HTTPS-kopteksten yn antwurden stjoert en kliïntapparaten lade om fersiken fan har te ûntfangen;
- wolkproxy's dy't fysyk tichtby Yndia lizze om TCP- en QUIC-ferbiningen te beëinigjen. Wylst wy foar TCP-beëiniging in omkearde proxy brûkten oan , wie it dreech om in iepen boarne reverse proxy foar QUIC te finen. Wy bouden sels in omkearde proxy foar QUIC mei de basis QUIC-stapel fan Chromium en it yn chromium as iepen boarne.
Figure 6. De TCP vs QUIC road test suite bestie út Android apparaten mei OkHttp en Cronet, wolk proxy foar it beëinigjen fan ferbinings, en in emulaasje tsjinner.
Eksperimint 2
Doe't Google makke QUIC beskikber mei , wy brûkten deselde ynventarisaasje, mar mei ien wiziging: ynstee fan NGINX, namen wy Google load balancers om TCP- en QUIC-ferbiningen fan apparaten te beëinigjen, en ek om HTTPS-ferkear nei de emulaasjetsjinner te routeren. Balancers wurde ferspraat oer de hiele wrâld, mar brûk de PoP-tsjinner it tichtst by it apparaat (mei tank oan geolokaasje).
Figure 7. Yn it twadde eksperimint woene wy de foltôgingslatinsje fan TCP en QUIC fergelykje: Google Cloud brûke en ús wolkproxy brûke.
As resultaat wachte ús ferskate iepenbieringen:
- beëiniging fia PoP ferbettere TCP-prestaasjes. Sûnt balancers TCP-ferbiningen tichter by brûkers beëinigje en tige optimalisearre binne, resultearret dit yn legere RTT's, wat de TCP-prestaasjes ferbettere. En hoewol QUIC minder beynfloede waard, prestearre it noch TCP yn termen fan it ferminderjen fan sturtlatens (mei 10-30 prosint).
- sturten wurde beynfloede . Hoewol ús QUIC-proxy fierder wie fan 'e apparaten (sawat 50 ms hegere latency) dan Google's loadbalancers, levere it ferlykbere prestaasjes - in 15% reduksje yn latency tsjin in 20% reduksje yn 'e 99e percentile foar TCP. Dit suggerearret dat de oergong fan 'e lêste kilometer in knyppunt is yn it netwurk.
Ofbylding 8: Resultaten fan twa eksperiminten litte sjen dat QUIC signifikant better presteart as TCP.
Combat ferkear
Ynspirearre troch eksperiminten hawwe wy QUIC-stipe ymplementearre yn ús Android- en iOS-applikaasjes. Wy hawwe A/B-testen útfierd om de ynfloed fan QUIC te bepalen yn 'e stêden wêr't Uber wurket. Yn 't algemien seagen wy in signifikante reduksje yn sturtfertragingen yn beide regio's, telekomoperators en netwurktype.
De grafiken hjirûnder litte de persintaazje ferbetterings yn tails (95 en 99 percentiles) sjen per makroregio en ferskate netwurktypen - LTE, 3G, 2G.
figuer 9. Yn striid tests, QUIC prestearre TCP yn termen fan latency.
Allinich foarút
Miskien is dit gewoan it begjin - de frijlitting fan QUIC yn produksje hat geweldige kânsen levere om applikaasjeprestaasjes te ferbetterjen yn sawol stabile as ynstabile netwurken, nammentlik:
Fergrutte dekking
Nei it analysearjen fan de prestaasjes fan it protokol op wirklik ferkear, seagen wy dat sawat 80% fan sesjes QUIC mei súkses brûkte foar всех fersiken, wylst 15% fan sesjes in kombinaasje fan QUIC en TCP brûkten. Wy geane derfan út dat de kombinaasje is te tankjen oan 'e Cronet-bibleteek-time-out werom nei TCP, om't it net ûnderskiede kin tusken echte UDP-fouten en minne netwurkbetingsten. Wy sykje op it stuit nei in oplossing foar dit probleem, om't wy wurkje oan 'e folgjende ymplemintaasje fan QUIC.
QUIC optimalisaasje
Ferkear fan mobile apps is latency gefoelich, mar net bânbreedte gefoelich. Ek wurde ús applikaasjes primêr brûkt op sellulêre netwurken. Op grûn fan eksperiminten binne sturtlatinsjes noch heech, ek al wurdt in proxy brûkt om TCP en QUIC tichtby brûkers te beëinigjen. Wy sykje aktyf nei manieren om oerlêstbehear te ferbetterjen en de effisjinsje fan QUIC-algoritmen foar ferliesherstel te ferbetterjen.
Mei dizze en ferskate oare ferbetteringen binne wy fan plan de brûkersûnderfining te ferbetterjen, nettsjinsteande netwurk en regio, wêrtroch handich en naadloos pakketferfier oer de hiele wrâld tagonkliker wurdt.
Boarne: www.habr.com