(轉)發起訪問網頁，整個網絡的詳細過程！

轉自https://onlyangelia.github.io/computerIntnet/intnetlink/

講解鏈接過程以前，先解釋幾點，給後面的闡述作鋪墊。在咱們的電腦啓動時，會經過DHCP協議(也是屬於應用層的協議，基於UDP協議，全程 Dynamic Host Configuration Protocol ：動態主機配置協議) 進行動態配置IP地址（固然也能夠手動配置IP，通常人不會這麼作），而且咱們的電腦會有對應的惟一的MAC地址（MAC全稱：Media Access Control，媒體訪問控制），發送網絡包，目標地址既要包括IP地址，也要包含MAC地址。IP地址相似於住址，MAC地址相似於身份證，二者缺一不可。IP地址和MAC地址的映射能夠經過APR協議(全稱：Address Resolution Protocol 地址解析協議，是屬於鏈路層的協議 ) 查詢。記住IP地址和MAC地址這兩個概念。

在TCP/IP五層模型下，經過在瀏覽器中瀏覽網頁，咱們來梳理下網絡的鏈接過程。好比，咱們在瀏覽器輸入：https://onlyAnglia.github.io ，按下回車，到瀏覽器中顯示出博客內容中間經歷了哪些過程？先簡單的講下HTTP的鏈接，再在HTTP的基礎上補充HTTPS的鏈接。固然應用層還有許多協議，例如RTMP、QUIC、GTP等，有基於TCP的，也有基於UDP的。這裏舉例用基於TCP的HTTP協議，有關傳輸層經常使用的協議UDP 和 TCP鏈接不一樣和詳細的鏈接過程，後面會單獨寫解釋,接下來看一下網絡的鏈接。

總體的傳輸流程以下：

 

 

TCP-IP五層模型數據傳輸.png

首先，機器和人不同，並不能識別咱們能熟記的域名，機器只認IP地址，因此

step1：進行DNS解析，獲得域名對應的IP地址(DNS解析比較複雜，這裏只說下通常流程，有關負載均衡等暫且不提)

瀏覽器先在本地DNS緩存中查找onlyAnglia.github.io 對應的IP地址，若找到則返回對應的IP；假若本地DNS緩存中未查找到域名對應的IP地址，則接下來會像本地DNS服務器詢問（若是是經過DHCP配置，本地DNS服務器由對應的 網絡服務商（ISP自動分配），若是找到就直接返回IP地址；若沒有找到，本地DNS服務器會向它的根域名服務器詢問,根域名服務器會告訴本地DNS服務器該向哪一個頂級域名服務器詢問，以後頂級域名服務器會告訴本地DNS服務器該向哪一個權威域名服務器詢問；接下來本地DNS服務器會找到對應的權威域名服務器查詢對應的IP地址，權威服務器將對應的IP地址告訴本地DNS服務器，本地DNS服務器再將IP地址返回給瀏覽器，瀏覽器接收到對應的IP地址，準備開始創建鏈接。

step2：使用HTTP協議，通過應用層包裝

查詢到域名對應的IP地址以後表示請求訪問的目標存在，能夠進行訪問。而後應用層請求構建HTTP，客戶端的HTTP報文叫作請求報文，多數使用的仍是HTTP1.1,在HTTP1.1的請求報文中包含了請求行、首部、正文實體。 其中，請求行包含用戶請求的方法，請求URI 和 HTTP版本號。 例如：POST /form/entry HTTP1.1 首部字段 包含各類請求條件和請求屬性，有些字段只是請求首部字段，部分是通用首部字段，還有一部分是實體首部字段(有關該部分可詳見：HTTP協議簡單解釋)。構建好請求報文後，經過stream二進制流傳遞給傳輸層。而且瀏覽器開啓端口號監聽。

step3：傳輸層接收請求報文，構建請求段(傳輸層協議主要有UDP協議和TCP協議，HTTP是基於TCP協議)

