TCP中的三次握手和四次挥手
TCP中的连接和断开可以说是在面试中经常被问到的问题之一,正好有空就总结一下,首先回顾一下TCP的相关知识点
1. TCP的基础知识
1.1 TCP的基本概念
我们知道TCP是运输层的面向连接的可靠的传输协议。面向连接的,指的就是在两个进程发送数据之前,必须先相互“握手”,确保两进程可以进行连接。并且这个传输是点对点的,即一个TCP连接中只有一个发送方和接收方;可靠的,指的是在任何网络情况下,在TCP传输中数据都将完整的发送到接收方。
1.2 TCP的报文段结构
-
源端口和目的端口:和UDP一样用于多路复用/分解来自或送到上一层
-
序号:一个报文段的序号是整个传送的字节流序列,而不是该报文段的序列
-
确认号:主机正在等待的数据的下一个字节序号
-
数据偏移:指TCP首部的长度,可变。默认长度为20字节
-
窗口:用于流量控制,用于指示接收方愿意接受的字节数量
-
标志字段:
- ACK:当该位为1时,确认号有效
- RST:该位为1时,表示TCP连接中出现异常必须强制断开连接
- SYC:该位为1时,开始建立连接,并且序号字段进行序列号初始值的设定
- FIN:该位为1时,断开连接,通信双方相互交换FIN位置为1的TCP段后断开连接
2. TCP连接
2.1 什么是连接(connection)和会话(Session)
连接是数据传输双方的契约,在设计上,连接是一种传输数据的行为,具体来说,数据收发双方的内存中都建立一个用于维护数据传输状态的对象,比如TCP 的连接组成包括一台主机上的缓存、变量和与进程连接的套接字,以及另外一台主机上的缓存、变量和与进程连接的套接字。(由端口号和IP地址组成)所以连接是网络行为状态的记录
而会话是应用的行为,比如说你在微信上给人发消息,打开应用聊天窗口和对方聊天是一个会话,但是连接只有在进行发消息、语音的时候连接才开启。其他不发消息和语音时,连接可能暂时断开,但是只要不关聊天窗口,会话时一直存在的。
总结而言,会话是应用层的概念,连接是传输层的概念,正是因为如此,在 TCP 连接的时候需要握手建立连接。
3. TCP连接建立
3.1 TCP 协议中的基本操作
也就是报文段的标志字段的含义和功能:
- SYN(Synchronization):请求同步,一个 Host 主动向另外一个 Host 发起连接。当 SYN=1,ACK=0 时,表示这是一个请求建立连接的报文段;当 SYN=1,ACK=1 时,表示对方同意建立连接
- PSH(Push): 数据推送,一个 Host 主动向另外一个 Host 发送数据
- FIN(Finish): 请求完成,一个 Host 主动断开请求,如果 FIN=1,表示数据已经发送完成,可以释放连接。
- ACK:表示前面的确认号字段是否有效。ACK=1 时表示有效。只有当 ACK=1 时,前面的确认号字段才有效。TCP 规定,连接建立后,ACK 必须为 1
- RST:表示是否重置连接。如果 RST=1,说明 TCP 连接出现了严重错误(如主机崩溃),必须释放连接,然后再重新建立连接。
如图,开始时,两个端口都是出于closed状态,当服务器端口变成listen时,监听端口,是否有数据传来。
-
第一步:客户端向服务端发送一个特殊的TCP报文段。客户端进入SYN_SENT状态这个报文段有以下特点:
- 不包含应用层数据,封装在一个IP数据报中发送给服务器
- SYN为1(此步是ACK唯一可为0处,其他时间均为1)
- 序号段有一个随机生成的初始序号(client_isn)
-
第二步:服务器端收到上步客户端的报文段后,同时为该TCP连接分配TCP缓存和变量,并向该客户发送允许连接的报文段。服务器进入SYN_RCVD状态,这个报文段特点有:
- 不包含应用层数据
- SYN为1,ACK为1
- 确认号段被置为client_isn + 1,序号段被置为server_isn
-
第三步:客户端收到上步服务端的报文段后,客户端为该连接分配缓存和变量,同时客户端向服务器端发送报文段,这个报文端特点有:
- 可以包含应用层数据
- SYN为0,ACK为1
- 确认号段被置为server_isn + 1
两端进入ESTABLISHED状态,连接建立
4. TCP连接断开
若客户端决定要关闭该连接(服务器端也可以发起关闭)
- 第一次:客户端发送带有FIN被置为1的报文段,进入FIN_WAIT_1状态,并等待一个来自服务器的带有确认的TCP报文段。
- 第二次:服务器端收到该报文段后,向客户端发送一个确认ACK报文段,进入CLOSE_WAIT状态。
- 第三次:服务器端处理完数据后向客户端发送FIN被置为1的报文段,进入LAST_ACK状态。
- 第四次:客户端收到服务器端的FIN报文段后,向服务器端发送一个确认ACK报文段,进入TIME_WAIT状态,服务器接收到该ACK报文段后关闭,客户端在经过2MSL(与具体实现有关,典型值是20s、1分钟或2分钟)等待后关闭。
5. 关于TCP连接的面试题
5.1 如何唯一确定一个TCP连接
可以通过四个变量来确定唯一的TCP连接:源地址、源端口、目标地址、目标端口来唯一确定一个TCP连接。其中源地址和目标地址的字段在IP头部,作用是通过IP协议发送报文给哪个主机;源端口和目标端口是在TCP首部,作用是通过TCP协议发送主机中的哪个进程。
5.2 UDP和TCP有什么区别
两者的区别
- UDP面向无连接,利用IP提供无连接的传输数据服务
- UDP可以支持一对多、一对一、多对多的交互通信
- UDP不保证可靠交付数据,传输过程中可能会丢包
- UDP首部只有固定的8字节;TCP首部最短20字节,能够变化
应用场景
- UDP用于包总量较少的通信,如DNS、SNMP;还有视频、音频等多媒体通信,以及广播通信等等
- TCP用于需要保证可靠性数据交付的场景,比如FTP、HTTP
5.3 为什么是三次握手?
为什么TCP连接建立过程中不是两次或者四次,三次就是最优解了吗?首先来看看两次握手建立连接会发生什么。
两次握手
如果连接过程是两次握手来建立,在理想的网络环境下是可以完成通信建立的,但是现实的网络环境很复杂,有时候会导致历史的报文段比新的报文段先到达服务器端,这时,如果没有第三次握手,就会造成无法同步序列号情况的发生。举个例子,客户端发送新SYN报文段的序号是100,网络环境中有旧的SYN报文端的序号是80,然而现在旧的先到达服务器端,那么服务器端则会返回一个确认号为81的SYN+ACK报文段,这个时候客户端接收到的报文段和预期报文段会不一致,就会造成无法同步序列号,达不到TCP可靠运输的效果,也会浪费资源。那么如果有第三次握手,这时客户端会反馈一个RST报文段,终止这次连接,等待新的SYN到来,这样保证数据的可靠性传输。
四次握手
四次握手可以对比四次挥手,客户端和服务器端都要分别发送SYN和ACK报文段,来表示之前的SYN报文已经被成功接收。
然而四次握手可以简化成三次,第二、三次可以优化成一次。所以三次是保证可靠性传输连接的最优解。
5.4 什么是SYN 泛洪?如何避免
SYN泛洪攻击通过发送大量的TCP SYN报文段,而不完成第三次握手的步骤。因为大量的SYN报文段的发送,服务器不断为这些半开连接分配资源,导致服务器的连接资源被消耗殆尽。
如何避免,现在有一种有效的防御系统,称为SYN cookie,它是这样工作的:
- 当服务器接收到一个SYN报文段时,它并不知道该报文段是来自一个合法用户还是SYN泛洪攻击的一部分。因此服务器不会为该报文段生成一个半开连接。相反,服务器会生成一个初始TCP序列号cookie值(由目的IP地址与端口号以及仅有该服务器知道的秘密数的一个复杂函数),并发送给客户端
- 如果客户是合法的,将会返回一个ACK报文段。而且当服务器收到该ACK后,需要验证该ACK是与前面发送的SYN相对应,并生成一个具有套接字的全开的连接。如果没有返回一个ACK报文段,则初始的SYN并没有对服务器产生危害,因为服务器也没为它分配任何资源。
5.5 为什么是四次挥手
四次挥手中双方发送了FIN报文段,所以在客户端发送FIN后,服务器端接收到后首先会回一个ACK应答报文,因为此时服务器端可能还有数据没发送完,所以在服务端数据处理完后,才发送FIN报文段给客户端表示现在可以关闭连接。正是因为这个等待过程,使得比三次握手多一次。
5.6 如果已经建立了连接,客户端出现故障了怎么办?
TCP有一个机制是保活机制:定义在一个时间段内,如果没有任何连接相关的活动,TCP保活机制则开始作用,每隔一个时间间隔会发送一个探测报文,该探测报文包含的数据很少,如果连续几个探测报文都没有得到响应,说明该TCP连接已经死亡。
客户端的故障也分为这几种:
- 对端系统正常回复探测报文,TCP保活时间重置,等待下一个保活时间到来,TCP连接正常运行。
- 对端程序崩溃并重启,此时可以对探测报完进行响应,但是没有连接的有效消息,序列不符合,最后会产生RST报文,这时连接被重置。
- 对端程序彻底崩溃,无法响应探测报,经过几次连续无响应后TCP会报告此连接已经死亡
5.7 为什么需要TIME_WAIT状态
首先要说明,只有主动发起关闭连接的一方才会有TIME_WAIT状态,那么为什么会有TIME_WAIT状态,这时因为在服务端关闭后,可能还会有其他的数据报未到达客户端,所以需要再等待一段时间。一般这个时间是2MSL时间,也就是报文段在两端传输的最大往返时间。
TIME_WAIT状态太多也会导致占用过多的端口资源,会导致无法创建新的连接
参考博客:
https://mp.weixin.qq.com/s/tH8RFmjrveOmgLvk9hmrkw