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還支持傳送內容的一部分。這樣當客戶端已經有一部分的資源后，只需要跟服務器請求另外的部分資源即可。這是支持文件斷點續傳的基礎。
現在可以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使得客戶端不需要通過輪詢即可以得到服務端的最新信息（比如股票價格），這樣可以節省大量的帶寬。
poptest是國內唯一一家培養測試開發工程師的培訓機構，以學員能勝任自動化測試，性能測試，測試工具開發等工作為目標。如果對課程感興趣，請大家咨詢qq：908821478，咨詢電話010-84505200。
HTTP是一個構建在傳輸層的TCP協議之上的應用層的協議，在這個層的協議，是一種網絡交互需要遵守的一種協議規范。
HTTP1.0的短連接
HTTP 1.0規定瀏覽器與服務器只保持短暫的連接，瀏覽器的每次請求都需要與服務器建立一個TCP連接，服務器完成請求處理后立即斷開TCP連接，服務器不跟蹤每個客戶也不記錄過去的請求。這個過程大概可以描述為：
1、建立連接：首先DNS解析過程。如把域名變成一個ip，如果url不包含端口號，則會使用該協議的默認端口號，HTTP協議的默認端口號為80。然后三次握手建立一個TCP連接；
2、請求：連接成功后，開始向web服務器發送請求，這個請求一般是GET或POST請求。
3、應答：web服務器收到這個請求，進行處理。web服務器會把文件內容傳送給響應的web瀏覽器。包括：HTTP頭信息，體信息。
4、關閉連接：當應答結束后，web瀏覽器與web服務器必須四次握手斷開連接，以保證其它web瀏覽器能夠與web服務器建立連接。
HTTP1.1的長連接
但是HTTP1.1開始默認建立的是長連接，即一旦瀏覽器發起HTTP請求，建立的連接不會請求應答之后立刻斷掉。
1、 一個復雜的具備很多HTTP資源的網頁會建立多少TCP連接，如何使用這些連接？
2、 已經建立的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）