在.net中做网络通讯往往都会用到SocketAsyncEventArgs，为了得到更好的性能配合Pool复用SocketAsyncEventArgs可以得到一个更好的效果，但在dotnet core在linux下这一块的处理好像存在严重的问题！经过多天的测试，终于在Linux下Debug到这一情况，实时调试输出接收的数据并不是当前请求的数据，而是之前另一请求的数据…… 接下来一下问题的实际情况！
问题的初现
前段时间有一个用户说FastHttpApi跑了一段时间后就出现请求混乱的情况，用户反映测试都正常，一发布上线在集群环境下运行一段时间后就会出现这情况……然后自己也根据相应的集群情况搭了个测试环境压测了一段时间也没出现这情况。本以为是用户集群路由转发的一些特性引起的异常就放下了这问题继续完成新功能版本。
再次发现问题并确认
当组件的接口集群调用体功能完成后，开始做接口混合调用并发测试，这个时候出现一些怪异的情况，当前请求返回的数据并不是当前请求数据内容，而是来源于其他请求的数据内容！后来在测试的过程中同时用浏览器访问相关接口，这个时候问题再一次出现，浏览器得到响应的数据并不是请求响应的数据，而是测试接口那边的数据。后来关闭压力测试，单独用浏览器访问还是有异常，打开日志发现浏览器请求的数据到服务端接收得到的数据竟然是之前测试请求的数据！这样的问题相当尴尬……因为接收数据是由‘’SocketAsyncEventArgs‘’来处理，我一直不相信问题出在SocketAsyncEventArgs身上；最终迫于没办法的情况只能调试Linux运行的代码，通过VS2017调试linux下dotnet core程序 最后把所有涉及请求的测试都关闭，单独由浏览器请求，这个时候得到的请求我都感到惊讶！ 
从结果看接收的数据并不是浏览器发出请求的数据，而是之前测试程序请求的内容，数据显示User-Agent都不是浏览器的内容。
调整实现
按理这样的问题不应该出现，因为早期MSDN也是推荐使用SocketAsyncEventArgs Pool的方式来复用SocketAsyncEventArgs提高性能。asp.net core核心的网络模块也是用这个的，如果有问题应该早就发现并解决掉！查看KestrelHttpServer 代码后才发现并没有使用SocketAsyncEventArgs Pool，每个连接都是单独的SocketAsyncEventArgs 并没有通过Pool共享，对应用的一次绑定的Buffer已经改由Pipe统一管理，每次收发都重新设置一下Buffer属性。 为了快速地解决这一问题，放弃了原有SocketAsyncEventArgs Pool的使用方式，改用KestrelHttpServer方式进行组件改造，这种方式通过了两天的混合并发测试暂没有出现之前的情况，估计之前的问题是由SocketAsyncEventArgs共享复用导致的;则于无法判断最终向corefx团队提了:issue,https://github.com/dotnet/corefx/issues/33794 这问题应该是存在的，因为碰到这一情况还有其他人。
总结
这问题发现到排查花了一个多星期的时间……到底是SocketAsyncEventArgs 的bug还是使用上不对导致的还没搞清楚，已经把相关问题描述和测试出现问题的程序提交给corefx团队，希望尽快能搞清楚具体原因。通过这一次问题总结出一个问题，在做网络测试的时候需要做更多的混合验证测试，特别针对这一问题，由于数据都是符合当前协议的，所以并不会有什么异常出现。但导致数据混乱这种问题比异常来得更严重和影响面更大。