我相信有很多網友都看過《網絡協議詳解》的前5篇內容，看后大多數人的感覺是“有點兒偏理論知識！學會這些知識對實際工作沒啥幫助！” 

為了解決大家的這些困惑，我將實際項目遇到的問題結合理論知識給大家講解，估計您看完這篇實戰案例后就覺得的理論知識的重要性。這些理論知識可以真真正正的解決大家的實際問題。有的網友可能說“我的工作不需要這樣的知識!”，而我想說的是“技不壓身”，會的東西不是越多越好嗎？

案例

好了，言歸到正題。這個案例可能有些網友在趙工的《我與PROFINET不得不說的事-08 案例分析》看到過，在這里我只想換個角度來說，我們的這個角度是：“如何將理論知識應用到實際的項目，并解決實際項目的問題”。

這個案例涉及到了TCP協議的工作原理（感興趣的可以在回顧看一下《網絡協議詳解03—TCP協議》），我們知道應用層的數據需要借助TCP傳輸層協議傳輸時，需要在通信的伙伴之間建立TCP的連接，這也是經常被稱為“三次握手”，如下圖所示：

三次握手的過程中，標志位和序列號按如下圖方式被設置：

01

第一次握手：客戶端發送標志位SYN=1, 發送序列號seq =x（這里x是客戶端操作系統初始化的一個序列號）包到服務器，并進入SYN_SENT狀態，等待服務器確認；

02

第二次握手：服務器收到SYN包，并會確認客戶的SYN 請求，

服務器會發送一個標志位SYN=1 和ACK=1，確認序列號 ack=x+1（x是剛從客戶端中接收到的發送序列號，通過x+1服務器確認收到了客戶端SYN請求包），發送序列號 seq=y（這里y是服務器操作系統初始化的一個序列號）包到客戶端，此時服務器進入SYN_RECV狀態；

03

第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送標志位ACK=1，發送序列號seq=x+1（x+1對于客戶端來說已經發送過1個SYN的包，所以此次的序列號需要在初始的序列號x的基礎上再加上1），確認序列號ack=y+1（y是剛從服務器端接收到的發送序列號，通過y+1客戶端確認收到了服務器發來的 SYN+ACK的包）。此包發送完畢，客戶端和服務器進入ESTABLISHED（TCP連接成功）狀態，完成三次握手。

可以看到握手時會在客戶端和服務器之間傳遞一些TCP頭信息，比如ACK標志、SYN標志以及揮手時的FIN標志等。

除了以上這些常見的標志頭信息，還有另外一些標志頭信息，比如推標志PSH、復位標志RST等。其中復位標志RST的作用就是“復位相應的TCP連接”。

導致“復位相應的TCP連接” 的其中一個原因是服務器端因為某種原因關閉了Connection，而客戶端依然在讀寫數據，此時服務器會返回復位標志“RST”。

Q

RST復位標志發送原因幾種可能：

1

被中間的防火墻設備攔截

2

對方端口未打開

3

全連接隊列已滿（超出了設備支持的TCP連接資源）

設置 connect_timeout（應用設置了連接超時，sync 未完成時超時了，會發送rst終止連接。）

4

設置 connect_timeout（應用設置了連接超時，sync 未完成時超時了，會發送rst終止連接。）

5

非正常包（連接已經關閉，seq 不正確等）

6

TCP在建鏈時，發出SYN報文之后，60秒之內都沒有收到對端的相應報文，會發送RST報文。

7

TCP報文在連續重傳閾值次數之后，都沒有收到對端相應報文時，會發送RST報文。

8

KeepAlive報文在連續發送5次之后，都沒有收到對端的KeeAliveReply報文時，會發送RST報文。

回顧完理論知識，我們在看一下現場的網絡拓撲結構如下圖所示：

