In TCP, flow control and congestion control both rely on dynamically adjusted windows, but the mechanisms used to adjust the windows rely on principally different inputs. In flow control, the main input for adjusting the window is how much data the receiver can accept, and since this information is known to the receiver, the sender can obtain it directly from the receiver. In congestion control, the main input for adjusting the window is how much data the network can accept, and since this information is not directly known to either the sender or the receiver, the sender has to estimate it indirectly.
In more detail for the flow control mechanism, the receiver advertises how many bytes it is still willing to receive in each acknowledgment message, and the receiver pauses when the messages that are in flight would exceed this limit.
In more detail for the congestion control mechanism, the sender estimates the state of the network from four distinct events that it can observe.
An in order acknowledgment is interpreted as an evidence that the network handles the current traffic well, and the congestion control window is slowly grown in response.
One or two duplicit acknowledgments, which occur when the receiver observes out of order messages, are interpreted as an evidence of acceptable message reordering, of no interest to congestion control.
Triple duplicit acknowledgments are interpreted as an evidence of a single message loss and therefore slight network overload. The congestion control window is halved in response.
Timeout is interpreted as an evidence of a significant message loss and therefore significant network overload. The congestion control window is minimized in response.
The congestion window growth is directed by either Slow Start or Congestion Control algorithms. Roughly, Slow Start increases the congestion window size by one segment every ACK of a single segment, while Congestion Control increases the congestion window size by one segment every ACK of the whole window. The switch from Slow Start to Congestion Control happens when an adaptive congestion window size threshold is reached.
The reaction to the slight network overload is somewhat complicated by the fact that the first indication of recovery in the form of the first in order acknowledgment comes only after the lost message is delivered. Until then, the last acknowledged position in the stream does not change, and if the congestion window were simply halved, no new message would be sent until the first in order acknowledgment arrives. After resending the lost message using the Fast Retransmit mechanism, the protocol therefore enters the Fast Recovery mode, where the congestion window size is increased on every duplicit ACK. As a result, the artificially inflated congestion window will reach the size that allows sending additional messages when just about half of the previously sent messages has reached the receiver. When the resent message reaches the receiver, the in order acknowledgment arrives and the artificially inflated congestion window is deflated back to the original size.