androidhttp原理

❶ 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模式，所以需要通過雲端伺服器的輔助來實現手機的端到端通信。

❷ Android編程http，怎麼提取自己輸入的網址

你可以寫一個類如：public void UrlConfig{ public static String url= "" } 定義一個靜態成員變數。 而HttpGet httpGet=new HttpGet(UrlConfig.url);在這里我們就直接用這個變數，這樣就可以不改變源代碼（處理連接的代碼） , 當文本輸入了網址之後獲取到文本的值，然後再賦給這個變數，就OK了。 另外你的netAddress類型可聲明成Stringedit 在Text.getText().toString().得到值。

❸ Android面試筆記——HTTP/HTTPS

HTTP和HTTPS是面試常問的問題，內容比較多而且復雜，HTTPS裡面的細節很多，本文只是把主要的東西寫出來，想要弄懂HTTPS還是要多看幾篇博文，自己動手走一遍把各個攻擊的case搞明白。

HTTP 是超⽂本傳輸協議，也就是HyperText Transfer Protocol。

Host 欄位 ：客戶端發送請求時，⽤來指定伺服器的域名。 Host: www..com

Content-Length 欄位 ：伺服器在返回數據時，會有 Content-Length 欄位，表明本次回應的數據長度。 Content-Length: 1000

Connection 欄位 ：Connection 欄位最常用於客戶端要求伺服器使⽤ TCP 持久連接，以便其他請求復⽤。 HTTP/1.1 版本的默認連接都是持久連接，但為了兼容⽼版本的 HTTP，需要指定 Connection ⾸部欄位的值為Keep-Alive 。

Content-Type 欄位 ：Content-Type 欄位⽤於伺服器回應時，告訴客戶端，本次數據是什麼格式 。 Content-Type: text/html; charset=utf-8

Content-Encoding 欄位 ：Content-Encoding 欄位說明數據的壓縮⽅法。表示伺服器返回的數據使用了什麼壓縮格式 。客戶端在請求時，⽤ Accept-Encoding 欄位說明自己可以接受哪些壓縮⽅法。 Accept-Encoding: gzip, deflate

下圖為訪問網路的返回欄位

HTTP/2 協議是基於 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。

這都是基於 TCP 傳輸層的問題，所以 HTTP/3 把 HTTP 下層的 TCP 協議改成了 UDP 。

UDP 發生是不管順序，也不管丟包的，所以不會出現 HTTP/1.1 的隊頭阻塞 和 HTTP/2 的⼀個丟包全部重傳問題。

UDP 是不可靠傳輸的，但基於 UDP 的 QUIC 協議 可以實現類似 TCP 的可靠性傳輸。

HTTPS 采⽤的是 對稱加密和⾮對稱加密結合 的「混合加密」⽅式：

采⽤「混合加密」的⽅式的原因：

摘要演算法⽤來實現 完整性 ，能夠為數據⽣成獨⼀⽆⼆的「指紋」，⽤於校驗數據的完整性，解決了篡改的⻛險。

客戶端在發送明⽂之前會通過摘要演算法算出明文的「指紋」，發送的時候把「指紋 + 明文」⼀同加密成密文後，發送給伺服器，伺服器解密後，用相同的摘要演算法算出發送過來的明文，通過⽐較客戶端攜帶的「指紋」和當前算出的「指紋」做⽐較，若「指紋」相同，說明數據是完整的。

客戶端先向伺服器端索要公鑰，然後⽤公鑰加密信息，伺服器收到密文後，⽤⾃⼰的私鑰解密。這就存在些問題，如何保證公鑰不被篡改和信任度？

所以這⾥就需要藉助第三⽅權威機構 CA （數字證書認證機構），將伺服器公鑰放在數字證書（由數字證書認證機構頒發）中，只要證書是可信的，公鑰就是可信的。

通過數字證書的⽅式保證伺服器公鑰的身份，解決冒充的⻛險 。

證書簽名和驗證過程 ：

兩種情況 ：

❹ android怎麼實現HTTP長連接

