關于HTTP1.1的長連接配接

http是一個建構在傳輸層的tcp協定之上的應用層的協定，在這個層的協定，是一種網絡互動須要遵守的一種協定規範。

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開始預設建立的是長連接配接，即一旦浏覽器發起http請求，建立的連接配接不會請求應答之後立馬斷掉。

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

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

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

對于第二個問題。

問題在于server端對于長連接配接的實作，特别是在對長連接配接的維護上。

ftp協定及smtp協定中有noop消息，這個就能夠覺得是心跳封包。但http協定沒有相似的消息，這樣server端僅僅能使用逾時斷開的政策來維護連接配接。

設想逾時時間非常短。那麼有效空暇時間就非常短。換句話講：一旦鍊路上沒有資料發送，server端非常快就關閉連接配接。

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

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

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

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

持久連接配接 （keep-alive/persistent connection）

并行連接配接

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的受支援的協定版本号。

<>

<col>

版本号

http 1.0 server（寬帶連接配接）

http 1.1 server（寬帶連接配接）

http 1.0 server（撥接上網）

http 1.1 server（撥接上網）

internet explorer 7 和早期版本号

4

2

internet explorer 8

6

internet explorer 9

10

?

internet explorer 10

internet explorer 11

chrome、firefox

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，這将有助于提升打開站點的速度。