$ echo 2 > /proc/sys/net/ipv4/tcp_syn_retries重传抓包后，用 Wireshark 打开分析，显示如下图：实验一的实验小结通过实验一的实验结果，我们可以得知，当客户端发起的 TCP 第一次握手 SYN 包，在超时时间内没收到服务端的 ACK，就会在超时重传 SYN 数据包，每次超时重传的 RTO 是翻倍上涨的，直到 SYN 包的重传次数到达 tcp_syn_retries 值后，客户端不再发送 SYN 包#实验二：TCP 第二次握手 SYN、ACK 丢包为了模拟客户端收不到服务端第二次握手 SYN、ACK 包，我的做法是在客户端加上防火墙限制，直接粗暴的把来自服务端的数据都丢弃，防火墙的配置如下：接着，在客户端执行 curl 命令：从 date 返回的时间前后，可以算出大概 1 分钟后，curl 报错退出了客户端在这其间抓取的数据包，用 Wireshark 打开分析，显示的时序图如下：从图中可以发现：客户端发起 SYN 后，由于防火墙屏蔽了服务端的所有数据包，所以 curl 是无法收到服务端的 SYN、ACK 包，当发生超时后，就会重传 SYN 包服务端收到客户的 SYN 包后，就会回 SYN、ACK 包，但是客户端一直没有回 ACK，服务端在超时后，重传了 SYN、ACK 包，接着一会，客户端超时重传的 SYN 包又抵达了服务端，服务端收到后，然后回了 SYN、ACK 包，但是SYN、ACK包的重传定时器并没有重置，还持续在重传，因为第二次握手在没收到第三次握手的 ACK 确认报文时，就会重传到最大次数最后，客户端 SYN 超时重传次数达到了 5 次（tcp_syn_retries 默认值 5 次），就不再继续发送 SYN 包了所以，我们可以发现，当第二次握手的 SYN、ACK 丢包时，客户端会超时重发 SYN 包，服务端也会超时重传 SYN、ACK 包咦？客户端设置了防火墙，屏蔽了服务端的网络包，为什么 tcpdump 还能抓到服务端的网络包？添加 iptables 限制后， tcpdump 是否能抓到包 ，这要看添加的 iptables 限制条件：如果添加的是 INPUT 规则，则可以抓得到包如果添加的是 OUTPUT 规则，则抓不到包网络包进入主机后的顺序如下：进来的顺序 Wire -> NIC -> tcpdump -> netfilter/iptables出去的顺序 iptables -> tcpdump -> NIC -> Wiretcp_syn_retries 是限制 SYN 重传次数，那第二次握手 SYN、ACK 限制最大重传次数是多少？TCP 第二次握手 SYN、ACK 包的最大重传次数是通过 tcp_synack_retries 内核参数限制的，其默认值如下：$ cat /proc/sys/net/ipv4/tcp_synack_retries5是的，TCP 第二次握手 SYN、ACK 包的最大重传次数默认值是 5 次为了验证 SYN、ACK 包最大重传次数是 5 次，我们继续做下实验，我们先把客户端的 tcp_syn_retries 设置为 1，表示客户端 SYN 最大超时次数是 1 次，目的是为了防止多次重传 SYN，把服务端 SYN、ACK 超时定时器重置接着，还是如上面的步骤：客户端配置防火墙屏蔽服务端的数据包客户端 tcpdump 抓取 curl 执行时的数据包把抓取的数据包，用 Wireshark 打开分析，显示的时序图如下：从上图，我们可以分析出：客户端的 SYN 只超时重传了 1 次，因为 tcp_syn_retries 值为 1服务端应答了客户端超时重传的 SYN 包后，由于一直收不到客户端的 ACK 包，所以服务端一直在超时重传 SYN、ACK 包，每次的 RTO 也是指数上涨的，一共超时重传了 5 次，因为 tcp_synack_retries 值为 5接着，我把 tcp_synack_retries 设置为 2，tcp_syn_retries 依然设置为 1:$ echo 2 > /proc/sys/net/ipv4/tcp_synack_retries$ echo 1 > /proc/sys/net/ipv4/tcp_syn_retries依然保持一样的实验步骤进行操作，接着把抓取的数据包，用 Wireshark 打开分析，显示的时序图如下：可见：客户端的 SYN 包只超时重传了 1 次，符合 tcp_syn_retries 设置的值；服务端的 SYN、ACK 超时重传了 2 次，符合 tcp_synack_retries 设置的值实验二的实验小结通过实验二的实验结果，我们可以得知，当 TCP 第二次握手 SYN、ACK 包丢了后，客户端 SYN 包会发生超时重传，服务端 SYN、ACK 也会发生超时重传客户端 SYN 包超时重传的最大次数，是由 tcp_syn_retries 决定的，默认值是 5 次；服务端 SYN、ACK 包时重传的最大次数，是由 tcp_synack_retries 决定的，默认值是 5 次#实验三：TCP 第三次握手 ACK 丢包为了模拟 TCP 第三次握手 ACK 包丢，我的实验方法是在服务端配置防火墙，屏蔽客户端 TCP 报文中标志位是 ACK 的包，也就是当服务端收到客户端的 TCP ACK 的报文时就会丢弃iptables 配置命令如下：接着，在客户端执行如下 tcpdump 命令：然后，客户端向服务端发起 telnet，因为 telnet 命令是会发起 TCP 连接，所以用此命令做测试：此时，由于服务端收不到第三次握手的 ACK 包，所以一直处于 SYN_RECV 状态：而客户端是已完成 TCP 连接建立，处于 ESTABLISHED 状态：过了 1 分钟后，观察发现服务端的 TCP 连接不见了：过了 30 分钟，客户端依然还是处于 ESTABLISHED 状态：接着，在刚才客户端建立的 telnet 会话，输入 123456 字符，进行发送：持续「好长」一段时间，客户端的 telnet 才断开连接：以上就是本次的实现三的现象，这里存在两个疑点：为什么服务端原本处于 SYN_RECV 状态的连接，过 1 分钟后就消失了？为什么客户端 telnet 输入 123456 字符后，过了好长一段时间，telnet 才断开连接？不着急，我们把刚抓的数据包，用 Wireshark 打开分析，显示的时序图如下：上图的流程：客户端发送 SYN 包给服务端，服务端收到后，回了个 SYN、ACK 包给客户端，此时服务端的 TCP 连接处于 SYN_RECV 状态；客户端收到服务端的 SYN、ACK 包后，给服务端回了个 ACK 包，此时客户端的 TCP 连接处于 ESTABLISHED 状态；由于服务端配置了防火墙，屏蔽了客户端的 ACK 包，所以服务端一直处于 SYN_RECV 状态，没有进入 ESTABLISHED 状态，tcpdump 之所以能抓到客户端的 ACK 包，是因为数据包进入系统的顺序是先进入 tcpudmp，后经过 iptables；接着，服务端超时重传了 SYN、ACK 包，重传了 5 次后，也就是超过 tcp_synack_retries 的值（默认值是 5），然后就没有继续重传了，此时服务端的 TCP 连接主动中止了，所以刚才处于 SYN_RECV 状态的 TCP 连接断开了，而客户端依然处于ESTABLISHED 状态；虽然服务端 TCP 断开了，但过了一段时间，发现客户端依然处于ESTABLISHED 状态，于是就在客户端的 telnet 会话输入了 123456 字符；由于服务端的防火墙配置了屏蔽所有携带 ACK 标志位的 TCP 报文，客户端发送的数据报文，服务端并不会接收，而是丢弃（如果服务端没有设置防火墙，由于服务端已经断开连接，此时收到客户的发来的数据报文后，会回 RST 报文）客户端由于一直收不到数据报文的确认报文，所以触发超时重传，在超时重传过程中，每一次重传，RTO 的值是指数增长的，所以持续了好长一段时间，客户端的 telnet 才报错退出了，此时共重传了 15 次，然后客户端的也断开了连接通过这一波分析，刚才的两个疑点已经解除了：服务端在重传 SYN、ACK 包时，超过了最大重传次数 tcp_synack_retries，于是服务端的 TCP 连接主动断开了客户端向服务端发送数据报文时，如果迟迟没有收到数据包的确认报文，也会触发超时重传，一共重传了 15 次数据报文， 最后 telnet 就断开了连接TCP 第一次握手的 SYN 包超时重传最大次数是由 tcp_syn_retries 指定，TCP 第二次握手的 SYN、ACK 包超时重传最大次数是由 tcp_synack_retries 指定，那 TCP 建立连接后的数据包最大超时重传次数是由什么参数指定呢？TCP 建立连接后的数据包传输，最大超时重传次数是由 tcp_retries2 指定，默认值是 15 次，如下：$ cat /proc/sys/net/ipv4/tcp_retries215如果 15 次重传都做完了，TCP 就会告诉应用层说：“搞不定了，包怎么都传不过去”那如果客户端不发送数据，什么时候才会断开处于 ESTABLISHED 状态的连接？这里就需要提到 TCP 的 保活机制这个机制的原理是这样的：定义一个时间段，在这个时间段内，如果没有任何连接相关的活动，TCP 保活机制会开始作用，每隔一个时间间隔，发送一个「探测报文」，该探测报文包含的数据非常少，如果连续几个探测报文都没有得到响应，则认为当前的 TCP 连接已经死亡，系统内核将错误信息通知给上层应用程序在 Linux 内核可以有对应的参数可以设置保活时间、保活探测的次数、保活探测的时间间隔，以下都为默认值：
net.ipv4.tcp_keepalive_time=7200net.ipv4.tcp_keepalive_intvl=75 net.ipv4.tcp_keepalive_probes=9tcp_keepalive_time=7200：表示保活时间是 7200 秒（2小时），也就 2 小时内如果没有任何连接相关的活动，则会启动保活机制tcp_keepalive_intvl=75：表示每次检测间隔 75 秒；tcp_keepalive_probes=9：表示检测 9 次无响应，认为对方是不可达的，从而中断本次的连接也就是说在 Linux 系统中，最少需要经过 2 小时 11 分 15 秒才可以发现一个「死亡」连接这个时间是有点长的，所以如果我抓包足够久，或许能抓到探测报文实验三的实验小结在建立 TCP 连接时，如果第三次握手的 ACK，服务端无法收到，则服务端就会短暂处于 SYN_RECV 状态，而客户端会处于 ESTABLISHED 状态由于服务端一直收不到 TCP 第三次握手的 ACK，则会一直重传 SYN、ACK 包，直到重传次数超过 tcp_synack_retries 值（默认值 5 次）后，服务端就会断开 TCP 连接而客户端则会有两种情况：如果客户端没发送数据包，一直处于 ESTABLISHED 状态，然后经过 2 小时 11 分 15 秒才可以发现一个「死亡」连接，于是客户端连接就会断开连接如果客户端发送了数据包，一直没有收到服务端对该数据包的确认报文，则会一直重传该数据包，直到重传次数超过 tcp_retries2 值（默认值 15 次）后，客户端就会断开 TCP 连接#TCP 快速建立连接客户端在向服务端发起 HTTP GET 请求时，一个完整的交互过程，需要 2.5 个 RTT 的时延由于第三次握手是可以携带数据的，这时如果在第三次握手发起 HTTP GET 请求，需要 2 个 RTT 的时延但是在下一次（不是同个 TCP 连接的下一次）发起 HTTP GET 请求时，经历的 RTT 也是一样，如下图：在 Linux 3.7 内核版本中，提供了 TCP Fast Open 功能，这个功能可以减少 TCP 连接建立的时延在第一次建立连接的时候，服务端在第二次握手产生一个 Cookie （已加密）并通过 SYN、ACK 包一起发给客户端，于是客户端就会缓存这个 Cookie，所以第一次发起 HTTP Get 请求的时候，还是需要 2 个 RTT 的时延；在下次请求的时候，客户端在 SYN 包带上 Cookie 发给服务端，就提前可以跳过三次握手的过程，因为 Cookie 中维护了一些信息，服务端可以从 Cookie 获取 TCP 相关的信息，这时发起的 HTTP GET 请求就只需要 1 个 RTT 的时延；注：客户端在请求并存储了 Fast Open Cookie 之后，可以不断重复 TCP Fast Open 直至服务器认为 Cookie 无效（通常为过期）在 Linux 上如何打开 Fast Open 功能？可以通过设置 net.ipv4.tcp_fastopn 内核参数，来打开 Fast Open 功能net.ipv4.tcp_fastopn 各个值的意义:0 关闭1 作为客户端使用 Fast Open 功能2 作为服务端使用 Fast Open 功能3 无论作为客户端还是服务器，都可以使用 Fast Open 功能TCP Fast Open 抓包分析在下图，数据包 7 号，客户端发起了第二次 TCP 连接时，SYN 包会携带 Cooike，并且长度为 5 的数据服务端收到后，校验 Cooike 合法，于是就回了 SYN、ACK 包，并且确认应答收到了客户端的数据包，ACK = 5 + 1 = 6#TCP 重复确认和快速重传当接收方收到乱序数据包时，会发送重复的 ACK，以便告知发送方要重发该数据包，当发送方收到 3 个重复 ACK 时，就会触发快速重传，立刻重发丢失数据包TCP 重复确认和快速重传的一个案例，用 Wireshark 分析，显示如下：数据包 1 期望的下一个数据包 Seq 是 1，但是数据包 2 发送的 Seq 却是 10945，说明收到的是乱序数据包，于是回了数据包 3 ，还是同样的 Seq = 1，Ack = 1，这表明是重复的 ACK；数据包 4 和 6 依然是乱序的数据包，于是依然回了重复的 ACK；当对方收到三次重复的 ACK 后，于是就快速重传了 Seq = 1 、Len = 1368 的数据包 8；当收到重传的数据包后，发现 Seq = 1 是期望的数据包，于是就发送了个确认收到快速重传的 ACK注意：快速重传和重复 ACK 标记信息是 Wireshark 的功能，非数据包本身的信息以上案例在 TCP 三次握手时协商开启了选择性确认 SACK，因此一旦数据包丢失并收到重复 ACK ，即使在丢失数据包之后还成功接收了其他数据包，也只需要重传丢失的数据包如果不启用 SACK，就必须重传丢失包之后的每个数据包如果要支持 SACK，必须双方都要支持在 Linux 下，可以通过 net.ipv4.tcp_sack 参数打开这个功能（Linux 2.4 后默认打开）#TCP 流量控制TCP 为了防止发送方无脑的发送数据，导致接收方缓冲区被填满，所以就有了滑动窗口的机制，它可利用接收方的接收窗口来控制发送方要发送的数据量，也就是流量控制接收窗口是由接收方指定的值，存储在 TCP 头部中，它可以告诉发送方自己的 TCP 缓冲空间区大小，这个缓冲区是给应用程序读取数据的空间：如果应用程序读取了缓冲区的数据，那么缓冲空间区就会把被读取的数据移除如果应用程序没有读取数据，则数据会一直滞留在缓冲区接收窗口的大小，是在 TCP 三次握手中协商好的，后续数据传输时，接收方发送确认应答 ACK 报文时，会携带当前的接收窗口的大小，以此来告知发送方假设接收方接收到数据后，应用层能很快的从缓冲区里读取数据，那么窗口大小会一直保持不变，过程如下：但是现实中服务器会出现繁忙的情况，当应用程序读取速度慢，那么缓存空间会慢慢被占满，于是为了保证发送方发送的数据不会超过缓冲区大小，服务器则会调整窗口大小的值，接着通过 ACK 报文通知给对方，告知现在的接收窗口大小，从而控制发送方发送的数据大小#零窗口通知与窗口探测假设接收方处理数据的速度跟不上接收数据的速度，缓存就会被占满，从而导致接收窗口为 0，当发送方接收到零窗口通知时，就会停止发送数据如下图，可以看到接收方的窗口大小在不断的收缩至 0：接着，发送方会定时发送窗口大小探测报文，以便及时知道接收方窗口大小的变化以下图 Wireshark 分析图作为例子说明：发送方发送了数据包 1 给接收方，接收方收到后，由于缓冲区被占满，回了个零窗口通知；发送方收到零窗口通知后，就不再发送数据了，直到过了 3.4 秒后，发送了一个 TCP Keep-Alive 报文，也就是窗口大小探测报文；当接收方收到窗口探测报文后，就立马回一个窗口通知，但是窗口大小还是 0；发送方发现窗口还是 0，于是继续等待了 6.8（翻倍） 秒后，又发送了窗口探测报文，接收方依然还是回了窗口为 0 的通知；发送方发现窗口还是 0，于是继续等待了 13.5（翻倍） 秒后，又发送了窗口探测报文，接收方依然还是回了窗口为 0 的通知；可以发现，这些窗口探测报文以 3.4s、6.5s、13.5s 的间隔出现，说明超时时间会翻倍递增这连接暂停了 25s，想象一下你在打王者的时候，25s 的延迟你还能上王者吗？#发送窗口的分析在 Wireshark 看到的 Windows size 也就是 " win = "，这个值表示发送窗口吗？这不是发送窗口，而是在向对方声明自己的接收窗口你可能会好奇，抓包文件里有「Window size scaling factor」，它其实是算出实际窗口大小的乘法因子，「Window size value」实际上并不是真实的窗口大小，真实窗口大小的计算公式如下：「Window size value」 「Window size scaling factor」 = 「Caculated window size 」对应的下图案例，也就是 32 2048 = 65536实际上是 Caculated window size 的值是 Wireshark 工具帮我们算好的，Window size scaling factor 和 Windos size value 的值是在 TCP 头部中，其中 Window size scaling factor 是在三次握手过程中确定的，如果你抓包的数据没有 TCP 三次握手，那可能就无法算出真实的窗口大小的值，如下图：如何在包里看出发送窗口的大小？很遗憾，没有简单的办法，发送窗口虽然是由接收窗口决定，但是它又可以被网络因素影响，也就是拥塞窗口，实际上发送窗口是值是 min(拥塞窗口，接收窗口)发送窗口和 MSS 有什么关系？发送窗口决定了一口气能发多少字节，而 MSS 决定了这些字节要分多少包才能发完举个例子，如果发送窗口为 16000 字节的情况下，如果 MSS 是 1000 字节，那就需要发送 1600/1000 = 16 个包发送方在一个窗口发出 n 个包，是不是需要 n 个 ACK 确认报文？不一定，因为 TCP 有累计确认机制，所以当收到多个数据包时，只需要应答最后一个数据包的 ACK 报文就可以了#TCP 延迟确认与 Nagle 算法当我们 TCP 报文的承载的数据非常小的时候，例如几个字节，那么整个网络的效率是很低的，因为每个 TCP 报文中都会有 20 个字节的 TCP 头部，也会有 20 个字节的 IP 头部，而数据只有几个字节，所以在整个报文中有效数据占有的比重就会非常低这就好像快递员开着大货车送一个小包裹一样浪费那么就出现了常见的两种策略，来减少小报文的传输，分别是：Nagle 算法延迟确认Nagle 算法是如何避免大量 TCP 小数据报文的传输？Nagle 算法做了一些策略来避免过多的小数据报文发送，这可提高传输效率Nagle 伪代码如下：if 有数据要发送 { if 可用窗口大小 >= MSS and 可发送的数据 >= MSS { 立刻发送MSS大小的数据 } else { if 有未确认的数据 { 将数据放入缓存等待接收ACK } else { 立刻发送数据 } }}使用 Nagle 算法，该算法的思路是延时处理，只有满足下面两个条件中的任意一个条件，才能可以发送数据：条件一：要等到窗口大小 >= MSS 并且 数据大小 >= MSS；条件二：收到之前发送数据的 ack 回包；只要上面两个条件都不满足，发送方一直在囤积数据，直到满足上面的发送条件上图右侧启用了 Nagle 算法，它的发送数据的过程：一开始由于没有已发送未确认的报文，所以就立刻发了 H 字符；接着，在还没收到对 H 字符的确认报文时，发送方就一直在囤积数据，直到收到了确认报文后，此时没有已发送未确认的报文，于是就把囤积后的 ELL 字符一起发给了接收方；待收到对 ELL 字符的确认报文后，于是把最后一个 O 字符发送了出去可以看出，Nagle 算法一定会有一个小报文，也就是在最开始的时候另外，Nagle 算法默认是打开的，如果对于一些需要小数据包交互的场景的程序，比如，telnet 或 ssh 这样的交互性比较强的程序，则需要关闭 Nagle 算法可以在 Socket 设置 TCP_NODELAY 选项来关闭这个算法（关闭 Nagle 算法没有全局参数，需要根据每个应用自己的特点来关闭）那延迟确认又是什么？事实上当没有携带数据的 ACK，它的网络效率也是很低的，因为它也有 40 个字节的 IP 头 和 TCP 头，但却没有携带数据报文为了解决 ACK 传输效率低问题，所以就衍生出了 TCP 延迟确认TCP 延迟确认的策略：当有响应数据要发送时，ACK 会随着响应数据一起立刻发送给对方当没有响应数据要发送时，ACK 将会延迟一段时间，以等待是否有响应数据可以一起发送如果在延迟等待发送 ACK 期间，对方的第二个数据报文又到达了，这时就会立刻发送 ACK延迟等待的时间是在 Linux 内核中定义的，如下图：关键就需要 HZ 这个数值大小，HZ 是跟系统的时钟频率有关，每个操作系统都不一样，在我的 Linux 系统中 HZ 大小是 1000，如下图：知道了 HZ 的大小，那么就可以算出：最大延迟确认时间是 200 ms （1000/5）最短延迟确认时间是 40 ms （1000/25）TCP 延迟确认可以在 Socket 设置 TCP_QUICKACK 选项来关闭这个算法延迟确认 和 Nagle 算法混合使用时，会产生新的问题当 TCP 延迟确认 和 Nagle 算法混合使用时，会导致时耗增长，如下图：发送方使用了 Nagle 算法，接收方使用了 TCP 延迟确认会发生如下的过程：发送方先发出一个小报文，接收方收到后，由于延迟确认机制，自己又没有要发送的数据，只能干等着发送方的下一个报文到达；而发送方由于 Nagle 算法机制，在未收到第一个报文的确认前，是不会发送后续的数据；所以接收方只能等待最大时间 200 ms 后，才回 ACK 报文，发送方收到第一个报文的确认报文后，也才可以发送后续的数据很明显，这两个同时使用会造成额外的时延，这就会使得网络"很慢"的感觉要解决这个问题，只有两个办法：要不发送方关闭 Nagle 算法要不接收方关闭 TCP 延迟确认参考资料：[1] Wireshark网络分析的艺术.林沛满.人民邮电出版社.[2] Wireshark网络分析就这么简单.林沛满.人民邮电出版社.[3] Wireshark数据包分析实战.Chris Sanders .人民邮电出版社.读者问答
（图片来源网络，侵删）
0 评论