心跳包

目录 1.背景 2.用类来封装以太网心跳包的优缺点 2.1.优点 2.2.缺点 3.网络心跳包封装类 4.实现IDisposable接口 5.应用层调用 6.Dispose()方法生效的测试 7.测试性能对比 8.综上，在C#里，结构体主要作用有如下两点： 1.背景 接上篇文章 深入浅出C#结构体——封装以太网心跳包的结构为例 ,使用结构体性能不佳，而且也说明了原因。本篇文章详细描述了以类来封装网络心跳包的优缺点，结果大大提升了解析性能。 2.用类来封装以太网心跳包的优缺点 2.1.优点 可以在类里直接new byte[]，即直接实例字节数组，然后写初始化方法或者构造函数中直接对传进来的缓存进行拷贝赋值； 无需装箱拆箱； 类属于引用类型，无需像结构体进行值拷贝，底层直接就是智能指针； 智能指针指向同一片内存，省内存空间； 可以在类里写很多方便的方法，这也就是面向对象，面向领域的基石，方便以后扩展； 2.2.缺点 存在堆里，读取性能会比栈稍差（现在PC端的计算速度很快，基本可忽略不计）； 虽然类也属于GC的托管资源，但是GC什么时候进行自动回收不可控制，需要实现IDisposable接口，用完该类，手动对该类进行释放动作； 使用类的实际性能怎样，我们用测试数据说话，后面会放上与结构体测试的性能对比数据。 3.网络心跳包封装类 这里全部都命名成了字节数组，包括 public byte[

转载： https://mp.weixin.qq.com/s?__biz=MzU2MTkwMTE4Nw==&mid=2247487168&idx=1&sn=e1cc38cae47b0ea86d66d64cb081e8a3&chksm=fc70f52ccb077c3a42b4c51919bec6b77a9a26bee7840a8a5529c286f7430ecfd56e65eb133d&scene=21#wechat_redirect 存在下面两种情形： 情形一 ：一个客户端连接服务器以后，如果长期没有和服务器有数据来往，可能会被防火墙程序关闭连接，有时候我们并不想要被关闭连接。例如，对于一个即时通讯软件，如果服务器没有消息时，我们确实不会和服务器有任何数据交换，但是如果连接被关闭了，有新消息来时，我们再也没法收到了，这就违背了“即时通讯”的设计要求。 情形二 ：通常情况下，服务器与某个客户端一般不是位于同一个网络，其之间可能经过数个路由器和交换机，如果其中某个必经路由器或者交换器出现了故障，并且一段时间内没有恢复，导致这之间的链路不再畅通，而此时服务器与客户端之间也没有数据进行交换，由于 TCP 连接是状态机，对于这种情况，无论是客户端或者服务器都无法感知与对方的连接是否正常，这类连接我们一般称之为“死链”。 情形一 中的应用场景要求必须保持客户端与服务器之间的连接正常

原文地址：http://blog.csdn.net/oqqENvY12/article/details/61615609 PX4 对Mavlink 协议提供了良好的原生支持。该协议既可以用于地面站(Ground ControlStation, GCS) 对无人机(UAV) 的控制，也可用于对地面站的信息反馈。其飞控场景一般是这样的： 也就是说，如果你想要实现地面站控制飞行，那么由你的地面站使用Mavlink 协议，通过射频信道（或wifi 等）给无人机发送控制指令就可以了。如果你想实现无人机自主飞行，那么就由你自己写的应用（运行在无人机系统上）使用Mavlink 协议给无人机发送本地的控制指令就可以了。 在PX4 中，并不鼓励开发者在自定义飞控程序中直接使用Mavlink ，而是鼓励开发者使用uORB微对象请求代理器消息机制。 在uORB 机制中，交换的消息被称之为主题(topic) ，一个主题仅包含一种消息类型（即数据结构）。每个进程（或驱动模块）均可“订阅”或“发布”多个主题，一个主题可以存在多个发布者，而且一个订阅者可也订阅多个主题。 Mavlink传输时的基本单位是消息帧。 协议设计的目标是传输速度和安全性。它允许消息内容检查、消息丢失检测，每个数据包需要6 字节报头。 每次发完一个消息，SEQ的内容会加1，加到255后会从0重新开始

