论坛徽章:: 0

电梯直达

1楼 [收藏(0)] [报告]

发表于 2012-11-23 20:37 |只看该作者 |倒序浏览

http://blog.chinaunix.net/uid-23849526-id-2921035.html
状态迁移

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选择第三种方式