Understanding network applications and network protocols

Network application is the reason why computer networks exist. If we don't envision any useful Web applications, then there's no need to design a network protocol that supports them. However, in the past 30 years, many people have devised a large number of sophisticated Web applications. These applications include text-based classic applications that have been popular since the the 1980s, such as remote computer access, e-mail, file transfer, newsgroups, chats, and so on, including the so-called multimedia applications in recent years, such as the web, Internet telephony, video conferencing, audio/video-on-demand, etc.

The software is almost always at its core, although there are many different types of Web applications that have a lot of interlaced parts. Software for network applications is distributed across two or more end systems (i.e., hosts). For example, Web Apps include two pieces of software that communicate with each other: browser software running on the user's host (PC, Mac, workstation, and so on), and Web server software running on the Web server. The Telnet application is also comprised of two pieces of software that run separately on the local host and the remote host. As for multiparty video conferencing, a subset of the software is running on each host that participates in the conference.

In the jargon of operating systems, communicating with one another is not actually a software component (the program) itself, but a process. We can think of a process as a program running in an end system. Processes running on the same end system communicate with each other through the use of interprocess communication. The specific rules for interprocess communication are determined by the operating system of the end system. This article does not care about interprocess communication within the same host, but is concerned with inter-process communication running on different hosts (the operating system may not be the same). Processes that run on different end systems communicate with each other over the network exchange messages. The sending process creates the message and passes it to the network; the receiving process collects the messages and may send the message as a response, as shown in the following figure. Each network application has its own application-layer protocol, which defines the format and sequence of messages exchanged between processes, as well as actions taken when sending or receiving messages.

　　Figure 1: Communication with each other should be with

The application layer is a good place for us to start studying the agreement. We are already familiar with many applications that rely on protocols. This will give us a sense of déjà vu, knowing that the purpose of the protocol is to help us understand many of the same problems that we will encounter when learning the Transport layer protocol, the Network layer protocol, and the Data Link layer protocol.

Network application is the reason why computer networks exist. If we don't envision any useful Web applications, then there's no need to design a network protocol that supports them. However, in the past 30 years, many people have devised a large number of sophisticated Web applications. These applications include text-based classic applications that have been popular since the the 1980s, such as remote computer access, e-mail, file transfer, newsgroups, chats, and so on, including the so-called multimedia applications in recent years, such as the web, Internet telephony, video conferencing, audio/video-on-demand, etc.

Application Layer Protocol

It is very important to differentiate between network application and Application layer protocol. The application layer protocol is only part of the Web application, let's look at a few examples. The Web is a Web application that allows users to obtain "documents" from a Web server on demand, and Web applications consist of a number of components, including standard in document format (Hypertext Markup Language HTML), Web browser software, Web server software (such as Apache, IIS Server), An application-level protocol. The application layer protocol for the web is Hypertext Transfer Protocol (HTTP), which defines how messages are passed between the browser and the Web server. So HTTP is only part of the Web App. Another example is an e-mail application. e-mail applications are also made up of a number of components, including mail servers that place user mailboxes, mail readers that let users read and create e-mail messages, a push to define the structure of e-mail messages, a set of definitions for how to pass e-mail messages between servers and between servers and readers, and explain their specific parts ( such as the letterhead) Application layer protocol. The primary application layer protocol for e-mail applications is the Simple Mail Transfer Protocol (SMTP). So SMTP is only part of the email app.

We have pointed out that application-layer protocols define how application processes running on different end systems pass messages to each other. Specifically, an application-layer protocol definition:

The type of message being passed, such as a request message and a response message.

The syntax for various message types, that is, the individual fields in the message and how they are bound.

The semantics of each field, that is, the meaning of the information in each field.

A rule that determines when and how a process will emit a message or respond to a message received.

Some application layer protocols are described in detail in the RFC documentation, which means they are in a free-to-access public domain. For example, HTTP can be obtained as an RfC. Browser software developers who follow the rules defined in the RFC can obtain Web pages from any Web server that also follows these rules. However, many other application layer protocols are proprietary and are intentionally not placed in the public domain. For example, many existing Internet telephony products use proprietary application-layer protocols.

　　Customers and servers

A network application protocol typically has two peer "end" or entities (client side) and server-side (side) that correspond to the client process running the client (the client) and the server process running the server program (the server), as shown in Figure 2. Clients in one end system communicate with each other on the server side of the other end system. For example, a Web browser implements an HTTP client, and the Web server implements an HTTP server side. In the e-mail app, the mail server that sends the mail message plays the SMIP client role, and the mail server that receives the mail message plays the server-side role of SMTP.

