網絡原理-TCP

1.UDP（即用戶數據報協議）

UDP是一種無連接的傳輸層協議，提供簡單的、不可靠的數據傳輸服務。它不保證數據包的順序、可靠性或重復性，但具有低延遲和高效率的特點。

UDP協議段格式

16位UDP?度,表?整個數據報(UDP?部+UDP數據)的最??度，也就是64kb可是現在的互聯網中已經不夠用了
如果校驗和出錯,就會直接丟棄

理解UDP的不可靠（即傳輸控制協議）

UDP 的不可靠體現在它無法保證數據能 “完整、有序、不重復” 地到達接收方，且出現問題時不會主動處理或通知。

無連接：跳過 “通信準備” 環節，發送方無需向接受方發起連接，直接進行傳輸
無確認與重傳機制：“發完即忘”，接收方未確認收到，可能數據丟失發送法也不知道也不會進行重傳
無序傳輸：不保證數據順序，沒有序號標記，數據報可能通過不同的路徑進行傳輸，接受方獲取亂序的數據
?無去重機制：可能收到重復數據，可能因為網絡問題導致接收方重復接受數據報
可選的校驗和：對數據損壞的處理有限，UDP的校驗和是可選的，如果出錯會直接丟棄
無流量控制與擁塞控制：“不管網絡死活”，若大量數據包發送造成網絡堵塞可能數據報會發生丟棄

2.TCP

TCP（Transmission Control Protocol）是傳輸層協議，提供面向連接、可靠的數據傳輸服務。

TCP協議段格式

TCP 頭部字段詳解

源/目的端口號

表示數據從哪個進程發送，到哪個進程接收。端口號用于標識主機上的具體應用進程。

32位序號/32位確認號

序號用于標識數據包的順序，確保數據按序傳輸。
確認號用于確認接收到的數據，表示期望接收的下一個字節序號。

4位TCP報頭長度

表示TCP頭部包含的32位字的數量。
頭部最大長度為15 × 4 = 60字節（因為4位最大值為15）。

6位標志位

URG：緊急指針是否有效。若為1，表示緊急數據需要優先處理。
ACK：確認號是否有效。若為1，表示確認號字段有意義。
PSH：提示接收端應用程序立即從TCP緩沖區讀取數據。
RST：表示要求重新建立連接。攜帶RST標志的報文稱為復位報文段。
SYN：請求建立連接。攜帶SYN標志的報文稱為同步報文段。
FIN：通知對方本端要關閉連接。攜帶FIN標志的報文稱為結束報文段。

16位窗口大小

表示接收端的接收緩沖區剩余空間大小，用于流量控制。

16位校驗和

由發送端填充，采用CRC校驗算法。
校驗范圍包括TCP頭部和數據部分。接收端校驗失敗則丟棄數據。

16位緊急指針

當URG標志為1時有效，指向緊急數據的末尾位置。

40字節頭部選項（可選字段）

用于擴展TCP功能，如最大報文段長度（MSS）、窗口縮放因子等。

TCP的可靠

確認應答

在上述我們說過UDP的不可靠而TCP卻恰恰相反。

每?個ACK都帶有對應的確認序列號,意思是告訴發送者,我已經收到了哪些數據;下?次你從哪?開始發送

超時重傳

主機A發送數據給B之后,可能因為?絡擁堵等原因,數據?法到達主機B
如果主機A在?個特定時間間隔內沒有收到B發來的確認應答,就會進?重發; 但是,主機A未收到B發來的確認應答,也可能是因為ACK丟失了

因此主機B會收到很多重復數據.那么TCP協議需要能夠識別出那些包是重復的包,并且把重復的丟棄掉

超時的時間如何確定?

最理想的情況下找個最小的時間，但是網絡通信的復雜程度哪有這么容易獲取呢，時間太長影響效率，時間太短重復發送。因此TCP為了保證?論在任何環境下都能?較?性能的通信,因此會動態計算這個最?超時時間。

