性能：絕對與相對URL

Question

速度更快？ Hot linking (inline linking)更改爲absolute URI或自己託管該資源並使用relative URI？

在他tutorial on how to style HTML5 elements in Internet Explorer，雷米夏普指出熱鏈接導致一個「額外的HTTP [GET]請求」。我同意你是否比較熱鏈接複製&將腳本粘貼（嵌入）到HTML中。但是，如果您將熱鏈接與本地託管腳本以及通過相對路徑進行鏈接進行比較，那麼我認爲熱鏈接實際上會（更快），因爲瀏覽器無需解析絕對路徑來自相對路徑的網址。但是，在這兩種情況下，都會執行額外的HTTP GET請求，是否正確？

Answer 1

正確的答案是 - 它取決於。

盜鏈可能會很慢，因爲 -

1. 需要一個額外的DNS查找
2. 無法重用現有的TCP/IP套接字連接

託管你的服務器上可能會很慢，因爲 -

1. 瀏覽器只允許每個主機有n個併發請求。對同一個主機有更多的請求有可能引入排隊，這可能會很慢。數字'n'是瀏覽器特定的，並且是2到6之間的任何值。See browserscope > network > connections per host name。

如果您認爲兩方面的服務器在各方面都相同，我會說在您的服務器上託管會更快。特別是在每臺主機的連接數爲6的新瀏覽器上，情況尤其如此。

但可悲的是，事情從未如此簡單。我建議僅當使用盜鏈 -

1. 你在你的領域有太多的資源（圖片/ JS）
2. 其他服務器是CDN，而資源是足夠的一個受歡迎的，所以，有一個它將會出現在瀏覽器的緩存中。在谷歌的服務器上思考JQuery。

對於所有其他用途的情況下，你最好的託管自己的服務器上。

Answer 2

我猜想，影響這種情況的唯一的東西是服務器的問題（速度）的相對速度以及你是否希望此代碼在任何其他網站（可維護性）運行。

Answer 3

假設資源沒有嵌入HTML文檔本身（即鏈接），並且資源位於具有相同主機名的同一臺服務器上，通過絕對URI或相對URI檢索資源的時間應該是虛擬的相同。其他HTTP請求將以任一方式提交。如果你想分割'幾乎相同的'，由於需要解析的HTML數量較少，所以我會傾向於相對路徑的速度非常非常小，路徑解析（如你所提到的）可能是更快（由於字符串標記器不必處理地址的域部分/地址更短）。這裏的區別僅僅是出於好奇心。我無法想象一個網站正在被優化到這個級別（雖然它可能會建立一個很好的經驗法則？相對路徑允許您自由地更改站點的域名/路徑而無需重寫包含的所有的URI的..）

有一點要考慮是，如果資源是不託管在同一臺服務器上，並引用HTML文檔的服務器啓用了保持活動，另一個TCP連接將不得不初始化以連接到第二個服務器（以及爲解析其他服務器的主機名而進行的DNS查詢，假設該訪問不是通過IP地址），從而導致與多個引用資源相比的額外開銷相同的服務器（GET請求將在現有T內發出） CP連接）。

這同樣適用於沒有啓用KeepAlive的服務器;將爲每個請求的資源初始化一個TCP連接。

Answer 4

這與更低級別的東西，如tcp而不是http本身有關。如果你現在從同一個網絡服務器得到兩個項目，你的瀏覽器很可能通過同一個tcp連接來獲取它們。這是通過一個tcp連接的兩個http事務。這避免了另一個TCP連接的開銷。這種開銷在流量方面很小，但可能涉及很多延遲。

OTOH，做兩個HTTP事務，他們每去到不同的服務器，也許更快，也許不是。誠然，你有兩個tcp連接的開銷。在這種情況下，他們是序列化—一個必須完成之前，第二個可以開始。但是，如果您拉下了很多對象，那麼第2,3,4 ...個連接都可以並行執行，從而屏蔽延遲問題。在這種情況下，事情可能會快得多，因爲小對象可能不受ISP的帶寬限制。

水域確實是泥濘的。

只要留意延遲和帶寬。取決於您的資源數量和規模。

Answer 5

客戶端需要解析相對URI的時間絕對可以忽略不計。

因此，使用絕對或相對URI鏈接到文檔相同域中的資源沒有任何區別。當資源被不同的服務器上承載

唯一的差別就越大。然後你需要，而一個額外的HTTP請求到服務器，你已經到可以用它連接的連接額外的TCP連接到該服務器。