java后台面试_腾讯Java后台面试经验总结

三次握手、四次挥手：由于之前认真看过，所以讲得也算流畅，详细说了下过程

面试官问：“四次挥手最后B给A请求的等待时间(是什么时间)”

我：“emmmmmmmm，不知道”

后查询发现还是自己掌握得不好，其实答案也很简单，如下：

TCP关闭连接用四次握手来实现，即A--->B Fin, B--->A ACK, B--->A Fin, A--->B ACK，为什么要这样？

A--->B Fin, B--->A ACK ，A属于主动关闭方，收到B的ACK后，A到B的方向连接关闭，即half shutown ，

这时A不能再发送数据了。这种状态下B还是可以单向发送数据的，B的数据发送完毕，也做关闭动作了：B--->A Fin

A--->B ACKB收到ACK，关闭连接。但是A无法知道ACK是否已经到达B，于是开始等待？

等待什么呢？假如ACK没有到达B，B会为FIN这个消息超时重传 timeout retransmit ，

那如果A等待时间足够，又再次收到FIN消息，说明刚才A返回的ACK没有到达B，于是再发送ACK，

直到在足够的时间内没有收到FIN，说明ACK成功到达。

这个等待时间至少是：B的timeout + FIN的传输时间，为了保证可靠，采用更加保守的等待时间2MSL。

按照《趣谈网络协议》的形象说法：

断开的时候，我们可以看到，当 A 说“不玩了”，就进入 FIN_WAIT_1 的状态，B 收到“A 不玩”的消息后，发送知道了，就进入 CLOSE_WAIT 的状态。

A 收到“B 说知道了”，就进入 FIN_WAIT_2 的状态，如果这个时候 B 直接跑路，则 A 将永远在这个状态。TCP 协议里面并没有对这个状态的处理，但是 Linux 有，可以调整 tcp_fin_timeout 这个参数，设置一个超时时间。

如果 B 没有跑路，发送了“B 也不玩了”的请求到达 A 时，A 发送“知道 B 也不玩了”的 ACK 后，从FIN_WAIT_2 状态结束，按说 A 可以跑路了，但是最后的这个 ACK 万一 B 收不到呢？则 B 会重新发一个“B 不玩了”，这个时候 A 已经跑路了的话，B 就再也收不到 ACK 了，因而 TCP 协议要求 A 最后等待一段时间 TIME_WAIT，这个时间要足够长，长到如果 B 没收到 ACK 的话，“B 说不玩了”会重发的，A 会重新发一个 ACK 并且足够时间到达 B。