應用層將請求報文傳遞給傳輸層後，傳輸層根據要使用的協議進行傳輸層報文的封裝，在這裏構建的是TCP包頭，傳輸層構建好TCP包頭後，將傳輸來的流信息做爲數據項。TCP的包頭比較複雜,這和TCP的可靠鏈接有關，此時到了傳輸層後內核會開啓，監聽端口號，等待接下來的迴應。（通常機器中會有一個網卡，也有部分機器會裝有多個網卡）此時瀏覽器處於SYN-SENT狀態。

 

TCP包頭.jpg

 

step4：網絡層接收傳輸層的段，構建IP包（網絡傳輸二層叫幀，網絡層叫包，傳輸層叫段）

網絡層在接收到傳輸層傳過來的TCP包後，第一個任務是封裝IP包，將應用層傳輸過來的TCP包做爲數據項，添加IP首部，造成IP包。傳輸層TCP協議的包頭首部中包含了源端口號、目的端口號，在網絡層IP協議要將源地址、目的地址包裝在IP包中。此外，IP包中還包含了版本、首部長度、服務類型TOS、總長度、標識、標誌、片偏移、首部檢驗和、生存時間TTL等。網絡層封裝完IP包後，將IP包傳交給鏈路層。

step5：數據鏈路層接收IP包，構建MAC幀

數據鏈路層又可稱爲MAC層(MAC全稱 Media Access Control 媒體訪問控制)，MAC層接收到IP包後，開始構建MAC幀，MAC幀開始是目標MAC地址和源MAC地址，源MAC地址毫無疑問是咱們本機的MAC地址，本機的MAC地址在該設備被創造出來的時候就有，而且是惟一的(要想查看IP地址和MAC地址，linux上使用ifconfig或者ip addr，會在終端輸出電腦的網絡相關信息)。知道了本身設備上的MAC地址，但不知道目標IP地址對應的MAC地址，因此須要一個可以查詢IP地址和MAC地址對應的協議，就是ARP（Address Resolution Protocol）協議。ARP協議只是針對IPv4，如果IPv6，要使用NDP協議。機器本地是有ARP協議緩存的，若能在ARP協議緩存中找到IP地址對應的MAC地址，便不會再去請求ARP協議，若沒有則會請求ARP協議。在知道了目標IP地址對應的MAC地址後，將目標MAC地址放在MAC幀裏,以太網的第二層最後面是CRC，也就是循環冗餘檢測，（MAC幀的其它組成不在細說）。

step6：MAC幀頭構建好後，網關準備發包

MAC幀構建好，在網絡中傳輸的網絡包即構建好，而後將網絡包發出去。在發包以前IP地址是否在同一個網段內的問題，經過CIDR和子網掩碼計算是否在一個網段內，若在同一個網段內直接發出。通常咱們訪問的網站是不太可能和咱們在同一網段內的，那麼須要將包發往默認網關，默認網關收入包。

step7：網關查詢路由表，經過路由協議進行網絡傳輸

網關收入包後，取下MAC幀和IP包，判斷該網哪裏轉發，根據路由算法，選擇一個合適的網段。網段的選擇會涉及到兩種形式的路由算法，一種是靜態路由，一種是動態路由。靜態路由就是在路由器上配置一條條規則，維護路由表。能夠經過route命令和ip route命令查看進行靜態路由的查詢和配置。 動態路由使用動態路由路由器，根據路由協議算法生成動態路由表，隨網絡運行狀況的變化而變化。動態路由協議算法也涉及兩大類，第一大類算法稱爲距離矢量路由（distance vector routing）適用於小型網絡，最先的路由協議RIP採用該算法，第二大類算法是鏈路狀態路由（link state routing）。內部網關協議採用基於鏈路狀態路由算法的OSPF（Open Shortest Path First，開放式最短路徑優先），網絡的路由協議是基於距離矢量路由算法的BGP(Border Gateway Protocol)。BGP分爲兩類，eBGP和iBGP。對於網絡包，每一個數據中心有本身的規則，網絡中這種不一樣規則所構成的網絡包爲自治系統AS(Autonomous System)。自治系統間邊界路由器使用eBGP廣播路由，內部運行iBGP，讓內部路由器快速找到到達外網目的的最好的邊界路由器。路由器之間信息交換使用的協議，RIP使用UDP協議，OSPF直接發送IP包，而BGP使用的是TCP協議，路由之間會創建TCP鏈接，每60s發送一次keep-alive 消息。此外HTTP 1.1默認keep-alive是開啓的。這樣網絡包就像跳方格同樣跳了多個（也許是一個）路由器以後，終於找到了目的IP地址所在的網關。

