HTTP学习

分布式计算的第一准则——不要分布你的对象

减少访问远程服务所花费的时间，比如可以通过更粗粒度地划分接口。远程还是本地是明确的设计决策，不能随意来回更动，这一点应当牢记。还要考虑分布式计算的第一准则——不要分布你的对象。

软件开发人员总爱在不需要的地方引入抽象和层。是的，这些概念对软件组件之间的解耦来说是很好的工具，但它们可能会增加复杂性、影响性能，尤其是在每层的数据表示之间都需要转换的情况下。因此，减少处理时间还要注意保证抽象不要过于抽象化，并且没有过多的分层。另外，对于我们视为理所当然的运行时服务，有必要理解其成本，因为除非它们提供了特定的服务水平协议，否则很有可能最终会成为应用中的瓶颈。

分布式必然带来复杂性的上升, 网络是不可靠的. 跨越网络带来的复杂性如果不能通过分层协议在网络两端取得同步和一致的结果, 对于应用就会造成数据不一致的后果.

现状:
HTTP作为最通用的应用层协议, 承担了互联网上多数的数据传输任务.

image.png

image.png

image.png

TCP/IP和OSI模型相比, 精简掉了会话和表示层, 把这些功能合并在应用层处理. 虽然简化了网络的设计和实现, 却给上层的应用带来了更多的维护负担.

最好把数据协议和传输协议分开, 虽然现在HTTP是Web标准, 但是面向未来, 最好不要捆绑在特定的传输协议上, 只做好Web可用的数据访问接口, 底层使用websocket, 或者HTTP2, HTTP3, 或者别的什么协议都可以. 这个问题其实是由于TCP/IP协议简化的应用层造成的, OSI模型中的会话层和表示层是有必要的, 而且并不需要特殊硬件, 应该是在软件中分层. 把所有功能都简化到应用层的后果就是HTTP承担了太多角色, 没有一个清晰的层次, 导致了Web开发需要后端写很多难以复用的接口. 所以REST和GraphQL都在填这个坑, 我觉得最根本的方式还是重视OSI模型, 在软件架构中分离出会话和表示层, 建立起通用规范的实现和接口调用方式, 这样不仅对于Web, 对于更底层直接基于socket的调用都是大有好处的, 现在的情况下是这些功能分布于通讯框架和业务代码中, 没有一个清晰的结构, 增加了复杂性. 当然, 这是从长远和理想角度考虑, 目前HTTP接口还是够用的, 前端通过对应的客户端库转接相应格式的接口, 后续切换应该也问题不大.

Web技术出现的较晚(约1990年), 而市场对于互联网应用的需求却很强烈, 导致Web在底层技术还没有准备好的情况下就要开始承担复杂的业务场景. 这是网络应用开发中的根本问题.

近些年Web标准作了一些升级和调整, 诸如HTML5, CSS3, ES6之类的标准, 为web应用提供了更多的可能, 但是作为传输主力的HTTP却调整缓慢.
HTTP/0.9 1990
HTTPS 1994
HTTP1.0 1996
HTTP1.1 1997
|
|
WebSocket 2011
SPDY 2012
HTTP/2 2015

HTTP为了实现的简单, 处于当时网络的实际情况和应用场景, 采取了一问一答, 无状态的纯文本格式传输模式. 相当于在不关心会话层实现, 表示层采用text/html或text/plain这样的简单文本格式. 在当时传输简单图文的场景下是够用且合适的, 但是当需求和应用越来越复杂, 简单的文本和html格式无法承担. 当时的W3C委员会制定的标准是XML, 建立一套基于XML的体系, 希望以此统一Web数据的承载格式. 但是之后业界更倾向于轻量级的JSON格式.