TCP協議的案例
圖文解析TCP協議
來源 |
面包板社區
TCP 是互聯網核心協議之一，本文介紹它的基礎知識。
一、TCP協議的作用
互聯網由一整套協議構成。TCP 只是其中的一層，有著自己的分工。
圖1：TCP 是以太網協議和 IP 協議的上層協議，也是應用層協議的下層協議
最底層的以太網協議（Ethernet）規定了電子信號如何組成數據（packet），解決了子網內部的點對點通信。（圖片說明：以太網協議解決了局域網的點對點通信。）
但是，以太網協議不能解決多個局域網如何互通，這由 IP 協議解決。
圖2：IP 協議可以連接多個局域網。IP 協議定義了一套自己的地址規則，稱為 IP 地址。它實現了路由功能，允許某個局域網的 A 主機，向另一個局域網的 B 主機發送消息
圖3：路由器就是基于 IP 協議。局域網之間要靠路由器連接
路由的原理很簡單。市場上所有的路由器，背后都有很多網口，要接入多根網線。
展開 一文入門車載以太網，吐血整理! 不看可惜！
該協議頭的各部分解釋如下圖：
圖9 IPV4 協議頭信息表
IPV6協議頭
圖10 IPV6 協議頭
需要注意的是IPv6 數據報文是 IPv4 的 4 倍，IPv6 數據報文主要由兩個部分組成：Header（首部）和 Payload（負載）。其中，IPv6 Header 的大小是 IPv4 的 2 倍。該協議頭的各部分解釋如下圖：
圖11 IPV6協議信息表
傳輸層
傳輸層的協議就是TCP/UDP，這兩者協議彼此獨立，也可以同時存在，看具體使用場景需求。TCP/UDP作為傳統以太網的標準協議，在這里同樣不做過多展開，僅整體介紹下TCP與UDP的特點及區別。
TCP協議
TCP協議頭
圖12 TCP協議頭
如下圖13所示為TCP協議頭的字段解釋：
圖13 TCP協議頭信息表
TCP建立連接過程
TCP是面向連接的可靠的網絡通信，因此要通信雙方建立通信連接，必須經過我們常說的“三次握手”才能夠開啟以太網通信，如下圖14所示為TCP的“三次握手”連接過程。
展開 36張圖詳解計算機網絡知識點
TCP協議的功能：
對應用層報文進行分段和重組；
面向應用層實現復用與分解；
實現端到端的流量控制；
擁塞控制；
傳輸層尋址；
對收到的報文進行差錯檢測（首部和數據部分都檢錯）；
實現進程間的端到端可靠數據傳輸控制。
TCP協議的特點：
TCP是面向連接的協議；
TCP是面向字節流的協議；
TCP的一個連接有兩端，即點對點通信；
TCP提供可靠的傳輸服務；
TCP協議提供全雙工通信（每條TCP連接只能一對一）；
5.2.1 TCP報文段結構：
最大報文段長度：報文段中封裝的應用層數據的最大長度。
TCP首部：
序號字段：TCP的序號是對每個應用層數據的每個字節進行編號；
確認序號字段：期望從對方接收數據的字節序號，即該序號對應的字節尚未收到。用ack_seq標識；
TCP段的首部長度最短是20B ，最長為60字節。
展開 弱電人必須掌握的計算機網絡基礎知識
OSI參考模型層次結構，OSI參考模型自下而上分為七層：
TCP/IP協議棧概述
TCP/IP起源于60年代末美國政府資助的一個分組交換網絡研究項目，到90年代已發展成為計算機之間最常用的組網形式。TCP/IP是一個真正的開放系統，因為其協議簇的定義及其多種實現可以免費或花費很少就可以公開地得到。TCP/IP是“全球互聯網”或“因特網”Internet的基礎。
與OSI參考模型一樣，TCP/IP對等模型也分為不同的層次，每一層負責不同的通信功能。五層對等模型是OSI和TCP/IP模型的綜合。
TCP/IP協議棧
IP協議是盡力傳輸的網絡協議，其提供的數據傳送服務是不可靠的、無連接的。IP協議不關心數據包的內容，不能保證數據包是否成功到達目的地，也不關心任何關于前后數據包的狀態信息。面向連接的的可靠服務由上層的TCP協議實現。所有的TCP、UDP、ICMP及IGMP等數據都最終封裝在IP報文中傳輸。
物理層功能
物理層主要是：規定介質類型、接口類型、信令類型 ；規范在終端系統之間激活、維護和關閉物理鏈路的電氣、機械、流程和功能等方面的要求；規范電平、數據速率、最大傳輸距離和物理接頭等特征；
同步串口可作為DCE 或者DTE，支持多種物理層協議：V.24/V.35/X.21 等協議，異步串口支持RS232 協議，最大速率為115.2kbit/s。G.703 E1/T1接口類型。
展開 
技術分享 | 車載以太網技術的深度解析與核心應用
（4）成本與標準化優勢
減少線束成本：單對非屏蔽雙絞線（如100BASE-T1）替代復雜線束，降低重量和成本；
產業鏈成熟：以太網技術已被IT行業驗證數十年，芯片、協議棧成熟，且支持DoIP（診斷 over IP）等標準化協議，簡化開發；
（5）面向未來的擴展性
車云協同與V2X：支持5G/V2X集成，實現車-路-云實時通信，為智慧交通奠定基礎。
功能安全與信息安全：基于以太網的防火墻、加密（如MACsec）更易實現符合ISO 21434的網絡安全要求。
三、車載以太網的技術架構
車載以太網(Automotive Ethernet)基本遵循OSI七層網絡模型，但在某些層面上進行了優化和簡化，以適應汽車電子系統的需求。
1、車載以太網與常規以太網的主要區別
網絡模型層級之間的區別：
（1）傳輸層
常規以太網的傳輸層會根據具體場景選擇UDP或者TCP協議，在需要面向連接、高可靠性場景中選擇TCP協議，在對實時性更高，需要高速傳輸的場景下選擇無邊車接的UDP協議，車載以太網中也會根據具體場景選擇對應傳輸層協議，大部分場景中使用實時性更高的UDP協議。
（2）網絡層
車載以太網的網絡層使用標準的IPv4/IPv6，同時配合DoIP和SOME/IP進行診斷和ECU之間的高效通信。
a. 普通數據通信→IPv4/IPv6；
b. 車載診斷&遠程升級→DolP (Diagnostics over IP)；
c. ECU之間的服務通信→SOME/IP。
展開 三菱Q系列PLC和WinCC以太網通訊的組態步驟
2、通過 TCP 協議通訊
PLC 組態步驟
（1） PLC 通訊協議設置：
WinCC 設置步驟
（1）WinCC 連接參數：
注意：網絡編號和 PC 編號可以對應 PLC 中的網絡號和站號，也可以使用默認值（網絡編號為 0，PC 編號為 255）。此處端口號為 PLC 的端口號（十進制），但需要注意（擴展的以太網模塊使用TCP 協議時）：當 WinCC 連接 Q 系列 PLC 擴展的以太網模塊使用 TCP 協議時，PLC 端口號不能設為 1388（十六進制）和 1389（十六進制），否則通訊不上。
轉發是最大的鼓勵！謝謝您的支持！
重要通知
想加入工控PLC學習技術交流群
請添加班長為好友
并備注：地區-行業-姓名昵稱獲取進群資格。
展開 三菱Q系列PLC和WinCC以太網通訊的組態步驟
此處端口號設定需要注意（擴展的以太網模塊使用 UDP 協議時）：當 WinCC 連接 Q 系列 PLC 擴展的以太網模塊使用 UDP 協議時，此處端口號需要設為 5000 或 5001（不論 PLC 端口設為多少）。
2、通過 TCP 協議通訊
PLC 組態步驟
（1） PLC 通訊協議設置：
WinCC 設置步驟
（1）WinCC 連接參數：
注意：網絡編號和 PC 編號可以對應 PLC 中的網絡號和站號，也可以使用默認值（網絡編號為 0，PC 編號為 255）。此處端口號為 PLC 的端口號（十進制），但需要注意（擴展的以太網模塊使用TCP 協議時）：當 WinCC 連接 Q 系列 PLC 擴展的以太網模塊使用 TCP 協議時，PLC 端口號不能設為 1388（十六進制）和 1389（十六進制），否則通訊不上。
轉發是最大的鼓勵！謝謝您的支持！
重要通知
想加入工控PLC學習技術交流群
請添加班長為好友
并備注：地區-行業-姓名昵稱獲取進群資格。
展開 Modbus 的RTU、ASCII、TCP傻傻搞不清楚？一文全解讀
該協議物理層，數據鏈路層，網絡層，傳輸層都是基于TCP 協議，只在應用層，將Modbus 協議修改后封裝進去; 接收端將該TCP 數據包拆封后，重新獲得原始Modbus 幀，然后按照Modbus 協議規范進行解析，并將返回的數據包重新封裝進TCP 協議中，返回到發送端。與串行鏈路傳輸的數據格式不同，TCP 模式去除了附加地址和校驗，增加了報文頭，其具體格式如圖4所示。
在modbus TCP中包含一個MBAP頭，該頭包含以下幾個部分：
區域
長度
描述
客戶端
服務器
傳輸標志
2字節
MODBUS 請求和響應傳輸過程中序列號
客戶端生成
應答時復制該值
協議標志
2字節
Modbus協議默認為0
客戶端生成
應答時復制該值
長度
2字節
剩余部分的長度
客戶端生成
應答時由服務器端生成
單元標志
1字節
從機標志（從機地址）
客戶端生成
應答時復制該值
注意：
a.傳輸標志可理解為序列號，防止 MODBUS TCP通信錯位，例如后發生的響應先到了主機，而早發生的響應后到主機；
b.單元標志可理解為從機地址，此時已經不再重要。
6.4 modbus tcp 和 TCP IP的關系
modbus TCP可以理解為發生在TCP上的應用層協議，既然是TCP協議那么一個完整的MODBUSTCP報文必然包括TCP首部，IP首部和Ethernet首部。
07
功能碼作用
啟動Modbus事務處理的客戶機創建Modbus應用數據單元。功能碼（PDU中的）向服務器指示將執行哪種操作。
展開 北斗賦能，無人劃線小車讓智慧施工升級
內置高精度雙天線GNSS板卡，4G全網通模塊、藍牙模塊，支持NTRIP CLIENT 協議、TCP/IP協議,支持JT808協議，支持千尋云蹤實時地圖顯示軌跡與位置，定位精度水平約1CM，高程精度約2CM。 支持聯通、移動、電信4G向下兼容3G、2G。設備供電后自動接收衛星信號，撥號上網，接入千尋知寸服務，獲得高精度位置信息，通過串口輸出給主控設備，也可以通過4G回傳到千尋FindS服務器或者用戶服務器。特別適用于需要高精度位置及方向信息的各種功能無人小車集成用戶及無人機用戶。
GNSS板卡OEM982的產品亮點
1、多星多頻，厘米定位
同時支持北斗 BDS B1I/B2I/B3I，GPS L1C/A/L2P (Y)/L2C/L5，Galileo E1/E5a/E5b，GLONASS G1/G2，QZSS L1/L2/L5全球定位系統，RTK厘米級定位定向模塊。
2、內置4G，三年免流
內置4G全網通模塊，全面支持移動，聯通和電信網絡，全面通訊覆蓋。內置e-SIM芯片，內含三年數據流量，免除辦卡充值煩惱。也可以根據客戶的需求保留SIM卡座。
3、千尋服務，自動接入
首次使用，配置相關千尋服務參數完成之后，每次使用只需要供電即可，自動接入千尋差分服務器，獲取差分數據，輸出高精度數據。
4、一鍵固定，智能互聯
內置高精度定位模塊，內置4G通訊模塊，供電自動撥號上網，自動接入千尋服務，無需復雜操作。
5、數據回傳，實時監控
支持實時定位信息回傳服務器，可以監控所有設備實時位置信息。支持TCP協議和JT808協議，無縫接入千尋云蹤FindS服務。
6、飛控接口，二次開發
整機僅重約12g，小巧便攜。具備無人機飛控接口，PIXHAWK/APM 即插即用。
展開 Modbus 的RTU、ASCII、TCP傻傻搞不清楚？一文最全解讀
該協議物理層，數據鏈路層，網絡層，傳輸層都是基于TCP 協議，只在應用層，將Modbus 協議修改后封裝進去; 接收端將該TCP 數據包拆封后，重新獲得原始Modbus 幀，然后按照Modbus 協議規范進行解析，并將返回的數據包重新封裝進TCP 協議中，返回到發送端。與串行鏈路傳輸的數據格式不同，TCP 模式去除了附加地址和校驗，增加了報文頭，其具體格式如圖4所示。
在modbus TCP中包含一個MBAP頭，該頭包含以下幾個部分：
區域
長度
描述
客戶端
服務器
傳輸標志
2字節
MODBUS 請求和響應傳輸過程中序列號
客戶端生成
應答時復制該值
協議標志
2字節
Modbus協議默認為0
客戶端生成
應答時復制該值
長度
2字節
剩余部分的長度
客戶端生成
應答時由服務器端生成
單元標志
1字節
從機標志（從機地址）
客戶端生成
應答時復制該值
【注意】
【1】傳輸標志可理解為序列號，防止 MODBUS TCP通信錯位，例如后發生的響應先到了主機，而早發生的響應后到主機
【2】單元標志可理解為從機地址，此時已經不再重要
6.4 modbus tcp 和 TCP IP的關系
modbus TCP可以理解為發生在TCP上的應用層協議，既然是TCP協議那么一個完整的MODBUSTCP報文必然包括TCP首部，IP首部和Ethernet首部。
展開 專業講解S7-1500PLC通信原理，這可是高級應用的重點
（2）數據鏈路層（Data Link Layer）：確定傳輸站點物理地址以及將消息傳送到協議棧，提供順序控制和數據流向控制。典型的數據鏈路層的設備有交換機和網橋等。
MAC地址屬于數據鏈路層，相當于人的證 件。有了這一層，發送過去的比特流可以得到檢測這樣就不會出現錯誤的信息了。
（3）網絡層（Network Layer）：定義了設備間通過邏輯地址（IP-Internet Protocol因特網協議地址）傳輸數據，連接位于不同廣播域的設備，常用來組織路由。典型的網絡層設備是路由器。
IP地址是IP協議為互聯網上的每一個網絡和每一臺主機分配一個逡輯地址，以此來屏蔽物理地址的差異。有了IP地址，電腦才可以上網。IP地址分成兩個部分，前三個數代表網絡，后一個數代表主機。如 192.168.0.1中，192.168.0代表網絡，1代表主機。IP可以根據需要修改 。
（4）傳輸層（Transport Layer）：建立會話連接，分配服務訪問點，允許數據進行可靠或者不可靠的傳輸。可以提供通信質量檢測服務。網關是互聯網設備中最復雜的，它是傳輸層及以上層的設備。
把要發送的數據（大數據）進行分包進行封裝，一個包一個包發送，叫傳輸層。TCP協議和UDP協議就在傳輸層。TCP是用于發大量數據的，分包發送，沒收到的重發。UDP是用于發送少量數據的。
展開 
S7-1500 PLC的通信基礎知識
（2）數據鏈路層（Data Link Layer）：確定傳輸站點物理地址以及將消息傳送到協議棧，提供順序控制和數據流向控制。典型的數據鏈路層的設備有交換機和網橋等。
MAC地址屬于數據鏈路層，相當于人的身份 證。有了這一層，發送過去的比特流可以得到檢測這樣就不會出現錯誤的信息了。
（3）網絡層（Network Layer）：定義了設備間通過邏輯地址（IP-Internet Protocol因特網協議地址）傳輸數據，連接位于不同廣播域的設備，常用來組織路由。典型的網絡層設備是路由器。
IP地址是IP協議為互聯網上的每一個網絡和每一臺主機分配一個逡輯地址，以此來屏蔽物理地址的差異。有了IP地址，電腦才可以上網。IP地址分成兩個部分，前三個數代表網絡，后一個數代表主機。如 192.168.0.1中，192.168.0代表網絡，1代表主機。IP可以根據需要修改 。
（4）傳輸層（Transport Layer）：建立會話連接，分配服務訪問點，允許數據進行可靠或者不可靠的傳輸。可以提供通信質量檢測服務。網關是互聯網設備中最復雜的，它是傳輸層及以上層的設備。
把要發送的數據（大數據）進行分包進行封裝，一個包一個包發送，叫傳輸層。TCP協議和UDP協議就在傳輸層。TCP是用于發大量數據的，分包發送，沒收到的重發。UDP是用于發送少量數據的。
展開 車載通訊系統：車載以太網的協議簇泛讀
基本上網絡層的協議保持了一致性，只是在一定程度上禁用了部分功能，但是主體上車載和非車載協議內容保持了完全的一致性。IP協議最為重要，應用層的大部分協議是基于IP協議來作為基礎的。
車載以太網協議——傳輸層
傳輸層的情況基本上是類似網絡層，保持了車載和非車載的一致性，主要是支持ICMP、UDP、TCP。
ICMP保持了我們最基礎的測試命令的使用場景：PING和tracert功能，本身相對使用情況比較單一，大家可以熟悉一下邏輯即可；
UDP和TCP協議兩者的區別和使用場景有很多的文章展示這部分內容，后期有時間可以好好的總結一下相關的內容；
傳輸層的主要是UDP和TCP兩種傳輸協議，大家對于這部分內容可以查閱協議，內容較多，在此就不展開描述了。
車載以太網協議——應用層
應用層的協議多數是依托網絡層的IP協議，傳輸層的TCP/UDP協議來展開的，車載以太網的應用層協議主要是：UDPNM（網絡管理協議）、DHCP（動態主機配置協議）、SOME/IP（服務中間件）、DoIP（診斷協議）以及XCP（標定協議）等。
DoIP：基于以太網的診斷傳輸協議，能夠將UDS進行封裝并基于IP網絡進行傳輸；應用于車輛檢查和維修、車輛或ECU軟件的重編程、車輛或ECU的下線檢查和維修等，其主要工作原理類似于Diagnostic over CAN（或稱為DoCAN）。
備注：現階段的OBD的診斷接口是使用的常規以太網TX協議來完成，后期可以完全實現車載系統，并需要診斷設備的支持。
展開 科普 | 車載以太網入門介紹
圖6：車載以太網在底層協議和高層協議適配最多
從OSI模型來看，適配最多的地方就是底下兩層和高層協議。宏觀來看，就是兩頭的協議改動最多，中間變化不大。
底下兩層關系到物理連接和實時性。物理層很好理解。實時性是因為越往高層，裝包解包的時間就長，所以實時性主要關注底層部分。
高層協議主要是魯棒性和使用場景適應。比如要看有沒有丟包或傳輸故障，單看底層是不夠的。畢竟底層傳輸正常，不代表高層協議處理就沒問題，因而要在高層協議適配端對端（E2E）保護。而車端有很多特殊應用，例如診斷服務UDS，屬于汽車行業通用標準，而且會在各式硬件和操作系統上部署，這就需要最接近應用軟件的高層通信協議（亦即DoIP）進行適配。而近年來由SOA（面向服務的架構）帶得火熱的SOME/IP協議，同樣是基于汽車應用適配的高層協議。
中間部分的協議是車載以太網復用傳統以太網最多的部分。比如網絡層的IPv4協議，和家用以太網基本一致，所以我們常說的IP地址、IP尋址、PING（ICMP的其中一種報文）等在汽車和家用以太網上都基本保持一致。
而中間層協議中，我們還會經常聽到TCP和UDP。它們屬于平行的兩種傳輸層協議，可以用于支持不同的上層協議。而兩者的主要特點如下表格所示：
表1：TCP與UDP對比
上表可見，UDP屬于不可靠的傳輸，但是支持一對多的組播和較好的實時性。而TCP增加了握手機制和控制策略，優點是傳輸更加可靠，但同時帶來的副作用就是實時性差。不同應用場景和需求下可以采用不同的傳輸層協議。
展開 科普 | 車載以太網入門介紹
這期間積累的各式協議和規范浩如煙海，我們作為汽車工程師要去熟悉每份協議實屬困難。
也許我們可以從抽象的高層次去理解車載以太網，然后再根據各自的具體需求再有針對性地查閱相關具體的協議。例如對如業務應用的算法工程師來說，也許了解下SOME/IP協議就足夠了，底層的IP協議、MAC協議等對于上層應用不可見，無需多花時間。而這也是以太網分層協議的初衷。希望這篇文章能夠拋磚引玉，幫助大家勾起生活中對以太網的常識，同時對車載以太網有所初識。
參考來源：
1. TCP/IP Model Vs OSI Model，
https://www.ahirlabs.com/difference/tcp-ip-model-vs-osi-model/
展開 