首頁  >  文章  >  後端開發  >  php會話控制原理是什麼

php會話控制原理是什麼

爱喝马黛茶的安东尼
爱喝马黛茶的安东尼原創
2019-08-28 13:43:323049瀏覽

php會話控制原理是什麼

會話控制是什麼?

cookie和session都是追蹤整個會話過程的技術手段。而會話,就是使用者透過瀏覽器和伺服器的一次通話。

為什麼要有會話控制?

因為HTTP協定是無狀態的,伺服器不知道使用者上一次做了什麼,這嚴重阻礙了互動式web應用程式的實作。 HTTP不透過額外的手段,伺服器並不知道使用者做了什麼,為了做到這一點,就需要使用cookie和session了。伺服器可以設定或讀取cookie中包含訊息,藉此維護使用者跟伺服器會話中的狀態。

session和cookie的差別?

儲存位置,隱私策略和安全性,資料類型,有效期,伺服器壓力,瀏覽器支持,跨網域支持,資料量。

(1)cookie在客戶端,session在伺服器端

(2)cookie在本地,可以隨便修改,session更安全

(3)cookie只支援ascII字串,需要解碼。 session支援所有的資料類型。

(4)cookie存在本地,可以永久有效。而session在伺服器上,設定永久有效之後,伺服器上session會不斷累積,會導致記憶體溢位。

(5)session會在一定時間內保存在伺服器上。當訪問增多,會比較佔用你伺服器的效能,如果主要考慮到減輕伺服器效能方面,應使用cookie。

(6)cookie需要瀏覽器支持,session不支持。

(7)cookie支援跨域,session不支援跨域。

(8)儲存量不同。

相關推薦:《PHP教程

1 .資料類型的不同

Cookie中只能保管ASCII字串,假如需求存取Unicode字元或二進位數據,需求先進行編碼。 Cookie中也不能直接存取Java物件。若要儲存略微複雜的訊息,運用Cookie是比擬艱難的。

而Session中能夠存取任何類型的數據,包括而不限於String、Integer、List、Map等。 Session中也能夠直接保管Java Bean乃至任何Java類,物件等,運用起來十分便當。能夠把Session看成是一個Java容器類別。

2 .隱私權策略的不同

Cookie儲存在客戶端閱讀器中,對客戶端是可見的,客戶端的一些程式可能會窺探、複製以修正Cookie中的內容。而Session儲存在伺服器上,對客戶端是透明的,不存在敏感資訊外洩的風險。

假如選用Cookie,比較好的方法是,敏感的資訊如帳號密碼等盡量不要寫到Cookie。最好是像Google、Baidu那樣將Cookie資訊加密,提交到伺服器後再進行解密,確保Cookie中的資訊只要本人能讀懂。而假如選擇Session就省事多了,反正是放在伺服器上,Session裡任何隱私都能夠有效的保護。

3.有效期限上的不同

使用過Google的人都曉得,如果登入Google,則Google的登入資訊長期有效。使用者不用每次造訪都重新登錄,Google會持久地記載該使用者的登入資訊。要到達這種效果,運用Cookie會是比較好的選擇。只需要設定Cookie的過期時間屬性為一個很大很大的數字。

由於Session依賴名為JSESSIONID的Cookie,而Cookie JSESSIONID的過期時間默許為–1,只需關閉了閱讀器該Session就會失效,因而Session不能完成資訊永世有效的效果。運用URL位址重寫也不能完成。而且如果設定Session的逾時時間過長,伺服器累計的Session就會越多,越容易招致記憶體溢位。

4.伺服器壓力的不同

Session是保管在伺服器端的,每個使用者都會產生一個Session。假如同時存取的用戶十分多,會產生十分多的Session,耗費大量的記憶體。因而像Google、Baidu、Sina這樣並發訪問量極高的網站,是不太可能運用Session來追蹤客戶會話的。

而Cookie保管在客戶端,不佔用伺服器資源。假如同時閱讀的使用者十分多,Cookie是很好的選擇。關於Google、Baidu、Sina來說,Cookie或許是唯一的選擇。

5.瀏覽器支援的不同

Cookie是需要客戶端瀏覽器支援的。如果客戶端禁用了Cookie,或不支援Cookie,則會話追蹤會失效。關於WAP上的應用,常規的Cookie就派不上用場了。

假如客戶端瀏覽器不支援Cookie,需要運用Session以及URL位址重寫。要注意的是一切的用到Session程式的URL都要進行URL位址重寫,否則Session會話追蹤還會失效。關於WAP應用程式來說,Session URL位址重寫或許是它唯一的選擇。

