詳情見：https://www.yuque.com/zaygee/tvg571/imghbh
1.tcp的報頭
校驗和：
發送端填充，CRC校驗（循環冗餘校驗碼（CRC），簡稱循環碼）接收校驗不通過，則認爲數據有問題，和UDP校驗的是數據本身，TCP校驗的包含TCP首部、TCP數據部分
緊急指針：
只有在URG爲1時有效 ，該字段爲1表示報文中的緊急數據的指針
選項：
用於提高TCP的傳輸性能，根據首部長度控制，其最大長度爲40字節
2.6個標誌位
URG：The urgent pointer,緊急標誌指針，爲1，表示某一位需要被優先處理
PSH：推標誌，提示接收端應用程序立即從TCP緩衝區把數據讀走
ACK：Acknowledgement Number,確認標誌，確認號是否有效，一般置爲1
RST：復位標誌有效。當RST=1時，表明TCP連接中出現嚴重差錯，必須釋放連接，再重新建立連接
SYN：Synchronize Sequence Numbers,請求建立連接，並在其序列號的字段進行序列號的初始值設定。建立連接，設置爲1
FIN：結束標誌，FIN=1時，表明此報文段的發送端的數據已經發送完畢，並要求釋放傳輸連接
3.三次握手
第一次握手：
建立連接，客戶端向服務端發送請求數據包，標誌位SYN置爲1，ACK爲0，發送順序號seq=X（隨機int）, 並進入SYN_SENT狀態， 等待服務器確認
第二次握手：
服務器收到請求，需要確認客戶端的數據包，發送SYN+ACK, SYN=1，ACK =1，並含有服務端的初始序號 seq=Y（隨機int），以及服務端對客戶端初始序號的確認，ACK=seq（客戶端）+1（X+1）
第三次握手：
客戶端接收到服務端的確認，向服務器發送一序列號，確認號ACK=Y+1，此後客戶端和服務端進入 ESTAB_LISHED狀態，完成三次握手
4.四次揮手
第一次揮手：主動關閉方發送第一個包，其中FIN標誌位爲1，發送順序號seq爲X。
第二次揮手：被動關閉方收到FIN包後發送第二個包，其中發送順序號seq爲Z，接收順序號ack爲X+1。
第三次揮手：被動關閉方再發送第三個包，其中FIN標誌位爲1，發送順序號seq爲Y，接收順序號ack爲X。
第四次揮手：主動關閉方發送第四個包，其中發送順序號爲X，接收順序號爲Y。至此，完成四次揮手
5.常見問題
1.瀏覽器在與服務器建立了一個 TCP 連接後是否會在一個 HTTP 請求完成後斷開？什麼情況下會斷開？
在 HTTP/1.0 中，一個服務器在發送完一個 HTTP 響應後，會斷開 TCP 鏈接。但是這樣每次請求都會重新建立和斷開 TCP 連接，代價過大。所以雖然標準中沒有設定，某些服務器對 Connection: keep-alive 的 Header 進行了支持，
持久連接：既然維持 TCP 連接好處這麼多，HTTP/1.1 就把 Connection 頭寫進標準，並且默認開啓持久連接，除非請求中寫明 Connection: close，那麼瀏覽器和服務器之間是會維持一段時間的 TCP 連接，不會一個請求結束就斷掉
2.一個 TCP 連接可以對應幾個 HTTP 請求？
如果維持鏈接，一個tcp連接可以對應多個http請求
3.一個 TCP 連接中 HTTP 請求發送可以一起發送麼（比如一起發三個請求，再三個響應一起接收）？
在 HTTP/1.1 存在 Pipelining 技術可以完成這個多個請求同時發送，但是由於瀏覽器默認關閉，所以可以認爲這是不可行的。在 HTTP2 中由於 Multiplexing 特點的存在，多個 HTTP 請求可以在同一個 TCP 連接中並行進行
4.爲什麼有的時候刷新頁面不需要重新建立 SSL 連接？
tcp連接有的時候會被瀏覽器和服務器會維持一段時間，tcp不需要重新連接，自然不需要重新建立ssl連接
5.瀏覽器對同一 Host 建立 TCP 連接到數量有沒有限制？
Chrome 最多允許對同一個 Host 建立六個 TCP 連接
6.收到的 HTML 如果包含幾十個圖片標籤，這些圖片是以什麼方式、什麼順序、建立了多少連接、使用什麼協議被下載下來的呢
如果圖片都是HTTPS連接並且在同一個域名下，那麼瀏覽器在ssl握手之後會和服務器商量能不能用https2，如果能用的話就使用Multiplexing 功能在這個連接進行多路傳輸
如果只能用http/1.1，那瀏覽器就會在一個host上建立多個TCP連接，連接數量的最大限制取決於瀏覽器的設置
7.爲什麼建立連接協議是三次握手，而關閉連接卻是四次握手？
服務端的LISTEN狀態下的SOCKET當收到SYN報文的連接請求時，可以把ACK和SYN放在一個報文裏來發送，但是關閉連接時，當收到對方的FIN 報文通知時，僅僅表示對方沒有數據發送給你了，不代表你的所有數據都發送對對方了，當你已經沒有數據發送給對方了，再發送FIN報文給對方表示你同意關閉連接了
8.爲什麼TIME_WAIT狀態還需要等2MSL才能返回到CLOSE狀態？
一是爲了保證a發送的最後一個ACK報文能夠到達b，如果這個ACK報文丟失，會使處在LAST_ACK狀態的b收不到對已發送的FIN和ACK報文段的確認，b會超時重傳這個FIN和ACK報文段，而a就在這個2MSL時間內收到這個重傳的ACK+FIN報文段，接着a重傳一次確認
二是防止已失效的連接請求報文段出現在本連接中，a在發送完最後一個ACK報文段後，再經過2MSL，就可以使本連接持續時間內所產生的所有報文段都中網絡中消失
ps：什麼是2MSL？MSL即Maximum Segment Lifetime，也就是報文最大生存時間
9.爲什麼不能用兩次握手進行連接？
把三次握手改成僅需要兩次握手，有可能發生死鎖，例如客戶端給服務端發送一個連接請求分組，服務端收到了這個分組，併發送了確認應答分組，假如兩次握手，服務端認爲連接已經成功的建立了就可以開始發送數據，可是客戶端服務端的應答在傳輸中被丟失的情況下，將無法得知服務端是否已準備好，甚至懷疑服務端是否已收到自己的連接請求，在此情況下，客戶端認爲連接未建立成功，將忽略服務端發來的任何數據，一心等待連接的確認，而服務端在發出的數據超時後，重複發送同樣的數據，這樣就形成了死鎖
10.TCP協議和UDP協議的區別是什麼？
TCP協議是有連接的，即在開始傳輸數據之前，TCP的客戶端和服務端必須通過三次握手建立連接，會話結束後也要結束連接，而UDP是無連接的
TCP 協議保證了數據按序發送按序到達，提供超時重傳，但UDP無法保證
TCP有流量控制和擁塞控制，UDP 沒有，網絡擁堵不會影響發送端的發送速率
TCP協議首部需20個字節，UDP首部字段只需8個字節
TCP是一對一的連接，UDP可一對多，多對多，多對一的通信
TCP 面向字節流的服務，UDP 面向報文的服務
參考原文：https://blog.csdn.net/qq_34827674/article/details/106627403
https://blog.csdn.net/weixin_44786530/article/details/89299896