A few questions about the properties of the TCP protocol

Question

Computer networks

Let's say the Ethernet MTU is 1500 bytes. We send 2048 bytes to the socket. The questions will be somewhat unusual.

We subtract the header sizes from the MTU - 20 bytes of IPv4 and 20 bytes of TCP. For simplicity, let's assume that the IP header is passed without options. It turns out that we can transfer 1460 bytes in one Ethernet frame.
Further, we simplify the conditions and assume that the transmitting and receiving parties do not support Selective Acknowledgment. Consider the situation where the remote TCP stack has a window large enough to accept 32 KB.

The first question is: does the TCP protocol specification support partial packet reception? Those. can the remote side set an Acknowledgment Number signaling the receipt of data smaller than the transmitted packet (less than 1460 bytes in this case)?

The second question is about transmission reliability. All sources state that TCP transport guarantees the delivery of packets. In this case, one point is not clear. The send() call does not guarantee delivery of data, it returns the amount of data written to the TCP stack's send buffer. But how do you know how many bytes were delivered to the remote side? It is clear that the stack itself, by accepting the Acknowledgment Number, “knows” how much data has been received by the remote side. But here the application program that transmitted the data is not given to know whether the data was received or not.

Answer 1

On the first question, there is no flag in the TCP header that indicates packet fragmentation (unlike IP), and there is also a checksum that will not be valid if the packet is not completely received. Packet fragmentation is handled by the IP layer.

Answer 2

On the second question, I can assume that the TCP / IP stack architecture isolates the upper levels about knowing the implementation details of the lower levels. Including data about SYN/ACK values. In general, the application does not need to know what is happening down there at all, otherwise the layers of the TCP / IP stack will depend on the implementation of neighboring layers, and this should not be.

Answer 3

But how do you know how many bytes were delivered to the remote side?

I’ll apply to know about this and it’s not required, that’s the point. TCP has packet integrity control, undelivered packets (including partially delivered ones) will be retransmitted the required number of times until the TCP_EST timeout is reached.

Answer 4

2) There seems to be no cross-platform way.
Linux has an ioctl SIOCOUTQ that allows you to determine how much unsent (not acknowledged) data is in the send buffer.
There is probably something similar in other OSes as well.
Knowing how many bytes we sent to the socket, and subtracting those not sent from them, we can determine how many were delivered.
Although usually the application protocol is built on the principle of request-response.
So when you receive a response to your request, you receive a confirmation of the delivery of the request.
Those. this problem doesn't exist at all.