编程技术文章分享与教程

网站首页 > 技术文章 正文

HTTP/1.1报文详解

hmc789 2024-11-18 12:58:59 技术文章 2 ℃

本文为《三万长文50+趣图带你领悟web编程的内功心法》第三个章节。

3、HTTP/1.1报文详解

在RFC2616中心详细的描述了HTTP/1.1[^3]的报文，感兴趣的朋友也可以前往阅读。

HTTP是基于TCP的，HTTP作为应用层协议，会在TCP/IP协议栈往下传递的时候，不断封装数据帧，如下图：

上面HTTP正文即是以我们HTTP报文格式来组织的。下面我们看看具体的HTTP报文的格式。

3.1、HTTP报文组成部分

HTTP请求和响应都使用如下通用的格式：

  • start-line：起始行，起始行可以为以下两者之一：

    • Request-Line：请求行，如：

      • GET /hello-world2.html HTTP/1.1

    • Status-Line：状态行，如：

      • HTTP/1.1 200 OK

  • *(message-header CRLF)：0个或者多个消息头；

  • CRLF：一个空行；

  • [message-body]：可选的消息体；

可以分别把请求报文和响应报文分开来描述：

请求报文

响应报文

可以发现，请求报文和响应报文格式就起始行不一样。

下面我们逐个来介绍。

为了尽可能保证内容的准确性，下面报文各种字段说明部分内容，大部分整理自RFC2616和MDN web docs：

以上资料内容有冲突的，以RFC2616的为准。

3.2、请求行

请求行格式：

Request-Line = Method SP Request-URI SP HTTP-Version CRLF

3.2.1、Method

方法是区分大消息的，以下是常用的方法：

方法说明
OPTIONS列出可以对服务器资源执行哪些方法
GET获取资源
HEAD获取资源的首部，与GET类似，但是不会响应消息体
POST向服务器提交数据
PUT将请求主体部分存储在服务器上
DELETE删除资源
TRACE对可能经过代理服务器传送到服务器上的报文进行追踪
CONNECT建立连接隧道
extension-method扩展方法

另外，服务器还可以实现一些自己的请求方法，这些附加的方法是对HTTP规范的扩展，因此也成为扩展方法。

extension-method = token

请求可能的返回结果：

  • 405：表示请求的方法不被允许，这个时候服务器响应头会响应当前资源允许的方法，如：

    • Allow: GET, HEAD, PUT

  • 501：代表原服务器的该方法未能被识别或者未实现；

下面逐个方法介绍下：

GET

GET方法意味着可以检索 Request-URI标识的任何信息。

如果Request-URI涉及到创建数据，则应该将新建的数据作为响应实体返回。

如果请求消息包含 If-Modified-Since，If-Unmodified-Since，If-Match，If-None_match或If-Range标头字段，则此时的Get为条件GET。通过使用缓存标头，可以尽可能避免不必要的网络传输。

如果请求标头包含Range，则GET方法变为部分GET。

HEAD方法与GET方法很类似，但是HEAD方法在在响应中只返回首部，不会反悔消息体。

这就允许客户端再不用获取实际资源的情况下，对资源首部进行检查。如：

  • 检查资源是否有更新：如果获取到的 Content-Length、Content-MD5、ETag、Last-Modified与之前获取到的值不同，那么缓存应该被视为过期；
  • 查看响应状态码，查看资源是否存在；
  • 获取首部更多信息，判断资源情况。

POST

POST方法起初是用来向服务器传输数据的，通常用来提交HTML的表单到服务器。

PUT

PUT方法用于向服务器写入资源，如果Request-URI对应的资源已经存在的话，就进行更新。

注意：

POST用于向服务器发送数据，PUT用于向服务器上的资源中存储数据。

DELETE

请求服务器删除URL所指示的资源，但是客户端无法保证删除操作一定会被执行，除非在响应式服务器打算删除资源或者将其移动到无法访问的位置。可能的响应：

  • 如果响应包含描述状态的实体，则响应200（确定）；
  • 如果尚未执行删除操作，则响应202（接受）；
  • 如果已执行该操作，并且响应不包含任何实体，则响应204（无内容）。

此方法的响应不可缓存。

TRACE

