前端常见知识点一之HTTP
生活随笔
收集整理的這篇文章主要介紹了
前端常见知识点一之HTTP
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
大半年沒更新了，一直忙，公司也沒有外網，這次找些材料整理復習鞏固一下。資料來源于網絡。
這里寫目錄標題
- 一、HTTP與HTTPS
- 1.http和https基本概念
- 2.http和https的區別
- 3.https協議的工作原理
- 4.http協議的優點
- 5.http協議的缺點
- 6.TCP三次握手、四次揮手
- 7.TCP和UDP的區別
- 8. 網絡七層模型
- 9.HTTP請求方式
- 10. HTTP2.0
- 11. 400和401、403狀態碼
- 12.HTTP狀態碼
- 13.http常用請求頭
- 14.強、協商緩存
- 15.GET和POST的區別
- 16.常見的HTTP頭部
一、HTTP與HTTPS
1.http和https基本概念
http: 超文本傳輸協議，是互聯網上應用最為廣泛的一種網絡協議，是一個客戶端和服務器請求和應答的標準（tcp），用于從WWW服務器傳輸超文本到瀏覽器的傳輸協議，它可以使瀏覽器更加高效，使網絡傳輸減少。
https: 是以安全為目標的http通道，簡單的講是http的安全版，即http下加入ssl層，http的安全基礎是ssl，因此加密的詳細內容就需要ssl。
https協議的主要作用是：建立一個信息安全通道，來確保數組的傳輸，確保網站的真實性
2.http和https的區別
http傳輸的數據都是未加密的，也是明文的，網景公司設置了SSL協議來對http協議傳輸的數據進行加密處理，簡單來說https協議是有http和ssl協議構建的可進行加密傳輸和身份認證的網絡協議，比http協議的安全性更高。 區別：
3.https協議的工作原理
客戶端在使用https方式與Web服務器通信時有以下幾個步驟:
4.http協議的優點
使用https協議可認證用戶和服務器，確保數據發送到正確的客戶機和服務器。
https協議是由http+ssl協議構建的可進行加密傳輸、身份認證的網絡協議，要比http協議安全，可防止數據在傳輸的過程中不被竊取、改變，確保數據的完整性。
https是現行框架下最安全的解決方案，雖然不是絕對的安全，但它大幅增加了中間人攻擊的成本。
比起同等http網站，采用https加密的網站在搜索中的排名將會更高。
5.http協議的缺點
https握手階段比較費時，會使頁面加載時間延長50%，增加費電。
https緩存不如http高效，會增加數據開銷。
ssl證書也需要錢，功能越強大的證書費用更高。
ssl證書需要綁定ip，不能在同ip上綁定多個域名，ipv4資源支持不了這種消耗。
6.TCP三次握手、四次揮手
三次握手的本質是確認通信雙方收發數據的能力：
首先，我讓信使運輸一份信件給對方，對方收到了，那么他就知道了我的發件能力和他的收件能力是可以的。
于是他給我回信，我若收到了，我便知我的發件能力和他的收件能力是可以的，并且他的發件能力和我的收件能力是可以。
然而此時他還不知道他的發件能力和我的收件能力到底可不可以，于是我最后回饋一次，他若收到了，他便清楚了他的發件能力和我的收件能力是可以的。
- 第一次握手：客戶端要向服務端發起連接請求，并發送報文；
- 第二次握手：服務端收到客戶端發過來的報文，并給客戶端回復可以建立連接
- 第三次握手：客戶端收到服務端的回復后，知道了服務端同意了這次連接，然后客戶端再回復一段報文給服務端建立連接；
四次揮手的目的是關閉一個連接
- 第一次揮手：當客戶端的數據都傳輸完成后，客戶端向服務端發出連接釋放報文
- 第二次揮手：服務端收到客戶端發的報文后給客戶端回復確認報文，此時服務端處于關閉等待狀態，因為服務端可能還有數據沒發完
- 第三次揮手：服務端將最后數據(比如50個字節)發送完畢后就向客戶端發出連接釋放報文
- 第四次揮手：客戶端收到服務端發的FIN報文后，向服務端發出確認報文，服務端收到確認報文釋放連接。
注意客戶端發出確認報文后不是立馬釋放TCP連接，而是要經過2MSL(最長報文段壽命的2倍時長)后才釋放TCP連接。而服務端一旦收到客戶端發出的確認報文就會立馬釋放TCP連接，所以服務端結束TCP連接的時間要比客戶端早一些。
想了解更清楚請移步該文章：《臥槽！牛皮了，頭一次見有大佬把TCP/IP三次握手四次揮手解釋的這么明白》
7.TCP和UDP的區別
UDP沒有擁塞控制，因此網絡出現擁塞不會使源主機的發送速率降低（對實時應用很有用，如IP電話，實時視頻會議等）；
那HTTP和TCP之間又有什么樣的關系？那我們先來了解一下網絡七層模型（OSI）:
8. 網絡七層模型
- 物理層：
物理層負責最后將信息編碼成電流脈沖或其它信號用于網上傳輸；
eg：RJ45等將數據轉化成0和1 - 數據鏈路層:
數據鏈路層通過物理網絡鏈路供數據傳輸。不同的數據鏈路層定義了不同的網絡和協 議特征,其中包括物理編址、網絡拓撲結構、錯誤校驗、數據幀序列以及流控;
可以簡單的理解為：規定了0和1的分包形式，確定了網絡數據包的形式； - 網絡層
網絡層負責在源和終點之間建立連接;
可以理解為，此處需要確定計算機的位置，怎么確定？IPv4，IPv6！ - 傳輸層
傳輸層向高層提供可靠的端到端的網絡數據流服務。
可以理解為：每一個應用程序都會在網卡注冊一個端口號，該層就是端口與端口的通信！常用的（TCP／IP）協議； - 會話層
會話層建立、管理和終止表示層與實體之間的通信會話；
建立一個連接（自動的手機信息、自動的網絡尋址）; - 表示層:
表示層供多種功能用于應用層數據編碼和轉化,以確保以一個系統應用層發送的信息 可以被另一個系統應用層識別;
可以理解為：解決不同系統之間的通信，eg：Linux下的QQ和Windows下的QQ可以通信 - 應用層:
OSI 的應用層協議包括文件的傳輸、訪問及管理協議(FTAM) ,以及文件虛擬終端協議(VIP)和公用管理系統信息(CMIP)等;
規定數據的傳輸協議
參考移步：《深入淺出－網絡七層模型》
9.HTTP請求方式
get，head，post，put，delete，connect，options，trace
- get：請求指定頁面信息，并返回實體主體；
- head：類似于get請求，只不過返回的響應中沒有具體的內容，用于獲取報頭；
- post：向指定資源提交數據進行處理請求（如提交表單或者上傳文件）。數據被包含在請求體中。post請求可能會導致新的資源的建立或已有資源的修改；
- put：從客戶端向服務器傳送的數據取代指定資源內容；
- delete：請求服務器刪除指定的頁面；
- connect：HTTP/1.1協議中預留給能夠將連接改為管道方式的代理服務器；
- options：允許客戶端查看服務器的性能；
- trace：回顯服務器收到的請求，主要用于測試或診斷
10. HTTP2.0
- 與http相比較，提升了訪問速度，請求資源所需的時間更少
- 內容安全，因為http2.0是基于https的，天然具有安全特性，通過http2.0的特性可以避免單純使用https的性能下降
- 二進制格式，http1.x的解析是基于文本的，http2.0將所有的信息分割為更小的消息和幀，并對他們采用二進制格式編碼，基于二進制可以讓協議有更多的擴展性，比如引入幀來傳輸數據和指令
- 允許多路復用，多路復用允許同時通過單一的HTTP2連接發送多重請求-響應信息，另外多路復用中也支持了流的優先級，允許客戶端告訴服務器那些內容是更優先級的資源
- 改善了在HTTP1.1中，瀏覽器在同一時間，針對同一域名下的請求有一定數量限制（連接數量），超過限制會被阻塞
- 首部壓縮
- 服務器推送
11. 400和401、403狀態碼
- 400狀態碼：請求無效
產生原因：
- 401狀態碼：當前請求需要用戶驗證
- 403狀態碼：服務已經得到請求、但是拒絕執行
12.HTTP狀態碼
- 100 Contion 繼續。客戶端應該繼續其請求；
- 101 SwitchingProtocols 切換協議。服務器根據客戶端的請求切換協議。只能切換到更高級的協議，例如，切換到HTTP的新版本協議；
- 200 OK 請求成功。一般用于GET和POST請求；
- 201 Created 已創建。成功請求并創建了新的資源；
- 202 Accepted 已接受。已接受請求，但未處理完成；
- 203 Non-Authoritative Information 非授權信息。請求成功但返回的meta信息不在原始服務器，而是一個副本
- 204 No Content 無內容。服務器處理成功，但未能返回內容。在未更新網頁的情況下，可確保瀏覽器繼續顯示當前文檔；
- 205 Reset Content 重置內容。服務器處理成功，用戶終端（瀏覽器）應重置文檔視圖。可通過此返回碼清除瀏覽器的表單域；
- 206 Partial Content 部分內容。服務器成功處理部分GET請求；
- 300 Multiple Choices 多種選擇。請求的資源可包括多個位置，相應可返回一個資源特征與地址的列表用于用戶終端（瀏覽器）選擇；
- 301 Moved Permanently 永久移動。請求的資源已被永久的移動到新的URL，返回信息會包括新的URL，瀏覽器會自動定向到新的URL。今后任何新的請求都應使用新的URL代替。
- 302 Found 臨時移動。與301類似。但資源只是臨時被移動。客戶端應繼續使用原有的URL；
- 303 See Other 查看其它地址。與301類似。使用GET和POST請求查看；
- 304 Not Modified 未修改。所有請求的資源未修改，服務器返回此狀態碼時，不會返回任何資源。客戶端通常會緩存訪問過的資源，通過提供一個頭信息指出客戶端希望只返回在指定日期之后修改的資源；
- 305 Use Proxy 使用代理。所請求的資源必須經過代理訪問；
- 306 Unused 已經被廢棄的HTTP狀態碼
- 307 Tenporary Redirect 臨時重定向。與302類似。使用GET請求重定向；
- 400 Bad Request 客戶端請求的語法錯誤，服務器無法理解；
- 401 Unauthorized 請求要求用戶的身份認證；
- 402 Payment Required 保留，將來使用；
- 403 Forbidden 服務器理解請求客戶端的請求，但是拒絕執行次請求
- 404 Not Found 服務器無法根據客戶端的請求找到網頁。通過此代碼，網站設計人員可設置“您所其你去的資源無法找到”的個性頁面
- 405 Method Not Allowed 客戶端請求中的方法被禁止
- 406 Not Acceptable 服務器無法根據客戶端請求的內容特性完成請求；
- 407 Poxy Authentication Required 請求要求代理的身份認證，與401類似但請求者應當使用代理進行授權；
- 408 Reuest Time-out 服務器等待客戶端發送的請求時間過長，超時
- 409 Conflict 服務器完成客戶端的PUT請求是可能返回此代碼，服務器處理請求時發生了沖突
- 410 Gone 客戶端請求的資源已經不存在。410不同于404，如果資源以前有現在被永久刪除了可使用410代碼，網站設計人員可通過301代碼指定資源的新位置；
- 411 Length Required 服務器無法處理客戶端發送的不帶Content-Length的請求信息；
- 412 Precondition Failed 客戶端請求信息的先決條件錯誤；
- 413 Request Entity Too Large 由于請求的實體過大，服務器無法處理，因此拒絕請求，為防止客服端的連續請求，服務器可能會關閉連接。如果只是服務器暫時無法處理，則會包含一個Retry-After的響應信息；
- 414 Request-URL Too Large 請求的url過長，服務器無法處理；
- 415 Unsupported Media Type 服務器無法處理請求附帶的媒體格式；
- 416 Request range not satisfiable 客戶端請求的范圍無效；
- 417 Expectation Failed服務器無法滿足Expect的請求頭信息；
- 500 Internal Server Error 服務器內部錯誤，無法完成請求
- 501 Not Implemented 服務齊全不支持請求的功能，無法完成請求；
- 502 Bad Gateway 作為網關或者代理工作的服務器嘗試執行請求時，從遠程服務器收到了一個無效的響應
- 503 Service Unavailable 由于超載或系統維護，服務器暫時的無法處理客戶端的請求。延時的長度可能包含在服務器的Retry-After頭信息中；
- 504 Gateway Time-out 充當網關或代理的服務器，未及時從遠端服務器獲取請求
- 505 HTTP Version not supported 服務器不支持請求的HTTP協議版本，無法完成處理
13.http常用請求頭
| Accept | 可接受的響應內容類型（content-type） |
| Accept-Charset | 可接受的字符集 |
| Accept-Encoding | 可接受的相應內容的編碼方式 |
| Accept-Language | 可接受的響應內容語言列表 |
| Accept-Datetime | 可接受的按照時間來表示的響應內容版本 |
| Authorization | 用于表示HTTP協議中需要認證資源的認證信息 |
| Cache-Control | 用來指定當前的請求/回復中的，是否使用緩存機制 |
| Cennection | 客戶端（瀏覽器）優先使用的連接類型 |
| Cookie | 由之前服務器通過set-cookie設置的一個HTTP協議cookie |
| Content-Length | 以8進制表示的請求體的長度 |
| Content-MD5 | 請求體的內容的二進制MD5散列值（數字簽名），以Base64編碼的結果 |
| Content-Type | 請求體的MIME類型（用于POST和PUT請求中） |
| Date | 發送該消息的日期和時間 |
| Expect | 表示客戶端要求服務器做出特定的行為 |
| From | 發起此請求的用戶的郵件地址 |
| Host | 表示 服務器的域名以及服務器所監聽的端口號。如果所請求的端口是對應的服務器的標準端口（80），則端口號可以省略 |
| If-Match | 僅當客戶端提供的實體與服務器上對應的實體相匹配時，才進行對應的操作。主要用于像PUT這樣的方法中，僅當從用戶上次更新某個資源后，該資源未被修改的情況下，才更新該資源 |
| If-modified-since | 允許在應對的資源未被修改的情況下返回304未修改 |
| If-none-Match | 允許在應對的內容未被修改的情況下返回304未修改（304 Not Modified），參考超文本傳輸協議的實體標記 |
| If-Range | 如果該實體未被修改過，則返回所缺少的那一個或多個部分，否則，返回整個新的實體 |
| If-Unmodified-Since | 僅當該實體自某個特定時間以來未被修改的情況下，才發送回應 |
| Max-Forwards | 限制該消息可被代理及網關轉發的次數 |
| Origin | 發起一個針對跨域資源共享的請求（該請求要求服務器在響應中加入一個Access-Control-Allow-Origin的消息頭，表示訪問控制所允許的來源） |
| Pragma | 與具體的實現相關。這些字段可能在請求/回應鏈中的任何時候產生 |
| Porxy-Authorization | 用于向代理進行認證的認證信息 |
| Range | 表示請求某個實體的一部分，字節偏移以0開始 |
| Referer | 表示瀏覽器所訪問的前一個頁面，可以認為是之前訪問頁面的鏈接將瀏覽器帶到了當前頁面，Referere其實是Referrer這個單詞，但是RFC制作標準時給拼錯了，后來也就將錯就錯使用Referer了 |
| TE | 瀏覽器預期接受的傳輸時的編碼方式：可使用回應協議頭Transfer-Encoding中的值用來表示瀏覽器希望在最后一個大小為0的塊之后還要接收到一些額外的字段 |
| User-Agent | 瀏覽器的身份標識字符串 |
| Upgrade | 要求服務器升級到一個高版本協議 |
| Via | 告訴服務器，這個請求是由哪些代理發出的 |
| Waming | 一個一般性的警告，表示在實體內容體中可能存在錯誤 |
14.強、協商緩存
緩存分為兩種：強緩存和協商緩存，根據響應的header內容來決定。
因為服務器上的資源不是一直固定不變的，大多數情況下它會更新，這個時候如果我們還訪問本地緩存，那個對用戶來說，那就是相當于，用戶看到的還是舊的資源；所以我們希望服務器上的資源更新了，瀏覽器就請求新的資源，沒有更新就使用本地的緩存，以最大程度的減少因網絡請求而產生的資源浪費。
瀏覽器請求流程：
- 瀏覽器會獲取該緩存資源的 header 中的信息，根據 response header 中的 expires 和 cache-control 來判斷是否命中強緩存，如果命中則直接從緩存中獲取資源。
- 如果沒有命中強緩存，瀏覽器就會發送請求到服務，服務器會通過 Last-Modified或者 Etag來判斷是否命中協商緩存。
- 如果命中，則服務器返回 304 狀態碼，并且不會返回資源內容，瀏覽器會直接從緩存獲取；
- 否則服務器最終會返回資源的實際內容，并更新 header 中的相關緩存字段。
強緩存相關字段有expires，cache-control后者優先級更高
協商緩存相關字段:Last-Modified/If-Modified-Since,Etag/If-none-Match
15.GET和POST的區別
- get參數通過url傳遞，post放在request body中；
- get請求在url中的參數有長度限制，post沒有；
- get比post更不安全，因為參數直接暴露在url中，所以不能用來傳遞敏感信息；
- get請求只能進行url編碼，而post支持多種方式編碼；
- get請求參數會被完整保留在瀏覽器的歷史記錄中，而post中的參數不會被保留；
- get和post本質上即使tcp鏈接，并無差別，但是由于HTTP的規定和 瀏覽器/服務器的限制，導致他們在應用過程中體現出一些不同；
- get產生一個tcp數據包，post產生兩個tcp數據包
16.常見的HTTP頭部
可以將http頭部分為：通用首部、請求首部、響應首部、實體首部
- 通用首部：表示一些通用信息，比如date表示報文創建時間
- 請求首部：請求報文中獨有的，如cookie，和緩存相關的如if-Modified-Since
- 響應首部：響應報文中獨有的，如set-cookie，和重定向相關的location
- 實體首部：用來描述實體部分，如allow用來描述可執行的請求方法，caontent-type描述主體類型，content-Encoding描述主體的編碼方式
總結
以上是生活随笔為你收集整理的前端常见知识点一之HTTP的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 南京驾车到甘南藏族自治州米拉日巴佛楼阁怎
- 下一篇： 2017年html5行业报告,云适配发布