登录/ 注册
 找回密码
 立即注册
关闭

CSDN热搜

程序园 精品问答 技术交流 资源下载
返回列表 发新帖
首页 › 业界区 › 业界 ›C#网络编程(三)----HTTP协议

C#网络编程(三)----HTTP协议

殳世英 7 天前
HTTP协议

HTTP(超文本传输协议)，属于应用层协议。基于TCP连接实现。但通信方向始终由客户端发起（HTTP/2之后已修改）。
维度TCP/IP协议族（传输层/TCP）HTTP协议（应用层）通信方向全双工（双向同时通信）单向（客户端→服务器请求，服务器响应）协议层次传输层（负责数据传输可靠性）应用层（定义数据格式和业务逻辑）典型场景基础网络通信（如文件传输、邮件）客户端获取服务器资源（如网页访问）主动通信能力双方均可主动发送数据仅客户端可主动发起请求HTTP报文结构

分为请求报文与响应报文，但结构类似，都由报文首部，空行(标识首部结束)与报文主体。
请求报文：
  1. /*HTPP协议的版本*/
  2. GET / HTTP/1.1
  3. /*客户端支持的内容类型*/
  4. Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
  5. /*客户端支持的内容编码类型*/
  6. Accept-Encoding: gzip, deflate, br, zstd
  7. /*客户端支持的语言*/
  8. Accept-Language: zh-CN,zh;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6
  9. /*缓存控制，0代表不使用缓存*/
  10. Cache-Control: max-age=0
  11. /*连接方式，keep-alive即持久连接*/
  12. Connection: keep-alive
  13. /*请求的主机名*/
  14. Host: www.baidu.com
复制代码
响应报文
  1. /*HTTP协议版本及状态码，表明使用HTTP/1.1协议，请求成功*/
  2. HTTP/1.1 200 OK
  3. /*连接方式，保持TCP连接持久化，便于后续请求复用连接*/
  4. Connection: keep-alive
  5. /*响应内容的编码方式，使用gzip压缩*/
  6. Content-Encoding: gzip
  7. /*响应内容的类型及字符编码，内容为HTML，编码是UTF-8*/
  8. Content-Type: text/html; charset=utf-8
  9. /*服务器生成响应的时间（格林尼治标准时间）*/
  10. Date: Sun, 27 Apr 2025 04:11:28 GMT
  11. /*服务器软件信息，使用百度Web服务器，版本1.1*/
  12. Server: BWS/1.1
  13. /*设置Cookie，H_PS_PSSID用于存储用户会话标识，指定路径、过期时间和域名*/
  14. Set-Cookie: H_PS_PSSID=61027_61673_62325_62337_62831_62863_62877_62885_62928_62969_63040_63050_63073; path=/; expires=Mon, 27-Apr-26 04:11:28 GMT; domain=.baidu.com
  15. /*设置Cookie，BDSVRTM用于百度统计相关，指定路径*/
  16. Set-Cookie: BDSVRTM=5; path=/
  17. /*设置Cookie，BD_HOME标识是否为百度首页访问，指定路径*/
  18. Set-Cookie: BD_HOME=1; path=/
  19. /*启用严格传输安全，强制浏览器在一定时间（172800秒）内通过HTTPS连接*/
  20. Strict-Transport-Security: max-age=172800
  21. /*百度内部请求追踪ID，用于全链路性能监控和问题定位*/
  22. Traceid: 1745727088348548045813596150688561061649
  23. /*建议浏览器使用Edge或Chrome内核渲染页面，提升兼容性*/
  24. X-Ua-Compatible: IE=Edge,chrome=1
  25. /*启用跨站脚本攻击防护，当检测到可疑脚本时直接阻止渲染*/
  26. X-Xss-Protection: 1;mode=block
  27. /*响应采用分块传输，大文件分段发送以提升传输可靠性*/
  28. Transfer-Encoding: chunked
复制代码
报文主体(可选)
具体的响应内容，不一定要有值。比如204 No Content状态码的响应
  1. <html>
  2.     <head>
  3.         <meta name="description" content="全球领先的中文搜索引擎、致力于让网民更便捷地获取信息，找到所求。百度超过千亿的中文网页数据库，可以瞬间找到相关的搜索结果。">
  4.         <title>百度一下，你就知道</title>
  5.         </head>
  6.         <body>
  7.         </body>
  8. </html>
复制代码
HTTP各版本之间的区别

HTTP/0.9

HTPP协议的第一个版本，诞生于1991年。是一种非常简单的协议，主要用于传输纯文本HTML页面。
功能很单一，只支持GET请求。属于三无产品，无请求头，无响应头，无状态码。
HTTP/1.0

