HTTP与HTTPS

HTTP

HTTP是超文本传输协议，是互联网上应用最为广泛的一种网络协议。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。 HTTP协议特点:

  1. HTTP是无状态的：无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

  2. HTTP是媒体独立的：这意味着，只要客户端和服务器知道如何处理数据内容，任何类型的数据都可以通过HTTP发送。客户端以及服务器指定使用适合的MIME-type内容类型。

  3. HTTP是无连接的：无连接是指每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。

  4. HTTP是灵活的：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。

  5. HTTP是支持客户端/服务器模式的：HTTP协议通信时，总是由客户端主动请求，服务器被动响应。 HTTP 缓存有两种实现方式，分别是强制缓存和协商缓存。 HTTP 最突出的优点是「简单、灵活和易于扩展、应用广泛和跨平台」 HTTP 协议里有优缺点一体的双刃剑，分别是「无状态、明文传输」，同时还有一大缺点「不安全」 对于无状态的问题，解法方案有很多种，其中比较简单的方式用 Cookie 技术。Cookie 通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。在客户端第一次请求后，服务器会下发一个装有客户信息的「小贴纸」，后续客户端请求服务器的时候，带上「小贴纸」，服务器就能认得了了， cookie技术

早期 HTTP/1.0 性能上的一个很大的问题，那就是每发起一个请求，都要新建一次 TCP 连接（三次握手），而且是串行请求，做了无谓的 TCP 连接建立和断开，增加了通信开销。

为了解决上述 TCP 连接问题，HTTP/1.1 提出了长连接的通信方式，也叫持久连接。这种方式的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。 为了解决上述 TCP 连接问题，HTTP/1.1 提出了长连接的通信方式，也叫持久连接。这种方式的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。

Q1:HTTP/1.1 的缺点有哪些？ A1:HTTP/1.1 主要有如下几个缺点：

  1. HTTP/1.1 仍然是无状态的，每次请求都需要携带身份认证信息，增加了额外的开销。

  2. HTTP/1.1 的队头阻塞问题，即同一时间只能处理一个请求，其余请求需要等待，降低了并发性能。

  3. HTTP/1.1 的安全问题，由于明文传输，容易被窃听和篡改，存在安全隐患。

连接复用(长连接)：HTTP/1.1的持久连接（长连接）机制是由客户端发起连接并在同一连接上进行多次请求来实现的。具体来说，客户端会建立一个TCP连接，然后在这个连接上连续发送多个HTTP请求，服务器在处理完每个请求后不会立即关闭连接，而是保持连接打开以等待后续请求。

管道（pipeline）网络传输：在同一个 TCP 连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。但是服务器必须按照接收请求的顺序发送对这些管道化请求的响应。如果服务端在处理 A 请求时耗时比较长，那么后续的请求的处理都会被阻塞住，这称为「队头堵塞」。所以，HTTP/1.1 管道解决了请求的队头阻塞，但是没有解决响应的队头阻塞，即客户端可以通过一个连接同时发送多个请求，但是服务端只能一个一个做出响应。 虽然HTTP/1.1支持管道化技术，但由于兼容性和性能问题，它没有被广泛采用。

队头阻塞：客户端通过同一个TCP连接连续发送多个HTTP请求，当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一同被阻塞了，会招致客户端一直请求不到数据。

HTTP/1.1 的性能一般般，后续的 HTTP/2 和 HTTP/3 就是在优化 HTTP 的性能。

HTTPS

HTTPS（全称：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。HTTPS协议的主要作用是：建立一个信息安全通道，来保证数据传输的安全。 HTTPS和HTTP的区别主要如下：

  1. HTTPS需要到CA申请证书，一般免费证书很少，需要交费。

  2. HTTP是超文本传输协议，信息是明文传输，HTTPS则是具有安全性的SSL加密传输协议。

  3. HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

  4. HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费。

  5. HTTP协议运行在TCP之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有传输的内容都经过加密，加密后的信息可以被任何人读取，但是只有用SSL/TLS的密钥才能解密，所以HTTPS可以防止数据在传输过程中被窃取、改变，确保了数据的完整性。

  6. HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费。

