[HacaX]

Esiteks olgu öeldud, et kirjeldet meetod ei võimalda üle oma varju hüpata, s.t. ei selle ega ka mingi teise (praktikas alati töötava) nipiga ei ole võimalik saada paremat ühendust kui ISP sulle seda pakub. Aga samamoodi nagu download acceleratorid jagavad tiritava faili juppideks saab ka WWW sirvimist panna proxydega mängides läbilaskevõimet paremini ära kasutama. Võit ei ole oluline, aga vast siiski parem kui mitte midagi.

Asja toimimiseks on vaja järgmisi asju:

* ligipääsu *vähemalt* kahele kiirele proxy serverile. Rõhk sõnal *kiire* seega kukuvad välismaised anonüümsed proxyd üldjuhul ära. Kuna ka servu oskus lehti cache'ida tuleb kasuks (ja sellist võimalust avalikud proxy reeglina(?) ei paku) siis sobivad praktikas enamasti vaid ISPi enda cache serverid. Kas teenusepakkujal on neid rohkem kui üks ja millise nime/IP peal nad istuvad on juba iga lugeja enda välja uurida. STV/Infoneti võrgus asi igatahes toimib.

* mõnda multiproxyimist oskavad programmi. Ise (ja seega ka järgnevas kirjelduses) kasutan MishkinSofti MultiProxyt, kuna see ei kuluta eriti resursse ja mis veelgi tähtsam - on tasuta. Põhimõtteliselt peaks sobima aga ka iga muu anonymizer tüüpi proge.

OK, ütleme, et MP on installitud. Esimese asjana tuleks tühjaks teha ta proxyde nimekiri:
Options=>Proxy servers list=>hiire vasema nupuga klõps esimesel serveril, SHIFT klahvi all mida ja klõps viimasel=>klõps parema nupuga=>Delete=>OK. Edasi tuleb sisse lüüa oma serverid: sealsamas lehel Menu=>Add=>kirjutada serveri nimi või IP ning kasutatav port=>OK. Korrata protseduuri ülejäänud servudega. Edasi võiks MP konfida sarnaselt:



Tasuks muidu märkida <Maximum simultaneous connections> kasti: selle väärtusega saab otseselt määrata kui palju ühendusi (ehk siis kui suurt lisakoormust) proxydega ühendumiseks kasutada. Enda 266MHzi peal paistab 10 olevat selline mõistlik number, kui raalil aga rohkem võimsust siis võib seda numbrit tõsta. Peaks asja veidi kiiremaks ajama.

Soh, MP on valmis pandud, nüüd vaja veel panna brauser teda kasutama. IE's käib see nii: Tools=>Internet Options=>Connections=>LAN Settings, kas pannna linnuke <Use a proxy server for your LAN> kasti ja siis käsitsi aadress (127.0.0.1 ja port mis pandi MPs) või tirida alla <Use automatic configuration script> kastis näidatud fail ning tolles asendada ISPi server 127.0.0.1:MPpoolttarbitavapordiga).

Edasi peaks kogu ühendumine käima läbi MultiProxy mis hoolitseb juba ise selle eest, et tarbitaks kiireimat serverit.

Lõpetuseks veel paar mõtet:

* kui asja tarbitase sisevõrgus siis ei pruugi sugugi iga kasutaja oma masinasse MPd installida vaid võib tolle panna jooksma näiteks kõige kõvemal/vähemhõivatud masinal ja ülejäänud siis panevad oma brauseri kasutama tolle IPd. MPs peab küll lisama Options=>Advanced Options=>"Allow connections from following IPs" kasti kasutajate masinate IPd.

* MP on suht vana proge ja ei oska ei teenusena joosta ega ka mitte end ise startupi toppida. Seega tuleks seda teha kasutajal, vältimaks olukorda, et välismaistele saitidele ei pääsegi. Lihtsam tee: vedada shortcut StartUp kausta (soovitatavalt AllUsersi all olevasse, et ikka kõigil asi käima läheks). Aga võib tarbida ka hoopis FireDaemoni, et MPd sevice'ina jooksutada. See on eriti kasulik eelnevalt mainitud kohtvõrgu situatsioonis, sest nõnda jääb nett ka siis jooksma kui kasutaja MPval arvutil end välja logib.

