Presentation is loading. Please wait.

Presentation is loading. Please wait.

Chapter 2 Application Layer Tami Meredith. A protocol defines: 1. Message Format (Syntax) 2. Rules of Communication (Semantics) 3. Synchronisation and.

Similar presentations


Presentation on theme: "Chapter 2 Application Layer Tami Meredith. A protocol defines: 1. Message Format (Syntax) 2. Rules of Communication (Semantics) 3. Synchronisation and."— Presentation transcript:

1 Chapter 2 Application Layer Tami Meredith

2 A protocol defines: 1. Message Format (Syntax) 2. Rules of Communication (Semantics) 3. Synchronisation and other application details (Implementation)

3

4  Network topology: Graph structure  Host networking system environment: Layered protocol stack  Application system communication structure:  Client-server (“pull”)  May have multiple clients and/or servers  Client initiates, host responds  Peer-to-peer (P2P)  E.g., Skype, BitTorrent  Highly scalable, distributed, no host overhead

5  Networks designed predominantly for download, not upload – P2P can stress ISP upload capacity  Easily hacked because there is no central control  User pushback – Do you want someone downloading from you and slowing down your connection while you’re doing online gaming?  Inefficiency – lack of control can lead to redundancy, version control issues, etc.

6  API (Application Programming Interface)  Based on “sockets”  Sockets are bound to “ports” each with a port number  Every host has an IP Address  Applications need a port and a host to be identified ip-address:port-number  E.g., 192.168.1.1:80, 140.184.133.99:8080

7 1. Reliability  Loss tolerant (UDP) – multimedia/video  Reliable data transfer (TCP) 2. Throughput  Bandwidth sensitive – voice  Elastic – file transfer 3. Timing  Impact of latency, delay, on the application 4. Security  Encryption, authentification, access

8 TCPUDP Connection-orientedConnectionless ReliableUnreliable Packet ordering ensuredRandom packet ordering Congestion controlNo congestion control No timing (delay) control No throughput (QoS, BPS) guarantees No security support

9  Hide many of the communication details for us  Tailored to specific application domains  May be public (e.g., HTTP) or proprietary (e.g., Skype)  Only concerned with data communication and communication format  E.g., http controls the transfer of a web-page but not its content format (html) – can transfer an invalid page  Is a critical part of the application but does not “create” the application – considerable additional support is needed (e.g., display and rendering).

10 HyperText Transfer Protocol  RFC 1945, 2616  Demand (Pull) oriented  Client (Browser) – server architecture  Developed by Tim Berners-Lee at CERN]  Is NOT the Internet, is just a single application running over the Internet  Content may use HTML (derived from SGML)  Communicates Documents (web pages) composed of Objects (files)

11  Consists of: scheme (colon) scheme-specific-part  More than just web addresses  Web URLs use http http://host:port/path?query-string#fragment-id  Browsers  implement extensions (e.g. user@URL)  fill in missing elements with defaults (e.g., port = 80, scheme = http)

12  Uses TCP  Stateless: server stores no information between requests (but client may, e.g., cookies)  Pull-based: updates not propagated to users  May use both:  persistent connections: one TCP connection for all request-response pairs  non-persistent connections: unique TCP connection for each request-response pair

13  Client initiates TCP connection  Server processes connection request and connection is built  Client sends request  Server responds to request  Client receives data and ends TCP connection  Server ends TCP connection

14

15

16 GET /public_html/index.html HTTP/1.1  Request line: method URL version Host: cs.smu.ca Connection: close User-agent: Mozilla/5.0 Accept-language: fr  Header lines: name value (many exist)  Blank line  Entity body (empty in this example – used for posts, form data) NOTE that a TCP connection exists when this is sent

17  GET: most common, requests an object  POST: a GET with information in the body  HEAD: respond with everything but the entity contents  PUT: upload a file to the web server  DELETE: delete a file on the web server

18

19 HTTP/1.1 200 OK Connection: close Date: Tue, 09 Aug 2011 15:44:04 GMT Server: Apache/2.2.3 (CentOS) Last-Modified: Tue, 09 Aug 2011 15:10:06 GMT Content-Length: 6821 Content-Type: text/html … 6821 bytes of data …

20 1xxInformational 2xxSuccessful  200OK 3xxRedirection  301Moved permanently 4xxClient errors  400Bad request  404Not found 5xxServer errors  505HTTP version not supported

21  Servers are stateless  no information held between requests except connections  Cookies (RFC6265) provide state to servers  Cookies (on clients) store an identifier that can be used by the server as a DB key to access information on a server-side DB 1) Cookie header line in HTTP requests 2) Cookie header line in HTTP responses 3) Cookie file kept by browser on user’s end system 4) Backend server-side database

22  A network entity that intercepts HTTP requests and satisfies them using a cached version of the response data  Entity contacts the actual server if data not in cache  Decreases net traffic  Improves response times for commonly accessed data  Can be used to control web access and bypass firewalls  May provide stale data

23

