Warstwa aplikacji
Architektura aplikacji sieciowych Architektura klient-serwer
Architektura aplikacji sieciowych Architektura P2P
Cechy aplikacji sieciowych Skalowalność Anonimowość Samoorganizacja sieci Odporność na awarie Koszty NAT i zapory sieciowe
Komunikacja procesów Komunikacja procesów dwóch różnych systemów końcowych polega na wymianie komunikatów za pośrednictwem sieci komputerowej. Proces nadawczy tworzy komunikaty i umieszcza je w sieci. Proces odbiorczy otrzymuje te komunikaty i ewentualnie odpowiada, odsyłając własne komunikaty.
Procesy klienta i serwera Biorąc pod uwagę sesję komunikacyjną pomiędzy parą procesów proces inicjujący połączenie (łączący się na początku sesji z drugim procesem) jest określany mianem klienta. Z kolei proces oczekujący na połączenie w celu rozpoczęcia sesji jest nazywany serwerem.
Interfejs łączący proces i sieć komputerową
Usługi transportowe dostępne aplikacjom Niezawodny transfer danych Przepustowość Czas Bezpieczeństwo
Usługi transportowe dostępne w Usługi protokołu TCP Usługi protokołu UDP Internecie Zastosowanie Utrata danych Przepustowość Zależność od czasu Transfer plików Poczta elektroniczna Strony WWW Telefonia internetowa wideokonferencje Strumieniowa transmisja danych a-v Gry interaktywne Przesyłanie wiadomości błyskawicznych Nie może dojść do utraty danych Nie może dojść do utraty danych Nie może dojść do utraty danych Utrata danych jest dopuszczalna Utrata danych jest dopuszczalna Utrata danych jest dopuszczalna Nie może dojść do utraty danych Użycie aktualnie dostępnej przepustowości Użycie aktualnie dostępnej przepustowości Użycie aktualnie dostępnej przepustowości Audio-od kilku kb/s do 1Mb/s Wideo-od 10kb/s do 5Mb/s Audio-od kilku kb/s do 1Mb/s Wideo-od 10kb/s do 5Mb/s Od kilku kb/s do 10 kb/s Użycie aktualnie dostępnej przepustowości Nie Nie Nie Tak-kilkaset milisekund Tak-kilka sekund Tak-kilkaset milisekund Tak i nie
Zabezpieczenie protokołu TCP Ani TCP, ani UDP nie obsługują szyfrowania danych. Dane przekazywane do gniazda przez proces nadawczy biegną do procesu odbiorczego w swojej pierwotnej postaci. Dlatego opracowano rozszerzenie protokołu TCP warstwę SSL. SSL nie jest trzecim internetowym protokołem transportowym z poziomu protokołów TCP i UDP, a jedynie rozszerzeniem tego pierwszego. last
Protokoły warstwy aplikacji Zastosowanie Protokół warstwy aplikacji Protokół warstwy transportowej Poczta elektroniczna SMTP (RFC 5321) TCP Zdalny dostęp terminalowy Telnet (RFC 854) TCP Technologia WWW HTTP (RFC 2616) TCP Transfer plików FTP (RFC 959) TCP Strumieniowa transmisja danych multimedialnych Telefonia internetowa HTTP (np. Youtube), RTP SIP, RTP, lub protokół zastrzeżony jak np. Skype UDP lub TCP Zazwyczaj UDP
Protokoły warstwy aplikacji - Typy wymienianych komunikatów (np. komunikaty żądań i odpowiedzi na nie; - Składnia różnego typu komunikatów (pola komunikatu i sposób ich opisu); - Semantyka pól, czyli znaczenie zwartych w nich informacji; - Zasady określające kiedy i w jaki sposób proces wysyła komunikaty i odpowiada na nie.
Protokół HTTP
Połączenia nietrwałe 1. Klient HTTP inicjuje połączenie TCP z serwerem www.uczelnia.edu za pomocą portu 80, który jest domzślnie używany przez protokół HTTP. Port ten jest powiązany z połączeniem TCP i posłuży jako gniazdo po stronie klienta oraz serwera; 2. Klient HTTP wysyła komunikat żądania HTTP do serwera za pośrednictwem swojego gniazda. Komunikat żądania zawiera ścieżkę /index.html. 3. Proces serwera HTTP odbiera komunikat żądania przy użyciu swojego gniazda powiązanego z połączeniem, a następnie z pamięci pobiera obiekt index.html, kapsułkuje wgo w komunikacie odpowiedzi HTTP, który odsyła klientowi, korzystając ze swojego gniazda; 4. Proces serwera HTTP nakazuje protokołowi TCP zakończenie połączenia TCP (protokół wykona tą operację po upewnieniu się, że klient otrzymał komunikat odpowiedzi w niezmienionej postaci); 5. Klient HTTP odbiera komunikat odpowiedzi. Połączenie TCP jest zakończone. Komunikat wskazuje, że kapsułkowanym obiektem jest plik HTML. Kient wyodrębnia plik z komunikatu, a następnie sprawdza go i odnajduje wszystkie odwołania do obiektów; 6. Dla każdego obiektu są powtarzane kroki 1-4
Ogólny format komunikatu żądania
1. GET / HTTP/1.1 (prośba o o URI / zgodnie z protokołem HTTP 1.1) 2. Host: host.com (wymagany w HTTP 1.1 zwrócenie dokumentu nagłówek Host służący do rozpoznania hosta, jeśli serwer na jednym IP obsługuje kilka VirtualHostów) 3. User-Agent: Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 (nazwa aplikacji klienckiej) 4. Accept: text/xml,application/xml,application/xhtml+xml,text/html; q=0.9,text/plain;q=0.8 (akceptowane (bądź nieakceptowane dla q=0) przez klienta typy plików) 5. Accept-Language: pl,en-us;q=0.7,en;q=0.3 (preferowany język strony nagłówek przydatny przy Language negotiation) 6. Accept-Charset: ISO-8859-2,utf-8;q=0.7,*;q=0.7 (preferowane kodowanie znaków, patrz strona kodowa) 7. Keep-Alive: 300 (czas, jaki klient chce zarezerwować do następnego zapytania w przypadku połączenia Keep-Alive) 8. Connection: keep-alive (chęć nawiązania połączenia stałego Keep-Alive z serwerem HTTP/1.0) 9. Znak powrotu karetki i nowej linii (CRLF)
Ogólny format komunikatu odpowiedzi
1. HTTP/1.1 200 OK (kod odpowiedzi HTTP, w tym wypadku zaakceptowanie i zwrócenie zawartości) 2. Date: Thu, 20 Dec 2001 12:04:30 GMT (czas serwera) 3. Server: Apache/2.0.50 (Unix) DAV/2 (opis aplikacji serwera) 4. Set-Cookie: PSID=d6dd02e9957fb162d2385ca6f2829a73; path=/ (nakazanie klientowi zapisania ciasteczka) 5. Expires: Thu, 19 Nov 1981 08:52:00 GMT (czas wygaśnięcia zawartości zwróconego dokumentu. Data w przeszłości zabrania umieszczenie dokumentu w pamięci podręcznej. Jest to stara metoda zastąpiona przez Cache-Control) 6. Cache-Control: no-store, no-cache, must-revalidate (no-store zabrania przechowywania dokumentu na dysku, nawet gdy nie jest to pamięć podręczna. must-revalidate nakazuje bezwzględnie stosować się do wytycznych i sprawdzić świeżość dokumentu za każdym razem) 7. Pragma: no-cache (informacje dotyczące zapisywania zawartości w pamięci podręcznej. Stara, niestandardowa metoda.) 8. Keep-Alive: timeout=15, max=100 9. Connection: Keep-Alive (akceptacja połączenia Keep-Alive dla klientów HTTP/1.0) 10. Transfer-Encoding: chunked (typ kodowania zawartości stosowanej przez serwer) 11. Content-Type: application/xhtml+xml; charset=utf-8 (typ MIME i strona kodowa zwróconego dokumentu) 12. znak powrotu karetki i nowej linii (CRLF) 13. tutaj zawartość dokumentu
Pliki cookies
Protokół FTP
Protokół FTP
Poczta elektroniczna
Protokół SMTP
Protokół HTTP i SMTP Protokół HTTP pobierający Protokół SMTP wysyłający Kodowanie 7 bitów dla protokołu SMTP Kapsułkowanie danych dla HTTP
Protokół SMTP 220 serwer ESMTP Exim 4.43 Wed, 12 Jan 2005 23:14:13 +0100 helo serwer.email.com 250 uzytkownik.internet.com Hello uzytkownik at uzytkownik.internet.com [1.1.1.1] mail from: <nadawca@example.org> 250 OK. rcpt to: <odbiorca@example.org> 250 Accepted data 354 Enter message, ending with "." on a line by itself Date: 03 Jan 07 21:21:21 From: nadawca@example.org To: odbiorca@example.org Subject: temat wiadomosci tresc wiadomosci. 250 OK id=1coql6-0003qi-mp quit 221 serwer.email.com closing connection LAST
Protokół POP3
+OK Cubic Circle's v1.31 1998/05/13 POP3 ready <4c210000ddb28641@pop3serwer> user uzytkownik +OK uzytkownik selected pass Haslo +OK Congratulations! list +OK 1 messages (627 octets) 1 627. retr 1 +OK 627 octets Received: by pop3serwer (mbox uzytkownik) (with Cubic Circle's cucipop (v1.31 1998/05/13) Mon Nov 1 23:04:26 2004) X-From_: uzytkownik@adres.email.com Mon Nov 01 23:04:07 2004 Return-path: <uzytkownik@adres.email.com> Envelope-to: uzytkownik@adres.email.com Received: from uzytkownik by pop3serwer.adres.email.com with local (Exim 3.35 #1 (Debian)) id 1COkHX-0002DO-00 for <uzytkownik@adres.email.com>; Mon, 01 Nov 2004 23:04:07 +0100 To: uzytkownik@adres.email.com Subject: test Message-Id: <E1COkHX-0002DO-00@pop3serwer.adres.email.com> From: Uzytkownik <uzytkownik@adres.email.com> Date: Mon, 01 Nov 2004 23:04:07 +0100. dele 1 +OK Message 1 deleted quit +OK Was it as good for you, as it was for me? (clean as a baby)
Protokół IMAP
Standardowe porty poczty elektronicznej: 25 protokół poczt przychodzącej (SMTP); 785 - obecnie 110 protokół poczty wychodzącej (POP3) Kodowane protokoły transportu poczty: POP3 - szyfrowanie SSL port 995 IMAP - szyfrowanie SSL port 993 SMTP - szyfrowanie SSL port 465