2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
TCP-protokollalla on yhteys, luotettava siirto, tavuvirtasuuntautunut, full-duplex jne. Luotettava siirto on sen ydin.
Kuvio 1
Yllä oleva kuva on TCP-otsikon rakenne.
(1) Lähdeporttia ja kohdeporttia ei tarvitse esitellä liikaa. Ne ovat ohjelmia, joita käytetään osoittamaan lähetyspää ja vastaanottopää.
(2) Järjestysnumeroa ja vahvistusjärjestysnumeroa käytetään myöhemmin esitellyssä TCP:n vahvistusvastausmekanismissa.
(3) Data offset -osan 4 bittiä käytetään itse asiassa osoittamaan TCP-otsikon pituutta. Koska 4 bittiä, suurin esitetty määrä on 15, mutta koska yksikkö on 4 tavua, yksikön enimmäispituus. TCP-otsikko on 60 tavua.
(4) Tiedämme kaikki, että UDP-datapakettien enimmäispituus on 64 kb, mikä on hyvin rajallista, joten tämän tilanteen välttämiseksi TCP-otsikossa on 6 varattu bittiä, joita voidaan käyttää, jos TCP-toimintoa laajennetaan. Edustettu myöhemmin varattujen bittien avulla.
(5) 6-tavuinen englantilainen tunniste liittyy myöhemmin esiteltyyn TCP-mekanismiin, eikä sitä esitetä tässä.
(6) Tarkistussummalla on sama tehtävä kuin UDP:n tarkistussummalla, ja sitä käytetään myös tarkistamaan, ovatko tiedot muuttuneet lähetysprosessin aikana.
(7) Ikkunasta keskustellaan myöhemmin, kun mekanismi otetaan käyttöön.
(8) Hätäosoitin otetaan käyttöön myöhemmin.
(9) Vaihtoehtojen joukossa on joitain valinnaisia/valinnaisia vaihtoehtoja.
TCP-protokollan on ratkaistava erittäin tärkeä ongelma - luotettava lähetys. Ns. luotettava lähetys ei tarkoita, että lähettäjä voisi lähettää tiedot vastaanottajalle 100 %, mutta se yrittää parhaansa mukaan ilmoittaa lähettäjälle, tietääkö vastaanottaja.
kuva 2
Kuten kuvassa 2, joka kerta kun lähetät viestin jumalattarelle, tämä on myös TCP:n tapaus palauttaa vastausdatapaketin Tällä hetkellä vastaustiedot Paketin ACK-lippu kuvassa 1 on asetettu arvoon 1.
kuva 3
Kuten kuvassa 3, kun lähetämme jumalattarelle useita viestejä, koska jumalatar vastaa viesteihin eri nopeuksilla, meidän on helppo hämmentyä. Itse asiassa jumalatar suostuu olemaan tyttöystäväni jumalatar sanoo eksymään. Tämä on Internet-ongelma, joka on objektiivisesti olemassa. Kun asiakkaalle lähetetään useita datapaketteja ja asiakas vastaa useisiin vastaustietopaketteihin, meidän on myös erotettava, mikä vastaus vastaa lähetettyä datapakettia. Tämä ongelma voidaan ratkaista käyttämällä kuvan 1 järjestysnumeroa ja vahvistusjärjestysnumeroa .
Jokaisella lähetetyllä datapaketilla on järjestysnumero, mutta vahvistusjärjestysnumeroa ei ole tai vahvistusjärjestysnumerokenttä on virheellinen. ja lähetetyn datapaketin järjestysnumero ja vastaus Datapakettien vahvistusjärjestysnumerot ovat vastaavat, jotta voidaan erottaa kuka vastasi kenelle ja edellä mainittu viimeksi tullutta palvellaan ensin -ongelma verkossa voidaan ratkaista. .
Varsinaisen TCP-datapaketin järjestysnumero on numeroitu tavujen mukaan. Jokaiselle tavulle annetaan järjestysnumero TCP-otsikossa on esimerkiksi hyötykuorman ensimmäisen tavun numero. Hyötykuorma-osan ensimmäisestä tavusta Tavunumero on 1 ja hyötykuorman pituus on 1000 tavua, niin datapaketin vastausdatapaketin otsikossa oleva kuittausjärjestysnumero on 1001. Tämä johtuu siitä, että kuittauksen järjestysnumero on datapaketin. Datapakettia vastaava vastaustietopaketti on asetettu arvoon Hyötykuorman viimeisen tavun lukumäärä kasvaa yhdellä. Itse asiassa tämä on helpompi ymmärtää, kun 1001 palautetaan, se tarkoittaa, että lähetetty 1000-tavuinen hyötykuorma on vastaanotettu 1001:n jälkeen pyydetään tietoja, kuten kuvassa 4.
Kuva 4
Seuraavien lähetettyjen datapakettien järjestysnumeroa kasvatetaan, mutta yksi asia on huomioitava, että vaikka se kasvaa, järjestysnumero ei ala 0:sta tai 1:stä.
Luotettava lähetys voidaan saavuttaa pääasiassa luottamalla "vahvistusvastaus" -mekanismiin. Se voi kertoa lähettäjälle vastausviestin kautta, meneekö kaikki hyvin ja tapahtuuko pakettihäviöitä. Mitä pitäisi tehdä, jos paketti katoaa (tieto putoaa lähetysprosessin aikana, eikä se pääse vastakkaiseen päähän, objektiivinen satunnainen tapahtuma)?
Aikakatkaisun uudelleenlähetystä käytetään pakettien katoamisongelmien ratkaisemiseen verkossa.
Tässä on pääasiassa kaksi tilannetta:
(1) Lähetetyt datapaketit menetetään
Tällä hetkellä B ei lähetä vastauspakettia, jos se ei vastaanota A:n datapakettia. Kun tapahtuma A odottaa ylittää tietyn kynnyksen, se määrittää pakettien katoamisongelman ja lähettää datapaketin uudelleen.
(2) Vastausdatapaketti on kadonnut
Kun A ei vastaanota vastausdatapakettia, se lähettää edelleen datapaketin, mutta tällä hetkellä B on vastaanottanut datapaketin uudelleenlähetyksessä kaksi identtistä datapakettia. Tämä on erittäin epätieteellistä , erityisesti sellaisissa asioissa, kuten siirrot, joissa toistuvia siirtoja tapahtuu.
Yllä olevia ongelmia varten TCP-vastaanotin poistaa vastaanotetun datan kopiot järjestysnumeron mukaan. TCP-kerros ei välitä kopiointiongelmasta. Tärkeintä on, että sovelluskerros ei voi lukea päällekkäisiä tietoja riippumatta siitä, kuinka monta kertaa se lähetetään, on varmistettava, että sovelluskerros lukee vain yhden kopion tiedoista.
Vastaanottavan käyttöjärjestelmän ytimessä on tietorakenne - vastaanottopuskuri Tämä tietorakenne on samanlainen kuin prioriteetin estojono Kun B vastaanottaa datapaketin ja kulkee kerrosten läpi siirtokerrokseen esto jono syöttää se ja jono määrittää, onko data olemassa datapaketin järjestysnumeron perusteella (olemassaolo tarkoittaa, että sama datapaketti on vastaanotettu ja lukenut sen kerran sovelluskerros), se hylätään suoraan. Toinen vastaanottopuskurin kohta on, että se voi ratkaista viimeksi tullutta palvellaan ensin -ongelman. Lähetetyt tiedot lajitellaan järjestysnumeron mukaan ja kulutetaan sitten sovelluskerroksen ohjelmassa.
Kuten yllä olevasta kuvasta näkyy, vastaanottopuskuriin saapuvat tiedot lajitellaan järjestysnumeron mukaan. Tämä ei ainoastaan ratkaise viimeksi lähetetyn saapumisjärjestyksessä, vaan myös kaksoistietopakettien vastaanottamisen ongelman Tällä kertaa, jos uudelleenlähetetty datapaketti vastaanotetaan järjestysnumerolla 500, se hylätään suoraan, koska vastaanottopuskurin minimijärjestysnumero on 1000, mikä tarkoittaa, että sovellusohjelma on jo lukenut 500.
Pakettihäviö itsessään on pieni todennäköisyystapahtuma Kun pakettihäviöiden määrä kasvaa, verkosta tulee suuri ongelma. Uudelleenlähetysten määrän kasvaessa uudelleenlähetysten välinen aika pitenee edelleen, koska uudelleenlähetysten lisääntyminen osoittaa, että verkossa on ongelma ja toistuvat uudelleenlähetykset kuluttavat resursseja. Kun uudelleenlähetysten määrä saavuttaa kynnyksen, lähetetään nollausviesti, jonka RST-lippubitti on asetettu arvoon 1, molempien päiden välitilan tyhjentämiseksi. Jos nollausviestiin ei vastata, molempien päiden yhteys poistetaan.
Aikakatkaisun uudelleenlähetys täydentää kuittausvastausta.
Kuva 5
Yhteyden muodostaminen tarkoittaa, että molemmat kommunikoivat osapuolet tallentavat toisen pään tiedot. Tietty valmistuminen vaatii kolme verkkovuorovaikutusta, kuten kuvassa 5.
Kolmisuuntaisen kättelyn ensimmäinen kerta tulee olla asiakkaan aloitteesta. Tarkka prosessi on esitetty kuvassa 5. Ensin asiakas lähettää SYN-paketin, eli otsikon SYN-lippu asetetaan arvoon 1. Sitten palvelin palauttaa vastauspaketin. Vastauspaketin ACK- ja SYN-liput ovat molemmat asetettu arvoon 1, koska ACK ja SYN Käyttöjärjestelmän ydin lähettää lippubittejä sisältävät datapaketit samanaikaisesti, joten ne voidaan lähettää yhdessä suorituskyvyn parantamiseksi. Lopuksi asiakas lähettää vastauspaketin palvelimelle, ja kolmisuuntainen kättely on valmis. Tämän prosessin aikana lähetetyt datapaketit eivät sisällä liiketoimintadataa.
Kolmisuuntaisen kättelyn merkitys:
(1) Kivien valu kysyäksesi ohjeita
Varmista, että viestintäyhteys toimii sujuvasti
(2) Neuvottele joitakin tärkeitä parametreja
Esimerkiksi lähetetyn datapaketin järjestysnumero
(3) Vahvista molempien osapuolten vastaanotto- ja lähetysominaisuudet
Miksi kolme kädenpuristusta? Sopiiko neljä vai kaksi kädenpuristusta?
Vaikka nelisuuntainen kättely ei vaikuta normaaleihin toimintoihin, se heikentää suorituskykyä. Kaksisuuntainen kättely ei voi täysin vahvistaa palvelimen vastaanotto- ja lähetysominaisuuksia.
Lisäksi tässä on mukana kaksi muuta tärkeää tilaa. Ensimmäinen on kuuntelutila, mikä tarkoittaa, että palvelin on sidonut portin tällä hetkellä ja odottaa asiakkaan lähettävän SYN-paketin helppo ymmärtää ja tarkoittaa, että kolmisuuntainen kättely on valmis. Tila yhteyden muodostuksen jälkeen.
Toisin kuin kolmisuuntainen kättely, jonka vain asiakas voi käynnistää ensin, sekä palvelin että asiakas voivat aloittaa nelisuuntaisen kättelyn.
Kuva 6
Neljän kerran heiluttamisen erityinen prosessi on esitetty kuvassa 6. Kun socket.close() -menetelmää kutsutaan asiakaskoodissa tai kun prosessi päättyy, lähetetään FIN-loppuviesti palvelimelle ACK-viesti takaisin, mutta se joutuu odottamaan palvelimen koodia Vain socket.close()-koodin kutsun jälkeen asiakas lähettää ACK-sanoman palvelimelle ja prosessi päättyy heiluttamalla neljä kertaa.
Tässä keskellä olevaa ACK:tä ja FIN:tä ei voi yhdistää, koska ACK:n lähettää järjestelmäydin, joten se lähetetään heti, kun palvelin vastaanottaa FIN-sanoman, mutta FIN-sanoman on odotettava palvelinpuolen koodia. suorittaa socketin Se voidaan lähettää sulkemisen jälkeen, ja näiden kahden välillä on aikaero. Mutta on tapa yhdistää nämä kaksi Erikoistilanteissa ACK voidaan lähettää viivästyneenä, jotta se voidaan lähettää yhdessä FIN: n kanssa.
Lisäksi neljässä heilutusprosessissa on kaksi tilaa. Tämä on tila, jossa vastaanottaja on vastaanottanut lähettäjän FIN-viestin jota osapuolen on odotettava vastaanotettuaan vastaanottajan lähettämän FIN:n ja lähettäessään sitten vastaanottajalle ACK:n. Yhteyttä ei voida katkaista välittömästi, koska se on välttämätöntä, jotta viimeinen lähettäjän vastaanottajalle lähettämä kuittaus katoaa. vastaanottaja lähettää FIN:n uudelleen Sen varmistamiseksi, että lähettäjä voi edelleen vastaanottaa tämän FIN:n, aika tässä tilassa on yleensä 2MSI (MSI: tiedonsiirron maksimiaika molemmissa päissä), mikä on yleensä 2 minuuttia.
Jos vastaanottimesta löytyy suuri määrä close_wait, se tarkoittaa, että close()-metodi on unohdettu. Jos palvelimelta löytyy suuri määrä time_wait, se tarkoittaa, että palvelin on käynnistänyt suuren määrän aktiivisia TCP-katkaisuja. toiminnot.
TCP:n on varmistettava luotettava tiedonsiirto, mutta samalla se haluaa myös suorittaa tiedonsiirron mahdollisimman tehokkaasti Liukuikkuna on tehokkuuden parantamismekanismi. Tämä on itse asiassa tapa korvata se, koska luotettavuuden varmistamiseksi TCP uhraa paljon suorituskykyä riippumatta siitä, kuinka liu'utat ikkunaa, tiedonsiirtonopeus ei voi olla nopeampi kuin UDP.
Kuva 7
Kuten kuvasta 7 näkyy, tämä on tiedonsiirtoprosessi, mutta datapaketin lähetys ja vastausdatapaketin vastaanottaminen on edelleen suhteellisen hidasta.
Kuva 8
Kuten kuvassa 8 näkyy, tämä tapahtuu liukuvan ikkunan mekanismin käyttöönoton jälkeen. Sen sijaan, että lähetettäisiin yksi datapaketti mutta useita datapaketteja kerrallaan, palautettujen vastausdatapakettien odotusaika menee päällekkäin. Odotamatta kuittausta erissä lähetettävän tiedon määrä on ikkunan koko.
Kuva 9
Ikkunan liukuminen on esitetty kuvassa 9. Oletetaan, että ikkunan koko on 4 ryhmää. Jos lähettäjä saa ACK:n 3001, se tarkoittaa, että tiedot 1001-3001 on vastaanotettu, joten ikkuna voi siirtyä kaksi välilyöntiä oikealle.
Mitä tehdä, jos liukuvassa ikkunassa tapahtuu pakettihäviöitä?
(1) Lähetetty datapaketti on kadonnut
Jos tietty ryhmä lähetettyjä datagrammeja katoaa, vaikka lähetät useita dataryhmiä vastaanottajalle erissä, vastaanotetun ACK:n vahvistusjärjestysnumero on edelleen kadonneen ryhmän numero, kunnes lähettäjä lähettää datagrammin uudelleen. Esimerkiksi datagrammit 1001-2000 yllä olevassa kuvassa menetetään Vaikka useita datajoukkoja lähetettäisiin myöhemmin, ACK 1001 palautetaan, kunnes lähettäjä lähettää uudelleen ja vastaanottaja vastaanottaa sen ja vastaa sitten ACK:lla 7001. .
(2) Vastaus ACK on menetetty
Jos vastaus ACK katoaa, sinun ei tarvitse huolehtia siitä, koska voit vain odottaa, kunnes muiden tietoryhmien ACK palautetaan Esimerkiksi, jos yllä olevan kuvan 1001 ACK katoaa, se ei väliä Seuraavan ACK:n 2001 lähettäjä on vastaanottanut sen, ja sama pätee, jos myöhemmän tiedon kuittaus katoaa.
Yllä mainittu pakettihäviön käsittely on edelleen erittäin tehokasta. Jos datapaketti katoaa, täytä aukko ja lähetä tiedot uudelleen. Tällaista toimintoa kutsutaan nopeaksi uudelleenlähetykseksi.
Aikakatkaisun uudelleenlähetys ja nopea uudelleenlähetys ovat erilaisia strategioita, joita käytetään eri ympäristöissä. Jos TCP lähettää vain vähän ja harvoin, aikakatkaisun uudelleenlähetys käynnistyy Nopea uudelleenlähetys, nopea uudelleenlähetys vastaa liukuvan ikkunan alla olevaa aikakatkaisun uudelleenlähetystä.
Kuten aiemmin mainittiin liukuvasta ikkunasta, ikkunan koko on vaihteleva. Mitä suurempi ikkuna, sitä enemmän dataa lähetetään aikayksikköä kohden. Mitä pienempi ikkuna, sitä enemmän dataa lähetetään aikayksikköä kohden Mitä vähemmän dataa on, sitä vähemmän se on tehokasta. Normaalisti toivomme, että hyötysuhde on mahdollisimman korkea, mutta korkean hyötysuhteen edellytyksenä on luotettavuuden varmistaminen on Vastaanotin ilmoittaa lähettäjälle, että lähetysnopeus on liian nopea.
Kuten yllä olevasta kuvasta näkyy, kuten aiemmin mainittiin, ytimessä on tietorakenteen vastaanottopuskuri ja vastaanotin palauttaa ikkunan kooksi vastaanottopuskurin vapaan tilan koon. Edellisessä TCP-otsikossa on 16-bittinen ikkunakokokenttä, joka tallentaa ja palauttaa nämä tiedot. Ikkunan koko -kenttä tulee voimaan vain ACK:ssa.
Kuten yllä olevasta kuvasta näkyy, ACK palauttaa ikkunan koon vuonhallinnan tarkoituksen saavuttamiseksi. Kun ikkunan koko palaa nollaan, lähettäjä lähettää ajoittain koetusviestejä, jotka eivät sisällä liiketoimintatietoja, käynnistääkseen ACK:n. puskurin tila.
Ruuhkanhallinta on hyvin samanlainen kuin virtauksen hallinta, molemmat mekanismit on yhdistetty liukuikkunoihin.
Kuten yllä olevasta kuvasta näkyy, verkon linkit ovat erittäin monimutkaisia, ja mikä tahansa linkin solmu voi rajoittaa lähettäjän nopeutta. Ruuhkanhallinnan ideana on käsitellä sitä kokonaisuutena riippumatta siitä, kuinka monimutkainen välirakenne on, ja sitten löytää sopivin ikkunakoko kokeilujen avulla.
Yllä oleva kuva on ruuhkanhallintaprosessi kokeile ensin suhteellisen pienellä ikkunalla (hidas käynnistys), koska et tiedä verkon ruuhkatilannetta. Sen jälkeen ikkunan koko kasvaa eksponentiaalisesti tietyn kynnyksen, se alkaa kasvaa lineaarisesti, ja sitten kun ikkuna kasvaa tietyssä määrin, tapahtuu pakettihäviöitä. Tällä hetkellä ikkunaa pienennetään kahdella tavalla.
(1) Kutista suoraan pohjaan, palaa hitaan käynnistyksen alkuun ja toista sitten edellinen prosessi (jo hylätty)
(2) Kutistua puoleen ja kasvaa sitten lineaarisesti (todellinen käytetty menetelmä)
Ruuhkanhallinta on kokeiden avulla löytää sopiva ikkunakoko. Jos pakettihäviöitä on paljon, pienennä ikkunan kokoa.
Viivästetty vastaus tarkoittaa, kuten nimestä voi päätellä, odottaa jonkin aikaa ennen ACK:n palauttamista. Tähän liittyy itse asiassa myös ikkunan koko, koska ACK:n viivästynyt vastaus antaa vastaanottajalle enemmän aikaa kuluttaa vastaanottopuskurissa olevia tietoja, mikä lisää. ilmaisen puskurin kokoa, ACK:n palauttama ikkunan koko kasvaa ja lähettäjä voi lähettää lisää tietoja erissä.
On olemassa kaksi viivästettyyn vastaustapaa:
(1) Määritä viive tietyn ajan mukaan
(2) Vastaanotetun tiedon määrän mukaan
Edellä mainittuja kahta strategiaa käytetään yhdessä.
Piggyback-reaktiot ovat itse asiassa ilmestyneet aiemmin mekanismina, jota on käytetty lähetyksen tehokkuuden parantamiseen. Tämä on tapaus, jossa ACK ja SYN palautetaan käyttämällä samaa datapakettia kolmisuuntaisessa kättelyssä. Tilanne on myös samanlainen kuin Four Wavesissa. Koska ACK ja FIN lähetetään eri aikoina, ACK-vastauksia ei voida lähettää niin nopeasti, ja se voidaan yhdistää kahteen FIN-lähetykseen.
Tavuvirtasuuntautunut on TCP:n mekanismi, johon on kiinnitettävä huomiota. Tämä ongelma johtuu kyvyttömyydestä erottaa eri sovelluskerroksen datapaketteja tavuvirta, palvelin voi Lukemalla useita tavuja voi lukea myös yhden tavun, mikä voi helposti aiheuttaa tämän ongelman.
Yllä olevaan tahmeapussiongelmaan on kaksi ratkaisua:
(1) Käytä erottimia
Mitä tahansa symbolia voidaan käyttää niin kauan kuin sitä ei ole pyyntöpaketissa
(2) Sovi datapaketin pituudesta
Useimmissa tapauksissa Java-ohjelmoijat eivät kuitenkaan käytä TCP:tä suoraan, vaan he käyttävät valmiita protokollia, kuten http, tai toteuttavat verkkoviestinnän, joka perustuu työkaluihin, kuten protobuffer tai dubbo. Nämä menetelmät ovat ratkaisseet kiinnittyvien pakettien ongelman. Kadonnut.
(1) Viestinnän molemmissa päissä prosessi kaatui toisessa päässä.
Käyttöjärjestelmä suorittaa neljä aaltoa ja aallot PCB:tä.
(2) Tietty isäntä suljetaan (normaali prosessi)
Ensimmäinen mahdollisuus on, että käyttöjärjestelmä on suorittanut neljä kertaa joka sammuu, koska ne kaikki suljetaan Tallennetut tiedot (muisti) ovat luonnollisesti poissa.
(3) Tietyn isännän virtalähde on katkaistu.
Kun sammutettu isäntä on palvelin, asiakkaan lähettämä datapaketti lähetetään uudelleen ilman ACK-kuittausta. Jos tulosta ei saada useiden uudelleenlähetysten jälkeen, yhteys poistetaan.
Kun virrankatkaisuisäntä on asiakas ja palvelin ei ole vastaanottanut datapakettia pitkään aikaan, se lähettää ajoittain sykepaketin ilman hyötykuormaa, vain laukaistakseen ACK:n. Jos asiakas on normaali, se palaa ACK, muuten se ei vastaanota sitä, jos asiakkaalta ei saada vastausta sen jälkeen, kun se on lähetetty useita kertoja peräkkäin, mutta vastausta ei ole, voidaan katsoa, että asiakas ei ole toiminnassa ja yhteystiedot on poistettu.
Lisäksi, vaikka TCP toteuttaa sykepaketteja, sykli on pitkä, jotta saadaan selville, että asiakas on alhaalla tämän sykepaketin kautta. Varsinaisessa kehityksessä sovelluskerroksen sykepaketit toteutetaan korkeammalla taajuudella ja lyhyemmällä aikavälillä (toinen taso/millisekunnin taso A->B lähettää pingin ja B->A vastaa pongilla). Kun tietty Jos laite jumittuu, voit löytää ongelman nopeasti.
(4) Verkkokaapeli on irrotettu
Pohjimmiltaan se on kolmas tapaus, jos lähettäjä ei saa kuittausta, se aikakatkaisee ja lähettää sen uudelleen, ja sitten poistaa yhteyden yksipuolisesti. Jos vastaanottaja ei vastaanota datapakettia, se lähettää sykepaketin Jos se ei vastaanota kuittausta, se lähettää vain sykepaketin.
TCP-otsikkorakenteessa on kaksi lippubittiä, joita ei mainita, nimittäin PSH ja URG kehottaa toista osapuolta palauttamaan vastauksen mahdollisimman pian. URG liittyy TCP-paketin otsikon hätäosoitinkenttään ja sitä käytetään yhdessä ohjaamaan TCP:n kaistan ulkopuolista tiedonsiirtoa.
Kaistan ulkopuolinen tiedonsiirto tarkoittaa, että yritystietojen lisäksi on olemassa joitakin erityisiä datapaketteja, joilla ohjataan itse TCP:n toimintamekanismia.
Hän on omistautunut teknologian tutkimukselle yli 30 vuoden ajan ja hallitsee useita kieliä, kuten java, linux, javascript, php, css jne. Hän on tehnyt paljon työtä avoimen lähdekoodin alalla Kehittäjän dokumentaatioasema, jossa voit jakaa joitakin teknologian kehittämisen ongelmia myöhempää käyttöä varten
