计算机网络——HTTP协议

1. HTTP的概述

        HTTP（超文本传输协议），定义在RFC2616中，是用于分布式和协作式多媒体系统之间交互的应用层通信协议。

1.1 无状态

        HTTP是一个无状态协议，意味着它不保存先前交互的记录。每个请求都独立于其他请求处理。

1.2 分布式和协作式多媒体系统间的交互

        HTTP旨在促进客户端和服务器在分布式系统中的互动，包括传输多媒体数据和在线协作。

1.3 HTTP的客户端/服务器模型

        客户端（通常是网络浏览器）向服务器（托管网站或应用程序的服务器）发送请求。然后服务器处理这个请求，并向客户端发送回应。

1.4 请求-响应连接

        客户端和服务器之间建立连接，以传输请求和响应。这可能是持久连接（为多个请求-响应保持开放）或非持久连接（每对请求-响应新建连接）。

1.5 HTTP消息：HTTP通信以消息的形式进行

        主要有两种类型的HTTP消息：请求和响应。

        请求通常由客户端发出，用于请求服务器上的特定资源，而响应则由服务器返回，以提供所请求的资源。

1.6 可靠的传输或会话协议

        HTTP依赖于可靠的传输协议，如TCP（传输控制协议），以确保传输的数据可靠。TCP确保数据按正确的顺序到达目的地，并且没有损坏。

1.7 GET请求

        大多数HTTP通信涉及到GET请求。GET请求用于请求服务器上特定资源的表示。例如，当您在浏览器中输入URL时，通常会向Web服务器发送一个GET请求，以获取相应的网页。

1.8 双向连接

        HTTP基于客户端-服务器通信模型，其中客户端发送请求到服务器，服务器则以响应方式回应。客户端和服务器之间的连接通常在通信期间保持打开，这允许双向交互，例如实时数据流传输。

        HTTP/1.1和之前的版本通常为每个请求/响应使用单独的TCP连接，这可能在某些情况下会导致延迟过高。

        HTTP/2和HTTP/3引入了改进，通过使用单个双向连接来处理多个请求和响应，以优化性能。

        总之，HTTP是Web的重要协议，允许Web浏览器可靠地向Web服务器请求资源，并提供保持双向连接以进行持续交互的能力。

2. HTTP协议的中介

        客户端、服务器和中介都可能具有缓存能力。图中展示了这些实体之间请求和响应的流程。

2.1 HTTP中介

        在HTTP通信中，“中介”（Intermédiaire）可以理解为在客户端和服务器之间传递信息的任何实体

        建立了一个连接链。

        HTTP的选项可以应用到最接近的中介上（隧道除外）。

        最终接收者。

        所有的中介。

        网络中的一个中介（比如代理、网关或隧道）可以介于客户端和服务器之间。

2.2 代理（Proxy）

        它像是一个中转站，客户端发送的请求会先到达代理，代理有可能会修改这个请求，然后再发送给真正的服务器。

2.3 网关（Passerelle）

        如果客户端和服务器之间的通信协议不同，网关会将客户端的请求翻译成服务器能理解的协议。

2.4 隧道（Tunnel）        

        隧道更像是一个直通管道，它不会修改经过的信息。当需要通过某些特殊的中介（比如防火墙）时，就会用到隧道。

2.5 缓存

        客户端、服务器和中介可能都设有缓存，以提高数据传输效率和减少延迟。

2.6 数据流

        客户端发送请求到服务器，以及服务器响应返回给客户端的过程，中间可能通过一个中介来完成数据传输。

        简单来说，这些描述指出在HTTP协议中，信息可以通过一个或多个中介（如代理服务器、网关等）来传递。每个中介都可以根据HTTP协议的选项进行操作，但是隧道类型的中介是个例外，它通常只是简单地传递信息而不做修改。最终，信息会到达最终的接收者，也就是目标服务器。在这个过程中，每个中介都可能会对信息流产生影响。

3. HTTP协议中的两种链接

3.1 非持久连接

        对于每个请求的URI（统一资源标识符），都会建立一个单独的连接。这种方式可能会导致服务器负载过重，互联网拥堵。在HTTP1.1之前的版本中，默认的连接是非持久的，有时候甚至不支持持久连接。

