Proxy-server och Ericssons e-box

Studie av proxy-tjänster och

e-boxen som proxy i hemnäten

 

 

 

 

 

 

 

 

 

 

 

____________________________

Martin Österberg Gävle

it96mao@student.docs.uu.se 1999-04-11

 

Proxy-server och

Ericssons e-box

studie av proxy-tjänster och e-boxen som proxy i hemnäten

Denna studie granskar några proxy-tjänster för Internet, både vanliga, som "caching" och sådana under utveckling, som till exempel anpassning av hypertext-protokollet HTTP för WAP-telefoner (Wireless Application Protocol).Därefter studeras huruvida Ericssons nya hem-server, eboxen, lämpar sig som proxy för dagens och morgondagens krav på flexibla och robusta nätverk.

Introduktion

Sedan några år tillbaka har proxy-tjänster använts som en brygga för att låta användare av ett internt intranet få tillgång till det världsomspännande internet. Proxy-tjänsterna har alltsedan dess utvecklats till att innehålla mer och mer funktionalitet, och idag är de en viktig del av nätverksarkitekturen för att få trafiken att flyta någorlunda jämnt och behagligt. Under året lanserar Ericsson en ny produkt, kallad eboxen. Denna skall i framtiden sitta i varje hem och ge invånaren tillgång till internet och en mängd andra tjänster, till exempel IP-telefoni och fjärrstyrning av hushållapparater.

Denna rapport beskriver inledningsvis några vanliga proxy-tjänster med några exempel. Sedan beskrivs mer moderna och framtida applikationer, samt några försök att implementera dessa. Därefter introduceras eboxen som en hem-server och Internet-leverantör. Slutligen förs en diskussion om eboxens lämplighet som proxy för dessa nätverk. Det visar sig att eboxen är lämplig för vissa typer av proxy-tjänster, men mindre lämpad för vissa andra. Detta beror till största delen på eboxens fysiska arkitektur; avsaknaden av permanent lagringskapacitet.

Proxy

Här beskrivs den allmänna modellen för proxy-tjänster, termen proxy definieras och exempel på vanliga tjänster tas upp.

Vad är en proxy?

En proxy kan ses som en ställföreträdande klient, som förser den riktiga klienten med anpassad information från någon källa på nätverket. En definition av proxy från Internet Requests for Comments [1] lyder:

"An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them, with possible translation, on to other servers. A proxy must interpret and, if necessary, rewrite a request message before forwarding it. Proxies are often used as client-side portals through network firewalls and as helper applications for handling requests via protocols not implemented by the user agent." Bild 1 illustrerar proxyns placering i den traditionella klient-servermodellen.

En proxy kan alltså utföra i stort sett vilken handling som helst på de data som flyter mellan servern och klienten. Regeln är dock att servern inte skall uppfatta att en proxy finns mellan den och klienten; proxyn skall imitera sin klient gentemot servern.

vanliga proxy-tjänster

Från början utvecklades proxy-applikationer för att låta till exempel de anställda på ett företag med ett slutet intranet få en väg ut till Internet [2], på ett säkert och enkelt sätt. Nu räckte det med att ha en proxy körandes på brandväggsmaskinen, så kunde alla anställda gå genom den för att få tag i dokument, filer, och andra nättjänster. En annan förtjänst var den att proxyn kunde tala det språk (protokoll) som de externa Internet-tjänsterna krävde, medan den enbart talade HTTP med de interna klienterna, vilket underlättade för "browser-programmen" som då inte behövde ha stöd för alla förekommande protokoll på Internet, utan kunde nöja sig med HTTP. Senare kom idén med "caching" fram, dvs att proxyn spar hämtade filer så att de inte behöver laddas ner igen om klienten vill gå tillbaka senare. Det visade sig att caching gav stora bandbreddsbesparingar, och en rad andra fördelar, som dock inte skall tas upp här, då det är ett omfattande ämne i sig. Traditionellt används proxy också för att föra loggbok på trafiken som flödar genom den. Detta gav administratörer kontroll över användarnas surfarvanor, samt gav statistiskt underlag för vissa delar av caching-problematiken. De funktioner som nämnts här stöds av de mest förekommande proxt-applikationerna, bland annat av CERN:s httpd [3].

nyare proxy-tjänster

