我了解TCP的伟大论文 我写错了

‍ ‍ 使用TCP握手的TCP三次测试在这篇文章中进行了三次:

• 实验一:初步握手时,模拟TPCP SYN投放袋。
• 实验二:模拟TCCP第二次握手SYN和ACK投放袋。
• 实验三:模拟TCP第三次握手的ACK包。

这是一个很棒的读物, 有超过1000个字。但是,在对实验的第二次分析中,一位读者告诉我,我指的是一个问题。实验二,我的防火墙在客户方面,把所有数据包放在防护罩服务上,模仿第二次握手的丢失,首先向大家展示实验的图像,正如我所说,分析过程。数字中的红框声明是麻烦的,而且是正确的:第二次握手的SYN和第二次握手的ACK不会被重新设定为接收SYN包,因为第二次握手的ACK必须确认第三次握手,然后才能被重新设定为第二次握手。
我还解决了TCP三次握手模拟的异常现象。您想要复制我论文中描述的实验步骤 。坚持住,五千字车!

分析TCP, 三次握手 不寻常的战斗。

TCP握手三次, 相信每个人的背已经成熟, 你有没有考虑过以下三个异常点:

• TCP和SYN第一次交换了握手,SYN放下了袋子,会发生什么?
• TCP, 第二次握手, SYN, ACK, 袋子丢失了 会发生什么?
• 如果TCP第三次握手的ACK包放错地方了怎么办?

有些小男人可能会回答,“很简单,如果你把袋子丢了,就会重新传送。” 所以我会问你:

• 那会重传几次？
• ROTO过期后会怎样?
• 我怎样才能改变Linux的重复次数?
• ….

我不太确定 但我要用三个测试案例 来把你们召集到一起 调查这三种异常

实验场景

实验使用两台虚拟计算机,一台是服务器,另一台是客户,其关系如下:

实验环境

• 客户和服务是CentOS 6.5 Linux, Linux内核2.32 对不起,对不起,对不起,对不起,对不起,对不起,对不起,对不起,对不起,对不起,对不起,对不起
• Apache 网络服务、服务
• 客户客户

实验1:SYN落袋TCP初步握手

服务器网络断开后, 我立即对客户进行了曲线命令, 以复制 TCP 最初的握手 SYN 下降 :

以下是tcpdump 抓捕命令:

Curl 最终返回超时连接中的错误 :

从date返回时间, 您可以看到 Curl 在近一分钟后返回了一个错误。 选择 tcp_ sys_ timeout. pcap 文件以 Wiresark 开始分析, 并显示以下图表 :

在整个期间,SYN重复五次。

如上图所示,自SYN软件包启动以来,客户没有提供ACK,因此这一过程在一段时间内重复了五次,每次ROTO超时次数不同:

• 一秒钟后,首次时间将再次发送。
• 3秒后,第二次被再次传送
• 7秒后,第三次被再次传送
• 大约15秒,第四秒再次发送。
• 31秒后,第5次再次传送

现已发现,每次超过最大再传送次数,而客户不再发送SYN包时,RTO就会指数性地增加(两倍)。SYN在内核参数中设定了发送超时值 $cat/proc/sys/net/ipv4/tcp_syn_retries。
5
tcp_syn_retries默认值为 5, 这意味着SYN 重复的最大次数为 5 。 让我们继续实验。 戴上它 。tcp_syn_retries设置为 2 次：$echo2 > /proc/sys/net/ipv4/tcp_syn_retries
重写抓取袋后, 使用 Wiresark 打开分析, 并显示下图 :

整个期间,SYN重复两次。

实验一的实验小结

作为试验之一的结果,我们可以发现,当客户第一次对SYN包握手时,随着时间的推移从服务中没收的ACK将SYN数据集随时间推移再传送,而经过一段时间再传送的RTO将翻一番,直到SYN包到达。tcp_syn_retries客户将不再按价值发送 SYN 包 。

SYN 超时重传

TCP 第二次握手 SYN, ACK 滴滴实验二

为了模仿客户无法接受SYN-ACK软件包的第二次握手,我为客户增加了防火墙限制,以便立即用暴力将服务的数据丢出,防火墙设置如下:

接下来,在客户端上, 运行旋律命令 :

从date它能够确定Curl在返回后约1分钟内被意外删除。 客户在此期间利用Wiresark开始分析获得的数据集揭示了以下时间顺序:

从图中可以发现：

