对于小白来说，只要知道”在浏览器输入一个网址，就会返回一个网页“就行了。那么对于一个后端程序员来说，我们需要知道的是是什么？

  前后端分离时代，一个应用软件被分成了前端应用和后端应用。简单的来说就是：前端程序猿写好页面，在需要有数据填充的地方调用API接口，这个API接口是由后端程序猿提供的（哈，这就是面向接口编程）。因此这个API接口就是关键，前后端分离的落地必须依靠优良的API接口定义。如何定义好一个优秀接口？

HTTP和各类RPC协议【比如比较有名的gRPC、thrift】大多都是基于TCP传输协议【但实际上它们不一定非得使用TCP，改用UDP或者HTTP，其实也可以做到类似的功能】造出来的，它们都只是定义了不同消息格式的应用层协议而已。 →HTTP协议（Hyper Text Transfer Protocol），又叫做超文本传输协议。我们用的比较多，平时上网在浏览器上敲个网址就能访问网页，这里用到的就是HTTP协议。 →RPC（Remote Procedure Call），又叫做远程过程调用。它本身并不是一个具体的协议，而是一种调用方式。

调用服务前，需要先设计好接口。

接口定义：程序之间协作所要遵循的一套规范、标准。

接口的优点：

API 应用程序编程接口（API：Application Programming Interface）：以HTTP协议形式提供，定义了输入、输出功能描述的服务。

按照一定的规则写出的易读、易懂的api文档；目的是让前端、后端、测试三方在工作的时候有据可循，以提升开发和测试的效率。（非强制要求，软要求）

REST即表述性状态传递（Representational State Transfer，简称REST），是一种软件架构风格。REST通过HTTP协议定义的通用动词方法(GET、PUT、DELETE、POST) ，以URI对网络资源进行唯一标识，响应端根据请求端的不同需求，通过无状态通信，对其请求的资源进行表述。

REST实现主要流程：REST使用HTTP+URI+XML /JSON 的技术来实现其API要求的架构风格=>HTTP协议和URI用于统一接口和定位资源，文本、二进制流、XML、JSON等格式用来作为资源的表述。

restful架构主要原则：

1、网络上的所有事物都被抽象为资源。 2、每个资源都有一个唯一的资源标识符。 3、同一个资源具有多种表现形(xml，json等)。 4、对资源的各种操作不会改变资源标识符。 5、所有的操作都是无状态的。

CRUD语法风格如下： 1.查 方法：get 响应码：200+查询数据 2.增 方法：post 响应码：201+新增数据 3.改 方法：put 响应码：200或201+修改数据 4.删 方法：delete 响应码：204+无

与 RPC 相比，Restful API 有相对统一的标准，因而更通用，兼容性更好，支持不同的语言。HTTP 协议是基于文本的，一般具备更好的可读性。但是缺点也很明显：

RPC(Remote Procedure Call，远程过程调用)是一种计算机通信协议，允许调用不同进程空间的程序。RPC 的客户端和服务器可以在一台机器上，也可以在不同的机器上。程序员使用时，就像调用本地程序一样，无需关注内部的实现细节。

RPC 即远程过程调用，很简单的概念，像调用本地服务(方法)一样调用服务器的服务(方法) 。

RPC具体实现步骤：

1、 服务调用方（client）(客户端)以本地调用方式调用服务； 2、 client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体，即序列化； 3、 client stub找到服务地址，并将消息通过网络发送到服务端； 4、 server stub收到消息后进行解码，即反序列化； 5、 server stub根据解码结果调用本地的服务； 6、 本地服务执行处理逻辑； 7、 本地服务将结果返回给server stub； 8、 server stub将返回结果打包成消息，Java里的序列化； 9、 server stub将打包后的消息通过网络并发送至消费方 10、 client stub接收到消息，并进行解码, Java里的反序列化； 11、 服务调用方（client）得到最终结果。

