一、连接管理
正常情况下,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
第一列是协议,第二列是本地地址,第三列是外部地址,第四列是状态,第五列是 PID。
其中,这里0.0.0.0是本机所有网络接口的地址,是本网络中的本机,也就是说,表示当前设备上所有可用的IP地址,也称为通配地址。而127.0.0.1是回环地址,是为了让本机能够实现自我测试和自我通信。
方括号是IPV6的地址。
服务器的端口号是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即可。