step8：找到目的IP地址後，網關取下MAC頭，將IP包發送給目的主機的 網絡層，檢查IP地址是否對上

目的IP地址所在的網關接收到網絡包後，發如今同一個網段內， 將包收入，而後發送給目的主機，目的主機取下MAC頭，判斷一下MAC地址和本身的相符，而後將IP包傳給網絡層，網絡層取下IP包頭,查看IP地址和本身的IP地址是否對上。

step9：IP地址對上以後，網絡層將包傳遞給傳輸層，TCP發確認包，會延剛纔的方向報平安，直到收到平安到達的回覆，進行TCP握手

網絡層數判斷IP地址對上以後，根據IP頭中的協議項，知道本身上層還須要TCP協議，將包傳遞給傳輸層，目的主機的內核開啓，當目的主機有了IP的端口號，就能夠調用listen函數進行監聽(TCP和UDP都是基於 Socket, 而 listen函數 是Socket裏的函數，有關 Socket 這裏不詳細解說)，目的主機處於LISTEN狀態。傳輸層在收到TCP請求段後，會發送ACK包確認到達，此時目的主機處於SYN-RCVD狀態，發送的網絡包延剛纔的路徑傳回，瀏覽器在接收到目的主機發送的SYN,ACK後進入ESTABLISHED狀態，同時再發出ACK，當目的主機接收到ACK後也進入ESTABLISHED狀態，此時TCP三次握手完成。

step10：TCP收到回覆後，進行目的端口匹配，將包內容傳給HTTP服務，RPC統籌處理請求，告訴相關進程

TCP三次握手完成後，進行目的端口匹配，以後將包內容傳給上層的HTTP服務，RPC統籌處理，告訴相關進程（Soket多是進程在維護也多是線程在維護監聽，而且TCP每每會創立兩個Socket，一個叫作就監聽Socket，一個是已鏈接Socket，這裏不詳細講述)。

step11：RPC處理完畢，會回覆一個HTTP/HTTPS包告知操做成功，準備向接收端傳輸處理結果

在RPC處理完畢後，目的主機開始向接收方發送數據。在鏈接創建的時候，兩方已商定起始ID，但數據的發送不是一個發送完等回覆後再發送另外一個，而是經過累計確認或者叫累計應答（cumulative acknowledgment） 的模式進行傳輸，即在應答某個以前的ID表示都收到了。這樣TCP須要雙方有緩存進行記錄，發送方的記錄分四部分：第一部分是發送了而且已確認，第二部分是發送了而且還沒有確認，第三部分是沒有發送但在等待發送，第四部分是沒有發送暫時也不會發送。第一部分和第二部分的分界線是lastByteAcked，第二部分和第三部分的分界線是lastByteSent，整個第二部分和第三部分的和 Advertised window 。 瀏覽器做爲接收端在TCP報文裏是會告訴發送端這個窗口大小的，超過了這個窗口的包，接收端沒法接收就會丟棄。（有關接收方的窗口說明詳情可自行查詢）（滑動窗口？）

step 12: TCP慢啓動，以後開始進行數據傳輸，並隨時監測窗口大小進行流量控制和擁塞控制

雖然瀏覽器做爲接收方告訴了發送方窗口大小，但網絡是瞬息萬變的，也許這會網絡變差了或者網段了，那麼TCP在一開始的時候，爲了不形成通道容量溢出，一條TCP鏈接後，設置只能發送一個報文段cwnd(congestion window 擁塞窗口)設置爲1，在收到一個確認後，cwnd加一，一次可以發送兩個，當這兩個報文段的確認到來的時候，每一個cwnd都加一，這樣兩個cwnd就加二，一次就能發四個，開始呈現指數級增加。當一次發送超過ssthresh的值時表明快要溢出，此時cwnd改成增長1/cwnd，一輪下來增加一個......這是有關傳輸過程當中的擁塞控制，關於擁塞控制仍有一些問題存在，具體的流程可自查詢相關的流量控制和擁塞控制。