假如客戶端支援Cookie,則Cookie既能夠設為本瀏覽器視窗以及子視窗內有效(把過期時間設為–1),也能夠設為一切閱讀器視窗內有效(把過期時間設為某個大於0的整數)。但Session只能在本閱讀器視窗以及其子視窗內有效。假如兩個瀏覽器視窗互不相干,它們將運用兩個不同的Session。 (IE8下不同視窗Session相干)

6.跨網域支援上的不同

Cookie支援跨網域訪問,例如將domain屬性設定為“.biaodianfu.com”,則以“ .biaodianfu.com」為後綴的一切網域均能夠存取該Cookie。跨網域Cookie如今普遍用在網路中,例如Google、Baidu、Sina等。而Session則不會支援跨網域存取。 Session僅在他所在的網域內有效。

只運用Cookie或僅運用Session可能完成不了理想的效果。這時應該嘗試同時運用Cookie與Session。 Cookie與Session的搭配運用在實務專案中會完成許多意想不到的效果。

7.儲存資料量不同

單一cookie儲存的資料不能超過4k,很多瀏覽器都限制一個網站最多儲存20個cookie。

session和cookie的使用場景?

將登陸資訊等重要資訊存放為SESSION;其他資訊如果需要保留,可以放在COOKIE中。

cookie的工作原理?

1、cookie分為兩種

(1)以檔案方式存在硬碟空間上的持久cookie(網站的【記住密碼】【自動登入】功能都是持久cookie)

(2)存在瀏覽器中佔用記憶體的臨時cookie

2、cookie採用的是在客戶端保持狀態的方案,它是客戶端的會話狀態的一種儲存機制。它是伺服器在本地機器上存儲的小段文字或記憶體中的一段數據,並隨每一個請求發送至同一個伺服器.

cookie工作原理:

cookie的工作原理,這需要有基本的HTTP協定基礎。

cookie是在RFC2109(已廢棄,被RFC2965取代)裡初次被描述的,每個客戶端最多保持三百個cookie,每個域名下最多20個Cookie(實際上一般瀏覽器現在都比這個多,如Firefox是50個),而每個cookie的大小為最多4K,不過不同的瀏覽器都有各自的實作。對於cookie的使用,最重要的就是控制cookie的大小,不要放入無用的訊息,也不要放入過多資訊。

無論使用何種服務端技術,只要發送回的HTTP回應中包含如下形式的頭,則視為伺服器要求設定一個cookie:

Set-cookie:name=name;expires=date;path=path;domain=domain

支援cookie的瀏覽器都會對此作出反應,即創建cookie檔案並保存(也可能是內存cookie),用戶以後在每次發出請求時,瀏覽器都要判斷當前所有的cookie中有沒有沒失效(根據expires屬性判斷)並且匹配了path屬性的cookie訊息,如果有的話,會以下面的形式加入到請求頭中發回服務端:

Cookie: name="zj"; Path="/linkage"

服務端的動態腳本會對其進行分析,並做出相應的處理,當然也可以選擇直接忽略。

cookie機制Cookies是伺服器在本機上儲存的小段文字並隨每個要求傳送至同一個伺服器。 IETF RFC 2965 HTTP State Management Mechanism 是通用cookie規格。網路伺服器用HTTP頭向客戶端發送cookies,在客戶終端,瀏覽器解析這些cookies並將它們保存為一個本地文件,它會自動將同一伺服器的任何請求縛上這些cookies 。

具體來說cookie機制採用的是在客戶端保持狀態的方案。它是在用戶端的會話狀態的存貯機制,他需要用戶開啟客戶端的cookie支援。 cookie的作用就是為了解決HTTP協定無狀態的缺陷所做的努力。

正統的cookie分發是透過擴充HTTP協定來實現的,伺服器透過在HTTP的回應頭中加上一行特殊的指示以提示瀏覽器依照指示產生對應的cookie。然而純粹的客戶端腳本如JavaScript也可以產生cookie。而cookie的使用是由瀏覽器依照一定的原則在後台自動發送給伺服器的。瀏覽器檢查所有儲存的cookie,如果某個cookie所聲明的作用範圍大於等於將要請求的資源所在的位置,則把該cookie附在請求資源的HTTP請求頭上傳送給伺服器。

