文章目录
一、TCP 连接管理
二、TCP 连接建立
三、TCP 连接建立 相关报文段 字段
四、SYN 洪泛攻击
五、TCP 连接释放
一、TCP 连接管理
TCP 传输数据过程 : 建立连接 -> 传输数据 -> 释放连接 ;
TCP 连接通信方式是 客户端 / 服务器 方式 , 主动发起连接的应用进程是 客户端 , 被动等待连接的应用进程是 服务器 ;
二、TCP 连接建立
TCP 连接建立过程 : 客户端 与 服务器 的 TCP 连接建立过程 ;
① 客户端 发送 连接请求报文段 , 该报文段 没有应用层数据 ;
SYN = 1 , 同步位 , 如果为 1 11 , 说明该位是连接请求 / 连接接收 报文 ; 本次的情况是 连接请求 ;
seq = x ( 随机 ) , 序号位 , 随机产生一个字节 , 确认号此时是无效的 , 客户端没有收到服务器发送的报文段 , 不知道期待获取什么序号的数据 ;
ACK = 0 , 确认位 , 连接还没有建立成功 , 此时是 0 00 , 之后连接建立成功后置位 1 11 ;
② 服务器端 收到 连接请求报文段 , 为 TCP 连接 分配 缓存和变量 , 向客户端返回 确认报文段 , 允许客户端连接 , 此时该报文段 也没有应用层数据 ;
SYN = 1 , 同步位 , 如果为 1 11 , 说明该位是连接请求 / 连接接收 报文 ; 本次的情况是 连接接收 ;
seq = y ( 随机 ) , 序号位 , 随机产生一个字节 , 确认号此时是无效的 , 客户端没有收到服务器发送的报文段 , 不知道期待获取什么序号的数据 ;
ACK = 1 , 确认位 , 连接建立成功后置位 1 11 ;
ack = x + 1 , 确认号 , 该 ack 与上面的 ACK 是配套使用的 ; 只有 ACK = 1 确认位为 1 时 , 确认号 ack 才生效 ;
③ 客户端 收到 服务器端 返回的 确认报文段 , 客户端为 TCP 连接分配缓存和变量 , 同时向 服务器端 返回 确认报文段 的 确认 , 并可以 携带实际传输的数据 ;
SYN = 0 , 同步位 , 说明该位 不是 连接请求 / 连接接收 报文 ;
seq =x+1 , 序号位 , 表明本次发送的数据的第一个字节的序号 ;
ACK = 1 , 确认位 , 连接建立成功后置位 1 11 ;
ack = y + 1 , 确认号 , 期望收到 服务器端 下一次 发送的序号 ; 该 ack 与上面的 ACK 是配套使用的 ; 只有 ACK = 1 确认位为 1 时 , 确认号 ack 才生效 ;
总结 :
SYN : 在开始的两个报文段为 1 11 , 这是建立连接的前两次握手 ; 等到真实传输数据时 , 该位 为 0 00 ;
ACK : 只在第一次握手时 为 0 00 , 此时还没有建立连接 , 之后服务器端接收后 , 知道连接建立成功了 , ACK 设置为 1 11 ;
序号位 : 随机值 , 客户端生成 发送的 随机序号位 x , 服务器端生成 发送的 随机序号位 y ;
确认号 : 对应上述 序号位 的是 确认号 , 客户端 生成的随机序号 x 是 服务器端 期待的接收的序号 确认号 , 服务器端 生成的 随机序号 y 是 客户端 期待接收的 序号 确认号 ;
三、TCP 连接建立 相关报文段 字段
上述涉及到的 TCP 报文的 四个字段 :
序号 seq : TCP 连接中 , 字节流中的 字节按照顺序编号 , 每个字节都有一个序号 , 本首部中的序号是本 TCP 报文 数据部分第一个字节的序号 ;
确认号 ack : 期望收到 对方 下一个报文段 第一个数据字节的序号 ; 序号为 100 100100 , 说明 99 9999 及之前的数据都已经收到 ;
同步位 SYN : SYN = 1 =1=1 时 , 表明该报文是一个 连接请求 / 连接接收 报文 ;
确认位 ACK : ACK = 1 = 1=1 时 , 确认号有效 , 连接建立后 , 所有的报文段的 ACK 都必须设置为 1 11 ;
上述 涉及到 TCP 报文内容 , 参考博客 【计算机网络】传输层 : TCP 协议 ( TCP 协议特点 | TCP 报文段首部格式 | TCP 报文段控制位 )
四、SYN 洪泛攻击
SYN 洪泛攻击 : 利用 TCP 连接的 三次握手 特性 ;
① 攻击者 伪装成客户端 , 向服务器端 发送 TCP 连接的第一个数据包 , SYN ;
② 服务器端 收到 第一个数据包 , 第一次握手完成 , 服务器返回 ACK , 但是 攻击者 客户端 不进行确认 ;
③ 此时服务器端 TCP 连接挂起 , 处于 半连接 状态 , 持续消耗服务器资源 ;
④ 消耗服务器资源 : 如果 攻击者 大量 发送 SYN 第一次握手数据 , 服务器消耗资源过多 导致宕机 ;
解决方案 : 采用 SYN Cookie 解决上述问题 ;
五、TCP 连接释放
TCP 连接释放 : 四次挥手 ;
① 客户端 : 客户端 发送 连 接释放报文段 , 停止发送数据 , 发起 TCP 连接关闭流程 ; 连接释放报文段 关键字段如下 :
FIN = 1 : 表明该报文发送完毕 , 释放连接 ;
seq = u : 序号位设置成 u
② 服务器端 : 返回 确认报文段 , 客户端收到该报文段后 ; 确认报文段 关键字段 如下 :
ACK = 1
seq = v : 服务器端生成的发送序号 ;
ack = u + 1 : 期待收到 客户端 发送的 u 之后的报文段 u + 1 ;
③ 服务器端 : 发送完毕 上面的 确认报文段后 , 发送 连接释放报文段 , 关闭 TCP 连接 ( 该链接时 客户端 -> 服务器端 方向的连接 ) ; 连接释放报文段 关键字段如下 :
FIN = 1
ACK = 1
seq = w : 服务器端 生成的序号 ;
ack = u + 1 : 该步骤 与 步骤 ② 中 , 没有收到客户端的报文 , 因此 ack 仍然保持 u + 1 不变 ;
④ 客户端 : 收到 服务器端 连接释放报文段 , 回复 确认报文段 , 等待 2MSL ( 最长报文寿命 ) 后 , 关闭 TCP 连接 ( 服务器 -> 客户端 方向连接 ) ; 确认报文段 格式 :
ACK = 1
seq = u + 1 : 第一次回收时是 u , 第四次挥手 时 , 是 u + 1 ;
ack = w + 1 : 服务器端发送的数据序号是 w , 本次期待收到下一次 w + 1