为了解决上述缺点，于1996年发布了HTTP/1.0版。
引入了POST/HEAD等方法，丰富了交互方式；
引入了请求头与响应头，实现了与正文的解耦；
引入了状态码，用于表示请求结果；
HTTP/1.0默认短连接，每一个请求都是独立的握手/挥手的过程，每个HTTP请求完成后，连接都会被关闭，效率很低。
如果你打开一个网页，该网页有10000个CSS/JS ，那么将会瞬间占满整个服务器资源。
1.png

HTTP/1.1

为了进一步优化性能和功能，随即在1997年发布了HTTP/1.1版
默认持久连接：keep-alive，允许一个TCP连接上发送多个请求和响应，减低了服务器监听TCP连接的压力，提高传输效率；
请求头压缩：通过压缩请求头，减少请求头大小，降低传输压力。
分块传输：Transfer - Encoding: chunked 允许服务器在数据未完全生成时就开始传输，提高效率。
缓存机制：Cache - Control、ETag
虚拟主机：Host，允许服务器托管多个域名。
Method增强：新增PUT，DELET，OPTIONS等方法请求
2.png

google浏览器默认为一个域名建立6条连接，所有文件传输都使用这六条连接复用。
常见优化思路：

  • 减少请求数量
    将资源文件(css,js等)合并
  • 增减连接数量
    将资源分散到不同域名下，以绕开浏览器对同一个域名的最大连接限制。
HTTP性能的关键在于低延迟而不是高宽带，以上优化，治标不治本。并没有完全解决这些问题。
HTTP/2

随着互联网发展，移动互联网与高并发场景的增加。HTTP/1.1逐渐暴露了性能瓶颈，在2015年发布了HTTP/2版本。
HTTP/2抽象出了Stream的概念，实现了并发传输，一个Stream就相当于HTTP/1.1的请求和响应

  • 二进制分帧：
    HTTP/1.1 以纯文本传输数据（如请求行、头部、实体），解析效率低且易出错；
    HTTP/2 将所有数据（包括请求、响应、头部、实体）分割为 二进制帧（Frame），二进制格式更紧凑、解析更快，且消除了文本解析的歧义
  • 多路复用：
    HTTP/1.1 依赖多个 TCP 连接或长连接（Keep-Alive）处理并发请求，但存在 队头阻塞。HTTP/2 通过 单个 TCP 连接 同时发送多个请求 / 响应，每个请求 / 响应称为一个 流（Stream），以唯一 ID 区分，帧可交错传输，接收端按流重组数据
  • 头部压缩：
    HTTP/2 使用 HPACK 算法，通过 静态字典（预定义常用头部）和 动态字典（记录此次连接中出现的新头部）对头部进行压缩，减少传输数据量。
  • 服务器推送：
    服务端可以主动向客户端推送资源，提前将客户端可能需要的资源发送给客户端，减少等待时间。
    比如客户端请求 index.html，服务器在响应 HTML 的同时，推送页面所需的 style.css 和 script.js，减少客户端的往返时间（RTT）。
    3.png

HTTP2在应用层与传输层之间增加了二进制分帧层，将HTTP协议由文本协议转为了二进制协议。从而实现乱序请求与响应，之前的文本协议是做不到的。
4.png

HTTP/3

尽管 HTTP/2 解决了 HTTP/1.1 的一些性能问题，但它仍然依赖于 TCP 协议，而 TCP 协议存在一些固有的缺陷，如TCP队头阻塞，握手挥手成本较大等问题。为了解决这些问题，在 2022 年发布了 HTTP/3 版本。
HTTP/3 放弃了 TCP，转而基于 QUIC（Quick UDP Internet Connections），这是其与 HTTP/2 的根本区别。QUIC 是一个运行在 UDP 之上的通用传输层协议，集成了传输控制、加密和多路复用功能

  • 基于 UDP 的快速连接建立：
    HTTP/2摆脱不了TCP，建立握手需要2-3个RTT，而QUIC只需要一个RTT
    5.png

  • 无队头阻塞的多路复用：
    HTTP/2虽然在应用层实现了多路复用，但受限于 TCP 单个连接，若 TCP 数据包丢失，滑动窗口无法向前移动，因此所有流都会阻塞。
    QUIC则是给每个Stream都分配了一个独立的滑动窗口，这样使得同一个连接数的多个Stream之间没有依赖关系，互联独立控制滑动窗口，从而实现真正意义上的多路复用。
    6.png

  • 改进的拥塞控制与可靠性：
    QUIC 使用 版本化的 ACK 机制，精确记录每个数据包的接收情况，避免 TCP 因序列号混乱导致的误判。支持多种算法（如 Cubic、BBR），并可动态调整，适应高丢包率网络（如移动蜂窝网络）。
  • 内置加密与安全：
    QUIC 继承 TLS 1.3 的加密能力，所有传输数据（包括握手过程和载荷）均经过加密，避免中间设备篡改或监听。
    TLS 1.3 的简化握手流程与 QUIC 深度整合，减少加密带来的性能损耗。
