互联网协议 — HTTP 协议与 Web 服务器

Posted 2023-03-13 范桂飓

目录

文章目录

• 目录
• Web 世界的诞生
• W3C（万维网联盟）
• HTTP 发展历程与 Apache 开源基金会
• REST 系统架构
• RESTful API 经济繁荣
• Web 应用程序系统架构

Web 世界的诞生

早古时期，计算机应用软件和网络通信技术是两个完全不同的领域，前者围绕着单机环境展开，而后者则研究系统之间的通信。后来随着 Internet 技术的兴起，使得这两个领域开始融合，首先被孵化出来的就是 HTTP 协议及其 Web 服务器，越来越多的人开始意识到，“网站” 即是 “软件”。

1989年，在瑞士日内瓦的 CERN（核子研究中心）工作的 Tim Berners-Lee（蒂姆·伯纳斯·李）在论文中提出了一种可以在 Internet 上构建超链接文档的技术，并提出了 3 点基本要素：

1. URI（Uniform Resource Identifier，统一资源标识符）：Internel 中的统一资源标识符，用于唯一标识一个 Internet 上的资源。
2. HTML（Hyper Text Markup Language，超文本标记语言）：使用 html 标签来构建超文本文档，HTML 标签将文字，图形、动画、声音、表格、链接等内容格式进行了统一。
3. HTTP（Hyper Text Transfer Protocol，超文本传输协议）：最初设计来用于传输 HTML 的协议，处于 TCP/IP 应用层，传输的数据主体称为 Message（消息），基于 TCP 传输协议。

Tim Berners-Lee 所定义的 Resource，指的是 Internet 上的一个实体，它可以是一段文本、一张图片、一首歌曲、一种服务等。URI 就是在 Internet 中标识一个 Resource 的唯一 ID，包含了 URL 和 URN 这 2 种形式。

• URL（Uniform Resource Loader，统一资源定位符）：侧重于 “定位”，类似一个地址，XX省XX市XX区XX单元XX室。
• URN（Uniform Resource Name，统一资源名称）：侧重于 “命名”，类似身份证号。

由于 URL 更具有空间层次设计，所以如今已经成为了主流，但开发者仍应该清晰区分两者。

W3C（万维网联盟）

1990 年 12 月 25 日，Tim Berners-Lee 和罗伯特·卡里奥一起成功通过 Internet 实现了 HTTP Client 与 Server 的第一次通讯。HTTP 服务器，又称为 Web 服务器，是 HTTP 协议的一种软件实现。

1991 年 8 月 6 日，Tim Berners-Lee 基于 HTTP 和 HTML 设计并开发了第一个网页浏览器，并发布了世界上第一个 Web 网站。它被称为 The First Website（第一个网站）或 InfoMesh（信息管理系统项目），运行在 CERN 的服务器上，旨在帮助研究人员共享信息和文献。基于 HTML，该网站可以提供一些链接，让用户通过单击超链接跳转到其他页面或文档，这种超链接的设计 Web 技术最重要的创新之一。

同年，Tim Berners-Lee 正式提出了 WWW（World Wide Web，万维网）的概念。并且由于 Internet 的飞速发展，1992 年几个 Internet 组织合并成立统一的 ISOC（因特网协会），此时的 Internet 已经注册了超过 100 万台主机，并持续指数级疯狂增长。

1994 年 10 月 1 日，Tim Berners-Lee 创建了非营利性的 W3C（World Wide Web Consortium，万维网联盟），邀集 Microsoft、 Netscape、 Sun、Apple、IBM 等共 155 家互联网上的著名公司。由 Tim Berners-Lee 担任 W3C 的主席，致力推动 WWW 协议的标准化，并进一步推动 Web 技术的发展。

在当时的浏览器热潮下，Tim Berners-Lee 也曾考虑过成立一家叫做 Websoft 的公司做网页浏览器。但很快他就放弃了，他担心这么做会导致激烈的市场竞争，开发出技术上互不兼容的浏览器、最终把 WWW 割裂成一个个利益集团。

• Tim Berners-Lee，万维网之父
  

HTTP 发展历程与 Apache 开源基金会

最初，由于那时候网络资源匮乏，HTTP/0.9 版本相对简单，采用纯文本格式，且设置为只读，所以当时整个 HTTP Request Message 只有一行，比如：GET www.leautolink.com。只能使用 GET 的方式从 Web 服务器获得 HTML 文档，响应以后则关闭。响应中也只包含了文档本身，无响应头，无错误码，无状态码。

