剛開始接觸PROFINET的時候，還不知道從哪里入手，東瞧瞧，西看看，Zui終覺得還是從協議入手，可是那個時候的我也是剛剛入職不久，說實話，協議是什么不是很懂。膠片和手冊中都提到PROFINET協議和TCP協議可以并存，里面也提到和TCP協議做對比，還提到建立通信連接是通過UDP協議的，而PN IO RT通信是不需要TCP和UDP協議的，當時看到這樣的話，也是一頭霧水，到底PN和TCP/UDP協議到底有什么關聯呢？兩者到底是怎樣工作在PN通信中的？帶著這樣的疑問，我想剛剛使用VB通過Socket來編寫TCP協議與TDC通信，還是先了解一下TCP/IP協議吧，畢竟我還是覺得自己更加的熟悉（就自以為是了，哈哈?。?，然而卻陷入了TCP/IP的陷阱，這是一個比PN難百倍的協議。經歷在技術支持工作超過15年，我也不敢說我精通TCP/IP協議，我只能說略懂，嗯，對，略懂而已！

手冊和膠片中常常說TCP的協議特點，如下：

下面我就通過對TCP/IP略懂的知識，給大家介紹一下，TCP/IP協議是怎樣的一種協議。

作為開放式協議，顯而易見，你也可以用，我也可以用，無論是西門子還是第三方設備，只要支持TCP/IP都遵循RFC793，即都可以相互通信。對比S7協議，這是西門子自己獨有的協議，只有西門子自己支持自己產品間的通信，所以不是開放式的協議。

面向連接，指的是TCP/IP通信是要先建立連接的，然后才能數據交換，建立連接的方式就是我們常常聽到的所謂的三次握手。字節流的通信，大家會覺得這三個字很簡單，首先，其它協議交換的數據信息都可以以字節為單位，那么關鍵在于“流”這個字眼?？吹竭@個字，大家的腦海里閃現的肯定是液體，或者首先想到的是水，那么TCP/IP似水一樣的流動，向接收端發送字節流，既然像水，接收端就像一個容器，接收這些水，那么你會區別這里面的水，哪些是先倒入的，哪些是后倒入的？顯而易見，你無法區分，所以才會有你在TCP/IP通信的時候，處理可變數據長度時的尷尬。

對于IP協議，這個TCP協議為啥還要關聯IP協議，總是湊成TCP/IP協議呢？這個IP協議的作用是大的很呢，可以說法力無邊！這要從ISO/OSI參考模型的第三層說起，第三層IP的主要作用有兩點，第一點是選路，也就是我們常說的路由，幫助IP數據從一個網段路由到另一個網段，這時IP地址就有用了。第二點就是分片，作為工控工程師，我們在做以太網通信時，應該知道以太網幀數據的長度是46-1500Bytes，這是由以太網的物理特性決定的，通常1500Bytes被稱為數據鏈路層的Zui大傳輸單元，即MTU。IP的數據報文從理論上Zui大可以傳輸64KB數據，但是在以太網上的傳輸數據長度卻不能，所以IP數據報大于1500B時，即大于MTU，發送方的IP報文即會被分解成若干片，這樣每一片都小于或等于MTU的大小。而接收方則對這些報文的分片進行重組。然而，由于可能網絡中各種狀況的出現，例如其中一片丟失，整個IP報就不能完成重組，整個IP報就會丟棄，所以IP報是不可靠的傳輸協議。

那這時大家會有疑問了，不是說TCP/IP是可靠的傳輸協議嗎？這到底是怎么回事兒？那需要我們說說TCP到底是怎么工作的，TCP采用了盡量分片的方法，避免IP在MTU分片所造成的不可靠的數據傳輸，這樣也就避免了IP分片所造成數傳時的數據丟失，增加重傳數據包的機率。前面提到TCP通信需要建立通信連接， 3次握手，在握手的時候，雙方就協商了MSS的大小，即Maximum Segment Size，也就是雙方確定TCPZui大分節長度。這個值用來告訴對方，能夠發送TCP分節的大小。而這個值是取其鏈路層MTU大小減去TCP頭部大小和IP頭部大小，即MSS=MTU-TCP頭部大小-IP頭部大小。這樣對于以太網的MSS的Zui大長度為1500-20-20=1460Bytes。這樣TCP的數據每次發送都不會超過1460B，到了數據鏈路層不會超過MTU的大小，那么IP報自然不會進行分片傳輸，這樣就減少了TCP/IP重傳的機率。TCP可靠的數據傳輸，除了MSS的協商機制，那么還有一個重要的特性就是序列號確認機制，這兩個特性基本上可以保證數據的可靠傳輸。在TCP分節報文中，包含順序號和應答號的字段，數據重傳和數據應答機制的基本前提就是對每個傳輸字節進行編號，即順序號Sequence Number。順序號表示發送方已發送字節流的計數，接收方在成功接收到一個有效數據包后，發送一個確認應答數據包給發送方，應答數據包中包含的應答號Ack Number即指已接收的數據長度+1，或者說已接收到的數據中的Zui后一個字節的序列號+1，表示已期望接收的下一個字節的序列號。這個機制可以解決諸如數據在傳輸過程中破壞的問題，處理接收重復數據的問題，數據丟失的問題，以及處理接收端數據亂序的問題等等來保證可靠的數據傳輸。

對于“滑動窗口”，這也是TCP/IP通信的一個特點，在TCP通要建立通信連接， 3次握手的時候，不僅僅雙方協商了MSS的大小，也協商了Window Size的大小。接收端的容器，水總會有注滿的時候，所以通過不斷向發送端告知容器還有多少的剩余，也就是自己窗口的大小，通知發送端，根據我的接收能力，你還能發送多少數據給我，這就是流量的控制。這個流量控制對于TCP/IP通信的通信速度影響很大，如果你需要你的TCP/IP通信快速，那你就需要保證你的接收側的滑動窗口始終有富余，唯一的辦法就是接收一定要比發送快！

對于端口號的多路復用，這里給大家舉一個例子，1500PLC是集成Web Server的，你可以通過一臺PC1的瀏覽器瀏覽這個網頁服務，默認的端口是80。當然你也可以同時使用另外一臺PC2瀏覽這個網頁服務，默認端口仍然是80。這個端口就是在被復用。

當然除此之外，還有許多定時器用于TCP/IP可靠的數據傳輸，例如Keepalive等等，這里就不一一贅述了。然而當看了五花八門的各種概念和協議機制，給了我亂花漸欲迷人眼的感覺，對于理解PN似乎沒有什么幫助啊，但是Zui起碼我知道了協議這個概念和工作機制。那么PN也可以套用這些理念的，至少可以做個對比