Minimalne mi chybi jeden podstatny - a sice, ze predpoklada, ze komunikace je end-to-end, tedy ze se spolu skutecne bavi dva koncove body.
Bohuzel toto platilo v drevnich dobach internetu pred mozna jeste 7 lety, nikoli vsak pozdeji, nikoli dnes a do opravdoveho nasazeni IPv6 nikdy v budoucnu. To co popisuje je velmi zajimavy material, ktery vsak rozdhodne neidentifikuje a nepocita s jakymkoli prostrednikem a uz vubec to nehovori o uzivatelich v dnesni podobe internetu.
V uvedenem oboru (clickstream analyza) se nepohybuji, zrejme dokazi analytici ziskat zajimave udaje (verim, ze daleko hodnotnejsi nez Page Views, kterym jsem se smal od zacatku - coby material pro reklamni agentury), otazka vsak je, zda-li pote tyto udaje pravdive interpretuji tak, aby odpovidali skutecnosti, o kterych se tu pise...
Osobne se vsak domnivam, ze za soucasneho stavu veci je sniffing metoda, kterou nelze ziskat data, ktera jsou zde popisovana jednoduse proto, ze TCP spojeni, jak je ustanoveno, neidentifikuje end-to-end komunikaci (zejmena u firemnich zakazniku je to velmi podstatne).
Ovsem je tu jeste druha cast a sice stravena doba a zda-li uzivatel obdrzel pozadovana data a jaky byl response time. Bohuzel, Vase informace mne rozhodne neuspokojily, naopak utvrdily v tom, co jsem si myslel, ze vydavate za realna data neco, co Vam 'vypadne' z analyzy a o cem jste mozna presvedceni, ze jsou to data, ktera jste v clanku pomerne rozsahle popsal. Domnivam se, ze nejen ja (coby clovek, zabyvajici se spise tim HTTP, TCP a nizsimi vrstvami) mam pocit, ze zrejme netusite co se muze na urovni HTTP, TCP a nizsich vrstev ve skutecnosti dit a ze to, co Vy namerite nejsou ve skutecnosti v zadnem pripade verohodna data, aspon ne ve smyslu, o kterem pisete. Jsou to data, ktera namerite, resp. analyzujete end-to-end komunikaci, ale nikoli od serveru k prostrednikovi (ci v lepsim pripade uzivateli), ale od serveru k prvnimu 'prestupnemu' bodu. Tvrdite, ze vychazite z pesimisticke varianty - v tom pripade Vase zavery nechapu o to vice, ze v tomto pripade v podstate nemate co merit, nic totiz nejste bez dodatecnych aplikaci (napr. applet na strane klienta) schopni zjistit. Tak jako ten proxy server nemusi byt v ceste osamocen (on totiz muze byt nastaven tak, aby si sam 'pushoval' data - uzivatel je tom irelevantni) - muze byt po ceste kaskada/strom cache serveru (rovnez realny stav), data mohou byt nekolikanasobne zpomalena/zahozena/duplikovana po ceste za tim prvnim 'end', ktere merite. Stejne tak jsem nemluvil jen o proxy serverech, coby aplikacnich aparatech, ale o obecnych NATovacich zarizenich - pokud si myslite, ze v ceste byva zpravidla maximalne jeden - mohu Vas vyvest z omylu, struktury VPN siti byvaji casto velmi slozite, nekdy az nad nutnou miru.
Obaval jsem se, ze je to opet spise marketing a penize nez skutecne dobre analyticke nastroje, Vase odpoved mne v tom utvrzuje cim dal vice, myslite si, ze se ve sve argumentaci (zustanme prosim v ciste technicke rovine) mylim?
Vezmu-li Vas doslova, pak tvrdite, ze transportni vrstva - ve Vasem pojeti protokol TCP - je komunikace uzivatelsky pocitac vs. server - dovolim si Vas vyvest z tohoto omylu - uz pri aplikaci zaklaniho NATu nekomunikuje server s uzivatelskym pocitacem, alebrz se strojem zajistujicim tento NAT. Ja se celou dobu nebavim o routerech (smerovacich, chcete-li cestinu) mostech (co jineho nez opakovac je most? - ja bych se drzel jasneho terminu bridge) a podobne, ktere konci na urovni IP protokolu (sitova vrstva), ale o TCP. IP protokol konci na urovni IP adres, ale jiz nikoli sluzeb, k tomu abyste byl schopen odlisit provoz na urovni aplikaci, potrebujete vedet pozadavky sluzby (TCP, UDP, RAW apod.) a tak se dostavate na transportni vrstvu. Rici, ze se neprovadi odposlech pod transportni vrstvou bohuzel svedci o tom, ze o vrstvove architekture zrejme moc nevite, jinak mi neni jasne, jak chcete zjistovat treba response time, chyby na siti apod. (protokol ICMP lezi presne na urovni IP protokolu, o transportnim layeru si nechte jenom zdat)...
Bez urazky bych Vam doporucoval nejprve patricnou problematiku nastudovat, zatim tu cim dal vice mlzite a ukazujete, ze skutecnost je asi nekde jinde, nez kam ji chcete dostat...
PS: Jak vite, ze transportni vrstva ma co do tuseni sitove komunikace, co kdyz je nizsi vrstva resena uplne jinym IPC mechanismem?
Co se tyce reseni vs. komercni uspech - je to presne jak napsal kolega - mozna jste zaznamenal obycejne teplomery vs. merice mikrovlneho zareni apod. - merit skutecny vyznam a dopad technologie dle jeji komercni uspesnosti je jedna cesta, poctiva prace a fakta je vsak bohuzel casto o necem jinem - ovsem vzdyt mame prece kapitalismus, ne?
Coze?
Cookie prece identifikuje uzivatele, nikoli pocitac (aspon pokud vim, tak ruzni uzivatele stejneho pocitace maji cookie file kazdy zvlast ve svem domovskem adresari).
-Yenya
I kdyz, je pravda, ze za muj dojem "vytrzenosti" mozna muze ten, kdo vybral neadekvatni titulek (ja vim, jde o pocet hitu ...), ktery rozhodne neevokuje dobrou predstavu toho, co bude obsahovat clanek - a proto jsou mozna ma (zklamana) ocekavani neduvodna ....
ČLÁNKY DO MAILU