关于http的一些常识性知识
-
- http头信息
- http响应码
- [HTTP/1.1 和 HTTP/2](#HTTP/1.1 和 HTTP/2)
-
- [**1. HTTP/1.1**](#1. HTTP/1.1)
- [**2. HTTP/2**](#2. HTTP/2)
- [**3. HTTP/1.1 和 HTTP/2 的区别**](#3. HTTP/1.1 和 HTTP/2 的区别)
- [**4. HTTP/2 的核心特性详解**](#4. HTTP/2 的核心特性详解)
-
- [**1. 二进制分帧层**](#1. 二进制分帧层)
- [**2. 多路复用**](#2. 多路复用)
- [**3. 头部压缩**](#3. 头部压缩)
- [**4. 服务器推送**](#4. 服务器推送)
- [**5. 流优先级**](#5. 流优先级)
- [**5. 示例对比**](#5. 示例对比)
-
- [**HTTP/1.1 的请求**](#HTTP/1.1 的请求)
- [**HTTP/2 的请求**](#HTTP/2 的请求)
- [**6. 总结**](#6. 总结)
- 请求转发与重定向
-
- [**1. 请求转发(Forward)**](#1. 请求转发(Forward))
- [**2. 请求重定向(Redirect)**](#2. 请求重定向(Redirect))
- [**3. 请求转发 vs 请求重定向**](#3. 请求转发 vs 请求重定向)
- [**4. 示例对比**](#4. 示例对比)
- [**5. 总结**](#5. 总结)
- socket与websocket
http头信息
以下是常见的 HTTP 头信息及其解释,使用表格形式展示:
头字段 | 类型 | 解释 |
---|---|---|
通用头(General Headers) | ||
Cache-Control |
请求/响应 | 控制缓存行为,如 no-cache 、max-age=3600 。 |
Connection |
请求/响应 | 控制是否保持连接,如 keep-alive 或 close 。 |
Date |
请求/响应 | 消息发送的日期和时间,格式为 Wed, 21 Oct 2023 07:28:00 GMT 。 |
Pragma |
请求/响应 | 用于向后兼容 HTTP/1.0 的缓存控制,通常为 no-cache 。 |
Transfer-Encoding |
请求/响应 | 指定传输编码方式,如 chunked 。 |
请求头(Request Headers) | ||
Host |
请求 | 指定目标服务器的域名和端口号。 |
User-Agent |
请求 | 标识客户端(如浏览器或爬虫)的类型和版本。 |
Accept |
请求 | 指定客户端能够接收的 MIME 类型,如 text/html 、application/json 。 |
Accept-Language |
请求 | 指定客户端偏好的语言,如 en-US 。 |
Accept-Encoding |
请求 | 指定客户端支持的压缩编码,如 gzip 、deflate 。 |
Authorization |
请求 | 用于身份验证,如 Bearer <token> 或 Basic <credentials> 。 |
Cookie |
请求 | 传递客户端存储的 Cookie 信息。 |
Referer |
请求 | 指示请求的来源页面 URL。 |
Content-Type |
请求 | 指定请求体的 MIME 类型,如 application/json 。 |
Content-Length |
请求 | 指定请求体的长度(以字节为单位)。 |
响应头(Response Headers) | ||
Content-Type |
响应 | 指定响应体的 MIME 类型,如 text/html; charset=UTF-8 。 |
Content-Length |
响应 | 指定响应体的长度(以字节为单位)。 |
Content-Encoding |
响应 | 指定响应体的压缩编码,如 gzip 。 |
Server |
响应 | 标识服务器软件的名称和版本,如 Apache/2.4.1 。 |
Set-Cookie |
响应 | 服务器向客户端设置 Cookie。 |
Location |
响应 | 用于重定向,指定新资源的 URL。 |
Expires |
响应 | 指定响应内容的过期时间。 |
ETag |
响应 | 资源的唯一标识符,用于缓存验证。 |
Last-Modified |
响应 | 指定资源的最后修改时间。 |
Access-Control-Allow-Origin |
响应 | 指定允许跨域请求的来源(CORS 相关),如 * 或特定域名。 |
实体头(Entity Headers) | ||
Content-Type |
实体 | 指定实体体的 MIME 类型。 |
Content-Length |
实体 | 指定实体体的长度(以字节为单位)。 |
Content-Encoding |
实体 | 指定实体体的压缩编码,如 gzip 。 |
Content-Disposition |
实体 | 指定如何显示实体体,如 attachment; filename="file.txt" 。 |
自定义头(Custom Headers) | ||
X-Request-ID |
自定义 | 用于标识请求的唯一 ID。 |
X-Custom-Header |
自定义 | 自定义头字段,用于传递特定应用的信息。 |
示例
请求头示例
http
GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html
Accept-Language: en-US
Authorization: Bearer <token>
Cookie: sessionid=1234
响应头示例
http
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1234
Server: Apache/2.4.1
Set-Cookie: sessionid=1234; Path=/
Cache-Control: public, max-age=3600
通过合理使用这些头字段,可以优化 HTTP 通信、控制缓存、实现身份验证等功能。
http响应码
以下是 HTTP 响应状态码的详细说明,使用表格形式展示:
状态码 | 类别 | 描述 | 常见状态码 |
---|---|---|---|
1xx | 信息响应 | 表示请求已被接收,继续处理。 | |
100 | 继续 | 客户端应继续发送请求的剩余部分。 | |
101 | 切换协议 | 服务器根据客户端的请求切换协议(如切换到 WebSocket)。 | |
2xx | 成功响应 | 表示请求已成功被服务器接收、理解并处理。 | |
200 | 成功 | 请求成功,响应体中包含请求的结果。 | 最常见的成功状态码。 |
201 | 已创建 | 请求成功,并创建了新资源(通常用于 POST 请求)。 | |
202 | 已接受 | 请求已被接受,但尚未处理完成。 | |
204 | 无内容 | 请求成功,但响应体中没有内容(通常用于 DELETE 请求)。 | |
3xx | 重定向 | 表示需要客户端进一步操作以完成请求。 | |
301 | 永久重定向 | 请求的资源已永久移动到新位置,客户端应使用新的 URL。 | |
302 | 临时重定向 | 请求的资源临时移动到新位置,客户端应继续使用原 URL。 | |
304 | 未修改 | 资源未修改,客户端可以使用缓存的版本。 | |
307 | 临时重定向 | 与 302 类似,但要求客户端保持请求方法不变。 | |
308 | 永久重定向 | 与 301 类似,但要求客户端保持请求方法不变。 | |
4xx | 客户端错误 | 表示客户端发送的请求有错误,服务器无法处理。 | |
400 | 错误请求 | 请求无效,服务器无法理解(如参数错误)。 | |
401 | 未授权 | 请求需要身份验证,客户端未提供有效的凭据。 | |
403 | 禁止访问 | 服务器拒绝请求,客户端没有访问权限。 | |
404 | 未找到 | 请求的资源不存在。 | 最常见的客户端错误状态码。 |
405 | 方法不允许 | 请求的方法(如 GET、POST)不被服务器支持。 | |
408 | 请求超时 | 服务器等待请求时超时。 | |
429 | 请求过多 | 客户端发送的请求过多,被服务器限制。 | |
5xx | 服务器错误 | 表示服务器处理请求时发生错误。 | |
500 | 服务器内部错误 | 服务器遇到意外错误,无法完成请求。 | 最常见的服务器错误状态码。 |
501 | 未实现 | 服务器不支持请求的功能。 | |
502 | 错误网关 | 服务器作为网关或代理时,从上游服务器收到无效响应。 | |
503 | 服务不可用 | 服务器暂时不可用(通常由于过载或维护)。 | |
504 | 网关超时 | 服务器作为网关或代理时,未能及时从上游服务器收到响应。 | |
505 | HTTP 版本不支持 | 服务器不支持请求中使用的 HTTP 协议版本。 |
状态码分类
-
1xx(信息响应)
表示请求已被接收,继续处理。
-
2xx(成功响应)
表示请求已成功被服务器接收、理解并处理。
-
3xx(重定向)
表示需要客户端进一步操作以完成请求。
-
4xx(客户端错误)
表示客户端发送的请求有错误,服务器无法处理。
-
5xx(服务器错误)
表示服务器处理请求时发生错误。
常见状态码示例
成功
-
200 OK
请求成功,响应体中包含请求的结果。
-
201 Created
请求成功,并创建了新资源(通常用于 POST 请求)。
重定向
-
301 Moved Permanently
请求的资源已永久移动到新位置。
-
302 Found
请求的资源临时移动到新位置。
客户端错误
-
400 Bad Request
请求无效,服务器无法理解。
-
404 Not Found
请求的资源不存在。
服务器错误
-
500 Internal Server Error
服务器遇到意外错误,无法完成请求。
-
503 Service Unavailable
服务器暂时不可用(通常由于过载或维护)。
通过理解这些状态码,可以更好地调试和优化 HTTP 请求与响应。
HTTP/1.1 和 HTTP/2
HTTP/1.1 和 HTTP/2 是两种广泛使用的 HTTP 协议版本,它们在性能、效率和功能上有显著差异。以下是它们的详细说明及区别:
1. HTTP/1.1
-
发布时间:1997 年(RFC 2068)。
-
特点:
- 文本协议:HTTP/1.1 是基于文本的协议,消息以纯文本形式传输。
- 持久连接:支持持久连接(Keep-Alive),允许在单个 TCP 连接上发送多个请求。
- 管道化:支持请求管道化(Pipelining),但存在队头阻塞(Head-of-Line Blocking)问题。
- 无状态:每个请求都是独立的,服务器不保留客户端的状态信息。
- 头部冗余:每个请求都会携带完整的头部信息,导致冗余。
-
缺点:
- 性能瓶颈:由于队头阻塞和头部冗余,性能较低。
- 并发限制:浏览器通常对同一域名下的并发连接数有限制(如 6-8 个)。
2. HTTP/2
-
发布时间:2015 年(基于 Google 的 SPDY 协议)。
-
特点:
- 二进制协议:HTTP/2 使用二进制格式传输数据,解析效率更高。
- 多路复用:支持在单个 TCP 连接上并行发送多个请求和响应,解决了队头阻塞问题。
- 头部压缩:使用 HPACK 算法压缩头部,减少冗余。
- 服务器推送:服务器可以主动向客户端推送资源,减少延迟。
- 流优先级:支持为请求和响应设置优先级,优化资源加载顺序。
-
优点:
- 性能提升:多路复用和头部压缩显著提高了性能。
- 减少延迟:服务器推送和流优先级优化了页面加载速度。
- 更好的用户体验:适用于现代 Web 应用的高并发需求。
3. HTTP/1.1 和 HTTP/2 的区别
特性 | HTTP/1.1 | HTTP/2 |
---|---|---|
协议格式 | 文本格式 | 二进制格式 |
连接方式 | 支持持久连接,但并发连接数有限制 | 多路复用,单个连接支持并行请求 |
头部传输 | 每个请求携带完整头部,冗余较大 | 使用 HPACK 压缩头部,减少冗余 |
队头阻塞 | 存在队头阻塞问题 | 通过多路复用解决队头阻塞 |
服务器推送 | 不支持 | 支持服务器主动推送资源 |
流优先级 | 不支持 | 支持为请求和响应设置优先级 |
性能 | 较低 | 较高 |
兼容性 | 广泛支持 | 需要客户端和服务器同时支持 |
4. HTTP/2 的核心特性详解
1. 二进制分帧层
HTTP/2 将消息分解为二进制帧(Frame),每个帧属于一个流(Stream)。帧可以交错发送,接收方根据流 ID 重新组装。
2. 多路复用
在单个 TCP 连接上,客户端和服务器可以同时发送多个请求和响应,避免了 HTTP/1.1 中的队头阻塞问题。
3. 头部压缩
使用 HPACK 算法压缩头部,减少了重复头部字段的传输,降低了带宽占用。
4. 服务器推送
服务器可以主动向客户端推送资源,而无需客户端显式请求。例如,服务器可以在返回 HTML 页面的同时推送相关的 CSS 和 JavaScript 文件。
5. 流优先级
客户端可以为请求设置优先级,服务器根据优先级处理请求,优化资源加载顺序。
5. 示例对比
HTTP/1.1 的请求
http
GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html
GET /style.css HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/css
HTTP/2 的请求
HTTP/2 将上述请求分解为二进制帧,并通过单个连接并行发送:
- 帧 1:
GET /index.html
(流 ID: 1) - 帧 2:
GET /style.css
(流 ID: 3) - 帧 3:头部帧(流 ID: 1)
- 帧 4:头部帧(流 ID: 3)
6. 总结
- HTTP/1.1 是传统的文本协议,性能较低,但兼容性广泛。
- HTTP/2 是现代的二进制协议,性能显著提升,支持多路复用、头部压缩和服务器推送等功能。
随着现代 Web 应用对性能要求的提高,HTTP/2 已成为主流协议,但 HTTP/1.1 仍然在一些旧系统中使用。
请求转发与重定向
请求转发(Forward) 和 请求重定向(Redirect) 是 Web 开发中两种常见的请求处理方式,它们的主要区别在于 请求的发起者 和 浏览器的行为。以下是它们的详细说明和区别:
1. 请求转发(Forward)
-
定义 :
请求转发是服务器内部的行为,客户端(浏览器)只发起一次请求,服务器将请求转发给另一个资源(如 Servlet、JSP 或其他页面)进行处理,最终将结果返回给客户端。
-
特点:
- 客户端无感知:客户端不知道请求被转发,浏览器的 URL 不会改变。
- 一次请求:整个转发过程在服务器内部完成,客户端只发送一次请求。
- 共享请求数据:转发的目标资源可以访问原始请求的所有数据(如参数、属性等)。
- 效率较高:因为只涉及一次请求和响应。
-
使用场景:
- 在服务器端完成多个资源的协作处理。
- 隐藏实际处理资源的细节(如将请求转发到内部 API)。
-
示例:
- 在 Java Servlet 中,使用
RequestDispatcher.forward()
实现请求转发。
- 在 Java Servlet 中,使用
2. 请求重定向(Redirect)
-
定义 :
请求重定向是服务器告诉客户端(浏览器)去访问另一个 URL,客户端会发起一个新的请求到指定的 URL。
-
特点:
- 客户端感知:客户端知道请求被重定向,浏览器的 URL 会改变。
- 两次请求:客户端先发送第一次请求,服务器返回重定向响应(状态码 302),客户端再发送第二次请求到新的 URL。
- 不共享请求数据:重定向后的请求是一个全新的请求,原始请求的数据不会自动传递。
- 效率较低:因为涉及两次请求和响应。
-
使用场景:
- 需要改变浏览器的 URL(如登录后跳转到主页)。
- 需要将客户端引导到外部资源。
-
示例:
- 在 HTTP 响应中返回状态码 302 和
Location
头字段,指示客户端重定向到新的 URL。 - 在 Java Servlet 中,使用
HttpServletResponse.sendRedirect()
实现请求重定向。
- 在 HTTP 响应中返回状态码 302 和
3. 请求转发 vs 请求重定向
特性 | 请求转发(Forward) | 请求重定向(Redirect) |
---|---|---|
发起者 | 服务器内部完成,客户端无感知。 | 客户端发起新的请求。 |
请求次数 | 一次请求。 | 两次请求。 |
URL 变化 | 浏览器 URL 不变。 | 浏览器 URL 改变。 |
数据共享 | 转发的目标资源可以访问原始请求的数据。 | 重定向后的请求是一个全新的请求,数据不共享。 |
效率 | 较高(只涉及一次请求和响应)。 | 较低(涉及两次请求和响应)。 |
实现方式 | 服务器端实现(如 RequestDispatcher.forward() )。 |
客户端实现(如返回 302 状态码和 Location 头)。 |
使用场景 | 服务器内部协作处理,隐藏资源细节。 | 需要改变浏览器 URL 或引导到外部资源。 |
4. 示例对比
请求转发(Forward)
- 客户端请求
/page1
。 - 服务器将请求转发给
/page2
处理。 - 服务器将
/page2
的结果返回给客户端。 - 客户端看到的 URL 仍然是
/page1
。
请求重定向(Redirect)
- 客户端请求
/page1
。 - 服务器返回 302 状态码和
Location: /page2
。 - 客户端重新请求
/page2
。 - 客户端看到的 URL 变为
/page2
。
5. 总结
- 请求转发:适合服务器内部协作处理,客户端无感知,效率高。
- 请求重定向:适合需要改变浏览器 URL 或引导到外部资源的场景,客户端感知,效率较低。
根据具体需求选择合适的方式,可以更好地实现 Web 应用的功能。
socket与websocket
Socket 和 WebSocket 是两种不同的通信技术,尽管它们的名字相似,但它们的用途、协议和实现方式有显著区别。以下是它们的详细对比:
1. Socket
定义
- Socket 是一种通用的网络通信接口,提供了进程间通信(IPC)的机制,尤其是在网络环境中。
- Socket 可以基于多种协议(如 TCP、UDP)实现,适用于各种网络通信场景。
特点
- 底层通信:Socket 是操作系统提供的底层 API,直接操作网络协议栈。
- 灵活性:支持多种协议(TCP、UDP、RAW)和通信模式(阻塞、非阻塞、异步)。
- 适用范围广:可用于实现各种网络应用,如 HTTP、FTP、SMTP 等。
工作流程
- 创建 Socket。
- 绑定地址和端口(服务器)。
- 监听连接(服务器)。
- 建立连接(客户端)。
- 数据传输。
- 关闭连接。
示例
- TCP Socket:用于可靠的、面向连接的通信。
- UDP Socket:用于不可靠的、无连接的通信。
2. WebSocket
定义
- WebSocket 是一种基于 TCP 的应用层协议,提供了全双工通信机制,允许客户端和服务器之间进行实时、双向的数据交换。
- WebSocket 是 HTML5 规范的一部分,主要用于 Web 应用中的实时通信。
特点
- 基于 HTTP 升级:WebSocket 连接通过 HTTP 协议升级(Upgrade)建立。
- 全双工通信:客户端和服务器可以同时发送和接收数据。
- 低延迟:适用于实时性要求高的场景,如在线聊天、实时游戏。
- 消息帧:数据以消息帧(Message Frame)的形式传输,支持文本和二进制数据。
工作流程
- 客户端通过 HTTP 请求发起 WebSocket 握手。
- 服务器响应 HTTP 101(Switching Protocols)表示协议升级。
- 建立 WebSocket 连接,客户端和服务器可以双向通信。
- 数据传输。
- 关闭连接。
示例
- 在线聊天应用。
- 实时数据推送(如股票行情、体育比分)。
- 多人协作工具(如在线文档编辑)。
3. Socket 和 WebSocket 的区别
特性 | Socket | WebSocket |
---|---|---|
协议层级 | 传输层(TCP/UDP)或更低层(RAW)。 | 应用层(基于 TCP)。 |
通信模式 | 支持单向或双向通信,取决于协议(如 TCP/UDP)。 | 全双工通信。 |
连接建立 | 直接通过 TCP/UDP 建立连接。 | 通过 HTTP 协议升级(Upgrade)建立连接。 |
数据格式 | 原始字节流或数据报。 | 消息帧(支持文本和二进制数据)。 |
使用场景 | 通用网络通信(如 HTTP、FTP、SMTP)。 | Web 应用中的实时通信(如聊天、推送)。 |
复杂性 | 需要手动处理协议细节(如数据封装、错误处理)。 | 提供高层 API,简化了实时通信的实现。 |
兼容性 | 适用于各种网络应用。 | 主要用于 Web 应用,需要浏览器支持。 |
4. 示例对比
Socket 示例(TCP)
-
服务器端
pythonimport socket server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) server_socket.bind(('0.0.0.0', 8888)) server_socket.listen(5) client_socket, client_address = server_socket.accept() data = client_socket.recv(1024) print(f"收到数据: {data.decode()}") client_socket.send("Hello, Client!".encode()) client_socket.close() server_socket.close()
-
客户端
pythonimport socket client_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) client_socket.connect(('127.0.0.1', 8888)) client_socket.send("Hello, Server!".encode()) data = client_socket.recv(1024) print(f"收到数据: {data.decode()}") client_socket.close()
WebSocket 示例
-
服务器端(使用
websockets
库)pythonimport asyncio import websockets async def handle_connection(websocket, path): async for message in websocket: print(f"收到消息: {message}") await websocket.send("Hello, Client!") start_server = websockets.serve(handle_connection, "0.0.0.0", 8888) asyncio.get_event_loop().run_until_complete(start_server) asyncio.get_event_loop().run_forever()
-
客户端(JavaScript)
javascriptconst ws = new WebSocket("ws://127.0.0.1:8888"); ws.onopen = () => { ws.send("Hello, Server!"); }; ws.onmessage = (event) => { console.log(`收到消息: ${event.data}`); };
5. 总结
- Socket 是底层的网络通信接口,支持多种协议和通信模式,适用于各种网络应用。
- WebSocket 是基于 TCP 的应用层协议,提供了全双工通信机制,主要用于 Web 应用中的实时通信。
根据具体需求选择合适的技术:
- 如果需要实现通用的网络通信,使用 Socket。
- 如果需要实现 Web 应用中的实时通信,使用 WebSocket。