超時以500ms為?個單位進?控制,每次判定超時重發的超時時間都是500ms的整數倍.
如果重發?次之后,仍然得不到應答,等待2*500ms后再進?重傳.
如果仍然得不到應答,等待4*500ms進?重傳.依次類推,以指數形式遞增.
累計到?定的重傳次數,TCP認為?絡或者對端主機出現異常,強制關閉連接

連接管理

在正常情況下,TCP要經過三次握?建?連接,四次揮?斷開連接

CLOSED：初始 “關閉” 狀態，連接未建立或已完全關閉，無任何連接相關資源占用。
LISTEN（僅服務器）：服務器調用?listen()?后進入，處于 “監聽” 狀態，等待客戶端發起連接請求。
SYN_SENT（僅客戶端）：客戶端調用?connect()?發送?SYN（同步連接請求）后進入，等待服務器響應?SYN+ACK。
SYN_RCVD（僅服務器）：服務器收到客戶端?SYN?后進入，已準備好響應?SYN+ACK，等待客戶端最終?ACK。
ESTABLISHED（客戶端 + 服務器）：三次握手完成后進入，連接 “已建立” 狀態，雙方可正常收發數據。
FIN_WAIT_1（僅客戶端）：客戶端主動調用?close()?發送?FIN（結束連接請求）后進入，等待服務器?ACK。
FIN_WAIT_2（僅客戶端）：客戶端收到服務器對?FIN?的?ACK?后進入，等待服務器發起?FIN?關閉請求。
CLOSE_WAIT（僅服務器）：服務器收到客戶端?FIN?后進入，需處理自身關閉邏輯（如收尾數據），準備主動發?FIN。
LAST_ACK（僅服務器）：服務器發送?FIN?后進入，等待客戶端最終?ACK?確認關閉。
TIME_WAIT（僅客戶端）：客戶端發送對服務器?FIN?的?ACK?后進入，需等待超時（避免報文丟失導致連接殘留），超時后徹底關閉。

TCP 三次握手（建立連接）

三次握手的目的是同步通信雙方的序列號，并確認彼此的接收和發送能力，最終建立可靠的連接。

過程詳解

第一次握手（客戶端 → 服務器）
- 客戶端向服務器發送?SYN（同步）報文，請求建立連接。
- 報文包含：客戶端的初始序列號（seq = x），表示后續數據將從?x+1?開始發送。
第二次握手（服務器 → 客戶端）
- 服務器收到 SYN 后，同意建立連接，回復?SYN+ACK（同步 + 確認）報文。
- 報文包含：
  - 服務器的初始序列號（seq = y）；
  - 確認號（ack = x+1），表示已收到客戶端的?x?序號，期待下一個數據從?x+1?開始。
第三次握手（客戶端 → 服務器）
- 客戶端收到 SYN+ACK 后，發送?ACK（確認）報文。
- 報文包含：確認號（ack = y+1），表示已收到服務器的?y?序號，期待下一個數據從?y+1?開始。
- 服務器收到 ACK 后，連接正式建立，雙方開始傳輸數據。

其實這里就像兩個人通電話：

甲打給乙：喂，你能聽到嗎？（甲發起連接請求）
乙回應：能聽到！你能聽到我嗎？（乙確認收到，同時反問甲）
甲回答：能聽到！那我們開始說吧。”（甲確認收到乙的回應）

TCP 四次揮手（終止連接）

過程詳解：

假設客戶端先主動關閉連接：

第一次揮手（客戶端 → 服務器）
- 客戶端發送?FIN（結束）報文，表示 “我不再發送數據了”。
- 報文包含：客戶端當前序列號（seq = u）。
第二次揮手（服務器 → 客戶端）
- 服務器收到 FIN 后，回復?ACK 報文，確認 “已收到關閉請求”。
- 報文包含：確認號（ack = u+1），服務器自身序列號（seq = v）。
- 此時，客戶端到服務器的方向連接關閉，但服務器仍可向客戶端發送數據（半關閉狀態）。
第三次揮手（服務器 → 客戶端）
- 服務器發送完所有數據后，也發送?FIN 報文，表示 “我也不再發送數據了”。
- 報文包含：服務器當前序列號（seq = w，w?可能大于?v，因期間可能發送了數據），確認號（ack = u+1）。
第四次揮手（客戶端 → 服務器）
- 客戶端收到 FIN 后，回復?ACK 報文，確認 “已收到服務器的關閉請求”。
- 報文包含：確認號（ack = w+1），客戶端自身序列號（seq = u+1）。
- 服務器收到 ACK 后，關閉連接；客戶端需等待一段時間（2MSL，確保服務器收到 ACK）后關閉連接。

