精华内容
下载资源
问答
  • linux 丢包排查思路简述概述网络包接收流程网络包发送流程丢包排查的思路tcp排查方法rdma排查方法网络工具汇总参考链接 概述 我们首先以tcp网络为例,谈谈linux系统如何收发网络包 在进行网络传输时,数据包就会...


    概述

    我们首先以tcp网络为例,谈谈linux系统如何收发网络包

    网络收发包流程图

    在进行网络传输时,数据包就会按照协议栈,对上一层发来的数据进行逐层处理;然后封装上该层的协议头,再发送给下一层。

    • 传输层在应用程序数据前面增加了 TCP 头;
    • 网络层在 TCP 数据包前增加了 IP 头;
    • 而网络接口层,又在 IP 数据包前后分别增加了帧头和帧尾。

    这些新增的头部和尾部,都按照特定的协议格式填充,想了解具体格式,你可以查看协议的文档。

    比如,你可以查看这里,了解 TCP 头的格式。这些新增的头部和尾部,增加了网络包的大小,但我们都知道,物理链路中并不能传输任意大小的数据包。网络接口配置的最大传输单元(MTU),就规定了最大的 IP 包大小。在我们最常用的以太网中,MTU 默认值是 1500(这也是 Linux 的默认值)。一旦网络包超过 MTU 的大小,就会在网络层分片,以保证分片后的 IP 包不大于 MTU 值。显然,MTU 越大,需要的分包也就越少,自然,网络吞吐能力就越好。

    如下图所示,就是 Linux 通用 IP 网络栈的示意图:(图片参考《性能之巅》图 10.7 通用 IP 网络栈绘制)

    网络栈

    我们从上到下来看这个网络栈,可以发现,

    • 最上层的应用程序,需要通过系统调用,来跟套接字接口进行交互;
    • 套接字的下面,就是我们前面提到的传输层、网络层和网络接口层;
    • 最底层,则是网卡驱动程序以及物理网卡设备。

    网卡,作为发送和接收网络包的基本设备。在系统启动过程中,网卡通过内核中的网卡驱动程序注册到系统中。而在网络收发过程中,内核通过中断跟网卡进行交互。再结合前面提到的 Linux 网络栈,可以看出,网络包的处理非常复杂。所以,网卡硬中断只处理最核心的网卡数据读取或发送,而协议栈中的大部分逻辑,都会放到软中断中处理。(如果top时发现系统的si比较高,可以通过定位/proc/softirqs中增长较快的软中断从而定位问题。)

    理解了上述架构,我们就不难理解,为什么tcp的收发过程会牵涉到如下几个缓冲区:

    • 网卡收发网络包时,通过 DMA 方式交互的环形缓冲区
    • 网卡中断处理程序为网络帧分配的,内核数据结构 sk_buff 缓冲区
    • 应用程序通过套接字接口,与网络协议栈交互时的套接字缓冲区

    网络包接收流程

    1. 当一个网络帧到达网卡后,网卡会通过 DMA 方式,把这个网络包放到收包队列中;然后通过硬中断,告诉中断处理程序已经收到了网络包。
    2. 接着,网卡中断处理程序会为网络帧分配内核数据结构(sk_buff),并将其拷贝到 sk_buff 缓冲区中;然后再通过软中断,通知内核收到了新的网络帧。
    3. 接下来,内核协议栈从缓冲区中取出网络帧,并通过网络协议栈,从下到上逐层处理这个网络帧。比如,
      • 在链路层检查报文的合法性,找出上层协议的类型(比如 IPv4 还是 IPv6),再去掉帧头、帧尾,然后交给网络层。
      • 网络层取出 IP 头,判断网络包下一步的走向,比如是交给上层处理还是转发。当网络层确认这个包是要发送到本机后,就会取出上层协议的类型(比如 TCP 还是 UDP),去掉 IP 头,再交给传输层处理。
      • 传输层取出 TCP 头或者 UDP 头后,根据 < 源 IP、源端口、目的 IP、目的端口 > 四元组作为标识,找出对应的 Socket,并把数据拷贝到 Socket 的接收缓存中。
    4. 最后,应用程序就可以使用 Socket 接口,读取到新接收到的数据了。

    网络包发送流程

    了解网络包的接收流程后,就很容易理解网络包的发送流程。网络包的发送流程就是上图的右半部分,很容易发现,网络包的发送方向,正好跟接收方向相反。

    1. 首先,应用程序调用 Socket API(比如 sendmsg)发送网络包。由于这是一个系统调用,所以会陷入到内核态的套接字层中。套接字层会把数据包放到 Socket 发送缓冲区中。
    2. 接下来,网络协议栈从 Socket 发送缓冲区中,取出数据包;再按照 TCP/IP 栈,从上到下逐层处理。比如,传输层和网络层,分别为其增加 TCP 头和 IP 头,执行路由查找确认下一跳的 IP,并按照 MTU 大小进行分片。
    3. 分片后的网络包,再送到网络接口层,进行物理地址寻址,以找到下一跳的 MAC 地址。然后添加帧头和帧尾,放到发包队列中。这一切完成后,会有软中断通知驱动程序:发包队列中有新的网络帧需要发送。
    4. 最后,驱动程序通过 DMA ,从发包队列中读出网络帧,并通过物理网卡把它发送出去。

    丢包排查的思路

    理解了linux网络栈的原理,我们就不难去定位丢包问题,

    1. 如果是出向丢包,那么肯定是网络包发送流程出了问题,所以排查第一步是找到什么网络包出现了丢包重传。然后再根据网络包发送流程分析丢包原因
    2. 如果是入向丢包,那么肯定是网络包接收流程出了问题,常见的问题如网络缓冲器满了等

    关于丢包及其分析设计网络栈、内核栈的各个层面,笔者在也仅仅稍懂皮毛,欢迎读者踊跃补充。

    我们可以使用ifconfig可以查看网络丢包情况

    $ ifconfig net0
    net0: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST>  mtu 1500
            ether 98:03:9b:8c:63:3a  txqueuelen 1000  (Ethernet)
            RX packets 46725983  bytes 9200932091 (8.5 GiB)
            RX errors 0  dropped 48193  overruns 0  frame 0
            TX packets 127710842  bytes 127005910250 (118.2 GiB)
            TX errors 1  dropped 0 overruns 0  carrier 1  collisions 0
    
    • RX errors: 表示总的收包的错误数量,这包括 too-long-frames 错误,Ring Buffer 溢出错误,crc 校验错误,帧同步错误,fifo overruns 以及 missed pkg 等等。
    • RX dropped: 表示数据包已经进入了 Ring Buffer,但是由于内存不够等系统原因,导致在拷贝到内存的过程中被丢弃。
    • RX overruns: 表示了 fifo 的 overruns,这是由于 Ring Buffer(aka Driver Queue) 传输的 IO 大于 kernel 能够处理的 IO 导致的,而 Ring Buffer 则是指在发起 IRQ 请求之前的那块 buffer。很明显,overruns 的增大意味着数据包没到 Ring Buffer 就被网卡物理层给丢弃了,而 CPU 无法即使的处理中断是造成 Ring Buffer 满的原因之一
    • RX frame: 表示 misaligned 的 frames。

    对于 TX 的来说,出现上述 counter 增大的原因主要包括 aborted transmission, errors due to carrirer, fifo error, heartbeat erros 以及 windown error,而 collisions 则表示由于 CSMA/CD 造成的传输中断。

    droppedoverruns的区别:

    • dropped,表示这个数据包已经进入到网卡的接收缓存fifo队列,并且开始被系统中断处理准备进行数据包拷贝(从网卡缓存fifo队列拷贝到系统内存),但由于此时的系统原因(比如内存不够等)导致这个数据包被丢掉,即这个数据包被Linux系统丢掉。
    • overruns,表示这个数据包还没有被进入到网卡的接收缓存fifo队列就被丢掉,因此此时网卡的fifo是满的。为什么fifo会是满的?因为系统繁忙,来不及响应网卡中断,导致网卡里的数据包没有及时的拷贝到系统内存,fifo是满的就导致后面的数据包进不来,即这个数据包被网卡硬件丢掉。所以,个人觉得遇到overruns非0,需要检测cpu负载与cpu中断情

    tcp排查方法

    tcp丢包排查方法和工具集比较健全,手段也比较多,一般情况下,我们分析tcp丢包主要分析出向丢包重传,通过在出向丢包的服务器上抓包,找到出问题的网络包和对端服务器。

    这里仅举几个例子:

    1. 通过tcpdump抓包,然后使用wireshark使用过滤器tcp.analysis.retransmission找到重传的网络包。
      • wireshark抓重传包的原理是:由于tcp字段中没有重传相关的资源,因此wireshark通过扫描网络包中SEQ/ACK number, IP ID, source and destination IP address, TCP Port等字段,找到重复包,这些包就是丢包重传的包。
    2. tcpdump作为用户态进程,势必要消耗很多系统资源,如果丢包概率很低,丢包出现的时间也很短,使用tcpdump往往会无功而返,Brendan Gregg依托eBPF开发出了轻量级的tcp重传抓取工具: tcpretrans(包含在bcc工具集中)。这个工具它只抓取所有重传的包,具体的原理是借助Linux Kernel的ftrace机制在tcp_retransmit_skb这个函数加了一个hook来获取重传包的skb地址,然后以这个skb的地址作为hash key去/proc/net/tcp这个文件里面匹配tcp连接信息,然后把发生重传的这个tcp连接的信息(time,src,sport,dst,dport,state)给打印出来。由于它只抓取该服务器发出的重传包,所以它的系统开销是很小的,我们完全可以把它部署到服务器上一直运行着去抓包。

    rdma排查方法

    目前我遇到的系统(mlx cx4/cx5/cx6),在rdma上主要的指标是入向丢包(out_of_order),其根因有如下几种情况:

    1. 入向丢包服务器的rdma网卡缓冲区拥塞,单凭ecn已经无法限制流量,因此网卡产生出向pfc,伴随有可能产生入向丢包。有关pfc可以查看笔者之前的文章 浅谈RDMA流控设计
    2. Roce 2网络链路上dscp配置出错,RDMA流量跑到了其他的网卡队里里,而其他的队列有可能是lossy模式,不能保证无损转发,因此导致丢包。排查步骤如下:
      • 打开roce v2的tcpdump支持ethtool --set-priv-flags net0 sniffer on(注意,使用完成之后记得关闭ethtool --set-priv-flags net0 sniffer off
      • 使用tcpdump进行抓包,在wireshark中使用过滤器ip.dsfield.dscp,过滤出dscp错误的rdma包。如果存在,说明有dscp入错队列的rdma流量。
        • 也可以在抓包的时候使用参数过滤,如:tcpdump -i net2 '(ip and (ip[1] & 0xfc) >> 2 != 46)' -w rdma_retrans.pcap,该语句过滤掉了dscp等于46的网络包。
      • 抓到包后我们就知道了问题流量的src和dest在哪里,我们可以通过perftest(如ib_send_bw)工具打流确认。

    网络工具汇总

    tcp

    tcp工具集

    rdma

    RoCE/RDMA Tools

    参考链接

    1. 在Wireshark的tcptrace图中看清TCP拥塞控制算法的细节(CUBIC/BBR算法为例)
    2. Wireshark tcptrace图关于丢包重传细节图解
    3. Linux服务器丢包故障的解决
    4. tcp retransmission抓包分析_Wireshark | 1. 网络抓包分析的利器
    5. tcpretrans
    6. How-To Dump RDMA Traffic Using the Inbox tcpdump tool (ConnectX-4 and above)
    7. Graphing Packet Retransmission Rates with Wireshark tcp.analysis.retransmission
    8. Using TCPDUMP to Filter on DSCPtcpdump -i eth0 (ip and (ip[1] & 0xfc) >> 2 == 20) -vvv
    9. Understanding mlx5 Linux Counters and Status Parameters
    10. Understanding mlx5 ethtool Counters
    11. Nak Errors
    展开全文
  • linux丢包问题排查

    2019-11-15 11:06:27
    linux机器上面发现请求接口经常失败,通过查看系统日志发现经常丢失。 系统日志:tail -fn100 /var/log/messages 出现: Nov 15 11:06:08 www kernel: nf_conntrack: table full, dropping packet Nov 15 ...

    在linux机器上面发现请求接口经常失败,通过查看系统日志发现包经常丢失。

     

    系统日志: tail -fn100 /var/log/messages

     

    出现:

    Nov 15 11:06:08 www kernel: nf_conntrack: table full, dropping packet
    Nov 15 11:06:09 www kernel: nf_conntrack: table full, dropping packet
    Nov 15 11:06:09 www kernel: nf_conntrack: table full, dropping packet
    Nov 15 11:06:09 www kernel: nf_conntrack: table full, dropping packet
    Nov 15 11:06:09 www kernel: nf_conntrack: table full, dropping packet
    Nov 15 11:06:09 www kernel: nf_conntrack: table full, dropping packet
    Nov 15 11:06:09 www kernel: nf_conntrack: table full, dropping packet
    Nov 15 11:06:09 www kernel: nf_conntrack: table full, dropping packet
    Nov 15 11:06:09 www kernel: nf_conntrack: table full, dropping packet
    Nov 15 11:06:09 www kernel: nf_conntrack: table full, dropping packet

     

    参数详细介绍博客:

    https://testerhome.com/topics/7509

    展开全文
  • 项目开了个P2P服务器,但是运行一段时间就会出现丢包问题,具体表现为:1、udp丢包严重(一分钟收发分别1.5W) 2、ssh(用于运维指令)连接不上该服务器(超时) 3、服务器运行好像没什么异常,udp假连接数比tcp...

    项目开了个P2P服务器,但是运行一段时间就会出现丢包问题,具体表现为:
    1、udp丢包严重(一分钟收发分别1.5W)

    2、ssh(用于运维指令)连接不上该服务器(超时)

    3、服务器运行好像没什么异常,udp假连接数比tcp连接数少(正常应该相近)

     


     

    首先开始怀疑是不是客户端有bug,查log发现某段时间有个别客户端发大量心跳包,开始怀疑这个原因导致服务异常。在多次关服开服后没出现这个问题,但是服务器运行一段时间依旧出现上述异常,排除这个原因。

     


     

    既然不是客户端导致的。。

    就开始在自身找原因,接着怀疑是不是最大连接数、最大文件打开数,查了一下服务器设置:

     ulimit -n  //可以打开最大文件描述符的数量

    65536

     

    ulimit -a  //显示当前所有的 limit 信息

    time(seconds) unlimited
    file(blocks) unlimited
    data(kbytes) unlimited
    stack(kbytes) 8192
    coredump(blocks) unlimited
    memory(kbytes) unlimited
    locked memory(kbytes) 64
    process 516037
    nofiles 65536
    vmemory(kbytes) unlimited
    locks unlimited

     

    cat /proc/sys/fs/nr_open  //单进程最大文件限制

    1048576

     

    cat /proc/sys/fs/file-max  //系统最大文件限制

    6605234

     

    再看下服务器现在相关信息:

    lsof -n  //查看服务器文件打开数信息

     

    ps -aef  //进程信息

     

    发现无论是文件描述符打开数还是文件打开数都没超标---陷入僵局。


     

    觉得应该是系统某个设置不当导致的,但是又无从查起,查 /car/log/messages 里面的信息应该能查到点端倪,可是没权限。(dmesg  命令好像可以查看)

    后来咨询其他小组,发现他们也遇到过一样的问题,问题来自于跟踪连接表的限制----nf_conntrack/ip_conntrack。

     

     理解nf_conntrack和调整nf_conntrack_max :nf_conntrack 工作在 层,支持 IPv4 和 IPv6,而 ip_conntrack 只支持 IPv4

     

    目前,大多的 ip_conntrack_* 已被 nf_conntrack_* 取代,很多 ip_conntrack_* 仅仅是个 alias,原先的 ip_conntrack 的 /proc/sys/net/ipv4/netfilter/ 依然存在,但是新的 nf_conntrack 在 /proc/sys/net/netfilter/ 中,这个应该是做个向下的兼容。

     

    nf_conntrack/ip_conntrack 跟 nat 有关,用来跟踪连接条目,它会使用一个哈希表来记录 established 的记录。nf_conntrack 在 2.6.15 被引入,而 ip_conntrack 在 2.6.22被移除,如果该哈希表满了,就会出现问题来。

     

    查看系统默认跟踪连接表限制:

    cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max  //最大
    cat /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established   //保存时间

     

    cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count  //当前

     

    查看了以后,发现运行一段时间后 跟踪连接表的确是满了,导致文章开始所述的情况出现,而 ip_conntrack_max 有个建议值:

    CONNTRACK_MAX = RAMSIZE(in bytes)/16384/(ARCH/32),如32G内存可以设置1048576

     

    临时修改该值:

    echo 1048576> /proc/sys/net/ipv4/netfilter/ip_conntrack_max

     

    p2p服务器重启后运行恢复正常。


     

     

    参考引用:

    http://itoedr.blog.163.com/blog/static/120284297201451013130868/

    http://www.cnblogs.com/276815076/p/5736272.html

    http://www.sdnlab.com/17530.html

    转载于:https://www.cnblogs.com/GO-NO-1/p/7324502.html

    展开全文
  • 网络丢包排查思路

    千次阅读 2020-03-18 18:28:56
    网络丢包排查思路 1.防火墙确认:看防火墙是否配置了DROP特定端口范围的可能性 方法:查看iptables filter表,确认是否有相应规则会导致此丢包行为,命令:sudoiptables-save-tfilter 2.连接跟踪表溢出 除了防火墙...

    网络丢包排查思路


    1.防火墙确认:

    看防火墙是否配置了DROP特定端口范围的可能性
    方法:查看iptables filter表,确认是否有相应规则会导致此丢包行为,命令: sudo iptables-save -t filter

    2.连接跟踪表溢出


    除了防火墙本身配置DROP规则外,与防火墙有关的还有连接跟踪表nf_conntrack,Linux为每个经过内核网络栈的数据包,生成一个新的连接记录项,当服务器处理的连接过多时,连接跟踪表被打满,服务器会丢弃新建连接的数据包。
    1)问题确认:通过dmesg可以确认是否有该情况发生:
        命令:dmesg |grep nf_conntrack,如果输出值中有“nf_conntrack: table full, dropping packet”,说明服务器nf_conntrack表已经被打满。
    通过/proc文件系统查看nf_conntrack表实时状态:
    # 查看nf_conntrack表最大连接数
    $ cat /proc/sys/net/netfilter/nf_conntrack_max
    65536
    # 查看nf_conntrack表当前连接数
    $ cat /proc/sys/net/netfilter/nf_conntrack_count
    7611
    2)解决办法:如果确认服务器因连接跟踪表溢出而开始丢包,首先需要查看具体连接判断是否正遭受DOS攻击,如果是正常的业务流量造成,可以考虑调整nf_conntrack的参数:
    nf_conntrack_max决定连接跟踪表的大小,默认值是65535,可以根据系统内存大小计算一个合理值:CONNTRACK_MAX = RAMSIZE(in bytes)/16384/(ARCH/32),如32G内存可以设置1048576;
    nf_conntrack_buckets决定存储conntrack条目的哈希表大小,默认值是nf_conntrack_max的1/4,延续这种计算方式:BUCKETS = CONNTRACK_MAX/4,如32G内存可以设置262144;
    nf_conntrack_tcp_timeout_established决定ESTABLISHED状态连接的超时时间,默认值是5天,可以缩短到1小时,即3600。
    命令行配置:
    $ sysctl -w net.netfilter.nf_conntrack_max=1048576
    $ sysctl -w net.netfilter.nf_conntrack_buckets=262144
    $ sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=3600

    3.Ring Buffer溢出


    排除了防火墙的因素,我们从底向上来看Linux接收数据包的处理过程,首先是网卡驱动层。
    物理介质上的数据帧到达后首先由NIC(网络适配器)读取,写入设备内部缓冲区Ring Buffer中,再由中断处理程序触发Softirq从中消费,Ring Buffer的大小因网卡设备而异。当网络数据包到达(生产)的速率快于内核处理(消费)的速率时,Ring Buffer很快会被填满,新来的数据包将被丢弃。
           1)判断方法:通过ethtool或/proc/net/dev可以查看因Ring Buffer满而丢弃的包统计,在统计项中以fifo标识:
    $ ethtool -S eth0|grep rx_fifo
        rx_fifo_errors: 0
    $ cat /proc/net/dev
        Inter-|   Receive                                                |  Transmit
    可以看到服务器的接收方向的fifo丢包数并没有增加,说明此阶段不存在丢包。
         2)如果是,解决办法:
    如果发现服务器上某个网卡的fifo数持续增大,可以去确认CPU中断是否分配均匀,也可以尝试增加Ring Buffer的大小,通过ethtool可以查看网卡设备Ring Buffer最大值,修改Ring Buffer当前设置:
    查看eth0网卡Ring Buffer最大值和当前设置
    $ ethtool -g eth0
    Ring parameters for eth0:
     
    Pre-set maximums:
    RX:     4096  
    RX Mini:    0
    RX Jumbo:   0
    TX:     4096  
    Current hardware settings:
    RX:     1024  
    RX Mini:    0
    RX Jumbo:   0
    TX:     1024  
    # 修改网卡eth0接收与发送硬件缓存区大小
    $ ethtool -G eth0 rx 4096 tx 4096
    Pre-set maximums:
    RX:     4096  
    RX Mini:    0
    RX Jumbo:   0
    TX:     4096  
    Current hardware settings:
    RX:     4096  
    RX Mini:    0
    RX Jumbo:   0
    TX:     4096


    4.netdev_max_backlog溢出


    netdev_max_backlog是内核从NIC收到包后,交由协议栈(如IP、TCP)处理之前的缓冲队列。每个CPU核都有一个backlog队列,与Ring Buffer同理,当接收包的速率大于内核协议栈处理的速率时,CPU的backlog队列不断增长,当达到设定的netdev_max_backlog值时,数据包将被丢弃。
          
    1)判断方法: 通过查看/proc/net/softnet_stat可以确定是否发生了netdev backlog队列溢出:
    其中:


        每一行代表每个CPU核的状态统计,从CPU0依次往下;
    每一列代表一个CPU核的各项统计:第一列代表中断处理程序收到的包总数;第二列即代表由于netdev_max_backlog队列溢出而被丢弃的包总数。
    从上面的输出可以看出,这台服务器统计中,并没有因为netdev_max_backlog导致的丢包。
    2)解决办法
    netdev_max_backlog的默认值是1000,在高速链路上,可能会出现上述第二列统计不为0的情况,可以通过修改内核参数net.core.netdev_max_backlog来解决:
        sysctl -w net.core.netdev_max_backlog=2000

    5.反向路由过滤

    反向路由过滤机制是Linux通过反向路由查询,检查收到的数据包源IP是否可路由(Loose mode)、是否最佳路由(Strict mode),如果没有通过验证,则丢弃数据包,设计的目的是防范IP地址欺骗攻击。rp_filter提供了三种模式供配置:
    0 - 不验证
    1 - RFC3704定义的严格模式:对每个收到的数据包,查询反向路由,如果数据包入口和反向路由出口不一致,则不通过
    2 - RFC3704定义的松散模式:对每个收到的数据包,查询反向路由,如果任何接口都不可达,则不通过
    1)如何确认
    查看当前rp_filter策略配置:
    $ cat /proc/sys/net/ipv4/conf/eth0/rp_filter
    0
    如果这里设置为1,就需要查看主机的网络环境和路由策略是否可能会导致客户端的入包无法通过反向路由验证了。
    从原理来看这个机制工作在网络层,因此,如果客户端能够Ping通服务器,就能够排除这个因素了。
    2)如何解决
    根据实际网络环境将rp_filter设置为0或2:
    $ sysctl -w net.ipv4.conf.all.rp_filter=2
     或
     $ sysctl -w net.ipv4.conf.eth0.rp_filter=2


    6.半连接队列溢出

    半连接队列指的是TCP传输中服务器收到SYN包但还未完成三次握手的连接队列,队列大小由内核参数tcp_max_syn_backlog定义。
    当服务器保持的半连接数量达到tcp_max_syn_backlog后,内核将会丢弃新来的SYN包。
    1)如何确认
    通过dmesg可以确认是否有该情况发生:
    $ dmesg | grep "TCP: drop open request from"
    半连接队列的连接数量可以通过netstat统计SYN_RECV状态的连接得知
    2)如何解决
    tcp_max_syn_backlog的默认值是256,通常推荐内存大于128MB的服务器可以将该值调高至1024,内存小于32MB的服务器调低到128,同样,该参数通过sysctl修改:netstat -ant|grep SYN_RECV|wc -l
    sysctl -w net.ipv4.tcp_max_syn_backlog=1024
    另外,上述行为受到内核参数tcp_syncookies的影响,若启用syncookie机制,当半连接队列溢出时,并不会直接丢弃SYN包,而是回复带有syncookie的SYC+ACK包,设计的目的是防范SYN Flood造成正常请求服务不可用。


     

    展开全文
  • 跟踪内核丢包排查

    2019-12-05 10:00:34
    跟踪内核丢包排查 问题背景 unaForwardKernel 转发udp 丢包 结论 192.168.1.2 > 192.168.1.25 > 192.168.1.201 25 上的unaForwardKernel在Pre-routing 将源地址改为了25,过不了反向路由查找: 25 > 201 ...
  • 失败的丢包排查

    2021-01-28 22:24:10
    一 背景有时候,需要关注下网络的是否丢包,特别是高带宽情况下测试系统的性能的时候, 这次我们在测试很小的流量的情况下,用ifconfig命令查看发现丢包:watchifconfige...
  •   tcp协议中,序号(seq,ack)的作用是保证连接的可靠和数据包的有序,但现实中往往会出现丢包,或者某些包迷路。例如序列号为s1的包A 因为网络问题没有到达,客户端重发s1包B,但因为带宽足够,在一次回话中,...
  • 问题这两天ffmpeg推流的同事反应服务器推送视频流到A直播云的直播播放某个时间段经常卡顿排查 mtr的使用在末尾 同一台服务器将视频流分别推送到B云直播、A直播云对比播放流畅度,B直播云播放流畅,判断:问题不在推...
  • Udp丢包排查过程

    万次阅读 2015-12-23 10:25:27
    1. 查看udp丢包,cat /...2. 查看网卡丢包(ifconfig 或者ethtool –S eth1) 3. Netstat –alupt 查看队列里现存的包数,如果过多说明有问题。 4. 查看socket队列长度,cat /proc/sys/net/core/rmem_default (wmem_def
  • 这次想分享的话题是比较常见服务器网卡丢包现象排查思路,如果你是想了解点对点的丢包解决思路涉及面可能就比较广,不妨先参考之前的文章如何使用 MTR 诊断网络问题,对于 Linux 常用的网卡丢包分析工.
  • Linux 丢包分析

    2020-12-01 10:08:13
    最近工作中遇到某个服务器应用程序 UDP 丢包,在排查过程中查阅了很多资料,总结出来这篇文章,供更多人参考。 在开始之前,我们先用一张图解释 linux 系统接收网络报文的过程。 首先网络报文通过物理网线发送到...
  • 本文分享了iptable防火墙状态异常导致丢包排查记录,这个排查过程非常曲折,最后使用了在现在的作者看来非常落伍的工具:systemtap,才得以排查成功。其实依作者现有的经验,此问题现在仅需一条命令即可找到原因,...
  • Table of Contents 1. 了解接收数据包的流程 将网卡收到的数据包转移到主机内存(NIC 与驱动交互) 通知系统内核处理(驱动与 Linux 内核交互)...4. 丢包排查思路 先查看硬件情况 overruns 和 buffer size Red H
  • 管理网CVM和CVK之间走的管理网尝试ping不丢包。主机和虚拟机状态都是正常的。尝试从虚拟机”windows 2008R2 test”(172.16.12.254)向虚拟机”linux test”(172.16.12.249)持续ping,然后在对应CVK和vnet口进行抓包。...
  • 丢包继续排查

    2021-02-03 22:36:25
    上次没查到根本原因,这次继续排查,发现和我们发的有很大的关系,根据上次rx_drop的含义,的数据可能是以下几种原因:Thesoftnetbacklogfull BadVLAN...
  • udp丢包问题排查

    2021-02-01 20:47:47
    背景: 类似于实时语音转译文本的产品,录音软件将客户端的语音流推送至后台服务,由后端服务转译后推送至客户端界面,后端服务使用到了redis,但是不和...后端服务排查发现,录音软件推送过来的udp有丢失问题..
  • Linux服务器性能排查

    2019-03-17 23:16:25
    TCP重传可能是因为网络环境恶劣,或者服务器压力过大导致丢包。 #####top top命令包含了前面好几个命令的检查的内容。比如系统负载情况(uptime)、系统内存使用情况(free)、系统CPU使用情况(vmstat)等。因此...
  • 虚拟机丢包问题排查处理

    千次阅读 2019-08-02 15:49:00
    同一台物理机上的多台虚拟机同时出现应用服务超时、无法访问等现象,ping虚拟机和物理机丢包严重。 故障原因 物理机上某台虚拟机建立了大量连接,导致物理机连接追踪表被大量ESTABLISHED连接记录塞满,进而出现...
  • linux 系统 UDP 丢包问题分析思路

    千次阅读 2018-01-18 10:54:18
    https://www.tuicool.com/articles/7ni2yyr最近工作中遇到某个服务器应用程序 UDP 丢包,在排查过程中查阅了很多资料,总结出来这篇文章,供更多人参考。在开始之前,我们先用一张图解释 linux 系统接收网络报文的...
  • Linux服务器丢包故障的解决

    千次阅读 2020-12-10 11:31:13
    我们使用Linux作为服务器操作系统时,为了达到高并发处理能力,充分利用机器性能,经常会进行一些内核参数的调整优化,但不合理的调整常常也会引起意想不到的其他问题,本文就一次Linux服务器丢包故障的处理过程,...
  • 通过dropwatch定位系统内核丢包 Finding out if/why a server is dropping packets github source coed: pavel-odintsov/drop_watch How to drop a packet in Linux in more ways than one 试试Linux下的ip命令...
  • linux UDP丢包问题分析

    2019-12-05 22:25:17
    linux 系统 UDP 丢包问题分析思路 www.cnblogs.com2018/01/13 转自:http://cizixs.com/2018/01/13/linux-udp-packet-drop-debug?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io 最近工作...
  • 简介事情是这样的,我买了一个newifi路由器,之后准备将家里的网络重新部署一下,所以就把我的蜗牛星际停了,之后把网络从以前的极路由连接到newifi下,突然发现丢包严重,而且不是一般的严重,几乎丢包率达到70%...
  • Linux入侵排查

    2021-07-27 14:28:42
    Linux入侵排查 0x00 前言 当企业发生黑客入侵、系统崩溃或其它影响业务正常运行的安全事件时,急需第一时间进行处理,使企业的网络信息系统在最短时间内恢复正常工作,进一步查找入侵来源,还原入侵事故过程,同时给...
  • linux运维故障排查

    2020-07-09 11:25:30
    网络 网络的监测是所有 Linux 子系统里面最复杂的,有太多的因素在里面,比如:延迟、阻塞、冲突、丢包等,更糟的是与 Linux 主机相连的路由器、交换机、无线信号都会影响到整体网络并且很难判断是因为 Linux 网络子...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 3,407
精华内容 1,362
关键字:

linux丢包排查

linux 订阅