网站建设首选公司优搜云seo
TCP相关问题1
1.TCP主动断开连接方为什么需要等待2MSL
如上图所示:在被动链接方调用close，发送FIN时进入LAST_ACK状态，但未收到主动连接方的ack确认，需要被动连接方重新发送一个FIN，而为什么是2MSL，一般认为丢失ack在网络中生存的时间是1MSL，重传FIN也需要1MSL，所以需要等待2MSL时间。
2.SYN什么时候被丢弃？
-
TCP的半连接队列和全连接队列满了，造成SYN被丢弃
-
开启tcp_tw_recycle参数，并且在NAT环境下，造成SYN被丢弃
a.TCP中linux 内核维持两个队列，半连接队列和全连接队列
三次握手过程 ：
- 服务端收到客户端SYN请求请求后，内核会把该连接存储到半连接队列，并向客户端响应SYN+ACK。
- 接着客户端会返回ACK，服务端收到第三次握手的ACK后，内核会把连接从半连接队列(listen)移除。
- 然后创建新的完全连接，并将其添加到accept完全队列，等待进程调用accept函数时把连接取出来。
-
半连接队列满了：大量SYN同时道道服务端，导致SYN被丢弃，会造成SYN泛洪攻击。
-
解决方案：
1.增加半连接队列。
2.开启tcp_syncookies
3.减少syn+ack重传次数
-
-
全连接队列满了:在服务端并发处理大量请求，如果accept队列过小时或者应用程序accept不及时，会造成accept队列满了，这是之后的连接会被丢弃，这样会造成服务端请求数量上不去的问题。
-
解决方案：
1.调大accept队列最大长度，通过accept 的backlog参数以及samaconnect参数
2.检查系统或者程序代码为什么accept不及时。
-
b.开启tcp_tw_recycle参数，并且在NAT环境下，造成SYN被丢弃
2.前因
TCP四次挥手过程中主动断开方会有一个TIME_WAIT状态，这个状态会有2MSL等待时间变为CLOSE状态。
-
前因1：在linux操作系统中，TIME_WAIT等待时间2MSL为60s。主动断开方需要等待2MSL时间端口才能被释放。
-
前因2：客户端主动断开连接并且大量主动断开连接。客户端一直占用连接，2MSL时间内端口一直被占用，一般开启的端口号为32768~61000,资源有限。如果客户端发起大量连接，并且断开进入TIME_WAIT状态，端口被占用导致后面其他客户端无端口可用。
小结：TCP要解决当前没有端口可用，客户端还要建立连接，所以诞生了tcp_tw_recycle
-
前因3：
- tcp_tw_recycle,如果选项开启的话，允许处于TIME_WAIT状态的连接被快速回收。
- tcp_tw_reuse,如果选项开启的话，在调用connect函数时，如果内核选择到的端口已经被相同的四元组占用时，就会判断是否处于TIME_WAIT状态，如果状态处于TIME_WAIT，并且状态持续时间超过了1s，那么就会重用这个连接，然后可以正常使用这个端口了,只使用于连接发起方
-
前因4：开启了recycle和timestamp选项，触发PAWS机制（per-host的PAWS机制）
-
作用防止TCP中的序号发生绕回
使用tcp协议进行数据传输时，tcp都包含一个32位的序号，用于表示报文段中的数据在整个数据流中的位置，TCP序号的最大值为2^32,是一个无符号整数，到达最大值时序号会循环变为0，这个现象叫做"序号绕回"
-
-
经过同一NAT转换来自不同的client的数据流，在服务端看来是于同一host打交道
客户端用的NAT网关，不同客户端经过同一NAT之后，转换为同一个公网IP，在服务端看来好像跟同一个客户端打交道
-
虽然经过同一个NAT转化，但不同客户端各自携带自己的timestamp，经过NAT转换后无法保证数据包带的timestamp值严格递增。
-
当服务端的per-host PAWS机制被触发后，会丢弃timestamp值不符合递增条件的包。
例如：
a.当客户端A经过NAT网关和服务端建立TCP连接，然后服务端主动关闭并快速回收TIME_WAIT状态连接后，客户端B 也通过NAT和服务器建立连接，由于客户端A和B经过同一个NAT转换，所以相同的IP地址服务端认为是一个客户端发送过来的，客户端B发送的timestamp较小，由于服务端的PAWS机制，服务端会丢弃客户端B发送的较小timestap的SYN包
-
tcp_tw_recyle在linux4.12版本后，直接取消了这一参数。
mestap的SYN包
- tcp_tw_recyle在linux4.12版本后，直接取消了这一参数。
参考连接:https://www.bilibili.com/video/BV1Pw411U7TA?spm_id_from=333.788.videopod.sections&vd_source=4a32de7f18a719e139c5f65d7ba504d1