Table of Contents
- 2.1 Principles of Network Applications
- 2.1.1 Network Application Architectures
- 2.1.2 Process Communicating
- 2.1.3 Transport Services Available to Applications
- 2.1.4 Transport Services Provided by the Internet
- 2.1.5 Application-Layer Protocols
- 2.1.6 Network Applications Covered in This Book
- 2.2 The Web and HTTP
- 2.2.1 Overview of HTTP
- 2.2.2 Non-Persistent and Persistent Connections
- 2.2.3 HTTP Message Format
- 2.2.4 User-Server Interaction: Cookies
- 2.2.5 Web Caching
- 2.2.6 The Conditional Get
- 2.3 File Transfer: FTP
- 2.4 Electronic Mail in the Internet
- 2.5 DNS The Internet’s Directory Service
- 2.6 Peer-to-Peer Applications
- 2.7 Socket Programming: Creating Network Applications
- 2.8 Summary
2.1 Principles of Network Applications
- Software you write should not need to actually have to be directly interact with network-core devices
- 2.1.1 Network Application Architectures
- Application architecture is distinctly different from the network architecture (5 layer)
- For a application developer all lower layers act as services
- The application architecture is designed by the developer and is structured on end systems to the developer’s desires
- There are 2 major types of architectures client-server and P2P
- Client-Server Architecture
- Always-on host which acts as the server
- Servers have a fixed IP address
- Servers are often collections of servers in a data center that act together as one virtual server
- Clients do not directly contact each other
- Clients only contact the server
- Always-on host which acts as the server
- Peer-to-Peer Architecture
- Peers directly communicate with each other
- Little to no reliance on dedicated server
- Client-Server vs P2P?
- P2P offers self-scalability
- For each client that’s added it will also serve as a “server” to offer connections to other clients
- P2P is harder to secure because peers have direct access to each other
- P2P offers self-scalability
- 2.1.2 Processes Communicating
- Processes on end systems communicate with each other using application level messages
- Client and Server Processes
- Network applications consist of pairs of processes that send messages to each other over a network
- One of these is the client and the other is the server
- The Interface Between the Process and the Computer Network
- Processes receive and send messages through the network through a software interface called a socket
- Think about this as the door to a house all things in and out must go through that door
- A socket has its own API between application and network
- This means that application developers only have access to what the API gives access to and thus there is very little control over the network components
- Addressing Processes
- Two pieces of information are required to identify a receiving process
- Address of host (IP address)
- An identifier that specifies the receiving process in the destination host (port number)
- Note some services over time have been given their own dedicated ports
- Two pieces of information are required to identify a receiving process
- 2.1.3 Transport Services Available to Applications
- Non/Reliable Data Transfer
- Reliable data transfer ensures that any packet that leaves a socket will be guaranteed to reach its destination even if a packet is dropped
- If a packet is dropped it is re-transmitted
- Loss-Tolerant applications don’t care if some packets are dropped often times these are multimedia applications
- Throughput
- Throughput is defined as the rate at which the sending process can deliver bits to the receiving process
- This rate is a fluctuating value and thus often reliable data transfer protocols will offer guaranteed speed
- Bandwidth-sensitive Applications: Applications that depend on a minimum speed (eg. calls)
- Elastic Applications: Applications that can suffer hits to throughput or random speeds (eg. sending email)
- Timing
- Timing Guarantee is a guarantee that any bit that leaves arrives at the other socket within a guaranteed amount of time
- Multiplayer games such as FPS games rely on low ping in order for it to feel as real time as possible
- Security
- Transport protocol can provide security by encrypting the data
- Non/Reliable Data Transfer
- 2.1.4 Transport Services Provided by the Internet
- Internet uses UDP and TCP
- TCP Services
- TCP service model is a connection-oriented service and a reliable transfer service
- Connection-Oriented Service: Client and server must identify and complete a handshake
- After handshake a TCP connection is established
- Once an application finishes sending messages the connection must be terminated
- Reliable data transfer service: Relies on TCP to guarantee that every packet is sent without error in the proper order
- TCP also contains a congestion control mechanism throttling the sending process if its sending things too fast
- UDP Services
- Lightweight transport protocol for minimal services
- Connectionless: No handshakes at the beginning
- Unreliable data service, does not guarantee whole message gets sent
- Data may also arrive out of order
- No congestion control
- Services Not Provided by Internet Transport Protocols
- We have classified protocols by
- Reliable data transfer, throughput, timing, and security
- However we have not mentioned timing and throughput for UDP and TCP (refer to chapter 7)
- A lot of applications prefer to use UDP due to lack of congestion control but almost always have a TCP backup in case UDP is blocked by firewalls
- We have classified protocols by
- 2.1.5 Application-Layer Protocols
- Application-Layer Protocol: Defines how applications at either end systems communicate with each other
- The following are defined by such protocol
- Types of messages exchanged
- The syntax of the messages exchanged
- Semantics of the fields (meaning)
- Rules for determining how a process sends and receives messages
- NOTE: Application-Layer Protocols are only one part of a network application and not a network application itself
- For example the web’s application layer protocol is HTTP which defines the format and sequence of messages sent between users/servers
- For example for email, SMTP
2.2 The Web and HTTP
- 2.2.1 Overview of HTTP
- NOTE: Web browsers implement the client side of HTTP and thus client==browser
- Web page: Collection of objects (files can be images, HTML pages, etc)
- Web server: Implement server side of HTTP
- HTTP uses TCP as its transport protocol
- 1. HTTP Client initiates TCP connections
- 2. After TCP handshake is completed server and client communicate through the open socket interfaces
- TCP will handle all the communications once the data is sent to the socket
- HTTP is stateless, this means that no information is stored about the state of the client
- Therefore for example if the client requests the same file twice within a short period of time, the server will still send it twice
- 2.2.2 Non-Persistent and Persistent Connections
- HTTP with Non-Persistent Connections (separate TCP connection)
- Suppose we are accessing a webpage with 1 HTML file and 10 jpg images
- Process:
- 1. HTTP Client initiates TCP connection with server on port 80 creating a socket on both ends
- 2. HTTP client sends HTTP request message to server via socket
- 3. HTTP server processes request message and retrieves file. The file is then encapsulated as a HTTP response message and sent back
- 4. HTTP server after sending tells TCP to close the connection (which will formally be terminated after the whole file is sent)
- 5. HTTP client receives the response message. TCP connection is terminated. Client then extracts the file from the HTTP message (HTML file first) and finds that there are 10 references to jpg objects
- 6. 1-4 is repeated for each referenced object
- The above is using a non-persistent connection where each TCP connection is closed after server sends the object and does not persist for subsequent objects
- The 10 jpgs can be sent via parallel or serial connections
- Round-Trip-Time (RTT): Time for a small packet to travel from client->server->client
- This includes packet-propagation delays, packet-queuing delays in switches/intermediate routers, and packet-processing delays
- Total time ~2 RTT + time for data transfer
- HTTP with Persistent Connections (same TCP connection)
- Unlike non-persistent, TCP connections are kept open after the first file is transferred, meaning all files can then be sent from one connection removing overhead of recreating the TCP connection
- This allows for back to back object requests and responses
- HTTP with Non-Persistent Connections (separate TCP connection)
- 2.2.3 HTTP Message Format (RFC 1945; RFC 2616)
- HTTP Request Message
- Note the carriage return and line feed
- GET doesn’t use entity body but POST does
- POST is thus often used for filling out forms
- Possible to use GET by putting the arguments into form into the URL eg. http://www.somesite.com/animalserach?monkeys&bananas
GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr
- Request Line: First line
- 3 fields: Method field, URL field, HTTP version
- Method: GET, POST, HEAD, PUT, DELETE
- GET: Browser requests an object
- POST: The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URL in the Request-Line
- HEAD: The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response.
- PUT: The PUT method requests that the enclosed entity be stored under the supplied Request-URL
- DELETE: The DELETE method requests that the origin server delete the resource identified by the Request-URL
- URL Field: Points to the directory and then the file on the server
- HTTP version: Version information
- Method: GET, POST, HEAD, PUT, DELETE
- 3 fields: Method field, URL field, HTTP version
- Header Lines: Remaining message
Host: www.someschool.edu
- Needed for web proxy caches even though TCP connection has already been established
Connection: close
- Don’t use persistent connections
User-agent: Mozilla/5.0
- Browser type of client
Accept-language: fr
- Tells server to try and find a French version of the object
- HTTP Response Message
-
HTTP/1.1 200 OK Connection: close Date: Tue, 09 Aug 2011 15:44:04 GMT Server: Apache/2.2.3 (CentOS) Last-Modified: Tues, 09 Aug 2011 15:11:03 GMT Content-Length: 6821 Content-Type: text/html (data ...)
- Status Line: First line
- 3 Fields: Protocol version, status code, status message
- Status Codes:
- 200 OK: Request succeeded and the information is returned in response
- 301 Moved Permanently: Permanently moved object and new URL is specified at the Location: header of response message which the client will automatically retrive
- 400 Bad Request: Generic error
- 404 Not Found: Requested document does not exist
- 505 HTTP Version Not Supported
- Status Codes:
- 3 Fields: Protocol version, status code, status message
- Six Header Lines
-
Connection: close
- Tells client that TCP connection will be closed
-
Date: Tue, 09 Aug 2011 15:44:04 GMT
- When the HTTP response was created/sent by server
-
Server: Apache/2.2.3 (CentOS)
- Information about the server
-
Last-Modified: Tues, 09 Aug 2011 15:11:03 GMT
- When object was last modified
-
Content-Length: 6821
- # of bytes of the object
-
Content-Type: text/html
- Type of requested content
-
- Entity Body
- HTTP Request Message
- 2.2.4 User-Server Interaction: Cookies
- Recall HTTP server is stateless
- Cookies are a way to identify and track users on websites
- An example of how a cookie is used to easily authenticate a user and enable such services as one-click shopping
- 2.2.5 Web Caching (Proxy Server)
- A server used to satisfy HTTP requests on behalf of an origin Web server
- This web cache stores recent copies of a web page/objects
- 1. Reduces response time for client
- 2. Reduce traffic on origin server
- Web cache and origin server setup with clients
- Example of a request using a web cache
- 1. Establish a TCP connection to the web cache and send the HTTP request there
- 2. Web cache checks to see if it has a copy if so return the object to client
- 3. If the web cache does not have the object the web cache creates a TCP connection with the origin server and then requests the object and receives it
- 4. The web cache caches the object and then sends it to the client
- Internet Delay: Time for a router from sending a request to when it receives the response
- REFER TO PAGE 112-113 for an example with numbers on how this can make it faster
- 2.2.6 The Conditional GET
- This solves the problem of whether a user is getting the most updated version of the webpage or not
- This is the same as the GET message but also contains the “If-Modified Since: “ header line
- For example
- 1. Client Request
- 2. Web cache gets from origin server
- 3. Web cache caches and sends to client
- 4. Client Requests at a later date
- 5. Web cache requests an up to date check using conditional get
-
GET /fruit/kiwi.gif HTTP/1.1 Host: www.exotiquecusinie.com If-modified-since: Wed, 7 Sep 2011 09:23:24
-
- 6. Origin server responds
- Not modified
-
HTTP/1.1 304 Not Modified Date: Sat, 15 Oct 2011 15:39:29 Server: Apache/1.3.0 (Unix) (empty entity body)
-
- Modified
- HTTP/1.1 304 Modified
Date: Sat, 15 Oct 2011 15:39:29
Server: Apache/1.3.0 (Unix)
(entity body)
- HTTP/1.1 304 Modified
- Not modified
- 7. Web cache caches and forwards on to client
2.3 File Transfer: FTP