　Figure 2: Client/server interaction

For many applications, their client and server side can be implemented on a single host at the same time. Take the example of a Telnet session between host A and Host B. If this Telnet session is initiated by host a (that is, a user on host A is logged on to Host B), then host A is running the application's client, and Host B is running the application's server side. Conversely, if this Telnet session is initiated by Host B, then Host B runs the client for that application. An additional example is provided for FTP to transfer files between two hosts. Once an FTP session is started between two hosts, any one of the hosts can communicate the file to another host before the end of the session. Nonetheless, we are marking the host of the initiating session as a customer, as is the case with almost all Web applications. In addition, a single host may actually be both a client host and a server host for a given application. For example, the mail server host runs both the SMLP client (for sending mail) and the server side (for receiving mail).

　Inter-process communication across the network

A network application involves two processes that communicate with each other across networks in two different hosts (of course, multicast network applications may involve communication between more than two hosts). The two processes communicate with each other by sending and receiving messages through their sockets. We can think of the socket as the "gate" on the corresponding process: The process sends the message to the network or receives the message from the network through its own socket. When a process wants to send a message to another process in another host, it launches the message into its own door. The process identified a transmission facility on the other side of the door that would transmit the message to the doorway of the destination process.

Figure 3 shows the socket communication between two processes that communicate with each other over the Internet (this figure assumes that the underlying transport protocol is TCP, but UDP can be used as well). A visible socket is an interface between the application layer and the transport layer within a single host. Sockets are also used to refer to the application interface between the application and the Network (application program interface, or API), as it is another programming interface for constructing network applications in the Internet. Application developers have full control over the application layer side of the socket and are almost powerless on the side of the socket's transport layer. For the transport layer side they can only control: (1) The choice of Transmission protocol, (2) such as the maximum buffer size and the maximum fragment size, such as a limited number of transport layer parameters adjustment. Once an available transport protocol is selected, the application is constructed using the Transport Layer service provided by the Protocol.

Figure 3: Application process, socket

Process addressing

For a process in one host to send a message to a process in another host, the sending process must be able to identify the receiving process. The information used to identify the receiving process has two: (1) The host name or host address of the receiving host, and (2) The identifier of the receiving process that is recognized internally within the receiving host.

Let's consider the host address first. In Internet applications, the receiving host is identified with its IP address (1P addresse). Now, we know that the IP address is a unique 32-bit binary value that uniquely identifies each end of the system (more precisely, the IP address uniquely identifies the network interface that connects each host to the Internet), since the IP address of any end system connected to the public Internet must be globally unique, and the allocation of IP addresses must be carefully managed. The addressing standards for ATM networks are different from the Internet. ITU-T has provided for the use of addresses of similar telephone numbers called e-mail addresses (ITU1997) in public ATM networks.

In addition to knowing the address of the system on which the receiving process resides, the sending process has to specify information that allows the receiving system to direct the transmitted message to the receiving process. The port number of the receiving process is used for this purpose in the Internet. The popular Application layer protocol has been given a specific port number. For example, a Web server process using the HTTP protocol is identified by the port number 80, and the mail server using the SMTP protocol is identified by the end gate number 25. RFC 1700 Lists all the known port numbers for Internet standard protocols. When developing a new network application, it must be given a new port number.

User Agent

Before you start studying the Application layer protocol, it might be helpful to discuss the user agent concept. A user agent is an interface that resides between a user and a network application. For example, a web app's user agent is a browser such as Netscape Navigator and Microsoft Internet Explore. Browsers make it possible to watch Web pages, surf the Web, provide form input, interact with small Java applications, and more. The browser also implements the HTTP protocol for the client. So after the launch of the browser in addition to provide an interface to the user, its process is also sent through a socket to receive messages. Another example is about the e-mail application. The user agent for the e-mail app is the Mail reader, which enables users to write and read mail messages. Many companies offer Mail readers (such as Eudora,netscape messenger,microsoft Outlook) that can run graphical user interfaces on PCs, Mac machines, and workstations. A mail reader running on a PC also implements a client for multiple application layer protocols, typically a client that has an SMTP protocol for sending mail. And a client that retrieves a message retrieval protocol, such as POP3 or IMAP.

Service required by the application

