四次挥手

背景描述 我们知道网络层，可以实现两个主机之间的通信。但是这并不具体，因为，真正进行通信的实体是在主机中的进程，是一个主机中的一个进程与另外一个主机中的一个进程在交换数据。IP协议虽然能把数据报文送到目的主机， 但是并没有交付给主机的具体应用进程 。而 端到端的通信 才应该是应用进程之间的通信。 UDP，在传送数据前不需要先建立连接，远地的主机在收到UDP报文后也不需要给出任何确认。虽然UDP不提供可靠交付，但是正是因为这样，省去和很多的开销，使得它的速度比较快，比如一些对实时性要求较高的服务，就常常使用的是UDP。对应的应用层的协议主要有 DNS,TFTP,DHCP,SNMP,NFS 等。 TCP，提供面向连接的服务，在传送数据之前必须先建立连接，数据传送完成后要释放连接。因此TCP是一种可靠的的运输服务，但是正因为这样，不可避免的增加了许多的开销，比如确认，流量控制等。对应的应用层的协议主要有 SMTP,TELNET,HTTP,FTP 等。 常用的熟知端口号 应用程序 FTP TFTP TELNET SMTP DNS HTTP SSH MYSQL 熟知端口 21,20 69 23 25 53 80 22 3306 传输层协议 TCP UDP TCP TCP UDP TCP TCP的概述 TCP把连接作为最基本的对象，每一条TCP连接都有两个端点，这种断点我们叫作套接字

1 问题描述： 最近websocket服务程序在绑定某些固定端口失败，使用statnet -noa查看后发现，系统中残留大量CLOSE_WAIT的状态和TIME_WAIT状态的端口。从而导致在绑定监听端口时，socket失败的情况。 CLOSE_WAIT 2 原理讲解 我们知道，在socket编程中，TCP的连接和断开需要经过三次握手和四次挥手的过程。这里着重讲四次挥手。当服务器端/客户端程序主动调用closesocket端口后，主动断开方就会向被动方发送FIN信号，被动方收到FIN信号后，就进入了 CLOSE_WAIT 状态。如果一切正常，稍后被动方需要再次发出 FIN 包，进而迁移到 LAST_ACK 状态；主动方收到FIN包后，回复ACK信号，并且状态变为TIME_WAIT状态，并且等待2倍的MSL周期后，状态变为CLOSED状态；当被动断开方收到ACK信号后，状态变为CLOSED状态。 四次挥手交互图以及调用函数 以上理论，在很多的文章都有详细的描述，个人感觉 https://www.cnblogs.com/kevingrace/p/9988354.html 文章描述的很好。之所以，TCP结束要设计如此的繁复，其实和日常打电话的情况是一样的；要挂电话之前，先要问对方是否还有其他事情，没有其他事情的情况下，才能真真的做出挂电话的动作。 实现代码在附件中，

讲一讲TCP的四次挥手？ 第一次挥手 ：客户端发送一个FIN，用来关闭客户端到服务器端的数据传送，客户端进入FIN_WAIT_1状态。 第二次挥手 ：服务器端收到FIN后，发送一个ACK给客户端，确认序号为收到的序号+1(与SYN相同，FIN只占用一个序列号),服务器端进入COLSE_WAIT状态。 第三次挥手 ：服务器端发送一个FIN，用来关闭服务器端到客户端的数据传送，服务器端进入LAST_ACK状态。 第四次挥手 ：客户端接收到FIN后，客户端进入TIME_WAIT状态，接着发送一个ACK给服务器端，确认序号为收到的序号+1，服务器端进入CLOSED状态，完成四次挥手。 面试题： 为什么要有TIME_WAIT状态？ 确保有足够的时间让对方收到ACK包，避免新旧连接混淆。 什么情况下服务器会出现大量的CLOSE_WAIT状态？ 当很多客户端大量请求然后关闭Socket连接，服务器方忙于读或写，没有及时关闭连接。 来源： CSDN 作者： 黄机智！ 链接： https://blog.csdn.net/weixin_43813004/article/details/104297352