转载自： https://www.cnblogs.com/cswuyg/p/3653263.html 本文总结&分享网络编程中涉及的长连接、短连接概念。 关键字：Keep-Alive，并发连接数限制，TCP，HTTP 一、什么是长连接 HTTP1.1规定了默认保持长连接（HTTP persistent connection ，也有翻译为持久连接），数据传输完成了保持TCP连接不断开（不发RST包、不四次握手），等待在同域名下继续用这个通道传输数据；相反的就是短连接。 　HTTP首部的Connection: Keep-alive是HTTP1.0浏览器和服务器的实验性扩展，当前的HTTP1.1 RFC2616文档没有对它做说明，因为它所需要的功能已经默认开启，无须带着它，但是实践中可以发现，浏览器的报文请求都会带上它。如果HTTP1.1版本的HTTP请求报文不希望使用长连接，则要在HTTP请求报文首部加上Connection: close。《HTTP权威指南》提到，有部分古老的HTTP1.0 代理不理解Keep-alive，而导致长连接失效：客户端-->代理-->服务端，客户端带有Keep-alive，而代理不认识，于是将报文原封不动转给了服务端，服务端响应了Keep-alive，也被代理转发给了客户端，于是保持了“客户端-->代理”连接和“代理-->服务端”连接不关闭，但是

一、什么是长连接 HTTP1.1规定了默认保持长连接（HTTP persistent connection ，也有翻译为持久连接），数据传输完成了保持TCP连接不断开（不发RST包、不四次握手），等待在同域名下继续用这个通道传输数据；相反的就是短连接。 HTTP首部的Connection: Keep-alive是HTTP1.0浏览器和服务器的实验性扩展，当前的HTTP1.1 RFC2616文档没有对它做说明，因为它所需要的功能已经默认开启，无须带着它，但是实践中可以发现，浏览器的报文请求都会带上它。如果HTTP1.1版本的HTTP请求报文不希望使用长连接，则要在HTTP请求报文首部加上Connection: close。《HTTP权威指南》提到，有部分古老的HTTP1.0 代理不理解Keep-alive，而导致长连接失效：客户端–>代理–>服务端，客户端带有Keep-alive，而代理不认识，于是将报文原封不动转给了服务端，服务端响应了Keep-alive，也被代理转发给了客户端，于是保持了“客户端–>代理”连接和“代理–>服务端”连接不关闭，但是，当客户端第发送第二次请求时，代理会认为当前连接不会有请求了，于是忽略了它，长连接失效。书上也介绍了解决方案：当发现HTTP版本为1.0时，就忽略Keep-alive，客户端就知道当前不该使用长连接。其实，在实际使用中不需要考虑这么多

一、什么是长连接 HTTP1.1规定了默认保持长连接（HTTP persistent connection ，也有翻译为持久连接），数据传输完成了保持TCP连接不断开（不发RST包、不四次握手），等待在同域名下继续用这个通道传输数据；相反的就是短连接。 　HTTP首部的Connection: Keep-alive是HTTP1.0浏览器和服务器的实验性扩展，当前的HTTP1.1 RFC2616文档没有对它做说明，因为它所需要的功能已经默认开启，无须带着它，但是实践中可以发现，浏览器的报文请求都会带上它。如果HTTP1.1版本的HTTP请求报文不希望使用长连接，则要在HTTP请求报文首部加上Connection: close。《HTTP权威指南》提到，有部分古老的HTTP1.0 代理不理解Keep-alive，而导致长连接失效：客户端-->代理-->服务端，客户端带有Keep-alive，而代理不认识，于是将报文原封不动转给了服务端，服务端响应了Keep-alive，也被代理转发给了客户端，于是保持了“客户端-->代理”连接和“代理-->服务端”连接不关闭，但是，当客户端第发送第二次请求时，代理会认为当前连接不会有请求了，于是忽略了它，长连接失效。书上也介绍了解决方案：当发现HTTP版本为1.0时，就忽略Keep-alive，客户端就知道当前不该使用长连接。其实

心跳包之所以叫心跳包是因为：它像心跳一样每隔固定时间发一次，以此来告诉服务器，这个客户端还活着。事实上这是为了保持长连接，至于这个包的内容，是没有什么特别规定的，不过一般都是很小的包，或者只包含包头的一个空包。 在TCP的机制里面，本身是存在有心跳包的机制的，也就是TCP的选项：SO_KEEPALIVE。系统默认是设置的2小时的心跳频率。但是它检查不到机器断电、网线拔出、防火墙这些断线。而且逻辑层处理断线可能也不是那么好处理。一般，如果只是用于保活还是可以的。 心跳包一般来说都是在逻辑层发送空的echo包来实现的。下一个定时器，在一定时间间隔下发送一个空包给客户端，然后客户端反馈一个同样的空包回来，服务器如果在一定时间内收不到客户端发送过来的反馈包，那就只有认定说掉线了。 其实，要判定掉线，只需要send或者recv一下，如果结果为零，则为掉线。但是，在长连接下，有可能很长一段时间都没有数据往来。理论上说，这个连接是一直保持连接的，但是实际情况中，如果中间节点出现什么故障是难以知道的。更要命的是，有的节点（防火墙）会自动把一定时间之内没有数据交互的连接给断掉。在这个时候，就需要我们的心跳包了，用于维持长连接，保活。 在获知了断线之后，服务器逻辑可能需要做一些事情，比如断线后的数据清理呀，重新连接呀……当然，这个自然是要由逻辑层根据需求去做了。 总的来说