RPC框架的目标就是把2-10步封装起来，把调用、编码/解码的过程封装起来，让用户像调用本地服务一样的调用远程服务。要做到对客户端（调用方）透明化服务， RPC框架需要考虑解决如下问题：

1、通讯问题 : 主要是通过在客户端和服务器之间建立TCP连接，远程过程调用的所有交换的数据都在这个连接里传输。连接可以是按需连接，调用结束后就断掉，也可以是长连接，多个远程过程调用共享同一个连接。 2、寻址问题 ： A服务器上的应用怎么告诉底层的RPC框架，如何连接到B服务器（如主机或IP地址）以及特定的端口，方法的名称是什么，这样才能完成调用。比如基于Web服务协议栈的RPC，就要提供一个endpoint URI，或者是从UDDI服务上查找。如果是RMI调用的话，还需要一个RMI Registry来注册服务的地址。 3、序列化与反序列化 ： 当A服务器上的应用发起远程过程调用时，方法的参数需要通过底层的网络协议如TCP传递到B服务器，由于网络协议是基于二进制的，内存中的参数的值要序列化成二进制的形式，也就是序列化（Serialize）或编组（marshal），通过寻址和传输将序列化的二进制发送给B服务器。 同理，B服务器接收参数要将参数反序列化。B服务器应用调用自己的方法处理后返回的结果也要序列化给A服务器，A服务器接收也要经过反序列化的过程。

简单模式：客户端发起一次请求，服务端响应一次数据，和普通的rpc没有区别。 服务端数据流模式：客户端发起一次请求，服务端返回一段连续的数据流。典型的例子是客户端发给服务端一个股票代码，服务端将该股票的数据实时不断的返回给客户端。还有我们常用的订阅场景也属于服务端流模式。 客户端数据流模式：与服务端数据流模式相反，由客户端源源不断的像服务端发送数据流，发送结束后，由服务端返回一个响应。典型的例子是物联网终端像服务器报送数据。 双向数据流模式：客户端和服务端可以向双方实时发送数据流进行交互，典型应用是聊天机器人，即时通信工具等。

总的来说：REST面向资源 RPC面向方法

1、以Apache Thrift为代表的二进制RPC，支持多种语言（但不是所有语言），四层通讯协议，性能高，节省带宽。相对Restful协议，使用Thrifpt RPC，在同等硬件条件下，带宽使用率仅为前者的20%，性能却提升一个数量级。但是这种协议最大的问题在于，无法穿透防火墙。

2、以Spring Cloud为代表所支持的Restful 协议，优势在于能够穿透防火墙，使用方便，语言无关，基本上可以使用各种开发语言实现的系统，都可以接受Restful 的请求。但性能和带宽占用上有劣势。

3、restful是在服务端把方法写好，客户端通过http方式调用，直接定位到方法上面去。而RPC服务则需要客户端接口与服务端保持一致，服务端提供一个方法，客户端通过接口直接发起调用，业务开发人员仅需要关注业务方法的调用即可，不再关注网络传输的细节，在开发上更为高效。（PRC是服务端提供好方法给客户端调用。定位到类，然后通过类去调用方法。）

所以，业内对微服务的实现，基本是确定一个组织边界，在边界内，使用RPC；边界外，使用Restful。这个边界，可以是业务、部门，甚至是全公司。

1、从性能角度看，使用Http时，Http本身提供了丰富的状态功能与扩展功能，但也正由于Http提供的功能过多，导致在网络传输时，需要携带的信息更多，从性能角度上讲，较为低效。而RPC服务网络传输上仅传输与业务内容相关的数据，传输数据更小，性能更高。

2、从使用方面看，Http接口只关注服务提供方（服务端），对于客户端怎么调用，调用方式怎样并不关心，通常情况下，客户端使用Http方式进行调用时，只要将内容进行传输即可，这样客户端在使用时，需要更关注网络方面的传输，比较不适用与业务方面的开发；而RPC服务则需要客户端接口与服务端保持一致，服务端提供一个方法，客户端通过接口直接发起调用，业务开发人员仅需要关注业务方法的调用即可，不再关注网络传输的细节，在开发上更为高效。

