netstat -p protocol

netstat -p 协议显示有关为协议变量 (udp,tcp,sctp,ip,icmp) ，它是协议的熟知名称或其别名。

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

以下示例显示了ipprotocol:

# 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

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

接收的总包数
接收到的 IP 数据报总数。
错误的头校验和或删除的片段
如果输出显示bad header checksum或fragments dropped因dup or out of space，这指示正在损坏包的网络或设备驱动程序接收不够大的队列。
接收的片段数
收到的段总数。
超时后删除
如果fragments dropped after timeout是零以外的，那么time to life counter型ip由于在数据报的所有片段到达之前网络繁忙，片段已到期。为避免此情况，可使用 no 命令来增大 ipfragttl 网络参数的值。另一个原因可能是 mbuf 的不足造成的，这就要增加 thewall 的参数值。
从此主机发送的包数
由这个系统创建并发送出去的 IP 数据报数目。这个计数不包括转发的数据报（由流量转发）。
已创建片段
发送 IP 数据报时系统中创建的段的数目。

查看 IP 统计信息时，请查看packets received至fragments received. 作为小型 MTU 网络的准则，如果 10% 或更多的包正在分段，您应该进一步调查以确定原因。如果有很大数量的分段，那表明远程主机 IP 层上的协议正在向 IP 传输比接口的 MTU 值要大的数据。网络路径中的网关或路由器可能也有比网络中其他节点小得多的 MTU 值。可以将相同的逻辑应用于packets sent和fragments created.

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

以下示例显示了udpprotocol:

# 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

下面是重要的统计信息：

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

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

以下示例显示了tcpprotocol:

 # 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
已接收的包数
Completely Duplicate Packets
Retransmit Timeouts

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

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

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