-
基础
-
基本概念
-
报文格式
1.1 请求报文:
请求方法、URL、协议版本
请求首部
空行
主体
1.2 响应报文
协议版本、状态码、描述
首部内容
空行
主体
-
URL:Uniform Resource Locator 统一资源定位符
URI:Identifier 标识符 = URL + URN
-
-
HTTP方法
GET、HEAD、POST、PUT、PATCH、DELETE、OPTIONS、CONNECT、TRACE
-
状态码
1xx:信息状态(正在处理)
2xx:成功状态(正常处理)
3xx:重定向(需附加操作)
4xx:客户端错误
5xx:服务器错误
-
首部:通用、响应、请求、实体
-
-
Cookies:保存状态信息,客户端数据存储
-
用途:会话状态管理、个性化设置、行为跟踪
-
创建过程
服务器发送响应报文包含Set-Cookie首部字段,客户端得到保存Cookie内容;
客户端发送请求报文包含Cookie首部字段
-
分类
会话期Cookie;持久性Cookie
-
作用域
Domain 标识指定了哪些主机可以接受 Cookie。如果不指定,默认为当前文档的主机(不包含子域名)。如果指定了 Domain,则一般包含子域名。
Path 标识指定了主机下的哪些路径可以接受 Cookie(该 URL 路径必须存在于请求 URL 中
-
JavaScript
浏览器通过
document.cookie属性可创建新的 Cookie,也可通过该属性访问非 HttpOnly 标记的 Cookie。 -
HttpOnly
标记为 HttpOnly 的 Cookie 不能被 JavaScript 脚本调用; 因此使用 HttpOnly 标记可以在一定程度上避免 XSS 攻击
-
Secure
被Secure标记的Cookie只能被HTTPS发送给服务器,即使如此,敏感信息也不应该用Cookie传输
-
Session
Session 可以将用户信息存储在服务器上的文件、数据库或者内存中,如Redis效率更高
维护用户登陆状态过程:
-
登录时提交用户名和密码,放入http请求报文中;
-
服务器验证如正确,存储到Redis中,key称为Session ID;
-
服务器返回响应报文Set-Cookie首部字段包含Seesion ID,客户端收到将Cookie值存入浏览器;
-
客户端之后对同一个服务器进行请求时会包含该 Cookie 值,服务器收到之后提取出 Session ID,从 Redis 中取出用户信息,继续之前的业务操作
-
注意Session ID:安全性问题;经常更新,重新验证
-
-
禁用
此时无法使用 Cookie 来保存用户信息,只能使用 Session。
不能再将 Session ID 存放到 Cookie 中,而是使用 URL 重写技术,将 Session ID 作为 URL 的参数进行传递。
-
Cookie与Session
-
Cookie 只能存储 ASCII 码字符串,而 Session 则可以存储任何类型的数据,考虑数据复杂性时首选 Session;
-
Cookie存储在客户端浏览器中,Session存储在服务端
-
Cookie 存储在浏览器中,容易被恶意查看;如果非要将一些隐私数据存在 Cookie 中,可以将 Cookie 值进行加密,然后在服务器进行解密; 对于大型网站,如果用户所有的信息都存储在 Session 中,那么开销是非常大的,因此不建议将所有的用户信息都存储到 Session 中。
-
-
-
缓存
-
优点:缓解服务器压力;降低客户端延迟
-
实现方法:代理服务器缓存;客户端浏览器缓存
-
Cashe-Control:HTTP/1.1 通过 Cache-Control 首部字段来控制缓存
-
no-store:禁止
-
No-cache:强制确认
-
Private:用户浏览器;public:代理服务器
-
Max-age:http/1.1 优先处理
请求报文中:小于该时间可被缓存
响应报文中:服务器保存时间
-
Expires
-
-
缓存验证
-
Etag:唯一标识
-
放入 If-None-Match 首部,服务器收到该请求后,判断缓存资源的 ETag 值和资源的最新 ETag 值是否一致,如果一致则表示缓存资源有效,返回 304 Not Modified
-
Last-Modified:一种弱校验器,因为只能精确到一秒,所以它通常作为 ETag 的备用方案
客户端可以在后续的请求中带上 If-Modified-Since 来验证缓存
-
-
-
HTTPS
-
概念: HTTP + SSL(secure sockets layer)
加密(防窃听)认证(防伪装) 完整(防篡改)
-
加密
-
对称密钥加密: 快但不安全
-
非对称密钥加密:慢但安全
-
https:混合
非对称密钥加密传输Secret Key;(公布公钥;客户端用公钥加密secret key传输;服务器私钥解密获得secret key)
使用Secret Key进行对称密钥加密
-
-
认证
服务器想CA申请公钥;
CA判明身份对公钥做数字签名,分配,绑定;
https通信时,服务器发送证书给客户端,客户端获得公钥使用数字签名验证,通过则通信
-
完整性保护:SSL 提供报文摘要功能来进行完整性保护
-
缺点:速度慢;证书授权费用高
-
-
其他
-
GET和POST比较
作用 参数 安全 幂等 可缓存 XMLHttpRequest Get 获取资源 ASCII码 只读 是 可 Header与data一起发送 Post 传输实体主体 标准字符集 不安全 不是 不可 先Header再data(火狐除外) -
HTTP2.0
-
HTTP/1.x缺陷:牺牲性能
-
C客户端需多个连接才能并发和缩短延迟
-
不压缩请求和响应头部,流量较大
-
不支持有效的资源优先级,底层TCP连接利用率低下
-
-
二进制分帧层
将报文分成HEADERS帧和DATA帧,都是二进制格式
通信过程中,只有一个 TCP 连接存在,它承载了任意数量的双向数据流(Stream)
-
一个数据流(Stream)都有一个唯一标识符和可选的优先级信息,用于承载双向信息。
-
消息(Message)是与逻辑请求或响应对应的完整的一系列帧。
-
帧(Frame)是最小的通信单位,来自不同数据流的帧可以交错发送,然后再根据每个帧头的数据流标识符重新组装。
-
-
服务端推送
HTTP/2.0 在客户端请求一个资源时,会把相关的资源一起发送给客户端
-
首部压缩
HTTP/2.0 要求客户端和服务器同时维护和更新一个包含之前见过的首部字段表,从而避免了重复传输。
不仅如此,HTTP/2.0 也使用 Huffman 编码对首部字段进行压缩。
-
-
HTTP1.1新特性
-
默认长连接
-
支持流水线
-
支持同时多个TCP连接
-
支持虚拟主机
-
新增状态码100
-
支持分块传输编码
-
新增缓存处理指令max-age
-
-
连接管理
-
短连接与长连接
长连接只需要建立一次 TCP 连接就能进行多次 HTTP 通信。
从 HTTP/1.1 开始默认是长连接的,如果要断开连接,需要由客户端或者服务器端提出断开,使用 Connection : close; 在 HTTP/1.1 之前默认是短连接的,如果需要使用长连接,则使用 Connection : Keep-Alive。
-
流水线
在同一条长连接上连续发出请求,而不用等待响应返回,这样可以减少延迟。
-
-
内容协商:返回最合适的内容,例如中英文
-
类型
-
服务端驱动型
难知道客户端全部信息;
客户端提供信息冗长;
给定资源需返回不同展现形式,共享缓存的效率降低,S复杂
-
代理驱动型
服务器返回 300 Multiple Choices 或者 406 Not Acceptable,客户端从中选出最合适的那个资源。
-
-
Vary
在使用内容协商的情况下,只有当缓存服务器中的缓存满足内容协商条件时,才能使用该缓存,否则应该向源服务器请求该资源
-
-
内容编码
将实体主体进行压缩,从而减少传输的数据量
常用的内容编码有:gzip、compress、deflate、identity
-
范围请求
如果网络出现中断,服务器只发送了一部分数据,范围请求可以使得客户端只请求服务器未发送的那部分数据,从而避免服务器重新发送所有数据
-
Range:请求报文
请求成功的话服务器返回的响应包含 206 Partial Content 状态码
-
Accept-Ranges
响应首部字段 Accept-Ranges 用于告知客户端是否能处理范围请求,可以处理使用 bytes,否则使用 none
-
响应状态码
请求成功:206 Partial Content
请求范围越界:416 Requested Range Not Satisfiable
不支持范围请求:200 OK
-
-
分块传输编码 Chunked Transfer Encoding
把数据分割成多块,让浏览器逐步显示页面
-
多部分对象集合
报文主体内可含有多种类型的实体同时发送,每个部分之间用 boundary 字段定义的分隔符进行分隔,每个部分都可以有首部字段
-
通信数据转发
-
代理:正向(用户察觉的到);反向
主要作用:
-
缓存
-
负载均衡
-
网络访问控制
-
访问日志记录
-
-
网关
与代理服务器不同的是,网关服务器会将 HTTP 转化为其它协议进行通信,从而请求其它非 HTTP 服务器的服务。
-
隧道:SSL等加密手段,安全的通信线路
-
-

被折叠的 条评论
为什么被折叠?



