HTTP

一. 網(wǎng)絡(luò)知識(shí)基礎(chǔ)

1. 網(wǎng)絡(luò)編程中的幾個(gè)基本概念

   • 客戶端Client: 移動(dòng)應(yīng)用App, 如iOS和安卓的應(yīng)用
   • 服務(wù)器Server: 為客戶端提供服務(wù), 提供數(shù)據(jù), 提供資源的機(jī)器
   • 請求Request: 客戶端向服務(wù)器端索取數(shù)據(jù)的一種行為
   • 響應(yīng)Response: 服務(wù)器對客戶端的請求作出的反應(yīng), 一般指返回?cái)?shù)據(jù)給客戶端

2. 移動(dòng)應(yīng)用的開發(fā), 主要是對客戶端進(jìn)行的開發(fā), 一般的網(wǎng)絡(luò)交互如下圖所示

3. 兩種服務(wù)器的基本概念:

   • 遠(yuǎn)程服務(wù)器
     • 又稱外網(wǎng)服務(wù)器, 正式服務(wù)器
     • 使用階段: 應(yīng)用上線后使用的服務(wù)器, 面向用戶, 供全體用戶使用
     • 速度: 取決于服務(wù)器的性能, 用戶的網(wǎng)速
   • 本地服務(wù)器
     • 又稱內(nèi)網(wǎng)服務(wù)器, 測試服務(wù)器
     • 使用階段: 應(yīng)用處于開發(fā)/測試階段時(shí)使用的服務(wù)器, 面向公司內(nèi)部開發(fā)人員和測試人員
     • 速度: 由于是局域網(wǎng), 所以會(huì)保證網(wǎng)速, 有助于提高開發(fā)測試的效率, 但是無法反應(yīng)出真實(shí)的情況

4. 網(wǎng)絡(luò)交互參考示意圖:

   
   
   網(wǎng)絡(luò)交互.png

二. HTTP

1. URL

   • URL全程: Uniform Resource Locator(統(tǒng)一資源定位符)
   • URL就是資源的地址/位置, 互聯(lián)網(wǎng)上的每一個(gè)資源都有一個(gè)唯一的URL, 通過一個(gè)URL, 能找到互聯(lián)網(wǎng)中唯一的一個(gè)資源
   • URL的基本格式: 協(xié)議://主機(jī)地址/路徑
     • 如: http://www.baidu.com
     • 如: http://202.104.33.4/img/logo.jpg
   • 協(xié)議: 不同的協(xié)議代表著不同的資源查找方式, 資源傳輸方式
     • HTTP: 超文本傳輸協(xié)議, 訪問的是遠(yuǎn)程網(wǎng)絡(luò)資源(網(wǎng)絡(luò)開發(fā)中最長用的協(xié)議)
     • file: 訪問的是本地計(jì)算機(jī)上面的資源(file://不用加主機(jī)地址, 直接寫路徑)
     • mailto: 訪問的是電子郵件地址
     • ftp: 訪問的是共享主機(jī)的文件資源
   • 主機(jī)地址: 存放著資源的主機(jī)(服務(wù)器)的IP地址(域名)
   • 路徑: 資源在主機(jī)(服務(wù)器)中的具體位置

2. TCP/IP協(xié)議簇

   • 通常意義上, 我們使用的網(wǎng)絡(luò)是在TCP/IP協(xié)議簇的基礎(chǔ)上運(yùn)作的, 而HTTP屬于它內(nèi)部的一個(gè)子集
   • 計(jì)算機(jī)與網(wǎng)絡(luò)設(shè)備需要通信的話, 雙方就要基于相同的方法, 比如具體應(yīng)該如何探測通信目標(biāo), 由哪一方發(fā)起通信, 使用什么語言去通信等, 所有的這些議定的規(guī)則, 稱之為協(xié)議
   • 在協(xié)議中規(guī)定了很多的各式各樣的內(nèi)容, 如選址方法, 雙方建立通信的順序等等, 這些協(xié)議如(ICMP/DNS/TCP/FTP/HTTP/SNMP/PPPoE/IP/FDDI等等), 通常我們把TCP/IP認(rèn)為是在IP協(xié)議的通信過程中, 使用到的協(xié)議簇的總稱
   • TCP協(xié)議簇里面最重要一點(diǎn), 就是分層設(shè)計(jì)
     • 按照層次分別分為: 應(yīng)用層, 傳輸層, 網(wǎng)絡(luò)層, 數(shù)據(jù)鏈路層
     • 其中, 與HTTP關(guān)系密切的協(xié)議有TCP, IP, DNS等

   • 參考模型:

     
     
     ![Uploading HTTP協(xié)議_465404.png . . .]

3. HTTP協(xié)議簡介

   • 移動(dòng)端和PC端, 大多數(shù)遠(yuǎn)程的網(wǎng)絡(luò)資源, 都使用的是HTTP協(xié)議
     • 如: http://www.baidu.com
   • HTTP協(xié)議的作用:
     • 協(xié)議, 主要是為了客戶端和服務(wù)器達(dá)成的協(xié)議共識(shí), 雙方遵守一份協(xié)議, 使用相同的語言才能互相進(jìn)行交互
     • HTTP的全稱: Hypertext Transfer Protocol, 即超文本傳輸協(xié)議
     • 它規(guī)定了客戶端和服務(wù)器之間的數(shù)據(jù)傳輸格式, 讓雙方進(jìn)行有效的數(shù)據(jù)溝通

     • 如下圖所示:

       
       
       HTTP協(xié)議.png
   • HTTP協(xié)議的特點(diǎn):
     • 簡單高效: 因?yàn)镠TTP協(xié)議簡單, 所以HTTP服務(wù)器的程序規(guī)模都很輕靈, 通信速度相對很快
     • 靈活: HTTP可以傳輸各種各樣的數(shù)據(jù)
     • HTTP0.9和1.0使用非持續(xù)鏈接
       • 限制每次連接只處理一個(gè)請求, 服務(wù)器對客戶端的請求作出響應(yīng)之后, 馬上斷開連接, 這種方式可以節(jié)省傳輸?shù)臅r(shí)間