一个请求从客户端到服务端，中间可能会经历各种代理、网关等程序，每个中间节点都可能修改原始HTTP请求。为此，通过TRACE，服务端会在接收到请求后反馈一个TRACE响应，并且在响应主体中携带它收到的原始请求报文。客户端拿到TRACE响应，就可以进行测试和诊断了。其中Via标头字段特别有用，它用于充当请求链的跟踪。

可以使用Max-Forwards标头字段限制请求链的长度，这对于测试无限循环中转发消息的代理很有用。

如果请求有效，则响应应该在实体正文中包含整个请求消息，其 Content-Type为"message/http"。对此方法的响应绝对不能缓存。

TRACE允跨站点跟踪问题，并且可能使黑客可以选择窃取您的cookie信息。基于安全的考虑，一般的服务器会关掉TRACE：

TraceEnable off

这样执行TRACE会导致客户端收到一个405不允许使用方法的状态码。

CONNECT

CONNECT 方法可以开启一个客户端与所请求资源之间的双向沟通的通道。它可以用来创建隧道（tunnel）。

例如，CONNECT 可以用来访问采用了 SSL (HTTPS) 协议的站点。客户端要求代理服务器将 TCP 连接作为通往目的主机隧道。之后该服务器会代替客户端与目的主机建立连接。连接建立好之后，代理服务器会面向客户端发送或接收 TCP 消息流。[^5]

OPTIONS

通过该方法，可以请求服务器获取Request-URI对应支持的各种通信选项的信息。最常见的如：询问服务器当前URI支持哪些请求方法。

此方法响应不能缓存。

方法的安全性与幂等性

所谓安全性，就是无论方法执行多少次，服务器上的数据都不会被改变。

安全方法：GET、HEAD；

不安全方法：POST、PUT、DELETE操作则会改动数据。

所谓幂等，就是多次执行一个方法，结果都是相同的。

幂等方法：GET、HEAD、PUT、DELETE；

非幂等方法：POST。

3.2.2、Request-URI

URI，Uniform Resource Identifier，请求的统一资源标识符。

3.2.2.1、URI与URL什么关系？

我们经常会用到这两个概念，但是他们是什么意思呢？

URI，Uniform Resource Identifier，统一资源标识符，能够唯一的标识网上的一个资源，比如，我的网站IT宅的Logo：

https://www.itzhai.com/resources/images/itzhai_logo_home_page.jpg

只要在世界的任何一个有网络的地方，发起请求，就可以拿到这个图片，这个URI具有唯一性。那什么是URL呢？

URI有两种形式：URL和URN。

URL

URL，Uniform Resource Locator，统一资源定位符，描述了一台特定服务器上某个资源的特定位置。例如上面的链接就是一个统一资源定位符：

  • secheme方案：指定方位资源所使用的协议类型，如HTTPS；
  • 主机与端口：英特网地址，即域名，这里默认为80端口；
  • 路径：其余部分指定web服务器上的某个资源。

几乎所有的 URI都是URL。

一个完整的URL格式如下：

  • 用户名和密码：有写服务器要求输入用户名和密码才允许用户访问数据，如FTP；
  • ?query 查询字符串：可以通过查询字符串进行查询来缩小所请求资源类型的范围；
  • fragment片段：指向HTML文档中特定的图片或者小节。

URN

URL，Uniform Resource Name，统一资源名，作为特定内容的唯一名称，与资源所在位置无关。也就是说，我可以给一份文档定义一个URN，不管你把这个文档放到哪里，有多少个URL，但是都只有唯一个URN。举个例子，因特网标准文档 RFC 3986不管存在哪个服务器上，都可以用唯一的URN来命名：

urn:ietf:rfc:3986

URN处于试验阶段，暂未大范围使用。

再通俗易懂点来说：URN就相当于身份证，通过特定的规则，制定了一串唯一的字符串作为你的身份证，但是没有规定身份证一定要放在哪里，只是作为你的个人唯一凭证。URL相当于是快递单上的地址，根据地址，快递员一定可以把快递送到唯一的一个目的地。

3.2.3、HTTP-Version

指定了当前请求用到的HTTP协议版本。

3.3、消息头[^6]

