Lines Matching full:tcp
32 The number of packets delivers to the upper layer protocols. E.g. TCP, UDP,
249 General TCP counters
257 The number of packets received by the TCP layer. As mentioned in
259 error, invalid TCP header and so on. Only one error won't be included:
263 packets would be delivered to the TCP layer, but the TCP layer will discard
274 The number of packets sent by the TCP layer. As mentioned in RFC1213,
286 It means the TCP layer sends a SYN, and come into the SYN-SENT
296 It means the TCP layer receives a SYN, replies a SYN+ACK, come into
301 When packets are received by the TCP layer and are not be read by the
302 application, the TCP layer will try to merge them. This counter
309 When sending packets, the TCP layer will try to merge small packets to
322 more useful to track the TCP retransmission rate.
342 When kernel receives a SYN from a client, and if the TCP accept queue
345 TCP socket is in LISTEN state, and kernel need to drop a packet,
353 an old kernel, the TCP stack has different behavior when TCP accept
354 queue is full. On the old kernel, TCP stack won't drop the SYN, it
355 would complete the 3-way handshake. As the accept queue is full, TCP
356 stack will keep the socket in the TCP half-open queue. As it is in the
357 half open queue, TCP stack will send SYN+ACK on an exponential backoff
358 timer, after client replies ACK, TCP stack checks whether the accept
365 TCP Fast Open
390 When the TCP stack wants to retransmit a packet, and finds that packet
391 is not lost in the network, but the packet is not sent yet, the TCP
413 TCP Fast Path
415 When kernel receives a TCP packet, it has two paths to handler the
428 - Unexpected TCP flags/window values/header lengths are received
429 (detected by checking the TCP header against pred_flags)
433 - Unexpected TCP option.
440 directions. When the TCP window scale option is not used, kernel will
442 established state, but if the TCP window scale option is used, kernel
455 If a TCP packet has data (which means it is not a pure ACK packet),
460 TCP abort
464 It means TCP layer has data in flight, but need to close the
465 connection. So TCP layer sends a RST to the other side, indicate the
483 This counter means the application has unread data in the TCP layer when
484 the application wants to close the TCP connection. In such a situation,
485 kernel will send a RST to the other side of the TCP connection.
489 When an application closes a TCP connection, kernel still need to track
490 the connection, let it complete the TCP disconnect process. E.g. an
501 1. the memory used by the TCP protocol is higher than the third value of
502 the tcp_mem. Please refer the tcp_mem section in the `TCP man page`_:
504 .. _TCP man page: http://man7.org/linux/man-pages/man7/tcp.7.html
511 This counter will increase when any of the TCP timers expire. In such
516 When a TCP connection comes into FIN_WAIT_2 state, instead of waiting
519 Linux kernel TCP stack. By configuring the TCP_LINGER2 socket option,
524 The kernel TCP layer will send RST if the `RFC2525 2.17 section`_ is
530 TCP Hybrid Slow Start
533 TCP congestion window Slow Start algorithm. It uses two pieces of
534 information to detect whether the max bandwidth of the TCP path is
566 TCP retransmission and congestion control
568 The TCP protocol has two retransmission mechanisms: SACK and fast
570 the kernel TCP stack would use SACK, or kernel would use fast
571 recovery. The SACK is a TCP option, which is defined in `RFC2018`_,
575 The TCP congestion control is a big and complex topic. To understand
589 TcpExtTCPRenoRecovery increases 1. These two counters mean the TCP
598 unusual, it is allowed by the TCP protocol. The sender doesn't really
633 packet yet, the sender would know packet 4 is out of order. The TCP
639 The TCP stack wants to retransmit a packet and the congestion control
644 The TCP stack wants to retransmit a packet and the congestion control
653 The TCP stack tries to deliver a retransmission packet to lower layers
658 The TCP stack retransmits a SYN packet.
665 duplicate. (2) an out of order packet is duplicate. The TCP stack
673 The TCP stack receives a duplicate packet which has been acked, so it
678 The TCP stack receives an out of order duplicate packet, so it sends a
683 The TCP stack receives a DSACK, which indicates an acknowledged
688 The TCP stack receives a DSACK, which indicate an out of order
700 18f02545a9a1 ("[TCP] MIB: Add counters for discarded SACK blocks")
706 SACK block is caused by ACK recording, the TCP stack will only ignore
713 of the TCP socket. If the undo_marker is not set, the TCP stack isn't
723 short). If a SACK block acrosses multiple skb, the TCP stack will try
741 A skb should be shifted or merged, but the TCP stack doesn't do it for
744 TCP out of order
748 The TCP layer receives an out of order packet and has enough memory
753 The TCP layer receives an out of order packet but doesn't have enough
763 TCP PAWS
766 which is used to drop old packets. It depends on the TCP
781 TCP ACK skip
796 TCP stack receives a SYN and replies SYN+ACK. Now the TCP stack is
797 waiting for an ACK. Generally, the TCP stack doesn't need to send ACK
798 in the Syn-Recv status. But in several scenarios, the TCP stack need
799 to send an ACK. E.g., the TCP stack receives the same SYN packet
802 the TCP stack needs to send ACK. If the ACk sending frequency is higher than
803 tcp_invalid_ratelimit allows, the TCP stack will skip sending ACK and
819 check and the TCP status is not Syn-Recv, Fin-Wait-2, and Time-Wait.
836 three scenarios, In some TCP status, the linux TCP stack would also
844 TCP receive window
848 Depending on current memory usage, the TCP stack tries to set receive
850 value. For example, if the previous window size is 10, and the TCP
856 The TCP receive window is set to zero from a no-zero value.
860 The TCP receive window is set to no-zero value from zero.
865 The TCP Delayed ACK is a technique which is used for reducing the
873 A delayed ACK timer expires. The TCP stack will send a pure ACK packet
878 A delayed ACK timer expires, but the TCP stack can't send an ACK
880 TCP stack will send a pure ACK later (after the userspace program
881 unlock the socket). When the TCP stack sends the pure ACK later, the
882 TCP stack will also update TcpExtDelayedACKs and exit the delayed ACK
887 It will be updated when the TCP stack receives a packet which has been
894 TLP is an algorithm which is used to detect TCP packet loss. For more
897 .. _TLP paper: https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01
907 TCP Fast Open description
909 TCP Fast Open is a technology which allows data transfer before the
910 3-way handshake complete. Please refer the `TCP Fast Open wiki`_ for a
917 When the TCP stack receives an ACK packet in the SYN-SENT status, and
918 the ACK packet acknowledges the data in the SYN packet, the TCP stack
924 This counter indicates that the TCP stack initiated a TCP Fast Open,
934 This counter indicates how many times the TCP stack accepts the fast
939 This counter indicates how many times the TCP stack rejects the fast
941 TCP stack finds an error during the socket creating process.
946 fastopenq->max_qlen, the TCP stack will reject the fast open request
947 and update this counter. When this counter is updated, the TCP stack
973 How many reply packets of the SYN cookies the TCP stack receives.
993 updates this counter, the TCP stack might send a challenge ACK and
999 When a socket is under memory pressure, the TCP stack will try to
1007 The TCP stack tries to reclaim memory for a socket. After updates this
1008 counter, the TCP stack will try to collapse the out of order queue and
1009 the receiving queue. If the memory is still not enough, the TCP stack
1015 The TCP stack tries to discard packet on the out of order queue.
1074 tcp 3-way handshake
1084 Connection to 192.168.122.251 9000 port [tcp/*] succeeded!
1086 The server listened on tcp 9000 port, the client connected to it, they
1091 nstatuser@nstat-b:~$ nstat | grep -i tcp
1099 nstatuser@nstat-a:~$ nstat | grep -i tcp
1116 TCP normal traffic
1126 Connection to nstat-b 9000 port [tcp/*] succeeded!
1131 Connection to nstat-b 9000 port [tcp/*] succeeded!
1165 Connection to nstat-b 9000 port [tcp/*] succeeded!
1207 TCP window scale option is not used, kernel will try to enable fast
1209 but if the TCP window scale option is used, kernel will disable the
1217 tcp 0 0 192.168.122.250:40654 192.168.122.251:9000
1263 packet, and the TCP layer has acked this packet, but the application didn't
1333 sudo iptables -A INPUT -i ens3 -p tcp --destination-port 9000 -j DROP
1346 TCP: 14 (estab 1, closed 0, orphaned 10, synrecv 0, timewait 0/0), ports 0
1352 TCP 14 13 1
1442 On the server, we run a program which listen on TCP port 9000, but
1497 the receiving queue. So the TCP layer merged the two packets, and we
1510 Connection to nstat-b 9000 port [tcp/*] succeeded!
1606 nc: connect to 8.8.8.8 port 53 (tcp) failed: Network is unreachable
1665 offload for the TCP checksum, so the checksum in the /tmp/syn.pcap
1678 nstatuser@nstat-a:~$ sudo iptables -A INPUT -p tcp --sport 9000 -j DROP
1708 Connection to nstat-b 9000 port [tcp/*] succeeded!
1732 window. The linux TCP stack would avoid to skip if the packet has
1751 Connection to nstat-b 9000 port [tcp/*] succeeded!
1754 Connection to nstat-b 9001 port [tcp/*] succeeded!