我们知道tcp服务器，

1、 一般处于被动打开；

2、 当服务器重启，会有2msl导致端口不可用的问题

3、 服务器重启，会有平静时间问题。

4、 服务器会存在半打开状态；

服务器一般支持并发，当一个链接建立，一般fork一个新的进程或线程处理这个新的链接。服务器处于被动打开，服务器始终要准备应答下一个接入的syn报文请求。但是当服务器正在处于忙碌的时候，tcp的建连请求syn到达，该如何处理。

Backlog

Tcp和应用进程通过一个称为“backlog”的fifo队列来管理syn链接。

1、 tcp和应用程序中间有一个固定长度队列，这个队列tcp建链后入队，应用程序出队。即这个队列保存（入队）已经syn建链而还没有被应用程序出读出的链接

2、 这个队列称为backlog，应用程序设置这个队列的大小，一般为0-5，

3、 当syn到达tcp协议栈时候，tcp判断这个队列积压值，判断是否处理这个syn

4、 Tcp监听这个backlog，当有空间时候tcp接收syn建立链接，应用只有在syn三次握手完成后才知道这个链接（syn到达时候应用程序不知道）；

5、 如果客户端和服务端建立tcp链接，但是服务器应用程序忙碌，客户端是不知道的，客户端发送数据，服务器tcp协议栈仅仅把这些数据存放到缓冲队列里。

6、 对于新syn链接建链，如果backlog已经没空间，服务器tcp协议栈不理会这个syn，也不像端口没有启动那样发送rst，这种情况，客户端syn将超时重发。

这个值，是被tcp接收的syn链接，但是还没被应用程序处理的链接个数。它和tcp能建链多少链接无关，它代表tcp建链和应用程序处理链接的速度关系，一般这个值积压，代表应用程序忙碌或者系统计算资源不足。

随着云计算普及，计算资源的虚拟化后，由于容量规划做不到位，计算资源过载经常会造成应用程序因资源不够而长期处于响应“迟钝”的状况。这种情况一般会加剧系统backlog的积压，一般在虚拟机环境下测试tcp性能，会出现和物理机性能差距明显的结果。当然这种情况hyperv会消耗一些计算资源，但是虚拟化后计算资源的规划，将会是影响tcp性能（主要应用程序受影响后间接影响了tcp协议栈的性能）。