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

HTTP1.0的短連接

HTTP 1.0規定瀏覽器與server僅僅保持短暫的連接。瀏覽器的每次請求都須要與server建立一個TCP連接，server完畢請求處理後馬上斷開TCP連接，server不跟蹤每一個客戶也不記錄過去的請求。這個過程大概能夠描寫敘述為：

1、建立連接：首先DNS解析過程。如把域名變成一個ip。假設url不包括port號，則會使用該協議的默認port號，HTTP協議的默認port號為80。然後三次握手建立一個TCP連接；

2、請求：連接成功後，開始向webserver發送請求。這個請求通常是GET或POST請求。

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

4、關閉連接：當應答結束後，web瀏覽器與webserver必須四次握手斷開連接，以保證其它web瀏覽器能夠與webserver建立連接。

HTTP1.1的長連接

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

1、 一個復雜的具備非常多HTTP資源的網頁會建立多少TCP連接，怎樣使用這些連接？

2、 已經建立的TCP連接是否會自己主動斷開。時間是多久？

對於第一個問題。如今瀏覽器都有最大並發連接數限制。應該說假設須要，就會盡量在同意範圍內建立很多其它的TCP持久連接來處理HTTP請求，相同滴。一個TCP持久連接能夠不斷傳輸多個HTTP請求。可是假設上一個請求的響應還未收到，則不能處理下一個請求(Pipeling管道技術能夠解決問題從而進一步提升性能)，所以說非常多瀏覽器事實上都能夠改動同意最大並發連接數以提升瀏覽網頁的速度。

對於第二個問題。

問題在於server端對於長連接的實現，特別是在對長連接的維護上。

FTP協議及SMTP協議中有NOOP消息，這個就能夠覺得是心跳報文。但HTTP協議沒有相似的消息，這樣server端僅僅能使用超時斷開的策略來維護連接。

設想超時時間非常短。那麽有效空暇時間就非常短。換句話講：一旦鏈路上沒有數據發送，server端非常快就關閉連接。

也就是說事實上HTTP的長連接非常easy在空暇後自己主動斷開，一般來說這個時間是300s左右。

參考資料

=====================================================================

1、HTTP1.1提升性能的手段

著作權歸作者全部。

商業轉載請聯系作者獲得授權。非商業轉載請註明出處。
作者：Saviio
鏈接：http://www.zhihu.com/question/36469741/answer/67608570
來源：知乎

HTTP1.1裏大概規範了幾項提高性能的手段：

1. 持久連接 （keep-alive/persistent connection）
2. 並行連接
3. Pipelining

第一點之前已經說過了，所以不表。

第二點。由於現代網頁通常包括了復數個（>=10）資源，而依照默認設定，一個連接中的每一個請求必須等待收到響應後才幹發送下一個請求，所以假設復數的資源請求全部在一個連接one by one發送給server顯然會非常慢，而為了彌補這一缺陷，瀏覽器一般會默認開啟多個TCP連接，然後再依據每一個連接的狀態在當中依次發送數據請求，並且client有權隨意關閉超發的連接。各個瀏覽器同意的並行連接數大致是這樣的（From SO）：

Firefox 2: 2

Firefox 3+: 6

Opera 9.26: 4

Opera 12: 6

Safari 3: 4

Safari 5: 6

IE 7: 2

IE 8: 6

IE 10: 8

Chrome: 6

由於TCP協議本身有慢啟動的特征，會隨著時間調諧連接的最大速度，因此在現代瀏覽器中持久連接和並行連接通常是搭配在一起使用的—— 一方面由於持久連接的存在。每一個TCP連接已經處於調諧後的狀態。還有一方面持久連接能夠避免又一次三次握手的開銷。

關於第三點，
依照HTTP1.1的描寫敘述。還有種能夠提升性能的方案是管道化。能夠在一個連接中發送多個請求不必等待前一個請求返回。

但這項技術比較easy踩坑，所以主流面向用戶的瀏覽器，這項技術是被默認關閉。

關於HTTP2：
HTTP2為了性能做了不少努力，比方提供了規範以支持連接的多路復用。

HTTP1.0須要加上keep-alive的請求首部。否則默認一個請求一個連接。

HTTP1.1之後keep-alive（持久連接）被默認啟用，除非在響應中指定connection：close，否則webserver會假定全部連接都是持久的。

=====================================================================

葛佳祥。程序猿/PHPer/開源愛好者

石建文、小小的寂寞、知乎用戶 等人贊同

@Saviio沒有正面回答這個問題。只是關於HTTP中的持久連接理解得不錯。

關於樓主的問題：假設第一個請求完畢後，再開始發送的第二個請求。就是1個tcp連接。假設是兩個請求同一時候開始，或者第一個請求還未結束就開始第二個請求，就是兩個tcp連接。

