請求行
由請求方法字段、URL字段和HTTP協(xié)議字段3個字段組成,它們由空格分隔;
例如,GET /index.html HTTP/1.1。
HTTP協(xié)議的請求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。
請求頭部
請求頭部由關鍵字/值對組成,每行一對,關鍵字和值用英文冒號“:”分隔。
請求頭部通知服務器有關于客戶端請求的信息;
常用的請求頭:
Accept 設置接受的內(nèi)容類型Accept: text/plain
;
Accept-Charset 設置接受的字符編碼:Accept-Charset: utf-8
;
Accept-Encoding 設置接受的編碼格式:Accept-Encoding: gzip, deflate
;
Accept-Language 設置接受的語言:Accept-Language: en-US
;
Cache-Control 設置請求響應鏈上所有的緩存機制必須遵守的指令:Cache-Control: no-cache
;
Connection 設置當前連接和hop-by-hop協(xié)議請求字段列表的控制選項:Connection: keep-alive
;
Content-Length 設置請求體的字節(jié)長度:Content-Length: 348
;
Content-Type 設置請求體的MIME類型(適用POST和PUT請求):Content-Type: application/x-www-form-urlencoded
;
Cookie 設置服務器使用Set-Cookie發(fā)送的http cookie:Cookie: $Version=1; Skin=new;
;
Host 設置服務器域名和TCP端口號,如果使用的是服務請求標準端口號,端口號可以省略:Host: en.wikipedia.org:8080
;
Origin 標識跨域資源請求(請求服務端設置Access-Control-Allow-Origin響應字段):Origin: http://www.example-social-network.com
;
Expires 設置響應體的過期時間:Expires: Thu, 01 Dec 1994 16:00:00 GMT
;
ETag 特定版本資源的標識符,通常是消息摘要:ETag: "737060cd8c284d8af7ad3082f209582d"
;
Last-Modified 設置請求對象最后一次的修改日期:Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
;
空行
最后一個請求頭之后是一個空行,發(fā)送回車符和換行符,通知服務器以下不再有請求頭。
請求主體(數(shù)據(jù))
請求數(shù)據(jù)不在GET方法中使用,而是在POST方法中使用。POST方法適用于需要客戶填寫表單的場合。與請求數(shù)據(jù)相關的最常使用的請求頭是Content-Type和Content-Length。
在響應中唯一真正的區(qū)別在于第一行中用狀態(tài)信息代替了請求信息。狀態(tài)行(status line)通過提供一個狀態(tài)碼來說明所請求的資源情況。
狀態(tài)行
格式:服務器HTTP協(xié)議的版本 響應狀態(tài)代碼 狀態(tài)代碼的文本描述;
狀態(tài)代碼由三位數(shù)字組成,第一個數(shù)字定義了響應的類別,且有五種可能取值:
1xx:指示信息--表示請求已接收,繼續(xù)處理。
2xx:成功--表示請求已被成功接收、理解、接受。
3xx:重定向--要完成請求必須進行更進一步的操作。
4xx:客戶端錯誤--請求有語法錯誤或請求無法實現(xiàn)。
5xx:服務器端錯誤--服務器未能實現(xiàn)合法的請求。
常見狀態(tài)代碼:
200 OK :表示請求成功 一切正常
301 Moved Permanently:重定向,客戶請求的文檔在其他地方,新的URL在Location頭中給出,瀏覽器應該自動地訪問新的URL
302 Found:臨時重定向,類似于301,但新的URL應該被視為臨時性的替代,而不是永久性的。
304 Not Modified:客戶端有緩沖的文檔并發(fā)出了一個條件性的請求。服務器告訴客戶,原來緩沖的文檔還可以繼續(xù)使用。
400 Bad Request:請求出現(xiàn)語法錯誤。
403 Forbidden:資源不可用。
404 Not Found:無法找到指定位置的資源。
405 Method Not Allowed:請求方法(GET、POST、HEAD、Delete、PUT、TRACE等)對指定的資源不適用。
500 Internal Server Error:服務器遇到了意料不到的情況,不能完成客戶的請求。
501 Not Implemented:服務器不支持實現(xiàn)請求所需要的功能
GET提交,請求的數(shù)據(jù)會附在URL之后(就是把數(shù)據(jù)放置在HTTP協(xié)議頭<request-line>中);
POST提交:把提交的數(shù)據(jù)放置在是HTTP包的包體<request-body>中;
傳輸數(shù)據(jù)的大小:
HTTP協(xié)議沒有對傳輸?shù)臄?shù)據(jù)大小進行限制,HTTP協(xié)議規(guī)范也沒有對URL長度進行限制。
而在實際開發(fā)中存在的限制主要有:
GET:特定瀏覽器和服務器對URL長度有限制,例如IE對URL長度的限制是2083字節(jié)(2K+35)。對于其他瀏覽器,如Netscape、FireFox等,理論上沒有長度限制,其限制取決于操作系統(tǒng)的支持。因此對于GET提交時,傳輸數(shù)據(jù)就會受到URL長度的限制。
POST:由于不是通過URL傳值,理論上數(shù)據(jù)不受限。但實際各個WEB服務器會規(guī)定對post提交數(shù)據(jù)大小進行限制,Apache、IIS6都有各自的配置。
4.安全性:
POST的安全性要比GET的安全性高。
通過GET提交數(shù)據(jù),用戶名和密碼將明文出現(xiàn)在URL上,因為
(1)登錄頁面有可能被瀏覽器緩存,
(2)其他人查看瀏覽器的歷史紀錄,那么別人就可以拿到你的賬號和密碼了
1. HTTP和HTTPS
HTTP協(xié)議通常承載于TCP協(xié)議之上,在HTTP和TCP之間添加一個安全協(xié)議層(SSL或TSL),這個時候,就成了我們常說的HTTPS
默認HTTP的端口號為80,HTTPS的端口號為443
2. 為什么HTTPS安全
因為網(wǎng)絡請求需要中間有很多的服務器路由器的轉發(fā)。中間的節(jié)點都可能篡改信息,而如果使用HTTPS,密鑰在你和終點站才有。https之所以比http安全,是因為他利用ssl/tls協(xié)議傳輸。它包含證書,卸載,流量轉發(fā),負載均衡,頁面適配,瀏覽器適配,refer傳遞等。保障了傳輸過程的安全性
3. 關于Http 2.0
HTTP/2引入了“服務端推(server push)”的概念,它允許服務端在客戶端需要數(shù)據(jù)之前就主動地將數(shù)據(jù)發(fā)送到客戶端緩存中,從而提高性能。
HTTP/2提供更多的加密支持
HTTP/2使用多路技術,允許多個消息在一個連接上同時交差。
它增加了頭壓縮(header compression),因此即使非常小的請求,其請求和響應的header都只會占用很小比例的帶寬
4. http缺點:
通信使用明文不加密,內(nèi)容可能被竊取;
不驗證通信方身份,可能遭到偽裝;
無法驗證報文完整性,可能被篡改。
5. HTTP/2 與 HTTP/1.x 的關鍵區(qū)別
二進制協(xié)議代替文本協(xié)議,更加簡潔高效
針對每個域只使用一個多路復用的連接
壓縮頭部信息減小開銷
允許服務器主動推送應答到客戶端的緩存中
簡單版 [ 100 Continue 繼續(xù),一般在發(fā)送post請求時,已發(fā)送了http header之后服務端將返回此信息,表示確認,之后發(fā)送具體參數(shù)信息 200 OK 正常返回信息 201 Created 請求成功并且服務器創(chuàng)建了新的資源 202 Accepted 服務器已接受請求,但尚未處理 301 Moved Permanently 請求的網(wǎng)頁已永久移動到新位置。 302 Found 臨時性重定向。 303 See Other 臨時性重定向,且總是使用 GET 請求新的 URI。 304 Not Modified 自從上次請求后,請求的網(wǎng)頁未修改過。 400 Bad Request 服務器無法理解請求的格式,客戶端不應當嘗試再次使用相同的內(nèi)容發(fā)起請求。 401 Unauthorized 請求未授權。 403 Forbidden 禁止訪問。 404 Not Found 找不到如何與 URI 相匹配的資源。 500 Internal Server Error 最常見的服務器端錯誤。 503 Service Unavailable 服務器端暫時無法處理請求(可能是過載或維護)。 ]
1. 一個頁面從輸入 URL 到頁面加載顯示完成,這個過程中都發(fā)生了什么?(流程說的越詳細越好)
一個頁面從輸入 URL 到頁面加載顯示完成,這個過程中都發(fā)生了什么
2. 說說網(wǎng)絡分層里七層模型是哪七層
應用層:應用層、表示層、會話層(從上往下)(HTTP、FTP、SMTP、DNS)
傳輸層(TCP和UDP)
網(wǎng)絡層(IP)
物理和數(shù)據(jù)鏈路層(以太網(wǎng))
每一層的作用如下:
物理層:通過媒介傳輸比特,確定機械及電氣規(guī)范(比特Bit)數(shù)據(jù)鏈路層:將比特組裝成幀和點到點的傳遞(幀F(xiàn)rame)
網(wǎng)絡層:負責數(shù)據(jù)包從源到宿的傳遞和網(wǎng)際互連(包PackeT)
傳輸層:提供端到端的可靠報文傳遞和錯誤恢復(段Segment)
會話層:建立、管理和終止會話(會話協(xié)議數(shù)據(jù)單元SPDU)
表示層:對數(shù)據(jù)進行翻譯、加密和壓縮(表示協(xié)議數(shù)據(jù)單元PPDU)
應用層:允許訪問OSI環(huán)境的手段(應用協(xié)議數(shù)據(jù)單元APDU)
3. 304緩存的原理
服務器首先產(chǎn)生ETag,服務器可在稍后使用它來判斷頁面是否已經(jīng)被修改。本質上,客戶端通過將該記號傳回服務器要求服務器驗證其(客戶端)緩存
304是HTTP狀態(tài)碼,服務器用來標識這個文件沒修改,不返回內(nèi)容,瀏覽器在接收到個狀態(tài)碼后,會使用瀏覽器已緩存的文件
客戶端請求一個頁面(A)。 服務器返回頁面A,并在給A加上一個ETag。 客戶端展現(xiàn)該頁面,并將頁面連同ETag一起緩存。 客戶再次請求頁面A,并將上次請求時服務器返回的ETag一起傳遞給服務器。 服務器檢查該ETag,并判斷出該頁面自上次客戶端請求之后還未被修改,直接返回響應304(未修改——Not Modified)和一個空的響應體
認識更多--瀏覽器緩存篇
相信看了本文案例你已經(jīng)掌握了方法,更多精彩請關注Gxl網(wǎng)其它相關文章!
推薦閱讀:
Oday提權批量拿取商城服務器root權限步奏詳解
在HTML中使用JS方法總結
聲明:本網(wǎng)頁內(nèi)容旨在傳播知識,若有侵權等問題請及時與本網(wǎng)聯(lián)系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com