http協議是建立在tcp/ip協議之上應用層協議,預設埠為80,8080
http協議的的特點是無狀態,無連線
利用抓包工具httpwatch可以獲取報文
http協議的報文傳輸的是ascii碼,在tcp/ip協議之上,主要主要分為三部分
請求行、請求頭、請求體
第一行,包含三個資訊:請求方式,url,http協議版本
get 請求
post 請求
區別:1、url可見性:
get,引數url可見;
post,url引數不可見
2、資料傳輸上:
get,通過拼接url進行傳遞引數;
post,通過body體傳輸引數
3、快取性:
get請求是可以快取的
post請求不可以快取
4、後退頁面的反應
get請求頁面後退時,不產生影響
post請求頁面後退時,會重新提交請求
5、傳輸資料的大小
get一般傳輸資料大小不超過2k-4k(根據瀏覽器不同,限制不一樣,但相差不大)
post請求傳輸資料的大小根據php.ini 配置檔案設定,也可以無限大。
6、安全性
這個也是最不好分析的,原則上post肯定要比get安全,畢竟傳輸引數時url不可見,但也擋不住部分人閒的沒事在那抓包玩。安全性個人覺得是沒多大區別的,防君子不防小人就是這個道理。對傳遞的引數進行加密,其實都一樣。
本質區別:
get產生乙個tcp資料報;post產生兩個tcp資料報。
對於get方式的請求,瀏覽器會把http header和data一併傳送出去,伺服器響應200(返回資料);
而對於post,瀏覽器先傳送header,伺服器響應100 continue,瀏覽器再傳送data,伺服器響應200 ok(返回資料)。
瀏覽器向伺服器傳送一些狀態資料,標識資料等等
乙個資訊一行,包括資訊名:資訊值 按行分隔
user-agent: firefox//表示傳送請求的瀏覽器(請求**端)是firefoxhost: shop.100.com//表示請求的主機網域名稱(基於網域名稱的虛擬主機就是靠這個頭判斷的)
cookie:name=itcast//瀏覽器攜帶的cookie資料。
content-length: 40
connection: keep-alive
注意,請求頭資訊,需要使用乙個空行結束!
請求**端項伺服器端,傳送的請求資料!
典型的就是post形式傳送的表單資料!
get請求,沒有請求主體部分!get資料是在請求行中的url上進行傳遞的!
響應包括:響應行、響應頭、響應體
響應行包括:協議版本、狀態碼、狀態訊息
典型的:
1xx:訊息
2xx:成功
3xx:請求被重定向
4xx:瀏覽器端錯誤
5xx:伺服器端錯誤
典型:500 伺服器內部錯誤
404 請求的頁面沒有找到
403 沒有許可權
200 請求成功
content-type: text/html 內容型別,告知瀏覽器接下來傳送的響應主體資料是什麼格式!
content-length: 響應主體資料的長度!
date: 響應的時間。gmt時間!
主要的響應資料,在瀏覽器的主體區域顯示的資料都是相應主體!
注意,每行,包括相應行和響應頭,都需要乙個 \r\n結尾
http 協議採用「請求-應答」模式,當使用普通模式,即非 keep-alive 模式時,每個請求/應答客戶和伺服器都要新建乙個連線,完成之後立即斷開連線(http 協議為無連線的協議);當使用 keep-alive 模式(又稱持久連線、連線重用)時,keep-alive 功能使客戶端到伺服器端的連線持續有效,當出現對伺服器的後繼請求時,keep-alive 功能避免了建立或者重新建立連線。
在 http 1.0 版本中,並沒有官方的標準來規定 keep-alive 如何工作,因此實際上它是被附加到 http 1.0協議上,如果客戶端瀏覽器支援 keep-alive ,那麼就在http請求頭中新增乙個字段 connection: keep-alive,當伺服器收到附帶有 connection: keep-alive 的請求時,它也會在響應頭中新增乙個同樣的字段來使用 keep-alive 。這樣一來,客戶端和伺服器之間的http連線就會被保持,不會斷開(超過 keep-alive 規定的時間,意外斷電等情況除外),當客戶端傳送另外乙個請求時,就使用這條已經建立的連線。
在 http 1.1 版本中,預設情況下所有連線都被保持,如果加入 "connection: close" 才關閉。目前大部分瀏覽器都使用 http 1.1 協議,也就是說預設都會發起 keep-alive 的連線請求了,所以是否能完成乙個完整的 keep-alive 連線就看伺服器設定情況。
由於 http 1.0 沒有官方的 keep-alive 規範,並且也已經基本被淘汰,以下討論均是針對 http 1.1 標準中的 keep-alive 展開的。
注意:transfer-encoding 是乙個用來標示 http 報文傳輸格式的頭部值。儘管這個取值理論上可以有很多,但是當前的 http 規範裡實際上只定義了一種傳輸取值——chunked。
如果乙個http訊息(請求訊息或應答訊息)的transfer-encoding訊息頭的值為chunked,那麼,訊息體由數量未定的塊組成,並以最後乙個大小為0的塊為結束。
每乙個非空的塊都以該塊包含資料的位元組數(位元組數以十六進製制表示)開始,跟隨乙個crlf (回車及換行),然後是資料本身,最後塊crlf結束。在一些實現中,塊大小和crlf之間填充有白空格(0x20)。
最後一塊是單行,由塊大小(0),一些可選的填充白空格,以及crlf。最後一塊不再包含任何資料,但是可以傳送可選的尾部,包括訊息頭欄位。訊息最後以crlf結尾。
0預設情況下 http 協議中每個傳輸層連線只能承載乙個 http 請求和響應,瀏覽器會在收到上乙個請求的響應之後,再傳送下乙個請求。在使用持久連線的情況下,某個連線上訊息的傳遞類似於請求1 -> 響應1 -> 請求2 -> 響應2 -> 請求3 -> 響應3
。
http pipelining(管線化)是將多個 http 請求整批提交的技術,在傳送過程中不需等待服務端的回應。使用 http pipelining 技術之後,某個連線上的訊息變成了類似這樣請求1 -> 請求2 -> 請求3 -> 響應1 -> 響應2 -> 響應3
。
注意下面幾點:
跨站請求偽造(csrf篡改本地資訊)
跨站指令碼攻擊(xss,就是在html總嵌入js指令碼)
http頭部攻擊
os命令攻擊
sql注入攻擊
目錄攻擊
dos攻擊
dos攻擊主要是有兩種
1)是集中利用訪問請求,或者攻擊者刻意製造訪問請求,造成資源過載,資源耗盡,服務停止
2)通過攻擊安全漏洞使服務停止
什麼是會話?
客戶端開啟與伺服器的連線發出請求到伺服器響應客戶端請求的全過程稱之為會話。
HTTP協議之報文詳解
學習web開發需要對http協議熟悉,下面直接進入主題。一 什麼是報文 報文,是網路中交換和傳輸的資料單元,即站點一次性要傳送的資料塊。報文包含了將要傳送的完整的資料資訊,其長短很不一致,長度不限且可變。http報文是由一行一行簡單的字串組成的。http報文都是純文字,不是二進位制 所以人們可以很方...
HTTP協議之報文詳解
學習web開發需要對http協議熟悉,下面直接進入主題。一 什麼是報文 報文,是網路中交換和傳輸的資料單元,即站點一次性要傳送的資料塊。報文包含了將要傳送的完整的資料資訊,其長短很不一致,長度不限且可變。http報文是由一行一行簡單的字串組成的。http報文都是純文字,不是二進位制 所以人們可以很方...
HTTP協議之報文詳解
學習web開發需要對http協議熟悉,下面直接進入主題。一 什麼是報文 報文,是網路中交換和傳輸的資料單元,即站點一次性要傳送的資料塊。報文包含了將要傳送的完整的資料資訊,其長短很不一致,長度不限且可變。http報文是由一行一行簡單的字串組成的。http報文都是純文字,不是二進位制 所以人們可以很方...