Chinaunix首页 | 论坛 | 博客
  • 博客访问: 509788
  • 博文数量: 100
  • 博客积分: 2058
  • 博客等级: 大尉
  • 技术积分: 1029
  • 用 户 组: 普通用户
  • 注册时间: 2010-07-14 23:29
文章分类
文章存档

2011年(94)

2010年(6)

分类: LINUX

2011-09-27 23:57:10

状态迁移

1. SO_LINGER/ SO_REUSEADDR
    TCP正常的关闭过程如下(四次握手过程):
(FIN_WAIT_1) A       ---FIN--->       B(CLOSE_WAIT)
(FIN_WAIT_2) A       <--ACK--       B(CLOSE_WAIT)
  (TIME_WAIT)A        <--FIN----       B(LAST_ACK)
  (TIME_WAIT)A        ---ACK->       B(CLOSED)
    Ø  A端首先发送一个FIN请求给B端,要求关闭,发送后A段的TCP状态变更为FIN_WAIT_1,接收到FIN请求后B端的TCP状态变更为CLOSE_WAIT
    Ø  B接收到ACK请求后,B回一个ACK给A端,确认接收到的FIN请求,接收到ACK请求后,A端的TCP状态变更为为FIN_WAIT_2。
    Ø  B端再发送一个FIN请求给A端,与连接过程的3次握手过程不一样,这个FIN请求之所以并不是与上一个请求一起发送,之所以如此处理,是因为TCP是双通道的,允许在发送ACK请求后,并不马上发FIN请求,即只关闭A到B端的数据流,仍然允许B端到A端的数据流。这个ACK请求发送之后,B端的TCP状态变更为LAST_ACK,A端的状态变更为TIME_WAIT。
    Ø  A端接收到B端的FIN请求后,再回B端一个ACK信息,对上一个FIN请求进行确认,到此时B端状态变更为CLOSED,Socket可以关闭。
   除了如上正常的关闭(优雅关闭)之外,TCP还提供了另外一种非优雅的关闭方式RST(Reset)
   (CLOSED) A         ---RST-->      B (CLOSED)
   Ø  A端发送RST状态之后,TCP进入CLOSED状态,B端接收到RST后,也即可进入CLOSED状态。
    在第一种关闭方式上(优雅关闭),非常遗憾,A端在最后发送一个ACK请求后,并不能马上将该Socket回收,因为A并不能确定B一定能够接收到这个ACK请求,因此A端必须对这个Socket维持TIME_WAIT状态2MSL(MSL=Max Segment Lifetime,取决于操作系统和TCP实现,该值为30秒、60秒或2分钟)。如果A端是客户端,这并不会成为问题,但如果A端是服务端,那就很危险了,如果连接的Socket非常多,而又维持如此多的TIME_WAIT状态的话,那么有可能会将Socket耗尽(报Too Many Open File)。
    服务端为了解决这个问题,可选择的方式有三种:
    Ø  保证由客户端主动发起关闭(即做为B端)
    Ø  关闭的时候使用RST的方式
    Ø  对处于TIME_WAIT状态的TCP允许重用
     一般我们当然最好是选择第一种方式,实在没有办法的时候,我们可以使用SO_LINGER选择第二种方式,使用SO_REUSEADDR选择第三种方式

阅读(6102) | 评论(0) | 转发(4) |
给主人留下些什么吧!~~