* kogu protseduur ei ole päris probleemivaba. Surfamisega pole endal veel jamasi esinenud, aga näiteks ePrompter, mis mingil arusaamatul põhjusel (lutikas?) tarbib samuti Winblowsi/IE proxysätteid, ei taha enamuse ajast kuidagi WWW põhistest süsteemidest (nagu Yahoo!Mail) meili tirida. MP enda võimalus "Disable (direct connection)" ei aita, ainuke mis mõjub on IE's proxy kasutamise ärakeelamine. Mugava inimesena tarbin ProxyPali, mis võimaldab IE menüsse ronimise asemel sisse-/välalülitamist teostada nupureal asuvat PP nuppu klõpsides (samas tegeleb PP ainult käsitsi pandud aadressivälja deaktiveerimisega, seega ei ole tast kasu kui tarbitud automaatse konfiguratsioonifailiga varianti).

[HacaX]

Ahjaa, lisaks ka need servud mida hetkel kasutan.
Seega STV/Infoneti klientidele sobivad siis (vähemalt hetkel) need:

cache1.infonet.ee
cache2.infonet.ee
cache3.infonet.ee
cache4.infonet.ee (alles 2005 aasta mingil hetkel uuesti tööle pandud)

"Ametlikku" serverit (kätte saadav nimedega cache.infonet.ee, rcache.infonet.ee, proxy.stv.ee) ei ole mõtet panna, kuna see ei tegele proxymisega vaid juhatab kõik päringud edasi ühele eelnevalt mainitud 4st serverist.

Oleks tore kui teiste ISPide kliendid kes juhtuvad oma võrgu masinaid teadma postitaks nende nimed või IPd.

[raxz]

Elionil
cache.neti.ee:8080

[cky]

Linking - cache.linking.sise

[davidco]

[ref]

[arva]

kas siis elioni klientidel on kasulik seda systeemi rakendada?

[HacaX]

