HTTP/1.0和HTTP/1.1 http2.0的區別，HTTP怎麼處理長鏈接（阿里）

 

HTTP1.0 HTTP 1.1主要區別

長鏈接

HTTP 1.0須要使用keep-alive參數來告知服務器端要創建一個長鏈接，而HTTP1.1默認支持長鏈接。

HTTP是基於TCP/IP協議的，建立一個TCP鏈接是須要通過三次握手的,有必定的開銷，若是每次通信都要從新創建鏈接的話，對性能有影響。所以最好能維持一個長鏈接，能夠用個長鏈接來發多個請求。

節約帶寬

HTTP 1.1支持只發送header信息(不帶任何body信息)，若是服務器認爲客戶端有權限請求服務器，則返回100，不然返回401。客戶端若是接受到100，纔開始把請求body發送到服務器。

這樣當服務器返回401的時候，客戶端就能夠不用發送請求body了，節約了帶寬。

另外HTTP還支持傳送內容的一部分。這樣當客戶端已經有一部分的資源後，只須要跟服務器請求另外的部分資源便可。這是支持文件斷點續傳的基礎。

HOST域

如今能夠web server例如tomat，設置虛擬站點是很是常見的，也便是說，web server上的多個虛擬站點能夠共享同一個ip和端口。

HTTP1.0是沒有host域的，HTTP1.1才支持這個參數。

HTTP1.1 HTTP 2.0主要區別

多路複用

HTTP2.0使用了(相似epoll)多路複用的技術，作到同一個鏈接併發處理多個請求，並且併發請求的數量比HTTP1.1大了好幾個數量級。

固然HTTP1.1也能夠多創建幾個TCP鏈接，來支持處理更多併發的請求，可是建立TCP鏈接自己也是有開銷的。

TCP鏈接有一個預熱和保護的過程，先檢查數據是否傳送成功，一旦成功過，則慢慢加大傳輸速度。所以對應瞬時併發的鏈接，服務器的響應就會變慢。因此最好能使用一個創建好的鏈接，而且這個鏈接能夠支持瞬時併發的請求。

數據壓縮

HTTP1.1不支持header數據的壓縮，HTTP2.0使用HPACK算法對header的數據進行壓縮，這樣數據體積小了，在網絡上傳輸就會更快。

服務器推送

意思是說，當咱們對支持HTTP2.0的web server請求數據的時候，服務器會順便把一些客戶端須要的資源一塊兒推送到客戶端，省得客戶端再次建立鏈接發送請求到服務器端獲取。這種方式很是合適加載靜態資源。

服務器端推送的這些資源其實存在客戶端的某處地方，客戶端直接從本地加載這些資源就能夠了，不用走網絡，速度天然是快不少的。

 

 

1.HTTP簡介

　　web瀏覽器和服務器之類的交互過程必須遵照的協議.他是tcp/ip中的一個應用協議。用來協議數據交換過程和數據自己的格式.主要的有HTTP/1.0和HTTP1.1. 

　　HTTP/1.0和HTTP/1.1都把TCP做爲底層的傳輸協議。

　　HTTP客戶首先發起創建與服務器TCP鏈接。一旦創建鏈接，瀏覽器進程和服務器進程就能夠經過各自的套接字來訪問TCP。如前所述，客戶端套接字是客戶進程和TCP鏈接之間的「門」，服務器端套接字是服務器進程和同一TCP鏈接之間的 「門」。客戶往本身的套接字發送HTTP請求消息，也從本身的套接字接收HTTP響應消息。相似地，服務器從本身的套接字接收HTTP請求消息，也往本身 的套接字發送HTTP響應消息。客戶或服務器一旦把某個消息送入各自的套接字，這個消息就徹底落入TCP的控制之中。

　　TCP給HTTP提供一個可靠的數據傳輸服務;這意味着由客戶發出的每一個HTTP請求消息最終將無損地到達服務器，由服務器發出的每一個HTTP響應消息最終也將無損地到達客戶。咱們可從中看到分層網絡體系結構的一個明顯優點——HTTP沒必要擔憂數據會丟失，也無需關心TCP如何從數據的丟失和錯序中恢復出來的細節。這些是TCP和協議棧中更低協議層的任務。

