diff options
Diffstat (limited to 'chromium/docs/website/site/developers/design-documents/network-stack/preconnect/index.md')
| -rw-r--r-- | chromium/docs/website/site/developers/design-documents/network-stack/preconnect/index.md | 93 |
1 files changed, 0 insertions, 93 deletions
diff --git a/chromium/docs/website/site/developers/design-documents/network-stack/preconnect/index.md b/chromium/docs/website/site/developers/design-documents/network-stack/preconnect/index.md deleted file mode 100644 index b915e0e8439..00000000000 --- a/chromium/docs/website/site/developers/design-documents/network-stack/preconnect/index.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -breadcrumbs: -- - /developers - - For Developers -- - /developers/design-documents - - Design Documents -- - /developers/design-documents/network-stack - - Network Stack -page_name: preconnect -title: Preconnect ---- - -## **[TOC]** - -## **Overview** - -The networking stack implements the blink interface for the [W3C Resource Hints -preconnect specification](http://www.w3.org/TR/resource-hints/#preconnect) to -allow site developers to request connections to servers in anticipation of -future requests. The predominant use cases are: - -1. sub-resources for the current page that the preload scanner is not - capable of identifying. This can include resources discovered by - styles being applied (background images, fonts) as well as resources - initiated by scripts (analytics beacons, ads domains, etc). -2. Top-level domains used in future navigations. For example, clinking - on a link to an url shortener or click tracker that then redirects - to the actual page. If the page knows the resulting final - destination it can start initiating the connection in parallel with - the navigation to the redirector. - -[Issue 450682](https://code.google.com/p/chromium/issues/detail?id=450682) -tracks the implementation as well as issues that came up during implementation -and experimentation. - -## Implementation Notes - -### Connection Pools (not all connections are the same) - -Chrome maintains separate connection pools for the various different protocols -(http, https, ftp, etc). Additionally, separate connection pools are managed for -connections where cookies can be transmitted and connections where they can not -in order to prevent tracking of users when a request is determined to be private -(when blocking cookies to third-party domains for example). The determination of -which connection pool a request will use is made at request time and depends on -the context in which it is being made. Top-level navigations go in the -cookie-allowed pool while sub-resource requests get assigned a pool based on the -domain of the request, the domain of the page and the user's privacy settings. - -Connections can not move from one pool to another so the determination of which -pool a connection will be assigned to needs to be made at the time when the -connection is being established. In the case of TLS connections, the cost of not -using a preconnected connection can be quite high, particularly on mobile -devices with limited resources. - -The initial implementation for preconnect did not take private mode into account -and all connections were pre-connected in the cookies-allowed connection pool -leading to -[situations](https://code.google.com/p/chromium/issues/detail?id=468005) where -the preconnected connection was not leveraged for the future request. - -### Preconnect Connection Pool Selection Heuristic (proposed) - -The two different use cases for preconnect require different treatment for -determining which connection pool a connection should belong to. In the case of -a sub-resource request the document URL should be considered and the relevant -privacy settings should be evaluated. In the case of the top-level navigation -the document URL should NOT be considered and the connection. There are no hints -that the site owner can provide to indicate what kind of request will be needed -so it is up to the browser to guess correctly. - -For preconnect requests that are initiated while the document is being loaded -(before the onload event while the HTML is being parsed and scripts are being -executed), Chrome will assume that preconnect requests are going to be for -sub-resources that are going to be requested in the context of the current -document and the connection pool will be selected by taking the owning -document's URL into account. - -For preconnect requests that are initiated after the document has finished -loading, Chrome will assume that preconnect requests will be used for future -page navigations and the connections will not take the current document's URL -into account when selecting a connection pool (which effectively means the -connection will be established in the allows-cookies pool). - -This does leave a few possible cases for mis-guessing but should handle the vast -majority of cases. Specifically: - -1. Top-level navigations that are preconnected before the page has - finished loading may end up in the wrong connection pool as the - document's URL will be considered. -2. Sub-resource requests that are preconnected after the page has - finished loading may end up in the wrong pool if the request - requires a private connection.
\ No newline at end of file |