TCP/IP协议超详解及SYN攻击原理_tcp syn

TCP/IP协议超详解

首先我们先来说一下TCP/IP协议的握手和挥手。

TCP连接时5种状态解释

CLOSED    初始状态，表示TCP连接是“关闭着的”或“未打开的”
LISTEN  表示服务器端的某个SOCKET处于监听状态，可以接受客户端的连接
SYN_SENT  表示请求连接
SYN_RCVD  表示服务器接收到了来自客户端请求连接的SYN报文(极其短暂)
ESTABLISHED  表示TCP连接已经成功建立。

1
2
3
4
5
6

三次握手

（1）第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。

（2）第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。

（3）第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。

这样建立连接的大致流程就很清楚了，下面进行细讲：

SYN是什么，ACK是什么？
tcp标志位，有6种标示：
.
URG紧急位：URG=1时，标明此报文段中有紧急数据，是高优先级的数据，应尽快传送，不用再缓存里排队，配合紧急指针使用
.
ACK确认位：ACK=1时确认号有效，在连接建立后所有传送的报文都必须把ACK置为1
.
PSH推送位：PSH=1时，接收方尽快交付接收进程，不用等到缓存填满再向上交付
.
RST复位：RST=1时，表明tcp连接中出现了严重差错，必须释放连接，然后再重新建立传输连接
.
SYN同步位：SYN=1时，表明是一个连接请求/连接请求接收报文
.
FIN终止位：FIN=1时，表明此报文发送方数据已发完，要求释放连接

SYN就是请求连接，ACK就是确认连接。
首先client给server发送SYN=1 sql=J，SYN就表示请求连接.
那seq又是什么？
seq是序列号，这是为了连接以后传送数据用的，ack是对收到的数据包的确认，值是需要等待接收的数据包的序列号。
seq=J，J是一个随机数，client给server发送了SYN=1,和sql=J，SYN=1就表示请求连接，sql=J就表示当前我给你发送的消息序列号是J，那么下一次你给我回复的消息序列号必须是J+1。
当server收到了client的消息后，表示我收到了你的消息.
server给client发送： ACK=1，表示我确认收到了你的消息，SYN=1，表示 ：欸！老弟我也想和你建立连接. ack=J+1表示server要给client回复的消息的序列号，seq=k，就表示我的序列号是k,下次我要收的消息序列号就是K+1.
然后client收到了消息，首先检查收到的ACK是不是为1，为一就说明上次发送的消息服务器收到了，消息没有问题，然后再看ack是不是等于J+1,如果ack是等于J+1，都没问题就给ACK置为1，ack=k+1；发送给server，server接收到消息后，判断ACK=1,ack=k+1，seq=J+1然后建立连接。

这样讲可能好理解一点，但是实际上的原理可能更加复杂。下面简单说一下实际中的情况。这里就要说一下seq和ack机制，引入这两个机制的原因就是为了确认传输过程中有没有出现丢包。
seq和ack机制

seq和ack号存在于TCP报文段的首部中，seq是序号，ack是确认号，大小均为4字节（注意与大写的ACK不同，ACK是6个控制位之一，大小只有一位， 仅当 ACK=1 时ack字段才有效。建立 TCP 连接后，所有报文段都必须把 ACK 字段置为 1。）
.
seq：占 4 字节，序号范围[0，2^32-1]，序号增加到 2^32-1 后，下个序号又回到 0。TCP 是面向字节流的，通过 TCP 传送的字节流中的每个字节都按顺序编号，而报头中的序号字段值则指的是本报文段数据的第一个字节的序号。
ack：占 4 字节，期望收到对方下个报文段的第一个数据字节的序号。

下面我们通过一张图来分析seq和ack，这张图是使用Wireshark抓包过程中seq和ack的变化。现实中传输建立时候seq在第一次握手发送和第二次握手发送都是随机值，上面显示的seq确是从0开始的，这是因为Wireshark等抓包软件为了让seq和ack展示更直观，自动帮我们减去了初始顺序号 ISN。

前三行就是TCP三次握手阶段，第四行开始进行数据传输。
第四行client给server发送了一个725位的数据：

-------------725bit----------------
4: client -----------> server seq=1 ack=1

5：client<------------server seq=1 ack=726

第四行服务器收到的seq=1表示客户端是从1开始发的
第五行服务器返回接收到的信息seq=1表示，假如服务器端要给客户端发消息的话是从1开始发的。ack就是确认消息的，客户端收到了ack发现为726，然后和自己这边的seq对比，自己这边是从1开始发的，发了725位，所以下一次是从726开始发。ack又等于726这说明第四行client发送给server的725位数据发送成功，没有出现丢包情况