• 由于防火墙封锁了服务在客户启动 SYN 后的所有数据包, Curl 无法接收服务 SYN 、 ACK 的软件包, 当超时发生时, SYN 软件包被重新传送。
• 客户收到客户的 SYN 软件包后,返回客户的 SYN 软件包,返回 SYN 、 ACK 软件包,但客户没有返回 ACK 软件包,在加班时间过后又重新转发了 SYN 、 ACK 软件包,客户收到SYN 软件包时,SYN 的SYN 软件包已经到达服务,客户返回 SYN 、 ACK 软件包,但SYN 、 ACK 重新传输计时器没有被重置,而且继续
• 最后,客户端 SYN 已达5次( tcp_ syn_retries 默认值为 5 次), 没有再交付 SYN 软件包 。

因此,当第二个握手 SYN, ACK 丢弃软件包时, 客户端会返回 SYN 软件包, 服务器会随着时间的推移返回 SYN, ACK 软件包 。

客户安装了防火墙并禁用了服务网络包。 为什么 tcpdump 无法捕捉服务网络包?

视额外表单限值而定,在添加表单限值后, tcpdump 是否将赶上包件 :

• 如果添加的是INPUT条例规定你可以拿包
• 如果添加的是OUTPUT规则，则抓不到包

网络软件包按以下顺序输入主机:

• 进来的顺序 Wire -> NIC ->tcpdump -> netfilter/iptables
• 出去的顺序iptables -> tcpdump-> NIC -> Wire

由于 tcp_syn_retries 限制 SYN 传送器, SYN 的最大限制是多少, 第二次振动的ACK 限制是多少?

第二次握手时向SYN和ACK包重新传送的最大次数是通过TCP。tcp_synack_retries以下是内核参数的默认值: $cat/ proc/sys/net/ipv4/ tcp_ synack_ restries
5
事实上,TCP第二次握手SYN、ACK袋最大再传输的默认设置是5接下来,我们将重复实验,从客户开始, 检查SYN和ACK包的最大再传送次数 五次。tcp_syn_retries设置为 1, 显示客户端 SYN 有一次性超时。 目标是防止许多 SYN 重复, 并重置服务器 SYN 、 ACK 定时器 。 然后, 如前所述 :

1. 客户配置防火墙屏蔽服务的数据包
2. 数据包是客户在卷发处方执行期间抓取的 tcpdump。

使用 Wiresark 打开分析, 并显示记录的数据包的年表如下:

从上述情况中可以得出以下结论:

• 因为客户的SYN只有一次被再次传送tcp_syn_retries值为 1
• 服务器响应客户的SYN时间超时软件包,而且由于客户的ACK软件包从未收到,服务器继续重复SYN、ACK软件包五次,每个软件包的RTO指数增加。tcp_synack_retries值为 5

然后,我把tcp_synack_retries的值增加到2。tcp_syn_retries依然设置为 1:$echo2 > /proc/sys/net/ipv4/tcp_synack_retries
$echo1 > /proc/sys/net/ipv4/tcp_syn_retries
依然保持一样的实验步骤进行操作，接着使用 Wiresark 打开分析, 并显示记录的数据包的年表如下:

可见：

• 根据tcp_syn_retries设定的提供条件,客户的SYN软件包一直仅一次重新发送一次。
• SYN和ACK重复两次,以匹配 tcp_synack_retries 提供的值。

实验二的实验小结

作为实验二的结果,我们可以发现,当 TCP 握握 SYN 、 ACK 套件丢失时, 客户 SYN 套件将随时间再次传输, 服务器 SYN 、 ACK 将随时间再次传输。 客户 SYN 套件重复超时的最大次数由 tcp_ syn_ retries 定义, 默认值为 5; 服务器 SYN 和 ACK 套件的最大次数

实验三:TCP,第三次握手,ACK,和袋滴。

我模拟TCP第三次握手的ACK软件包的实验技术是将防火墙安装在服务上,保护客户免受TCP信息中显示为ACK的软件包,即当服务获得客户端的TCPACK软件包时,它会丢弃它。下面是ipables配置命令:

接下来,在客户端上,运行以下 tcpdump 命令 :

客户端然后通过调频网连接到服务, 因为调频网命令用于建立 TCP 连接, 因此此命令用于测试 :

在这一点上,客户处于这一位置,因为他第三次没有拿到ACK包。SYN_RECV状态：

在这种情况下,客户已完成TCP连接的建立。ESTABLISHED状态：

服务器的 TCP 连接在一分钟后被发现缺席 :

客户仍在办公。ESTABLISHED状态：

接下来,在客户刚刚建立的远程网上会话中, 第123456型字符发送 :

"好久不见 客户的电话网被拆解了

以上是这一成就的三种表现,有两种保留:

