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 用户数据报协议
|
OSI七层网络模型 |
TCP/IP四层概念模型 |
对应网络协议 |
|
应用层（Application） |
应用层 |
HTTP、TFTP, FTP, NFS, WAIS、SMTP |
|
表示层（Presentation） |
Telnet, Rlogin, SNMP, Gopher |
|
|
会话层（Session） |
SMTP, DNS |
|
|
传输层（Transport） |
传输层 |
TCP, UDP |
|
网络层（Network） |
网络层 |
IP, ICMP, ARP, RARP, AKP, UUCP |
|
数据链路层（Data Link） |
数据链路层 |
FDDI, Ethernet, Arpanet, PDN, SLIP, PPP |
|
物理层（Physical） |
IEEE 802.1A, IEEE 802.2到IEEE 802.11 |
-----------------------------------------------割了--------------------------------------------
软件开发人员 一般都在 应用层 ！
使用的常用的 TCP UDP HTTP
TCP/IP和Socket的关系
要写网络程序就必须用Socket，这是程序员都知道的。而且，面试的时候，我们也会问对方会不会Socket编程？一般来说，很多人都会说，Socket编程基本就是listen，accept以及send，write等几个基本的操作。是的，就跟常见的文件操作一样，只要写过就一定知道。
对于网络编程，我们也言必称TCP/IP，似乎其它网络协议已经不存在了。对于TCP/IP，我们还知道TCP和UDP，前者可以保证数据的正确和可靠性，后者则允许数据丢失。最后，我们还知道，在建立连接前，必须知道对方的IP地址和端口号。除此，普通的程序员就不会知道太多了，很多时候这些知识已经够用了。最多，写服务程序的时候，会使用多线程来处理并发访问。
来自：https://blog.csdn.net/haonan108/article/details/52288112
来自:https://www.cnblogs.com/LUO77/p/5801977.html
关于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框架还是比较多的。下面重点介绍三种：
- gRPC是Google最近公布的开源软件，基于最新的HTTP2.0协议，并支持常见的众多编程语言。 我们知道HTTP2.0是基于二进制的HTTP协议升级版本，目前各大浏览器都在快马加鞭的加以支持。 这个RPC框架是基于HTTP协议实现的，底层使用到了Netty框架的支持。
- Thrift是Facebook的一个开源项目，主要是一个跨语言的服务开发框架。它有一个代码生成器来对它所定义的IDL定义文件自动生成服务代码框架。用户只要在其之前进行二次开发就行，对于底层的RPC通讯等都是透明的。不过这个对于用户来说的话需要学习特定领域语言这个特性，还是有一定成本的。
- 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
.NET Remoting三种信道Http,Tcp,IPC和Web Service的访问速度比较(转)
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格式来封装各种不同类型的数据，并且发送到注册中心或者由注册中心来返回需要的数据。
从WCF所处的位置来看，它是包含在.NET 3.0（也包括.NET 3.5）之中的。我们注意比较.NET 3.0与.NET 2.0，其实唯一的区别就是.NET 3.0包含了WCF、WPF、WF（或者还有CardSpace）而已。因此，我们认为WCF是.NET框架的一部分，似乎并不为过。尤为关键的是，WCF并不能脱离.NET框架而单独存在（但非WCF客户端可以调用WCF服务），因此，虽然WCF是微软用以应对SOA解决方案的开发需求而专门推出的，但它并不是例如Spring、Struts那样的框架，也不是像EJB那样的容器或者服务器。微软真正符合SOA企业应用服务器角色的，我想应该是Biztalk Server。
严格的说，WCF就是专门用于服务定制、发布与运行以及消息传递和处理的一组专门类的集合，也就是所谓的“类库”。这些类通过一定方式被组织起来，共同协作，并为开发者提供了一个统一的编程模式。WCF之所以特殊，是在于它所应对的场景与普通的.NET类库不同，它主要用于处理进程间乃至于机器之间消息的传递与处理，同时它引入了SOA的设计思想，以服务的方式公布并运行，以方便客户端跨进程和机器对服务进行调用。实际上，WCF就是微软对于分布式处理的编程技术的集大成者，它将DCOM、Remoting、Web Service、WSE、MSMQ集成在一起，从而降低了分布式系统开发者的学习曲线，并统一了开发标准。
WCF与其它类库还有不同的地方，则在于WCF充分地体现了运行时环境的概念。对于早期使用WCF的开发人员而言，就可能知道如果在.NET 2.0下要开发WCF，还需要专门下载一个Runtime Component 3.0版，其中就包含了WCF、WF等内容。在.NET中一贯存在所谓“宿主”的概念，整个.NET Framework（或者说是CLR）就可以认为是一个大的宿主，就像Java的虚拟机一样。由于WCF对服务有着专门的需求，对于服务端，需要发布和运行服务；对于客户端，则需要调用服务；因而对于开发者，就需要编写定义、发布、运行、调用服务的相关代码。而服务就只能运行在特定的宿主上，这些宿主可以是控制台应用程序进程、Windows或Web应用程序进程，也可以是Windows服务进程，或者为最常用的IIS宿主。在宿主内部，则封装了通道堆栈，其中又包含了对协议、编码、消息传输、代理的处理。而在通道层的顶部，还提供了一个高级运行时，以针对应用程序的开发人员。