协议签字了反悔有效吗 http请求的过程与原理?
http请求的过程与原理?
其工作过程分为四步:
1.客户机与服务器建立连接:客户单击某个超级链接,HTTP的工作开始,接下来进行TCP连接的三次握手过程。
2.建立连接后,客户几发送一个请求给服务器,请求方式的格式为:统一资源标识符(URL)、协议版本号、MIME信息(包括请求修饰符、客户机信息和可能的内容)。
3.服务器接到请求后,给予相应的响应信息,其格式为:一个状态行(包括信息的协议版本号)、一个成功或错误的代码、后面的是MIME信息(包括服务器信息、实体信息、可能的内容)。
4.客户端接收到服务器所返回的信息,通过浏览器显示在用户的显示屏上,然后客户机与服务器断开连接。客户端收到服务器信息后,向服务器发送一个确认包,此包发送完毕,表示完成三次握手。
微服务调用为啥用RPC框架,http不更简单吗?
简单点,HTTP是协议,RPC是概念!实现RPC可以基于HTTP协议(Feign),TCP协议(Netty),RMI协议(Soap),WebService(XML—RPC)框架。传输过程中,也因为序列化方式的不同,又有一些框架和协议,比如Dubbo中的Dubbo协议,gRpc—Protobuf序列化协议等等。其实,都是基于远程调用的概念,何为远程调用?
重点是,RPC就是远程调用,远程调用就是客户端把调用的接口,参数,参数类型,方法,返回值,返回值类型等(这些称为方法签名),通过如上的协议,发送给服务端,告知服务端需要调用的接口方法,这个过程就是RPC的实现过程!HTTP和RPC是不同层面的两个东西!
性能方面,HTTP本身是基于TCP协议的,属于应用层协议,所以HTTP协议本身在实现过程中就会占用大量的资源(内存,带宽等),性能上肯定没有通过TCP直接实现RPC协议快,不管HTTP如何优化肯定的是不如TCP的!而TCP则是依靠字节码,现在普遍采用的是将客户端调用的接口信息,序列化的方式发送给服务端,序列化框架又包含很多(Hession,Protobuf,Kryo等等,序列化性能最高的是Kryo,序列化后字节码最小的是Protobuf),序列化后的字节码越小,占用带宽越少,序列化时间越短,线程IO等待时间就会越小。所以,在具体应用层面有很多可探讨的技术,可以根据自己的硬件能力来选择相应的技术就可以了!
欢迎热爱技术的人来探讨!
版权声明:本文内容由互联网用户自发贡献,本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。