# 网络相关
# TCP三次握手，四次挥手
先建立连接
- 确保双方都有收发消息的能力
再传输内容
- 发请求
网络连接协议是tcp, 传输协议是http协议
三次握手的建立
- client发包，server接收 ；server: 有client的消息
- server发包，client接收；client: server 具备接收消息的能力
- client发包，server接收，server: 等待client发送
四次挥手 断开
- client发包 ，server 接收；client发送断开的请求
- server发包，client 接收；server收到断开的请求
- server发包，client接收；server发送可以断开的信号
- client发包，server接收；server断开
# HTTPS 握手过程
- 客户端使用https的url访问web服务器,要求与服务器建立ssl连接
- web服务器收到客户端请求后, 会将网站的证书(包含公钥)传送一份给客户端
- 客户端收到网站证书后会检查证书的颁发机构以及过期时间, 如果没有问题就随机产生一个秘钥
- 客户端利用公钥将会话秘钥加密, 并传送给服务端, 服务端利用自己的私钥解密出会话秘钥
- 之后服务器与客户端使用秘钥加密传输
# HTTPS 中间人攻击 如何预防
加密传输 http ssl
- 服务器向客户端发送公钥。
- 攻击者截获公钥，保留在自己手上。
- 然后攻击者自己生成一个【伪造的】公钥，发给客户端。
- 客户端收到伪造的公钥后，生成加密hash值发给服务器。
- 攻击者获得加密hash值，用自己的私钥解密获得真秘钥。
- 同时生成假的加密hash值，发给服务器。
- 服务器用私钥解密获得假秘钥。
- 服务器用加秘钥加密传输信息
# 预防
- 服务端在发送浏览器的公钥中加入CA证书，浏览器可以验证CA证书的有效性
# HTTPS 握手过程中,客户端如何验证证书的合法性
- 校验证书的颁发机构是否受客户端信任。
- 通过 CRL 或 OCSP 的方式校验证书是否被吊销。
- 对比系统时间，校验证书是否在有效期内。
- 通过校验对方是否存在证书的私钥，判断证书的网站域名是否与证书颁发的域名一致。
# HTTP协议和UDP协议有什么区别
- http 协议在应用层
- TCP UDP 在传输层
- tcp
- 稳定传输
- UDP
- 无连接，无断开
- 不稳定传输，效率高
- 视频会议，语音通话
- tcp
# Http 状态码 301 和 302 的应用场景分别是什么
https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status (opens new window)
# 301
301应用场景: 域名到期不想继续用这个,换了地址
请求资源的 URL 已永久更改。在响应中给出了新的 URL
# 302
302应用场景: 做活动时候,从首页跳到活动页面
只有在Cache-Control或Expires中进行了指定的情况下，这个响应才是可缓存的
# http跨域请求时为什么发送options请求
跨域请求之前的预检查
浏览器执行发起的
跨域请求
- 浏览器的同源策略
- 限制于ā ja x请求，不能跨域请求server
- 不会限制 img link iframe script 加载第三方的资源
JSONP
a <script> window.onSuccess=function(data){ } </script> <script scr=''></script> b "onSucesss({data:{}})"CORS
setHeader
# http 协议1.0 1.1 2.0有什么区别
# 1.1
- 缓存策略 cache-control
- 支持长连接 connection: keep-alive
- 断点续传
- 支持PUT DELETE
# 2.0
- 可压缩header，减少体积
- 多路复用
- 服务端推送
# http2的多路复用
# 解决http1的问题
- 在 HTTP/1 中，每次请求都会建立一次HTTP连接，也就是我们常说的3次握手4次挥手，这个过程在一次请求过程中占用了相当长的时间，即使开启了 Keep-Alive ，解决了多次连接的问题，但是依然有两个效率上的问题：
- 第一个：串行的文件传输。当请求a文件时，b文件只能等待，等待a连接到服务器、服务器处理文件、服务器返回文件，这三个步骤。我们假设这三步用时都是1秒，那么a文件用时为3秒，b文件传输完成用时为6秒，依此类推。（注：此项计算有一个前提条件，就是浏览器和服务器是单通道传输）
- 第二个：连接数过多。我们假设Apache设置了最大并发数为300，因为浏览器限制，浏览器发起的最大请求数为6，也就是服务器能承载的最高并发为50，当第51个人访问时，就需要等待前面某个请求处理完成
# 帧和流
- 帧代表着最小的数据单位，每个帧会标识出该帧属于哪个流，
- 流也就是多个帧组成的数据流。
- 多路复用，就是在一个 TCP 连接中可以存在多条流，也就是可以发送多个请求
- 通过帧中的标识知道属于哪个请求。
# 对比http1.x
- 在HTTP1.x中，
- 并发多个请求需要多个TCP连接，浏览器为了控制资源会有6-8个TCP连接都限制。
- HTTP2中
- 同域名下所有通信都在单个连接上完成，消除了因多个 TCP 连接而带来的延时和内存消耗。
- 单个连接上可以并行交错的请求和响应，之间互不干扰
# 为什么 HTTP1.1 不能实现多路复用
- HTTP/1.1 不是二进制传输，而是通过文本进行传输。由于没有流的概念，在使用并行传输（多路复用）传递数据时，接收端在接收到响应后，并不能区分多个响应分别对应的请求，所以无法将多个响应的结果重新进行组装，也就实现不了多路复用
# HTTP1.x是序列和阻塞机制
# HTTP 2.0 是多工复用TCP连接，
在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应，这样就避免了"队头堵塞"。
- 举例来说，在一个TCP连接里面，服务器同时收到了A请求和B请求，于是先回应A请求，结果发现处理过程非常耗时，于是就发送A请求已经处理好的部分， 接着回应B请求，完成后，再发送A请求剩下的部分。
- 旧的http1.1是会等 A请求完全处理完后在 处理B请求，会阻塞
# http1.1已经实现了管道机制
- 即 在同一个TCP连接里面，客户端可以同时发送多个请求。
- http 1.0并做不到，所以效率很低