3.2 持久连接

        通过一次连接，可以发送多个请求并接收多个响应，不需要每次都重新建立连接。这减少了开启和关闭连接的频繁操作，提高了效率。

3.2.1 管道化（Pipeline）

        在HTTP1.1中，客户端可以同时发送多个请求，而不用等待对前一个请求的响应。服务器按照请求接收的顺序发送回响应。这进一步提高了传输效率。

3.2.2 持久性

        如果服务器关闭了连接，客户端应该准备好重新发起请求。这意味着客户端在连接被关闭时能够恢复通信，而不会丢失请求。

        简而言之，HTTP的持久连接和管道化技术都是为了让网页加载更快、更高效，减少因频繁建立连接造成的延迟和资源消耗。

4. HTTP消息结构——HTTP消息的基本组成部分

        两种类型的消息：请求（requête）和响应（réponse）

        消息结构：一个消息包含四个部分

4.1 起始行（start-line）

4.1.1 基本概念

        HTTP消息的第一行非常重要，因为它定义了消息是一个请求还是一个响应：

        对于请求来说，包括了方法（GET、POST等）、请求的URI和HTTP版本。

        对于响应来说，包括了HTTP版本、状态码和状态消息。

4.1.2 具体解释

        起始行（start-line）：这一行指定了消息的类型。它可以是请求行（Request-Line）或状态行（Status-Line）。

        如果是请求行，它会包含三个部分：

4.1.2.1 方法（Method）        

        这指的是HTTP请求的类型，例如GET（获取数据）、POST（发送数据）等。

        HTTP协议中不同方法的说明：

        GET：用于请求访问由URI（统一资源标识符）所标识的资源。

        HEAD：类似于GET方法，但是服务器在响应中只返回头部信息，不返回实际的资源内容。

        POST：用于向指定的资源提交数据，例如，提交表单或上传文件。数据包含在请求体中。

        PUT：用于上传指定的资源。如果URI指向的资源不存在，服务器可以创建这个资源。

        DELETE：请求服务器删除指定的URI所标识的资源。

        TRACE：回显服务器收到的请求，主要用于测试或诊断。

        CONNECT：将连接转换为透明的TCP/IP隧道，通常用于SSL加密服务器的连接（通过HTTP代理）。

        OPTIONS：用于描述通信选项的测试方法，用于了解服务器或其他网络组件的能力。

        这些方法定义了客户端与服务器之间交互的不同方式，使得HTTP协议能够支持多种不同的网络操作。

4.1.2.2 请求目标（request-target）

        通常是你要请求的网址，即统一资源标识符（URI）。

4.1.2.3 协议版本（HTTP-Version）

        表明使用的HTTP协议的版本，如HTTP/1.1。

        每部分之间通常用空格分开，并且以CRLF（回车换行）符号结束这一行。所以，如果是一个请求，起始行会告诉服务器你想要做什么（方法），你想在哪里做（请求目标），以及你打算使用哪个版本的HTTP协议来通信。

4.2.头部（message-header）

4.2.1 基本定义

        跟随起始行，包含了键值对形式的元数据，如内容类型、内容长度、缓存控制等。

        HTTP头部：它由一个名字和一个值组成，这些都是用ASCII码编码的。

        一个消息头的格式是这样的：field-name: field-value

        举例来说，Content-Type: text/html就是一个消息头，其中Content-Type是字段名，text/html是字段值。

4.2.2 头部类型

        HTTP头部可以是通用头部，也可以是请求或响应特有的头部，或者是与消息体中所含实体相关的头部。

4.2.2.1 通用头部（General header）

        是指那些请求和响应消息都可能使用的头部，比如`Date`或者`Cache-Control`

        通用头部：这些头部与整个消息有关，而不是仅与消息的内容（即消息体）有关。

        用途：通用头部用于控制消息的处理过程，这个处理过程可能涉及客户端、服务器或中间件。它们也可以提供一些额外的信息。

        特性：通用头部不特定于任何一个请求、响应或消息体中的实体。

        通用头部的例子包括：

        Cache-Control：指示缓存行为。

        Connection：指示是否持久连接。连接选项，不会通过代理传递。例如：`Connection: close`，表示关闭连接，不使用持久连接。

        Date：消息创建的日期和时间。消息生成的日期。示例为`Date: Tue, 15 Nov 1994 08:12:31 GMT`，表示消息是在1994年11月15日格林尼治时间上午8点12分31秒生成的。

        Transfer-Encoding：传输消息体时使用的编码类型。

        no-cache：指示缓存必须向服务器验证响应的有效性。

        no-store：指示请求或响应不能被缓存。

        这些头部用于控制HTTP消息如何被发送、接收和处理，它们对于管理网络连接和缓存行为非常重要。        

