🗒️HTTP 的特点
HTTP/1.1 的特点、优点、缺点
1. HTTP 协议的特点
1.1 灵活可扩展
HTTP 协议是一个“灵活可扩展”的传输协议。结合它的报文格式，我们知道 HTTP 是可以任意添加 header 字段实现任意功能的，其 body 也支持各种格式。
正是因为这个特点，HTTP 才能在三十年的历史长河中屹立不倒。
1.2 可靠传输
HTTP 协议是一个“可靠”的传输协议，因为它是基于 TCP/IP 协议的。
不过，我们必须正确地理解“可靠”的含义，HTTP 并不能 100% 保证数据一定能够发送到另一端。比如在网络繁忙或连接质量差等恶劣的环境下，也是有可能收发失败的；比如光纤被意外挖断，那必然是不能发送成功的。“可靠”只是向使用者提供了一个承诺——会在下层使用多种手段“尽量”地保证数据的完整送达。
“可靠”传输是指，在网络基本正常的情况下，数据收发必定成功。
1.3 应用层协议
HTTP 协议是一个应用层的协议。虽然这个特点不言自明，但却很重要。
在 TCP/IP 诞生后的几十年里，虽然出现了许多的应用层协议，但它们都只关注很小的应用领域，局限在很少的应用场景。比如 FTP 只能传输文件、SMTP 只能发送邮件、SSH 只能远程登录等，它们在通用数据传输方面都不行。
HTTP 称得上是一个万能协议，它几乎可以传递一切东西，只要不太苛求性能。套用一个流行段子，HTTP 完全可以用开玩笑的口吻说：“不要误会，我不是针对 FTP，我是说在座的应用层各位，都是垃圾。”
1.4 请求-应答
HTTP 协议使用的是“请求-应答”的通信模式，通俗地讲就是一发一收、有来有去。
请求-应答模式明确了 HTTP 协议里通信双方的定位，永远是请求方先发起连接和请求（是主动的），而应答方只有在收到请求后才能答复（是被动的），当没有请求时是不会有任何动作的。客户端主动发起请求，服务器被动回复请求。
HTTP 的请求-应答模式也恰好契合了传统的 C/S（Client/Server）系统架构，以及随着互联网发展而出现的 B/S（Browser/Server）架构。B/S 架构是用轻量级的浏览器代替笨重的客户端应用，实现零维护的瘦客户端，而服务器则摈弃私有通信协议转而使用 HTTP 协议。
请求-应答模式也完全符合 RPC（Remote Procedure Call）的工作模式，可以把 HTTP 请求处理封装成远程函数调用，从而出现了 WebService、RESTful 和 gRPC 等。
1.5 无状态
HTTP 协议是无状态的。
所谓“状态”，就是客户端或服务器里保存的一些数据和标志，记录了通信过程中的一些变化信息。
对比有状态的 TCP 协议理解下。在 HTTP 中，整个协议中没有规定任何的“状态”，客户端和服务器永远处在一种“无知”的状态：建立连接前，两者互不知情；每次收发的报文，也都互相独立，没有任何联系；收发报文也不会对客户端或服务器产生任何影响；连接后，也不会要求保存任何信息。
“无状态”就是“没有记忆能力”。比如，浏览器发了一个请求说“我是小明，请给我文件 A”，服务器收到报文后就会检查一下权限，看小明确实可以访问文件 A，于是就把文件发回给了浏览器。接着浏览器还想要文件 B，但服务器不会记录刚才的请求状态，不知道第二个请求和第一个请求是同一个浏览器发来的，所以浏览器必须再重复一次自己的身份才行“我是刚才的小明，请再给我文件 B。”
对比无连接也无状态的 UDP 协议理解下。UDP 是顺序发乱序收，数据包发出去后就不管了，收到后也不会顺序整理。而 HTTP 是有连接无状态，顺序发顺序收，按照收发的顺序管理报文。
综上，HTTP 本质上是无状态的，每个请求都是互相独立、毫无关联的，协议不要求客户端或服务器记录请求相关的信息。但又因为 HTTP 是“灵活可扩展”的，所以虽然标准里没有规定“状态”，但完全能够在协议的框架里给它“打个补丁”，增加这个特性。
1.6 其它
以下都是由“灵活可扩展”这一特点衍生出来的，比如：
传输的实体数据可缓存、可压缩、可分段
支持身份认证
支持国际化语言
2. 优点
2.1 简单+灵活易扩展
HTTP 最大的优点就是简单、灵活和易于扩展；
简单：“文本”协议，报文格式
灵活+易于扩展（互为表里 互相促进）
报文的字段定制：每一个核心的组成要素都不是写死的
对“可靠传输”的定义上：它不限制具体的下层协议（TCP, UNIX Domain Socket, SSL/TLS, 基于 UDP 的 QUIC），下层可以随意变化，而上层的语义始终保持稳定
2.2 应用广泛+环境成熟
HTTP 拥有成熟的软硬件环境，应用的非常广泛，是互联网的基础设施。
在应用领域，HTTP 无处不在
在开发领域，几乎所有的编程语言都有 HTTP 调用库和外围的开发测试工具（跨语言、跨平台）
硬件基础设施的支持：各个公司都不遗余力地购买服务器、开办网站、建设数据中心/CDN/高速光纤、持续地优化上网体验，让 HTTP 运行得越来越顺畅
HTTP 协议是开发者必须要掌握的基本技能
出于安全原因，绝大多数网站都封禁了 80/8080 以外的端口号，只允许 HTTP 穿透。这也是造成 HTTP 流行的客观原因之一。
3. 双刃剑
3.1 无状态
3.1.1 好处
HTTP 是无状态的，可以轻松实现集群化，扩展性能。
因为服务器没有记忆能力，所以就不需要用额外的资源来记录状态信息，不仅实现上会简单一些，还能减轻服务器的负担，能够把更多的 CPU 和内存用来对外提供服务。
此外，无状态也表示服务器都是相同的，没有状态的差异，所以可以很容易地组成集群，让负载均衡把请求转发到任意一台服务器，不会因为状态不一致导致处理出错，使用堆机器的笨办法也能轻松实现高并发高可用。
3.1.2 坏处
既然服务器没有记忆能力，那它就无法支持需要连续多个步骤的事务操作。
比如电商购物，首先要登录，然后添加购物车，再下单、结算、支付，这一系列操作都需要知道用户的身份才行，但“无状态”服务器是不知道这些请求是相互关联的，每次都得问一遍身份信息，不仅麻烦，而且还增加了不必要的数据传输量。
可使用 Cookie 技术来实现“有状态”
3.2 明文传输
明文是指协议里的报文（准确地说是 header 部分）使用了简单可阅读的文本形式，而不是二进制数据。HTTP 是明文传输，数据完全肉眼可见，能够方便地研究分析，但也容易被窃听。
3.2.1 好处
不需要借助任何外部工具，用浏览器、Wireshark 或者 tcpdump 抓包后，直接用肉眼就可以很容易地查看或者修改，为开发调试工作带来极大的便利。
3.2.2 坏处
HTTP 报文的所有信息都会暴露在光天化日之下，在漫长的传输链路的每一个环节上都毫无隐私可言，不怀好意的人只要侵入了这个链路里的某个设备，简单地旁路一下流量，就可以实现对通信的窥视。
比如免费 WiFi 陷阱，黑客就是利用了 HTTP 明文传输的缺点，在公共场所架设一个 WiFi 热点开始钓鱼，诱骗网民上网。一旦连上了这个 WiFi 热点，所有的流量都会被截获保存，里面如果有银行卡号、网站密码等敏感信息的话那就危险了，黑客拿到了这些数据就可以冒充你为所欲为。
4. 缺点
4.1 不安全
HTTP 是不安全的，无法验证通信双方的身份，也不能判断报文是否被篡改；
不安全和“明文”相关，但不完全等同，因为安全有很多方面：
在机密性方面，明文是个缺点
在身份认证方面：HTTP 没有提供有效的手段来确认通信双方的真实身份
身份认证简单来说就是：怎么证明你就是你
虽然协议里有一个基本的认证机制，但因为“明文传输”的缺点，该机制几乎可以说是纸糊的，非常容易被攻破。
如果仅使用 HTTP 协议，我们很可能会连到一个页面一模一样但却是个假冒的网站，然后再被钓走各种私人信息
完整性校验：HTTP 也不支持完整性校验，数据在传输过程中容易被篡改而无法验证真伪
比如我们收到了一条银行用 HTTP 发来的消息“小明向你转账100元”，但我们无法知道小明是否真的就只转了一百元，也许他转了1k或50元，但被黑客篡改成了100元，真实情况到底是什么样子，HTTP 协议没办法给我们答案。
虽然银行可以用 MD5、SHA1 等算法给报文加上数字摘要，但还是因为“明文”这个致命缺点，黑客可以连同摘要一同修改，最终还是判断不出报文是否被篡改。
为了解决 HTTP 不安全的缺点，就出现了 HTTPS。
4.2 性能
用六个字概括：“不算差，不够好”。HTTP 的性能不算差，但不完全适应现在的互联网，还有很大的提升空间。
HTTP 协议基于 TCP/IP，并且使用了“请求-应答”的通信模式，所以性能的关键就在这两点上。
必须要说的是，TCP 的性能是不差的，否则也不会纵横互联网江湖四十余载了，而且它已经被研究得很透，集成在操作系统内核里经过了细致的优化，足以应付大多数的场景。只可惜现在互联网的特点是移动和高并发，不能保证稳定的连接质量，所以在 TCP 层面上 HTTP 协议有时就会表现得不够好。
而“请求-应答”模式则加剧了 HTTP 的性能问题，这就是著名的“队头阻塞”（Head-of-line blocking），当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一并被阻塞，会导致客户端迟迟收不到数据。
此外，HTTP/1.1 以文本格式传输 header，有严重的数据冗余，也影响了它的性能。
为了解决这个问题，就诞生了一个专门的研究课题“Web 性能优化”，HTTP 官方标准里就有“缓存”一章。非官方的招儿就更多了，比如切图、数据内嵌与合并、域名分片、JavaScript 黑科技等。
不过，现在已经有了终极解决方案：HTTP/2 和 HTTP/3。
5. 主要参考
笔记整理自：
Last updated