HTTP
HTTP状态码及含义
1xx 服务器收到请求,继续处理
2xx 表示成功
3xx 表示需要进一步操作
4xx 表示浏览器方面出错
5xx 表示服务器方面出错
200 - 请求成功
201 - 已创建
202 - 已接受
203 - 成功,未授权
204 - 成功,无内容
205 - 成功,重置内容
206 - 成功,部分内容
301 - 永久移动,重定向
302 - 临时移动,可使用原url
304 - 未修改,可使用缓存
305 - 需代理访问
400 - 请求语法错误
401 - 要求身份认证
403 - 拒绝请求
404 - 请求的资源(网页等)不存在
500 - 内部服务器错误
HTTP 缓存
CacheControl
: max-age=3600 是设置过期时长(相对时间),跟本地时间无关。
Expires
是设置过期时间(绝对时间),但是如果用户的本地时间错乱了,可能会有问题
ETag
是通过对比浏览器和服务器资源的特征值(如MD5)来决定是否要发送文件内容,如果一样就只发送 304(not modified)
缓存策略: 可分为 强缓存 和 协商缓存
- Cache-Control/Expires: 浏览器判断缓存是否过期,未过期时,直接使用强缓存,Cache-Control的 max-age 优先级高于 Expires
- 当缓存已经过期时,使用协商缓存
唯一标识方案: Etag(response 携带) & If-None-Match(request携带,上一次返回的 Etag): 服务器判断资源是否被修改
最后一次修改时间: Last-Modified(response) & If-Modified-Since (request,上一次返回的Last-Modified);如果一致,则直接返回 304 通知浏览器使用缓存;如不一致,则服务端返回新的资源。
Last-Modified 缺点:
周期性修改,但内容未变时,会导致缓存失效
最小粒度只到 s, s 以内的改动无法检测到
Etag 的优先级高于 Last-Modified
GET和POST的区别
- GET比POST更不安全,因为参数直接暴露在URL上,所以不能用来传递敏感信息
- GET请求在URL中传送的参数是有长度限制的,而POST没有
- GET参数通过URL传递,POST放在Request body中
- GET幂等,POST不幂等(幂等指的是同样的请求被执行一次与连续执行多次的效果是一样的,服务器的状态也是一样的)
- GET 只需要一个报文,POST 需要两个以上报文
- GET请求参数会被完整保留在浏览器历史记录里,而POST中的参数不会被保留。
- GET请求会被浏览器主动cache,而POST不会,除非手动设置
- GET请求只能进行url编码,而POST支持多种编码方式
- 对参数的数据类型,GET只接受ASCII字符,而POST没有限制
- GET在浏览器回退时是无害的,而POST会再次提交请求
- GET产生的URL地址可以被加入收藏栏,而POST不可以
Cookie 、LocalStorage 、SessionStorage 、Session
Cookie V.S. LocalStorage
主要区别是 Cookie 会被发送到服务器,而 LocalStorage 不会
Cookie 一般最大 4k,LocalStorage 可以用 5Mb 甚至 10Mb(各浏览器不同)
LocalStorage V.S. SessionStorage
LocalStorage 一般不会自动过期(除非用户手动清除),而 SessionStorage 在回话结束时过期(如关闭浏览器)
Cookie V.S. Session
Cookie 存在浏览器的文件里,Session 存在服务器的文件里
Session 是基于 Cookie 实现的,具体做法就是把 SessionID 存在 Cookie 里
http1.0 http1.1 http2.0区别
-
1.0 协议缺陷:
无法复用链接,完成即断开,重新慢启动和 TCP 3次握手
head of line blocking: 线头阻塞,导致请求之间互相影响 -
1.1 改进:
长连接(默认 keep-alive),复用
host 字段指定对应的虚拟站点
新增功能:
断点续传、身份认证、状态管理、cache 缓存(Cache-Control
、Expires
、Last-Modified
、Etag
) -
2.0:
多路复用: 在共享TCP链接的基础上同时发送请求和响应
二进制分帧层: 应用层和传输层之间
首部压缩
服务端推送:服务器可以额外的向客户端推送资源,而无需客户端明确的请求
https: 较为安全的网络传输协议
证书(公钥)、SSL 加密、端口 443
TCP:
-
三次握手
建立连接前,客户端和服务端需要通过握手来确认对方:
客户端发送 syn(同步序列编号) 请求,进入 syn_send 状态,等待确认
服务端接收并确认 syn 包后发送 syn+ack 包,进入 syn_recv 状态
客户端接收 syn+ack 包后,发送 ack 包,双方进入 established 状态 -
四次挥手
客户端 -- FIN --> 服务端, FIN—WAIT
服务端 -- ACK --> 客户端, CLOSE-WAIT
服务端 -- ACK,FIN --> 客户端, LAST-ACK
客户端 -- ACK --> 服务端,CLOSED