　　TCP還使用一個擁塞控制機制。該機制迫使每一個新的TCP鏈接一開始以相對緩慢的速率傳輸數據，然而只要網絡不擁塞，每一個鏈接能夠迅速上升到相對較高的速率。這個慢速傳輸的初始階段稱爲緩啓動(slow start)。

　　須要注意的是，在向客戶發送所請求文件的同時，服務器並無存儲關於該客戶的任何狀態信息。即使某個客戶在幾秒鐘內再次請求同一個對象，服務器也不會響應說:本身剛剛給它發送了這個對象。相反，服務器從新發送這個對象，由於它已經完全忘記早先作過什麼。既然HTTP服務器不維護客戶的狀態信息，咱們因而 說HTTP是一個無狀態的協議(stateless protocol)。

 2.一個完整的HTTP請求過程

　　HTTP事務=請求命令+響應結果

　　

　　一次完整的請求過程：

　　（1）域名解析

　　（2）創建TCP鏈接，三次握手

　　（3）Web瀏覽器向Web服務端發送HTTP請求報文

　　（4）服務器響應HTTP請求

　　（5）瀏覽器解析HTML代碼，並請求HTML代碼中的資源（JS，CSS，圖片）（這是自動向服務器請求下載的）

　　（6）瀏覽器對頁面進行渲染呈現給客戶

　　（7）斷開TCP鏈接

如何解析對應的IP地址？域名解析過程（注意了先走本地再走DNS）

 3.HTTP/1.0和HTTP/1.1的區別

　　HTTP 協議老的標準是HTTP/1.0，目前最通用的標準是HTTP/1.1。　　

　　在同一個tcp的鏈接中能夠傳送多個HTTP請求和響應.
　　多個請求和響應能夠重疊，多個請求和響應能夠同時進行.
　　更加多的請求頭和響應頭(好比HTTP1.0沒有host的字段).

　　它們最大的區別：
　　在 HTTP/1.0 中,大多實現爲每一個請求/響應交換使用新的鏈接。HTTP 1.0規定瀏覽器與服務器只保持短暫的鏈接，瀏覽器的每次請求都須要與服務器創建一個TCP鏈接，服務器完成請求處理後當即斷開TCP鏈接，服務器不跟蹤每一個客戶也不記錄過去的請求。

　　在 HTTP/1.1 中,一個鏈接可用於一次或屢次請求/響應交換,儘管鏈接可能因爲各類緣由被關閉。HTTP 1.1支持持久鏈接，在一個TCP鏈接上能夠傳送多個HTTP請求和響應，減小了創建和關閉鏈接的消耗和延遲。一個包含有許多圖像的網頁文件的多個請求和應答能夠在一個鏈接中傳輸，但每一個單獨的網頁文件的請求和應答仍然須要使用各自的鏈接。HTTP 1.1還容許客戶端不用等待上一次請求結果返回，就能夠發出下一次請求，但服務器端必須按照接收到客戶端請求的前後順序依次回送響應結果，以保證客戶端可以區分出每次請求的響應內容，這樣也顯著地減小了整個下載過程所須要的時間。

　　舉例說明：

　　一個包含有許多圖像的網頁文件中並無包含真正的圖像數據內容，而只是指明瞭這些圖像的URL地址，當WEB瀏覽器訪問這個網頁文件時，瀏覽器首先要發出針對該網頁文件的請求，當瀏覽器解析WEB服務器返回的該網頁文檔中的HTML內容時，發現其中的<img>圖像標籤後，瀏覽器將根據<img>標籤中的src屬性所指定的URL地址再次向服務器發出下載圖像數據的請求。

　　

