浏览器输入url后发生了什么
1.DNS解析 包括了 浏览器缓存、操作系统缓存、本地 DNS 服务器 到 根域名服务器的递归查询
2.TCP链接 http请求 知道地址和端口后，使用三次握手建立TCP链接，然后发送http请求。
3.服务器接收请求后，返回处理浏览器渲染
4.客户端保持TCP链接或者四次挥手关闭TCP链接
http的格式
请求行（Request Line）
GET /api/user HTTP/1.1请求头（Headers）accept:html，txt Accept-Language:zh-CN Content-Type ,Content-Length keepalive:true host:www.xxx.com User-Agent:Android auth:xxxx,
请求体（Body，可选：POST/PUT 才常见）
具体而言，
http状态码
2xx：成功
3xx：重定向 301 永久重定向 302 临时重定向
4xx：客户端错误 404 资源未找到 403 禁止访问 400 客户端请求参数错误
5xx：服务器错误 500 服务器内部错误 502 网关错误
http的状态演进
针对的上一个版本的痛点，这个版本的改进，带了的收益 思考
HTTP/1.0：：短连接。每个请求都要经历“三次握手”建立 TCP 连接，请求完立即断开。主要是少量的文本和少量图片。
HTTP/1.1：：长连接。同一个 TCP 连接可以传输多个 HTTP 请求。引入了 Keep-Alive（长连接），允许在同一个 TCP 连接上发送多个请求。痛点：“队头阻塞（Head-of-line blocking）”：请求还是按照顺序一个一个来，如果前面的请求没处理完，后面的请求就得等着。 1.1是目前用的最广泛的http版本，解决了连接频繁建立的问题，但本质上还是单行道，可以提高“带宽利用率”。
HTTP/2：：多路复用。在同一个 TCP 连接上并行传输多个 HTTP 请求和响应。引入了二进制分帧、头部压缩等特性。解决了队头阻塞的问题。“TCP 层的队头阻塞”。即便 HTTP 层不排队了，如果底层 TCP 丢了一个包，整个连接都会因为丢包重传而卡住。
HTTP/3：：基于 UDP。使用 QUIC 协议，在同一个 UDP 连接上并行传输多个 HTTP 请求和响应。解决了TCP层的队头阻塞问题。从 Wi-Fi 切换到 4G，因为 QUIC 使用 Connection ID 而不是 IP+端口，你的视频通话或下载不会中断
https
HTTPS 本质上是 HTTP 跑在 TLS 之上。 它主要解决三个问题：数据加密、服务端身份认证、数据完整性保护。 流程上就是：客户端发起连接，服务端返回证书，客户端校验证书，双方协商会话密钥，之后再用对称加密传输 HTTP 数据。 这里的核心设计是：用非对称加密解决密钥交换和身份认证，用对称加密解决高效传输。
TCP基础认真
TCP 是一个面向连接、可靠、基于字节流、全双工的传输层协议。 面向连接上是三次握手，四次挥手，tcp需要通过链接维持传输的状态。 可靠性上通过序列号、确认应答、重传、滑动窗口、流量控制、拥塞控制来保证数据尽量可靠且有序地到达。 基于字节流式指tcp发送和接收看到的都是连续字节序列，不保留应用层消息的边界。
TCP 三次握手
要说出三次握手的流程，以及状态。
为什么不能两次握手？
需要保证双方都发送了SYN 和 ACK ，第三次握手刚好SYN 和 ACK 一起发送，所以三次刚好。 如果两次出现的问题：1. 客户端发送SYN后，服务器返回SYN+ACK，客户端收到后直接发送ACK，这样服务器无法确认客户端是否收到SYN+ACK，2.历史的重复链接，一个SYN 延迟后，客户端重发SYN，服务器以为是新的连接。
四次握手没必要，因为第二次握手就可以把SYN+ACK发送到client。
TCP 的滑动窗口: 如果每发一个包都要等一次 ACK，效率很低。 所以 TCP 引入滑动窗口，允许发送方一次发送多个还没确认的数据。 接收方会告诉发送方自己还能接收多少，这就是接收窗口。如果接受方通告窗口为 0，发送方暂时不能继续发数据。此时发送方要周期性发送零窗口探测包，查看窗口有没有回复。
TCP的拥塞控制：为了防止网络被打爆，发送方也需要控制发送的流量。 具体而言：1.在启动的时候，慢启动，先从小窗口发送后翻倍发送。2.拥塞避免，当发送窗口达到门控的时候(ssthresh) 就线性增长。3，处理拥塞：A：超时重传，说明拥塞严重，重新进行慢启动，ssthresh 减半。B：收到三个重复的ACK，说明网络拥塞，ssthresh 减半，重新进行拥塞避免（线性增长）。
还有一些关于第几个包丢失了的状态。这个时候要整理清楚。谁在等、谁会重传、最终连接会不会建立、会不会造成半连接。原则上：ACK 报文是不会有重传的，当 ACK 丢失了，就由对方重传对应的报文，所以是谁发送了关键报问谁就重新传输。
客户端
异常断网、崩溃、断电，客户端来不及发 FIN，服务端往往要等到下次读写失败，或者依赖 TCP keepalive、应用层心跳，才能判断连接已经失效。 如果客户端重新上线重连，从 TCP 层看这通常是一个全新的连接，因为四元组往往已经变了。 服务端需要通过登录态、token 或 session 恢复机制，把这个新连接重新绑定到原来的用户，再恢复在线状态、订阅关系以及未送达消息补发。