作为开发对网络的疑问
1，带宽是什么？
2，丢包问题如何排查？
3，如何衡量网络性能好坏，你平时需要关注网络的哪些指标呢？
概念模型
带宽是什么
带宽是网络包被发送的能力，会受到网卡复制网络包到内核缓冲区或者搬运内核缓冲区的网络包到网卡缓冲区的能力影响，也会受到接收窗口，拥塞窗口的影响。
如果对端接收能力变弱，那么带宽也不能提升上去。
当网络链路变长以后，网络的情况就及其复杂，因为可能网络包会经过多个路由器乃至不同运营商之间进行数据交换，而不同代理商之间的网络流量又是及其庞大的，可能会导致你的网络包产生丢包或者重发的状况。
网络包收发过程
如何衡量网络情况的好坏
- 从系统层面看网络
几个重要的指标
MBS 每秒多少个MB字节
Mbps 每秒多少个M比特位
换算关系 MBS = Mbps / 8
网卡流入流出的流量 Mbps Gbps
每秒收发包的数量 pps
丢包数
使用sar每1秒统计一次网络接口的活动状况，连续显示5次。
sar -n DEV 1 5
03:05:31 PM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s
03:05:32 PM eth0 3.00 1.00 0.26 0.20 0.00 0.00 0.00
03:05:32 PM lo 138.00 138.00 40.56 40.56 0.00 0.00 0.00
IFACE：网络接口名称。
rxpck/s、txpck/s：每秒收或发的数据包数量。
rxkB/s、txkB/s：每秒收或发的字节数，以kB/s为单位。
rxcmp/s、txcmp/s：每秒收或发的压缩过的数据包数量。
rxmcst/s：每秒收到的多播数据包。
- 从进程角度看
更多的时候其实不是系统网络达到瓶颈，而是进程处理网络包的能力跟不上。
能够列出每一条连接的Mbps 找出哪个ip消耗流量最多
iftop -P
查看进程占用带宽情况
sudo nethogs eth0
go tool trace 能分析出程序由于网络调度带来的延迟问题，找出网络延迟最高的一块代码。
如何查找丢包问题
应用层
内核在监听套接字的时候，在三次握手时，会创建两个队列，在服务器收到syn 包时，会创建半连接队列，并将这条未完成的连接 放到里面，然后回复ack，syn包给客户端，当客户端回复ack时，内核会将这条连接放到全连接队列里，调用accept就是将连接从全连接队列里取出。
如果半连接队列或者全连接队列满了，则可能发生丢包行为。
半连接队列大小由内核参数tcp_max_syn_backlog定义。
sysctl -w net.ipv4.tcp_max_syn_backlog=1024
另外，上述行为受到内核参数tcp_syncookies的影响，若启用syncookie机制，当半连接队列溢出时，并不会直接丢弃SYN包，而是回复带有syncookie的SYC+ACK包，设计的目的是防范SYN Flood造成正常请求服务不可用。
sysctl -w net.ipv4.tcp_syncookies=1
如何确认
dmesg | grep "TCP: drop open request from"
netstat -ant|grep SYN_RECV|wc -l
全连接队列大小
ss 命令可以查看全连接队列大小
# -l 显示正在监听
# -n 不解析服务名称
# -t 只显示 tcp socket
$ ss -lnt
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 50 *:2181 *:*
LISTEN 0 32768 127.0.0.1:9200 *:*
LISTEN 0 32768 192.168.0.233:9200 *:*
Recv-Q：当前全连接队列的大小，也就是当前已完成三次握手并等待服务端 accept() 的 TCP 连接；
Send-Q：当前全连接最大队列长度，上面的输出结果说明监听 8088 端口的 TCP 服务，最大全连接长度为 128；
listen 的全连接大小可以在listen系统调用的时候指定。
go源码里读取的是 /proc/sys/net/core/somaxconn 里的值。
# -n 不解析服务名称
# -t 只显示tcp socket
$ ss -nt
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 0 192.168.0.233:27266 192.168.0.129:3306
ESTAB 0 0 192.168.0.233:30212 192.168.0.129:3306
ESTAB 0 0 192.168.0.233:8000 100.125.64.81:44948
Recv-Q：已收到但未被应用进程读取的字节数；
Send-Q：已发送但未收到确认的字节数；
当全连接队列满了后，默认内核会将包丢弃，但是也可以指定其他策略。
cat /proc/sys/net/ipv4/tcp_abort_on_overflow
0
0 ：如果全连接队列满了，那么 server 扔掉 client 发过来的 ack ；
1 ：如果全连接队列满了，server 发送一个 reset 包给 client，表示废掉这个握手过程和这个连接；
传输层
除了防火墙本身配置DROP规则外，与防火墙有关的还有连接跟踪表nf_conntrack，Linux为每个经过内核网络栈的数据包，生成一个新的连接记录项，当服务器处理的连接过多时，连接跟踪表被打满，服务器会丢弃新建连接的数据包。
# 查看nf_conntrack表最大连接数
$ cat /proc/sys/net/netfilter/nf_conntrack_max
65536
# 查看nf_conntrack表当前连接数
$ cat /proc/sys/net/netfilter/nf_conntrack_count
7611
网络层，物理层
netstat 可以统计网路丢包以及环形缓冲区溢出
root@nginx:/# netstat -i
Kernel Interface table
Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 100 157 0 344 0 94 0 0 0 BMRU
lo 65536 0 0 0 0 0 0 0 0 LRU
netstat 查看网络协议层丢包
root@nginx:/# netstat -s
Ip:
Forwarding: 1 //开启转发
31 total packets received //总收包数
0 forwarded //转发包数
0 incoming packets discarded //接收丢包数
25 incoming packets delivered //接收的数据包数
15 requests sent out //发出的数据包数
Icmp:
0 ICMP messages received //收到的ICMP包数
0 input ICMP message failed //收到ICMP失败数
ICMP input histogram:
0 ICMP messages sent //ICMP发送数
0 ICMP messages failed //ICMP失败数
ICMP output histogram:
Tcp:
0 active connection openings //主动连接数
0 passive connection openings //被动连接数
11 failed connection attempts //失败连接尝试数
0 connection resets received //接收的连接重置数
0 connections established //建立连接数
25 segments received //已接收报文数
21 segments sent out //已发送报文数
4 segments retransmitted //重传报文数
0 bad segments received //错误报文数
0 resets sent //发出的连接重置数
Udp:
0 packets received
...
TcpExt:
11 resets received for embryonic SYN_RECV sockets //半连接重置数
0 packet headers predicted
TCPTimeouts: 7 //超时数
TCPSynRetrans: 4 //SYN重传数
...
mtu的设置有时可能导致丢包的产生，如果发送的mtu包的大小超过网卡规定的大小，并且网卡不允许分片，那么则会产生丢包。