cs架构接口协议（常用socket协议）与bs架构接口协议（常用http协议）_cs架构传输协议

Socket原理以及与websocket、http的区别：
B/S的系统通常使用http协议进行客户端和服务器商的信息交换，C/S的系统通常使用socket协议进行信息交换
参考：https://blog.csdn.net/qq_39813400/article/details/106721810

Socket原理：
服务端有一个进程（或者多个进程）在指定端口等待客户来连接，服务程序等待客户的连接信息，一旦连接上之后，就可以按设计的数据交换方法和格式进行数据传输。客户端在需要的时刻发出向服务器端的连接请求。

比如B/S的系统通常使用http协议进行客户端和服务器商的信息交换，C/S的系统通常使用socket协议进行信息交换

socket、websocket、http的区别
socket是TCP/IP进程间通讯的底层实现bai（当然，socket只是duipc中的一种，此zhi外还有消息队列、信号灯、共享dao内存等很多手段）。

http(s)是在socket之上封装的一种上层通讯协议，其特点是：

服务端监听通讯，被动提供服务；客户端主动向服务端发起连接请求，建立起通讯。

每一次交互都是：客户端主动发起请求（request），服务端被动应答（response）。

服务端不能主动向客户端推送数据。

通信的数据是基于文本格式的。二进制数据（比如图片等）要利用base64等手段转换为文本后才能传输。

websocket也是在socket之上封装的一种上层通讯协议，其特点是：
websocket通讯的建立阶段是依赖于http协议的。最初的握手阶段是http协议，握手完成后就切换到websocket协议，并完全与http协议脱离了。

建立通讯时，也是由客户端主动发起连接请求，服务端被动监听。

通讯一旦建立连接后，通讯就是“全双工”模式了。也就是说服务端和客户端都能在任何时间自由得发送数据，非常适合服务端要主动推送实时数据的业务场景。

交互模式不再是“请求-应答”模式，完全由开发者自行设计通讯协议。

通信的数据是基于“帧(frame)”的，可以传输文本数据，也可以直接传输二进制数据，效率高。当然，开发者也就要考虑封包、拆包、编号等技术细节。

编程步骤
（1）服务端
　　　　加载套接字库，创建套接字（WSAStartup()/socket()）;
　　　　绑定套接字到一个IP地址和一个端口上（bind()）;
　　　　将套接字设置为监听模式等待连接请求（listen()）；
　　　　请求到来后，接受连接请求，返回一个新的对应于此次连接的套接字（accept()）；
　　　　用返回的套接字和客户端进行通信（send()/recv()）；
　　　　返回，等待另一个连接请求；
　　　　关闭套接字，关闭加载的套接字库（closesocket()/WSACleanup()）；

（2）客户端
　　　　加载套接字库，创建套接字（WSAStartup()/socket()）；
　　　　向服务器发出连接请求（connect()）；
　　　　和服务器进行通信（send()/recv()）；
　　　　关闭套接字，关闭加载的套接字库（closesocket()/WSACleanup()）；

WebSocket的优势
传输速度收到的影响很多，我们可以从多个角度对HTTP和WebSocket进行比较。

从纯粹的字节数角度考虑
HTTP：每一次数据传输都需要有一个HTTP头部，头部的大小不一，可能只有几百B，也可能有几千B。

WebSocket只有在进行连接的时候需要发送一个HTTP请求，之后就再也不需要发送纷繁的HTTP头部信息，光从字节数上就减少了很多。而在关闭WebSocket的过程中，也不需要像建立握手的时候那么繁杂，只需要传送一个特定的字节码0×8的关闭帧就行，服务端收到之后，需要响应一个关闭帧到客户端。

从请求数的角度考虑
正常情况下，如果我们要请求多个数据，就多发多次HTTP请求，整个过程包括建立连接，关闭连接，特别是建立连接的时间在整个传输时间中还占据了比较大的比重。HTTP长连接的劣势也在上面有描述过。

WebSocket可以一直保持连接，通过Socket通道传输数据，节省掉了建立连接需要耗费的时间。

从服务器并发数的角度考虑
服务端要同时维持大量连接处于打开状态，就需要能以低性能开销接收高并发数据的架构。此类架构通常是围绕线程或所谓的非阻塞 IO 而设计的。这就与传统服务器围绕 HTTP 请求/响应循环的设计不同。这个时候，我们就会想到nodejs，使用事件机制和异步IO对请求进行处理，提高了服务器的并发能力，并且减少了线程切换带来的开销。

Java曾引入一个新的I/O API，其被称为非阻塞式的I/O。这一API使用一个选择器来避免每次有新的HTTP连接在服务器端建立时都要绑定一个线程的做法，当有数据到来时，就会有一个事件被接收，接着某个线程就被分配来处理该请求。因此，这种做法被称为每个请求一个线程（thread-per-request）模式。其允许web服务器，比如说WebSphere和Jetty等，使用固定数量的线程来容纳并处理越来越多的用户连接。在相同硬件配置的情况下，在这一模式下运行的web服务器的伸缩性要比运行在每个连接一个线程（thread-per-connection）模型下的好得多。

每个连接一个线程模式通常会有一个更好的响应时间，因为所有的线程都已启动、准备好且是等待中，但在连接的数目过高时，其会停止提供服务。在每个请求一个线程模式中，线程被用来为到达的请求提供服务，连接则是通过一个NIO选择器来处理。响应时间可能会较慢一些，但线程会回收再用，因此该方案在大容量连接方面有着更好的伸缩性。

而WebSocket对于服务端的优势就在于Socket减少了数据传输和处理的成本，使得这些异步的IO机制能够充分地扬长避短。

换句话说，WebSocket带来的并发能力提升，不仅仅因为传输机制本身，服务端一样需要做调整来适应新的机制，这样才能充分发挥WebSocket的优势。

如何使用Jmeter进行Socket测试:
传送门：
https://jingyan.baidu.com/article/ceb9fb1067d84a8cad2ba03d.html
————————————————
版权声明：本文为CSDN博主「tester_sz」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_39813400/article/details/106721810