4.2.2.2 请求头部（Request header）

        是指那些只在请求消息中使用的头部，比如User-Agent或Accept。

        请求头部的一些例子：

        Accept：客户端能够接收的媒体类型。示例`Accept: audio/*; q=0.2, audio/basic`表示客户端优先接收基本的音频类型，但也可以接受其他类型的音频内容，尽管它们的优先级较低（q=0.2）。

        Accept-Charset：客户端支持的字符集。示例`Accept-Charset: iso-8859-5, unicode-1-1;q=0.8`表示客户端优先接受ISO-8859-5编码的字符集，但也可以接受Unicode-1-1，尽管其优先级稍低（q=0.8）。

        Accept-Encoding：客户端支持的内容编码。示例`Accept-Encoding: 表示客户端接受任何类型的内容编码。

        Accept-Language：客户端优先接受的语言。示例`Accept-Language: en-gb;q=0.8, en;q=0.7`表示客户端优先接受英国英语，其次是其他类型的英语。

        Accept-Ranges：服务器可以接受的部分请求的单位。示例`Accept-Ranges: bytes`表示服务器可以处理以字节为单位的部分请求。

        Allow：服务器支持的HTTP方法。示例`Allow: GET, HEAD, PUT`表示服务器支持GET、HEAD和PUT这三种请求方法。

        If-Modified-Since：告诉服务器如果请求的资源自指定的日期之后被修改过，就发送资源。示例`If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT`表示如果自1994年10月29日19点43分31秒GMT之后资源有变更，就发送该资源；否则，返回304状态码，表示资源未修改。

        这些请求头部使得HTTP请求可以更精确地告诉服务器客户端的具体需求和支持的特性，以便服务器可以发送符合客户端要求的响应。

4.2.2.3 响应头部（Response header）

        是指只在响应消息中使用的头部，比如Server或WWW-Authenticate。

        HTTP响应头部的一些例子：

        Accept-Ranges：定义服务器是否接受范围请求，以及定义的范围类型。示例`Accept-Ranges: none`表明服务器不支持范围请求。

        Age：表示自从响应产生以来经过的时间（以秒为单位）。示例`Age: 3000`表明该响应已经产生了3000秒。

        Location：用于重定向到一个新的URI。示例`Location: http://www.cnam.fr`表示客户端应跳转到提供的URI。

        Etag：响应内容的唯一标识（实体标签）。它可以用来检查资源是否有变化。示例`ETag: "nom"`提供了一个值，客户端可以在后续的请求中使用这个值来检查资源是否被修改。

        这些响应头部帮助客户端理解服务器的响应并适当地处理它们，例如判断内容是否最新、是否需要重定向到新的地址，或者验证缓存的内容是否仍然是最新的。

4.2.2.4 实体头部（Entity header）

        是指那些和消息体的内容相关的头部，比如`Content-Length`或`Content-Type`。

        当然，这里有一个HTTP请求的头部示例：

        假设您的浏览器向`www.example.com`的服务器发送一个请求来获取首页的HTML文档，HTTP请求可能包含以下头部：

        GET /index.html HTTP/1.1是请求行，指明使用GET方法获取`/index.html`这个资源，使用的是HTTP 1.1版本。

        Host: www.example.com 是一个请求头部，指定请求的服务器地址。

        User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.3是一个请求头部，描述了发出请求的浏览器的类型和版本。

        Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 是一个请求头部，告诉服务器客户端能够处理的内容类型。

        Accept-Language: en-US,en;q=0.5是一个请求头部，说明客户端优先接受的语言。

        Accept-Encoding: gzip, deflate 是一个请求头部，说明客户端可以接受的内容编码类型，比如gzip压缩。

        Connection: keep-alive：是一个请求头部，要求服务器保持连接打开，以便后续请求复用通过这些头部，HTTP消息可以携带关于请求或响应的附加信息，以及关于实体本身的数据。

