输入网址到页面加载的过程涉及知识点众多，所以这里整理一下自己看过的相关文章内容。
在浏览器中输入URL（也就是网址）（URL是Uniform Resource Locator的缩写，即统一资源定位系统，也就是我们通常所说的网址）。
输入URL后，会进行解析（URL的本质就是统一资源定位符）
protocol :// username:password @ hostname[:port] / path / [;parameters][?query][#fragment]
URL一般包括几大部分：
与URL相比，还有
URI(Uniform Resource Identifier) 统一资源标识符。URI就是由某个协议方案表示的资源的定位标识符。协议 方案是指访问资源所使用的协议类型名称。
URN(Uniform Resource Name) 统一资源名称，
简单来说，就是URI是抽象的定义，不管用什么方法表示，只要能定位一个资源，就叫URI。
本来设想的的使用两种方法定位：1，URL，用地址定位；2，URN 用名称定位。
举个例子：去村子找个具体的人（URI），如果用地址：某村多少号房子第几间房的主人 就是URL， 如果用身份证号+名字 去找就是URN了。
原来uri包括url和urn，后来urn没流行起来，导致几乎目前所有的uri都是url。
缓存位置：
所谓的浏览器缓存就是浏览器将用户请求过的资源存储到本地电脑。当浏览器再次访问时就可以直接从本地进行加载，不需要去服务端进行请求。它减少不必要的数据传输，减少服务器负担担升网站性能，提高了客户端网页的打开速度。一般分为强缓存和协商缓存
当浏览器向服务器发起请求时，服务器会将缓存规则放入HTTP响应报文的HTTP头中和请求结果一起返回给浏览器，控制强制缓存的字段分别是Expires和Cache-Control，其中Cache-Control优先级比Expires高。 用户第一次访问页面之后，浏览器将数据存在缓存中，在过期时间之内，都不会再请求服务器。是否使用强制缓存在于资源是否过期，该过期时间从第一次请求的服务器响应头中获取。如果在过期时间内，从缓存中读取，如果超出过期时间，则使用协商缓存（下面会讲）。上面的200 from memory cache和200 from disk cache属于强制缓存。
协商缓存，是浏览器和服务器之间协商，那么浏览器每次都要和服务器通信。 在第一次请求服务器时，服务器会返回资源，并且返回一个资源的缓存标识，一起存到浏览器的缓存数据库。当第二次请求资源时，浏览器会首先将缓存标识发送给服务器，服务器拿到标识后判断标识是否匹配，如果不匹配，表示资源有更新，服务器会将新数据和新的缓存标识一起返回到浏览器；如果缓存标识匹配，表示资源没有更新，并且返回 304 状态码，浏览器就读取本地缓存服务器中的数据。
与协商缓存有关的字段是Last-Modified/IF-Modified-Since、Etag/IF-None-Match。
Last-Modified与ETag是可以一起使用的，服务器会优先验证ETag，一致的情况下，才会继续比对Last-Modified，最后才决定是否返回304。
不同情况下的过程可以参考下面几张图：
DNS全称 Domain Name System ,即域名系统。
通过域名,最终得到该域名对应的IP地址的过程叫做域名解析（或主机名解析）。
www.dnscache.com (域名) - DNS解析 -> 11.222.33.444 (IP地址)
DNS查询过程如下:
解析出IP地址后，根据IP地址和默认80端口，和服务器建立TCP连接。
建立tcp连接就是三次握手，三次握手的过程采用 TCP 协议，其可以保证信息传输的可靠性，三次握手过程中，若一方收不到确认信号，协议会要求重新发送信号
Accept: 接收类型，表示浏览器支持的MIME类型
（对标服务端返回的Content-Type）
Accept-Encoding：浏览器支持的压缩类型,如gzip等,超出类型不能接收
Content-Type：客户端发送出去实体内容的类型
Cache-Control: 指定请求和响应遵循的缓存机制，如no-cache
If-Modified-Since：对应服务端的Last-Modified，用来匹配看文件是否变动，只能精确到1s之内，http1.0中
Expires：缓存控制，在这个时间内不会请求，直接使用缓存，http1.0，而且是服务端时间
Max-age：代表资源在本地缓存多少秒，有效时间内不会请求，而是使用缓存，http1.1中
If-None-Match：对应服务端的ETag，用来匹配文件内容是否改变（非常精确），http1.1中
Cookie: 有cookie并且同域访问时会自动带上
Connection: 当浏览器与服务器通信时对于长连接如何进行处理,如keep-alive
Host：请求的服务器URL
Origin：最初的请求是从哪里发起的（只会精确到端口）,Origin比Referer更尊重隐私
Referer：该页面的来源URL(适用于所有类型的请求，会精确到详细页面地址，csrf拦截常用到这个字段)
User-Agent：用户客户端的一些必要信息，如UA头部等
Access-Control-Allow-Headers: 服务器端允许的请求Headers
Access-Control-Allow-Methods: 服务器端允许的请求方法
Access-Control-Allow-Origin: 服务器端允许的请求Origin头部（譬如为*）
Content-Type：服务端返回的实体内容的类型
Date：数据从服务器发送的时间
Cache-Control：告诉浏览器或其他客户，什么环境可以安全的缓存文档
Last-Modified：请求资源的最后修改时间
Expires：应该在什么时候认为文档已经过期,从而不再缓存它
Max-age：客户端的本地资源应该缓存多少秒，开启了Cache-Control后有效
ETag：请求变量的实体标签的当前值
Set-Cookie：设置和页面关联的cookie，服务器通过这个头部把cookie传给客户端
Keep-Alive：如果客户端有keep-alive，服务端也会有响应（如timeout=38）
Server：服务器的一些相关信息
100 —— Continue —— 继续，这个临时响应表明，收到了请求的起始部分，客户端应该继续请求，如果已经完成，则忽略它。
101 —— Switching Protocol —— 切换协议，服务器正根据客户端的指示将协议切换成 Update 首部列出的协议，并且指示服务器也正在切换的协议。
102 —— Processing —— 处理中，此代码表示服务器已收到并正在处理该请求，但没有响应可用。
103 —— Early Hints —— 早期提示，此状态代码主要用于与 Link 链接头一起使用，以允许用户代理在服务器仍在准备响应时开始预加载资源。
104 —199 —— 暂空
200 —— OK —— 请求成功，表明该请求被成功地完成，所请求的资源发送回客户端，在响应报文内，随状态码一起返回的信息会因方法的不同而发生改变。比如，使用 GET 方法时，对应请求资源的实体会作为响应返回；而使用 HEAD 方法时，对应请求资源的实体首部不随报文主体作为响应返回（即在响应中只返回首部，不会返回实体的主体部分）。
201 —— Created —— 已创建，对那些要服务器创建对象的请求来说，新的资源已创建完毕。这通常是在 POST 请求，或是某些 PUT 请求之后返回的响应。
202 —— Accepted —— 已接受)，请求已经接收到，但服务器尚未处理，还未响应。意味着不会有一个异步的响应去表明当前请求的结果，预期另外的进程和服务去处理请求，或者批处理。
203 —— Non-Authoritative Information —— 非权威信息，服务器已成功处理了请求，但返回的实体头部元信息不是在原始服务器上有效的确定集合，而是来自本地或者第三方的拷贝。当前的信息可能是原始版本的子集或者超集。例如，包含资源的元数据可能导致原始服务器知道元信息的超集。使用此状态码不是必须的，而且只有在响应不使用此状态码便会返回 200 OK 的情况下才是合适的。
204 —— No Content —— 没有内容，该状态码代表服务器接收的请求已成功处理，但在返回的响应报文中不含实体的主体部分。另外，也不允许返回任何实体的主体。比如，当从浏览器发出请求处理后，返回 204 响应，那么浏览器显示的页面不发生更新。一般在只需要从客户端往服务器发送信息，而对客户端不需要发送新信息内容的情况下使用。
205 —— Reset Content —— 重置内容，服务器成功处理了请求，且没有返回任何内容。但是与 204 响应不同，返回此状态码的响应要求请求者重置文档视图。该响应主要是被用于接受用户输入后，立即重置表单，以便用户能够轻松地开始另一次输入。与 204 响应一样，该响应也被禁止包含任何消息体，且以消息头后的第一个空行结束。
206 —— Partial Content —— 部分内容，该状态码表示客户端进行了范围请求，而服务器成功执行了这部分的 GET 请求。响应报文中包含由 Content-Range 指定范围的实体内容。
207 —— Multi-Status —— 多状态，由WebDAV(RFC 2518)扩展的状态码，代表之后的消息体将是一个XML消息，并且可能依照之前子请求数量的不同，包含一系列独立的响应代码。
208 —— Already Reported —— 已经报告，在 DAV 里面使用: propstat 响应元素以避免重复枚举多个绑定的内部成员到同一个集合。
209 —225 —— 暂空
226 —— IM Used —— 已完成响应，服务器已经完成了对资源的 GET 请求，并且响应是对当前实例应用的一个或多个实例操作结果的表示。
227 —299 —— 暂空
300 —— Multiple Choice —— 多项选择,被请求的资源有一系列可供选择的回馈信息，每个都有自己特定的地址和浏览器驱动的商议信息。用户或浏览器能够自行选择一个首选的地址进行重定向。
301 —— Moved Permanently —— 永久移除，永久重定向，请求的网页已永久移动到新位置， 请求的URI资源路径已经改变,新的URL会在响应的Location:头字段里找到
302 —— Found —— 已找到,临时重定向，服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来响应以后的请求，所请求的URL资源路径临时改变,并且还可能继续改变.因此客户端在以后访问时还得继续使用该URL.新的URL会在响应的Location:头字段里找到。
303 —— See Other —— 参见其他,该状态码表示由于请求对应的资源存在着另一个 URI，应使用 GET 方法定向获取请求的资源。
304 —— Not Modified —— 未修改,该状态码表示客户端发送附带条件的请求时，服务器端允许请求访问资源，但未满足条件的情况。304 状态码返回时，不包含任何响应的主体部分。附带条件的请求是指采用 GET 方法的请求报文中包含 If-Match，If-ModifiedSince，If-NoneMatch，If-Range，If-Unmodified-Since 中任一首部。
305 —— Use Proxy —— 使用代理,被请求的资源必须通过指定的代理才能被访问。Location 域中将给出指定的代理所在的 URI 信息，接收者需要重复发送一个单独的请求，通过这个代理才能访问相应资源。只有原始服务器才能建立305响应。
306 —— unused —— 未使用,在最新版的规范中，306 状态码已经不再被使用。
307 —— Temporary Redirect —— 临时重定向,临时重定向。该状态码与 302 Found 有着相同的含义。尽管 302 标准禁止 POST 变换成GET，但实际使用时大家并不遵守。307 会遵照浏览器标准，不会从 POST 变成 GET。但是，对于处理响应时的行为，每种浏览器有可能出现不同的情况。
308 —— Permanent Redirect —— 永久重定向，这意味着资源现在永久位于由 Location: HTTP Response 标头指定的另一个 URI。这与 301 Moved Permanently HTTP 响应代码具有相同的语义，但用户代理不能更改所使用的 HTTP 方法：如果在第一个请求中使用 POST，则必须在第二个请求中使用 POST。
309 —399 —— 暂空
400 —— Bad Request —— 错误请求，表示服务器无法理解该请求。客服端不应该在未经修改的情况下重复此请求。一般会因为前端提交数据的字段名称，或者是字段类型和后台的实体类不一致，导致无法封装。
401 —— Unauthorized —— 未经授权，请求要求身份验证，验证后才能获取所请求的内容，只要正确输入账号密码即可通过验证，也可以成为“HTTP基本验证”
402 —— Payment Required —— 要求付款,此响应码保留以便将来使用，创造此响应码的最初目的是用于数字支付系统，然而现在并未使用。
403 —— Forbidden —— 禁止访问，服务器拒绝请求，通常代表客户端错误，服务器端有能力处理请求，但是拒绝授权访问
404 —— Not Found —— 请求错误，可能是链接失效导致，或者是URL拼写错误，还有可能是由于Web服务器将所请求的资源移到了其它的地方，服务器找不到请求的网页
405 —— Method Not Allowed —— 不允许使用的方法,请求行中指定的请求方法不能被用于请求相应的资源。该响应必须返回一个 Allow 头信息用以表示出当前资源能够接受的请求方法的列表。鉴于 PUT，DELETE 方法会对服务器上的资源进行写操作，因而绝大部分的网页服务器都不支持或者在默认配置下不允许上述请求方法，对于此类请求均会返回 405 错误。
406 —— Not Acceptable —— 无法接受,请求的资源的内容特性无法满足请求头中的条件，因而无法生成响应实体。
407 —— Proxy Authentication Required —— 要求进行代理认证,与 401 响应类似，只不过客户端必须在代理服务器上进行身份验证。代理服务器必须返回一个 Proxy-Authenticate 用以进行身份询问。客户端可以返回一个 Proxy-Authorization 信息头用以验证。
408 —— Request Timeout —— 请求超时,请求超时。客户端没有在服务器预备等待的时间内完成一个请求的发送。客户端可以随时再次提交这一请求而无需进行任何更改。
409 —— Conflict —— 冲突,由于和被请求的资源的当前状态之间存在冲突，请求无法完成。这个代码只允许用在这样的情况下才能被使用：用户被认为能够解决冲突，并且会重新提交新的请求。该响应应当包含足够的信息以便用户发现冲突的源头。
410 —— Gone —— 消失了,被请求的资源在服务器上已经不再可用，而且没有任何已知的转发地址。这样的状况应当被认为是永久性的。如果可能，拥有链接编辑功能的客户端应当在获得用户许可后删除所有指向这个地址的引用。如果服务器不知道或者无法确定这个状况是否是永久的，那么就应该使用 404 状态码。除非额外说明，否则这个响应是可缓存的。
411 —— Length Required —— 要求长度指示,服务器拒绝在没有定义 Content-Length 头的情况下接受请求。在添加了表明请求消息体长度的有效 Content-Length 头之后，客户端可以再次提交该请求。
412 —— Precondition Failed —— 先决条件失败,服务器在验证在请求的头字段中给出先决条件时，没能满足其中的一个或多个。这个状态码允许客户端在获取资源时在请求的元信息（请求头字段数据）中设置先决条件，以此避免该请求方法被应用到其希望的内容以外的资源上。
413 —— Payload Too Large —— 请求实体太大,服务器拒绝处理当前请求，因为该请求提交的实体数据大小超过了服务器愿意或者能够处理的范围。此种情况下，服务器可以关闭连接以免客户端继续发送此请求。如果这个状况是临时的，服务器应当返回一个 Retry-After 的响应头，以告知客户端可以在多少时间以后重新尝试。
414 —— URI Too Long —— 请求 URI 太长,请求的 URI 长度超过了服务器能够解释的长度，因此服务器拒绝对该请求提供服务。这比较少见，通常的情况包括：本应使用 POST 方法的表单提交变成了 GET 方法，导致查询字符串（Query String）过长。
415 —— Unsupported Media Type —— 不支持的媒体类型,对于当前请求的方法和所请求的资源，请求中提交的实体并不是服务器中所支持的格式，因此请求被拒绝。
416 —— Range Not Satisfiable —— 范围不满足，所请求的范围未得到满足,如果请求中包含了 Range 请求头，并且 Range 中指定的任何数据范围都与当前资源的可用范围不重合，同时请求中又没有定义 If-Range 请求头，那么服务器就应当返回 416 状态码。
417 —— Expectation Failed —— 无法满足期望,此响应代码意味着服务器无法满足 Expect 请求标头字段指示的期望值。
418 —— I'm a teapot —— 我是个茶壶,服务器拒绝尝试用 “茶壶冲泡咖啡”。
421 —— Misdirected Request —— 请求方向错误,该请求针对的是无法产生响应的服务器。这可以由服务器发送，该服务器未配置为针对包含在请求 URI 中的方案和权限的组合产生响应。
422 —— Unprocessable Entity —— 不可处理的实体,请求格式良好，但由于语义错误而无法遵循。
423 —— Locked —— 已锁定,正在访问的资源被锁定。
424 —— Failed Dependency —— 失败的依赖关系,由于先前的请求失败，所以此次请求失败。
425 —— Too Early —— 太早,服务器不愿意冒着风险去处理可能重播的请求。
426 —— Upgrade Required —— 需要升级,服务器拒绝使用当前协议执行请求，但可能在客户机升级到其他协议后愿意这样做。服务器在 426 响应中发送 Upgrade (en-US) 头以指示所需的协议。
427 —— 暂空
428 —— Precondition Required —— 需要先决条件,原始服务器要求该请求是有条件的。旨在防止“丢失更新”问题，即客户端获取资源状态，修改该状态并将其返回服务器，同时第三方修改服务器上的状态，从而导致冲突。
429 —— Too Many Requests —— 请求太多,用户在给定的时间内发送了太多请求（“限制请求速率”）。
430 —— 暂空
431 —— Request Header Fields Too Large —— 请求头字段太大,服务器不愿意处理请求，因为它的 请求头字段太大（ Request Header Fields Too Large）。请求可以在减小请求头字段的大小后重新提交。
432 —— 448 —— 暂空
449 —— Retry With —— 重试方式，由微软扩展，代表请求应当在执行完适当的操作后进行重试。
450 —— 暂空
451 —— Unavailable For Legal Reasons —— 因法律原因无法使用,用户请求非法资源，例如：由政府审查的网页。
452 —— 499 —— 暂空
500 —— Internal Server Error —— 内部服务器错误，主要是由于程序代码和服务器配置这两个问题，对于代码而言，要对站点进行升级，对服务器而言大多是因为系统版本升级导致。
501 —— Not Implemented —— 未实现,此请求方法不被服务器支持且无法被处理。只有 GET 和 HEAD 是要求服务器支持的，它们必定不会返回此错误代码。
502 —— Bad Gateway —— 错误网关，从上游服务器收到无效响应，可能暂时，也可能永久
503 —— Service Unavailable —— 未提供此服务.该状态码表明服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。如果事先得知解除以上状况需要的时间，最好写入 RetryAfter 首部字段再返回给客户端。
504 —— Gateway Timeout —— 网关超时,当服务器作为网关，不能及时得到响应时返回此错误代码。
505 —— HTTP Version Not Supported —— 不支持的 HTTP 版本,服务器不支持请求中所使用的 HTTP 协议版本。
506 —— Variant Also Negotiates —— 变体也进行协商,服务器有一个内部配置错误：对请求的透明内容协商导致循环引用。
507 —— Insufficient Storage —— 存储不足,服务器有内部配置错误：所选的变体资源被配置为参与透明内容协商本身，因此不是协商过程中的适当端点。
508 —— Loop Detected —— 检测到环路,服务器在处理请求时检测到无限循环。
509 —— Bandwidth Limit Exceeded —— 超越带宽限制，服务器带宽有限，相比其他500状态码，509算是一个特殊的存在。之所以特殊，是由于这个错误要用钱来处理。509并不是官方的状态码，但是依然被普遍运用。正如名字所示，网站流量增大，带宽不够用就会呈现这类错误，网站管理员只能掏钱向主机商买流量。
510 —— Not Extended —— 未扩展,客户端需要对请求进一步扩展，服务器才能实现它。服务器会回复客户端发出扩展请求所需的所有信息。
511 —— Network Authentication Required —— 需要网络身份验证,客户端需要进行身份验证才能获得网络访问权限。这种状态不是由原始服务器生成的，而是通过拦截代理来控制对网络的访问。网络运营商在授予访问权限之前（例如在网吧或机场）有时需要一些认证，接受条款或其他用户互动。他们通常使用媒体访问控制（MAC）地址识别尚未这样做的客户。
512 —— 599 —— 暂空
1xx —— Informational(信息性状态码) ，表示请求已接收，继续处理
2xx —— Successful(成功状态码)，表示请求已被成功接收、理解、接受
3xx —— Redirection(重定向状态码)，要完成请求必须进行更进一步的操作
4xx —— Client error(客户端错误状态码)，请求有语法错误或请求无法实现
5xx —— Server error(服务器错误状态码)，服务器未能实现合法的请求
6xx —— Unparseable Response Headers(源站没有返回响应头部)，只返回实体内容
通过四次挥手释放TCP连接； 前 两 次挥手用于关闭一个方向的数据通道，后两次挥手用于关闭另外一个方向的数据通道。
TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。
TCP是全双工模式，这就意味着，当客户端发出FIN报文段时，只是表示客户端已经没有数据要发送了，客户端告诉服务器，它的数据已经全部发送完毕了；
但是，这个时候客户端还是可以接受来自服务端的数据；
当服务端返回ACK报文段时，表示它已经知道客户端没有数据发送了，但是服务端还是可以发送数据到客户端的；
当服务端也发送了FIN报文段时，这个时候就表示服务端也没有数据要发送了，就会告诉客户端，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。
客户端（浏览器）解析HTML内容并渲染出来，浏览器接收到数据包后的解析流程为：
这样会让浏览器尽早拿到 CSS 尽早生成 CSSOM ，然后在解析 HTML 之后可一次性生成最终的RenderTree ，渲染一次即可。如果 CSS 放在 HTML 底部，会出现渲染卡顿的情况，影响性能和体验。
JS 放在底部可以保证让浏览器优先渲染完现有的 HTML 内容，让用户先看到内容，体验好。另外， JS 执行如果涉及 DOM 操作，得等待 DOM 解析完成才行， JS 放在底部执行时， HTML 肯定都解析成了 DOM 结构。 JS 如果放在 HTML 顶部， JS 执行的时候 HTML 还没来得及转换为 DOM 结构，可能会报错。
一文带你理解URI 和 URL 有什么区别？ - 知乎
https://zhuanlan.zhihu.com/p/465487888
从输入URL到页面加载的过程？如何由一道题完善自己的前端知识体系！https://juejin.cn/post/6844903574535667719#heading-7
URL解析全过程
https://www.cnblogs.com/davina123/p/12978114.html
DNS 缓存、CDN 缓存、浏览器缓存，JVM DNS 缓存详解
https://blog.csdn.net/zzhongcy/article/details/115759564
【浏览器系列】从输入网址（URL）到页面加载的全过程
https://blog.csdn.net/pakerder/article/details/127324417
一键收藏！HTTP 响应状态码
https://blog.51cto.com/u_15891283/5886184