　　顯然，訪問一個包含有許多圖像的網頁文件的整個過程包含了屢次請求和響應，每次請求和響應都須要創建一個單獨的鏈接，每次鏈接只是傳輸一個文檔和圖像，上一次和下一次請求徹底分離。即便圖像文件都很小，可是客戶端和服務器端每次創建和關閉鏈接倒是一個相對比較費時的過程，而且會嚴重影響客戶機和服務器的性能。當一個網頁文件中包含Applet，JavaScript文件，CSS文件等內容時，也會出現相似上述的狀況。

　　爲了克服HTTP 1.0的這個缺陷，HTTP 1.1支持持久鏈接，在一個TCP鏈接上能夠傳送多個HTTP請求和響應，減小了創建和關閉鏈接的消耗和延遲。一個包含有許多圖像的網頁文件的多個請求和應答能夠在一個鏈接中傳輸，但每一個單獨的網頁文件的請求和應答仍然須要使用各自的鏈接。

　　HTTP 1.1還容許客戶端不用等待上一次請求結果返回，就能夠發出下一次請求，但服務器端必須按照接收到客戶端請求的前後順序依次回送響應結果，以保證客戶端可以區分出每次請求的響應內容，這樣也顯著地減小了整個下載過程所須要的時間。

　　基於HTTP 1.1協議的客戶機與服務器的信息交換過程，以下圖所示

　　

　　可見，HTTP 1.1在繼承了HTTP 1.0優勢的基礎上，也克服了HTTP 1.0的性能問題。

還有哪些小的區別呢？

　　HTTP 1.1還經過增長更多的請求頭和響應頭來改進和擴充HTTP 1.0的功能。

　　例如，因爲HTTP 1.0不支持Host請求頭字段，WEB瀏覽器沒法使用主機頭名來明確表示要訪問服務器上的哪一個WEB站點，這樣就沒法使用WEB服務器在同一個IP地址和端口號上配置多個虛擬WEB站點。

　　在HTTP 1.1中增長Host請求頭字段後，WEB瀏覽器可使用主機頭名來明確表示要訪問服務器上的哪一個WEB站點，這才實現了在一臺WEB服務器上能夠在同一個IP地址和端口號上使用不一樣的主機名來建立多個虛擬WEB站點。

　　HTTP 1.1的持續鏈接，也須要增長新的請求頭來幫助實現。

　　例如，Connection請求頭的值爲Keep-Alive時，客戶端通知服務器返回本次請求結果後保持鏈接；Connection請求頭的值爲close時，客戶端通知服務器返回本次請求結果後關閉鏈接。

　　HTTP 1.1還提供了與身份認證、狀態管理和Cache緩存等機制相關的請求頭和響應頭。

4.Http怎麼處理長鏈接

　　　基於http協議的長鏈接

         在HTTP1.0和HTTP1.1協議中都有對長鏈接的支持。其中HTTP1.0須要在request中增長」Connection： keep-alive「 header纔可以支持，而HTTP1.1默認支持.

      http1.0請求與服務端的交互過程:

      （1）客戶端發出帶有包含一個header：」Connection： keep-alive「的請求

      （2）服務端接收到這個請求後,根據http1.0和」Connection： keep-alive「判斷出這是一個長鏈接,就會在response的header中也增長」Connection： keep-alive「，同時不會關閉已創建的tcp鏈接.

      （3）客戶端收到服務端的response後,發現其中包含」Connection： keep-alive「，就認爲是一個長鏈接，不關閉這個鏈接。並用該鏈接再發送request.轉到（1）

    http1.1請求與服務端的交互過程:

    （1）客戶端發出http1.1的請求

    （2）服務端收到http1.1後就認爲這是一個長鏈接,會在返回的response設置Connection： keep-alive,同時不會關閉已創建的鏈接.

    （3）客戶端收到服務端的response後,發現其中包含」Connection： keep-alive「，就認爲是一個長鏈接，不關閉這個鏈接。並用該鏈接再發送request.轉到（1）

     基於http協議的長鏈接減小了請求,減小了創建鏈接的時間,可是每次交互都是由客戶端發起的,客戶端發送消息,服務端才能返回客戶端消息。由於客戶端也不知道服務端何時會把結果準備好，因此客戶端的不少請求是多餘的,僅是維持一個心跳,浪費了帶寬。

