Android Http協議

一次HTTP操作稱為一個事務,其工作過程可分為四步:

  1. 首先客戶端與服務器需要建立連接。只要單機某個超級鏈接,HTTP的工作就開始了。
  2. 建立連接后,客戶端發送一個請求給服務器,請求方式的格式為:統一資源標識符(URL)、協議版本號,后邊是MIME信號包括請求修飾符、客戶端信息和其他內容。
  3. 服務器接到請求后,給予相應的響應信息,其格式為一個狀態行,包括信息的協議版本號、一個成功或者失敗的代碼,后邊是MIME信息包括服務器信息、實體信息和可能的內容。
  4. 客戶端接收到服務器所返回的信息通過瀏覽器顯示在用戶的顯示屏幕上,然后客戶端和服務器斷開連接。

HTTP協議永遠都是客戶端發起請求,服務器回送相應。
這樣就限制了使用HTTP協議,無法實現在客戶端沒有發起請求的時候,服務器將消息推送給客戶端。
HTTP協議是一個無狀態的協議,同一個客戶端的這次請求和上次請求是沒有關系的。


URL(統一資源定位符)也被稱為網頁地址,是因特網上標準的資源的地址。
例如:http://www.imooc.com/index.jsp,URL的格式由三部分組成:

  1. 第一部分是協議(或稱為服務方式)。例如“http”或者“https”;
  2. 第二部分是存有該資源的主機IP地址(有時候也包括端口號)。例如“www.imooc.com”;
  3. 第三部分是主機資源和具體地址,例如目錄和文件名。例如“index.jsp”;
    第一部分和第二部分用“://”隔開,第二部分和第三部分用“/”隔開。第一部分和第二部分不可缺少。

HTTP協議建立在TCP/IP協議之上。

TCP/IP三次握手:
客戶端要和服務端建立連接時,客戶端向服務端發送SYN消息,服務器收到消息后向客戶端發送SYN+ACK消息,最后客戶端再以ACK消息響應,如此一來才會在客戶端和服務端之間建立起可靠的TCP連接,數據才可以在客戶端和服務器之間傳遞。
SYN:synchronous,握手信號。
ACK:Acknowledgment,確認字符。接收站發送給發送站的一種傳輸類控制字符,表示發來是數據已接收、確認無誤。


OSI (Open System Interconnection)七層協議
由低到高分別是:
物理層
數據鏈路層
網絡層
傳輸層
會話層
表示層
應用層

如下摘自網絡:

  1. 物理層的作用是實現相鄰計算機節點之間比特流的透明傳送,盡可能屏蔽掉具體傳輸介質和物理設備的差異。
  2. 數據鏈路層(Data Link Layer)是OSI模型的第二層,負責建立和管理節點間的鏈路。
  3. 網絡層(Network Layer)是OSI模型的第三層,它是OSI參考模型中最復雜的一層。它在下兩層的基礎上向資源子網提供服務。其主要任務是:通過路由選擇算法,為報文或分組通過通信子網選擇最適當的路徑。
  4. 傳輸層(Transport Layer)是OSI模型的第4層。因此該層是通信子網和資源子網的接口和橋梁,起到承上啟下的作用。該層的主要任務是:向用戶提供可靠的端到端的差錯和流量控制,保證報文的正確傳輸。
  5. 會話層(Session Layer)是OSI模型的第5層,是用戶應用程序和網絡之間的接口,主要任務是:向兩個實體的表示層提供建立和使用連接的方法。
  6. 表示層(Presentation Layer)是OSI模型的第六層,它對來自應用層的命令和數據進行解釋,對各種語法賦予相應的含義,并按照一定的格式傳送給會話層。其主要功能是“處理用戶信息的表示問題,如編碼、數據格式轉換和加密解密”等。
  7. 應用層(Application Layer)是OSI參考模型的最高層,它是計算機用戶,以及各種應用程序和網絡之間的接口,其功能是直接向用戶提供服務,完成用戶希望在網絡上完成的各種工作。
    后來有人將此簡化為 TCP/IP 四層協議

http/1.0和1.1區別
HTTP/1.0每次請求都需要建立新的TCP連接,連接不能復用。
HTTP/1.1新的請求可以在上次請求建立的TCP連接之上發送,連接可以復用。優點是減少重復進行TCP三次握手的開銷,提高效率。
HTTP1.1在Request消息頭里頭多了一個Host域,HTTP1.0則沒有這個域。Host:www.w3.org
HTTP1.1增加了OPTIONS,PUT,DELETE,TRACE,CONNECT這些Request方法等


HttpClient比HttpURLConnection更加的強大和豐富。所以建議使用這個來開發Android的http客戶端。
但從android sdk(6.0)開始,Google在官方文檔里已經不推薦用HttpClient。
話說Google廢棄了HttpClient,卻沒有新的網絡框架作為替代……而實際開發中又并不會用HttpURLConnection,所以一般都是用開源網絡請求框架,比如 loopjVolley

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 230,002評論 6 542
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 99,400評論 3 429
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 178,136評論 0 383
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,714評論 1 317
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 72,452評論 6 412
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,818評論 1 328
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,812評論 3 446
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,997評論 0 290
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 49,552評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 41,292評論 3 358
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,510評論 1 374
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 39,035評論 5 363
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,721評論 3 348
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 35,121評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,429評論 1 294
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 52,235評論 3 398
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,480評論 2 379

推薦閱讀更多精彩內容