Lines Matching full: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
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
361 time client replies ACK, this socket will get another chance to move
431     or pure receivers (this means either the sequence number or the ack
438 good. Kernel would also come into slow path if the "Delayed ack" is
439 used, because when using "Delayed ack", the data is sent in both
448 If a packet set ACK flag and has no data, it is a pure ACK packet, if
455 If a TCP packet has data (which means it is not a pure ACK packet),
535 approached. The two pieces of information are ACK train length and
537 `Hybrid Slow Start paper`_. Either ACK train length or packet delay
548 How many times the ACK train length threshold is detected
552 The sum of CWND detected by ACK train length. Dividing this value by
554 ACK train length.
607 the duplicate ACK number. E.g., if retransmission is triggered, and
618 1,2,4,5,3. When the sender receives the ACK of packet 3 (which will
621 3 is retransmitted but the timestamp of the packet 3's ACK is earlier
706 SACK block is caused by ACK recording, the TCP stack will only ignore
781 TCP ACK skip
785 section of the `sysctl document`_. When kernel decides to skip an ACK
787 counters to indicate the ACK is skipped in which scenario. The ACK
795 The ACK is skipped in Syn-Recv status. The Syn-Recv status means the
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
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
809 The ACK is skipped due to PAWS (Protect Against Wrapped Sequence
811 or Time-Wait statuses, the skipped ACK would be counted to
813 TcpExtTCPACKSkippedTimeWait. In all other statuses, the skipped ACK
823 The ACK is skipped in Fin-Wait-2 status, the reason would be either
828 The ACK is skipped in Time-Wait status, the reason would be either
833 The ACK is skipped if the ACK is a challenge ACK. The RFC 5961 defines
834 3 kind of challenge ACK, please refer `RFC 5961 section 3.2`_,
837 send challenge ACKs if the ACK number is before the first
863 Delayed ACK
865 The TCP Delayed ACK is a technique which is used for reducing the
867 `Delayed ACK wiki`_
869 .. _Delayed ACK wiki: https://en.wikipedia.org/wiki/TCP_delayed_acknowledgment
873 A delayed ACK timer expires. The TCP stack will send a pure ACK packet
874 and exit the delayed ACK mode.
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
888 ACKed. A Delayed ACK loss might cause this issue, but it would also be
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
981 Challenge ACK
983 For details of challenge ACK, please refer the explanation of
993 updates this counter, the TCP stack might send a challenge ACK and
1104 When the server received the first SYN, it replied a SYN+ACK, and came into
1106 SYN, sent SYN+ACK, received ACK, so server sent 1 packet, received 2
1107 packets, TcpInSegs increased 2, TcpOutSegs increased 1. The last ACK
1108 of the 3-way handshake is a pure ACK without data, so
1112 TcpActiveOpens increased 1, the client sent SYN, received SYN+ACK, sent
1113 ACK, so client sent 2 packets, received 1 packet, TcpInSegs increased
1206 replied an ACK. But kernel handled them in different ways. When the
1224 reply an ACK, when kernel handled this ACK, the fast path was not
1225 enabled, so the ACK was counted into 'TcpExtTCPPureAcks'.
1228 and received another ACK from the server, in this time, the fast path is
1229 enabled, and the ACK was qualified for fast path, so it was handled by
1230 the fast path, so this ACK was counted into TcpExtTCPHPAcks.
1588 re-send the SYN packet if it didn't receive a SYN+ACK, we could find
1647 and reply a SYN/ACK. The second SYN will let server reply the SYN/ACK
1648 again, and record the reply time (the duplicate ACK reply time). The
1649 third SYN will let server check the previous duplicate ACK reply time,
1650 and decide to skip the duplicate ACK, then increase the
1725 failed, the nstat-b replied an ACK for the first SYN, skipped the ACK
1733 data, so we need a pure ACK packet. To generate such a packet, we
1735 we capture an ACK on port 9001, change the source/destination port
1756 On nstat-a, run tcpdump to capture an ACK::
1769 On nstat-a, the tcpdump should have captured the ACK. We should check