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

 

如果同時只有2個併發連線數數量，那網頁開啟的時候只能依賴於這2條執行緒，前面如果有開啟慢的內容，就會直接影響到後面的內容開啟。但是如果同時有更多的併發連線數，這樣就會大大的提高網頁載入速度。詳情可檢視我們之前釋出的文章：併發連線數對瀏覽器載入速度的測試。瀏覽器的併發連線數也並非越大越好。

 

下表概括了基於主機上執行的IE瀏覽器的版本的最大併發連線數、主機的連線速度和伺服器的受支援的協議版本。

  

1，HTTP客戶端一般對同一個伺服器的併發連線個數都是有限制的。

實際上，瀏覽器確實使用並行連線，但它們將並行連線的總數限制為少量（通常為四個）。伺服器可以自由地關閉來自特定客戶端的過多連線。

2，一些主流瀏覽器對HTTP 1.1和HTTP 1.0的最大併發連線數目，可以參考如下表格：

瀏覽器	HTTP / 1.1	HTTP / 1.0
IE 11	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個（相關資料可以檢視文章的結尾），於是通常的優化網站載入速度的方法是採用多個域名增加瀏覽器對同一網頁的請求併發連線數。

二、下面我來看看各大電商是怎麼處理的。

1.京東（www.jd.com）

    京東圖片域名一直是老域名360buyimg.com。

    http://img13.360buyimg.com/da/jfs/t1879/131/2924301202/126044/7c7cbf5c/56f3b58fN37c1340a.jpg

    比如說這張圖片，你可以複製開啟這個連結，把前面的二級域名的Img13換成img11、img12、img13等，發現都是可以開啟的，而且一般是同一IP，有的同學說換成img8、img1、img2等打不開，這個是策略問題。這只是舉個栗子。

2.天貓（www.tmall.com）

    圖片CDN域名有很多，tbcdn.cn、alicdn.com 等

    也是同理，不過最近HTTPS轉變後都換成img.alicdn.com了。原因不明。

三、說一下Firefox瀏覽器

在Firefox位址列中輸入：about:config

在搜尋項輸入：network.http.max-connections

老版本值是30，我這個版本是256，說明有改進。

我們再輸入：network.http.max-persistent-connections-per-server進行搜尋，發現是6。

你可以寫個Demo測試一下，寫個小迴圈，然後訪問同一個域名（推薦用 Ajax  方式），然後後臺sleep一會，你就能看出效果。之前有人做過低版本的測試，得出結論。

IE8的併發連線數限制為10；

Firefox    和 chrome  的併發連線數都為6，可能各個版本有區別。作為一個站長，或者說一個完善的產品，這個是不得不考慮的。

解決方案：

1.給定一組域名，如：img1.baidu.com、img2.baidu.com、img3.baidu.com、img4.baidu.com... ... 

2.這組域名指向同一個源，或者說最終源是一個。

3.上傳圖片（靜態檔案）的時候隨機返回這組域名中的其中一個即可，這樣圖片的訪問域名就不會出現只是一個域名了。

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

 

如果同時只有2個併發連線數數量，那網頁開啟的時候只能依賴於這2條執行緒，前面如果有開啟慢的內容，就會直接影響到後面的內容開啟。但是如果同時有更多的併發連線數，這樣就會大大的提高網頁載入速度。詳情可檢視我們之前釋出的文章：併發連線數對瀏覽器載入速度的測試。瀏覽器的併發連線數也並非越大越好。

 

下表概括了基於主機上執行的IE瀏覽器的版本的最大併發連線數、主機的連線速度和伺服器的受支援的協議版本。

  

1，HTTP客戶端一般對同一個伺服器的併發連線個數都是有限制的。

實際上，瀏覽器確實使用並行連線，但它們將並行連線的總數限制為少量（通常為四個）。伺服器可以自由地關閉來自特定客戶端的過多連線。

2，一些主流瀏覽器對HTTP 1.1和HTTP 1.0的最大併發連線數目，可以參考如下表格：

瀏覽器	HTTP / 1.1	HTTP / 1.0
IE 11	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個（相關資料可以檢視文章的結尾），於是通常的優化網站載入速度的方法是採用多個域名增加瀏覽器對同一網頁的請求併發連線數。

二、下面我來看看各大電商是怎麼處理的。

1.京東（www.jd.com）

    京東圖片域名一直是老域名360buyimg.com。

    http://img13.360buyimg.com/da/jfs/t1879/131/2924301202/126044/7c7cbf5c/56f3b58fN37c1340a.jpg

    比如說這張圖片，你可以複製開啟這個連結，把前面的二級域名的Img13換成img11、img12、img13等，發現都是可以開啟的，而且一般是同一IP，有的同學說換成img8、img1、img2等打不開，這個是策略問題。這只是舉個栗子。

2.天貓（www.tmall.com）

    圖片CDN域名有很多，tbcdn.cn、alicdn.com 等

    也是同理，不過最近HTTPS轉變後都換成img.alicdn.com了。原因不明。

三、說一下Firefox瀏覽器

在Firefox位址列中輸入：about:config

在搜尋項輸入：network.http.max-connections

老版本值是30，我這個版本是256，說明有改進。

我們再輸入：network.http.max-persistent-connections-per-server進行搜尋，發現是6。

你可以寫個Demo測試一下，寫個小迴圈，然後訪問同一個域名（推薦用 Ajax  方式），然後後臺sleep一會，你就能看出效果。之前有人做過低版本的測試，得出結論。

IE8的併發連線數限制為10；

Firefox    和 chrome  的併發連線數都為6，可能各個版本有區別。作為一個站長，或者說一個完善的產品，這個是不得不考慮的。

解決方案：

1.給定一組域名，如：img1.baidu.com、img2.baidu.com、img3.baidu.com、img4.baidu.com... ... 

2.這組域名指向同一個源，或者說最終源是一個。

3.上傳圖片（靜態檔案）的時候隨機返回這組域名中的其中一個即可，這樣圖片的訪問域名就不會出現只是一個域名了。