1995 年，由 Brian Behlendorf 发布了基于 HTTP/0.9 的 Apache HTTP Server 开源项目。同年，网景和微软开启浏览器大战，但好在 Tim Berners-Lee 担心的 “撕裂“ 并未发生，HTTP 协议已经逐成气候。

随着 Apache HTTP Server 的诞生，以及同时期其他的多媒体等技术发展迅速，都进一步的促使 HTTP 协议的演进。紧跟着 1996 年，HTTP/1.0 发布，更好的支持采用图文网页形式。具体而言增加了以下几个特性：

1. 增加 HTTP Header 格式。
2. 增加协议版本号。
3. 增加 POST 方法。
4. 增加 HEAD 方法。
5. 增加文件处理类型。
6. 增加响应状态码。
7. 提供国际化支持。

经过几年的发展，1999 年，HTTP/1.1 发布并成为标准，写入 RFC。至此，HTTP 协议已然成为了 Web 世界的奠基石。

1. 增加 PUT 等方法。
2. 增加缓存处理机制：在 Header 增加了如：Entity tag，If-Unmodified-Since，If-Match，If-None-Match 等可供选择的 Request Body 来控制缓存策略。
3. 增加带宽优化机制：在 Header 增加了 Range 字段，它允许只请求资源的某个部分，而不是一揽子返回，得以更充分的利用带宽和网络连接。
4. 增加错误通知的管理：新增了 24 个错误状态响应码。
5. 增加 Host 虚拟主机：支持 HTTP Server 虚拟主机技术。可以在一台物理服务器上存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个 IP 地址，通过不同 Hostname 区分。
6. 增加长连接机制：默认使用长连接，应对日益复杂的网页（网页内的图片、脚本越来越多了）。
7. 等等。

随着 HTTP/1.1 被纳入 RFC 标准，同在 1992 年，由 HTTP/1.0 和 1.1 的主要设计者 Roy Thomas Fielding 宣布成立了 Apache 软件基金会，并作为 Apache 基金会的第一任主席，从此，Apache Web Server 和 HTTP 协议携手共生共荣。

除了 HTTP 协议，Apache 软件基金会旨在促进各种开源软件项目的开发和使用，其中 Apache HTTP Server 作为首个核心项目。这为 Apache HTTP Server 的长期发展奠定了良好的基础，同时也缔造了繁荣的开源生态系统，孵化了包括：Tomcat、Hadoop、Lucene、OpenOffice 等开源项目。

至今而至，Apache 软件基金会已成为了全球最大的开源组织之一。

REST 系统架构

2000 年，Apache 基金会的第一任主席 Roy Thomas Fielding 在博士论文《Architectural Styles and the Design of Network-based Software Architectures（架构风格和基于网络的软件架构设计）》中提出了 REST（Representational State Transfer，表现层状态转移）的理念。

顾名思义，Roy Thomas Fielding 在这篇论文中主要讨论的是：如何在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。

可见，REST、HTTP 协议、Web 服务器，这 3 者之间天生关系紧密。所以，开发者要清晰理解 Representational State Transfer 含义，应该先 HTTP 协议有一个清晰的认识。

通过拆词法，尝试对 Representational State Transfer 的含义进行以下解构：

1. Representational（表现层）：即 Resources 的表现层。上述我们知道 Resource 是一种抽象，它具有多种表现形式，而最终把 Resource 具体呈现出来的形式，就叫做它的 “表现层”。例如：一个文本资源可以使用 TEXT 格式表现，也可以使用 HTML、XML、JSON 等格式表现。在 HTTP/1.0 中，Roy Thomas Fielding 为 HTTP Header 设计了 Accept/Content-Type 字段来描述这个 Resource 的 Representational。

所以，需要注意的是：URI 仅用于标识一个 Resource，而不应该在 URI 中描述表现层的内容，一个优雅的 RESTful API 应该使用 Accept/Content-Type 字段来描述 Resource 的表现层。

Accept: Application/json
Content-Type: Application/json