4.3 空行（CRLF，即Carriage Return Line Feed）

        标记头部结束和消息体开始的地方。

4.4 消息体（message-body）

        可选部分，包含了发送的数据，比如网页的HTML代码或API调用的JSON数据。

        消息体编码：HTTP消息的主体部分在传输时会进行编码，这种编码方式会在HTTP头部中指定。消息体可以包含任意的数据字节（在文本中表示为`OCTET`）。

        实体（entité）：传输在消息体中的资源被称为实体。实体可以是文档、图片或其他任何类型的数据。

        简而言之，HTTP消息体是HTTP消息结构的一个组成部分，它承载了客户端请求或服务器响应中的实际内容。比如，当你请求一个网页时，该网页的HTML内容就会作为响应的消息体发送给你。消息体的具体内容和格式由HTTP头部中的`Content-Type`和`Content-Encoding`等字段指定。

4.5 理解

        HTTP消息就像是互联网上的信封，里面装着网页或应用程序发送和接收的信息。这个“信封”有固定的格式，分为几个部分：

        起始行：就像信封的标题，告诉我们这是什么类型的信息。如果是请求，会包含你想要做的事情（比如查看网页），如果是响应，会告诉你请求结果如何（比如请求成功或失败）。

        头部：提供额外信息，比如内容有多长，需要用什么方式查看等。

        空行：头部结束的标志，就像写信时在正文前空一行一样。

        消息体：这是可选的，如果你发送的是网页内容或者是其他数据，就会用到这一部分。

        总的来说，HTTP消息就是互联网上发送和接收数据的方式，它有固定的格式，确保数据能够正确地发送和接收。

        通常，一个HTTP消息从起始行开始，然后是多个头部，一个空行，最后是消息体（如果有的话）。这种结构使得HTTP消息既可以携带请求的详细信息，也可以携带服务器的响应数据。

5. HTTP协议和统一资源标识符（URI）的使用

5.1 目标资源

        在HTTP请求中，客户端指定想要交互的目标资源，这个资源通过URI来识别。

5.1.1 绝对形式

        客户端在请求行中使用完整的URI来指定资源。例如：

 GET http://www.ietf.org/rfc/rfc2616.txt HTTP/1.1

        这里GET是请求方法，http://www.ietf.org/rfc/rfc2616.txt是资源的绝对URI，HTTP/1.1是HTTP协议的版本。

5.1.2 相对形式

        客户端可以在请求行中使用相对URI，并在请求头部使用`Host`字段来指定主机名。例如：

GET /rfc/rfc2616.txt HTTP/1.1

Host: www.ietf.org

        在这种情况下，请求行只包含资源的相对路径（`/rfc/rfc2616.txt`），而`Host`头部指定了完整的主机名（`www.ietf.org`）。

        绝对形式的URI在请求中提供了资源的完整地址，而相对形式则需要结合`Host`头部字段来确定资源的完整位置。这两种形式都是HTTP/1.1标准中支持的。

5.2 HTTP请求和响应的格式

5.2.1 请求

5.2.1.1 格式

        由请求行（Request-Line）开始，这是HTTP请求的第一行，包含了方法、请求的资源URI和HTTP版本。

        紧接着是零个或多个头部字段（header-field），每个字段都以回车换行符（CRLF）结束。

        头部字段和消息体之间有一个空的回车换行符（CRLF）作为分隔。

        可选的消息体（message-body），用于包含如POST请求的数据。

5.2.1.2 示例

GET /path/file.html HTTP/1.0

From: [email protected]

User-Agent: HTTPTool/1.0

[blank line here]

        请求行：使用GET方法请求/path/file.html这个资源，HTTP版本为1.0。

        From头部：发起请求的用户的电子邮件地址是[email protected]。

        User-Agent头部：发起请求的客户端程序是HTTPTool/1.0。

        请求头部与消息体之间有一个空白行，表示消息头部结束，如果有消息体的话会在这个空白行后面开始

5.2.2 响应

5.2.2.1 格式

        由状态行（Status-Line）开始，这是HTTP响应的第一行，包含了HTTP版本、状态码和状态描述。

        同样地，紧接着是零个或多个头部字段（header-field），每个字段都以回车换行符（CRLF）结束。

        头部字段和消息体之间有一个空的回车换行符（CRLF）作为分隔。

        可选的消息体（message-body），用于包含如返回的网页内容或API调用的JSON数据。

