從一個HTTP請求來讀懂HTTP、TCP協(xié)議
從一個HTTP請求來看網(wǎng)絡(luò)分層原理
兩臺主機間會通過非常多網(wǎng)絡(luò)設(shè)備，不管哪個網(wǎng)絡(luò)設(shè)備都會發(fā)生數(shù)據(jù)丟失，如果發(fā)生數(shù)據(jù)丟失的話，會發(fā)生數(shù)據(jù)重傳，會出現(xiàn)數(shù)據(jù)重復(fù)(之前丟失的包并不是丟失而是產(chǎn)生了延時)。數(shù)據(jù)傳輸?shù)慕橘|(zhì)也可能多樣，如內(nèi)網(wǎng)里通過網(wǎng)線進行傳輸，連接到公網(wǎng)的話會通過光纖進行連接，所以要實現(xiàn)不同介質(zhì)間信號的轉(zhuǎn)換，還有從光纖到路由器無線脈沖轉(zhuǎn)換，距離遠的話還有信號衰減問題。所以在網(wǎng)絡(luò)傳輸過程中有非常多的問題需要解決，把問題分組分層，不同層次間解決不同問題，不同層次間定義標準化接口讓它們間可以進行數(shù)據(jù)的通信。
復(fù)雜的網(wǎng)絡(luò)
為了簡化網(wǎng)絡(luò)的復(fù)雜度，網(wǎng)絡(luò)通信的不同方面被分解為多層次結(jié)構(gòu)，每一層只與緊挨著的上層或者下層進行交互，將網(wǎng)絡(luò)分層，這樣就可以修改，甚至替換某一層的軟件，只要層與層之間的接口保持不變，就不會影響到其他層。
- OSI( Open System Interconnection Reference Model): 開放系統(tǒng)互聯(lián)參考模型
- TCP/IP 協(xié)議族
OSI七層理論體系結(jié)構(gòu)
- 物理層：解決兩臺主機的通信問題—A往B發(fā)送比特流(0101)，B能接收到這些比特流。定義了物理設(shè)備的標準如網(wǎng)線的類型，光纖的接口類型以及傳輸介質(zhì)的傳輸速率等。
- 數(shù)據(jù)鏈路層：由于物理層上的傳輸?shù)谋忍亓骺赡軙霈F(xiàn)錯傳、誤傳等，所以數(shù)據(jù)鏈路層定義了如何格式化數(shù)據(jù)即將比特流封裝成幀，提供了錯誤檢測。
- 網(wǎng)絡(luò)層：隨著節(jié)點的增加，點對點通信是需要經(jīng)過多個節(jié)點的，如何找到目標節(jié)點，如何找到最優(yōu)路徑變成為了首要需求。所以出現(xiàn)了網(wǎng)絡(luò)層，主要目的是將網(wǎng)絡(luò)地址翻譯成對應(yīng)的物理地址，分組傳輸、路由選擇，本層的傳輸單位是數(shù)據(jù)報(分組)，本層需要注意的TCP/IP協(xié)議中的TCP協(xié)議。
- 傳輸層：隨著網(wǎng)絡(luò)需要的進一步擴大，通信過程中需要傳輸大量的數(shù)據(jù)，網(wǎng)絡(luò)可能會發(fā)生中斷，為了保證傳輸大量文件時的準確性，需要對發(fā)送的數(shù)據(jù)進行切分，切分成一個個的segment進行發(fā)送，考慮如何在接受方拼接切分的segment組成完整的數(shù)據(jù)，以及發(fā)現(xiàn)丟失segment時該如何處理，需要注意的協(xié)議TCP、UDP。
- 會話層：不同機器上的用戶之間建立以及管理會話。用于保證應(yīng)用程序自動收發(fā)包和尋址。
- 表示層：信息的語義語法，加密解密，轉(zhuǎn)換翻譯，壓縮解壓縮。
- 應(yīng)用層：規(guī)定雙方必須使用固定長度的消息頭，且消息頭必須記錄消息長度等信息。需要注意的是TCP/IP協(xié)議中的HTTP協(xié)議。
TCP/IP四層模型
是OSI的一種實現(xiàn)，包括應(yīng)用層、運輸層、網(wǎng)際層和網(wǎng)絡(luò)接口層。
一個HTTP請求的分層解析流程
如上圖右邊一個服務(wù)器部署了一個靜態(tài)頁面，通過nginx部署在公網(wǎng)上，瀏覽器通過域名對它進行訪問，瀏覽器輸入域名點回車后是怎么工作的呢？
- http://www.dumain.com
服務(wù)端只認ip地址，瀏覽器將域名解析出來，看下瀏覽器里有沒有域名對應(yīng)DNS的緩存，有的話直接拿到服務(wù)端的ip地址，沒有的話去本地的host文件看有沒有配置，沒有配置的話才會發(fā)起一個DNS請求用來獲取服務(wù)器ip地址。
DNS也是臺服務(wù)器也有自己的ip地址，這時候應(yīng)用層會構(gòu)造一個DNS請求報文，應(yīng)用層會去調(diào)用傳輸層的接口一個socket的API，DNS默認使用UDP實現(xiàn)數(shù)據(jù)傳輸，即應(yīng)用層調(diào)用傳輸層的API，傳輸層會在DNS請求報文基礎(chǔ)上加一個UDP的請求頭，傳輸層將數(shù)據(jù)交給網(wǎng)絡(luò)層，網(wǎng)絡(luò)層同樣在UDP請求報文基礎(chǔ)上加IP的請求頭，網(wǎng)絡(luò)層會將IP請求報文交給數(shù)據(jù)鏈路層，數(shù)據(jù)鏈路層會將自己的mac頭加上去并把對應(yīng)的請求報文交給下一個機器的mac地址也會加上去，下一個機器的mac地址通過網(wǎng)絡(luò)層ARP協(xié)議找到，ARP會發(fā)送一些請求看下你對應(yīng)的ip地址的mac地址是多少，最后通過物理層物理介質(zhì)傳出去，通常傳到路由器上.
路由器是三層設(shè)備(從下向上)從物理層開始連接，物理層交給數(shù)據(jù)鏈路層，數(shù)據(jù)鏈路層看下地址是不是給我的，是給我的進行解析，不是給我的就丟棄，報文再傳給上面一層網(wǎng)絡(luò)層，網(wǎng)絡(luò)層把數(shù)據(jù)傳到下一個路由器的地址是多少，會通過運營商的網(wǎng)絡(luò)接口傳到運營商的路由器上，運營商有自己的DNS服務(wù)器，如果配置的是運營商自己的DNS服務(wù)器的話會直接在這個DNS服務(wù)器里找自己對應(yīng)的域名拿到對應(yīng)的ip地址，也就是剛請求DNS報文地址，然后原路返回解析直到應(yīng)用層拿到剛域名對應(yīng)的ip地址，這樣就可以進行HTTP請求報文的發(fā)送，再調(diào)用傳輸層協(xié)議是TCP參數(shù)，同樣每到一層加頭。
HTTP
什么是HTTP?
超文本傳輸協(xié)議，是一個基于請求與響應(yīng)，無狀態(tài)的，應(yīng)用層的協(xié)議，常基于TCP/IP協(xié)議傳輸數(shù)據(jù)，互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議,所有的WWW文件都必須遵守這個標準。設(shè)計HTTP的初衷是為了提供一種發(fā)布和接收HTML頁面的方法。
HTTP特點
- 無狀態(tài)：協(xié)議對客戶端沒有狀態(tài)存儲，對事物處理沒有“記憶”能力，比如訪問一個網(wǎng)站需要反復(fù)進行登錄操作。
- 無連接：HTTP/1.1之前，由于無狀態(tài)特點，每次請求需要通過TCP三次握手四次揮手，和服務(wù)器重新建立連接。比如某個客戶機在短時間多次請求同一個資源，服務(wù)器并不能區(qū)別是否已經(jīng)響應(yīng)過用戶的請求，所以每次需要重新響應(yīng)請求，需要耗費不必要的時間和流量。
- 基于請求和響應(yīng)：基本的特性，由客戶端發(fā)起請求，服務(wù)端響應(yīng)。
- 簡單快速、靈活。
- 通信使用明文、請求和響應(yīng)不會對通信方進行確認、無法保護數(shù)據(jù)的完整性。
HTTP協(xié)議版本已經(jīng)演化到3.0版本，關(guān)于協(xié)議版本可以查看 快速掌握HTTP1.0 1.1 2.0 3.0的特點及其區(qū)別
HTTP報文格式
HTTP 協(xié)議的請求報文和響應(yīng)報文的結(jié)構(gòu)基本相同，由三大部分組成:
- 起始行(start line)：描述請求或響應(yīng)的基本信息
- 頭部字段集合(header)：使用 key-value 形式更詳細地說明報文
- 消息正文(entity)：實際傳輸?shù)臄?shù)據(jù)，它不一定是純文本，可以是圖片、視頻等二進制數(shù)據(jù)
其中起始行和頭部的字段并成為 請求頭 或者 響應(yīng)頭，統(tǒng)稱為 Header;消息正文也叫實體，稱為 body。HTTP 協(xié)議規(guī)定每次發(fā)送的報文必須要有 Header，但是可以沒有 body，也就是說頭信息是必須的，實體信息可以沒有。而且在 header 和 body 之間必須要有一個空行(CRLF)。
請求行報文格式
- 請求方法:如 GET/HEAD/PUT/POST，表示對資源的操作;
- 請求目標:通常是一個 URI，標記了請求方法要操作的資源;
- 版本號:表示報文使用的 HTTP 協(xié)議版本。
響應(yīng)報文格式
- 版本號:表示報文使用的 HTTP 協(xié)議版本;
- 狀態(tài)碼:一個三位數(shù)，用代碼的形式表示處理的結(jié)果，比如 200 是成功，500 是服務(wù)器錯誤;
- 原因:作為數(shù)字狀態(tài)碼補充，是更詳細的解釋文字，幫助人理解原因。
請求及響應(yīng)報文格式對比
HTTP 頭字段
頭部字段是 key-value 的形式，key 和 value 之間用“:”分隔，最后用 CRLF 換行表示字
段結(jié)束。比如前后分離時經(jīng)常遇到的要與后端協(xié)商傳輸數(shù)據(jù)的類型“Content-type: application/json”，這里 key 就是“Content-type”，value 就 是“application/json”。HTTP 頭字段非常靈活，不僅可以使用標準里的 Host、 Connection 等已有頭，也可以任意添加自定義頭，這就給 HTTP 協(xié)議帶來了無限的擴展可能。
頭字段注意事項
- 字段名不區(qū)分大小寫，字段名里不允許出現(xiàn)空格，可以使用連字符“-”，但不
- 能使用下劃線“_”(有的服務(wù)器不會解析帶“_”的頭字段)。字段名后面必須緊接 著“:”，不能有空格，而“:”后的字段值前可以有多個空格;
- 字段的順序是沒有意義的，可以任意排列不影響語義;
- 字段原則上不能重復(fù)，除非這個字段本身的語義允許，例如 Set-Cookie。
HTTP 協(xié)議中有非常多的頭字段，但基本上可以分為四大類：通用標頭、實體標頭、請求標頭、響應(yīng)標頭。
HTTP 頭字段更多內(nèi)容請查看《深入掌握HTTP四種標頭基本概念 》
TCP 協(xié)議
TCP(Transmission Control Protocol)，傳輸控制協(xié)議：面向連接的，可靠的，基于字節(jié)流的傳輸層通信協(xié)議。它能幫助你確定計算機連接到 Internet 以及它們之間的數(shù)據(jù)傳輸。通過三次握手來建立 TCP 連接，三次握手就是用來啟動和確認 TCP 連接的過程。一旦連接建立后，就可以發(fā)送數(shù)據(jù)了，當數(shù)據(jù)傳輸完成后，會通過關(guān)閉虛擬電路來斷開連接。
TCP特點
- 基于連接的：數(shù)據(jù)傳輸之前需要建立連接
- 全雙工的：雙向傳輸
- 字節(jié)流：不限制數(shù)據(jù)大小，打包成報文段，保證有序接收，重復(fù)報文自動丟棄
- 流量緩沖：解決雙方處理能力的不匹配
- 可靠的傳輸服務(wù)：保證可達，丟包時通過重發(fā)機制實現(xiàn)可靠性
- 擁塞控制：防止網(wǎng)絡(luò)出現(xiàn)惡性擁塞
TCP報文格式
- 16位源端口/16位目的端口：負責(zé)實現(xiàn)應(yīng)用程序之間的數(shù)據(jù)傳輸
- 32位序號/32位確認序號：用于實現(xiàn)tcp在傳輸層的包序管理——tcp有序交付數(shù)據(jù)
- 4位頭部長度：以4個字節(jié)為單位;4位保存的最大數(shù)字是15;因此tcp報頭最大長度是15*4=60個字節(jié)
- 6位保留位;
- 6位標志：
- URG——緊急指針標志
- ACK——確認回復(fù)標志
- PSH——提示立即接受位
- RST——重置連接位
- SYN——連接建立請求位
- FIN——斷開連接請求位
- 16位窗口大?。?/strong>滑動窗口機制–>流量控制–>告訴對端所能發(fā)送的最大數(shù)據(jù)量
- 校驗和：二進制反碼求和–>校驗數(shù)據(jù)一致性
- 緊急指針：指明哪些數(shù)據(jù)是緊急數(shù)據(jù)
- 選項數(shù)據(jù)：三次握手時，協(xié)商MSS大小的數(shù)據(jù)
TCP連接:四元組[ 源地址， 源端口， 目的地址， 目的端口 ]
TCP三次握手
同步通信雙方初始序列號( ISN, initial sequence number )
協(xié)商TCP通信參數(shù)(MSS, 窗口信息，指定校驗和算法)
在了解具體流程之前，我們先認識幾個概念
最初兩端的TCP進程都處于CLOSED關(guān)閉狀態(tài)，A主動打開連接，而B被動打開連接。
A、B關(guān)閉狀態(tài)CLOSED — B收聽狀態(tài)LISTEN — A同步已發(fā)送狀態(tài)SYN-SENT — B同步收到狀態(tài)SYN-RCVD— A、B連接已建立狀態(tài)ESTABLISHED
B的TCP服務(wù)器進程先創(chuàng)建傳輸控制塊TCB，準備接受客戶進程的連接請求。然后服務(wù)器進程就處于LISTEN(收聽)狀態(tài)，等待客戶的連接請求。若有，則作出響應(yīng)。
- SYN：它的全稱是 Synchronize Sequence Numbers ，同步序列編號。是 TCP/IP 建立連接時使用的握手信號。在客戶機和服務(wù)器之間建立 TCP 連接時，首先會發(fā)送的一個信號?？蛻舳嗽诎l(fā)送 SYN 消息時，就會在自己的段內(nèi)生成一個隨機值 X。
- SYN-ACK：服務(wù)器收到 SYN 后，應(yīng)答客戶端連接，發(fā)送一個 SYN-ACK作為答復(fù)。確認號設(shè)置為比接收到的序列號多一個，即 X + 1，服務(wù)器為數(shù)據(jù)包選擇的序列號是另一個隨機數(shù) Y。
- ACK： Ackowledge character ，確認字符，表示發(fā)來的數(shù)據(jù)已確認接收無誤。最后客戶端將 ACK 發(fā)送給服務(wù)器。序列號被設(shè)置為所接收的確認值即 Y+ 1。
下面通過一個案例看三次握手是怎么進行的
在Nginx服務(wù)器部署一個靜態(tài)頁面(我的端口為：8000)
tcpdump指定網(wǎng)卡進行監(jiān)聽抓取報文
- tcpdump -i en0 -S -c 3 port 8000
在客戶端使用nc網(wǎng)絡(luò)工具發(fā)送一個請求
- nc 192.168.109.200 8000
三次握手監(jiān)聽結(jié)果如下：
內(nèi)核在三次握手做的一些事情，如下：
連接狀態(tài)查看
- netstat -tpn # t:TCP連接裝，p:進程顯示 ，n:數(shù)字形式
- # 每秒查看一次
netstat -tpn -c 1
TCP四次揮手
- A: 發(fā)送FIN數(shù)據(jù)包，代表A不再發(fā)送數(shù)據(jù)
- B: 收到請求，開始應(yīng)答 ，避免了A重新發(fā)送FIN重試(應(yīng)答機制)
- B: 處理完數(shù)據(jù)之后關(guān)閉，關(guān)閉連接,及發(fā)送FIN請求
- A: 收到請求后發(fā)送ACK應(yīng)答，B服務(wù)可以釋放連接
等待 2MSL后釋放連接
- 防止報文丟失，導(dǎo)致B重復(fù)發(fā)送FIN
- 防止滯留在網(wǎng)絡(luò)中的報文，對新建立的連接造成數(shù)據(jù)擾亂
字節(jié)流的協(xié)議
TCP把應(yīng)用交付的數(shù)據(jù)僅僅看成是一連串的無結(jié)構(gòu)的字節(jié)流，TCP并不 知道字節(jié)流的含義，TCP并不關(guān)心應(yīng)用程序一次將多大的報文發(fā)送到 TCP的緩存中，而是根據(jù)對方給出的窗口值和當前網(wǎng)絡(luò)擁堵的程度來決 定一個報文段應(yīng)該包含多少個字節(jié)。
- MSS: Max Segment Size, 默認 536byte 實際數(shù)據(jù)
在網(wǎng)絡(luò)傳輸過程中可能會出現(xiàn)以下的一些情況：
- 客戶端一段時間沒有收到 ack 消息則重傳
- 如果緩沖區(qū)滿了則可能丟包或延時都需要重傳
- 根據(jù)報文 sequeence number 字段重排序，還需要丟棄重復(fù)包。
數(shù)據(jù)傳輸?shù)目煽啃?/span>
停止等待協(xié)議如下：
停止等待協(xié)議，效率比較低
重傳機制如下：
ack 報文丟失
請求報文丟失
滑動窗口協(xié)議與累計確認(延時ack)
如上效率低，所以tcp提出了新的協(xié)議-滑動窗口協(xié)議與累計確認(延時ack)。
滑動窗口大小同通過tcp三次握手和對端協(xié)商，且受網(wǎng)絡(luò)狀況影響。
上面是一個一個報文，實際可發(fā)一批報文，服務(wù)器并不是挨個去確認，上面回一個ack浪費資源，單獨響應(yīng)一個報文時，tcp本身一個報文至少20個字節(jié)再加上ip頭報文20字節(jié)，所以一個ack至少40字節(jié)。
所以延時ack的發(fā)送，如下圖確認最后一個報文如5就可以，但這樣也有一個問題如3的報文丟了，這時只能確認1和2連續(xù)報文，從3以后的報文全要重傳，已確認的報文在緩沖區(qū)丟棄掉。