栗子：下列哪些http方法對於服務端和用戶端必定是安全的？（C）　　

　　　　A.GET

　　　　B.HEAD

　　　　C.TRACE

　　　　D.OPTIONS

　　　　E.POST

TRACE: 這個方法用於返回到達最後服務器的請求的報文，這個方法對服務器和客戶端都沒有什麼危險。

 

HTTP是無狀態的 
也就是說，瀏覽器和服務器每進行一次HTTP操做，就創建一次鏈接，但任務結束就中斷鏈接。若是客戶端瀏覽器訪問的某個HTML或其餘類型的Web頁中包含有其餘的Web資源，如JavaScript文件、圖像文件、CSS文件等；當瀏覽器每遇到這樣一個Web資源，就會創建一個HTTP會話

HTTP1.1和HTTP1.0相比較而言，最大的區別就是增長了持久鏈接支持(貌似最新的 http1.0 能夠顯示的指定 keep-alive),但仍是無狀態的，或者說是不能夠信任的。

若是瀏覽器或者服務器在其頭信息加入了這行代碼

Connection:keep-alive

TCP鏈接在發送後將仍然保持打開狀態，因而，瀏覽器能夠繼續經過相同的鏈接發送請求。保持鏈接節省了爲每一個請求創建新鏈接所需的時間，還節約了帶寬。

實現長鏈接要客戶端和服務端都支持長鏈接。

若是web服務器端看到這裏的值爲「Keep-Alive」，或者看到請求使用的是HTTP 1.1（HTTP 1.1默認進行持久鏈接），它就能夠利用持久鏈接的優勢，當頁面包含多個元素時（例如Applet，圖片），顯著地減小下載所須要的時間。要實現這一點， web服務器須要在返回給客戶端HTTP頭信息中發送一個Content-Length（返回信息正文的長度）頭，最簡單的實現方法是：先把內容寫入ByteArrayOutputStream，然 後在正式寫出內容以前計算它的大小

不管客戶端瀏覽器 (Internet Explorer) 仍是 Web 服務器具備較低的 KeepAlive 值，它都將是限制因素。例如，若是客戶端的超時值是兩分鐘，而 Web 服務器的超時值是一分鐘，則最大超時值是一分鐘。客戶端或服務器均可以是限制因素

在header中加入 --Connection:keep-alive 
在HTTp協議請求和響應中加入這條就能維持長鏈接。 
再封裝HTTP消息數據體的消息應用就顯的很是簡單易用

Http Keep-Alive seems to be massively misunderstood. Here's a short description of how it works, under both 1.0 and 1.1

HTTP/1.0

Under HTTP 1.0, there is no official specification for how keepalive operates. It was, in essence, tacked on to an existing protocol. If the browser supports keep-alive, it adds an additional header to the request:

Connection: Keep-Alive

Then, when the server receives this request and generates a response, it also adds a header to the response:

Connection: Keep-Alive

Following this, the connection is NOT dropped, but is instead kept open. When the client sends another request, it uses the same connection. This will continue until either the client or the server decides that the conversation is over, and one of them drops the connection.

HTTP/1.1

Under HTTP 1.1, the official keepalive method is different. All connections are kept alive, unless stated otherwise with the following header:

Connection: close

The Connection: Keep-Alive header no longer has any meaning because of this.

Additionally, an optional Keep-Alive: header is described, but is so underspecified as to be meaningless. Avoid it.

Not reliable

HTTP is a stateless protocol - this means that every request is independent of every other. Keep alive doesn’t change that. Additionally, there is no guarantee that the client or the server will keep the connection open. Even in 1.1, all that is promised is that you will probably get a notice that theconnection is being closed. So keepalive is something you should not write your application to rely upon.

KeepAlive and POST

