谢希仁版《计算机网络》中的例子:
"已失效的连接请求报文段”的产生在这样一种情况下：
client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。
本来这是一个早已失效的报文段,但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。
于是就向client发出确认报文段，同意建立连接。
假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。
由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据,但server却以为新的运输连接已经建立，并一直等待client发来数据。
这样，server的很多资源就白白浪费掉了。
采用“三次握手”的办法可以防止上述现象发生。
例如刚才那种情况，client不会向server的确认发出确认,server由于收不到确认，就知道client并没有要求建立连接。”
这个例子很清晰的阐释了“三次握手”对于建立可靠连接的意义。
编辑于 2016-03-07 21:26:53
回复(5)
第一次握手，发送SYN报文，传达信息：“你好，我想建立连接”；
第二次握手，回传SYN+ACK报文，传达信息：“好的，可以建立链接”；
第三次握手，回传ACK报文，传到信息：“好的，我知道了，那我们连接”。然后就建立连接了。在发送报文之前各方都要确认可以进行连接。
之所以采取三次握手机制，不过是为了信息传输的可靠性，如果其中某个握手失败，这个过程将会重复，来确保其可靠性。
如果采取两次握手，相当于第二次握手结束便建立连接，如果发送SYN的一方不想连接了，也不会有反馈，另一方却一直在等待，浪费了时间。
当然可以采取4次甚至N次握手，但是有必要吗？建立连接的时间太长，效果也会大打折扣。
所以3次只是折中方案，保证了可靠性，又节俭了建立连接的时间，是吧，哈哈。
发表于 2016-11-09 17:18:43
回复(1)
为什么不采用两次握手？ 如果是两次握手的情景: 客户端在发送一个连接建立请求之后进入等待状态，等到服务端确认之后就进入established状态。服务端在发送一个确认连接建立请求报文之后(不管客户端是否有回应)也进入established状态。 这就好比， A给B打电话， A:你听得到我说话吗？ B:我听得到啊 A和B就都以为对方都能听得到自己了。 但有一种情况是，B的麦是坏的，A根本就听不到B说话，结果A没收到B的回应，但B却以为A能听得到他，B就一直等着A说点什么...这样让B身心俱疲。 三次握手: 客户端在发送一个连接建立请求报文之后进入等待状态，等到服务端返回确认建立连接的通知; 服务端发送确认建立连接请求报文，同时向客户端发送连接建立请求报文，进入等待状态。 客户端接受到服务端发送的确认请求报文。进入established状态。客户端接受到来自服务端的连接建立请求报文，发送确认连接建立请 求报文。 服务端接受到来自客户端的确认建立连接报文，进入established。 如果是三次握手，则会是这样: A:你能听得到我说话吗？ B:我听得到啊，你能不能听得到我说话？ A:我也听得到你啊。( established) B:(established) A和B都能明确知道对方肯定能听得到自己说话 这样A和B就能安心煲电话粥了。从此过上幸福的快乐的生活。
发表于 2018-03-25 11:18:42
回复(0)
答:建立连接的过程是利用客户服务器模式，假设主机A为客户端，主机B为服务器端。
（1）TCP的三次握手过程：主机A向B发送连接请求；主机B对收到的主机A的报文段进行确认；主机A再次对主机B的确认进行确认。
（2）采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B，因而产生错误。失效的连接请求报文段是指：主机A发出的连接请求没有收到主机B的确认，于是经过一段时间后，主机A又重新向主机B发送连接请求，且建立成功，顺序完成数据传输。考虑这样一种特殊情况，主机A第一次发送的连接请求并没有丢失，而是因为网络节点导致延迟达到主机B，主机B以为是主机A又发起的新连接，于是主机B同意连接，并向主机A发回确认，但是此时主机A根本不会理会，主机B就一直在等待主机A发送数据，导致主机B的资源浪费。
（3）采用两次握手不行，原因就是上面说的实效的连接请求的特殊情况。
（1）TCP的三次握手过程：主机A向B发送连接请求；主机B对收到的主机A的报文段进行确认；主机A再次对主机B的确认进行确认。
（2）采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B，因而产生错误。失效的连接请求报文段是指：主机A发出的连接请求没有收到主机B的确认，于是经过一段时间后，主机A又重新向主机B发送连接请求，且建立成功，顺序完成数据传输。考虑这样一种特殊情况，主机A第一次发送的连接请求并没有丢失，而是因为网络节点导致延迟达到主机B，主机B以为是主机A又发起的新连接，于是主机B同意连接，并向主机A发回确认，但是此时主机A根本不会理会，主机B就一直在等待主机A发送数据，导致主机B的资源浪费。
（3）采用两次握手不行，原因就是上面说的实效的连接请求的特殊情况。
发表于 2015-10-29 12:06:16
回复(0)
问题1/为什么不用两次握手？ 客户端向服务器发送SYN，按两次握手来说，客户端只要收到ACK就是连接成功。假如SYN丢包了，客户端会定时再次发送。 1.那假如并没有丢包而是网络延时，客户端就会发送很多SYN给服务器，服务器是个一对多的工作环境，这样会造成服务器的效率低下。 2.假如SYN包一直延迟到连接都已经结束了断开了，服务器才收到，服务器会以为这是新的连接申请，给客户端发ACK响应，但客户端并没有发送再SYN，不予理会，服务器会以为连接成功。这样会浪费服务器可用资源。但假设服务器发送ACK之后还要听一听客户端的“想法”，那就是三次握手了。 问题2/ 为什么要三次握手？ 1.因为TCP的socket是一个双全工，必须建立两个方向上的连接。 2.假设上述丢包情况发生，那么服务器收不到ACK，连接不会建立，还会向客户端不停发送ACK，虽然客户端会收到很多SYN但这样避免了服务器收到冗余数据。
编辑于 2019-04-17 20:15:03
回复(0)
（1）TCP的三次握手过程：主机A向B发送连接请求；主机B对收到的主机A的报文段进行确认；主机A再次对主机B的确认进行确认。 （2）采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B，因而产生错误。 （3）采用两次握手不行，特殊情况：主机A第一次发送的连接请求并没有丢失，而是因为网络节点导致延迟达到主机B，主机B以为是主机A又发起的新连接，于是主机B同意连接，并向主机A发回确认，但是此时主机A根本不会理会，主机B就一直在等待主机A发送数据，导致主机B的资源浪费。
编辑于 2020-04-01 23:47:30
回复(0)
答:建立连接的过程是利用客户服务器模式，假设主机A为客户端，主机B为服务器端。
（1）TCP的三次握手过程：主机A向B发送连接请求；主机B对收到的主机A的报文段进行确认；主机A再次对主机B的确认进行确认。
（2）采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B，因而产生错误。失效的连接请求报文段是指：主机A发出的连接请求没有收到主机B的确认，于是经过一段时间后，主机A又重新向主机B发送连接请求，且建立成功，顺序完成数据传输。考虑这样一种特殊情况，主机A第一次发送的连接请求并没有丢失，而是因为网络节点导致延迟达到主机B，主机B以为是主机A又发起的新连接，于是主机B同意连接，并向主机A发回确认，但是此时主机A根本不会理会，主机B就一直在等待主机A发送数据，导致主机B的资源浪费。
（3）采用两次握手不行，原因就是上面说的失效的连接请求的特殊情况。
（1）TCP的三次握手过程：主机A向B发送连接请求；主机B对收到的主机A的报文段进行确认；主机A再次对主机B的确认进行确认。
（2）采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B，因而产生错误。失效的连接请求报文段是指：主机A发出的连接请求没有收到主机B的确认，于是经过一段时间后，主机A又重新向主机B发送连接请求，且建立成功，顺序完成数据传输。考虑这样一种特殊情况，主机A第一次发送的连接请求并没有丢失，而是因为网络节点导致延迟达到主机B，主机B以为是主机A又发起的新连接，于是主机B同意连接，并向主机A发回确认，但是此时主机A根本不会理会，主机B就一直在等待主机A发送数据，导致主机B的资源浪费。
（3）采用两次握手不行，原因就是上面说的失效的连接请求的特殊情况。
发表于 2019-10-23 20:13:51
回复(0)
客户端发送的连接请求，并没有消失，而是在某个网络节点长时间滞留了，以至于延迟到连接释放之后才打到服务器。原本这个早已失效的报文段，但是服务器误认为是客服端发送的新的请求，于是就向客户端发送确定的报文段，同意建立连接，若不采用三次握手，新的连接就建立了。由于客户端并没有发送连接请求，不会理睬服务器的请求，浪费服务器的资源。
发表于 2016-09-25 13:24:35
回复(0)
问题信息
相关试题
-
扫描二维码，关注牛客网
- 意见反馈
-
下载牛客APP，随时随地刷题
扫一扫，把题目装进口袋
- 求职之前，先上牛客
-
扫描二维码，进入QQ群
扫描二维码，关注牛客公众号
- 公司地址：北京市朝阳区北苑路北美国际商务中心K1座一层-北京牛客科技有限公司
- 联系方式：010-60728802 投诉举报电话：010-57596212（朝阳人力社保局）
- 牛客科技© All rights reserved admin@nowcoder.com
- 京ICP备14055008号-4 增值电信业务经营许可证 营业执照 人力资源服务许可证
-
京公网安备
11010502036488号
