https://tools.ietf.org/html/rfc2001
flow control( advertised by receiver)
a mechanism to prevent the sender from overwhelming the receiver with data it may not be able to process
each side of the connection advertises its own receive windows size(rwnd), which communicate the windo size of the aviailable buffer space to hold the incoming data.
if the window size is 0, then the sender should stop sending data until the data in the buffer has been clear by the application layer.
This workflow continues throughout the lifetime of every TCP connection: each ACK packet carries the latest rwnd value for each side, allowing both sides to dynamically adjust the data flow rate to the capacity and processing speed of the sender and receiver.
fast retransmission:
The TCP sender SHOULD use the "fast retransmit" algorithm to detect and repair loss, based on incoming duplicate ACKs. The fast retransmit algorithm uses the arrival of 3 duplicate ACKs (4 identical ACKs without the arrival of any other intervening packets) as an indication that a segment has been lost. After receiving 3 duplicate ACKs, TCP performs a retransmission of what appears to be the missing segment, without waiting for the retransmission timer to expire.
fast recovery mode :
slow start
flow control sliding windows
congestion control : congestion windows
Duplicate ACKs
are sent when the receiver sees a gap in the packets it receives. They're not just used for fast retransmissions, it is the other way around (sort of): fast retransmissions use a counter for duplicate ACKs to trigger a retransmission faster than by Retransmission TimeOut (RTO).
If you see duplicate ACKs coming in and no gaps in the packets going out it means that you capture at the source of the data (not the receiving side). That is quite normal if the packet loss occurs somewhere in the path to the receiver. You should see a retransmission though; if you don't you probably have a case where packets get reordered on the way and arrive out-of-order, which results in duplicate ACKs as well. The difference between packet loss and out-of-order is that the Duplicate ACK count is very low for out-of-order (often only going up to "Duplicate ACK #1"), while with packet loss they can reach counters above 100 in real bad cases.
congestion control
When congestion occurs (indicated by a timeout or the reception of duplicate ACKs)
slow start :
The problem was that flow control prevented the sender from overwhelming the receiver, but there was no mechanism to prevent either side from overwhelming the underlying network: neither the sender nor the receiver knows the available bandwidth at the beginning of a new connection, and hence need a mechanism to estimate it and also to adapt their speeds to the continuously changing conditions within the network.
Van Jacobson documented several algorithms to address these problems: slow-start, congestion avoidance, fast retransmit, and fast recovery. All four quickly became a mandatory part of the TCP specification.
The only way to estimate the available capacity between the client and the server is to measure it by exchanging data, and this is precisely what slow-start is designed to do. To start, the server initializes a new congestion window (cwnd) variable per TCP connection,The cwnd variable is not advertised or exchanged between the sender and receiverthe maximum amount of data in flight (not ACKed) between the client and the server is the minimum of the rwnd and cwnd variables.
how do the server and the client determine optimal values for their congestion window sizes?
The solution is to start slow and to grow the window size as the packets are acknowledged: slow-start! Originally, the cwnd start value was set to 1 network segment,or every received ACK, the slow-start algorithm indicates that the server can increment its cwnd window size(exponential growth)
congestion windows
TCP uses a congestion window in the sender side to do congestion avoidance. The congestion window indicates the maximum amount of data that can be sent out on a connection without being acknowledged. TCP detects congestion when it fails to receive an acknowledgement for a packet within the estimated timeout.
三、拥塞控制
网络中的链路容量和交换结点中的缓存和处理机都有着工作的极限，当网络的需求超过它们的工作极限时，就出现了拥塞。拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。常用的方法就是：
慢开始、拥塞控制
快重传、快恢复
一切的基础还是慢开始，这种方法的思路是这样的：
-1. 发送方维持一个叫做“拥塞窗口”的变量，该变量和接收端口共同决定了发送者的发送窗口；
-2. 当主机开始发送数据时，避免一下子将大量字节注入到网络，造成或者增加拥塞，选择发送一个1字节的试探报文；
-3. 当收到第一个字节的数据的确认后，就发送2个字节的报文；
-4. 若再次收到2个字节的确认，则发送4个字节，依次递增2的指数级；
-5. 最后会达到一个提前预设的“慢开始门限”，比如24，即一次发送了24个分组，此时遵循下面的条件判定：
*1. cwnd < ssthresh， 继续使用慢开始算法；
*2. cwnd > ssthresh，停止使用慢开始算法，改用拥塞避免算法；
*3. cwnd = ssthresh，既可以使用慢开始算法，也可以使用拥塞避免算法；
-6. 所谓拥塞避免算法就是：每经过一个往返时间RTT就把发送方的拥塞窗口+1，即让拥塞窗口缓慢地增大，按照线性规律增长；
-7. 当出现网络拥塞，比如丢包时，将慢开始门限设为原先的一半，然后将cwnd设为1，执行慢开始算法（较低的起点，指数级增长）；
上述方法的目的是在拥塞发生时循序减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够的时间把队列中积压的分组处理完毕。慢开始和拥塞控制算法常常作为一个整体使用，而快重传和快恢复则是为了减少因为拥塞导致的数据包丢失带来的重传时间，从而避免传递无用的数据到网络。快重传的机制是：
-1. 接收方建立这样的机制，如果一个包丢失，则对后续的包继续发送针对该包的重传请求；
-2. 一旦发送方接收到三个一样的确认，就知道该包之后出现了错误，立刻重传该包；
-3. 此时发送方开始执行“快恢复”算法：
*1. 慢开始门限减半；
*2. cwnd设为慢开始门限减半后的数值；
*3. 执行拥塞避免算法（高起点，线性增长）；
What is a TCP Keep Alive?
Before TCP can transfer data to another system, it first has to establish a TCP handshake (SYN – SYN/ACK – ACK)connection . If successful, the connection will now be available to transmit data.
Once the connection is established, a timer is started on each TCP stack that will eventually time out the connection. This means that if a socket is not in use for a specified amount of time, if the stack is configured to do so, it will send a TCP Keep Alive. This timer is a configurable setting and varies depending on the system.
The sending station is trying to see if the remote peer is dead, if the connection is still open and in use, or may just need to keep the connection open instead of suffering another handshake overhead. If the target does not respond, the sender may send several Keep Alives before finally sending a TCP reset to kill the socket. This is a good thing, since we don't want open/unused TCP connections staying open and hogging resources forever.
the TCP Keep Alive will also include 1 byte of data, which the connection partner needs to acknowledge. That will increment the sequence number by 1, and of course the ACK on the response.