企业网站公示怎么做百度平台客服
大家好我是苏麟 , 今天说说HTTP特性.
资料来源 : 小林coding
小林官方网站 : 小林coding (xiaolincoding.com)
到目前为止，HTTP 常见到版本有 HTTP/1.1，HTTP/2.0,HTTP/3.0，不同版本的 HTTP 特性是不一样的。
这里先用 HTTP/1.1 版本给大家介绍，其他版本的后续也会介绍。
HTTP/1.1 的优点有哪些?
HTTP 最突出的优点是「简单、灵活和易于扩展、应用广泛和跨平台」。
1.简单
HTTP 基本的报文格式就是 header+body , 头部信息也是 key-value 简单文本的形式，易于理解，降低了学习和使用的门槛。
2.灵活和易于扩展
HTTP 协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发人员自定义和扩充。
同时 HTTP 由于是工作在应用层( OS! 第七层)，则它下层可以随意变化，比如:
- HTTPS 就是在 HTTP 与 TCP 层之间增加了 SSL/TLS 安全传输层
- HTTP/1.1 和 HTTP/2.0 传输协议使用的是 TCP 协议，而到了 HTTP/3.0 传输协议改用了 UDP 协议
3.应用广泛和跨平台
互联网发展至今，HTTP 的应用范围非常的广泛，从台式机的浏览器到手机上的各种 APP，从看新闻、刷贴吧到购物、理财、吃鸡，HTTP 的应用遍地开花，同时天然具有跨平台的优越性。
HTTP/1.1 的缺点有哪些?
HTTP 协议里有优缺点一体的双刃剑，分别是「无状态、明文传输」，同时还有一大缺点「不安全」。
1.无状态双刃剑
无状态的好处，因为服务器不会去记忆 HTTP 的状态，所以不需要额外的资源来记录状态信息，这能减轻服务器的负担，能够把更多的 CPU 和内存用来对外提供服务。
无状态的坏处，既然服务器没有记忆能力，它在完成有关联性的操作时会非常麻烦。
例如登录->添加购物车->下单->结算->支付，这系列操作都要知道用户的身份才行。但服务器不知道这些请求是有关联的，每次都要问一遍身份信息。
这样每操作一次，都要验证信息，这样的购物体验还能愉快吗?别问，问就是酸爽
对于无状态的问题，解法方案有很多种，其中比较简单的方式用 Cookie 技术
Cookie 通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态
相当于，在客户端第一次请求后，服务器会下发一个装有客户信息的「小贴纸」，后续客户端请求服务器的时候，带上「小贴纸」，服务器就能认得了了
2.明文传输双刃剑
明文意味着在传输过程中的信息，是可方便阅读的，比如 Wireshark 抓包都可以直接肉眼查看，为我们调试工作带了极大的便利性。
但是这正是这样，HTTP 的所有信息都暴露在了光天化日下，相当于信息裸奔。在传输的漫长的过程中信息的内容都毫无隐私可言，很容易就能被窃取，如果里面有你的账号密码信息，那你号没了。
3.不安全
HTTP 比较严重的缺点就是不安全:
- 通信使用明文(不加密)，内容可能会被窃听。比如，账号信息容易泄漏，那你号没了
- 不验证通信方的身份，因此有可能遭遇伪装。比如，访问假的淘宝、拼多多，那你钱没了
- 无法证明报文的完整性，所以有可能已遭篡改。比如，网页上植入垃圾广告，视觉污染，眼没了
HTTP 的安全问题，可以用 HTTPS 的方式解决，也就是通过引入 SSLTLS 层，使得在安全上达到了极致。
HTTP/1.1 的性能如何?
HTTP 协议是基于 TCP/IP，并且使用了「请求-应答」的通信模式，所以性能的关键就在这两点里
1.长连接
早期 HTTP/1.0 性能上的一个很大的问题，那就是每发起一个请求，都要新建一次 TCP 连接(三次握手)，而且是串行请求，做了无谓的TCP 连接建立和断开，增加了通信开销。
为了解决上述 TCP 连接问题，HTTP/1.1 提出了长连接的通信方式，也叫持久连接。这种方式的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。
持久连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。
当然，如果某个 HTTP 长连接超过一定时间没有任何数据交互，服务端就会主动断开这个连接。
2.管道网络传输
HTTP/1.1 采用了长连接的方式，这使得管道(pipeline)网络传输成为了可能
即可在同一个 TCP 连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。
举例来说，客户端需要请求两个资源。以前的做法是，在同一个 TCP 连接里面，先发送A 请求，然后等待服务器做出回应，收到后再发出 B请求。那么，管道机制则是允许浏览器同时发出 A请求和 B 请求，如下图:
但是服务器必须按照接收请求的顺序发送对这些管道化请求的响应
如果服务端在处理 A 请求时耗时比较长，那么后续的请求的处理都会被阻塞住，这称为「队头堵塞」。
所以，HTTP/1.1 管道解决了请求的队头阻塞，但是没有解决响应的队头阻塞
注意!!!
实际上 HTTP/1.1 管道化技术不是默认开启，而且浏览器基本都没有支持，所以后面所有文章讨论HTTP/1.1 都是建立在没有使用管道化的前提。大家知道有这个功能，但是没有被使用就行了。
3. 队头阻塞
「请求-应答」的模式会造成 HTTP 的性能问题。为什么呢?
因为当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一同被阻塞了，会招致客户端一直请求不到数据，这也就是「队头阻塞」，好比上班的路上塞车。
总之 HTTP/1.1 的性能一般般，后续的 HTTP/2 和 HTTP/3 就是在优化 HTTP 的性能。
这期就到这里,下期见 !