rpc

rpc的用法是客戶端直接調(diào)用服務(wù)端的函數(shù)，其實(shí)他就是把數(shù)據(jù)傳給服務(wù)端，服務(wù)端處理完以后返回給客戶端，

websocket是把數(shù)據(jù)發(fā)出去,他是在tcp之上一層的，他有發(fā)送結(jié)束標(biāo)志，就是一次ws.send的結(jié)束，服務(wù)器會知道，服務(wù)器按照協(xié)定可以拿出完整的一次ws.send那么區(qū)別就出來了：websocket并不關(guān)系對方拿到數(shù)據(jù)后處理的過程是否完成，而rpc是和處理過程相關(guān)的，其實(shí)他們不是同一個級別的東西。如果是短連接的話，rpc更像是http,

rpc適合做數(shù)據(jù)同步，websocket適合做流，當(dāng)然也可以用websocket實(shí)現(xiàn)rpc

對為什么不用http而用rpc的一點(diǎn)理解,http和rpc和websocket有什么關(guān)系呢 - 簡書

這個問題其實(shí)是有理解誤區(qū)的，首先 http 和 rpc 并不是一個并行概念。
rpc是遠(yuǎn)端調(diào)用協(xié)議, 包含傳輸協(xié)議和編碼協(xié)議。
傳輸協(xié)議包含: 如著名的 [gRPC](grpc / grpc.io**) 使用的 http2 協(xié)議，也有如dubbo一類的自定義報(bào)文的tcp協(xié)議。
編碼協(xié)議包含: 如基于文本編碼的 xml json，也有二進(jìn)制編碼的 protobuf binpack 等。
因此我理解的你想問的問題應(yīng)該是：為什么要使用自定義 tcp 協(xié)議的 rpc 做后端進(jìn)程通信？
要解決這個問題就應(yīng)該搞清楚 http 使用的 tcp 協(xié)議，和我們自定義的 tcp 協(xié)議在報(bào)文上的區(qū)別。

那么假如我們使用自定義tcp協(xié)議的報(bào)文如下:

報(bào)頭占用的字節(jié)數(shù)也就只有16個byte，極大地精簡了傳輸內(nèi)容。
這也就是為什么后端進(jìn)程間通常會采用自定義tcp協(xié)議的rpc來進(jìn)行通信的原因。
 

http

HTTP是一個屬于應(yīng)用層的面向?qū)ο蟮膮f(xié)議，HTTP 協(xié)議一共有五大特點(diǎn)：1、支持客戶/服務(wù)器模式；2、簡單快速；3、靈活；4、無連接；5、無狀態(tài)?；贖TTP協(xié)議的客戶/服務(wù)器模式的信息交換過程，分四個過程：建立連接、發(fā)送請求信息、發(fā)送響應(yīng)信息、關(guān)閉連接。

無連接

無連接是指限制每次連接只處理一個請求。服務(wù)器處理完客戶的請求，并收到客戶的應(yīng)答后，即斷開連接。采用這種方式可以節(jié)省傳輸時間。

無狀態(tài)

無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶能力，服務(wù)器不知道客戶端是什么狀態(tài)。即我們給服務(wù)器發(fā)送 HTTP 請求之后，服務(wù)器根據(jù)請求，會給我們發(fā)送數(shù)據(jù)過來，但是，發(fā)送完，不會記錄任何信息。HTTP 是一個無狀態(tài)協(xié)議，這意味著每個請求都是獨(dú)立的。

WebSocket一種在單個TCP連接上進(jìn)行全雙工通訊的協(xié)議。WebSocket通信協(xié)議于2011年被IETF定為標(biāo)準(zhǔn)RFC 6455，并被RFC7936所補(bǔ)充規(guī)范。WebSocket API也被W3C定為標(biāo)準(zhǔn)。

WebSocket 使得客戶端和服務(wù)器之間的數(shù)據(jù)交換變得更加簡單，允許服務(wù)端主動向客戶端推送數(shù)據(jù)。在 WebSocket API 中，瀏覽器和服務(wù)器只需要完成一次握手，兩者之間就直接可以創(chuàng)建持久性的連接，并進(jìn)行雙向數(shù)據(jù)傳輸。

• 較少的控制開銷。在連接創(chuàng)建后，服務(wù)器和客戶端之間交換數(shù)據(jù)時，用于協(xié)議控制的數(shù)據(jù)包頭部相對較小。相對于HTTP請求每次都要攜帶完整的頭部，此項(xiàng)開銷顯著減少了。

• 更強(qiáng)的實(shí)時性。由于協(xié)議是全雙工的，所以服務(wù)器可以隨時主動給客戶端下發(fā)數(shù)據(jù)。相對于HTTP請求需要等待客戶端發(fā)起請求服務(wù)端才能響應(yīng)，延遲明顯更少；

