http 和 https 区别
输入 URL 后，会发生什么
URL 解析 => DNS 查询 => TCP 连接 => HTTP 请求 => 响应请求 => 页面渲染
- 域名解析
- 发起 TCP 的3次握手
- 建立 TCP 连接后发起 HTTP 请求
- 服务器收到请求并给予相应信息
- 客户端浏览器将返回的内容解析并呈现
DNS 解析过程
-
首先搜索浏览器的 DNS 缓存，缓存中维护一张域名与 IP 地址的对应表
-
若没有命中，搜索操作系统的 DNS 缓存
-
若依然没有命中，操作系统会将域名发送至
本地域名服务器，本地域名服务器查询自己的 DNS 缓存，查询成功则返回结果。（PS：主机和本地域名服务器之间的查询方式是递归查询） -
若本地域名服务器的 DNS 缓存没有命中，则本地域名服务器向上级域名服务器进行迭代查询。
- 本地域名服务器向根域名服务器发起请求，根域名服务器返回顶级域名服务器的地址
- 本地域名服务器拿到顶级域名服务器的地址后，就向其发起请求，返回权限域名服务器的地址
- 本地域名服务器拿到权限域名服务器的地址后，向其发起请求，最终得到对应的 IP 地址。
-
地址域名服务器将得到的 IP 地址返回给操作系统，同时自己把 IP 地址缓存起来
-
操作系统将 IP 地址返回给浏览器，同时自己也将 IP 地址缓存起来
-
浏览器得到域名对应的 IP 地址，并将 IP 地址缓存起来
三次握手
- 一开始，客户端和服务端都处于 CLOSED 状态，服务端主动监听某个端口，处理 LISTEN 状态
- 客户端主动发起连接 SYN，之后处于 SYN-SENT 状态
- 服务端收到发起的连接，返回 SYN+ACK，之后处于 SYN-RCVD 状态
- 客户端收到服务端发送的 SYN 和 ACK 之后，发送 ACK，之后处于 ESTABLISHED 状态。因为一发一收成功了。
- 服务端收到 ACK 之后，也进入 ESTABLISHED 状态，因为一发一收成功了
三次握手的目的是：保证双方都有发送和接收的能力
TCP 握手为什么是三次，不能是两次，不能是四次？
TCP 三次握手能够保证双方都有发送和接收的能力
第一次握手：接收方能够确认发送方的发送能力和接收方的接受能力是正常的
第二次握手：发送方能够确认发送方的发送/接收能力是正常的，接收方的发送/接收能力是正常的
第三次握手：接收方能够确认接收方的发送/接收能力是正常的，发送方的发送/接收能力是正常的。
若只有两次握手，则接收方不能确认自己的发送能力是否正常
为什么不能是四次，因为三次就能够确认双方的发送/接收
HTTP 长连接和短连接的区别
HTTP/1.0 中默认使用短连接，客户端和服务器没尽兴一次 HTTP 操作，就建立一次连接，任务结束就中断连接
HTTP/1.1 起，默认使用长连接
HTTPS 和 HTTP 的区别
1、HTTP 协议传输的数据都是未加密的，HTTPS 协议是由 SSL + HTTP 协议构建的可进行加密传输、身份认证的网络协议
2、HTTPS 协议需要用到 ca 申请证书
3、HTTP 和 HTTPS 用的端口不同，前者使用的是 80 端口，后者使用的是 443 端口
什么是半连接队列
服务器第一次收到客户端的 SYN 之后，就会处于 SYN-RCVD 状态，此时双方还没有完全建立连接，服务器会把这种状态下的请求连接放到一个队列，叫半连接队列。
SYC-ACK 重传次数：服务器发送完 SYN-ACK 包，如果未收到客户端的 ACK 包，服务器会进行重传，如果重传之后还为得到回应，会进行第二次重传。如果重传次数超过系统规定的最大重传次数，会将该连接信息从半连接队列中删除。
每次重传等待的时间不一定相同，一般是指数增长
ISN 是固定的吗
当一端想建立连接时，会为连接选择一个初始序号。 ISN 随时间而变化，因此每个连接的 ISN 都会不一样
四次挥手释放连接时，等待 2MSL 的意义
1、保证客户端发送的最后一个 ACK 报文段能够到达服务端。这个 ACK 报文段有可能丢失，使得处于 LAST-ACK 状态的服务端收不到对已发送的 FIN+ACK 报文段的确认。服务端超时重传 FIN + ACK 报文段，而客户端能在 2MSL 时间内收到这个重传的 FIN + ACK 报文段。 接着客户端重传一次确认，重新启动 2MSL 计时器。 若客户端不等待 2MSL ，可能会导致服务端无法关闭连接，一只处于 LAST-ACK 状态。
TCP 有哪些状态？
- listen
- syn_sent
- syn_recv
- established
- fin_wait1
- close_wait
- fin_wait2
- last_ack
- time_wait
- close
文章参考
TIME_WAIT 过多的危害
- 内存资源的占用
- 端口资源的占用，一个 TCP 连接至少消耗一个本地端口
time_wait过多怎么办
- 避免使用 TCP 短连接
GRPC 为什么性能高
- protocol 性能比 json 高 zhuanlan.zhihu.com/p/377860784
SSL 是怎么保证保全的（HTTPS 是如何保证数据传输的安全性）？
- 客户端向浏览器发起 SSL 连接请求
- 服务器把公钥发送给客户端，服务器保存着唯一私钥
- 客户端用公钥对双方通信的对称密钥进行加密，并发送给服务器
- 服务器利用自己唯一的私钥对客户端发送过来的对称密钥进行解密
- 双方开始进行数据传输，服务器和客户端双方用共有的相同的对称密钥对数据进行加密解密，保证在数据收发过程中的安全性。尽管第三方获取数据包，也无法对其进行解密和篡改
HTTP1.0、HTTP1.1、HTTP2.0
- HTTP 1.0
浏览器与服务器只保持短暂的连接，浏览器每次请求都需要与服务器建立一个 TCP 连接
- HTTP1.1
引入了长连接，TCP 连接默认不关闭，可以被多个连接复用
允许复用 TCP 连接，但是同一个 TCP 连接中，所有的数据通信都是按次序进行的，服务器处理完一个请求，才会接着处理下一个请求。
- HTTP2.0
采用二进制格式而非文本格式
完全多路复用，而非有序并阻塞，只需一个连接即可实现并行
http keep-alive 和 tcp keepalive 的区别
http keep-alive 是为了重用 tcp，避免每次请求，都重复创建 tcp
tcp keepalive 是一种保活机制，检测对端是否依然存活
tcp keepalive 机制
可参考
TCP 怎么保证数据可靠性
- 序列号/确认应答机制
序列号的作用不仅仅是应答的作用，有了序列号可以对接收到的数据按照序列号进行排序，并且可以去掉重复的序列号的数据。
每次接收方收到数据后，都会堆传输方进行确认应答，也就是发送 ACK 报文。这个 ACK 报文中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里开始发。
- 校验和
接收端可以检测出来数据是否有差错和异常，假如有差错会直接丢弃 TCP 段。
- 滑动窗口
TCP 利用滑动窗口来实现流量控制，避免发送方发送过多的数据导致接收方无法正常接收数据。
- 超时重传
超时重传发送方不能及时是收到确认包时，会重新发送数据包。
- 拥塞控制
在数据传输的过程中，由于网络的问题，造成网络拥堵。引入拥塞控制，在保证 TCP 可靠性的同时，提高性能。
TCP 拥塞控制
TODO
HTTPS 验证流程
- 客户端发起 http 请求，告诉服务器自己支持哪些 hash 算法
- 服务端把自己的信息以数字证书的形式发送给客户端，其中证书内容包括公钥、网站地址、证书颁发机构、失效日期等。
- 客户端收到服务器的响应后验证证书是否合法。验证的时候会验证证书中的地址与访问的地址是否一致、证书是否过期等
- 验证通过后，浏览器会生成一个随机的对称密钥，并用公钥加密，服务端收到这个包后，用私钥解密，解密后服务端客户端传输数据的时候就用该对称密钥来加密解密了。
