普通socket, rpc, websocket,http(restful)等

sun007700

已于 2024-05-10 11:04:21 修改

阅读量3.1k

点赞数

分类专栏： socket 文章标签： rpc websocket http

于 2019-08-16 09:59:24 首次发布

本文链接：https://blog.youkuaiyun.com/sun007700/article/details/99672063

版权

socket 专栏收录该内容

9 篇文章

订阅专栏

rpc

rpc的用法是客户端直接调用服务端的函数，其实他就是把数据传给服务端，服务端处理完以后返回给客户端，

websocket是把数据发出去,他是在tcp之上一层的，他有发送结束标志，就是一次ws.send的结束，服务器会知道，服务器按照协定可以拿出完整的一次ws.send那么区别就出来了：websocket并不关系对方拿到数据后处理的过程是否完成，而rpc是和处理过程相关的，其实他们不是同一个级别的东西。如果是短连接的话，rpc更像是http,

rpc适合做数据同步，websocket适合做流，当然也可以用websocket实现rpc

对为什么不用http而用rpc的一点理解,http和rpc和websocket有什么关系呢 - 简书

这个问题其实是有理解误区的，首先 http 和 rpc 并不是一个并行概念。
rpc是远端调用协议, 包含传输协议和编码协议。
传输协议包含: 如著名的 [gRPC](grpc / grpc.io**) 使用的 http2 协议，也有如dubbo一类的自定义报文的tcp协议。
编码协议包含: 如基于文本编码的 xml json，也有二进制编码的 protobuf binpack 等。
因此我理解的你想问的问题应该是：为什么要使用自定义 tcp 协议的 rpc 做后端进程通信？
要解决这个问题就应该搞清楚 http 使用的 tcp 协议，和我们自定义的 tcp 协议在报文上的区别。

那么假如我们使用自定义tcp协议的报文如下:

报头占用的字节数也就只有16个byte，极大地精简了传输内容。
这也就是为什么后端进程间通常会采用自定义tcp协议的rpc来进行通信的原因。

http

HTTP是一个属于应用层的面向对象的协议，HTTP 协议一共有五大特点：1、支持客户/服务器模式；2、简单快速；3、灵活；4、无连接；5、无状态。基于HTTP协议的客户/服务器模式的信息交换过程，分四个过程：建立连接、发送请求信息、发送响应信息、关闭连接。

无连接

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

无状态

无状态是指协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。即我们给服务器发送 HTTP 请求之后，服务器根据请求，会给我们发送数据过来，但是，发送完，不会记录任何信息。HTTP 是一个无状态协议，这意味着每个请求都是独立的。

WebSocket一种在单个TCP连接上进行全双工通讯的协议。WebSocket通信协议于2011年被IETF定为标准RFC 6455，并被RFC7936所补充规范。WebSocket API也被W3C定为标准。

WebSocket 使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据。在 WebSocket API 中，浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。

较少的控制开销。在连接创建后，服务器和客户端之间交换数据时，用于协议控制的数据包头部相对较小。相对于HTTP请求每次都要携带完整的头部，此项开销显著减少了。

更强的实时性。由于协议是全双工的，所以服务器可以随时主动给客户端下发数据。相对于HTTP请求需要等待客户端发起请求服务端才能响应，延迟明显更少；

保持连接状态。于HTTP不同的是，Websocket需要先创建连接，这就使得其成为一种有状态的协议，之后通信时可以省略部分状态信息。而HTTP请求可能需要在每个请求都携带状态信息（如身份认证等）。

更好的二进制支持。Websocket定义了二进制帧，相对HTTP，可以更轻松地处理二进制内容

websocket与http关系 http://blog.youkuaiyun.com/btqszl/article/details/62893880

WebSocket和HTTP的主要区别包括：12

含义不同：WebSocket是一种在单个TCP连接上进行全双工通信的协议；HTTP是超文本传输协议，是一个简单的请求-响应协议，运行在TCP之上，是单向的通信协议。
连接方式不同：WebSocket需要浏览器和服务器握手进行建立连接；HTTP是浏览器发起向服务器的连接，服务器预先并不知道这个连接。
连接长度和状态不同：WebSocket是持久连接，是有状态的双向连接；HTTP是短连接，是无状态的。
数据传输方式不同：WebSocket允许服务器主动向客户端推送数据，实现了服务器和客户端之间的实时双向通信；HTTP协议是基于请求-响应模式的，客户端发送请求，服务器返回响应。
数据格式不同：WebSocket可以传输任意格式的数据，包括文本、二进制、JSON等；HTTP协议传输的数据通常是文本或二进制数据。
端口不同：WebSocket使用的默认端口是80（WS）或443（WSS）；HTTP协议使用的默认端口是80（HTTP）或443（HTTPS）。