轉載 這種功能實際上就是數據同步，同時要考慮手機本身、電量、網路流量等等限制因素，所以通常在移動端上有一下兩個解決方案: 1.一種是定時去server查詢數據，通常是使用HTTP協議來訪問web伺服器，稱Polling（輪詢）； 2.還有一種是移動端和伺服器建立長連接，使用XMPP長連接，稱Push（推送）。 從耗費的電量、流量和數據延遲性各方面來說，Push有明顯的優勢。但是使用Push的缺點是： 對於客戶端：實現和維護相對成本高，在移動無線網路下維護長連接，相對有一些技術上的開發難度。 對於伺服器：如何實現多核並發，cpu作業調度，數量龐大的長連接並發維護等技術，仍存在開發難點。 在講述Push方案的原理前，我們先了解一下移動無線網路的特點。 移動無線網路的特點： 因為 IP v4 的 IP 量有限，運營商分配給手機終端的 IP 是運營商內網的 IP，手機要連接 Internet，就需要通過運營商的網關做一個網路地址轉換（Network Address Translation，NAT）。簡單的說運營商的網關需要維護一個外網 IP、埠到內網 IP、埠的對應關系，以確保內網的手機可以跟 Internet 的伺服器通訊 GGSN（Gateway GPRS Support Node 網關GPRS支持結點）模塊就實現了NAT功能。 因為大部分移動無線網路運營商都是為了減少網關的NAT映射表的負荷，所以如果發現鏈路中有一段時間沒有數據通訊時，會刪除其對應表，造成鏈路中斷。（關於NAT的作用及其原理可以查看我的另一篇博文：關於使用UDP(TCP)跨區域網，NAT穿透的心得） Push在Android平台上長連接的實現： 既然我們知道我們移動端要和Internet進行通信，必須通過運營商的網關，所以，為了不讓NAT映射表失效，我們需要定時向Internet發送數據，因為只是為了不然NAT映射表失效，所以只需發送長度為0的數據即可。 這時候就要用到定時器，在android系統上，定時器通常有一下兩種： 1.java.util.Timer 2.android.app.AlarmManager 分析： Timer:可以按照計劃或者時間周期來執行相關的任務。但是Timer需要用WakeLock來讓CPU保持喚醒狀態，才能保證任務的執行，這樣子會消耗大量流量；當CPU處於休眠的時候，就不能喚醒執行任務，所以應用於移動端明顯是不合適。 AlarmManager：AlarmManager類是屬於android系統封裝好來管理RTC模塊的管理類。這里就涉及到RTC模塊，要更好地了解兩者的區別，就要明白兩者真正的區別。 RTC（Real- Time Clock）實時鬧鍾在一個嵌入式系統中，通常採用RTC 來提供可靠的系統時間，包括時分秒和年月日等;而且要求在系統處於關機狀態下它也能夠正常工作（通常採用後備電池供電），它的外圍也不需要太多的輔助電路，典型的就是只需要一個高精度的32.768KHz 晶體和電阻電容等。（如果對這方面感興趣，可以自己查閱相關資料，這里就說個大概） 好了，回來正題。所以，AlarmManager又稱全局定時鬧鍾。這意味著，當我用使用AlarmManager來定時執行任務，CPU可以正常地休眠，只有在執行任務是，才喚醒CPU，這個過程是很短時間的。 下面簡單來說明其使用： 1.類似於Timer功能： //獲得鬧鍾管理器 AlarmManager am = (AlarmManager)getSystemService(ALARM_SERVICE); //設置任務執行計劃 am.setRepeating(AlarmManager.ELAPSED_REALTIME, firstTime, 5*1000, sender);//從firstTime才開始執行，每隔5秒再執行 2.實現全局定時功能： //獲得鬧鍾管理器 AlarmManager am = (AlarmManager)getSystemService(ALARM_SERVICE); //設置任務執行計劃 am.setRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP, firstTime, 5*1000, sender);//從firstTime才開始執行，每隔5秒再執行 總結：在android客戶端使用Push推送時，應該使用AlarmManager來實現心跳功能，使其真正實現長連接。

❺ Android網路請求庫【OkHttp4.9.3】基本用法與原理分析

OkHttp是一套處理 HTTP 網路請求的依賴庫，由 Square 公司設計研發並開源，目前可以在 Java 和 Kotlin 中使用。對於 Android App 來說，OkHttp 現在幾乎已經占據了所有的網路請求操作，Retrofit + OkHttp實現網路請求似乎成了一種標配。因此它也是每一個 Android 開發工程師的必備技能，了解其內部實現原理可以更好地進行功能擴展、封裝以及優化。

OkHttp的高效性體現在：

第一步：創建OkHttpClient，創建OkHttpClient有兩種方式：

OkHttpClient提供了豐富的配置方法，例如添加攔截器、指定連接池、設置請求超時等等。

第二步：創建請求

使用Request.Builder() 構建Request實例

第三步：發起網路請求

OkHttp支持同步和非同步兩種請求方式

OkHttp的使用方法非常簡單，三步操作就可以發起一個簡單的同步或非同步請求。我們也可以很輕松地對網路請求進行配置，例如添加請求頭、設置請求方式、設置請求超時等等，這些配置參數會在源碼分析過程中詳細介紹。

現在我們已經學會了三步操作發起網路請求，接下來以這三個步驟為切入點，深入到源碼中學習OkHttp的實現原理，廢話少說馬上開車。

