HTTP协议
- HTTP协议简介与作用
- HTTP基本工作原理
- 非持久连接与持久连接的区别
- HTTP请求与响应
- HTTP请求
- HTTP响应
- 请求与响应的交互流程
- HTTP方法
- 实例
- GET 请求示例
- POST 请求示例
- HEAD 请求示例
- 使用场景
- HTTP状态码
- HTTP消息结构与头字段
- 头字段
- HTTP的无状态性与状态管理
- 初步了解安全性与HTTPS
我们今天来了解一下HTTP这个重要的协议,HTTP是在互联网上进行数据传输的主要方式,尤其对于Web服务至关重要,并且,HTTP协议是作为应用层协议如果大家对TCP/IP网络协议模型不是很清晰这块不是很了解,大家可以点击这里:
https://blog.csdn.net/qq_67693066/article/details/136614754
HTTP协议简介与作用
HTTP(超文本传输协议)是一种在互联网上传输信息的协议。它允许用户通过浏览器(如Firefox、Chrome等)向服务器发送请求,服务器则返回相应的信息。这种请求和响应的过程就像我们平时写信一样,浏览器是写信人,服务器是收信人。
HTTP协议的作用主要有三个:
定义通信规则:HTTP协议规定了浏览器和服务器之间如何交流。例如,当我们在浏览器中输入一个网址时,浏览器会按照HTTP协议的规则向服务器发送一个请求,服务器收到请求后,也会按照HTTP协议的规则返回一个响应。
定义请求和响应格式:HTTP协议不仅规定了通信的规则,还规定了请求和响应的格式。例如,当我们向服务器发送一个请求时,请求的内容应该是什么样的,服务器返回的响应又应该是什么样的。
处理请求和响应:HTTP协议还定义了一些处理请求和响应的规则。例如,当服务器收到一个请求时,它会根据请求的内容进行处理,然后返回一个响应。这个响应可能是一个网页,也可能是一个错误信息。
总的来说,HTTP协议就像是一个语言,它规定了浏览器和服务器之间如何交流,以及交流的内容和格式。
我们学习HTTP的目的就是:理解HTTP旨在解决客户端(如浏览器)与服务器之间的数据传输问题,支持文件下载、页面浏览、表单提交等多种操作。
HTTP基本工作原理
HTTP协议的基本工作原理主要基于客户端-服务器架构,通过请求和响应的方式实现数据的交互。以下是其工作原理的详细解释:
客户端发起请求:
当用户在浏览器中输入URL或点击某个链接时,浏览器会作为HTTP客户端,根据URL信息构建HTTP请求。请求中包含了请求方法(如GET、POST等)、请求头(如User-Agent、Accept等)以及请求体(如果有的话,例如POST请求中的表单数据)。
建立连接:
客户端通过TCP/IP协议与服务器建立连接。在HTTP/1.0中,每次请求都需要建立一个新的连接;而在HTTP/1.1中,引入了持久连接(keep-alive)机制,允许多个请求在同一个连接上发送,减少了连接建立和断开的开销。
服务器处理请求:
服务器接收到客户端的请求后,会根据请求中的URL定位到相应的资源或处理逻辑。服务器会解析请求头中的信息,理解客户端的需求,并执行相应的操作。如果需要,服务器还可能访问数据库或其他服务来获取所需的数据。
生成响应:
根据请求的处理结果,服务器会生成HTTP响应。响应中包含状态码(如200表示成功,404表示未找到资源等)、响应头(如Content-Type、Server等)以及响应体(包含返回的数据)。
发送响应并关闭连接:
服务器将生成的响应发送回客户端,并通过TCP/IP连接将数据传输给客户端。在HTTP/1.0中,发送完响应后连接会被关闭;而在HTTP/1.1的持久连接中,连接会保持打开状态,直到一方主动关闭或超时断开。
客户端处理响应:
客户端接收到服务器的响应后,会根据响应中的状态码和内容执行相应的处理。例如,如果状态码为200,且响应体中包含HTML代码,浏览器会解析HTML并渲染出网页。
举个例子:
假设你想访问一个在线书店的网站,并在网站上搜索一本名为《哈利·波特与魔法石》的书。当你输入URL并按下回车键时,浏览器会构建一个HTTP请求并发送给服务器。以下是一个简化的示例:
- URL:https://www.example-bookstore.com/search?keyword=harry+potter+and+the+sorcerer%27s+stone
- 解析URL:
- 协议:HTTPS
- 域名:www.example-bookstore.com
- 端口:443(HTTPS默认端口)
- 路径:/search
- 查询参数:keyword=harry+potter+and+the+sorcerer%27s+stone
- 建立连接:浏览器与www.example-bookstore.com的443端口建立TCP连接,并进行SSL/TLS握手。
- 发送请求:浏览器构建以下HTTP请求并发送给服务器:
GET /search?keyword=harry+potter+and+the+sorcerer%27s+stone HTTP/1.1
Host: www.example-bookstore.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0
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, br
Connection: keep-alive
Upgrade-Insecure-Requests: 1- 接收响应:服务器处理请求并返回以下HTTP响应:
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 12345
Date: Fri, 26 Mar 2023 10:00:00 GMT
Server: Apache/2.4.41 (Unix)
//你看到的页面- 关闭连接:浏览器和服务器在完成数据交换后,关闭TCP连接。
在这个例子中,浏览器根据URL信息构建了一个HTTP GET请求,用于搜索名为《哈利·波特与魔法石》的书。服务器处理请求并返回一个包含搜索结果的HTML页面。
在整个过程中,HTTP协议是无状态的,即服务器不会记住之前与客户端的通信状态。每个请求都是独立的,服务器只会根据当前请求的内容进行处理。这种设计简化了协议的实现,并提高了系统的可伸缩性。
需要注意的是,HTTP协议只负责传输数据,而不关心数据的具体含义或格式。数据的解释和处理由应用程序(如Web浏览器)来完成。此外,HTTPS(HTTP Secure)是HTTP的安全版本,通过在传输层使用SSL/TLS协议加密数据,提供了更安全的数据传输方式。
非持久连接与持久连接的区别
非持久连接与持久连接在HTTP通信模型中存在显著的区别,主要体现在以下几个方面:
连接状态与生命周期:
非持久连接:每次请求与响应之间都会关闭连接。也就是说,当客户端向服务器发送请求后,服务器会立即返回响应,然后关闭连接。下一次请求需要重新建立连接。这种方式的优点是可以及时释放资源,但缺点也很明显,即每次请求都需要重新建立连接,影响效率。
持久连接(也称为长连接):在一次TCP连接中,允许多个请求和响应的交互。即在一次TCP连接之内,客户端可以发送多个请求,并且服务器也可以分别响应这些请求,直到客户端显式地要求关闭连接或者达到了某个预设的超时时间。这种连接在TCP层握手成功后不会立即断开,而是在此连接的基础上进行多次消息(包括心跳)交互,直至连接的任意一方主动断开连接。
资源利用与效率:
非持久连接由于每次请求都需要建立新的连接,因此会造成大量的通信开销,特别是在请求频繁的情况下。这种方式对于服务器来说可能会带来较重的负担,因为每台服务器可能同时面对数以百计甚至更多的请求。
持久连接通过保持连接状态,减少了建立连接的次数,从而节省了通信量,提高了效率。这种方式更适合于请求频繁的场景,能够显著减少通信开销。
适用场景:
非持久连接可能更适合于那些请求不频繁、对实时性要求不高的场景。
持久连接则更适用于请求频繁、对效率要求较高的场景,如现代Web应用中的AJAX请求、WebSockets等。
总结来说,非持久连接和持久连接各有其优缺点和适用场景。在实际应用中,需要根据具体的需求和场景来选择合适的连接方式。
HTTP请求与响应
HTTP请求和响应是HTTP协议中两个核心的概念,它们分别代表客户端(通常是浏览器)与服务器之间的通信过程。下面详细解释它们的组成及交互流程。
HTTP请求
HTTP请求是由客户端(通常是Web浏览器)发送到服务器的信息,用于请求服务器提供资源或执行特定操作。HTTP请求通常包含以下几个部分:
-
请求行:包含请求方法(如GET, POST, PUT, DELETE等)、请求资源的URI以及HTTP版本号。
比如我们使用火狐浏览器,右键单击,检查:
找到网络:
我们刷新一下页面,这时候会涌出很多东西:
我们点进去一个GET看看:
请求头那里改为原始:
-
请求头:包含一系列键值对,提供有关请求的附加信息。常见的请求头包括
User-Agent
(客户端类型)、Accept
(可接受的数据类型)等。
下面就是请求头:
点击原始,我们可以看到原始版本:
-
请求体:不是所有请求都包含请求体。当使用GET或HEAD方法时,请求体通常为空。而对于POST、PUT等方法,请求体会包含要发送给服务器的实际数据。请求体的数据类型由
Content-Type
头指定。
我在这里并没有找到请求体,但是它应该长的类似于像这样:
Content-Type: application/x-www-form-urlencoded
Content-Length: 34name=John+Doe&age=25&city=New+York
HTTP响应
HTTP响应是由服务器发送回客户端的信息,作为对HTTP请求的回应。HTTP响应通常包含以下几个部分:
-
状态行:包含HTTP版本号、状态码(如200 OK, 404 Not Found等)以及简短的原因短语。
-
响应头:与请求头类似,响应头也包含一系列键值对,提供有关响应的附加信息。常见的响应头包括
Content-Type
(响应数据的类型)、Content-Length
(响应体的长度)等。
-
响应体:包含服务器返回的实际数据。对于HTML页面、图片等资源,响应体将包含这些资源的实际内容。响应体的数据类型由
Content-Type
头指定。
其实就是我们最终在页面上看到的东西:
请求与响应的交互流程
- 客户端(通常是浏览器)根据用户操作(如点击链接、提交表单等)构造HTTP请求。
- 客户端通过网络将HTTP请求发送给服务器。
- 服务器接收到HTTP请求后,根据请求内容进行处理。
- 服务器构造HTTP响应,并将其发送回客户端。
- 客户端接收到HTTP响应后,根据响应内容进行相应处理(如显示网页、执行操作等)。
这个过程可能会涉及多次请求和响应的交互,直到客户端完成其任务或用户主动终止交互。
HTTP方法
HTTP方法(也称为HTTP请求方法或动作)是HTTP协议中定义的一种用来指定客户端与服务器之间交互方式的一种手段。它们告诉服务器需要对请求的资源执行何种操作。HTTP/1.1协议中共定义了八种方法,其中包括GET、POST、HEAD等。以下是其中几种常见的方法的简要说明:
GET:这是最常用的方法,用于请求指定的页面信息。当使用GET方法时,浏览器会向服务器发送请求,并获取服务器返回的资源。GET请求的数据会附加在URL之后,并以查询字符串的形式呈现。
HEAD:类似于GET请求,但返回的响应中没有具体的内容,只包含报头。这种方法通常用于获取与特定资源关联的元信息,而不需要传输整个资源本身。
POST:用于向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。与GET方法不同,POST请求的数据包含在请求体中,这样可以在请求中发送大量数据,而且这些数据不会在URL中显示。POST请求可能会导致新的资源的建立或已有资源的修改。
除了上述三种常见方法外,HTTP/1.1还定义了PUT、DELETE、CONNECT、OPTIONS和TRACE等其他方法,每种方法都有其特定的用途和操作方式。这些方法的使用取决于具体的应用场景和需求。
总的来说,HTTP方法提供了客户端与服务器之间灵活且多样化的交互方式,使得Web应用能够处理各种复杂的请求和操作。
实例
当然可以,以下是对HTTP方法中GET、POST和HEAD的示例请求,并附带了注释来解释每个请求的结构和用途:
GET 请求示例
http
GET /users/123 HTTP/1.1 // 请求行,指定方法为GET,请求的资源路径为/users/123,使用的HTTP协议版本为1.1
Host: example.com // 请求头,指定请求的主机名
Accept: text/html // 请求头,表示客户端希望接收的响应内容类型
User-Agent: Mozilla/5.0 // 请求头,包含客户端(浏览器)的类型和版本信息
// GET请求没有请求体,所有需要传输的数据都包含在URL中
注释:
GET /users/123 HTTP/1.1:请求行指定了使用GET方法获取/users/123这个资源,并使用HTTP/1.1协议。
Host: example.com:请求头指定了目标服务器的域名。
Accept: text/html:请求头告诉服务器客户端希望接收的响应内容类型为HTML。
User-Agent: Mozilla/5.0:请求头提供了关于发起请求的客户端的信息,这有助于服务器为不同的客户端类型返回适当的内容。
比如我们看到的这个:
POST 请求示例
http
POST /login HTTP/1.1 // 请求行,指定方法为POST,请求的资源路径为/login,使用的HTTP协议版本为1.1
Host: example.com // 请求头,指定请求的主机名
Content-Type: application/x-www-form-urlencoded // 请求头,指定请求体的内容类型
Content-Length: 34 // 请求头,指定请求体的长度
username=myuser&password=mypass // 请求体,包含要提交给服务器的表单数据
注释:
POST /login HTTP/1.1:请求行指定了使用POST方法提交数据到/login这个资源,并使用HTTP/1.1协议。
Content-Type: application/x-www-form-urlencoded:请求头指定了请求体的内容类型,这里是表单编码的数据。
Content-Length: 34:请求头告知服务器请求体的长度,这有助于服务器正确解析请求体。
username=myuser&password=mypass:请求体包含了要发送给服务器的表单数据,这些数据在服务器端将被解析并用于处理登录请求。
就像这样子的一样:
HEAD 请求示例
http
HEAD /favicon.ico HTTP/1.1 // 请求行,指定方法为HEAD,请求的资源路径为/favicon.ico,使用的HTTP协议版本为1.1
Host: example.com // 请求头,指定请求的主机名
Accept: / // 请求头,表示客户端希望接收任何类型的响应内容
// HEAD请求没有请求体,服务器只返回响应头,不包含响应体
注释:
HEAD /favicon.ico HTTP/1.1:请求行指定了使用HEAD方法获取/favicon.ico这个资源的元数据,并使用HTTP/1.1协议。
Host: example.com:请求头指定了目标服务器的域名。
Accept: /:请求头表示客户端可以接受任何类型的响应内容。
HEAD请求通常用于获取资源的元信息(如内容类型、长度、最后修改时间等),而不需要下载资源的实际内容。服务器会返回与GET请求相同的响应头,但不会包含响应体。
使用场景
这三种HTTP方法(GET、POST和HEAD)各自适用于不同的场景,下面分别说明它们的常见使用场景:
GET 方法
常见使用场景:
请求并检索页面内容或资源(如图片、CSS文件、JavaScript脚本等)。
提交表单数据,这些数据通常会被附加到URL的查询字符串中。
缓存数据,因为GET请求通常可以被浏览器缓存。
通过API查询信息,比如获取特定用户的信息、查询数据库中的数据等。
注意:
GET请求应只用于检索数据,不应包含会改变服务器状态的操作。
由于GET请求的数据在URL中可见,因此不应包含敏感信息,如密码。
POST 方法
常见使用场景:
提交表单数据,特别是当表单数据包含敏感信息或数据量较大时。
上传文件到服务器。
创建新的资源,如发布博客文章、创建新用户等。
通过API提交数据,如发送消息、提交订单等。
注意:
POST请求的数据包含在请求体中,不会在URL中显示,因此适合传输敏感数据。
POST请求可能会导致服务器上资源的创建或状态的改变。
HEAD 方法
常见使用场景:
获取资源的元信息,如内容类型、长度、最后修改时间等,而不必下载资源的实际内容。
检查资源是否存在,以及了解资源的状态(如是否已修改)。
在实际下载大文件之前,先通过HEAD请求获取文件的大小和类型,以便进行预处理或显示给用户。
注意:
HEAD请求的响应只包含响应头,不包含响应体,因此可以快速获取资源的元信息而不需要传输大量数据。
总的来说,GET、POST和HEAD这三种HTTP方法各自有不同的用途和适用场景,开发者应根据具体需求选择合适的方法来实现客户端与服务器之间的交互。
HTTP状态码
HTTP状态码是HTTP协议中规定的一种三位数字代码,用于表示客户端与服务器间HTTP事务处理的结果。每个状态码的第一位数指示了响应的类别(也称为状态类别),共有五类:
- 1xx(临时响应):信息性状态码,表明请求已被接受,正在处理中。
- 示例:100 Continue,101 Switching Protocols
- 2xx(成功):表示请求已成功被服务器接收、理解并接受。
- 示例:200 OK,201 Created,202 Accepted,204 No Content
- 3xx(重定向):要求客户端采取进一步操作完成请求。
- 示例:301 Moved Permanently(永久重定向),302 Found(临时重定向),304 Not Modified(资源未修改)
- 4xx(客户端错误):由于客户端错误(如请求语法错误或无效请求)导致请求无法满足。
- 示例:400 Bad Request(错误请求),401 Unauthorized(未授权),403 Forbidden(禁止访问),404 Not Found(找不到资源)
- 5xx(服务器错误):服务器在处理请求时遇到了意外情况,未能完成请求。
- 示例:500 Internal Server Error(内部服务器错误),502 Bad Gateway(错误的网关),503 Service Unavailable(服务不可用),504 Gateway Timeout(网关超时)
这些状态码可以帮助开发者和用户更好地理解请求执行的情况,并根据不同的状态码做出相应的处理。状态码的具体含义可以通过RFC文档和其他相关标准获得更详细的解释。
HTTP消息结构与头字段
HTTP消息是由请求和响应组成的,它们都遵循相同的结构。HTTP消息由以下部分组成:
-
起始行:起始行包含请求方法(对于请求)或状态码和原因短语(对于响应)。起始行还包含HTTP版本号。
请求示例:
GET /index.html HTTP/1.1
响应示例:
HTTP/1.1 200 OK
-
头字段:头字段是一系列键值对,用于提供有关请求或响应的附加信息。常见的头字段包括
User-Agent
(客户端类型)、Content-Type
(请求体或响应体的数据类型)、Content-Length
(请求体或响应体的长度)等。示例:
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 Content-Type: text/html; charset=UTF-8 Content-Length: 1234
-
空行:头字段后面需要有一个空行(即两个换行符),用于分隔头字段和消息体。
-
消息体:对于请求,消息体包含要发送给服务器的实际数据(例如表单数据或文件内容)。对于响应,消息体包含服务器返回的实际数据(例如HTML文档或JSON数据)。
HTTP消息的基本结构如下:
起始行
头字段1: 值1
头字段2: 值2
...
头字段n: 值n消息体
请注意,消息体可能为空,尤其是对于某些类型的请求(如GET、HEAD等)或响应(如204 No Content等)。在这种情况下,空行后面不会有任何内容。
大家可以结合这个图片进行进一步理解:
头字段
头字段包括请求头(Request Headers)和响应头(Response Headers)
这里面包括许多字段:
HTTP头字段是HTTP请求和响应消息中的一部分,用于提供关于请求或响应的附加信息。HTTP头字段由一系列的键值对组成,每个键值对表示一个特定的头字段。以下是一些常见的HTTP头字段及其用途:
-
Request(请求头字段):
Accept
: 客户端可处理的媒体类型Accept-Charset
: 客户端优先使用的字符集Accept-Encoding
: 客户端优先使用的编码方式Accept-Language
: 客户端希望的语言Authorization
: 用户代理对服务器进行认证的方式Cookie
: 客户端接收到的cookie信息Expect
: 期待服务器的特定行为From
: 用户的电子邮箱地址Host
: 请求资源所在的服务器主机名If-Match
: 比较实体标记(ETag)If-Modified-Since
: 比较资源的更新时间If-None-Match
: 比较实体标记(ETag)If-Range
: 资源未更新时发送实体Byte的范围请求If-Unmodified-Since
: 比较资源的更新时间Max-Forwards
: 最大传输逐跳数Pragma
: 报文指令Range
: 实体的字节范围请求Referer
: 前一个页面的URLTE
: 客户端可处理的传输编码方式User-Agent
: 用户代理的名称和版本
-
Response(响应头字段):
Accept-Ranges
: 是否接受字节范围请求Age
: 推算资源创建经过的时间ETag
: 资源的匹配信息Location
: 令客户端重定向至指定URIProxy-Authenticate
: 代理服务器对客户端的质询认证信息Retry-After
: 对再次发起请求的时机要求Server
: 服务器的名称和版本Set-Cookie
: 在客户端设置cookie信息Vary
: 代理服务器缓存的管理信息WWW-Authenticate
: 服务器对客户端的质询认证信息
-Content-Type
:指示响应体的媒体类型(MIME类型),如text/html、application/json等
这些头字段在不同的HTTP请求和响应中可能会有不同的用途和意义。有些头字段是必需的,而有些则是可选的。在实际应用中,根据具体的业务需求和场景来选择合适的头字段。
HTTP的无状态性与状态管理
HTTP的无状态性是指HTTP协议本身并不维护客户端和服务器之间的会话状态。每次HTTP请求和响应都是独立的,服务器不会记住请求之间的任何信息。这种设计使得HTTP协议简单、高效,并且易于扩展和维护。
然而,在实际应用中,许多场景需要服务器记住客户端的状态,例如购物车、登录状态等。为了解决这一问题,HTTP协议引入了一些状态管理机制,如Cookie和Session。
- Cookie:Cookie是一种由服务器发送到客户端的特殊信息,客户端会将这些信息保存在本地。当客户端再次访问同一服务器时,它会将Cookie信息发送回服务器。这样,服务器就可以通过识别Cookie信息来恢复客户端的状态。Cookie通常用于存储用户的登录信息、偏好设置等。
- Session:Session是一种在服务器端维护客户端状态的方法。当客户端第一次访问服务器时,服务器会为它分配一个唯一的Session ID,并将这个ID通过Cookie或其他方式发送给客户端。客户端在后续的请求中会携带这个Session ID,服务器根据这个ID就可以找到对应的Session数据,从而恢复客户端的状态。Session通常用于存储用户的购物车信息、登录状态等。
需要注意的是,Cookie和Session都有一定的安全风险,例如Cookie劫持、Session固定攻击等。因此,在使用这些状态管理机制时,需要注意安全性问题,并采取相应的防护措施。
初步了解安全性与HTTPS
在了解HTTPS之前,我们首先需要了解网络安全性的相关概念。网络安全性是指保护网络系统和数据不受到未经授权的访问、篡改或破坏的能力。这涉及到多个方面,如身份验证、授权、数据加密和完整性保护等。
HTTP(超文本传输协议)是一种用于传输超文本的协议,它是互联网的基础协议之一。然而,HTTP本身并不提供任何安全性保证。在HTTP中,数据是以明文形式传输的,这意味着任何人都可以截获和查看传输的数据。此外,HTTP也无法验证通信双方的身份,因此容易受到中间人攻击。
为了解决这些问题,HTTPS(安全超文本传输协议)应运而生。HTTPS是HTTP的安全版本,它在HTTP的基础上增加了一层安全性保护——SSL/TLS协议。SSL(安全套接字层)和TLS(传输层安全)是两种网络安全协议,它们可以为HTTP提供加密、身份验证和完整性保护等安全功能。
使用HTTPS时,客户端和服务器之间会先进行SSL/TLS握手过程,以协商加密算法和密钥。一旦握手成功,客户端和服务器之间的所有通信数据都将使用协商好的加密算法进行加密传输,从而防止数据被窃取或篡改。同时,SSL/TLS协议还可以验证通信双方的身份,确保数据只能被合法的通信方接收。
除了提供加密和身份验证功能外,HTTPS还可以帮助网站提高搜索引擎排名和用户体验。因为搜索引擎通常会优先考虑使用HTTPS的网站,而且用户在浏览使用HTTPS的网站时也会更加放心。
总之,HTTPS是一种更加安全的HTTP版本,它可以提供加密、身份验证和完整性保护等安全功能,从而保护网络系统和数据的安全。在现代互联网应用中,使用HTTPS已经成为一种标准和最佳实践。