• 把服务器放在首位有什么意义?SYN_RECV一分钟后 州际联系消失了?
• 为什么客户在输入了123456个字符很长时间之后,电话网断开?

让我们打开刚刚用Wiresark下载的数据集, 并显示以下时间顺序:

上图的流程：

• 服务 TCP 连接定位后, 客户端会将 SYN 包发送到服务器, 服务器会接受它们, 并将 SYN 、 ACK 包返回到客户端 。SYN_RECV状态；
• 在发现客户的TCP连接后,客户收到了服务SYN和ACK包,并将ACK包还给了服务。ESTABLISHED状态；
• 该服务器自安装防火墙以来就一直在运行,防火墙防住了客户的ACK软件包。SYN_RECV状态，没有进入ESTABLISHED目前, tcpdump 能够从客户端收集ACK 软件包, 因为软件包按程序 tcpudmp 和 ipables 到达系统。
• 服务端再发送 SYN 和 ACK 包五倍, 或 tcp_ synack_ retries (默认值为 5) 的值, 然后不再发送 。 由于服务的 TCP 连接是自愿终止的, 刚刚处于 SYN_ RECV 状态的 TCP 连接被切断, 客户仍然处于同一位置 。ESTABLISHED状态；
• 尽管服务器TCP没有插管,但发现客户在一段时间后仍保持连接。ESTABLISHED状态, 从而在客户的 Telnet 会话中输入 123456 个字符 ;
• 在服务中断,客户的数据电文经过一段时间再次传送后,实时传输机会的价值每一次都成倍上升,持续了很长时间,客户的Telnet只报告了15次错误的退出。

通过这一轮分析,消除了以下怀疑点:

• 当再传送 SYN 和 ACK 包时, 服务器超过再传送的最大数量 。tcp_synack_retries,TCP与服务端的连接被立即终止。
• 在客户向服务提供包件时,由于服务TCP的连接被撤销,已重新发送15次。

在 tcp_ syn_ retries 指定第一次握手后, SYN 包最多可以重复多少次,在 tcp_ synack_ retries 指定第二次握手后, SYN 包最多可以重复多少次。 TCP 连接建立后,该包最多可以重复多少次?

连接建立后TCP包包件转让,最大超时传输tcp_retries2默认值为15倍,如 $cat/proc/sys/net/ipv4/tcp_retries2 所指定。
15
如果所有15次转播都完成了 TCP 会通知程序"不可能,不可能通过包包!"

如果客户不提交数据,何时终止已建立的连接?

这里需要提及的是TCP的生存机制。 这个机制的理由如下: 定义一个时间段, 在没有任何相关活动的情况下, TCP 生存机制将在每一间隔期间通过发送 " 检测报告 " 开始运行, 间隔期中包含极少的数据, 如果连续几次检测报告没有得到回应, 则可以认为当前的 TCP 连接已经停止, 通知上一级错误信息应用的系统微小。 Linux 中的内核可以拥有相应的参数来确定活时间、 探测的活时间和探测的活间隔, 所有这些都是默认值: Net. ipv4. tcp_keepalive_time=7200。
net.ipv4.tcp_keepalive_intvl=75
net.ipv4.tcp_keepalive_probes=9

• tcp_keepalive_time= 7200: 指定时间为 7200 秒( 2小时), 之后如果没有连接活动, 机制将被启用 。
• tcp_keepalive_intvl=75:表示每个测试间隔应持续75秒。
• tcp_keepalive_probes=9:9次没有收到答复,表示对方无法进入,导致连接中断。

“死亡”连接至少需要2小时11分15秒 才能在Linux系统中发现

有点长,但如果我拿着包够久 我也许能拿到报告

实验三的实验小结

在建立 TCP 连接时, 如果服务器不能为第三次握手获得 ACK, 服务器将暂时定位 。SYN_RECV客户的身份和客户的身份ESTABLISHED因为客户没有收到 TCP 第三次握手ACK, SYN, ACK包将重新发送, 直到收到不止一次重复。tcp_synack_retries服务器将在值之后断开 TCP 连接( 默认为 5 次 ) 。 对于客户来说, 有两种情景:

• 如果客户不提交数据包,请保持联络。ESTABLISHED如果2小时11分15秒后发现“死亡”连接,客户连接将被终止。
• 如果客户发送软件包,而没有收到服务确认信息,该软件包将受到怨恨,直到重复一次以上。tcp_retries2 值( 默认 15 次) TCP 连接后, 客户端将被断开 。

到此为止 小林周末会开个节目 请留意一下 ‍ ‍

本文由 在线网速测试 整理编辑，转载请注明出处，原文链接：https://www.wangsu123.cn/news/12041.html。