HTTP 由于是明文传输，所以安全上存在以下三个风险：

  • 窃听风险，比如通信链路上可以获取通信内容，用户号容易没。

  • 篡改风险，比如强制植入垃圾广告，视觉污染，用户眼容易瞎。

  • 冒充风险，比如冒充淘宝网站，用户钱容易没。

HTTPS 在 HTTP 与 TCP 层之间加入了 SSL/TLS 协议，可以很好的解决了上述的风险：

  • 混合加密的方式实现信息的机密性，解决了窃听的风险。

  • 摘要算法的方式来实现完整性，它能够为数据生成独一无二的「指纹」，指纹用于校验数据的完整性，解决了篡改的风险。

  • 将服务器公钥放入到数字证书中，解决了冒充的风险。 对称加密只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换。 非对称加密使用两个密钥：公钥和私钥，公钥可以任意分发而私钥保密，解决了密钥交换问题但速度慢。 通过哈希算法可以确保内容不会被篡改，但是并不能保证「内容 + 哈希值」不会被中间人替换，因为这里缺少对客户端收到的消息是否来源于服务端的证明。 那为了避免这种情况，计算机里会用非对称加密算法来解决，共有两个密钥： 一个是公钥，这个是可以公开给所有人的； 一个是私钥，这个必须由本人管理，不可泄露。 这两个密钥可以双向加解密的，比如可以用公钥加密内容，然后用私钥解密，也可以用私钥加密内容，公钥解密内容。 公钥加密，私钥解密。这个目的是为了保证内容传输的安全，因为被公钥加密的内容，其他人是无法解密的，只有持有私钥的人，才能解密出实际的内容； 私钥加密，公钥解密。这个目的是为了保证消息不会被冒充，因为私钥是不可泄露的，如果公钥能正常解密出私钥加密的内容，就能证明这个消息是来源于持有私钥身份的人发送的。 一般我们不会用非对称加密来加密实际的传输内容，因为非对称加密的计算比较耗费性能的。

所以非对称加密的用途主要在于通过「私钥加密，公钥解密」的方式，来确认消息的身份，我们常说的数字签名算法，就是用的是这种方式，不过私钥加密内容不是内容本身，而是对内容的哈希值加密。 数字签名 数字证书工作流程 通过数字证书的方式保证服务器公钥的身份，解决冒充的风险。

HTTP的演变

HTTP/1.1 相比 HTTP/1.0 性能上的改进：

  • 使用长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。

  • 支持管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。 但 HTTP/1.1 还是有性能瓶颈：

  • 请求 / 响应头部（Header）未经压缩就发送，首部信息越多延迟越大。只能压缩 Body 的部分；

  • 发送冗长的首部。每次互相发送相同的首部造成的浪费较多；

  • 服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端一直请求不到数据，也就是队头阻塞；

  • 没有请求优先级控制；

  • 请求只能从客户端开始，服务器只能被动响应。

HTTP/2 做了什么优化

HTTP/2 协议是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。 那 HTTP/2 相比 HTTP/1.1 性能上的改进：

  • 头部压缩

  • 二进制格式

  • 并发传输

  • 服务器主动推送资源 HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会帮你消除重复的部分。 这就是所谓的 HPACK 算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。 HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式，头信息和数据体都是二进制，并且统称为帧（frame）：头信息帧（Headers Frame）和数据帧（Data Frame）。 这样虽然对人不友好，但是对计算机非常友好，因为计算机只懂二进制，那么收到报文后，无需再将明文的报文转成二进制，而是直接解析二进制报文，这增加了数据传输的效率。

