http学习 http的特点
HTTP 协议是成熟的，但不是完美的。既要看到它好的一面，也要正视它不好的一面，只有全方位、多角度了解 HTTP，才能实现“扬长避短”，更好地利用 HTTP。
灵活可扩展 - 优点
- HTTP 协议是一个“灵活可扩展”的传输协议。
- http只规定了报文的基本格式，比如用空格分隔单词，用换行分隔字段，“header+body”等，报文里的各个组成部分都没有做严格的语法语义限制，可以由开发者任意定制。
- 发展过程中，HTTP 协议逐渐增加了请求方法、版本号、状态码、头字段等特性。而 body 也不再限于文本形式的 TXT 或 HTML，而是能够传输图片、音频视频等任意数据。
- 而那些 RFC 文档，实际上也可以理解为是对已有扩展的“承认和标准化”，实现了“从实践中来，到实践中去”的良性循环。
应用层协议：应用广泛、环境成熟 - 优点
- 只要不太苛求性能，HTTP 几乎可以传递一切东西，满足各种需求，称得上是一个“万能”的协议。
- “应用广泛”，软硬件环境都非常成熟。
可靠传输
- HTTP 协议是一个“可靠”的传输协议，因为 HTTP 协议是基于 TCP/IP 的，而 TCP 本身是一个“可靠”的传输协议，所以 HTTP 自然也就继承了这个特性
- 可靠”只是向使用者提供了一个“承诺”，会在下层用多种手段“尽量”保证数据的完整送达，不保证一定成功。
请求 - 应答
- HTTP 协议使用的是请求 - 应答通信模式。
- 契合了传统的 C/S（Client/Server）系统架构，请求方作为客户端、应答方作为服务器
- 完全符合 RPC（Remote Procedure Call）的工作模式，可以把 HTTP 请求处理封装成远程函数调用，导致了 WebService、RESTful 和 gRPC 等的出现。
无状态 - 双刃剑
- HTTP 协议是无状态的
- 在整个协议里没有规定任何的“状态”，客户端和服务器永远是处在一种“无知”的状态。建立连接前两者互不知情，每次收发的报文也都是互相独立的，没有任何的联系。收发报文也不会对客户端或服务器产生任何影响，连接后也不会要求保存任何信息。
- HTTP 是有连接无状态，顺序发包顺序收包，按照收发的顺序管理报文。
好处：
-
- 不需要额外的资源来记录状态信息，不仅实现上会简单一些，而且还能减轻服务器的负担
- “无状态”也表示服务器都是相同的，没有“状态”的差异，所以可以很容易地组成集群，让负载均衡把请求转发到任意一台服务器，不会因为状态不一致导致处理出错，使用“堆机器”的“笨办法”轻松实现高并发高可用。
坏处：
-
- 无法支持需要连续多个步骤的“事务”操作。
- “无状态”服务器是不知道某些请求是相互关联的，每次都得问一遍身份信息，不仅麻烦，而且还增加了不必要的数据传输量。
明文 - 双刃剑
- 协议里的报文（准确地说是 header 部分）不使用二进制数据，而是用简单可阅读的文本形式。
优点：
-
- 不需要借助任何外部工具，用浏览器、Wireshark 或者 tcpdump 抓包后，直接用肉眼就可以很容易地查看或者修改，为我们的开发调试工作带来极大的便利。
缺点：
- 信息容易被窃取
- ASCII 码, 一个字节表示一个字母, 所有 HTTP 报文会比较大 而那些二进制协议, 可以利用一个字节的 8 个比特表示更多信息, 这些信息通常是协议规定, 所以需要对应程序进行解析
不安全 - 缺点
-
明文只是“机密”方面的一个缺点，在“身份认证”和“完整性校验”这两方面 HTTP 也是欠缺的。
性能
- “不算差，不够好”。
- HTTP 协议基于 TCP/IP，并且使用了“请求 - 应答”的通信模式，所以性能的关键就在这两点上。
- 现在互联网的特点是移动和高并发，不能保证稳定的连接质量，所以在 TCP 层面上 HTTP 协议有时候就会表现的不够好。
- “请求 - 应答”模式则加剧了 HTTP 的性能问题，这就是著名的“队头阻塞”（Head-of-line blocking），当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一并被阻塞，会导致客户端迟迟收不到数据。
