HTTP版本介绍
A.Http0.9版本
0.9是鼻祖版本，它的主要特点包括：
- 请求方法支持有限
只支持GET请求方式，不支持其他请求方式 因此客户端向服务端传输信息的量非常有限，也就是现在常用的Post请求无法使用 - 不支持请求头header
不能在请求中指定版本号，服务端只具有返回HTML字符串的能力 - 响应即关闭
服务端相响应之后，立即关闭TCP连接
B.Http1.0版本
1.0版本主要是对0.9版本的强化，效果也比较明显，主要特性和缺点包括：
- 丰富请求方法
请求方式新增了POST，DELETE，PUT，HEADER等方式，提高了客户端向服务端发送信息的量级 - 增加请求头和响应头
增添了请求头和响应头的概念，可以在通信中指定了HTTP协议版本号，以及其他header信息，使得C/S交互更加灵活方便 - 丰富数据传输内容
扩充了传输内容格式包括：图片、音视频资源、二进制等都可以进行传输，相比0.9的只能传输html内容让http的应用场景更多 - 链接复用性差
1.0版本中每个TCP连接只能发送一个请求，数据发送完毕连接就关闭，如果还要请求其他资源，就必须重新建立连接。TCP为了保证正确性和可靠性需要客户端和服务器三次握手和四次挥手，因此建立连接成本很高，基于拥塞控制开始时发送速率较慢，所以1.0版本的性能并不理想。 - 无状态无连接的弊端
1.0版本是无状态且无连接的，换句话说就是服务器不跟踪不记录请求过的状态，客户端每次请求都需要建立tcp连接不能复用，并且1.0规定在前一个请求响应到达之后下一个请求才能发送，如果前一个阻塞后面的请求就会被阻塞。 丢包和乱序问题和高成本的链接过程让复用和队头阻塞产生很多问题，所以无连接无状态是1.0版本的一个弱肋。
C.Http1.1版本
1.1版本在1.0版本发布后大约1年就推出了，是对1.0版本的优化和完善，1.1版本的主要特点包括：
- 增加长连接
新增Connection字段，可以设置keep-alive值保持连接不断开，即 TCP 连接默认不关闭，可以被多个请求复用，这也是1.1版本很重要的优化，但是在S端服务器只有处理完一个回应，才会进行下一个回应。要是前面的回应特别慢，后面就会有许多请求排队等着，仍然存在队头阻塞问题。 - 管道化
在长连接的基础上，管道化可以不等第一个请求响应继续发送后面的请求，但响应的顺序还是按照请求的顺序返回，即在同一个TCP连接中，客户端可以同时发送多个请求，进一步改进了HTTP协议的传输效率。 - 更多的请求方法
增加了 PUT、PATCH、OPTIONS、DELETE 等请求方式。 - host字段
Host字段用来指定服务器的域名，这样就可以将多种请求发往同一台服务器上的不同网站，提高了机器的复用，这个也是重要的优化
D.Http2.0版本
2.0版本是个里程碑式的版本，相比1.x版本有了非常多的优化去适应当前的网络场景，其中几个重要功能点包括：
- 二进制格式
1.x是文本协议，然而2.0是以二进制帧为基本单位，可以说是一个二进制协议，将所有传输的信息分割为消息和帧，并采用二进制格式的编码，一帧中包含数据和标识符，使得网络传输变得高效而灵活。 - 多路复用
这是一个非常重要的改进，1.x中建立多个连接的消耗以及效率都存在问题，2.0版本的多路复用多个请求共用一个连接，多个请求可以同时在一个TCP连接上并发，主要借助于二进制帧中的标识进行区分实现链路的复用。 - 头部压缩
2.0版本使用使用HPACK算法对头部header数据进行压缩，从而减少请求的大小提高效率，这个非常好理解，之前每次发送都要带相同的header，显得很冗余，2.0版本对头部信息进行增量更新有效减少了头部数据的传输。 - 服务端推送
这个功能有点意思，之前1.x版本服务端都是收到请求后被动执行，在2.0版本允许服务器主动向客户端发送资源，这样在客户端可以起到加速的作用。
E.Http3.0版本
HTTP3.0又称为HTTP Over QUIC，其弃用TCP协议，改为使用基于UDP协议的QUIC协议来实现。QUIC其实是Quick UDP Internet Connections的缩写，直译为快速UDP互联网连接。它是 Google 提出来的一个基于 UDP 的传输协议。HTTP 3.0 于 2022 年 6 月 6 日正式发布，IETF 把 HTTP 3.0 标准制定在了 RFC 9114 中。
使用QUIC的优势
-
使用 UDP 协议，不需要三次连接进行握手，而且也会缩短 TLS 建立连接的时间。
-
解决了队头阻塞问题。
-
实现动态可插拔，在应用层实现了拥塞控制算法，可以随时切换。
-
报文头和报文体分别进行认证和加密处理，保障安全性。
-
连接能够平滑迁移。
WebSocket
WebSocket 是一个双向通信协议，它在握手阶段采用 HTTP/1.1 协议（暂时不支持 HTTP/2）。先通过HTTP/HTTPS协议发起一条特殊HTTP请求进行握手后创建一个用于交换数据的TCP连接，也是支持长连接的。WebSocket是由HTTP先发起的，然后在转为WebSocket。
WebSocket协议的特点
- 建立在 TCP 协议之上，它需要通过握手连接之后才能通信，服务器端的实现比较容易。
- 与 HTTP 协议有着良好的兼容性。默认端口也是80或443，并且握手阶段采用 HTTP 协议，因此握手时不容易屏蔽，能通过各种 HTTP 代理服务器。
- 数据格式比较轻量，性能开销小，通信高效。可以发送文本，也可以发送二进制数据。
- 没有同源限制，客户端可以与任意服务器通信。
- 协议标识符是ws（如果加密，则为wss），服务器网址就是URL。（例如：ws://www.example.com/chat）
- 它是一种双向通信协议，采用异步回调的方式接受消息，当建立通信连接，可以做到持久性的连接，WebSocket服务器和Browser都能主动的向对方发送或接收数据，实质的推送方式是服务器主动推送，只要有数据就推送到请求方。
握手过程
首先客户端向服务端发起一个特殊的 HTTP 请求.如果服务端支持该版本的 WebSocket，会返回 101 响应,握手完成后，接下来的 TCP 数据包就都是 WebSocket 协议的帧了。如图所示：
HTTP1.1与WebSocket的异同
最后，作为总结，让我们再来回顾一下HTTP1.1与WebSocket的相同与不同。加深对WebSocket的理解。
协议层面的异同
相同点
- 都是基于TCP的应用层协议。
- 都使用Request/Response模型进行连接的建立。
- 在连接的建立过程中对错误的处理方式相同，在这个阶段WebSocket可能返回和HTTP相同的返回码。
不同点
- HTTP协议基于Request/Response，只能做单向传输，是半双工协议，而WebSocket是全双工协议，类似于Socket通信，双方都可以在任何时刻向另一方发送数据。
- WebSocket使用HTTP来建立连接，但是定义了一系列新的Header域，这些域在HTTP中并不会使用。换言之，二者的请求头不同。
- WebSocket的连接不能通过中间人来转发，它必须是一个直接连接。如果通过代理转发，一个代理要承受如此多的WebSocket连接不释放，就类似于一次DDOS攻击了。
- WebSocket在建立握手连接时，数据是通过HTTP协议传输的，但在建立连接之后，真正的数据传输阶段是不需要HTTP协议参与的。
- WebSocket传输的数据是二进制流，是以帧为单位的，HTTP传输的是明文传输，是字符串传输，WebSocket的数据帧有序
websocket与HTTP的关系可以参考下图
WebSockets 最初是为 HTTP/1.1 设计的，但后来改用于 HTTP/2。
.NET 7 为 Kestrel、SignalR JavaScript 客户端和带有 Blazor WebAssembly 的 SignalR 引入了基于 HTTP/2 的 Websockets 支持。
HTTP/2 WebSockets 使用 CONNECT 请求而不是 GET，因此可能需要更新你自己的路由和控制器。
SignalR
ASP.NET Core SignalR 是一个开放源代码库，可用于简化向应用添加实时 Web 功能。 实时 Web 功能使服务器端代码能够将内容推送到客户端。按照我的理解也是基于Http2.0的消息传输框架。
适合 SignalR 的候选项：
- 需要从服务器进行高频率更新的应用。 示例包括游戏、社交网络、投票、拍卖、地图和 GPS 应用。
- 仪表板和监视应用。 示例包括公司仪表板、即时销售更新或旅行警报。
- 协作应用。 协作应用的示例包括白板应用和团队会议软件。
- 需要通知的应用。 社交网络、电子邮件、聊天、游戏、旅行警报和很多其他应用都需使用通知。
SignalR 提供用于创建服务器到客户端远程过程调用（RPC） 的 API。 RPC 从服务器端 .NET Core 代码调用客户端上的函数。 提供多个受支持的平台，其中每个平台都有各自的客户端 SDK。 因此，RPC 调用所调用的编程语言有所不同。
以下是 ASP.NET Core SignalR 的一些功能：
- 自动处理连接管理。
- 同时向所有连接的客户端发送消息。 例如聊天室。
- 向特定客户端或客户端组发送消息。
- 对其进行缩放，以处理不断增加的流量。
- SignalR中心协议
传输
SignalR 支持以下用于处理实时通信的技术（按正常回退的顺序）：
- WebSockets
- Server-Sent Events
- 长轮询
SignalR 自动选择服务器和客户端能力范围内的最佳传输方法。
中心
SignalR 使用中心在客户端和服务器之间进行通信。
Hub 是一种高级管道，允许客户端和服务器相互调用方法。 SignalR 自动处理跨计算机边界的调度，并允许客户端调用服务器上的方法，反之亦然。 可以将强类型参数传递给方法，从而支持模型绑定。 SignalR 提供两个内置中心协议：基于 JSON 的文本协议和基于 MessagePack的二进制协议。相比 JS，MessagePack 通常会创建较小的消息。
中心通过发送包含客户端方法的名称和参数的消息来调用客户端代码。 作为方法参数发送的对象使用配置的协议进行反序列化。 客户端尝试将名称与客户端代码中的方法匹配。 当客户端找到匹配项时，它会调用该方法并将反序列化的参数数据传递给它。
GRPC
概述
GRPC是一个高性能、通用的开源RPC框架，基于底层HTTP/2协议标准和协议层Protobuf序列化协议开发，支持众多的开发语言。
gRPC 也是基于以下理念：定义一个服务，指定其能够被远程调用的方法（包含参数和返回类型）。在服务端实现这个接口，并运行一个 gRPC服务器来处理客户端调用。在客户端拥有一个存根能够像服务端一样的方法。
gRPC使用protocol buffers作为接口描述语言（IDL）以及底层的信息交换格式
优点
- 基于 HTTP/2 之上的二进制协议（Protobuf 序列化机制）；
- 一个连接上可以多路复用，并发处理多个请求和响应；
- 多种语言的类库实现；
- 服务定义文件和自动代码生成（.proto 文件和 Protobuf 编译工具）。
- RPC 还提供了很多扩展点，用于对框架进行功能定制和扩展，例如，通过开放负载均衡接口可以无缝的与第三方组件进行集成对接（Zookeeper、域名解析服务、SLB 服务等）