HTTP相关问题

HTTP长连接和短连接

• HTTP/1.0默认使用短连接。客户端和服务器建立连接，完成传输任务之后，就会终端这个连接。下一次还有请求任务时，重新建立连接。
• HTTP/1.1开始，默认使用长连接。使用长连接，会在HTTP响应头增加内容Connection:keep-alive。即，在完成一次传输任务之后并不会马上关闭这个连接，下一次还有请求的时候，客户端和服务器的连接已经是建立好的了。但是，这个连接并不会保持永久连接，我们可以在不同的服务器中设置这个时间。

HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

HTTP是无状态协议，那么怎么做到保持用于状态呢？

HTTP本身不对用户和服务器的连接的通讯状态进行保存。Session就是为了解决这个问题的，Session的主要作用就是通过服务器来来记录用户的状态。服务器端给特定的用户创建一个具有辨识性的Session用户标识并跟踪这个用户，一般情况下这个Session有一个存在时间，过期，则删除该Session。例如购物车添加商品的情景，想服务器发送请求并携带一个Cookie，Cookie中存放对应的SessionID，对比正确服务器就知道这个用户和自己的连接状态了。Session一般存放在数据库（MySQL、Redis）中。

存在一个问题：如果Cookie被禁用怎么办？最简单的办法就是，将SessionID作为参数附加在URL后面。

Cookie和Session

Cookie和Session都是用来跟踪浏览器用户身份的会话方式，但是使用场景不一样。有这么一个场景：你在浏览器上登录过一次了，下次再来访问这个网页的时候，大多数网页的做法都是让你免登录的------这是Cooike帮你做的事；你去网购物车里添加一件商品，往服务器端发送添加商品请求，服务器要判断这个请求是不是在登录状态下做的，如果不是，就拒绝请求------这个判断是否登录状态就是Session做的事。

写过JS的可能知道，这两个事务的过程：

• Cookie：用户再次浏览一个页面，在渲染页面（created）的时候便执行JS，在localStorage或者globalStorage中找对应的token，如果找得到，那说明用户是处于登录状态的。也就是为什么你清理掉浏览器Cookie之后，你的登录状态都失效了的原因。
• Session：服务器想要知道用户是不是处于登录状态，那么就需要用户在发送请求的时候，把Cookie中存放的SessionID跟着请求一起发送到服务器，服务器跟自己存在的SessionID做对比，相同，那么就判断用户是处于登录状态的。

Cookie存放在客户端、Session存放在服务器端，Session相对CooKie来说更加安全。

HTTP/1.0和HTTP/1.1的区别

由于面向的场景不一样，导致有这两个HTTP版本。HTTP/1.0最早使用在1996年，当时还只是请求一些简单的网页和简单的网络请求上，所以相对1999年使用的HTTP/1.1存在一些不足：

1. 长/短连接。前面的问题已经提到过这个。后面的HTTP使用长连接的原因是：TCP建立连接开销是很大的，三次握手、四次挥手，如果每次请求都是用短连接的话，效率就会很低下。
2. 错误状态响应码。可以这么理解，1.0版本请求相对简单，错误类型没这么多，1.1版本就完善了一下。
3. 缓存处理。1.1版本有跟多的缓存处理方法。
4. 带宽优化及网络连接的使用。1.0版本要请求某个对象的一部分时，服务器会将整个对象个传过来；1.1版本使得服务器只会传这个对象的一部分。

HTTP和HTTPS

1. 端口：HTTP默认80端口，HTTPS默认443端口
2. 安全性：HTTP使用TCP进行明文传输，客户端和服务器端无法验证对方的身份。HTTPS是运行在SSL/TLS上的协议，SSL/TLS运行在TCP上，也就是说HTTPS会对报文进行加密（对称加密和非对称加密），将加密的报文通过TCP进行传输。显然，有这些加密操作会拉低HTTPS的性能，故HTTPS会消耗更多的资源。

对称加密和非对称加密可以见博文https://blog.csdn.net/weixin_42065178/article/details/124413389