Allteftersom Internet expanderar, blir mer trafikerat och mer spritt vad gäller de typer av fysiska nätverk mellan routrar (Ethernet, BlueTooth, infraröda nätverk, satellitlänk, uppringd förbindelse, m.m.), blir också variationen i kapacitet större och större mellan olika delar i nätverket. Dessutom finns stora variationer i hårdvara vad gäller till exempel minneskapacitet, skärmstorlek och färgrepresentation. I försök att utjämna trafiken och inte belasta nätverket mer än nödvändigt, har det kommit förslag på lösningar som använder sig av proxy-applikationer. Dessa går ut på att inte skicka mer information än nödvändigt till klienter med till exempel låg skärm-upplösning eller låg- bandbreddsuppkoppling. I detta avsnitt skall vi titta på några tjänster som framtidens proxy-applikationer bör hantera, samt några försök att implementera dessa tjänster.

proxy-lösningar tll kapacitetsvariationer över internet

Det ökande intresset för överbyggande av heterogeniteten i dagens Internet hänger samman med det växande kravet på mobila klienter, där egenskaper som bandbredd och skärmkapacitet är flaskhalsar för kommunikationen med resten av nätverket. Det finns tre möjligheter att hantera de klient-specifika avvikelserna för dataöverföring till en server någonstans på Internet:

  1. Man skriver applikationer till de mobila klienterna som själva hanterar problemet. Detta leder till att klienterna måste vara komplexa och flexibla, vilket kontrasterar mot den låga kapacitet som mobila klienter ofta har.
  2. Man skriver server-applikationer så att de hanterar olika klienter olika. Detta leder till att alla servrar i princip måste skriva om sina applikationer, och med tanke på de belopp som finns investerade i den funktionella strukturen som finns idag, är det knappast rimligt.
  3. Man har en proxy mellan klient och server som sköter hanteringen så att servern inte ser någon skillnad på klienterna, och klienterna får anpassad trafik kommunicerad till sig. Detta sätt att lösa problemet har åtminstone tre fördelar [4] med sig gentemot de andra två, nämligen: Det krävs ingen omarbetning av de existerande strukturerna och tjänsterna på Internet. Det är lätt att göra prototyper och testa dem på befintlig utrustning; man behöver ju inte utveckla nya server- och klientapplikationer för varje försök. Det har visat sig vara lönande att ha funktionalitet centralt i nätverken, jämfört med att ha den i ändstationerna.

exempel på tjänster

De tjänster det i första hand rör sig om handlar om att minimera datamängden som skickas mellan proxyn och klienten. Exempel på detta är:

Detta är exempel på fasta tjänster som en proxy-server kan leverera till klienten. Vissa inställningar av variabler för proxyns funktion kan göras via meddelanden från klienten, eller information från porxyns omgivning. Den stora fördelen med de modernare proxy-servrarna är dock att de tillåter en dynamisk nedladdning och exekvering av proxykod, eller filterkod, antingen från klienten eller från någon källa på Internet.

Denna möjlighet banar väg för godtyckliga filter och proxy-tjänster att exekvera på proxy-maskinen och tillåter därför ohämmad utveckling av nya tjänster och applikationer. En version av en sådan proxy har utvecklats av Bruce Zenel och Dan Duchamp vid Columbia Univerity, USA [4]. Deras funktion för den dynamiska nedladdningen av filter bygger på att man infogar det exekverande filtret i dataströmmen mellan server och klient. För att åstakomma detta, flyttar de först klientens socket till proxyn [8]. Därefter kan ett filter laddas ner från klienten eller från någon annan källa på det fasta nätverket. Filtret startas och kopplas till proxyns socket mot serversidan. Från filtrets utström görs en ny koppling tillbaka till klienten. På detta sätt märker servern inte att en proxy har satts in mellan den och klienten utan antar att den talar direkt till klienten. Metoden att använda en flyttbar socket kräver dock extra stöd från operativsystemet.

En annan proxy som tar hänsyn till klientens specifika önskemål kallas OreO, och har utvecklats av C.Brooks, M.S. Mazer, S.Meeks och J. Milller vid Open Software Foundation [6]. Denna inriktar sig främst på att förbättra kommunikationen av HTTP-data, och är inte specifikt utvecklad för mobila användare. Även om deras lösning inte stödjer dynamisk laddning av kod, har de utvecklat ett verktyg för att lätt kunna skapa och köra ny filterkod. De ser sin applikation som ett "rån"; som en fyllning omgiven av två kex. Kexen sköter mottagandet och sändandet av data i dataströmmen, medan en applikationsutvecklare själv kan skriva "fyllningen" som skall filtrera HTTP-strömmen till klienten. OreO:n kan användas för att samla in data och bygga en dynamisk modell av nätverkets aktuella tillstånd, eller tillgodose personliga preferenser för vad man vill ha ut av sin nätverkskontakt.