2. State Transfer（状态转移）：Resource 作为 C/S 交互的实体，必然存在着状态的变化，然而 HTTP 是一种 Stateless（无状态）的协议（不传输资源状态的描述）。这意味着：Resource 的状态都保存在 Server，而 Client 想要操作某个 Resource（改变其状态）就必须通过某种手段让 Resource 在 Server 上发生状态的 “转移”，而且这种 “转移” 必然是建立在 Resource 的 “表现层” 之上的，例如：创建一个图片资源、删除一个图片资源；启动一个服务，关闭一个服务。故称之为 “表现层状态转移”。

Client 可以使用的手段就是 Roy Thomas Fielding 在 HTTP 请求行中设计的 Request Methods（HTTP/0.9 引入 GET，HTTP/1.0 引入 POST、HEAD，HTTP/1.1 引入 PUT 等）。

# Client
GET /resource
Accept: text/html

# Server
Content-Type: text/html;charset=utf-8
Response code: 200

至此，我们回头再看，REST 讨论的其实是一个：如何将软件和网络两个领域进行交叉融合，继而得到一个功能强、性能好、适宜通信的互联网软件架构的问题。

RESTful API 经济繁荣

RESTful API 就是符合 REST 架构设计思想的软件 API 风格，其中 *-ful 在西文语境中常用于表示一种风格。

笔者最早认识到 RESTful API，源于时任 AWS CTO 的一封内部邮件，那时是 2006 年，正值 AWS 孵化的初期，印象非常深刻的有两点：

1. 强调 AWS 必须是一种 Resilient software architecture（具有韧性/弹性的软件架构）。
2. 不使用 RESTful API 的员工将被辞退。

直到 2013 年笔者接触 OpenStack（OpenStack 初期常被认为是 AWS 的开源对标版本）之后才更深刻的体会到了其内涵和精髓。大型分布式软件的各个组件之间必须具备解耦和扩展的能力，网络（Network-base）是组件之间通信的唯一依赖，且对资源的操作具有唯一的确定性。

我们可以选取一个角度来比较一下 RESTful 与另外两种常见的分布式架构风格的区别：

• RESTful 抽象的是资源，资源的抽象不需要依赖开发平台或编程语言，客户端和服务端完全松耦合。
• DO（Distributed Objects，分布式对象）抽象的是对象，而不同的编程语言对对象的定义有很大差别，所以 DO 架构通常会与某种编程语言（.NET）绑定，若跨语言交互，实现则会非常复杂。架构实例有 RMI、EJB/DCOM、.NET Remoting 等。
• RPC（Remote Procedure Call，远程过程调用）抽象的是过程，这要求客户端和服务端具有很强的耦合度，否者双方无法理解对方的意图。所以 RESTful 只需要以名词为核心的，而 RPC 则需要以动词为核心。架构实例有 SOAP、XML-RPC、Flash AMF 等。

AWS 奉行的这一铁律，使其得以在几年间飞速扩展至上百个核心组件，成为了极具韧性和良好生态的公有云架构。现在的软件公司基本都会采用 RESTful API 风格，让产品可以通过 API 的方式融入到行业生态中，形成 APIs 经济效益。

Web 应用程序系统架构

时至今天，一个典型的 Web 应用程序系统架构应该包括以下 4 个核心元素：

• Web Client：使用 Browser（浏览器）通过 Web site Domain name（网站域名）访问网络资源。

• Web Server：负责处理 HTTP 协议、提供 HTTP 虚拟主机、管理 TCP 连接、执行基本的安全性和身份验证检查、存储静态和动态 Web 内容等。

• Web Application：提供动态内容和交互性 Services（服务）。区别于静态 Web 内容，Application 从 Server 转接 Client Request，并提供 Request 的参数来动态生成内容。Web Application 通常使用 Web Framework 开发，例如：Java SSH、Python Django 等，通常提供了以下定义：

  • Resources：服务资源。
  • Routers：请求路由器。
  • Handlers：请求处理器。
  • Controllers：资源表现层状态转移控制器。

• WSGI（Web Server Gateway Interface，Web 服务器网关接口）：本质是一种规范，作为 Web Server 和 Web Application 的交互接口，用于实现 Web Server + Web Middleware + Web Application 的三位一体。

以 Python 为例，它通过 wsgi_mod 和 Apache HTTP Server 进行交互。让 Server 知道如何将 Client Request 传递给 Application。也让 Application 能理解 Client Request 并执行对应操作，最后将执行结果返回给 Server 再响应到 Client。