Ming
0%

http

Posted on Edited on In

HTTP

协议

传输之前总要先约定好的吧

HTTP协议

从web服务器传输html到浏览器的协议

版本

1.0

  • 一次连接一次传输

1.1

  • 一次连接多次传输

2.0

  • 实验阶段

原理

TCP/IP协议

BS架构

浏览器作为HTTP客户端通过URL向服务器发送请求

DNS服务器

保存所有主机的域名和IP地址

可以把域名翻译成IP地址

流程

DNS服务器把域名解析成IP地址

客户端和服务器三次握手建立TCP连接

客户端向服务器发送HTTP请求

服务器向客户端发送HTTP响应

客户端把得到的html和资源渲染到前端呈现给用户

特点

BS架构

  • 请求-响应模式

请求简单

  • 请求命令

    • GET
    • POST
    • Delete

  • 资源路径

啥都能传

  • 传输的类型用Content-Type标记

URI和URL

Uniform Resource Identifier

  • 标识

Uniform Resource Location

  • 定位
  • 互联网的资源都有唯一的URL

Request

请求行

  • 请求方法

    • 分类

      • GET

        • 请求获得某个资源

      • POST

        • 提交表单
        • 上传文件

      • HEAD

        • 只能获得header的Get

      • PUT

        • 请求创建或修改文件

      • DELETE

        • 请求删除文件

    • POST和GET的区别

      • GET请求的内容在URL就可以看到
      • GET没BODY
      • POST有BODY

  • URL

  • 协议类型

  • 协议版本

Body

Response

状态行

  • 响应状态码

    • 分类

      • 1XX

        • 服务器收到请求，给客户端一个message，明示你继续操作

      • 2XX

        • 一切OK，清楚明白

      • 3XX

        • 重定向

          • 比如之前的资源换位置了

      • 4XX

        • 客户端的错误

          • 语法
          • 服务器无法完成请求

      • 5XX

        • 服务器的错误

          • 服务器处理请求的时候出了差错

    • 常见/常用

      • 200

      • 301

        • URL变了

          • 这人搬家了，去别处找吧

      • 302

        • 这人暂时不在这里，去别处找吧

      • 400

        • 客户端的请求有语法错误

          • 服务器：？

      • 401

        • 服务器：你没有资格和我提这样的请求

      • 404

        • NOT FOUND

      • 500

        • 服务器：dbq

      • 503

        • 服务器：我很忙，过会儿再来试试吧

Header

Body

HTTPS

HTTP存在的问题

  • 请求的信息明文传输，能被轻易窃取
  • 数据的完整性未经校验，可能被篡改
  • 对方身份未经检验，可能被冒充

问题的解决

  • HTTP+SSL/TLS
  • Hypertext transfer protocol over secure socket layer

SSL

  • 提供安全支持的一种协议

TLS

  • 由SSL演化而来

传输数据的流程

  • 建立HTTPS连接
  • 用非对称加密传输对称加密的密钥
  • 通过密钥进行密文通信
  • （详情见网络通信加密）

缺点（相对于http）

  • 慢

  • SSL证书要钱，越好的越贵

    • SSL证书是CA证书的一种

  • 消耗资源多

值得一提的是HTTP和HTTPS用的端口不一样

网络通信加密

盘古时代

  • 路不拾遗，夜不闭户

    • 明文直接传

上古时代

  • 问题

    • 出现了刁民监听数据、伪造数据

  • 应对策略

    • 对称加密

      • 约定公用一把钥匙
      • 关键是钥匙不能给别人知道
      • 56bit的DES

近代

  • 问题

    • 道高一尺魔高一丈
    • 找个好的计算机可以暴力破解56位的钥匙

  • 应对策略

    • 对称加密（pro

      • 长度加倍，不够再加倍
      • 256位的AES
      • 168位的DES

现代

  • 问题

    • 对称加密需要一把唯一的key，这个key得找个好的时机告诉对方，决不能泄露，否则所做的一切毫无意义
    • 访问的人数太多了，言多必失

  • 应对策略

    • 非对称加密

      • 奥义

        • 加密解密所用的不是一把钥匙

      • 钥匙

        • private key
        • public key

      • 流程

        • A和B双方各有一个private key和对方的public key

        • 关于数据的安全性

          • A用B的public key对数据加密 发送给B
          • B用自己的private key对数据解密

        • 关于数据的完整性

          • A用自己的private key给hash值加密 发送给A
          • B用A的public key解密收到的hash
          • B用解密的数据算一下hash
          • B对比一下两个hash

非对称加密的安全隐患

  • 天下没有不透风的墙，如果有，那肯定是暂时的

  • 非对称加密最初需要告知对方自己的public key

  • C拦截了传输的public key，并把自己的public key传输给了A和B

  • 在之后的A和B的传输中，C可以获取A发给B的内容并篡改

    • hash值呢？

      • C自己整一个就行了呗，反正C已经无所不知了

  • 应对策略

    • 保证public key不被拦截

CA

  • 一个嵌入在浏览器或者操作系统的第三方
  • A和B通过CA生成数字证书交换public key
  • C可以获取public key但不能伪造数字证书 因为CA在本地从未经过传输

实际使用

  • 非对称加密太复杂了
  • 非对称加密太慢了
  • 所以我还用对称加密，但用非对称加密传输对称加密的密钥