Ett tredje alternativ kommer från Kalifornien [5]. Tjänsterna är i princip desamma som för [4], men här har man lagt till en finurlig funktion. Mycket av den data som skickas till klienten "yxas till" av deras proxy, så att den blir mer grovkornig, till exempel sämre upplösning av bilder och video, eller omformatering av text. Denna proxy tillhandahåller en möjlighet för klienten att "zooma" in ett parti som proxyn har degenererat, så att klienten kan få en finare upplösning på valda delar av informationen när så önskas. Denna metod kallar de att "destillera" och "raffinera".

Nu när vi har fått en uppfattning om vad en proxy gör eller kan göra, eller borde kunna göra skall vi ta en titt på Ericssons senaste invention, eboxen, och slutligen kommentera dess lämplighet för ovanstående proxy-tjänster.

eboxen

I utvecklingen av det världsomspännande Internet ses nu hemnäten som nästa stora frontlinje. Man [7] räknar med en enorm marknad för de uppkopplade hemmen, och alla tjänster som kan säljas in i hushållen. För att vara med på en bit av kakan har Ericsson utvecklat en del av denna uppkopplade infrastruktur, nämligen eboxen.

Vad är en ebox?

Eboxen är en förmedlare av de tjänster som skall säljas till hemmen i framtiden. Det är en server som sitter uppkopplad mellan hemmets lokala närverk och det stora Internet (bild 2). På denna apparat är det tänkt att applikationer skall kunna laddas ner och köras, för att tillgodose någon nytta för hemägaren. Tjänst köper hemägaren av ett företag som tillhandahåller den och står för underhållandet av applikationens liv. Standardtjänster är till exempel Internetaccess och IP-telefoni. Utåt mot Internet har eboxen oftast en fast uppkoppling till ett snabbt nätverk, eller en uppringd förbindelse via telefonnätet eller ISDN. Innåt, mot hemmet, är eboxen som en spindel i det lokala nätverket av apparater, givare, datorer, telefoner, med mera.

Hårdvarumässigt liknar en ebox en standard-PC. Den har 32-bitars processor, upp till 32MB DRAM i internminne och kortplatser för nätverkskort (Ethernet, ISDN). Det som skiljer eboxen från en vanlig PC är att den inte har någon hårddisk. Den har inte heller någon skärm, tangentbord eller mus. Eboxen är alltså helt och hållet byggd för att fjärrstyras. Denna fjärrstyrning står nätverksleverantören för; det är inte användarens uppgift att sköta om eboxen.

Även när det gäller mjukvara följer eboxen existerande modeller, och kör ett UNIX-baserat operativsstem. Detta OS tillåter applikationer att köras säkert och avskärmat från varandra. Det finns dock möjligheter för processer att kommunicera med varandra via väl definierade gränssnitt. I systemmjukvaran ingår dessutom webbservrar, WAP-servrar, och en JVM (Java Virtual Machine) på vilken serviceapplikationerna körs.

Nästa nivå i mjukvaran är standardapplikationer ,"basic services", som tillexempel IP-telefoni och Internetaccess. Dessa kör närmare hårdvaran än serviceapplikationerna som köps in utifrån.

En tjänst som ett företag vill sälja till hemägare implementeras som en boxlet. En boxlet är ett stycke Javakod som följer vissa restriktioner, vad gäller tillgången till resurser i eboxen. Denna boxlet kan laddas ner och exekveras på eboxens JVM, som innesluter exekveringsmiljön i en cell, som representerar de resurser som finns tillgängliga för applikationen.

eboxen som hemma-proxy

Placeringen av eboxen mellan hemmets lokala nät och ett större, med Internet sammankopplat, externt nätverk gör den väl lämpad för proxy-uppgifter. Eftersom den kommer att försörja hemmen med access till Internet, får den en viktig roll i att sköta denna access så smidigt och effektivt som möjligt. Visionen om hemnäten är bland annat att man inte skall dra kabel runt hela huset, utan informationsutbytet mellan apparater skall ske antingen genom befintliga kablar (såsom el-nätverket) eller radionätverk (som BlueTooth). Detta kräver att eboxen kan tala olika språk med sin a sammankopplade parter (telefoner, intelligenta kylskåp, smarta tvättmaskiner, digitala tandborstar, vad vet jag). Eftersom dessutom eboxen ofta kommer att sitta i externa nätverk av hundratals eboxar, blir det viktigt att kunna styra trafiken på ett bra sätt och anpassa skickandet av data efter aktuella förhållanden. En duktigt implementerad proxy skulle kunna underlätta detta. Om man jämför funktionaliteten hos eboxen med den proxy som utvecklats av universitetet i Columbia, och deras sätt att dynamiskt ladda ned filterkod ser man en möjlighet till sammansvetsning av de två. Man kunde ha ytterligare en standardservice på eboxen, tillsammans med IP-telefoni och Internetaccess, som utgör kärnan i en proxy. Denna kan sedan tillåta nedladdning av valfria filter för olika datatyper, typer av strömmar, protokoll, etcetera. Sedan kunde var och en som ville utveckla sina egna filter och sälja dem som tjänster till hemnätsägare som vill utöka sin nätkapacitet.