We know that the socket is the interface between the application process and the transport protocol. The application process on the sending side sends out messages through this door. On the other side of the door, the transport protocol is responsible for transmitting these messages across the network to the doorway of the receiving process. Many network architectures, including the Internet, provide more than one transport protocol. When developing an application, you must select one of the available transport protocols. How do you make a choice? The most likely scenario is to first examine the services provided by the available transport protocols and then select the protocols that best match the needs of their services to the application. This is similar to whether you choose to travel by train or by plane when traveling between two cities. You can only choose one of these modes of transport, and each provides a different service (for example, trains provide urban passenger services.). The aircraft offers shorter transit times.

What kind of service can a network application require from a transport protocol? We can divide the service requirements of the network application roughly into the following 3 scales: reliability, bandwidth, real-time performance.

　Reliability

Some applications require complete and reliable transmission of data, i.e. no data loss, such as e-mail, file transfer, remote host access, Web document transfer, financial applications, etc. The disastrous consequences of missing file data or financial transaction data are conceivable. There are also some loss tolerance applications (lose-tolerant application) that tolerate a certain amount of data loss, such as multimedia applications such as real-time audio/video or warehousing audio/video. In the case of lost and tolerated multimedia applications, the loss of data may introduce short-term pulse interference in the audio/video playback, but it is not a vital damage. The impact of data loss on the quality of applications and the actual amount of packet loss that can be tolerated is strongly dependent on the application itself and the encoding scheme used.

Bandwidth

Some applications must transmit data at a specific sustained rate to be effective. For example, if an Internet phone is applying a 32Kbps rate-coded voice, it must be able to send data to the network at the same rate and then be delivered to the receiving application by the network. If this amount of bandwidth is not available, the application can be encoded at a lower rate, and the bandwidth sufficient to maintain the encoding rate is obtained, otherwise it will only be discarded, because for such a bandwidth-sensitive application (bandwidth-sensitive application), It is useless to just get half of the required bandwidth. Many current multimedia applications are bandwidth-sensitive, but future multimedia applications may use adaptive coding techniques that can be encoded at a rate that matches the current available bandwidth. Bandwidth-sensitive applications require a given amount of bandwidth, and in contrast, elastic applications (elastic application) can use bandwidth as much as possible depending on the amount of temporary availability. e-mail, file transfer, remote access, web transfer, etc. are all elastic applications. Sure, the higher the bandwidth, the better.

　　Real-time sex

Interactive real-time applications such as Internet telephony, virtual environments, teleconferencing, multiparty games, etc. require data delivery to meet stringent timing limits to ensure effectiveness. Many of these applications require an order of magnitude of hundreds of milliseconds or less for end-to-end latency. For example, long delays in internet telephony often lead to unnatural pauses in conversations: in multi-party games or virtual interactions, a long delay between taking action and seeing a response from the environment (such as seeing a response from another player at the end of an end-to-end connection) makes the app feel unrealistic. For non-real-time applications, low-latency total high latency is preferable, but they do not impose any stringent restrictions on end-to-end latency.

The following table summarizes the reliability, bandwidth, and real-time requirements of some popular and emerging internet applications. This is just a summary of some of the key needs of some of the more popular Internet applications. Our goal is not to provide a complete classification of the needs of the Web application, but to simply identify some of the most important axes that can be categorized as network application requirements.

Table 1: Service Requirements for some Web applications

The Internet (more generally, TCP Network) provides two transport protocols to the application: the User Datagram Protocol (Userdatagram PROTOCOL,UDP) and the Transmission Control Protocol (Transaction). When a developer creates a new Internet application, he must select either UDP or TCP as one of the two protocols for the application. These two protocols provide different service models to the application.

Services provided by the Internet Transport Protocol

TCP Service

The TCP service model includes connection-oriented services and reliable data transfer services. Call TCP as the application of its transport protocol to both of these services.

A connection-oriented service refers to the client and server-side TCP to exchange transport-layer control information before starting to transmit the application-layer message. This so-called handshake process alerts customers and servers so that they are ready for the group impact from each other. After the handshake phase is over, we say there is a TCP connection (TCP connection) between the two processes ' sockets. This is a full-duplex connection, which means that both the client and server processes can send messages to each other through the connection at the same time. After the message is sent, the application process must tell TCP to remove the connection. The rationale for this service as a "connection-oriented" service rather than a "connect" service (or "virtual circuit" service) is that the processes on both sides of it are connected in a very loose manner.

