❶ 視頻監控系統前端設備包括哪些
視頻監控系統產品包含光端機,光纜終端盒,雲台,雲台解碼器,視頻矩陣,硬碟錄像機,監控攝像機,鏡頭,支架。視頻監控系統組成部分包括監控前端、管理中心、監控中心、PC客戶端及無線網橋。組成部分的說明如下:
1、監控前端:用於採集被監控點的監控信息,並可以配備報警設備。①普通攝像頭+視頻伺服器。普通攝像頭可以是模擬攝像頭,也可以是數字攝像頭。原始視頻信號傳到視頻伺服器,經視頻伺服器編碼後,以TCP/IP協議通過網路傳至其他設備。
網路攝像頭。網路攝像頭是融攝像、視頻編碼、Web服務於一體的高級攝像設備,內嵌了TCP/IP協議棧。可以直接連接到網路。
2、管理中心:承擔所有前端設備的管理、控制、報警處理、錄像、錄像回放、用戶管理等工作。各部分功能分別由專門的伺服器各司其職。
3、監控中心:用於集中對所轄區域進行監控,包括電視牆、監控客戶終端群組成。系統中可以有一個或多個監控中心。
4、PC客戶端:在監控中心之外,也可以由PC機接到網路上進行遠程監控。
5、無線網橋:無線網橋用於接入無線數據網路,並訪問互聯網。通過無線網橋,可以將IP網上的監控信息傳至無線終端,也可以將無線終端的控制指令傳給IP網上的視頻監控管理系統。常用的無線網路為CDMA網路。
❷ 前端本地數據存儲localStorage
場景1、 調用登錄介面,當後端放回登錄成功後,此時需要把用戶令牌token存儲
場景2、當用戶操作時檢測當前的時間,如果當前的時間超過擬定的時間 就把登錄信息清空,並返回登錄頁面
❸ 鑒權必須了解的 5 個兄弟:cookie、session、token、jwt、單點登錄
本文你將看到:
**「前端存儲」**這就涉及到一發、一存、一帶,發好辦,登陸介面直接返回給前端,存儲就需要前端想辦法了。
前端的存儲方式有很多。
有,cookie。cookie 也是前端存儲的一種,但相比於 localStorage 等其他方式,藉助 HTTP 頭、瀏覽器能力,cookie 可以做到前端無感知。一般過程是這樣的:
「配置:Domain / Path」
cookie 是要限制::「空間范圍」::的,通過 Domain(域)/ Path(路徑)兩級。
「配置:Expires / Max-Age」
cookie 還可以限制::「時間范圍」::,通過 Expires、Max-Age 中的一種。
「配置:Secure / HttpOnly」
cookie 可以限制::「使用方式」::。
**「HTTP 頭對 cookie 的讀寫」**回過頭來,HTTP 是如何寫入和傳遞 cookie 及其配置的呢?HTTP 返回的一個 Set-Cookie 頭用於向瀏覽器寫入「一條(且只能是一條)」cookie,格式為 cookie 鍵值 + 配置鍵值。例如:
那我想一次多 set 幾個 cookie 怎麼辦?多給幾個 Set-Cookie 頭(一次 HTTP 請求中允許重復)
HTTP 請求的 Cookie 頭用於瀏覽器把符合當前「空間、時間、使用方式」配置的所有 cookie 一並發給服務端。因為由瀏覽器做了篩選判斷,就不需要歸還配置內容了,只要發送鍵值就可以。
**「前端對 cookie 的讀寫」**前端可以自己創建 cookie,如果服務端創建的 cookie 沒加HttpOnly,那恭喜你也可以修改他給的 cookie。調用document.cookie可以創建、修改 cookie,和 HTTP 一樣,一次document.cookie能且只能操作一個 cookie。
調用document.cookie也可以讀到 cookie,也和 HTTP 一樣,能讀到所有的非HttpOnly cookie。
現在回想下,你刷卡的時候發生了什麼?
這種操作,在前後端鑒權系統中,叫 session。典型的 session 登陸/驗證流程:
**「Session 的存儲方式」**顯然,服務端只是給 cookie 一個 sessionId,而 session 的具體內容(可能包含用戶信息、session 狀態等),要自己存一下。存儲的方式有幾種:
「Session 的過期和銷毀」**很簡單,只要把存儲的 session 數據銷毀就可以。****「Session 的分布式問題」**通常服務端是集群,而用戶請求過來會走一次負載均衡,不一定打到哪台機器上。那一旦用戶後續介面請求到的機器和他登錄請求的機器不一致,或者登錄請求的機器宕機了,session 不就失效了嗎?這個問題現在有幾種解決方式。
但通常還是採用第一種方式,因為第二種相當於閹割了負載均衡,且仍沒有解決「用戶請求的機器宕機」的問題。**「node.js 下的 session 處理」**前面的圖很清楚了,服務端要實現對 cookie 和 session 的存取,實現起來要做的事還是很多的。在npm中,已經有封裝好的中間件,比如 express-session - npm,用法就不貼了。這是它種的 cookie:
express-session - npm 主要實現了:
session 的維護給服務端造成很大困擾,我們必須找地方存放它,又要考慮分布式的問題,甚至要單獨為了它啟用一套 Redis 集群。有沒有更好的辦法?
回過頭來想想,一個登錄場景,也不必往 session 存太多東西,那為什麼不直接打包到 cookie 中呢?這樣服務端不用存了,每次只要核驗 cookie 帶的「證件」有效性就可以了,也可以攜帶一些輕量的信息。這種方式通常被叫做 token。
token 的流程是這樣的:
**「客戶端 token 的存儲方式」 在前面 cookie 說過,cookie 並不是客戶端存儲憑證的唯一方式。token 因為它的「無狀態性」,有效期、使用限制都包在 token 內容里,對 cookie 的管理能力依賴較小,客戶端存起來就顯得更自由。但 web 應用的主流方式仍是放在 cookie 里,畢竟少操心。 「token 的過期」**那我們如何控制 token 的有效期呢?很簡單,把「過期時間」和數據一起塞進去,驗證時判斷就好。
編碼的方式豐儉由人。**「base64」**比如 node 端的 cookie-session - npm 庫
默認配置下,當我給他一個 userid,他會存成這樣:
這里的 eyJ1c2VyaWQiOiJhIn0=,就是 {"userid":"abb」} 的 base64 而已。 「防篡改」
是的。所以看情況,如果 token 涉及到敏感許可權,就要想辦法避免 token 被篡改。解決方案就是給 token 加簽名,來識別 token 是否被篡改過。例如在 cookie-session - npm 庫中,增加兩項配置:
這樣會多種一個 .sig cookie,裡面的值就是 {"userid":"abb」} 和 iAmSecret通過加密演算法計算出來的,常見的比如HMACSHA256 類 (System.Security.Cryptography) | Microsoft Docs。
好了,現在 cdd 雖然能偽造出eyJ1c2VyaWQiOiJhIn0=,但偽造不出 sig 的內容,因為他不知道 secret。**「JWT」**但上面的做法額外增加了 cookie 數量,數據本身也沒有規范的格式,所以 JSON Web Token Introction - jwt.io 橫空出世了。
它是一種成熟的 token 字元串生成方案,包含了我們前面提到的數據、簽名。不如直接看一下一個 JWT token 長什麼樣:
這串東西是怎麼生成的呢?看圖:
類型、加密演算法的選項,以及 JWT 標准數據欄位,可以參考 RFC 7519 - JSON Web Token (JWT)node 上同樣有相關的庫實現:express-jwt - npm koa-jwt - npm
token,作為許可權守護者,最重要的就是「安全」。業務介面用來鑒權的 token,我們稱之為 access token。越是許可權敏感的業務,我們越希望 access token 有效期足夠短,以避免被盜用。但過短的有效期會造成 access token 經常過期,過期後怎麼辦呢?一種辦法是,讓用戶重新登錄獲取新 token,顯然不夠友好,要知道有的 access token 過期時間可能只有幾分鍾。另外一種辦法是,再來一個 token,一個專門生成 access token 的 token,我們稱為 refresh token。
有了 refresh token 後,幾種情況的請求流程變成這樣:
如果 refresh token 也過期了,就只能重新登錄了。
session 和 token 都是邊界很模糊的概念,就像前面說的,refresh token 也可能以 session 的形式組織維護。狹義上,我們通常認為 session 是「種在 cookie 上、數據存在服務端」的認證方案,token 是「客戶端存哪都行、數據存在 token 里」的認證方案。對 session 和 token 的對比本質上是「客戶端存 cookie / 存別地兒」、「服務端存數據 / 不存數據」的對比。**「客戶端存 cookie / 存別地兒」**存 cookie 固然方便不操心,但問題也很明顯:
存別的地方,可以解決沒有 cookie 的場景;通過參數等方式手動帶,可以避免 CSRF 攻擊。 「服務端存數據 / 不存數據」
前面我們已經知道了,在同域下的客戶端/服務端認證系統中,通過客戶端攜帶憑證,維持一段時間內的登錄狀態。但當我們業務線越來越多,就會有更多業務系統分散到不同域名下,就需要「一次登錄,全線通用」的能力,叫做「單點登錄」。
簡單的,如果業務系統都在同一主域名下,比如wenku..com tieba..com,就好辦了。可以直接把 cookie domain 設置為主域名 .com,網路也就是這么乾的。
比如滴滴這么潮的公司,同時擁有didichuxing.com xiaojukeji.com didiglobal.com等域名,種 cookie 是完全繞不開的。這要能實現「一次登錄,全線通用」,才是真正的單點登錄。這種場景下,我們需要獨立的認證服務,通常被稱為 SSO。 「一次「從 A 系統引發登錄,到 B 系統不用登錄」的完整流程」
**「完整版本:考慮瀏覽器的場景」**上面的過程看起來沒問題,實際上很多 APP 等端上這樣就夠了。但在瀏覽器下不見得好用。看這里:
對瀏覽器來說,SSO 域下返回的數據要怎麼存,才能在訪問 A 的時候帶上?瀏覽器對跨域有嚴格限制,cookie、localStorage 等方式都是有域限制的。這就需要也只能由 A 提供 A 域下存儲憑證的能力。一般我們是這么做的:
圖中我們通過顏色把瀏覽器當前所處的域名標記出來。注意圖中灰底文字說明部分的變化。
謝謝大家哦
❹ 說一下前端數據存儲方式(cookies,localstorage,sessionstorage,indexedDB)的區別
Cookie最初是在客戶端用於存儲會話信息的,其要求伺服器對任意HTTP請求發送Set-CookieHTTP頭作為響應的一部分。cookie
以name為名稱,以value為值,名和值在傳送時都必須是URL編碼的。瀏覽器會存儲這樣的會話信息,在這之後,通過為每個請求添加Cookie
HTTP頭將信息發送回伺服器。
localstorage
存儲方式:
以鍵值對(Key-Value)的方式存儲,永久存儲,永不失效,除非手動刪除。
sessionstorage
HTML5 的本地存儲 API 中的 localStorage 與 sessionStorage 在使用方法上是相同的,區別在於 sessionStorage 在關閉頁面後即被清空,而 localStorage 則會一直保存。
IndexedDB
索引資料庫(IndexedDB) API(作為 HTML5 的一部分)對創建具有豐富本地存儲數據的數據密集型的離線 HTML5 Web 應用程序很有用。同時它還有助於本地緩存數據,使傳統在線 Web 應用程序(比如移動 Web 應用程序)能夠更快地運行和響應。
❺ 誰能簡述三大網路存儲
三大網路存儲:
1、前端存儲
所謂前端存儲,是在網路視頻監控系統的前端設備(如網路視頻編碼器或網路攝像機)中內置存儲部件,由前端設備直接完成監控圖像的本地錄制和保存。
前端存儲具有幾個方面的優勢:一是可以通過分布式的存儲部署,來減輕集中存儲帶來的容量壓力;二是可以有效緩解集中存儲帶來的網路流量壓力;三是可以避免集中存儲在網路發生故障時的圖像丟失。
對於前端存儲,由於單個前端編碼設備通常所帶監控點路數不多,存儲時間也不長,所以對存儲容量要求不高,網路攝像機一般用CF卡或SD卡,視頻伺服器一般用內置硬碟。這與以往單機存儲相比,基本沒有區別。
而與以往單機存儲本質上不同的是,為了保證用戶訪問的靈活性和便捷性,網路視頻監控系統中的所有前端存儲除了要能夠提供點對點的單機訪問外,還要能夠通過一個統一的介面提供所有內容的集中共享。為此,網路視頻監控系統通過中心業務平台對所有前端存儲進行統一管理和調度,並實現存儲空間和存儲內容的網路化。這樣,用戶既可以直接登錄單個前端設備進行錄像資料的點播回放,也可以統一登錄中心業務平台進行所有前端錄像資料的集中檢索和回放。
2、中心存儲
在網路視頻監控系統中,部署得更多的是中心存儲。前端設備採集監控點圖像並編碼壓縮處理成數字監控碼流,然後通過網路傳送到中心業務平台,由中心業務平台將碼流分發給網路錄像單元進行集中存儲。
在很多大型的視頻監控聯網應用中,也可採用多級分布的中心存儲方式,即分中心存儲,這樣一方面可以降低一個中心點集中存儲帶來的存儲容量和網路流量的壓力,一方面可以大幅度提升系統的可靠性。
使用中心/分中心存儲,在以下幾個方面具有明顯優勢:一是對於用戶而言,檢索和調用錄像資源更為方便;二是存儲內容的完整性更容易保證,不會因為某個前端設備失竊或損壞而導致重要內容的丟失;三是可以合理的進行資源調度,為前端設備按需分配存儲空間,從而節約資源;四是有利於制定多樣化的存儲策略,以滿足用戶的個性化需求;五是維護方便,便於集中檢測和及時排查問題。
對於監控點路數比較少、存儲時間要求不長的應用場合,中心/分中心存儲可以採用伺服器插硬碟或外接磁碟櫃這種比較簡單的方式進行部署,稱為DAS(直接訪問存儲),與單機類似。而隨著網路視頻監控的優勢被廣泛認可,現在開始出現越來越多的大型甚至超大型視頻監控系統,比如「平安城市」建設中的社會面治安監控系統、中國電信和中國網通正在全面推進的「全球眼」和「寬視界」這兩大運營級視頻監控系統,這些監控系統都面臨著前端設備的大規模接入和大容量集中存儲的需求。以往的單機存儲方式無法滿足這些系統在容量靈活擴展方面的應用需求,必須採用更為先進的網路存儲設備和存儲技術,其中典型的就是SAN、NAS以及iSCSI。
SAN(存儲區域網)起源於上世紀九十年代中後期,與DAS不同,SAN基於光纖通道技術,伺服器和存儲陣列之間通過光纖通道交換機連接,形成專用於數據存儲的區域網路。SAN採用了面向網路的存儲結構,數據處理和數據存儲分離,具有存儲空間易於擴展、定址靈活、可遠距離傳輸數據、I/O性能高、存儲設備利用率高等特點,是一種全新的存儲體系結構。
與SAN基於專門的光纖通道協議不同,NAS(網路訪問存儲)基於IP網路實現伺服器和存儲陣列的互聯,使用TCP/IP協議進行通信,以文件級的I/O方式進行數據傳輸。相比之下,NAS設備的安裝、調試、使用和管理更簡單,部署成本也相對較低。
iSCSI是IETF一種新的標准協議,即透過IP網路,將SCSI區塊數據轉換成網路封包的一種傳輸標准,它和NAS一樣透過IP網路來傳輸數據,但在數據存取方式上,則採用與NAS不同的,而與SAN相同的Block Protocol協議。由此,iSCSI給用戶帶來的價值在於:第一,iSCSI使SCSI數據包在乙太網中傳輸成為可能,使SAN擺脫了昂貴的光纖網路,通過IP網路即可實現原先的功能,既降低了管理復雜度又降低了成本;第二,由於用戶應用需求的復雜性,往往會同時部署SAN和NAS兩種存儲網路,而iSCSI則可以將兩者融合起來。
iSCSI的這些特點非常契合現在的視頻監控發展的現狀和方向,特別是在運營級視頻監控領域,存儲的規模大、投入高,基於目前成熟的IP網路進行中心/分中心存儲系統的構建,iSCSI技術無疑是一個很好的參考。
3、混合型存儲
對於視頻監控網路比較復雜,對存儲安全性和可靠性要求又非常高的應用場合,可以採用既有集中存儲也有前端存儲的部署方式,兼有二者的優勢,並規避可能存在的風險,是一種比較好的選擇。但會帶來管理的復雜度和高昂的建設成本,需要根據具體情況而定。
❻ web前端常用的資料庫有哪些
1、MySQL
2、Mongodb
3、SQL Server
4、Oracle
❼ cookie前端存儲有哪幾種
1、cookie
HTTP cookie,通常直接叫做cookie,是客戶端用來存儲數據的一種選項,它既可以在客戶端設置也可以在伺服器端設置。cookie會跟隨任意HTTP請求一起發送。
優點:兼容性好
缺點:一是增加了網路流量;二則是它的數據容量有限,最多隻能存儲4KB的數據,瀏覽器之間各有不同;三是不安全。
2、userData
userData是微軟通過一個自定義行為引入的持久化用戶數據的概念。用戶數據允許每個文檔最多128KB數據,每個域名最多1MB數據。
缺點:userData不是 web 標準的一部分,只有IE支持。
3、web存儲機制
web storage,包括兩種:sessionStorage 和 localStorage,前者嚴格用於一個瀏覽器會話中存儲數據,因為數據在瀏覽器關閉後會立即刪除;後者則用於跨會話持久化地存儲數據。
缺點:IE不支持 SessionStorage,低版本IE ( IE6, IE7 ) 不支持 LocalStorage,並且不支持查詢語言
4、indexedDB
indexed Database API,簡稱為indexedDB,是在瀏覽器中保存結構化數據的一種「資料庫」。它類似SQL資料庫的結構化數據存儲機制,代替了廢棄已久的web SQL Database API,它能夠在客戶端存儲大量的結構化數據,並且使用索引高效檢索的API。
缺點:兼容性不好,未得到大部分瀏覽器的支持。
5、Flash cookie
Flash本地存儲,類似於HTTP cookie,它是利用 SharedObject類來實現本地存儲信息。它默認允許每個站點存儲不超過100K的數據,遠大於cookie,而且能夠跨瀏覽器。
缺點:瀏覽器需安裝 Flash 控制項,畢竟它是通過Flash的類來存儲。所幸的是,沒有安裝Flash的用戶極少。
6、Google Gears
Google Gears是Google在07年發布的一個開源瀏覽器插件,Gears 內置了一個基於SQLite的嵌入式 SQL資料庫,並提供了統一API 對 資料庫進行訪問,在取得用戶授權之後,每個站點可以在SQL資料庫中存儲「不限大小」的數據。
缺點:需要安裝 Google Gears 組件
❽ 前端本地存儲有幾種方式
三種:localStorage、sessionStorage、token
❾ 前端存儲方式有哪些
1.本地存儲localstorage
localStorage 方法存儲的數據沒有時間限制。第二天、第二周或下一年之後,數據依然可用。
存儲方式:
以鍵值對(Key-Value)的方式存儲,永久存儲,永不失效,除非手動刪除。
2.本地存儲sessionstorage
HTML5 的本地存儲 API 中的 localStorage 與 sessionStorage 在使用方法上是相同的,區別在於 sessionStorage 在關閉頁面後即被清空,而 localStorage 則會一直保存。
3.離線緩存(application cache)
❿ 前端 自定義網址功能 localStorage 本地存儲
是的,localStorage是本地存儲。
本地存儲可以在瀏覽器本地存儲一些需要長期存儲的數據,除非做清除操作,否則會長期存儲在本地供本域名下的程序使用。相對於以前的cookie來說,存儲容量更大,而且請求伺服器的時候不會隨請求頭一起傳輸。
另外,html5還新增了sessionStorage,即會話存儲,在瀏覽器不關閉的情況下和localStorage有相似之處,但僅作用於本次會話。