当前位置:   article > 正文

TCP连接建立_建立 tcp 连接

建立 tcp 连接

TCP: 一种面向来连接的、可靠的、基于字节流的传输层通信协议。

  • 面向连接: 数据在发送之前必须在两端建立连接,方法就是我们熟知的三次握手连接。
  • 可靠传输: 通过多种机制来保证数据的正确传输,比如序列号/确认应答机制、检验和机制、超时重传机制、流量控制、拥塞避免机制等。
  • 基于字节流: 虽然应用程序和TCP的交互是一次一个数据块(大小不等),但TCP把应用程序看成是一连串的无结构的字节流。TCP有一个缓冲,当应用程序传送的数据块太长,TCP就可以把它划分短一些再传送。如果应用程序一次只发送一个字节,TCP也可以等待积累有足够多的字节后再构成报文段发送出去。

特点:

  • 面向连接
  • 仅支持单播传输
  • 面向字节流
  • 可靠传输
  • 提供全双工通信

TCP的三次握手:
在这里插入图片描述

1、客户端向服务器申请建立TCP连接,向服务发送一个SYN报文,作为第一次握手。客户端把这段连接的SYN设定为随机数A。

2、服务器端收到SYN报文后,会向客户端发送一个报文。报文中ACK的确认码为A+1,同时发送另一个SYN为随机序号B。

3,此时,客户端收到ACK为A+1的报文,将之与发送的SYN包进行比对,如果满足+1的关系,则在客户端判断连接已建立。并给服务器发送确认数据包,SYN为A+1,表明已收到上一报文,ACk为B+1,通知服务器进入连接状态。

TCP的四次挥手:
在这里插入图片描述

1、客户端向服务器发送一个FIN报文,作为第一次挥手。通知服务器,我已经没有数据还要发送。但不确认服务器是否仍有数据返回,所以连接仍是建立状态。
2、服务器收到FIN报文,返回一个ACK报文,告诉客户端,我知道你已经没有东西要发送了,但我还要再确认一下我是不是还有东西要给你。
3、服务器判断自己也没有报文需要发送给客户端,发送FIN报文,告诉客户端,好了,这下我也没有东西要给你了,你可以终结连接了。此时服务器不确认客户端是否收到信息,继续保持连接。
4、客户端收到ACK和FIN消息后,得知服务器已经知道自己要终结,并无更新内容,便给服务器发送一个ACK说我知道了,你也终结吧,客户机便终结连接。服务器在收到一条ACK后,也终结连接。

面试题:

  1. 为什么连接的时候是三次握手,关闭的时候却是四次握手?

因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。
其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,“你发的FIN报文我收到了”。
只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。

  1. 为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?

按道理,四个报文都发送完毕,我们可以直接进入CLOSE状态了,但是我们必须假象网络是不可靠的,有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。
在Client发送出最后的ACK回复,但该ACK可能丢失。Server如果没有收到ACK,将不断重复发送FIN片段。所以Client不能立即关闭,它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器,等待2MSL的时间。如果在该时间内再次收到FIN,那么Client会重发ACK并再次等待2MSL。
所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间,2MSL就是一个发送和一个回复所需的最大时间。
如果直到2MSL,Client都没有再次收到FIN,那么Client推断ACK已经被成功接收,则结束TCP连接。

  1. 为什么不能用两次握手进行连接?

3次握手完成两个重要的功能,既要双方做好发送数据的准备工作(双方都知道彼此已准备好),也要允许双方就初始序列号进行协商,这个序列号在握手过程中被发送和确认。

现在把三次握手改成仅需要两次握手,死锁是可能发生的。作为例子,考虑计算机S和C之间的通信,假定C给S发送一个连接请求分组,S收到了这个分组,并发 送了确认应答分组。按照两次握手的协定,S认为连接已经成功地建立了,可以开始发送数据分组。可是,C在S的应答分组在传输中被丢失的情况下,将不知道S 是否已准备好,不知道S建立什么样的序列号,C甚至怀疑S是否收到自己的连接请求分组。在这种情况下,C认为连接还未建立成功,将忽略S发来的任何数据分 组,只等待连接确认应答分组。而S在发出的分组超时后,重复发送同样的分组。这样就形成了死锁。

  1. 如果已经建立了连接,但是客户端突然出现故障了怎么办?

CP还设有一个保活计时器,显然,客户端如果出现故障,服务器不能一直等下去,白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器,时间通常是设置为2小时,若两小时还没有收到客户端的任何数据,服务器就会发送一个探测报文段,以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应,服务器就认为客户端出了故障,接着就关闭连接。

  1. 在握手与挥手的过程中,往复的ack与seq有什么含义?

这是通信双方在通信过程中的一种确认手段,确保通信双方通信的正确性。例如小时候模仿电视剧里无线电呼叫的过程:“土豆土豆,我是地瓜,你能听到吗?”“地瓜地瓜,我是土豆,我能听到”。 若客户端的报文请求号为“土豆”,则服务器端就将返回确认号“土豆+1”(标志土豆已收到),是一种通信双方的确认手段。

  1. 在结束连接的过程中,为什么在收到服务器端的连接释放报文段之后,客户端还要继续等待2MSL之后才真正关闭TCP连接呢?

① 需要保证服务器端收到了客户端的最后一条确认报文。假如这条报文丢失,服务器没有接收到确认报文,就会对连接释放报文进行超时重传,而此时客户端连接已关闭,无法做出响应,就造成了服务器端不停重传连接释放报文,而无法正常进入关闭状态的状况。而等待2MSL,就可以保证服务器端收到了最终确认;若服务器端没有收到,那么在2MSL之内客户端一定会收到服务器端的重传报文,此时客户端就会重传确认报文,并重置计时器。
②存在一种“已失效的连接请求报文段”,需要避免这种报文端出现在本连接中,造成异常。

这种“已失效的连接请求报文段”是这么形成的:假如客户端发出了连接请求报文,然而服务器端没有收到,于是客户端进行超时重传,再一次发送了连接请求报文,并成功建立连接。然而,第一次发送的连接请求报文并没有丢失,只是在某个网络结点中发生了长时间滞留,随后,这个最初发送的报文段到达服务器端,会使得服务器端误以为客户端发出了新的请求,造成异常。

  1. 若通信双方同时请求连接或同时请求释放连接,情况如何?

这种情况虽然发生的可能性极小,但是是确实存在的,TCP也特意设计了相关机制,使得在这种情况下双方仅建立一条连接。双方同时请求连接的情况下,双方同时发出请求连接报文,并进入SYN-SENT状态;当收到对方的请求连接报文后,会再次发送请求连接报文,确认号为对方的SYN+1,并进入SYN-RCVD状态;当收到对方第二次发出的携带确认号的请求报文之后,会进入ESTAB-LISHED状态。 双方同时请求释放连接也是同样的,双方同时发出连接释放报文,并进入FIN-WAIT-1状态;在收到对方的报文之后,发送确认报文,并进入CLOSING状态;在收到对方的确认报文后,进入TIME-WAIT状态,等待2MSL之后关闭连接。需要注意的是,这个时候虽然不用再次发送确认报文并确认对方收到,双方仍需等待2MSL之后再关闭连接,是为了防止“已失效的连接请求报文段”的影响

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/从前慢现在也慢/article/detail/694241
推荐阅读
相关标签
  

闽ICP备14008679号