用tcp好还是rtu(用TCP好还是RTU连接上区别)

在编写网络游戏的时候，到底使用UDP还是TCP的问题迟早都要面对。 一般来说你会听到人们这样说：“除非你正在写一个动作类游戏，否则你就用TCP吧” 或者是 “你能够在MMO游戏中用TCP,因为魔兽世界就用的TCP！”遗憾的是，这些观点都没有反映这个问题的复杂性。背景首先，说明一下，我之前主要是用TCP进行网络编程。我曾为一个流行的在线纸牌游戏编写服务器了好几年，在高峰期我们的每台服务器能够承受4000到10000个连接（同一台物理机器上有多个服务器进程在跑）都没有问题。在我来看，TCP是一种安全而且常见的选择。尽管如此，我们最新的项目却是使用UDP协议，而且我们的项目无法通过任何方式在TCP下工作。事实上，项目一开始使用的TCP，但是后来发现我们使用TCP无法达到我们需求的连接数量时，我们只能换成UDP了。在使用中TCP表现怎么样呢从原理上，TCP的优势有：简单直接的长连接可靠的信息传输数据包的大小没有限制任何一个和TCP打过交道的人都知道，要实现一个稳定的TCP网络连接，需要处理各种隐藏的坑，比如断线检测、慢速客户端响应阻塞数据包，对开放连接的各种dos攻击，阻塞和非阻塞IO模型等等。除了上面列出的这些问题外，一个好的TCP模块确实不好编码实现。但是，TCP最糟糕的特性是它对阻塞的控制。一般来说，TCP假定丢包是由于网络带宽不够造成的，所以发生这种情况的时候，TCP就会减少发包速度。在3G或WiFi下，一个数据包丢失了，你希望的是立马重发这个数据包，然而TCP的阻塞机制却完全是采用相反的方式来处理！而且没有任何办法能够绕过这个机制，因为这是TCP协议构建的基础。这就是为什么在3G或者WiFi环境下，ping值能够上升到1000多毫秒的原因。为什么不用UDPUDP相对TCP来说既简单又困难。举个例子来说，UDP是基于数据包构建，这意味着在某些方面需要你完全颠覆在TCP下的观念。UDP只使用一个socket进行通信，不像TCP需要为每一个客户端建立一个socket连接。这些都是UDP非常不错的地方。但是，大多数情况下你需要的仅仅是一些连接的概念罢了，一些基本的包序功能，以及所谓的连接可靠性。可惜的是，这些功能UDP都没有办法简单的提供给你，而你使用TCP却都可以免费得到。这也是人们为什么经常推荐TCP的原因。在用TCP的时候你可以不考虑这些问题，直到你需要同步连接的数量级达到500以上的时候。所以，是的，UDP没有提供所有的解决方法，但是就像你看到的那样，这也正是UDP好用的地方。在某种意义上来说，TCP对UDP就好比是Hibernate和手写SQL的区别。使用TCP失败的地方人们经常给你建议，让你去使用TCP，比如“TCP跟UDP一样快”或者“游戏X用TCP如此成功，所以TCP当然是首选”，然而，他们完全没有理解为什么在那个特定的游戏中TCP是有效的，为什么UDP不按照顺序发送数据包呢？那么为什么魔兽世界采用TCP呢？首先我们需要解释这个问题。这个问题其实是“为什么魔兽世界有的时候1000毫秒以上的延迟还能够运行？”这是TCP的性质决定的，在发生丢包的时候，会产生巨大的延迟，因为TCP首先会去检测哪些包发生了丢失，然后重发所有丢失的包，直到他们都被接收到。可靠的UDP也是有延迟的，但是由于它是在UDP的基础之上建立的通信协议，所以可以通过多种方式来减少延迟，不像TCP，所有的东西都要依赖于TCP协议本身而无法被更改。就这一点来讲，一些人要开始提到Nagle算法了，实际上它是你在实现任意一个对延迟敏感的TCP模型时首先需要禁止使用的。那么魔兽世界以及其他的一些游戏是怎么处理延迟问题的呢？方法也很简单，他们能够隐藏掉延迟带来的影响。在魔兽世界中，玩家和玩家是无法碰撞的：因为这类碰撞是无法通过一些预测来处理的，但是玩家和环境之间的碰撞却是可以通过预测来处理的，所以这里使用TCP是没有问题的。我们来看一下魔兽世界的战斗就会发现，玩家的攻击指令发送给服务器的操作是放在比如“attack_entity(entity_id)”或者”cast_spell(entity_id, spell_id)“的接口中来做的，换句话说，瞄准操作是独立于进行的。如此一来，一些类似发起攻击动作和释放技能特效就能够在没有收到服务器确认的情况下就直接执行，比如展现冰冻技能的效果就可以在服务器没有返回数据前在客户端就做出来。客户端直接开始进行计算而不等待服务端确认是一种典型的隐藏延迟的技术。几年前，我为一个叫“Five Card Jazz”的纸牌游戏编写过客户端。它使用的是http协议，它比直接的TCP协议连接的延迟更加严重。我们用简单的纸牌绘制和抽牌的动画来掩盖延迟的问题，所以延迟的问题只在非常糟糕的连接下才会被看出来。这种方法也非常的典型：发送请求的同时开始播放牌桌的动画，一直播放翻动最后一张牌直到接收到了服务端传回来的数据为止。魔兽世界的战斗特效就是使用类似的原理。这也意味着，我们到底是使用TCP还是UDP取决于我们能否隐藏延迟。TCP在什么时候失效一个采用TCP的游戏必须能够处理好突发的延迟问题（纸牌客户端就很典型，对突发性的一秒的延迟，玩家也不会产生什么抱怨）或者是拥有缓解延迟问题的好方法。但是如果你运行的是一个无法使用任何减缓延迟措施的游戏呢？玩家对玩家的动作类游戏通常就属于这个范畴，但是这也不仅仅限于动作类游戏。举个例子：我目前正在写一个多人游戏（War Arcana）。一种常见的操作是，你快速的移动你的角色通过一张充满战争迷雾的世界地图，但是一旦你探索过，迷雾就会被打开。为了确保游戏的规则，防止玩家作弊，服务器只能显示玩家当前位置附近的信息。这意味着不像魔兽世界，玩家无法在没有得到服务器响应的情况下，做出完整的动作。和Five Card Jazz相比，我们即使允许500毫秒的延迟，也已经非常困难了。在实现了游戏的原型后，在局域网内一切都进行的非常顺利，但当我们在WiFi环境下测试时，操作会间歇性的卡起来或者延迟高起来。写了一些测试程序之后发现，WiFi环境下偶尔会发生丢包行为，每当发生丢包的时候，服务器的响应速度就从100-150毫秒上升到1000-2000毫秒。没有任何办法可以绕过TCP的这个设置来避开这个问题。我们替换了TCP的代码，用了自定义的可靠的UDP来实现，把大量的丢包产生的延迟降到了仅仅只有50毫秒，甚至比以前TCP不丢包的情况一个来回的延迟还要小。当然，这只可能建立在UDP之上，这样我们才对可靠性拥有完全的掌控力。困惑：可靠的UDP只是TCP的一种简单的实现？你有没有听过这种说法：“可靠的UDP就像TCP一样，所以还是用TCP吧”。问题是这种说法是错误的。可靠的UDP一点也不像TCP，要去实现一个特殊的阻塞控制。事实上，这也是你使用可靠UDP代替TCP的最大的原因，避免TCP的阻塞控制。另一个重点是可靠的UDP的可靠性是如何保证的。这里有很多种方法去实现。我非常喜欢Quake3网络库代码里的一些想法，它们也激发了我在War Arcana中使用UDP协议。你也可以使用许多支持可靠通信的UDP库，当然，这样在可靠性方面，相比自己手动实现全部的代码而言，可能会更加通用而失去了一些性能优势。底线那么到底是用UDP还是TCP呢？如果是由客户端间歇性的发起无状态的查询，并且偶尔发生延迟是可以容忍，那么使用HTTP/HTTPS吧。如果客户端和服务器都可以独立发包，但是偶尔发生延迟可以容忍（比如：在线的纸牌游戏，许多MMO类的游戏），那么使用TCP长连接吧。如果客户端和服务器都可以独立发包，而且无法忍受延迟（比如：大多数的多人动作类游戏，一些MMO类游戏），那么使用UDP吧。这些也应该考虑在内：你的MMO客户端也许首先使用HTTP去获取上一次的更新内容，然后使用UDP跟游戏服务器进行连接。 永远不要害怕去使用最佳的工具来解决问题。
TCP是可靠协议，需要对方确认！如QQ视频等。 UDP具有实时传输，无需对方确认，如电视直播等。 具体要看实际需求

