說到計算機網絡原理，大家可能馬上聯想到，七層協議，傳輸層，鏈路層，三次握手四次揮手；前端的同學，還會想到我們用Crome F12的network里面的headers，狀態碼等。后端同學可能會聯想到，抓包，路由網關等。你們聯想到什么關鍵字，歡迎留言喲！
那么，我們來提出幾個問題：
- 七層協議之間是如何傳輸的？什么是包、幀、段？
- TCP/IP協議是什么？TCP和UPD有什么區別？
- 什么是三次握手四次揮手？為什么要握手和揮手？
- 瀏覽器network的HTTP headers 和 TCP headers有什么區別？
下面，我們就一一回答上面的問題。
七層協議之間是如何傳輸的？什么是包、幀、段？
看上圖，所以數據、段、包、幀、比特，講的其實都是一個東西，只是由於所在的位置不同，作為專有名詞的名字不同。
-
我們先看一下最上層的數據，Data是應用層協議產生的數據，例如訪問網頁、看視頻、聽音樂，這些都可以稱為應用層數據，電腦的操作系統會把這些應用層數據按照一定的規則傳給下一層傳輸層。
-
在傳輸層，我們看到的數據稱之為Segment，中文意思是段。在這一層，數據會被加上TCP或者UDP頭，變成一個應用程序特有的數據。操作系統就是通過TCP或UDP端口號來區別不同應用程序的。
-
當數據再被往下傳輸的時候，就變成了packet，即“包”的意思。在這一層，Segment會被加上IP頭部信息，然后就可以在三層傳輸了，而工作在三層的路由器會根據目的IP地址來轉發這些”包“。
-
在往下，數據就會被加上MAC地址信息，名稱就變成了Frame，”幀“。在這一層，就是交換機的世界了，交換機通常查找MAC地址表項來轉發相應的”幀“。
上面的幾個層次都可以使用wireshark抓包查看到具體的內容，比較形象，例如下面，一層套着一層，明顯可以看出幀、包、段、數據的區別。
那么，不同層之間，是如何通信的呢？
很多人講到七層協議傳輸，會想到教材下圖左，可是這七層是如何一層層互相構成的，更符合大腦感官的是另一種認知形式，是一種洋蔥形的結構，層層疊疊互相包裹，可以用下圖表示：
一層一層傳輸，加上圖一對應的頭部信息，或者mac地址，進行封裝，傳給下一層。具體的也可以看上圖抓包信息。每一層的數據，內容不同，叫不同的名字。
再往下面的物理層（layer1），我們能看到的都是BIT流，它們呈現給我們的都是0和1這樣的電氣特性。他們將數字信號轉化為物理信號，bits 轉化為光信號。網絡延時，一般在這一層，考慮傳輸距離和光速，光纖管道擁塞，包等待，TCP 做 Flow Control（流控），轉化速率等，平常只有那些頭發比較稀少的硬件工程師才關注，咱們一般看不到。工作中我們看到網絡設備的物理層都已經是非常成熟的內容，一般不會有問題。
各位看到這里，應該能夠明白“幀”和“包"區別了吧？其實很多的時候它們就是通用的，只是它們所在的網絡層次不同，封裝也不同。為了顯示專業，一般我們在討論交換機相關的layer2內容時，可以把數據稱之為”幀“，在討論與路由器相關的layer3內容時，就把數據稱之為”包“。他們是如何傳輸的，以上也做了解答。
TCP/IP協議是什么？TCP和UPD有什么區別？
計算機硬件通過網絡通信，雙方就要基於相同的方法。比如，如何探測到通信目標、由哪一邊先發起通信、使用哪種語言進行通信、怎樣結束通信等規則都需要事先確定。不同的硬件、操作系統之間的通信，所有的這一切都需要一種規則。而我們就把這種規則稱為協議（protocol）。
TCP/IP 是互聯網相關的各類協議族的總稱，比如：TCP，UDP，IP，FTP，HTTP，ICMP，SMTP 等都屬於 TCP/IP 族內的協議。
TCP/IP模型是互聯網的基礎，它是一系列網絡協議的總稱。這些協議可以划分為四層，分別為鏈路層、網絡層、傳輸層和應用層。
也就是每一層都有自己的協議，我們前端在瀏覽器調試的是最上層——應用層的HTTP協議，屬於TCP/IP協議的一種。 具體看下圖：
- 應用層：負責向用戶提供應用程序，比如HTTP、FTP、Telnet、DNS、SMTP等。
- 傳輸層：負責對報文進行分組和重組，並以TCP或UDP協議格式封裝報文。
- 網絡層：負責路由以及把分組報文發送給目標網絡或主機。
- 鏈路層：負責封裝和解封裝IP報文，發送和接受ARP/RARP報文等。
傳輸層協議里面有UDP和TCP協議，我們來看看他們具體區別和應用場景。
UDP和TCP協議區別（廣播，一對一）
如上圖：
TCP向上層提供面向連接的可靠服務 ，UDP向上層提供無連接不可靠服務。 雖然 UDP 並沒有 TCP 傳輸來的准確，但是也能在很多實時性要求高的地方有所作為 對數據准確性要求高，速度可以相對較慢的，可以選用TCP 我們在第一部分，說明了，從應用層到傳輸層，會加上UDP/TCP頭，那什么情況加UDP頭，什么情況加UDP頭呢？以下分別進行說明：
UDP
UDP協議全稱是用戶數據報協議，在網絡中它與TCP協議一樣用於處理數據包，是一種無連接的協議UDP有不提供數據包分組、組裝和不能對數據包進行排序的缺點，也就是說，當報文發送之后，是無法得知其是否安全完整到達的。
它有以下幾個特點：
- 面向無連接
首先 UDP 是不需要和 TCP一樣在發送數據前進行三次握手建立連接的，想發數據就可以開始發送了。並且也只是數據報文的搬運工，不會對數據報文進行任何拆分和拼接操作。
具體來說就是： 在發送端，應用層將數據傳遞給傳輸層的 UDP 協議，UDP 只會給數據增加一個 UDP 頭標識下是 UDP 協議，然后就傳遞給網絡層了。 在接收端，網絡層將數據傳遞給傳輸層，UDP 只去除 IP 報文頭就傳遞給應用層，不會任何拼接操作。
- 有單播，多播，廣播的功能
UDP 不止支持一對一的傳輸方式，同樣支持一對多，多對多，多對一的方式，也就是說 UDP 提供了單播，多播，廣播的功能。
- UDP是面向報文的
發送方的UDP對應用程序交下來的報文，在添加首部后就向下交付IP層。UDP對應用層交下來的報文，既不合並，也不拆分，而是保留這些報文的邊界。因此，應用程序必須選擇合適大小的報文。
- 不可靠性
首先不可靠性體現在無連接上，通信都不需要建立連接，想發就發，這樣的情況肯定不可靠。
並且收到什么數據就傳遞什么數據，並且也不會備份數據，發送數據也不會關心對方是否已經正確接收到數據了。
再者網絡環境時好時壞，但是 UDP 因為沒有擁塞控制，一直會以恆定的速度發送數據。即使網絡條件不好，也不會對發送速率進行調整。這樣實現的弊端就是在網絡條件不好的情況下可能會導致丟包，但是優點也很明顯，在某些實時性要求高的場景（比如電話會議）就需要使用 UDP 而不是 TCP。
12.gif 從上面的動態圖可以得知，UDP只會把想發的數據報文一股腦的丟給對方，並不在意數據有無安全完整到達。
- 頭部開銷小，傳輸數據報文時是很高效的。
UDP 頭部包含了以下幾個數據：
- 兩個十六位的端口號，分別為源端口（可選字段）和目標端口
- 整個數據報文的長度
- 整個數據報文的檢驗和（IPv4 可選 字段），該字段用於發現頭部信息和數據中的錯誤
因此 UDP 的頭部開銷小，只有八字節，相比 TCP 的至少二十字節要少得多，在傳輸數據報文時是很高效的。
TCP
當一台計算機想要與另一台計算機通訊時，兩台計算機之間的通信需要暢通且可靠，這樣才能保證正確收發數據。對比上面的UDP，就知道為啥要握手和揮手了，目的就是為了保證可靠的連接。平時TCP用的場景更多。
TCP協議全稱是傳輸控制協議是一種面向連接的、可靠的、基於字節流的傳輸層通信協議，由 IETF 的RFC 793定義。流就是指不間斷的數據結構，你可以把它想象成排水管中的水流。
- tcp連接過程，建立連接，三次握手。為啥握手揮手？基於安全考慮，確認連接對象（面向連接）和其狀態（可靠傳輸）
第一次握手 客戶端向服務端發送連接請求報文段。該報文段中包含自身的數據通訊初始序號。請求發送后，客戶端便進入 SYN-SENT 狀態。
第二次握手 服務端收到連接請求報文段后，如果同意連接，則會發送一個應答，該應答中也會包含自身的數據通訊初始序號，發送完成后便進入 SYN-RECEIVED 狀態。
第三次握手 當客戶端收到連接同意的應答后，還要向服務端發送一個確認報文。客戶端發完這個報文段后便進入ESTABLISHED 狀態，服務端收到這個應答后也進入ESTABLISHED狀態，此時連接建立成功。
這里可能大家會有個疑惑：為什么 TCP建立連接需要三次握手，而不是兩次？這是因為這是為了防止出現失效的連接請求報文段被服務端接收的情況，從而產生錯誤。
2.斷開連接，四次揮手
TCP是全雙工的，在斷開連接時兩端都需要發送 FIN 和 ACK，2*2就是4次啦。
第一次揮手 若客戶端 A 認為數據發送完成，則它需要向服務端 B 發送連接釋放請求。
第二次揮手 B 收到連接釋放請求后，會告訴應用層要釋放 TCP 鏈接。然后會發送 ACK 包，並進入 CLOSE_WAIT 狀態，此時表明 A 到 B 的連接已經釋放，不再接收 A 發的數據了。但是因為 TCP 連接是雙向的，所以 B 仍舊可以發送數據給 A。
第三次揮手 B 如果此時還有沒發完的數據會繼續發送，完畢后會向 A 發送連接釋放請求，然后 B 便進入 LAST-ACK 狀態。
第四次揮手 A 收到釋放請求后，向 B 發送確認應答，此時 A 進入 TIME-WAIT 狀態。該狀態會持續 2MSL（最大段生存期，指報文段在網絡中生存的時間，超時會被拋棄） 時間，若該時間段內沒有 B 的重發請求的話，就進入 CLOSED 狀態。當 B 收到確認應答后，也便進入 CLOSED 狀態。
所以，TCP協議的特點：
1.面向連接
面向連接，是指發送數據之前必須在兩端建立連接。建立連接的方法是“三次握手”，這樣能建立可靠的連接。建立連接，是為數據的可靠傳輸打下了基礎。
2.僅支持單播傳輸
每條TCP傳輸連接只能有兩個端點，只能進行點對點的數據傳輸，不支持多播和廣播傳輸方式。
3.面向字節流
TCP不像UDP一樣那樣一個個報文獨立地傳輸，而是在不保留報文邊界的情況下以字節流方式進行傳輸。
4.可靠傳輸
對於可靠傳輸，判斷丟包，誤碼靠的是TCP的段編號以及確認號。TCP為了保證報文傳輸的可靠，就給每個包一個序號，同時序號也保證了傳送到接收端實體的包的按序接收。然后接收端實體對已成功收到的字節發回一個相應的確認(ACK)；如果發送端實體在合理的往返時延(RTT)內未收到確認，那么對應的數據（假設丟失了）將會被重傳。
5.提供擁塞控制
當網絡出現擁塞的時候，TCP能夠減小向網絡注入數據的速率和數量，緩解擁塞
6.TCP提供全雙工通信
TCP允許通信雙方的應用程序在任何時候都能發送數據，因為TCP連接的兩端都設有緩存，用來臨時存放雙向通信的數據。當然，TCP可以立即發送一個數據段，也可以緩存一段時間以便一次發送更多的數據段（最大的數據段大小取決於MSS）
7.TCP頭部
一個 TCP Header 一般有 20 個字節，如果啟用了 options，header的長度可以達到 60 個字節。 內容包含：
- 發送方端口號和接收方的端口號
- 發送方的序列號
- 接收方 ack 的序列號
- 從 CWR 到 FIN 的 8 個 bit
- ACK 和 SYN
- 校驗
詳細內容，可以到網上搜，不贅述。總之，里面包含了三次握手和四次揮手的內容，以及端口號校驗碼等，來確認兩台機器的可靠連接。
瀏覽器network的HTTP headers 和 TCP headers有什么區別？
我們上面說了這么多，大概知道了HTTP headers 和 TCP headers的區別，http是應用層的協議，tcp是傳輸層可靠連接協議，tcp/ip是協議族總稱，不僅包含tcp和http，還包含所有七層用到的所有協議。
HTTP協議用於客戶端和服務器端之間的通信。
HTTP協議和TCP/IP協議族內的其他眾多的協議相同， 用於客戶端和服務器之間的通信。請求訪問文本或圖像等資源的一端稱為客戶端， 而提供資源響應的一端稱為服務器端。在兩台計算機之間使用HTTP協議通信時， 在一條通信線路上必定有一端是客戶端， 另一端則是服務器端。
有時候， 按實際情況， 兩台計算機作為客戶端和服務器端的角色有可能會互換。 但就僅從一條通信路線來說， 服務器端和客戶端的角色是確定的， 而用HTTP協議能夠明確區分哪端是客戶端， 哪端是服務器端。
HTTP協議規定， 請求從客戶端發出， 最后服務器端響應該請求並返回。
換句話說， 肯定是先從客戶端開始建立通信的， 服務器端在沒有接收到請求之前不會發送響應。
HTTP是一種不保存狀態， 即無狀態（stateless） 協議。HTTP協議自身不對請求和響應之間的通信狀態進行保存。 也就是說在HTTP這個級別， 協議對於發送過的請求或響應都不做持久化處理。
現在我們來了解一下HTTP headers內容
上圖從上到下解析：
- 請求地址
- get表示請求訪問服務器的類型， 稱為方法（method），還有post
- status code 服務器返回狀態碼
- 其他的看下表
前端用的多的主要是這些，還有根據方法不同的各種傳參方式，轉json格式，body等
GET和POST區別GET后退按鈕/刷新無害，POST數據會被重新提交（瀏覽器應該告知用戶數據會被重新提交）。
GET書簽可收藏，POST為書簽不可收藏。
GET能被緩存，POST不能緩存 。
GET編碼類型application/x-www-form-url，POST編碼類型encodedapplication/x-www-form-urlencoded 或 multipart/form-data。為二進制數據使用多重編碼。
GET歷史參數保留在瀏覽器歷史中。POST參數不會保存在瀏覽器歷史中。
GET對數據長度有限制，當發送數據時，GET 方法向 URL 添加數據；URL 的長度是受限制的（URL 的最大長度是 2048 個字符）。POST無限制。
GET只允許 ASCII 字符。POST沒有限制。也允許二進制數據。
與 POST 相比，GET 的安全性較差，因為所發送的數據是 URL 的一部分。在發送密碼或其他敏感信息時絕不要使用 GET ！POST 比 GET 更安全，因為參數不會被保存在瀏覽器歷史或 web 服務器日志中。
GET的數據在 URL 中對所有人都是可見的。POST的數據不會顯示在 URL 中。
請求首部字段（Request Header Fields）：從客戶端向服務器端發送請求報文時使用的首部。 補充了請求的附加內容、 客戶端信息、 響應內容相關優先級等信息。
響應首部字段（Response Header Fields）：從服務器端向客戶端返回響應報文時使用的首部。 補充了響應的附加內容， 也會要求客戶端附加額外的內容信息。
實體首部字段（Entity Header Fields）：針對請求報文和響應報文的實體部分使用的首部。 補充了資源內容更新時間等與實體有關的信息。 這些也是我們跟后端交互，調用接口的關鍵信息
請求方法： I
這篇文章寫的太全了，我感覺超越不了，你們可以直接看原文：
最詳細的http協議、tcp/ip協議：https://www.cnblogs.com/daijiabao/p/11183265.html
以上就是本文全部內容【完】