通过传递消息头(首部)，服务器和客户端可以把自己的信息或者是请求响应相关信息进行传递。

可以把首部分为：通用首部，请求首部，响应首部，实体首部，扩展首部。下面就来详细介绍下。

3.3.1、通用首部

有些首部，不管是请求还是响应都会出现他们的身影，我们把他们归类为通用首部。常见通用首部如下表格所示：

首部说明
Cache-Control通过指定指令来实现缓存机制
ConnectionConnection 头（header） 决定当前的事务完成后，是否会关闭网络连接。如果该值是“keep-alive”，网络连接就是持久的，不会关闭，使得对同一个服务器的请求可以继续在该连接上完成：
Connection: keep-alive
Connection: close
Data提供报文创建的时间
MIME-Version提供发送端使用的MIME版本
Trailer允许发送方在分块发送的消息后面添加额外的元信息，这些元信息可能是随着消息主体的发送动态生成的，比如消息的完整性校验，消息的数字签名，或者消息经过处理之后的最终状态等。
Transfer-Encoding告知接收端报文的编码方式
Upgrade允许客户端指定它支持并且希望使用的通信协议，如果服务器认为适合，则切换协议，服务器必须使用101(交换协议)中的Upgrade标头字段响应，以知识正在交换的协议。
Via显示报文经过的中间节点，用来追踪消息转发情况，防止循环请求，以及识别在请求或响应传递链中消息发送者对于协议的支持能力
Warning包含报文当前状态可能存在的问题。在响应中可以出现多个 Warning 首部。一般来说， Warning 首部可以应用于任何类型的报文。然而一部分警告码（warn-code）是为缓存代理服务器定制的，并且只可以应用在响应报文中。

3.3.2、请求首部

客户端通过传递请求头字段，将有关请求以及有关客户端本身的其他信息传递给服务器，这些字段充当请求修饰符，其语义等同于编程语言方法调用中的参数。

常见的请求头如下：

Accept首部

首部说明
Accept表明客户端能够接受的媒体类型
Accept-Charset表明客户端能够接受的字符集
Accept-Encoding表明客户端能够接受的编码方式
Accept-LanguageSection 14.4
TE表明客户端能够接受的扩展传输编码

条件请求首部

首部说明
Expect指示客户端要求特定的服务器行为
目前规范中只规定了 "100-continue" 这一个期望条件：通知接收方客户端要发送一个体积可能很大的消息体，期望收到状态码为100 (Continue) 的临时回复
If-Match请求首部 If-Match 的使用表示这是一个条件请求。在请求方法为 GET 和 HEAD 的情况下，服务器仅在请求的资源满足此首部列出的 ETag值时才会返回资源。而对于 PUT 或其他非安全方法来说，只有在满足条件的情况下才可以将资源上传。
If-Modified-SinceIf-Modified-Since 是一个条件式请求首部，服务器只在所请求的资源在给定的日期时间之后对内容进行过修改的情况下才会将资源返回，状态码为 200 。如果请求的资源从那时起未经修改，那么返回一个不带有消息主体的 304 响应，而在 Last-Modified 首部中会带有上次修改时间。 不同于 If-Unmodified-Since, If-Modified-Since 只可以用在GET 或 HEAD 请求中。
If-None-Match对于 GET 和 HEAD 请求方法来说，当且仅当服务器上没有任何资源的 ETag 属性值与这个首部中列出的相匹配的时候，服务器端会才返回所请求的资源，响应码为 200。对于其他方法来说，当且仅当最终确认没有已存在的资源的 ETag 属性值与这个首部中所列出的相匹配的时候，才会对请求进行相应的处理。
If-RangeIf-Range HTTP 请求头字段用来使得 Range 头字段在一定条件下起作用：当字段值中的条件得到满足时，Range 头字段才会起作用，同时服务器回复206 部分内容状态码，以及Range 头字段请求的相应部分；如果字段值中的条件没有得到满足，服务器将会返回 200 OK 状态码，并返回完整的请求资源。
If-Unmodified-SinceHTTP协议中的 If-Unmodified-Since 消息头用于请求之中，使得当前请求成为条件式请求：只有当资源在指定的时间之后没有进行过修改的情况下，服务器才会返回请求的资源，或是接受 POST 或其他 non-safe 方法的请求。如果所请求的资源在指定的时间之后发生了修改，那么会返回 412 (Precondition Failed) 错误。
RangeThe Range 是一个请求首部，告知服务器返回文件的哪一部分。在一个 Range 首部中，可以一次性请求多个部分，服务器会以 multipart 文件的形式将其返回。如果服务器返回的是范围响应，需要使用 206 Partial Content 状态码。假如所请求的范围不合法，那么服务器会返回 416 Range Not Satisfiable 状态码，表示客户端错误。服务器允许忽略 Range 首部，从而返回整个文件，状态码用 200 。

