What is a virtual circuit network? Telecommunication networks - PDF document

What is a virtual circuit network? Telecommunication networks Circuit-switched Packet-switched networks networks virtual circuit Datagram FDM TDM Networks Networks 2 1 3 4 5 B A 4/8/03 lixia@cs.ucla.edu 1 Chapter 2 outline v 2.1 Principles of app layer protocols Tue 4/8 v 2.2 Web and HTTP v 2.3 FTP Next week v 2.4 Electronic Mail v 2.5 DNS v 2.6 Socket programming with TCP Thu 4/10 v 2.7 Socket programming with UDP v 2.8 Building a Web server v 2.9 Content distribution ÿ Network Web caching ÿ Content distribution networks ÿ P2P file sharing 4/8/03 lixia@cs.ucla.edu 2 1

Applications and application-layer protocols v Application application transport network data link physical v Application-layer protocols request v Client: reply application transport network data link v Server physical Q: how does one process “identify” the other process with which it wants to communicate? 4/8/03 lixia@cs.ucla.edu 3 Network applications: some jargons v Process: program running within a host. v two processes within the same host communicate using interprocess communication (defined by operating system) v Processes running in different hosts communicate through an application-layer protocol v user agent: software process. ÿ Web:browser ÿ E-mail: mail reader v API: Application Programming Interface ÿ defines interface between application and transport layer v socket: Internet API ÿ two processes communicate by sending data into socket, reading data out of socket 4/8/03 lixia@cs.ucla.edu 4 2

Internet transport protocols services TCP service UDP service v connection-oriented: setup v unreliable data transfer connection between client between sending and and server first receiving process v reliable data delivery v does not provide: between the two ends ÿ connection setup v flow control: sender won’t ÿ Reliability overwhelm receiver ÿ flow control v congestion control: ÿ congestion control throttle sender when ÿ timing, or ÿ bandwidth guarantee network overloaded v does not provide: ÿ Timing ÿ bandwidth guarantees 4/8/03 lixia@cs.ucla.edu 5 World Wide Web v Web page v Object: HTML file, JPEG image, Java applet, audio file,… v Each object is addressable by a URL (Universal resource locator ) app://host_name:port#/path_and_file_name ex: http://www.cs.ucla.edu/classes/spring03/cs118/slides.html v Web browser: User agent for Web v Web server: 4/8/03 lixia@cs.ucla.edu 6 3

The Web and http protocol http: hypertext transfer protocol v client/server model http request ÿ client: browser that PC running http response requests, receives, Explorer “displays” Web objects ÿ server: Web server http request sends objects in e Server s n o p s e running r response to requests p t t h NCSA Web v http1.0: RFC 1945 server v http1.1: RFC 2068 Mac running Navigator 4/8/03 lixia@cs.ucla.edu 7 The http protocol: more Use TCP transport service http is “stateless” v server maintains no information about past client requests aside Protocols that maintain “state” are more complex! past history (state) must be maintained if server/client crashes, their views of “state” may be inconsistent, must be reconciled 4/8/03 lixia@cs.ucla.edu 8 4

http example (cont.) fetch www.someSchool.edu/someDepartment/home.index (contains text, references to time 10 jpeg images) 1a . http client initiates TCP 1b. http server at host connection to http server www.someSchool.edu waiting for (process) at TCP connection at port 80. www.SomeSchool.edu “accepts” connection 2. http client sends http 3. http server receives request, request message (containing forms response msg containing URL) into TCP connection socket requested object (someDepartment/home.index), 5. http client receives response sends message into socket message containing html file, 4. http server closes TCP conn. displays html. Parsing html file, finds 10 referenced jpeg objects 6. Steps 1-5 repeated for each of 10 jpeg objects 4/8/03 lixia@cs.ucla.edu 9 Non-persistent, persistent connections Non-persistent Persistent v http/1.0: server parses v default for htp/1.1 request, responds, closes v on same TCP connection: TCP connection server parses request, v 2 RTTs to fetch object responds, parses new ÿ TCP connection request,.. ÿ object v client sends requests for request/transfer all referenced objects as v many browsers open soon as it receives base multiple parallel HTML. connections v fewer RTTs 4/8/03 lixia@cs.ucla.edu 10 5