特性HTTP/1.1HTTP/2HTTP/3 (QUIC)发布时间1997年（RFC 2616，后续修订）2015年（RFC 7540）2022年（RFC 9000，基于 QUIC）应用层协议基于 TCP基于 TCP基于 UDP（通过 QUIC 实现可靠传输）传输层协议TCPTCPUDP + QUIC 协议（内置 TLS 加密）多路复用每个请求单独建立 TCP 连接，
通过 Connection: keep-alive 复用连接，
但存在连接级队头阻塞（同一连接中请求需按顺序处理）二进制分帧（Binary Framing），
单个 TCP 连接中多路复用多个请求/响应，
消除连接级队头阻塞，但流内仍有队头阻塞QUIC 基于 UDP，每个流（Stream）独立传输，
流之间互不阻塞，
完全消除连接级和流级队头阻塞头部压缩无专用头部压缩，仅支持 gzip 等通用压缩（开销大）引入 HPACK 算法，对头部字段进行索引和霍夫曼编码，大幅减少头部开销基于 QUIC 的头部压缩（类似 HPACK），
支持动态表管理，压缩效率与 HTTP/2 相近连接建立TCP 三次握手（1 RTT），
TLS 需额外 1-2 RTT（如 TLS 1.2）TCP 三次握手（1 RTT），
TLS 通过 ALPN 协商（1 RTT，TLS 1.3 优化后）QUIC 握手集成 TLS 加密，
首次连接 1 RTT，
会话恢复可实现 0 RTT（安全模式下有限制）安全性明文传输（HTTPS 需额外 TLS 层），
默认不加密支持明文（http://），但推荐 HTTPS（https://）强制加密（基于 TLS 1.3，QUIC 内置加密），
无明文传输模式流控制基于 TCP 协议的流控制（窗口机制）新增 HTTP 层流控制，
支持连接级和流级独立控制（窗口机制）QUIC 层流控制（基于 UDP 的窗口机制），
更精细的流和连接级控制优先级与依赖处理无显式优先级，资源按请求顺序加载支持请求优先级（通过流优先级标记），
允许服务器优先处理关键资源继承 HTTP/2 的优先级机制，
基于 QUIC 流的优先级管理队头阻塞连接级和请求级均存在（同一连接中请求阻塞会影响后续请求）连接级消除，但流内请求仍可能阻塞（单个流内包丢失会阻塞该流）完全消除（每个流独立，流间包丢失不互相影响）协议升级方式无内置升级机制，需手动切换（如 HTTP 到 HTTPS）通过 ALPN（Application-Layer Protocol Negotiation）在 TLS 握手时协商升级通过 QUIC 版本协商（UDP 端口 443，兼容现有防火墙），
支持动态版本更新错误恢复与重传依赖 TCP 的重传机制（慢启动、拥塞控制）同 TCP 机制，
但 HTTP/2 帧级重传需依赖 TCP 层QUIC 内置多路复用和独立流控制，
单个流的包丢失仅重传该流数据，
拥塞控制更灵活（如 ECMP 多路径传输）服务器推送不支持支持（Server Push），可主动推送资源到客户端理论上支持，但 QUIC 层未显式定义，
实际应用较少默认端口80（明文）、443（HTTPS）80（明文）、443（HTTPS）（与 HTTP/1.1 兼容）443（强制加密，复用 HTTPS 端口，
也可支持其他端口，但推荐 443）适用场景老旧系统、低并发场景高并发网站、需要减少延迟的场景（如单页应用）高延迟或网络不稳定环境（如移动网络、物联网），
追求极速连接和低延迟的场景主要优势兼容性强，实现简单减少连接数、降低延迟、提升吞吐量更快的连接建立、抗网络拥塞、消除队头阻塞主要劣势高延迟、队头阻塞严重、头部开销大仍依赖 TCP，受限于 TCP 固有缺陷（如队头阻塞在流内残留）基于 UDP，可能受防火墙限制，
实现复杂度高为什么不升级TCP协议而是QUIC协议?

