Tillämpningsskiktet Tillämpningsskiktet Sidorna 354-399 i boken Dessa protokoll kopplar samman tillämpningar och utnyttjar lägre skikts protokoll Tillämpningar kommunicerar med tillämpningsprotokoll Tillämpningar utnyttjar TCP, UDP och via dessa IP som tjänster Tillämpningar måste förstå port och IP-adresser Tillämpningsskiktets protokoll är i allmänhet planerade för tillämpningens kommunikationsbehov Samtidig eller asynkron kommunikation Meddelandeförmedling, filkopiering, terminalsession, mätdata Tillämpningsarkitektur WWW och HTTP Tillämpningsarkitekturen definierar tillämpningens struktur Vilken information finns var Vilka uppgifter olika delar av tillämpningen har Vilka protokoll används för datatransmission Vilka dataformat används Vi behandlar några vanliga arkitekturer som Klient-server Peer to peer World Wide Web är ett hypertextbaserat multimediasystem som blev populärt i början av 1990-talet Är både tillämpning och plattform för tillämpningar Baserade sig ursprungligen på kopiering av HTML-filer med HTTP-protokollet HyperText Markup Language HyperText Transfer Protocol Filerna befinner sig på servern, klientprogrammet kopierar filer och visar dem för användaren Förverkligar klient-server arkitekturen Servern väntar på tjänstebegäran Klienten kontaktar servern och ber om en tjänst Klientens HTTP-kommunikation Serverns HTTP-kommunikation Klienten (webbläsare) får en URL-adress och tolkar den protokoll://maskinnamn:port/sökväg Klienten öppnar en TCP-förbindelse till servern DNS-förfrågan från namn till IP-adress Kommando till operativsystemets TCP att öppna förbindelse Klienten använder HTTP för att be om filen GET sökväg HTTP/1.0 Host: maskinnamn... Servern har reserverat en TCP-port eller portar och lyssnar på dessa portar väntande på förbindelser Operativsystemet kopplar inkommande förbindelsen och informerar servern om den nya förbindelsen Servern tolkar förfrågan och svarar HTTP/versio status-koodi viesti Om den begärda filen finns HTTP/1.1 200 OK Date:... Samt ifrågavarande fil Serverns svar kan vara en HTML-fil, bild, ljudfil o.s.v.
Klient-server modellen HTTP:s struktur I klient-servermodellen har servern någon resurs (data, räknekapacitet) och servern väntar passivt på klientens begäran om tjänst Ofta talas det om tunna (thin) och tjocka (fat) klienter En tunn klient behandlar inte just data T.ex. terminal-emulaator, WWW-bläddrare En tjock klient behandlar data T.ex. WWW-anslutning till e-post, som ur e- postsystemets synvinkel är en klient Protokollet baserar sig på kommunikation över TCP Klientens viktigaste kommandon (metoder): Command Explanation GET Normal method to request documents HEAD Method to request document headers POST Method to send data to server PUT Method to send a document to server Dataposter i HTTP-klientens pakethuvud HTTP-servern svarar Klienten specificerar kommandot med dessa (några vanliga): Header Accept Connection Cookie Host If-Modified-Since Explanation Usually username:password encoded in base64 If Keep-Alive used connection is not closed after each request on HTTP/1.0 (default behavior for HTTP/1.1) Returns information supplied via a Set-Cookie header (in previous connection) Host and port as listed in the original URL Conditional GET HTTP/Version Status-Code Reason-Phrase Svarmeddelandena är delade i klasser, motsvarande används i många andra Internet-protokoll T.ex. SMTP ja NNTP påminner om dessa 1xx: Information, t.ex. del av förfrågan godkänd 2xx: Lyckad transaktion 3xx: Omdirigering (redirect) 4xx: Fel vid klienten 5xx: Fel vid servern Referer Specifies URL of the page that contained the cross-reference "200" ; OK "201" ; Created "202" ; Accepted "203" ; Non-Authoritative Information "301" ; Moved Permanently "400" ; Bad Request "404" ; Not Found "500" ; Internal Server Error "505" ; HTTP Version not supported HTTP/1.1 svarkoder Några vanliga tilläggsfält i svaret: Content- Encoding Content- Length Content-Type Last-Modified Location Set-Cookie WWW- Authenticate HTTP-svarets pakethuvud Describes the decoding mechanism that must be used to obtain the MIME media type specified in the Content-Type header Number of bytes in the file MIME type and subtype Time and date when document was changed last time New location of the requested document name/value pair to be stored by browser. This pair will be transmitted in the Cookie header in future requests to the same URL Gives authorization type and realm that the client has to supply in an Authorization header
Internets e-post E-postens väg E-posttjänsten fanns långt före WWW I nätbruk från året 1972 E-post är också baserat på servrar, men har skillnader till www I stället för multimediafiler förmedlas meddelanden E-postmeddelanden skjuts fram (push) med SMPTprotokollet mot mottagarens server, varifrån mottagaren hämtar (pull) meddelandet med POPeller IMAP-protokollet Simple Mail Transfer Protocol Post Office Protocol Internet Message Access Protocol Sender Host sends e-mail using SMTP Server forwards mail using SMTP Sender's local server Receiver's local server Client retrieves mail using POP or IMAP Receiver Klient eller server Push- och pullteknologi E-postservern fungerar samtidigt både som server och klient Processen som väntar på post i TCP-porten 25 är server När samma process kontaktar en annan server är den klient Rollerna är alltså inte nödvändigtvis fasta Samma process kunde fungera också som IMAPoch POP server I allmänhet sparas e-posten i användarens postlåda (en fil) och ett annat program används för läsning Vi har alltså varierande roller och skillnad på serverns interna och yttre arkitektur När meddelandet förmedlas vidare med SMPT, skjuts det framåt (push) Mottagande server kan inte veta varifrån det är post på kommande E-post programmet kunde också vara en server som väntar på post Användarmaskiner är inte pålitligt påkopplade och användaren kan önska använda flere klientprogram Posten blir på mottagarens server, varifrån den hämtas (pull) Även HTTP-protokollet i WWW är pullteknologi Klientprogrammet frågar regelbundet (poll) servern om det finns ny post Rollerna i Internets e-post E-postens väg Mail User Agent är programmet som står för användargränssnittet Posten skrivs och läses med detta program Pine, Microsoft Outlook, MH, Mozilla, Elm, mail, Firefox jne. Mail Transfer Agent skickar posten i nätet Skickar vidare meddelandet mellan MUA:n på basen av mottagarens adress Vägval på tillämpningsnivå, inte direkt relaterad till IPvägval MTA kan ändra på mottagaradressen och ta meddelandet i behandling på nytt T.ex. alias,.forward SMTP-meddelandet har två delar Ett skal (kuvert), som SMTP-protokollet använder Innehållet, meddelandet med pakethuvud MUA tar emot meddelandet och skapar ett kuvert MUA skickar meddelandet till den MTA som fungerar som server (enligt inställningar) MTA tar emot meddelandet och sparar den oftast i spoolkatalogen för att vänta på vidare förmedling Slutliga mottagarens MTA sparar meddelandet i mottagarens postlåda Postlådan är en fil, databas eller motsvarande
Store and Forward-konceptet Exempel på SMTP-session Lagrad överföring (fi etappivälitys) Mottagaren sparar meddelandet för det skickas vidare I minnet eller på skiva IP-växlar tar emot IP-paketet före de avgör i vilken utgående kö paketet placeras Om kön är full, slopas paketet E-postservrar tar emot meddelanden, sparar dem i spool-katalogen och bekräftar att de tagit emot meddelandet Ansvaret flyttas, i felsituationer kan servrarnas logfiler läsas för att red ut var meddelandet tappades morphine ~ 1$ telnet mail.tml.hut.fi 25 Connected to mail.tml.hut.fi (130.233.47.34). 220 mail.tml.hut.fi ESMTP helo morphine.tml.hut.fi 250 mail.tml.hut.fi mail from: joulupukki@korvatunturi.fi 250 Ok rcpt to: kiravuo@tml.hut.fi 250 Ok data 354 End data with <CR><LF>.<CR><LF> From: Joulupukki@Korvatunturi.fi To: Kaikki kiltit lapset Subject: Joulu tulee Muistakaa olla kiltteja, pukki valvoo. T. joulupukki. 250 Ok: queued as 9C5773A2CCC quit 221 Bye Mottagna meddelandet Meddelandets struktur Return-Path: <joulupukki@korvatunturi.fi> Received: from mail.tml.hut.fi (mail.tml.hut.fi [130.233.47.34]) by tml-yp-4.tml.hut.fi (Cyrus v2.2.12) with LMTPA; Tue, 20 Feb 2007 14:11:19 +0200 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by mail.tml.hut.fi (Postfix) with SMTP id 9C5773A2CCC for <kiravuo@tml.hut.fi>; Tue, 20 Feb 2007 14:10:11 +0200 (EET) From: Joulupukki@Korvatunturi.fi To: Kaikki@tml.hut.fi, kiltit@tml.hut.fi, lapset@tml.hut.fi Subject: Joulu tulee Message-Id: <20070220121011.9C5773A2CCC@mail.tml.hut.fi> Date: Tue, 20 Feb 2007 14:10:11 +0200 (EET) Muistakaa olla kiltteja, pukki valvoo. T. joulupukki Kuvertet har MTA:s uppfattning on sändare och mottagare Kan skilja sig från meddelandets sändare (From:) och mottagare Virus och spam missbrukar denna egenskap SMTP:s MAIL FROM och RCPT TO utnyttjar dessa Pakethuvud Från början av meddelandet till första tomma raden Meddelandets stomme Efter pakethuvudet SMTP ja DNS Att läsa post i nätet MX-dataposter Mail exchanger dataposterna i DNS-systemet Berättar vart post till en viss adress skall styras Gör det möjligt att prioritera servrar och presentera reservservrar T.ex.: sral.fi:s MX-data sral.fi. IN MX 10 bar.foo.fi. sral.fi. IN MX 20 smtp3.kolumbus.fi. Logik: posten skickas till servern med lägsta nummer i MX-listan som kan kontaktas Om ingen MX-datapost har definierats, används A- dataposten (IP-adress) Inom samma maskin (t.ex. Unix-server) läses posten direkt från postlådan Fil, t.ex. i /var/spool/mail katalogen MUA kontaktar servern och ber om klientens meddelanden Förmedlar användarnamn och lösenord Kan använda SSL-kryptering POP, Post Office Protocol TCP-port 110 (version 3) Används i allmänhet bara för att hämta post IMAP, Internet Message Access Protocol TCP-port 143 Stöder flere mappar (kataloger) på servern
E-postens helhetsarkitektur E-postens arkitektur består av många delar och den kan studeras ur olika vinklar Abstrakt, MTA, MUA, meddelandets struktur Konkret, SMTP, POP, IMAP, meddelandets format definierad i RFC-2822 Enligt kraven för roller och programprocesser Väsentliga nyttan med arkitekturen är att delarna kan bytas ut och den interna strukturen döljs Postlådans interna arkitektur påverkar inte andra program ifall postlådan kommunicerar enbart via SMPT och IMAP När systemet har en arkitektur, kan enskilda delar utvecklas utan att röra andra delar Multipurpose Internet Mail Extensions Exempel på införande av nya egenskaper i ett existerande system Postsystemet var ursprungligen definierat bara för 7 bitars ASCII tecken Räcker inte ens för engelska, för att inte tala om bildbilagor MIME utvidgar möjligheterna att använda olika teckenuppsättningar, alternativa format och bilagor MIME-definitionerna används även i samband med andra protokoll som HTTP MIME-meddelande (delar) MIME-meddelande fortsätter FROM: "MS Security Center" <aytnddhiqp@support_msdn.net> TO: "Partner" <partner@support_msdn.net> SUBJECT: Current Net Security Patch Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="dqrvzwnprd" --dqrvzwnprd Content-Type: multipart/related; boundary="jtdukndxczlsbnv"; type="multipart/alternative" --jtdukndxczlsbnv Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Microsoft Partner this is the latest version of security update, the... --jtdukndxczlsbnv Content-Type: text/html Content-Transfer-Encoding: quoted-printable <HTML>... --jtdukndxczlsbnv-- --dqrvzwnprd Content-Type: image/gif Content-Transfer-Encoding: base64 R0lGODlhaAA7APcAAP///+rp6puSp6GZrDUjUUc6Zn53mFJMdb... --dqrvzwnprd Content-Type: application/x-msdownload; name="install65.exe" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAA... --dqrvzwnprd-- MIME Spam Meddelandetexten kan innehålla flere objekt En del av objekten alternativa, t.ex. Meddelandet som text och HTML-kodat Sändaren känner i allmänhet inte till egenskaperna hos mottagarens MUA Binärdata kodas så att det passerar 7 bits systemen Alla SMTP MTA stöder inte 8 bitars data Base-64 är en typisk kodning för data Quoted-printable kodning används för enskilda 8 bitars tecken i texten Egen kodning för huvudfälten för meddelandeförmedling From: =?GB2312?B?za/R1cHB18s=?= <info@shanghaity.com> Subject: =?GB2312?B?za/R1cHB18vT68T6ubK2ybn6x+w=?= Reklampost som mottagaren inte önskar motta Märkbart problem på grund av volymen (100-200 meddelanden dagligen) Skickas på olika sätt Sändande firma har egna e-postservrar Utnyttjar stora mängder vanliga hemmaskiner som har kapats Hitta en postserver som vidarebefordrar meddelanden trots att de inte kommer från adresser servern betjänar eller är på väg till sådana adresser Meddelandet har oftast förfalskad sändar- och mottagarinformation Ett meddelande skickas med stort antal (tusentals) mottagare, så att vidarebefordringsbördan blir hos servern
Bekämpning av spam Diskussionsgrupper ((Usenet) News) Hindra vidarebefordring (relaying) i e-postservern Meddelandet skall vara på väg till eller från egen domain för att det hanteras Skydda hemdatorn Svarta listor för e-postservrar Lista på kända spam-källor Bayesian filtrering Lär sig känna igen spam För tillfället den lösning som verkar fungera bäst Juridiska lösningar Mera information: http://spam.abuse.net/ E-post är dubbelriktad kommunikation i liten grupp och WWW enkelriktad kommunikation för stor grupp News-systemet utvecklades på 1980-talet (före WWW) till ett omfattande distribuerat diskussionsforum Diskussionen är delad i grupper och artiklar Samma artikel kan skickas till flere grupper Grupperna har namn sfnet.harrastus.retkeily Artiklarna har unika identifierare Message-ID: <Pine.GSO.1.64.0702014510.4033@hila.hut.fi> Servrarna byter artiklar sinsemellan News-systemets arkitektur Icke-hierarkiska nät Servrarna har information om andra servrar De kontaktar regelbundet varann och byter artiklar Med hjälp av Message-ID kan servern avgöra om den redan har ifrågavarande artikel Använder protokollet NNTP, Network News Transfer Protocol Servrarna bildar ett icke-hierarkiskt nät (P2P-nät) där en ny artikel sprider sig till alla servrar i nätet (flooding) Användarna läser artiklar med ett klientprogram från en server i P2P-nätet I P2P (Peer to Peer) -nät är maskinerna relativt jämbördiga sinsemellan Skiljer sig alltså från klient-server modellen De använda protokollen kan skilja på klient- och serverrollerna Typiskt är att en maskin kontaktar en annan Innehållsmässigt är kommunikationen jämbördig Oftast ingår både klient- och serveregenskaper i samma tillämpning som kan fungera i båda rollerna Arkitekturen är ofta distribuerad och dynamisk News-servrarna känner bara sina grannar, så det är lätt att koppla nya servrar till nätet Fildelningsnät Protokoll och gränssnitt Ny utveckling jämfört med News-systemet Vanliga användare kan byta filer med varandra Att hitta rätt fil är den centrala frågan i denna arkitektur Indexserver som söndrar P2P-modellen Identifierare som pekar till filen och algoritm som frågar andra servrar information om filen Delning filen i mindre stycken och sökning av (redundanta) stycken på motsvarande sätt tills hela filen är samlad Teknologierna för fildelning utvecklas som bäst och tillåter bl.a. kryptering och delning av filen så ett ingen vet var fildelarna finns, men de kan fås via P2P-nätet Olika enheter i nätet använder protokoll för att utbyta information Firefox i OS X kan skicka e-post till Sendmail i Unix,varifrån mottagaren läser posten med Outlook i Window Ett gemensamt språk täcker skillnader i implementationerna Protokollen använder tjänster, som lägre skikt erbjuder, via gränssnitt Tillämpningar talar tillämpningsprotokoll med TCP/IP via socketgränssnittet Ethernet-hanteraren talar med ethernet-kortet via drivrutingränssnittet Gränssnitten är ofta olika för olika av operativsystem Gränssnittet har inte betydelse för protokollet funktion, men inverkar på hur programmet fungerar i olika omgivningar Internet-protokollfamiljen ger ett abstraktionsskikt som täcker egenskaperna hos olika fysiska kommunikationsteknologier Protokoll på högre skikt litar på tjänster från protokoll på lägre skikt