Lines Matching refs:ACK

275 it excludes the retransmitted packets. But it includes the SYN, ACK
296 It means the TCP layer receives a SYN, replies a SYN+ACK, come into
329   TCPSynRetrans: number of SYN and SYN/ACK retransmits to break down
359 half open queue, TCP stack will send SYN+ACK on an exponential backoff
360 timer, after client replies ACK, TCP stack checks whether the accept
363 time client replies ACK, this socket will get another chance to move
450 If a packet set ACK flag and has no data, it is a pure ACK packet, if
457 If a TCP packet has data (which means it is not a pure ACK packet),
537 approached. The two pieces of information are ACK train length and
539 `Hybrid Slow Start paper`_. Either ACK train length or packet delay
550 How many times the ACK train length threshold is detected
554 The sum of CWND detected by ACK train length. Dividing this value by
556 ACK train length.
609 the duplicate ACK number. E.g., if retransmission is triggered, and
620 1,2,4,5,3. When the sender receives the ACK of packet 3 (which will
623 3 is retransmitted but the timestamp of the packet 3's ACK is earlier
710 SACK block is caused by ACK recording, the TCP stack will only ignore
785 TCP ACK skip
789 section of the `sysctl document`_. When kernel decides to skip an ACK
791 counters to indicate the ACK is skipped in which scenario. The ACK
799 The ACK is skipped in Syn-Recv status. The Syn-Recv status means the
800 TCP stack receives a SYN and replies SYN+ACK. Now the TCP stack is
801 waiting for an ACK. Generally, the TCP stack doesn't need to send ACK
803 to send an ACK. E.g., the TCP stack receives the same SYN packet
806 the TCP stack needs to send ACK. If the ACk sending frequency is higher than
807 tcp_invalid_ratelimit allows, the TCP stack will skip sending ACK and
813 The ACK is skipped due to PAWS (Protect Against Wrapped Sequence
815 or Time-Wait statuses, the skipped ACK would be counted to
817 TcpExtTCPACKSkippedTimeWait. In all other statuses, the skipped ACK
827 The ACK is skipped in Fin-Wait-2 status, the reason would be either
832 The ACK is skipped in Time-Wait status, the reason would be either
837 The ACK is skipped if the ACK is a challenge ACK. The RFC 5961 defines
838 3 kind of challenge ACK, please refer `RFC 5961 section 3.2`_,
841 send challenge ACKs if the ACK number is before the first
867 Delayed ACK
869 The TCP Delayed ACK is a technique which is used for reducing the
871 `Delayed ACK wiki`_
873 .. _Delayed ACK wiki: https://en.wikipedia.org/wiki/TCP_delayed_acknowledgment
877 A delayed ACK timer expires. The TCP stack will send a pure ACK packet
878 and exit the delayed ACK mode.
882 A delayed ACK timer expires, but the TCP stack can't send an ACK
884 TCP stack will send a pure ACK later (after the userspace program
885 unlock the socket). When the TCP stack sends the pure ACK later, the
886 TCP stack will also update TcpExtDelayedACKs and exit the delayed ACK
892 ACKed. A Delayed ACK loss might cause this issue, but it would also be
921 When the TCP stack receives an ACK packet in the SYN-SENT status, and
922 the ACK packet acknowledges the data in the SYN packet, the TCP stack
985 Challenge ACK
987 For details of challenge ACK, please refer the explanation of
997 updates this counter, the TCP stack might send a challenge ACK and
1108 When the server received the first SYN, it replied a SYN+ACK, and came into
1110 SYN, sent SYN+ACK, received ACK, so server sent 1 packet, received 2
1111 packets, TcpInSegs increased 2, TcpOutSegs increased 1. The last ACK
1112 of the 3-way handshake is a pure ACK without data, so
1116 TcpActiveOpens increased 1, the client sent SYN, received SYN+ACK, sent
1117 ACK, so client sent 2 packets, received 1 packet, TcpInSegs increased
1210 replied an ACK. But kernel handled them in different ways. When the
1228 reply an ACK, when kernel handled this ACK, the fast path was not
1229 enabled, so the ACK was counted into 'TcpExtTCPPureAcks'.
1232 and received another ACK from the server, in this time, the fast path is
1233 enabled, and the ACK was qualified for fast path, so it was handled by
1234 the fast path, so this ACK was counted into TcpExtTCPHPAcks.
1592 re-send the SYN packet if it didn't receive a SYN+ACK, we could find
1651 and reply a SYN/ACK. The second SYN will let server reply the SYN/ACK
1652 again, and record the reply time (the duplicate ACK reply time). The
1653 third SYN will let server check the previous duplicate ACK reply time,
1654 and decide to skip the duplicate ACK, then increase the
1729 failed, the nstat-b replied an ACK for the first SYN, skipped the ACK
1737 data, so we need a pure ACK packet. To generate such a packet, we
1739 we capture an ACK on port 9001, change the source/destination port
1760 On nstat-a, run tcpdump to capture an ACK::
1773 On nstat-a, the tcpdump should have captured the ACK. We should check