本来他们两个是为了适用不同的需求而出来的传输方式，没得说谁好谁坏，如果硬是要说好和坏，只能从不同业务需求来说，对于实时性要求比较高的时候，肯定是udp，因为实时性中传输大量的数据，丢一些包不妨碍实时性； 如果是网络非常好的情况，并且要数据完整的只能说优先考虑tcp，udp也是可以做到的，但是就比较麻烦需要去做拆包分包的帧的验证和判断，但是做好了绝对比tcp好，这是在公司人力资源允许的情况下； 因此综上所述：inter网的传输优先考虑udp，实时性高的只能用udp，tcp开发相对简单，为了开发效率可以考虑；如果是局域网的传输，想都别想就用tcp，无论是实时的还是大文件的都用tcp，因为局域网的网速是不用质疑的； 另外，拿个QQ例子，个人认为，qq文件传输中，应该是判断对方好友是否是和本人在同一个局域网下，如果是就用tcp连接发送文件飞快，如果是外网的应该是用udp
TCP是全世界免费使用的网络协议，UDP是需要另外支付费用的。TCP安全，绝大部分网络连接都要使用TCP/IP协议，UDP适用于下载上传等操作，顺便说一句，QQ的连接也是个UDP，不包括发送文件和图片。

ModBus协议是应用层报文传输协议（OSI模型第7层），它定义了一个与通信层无关的协议数据单元（PDU），即PDU=功能码+数据域。 ModBus协议能够应用在不同类型的总线或网络。对应不同的总线或网络，Modbus协议引入一些附加域映射成应用数据单元（ADU），即ADU=附加域+PDU。目前，Modbus有下列三种通信方式： 1. 以太网，对应的通信模式是MODBUS TCP。 2. 异步串行传输（各种介质如有线RS-232-/422/485/；光纤、无线等），对应的通信模式是MODBUS RTU或MODBUS ASCII。 3. 高速令牌传递网络，对应的通信模式是Modbus PLUS。