step 13:接收方瀏覽器接收到數據後，開始進行處理，逐漸在瀏覽器上顯示

經過數據的傳輸，接收端接收到了來自發送方的網絡包，當接收到一個網絡包時，TCP最終將包傳遞給瀏覽器，讓瀏覽器處理HTTP應答報文，這樣隨着應答報文的數量增長，網頁中的內容也會逐漸的顯示在瀏覽器上。

step 14: 數據傳輸完成，進行鏈接斷開，四次揮手說再見

數據終於傳輸完成，到了該斷開的時候。但咱們知道TCP是可靠的傳輸鏈接，是相對靠譜的，那做爲靠譜的協議在斷開的時候不能說斷開就斷開，而且TCP是全雙工的，因此接收端和發送端須要各自斷開。數據傳輸完畢時，服務器和瀏覽器做爲發送方和接收方都處於ESTABLISHED狀態，此時服務器知道數據已傳輸完畢，準備斷開，就向接收方發送FIN報文，進入FIN-WAIT-1狀態；接收方收到FIN報文後，向發送方發送ACK，進入CLOSED-WAIT狀態；服務端收到ACK後從FIN-WAIT-1狀態進入FIN-WAIT-2狀態；接收方進入CLOSED-WAIT狀態結束後再向發送方發送FIN,ACK ,並進入LAST-ACK狀態；發送方接收到FIN、ACK後從FIN-WAIT-2狀態進入TIME-WAIT狀態(等待2MSL)，而且發送ACK；接收方接收到ACK後進入CLOSED狀態；服務端等待2MSL(MSL: Maximum Segment Lifetime ,報文最大生成時間)後也進入CLOSED狀態。至此，創建的鏈接已經各自斷開，整個鏈接過程結束。

爲了更好的理解TCP三次握手和四次揮手，附上TCP狀態機 

 

TCP狀態機.jpg

 

以HTTP爲例講述了網絡的鏈接過程，其它協議與此大同小異，如果基於UDP的協議會在上述步驟中簡化不少，數據傳輸中的socket維護也相對簡單。以上就是網絡的鏈接過程。

講解鏈接過程以前，先解釋幾點，給後面的闡述作鋪墊。在咱們的電腦啓動時，會經過DHCP協議(也是屬於應用層的協議，基於UDP協議，全程 Dynamic Host Configuration Protocol ：動態主機配置協議) 進行動態配置IP地址（固然也能夠手動配置IP，通常人不會這麼作），而且咱們的電腦會有對應的惟一的MAC地址（MAC全稱：Media Access Control，媒體訪問控制），發送網絡包，目標地址既要包括IP地址，也要包含MAC地址。IP地址相似於住址，MAC地址相似於身份證，二者缺一不可。IP地址和MAC地址的映射能夠經過APR協議(全稱：Address Resolution Protocol 地址解析協議，是屬於鏈路層的協議 ) 查詢。記住IP地址和MAC地址這兩個概念。

在TCP/IP五層模型下，經過在瀏覽器中瀏覽網頁，咱們來梳理下網絡的鏈接過程。好比，咱們在瀏覽器輸入：https://onlyAnglia.github.io ，按下回車，到瀏覽器中顯示出博客內容中間經歷了哪些過程？先簡單的講下HTTP的鏈接，再在HTTP的基礎上補充HTTPS的鏈接。固然應用層還有許多協議，例如RTMP、QUIC、GTP等，有基於TCP的，也有基於UDP的。這裏舉例用基於TCP的HTTP協議，有關傳輸層經常使用的協議UDP 和 TCP鏈接不一樣和詳細的鏈接過程，後面會單獨寫解釋,接下來看一下網絡的鏈接。

總體的傳輸流程以下：

 

 

TCP-IP五層模型數據傳輸.png

首先，機器和人不同，並不能識別咱們能熟記的域名，機器只認IP地址，因此

step1：進行DNS解析，獲得域名對應的IP地址(DNS解析比較複雜，這裏只說下通常流程，有關負載均衡等暫且不提)

