前言
虽然应用层协议是我们程序猿自己定的,但实际上已经有大佬们定义了一些现成的又非常好用的应用层协议供我们直接参考使用,HTTP(超文本传输协议)就是其中之一。
在互联网世界中,HTTP(HyperText Transfer Protocol,超文本传输协议)是一个至关重要的协议。它定义了客户端(如浏览器)与服务器之间如何通信以交换或传输超文本(如 HTML 文档)。 HTTP 协议是客户端与服务器之间通信的基础。客户端通过HTTP协议向服务器发送请求,服务器收到请求后处理并返回响应。HTTP协议是一个无连接、无状态的协议,即每次请求都需要建立新的连接,且服务器不会保存客户端的状态信息。
1. URL
1.1 url 的认识
平时我们俗称的 "网址" 其实就是说的 URL(Uniform Resource Locator,统一资源定位符)。
下图就是一个URL的常见格式:
认识:
1. 我们上网的行为,本质就是IO。(我的数据给别人,别人的数据给我)
2. 我们上网所获得的图片、音频、文本等都是资源。
3. 我们想要通过网络获取资源,首先就需要确定资源在哪台服务器(IP+端口号),在什么路径下(linux的文件路径,这里的路径指的是web根目录),于是就有了URL。
4. 成熟的应用层协议往往都与端口号是强关联的,所以不需要指明端口号。
1.2 urlencode 和 urldecode
像 / ? : 等这样的字符,已经被 url 当做特殊意义理解了,因此这些字符不能随意出现。比如,某个参数中需要带有这些特殊字符,就必须先对特殊字符进行转义,转义的规则如下:将需要转码的字符转为16进制,然后从右到左,取 4 位(不足 4 位直接处理),每 2 位做一位,前面加上%,编码成%XY格式。urldecode 就是 urlencode 的逆过程。例如:
2. HTTP协议的宏观格式
HTTP不想依赖任何的库所以自己做了序列化和反序列化。
2.1 HTTP的请求行与状态行
2.1.1 请求方法
请求方法中最常用的就是 GET 方法和 POST 方法。
GET和POST方法的区别:
• 相同点:两者均用于请求url的指定资源。
• 不同点:GET方法请求的资源,参数附加在URL中(如
?name=Alice&age=20
),可见且长度受限。POST方法请求的资源,参数封装在请求正文中,不可见且理论上无大小限制。
2.1.2 HTTP的状态码
最常见的状态码, 比如 200(OK), 404(Not Found), 403(Forbidden), 302(Redirect, 重定向), 504(Bad Gateway)
状态码 | 含义 | 应用样例 |
---|---|---|
100 | Continue | 上传大文件时,服务器告诉客户端可以 继续上传 |
200 | OK | 访问网站首页,服务器返回网页内容 |
201 | Created | 发布新文章,服务器返回文章创建成功 的信息 |
204 | No Content | 删除文章后,服务器返回“无内容”表示操 作成功 |
301 | Moved Permanently | 网站换域名后,自动跳转到新域名;搜 索引擎更新网站链接时使用 |
302 | Found 或 See Other | 用户登录成功后,重定向到用户首页 |
304 | Not Modified | 浏览器缓存机制,对未修改的资源返回 304 状态码 |
400 | Bad Request | 填写表单时,格式不正确导致提交失败 |
401 | Unauthorized | 访问需要登录的页面时,未登录或认证 失败 |
403 | Forbidden | 尝试访问你没有权限查看的页面 |
404 | Not Found | 访问不存在的网页链接 |
500 | Internal Server Error | 服务器崩溃或数据库错误导致页面无法 加载 |
502 | Bad Gateway | 使用代理服务器时,代理服务器无法从 上游服务器获取有效响应 |
503 | Service Unavailable | 服务器维护或过载,暂时无法处理请求 |
2.2 HTTP的请求报头
• Content-Type:数据类型(text/html 等)
• Content-Length:Body 的长度
• Host:客户端告知服务器, 所请求的资源是在哪个主机的哪个端口上;
• User-Agent:声明用户的操作系统和浏览器版本信息
• referer:当前页面是从哪个页面跳转过来的
• Location:搭配 3xx 状态码使用, 告诉客户端接下来要去哪里访问
• Cookie:用于在客户端存储少量信息. 通常用于实现会话(session)的功能
3. HTTP协议的版本变迁
版本 | 发布年份 | 核心特性 | 存在问题 |
---|---|---|---|
HTTP/0.9 | 1991 | 仅支持 GET 请求,传输纯文本 | 无状态、无首部、功能极简 |
HTTP/1.0 | 1996 | 引入状态码、请求/响应首部、多种方法 | 每次请求重新建立连接 |
HTTP/1.1 | 1997-1999 | 长连接、管道化、缓存机制 | 队头阻塞、效率不高 |
HTTP/2 | 2015 | 二进制帧、多路复用、头部压缩 | 加密依赖 TLS,复杂度高 |
HTTP/3 | 2022 | 基于 QUIC 协议,0-RTT 建连,减少丢包 | 仍在推广中,部署成本高 |
特性 | HTTP/1.0 | HTTP/1.1 | HTTP/2 | HTTP/3 |
---|---|---|---|---|
连接方式 | 短连接 | 长连接 | 多路复用(TCP) | 多路复用(QUIC/UDP) |
并发性能 | 差 | 管道化,有限提升 | 真正多路复用 | 多路复用 + 低延迟 |
编码方式 | 文本 | 文本 | 二进制帧结构 | 二进制帧结构 |
头部压缩 | 无 | 无 | HPACK | QPACK |
队头阻塞 | 严重 | 存在 | 应用层阻塞(TCP 造成) | 无(QUIC 层完全避免) |
安全机制 | 无 | 支持 TLS | 默认需 TLS | 内置加密(QUIC 原生支持) |