1. 背景情況
突然想起來很久以前聽部門一位同事說過，Http協議適用于廣域網，而TCP協議就不適用于廣域網，因為Http協議是短連接，而TCP協議是長連接，開銷比較大!
其實仔細分析就知道這種說話不成立。Http協議本身就是基于TCP協議的，發起一次Http請求之前客戶端需要同服務端通過三次握手建立TCP連接。
以下幾段內容摘自網絡，最后給出自己總結的結論。
2. 長連接與短連接
長連接與短連接的操作過程：
短連接的操作步驟是：建立連接——數據傳輸——關閉連接...建立連接——數據傳輸——關閉連接;
長連接的操作步驟是：建立連接——數據傳輸...(保持連接)...數據傳輸——關閉連接
長連接與短連接的使用時機：
長連接多用于操作頻繁，點對點的通訊，而且連接數不能太多的情況。每個TCP連接的建立都需要三次握手，每個TCP連接的斷開要四次握手。如果每次操作都要建立連接然后再操作的話處理速度會降低，所以每次操作下次操作時直接發送數據就可以了，不用再建立TCP連接。例如：數據庫的連接用長連接，如果用短連接頻繁的通信會造成socket錯誤，頻繁的socket創建也是對資源的浪費。
短連接：web網站的http服務一般都用短連接。因為長連接對于服務器來說要耗費一定的資源。像web網站這么頻繁的成千上萬甚至上億客戶端的連接用短連接更省一些資源。試想如果都用長連接，而且同時用成千上萬的用戶，每個用戶都占有一個連接的話，可想而知服務器的壓力有多大。所以并發量大，但是每個用戶又不需頻繁操作的情況下需要短連接。
總之：長連接和短連接的選擇要視需求而定。
3. HTTP 1.1與HTTP 1.0的比較
一個WEB站點每天可能要接收到上百萬的用戶請求，為了提高系統的效率，HTTP 1.0規定瀏覽器與服務器只保持短暫的連接，瀏覽器的每次請求都需要與服務器建立一個TCP連接，服務器完成請求處理后立即斷開TCP連接，服務器不跟蹤每個客戶也不記錄過去的請求。但是，這也造成了一些性能上的缺陷，例如，一個包含有許多圖像的網頁文件中并沒有包含真正的圖像數據內容，而只是指明了這些圖像的URL地址，當WEB瀏覽器訪問這個網頁文件時，瀏覽器首先要發出針對該網頁文件的請求，當瀏覽器解析WEB服務器返回的該網頁文檔中的HTML內容時，發現其中的圖像標簽后，瀏覽器將根據標簽中的src屬性所指定的URL地址再次向服務器發出下載圖像數據的請求，如圖3.3所示。
圖3.3
顯 然，訪問一個包含有許多圖像的網頁文件的整個過程包含了多次請求和響應，每次請求和響應都需要建立一個單獨的連接，每次連接只是傳輸一個文檔和圖像，上一次和下一次請求完全分離。即使圖像文件都很小，但是客戶端和服務器端每次建立和關閉連接卻是一個相對比較費時的過程，并且會嚴重影響客戶機和服務器的性能。當一個網頁文件中包含Applet，JavaScript文件，CSS文件等內容時，也會出現類似上述的情況。
為了克服HTTP 1.0的這個缺陷，HTTP 1.1支持持久連接，在一個TCP連接上可以傳送多個HTTP請求和響應，減少了建立和關閉連接的消耗和延遲。一個包含有許多圖像的網頁文件的多個請求和應答可以在一個連接中傳輸，但每個單獨的網頁文件的請求和應答仍然需要使用各自的連接。HTTP 1.1還允許客戶端不用等待上一次請求結果返回，就可以發出下一次請求，但服務器端必須按照接收到客戶端請求的先后順序依次回送響應結果，以保證客戶端能夠區分出每次請求的響應內容，這樣也顯著地減少了整個下載過程所需要的時間。基于HTTP 1.1協議的客戶機與服務器的信息交換過程，如圖3.4所示。
圖3.4
可見，HTTP 1.1在繼承了HTTP 1.0優點的基礎上，也克服了HTTP 1.0的性能問題。不僅如此，HTTP 1.1還通過增加更多的請求頭和響應頭來改進和擴充HTTP 1.0的功能。例如，由于HTTP1.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緩存等機制相關的請求頭和響應頭。
HTTP 協議老的標準是HTTP/1.0，目前最通用的標準是HTTP/1.1。HTTP/1.1是在HTTP/1.0基礎上的升級，增加了一些功能，全面兼容 HTTP/1.0。HTTP/1.0不支持文件斷點續傳，目前的Web服務器絕大多數都采用了HTTP/1.1。
RANGE:bytes是HTTP/1.1新增內容，HTTP/1.0每次傳送文件都是從文件頭開始，即0字節處開始。RANGE:bytes=XXXX表示要求服務器從文件XXXX字節處開始傳送，這就是我們平時所說的斷點續傳!
4. HTTP 1.1長連接與HTTP 1.0短連接
1. 背景
KeepAlive是就是通常所稱的長連接。KeepAlive帶來的好處是可以減少tcp連接的開銷，這對于短response body的請求效果更加明顯。同時，可以為采用HTTP協議的交互式應用提供良好的session支持。
2. KeepAlive的原理
在HTTP1.0和HTTP1.1協議中都有對KeepAlive的支持。其中HTTP1.0需要在request中增加”Connection： keep-alive“ header才能夠支持，而HTTP1.1默認支持。
HTTP1.0 KeepAlive支持的數據交互流程如下：
a)Client發出request，其中該request的HTTP版本號為1.0。同時在request中包含一個header：”Connection：keep-alive“。
b)Web Server收到request中的HTTP協議為1.0及”Connection：keep-alive“就認為是一個長連接請求，其將在response的header中也增加”Connection： keep-alive“。同時不會關閉已建立的tcp連接。
c)Client收到Web Server的response中包含”Connection： keep-alive“，就認為是一個長連接，不close tcp連接。并用該tcp連接再發送request。(跳轉到a))
HTTP1.1 KeepAlive支持的數據交互流程如下：
a)Client發出request，其中該request的HTTP版本號為1.1。
b)Web Server收到request中的HTTP協議為1.1就認為是一個長連接請求，其將在response的header中也增加”Connection： keep-alive“。同是不會關閉已建立的tcp連接。
c)Client收到Web Server的response中包含”Connection： keep-alive“，就認為是一個長連接，不close tcp連接。并用該tcp連接再發送request。(跳轉到a))
5. 總結
由此可以推斷“TCP或者說長連接不適用于廣域網”的說法不成立。
京公網安備 11010502049343號