HTTP/1.1 的实现是基于请求-响应模型的。同一个连接中，HTTP 完成一个事务（请求与响应），才能处理下一个事务，也就是说在发出请求等待响应的过程中，是没办法做其他事情的，如果响应迟迟不来，那么后续的请求是无法发送的，也造成了队头阻塞的问题。 HTTP/2 就很牛逼了，引出了 Stream 概念，多个 Stream 复用在一条 TCP 连接。 针对不同的 HTTP 请求用独一无二的 Stream ID 来区分，接收端可以通过 Stream ID 有序组装成 HTTP 消息，不同 Stream 的帧是可以乱序发送的，因此可以并发不同的 Stream ，也就是 HTTP/2 可以并行交错地发送请求和响应。

HTTP/2 通过 Stream 的并发能力，解决了 HTTP/1 队头阻塞的问题，看似很完美了，但是 HTTP/2 还是存在“队头阻塞”的问题，只不过问题不是在 HTTP 这一层面，而是在 TCP 这一层。 HTTP/2 是基于 TCP 协议来传输数据的，TCP 是字节流协议，TCP 层必须保证收到的字节数据是完整且连续的，这样内核才会将缓冲区里的数据返回给 HTTP 应用，那么当「前 1 个字节数据」没有到达时，后收到的字节数据只能存放在内核缓冲区里，只有等到这 1 个字节数据到达时，HTTP/2 应用层才能从内核中拿到数据，这就是 HTTP/2 队头阻塞问题。一旦发生了丢包现象，就会触发 TCP 的重传机制，这样在一个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来。

HTTP/3 做了哪些优化

HTTP/1.1 中的管道（ pipeline）虽然解决了请求的队头阻塞，但是没有解决响应的队头阻塞，因为服务端需要按顺序响应收到的请求，如果服务端处理某个请求消耗的时间比较长，那么只能等响应完这个请求后， 才能处理下一个请求，这属于 HTTP 层队头阻塞。 HTTP/2 虽然通过多个请求复用一个 TCP 连接解决了 HTTP 的队头阻塞 ，但是一旦发生丢包，就会阻塞住所有的 HTTP 请求，这属于 TCP 层队头阻塞。 HTTP/2 队头阻塞的问题是因为 TCP，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP UDP 发送是不管顺序，也不管丢包的，所以不会出现像 HTTP/2 队头阻塞的问题。大家都知道 UDP 是不可靠传输的，但基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。 QUIC 有以下 3 个特点。

  • 无队头阻塞

  • 更快的连接建立

  • 连接迁移 QUIC 是一个在 UDP 之上的伪 TCP + TLS + HTTP/2 的多路复用的协议 QUIC 是新协议，对于很多网络设备，根本不知道什么是 QUIC，只会当做 UDP，这样会出现新的问题，因为有的网络设备是会丢掉 UDP 包的，而 QUIC 是基于 UDP 实现的，那么如果网络设备无法识别这个是 QUIC 包，那么就会当作 UDP包，然后被丢弃。

优化

HTTP/1.1 如何优化

  • 尽量避免发送 HTTP 请求；(采用缓存)

  • 在需要发送 HTTP 请求时，考虑如何减少请求次数；(减少重定向请求次数；合并请求； 延迟发送请求)

  • 减少服务器的 HTTP 响应的数据大小； 服务器上的一个资源可能由于迁移、维护等原因从 url1 移至 url2 后，而客户端不知情，它还是继续请求 url1，这时服务器不能粗暴地返回错误，而是通过 302 响应码和 Location 头部，告诉客户端该资源已经迁移至 url2 了，于是客户端需要再发送 url2 请求以获得服务器的资源。那么，如果重定向请求越多，那么客户端就要多次发起 HTTP 请求，每一次的 HTTP 请求都得经过网络，这无疑会越降低网络性能。 重定向响应码 如果把多个访问小文件的请求合并成一个大的请求，虽然传输的总资源还是一样，但是减少请求，也就意味着减少了重复发送的 HTTP 头部。 另外由于 HTTP/1.1 是请求响应模型，如果第一个发送的请求，未收到对应的响应，那么后续的请求就不会发送（PS：HTTP/1.1 管道模式是默认不使用的，所以讨论 HTTP/1.1 的队头阻塞问题，是不考虑管道模式的），于是为了防止单个请求的阻塞，所以一般浏览器会同时发起 5-6 个请求，每一个请求都是不同的 TCP 连接，那么如果合并了请求，也就会减少 TCP 连接的数量，因而省去了 TCP 握手和慢启动过程耗费的时间。 有的网页会含有很多小图片、小图标，有多少个小图片，客户端就要发起多少次请求。那么对于这些小图片，我们可以考虑使用 CSS Image Sprites 技术把它们合成一个大图片，这样浏览器就可以用一次请求获得一个大图片，然后再根据 CSS 数据把大图片切割成多张小图片。 这种方式就是通过将多个小图片合并成一个大图片来减少 HTTP 请求的次数，以减少 HTTP 请求的次数，从而减少网络的开销。 另外，还可以将图片的二进制数据用 base64 编码后，以 URL 的形式嵌入到 HTML 文件，跟随 HTML 文件一并发送. 这样客户端收到 HTML 后，就可以直接解码出数据，然后直接显示图片，就不用再发起图片相关的请求，这样便减少了请求的次数。

