1.確認應答機制

由于發送信息的距離可能較遠,可能出現后發的信息先到的情況,怎么辦?

TCP將每個字節的數據都進行了編號,即為序列號

如何分辨一個數據包是普通數據還是應答數據呢

2.超時重傳

由于丟包是一個隨機的事件,因此在上述tcp傳輸的過程中,丟包就存在兩種情況

但是在發送方的角度,無法區分這兩種情況

無論出現哪種情況,發送方都會進行"重新傳輸"

所以udp一般延遲比較低

如果a給b發了消息,而b回復的數據丟了,那a就會超時重傳一條一樣的數據過去

3.連接管理機制

3.1 建立連接,TCP三次握手

TCP在建立連接的過程中,需要通信雙方一共"打三次招呼",才能發完成連接建立的

ack和syn同時為一,此時就是三次握手了

3.2 連接斷開,四次揮手

建立連接一般是客戶端主動發起

斷開連接,客戶端和服務器都可以主動發起

和三次握手不同,此處的四次握手,不一定能把中間的兩次交互合并

不能的原因:ack和第二個fin的觸發時機是不同的

ack是內核響應,b收到fin,就會立即返回ack

第二個fin是應用程序的代碼觸發,b這邊調用了close方法才會觸發fin

可以的原因:

3.3?問題

3.3.1 怎么判斷報文是不是同步報文段?

3.3.2 三次握手要解決什么問題? (核心作用)

這種設定,是避免前朝的劍斬本朝的官

3.3.3 兩次,三次握手是否可行?

兩次不行,四次可以,但沒必要,兩個數據合并成一個數據更高效\

4.滑動窗口機制

4.1丟包如何重傳

??

這種情況不用任何重傳,因為有確認序號機制

TCP前提是可靠性,在可靠性的前提上,再提高傳輸效率

5.流量控制

站在接收方的角度,反向制約發送方的傳輸速率

6.擁塞控制

6.1過程

在指數增長的過程中,如果達到閾值,就從指數增長,變成線性增長

線性增長也是增長,如果傳輸速率越來越快增長到一定程度,網絡上就可能會出現丟包了(網絡堵塞)

一旦觸發丟包,就把窗口大小縮小,重新進行前面的慢開始 - 指數增長 - 線性增長

并且會根據當前丟包的窗口大小,重新指定線性增長閾值(為了避免指數增長一下就達到丟包閾值)

這是經典版本的擁塞控制,后面tcp又進行了改進

最終時機發送的窗口大小,是取流量控制和擁塞控制中窗口的較小值

7.延時應答

8.捎帶應答

在延時應答的基礎上,進一步提高效率

9.面向字節流

相比之下,UDP這樣的面向數據報的通信方式就沒有這樣的問題

如何解決粘包問題?

前面寫的回顯服務器,就是這樣的方式

10.異常情況處理

10.1 進程崩潰

10.2 主機關機(正常流程)

10.3 主機掉電

10.4 網線斷開

11.TCP的心跳機制