作者 | 雨田

小編 | CACTUS

在智能汽車加速邁入數字化的今天，車載以太網早已不是簡單的 “數據通道”，而是像縱橫交錯的城市快速路網絡，日夜承載著自動駕駛的決策指令、智能座艙的影音交互數據、云端互聯的實時路況信息 —— 這些數據洪流如同高速行駛的車流，一旦出現 “丟件”“堵車”，小則影響車機使用體驗，大則關乎自動駕駛的安全決策。而在這條 “信息高速公路” 上，有一位默默守護的 “衛士”，始終確保關鍵數據不丟失、不錯亂、準時抵達目的地，它就是我們今天要聊的核心 ——TCP 協議。

TCP 協議概念

TCP協議（Transmission Control Protocol，傳輸控制協議）是車載以太網中的核心組件之一，主要運行于OSI模型的傳輸層。作為一種面向連接、可靠且基于字節流的傳輸層通信協議，TCP憑借其多項關鍵機制包括三次握手、四次揮手、確認應答、超時重傳、滑動窗口、擁塞控制以及保活機制等有效保障了數據傳輸的可靠性與穩定性，確保數據在網絡中有序、無誤地傳輸。

TCP報文結構

TCP協議報文也稱TCP報文段，是TCP通信的基本單元，一個TCP報文段由首部和數據兩部分組成，其中首部包含了必要的控制信息，確保數據的正確傳輸和連接管理，下圖是TCP報文結構，并對TCP首部進行了格式解析：

源端口號：占16 位，表示發送方的端口號，取值范圍0~65535；

目的端口號：占16位，表示接收方的端口號，取值范圍0~65535；

序列號：占32位，表示本報文段所發送的數據的第一個字節的序號，取值范圍0~2^32 – 1，當序號增加到2^32-1后，下一個序號就又回到0；

確認號：占32位，表示期望收到對方下一個報文段的第一個數據字節的序號；

首部長度：占4位，表示TCP首部數據長度，以4字節為單位計數，最大長度為60字節；

標志位：占6位，包括URG、ACK、PSH、RST、SYN、FIN 6個標志位；

URG：占1位，緊急指針標志，當URG被設置1時，緊急指針字段有效；

ACK：占1位，確認標志，當ACK被設置1時，確認號字段才有效；

PSH：占1位，推送標志，當收到TCP報文段中的PSH值為1時應盡快將數據傳遞給應用程序，不需要等到整個緩存都填滿后再向應用層傳遞；

RST：占1位，重置連接標志，當RST被置1時表示連接錯誤或者連接被拒絕；

SYN：占1位，同步標志，用于連接建立，當SYN被置1時表示一個連接請求或連接接收報文；

FIN：占1位，結束標志，用于關閉連接；

窗口大小：占16位，表示接收方希望一次接收多少字節；

檢驗和：占16位，用于校驗數據的完整性；

緊急指針：占16位，當URG標志置1時緊急指針才有效，緊急指針是一個正的偏移量，和序列號字段的值相加表示緊急數據最后一個字節的序號；

選項：可變長度，最大長度為40字節【計算方式 ：首部總長度-20字節固定長度】，由于TCP首部的偏移單位為4 字節，當選項占用字節個數不是4字節的整數倍時，需要進行數據填充。

以下為Wireshark數據示例

TCP連接建立與終止

TCP協議是一種面向連接的協議，在進行數據傳輸之前，需通過三次握手建立連接，數據傳輸完成后，通過四次揮手斷開連接。

1.三次握手

1）第一次握手(SYN)：客戶端向服務端發送一個SYN報文，并且會隨機生成一個客戶端的序列號(seq)。

2）第二次握手(SYN-ACK)：服務端收到來自客戶端的SYN報文后也會生成一個隨機的序列號，同時也會計算出確認號(Ack)，并通過SYN-ACK 報文發送給客戶端，該確認號(Ack)也會告知客戶端下一次期望接收到報文序列號是多少。

3）第三次握手(ACK)：客戶端收到來自服務端的SYN-ACK 報文后，會發送一個ACK報文通知服務端，確認接收到了序列號并可以開始通信。

三次握手過程如圖所示，此過程確保了雙方都能確認對方的連接能力，從而建立起一個可靠的，雙向的通信通道。

2.四次揮手

1）第一次揮手(FIN)：客戶端發送一條FIN報文，通知數據發送完畢，希望關閉連接。

2）第二次揮手(ACK)：服務端回復一條ACK報文，確認收到了客戶端FIN報文，ACK報文中的確認號是收到FIN報文的序列號加1，表示所有數據已被接收。

