http相關的東西也寫了好幾篇了，但是一直都在涉及http周邊的東西，最核心最底層的沒有涉及到。本篇就要揭開網路請求的神祕面紗，將最底層的東西以最簡單的方式呈現給大家。

那就得先講講OSI七層模型，OSI（Open System Interconnect），即開放式系統互聯。 一般都叫OSI參考模型，是ISO（國際標準化組織）組織在1985年研究的網路互連模型。

有了上面這張圖，相信大家對網路架構有了基本的認識了吧。

然後http並不是建立在OSI這個開放式系統互聯架構上的，為什麼呢？因為太複雜了。http建立在TCP/IP模型之上，TCP/IP模型相對於OSI模型來說就簡單很多了。下面是一張對比圖：

是不是覺得清爽了很多。下面詳細講解下TCP/IP各層的作用：
　1、主機到網路層　　
　　實際上TCP/IP參考模型沒有真正描述這一層的實現，只是要求能夠提供給其上層-網路互連層一個訪問介面，以便在其上傳遞IP分組。由於這一層次未被定義，所以其具體的實現方法將隨著網路型別的不同而不同。　　
　　2、網路互連層　　
　　網路互連層是整個TCP/IP協議棧的核心。它的功能是把分組發往目標網路或主機。同時，為了儘快地傳送分組，可能需要沿不同的路徑同時進行分組傳遞。因此，分組到達的順序和傳送的順序可能不同，這就需要上層必須對分組進行排序。　　
　　網路互連層定義了分組格式和協議，即IP協議（Internet Protocol）。　　
　　網路互連層除了需要完成路由的功能外，也可以完成將不同型別的網路（異構網）互連的任務。除此之外，網路互連層還需要完成擁塞控制的功能。　　
　　3、傳輸層　　
　　在TCP/IP模型中，傳輸層的功能是使源端主機和目標端主機上的對等實體可以進行會話。在傳輸層定義了兩種服務質量不同的協議。即：傳輸控制協議TCP（transmission control protocol）和使用者資料報協議UDP（user datagram protocol）。　　
　　TCP協議是一個面向連線的、可靠的協議。它將一臺主機發出的位元組流無差錯地發往網際網路上的其他主機。在傳送端，它負責把上層傳送下來的位元組流分成報文段並傳遞給下層。在接收端，它負責把收到的報文進行重組後遞交給上層。TCP協議還要處理端到端的流量控制，以避免緩慢接收的接收方沒有足夠的緩衝區接收發送方傳送的大量資料。　　
　　UDP協議是一個不可靠的、無連線協議，主要適用於不需要對報文進行排序和流量控制的場合。　　
　　4、應用層　　
　　TCP/IP模型將OSI參考模型中的會話層和表示層的功能合併到應用層實現。　　
　　應用層面向不同的網路應用引入了不同的應用層協議。其中，有基於TCP協議的，如檔案傳輸協議（File Transfer Protocol，FTP）、虛擬終端協議（TELNET）、超文字連結協議（Hyper Text Transfer Protocol，HTTP），也有基於UDP協議的。
整個網路應用架構就是這樣，現在我們就來詳細看下，當我們發起一個http請求到底做了什麼？
1.DNS解析
當我們在位址列輸入網站，按下回車後，會通過DNS解析獲取網址的IP地址，通過IP定址知道對應伺服器的地址。如果不是第一次請求的網址，則從DNS快取中獲取對應的IP地址。
2、建立TCP連線
在HTTP工作開始之前，Web瀏覽器首先要通過網路與Web伺服器建立連線，該連線是通過TCP來完成的，該協議與IP協議共同構建Internet，即著名的TCP/IP協議族，因此Internet又被稱作是TCP/IP網路。HTTP是比TCP更高層次的應用層協議，根據規則，只有低層協議建立之後才能，才能進行更層協議的連線，因此，首先要建立TCP連線，一般TCP連線的埠號是80。
3、Web瀏覽器向Web伺服器傳送請求命令
一旦建立了TCP連線，Web瀏覽器就會向Web伺服器傳送請求命令。例如：GET/sample/hello.jsp HTTP/1.1。
4、Web瀏覽器傳送請求頭資訊
瀏覽器傳送其請求命令之後，還要以頭資訊的形式向Web伺服器傳送一些別的資訊，之後瀏覽器傳送了一空白行來通知伺服器，它已經結束了該頭資訊的傳送。
5、web伺服器應答
客戶機向伺服器發出請求後，伺服器會客戶機回送應答， HTTP/1.1 200 OK ，應答的第一部分是協議的版本號和應答狀態碼。
6、 Web伺服器傳送應答頭資訊
正如客戶端會隨同請求傳送關於自身的資訊一樣，伺服器也會隨同應答向用戶傳送關於它自己的資料及被請求的文件。
7、 Web伺服器向瀏覽器傳送資料
Web伺服器向瀏覽器傳送頭資訊後，它會發送一個空白行來表示頭資訊的傳送到此為結束，接著，它就以Content-Type應答頭資訊所描述的格式傳送使用者所請求的實際資料。
8、Web伺服器關閉TCP連線
一般情況下，一旦Web伺服器向瀏覽器傳送了請求資料，它就要關閉TCP連線，然後如果瀏覽器或者伺服器在其頭資訊加入了這行程式碼：
Connection:keep-alive
TCP連線在傳送後將仍然保持開啟狀態，於是，瀏覽器可以繼續通過相同的連線傳送請求。保持連線節省了為每個請求建立新連線所需的時間，還節約了網路頻寬。
從3往後都是我之前分享過的內容，這裡就不再重複了。現在主要講下1和2。
DNS（Domain Name System，域名系統），因特網上作為域名和IP地址相互對映的一個分散式資料庫，能夠使使用者更方便的訪問網際網路，而不用去記住能夠被機器直接讀取的IP數串。通過主機名，最終得到該主機名對應的IP地址的過程叫做域名解析（或主機名解析）。DNS協議執行在UDP協議之上，使用埠號53。在RFC文件中RFC 2181對DNS有規範說明，RFC 2136對DNS的動態更新進行說明，RFC 2308對DNS查詢的反向快取進行說明。
DNS解析實際上就是把你輸入的網址例如www.baidu.com，解析成實際的伺服器的IP地址，然後通過IP定址找到伺服器，建立連線。負載均衡的實現裡面就有通過DNS伺服器實現負載均衡的方案。
建立TCP連線，這裡有一個繞不過的流程是TCP三次握手和四次分手，如下圖：