Tuleks kontrollida, et ehk on neid servereid siiski rohkem. Kõige lihtsam viis: anda brauserile söömiseks mõni mitteeksisteeriv aadress (näiteks http://www.sedaadressipoleolemasagaegaseemeidhairi.com/ ) ja uurida proxy tagastatavat veateadet. Näiteks STV kliendina saan järgmise informatiivse teksti:

ERROR: The requested URL could not be retrieved.
While trying to retrieve the URL: http://www.sedaadressipoleolemasagaegaseemeidhairi.com/

The following error was encountered:

Unable to determine IP address from host name for www.sedaadressipoleolemasagaegaseemeidhairi.com
The dnsserver returned:

Name Error: The domain name does not exist.
This means that:

The cache was not able to resolve the hostname presented in the URL.
Check if the address is correct.
Your cache administrator is cachemgr@infonet.ee.

--------------------------------------------------------------------------------

Generated Sun, 08 Aug 2004 19:28:28 GMT by cache1.infonet.ee (squid/2.5.STABLE4)

Huvipakkuv on just viimane rida, kus ilusasti kirjas, et tegelik ühendus käis läbi cache1.infonet.ee (ehkki IE sätetes on cacheks pandud cache.infonet.ee). Ülejäänud 2 serveri (cache2 ja cache3) leidmine oli lihtsalt proovimise küsimus.

[droz]

elionil siis
194.126.101.132 cache.elion.ee
194.126.101.133 cache1.elion.ee
194.126.101.134 cache2.elion.ee
194.126.101.135 cache3.elion.ee
194.126.101.136 cache4.elion.ee
194.126.101.137 cache5.elion.ee
194.126.101.138 cache6.elion.ee

pordiks 8080 või squidi 3128

[kaiowas]

See kõik on ju täielik jama mida siin kirjutatakse. Sellistel puhkudel (kui on mitu cache serverit), kasutab teenusepakkuja hästi suure tõenäosusega mõnda LB süsteemi (loadbalancing), mis tähendab et päringud jagatakse serverite vahel võrdselt või siis koormuse alusel. See tähendab seda, et üldnime taga peitub tegelikult loadbalancer mis on otsast otsani tarkust täis kuidas seda kõike teha, kaasaarvatud seda, et mõne backendi surma korral jagatakse päringud allesjäänute vahel automaatselt ära niimoodi, et klient seda tähelegi ei pane. Seda kõike eirates ja backendi poole otse pöördudest võib lõdvalt sattuda hoopis ülekoormatud serveri otsa sa seega kiiruses hoopis kaotada, mitte või.ta. Samuti on backendi surma korral sul ikaldus majas.
Seega unustage see mitme cache kasutamine enda poolel ilusti ära ja usaldage see ülesanne teenusepakkujale.

[jossi 1]

On esinenud juhtumeid kus teenusepakkuja süsteem ei toimi. Näiteks oli kliendil määratud cache.elion.ee ja netti ei saanud. Pidi käsitsi vahetama mõne teise vastu või siis proxy üldse keelama.

[HacaX]

kaiowas: ei ütleks, et täielik jama. Su jutt on jumala õige, aga sinu usk ISPi tegevusse veidi ülepingutatud. Võib tegelikult täiesti olla, et näiteks Elioni tarbides jookseb kõik õlitatult, aga enda STV peal *on* antud meetodi võit sõna otseses mõttes silmaga näha (lihtne näide: Yahoo!Mail tuleb sõna otseses mõttes Silmapilkselt ette, Infoneti enda ametlikku serverit tarbides mitte). *Miks* see nii on selles suhtes on mul järgnevad mõtted: a) MultiProxy sõna otseses mõttes tarbib (aegajalt) mitut serverit korraga, s.t. üks osa lehest tuleb üht ja teine teist proxyt pidi; IMO STV enda jubin säärast võtet ei tarvita; b) MP pidevalt uurib kui kiired servud on... aegajalt tõesti juhtub täpselt see mis kirjeldasid, et satub ülekoormatud server, aga selle avastuse teeb ka MP suht kiiresti ja alati on võimalik manuaalselt käivitada proxyde kontroll (Check All Proxies nupp)... ju siis toimub kontroll sagedamini kui ametliku servu poolt (ja kui server üleüldse maas on siis avastatakse ka see kuna justnimelt selle tarvis ongi "Default timeout" lahter); c) asi hoolitseb ainuüksi *minu* ühenduse eest, seega ei pea vast muretsema selle pärast, et edasisuunav server *ise* ülekoormatud oleks; d) lihtsalt vandenõuteooria, aga kindel, et ametlik proxy *kõiki* servereid kasutada laseb? Asi saigi esmajoones selle pärast püsti pandud, et endale ei hakanud kunagi silma nagu oleksin liikunud läbi Infoneti 1. serveri, ikka oli veateadetele allkirja pannud 2. või 3. server... äkki 1'le jagatakse mingeid rohkem pappi maksnud pakettide kliente (keda vähem ja seega parem läbilase) vms? Peab tunnistama, et MP väidete kohaselt 1. ei ole reeglina kõige kiirem (vast pigem hoopis hõivatum) aga kes teab kindlalt väita, et sinu võrgus samamoodi on
Kokkuvõtlikult ütleks nii: ei üritagi siin mingit imeasja kokku panna, lihtsalt huvitab *veidike* suurem kontroll selle üle mismoodi minu liikumine võrgus täpselt toimub. Kui asi ka juhtumisi natuke kiirema lehtede laadimise annab, siis seda parem

[kaiowas]

