摘記《Wireshark網絡分析就這麼簡單》

• A、B在不一樣子網，B向A發起請求，跨子網須要默認網關轉發。先經過ARP廣播獲取默認網關的MAC地址。而後默認網關向A轉發請求，最後A回覆B，造成三角迴路。
• MTU：最大傳輸單元（決定每次傳輸多少，發包的大小由MTU較小一方決定）
• MSS(Maximum Segment Size)：每一個TCP包所能攜帶的最大數據量。在TCP鏈接創建時（三次握手），雙方會告知對方MSS。

MTU = MSS + TCP頭 + IP頭
TCP頭：20字節
IP頭：20字節
MTU：1500字節（以太網決定）採用巨幀（Jumbo Frame）能達到9000字節。

Seq：該數據段的序號
Len：該數據段的長度
Ack：接收方的確認號（各自維護）

Seq = 上一個Seq + Len
Ack = Seq + Len
理論上，接收方回覆的Ack = 下一個發送方的Seq

SYN：正在發起鏈接請求（由於鏈接是雙向的，因此雙方都要發一個SYN）
FIN：正在請求終止鏈接
RST：重置混亂鏈接或拒絕無效請求

三次握手

A --> B: [SYN] Seq=x
B --> A: [SYN, ACK] Seq=y, Ack=x+1
A --> B: [ACK] Seq=x+1, Ack=y+1

窗口滑動機制

* 咱們提到滑動窗口（slide window) 指的是發送方維護的窗口
    * 窗口的左側是：「成功發送、並已經被接收方確認的字節序列號」
    * 窗口的右側是：「發送方目前能夠發送的最大字節序列號」
    * Window size = 窗口右側 - 窗口左側
    * 當滑動窗口的左側與右側徹底重合，則意味着接收方通告發送方 window size = 0 ，發送方就要暫時中止數據的發送。直到對方TCP buffer有空餘的空間，告訴發送方新的 window size，或者發送方主動去查詢是否能夠發送數據。

# window size：
    * 接收方向發送方聲明本身的接收窗口（若接收方處理緩慢，緩存佔滿，此時WIN＝0）
    * 接收方告訴發送方本身還有多少緩衝區能夠接收數據
    * TCP傳輸速率不能大於應用的數據處理速率

重傳

• 擁塞點：致使網絡擁塞的數據量
• 擁塞窗口：發送方維護的虛擬的窗口

實際窗口的大小是接收窗口和擁塞窗口的較小值

• RTO：從發送原始包（丟失，未到達接收方）到重傳該包的這段時間

TCP引入了RTT——Round Trip Time，也就是一個數據包從發出去到回來的時間。這樣發送端就大約知道須要多少的時間，從而能夠方便地設置Timeout——RTO（Retransmission TimeOut），以讓咱們的重傳機制更高效。

• 慢啓動：在擁塞窗口增大的初期，接收到N個確認，則將擁塞窗口增大N個MSS。即翻倍增長。

• 臨界窗口值：

  • 若以前未發生擁塞，可取相對較大值，好比和最大接收窗口相等。
  • 若以前發生了擁塞，RFC建議大小爲以前發生擁塞時未確認包的一半，但 >= 2個MSS。
• 擁塞避免：每一個往返時間增長1個MSS（發送16個MSS所有被確認了，增長1個MSS）

• 超時重傳：發送方在發送後一段時間內沒收到確認，則須要從新傳輸。

  • 超時重傳後，擁塞窗口須要從慢啓動從新開始。
  • 影響：1.期間不能傳輸數據。2.擁塞窗口急劇減小
  • RFC建議將以後的擁塞窗口變成1個MSS。

• 快速重傳：

  • 當單包丟失，後續包正常到達時，接收方發現其Seq大於指望值，因此沒接收到一個包就Ack一次指望的Seq，提醒重傳；
  • 發送方接到3個以上（Dup Ack）時，當即重傳該包。（回覆3個Ack是由於避免只是亂序緣由致使重傳）

Wireshark -> Analyze -> Expert Info Composite #能夠查看重傳包

丟包對小文件的影響大於大文件。小文件可能湊不到3個Dup Ack，致使超時重傳。

超時重傳

快速重傳

擁塞控制

• 慢啓動 － 擁塞避免 － 擁塞發生(觸發超時重傳) － 慢啓動
• 慢啓動 － 擁塞避免 － 快速重傳 － 擁塞避免

• SACK（RFC2018定義）：

  • 接收到的包；在丟包時，經過接收方回覆Ack＋SACK，確認丟失的具體包
  • 能夠經過tcp_sack參數打開這個功能（Linux 2.4後默認打開）。

延遲確認：

1. TCP交互場景中，接收方在收到包後暫時無數據返回，則延遲一段時間確認，
2. 若在這段時間內有數據須要返回，則確認信息和數據一塊兒返回。
3. 並無提升性能，只是減小了確認包。

UDP

• UDP頭：端口號、包長度、校驗碼。共8個字節。
• 沒有Seq、Ack，沒法維持一個鏈接。省去創建鏈接的負擔。（例如：DNS）
• 發送方的網絡層會將數據包分片。接收方進行組裝。
• UDP沒有重傳機制，丟包由應用層來處理，丟包的話須要重傳全部的包。

• 接收方經過「More fragments」參數組裝包；

  • 1.後續還有分片；
  • 0.這是最後一個分片，能夠開始組裝。

易遭受黑客攻擊，黑客快速發送flag=1的UDP包，使發送方一直沒法將包組裝起來，致使內存耗盡。