瀏覽器先在本地DNS緩存中查找onlyAnglia.github.io 對應的IP地址，若找到則返回對應的IP；假若本地DNS緩存中未查找到域名對應的IP地址，則接下來會像本地DNS服務器詢問（若是是經過DHCP配置，本地DNS服務器由對應的 網絡服務商（ISP自動分配），若是找到就直接返回IP地址；若沒有找到，本地DNS服務器會向它的根域名服務器詢問,根域名服務器會告訴本地DNS服務器該向哪一個頂級域名服務器詢問，以後頂級域名服務器會告訴本地DNS服務器該向哪一個權威域名服務器詢問；接下來本地DNS服務器會找到對應的權威域名服務器查詢對應的IP地址，權威服務器將對應的IP地址告訴本地DNS服務器，本地DNS服務器再將IP地址返回給瀏覽器，瀏覽器接收到對應的IP地址，準備開始創建鏈接。

step2：使用HTTP協議，通過應用層包裝

查詢到域名對應的IP地址以後表示請求訪問的目標存在，能夠進行訪問。而後應用層請求構建HTTP，客戶端的HTTP報文叫作請求報文，多數使用的仍是HTTP1.1,在HTTP1.1的請求報文中包含了請求行、首部、正文實體。 其中，請求行包含用戶請求的方法，請求URI 和 HTTP版本號。 例如：POST /form/entry HTTP1.1 首部字段 包含各類請求條件和請求屬性，有些字段只是請求首部字段，部分是通用首部字段，還有一部分是實體首部字段(有關該部分可詳見：HTTP協議簡單解釋)。構建好請求報文後，經過stream二進制流傳遞給傳輸層。而且瀏覽器開啓端口號監聽。

step3：傳輸層接收請求報文，構建請求段(傳輸層協議主要有UDP協議和TCP協議，HTTP是基於TCP協議)

應用層將請求報文傳遞給傳輸層後，傳輸層根據要使用的協議進行傳輸層報文的封裝，在這裏構建的是TCP包頭，傳輸層構建好TCP包頭後，將傳輸來的流信息做爲數據項。TCP的包頭比較複雜,這和TCP的可靠鏈接有關，此時到了傳輸層後內核會開啓，監聽端口號，等待接下來的迴應。（通常機器中會有一個網卡，也有部分機器會裝有多個網卡）此時瀏覽器處於SYN-SENT狀態。

 

TCP包頭.jpg

 

step4：網絡層接收傳輸層的段，構建IP包（網絡傳輸二層叫幀，網絡層叫包，傳輸層叫段）

網絡層在接收到傳輸層傳過來的TCP包後，第一個任務是封裝IP包，將應用層傳輸過來的TCP包做爲數據項，添加IP首部，造成IP包。傳輸層TCP協議的包頭首部中包含了源端口號、目的端口號，在網絡層IP協議要將源地址、目的地址包裝在IP包中。此外，IP包中還包含了版本、首部長度、服務類型TOS、總長度、標識、標誌、片偏移、首部檢驗和、生存時間TTL等。網絡層封裝完IP包後，將IP包傳交給鏈路層。

step5：數據鏈路層接收IP包，構建MAC幀

數據鏈路層又可稱爲MAC層(MAC全稱 Media Access Control 媒體訪問控制)，MAC層接收到IP包後，開始構建MAC幀，MAC幀開始是目標MAC地址和源MAC地址，源MAC地址毫無疑問是咱們本機的MAC地址，本機的MAC地址在該設備被創造出來的時候就有，而且是惟一的(要想查看IP地址和MAC地址，linux上使用ifconfig或者ip addr，會在終端輸出電腦的網絡相關信息)。知道了本身設備上的MAC地址，但不知道目標IP地址對應的MAC地址，因此須要一個可以查詢IP地址和MAC地址對應的協議，就是ARP（Address Resolution Protocol）協議。ARP協議只是針對IPv4，如果IPv6，要使用NDP協議。機器本地是有ARP協議緩存的，若能在ARP協議緩存中找到IP地址對應的MAC地址，便不會再去請求ARP協議，若沒有則會請求ARP協議。在知道了目標IP地址對應的MAC地址後，將目標MAC地址放在MAC幀裏,以太網的第二層最後面是CRC，也就是循環冗餘檢測，（MAC幀的其它組成不在細說）。

