http协议
1 概念
http协议是一个应用层协议,它详细规定了浏览器和万维网服务器之间通信的规则,它可以使浏览器更加高效、使网络传输减少。它不仅保证计算机正确快速地传输超文本文档,还确立传输文档中的那一部分以及那一部分先传
http协议由请求和响应构成,是一个标准的客户端服务器模型,是一种无状态协议
在 Internet 所有传输都是通过 TCP/IP 进行的
HTTP默认的端口是80,HTTPS是443
2 简史
它的发展是万维网协会和Internet工作夏普组合作的结果
3 特点
HTTP协议永远都是客户端发起请求,服务端回应请求。这样就限制了使用HTTP协议,无法实现在客户端没有发起请求的时候,服务器将信息推送给客户端
主要特点:
- 支持客户/服务器模式,支持基本认证和安全认证
- 简单快速:客户向服务器请求服务时,只需传送请求方法和路径,请求方法常用GET、POST、HEAD,每种方法规定了客户与服务器联系的类型不同
- 灵活:HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记
- HTTP 0.9和1.0使用非持续连接:限制每次连接只处理一个请求,服务器处理完客户请求,并受到答应后即断开联系;HTTP 1.1使用持续连接,不必为每个web对象创建一个新的连接,一个连接可以传送多个对象
- 无状态:对事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息,则它必须重传
- 无状态协议
- 协议的状态是指下一次传输可以“记住”这次传输信息的能力
- http协议的无状态是为了节省内存
4 HTTP协议的工作流程
4.1 建立连接
在客户端和服务器进行通信之前,需要先建立一个TCP连接。TCP是一种可靠的传输协议,它可以确保数据在传输过程中不会丢失或损坏。客户端通过向服务器的特定端口(通常是80或443)发送一个连接请求,服务器接收到请求后,如果同意连接,就会返回一个确认信息,这样客户端和服务器之间就建立了一个TCP连接。这就好比我们打电话,先拨对方的电话号码,对方接听后,我们就可以开始通话了。
4.2 发送请求
建立连接后,客户端就可以向服务器发送HTTP请求了。客户端根据用户的操作,构造一个HTTP请求消息,并通过TCP连接发送给服务器。请求消息的格式必须符合HTTP协议的规定,否则服务器可能无法正确解析。例如,当我们在浏览器中访问一个网页时,浏览器会构造一个GET请求,请求的URL就是我们输入的网址。
4.3 服务器处理请求
服务器接收到客户端的请求后,会对请求进行解析和处理。服务器首先会检查请求的格式是否正确,如果格式不正确,就会返回一个错误响应。然后,服务器会根据请求的内容,查找相应的资源或执行相应的操作。比如,如果请求的是一个网页,服务器就会从文件系统中查找该网页的HTML文件,并读取其内容。
4.4 发送响应
服务器处理完请求后,会构造一个HTTP响应消息,并通过TCP连接发送给客户端。响应消息的格式也必须符合HTTP协议的规定,包含响应行、响应头和响应体。响应行中的状态码表示请求的处理结果,常见的状态码有200表示成功,404表示请求的资源不存在,500表示服务器内部错误等。
4.5 关闭连接
客户端接收到服务器的响应后,会根据响应的内容进行相应的处理,比如显示网页内容。然后,客户端和服务器会关闭之前建立的TCP连接,释放系统资源。现代的 HTTP 1.1 及以上协议支持持久连接,即一次连接可以处理多个请求和响应,不需要每次都重新建立连接。
5 头域
每个头域由一个域名,冒号(:)和域值三部分组成。域名的大小写无关的,域值前可以添加任何数量的空格符,头域可以被扩展为多行,每行开始处,使用至少一个空格或制表符
5.1 请求信息
发出的请求信息:
- 请求行(Request Line):
- 方法:如 GET、POST、PUT、DELETE等,指定要执行的操作。
- 请求 URI(统一资源标识符):请求的资源路径,通常包括主机名、端口号(如果非默认)、路径和查询字符串。
- HTTP 版本:如 HTTP/1.1 或 HTTP/2。
请求行的格式示例:GET /index.html HTTP/1.1
- 请求头(Request Headers):
- 包含了客户端环境信息、请求体的大小(如果有)、客户端支持的压缩类型等。
- 常见的请求头包括
Host、User-Agent、Accept、Accept-Encoding、Content-Length等。
- 空行:
- 请求头和请求体之间的分隔符,表示请求头的结束。
- 请求体(可选):
- 在某些类型的HTTP请求(如 POST 和 PUT)中,请求体包含要发送给服务器的数据。
5.2 请求方法
HTTP/1.1 协议定义了八种方法
- GET:最常用的方法,用于请求指定资源的表示。GET请求应该只接收数据。
- POST:用于提交数据到指定资源,数据包含在请求体中。POST请求可能会导致新的资源的创建和/或已有资源的修改。
- PUT:用于将数据发送到服务器以更新指定的资源。与POST不同,PUT方法是幂等的。
- DELETE:用于删除指定的资源。
- HEAD:与GET方法一样,都是请求指定的资源,但HEAD方法没有响应体。只返回资源的头部信息。
- OPTIONS:用于获取目标资源所支持的通信选项。返回服务器支持的HTTP方法。
- CONNECT:主要用于SSL隧道代理。用于建立网络连接,通常用于HTTPS。
- TRACE:进行回环诊断。它会在响应体中返回请求的原始形式,用于诊断和测试。
[!tip] GET和POST的区别
- GET提交的数据会放在URL之后,以?分割URL和传输数据,参数之间通过&相连;POST方法是把提交数据放在body中
- GET提交的大小是有限制的,最多只能有1024个字节;POST没有
- GET方式需要使用Request.QueryString来取得变量的值;POST方法通过Request.Form来获取
- GET方式提交数据,会带来安全问题,比如一个登录页面,通过GET提交数据时,用户名和密码将出现在URL上,如果页面可以被缓存或者其他人可以访问这台机器,就可以获取该用户账号密码
当浏览者访问一个网页时,浏览者的浏览器会向网页所在服务器发出请求。当浏览器接收并显示网页前,此网页所在的服务器会返回一个包含 HTTP 状态码的信息头(server header)用以响应浏览器的请求。
HTTP 状态码的英文为 HTTP Status Code。
下面是常见的 HTTP 状态码:
- 1xx(信息性状态码):表示接收的请求正在处理。
- 2xx(成功状态码):表示请求正常处理完毕。
- 3xx(重定向状态码):需要后续操作才能完成这一请求。
- 4xx(客户端错误状态码):表示请求包含语法错误或无法完成。
- 5xx(服务器错误状态码):服务器在处理请求的过程中发生了错误。
5.2.1 HTTP 状态码分类
HTTP 状态码由三个十进制数字组成,第一个十进制数字定义了状态码的类型。响应分为五类:信息响应(100–199),成功响应(200–299),重定向(300–399),客户端错误(400–499)和服务器错误 (500–599):
| 分类 | 分类描述 |
|---|---|
| 1** | 信息,服务器收到请求,需要请求者继续执行操作 |
| 2** | 成功,操作被成功接收并处理 |
| 3** | 重定向,需要进一步的操作以完成请求 |
| 4** | 客户端错误,请求包含语法错误或无法完成请求 |
| 5** | 服务器错误,服务器在处理请求的过程中发生了错误 |
HTTP状态码列表:
| 状态码 | 状态码英文名称 | 中文描述 |
|---|---|---|
| 100 | Continue | 继续。客户端应继续其请求 |
| 101 | Switching Protocols | 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议,例如,切换到HTTP的新版本协议 |
| 200 | OK | 请求成功。一般用于GET与POST请求 |
| 201 | Created | 已创建。成功请求并创建了新的资源 |
| 202 | Accepted | 已接受。已经接受请求,但未处理完成 |
| 203 | Non-Authoritative Information | 非授权信息。请求成功。但返回的meta信息不在原始的服务器,而是一个副本 |
| 204 | No Content | 无内容。服务器成功处理,但未返回内容。在未更新网页的情况下,可确保浏览器继续显示当前文档 |
| 205 | Reset Content | 重置内容。服务器处理成功,用户终端(例如:浏览器)应重置文档视图。可通过此返回码清除浏览器的表单域 |
| 206 | Partial Content | 部分内容。服务器成功处理了部分GET请求 |
| 300 | Multiple Choices | 多种选择。请求的资源可包括多个位置,相应可返回一个资源特征与地址的列表用于用户终端(例如:浏览器)选择 |
| 301 | Moved Permanently | 永久移动。请求的资源已被永久的移动到新URI,返回信息会包括新的URI,浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替 |
| 302 | Found | 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI |
| 303 | See Other | 查看其它地址。与301类似。使用GET和POST请求查看 |
| 304 | Not Modified | 未修改。所请求的资源未修改,服务器返回此状态码时,不会返回任何资源。客户端通常会缓存访问过的资源,通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源 |
| 305 | Use Proxy | 使用代理。所请求的资源必须通过代理访问 |
| 306 | Unused | 已经被废弃的HTTP状态码 |
| 307 | Temporary Redirect | 临时重定向。与302类似。使用GET请求重定向 |
| 400 | Bad Request | 客户端请求的语法错误,服务器无法理解 |
| 401 | Unauthorized | 请求要求用户的身份认证 |
| 402 | Payment Required | 保留,将来使用 |
| 403 | Forbidden | 服务器理解请求客户端的请求,但是拒绝执行此请求 |
| 404 | Not Found | 服务器无法根据客户端的请求找到资源(网页)。通过此代码,网站设计人员可设置”您所请求的资源无法找到”的个性页面 |
| 405 | Method Not Allowed | 客户端请求中的方法被禁止 |
| 406 | Not Acceptable | 服务器无法根据客户端请求的内容特性完成请求 |
| 407 | Proxy Authentication Required | 请求要求代理的身份认证,与401类似,但请求者应当使用代理进行授权 |
| 408 | Request Time-out | 服务器等待客户端发送的请求时间过长,超时 |
| 409 | Conflict | 服务器完成客户端的 PUT 请求时可能返回此代码,服务器处理请求时发生了冲突 |
| 410 | Gone | 客户端请求的资源已经不存在。410不同于404,如果资源以前有现在被永久删除了可使用410代码,网站设计人员可通过301代码指定资源的新位置 |
| 411 | Length Required | 服务器无法处理客户端发送的不带Content-Length的请求信息 |
| 412 | Precondition Failed | 客户端请求信息的先决条件错误 |
| 413 | Request Entity Too Large | 由于请求的实体过大,服务器无法处理,因此拒绝请求。为防止客户端的连续请求,服务器可能会关闭连接。如果只是服务器暂时无法处理,则会包含一个Retry-After的响应信息 |
| 414 | Request-URI Too Large | 请求的URI过长(URI通常为网址),服务器无法处理 |
| 415 | Unsupported Media Type | 服务器无法处理请求附带的媒体格式 |
| 416 | Requested range not satisfiable | 客户端请求的范围无效 |
| 417 | Expectation Failed(预期失败) | 服务器无法满足请求头中 Expect 字段指定的预期行为。 |
| 418 | I’m a teapot | 状态码 418 实际上是一个愚人节玩笑。它在 RFC 2324 中定义,该 RFC 是一个关于超文本咖啡壶控制协议(HTCPCP)的笑话文件。在这个笑话中,418 状态码是作为一个玩笑加入到 HTTP 协议中的。 |
| 500 | Internal Server Error | 服务器内部错误,无法完成请求 |
| 501 | Not Implemented | 服务器不支持请求的功能,无法完成请求 |
| 502 | Bad Gateway | 作为网关或者代理工作的服务器尝试执行请求时,从远程服务器接收到了一个无效的响应 |
| 503 | Service Unavailable | 由于超载或系统维护,服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中 |
| 504 | Gateway Time-out | 充当网关或代理的服务器,未及时从远端服务器获取请求 |
| 505 | HTTP Version not supported | 服务器不支持请求的HTTP协议的版本,无法完成处理 |
6 http解决无状态的问题
6.1 通过cookies来保存状态信息
通过cookies,服务端就可以清楚地知道请求1和请求2来自同一客户端
6.1.1 为什么需要 Cookie 和 Session?
HTTP 协议是无状态(Stateless)的,这意味着:
每次请求之间,服务器不会主动记住你是谁。
用户在一次请求中登录了,下一次请求服务器依然当你是新访客。
像购物车、个人中心、支付流程等功能无法在多次请求之间共享状态。
所以,状态保持技术的核心目标是:
让服务器在多个 HTTP 请求中”记住”客户端的身份和相关信息。
最常见的两种技术就是 Cookie 和 Session。
6.1.2 Cookie ——— 浏览器端的状态记录
6.1.2.1 概念
Cookie 是一小段存储在浏览器端 的文本数据,由服务器生成并通过响应头 Set-Cookie 发送给浏览器保存。之后浏览器访问同一域名时会自动携带 Cookie 发送给服务器。
6.1.2.2 工作原理
首次请求:浏览器访问服务器,服务器在响应头中设置 Cookie。
存储:浏览器将 Cookie 保存到本地文件(每个浏览器保存方式不同)。
后续请求:浏览器在请求头中自动带上 Cookie 信息。
服务器读取:服务器解析 Cookie,从而识别用户身份。
流程图示意:
css复制代码
1 | [浏览器] --请求--> [服务器] |
6.1.2.3 示例
html复制代码
1 | HTTP/1.1 200 OK |
下次请求:
html复制代码
1 | GET /index.html HTTP/1.1 |
6.1.2.4 Cookie 的关键属性
| 属性 | 作用 |
|---|---|
| Name=Value | 键值对数据 |
| Domain | 指定 Cookie 生效的域名 |
| Path | 指定 Cookie 生效的路径 |
| Expires / Max-Age | 设置过期时间 |
| HttpOnly | 防止 JavaScript 读取,增强安全性 |
| Secure | 仅在 HTTPS 下传输 |
6.1.2.5 Cookie 的优缺点
优点:
浏览器自动管理,无需额外代码处理传输。
可以持久化存储(设置过期时间)。
缺点:
Session 是一种服务器端存储 的会话数据机制。
当用户第一次访问时,服务器会为其创建一个 Session,并分配一个唯一的 Session ID,将这个 ID 返回给浏览器保存(通常通过 Cookie)。
6.2.2 工作原理
- 首次访问:服务器生成 Session 数据(例如登录状态、购物车内容),并生成唯一的 Session ID。
- 返回 Session ID :服务器通过 Cookie 将 Session ID 发给浏览器(如
JSESSIONID=xyz123)。 - 浏览器保存:浏览器保存 Session ID 到 Cookie。
- 后续请求:浏览器在请求中携带 Session ID,服务器根据该 ID 找到对应的 Session 数据。
例如:
1 | Set-Cookie: JSESSIONID=xyz123; Path=/; HttpOnly |
后续请求:
1 | GET /cart HTTP/1.1 |
6.2.3 Session 特性
- 存储位置:服务器内存 / 数据库 / 分布式缓存(如 Redis)。
- 生命周期:默认 30 分钟(可配置)。
- 容量限制:取决于服务器内存,理论上可存储较大数据。
- 安全性:数据不直接暴露给客户端,安全性高。
6.2.4 Cookie 与 Session 的关系
实际上,Session 通常依赖 Cookie 来保存 Session ID:
- Cookie 中只保存一个
Session ID。 - 具体的用户数据(登录状态、购物车等)存放在服务器的 Session 对象中。
这种方式结合了两者的优点:
- 减少 Cookie 存储压力。
- 提升安全性(敏感数据不放在客户端)。
6.2.5 Cookie 与 Session 的对比
| 对比项 | Cookie | Session |
|---|---|---|
| 存储位置 | 客户端(浏览器) | 服务器端 |
| 安全性 | 易被窃取或篡改(需加密) | 高,数据不暴露给客户端 |
| 存储容量 | 单个 ≤ 4KB | 受服务器内存限制 |
| 生命周期 | 可设置过期时间 | 默认短时存储,可配置 |
| 性能影响 | 占用客户端空间,增加网络流量 | 占用服务器内存 |
| 使用场景 | 保存非敏感、需要持久化的数据 | 保存敏感数据(如登录信息) |
7 url详解
一个url通常包括:
https://- Protocolwww.- Sub Domain(子域名)wljslmz.cn- Domain Name(域名):80- Port(端口)/login.html- Path(路径)?key1=value1- Query(查询字符串)#123- Fragment(片段标识符)