4. HTTP的基本通信過程

   • 完整的HTTP通信可以分為2個(gè)步驟
     • 請求: 客戶端向服務(wù)器索取數(shù)據(jù)
     • 響應(yīng): 服務(wù)器返回客戶端需要的數(shù)據(jù)
   • 完整步驟
     1. 確定請求路徑URL
     2. 獲取主機(jī)名或者域名
     3. DNS域名解析
     4. 獲取端口號(hào)
     5. 連接到指定服務(wù)器的端口(如: 120.20.225.18的80端口)
     6. 客戶端向服務(wù)器發(fā)送一個(gè)GET請求
     7. 服務(wù)器返回客戶端請求的數(shù)據(jù)
     8. 關(guān)閉連接

5. 發(fā)送HTTP請求的方法

   • 在HTTP1.1版本的協(xié)議中, 定義了8中發(fā)送HTTP請求的方法
     • GET, POST, OPTIONS, HEAD, PUT, DELETE, TRACE, CONNECT, PATCH
     • 根據(jù)HTTP協(xié)議的設(shè)計(jì)初衷, 不同的方法對資源有著不同的操作方式:
       • PUT: 增
       • DELETE: 刪
       • POST: 改
       • GET: 查
     • 其中最常用的就是GET和POST, 實(shí)際上GET和POST都能辦到增刪改查
   • 參數(shù): 就是傳遞給服務(wù)器的具體數(shù)據(jù), 比如登錄時(shí)的賬號(hào)密碼

6. GET和POST的對比: GET和POST的區(qū)別主要體現(xiàn)在數(shù)據(jù)的傳遞上

   • GET:
     • 在請求URL后面以?的形式, 接上要發(fā)給服務(wù)器的參數(shù), 多個(gè)參數(shù)之間用&隔開
     • 如: http://www.test.com/login?username=xxx&pwd=abc&type=JSON
     • 由于瀏覽器和服務(wù)器對URL長度有限制, 因此在URL后面附帶的參數(shù)是有限制的, 通常不能超過1kb
   • POST:
     • 發(fā)給服務(wù)器的參數(shù), 全部都放在請求體中
     • 理論上, POST傳遞的數(shù)據(jù)量沒有限制(但是只是理論上, 具體還得看服務(wù)器的處理能力)

