從輸入url到頁面（二）：TCP/IP 與 http協議

4、TCP/IP協議

　　拿到域名對應的IP地址以後，瀏覽器會以一個隨機端口（1024<端口<65535）向服務器的WEB程序發起TCP的鏈接請求。這個鏈接請求到達服務器端後（這中間經過各類路由設,代理，局域網內除外），進入到網卡，而後是進入到內核的TCP/IP協議棧（用於識別該鏈接請求，解封包），最終到達WEB程序，最終創建了TCP/IP的鏈接。能夠保證傳輸的報文永不丟失，受損或者亂序

（一）IP數據包

　　TCP的數據，是經過名爲IP分組的小數據塊來發送的。以流的形式將報文數據的內容，經過一條打開的TCP鏈接按序傳輸。TCP收到數據流以後，將數據流砍成小TCP數據段，並將其封裝在IP分組中，經過網絡進行傳輸。

　　每一個IP分組包括：IP分組首部，TCP段首部，TCP數據塊

　　IP分組首部包含了源和目的IP地址、首部長度、數據報總長、首部較驗和等標記。

　　TCP段的首部包含了TCP端口號、TCP控制標記、和用於數據排序和數據完整性檢查的一些標記。

（二）TCP鏈接

　　任意時刻計算機均可以有幾條TCP鏈接處於打開狀態，是經過端口號來保持全部的這些鏈接持續不斷地運行的。

　　經過四個值來識別和惟一地定義一條鏈接：<源IP，源端口號，目的IP，目的端口號>。兩條不一樣鏈接不能擁有4個徹底相同的地址組件值。

（三）HTPP事務的時延

　　一、  若是對URI的主機名最近沒有訪問，經過DNS解析須要花費時間

　　二、  TCP鏈接創建時延。三次握手，多條鏈接的時延會快速的疊加。

　　三、  傳輸請求報文，服務器接收並進行處理。

　　四、  服務器會送HTTP響應報文。

（四）TCP性能聚焦

　　影響較大，較常見的TCP相關時延包括：創建握手；慢啓動擁塞控制、數據彙集的Nagle算法、用於捎帶確認的TCP延遲確認算法、TIME_WAIT時延和端口耗盡。

　　一、  在創建一條新的鏈接以前，甚至在發送任意數據以前，TCP軟件之間會交換一系列的IP分組，對鏈接的有關參數進行確認。若是鏈接只用來傳送少許數據，這些交換過程會嚴重下降HTTP的性能。

　　　　第一步，客戶端向服務器發送一個小的TCP分組，其中設置一個特殊的SYN標記，說明是一個鏈接請求。

　　　　第二步，服務器若是接受了請求，對一些鏈接參數進行計算，向客戶端回送一個TCP分組，分組中SYN和ACK標記都被置位，說明鏈接請求已被接受。

　　　　第三步，客戶端回送一條確認信息，通知鏈接已經成功創建。現代TCP棧都容許客戶端在這個分組中發送數據。304 Not Modified 等小型http事務，在創建鏈接上耗時可能50%以上。

　　二、  延遲確認。因特網沒法確保可靠的分組傳輸，TCP實現有本身的確認機制來確保數據的成功傳輸。

　　　　每一個TCP段都有一個序列號和數據完整性校驗和。接收者收到無缺的段時，都會向發送者回送小的確認分組。若是發送者沒有在指定的窗口時間內收到確認信息，發送者就認爲分組已經被破壞，並重發數據。

　　　　因爲確認報文很小，因此TCP容許在發往相同方向的輸出數據分組中對其進行「捎帶」。不少TCP棧都實現了一種「延遲確認」算法。會在一個特定的窗口時間內，將輸出確認存放在緩衝區內，以尋找可以捎帶它的輸出數據分組。若是沒有輸出數據分組，就將其單獨發送。

　　　　可是，HTTP具備雙峯特徵的請求，應答行爲下降了捎帶信息的可能。一般，延遲確認算法會引入至關大的時延。根據所使用操做系統的不一樣，能夠調整或禁止延遲確認算法。

　　三、  TCP慢啓動。鏈接會隨着時間進行自我「調諧」，起初會限制鏈接的最大速度，若是數據傳輸成功，會隨着時間的推移提升傳輸的速度。用於阻止因特網的忽然過載和擁塞。

　　　　因爲這種特性，新打開的鏈接傳輸速度會比交換過必定數量數據的鏈接慢一點。應儘可能重用現存鏈接。

　　四、  Nagle算法與TCP_NODELAY。TCP有一個數據流接口。能夠將任意大小的數據放入TCP棧中，因此若是大量包含極少數據的分組，網絡的性能就會嚴重降低。

　　　　Nagle算法試圖在發送一個分組以前，將大量TCP數據綁定在一塊兒，提升網絡效率。鼓勵發送全尺寸的段（LAN上最大尺寸的分組大約是1500字節，在網絡中是幾百字節）。只有當全部其餘分組都被確認以後，Nagle算法才容許發送非全尺寸的分組。

　　　　HTTP應用程序經常會在本身的棧中設置參數TCP_NODELAY，禁用此算法，提升性能。

　　五、  TIME_WAIT累積與端口耗盡

