一次面试过后的反思

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

1.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标志,连接断开。)

2.在tcp的三次握手过程中,假设第二次没有发送数据包,会出现什么情况?

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


    

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值