TCP的三次握手建立连接 第一次握手：建立连接时，客户端发送SYN包（syn=j）到服务器，并进入SYN_SEND状态，等待服务器确认 第二次握手：服务器收到SYN包，必须确认客户的SYN（ack=j+1）,同时自己也发送一个SYN包(syn=k),即SYN+ACK包，此时服务器进入SYN_RECV状态 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1),此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手 为什么需要三次握手才能建立起连接？ 为了初始化Sequence number的初始值，这个值要作为以后通信的序号 TCP的四次挥手释放连接 第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态； 第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到的序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态； 第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态； 第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给server，确认序号为收到的序号+1

涉及到的3个标志位： SYN：为1时表示发起新连接。 FIN：终止这一方向的连接，如client向server发送FIN，那么server将不会再接受请求，但是server还是能发送。 ACK：为1时表示确认序号有效。 2个重要的序号： seq：一方发送的随机生成的序列号。 ack：用于确认对方的序列号（ack = seq + 1）。 1、三次握手： （1）第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。 （2）第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求Server进入SYN_RCVD状态。 （3）第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。 2、四次挥手：（由于TCP连接时全双工的，因此

本文经过借鉴书籍资料、他人博客总结出的知识点，欢迎提问 序列号seq：占4个字节，用来标记数据段的顺序，TCP把连接中发送的所有数据字节都编上一个序号，第一个字节的编号由本地随机产生；给字节编上序号后，就给每一个报文段指派一个序号；序列号seq就是这个报文段中的第一个字节的数据编号。 确认号ack：占4个字节，期待收到对方下一个报文段的第一个数据字节的序号；序列号表示报文段携带数据的第一个字节的编号；而确认号指的是期望接收到下一个字节的编号；因此当前报文段最后一个字节的编号+1即为确认号。 确认ACK：占1位，仅当ACK=1时，确认号字段才有效。ACK=0时，确认号无效 同步SYN：连接建立时用于同步序号。当SYN=1，ACK=0时表示：这是一个连接请求报文段。若同意连接，则在响应报文段中使得SYN=1，ACK=1。因此，SYN=1表示这是一个连接请求，或连接接受报文。SYN这个标志位只有在TCP建产连接时才会被置1，握手完成后SYN标志位被置0。 终止FIN：用来释放一个连接。FIN=1表示：此报文段的发送方的数据已经发送完毕，并要求释放运输连接 PS：ACK、SYN和FIN这些大写的单词表示标志位，其值要么是1，要么是0；ack、seq小写的单词表示序号。 字段 含义 URG 紧急指针是否有效。为1，表示某一位需要被优先处理 ACK 确认号是否有效，一般置为1。 PSH

一、TCP传输的过程 1.建立连接并确认连接（三次握手） 过程： （1）客户端向服务端发出连接请求SYN，等待服务端响应 （2）服务端做出响应ACK和连接信号SYN （3）为防止数据丢失，客户端也要做出响应ACK，确认是否有效 2 .进行数据传输，发送数据包 数据传输总是从 客户端---》服务端，因此客户端和服务端不是固定的。 3.关闭连接（四次挥手）： 1.（客户端：终止等待1）客户端向服务端发起关闭连接的请求，不再发送数据了，但如果服务器发送数据，客户端还要接收 2.（服务端：关闭等待）服务端可能还有数据为传输完毕，所以还无法完成关闭。所以先响应客户端ACK，，表示收到关闭请求。客户端向服务器的方向释放，整个处于半关闭状态 3.（客户端：终止等待2）客户端收到服务器的确认请求后，客户端进入终止等待2，等待服务端发送连接释放报文 4.（服务端：最后确认）等服务器的数据传输工作完成，就把FIN信号（连接释放报文）发送给客户端，可能还会发送一些数据 5.(客户端：时间等待)客户端收到服务器的连接释放报文。发出确认ACK 6.（服务端：CLOSED）服务端收到客户端的确认，立即进入CLOSED状态 7.服务器结束TCP连接的时间比客户端早 来源： 51CTO 作者： 小西几 链接： https://blog.51cto.com/14234228/2462610

