精华内容
下载资源
问答
  • TCP重传
    千次阅读
    2019-06-10 15:50:40

    一、TCP重传
        1、重传的原因
            1)发端计时器超时
            TCP每发送一个报文段,就对这个报文段设置一次计时器。当计时器超时而没有收到确认时,就重传该报文。
            注:原来报文哪去了呢?两种可能:
                1)在中间节点丢了。2)还在路上,走的慢。
            对于第一种情况:接收端是不知情的,而对于第二种情况,接收端表现为收到两个一摸一样的报文。
            2)快重传
            就是说在发送端一连收到4个ack报文,其中3个重复报文时,就立即重传相应的报文而不等到定时器超时。
            注:
                1)原来报文的去向以上同。
                2)重传报文可以与原报文不同,就是说重传报文长度可以比原报文长也可以比原报文短等。
                3)说明下逆序问题。还没到快重传的时候,走丢的包就出现了。这时候接收端保留逆序包,发送端不用对其进行重传。
        2、重传的判定
            TCM监测点要求计算一次HTTP过程的重传率,公式:重传率=重传报文数/有效报文数
            其中有效报文数:指的是除了纯ACK包外的报文总数。因为纯ACK包没有重传的说法。
            重传报文的判定分双向进行,现在的算法(简要说明):
            设置一个变量MaxSeq,初始化为0.每来一个包,查看其seq,如果该seq大于MaxSeq,则
            MaxSeq = seq,否则判定为重传包。
            该算法的缺点:目前看到的情况,无法区分逆序后来的包和重传包。如同逆序图所示:其实M3只是迟到了,并没有重传,但我们的算法却把它判定为重传报文。
    二、因重传引起的问题
        1.在测量过程中发现某个网站TCP连接的重置率特别高,抓包后发现,原来都是重传惹的祸(FIN ACK包重传)。
        可以理解当服务器收到客户端第一个Ack报文时,该次TCP连接就关闭了。再次收到ACK,就出错

    Ø 为什么TCP存在重传
        TCP是一种可靠的协议,在网络交互的过程中,由于TCP报文是封装在IP协议中的,IP协议的无连接特性导致其可能在交互的过程中丢失,在这种情况下,TCP协议如何保障其传输的可靠性呢?
        TCP通过在发送数据报文时设置一个超时定时器来解决这种问题,如果在定时器溢出时还没有收到来自对端对发送报文的确认,它就重传该数据报文。
    Ø 导致重传的常见状况
        1 数据报传输中途丢失
        发送端的数据报文在网络传输的过程中,被中间链路或中间设备丢弃,这个过程如下图所示:
        2 接收端的ACK确认报文在传输中途丢失
        发送端发送的数据报文到达了接受端,接受端也针对接收到的报文发送了相应的ACK确认报文,但是,这个ACK确认报文被中间链路或中间设备丢弃了,该过程如下图所示:
        3 接收端异常未响应ACK或被接收端丢弃
        发送端发送的数据报文到达了接收端,但是,接收端由于种种原因,直接忽略该数据报文,或者接收到报文但并没有发送针对该报文的ACK确认报文,这个过程如下图所示:
    Ø TCP重传间隔时间和TCP重传次数
        一般TCP报文的重传超时时间
        TCP重传时间间隔有着多种不同的算法,最常见的就是《TCP/IP详解卷1》中关于超时重传的算法。具体算法不再赘述,请大家参考《TCP/IP详解卷1》第21章《TCP的超时与重传》。
        SYN报文重传间隔时间
        在实际情况下,由于SYN报文是TCP连接的第一个报文,如果该报文在传输的过程中丢弃了,那么发送方则无法测量RTT,也就无法根据RTT来计算RTO。因此,SYN重传的算法就要简单一些,SYN重传时间间隔一般根据系统实现的不同稍有差别,windows系统一般将第一次重传超时设为3秒,以后每次超时重传时间为上一次的2倍,如下图所示:
        报文重传的次数
        TCP报文重传的次数也根据系统设置的不同而有区分,有些系统,一个报文只会被重传3次,如果重传三次后还未收到该报文的确认,那么就不再尝试重传,直接reset重置该TCP连接,但有些要求很高的业务应用系统,则会不断的重传被丢弃的报文,以尽最大可能保证业务数据的正常交互。
    Ø 重传对业务应用的影响
        1 保障了业务的可靠性
        TCP的重传存在原因就是为了保障TCP的可靠性,正是由于TCP存在重传的机制,那些基于TCP的业务应用在网络交互的过程中,不再担心由于丢包、包损坏等导致的一系列应用问题了。
        2 反映网络通讯的状况
        由于IP协议的不可靠性和网络系统的复杂性,少量的报文丢失和TCP重传是正常的,但是如果业务交互过程中,存在大量的TCP重传,会严重影响业务系统交互的效率,导致业务系统出现缓慢甚至无响应的情况发生。
        一般而言,出现大量TCP重传说明网络通讯的状况非常糟糕,需要站在网络层的角度分析丢包和重传的原因。
    Ø 在实际的分析过程中,我们如何确认一个TCP报文是重传报文
        在实际的数据交互过程中,重传报文一般具有以下两个特征:一是TCP交互序列号突然下降,二是其在TCP报头中的序列号、数据长度、应用数据等参数跟前面某TCP报文一致。
        1 序列号突然下降(一般是TCP重传)
        在TCP报文传输的过程中,因为其需要不断的交互应用数据,因此,TCP报文的序列号会不断的变大。正常情况下,TCP序列号不会出现下降的情况,出现序列号下降,一般都是TCP的重传报文导致的。如下图所示:
        在上图中,服务器端交互的TCP报文序列号从24481开始一直处于不断上升的趋势,但是服务器的第六个TCP报文序列号却突然下降为20161,这个情形,基本上可以肯定这第六个TCP报文是前面某个报文的重传报文。
        2 根据序列号、长度甚至应用数据等确认是哪一个报文的重传。
        在数据交互过程中,一般情况下,TCP重传的报文跟传输中被丢弃的报文在序列号、数据长度、应用字段值上都是一样的,我们可以利用这个特征来确定某个具体的TCP报文是否是前面某个报文的重传。下图是一个客户端存在重传的数据流图:
        在上图中,我们看到客户端第三个报文和第四个报文的序列号(Seq)、下一个序列号(Next Seq)以及载荷长度都是一样的,那么我们可以肯定客户端的第四个报文是客户端第三个报文的重传。
        现在很多的网络分析工具的专家诊断系统基本上都可以针对TCP重传直接告警,我们不需要在去深入分析这个过程了,为我们节省了大量的分析时间。

    更多相关内容
  • tcp 重传超时次数

    千次阅读 2021-05-12 08:09:08
    tcp 重传超时次数数据被重发以后若还是收不到应答, 则进行再次发送. 此时等待确认应答时间会以 2 倍, 4 倍的指数函数延长.此外, 数据也不会被无限, 反复的重发. 达到一定的重发次数之后, 如果仍然没有任何确认应答...

    tcp 重传超时次数

    数据被重发以后若还是收不到应答, 则进行再次发送. 此时等待确认应答时间会以 2 倍, 4 倍的指数函数延长.

    此外, 数据也不会被无限, 反复的重发. 达到一定的重发次数之后, 如果仍然没有任何确认应答返回, 就会判断为网络或者对端主机发生了异常, 强制关闭连接.

    Linux 的设置

    最小重传时间是 200ms

    最大重传时间是 120s

    重传次数为 15TCP retransmits an unacknowledged packet up to tcp_retries2 sysctl setting times(defaults to15)usingan exponential backoff timeoutforwhich each retransmission timeoutisbetween TCP_RTO_MIN(200ms)andTCP_RTO_MAX(120seconds).Oncethe15thretryexpires(bydefault),the TCP stack will notify the layers above(IE.App)ofa broken connection.

    ThevalueofTCP_RTO_MINandTCP_RTO_MAXishardcodedintheLinuxkernelanddefinedbythe following constants:

    #defineTCP_RTO_MAX((unsigned)(120*HZ))

    #defineTCP_RTO_MIN((unsigned)(HZ/5))

    Linux 2.6+ uses HZ of 1000ms, so TCP_RTO_MIN is ~200 ms and TCP_RTO_MAX is ~120 seconds. Given a default value of tcp_retries set to 15, it means that it takes 924.6 seconds before a broken network link is notified to the upper layer (IE. application), since the connection is detected as broken when the last (15th) retry expires.

    ab7653affab982b574eb7acc55df2e04.gifimage.PNGFromtheLinuxkernel doc

    tcp_retries2-INTEGER

    Thisvalueinfluences the timeoutofan alive TCP connection,

    when RTO retransmissions remain unacknowledged.GivenavalueofN,a hypothetical TCP connection following

    exponential backoffwithan initial RTOofTCP_RTO_MIN would

    retransmit N times before killing the connection at the(N+1)th RTO.

    Thedefaultvalueof15yields a hypothetical timeoutof924.6

    secondsandisa lower boundforthe effective timeout.

    TCP will effectively timeoutat the first RTO which exceeds the

    hypothetical timeout.

    RFC1122recommends at least100secondsforthe timeout,

    which corresponds to avalueofat least8.

    参考地址

    https://pracucci.com/linux-tcp-rto-min-max-and-tcp-retries2.html

    来源: http://www.jianshu.com/p/51d7f7fb3e4b

    展开全文
  • 一、什么是TCP重传? 在发送一个数据之后,就开启一个定时器,若是在这个时间内没有收到发送数据的ACK确认报文,则对该报文进行重传。 TCP重传率:重新发送信息的与全部的调用信息之间的比值。 二、TCP...

    一、什么是TCP重传?

    在发送一个数据之后,就开启一个定时器,若是在这个时间内没有收到发送数据的ACK确认报文,则对该报文进行重传。 

    TCP重传率:重新发送信息的与全部的调用信息之间的比值。

    二、TCP重传率高的可能原因

    发生重传说明网络传输有丢包,基本上从3个点去定位: 客户端网络情况、服务端网络情况、中间链路网络情况。

    1. 客户端机器网络异常

    2.服务端网卡流量跑满,网卡有丢包现象,关注ifconfig的error输出

    3.中间网络连路拥塞,比如交换机上联、核心交换机链路等,需要逐个排查链路流量情况

    三、数据包相关统计

    # netstat -s

    # which nstat

    # rpm -qf /usr/sbin/nstat

    iproute-4.11.0-14.el7.x86_64

    # nstat -a | grep -i Segs

    # cat /proc/net/snmp

    这些统计值反应的也是历史状态,独立的来看意义并不大。

    一般可统计一段时间内的变化,关注以下几个指标:

    1. (发送)TCP 分段重传占比:ΔRetransSegs / ΔOutSegs ;

    该值越小越好,如果超过 20% 则应该引起注意(这个值根据实际情况而定);

    2. (发送)RST 分段占比:ΔOutRsts / ΔOutSegs ;

    该值越小越好,一般应该在 1% 以内;

    3. (接收)错误分段占比:ΔInErrs / ΔInSegs ;

    该值越小越好,一般应该在 1% 以内,同时由 checksum 导致的问题包应该更低;

    # awk 'BEGIN {OFS=" "} $1 ~ /Tcp:/ && $2 !~ /RtoAlgorithm/ {print "InSegs\t",$11,"\nOutSegs\t",$12,"\nRetransSegs\t",$13,"\nPctReTrans\t",($13/$12*100)}' /proc/net/snmp

    四、重传率计算脚本

    #  check_tcp_retrans_rate.sh

    #########################################################

    #!/bin/bash

    awk 'BEGIN {OFS=" "} $1 ~ /Tcp:/ && $2 !~ /RtoAlgorithm/ {print "OutSegs\t",$12,"\nRetransSegs\t",$13}' /proc/net/snmp

    out_segs_1=`awk 'BEGIN {OFS=" "} $1 ~ /Tcp:/ && $2 !~ /RtoAlgorithm/ {print $12}' /proc/net/snmp`

    retrans_segs_1=`awk 'BEGIN {OFS=" "} $1 ~ /Tcp:/ && $2 !~ /RtoAlgorithm/ {print $13}' /proc/net/snmp`

    sleep 60

    out_segs_2=`awk 'BEGIN {OFS=" "} $1 ~ /Tcp:/ && $2 !~ /RtoAlgorithm/ {print $12}' /proc/net/snmp`

    retrans_segs_2=`awk 'BEGIN {OFS=" "} $1 ~ /Tcp:/ && $2 !~ /RtoAlgorithm/ {print $13}' /proc/net/snmp`

    out_segs=$((${out_segs_2} - ${out_segs_1}))

    retrans_segs=$((${retrans_segs_2} - ${retrans_segs_1}))

    tcp_retrans_rate=$(($retrans_segs/$out_segs))

    echo ${tcp_retrans_rate}

    #########################################################

    五、参考

    How passively monitor for tcp packet loss? (Linux)

    https://serverfault.com/questions/318909/how-passively-monitor-for-tcp-packet-loss-linux

    Linux/TCP 相关统计信息详解.md

    https://github.com/moooofly/MarkSomethingDown/blob/master/Linux/TCP%20%E7%9B%B8%E5%85%B3%E7%BB%9F%E8%AE%A1%E4%BF%A1%E6%81%AF%E8%AF%A6%E8%A7%A3.md

    Is there documentation for /proc/net/netstat and /proc/net/snmp?

    https://unix.stackexchange.com/questions/435579/is-there-documentation-for-proc-net-netstat-and-proc-net-snmp

    Linux性能监控 - CPU、Memory、IO、Network

    https://www.cnblogs.com/insane-Mr-Li/p/11209076.html

    Linux环境 网络流量统计/proc/net/dev和/proc/net/snmp

    https://blog.csdn.net/paradox_1_0/article/details/109175339

    Hands-on Guide for Linux /proc file and folders

    https://www.coding-bootcamps.com/linux/filesystem/proc.html

    Linux计算TCP重传率

    http://www.opstool.com/article/309

    https://s905060.gitbooks.io/site-reliability-engineer-handbook/content/linux_tcp_retransmission_rate_calculation.html

    /proc/net/snmp

    https://blog.titanwolf.in/a?ID=00500-531f4315-916d-41c1-a007-7d5a8649934f

    Checking for TCP/IP packet loss

    https://www.clouddirect.net/knowledge-base/KB0011163/checking-for-tcpip-packet-loss

    Linux network metrics: why you should use nstat instead of netstat

    https://loicpefferkorn.net/2016/03/linux-network-metrics-why-you-should-use-nstat-instead-of-netstat

    展开全文
  • TCP重传机制详解

    千次阅读 2022-04-11 09:38:57
    TCP针对数据包丢失的情况,采用重传机制解决 常见的重传机制: 超时重传 快速重传 SACK D-SACK 超时重传 超时重传:当发送数据时,设立一个定时器,当超过指定时间后,发送端没有收到ACK应答报文,则触发超时重传...

    本文提纲

    在这里插入图片描述

    重传机制

    TCP针对数据包丢失的情况,采用重传机制解决
    常见的重传机制:

    1. 超时重传
    2. 快速重传
    3. SACK
    4. D-SACK

    超时重传

    超时重传:当发送数据时,设立一个定时器,当超过指定时间后,发送端没有收到ACK应答报文,则触发超时重传机制,重发该数据

    超时时间设置为多少呢?也就是超时重传时间RTO

    假设我们设置的超时重传时间过短的话,那么就很有可能造成我们数据包还没到接收端或者应答ACK没到发送方就会重传:
    在这里插入图片描述
    假设我们设置超时时间过长的话,那么就会导致数据包丢失了一段花时间,我们才重传,减低了我们网络传输效率:
    在这里插入图片描述
    所以超时时间就应该设置为一个适中的值,那拿什么作为标准呢?
    首先我们清楚一个RTT(往返时延) 的概念
    在这里插入图片描述
    所以我们的超时时间RTO的值应该略大于报文往返 RTT 的值
    因为我们的网络是经常变化的,所以我们RTT报文往返时延也会动态变化,RTO时间也会动态变化

    定时器过期很可能是由网络拥塞引起的,在拥塞的时候,如果发送端持续重传分组,会使得拥塞越来越严重。相反,TCP采用的是发送端每次的重传都是经过越来越长的时间进行的。每当遇到一次超时重传的时候,都会将下一次超时时间间隔设为先前值的两倍。两次超时,就说明网络环境差,不宜频繁反复发送。

    超时重传存在的问题之一就是超时周期过长,当我们多次丢失数据包时,这种长周期的机制就会使我们延迟发送,加大了端到端的时延

    快速重传

    为了解决这种长周期情况,TCP通常可在超时时间发生之前通过冗余的ACK来较好的检测丢包情况
    在这里插入图片描述
    因为发送方经常一个接一个地发送大量的报文段,如果一个报文段丢失,就很可能引起许多一个接一个的冗余ACK,如果TCP发送方接收到对相同数据的3个冗余ACK,它 把这当作一种指示,说明跟在这个已被确认过3次的报文段之后的报文段已经丢失.一旦收到3个冗余ACK, TCP就执行快速重传(fast retransmit) [RFC 5681 ],即 在该报文段的定时器过期之前重传丢失的报文段

    事件:收到ACK,具有ACK字段值y
    if (y > SendBase) {
    SendBase=y
    if (当前仍无任何应答报文段)启动定时器 } 
    else {/★对已经确认的报文段的一个冗余ACK */
    	对y收到的冗余ACK数加1
    	if (对y==3收到的冗余ACK数)
    		/* TCP快速重传*/
    		重新发送具有序号y的报文段
    }
    break;
    

    快速重传机制只解决了一个问题,就是超时时间的问题,但是它依然面临着另外一个问题。就是重传的时候,是重传之前的一个,还是重传所有的问题。

    SACK

    针对上述情况,改进的方法就是 SACK(Selective Acknowledgment),这种方式需要在 TCP 头部「选项」字段里加一个 SACK 的东西,简单来讲就是在快速重传的基础上,返回最近收到的报文段的序列号范围,这样客户端就知道,哪些数据包已经到达服务器了。
    在这里插入图片描述
    如上图,发送方收到了三次同样的 ACK 确认报文,于是就会触发快速重发机制,通过 SACK 信息发现只有 200~299 这段数据丢失,则重发时,就只选择了这个 TCP 段进行重复。

    Duplicate SACK

    DSACK,即重复 SACK,这个机制是在 SACK 的基础上,额外携带信息,告知发送方有哪些数据包自己重复接收了。DSACK 的目的是帮助发送方判断,是否发生了包失序、ACK 丢失、包重复或伪重传。让 TCP 可以更好的做网络流控

    展开全文
  • 第10课 TCP重传技术的研究

    千次阅读 2022-03-27 17:22:03
    (1)TCP重传机制的必要性 当基于TCP的网络传输出现错误时,最基本的错误恢复方式就是重传数据包。这种机制专门被设计用来应对数据包丢失的情况(比如:路由器流量负载过重、应用程序出现故障或者临时性的网络中断...
  • TCP重传的进一步认识

    千次阅读 2019-06-03 14:44:08
    一、看图说话 1、基于套接字的TCP服务器/客户端程序流程 2、TCP三次握手建立连接 ...解释下MSL:最长分节生存周期,他代表了IP数据报载网络上的最长生命周期。...二、TCP重传 1、重传的原因 1)发...
  • Tcp重传

    千次阅读 2015-08-19 15:29:24
    Ø 为什么TCP存在重传 TCP是一种可靠的协议,在网络交互的过程中,由于TCP报文是封装在IP协议中的,IP协议的无连接特性导致其可能在交互的过程中丢失,在这种情况下,TCP协议如何保障其传输的可靠性呢? T C P...
  • TCP重传计时器浅析

    2014-05-29 14:10:15
    在一个TCP连接中,TCP每发送一个报文段, 就对此报文段设置一个超时重传计时器。 那么当发送多个报文段时,究竟有几个重传计时器?
  • TCP重传机制

    万次阅读 2018-09-18 21:47:57
    为保证数据传输的正确性,TCP重传其认为已丢失(包括报文中的比特错误)的包。TCP使用两套独立的机制来完成重传,一是基于时间,二是基于确认信息的构成。  第一种基于时间的重传在其下的数据链路层、网络层乃至...
  • TCP重传分析

    千次阅读 2017-09-15 10:52:53
    0x01 缘由  最近在结合linux tcp/ip协议栈,以及上层socket编程来进行相关学习,学习过程... tcp超时重传机制:https://baike.baidu.com/item/TCP%E8%B6%85%E6%97%B6%E9%87%8D%E4%BC%A0%E6%9C%BA%E5%88%B6/2122456?
  • TCP重传问题排查思路与实践

    千次阅读 2019-03-05 21:40:01
    一 关于TCP重传 TCP有重传是正常的机制,为了保障数据传输可靠性。只是局域网环境,网络质量有保障,因为网络问题出现重传应该极低;互联网或城域网环境,线路复杂(可以想象下城市地下管网,错综复杂的电线杆等),...
  • 1、关于TCP重传 TCP有重传是正常的机制,为了保障数据传输可靠性。只是局域网环境,网络质量有保障,因为网络问题出现重传应该极低;互联网或城域网环境,线路复杂(可以想象下城市地下管网,错综复杂的电线杆等)...
  • 物联网应用的关键技术之一就是要实现嵌入式设备的网络化,其中一种思路就是在...以嵌入式Web服务为例,紧紧围绕嵌入式Web服务器应用的具体要求,详细分析了如何设计并实现TCP重传队列。测试结果表明,该设计思路可行。
  • TCP重传率 重传率=重传报文数/有效报文数 其中有效报文数:指的是除了纯ACK包外的报文总数。 TCP重传率是对网络质量的一个体现。 计算 TCP重传率shell 脚本 简单包装netstat -s的输出可以计算出TCP重传...
  • 解决网络性能问题,首先从TCP错误恢复功能(TCP重传与重复ACK)和流控功能说起。之后阐述如何发现网络慢速之源。最后,对网络各组成部分上的数据流进行概况分析。这几张内容将会帮助读者识别,诊断,以及排查慢速...
  • TCP重传 滑动窗口 流量控制 拥塞控制 学习资源 小林coding 2022.4.7 重传机制 TCP实现可靠传输的方式之一 通过序列号与确认应答 TCP 当发送端的数据到达接受主机时 接收端主机回返回一个确认应答消息 表示已收到...
  • TCP重传与linux监控

    千次阅读 2020-01-05 11:45:36
    syn重传多少次后放弃 net.ipv4.tcp_syn_retries syn ack重传多少次后放弃 net.ipv4.tcp_synack_retries syn 包队列 net.ipv4.tcp_max_syn_backlog 重传统计 ss命令 ss -anti | grep -B 1 ...
  • 如何解决TCP重传、乱序和重复?

    千次阅读 2020-03-10 17:33:43
    TCP提供两种重传的机制,一种是基于时间的超时重传,一种是基于接收端反馈消息的快速重传。相比之下前者占用更少的网络带宽,但是效率很低。而后者则相反。下面我们来具体看一下这两种机制的实现方式。 超时重传 ...
  • Wireshark抓包实例分析TCP重传

    万次阅读 2017-08-09 18:56:38
    tcp重传机制
  • 如果你真的就看完了《packetdrill框架点滴剖析以及TCP重传的一个细节》,我觉得你应该有一个疑问,那就是RH发行版使用的2.6.32内核真的使用了PRR降窗算法吗?为此,我把故事再撸一遍。 按照标准的2.6.32内核,第一...
  • TCP超时重传次数

    2022-03-29 20:50:16
    sudo sysctl -a|grep retries查看TCP重传有关的内核参数值: 建立连接后的重传:超时重传,或者快速重传,如果收到三个冗余ACK,则表明极有可能数据丢失,则重传,此时拥塞窗口减半,如果没有收到三个冗余ACK,但是...
  • TCP重传率高的监控

    千次阅读 2016-12-21 10:43:00
    TCP重传率是对网络质量的一个体现,简单包装netstat -s的输出可以计算出TCP重传率。现成的脚本如下: #!/bin/bash export PATH='/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin' SHELLDIR="$( ...
  • TCP重传的次数和间隔时间

    万次阅读 2017-03-05 20:05:38
    第一次发送后所设置的超时时间...一共重传12次,大约9分钟才放弃重传,该时间在目前的TCP实现中是不可变的,Solaris2.2允许管理者改变这个时间,tcp_ip_abort_interval变量。且其默认值为两分钟,而不是最常用的9分钟。
  • TCP超时重传机制

    千次阅读 2021-06-23 10:33:39
    超时重传TCP协议保证数据可靠性的另一个重要机制,其原理是在发送某一个数据以后就开启一个计时器,在一定时间内如果没有得到发送的数据报的ACK报文,那么就重新发送数据,直到发送成功为止。[1]中文名TCP超时重传...
  • 最近在学习wireshark 看到一个挺有用的一个知识点,我的云服务器到我的客户机哪里总是出现tcp重传的问题,而且数量还挺大,又有带宽足够大所以业务上面看起来并没有感到什么异常情况,但是随着业务流量的逐渐增大,...
  • 前文论述了TCP基础知识,从本节开始,通过TCP抓包实例来诊断TCP常见问题。 TCP进程通讯时,双方打开连接,发送数据,最后关闭连接。当TCP打开连接时,从源端口到目的端口发送一个请求。在应用建立或关闭时可能发生...
  • 关于TCP重传、乱序和重复的问题

    千次阅读 2019-03-17 11:46:28
    TCP提供两种重传的机制,一种是基于时间的超时重传,一种是基于接收端反馈消息的快速重传。相比之下前者占用更少的网络带宽,但是效率很低。而后者则相反。下面我们来具体看一下这两种机制的实现方式。 超时重传 ...
  • Wireshark过滤掉TCP重传数据包

    万次阅读 2017-08-13 10:30:22
    Wireshark过滤TCP重传数据包 1. TCP Retransmission数据包是由于通讯超时产生的重传数据包,在网络性能差的情况下经常会看到这类数据包。因而使用Wireshark即可过滤或者显示这类数据包。 2. 先显示TCP重传...
  • tcp重传和udp视频传输

    千次阅读 2018-05-03 19:53:53
    udp : 视频重传目前是有 server端来控制.tcp重传时间和linux默认配置200ms : https://blog.csdn.net/q1007729991/article/details/70196099另外一篇佐证: ...-- I 帧,B帧,...
  • 重传时间分别为1s,2s,4s,8s,16s,以此类推。 理论依据是RFC 6298,RTO的初始值设定为1s 。参考2.1节内容:Until a round-trip time (RTT) measurement has been made for a segment s

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 107,924
精华内容 43,169
关键字:

tcp重传