标签：二次开发   常用   处理   不同类   rds   tran   socket编程   请求方法   流行   

OSI七层和TCP/IP四层的关系

1.1 OSI引入了服务、接口、协议、分层的概念，TCP/IP借鉴了OSI的这些概念建立TCP/IP模型。

1.2 OSI先有模型，后有协议，先有标准，后进行实践；而TCP/IP则相反，先有协议和应用再提出了模型，且是参照的OSI模型。

1.3 OSI是一种理论下的模型，而TCP/IP已被广泛使用，成为网络互联事实上的标准。

TCP：transmission control protocol 传输控制协议

UDP：user data protocol 用户数据报协议

-----------------------------------------------割了--------------------------------------------

软件开发人员 一般都在 应用层 ！

使用的常用的 TCP  UDP HTTP 

 关于IPC 进程间通信和TCP的比较

IPC，全名Inter Process Communication即进程间通讯，在同一台机器上的两个进程就用IPC，不能跨物理机器。IPC包括共享内存、队列、信号量等几种方式，由于IPC通讯效率之高，所以大量的Unix下软件都用IPC通讯，如oracle。

      TCP/IP，全名Transmission Control Protocol/Internet Protocol即传输控制协议/网间网协议，TCP/IP可在同一台机子或两台物理机或不同操作平台之间的两个进程进行通讯。标准IPC/IP通讯过程：在主机1上，应用层将一串应用数据流传送给传输层；传输层将应用层的数据流截成分组，并加上TCP报头形成TCP段，送交网络层；在网络层给TCP段加上包括源、目的主机2 IP地址的IP报头，生成一个IP数据包，并将IP数据包送交链路层；链路层在其MAC帧的数据部分装上IP数据包，再加上源、目的主机2的MAC地址和帧头，并根据其目的MAC地址，将MAC帧发往目的主机2或IP路由器。在目的主机2，链路层将MAC帧的帧头去掉，并将IP数据包送交网络层；网络层检查IP报头，如果报头中校验和与计算结果不一致，则丢弃该IP数据包；若校验和与计算结果一致，则去掉IP报头，将TCP段送交传输层；传输层检查顺序号，判断是否是正确的TCP分组，然后检查TCP报头数据。若正确，则向源主机1发确认信息；若不正确或丢包，则向源主机1要求重发信息；在目的主机2，传输层去掉TCP报头，将排好顺序的分组组成应用数据流送给应用程序。这样目的主机2接收到的来自源主机1的字节流，就像是直接接收来自源主机1的字节流一样。

       如果两个进程在同一台机子且在同一个操作平台，可选择IPC或TCI/IP两种通讯方式都可以，但IPC效率高于TCP/IP。采用IPC通讯，进程1直接把通讯包发给进程2，采用TCP/IP通讯，进程1将要先把通讯包发给“LO”即本地环路接口，通过"LO"再把通讯包发给进程2。

       如果两个进程在不同的物理机上或在不同的操作平台，则不能用IPC，这时用TCP/IP通讯，进程1把通讯包发给本机的物理网卡1，物理网卡1通过网线把通讯包发给进程2所在的机器的物理网卡2，网卡2再把通讯包发给进程2。

 IPC的几种实现方式

进程通信的方式

管道( pipe )：

管道包括三种:

• 普通管道PIPE： 通常有两种限制,一是单工,只能单向传输;二是只能在父子或者兄弟进程间使用.
• 流管道s_pipe: 去除了第一种限制,为半双工，只能在父子或兄弟进程间使用，可以双向传输.
• 命名管道:name_pipe：去除了第二种限制,可以在许多并不相关的进程之间进行通讯.

信号量( semophore ) ：

• 信号量是一个计数器，可以用来控制多个进程对共享资源的访问。它常作为一种锁机制，防止某进程正在访问共享资源时，其他进程也访问该资源。因此，主要作为进程间以及同一进程内不同线程之间的同步手段。

消息队列( message queue ) ：

• 消息队列是由消息的链表，存放在内核中并由消息队列标识符标识。消息队列克服了信号传递信息少、管道只能承载无格式字节流以及缓冲区大小受限等缺点。

信号 ( sinal ) ：

• 信号是一种比较复杂的通信方式，用于通知接收进程某个事件已经发生。

共享内存( shared memory ) ：

• 共享内存就是映射一段能被其他进程所访问的内存，这段共享内存由一个进程创建，但多个进程都可以访问。共享内存是最快的 IPC 方式，它是针对其他进程间通信方式运行效率低而专门设计的。它往往与其他通信机制，如信号两，配合使用，来实现进程间的同步和通信。