安全请求首部

首部说明
AuthorizationHTTP协议中的 Authorization 请求消息头含有服务器用于验证用户代理身份的凭证，通常会在服务器返回401 Unauthorized 状态码以及WWW-Authenticate 消息头之后在后续请求中发送此消息头。
CookieCookie 是一个请求首部，其中含有先前由服务器通过 Set-Cookie 首部投放并存储到客户端的 HTTP cookies。
Cookie2这个已经被废弃的 Cookie2 请求首部曾经被用来告知浏览器该用户代理支持“新型” cookies，但是现代的用户代理一般使用 Cookie 来替代 Cookie2。

代理请求首部

首部说明
Max-Forwards在通往源端服务器的路径上，将请求转发给其他代理或者网关的最大次数，与TRACE方法类似。
Proxy-AuthorizationProxy-Authorization 是一个请求首部，其中包含了用户代理提供给代理服务器的用于身份验证的凭证。这个首部通常是在服务器返回了 407 Proxy Authentication Required 响应状态码及 Proxy-Authenticate 首部后发送的。
Proxy-Connection同Connection，不过这个首部是在与代理建立连接时使用。

3.3.3、响应首部

首部说明
AgeAge 消息头里包含对象在缓存代理中存贮的时长，以秒为单位。
Age的值通常接近于0。表示此对象刚刚从原始服务器获取不久；其他的值则是表示代理服务器当前的系统时间与此应答中的通用头 Date 的值之差。
Retry-After在HTTP协议中，响应首部 Retry-After 表示用户代理需要等待多长时间之后才能继续发送请求。这个首部主要应用于以下两种场景：
- 当与 503 响应一起发送的时候，表示服务下线的预期时长；
- 当与重定向响应一起发送的时候，比如 301 (Moved Permanently，永久迁移)，表示用户代理在发送重定向请求之前需要等待的最短时间。
ServerServer 首部包含了处理请求的源头服务器所用到的软件相关信息。
避免描述的过于详细，因为这有可能泄露服务器内部实现细节，或者被攻击者找到已知安全漏洞。
Title对于HTML文档来说，就是HTML文案定的源端给出的标题。
该首部定义与原始的 HTTP/1.0草案，并未列入RFC2616。
WarningWarning 是一个通用报文首部，包含报文当前状态可能存在的问题。在响应中可以出现多个 Warning 首部。
一般来说， Warning 首部可以应用于任何类型的报文。然而一部分警告码（warn-code）是为缓存代理服务器定制的，并且只可以应用在响应报文中。格式：
Warning: <warn-code> <warn-agent> <warn-text> [<warn-date>]

协商首部

如果资源有多种表示方法，服务器可以通过协商首部来传递可协商资源有关的信息。

首部说明
Accept-Range服务器使用 HTTP 响应头 **Accept-Ranges** 标识自身支持范围请求(partial requests)。字段的具体值用于定义范围请求的单位。
当浏览器发现Accept-Ranges头时，可以尝试继续中断了的下载，而不是重新开始。
VaryVary 是一个HTTP响应头部信息，它决定了对于未来的一个请求头，应该用一个缓存的回复(response)还是向源服务器请求一个新的回复。
例如，移动端和桌面端响应内容是不同的，为了防止移动端误用了桌面端的缓存，可以这样指定Vary：Vary: User-Agent

安全响应首部