step6：MAC幀頭構建好後，網關準備發包

MAC幀構建好，在網絡中傳輸的網絡包即構建好，而後將網絡包發出去。在發包以前IP地址是否在同一個網段內的問題，經過CIDR和子網掩碼計算是否在一個網段內，若在同一個網段內直接發出。通常咱們訪問的網站是不太可能和咱們在同一網段內的，那麼須要將包發往默認網關，默認網關收入包。

step7：網關查詢路由表，經過路由協議進行網絡傳輸

網關收入包後，取下MAC幀和IP包，判斷該網哪裏轉發，根據路由算法，選擇一個合適的網段。網段的選擇會涉及到兩種形式的路由算法，一種是靜態路由，一種是動態路由。靜態路由就是在路由器上配置一條條規則，維護路由表。能夠經過route命令和ip route命令查看進行靜態路由的查詢和配置。 動態路由使用動態路由路由器，根據路由協議算法生成動態路由表，隨網絡運行狀況的變化而變化。動態路由協議算法也涉及兩大類，第一大類算法稱爲距離矢量路由（distance vector routing）適用於小型網絡，最先的路由協議RIP採用該算法，第二大類算法是鏈路狀態路由（link state routing）。內部網關協議採用基於鏈路狀態路由算法的OSPF（Open Shortest Path First，開放式最短路徑優先），網絡的路由協議是基於距離矢量路由算法的BGP(Border Gateway Protocol)。BGP分爲兩類，eBGP和iBGP。對於網絡包，每一個數據中心有本身的規則，網絡中這種不一樣規則所構成的網絡包爲自治系統AS(Autonomous System)。自治系統間邊界路由器使用eBGP廣播路由，內部運行iBGP，讓內部路由器快速找到到達外網目的的最好的邊界路由器。路由器之間信息交換使用的協議，RIP使用UDP協議，OSPF直接發送IP包，而BGP使用的是TCP協議，路由之間會創建TCP鏈接，每60s發送一次keep-alive 消息。此外HTTP 1.1默認keep-alive是開啓的。這樣網絡包就像跳方格同樣跳了多個（也許是一個）路由器以後，終於找到了目的IP地址所在的網關。

step8：找到目的IP地址後，網關取下MAC頭，將IP包發送給目的主機的網絡層，檢查IP地址是否對上

目的IP地址所在的網關接收到網絡包後，發如今同一個網段內， 將包收入，而後發送給目的主機，目的主機取下MAC頭，判斷一下MAC地址和本身的相符，而後將IP包傳給網絡層，網絡層取下IP包頭,查看IP地址和本身的IP地址是否對上。

step9：IP地址對上以後，網絡層將包傳遞給傳輸層，TCP發確認包，會延剛纔的方向報平安，直到收到平安到達的回覆，進行TCP握手

網絡層數判斷IP地址對上以後，根據IP頭中的協議項，知道本身上層還須要TCP協議，將包傳遞給傳輸層，目的主機的內核開啓，當目的主機有了IP的端口號，就能夠調用listen函數進行監聽(TCP和UDP都是基於 Socket, 而 listen函數 是Socket裏的函數，有關 Socket 這裏不詳細解說)，目的主機處於LISTEN狀態。傳輸層在收到TCP請求段後，會發送ACK包確認到達，此時目的主機處於SYN-RCVD狀態，發送的網絡包延剛纔的路徑傳回，瀏覽器在接收到目的主機發送的SYN,ACK後進入ESTABLISHED狀態，同時再發出ACK，當目的主機接收到ACK後也進入ESTABLISHED狀態，此時TCP三次握手完成。

step10：TCP收到回覆後，進行目的端口匹配，將包內容傳給HTTP服務，RPC統籌處理請求，告訴相關進程

TCP三次握手完成後，進行目的端口匹配，以後將包內容傳給上層的HTTP服務，RPC統籌處理，告訴相關進程（Soket多是進程在維護也多是線程在維護監聽，而且TCP每每會創立兩個Socket，一個叫作就監聽Socket，一個是已鏈接Socket，這裏不詳細講述)。

