前言
事实证明，读过Linux内核源码确实有很大的好处，尤其在处理问题的时刻。当你看到报错的那一瞬间，就能把现象/原因/以及解决方案一股脑的在脑中闪现。甚至一些边边角角的现象都能很快的反应过来是为何。笔者读过一些Linux TCP协议栈的源码，就在解决下面这个问题的时候有一种非常流畅的感觉。
Bug现场
首先，这个问题其实并不难解决，但是这个问题引发的现象倒是挺有意思。先描述一下现象吧，笔者要对自研的dubbo协议隧道网关进行压测(这个网关的设计也挺有意思，准备放到后面的博客里面)。先看下压测的拓扑吧:
为了压测笔者gateway的单机性能，两端仅仅各保留一台网关，即gateway1和gateway2。压到一定程度就开始报错，导致压测停止。很自然的就想到，网关扛不住了。
网关的情况
去Gateway2的机器上看了一下，没有任何报错。而Gateway1则有大量的502报错。502是Bad Gateway，Nginx的经典报错，首先想到的就是Gateway2不堪重负被Nginx在Upstream中踢掉。
那么，就先看看Gateway2的负载情况把，查了下监控，发现Gateway2在4核8G的机器上只用了一个核，完全看不出来有瓶颈的样子，难道是IO有问题？看了下小的可怜的网卡流量打消了这个猜想。
Nginx所在机器CPU利用率接近100%
这时候，发现一个有意思的现象,Nginx确用满了CPU!
再次压测，去Nginx所在机器上top了一下，发现Nginx的4个Worker分别占了一个核把CPU吃满-_-!
什么，号称性能强悍的Nginx竟然这么弱，说好的事件驱动\epoll边沿触发\纯C打造的呢？一定是用的姿势不对！
去掉Nginx直接通信毫无压力
既然猜测是Nginx的瓶颈,就把Nginx去掉吧。Gateway1和Gateway2直连，压测TPS里面就飙升了，而且Gateway2的CPU最多也就吃了2个核，毫无压力。
去Nginx上看下日志
由于Nginx机器权限并不在笔者手上，所以一开始没有关注其日志&#