http/https
1、http与https
| HTTP | HTTPS |
| 信息明文传输 | 加入ssl加密传输协议，可以使得报文加密传输 |
| 默认端口80 | 默认端口443 |
| 连接简单TCP三次握手通信 | TCP三次握手后还要SSL/TLS握手过程，才可以加密报文传输 |
| 无状态不安全 | 需要到CA申请证书，身份认证，自然安全 |
| http/1.0 | 1. 默认不支持长连接，需要设置keep-alive参数指定 2. 强缓存expired、协商缓存last-modified\if-modified-since 有一定的缺陷 |
| http 1.1 | 1. 默认长连接(keep-alive)，http请求可以复用Tcp连接，但是同一时间只能对应一个http请求(http请求在一个Tcp中是串行的) 2. 增加了强缓存cache-control、协商缓存etag\if-none-match 是对http/1 缓存的优化 |
| http/2.0 | 1. 多路复用，一个Tcp中多个http请求是并行的 ；2. 二进制格式编码传输；3. 使用HPACK算法做header压缩；4. 服务端推送 |
2、HTTP常用方法和常见状态码
| 方法 | 状态码 |
| GET： 用于请求访问已经被URI（统一资源标识符）识别的资源，可以通过URL传参给服务器 | 200 : 从状态码发出的请求被服务器正常处理。 204 : 服务器接收的请求已成功处理，但在返回的响应报文中不含实体的主体部分【即没有内容】。 206 : 部分的内容（如：客户端进行了范围请求，但是服务器成功执行了这部分的请求）。 |
| POST：用于传输信息给服务器，主要功能与GET方法类似，但一般推荐使用POST方式。 PUT： 传输文件，报文主体中包含文件内容，保存到对应URI位置。 | 301 : 跳转，代表永久性重定向（请求的资源已被分配了新的URI。 302 : 临时性重定向（请求的资源已经分配了新的URI，希望用户本次能够使用新的URI来进行访问）。 303 : 由于请求对应的资源存在的另一个URI（因使用get方法，定向获取请求的资源）。 304 : 客户端发送附带条件的请求时，服务器端允许请求访问资源，但因发生请求未满足条件的情况后，直接返回了 304。 307 : 临时重定向【该状态码与302有着相同的含义】。 |
| HEAD： 获得报文首部，与GET方法类似，只是不返回报文主体，一般用于验证URI是否有效。 DELETE：删除文件，与PUT方法相反，删除对应URI位置的文件。 | 400 : 请求报文中存在语法错误（当错误方式时，需修改请求的内容后，再次发送请求）。 401 : 发送的请求需要有通过HTTP认证的认证信息。 403 : 对请求资源的访问被服务器拒绝了。 404 : 服务器上无法找到请求的资源。 |
| OPTIONS：查询相应URI支持的HTTP方法 | 500 : 服务器端在执行请求时发生了错误。 503 : 服务器暂时处于超负载或者是正在进行停机维护，现在无法处理请求 |
| 最常用的：GET与POST的区别；1：GET请求在URL中传送的参数是有长度限制的，而POST没有。 2. GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。 POST参数放在Request body中。 3. GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。 4. GET请求只能进行url编码，而POST支持多种编码方式。 5. GET请求会被浏览器主动cache，而POST不会，除非手动设置。 6. GET产生的URL地址可以被Bookmark，而POST不可以。 7. GET在浏览器回退时是无害的，而POST会再次提交请求。 | |
3、cookie与session
| cookie | session |
| Cookie与Session都是会话的一种方式。它们的典型使用场景比如“购物车”，当你点击下单按钮时，服务端并不清楚具体用户的具体操作，为了标识并跟踪该用户，了解购物车中有几样物品，服务端通过为该用户创建Cookie/Session来获取这些信息（用来记录用户状态） | |
| cookie数据存放在客户的浏览器上 | session数据放在服务器上。 |
| cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗 | 考虑到安全应当使用session。 |
| 单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。 | session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，考虑性能方面使用cookie。 |
4、HTTPS建立连接的过程
1、先进行TCP三次握手客户端与服务端申请建立连接
2、建立TLS/SSL连接协商加密算法：
1）首先客户端向服务器发起加密通信请求，也就是 ClientHello 请求。这里客户端主要向服务器发送以下信息：（1）客户端支持的 SSL/TLS 协议版本，2）客户端生产的随机数（ Client Random ），后面用于生产会话秘钥。3）客户端支持的密码套件列表，如 RSA 加密算法。
2）服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello 。服务器回应的内容1）确认 SSL/ TLS 协议版本，如果浏览器不支持，则关闭加密通信。2）服务器生产的随机数（ Server Random ），后面用于生产「会话秘钥」。3）确认的密码套件列表，如 RSA 加密算法。4）服务器的数字证书。
3）客户端回应：收到回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：1）一个随机数（ pre-master key ）。该随机数会被服务器公钥加密。2）加密通信算法改变通知，表示随后的信息都将用会话秘钥加密通信。3）客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供服务端校验。这里的随机数是整个握手阶段的第三个随机数，这样服务器和客户端就同时有三个随机数，接着就用双方协商的加密算法，各自生成本次通信的会话秘钥。
4）服务器收到客户端的第三个随机数（ pre-master key ）之后，通过协商的加密算法，计算出本次通信的会话秘钥。然后向客户端发生最后的信息：1）加密通信算法改变通知，表示随后的信息都将用会话秘钥加密通信。2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。
至此，整个 SSL/TLS 的握手阶段全部结束。客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用会话秘钥加密内容。
简单流程就是：客户端在浏览器中输入一个https网址，然后连接到server的443端口采用https协议的server必须有一套数字证书（一套公钥和密钥） 首先server将证书（公钥）传送到客户端客户端解析证书，验证成功，则生成一个随机数（私钥），并用证书将该随机数加密后传回server，server用密钥解密后，获得这个随机值，然后将要传输的信息和私钥通过某种算法混合在一起（加密）传到客户端客户端用之前的生成的随机数（私钥）解密服务器端传来的信息。
原文地址：https://blog.csdn.net/dingyahui123/article/details/143961076
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！