分布式协议基础http协议

Http 协议的组成

• 抓包工具，Fillder
• request

response

URL（Uniform Resource Locator）

• 址用于描述一个网络上的资源，
• 基本格式：
  • 举例：http://www.gupaoedu.com:80/java/index.html?name=mic#head
  • schema://host[:port#]/path/.../?[url-params]#[ query-string]
    • scheme 指定应用层使用的协议(例如：http, https, ftp)
    • host HTTP 服务器的IP 地址或者域名
    • port# HTTP 服务器的默认端口是80，这种状况下端口号能够省略；若是使用了别的端口， 必须指明
    • path 访问资源的路径
    • query-string 查询字符串
    • # 片断标识符
      • 使用片断标识符一般可标记出已获取资源中的子资源（文档内的某个位置））

URI(Uniform Resource Identifier)

• 每一个web 服务器资源都有一个名字，这样客户端就能够根据这个名字来找到对应的资源，这个资源称之为（统一资源标识符）
• URI 是用一个字符串来表示互联网上的某一个资源。
• 而URL表示资源的地点（互联网所在的位置）

方法

• TTP 发起的每一个请求，都须要告诉告诉服务器要执行什么动做，
• 那么这个动做就是前面报文中看到的【method】
• http 协议中提供了多个方法，不一样方法的使用场景也也不同：
  • GET：通常是用于客户端发送一个URI 地址去获取服务端的资源（通常用于查询操做）
  • POST：通常用户客户端传输一个实体给到服务端，让服务端去保存（通常用于建立操做）
  • PUT：向服务器发送数据，通常用于更新数据的操做
  • HEAD：用于向服务端发起一个查询请求获取head 信息，
    • 好比获取index.html 的有效性、最近更新时间等。
  • DELETE：客户端发起一个Delete 请求要求服务端把某个数据删除（通常用于删除操做）
  • OPTIONS：查询指定URI 支持的方法类型（get/post）
    • http1.1 还支持 trace(追踪路径)和connect 方法类型

HTTP 协议的特色：

• HTTP 协议是无状态的
  • 什么是无状态呢？
    • 就是说HTTP 协议自己不会对请求和响应之间的通讯状态作保存。

如何实现有状态的协议

• Http 协议中引入了cookie 技术，用来解决http 协议无状态的问题。
• 在请求和响应报文中写入Cookie 信息来控制客户端的状态；
• Cookie会根据从服务器端发送的响应报文内的一个叫作 Set-Cookie 的首部字段信息，通知客户端保存 Cookie。
• 当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出去。
• 在基于tomcat 这类的jsp/servlet 容器中，会提供session 这样的机制来保存服务端的对象状态。

HTTP 协议的缺陷：

1. 通讯过程当中是使用明文，内容可能会被窃听
2. 不验证通讯双方的身份
3. 没法验证报文的完整性，报文可能被篡改

HTTPS 的原理：

• 人们为了防止信息在传输过程当中遭到泄漏或者篡改，就想出来对传输通道进行加密的方式https。
• https 是一种加密的超文本传输协议，它与HTTP 在协议差别在于对数据传输的过程当中，https 对数据作了彻底加密。
• 在tcp 协议层之上增长了一层SSL（Secure Socket Layer，安全层）或者TLS（Transport Layer Security） 安全层传输协议组合使用用于构造加密通道；

HTTPS 的实现原理

客户端发起请求(Client Hello 包)：

• 三次握手，创建TCP 链接
• 支持的协议版本(TLS/SSL)
• 客户端生成的随机数client.random，后续用于生成“对话密钥”
• 客户端支持的加密算法
• sessionid，用于保持同一个会话（若是客户端与服务器费尽周折创建了一个HTTPS 连接，刚建完就断了，也太惋惜）

服务端收到请求，而后响应（Server Hello）

• 确认加密通道协议版本
• 服务端生成的随机数server.random，后续用于生成“对话密钥”
• 确认使用的加密算法（用于后续的握手消息进行签名防止篡改）
• 服务器证书（CA 机构颁发给服务端的证书）

客户端收到证书进行验证

• 验证证书是不是上级CA 签发的,
  • 在验证证书的时候，浏览器会调用系统的证书管理器接口对证书路径中的全部证书一级一级的进行验证，只有路径中全部的证书都是受信的，整个验证的结果才是受信
• 服务端返回的证书中会包含证书的有效期，
  • 能够经过失效日期来验证 证书是否过时
• 验证证书是否被吊销了
• 前面咱们知道CA 机构在签发证书的时候，都会使用本身的私钥对证书进行签名
  • 证书里的签名算法字段 sha256RSA 表示CA 机构使用sha256对证书进行摘要，而后使用RSA 算法对摘要进行私钥签名
  • RSA 算法中，使用私钥签名以后，只有公钥才能进行验签。
• 浏览器使用内置在操做系统上的CA机构的公钥对服务器的证书进行验签
  • 肯定这个证书是否是由正规的机构颁发。
  • 若是获得的值和服务端返回的证书验签以后的摘要相同，表示证书没有被修改过
• 验证经过后，就会显示绿色的安全字样
• 客户端生成随机数，验证经过以后，客户端会生成一个随机数pre-master secret ，
  • 客户端根据以前的： Client.random +sever.random + pre-master 生成对称密钥
  • 而后使用证书中的公钥进行加密，同时利用前面协商好的加密算法，将握手消息取HASH 值，而后用“随机数加密“握手消息+握手消息HASH 值（签名）”而后传递给服务器端；
    • 在这里之因此要取握手消息的HASH值，主要是把握手消息作一个签名，用于验证握手消息在传输过程当中没有被篡改过。

服务端接收随机数

• 服务端收到客户端的加密数据之后，用本身的私钥对密文进行解密
• 而后获得client.random/server.random/pre-master secret
• 再用随机数密码 解密 握手消息与HASH 值，并与传过来的HASH 值作对比确认是否一致。
• 而后用随机密码加密一段握手消息(握手消息+握手消息的HASH 值 )给客户端

客户端接收消息

• 客户端用随机数解密并计算握手消息的HASH，若是与服务端发来的HASH 一致，此时握手过程结束，
• 以后全部的通讯数据将由以前交互过程当中生成的pre mastersecret / client.random/server.random 经过算法得出sessionKey，做为后续交互过程当中的对称密钥