HTTP 梳理
2019-06-19 本文已影响0人
一只重拾梦想的小水
方法 Method
- 1.0
get、head、post - 1.1
put、option测试服务端可用、trace追踪错误、delete、connect
get vs post
- get: url?param1=p1；数据大小（由于各浏览器url长度限制）；不安全 url明文；一般用于资源/数据获取
- Post: request.body: param1:p1；没有数据大小限制（服务端限制）；较安全；一般用于表单提交/ 更改数据
restful中 put vs post
- post：有副作用、不幂等；增减账户余额，传+1、-1
- put：幂等（参数相同，n次调用结果一致）；文档更新等
跨域：
- jsonp：script或者img的src允许跨域，服务端利用callback返回数据
- postmessage：webview中的iframe跨域window.addEventListener(‘message’)=(e) =>{ e.data }
- websocket（启动websocket服务）
- cors：
服务端设置access-control-allow-origin
请求：浏览器自动控制，或者 fetch: promise( mode: ‘cors’)
SSL\ TSL
SSL：直接ip + port 访问， 需要私钥密钥对？？？
待续
cookie & session ——http无状态的解决方案
- cookie：客户端 userid等、敏感信息外露不安全、伪造攻击
- session：信息存在服务端，配合客户端cookie存JSessionId、安全、增加服务端的存储压力、不活跃过期清除、浏览器窗口级别（父子窗口公用）、postmessage/存储disk cookie解决多窗口
鉴权：（安全性）
解释一下有状态和无状态的区别：
有状态：cookie\ session\ token （服务端可以根据这些来判断用户是否已登录等）
无状态：restful api，不能依赖cookie和session
- basic auth：
原理：未授权访问 — 服务端返回 401&认证域 — 输入用户名密码 — base64编码带到header的authorization字段 — 通过验证
特点：浏览器支持度高、明文传输不安全、无法主动注销（只能关闭网页）
-
digest：
摘要鉴权，升级版basic
原理：401— 服务端返回唯一的nonce — 客户端用nonce、参数、用户信息生成摘要（md5），重新请求
特点：唯一nonce防止重放攻击，各浏览器支持方式和程度不同、不够通用，客户端发两次请求 -
HMAC：
- 一些概念：
appId：客户端唯一标识-公开
appKey：私钥-服务端和客户端各维护一份，不会在请求中传输
timestamp：时间戳
hmac算法：类似md5 - 原理：
参数的值转成basestring，带上appId、timestamp，用算法HMAC和私钥appkey加密，生成摘要串digest，带上，发送请求（parameter1=p1¶meter2=p2&apiId=API KEY&digest=digest×tamp=timestamp）
服务端 同样的方式生成，判断一致性，不一致报错，摘要已存在报错，否则正常返回+存储摘要 - 特点：
参数加密、私钥appkey不在网络传输、hmac算法防止篡改、timestamp防止重放攻击
- 其他：jsets库，封装了验证码、密码错误次数等功能
http 返回码
- 常见：
200、301永久、302短期、400bad、401、403forbidden 文件损坏及目录许可、404、500、503当前处理不了、短期恢复（超载），retry-time建议重试时间 - 不那么常见：
101 协议转换 ws
201 已创建 云服务，上传之前返回url
202 已接受，暂时没有处理完成
304 缓存
305 代理，通过代理获得
405 方法不允许
408 timeout
409 冲突 eg:put格式问题
413 请求实体过大
502 bad gateway （可以理解成代理）
504 网关gateway timeout
505 不支持的http版本
资源缓存
强缓存pragma、cache-control、expires 不发请求 200
弱缓存 lastmodifiedTime/if-not-modify 只能精确到秒、Etag/if-not-match 精确到毫秒
http 2 ——服务端推送：“数据流的兴起”、预言webpack的打包策略会进化
Http1.0: 短连接、无状态
Http1.1: 长连接、auth
出现原因：——解决http1.1问题
- tcp连接数6-8、效率低（以前的解决方式：多个二级域名扩展连接数）
- 多次DNS解析、tcp慢启动、tls握手，时间代价
- 线头阻塞 tpc同时只能处理一个连接。FIFO，前面的慢，后面的会被block
一些概念：
- 流：每个请求的数据的抽象概念，一个流有n个帧组成，streamId唯一标识
- 帧：http2数据传输的最小单位（带上streamId）
http2的特点：
- 二进制帧
- 多路复用：不同的流可以并行传输，响应端对同一streamid的帧合并，一起处理
- 服务器推送：http2的连接是双向的，服务端可以主动推送数据。请求html，响应会自动推送相应的css等
- 请求的优先级：依赖和权重，解决阻塞
- 重置连接：不断开连接，只取消某一个request（http1只能断开）
points：
- 一些状态：idle、open、reserved（即push，服务端推送、客户端等待，可以选择拒绝rst-stream）、half-close（local、remote）、close
http2性能优化：
- 每个请求数据粒度尽量小（多路复用），比如合并文件、雪碧图反而不好，资源内联不能充分利用缓存
- 尽可能共用TCP连接：防止资源浪费，同一域名，用同一份证书->http2自动合并到同一个tcp连接
通用性能优化
- 缓存：nginx配置expires、Etag&if-not-match、文件query根据内容hash
- CDN加速：cache-dns
- 减少DNS解析：涉及域名尽量少
