關於通信的關鍵詞UDP/(TCP/IP)/IPC/RPC/.NET Remoting/WebService/WCF/Http 系列

阿新 • • 發佈：2018-05-26

分別是 scrip 接收 callable dsp ip協議阿裏互聯 otto

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

Socket是TCP/IP協議的API TCP是數據的介質,Socket是TCP的介質. 查了一下RFC文檔,Socket是RFC147,更新時間是1971年.TCP是RFC793,更新時間是1981年.Socket在ARPA網就出現了. 應該說TCP是socket上的一種通信協議. http://bbs.csdn.net/topics/320251688 http://www.cnblogs.com/riacool/archive/2010/12/14/1905404.html

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

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格式來封裝各種不同類型的數據，並且發送到註冊中心或者由註冊中心來返回需要的數據。

參考： https://www.cnblogs.com/peterpc/p/4628441.html WCF 1、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 在實際項目中，根據不同的場景使用不同的策略。結束：時代在進步。。。。。。。。。。

關於通信的關鍵詞UDP/(TCP/IP)/IPC/RPC/.NET Remoting/WebService/WCF/Http 系列

分別是 scrip 接收 callable dsp ip協議阿裏互聯 otto OSI七層和TCP/IP四層的關系 1.1 OSI引入了服務、接口、協議、分層的概念，TCP/IP借鑒了OSI的這些概念建立TCP/IP模型。 1.2 OSI先有模型，後有協議，先

關於通信的關鍵詞UDP/(TCP/IP)/IPC/RPC/.NET Remoting/WebService/WCF/Http 系列

TCP/IP和Socket的關系