Comments on: Velocity: TCP and the Lower Bound of Web Performance

By: Johann

Johann — Thu, 03 Feb 2011 22:13:11 +0000

I’ve just tried to reproduce this with wget and Wireshark but I have not seen the delayed ACK behavior above but always one ACK for each packet.

Is this only happening on a certain operating system? (I’m using Linux)

Thanks

By: Will Alexander

Will Alexander — Thu, 09 Dec 2010 17:23:00 +0000

This page has an excellent animation that demonstrates the effect of slow-start and window scaling

http://www.osischool.com/protocol/Tcp/slowstart/index.php

By: Reed Hedges

Reed Hedges — Mon, 20 Sep 2010 17:07:30 +0000

Please don’t abandon a periodic blog post. It could be a summary of a week’s tweets or something… but reform them into sentences and paragraphs in that case, not just copy them, please :)

By: Cthulhu

Cthulhu — Wed, 21 Jul 2010 14:31:26 +0000

So, next to flushing early as Steve suggests, how can a web developer like me influence the order at which external resources (images, css etc) is downloaded? It makes sense that this happens sequentially, but that means that you can only have the browser download CSS and JS and other HEAD-resources before it downloads things like images – which may be smaller than CSS / JS and such.

Maybe sending a list of resources (+ their type and size) before or while sending the HTML (or whatever content) would be a worthwhile addition to the various internet standards. This’ll allow the browser itself to start downloading external resources (and prioritize them) while also downloading the HTML and other bits of the site. That is, if that really makes such a big difference.

By: Me, my self and I

Me, my self and I — Fri, 16 Jul 2010 05:10:02 +0000

Idunno. IMO, app responsiveness is a matter of design. Nowadays browsers and the HW platforms they’re running on allow moving quite a lot of the logic to the client. IMO, the best approach of creating responsive apps isn’t in optimizing the low level design of the data transfer layer, but moving most of the logic to the client, and have the client only communicate seldomly with the server, asynchronously, if possible, even if transferring large chunks of data at a time. The user won’t mind waiting a few seconds for a large form to be submitted – he’s used to wait a few seconds to save a large document or spreadsheet. But he surely will mind if each and every click needs half a second to be processed, because it is being processed server-side.

By: Billy Hoffman

Billy Hoffman — Thu, 15 Jul 2010 16:44:02 +0000

I would add another takeaway from John’s excellent research: new, HTTP connections are *very* expensive. Creation involves a 3-way handshake, and then you have slow-start. Developers should check to make sure their application code, CMS, or inline devices aren’t adding “Connection: closed” headers.

By: Steve Souders

Steve Souders — Thu, 15 Jul 2010 14:49:00 +0000

@Dana: This is flushing the document early.

By: Dana Andrews

Dana Andrews — Thu, 15 Jul 2010 13:22:23 +0000

What do you mean Willis ’2.2 Open connections for assets in the first three packets’? Is this like pre-loading images in javascript etc?

By: Roland Dobbins

Roland Dobbins — Thu, 15 Jul 2010 10:21:57 +0000

In addition to NVP, packet-regeneration times at each hop must be taken into account, as well.

By: Daniel Krsicka

Daniel Krsicka — Thu, 15 Jul 2010 08:17:28 +0000

Even if many other factors participate on overall web app latency, I must confirm all what’s here. And I’m glad to read this kind of article because from my experience only a small amount of developers know something more about network protocol stack.

What’s obvious but interesting to read in black and white is that latency of small frame/packet/segment on metalic or optical fiber is the same as before 15 years :-). IT proffesionals live in world where everything change day by day. It can suprising that physical principles stay the same :-).