在華為的超融合網絡中虛擬服務器中安裝有MES系統和KEPServer OPC服務器。MES通過OPC的方式從KEPServer OPC 服務器讀寫數據，KEPServer OPC服務器通過自己集成的S7-300驅動程序經由路由的網絡結構讀寫S7-1200和S7-1500中的數據（即KEPServer所在的虛擬主機在一個VLAN X子網，S7-1200和S7-1500在另一個VLAN Y子網）。KEPServer配置的驅動如下圖所示：

現場出現的問題是PLC采用 S7-1500+CP1543-1的方案通信沒問題，即KEPServer OPC服務器可以正常讀寫PLC中的數據；但PLC采用S7-1200集成口或S7-1200+CP243-1 或 S7-1500集成口的方案時，KEPServer OPC服務器不能正常讀寫PLC中的數據。

在現場已經排查出不是KEPServer OPC服務器的問題，在服務器所在的位置用TIA Portal 軟件也無法在線連接到S7-1200。那現在只能懷疑超融合的網絡可能有問題。為了驗證，現場脫離了原有的超融合網絡架構，用西門子SCALANCE XC208模擬超融合網絡的路由網絡架構。且IP子網設置與現場的超融合網絡KEPServer OPC服務器所在虛擬主機相同的子網和相同的IP地址。模擬網絡架構如下圖：

采用上面模擬的超融合網絡架構的結果是所有的PLC都可以正常與KEPServer OPC服務器通信（S7-1200集成口、S7-1200+CP243-1、S7-1500集成口或S7-1500+CP543-1的方案都正常通信）。

從測試的結果來看，不是PLC通信性能的問題，而是網絡存在這一定的問題。為了找到問題的正真原因，我們在KEPServer OPC服務器所在的超融合網絡的虛擬主機與S7-1200 PLC 上同時抓包分析(在PLC下載完程序啟動的時候就開始抓包)。

在KEPServer OPC 服務器端抓取到的文件命名為：“04_CP_1200_Fault_2023_10_28_CaptureInSERVER.pcapng”

在S7-1500 PLC端抓取到的文件命名為：

“04_CP_1200_Fault_2023_10_28_CaptureInPLC.pcap”

KEPServer OPC 服務器所在的虛擬主機的IP地址“10.16.3.110“，子網掩碼”255.255.255.0“ 網關地址”10.16.3.1“。

S7-1200 CP卡的IP地址為”10.18.61.8/23“，子網掩碼”255.255.254.0“ 網關地址”10.18.60.1“。

通信的兩個設備不在同一個IP子網中，需要通過華為超融合網絡的路由器來實現數據的路由轉發。從S7通信的角度看，此時KEPServer 為S7的客戶端，S7-1200 PLC為S7服務器。我們對照著理論部分的TCP建立過程來看S7通信建立的TCP的建立過程。

先看在KEPServer S7客戶端抓包文件，分析如下圖：

再看再PLC S7服務器端的抓包文件，分析如下圖：

問題就出現在TCP的三次握手的第三次，從KEPServer端看發出正常的ACK=1的確認包，而當通過網絡轉發給PLC的時候，該包被修改，除了原來ACK=1外又被修改RST=1，源發著可沒有發送RST=1。換句話說，PLC的三次握手的Zui后一次沒有正常，所以PLC的TCP連接沒有進入到TCP連接建立的狀態，也就是所謂的TCP半連接狀態。PLC的TCP既然沒有完全建立成功，所以發送過來的任何的應用層請求連接都會被PLC發送RST=1的包。可以用下圖來示意上面的連接過程：

對于客戶端已經完成了三次握手，所以客戶端的TCP狀態機已經進入到了 “ESTABLISHED“狀態；而對服務器端由于沒有正確收到 ACK的報文，而是收到ACK和RST同時為1的包，所以服務器端的TCP狀態機只是進入到了 ”SYN-RCVD“狀態，沒有進入到下一個狀態 ”ESTABLISHED“。這是造成現場問題的正真原因。