建立连接的三次握手以及四次挥手： MSL 是Maximum Segment Lifetime英文的缩写，中文可以译为“报文最大生存时间”，他是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。因为tcp报文 （segment）是ip数据报（datagram）的数据部分，具体称谓请参见《数据在网络各层中的称呼》一文 TIME_WAIT 根据TCP协议定义的3次握手断开连接规定,发起socket主动关闭的一方 socket将进入TIME_WAIT状态。TIME_WAIT状态将持续2个MSL(Max Segment Lifetime),在Windows下默认为4分钟，即240秒。TIME_WAIT状态下的socket不能被回收使用. 具体现象是对于一个处理大量短连接的服务器,如果是由服务器主动关闭客户端的连接，将导致服务器端存在大量的处于TIME_WAIT状态的socket， 甚至比处于Established状态下的socket多的多,严重影响服务器的处理能力，甚至耗尽可用的socket，停止服务。 为什么需要TIME_WAIT？TIME_WAIT是TCP协议用以保证被重新分配的socket不会受到之前残留的延迟重发报文影响的机制,是必要的逻辑保证。 和TIME_WAIT状态有关的系统参数有一般由3个，本厂设置如下： net.ipv4.tcp_tw_recycle = 1 net

TCP连接释放的过程叫做挥手，挥手需要在客户和服务器之间交换四个TCP报文段。 下图是四报文挥手释放TCP连接的过程： 数据传输结束后，通信的双方都可释放连接。现在A和B都处于ESTABLISHED状态。 结合 情侣分手 来演示一下四报文挥手（A是男方，B是女方）： A的应用进程先向其TCP发出释放报文段，并停止再发送数据，主动关闭TCP连接。A把连接释放报文段首部的终止控制位FIN置1，其序号seq=u,它等于前面已传送过的数据的最后一个字节的序号加1。这时A进入FIN-WAIT-1(终止等待1）状态，等待B的确认。请注意，TCP规定，FIN报文段即使不携带数据，它也消耗掉一个序号。 （ 某一天男朋友 (A) 向你 (B) 微信发消息单方面提出分手 ） B收到连接释放报文段后即发出确认，确认号是ack=u+1,而这个报文段自己的序号是v，等于B前面已传送过的数据的最后一个字节的序号加1。然后B进入CLOSE-WAIT(关闭等待)状态。TCP服务器进程这时应通知高层应用进程，因而从A到B这个方向的连接就释放了，这时的TCP连接处于半关闭状态，即A已经没有数据要发送了，但B若发送数据，A仍要接收。也就是说，从B到A这个方向的连接并未关闭，这个状态可能会持续一段时间。 A收到来自B的确认后，就进入FIN-WAIT-2（终止等待2）状态，等待B发出的连接释放报文段。 （接着你 (B)

上文链接： 详解TCP连接的“三次握手”与“四次挥手”(上) 四、TCP的四次挥手（Four-Way Wavehand） 0.前言 对于"三次握手"我们耳熟能详，因为其相对的简单。但是，我们却不常听见“四次挥手”，就算听过也未必能详细地说明白它的具体过程。下面就为大家详尽，直观，完整地介绍“四次挥手”的过程。 1.“四次挥手”的详解 所谓的四次挥手即TCP连接的释放(解除)。连接的释放必须是一方主动释放，另一方被动释放。以下为客户端主动发起释放连接的图解： 挥手之前主动释放连接的客户端结束ESTABLISHED阶段。随后开始“四次挥手”： （1） 首先客户端 想要释放连接 ，向服务器端发送一段TCP报文，其中： 标记位 为FIN，表示“请求释放连接“； 序号 为Seq=U； 随后客户端进入FIN-WAIT-1阶段，即半关闭阶段。并且停止在客户端到服务器端方向上发送数据，但是客户端仍然能接收从服务器端传输过来的数据。 注意： 这里不发送的是正常连接时传输的数据(非确认报文)，而不是一切数据，所以客户端仍然能发送ACK确认报文。 （2） 服务器端接收到从客户端发出的TCP报文之后， 确认了客户端想要释放连接 ，随后服务器端结束ESTABLISHED阶段，进入CLOSE-WAIT阶段（半关闭状态）并返回一段TCP报文，其中： 标记位 为ACK，表示“接收到客户端发送的释放连接的请求”；