标签：10 ACK 报文 确认 TCP 计算机网络 服务器 连接

TCP的运输连接管理

TCP是面向连接的通信，运输连接是用来传送TCP报文的，TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。因此，运输连接有三个阶段，即：建立连接，数据传送，连接释放，运输连接的管理就是使运输连接和释放都能正常的进行。在TCP连接中主要解决以下问题：

• 要使每一方都能确认对方的存在。

• 要允许双方协商一些参数（如最大窗口值，是否使用窗口扩大选项和时间戳选项以及服务质量等）。

• 能够对运输实体资源进行合理的分配（如缓存大小，连接表中的项目等）。

TCP连接的建立采用客户服务器方式。主动发起连接建立的应用进程叫做客户（client）,而被动等待连接的应用进程叫做服务器（server）。

TCP的连接建立

TCP建立连接的过程叫握手，握手需要客户和服务器之间交换三个TCP报文段。如下图5-28。

假定主机A运行的是TCP客户程序，而B运行的是TCP服务程序，最初两端的连接处于CLOSE(关闭) 状态，在本例中A主动打开连接，B被动打开连接。

TCP握手过程描述：

1. 一开始,B的TCP服务器进程先创建传输控制块TCB（Transmission Control Block），准备接受客户进程的连接请求，然后服务器就处于LISTEN（监听）状态，等待客户的连接请求，如果有，就做出响应。
2. A的TCP客户进程也是首先创立传输控制模块TCB，然后在建立连接的时候，向服务器B发送连接请求报文段，这时候首部中的同步位SYN=1，同时选择一个初始序号seq=x。TCP规定：SYN报文段（SYN=1的报文段）不能携带数据，但是要消耗掉一个序列号，这时候，TCP客户端进程进入SYN-SENT同步已发送状态。
3. B收到连接请求的报文段，如果同意建立连接，则向A发送确认，在确认报文段SYN位=1，ACK位为1，确认号是ack=x+1，同时也为自己选择一个初始序号seq=y，注意，这个报文段也不能携带数据，但是同样要消耗一个序列号。这时候TCP服务器进程处于SYN-RCVD（同步收到）状态。
4. TCP客户进程收到B的确认后，还要给B给出确认，确认报文段的ACK=1确认号ack=y+1，而自己的序号seq=x+1。TCP的标准规定，ACK报文段可以携带数据，但如果不携带数据则不消耗序号，这种情况下，下一个数据报文段的序号仍然是seq=x+1，这时候，TCP连接已经建立连接，客户端A进入ESTABLISHED(已建立连接状态)，
5. B收到A的确认报文后，也进入ESTABLISHED状态。

上面给出的连接过程叫做三次报文握手，注意，在图中，当B发送给A的报文段，也可以拆分成两个报文段，可以先发送确认报文段（ACK=1,ack=x+1）,然后再发送一个同步报文段（SYN=1，seq=y）,这样的过程就变成了四报文握手，但效果是一样的。

为什么A最后还要发送一次确认呢？这主要是为了防止已失效的连接请求报文突然又传送到B，因而产生错误。

所谓“已失效的连接请求报文段”是这样产生的。考虑一种正常情况，A 发出连接请求，但因连接请求报文丢失而未收到确认。于是 A 再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接。A 共发送了两个连接请求报文段，其中第一个丢失，第二个到达了 B，没有“已失效的连接请求报文段”。

现假定出现一种异常情况，即 A 发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间滞留了，以致延误到连接释放以后的某个时间才到达 B。本来这是一个早已失效的报文段。但 B 收到此失效的连接请求报文段后，就误认为是A又发出一次新的连接请求。于是就向 A 发出确认报文段，同意建立连接。假定不采用报文握手，那么只要 B发出确认，新的连接就建立了。

由于现在 A 并没有发出建立连接的请求，因此不会理睬 B 的确认，也不会向 B 发送数据。但 B 却以为新的运输连接已经建立了，并一直等待 A 发来数据。B 的许多资源就这样白白浪费了。

采用三报文握手的办法，可以防止上述现象的发生。例如在刚才的异常情况下，A 不会
向B的确认发出确认。B 由于收不到确认，就知道A并没有要求建立连接。

TCP连接释放

TCP连接释放比较复杂，我们仍然结合双方状态的改变来阐明连接释放的过程。

