一次面试过后的反思

昨天，滴滴出行的技术人员对我进行了一轮电话面试。在面试过后，关于一些面试题的反思。

１．tcp为什么要三次握手，四次挥手？

    这个问题，当时一下没有想出来。可能有点紧张吧。

    三次握手：

    第一种回答：“这个问题的本质是, 信道不可靠, 但是通信双发需要就某个问题达成一致. 而要解决这个问题, 无论你在消息中包含什么信息, 三次通信是理论上的最小值. 所以三次握手不是TCP本身的要求, 而是为了满足"在不可靠信道上可靠地传输信息"这一需求所导致的. 请注意这里的本质需求,信道不可靠, 数据传输要可靠. 三次达到了, 那后面你想接着握手也好, 发数据也好, 跟进行可靠信息传输的需求就没关系了. 因此,如果信道是可靠的, 即无论什么时候发出消息, 对方一定能收到, 或者你不关心是否要保证对方收到你的消息, 那就能像UDP那样直接发送消息就可以了.”。

    第二种回答：谢希仁版《计算机网络》中的例子是这样的，“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”。主要目的防止server端一直等待，浪费资源。

    四次挥手：

    由于tcp是双向连接。关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。（因为，在server收到fin标志后，表示client段没有数据了，但是server端还有可能在发送数据，所以，在收到client端的fin标志后，server端必须回复一个ack和一个fin标志，表示server端的数据也停止发送了，最后,client端发送一个ack，表示收到了server的fin标志，连接断开。）

２．在tcp的三次握手过程中，假设第二次没有发送数据包，会出现什么情况？

    如果出现这种情况，server端不会收到client端的ack+syn回应，那么，server会尝试重新发送，并且会维持这个半连接。通常维持时间一般是几分钟。一个这样的半连接并不会消耗过多的server的资源，但是，要是有人模仿或者恶意攻击server。在短时间内，出现大量的半连接状态。那么，server维护的半连接状态就会迅速耗尽server的资源，导致服务崩溃。（SYN Flood）SYN泛洪。