首部描述
Proxy-Authenticate指定了获取 proxy server （代理服务器）上的资源访问权限而采用的身份验证方式。代理服务器对请求进行验证，以便它进一步传递请求。
Proxy-Authenticate首部需要与 407 Proxy Authentication Required 响应一起发送。
Set-Cookie响应首部 Set-Cookie 被用来由服务器端向客户端发送 cookie。
Set-Cookie2已废弃使用。它被服务器用来向客户端发送 cookie 数据，但是已经在协议中被标记为不赞成使用了。请使用 Set-Cookie 将其代替。
WWW-Authenticate定义了使用何种验证方式去获取对资源的连接。
WWW-Authenticate header通常会和一个 401 Unauthorized 的响应一同被发送。

3.3.4、实体首部

用来描述HTTP报文中实体相关信息的首部，我们成为实体首部。

首部描述
AllowAllow 首部字段用于枚举资源所支持的 HTTP 方法的集合。
LocationLocation 首部指定的是需要将页面重新定向至的地址。一般在响应码为3xx的响应中才会有意义：
- 303 (See Also) 始终引致请求使用 GET 方法，而，而 307 (Temporary Redirect) 和 308 (Permanent Redirect) 则不转变初始请求中的所使用的方法；
- 301 (Permanent Redirect) 和 302 (Found) 在大多数情况下不会转变初始请求中的方法，不过一些比较早的用户代理可能会引发方法的变更；
除了重定向响应之外， 状态码为 201 (Created) 的消息也会带有Location首部。它指向的是新创建的资源的地址。

内容首部

首部描述
Content-EncodingContent-Encoding 是一个实体消息首部，用于对特定媒体类型的数据进行压缩。
Content-LanguateContent-Language 用来说明访问者希望采用的语言或语言组合，这样的话用户就可以根据自己偏好的语言来定制不同的内容。
Content-Length指明发送给接收方的消息主体的大小，即用十进制数字表示的八位元组的数目。
Content-Location指定的是要返回的数据的地址选项。最主要的用途是用来指定要访问的资源经过内容协商后的结果的URL。
Content-MD5消息主题的MD5校验和
Content-Range描述一个数据片段在整个文件中的位置
Content-Type指示资源的MIME类型 media type

实体缓存首部

实体缓存首部提供与被缓存实体有关的信息，如什么时候或者如何缓存，缓存是否有效等，通过缓存首部可以估计缓存何时失效。

首部描述
ETag资源的特定版本的标识符。这可以让缓存更高效，并节省带宽，因为如果内容没有改变，Web服务器不需要发送完整的响应。
如果给定URL中的资源更改，则一定要生成新的Etag值。
Expires该首部包含日期/时间， 即在此时候之后，响应过期。
无效的日期，比如 0, 代表着过去的日期，即该资源已经过期。
Last-Modified含源头服务器认定的资源做出修改的日期及时间。 它通常被用作一个验证器来判断接收到的或者存储的资源是否彼此一致。
由于精确度比 ETag 要低，所以这是一个备用机制。包含有 If-Modified-Since 或 If-Unmodified-Since 首部的条件请求会使用这个字段。

3.4、消息体

3.4.1、请求消息体

并不是所有的请求都需要body，如：GET，HEAD，DELETE，OPTIONS通产不需要body。

请求body可以分为两类：

3.4.2、响应消息体

并不是所有的响应都有body，如 201 或 204状态码的响应一般不会有body。

响应body可以分为三类：

  • Single-resource bodies，由已知长度的单个文件组成。该类型 body 由两个 header 定义：Content-Type 和 Content-Length；
  • Single-resource bodies，由未知长度的单个文件组成，通过将 Transfer-Encoding 设置为 chunked来使用 chunks 编码；
  • Multiple-resource bodies，由多部分 body 组成，每部分包含不同的信息段。但这是比较少见的。

3.5、状态行

响应消息的第一行是状态行，由协议版本，数字状态代码及其关联的文本短语组成，每个元素由SP字符分隔。 除最后的CRLF序列外，不允许CR或LF。

状态行格式：

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

3.5.1、Status-Code状态码和Reason-Phrase状态描述

状态码是3位数的整数结果代码。

