http 协议
http 是一个基于 TCP/IP 通信协议来传递数据(HTML 文件, 图片文件, 查询结果等)
http 协议是无状态的,同一个客户端的这次请求和上次请求是没有对应关系,对 http 服务器来说,它并不知道这两个请求来自同一个客户端。 为了解决这个问题, Web 程序引入了 Cookie 机制来维护状态.
统一资源标识符 (URI)
HTTP 使用统一资源标识符(Uniform Resource Identifiers, URI)来传输数据和建立连接
http://<host>:<port>/<path>?<query>#<frag>
https://<host>:<port>/<path>?<query>#<frag>
- 默认 HTTP 的端口号为 80,HTTPS 的端口号为 443。
HTTP 报文结构(请求报文和响应报文)
- request line 请求行
- request header 请求头
- 空行
- body 内容: 请求数据
请求行
GET /index.js HTTP/1.1
请求方法:
- GET 获取
- POST 对资源的建立或修改、
- HEAD :类似 get,只不过响应只有报头,用于节省字节
- PUT : 替换对应的资源
- DELETE 删除
- OPTIONS 嗅探请求预检,复杂请求中跨域的时候用到
请求头
- host 域名
- User-Agent : 它是一个特殊字符串头,使得服务器能够识别客户使用的操作系统及版本、CPU 类型、浏览器及版本、浏览器渲染引擎、浏览器语言、浏览器插件等。
- Referer 告诉服务器我是从哪个页面链接过来的,服务器基于此可以获得一些信息用于处理
- Accept-Encoding 浏览器发给服务器,声明浏览器支持的编码类型 eg: gzip(一般对纯文本内容可压缩到原大小的 40%)
- cookie 保存一些信息
- If-Modified-Since 从何时开始是否有修改
- If-None-Match 检查 MD5 之类的 hash 值
- Cache-Control: no-cache
响应头
- Content-Type 响应的 HTTP 内容类型
- Cache-Control max-age=3600
- Expires 过期时间
- Access-Control-Allow-Origin 设置允许的来源,验证请求的时候会带的 Origin
- Access-Control-Allow-Headers 设置允许跨域携带的 headers
- Access-Control-Allow-Methods 设置允许跨域方法
- ETag 被请求变量的实体值,与 Web 资源关联的记号
- last-modified 标记此文件在服务器端最后被修改的时间
- status 状态码
- Set-Cookie 设置客户端的 cookie
状态码
1xx 消息
2xx 请求成功
- 200 成功
- 206 (Partial Content)断点续传和多线程下载
3xx 重定向
- 301 请求的资源永久从不同的 URI 响应请求
- 302 请求的资源临时从不同的 URI 响应请求
- 304 如果客户端发送了一个带条件的 GET 请求且该请求已被允许,而文档的内容(自上次访问以来或者根据请求的条件)并没有改变,则服务器应当返回这个状态码
4xx 客户端错误
- 400 Bad Request (语义有误或者请求参数出错)
- 401 Unauthorized 需要权限验证
- 403 Forbidden 服务器收到请求,但是拒绝提供服务
- 404 not found 请求失败,请求所希望得到的资源未被在服务器上发现
5xx 服务器错误
- 500 Internal Server Error 服务器遇到了一个未曾预料的状况,导致了它无法完成对请求的处理
- 503 Service Unavailable 由于临时的服务器维护或者过载,服务器当前无法处理请求
- 504 Bad Gateway 作为网关或者代理工作的服务器尝试执行请求时,未能及时从上游服务器或者辅助服务器(例如 DNS)收到响应。
https
HTTPS = HTTP + SSL
加密方式
对称加密,比较有代表性的就是 AES 加密算法;双方密钥相同,加解密速度快
非对称加密,经常使用到的 RSA 加密算法就是非对称加密的;公钥和私钥
http 风险
- 被窃听
- 被篡改
- 被冒充
基本运行原理
- 客户端和服务端建立 SSL 握手 _客户端通过 CA 证书来确认服务端的身份_;
- 互相传递三个随机数,之后通过这随机数来生成一个密钥;
- 互相确认密钥,然后握手结束;
- 数据通讯开始,都使用同一个对话密钥来加解密;
基本运行原理(详细)
- 首先,客户端 A 访问服务器 B ,客户端 A 会生成一个随机数 1,把随机数 1 、自己支持的 SSL 版本号以及加密算法等这些信息告诉服务器 B 。
- 服务器 B 知道这些信息后,确认一下双方的加密算法,生成一个随机数 2 以及一个公钥返回给客户端 A
- 客户端 A 生成一个随机数 3 ,然后用公钥加密随机数 3 并传输给服务端 B 。
- 服务端 B 接收到后利用私钥进行解密,得到随机数 3。
- 最后,客户端 A 和服务端 B 都有随机数 1、随机数 2、随机数 3,然后双方都利用这三个随机数生成一个对话密钥。之后传输内容就是利用对话密钥来进行加解密了。这时就是利用了对称加密。
- SSL 的握手部分结束,客户端 A 和服务器 B 开始使用相同的对话密钥进行数据通讯。
为啥需要 CA 证书
因为在第一步的时候,我们并不清楚服务器 B 是不是真的是服务器 B。所以需要一个我们信得过的机构来告诉我们。
基本运行原理(带 CA 证书)
- 首先,客户端 A 访问服务器 B ,客户端 A 会生成一个随机数 1,把随机数 1 、自己支持的 SSL 版本号以及加密算法等这些信息告诉服务器 B 。
- 服务器 B 知道这些信息后,确认一下双方的加密算法,然后也生成一个随机数 B ,并将随机数 B 和 CA 颁发给自己的证书一同返回给客户端 A 。
- 客户端 A 得到 CA 证书后,会去校验该 CA 证书的有效性。校验通过后,客户端生成一个随机数 3 ,然后用证书中的公钥加密随机数 3 并传输给服务端 B 。
- 服务端 B 加密后的随机数 3,利用私钥进行解密,得到随机数 3。
- 最后,客户端 A 和服务端 B 都有随机数 1、随机数 2、随机数 3,然后双方都利用这三个随机数生成一个对话密钥。之后传输内容就是利用对话密钥来进行加解密了。这时就是利用了对称加密,一般用的都是 AES 算法。
- SSL 的握手部分结束,客户端 A 和服务器 B 开始使用相同的对话密钥进行数据通讯。
浏览器验证证书的合法性
证书链
证书链由多个证书一层一层组成的,除了最底层的网站证书的公钥是给用户加密报文外,其他层证书中的公钥均用于解密底层的证书指纹签名。最高层的根证书是自签名的,也就是自己颁发给自己,所以它的公钥不仅用来解密下层的签名,也用来给自己的签名解密。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。