前言
網際網路的原始目的，就是為了傳輸文本（文本對話）。那我們使用浏覽器發送請求後頁面是如何呈現在我們面前的呢？ 接下來由圖檔介紹下URL到呈現頁面的過程。
一、文本對話--從請求到響應
我們在浏覽器中輸入一個 URL，回車之後便會在浏覽器中觀察到頁面内容。實際上這個過程是：
（1）浏覽器向網站所在的伺服器發送了一個 Request（請求）
（2）網站伺服器接收到這個Request之後進行處理和解析
（3）然後傳回對應的一個Response（響應）給浏覽器，Response裡面就包含了頁面的源代碼等内容
（4）浏覽器再對其進行解析便将網頁呈現了出來。
這個文本對話的過程是建立在怎樣的規則上面呢？簡單說，這個通信的過程是基于TCP/IP通信協定族規範上實作的，完成從用戶端到伺服器端等一系列資訊交換的流程。
二、TCP/IP 協定族介紹
1、TCP/IP協定族是什麼呢？
TCP/IP協定族的目的就是通過建立規則使計算機之間可以進行資訊交換。
互相通信的雙方就必須基于相同的方法，比如由哪一邊先發起通信、使用哪種語言進行通信、怎樣結束通信等規則都需要事先确定，我們就把這種規則稱為協定（protocol）。通常我們說的TCP/IP協定族是網際網路相關的各類協定族的總稱。
TCP/IP協定族由那麼多的協定組成，那功能上如何劃分的呢？
這裡就說到TCP/IP重要的階層化劃分，按層次可以分為4層：應用層、傳輸層、網絡層和鍊路層。（階層化的好處在于每個層次内部的設計可以自由改動，并通過各層的接口關聯起來，而如果隻有一個協定統籌就需要對所有涉及到的部分都重新設計。）
2、TCP/IP各功能層的作用
（1） 應用層：決定了向使用者提供應用服務時候的通信活動。應用層負責傳送各種最終形态的資料，是直接與使用者打交道的層，典型協定是HTTP、FTP等。
（2） 傳輸層：負責傳送文本資料。傳輸層有兩個性質不同的協定： TCP（Transmission Control Protocol，傳輸控制協定）和 UDP（User Data Protocol，使用者資料報協定）。
（3） 網絡層：負責配置設定位址和傳送二進制資料，主要協定是IP協定；
（4） 鍊路層：負責建立電路連接配接，是整個網絡的實體基礎，典型的協定包括以太網、ADSL等。
3、TCP/IP 通信傳輸流
在TCP/IP各功能層之間資料是如何流動傳輸的呢？
（1）首先作為發送端的用戶端在應用層（HTTP 協定）發出的
HTTP請求（如：想浏覽www.baidu.com），并生成HTTP封包。
（2）為了傳輸友善，在傳輸層（TCP 協定）把從應用層處收到的資料（HTTP 請求封包）進行分割，并在
各個封包上打上标記序号及端口号後轉發給網絡層。
（3）在網絡層（IP 協定），增加作為通信目的地的 MAC 位址後轉發給鍊路層。
（4）給這些資料附加上以太網首部并進行發送處理，生成的以太網資料包将通過實體層傳輸給接收端。
（5）接收端的伺服器在鍊路層接收到資料，按序往上層發送，一直到應用層。當傳輸到應用層，才能算真正接收到由用戶端發送過來的 HTTP 請求。
在通信過程每經過一層時必定會被打上一個該層所屬的首部資訊。反之，接收端在層與層傳輸資料時，每經過一層時會把對應的首部消去。
三、基于TCP/IP通信過程
一張圖來說明請求到網頁呈現的通信過程（ 下圖基于IP 協定、TCP
協定 、DNS 服務和HTTP 協定的通信過程），并對每一步做說明：
1、浏覽器輸入URL發送請求
URL（Uniform Resource Locator，統一資源定位符），是使用 Web 浏覽器等通路 Web 頁面時需要輸入的網頁位址。
（1） 傳送協定：http:或者https:等
（2） 層級URL标記符号：為“//”固定不變
（3） 登入資訊： 通路資源需要的憑證資訊（可省略）
（4） 伺服器位址：通常為域名，有時為IP位址（實際通信中需要通過IP位址通路，域名通過DNS伺服器解析出IP位址）
（5） 端口号：以數字方式表示，若為HTTP的預設值“:80”可省略
（6） 路徑：以“/”字元差別路徑中的每一個目錄名稱
（7） 查詢：GET模式的窗體參數，以“?”字元為起點，每個參數以“&”隔開，再以“=”分開參數名稱與資料，通常以UTF8的URL編碼，避開字元沖突的問題
（8） 片段：以“#”字元為起點，使用片段辨別符通常可标記出已擷取資源中的子資源
2、DNS對請求中的URL域名解析
DNS（Domain Name System）服務是和 HTTP協定一樣位于應用層的協定，它提供域名到 IP 位址之間的解析服務。
計算機既可以被賦予IP位址，也可以被賦予主機名和域名，使用者通常使用主機名或域名來通路對方的計算機，而不是直接通過 IP 位址通路。而計算機相對更容易處理一組數字，這時DNS域名解析服務應運而生。DNS 協定提供通過域名查找 IP 位址（或逆向從 IP 位址反查域名的服務）。
3、HTTP協定生成請求封包
HTTP協定：HyperText Transfer Protocol超文本傳輸協定位于應用層，決定從用戶端到伺服器端等一系列通信内容及方式，這通過生成封包并發送完成通信。
（1）請求封包的構成
（2）響應封包的構成
4、TCP協定提供可靠的位元組流傳輸服務
TCP協定：Transmission Control Protocol傳輸控制協定，位于傳輸層。
（1）位元組流服務（Byte Stream Service）是指，為了友善傳輸，将大塊資料分割成以封包段（segment）
為機關的資料包進行管理。
（2）可靠的傳輸服務是指，能夠把資料準确可靠地傳給對方。TCP 協定采用了三次握手連接配接等政策保證傳輸的可靠性（三次握手，四次揮手文末會有重點補充）
5、IP協定實作資料傳遞到對方計算機
IP（Internet Protocol）網際協定位于網絡層。 IP協定的作用在于實作資料包傳遞到對方計算機IP位址。而IP間的通信依賴于MAC 位址（網卡所屬的固定位址），還需要再通過ARP 協定根據通信方的 IP 位址反查出對應的MAC 位址。
6、接收并解析請求封包後回傳響應封包
接收端（伺服器）響應封包同樣利用TCP/IP通信協定回傳
四、TCP建立連接配接及斷開（重點補充）
TCP建立連接配接（3次握手）
TCP 提供面向有連接配接的通信傳輸，面向有連接配接是指在資料通信開始之前先做好兩端之間的準備工作。
三次握手是指建立一個TCP連接配接時需要用戶端和伺服器端總共發送三個标記包以确認連接配接的建立。下面來看看三次握手的流程圖：
第一次握手：用戶端将标志位SYN置為1，随機産生一個值seq=J，并将該資料包發送給伺服器端，用戶端進入SYN_SENT狀态，等待伺服器端确認。
第二次握手：伺服器端收到資料包後由标志位SYN=1知道用戶端請求建立連接配接，伺服器端将标志位SYN和ACK都置為1，ack=J+1，随機産生一個值seq=K，并将該資料包發送給用戶端以确認連接配接請求，伺服器端進入SYN_RCVD狀态。
第三次握手：用戶端收到确認後，檢查ack是否為J+1，ACK是否為1，如果正确則将标志位ACK置為1，ack=K+1，并将該資料包發送給伺服器端，伺服器端檢查ack是否為K+1，ACK是否為1，如果正确則連接配接建立成功，用戶端和伺服器端進入ESTABLISHED狀态，完成三次握手建立連接配接，随後用戶端與伺服器端之間可以開始傳輸資料了。
為什麼3次握手: 前兩次的握手很顯然是必須的，主要是最後一次，即用戶端收到服務端發來的确認後為什麼還要想服務端再發送一次确認呢？這主要是為了防止已失效的請求封包段突然又傳送到了服務端而産生連接配接的誤判。
考慮如下的情況：
用戶端發送了一個連接配接請求封包段到服務端，但是在某些網絡節點上長時間滞留了，是以用戶端又逾時重發了一個連接配接請求封包段該服務端，而後正常建立連接配接，資料傳輸完畢，并釋放了連接配接。
如果這時候第一次發送的請求封包段（已過期的）延遲了一段時間後，又到了服務端，很顯然，這本是一個早已失效的封包段，但是服務端收到後會誤以為用戶端又發出了一次連接配接請求，于是向用戶端發出确認封包段，并同意建立連接配接。假設不采用三次握手，這時服務端隻要發送了确認，新的連接配接就建立了。但由于用戶端現階段沒有發出建立連接配接的請求，是以不會理會服務端的确認，也不會向服務端發送資料，而服務端卻認為新的連接配接已經建立了，并在一直等待用戶端發送資料，這樣服務端就會一直等待下去，直到超出保活計數器的設定值，而将用戶端判定為出了問題，才會關閉這個連接配接。這樣就浪費了很多伺服器的資源。而如果采用三次握手，用戶端沒有再向服務端發出确認，服務端由于收不到确認，就知道用戶端沒有要求建立連接配接，進而不建立該連接配接。
TCP斷開連接配接（4次揮手）
TCP連接配接是全雙工的，是以，每個方向都必須要單獨進行關閉，
四次揮手即終止TCP連接配接，就是指斷開一個TCP連接配接時，需要用戶端和服務端總共發送4個包以确認連接配接的斷開。
下面來看看四次揮手的流程圖：
注：中斷連接配接端可以是用戶端，也可以是伺服器端。下文舉的例子是以用戶端發出中斷請求。
第一次揮手：用戶端發送一個FIN=M，用來關閉用戶端到伺服器端的資料傳送，用戶端進入FIN_WAIT_1狀态。意思是說"我用戶端沒有資料要發給你了"，但是如果你伺服器端還有資料沒有發送完成，則不必急着關閉連接配接，可以繼續發送資料。
第二次揮手：伺服器端收到FIN後，先發送ack=M+1，告訴用戶端，“你的請求我收到了，但是我還沒準備好，請繼續你等我的消息。”這個時候用戶端就進入FIN_WAIT_2狀态，繼續等待伺服器端的FIN封包。
第三次揮手：當伺服器端确定資料已發送完成，則向用戶端發送FIN=N封包，告訴用戶端，好了，我這邊資料發完了，準備好關閉連接配接了。伺服器端進入LAST_ACK狀态。
第四次揮手：用戶端收到FIN=N封包後，就知道可以關閉連接配接了，但是他還是不相信網絡，怕伺服器端不知道要關閉，是以發送ACK=1，ack=N+1後進入TIME_WAIT狀态，如果伺服器端沒有收到ACK則可以重傳。伺服器端收到ACK後，就知道可以斷開連接配接了（CLOSED狀态）。用戶端等待了2MSL（時間MSL叫做最長封包壽命，RFC建議設為2分鐘）後依然沒有收到回複，則證明伺服器端已正常關閉，用戶端也可以關閉連接配接了。最終完成了四次握手。
為什麼4次揮手：TCP協定是一種面向連接配接的、可靠的位元組流的運輸層通信協定，TCP是全雙工模式，這就意味着，當用戶端發出FIN封包段時，隻是表示用戶端已經沒有資料要發送了，用戶端告訴伺服器，它的資料已經全部發送完畢了；但是，這個時候用戶端還是可以接受來自伺服器的資料；當伺服器傳回ACK封包段時，表示它已經知道用戶端沒有資料發送了，但是主機2還是可以發送資料到用戶端的；當伺服器也發送了FIN封包段時，這個時候就表示伺服器也沒有資料要發送了，就會告訴用戶端，我也沒有資料要發送了，之後彼此就會愉快的中斷這次TCP連接配接。
為什麼用戶端TIME_WAIT等待2MSL：
（1）為了保證用戶端發送的最後一個ACK封包段能夠到達伺服器。該ACK封包段很有可能丢失，因而使處于在LIST—ACK狀态的伺服器收不到對已發送的FIN+ACK封包段的确認，伺服器可能會重傳這個FIN+ACK封包段，而用戶端就在這2MSL時間内收到這個重傳的FIN+ACK封包段，接着用戶端重傳一次确認，重新啟動2MSL計時器，最後用戶端和伺服器都進入CLOSED狀态。（2）防止已失效的請求連接配接出現在本連接配接中。在連接配接處于2MSL等待時，任何遲到的封包段将被丢棄，因為處于2MSL等待的，由該插口（插口是IP和端口對的意思，socket）定義的連接配接在這段時間内将不能被再用，這樣就可以使下一個新的連接配接中不會出現這種舊的連接配接之前延遲的封包段。
小結
以上，我們了解TCP/IP協定的作用及通信的流程，針對Http協定後續再做詳細介紹。
原文釋出時間為：2018年06月08日
原文作者：Jacky心外無事
本文來源：
掘金 https://juejin.im/entry/5b3a29f95188256228041f46如需轉載請聯系原作者