轉自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連接不同和詳細的連接過程，后面會單獨寫解釋,接下來看一下網絡的連接。
整體的傳輸流程如下：
首先，機器和人不一樣，並不能識別我們能熟記的域名，機器只認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狀態。
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狀態機
以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連接不同和詳細的連接過程，后面會單獨寫解釋,接下來看一下網絡的連接。
整體的傳輸流程如下：
首先，機器和人不一樣，並不能識別我們能熟記的域名，機器只認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狀態。
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狀態機
以HTTP為例講述了網絡的連接過程，其它協議與此大同小異，若是基於UDP的協議會在上述步驟中簡化很多，數據傳輸中的socket維護也相對簡單。以上就是網絡的連接過程。