那这时大家会有疑问了，不是说TCP/IP是可靠的传输协议吗？这到底是怎么回事儿？那需要我们说说TCP到底是怎么工作的，TCP采用了尽量分片的方法，避免IP在MTU分片所造成的不可靠的数据传输，这样也就避免了IP分片所造成数传时的数据丢失，增加重传数据包的机率。前面提到TCP通信需要建立通信连接，3次握手，在握手的时候，双方就协商了MSS的大小，即Maximum SegmentSize，也就是双方确定TCPZui大分节长度。这个值用来告诉对方，能够发送TCP分节的大小。而这个值是取其链路层MTU大小减去TCP头部大小和IP头部大小，即MSS=MTU-TCP头部大小-IP头部大小。这样对于以太网的MSS的Zui大长度为1500-20-20=1460Bytes。这样TCP的数据每次发送都不会超过1460B，到了数据链路层不会超过MTU的大小，那么IP报自然不会进行分片传输，这样就减少了TCP/IP重传的机率。TCP可靠的数据传输，除了MSS的协商机制，那么还有一个重要的特性就是序列号确认机制，这两个特性基本上可以保证数据的可靠传输。在TCP分节报文中，包含顺序号和应答号的字段，数据重传和数据应答机制的基本前提就是对每个传输字节进行编号，即顺序号SequenceNumber。顺序号表示发送方已发送字节流的计数，接收方在成功接收到一个有效数据包后，发送一个确认应答数据包给发送方，应答数据包中包含的应答号AckNumber即指已接收的数据长度+1，或者说已接收到的数据中的Zui后一个字节的序列号+1，表示已期望接收的下一个字节的序列号。这个机制可以解决诸如数据在传输过程中破坏的问题，处理接收重复数据的问题，数据丢失的问题，以及处理接收端数据乱序的问题等等来保证可靠的数据传输。
对于“滑动窗口”，这也是TCP/IP通信的一个特点，在TCP通要建立通信连接，3次握手的时候，不仅仅双方协商了MSS的大小，也协商了WindowSize的大小。接收端的容器，水总会有注满的时候，通过不断向发送端告知容器还有多少的剩余，也就是自己窗口的大小，通知发送端，根据我的接收能力，你还能发送多少数据给我，这就是流量的控制。这个流量控制对于TCP/IP通信的通信速度影响很大，如果你需要你的TCP/IP通信快速，那你就需要保证你的接收侧的滑动窗口始终有富余，唯一的办法就是接收一定要比发送快！
对于端口号的多路复用，这里给大家举一个例子，1500PLC是集成WebServer的，你可以通过一台PC1的浏览器浏览这个网页服务，默认的端口是80。当然你也可以使用一台PC2浏览这个网页服务，默认端口仍然是80。这个端口就是在被复用。
当然还有许多定时器用于TCP/IP可靠的数据传输，例如Keepalive等等，这里就不一一赘述了。当看了五花八门的各种概念和协议机制，给了我乱花渐欲迷人眼的感觉，对于理解PN似乎没有什么帮助啊，Zui起码我知道了协议这个概念和工作机制。那么PN也可以套用这些理念的，至少可以做个对比。
