Request-response protocols
Numerous networking protocols have been developed for sharing information from one point of the Internet to the other. Almost all of the protocols use the TCP/IP Internet protocol suite. This has enabled the free flow of information across the globe, and it has also had an immeasurable impact on modern business and commerce, which rely greatly on computer networks and distributed computing.
This diagram shows a very simple but typical arrangement. In enterprise settings, the two halves will likely be on the same network, or perhaps a VPN is used to securely connect clients to the servers. For eCommerce, SaaS (Software as a Service) and other Internet offerings, the servers might be hosted in the provider’s datacenter or even with a third-party provider like Amazon Elastic Compute Cloud (EC2), Google Cloud Platform, or Microsoft Azure. The main components of interest here are clients, on the left, and servers, on the right.
A client is a program that initiates communication-usually by creating a TCP connection. It may be an end-user program, initiating communication to request information or resources that it presents to a user. In web applications, for example, the client is a web browser such as Chrome or Firefox.
A server is a program that accepts these client connections and in turn processes their requests. There are many kinds of servers. The diagram shows an application server, so named because it serves data to the client application. (It is also called a web server if it uses HTTP as the communication protocol). As shown in the diagram, the application server may involve other computers in order to serve responses. In that case, the server also acts as a client. In the diagram, the application server acts as a database client, requesting information from the database server.
Most networking protocols follow this pattern: a client creates a network connection to the server and sends requests. The server accepts requests, performs some processing, and then sends responses. This request-response flow was conceived in the early days of networking in the 1960’s and has been foundational to distributed computing ever since.
