HTTP和HTTPS协议详解

HTTP和HTTPS协议详解

• HTTP详解
• • 什么是http协议
  • http协议的发展史
  • • http0.9
    • http1.0
    • http1.1
    • http2.0
  • http协议的格式
  • • URI和URL
    • 请求request
    • 响应response
  • http协议完整的请求与响应流程
• HTTPS详解
• • 为什么使用HTTPS
  • SSL协议
  • HTTPS通信过程
  • TLS协议

HTTP详解

什么是http协议

1、全称Hyper Text Transfer Protocol（超文本传输协议）

• 普通文本：文件内存放的是一些人类认识的文字符号(汉字、英语、阿拉伯数字)
• 超级文本：除了普通文本内容之外，还有视频、图片、语音、超链接

http协议都能传输上述内容，所以说http协议是专用于传输超文本的协议

2、http主要用于B/S架构

3、http是基于tcp协议的

强调：基于http协议发包之前，必须先建立tcp协议的双向通路

http协议的发展史

http0.9

请求方法：只支持GET方法

请求头：不支持

响应信息：只支持纯文本，不支持图片

无连接/短连接/非持久连接：利用完 tcp 连接之后会立即回收，所以无连接指的不是说没有连接，而是说没有持久连接/长连接的http协议通信，先建立tcp连接，然后客户端发请求包，服务端收到后发送响应包，服务端一旦发送完响应包之后，服务端会立即主动断开tcp连接，下次http通信还需要重新建立tcp连接。 同一个用户在短期内访问多次服务端，那大量的时候都会消耗在重复创建tcp连接上，在高并发场景下，对服务端是非常大的消耗，客户端的访问速度也会非常的慢

无状态（一个http协议的请求无法标识自己的身份）：http无法保存状态，比如登录状态，那意味着每次请求都需要重新输出一次账号密码来认证

http1.0

请求方法：支持PUT(增)、DELETE(删)、POST(改)、GET(查)

请求头：支持

响应信息：支持超文本

支持缓存

同一个用户在短期内访问多次服务端，不要重复建立tcp连接，而是能够共用一个tcp连接解决方案：支持持久连接/长连接 keep-alive

• 前提：发送完http响应包之后，服务端立即断tcp连接，这是服务端的默认行为，要改变这种默认行为，要客户端通知服务端才行
• 实现：
  • 客户端在发送http的请求时，需要再请求头里带上connection: keep-alive这个参数
  • 服务端的keepalive timeout设置要大于0
  • 服务端收到后读取该参数，服务端会保持与这一个客户端tcp连接一段时间，响应时也会在响应头里放connection:keep-alive这个参数
  • 该tcp会保持一段时间直到达到服务端设置的keepalive_timeout时间
• 补充:
  • 在http1.0协议还需要你发请求时你自己加上connection: keep-alive这个参数
  • 在http1.1协议里所有的请求都会自动加上connection: keep-alive，也就是说在htp1.1客户端默认就开启了长连接支持，配套的服务端也要开启(服务端的keepalive_timeout设置要大于0)

服务端要客户端有状态(让客户端每次发请求的时候都能标识自身的唯一性)：解决方案是cookie、session、jwt

cookie机制：

1. 访问一个站点，服务端返回的响应头会设置set-cookie: k1=v1;k2=v2
2. 浏览器收到后，会根据set-cookie来设置存入本地的cookie值
3. 下次请求该网站，浏览器会从本地cookie里取出cookie值，放到http请求的cookie字段里，发往服务端
4. 特点:
   • cookie是浏览器的功能，是放在客户端的
   • cookie内存放的内容是可以被客户端篡改的

cookie机制+session机制：

1. 访问一个站点，输入自己的账号密码进程认证，服务端收到请求之后认证通过，会产生一些标识用身份的数据
   • 这些数据 ---> value
   • 把这些数据关联一个 ---> key
   • key:value
   • key给客户端，存入cookie
   • value放在服务端，称之为session
