> For the complete documentation index, see [llms.txt](https://azunyan.gitbook.io/internet-protocol/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://azunyan.gitbook.io/internet-protocol/2.-application-layer/2.1-principles-of-network-applications.md). # 2.1 Principles of Network Applications ## 2.1.1 Network Application Architectures The application architecture is designed by the application developer and dictates how the application is structured over the various end systems. In choosing the application architecture, an application developer will likely draw on one of the two predominant architectural paradigms used in modern network applications: the **client-server architecture** or the **peer-to-peer (P2P) architecture**. In a **client-server architecture**, there is an always-on host, called the **server**, which services requests from many other hosts, called **clients**. Note that with the client-server architecture, clients do not directly communicate with each other; Another characteristic of the client-server architecture is that the server has a fixed, well-known address, called an IP address. Because the server has a fixed, well-known address, and because the server is always on, a client can always contact the server by sending a packet to the server’s IP address. Often in a client-server application, a single-server host is incapable of keeping up with all the requests from clients. For this reason, a data center, housing a large number of hosts, is often used to create a powerful virtual server. 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. One of the most compelling features of P2P architectures is their **self scalability**. However, P2P applications face challenges of security, performance, and reliability due to their highly decentralized structure. ## 2.1.2 Processes Communicating In the jargon of operating systems, it is not actually programs but **processes** that communicate. A process can be thought of as a program that is running within an end system. Processes on two different end systems communicate with each other by exchanging **messages** across the computer network. #### Client and Server Processes A network application consists of pairs of processes that send messages to each other over a network. 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.** It is also referred to as the Application Programming Interface (API) between the application and the network, since the socket is the programming interface with which network applications are built. #### Addressing Processes To identify the receiving process, two pieces of information need to be specified: (1) the address of the host and (2) an identifier that specifies the receiving process in the destination host. In the Internet, the host is identified by its **IP address.** In addition to knowing the address of the host to which a message is destined, the sending process must also identify the receiving process (more specifically, the receiving socket) running in the host. A destination **port number** serves this purpose. 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 Recall that a socket is the interface between the application process and the transport-layer protocol. We can broadly classify the possible services along four dimensions: reliable data transfer, throughput, timing, and security. #### Reliable Data Transfer One important service that a transport-layer protocol can potentially provide to an application is process-to-process reliable data transfer. When a transport protocol provides this service, the sending process can just pass its data into the socket and know with complete confidence that the data will arrive without errors at the receiving process. When a transport-layer protocol doesn’t provide reliable data transfer, some of the data sent by the sending process may never arrive at the receiving process. This may be acceptable for **loss-tolerant applications**. #### Throughput Available throughput, in the context of a communication session between two processes along a network path, is the rate at which the sending process can deliver bits to the receiving process. A natural service that a transport-layer protocol could provide, namely, guaranteed available throughput a 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**. While bandwidth-sensitive applications have specific throughput requirements, **elastic applications** can make use of as much, or as little, throughput as happens to be available #### Timing As with throughput guarantees, timing guarantees can come in many shapes and forms. An example guarantee might be that every bit that the sender pumps into the socket arrives at the receiver’s socket no more than 100 msec later. Such a service would be appealing to interactive real-time applications. #### Security 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 (and, more generally, TCP/ IP networks) makes two transport protocols available to applications, **UDP** and **TCP**. #### TCP Services * **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 an onslaught of packets. 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. * **Reliable data transfer service**. The communicating processes can rely on TCP to deliver all data sent without error and in the proper order. When one side of the application passes a stream of bytes into a socket, it can count on TCP to deliver the same stream of bytes to the receiving socket, with no missing or duplicate bytes. TCP also includes a congestion-control mechanism, a service for the general welfare of the Internet rather than for the direct benefit of the communicating processes. The TCP congestion-control mechanism throttles a sending process (client or server) when the network is congested between sender and receiver. #### UDP Services 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 Neither TCP nor UDP provides any encryption—the data that the sending process passes into its socket is the same data that travels over the network to the destination process. #### Services Not Provided by Internet Transport Protocols We have already noted that TCP provides reliable end-to-end data transfer. And we also know that TCP can be easily enhanced at the application layer with TLS to provide security services. But in our brief description of TCP and UDP, conspicuously missing was any mention of throughput or timing guarantees—services not provided by today’s Internet transport protocols. In summary, today’s Internet can often provide satisfactory service to time sensitive applications, but it cannot provide any timing or throughput guarantees. ## 2.1.5 Application-Layer Protocol An application-layer protocol defines how an application’s processes, running on different end systems, pass messages to each other. 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 ## 2.1.6 Network Applications Covered in This Book We first discuss the Web, not only because it is an enormously popular application, but also because its application-layer protocol, **HTTP**, is straightforward and easy to understand. We then discuss electronic mail, the Internet’s first killer application. E-mail is more complex than the Web in the sense that it makes use of not one but several application-layer protocols. After e-mail, we cover **DNS**, which provides a directory service for the Internet. **DNS** illustrates nicely how a piece of core network functionality (network-name to network-address translation) can be implemented at the application layer in the Internet. We then discuss **P2P** file sharing applications, and complete our application study by discussing video streaming on demand, including distributing stored video over content distribution networks. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://azunyan.gitbook.io/internet-protocol/2.-application-layer/2.1-principles-of-network-applications.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.