5.2.2.2 示例

HTTP/1.0 200 OK

Date: Fri, 31 Dec 1999 23:59:59 GMT

Content-Type: text/html

Content-Length: 1354

  ... 

        状态行：HTTP版本为1.0，状态码为200，表示请求成功。

        Date头部：响应生成的日期和时间是1999年12月31日23时59分59秒 GMT。

        Content-Type头部：响应的内容类型是text/html，表示是一个HTML文档。

        Content-Length头部：响应的内容长度是1354字节。

        消息体：包含HTML文档的实际内容，从开始，到结束。

        这个格式允许HTTP消息在网络上清晰地传输请求和响应信息，确保接收方可以正确解析消息的各个部分。

5.2.2.2.1 HTTP版本（HTTP-Version）

        指明了响应遵循的HTTP协议版本，例如HTTP/1.1或HTTP/2.0。

5.2.2.2.2 状态码（Status-Code）

        是一个三位整数，用于表示请求的处理结果。例如，200表示请求成功，404表示没有找到请求的资源。

HTTP响应状态码的分类：

        1xx（信息响应）：表示接收到请求并且继续处理中。

        2xx（成功）：表示请求已被成功接收、理解并接受。

        3xx（重定向）：表示需要进一步的操作以完成请求，通常用来进行URL的重定向。

        4xx（客户端错误）：表示请求包含语法错误或无法完成请求。

        5xx（服务器错误）：表示服务器在尝试处理请求时发生了错误。

        每个数字范围代表一个响应类型，其中首位数字定义了响应的类别，其后两位数字无分类作用，但指定了具体的响应条件或错误。这个系统允许客户端理解它们的请求是否成功，并在出错时了解问题所在。

        100 Continue：继续。客户端应继续其请求。

        101 Switching Protocols：切换协议。服务器根据客户端的请求切换协议。

        200 OK：请求成功。一般用于GET与POST请求。

        201 Created：已创建。成功请求并创建了新的资源。

        202 Accepted：已接受。已经接受请求，但未处理完成。

        203 Non-Authoritative Information：非权威信息。请求成功，但返回的信息可能来自第三方。

        204 No Content：无内容。服务器成功处理，但未返回内容。

        301 Moved Permanently：永久移动。请求的资源已永久移动到新位置。

        307 Temporary Redirect：临时重定向。请求的资源临时从其他地址响应。

        400 Bad Request：错误请求。服务器无法理解请求的格式。

        500 Internal Server Error：内部服务器错误。服务器遇到错误，无法完成请求。

        这些状态码是客户端与服务器通信时，用于表示请求处理情况和结果的重要信息

        原因短语（Reason-Phrase）：是一个对状态码的简短文字描述，例如"OK"表示成功，"Not Found"表示资源未找到。

        回车换行符（CRLF）：状态行的结束标志，确保与后续头部的分隔。

        例如，一个典型的状态行可能是：

`        HTTP/1.1 200 OK，其中`HTTP/1.1`是协议版本，`200`是状态码，`OK`是原因短语，表示请求已经成功处理。

6. HTTP协议的总结

        请求-响应简单协议：HTTP是一个基于TCP（传输控制协议）的简单请求-响应类型的协议，它是无状态的，意味着服务器不会保持与客户端之间的交互状态。

        Cookies：Cookies是一种在客户端存储状态信息的简单方式，用于跨越多个请求维持交互状态。

        信息传输载体：HTTP可以用来传输任何类型的信息。

        认证机制：HTTP支持基本的认证方案，如用户名和密码登录，也支持更安全的摘要认证和加密，比如使用SSL（安全套接层）。

        代理作为中间人：在HTTP通信中，代理服务器（Proxy）充当客户端和服务器之间的中间人，可以处理和转发请求和响应。

        规范参考：HTTP协议的规范由W3C（万维网联盟）维护，参考地址是：[http://www.w3.org/Protocols/Specs.html](http://www.w3.org/Protocols/Specs.html)。

        这段总结指出了HTTP协议的基本特征和一些关键的技术点，以及它如何适用于Web通信和数据传输。