一:http常见的状态码有哪些?
1:什么是HTTP协议:
它是单向的:基于请求-应答模式的协议
它是无状态的:服务器对客户端的请求做出的事务处理不带二和记忆性,每次都是重新处理。
它是基于 TCP/IP 的可靠超文本传输协议
2. 状态码分类
状态码 | 对应状态描述 |
---|---|
1xx | 服务器收到请求 |
2xx | 表示成功处理请求,如200 |
3xx | 需要重定向,浏览器直接跳转,如301,302,304 |
4xx | 客户端请求错误,如404,403 |
5xx | 服务器端错误,如500 |
3. 常见状态码
常见状态码 | 对应状态描述 |
---|---|
200 | 请求成功 |
301 | 永久重定向:配合location, 浏览器自动处理:比如自己的域名过期,更新了其他域名,返回状态码为301的话,为永久重定向,浏览器字第一次重定向后便会记住,之后访问地址都会直接变为重定向后的地址 |
302 | 临时重定向:配合location,浏览器自动处理,不带记忆功能,每次都是访问请求发出的地址。 常见场景:百度中点击一个搜索结果的链接,实际打开的网页地址并非点击文字定向的href,而是Reponse Headers中返回location的值![]() |
304 | 资源未被修改:之前已经请求,且当前依然有效,直接用之前的就好(下面last-modified缓存知识有涉及) |
403 | 没有权限:未登录就请求资源或是没有对应等级的查看权限 |
404 | 资源未找到 |
500 | 服务器错误 |
504 | 网关超时 |
4:HTTP 和 HTTPS
HTTP的优缺点:
优:
- 简单——
灵活——协议里的请求方法,URL,状态码等核心要素都没有写死,允许开发者定制修改或是解释
易扩展——可根据需要添加自定义请求头
- 应用广泛,环境成熟
缺:
- 传输的数据是明文传输,无加密,内容存在被窃取的可能
- 没有身份认证,用户身份可能会被伪装
- 消息完整性检测的缺乏,存在数据被篡改的可能,
HTTPS协议:
是由HTTP结合TLS/SSL构建的可进行加密传输,身份认证的网络协议,主要通过数字证书,加密算法,非对称密钥等技术完成互联网数据传输加密.
具体传输过程:
- 浏览器发起 HTTPS 请求,要求与 Web 服务器建立 SSL 连接
- Web 服务器收到客户端请求后,会生成一对公钥和私钥,并把公钥放在证书中发送给客户端浏览器
- 客户端验证证书是否合法,如果不合法则提示告警
- 客户端验证证书合法后,在本地生成随机数
- 通过公钥加密随机数,并把加密后的随机数传输到服务端
- 服务端通过私钥对随机数进行解密
- 服务端通过客户端传入的随机数构造对称加密算法,对返回结果内容进行加密后传输
二:http methods ?
1: 传统methods:
get 获取服务器数据
post 向服务器提交数据
2:现在的methods:
get 获取数据
post 新建数据
patch / put 更新数据
delete 删除数据
3:get 和 post 的差别
同:通过TCP/IP建立连接,都是HTTP请求的发出方式
异:
- get 用于获取数据,存在用缓存的可能;采用明文传输,故存在安全隐患;且因为放在url中传递,url 的长度是被浏览器限制了的,故get的传送数据量较小
- post 用于修改数据,肯定使用不到缓存;请求参数放在请求体(body)中,相较安全;不是放在url 中传递,放在body中,对传送长度无限制
post 的优点即是什么时候使用 POST 的答案
三:http常见的header有哪些?
1:Request Headers
- Accept 浏览器可接受的数据格式
- Accept-Encoding 浏览器可接收的压缩算法,如 gzip
- Accept-lanuage 浏览器能接收的语言
- Connection: keep-alive 一次TCP连接重复使用(一次连接,多次使用)
- cookie 非跨域请求都会带上
- Host请求的域名
- User-Agent(简称 UA)发出请求的客户端,浏览器信息
- Content-type 发送方数据的格式,如application/json
***自定义Header(有些api要求再request-headers加一些特定的密钥或是特定的值才会通过请求,否则认定为非法请求),相关使用场景有:
1):请求拦截器(在请求之前进行一些配置)
axios.interceptors.request.use(config => {
//比如介入授权认证后需在请求头中添加token信息
config.headers['X-Gisq-Token'] = config.headers['X-Gisq-Token'] ?? token
congfig.headers.X-Gisq-AppCode = 'reg3'
return config
} ,error => {
return Promise.reject(error);
})
2):响应拦截器(在响应之后对数据进行一些处理)
axios.interceptors.response.use ( res => {
let data=res.data
//比如响应一些报错信息
return data
})
2: Response Headers
- Content-type返回数据格式,如application/json
- Content-length 返回数据的大小,多少字节
- Content-Enconding 返回的数据的压缩算法,如gzip
- set-cookies:服务端修改的cookie
3:缓存相关的headers(下面有详细说明)
- Cache-Control
- Expires (不常用)
- Last-Modified(响应头中携带)
- If-Modified-Since(请求头中携带)
- Etag(响应头中携带)
- If-None-Match(请求头中携带)
四:什么是Restful API?
传统API设计:把每个url当作一个功能
例:/api/list?pageIndex=2
post请求 /api/create-blog
post请求 /api/update-blog?id=100
get请求 /api/get-blog?id=100
Restful API:把每个url当作一个唯一的资源标识
-
尽量不用url参数
-
用method表示操作类型(Restful API设计)
post请求 /api/blog patch请求 /api/blog/100 get请求 /api/blog/100
五:描述一下http的缓存机制(重要)?
1:为什么需要缓存:
网络请求相较于CPU计算以及页面渲染速度都较为缓慢,故性能优化及加快页面显示都应从网络请求这下手,最大化减少网络请求的体积和数量
2:可被缓存的资源:
静态资源(js css img)
写在前面,http缓存机制主要在http响应头中设定,响应头相关字段为Cache-Controls,Expires, Last-Modified/If-Modified-Since,Etag/If-None-Match
3:http强制缓存:Cache-Control
- 在Resopnse Headers中返回
- 控制强制缓存逻辑
- 例如Cache-Control:max-age = 31536000(单位:秒)------缓存时间
- cache-control的值
对应值名称 | 解释 |
---|---|
max-age | 缓存最大的有效时间,当浏览器向服务器发送请求后,在max-age这段时间之内浏览器不会再向服务器发出请求 |
no-cache | 不用强制缓存,交给服务端处理;no-cache是会被缓存的,只不过客户端在使用数据前,都必须向服务端发起一次请求,依靠服务端的返回判断评估缓存资源的有效性,如若变更,返回新资源,否则返回304 |
no-store | 禁止一切缓存,每次请求资源都要从服务器重新获取 |
private | 私有缓存,只能被终端浏览器缓存不允许中继服务器进行缓存 |
public | 可被多用户缓存,包括终端和CDN等中间代理服务器 |
- Expires(了解一下就够了)
1)同在Response Headers中
2)同为控制缓存过期
3)已被Cache-Control代替
4:协商缓存(对比缓存):Etag和Last-Modified-http
-
服务端缓存策略:
服务端判断是否可以使用本地缓存的内容,并非资源缓存在服务端;服务端判断客户端资源,是或否和服务端资源一样;一致则返回304(无文件返回),否则返回200和最新的资源 -
资源标识:
在Response Header 中,有两种:
1)Last-Modified资源的最后修改时间
初次请求时服务端返回资源和Last-Modified,当浏览器下一次再次请求时请求头中带着IF-Modified-Since(值为上一次服务端返回的Last-Modified的值),此时接到请求的服务端拿自己资源的最新更新时间与请求头中If-Modified-Since的值做协商/对比,一致则返回304,即无需携带任何资源返回,不一致返回新的资源和新的Last-Modified
2)Etag资源的唯一标识(字符串,类似人的指纹)
-
Last-Modified和Etag二者差别和联系
1)会优先使用Etag
2)Last-Modified只能精确到秒级
3)如果资源被重复生成,而内容不变,则Etag更精确,可避免发起不必要的重复性请求
http缓存-综述(强制缓存和协商缓存共存)
二者关系:当强制缓存和协商缓存命中资源时,都是从本地读取资源;二者中强制缓存优先级高,及它命中时,则不会进行协商缓存,而协商缓存不管是否可以使用缓存资源都得向服务端发起请求进行协商,根据返回的是200还是304进行具体操作
4:刷新页面对http缓存的影响
刷新方式 | 缓存策略 |
---|---|
正常操作(地址栏输入url,跳转连接,浏览器前进后退等) | 强制缓存有效,协商缓存有效 |
手动刷新(F5,点击刷新按钮,右击菜单刷新) | 强制缓存失效,协商缓存有效 |
强制刷新(ctrl + F5 ) | 强制缓存失效,协商缓存失效 |