一、基础概念
1、啥是TCP?
它是面向连接的一种协议,任何数据发送之前都需要建立连接。
2、TCP/IP协议的四层中那一层?
TCP位于运输层,详见下图
3、TCP协议的状态机有哪些?
在链接建立和断开不同阶段都有不同的状态,这些状态想必大家也都耳熟能详了,具体可以参考下图。
二、三次握手和四次挥手
1、TCP状态如何变的?
连接时的三次握手:
第一次握手:
客户端给服务器发送一个SYN段(在 TCP 标头中 SYN 位字段为 1 的 TCP/IP 数据包), 该段中也包含客户端的初始序列号(Sequence number = J),客户端TCP状态为SYN_SENT。
第二次握手:
服务器返回客户端 SYN +ACK 段(在 TCP 标头中SYN和ACK位字段都为 1 的 TCP/IP 数据包), 该段中包含服务器的初始序列号(Sequence number = K);同时使 Acknowledgment number = J + 1来表示确认已收到客户端的 SYN段(Sequence number = J),服务端TCP状态为SYN_RCVD。
第三次握手:
客户端给服务器响应一个ACK段(在 TCP 标头中 ACK 位字段为 1 的 TCP/IP 数据包), 该段中使 Acknowledgment number = K + 1来表示确认已收到服务器的 SYN段(Sequence number = K)。双方TCP进入ESTABLISHED状态。
关闭时的四次挥手:
第一次挥手:
客户端发出释放FIN=1,自己序列号seq=u,进入FIN-WAIT-1状态。
第二次挥手:
服务器收到客户端的后,发出ACK=1确认标志和客户端的确认号ack=u+1,自己的序列号seq=v,进入CLOSE-WAIT状态。
第三次挥手:
客户端收到服务器确认结果后,进入FIN-WAIT-2状态。此时服务器发送释放FIN=1信号,确认标志ACK=1,确认序号ack=u+1,自己序号seq=w,服务器进入LAST-ACK(最后确认态)。
第四次挥手:
客户端收到回复后,发送确认ACK=1,ack=w+1,自己的seq=u+1,客户端进入TIME-WAIT(时间等待)。客户端经过2个最长报文段寿命后,客户端CLOSE;服务器收到确认后,立刻进入CLOSE状态。
2、子概念
SYN:
是同步的缩写,SYN 段是发送到另一台计算机的 TCP 数据包,请求在它们之间建立连接。
ACK:
是“确认”的缩写。 ACK 数据包是任何确认收到一条消息或一系列数据包的 TCP 数据包。
FIN:
结束标志,用于释放连接,为1表示关闭本方数据流。
三、常见TCP的一些问题
1、为什么建立连接是三次握手,关闭连接确是四次挥手?
1)三次握手时,服务器同时把ACK和SYN放在一起发送给了客户端。
2)四次挥手时,当收到客户端的 FIN 报文时,仅仅表示对方不再发送数据了但是还能接收数据,所以服务器只能先回复一个ACK报文,告诉Client端,"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。所以关闭连接时多了一步服务侧的挥手。
2、握手时两次为何不行?
为了服务侧确认客户端的接收能力正常。
3、什么是连接队列?
全连接队列
当客户端返回ACK, 服务端接收后,三次握手完成。这个时候连接等待被具体的应用取走,在被取走之前,它会被推入另外一个 TCP 维护的队列,也就是全连接队列(Accept Queue) 。
半连接队列
当客户端发送SYN到服务端,服务端收到以后回复ACK和SYN,状态由LISTEN变为SYN_RCVD,此时这个连接就被推入了SYN队列 ,也就是半连接队列 。
4、关于SYN Flood攻击
是指,恶意估计者给服务器发送一个SYN后,直接下线,服务器侧则需要默认等63s才会断开连接,这样,攻击者就可以把服务器的syn连接(半连接)的队列耗尽,让正常的连接请求不能处理。
Linux下tcp_syncookies的参数可以应对这个事——当SYN队列满了后,TCP会通过源地址端口、目标地址端口和时间戳打造出一个特别的Sequence Number发回去(又叫cookie),如果是攻击者则不会有响应,如果是正常连接,则会把这个 SYN Cookie发回来,然后服务端可以通过cookie建连接(即使你不在SYN队列中)。请注意,请先千万别用tcp_syncookies来处理正常的大负载的连接的情况。因为,synccookies是妥协版的TCP协议,并不严谨。对于正常的请求,你应该调整三个TCP参数可供你选择,第一个是:tcp_synack_retries 可以用他来减少重试次数;第二个是:tcp_max_syn_backlog,可以增大SYN连接数;第三个是:tcp_abort_on_overflow 处理不过来干脆就直接拒绝连接了。
5、关于TIME_WAIT数量太多
在大并发的短链接下,TIME_WAIT 就会太多,也会消耗很多系统资源,如果客户端的并发量持续很高,此时部分客户端就会显示连接不上。
如何尽量处理TIMEWAIT过多?
1)长连接 对于反向代理和应用服务器,最好是要配置成支持keepalive长连接,否则在系统并发增加时会导致一系列的连接问题。对于nginx+tomcat长连接的配置前面有一些介绍可以参考,其它服务器一般也是提供支持长连接配置的,设置后建议抓包测试验证。 一般来说长连接设置正确了TIME_WAIT数量不会暴涨,但是长连接最大请求数也是有效的,但如果应用的处理速度很快导致TIME_WAIT的产生的速度远快于TIME_WAIT的消耗速度时系统就会累计TIME_WAIT状态连接。这时候可能就要修改一些系统配置了。
2)ip_conntrack 用于跟踪TCP连接。一旦激活了此模块,就能在系统参数里发现很多用来控制网络连接状态超时的设置,其中自然也包括TIME_WAIT,默认ip_conntrack_max最大为65536,可以将其设置得更大一些。一般不建议此模块,如果系统安装使用iptable会启动该模块。
3)tcp_tw_recycle 在网上搜索TIME_WAIT问题的解决方法,大多都会提到这个参数,不过官方网站上不建议开启这个参数,原因是会导致一些安全问题。例如,当多个客户端通过NAT方式联网并与服务端交互时,服务端看到的是同一个IP,由于这些客户端的时间戳可能存在差异,所以从服务端的视角看,便可能出现时间戳错乱的现象,进而直接导致时间戳小的数据包被丢弃。
4)tcp_tw_reuse 当创建新连接的时候,如果可能的话会考虑复用相应的TIME_WAIT连接。官方文档里提到的是如果从协议视角看它是安全的,那么就可以使用。这个很难判定这个参数是否应该开启,不到万不得已的时候,即使我们要开启这个参数复用连接,也应该在连接的发起方使用,而不能在被连接方使用。
PS:tcp_tw_recycle和tcp_tw_reuse,非极端情况不建议使用这两参数,打开这两个参数会有比较大的坑——后期可能会让TCP连接出一些诡异的问题