The HTTP 1.1 spec states that following the body of a POST, there are to be no additional characters. It also states that "certain" browsers may not follow this spec, putting a CRLF after the body of the POST. Mmm-hmm. As near as I can tell, most browsers follow a POSTed body with a CRLF. There are two ways of dealing with this: Disallow keepalive in the context of a POST request, or ignore CRLF on a line by itself. Most servers deal with this in the latter way, but there's no way to know how a server will handle it without testing.

 

Java應用

client用apache的commons-httpclient來執行method 。 
用 method.setRequestHeader("Connection" , "Keep-Alive" or "close") 來控制是否保持鏈接。

 

經常使用的apache、resin、tomcat等都有相關的配置是否支持keep-alive。

 

tomcat中能夠設置：maxKeepAliveRequests

 

The maximum number of HTTP requests which can be pipelined until the connection is closed by the server. Setting this attribute to 1 will disable HTTP/1.0 keep-alive, as well asHTTP/1.1 keep-alive and pipelining. Setting this to -1 will allow an unlimited amount of pipelined or keep-alive HTTP requests. If not specified, this attribute is set to 100.

解釋1

所謂長鏈接指創建SOCKET鏈接後無論是否使用都保持鏈接，但安全性較差，   
所謂短鏈接指創建SOCKET鏈接後發送後接收完數據後立刻斷開鏈接，通常銀行都使用短鏈接

 

解釋2

長鏈接就是指在基於tcp的通信中，一直保持鏈接，無論當前是否發送或者接收數據。   
而短鏈接就是隻有在有數據傳輸的時候才進行鏈接，客戶－服務器通訊/傳輸數據完畢就關閉鏈接。

 

解釋3

長鏈接和短鏈接這個概念好像只有移動的CMPP協議中提到了，其餘的地方沒有看到過。   
通訊方式   
各網元之間共有兩種鏈接方式：長鏈接和短鏈接。所謂長鏈接，指在一個TCP鏈接上能夠連續發送多個數據包，在TCP鏈接保持期間，若是沒有數據包發送，須要雙方發檢測包以維持此鏈接。短鏈接是指通訊雙方有數據交互時，就創建一個TCP鏈接，數據發送完成後，則斷開此TCP鏈接，即每次TCP鏈接只完成一對 CMPP消息的發送。   
現階段，要求ISMG之間必須採用長鏈接的通訊方式，建議SP與ISMG之間採用長鏈接的通訊方式。

 

解釋4

短鏈接：好比http的，只是鏈接、請求、關閉，過程時間較短,服務器如果一段時間內沒有收到請求便可關閉鏈接。   
長鏈接：有些服務須要長時間鏈接到服務器，好比CMPP，通常須要本身作在線維持。

最近在看「服務器推送技術」，在B/S結構中，經過某種magic使得客戶端不須要經過輪詢便可以獲得服務端的最新信息（好比股票價格），這樣能夠節省大量的帶寬。

 

     傳統的輪詢技術對服務器的壓力很大，而且形成帶寬的極大浪費。若是改用ajax輪詢，能夠下降帶寬的負荷（由於服務器返回的不是完整頁面），可是對服務器的壓力並不會有明顯的減小。

 

    而推技術（push）能夠改善這種狀況。但由於 HTTP鏈接的特性（短暫，必須由客戶端發起），使得推技術的實現比較困難，常見的作法是經過延長http鏈接的壽命，來實現push。

 

    接下來天然該討論如何延長 http鏈接的壽命，最簡單的天然是死循環法：

 

    【servlet代碼片斷】

     public void doGet(Request req, Response res) {

          PrintWriter out = res.getWriter();

          ……

          正常輸出頁面

          ……

          out.flush();

          while (true) {

                out.print("輸出更新的內容");

                out.flush();

                Thread.sleep(3000);

          }

      }

 

     若是使用觀察者模式則能夠進一步提升性能。

 

     可是這種作法的缺點在於客戶端請求了這個servlet後，web服務器會開啓一個線程執行servlet的代碼，而servlet由遲遲不願結束，形成該線程也沒法被釋放。因而乎，一個客戶端一個線程，當客戶端數量增長時，服務器依然會承受很大的負擔。

 

     要從根本上改變這個現象比較複雜，目前的趨勢是從web服務器內部入手，用 nio（JDK 1.4提出的java.nio包）改寫request/response的實現，再利用線程池加強服務器的資源利用率，從而解決這個問題，目前支持這一非J2EE官方技術的服務器有 Glassfish和 Jetty（後者只是據說，沒有用過）。

 

     目前也有一些框架/工具能夠幫助你實現推功能，好比pushlets。不過沒有深刻研究。

 

     這兩天準備學習一下Glassfish中對Comet（彗星：某人給服務器推送技術起的名字）的支持，呵呵。

 

 

