http和websocket

会笑的那双眼

已于 2022-04-09 09:41:10 修改

阅读量3k

点赞数

分类专栏： http websocket 文章标签： tcp epoll reactor

于 2022-04-09 09:37:55 首次发布

本文链接：https://blog.csdn.net/lswdcyy/article/details/123959603

版权

http 同时被 2 个专栏收录

1 篇文章 0 订阅

订阅专栏

websocket

1 篇文章 0 订阅

订阅专栏

本文探讨了HTTP的C/S模型，TCP粘包处理方法，以及Http与WebSocket的关系，解释了为何HTTP限制客户端主动、WebSocket出现的原因。还介绍了Base64压缩和阻塞/非阻塞读取在Web通信中的作用，以及Web协议扩展和WebSocket的握手机制。

摘要由CSDN通过智能技术生成

关于HTTP

http的模型就是C/S模型，对数据的处理就是客户端发送申请，服务器接收申请进行响应的过程。因此本质上他是个半双工的、且通信只能由客户端发起的一种通信方式；

关于tcp粘包

一般有两种方式：一种是定义分隔符；一种是定义包头，通过包头的长度来进行边界确认。包头的话，一般包头的数据格式直接定义成为一个固定格式，在保证包头的数据格式正确的基础之上保证整体的http数据完整；

关于Http、WebSocket和Tcp

这三个协议，首先就是Http和Tcp，这两个协议一个是应用层的，一个是传输层的，一直是比较纠结的是Http明明是基于Tcp的应用层协议，然后资料上又说Http的交互只能是由客户端主动发起，服务器端进行响应这种模式；且Tcp又是可以进行全双工数据通信的，也没有Http的这种限制，为什么Http反而有了这种限制？无他，是因为协议，如果说确定一种仅仅是有限范围人群使用的通信方式的话，那么基于Tcp的通信方式是完全可以自由定义的，但是一旦是一个所有互联网人群需要遵循的话，就需要每个人都遵守这种规则，也就是Http协议，Http协议规定了客户端发起、服务器端响应的通信模型，在实现Http的时候就要遵守这个规则，否则就是无法正常通信的；

那么为什么Http定义这种模型，这就和服务器承担的职责有关了，服务器需要为全网络的人群提供服务，不可能会一直为某个客户端保持连接，他要尽可能多的为浏览器提供服务，因此就有了这种模型；

而有的浏览器需要保持长连接的功能，于是就有了WebSocket协议，至于为什么不直接使用Tcp，Tcp只是一种数据通信方式，并没有数据结构，纯粹的数据是没有意义的，本质上WebSocket就是基于Tcp的应用层协议；至于为什么WebSocket要间接的使用Http的格式来进行握手，原因就是Http已经是成熟的协议了，间接握手看起来是比较复杂的，但是重用了Http整体上看却是比较简单的。

当然，如果说是有限范围人员定义了一个协议，那这个协议完全就充当了应用层角色，tcp本质上就是个通信手段，这时候也就没http和websocket什么事了。

关于base64

base64本质上是为了缩减传输信息的一种数据压缩算法。就是二进制文件的64进制显示，且这个64进制可以用显示字符进行表示。比如要传输一个二进制文件，如果是直接以二进制的形式传输，那么3Byte数据就要24个字符传输，而使用64进制，那么只需要4个字符，至于为什么不直接使用ASCII码，因为ASCII码中有很多是控制字符，并不是可打印字符(可打印字符为95个)，因此有了base64；

阻塞读取与非阻塞读取

不论是http还是weosocket，本质上的通讯都是tcp，首先要处理的就是如何针对tcp这样的流式数据提取http或websocket数据结构，在读取的时候有两种方式，一种是阻塞性的，一种是非阻塞性的；

主机在进行tcp数据收发的过程中有两个阶段，本质上就是内核关于套接字的缓冲区，需要将用户区数据进行收发的时候，首先使用系统调用将数据复制到内核的套接字缓冲区，接着由内核网络驱动完成数据收发，这个过程中如果使用了阻塞收发的话，在处理一个连接的时候就要等到数据完全读取或者完全发送完毕才能继续之后的连接操作，如果遇到一个大数据量的数据交互，等待网络发送完毕的过程中就会有服务器卡顿的问题，因此一般需要使用非阻塞操作，相应的程序复杂度也有一定程度的提升。

在使用非阻塞操作的时候，对于读取而言，需要对流式信息进行数据提取，且Http的属性是没有严格顺序的，每个消息头属性的结束为\r\n；整个消息头结束的时候会有一行空白行，即没有信息，一行中只有\r\n；通过这个规则可以提取出消息头，然后根据消息头的信息再去提取消息体的数据。