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 报文结构(请求报文和响应报文)

图片描述

  1. request line 请求行
  2. request header 请求头
  3. 空行
  4. body 内容: 请求数据

请求行

GET /index.js HTTP/1.1

请求方法:

  1. GET 获取
  2. POST 对资源的建立或修改、
  3. HEAD :类似 get,只不过响应只有报头,用于节省字节
  4. PUT : 替换对应的资源
  5. DELETE 删除
  6. 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 风险

  1. 被窃听
  2. 被篡改
  3. 被冒充

基本运行原理

  1. 客户端和服务端建立 SSL 握手 _客户端通过 CA 证书来确认服务端的身份_;
  2. 互相传递三个随机数,之后通过这随机数来生成一个密钥;
  3. 互相确认密钥,然后握手结束;
  4. 数据通讯开始,都使用同一个对话密钥来加解密;

基本运行原理(详细)

  1. 首先,客户端 A 访问服务器 B ,客户端 A 会生成一个随机数 1,把随机数 1 、自己支持的 SSL 版本号以及加密算法等这些信息告诉服务器 B 。
  2. 服务器 B 知道这些信息后,确认一下双方的加密算法,生成一个随机数 2 以及一个公钥返回给客户端 A
  3. 客户端 A 生成一个随机数 3 ,然后用公钥加密随机数 3 并传输给服务端 B 。
  4. 服务端 B 接收到后利用私钥进行解密,得到随机数 3。
  5. 最后,客户端 A 和服务端 B 都有随机数 1、随机数 2、随机数 3,然后双方都利用这三个随机数生成一个对话密钥。之后传输内容就是利用对话密钥来进行加解密了。这时就是利用了对称加密。
  6. SSL 的握手部分结束,客户端 A 和服务器 B 开始使用相同的对话密钥进行数据通讯。

为啥需要 CA 证书

因为在第一步的时候,我们并不清楚服务器 B 是不是真的是服务器 B。所以需要一个我们信得过的机构来告诉我们。

基本运行原理(带 CA 证书)

  1. 首先,客户端 A 访问服务器 B ,客户端 A 会生成一个随机数 1,把随机数 1 、自己支持的 SSL 版本号以及加密算法等这些信息告诉服务器 B 。
  2. 服务器 B 知道这些信息后,确认一下双方的加密算法,然后也生成一个随机数 B ,并将随机数 B 和 CA 颁发给自己的证书一同返回给客户端 A
  3. 客户端 A 得到 CA 证书后,会去校验该 CA 证书的有效性。校验通过后,客户端生成一个随机数 3 ,然后用证书中的公钥加密随机数 3 并传输给服务端 B 。
  4. 服务端 B 加密后的随机数 3,利用私钥进行解密,得到随机数 3。
  5. 最后,客户端 A 和服务端 B 都有随机数 1、随机数 2、随机数 3,然后双方都利用这三个随机数生成一个对话密钥。之后传输内容就是利用对话密钥来进行加解密了。这时就是利用了对称加密,一般用的都是 AES 算法。
  6. SSL 的握手部分结束,客户端 A 和服务器 B 开始使用相同的对话密钥进行数据通讯。

浏览器验证证书的合法性

CA

证书链

证书链由多个证书一层一层组成的,除了最底层的网站证书的公钥是给用户加密报文外,其他层证书中的公钥均用于解密底层的证书指纹签名。最高层的根证书是自签名的,也就是自己颁发给自己,所以它的公钥不仅用来解密下层的签名,也用来给自己的签名解密。


chen4342024
180 声望23 粉丝

GitHub:[链接]


下一篇 »
js 任务