http message format: request v two types of http messages: request , response v http request message: ÿ ASCII (human-readable format) request line (GET, POST, GET /somedir/page.html HTTP/1.0 User-agent: Mozilla/4.0 HEAD commands) Accept: text/html, image/gif,image/jpeg header Accept-language:fr lines (extra carriage return, line feed) Carriage return, line feed indicates end of message 4/8/03 lixia@cs.ucla.edu 11 http request message: general format 4/8/03 lixia@cs.ucla.edu 12 6

http message format: response status line (protocol HTTP/1.0 200 OK status code Date: Thu, 06 Aug 1998 12:00:15 GMT status phrase) Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 …... header Content-Length: 6821 lines Content-Type: text/html data data data data data ... data, e.g., requested html file 4/8/03 lixia@cs.ucla.edu 13 http response status codes In first line in server->client response message. A few sample codes: 200 OK 301 Moved Permanently 400 Bad Request 404 Not Found 505 HTTP Version Not Supported 4/8/03 lixia@cs.ucla.edu 14 7

User-server interaction: authentication control access to the content v authorization credentials: server client typically name, password usual http request msg v stateless: client must 401: authorization req. present authorization in WWW authenticate: each request usual http request msg ÿ authorization: header line in + Authorization: <cred> each request usual http response msg ÿ if no authorization : header, server refuses access usual http request msg + Authorization: <cred> time usual http response msg 4/8/03 lixia@cs.ucla.edu 15 Cookies: keeping “state” Many major Web sites use Example: cookies ÿ Susan access Internet Four components: always from same PC 1) cookie header line in the HTTP response message 2) cookie header line in HTTP request message 3) cookie file kept on user’s host and managed by user’s browser 4) back-end database at Web site 4/8/03 lixia@cs.ucla.edu 16 8

Cookies: keeping “state” (cont.) client server usual http request msg entry in backend Cookie file server database usual http response + creates ID ebay: 8734 Set-cookie: 1678 1678 for user Cookie file usual http request msg cookie- amazon: 1678 access cookie: 1678 ebay: 8734 specific usual http response msg action access one week later: usual http request msg Cookie file cookie- cookie: 1678 amazon: 1678 spectific ebay: 8734 usual http response msg action 4/8/03 lixia@cs.ucla.edu 17 Conditional GET: client-side caching v Goal: don’t send object if client has up-to-date server client cached version http request msg If-modified-since: object <date> not modified http response HTTP/1.0 304 Not Modified http request msg If-modified-since: object <date> modified http response HTTP/1.1 200 OK <data> 4/8/03 lixia@cs.ucla.edu 18 9

Socket programming controlled by process process application socket developer socket controlled by operating internet system socket a host-local , application-created/owned , OS-controlled interface (a “door”) into which application process can both send and receive messages to/from another (remote or local) application process Create close the Establish Send/recv Socket API: socket socket connection data 4/8/03 lixia@cs.ucla.edu 19 Socket functional calls v socket (): Create a socket v bind(): bind a socket to a local IP address and port # v listen(): passively waiting for connections v connect(): initiating connection to another socket v accept(): accept a new connection v Write(): write data to a socket v Read(): read data from a socket v sendto(): send a datagram to another UDP socket v recvfrom(): read a datagram from a UDP socket v close(): close a socket (tear down the connection) 4/8/03 lixia@cs.ucla.edu 20 10

Socket programming with TCP Client must contact server v When client creates v server process must socket: client TCP first be running establishes connection to server TCP v server must have created socket (door) v When contacted by client, that welcomes client’s server TCP creates new contact socket for server process to communicate with client Client contacts server by: ÿ allows server to talk v creating client-local with multiple clients TCP socket v specifying IP address, application viewpoint port number of server TCP provides reliable, in-order process transfer of bytes (“pipe”) between client and server 4/8/03 lixia@cs.ucla.edu 21 Socket-programming using TCP TCP service: reliable byte stream transfer socket( ) bind( ) server socket( ) listen( ) client bind( ) connect( ) TCP conn. request accept( ) send( ) TCP ACK recv( ) recv( ) send( ) close( ) close( ) controlled by process application process developer socket socket TCP with controlled by TCP with operating buffers, internet buffers, system variables variables 4/8/03 lixia@cs.ucla.edu 22 11