學習資料：

• 《圖解Http》

正在學習了解OkHttp的知識，遇到了關于http的知識點時几迄，都不知所云胁后。百度到的東西衅枫，看得云里霧里的，感覺還是自己找本書看看阅悍，效果比較好判帮。正好同學有本圖解Http，講的挺基礎溉箕，能看懂晦墙，就拿來看看，系統(tǒng)性得了解了解基礎知識肴茄，寫寫博客晌畅，記錄一下書上的知識點

電子版，上傳到了CSDN寡痰，盜版資源抗楔，罪過罪過 ：）

博客就是摘抄書上的知識點

1. 了解Web及網(wǎng)絡基礎

Web browser通過指定的URl，從Web服務器端獲取文件資源等信息拦坠，然后顯示出Web頁面连躏。Web使用的便是HTTP(HyperText Transfer Protocol)超文本傳輸協(xié)議作為規(guī)范

1.1 網(wǎng)絡基礎 TCP／IP

通常使用的網(wǎng)絡，包括互聯(lián)網(wǎng)贞滨，是在TCP/IP協(xié)議族的基礎上運作入热，HTTP屬于它內部的一個子集

計算機與網(wǎng)絡設備要相互通信，雙方就必須基于相同的方法晓铆。例如勺良，如何探測到通信目標、由哪一邊先發(fā)起通信骄噪、使用哪種語言進行通信尚困、怎樣結束通信等規(guī)則都需要事先確定

不同的硬件、操作系統(tǒng)之間的通信链蕊，所有的一切都需要一種規(guī)則事甜，這種規(guī)則被稱為 協(xié)議protocol谬泌， 而TCP/IP是互聯(lián)網(wǎng)相關協(xié)議的各類協(xié)議族的總稱

TCP／IP 協(xié)議族

作用：

• IP協(xié)議：指定數(shù)據(jù)發(fā)送目的地的IP地址以及通過路由器轉發(fā)數(shù)據(jù)
• TCP協(xié)議：通過數(shù)據(jù)發(fā)送者和接收者相互回應對方發(fā)來的確認信號，可靠地傳輸數(shù)據(jù)

協(xié)議中存在各式各樣的內容逻谦。電纜的規(guī)格到IP地址的選定方法掌实，尋找異地用戶的方法、雙方建立通信的順序跨跨，以及Web頁面顯示需要的步驟潮峦，等等之類的

協(xié)議囱皿，個人理解勇婴，就是網(wǎng)絡間通信的江湖規(guī)矩，行走江湖嘱腥，出來混耕渴，就得遵守江湖規(guī)矩

1.1.1 TCP/IP 分層

TCP/IP分4層：應用層,傳輸層,網(wǎng)絡層,數(shù)據(jù)鏈路層

分層的好處：

1. 修改協(xié)議時，只需把需要變動的層替換就可以齿兔，改動比較自由橱脸。如整個協(xié)議不分層，只有一個整體分苇，即使有一個改變地方需要改變設計添诉，就得把所有不分整體替換
2. 層次化之后，設計也變得相對簡單医寿。處于應用層上的應用考慮分派給自己的任務栏赴，而不必清楚對方在哪個地方，對方的傳輸路線是怎樣的靖秩、是否能確保傳輸送達

• 應用層：決定向用戶提供應用服務時通信的活動
  
  TCP/IP協(xié)議族內預存了各類通用的應用服務须眷。例如，FTP(File Transfer Protocl)沟突，文件傳輸協(xié)議花颗；DNS(Domain Name System)域名系統(tǒng)。 HTTP協(xié)議也在應用層

• 傳輸層：為上一層的應用層惠拭，提供處于網(wǎng)絡連接中的兩臺計算機之間的數(shù)據(jù)傳輸
  
  在傳輸層扩劝，有兩個性質不同的協(xié)議：TCP(Transmission Control Protocol)傳輸控制協(xié)議協(xié)議，UDP(User Data Protocl)用戶數(shù)據(jù)報協(xié)議

• 網(wǎng)絡層：處理在網(wǎng)絡上流動的數(shù)據(jù)包
  
  數(shù)據(jù)包是網(wǎng)絡傳輸?shù)淖钚〉臄?shù)據(jù)單位
  
  該層規(guī)定了通過怎樣的路徑到達對方計算機职辅，并把數(shù)據(jù)包傳送給對方今野。與對方計算機之間的通過多臺計算機或網(wǎng)絡設備進行傳輸時，網(wǎng)絡層所起的作用的就是在眾多的選項內選擇一條傳輸路線

