流程如下，collecter抓取网卡lo和wlan0数据，其中lo口无数据，wlan0是笔记本上网网口，然后按自定义协议把数据包通过lo口发给后端dispatch进行分发！
这种模式下，抓包程序每经过一段时间，lo口就会开始抓到超出上层应用协议的数据包(上层应用最大支持长度0xffff)，导致collecter和dispatch间断链重连。如果停掉collecter向后转发，则collecter抓取的数据包长度正常，用tcpdump验证，抓取wlan0口数据包平均包长在500B左右，lo口无数据；
启动向后转发，collecter只抓lo口，同时配置collecter读取一个只有数据包的pcap文件作为初始输入，原始数据包如下：
tcpdump从lo口抓包， 发现通过lo口转发到后端的数据，会被collecter捕获然后再又通过lo口发出，形成环路，如下所示：
1. 第一个带数据的是第11个数据包，前面的一些包是鉴权和协商！蓝色部分前8字节是协议部分！可以看到这时捕获正常(数据66B + 8B协议头 = 74B)。
2. 第11个数据包发出后就被捕获，看下面第13个数据包的承载部分，collecter接收到这个数据后，会额外打上协议头再转发(新的长度 = 第11个包长度 + 8B协议头 = 148)，从这看出数据开始形成环路：
查看lo口MTU和tcp协商的MSS如下：
可以看到lo口MTU过大，由于lo环路，会导致tcp承载数据越来越大。对上层协议来说，由于协议缓冲区最大长度为65535,当捕获的数据包中应用协议长度大于(65535 - 8)时，就会产生错误，导致断链！
解决方法：
1. 调整部署，捕获数据的网口应该专用于数据接入，数据发送使用其它网口！
2. 调小lo口MTU，这样只能避免断链问题，错误会越积越多！
待验证：
有同事测试发现，大流量下lo口(mtu默认为65536)数据转发，cpu利用率很低(2.4G服务器8核24线程, 无法跑满单核CPU, 占比3%左右)，导致发送线程睡眠，阻塞报文，程序性能很低。后调整MTU至1500后cpu利用率提升，程序性能提高三倍！