Compare Revisions

Connection management in HTTP/1.x

Change Revisions

Revision 1121965:

Revision 1121965 by bunnybooboo on September 21, 2016 at 4:04:19 AM PDT

Revision 1121969:

Revision 1121969 by bunnybooboo on September 21, 2016 at 4:24:16 AM PDT

Title:

Connection management in HTTP/1.x

Slug:

Web/HTTP/Connection_management_in_HTTP_1.x

Tags:

"Guide" "HTTP" "Performance" "WebMechanics" "Performance"

Comment:

editorial review pipelining

completion of editorial review

Content:

	Revision 1121965			Revision 1121969
n	108	As an HTTP/1.x connection is serializing requests, even if	n	108	As an HTTP/1.x connection is serializing requests, even wit
	>	there is no real ordering between them, it can't be optimal, when		>	hout any ordering, it can't be optimal without large enough avail
	>	the available bandwidth is large enough. To work around this, br		>	able bandwidth. As a solution, browsers open several connections
	>	owsers open several connection to each domain and send request in		>	to each domain, sending parallel requests. Default was once 2 to
	>	parallel. Originally, they were opening 2 or 3 connections, but		>	3 connections, but this has now increased to a more common use of
	>	this increased and the most common amount of parallel connections		>	6 parallel connections. There is a risk of triggering <a href="/
	>	is now 6. They can't really open more of these without triggerin		>	en-US/docs/Glossary/DOS_attack">DoS</a> protection on the server
	>	g <a href="/en-US/docs/Glossary/DOS_attack">DoS</a> protection on		>	side if attempting more than this number.
	>	the server side.
n	111	If  the server wants that the Web site or application	n	111	If  the server wishes a faster Web site or application
	>	react faster, he can trick the browsers to open more connections.		>	response, it is possible for the server to force the opening of
	>	Instead of having all resources on the same domain, say <code>ww		>	more connections. For example, Instead of having all resources on
	>	w.example.com</code> it splits over several, like <code>www1.exam		>	the same domain, say <code>www.example.com</code>, it could spli
	>	ple.com</code>, <code>www2.example.com</code>, <code>www3.example		>	t over several domains, <code>www1.example.com</code>, <code>www2
	>	.com</code>. Each of these domains resolve to the <em>same</em> s		>	.example.com</code>, <code>www3.example.com</code>. Each of these
	>	erver, and the browsers will open 6 connections to each of them (		>	domains resolve to the <em>same</em> server, and the Web browser
	>	18 in our example). This technique is called <em>domain sharding<		>	will open 6 connections to each (in our example, boosting the co
	>	/em>.		>	nnections to 18). This technique is called <em>domain sharding</e
				>	m>.
t	120	Better connection management allows to considerably improve	t	120	Improved connection management allows considerable boosting
	>	performance of HTTP. With HTTP/1.1 or HTTP/1.0, using a persiste		>	of performance in HTTP. With HTTP/1.1 or HTTP/1.0, using a persi
	>	nt connection – at least until it gets idle – leads to the best p		>	stent connection – at least until it becomes idle – leads to the
	>	erformance. But, over the years and the failure of pipelining, be		>	best performance. However, the failure of pipelining has lead to
	>	tter connection management models have been designed and incorpor		>	designing superior connection management models, which have been
	>	ated into HTTP/2.		>	incorporated into HTTP/2.

Back to History