• 鏈路層：處理連接網(wǎng)絡的硬件部分
  
  包括控制操作系統(tǒng)罐农、硬件的設備驅動条霜、NIC(Network Interface Card)網(wǎng)卡，光纖等物理硬件部分涵亏。硬件上的范疇均在鏈路層的作用范圍之內

1.1.2 TCP/IP通信傳輸流

TCP/IP通信傳輸流

利用TCP/IP協(xié)議族進行網(wǎng)絡通信時宰睡，通過分層的順序與對方進行通信蒲凶，發(fā)送端從應用層往下走，接受端則向應用層拆内，向上層走

HTTP舉例說明：

HTTP 通信舉例

1. 作為發(fā)送端的客戶端在應用層旋圆，遵循HTTP協(xié)議，發(fā)出一個顯示某個Web頁面的HTTP請求
2. 為了傳輸方便麸恍，在傳輸層TCP協(xié)議下灵巧，把從應用層處，收到的數(shù)據(jù)抹沪，也就是HTTP請求報文刻肄，進行分割，并在各個報文打上標記序號以及端口號后融欧，轉發(fā)給網(wǎng)絡層
3. 在網(wǎng)絡層敏弃，IP協(xié)議，增加作為通信目的地的MAC地址后噪馏，轉發(fā)給鏈路層麦到。到了此時，發(fā)往通信的請求就準備齊全
4. 接收端的服務器在鏈路層接收到數(shù)據(jù)欠肾，按序往上層發(fā)送瓶颠，一直到應用層

當傳輸?shù)綉脤樱拍芩阏嬲邮盏接煽蛻舳税l(fā)送過來的HTTP請求

發(fā)送端在層與層之間傳輸數(shù)據(jù)時刺桃，每經(jīng)過一層粹淋，必定會被打上一個該層所屬的首部信息。反之虏肾，接收端在層與層傳輸數(shù)據(jù)時廓啊，每經(jīng)過一層會把對應的首部消去

過程之中，把數(shù)據(jù)信息包裝起來的做法稱為封裝

1.2 與HTTP關系密切的協(xié)議：IP封豪、TCP和DNS

1.2.1 負責傳輸?shù)腎P協(xié)議

按層次分谴轮，IP(Internet Protocol)網(wǎng)際協(xié)議位于網(wǎng)絡層。 幾乎所有使用網(wǎng)絡的系統(tǒng)都會用到IP協(xié)議

IP協(xié)議的作用是把各種數(shù)據(jù)包傳給對方吹埠。而要保證確實傳到對方那里第步，有兩個重要的條件IP 地址和MAC 地址(Media Access Control Address)

• IP地址指明路節(jié)點被分配到的地址
• MAC地址是指網(wǎng)卡所屬的固定地址

IP地址可以和MAC地址進行配對，但 IP地址可變換缘琅，MAC地址基本上是固定的粘都，唯一的，不會改變

• 使用ARP協(xié)議憑借MAC地址進行通信

IP間的通信依賴MAC地址

一般刷袍，通信的雙方都不在在同一局域網(wǎng)LAN內翩隧，通常是經(jīng)過多臺計算機和網(wǎng)絡設備中轉才能連接到對方。在進行中轉時呻纹，會利用下一站中轉設備的MAC地址搜索下一個中轉目標

搜索中轉目標需要ARP(Address Resolution Rrotocol)協(xié)議堆生，ARP是一種用以解析地址的協(xié)議专缠，根據(jù)通信方的IP地址就可以反查出對應的MAC地址

IP ARP MAC 工作流程

無論哪臺計算機、哪臺網(wǎng)絡設備淑仆，在通信過程中涝婉，它們都無法全面掌握互聯(lián)網(wǎng)中的細節(jié)

在到達通信目標前的中轉過程中，涉及通信的計算機和路由器等網(wǎng)絡設備只能獲悉很粗略的傳輸路線蔗怠，這種機制成為路由選擇(routing)

類似送快遞的整個過程墩弯，寄快遞的人只需要將自己的包裹交給承運人，就可以查詢到自己的包裹的狀態(tài)寞射，位置信息渔工。而接管包裹的快遞公司的集散中心檢查包裹的送達地址，明確下一個送往集散中心怠惶，這個目標集散中心再進行判斷包裹是否達到

整個過程涨缚，每個集散中心并不清楚知道包裹在上個環(huán)節(jié)或下個環(huán)節(jié)的具體細節(jié)

