http是HyperText Transfer Protocol的縮寫,也稱爲超文本傳輸協議,最初的版本只能用來傳輸html文件,如今則能夠傳輸包括文字、圖像、視頻和二進制文件的全部內容css
一、簡單快速,每一個資源固定出來起來方便 二、 靈活,每一個資源頭部數據類型 三、 無鏈接:鏈接一次就會斷掉,不會一直鏈接 四、無狀態,客戶端和服務端是兩種身份,http幫助鏈接,下次鏈接不會記住狀態,是誰鏈接的
請求報文:請求行、請求頭、空行(告訴服務器請求頭部到此爲止)、請求體html
響應報文:狀態行(200 ok)、響應頭、空行、響應體sql
一、Get 請求能緩存,Post 不能 二、Post 相對 Get 安全一點點,由於Get 請求都包含在 URL 裏,且會被瀏覽器保存歷史紀錄,Post 不會,可是在抓包的狀況下都是同樣的。 三、Post 能夠經過 request body來傳輸比 Get 更多的數據,Get 沒有這個技術 四、URL有長度限制,會影響 Get 請求,可是這個長度限制是瀏覽器規定的,不是 RFC 規定的 五、Post 支持更多的編碼類型且不對數據類型限制 六、在express框架中,對於GET請求的參數'?xxxx=',使用req.query.xxxxx方法得到;對於POST請求的參數,使用req.body.xxxxx方法得到
2XX 成功數據庫
200 OK,表示從客戶端發來的請求在服務器端被正確處理
204 No content,表示請求成功,但響應報文不含實體的主體部分
206 Partial Content,進行範圍請求express
3XX 重定向後端
301 moved permanently,永久性重定向,表示資源已被分配了新的 URL
302 found,臨時性重定向,表示資源臨時被分配了新的 URL
303 see other,表示資源存在着另外一個 URL,應使用 GET 方法丁香獲取資源
304 not modified,表示服務器容許訪問資源,但因發生請求未知足條件的狀況
307 temporary redirect,臨時重定向,和302含義相同瀏覽器
4XX 客戶端錯誤緩存
400 bad request,請求報文存在語法錯誤
401 unauthorized,表示發送的請求須要有經過 HTTP 認證的認證信息
403 forbidden,表示對請求資源的訪問被服務器拒絕
404 not found,表示在服務器上沒有找到請求的資源安全
5XX 服務器錯誤服務器
500 internal sever error,表示服務器端在執行請求時發生了錯誤
503 service unavailable,代表服務器暫時處於超負載或正在停機維護,沒法處理請求
HTTP 協議採用「請求-應答」模式,當使用普通模式,即非 Keep-Alive 模式時,每一個請求/應答客戶和服務器都要新建一個鏈接,完成以後當即斷開鏈接(HTTP協議爲無鏈接的協議);當使用 Keep-Alive 模式(又稱持久鏈接、鏈接重用)時,Keep-Alive 功能使客戶端到服務器端的鏈接持續有效,當出現對服務器的後繼請求時,Keep-Alive 功能避免了創建或者從新創建鏈接
默認狀況下 HTTP 協議中每一個傳輸層鏈接只能承載一個 HTTP 請求和響應,瀏覽器會在收到上一個請求的響應以後,再發送下一個請求。在使用持久鏈接的狀況下,某個鏈接上消息的傳遞相似於請求1 -> 響應1 -> 請求2 -> 響應2 -> 請求3 -> 響應3。
HTTP Pipelining(管線化)是將多個 HTTP 請求整批提交的技術,在傳送過程當中不需等待服務端的迴應。使用 HTTP Pipelining 技術以後,某個鏈接上的消息變成了相似這樣請求1 -> 請求2 -> 請求3 -> 響應1 -> 響應2 -> 響應3。
注意下面幾點:
一、管線化機制經過持久鏈接(persistent connection)完成,僅 HTTP/1.1 支持此技術(HTTP/1.0不支持) 二、只有 GET 和 HEAD 請求能夠進行管線化,而 POST 則有所限制 三、初次建立鏈接時不該啓動管線機制,由於對方(服務器)不必定支持 HTTP/1.1 版本的協議 四、管線化不會影響響應到來的順序,如上面的例子所示,響應返回的順序並未改變 五、HTTP /1.1 要求服務器端支持管線化,但並不要求服務器端也對響應進行管線化處理,只是要求對於管線化的請求不失敗便可 六、因爲上面提到的服務器端問題,開啓管線化極可能並不會帶來大幅度的性能提高,並且不少服務器端和代理程序對管線化的支持並很差,所以現代瀏覽器如 Chrome 和 Firefox 默認並未開啓管線化支持
對於強制緩存,服務器通知瀏覽器一個緩存時間,在緩存時間內,下次請求,直接用緩存,不在時間內,執行比較緩存策略
對於比較緩存,將緩存信息中的Etag和Last-Modified經過請求發送給服務器,由服務器校驗,返回304狀態碼時,瀏覽器直接使用緩存
一、Cookies:瀏覽器均支持,容量爲4KB 二、UserData:僅IE支持,容量爲64KB 三、 Flash:100KB,非HTML原生,須要插件支持 四、 Google Gears SQLite :須要插件支持,容量無限制 五、 LocalStorage:HTML5,容量爲5M 六、 SesstionStorage:HTML5,容量爲5M 七、globalStorage:Firefox獨有的,Firefox13開始就再也不支持這個方法
特色
一、cookie的大小受限制,cookie大小被限制在4KB,不能接受像大文件或郵件那樣的大數據 二、cookie要在服務器和瀏覽器之間來回傳送,cookie數據始終在同源的http請求中攜帶(即便不須要) 三、cookie是服務端生成,客戶端進行維護和存儲
Cookie的生成方式
生成方式一:http response header中的set-cookie
生成方式二:js中能夠經過document.cookie能夠讀寫cookie//以鍵值對的形式展現
Cookie的缺陷
一、cookie會被附加在每一個HTTP請求中,在HttpRequest 和HttpResponse的header中都是要被傳輸的,因此無形中增長了一些沒必要要的流量損失
cookie是用來維護用戶信息的,而域名(domain)下全部請求都會攜帶cookie,但對於靜態文件的請求,攜帶cookie信息根本沒有用,此時能夠經過cdn(存儲靜態文件的)的域名和主站的域名分開來解決
二、因爲在HTTP請求中的Cookie是明文傳遞的,因此安全性成問題,除非用HTTPS。 可使用HttpOnly提高Cookie安全性。httponly 不支持讀寫,瀏覽器不容許腳本操做document.cookie去更改cookie,通常狀況下都應該設置這個爲true,這樣能夠避免被XSS攻擊拿到cookie
session機制是一種服務器端的機制,服務器使用一種相似於散列表的結構(也可能就是使用散列表)來保存信息
這是一種持久化的存儲方式,也就是說若是不手動清除,數據就永遠不會過時。它也是採用Key - Value的方式存儲數據,底層數據接口是sqlite,按域名將數據分別保存到對應數據庫文件裏。它能保存更大的數據(IE8上是10MB,Chrome是5MB),同時保存的數據不會再發送給服務器,避免帶寬浪費
localStorage缺點
① localStorage大小限制在500萬字符左右,各個瀏覽器不一致
② localStorage在隱私模式下不可讀取
③ localStorage本質是在讀寫文件,數據多的話會比較卡
④ localStorage不能被爬蟲爬取,不要用它徹底取代URL傳參
和服務器端使用的session相似,是一種會話級別的緩存,關閉瀏覽器會數據會被清除。不過有點特別的是它的做用域是窗口級別的,也就是說不一樣窗口間的sessionStorage數據不能共享的。
SessionStorage缺點
① 會話級別的瀏覽器存儲② 大小爲5M左右③僅在客戶端使用,不和服務端進行通訊④ 接口封裝較好