计算机网络——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通信和数据传输。

你可能感兴趣的:(计算机网络,计算机网络,http,网络协议)