精华内容
下载资源
问答
  • 2020-12-29 07:39:05

    在一台suse linux上使用tcpdump命令抓包,出现“packets dropped by kernel”,一般造成这种丢包的原因是libcap抓到包后,tcpdump上层没有及时取出,导致libcap缓冲区溢出,从而覆盖了未处理包,显示为dropped by kernel,这里的kernel并不是说是被linux内核抛弃的,而是被tcpdump的内核,即libcap抛弃掉。

    解决方法:

    根据以上分析,可以通过改善tcpdump上层的处理效率来减少丢包率,下面的几步根据需要选用,每一步都能减少一定的丢包率。

    1.最小化抓取过滤范围,即通过指定网卡,端口,包流向,包大小减少包数量

    2. 添加-n参数,禁止反向域名解析

    tcpdump -i eth0 dst port 1234 and udp -s 2048 -n -X -tt >a.pack

    大多数情况这样就可以解决

    可以通过改善tcpdump上层的处理效率来减少丢包率

    3. 将数据包输出到cap文件

    tcpdump -i eth0 dst port 1234 and udp -s 2048 -n -X -tt -w a.cap

    4. 用sysctl修改SO_REVBUF参数,增加libcap缓冲区长度

    更多相关内容
  • Linux下实现测试TCP和UDP的丢包检测!疯狂の猿猴•2020 年 12 月 11 日前言本人平时基本上都是win,一下子转战到linux,有点不习惯!因此做个记录,便于以后自己查阅,同时也作为分享给大家参考!大佬,请绕路! 工具挨个...

    在Linux下实现测试TCP和UDP的丢包检测!

    疯狂の猿猴 • 2020 年 12 月 11 日

    前言

    本人平时基本上都是win,一下子转战到linux,有点不习惯!

    因此做个记录,便于以后自己查阅,同时也作为分享给大家参考!

    大佬,请绕路! 工具挨个介绍!

    本人的系统环境 CentOS7.6

    工具Tcpping 介绍

    测试网络延迟最常用方法是使用ping工具,它使用ICMP协定。在某些情况下ICMP是被防火墙阻挡,这使得Ping在这情况下是无法使用的。

    此时为了能够继续监控的话,就必需使用TCP / UDP的方式,TCPPING为更容易绕过普通的防火墙规则的第3层测试工具。

    这样的一个第3层的测试工具TCPPING 。

    为了测量延迟, TCPPING采取所谓的半开连接技术,基于TCP三次握手的优势。

    也就是说,它发送一个TCP SYN包的端口号(默认为80 )远程主机。如果远程主机正在侦听的端口,它会响应的TCP ACK数据包。否则,它会响应的TCP RST包。无论哪种方式, TCPPING可以测量往返时间远程主机( RTT)的延迟,通过定时传出SYN数据包和输入的ACK (或RST )数据包。

    相同的半开连接技术已经实现了tcptraceroute工具。

    所以TCPPING只是依靠tcptraceroute执行延迟测量。

    为了TCPPING安装在Linux上,你首先需要安装tcptraceroute和bc,然后从下载TCPPING脚本。

    安装tcptraceroute和bcyum -y install tcptraceroute bc

    下载tcppingcd /usr/bin

    wget http://www.vdberg.org/~richard/tcpping

    chmod +x tcpping

    命令使用tcpping www.123admin.com 80

    测试UDP监听协议

    如果您的全球加速配置的监听协议是UDP协议,您可以通过UDPing测试全球加速的加速效果,UDPing使用特定的端口号将UDP ping发送到特定的IP地址。

    本文以终端节点服务器和客户端都为CentOS系统为例,介绍如何通过UDPing测试UDP监听协议的网络加速效果。

    下载UDPing工具wget https://networktools-public.oss-cn-hangzhou.aliyuncs.com/ga/udping/udping.py

    赋予UDPing工具执行权限。chmod +x udping.py

    命令使用./udping.py

    以上是测试网络延迟的方法,下面是查看指定端口 TCP和UDP端口是否打开的工具版权属于:疯狂的猿猴

    本站文章采用 知识共享署名4.0 国际许可协议 进行许可,请在转载时注明出处及本声明!

    展开全文
  • 如何分析linux tcp/ip 丢包问题

    千次阅读 2020-09-15 21:25:11
    通过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命令...

    引用


    一. 如何查看自己的网卡丢包情况

    1. proc文件系统

    1.1 dev: 查看各net device的统计信息

    root@spc:/home/vec/dev_document/dropwatch/drop_watch/src# cat /proc/net/dev
    Inter-|   Receive                                                |  Transmit
     face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
        lo:   29142     323    0    0    0     0          0         0    29142     323    0    0    0     0       0          0
    wlp3s0: 35148233   39485    0 1226    0     0          0         0  4937381   36609    0    0    0     0       0          0
    enp4s0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
    

    1.2 softnet_stat: 查看各CPU下的backlog统计信息

    root@spc:/home/vec/dev_document/dropwatch/drop_watch/src# cat /proc/net/softnet_stat
    000001b0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    00000094 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    00009a0f 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    00000089 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    
    注:
    seq_printf(seq,
           "%08x %08x %08x %08x %08x %08x %08x %08x %08x %08x %08x\n",
           sd->processed, sd->dropped, sd->time_squeeze, 0,
           0, 0, 0, 0, /* was fastroute */
           sd->cpu_collision, sd->received_rps, flow_limit_count);
    
    Each line of /proc/net/softnet_stat corresponds to a struct softnet_data structure, of which there is 1 per CPU.
     
    The values are separated by a single space and are displayed in hexadecimal
    
    The first value, sd->processed, is the number of network frames processed. This can be more than the total
     number of network frames received if you are using ethernet bonding. There are cases where the ethernet
     bonding driver will trigger network data to be re-processed, which would increment the sd->processed count
     more than once for the same packet.
     
    The second value, sd->dropped, is the number of network frames dropped because there was no room on the
     processing queue. More on this later.
     
    The third value, sd->time_squeeze, is (as we saw) the number of times the net_rx_action loop terminated
     because the budget was consumed or the time limit was reached, but more work could have been. Increasing
     the budget as explained earlier can help reduce this.
     
    The next 5 values are always 0.
    
    The ninth value, sd->cpu_collision, is a count of the number of times a collision occurred when trying to
     obtain a device lock when transmitting packets. This article is about receive, so this statistic will not be seen below.
     
    The tenth value, sd->received_rps, is a count of the number of times this CPU has been woken up to process
     packets via an Inter-processor Interrupt
     
    The last value, flow_limit_count, is a count of the number of times the flow limit has been reached.
     Flow limiting is an optional Receive Packet Steering feature that will be examined shortly.
    

    ------
    默认每个cpu的backlog是1000。
    当netdev driver使用的非NAPI或开启了RPS时,就会用到backlog。
    当进行高tput测试时,可以查看是否有在backlog这里丢包。

    root@spc:/home/vec/dev_document/dropwatch/drop_watch/src# sysctl net.core.netdev_max_backlog
    net.core.netdev_max_backlog = 1000

    ------

    1.3 snmp: 查看各层协议的收发信息

    root@spc:/home/vec/dev_document/dropwatch/drop_watch/src# cat /proc/net/snmp
    Ip: Forwarding DefaultTTL InReceives InHdrErrors InAddrErrors ForwDatagrams InUnknownProtos InDiscards InDelivers OutRequests OutDiscards OutNoRoutes ReasmTimeout ReasmReqds ReasmOKs ReasmFails FragOKs FragFails FragCreates
    Ip: 2 64 42966 0 2 0 0 0 40770 50253 20 0 0 0 0 0 0 0 0
    Icmp: InMsgs InErrors InCsumErrors InDestUnreachs InTimeExcds InParmProbs InSrcQuenchs InRedirects InEchos InEchoReps InTimestamps InTimestampReps InAddrMasks InAddrMaskReps OutMsgs OutErrors OutDestUnreachs OutTimeExcds OutParmProbs OutSrcQuenchs OutRedirects OutEchos OutEchoReps OutTimestamps OutTimestampReps OutAddrMasks OutAddrMaskReps
    Icmp: 40 0 0 40 0 0 0 0 0 0 0 0 0 0 40 0 40 0 0 0 0 0 0 0 0 0 0
    IcmpMsg: InType3 OutType3
    IcmpMsg: 40 40
    Tcp: RtoAlgorithm RtoMin RtoMax MaxConn ActiveOpens PassiveOpens AttemptFails EstabResets CurrEstab InSegs OutSegs RetransSegs InErrs OutRsts InCsumErrors
    Tcp: 1 200 120000 -1 38 11 2 0 3 39093 49237 386 0 22 0
    Udp: InDatagrams NoPorts InErrors OutDatagrams RcvbufErrors SndbufErrors InCsumErrors IgnoredMulti
    Udp: 1196 40 0 594 0 0 0 576
    UdpLite: InDatagrams NoPorts InErrors OutDatagrams RcvbufErrors SndbufErrors InCsumErrors IgnoredMulti
    UdpLite: 0 0 0 0 0 0 0 0
    

    2. ifconfig

    root@spc:/home/vec/dev_document/dropwatch/drop_watch/src# ifconfig
    enp4s0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
            ether 30:85:a9:2a:48:06  txqueuelen 1000  (Ethernet)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    ----
    注:
    /net/core/dev.c
    
    struct rtnl_link_stats64 *dev_get_stats(struct net_device *dev,
    					struct rtnl_link_stats64 *storage)
    {
    	const struct net_device_ops *ops = dev->netdev_ops;
    
    	/* 网卡有注册  ndo_get_stats64该函数*/
    	if (ops->ndo_get_stats64) {
    		memset(storage, 0, sizeof(*storage));
    		ops->ndo_get_stats64(dev, storage);
    
    	/* 网卡有注册 ndo_get_stats 该函数*/
    	} else if (ops->ndo_get_stats) {
    		netdev_stats_to_stats64(storage, ops->ndo_get_stats(dev));
    
    	/* 直接通过 dev->stats 获取, 该结构正在被遗弃。*/
    	} else {
    		netdev_stats_to_stats64(storage, &dev->stats);
    	}
    
    	/* 即 这里还要加上 kernel drop的packet - /net/core/dev.c 。 
           1. enqueue_to_backlog(): 当backlog不够时。atomic_long_inc(&skb->dev->rx_dropped)
    (同时也会更新 sd->dropped++)
           2. __netif_receive_skb_core() -- 不认识的packet。atomic_long_inc(&skb->dev->rx_dropped);
        */
    	storage->rx_dropped += (unsigned long)atomic_long_read(&dev->rx_dropped);
    	storage->tx_dropped += (unsigned long)atomic_long_read(&dev->tx_dropped);
    	storage->rx_nohandler += (unsigned long)atomic_long_read(&dev->rx_nohandler);
    	return storage;
    }

    3. ip

    root@spc:/home/vec/dev_document/dropwatch/drop_watch/src# ip -s -s link ls enp4s0
    2: enp4s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
        link/ether 30:85:a9:2a:48:06 brd ff:ff:ff:ff:ff:ff
        RX: bytes  packets  errors  dropped overrun mcast
        0          0        0       0       0       0
        RX errors: length   crc     frame   fifo    missed
                   0        0       0       0       0
        TX: bytes  packets  errors  dropped carrier collsns
        0          0        0       0       0       0
        TX errors: aborted  fifo   window heartbeat transns
                   0        0       0       0       1
    

    4.netstat

    4.1 查看各网卡的netdev统计信息

    root@spc:/home/vec/dev_document/dropwatch/drop_watch/src# netstat -i
    Kernel Interface table
    Iface      MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
    enp4s0    1500        0      0      0 0             0      0      0      0 BMU
    lo       65536      327      0      0 0           327      0      0      0 LRU
    wlp3s0    1500    41520      0   1434 0         40349      0      0      0 BMRU
    

    4.2 查看特定协议(例如.UDP)的统计信息

    root@spc:/home/vec/dev_document/dropwatch/drop_watch/src# netstat -su
    IcmpMsg:
        InType3: 40
        OutType3: 40
    Udp:
        1159 packets received
        40 packets to unknown port received
        0 packet receive errors
        576 packets sent
        0 receive buffer errors
        0 send buffer errors
        IgnoredMulti: 468
    UdpLite:
    IpExt:
        InMcastPkts: 370
        OutMcastPkts: 83
        InBcastPkts: 728
        OutBcastPkts: 77
        InOctets: 34596737
        OutOctets: 3791474
        InMcastOctets: 147789
        OutMcastOctets: 9349
        InBcastOctets: 311773
        OutBcastOctets: 13116
        InNoECTPkts: 39035
    

    5.ethtool

    root@spc:/home/vec/dev_document/dropwatch/drop_watch/src# ethtool -S enp4s0
    NIC statistics:
         tx_packets: 0
         rx_packets: 0
         tx_errors: 0
         rx_errors: 0
         rx_missed: 0
         align_errors: 0
         tx_single_collisions: 0
         tx_multi_collisions: 0
         unicast: 0
         broadcast: 0
         multicast: 0
         tx_aborted: 0
         tx_underrun: 0
    

    二. 如何分析和解决丢包问题

    1. 扩大协议栈相关buffer

    ### KERNEL TUNING ###
    
    # Increase size of file handles and inode cache
    fs.file-max = 2097152
    
    # Do less swapping
    vm.swappiness = 10
    vm.dirty_ratio = 60
    vm.dirty_background_ratio = 2
    
    # Sets the time before the kernel considers migrating a proccess to another core
    kernel.sched_migration_cost_ns = 5000000
    
    # Group tasks by TTY
    #kernel.sched_autogroup_enabled = 0
    
    ### GENERAL NETWORK SECURITY OPTIONS ###
    
    # Number of times SYNACKs for passive TCP connection.
    net.ipv4.tcp_synack_retries = 2
    
    # Allowed local port range
    net.ipv4.ip_local_port_range = 2000 65535
    
    # Protect Against TCP Time-Wait
    net.ipv4.tcp_rfc1337 = 1
    
    # Control Syncookies
    net.ipv4.tcp_syncookies = 1
    
    # Decrease the time default value for tcp_fin_timeout connection
    net.ipv4.tcp_fin_timeout = 15
    
    # Decrease the time default value for connections to keep alive
    net.ipv4.tcp_keepalive_time = 300
    net.ipv4.tcp_keepalive_probes = 5
    net.ipv4.tcp_keepalive_intvl = 15
    
    ### TUNING NETWORK PERFORMANCE ###
    
    # Default Socket Receive Buffer
    net.core.rmem_default = 31457280
    
    # Maximum Socket Receive Buffer
    net.core.rmem_max = 33554432
    
    # Default Socket Send Buffer
    net.core.wmem_default = 31457280
    
    # Maximum Socket Send Buffer
    net.core.wmem_max = 33554432
    
    # Increase number of incoming connections
    net.core.somaxconn = 65535
    
    # Increase number of incoming connections backlog
    net.core.netdev_max_backlog = 65536
    
    # Increase the maximum amount of option memory buffers
    net.core.optmem_max = 25165824
    
    # Increase the maximum total buffer-space allocatable
    # This is measured in units of pages (4096 bytes)
    net.ipv4.tcp_mem = 786432 1048576 26777216
    net.ipv4.udp_mem = 65536 131072 262144
    
    # Increase the read-buffer space allocatable
    net.ipv4.tcp_rmem = 8192 87380 33554432
    net.ipv4.udp_rmem_min = 16384
    
    # Increase the write-buffer-space allocatable
    net.ipv4.tcp_wmem = 8192 65536 33554432
    net.ipv4.udp_wmem_min = 16384
    
    # Increase the tcp-time-wait buckets pool size to prevent simple DOS attacks
    net.ipv4.tcp_max_tw_buckets = 1440000
    net.ipv4.tcp_tw_recycle = 1
    net.ipv4.tcp_tw_reuse = 1

    2. 可能性

    2.1 防火墙拦截

    root@spc:~# iptables -L -n
    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination
    
    Chain FORWARD (policy ACCEPT)
    target     prot opt source               destination
    
    Chain OUTPUT (policy ACCEPT)
    target     prot opt source               destination
    

    2.2 连接跟踪表溢

    root@spc:/# conntrack -S
    cpu=0           found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    cpu=1           found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    cpu=2           found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    cpu=3           found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    cpu=4           found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    cpu=5           found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    cpu=6           found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    cpu=7           found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    cpu=8           found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    cpu=9           found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    cpu=10          found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    cpu=11          found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    cpu=12          found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    cpu=13          found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    cpu=14          found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    cpu=15          found=0 invalid=0 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
    
    注:
    除了防火墙本身配置DROP规则外,与防火墙有关的还有连接跟踪表nf_conntrack,Linux为每个经过内核网络
    栈的数据包,生成一个新的连接记录项,当服务器处理的连接过多时,连接跟踪表被打满,服务器会丢弃新建连
    接的数据包。
    
    如何确认:
    通过dmesg可以确认是否有该情况发生:如果输出值中有“nf_conntrack: table full, dropping 
    packet”,说明服务器nf_conntrack表已经被打满。
    
    通过conntrack工具或/proc文件系统查看nf_conntrack表实时状态:在本案例中,当前连接数远没有达到跟
    踪表最大值,因此排除这个因素。
    
    如何解决:
    如果确认服务器因连接跟踪表溢出而开始丢包,首先需要查看具体连接判断是否正遭受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
    

    2.3 网卡设备的ring buffer溢出(网卡driver的统计)

    如何确认:
    通过 ifconfig/ifconfig/ip/ethtool, /proc/net/dev等可以查看drop包的数量。
    
    如何解决:
    通过调整网卡driver中的相关buffer
    

    2.4 netdev_max_backlog溢出

    通过 /proc/net/softnet_stat 可查看溢出信息。
    
    netdev_max_backlog是内核从NIC收到包后,交由协议栈(如IP、TCP)处理之前的缓冲队列。每个CPU核都有一
    个backlog队列,与Ring Buffer同理,当接收包的速率大于内核协议栈处理的速率时,CPU的backlog队列不断
    增长,当达到设定的netdev_max_backlog值时,数据包将被丢弃。
    
    如何确认:
    通过查看/proc/net/softnet_stat可以确定是否发生了netdev backlog队列溢出。其中:
    每一行代表每个CPU核的状态统计,从CPU0依次往下
    每一列代表一个CPU核的各项统计:第一列代表中断处理程序收到的包总数;第二列即代表由于
    netdev_max_backlog队列溢出而被丢弃的包总数
    
    如何解决:
    netdev_max_backlog的默认值是1000,在高速链路上,可能会出现上述第二列统计不为0的情况,可以适当调大
    内核参数net.core.netdev_max_backlog到2000来解决。

    2.5 反向路由过滤

    root@spc:/# sysctl -a | grep rp_filter
    net.ipv4.conf.all.arp_filter = 0
    net.ipv4.conf.all.rp_filter = 2
    net.ipv4.conf.default.arp_filter = 0
    net.ipv4.conf.default.rp_filter = 2
    net.ipv4.conf.enp4s0.arp_filter = 0
    net.ipv4.conf.enp4s0.rp_filter = 2
    net.ipv4.conf.lo.arp_filter = 0
    net.ipv4.conf.lo.rp_filter = 0
    net.ipv4.conf.wlp3s0.arp_filter = 0
    net.ipv4.conf.wlp3s0.rp_filter = 2
    
    
    注:
    反向路由过滤机制是Linux通过反向路由查询,检查收到的数据包源IP是否可路由(Loose mode)、是否最佳
    路由(Strict mode),如果没有通过验证,则丢弃数据包,设计的目的是防范IP地址欺骗攻击。rp_filter提供了三种模式供配置:
    
    0 - 不验证
    1 - RFC3704定义的严格模式:对每个收到的数据包,查询反向路由,如果数据包入口和反向路由出口不一致,则不通过
    2 - RFC3704定义的松散模式:对每个收到的数据包,查询反向路由,如果任何接口都不可达,则不通过
    
    查看和配置:sysctl -a | grep rp_filter 
    关于rp_filter :https://www.cnblogs.com/lipengxiang2009/p/7446388.html
    
    如何确认:
    查看当前rp_filter策略配置,如果设置为1,就需要查看主机的网络环境和路由策略是否可能会导致客户端的入包无法通过反向路由验证。
    
    从原理来看这个机制工作在网络层,因此,如果客户端能够Ping通服务器,就能够排除这个因素了。
    
    解决办法:
    1.修改路由表,使响应数据包从eth1出,即保证请求数据包进的网卡和响应数据包出的网卡为同一个网卡。
    2.关闭rp_filter参数。(注意all和default的参数都要改)
    1)修改/etc/sysctl.conf文件,然后sysctl -p刷新到内存。
    2)使用sysctl -w直接写入内存:sysctl -w net.ipv4.conf.all.rp_filter=0
    3)修改/proc文件系统: echo "0">/proc/sys/net/ipv4/conf/all/rp_filter

    2.6 半连接队列溢出

    半连接队列指的是TCP传输中服务器收到SYN包但还未完成三次握手的连接队列,队列大小由内核参数tcp_max_syn_backlog定义。
    当服务器保持的半连接数量达到tcp_max_syn_backlog后,内核将会丢弃新来的SYN包。
    
    如何确认:
    通过dmesg可以确认是否有该情况发生:如果输出值中有“TCP: drop open request from”,说明半连接队列已
    被打满。
    半连接队列的连接数量可以通过netstat统计SYN_RECV状态的连接得知。大多数情况下这个值应该是0或很小,因
    为半连接状态从第一次握手完成时进入,第三次握手完成后退出,正常的网络环境中这个过程发生很快,如果这个
    值较大,服务器极有可能受到了SYN Flood攻击。
    
    如何解决:
    tcp_max_syn_backlog的默认值是256,通常推荐内存大于128MB的服务器可以将该值调高至1024,内存小于32MB
    的服务器调低到128,同样,该参数通过sysctl修改。
    另外,上述行为受到内核参数tcp_syncookies的影响,若启用syncookie机制,当半连接队列溢出时,并不会直
    接丢弃SYN包,而是回复带有syncookie的SYC+ACK包,设计的目的是防范SYN Flood造成正常请求服务不可用。
    

    2.7 PAWS :内核参数/proc/sys/net/ipv4/tcp_tw_recycle 控制

    PAWS全名Protect Againest Wrapped Sequence numbers,目的是解决在高带宽下,TCP序列号在一次会话中可能被重复使用而带来的问题

    3. dropwatch

    root@spc:/home/vec/dev_document/dropwatch/drop_watch/src# sudo ./dropwatch -l kas
    Initalizing kallsyms db
    dropwatch> start
    Enabling monitoring...
    Kernel monitoring activated.
    Issue Ctrl-C to stop monitoring
    9 drops at __init_scratch_end+1243f1ee (0xffffffffc083f1ee)
    1 drops at __netif_receive_skb_core+14f (0xffffffffac73612f)
    4 drops at __init_scratch_end+1243f1ee (0xffffffffc083f1ee)
    9 drops at __init_scratch_end+1243f1ee (0xffffffffc083f1ee)
    4 drops at __init_scratch_end+1243f1ee (0xffffffffc083f1ee)
    2 drops at __init_scratch_end+1243f1ee (0xffffffffc083f1ee)
    1 drops at __netif_receive_skb_core+14f (0xffffffffac73612f)
    4 drops at __init_scratch_end+1243f1ee (0xffffffffc083f1ee)
    4 drops at __init_scratch_end+1243f1ee (0xffffffffc083f1ee)
    5 drops at __init_scratch_end+1243f1ee (0xffffffffc083f1ee)
    4 drops at __init_scratch_end+1243f1ee (0xffffffffc083f1ee)
    1 drops at __netif_receive_skb_core+14f (0xffffffffac73612f)
    1 drops at ip_rcv_finish_core.isra.0+1b2 (0xffffffffac7affa2)
    ^CGot a stop message
    dropwatch>
    

    4. perf

    sudo perf record -g -a -e skb:kfree_skb
    sudo perf script

    展开全文
  • 故障排查:早上突然收到nagios服务器check_icmp的报警,报警显示一台网站服务器的...首先使用ping 内网IP的方式查看内网的连通性,ping的过程中出现丢包现象,信息如下:64 bytes from 10.1.1.1: icmp_seq=34 ttl=...

    故障排查:

    早上突然收到nagios服务器check_icmp的报警,报警显示一台网站服务器的内网网络有问题。因为那台服务器挂载了内网的NFS,因此内网的网络就采用nagios的check_icmp来做监控。

    赶紧登录服务器进行排查。首先使用ping 内网IP的方式查看内网的连通性,ping的过程中出现丢包现象,信息如下:

    64 bytes from 10.1.1.1: icmp_seq=34 ttl=255 time=0.928 ms

    64 bytes from 10.1.1.1: icmp_seq=35 ttl=255 time=1.01 ms

    ping: sendmsg: Operation not permitted

    ping: sendmsg: Operation not permitted

    显示ping不被允许,奇怪,防火墙上明明开通了icmp的协议。有问题先看日志,日志文件一般会有所记录,tail –f /var/log/messages,发现大量的如下内容:

    Sep 13 09:11:21 dowload_server1 kernel: printk: 261 messagessuppressed.

    Sep 13 09:11:21 dowload_server1 kernel: ip_conntrack: table full,dropping packet

    发现是当前会话数已经满了,因此出现丢包现象。这里对ip_conntrack做一下简单的介绍:IP_conntrack表示连接跟踪数据库(conntrack database),代表NAT机器跟踪连接的数目,连接跟踪表能容纳多少记录是被一个变量控制的,它可由内核中的ip-sysctl函数设置。每一个跟踪连接表会占用350字节的内核存储空间,时间一长就会把默认的空间填满,那么默认空间是多少?在内存为64MB的机器上是4096,内存为128MB是8192,内存为256MB是16384

    通过如下命令查看当前的会话数:

    cat /proc/net/ip_conntrack | wc –l    不要用,占CPU

    或者使用:

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

    使用如下命令查看设置的最大会话数

    cat /proc/sys/net/ipv4/ip_conntrack_max

    解决办法:

    发现确实已经达到了最大会话数,通过google发现,可以直接调大用户的最大会话数,命令为:

    echo "102400" > /proc/sys/net/ipv4/ip_conntrack_max

    执行此命令后,不在丢包了,ping也正常了。但是这样设置不会永久保存,当系统重启后设置会丢失,因此需要保存到/etc/sysctl.conf,在/etc/sysctl.conf中加入:net.ipv4.ip_conntract_max =102400,然后执行/sbin/sysctl –p刷新内核参数即可,如果出现error:"net.ipv4.ip_conntract_max" is an unknown key报错的话,需要加载ip_conntract模块,使用modprobe  ip_conntrack加载,使用lsmod | grepip_conntrack查看模块是否加载。

    终极解决:

    为了使彻底解决此问题,还需要再设置一个东西,那就是会话连接超时变量,这个参数设置太长的话就会导致会话连接数不断增加,默认是设置为432000秒,很显然这个值太大了,通过如下命令设置小一点:

    echo 21600>/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established

    设置成21600也就是6小时,这样会自动清除6小时候后的无效链接。记得将这句话加到自动启动文件/etc/rc.local文件中去。

    展开全文
  • linux tcp之三次握手】
  • Linux UDP严重丢包问题的解决,linuxudp丢包测试系统在Linux上的性能发现丢包率极为严重,发210000条数据,丢包达110000之巨,丢包率超过50%。同等情形下Windows上测试,仅丢几条数据。形势严峻,必须解决。考虑可能...
  • iperf测UDP和TCP丢包率及带宽

    千次阅读 2021-09-01 16:22:40
    master$ iperf3 -s //tcp和udp服务器端用iperf3的话都是这个命令,如果是udp,在客户端加上-u即可 //如果是iperf,tcp和udp在服务器端加-u,tcp和udp的客户端命令相同 Server listening on 5201 (test #1) 安装 方法...
  • Linux下UDP丢包问题分析思路

    千次阅读 2021-05-18 01:58:44
    下面我们就来分析一下丢包发生的原因以及解决办法1.linux 系统接收网络报文的过程接收数据包是一个复杂的过程,涉及很多底层的技术细节,但大致需要以下几个步骤:网卡收到数据包。将数据包从网卡硬件缓存转移到...
  • 使用ifconfig命令,ifconfig是最常用的配置和查看网络接口信息的命令,服务器上执行此命令会得到类下文的内容,一下内容可看到多个设备和设备状态、信息。 # 不包括down状态的网卡 ifconfig #查看所有网卡的...
  • tcp三次握手丢包后会发生什么

    千次阅读 2022-02-27 21:03:53
    测试工具 本片文章会用到以下工具来学习tcp三次握手: tcpdup,一个运行在用户态的应用程序,它本质上...iptables,也是一个运行在用户态的应用程序,底层用的内核模块netfilter,是一个linux防火墙,我们用它来模拟三
  • 故障排查:早上突然收到nagios服务器check_icmp的报警,报警显示一台网站服务器的...首先使用ping 内网IP的方式查看内网的连通性,ping的过程中出现丢包现象,信息如下:64 bytes from 10.1.1.1: icmp_seq=34 ttl=...
  • 服务器网卡丢包

    2021-05-15 01:54:35
    有时会发生网络丢包现象,此处的丢包有两种,真正意义上的丢包和逻辑丢包(此处以tcp协议栈丢包为例)。之前falcon-agent也上报了相应的指标,在此处对一些疑问给出尽量详细的解释。二、linux系统pakcet接收的过程过程...
  • linux网络udp和tcp

    千次阅读 2022-03-17 20:30:18
    超时重传机制 32位序号(解决乱序问题 + 去重) 32位确认序号(解决丢包问题) 为什么一个header要同时有序号和确认序号(重点) tcp缓冲区 16位窗口大小 标志位 内核tcpheader源代码 tcp连接管理机制 三次握手 四次...
  • LinuxTCP协议的特点

    千次阅读 2022-02-23 21:06:22
    TCP协议的特点
  • 作为一款功能强大的网络流量控制工具,TC可以控制网络带宽、丢包率、延时等网络参数,使我们能够在网络环境良好的局域网中模拟出各种复杂的网络场景。 二、 TC的工作原理 操作系统处理网络数据的基本流程如下:...
  • Linux UDP严重丢包问题的解决

    千次阅读 2016-09-20 11:19:35
    测试系统在Linux上的性能发现丢包率极为严重,发210000条数据,丢包达110000之巨,丢包率超过50%。同等情形下Windows上测试,仅丢几条数据。形势严峻,必须解决。考虑可能是因为协议栈Buffer太低所致,于是先看看...
  • 出现的问题主要体现在几个点:①:服务器间歇性 NodeNotReady②:服务器丢包极为严重③:服务器网络非常慢,以至于在服务器上执行 curl youku.com 都要响应很久。Istio的遥测组件,是一个服务,由Istio的Ingress以及...
  • ActiveMQ之Mqtt的TCP丢包

    千次阅读 2018-09-13 14:26:21
    现象 Mqtt Consumer应该收到的消息少于预期,登录ActiveMQ...怀疑是TCP丢包,通过netstat -s命令观察发送消息前后Tcp信息的输出 对比两次Tcp信息的输出,发现packets pruned from receive queue because of socke...
  • Ubuntu下配置网络时延、丢包、带宽等,可应用于容器内。
  • 239-Linux TCP协议和UDP协议

    千次阅读 2022-03-09 11:12:13
    1.TCP 协议提供的是:面向连接、可靠的、字节流服务。...使用 tcpdump 可以抓观察 TCP 连接的建立与关闭。该命令需要管理员权限,格式如下(假设两个测试用的主机 IP 地址为 192.168.43.214 和 192.168.43.160 )
  • linux系统内核UDP丢包原因分析1、UDP校验和错误现象:可以用netstat -su 查看到有UDP错包。tcpdump捕包,在wireshark打开捕获的udp报文,开启校验和选项,有错包。方案:查找链路故障 www.ahlinux.com2、防火墙开启...
  • 网络环境:1000M,直连,多网卡系统:Linux version 3.19.0接收模式:udp模式的raw socket(优化的话,可以直接通过网卡处理)发送模式:udp模式的raw socket(优化的话,可以直接通过网卡处理),单线程/多线程2M...
  • 先说结论:执行了如下的命令后,问题解决。 之前nf_conntrack_max的值是65536sysctl -w net.netfilter.nf_conntrack_max=358576参考:Linux服务器丢包故障的解决思路及引申的TCP/IP协议栈理论...
  • Netem 是 Linux 2.6 及以上内核版本提供的一个网络模拟功能模块,该功能模块可以用来在性能良好的局域网中,模拟出复杂的互联网传输性能,诸如低带宽、传输延迟、丢包等等情况。使用 Linux 2.6 (或以上) 版本内核的...
  • 最近工作中遇到某个服务器应用程序 UDP 丢包,在排查过程中查阅了很多资料,我在排查过程中基本都是通过使用 tcpdump 在出现问题的各个环节上进行抓包、分析在那个环节出现问题、针对性去排查解决问题,对症下药,...
  • 最近工作中遇到某个服务器应用程序 UDP 丢包,在排查过程中查阅了很多资料,总结出来这篇文章,供更多人参考。 在开始之前,我们先用一张图解释 linux 系统接收网络报文的过程。 首先网络报文通过物理网线发送到...
  • 主要是判定丢包 丢在个哪一个阶段 MAC与PHY 通信的 QSGMII 总线上 PHY 的 utp 端口 MDI 线路上 1、phy utp internel boopback 内部回环模式,验证QSGMII 和 MAC 之间的通信质量 可以通过下面的配置将phy ...
  • [linux] tc netem 模拟网络丢包linux下的tc可以操纵网络,比如分配带宽给不同的应用、模拟网络时延、模拟糟糕网络环境下的丢包等。但在实际使用模拟丢包时,我们 发现了问题:两台服务器,一台跑tcp的server,一台跑...
  • Linux tcp拥塞控制

    2020-11-27 22:20:18
    1、滑动窗口 滑动窗口是发送方根据接收方的接收窗口来控制发送速率的手段,接收发的滑动窗口可分成以下四个部分,最左边...紫色区域最右边的值对应tcp的snd_una,蓝色最左侧对应tcp的snd_next;在数据包传输过程中,sn

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 15,643
精华内容 6,257
热门标签
关键字:

linux tcp 丢包命令