2-Application Layer

Please indicate the source: http://blog.csdn.net/gaoxiangnumber1
Welcome to my github: https://github.com/gaoxiangnumber1

2.1 Principles of Network Applications

2.1.1 Network Application Architectures

• Application’s architecture is different from the network architecture (e.g., the five-layer Internet architecture):
  
  1. The application architecture is designed by the application developer and dictates how the application is structured over the various end systems. Two main architectures used in applications: the client-server architecture or the peer-to-peer (P2P) architecture.
  2. The network architecture is fixed and provides a specific set of services to applications.
• In a client-server architecture, there is an always-on host(server), which services requests from many other hosts(clients).
• In a P2P architecture, there is minimal (or no) reliance on dedicated servers in data centers. Instead the application exploits direct communication between pairs of intermittently connected hosts, called peers. The peers are not owned by the service provider, but are instead desktops and laptops controlled by users, with most of the peers residing in homes. Because the peers communicate without passing through a dedicated server, the architecture is called peer-to-peer.

2.1.2 Processes Communicating

• A network application consists of pairs of processes that send messages to each other over a network. For each pair of communicating processes, we label one as the client and the other as the server. The process that initiates the communication (that is, initially contacts the other process at the beginning of the session) is labeled as the client. The process that waits to be contacted to begin the session is the server.
• A process sends messages into, and receives messages from, the network through a software interface called a socket. A socket is the interface between the application layer and the transport layer within a host which is also referred to as the Application Programming Interface (API) between the application and the network.
  
• The application developer has control of everything on the application-layer side of the socket but has little control of the transport-layer side of the socket. The only control that the application developer has on the transport-layer side is
  (1) the choice of transport protocol and
  (2) the ability to fix a few transport-layer parameters such as maximum buffer and maximum segment sizes.
  Once the application developer chooses a transport protocol, the application is built using the transport-layer services provided by that protocol.
• In order for a process running on one host to send packets to a process running on another host, the receiving process needs to have an address. To identify the receiving process:
  (1) the address of the host;
  (2) an identifier that specifies the receiving process in the destination host.
• The host is identified by its IP address that is a 32-bit quantity.
  The receiving process is identified by a destination port number.
• Popular applications have been assigned specific port numbers. For example, a Web server is identified by port number 80. A mail server process (using the SMTP protocol) is identified by port number 25.

2.1.3 Transport Services Available to Applications

• Services that a transport-layer protocol can offer to applications invoking: reliable data transfer, throughput, timing, and security.
• When a transport protocol provides process-to-process reliable data transfer, the sending process can pass its data into the socket and know with confidence that the data will arrive without errors at the receiving process.
• Available throughput between two processes in network is the rate at which the sending process can deliver bits to the receiving process. Transport-layer protocol could provide guaranteed available throughput at some specified rate. With such a service, the application could request a guaranteed throughput of r bits/sec, and the transport protocol would then ensure that the available throughput is always at least r bits/sec.
• Applications that have throughput requirements are said to be bandwidth-sensitive applications, otherwise are elastic applications.
• Timing guarantees can come in many forms. E.g.: every bit that the sender pumps into the socket arrives at the receiver’s socket no more than 100 msec later.
• A transport protocol can provide an application with one or more security services. For example, in the sending host, a transport protocol can encrypt all data transmitted by the sending process, and in the receiving host, the transport-layer protocol can decrypt the data before delivering the data to the receiving process.

2.1.4 Transport Services Provided by the Internet

• The Internet (TCP/IP networks) makes two transport protocols available to applications, UDP and TCP.
  TCP Services
• The TCP service model includes a connection-oriented service and a reliable data transfer service.
  
  1. Connection-oriented service. TCP has the client and server exchange transport-layer control information with each other before the application-level messages begin to flow. This so-called handshaking procedure alerts the client and server, allowing them to prepare for packets stream. After the handshaking phase, a TCP connection is said to exist between the sockets of the two processes. The connection is a full-duplex connection in that the two processes can send messages to each other over the connection at the same time. When the application finishes sending messages, it must tear down the connection.
  2. Reliable data transfer service. The communicating processes can rely on TCP to deliver all data sent without error and in the proper order.
• The TCP congestion-control mechanism throttles a sending process (client or server) when the network is congested between sender and receiver. TCP congestion control also attempts to limit each TCP connection to its fair share of network bandwidth.
  UDP Services
• UDP is connectionless, so there is no handshaking before the two processes start to communicate.
• UDP provides an unreliable data transfer service: when a process sends a message into a UDP socket, UDP provides no guarantee that the message will ever reach the receiving process.
• UDP does not include a congestion-control mechanism, so the sending side of UDP can pump data into the layer below (the network layer) at any rate it pleases.

2.1.5 Application-Layer Protocols

• An application-layer protocol defines:
  
  1. The types of messages exchanged, for example, request messages and response messages.
  2. The syntax of the various message types, such as the fields in the message and how the fields are delineated.
  3. The semantics of the fields, that is, the meaning of the information in the fields.
  4. Rules for determining when and how a process sends messages and responds to messages.
