Principle of Network Application
Application Architecture
Client-Server Architecture
- Data Center, housing a large number of hosts
- Google, Amazon, etc.
P2P Architecture
- Peers. Application exploits direct communication between pairs of intermittently connected hosts.
- Traffic-intensive applications: BitTorrent, XunLei, etc.
Processing Communicating
- Processes communicate among different end-system hosts
- Processes on two different end systems communicate with each other by exchanging messages across the computer network.
Client and Server processes
- In the context of a communication session between a pair of processes, 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.
The Interface Between the Process and the Computer Network
- A process sends messages into, and receives messages from, the network through a software interface called a socket.
- Between the application process and the transport-layer protocol.
Transport Service
The application at the sending side pushes messages through the socket. At the other side of the socket, the transport-layer protocol has the responsibility of getting the messages to the socket of the receiving process
Four Dimension Of Transport-Layer Protocol
– Reliable Data Transfer ( No lost data)
– Throughput (Bits delivery rate)
– Timing (Short delays)
– Security (Encrypt & Decrypt)
Transport Protocol Service
TCP
The TCP service model includes a connection-oriented service and a reliable data transfer service. When an application invokes TCP as its transport protocol, the application receives both of these services from TCP.
- Connection-oriented service.
- handshaking procedure
- Reliable data transfer service.
- no missing or duplicate bytes.
- Congestion-control mechanism
- throttles a sending process (client or server) when the network is congested
UDP
UDP is a no-frills, lightweight transport protocol, providing minimal services. UDP is connectionless, so there is no handshaking before the two processes start to communicate. UDP provides an unreliable data transfer service—that is, when a process sends a message into a UDP socket, UDP provides no guarantee that the message will ever reach the receiving process. Furthermore, messages that do arrive at the receiving process may arrive out of order.
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. (Note, however, that the actual end-to-end throughput may be less than this rate due to the limited transmission capacity of intervening links or due to congestion).
Application Layer Protocol
An application-layer protocol defines how an application’s processes, running on different end systems, pass messages to each other. eg. HTTP for Web’s Application Layer Protocol. In particular, an application-layer protocol defines:
- The types of messages exchanged, for example, request messages and response messages
- The syntax of the various message types, such as the fields in the message and how the fields are delineated
- The semantics of the fields, that is, the meaning of the information in the fields
- Rules for determining when and how a process sends messages and responds to messages
The Web and HTTP
HTTP
- The HyperText Transfer Protocol (HTTP), the Web’s application-layer protocol.
- HTTP defines the structure of these messages and how the client and server exchange the messages.
Web Page
- A Web page (also called a document) consists of objects.
- An object is simply a file—such as an HTML file, a JPEG image, a Java applet, or a video clip—that is addressable by a single URL.
- Most Web pages consist of a base HTML file and several referenced objects.
Non-persistent connections and persistent connections
- Non-persisteng connections: each request/response pair be sent over a separate TCP connection.
- Persistent connections: all of the requests and their corresponding responses be sent over the same TCP connection.
Round-Trip Time (RTT)
- The time it takes for a small packet to travel from client to server and then back to the client.
HTTP Message Format
HTTP Request Message
- Request Line (first line): the method field, the URL field, the HTTP version field
- Header Line (subsequent line): specifies the host on which the object resides, the connection type, the client agent, user prefer language
HTTP Response Message
- Status Line: the protocol version field, a status code, and a corresponding status message
- Header Line: the connection type, the date, the server, the modified log, content information
- Enity Body: requested object itself
Cookies
Allow sites to keep track of users. Most major commercial Web sites use cookie today.
Cookie technology has four components:
- A cookie header line in the HTTP response message
- A cookie header line in the HTTP request message
- A cookie file kept on the user’s end system and managed by the user’s browser
- A back-end database at the Web site.
Web Caching
A Web cache—also called a proxy server—is a network entity that satisfies HTTP requests on the behalf of an origin Web server. The Web cache has its own disk storage and keeps copies of recently requested objects in this storage.
A user’s browser can be configured so that all of the user’s HTTP requests are first directed to the Web cache. Once a browser is configured, each browser request for an object is first directed to the Web cache.
As an example, suppose a browser is requesting the object http://www.someschool.edu/campus.gif. Here is what happens:
- The browser establishes a TCP connection to the Web cache and sends an HTTP request for the object to the Web cache.
- The Web cache checks to see if it has a copy of the object stored locally. If it does, the Web cache returns the object within an HTTP response message to the client browser.
- If the Web cache does not have the object, the Web cache opens a TCP connection to the origin server, that is, to www.someschool.edu. The Web cache then sends an HTTP request for the object into the cache-to-server TCP connection. After receiving this request, the origin server sends the object within an HTTP response to the Web cache.
- When the Web cache receives the object, it stores a copy in its local storage and sends a copy, within an HTTP response message, to the client browser (over the existing TCP connection between the client browser and the Web cache).
Why do we need Web Cache?
- First, a Web cache can substantially reduce the response time for a client request, particularly if the bottleneck bandwidth between the client and the origin server is much less than the bottleneck bandwidth between the client and the cache. If there is a high-speed connection between the client and the cache, as there often is, and if the cache has the requested object, then the cache will be able to deliver the object rapidly to the client.
- Second, as we will soon illustrate with an example, Web caches can substantially reduce traffic on an institution’s access link to the Internet. By reducing traffic, the institution (for example, a company or a university) does not have to upgrade bandwidth as quickly, thereby reducing costs. Furthermore, Web caches cansubstantially reduce Web traffic in the Internet as a whole, thereby improving performance for all applications.
Electronic Mail in the Internet
Simple Mail Transfer Protocol ( SMTP )
SMTP transfers messages from senders’ mail servers to the recipients’ mail servers.
Post Office Protocol—Version 3 ( POP 3 )
POP3 is an extremely simple mail access protocol.
POP3 begins when the user agent (the client) opens a TCP connection to the mail server (the server) on port 110. With the TCP connection established, POP3 progresses through three phases: authorization, transaction, and update.
1.During the first phase, authorization, the user agent sends a username and a password (in the clear) to authenticate the user.
2.During the second phase, transaction, the user agent retrieves messages; also during this phase, the user agent can mark messages for deletion, remove deletion marks, and obtain mail statistics.
3.The third phase, update, occurs after the client has issued the quit command, ending the POP3 session; at this time, the mail server deletes the messages that were marked for deletion.
Internet Mail Access Protocol ( IMAP )
The IMAP protocol provides commands to allow users to create folders and move messages from one folder to another. IMAP also provides commands that allow users to search remote folders for messages matching specific criteria.
Another important feature of IMAP is that it has commands that permit a user agent to obtain components of messages.
DNS – The Internet’s Directory Service
How to identify hosts
Host name and IP address
DNS (Domain Name System)
People prefer the more mnemonic hostname identifier, while routers prefer fixed-length, hierarchically structured IP addresses. In order to reconcile these preferences, we need a directory service that translates hostnames to IP addresses.
The DNS is (1) a distributed database implemented in a hierarchy of DNS servers, and (2) anapplication-layer protocol that allows hosts to query the distributed database.
DNS provides a few other important services in addition to translating hostnames to IP addresses:
- Host aliasing.
- Mail server aliasing.
- Load distribution.
Peer-to-Peer File Distribution
BitTorrent
BitTorrent is a popular P2P protocol for file distribution. In BitTorrent lingo, the collection ofall peers participating in the distribution of a particular file is called a torrent. Peers in a torrent download equal-size chunks of the file from one another, with a typical chunk size of 256 KBytes.
When a peer first joins a torrent, it has no chunks. Over time it accumulates more and more chunks. While it downloads chunks it also uploads chunks to other peers. Once a peer has acquired the entire file, it may (selfishly) leave the torrent, or (altruistically) remain in the torrent and continue to upload chunks to other peers. Also, any peer may leave the torrent at any time with only a subset of chunks, and later rejoin the torrent.
Video Streaming and Content Distribution Networks
Internet Video
These prerecorded videos are placed on servers, and users send requests to the servers to view the videos on demand.
HTTP Streaming and DASH
In HTTP streaming, the video is simply stored at an HTTP server as an ordinary file with a specific URL. When a user wants to see the video, the client establishes a TCP connection with the server and issues an HTTP GET request for that URL.
However, it has a major shortcoming: All clients receive the same encoding of the video, despite the large variations in the amount of bandwidth available to a client, both across different clients and also over time for the same client.
Dynamic Adaptive Streaming over HTTP (DASH)
In DASH, the video is encoded into several different versions, with each version having a different bit rate and, correspondingly, a different quality level. The client dynamically requests chunks of video segments of a few seconds in length. When the amount of available bandwidth is high, the client naturally selects chunks from a high-rate version; and when the available bandwidth is low, it naturally selects from a low-rate version.
Content Distribution Networks
In order to meet the challenge of distributing massive amounts of video data to users distributed around the world, almost all major video-streaming companies make use of Content Distribution Networks (CDNs). A CDN manages servers in multiple geographically distributed locations, stores copies of the videos (and other types of Web content, including documents, images, and audio) in its servers, and attempts to direct each user request to a CDN location that will provide the best user experience. TheCDN may be a private CDN, that is, owned by the content provider itself; for example, Google’s CDN distributes YouTube videos and other types of content.
Socket Programming: Creating Network Applications
We’ll use the following simple client-server application to demonstrate socket programming for both UDP and TCP:
- The client reads a line of characters (data) from its keyboard and sends the data to the server. 2. The server receives the data and converts the characters to uppercase.
- The server sends the modified data to the client.
- The client receives the modified data and displays the line on its screen.
You can access the specified program files in My GitHub.