沈阳做网站的,做个网址多少钱,帝国CMS做的淘客网站,网站建设优缺点1#xff1a;TCP 三次握手过程是怎样的#xff1f; 客户端和服务端都处于 CLOSE 状态#xff0c;服务端主动监听某个端口#xff0c;处于 LISTEN 状态 第一次握手#xff1a;客户端带着序号和SYN为1#xff0c;把第一个 SYN 报文发送给服务端#xff0c;客户端处于 SYN-… 1TCP 三次握手过程是怎样的 客户端和服务端都处于 CLOSE 状态服务端主动监听某个端口处于 LISTEN 状态 第一次握手客户端带着序号和SYN为1把第一个 SYN 报文发送给服务端客户端处于 SYN-SENT 状态 第二次握手服务端收到客户端的 SYN 报文后服务物端带着序号和SYN和ACK为1把报文发送给客户端服务端处于 SYN-RCVD 状态 第三次握手客户端收到服务端报文后把带着ACK为1的报文发送给服务端这次报文可以携带客户到服务端的数据客户端处于 ESTABLISHED 状态 服务端收到客户端的应答报文后也进入 ESTABLISHED 状态 第三次握手是可以携带数据的前两次握手是不可以携带数据的 2如何在 Linux 系统中查看 TCP 状态 TCP 的连接状态查看在 Linux 可以通过 netstat -napt 命令查看 3为什么是三次握手不是两次、四次 三次握手才可以阻止重复历史连接的初始化主要原因 三次握手才可以同步双方的初始序列号序列号能够保证数据包不重复、不丢弃和按序传输。 三次握手才可以避免资源浪费 不使用「两次握手」和「四次握手」的原因 「两次握手」无法防止历史连接的建立会造成双方资源的浪费也无法可靠的同步双方序列号 「四次握手」三次握手就已经理论上最少可靠连接建立所以不需要使用更多的通信次数。 4为什么每次建立 TCP 连接时初始化的序列号都要求不一样呢 主要原因有两个方面 为了防止历史报文被下一个相同四元组的连接接收主要方面 为了安全性防止黑客伪造的相同序列号的 TCP 报文被对方接收 注意 每次初始化序列号不一样很大程度上能够避免历史报文被下一个相同四元组的连接接收注意是很大程度上并不是完全避免了因为序列号会有回绕的问题所以需要用时间戳的机制来判断历史报文 5初始序列号 ISN 是如何随机产生的 起始 ISN 是基于时钟的每 4 微秒 1转一圈要 4.55 个小时。 RFC793 提到初始化序列号 ISN 随机生成算法ISN M F(localhost, localport, remotehost, remoteport)。 M 是一个计时器这个计时器每隔 4 微秒加 1。 F 是一个 Hash 算法根据源 IP、目的 IP、源端口、目的端口生成一个随机数值。要保证 Hash 算法不能被外部轻易推算得出用 MD5 算法是一个比较好的选择。 可以看到随机数是会基于时钟计时器递增的基本不可能会随机成一样的初始化序列号。 6既然 IP 层会分片为什么 TCP 层还需要 MSS 呢 MTU一个网络包的最大长度以太网中一般为 1500 字节 MSS除去 IP 和 TCP 头部之后一个网络包所能容纳的 TCP 数据的最大长度 因为IP 层本身没有超时重传机制由传输层的 TCP 来负责超时和重传。那么当如果一个 IP 分片丢失整个 IP 报文的所有分片都得重传。 所以建立连接的时候通常要协商双方的 MSS 值进行重发时也是以 MSS 为单位不用重传所有的分片大大增加了重传的效率。 7第一次握手丢失了会发生什么 当客户端超时重传 3 次 SYN 报文后由于 tcp_syn_retries 为 3已达到最大重传次数于是再等待一段时间时间为上一次超时时间的 2 倍如果还是没能收到服务端的第二次握手SYN-ACK 报文那么客户端就会断开连接。 8第二次握手丢失了会发生什么 当客户端超时重传 1 次 SYN 报文后由于 tcp_syn_retries 为 1已达到最大重传次数于是再等待一段时间时间为上一次超时时间的 2 倍如果还是没能收到服务端的第二次握手SYN-ACK 报文那么客户端就会断开连接。 当服务端超时重传 2 次 SYN-ACK 报文后由于 tcp_synack_retries 为 2已达到最大重传次数于是再等待一段时间时间为上一次超时时间的 2 倍如果还是没能收到客户端的第三次握手ACK 报文那么服务端就会断开连接。 9第三次握手丢失了会发生什么 当服务端超时重传 2 次 SYN-ACK 报文后由于 tcp_synack_retries 为 2已达到最大重传次数于是再等待一段时间时间为上一次超时时间的 2 倍如果还是没能收到客户端的第三次握手ACK 报文那么服务端就会断开连接。 10什么是 SYN 攻击如何避免 SYN 攻击 在 TCP 三次握手的时候Linux 内核会维护两个队列分别是 半连接队列也称 SYN 队列 全连接队列也称 accept 队列 假设攻击者短时间伪造不同 IP 地址的 SYN 报文服务端每接收到一个 SYN 报文就进入SYN_RCVD 状态但服务端发送出去的 ACK SYN 报文无法得到未知 IP 主机的 ACK 应答久而久之就会占满服务端的半连接队列使得服务端不能为正常用户服务。 解决 调大 netdev_max_backlog当网卡接收数据包的速度大于内核处理的速度时会有一个队列保存这些数据包。控制该队列的最大值如下参数 net.core.netdev_max_backlog 10000 增大 TCP 半连接队列增大 net.ipv4.tcp_max_syn_backlog 增大 listen() 函数中的 backlog 增大 net.core.somaxconn 开启 tcp_syncookies开启 syncookies 功能就可以在不使用 SYN 半连接队列的情况下成功建立连接相当于绕过了 SYN 半连接来建立连接。 net.ipv4.tcp_syncookies 参数主要有以下三个值0 值表示关闭该功能1 值表示仅当 SYN 半连接队列放不下时再启用它2 值表示无条件开启功能 修改 echo 1 /proc/sys/net/ipv4/tcp_syncookies 减少SYNACK重传次数修改 echo 1 /proc/sys/net/ipv4/tcp_synack_retries
