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

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.csdn.net/btqszl/article/details/62893880

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

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

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

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

常用的方法有:

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

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

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

这里提到的条件包括:

  1. C/S结构 (这是Internet服务的一个基本特征)
  2. 无状态 (很熟悉吧,呵呵)
  3. 可以cache (想起了浏览器?)
  4. 分层系统 (想起了无数的架构?)
  5. 统一的接口 (如果这是可能的,程序员有福了, :D)
  6. 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 面试让聊-CSDN博客

如何选择?

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

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

http、websocket;restful、rpc的区别_websocket restful-CSDN博客

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

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

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

Restful、SOAP、RPC、SOA、微服务之间的区别

Restful、SOAP、RPC、SOA、微服务之间的区别_dds rpc 微服务-CSDN博客

Rest,RESTful和RestTemplate的理解

Rest,RESTful和RestTemplate的理解_rest和resttemplate-CSDN博客

33.服务之间的调用之RPC、Restful深入理解

33.服务之间的调用之RPC、Restful深入理解_rpc的alias-CSDN博客

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值