Web Service 也提出了好久了, 那么究竟什么是 Web Service ?

简单地说, 也就是服务器如何向客户端提供服务.

常用的方法有:

RPC 所谓的远程过程调用 (面向方法)
SOA 所谓的面向服务的架构(面向消息)
REST 所谓的 Representational state transfer (面向资源)

RPC是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加轻易。
　　 RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息的到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用过程接收答复信息，获得进程结果，然后调用执行继续进行。
RPC信息协议由两个不同结构组成：调用信息和答复信息。

RESTFUL 不是一种协议,它是一种架构, 一种 Web Service 能够如果满足 REST 的几个条件, 通常就称这个系统是 Restful 的.

这里提到的条件包括:

C/S结构 (这是Internet服务的一个基本特征)
无状态 (很熟悉吧,呵呵)
可以cache (想起了浏览器?)
分层系统 (想起了无数的架构?)
统一的接口 (如果这是可能的,程序员有福了, :D)
code on demand(可选, 其实是一种扩展性的要求)

RPC与REST的区别

RPC是以动词为中心的, REST是以名词为中心的, 此处的动词指的是一些方法, 名词是指资源.

你会发现,以动词为中心,意味着,当你要需要加入新功能时,你必须要添加更多的动词, 这时候服务器端需要实现相应的动词(方法), 客户端需要知道这个新的动词并进行调用.

而以名词为中心, 假使我请求的是 hostname/friends/, 无论这个URI对应的服务怎么变化,客户端是无需关注和更新的,而这种变化对客户端也是透明的.

WEB开发中，使用JSON-RPC好，还是RESTful API好？

WEB开发中，使用JSON-RPC好，还是RESTful API好？ - 知乎

REST是一种设计风格，它的很多思维方式与RPC是完全冲突的。

RPC的思想是把本地函数映射到API，也就是说一个API对应的是一个function，我本地有一个getAllUsers，远程也能通过某种约定的协议来调用这个getAllUsers。至于这个协议是Socket、是HTTP还是别的什么并不重要；

RPC中的主体都是动作，是个动词，表示我要做什么。

而REST则不然，它的URL主体是资源，是个名词。而且也仅支持HTTP协议，规定了使用HTTP Method表达本次要做的动作，类型一般也不超过那四五种。这些动作表达了对资源仅有的几种转化方式。

这种设计思路是反程序员直觉的，因为在本地业务代码中仍然是一个个的函数，是动作，但表现在接口形式上则完全是资源的形式。

就像面向对象的「万物皆对象」理论在习惯了纯粹面向过程开发的程序员眼里显得十分别扭一样：我的代码本来就是按顺序、循环、分支这么运行的啊，为啥非得在很明确的结构上封装一层一层的基类子类接口，还要故意给两个函数起同一个名字，调用时才选择用哪一个呢？

RESTful

面试官：你连RESTful都不知道我怎么敢要你？_restful 面试让聊-优快云博客

如何选择?

建议 能够使用REST就尽量使用REST, 主要基于下面几个考虑:

扩展性
松耦合(意味着,不用强制要求客户端去更新相应的代码)
客户端实现语言无关
性能
安全性(例如HTTPS)

http、websocket;restful、rpc的区别_websocket restful-优快云博客

对为什么不用http而用rpc的一点理解,http和rpc和websocket有什么关系呢

对为什么不用http而用rpc的一点理解,http和rpc和websocket有什么关系呢 - 简书

简单来说成熟的rpc库相对http容器，跟多的是封装了“服务发现”，"错误重试"一类面向服务的高级特性。可以这么理解，rpc框架是面向服务的更高级的封装。如果把一个http server容器上封装一层服务发现和函数代理调用，那它就已经可以做一个rpc框架了。
所以为什么要用rpc调用？
因为良好的rpc调用是面向服务的封装，针对服务的可用性和效率等都做了优化。单纯使用http调用则缺少了这些特性。