西门子PROFINET第三讲：协议

刚开始接触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也可以套用这些理念的，至少可以做个对比