Hypertext Transfer Protocol

Posted 2021-02-16 hahaccy

Network Performance

Latency(Propagation time; Transmission time)

Data Transfer Rate(Bandwidth)

Retransmission(Dropped packets)

Under Light Traffic

Message Length Message Transmission Time = Latency +Message Length/Bandwidth

 

OSI reference Model

Application:HTTP, SMTP, POP, IMAP, FTP, VOIP JSON, XML, ASN.1, MIME

Presentation:JSON, XML, ASN.1, MIME

Session:SSL

Transport:IP, X.25

Network:IP, X.25

Data Link:Ethernet MAC, PPP

Physical:USB, Bluetooth, 1000BaseT

 

 

IP stack

middleware=presentation+session

 

Internet Protocol (IP)
• A set of protocols for the interconnection of many LANs and WANs that make up the Internet
• IPv4 and IPv6 (network layer)

IP Transport Layer Protocols
• Transmission Control Protocol (TCP)
– Connection-oriented
– Full duplex
– Reliable and in-order
– Flow and congestion control
• User Datagram Protocol (UDP)
– Connectionless
– Packets may arrive out of sequence – Corrupt data are dropped

Application Layer Protocols
Request Protocols
Request-Reply Protocols
Request-Reply-Acknowledge Protocols

 

 

In a networked system a client is considered to be a requester of some service and a server is the provider of a service.

A protocol used at the application layer for communication between a client and a server is typically layered on top of either TCP or UDP and is sometimes classified into one of three types:
Request protocol where a single request is made from the client to the server, used when the client does not require a response and no confirmation is required. 

If UDP is used then there is no guarantee that the request has actually been received by the server. Request-Reply protocol where a request is made from the client to the server, prompting the server to perform some function and return an appropriate reply. Often this communication is implemented over TCP but can be more efficiently implemented over UDP as the reply itself provides a confirmation to the client that the server received the request, and if the client does not receive a response within a reasonable time then it can just send another request. For efficiency the server might cache responses in case it receives a request multiple times from a client.

Request-Reply-Acknowledge protocol which is similar to a request-reply protocol but where after receiving a reply the client confirms its receipt by sending an acknowledgement message to the server. When the server receives the acknowledgement it can clear its cache.

The request-reply protocol is the most common type of protocol for client-server communication. The Hypertext Transfer Protocol (HTTP) is an important and very common request-reply protocol implemented over TCP that is used for communication with web servers. In HTTP version 1.0 a client initiates a TCP connection to a server, typically on port 80, sends a request message to the server, which sends back a response, and then the connection is closed.

As HTTP clients are frequently browsers that must make a request for each resource in a web page (such as for each image in the page), HTTP 1.1 allows the connection to remain alive for a series of further request-reply exchanges, avoiding the overhead of reestablishing a connection for each request.
An HTTP request is an ASCII text string that starts with an HTTP method name, followed by the URL of a resource on the server, the version of HTTP used (such as HTTP/1.1), some headers (containing information such as acceptable data formats and whether to keep the connection alive), and an optional message body containing data. Method names supported by HTTP include:

GET which requests the server to retrieve the specified resource, such as data or
the output of a program,
HEAD which is the same as GET but only information about the resource is re- trieved, such as when it was last modified,
POST which is similar to GET but can be more suitable for passing data with the request,
PUT which requests the server to store the data in the request at the specified URL (this operation might not be allowed by the server),
DELETE which requests the server to delete the resource at the specified URL (this operation might not be allowed by the server),
OPTIONS which requests the server to respond with a list of the method names that it allows to be applied to the resource at the specified URL,
TRACE which requests the server to echo back the request message (used for testing).
An HTTP response from the server to a client starts with the version of HTTP, a three-digit status code (such as 200 for okay, 400 for bad request, or 404 for resource not found), a corresponding text reason, some headers (containing information about the server and resource such as its MIME content type and length), and an optional message body (which might contain data such as the resource for a GET or POST request).
The class EchoWebServer slightly modifies the approach of EchoServer from Section 1.2. Instead of replying with an exact copy of a TCP request it treats it as an HTTP request and sends an HTTP reply containing the request in the message body as an html page. Although at first this might appear strange, it is very common for web servers to send HTTP replies containing HTML pages so that the response can be viewed by a browser.
Testing the class EchoWebServer with a Firefox browser (using the URL http://localhost:8080/) results in the following web page being displayed:
EchoWebServer Response

Cookies

If a client allows cookies (small pieces of text data) to be stored, then the server can create a cookie containing a unique ID for each clien, which it sends to the client as part of its first response, and which the client includes with any further requests. These cookies can be read by the server whenever it needs to distinguish between clients (such as when items are added to a shopping cart or an on-line payment is made. The ID stored in each cookie is typically used to look up session information for that client in a hash table.
URL-rewriting Any URL that is returned to a client has extra information appended to it by the server in order to identify that client, such as:
<FORM ACTION=
"http://localhost:8080/Whatever;mysessionid=123">
...
</FORM>
This information can be extracted from the next GET or POST request that
is made when the form data is submitted.
Hidden form fields A form that has been passed back to a client contains a hidden input holding information to identify the client:
firstname=Joe&lastname=Bloggs&Fire=fire

 

The hidden input does not appear when the web page is displayed, but its name and value is included when the form is submitted.
Server programs are extensively used as web servers in both the Internet and organization intranets for processing web page form submissions and providing HTTP replies containing HTML suitable for presentation in a web browser. Such programs are called common gateway interface (CGI) programs.