1,重传基本原理 TCP协议是一种面向连接的可靠的传输层协议，它保证了数据的可靠传输。既然是可靠的传输，那对于丢包情况肯定有一套重传的机制。...TCP重传的基本原理：在发送一个数据之后，就开启一个定时器，若是在这个时间内没有收到发送数据的ACK确认报文，则对该报文进行重传。 1.jpg 上面的时序图，就是TCP重传的全部内容吗？...有有种测量方法： 1）重传队列中数据包的TCP控制块 TCP每发送一个数据包，就会把该数据包复制一份放到TCP重传队列中，数据包skb中的TCP控制块包含着一个变量tcp_skb_cb->when，记录了该数据包的第一次发送时间...因为根据TCP Timestamp测出来的RTT更加准确；对于重传的数据包的响应，重传队列方法并不知道重传的开始时间，所以没办法采集起来作为一个样本；而TCP Timestamp方法则可以。...5，选择性重传 TCP通信时，如果发送序列中间某个数据包丢失，TCP会通过重传最后确认的包开始的后续包，这样原先已经正确传输的包也可能重复发送，急剧降低了TCP性能。
收到研发反馈，TCP重传严重。...，可接受短暂的非0情况 ulimit -a检查服务打开的文件句柄上限,10多万正常是足够的 通过ifconfig查看网卡是否存在持续drop、error现象 容器状态正常，开始使用wiresherk分析抓包文件...中的TCP重传抓包分析占用带宽，进一步作出网络策略 2、Statistics–>Flow graph会话通信过程图形可视化，还可以看到是否有TCP的延迟包括延迟确认(Delayed ACK),服务端是否开启...没收到一个这种包就会Ack一次期望的Seq值，提现发送方 6、TCP Fast Retransmission 当发送方收到3个或以上的【TCP Dup ACK】，就意识到之前发的包可能丢了，于是快速重传它...7、TCP Retransmission 如果一个包真的丢了，又没有后续包可以在接收方触发【Dup Ack】就不会快速重传，这种情况下发送方只好等到超时了再重传 8、TCP zerowindow
摘要 重传机制 超时重传 快速重传 SACK重传 Duplicate SACK 重传机制 TCP重传机制主要是为了防止网路包丢弃，重传的工作方式主要借助TCP头部中的序列号和确认号来决定是否重传，重传的触发方式主要由以下几种...根据TCP实现的不同，上述两种情况都可能存在。 SACK重传 SACK重传其实就是选择性重传，它是为了解决快速重传不知道需要重传哪些包的问题。 SACK是如何让发送方知道重传哪些包的？...TCP的选项字段增加一个SACK字段，接收方会将已经收到数据包序列号范围发送给发送方，这样发送方通过SACK信息就能找到丢失的数据包重传此数据包。...SACK的使用条件 SACK必须要发送方和接收方同时支持，在linux中可以通过net.ipv4.tcp_sack参数开启（Linux2.4以后默认开启）。...如何开启D-SACK 在Linux下可以通过net.ipv4.tcp_dsack参数开启/关闭这个功能(Linux 2.4后默认打开)。
第21章 TCP的超时与重传 21.1 引言 T C P提供可靠的运输层。它使用的方法之一就是确认从另一端收到的数据。但数据和确认都有可能会丢失。 T C P通过在发送时设置一个定时器来解决这种问题。...如果当定时器溢出时还没有收到确认，它就重传该数据。对任何实现而言，关键之处就在于超时和重传的策略，即怎样决定超时间隔和如何确定重传的频率。...我们已经看到过两个超时和重传的例子： （1）在6 . 5节的I C M P端口不能到达的例子中，看到T F T P客户使用U D P实现了一个简单的超时和重传机制：假定 5秒是一个适当的时间间隔，并每隔...5秒进行重传； （ 2）在向一个不存在的主机发送 A R P的例子中（第 4 . 5节），我们看到当T C P试图建立连接的时候，在每个重传之间使用一个较长的时延来重传 S Y N。...重传定时器使用于当希望收到另一端的确认。在本章我们将详细讨论这个定时器以及一些相关的问题，如拥塞避免。
图 under the strange horizon by joeyjazz 一 关于TCP重传 TCP有重传是正常的机制，为了保障数据传输可靠性。...快速重传不太影响rt，但是发送窗口立即减半，会对吞吐带宽有一定影响 # 云环境虚拟机，还要考虑分析宿主机的问题 sudo ss -anti |grep -B 1 retrans #重传统计 if...\}//g'|egrep -v "^1 |Request" 2、联通性检查 ping $ip nc -nvz $ip $port 3、接收端应用程序问题排查；来源和目的抓包，wireshark分析具体是什么包丢失导致了重传...wireshark 分析该包，注意因为重传不是时刻都有的，所以抓包命令是要持续执行以便捕捉到重传的包。...这个案例仅仅发生一次，没有复现，通过抓包解析出来分析没有得到明确的结论。
本文讲述使用 BPF 记录 TCP 的重传和丢包记录，作为定位网络问题的一种辅助手段。...有了这些背景知识后，我们可以使用 kprobe 来达成这一目标，记录 TCP 重传的例子如下： $ echo 'p:kprobes/tcp_retransmit tcp_retransmit_skb port...对于上面的例子，一个等价的 BPF 程序如下： #include #include int log_tcp_retransmit(...对于 TCP 重传，也是一样的道理。...2452 TCP_ESTABLISHED 结论 本文讲述使用 BPF 带来的可观测性能力，获取 TCP 的重传及丢包记录，作为辅助定位网络问题的手段。
Acknowledgment Number Out = Sequence Number In + Bytes of Data Received 1.TCP重传 报文重传是TCP最基本的错误恢复功能...针对上述问题，TCP中设计了超时重传机制。...决定报文是否有必要重传的主要机制是重传计时器（retransmission timer），它的主要功能是维护重传超时（RTO）值。当报文使用TCP传输时。重传计时器启动，收到ACK时计时器停止。...在终于RTO值确定之前，确定每一次报文传输是否有丢包发生使用重传计时器，下图说明了TCP重传过程。 当报文发送之后，但接收方尚未发送TCP ACK报文，发送方假设源报文丢失并将其重传。...大多数Linux系统默认最大15次。两种操作系统都可配置。 1）超时重传 超时重传机制用来保证TCP传输的可靠性。
上篇中，主要向你介绍TCP协议的定义和丢包时的重传机制 下篇中，重点介绍TCP的流迭、拥塞处理。...于是，Linux下给了一个叫tcp_syncookies的参数来应对这个事——当SYN队列满了后，TCP会通过源地址端口、目标地址端口和时间戳打造出一个特别的Sequence Number发回去（又叫cookie...重传机制 TCP要保证所有的数据包都可以到达，所以，必需要有重传机制。...在 Linux下，可以通过tcp_sack参数打开这个功能（Linux 2.4后默认打开）。...Linux下的tcp_dsack参数用于开启这个功能（Linux 2.4后默认打开） 好了，上篇就到这里结束了。如果你觉得我写得还比较浅显易懂，那么，欢迎移步看下篇《TCP的流迭、拥塞处理》
当tcp进行三次握手的时候 , 第一步是客户端发送syn请求 , 服务端返回syn+sck , 客户端响应sck 当syn请求超时的时候,tcp会进行超时重传 , 重传次数在这里查看 cat /proc.../sys/net/ipv4/tcp_syn_retries ?...可以看到重传次数是6次 每次超时的时间是 1秒 2秒 4秒 8秒 16秒 32秒 使用telnet 测试一个不存在的ip和端口 telnet 222.222.222.222 80 使用...tcpdump 查看重传现象 tcpdump -i any port 88 ?...可以看到第一次连接失败后 , 重传了6次 间隔时间是 1秒 2秒 4秒 8秒 16秒 32秒
下面我们将针对每个定时器进行分析。 重传定时器 TCP协议是通过“确认+重传”来保证数据的可靠传输。当对端确认超时后，本端则要进行重传，下面我们来分析重传定时器的执行函数。...) { 44 if (tcp_is_sack(tp)) 45 mib_idx = LINUX_MIB_TCPSACKRECOVERYFAIL;...icsk->icsk_ca_state == TCP_CA_Loss) { 49 mib_idx = LINUX_MIB_TCPLOSSFAILURES; 50...if (tcp_is_sack(tp)) 53 mib_idx = LINUX_MIB_TCPSACKFAILURES; 54 else 55...mib_idx = LINUX_MIB_TCPRENOFAILURES; 56 } else { 57 mib_idx = LINUX_MIB_TCPTIMEOUTS
文章目录 Pre 为什么需要设计重传机制 四种常见的重传机制 超时重传 快速重传 SACK D-SACK 为什么需要设计重传机制 TCP 实现可靠传输的方式之一，是通过序列号与确认应答。...在 TCP 中，当发送端的数据到达接收主机时，接收端主机会返回一个确认应答消息，表示已收到消息 在复杂的网络环境中，数据包丢失是不可避免的。 所以 TCP 针对数据包丢失的情况，会用重传机制解决。...这些重传机制的引入旨在提高TCP协议在不同网络条件下的稳定性和性能。 超时重传是基本的机制，但可能导致不必要的等待。 快速重传通过更早地检测到冗余确认，加速了丢失数据的恢复。...四种常见的重传机制 超时重传 快速重传 SACK D-SACK 超时重传： 优点：简单直观，适用于各种网络环境。 缺点：可能导致不必要的重传，影响性能。...超时重传 快速重传 SACK D-SACK
引言 上一篇文章中，我们利用 wireshark 排查定位了 TCP 的连接问题与重传问题： 实战网络问题排查（四） -- 利用 wireshark 排查 TCP 连接与重传问题 TCP 有另一个常见的问题...快速重传机制 超时重传机制让 TCP 避免了因为网络异常等原因导致的丢包，但超时重传机制也伴随着许多问题，比如： 当一个报文段丢失，会等待一定的超时周期然后才重传分组，增加了端到端的时延。...当一个报文段丢失时，由于接收端一直在等待，导致其后的报文段已经被接收端接收但却迟迟得不到确认，造成超时的连锁反应，全部都不得不被重传，浪费了不必要的资源。 由此，TCP 诞生了快速重传机制。...但是，由于 IP 协议包的无序性，偶发的 TCP 快速重传是可以接受的，如果有 1% 以上的快速重传，那就需要引起注意了。 3....通过 wireshark 排查 TCP 快速重传 3.1 wireshark 中的快速重传 在 wireshark 中，重复 ACK 的关键字是“TCP Dup ACK”，快速重传的关键字是“TCP Fast
前言 上周Linux内核修复了4个CVE漏洞[1]，其中的CVE-2019-11477感觉是一个很厉害的Dos漏洞，不过因为有其他事打断，所以进展的速度比较慢，这期间网上已经有相关的分析文章了。...[2][3] 而我在尝试复现CVE-2019-11477漏洞的过程中，在第一步设置MSS的问题上就遇到问题了，无法达到预期效果，但是目前公开的分析文章却没对该部分内容进行详细分析。...所以本文将通过Linux内核源码对TCP的MSS机制进行详细分析。...对于MSS的深入研究 关于该漏洞的细节，别的文章中已经分析过了，这里简单的提一下，该漏洞为uint16溢出： tcp_gso_segs 类型为uint16 tcp_set_skb_tso_segs:...最后发现，传入tcp_write_xmit函数的mss_now都是通过tcp_current_mss函数进行计算的 随后对tcp_current_mss函数进行分析，关键代码如下： # tcp_output.c
分析认为SESU10母盘上内核TCP拥塞控制算法和Windows的Ack频率控制的策略存在不兼容情况。...目前至少确认 2.6.16内核版本存在此问题，打TCP优化补丁或者更换Tlinux以后可以解决问题。...客户端： Windows XP， Windows7，任意浏览器或者旋风（单线程下载） 测试工具：wireshark， httpwatch 测试连接：分别是自建CDN、百度下载、深圳DC+Apache 问题分析...： 通过客户端抓包分析发现速度很慢的段有两个问题： 服务器端总是等到前面的数据包确认以后才发送第二个包 Windows总是等到200ms左右才发送ACK确认。...Linux这一端，首先怀疑和nagle算法有关系，在nws服务器上设置TCP_NODELAY以后仍然可以重现，可以排除Nagle算法的影响。
[2][3] 而我在尝试复现CVE-2019-11477漏洞的过程中，在第一步设置MSS的问题上就遇到问题了，无法达到预期效果，但是目前公开的分析文章却没对该部分内容进行详细分析。...所以本文将通过Linux内核源码对TCP的MSS机制进行详细分析。 测试环境 1....对于MSS的深入研究 关于该漏洞的细节，别的文章中已经分析过了，这里简单的提一下，该漏洞为uint16溢出： tcp_gso_segs 类型为uint16 tcp_set_skb_tso_segs: tcp_skb_pcount_set...最后发现，传入tcp_write_xmit函数的mss_now都是通过tcp_current_mss函数进行计算的 随后对tcp_current_mss函数进行分析，关键代码如下： # tcp_output.c...endif 所以在Linux 4.15内核中，在用户不干预的情况下，内核是不会发出头部大小为60字节的TCP包。
TCP 重传 TCP 通信过程中一个最常见的问题就是 TCP 重传。...TCP 重传是 TCP 用来恢复受损、丢失、重复或失序的一个重要机制，如果发送方一段时间内未收到已发送包的确认，发送方就会触发重传。...在通信过程中，如果 TCP 重传的报文达到 0.5%，就会对性能产生严重影响，如果达到了 5%，那 TCP 连接就将会中断。...在 wireshark 中，重传报文被标记为 TCP Retransmission。...绝大部分性能问题都是业务层面引起的，也就是说是应用代码造成的，所以最先需要排查的是应用代码是否在性能问题出现时有过某些修改，这些修改是否会带来这些性能问题，充分否定这一情况以后，再花费精力去借助工具抓包分析网络链路上的问题
tcp 状态 tcp握手挥手的状态图如下: 服务端状态 CLOSED: 初始状态, 表示 TCP “关闭” LISTENING: server 侦听远方的tcp端口的连接请求(Server端bind某个端口...TIME_WAIT状态下的TCP连接会等待 2*MSL（Max Segment Lifetime，最大分段生存期，指一个TCP报文在Internet上的最长生存时间。...每个具体的TCP协议实现都必须选择一个确定的MSL值，RFC 1122建议是2分钟，但BSD传统实现采用了30秒，Linux可以cat /proc/sys/net/ipv4/tcp_fin_timeout...主要的目的是确保报文能够完整传输 常见TCP排查命令 netstat -nat: 查看 tcp 各个连接状态的数量 tcpdump -iany tcp port 9000: 对tcp端口为9000的进行抓包...lsof -i:9000, 对9000端口的套接字状态进行查看 参考资料 TCP状态分析
在Linux下，默认重试次数为5次，重试的间隔时间从1s开始每次都翻售，5次的重试时间间隔为1s, 2s, 4s, 8s, 16s，总共31s，第5次发出后还要等32s都知道第5次也超时了，所以，总共需要...于是，Linux下给了一个叫tcp_syncookies的参数来应对这个事——当SYN队列满了后，TCP会通过源地址端口、目标地址端口和时间戳打造出一个特别的Sequence Number发回去（又叫cookie...我们注意到，在TCP的状态图中，从TIME_WAIT状态到CLOSED状态，有一个超时设置，这个超时设置是 2*MSL（RFC793定义了MSL为2分钟，Linux设置成了30s）为什么要这有TIME_WAIT...建链接的SYN可能就被直接丢掉了（你可能会看到connection time out的错误）（如果你想观摩一下Linux的内核代码，请参看源码 tcp_timewait_state_process）。...如果网络上的延时突然增加，那么，TCP对这个事做出的应对只有重传数据，但是，重传会导致网络的负担更重，于是会导致更大的延迟以及更多的丢包，于是，这个情况就会进入恶性循环被不断地放大。
TCP问题分析 网络的五层协议 物理层 数据链路层 网络层，IP协议，ICMP协议（ping） 传输层，传输层有两个协议，面向连接的TCP和无连接的UDP，TCP是点对点的可靠连接，保证数据顺序必达...连续收到3次或者3次以上的重复Ack，就会触发一次快速重传 超时重传 RTT，消息包发送和收到Ack的往返时间，每一个消息包的RTT都可能不一样，TCP会根据消息包的RTT去计算下一次重传的时间间隔，...，也就是下重传消息需要等待Ack的时间，超过这个时间就再次发起下一次重传 TCP抓包分析 wireshark工具来查看tcpdump的抓包 对于有root过的android手机，如果手机系统中已经内置了...端的TCP发起了一个FIN，可能是调用了socket的close方法 tcpdump抓包分析 tcp dup ack 重复的Ack，#前面的数组表示丢包的包序号，后面表示第几次丢失，之所以会重复的Ack...是可能是因为在网络延迟较高，或者链路拥塞的时候一个包重传了多次，但是重传的这几次最终都被收到了，在接收端第一次收到这个包的时候对这个包进行了Ack，然后再收到后面几次重传，再回复重复的Ack tcp out
协议通过以下几种机制来提高可靠性： 确认机制：TCP协议采用确认机制来确保数据的可靠传输，发送方在发送数据后会等待接收方的确认消息，如果没有收到确认消息，则发送方会重传数据，直到接收方确认收到数据为止...超时重传机制：如果发送方在规定的时间内没有收到确认消息，则会认为数据丢失，会触发超时重传机制，即发送方会重新发送数据 滑动窗口机制：TCP协议采用滑动窗口机制来进行流量控制，即发送方和接收方都有一个窗口大小...B会超时重传这个FIN+ACK报文段，而A就能在2MSL时间内收到这个重传的FIN+ACK报文段，接着A重传一次确认，重新启动2MSL计时器。最后A和B都正常进入到CLOSED状态。...如果A在TIME-WAIT状态不等待一段时间而是在发送完ACK报文段后立即释放连接，那么就无法收到B重传的FIN+ACK报文段，因而也不会再发送一次确认报文段，这样B就无法按照正常步骤进入CLOSED状态...== 1 文末小结 通过本文的介绍我们了解了WireShark的基本使用和TCP协议的原理，在分析TCP流时我们可以从序列号、确认号、窗口大小等方面入手，深入理解数据包的传输过程，同时我们也学会了如何利用
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
