TCP與UDP

TCP 是面向連接的、可靠的流協議，通過三次握手建立連接，通訊完成時要拆除連接。

UDP是面向無連接的通訊協議，UDP通訊時不需要接收方確認，屬于不可靠的傳輸，可能會出現丟包現象

端口號：

端口號用來識別同一臺計算機中進行通信的不同應用程序。因此，它也被稱為程序地址

TCP得數據包

請求報文結構

請求報文的首部內容由以下數據組成：

請求行——包含用于請求的方法、請求 URI 和 HTTP 版本。

首部字段——包含表示請求的各種條件和屬性的各類首部。（通用首部、請求首部、實體首部以及RFC里未定義的首部如 Cookie 等）

響應報文結構

狀態行——包含表明響應結果的狀態碼、原因短語和 HTTP 版本。

首部字段——包含表示請求的各種條件和屬性的各類首部。（通用首部、響應首部、實體首部以及RFC里未定義的首部如 Cookie 等）

請求狀態碼：

	類別	原因
1xx	Informational(信息性狀態碼)	接收的請求正在處理
2xx	Success(成功狀態碼)	請求正常處理完畢
3xx	Redirection(重定向狀態碼)	需要進行附加操作以完成請求
4xx	Client Error(客戶端錯誤狀態碼)	服務器無法處理請求
5xx	Server Error(服務器錯誤狀態碼)	服務器處理請求出錯

TCP得滑動窗口傳輸機制

TCP協議數據包傳輸時并不是每一個報文段都會回復ACK的，可能會對兩個報文段發送一個ACK，也可能會對多個報文段發送1個ACK【累計ACK】，比如說發送方有1/2/3 3個報文段，先發送了2,3 兩個報文段，但是接收方期望收到1報文段，這個時候2,3報文段就只能放在緩存中等待報文1的空洞被填上，如果報文1，一直不來，報文2/3也將被丟棄，如果報文1來了，那么會發送一個ACK對這3個報文進行一次確認。

例子：

假設32~45 這些數據，是上層Application發送給TCP的，TCP將其分成四個Segment來發往接收方

2. 數據包1 32~34 ，數據包3 35~36， 數據包3 37~41 ，數據包4 42~45 這四個片段，依次發送出去，此時假設接收端之接收到了數據包1 數據包2 數據包4

3. 此時接收端的行為是回復一個ACK包說明已經接收到了32~36的數據，并將seg4進行緩存（保證順序，產生一個保存數據包3 的hole）

4. 發送端收到ACK之后，就會將32~36的數據包從發送并沒有確認切到發送已經確認，提出窗口，這個時候窗口向右移動

5. 假設接收端通告的Window Size仍然不變，此時窗口右移，產生一些新的空位，這些是接收端允許發送的范疇

6. 對于丟失的seg3，如果超過一定時間，TCP就會重新傳送（重傳機制），重傳成功會seg3 seg4一塊被確認，不成功，seg4也將被丟棄

就是不斷重復著上述的過程，隨著窗口不斷滑動，將真個數據流發送到接收端，實際上接收端的Window Size通告也是會變化的，接收端根據這個值來確定何時及發送多少數據，從對數據流進行流控。原理圖如下圖所示：

滑動窗口動態調整

主要是根據接收端的接收情況，動態去調整Window Size，然后來控制發送端的數據流量，當接收方再一定時間內數據讀取達到上限了，則會動態得調整下次數據接收窗口大小，并通知給發送方，發送方收到接收方得窗口大小后會改變下次傳輸得數據包大小，保證數得傳輸不會因為接收方數據量過載導致的丟失，以此用來做擁塞控制提高傳輸安全性