cookie的內容主要包括:名字,值,過期時間,路徑和域。路徑與域一起構成cookie的作用範圍。若不設定過期時間,表示這個cookie的生命期為瀏覽器會話期間,關閉瀏覽器窗口,cookie就會消失。這種生命期為瀏覽器會話期的cookie被稱為會話cookie。會話cookie一般不儲存在硬碟上而是保存在記憶體裡,當然這種行為並不是規範規定的。若設定了過期時間,瀏覽器就會把cookie儲存到硬碟上,關閉後再次開啟瀏覽器,這些cookie仍然有效直到超過設定的過期時間。儲存在硬碟上的cookie可以在不同的瀏覽器進程間共用,例如兩個IE視窗。而對於保存在記憶體裡的cookie,不同的瀏覽器有不同的處理方式。

而session機制採用的是一種在伺服器端保持狀態的解決方案。同時我們也看到,由於採用伺服器端保持狀態的方案在客戶端也需要保存一個標識,所以session機制可能需要藉助於cookie機制來達到保存標識的目的。而session提供了方便管理全域變數的方式 。

session是針對每個使用者的,變數的值保存在伺服器上,用一個sessionID來區分是哪個使用者session變數,這個值是透過使用者的瀏覽器在存取的時候回傳給伺服器,當當客戶停用cookie時,這個值也可能設定為由get來回傳給伺服器。

就安全性來說:當你造訪一個使用session 的站點,同時在自己機子上建立一個cookie,建議在伺服器端的session機制更安全些,因為它不會任意讀取客戶儲存的資訊.

session的工作原理?

(1)預設情況下所有的使用者資訊都存放在伺服器的硬碟中。但是可以用memcache把這些資料放在記憶體中。

(2)當客戶端向伺服器發出請求時,要求伺服器端產生一個 session時,伺服器端會先檢查一下,客戶端的 cookie裡面有沒有session_id,是否已經過期。如果有這樣的 session_id的話,伺服器端會根據cookie裡的session_id 把伺服器的 session檢索出來。如果沒有這樣的session_id的話,伺服器端會重新建立一個。 PHPSESSID是一串加了密的字串,它的產生依照一定的規則來執行。同一客戶端啟動二次session_start的話,session_id是不一樣的。

(3)由於採用伺服器端保持狀態的方案在客戶端也需要保存一個標識,所以session機制借助於cookie 機制來達到保存標識的目的

(4)session產生的session_id 放在cookie裡面,如果使用者把cookie禁止掉,是不是session也不能用了呢?禁止掉 cookie後,session 當然可以用,不過透過其他的方式來獲得這個 sessionid,比如,可以根在url的後面,或者以表單的形勢提交到伺服器端。從而使伺服器端了解客戶端的狀態。

再看一下session的原理:

(1)產生全域唯一識別碼(sessionid);

(2)開啟資料儲存空間。一般會在記憶體中建立對應的資料結構,但在這種情況下,系統一旦掉電,所有的會話資料就會遺失,如果是電子商務網站,這種事故會造成嚴重的後果。不過也可以寫到文件裡甚至儲存在資料庫中,這樣雖然會增加I/O開銷,但session可以實現某種程度的持久化,而且更有利於session的共享;

(3)將session的全域唯一標示符傳送給客戶端。

session機制

session機制是一種伺服器端的機制,伺服器使用一種類似雜湊表的結構(也可能就是使用雜湊表)來保存資訊。

當程式需要為某個客戶端的請求建立一個session時,伺服器首先檢查這個客戶端的請求裡是否已包含了一個session標識(稱為session id),如果已包含則表示以前已經為此客戶端創建過session,伺服器就按照session id把這個session檢索出來使用(檢索不到,會新建一個),如果客戶端請求不包含session id,則為此客戶端創建一個session並且產生一個與此session相關聯的session id,session id的值應該是一個既不會重複,又不容易被找到規律以仿造的字串,這個session id將被在本次回應中傳回給客戶端保存。

儲存這個session id的方式可以採用cookie,這樣在互動過程中瀏覽器可以自動的依照規則把這個識別發揮給伺服器。一般這個cookie的名字都是類似SEEESIONID。但cookie可以被人為的禁止,則必須有其他機制以便在cookie被禁止時仍然能夠把session id傳回伺服器。

常被使用的一種技術叫做URL重寫,就是把session id直接附加在URL路徑的後面。還有一種技術叫做表單隱藏欄位。就是伺服器會自動修改表單,新增一個隱藏字段,以便在表單提交時能夠把session id傳回伺服器。

Cookie與Session都能夠進行會話跟踪,但是完成的原理不太一樣。普通狀況下二者皆能滿足需求,但有時分不能夠運用Cookie,有時分不能夠運用Session。以下經過比擬闡明二者的特性以及適用的場所。

以上是php會話控制原理是什麼的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn