问题描述
业务中有一个测试服务器，里面运行了好几个任务队列。但是自从将任务队列从redis迁移到rabbitmq上后，一直会在运行一段时间后停止运行。一般这种情况下，要么是进程退出了，要么是连接断开了。但是检查后发现，进程是正常运行的，并且通过netstat发现，连接也一直存在。如果是连接断开，我的代码中也做了断线重连的机制。
问题排查
一开始以为是php-amqplib这个库的问题，就去找它的issue，看看有没有类似的问题。这里没有找到类似的bug。
然后去复现了一个最小的demo，这个问题一直都是出现在运行相当长的时间之后。于是决定对测试服务器上已经出现问题的代码进行抓包。新push的任务，任务队列的进程就是接收不到，但是netstat结果，任务队列到rabbit服务的连接又确实是存在的。
没有办法就去随便翻翻《UNIX网络编程》的TCP章节，然后想到TCP的全双工特性。全双工特性就是说在一个给定的连接上应用可以在任何时候在进出两个方向上既发送数据又接收数据。建立一个全双工连接后，需要的话可以把它转换成一个单工连接。于是用netstat检查rabbit服务的连接，发现是没有到任务队列的连接的。所以问题就是出现在这里。**但是仔细思考一下，这里的问题并不能用全双工特性去解释，因为全双工转成单工是tcp的一个特性，但是在这个问题中，应该是一个异常情况。全双工是需要双端协商的，而我这里的问题应该是：
服务器关闭了连接，但是任务队列却没有收到关闭的Fin报文，很多时候被称为半打开。
问题解决
解决这个问题很简单，启用php-amqplib的心跳包机制即可。
更多的思考
1.半连接，半打开，半关闭（以下用A,B代表连接的两端）
半连接:出现在tcp的三次握手阶段。A发送syn，B响应ack,syn后，此时处于半连接状态。如果A不发送ack，B将会一直为这个半连接分配一段内存空间。因此可以使用这个特点对B进行半连接攻击
半打开(half-open):A断开连接但是却没有发送Fin报文，导致B不知道。在维基百科上半打开和半连接是相同的。
半关闭:在关闭的4次挥手阶段，A端发送Fin,B端ack但是不发送Fin。
半连接、半关闭都是正常出现的情况。半打开则是不正常的状态，一个Unix进程无论自愿地（调用exit或是从main函数中返回）还是非自愿地（收到一个终止本进程的信号）终止时，所有打开的描述符都被关闭，这也导致仍然打开的任何TCP连接上也发出一个FIN。也就是说，只有当服务器断电等这种非正常关闭的情况下才会出现半连接，否则对端都应该收到Fin报文，然后关闭连接。
1.什么情况导致了半打开？
服务器断电这类情况肯定是没有出现的，所以一定是其他地方有问题导致了这个情况。因为这个问题只在测试服务器上出现，生产服务器上并没有。所以有点难推测。
2.双向连接(bidirectional)和全双工(full-duplex)
在我的理解中，双向连接指的是A端确认了到B端的连接，B端也确认了到A端的连接。全双工则指可以同时发送和接收，互不干扰。
3.心跳机制是如何避免这种情况的？
心跳机制一般都是隔一段时间主动发送一个消息给对端来确认连接是否存活。如果连接丢失，则必然不会收到对端的响应。这样在响应超时后重新发起连接即可。
其实tcp也有一个keep-alive机制。与心跳包作用类似，但是一是检查的周期长，二是一旦启用，机器上所有的连接都会启用这个机制，导致资源浪费。