A post here:
http://blogs.adobe.com/dreamweaver/2011/02/optimal-css-tiled-background-image-size.html
staes that "The smallest download that browsers can do is 1K bytes."
Is this due to minimum size of a packet across the network? If not, what is the reason for this (if it is indeed true)?
Packet is an ambiguous term here because it is sometimes misused to refer to different elements for your transmission. Lets see what your data is wrapped up in and you'll see what I mean, and hopefully get the answer you wanted:
Lets assume you're sending 1 byte of data1 over the internet, on the TCP/IP model.
The data starts on the application level and needs to be wrapped up in headers for the lower levels so that it can be passed around.
First that data is wrapped in a TCP Segment, which adds a header of 20 bytes (min size now 21 bytes).
This puts us on the transport level.
This is then wrapped in an IP Packet, which adds another header of 20 bytes (min size now 41 bytes).
Now we're on internet level.
Note that this wrapping is changed each time a new router forwards your data to a new subnet.
This is wrapped in a link frame of some type - of which the header and footer size vary depending on the type of frame used, which depends on the type of link being used.
This is on link level.
This wrapping is changed each time the unit if transmitted between two entities.
Finally is the physical transmission (eg, electrical signals down a cable, radio waves, etc).
Here's some informative images available from the Wikipedia TCP/IP model page that hep to visually explain what is happening:
1. I guess you might be able to send 0 bytes... but haven't checked that. In fact I haven't checked if 1 byte is allowed either, but hey.
That is incorrect, there is no minimum size for a download. You can verify this by creating a tiny file on your webserver and using wireshark to watch the network traffic when you download that file.
The minimum size of a standard ethernet packet is 64 bytes.
On the face of it, the blog posting you are quoting from is incorrect. There is no "minimum download size" for HTTP. (And your theory about minimum packet sizes is also incorrect.)
However, there is a grain of truth to this. And that is that if the size of the file you are downloading is small enough, the HTTP response message (consisting of the file and the HTTP response headers) will fit into a single network packet. If that happens, the browser is likely to get the file faster than if it took two or more packets to send the response.
(With one packet in the response, there is less chance that a packet will be dropped and need to be resent, and a greater chance that the TCP/IP flow-control window won't add extra round-trip delays for packet acknowledgment.)
The typical maximum size of a packet sent / received (the MTU) is 1500 bytes for ethernet. When you factor in the IP and TCP overheads, and the size of a typical HTTP response header, that could well leave you ~1K left for file data in the first packet of a response. Hence the grain of truth in the blogger's comment.
It's worse than you think.
The slow page loading is because the browser is having issues rendering the 1x1 pixel 800000 times (e.g. for a browser window set to 1000x800). Many years ago, perhaps in 1999, I read an article somewhere that prescribed 16x16 as being the 'fastest' x smallest for tiling. Of course, rendering may be different now.
If you read the blog post, the complaint is actually about slow page loading. Not slow downloading. It doesn't have anything to do with packets although its been an interesting discussion.
So perhaps the question should be re-worded.