Det finns dock en viktig proxy-tjänst som eboxen inte är bra på (och aldrig kan bli det heller) och det är caching. eboxen saknar totalt permanent minne. Den har enbart arbetsminne, och detta duger inte om man vill spara alla dokument man besökt. Det kan också bli problem med spooling, det vill säga att proxyn spar meddelanden som klienten inte har läst, och kanske inte kommer att läsa, som tillexempel e-post.

sammanfattning

Dagens växande Internet har också en växande heterogenitet. Olika typer av hårdvara och lokala nätverk kopplas in i det världsomspännande. För att klara av detta med någorlunda bibehållen och jämn nätverkskapacitet behövs en intermediär belastningsutjämnare. Detta är just vad en proxy är! De tjänster som krävs (eller kommer att krävas inom kort) är bland annat följande:

När det gäller eboxen, verkar det uppenbart att det behövs en bra proxy för att hantera alla dessa protokoll och tjänster på ett bra sätt. Eboxen har en strategisk placering mellan lokala hemnät och publika WAN-nät. Detta gör den mycket lämpad som proxy för hemmet, där den kan sköta sitt jobb på ett kundanpassat sätt. Den allmänna arkitekturen gör eboxen lämpad för så kallad dynamisk nedladdning av proxykod, vilket gör den lätt att uppdatera och anpassa efter nätverkets aktuella belastning.

Det finns dock nackdelar med att anlita eboxen som proxy. Avsaknaden av permanent minne gör den mindre lämpad för minneskrävande applikationer såsom caching, och mer lämpad för rena översättnings-applikationer.

slutsats

Enligt min mening är det uteslutet att köra en ebox utan någon proxy. Dess tillämpning kräver det. Emellertid finns det vissa tjänster som eboxen inte kan lösa effektivt, till exempel spooling. Därför vill jag göra följande förslag på användandet av Ericssons ebox som proxy-server för hemnäten:

På eboxen bör finnas inbyggd en kärna för proxy-hantering, implementerad som en "basic service", liknande den som Zenel och Duchamp har utvecklat, för att ladda ner och köra godtycklig proxykod. Dessutom har man både vid Berkley och från OSF visat på exempel på proxy-tjänster som genom att transformera dataströmmarna skulle minska trafiken i hemnäten, som kanske inte alltid har så hög prestanda. Denna typ av hantering av kontinuerliga dataströmmar är något som eboxens arkitektur underbygger, medan mer minneskrävande applikationer undergrävs av bristen på långtidsminne. När det gäller tjänster såsom caching och spooling, kan de förläggas till någon mer central server, där dess cache skulle bli till nytta för fler användare än bara de i det egna hemmet. Denna typ av distrubierad proxyanvänding är för övrigt något som jag stödjer och tror på inför framtiden.

Referenslista:

[1] Internet Requests for Comments (RFC) at Ohio state univerity. http://www.cis.ohio-state.edu/htbin/rfc/rfc1945.html

[2] A. Luotonen; CERN, K. Altis; Intel, World-Wide Web Proxies, 1994

[3] CERN hypertext daemon, URL: http://info.cern.ch/hypertext/WWW/Daemon/Status.html

[4] B. Zenel, D. Duchamp, A General Purpose Proxy Filtering Mechanism Applied to the Mobile Environment, MOBICOM 97 Budapest Hungary.

[5] Fox, Gribble, Chawathe, Brewer, University of California, Berkley, IEEE Personal Communications August 1998.

[6] Brooks, Mazer, Meeks, Miller, Application-Specific Proxy Servers as HTTP Stream Transducers, Open Software Foundation, 1994.

[7] M. Liljestråle, T. Idermark, J. Vasell, Ericsson’s e-box system – An electronic services enabler, Ericsson Review No. 1, 1999.

[8] Brake, Badrinath, Handoff and System Support for Indirect TCP/IP. In Proc. Second Symposium on Mobile and Location-Independent Computing (Aprill 1995) USENIX, pp. 11-24.