1.2.2 確痹冢可靠的TCP協(xié)議

TCP位于傳輸層策治，提供可靠的字節(jié)流服務

• 字節(jié)流服務：將大塊數(shù)據(jù)分割成以報文段(Byte Stream Service)為單位的數(shù)據(jù)包進行管理

可靠，指的就是將數(shù)據(jù)準確可靠地傳給對方

概括：TCP協(xié)議為了更容易傳送大數(shù)據(jù)才把數(shù)據(jù)分割兰吟，而且TCP協(xié)議能夠確認數(shù)據(jù)最終是否送達對方

• 三次握手

用TCP協(xié)議將數(shù)據(jù)包送出去之后通惫，TCP一定會向對方確認是否成功送達

握手過程中使用了TCP的標志flag——SYN(synchronzie)和ACK(acknowledgement)

3次握手

發(fā)送端首先發(fā)送一個帶SYN標志的數(shù)據(jù)包給對方。接收端收到以后混蔼，回傳一個帶有ACK標志的數(shù)據(jù)包履腋，代表握手結束

握手過程中，某個階段莫名中斷惭嚣，TCP協(xié)議會再次以相同的順序發(fā)送相同的數(shù)據(jù)包

然而3次握手也并不一定能確保數(shù)據(jù)100%準確送到

1.2.3 負責域名解析的DNS服務

DNS(Domain Name System)服務和HTTP協(xié)議一樣位于應用層的協(xié)議遵湖， 提供域名到IP地址之間的解析服務

計算機既可以被賦予IP地址，也可以被賦予主機名和域名晚吞，例如www.baidu.com

域名相比較起IP地址延旧，更利于網(wǎng)站的推廣

但對于計算機而言，理解域名比IP地址要困難的多槽地，計算機更擅長處理一長串數(shù)字

DNS協(xié)議

DNS協(xié)議作用：通過域名來查找IP地址迁沫，或逆向從IP地址反查域名的服務

1.3 各種協(xié)議與HTTP協(xié)議的關系

各種協(xié)議與HTTP協(xié)議的關系

1.4 URI 和 URL

作用：

• URI:用字符串表示某一個互聯(lián)網(wǎng)資源
• URL:統(tǒng)一資源定位符，訪問Web頁面時捌蚊，需要的網(wǎng)頁地址集畅。表示資源所在地點，所處的位置

URL是URI的子集

1.4.1 URI統(tǒng)一資源標識符

URI是Uniform Resource Identifier

• Uniform：
  
  規(guī)定統(tǒng)一的格式可以方便處理多種不同類型的資源缅糟，不用再根據(jù)上下文環(huán)境來識別資源指定的訪問方式挺智。加入新的協(xié)議方案也更容易，例如http:或ftp:

• Resource：
  
  資源窗宦，指的是可標示的任何東西赦颇。除了文檔文件谣辞，圖像，或服務（如天氣預報）等能夠區(qū)別于其他類型的沐扳，全都可以作為資源泥从。資源不僅可以是單一的，也可以是多數(shù)的集合體

• Identifier：
  
  可標示的對象沪摄。也稱為標識符

URI就是由某個協(xié)議方案表示的資源的定位標識符躯嫉，協(xié)議方案是指訪問資源使用的協(xié)議類型名稱

采用HTTP協(xié)議時，協(xié)議方案就是http杨拐，還有ftp,mailto,telnet,file等祈餐。標準的協(xié)議方案有30多種

URI 舉例

1.7.2 URL格式

表示指定的URI，要使用涵蓋全部信息的絕對URI哄陶，絕對URL帆阳，相對URL

相對URI:是指從瀏覽器中基本URI處指定的URL，例如image/logo.png

絕對URI格式

• 協(xié)議方案名：
  
  使用http:或https:等協(xié)議方案名稱獲取訪問資源時要指定協(xié)議類型屋吨，不區(qū)分字母大小寫蜒谤，最后附一個:

• 登錄信息：可選項
  
  指定用戶名和密碼作為從服務器端獲取資源時，必要的登錄信息至扰，也就是身份認證鳍徽，可選項

• 服務器地址：
  
  使用絕對URI必須指定待訪問的服務器地址。地址可以是IP地址敢课，也可以是DNS可以解析的域名

• 服務器端口號：可選項
  
  指定服務器連接的網(wǎng)絡端口號阶祭。可選項直秆，省略使用默認端口號

• 帶層次的文件路徑：
  
  指定服務器上的文件路徑來定位特指的資源

