An over view of HTTP

                                             Crimson Security Group

                                                                 we yearn security......

Today my article is on HTTP Protocol. Instead of explain it regular manner, I want to explain it with some different way..

So,  We need to follow this Mind Map of HTTP protocol.

Here I am going to explain in step by step process at end we reach to security module means what are the security measures we need to take ....So, let's start  


About HTTP

 

What is HTTP ?

HTTP - Hyper Text Transfer protocol. HTTP is the core communication protocol used to access WWW. This provides resilience(the capacity to recover quickly from difficulties) in the event of communication errors and avoid the need of server to hold a open network connection to every user.It can also be proxied and tunneling over other protocols, allowing for secure communication in any network configuration.

HTTP is basically a client-server protocol, wherein the client(web browser) makes a request to the server and in return server responds to the request.The response by the server is mostly in the form of HTML formatted pages.HTTP protocol by default use port 80, but the web server and client can be configured to use a different port.

Let us understand the key design changes of HTTP, and the motivations behind each, will give us the necessary background for our discussions on HTTP performance, especially in the context of the many upcoming improvements in HTTP/2.  

HTTP 0.9: The One-line-Protocol

In 1991, Berners-Lee outlined the motivation for the new protocol and listed several high-level design goals: file transfer functionality, ability to request an index search of a hypertext archive, format negotiation, and an ability to refer the client to another server. To prove the theory in action, a simple prototype was built, which implemented a small subset of the proposed functionality:

 * Client request is a single ASCII character string. 

 * Client request is terminated by a carriage return (CRLF). 

 * Server response is an ASCII character stream.

 * Server response is a hypertext markup language (HTML). 

 * Connection is terminated after the document transfer is complete.

 consider an example with Telnet protocol....

         $> telnet example.com 80         ---> Connecting to domain through port 80 using Telnet

            Connected to 74.XX.XX.XX      ---> IP Address

            GET /about/                   ---> GET is method to get source

            (hypertext response)
            (connection closed)

 HTTP 1.0: Rapid Growth and Informational

The growing list of desired capabilities of the nascent Web and their use cases on the public Web quickly exposed many of the fundamental limitations of HTTP 0.9: we needed a protocol that could serve more than just hypertext documents, provide richer meta data about the request and the response, enable content negotiation, and more.

Consider an example....

$> telnet example.com 80

Connected to xxx.xxx.xxx.xxx

GET sample.txt HTTP/1.0     (request line with HTTP version number,followed by request headers)
User-Agent: CERN-LineMode/2.15              
Accept: */*

HTTP/1.0 200 OK          (Response status, followed by response headers)          
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 01 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 1 May 1996 12:45:26 GMT
Server: Apache 0.84

(plain-text response)
(connection closed)

The preceding exchange is not an exhaustive list of HTTP/1.0 capabilities, but it  does illustrate some of the key protocol changes: 

* Response object is prefixed with a response status line.

* Request may consist of multiple newline separated header fields. 

* Response object has its own set of newline separated header fields.

* Response object is not limited to hypertext

* The connection between server and client is closed after every request. 

Both the request and response headers were kept as ASCII encoded, but the response object itself could be of any type: an HTML file, a plain text file, an image, or any other content type. In reality, HTTP has quickly evolved to become a hypermedia transport, but the original name stuck.

In addition to media type negotiation, the RFC also documented a number of other commonly implemented capabilities: content encoding, character set support, multi-part types, authorization, caching, proxy behaviors, date formats, and more.  

HTTP/1.1: Internet Standard

The HTTP/1.1 standard resolved a lot of the protocol ambiguities found in earlier versions and introduced a number of critical performance optimizations: keep alive connections, chunked encoding transfers, byte-range requests, additional caching mechanisms, transfer encodings, and request pipelining.

Consider an example for request and response through telnet protocol ...

 

HTTP/1.1 changed the semantics of the HTTP protocol to use connection keep alive by default. Meaning, unless told otherwise (via Connection: close header), the server should keep the connection open by default.However, this same functionality was also back ported to HTTP/1.0 and enabled via the Connection: Keep-Alive header. Hence, if you are using HTTP/1.1, technically you don’t need the Connection: Keep-Alive header, but many clients choose to provide it nonetheless.

 Additionally, the HTTP/1.1 protocol added content, encoding, character set, and even language negotiation, transfer encoding, caching directives, client cookies, plus a dozen other capabilities that can be negotiated on each request.

What are the differences between HTTP1.0 and HTTP1.1........

      

     Reference link : http://www8.org/w8-papers/5c-protocols/key/key.html

HTTP/2: Improving Transport Performance


What began as a simple, one-line protocol for retrieving hypertext quickly evolved into a generic hypermedia transport, and now a decade later can be used to power just about any use case you can imagine. Both the ubiquity (presence everywhere) of servers that can speak the protocol and the wide availability of clients to consume it means that many applications are now designed and deployed exclusively on top of HTTP.

The simplicity of the HTTP protocol is what enabled its original adoption and rapid growth. In fact, it is now not unusual to find embedded devices—sensors, actuators, and coffee pots alike—using HTTP as their primary control and data protocols. But under the weight of its own success and as we increasingly continue to migrate our everyday interactions to the Web—social, email, news, and video, and increasingly our entire personal and job workspaces—it has also begun to show signs of stress. Users and web developers alike are now demanding near real-time responsiveness and protocol performance from HTTP/1.1, which it simply cannot meet without some modifications. 

To meet these new challenges, HTTP must continue to evolve, and hence the HTTPbis working group announced a new initiative for HTTP/2 in early 2012.

The primary focus of HTTP/2 is on improving transport performance and enabling both lower latency and higher throughput. The major version increment sounds like a big step, which it is and will be as far as performance is concerned, but it is important to note that none of the high-level protocol semantics are affected: all HTTP headers, values, and use cases are the same.  

Any existing website or application can and will be delivered over HTTP/2 without modification: you do not need to modify your application markup to take advantage of HTTP/2. The HTTP servers will have to speak HTTP/2, but that should be a transparent upgrade for the majority of users.

HTTP/2 Multiplexing .....

HTTP/2  Request Response Multiplexing...

If u have any queries regarding to HTTP/2 follow these link...
  
             
                    Reference Link: https://http2.github.io/faq/



TCP connection per HTTP request  with different HTTP protocol versions.......