HTTP協議
在 OSI 七層模型中,HTTP協議位於最頂層的應用層中。通過瀏覽器訪問網頁就直接使用了 HTTP 協議。使用 HTTP 協議時,客戶端首先與服務端的 80 端口建立一個 TCP 連接,然后在這個連接的基礎上進行請求和應答,以及數據的交換。
HTTP 有兩個常用版本,分別是 1.0 和 1.1。主要區別在於 HTTP 1.0 中每次請求和應答都會使用一個新的 TCP 連接,而從 HTTP 1.1 開始,運行在一個 TCP 連接上發送多個命令和應答。因此大幅度減少了 TCP 連接的建立和斷開,提高了效率。
常用的HTTP方法有哪些?
-
GET:用於請求訪問已經被URL(統一資源標識符)識別的資源,可以通過URL傳參給服務器。
-
POST:用於傳輸信息給服務器,主要功能與Get方法類似,但一般推薦POST方式。
-
PUT:傳輸文件,報文主體包含文件內容,保存到對應URL位置。
-
HEAD:獲取報文首部,與GET方法類似,只是不返回報文主體,一般用於驗證URL是否有效。
-
DELET:刪除文件,與PUT方法相反,刪除對應URL位置的文件。
-
OPTIONS:查詢相應URL支持的HTTP方法。
get和post的區別
-
get是從服務器上獲取數據,post是向服務器傳送數據。
-
get是把參數數據隊列加到提交表單的ACTION屬性所指的URL中,值和表單內各個字段一一對應,在URL中可以看到。post是通過HTTP 的post機制,將表單內各個字段與其內容放置在HTML header內一起傳送到ACTION屬性所指的URL地址。用戶看不到這個過程。
-
對於get方式,服務器端用Request.QueryString獲取變量的值,對於post方式,服務器端用Request.Form獲取提交的數據。
-
get傳送的數據量較小,因為受URL限制,不能大於2KB,但是效率高。
post傳送的數據量較大,一般被默認為不受限制,所以上傳文件時只能用post。但理論上,IIS4中最大量為80KB,IIS5中為100KB。 -
get安全性非常低,因為URL是可見的,可能會泄露私密信息,如密碼等,post安全性較高。但是執行效率卻比Post方法好。
-
get方式只能支持ASCII字符,向服務器傳的中文字符可能會亂碼。
post支持標准字符集,可以正確傳遞中文字符。 -
get請求可以被緩存,可以被收藏為書簽,但 post 不行。
-
get請求會保留在瀏覽器的歷史記錄中,post 不會。
SO:
1、get方式的安全性較Post方式要差些,包含機密信息的話,建議用Post數據提交方式;
2、在做數據查詢時,建議用Get方式;而在做數據添加、修改或刪除時,建議用Post方式
PS: POST 請求僅比 GET 請求略安全一點,它的數據不在 URL 中,但依然以明文的形式存放於 HTTP 的請求頭中。
HTTP請求報文與響應報文格式
請求報文包含三部分:
-
請求行:包含請求方法、URI、HTTP版本信息
-
請求首部字段
-
請求內容實體
響應報文包含三部分:
-
狀態行:包含HTTP版本、狀態碼、狀態碼的原因短語
-
響應首部字段
-
響應內容實體
常見的HTTP相應狀態碼
200:請求被正常處理
204:請求被受理但沒有資源可以返回
206:客戶端只是請求資源的一部分,服務器只對請求的部分資源執行GET方法,相應報文中通過Content-Range指定范圍的資源。
301:永久性重定向
302:臨時重定向
303:與302狀態碼有相似功能,只是它希望客戶端在請求一個URI的時候,能通過GET方法重定向到另一個URI上
304:發送附帶條件的請求時,條件不滿足時返回,與重定向無關
307:臨時重定向,與302類似,只是強制要求使用POST方法
400:請求報文語法有誤,服務器無法識別
401:請求需要認證
403:請求的對應資源禁止被訪問
404:服務器無法找到對應資源
500:服務器內部錯誤
503:服務器正忙
常見HTTP首部字段
通用首部字段(請求報文與響應報文都會使用的首部字段)
Date:創建報文時間
Connection:連接的管理
Cache-Control:緩存的控制
Transfer-Encoding:報文主體的傳輸編碼方式
請求首部字段(請求報文會使用的首部字段)
Host:請求資源所在服務器
Accept:可處理的媒體類型
Accept-Charset:可接收的字符集
Accept-Encoding:可接受的內容編碼
Accept-Language:可接受的自然語言
響應首部字段(響應報文會使用的首部字段)
Accept-Ranges:可接受的字節范圍
Location:令客戶端重新定向到的URI
Server:HTTP服務器的安裝信息
實體首部字段(請求報文與響應報文的的實體部分使用的首部字段)
Allow:資源可支持的HTTP方法
Content-Type:實體主類的類型
Content-Encoding:實體主體適用的編碼方式
Content-Language:實體主體的自然語言
Content-Length:實體主體的的字節數
Content-Range:實體主體的位置范圍,一般用於發出部分請求時使用
一次完整的HTTP請求事務包含以下四個環節
-
建立起客戶機和服務器連接。
-
建立連接后,客戶機發送一個請求給服務器。
-
服務器收到請求給予響應信息。
-
客戶端瀏覽器將返回的內容解析並呈現,斷開連接。
一次完整的HTTP請求所經歷的7個步驟
HTTP通信機制是在一次完整的HTTP通信過程中,Web瀏覽器與Web服務器之間將完成下列7個步驟:
建立TCP連接->發送請求行->發送請求頭->(到達服務器)發送狀態行->發送響應頭->發送響應數據->斷TCP連接
建立TCP連接
在HTTP工作開始之前,Web瀏覽器首先要通過網絡與Web服務器建立連接,該連接是通過TCP來完成的,該協議與IP協議共同構建 Internet,即著名的TCP/IP協議族,因此Internet又被稱作是TCP/IP網絡。HTTP是比TCP更高層次的應用層協議,根據規則, 只有低層協議建立之后才能,才能進行更層協議的連接,因此,首先要建立TCP連接,一般TCP連接的端口號是80。
Web瀏覽器向Web服務器發送請求行
一旦建立了TCP連接,Web瀏覽器就會向Web服務器發送請求命令。例如:GET /sample/hello.jsp HTTP/1.1。
Web瀏覽器發送請求頭
瀏覽器發送其請求命令之后,還要以頭信息的形式向Web服務器發送一些別的信息,之后瀏覽器發送了一空白行來通知服務器,它已經結束了該頭信息的發送。
Web服務器應答
客戶機向服務器發出請求后,服務器會客戶機回送應答, HTTP/1.1 200 OK ,應答的第一部分是協議的版本號和應答狀態碼。
Web服務器發送應答頭
正如客戶端會隨同請求發送關於自身的信息一樣,服務器也會隨同應答向用戶發送關於它自己的數據及被請求的文檔。
Web服務器向瀏覽器發送數據
Web服務器向瀏覽器發送頭信息后,它會發送一個空白行來表示頭信息的發送到此為結束,接着,它就以Content-Type應答頭信息所描述的格式發送用戶所請求的實際數據。
Web服務器關閉TCP連接
一般情況下,一旦Web服務器向瀏覽器發送了請求數據,它就要關閉TCP連接,然后如果瀏覽器或者服務器在其頭信息加入了這行代碼:
Connection:keep-alive
TCP連接在發送后將仍然保持打開狀態,於是,瀏覽器可以繼續通過相同的連接發送請求。保持連接節省了為每個請求建立新連接所需的時間,還節約了網絡帶寬。
HTTP優化
-
TCP復用:TCP連接復用是將多個客戶端的HTTP請求復用到一個服務器端TCP連接上,而HTTP復用則是一個客戶端的多個HTTP請求通過一個TCP連接進行處理。前者是負載均衡設備的獨特功能;而后者是HTTP 1.1協議所支持的新功能,目前被大多數瀏覽器所支持。
-
內容緩存:將經常用到的內容進行緩存起來,那么客戶端就可以直接在內存中獲取相應的數據了。
-
壓縮:將文本數據進行壓縮,減少帶寬
-
SSL加密(SSL Acceleration):使用SSL協議對HTTP協議進行加密,在通道內加密並加速
-
TCP緩沖:通過采用TCP緩沖技術,可以提高服務器端響應時間和處理效率,減少由於通信鏈路問題給服務器造成的連接負擔。
HTTP的缺點
-
通信使用明文不加密,內容可能被竊聽
-
不驗證通信方身份,可能遭到偽裝
-
無法驗證報文完整性,可能被篡改
HTTP1.1版本新特性
-
默認持久連接節省通信量,只要客戶端服務端任意一端沒有明確提出斷 - 管線化,客戶端可以同時發出多個HTTP請求,而不用一個個等待響應
-
斷點續傳 (實際上就是利用HTTP消息頭使用分塊傳輸編碼,將實體主體分塊傳輸)
Cookie和Session的區別
HTTP 是一種無狀態的連接,客戶端每次讀取 web頁面時,服務器都會認為這是一次新的會話。但有時候我們又需要持久保持某些信息,比如登錄時的用戶名、密碼,用戶上一次連接時的信息等。這些信息就由 Cookie 和 Session 保存。
Cookie
cookie實際上是一小段文本信息。客戶端請求服務器,如果服務器需要記錄該用戶狀態,就使用response向客戶端瀏覽器頒發一個cookie,客戶端瀏覽器會把cookie保存起來,當瀏覽器再次請求訪問該網站時,瀏覽器把請求的網站連同該cookie一同提交給服務器,服務器檢查該cookie,以此來辨認用戶狀態。
-
簡單來說,cookie的工作原理可總結如下:client連接server
-
client生成cookie(有效期),再次訪問時攜帶cookie
-
server根據cookie的信息識別用戶身份
Session
Session是服務器端使用的一種記錄客戶端狀態的機制,使用上比Cookie簡單一些。同一個客戶端每次和服務端交互時,不需要每次都傳回所有的 Cookie 值,而是只要傳回一個 ID,這個 ID 是客戶端第一次訪問服務器的時候生成的,而且每個客戶端是唯一的。這樣每個客戶端就有了一個唯一的 ID,客戶端只要傳回這個 ID 就行了,這個 ID 通常是 name為 JSESIONID 的一個 Cookie。Session依據這個id來識別是否為同一用戶(只認ID不認人)。
區別:
-
cookie數據存放在客戶的瀏覽器上,session數據放在服務器上。
-
cookie不是很安全,別人可以分析存放在本地的COOKIE並進行COOKIE欺騙
考慮到安全應當使用session。 -
session會在一定時間內保存在服務器上。當訪問增多,會比較占用你服務器的性能
考慮到減輕服務器性能方面,應當使用COOKIE。 -
單個cookie保存的數據不能超過4K,很多瀏覽器都限制一個站點最多保存20個cookie。