• 查詢字符串：可選項
  
  針對已指定的文件路徑內的資源濒募，可以使用查詢字段傳入任意參數(shù)，可選項

• 片段標識符：可選項
  
  使用片段標識符通郴幔可以標記出已獲取資源中的子資源瑰剃，文檔內的某個位置

2. 簡單的HTTP協(xié)議

主要是對HTTP協(xié)議結構講解，主要使用HTTP/1.1版本

• HTTP協(xié)議用于客戶端和服務端之間的通信
  
  HTTP協(xié)議和TCP/IP協(xié)議族內的其他眾多的協(xié)議相同疫稿，用于客戶端和服務器之間的通信
  
  
  請求訪問文本或圖像等資源的一端稱為客戶端培他，而提供資源的響應的一端稱為服務器端
  
  
  使用HTTP能夠明確區(qū)分哪一端是客戶端，哪一端是服務端

2.1 通過請求和響應的交換達成通信

HTTP協(xié)議規(guī)定遗座，請求從客戶端發(fā)出舀凛，最后服務器端響應該請求并返回。也就是說途蒋，肯定是先從客戶端開始建立通信的猛遍，服務器端在沒有接受到請求之前不會響應

具體示例：

GET請求示例

請求頭報文中內容：

GET / index.htm HTTP/1.1
Host: hackr.jp

含義：請求訪問某臺HTTP服務器上的/index.htm頁面資源

起始行開頭的GET表示請求訪問服務器的類型，稱為方法method。隨后的字符串/index.htm指明了請求訪問的資源對象懊烤，也叫做請求URI梯醒，request-URI。最后的HTTP/1.1腌紧，就是HTTP的版本號茸习，用來提示客戶端使用的HTTP協(xié)議功能

請求報文是由請求方法、請求URL壁肋、協(xié)議版本号胚、可選的請求首部字段和內容實體構成的

請求報文

用于HTTP協(xié)議交互的信息被稱為HTTP報文

響應報文

200表示請求的處理結果的狀態(tài)碼status code，OK是原因短語reason-phrase

下一行顯示了創(chuàng)建響應的日期時間浸遗，是首部字段header first內的一個屬性

接著猫胁，空行；之后跛锌，便是資源的實體entity body

2.2 HTTP是不保存狀態(tài)的協(xié)議

HTTP協(xié)議自身不具備保存之前發(fā)送過的請求或響應的功能

HTTP是一種不保存狀態(tài)弃秆，無狀態(tài)stateless協(xié)議，也就是HTTP這個級別髓帽，協(xié)議對于發(fā)送過的請求或響應都不做持久化處理

為了實現(xiàn)期望的保持狀態(tài)功能菠赚，引入了cookie

使用HTTP協(xié)議時，每當有新的請求時氢卡，就會有對應的新響應產(chǎn)生锈至。協(xié)議本身并不保留之前一切的請求或響應報文的信息

HTTP協(xié)議使用URI定位互聯(lián)網(wǎng)上的資源

2.3 HTTP方法

• GET:獲取資源
  
  
  GET 請求

GET方法用于請求訪問已被URI識別的資源晨缴，指定的資源經(jīng)服務器端解析后返回響應內容

如果請求的資源是文本译秦，就保持原樣返回；如果是像CGI(Common Gateway Interface)通用網(wǎng)關接口那樣的程序击碗，則返回執(zhí)行后的結果

GET 請求響應

• POST：傳輸實體主體
  
  
  POST 請求

PSOT方法用來傳輸實體的主體
雖然用GET方法也可以傳輸實體的筑悴，但一般不用GET方法進行傳輸， POST主要目的不是獲取響應的主體內容

PUT 請求響應

• PUT:用于傳輸文件稍途，就像FTP協(xié)議的文件上傳一樣阁吝，要求在請求報文的主體中包含文件內容，然后保存到請求URI指定的位置械拍，但由于HTTP/1.1的PUT方法自身不帶驗證機制突勇，一般不采用
• HEAD:和GET方法一樣，只是返回報文主體部分坷虑，用于確認URI的有效性及資源更新的日期時間等
• DELETE:刪除文件甲馋，一般也不用
• OPTIONS:詢問支持的方法，用來查詢針對請求URI指定的資源支持的方法

2.4 使用Cookie的狀態(tài)管理

由于HTTP是無狀態(tài)協(xié)議迄损，不會對之前發(fā)生過的請求和響應的狀態(tài)進行管理