2. 服务端会把key放入cookie放入set-cookie里，返回给客户端
3. 客户端收到响应后，会把key存入本地的cookie
4. 下次请求该网站，会带着该key去到目标站点，目标站点收到后，会根据key取出value，value里放着本次请求的身份
5. 特点:
   把保密数据放在服务端，称之为session数据，然后针对session数据生成一个key值存入客户端的cookie中
   • 可以防止篡改
   • 在集群的场景下，需要做会话共享(session存入共享的地方)
     • 通过会将session数据存入redis
     • redis作为一个大家依赖的共享点，会影响集群的扩展性

总结cookie和session：

• 单用cookie来存放状态信息
  • 优点:服务端不需要做会话共享
  • 缺点:客户端可以算改状态信息，不安全
• cookie+session
  • 优点:状态信息即session数据是存放在服务端的，状态不会被改
  • 缺点:服务端需要做会话共享，增加了集群的耦合性

JWT(json web token)：

1. 服务端会将状态信息进行加密，然后把加密数据放入客户的cookie中，这个加密的数据称之为token ---> 篡改的问题解决了
2. 下次请求会从cookie中取出token带上一起发送给服务端，服务端收到后用加密算法解密 ---> 不需要再做会话共享/保持
3. 追求：服务端不保存状态
4. 优点：不需要做会话共享、又能很安全
5. 缺点：最大的缺点就是无法做到主动废弃掉某个token，一个token一旦下发之后，就只能等着该token，服务端无法做到主动废弃该token ---> 想要做到随时都能主动废弃掉某个token，就需要开发额外的代码来支持

http1.1

默认所有请求都启用长连接，请求与响应头里都带着connection:keep-alive，对应服务端需要设置keepalive timeout大于0

Pipelining(请求流水线化/管道化)

分块传输编码chunked

http2.0

引入头信息压缩机制：头信息使用gzip或compress压缩后再发送

允许服务器有新数据时未经请求，主动向客户端发送资源，而无需客户端拉取，即服务器推送（server push）

http协议的格式

URI和URL

URI：统一资源标识符

URL：统一资源定位服务，是URI的一种具体实现
http://192.168.71.10:8080/a/b/1.txt?x=1&y=2&page=10#_label5

• http:// ---> 协议部分。不写协议，默认http协议
• 192.168.71.10:8080 ---> ip+port部分，不写端口默认服务端的端口是80
• /a/b/1.txt ---> 路径部分，不写路径，默认加一个/结尾
• ?x=1&y=2&page=10 ---> 请求参数部分
• #_label5 ---> 锚

URN：也是URI的一种具体实现，例如：mailto:java-net@java.sun.com.

请求request

包含四部分：

• 请求首行：请求方法 请求的路径部分及后续部分 http协议版本
  • GET /a.txt HTTP/1.1
• 请求头：都是 key:value 格式，用来定制一些参数
• 空行
• 请求体数据

请求方法:

• GET(查) ----> 请求的数据可以放在URL地址的?号后
• POST(改) ----> 携带请求体数据
• DELETE(删)
• PUT(增)
• HEAD：类似GET请求，不一样的是不会获取响应的数据，但是会获取响应头，而响应头包含着状态码，状态码代表着本次访问是否成功，所以HEAD主要用来检测某个资源是否可以正常访问
• OPTIONS：一般用作预检请求，在发真正请求之前先发个options请求预检一下服务端支持哪些http方法、跨域检测等

GET和POST的区别:

• 携带数据的方式不同
• 携带数据的话post更安全
• 传输数据大小
  • GET与POST这两个方法本身没有限制
  • 但因为GET方法的数据都放在URL地址中，而URL地址的长度在一些浏览器中是有限制
  • 所以如果要传一些比较大的数据，不能用GET方法，应该使用POST方法把数据放入请求里传输

响应response

也是包含四部分：

• 响应首行：协议 状态码
  • HTTP/1.1 200 OK
• 响应头
  • set-cookie：要求浏览器把cookie信息存入本地
  • cache-control：要求浏览器把一些文件缓存到本地
  • connection:keep-alive：要求浏览器保持长连接
  • Content-Type:text/html：告诉浏览器本次返回内容的格式
    • text/plain 告诉浏览器本次返回的内容格式是普通文本
• 空行
• 响应体

状态码

