As you can see the amount of failed connections is a little bit stunning -- it's almost 2/3 of the total number of connections. The second thing are retransmissions, and again the number of segments that was retransmitted is quite high.$ netstat -s
Ip:
999320 total packets received
94636 forwarded
0 incoming packets discarded
884213 incoming packets delivered
1184677 requests sent out
1898 outgoing packets dropped
1 dropped because of missing route
60 fragments received ok
120 fragments created
Icmp:
25011 ICMP messages received
5687 input ICMP message failed.
ICMP input histogram:
destination unreachable: 23898
timeout in transit: 1105
redirects: 3
echo replies: 5
644 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
destination unreachable: 639
echo request: 5
IcmpMsg:
InType0: 5
InType3: 23898
InType5: 3
InType11: 1105
OutType3: 639
OutType8: 5
Tcp:
97509 active connections openings
1876 passive connection openings
60911 failed connection attempts
2291 connection resets received
6 connections established
489070 segments received
591406 segments send out
62036 segments retransmited
699 bad segments received.
3557 resets sent
Udp:
369824 packets received
213 packets to unknown port received.
0 packet receive errors
512524 packets sent
UdpLite:
TcpExt:
3 ICMP packets dropped because they were out-of-window
6790 TCP sockets finished time wait in fast timer
4487 delayed acks sent
58 delayed acks further delayed because of locked socket
Quick ack mode was activated 1005 times
463 packets directly queued to recvmsg prequeue.
3070 bytes directly in process context from backlog
30241 bytes directly received in process context from prequeue
152172 packet headers predicted
83 packets header predicted and directly queued to user
119279 acknowledgments not containing data payload received
76845 predicted acknowledgments
1 times recovered from packet loss due to fast retransmit
1604 times recovered from packet loss by selective acknowledgements
Detected reordering 1 times using FACK
Detected reordering 6 times using SACK
234 congestion windows recovered without slow start by DSACK
809 congestion windows recovered without slow start after partial ack
TCPLostRetransmit: 765
84 timeouts after SACK recovery
95 timeouts in loss state
6974 fast retransmits
265 forward retransmits
358 retransmits in slow start
26137 other TCP timeouts
TCPLossProbes: 4764
TCPLossProbeRecovery: 1727
144 SACK retransmits failed
1070 DSACKs sent for old packets
4 DSACKs sent for out of order packets
2911 DSACKs received
1 DSACKs for out of order packets received
201 connections reset due to unexpected data
865 connections reset due to early user close
376 connections aborted due to timeout
TCPDSACKIgnoredOld: 4
TCPDSACKIgnoredNoUndo: 1564
TCPSpuriousRTOs: 129
TCPSackShifted: 37
TCPSackMerged: 9428
TCPSackShiftFallback: 26231
TCPRetransFail: 2262
TCPRcvCoalesce: 33276
TCPOFOQueue: 6611
TCPOFOMerge: 4
TCPChallengeACK: 803
TCPSYNChallenge: 750
TCPSpuriousRtxHostQueues: 339
IpExt:
InMcastPkts: 13030
OutMcastPkts: 18252
InBcastPkts: 5252
OutBcastPkts: 462
InOctets: 269470040
OutOctets: 775136946
InMcastOctets: 2145695
OutMcastOctets: 3004421
InBcastOctets: 1561083
OutBcastOctets: 76230
InNoECTPkts: 998626
InECT1Pkts: 70
InECT0Pkts: 113
InCEPkts: 575
When I turn qbittorrent off, retransmissions do exist, but the value is about 0,01%, and there's no failed connection at all or maybe just single ones.
The question is: is it normal to get so high numbers for retransmissions and failed connection when it comes to torrents and other form of p2p? Maybe is there something I can do about it? Is there a chance that NAT can break those connections?