瀏覽器同域名請求的最大併發數限制

時間 2019-11-12

原文原文鏈接

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

若是同時只有2個併發鏈接數數量，那網頁打開的時候只能依賴於這2條線程，前面若是有打開慢的內容，就會直接影響到後面的內容打開。可是若是同時有更多的併發鏈接數，這樣就會大大的提升網頁加載速度。詳情可查看咱們以前發佈的文章：併發鏈接數對瀏覽器加載速度的測試。瀏覽器的併發鏈接數也並不是越大越好。html

下表歸納了基於主機上運行的IE瀏覽器的版本的最大併發鏈接數、主機的鏈接速度和服務器的受支持的協議版本。java

1，HTTP客戶端通常對同一個服務器的併發鏈接個數都是有限制的。node

實際上，瀏覽器確實使用並行鏈接，但它們將並行鏈接的總數限制爲少許（一般爲四個）。服務器能夠自由地關閉來自特定客戶端的過多鏈接。web

2，一些主流瀏覽器對HTTP 1.1和HTTP 1.0的最大併發鏈接數目，能夠參考以下表格：ajax

瀏覽器chrome	HTTP / 1.1數據庫	HTTP / 1.0編程
IE 11json	6	6
IE 10	6	6
IE 9	10	10
IE 8	6	6
IE 6,7	2	4
火狐	6	6
Safari 3,4	4	4
Chrome 4+	6	6
歌劇9.63,10.00alpha	4	4
Opera 10.51+	8	？

iPhone 2	4	？
iPhone 3	6	？
iPhone 4	4	？
iphone 5	6	？

Android2-4	4	？

3，Firefox 瀏覽器的最大併發鏈接數

在Firefox中的地址欄輸入「about：config中」，而後搜索並修改以下兩個配置項目便可：

network.http.max持久的鏈接 - 每一個服務器

network.http.max持久的鏈接 - 每一個代理

網絡。HTTP。最大的鏈接：設置的Http同時鏈接的最大數量

network.http.max持久的鏈接，每臺服務器是鏈接同一個服務器容許的最大持久鏈接數，默認爲6，能夠不用更改。

network.http.max持久的鏈接 - 每一個代理每一個代理服務器容許的最大持久鏈接數

公司用戶使用代理服務器，可是外面的客戶通常不使用代理，火狐的維基推薦的network.http.max持久的鏈接，每臺服務器設置爲：<= 10。

4，IE 瀏覽器的最大併發鏈接數

用「註冊表編輯器」命令打開註冊表編輯器，找到：

[HKEY_CURRRENT_USER \ Software \ Microsoft \ Windows \ CurrentVersion \ Internet Settings]，能夠看到MaxConnectionsPerServer和MaxConnectionsPer1_0Server

這兩個鍵（分別是針對HTTP 1.1和HTTP 1.0的設置）

對於IE 9