• Some application-layer protocols are specified in RFCs and are therefore in the public domain. For example, the Web’s application-layer protocol, HTTP is available as an RFC. If a browser developer follows the rules of the HTTP RFC, the browser will be able to retrieve Web pages from any Web server that has also followed the rules of the HTTP RFC. Many other application-layer protocols are proprietary and intentionally not available in the public domain.
• An application-layer protocol is only one piece of a network application. E.g.: The Web application consists of many components, including a standard for document formats (HTML), Web browsers, Web servers, and an application-layer protocol. The Web’s application-layer protocol, HTTP, defines the format and sequence of messages exchanged between browser and Web server. Thus, HTTP is only one piece of the Web application.

2.1.6 Network Applications Covered in This Book

2.2 The Web and HTTP

2.2.1 Overview of HTTP

• HTTP is implemented in two programs: a client program and a server program. The client program and server program, executing on different end systems, talk to each other by exchanging HTTP messages. HTTP defines the structure of these messages and how the client and server exchange the messages.
• A Web page consists of objects. An object is a file—such as an HTML file, a JPEG image—that is addressable by a single URL. Most Web pages consist of a base HTML file and several referenced objects. For example, if a Web page contains HTML text and five JPEG images, then the Web page has six objects.
• Each URL has two components: the hostname of the server that houses the object and the object’s path name. For example, the URL: http://www.someSchool.edu/someDepartment/picture.gif has www.someSchool.edu for a hostname and /someDepartment/picture.gif for a path name.
• HTTP defines how Web clients request Web pages from Web servers and how servers transfer Web pages to clients. When a user requests a Web page, the browser sends HTTP request messages for the objects in the page to the server. The server receives the requests and responds with HTTP response messages that contain the objects.
• HTTP uses TCP as its underlying transport protocol. The HTTP client first initiates a TCP connection with the server. After the connection is established, the browser and the server processes access TCP through their socket interfaces. The client sends HTTP request messages into its socket interface and receives HTTP response messages from its socket interface.
• The server sends requested files to clients without storing any state information about the client. If a particular client asks for the same object twice in a period of a few seconds, the server resends the object. Because an HTTP server maintains no information about the clients, HTTP is said to be a stateless protocol.

2.2.2 Non-Persistent and Persistent Connections

• In Internet applications, the client and server communicate for an period of time, with the client making a series of requests and the server responding to each of the requests. The series of requests may be made back-to-back, periodically at regular intervals, or intermittently. When this client-server interaction is taking place over TCP, the application developer needs to decide that should each request/response pair be sent over a separate TCP connection, or should all of the requests and their corresponding responses be sent over the same TCP connection? In the former approach, the application is said to use non-persistent connections; and in the latter approach, persistent connections.
• HTTP uses persistent connections in its default mode, HTTP clients and servers can be configured to use non-persistent connections instead.
  HTTP with Non-Persistent Connections
• Suppose the page consists of a base HTML file and 10 JPEG images, and that all 11 of these objects reside on the same server. The URL for the base HTML file is http://www.someSchool.edu/someDepartment/home.index
  
  1. The HTTP client process initiates a TCP connection to the server www.someSchool.edu on port number 80, which is the default port number for HTTP. Associated with the TCP connection, there will be a socket at the client and a socket at the server.
  2. The HTTP client sends an HTTP request message to the server via its socket. The request message includes the path name /someDepartment/home.index.
  3. The HTTP server process receives the request message via its socket, retrieves the object /someDepartment/home.index from its storage, encapsulates the object in an HTTP response message, and sends the response message to the client via its socket.
  4. The HTTP server process tells TCP to close the TCP connection. But TCP doesn’t actually terminate the connection until it knows for sure that the client has received the response message intact.
  5. The HTTP client receives the response message. The TCP connection terminates. The message indicates that the encapsulated object is an HTML file. The client extracts the file from the response message, examines the HTML file, and finds references to the 10 JPEG objects.
  6. The first four steps are then repeated for each of the referenced JPEG objects.
• Each TCP connection transports exactly one request message and one response message. In this example, when a user requests the Web page, 11 TCP connections are generated.
• Round-Trip Time (RTT) is the time it takes for a small packet to travel from client to server and then back to the client which includes packet-propagation delays, packet-queuing delays in intermediate routers and switches, and packet-processing delays.
  
• When a user clicks on a hyperlink, the browser initiates a TCP connection between the browser and the Web server which involves a “three-way handshake”.
• The client sends a small TCP segment to the server, the server acknowledges and responds with a small TCP segment, and, finally, the client acknowledges back to the server. The first two parts of the three-way handshake take one RTT.
• After completing the first two parts of the handshake, the client sends the HTTP request message combined with the third part of the three-way handshake (the acknowledgment) into the TCP connection. Once the request message arrives at the server, the server sends the HTML file into the TCP connection. This HTTP request/response eats up another RTT.
• The total response time is two RTTs plus the transmission time at the server of the HTML file.
  HTTP with Persistent Connections
• Non-persistent connections have shortcomings.
  Firs