摘要
当我们访问网页时，打开chrome浏览器的开发者工具DevTools，在Network(网络)面版我们可以看到访问当前页面所发出的所有请求，鼠标移到任一请求的Waitfull列，或者选中任一请求，点击Timing，我们就可以看到chrome浏览器资源加载时序信息，见下图：
由图可得知，从资源加载时序的角度分析，浏览器发起请求到页面渲染完成会经历如下几个阶段：
时序分解阶段说明（内容翻译自官方文档 Chrome 开发者工具-网络功能参考）：
上图的过程大致可以分为三个大的阶段：
缓存相关：主要包括Prompt for unload,redirect和App cache3个过程
网络相关：主要包括DNS,TCP和HTTP(Request,Response)3个过程
浏览器相关：主要包括Processing和onload两个过程
通过将整个过程细分为3个大的阶段，然后再每个阶段每个阶段介绍，这样方便我们记忆和理解。
这边对一个完整的URL 解析过程大致总结为以下7个步骤：
1、URL解析：地址栏输入地址，浏览器对输入内容进行解析，判断URL的合法性，和是否有可用缓存
2、DNS解析：域名解析系统（DNS）查找对应的IP地址
3、建立TCP连接（三次握手）：浏览器向服务器发起TCP连接，与浏览器建立TCP三次握手
4、HTTP请求：浏览器将http请求数据发给服务器（客户端–>服务器）
5、HTTP响应：服务器处理收到的请求，返回响应结果至浏览器（服务器–>客户端）
6、关闭TCP连接（四次挥手）：数据传输完成后，还要经过四次握手以终止连接
7、页面渲染：浏览器解析响应结果，进行页面渲染
以上步骤中，1为缓存相关，2、3、4、5、6为网络相关，7为浏览器相关
1、当用户在浏览器地址栏输入内容时，浏览器会去解析输入的字符串,判断是URL还是搜索关键字，要是解析为URL则开始寻求URL对应的IP地址，否则按照搜索关键字处理交给默认搜索引擎搜索。
2、卸载已有的页面(Prompt for unload)
我们在页面中输入URL时，首先会卸载掉原来的页面。这是为了释放页面占据的内存，否则每请求一次URL都占据一份内存，会导致浏览器占据内存越来越大。
3、重定向(redirect)
所谓的重定向实际上就是先从本地缓存中去查找请求的内容，如果本地缓存中有则直接使用，如果没有则向服务器进行请求(这只是简单的理解，实际上如何获取数据是存在缓存策略的)。事实上，每次从服务器获取到文件，文件会被暂时存放到一个指定区域，当我们下次再次请求这个文件时，浏览器会首先从这个区域查看是否已经存在过这个文件，如果已经存在，则不需要再次进行请求数据。
4、App cache
相关应用程序缓存，资源是从相关应用缓存或本地资源（包括 HTTP缓存）中获取的。
浏览器缓存相关问题：
浏览器的缓存策略有哪些？
浏览器每次发起请求时，先在本地缓存中查找结果以及缓存标识，根据缓存标识来判断是否使用本地缓存。如果缓存有效，则使用本地缓存；否则，则向服务器发起请求并携带缓存标识。
根据是否需向服务器发起HTTP请求，将缓存过程划分为两个部分：强缓存和协商缓存，强缓存优先于协商缓存。
强缓存，服务器通知浏览器一个缓存时间，在缓存时间内，下次请求，直接用缓存，不在时间内，执行比较缓存策略。
协商缓存，让客户端与服务器之间能实现缓存文件是否更新的验证、提升缓存的复用率，将缓存信息中的Etag和Last-Modified
通过请求发送给服务器，由服务器校验，返回304状态码时，浏览器直接使用缓存。
HTTP缓存都是从第二次请求开始的：
第一次请求资源时，服务器返回资源，并在response header中回传资源的缓存策略；
第二次请求时，浏览器判断这些请求参数，击中强缓存就直接200，否则就把请求参数加到request header头中传给服务器，看是否击中协商缓存，击中则返回304，否则服务器会返回新的资源。
参考内容：Http 缓存策略，有什么区别，分别解决了什么问题
浏览器缓存控制机制有哪些？
浏览器缓存控制机制有两种：HTML Meta标签 和HTTP头信息
使用HTML Meta 标签：
HTML Meta标签是应用在HTML文件中的head头部分。主要作用就是告诉浏览器此HTML页面不被缓存，每次访问都去服务器上下载。使用上很简单，但只有部分浏览器可以支持，而且所有缓存代理服务器都不支持，因为代理不解析HTML内容本身。所以常说的浏览器缓存还是通过http头信息来控制缓存
使用HTTP头信息控制缓存：
通过浏览器开发者工具我们可以看到，浏览器请求服务器静态资源的响应状态码主要就是下图的三种：
页面的缓存状态是由HTTP协议中关于缓存的信息头决定的，主要的控制关键字有4种：Last-Modified、Etag、Cache-Control、Expires
Cache-Control 和 Expires首部用于指定缓存时间，Last-Modified和ETag 首部提供验证机制
更多详细内容参考：彻底理解浏览器的缓存机制（http缓存机制）
哪些请求不能被缓存？
1、HTTP 信息头中包含 Cache-Control:no-cache，pragma:no-cache，或 Cache-Control:max-age=0 等告诉浏览器不用缓存的请求
2、需要根据 Cookie，认证信息等决定输入内容的动态请求是不能被缓存的
3、经过 HTTPS 安全加密的请求（有人也经过测试发现，ie 其实在头部加入 Cache-Control：max-age 信息，firefox 在头部加入 Cache-Control:Public 之后，能够对 HTTPS 的资源进行缓存，参考《HTTPS 的七个误解》）
4、POST 请求无法被缓存
5、HTTP 响应头中不包含 Last-Modified/Etag，也不包含 Cache-Control/Expires 的请求无法被缓存
部署时缓存的问题：我们不仅要缓存代码，还需要更新代码。如果静态资源名字不变，怎么让浏览器即能缓存又能在有新代码时更新？
最简单的解决方式就是静态资源路径添加一个版本值，版本不变就走缓存策略，版本变了就加载新资源。如下：
<script src="xx/xx.js?v=24334452"></script>
然而这种处理方式在部署时有问题。
解决方法：静态资源和页面是分开部署
先部署页面再部署静态资源，会出现用户访问到旧的资源
先部署静态资源再部署页面，会出现没有缓存用户加载到新资源而报错
这些问题的本质是以上的部署方式是“覆盖式发布”，解决方式是“非覆盖式发布”。即用静态资源的文件摘要信息给文件命名，这样每次更新资源不会覆盖原来的资源，先将资源发布上去。这时候存在两种资源，用户用旧页面访问旧资源，然后再更新页面，用户变成新页面访问新资源，就能做到无缝切换。简单来说就是给静态文件名加hash值。
那如何实现呢？使用webpack持久化缓存
现在前端代码都用webpack之类的构建工具打包，浏览器有其缓存机制，想要既能缓存又能在部署时没有问题，需要给静态文件名添加hash值。在webpack中，有些配置能让我们实现持久化缓存。
更多详细内容参考：webpack持久化缓存
关于URL的拓展介绍：
URL定义
统一资源定位系统（uniform resource locator;URL）是因特网的万维网服务程序上用于指定信息位置的表示方法
URL语法
举个栗子：protocol://hostname:port/path/index.html?query=1&query1=3#detail
一个完整的URL包括：
协议部分、域名部分、端口部分、虚拟目录部分、文件名部分、参数部分、锚部分，如下图：
| 位置 | 参数 | 解析 |
|---|---|---|
| 协议 | protocol | 指定使用的传输协议，最常用的是HTTP协议，是目前WWW中应用最广的协议。其他常用的有： http:// 通过 HTTP 访问资源；https:// 通过安全的 HTTPS 访问资源；file:/// 访问本地资源；ftp:// 通过 FTP访问资源 … |
| 域名 | hostname | 是指存放资源的服务器的 域名 系统 ( DNS ) 主机名或 IP 地址 ，有时，在主机名前也可以包含连接到服务器所需的用户名和密码（格式：username:password） |
| 端口 | port | 整数，可选，省略时使用方案的默认端口，各种传输协议都有默认的端口号，如HTTP为80，HTTPS为443。如果输入时省略，则使用默认端口号。有时候出于安全或其他考虑，可以在服务器上对端口进行重定义，即采用非标准端口号，此时，URL中就不能省略端口号这一项 |
| 虚拟目录 | path | 由零或多个“/”符号隔开的字符串，一般用来表示主机上的一个目录或文件地址 |
| 文件 | index | 文件名称 |
| 参数 | query | 可选，GET模式的窗体参数，以“?”字符为起点，用于给动态网页 （如使用 CGI 、 ISAPI 、 PHP / JSP / ASP / ASP.NET 等技术制作的网页）传递参数，每个参数以“&”隔开，再以“=”分开参数名称与数据，通常以UTF8的URL编码，避开字符冲突的问题 |
| 锚 | detail | 是资源本身的另一部分的锚点. 锚点表示资源中的一种“书签”，给浏览器显示位于该“加书签”位置的内容的方向。例如，在HTML文档上，浏览器将滚动到定义锚点的位置;在视频或音频文档上，浏览器将尝试转到锚代表的时间。值得注意的是，＃后面的部分（也称为片段标识符）从来没有发送到请求的服务器 |
URL编码
通常如果一样东西需要编码，说明这样东西并不适合传输。原因多种多样，如Size过大，包含隐私数据，对于URL来说，之所以要进行编码，是因为URL中有些字符会引起歧义。URL的编码格式采用的是ASCII码，而不是Unicode，这也就是说你不能在URL中包含任何非ASCII字符，例如中文。否则如果客户端浏览器和服务端浏览器支持的字符集不同的情况下，中文可能会造成问题。所以需要对非ASCII码进行编码，这也便于后续的DNS查询。
Url编码的原则就是使用安全的字符（没有特殊用途或者特殊意义的可打印字符）去表示那些不安全的字符。
举个栗子：
网址URL中常见特殊字符转义编码参照表：
| 字符 | URL编码值 |
|---|---|
| 空格 | %20 |
| ! | %21 |
| " | %22 |
| # | %23 |
| $ | %24 |
| % | %25 |
| & | %26 |
| ’ | %27 |
| ( | %28 |
| ) | %29 |
| * | %2A |
| + | %2B |
| , | %2C |
| / | %2F |
| : | %3A |
| ; | %3B |
| < | %3C |
| = | %3D |
| > | %3E |
| ? | %3F |
| @ | %40 |
| [ | %5B |
| \ | %5C |
| ] | %5D |
| 竖线 | %7C |
更多关于URL编码的介绍可参考：网址URL中特殊字符转义编码
整个网络相关部分，其实中间经历了五层网络协议栈，即：客户端发出http请求到服务器接收，中间会经过一系列的流程。
客户端发送请求流程：从应用层发动http请求，到传输层通过三次握手建立tcp/ip连接，再到网络层的ip寻址，再到数据链路层的封装成帧，最后在物理层通过物理介质传输。
服务端接收请求流程：反过来。
五层网络协议：
| 五层网络协议 | 协议 | 作用 |
|---|---|---|
| 应用层 | DNS，HTTP | DNS解析成IP并发送http请求 |
| 传输层 | TCP，UDP | 建立TCP连接（3次握手） |
| 网络层 | IP，ARP | IP寻址 |
| 数据链路层 | PPP | 封装成帧 |
| 物理层 | 利用物理介质传输比特流 | 物理传输（通过双绞线，电磁波等各种介质） |
用户访问网页，DNS服务器（域名解析系统）会根据用户提供的域名查找对应的IP地址。
域名解析服务器是基于UDP协议实现的一个应用程序，通常通过监听53端口来获取客户端的域名解析请求。
DNS(Domain Name System)域名系统，顾名思义是用来解析域名系统的。在网络中，我们人适合于记忆文本，因此我们输入的都是www.baidu.com这种字符串，但是计算机适合于处理数字，每一台计算机对应的是一个IP地址。因此，如果我们要访问一个指定的资源，必须先找到对应的服务器，而找到服务器需要先将域名转换为对应的IP地址。而DNS就是帮助我们实现这个过程。
DNS查找过程如下：
关于DNS的详细介绍可参考：DNS解析的过程是什么，求详细的
接下来我们将详细讲解URL解析过程中的：建立TCP连接、HTTP请求、HTTP响应、关闭TCP连接 几个阶段
这几个阶段大致可归纳为：三个阶段：
连接建立时会有三次握手，连接释放时会有四次挥手
以访问百度为例，我们通过抓包工具WireShark获取到相应的数据包，可以清晰的看出TCP建立连接时三次握手、HTTP数据传输和TCP关闭连接时四次挥手的过程，见下图：
建立连接过程中要解决以下三个问题：
建立连接的方式-客户服务器方式
1、什么是 TCP 呢？
TCP（Transmission Control Protocol 传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议
2、TCP协议的作用
TCP协议的作用是将数据流从一台主机可靠地传输到另一台主机，保证连接的可靠，包括防丢、防错
3、TCP报文的头部结构：
在了解TCP连接之前先来了解一下TCP报文的头部结构：
上图中有几个字段需要重点介绍下：
（1）序号：seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。
（2）确认序号：ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，ack=seq+1。
（3）标志位：共6个，即URG、ACK、PSH、RST、SYN、FIN等，具体含义如下：
ACK：确认序号有效。
FIN：释放一个连接。
PSH：接收方应该尽快将这个报文交给应用层。
RST：重置连接。
SYN：发起一个新连接。
URG：紧急指针（urgent pointer）有效。
需要注意的是：
浏览器通过DNS获取到web服务器真实IP地址后，便向服务器发起TCP连接请求，通过TCP的三次握手建立连接后，浏览器便可以将http请求数据发送给服务器了
三次握手：
第一次握手：建立连接。客户端发送连接请求报文段，将SYN位置为1，Sequence Number为x；然后，客户端进入SYN_SEND状态，等待服务器的确认；
第二次握手：服务器收到SYN报文段。服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，设置Acknowledgment Number为x+1(Sequence Number+1)；同时，自己还要发送SYN请求信息，将SYN位置为1，Sequence Number为y；服务器端将上述所有信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN+ACK报文段。然后将Acknowledgment Number设置为y+1，向服务器发送ACK报文段，这个报文段发送完毕以后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。
三次握手动态过程：
三次握手通俗解释：
把客户端比作男孩，服务器比作女孩，用他们的交往来说明“三次握手”过程：
（1）男孩喜欢女孩，于是写了一封信告诉女孩：我爱你，请和我交往吧！（写完信之后，男孩焦急地等待，因为不知道信能否顺利传达给女孩）
（2）女孩收到男孩的情书后，心花怒放，原来我们是两情相悦呀！于是给男孩写了一封回信：我收到你的情书了，也明白了你的心意，其实，我也喜欢你！我愿意和你交往！（写完信之后，女孩也焦急地等待，因为不知道回信能否能顺利传达给男孩）
（3）男孩收到回信之后很开心，因为发出的情书女孩收到了，并且从回信中知道了女孩喜欢自己，并且愿意和自己交往。然后男孩又写了一封信告诉女孩：你的心意和信我都收到了，谢谢你，还有我爱你！
（女孩收到男孩的回信之后，也很开心，因为发出的情书男孩收到了。由此男孩女孩双方都知道了彼此的心意，之后就快乐地交流起来了~~）
这就是通俗版的“三次握手”，期间一共往来了三封信也就是“三次握手”，以此确认两个方向上的数据传输通道是否正常。
数据传输：
完成了三次握手，客户端和服务器端就可以开始传输数据了
发送HTTP请求的过程就是构建HTTP请求报文并通过TCP协议发送到服务器指定端口(HTTP协议80/8080, HTTPS协议443)
HTTP协议：超文本传输协议（HTTP，HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议，所有的WWW文件都必须遵守这个标准
HTTP是应用层协议，也是一个无状态的协议，它的任务是与服务器交换信息，至于怎么连到服务器，怎么保证数据正确，HTTP不管（连接是否可靠，数据是否正确，是否丢包的任务是由TCP协议负责的），它总是假设数据是正确地传输的
HTTP协议通常承载于TCP协议之上，有时也承载于TLS或SSL协议层之上，这个时候，就成了我们常说的HTTPS
HTTPS 的全称是 Hypertext Transfer Protocol Secure，从名称我们可以看出 HTTPS 要比 HTTPS 多了 secure 安全性这个概念，实际上， HTTPS 并不是一个新的应用层协议，它其实就是 HTTP + TLS/SSL 协议组合而成，而安全性的保证正是 TLS/SSL 所做的工作。也就是说，HTTPS 就是身披了一层 SSL 的 HTTP
HTTP请求报文是由三部分组成:：请求行、请求头和请求体
下面是一个实际的请求报文：
①是请求方法，GET和POST是最常见的HTTP方法，除此以外还包括DELETE、HEAD、OPTIONS、PUT、TRACE
②为请求对应的URL地址，它和报文头的Host属性组成完整的请求URL
③是协议名称及版本号
④是HTTP的报文头，报文头包含若干个属性，格式为“属性名:属性值”，服务端据此获取客户端的信息
⑤是报文体，它将一个页面表单中的组件值通过param1=value1¶m2=value2的键值对形式编码成一个格式化串，它承载多个请求参数的数据。不但报文体可以传递请求参数，请求URL也可以通过类似于“/chapter15/user.html? param1=value1¶m2=value2”的方式传递请求参数。
请求行
请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本
格式：Method Request-URL HTTP-Version CRLF
例子：GET /index.html HTTP/1.1
请求头
请求报头允许客户端向服务器传递请求的附加信息和客户端自身的信息。
PS: 客户端不一定特指浏览器，有时候也可使用Linux下的CURL命令以及HTTP客户端测试工具等。
常见的请求报头有: Accept, Accept-Charset, Accept-Encoding, Accept-Language, Content-Type, Authorization, Cookie, User-Agent等，如下图示例：
常用的请求头名称和解释
| 名称 | 解释 |
|---|---|
| Accept | 接受类型，表示浏览器支持的MIME类型 |
| Accept-Encoding | 浏览器支持的压缩类型，如gzip等，超出类型不能接收 |
| Content-Type | 客户端发送出去实体内容的类型 |
| Cache-Control | 指定请求和响应遵循的缓存机制 |
| If-Modifyied-Since | 用来匹配文件是否有变动 |
| If-None-Match | 用来匹配文件内容是否改变 |
| cookie | 有cookie并且同域访问时会自动带上 |
| Connection | 当浏览器与服务器通信时对于长连接如何进行处理，如keep-alive |
| Origin | 最初的请求是从哪里发起的 |
| Host | 请求服务器的url |
| Referer | 该页面的来源URL |
| User-Agent | 用户代理：记录用户的浏览器类型、操作系统及版本、CPU 类型、浏览器渲染引擎、浏览器语言、浏览器插件等信息 |
请求体
将一些需要的参数都放入请求体(body)中进行传入的方式，常用于post请求
常见的post请求body的参数形式（Content-Type）:
| Content-Type | 解释 | 在postman中等价于 |
|---|---|---|
| application/x-www-form-urlencoded | 能传输文本（不能传输数据流，文件）的键值对，不能用来上传二进制数据流，比如图片上传等 | x-www-form-urlencoded |
| multipart/form-data | 能传输数据流（上传）的键值对，既可以上传(多个)文件等二进制数据，也可以上传表单键值对 | form-data |
| application/json | 告诉服务端消息主体是序列化的JSON字符串 | raw中的json |
| text/xml | 是一种使用 HTTP 作为传输协议，XML 作为编码方式的远程调用规范 | raw中的text/xml |
| application/octet-stream | 只可以上传二进制数据，通常用来上传文件，由于没有键值，所以，一次只能上传一个文件 | binary |
从服务器接收请求到对应后台接收到请求，内部会有很多处理，包括：负载均衡和后台处理
负载均衡
对于大型项目，并发访问很大，一台服务器吃不消，一般会有若干台服务器组成一个集群，然后配合反向代理实现均衡负载。均衡负载不止一种实现方式。
概括的说：用户发送的请求指向调度服务器（反向代理服务器，比如nginx的均衡负载），然后调度服务器根据实际的调度算法，分配不同的请求给对应的集群中的服务器执行，然后调度服务器等待实际服务器的HTTP响应，并且反馈给用户。
后台处理
一般后台都部署到容器中。过程如下：
（1）先是容器接收到请求（比如tomcat容器）
（2）然后对应容器中的后台程序接收到请求（比如java程序）
（3）然后就是后台自己的统一处理，处理完毕后响应结果
具体概括一下：
（1）一般有的后端有统一的验证，比如安全拦截，跨域验证
（2）如果不符合验证规则，就直接返回相应的http报文（拒绝请求等）
（3）如果验证通过了，才会进入到实际的后台代码，此时程序接收到请求，然后执行查询数据库，大量计算等等
（4）等程序执行完毕后，会返回一个http响应包（一般这一步会经过多层封装）
（5）然后将这个数据包从服务端返回到客户端，完成交互
下面是一个实际的响应报文：
①是报文协议及版本
②是状态码及描述
③和请求头一样，由属性组成
④是服务器返回给客户端的文本信息
响应行
响应行由报文协议及版本和状态码及描述组成，如：HTTP/1.1 200 OK
HTTP响应状态码由三个十进制数字组成，第一个十进制数字定义了状态码的类型，后两个数字没有分类的作用
HTTP状态码共分为5种类型：
| 分类 | 分类描述 |
|---|---|
| 1** | 指示信息，服务器收到请求，需要请求者继续执行操作 |
| 2** | 成功，操作被成功接收并处理 |
| 3** | 重定向，需要进一步的操作以完成请求 |
| 4** | 客户端错误，请求包含语法错误或无法完成请求 |
| 5** | 服务器错误，服务器在处理请求的过程中发生了错误 |
HTTP状态码总列表：
| 状态码 | 英文名称 | 描述 |
|---|---|---|
| 100 | Continue | 继续。客户端应继续其请求 |
| 101 | Switching Protocols | 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议 |
| 200 | OK | 请求成功。一般用于GET与POST请求 |
| 201 | Created | 已创建。成功请求并创建了新的资源 |
| 202 | Accepted | 已接受。已经接受请求，但未处理完成 |
| 203 | Non-Authoritative Information | 非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本 |
| 204 | No Content | 无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档 |
| 205 | Reset Content | 重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域 |
| 206 | Partial Content | 部分内容。服务器成功处理了部分GET请求 |
| 300 | Multiple Choices | 多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择 |
| 301 | Moved Permanently | 永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替 |
| 302 | Found | 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI |
| 303 | See Other | 查看其它地址。与301类似。使用GET和POST请求查看 |
| 304 | Not Modified | 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源 |
| 305 | Use Proxy | 使用代理。所请求的资源必须通过代理访问 |
| 306 | Unused | 已经被废弃的HTTP状态码 |
| 307 | Temporary Redirect | 临时重定向。与302类似。使用GET请求重定向 |
| 400 | Bad Request | 客户端请求的语法错误，服务器无法理解 |
| 401 | Unauthorized | 请求要求用户的身份认证 |
| 402 | Payment Required | 保留，将来使用 |
| 403 | Forbidden | 服务器理解请求客户端的请求，但是拒绝执行此请求 |
| 404 | Not Found | 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面 |
| 405 | Method Not Allowed | 客户端请求中的方法被禁止 |
| 406 | Not Acceptable | 服务器无法根据客户端请求的内容特性完成请求 |
| 407 | Proxy Authentication Required | 请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权 |
| 408 | Request Time-out | 服务器等待客户端发送的请求时间过长，超时 |
| 409 | Conflict | 服务器完成客户端的 PUT 请求时可能返回此代码，服务器处理请求时发生了冲突 |
| 410 | Gone | 客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置 |
| 411 | Length Required | 服务器无法处理客户端发送的不带Content-Length的请求信息 |
| 412 | Precondition Failed | 客户端请求信息的先决条件错误 |
| 413 | Request Entity Too Large | 由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息 |
| 414 | Request-URI Too Large | 请求的URI过长（URI通常为网址），服务器无法处理 |
| 415 | Unsupported Media Type | 服务器无法处理请求附带的媒体格式 |
| 416 | Requested range not satisfiable | 客户端请求的范围无效 |
| 417 | Expectation Failed | 服务器无法满足Expect的请求头信息 |
| 500 | Internal Server Error | 服务器内部错误，无法完成请求 |
| 501 | Not Implemented | 服务器不支持请求的功能，无法完成请求 |
| 502 | Bad Gateway | 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应 |
| 503 | Service Unavailable | 由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中 |
| 504 | Gateway Time-out | 充当网关或代理的服务器，未及时从远端服务器获取请求 |
| 505 | HTTP Version not supported | 服务器不支持请求的HTTP协议的版本，无法完成处理 |
响应头
如下图示例：
常用的响应头名称和解释：
| 名称 | 解释 |
|---|---|
| Content-Encoding | 服务器返回对应的编码格式 |
| Content-Type | 服务端返回的实体内容的类型 |
| Max-age | 客户端本地资源应该缓存多少秒 |
| Last-Modified | 请求资源的最后修改时间 |
| ETag | 请求变量的实体标签的当前值，是一种文件指纹，只要文件改变，ETag立刻变，带有Last-Modified时，ETag优先级最高 |
| Set-Cookie | 设置和页面关联的cookie，服务器通过这个头部把cookie传给客户端 |
| Connection | 表示是否需要持久连接，如Keep-alive |
| Assess-Control-Allow-Origin | 服务器允许的请求Origin头部 |
| Access-Control-Allow-Headers | 服务器允许的请求Headers |
| Access-Control-Allow-Methods | 服务器允许的请求方法 |
响应体
响应头之后紧跟着一个空行，然后接响应体。响应体就是Web服务器发送到客户端的实际内容。除网页外，响应体还可以是诸如Word、Excel或PDF等其他类型的文档，具体是哪种文档类型由Content-Type指定的MIME类型决定。
http请求常见问题：
GET请求和POST请求的区别
1、GET在浏览器回退时是无害的，而POST会再次提交请求
2、GET产生的URL地址可以被Bookmark，而POST不可以。
3、GET请求会被浏览器主动cache，而POST不会，除非手动设置。
4、GET请求只能进行url编码，而POST支持多种编码方式。
5、GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
6、GET请求在URL中传送的参数是有长度限制的，而POST么有。
7、对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
8、GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
9、GET参数通过URL传递，POST放在Request body中。
以上为标准答案参考自w3schools，可以理解为是基于http层面的对比
但GET和POST本质都是tcp/ip，除了http外层外，在tcp/ip层面也有区别：
GET请求产生1个tcp数据，POST请求产生2个tcp数据包
具体就是：
1、GET请求时，浏览器会把header和data一起发送出去，服务器响应200（返回数据）
2、POST请求时，浏览器首先发送headers，服务器响应100 continue，浏览器再发送data，服务器响应200（返回数据）
如果把TCP传输比作汽车运输，那么GET只需要汽车跑一趟就把货送到了，而POST得跑两趟，第一趟，先去和服务器打个招呼“嗨，我等下要送一批货来，你们打开门迎接我”，然后再回头把货送过去
HTTP 与 HTTPS 区别
1、安全性不同：HTTP明文传输，数据都是未加密的，安全性较差，HTTPS（SSL+HTTP） 数据传输过程是加密的，安全性较好。
2、网站申请流程不同：使用HTTPS协议需要到 CA（Certificate Authority，数字证书认证机构） 申请证书，一般免费证书较少，因而需要一定费用。证书颁发机构如：Symantec、Comodo、GoDaddy 和 GlobalSign 等。
3、响应速度不同：HTTP页面响应速度比 HTTPS 快，主要是因为 HTTP 使用 TCP 三次握手建立连接，客户端和服务器需要交换 3 个包，而 HTTPS 除了 TCP 的三个包，还要加上 ssl 握手需要的 9 个包，所以一共是 12 个包。
4、资源消耗不同：HTTPS其实就是建构在 SSL/TLS 之上的 HTTP 协议，所以，要比较 HTTPS 比 HTTP 要更耗费服务器资源。
5、默认端口不同：HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。在网络模型中，HTTP工作于应用层，而HTTPS工作在传输层
6、对搜索排名的提升：百度和谷歌两大搜索引擎都已经明确表示，HTTPS网站将会作为搜索排名的一个重要权重指标。也就是说HTTPS网站比起HTTP网站在搜索排名中更有优势。
当数据传输完成后，由于TCP是半关闭（half-close）的，因此终止一个连接还要经过四次握手
一个TCP连接是全双工（即数据在两个方向上能同时传递，可理解为两个方向相反的独立通道），因此每个方向必须单独地进行关闭。这原则就是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向连接。
四次挥手：
当客户端和服务器通过三次握手建立了TCP连接以后，数据已传送完毕，是要断开TCP连接的，那对于TCP的断开连接，这里就有了神秘的“四次分手”：
第一次挥手：主机1（可以是客户端，也可以是服务器端），设置Sequence Number和Acknowledgment Number，向主机2发送一个FIN报文段；此时，主机1进入FIN_WAIT_1状态；这表示主机1没有数据要发送给主机2了；
第二次挥手：主机2收到了主机1发送的FIN报文段，向主机1回一个ACK报文段，Acknowledgment Number为Sequence Number加1；主机1进入FIN_WAIT_2状态；主机2告诉主机1，我“同意”你的关闭请求；
第三次挥手：主机2向主机1发送FIN报文段，请求关闭连接，同时主机2进入LAST_ACK状态；
第四次挥手：主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段，然后主机1进入TIME_WAIT状态；主机2收到主机1的ACK报文段以后，就关闭连接；此时，主机1等待2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，主机1也可以关闭连接了。
四次挥手动态过程：
四次挥手通俗解释：
把客户端比作男孩，服务器比作女孩，通过他们的分手来说明“四次挥手”过程：
（1）“第一次挥手”：日久见人心，男孩发现女孩变成了自己讨厌的样子，忍无可忍，于是决定分手，随即写了一封信告诉女孩。
（2）“第二次挥手”：女孩收到信之后，知道了男孩要和自己分手，怒火中烧，心中暗骂：你算什么东西，当初你可不是这个样子的！于是立马给男孩写了一封回信：分手就分手，给我点时间，我要把你的东西整理好，全部还给你！（男孩收到女孩的第一封信之后，明白了女孩知道自己要和她分手。随后等待女孩把自己的东西收拾好）
（3）“第三次挥手”：过了几天，女孩把男孩送的东西都整理好了，于是再次写信给男孩：你的东西我整理好了，快把它们拿走，从此你我恩断义绝！
（4）“第四次挥手”：男孩收到女孩第二封信之后，知道了女孩收拾好东西了，可以正式分手了，于是再次写信告诉女孩：我知道了，这就去拿回来！
这里双方都有各自的坚持。
女孩自发出第二封信开始，限定一天内收不到男孩回信，就会再发一封信催促男孩来取东西！
男孩自发出第二封信开始，限定两天内没有再次收到女孩的信就认为，女孩收到了自己的第二封信；若两天内再次收到女孩的来信，就认为自己的第二封信女孩没收到，需要再写一封信，再等两天…
倘若双方信都能正常收到，最少只用四封信就能彻底分手！这就是“四次挥手”。
TCP连接常见问题：
为什么TCP连接的时候是3次？2次不可以吗？
因为需要考虑连接时丢包的问题，如果只握手2次，第二次握手时如果服务端发给客户端的确认报文段丢失，此时服务端已经准备好了收发数(可以理解服务端已经连接成功)据，而客户端一直没收到服务端的确认报文，所以客户端就不知道服务端是否已经准备好了(可以理解为客户端未连接成功)，这种情况下客户端不会给服务端发数据，也会忽略服务端发过来的数据。
如果是三次握手，即便发生丢包也不会有问题，比如如果第三次握手客户端发的确认ack报文丢失，服务端在一段时间内没有收到确认ack报文的话就会重新进行第二次握手，也就是服务端会重发SYN报文段，客户端收到重发的报文段后会再次给服务端发送确认ack报文。
为什么TCP连接的时候是3次，关闭的时候却是4次？
因为只有在客户端和服务端都没有数据要发送的时候才能断开TCP。而客户端发出FIN报文时只能保证客户端没有数据发了，服务端还有没有数据发客户端是不知道的。而服务端收到客户端的FIN报文后只能先回复客户端一个确认报文来告诉客户端我服务端已经收到你的FIN报文了，但我服务端还有一些数据没发完，等这些数据发完了服务端才能给客户端发FIN报文(所以不能一次性将确认报文和FIN报文发给客户端，就是这里多出来了一次)。
为什么客户端发出第四次挥手的确认报文后要等2MSL的时间才能释放TCP连接？
这里同样是要考虑丢包的问题，如果第四次挥手的报文丢失，服务端没收到确认ack报文就会重发第三次挥手的报文，这样报文一去一回最长时间就是2MSL，所以需要等这么长时间来确认服务端确实已经收到了。
TCP/IP的并发限制
其实浏览器对同一域名下并发的 TCP 连接是有限制的（2-10个不等）
而且在 HTTP1.0 中往往一个资源下载就需要对应一个 TCP/IP 请求
TCP协议特点
面向连接：面向连接，是指发送数据之前必须在两端建立连接，建立连接的方法就是 三次握手，这样能建立可靠的连接，为数据的可靠传输打下了基础
仅支持单播传输：每条TCP传输连接只能有两个端点，只能进行点对点的数据传输，不支持多播和广播传输方式
面向字节流：TCP不像UDP一样那样一个个报文独立传输，而是在不保留报文边界的情况下以字节流方式进行传输
可靠传输：对于可靠传输，判断丢包，误码靠的是TCP的段编号以及确认号，TCP为了保证报文传输的可靠，就给每个包一个序号，同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的字节发回一个相应的确认(ACK)，如果发送端实体在合理的往返时延(RTT)内未收到确认，那么对应的数据（假设丢失了）将会被重传
提供拥塞控制：当网络出现拥塞的时候，TCP 能够减小向网络注入数据的速率和数量，缓解拥塞
TCP提供全双工通信：TCP允许通信双方的应用程序在任何时候都能发送数据，因为TCP连接的两端都设有缓存，用来临时存放双向通信的数据。当然，TCP可以立即发送一个数据段，也可以缓存一段时间以便一次发送更多的数据段（最大的数据段大小取决于MSS）
UDP协议和TCP协议区别
| 对比项 | UDP | TCP |
|---|---|---|
| 是否链接 | 无链接，无需建立连接就可以直接发送大量数据 | 面向链接，在发送数据前先需要建立连接，然后再发送数据 |
| 是否可靠 | 不可靠传输，不使用流量控制和拥塞控制 | 可靠传输，使用流量控制和拥塞控制 |
| 发送确认 | 没有发送确认 | 有发送确认 |
| 连接个数 | 支持一对一，一对多，多对一和多对多通信 | 只能一对一通信 |
| 传输方式 | 面向报文 | 面向字节流 |
| 传输速度 | 传输会更快 | 传输的速度比较慢 |
| 错误校验 | 也会错误检查，但会丢弃错误的数据包 | 会进行错误校验，并能够进行错误恢复 |
| 握手协议 | 无握手协议 | 有握手协议 ，例如 SYN，SYN-ACK，ACK |
| 首部开销 | 首部开销小，仅8字节 | 首部最小20字节，最大60字节 |
| 适用场景 | 适用于实时应用：IP电话、视频会议、直播等 | 适用于要求可靠传输的应用：文件传输等 |
TCP向上层提供面向连接的可靠服务 ，UDP向上层提供无连接不可靠服务
虽然 UDP 并没有 TCP 传输来的准确，但是也能在很多实时性要求高的地方有所作为
对数据准确性要求高，速度可以相对较慢的，可以选用 TCP
浏览器接收到响应成功的报文后便开始下载网页，进行页面渲染
当浏览器收到html文件后，尽管html文件还未传输完成，仍然开始解析html。解析的过程是从上而下，顺序解析。HTML对应于DOM的生成，CSS对应于CSSOM的生成，最终生成渲染树render-tree。再根据布局进行计算，最后GPU进行绘制。
ps：构建DOM树期间，如果遇到JS，阻塞DOM树及CSSOM树的构建，优先加载JS文件，加载完毕，再继续构建DOM树及CSSOM树。
渲染步骤如下：
解析HTML构建DOM Tree
拿到服务器返回的网页后，首先，根据顶部定义的DTD类型进行对应的解析方式，网页的解析将会被交给内部的GUI渲染线程处理
渲染线程中的HTML解释器，将HTML网页和资源从字节流解释转换成字符流，再通过词法分析器将字符流解释成词，之后经过语法分析器根据词构建成节点，最后通过这些节点组建一个DOM树
这个过程中，如果遇到的节点是 JS 代码，就会调用 JS引擎 对 JS代码进行解释执行，此时由于 JS引擎 和 GUI渲染线程 的互斥，GUI渲染线程 就会被挂起，渲染过程停止，如果 JS 代码的运行中对DOM树进行了修改，那么DOM的构建需要从新开始
如果节点需要依赖其他资源，图片/CSS等等，就会调用网络模块的资源加载器来加载它们，它们是异步的，不会阻塞当前DOM树的构建
如果遇到的是 JS 资源URL（没有标记异步），则需要停止当前DOM的构建，直到 JS 的资源加载并被 JS引擎 执行后才继续构建DOM
解析CSS构建CSSOM Tree
CSS解释器会将CSS文件解释成内部表示结构，生成CSS规则树，这个过程也是和DOM解析类似的，CSS 字节转换成字符，接着词法解析与法解析，最后构成 CSS对象模型(CSSOM) 的树结构
构建的过程中浏览器得递归 DOM 树来确定元素到底是什么样式，为了 CSSOM 的完整性，只有等构建完毕才能进入到下一个阶段，所以就算 DOM 已经构建完了，也得等 CSSOM，然后才能进入下一个阶段
构建渲染树 (Render Tree)
接着 CSSOM 树和 DOM 树 合并成渲染树，也叫呈现树，渲染树 只包含渲染网页所需的节点，然后用于计算每个可见元素的布局，并输出给绘制流程，将像素渲染到屏幕上
布局 (Layout)
渲染树 同时包含了屏幕上的所有可见内容及其样式信息，有了渲染树，再接着就会进入布局 ( layout ) 阶段了，到目前为止，浏览器计算了哪些节点应该是可见的以及它们的计算样式，但还没有计算它们在设备视口内的确切位置和大小，这就是 布局 ( Layout ) 阶段，也称为 自动重排 或 回流 ( Reflow )
此阶段一般意味着元素的内容、结构、位置或尺寸发生了变化，需要重新计算样式和渲染树
绘制 (Painting)
经由前几步我们知道了哪些节点可见、它们的计算样式以及几何信息，将这些信息及渲染树中的每个节点转换成屏幕上的实际像素，也就是俗称的 绘制 或 栅格化 阶段
合成(Composite)
最后一步合成( composite )，这一步骤浏览器会将各层信息发送给GPU，GPU将各层合成，显示在屏幕上
页面渲染常见问题：
页面渲染优化策略
HTML文档结构层次尽量少，最好不深于六层
JS 脚本尽量后放
样式结构层次尽量简单
少量首屏样式使用内联方式放在标签内
在脚本中尽量减少DOM操作，尽量访问离线DOM样式信息，避免过度触发回流
减少通过 JS 代码修改元素样式，尽量使用修改 class 名方式操作样式或动画
尽量减少浏览器重排和重绘的一些情况发生
2020年了！就不要使用 table 布局了
CSS 动画中尽量只使用 transform 和 opacity ，不会发生重排和重绘
隐藏在屏幕外，或在页面滚动时，尽量停止动画
尽可能只使用 CSS 做动画，CSS动画肯定比 JS 动画要好很多
避免浏览器的隐式合成
改变复合层的尺寸
JS脚本为什么要尽量后放
解析 JS 的步骤是不固定的，因为在构建DOM 树的过程中，当 HTML 解析器遇到一个 script 标记时，即遇到了js，立即阻塞DOM树的构建，就会将控制权移交给 JavaScript 引擎，等到 JavaScript 引擎运行完毕，浏览器才会从中断的地方恢复DOM树的构建。若在 HTML 头部加载 JS 文件，由于 JS 阻塞，会推迟页面的首绘，所以为了加快页面渲染，一般将 JS 文件放到HTML 底部进行加载，或是对 JS 文件执行 async （异步执行）或 defer （延迟执行）加载。
至此上述的内容就是个人理解的从输入 URL 到页面加载完成的生命历程了。
≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡▶▷►◈◄◀◁≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