by Warren Gaebel
| Oct 16, 2012
When we left off last time, our hero had bravely traversed the Internet and found his way back to the client machine. What courage! What tenacity! What a component!Now that the component has arrived at the client machine, it must make its way up the protocol stack, which is the subject of this part. Climbing the protocol stack is the same as described in Part IV, except that the packets are carrying the reply, not the request.The most noticeable difference between this trip up the protocol stack, as compared to Part IV’s trip up the protocol stack, is that we are typically dealing with many more frames, datagrams, and segments. Part IV was the delivery of the request (small); this part is the delivery of the resource (big). This means extra work at every layer of the protocol stack. Not necessarily different work, just more of it.
Performance Consideration:
SIZE MATTERS! Big means increased latency. Small means faster. Splitting large components into multiple small components can yield better performance. However, because this approach increases the number of components and therefore the number of connections, it can actually worsen performance. The only way to know for sure is to try.
SIZE MATTERS! Oh, did I say that before? Well, it’s still true. And the best way to leverage this tip is to reduce the size of the webapp at both the macro and micro levels. At the macro level, supply the functionality the user needs, but don’t give him every whiz-bang that your imagination can come up with. Too much affects not only performance, but also usability. At the micro level, minify. Comments, extraneous white space, and super-long identifiers aren’t needed. Use a minifier to get rid of them.The physical layer, the data link layer, the network layer, the transport layer, and the session layer are all the same as in Part IV, so let’s not go there again. We’ll start (and end) at the second last layer – the presentation layer.
The Presentation Layer
In Part VIII (down the protocol stack on the server side), the presentation layer compressed and encrypted the resource. Here in the client machine, the presentation layer decrypts and uncompresses.
Performance Consideration:
SSL/TLS handshaking is still a concern because it happens once for every connection. The more connections we have, the more handshaking we have to bear. Now that HTTP uses persistent connections, this is not as much of a concern, but SPDY still outperforms HTTP because SPDY uses only one connection.
The Application Layer
The application layer extracts the component and passes it to the web browser. And that’s where the fun really begins… (to be continued)
For quick reference, here is the series’ table of contents:
Post Tagged with