HTTP与RPC

TCP 是70年代出来的协议，而 HTTP 是 90 年代才开始流行的， RPC是80年代出来的。 Socket（套接字）是一种抽象化的通信端点，通常用于描述网络中两台计算机之间的通信链路。它是一种通信机制，通过网络传输数据，使得客户端和服务器可以在不同主机上进行通信。在编程中，Socket通常被用于构建客户端-服务器模型的应用程序，如Web服务器、聊天程序、文件传输等。通过Socket，程序员可以控制和管理网络通信的细节，实现高效、稳定的网络应用。

# 创建一个Socket对象，指定协议族（AF_INET）和套接字类型（SOCK_STREAM），并返回一个文件描述符（fd）。
fd = socket(AF_INET,SOCK_STREAM,0);

socket编程模型

其中 SOCK_STREAM，是指使用字节流传输数据，说白了就是 TCP 协议。 纯裸TCP是不能直接拿来用的，需要在这个基础上加入一些自定义的规则，用于区分消息边界。把每条要发送的数据都包装一下，比如加入消息头，消息头里写清楚一个完整的包长度是多少，根据这个长度可以继续接收数据，截取出来后它们就是我们真正要传输的消息体。而这里头提到的消息头，还可以放各种东西，比如消息体是否被压缩过和消息体格式之类的，只要上下游都约定好了，互相都认就可以了，这就是所谓的协议。于是基于 TCP，就衍生了非常多的协议，比如 HTTP 和 RPC。

Socket编程本身并不能直接解决字节流的边界问题，因为Socket仅提供了数据的传输通道，并没有提供对数据的分割、组装或边界标识的机制。这意味着在接收方，你可能会面临接收到不完整的数据、粘包（多个数据包粘在一起）或拆包（一个数据包被拆成多个片段）的情况。

http与rpc

TCP 是传输层的协议，而基于 TCP 造出来的 HTTP 和各类 RPC 协议，它们都只是定义了不同消息格式的应用层协议而已。 HTTP 协议（Hyper Text Transfer Protocol），又叫做超文本传输协议。我们用的比较多，平时上网在浏览器上敲个网址就能访问网页，这里用到的就是 HTTP 协议。 而 RPC（Remote Procedure Call），又叫做远程过程调用。它本身并不是一个具体的协议，而是一种调用方式。 如果现在这不是个本地方法，而是个远端服务器暴露出来的一个方法 remoteFunc，如果我们还能像调用本地方法那样去调用它，这样就可以屏蔽掉一些网络细节，用起来更方便,基于这个思路，大佬们造出了非常多款式的 RPC 协议，比如比较有名的gRPC，thrift。 在多年以前，HTTP 主要用于 B/S 架构，而 RPC 更多用于 C/S 架构。但现在其实已经没分那么清了，B/S 和 C/S 在慢慢融合。很多软件同时支持多端，比如某度云盘，既要支持网页版，还要支持手机端和 PC 端，如果通信协议都用 HTTP 的话，那服务器只用同一套就够了。而 RPC 就开始退居幕后，一般用于公司内部集群里，各个微服务之间的通讯。

