android與伺服器通信協議
1. Android Http連接和TCP連接的區別
Http是應用層協議，TCP是網路層協議，應用層在TCP/IP四層架構中位於TCP的上一層。
建立Http連接在實現時有以下兩種方式：
1、[java] view plain
DefaultHttpClient http = new DefaultHttpClient();
HttpGet method = new HttpGet(url);
HttpResponse response =http.execute(method);
2、[java] view plain
URL url = new URL(uri);
HttpURLConnection connection = (HttpURLConnection)
url.openConnection();
connection.connect();
而TCP連接在實現時要藉助Socket（套接字 IP+埠號）
[java] view plain
Socket s = new Socket("localhost", 12345);
區別從這兩個連接的實現方式就可以看出來，HTTP連接需要指明資源的URL，發出請求的應用不知道伺服器的IP，雖然域名伺服器也是要把域名解析成IP地址，但不屬於應用所關心的范疇，是網路層應該完成的工作。所以Http連接屬於無狀態的短連接，若再請求其他數據，需要再重新建立連接。客戶端向伺服器發送請求後，伺服器才知道客戶端的存在。
TCP連接實現時需要指明IP地址和埠號，就可以跟目的主機通過三次握手建立聯系，該連接一直保持直到某一方提出取消連接，通過四次握手關閉連接。Socket支持TCP/UDP協議，如果使用TCP協議，那麼socket連接就是TCP連接。論文提到的應用場景是手機與雲端的伺服器建立聯系，因為要保持連接並指定連接的建立時間，所以在這種場景下使用TCP連接最合適。3G網路不支持端到端建立TCP連接，因為它是client-server模式，所以需要通過雲端伺服器的輔助來實現手機的端到端通信。
2. android平台的app 手機客戶端和後台伺服器怎麼進行數據交互的
首先不要管安卓端還是蘋果端，現在一般都是響應式的app，你放到安卓或者蘋果或者pc或者平板都是沒有問題的。一般採用的是http介面通訊，或者socket連接。具體你要去查資料找Demo了。而且現在主流是採用html5開發或者混合開發了。所以最好是伺服器提供appAPI介面，通過http訪問伺服器，獲取數據，數據一般是json，或者xml，拿到後解析數據就可以了，然後再用UI框架或者其他框架或者自定義的UI封裝下格式很漂亮了，至於cookie和session等，看你的習慣，網路驗證和簽名那些也自己看習慣，如果涉及到大數據，還需要引入第三方框架的，直接引入就可以了，不過推薦自己寫，防止侵權。都是很通用的。
3. android伺服器與客戶端通信最好用什麼協議 用http還是用套接字啊。打算做關於圖書館管理的android應用。。
首先基於TCP協議在Android終端和PC兩端之間形成網路虛擬鏈路。使用ServerSocket創建TCP伺服器端，然後在Android客戶端使用Socket的構造器來連接伺服器。其中Android終端通過WIFI連接和PC處於同一區域網。
1. PC伺服器啟用ServerSocket
兩個通信實體在建立虛擬鏈路之前，需要有一方先准備好，主動接受來自其他通信實體的連接請求。
使用ServerSocket對象監聽來自客戶端的Socket連接
2. Android終端使用Socket通信
客戶端使用Socket的構造器連接伺服器，指定伺服器IP和埠號就可以了。
Socket s = new Socket(「192.168.1.100」, 30000);
這樣伺服器端的accept()方法就得到響應，從而向下執行，伺服器端和客戶端就形成了一對互相連接的Socket。再進行通信時就沒有伺服器和客戶端之分了，都是通過輸入輸出流進行通信。
4. 安卓http和https的區別
HTTPS（）安全超文本傳輸協議它是一個安全通信通道，它基於HTTP開發，用於在客戶計算機和伺服器之間交換信息。它使用安全套接字層(SSL)進行信息交換，簡單來說它是HTTP的安全版。它是由Netscape開發並內置於其瀏覽器中，用於對數據進行壓縮和解壓操作，並返回網路上傳送回的結果。HTTPS實際上應用了Netscape的安全全套接字層（SSL）作為HTTP應用層的子層。（HTTPS使用埠443，而不是象HTTP那樣使用埠80來和TCP/IP進行通信。）SSL使用40位關鍵字作為RC4流加密演算法，這對於商業信息的加密是合適的。HTTPS和SSL支持使用X.509數字認證，如果需要的話用戶可以確認發送者是誰。HTTPS和HTTP的區別：https協議需要到ca申請證書，一般免費證書很少，需要交費。http是超文本傳輸協議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協議http和https使用的是完全不同的連接方式用的埠也不一樣,前者是80,後者是443。http的連接很簡單,是無狀態的HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議要比http協議安全HTTPS解決的問題：1.信任主機的問題.採用https的server必須從CA申請一個用於證明伺服器用途類型的證書.改證書只有用於對應的server的時候,客戶度才信任次主機.所以目前所有的銀行系統網站,關鍵部分應用都是https的.客戶通過信任該證書,從而信任了該主機.其實這樣做效率很低,但是銀行更側重安全.這一點對我們沒有任何意義,我們的server,採用的證書不管自己issue還是從公眾的地方issue,客戶端都是自己人,所以我們也就肯定信任該server.2.通訊過程中的數據的泄密和被竄改1.一般意義上的https,就是server有一個證書.a)主要目的是保證server就是他聲稱的server.這個跟第一點一樣.b)服務端和客戶端之間的所有通訊,都是加密的.i.具體講,是客戶端產生一個對稱的密鑰,通過server的證書來交換密鑰.一般意義上的握手過程.ii.加下來所有的信息往來就都是加密的.第三方即使截獲,也沒有任何意義.因為他沒有密鑰.當然竄改也就沒有什麼意義了.2.少許對客戶端有要求的情況下,會要求客戶端也必須有一個證書.a)這里客戶端證書,其實就類似表示個人信息的時候,除了用戶名/密碼,還有一個CA認證過的身份.應為個人證書一般來說上別人無法模擬的,所有這樣能夠更深的確認自己的身份.b)目前少數個人銀行的專業版是這種做法,具體證書可能是拿U盤作為一個備份的載體.HTTPS一定是繁瑣的.a)本來簡單的http協議,一個get一個response.由於https要還密鑰和確認加密演算法的需要.單握手就需要6/7個往返.i.任何應用中,過多的roundtrip肯定影響性能.b)接下來才是具體的http協議,每一次響應或者請求,都要求客戶端和服務端對會話的內容做加密/解密.i.盡管對稱加密/解密效率比較高,可是仍然要消耗過多的CPU,為此有專門的SSL晶元.如果CPU信能比較低的話,肯定會降低性能,從而不能serve的請求.ii.加密後數據量的影響.所以，才會出現那麼多的安全認證提示
5. Android MQTT 通信
MQTT 協議 是基於發布/訂閱模式的物聯網通信協議，憑借簡單易實現、支持 QoS、報文小等特點，占據了物聯網協議的半壁江山。
常用於 IOT 物聯網和一些需要服務端主動通知客戶端的場景。
1. 導入依賴
2. 創建 MqttHelper 輔助類，設置回調監聽
3. 連接 MQTT
連接成功或失敗，以及中途的連接掉線，會觸發 OnMqttStatusChangeListener 回調
4. MQTT 連接狀態監聽
5. MQTT 收發消息監聽
onSubMessage 訂閱的消息回調，因為存在訂閱多個 topic 的情況，所以回調能知道是來自哪個 Topic 的消息；
onPubMessage 發布的消息回調，用於確認發布的消息是否發送成功。
6. MQTT 訂閱 Topic
需要在 MQTT 連接成功後才能訂閱 topic，否則訂閱 Topic 不成功，收不到對應消息
7. MQTT 取消訂閱 Topic
8. MQTT 發布消息
9. MQTT 斷開連接
10. 通知設置
由於 MQTT 啟動了一個 Service，而 Android 8.0 以上對於後台 Service 限制時長 5 秒；所以將 MqttService 綁定到 Notification 上成為了一個前台通知；通知的標題和內容顯示可以在 strings.xml 中設置，對應屬性如下：
Android 8.0 及以上開啟前台服務綁定到通知，8.0 以下默認不啟用，可將 mqtt_foreground_notification_low_26 設為 true，將 8.0 以下設備也開啟前台通知服務
創建 MQTT 實例時需要傳送參數 MqttOptions,下面將介紹下部分參數;
1. Topic
MQTT 是一種發布/訂閱的消息協議, 通過設定的主題 Topic,
發布者向 Topic 發送的 payload 負載消息會經過伺服器, 轉發到所有訂閱襪橋
該 Topic 的訂閱者
通配符 : 假想移動端消息推送場景,有的系統消息是全體用戶接收,有的消息是 Android 或 iOS 設備接收, 又或者是某些消息具體推送到用戶,當然, 對應的多種類型消息可以通過多訂閱幾個對應的 Topic 解決,也可以使用通配符;
通配符有兩個, " + " 和 " # ", 與正斜杠 " / " 組合使用;加號只能表示一級Topic, 井號可以表示任意層級 Topic; 例如: 訂閱 Topic為 " System/+ ", 發布者發布的 Topic 可以是 System、System/Android、System/iOS; 但是不能是 System/iOS/123, 而訂閱的 Topic 如果是" System/# " 則可以收到;
注意,只有訂閱的 Topic 才可以使用 通配符, 發布和遺囑的 Topic 不能包含通配符.
2. ClientID
發布者和訂閱者都是屬於客戶端, 客戶端與服務端建立連接之後,發送的第一個報文消息必須是 Connect 消息隱好缺,而 Connect 的消息載荷中必須包含 clientID 客戶端唯一標識;
如果兩個客戶端的 clientID 一樣, 則服務端記錄第一個客戶端連接之後再收到第二個客戶端連接請求,則會向一個客戶端發送 Disconnect 報文斷開連接, 並連接第二個客戶端, 而如果此時設置了自動重連, 第一個客戶端再次連接,服務端又斷開與第二個的連接, 連上第一個客戶端, 如此將導灶辯致兩個客戶端不斷的被擠掉重連.
注意: clientID 使用的字元最好是 大小寫字母和數字, 長度最好限制在[1, 23] 之間;
3. 遺囑消息
可選參數, 客戶端沒有主動向服務端發起 disconnect 斷開連接消息,然而服務端檢測到和客戶端之間的連接已斷開, 此時服務端將該客戶端設置的遺囑消息發送出去
應用場景: 客戶端因網路等情況掉線之後, 可以及時通知到所有訂閱該遺囑 Topic 的客戶端;
遺囑 Topic 中不能存在通配符.
4. Session
客戶端和服務端之間建立的會話狀態, 一般用於消息保存, 如果設置清除 Session,則每次客戶端和服務端建立連接會創建一個新的會話,之前連接中的消息不能恢復,
而設置不清除會話, 對應發布者發送的 qos 為 1和2 的消息,還未被訂閱者接收確認,則需要保存在會話中, 以便訂閱者下次連接可以恢復這些消息;
注意: Session 存儲的消息是保存在內容中的, 所以如果不是重要的消息,最好是設置清除 Session, 或者設置 qos = 0;
5. 心跳包
標識客戶端傳輸一次控制報文到下一次傳輸之間允許的空閑時間；在這段時間內，如果客戶端沒有其他任何報文發送，必須發送一個 PINGREQ 報文到伺服器，而如果服務端在 1.5 倍心跳時間內沒有收到客戶端消息，則會主動斷開客戶端的連接，發送其遺囑消息給所有訂閱者。而服務端收到 PINGREQ 報文之後，立即返回 PINGRESP 報文給客戶端
心跳時間單位為秒，佔用2個位元組，最大 2^16 - 1 = 65535秒（18小時12分鍾15秒）,設置為 0 表示不使用心跳機制； 心跳時間一般設置為幾分鍾或幾十秒即可，時間短點可以更快的發出遺囑消息通知掉線，但是時間短會增加消息頻率，影響服務端並發； 微信長連接為 300 秒，而三大運營商貌似也有個連接時間最小的為 5 分鍾。
6. qos
服務質量等級 qos 對應兩部分,一是客戶端到服務端發送的消息, 一是服務端到客戶端訂閱的消息; 從發布者到訂閱者實際 qos 為兩段路中 qos 最小的。
qos 可選值 0(最多交付一次)、1(最少交付一次)、2(正好交付一次);
qos = 0 ：接收方不發送響應，發送方不進行重試；發送方只管發一次，不管是否發成功，也不管接收方是否成功接收，適用於不重要的數據傳輸；
qos = 1 ：確保消息至少有一次到達接收方，發送方向接收方發送消息，需要等待接收方返回應答消息，如果發送方在一定時間之內沒有收到應答，發送方繼續下一次消息發送，直到收到應答消息，刪除本地消息緩存，不再發送；所以接收方可能收到1-n次消息；適用於需要收到所有消息，客戶端可以處理重復消息。
qos = 2 ：確保消息只一次到達接收方，發送方和接收方之間消息處理流程最復雜；
Mqtt Qos 深度解讀 和 MQTT協議QoS2 准確一次送達的實現
7. payload 負載消息
位元組流類型, 是 MQTT 通信傳輸的真實數據
8. 保留消息
發布消息時設置, 對應參數 retain, 服務端將保留對應 Topic 最新的一條消息記錄; 保留消息的作用是每次客戶端連接上線都會收到其 Topic 的最後一條保留消息, 所以可能存在網路不穩定,頻繁掉線重連,每次重連重復收到保留消息;
可以向對應的 Topic 發送一條 空消息,用於清除保留消息。
MQTT 服務搭建 Apache Apollo 伺服器 搭建 MQTT 服務
Github 倉庫
mqtt 協議
6. Android socket通信協議的封裝和解析
android socket通信協議的封裝和解析，其實是和java一樣的，都是通過http中的相關知識來封裝和解析，主要是通過多次握手，如下代碼：
importjava.io.BufferedReader;
importjava.io.BufferedWriter;
importjava.io.IOException;
importjava.io.InputStreamReader;
importjava.io.OutputStreamWriter;
importjava.io.PrintWriter;
importjava.net.ServerSocket;
importjava.net.Socket;
importjava.util.ArrayList;
importjava.util.List;
importjava.util.concurrent.ExecutorService;
importjava.util.concurrent.Executors;
publicclassMain{
privatestaticfinalintPORT=9999;
privateList<Socket>mList=newArrayList<Socket>();
privateServerSocketserver=null;
=null;//threadpool
publicstaticvoidmain(String[]args){
newMain();
}
publicMain(){
try{
server=newServerSocket(PORT);
mExecutorService=Executors.newCachedThreadPool();//createathreadpool
System.out.println("伺服器已啟動...");
Socketclient=null;
while(true){
client=server.accept();
//把客戶端放入客戶端集合中
mList.add(client);
mExecutorService.execute(newService(client));//
}
}catch(Exceptione){
e.printStackTrace();
}
}
{
privateSocketsocket;
privateBufferedReaderin=null;
privateStringmsg="";
publicService(Socketsocket){
this.socket=socket;
try{
in=newBufferedReader(newInputStreamReader(socket.getInputStream()));
//客戶端只要一連到伺服器，便向客戶端發送下面的信息。
msg="伺服器地址："+this.socket.getInetAddress()+"cometoal:"
+mList.size()+"（伺服器發送）";
this.sendmsg();
}catch(IOExceptione){
e.printStackTrace();
}
}
@Override
publicvoidrun(){
try{
while(true){
if((msg=in.readLine())!=null){
//當客戶端發送的信息為：exit時，關閉連接
if(msg.equals("exit")){
System.out.println("ssssssss");
mList.remove(socket);
in.close();
msg="user:"+socket.getInetAddress()
+"exittotal:"+mList.size();
socket.close();
this.sendmsg();
break;
//接收客戶端發過來的信息msg，然後發送給客戶端。
}else{
msg=socket.getInetAddress()+":"+msg+"（伺服器發送）";
this.sendmsg();
}
}
}
}catch(Exceptione){
e.printStackTrace();
}
}
/**
*循環遍歷客戶端集合，給每個客戶端都發送信息。
*/
publicvoidsendmsg(){
System.out.println(msg);
intnum=mList.size();
for(intindex=0;index<num;index++){
SocketmSocket=mList.get(index);
PrintWriterpout=null;
try{
pout=newPrintWriter(newBufferedWriter(
newOutputStreamWriter(mSocket.getOutputStream())),true);
pout.println(msg);
}catch(IOExceptione){
e.printStackTrace();
}
}
}
}
}