-
Source Port / Destination Port:这个就是客户端口(源端口)和服务器端口(目的端口). 端口就是用来区别主机中的不同进程,通过结合源IP和目的IP结合,得出唯一的TCP连接。
-
Sequence Number(seqNumber): 一般由 客户端发送,用来表示报文段中第一个数据字节在数据流中的序号,主要用来解决网络包乱序的问题。
-
Acknowledgment Number(ACK): 即就是用来存放客户端发来的seqNumber的下一个信号(seqNumber+1). 只有当 TCP flags中的ACK为1时才有效. 主要是用来解决不丢包的问题。
-
TCP flags: TCP中有6个首部,用来控制TCP连接的状态.取值为0,1.这6个有:URG,ACK,PSH,RST,SYN,FIN.
-
URG 当为1时,用来保证TCP连接不被中断, 并且将该次TCP内容数据的紧急程度提升(就是告诉电脑,你丫赶快把这个给resolve了)
-
ACK 通常是服务器端返回的。 用来表示应答是否有效。 1为有效,0为无效
-
PSH 表示,当数据包得到后,立马给应用程序使用(PUSH到最顶端)
-
RST 用来确保TCP连接的安全。 该flag用来表示 一个连接复位的请求。 如果发生错误连接,则reset一次,重新连。当然也可以用来拒绝非法数据包。
-
SYN 同步的意思,通常是由客户端发送,用来建立连接的。第一次握手时: SYN:1 , ACK:0. 第二次握手时: SYN:1 ACK:1
-
FIN 用来表示是否结束该次TCP连接。 通常当你的数据发送完后,会自动带上FIN 然后断开连接
-
TCP 3次握手
-
第一次握手. 客户端向服务器发送一个SYN包,并且添加上seqNumber(假设为x),然后进入SYN_SEND状态,并且等待服务器的确认。
-
第二次握手: 服务器接受SYN包,并且进行确认,如果该请求有效,则将TCP flags中的ACK 标志位置1, 然后将AckNumber置为(seqNumber+1),并且再添加上自己的seqNumber(y), 完成后,返回给客户端.服务器进入SYN_RECV状态.(这里服务端是发送SYN+ACK包)
-
第三次握手 客户端接受ACK+SYN报文后,获取到服务器发送seqNumber(y), 并且 将新头部的AckNumber变为(y+1).然后发送给服务器,完成TCP3次连接。此时服务器和客户端都进入ESTABLISHED状态.
回答一下这个比较尴尬的问题,为什么只有3次握手,而不是4次,或者2次?
很简单呀,因为3次就够了,干嘛用4次。23333. 举个例子吧,假如是2次的话, 可能会出现这样一个情况。
-
当客户端发送一次请求A后,但是A在网络延迟了很久, 接着客户端又发送了一次B,但是此时A已经无效了。 接着服务器相应了B,并返回TCP连接头,建立连接(这里就2次哈)。 然后,A 历经千山万水终于到服务器了, 服务器一看有请求来了,则接受,由于一开始A带着的TCP格式都是正确的,那么服务器,理所应当的也返回成功连接的flag,但是,此时客户端已经判断该次请求无效,废弃了。 然后服务器,就这么一直挂着(浪费资源),造成的一个问题是,md, 这个锅是谁的? 所以,为了保险起见,再补充一次连接就可以了。所以3次是最合适的。在Chinese中,以3为起称为多,如果你用4,5,6,7,8...次的话,这不更浪费吗?
2.1、SYN Flood 攻击
SYN- Flood攻击是当前网络上最为常见的DDoS攻击,也是最为经典的拒绝服务攻击,它就是利用了TCP协议实现上的一个缺陷,通过向网络服务所在端口发送大量 的伪造源地址的攻击报文,就可能造成目标服务器中的半开连接队列被占满,从而阻止其他合法用户进行访问。这种攻击早在1996年就被发现,但至今仍然显示 出强大的生命力。很多操作系统,甚至防火墙、路由器都无法有效地防御这种攻击,而且由于它可以方便地伪造源地址,追查起来非常困难。它的数据包特征通常 是,源发送了大量的SYN包,并且缺少三次握手的最后一步握手ACK回复。
原理:攻击者首先伪造地址对 服务器发起SYN请求,服务器回应(SYN+ACK)包,而真实的IP会认为,我没有发送请求,不作回应。服务 器没有收到回应,这样的话,服务器不知 道(SYN+ACK)是否发送成功,默认情况下会重试5次(tcp_syn_retries)。这样的话,对于服务器的内存,带宽都有很大的消耗。攻击者 如果处于公网,可以伪造IP的话,对于服务器就很难根据IP来判断攻击者,给防护带来很大的困难。
2.2、SYN Flood 防护措施
2.2.1. 无效连接监视释放
这种方法不停的监视系统中半开连接和不活动连接,当达到一定阈值时拆除这些连接,释放系统资源。这种绝对公平的方法往往也会将正常的连接的请求也会被释放掉,”伤敌一千,自损八百“
2.2.2. 延缓TCB分配方法
SYN Flood关键是利用了,SYN数据报文一到,系统立即分配TCB资源,从而占用了系统资源,因此有俩种技术来解决这一问题
Syn Cache技术
这种技术在收到SYN时不急着去分配TCB,而是先回应一个ACK报文,并在一个专用的HASH表中(Cache)中保存这种半开连接,直到收到正确的ACK报文再去分配TCB
Syn Cookie技术
Syn Cookie技术则完全不使用任何存储资源,它使用一种特殊的算法生成Sequence Number,这种算法考虑到了对方的IP、端口、己方IP、端口的固定信息,以及对方无法知道而己方比较固定的一些信息,如MSS、时间等,在收到对方 的ACK报文后,重新计算一遍,看其是否与对方回应报文中的(Sequence Number-1)相同,从而决定是否分配TCB资源
2.2.3. 使用SYN Proxy防火墙
原理:对试图穿越的SYN请求进行验证之后才放行
TCP4次挥手
-
第一次挥手: A机感觉此时如果keep-alive比较浪费资源,则他提出了分手的请求。设置SeqNumber和AckNumber之后,向B机发送FIN包, 表示我这已经没有数据给你了。然后A机进入FIN_WAIT_1状态
-
第二次挥手:B机收到了A机的FIN包,已经知道了A机没有数据再发送了。此时B机会给A机发送一个ACK包,并且将AckNumber变为 A机传输来的SeqNumber+1. 当A机接受到之后,则变为FIN_WAIT_2状态。表示已经得到B机的许可,可以进行关闭操作。不过此时,B机还是可以向A机发送请求的。
-
第三次挥手 B机向A机发送FIN包,请求关闭,相当于告诉A机,我这里也没有你要的数据了。然后B机进入CLOSE_WAIT状态.(这里还需要带上SeqNumber,大家看图说话就可以了)
-
第四次挥手 A机接收到B机的FIN包之后,然后同样,发送一个ACK包给B机。 B机接受到之后,就断开了。 而A机 会等待2MSL之后,如果没有回复,确保服务器端确实是关闭了。然后A机也可以关闭连接。A,B都进入了CLOSE状态.
常见问题:为什么连接的时候是三次握手,关闭的时候却是四次握手?
因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,”你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。
经历状态:
Client端所经历的状态
Server端所经历的状态
各种状态解析
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看到。(主动方)
FIN_WAIT_2:上面已经详细解释了这种状态,实际上FIN_WAIT_2状态下的SOCKET,表示半连接,也即有一方要求close连接,但另外一方告诉对方,我暂时还有点数据需要传送给你(ACK信息),稍后再关闭连接。(主动方)
TIME_WAIT: 表示收到了对方的FIN报文,并发送出了ACK报文,就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下,收到了对方同时带FIN标志和ACK标志的报文时,可以直接进入到TIME_WAIT状态,而无须经过FIN_WAIT_2状态。(主动方)
CLOSING(比较少见): 这种状态比较特殊,实际情况中应该是很少见,属于一种比较罕见的例外状态。正常情况下,当你发送FIN报文后,按理来说是应该先收到(或同时收到)对方的 ACK报文,再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后,并没有收到对方的ACK报文,反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢?其实细想一下,也不难得出结论:那就是如果双方几乎在同时close一个SOCKET的话,那么就出现了双方同时发送FIN报文的情况,也即会出现CLOSING状态,表示双方都正在关闭SOCKET连接。
CLOSE_WAIT: 这种状态的含义其实是表示在等待关闭。怎么理解呢?当对方close一个SOCKET后发送FIN报文给自己,你系统毫无疑问地会回应一个ACK报文给对方,此时则进入到CLOSE_WAIT状态。接下来呢,实际上你真正需要考虑的事情是查看你是否还有数据发送给对方,如果没有的话,那么你也就可以close这个SOCKET,发送FIN报文给对方,也即关闭连接。所以你在CLOSE_WAIT状态下,需要完成的事情是等待你去关闭连接。(被动方)
LAST_ACK: 这个状态还是比较容易好理解的,它是被动关闭一方在发送FIN报文后,最后等待对方的ACK报文。当收到ACK报文后,也即可以进入到CLOSED可用状态了。(被动方)
CLOSED: 表示连接中断。
问题:为什么存在TIME_WAIT状态?
答:1、可靠的终止TCP连接
如果服务器发送的FIN保温丢失,那么服务器会重发结束报文段,因此客户端需要停留在某个状态以处理重复收到的结束报文段。否则,客户端会以复位报文段回复服务器,服务器会认为这是一个错误,因为它想要收到一个确认报文段。
2.保证让迟来的TCP报文段有足够的时间被识别并丢弃
当连接处于TIME_WAIT状态,无法立即使用该连接占用的接口重新建立连接。假如说不存在TIME_WAIT状态,应用程序可以立即建立一个和刚关闭的连接相似的连接,新连接可能会接收到属于原来连接的报文。