這里就像有一方想掛電話的場景：

甲說：我說完了，要掛了哦。（甲請求關閉連接）
乙回應：好，知道你要掛了，我這邊還有點話沒說完。（乙確認收到，但沒準備好）
乙補完話說：我也說完了，你可以掛了。（乙準備好關閉）
甲回應：好，那掛了。（甲確認，最終斷開）

滑動窗?

窗???指的是?需等待確認應答?可以繼續發送數據的最?值.上圖的窗???就是4000個字節，收到第一個ASK的時候繼續發送以此類推。這樣的話同時也伴隨著問題。

情況?:數據包已經抵達,ACK被丟了

這種情況下,部分ACK丟了并不要緊,因為可以通過后續的ACK進?確認;

情況?:數據包就直接丟了

當中間有一段數據段丟失了，接收方就會一直1001ACK重復應答，接收方就收到重復的1001ACK的確認應答，則進行重發，再次收到就是7001ACK，因為之前已經發送過了只是因為丟失進入了接收緩沖區

流量控制

接收端處理數據的速度是有限的.如果發送端發的太快,導致接收端的緩沖區被打滿,這個時候如果發送端繼續發送,就會造成丟包,繼?引起丟包重傳等等?系列連鎖反應.

因此TCP?持根據接收端的處理能?,來決定發送端的發送速度.這個機制就叫做流量控制

接收端將??可以接收的緩沖區??放?TCP?部中的"窗???"字段,通過ACK端通知發送端;

這里的緩沖區可以看出一杯水，滿了就不能再加了，需要喝水，取決于你喝多少水，我就加多少水。

窗???字段越?,說明?絡的吞吐量越?;
接收端?旦發現??的緩沖區快滿了,就會將窗???設置成?個更?的值通知給發送端;?
發送端接受到這個窗?之后,就會減慢??的發送速度;
如果接收端緩沖區滿了,就會將窗?置為0;這時發送?不再發送數據,但是需要定期發送?個窗?探測數據段,使接收端把窗???告訴發送端.

擁塞控制

雖然TCP有了滑動窗?這個?殺器,能夠?效可靠的發送?量的數據.但是如果在剛開始階段就發送?量的數據,仍然可能引發問題.

因為?絡上有很多的計算機,可能當前的?絡狀態就已經?較擁堵.在不清楚當前?絡狀態下,貿然發送 ?量的數據,是很有可能引起雪上加霜的.

TCP引?慢啟動機制,先發少量的數據,探探路,摸清當前的?絡擁堵狀態,再決定按照多?的速度傳輸數據;

此處引??個概念程為擁塞窗??
發送開始的時候,定義擁塞窗???為1
每次收到?個ACK應答,擁塞窗?加1
每次發送數據包的時候,將擁塞窗?和接收端主機反饋的窗???做?較,取較?的值作為實際發送的窗?

像上?這樣的擁塞窗?增?速度,是指數級別的."慢啟動"只是指初使時慢,但是增?速度?常快，為了不增?的那么快,因此不能使擁塞窗?單純的加倍

此處引??個叫做慢啟動的閾值
當擁塞窗?超過這個閾值的時候,不再按照指數?式增?,?是按照線性?式增?
當TCP開始啟動的時候,慢啟動閾值等于窗?最?值
在每次超時重發的時候,慢啟動閾值會變成原來的?半,同時擁塞窗?置回1

延遲應答

指接收方收到數據后，不立即返回確認（ACK）報文，而是短暫延遲一段時間（通常不超過 500ms），等待是否有其他數據或控制信息可以與 ACK “合并” 發送（例如結合捎帶應答機制），從而減少網絡中單獨 ACK 報文的數量，降低帶寬消耗。