第六行server给client发送了1448位个数据

-------------1448bit----------------
6: client <----------- server seq=1 ack=726

7：client------------>server seq=726 ack=1449

第六行服务器给客户端发送了1448个位的数据， seq=1，表示服务器端从1开始发的，ack=726，同第五次解释。然后第七行客户端seq=725表示如果客户端需要再次发消息给服务器端是从726开始发的。ack=1149.说明客户端接收成功没有出现丢包。

为什么是三次握手？

第一次握手，客户端发送服务器端接收，说明客户端发送没有问题，服务器接收没有问题，第二次握手服务器端给客户端发送消息，说明服务器端发送没有问题。但此时并不能说明服务器端发送没有问题，客户端接收没有问题。所以第三次握手，客户端接收到服务器的消息，并发送一个消息给服务器。此时说明服务器的发送接收，客户端的发送接收都没有问题，连接建立！

TCP关闭连接时的几种状态

FIN_WAIT_1 ：这个状态得好好解释一下，其实FIN_WAIT_1 和FIN_WAIT_2 
两种状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别
是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动
关闭连接，向对方发送了FIN报文，此时该SOCKET进入到FIN_WAIT_1 状
态。而当对方回应ACK报文后，则进入到FIN_WAIT_2 状态。当然在实际的
正常情况下，无论对方处于任何种情况下，都应该马上回应ACK报文，所
以FIN_WAIT_1 状态一般是比较难见到的，而FIN_WAIT_2 状态有时仍可以
用netstat看到

CLOSE_WAIT ：表示正在等待关闭。怎么理解呢？当对方close()一个
SOCKET后发送FIN报文给自己，你的系统毫无疑问地将会回应一个ACK报文
给对方，此时TCP连接则进入到CLOSE_WAIT状态。接下来呢，你需要检查
自己是否还有数据要发送给对方，如果没有的话，那你也就可以close()
这个SOCKET并发送FIN报文给对方，即关闭自己到对方这个方向的连接。
有数据的话则看程序的策略，继续发送或丢弃。简单地说，当你处于
CLOSE_WAIT 状态下，需要完成的事情是等待你去关闭连接。

FIN_WAIT_2 ：上面已经解释了这种状态的由来，实际上FIN_WAIT_2状态
下的SOCKET表示半连接，即有一方调用close()主动要求关闭连接。注
意：FIN_WAIT_2 是没有超时的（不像TIME_WAIT 状态），这种状态下如
果对方不关闭（不配合完成4次挥手过程），那这个 FIN_WAIT_2 状态将
一直保持到系统重启，越来越多的FIN_WAIT_2 状态会导致内核crash。

LAST_ACK ：当被动关闭的一方在发送FIN报文后，等待对方的ACK报文的
时候，就处于LAST_ACK 状态。当收到对方的ACK报文后，也就可以进入到
CLOSED 可用状态了。

TIME_WAIT ：表示收到了对方的FIN报文，并发送出了ACK报文。 
TIME_WAIT状态下的TCP连接会等待2*MSL（Max Segment Lifetime，最大
分段生存期，指一个TCP报文在Internet上的最长生存时间。每个具体的
TCP协议实现都必须选择一个确定的MSL值，RFC 1122建议是2分钟，但BSD
传统实现采用了30秒，Linux可以cat 
/proc/sys/net/ipv4/tcp_fin_timeout看到本机的这个值），然后即可回
到CLOSED 可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标
志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过
FIN_WAIT_2状态。（这种情况应该就是四次挥手变成三次挥手的那种情
况）

**********************************************************
CLOSING ：这种状态在实际情况中应该很少见，属于一种比较罕见的例外
状态。正常情况下，当一方发送FIN报文后，按理来说是应该先收到（或
同时收到）对方的ACK报文，再收到对方的FIN报文。但是CLOSING 状态表
示一方发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方
的FIN报文。什么情况下会出现此种情况呢？那就是当双方几乎在同时
close()一个SOCKET的话，就出现了双方同时发送FIN报文的情况，这是就
会出现CLOSING 状态，表示双方都正在关闭SOCKET连接。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

（1）第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
.
（2）第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。
.
（3）第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
.
（4）第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。

为什么连接是三次握手，断开连接是4次握手呢？

可以注意到在TCP连接时候，在第二次握手的时候，对消息的确认ACK,ack和连接请求SYN是一起发送过去的。而在断开连接时候，服务器接收到了客户端的FIN报文后，先发送一个消息确认收到了，然后再发送一个FIN请求关闭服务器到客户端的连接。也就是断开连接时候，对于客户端的请求FIN的应答，ACK和FIN是分开发送的。之所以断开连接使用这种方法，是为了保证TCP连接的严谨性，再断开连接时候，当服务器接收到客户端发送来的FIN报文后，这说明客户端没有数据传输了，但是客户端还是可以接收数据，服务器端此时也不一定数据都发送完成。所以一般情况下ACK和FIN是分开发送的。