A reliable transport service refers to processes that communicate with each other and can rely on TCP to deliver all data in an error-free order. When any one of the application processes passes a byte stream into the socket, it can expect TCP to deliver the same byte stream to the other's socket, without the loss or repetition of bytes in the middle.

TCP also includes a congestion control mechanism, which is a public service for the Internet and is not intended to benefit directly from the process of communicating with each other. The TCP congestion control mechanism suppresses the sending process (either a customer or a server) when the network becomes congested. Specifically, TCP congestion control attempts to limit each TCP connection to its fairly shared network bandwidth. For real-time audio and video applications with minimum bandwidth requirements, suppressing transmission rates can have bad consequences. In addition, real-time applications tolerate data loss without the need for fully reliable transport services. For these reasons, developers of real-time applications are often designed to run their apps on UDP instead of TCP.

After outlining the services provided by TCP, let's talk about the services that TCP does not provide. First, TCP does not guarantee the minimum transfer rate. Specifically, TCP does not allow the sending process to send at any rate desired, whereas the sending rate is regulated by TCP congestion control, and the sending process may be forced to send at a lower average rate. Second, TCP does not provide any delay guarantees. Specifically, after the sending process passes the data to its own TCP socket, the data will eventually reach its receiving socket, but for how long it takes for that data to arrive there, TCP is definitely not guaranteed. Spend dozens of seconds or even a few minutes waiting for TCP to deliver a message from the Web server to a Web browser (for example, it contains an HTML file) is not uncommon. In summary, TCP guarantees delivery of all data, but does not guarantee the delivery rate and the latency experienced.

UDP service

UDP is a lightweight transport protocol that does not provide non-essential services and has a minimalist service model. UDP is not connected, so there is no handshake process before two processes communicate with each other. UDP provides unreliable data transfer services, which means that when a process sends a message to its own UDP socket, UDP does not guarantee that the message will eventually reach the receiving socket. Also, when you do arrive at a message that receives a socket, the order in which they arrive may also be inconsistent with the order in which they were sent.

UDP does not contain congestion control mechanisms, so the sending process can pour data into UDP sockets at any rate. Although there is no guarantee that all data will reach the receiving socket, there will still be a considerable percentage of data arriving. Developers of real-time applications often choose to run their apps on UDP. Like TCP, UTP does not provide any delay guarantees.

The following table identifies the transport protocols used by some popular Internet applications. We see that e-mail, remote terminal access, Web, and file transfer all use TCP. The main reason for these applications to choose TCP is that TCP provides reliable data transfer services that ensure that all of the information eventually reaches its destination. We also see that internet telephony generally runs on top of UDP. Both ends of an Internet Telephony application can send data across the network at a minimum rate: UDP is more likely to meet this requirement than TCP. In addition, Internet telephony applications can tolerate data loss and therefore do not require reliable data transfer services provided by TCP.

Table 2: Popular applications and Protocols adopted

We have pointed out that both TCP and UDP do not provide timing guarantees, does this mean that time-sensitive applications cannot run on the Internet today? The answer is clearly no--time-sensitive applications have been around the internet for years. These applications tend to work quite well because they have been designed to deal with this lack of assurance to the greatest extent possible. Even so, when the delay is too large (which is common in the public Internet), the smartest design has its limitations. In short, today's internet often provides a satisfying service for time-sensitive applications, but does not provide any timing or bandwidth guarantees.

　The network application that this article prepares to introduce

On the Internet, public domain and proprietary applications abound. We don't want an encyclopedic list of Internet applications, so we've chosen a handful of important and popular applications to focus on. We will discuss 4 popular applications in detail: Web, File transfer, e-mail, directory services. We discuss the Web first, not only because the Web is an extremely popular application, but also because its application-layer protocol, or HTTP, is relatively simple and can be used to illustrate many of the key elements of network protocols. The next discussion of file transfer, because its protocol is exactly in contrast to HTTP, allows us to highlight some additional factors. We also discuss e-mail, which is the first highly popular application in the Internet. It should be seen that modern e-mail uses more than one application layer protocol. Web, file transfer, and e-mail have a common service requirement: Reliable transport services, no special timing requirements, and flexible bandwidth services. The services provided by TCP fully meet these 3 applications. Domain name SYSTEM,DN5 is the 4th application we have discussed, which provides directory services for the Internet. Most users do not interact directly with DNS; instead, they indirectly resort to DNS through other applications, including the 3 apps that are about to be discussed. DNS subtly demonstrates how a distributed database can be implemented in the Internet. The 4 applications that are about to be discussed are not very sensitive to time.