TCP也在升级进化，Fast Open可以缩短连接建立时间，BBR算法可以避免拥塞和滑动窗口阻塞问题。这些都可以大大提高TCP协议的处理速度。
主要原因在于历史包袱，因为TCP协议的处理和由操作系统内核来实现的，属于内核态，所以海量的旧设备无法享受到新技术带来的便利，而QUIC协议是用户态协议，升级成本相对较低。
TCP的各种机制在诞生之初，是为了在不丢失的情况下最大化使用带宽极限，随着互联网基建的完善，现代宽带的链路已经很稳定了，之前的慢启动，拥塞控制机制反而会称为拖累，尽管后续衍生出了cwnd，快速重传，快速恢复等加快传输速度的优化，但依旧不如直接使用UDP+应用层协议，后者更加符合现代互联网的实际情况
HTTP是无状态的短链接，而TCP的优势是大文件传输(长连接)，所以基于TCP的HTTP天生就有不适应的地方
QUIC的本质，就是在UDP上重新做了一个类似TCP的轮子，把之前要在内核态控制的逻辑挪到用户态，然后再适配HTTP的特性。
HTTP请求方式

方法作用场景是否幂等GET请求资源，无请求体(并不强制)页面浏览，API数据查询幂等，多次请求结果一致，不修改服务器状态POST提交数据，有请求头登录，评论等创建资源行为非幂等，多次请求创建多个资源PUT更新资源，全量更新文件内容替换幂等，全局替换，资源最终状态一致PATCH更新资源，部分更新更新用户名，修改密码，更新订单状态非幂等，可能包含增量，比如修改次数等，多次执行结果可能不同DELETE删除指定资源删除博客，删除订单，用户注销幂等，最终状态均为不存在HEAD仅获取响应头部(不返回主体)检查资源是否存在及元信息幂等，仅获取响应头，不修改服务器OPTIONS查看服务器支持的HTTP方法请求前的检查幂等，用于查询服务器支持的请求方法和跨域配置，不修改服务器CONNECT建立一个到目标资源的隧道用于在客户端和服务器之间进行加密的隧道传输,.通常用于 SSL/TLS 代理未定义，仅用于建立隧道，理论上是幂等TRANCE显示服务器收到的请求主要用于测试与调试，大多数服务器都会禁用TRANCE幂等，仅回显，不修改服务器HTTP响应码

基于 **RFC 7231/7232/7233 等规范
类别含义首位数字典型场景信息性请求已接收，继续处理1xx101 Switching Protocols（协议升级）成功请求已成功处理2xx200 OK、201 Created重定向需要进一步操作以完成请求3xx301 Moved Permanently、302 Found客户端错误请求存在语法错误或无法处理4xx404 Not Found、403 Forbidden服务器错误服务器处理请求时发生错误5xx500 Internal Server Error
老八股文了，大模型会更详细，不再赘述。
RESTFUL个人使用经验(未必正确)

在实践RESTFUL过程中，如果严格按照RESTFUL标准，无疑增加与前端对接的成本。
约定优于配置，因此团队内部只使用几个特定状态码，避免没有必要的沟通。
200:表示成功，响应中会返回具体信息，不再区分200,201,204
304:API缓存，响应中会返回具体信息。
400:业务异常，响应中会返回具体信息，401，403状态码由Gateway处理，微服务不再鉴权重复鉴权。
500:服务器异常
其它冷门状态码会被Gateway所处理
番外

Socket与Websocket的区别?

Socket是网络编程的一个抽象概念，一套标准。借助Socket，开发者能够在不同主机间实现通信，屏蔽细节。它的主流实现都是基于TCP/IP协议。
WebSocket则是建立在HTTP协议之上，由 HTML5 提出，目的是为了解决HTTP协议只能单向通信的问题，属于应用层协议。
GET请求长度限制？

GET请求有最大长度限制，这是一个流传很久的都市谣言。
事实上，W3C组织从来没有对GET长度做出要求，真正限制GET长度的是浏览器(IE，Chrome,FireFox)与服务器(Nginx，Tomcat，Kestrel)。
目前使用最广泛的HTTP协议？

https://w3techs.com/technologies/history_overview/site_element/all
7.png

截至 2025 年，全球前 1000 大网站中约 30% 已部署 HTTP/3，主要集中在大型 CDN 和对性能敏感的应用（如 Google、Netflix），但仍低于 HTTP/2 的普及率（约 80%）

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

使用道具 举报
相关推荐
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 | 立即注册
发帖
殳世英
7 天前

0

粉丝关注

8

主题发布

板块介绍填写区域，请于后台编辑
微信扫一扫