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! 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.
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
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
For quick reference, here is the series’ table of contents:
- Part I – an overview of the entire process from beginning to end
- Part II – down the protocol stack (client side)
- Part III – the journey from client to server
- Part IV – up the protocol stack (server side)
- Part V – the web server (software)
- Part VI – the server side script
- Part VII – the database management system
- Part VIII – down the protocol stack (server side)
- Part IX – the journey from server to client
- Part X (this one) – up the protocol stack (client side)
- Part XI – the client-side script
- Part XII – the Document Object Model
- Part XIII – after the document is complete
- Part XIV – concurrency
- Part XV – wrap-up; best practices
