netstat -p protocol （原文出处）

netstat -p protocol 显示了有关为 protocol 变量所指定的值（udp、tcp、ip、icmp）的统计信息，该变量可以是协议的通用名称，也可以是其别名。

在 /etc/protocols 文件中列示了一些协议名称和它们的代名。一个空响应表明，没有要报告的数据。如果没有统计程序，那么协议参量指定值的程序报告就是不可知的。

下面的示例显示的是 ip 协议的输出：

# netstat -p ip
ip:
                45775 total packets received
                0 bad header checksums
                0 with size smaller than minimum
                0 with data size < data length
                0 with header length < data size
                0 with data length < header length
                0 with bad options
                0 with incorrect version number
                0 fragments received
                0 fragments dropped (dup or out of space)
                0 fragments dropped after timeout
                0 packets reassembled ok
                45721 packets for this host
                51 packets for unknown/unsupported protocol
                0 packets forwarded
                4 packets not forwardable
                0 redirects sent
                33877 packets sent from this host
                0 packets sent with fabricated ip header
                0 output packets dropped due to no bufs, etc.
                0 output packets discarded due to no route
                0 output datagrams fragmented
                0 fragments created
                0 datagrams that can't be fragmented
                0 IP Multicast packets dropped due to no receiver
                0 successful path MTU discovery cycles
                1 path MTU rediscovery cycle attempted
                3 path MTU discovery no-response estimates
                3 path MTU discovery response timeouts
                1 path MTU discovery decrease detected
                8 path MTU discovery packets sent
                0 path MTU discovery memory allocation failures
                0 ipintrq overflows                0 with illegal source
                0 packets processed by threads
                0 packets dropped by threads
                0 packets dropped due to the full socket receive buffer
                0 dead gateway detection packets sent
                0 dead gateway detection packet allocation failures
                0 dead gateway detection gateway allocation failures

突出显示的字段描述如下：

Total Packets Received
接收到的 IP 数据报总数。
Bad Header Checksum or Fragments Dropped
如果输出表明无效报头校验和或删除段是由于重复或超出空间造成的，这就表明网络传输信息包出现谬误或是设备驱动程序接收信息包的队列没有足够大。
Fragments Received
收到的段总数。
Dropped after Timeout
如果超时后删除的段为非零，那么 ip 段的计数时间在所有的数据报段到达之前就会因为网络繁忙而终止。为避免此情况，可使用 no 命令来增大 ipfragttl 网络参数的值。另一个原因可能是 mbuf 的不足造成的，这就要增加 thewall 的参数值。
Packets Sent from this Host
由这个系统创建并发送出去的 IP 数据报数目。这个计数不包括转发的数据报（由流量转发）。
Fragments Created
发送 IP 数据报时系统中创建的段的数目。

查看 IP 的统计信息时，参阅一下收到的信息包和收到的分段的比率。对于小的 MTU 网络有一个准则，如果有 10% 或者更多的信息包进行了分段，那么您就应该进一步调查以确定其原因。如果有很大数量的分段，那表明远程主机 IP 层上的协议正在向 IP 传输比接口的 MTU 值要大的数据。网络路径中的网关或路由器可能也有比网络中其他节点小得多的 MTU 值。对于发送的信息包和创建的段这也同样适用。

分段会导致 CPU 的额外负载，所以确定它的起因很重要。要知道一些应用程序本身就能够导致分段。比如，一个发送小数量数据的应用程序就能够导致出现分段。然而，如果您知道应用程序正在发送大量的数据，同时仍然出现分段，就需要确定它的起因。然而，如果您知道应用程序正在发送大量的数据，同时仍然出现分段，就需要确定它的起因。可能是因为使用的 MTU 大小不是系统中所配置的 MTU 大小。

下面的示例显示的是 udp 协议的输出：

# netstat -p udp
udp:
                11623 datagrams received
                0 incomplete headers
                0 bad data length fields
                0 bad checksums
                620 dropped due to no socket
                10989 broadcast/multicast datagrams dropped due to no socket
                0 socket buffer overflows
                14 delivered
                12 datagrams output

下面是重要的统计信息：

