从输入URL到页面加载的过程
- 浏览器接收URL开启网络请求线程
- DNS查询
- TCP/IP请求
- 服务器接收到请求、对应后台处理请求
- 后台和前台的HTTP交互
- 浏览器接收到HTTP数据包并解析
- 页面渲染
- JS引擎解析
进程和线程
进程是CPU资源分配的最小单位，线程是CPU调度的最小单位
浏览器的进程
- Browser进程：浏览器的主进程，负责协调、主控，只有一个。负责界面显示、用户交互、页面管理、绘制、下载等
- 第三方插件进程：每个插件对应一个线程，使用时创建
- GPU线程，用于3D绘制
- 浏览器渲染进程：默认每个Tab页一个进程
浏览器多进程的优势
- 避免单个page crash影响整个浏览器
- 避免第三方插件crash影响整个浏览器
- 多进程充分利用多核优势
浏览器内核进程（tab页面）的线程
- GUI线程（渲染界面）
- JS引擎线程
- 事件触发线程（事件循环）
- 定时器线程
- 网络请求线程
其中GUI渲染线程和JS引擎是无法同时工作的
DNS查询
- 浏览器缓存
- hosts
- 路由器缓存
- ISP（网络服务提供商）
- 递归查询
五层因特网协议栈
- 应用层（HTTP）
- 传输层（TCP、UDP）
- 网络层（IP）
- 数据链路层
- 物理层
TCP的三次握手
- 第一次握手(SYN=1, seq=x):
客户端发送一个 TCP 的 SYN 标志位置1的包，指明客户端打算连接的服务器的端口，以及初始序号 X,保存在包头的序列号(Sequence Number)字段里。
发送完毕后，客户端进入 SYN_SEND 状态。 - 第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1):
服务器发回确认包(ACK)应答。即 SYN 标志位和 ACK 标志位均为1。服务器端选择自己 ISN 序列号，放到 Seq 域里，同时将确认序号(Acknowledgement Number)设置为客户的 ISN 加1，即X+1。 发送完毕后，服务器端进入 SYN_RCVD 状态。 - 第三次握手(ACK=1，ACKnum=y+1)
客户端再次发送确认包(ACK)，SYN 标志位为0，ACK 标志位为1，并且把服务器发来 ACK 的序号字段+1，放在确定字段中发送给对方，并且在数据段放写ISN的+1
发送完毕后，客户端进入 ESTABLISHED 状态，当服务器端接收到这个包时，也进入 ESTABLISHED 状态，TCP 握手结束。
TCP的四次挥手
- 第一次挥手(FIN=1，seq=x)
假设客户端想要关闭连接，客户端发送一个 FIN 标志位置为1的包，表示自己已经没有数据可以发送了，但是仍然可以接受数据。
发送完毕后，客户端进入 FIN_WAIT_1 状态。 - 第二次挥手(ACK=1，ACKnum=x+1)
服务器端确认客户端的 FIN 包，发送一个确认包，表明自己接受到了客户端关闭连接的请求，但还没有准备好关闭连接。
发送完毕后，服务器端进入 CLOSE_WAIT 状态，客户端接收到这个确认包之后，进入 FIN_WAIT_2 状态，等待服务器端关闭连接。 - 第三次挥手(FIN=1，seq=y)
服务器端准备好关闭连接时，向客户端发送结束连接请求，FIN 置为1。
发送完毕后，服务器端进入 LAST_ACK 状态，等待来自客户端的最后一个ACK。 - 第四次挥手(ACK=1，ACKnum=y+1)
客户端接收到来自服务器端的关闭请求，发送一个确认包，并进入 TIME_WAIT状态，等待可能出现的要求重传的 ACK 包。
服务器端接收到这个确认包之后，关闭连接，进入 CLOSED 状态。
客户端等待了某个固定时间（两个最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后，没有收到服务器端的 ACK ，认为服务器端已经正常关闭连接，于是自己也关闭连接，进入 CLOSED 状态。
TCP和UDP的区别
粘包
默认情况下, TCP 连接会启用延迟传送算法 (Nagle 算法), 在数据发送之前缓存他们. 如果短时间有多个数据发送, 会缓冲到一起作一次发送 (缓冲大小见 socket.bufferSize), 这样可以减少 IO 消耗提高性能.
如果是传输文件的话, 那么根本不用处理粘包的问题, 来一个包拼一个包就好了. 但是如果是多条消息, 或者是别的用途的数据那么就需要处理粘包.
可以参见网上流传比较广的一个例子, 连续调用两次 send 分别发送两段数据 data1 和 data2, 在接收端有以下几种常见的情况:
A. 先接收到 data1, 然后接收到 data2 .
B. 先接收到 data1 的部分数据, 然后接收到 data1 余下的部分以及 data2 的全部.
C. 先接收到了 data1 的全部数据和 data2 的部分数据, 然后接收到了 data2 的余下的数据.
D. 一次性接收到了 data1 和 data2 的全部数据.
其中的 BCD 就是我们常见的粘包的情况. 而对于处理粘包的问题, 常见的解决方案有:
多次发送之前间隔一个等待时间
关闭 Nagle 算法
进行封包/拆包
TCP流量控制
通过滑动窗口协议（连续ARQ协议）实现，保证了分组无差错、有序接收、流量控制。接收方返回的ACK中会包含自己的接收窗口的大小，并且利用大小来控制发送方的数据发送。
TCP流量控制中的死锁
当发送者收到了一个窗口为0的应答，发送者便停止发送，等待接收者的下一个应答。如果这个窗口不为0的应答在传输过程中丢失，发送者一直等待，接收者以为发送者收到该应答，等待接收新数据，这样双方就相互等待，从而产生死锁
TCP流量控制中的死锁的解决
TCP使用了持续计时器。每当发送者收到一个0窗口的应答后就启动该计时器。计时器到时便主动发送报文询问接收者的窗口大小。若接收者仍然返回0窗口，则重置该计时器继续等待；若窗口不为0，则标识应答报文丢失了，此时重置发送窗口开始发送，这样就避免了死锁的产生
拥塞控制和流量控制的区别
拥塞控制是作用于网络的，防止网络负载过大，常用的方法：1.慢启动、拥塞避免 2.快重传、快恢复。流量控制是作用于接收者的，控制发送者的发送速度使接收者来得及接收，防止分组丢失
慢启动算法
发送方维持一个叫做拥塞窗口CWnd的状态变量，控制着传输速度，TCP开始发送报文时CWnd=1。一个传输轮次所经历的时间就是往返时间RTT，每经过一个RTT并且按时收到确认，就将拥塞窗口CWnd加倍。还有一个叫慢启动门限ssthresh的状态变量，当CWnd
拥塞避免算法
每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1而不是加倍。无论在慢启动阶段还是拥塞避免阶段，只要发送方没有按时收到确认，就把慢启动门限设置为出现拥塞时的拥塞窗口cwnd的一半（但不小于2）。然后把拥塞窗口cwnd重置为1，执行慢启动算法
快重传算法
接收方收到一个失序的报文段后就立刻发出重复确认而不是等到自己发送数据时捎带确认。只要发送方一连收到三个重复确认就立即重传对方尚未收到的报文段，而不是等待重传计时器到期
快恢复算法
当发送方连续收到三个重复确认时，把慢启动门限ssthresh减半，但是并不执行慢开始算法，而是将拥塞窗口cwnd设置为ssthresh减半后的值，直接执行拥塞避免算法。快重传配合快恢复的TCP Reno版本是目前使用最广的版本。
HTTP报文结构
- 通用头部
- 请求/响应头部
- 请求/响应体
常见请求头部
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：服务器的一些相关信息
HTTP2.0相对于HTTP1.x有什么优势和特点
二进制分帧
帧：HTTP/2 数据通信的最小单位消息：指 HTTP/2 中逻辑上的 HTTP 消息。例如请求和响应等，消息由一个或多个帧组成。
流：存在于连接中的一个虚拟通道。流可以承载双向消息，每个流都有一个唯一的整数ID
头部压缩
HTTP/1.x会在请求和响应中中重复地携带不常改变的、冗长的头部数据，给网络带来额外的负担。
- HTTP/2在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键－值对，对于相同的数据，不再通过每次请求和响应发送
- 首部表在HTTP/2的连接存续期内始终存在，由客户端和服务器共同渐进地更新
- 每个新的首部键－值对要么被追加到当前表的末尾，要么替换表中之前的值
服务器推送
服务端可以在发送页面HTML时主动推送其它资源，而不用等到浏览器解析到相应位置，发起请求再响应。例如服务端可以主动把JS和CSS文件推送给客户端，而不需要客户端解析HTML时再发送这些请求。
服务端可以主动推送，客户端也有权利选择是否接收。如果服务端推送的资源已经被浏览器缓存过，浏览器可以通过发送RST_STREAM帧来拒收。主动推送也遵守同源策略，服务器不会随便推送第三方资源给客户端。
多路复用
HTTP 1.x 中，如果想并发多个请求，必须使用多个 TCP 链接，且浏览器为了控制资源，还会对单个域名有 6-8个的TCP链接请求限制。
HTTP2中：
同域名下所有通信都在单个连接上完成。
单个连接可以承载任意数量的双向数据流。
数据流以消息的形式发送，而消息又由一个或多个帧组成，多个帧之间可以乱序发送，因为根据帧首部的流标识可以重新组装
HTTP的缓存过程
- 客户端向服务器发出请求，请求资源
- 服务器返回资源，并通过响应头决定缓存策略
- 客户端根据响应头的策略决定是否缓存资源（这里假设是），并将响应头与资源缓存下来
- 在客户端再次请求且命中资源的时候，此时客户端去检查上次缓存的缓存策略，根据策略的不同、是否过期等判断是直接读取本地缓存还是与服务器协商缓存
原文章
前端面试与进阶指南
从输入URL到页面加载的过程？如何由一道题完善自己的前端知识体系！