首先看下tcp的状态转移图，从几个角度看下这张图：

首先，代码本身逻辑有问题，反应到上图会有什么现象，

    1，服务器端出现大量的syn_rcvd，这个明显很明显，客户端故意不发ack，应该是客户端逻辑问题，有人在SYN泛洪。

    2，服务器端如果代码收到fin或者rst，不显式调用close会出现什么情况，服务端会一直停留在close_wait.

    3,客户端或者服务端出现大量的time_wait这个正常吗，这两个情况都是有可能出现的。首先看第一个，客户端大量出现。我用requests请求，频繁post/get，或者频繁调用curl(会立刻四次握手结束连接)。这种情况一般不会出问题，但是如果使用多线程/进程，大量post的时候，会占光操作系统fd，如果不做内核参数优化，会报错！这种情况，如果发给一个地址，能用长连接，尽量用长连接，能迅速改善。第二种是服务端出现大量的close_wait，这里就要看访问请求的类型了，是否该开放长连接，长连接timeout是否设置得当，是否该使用套接字复用。

总结，由于代码层次误操作，不显式close，长连接使用不当，会响应出现timewait，close_wait，其中，长连接及其超时设置不当，生产中出现的比较多，特别是使用apache，由于基于多线程方式，容易down。

第二个问题，什么时候会发fin/rst的问题。

第三个，python中的read/recv函数如何判断fin/rst,这里和c的不一样，做了简化

补充下，http1.0默认是短链接，http1.1是长链接，而urllib2/3默认是短链接，request得注意版本。