北京做网络工程公司的网站,wordpress文章首字下沉,成都精品网站建设,外贸建站公司一、基础概念
1、啥是TCP#xff1f;
它是面向连接的一种协议#xff0c;任何数据发送之前都需要建立连接。
2、TCP/IP协议的四层中那一层#xff1f;
TCP位于运输层#xff0c;详见下图 3、TCP协议的状态机有哪些?
在链接建立和断开不同阶段都有不同的状态#xf…一、基础概念
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状态。
关闭时的四次挥手
第一次挥手
客户端发出释放FIN1自己序列号sequ进入FIN-WAIT-1状态。
第二次挥手
服务器收到客户端的后发出ACK1确认标志和客户端的确认号acku1自己的序列号seqv进入CLOSE-WAIT状态。
第三次挥手
客户端收到服务器确认结果后进入FIN-WAIT-2状态。此时服务器发送释放FIN1信号确认标志ACK1确认序号acku1自己序号seqw服务器进入LAST-ACK最后确认态。
第四次挥手
客户端收到回复后发送确认ACK1ackw1自己的sequ1客户端进入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长连接否则在系统并发增加时会导致一系列的连接问题。对于nginxtomcat长连接的配置前面有一些介绍可以参考,其它服务器一般也是提供支持长连接配置的设置后建议抓包测试验证。 一般来说长连接设置正确了TIME_WAIT数量不会暴涨但是长连接最大请求数也是有效的但如果应用的处理速度很快导致TIME_WAIT的产生的速度远快于TIME_WAIT的消耗速度时系统就会累计TIME_WAIT状态连接。这时候可能就要修改一些系统配置了。
2ip_conntrack 用于跟踪TCP连接。一旦激活了此模块就能在系统参数里发现很多用来控制网络连接状态超时的设置其中自然也包括TIME_WAIT默认ip_conntrack_max最大为65536可以将其设置得更大一些。一般不建议此模块如果系统安装使用iptable会启动该模块。
3tcp_tw_recycle 在网上搜索TIME_WAIT问题的解决方法大多都会提到这个参数不过官方网站上不建议开启这个参数原因是会导致一些安全问题。例如当多个客户端通过NAT方式联网并与服务端交互时服务端看到的是同一个IP由于这些客户端的时间戳可能存在差异所以从服务端的视角看便可能出现时间戳错乱的现象进而直接导致时间戳小的数据包被丢弃。
4tcp_tw_reuse 当创建新连接的时候如果可能的话会考虑复用相应的TIME_WAIT连接。官方文档里提到的是如果从协议视角看它是安全的那么就可以使用。这个很难判定这个参数是否应该开启不到万不得已的时候即使我们要开启这个参数复用连接也应该在连接的发起方使用而不能在被连接方使用。
PS:tcp_tw_recycle和tcp_tw_reuse非极端情况不建议使用这两参数打开这两个参数会有比较大的坑——后期可能会让TCP连接出一些诡异的问题
