http、TCP/IP協議與socket、udp、webservice 等差異

計算機層級劃分以下：

1、網絡層協議：

定義：網絡層協議主要應用於主機與主機之間的相互通訊。網絡層提供路由和尋址的功能，使兩終端系統可以互連且決定最佳路徑，並具備必定的擁塞控制和流量控制的能力。

應用：網際協議IP、Internet互聯網控制報文協議ICMP、Internet組織管理協議IGMP、地址解析協議ARP。

2、傳輸層協議

定義：傳輸層協議主要用於主機的進程與進程之間的相互通訊

應用：傳輸控制協議TCP和用戶數據報協議UDP

1.TCP協議：

面向鏈接的可靠傳輸協議。利用TCP進行通訊時，首先要經過三步握手，以創建通訊雙方的鏈接。TCP提供了數據的確認和數據重傳的機制，保證發送的數據必定能到達通訊的對方。

TCP鏈接「三次握手」：
第一次握手：客戶端發送syn包(syn=j)到服務器，並進入SYN_SEND狀態，等待服務器確認；
第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時本身也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態；
第三次握手：客戶端收到服務器的SYN＋ACK包，向服務器發送確認包ACK(ack=k+1)，此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手。

SYN(synchronous創建聯機)
ACK(acknowledgement 確認)
FIN(finish結束)

握手過程當中傳送的包裏不包含數據，三次握手完畢後，客戶端與服務器才正式開始傳送數據。理想狀態下，TCP鏈接一旦創建，在通訊雙方中的任何一方主動關閉鏈接以前，TCP 鏈接都將被一直保持下去。

斷開鏈接時「四次揮手」：（是爲了保證傳輸已完成）

爲何要4次揮手？
確保數據可以完整傳輸。
當被動方收到主動方的FIN報文通知時，它僅僅表示主動方沒有數據再發送給被動方了。
但未必被動方全部的數據都完整的發送給了主動方，因此被動方不會立刻關閉SOCKET,它可能還須要發送一些數據給主動方後，
再發送FIN報文給主動方，告訴主動方贊成關閉鏈接，因此這裏的ACK報文和FIN報文多數狀況下都是分開發送的。

2.UDP協議：

是無鏈接的，不可靠的傳輸協議。採用UDP進行通訊時不用創建鏈接，能夠直接向一個IP地址發送數據，可是不能保證對方是否能收到。（就像發生短信，只須要知道對方手機號碼就行，至於對方是否接收成功無論）

 

3、應用層協議

1.應用舉例：

1).超文本傳輸協議（HTTP）默認使用了TCP的80端口號 ：

HTTP是一個無狀態的協議；HTTP協議是創建在TCP協議之上的一種應用;因爲HTTP在每次請求結束後都會主動釋放鏈接，所以HTTP鏈接是一種「短鏈接」，要保持客戶端程序的在線狀態

a.在HTTP 1.0中，客戶端的每次請求都要求創建一次單獨的鏈接，在處理完本次請求後，就自動釋放鏈接。

b.在HTTP 1.1中則能夠在一次鏈接中處理多個請求，而且多個請求能夠重疊進行，不須要等待一個請求結束後再發送下一個請求。

2).文件傳輸協議（FTP）默認使用TCP的21端口號 
3).遠程登陸協議（Telnet)默認使用了TCP的23端口號 
4).簡單郵件傳輸協議（SMTP）默認使用了TCP的25端口號 
5).域名服務協議（DNS）默認使用了UDP的53端口號 
6).RIP協議默認使用了UDP的520端口號 
7).DHCP協議默認使用了UDP的67端口號

2.HTTP協議的工做流程  

一次HTTP操做稱爲一個事務，其工做過程可分爲四步：  

1）首先客戶機與服務器須要創建鏈接。只要單擊某個超級連接，HTTP的工做開始。 

 2）創建鏈接後，客戶機發送一個請求給服務器，請求方式的格式爲：統一資源標識符（URL）、協議版本號，後邊是MIME信息包括請求修飾符、客戶機信息和可能的內容。 

 3）服務器接到請求後，給予相應的響應信息，其格式爲一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，後邊是MIME信息包括服務器信息、實體信息和可能的內容。  

4）客戶端接收服務器所返回的信息經過瀏覽器顯示在用戶的顯示屏上，而後客戶機與服務器斷開鏈接。  若是在以上過程當中的某一步出現錯誤，那麼產生錯誤的信息將返回到客戶端，有顯示屏輸出。

3.web service相對http (post/get)有好處嗎？

二者差異:這兩個是徹底不一樣的概念，http是一種網絡協議，而webservice是一種兩個應用程序之間實現通訊的解決方

