<code id="nbzwf"></code>
  1. <var id="nbzwf"></var>
    1. <meter id="nbzwf"></meter>
        <option id="nbzwf"><menuitem id="nbzwf"></menuitem></option><listing id="nbzwf"><delect id="nbzwf"><p id="nbzwf"></p></delect></listing>
        • 2019 Android網絡編程總結

          發布:51Code 時間: 2019-03-11 09:38

        • 1.網絡分層 OSI七層模型 OSI七層協議模型主要是:應用層(Application)、表示層(Presentation)、會話層(Session)、傳輸層(Transport)、網絡層(Network)、數據鏈路層(Data Link)、物理層...

        • 1.網絡分層

          OSI七層模型

          OSI七層協議模型主要是:應用層(Application)、表示層(Presentation)、會話層(Session)、傳輸層(Transport)、網絡層(Network)、數據鏈路層(Data Link)、物理層(Physical)。

          TCP/IP五層模型

          TCP/IP五層模型:應用層(Application)、傳輸層(Transport)、網絡層(Network)、數據鏈路層(Data Link)、物理層(Physical)。

          2.三次握手與四次揮手

          第一次握手:客戶端發送syn包(syn=j)到服務器,并進入SYN_SEND狀態,等待服務器確認;

          第二次握手:服務器收到syn包,必須確認客戶的SYN(ack=j+1),同時自己也發送一個SYN包(syn=k),即SYN+ACK包,此時服務器進入SYN_RECV狀態;

          第三次握手:客戶端收到服務器的SYN+ACK包,向服務器發送確認包ACK(ack=k+1),此包發送完畢,客戶端和服務器進入ESTABLISHED狀態,完成三次握手。

          握手過程中傳送的包里不包含數據,三次握手完畢后,客戶端與服務器才正式開始傳送數據。理想狀態下,TCP連接一旦建立,在通信雙方中的任何一方主動關閉連接之前,TCP 連接都將被一直保持下去。斷開連接時服務器和客戶端均可以主動發起斷開TCP連接的請求,斷開過程需要經過“四次握手”

          第一次揮手:客戶端發送報文告訴服務器沒有數據要發送了

          第二次揮手:服務端收到,再發送給客戶端告訴它我收到了

          第三次揮手:服務端向客戶端發送報文,請求關閉連接

          第四次揮手:客戶端收到關閉連接的請求,向服務端發送報文,服務端關閉連接

          TCP 為什么三次握手而不是兩次握手,為什么兩次握手不安全

          為了實現可靠數據傳輸, TCP 協議的通信雙方, 都必須維護一個序列號, 以標識發送出去的數據包中, 哪些是已經被對方收到的。 三次握手的過程即是通信雙方相互告知序列號起始值, 并確認對方已經收到了序列號起始值的必經步驟

          如果只是兩次握手, 至多只有連接發起方的起始序列號能被確認, 另一方選擇的序列號則得不到確認

          3.為什么TCP是可靠的,UDP早不可靠的?為什么UDP比TCP快?

          TCP/IP協議擁有三次握手雙向機制,這一機制保證校驗了數據,保證了他的可靠性。

          UDP就沒有了,udp信息發出后,不驗證是否到達對方,所以不可靠。

          4.http協議

          http協議是一個基于請求與響應模式的無連接,無狀態,應用層的協議,支持c/s模式,簡單快速,靈活

          簡單快速:協議簡單,通信速度快

          靈活:允許傳輸任意類型的數據對象,由Content-Type標記

          無連接:每次處理一個請求,處理完成后既斷開

          無狀態:對事務處理沒有記憶能力

          http有兩種報文:請求報文和響應報文

          請求報文由請求行,請求報頭,和請求數據組成

          請求行:抓包第一行,包括請求方法,url和http版本

          請求報頭:指的就是題目中“里面的協議頭部”

          請求數據:指post方式提交的表單數據

          響應報文由狀態行,響應報頭,響應正文組成

          狀態行:狀態碼

          響應報頭:同請求報頭

          響應正文:服務器返回的資源數據

          接下來是http頭部,既請求報頭和響應報頭,統稱消息報頭,消息報頭可以分為通用報頭,請求報頭,響應報頭,實體報頭等

          通用報頭和實體報頭既可以出現在請求報頭中,也可以出現在響應報頭中,通用報頭包含的字段如:Date Connection Cache-Control,實體報頭中有Content-Type Content-Length Content-Language Content-Encoding.

          請求報頭中包含的字段有:

          Host,User-Agent,Accept-Encoding,Accept-Language,Connection

          響應報頭包含的字段:

          Location,Server

          http的get和post的區別

          http是應用層的協議,底層基于TCP/IP協議,所以本質上,get和post請求都是TCP請求。所以二者的區別都是體現在應用層上(HTTP的規定和瀏覽器/服務器的限制)

          1.參數的傳輸方式:GET參數通過URL傳遞,POST放在Request body中。

          2.GET請求在URL中傳送的參數是有長度限制的,而POST沒有。

          3.對于GET方式的請求,瀏覽器會把http header和data一并發送出去,服務器響應200(返回數據);而對于POST,瀏覽器先發送header,服務器響應100 continue,瀏覽器再發送data,服務器響應200 ok(返回數據)。不過要注意,并不是所有瀏覽器都會在POST中發送兩次包,比如火狐

          4.對參數的數據類型,GET只接受ASCII字符,而POST沒有限制。

          5.GET比POST更不安全,因為參數直接暴露在URL上,所以不能用來傳遞敏感信息。

          1.GET請求只能進行url編碼,而POST支持多種編碼方式。

          7.GET在瀏覽器回退時是無害的,而POST會再次提交請求。

          8.GET產生的URL地址可以被Bookmark,而POST不可以。

          9.GET請求會被瀏覽器主動cache,而POST不會,除非手動設置。

          socket和http的區別:

          Http協議:簡單的對象訪問協議,對應于應用層。Http協議是基于TCP鏈接的。

          tcp協議:對應于傳輸層

          ip協議:對應與網絡層

          TCP/IP是傳輸層協議,主要解決數據如何在網絡中傳輸;而Http是應用層協議,主要解決如何包裝數據。

          Socket是對TCP/IP協議的封裝,Socket本身并不是協議,而是一個調用接口(API),通過Socket,我們才能使用TCP/IP協議。

          Http連接:http連接就是所謂的短連接,及客戶端向服務器發送一次請求,服務器端相應后連接即會斷掉。

          socket連接:socket連接及時所謂的長連接,理論上客戶端和服務端一旦建立連接,則不會主動斷掉;但是由于各種環境因素可能會是連接斷開,比如說:服務器端或客戶端主機down了,網絡故障,或者兩者之間長時間沒有數據傳輸,網絡防火墻可能會斷開該鏈接已釋放網絡資源。所以當一個socket連接中沒有數據的傳輸,那么為了位置連續的連接需要發送心跳消息,具體心跳消息格式是開發者自己定義的

          TCP與UDP區別總結:

          1、TCP面向連接(如打電話要先撥號建立連接);UDP是無連接的,即發送數據之前不需要建立連接

          2、TCP提供可靠的服務。也就是說,通過TCP連接傳送的數據,無差錯,不丟失,不重復,且按序到達;UDP盡最大努力交付,即不保   證可靠交付

          3、TCP面向字節流,實際上是TCP把數據看成一連串無結構的字節流;UDP是面向報文的

          UDP沒有擁塞控制,因此網絡出現擁塞不會使源主機的發送速率降低(對實時應用很有用,如IP電話,實時視頻會議等)

          4、每一條TCP連接只能是點到點的;UDP支持一對一,一對多,多對一和多對多的交互通信

          5、TCP首部開銷20字節;UDP的首部開銷小,只有8個字節

          6、TCP的邏輯通信信道是全雙工的可靠信道,UDP則是不可靠信道

          5.https

          HTTPS(全稱:Hyper Text Transfer Protocol over Secure Socket Layer),是以安全為目標的HTTP通道,簡單講是HTTP的安全版。HTTP是應用層協議,位于HTTP協議之下是傳輸協議TCP。TCP負責傳輸,HTTP則定義了數據如何進行包裝,在HTTP跟TCP中間加多了一層加密層TLS/SSL,SSL是個加密套件,負責對HTTP的數據進行加密。TLS是SSL的升級版。現在提到HTTPS,加密套件基本指的是TLS。

          傳輸加密的流程:http是應用層將數據直接給到TCP進行傳輸,https是應用層將數據給到TLS/SSL,將數據加密后,再給到TCP進行傳輸。

          HTTPS是如何加密數據的:

          一般來說,加密分為對稱加密、非對稱加密

          對稱加密:對稱加密的意思就是,加密數據用的密鑰,跟解密數據用的密鑰是一樣的。

          對稱加密的優點在于加密、解密效率通常比較高。缺點在于,數據發送方、數據接收方需要協商、共享同一把密鑰,并確保密鑰不泄露給其他人。傳輸過程中容易被截獲。

          網上一個很形象的例子:假如現在小客與小服要進行一次私密的對話,他們不希望這次對話內容被其他外人知道。可是,我們平時的數據傳輸過程中又是明文傳輸的,萬一被某個黑客把他們的對話內容給竊取了,那就難受了。為了解決這個問題,小服這家伙想到了一個方法來加密數據,讓黑客看不到具體的內容。該方法是這樣子的:在每次數據傳輸之前,小服會先傳輸小客一把密鑰,然后小服在之后給小客發消息的過程中,會用這把密鑰對這些消息進行加密。小客在收到這些消息后,會用之前小服給的那把密鑰對這些消息進行解密,這樣,小客就能得到密文里面真正的數據了。如果小客要給小服發消息,也同樣用這把密鑰來對消息進行加密,小服收到后也用這把密鑰進行解密。 這樣,就保證了數據傳輸的安全性。

          非對稱加密

          非對稱加密的意思就是,加密數據用的密鑰(公鑰),跟解密數據用的密鑰(私鑰)是不一樣的。

          網上一個很形象的例子:小服還是挺聰明的,得意了一會之后,小服意識到了密鑰會被截取這個問題。倔強的小服又想到了另外一種方法:用非對稱加密的方法來加密數據。該方法是這樣的:小服和小客都擁有兩把鑰匙,一把鑰匙的公開的(全世界都知道也沒關系),稱之為公鑰;而另一把鑰匙是保密(也就是只有自己才知道),稱之為私鑰。并且,用公鑰加密的數據,只有對應的私鑰才能解密;用私鑰加密的數據,只有對應的公鑰才能解密。所以在傳輸數據的過程中,小服在給小客傳輸數據的過程中,會用小客給他的公鑰進行加密,然后小客收到后,再用自己的私鑰進行解密。小客給小服發消息的時候,也一樣會用小服給他的公鑰進行加密,然后小服再用自己的私鑰進行解密。 這樣,數據就能安全著到達雙方。是什么原因導致非對稱加密這種方法的不安全性呢?它和對稱加密方法的不安全性不同。非對稱加密之所以不安全,是因為小客收到了公鑰之后,無法確定這把公鑰是否真的是小服。

          解決的辦法就是數字證書:小服再給小客發公鑰的過程中,會把公鑰以及小服的個人信息通過Hash算法生成消息摘要,為了防止摘要被人調換,小服還會用CA提供的私鑰對消息摘要進行加密來形成數字簽名,當小客拿到這份數字證書之后,就會用CA提供的公鑰來對數字證書里面的數字簽名進行解密得到消息摘要,然后對數字證書里面小服的公鑰和個人信息進行Hash得到另一份消息摘要,然后把兩份消息摘要進行對比,如果一樣,則證明這些東西確實是小服的,否則就不是。

          加密算法

          1.對稱加密算法

          Data Encryption Standard(DES)

          DES 是一種典型的塊加密方法:將固定長度的明文通過一系列復雜的操作變成同樣長度的密文,塊的長度為64位。同時,DES 使用的密鑰來自定義變換過程,因此算法認為只有持有加密所用的密鑰的用戶才能解密密文。 DES 的密鑰表面上是64位的,實際有效密鑰長度為56位,其余8位可以用于奇偶校驗。

          DES 現在已經不被視為一種安全的加密算法,主要原因是它使用的56位密鑰過短。

          為了提供實用所需的安全性,可以使用 DES 的派生算法 3DES 來進行加密 (雖然3DES 也存在理論上的攻擊方法)。

          Advanced Encryption Standard(AES)

          AES 在密碼學中又稱 Rijndael 加密法,用來替代原先的 DES,已經被多方分析且廣泛使用。

          DES與AES的比較

          自DES 算法公諸于世以來,學術界圍繞它的安全性等方面進行了研究并展開了激烈的爭論。在技術上,對DES的批評主要集中在以下幾個方面:

          1、作為分組密碼,DES 的加密單位僅有64 位二進制,這對于數據傳輸來說太小,因為每個分組僅含8 個字符,而且其中某些位還要用于奇偶校驗或其他通訊開銷。

          2、DES 的密鑰的位數太短,只有56 比特,而且各次迭代中使用的密鑰是遞推產生的,這種相關必然降低密碼體制的安全性,在現有技術下用窮舉法尋找密鑰已趨于可行。

          3、DES 不能對抗差分和線性密碼分析。

          4、DES 用戶實際使用的密鑰長度為56bit,理論上最大加密強度為256。DES 算法要提高加密強度(例如增加密鑰長度),則系統開銷呈指數增長。除采用提高硬件功能和增加并行處理功能外,從算法本身和軟件技術方面都無法提高DES 算法的加密強度。

          2.非對稱加密算法

          RSA

          1977年由 MIT 的 Ron Rivest、Adi Shamir 和 Leonard Adleman 一起提出,以他們三人姓氏開頭字母命名,是一種獲得廣泛使用的非對稱加密算法。

          對極大整數做因數分解的難度 (The Factoring Problem) 決定了 RSA 算法的可靠性。換言之,對一個極大整數做因數分解愈困難,RSA 算法就愈可靠。假如有人找到一種快速因數分解的算法的話,那么用 RSA 加密的信息的可靠性就肯定會極度下降。目前看來找到這樣的算法的可能性非常小。

          DES與RSA的比較

          RSA算法的密鑰很長,具有較好的安全性,但加密的計算量很大,加密速度較慢限制了其應用范圍。為減少計算量,在傳送信息時,常采用傳統加密方法與公開密鑰加密方法相結合的方式,即信息采用改進的DES對話密鑰加密,然后使用RSA密鑰加密對話密鑰和信息摘要。對方收到信息后,用不同的密鑰解密并可核對信息摘要。

          采用DES與RSA相結合的應用,使它們的優缺點正好互補,即DES加密速度快,適合加密較長的報文,可用其加密明文;RSA加密速度慢,安全性好,應用于DES 密鑰的加密,可解決DES 密鑰分配的問題。

          目前這種RSA和DES結合的方法已成為EMAIL保密通信標準。

          Volley

          Volley的特點

          Volley是谷歌大會上推出的網絡通信框架(2.3之前使用HttpClient,之后使用HttpUrlConnection),它既可以訪問網絡獲取數據,也可以加載圖片,并且在性能方面進行了大幅度的調整,它的設計目的就是適合進行數據量不大但通信頻繁的網絡操作,而對于大數據量的操作,比如文件下載,表現很糟糕,因為volley處理http返回的默認實現是BasicNetwork,它會把返回的流全部導入內存中,下載大文件會發生內存溢出

          Volley執行的過程:

          默認情況下,Volley中開啟四個網絡調度線程和一個緩存調度線程,首先請求會加入緩存隊列,,緩存調度線程從緩存隊列中取出線程,如果找到該請求的緩存就直接讀取該緩存并解析,然后回調給主線程,如果沒有找到緩存的響應,則將這個請求加入網絡隊列,然后網絡調度線程會輪詢取出網絡隊列中的請求,發起http請求,解析響應并將響應存入緩存,回調給主線程

          Volley為什么不適合下載上傳大文件?為什么適合數據量小的頻率高的請求?

          1.volley基于請求隊列,Volley的網絡請求線程池默認大小為4。意味著可以并發進行4個請求,大于4個,會排在隊列中。并發量小所以適合數據量下頻率高的請求

          2.因為Volley下載文件會將流存入內存中(是一個小于4k的緩存池),大文件會導致內存溢出,所以不能下載大文件,不能上傳大文件的原因和1中差不多,設想你上傳了四個大文件,同時占用了volley的四個線程,導致其他網絡請求都阻塞在隊列中,造成反應慢的現象

          OKHttp

          OKHttp的特點

          1.相較于Volley,它的最大并發量為64

          2.使用連接池技術,支持5個并發的socket連接默認keepAlive時間為5分鐘,解決TCP握手和揮手的效率問題,減少握手次數

          3.支持Gzip壓縮,且操作對用戶透明,可以通過header設置,在發起請求的時候自動加入header,Accept-Encoding: gzip,而我們的服務器返回的時候header中有Content-Encoding: gzip

          4.利用響應緩存來避免重復的網絡請求

          5.很方便的添加攔截器,通常情況下,攔截器用來添加,移除,轉換請求和響應的頭部信息,比如添加公參等

          6.請求失敗,自動重連,發生異常時重連,看源碼調用recover方法重連了一次

          7.支持SPDY協議(SPDY是Google開發的基于TCP的應用層協議,用以最小化網絡延遲,提升網絡速度,優化用戶的網絡使用體驗。SPDY并不是一種用于替代HTTP的協議,而是對HTTP協議的增強。新協議的功能包括數據流的多路復用、請求優先級以及HTTP報頭壓縮。谷歌表示,引入SPDY協議后,在實驗室測試中頁面加載速度比原先快64%)

          8.使用Okio來簡化數據的訪問與存儲,提高性能

          OkHttp的缺點

          1.消息回來需要切到主線程,主線程要自己去寫。

          2.調用比較復雜,需要自己進行封裝。

          3.緩存失效:網絡請求時一般都會獲取手機的一些硬件或網絡信息,比如使用的網絡環境。同時為了信息傳輸的安全性,可能還會對請求進行加密。在這些情況下OkHttp的緩存系統就會失效了,導致用戶在無網絡情況下不能訪問緩存。

          OkHttp框架中都用到了哪些設計模式

          1.最明顯的Builder設計模式,如構建對象OkHttpClient,還有單利模式

          2.工廠方法模式,如源碼中的接口Call

          3.觀察者模式如EventListener,監聽請求和響應

          4.策略模式

          5.責任鏈模式,如攔截器

          Retrofit

          Retrofit底層是基于OkHttp實現的,與其他網絡框架不同的是,它更多使用運行時注解的方式提供功能

          原理

          通過java接口以及注解來描述網絡請求,并用動態代理的方式生成網絡請求的request,然后通過client調用相應的網絡框架(默認okhttp)去發起網絡請求,并將返回的response通過converterFactorty轉換成相應的數據model,最后通過calladapter轉換成其他數據方式(如rxjava Observable)

          Retrofit流程

          (1)通過解析 網絡請求接口的注解 配置 網絡請求參數

          (2)通過 動態代理 生成 網絡請求對象

          (3)通過 網絡請求適配器 將 網絡請求對象 進行平臺適配

          (4)通過 網絡請求執行器 發送網絡請求

          (5)通過 數據轉換器 解析服務器返回的數據

          (6)通過 回調執行器 切換線程(子線程 ->>主線程)

          (7)用戶在主線程處理返回結果

          Retrofit優點

          1.可以配置不同HTTP client來實現網絡請求,如okhttp、httpclient等;

          2.請求的方法參數注解都可以定制;

          3.支持同步、異步和RxJava;

          4.超級解耦;

          5.可以配置不同的反序列化工具來解析數據,如json、xml等

          6.框架使用了很多設計模式

          文章來源:https://www.jianshu.com/p/a0b37a0ea1c6 版權歸原作者所有
          如涉及知識產權問題,請權利人聯系博為峰小編(021-64471599-8103),我們將立即處理。
        • 上一篇:一名Android程序員的BAT面經和感想

          下一篇:App相互喚醒的幾種方式

        網站導航
        Copyright(C)51Code軟件開發網 2003-2019 , 滬ICP備05003035號-6
        北京快三路线温都水城

          <code id="nbzwf"></code>
        1. <var id="nbzwf"></var>
          1. <meter id="nbzwf"></meter>
              <option id="nbzwf"><menuitem id="nbzwf"></menuitem></option><listing id="nbzwf"><delect id="nbzwf"><p id="nbzwf"></p></delect></listing>

                <code id="nbzwf"></code>
              1. <var id="nbzwf"></var>
                1. <meter id="nbzwf"></meter>
                    <option id="nbzwf"><menuitem id="nbzwf"></menuitem></option><listing id="nbzwf"><delect id="nbzwf"><p id="nbzwf"></p></delect></listing>
                    吉林快三精准计划图网站 2019年生肖合数单双表 王者荣耀公孙离图片黄 台湾美女uni 播放 黑龙江时时彩 博财汇娱乐app 百人炸金花怎么玩 天龙国际app靠谱吗 重时时彩现场开奖号码 上海时时杀码