TCP is a streaming protocol. Which means that you as sender have no control over how many send operations are actually going on in the kernel.
There are several mechanisms at play here. A client can call send many times with only one byte. TCP will try to accumulate these bytes until the MTU of the L2 is filled and only then send it, or sooner if a timeout is reached.
In one send operation you can send 64K approx.
To send a file, you need thus several send operatons until the whole file is sent.
On the receiving side of the TCP, there is no relation to the number of send operations and the number of receive operations. If the sender send 5 times 10 bytes consecutively and fast, very likely they will be received as 50 bytes in one receive operation.
Actually for TCP there is no such thing as a packet. It is called a frame.
Packets are used for UDP, because UDP is not a streaming protocol.
In UDP, if you send 5 bytes, the receiver will receive 5 bytes or nothing because UDP is not connection oriented. Whereas TCP is.
For UDP the max size is approx 64k. This 64k will get chopped to pieces by IP to send it over the wire, and IP will put it back together upon reception. This is all because of the L2 MTU.