短鏈接:客戶端和服務器每進行一次http操做,就創建一次鏈接,任務結束就中斷鏈接。linux
短鏈接的操做步驟是:web
創建鏈接——數據傳輸——關閉鏈接...創建鏈接——數據傳輸——關閉鏈接
長鏈接:客戶端和服務器之間用於傳輸HTTP數據的TCP鏈接不會關閉,客戶端再次訪問這個服務器時,會繼續使用一條已經創建的鏈接。算法
長鏈接的操做步驟是:apache
創建鏈接——數據傳輸...(保持鏈接)...數據傳輸——關閉鏈接
HTTP實現長鏈接的方式緩存
HTTP 1.0須要使用keep-alive參數來告知服務器端要創建一個長鏈接,而HTTP1.1默認支持長鏈接。服務器
HTTP是基於TCP/IP協議的,建立一個TCP鏈接是須要通過三次握手的,有必定的開銷,若是每次通信都要從新創建鏈接的話,對性能有影響。所以最好能維持一個長鏈接,能夠用一個長鏈接來發多個請求。網絡
HTTP 1.1支持只發送header信息(不帶任何body信息),若是服務器認爲客戶端有權限請求服務器,則返回100,不然返回401。客戶端若是接收到100,纔開始把請求body發送到服務器。這樣當服務器返回401的時候,客戶端就能夠不用發送請求body了,節約了帶寬。併發
另外HTTP還支持傳送內容的一部分。這樣當客戶端已經有一部分的資源後,只須要跟服務器請求另外的部分資源便可。這是支持文件斷點續傳的基礎。app
在網絡中,一個IP對應多個域名。假設 使用Tomcat 搭建網站站點,在Tomact中搭建多個站點,站點使用相同的IP和PORT,當域名映射成ip,如何區分站點呢?使用Host。webapp
設置HOST,只須要編輯 server.xml 便可,實例以下:
<Engine name="Catalina" defaultHost="www.qiniu.com"> <Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/> <Host name="www.qiniu.com" appBase="qiniuwebapp" unpackWARs="true" autoDeploy="true" > <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="qiniuwebapp_access_log." suffix=".txt" pattern="%h %l %u %t "%r" %s %b" /> </Host> <Host name="www.taobao.com" appBase="taobaowebapp" unpackWARs="true" autoDeploy="true" > <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="taobaowebapp_access_log." suffix=".txt" pattern="%h %l %u %t "%r" %s %b" /> </Host> <Host name="www.jb.com" appBase="jbwebapp" unpackWARs="true" autoDeploy="true" > <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="jbwebapp_access_log." suffix=".txt" pattern="%h %l %u %t "%r" %s %b" /> </Host> </Engine>
如今能夠用web server(例如tomat),設置虛擬站點是很是常見的,也便是說,web server上的多個虛擬站點能夠共享同一個ip和端口。
HTTP1.0是沒有host域的,HTTP1.1才支持這個參數。
HTTP2.0使用了多路複用的技術,作到同一個鏈接併發處理多個請求,並且併發請求的數量比HTTP1.1大了好幾個數量級。
固然HTTP1.1也能夠多創建幾個TCP鏈接,來支持處理更多併發的請求,可是建立TCP鏈接自己也是有開銷的。
TCP鏈接有一個預熱和保護的過程,先檢查數據是否傳送成功,一旦成功過,則慢慢加大傳輸速度。所以對應瞬時併發的鏈接,服務器的響應就會變慢。因此最好能使用一個創建好的鏈接,而且這個鏈接能夠支持瞬時併發的請求。
HTTP1.1不支持header數據的壓縮,HTTP2.0使用HPACK算法對header的數據進行壓縮,這樣數據體積小了,在網絡上傳輸就會更快。
HTTP 2.0 新增的一個強大的新功能,就是服務器能夠對一個客戶端請求發送多個響應。換句話說,除了對最初請求的響應外,服務器還能夠額外向客戶端推送資源,而無需客戶端明確地請求。
有了HTTP2.0的服務器推送,HTTP1.x時代的內嵌資源的優化手段也變得沒有意義了。並且使用服務器推送的資源的方式更加高效,由於客戶端還能夠緩存起來,甚至能夠由不一樣的頁面共享(依舊遵循同源策略)。