OkHttpClient創建方式有兩種，我們看看兩種方式有什麼區別。

第一種直接使用默認構造函數，內部依然是使用建造者模式

第二種使用建造者模式

兩種方式最終都是調用構造函數OkHttpClient(builder:Builder)，由參數builder負責所有的參數配置工作。

當您創建單個OkHttpClient實例並將其用於所有 HTTP 調用時，OkHttp 性能最佳。 這是因為每個OkHttpClient都擁有自己的連接池和線程池，重用連接和線程可減少延遲並節省內存。 相反，為每個請求創建一個客戶端會浪費空閑池上的資源。

Request同樣使用建造者模式來創建，這里貼上部分重要源碼，很簡單就不細說了。

OkHttp發起網路請求分為同步請求和非同步請求兩種方式，我們只分析非同步請求流程，因為只要理解了非同步請求過程，基本上也就明白同步請求是怎麼一回事了。

RealCall是連接應用層與網路層的橋梁，負責處理連接、請求、響應和數據流。

Dispatcher維護著一套非同步任務執行策略，分析策略之前先介紹幾個重要概念：

client.dispatcher.enqueue(AsyncCall(responseCallback)) 執行步驟為：

AsyncCall實現了Runnable介面，因此一旦被線程池中的線程處理就會調用它的run()方法：

話休絮煩，我們開始分析攔截器責任鏈：

責任鏈執行流程：首先獲取當前攔截器interceptor，並且調用interceptor.intercept(next)執行攔截器操作。這里的next表示的是index+1後的責任鏈對象，攔截器的intercept()方法內部會調用next.proceed(request)方法再次進入到責任鏈，由於此時index已經加1，所以處理的是下一個攔截器。

如此循環往復，直到處理完責任鏈上最後一個攔截器為止。

注意除最後一個攔截器CallServerInterceptor不會調用chain.proceed(request)方法之外，其他攔截器都應該至少調用一次chain.proceed(request)方法。

為了驗證上面的結論，我們進入到RetryAndFollowUpInterceptor的intercept()方法一探究竟：

可以看到注釋1處重新進入責任鏈處理下一個攔截器。

有興趣可以自行查看最後一個攔截器CallServerInterceptor源碼，此處只給出本人閱讀源碼後得出的結論：

以上就是攔截器責任鏈的工作流程，我們再通過流程圖仔細感受一下。

分析完攔截器責任鏈，我們繼續分析AsyncCall#run()方法：

我們看到，如果()方法成功獲得服務端返回的數據，則調用responseCallback.onResponse(this@RealCall, response)方法完成非同步回調；如果服務端數據獲取失敗（請求異常），則調用responseCallback.onFailure(this@RealCall, canceledException)方法完成非同步回調

需要注意的是，responseCallback回調是在子線程中完成的，所以如果想把數據顯示到UI上，需要切換回主線程進行UI操作。

OkHttp發起網路請求全過程：

【知識點】OkHttp 原理 8 連問

❻ android http-httpclient與HttpURLConnection有什麼不同

最近在研究Volley框架的源碼，發現它在HTTP請求的使用上比較有意思，在Android 2.3及以上版本，使用的是HttpURLConnection，而在Android 2.2及以下版本，使用的是HttpClient。我也比較好奇這么使用的原因，於是專門找到了一位Google的工程師寫的一篇博客，文中對HttpURLConnection和HttpClient進行了對比，下面我就給大家簡要地翻譯一下。
原文地址：http://android-developers.blogspot.com/2011/09/androids-http-clients.html
大多數的Android應用程序都會使用HTTP協議來發送和接收網路數據，而Android中主要提供了兩種方式來進行HTTP操作，HttpURLConnection和HttpClient。這兩種方式都支持HTTPS協議、以流的形式進行上傳和下載、配置超時時間、IPv6、以及連接池等功能。
HttpClient
DefaultHttpClient和它的兄弟AndroidHttpClient都是HttpClient具體的實現類，它們都擁有眾多的API，而且實現比較穩定，bug數量也很少。
但同時也由於HttpClient的API數量過多，使得我們很難在不破壞兼容性的情況下對它進行升級和擴展，所以目前Android團隊在提升和優化HttpClient方面的工作態度並不積極。
HttpURLConnection
HttpURLConnection是一種多用途、輕量極的HTTP客戶端，使用它來進行HTTP操作可以適用於大多數的應用程序。雖然HttpURLConnection的API提供的比較簡單，但是同時這也使得我們可以更加容易地去使用和擴展它。
不過在Android 2.2版本之前，HttpURLConnection一直存在著一些令人厭煩的bug。比如說對一個可讀的InputStream調用close()方法時，就有可能會導致連接池失效了。那麼我們通常的解決辦法就是直接禁用掉連接池的功能：
private void () {
// 這是一個2.2版本之前的bug
if (Integer.parseInt(Build.VERSION.SDK) < Build.VERSION_CODES.FROYO) {
System.setProperty("http.keepAlive", "false");
}
}

