Go-ohjelmasi opettaminen puhumaan kuin Chrome

Jos olet koskaan matkustanut ulkomaille ja tilannut kahvin oppikirjan täydellisellä lauseella, tunnet baristan katseen. Kielioppisi on kunnossa. Jokainen sana löytyy sanakirjasta. Silti puolessa sekunnissa kaikki kahvilassa tietävät, että olet kotoisin muualta.

Go-kielen vakio-HTTP-asiakkaassa on hieman samanlainen ongelma. Se on erinomainen oletusratkaisu: luotettava, siisti ja valmis vakavaan työhön heti alusta asti. Kun ohjelmasi ottaa yhteyden palvelimeen, se kuitenkin selvästi näyttää Go-ohjelmalta. Useimmiten kukaan ei välitä siitä. Silti jotkin verkkosivustot, CDN-palvelut ja testiympäristöt kiinnittävät tarkkaan huomiota siihen, kuka kolkuttaa ovella, ja ne käyttäytyvät melko eri tavalla sen mukaan, minkälaiseksi asiakkaaksi ne luulevat asiakasta.

Siksi rakensimme gosuda.org/chromenet-kirjaston. Sen sijaan, että opettaisimme Go-kielen vakioasiakasta esittämään kelvollista selainta, chromenet antaa Go-ohjelmalle mahdollisuuden kommunikoida verkossa samalla verkkomoottorilla, jota Google Chrome käyttää, eli Chromiumin omalla verkkokoodilla. Tarkistitpa sitten, miten omat testiympäristösi käsittelevät selainliikennettä, tai puhut sivuston kanssa, joka on kiinni tarkassa CDN-palvelussa, Chromen moottorin kautta viestiminen poistaa kokonaisen kerroksen arvailua.

Sovelluksesi ei tarvitse kirjoittaa uudelleen, jotta voit käyttää sitä. Koodissasi se toimii suoraan http.Transport-tyypin korvaajana. Käytät edelleen http.Client-asiakasta tavalliseen tapaan, ja chromenet hoitaa keskustelun taustalla.

Uusimman julkaisun kokeilemiseksi asenna se komennolla go get:

1go get gosuda.org/chromenet@v0.2.10157081033800

Anna sitten sen kuljetin asiakkaallesi:

1client := http.Client{
2	Transport: chromenet.NewTransport(chromenet.Options{}),
3}

Tämän julkaisun myötä kaikki moderni verkkoliikenne kulkee Chromen moottorin kautta. Se kattaa nyt tavalliset verkkopyynnöt, WebSocketin ja WebTransportin. Aiemmat versiot käsittelivät kunnolla vain tavallisia pyyntöjä, kun taas WebSocket ja WebTransport olivat väliaikaisia korvikkeita. Tämä tarkoitti, että alkutervehdyksesi ovella kuulosti Chromelta, mutta jos vaihdoit toisenlaiseen keskustelutyyliin, peitteesi saattoi lipsahtaa. Tämä julkaisu korvaa nuo korvikkeet oikealla toteutuksella.

Odota, jos käytämme Chromiumin omaa verkkokoodia, muuttuuko hiljainen Go-buildisi laajaksi C-kääntäjän päänsäryksi? Onneksi ei. Go-koodisi pysyy tavallisena Go-koodina, eikä cgo:ta tai C-kääntäjää tarvita.

Selainkoodin upottamisen sijaan suoraan binääriisi chromenet ajaa moottorin pienenä erillisenä ohjelmana Go-ohjelmasi vieressä. Ajattele sitä kuin palkkaisit sujuvan paikallisen tulkin, joka kulkee rinnallasi sen sijaan, että yrittäisit rakentaa uudelleen omat äänihuulesi. Koska moottori toimii erillisessä ohjelmassa, sen kaatuminen ei voi kaataa palveluasi.

Go-ohjelmasi pysyy tavallisena Go-koodina, kun pieni kumppaniohjelma kuljettaa liikennettä Chromiumin verkkomoottorin kautta.

Työasemallesi tai palvelimillesi ei myöskään tarvitse asentaa mitään ylimääräistä. Moottorin binäärit Linuxille, macOS:lle ja Windowsille sekä Intel/AMD- että ARM-arkkitehtuureille tulevat suoraan Go-moduulin mukana, ja ne varmennetaan ennen suorittamista.