7. GET和POST的選擇

   • 如果要傳遞大量數(shù)據(jù), 比如文件傳送, 只能使用POST請求
   • GET的安全性比POST要差, 如果包含機(jī)密信息的話, 建議使用POST
   • 如果只是索取數(shù)據(jù), 建議使用GET, 比如數(shù)據(jù)查詢, 發(fā)送特定的參數(shù), 獲取特定的數(shù)據(jù)
   • 如果是對數(shù)據(jù)做出修改, 建議使用POST

8. HTTP報(bào)文

   • HTTP報(bào)文結(jié)構(gòu)示意圖:

     
     
     報(bào)文示意圖.png
   • 報(bào)文首部: 在客戶端和服務(wù)器處理時(shí), 起重要作用的信息(比如端口數(shù)據(jù), 端口)
     • 請求報(bào)文
       • 請求行: 請求方法 + URL + HTTP版本
       • 請求頭:
         • 請求首部字段
         • 通用首部字段
         • 實(shí)體首部字段
     • 響應(yīng)報(bào)文
       • 狀態(tài)行: HTTP版本 + 狀態(tài)碼
       • 響應(yīng)頭:
         • 響應(yīng)首部字段
         • 通用首部字段
         • 實(shí)體首部字段
   • 空行:
   • 報(bào)文主體(請求體/響應(yīng)體): 請求參數(shù)或響應(yīng)的數(shù)據(jù)

9. HTTP通信過程 - 請求

   • HTTP協(xié)議規(guī)定: 一個(gè)完整的由客戶端發(fā)送給服務(wù)器的HTTP請求中, 包含以下內(nèi)容
   • 請求頭: 包含了對客戶端的環(huán)境描述, 客戶端請求信息等
     • GET/background.png HTTP/1.1: 請求方法+請求資源路徑+HTTP協(xié)議版本
     • Host: 120.25.225.168:81: 客戶端想訪問的服務(wù)器主機(jī)地址
     • User-Agent: Mozilla/5.0: 客戶端的類型, 客戶端的軟件環(huán)境
     • Accept: text/html(xx/xx): 客戶端所能接收的數(shù)據(jù)類型
     • Accept-Language: zh-cn: 客戶端的語言環(huán)境
     • Accept-Encoding: gzip: 客戶端支持的數(shù)據(jù)壓縮格式
   • 請求體: 客戶端發(fā)給服務(wù)器的具體數(shù)據(jù), 比如文件數(shù)據(jù)(注: 只有POST請求才有)

10. HTTP通信過程 - 響應(yīng)

    • 客戶端向服務(wù)器發(fā)送請求, 服務(wù)器應(yīng)當(dāng)響應(yīng)客戶端的請求, 并且返回?cái)?shù)據(jù)給客戶端
    • HTTP協(xié)議規(guī)定: 一個(gè)完整的HTTP響應(yīng)應(yīng)該包含以下內(nèi)容
    • 響應(yīng)頭: 包含了對服務(wù)器的描述, 對返回?cái)?shù)據(jù)的描述
      • HTTP/1.1 200 OK: HTTP協(xié)議版本, 狀態(tài)碼, 狀態(tài)的英文說明
      • Server: Apache-Coyote/1.1: 服務(wù)器的類型
      • Content-Type: image/jpeg: 返回?cái)?shù)據(jù)的類型
      • Content-Length: 56811: 返回?cái)?shù)據(jù)的長度
      • Date: Mon, 23 Jun 2014 12:54:52 GMT: 響應(yīng)的時(shí)間
    • 響應(yīng)體: 服務(wù)器返回給客戶端的具體數(shù)據(jù), 比如請求一個(gè)文件, 返回的整體文件數(shù)據(jù)