poptest是國內惟一一家培養測試開發工程師的培訓機構，以學員能勝任自動化測試，性能測試，測試工具開發等工做爲目標。若是對課程感興趣，請你們諮詢qq：908821478，諮詢電話010-84505200。

HTTP是一個構建在傳輸層的TCP協議之上的應用層的協議，在這個層的協議，是一種網絡交互須要遵照的一種協議規範。

 

HTTP1.0的短鏈接

HTTP 1.0規定瀏覽器與服務器只保持短暫的鏈接，瀏覽器的每次請求都須要與服務器創建一個TCP鏈接，服務器完成請求處理後當即斷開TCP鏈接，服務器不跟蹤每一個客戶也不記錄過去的請求。這個過程大概能夠描述爲：

一、創建鏈接：首先DNS解析過程。如把域名變成一個ip，若是url不包含端口號，則會使用該協議的默認端口號，HTTP協議的默認端口號爲80。而後三次握手創建一個TCP鏈接；

二、請求：鏈接成功後，開始向web服務器發送請求，這個請求通常是GET或POST請求。

三、應答：web服務器收到這個請求，進行處理。web服務器會把文件內容傳送給響應的web瀏覽器。包括：HTTP頭信息，體信息。

四、關閉鏈接：當應答結束後，web瀏覽器與web服務器必須四次握手斷開鏈接，以保證其它web瀏覽器可以與web服務器創建鏈接。

 

HTTP1.1的長鏈接

可是HTTP1.1開始默認創建的是長鏈接，即一旦瀏覽器發起HTTP請求，創建的鏈接不會請求應答以後馬上斷掉。

 

一、 一個複雜的具有不少HTTP資源的網頁會創建多少TCP鏈接，如何使用這些鏈接？

二、 已經創建的TCP鏈接是否會自動斷開，時間是多久？

 

對於第一個問題。如今瀏覽器都有最大併發鏈接數限制，應該說若是須要，就會盡可能在容許範圍內創建更多的TCP持久鏈接來處理HTTP請求，一樣滴，一個TCP持久鏈接能夠不斷傳輸多個HTTP請求，可是若是上一個請求的響應還未收到，則不能處理下一個請求(Pipeling管道技術能夠解決這個問題從而進一步提高性能)，因此說不少瀏覽器其實均可以修改容許最大併發鏈接數以提高瀏覽網頁的速度。

 

對於第二個問題。問題在於服務器端對於長鏈接的實現，特別是在對長鏈接的維護上。FTP協議及SMTP協議中有NOOP消息，這個就能夠認爲是心跳報文，但HTTP協議沒有相似的消息，這樣服務器端只能使用超時斷開的策略來維護鏈接。設想超時時間很是短，那麼有效空閒時間就很是短，換句話講：一旦鏈路上沒有數據發送，服務器端很快就關閉鏈接。

也就是說其實HTTP的長鏈接很容易在空閒後自動斷開，通常來講這個時間是300s左右。 

 

參考：HTTP/1.0和HTTP/1.1的區別，HTTP怎麼處理長鏈接

參考：HTTP實現長鏈接（TTP1.1和HTTP1.0相比較而言，最大的區別就是增長了持久鏈接支持Connection: keep-alive）

參考：老李談HTTP1.1的長鏈接

參考：HTTP1.0 HTTP 1.1 HTTP 2.0主要區別

參考：HTTP1.0和HTTP1.1的區別

參考：HTTP 1.1與HTTP 1.0的比較