本文为《三万长文50+趣图带你领悟web编程的内功心法》第二个章节。
2、初识HTTP/1.1
接下来我们先来简单介绍下HTTP/1.1的优缺点，好让大家对它有个认识，然后再进一步深入了解。
2.1、可扩展
正是因为HTTP规范中限制很少，告诉你可以做什么，但是不会告诉你各种条条框框不能做什么，所以，很容易扩展，这也是为什么从HTTP/0.9诞生，一直扩展升级，添加更多的特性的原因。
image-20200825221924888
2.2、传输可靠性
由于底层是基于TCP协议的，所以继承了TCP传输数据的可靠性，主要体现在[1]：
- 数据的顺序传输；
- 丢包重传，保证可靠；
- 连接维护；
- 流量控制，保证稳定；
- 拥塞控制，及时调整，最大程度保证传输正常进行。
2.3、基于请求应答模式
只有一方先主动发起连接和请求之后，接收方才可以进行响应。HTTP正是基于这种一问一答的请求应答模式。如果客户端不请求，服务端就不会搭理客户端。
虽然后面HTTP/2出现了服务端推送[2]，但是也是针对特定资源的推送，并不是服务端想推送什么就推送什么。
2.4、无状态
有状态意味着一定会通过某种状态标识为去追踪状态，就像TCP的状态机，TCP请求头有特定的状态标识位来维护连接的状态。
HTTP并没有提供记录状态的地方，也就是说在交互性场景中，HTTP没有记忆能力。这就会导致这样的问题：
- 同一个用户多次访问一个网站，都需要重复读做身份验证。
即使开启了keep-alive机制，也只是TCP层面的维持连接，对于HTTP层来说，看起来还是无状态的。
我们不能每次都要让用户输入账号密码进行身份验证吧，为此才会出现Cookie和Session，为HTTP弥补了状态存储的问题。
2.5、明文传输，不安全
我们通过抓包工具抓HTTP/1.1的包，通过肉眼都可以看到请求头和请求体里面的内容，那么用户登录请求的时候，传输的账号密码以下子就可以捕获到了。
我们知道，数据在网络中请求的链路是很漫长的，只要任何一个环节抓到了你的包，你的数据就泄露了。这也是为什么要推出HTTPS的原因。
2.6、性能较差(请求-应答)
由于使用请求应答机制，每次都需要传一大段请求头，效率比较差。
另外，HTTP/1.1基于请求-应答模式，在应用层存在队头阻塞问题，并且TCP层同样会存在TCP的队头阻塞问题，导致性能比较差，需要通过各种奇门妙招去优化网络请求。
效率问题正是促使HTTP/2、HTTP/3诞生的原因之一。
本文为arthinking基于相关技术资料和官方文档撰写而成，确保内容的准确性，如果你发现了有何错漏之处，烦请高抬贵手帮忙指正，万分感激。
如果您觉得读完本文有所收获的话，可以关注我的账号，或者点赞吧，码字不易，您的支持就是我写作的最大动力，再次感谢！
为了把相关系列文章收集起来，方便后续查阅，这里我创建了一个Github仓库，把发布的文章按照分类收集起来了，感兴趣的朋友可以Star跟进：
java-tech-stack-info
关注我的博客IT宅(itzhai.com)或者公众号Java架构杂谈，及时获取最新的文章。我将持续更新后端相关技术，涉及JVM、Java基础、架构设计、网络编程、数据结构、数据库、算法、并发编程、分布式系统等相关内容。
References
- 谢希仁. 计算机网络(第6版). 电子工业出版社.
- TCP/IP详解 卷1：协议（原书第2版）. 机械工业出版社.
- UNIX网络编程 卷1：套接字联网API. 人民邮电出版社
- HTTP权威指南. 人民邮电出版社
- HTTP/2基础教程. 人民邮电出版社
- 刘超. 趣谈网络协议. 极客时间
- 罗剑锋. 透视HTTP协议.极客时间
本文同步发表于我的博客IT宅(itzhai.com)和公众号(Java架构杂谈)
作者：arthinking | 公众号：Java架构杂谈
博客链接：https://www.itzhai.com/articles/getting-to-know-http-1-1.html
版权声明： 版权归作者所有，未经许可不得转载，侵权必究！联系作者请加公众号。
网友评论