24  Uses header line in request: If-modified-since: Wed, 2 Jan 2013 09:23:44  Server responds normally if the page has been modified  Server responds with 304 Not Modified it has not been modified  Reduces bandwidth usage  Used by proxy servers to check for stale data

25

26 TCPUDP Connection-orientedConnectionless ReliableUnreliable Packet ordering ensuredRandom packet ordering Congestion controlNo congestion control No timing (delay) control No throughput (QoS, BPS) guarantees No security support

27  Consists of: scheme (colon) scheme-specific-part  More than just web addresses  Web URLs use http http://host:port/path?query-string#fragment-id  Browsers  implement extensions (e.g. user@URL)  fill in missing elements with defaults (e.g., port = 80, scheme = http)

28  File transfer protocol  Uses two parallel TCP connections  Communication is “ out-of-band ” as compared to HTTP which is “ in-band ”  Server maintains “state” information for each control connection  e.g., current working directory  cf. HTTP which is designed as stateless

29 1. Control Connection  Communicates control (header information)  Kept open for the duration of the session 2. Data Connection  For transmission of the file  Non-persistent, closed after transfer complete  New connection opened for each file

30  Generally insecure, use SFTP, FTPS, or FTP over SSH for secure transfer  Transfer representations of ASCII, EBCDIC, binary, local  Active mode: client initiates control connection (port 21) and then server initiates data connection  Passive mode: (client behind firewall) client initiates control connection and then sends a “PASV” command, server returns connection info via control to allow client to initiate data connections  Normally requires login, but anonymous FTP can be performed  Normally a CLI due to its age, generally being replaced by SCP

31  Hybrid architecture  Mail servers communicate P2P using SMTP (RFC 5321)  User agents communicate to mail server with SMTP (send) or POP3/IMAP (receive)

32  User Agents: E.g., Outlook, pine, elm, Mail  Mail servers  Outgoing message queue  Incoming mailboxes (one per user)  Communicate using SMTP  Function both as clients (sending) and server (receiving)  Persistent connections for more than one message

33

34  SMTP = Push: Servers are active in pushing data to the destinations  Really? What about the receiving server handling incoming mail messages?  HTTP = Pull: Servers are passive and wait for clients to pull the data from them  SMTP requires 7-bit ASCII while HTTP does not  HTTP permits multiple objects whereas a mail message must be a single object (including attachments)

35  SMTP is designed to push mail to another server  Permits retries  Always there if user has dynamic DNS  Need a way for user mail agent to pull mail from the mailbox at the local mail server 1. POP3 – Post Office Protocol 2. IMAP – Internet Mail Access Protocol

36  RFC 1939  Authorisation – passwords in the clear  Transaction(s)  Update on closing connection  POP3 servers do not maintain state information between connections  Basically a program on the same system as the mailbox for manipulating a mailbox

37  IMAP is considerably more feature-rich than POP3  Maintains persistent state information for each mailbox (e.g., directory structure)  Allows users to obtain components (e.g., attachments) of messages  Also implemented using a basic client-server model

38  Domain Name System (RFC 1034, 1035)  Uses UDP on port 53  Translates registered hostnames to IP addresses  Hostname: cs.smu.ca  IP address: 140.184.133.99  Not 1:1 but n:m for host:address  Permits aliasing (multiple names for an IP address)  Manages complex multi-machine servers (e.g., google.com, cnn.com)  Originally based on BIND (Berkeley Internet Name Domain)

39 #include extern int h_errno; struct hostent *gethostbyname(const char *name);  SIMPLE – DNS is encapsulated into a single system call

40  Want everyone to have the same updated information which suggests a single global database  Single point of failure  Ridiculously high traffic volume  Potentially long latency (distance etc.)  Extreme maintenance and update demands  Uses a distributed hierarchical DB instead  http://www.root-servers.org http://www.root-servers.org

41  ICANN: Internet Corporation for Assigned Names and Numbers (http://www.ican.org)  U.S. Corporation reporting to U.S. government  IANA: Internet Assigned Numbers Authority (http://www.iana.org)  Department of ICANN  Internet Society (http://www.internetsociety.org)  Parent Corporation of the IETF  IETF: Internet Engineering Task Force (http://www.ietf.org)http://www.ietf.org  W3C: World Wide Web Consortium (http://www.w3.org)

42  Root DNS Servers  13 Root servers  TLD Servers  Control specific domains, e.g.,.ca  Authoritative servers  Hostnames for specific machines  May be provided by an organization such as smu.ca  May be provided by an ISP

43

44

45 (Name, Value, Type, TTL) 1. A: Standard Hostname:IP address pair 2. NS: value is an authoritative name-server for a domain (used for DNS chaining) 3. CNAME: value is a canonical hostname for aliased hosts 4. MX: value is the canonical hostname of a mailserver

46

47


Download ppt "Chapter 2 Application Layer Tami Meredith. A protocol defines: 1. Message Format (Syntax) 2. Rules of Communication (Semantics) 3. Synchronisation and."

Similar presentations


Ads by Google