状态码的第一位数字定义响应的类别。 后两位数字没有任何分类作用。可以分为5个类别：

  • 1xx：信息状态码，收到请求，继续进行；
  • 2xx：请求成功接收；
  • 3xx：重定向，必须采取进一步措施才能完成请求；
  • 4xx：客户端错误，请求包含错误语法，或者不能被完成；
  • 5xx：服务器错误，服务器无法完成看似有效的请求；

RFC中定义的状态码很多，这里我们列出最常见的一些状态码：

状态码描述详细说明
101Switching Protocol该代码是响应客户端的 Upgrade 标头发送的，并且指示服务器也正在切换的协议。
200OK请求成功。
204No Content服务器成功处理了请求，但不需要返回任何实体内容，并且希望返回更新了的元信息。
用这个状态码区分成功状态下又返回内容和没返回内容的响应。
206Partial Content服务器已经成功处理了部分 GET 请求。通过HTTP的分块下载，获取资源的部分时返回。该请求必须包含 Range 头信息来指示客户端希望得到的内容范围，并且可能包含 If-Range 来作为请求条件。
206状态码通常会携带Content-Range，用于表示报文里面body数据的具体范围。
301Moved Permanently永久重定向，将来任何对此资源的引用都应该使用本响应返回的若干个 URI 之一。
302Found临时重定向，客户端下次应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下，这个响应才是可缓存的。
304Not Modified如果客户端发送了一个带条件的 GET 请求且该请求已被允许，而文档的内容（自上次访问以来或者根据请求的条件）并没有改变，则服务器应当返回这个状态码。304 响应禁止包含消息体，因此始终以消息头后的第一个空行结尾。
400Bad Request语义有误，当前请求无法被服务器理解。除非进行修改，否则客户端不应该重复提交这个请求。
401Unauthorized当前请求需要用户验证。该响应必须包含一个适用于被请求资源的 WWW-Authenticate 信息头用以询问用户信息。客户端可以重复提交一个包含恰当的 Authorization 头信息的请求。
403Forbidden服务器已经理解请求，但是拒绝执行它。如果这不是一个 HEAD 请求，而且服务器希望能够讲清楚为何请求不能被执行，那么就应该在实体内描述拒绝的原因。当然服务器也可以返回一个 404 响应，假如它不希望让客户端获得任何信息。
404Not Found请求失败，请求所希望得到的资源未被在服务器上发现。
究竟是不是真的资源不存在呢？还得看程序是怎么写的。
405Method Not Allowed请求行中指定的请求方法不能被用于请求相应的资源。该响应必须返回一个Allow 头信息用以表示出当前资源能够接受的请求方法的列表。
408Request Timeout请求超时。客户端没有在服务器预备等待的时间内完成一个请求的发送。客户端可以随时再次提交这一请求而无需进行任何更改。
409Conflict由于和被请求的资源的当前状态之间存在冲突，请求无法完成。
413Payload Too Large请求提交的实体数据大小超过了服务器愿意或者能够处理的范围。此种情况下，服务器可以关闭连接以免客户端继续发送此请求。如果这个状况是临时的，服务器应当返回一个 Retry-After 的响应头，以告知客户端可以在多少时间以后重新尝试。
429Too Many Requests用户在给定的时间内发送了太多请求（“限制请求速率”）。
431Request Header Fields Too Large请求头字段太大（ Request Header Fields Too Large）
500Internal Server Error服务器遇到了不知道如何处理的情况。通常用来捕获服务器异常，统一返回500，避免输出详细错误堆栈给别人利用。
501Not Implemented此请求方法不被服务器支持且无法被处理。只有GET和HEAD是要求服务器支持的，它们必定不会返回此错误代码。
502Bad Gateway此错误响应表明服务器作为网关需要得到一个处理这个请求的响应，但是得到一个错误的响应。
503Service Unavailable服务器没有准备好处理请求。 常见原因是服务器因维护或重载而停机。
504Gateway Timeout当服务器作为网关，不能及时得到响应时返回此错误代码。

更多状态码说明：

上面我们把HTTP报文介绍了一遍，HTTP作为一个协议，只是规定了大家要遵循这样的约定，但是具体实现的时候，还是要看应用程序的兼容程度。我们在写程序的时候，也不要跟协议对着干，这会让对接的同事无法理解的。

你都知道以下状态码的含义了吗？

200 204 206 301 302 304 401 403 405 500 501 502 503 504