　　　　端口耗滿是很嚴重的問題，當某個TCP端點關閉鏈接時，會在內存中維護一個小的控制塊，用來記錄最近所關閉鏈接的IP地址和端口號。

　　　　一般只會維持一小段時間，2分鐘左右，以確保在這段時間內不會建立具備相同地址和端口號的新鏈接。防止來自以前鏈接的複製分組插入了具備相同鏈接值的新TCP流中，會破壞TPC數據。

（五）HTTP鏈接的處理

　　　若是隻對鏈接作簡單的串行管理，TCP的鏈接時延和慢啓動會很快疊加起來。更壞的狀況，有些瀏覽器在對象加載完畢以前沒法獲知對象的尺寸，計算佈局位置，在加載完以前，頁面沒法顯示內容。幾種現存和新興的方法能夠提升HTTP的鏈接性能。

　　一、  並行鏈接。瀏覽器能夠執行多個HTTP事務。

　　　　優點：使鏈接時延重疊，高效利用帶寬，多個組件對象同時顯示加載對用戶友好。劣勢：帶寬有限時，每一個鏈接都很慢尤爲新打開時，web服務器的性能壓力

　　　　現狀：瀏覽器使用了並行鏈接，對同一域名的連接總數限制爲一個較小的值，且服務器能夠隨意關閉超量鏈接。

　　二、  持久連接。HTTP/1.1容許設備在事務處理結束以後將TCP鏈接保持在打開狀態。

　　　　優點：避免屢次的鏈接時延，和慢啓動的擁塞適應，減小了鏈接數量、性能壓力。

　　　　劣勢：按順序串行請求，對帶寬可能有浪費。

　　　　現狀：與並行鏈接結合使用，打開最多兩條並行的持久鏈接。

　　三、  管道化連接。在持久鏈接的基礎上的優化。

　　　　在響應到達以前，能夠將多條請求放入隊列，順序發出。

　　　　限制：服務器必須按照與請求相同的順序回送HTTP響應。鏈接會在任意時刻斷開，客戶端要能重發全部未完的請求。不該該在管道中發送有反作用非冪等的請求（post等），沒法安全的重試。

　　四、  SPDY會話層協議。Chromium引入的新機制，爲了解決網絡延遲和安全性問題。

　　　　在HTTP2.0的草案中將引入此協議。核心思想是多路複用，使用一個鏈接來傳輸網頁中的衆多資源。HTTP>SYDY>SSL>TCP>IP。

　　　　優點：根據請求的優先級，服務器能夠優先回復優先的資源。服務器能夠在發送網頁時，嘗試發送一些信息給瀏覽器，瀏覽器能夠提早知道並決定是否須要下載，甚至，服務求能夠主動發送資源。

5、HTTP報文

　　報文由三部分組成：起始行，首部塊，可選包含數據的主體。分爲請求報文和響應報文。

　　請求報文：

<method> <request-URL> <version>
<header>

<entity-body>

　　響應報文：

<version> <status> <reason-phrase>
<headers>

<entity-body>

（一）請求報文

　　在請求報文起始行開始位置，客戶端但願服務器對資源執行的動做標識。各方法在網絡發送並沒有實質不一樣，都是HTTP的報文，只是在規範上有所不一樣，如GET不發送實體，能夠在URL後加查詢字符串；POST將數據放在數據報文實體中。服務器端根據不一樣的路由設置來處理對應的報文。

　　一、  GET方法。最經常使用的，安全方法，一般用於請求服務器發送某個資源。

　　二、  HEAD。只返回一樣GET方法的首部信息。不會反悔實體的主體部分。能夠用來查看對象資源的狀態，是否存在，是否有效。

　　三、  PUT。向服務器寫入文檔，建立一個由所請求的URL命名的新文檔。

　　四、  POST，起初是用來向服務器輸入數據的，一般用來支持HTML的表單。

　　五、  TRACE，終端服務器會發起一個追蹤響應，在主體中攜帶它收到的原始請求報文，能夠查看報文是否被中間實體修改過。缺陷是,要假定中間應用程序對不一樣類型的請求處理是相同的.

　　六、  OPTIONS,請求告知服務器對某資源支持的各類功能。

　　七、  DELETE，請求刪除URL指定的資源。

（二）報文首部

　　

能夠分爲通用、請求、響應、實體、擴展首部。

一、  通用信息性首部

　　通用緩存首部

二、  請求首部

　　請求信息性首部，

　　Accept內容協商首部

　　條件請求首部

　　安全請求首部

　　代理請求首部

三、  響應首部

　　信息性首部

　　協商首部

　　安全響應首部

四、  實體信息性首部

　　內容首部

　　實體緩存首部

6、Web的結構組件

　　代理：接收客戶端請求，轉發給服務器。反向代理，負載均衡等應用。

　　緩存：或代理緩存。特殊的HTTP代理服務器，提供文檔緩存服務。

　　網關：特殊上服務器，做爲其餘服務器的中間實體使用，用在HTTP協議與其餘協議之間的轉換溝通。

　　隧道：在鏈接之間對原始數據進行盲轉發的HTTP應用程序。

　　Agent代理：瀏覽器，網絡爬蟲