http的请求方式
- get：获取数据
- post：修改数据
- put：新增数据
- delete：删除数据
- options：查询接口能使用那些请求方式
get和post的使用场景
http的常见请求头和响应头
请求头
- host
- user-Agency
- method
- accept-encoding
- accept-charset
- cookie
- content-type
- cache-control
响应头
- date
- content-type
- cache-control
content-type的种类
- text
- json
- form-data
- de
http1.0和http1.1的区别
- http1.0发起一次请求就会建立一次tcp/ip连接，请求结束后，连接断开；而http1.1会保持tcp/ip链接。
- http1.0请求资源是会拿到整个资源的（比如视频），然后整个返回给客户端，这样会浪费宽带；而http1.1则能获取资源的指定字节范围，比如获取视频资源的第a字节到第b字节的内容，响应码是206。
- httt1.0的浏览器缓存只有cache-control、expires，而http1.1有If-modify-since/last-modify和eTag/if-no-matched等
- http1.0的响应头没有host字段，所以没法用域名系统；http1.1有
队头阻塞
问题：http1.1可以保持tcp/ip链接，所以可以使用通道，在一个tcp/ip连接中发起多个请求，但是由于http1.0和http1.1是一发一收，所以得等第一个请求接受到响应了才能发起第二个请求，当第一个请求阻塞就会发生队头阻塞。
解决方案：浏览器对于同一个 域名最多建立6个tcp/ip链接，那我们同时建立多个tcp/ip请求；域名分片，有多个二级域名指向同一个域名，然后浏览器发起多个请求请求二级域名
http1.1和http2.0的区别
- http2.0将一个请求或者响应，都封装成帧，然后在tcp/ip连接里建立流（一个http请求建立一个流），流中能无序传输多个分片帧。每个流有自己的编号。
- http2.0是彻底的二进制，包括请求头和请求体，分别被封装成了头信息帧和数据帧，然后拆分成片段帧，每个分片帧都有帧号，server端能将分片帧合并，从而获取请求头和请求体。所以多个请求/响应能在一个tcp/ip连接中全部发送出去。从而避免了队头阻塞问题。
- http2.0有头部压缩，即第一次请求的请求头中携带全量的数据，之后的请求只需要携带变更的请求头数据即可
- http2.0服务器可以主动推送东西，减少请求发起
http和https的区别
http:超文本传输协议 https:超文本安全传输协议
- http是明文传输，不安全；https是加密传输，较为安全
- https需要数字签名，需要钱
- https需要一层https握手，所以耗时
- http是80端口；https是443端口
在浏览器输入https://www.google.com发生了什么
- 解析出请求协议、请求host、端口
- 缓存判断
- dns解析
- tcp三次握手
- https握手
- 发送数据
- 获取响应
- tcp四次挥手
- 解析html
- 渲染在浏览器
keep-alive
用于连接是否要保活的标识
- 短连接：http1.0时不传入keep-alive，所以每次http请求都会建立tcp/ip连接，请求完成就关闭
- 长连接：http1.1默认content-type:keep-alive，保持tcp/ip连接存活，然后通过content-type:close主动关闭连接
当有多张图片时，http表现如何
- http1.x下，tcp/ip连接最多有6个连接，而每个连接中的http请求必须得同步发送，所以一定时间内请求发起数少
- http2.x下，可以在一个tcp/ip连接中同时发起多个请求，所以效果好
URL有哪些组成部分
比如：https://www.baicu.com/index.html#a=1?b:1
- 协议
- 万维网前缀
- host
- 路径path
- 入参(?)
- 锚点(#)
请求头中关于缓存的字段
强缓存
- expires
- cache-control
协商缓存 - if-modify-since/last-modify
- etag/if-no-match
https协议
http协议是tcp/ip五层网络协议，而https需要在tcp/ip连接建立之前，先进行ssl认证。 背景：http是明文、无身份认证的传输协议，这会有以下的问题
- 中间人能窃听请求/响应
- 中间人能新增/修改请求/响应
- 浏览器是不知道某个http响应是不是真正的服务器返回的（有可能是中间人插入在client/server中间）。
方法：
- 通过给传输的内容hash，生成hash值，内容任何的修改都会导致新hash与旧hash的不一致。这种方式会被中间人修改内容以及hash从而来修改内容，所以我们需要给内容和hash加密
- 通过对称加密的方式（client/server公用一个秘钥来加解密），这样就能加密传输内容。这种方式需要先传输公用的秘钥（比如client->server随机数A，server->client随机数B，两个随机数作为入参，双方使用同一个加解密函数作为公用的秘钥），如果被窃取了两个随机数，那就gg
- https通过
非对称加密的方式，server将公钥传输给client，然后在对称加密的两个随机数AB基础上，client使用公钥加密随机数C（中间人无法解密这个随机数C），传输给server，之后双方使用随机数ABC+加解密函数作为对称加密的私钥，这样私钥就不会被破解了。（因为非对称加密耗时，所以只作为对称加密的秘钥的加密方式）\
数字签名
我们解决了传输信息的窃听、修改问题了，但是有另一个问题出现了。
背景：
中间人不窃听、不修改，就单纯的插在中间：client-中间人-server，中间人提供给client自己的公钥、然后拿server的公钥，这样就能获取client的请求，以及server的响应。
方法:
让server的公钥被公信化，比如有一个权威机构认证的公钥。bilibili网站把自己的公钥给到权威机构去认证，获取公证，公证+公钥=数字签名，然后bilibili把数字签名给浏览器，浏览器验证公证就认为这个公钥是来自bilibili的，而不是中间人的。这种方式实现了身份认证e。
所以https握手过程
- client发起一个请求，带有随机数A、允许的加密方式、以及所有内容的hash值
- server将自己的公钥+权威认证=数字证书+随机数B、以及所有内容的hash值发送给client
- client生成一个随机数C，生成hash，用数字证书中的公钥加密所有内容，发送给server
- client/server使用这随机数ABC+加密方法作为两者公用的秘钥进行数据交互
响应状态码
2xx
- 200：成功
- 204：not content 响应体中无内容
- 206：partial content 部分内容，比如该响应只返回某视频资源的0字节-2000字节内容
3xx：大部分和重定向有关
- 301：永久重定向
- 302：临时重定向
- 304：not modified 协商缓存后，server让client直接用本地缓存
4xx：client的问题
- 400：bad request，一般是传参格式错误、url错误
- 401：服务器认证失败
- 403：禁止访问
- 404：没找到
- 405：请求方式不允许
5xx：server的问题
- 500：服务器内部错误
- 503：服务器超载
DNS是什么
domain name server 域名服务：ip不好记，域名好记door了！但是ip层传输得用ip，所以我们得有域名服务器将域名和ip做一一映射
DNS解析过程
- 浏览器缓存 => 本地域名服务器（host文件）=> 顶级域名服务器 => 权威域名服务器
网络模型
Tcp/ip 五层网络模型
- 应用层（http、https、ftp等）
- 传输层（tcp、udp）
- 网络层（ip）
- 链路层
- 物理层
Tcp的拥塞控制
- 慢启动
- 拥塞避免
- 快速恢复
- 流量控制
tcp的三握四挥
前后端实时通信的方式
tcp、http都是可以一直保持着的链接、只要后端不主动关闭，那么链接就会一直保持的（不考虑重连保活）
- 轮询：前端每隔一定时间就向后端请求数据，无论是否有新的数据。
- 长轮询：前端发一个请求给后端，后端将该连接保持着，等有新数据才返回，然后关闭连接。
- 长连接：比如iframe方式：后端接受请求后，将连接一直保持着，维护它，并且不关闭。
- websocket
- sse
各方式的优缺点：
- 优点：写起来简单；缺点：频繁发起请求
- 优点：避免了多次无意义的请求；缺点：是http，所以请求头带了很多信息，而且维持这个连接也需要资源
- 优点：同上；缺点：同上+后端维护连接难度增加
- 优化：很好；缺点：无法断线重连，兼容性问题
- 优点：很好；缺点：无
