超文本传输协议（Hypertext Transfer Protocol，HTTP）是一个简单的请求-响应协议，它通常运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。请求和响应消息的头以ASCII形式给出；而消息内容则具有一个类似MIME的格式。超文本传输协议是一种用于分布式、协作式和超媒体信息系统的应用层协议，是万维网WWW（World Wide Web）的数据通信的基础。

万维网WWW发源于欧洲日内瓦量子物理实验室CERN，正是WWW技术的出现使得因特网得以超乎想象的速度迅猛发展。这项基于TCP/IP的技术在短短的十年时间内迅速成为已经发展了几十年的Internet上的规模最大的信息系统，它的成功归结于它的简单、实用。在WWW的背后有一系列的协议和标准支持它完成如此宏大的工作，这就是Web协议族，其中就包括HTTP超文本传输协议。

在1990年，HTTP就成为WWW的支撑协议。当时由其创始人WWW之父蒂姆·伯纳斯·李（Tim Berners-Lee）提出，随后WWW联盟（WWW Consortium）成立，组织了IETF（Internet Engineering Task Force）小组进一步完善和发布HTTP。

HTTP是应用层协议，同其他应用层协议一样，是为了实现某一类具体应用的协议，并由某一运行在用户空间的应用程序来实现其功能。HTTP是一种协议规范，这种规范记录在文档上，为真正通过HTTP进行通信的HTTP的实现程序。

HTTP是基于B/S架构进行通信的，而HTTP的服务器端实现程序有httpd、nginx等，其客户端的实现程序主要是Web浏览器，例如Firefox、Internet Explorer、Google Chrome、Safari、Opera等，此外，客户端的命令行工具还有elink、curl等。Web服务是基于TCP的，因此为了能够随时响应客户端的请求，Web服务器需要监听在80/TCP端口。这样客户端浏览器和Web服务器之间就可以通过HTTP进行通信了。

1991年，第一个有文档记载的HTTP正式版本被写成了一个普通文档，长度不到700字，这个版本被命名为HTTP/0.9。0.9协议是适用于各种数据信息的简洁快速协议，但是远不能满足日益发展的各种应用的需要。0.9协议就是一个交换信息的无序协议，仅仅限于文字。由于无法进行内容的协商，在双发的握手和协议中，并没有规定双发的内容是什么，也就是图片是无法显示和处理的。

到了1.0协议阶段，也就是在1992年，Tim Berners-Lee编写了一份新的文件，以具体说明基本议定书向下一个完整版本的演变。它支持0.9版本的简单请求方法和包含客户端HTTP版本的完整GET请求。1996年5月，RFC 1945作为HTTP/1.0的最终修订版发布，该修订版在过去4年中一直作为标准HTTP/1.0草案使用，已经被许多Web浏览器和Web服务器使用。在此后的不断丰富和发展中，HTTP/1.0成为最重要的面向事务的应用层协议。该协议对每一次请求/响应建立并拆除一次连接。其特点是简单、易于管理，所以它符合了大家的需要，得到了广泛的应用。

关于HTTP1.0协议的具体内容可以参考RFC 1945。

在1.0协议中，双方规定了连接方式和连接类型，这已经极大扩展了HTTP的领域，但对于互联网最重要的速度和效率，并没有太多的考虑。毕竟，作为协议的制定者，当时也没有想到HTTP会有那么快的普及速度。

关于HTTP1.1协议的具体内容可以参考RFC 2616。

HTTP2.0的前身是HTTP1.0和HTTP1.1。虽然之前仅仅只有两个版本，但这两个版本所包含的协议规范十分庞大。网络协议新版本并不会马上取代旧版本。实际上，HTTP 1.0和HTTP1.1在之后很长的一段时间内一直并存，这是由于网络基础设施更新缓慢所决定的。

关于HTTP2.0协议的具体内容可以参考RFC 7540。

HTTP3.0是超文本传输协议的第三个主要版本，用于在万维网上交换信息，补充了广泛部署的HTTP1.1和HTTP2.0。与之前依赖于成熟的TCP的版本不同，HTTP3.0使用QUIC，一种基于UDP的多路传输协议。HTTP3.0具有更低的延迟和更快的加载速度。

关于HTTP3.0协议的具体内容可以参考RFC 9114。

HTTP诞生之初主要是应用于WEB端内容获取，那时候内容还不像现在这样丰富，排版也没那么精美，用户交互的场景几乎没有。对于这种简单的获取网页内容的场景，HTTP表现得还算不错。但随着互联网的发展和WEB2.0的诞生，更多的内容开始被展示（更多的图片文件），排版变得更精美（更多的CSS），更复杂的交互也被引入（更多的JS）。用户打开一个网站首页所加载的数据总量和请求的个数也在不断增加。

今天绝大部分的门户网站首页大小都会超过2M，请求数量可以多达100个。另一个广泛的应用是在移动互联网的客户端app，不同性质的app对HTTP的使用差异很大。对于电商类app，加载首页的请求也可能多达10多个。对于微信这类IM，HTTP请求可能仅限于语音和图片文件的下载，请求出现的频率并不算高。

HTTP是基于客户/服务器模式，且面向连接的。典型的HTTP事务处理有如下的过程：

（1）客户与服务器建立连接；

（2）客户向服务器提出请求；

（3）服务器接受请求，并根据请求返回相应的文件作为应答；

（4）客户与服务器关闭连接。

