输入url到看到网页经历了什么

URL解析

URL编码

例如 https://csdn.net?name=张三&from=https://www.baidu.com 这样的 url 中有中文和 url，他识别可能会出问题，所以要编码和解码。

• 对整个 url 编码解码：encodeURI、decodeURI。处理空格、中文等
• 对传参编码解码：encodeURIComponent、decodeURIComponent

let url = `https://csdn.net?name=${encodeURIComponent(张三)}&from=https${encodeURIComponent(://www.baidu.com)}`

缓存检测

缓存位置

• Memory Cache 内存缓存
• Disk Cache 硬盘缓存
  打开网页：查看硬盘缓存中是否存在，有则使用，没有则发送请求
  普通刷新：因为网页没关，所以内存缓存可以用，优先级更高
  强制刷新：内存缓存没了，并且会直接跳过硬盘缓存，直接发送请求，请求头中 Cache-control: no-cache，服务器返回内容。

强缓存

http1.0 用的是 Expire 字段
http1.1 用的是 Cache-control 字段 Cache-control: max-age=2590000
Cache-control 优先级更高
缺点是如果服务端资源更新了，但是客户端这边还没过期，他会使用这个过期的资源，得不到最新的资源。
解决方案：

• 由于所有的资源 css、js、jpg 都是 html 引入的，所以 html 不做缓存，每次都去请求服务端返回，然后他引入的资源都带上例如时间戳这样的东西，这样名字不一样他就会更新了。
• 或者用协商缓存

协商缓存

第一次请求后服务端返回 Last-Modified / ETag
客户端携带标识符 If-Modified-Since / If-None-Match 请求，如果资源更新了，返回 200 和新的资源；如果没更新，返回 304，客户端可以直接用缓存中的。

DNS

<link rel="dns-prefetch" href="xxx"></link>

TCP

三次握手

四次挥手

四次挥手为什么是四次，也就是说第二次挥手的时候为什么不是FIN+ACK一起发送。其实发送FIN的意思是终止这一方向的数据传输，而接收到FIN的意思是这一方向上已经没有数据可以接收了，但仍可以发送数据。第一次挥手：客户端向服务端发送FIN，客户端对服务端说：我已经没有数据要发送了，想结束连接，虽然你已经没有数据可接收了，但我知道数据发送是以数据流的形式传输的，所以如果你还有数据没发送完可以不用着急关闭，我等你。第二次挥手：服务端向客户端发送ACK。服务端对客户端说：老弟呀，你的请求我收到了哈，但我不能马上断开哈，还真让你说对了，我还真有点东西没发送完，但我不能一声不吭让你默默的等啊，我先给你发送个ACK吧。第三次挥手：服务端向客户端发送FIN。服务端对客户端说：艾玛终于搞完了，我这边也没数据要发送了，那我就把FIN给你发过去了哈，我也同意断开了。注意此时服务端并没有断开哦，它还在等最终确认。第四次挥手：客户端向服务端发送ACK。客户端对服务端说：你发的FIN我收到了，既然你那边也没东西要发送了，那咱就断开吧。此时服务端想：这货最后的ACK怎么还不到啊，我得拿到最后的ACK才能断开啊，迟迟不给我ACK的话是不是他没收到我的FIN啊，再不给我ACK我就再给他发一次FIN，反正我拿不到ACK我就一直给你发FIN，哼！刚说完服务端就拿到了ACK，开开心心的断开了连接。这时客户端想：这网络会不会靠不住啊，对面到底收没收到我的ACK啊，万一我的ACK丢包了咋办，要不我再等等吧，就等2MSL（这个时间是数据包往返客户端和服务端一次的最大时长）这么长时间，反正他如果没收到我的ACK还会向我发送FIN的。2MSL的时间过去了。客户端：咦，没有再次收到他的FIN，说明这货已经拿到了我的ACK断开了啊，那我也断开吧！至此，二者彻底断开了连接！