简介
本篇读完需要15分钟,读完能了解:
1. TCP3次握手流程
2. 为什么要三次握手
3. 三次握手的问题
4. DDNS的预防等
TCP-3次握手小记是TCP系列第一篇,后续会出,TCP挥手,拥塞机制,滑动窗口等
详情见:
目录
握手流程
握手示意图
Tips
1. SYN和ACK的含义
TCP包有SYN标志位和ACK标志位,SYN=1表示这是一个SYN包,ACK=1表示这是一个ACK包，SYN&ACK是两个标志位均为1。
2. seq和ack的含义:
seq=x 表示包序列号为x,当一个包发送seq=x的时候,接受方的ACK包通常会回一个ack=x+1,
表示期望下个包seq=x+1
3. 出现服务端seq=y,客户端seq=x原因:
双方的发送方均会初始化随机一个序列号,各自维护。
4. 状态变化:
a. 客户端发送SYN 后变成 SYN-SENT
b. 服务端监听SYN后发送SYN&ACK变成 SYN-RECV
c. 客户端接受ACK变成ESTABLISHED,同时发送ACK
d. 服务端接受ACK变成ESTABLISHED
2次握手有什么问题
2次握手正向流程示意
2次握手异常状况示意
Tips
两次握手有什么问题
1. 【客户端】发送第一个连接请求报文x，因为某种原因阻塞了。（第1步）
2. x阻塞后超时，【客户端】重新发送连接请求报文y,顺利到达【服务端】….成功建立TCP连接发送完数据，释放了。（2-6步）
3. x在上述TCP连接释放后到达【服务端】后，【服务端】发送同意连接报文给【客户端】后(第二次握手)，就认为重新建立了TCP连接，一直等待【客户端】发送数据，造成【服务端】资源浪费。(7-9步)三次握手解决思路：
第7步ACK到达客户端后，【服务端】需要等【客户端】的确认连接(第三次握手)后才认为建立TCP连接。
而此时，因为【客户端】不需要连接了，所以在接收到【服务端】的同意连接报文后舍弃，不会发送确认连接(第三次握手)。
B在一定时间内没有接收到确认连接，就不会认为连接建立，因此不会造成B资源浪费。
3次握手异常&3次握手攻击
3次握手异常&3次握手攻击示意
Tips
1) SYN Flood攻击正是利用了TCP连接的三次握手，假设一个用户向服务器发送了SYN报文后突然死机或掉线，那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的(第三次握手无法完成)，这种情况下服务器端一般会重试(再次发送SYN+ACK给客户端)并等待一段时间后丢弃这个未完成的连接，这段时间的长度我们称为SYN Timeout，一般来说这个时间是分钟的数量级(大约为30秒-2分钟)；一个用户出现异常导致服务器的一个线程等待1分钟并不会对服务器端造成什么大的影响，但如果有大量的等待丢失的情况发生，服务器端将为了维护一个非常大的半连接请求而消耗非常多的资源
2) 服务端在等待客户端回复ACK的过程中超时了,那么服务端会向客户端发送一个RTS报文段并进入关闭状态
即：并不等待A第三次握手的ACK包重传，直接关闭连接请求。 这也是为了减少SYN攻击的影响。
3次握手攻击预防措施
SYN攻击属于DOS攻击的一种,它利用TCP协议缺陷,通过发送大量的半连接请求,耗费服务器CPU和内存资源。
目前对于暴露的IP没有完美解决方案。
- 思路上先是隐藏IP,比如应用游戏上的游戏盾,CDN网络等。
- 对于IP的防护当然也有
- 减少系统SYN等待时间（只能缓解攻击，同时会导致有些网络不好的Client体验更差）
- 对攻击源地址进行过滤拉黑（依赖防火墙）
- 修改系统SYN-back-log上限（TCP 协议栈中的半连接队列长度,只能缓解攻击,不真正解决问题）
- 减少SYN-ACK数据包的重发次数（可以缓解攻击）
- 设置SYN-cookies （返回特定序列号,可以较好缓解攻击）