1).接口中實現的方法和要求參數一目瞭然

2).不用擔憂大小寫問題

3).不用擔憂中文urlencode問題

4).代碼中不用屢次聲明認證(帳號,密碼)參數

5).傳遞參數能夠爲數組，對象等...

6).因爲要進行xml解析，速度可能會有所下降。

4.Socket鏈接與HTTP鏈接

Socket是操做系統提供的一個編程接口，經過socket來調用系統內核中處理網絡協議的模塊，咱們只須要提供所要傳輸的內容就能夠了；咱們並不須要知道具體怎麼構成一個UDP包。Socket能夠支持不一樣的傳輸層協議（TCP或UDP），當使用TCP協議進行鏈接時，該Socket鏈接就是一個TCP鏈接。Socket自己並非協議，而是一個調用接口（API）

HTTP鏈接使用的是「請求—響應」的方式，不只在請求時須要先創建鏈接，並且須要客戶端向服務器發出請求後，服務器端才能回覆數據；若雙方創建的是Socket鏈接，服務器就能夠直接將數據傳送給客戶端；若雙方創建的是HTTP鏈接，則服務器須要等到客戶端發送一次請求後才能將數據傳回給客戶端

5.FTP和HTTP文件上傳方式區別

FTP(File Transfer Protocol，文件傳輸協議是Internet上使用很是普遍的一種通信協議，它是爲Internet用戶進行文件傳輸(包括文件的上傳和下載)而制定的。要想實現FTP文件傳輸，必須在相連的兩端都裝有支持FTP協議的軟件； FTP方式慢慢已不建議採用；

HTTP是一個屬於應用層的面向對象的協議，因爲其簡捷、快速的方式，適用於分佈式超媒體信息系統。

6.長鏈接和短鏈接區別

短鏈接 
鏈接->傳輸數據->關閉鏈接 
HTTP是無狀態的，瀏覽器和服務器每進行一次HTTP操做，就創建一次鏈接，到任務結束就中斷鏈接。 
也能夠這樣說：短鏈接是指SOCKET鏈接後發送後接收完數據後立刻斷開鏈接。 
長鏈接 
鏈接->傳輸數據->保持鏈接 -> 傳輸數據-> 。。。 ->關閉鏈接。 
長鏈接指創建SOCKET鏈接後不論是否使用都保持鏈接，但安全性較差。這就要求長鏈接在沒有數據通訊時，定時發送數據包(心跳)，以維持鏈接狀態，短鏈接在沒有數據傳輸時直接關閉就好了。

7.java socket半包、粘包問題解決方案

1）以特殊字符串好比/r、/n做爲數據的結尾，這樣就能夠區分數據包了。
2）發送請求包的時候只發送固定長度的數據包，這樣在服務端接收數據也只接收固定長度的數據，這種方法效率過低，不太合適頻繁的數據包請求。
3）在tcp協議的基礎上封裝一層數據請求協議，既數據包=數據包長度+數據包內容，這樣在服務端就能夠知道每一個數據包的長度，也就能夠解決半包、粘包問題

八、進程間通信的方式有哪些，各有什麼優缺點：

1）管道：管道是一種半雙工的通訊方式，數據只能單向流動，並且只能在具備親緣關係的進程之間使用。進程的親緣關係一般是指父子進程關係。

2）有名管道（FIFO）：有名管道也是半雙工的通訊方式，可是容許在沒有親緣關係的進程之間使用，管道是先進先出的通訊方式。

3）信號量：信號量是一個計數器，能夠用來控制多個進程對共享資源的訪問。它常做爲一種鎖機制，防止某進程正在訪問共享資源時，其餘進程也訪問該資源。所以，主要做爲進程間以及同一進程內不一樣線程之間的同步手段。

4）消息隊列：消息隊列是有消息的鏈表，存放在內核中並由消息隊列標識符標識。消息隊列克服了信號傳遞信息少、管道只能承載無格式字節流以及緩衝區大小受限等缺點。

5）信號 ( sinal ) ：信號是一種比較複雜的通訊方式，用於通知接收進程某個事件已經發生。

6）共享內存( shared memory ) ：共享內存就是映射一段能被其餘進程所訪問的內存，這段共享內存由一個進程建立，但多個進程均可以訪問。共享內存是最快的 IPC 方式，它是針對其餘進程間通訊方式運行效率低而專門設計的。它每每與其餘通訊機制，如信號量，配合使用，來實現進程間的同步和通訊。 7）套接字( socket ) ：套接字也是一種進程間通訊機制，與其餘通訊機制不一樣的是，它可用於不一樣機器間的進程通訊。