在之前的項目裡經常使用到HTTP，但是嘞，又沒有很“經常”。這關系到HTTP一個特點，即“一次配置，終身使用”。
很多時候我們本根不需要去關注他怎麼寫，在公司或者其他組織裡隻要有相關的規範或者說是架構，那麼裡面有關HTTP的部分就是已經寫好的，不管你能不能了解，隻要照着别人寫過的例子你就會使用。但這種會使用還真就不是說也一定能講清楚http。近期面試就有一個很大的感觸，面試官問到有關HTTP的内容時，可以将幾句，但是問深了，問到一些不經常使用的内容就還是會迷糊。
是以這裡是在做一篇有關于HTTP的整理，會講到什麼是HTTP、HTTPS為什麼是安全的、“長連接配接”“連接配接”是什麼、什麼是用JSON傳資料。
什麼是HTTP？
通常我們見到的HTTP就兩個地方:
一是浏覽器位址欄輸入的位址
http（協定類型）://baidu.com（伺服器位址）/user?gender=male(路徑path)；
二是Android裡發送網絡請求，傳回對應内容這個過程。
官方的解釋是：HTTP是一種超文本傳輸協定（Hypertext Transfer Protocol）
翻譯過來就是：在兩個端之間傳輸字元、圖檔、聲音等資訊的一種網絡規範（協定）
也就是浏覽器到伺服器之間的一個過程
三次握手（連接配接），四次揮手（斷開）
不多說，懂的都懂，直接看圖（這裡怎麼去清楚的講給面試官聽，留了一個自由發揮的空間，注意要簡潔明了）
連接配接過程
斷開過程
HTTP的封包
封包包括： 請求行/狀态行、Header、body（body可以有可無）
請求封包
請求方法
所有請求方法的響應都有Body，HEAD除外
GET 請求資源；沒有Body（請求body）
書寫格式，例：
@GET（“users/{id}”）
Call<User> getUser(@path("id") String userId);
POST 修改或删除資源，有Body
PUT 修改資源，有Body
DELETE 删除資源，有Body
HEAD 擷取資訊（與GET請求一樣，不同的是：響應沒有Body）
正常情況下GET請求是不會有Body的，有些公司的程式員會在GET請求裡帶Body，這是一種錯誤的寫法，不規範。
如果背景非要在GET裡面帶Body，那麼上述的GET請求應改為：
@GET("users")
Call<User> getUser(@Body String userId);
除此之外，還應該在Retrofit裡面添加對字元串的支援（因為Body本身不支援字元串）
如果背景非要在GET請求裡面帶Body，在Retrofit裡面沒有加Body（不能有Body的注解）就有可能出現這個報錯（參數不對）：
這種情況最好是聯系背景讓背景改接口（當然也會有方法解決，但是Android端做起來很麻煩）
另外，GET、PUT、DELETE請求都是幂等的（*幂等：多次調用不變）。
響應封包
狀态碼
響應狀态碼的作用在于，讓程式員在開發過程中快速定位到問題所在，友善調試
| 狀态碼 | 含義 | 舉例 |
| 1xx | 消息（臨時消息） | 100：繼續發送、101：正在切換協定 |
| 2xx | 成功 | 200：擷取成功、201：建立成功 |
| 3xx | 重定向 | 301：資源永久遷移、302：資源臨時遷移、304：内容未改變 |
| 4xx | 用戶端錯誤（請求本身錯誤） | 400：用戶端請求錯誤、404：資源不存在、401：認證失敗、資源未授權 |
| 5xx | 伺服器錯誤（記憶體不足） | 500：内部伺服器錯誤、501:未實作（不支援）、502：錯誤的網關、503:服務無法獲得、504:網關逾時、505:不支援的Http版本 |
*重定向：原位址的東西在另一個位址
例：100 繼續
如果伺服器收到頭資訊中帶有100-continue的請求，是用戶端在問伺服器後續的請求中是否可以發送附件。伺服器用100(SC_CONTINUE)允許用戶端繼續或用417 (Expectation Failed)告訴用戶端不同意接受附件
例：101 切換協定
當一個 詢問可以使用http2嗎？如果回複101表示http2也可以用，如果回複200表示不能使用http2
例：200 正常
200 (SC_OK)的意思是一切正常。一般用于相應GET和POST請求。這個狀态碼對servlet是預設的;如果沒有調用setStatus方法的話，就會得到200。
例：201 已建立
201 (SC_CREATED)表示伺服器在請求的響應中建立了新文檔;應在定位頭資訊中給出它的URL。
例：202 接受
202 (SC_ACCEPTED)告訴用戶端請求正在被執行，但還沒有處理完。
例：203 非官方資訊
狀态碼203 (SC_NON_AUTHORITATIVE_INFORMATION)是表示文檔被正常的傳回，但是由于正在使用的是文檔副本是以某些響應頭資訊可能不正确。
例：204 無内容
在并沒有新文檔的情況下，204 (SC_NO_CONTENT)確定浏覽器繼續顯示先前的文檔
例：301 資源永久遷移
當我們輸入某連結為http開頭時，浏覽器會使用将http自動轉為https，這時可以看到響應狀态碼為301，表示這個http裡的内容永久轉移到https上了。
例：400 用戶端錯誤
400 (SC_BAD_REQUEST)指出用戶端請求中的文法錯誤
例：401 未授權
401 (SC_UNAUTHORIZED)表示用戶端在授權頭資訊中沒有有效的身份資訊時通路受到密碼保護的頁面
例：403 禁止
403 (SC_FORBIDDEN)的意思是除非擁有授權否則伺服器拒絕提供所請求的資源。這個狀态經常會由于伺服器上的損壞檔案或目錄許可而引起
例：500 内部伺服器錯誤
500 (SC_INTERNAL_SERVER_ERROR) 是常用的“伺服器錯誤”狀态。該狀态經常由CGI程式引起也可能由無法正常運作的或傳回頭資訊格式不正确的servlet引起
例：501 未實作
501 (SC_NOT_IMPLEMENTED)狀态告訴用戶端伺服器不支援請求中要求的功能。例如，用戶端執行了如PUT這樣的伺服器并不支援的指令
例：502 錯誤的網關
502 (SC_BAD_GATEWAY)被用于充當代理或網關的伺服器;該狀态指出接收伺服器接收到遠端伺服器的錯誤響應
Header（HTTP消息的中繼資料 metadata）
Host ： 服務其位址（目标主機位址）
DNS查詢（Domain Name System 域名）
DNS伺服器詢問 api.github.com的IP位址是多少，伺服器回複這個IP位址給浏器。
Content-Length : 内容的長度（位元組）
給出這個長度是說明要讀取Body裡面的多少個位元組，因為Body的類型有很多種，如果以\n來讀取的話，當碰到Body資訊本身就含有\n的地方時就會停止讀取，這樣會導緻資訊丢失。
Content-Type ： 内容的類型
text/html : html文本，浏覽器頁面響應
application/x-www-from-urlencoded : 普通表單（即純文字表單），encoded URL 格式
multipart/from-data ：多部分形式，一般用于傳輸包含二進制的多項内容（圖檔、檔案等）
普通表單裡隻有文字，可以用&劃分（因為boundary很長浪費空間，這裡不需要使用）
application/json : json形式，用于Web api響應或POST、PUT請求
iamge/jpeg/application/zip... : 單檔案，用于Web api響應或POST、PUT請求
域名是給人類看的，并不能找到該網頁，通過IP位址才能找到網頁（DNS将域名換成IP位址）
Cache：緩存
Buffer：緩沖
HTTPS為什麼是安全的？
HTTPS = HTTP + SSL / TLS （SSL是TLS的前身）
HTTPS沒有版本号，它并不是一個更進階的協定，而是在HTTP下增加的一個安全層，用來保障HTTP的加密傳輸的。
--> 本質上是在用戶端和服務端之間用非對稱加密協商出的一套對稱密鑰，每次發送資訊之前将内容加密，收到資訊後再解密，是内容加密傳輸。
為什麼不直接使用非對稱加密？
因為非對稱加密速度太慢了，裡面使用了很多複雜的數學原理計算非常複雜，完全使用非對稱加密會影響網絡通信的性能。
但是非對稱加密更安全，是以先用非對稱機密去協商一個對稱加密的密鑰，後面再完全使用對稱加密。（這樣可以保證安全性和性能）
HTTPS的連接配接
1.用戶端請求建立TLS的連接配接
首先用戶端發一個單位元組資料（client hello）與伺服器打招呼，并提供所支援TLS版本的集合和加密套件（即，可選的對稱、非對稱的加密算法hash算法），用戶端随機數（本地會保留一份）；
2.伺服器發回證書
伺服器也發送一個單位元組數，并選出TLS的版本和加密套件回複給用戶端（servers hello），伺服器随機數（本地會保留一份）；伺服器把證書發給用戶端（伺服器公鑰）
3.用戶端驗證這個證書
4.用戶端信任伺服器之後與伺服器協商對稱密鑰
用戶端發送根據伺服器的公鑰生成的加密随機數（pre-master secret），
5.使用對稱密鑰開始通信(用戶端)
注釋：證書隻能證明這是我的證書，不一定表示合法
6.finished
7.使用加密通信（伺服器）
8.finished
另外的一些補充資訊：
HTTPS的連接配接是用于加密和解密的；
HTTPS不負責資料的穩定傳輸，資料的穩定傳輸是由TCP負責的
HTTPS需要用到SSL證書，而HTTP不用;
HTTPS标準端口443，HTTP标準端口80;
HTTPS基于傳輸層，HTTP基于應用層;
“長連接配接”“短連接配接”是什麼？
定義
短連接配接：
在三次握手之後建立連接配接，發送資料包并得到伺服器傳回的結果之後，通過用戶端和服務端的四次握手進行關閉斷開
長連接配接：
執行三次握手連結後，不斷開連結，保持用戶端和服務端通信，直到伺服器逾時自動斷開連結，或者用戶端主動斷開連結
HTTP1.0中預設使用短連接配接
HTTP1.1中使用長連接配接。
使用長連接配接的HTTP協定，會在響應頭加入這行代碼：
Connection:keep-alive
HTTP的長連接配接、短連接配接實際還是TCP的長連接配接】短連接配接
優缺點
短連接配接由于三次握手連結及四次握手斷開，在請求頻繁的情況下，連結請求和斷開請求的開銷較大會影響效率
使用場景
長連接配接：用戶端和服務端通信很頻繁的場景，比如：聊天室、實時的遊戲
短連接配接：網頁浏覽等資料重新整理率低的時候
什麼是用JSON傳資料？
Json優點
1.資料格式比較簡單, 易于讀寫, 格式都是壓縮的, 占用帶寬小
2.易于解析這種語言, 用戶端JavaScript可以簡單的通過eval()進行JSON資料的讀取
3.因為JSON格式能夠直接為伺服器端代碼使用, 簡化了伺服器端和用戶端的代碼開發量, 但是完成的任務不變, 且易于維護
JSON文法
文法規則
資料在名稱/值對中
資料由逗号分隔
花括号儲存對象
{"key":value"}==>key=value 因為是字元串是以用雙引号
方括号儲存數組
鍵值對
JSON 資料的書寫格式是：{Key:Value}、{Key:Array}。
注意：如果是字元串則需要用引号
例如：{"name" : "晉二"}等價于js語句的name="晉二"
JSON資料結構中的value的取值：
string（雙引号中）、number、object（花括号中）、array（方括号中）、boolean（true/false）,null
{
"type1": "string",
"type2": 31,
"type3": {"name":"王五"},
"type4": ["張三","李四"],
"type5": true,
"type6": null,
}
一般前後端傳遞資料用的是鍵值對的方式就是JSON傳資料了，另外，fastjson在序列化和反序列化這方面非常友善，可以試試。