假設接收端緩沖區為1M.?次收到了500K的數據;如果?刻應答,返回的窗?就是500K;
但實際上可能處理端處理的速度很快,10ms之內就把500K數據從緩沖區消費掉了;
在這種情況下,接收端處理還遠沒有達到??的極限,即使窗?再放??些,也能處理過來;
?如果接收端稍微等?會再應答,?如等待200ms再應答,那么這個時候返回的窗???就是1M;

延遲應答的限制

數量限制:每隔N個包就應答?次;

時間限制:超過最?延遲時間就應答?次;

具體的數量和超時時間,依操作系統不同也有差異;?般N取2,超時時間取200ms

捎帶應答

指發送方在向接收方傳輸數據報文時，順便將對之前已接收數據的確認（ACK）信息 “捎帶” 在該數據報文中，而非單獨發送一個 ACK 報文。這一機制的核心目的是減少網絡中報文的數量，降低帶寬消耗，提高通信效率。

?向字節流

創建?個TCP的socket,同時在內核中創建?個發送緩沖區和?個接收緩沖區
調?write時,數據會先寫?發送緩沖區中;?
如果發送的字節數太?,會被拆分成多個TCP的數據包發出;
?如果發送的字節數太短,就會先在緩沖區?等待,等到緩沖區?度差不多了,或者其他合適的時機發送出去;
接收數據的時候,數據也是從?卡驅動程序到達內核的接收緩沖區;
然后應?程序可以調?read從接收緩沖區拿數據;
另???,TCP的?個連接,既有發送緩沖區,也有接收緩沖區,那么對于這?個連接,既可以讀數據, 也可以寫數據.這個概念叫做全雙?

粘包問題

是 “面向字節流” 特性帶來的典型現象 —— 接收方無法直接區分應用層發送的多個消息邊界，導致多個消息被 “粘” 在一起接收，或一個消息被拆分成多個部分接收。

為什么會出現粘包？

發送方的緩沖與合并
發送方 TCP 為提高效率，會將應用層多次發送的小數據合并成一個大報文發送（Nagle 算法）。例如：應用層連續發送?"A"、"B"、"C"?三個小消息，TCP 可能將它們合并為一個報文發送，接收方一次收到?"ABC"，無法區分清原始的三個消息。
接收方的緩沖與拆分
接收方 TCP 會將收到的數據先放入緩沖區，再按需交付給應用層。如果緩沖區中的數據未被應用層及時讀取，新到的數據會繼續存入緩沖區，導致多個消息被 “粘” 在緩沖區中。
網絡分段的不確定性
TCP 可能根據網絡 MTU（最大傳輸單元）將大消息拆分成多個小報文傳輸，接收方可能分多次收到這些分段，導致一個完整消息被拆分接收。

粘包的表現形式

多包合一：多個消息被合并成一個報文接收。
一包拆分：一個消息被拆分成多個報文接收。
混合形式：部分消息合并，部分拆分。

如何解決粘包問題？

固定長度
約定每個消息的字節數固定（如 100 字節）。接收方每次讀取固定長度的數據，不足時等待補全。
缺點：不適合長度多變的消息，可能浪費帶寬。
分隔符
在消息末尾添加特殊分隔符（如?\r\n、|?等，需確保分隔符不會出現在消息內容中）。接收方通過分隔符拆分消息。
例：HTTP 協議用?\r\n?分隔請求頭字段。
長度前綴
在消息頭部添加固定長度的 “長度字段”，說明后續消息正文的字節數。接收方先讀長度字段，再按長度讀取對應字節數的正文。
例：二進制協議常用 4 字節整數表示消息長度

異常情況

進程終?:進程終?會釋放?件描述符,仍然可以發送FIN.和正常關閉沒有什么區別.
機器重啟:和進程終?的情況相同.
機器掉電/?線斷開:接收端認為連接還在,?旦接收端有寫?操作,接收端發現連接已經不在了,就會進?reset.即使沒有寫?操作,TCP??也內置了?個保活定時器,會定期詢問對?是否還在.如果對?不在,也會把連接釋放.

