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
在實際項目中，根據不一樣的場景使用不一樣的策略。
結束：時代在進步。。。。。。。。。。
