When the data is correctly received, it enters the TCP read buffer and is immediately subject to confirmation. This does not mean that the confirmation is sent immediately, as it will be more efficient to combine the confirmation with updating the window size or with transferring data over the connection in the other direction or with confirmation of more data.
For example, suppose you send one byte at a time corresponding to the user, and the other side has a receive buffer of 50,000 bytes. It tells you that the window size is 50,000 bytes, which means that you can send as many bytes of data without receiving anything further. Each byte of data sent closes the window by one byte. Now the receiver can send a packet confirming one byte as soon as it was correctly received and has entered a TCP receive buffer with a window size of 49999 bytes, because this is how much space is left in the receive buffer. Confirmation will allow you to remove the byte from your send buffer, since now you know that the byte is received correctly and will not need to be repeated. Then, when the application reads it from the TCP receive buffer using read() or recv() , which will make a buffer space for one additional byte of data to be received, so it can then send another packet updating the TCP window size with one byte, so that you can send again 50,000 bytes, and not 49999. Then the application can echo a character or send another answer to the data, as a result of which a third packet will be sent. Fortunately, a well-designed TCP implementation will not do this, as it will create a lot of overhead. It will ideally send one packet containing any data going in the other direction, as well as any confirmation confirmation and window size as part of the same packet. It might seem that confirmation is sent when the application reads the data and leaves the receive buffer, but it may just be the event that caused the packet to be sent. However, it does not always delay confirmation and does not delay it indefinitely; after a short timeout without any other activity, he will send any delayed confirmation.
Regarding the size of the receive buffer, which contains received data that has not yet been read by the application, which can be controlled using setsockopt() with the SO_RCVBUF option. The default value may vary depending on the OS, memory size and other parameters. For example, fast connections with high latency (such as satellite) may require large buffers, although this will increase memory usage. There is also a send buffer ( SO_SNDBUF ), which includes data that has not yet been transmitted or has been transmitted but not yet acknowledged.