TCP可靠传输-运输连接管理

TCP是面向连接的协议。运输连接及=是用来传送TCP报文的，TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。因此，运输连接就有三个阶段，即：连接建立、数据传送和连接释放。运输连接的管理就是使运输连接的建立和释放都能正常地进行。

在TCP连接建立过程中要解决一下三个问题：

• 要使每一方能够确知对方的存在。
• 要允许双方协商一些参数(如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等)。
• 能够对运输实体资源(缓存大小、连接表中的项目等)进行分配。

TC+P连接的建立采取客户服务器方式。主动发起连接建立的应用进程叫做客户，而被动等待连接的=建立的应用进程叫做服务器

TCP的连接建立

tcp的建立过程其实就是三次握手过程(复习一下：三次握手是在客户端执行connect()后进行的)

下面，通过一个例子来引出具体的过程描述，(假如老王现在要和建国通话)：

 在介绍过程之前，可以先看看我之前写的这篇博客(关于TCP头部的解释)：

https://blog.youkuaiyun.com/qq_54669536/article/details/124254447

上述这个例子是不是很好理解呢，其实在TCP建立连接时，和它是很相似的，只不过有很多小细节需要处理，如图：

 三次握手就是类似这个过程。

 解释：

最初两端的进程都处于CLOSE(关闭)状态；

一开始，TCP服务器进程先创建传输控制块TCB，准备接受客户进程的连接请求，然后服务器进程就处于LISTEN(监听)状态，等待客户到的连接请求。

客户端进程也是首先创建传输控制快TCB，然后，在打算建立TCP连接时，向B发出连接请求报文段，这时首部中的同步位SYN=1，同时选择一个1初始序号seq=X。TCP规定，SYN报文段不能携带数据，但要消耗掉一个序号。这时，TCP客户进程进入SYN_SENT(同步已发送)状态。

服务器端收到请求连接报文段后，若同意建立连接，则向客户端发送确认。在确认报文段中应把SYN位和ACK都置为1(ACK置为1确认号才有效)，确认号ack=x+1,同时也为自己选择一个初始序号seq=y。请注意，这个报文段也不能携带数据，这时TCP服务器进程进入SYN_RCVD(同步收到)状态。

TCP客户端收到服务器端的确认后，还要服务器端确认，ACK依旧为1，确认号ack=y+1,而自己的序号为seq=x+1。TCP的标准规定，ACK报文段可以携带数据。但如果不携带数据则不消耗序号，在这种情况下，下一个数据报文段的序号仍是seq=x+1。这时，TCP连接已经建立，客户端进入ESTABISHED(已建立连接状态)状态。

服务器端收到客户端的确认后，也进入ESTABLISHED状态。

这个时候面试官问了，两次握手行不行呢？

假如老王没有给建国说我也听得到，那么建国就认为老王听不到，这个时候建国是不说话的，说话不能保证老王能听到，肯定不敢说。

在TCP连接中也是类似的情况，第三次握手主要是为了防止已失效的连接请求报文段突然又传送到了服务器端

假设客户端给服务器端发的请求连接报文段在某个网络点滞留了，过了一段时间后，客户端重新发送了请求连接，重新建立的通信，待这个通信结束后，之前那个滞留的请求报文段服务器端又收到了，此时服务器端认为客户端又要和我建立连接，于是发送了确认报文段。但是现在情况是，客户端此时并没有主动连接，那只是之前的，所以客户端对服务器发来的确认不予理睬，也不会向服务器端发送任何数据。假设没有第三次握手，那么服务器端认为此时已经建立了连接，等待客户端发送过来的数据，那么B的许多资源就白白浪费了。

 注：传输控制块TCP存储了每一个连接中的一些重要信息，如：TCP连接表，指向发送和接收缓存的指针，指向重传队列的指针，当前的发送和接收序号等

TCP的连接释放

所谓连接释放其实也就是四次挥手的过程,如图：

 真是的四次挥手也类似上述过程

解释：

TCP通信结束后，两端仍处于ESTABLIAHED状态。现在开始要进行四次挥手的过程

第一次挥手：客户端进程先向其TCP发出连接释放报文段，并停止发送数据，主动关闭TCP连接。A把连接释放报文段首部的终止控制位FIN置为1，其序号seq=u，它等于前面已传送过的数据的最后一个字节的序号加1。这时客户端进入FIN_WAIT_1(终止等待1)状态，等待服务器端的确认。注意：TCP规定，FIN报文段即使不携带数据，它也消耗掉一个序号。

第二次挥手：服务器端收到客户端的连接释放报文段后即发出确认，ACK置为1，确认号ack=u+1,而这个报文段自己的序号是v,它等于前面已传送过的数据最后一个字节的序号加1。然后服务器端就进入CLOSE_WAIT(关闭等待)状态。TCP服务器进程这时应通知高层应用进程，因而从客户端到服务器端这个方向的连接就释放了，这时的TCP连接处于半关闭状态，即客户端已经不能发送数据了，服务器端不能接收数据了，但是服务器端可以发送数据，客户端可以接收数据，这个状态可能会持续一段时间。

客户端收到服务器端发来的确认后，就进入FIN_WAIT_2(终止等待2)状态，等待服务器端发出的连接释放报文段。

第三次挥手：若服务器端已经没有要向客户端发送的数据，其应用进程就通知TCP连接释放连接。这时服务器端发送出的连接释放报文段必须使FIN=1。现在假定服务器端的序号为w(在半关闭状态服务器端可能又发送了一些数据(假定数据量为n),即：w=v+n)，B还必须重复上次已经发送过的确认号ack=u+1(ACK依旧为1)，这时服务器端就进入LAST_ACK(最后确认)状态，等待客户端的确认。

第四次挥手：客户端在收到服务器端的连接释放报文段后，必须对此发出确认。在确认报文段把ACK置为1，确认号ack=w+1,而自己的序号是seq=u+1。然后进入到TIME_WAIT(时间状态)状态。请注意，现在TCP连接还没有释放掉。必须等待时间等待计时器设置的时间2MSL后，客户端才进入到CLOSE状态。时间MSL叫做最长报文段寿命

 这个时候，面试官又问了，最后为什么要等待2MSL？

两个原因：

第一，为了保证客户端发送的最后一个ACK确认报文段能够到达服务器端。这个ACK很可能丢失，因而处于LASK_ACK状态的服务器端手不戴对已发送的FIN+ACK报文段的确认。服务器端会超时重传这个FIN+ACK报文段，而客户端就能在2MSL时间内收到这个重传的FIN+ACK报文段。接着客户端再重传一次确认，重新启动2MSL计时器。最后，客户端和服务器端都正常进入到CLOSED状态。如果客户端在TIME_WAIT状态不等待一段时间，而是在发送完ACK报文段之后就直接断开连接，那么就无法接受到服务器端重传的报文，B就无法按照正常步骤进入CLOSED状态。

第二，客户端在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的的所有报文段都从网络中丢失，这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段(即已失效的报文段)。

关于这里的问题，也可以看一下，我另一篇博客！！！

https://blog.youkuaiyun.com/qq_54669536/article/details/120544046