套接字( socket ) ：

• 套解口也是一种进程间通信机制，与其他通信机制不同的是，它可用于不同机器间的进程通信。

参考：https://www.linuxidc.com/Linux/2016-10/136542.htm

RPC:

RPC服务

从三个角度来介绍RPC服务：分别是RPC架构，同步异步调用以及流行的RPC框架。

RPC架构

先说说RPC服务的基本架构吧。允许我可耻地盗一幅图哈~我们可以很清楚地看到，一个完整的RPC架构里面包含了四个核心的组件，分别是Client ,Server,Client Stub以及Server Stub，这个Stub大家可以理解为存根。分别说说这几个组件：

• 客户端（Client），服务的调用方。
• 服务端（Server），真正的服务提供者。
• 客户端存根，存放服务端的地址消息，再将客户端的请求参数打包成网络消息，然后通过网络远程发送给服务方。
• 服务端存根，接收客户端发送过来的消息，将消息解包，并调用本地的方法。

RPC主要是用在大型企业里面，因为大型企业里面系统繁多，业务线复杂，而且效率优势非常重要的一块，这个时候RPC的优势就比较明显了。实际的开发当中是这么做的，项目一般使用maven来管理。比如我们有一个处理订单的系统服务，先声明它的所有的接口（这里就是具体指Java中的interface），然后将整个项目打包为一个jar包，服务端这边引入这个二方库，然后实现相应的功能，客户端这边也只需要引入这个二方库即可调用了。为什么这么做？主要是为了减少客户端这边的jar包大小，因为每一次打包发布的时候，jar包太多总是会影响效率。另外也是将客户端和服务端解耦，提高代码的可移植性。

同步调用与异步调用

什么是同步调用？什么是异步调用？同步调用就是客户端等待调用执行完成并返回结果。异步调用就是客户端不等待调用执行完成返回结果，不过依然可以通过回调函数等接收到返回结果的通知。如果客户端并不关心结果，则可以变成一个单向的调用。这个过程有点类似于Java中的callable和runnable接口，我们进行异步执行的时候，如果需要知道执行的结果，就可以使用callable接口，并且可以通过Future类获取到异步执行的结果信息。如果不关心执行的结果，直接使用runnable接口就可以了，因为它不返回结果，当然啦，callable也是可以的，我们不去获取Future就可以了。

流行的RPC框架

目前流行的开源RPC框架还是比较多的。下面重点介绍三种：

1. gRPC是Google最近公布的开源软件，基于最新的HTTP2.0协议，并支持常见的众多编程语言。 我们知道HTTP2.0是基于二进制的HTTP协议升级版本，目前各大浏览器都在快马加鞭的加以支持。 这个RPC框架是基于HTTP协议实现的，底层使用到了Netty框架的支持。
2. Thrift是Facebook的一个开源项目，主要是一个跨语言的服务开发框架。它有一个代码生成器来对它所定义的IDL定义文件自动生成服务代码框架。用户只要在其之前进行二次开发就行，对于底层的RPC通讯等都是透明的。不过这个对于用户来说的话需要学习特定领域语言这个特性，还是有一定成本的。
3. Dubbo是阿里集团开源的一个极为出名的RPC框架，在很多互联网公司和企业应用中广泛使用。协议和序列化框架都可以插拔是及其鲜明的特色。同样 的远程接口是基于Java Interface，并且依托于spring框架方便开发。可以方便的打包成单一文件，独立进程运行，和现在的微服务概念一致。

偷偷告诉你集团内部已经不怎么使用dubbo啦，现在用的比较多的叫HSF，又名“好舒服”。后面有可能会开源，大家拭目以待。

HTTP服务

其实在很久以前，我对于企业开发的模式一直定性为HTTP接口开发，也就是我们常说的RESTful风格的服务接口。的确，对于在接口不多、系统与系统交互较少的情况下，解决信息孤岛初期常使用的一种通信手段；优点就是简单、直接、开发方便。利用现成的http协议进行传输。我们记得之前本科实习在公司做后台开发的时候，主要就是进行接口的开发，还要写一大份接口文档，严格地标明输入输出是什么？说清楚每一个接口的请求方法，以及请求参数需要注意的事项等。比如下面这个例子：
POST http://www.httpexample.com/restful/buyer/info/share
接口可能返回一个JSON字符串或者是XML文档。然后客户端再去处理这个返回的信息，从而可以比较快速地进行开发。但是对于大型企业来说，内部子系统较多、接口非常多的情况下，RPC框架的好处就显示出来了，首先就是长链接，不必每次通信都要像http一样去3次握手什么的，减少了网络开销；其次就是RPC框架一般都有注册中心，有丰富的监控管理；发布、下线接口、动态扩展等，对调用方来说是无感知、统一化的操作。

