What's the difference between "Queueing" time and "Stalled" time in network panel?

[Chen Yang]

It seems that the "Stalled" time is equal to the min value in Dns start time, Connect start time and Send start time.

According to this answer http://stackoverflow.com/questions/31240207/what-does-chrome-network-timings-really-mean-and-what-does-affects-each-timing-l/31248247#31248247 ,it occurs because of the the maximum connection limit.

But I still can't understand the "Queueing" time.It seems that the "Queueing" time is the difference between Issue time and Start time.

Can anyone explain the relationship and difference between "Queueing" time and "Stalled" time?

Thanks

[Kayce Basques]

Queuing
If a request is queued it indicated that:

• The request was postponed by the rendering engine because it's considered lower priority than critical resources (such as scripts/styles). This often happens with images.

• The request was put on hold to wait for an unavailable TCP socket that's about to free up.

• The request was put on hold because the browser only allows six TCP connections per origin on HTTP 1.

• Time spent making disk cache entries (typically very quick.)

Stalled/Blocking

• Time the request spent waiting before it could be sent. It can be waiting for any of the reasons described for Queueing. Additionally, this time is inclusive of any time spent in proxy negotiation.

Let me know if that helps.

Source: https://developers.google.com/web/tools/chrome-devtools/profile/network-performance/understanding-resource-timing?hl=en

[Chen Yang]

Thanks for your answer.

"It can be waiting for any of the reasons described for Queueing"

Dose this sentence mean the Stalled time should include Queuing time?

But I always get a long Queuing time and short Stalled time.

[Volkan Özçelik]

> Dose this sentence mean the Stalled time should include Queuing time?

Here is my understanding on that after reading the source code a bit. 

Please correct me and contribute since I’m not familiar with the Chromium C source code that much.

To my understanding, the entire flow is a state machine. Starting from the queueing state and going all the way towards content download.

The next state after queueing in the machine is stalled. Ergo the state machine starts with the queueing state; it waits there for a while; then it transitions to stalled state. — it may or may not wait there (in stalled state) for a while. and then it follows the rest of the lifecycle.

So a request may (and often does) get stalled after being dequeued already.

queueing and stalled are (to my understanding) two different states in the request’s lifecycle, and they don’t have any intersection and/or parent/child relationship.

You can kind of think stalled as a stage where the requests waits after it has been already dequeued (hence queueing is not possible afterall).

As I said these are my educated guesses; 

I’d appreciate any further insight on that.