在Android 2.3版本的時候，我們加入了更加透明化的響應壓縮。HttpURLConnection會自動在每個發出的請求中加入如下消息頭，並處理相應的返回結果：
Accept-Encoding: gzip
配置你的Web伺服器來支持對客戶端的響應進行壓縮的功能，從而可以在這一改進上獲取到最大的好處。如果在壓縮響應的時候出現了問題，這篇文檔會告訴你如何禁用掉這個功能。
但是如果啟動了響應壓縮的功能，HTTP響應頭里的Content-Length就會代表著壓縮後的長度，這時再使用getContentLength()方法來取出解壓後的數據就是錯誤的了。正確的做法應該是一直調用InputStream.read()方法來讀取響應數據，一直到出現-1為止。
我們在Android 2.3版本中還增加了一些HTTPS方面的改進，現在HttpsURLConnection會使用SNI(Server Name Indication)的方式進行連接，使得多個HTTPS主機可以共享同一個IP地址。除此之外，還增加了一些壓縮和會話的機制。如果連接失敗，它會自動去嘗試重新進行連接。這使得HttpsURLConnection可以在不破壞老版本兼容性的前提下，更加高效地連接最新的伺服器。
在Android 4.0版本中，我們又添加了一些響應的緩存機制。當緩存被安裝後(調用HttpResponseCache的install()方法)，所有的HTTP請求都會滿足以下三種情況：
所有的緩存響應都由本地存儲來提供。因為沒有必要去發起任務的網路連接請求，所有的響應都可以立刻獲取到。
視情況而定的緩存響應必須要有伺服器來進行更新檢查。比如說客戶端發起了一條類似於 「如果/foo.png這張圖片發生了改變，就將它發送給我」 這樣的請求，伺服器需要將更新後的數據進行返回，或者返回一個304 Not Modified狀態。如果請求的內容沒有發生，客戶端就不會下載任何數據。
沒有緩存的響應都是由伺服器直接提供的。這部分響應會在稍後存儲到響應緩存中。
由於這個功能是在4.0之後的版本才有的，通常我們就可以使用反射的方式來啟動響應緩存功能。下面的示例代碼展示了如何在Android 4.0及以後的版本中去啟用響應緩存的功能，同時還不會影響到之前的版本：
private void enableHttpResponseCache() {
try {
long httpCacheSize = 10 * 1024 * 1024; // 10 MiB
File httpCacheDir = new File(getCacheDir(), "http");
Class.forName("android.net.http.HttpResponseCache")
.getMethod("install", File.class, long.class)
.invoke(null, httpCacheDir, httpCacheSize);
} catch (Exception httpResponseCacheNotAvailable) {
}
}

你也應該同時配置一下你的Web伺服器，在HTTP響應上加入緩存的消息頭。
哪一種才是最好的？
在Android 2.2版本之前，HttpClient擁有較少的bug，因此使用它是最好的選擇。
而在Android 2.3版本及以後，HttpURLConnection則是最佳的選擇。它的API簡單，體積較小，因而非常適用於Android項目。壓縮和緩存機制可以有效地減少網路訪問的流量，在提升速度和省電方面也起到了較大的作用。對於新的應用程序應該更加偏向於使用HttpURLConnection，因為在以後的工作當中我們也會將更多的時間放在優化HttpURLConnection上面。

❼ android的自帶的httpClient 怎麼上傳文件

在Android開發中，Android SDK附帶了Apache的HttpClient，它是一個完善的客戶端。它提供了對HTTP協議的全面支持，可以使用HttpClient的對象來執行HTTP GET和HTTP POST調用。

HTTP工作原理：

1.客戶端(一般是指瀏覽器，這里是指自己寫的程序)與伺服器建立連接

2.建立連接後，客戶端向伺服器發送請求

3.伺服器接收到請求後，向客戶端發送響應信息

4.客戶端與伺服器斷開連接

HttpClient的一般使用步驟：

1.使用DefaultHttpClient類實例化HttpClient對象

2.創建HttpGet或HttpPost對象，將要請求的URL通過構造方法傳入HttpGet或HttpPost對象。

3.調用execute方法發送HTTP GET或HTTP POST請求，並返回HttpResponse對象。

4.通過HttpResponse介面的getEntity方法返回響應信息，並進行相應的處理。

最後記得要在AndroidManifest.xml文件添加網路許可權

<uses-permission android:name="android.permission.INTERNET" />

附件中包含了一個拍照上傳的源代碼