Usu mind, ma olen loadbalanceritega töötanud juba oikuikaua ja tean neist nii mõndagi. Riistvaraliset tehakse seda content switchidega (layer4), tarkvaraliselt on olemas igasugused lahendused, enamasti LVS'i põhised, nagu näiteks ultramonkey jms. See, et content switch võib ülekoormusesse sattuda, on isegi ette tulnud, aga et kernelipõhine LVS droppima hakkaks, pole veel näinud ja seda ka väga suure koormuse ja trafficu juures. See, millise jaotusalgoritmi järgi loadbalanceril toimida lastakse, võib tõesti kiirusomadusi mõjutada, eriti siis, kui kasutatakse tavalist round-robin meetodit, mis ei arvesta hetkel olemas olevaid ja aktiivseid ühendusi, ning laob uusi valimatult otsa. Selles osas tuleks siiski loota teenusepakkuja poolsele mõistlikkusele selliseid asju teada. Muideks, tavaline round-robin tegelikult ei tahagi hästi toimida, see tekitab komplikatsioone erinevate webirakenduste puhul, millel on kasutatud kliendi ip aadressi kontrolli, näiteks erinevad webipõhised jututoad jms. Seal võib juhtuda, et üks päring tehakse ühest, teine teisest cache serverist, täpselt nii, nagu sinu ulmesüsteemigi puhul ja kogu värk saab täiega tala.

[HacaX]

Ja ikka jääb küsimus miks asi nii ulmeline on? Nagu isegi mainisid annab asja ka tarkvaraliselt teha, lihtsalt antud juhul tegeleb sellega ISPi masina asemel kasutaja enda raal...
Lisaks siis veel 3 mõtet miks asi (vähemalt mul) kipub kiirem olema: a) kogu askeldamine käib *minu* mätta otsast vaadates, mitte "üldpildi" (mis IMO peaks ISPil välja nägema umbes selline, et kõigile ühenduses olijatele võimaldada kiireim ühendus aga omada ka mingeid resursse juhuks kui (näiteks) 100+ uut matsi järsku korraga päringutega pommitama hakkavad) alusel; b) ühenduste arv: (vähemalt) IEl oli ju paika pandud kui palju ühendusi mingi serveriga tohib teha (kui ma nüüd segi ei aja siis oli neid HTTP 1.0 puhul 4 ja 1.1 jaoks 2), MPs aga saad ise paika panna palju sa neid tahad... samas loogiliselt võttes ei tohiks tõesti erilist vahet olla kas inffi tuleb 1 või 21 ühenduse kaudu kui tervet ribalaiust ära ei kasutada ; 3) see vast minimaalne kiirusevõit, aga selle asemel, et ronida esmalt jagaja järjekorda ja sealt edasi maanduda tegelikult andmeid liigutava serveri järjekorda hüppan ma otseteed liigutaja juurde...
Aga esitaks säärase imeliku küsimuse lõpetuseks: mis krdi põhjusel kogu värk siis toimib, kui ISPi servu kasutamine peaks iga kell parema tulemuse andma (sest täiesti nõustun, et teenusepakkuja vidin peaks juba kasvõi põhimõtte poolest omama hulga asjalikumat inffi masinate hetkeolukorra kohta kui MP tühipaljas ping)? Või oled sa veendunud, et ma sõna otseses mõttes fantaseerin?

[kaiowas]

Ulmelist ei ole siin mitte midagi, lihtsalt loadbalancer teab backendide kohta tunduvalt enam, muuhulgas kuulavad mõned neist ka serverite südamelööke (heartbeat) ja otsustavad selle järgi koormuse üle, mitte ei mõõda tuimalt aktiivsete ühenduste arvu. Sina seda mitte mingisuguse valemiga kahjuks teada ei saa. Sa mainid siin võimalikki kiirusekaotust, loadbalancerit läbides ? siinkohal sa kahjuks eksid, kuna lb toimib paljuski kui tavaline ruuter, ning vastusepaketid (need kõige mahukamad), tulevad otse backendist ja ei läbi loadbalancerit ennast. Kõige lõpetuseks võin ma öelda ka seda, et isp võib vajadusel neid backende maha korjata või juurde panna niipalju kui heaks arvab ja sina ei saa nende maasoleku kohta mitte midagi uriseda, kuna tegemist on sinu omavolilise häkiga, mitte väljareklaamitud tootega. Kõike eelnevat silmas pidades, pean ma veelkord ütlema, et tegemist on mõttetu häkiga, mille avaldamine "kasulike näpunäidete" all on sobimatu, kuna kutsub üles teisigi samamoodi käituma. Kriitiline mass selliseid "tarkpäid" ja isp'l on tõsine probleem, kuidas serverite koormust kontrolli all hoida, sest mingisugused tüübid käivad otse seal kallal. Cache kasutamise soovitus on igati mõistlik ja teaduslikult tõestatud, kui toimiv idee, kuid mitte sellisel moel.