总结

RPC服务和HTTP服务还是存在很多的不同点的，一般来说，RPC服务主要是针对大型企业的，而HTTP服务主要是针对小企业的，因为RPC效率更高，而HTTP服务开发迭代会更快。总之，选用什么样的框架不是按照市场上流行什么而决定的，而是要对整个项目进行完整地评估，从而在仔细比较两种开发框架对于整个项目的影响，最后再决定什么才是最适合这个项目的。一定不要为了使用RPC而每个项目都用RPC，而是要因地制宜，具体情况具体分析。

.NET Remoting/WebService/WCF/Http

Remoting和Web Service是.net中的重要技术，都可用来实现分布式系统开发，如果是不同的平台就只能选择Web Service,但如果是同一平台，就都可以选择了。到底选择那种，当然还有访问效率上的考虑，同时在Remoting中又有三中信道 Http,Tcp,Ipc，它们又各有差别。HTTP方式的信道在跨越防火墙上有优势；TCP方式的信道常用在局域网内通信，速度比HTTP快很 多；IPC信道用于同一台机器的进程间通信，通信不占用网络资源，速度又比TCP快很多。为了能够实际的比较一下这四者的实际访问速度，我写了个小程序用 测试。这个程序的实现很简单利用Remoting三种信道和Web Service 访问同一个对象（相当于实际项目中的业务层），而这个对象实现返回系统的时间。就这么简单。如果有对Remoting和Web Service不太了解的，也可以通过我这个例子熟悉一下Remoting三种信道的写法差别和Web Service的调用。

下面是程序运行的界面，我使用.net中的最小时间度量：刻度（用毫秒在本机上可能都很难测出它们之间的差别），来测试每次调用所发的时间，并通过多次调 用来测的一个平均时间来比较访问的速度。通过测试可以看得出他们四者得访问速度：ipc>tcp>http>Web Service.(其实Remoting的http信道和Web Service的访问速度还有待比较，跟测试的主机还有一定关系，在我办公室里的一台电脑上好像Web service的访问速度更快于http信道)，大家可以自己测试一下，或研究一个比较好的方法。

 

