https
ActivePublic
Actions

Authored by greg on Jan 29 2015, 5:53 PM.

Tags

None

Referenced Files

	F32936: https
	Jan 29 2015, 5:53 PM

Subscribers

None

	As I was saying on IRC two days ago, I don't think that that data is
	correct. The test used upload.wikimedia.org, at a time when the
	browser would already have a keepalive connection open to port 80 but
	not port 443. Client-side aborts caused by navigating away from the
	page are not logged, and so if the HTTP request completes earlier than
	the HTTPS request, this opens a window for a systemic error in the
	results. If the user navigates away after the completion of the HTTP
	request, but before the completion of the HTTPS request, this would be
	logged as an HTTPS failure.

	My theory two days ago was that the size of the window would be the
	time it took the browser to do the connection setup, or possibly the
	whole request. But it occurs to me now that the browser may have its
	maximum number of concurrent connections open when the test starts. So
	the request might be queued by the browser until a connection slot
	opens up. That queue wait time might depend on network bandwidth, as
	well as RTT.

	If both the HTTP and the HTTPS tests used a hostname which is unlikely
	to have a keepalive connection open, and if the order of the two tests
	was randomized rather than always sending the HTTP request first, then
	I think you would get closer to accurate results. However, actual
	performance differences between HTTPS and HTTP would still cause a
	systemic error.

	-- Tim Starling

greg changed the title of this paste from untitled to https.

greg updated the paste's language from autodetect to autodetect.

greg changed the edit policy from "All Users" to "greg (Greg Grossmeier)".

httpsActivePublicActions