OSI七层和TCP/IP四层的关系html
1.1 OSI引入了服务、接口、协议、分层的概念，TCP/IP借鉴了OSI的这些概念创建TCP/IP模型。java
1.2 OSI先有模型，后有协议，先有标准，后进行实践；而TCP/IP则相反，先有协议和应用再提出了模型，且是参照的OSI模型。linux
1.3 OSI是一种理论下的模型，而TCP/IP已被普遍使用，成为网络互联事实上的标准。程序员
TCP：transmission control protocol 传输控制协议web
UDP：user data protocol 用户数据报协议面试
| OSI七层网络模型spring |
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
Socket是TCP/IP协议的API
TCP是数据的介质,Socket是TCP的介质.
查了一下RFC文档,Socket是RFC147,更新时间是1971年.TCP是RFC793,更新时间是1981年.Socket在ARPA网就出现了.
应该说TCP是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
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
1、基本概念
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格式来封装各类不一样类型的数据，而且发送到注册中心或者由注册中心来返回须要的数据。
参考：
https://www.cnblogs.com/peterpc/p/4628441.html
WCF
一、WCF是什么？
从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宿主。在宿主内部，则封装了通道堆栈，其中又包含了对协议、编码、消息传输、代理的处理。而在通道层的顶部，还提供了一个高级运行时，以针对应用程序的开发人员。
参考：http://www.cnblogs.com/wayfarer/archive/2008/04/15/1153775.html
Http、Https系：
WebService
WCF也支持
Webform
Mvc
WebApi
在实际项目中，根据不一样的场景使用不一样的策略。
结束：时代在进步。。。。。。。。。。