3、从运维角度看，使用Http接口时，常常使用一个前端代理，来进行Http转发代理请求的操作，需要进行扩容时，则需要去修改代理服务器的配置，较为繁琐，也容易出错。而使用RPC方式的微服务，则只要增加一个服务节点即可，注册中心可自动感知到节点的变化，通知调用客户端进行负载的动态控制，更为智能，省去运维的操作。

1、服务发现 首先要向某个服务器发起请求，得先建立连接，而建立连接的前提是，得知道IP地址和端口。这个找到服务对应的IP端口的过程，其实就是服务发现。

在HTTP中，知道服务的域名，就可以通过DNS服务去解析得到它背后的IP地址，默认80端口。

而RPC的话，就有些区别，一般会有专门的中间服务去保存服务名和IP信息，比如consul或者etcd，甚至是redis。想要访问某个服务，就去这些中间服务去获得IP和端口信息。由于dns也是服务发现的一种，所以也有基于dns去做服务发现的组件，比如CoreDNS。

可以看出服务发现这一块，两者是有些区别，但不太能分高低。

2、底层连接形式 以主流的HTTP1.1协议为例，其默认在建立底层TCP连接之后会一直保持这个连接（keep alive），之后的请求和响应都会复用这条连接。

而RPC协议，也跟HTTP类似，也是通过建立TCP长链接进行数据交互，但不同的地方在于，RPC协议一般还会再建个连接池，在请求量大的时候，建立多条连接放在池内，要发数据的时候就从池里取一条连接出来，用完放回去，下次再复用，可以说非常环保。

由于连接池有利于提升网络请求性能，所以不少编程语言的网络库里都会给HTTP加个连接池，比如go就是这么干的。

可以看出这一块两者也没太大区别，所以也不是关键。

3、传输的内容 对于主流的HTTP1.1，虽然它现在叫超文本协议，支持音频视频，但HTTP设计初是用于做网页文本展示的，所以它传的内容以字符串为主。因为要区分传输内容，所以必须通过冗余信息[header]来标记内容信息[body]。所以数据自然很大。

RPC，因为它定制化程度更高，可以采用体积更小的protobuf或其他序列化协议去保存结构体数据，同时也不需要像HTTP那样考虑各种浏览器行为，比如302重定向跳转啥的。因此RPC性能也会更好一些，这也是在公司内部微服务中抛弃HTTP，选择使用RPC的最主要原因。

HTTP2在前者HTTP1的基础上做了很多改进，所以性能可能比很多RPC协议还要好，甚至连gRPC底层都直接用的HTTP2。 【那为啥既然有了HTTP2，还要有RPC协议？】 HTTP2是2015年出来的。很多公司内部的RPC协议都已经跑了好些年了，基于历史原因，一般也没必要去换。

既然有HTTP协议，为什么还要有RPC？

相关链接：https://mp.weixin.qq.com/s/jBwnEzug5d3BNeP5t__kZw

这个得从发展历史来看：

其实，TCP是70年代出来的协议，而HTTP是90年代才开始流行的。而直接使用裸TCP会有问题，可想而知，这中间这么多年有多少自定义的协议，而这里面就有80年代出来的RPC。

所以该问的不是既然有HTTP协议为什么要有RPC，而是为什么有RPC还要有HTTP协议？

现在电脑上装的各种联网软件，比如xx管家，xx卫士，它们都作为客户端（client）需要跟服务端（server）建立连接收发消息，此时都会用到应用层协议，在这种client/server (c/s)架构下，它们可以使用自家造的RPC协议，因为它只管连自己公司的服务器就ok了。