step11：RPC處理完畢，會回覆一個HTTP/HTTPS包告知操做成功，準備向接收端傳輸處理結果

在RPC處理完畢後，目的主機開始向接收方發送數據。在鏈接創建的時候，兩方已商定起始ID，但數據的發送不是一個發送完等回覆後再發送另外一個，而是經過累計確認或者叫累計應答（cumulative acknowledgment） 的模式進行傳輸，即在應答某個以前的ID表示都收到了。這樣TCP須要雙方有緩存進行記錄，發送方的記錄分四部分：第一部分是發送了而且已確認，第二部分是發送了而且還沒有確認，第三部分是沒有發送但在等待發送，第四部分是沒有發送暫時也不會發送。第一部分和第二部分的分界線是lastByteAcked，第二部分和第三部分的分界線是lastByteSent，整個第二部分和第三部分的和 Advertised window 。 瀏覽器做爲接收端在TCP報文裏是會告訴發送端這個窗口大小的，超過了這個窗口的包，接收端沒法接收就會丟棄。（有關接收方的窗口說明詳情可自行查詢）

step 12: TCP慢啓動，以後開始進行數據傳輸，並隨時監測窗口大小進行流量控制和擁塞控制

雖然瀏覽器做爲接收方告訴了發送方窗口大小，但網絡是瞬息萬變的，也許這會網絡變差了或者網段了，那麼TCP在一開始的時候，爲了不形成通道容量溢出，一條TCP鏈接後，設置只能發送一個報文段cwnd(congestion window 擁塞窗口)設置爲1，在收到一個確認後，cwnd加一，一次可以發送兩個，當這兩個報文段的確認到來的時候，每一個cwnd都加一，這樣兩個cwnd就加二，一次就能發四個，開始呈現指數級增加。當一次發送超過ssthresh的值時表明快要溢出，此時cwnd改成增長1/cwnd，一輪下來增加一個......這是有關傳輸過程當中的擁塞控制，關於擁塞控制仍有一些問題存在，具體的流程可自查詢相關的流量控制和擁塞控制。

step 13:接收方瀏覽器接收到數據後，開始進行處理，逐漸在瀏覽器上顯示

經過數據的傳輸，接收端接收到了來自發送方的網絡包，當接收到一個網絡包時，TCP最終將包傳遞給瀏覽器，讓瀏覽器處理HTTP應答報文，這樣隨着應答報文的數量增長，網頁中的內容也會逐漸的顯示在瀏覽器上。

step 14: 數據傳輸完成，進行鏈接斷開，四次揮手說再見

數據終於傳輸完成，到了該斷開的時候。但咱們知道TCP是可靠的傳輸鏈接，是相對靠譜的，那做爲靠譜的協議在斷開的時候不能說斷開就斷開，而且TCP是全雙工的，因此接收端和發送端須要各自斷開。數據傳輸完畢時，服務器和瀏覽器做爲發送方和接收方都處於ESTABLISHED狀態，此時服務器知道數據已傳輸完畢，準備斷開，就向接收方發送FIN報文，進入FIN-WAIT-1狀態；接收方收到FIN報文後，向發送方發送ACK，進入CLOSED-WAIT狀態；服務端收到ACK後從FIN-WAIT-1狀態進入FIN-WAIT-2狀態；接收方進入CLOSED-WAIT狀態結束後再向發送方發送FIN,ACK ,並進入LAST-ACK狀態；發送方接收到FIN、ACK後從FIN-WAIT-2狀態進入TIME-WAIT狀態(等待2MSL)，而且發送ACK；接收方接收到ACK後進入CLOSED狀態；服務端等待2MSL(MSL: Maximum Segment Lifetime ,報文最大生成時間)後也進入CLOSED狀態。至此，創建的鏈接已經各自斷開，整個鏈接過程結束。

爲了更好的理解TCP三次握手和四次揮手，附上TCP狀態機 

 

TCP狀態機.jpg

 

以HTTP爲例講述了網絡的鏈接過程，其它協議與此大同小異，如果基於UDP的協議會在上述步驟中簡化不少，數據傳輸中的socket維護也相對簡單。以上就是網絡的鏈接過程。