关于软件设计的两三事：为什么Web世界不能没有HTTP？

前言

当你打开浏览器在地址栏中输入一个URL地址时，不知道会不会注意到这样一个事情：所有的URL地址前面都会有这样一个前缀——https:///http://。

这个前缀看起来相当得不起眼，甚至市面上绝大部分的浏览器都会自动将其隐藏起来。但就是这么一个毫不起眼的前缀，在过去的几十年中，构筑了整个互联网的数据传输规则，支撑起了整个Web生态的繁荣。

哈喽，我是闲宇，今天我们就来具体聊一聊：为什么Web世界不能没有HTTP？

HTTP的诞生

让我们将时间拨回到那个HTTP还没有诞生的年代。彼时的互联网已经发展了快二十年的时间，而在这段时间当中诞生了许多成熟且优秀的应用层协议，比如FTP、比如SMTP，但这些协议都有着相当严重的局限性。

首先，来看一下互联网最古老的文件传输协议FTP。FTP协议诞生的目的是为了进行文件管理，而非进行信息的浏览。这也就导致了在FTP的设计哲学中文件访问的过程需要执行非常严密且繁琐的登录认证、切换目录、列出文件等一系列命令操作。这些繁琐的操作对于非计算机科班出身、甚至是某些科班出身的用户来说，都是极其以及非常不友好的。我就只想简简单单地看个图，你却非要把前戏拉这么长，这合理吗？这一定是不合理的。除此以外，由于没有检索和跳转功能，这就导致了文件和文件之间处于一种相互独立的状态。当你费了九牛二虎之力进入到某个文件夹之后，却发现你要的一部分信息在另一个文件时，你唯一能做的就是重新切换目录，然后将原先做过的操作重新再做一遍。（这里可以放一个及其崩溃的图）是不是感觉非常的崩溃、非常的繁琐。

接着，我们来看一下著名的邮件传输协议SMTP。从名称上我们就能看出来，设计这个协议的目的是为了进行电子邮件的传输。无论是日常生活中，还是互联网中，邮件的传输都是点对点的通信，并且是一种被动的通信。如果你想查看一个文件就必须得等别人先用邮件发给你，你才能看得到，你自己想看？不好意思，没门。同样的，SMTP协议也是不支持文件互联的，要是你想要的信息没有发给你怎么办？等着，等我下次再发给你。

可以看到，当时的这些协议都是将互联网当做了文件仓库或者是通信管道，它们并没有站在一个普通用户的角度来思考这样一个问题：如何用更简单、并且可交互的方式来传播信息？

这个时候，蒂姆站了出来（这里放库克的照片），哦不，是这个蒂姆（这里放真实的提姆的照片），他站了出来，他说：“我要把互联网变成一个互联的知识网络，让大家能够更方便、更轻松地获得想要的所有信息。”于是，抱着这样一个愿景，HTTP协议诞生了。

HTTP的运行机制

为了解决那些前辈协议中存在的种种缺陷，蒂姆为HTTP协议做出了更简约、更高效的设计。下面，就是HTTP协议中最核心的四种特性：

无状态

在HTTP协议中，服务器和客户端之间的通信不再是有状态的，服务器不需要再通过维持会话的方式来保存请求的上下文。简单来说就是，服务端不再关心发过来的请求是否来自于同一个用户，当前的请求和上一个请求是否存在任何关联，它们只需要处理接收到的请求就好了。这种设计方式极大程度上减轻了服务器的压力，同时也让服务器的架构变得更为扁平，更易于在水平方向进行扩展；

请求-响应模型

是一种由客户端主动发起请求，服务端在同一个连接中返回响应的交互模型。这里的主动请求模型看起来和FTP协议的请求方式非常相似，但其实内部的实现细节却有着非常大的不同。关键就在于HTTP协议（HTTP/1.1以后）使用的是单连接复用，而FTP协议使用的是多连接切换，需要始终保持一个连接用于维持登录状态和命令传输。

基于HTML文本

基于HTML的内容传输，让内容和内容之间不再独立，而是可以通过链接的方式相互跳转，极大地降低了内容切换的难度，让整个互联网真正意义上形成了一个网状的知识库；

基于头部机制，灵活可扩展

借助Header+Body的报文结构，HTTP协议实现了客户端和服务端基于Header头进行内容处理的工作机制。它并没有直接提供一套完整不可变的Header，而是给了一个宽松、可变的Header，借此将内容的协商和处理下放到了开发者手中，让开发者可以根据不同的业务场景自行对Header进行添加和改造。

基于以上的这些设计，蒂姆实现了让更多的普通用户能够低门槛甚至无门槛地实现信息的获取和浏览，并且通过HTML以及链接的方式让互联网上的所有的信息组成了一个网状的知识库，让信息不再是平面独立的，而是相互关联，并且可以相关跳转的。

当然，随着时代的进步，HTTP协议也进化出了更多的特性和能力，这里就不再过多赘述。不过，可以确定的是，如果没有HTTP协议，互联网是绝对无法发展成为今天这样一个繁荣的景象的。