UDP
UDP數據報=UDP報頭+UDP載荷
UDP的報文格式：
這里的UDP長度，描述了整個UDP數據報，占多少個字節，這里整個UDP長度最多是64kb
在UDP中校驗和就是使用CRC的方式來完成的
數據在網絡傳輸中是可能會出現錯誤的，例如比特翻轉（0變成1，1變成0），基于數據內容生成校驗和
主機A對數據內容進行校驗和后發送給主機B，主機B再對傳輸來的數據繼續進行一遍校驗和，如果不相等就舍棄。
CRC算法是一個簡單粗暴的計算校驗和方式，循環冗余校驗。
設定2個字節的變量，把數據的每個字節取出來，往這個變量上進行累加，如果結果溢出超過兩個字節，溢出部分就舍棄
TCP
TCP的報文格式：
四位首部長度（是可變長的）：指的是報頭的長度
如果選項沒有，tcp報頭的長度就是20字節
如果選項拉滿，tcp報頭最長為60個字節
4bit表示的數據范圍為：0-15，此處首部長度的單位是“4字節”，實際首部長度要在這個數字基礎是*4
選項部分最多可能有40個字節
這里的PSH（就是你速度給我會消息，催單用的）
TCP10個比較核心的機制
1.確認應答機制
對于TCP協議來說，可靠傳輸是一個很重要的問題
我們可以發現在報文中也有一個ack，當這個ack為1時，說明這個是應答報文
但在網絡傳輸中可能會出現后發先至的問題（你如在微信聊天的時候，你發給你的好友兩條消息，你的好友會分別回應你這兩條消息，但是由于后發先至的問題，你看見的是你的好友對于你的第一條他是第二條回應的）
為了解決這個問題，我們用32位序號和32位確認序號，
由于tcp是根據“字節”來進行編號的
2.超時重傳
用來應對網絡出現丟包的情況
一般情況下，TCP是通過確認應答來確定數據是否被接收端收到
在前面的確認應答機制中，發送方是通過接受方返回ACK來確定接受端是否收到了數據，假設在發送端發送的數據出現了丟包的情況，那么接受端就不會給發送端發送ACK（正常情況下接受端在收到數據并向發送端發送ACK也是需要時間的，發送端就會進行一定的等待，但是不可能一直等吧，如果這個等待超過了這個時間閾值，那么發送端就會認為發送數據時發生了丟包，發送端就會再將數據重新發送一份給接收端，這就是重傳）
接下來我們思考這樣一個問題，既然發送的數據會發送丟包，那么接收端在發送ACK的時候會發生丟包嗎？
答案是當然會的，如果發送端沒有接受到ACK，那么就會認為數據發生了丟包的情況，超過閾值時間后就會再發一次數據給接收端，這時接收端就會有兩份一模一樣的數據（這樣的重傳是不允許的，假設你給好朋友轉賬如果觸發重傳就會再一次進行轉賬這是一個嚴重的問題）但是對于這種情況大佬早已為你解決，去重）
注意：無論tcp底層重傳多少次，但核心機制都要保證應用層讀到的數據只能有一份
如何進行去重？
發送端在未收到ACK的條件下，會再次向接收端發送一次數據，此時接收端會有兩份數據，在接收端會按照序列號來進行去重。
接收端的操作系統內核中，存在一個數據結構“接受緩沖區”類似于阻塞隊列，將接受的數據按序列號放入阻塞隊列中，在隊列中進行判斷，判定這個數據是否在隊列中存在或是否以前曾出現在隊列中，這要出現過這個數據就不會進入隊列，直接丟棄（當然在你丟棄的時候，接收端的操作系統內核就知道發生了ack丟包的情況，會再發送一次ack給發送端）這就是一次完整的去重
假設你說我就是想多發一次，不好意思序號是不同的，且序號是協商的不是人為
接受緩沖區除了去重還可以排序，解決在網絡傳輸中先發后至的問題，在接受緩沖區中根據序號的大小進行排序。
上述我們談到了發送端會在閾值時間內等待接收端發送ACK，那么這個等待時間是多少呢？
這個時間不是一個固定數值而是動態變化的，隨著重傳次數的增加等待時間也增加。
如果在網絡傳輸中確實出現了嚴重的故障，重傳的很多次還是沒有成功，達到一定次數后，就會嘗試重置連接，即那六個標志位的RST標志位（復位報文），通信雙方清空在這次連接中 的緩沖區的所有數據，重新進行傳輸。當然這個報文也是要進行傳輸的，如果出現嚴重的故障這個報文也是無法發送出去的，此時重置失敗，只能斷開連接（這個斷開連接就是把保存的信息全部刪除掉）
綜上所述，確認應答機制和超時重傳對于可靠性傳輸是很重要的
3.連接管理
建立連接的流程：三次握手（一定是客戶端先發起第一次請求）
斷開連接的流程：四次揮手（客戶端和服務器都可以發出請求）
建立連接就是通信雙方保存對方的信息，完成上述過程要經過三次網絡交互
SYN（sychronized）同步 也是TCP報頭六位標志位之一
為什么要進行三次握手呢？
首先是為了確保網絡傳輸通道是否暢通（就像地鐵的早上第一輛車，查看是否有異常），其次為了保證發送端發送和接收端接受正常（舉個例子在打電話有a和b兩人，a說話（SYN）后b回應（SYN+ACK）這就讓a知道我話筒和聽筒都好著，b就知道字節的聽筒好著，但是不知道話筒有沒有問題，a再回應b（ACK）這時候雙方都能確認可以進行正常通話） ，再次在進行連接管理的時候會將tcp報頭發送過去，報頭包括SYN位為1，還有端口號和ip（肯定要加ip報頭才能發送），這樣就能讓通信雙方保留對方的信息 ，還有在這三次握手中還要協商一些必要的參數，比如起始序號，從多少開始然后以字節為單位進行排序
一些特殊情況：比如第一次建立連接所發送的數據報在第一次斷開連接后未到達，但是在第二次建立連接后到達了，這種情況下，到達的數據報會直接丟棄，那么我們如何區分這個數據報是不是以前建立連接的報文呢，根據序號就可以判斷出來，建立連接時的起始序號時差異很大的
TCP狀態
斷開連接（四次揮手）
舉個例子：假設有兩個人a（客戶端）和b（服務器） a對b說我要把你刪了，b回應知道了，那我也要把你刪了，a回應說好。 相互刪除，誰怕誰
根據上述圖，可以合并為三次揮手嗎？答案是可以的，不過得是特殊情況
首先為什么不能合并？
在客戶端的FIN發來時，服務器會立即發送一個ACK過去，但在服務器中要應用程序調用close的時候才會給客戶端發送FIN兩個的時間相隔很久，所以不能合并
在特殊情況下又能合并
在tcp中還有一個機制，”延時應答機制“，我會給你發送ack，但不是這會，這樣就可以等待一起發送
四次揮手的重要狀態
CLOSE_WAIT:等待應用程序調用close方法
TIME_WAIT：應對最后一個ack丟包這樣的場景
客戶端在收到服務器發送的fin之后，不能立即釋放tcp連接（如果立即釋放的，后續一旦對端重傳了fin，此時客戶端就無法應對了，無法返回ACK）
因此客戶端這邊就需要一個特殊狀態TIME_WAIT狀態等待可能到達的fin重傳的數據。
TIME_WAIT狀態不是持續的，而是有一定時間限制的（等待時間，一般時2MSL），在一定時間內，如果沒有收到重傳的fin，就默認最后一個ack已經被對方接收，此時TIME_WAIT釋放，tcp連接釋放
如果服務器出現大量的TIME_WAIT怎么處理？
出現大量TIME_WAIT說明服務器這邊觸發大量主動斷開tcp連接的操作
4.滑動窗口
滑動窗口是一種提高傳輸效率的機制
這是不引入滑動窗口的數據傳輸過程
這是引入滑動窗口的數據傳輸過程
窗口即不等待ack，批量發送數據的過程
滑動窗口中，批量發送的四組數據，不是等待四組數據的ack全部返回后再進行下一組，而是返回一組的ack，繼續再發送一組
5.流量控制
流量控制是根據在批量轉發數據時，窗口的大小，窗口越大單位內發送的數據就越多，效率就越高，在通常情況下我們肯定是希望單位時間內發送的數據越多越好，但是要保證可靠性，如果發送方太快處理不過來，就有可能引起丟包，這種控制單位時間發送數據的效率以及保證其可靠性的過程叫做流量控制（接收方根據自己的處理速度來約束發送方的速度，使發送數據達到一個平衡）
那么具體如何衡量接受方的速度？
在接收放有一個接受緩沖區（相當于一個阻塞隊列），根據這個緩沖區的空閑大小來設置窗口大小，在我們的tcp報頭中有16位窗口大小，也就是說就這個16位窗口大小來說最多是64kb，但實際上可以更大，因為在我們的選項中可以設置窗口擴展因子（窗口大小<<窗口擴展因子）
擁塞控制
這也是一個與滑動窗口相配合的機制
流量控制是以接收端的角度去思考的，而擁塞控制則是站在網絡節點，在網絡傳輸中，每個網絡節點的繁忙程度也各有不同，接受方可以每秒接受很多數據，但是發送的數據就會很有可能卡在半路，發送太快最后引發BUG，這樣我們就得去實驗：
先將窗口大小以很小的速度進行發送，然后逐漸增加直到出現丟包，然后減小到不丟包了繼續增加。
這樣我們就可以得到一個合適的窗口大小，不僅僅可以以最快的速度傳輸，還能保障傳輸的速度，由于網絡是多變的，為了更好的提高數據傳輸的效率，動態平衡隨時調整窗口大小
- 剛開始以比較小的窗口進行數據傳輸
- 按照指數的方式擴大窗口
- 在指數增長到某個閾值后變成線性增長
- 線性增長到一定程度后出現丟包
- 縮小窗口（方式1：回到剛開始的慢啟動。方式2：縮小到一半大小）
7.延時應答
在發送端發送數據后，接受端并沒有立刻回應（返回ACK）
延時的目的是為了提高傳輸效率，通過延時可以給應用程序騰出來更多消費時間，就像你現在直接返會ACK，接受端的接受緩沖區是4kb，你等待一會，接受緩沖區消化一部分后就有4.5kbl，這樣他的窗口大小就可以更大，傳輸效率也就越快了
延時時間的兩種方式：1.按照一定的時間來指定延時 2.按照一定的數據量
一般情況下兩者結合使用
8.捎帶應答
建立在延時應答的基礎上，提高效率的
用白話就是說，我看電影，想去上廁所，順帶著倒了杯水。
我們在講四次揮手的時候，就提到特殊情況下，可以變為三次揮手。就是讓延時應答發送端的FIN，然后等待接收端也要給發送端FIN的時候捎帶著把應答報文一起發送給發送端
9.面向字節流
在字節流的讀取過程中會涉及到一個非常關鍵的問題：粘包問題（粘的是應用層數據報）
解決方式：分隔符（在1.1中寫代碼時為什么要加分隔符號的原因）
10.異常問題
1.進程突然崩了
在這種情況下，操作系統任然可以正常回收釋放的PCB，釋放里面的文件描述符表，雖然進程沒了，但操作系統任然管理著tcp的連接，可以正常完成四次揮手斷開連接
2.某個主機被關機
關機的時候會彈出讓你結束所有你打開的應用進程，然后就是和進程崩了一樣的處理。
3.如果直接物理關機
假設接收端掉電，發送端發送數據但結果時得不到回應，重傳一定次數后，發送復位報文RST，RST沒響應就把他刪了
假設發送端掉電，接收端等半天沒機發消息，發送個心跳包給接收端問他嗝屁沒，嗝屁了就刪了所有信息
4.網線斷開
發送端發送RST，沒回應，刪！
接收端發送心跳包，沒回應，嗝屁了，刪！
)
