TCP-3次握手小记

简介

本篇读完需要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没有完美解决方案。

1. 思路上先是隐藏IP,比如应用游戏上的游戏盾,CDN网络等。
2. 对于IP的防护当然也有
   1.  减少系统SYN等待时间（只能缓解攻击，同时会导致有些网络不好的Client体验更差）
   2. 对攻击源地址进行过滤拉黑（依赖防火墙）
   3. 修改系统SYN-back-log上限（TCP 协议栈中的半连接队列长度,只能缓解攻击,不真正解决问题）
   4. 减少SYN-ACK数据包的重发次数（可以缓解攻击）
   5. 设置SYN-cookies （返回特定序列号,可以较好缓解攻击）