　　 心跳包之所以叫心跳包是因为：它像心跳一样每隔固定时间发一次，以此来告诉服务器，这个客户端还活着。事实上这是为了保持长连接，至于这个包的内容，是没有什么特别规定的，不过一般都是很小的包，或者只包含包头的一个空包。 　　 在TCP的机制里面，本身是存在有心跳包的机制的，也就是TCP的选项：SO_KEEPALIVE。系统默认是设置的2小时的心跳频率。但是它检查不到机器断电、网线拔出、防火墙这些断线。而且逻辑层处理断线可能也不是那么好处理。一般，如果只是用于保活还是可以的。 　　 心跳包一般来说都是在逻辑层发送空的echo包来实现的。下一个定时器，在一定时间间隔下发送一个空包给客户端，然后客户端反馈一个同样的空包回来，服务器如果在一定时间内收不到客户端发送过来的反馈包，那就只有认定说掉线了。 　　 其实，要判定掉线，只需要send或者recv一下，如果结果为零，则为掉线。但是，在长连接下，有可能很长一段时间都没有数据往来。理论上说，这个连接是一直保持连接的，但是实际情况中，如果中间节点出现什么故障是难以知道的。更要命的是，有的节点（防火墙）会自动把一定时间之内没有数据交互的连接给断掉。在这个时候，就需要我们的心跳包了，用于维持常连接，保活。 　　 在获知了断线之后，服务器逻辑可能需要做一些事情，比如断线后的数据清理呀，重新连接呀……当然，这个自然是要由逻辑层根据需求去做了。 　　

概述 目前IM软件有一个基本的功能就是长在线，即只要有网络就保持登录，然而，网络状态是无法预测的，所以IM软件经常会有”离线“状态，尤其是手机客户端。长在线这个功能依赖断线重连完成。 通常，网络不稳定是造成不能长时间在线的主要原因，还有比如：服务器强制注销客户端、次客户端被主客户端踢。目前的qq和飞信都有断线重连机制。有时候IM软件自动完成登录，有时候需要用户手动登录。所以，断线重连是一个广泛的概念。可以这么理解：除了从登录界面进去的登录，都可以称之为断线重连。 断线重连的定义 使得IM软件能够长在线，或者短时间内掉线，用户无感知。 广义断线重连：用户已经成功登录IM客户端，用户将程序放到后台、或者手机重启，IM软件再次进入前台，软件应帮助用户实现自动登录。 狭义的断线重：客户端的网络状况是不可预知的，可能从2G切换到3G或者WiFi，或者又切换到2G，甚至“飞行模式”（iOS设备）。客户端要及时对网络的变化做出反应，即尝试进行登录。 总之：断线重连，一般是网络原因引起的，目的是让IM软件维持在线。 实现方法 IM客户端始终尽可能的保持连接跟服务器的连接，客户端维护登录状态，以便断线重连。从逻辑层次上来说，断线重连的逻辑是基于登录的逻辑的，首次登录成功后，都有可能有断线重连。断线重连，实质上分为两步：一、使客户端断线；二、让客户端重连服务器。一般来说这两步是一个有前后顺序

概述 目前IM软件有一个基本的功能就是长在线，即只要有网络就保持登录，然而，网络状态是无法预测的，所以IM软件经常会有”离线“状态，尤其是手机客户端。长在线这个功能依赖断线重连完成。 通常，网络不稳定是造成不能长时间在线的主要原因，还有比如：服务器强制注销客户端、次客户端被主客户端踢。目前的qq和飞信都有断线重连机制。有时候 IM软件自动完成登录，有时候需要用户手动登录。所以，断线重连是一个广泛的概念。可以这么理解：除了从登录界面进去的登录，都可以称之为断线重连。 断线重连的定义 使得IM软件能够长在线，或者短时间内掉线，用户无感知。 广义断线重连：用户已经成功登录IM客户端，用户将程序放到后台、或者手机重启，IM软件再次进入前台，软件应帮助用户实现自动登录。 狭义的断线重：客户端的网络状况是不可预知的，可能从2G切换到3G或者WiFi，或者又切换到2G，甚至“飞行模式”（iOS设备）。客户端要及时对网络的变化做出反应，即尝试进行登录。 总之：断线重连，一般是网络原因引起的，目的是让IM软件维持在线。 实现方法 IM客户端始终尽可能的保持连接跟服务器的连接，客户端维护登录状态，以便断线重连。从逻辑层次上来说，断线重连的逻辑是基于登录的逻辑的，首次登录成功 后，都有可能有断线重连。断线重连，实质上分为两步：一、使客户端断线；二、让客户端重连服务器。一般来说这两步是一个有前后顺序