本文首次发表于: HTTP/1.1报文详解 以及公众号 Java架构杂谈，未经许可，不得转载。

本文为arthinking基于相关技术资料和官方文档撰写而成，确保内容的准确性，如果你发现了有何错漏之处，烦请高抬贵手帮忙指正，万分感激。

如果您觉得读完本文有所收获的话，可以关注我的账号，或者点赞吧，码字不易，您的支持就是我写作的最大动力，再次感谢！

为了把相关系列文章收集起来，方便后续查阅，这里我创建了一个Github仓库，把发布的文章按照分类收集起来了，感兴趣的朋友可以Star跟进：

https://github.com/arthinking/java-tech-stack

关注我的博客IT宅(itzhai.com)或者公众号Java架构杂谈，及时获取最新的文章。我将持续更新后端相关技术，涉及JVM、Java基础、架构设计、网络编程、数据结构、数据库、算法、并发编程、分布式系统等相关内容。

References

[^1]: Hypertext Transfer Protocol -- HTTP/1.0 RFC 1945. Retrieved from https://datatracker.ietf.org/doc/rfc1945/

[^2]: HypertextTransferProtocol--HTTP/1.1 2068. Retrieved from https://tools.ietf.org/html/rfc2068

[^3]: Hypertext Transfer Protocol -- HTTP/1.1 2616. Retrieved from https://tools.ietf.org/html/rfc2616

[^4]: Hypertext Transfer Protocol Version 3 (HTTP/3). Retrieved from https://quicwg.org/base-drafts/draft-ietf-quic-http.html

[^5]: CONNECT. Retrieved from https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Methods/CONNECT

[^6]: HTTP Headers. Retrieved from https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers

[^7]: HTTP. MDN web docs. Retrieved from https://developer.mozilla.org/zh-CN/docs/Web/HTTP

[^8]: List of HTTP status codes. Retrieved from https://en.wikipedia.org/wiki/List_of_HTTP_status_codes

[^9]: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status. Retrieved from https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status

[^10]: 两万字长文50+张趣图带你领悟网络编程的内功心法-TCP特点. Retrieved from https://www.itzhai.com/network/comprehend-the-underlying-principles-of-network-programming.html#4-2-2%E3%80%81TCP%E7%89%B9%E7%82%B9

[^11]: 技术干货：HTTP/2 之服务器推送 (Server Push) 最佳实践. Retrieved from https://www.infoq.cn/article/qYdN85t4G4dL4vBAe3N2

[^12]: 《HTTP权威指南》第17章 内容协商与转码. 人民邮电出版社. P413

[^13]: 两万字长文50+张趣图带你领悟网络编程的内功心法-TCP连接管理. Retrieved from https://www.itzhai.com/network/comprehend-the-underlying-principles-of-network-programming.html#4-2-3、连接管理

[^14]: 《HTTP权威指南》 第六章 代理

[^15]: 《HTTP权威指南》 第八章 集成点：网关、隧道及中继

[^16]: Module ngx_http_upstream_module. Retrieved from http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive

[^17]: 161 Cipher Suites. Retrieved from https://ciphersuite.info/cs/?software=openssl&singlepage=true

[^18]: HTTP/2 简介. Retrieved from https://developers.google.com/web/fundamentals/performance/http2

  • 谢希仁. 计算机网络(第6版). 电子工业出版社.
  • TCP/IP详解 卷1：协议（原书第2版）. 机械工业出版社.
  • UNIX网络编程 卷1：套接字联网API. 人民邮电出版社
  • HTTP权威指南. 人民邮电出版社
  • HTTP/2基础教程. 人民邮电出版社
  • 刘超. 趣谈网络协议. 极客时间
  • 罗剑锋. 透视HTTP协议. 即可时间

本文同步发表于我的博客IT宅(itzhai.com)和公众号(Java架构杂谈)

作者：arthinking | 公众号：Java架构杂谈

博客链接：https://www.itzhai.com/articles/detailed-explanation-of-http-1-1-messages.html

版权声明： 版权归作者所有，未经许可不得转载，侵权必究！联系作者请加公众号。

Tags：

猜你喜欢

标签列表
最新留言