数据传输结束后，通信的双方都可释放连接。现在 A 和 B 都处于 ESTABLISHED 状态（图5-29）。A 的应用进程先向其TCP发出连接释放报文段，并停止再发送数据，主动关闭TCP 连接。A 把连接释放报文段首部的终止控制位 FIN 置 1，其序号 seq = u，它等于前面已传送过的数据的最后一个字节的序号加 1。这时 A 进入 FIN-WAIT-1（终止等待 1）状态，等待 B 的确认。请注意，TCP 规定，FIN 报文段即使不携带数据，它也消耗掉一个序号。

• B服务器收到连接释放的报文段后立即发出确认，确认号为ack=u+1，而这个报文段自己的序号为v，等于B前面已传过的数据的最后一个字节+1，然后服务器就进入CLOSE-WAIT(关闭等待)状态，TCP服务器进程这时候通知高层应用进程，因而从客户端A到服务器端B这个连接就释放了，这时候的TCP连接窗台处于半关闭状态（HALF-CLOSE），A已经没有数据发送给B了，但是B要使发数据，A仍然要接受，也就说，从B到A的方向的连接仍未关闭，这个状态可能还要持续一段时间。 A收到来自B的确认后，就进入FIN-WAIT2(终止等待2)状态，等待B发出的连接释放报文段。若B已经没有必要向A发送数据了，其应用进程就通知TCP释放连接。这时候B发出的连接释放报文段必须使FIN=1。现假设B的序号为w，B还重复上次已经发送过的确认号ack=u+1，这时候B就进入LAST-ACK（最后确认状态），等待A的确认。A在收到B的连接释放的时候，必须对此发出确认，在确认报文段中把ACK=1,确认号ack=w+1，自己的序号为seq=u+1，然后进入到TIME-WAIT（时间等待状态），注意，现在的TCP并没有断开连接，而是必须经过时间等待计时器设置的2MSL(max segment lifetime),A才能进入CLOSED状态，时间MSL叫做最长报文段寿命，RFC标准建议为2min。为什么要设立时间等待状态必须为2MSL呢？

  1. 为了保证客户端发送额最后一个ACK报文段能够到达B，这个ACK报文段有可能会丢失，因而使用LAST-ACK状态的B收不到对已发送FIN+ACK报文的确认，B会超时重传这个FIN+ACK报文段，而A就能在2MSL时间内收到这个重传的FIN+ACK报文段，接着A重传一次确认，重新启动AMSL计时器。最后知道A和B都进入CLOSED状态。
  2. 防止上面提到的已失效的连接请求报文段出现在本连接中，A在发完最后一个ACK报文段的时候，再经过2MSL时间，就可以是本连接持续的时间内产生的所有报文段都从网络中协消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求文。

  除了时间等待计时器之外，还应该设有保活计时器（keep-live timer），有这样的一个场景：客户端已经主动与服务器建立了TCP连接，但是后来客户端的主机突然出现了故障，显然，服务器以后就不能在也接收到客户端的数据了，因此，服务器就没有必要浪费资源继续与出现故障的客户端继续保持相连。这就需要使用保活计时器，服务器每收到一次客户端请求的数据，就重新重置保活计数器，时间的设置通常是两小时，若两小时内没有收到客户端的数据，服务器就发送一个探测报文段，以后每隔75s发送一个，若一连发送10个探测报文段后仍然没有相应，服务器就认为该客户端出现了故障，就关闭这个连接。

TCP的有限状态机)

为了更清晰地看出 TCP 连接的各种状态之间的关系，图 5-30 给出了 TCP 的有限状态机。图中每一个方框即 TCP 可能具有的状态。每个方框中的大写英文字符串是 TCP 标准所使用的 TCP 连接状态名。状态之间的箭头表示可能发生的状态变迁。箭头旁边的字，表明引起这种变迁的原因，或表明发生状态变迁后又出现什么动作。请注意图中有三种不同的箭头。粗实线箭头表示对客户进程的正常变迁。粗虚线箭头表示对服务器进程的正常变迁。另一种细线箭头表示异常变迁。

标签：10,ACK,报文,确认,TCP,计算机网络,服务器,连接
来源： https://www.cnblogs.com/xiaomitu/p/15874310.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。