• 2xx：代表访问成功
• 3xx：本次请求被重定向
• 4xx：客户端错误
  • 404：客户端访问的资源不存在
  • 403：客户端没有对目标资源的访问权限
• 5xx：服务端错误
  • 503：服务端故障

http协议完整的请求与响应流程

浏览器访问一个URL地址：http://baidu.com:80/a/b/1.html

1. 浏览器会先问本地DNS把域名baidu.com解析为ip地址
2. 浏览器作为客户端会与目 ip:port 建立TCP三次握手
3. 浏览器会基于HTTP协议封装请求包(OSI七层的封包流程)
4. 服务端收到包(OSI七层的解包流程)，拿到一个HTTP协议的请求包，按照HTTP协议来解析请求会拿到请求路径部分 /a/b/1.html，服务端会打开该文件(对一个文件描述符)把文件内容从硬盘读入内存，然后服务端程序会基于HTTP协议封装读入内存的数据，形成一个响应包，发给客户端浏览器
5. 浏览器收到HTTP协议的响应包之后，先解析响应头，看到响应的状态码，知道本次是否成功，在解析响应头时，可以拿到Content-Type就知道该用什么数据格式来解析内容，如果值为 text/html 就会按照html代码的方式来解析返回的内容，再读取内容部分，当成html代码来解析
6. 在解析html代码的过程中，有可能遇到css、jss、图片、视频等资源，会发起二次、三次...请求，直到把整个页面都渲染完毕

HTTPS详解

为什么使用HTTPS

http协议：明文传输，可能会遭到窃听、改、冒充/挟持，因此使用HTTP协议传输隐私信息非常不安全。

https：http协议+ssl协议，密文传输，可以防止窃听、算改，并且有ca权威机构认证服务端身份，可以防冒充/劫持

SSL协议

SSL是一种加密协议，对http协议通信的加强，可以防窃听、改、伪装/冒充

数字签名：防止篡改/丢失

• 把包的内容做hash校验得到的hash值称之为摘要 ---> digest
• 服务端用自己的私钥对digest进行加密 ---> 得到东西叫数字签名signature
• 客户端收到包之后先用公钥解开得到digest ---> 重新hash，验证是否被篡改

数字证书：防止伪装/冒充

• CA中心：公认的权威认证中心，找一个证书中心为自己的公钥做认证。
• CA中心用自己的私钥，对服务端的公钥和其他相关信息一起加密，生成"数字证书"。
• 数字证书就是加了密的服务端公钥。

非对称加密

• 两个密码(公钥、私钥)：公钥加密用私钥解密，私钥加密用公钥解密
• 优点：
  • 公私分明，公钥任何人都可以获取，而私钥只有服务端自己手里有
  • 安全性更高一些，只要私钥不泄露，就没法解开包
• 缺点：非对称加密的速度慢，不适合大规模数据加解密

对称加密

• 只有一个私钥，加解密用的都是同一套私钥
• 优点：加解密效率高
• 缺点：私钥的泄露几率高，一旦某一方泄露私钥，则加密信息就无法得到安全保障问题

SSL协议通信过程中即用了非对称加密，又用了对称加密

• 客户端先通过ssl通信的第二次握手获得服务端数字证书（内含公钥）
• 然后使用非对称加密传输对称加密的密钥（更安全），后面的数据传输就使用对称性加密（更高效）。

HTTPS通信过程

认证作用就是为了确定对方的真实性，避免其他人伪装/冒充，主要是通过CA机构对数字证书的认证，来判断访问对象真实性。

单向认证：客户端验证服务端的真假，防止有人冒充服务端

双向认证

• 客户端验证服务端的真假，防止有人冒充服务端
• 服务端也要认证客户端的真假，防止有人冒充客户端
  

TLS协议

SSL是一种技术，您的应用程序或浏览器可能使用该技术在任何网络上创建安全的加密通信通道。但是SSL是一种较老的技术，包含一些安全漏洞。传输层安全性协议(TLS)是SSL 的升级版本，用于修复现有 SSL 漏洞。TLS 可以更高效地进行身份验证，并继续支持加密的通信通道。

TLS协议就是一个升级版的SSL，由于SSL这一术语更为常用，所以我们通常仍将我们的安全证书称作SSL