客户与服务器之间的HTTP连接是一种一次性连接，它限制每次连接只处理一个请求，当服务器返回本次请求的应答后便立即关闭连接，下次请求再重新建立连接。这种一次性连接主要考虑到WWW服务器面向的是Internet中成千上万个用户，且只能提供有限个连接，故服务器不会让一个连接处于等待状态，及时地释放连接可以大大提高服务器的执行效率。

HTTP是一种无状态协议，即服务器不保留与客户交易时的任何状态。这就大大减轻了服务器记忆负担，从而保持较快的响应速度。HTTP是一种面向对象的协议。允许传送任意类型的数据对象。它通过数据类型和长度来标识所传送的数据内容和大小，并允许对数据进行压缩传送。当用户在一个HTML文档中定义了一个超文本链后，浏览器将通过TCP/IP协议与指定的服务器建立连接。

HTTP支持持久连接，在HTTP / 0.9和1.0中，连接在单个请求/响应对之后关闭。在HTTP / 1.1中，引入了保持活动机制，其中连接可以重用于多个请求。这样的持久性连接可以明显减少请求延迟，因为在发送第一个请求之后，客户端不需要重新协商TCP 3-Way-Handshake连接。另一个积极的副作用是，通常，由于TCP的缓慢启动机制，连接随着时间的推移而变得更快。

该协议的1.1版还对HTTP / 1.0进行了带宽优化改进。例如，HTTP / 1.1引入了分块传输编码，以允许流传输而不是缓冲持久连接上的内容。HTTP流水线进一步减少了延迟时间，允许客户端在等待每个响应之前发送多个请求。协议的另一项附加功能是字节服务，即服务器仅传输客户端明确请求的资源部分。

从技术上讲是客户在一个特定的TCP端口（端口号一般为80）上打开一个套接字。如果服务器一直在这个周知的端口上倾听连接，则该连接便会建立起来。然后客户通过该连接发送一个包含请求方法的请求块。

HTTP规范定义了9种请求方法，每种请求方法规定了客户和服务器之间不同的信息交换方式，常用的请求方法是GET和POST。服务器将根据客户请求完成相应操作，并以应答块形式返回给客户，最后关闭连接。

在WWW中，“客户”与“服务器”是一个相对的概念，只存在于一个特定的连接期间，即在某个连接中的客户在另一个连接中可能作为服务器。基于HTTP的客户/服务器模式的信息交换过程，它分四个过程：建立连接、发送请求信息、发送响应信息、关闭连接。

HTTP是基于请求/响应范式的。一个客户机与服务器建立连接后，发送一个请求给服务器，请求方式的格式为，统一资源标识符、协议版本号，后边是MIME信息包括请求修饰符、客户机信息和可能的内容。服务器接到请求后，给予相应的响应信息，其格式为一个状态行包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。其实简单说就是任何服务器除了包括HTML文件以外，还有一个HTTP驻留程序，用于响应用户请求。你的浏览器是HTTP客户，向服务器发送请求，当浏览器中输入了一个开始文件或点击了一个超级链接时，浏览器就向服务器发送了HTTP请求，此请求被送往由IP地址指定的URL。驻留程序接收到请求，在进行必要的操作后回送所要求的文件。在这一过程中，在网络上发送和接收的数据已经被分成一个或多个数据包（packet），每个数据包包括：要传送的数据；控制信息，即告诉网络怎样处理数据包。TCP/IP决定了每个数据包的格式。如果事先不告诉你，你可能不会知道信息被分成用于传输和再重新组合起来的许多小块。

许多HTTP通讯是由一个用户代理初始化的并且包括一个申请在源服务器上资源的请求。最简单的情况可能是在用户代理（UA）和源服务器（O）之间通过一个单独的连接来完成。

当一个或多个中介出现在请求/响应链中时，情况就变得复杂一些。中介有三种：代理（Proxy）、网关（Gateway）和通道（Tunnel）。一个代理根据URI的绝对格式来接受请求，重写全部或部分消息，通过URI的标识把已格式化过的请求发送到服务器。网关是一个接收代理，作为一些其它服务器的上层，并且如果必须的话，可以把请求翻译给下层的服务器协议。一个通道作为不改变消息的两个连接之间的中继点。当通讯需要通过一个中介（例如：防火墙等）或者是中介不能识别消息的内容时，通道经常被使用。

HTTP报文由从客户机到服务器的请求和从服务器到客户机的响应构成。请求报文格式如下：

请求行 － 通用信息头 － 请求头 － 实体头 － 报文主体

请求行以方法字段开始，后面分别是URL字段和HTTP协议版本字段，并以CRLF结尾。SP是分隔符。除了在最后的CRLF序列中CF和LF是必需的之外，其他都可以不要。有关通用信息头，请求头和实体头方面的具体内容可以参照相关文件。

应答报文格式如下：

状态行 － 通用信息头 － 响应头 － 实体头 － 报文主体

状态码元由3位数字组成，表示请求是否被理解或被满足。原因分析是对原文的状态码作简短的描述，状态码用来支持自动操作，而原因分析用来供用户使用。客户机无需用来检查或显示语法。有关通用信息头，响应头和实体头方面的具体内容可以参照相关文件。

HTTP请求和响应消息包括HTTP版本号，关于HTTP版本号的正确使用和解释以及关于不同协议转换的HTTP实现的互操作性存在一些混淆。使用和解释HTTP版本号可以参考RFC 2145。