LoadTiming implementation in net, part 1.

net/base/load_timing_info.h

+// Copyright (c) 2012 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef LOAD_TIMING_INFO_H_

[eroman, 2012/12/14 04:08:35]

Shouldn't this be NET_BASE_LOAD_TIMING_INFO_H_ ?

[mmenke, 2012/12/14 13:36:12]

Done.  Odd that the linter didn't catch this.

+#define LOAD_TIMING_INFO_H_
+
+#include "base/basictypes.h"
+#include "base/time.h"
+#include "net/base/net_export.h"
+
+namespace net {
+
+// All events that do not apply to a request are NULL.  For non-HTTP requests,
+// all times other than the request_start times are NULL.
+//
+// The general order for events is:
+// request_start
+// proxy_start
+// proxy_end
+// *dns_start
+// *dns_end
+// *connect_start
+// *ssl_start
+// *connect_end
+// send_start
+// send_end
+// receive_headers_end
+//
+// Due to preconnect, late-binding, and cancelled requests, a request may use a

[eroman, 2012/12/14 04:08:35]

I found this paragraph challenging to read. Not sure I understood it.

[mmenke, 2012/12/14 13:36:12]

I've tried to make it easier to understand, but it's rather complicated.

Basically, the non-starred times are computed in a guaranteed order by objects
created and owned by the URLRequest.  The starred times are computed by the
ConnectJob.  A URLRequest may be assigned a ClientSocketHandle created by a
ConnectJob that started before the URLRequest started, or while it was resolving
the proxy.  The ConnectJob it ends up getting a socket from could have been that
for another, lower priority, request, or that for a preconnect.

We could modify the times so there is a guaranteed ordering (And in fact, we may
well want to do that, before passing the data to WebKit), but not sure we should
be doing that in the network stack.  It's also not clear how we should be doing
this - we could just chop off dns / connect / ssl times that occur too early,
but proxy times are reported by the NavigationTiming API, so it may make more
sense to modify the proxy times instead, and then clip the others by
request_start.

Since choices here are based more on WebKit/NavigationTiming API behavior, think
they make more sense in chrome/ than they do here.

+// fresh connection that was started before the request was issued.  In this
+// case, while the events without a * will always appear in the same order
+// relative to each other, and those with a * will as well, starred events may
+// occur before, during, or after request_start and proxy events.  socket_reused
+// will be false in this case.
+struct NET_EXPORT LoadTimingInfo {
+  LoadTimingInfo();
+  ~LoadTimingInfo();
+
+  // True if the socket was reused.  When true, DNS, connect, and SSL times
+  // will all be NULL.  When false, those times may be NULL, too, if the socket
+  // was preconnected.
+  bool socket_reused;
+
+  // Unique socket ID, can be used to identify requests served by the same
+  // socket.
+  // TODO(mmenke):  Do something reasonable for SPDY proxies.
+  uint32 socket_log_id;
+
+  base::Time request_start_time;

[eroman, 2012/12/14 04:08:35]

Why is this a Time whereas the rest are TimeTicks?

[mmenke, 2012/12/14 13:36:12]

Added a comment.  This is the same thing LoadTimingObserver does - all times are
recorded in TimeTicks, so that the deltas aren't affected by clock changes, but
the underlying API wants real times, so need a base::Time to convert TimeTicks
to times.

We could get rid of this field, and let the consumer worry about it all, but we
already record the Time we send a request, and it has to be a Time, since we
save it in the cache for expiration logic, so seemed reasonable to store it
here.

+  base::TimeTicks request_start;
+
+  // The time spent determing which proxy to use.
+  base::TimeTicks proxy_start;

[eroman, 2012/12/14 04:08:35]

Nit: I would suggest calling this proxy_resolve_start instead, so it is not
confused with the time spent connecting to the proxy.

[mmenke, 2012/12/14 13:36:12]

SGTM.  Done.

+  base::TimeTicks proxy_end;
+
+  // The time spent looking up the host's DNS address.  NULL for requests that
+  // used proxies to look up the DNS address.  Also NULL for SOCKS4 proxies,

[eroman, 2012/12/14 04:08:35]

Seems we *could* include this for SOCKS4. If needed, we could do the DNS resolve
first (in fact seems desirable to do that). No action necessary for this CL.

[mmenke, 2012/12/14 13:36:12]

Sounds reasonable to me.  Looked to me like it would require a fair bit of
refactoring, though I didn't spend much time investigating.

+  // since the DNS address is only looked up after the connection is
+  // established, which results in unexpected event ordering.
+  base::TimeTicks dns_start;
+  base::TimeTicks dns_end;
+
+  // The time spent establishing the connection started. Connect time includes
+  // proxy DNS lookup times, blocking, TCP, TCP retries and SSL time.

[eroman, 2012/12/14 04:08:35]

Is this what webtiming expects too? (I could see how proxy DNS might fit into
proxy_start/proxy_end instead).

[mmenke, 2012/12/14 13:36:12]

The spec is unclear.  I talked to one of the NavigationTiming API authors (Who
conveniently works at Google), and this is the behavior he suggested.

+  base::TimeTicks connect_start;
+  base::TimeTicks connect_end;
+
+  // The time when the SSL handshake started / completed. For non-HTTPS requests
+  // these are NULL.  These times are only for the SSL connection to the final
+  // destination server, not an SSL/SPDY proxy.
+  base::TimeTicks ssl_start;
+  base::TimeTicks ssl_end;
+
+  // The time that sending HTTP request started / ended.
+  base::TimeTicks send_start;
+  base::TimeTicks send_end;
+
+  // The time at which the end of the HTTP headers were received.
+  base::TimeTicks receive_headers_end;
+};
+
+}  // namespace net
+
+#endif  // LOAD_TIMING_INFO_H_