Binäärien toimittaminen moduulin sisällä herättää ymmärrettävästi kysymyksen kaikille, jotka välittävät luottamuksesta, ja halusimme antaa suoran vastauksen. Binäärit rakennetaan toistettavalla tavalla tietystä Chromium-julkaisusta, tällä hetkellä Chromium 157:stä, joten kuka tahansa voi rakentaa ne uudelleen ja saada täsmälleen samat tavut, ja GitHub todentaa jokaisen julkaisun. Jotta selainmaailman tahtiin pysyttäisiin ilman manuaalista työtä, ajastettu työ seuraa Chromiumin vakaata kanavaa ja päivittää version automaattisesti, kun uusi Chrome julkaistaan.

Entä uTLS?

Jos olet aiemmin yrittänyt saada Go-asiakkaasi näyttämään selaimelta, olet todennäköisesti törmännyt uTLS:ään. Se on upea työ: Go-kirjasto, jonka avulla voit pukea suojatun yhteyden ensimmäisen viestin muotoon, joka muistuttaa Chromea, Firefoxia tai mitä ikinä haluat. Se on pieni, puhdasta Go-kieltä, eikä ohjelmasi rinnalla aja mitään ylimääräistä.

Ongelma on siinä, kuinka pitkälle asu ulottuu. uTLS kattaa kättelyn, eli keskustelun ensimmäiset sanat. Kaikki sen jälkeen on edelleen sinun rakennettavissasi: HTTP/2-kerros on kytkettävä ja viritettävä käsin, HTTP/3 on oma seikkailunsa, ja WebSocket tai WebTransport vaativat vielä lisää liimakoodia. Chrome-esiasetukset ovat myös kopioita, joten joku joutuu pitämään ne ajan tasalla aina, kun Chrome muuttaa tapojaan. Se on vähän kuin ihmisen aksentin jäljittelemistä, kun hänen kehonkielensä silti paljastaa hänet.

chromenet valitsee päinvastaisen lähestymistavan. Se ei jäljittele Chromea, vaan pyytää Chromen omaa moottoria hoitamaan puheen, joten kättely, yhteyksien uudelleenkäyttö, protokollapäivitykset ja kuljettimet tulevat kaikki samasta paikasta ja etenevät yhdessä, kun Chromium etenee.

Kompromissi on rehellinen. uTLS on kevyempi ja antaa sinun muotoilla minkä tahansa tervehdyksen, jonka voit kuvitella, kun taas chromenet tuo mukanaan 25 MB:n apuohjelman ja antaa Chromen todellisen käyttäytymisen eikä mukautettua versiota. Jos haluat pienen riippuvuuden ja täyden hallinnan kättelystä, uTLS on edelleen erinomainen valinta.

Jokaisessa ratkaisussa on kompromisseja, ja haluamme olla tässä avoimia rajoituksista. Todellisen selaimen verkkomoottorin paketointi ei ole pientä: jokainen moottoribinääri on noin 25 MB. macOS:llä binäärejä ei ole notarisoitu. Linuxissa järjestelmässäsi tulee olla glibc 2.31 tai uudempi. Jos nämä rajat sopivat ympäristöösi, saat aidon Chromen verkkoyhteyden vaihtamalla yhden kuljetinkentän.

Projekti sijaitsee osoitteessa github.com/gosuda/chromenet. Jos tunnet gosuda-avoimen lähdekoodin sisarprojektit gosuda.org/hqq ja gosuda.org/sqlite3, henki tuntuu tutulta: otetaan kykeneviä, raskaita työkaluja laajemmasta ohjelmistomaailmasta ja tehdään niistä luontevia osia tavalliseen Go-koodiin.

Joten jos tavoittelet uTLS:ää, koska tarvitset Go-ohjelmasi kuulostamaan selaimelta, kokeile chromenetiä. Se voi olla hyvä vaihtoehto uTLS:lle erityisesti silloin, kun tarvitset enemmän kuin HTTPS-pyyntöjä: HTTP/2, HTTP/3, WebSocket ja WebTransport kulkevat kaikki saman Chrome-moottorin kautta ilman liimakoodia puolellasi.