• 保持連接狀態(tài)。于HTTP不同的是，Websocket需要先創(chuàng)建連接，這就使得其成為一種有狀態(tài)的協(xié)議，之后通信時可以省略部分狀態(tài)信息。而HTTP請求可能需要在每個請求都攜帶狀態(tài)信息（如身份認(rèn)證等）。

• 更好的二進(jìn)制支持。Websocket定義了二進(jìn)制幀，相對HTTP，可以更輕松地處理二進(jìn)制內(nèi)容

websocket與http關(guān)系 http://blog.csdn.net/btqszl/article/details/62893880

WebSocket和HTTP的主要區(qū)別包括：12

1. 含義不同：WebSocket是一種在單個TCP連接上進(jìn)行全雙工通信的協(xié)議；HTTP是超文本傳輸協(xié)議，是一個簡單的請求-響應(yīng)協(xié)議，運(yùn)行在TCP之上，是單向的通信協(xié)議。
2. 連接方式不同：WebSocket需要瀏覽器和服務(wù)器握手進(jìn)行建立連接；HTTP是瀏覽器發(fā)起向服務(wù)器的連接，服務(wù)器預(yù)先并不知道這個連接。
3. 連接長度和狀態(tài)不同：WebSocket是持久連接，是有狀態(tài)的雙向連接；HTTP是短連接，是無狀態(tài)的。
4. 數(shù)據(jù)傳輸方式不同：WebSocket允許服務(wù)器主動向客戶端推送數(shù)據(jù)，實(shí)現(xiàn)了服務(wù)器和客戶端之間的實(shí)時雙向通信；HTTP協(xié)議是基于請求-響應(yīng)模式的，客戶端發(fā)送請求，服務(wù)器返回響應(yīng)。
5. 數(shù)據(jù)格式不同：WebSocket可以傳輸任意格式的數(shù)據(jù)，包括文本、二進(jìn)制、JSON等；HTTP協(xié)議傳輸?shù)臄?shù)據(jù)通常是文本或二進(jìn)制數(shù)據(jù)。
6. 端口不同：WebSocket使用的默認(rèn)端口是80（WS）或443（WSS）；HTTP協(xié)議使用的默認(rèn)端口是80（HTTP）或443（HTTPS）。

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

簡單地說, 也就是服務(wù)器如何向客戶端提供服務(wù).

常用的方法有:

1. RPC 所謂的遠(yuǎn)程過程調(diào)用 (面向方法)
2. SOA 所謂的面向服務(wù)的架構(gòu)(面向消息)
3. REST 所謂的 Representational state transfer (面向資源)

RPC是一種通過網(wǎng)絡(luò)從遠(yuǎn)程計(jì)算機(jī)程序上請求服務(wù)，而不需要了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議。RPC協(xié)議假定某些傳輸協(xié)議的存在，如TCP或UDP，為通信程序之間攜帶信息數(shù)據(jù)。在OSI網(wǎng)絡(luò)通信模型中，RPC跨越了傳輸層和應(yīng)用層。RPC使得開發(fā)包括網(wǎng)絡(luò)分布式多程序在內(nèi)的應(yīng)用程序更加輕易。
　　 RPC采用客戶機(jī)/服務(wù)器模式。請求程序就是一個客戶機(jī)，而服務(wù)提供程序就是一個服務(wù)器。首先，調(diào)用進(jìn)程發(fā)送一個有進(jìn)程參數(shù)的調(diào)用信息到服務(wù)進(jìn)程，然后等待應(yīng)答信息。在服務(wù)器端，進(jìn)程保持睡眠狀態(tài)直到調(diào)用信息的到達(dá)為止。當(dāng)一個調(diào)用信息到達(dá)，服務(wù)器獲得進(jìn)程參數(shù)，計(jì)算結(jié)果，發(fā)送答復(fù)信息，然后等待下一個調(diào)用信息，最后，客戶端調(diào)用過程接收答復(fù)信息，獲得進(jìn)程結(jié)果，然后調(diào)用執(zhí)行繼續(xù)進(jìn)行。
RPC信息協(xié)議由兩個不同結(jié)構(gòu)組成：調(diào)用信息和答復(fù)信息。

RESTFUL 不是一種協(xié)議,它是一種架構(gòu), 一種 Web Service 能夠如果滿足 REST 的幾個條件, 通常就稱這個系統(tǒng)是 Restful 的.

這里提到的條件包括:

