tcp协议-http协议-time-wait-close-wait必知

时间:2022-12-14 22:17:03

 前言: 

tcp四次挥手过程中,谁主动断开,谁有time_wait,被动断开一方会有close_wait

  • time_wait:保持端口占用2mls~4min,避免对方还有一些tcp片发往这个端口,新链接受影响。time_wait的缺点:占用内存
  • close_wait:被动关闭一方接受到fin信号后马上回复ack表示收到fin信号,同时进入close_wait 状态,等待未传输完成的data继续传输完毕,close_wait状态结束,发送fin信号。即close_wait的目的是等待未传输完成的data继续传输完毕。

http 1.0与1.1

http1.0 默认是短连接,client端主动发起,server端服务完毕后,将连接关毕,client端也借此判断数据发送完毕。所以http1.0时代,服务端容易有较多的time_wait。

  • 如果http 1.0协议,client希望使用长连接,需要在header中设置connection:keep-alive

http1.1默认是长连接

  • 如果client不希望使用长连接,需要在header中设置connection:close
  • 如果server不希望使用长连接,也需要在reponse中设置connection:close
http header中keep-alive参数用于设置客户端希望服务端保持连接的秒数

长连接的问题

keep-alive模式带来的问题:此时服务端不关闭连接,客户端如何知道消息内容是否发送完毕(bfe曾经因为对http1.0没有主动关闭连接,导致一些老旧php上的的socket http包因为等待服务端关闭连接判断消息发送完毕而超时)

keep-alive模式下,通过两种方式

  • 服务端reqponse设置content-length参数:告知内容大小,客户端收到指定内容长度后即可关闭连接。客户端发送post时也会采用这种方式,如若content-length大于实际发生的值会超时,小于则服务端会响应400。这种模式有缺陷,动态页面服务器也不知道内容大小,只有等内容全准备完毕后才知道,若等到此时发送,效率太低了。
  • transfer-encoding:chunked模式:此模式下简单说是规定一直特殊的响应data格式,此种格式中会包含body结束的标志。客户端收到此标志即知道数据发送完毕,可以组装解密数据了。

content-length,transfer-encoding,content-encoding

  • transfer-encoding:传输编码,针对传输过程来的,传输完解码才拿到对象。用于在网络传输国财中保证数据安全成功的传输。在http1.1里,如果有transfer-encoding,则必须是chunked,此时不能有content-lengh参数,即使有也会忽略。transfer-encoding相冲突,因为transfer-encoding会通过额外的处理方式来改变数据的组织方式,就会改变实际的数据长度,如果客户端仍按照原content-length来处理的话,则不会接收到完整的数据。
  • content-encoding: 内容编码和accept-encoding对应。比如gzip,对于文本有较好的压缩效果。

附两篇很好的文章

1.介绍http:https://www.byvoid.com/zhs/blog/http-keep-alive-header

2.content-length:http://www.tuicool.com/articles/FJ7rye

3.http协议官方文档:http://greenbytes.de/tech/webdav/rfc7230.html#header.content-length

4.http://liupan2668.blog.163.com/blog/static/12038513120140129504967/