Opening many connections for a page has a number of detrimental effects on throughput and the network load. First, each connection requires a certain amount of time for setup and shutdown. This decreases the throughput experienced by the user. In addition, the packets used for setup and shutdown don't contain application data, thereby unnecessarily increasing network load.
Second, each connection consumes state in the HTTP server. HTTP uses TCP for its transport protocol. TCP specifies that a connection must remain in a waiting state for four minutes after it is closed. Thus, a server may be littered with many ports in this state. In many TCP implementations, the more ports a server has open, the longer it takes the server to determine which application a packet is destined for. We didn't measure the effect of excessive state on the HTTP server because it would be the same regardless of whether we were using a wired or wireless network.
Another detrimental effect is that TCP cannot utilize the full bandwidth of the network. Most HTTP/1.0 connections are very short, since most HTTP objects are small. TCP has a slow start mechanism which gradually increases the sending rate in order to probe the network for the best throughput rate without causing congestion. However, a short-lived connection may never reach its full throughput potential. This causes the throughput experienced by the user to be unnecessarily low.
Another problem is that HTTP/1.0 has poor throughput on high latency connections because it is a strict request/response protocol. This means it requests an object and then waits until it has received the object before requesting the next object. As a consequence, HTTP/1.0 requires at least two network round trips for each retrieved object, which greatly decreases throughput on high latency networks such as the Metricom Ricochet.
The final problem is that HTTP/1.0 usually causes high internal fragmentation (not the same as IP fragmentation). This is because most HTTP objects are small and HTTP/1.0 uses a separate connection for each object. For example, an object slightly larger than a packet will cause one full-size packet and one small packet to be sent because we can't pack data from another object in with the last bit of data from the first object.
High internal fragmentation causes the many small packets to be sent. Small packets are wasteful of network resources because packets have a fixed cost of certain network resources regardless of the size of the packet. For example, routers have to spend some amount of CPU time to process a packet regardless of size. For a small packet, this CPU time cannot be amortized over many bytes, and therefore the router isn't working at optimal efficiency. Another example is the bytes used by packet headers. HTTP packets are also TCP packets and therefore have a header of 40 bytes per packet. The smaller the packet size, the greater the relative cost of the header in bandwidth.