3）第三次揮手(FIN)：服務端發送完所有數據后，也會發送一條FIN報文給客戶端，通知數據發送完畢，準備關閉連接。

4）第四次揮手(ACK)：客戶端回復一條ACK報文，確認收到了服務端的FIN報文，至此，連接完全關閉。

如下圖所示，四次揮手機制確保了雙方都有機會發送完所有數據，并且相互確認了對方的終止請求，從而實現了TCP連接的優雅關閉。

在揮手過程中涉及到幾種狀態，如下所示：

ESTABLISHED狀態：已建立連接的狀態，可正常收發數據；

FIN-WAIT-1狀態：客戶端向服務端發送FIN報文后進入FIN-WAIT-1狀態，此狀態下可以接收數據，禁止發送新數據；

FIN-WAIT-2狀態：客戶端接收到ACK 報文后進入FIN-WAIT-2狀態，此狀態可以接收數據，停止發送新數據；

CLOSE-WAIT狀態：服務端發送ACK 后進入CLOSE-WAIT狀態，此狀態可以發送數據，停止接收新數據；

TIME-WAIT 狀態：客戶端接收到來自服務端FIN報文并返回ACK后進TIME-WAIT 狀態，該狀態持續時間為2MSL(Maximum Segment Lifetime，最大報文段生存時間);

LAST-ACK 狀態：服務端發送FIN報文后進入此狀態等待客戶端發送ACK報文；

TCP的重要機制

1.確認應答與超時重傳

TCP 通過確認應答(ACK)實現可靠的數據傳輸，在建立TCP連接時會雙方都會產生一個屬于自己的序列號，當服務端收到數據后會根據seq信息判斷是否所期望的數據序號，判斷沒問題后會響應一條ACK 報文告知對方已發送成功。

如下圖所示：

數據在網絡通道上傳輸常常會遇到突發情況，導致數據未發送到目的地，遇到這種情況TCP協議作為交通指揮官將會行使自己的超時重傳權力來處理突發狀況。如下兩種情景所示：

情景一：當客戶端在一定時間內沒有收到確認應答，會認為自己數據已經丟失并進行重傳。

如下圖所示：

情景二：服務端回復了確認應答，但是服務端在一定時間內并未收到，則客戶端也會進行重新發送。

如下圖所示：

由以上兩種情景可知，當客戶端在一定時間內未接收到應答報文才會進行重傳，這個時間定義為超時重傳時間(RTO)，如果重傳后還未接收到應答報文，則重傳時間為2*RTO，以此類推，每重傳一次RTO值會加倍，這種行為也稱為指針退避策略。

2.滑動窗口機制

通過TCP 的確認應答和超時重傳機制可知，每發一個TCP報文段時都要等待對方的應答報文，這樣的傳輸方式降低了網絡吞吐量，為了解決這個問題，TCP協議又增加一個滑動窗口功能。簡單的講，在服務端的窗口大小范圍內發送一個TCP報文段后不必要一直等待確認應答，而是可以繼續發送。

假設需要發送1000字節數據，TCP最大報文段為100字節，服務端窗口大小為400字節，數據該如何進行傳輸呢？

如下圖所示：

服務端滑動窗口：當收到TCP報文段數據總長度為400字節時，已占滿了整個窗口大小，此時無法再接收其他數據，需要確認接收后才可以釋放一定的緩存空間。

如下圖所示：

客戶端滑動窗口：

3．擁塞控制機制

通過滑動窗口、確認應答、超時重傳等機制都體現了TCP協議傳輸的可靠性，當網絡擁堵狀態下，由于客戶端接收不到確認應答報文會在一定時間內進行數據重傳，這樣反而加重了擁堵程度，而TCP的擁塞控制就是避免將過多的數據包被發送到網絡中，導致網絡擁堵和數據丟失，TCP擁塞控制算法包括以下四個主要部分：

（1)慢啟動

慢啟動為發送方的TCP增加了另一個窗口：擁塞窗口(congestion window)，記為cwnd，當兩個主機建立TCP連接時，假定擁塞窗口被初始化為1個報文段(MSS)。發送方開始時發送一個報文段，然后等待ACK。當收到該ACK時，擁塞窗口從1增加為2， 即可以發送兩個報文段。當收到這兩個報文段的ACK時，擁塞窗口就增加為 4，這是一種指數增加的關系。

如下圖所示：

（2）擁塞避免