由於HTTP協議是同步的沒有多路復用支持。一個管道同一時候僅僅能做一件事。

只是幸好現代計算機已經全然不用在乎幾個tcp連接了，協議簡單事實上挺好的。

=============================================================

2、關於火狐中HTTP參數的設置：
about:config network.http.* 的相關參數
network.http.keep-alive 默認是 true 是否同意持久連接。這個默認就是 true，改成 false 的是大傻瓜。
network.http.keep-alive.timeout 默認是 300 持久連接同意的保持時間，這個調大了沒意義，由於一般 server 設置的就是 300。

server 把你哢嚓了你還能有什麽辦法。
network.http.max-connections-per-server 默認是 8 連接同一個server同意的最大連接數。一般覺得在開啟持久連接的情況下把這個數值調大沒什麽作用，並且不太道德。須要調大的情況比方：你同一時候從站點下 10 個大文件。
network.http.max-persistent-connections-per-server默認是 2 連接同一個server同意的最大持久連接數，這個數值 HTTP/1.1 標準推薦的是 2。調大了反而添加你自己的網絡消耗。並且一般一個server同意的持久連接數是有限的，你調大了就可能造成別人可用的降低，假設大家都調大，就意味著網絡效 率的喪失。我個人建議不要動這個數值。

network.http.pipelining 默認是 false 是否同意 pipelining，這個功能由於眼下還是試驗階段，所以默認沒有打開。

強烈建議打開。
network.http.pipelining.maxrequests 默認是 4 每一個持久連接同意一次發送的請求數。假設 pipeline 裏面有一個大圖片或者執行時間較長的腳本，後面已經發送的請求就會被堵塞（註意server必須是依次回應請求）；而在這樣的情況下。假設沒有使用 pipelining，瀏覽器發現一個請求處理時間非常長。自然會使用還有一條持久連接用作興許請求，甚至進一步開啟非持久連接。

另外，假設server支持 pipelining 不好而過早的關閉連接，瀏覽器勢必要又一次發送請求。基於這樣的種原因。有人覺得這個數字設置得比 2 大反而會降低瀏覽速度。我個人的推薦是，這個數值普通情況能夠保持默認值 4。假設瀏覽的站點有大量的靜態小圖片。或者網絡速度較慢。能夠嘗試將其調大。
network.http.max-persistent-connections-per-proxy 默認是 4 每一個代理server同意的最大持久連接數。

4 是眼下比較公認的最合適的數值。雖然HTTP/1.1 的推薦值是 2。

network.http.proxy.keep-alive 默認是 true 連接代理server是否同意持久連接。true 挺好的。

network.http.proxy.pipelining 默認是 false 連接代理server是否同意 pipelining。眼下普遍覺得大多數代理server支持 pipelining 並不好。所以一般不建議打開。
pipelining 眼下是一個有爭議的。仍舊在實驗階段的特性。

雖然它可能確實會加快瀏覽速度，可是這在一定程度上取決於網絡的各項因素，所以不要盲目的依照網上建議的方式設置相關的參數。

============================================================

3、具體解釋瀏覽器最大並發連接數

當我們在瀏覽網頁的時候，對瀏覽速度有一個重要的影響因素，就是瀏覽器的並發數量。並發數量簡單通俗的講就是，當瀏覽器網頁的時候同一時候工作的進行數量。

假設同一時候僅僅有2個並發連接數數量，那網頁打開的時候僅僅能依賴於這2條線程，前面假設有打開慢的內容，就會直接影響到後面的內容打開。可是假設同一時候有很多其它的並發連接數。這樣就會大大的提高網頁載入速度。詳情可查看我們之前公布的文章：並發連接數對瀏覽器載入速度的測試。

瀏覽器的並發連接數也並不是越大越好。

下表概括了基於主機上執行的IE瀏覽器的版本號的最大並發連接數、主機的連接速度和server的受支持的協議版本號。

<>

InternetExplorer 8+ 提供了一個 window. maxConnectionsPerServer 對象，server能夠利用此對象來確定client計算機上的可用連接數。

在 Internet Explorer 8+ 中。maxConnectionsPerServer對於寬帶連接將返回 6。除非用戶或管理員已重寫此默認值。在client計算機通過撥號連接時，假設連接到 HTTP 1.1 server，則 maxConnectionsPerServer 將返回 2；假設連接到 HTTP 1.0 server，則 maxConnectionsPerServer 將返回 4。

非常多人都說是：

實際情況（china）：

非常多client軟件能夠改動電腦的最大連接數。比方：迅雷、暴風影音等。

之前我們曾跟大家分享過怎樣改動IE瀏覽器的並發連接數，假設你正在使用IE7及下面的更低版本號，最好還是嘗試將連接數改動到6，這將有助於提升打開站點的速度。

關於HTTP1.1的長連接