[HKEY_CURRRENT_USER \ Software \ Policies \ Microsoft \ Internet Exploer \ Main \ FeatureControl，能夠看到FEATURE_MAXCONNECTIONSPER1_0SERVER和FEATURE_MAXCONNECTIONSPERSERVER

這兩個鍵（分別是針對HTTP 1.1和HTTP 1.0的設置）

************************************************** **************************

5，假定一個瀏覽器的併發鏈接請求數爲10，一般同一時間內會有多個用戶併發訪問網站。又考慮到，一個Http鏈接請求在同一時間只能被一個線程訪問。

因此，IHS服務器的httpd.conf裏的maxclients（容許創建的總線程數）要可以處理峯值時刻的瀏覽器鏈接請求才行。

同時，考慮不是全部的鏈接請求都會到was server，有的鏈接只是爲了在web服務器上取靜態資源，因此，was上的線程池數目（Thread pools ：50 ）會遠小於IHS server上的maxclients值譬如400）。

************************************************** *****************************

6，HTTP 鏈接請求與線程

HTTP鏈接是複雜，有狀態的對象，因此它必須被妥善管理。一個HTTP 鏈接請求在同一時間只能被一個線程訪問。

HttpClient的使用一個叫作的Http鏈接管理器的特殊實體類來管理的Http鏈接.Http鏈接管理器在新建的HTTP鏈接時，做爲工廠類;管理持久的http鏈接的生命週期;同步持久鏈接（確保線程安全，即一個HTTP鏈接同一時間只能被一個線程訪問）。

若是一個的Http鏈接被釋放或者被它的消費者明確表示要關閉，那麼底層的鏈接就會和它的代理進行分離，而且該鏈接會被交還給鏈接管理器。這是，即便服務消費者仍然持有代理的引用，它也不能再執行I / O操做，或者更改的Http鏈接的狀態。

如圖7所示，鏈接池管理器

鏈接池管理器是個複雜的類，它管理着鏈接池，能夠同時爲不少線程提供HTTP鏈接請求。當請求一個新的鏈接時，若是鏈接池有有可用的持久鏈接，鏈接管理器就會使用其中的一個，而不是再建立一個新的鏈接。

當使用了請求鏈接池管理器後，HttpClient的就能夠同時執行多個線程的請求了。

鏈接池管理器會根據它的配置來分配請求鏈接。若是鏈接池中的全部鏈接都被佔用了，那麼後續的請求就會被阻塞，直到有鏈接被釋放回鏈接池中。

8，線程池的原理：

線程池的原理很簡單，相似於操做系統中的緩衝區的概念，它的流程以下：

線程池在尚未任務到來以前，建立必定數量的線程，放入空閒隊列中。這些線程都是處於睡眠狀態，即均爲啓動，不消耗CPU，而只是佔用較小的內存空間。當客戶端有一個新請求時，就會喚醒線程池中的某一個睡眠線程，讓它來處理客戶端的這個請求，當處理完這個請求後，線程又處於睡眠狀態。

線程池能節約大量的的系統資源，使得更多的CPU時間和內存用來處理實際的商業應用，而不是頻繁的線程建立與銷燬

每一個線程須要大約1MB內存，線程開的越多，消耗的內存也就越大。

在什麼狀況下使用線程池：
1.單個任務處理的時間比較短
2.將需處理的任務的數量大

9，數據庫鏈接池：

數據庫鏈接池的解決方案是在應用程序啓動時創建足夠的數據庫鏈接，並講這些鏈接組成一個鏈接池（簡單說：在一個「池」裏放了好多半成品的數據庫聯接對象），由應用程序動態地對池中的鏈接進行申請，使用和釋放。對於多於鏈接池中鏈接數的併發請求，應該在請求隊列中排隊等待。而且應用程序能夠根據池中鏈接的使用率，動態增長或減小池中的鏈接數。
鏈接池技術儘量多地重用了消耗內存地資源，大大節省了內存，提升了服務器地服務效率，可以支持更多的客戶服務。經過使用鏈接池，將大大提升程序運行效率，同時，咱們能夠經過其自身的管理機制來監視數據庫鏈接的數量，使用狀況等。

1）最小鏈接數是鏈接池一直保持的數據庫鏈接，因此若是應用程序對數據庫鏈接的使用量不大，將會有大量的數據庫鏈接資源被浪費;
2）最大鏈接數是鏈接池能申請的最大鏈接數，若是數據庫鏈接請求超過此數，後面的數據庫鏈接請求將被加入到等待隊列中，這會影響以後的數據庫操做。

數據庫鏈接是一種關鍵的有限的昂貴的資源，這一點在多用戶的網頁應用程序中體現得尤其突出。一個數據庫鏈接對象均對應一個物理數據庫鏈接，每次操做都打開一個物理鏈接，使用完都關閉鏈接，這樣形成系統的性能低下。

10，WebSphere Application Server性能

http://websphere.sys-con.com/node/46514/print

構建服務器應用程序的一個過於簡單的模型是：每當一個請求到達就建立一個新的服務對象，而後在新的服務對象中爲請求服務但當有大量請求併發訪問時，服務器不斷的建立和銷燬對象的開銷很大。

在面向對象的編程中，建立和銷燬對象是很浪費資源的，由於建立一個對象要獲取內存資源或者其它更多資源。在Java的中更是如此，虛擬機試圖跟蹤每個對象，以便可以在對象銷燬後進行垃圾回收。因此，提升程序效率的一個手段就是儘量減小建立和銷燬對象的次數。利用已有的對象來服務就是「池化資源」技術產生的緣由。

圖1顯示了一個須要後端處理的應用程序請求流程，並說明了在處理用戶請求時線程池之間的關係。

HTTP偵聽器
HTTP偵聽器負責在HTTP服務器級別建立線程。這裏發生的大多數處理是靜態頁面服務，或HTTP post / GET傳遞命令到後端。這是必須考慮的第一級線程配置。

Web容器
Web容器負責在應用程序服務器級別建立線程池。此級別的大多數處理包括servlet，JSP，EJB，動態頁面建立和後端傳遞處理。Web容器是必須配置的第二級線程池配置。

ORB容器 ORB容器負責在對象級建立線程池。這裏發生的大部分處理包括處理基於非Web的客戶端。ORB容器是必須配置的線程池配置的第三級。

數據源
數據源級負責建立從數據庫或「傳統」系統訪問的鏈接線程。這些線程是必須解決的第四級配置

實際狀況（china）：

不少客戶端軟件能夠修改電腦的最大鏈接數，好比：迅雷、暴風影音等。

以前咱們曾跟你們分享過如何修改IE瀏覽器的併發鏈接數，若是你正在使用IE7及如下的更低版本，不妨嘗試將鏈接數修改到6，這將有助於提高打開網站的速度。

舉個例子：

IE8

和IE6徹底不一樣的瀑布圖，其特色有：

最大併發HTTP鏈接數爲6個。
javascript文件已經不會阻塞其餘資源的加載，甚至多個javascript文件能夠一塊兒加載，而且會保證執行的順序。
會分析HTML結構，優先下載script和link標籤訂義的外部資源。

Firefox3.6

和IE8的幾乎徹底同樣：

最大併發HTTP鏈接數爲6個（可在about:config中修改）。
javascript文件不會阻塞其餘資源的加載，多個javascript文件能夠一塊兒加載。
會分析HTML結構，優先下載script和link標籤訂義的外部資源。

Firefox4 beta12

不知是由於設計理念上的不一樣，仍是由於beta版未照顧到這一塊，Firefox4反而退化了，和Firefox3.6的區別主要體如今對資源類型的處理上，Firefox4再也不嚴格地優先下載script和link標籤訂義的外部資源，而是按照HTML結構中出現的順序來進行加載。

Chrome8

Chrome自帶的工具不能很清楚地表示各請求的開始時間，因此使用了Fiddler的瀑布圖，從圖上能夠看出，Chrome也是比較特立獨行的一位，其特色有：

最大併發HTTP鏈接數爲6。
head部分的資源會單獨下載，且阻塞body中的其餘資源的加載。
會優先加載script和link標籤訂義的資源。

Opera11

先報怨一下，Dragonfly不怎麼好用來着……Opera的資源加載也比較有特點，並且很難看出規律，只能大體總結一下：

Opera的最大併發HTTP鏈接數默認爲16，可在opera:config - Performance - Max Connections Server查看和修改。
javascript文件的加載會阻塞其餘script和link標籤訂義的外部資源的加載，如圖中的2.js。但不會阻塞圖片等其餘資源的加載，如圖中的3.js。
會必定程度上對資源的優先級進行優化，但因爲javascript文件要阻止後續部分資源的加載，又爲了充分利用最大HTTP鏈接數，所以不能嚴格先加載全部的script和link標籤訂義的資源，致使瀑布圖上各種型資源有相互穿插，難尋規律。

這仍是在比較樂觀的狀況下，有幾秒加載完畢的，按道理來講，圖片都不大，應該都在1秒範圍內就纔是在接收範圍內。固然和用戶自身的帶寬也有關係，可是從個人觀察來看，是分批加載的。

因而乎我查看資料，發現。

從Yahoo關於網站優化的經典14條建議，在V2版中，已經更新到35條了，其中有須要減小請求鏈接數和減小DNS解析次數，因爲在http協議中有對瀏覽器併發請求鏈接數的限制，1.1版本中規定了是2個（相關資料能夠查看文章的結尾），因而一般的優化網站加載速度的方法是採用多個域名增長瀏覽器對同一網頁的請求併發鏈接數。