HTTP和RPC区别

服务发现： 首先要向某个服务器发起请求，你得先建立连接，而建立连接的前提是，你得知道 IP 地址和端口。这个找到服务对应的 IP 端口的过程，其实就是服务发现。在 HTTP 中，你知道服务的域名，就可以通过 DNS 服务去解析得到它背后的 IP 地址，默认 80 端口。而 RPC 的话，就有些区别，一般会有专门的中间服务去保存服务名和IP信息，比如 Consul 或者 Etcd，甚至是 Redis。想要访问某个服务，就去这些中间服务去获得 IP 和端口信息。由于 DNS 也是服务发现的一种，所以也有基于 DNS 去做服务发现的组件，比如CoreDNS。 底层连接形式： 以主流的 HTTP/1.1 协议为例，其默认在建立底层 TCP 连接之后会一直保持这个连接（Keep Alive），之后的请求和响应都会复用这条连接。 而 RPC 协议，也跟 HTTP 类似，也是通过建立 TCP 长链接进行数据交互，但不同的地方在于，RPC 协议一般还会再建个连接池，在请求量大的时候，建立多条连接放在池内，要发数据的时候就从池里取一条连接出来，用完放回去，下次再复用，可以说非常环保。 rpc连接池

由于连接池有利于提升网络请求性能，所以不少编程语言的网络库里都会给 HTTP 加个连接池，比如 Go 就是这么干的。 传输的内容： 基于 TCP 传输的消息，说到底，无非都是消息头 Header 和消息体 Body。 Header 是用于标记一些特殊信息，其中最重要的是消息体长度。 Body 则是放我们真正需要传输的内容，而这些内容只能是二进制 01 串，毕竟计算机只认识这玩意。所以 TCP 传字符串和数字都问题不大，因为字符串可以转成编码再变成 01 串，而数字本身也能直接转为二进制。但结构体呢，我们得想个办法将它也转为二进制 01 串，这样的方案现在也有很多现成的，比如 Json，Protobuf。 这个将结构体转为二进制数组的过程就叫序列化，反过来将二进制数组复原成结构体的过程叫反序列化。 序列化与反序列化

像 Header 里的那些信息，其实如果我们约定好头部的第几位是 Content-Type，就不需要每次都真的把”Content-Type”这个字段都传过来，类似的情况其实在 body 的 Json 结构里也特别明显。 而 RPC，因为它定制化程度更高，可以采用体积更小的 Protobuf 或其他序列化协议去保存结构体数据，同时也不需要像 HTTP 那样考虑各种浏览器行为，比如 302 重定向跳转啥的。因此性能也会更好一些，这也是在公司内部微服务中抛弃 HTTP，选择使用 RPC 的最主要原因。 RPC序列化与反序列化

总结

纯裸 TCP 是能收发数据，但它是个无边界的数据流，上层需要定义消息格式用于定义消息边界。于是就有了各种协议，HTTP 和各类 RPC 协议就是在 TCP 之上定义的应用层协议。 RPC 本质上不算是协议，而是一种调用方式，而像 gRPC 和 Thrift 这样的具体实现，才是协议，它们是实现了 RPC 调用的协议。目的是希望程序员能像调用本地方法那样去调用远端的服务方法。同时 RPC 有很多种实现方式，不一定非得基于 TCP 协议。 从发展历史来说，HTTP 主要用于 B/S 架构，而 RPC 更多用于 C/S 架构。但现在其实已经没分那么清了，B/S 和 C/S 在慢慢融合。很多软件同时支持多端，所以对外一般用 HTTP 协议，而内部集群的微服务之间则采用 RPC 协议进行通讯。 RPC 其实比 HTTP 出现的要早，且比目前主流的 HTTP/1.1 性能要更好，所以大部分公司内部都还在使用 RPC。 HTTP/2.0 在 HTTP/1.1 的基础上做了优化，性能可能比很多 RPC 协议都要好，但由于是这几年才出来的，所以也不太可能取代掉 RPC。

服务器主动发消息给客户端