Bad Checksums
无效校验和可能是由于硬件板卡或是电缆故障造成的。
Dropped Due to No Socket
那些没有打开端口的套接字所接收到的 UDP 数据报总数。因而，肯定会发送 ICMP 目标地址无法到达 - 端口无法到达的信息。但是如果收到的 UDP 数据报是广播数据报，就不会产生 ICMP 错误。如果这个值较高，就需要检查应用程序如何如何处理套接字的。
Socket Buffer Overflows
Socket Buffer Overflows（套接字缓冲区溢出）可能是由于发送和接收 UDP 套接字不足、nfsd 守护程序过少，或者是 nfs_socketsize、udp_recvspace 和 sb_max 值过小而造成。

如果 netstat -p udp 命令表明套接字溢出，那么可能需要增加服务器上 nfsd 守护程序的数量。首先，检查受影响系统的 CPU 或 I/O 饱和度，然后使用 no -a 命令验证其他通信层的建议设置。如果系统处于饱和状态，那么您必须降低它的负载或是增加资源。

下面的示例显示的是 tcp 协议的输出：

 # netstat -p tcp
tcp:
                576 packets sent
                                512 data packets (62323 bytes)
                                0 data packets (0 bytes) retransmitted
                                55 ack-only packets (28 delayed)
                                0 URG only packets
                                0 window probe packets
                                0 window update packets
                                9 control packets
                                0 large sends
                                0 bytes sent using largesend
                                0 bytes is the biggest largesend
                719 packets received
                                504 acks (for 62334 bytes)
                                19 duplicate acks
                                0 acks for unsent data
                                449 packets (4291 bytes) received in-sequence
                                8 completely duplicate packets (8 bytes)
                                0 old duplicate packets
                                0 packets with some dup. data (0 bytes duped)
                                5 out-of-order packets (0 bytes)
                                0 packets (0 bytes) of data after window
                                0 window probes
                                2 window update packets
                                0 packets received after close
                                0 packets with bad hardware assisted checksum
                                0 discarded for bad checksums
                                0 discarded for bad header offset fields
                                0 discarded because packet too short
                                0 discarded by listeners
                                0 discarded due to listener's queue full
                                71 ack packet headers correctly predicted
                                172 data packet headers correctly predicted
                6 connection requests
                8 connection accepts
                14 connections established (including accepts)
                6 connections closed (including 0 drops)
                0 connections with ECN capability
                0 times responded to ECN
                0 embryonic connections dropped
                504 segments updated rtt (of 505 attempts)
                0 segments with congestion window reduced bit set
                0 segments with congestion experienced bit set
                0 resends due to path MTU discovery
                0 path MTU discovery terminations due to retransmits
                0 retransmit timeouts
                                0 connections dropped by rexmit timeout
                0 fast retransmits
                                0 when congestion window less than 4 segments
                0 newreno retransmits
                0 times avoided false fast retransmits
                0 persist timeouts
                                0 connections dropped due to persist timeout
                16 keepalive timeouts
                                16 keepalive probes sent
                                0 connections dropped by keepalive
                0 times SACK blocks array is extended
                0 times SACK holes array is extended
                0 packets dropped due to memory allocation failure
                0 connections in timewait reused
                0 delayed ACKs for SYN
                0 delayed ACKs for FIN
                0 send_and_disconnects                0 spliced connections
                0 spliced connections closed
                0 spliced connections reset
                0 spliced connections timeout
                0 spliced connections persist timeout
                0 spliced connections keepalive timeout

下面是重要的统计信息：

Packets Sent
Data Packets
Data Packets Retransmitted
Packets Received
Completely Duplicate Packets
Retransmit Timeouts

对于 TCP 统计信息，比较发送的信息包数和重发的信息包数。如果重发的信息包数大于总发送信息包量的 10-15%，TCP 就会出现超时，这表明网络流量负载很大，在超时之前不能返回应答信号（ACK）。接收的网节点的瓶颈或是一般的网络故障也会导致 TCP 重发，这会增大网络流量，给网络性能带来了进一步的问题。

同样，需要比较接收到的信息包量和完整复制的信息包量。如果在发送网节点上的 TCP 在从接收节点收到 ACK 信号之前就已经超时，它会重发这个信息包。当接收节点最终接收到所有重发的信息包时会进行复制。如果复制信息包的数量超出了 10-15%，那么这个问题可能还是由于网络流量过大或是接收节点的瓶颈问题所造成的。复制信息包会增加网络流量。

如果 TCP 发出一个信息包但没有按时接收到 ACK 信号，就会生成重发超时的一个量。然后它会重新发送信息包。对于任何后续重发，此值都会递增。这些持续的重发操作使得 CPU 的利用率更高，而且如果接收节点没有收到信息包，它最终会被删除掉。

历史上的今天...