UDP协议无需握手，速度快，消耗少，但是无确保，易丢包；TCP三次握手，速度慢消耗多，但是可以确保消息正确发送。 TCP（Transmission Control Protocol，传输控制协议）是基于连接的协议，也就是说，在正式收发数据前，必须和对方建立可靠的连接。一个TCP连接必须要经过三次“对话”才能建立起来，其中的过程非常复杂，我们这里只做简单、形象的介绍，你只要做到能够理解这个过程即可。我们来看看这三次对话的简单过程：主机A向主机B发出连接请求数据包：“我想给你发数据，可以吗？”，这是第一次对话；主机B向主机A发送同意连接和要求同步（同步就是两台主机一个在发送，一个在接收，协调工作）的数据包：“可以，你什么时候发？”，这是第二次对话；主机A再发出一个数据包确认主机B的要求同步：“我现在就发，你接着吧！”，这是第三次对话。三次“对话”的目的是使数据包的发送和接收同步，经过三次“对话”之后，主机A才向主机B正式发送数据。UDP（User Data Protocol，用户数据报协议）是与TCP相对应的协议。它是面向非连接的协议，它不与对方建立连接，而是直接就把数据包发送过去！ UDP适用于一次只传送少量数据、对可靠性要求不高的应用环境。比如，我们经常使用“ping”命令来测试两台主机之间TCP/IP通信是否正常，其实“ping”命令的原理就是向对方主机发送UDP数据包，然后对方主机确认收到数据包，如果数据包是否到达的消息及时反馈回来，那么网络就是通的。例如，在默认状态下，一次“ping”操作发送4个数据包。大家可以看到，发送的数据包数量是4包，收到的也是4包（因为对方主机收到后会发回一个确认收到的数据包）。这充分说明了UDP协议是面向非连接的协议，没有建立连接的过程。正因为UDP协议没有连接的过程，所以它的通信效果高；但也正因为如此，它的可靠性不如TCP协议高。QQ就使用UDP发消息，因此有时会出现收不到消息的情况
1、局域网的线路短，信号损失很小，所以对可靠性要求不高，允许使用UDP； 2、TCP需要预留较大的余量，否则网络易崩溃，而UDP虽然会丢包，但不会对网络系统造成破坏；3、UDP不需要维护连接，所以程序中也不需要判断连接是否意外中断，逻辑更简单； UDP更适合用在工业系统中，进行MODBUS-RTU的透传，可利用报文校验来保证可靠性，不一定要依赖TCP。而且工业系统都是允许丢包的。而办公系统文件大，通信频次少，丢包的代价太高，应该用TCP传办公文件。
小型局域网的稳定性高，所以选择传输效率高的UDP是更好的选择，不会出现太大问题。但是最好还是采用netbios协议。
可能减少数据包包头的大小，增加点传输速度。
不能保证数据的有效到达，这是UDP协议的特点决定的。 文字聊天工具使用的基本都是UDP协议，主要就是为了加快数据传输。 你可以想象一下使用TCP协议的聊天工具，不论你打多少个字，每次通信都要经过3次握手的过程，这样多浪费时间。

这个问题已经有很多人问过了。MODBUS RTU说的是指令格式，这指的是以二进制格式，进行MODBUS协议通讯，与此相对应的是MODBUS ASCII，指的是将MODBUS指令转换为十六进制ASCII码格式进行通讯。而MODBUS TCP与前面的MODBUS RTU，MODBUS ASCII都不是一个概念。进行MODBUS通讯，既可以在485或232串口信道上使用，也可以在以太网信道上使用，在以太网信道中使用MODBUS协议，就是MODBUS TCP，指令格式既可以是MODBUS RTU，也可以是MODBUS ASCII。