使用 HTTP 不断轮询

问题的痛点在于，怎么样才能在用户不做任何操作的情况下，网页能收到消息并发生变更。 最常见的解决方案是，网页的前端代码里不断定时发 HTTP 请求到服务器，服务器收到请求后给客户端响应消息。这其实时一种「伪」服务器推的形式。 会有两个比较明显的问题：

  • 当你打开 F12 页面时，你会发现满屏的 HTTP 请求。虽然很小，但这其实也消耗带宽，同时也会增加下游服务器的负担。

  • 最坏情况下，用户在扫码后，需要等个 1~2 秒，正好才触发下一次 HTTP 请求，然后才跳转页面，用户会感到明显的卡顿。

长轮询

长轮询的基本思想是客户端在打开网页时发送一个长连接请求，然后服务器保持连接打开，等待有新数据可用或超时发生。当服务器有新数据可用或特定条件满足时，会返回响应给客户端。 HTTP 请求发出后，一般会给服务器留一定的时间做响应，比如 3 秒，规定时间内没返回，就认为是超时。如果我们的 HTTP 请求将超时设置的很大，比如 30 秒，在这 30 秒内只要服务器收到了扫码请求，就立马返回给客户端网页。如果超时，那就立马发起下一次请求。这样就减少了 HTTP 请求的个数，并且由于大部分情况下，用户都会在某个 30 秒的区间内做扫码操作，所以响应也是及时的。 像这种发起一个请求，在较长时间内等待服务器响应的机制，就是所谓的长训轮机制。我们常用的消息队列 RocketMQ 中，消费者去取数据时，也用到了这种方式。像这种发起一个请求，在较长时间内等待服务器响应的机制，就是所谓的长训轮机制。我们常用的消息队列 RocketMQ 中，消费者去取数据时，也用到了这种方式。 本质上，无论是轮询还是长轮询都还是客户端主动去取数据

WebSocket

全双工： 在全双工通信中，通信的两个实体可以同时进行双向的数据传输。这意味着两个实体可以同时发送和接收数据，彼此之间可以进行实时的双向通信，就像是在同一条通道上进行两个独立的通信。全双工通信不会出现冲突，因为发送和接收是独立进行的。比如电话 半双工： 在半双工通信中，通信的两个实体可以进行双向数据传输，但不能同时进行。在任何给定的时间，只有一个实体可以发送数据，而另一个实体则处于接收状态。需要注意的是，半双工通信中的发送和接收方向可以交替进行，但不会同时进行。比如对讲机 TCP 连接的两端，同一时间里，双方都可以主动向对方发送数据，而现在使用最广泛的HTTP/1.1，也是基于TCP协议的，同一时间里，客户端和服务器只能有一方主动发数据，这就是所谓的半双工。 这是由于 HTTP 协议设计之初，考虑的是看看网页文本的场景，能做到客户端发起请求再由服务器响应，就够了，根本就没考虑网页游戏这种，客户端和服务器之间都要互相主动发大量数据的场景。 为了更好的支持这样的场景，我们需要另外一个基于TCP的新协议。于是新的应用层协议WebSocket就被设计出来了。 websocket 为了兼容这些使用场景。浏览器在 TCP 三次握手建立连接之后，都统一使用 HTTP 协议先进行一次通信。

  • 如果此时是普通的 HTTP 请求，那后续双方就还是老样子继续用普通 HTTP 协议进行交互，这点没啥疑问。

  • 如果这时候是想建立 WebSocket 连接，就会在 HTTP 请求里带上一些特殊的header 头，如下：

Connection: Upgrade
Upgrade: WebSocket
Sec-WebSocket-Key: T2a6wZlAwhgQNqruZ2YUyg==\r\n

这些 header 头的意思是，浏览器想升级协议（Connection: Upgrade），并且想升级成 WebSocket 协议（Upgrade: WebSocket）。同时带上一段随机生成的 base64 码（Sec-WebSocket-Key），发给服务器。 如果服务器正好支持升级成 WebSocket 协议。就会走 WebSocket 握手流程，同时根据客户端生成的 base64 码，用某个公开的算法变成另一段字符串，放在 HTTP 响应的 Sec-WebSocket-Accept 头里，同时带上101状态码，发回给浏览器。HTTP 的响应如下：