但有个软件不同，浏览器（browser），不管是chrome还是IE，它们不仅要能访问自家公司的服务器（server），还需要访问其他公司的网站服务器，因此它们需要有个统一的标准，不然大家没法交流。于是，HTTP就是那个时代用于统一 browser/server (b/s) 的协议。

也就是说在多年以前，HTTP主要用于b/s架构，而RPC更多用于c/s架构。但现在其实已经没分那么清了，b/s和c/s在慢慢融合。很多软件同时支持多端，比如某度云盘，既要支持网页版，还要支持手机端和pc端，如果通信协议都用HTTP的话，那服务器只用同一套就够了。而RPC就开始退居幕后，一般用于公司内部集群里，各个微服务之间【分布式项目】的通讯。

HTTP：超文本传输协议，是一种规定了浏览器和服务器之间通信的规则。

HTTP相关链接：https://blog.csdn.net/qq_41822345/article/details/104675572

HTTP建立过程 [socket建立过程]：

在TCP/IP五层模型下，HTTP位于应用层，需要有传输层来承载HTTP协议。传输层比较常见的协议是TCP，UDP，SCTP等。 由于UDP不可靠，SCTP有自己特殊的运用场景，所以一般情况下HTTP是由TCP协议承载的(可以使用wireshark抓包然后查看各层协议)。

使用TCP协议的话，就会涉及到TCP是如何建立起来的。面试中能够常遇到的名词三次握手，四次挥手就是在这里产生的。

所以说，要想能够对客户端http请求进行回应的话，就首先需要建立起来TCP连接，也就是socket。

4、 建立了客户端和服务器端通讯Socket后。就可以使用Socket的方法getInputStream()和getOutputStream()来创建输入/输出流。这样，使用Socket类后，网络输入输出也转化为使用流对象的过程。

5、 待通讯任务完毕后，我们用流对象的close()方法来关闭用于网络通讯的输入输出流,在用Socket对象的close()方法来关闭Socket。

  用来监听指定IP:port，一旦在该IP:port上发送请求，Tomcat服务器立马收到。所以简单来说Tomcat就是用来监听请求的。

前端url请求→cas网关认证→ngnix转发→后端IP:port/url路径

Step1：登录用户发送url请求（eg：douyu.com） 格式：协议://主机地址/路径

Step2：cas认证系统对登录用户的token进行网关认证

Step3：认证通过后交给ngnix服务器进行转发，转发到指定的服务器路径（10.128.191.19:8080/douyu/index）

  这里的10.128.191.19即为指定服务器，8080即为指定端口，douyu即为指定应用，index即为指定服务。

  前端就是通过这样一个过程访问到指定的服务的。

   通过 @RequestMapping，它是一个用来处理请求地址映射的注解，可用于类或方法上。用于类上，表示类中的所有响应请求的方法都是以该地址作为父路径。 用于方法上，表示将指定请求映射到指定方法上。

@RequestHeader 注解，可以把Request请求header部分的值绑定到方法的参数上。

@RequestParam常用来处理简单类型的绑定，通过Request.getParameter() 获取的String可直接转换为简单类型的情况 ， 因为使用request.getParameter()方式获取参数，所以可以处理get 方式中queryString的值，也可以处理post方式中 body data的值；

@RequestBody：该注解常用来处理Content-Type: 它是通过使用HandlerAdapter 配置的HttpMessageConverters来解析post data body，然后绑定到相应的bean上的。

@PathVariable：当使用@RequestMapping URI template 样式映射时， 即 someUrl/{paramId}, 这时的paramId可通过 @Pathvariable注解绑定它传过来的值到方法的参数上。

@SessionAttributes ：该注解用来绑定HttpSession中的attribute对象的值，便于在方法中的参数里使用。该注解有value、types两个属性，可以通过名字和类型指定要使用的attribute 对象；

@ModelAttribute：用于方法上时： 通常用来在处理@RequestMapping之前，为请求绑定需要从后台查询的model；用于参数上时： 用来通过名称对应，把相应名称的值绑定到注解的参数bean上。