當要實現(xiàn)類似保存的登錄信息這樣的需求時定躏，引入了cookie

Cookie會根據(jù)從服務端發(fā)送的響應內的一個叫做Set-Cookie的首部字段信息，通知客戶端保存Cookie。當下次客戶端再往該服務器發(fā)送請求時痊远，客戶端會自動在請求報文中加入Cookie值垮抗，然后發(fā)送出去

服務器端發(fā)現(xiàn)客戶端發(fā)送過來的Cookie后，會主動檢查是從哪一個客戶端發(fā)來的連接請求碧聪，然后對比服務器上的記錄冒版，最后得到之前的狀態(tài)信息

• 沒有Cookie消息狀態(tài)時，第1次請求
  

  沒有Cookie消息狀態(tài)時

• 存入Cookie信息逞姿，第2次請求
  

  存入Cookie信息壤玫，第2次請求

• HTTP請求報文或響應報文
  

  HTTP請求報文或響應報文

3. HTTP報文內的HTTP信息

HTTP通信過程包括從客戶端發(fā)往服務器及從服務端返回客戶端的響應

3.1 HTTP報文

用于HTTP協(xié)議交互的信息被稱為HTTP報文。請求端的HTTP報文叫做請求報文哼凯，響應端的叫做響應報文欲间。HTTP報文本身是由多行數(shù)據(jù)結構構成的字符串文本，用CR+LF作換行符

HTTP報文大致可以分為報文首部和報文主體兩塊断部，兩者由最早出現(xiàn)的空行分隔開猎贴，一般并不一定有報文主體

報文結構

3.2 請求報文及響應報文的結構

請求報文和響應報文結構

請求報文及響應報文 示例

• 請求行：包含用語請求的方法，請求URI和HTTP版本
• 狀態(tài)行：包含表明響應結果的狀態(tài)碼蝴光，原因短語和HTTP版本
• 首部字段：包含表示請求和響應的各種條件和屬性的各類首部她渴，一般有4種，通用首部蔑祟，請求首部趁耗，響應首部，實體首部
• 其他：可能包含HTTP的RFC里未定義的首部疆虚，cookie等

3.3 編碼提升傳輸速率

HTTP在傳輸數(shù)據(jù)時可以按照數(shù)據(jù)原樣直接傳輸苛败，也可以在傳輸過程中通過編碼提升傳輸速率。但径簿，編碼的過程會消耗CPU等資源

3.3.1 報文主體和實體的差異

• 報文Message
  
  HTTP通信中的基本單位罢屈，由8位組字節(jié)流octet sequeence組成，通過HTTP通信傳輸

• 實體Enity
  
  作為請求或響應的有效載荷數(shù)據(jù)被傳輸篇亭，內容由實體首部和實體組成

HTTP報文的主體用語傳輸請求或響應的實體主體

一般缠捌，報文主體等于實體主體，只有當傳輸中進行編碼操作時译蒂，實體主體的內容發(fā)生變化曼月，才導致它和報文主體產(chǎn)生差異

• 壓縮傳輸?shù)膬热菥幋a

1. gzip(GNU zip)
2. compress(Unix系統(tǒng)的標準壓縮)
3. defalte(zlib)
4. identity(不進行編碼)

3.4 發(fā)送多種數(shù)據(jù)的多部分對象集合

郵件中通常可以添加附件柔昼，郵件采用的是MIME(Mulitipurpose Internet Mail Extensions)多用途因特網(wǎng)郵件擴展哑芹，允許郵件處理文本，圖片岳锁，視頻等多個不同類型的數(shù)據(jù)

在HTTP協(xié)議中绩衷，也可以采用多部分對象集合蹦魔，發(fā)送一份報文主體內可以含有多類型實體，通常用于圖片和文本文件上傳

• multipart/form-data
  
  在Web表單文件上傳時使用
• multipart／byteranges
  
  狀態(tài)碼206響應報文包含了多個范圍的內容時使用
• multipart／form-data
  
  
  multipart／form-data
• multipart／byteranges
  
  
  multipart／byteranges

使用boundary字符串來劃分多部分對象集合指名的各類實體類

在boundary字符串指定的各個實體的起始之前加--咳燕，在多部分對象集合對應的字符串的最后插入--作為結束

多部分對象集合的每個部分類型中勿决，都可以含有首部字段，也可以在某個部分中嵌套使用多部分對象集合

4. 最后

前3章的摘抄

有錯誤招盲，請指出

共勉 ：）