http的小总结

最近看图解网络，在这里做个笔记

http的概念

​ http -> 超文本传输协议，早期只是用来传输文本，现在可以用了传输音频图像，所以称为超文本协议

GET 与 POST

• get请求： get 意为得到，取得 get请求就是 请求从服务器获取资源，这个资源可以是静态的⽂本、⻚⾯、图⽚视频等。

• post请求： post 投递的意思，他将指定的资源通过http协议提交服务器

说到get和post 又得提到 安全 和 幂等

• 安全是指 多次请求不会对服务区产生副作用，即不会改变资源的转态，打个比方，我想用get请求一个网页，无论操作多少次，对服务器上的数据都不影响，而post有新增或提交数据的操作，会修改服务器上的资源，所以不是安全的
• 幂等是指多次执⾏相同的操作，得到的结果都是相同的，每次get请求一个页面，都是一样的则这个是幂等的

http特性

• 跨平台，易扩展

  手机端，PC端都可以使用

• 简单，http 格式 有 header + body（数据 ),头部 key -value形式存储如下所示

GET /admin_ui/rdx/core/images/close.png HTTP/1.1
Accept: */*
Referer: http://xxx.xxx.xxx.xxx/menu/neo
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E)
Accept-Encoding: gzip, deflate
Host: xxx.xxx.xxx.xxx
Connection: Keep-Alive
Cookie: startupapp=neo; is_cisco_platform=0; rdx_pagination_size=250%20Per%20Page; SESSID=deb31b8eb9ca68a514cf55777744e339

• 无状态 服务器不会去记忆 HTTP 的状态，所以不需要额外的资源来记录状态信息，这能减轻服务器的负担，能够把更多的 CPU 和内存⽤来对外提供服务 ，就好像 登录了某个网站，正常来说验证一次密码（那是有cookie情况下），没状态情况是 每次操作都得重新输入一次密码，这样肯定不方便，后来引入cookie；
• 不安全：
  • 明文传输，抓包一下子就数据就泄漏了
  • 没有验证对方的真实身份，可能访问到伪装的网站
  • 可以篡改报文内容，抓包后修改里面的内容也是可以的

---

http 和 https（重点）

上文收到htpp传输是明文传输不安全的，数据有篡改和冒充的风险，为了提高安全性，目前都基本使用 https, 这里的s指的 是SecureSocket Layer（SSL） 的首字母，意为安全套接层

https是什么？

​ HTTPS 可以解决 HTTP 不安全的缺陷，在TCP 和 HTTP ⽹络层之间加⼊了 SSL/TLS 安全协议，使得报⽂能够加密传输。HTTPS 在 TCP 三次握⼿之后还需要进行 SSL/TLS的握手过程，才可进⼊加密报⽂传输； HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的（防止伪装站点）。

HTTP和TCP直接加了一层SSL/TLS

公钥 私钥 对称加密

• 公钥 和 私钥 ： 可以类比为 公钥→锁头 私钥→钥匙（私钥只有一把只有一把） 我用公钥加密数据，那我就的用对应的私钥解密数据
• 非对称加密： 使用两个秘钥来加密数据， 就是上面提到的 公钥和秘钥
• 对称加密： 使用一个共同加密方式来 加密数据，简称 会话秘钥
• 证书： 可以理解为一种合法身份的象征，把公钥放在证书里，只要证书是可信的，公钥就是可信的

加密方式

HTTPS 采⽤的是对称加密和⾮对称加密结合的「混合加密」⽅式：

• 在通信建⽴前采⽤⾮对称加密的⽅式交换「会话秘钥」，后续就不再使⽤⾮对称加密。
• 在通信过程中全部使⽤对称加密的「会话秘钥」的⽅式加密明⽂数据。

如何实现的呢？

在TCP三次握手后， 首先使用非对称加密的方式 生成会话秘钥，接下来服务端和客户端都是使用 这个会话秘钥加密数据（对称加密），所以现在分为两部分来讲，以下也会SSL/TLS协议基本流程

• 非对称加密

  这部分的目标是生成 会话秘钥，双方都可用的秘钥！

  这里我先用通俗的语言来说

  服务器 自己有 公钥和秘钥， 他把公钥 交给比较权威的机构，生成证书，机构使用自己的私钥加密这个证书

  客户端这边 携带了 机构的公钥，然后客户想服务端请求证书，然后用机构的公钥确定这个证书是否是可信的，如果用记过的公钥能解锁这个证书，说明服务端是经过机构认证的，就可通过证书获得服务端的公钥！

  • 为什么要通过第三方来过去服务端的公钥呢？

  ​ 如果直接把服务端的公钥发给客户端没有加密的话，中间如果有人拦截了并伪造了公钥，那就后果不堪设想了，所以有了证书确认身份，可以减少这个风险发生；

  ​ 现在客户端获得了服务端的公钥，用服务端的公钥加密消息，和服务端通信，商定好 会话秘钥，而这这个会话秘钥如何生成的呢？ 是通过 ssl协议的四次握手生成的
  - 首先客户端向服务器发起加密通信请求，加密内容包含了客户端产生的随机数， SSL/TLS 协议版本，如 TLS 1.2 版本，以及客户端支持的解密算法，最后用从证书获取服务端的公钥进行加密。这里就保证了只有服务端才能看到这个消息（只有服务端才有私钥）。
  - 服务端收到后，给客户端发出响应，内容如下

      （1）确认 SSL/ TLS 协议版本，如果浏览器不⽀持，则关闭加密通信。
  

  ​ （2）服务器⽣产的随机数（ Server Random ），后⾯⽤于⽣产「会话秘钥」。

  ​ （3）确认的密码套件列表，如 RSA 加密算法。 （确定使用那种算法）

  ​ （4）服务器的数字证书

  ​ 服务端也会产生随机数，且确定使用那种加密算法，此时还需要确定这个消息真实性，防止被别人篡改了，所以还需要再一次 验证证书是否可信

  • 客户端收到后，⾸先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。没问题的话取出证书的公钥来加密待会要发送的数据，待发送的数据如下

    （1）⼀个随机数（ pre-master key ）。该随机数会被服务器公钥加密。
    

  ​ （2）加密通信算法改变通知，表示随后的信息都将⽤「会话秘钥」加密通信。

  ​ （3）客户端握⼿结束通知，表示客户端的握⼿阶段已经结束。同时把之前所有内容的发⽣的数据做个摘要，⽤来供服务端校验

  • 服务端收到后，也会回应，也是最后一次回应了，通过私钥解密，服务器收到客户端的第三个随机数（ pre-master key ）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。然后，向客户端发⽣最后的信息。

  ⾄此，整个 SSL/TLS 的握⼿阶段全部结束。接下来，客户端与服务器进⼊加密通信，实际上还是使用基本http通信，只不过是 通信前双方 约定好加密解锁方式而已

​ 对于https 介绍到这里先结束，其实这其中还有很多的细节没有阐述清楚，后续又遇到关于https的问题再补充下；

---

https1.1 改进和瓶颈

• 长链接

  http1.0 中 每一次的请求都建立三次握手（http是基于tcp的），增加了开销，http1.1 增加了长链接方式，建立了一次tcp链接后，接下来都不需要重新握手

• 管道传输

  hhtp1.0 中发一次请求，等待回应，有回应后然后在发送下一个请求，在1.1中，使用过管道传输则可以同⼀个 TCP 连接⾥⾯，客户端可以发起多个请求，只要第⼀个请求发出去了，不必等其回来，就可以发第⼆个请求出去，可以减少整体的响应时间

• 瓶颈

  • 但是可能会造成对头堵塞 多个请求发个服务器后，服务器处理请求还是按照先后顺序来，如果某个请求耗时长，堵塞了接下来的请求（可以加开多几条连接）
  • 协议头部无法压缩，只能压缩 Body 部分，传输效率低
  • 请求只能客户端开始，服务器只能被动响应（websocket 可以）

http2.0 改进

• 头部压缩

  发送多个请求如果 是头部数据相似，协议会使用头部压缩算法（HPACK）清除重复的部分

• 使用二进制文本

  从明文报文改进为二进制格式的报文，对计算机来说，可以直接解析，增加数据的传输效率

• 多路复用

  一个连接并发多个请求或回应，不用像上一代版本会有阻塞，通俗的说就是服务端处理这A和B两个请求，A的处理时间比较长，于是就先回应A处理好的部分，然后回应B请求，然后再回复A请求剩下的（如果出现丢包还能回阻塞的）

• 服务器推送

  HTTP2.0新增的一个强大的新功能，就是服务器可以对一个客户端请求发送多个响应。服务器向客户端推送资源无需客户端明确的请求。HTTP 2.0 可以使服务器主动返回资源给客户端用户。

http3.0

基于UDP的QUIC协议，主要改进的问题还是 请求阻塞的问题（udp传输特性），减少了tcp三次握手时间，以及tls握手时间

---

待更新