tcp协议几个要注意的点

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

24122922_KJor.jpg

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

    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得注意版本。

转载于:https://my.oschina.net/u/2950272/blog/1014846

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值