TCP(UDP)/IP 作爲網絡通訊協議最基礎和常用的協議, 討論的非常多, 本文對TCP/IP 做一個簡單的回顧
1、網絡協議模型
鏈路層 (對應的是硬件部分, 在 7層模型中對應 鏈路層和物理層)
網絡層 IP協議所在的層 (7 層模型中的 網絡層)
傳輸層 TCP協議所在的層 ( 7 層模型的 傳輸層)
應用層 HTTP、FTP 協議所在的層 ( 7 層模型上三層)
其實層次模型非常好記, 最底層肯定是要處理硬件的轉換； 接着就是需要尋址, 設備互聯; 連通了設備, 考慮數據發送的各種(比如 流量控制)；最後在這個基礎上可以設計任意協議。
這也給了我們 在設計程序 交互的思路、平臺框架的思路，先基礎設施、然後功能疊加。
2、TCP 建鏈(握手)過程 和 關閉鏈接(揮手)過程
TCP 三次握手
Client A sync=j ->Server B 進入SYN_SEND狀態
Server B sync=j+1 sync=k - >Client A 進入SYN_RECV 狀態
Client A sync=k+1 ->Server B 共同進入 ESTABLISHED狀態
TCP 四次揮手
Client A Fin(i) -> Server B
Server B Ack(i+1) -> Client A
Server B Fin(j) - > Client A
Client A Ack(j+1) -> Server B
關閉時，採用四次而不是三次，因爲A關閉時，此時 B 不一定數據都發完了，所以B要另外等一下再發自己的關閉消息
3、IP 路由過程
從前面的描述,可以知道 每一層協議都會在消息頭部加上自己的內容, 比如TCP層加上端口號, IP層會加上IP地址, 鏈路層則會加上MAC地址。
那通訊的兩個節點 A 怎麼知道 如何到 B呢？
I、網段內的路由 - ARP
對於 一層設備(HUB)組合的網絡, 不能識別IP和MAC都是廣播的。
對於 二層設備(交換機)組合的網絡。
a、A 發出廣播, 尋找目標IP的 MAC地址, 並附上自己的MAC地址。
b、交換機收到廣播, [更新自己的MAC地址表], 轉發廣播請求
c、B收到廣播響應消息, 給A回一個消息
d、交換機收到消息 , [更新自己的MAC地址表], 找到A 的MAC地址對應的端口,把消息給A
e、A收到消息, 得到B的MAC地址, 緩存在本地。 尋址結束
II、不同網段的路由 - RIP/BGP
如果是跨網段的路由, 則需要用到 三層交換設備(路由器), 識別IP地址
尋址過程和 交換機的類似, 只是中間過程, 路由器需要不斷的接力, 把數據在 路由器網絡間傳遞, 到達目標網段後, 再由當前路由器分發到具體的節點(通過查找ARP緩存或者廣播ARP消息)
路由器之間的 路由過程？
通過IP 和 掩碼構建路由表。這個路由的構成, 就是通過 RIP協議廣播得到的。
a、每隔一段時間 廣播一下自己的路由表；爲了防止廣播風暴, 時間間隔可以設置隨機
b、收到的路由器更新自己的路由表
c、防止路由相互更新循環錯誤, 規定最大不能超過 15跳(每經過一個路由器, 爲一跳),超過 15跳, 認爲路徑不可達
4、數據發送
I、發送內容
a、IP報文
b、TCP 報文
c、UDP 報文
IP報文的數據段就是TCP/UDP報文, 理論上一個IP報文的最大單包大小可達 65535(包含報文頭), 實際上因爲在傳輸過程中 會對IP包分片爲 MTU；而以太網的MTU值爲 1500；實際使用中, 一般單包長度設置 < 1500 - 20(IP頭) - 20(TCP頭)
可以使用 Wireshark 抓包看每個報文, 網絡程序開發時, 查看報文是非常重要的手段。
重點關注 報文內容| 報文長度 | 五元組(源和目標的IP地址、端口, 協議類型)
II、流量(擁塞)控制 - 滑動窗口協議
傳輸的雙方非常類似於傳統的 生產-消費模型；發送方就是 生產者，接收方就是 消費者。
在生產 - 消費模型的典型設計中, 一般會有一個 緩存隊列, 生產者不斷推送數據到隊列，消費者不斷從隊列取數據進行處理。當兩者的處理速率不一致時, 就會出現 要麼隊列充滿, 生產者等待, 要麼隊列爲空, 消費者等待。
滑動窗口協議也採用了類似的思路。
在發送方和消費方都有各自的緩存 - 類似於 隊列。
a、在建鏈時, 協商每次發送的數據大小 (窗口 window); 以後每次接收方都反饋一個 窗口通知, 告知可接受的窗口大小; 如果爲 0 , 發送者停止發送
b、發送方和接收方不斷調整窗口的大小, 當出現擁塞時, 發送方減小窗口大小; 如果接收方處理加快,則窗口也加大
這樣就實現了 動態調整 高效的 數據發送和接受
III、TCP VS UDP
TCP是面向連接的協議, 通過報文, 可以看到 TCP 有確認措施, 保證數據能夠安全發送和接受, 沒有確認的, 會重發; 通過流量控制的窗口, 可以保證 數據有序的發送.
UDP是無連接的協議, 通過報文可知, 發送方只管發送, 不管是否收到, 也不管順序。 但因爲, 缺少交互的確認過程, 所以 UDP 的發送效率要高於TCP。
一般情況下, 如果需要更高效率的發送可以使用UDP, 而且UDP並沒有想象的有那麼多丟包。 實際使用過程中, 可以由應用, 在數據裏面增加 數據序號, 從而實現丟包重發和排序。