HTTP/1.1 101 Switching Protocols\r\n
Sec-WebSocket-Accept: iBJKv/ALIW2DobfoA4dmr3JHBCY=\r\n
Upgrade: WebSocket\r\n
Connection: Upgrade\r\n

HTTP 状态码=200（正常响应）的情况，大家见得多了。101 确实不常见，它其实是指协议切换。 之后，浏览器也用同样的公开算法将base64码转成另一段字符串，如果这段字符串跟服务器传回来的字符串一致，那验证通过。 websocket通信

WebSocket和HTTP一样都是基于TCP的协议。经历了三次TCP握手之后，利用 HTTP 协议升级为 WebSocket 协议。

WebSocket的消息格式： 数据包在WebSocket中被叫做帧，我们来看下它的数据格式长什么样子。 websocket协议头部

这里面字段很多，但我们只需要关注下面这几个。

opcode字段：这个是用来标志这是个什么类型的数据帧。比如。

  • 等于 1 ，是指text类型（string）的数据包

  • 等于 2 ，是二进制数据类型（[]byte）的数据包

  • 等于 8 ，是关闭连接的信号

payload字段：存放的是我们真正想要传输的数据的长度，单位是字节。比如你要发送的数据是字符串”111”，那它的长度就是3。 WebSocket会用最开始的7bit做标志位。不管接下来的数据有多大，都先读最先的7个bit，根据它的取值决定还要不要再读个 16bit 或 64bit。

  • 如果最开始的7bit的值是 0~125，那么它就表示了 payload 全部长度，只读最开始的7个bit就完事了。

  • 如果是126（0x7E）。那它表示payload的长度范围在 126~65535 之间，接下来还需要再读16bit。这16bit会包含payload的真实长度。

  • 如果是127（0x7F）。那它表示payload的长度范围>=65536，接下来还需要再读64bit。这64bit会包含payload的长度。这能放2的64次方byte的数据，换算一下好多个TB，肯定够用了。 payload data字段：这里存放的就是真正要传输的数据，在知道了上面的payload长度后，就可以根据这个值去截取对应的数据。 WebSocket的数据格式也是数据头（内含payload长度） + payload data 的形式。 这是因为 TCP 协议本身就是全双工，但直接使用纯裸TCP去传输数据，会有粘包的”问题”。为了解决这个问题，上层协议一般会用消息头+消息体的格式去重新包装要发的数据。 而消息头里一般含有消息体的长度，通过这个长度可以去截取真正的消息体。 WebSocket的使用场景： WebSocket完美继承了 TCP 协议的全双工能力，并且还贴心的提供了解决粘包的方案。它适用于需要服务器和客户端（浏览器）频繁交互的大部分场景，比如网页/小程序游戏，网页聊天室，以及一些类似飞书这样的网页协同办公软件。

总结

  • TCP 协议本身是全双工的，但我们最常用的 HTTP/1.1，虽然是基于 TCP 的协议，但它是半双工的，对于大部分需要服务器主动推送数据到客户端的场景，都不太友好，因此我们需要使用支持全双工的 WebSocket 协议。

  • 在 HTTP/1.1 里，只要客户端不问，服务端就不答。基于这样的特点，对于登录页面这样的简单场景，可以使用定时轮询或者长轮询的方式实现服务器推送(comet)的效果。

  • 对于客户端和服务端之间需要频繁交互的复杂场景，比如网页游戏，都可以考虑使用 WebSocket 协议。

  • WebSocket 和 socket 几乎没有任何关系，只是叫法相似。

  • 正因为各个浏览器都支持 HTTP协 议，所以 WebSocket 会先利用HTTP协议加上一些特殊的 header 头进行握手升级操作，升级成功后就跟 HTTP 没有任何关系了，之后就用 WebSocket 的数据格式进行收发数据。