开发必备:HTTP 及 TLS( 二 )

  • 204 No content , 表示请求成功 , 但响应报文不含实体的主体部分
  • 205 Reset Content , 表示请求成功 , 但响应报文不含实体的主体部分 , 但是与 204 响应不同在于要求请求方重置内容
  • 206 Partial Content , 进行范围请求
  • 3XX 重定向
    • 301 moved permanently , 永久性重定向 , 表示资源已被分配了新的 URL
    • 302 found , 临时性重定向 , 表示资源临时被分配了新的 URL
    • 303 see other , 表示资源存在着另一个 URL , 应使用 GET 方法获取资源
    • 304 not modified , 表示服务器允许访问资源 , 但因发生请求未满足条件的情况
    • 307 temporary redirect , 临时重定向 , 和302含义类似 , 但是期望客户端保持请求方法不变向新的地址发出请求
    4XX 客户端错误
    • 400 bad request , 请求报文存在语法错误
    • 401 unauthorized , 表示发送的请求需要有通过 HTTP 认证的认证信息
    • 403 forbidden , 表示对请求资源的访问被服务器拒绝
    • 404 not found , 表示在服务器上没有找到请求的资源
    5XX 服务器错误
    • 500 internal sever error , 表示服务器端在执行请求时发生了错误
    • 501 Not Implemented , 表示服务器不支持当前请求所需要的某个功能
    • 503 service unavailable , 表明服务器暂时处于超负载或正在停机维护 , 无法处理请求
    TLS协议HTTPS 还是通过了 HTTP 来传输信息 , 但是信息通过 TLS 协议进行了加密 。
    TLS 协议位于传输层之上 , 应用层之下 。首次进行 TLS 协议传输需要两个 RTT  , 接下来可以通过 Session Resumption 减少到一个 RTT 。
    在 TLS 中使用了两种加密技术 , 分别为:对称加密和非对称加密 。
    对称加密:
    对称加密就是两边拥有相同的秘钥 , 两边都知道如何将密文加密解密 。
    这种加密方式固然很好 , 但是问题就在于如何让双方知道秘钥 。因为传输数据都是走的网络 , 如果将秘钥通过网络的方式传递的话 , 一旦秘钥被截获就没有加密的意义的 。
    非对称加密:
    有公钥私钥之分 , 公钥所有人都可以知道 , 可以将数据用公钥加密 , 但是将数据解密必须使用私钥解密 , 私钥只有分发公钥的一方才知道 。
    这种加密方式就可以完美解决对称加密存在的问题 。假设现在两端需要使用对称加密 , 那么在这之前 , 可以先使用非对称加密交换秘钥 。
    简单流程如下:首先服务端将公钥公布出去 , 那么客户端也就知道公钥了 。接下来客户端创建一个秘钥 , 然后通过公钥加密并发送给服务端 , 服务端接收到密文以后通过私钥解密出正确的秘钥 , 这时候两端就都知道秘钥是什么了 。
    TLS 握手过程如下图:
    开发必备:HTTP 及 TLS

    文章插图
     
    客户端发送一个随机值以及需要的协议和加密方式 。
    服务端收到客户端的随机值 , 自己也产生一个随机值 , 并根据客户端需求的协议和加密方式来使用对应的方式 , 并且发送自己的证书(如果需要验证客户端证书需要说明)
    客户端收到服务端的证书并验证是否有效 , 验证通过会再生成一个随机值 , 通过服务端证书的公钥去加密这个随机值并发送给服务端 , 如果服务端需要验证客户端证书的话会附带证书
    服务端收到加密过的随机值并使用私钥解密获得第三个随机值 , 这时候两端都拥有了三个随机值 , 可以通过这三个随机值按照之前约定的加密方式生成密钥 , 接下来的通信就可以通过该密钥来加密解密
    通过以上步骤可知 , 在 TLS 握手阶段 , 两端使用非对称加密的方式来通信 , 但是因为非对称加密损耗的性能比对称加密大 , 所以在正式传输数据时 , 两端使用对称加密的方式通信 。
    备注:以上说明的都是 TLS 1.2 协议的握手情况 , 在 1.3 协议中 , 首次建立连接只需要一个 RTT , 后面恢复连接不需要 RTT 了 。
    小结这篇文章的内容还是相对比较多的 , 需要同学们多次阅读 , 慢慢理解 , 里面有些术语如果不太懂的同学可以去网上学习一下 , 下面总结一下内容:


    推荐阅读