相关代码：

  1     //使用Http信道
  2     public void Http()
  3     {
  4       Stopwatch stopWatch = new Stopwatch();
  5       stopWatch.Start();
  6       MyObject myObj = (MyObject)Activator.GetObject(typeof(MyObject), "http://localhost:9001/MyObject");
  7       myObj.GetServerTime();
  8       stopWatch.Stop();
  9       lsbHttp.Items.Add(stopWatch.ElapsedTicks);
 10     }
 11      //使用Tcp信道
 12     public void Tcp()
 13     {
 14         Stopwatch stopWatch = new Stopwatch();
 15         stopWatch.Start();
 16         MyObject myObj = (MyObject)Activator.GetObject(typeof(MyObject), "tcp://localhost:9002/MyObject");
 17         myObj.GetServerTime();
 18         stopWatch.Stop();
 19         lsbTcp.Items.Add(stopWatch.ElapsedTicks);
 20     }
 21      //使用Ipc信道
 22     public void Ipc()
 23     {
 24       Stopwatch stopWatch = new Stopwatch();
 25       stopWatch.Start();
 26       MyObject myObj = (MyObject)Activator.GetObject(typeof(MyObject), "Ipc://MyHost/MyObject");
 27       myObj.GetServerTime();
 28       stopWatch.Stop();
 29       lsbIpc.Items.Add(stopWatch.ElapsedTicks);
 30     }
 31 
 32       //访问Web Service
 33     public void WebService()
 34     {
 35       Stopwatch stopWatch = new Stopwatch();
 36       stopWatch.Start();
 37       localhost.Service ws = new localhost.Service();
 38       ws.GetServerTime();
 39       stopWatch.Stop();
 40       lsbWeb.Items.Add(stopWatch.ElapsedTicks);
 41     }
 42     private void btnHttp_Click(object sender, EventArgs e)
 43     {
 44       Http();
 45     }
 46 
 47     private void btnTcp_Click(object sender, EventArgs e)
 48     {
 49       Tcp();
 50     }
 51 
 52     private void btnWebService_Click(object sender, EventArgs e)
 53     {
 54         WebService();
 55     }
 56 
 57     private void btnIpc_Click(object sender, EventArgs e)
 58     {
 59         Ipc();
 60     }
 61 
 62      //开始测试
 63     private void btnStat_Click(object sender, EventArgs e)
 64     {
 65       Int32 Times = int.Parse(txtTimes.Text);
 66       Int64 Sum = 0;
 67       double Ave=0;
 68       lsbHttp.Items.Clear();
 69       lsbIpc.Items.Clear();
 70       lsbTcp.Items.Clear();
 71       lsbWeb.Items.Clear();
 72 
 73       for (Int32 i = 0; i < Times; i++)
 74       {
 75         Http();
 76         Tcp();
 77         Ipc();
 78         WebService();
 79       }
 80        //计算平均时间
 81       for(Int32 i=0;i<Times;i++)
 82       {
 83         Sum += int.Parse(lsbHttp.Items[i].ToString ());
 84       }
 85       Ave = Sum / Times;
 86       txtHttp.Text = Ave.ToString();
 87 
 88       Sum = 0;
 89       for (Int32 i = 0; i < Times; i++)
 90       {
 91         Sum += int.Parse(lsbTcp.Items[i].ToString());
 92       }
 93       Ave = Sum / Times;
 94       txtTcp.Text = Ave.ToString();
 95 
 96       Sum = 0;
 97       for (Int32 i = 0; i < Times; i++)
 98       {
 99         Sum += int.Parse(lsbWeb.Items[i].ToString());
100       }
101       Ave = Sum / Times;
102       txtWebService.Text = Ave.ToString();
103 
104       Sum = 0;
105       for (Int32 i = 0; i < Times; i++)
106       {
107         Sum += int.Parse(lsbIpc.Items[i].ToString());
108       }
109       Ave = Sum / Times;
110       txtIpc.Text = Ave.ToString();
111     }
112       HttpChannel httpChannel = new HttpChannel(9001);
113       ChannelServices.RegisterChannel(httpChannel,false );
114 
115       TcpChannel tcpChannel = new TcpChannel(9002);
116       ChannelServices.RegisterChannel(tcpChannel,false );
117 
118       IpcChannel ipcChannel = new IpcChannel("MyHost");
119       ChannelServices.RegisterChannel(ipcChannel,false );
120 
121       RemotingConfiguration .RegisterWellKnownServiceType (typeof (RemoteObject .MyObject ),"MyObject",WellKnownObjectMode.SingleCall);
122       Console.ReadLine();

 

WebService 

C#调用WebService实例和开发

 

一、基本概念

　　Web Service也叫XML Web Service WebService是一种可以接收从Internet或者Intranet上的其它系统中传递过来的请求，轻量级的独立的通讯技术。是:通过SOAP在Web上提供的软件服务，使用WSDL文件进行说明，并通过UDDI进行注册。简单的理解就是：webservice就是放在服务器上的函数，所有人都可以调用，然后返回信息。 比如google就有一个web service ，你调用它就可以很容易的做一个搜索网站。 就像调用函数一样，传入若干参数（比如关键字、字符编码等），然后就能返回google检索的内容（返回一个字符串）。其中，

　　Soap：(Simple Object Access Protocol)简单对象存取协议。是XML Web Service 的通信协议。当用户通过UDDI找到你的WSDL描述文档后，他通过可以SOAP调用你建立的Web服务中的一个或多个操作。SOAP是XML文档形式的调用方法的规范，它可以支持不同的底层接口，像HTTP(S)或者SMTP。

　　WSDL：(Web Services Description Language) WSDL 文件是一个 XML 文档，用于说明一组 SOAP 消息以及如何交换这些消息。大多数情况下由软件自动生成和使用。

　　UDDI (Universal Description, Discovery, and Integration) 是一个主要针对Web服务供应商和使用者的新项目。在用户能够调用Web服务之前，必须确定这个服务内包含哪些商务方法，找到被调用的接口定义，还要在服务端来编制软件，UDDI是一种根据描述文档来引导系统查找相应服务的机制。UDDI利用SOAP消息机制（标准的XML/HTTP）来发布，编辑，浏览以及查找注册信息。它采用XML格式来封装各种不同类型的数据，并且发送到注册中心或者由注册中心来返回需要的数据。

 

关于通信的关键词UDP/(TCP/IP)/IPC/RPC/.NET Remoting/WebService/WCF/Http 系列

标签：二次开发   常用   处理   不同类   rds   tran   socket编程   请求方法   流行   

原文地址：https://www.cnblogs.com/micro-chen/p/9092570.html