TCP连接和释放

TCP是面向连接的协议，运输连接用于传送TCP报文，TCP的运输连接包括三个阶段：连接建立、数据传送和连接释放。

TCP连接

TCP建立连接的过程叫做握手，握手需要在客户端和服务器之间交换三个TCP报文段。将TCP连接称为“三次握手”是不严谨的，应该是在一次握手的过程中交换了三个TCP报文。

假设主机A运行的是TCP客户程序，B运行的是TCP服务器程序。最初两端的TCP进程都处于CLOSED状态。

当客户端需要发送请求时，主动打开连接，A的TCP客户进程首先创建传输控制模块TCB，向B发送连接请求报文段，此时TCP报文首部的同步位SYN=1，同时选择一个初始序号seq=x。（TCP协议规定，SYN报文段不能携带数据，但要消耗掉一个序号）此时，A进入SYN-SENT（同步已发送）阶段。

B收到连接请求报文段后，如同意建立连接，则向A发送确认，确认报文段中SYN位和ACK位都置1，确认号是ack=x+1，自己的初始序号seq=y。这时，TCP服务器进程进入SYN-RCVD（同步收到）状态。

A收到B的确认后，还要给B确认。ACK置1，确认号ack=y+1,自己的序号seq=x+1。（ACK报文段可以携带数据，如果不携带数据则不消耗序号，下一个数据报文段的序号仍然是seq=x+1）此时，TCP连接建立，A进入ESTABLISTENED（已建立连接）状态。

B收到A的确认，也进入ESTABLISTENED状态。

问题：为什么是三报文握手而不是两报文握手？

主要是为了防止已失效的连接请求报文段突然又传送到了B：A发出连接请求，但因连接请求报文丢失而未收到确认，于是A再一次重传连接请求，后来A收到了确认，建立了连接。假如A第一次连接请求的报文段并没有丢失，而是在某网络结点长时间滞留了，以致延误到连接释放以后的某个时间才到达B。B收到此失效的连接请求报文段后，就误认为是A又发出的一次新的连接，于是就向A发出确认报文段，同意建立连接。假定不采用报文握手，只要B发出确认，新的连接就建立了。而此时A并没有发出建立连接的请求，B却一直等待A发送数据，就会浪费B的资源。

TCP释放

TCP释放的过程我们可以称为四次挥手。

第一次挥手：由客户端A向服务器发送连接释放请求，此时，A的TCP报文首部的终止控制位FIN=1，序号seq=u（TCP规定，FIN报文段即使不携带数据，也要消耗一个序号）。A进入FIN-WAIT1状态。

第二次挥手：B收到A的连接释放请求后，向A发送一个确认报文，确认号ack=u+1，这个报文自己的序号seq=v（=B之前传送的数据的最后一个字节的序号+1），此时TCP连接处于半关闭状态，即A没有数据要发送，但B若发送数据，A仍要接收。A进入FIN-WAIT2状态，等待B发出的连接释放报文段。

第三次挥手：B没有要向A发送的数据之后，其应用进程就会通知TCP释放连接，此时B发送FIN报文，假定B的序号seq=w（半关闭状态B又发送了一些数据），B重复上一次的确认号ack=u+1。此时B进入LAST-ACK状态，等待A的确认。

第四次挥手：客户端收到连接释放报文段之后，必须发出确认：ACK=1,seq=u+1,ack=w+1。 再经过2MSL(最长报文端寿命)后，本次TCP连接真正结束。

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

第一个是：需要保证服务器端收到了客户端的最后一条确认报文。假如这条报文丢失，服务器没有接收到确认报文，就会对连接释放报文进行超时重传，而此时客户端连接已关闭，无法做出响应，就造成了服务器端不停重传连接释放报文，而无法正常进入关闭状态的状况。而等待2MSL，就可以保证服务器端收到了最终确认；若服务器端没有收到，那么在2MSL（最长报文段寿命）之内客户端一定会收到服务器端的重传报文，此时客户端就会重传确认报文，并重置计时器。

第二个是：存在一种“已失效的连接请求报文段”，需要避免这种报文端出现在本连接中，造成异常。
A在发送完最后一个ACK报文段之后，再经过2MSL，就可以使本连接持续时间内产生的所有报文都从网络中消失，这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。

标签：释放,报文,确认,TCP,序号,连接,客户端
来源： https://www.cnblogs.com/JJuan/p/16253379.html