第一次握手：建立連線。客戶端傳送連線請求報文段，將SYN位置為1，Sequence Number為x；然後，客戶端進入SYN_SEND狀態，等待伺服器的確認；
第二次握手：伺服器收到SYN報文段。伺服器收到客戶端的SYN報文段，需要對這個SYN報文段進行確認，設定Acknowledgment Number為x+1(Sequence Number+1)；同時，自己自己還要傳送SYN請求資訊，將SYN位置為1，Sequence Number為y；伺服器端將上述所有資訊放到一個報文段（即SYN+ACK報文段）中，一併傳送給客戶端，此時伺服器進入SYN_RECV狀態；
第三次握手：客戶端收到伺服器的SYN+ACK報文段。然後將Acknowledgment Number設定為y+1，向伺服器傳送ACK報文段，這個報文段傳送完畢以後，客戶端和伺服器端都進入ESTABLISHED狀態，完成TCP三次握手。
第一次分手：主機1（可以使客戶端，也可以是伺服器端），設定Sequence Number和Acknowledgment Number，向主機2傳送一個FIN報文段；此時，主機1進入FIN_WAIT_1狀態；這表示主機1沒有資料要傳送給主機2了；
第二次分手：主機2收到了主機1傳送的FIN報文段，向主機1回一個ACK報文段，Acknowledgment Number為Sequence Number加1；主機1進入FIN_WAIT_2狀態；主機2告訴主機1，我“同意”你的關閉請求；
第三次分手：主機2向主機1傳送FIN報文段，請求關閉連線，同時主機2進入LAST_ACK狀態；
第四次分手：主機1收到主機2傳送的FIN報文段，向主機2傳送ACK報文段，然後主機1進入TIME_WAIT狀態；主機2收到主機1的ACK報文段以後，就關閉連線；此時，主機1等待2MSL後依然沒有收到回覆，則證明Server端已正常關閉，那好，主機1也可以關閉連線了。
好了以上就是TCP連線建立和斷開過程。整個http請求從輸入網站到斷開連線的整個過程就是這樣，如果想要詳細瞭解的童鞋，不妨參考下這篇文章，裡面的內容也很詳實，如果兩篇結合起來，你會有更好的收貨。