为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

一、保证TCP协议的全双工连接能够可靠关闭
二、保证这次连接的重复数据段从网络中消失
.
先说第一点，如果Client直接CLOSED了，那么由于IP协议的不可靠性或者是其它网络原因，导致Server没有收到Client最后回复的ACK。那么Server就会在超时之后继续发送FIN，此时由于Client已经CLOSED了，就找不到与重发的FIN对应的连接，最后Server就会收到RST而不是ACK，Server就会以为是连接错误把问题报告给高层。这样的情况虽然不会造成数据丢失，但是却导致TCP协议不符合可靠连接的要求。所以，Client不是直接进入CLOSED，而是要保持TIME_WAIT，当再次收到FIN的时候，能够保证对方收到ACK，最后正确的关闭连接。
.
再说第二点，如果Client直接CLOSED，然后又再向Server发起一个新连接，我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题，但是还是有特殊情况出现：假设新连接和已经关闭的老连接端口号是一样的，如果前一次连接的某些数据仍然滞留在网络中，这些延迟数据在建立新连接之后才到达Server，由于新连接和老连接的端口号是一样的，又因为TCP协议判断不同连接的依据是socket pair，于是，TCP协议就认为那个延迟的数据是属于新连接的，这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME_WAIT状态等待2倍MSL，这样可以保证本次连接的所有数据都从网络中消失。

SYN攻击原理

SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server回复确认包，并等待Client的确认，由于源地址是不存在的，因此，Server需要不断重发直至超时，这些伪造的SYN包将产时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络堵塞甚至系统瘫痪。SYN攻击时一种典型的DDOS攻击，检测SYN攻击的方式非常简单，即当Server上有大量半连接状态且源IP地址是随机的。也就是说服务器收到了大量虚拟IP的访问请求，服务器发送SYN,ACK后，但是收不到应答。
当Server上有大量半连接状态且源IP地址是随机的，则可以断定遭到SYN攻击了，使用如下命令可以让之现行：

#netstat -nap | grep SYN_RECV
1

如何避免 SYN攻击呢？

1、修改等待数
sysctl -w net.ipv4.tcp_max_syn_backlog=2048

2、启用syncookies
sysctl -w net.ipv4.tcp_syncookies=1

3、修改重试次数
sysctl -w net.ipv4.tcp_syn_retries = 0
重传次数设置为0，只要收不到客户端的响应，立即丢弃该连接，默认设置为5次

4、限制单IP并发数
使用iptables限制单个地址的并发连接数量：
iptables -t filter -A INPUT -p tcp --dport 80 --tcp-flags FIN,SYN,RST,ACK SYN -m connlimit --connlimit-above 10 --connlimit-mask 32 -j REJECT

5、限制C类子网并发数
使用iptables限制单个c类子网的并发链接数量：
iptables -t filter -A INPUT -p tcp --dport 80 --tcp-flags FIN,SYN,RST,ACK SYN -m connlimit --connlimit-above 10 --connlimit-mask 24 -j REJECT

6、限制单位时间内连接数
设置如下：
iptables -t filter -A INPUT -p tcp --dport 80 -m --state --syn -m recent --set
iptables -t filter -A INPUT -p tcp --dport 80 -m --state --syn -m recent --update --seconds 60 --hitcount 30 -j DROP

7、修改modprobe.conf
为了取得更好的效果，需要修改/etc/modprobe.conf
options ipt_recent ip_list_tot=1000 ip_pkt_list_tot=60
作用：记录10000个地址，每个地址60个包，ip_list_tot最大为8100,超过这个数值会导致iptables错误

8、限制单个地址最大连接数
iptables -I INPUT -p tcp --dport 80 -m connlimit --connlimit-above 50 -j D
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

–END–
以上内容参考了很多博客和资料，如有错误欢迎指正交流，感谢阅读。

参考文献：

TCP/IP协议详解
TCP可靠性的体现：seq和ack机制
TCPIP协议详解
TCP三次握手连接及seq和ack号的正确理解
TCP的seq和ack号计算方法
TCP三次握手中SYN，ACK，Seq含义
TCP11种状态
服务器遭到SYN攻击怎么办？如何防御SYN攻击？
让Linux系统防止syn攻击
《计算机网络》(第七版)
鸟哥的Linux私房菜-服务器架设篇