|
目录 一、连接管理正常情况下，TCP要经历“三次握手”建立连接，“四次挥手”断开连接。 TCP是有连接的，我们程序员编写客户端代码时，只要：socket = new Socket(String serverIP, int serverPort)，操作系统内核中就会自动和服务器建立连接，如图：
内核是怎么完成上述建立连接的过程的呢？——三次握手 而当要断开连接时，内核是怎么进行的呢？——四次挥手 二、三次握手1、何为三次握手？ 在建立连接的过程中，客户端一定是主动的一方，第一次交互就是客户端发起的，客户端首先要发送给服务器syn（同步报文段），然后服务器收到 syn 后，服务器就会发送ack（应答报文），然后服务器也要发送 syn 给客户端，客户端在收到 syn 后，就会返回一个 ack 给服务器，这是，三次握手的就完成了，如图： 上面画的好像是四次交互啊，那为啥称为三次握手呢？原因很简单，因为服务器给客户端发送的两个报文，可以合并成一个也就是ack+syn。为什么呢？想象一下，我们网购的时候，同时买了两份商品，商家是不是就会把这两份商品打包成一件商品，一起邮寄给我们，原因很简单，就是节省成本。网络中也是如此，反正ack和syn都要发到客户端中，那为什么不直接打包成一份呢？何况网络传输是要经过层层封装、分用，多一个次传输，传输成本就会增加好多，也就成了三次握手，如下图：
除了节约成本外，还有一个原因（也是能合并的前提）：ack和syn的触发时机是一样的，所以可以把这两个合并在一起。所以100%会合并！ 这里客户端在第一次交互中，虽然已经发送给服务器syn了，但是服务器是否要保存客户端的信息，还得观望观望，等这三次握手结束后，才能保存客户端的信息，确立连接，以及后续的通信。 这里的第一次交互，服务器收到客户端发来的syn，服务器会有两种情况：一、服务器同意，表示服务器也愿意和客户端建立连接；二、服务器不同意，这种情况很少出现，一般的原因就是服务器的负载极高，已经处理不过来了，客户端发来的请求处理不过来了，服务器完全无法响应，就没有下文了。 因为服务器是提供服务的，所以客户端发来的请求就一定会尽可能的处理，返回响应，所以一般都会同意客户端的建立请求。 握手的英译：handshake，是一个形象的比喻，握手只是打招呼，不用商讨具体的细节（业务逻辑，也就是应用程序 / 应用层要完成的事情）。其中这里就是简单的建立个连接而已，没有其他操作，还有三次握手也会有超时重传，三次握手结束后，超时重传也还存在。 syn的介绍：所谓的syn就是一个特殊的TCP数据报 syn是六个标志位的第五位，全称：synchronize ，表示同步的意思，如图：
表达的语义：我想和你建立连接。这里的 syn 虽然不带有应用层载荷，但也会带有 IP报头 / 以太网数据帧等等，更会有TCP报头，其中TCP报头中就包含了客户端自己的端口，IP报头中就包含了客户端的IP。 2、三次握手有何意义？（1）投石问路，确认客户端和服务器之间的通信通道是否“通畅” 比如地铁，地铁每天的第一趟不是载客的，而是先空车跑一趟，确认列车是否能正常运行到目的地，中间是否会有故障；而三次握手也是有类似的功能，通信前先确认通信链路是否是通畅的，有一种投石问路的效果。 （2）三次握手，也是在确定通信双方是否能发送信息和接受信息（接受和发送能力是否正常） 功能和上面画的图一样，如图：
第一次交互，客户端先给服务器发送syn建立请求，服务器收到了syn后，就知道客户端的发送能力是没有问题的；第二次交互，服务器发送ack+syn给客户端，当客户端收到后，客户端就知道了，自己的发送能力没有问题，服务器的接受和发送能力没有问题；第三次交互，客户端发送ack给服务器，服务器收到ack，服务器就能知道，自己的发送能力和接受能力都没有问题，还有客户端的接受能力也没有问题。 （3）建立连接的过程也会协商一些参数 因为网络通信是客户端和服务器两方的事情，所以就要配合，就要协商一些信息，保证其中的有些内容要一样。 TCP协议中也有很多参数是要客户端和服务器双方进行协商的，这些内容往往体现在 选项中，如图
其中有一个信息是挺关键的：TCP 的通信序号，如图：
也是因为网络传输中：后发先至（先发后至）的情况是普遍存在的，所以要引入序号这一概念。为了区分不同连接之间的数据包。 TCP在通信过程中，序号不是从 0 / 1开始的，而是选择一个比较大的数字，以这个数字开头来计算，即使是同一个客户端和服务器，每次连接，开始的序号都不同，原因：避免“前朝的件，斩本朝的官”。啥意思，如图： 所以，第二次连接，旧的数据应该丢弃。而旧的数据包也能一眼就看出来，原因就是每次连接（就算是同一客户端和服务器的连接），每次开始的序号也会不同，就很容易区别新旧数据包，把旧的数据包丢弃。 比如清朝的人，和我们现代人走在一起，想象清朝的人是“大粽子”，是不是一眼就能看出来他“不是人”（doge）。 三、四次挥手连接的过程，本质是在于服务器和客户端直接能保存对端的信息，是虚拟的连接，而这些信息是要放在数据结构中的。 断开连接的过程，本质就在于把服务器和客户端里保存的对端的信息，在数据结构上给释放掉，是逻辑上的断开连接，也是虚拟的。 其中四次挥手有点类似现实中的离婚的“和离”（和平分手），因为结婚领证后是具有法律效应的，如果要离婚，就会牵扯到财产纠纷问题，并不是其中的一方想离就立即能离的，一般要确认财产分配问题，双方的观念达成一致，才能离成，这种情况就是“和离”；而四次挥手呢，也并不是客户端和服务器的其中一端的单方面情况，想断开连接就断开连接，而是要遵循一些约定，经过四次挥手的过程后，才能断开连接。 那么四次挥手的过程是咋样的呢？（断开连接并不像建立连接，发送端一定是客户端，断开连接的发起者，可以是服务器，也可以是客户端）大概流程如图：
这里就涉及到四次交互，其中服务器这边，是不可以把ack和fin进行合并！！一起发送给客户端的，为什么呢，原因就是：服务器这边的ack和fin触发时机是不一样的！服务器接受到对端的fin时，就会立即发送ack给对端，而fin要经历一些程序员写的一些代码，一些逻辑后，才能执行服务器这边的代码： socket.close()，才会给对端发fin。当然也不是绝对的，如果服务器这边的如果断开连接的代码很少，fin和发送ack的触发时机几乎是同一时间，这时候服务器当然也可以把ack+fin合并到一起再发送给对端啦。所以，中间两次可以合并吗？我们称为 ：如合！ 上面这四次交互，就是四次挥手的过程了。 三次握手和四次挥手的相似之处和不同之处（1）相似之处传输顺序是相似的，都是各自给对端发生 syn / fin，对端返回ack，然后对端再发送 syn / fin , 当前端再返回回去ack。 三次握手交互顺序：syn / ack / syn / ack 四次挥手交互顺序：fin / ack / fin /ack （2）不同之处发送方的约定不同，三次握手的发送方（主动方）必须是客户端，四次挥手的发送方双方（主动方）都可以。 四、TCP的状态 下图是TCP状态转换的汇总： 这里主要介绍四个常用的状态。 建立连接：LISTEN状态：在Linux系统是LISTEN，Windows系统是LISTENING；表示服务器这边已经创建好ServerSocket了，并且已经好绑定IP地址和端口了，随时可以接收客户端发来的请求。 ESTABLISHED状态：表示三次握手的过程已经结束了，客户端和服务器之间已经建立好连接了。 断开连接：CLOSE_WAIT状态：表示被动方的这一端，收到了对端发来的fin后，会进入这个状态。 TIME_WAIT状态：表示主动方这一端，发送给对端fin后，对端也发送fin给我后，本端会处于这个状态，就是为了给最后一个ack的重传留有一定时间。 CMD控制平台观察上面介绍的状态首先，启动我们之前写的TCP代码，启动这服务器和客户端。 详细代码在：网络编程套接字(4)——Java套接字（TCP协议）-CSDN博客 其中服务器和客户端的端口和地址，如图：
LISTEN和ESTABLISHED只启动服务器
在CMD控制平台输入：netstat -ano | findstr 9090
服务器的端口号是9090，也就是服务器的地址，当前状态是LISTENING，表示服务器已经绑定好了IP地址和端口，随时可以和客户端建立连接。 大概流程如下图：
启动服务器和客户端
在CMD控制平台输入：netstat -ano | findstr 9090
客户端是第三行，服务器是第二行，其中它们的状态都变成了ESTABLISHED，表示服务器和客户端两端已经建立了联系。 CLOSE_WAIT和TIME_WAIT
在Windows操作系统，CLOSE_WAIT和TIME_WAIT是不容易被观察到的，用CMD控制平台看不到这个状态。 其中，这里TIME_WAIT是为了给最后一个ack重传留有一定的时间。其中，最后一个ack要发送给服务器，客户端和服务器之间，在数据结构中保存的对端信息才能被释放掉，如果最后一个ack丢包了，客户端这边也不知道是啥情况，就可以使用TIME_WAIT状态进行标记，如果ack丢包了，就等一定的时间，给客户端这边重传ack提供保障。 当然，这里也不是无休止的等，是有一定是时间限制的，最多等2MSL（MSL是一个系统内核的配置项，表示服务器和客户端之间消耗最多的时间，常见的设置值是2 min），这里如果等了2MSL，还没收到客户端发来的ack，也意味着客户端这边不可能会发ack过来了，再也不会重传了，就直接断开连接吧，丢弃一些在数据结构中的信息。 一般而言，对于服务器出现大量的CLOSE_WAIT状态，原因就是服务器没有正确关闭socket，导致四次挥手没有正确完成，这是应该BUG；只需要加上对应的close即可。 |
原文地址：https://blog.csdn.net/cool_tao6/article/details/136843088
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：https://www.msipo.com/article-651097.html 如若内容造成侵权/违法违规/事实不符，请联系MSIPO邮箱：3448751423@qq.com进行投诉反馈，一经查实，立即删除！
Copyright © 2024, msipo.com