[HacaX]

No näed, sa oskad ju küll. See oli väga ilus ja korralik põhjendus, millega oleks võinud hoopistükkis alustada (midagi stiilis "jah, *võib* küll juhtuda, et mingid lehed aeg-ajalt tulevad kiiremini, aga samahästi võid ka enamuse ajast niru toru otsas istuda... sellest kuidas sa ISPi poolsete muudatustega kursis ei ole ja millist negatiivset mõju sa kõigile ülejäänud surfajatele avaldad me parem ei räägigi" ). Tubli!
Tegelikult on lugupeetud kasutaja kaiowase postid teema arengule kõvasti kaasa aidanud, sest ta on välja toonud terve hulga võimalikke probleeme: alates sellest, et võib vabalt viletsa proxy peale jääda (selle vastu peaks aitama eelpool mainitud "Check all proxies" nupp); üle selle, et kõigile ei pruugi sugugi meeldida kui poole sessiooni pealt proxyt vahetad (konkreetselt selle efekti vastu ongi pildil toodud kohas "Maintain fixed proxy/IP for web-site" lahter); kuni selleni välja kas see artikkel on üleüldse eetiline, eriti kui vaadata asja selles valguses, et säärae isetegevus võib kahjulikult mõjuda *teistele* ISPi klientidele...
Käin välja oma viimased mõtted, alates "kriitilisest massist". Seda teemat on praeguse seisuga vaadatud 1500+ korda (millest protsendi või kaks võib vabalt minu arvele kanda ), võib arvata, et ka ülejäägist suur osa on refreshi tulemus. Ja lõppude lõpuks kui paljud ikka viitsivad sellise x meetodga jamada. Seega pakuks vast 200 indiviidi kes üleüldse võiks selle projekti ette võtta. Kahtlen sügavalt kui palju on Eestis ISPe kel rohkem kui 1 cache server ja keda säärane hulk häkerdajaid meeleheitesse võiks viia.
Tehnilise külje pealt: minu arusaamised proxy ja koordinaatori suhete osas on igati puudulikud, aga kas ma olen õieti aru saanud, et need on *natuke* tõsisemad kui umbkaudne arvutamine a'la "selle portsu sissetulnud päringutest saadame servule X, mille koormus peaks nüüd olema x, teise osa saadame Y'le mis minu rehkendamise kohaselt peaks olema y% hõivatud, jne"? Kui jah, siis isetegevus ülejäänud võrku eriti häirida ei tohiks: kui kõik MPjad ronivad 1. proxy otsa, siis töödejuhata on sest teadlik ja saadab ametlikku käiku kasutavad tegelased 2. või mõne hilisema serveri peale (ja ka MPjad hakkavad ümber kolima kui ping langeb, ehk siis teisisõnu koormus jaguneb taas laiali, lihtsalt stabiliseerumine ei toimu nii kiiresti kui ISPi enda masina juhendamisel).
Viimaks eetilisuse küsimus... jah, see on problemaatiline. Pole vist midagi muud öelda, et tegelikult kehtib see ksimus iga korra kohta kui üritatakse teha midagi moel, mida pole ette nähtud... ja seda ka siis kui isegi mitte teoreetilist võimalust teiste häirimiseks ei ole (mis antud juhul küll ei kehti)...