因慢啟動中擁塞窗口呈指數增長，當達到一定值時會再次造成網絡擁塞，為避免這種現象，將設置一個閾值，當達到閾值后擁塞窗口將進行緩慢增長，這種方法稱為擁塞避免算法，而這個閾值稱為慢啟動閾值(slow start threshold)，記為ssthresh，擁塞避免算法需要維持兩個變量：一個擁塞窗口和一個慢 啟動閾值。

工作過程下圖所示：

在該圖中，設置ssthresh初始值為16個報文段，在時刻0發送了一個報文段，在時刻1收到它的ACK，此時cwnd 增長為2，接著發送了2個報文段，并假定在時刻2接收到它們的ACK，于是cwnd增加為4(對每個ACK增加一次)，這種指數增長方式一直進行到時刻3和4之間收到8個ACK后，cwnd等于ssthresh時才停止，從此刻起，cwnd以線性方式增長，在每個往返時間內最多增加一個報文段，假設在時刻4和5之間出現了超時情況，則重新進入慢啟動，此時cwnd 為1，ssthresh值更新為cwnd/2。

（3）快速重傳

客戶端如果連續收到3個或者3個以上的重復ACK，此時會認為某一報文段丟失并立刻進行重傳而不需要等待超時重傳的時間，這種策略稱為快速重傳算法。

如下圖所示：

1）客戶端發送數據Seq1，服務端接收到返回Ack2（希望下一個數據的Seq號信息2）；

2）客戶端發送數據Seq2，因某種原因使其發送數據中斷無法到達；

3）客戶端繼續發送數據Seq3，因服務端未收到期望的Seq2的數據信息，繼續回復Ack2；

4）客戶端繼續發送Seq4，同理，服務端繼續回復Ack2；

5）當客戶端接收到三次重復的Ack2信息后確認發送數據Seq2丟失，客戶端重新發送Seq2，服務端接收到Seq2數據后，回復Ack5告知客戶端Seq1-Seq4數據段全部接收成功，期望下一次接收的數據信息為Seq5；

（4）快速恢復

當快速重傳之后，不經過慢啟動過程而直接進入擁塞避免階段，這就是快速恢復算法，未經過慢啟動的原因是因為接收方只有收到另一個報文段時才會產生重復的ACK，也說明了后續的報文段已經成功發送到服務端的緩存中，并不需要減少網絡上的數據流，快速恢復算法過程如下所示：

1）當收到第3個重復的ACK時，將ssthresh設置為當前擁塞窗口的一半，并重傳丟失的報文段，設置cwnd為ssthresh +3個報文段；

2）每次收到另一個重復的ACK時，cwnd增加一個報文段大小

3）當收到對丟失報文和其后若干報文段的累計確認后置cwnd=ssthresh，進入擁塞避免階段。

4.保活機制

保活機制(Keep-Alive) 是確保TCP連接處于活動狀態或者及時檢測并關閉空閑連接的一種方法。關于保活機制有以下幾個重要參數：

保活時間：處于非活動狀態的時間內

保活時間間隔：兩個保活探測報文的時間間隔

保活探測數：探測報文的最大次數

描述：如果在保活時間內連接處于非活動狀態，則TCP一端將會開啟保活機制向另一端發送保活探測報文，如果客戶端沒有收到響應報文，則經過保活時間間隔后會再次發送一條保活探測報文，直到發送次數達到保活探測數，此時將認為另一端不在線，并關閉TCP連接。保活探測報文的報文段長度為0或者包含一個字節的數據，序列號為對方主機最大應答號減1

TCP在車載以太網中扮演關鍵角色，通過連接管理、確認應答、超時重傳、擁塞控制等機制，實現數據的高效、可靠傳輸，其實現遵循國際標準文檔（如RFC793），從而保證不同廠商提供的TCP實現具備良好的互通性與兼容性，為OTA、診斷、信息 娛樂等核心功能提供了堅實的網絡基礎。

與此同時，OPEN聯盟發布了相應的測試規范，其中《OPEN Alliance Automotive Ethernet ECU Test Specification Layer 3-7》明確列出了TCP協議的測試項目，包括標志位測試、窗口測試、序列號測試等，為行業提供了統一的驗證依據。

北匯信息作為一家專注于汽車電子測試領域的企業，在車載以太網測試方面積累了豐富經驗。我們可提供專業的培訓、技術咨詢及完整的測試解決方案，協助汽車制造商與零部件供應商確保車載以太網系統的可靠性及安全性。如您需要具體的測試服務或希望了解更多信息，歡迎隨時聯系我們。

參考文獻：

【1】《TCP/IP詳解 卷1：協議》

【2】《車載以太網權威指南》

【3】《RFC 793文檔》