該文章轉載自楊建勇的個人博客
總結記錄HTTP協議/TCP/IP協議
HTTP協議
協議也就是結構，結構分爲請求結構和響應結構
請求結構
這裏着重講解一下協議的結構，很多時候我們收到服務器響應的400錯誤（Bad Request）的時候，就是因爲結構不規範，服務器不接受請求。下圖是HTTP協議的Request結構
注意結構中的回車符，換行符還有空格。很多時候寫程序構建協議的結構的時候，都是因爲這些細節導致的400錯誤
可以看出圖中的結構分爲四部分：
第一部分：結構爲：請求方法+空格+URI+空格+協議/版本。格式錯誤都將造成400錯誤
第二部分：請求頭部
第三部分：空行（用curl構建的時候該行用\r\n來構建）
第四部分：請求實體內容
實例代碼：
POST / HTTP/1.1
Host:baidu.com
User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Content-Type:application/x-www-form-urlencoded
Content-Length:40
Connection: Keep-Alive
test=post%20data=test_data
響應結構
下圖是Response的結構
實例代碼：
HTTP/1.1 200 OK
Date: Fri, 28 May 2020 16:07:21 GMT
Content-Type: text/html; charset=UTF-8
<html>
<head>Test</head>
<body>
<h1>Test Response</h1>
</body>
</html>
同樣的返回的結構也是由四部分組成：
第一部分：狀態行（包含了協議/協議版本+空格+狀態碼+空格+消息狀態）
第二部分：消息報頭（代碼中的2-3行）。包含了各種消息報頭（Header）
第三部分：空行
第四部分：響應的主體內容（主體響應內容就是HTML代碼）
HTTP狀態碼
狀態是經常使用到的，分爲5大類，類別有數字1,2,3,4,5開頭組成的，每一類的狀態碼都由三個數字組成。
第一類：1xx。消息狀態碼
第二類：2xx。成功狀態碼
第三類：3xx。重定向狀態碼
第四類：4xx。客戶端錯誤狀態碼
第五類：5xx。服務端錯誤狀態碼
以上就是HTTP協議
TCP協議
TCP簡述
在TCP/IP網絡模型中，將網絡的數據分層分爲了四層。從下到上爲網絡接口層—網絡層—運輸層—應用層。TCP協議的作用就是用於在運輸層中各種應用程序之間的數據傳輸。並且要求TCP協議在傳輸數據時必須是面向連接的、可靠的、數據完整的。在應用程序之間傳輸數據之前必須要建立起TCP連接，在數據傳輸完畢之後必須釋放已建立的連接。
建立TCP連接
在傳輸數據之前，應用程序之間必須要先建立起連接，數據傳輸後必須釋放已建立的連接。這就涉及三次握手（連接）和四次揮手（斷開）
三次握手從上圖可以看出建立連接來回進行了三次問答
- 第一次握手(SYN=1, seq=x)。首先Client端發送一個SYN 標誌位置1的包，指明Client端要建立連接的服務器的端口，以及初始序號 X。保存在包頭的序列號(Sequence Number)字段裏。發送完畢後，Client端進入 SYN_SEND 狀態
- 第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1)。Client端接收到連接請求後，發回確認包(ACK)應答。即 SYN 標誌位和 ACK 標誌位均爲1。Client端選擇自己 ISN 序列號，放到 Seq 域裏，同時將確認序號(Acknowledgement Number)設置爲客戶的 ISN 加1，即X+1。 發送完畢後，Client端進入 SYN_RCVD 狀態
- 第三次握手(ACK=1，ACKnum=y+1)。Server端再次發送確認包(ACK)，SYN 標誌位爲0，ACK 標誌位爲1，並且把服務器發來 ACK 的序號字段+1，放在確定字段中發送給對方，並且在數據段放寫ISN的+1。發送完畢後，Client端進入 ESTABLISHED 狀態，當服務器端接收到這個包時，也進入 ESTABLISHED 狀態，此時TCP三次握手完成
通俗的理解建立TCP連接的過程：1、Client向Server端請求說我要傳輸數據；2、Server端接收到請求後向Client端回答說我已經接收到請求；3、Client端接收到Server端的確認應到後向Server端回答說已經接收到確認
四次揮手從圖中可以看出斷開已建立的TCP經歷了四次問答 - 第一次揮手(FIN=1，seq=x)。假設客戶端想要關閉連接，客戶端發送一個 FIN 標誌位置爲1的包，表示自己已經沒有數據可以發送了，但是仍然可以接受數據。發送完畢後，客戶端進入 FIN_WAIT_1 狀態
- 第二次揮手(ACK=1，ACKnum=x+1)。服務器端確認客戶端的 FIN 包，發送一個確認包，表明自己接受到了客戶端關閉連接的請求，但還沒有準備好關閉連接。發送完畢後，服務器端進入 CLOSE_WAIT 狀態，客戶端接收到這個確認包之後，進入 FIN_WAIT_2 狀態，等待服務器端關閉連接。
- 第三次揮手(FIN=1，seq=y)。服務器端準備好關閉連接時，向客戶端發送結束連接請求，FIN 置爲1。發送完畢後，服務器端進入 LAST_ACK 狀態，等待來自客戶端的最後一個ACK。
- 第四次揮手(ACK=1，ACKnum=y+1)。Client接收到來自服務器端的關閉請求，發送一個確認包，並進入 TIME_WAIT狀態，等待可能出現的要求重傳的 ACK 包。Server端接收到這個確認包之後，關閉連接，進入 CLOSED 狀態。Client等待了某個固定時間（兩個最大段生命週期，2MSL，2 Maximum Segment Lifetime）之後，沒有收到Server端的 ACK ，認爲Server端已經正常關閉連接，於是自己也關閉連接，進入 CLOSED 狀態。
通俗的理解斷開TCP連接的過程**（Client/Server沒有順序關係，任何一端都可以發送關閉close()請求）**：1、Client端發送我已經沒有數據可以傳輸，但是可以接收數據，請求斷開連接；2、Server端接收到斷開請求後返回我同意你的關閉請求，但此時有可能還需要傳輸數據；3、當Server不需要再傳輸數據後就向Client端發送一個斷開連接的請求；4、Client端接收Server端的斷開請求後回覆可以斷開連接