1. C/S結(jié)構(gòu) (這是Internet服務(wù)的一個基本特征)
2. 無狀態(tài) (很熟悉吧,呵呵)
3. 可以cache (想起了瀏覽器?)
4. 分層系統(tǒng) (想起了無數(shù)的架構(gòu)?)
5. 統(tǒng)一的接口 (如果這是可能的,程序員有福了, :D)
6. code on demand(可選, 其實(shí)是一種擴(kuò)展性的要求)

RPC與REST的區(qū)別

 RPC是以動詞為中心的, REST是以名詞為中心的, 此處的 動詞指的是一些方法, 名詞是指資源.

你會發(fā)現(xiàn),以動詞為中心,意味著,當(dāng)你要需要加入新功能時,你必須要添加更多的動詞, 這時候服務(wù)器端需要實(shí)現(xiàn) 相應(yīng)的動詞(方法), 客戶端需要知道這個新的動詞并進(jìn)行調(diào)用.

而以名詞為中心, 假使我請求的是 hostname/friends/, 無論這個URI對應(yīng)的服務(wù)怎么變化,客戶端是無需 關(guān)注和更新的,而這種變化對客戶端也是透明的.

WEB開發(fā)中，使用JSON-RPC好，還是RESTful API好？

WEB開發(fā)中，使用JSON-RPC好，還是RESTful API好？ - 知乎

REST是一種設(shè)計(jì)風(fēng)格，它的很多思維方式與RPC是完全沖突的。

RPC的思想是把本地函數(shù)映射到API，也就是說一個API對應(yīng)的是一個function，我本地有一個getAllUsers，遠(yuǎn)程也能通過某種約定的協(xié)議來調(diào)用這個getAllUsers。至于這個協(xié)議是Socket、是HTTP還是別的什么并不重要；

RPC中的主體都是動作，是個動詞，表示我要做什么。

而REST則不然，它的URL主體是資源，是個名詞。而且也僅支持HTTP協(xié)議，規(guī)定了使用HTTP Method表達(dá)本次要做的動作，類型一般也不超過那四五種。這些動作表達(dá)了對資源僅有的幾種轉(zhuǎn)化方式。

這種設(shè)計(jì)思路是反程序員直覺的，因?yàn)樵诒镜貥I(yè)務(wù)代碼中仍然是一個個的函數(shù)，是動作，但表現(xiàn)在接口形式上則完全是資源的形式。

就像面向?qū)ο蟮摹溉f物皆對象」理論在習(xí)慣了純粹面向過程開發(fā)的程序員眼里顯得十分別扭一樣：我的代碼本來就是按順序、循環(huán)、分支這么運(yùn)行的啊，為啥非得在很明確的結(jié)構(gòu)上封裝一層一層的基類子類接口，還要故意給兩個函數(shù)起同一個名字，調(diào)用時才選擇用哪一個呢？

RESTful

面試官：你連RESTful都不知道我怎么敢要你？_restful 面試讓聊-CSDN博客

如何選擇?

 建議 能夠使用REST就盡量使用REST, 主要基于下面幾個考慮:

1. 擴(kuò)展性
2. 松耦合(意味著,不用強(qiáng)制要求客戶端去更新相應(yīng)的代碼)
3. 客戶端實(shí)現(xiàn)語言無關(guān)
4. 性能
5. 安全性(例如HTTPS)

http、websocket;restful、rpc的區(qū)別_websocket restful-CSDN博客

對為什么不用http而用rpc的一點(diǎn)理解,http和rpc和websocket有什么關(guān)系呢

對為什么不用http而用rpc的一點(diǎn)理解,http和rpc和websocket有什么關(guān)系呢 - 簡書

簡單來說成熟的rpc庫相對http容器，跟多的是封裝了“服務(wù)發(fā)現(xiàn)”，'錯誤重試'一類面向服務(wù)的高級特性?？梢赃@么理解，rpc框架是面向服務(wù)的更高級的封裝。如果把一個http server容器上封裝一層服務(wù)發(fā)現(xiàn)和函數(shù)代理調(diào)用，那它就已經(jīng)可以做一個rpc框架了。
所以為什么要用rpc調(diào)用？
因?yàn)榱己玫膔pc調(diào)用是面向服務(wù)的封裝，針對服務(wù)的可用性和效率等都做了優(yōu)化。單純使用http調(diào)用則缺少了這些特性。

Restful、SOAP、RPC、SOA、微服務(wù)之間的區(qū)別

Restful、SOAP、RPC、SOA、微服務(wù)之間的區(qū)別_dds rpc 微服務(wù)-CSDN博客

Rest，RESTful和RestTemplate的理解

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

33.服務(wù)之間的調(diào)用之RPC、Restful深入理解

33.服務(wù)之間的調(diào)用之RPC、Restful深入理解_rpc的alias-CSDN博客