3.TCP/UDP對?

特性	TCP協議	UDP協議
連接性	面向連接（需三次握手建立連接，四次揮手關閉連接）	無連接（直接發送數據，無需建立/關閉連接）
可靠性	提供可靠傳輸（保證數據不丟失、不重復、按序到達）	不可靠傳輸（不保證數據到達，可能丟失、亂序）
數據邊界	面向字節流（無消息邊界，可能出現粘包）	面向報文（保留消息邊界，不合并、不拆分）
擁塞控制與流量控制	有（通過滑動窗口、擁塞窗口等機制動態調整發送速率）	無（發送速率不受控制，可能導致網絡擁塞）
首部開銷	較大（固定首部20字節，可選擴展字段）	較小（固定首部8字節）
適用場景	對可靠性要求高的場景（文件傳輸、網頁加載、郵件等）	對實時性要求高的場景（視頻通話、游戲、廣播等）

4.IP

主機:配有IP地址,但是不進?路由控制的設備;
?路由器:即配有IP地址,?能進?路由控制;?
節點:主機和路由器的統稱;

協議頭格式

4位版本號(version):指定IP協議的版本,對于IPv4來說,就是4
4位頭部?度(headerlength):IP頭部的?度是多少個32bit,也就是length*4的字節數.4bit表?最 ?的數字是15,因此IP頭部最??度是60字節
8位服務類型(TypeOfService):3位優先權字段(已經棄?),4位TOS字段,和1位保留字段(必須置為 0). 4位TOS分別表?:最?延時,最?吞吐量,最?可靠性,最?成本.這四者相互沖突,只能選擇?個. 對于ssh/telnet這樣的應?程序,最?延時?較重要;對于ftp這樣的程序,最?吞吐量?較重要
16位總?度(totallength):IP數據報整體占多少個字節
16位標識(id):唯?的標識主機發送的報?.如果IP報?在數據鏈路層被分?了,那么每?個???的這個id都是相同的
3位標志字段:第?位保留(保留的意思是現在不?,但是還沒想好說不定以后要?到).第?位置為1表 ?禁?分?,這時候如果報??度超過MTU,IP模塊就會丟棄報?.第三位表?"更多分?",如果分? 了的話,最后?個分?置為1,其他是0.類似于?個結束標記.
13位分?偏移(framegamentoffset):是分?相對于原始IP報?開始處的偏移.其實就是在表?當前分?在原報?中處在哪個位置.實際偏移的字節數是這個值*8得到的.因此,除了最后?個報?之外,其他報?的?度必須是8的整數倍(否則報?就不連續了)
8位?存時間(TimeToLive,TTL):數據報到達?的地的最?報?跳數.?般是64.每次經過?個路由,TTL-=1,?直減到0還沒到達,那么就丟棄了.這個字段主要是?來防?出現路由循環比特就業課?
8位協議:表?上層協議的類型
16位頭部校驗和:使?CRC進?校驗,來鑒別頭部是否損壞
32位源地址和32位?標地址:表?發送端和接收端

地址管理

?絡號:保證相互連接的兩個?段具有不同的標識
主機號:同??段內,主機之間具有相同的?絡號,但是必須有不同的主機號

同一個局域網中不同設備網絡號必須相同，主機號必須不同
相鄰局域網中不同設備網絡號必須不同，主機號無限制

IP不夠用了怎么辦

NAT（網絡地址轉換）

原理：在局域網（如家庭、企業內網）中使用私有 IPv4 地址（如192.168.x.x、10.x.x.x），僅通過 1-2 個公網 IPv4 地址接入互聯網。NAT 設備（如家用路由器）負責在私有地址與公網地址之間轉換，實現多設備共享一個公網 IP。
作用：極大減少對公網 IPv4 地址的消耗（一個公網 IP 可支持數十甚至上百臺設備），是目前最廣泛使用的短期解決方案。

CIDR（動態分配IP地址）