關于 Web 漏洞原理與利用：3. CSRF（跨站請求偽造）

一、原理：

利用用戶登錄態偽造操作

CSRF（Cross-Site Request Forgery，跨站請求偽造）是攻擊者“借刀殺人”，借用用戶瀏覽器中已有的登錄狀態，誘導用戶完成攻擊者指定的操作。

1.?基本機制分解

1）瀏覽器的默認行為：自動帶上 Cookie（包括 sessionid）

當你訪問一個網站并登錄后，例如：

POST /login
Host: bank.com
Cookie: sessionid=abc123

  • 網站會通過 Cookie（如 sessionid）記錄你的登錄狀態。

  • 登錄后，每次你再訪問這個網站，瀏覽器都會自動帶上 Cookie：

GET /user/profile
Cookie: sessionid=abc123

這是 瀏覽器的默認行為，不管你怎么發請求，只要是訪問 bank.com，就自動帶上它的 Cookie。

2）網站服務器的判斷邏輯

網站一般只根據 Cookie 判斷用戶身份：

if request.cookie["sessionid"] is valid:allow_operation()

所以請求 只要帶了合法的 Cookie，網站就以為是“你自己操作的”。

3）攻擊者不能獲取 Cookie，但能讓瀏覽器代發請求

攻擊者 無法直接讀取你的 Cookie，但卻可以通過誘導你訪問惡意頁面，讓瀏覽器替他發出請求。
瀏覽器會在請求中 自動附帶 Cookie，即使這是攻擊者構造的請求！

攻擊者只需要這樣：

<img src="https://bank.com/transfer?to=attacker&amount=10000">

當你一打開這個網頁：

  • 瀏覽器會訪問 bank.com；

  • 自動附帶你的 Cookie（如 sessionid）；

  • 請求落到銀行服務器上；

  • 銀行服務器識別 Cookie 合法，就執行了“轉賬”。

結果是：你替攻擊者完成了操作，自己還一無所知。

2.?類比解釋：偽造你發指令

想象這個場景：

  • 你在一個公司門禁系統中，登錄了一個可以發指令的管理后臺；

  • 攻擊者不能進公司，但可以給你發一個“點擊這個鏈接”的誘導郵件；

  • 你一不小心點開，就自動觸發了一個“給他打錢”的命令；

  • 門禁系統看到是你發的，指令合法，就執行了。

攻擊者沒權限，但他“騙你”用你的權限幫他做了事。

3.?條件總結（CSRF 成功的關鍵前提）

  1. ?用戶已登錄目標網站，且登錄狀態仍有效（Cookie 存在）；

  2. ?目標網站通過 Cookie 識別身份（常見）；

  3. ?請求沒有額外校驗（如 CSRF token）；

  4. ?攻擊者誘導用戶訪問了惡意鏈接或頁面；

  5. ?瀏覽器自動發送 Cookie，服務器誤以為是用戶行為。

4.?攻擊流程圖（邏輯順序）

[用戶登錄 bank.com] → [獲得 sessionid Cookie]↓
[訪問惡意網站] → [構造對 bank.com 的請求]↓
[瀏覽器自動帶上 sessionid]↓
[bank.com 收到請求] → [識別為用戶操作] → 執行了操作

5.?攻擊者和用戶的角色區別

項目用戶攻擊者
擁有 Cookie?是?否
能發請求?是?能騙用戶發
能偽造內容?無法偽造 Cookie，但能偽造請求內容
能操作目標站（自己操作）（借助用戶操作）

總結

CSRF 利用的不是系統漏洞，而是 Web 的信任機制 + 用戶不知情行為 + 瀏覽器的自動 Cookie 行為。

二、構造：

自動提交表單

攻擊者構造一個偽造的表單，提前填好表單字段，讓用戶在訪問時自動提交，借此觸發目標網站上的敏感操作（如轉賬、修改密碼等）。

1.?構造基本結構

<form action="https://bank.com/transfer" method="POST"><input type="hidden" name="to" value="attacker123"><input type="hidden" name="amount" value="10000">
</form><script>document.forms[0].submit(); // 頁面加載后自動提交表單
</script>

2.?構造流程詳解

1）<form> 標簽構建 POST 請求

<form action="https://bank.com/transfer" method="POST">

  • action 是目標地址；

  • method="POST" 表示發起 POST 請求；

  • 請求將帶上表單中的參數。

2）使用隱藏字段構造參數

<input type="hidden" name="to" value="attacker123">
<input type="hidden" name="amount" value="10000">

  • 這些字段用戶看不到；

  • 但它們會作為 POST 的參數發送出去；

  • 模擬的是用戶提交表單的過程。

3）使用 JavaScript 自動提交表單

document.forms[0].submit();

  • 頁面加載時立即提交；

  • 用戶根本無感知。

3.?構造后發出的請求（抓包效果）

POST /transfer HTTP/1.1
Host: bank.com
Content-Type: application/x-www-form-urlencoded
Cookie: sessionid=abcdef123456to=attacker123&amount=10000

瀏覽器自動帶上用戶登錄狀態中的 Cookie（如 sessionid），服務器誤以為是用戶自己發出的請求。

4.?實戰演示用法（真實攻擊邏輯）

假設：

目標網站 bank.com 有如下邏輯：

  • POST /transfer 可以轉賬；

  • 需要參數 to 和 amount；

  • 只要 Cookie 中的 session 合法就執行操作；

  • 沒有 CSRF Token 或 Referer 校驗。

攻擊頁面代碼：

<!DOCTYPE html>
<html lang="zh-CN">
<head><meta charset="UTF-8"><title>你中獎了</title>
</head>
<body><h1>恭喜你中獎了！正在處理領獎信息...</h1><form id="csrfForm" action="http://localhost:8000/transfer" method="POST"><input type="hidden" name="to" value="attacker_account"><input type="hidden" name="amount" value="10000"></form><script>window.onload = function() {document.getElementById('csrfForm').submit();}</script>
</body>
</html>

攻擊流程：

  • 用戶在登錄了 bank.com 后，未退出；

  • 用戶訪問了攻擊者構造的釣魚網頁；

  • 瀏覽器在加載頁面時，自動提交表單；

  • bank.com 收到合法 Cookie + 合法參數；

  • 成功執行“給攻擊者轉賬”操作。

5.?關鍵點

特性描述
請求類型POST
參數構造方式隱藏字段 <input type="hidden">
自動觸發方式JS：form.submit()
瀏覽器行為自動攜帶 Cookie
用戶感知程度無感知，訪問頁面即中招

6.?限制與防御

這種方式雖然常見，但也容易被防御：

防御方式是否能阻止這種攻擊
CSRF Token 校驗?可以阻止
Referer 校驗?可以阻止
SameSite Cookie 限制?可以阻止
登出機制不當?無法阻止
用戶粗心點開鏈接?攻擊成功

總結

自動提交表單是構造 CSRF 的最主流手段，它依賴瀏覽器自動攜帶 Cookie + 用戶無感知行為，在攻擊頁面中用隱藏字段 + JS 一鍵觸發操作。

=======================================

img/src 請求

<img> 標簽中的 src 屬性，只要被瀏覽器解析，就會自動發出 GET 請求。

攻擊者可利用這一點，構造一段帶有 img 標簽的 HTML 頁面，誘導用戶訪問，讓用戶在不知情的情況下向目標網站發起請求。

最關鍵的是：瀏覽器在發出這個 GET 請求時，會自動攜帶當前域名下的 Cookie（如 sessionid、token 等登錄態信息）。

如果目標網站沒有做好 CSRF 防御，攻擊就可能成功。

1.?構造示例

<!-- 攻擊者網頁上的 HTML 代碼 -->
<img src="https://bank.com/transfer?to=attacker&amount=10000">

2.?瀏覽器行為分析

  • 用戶訪問攻擊者構造的網頁；

  • <img> 標簽被瀏覽器解析；

  • 瀏覽器自動向 https://bank.com/transfer?... 發起 GET 請求；

  • 自動帶上當前用戶的 Cookie（如 sessionid=abcdef123456）；

  • 如果目標接口沒有驗證 Referer、Token，服務器會誤以為是合法操作；

  • 攻擊成功。

發出的請求大致

GET /transfer?to=attacker&amount=10000 HTTP/1.1
Host: bank.com
Cookie: sessionid=abcdef123456
User-Agent: Mozilla/5.0 ...

3.?攻擊條件

要讓攻擊成功，必須滿足以下條件：

條件說明
用戶已登錄目標網站否則沒有有效 Cookie，無法偽造操作
Cookie 中記錄了身份憑證如 sessionid 或 JWT
目標接口使用 GET 實現敏感操作如轉賬、綁定郵箱、刪除內容等（極其不安全）
沒有 CSRF Token 或 Referer 檢查否則請求會被攔截

4.?其它類似的標簽（也能觸發 GET）

攻擊者可以不止使用 <img>，還可以使用以下方式：

標簽示例代碼
<img><img src="...">
<script><script src="...">
<iframe><iframe src="...">
<link><link rel="stylesheet" href="...">
<object><object data="...">

5.?img/src 的限制

限制點說明
只能發 GET 請求無法發 POST 請求
無法自定義請求頭不能設置 Referer、User-Agent 等
無法處理響應JavaScript 無法獲取返回內容
一旦目標接口有驗證就失敗CSRF Token、SameSite Cookie、Referer 限制

6.?使用場景

雖然 POST 請求一般更危險，但一些老舊或不規范的網站，可能把敏感操作寫成 GET 請求，比如：

  • GET /deleteAccount?id=123

  • GET /addFriend?user=evil

  • GET /transfer?to=attacker&amount=5000

這類系統就特別容易被 <img> 標簽攻擊。

7.?攻擊場景舉例

1）刪除某用戶帖子：

<img src="https://forum.com/deletePost?id=999">

用戶點擊釣魚鏈接或訪問攻擊頁面后，該帖子被刪除。

2）給攻擊者點贊/加好友：

<img src="https://social.com/addFriend?uid=attacker">

用戶以為自己在看圖片，其實是在無意間幫攻擊者加了好友。

8. 安全建議（從服務端角度）

防御措施有效性
禁止用 GET 做敏感操作?非常重要
使用 CSRF Token?推薦
檢查 Referer / Origin?可選
設置 SameSite Cookie?可阻止跨站請求
用戶操作需二次確認?提高安全性

總結

img/src 是最“隱蔽”的 CSRF 構造方式之一，用戶根本意識不到任何操作，但背后其實可能在給別人轉賬、點贊、刪除內容，屬于“無交互感知攻擊”，而瀏覽器的默認行為（自動發 GET、自動帶 Cookie）正是它得逞的根源。

三、? 防御：

Token 驗證

**CSRF Token（跨站請求偽造令牌）**是一段由服務器生成、隨機、不可預測的字符串，用來綁定用戶請求和用戶身份之間的唯一性，防止惡意網站偽造用戶的請求。

它不保存在 Cookie 中，而是嵌入在 HTML 頁面中，并隨著每個請求一起發送回來。

為什么需要 Token？

因為 Cookie 是自動發送的，攻擊者可以構造偽造請求利用用戶的登錄態。而 Token 是攻擊者無法提前獲取、又必須提交的驗證參數。

所以只要驗證這個 Token，服務器就能判斷請求是不是由真實用戶頁面發起的。

1.?工作原理詳解

1）用戶訪問頁面

  • 服務器生成一個隨機 Token：

    session['csrf_token'] = 'Xyz123Abc...'

  • 把這個 Token 插入到 HTML 頁面里（常見方式是 form 隱藏字段）：

    <input type="hidden" name="csrf_token" value="Xyz123Abc..." />

2）用戶提交表單時

瀏覽器會將該隱藏字段和其他字段一起發送：

POST /transfer HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Cookie: sessionid=abc123to=tom&amount=1000&csrf_token=Xyz123Abc...

3）后端校驗

后端取出提交的 Token 和保存在會話（session）中的 Token 進行比對：

if request.form['csrf_token'] != session['csrf_token']:return 'CSRF ATTACK DETECTED'

一致：允許操作
不一致/缺失：攔截攻擊

2.?為什么能防御 CSRF？

因為：

  • 攻擊者不能獲取用戶的 Token（它是嵌入 HTML 的，不能跨域讀取）；

  • 攻擊者無法猜出 Token 內容（足夠隨機）；

  • 即使攻擊者構造了相同參數請求，缺了 Token 也無法通過驗證。

3.?示例（完整 Flask 演示）

from flask import Flask, request, session, render_template_string, redirect
import secretsapp = Flask(__name__)
app.secret_key = 'your-secret-key'@app.route('/')
def form():# 生成隨機 CSRF Tokentoken = secrets.token_hex(16)session['csrf_token'] = tokenreturn render_template_string('''<form action="/submit" method="post"><input type="text" name="to" placeholder="轉賬對象"><input type="text" name="amount" placeholder="金額"><input type="hidden" name="csrf_token" value="{{token}}"><input type="submit" value="提交"></form>''', token=token)@app.route('/submit', methods=['POST'])
def submit():if session.get('csrf_token') != request.form.get('csrf_token'):return "CSRF ATTACK BLOCKED"return f"已向 {request.form['to']} 轉賬 {request.form['amount']} 元"if __name__ == '__main__':app.run(debug=True)

4.?建議

方法描述
每個表單獨立 Token提高安全性（避免 Token 重用）
Token 過期時間防止長期有效的令牌被利用
雙 Token 機制Cookie + 表單同時攜帶，提升安全性
Ajax 請求放在自定義 Header 中，防止被 HTML form 模擬提交

注意：GET 請求無法用 Token 防御！

因為 <img>、<a>、<script> 標簽都可以發 GET 請求，但無法攜帶 Token，所以：

  • 敏感操作必須使用 POST/PUT/DELETE 請求

  • 且要配合 Token 驗證

總結

特性描述
?核心機制最強大的 CSRF 防御方式
?獨立于瀏覽器行為不依賴 Cookie 屬性
?不影響用戶體驗用戶無感知
?實現略復雜需要頁面與服務端同步 Token

=======================================

Referer 檢查

Referer（原意是 Referrer，拼寫錯了但沿用了）是 HTTP 請求頭的一部分，它記錄了：

這個請求是從哪個頁面跳轉過來的。

例如，在網頁中點擊了一個鏈接或提交了一個表單，請求頭就會帶上：

Referer: https://www.bank.com/account

這個字段就告訴服務器：用戶當前的請求是從 https://www.bank.com/account 頁面發出來的。

1.?Referer 檢查的原理

核心邏輯：只允許來自本站頁面發起的請求。

如果服務端發現請求的 Referer 不是自己的域名，則判定請求不是合法來源，有可能是 CSRF 攻擊。

2.?Referer 檢查怎么實現？

以 Python Flask 為例：

from flask import request@app.route('/transfer', methods=['POST'])
def transfer():referer = request.headers.get('Referer')if referer is None or not referer.startswith("https://www.bank.com"):return "非法請求，可能是 CSRF 攻擊", 403# 執行轉賬操作return "轉賬成功"

3.?攻擊與防御場景對比

攻擊請求（來自攻擊者網站）：

攻擊者構造一個頁面，誘導你點擊按鈕：

<form action="https://www.bank.com/transfer" method="POST"><input type="hidden" name="amount" value="10000"><input type="hidden" name="to" value="attacker">
</form>
<script>document.forms[0].submit()</script>

點擊后瀏覽器發出 POST 請求：

POST /transfer HTTP/1.1
Host: www.bank.com
Referer: https://evil.com/attack.html
Cookie: session=123456

Referer 檢查發現不是本域名，攔截。

正常請求（正常用戶操作）：

用戶在 https://www.bank.com/account 頁面點擊“轉賬”，發起請求：

Referer: https://www.bank.com/account

服務器一看，是本站頁面發來的，請求放行。

4.?Referer 檢查的優缺點

優點：

優點描述
簡單不需要在頁面嵌入 Token，服務器代碼也很簡單
快速生效服務端只需增加 Referer 檢查邏輯即可
對用戶透明不影響用戶體驗，不需要頁面修改

缺點：

缺點描述
Referer 可能為空某些瀏覽器或隱私插件會去掉 Referer，導致誤判
有些合法請求可能是跨域比如 OAuth 登錄回調、第三方支付跳轉，Referer 不是本站但合法
攻擊者不能偽造 Referer，但可以構造沒有 Referer 的請求比如通過 <img>、<iframe> 發起請求，瀏覽器可能不帶 Referer
不適用于 API 接口移動端請求或者 AJAX 跨域接口可能沒有 Referer，造成誤判或不適用

5.?實際使用建議

Referer 檢查作為 輔助防御機制 是很有價值的，但不能作為唯一防線，因為：

  • 它容易被繞過（Referer 空值、瀏覽器兼容性等）；

  • 有時候會攔正常請求；

  • 安全級別不如 CSRF Token 或 SameSite Cookie。

6.?最佳實踐

場景建議
Web 表單提交推薦使用 CSRF Token + Referer 檢查雙重防御
AJAX 請求建議加 CSRF Token 頭部或參數驗證
開放接口（如 API）不建議使用 Referer，推薦使用 OAuth / 簽名機制等

總結

Referer 檢查是一種基于請求來源的 CSRF 防御手段，通過驗證請求的 Referer 是否來自本站，攔截非本站發起的請求。雖然簡單有效，但存在兼容性和安全邊界問題，建議作為 CSRF Token 的補充手段。

=======================================

SameSite Cookie

SameSite 是 Cookie 的一個屬性，用來控制瀏覽器在“跨站請求”時是否發送這個 Cookie。

它是由瀏覽器實現的安全策略，不依賴后端邏輯。主要用來防御跨站攻擊（特別是 CSRF）。

跨站請求是什么意思？

舉例說明：

  • 你在瀏覽 https://evil.com，這上面有一個表單偷偷向 https://bank.com/transfer 發 POST 請求。

  • 瀏覽器默認會攜帶你在 bank.com 登錄時留下的 Cookie（含 session id）！

  • bank.com 后臺認為你是登錄用戶，直接處理請求了！這就是 CSRF！

SameSite 屬性有哪幾種值？

SameSite 值描述是否允許跨站請求帶 Cookie
Strict最嚴格，完全禁止?不允許任何跨站請求帶 Cookie
Lax默認，兼容性好?允許 GET 請求帶 Cookie，禁止 POST
None不限制?始終允許，但必須配合 Secure（即 HTTPS）

1.?各模式詳細解讀

1）SameSite=Strict

只允許 同站請求（用戶主動點擊本站鏈接、表單提交等），否則瀏覽器不會附帶 Cookie。

可防御所有類型的 CSRF！

缺點：

  • 用戶從其他站點點擊鏈接訪問本站后，可能需要重新登錄。

2）SameSite=Lax

略微放寬，允許以下情況攜帶 Cookie：

  • 鏈接跳轉（GET）

  • 資源加載（img、iframe）

  • 表單或腳本的 POST?不攜帶 Cookie（可防御 CSRF）

優點：

  • 大多數網站默認使用這個值，兼容性好；

  • 可防御大多數 CSRF（POST 被阻止）。

3）SameSite=None

這是唯一允許完全跨站請求帶 Cookie的選項。

但有個前提：必須同時設置 Secure 屬性，且使用 HTTPS，否則瀏覽器會拒絕設置 Cookie！

如果不加 Secure，Chrome 直接不保存這個 Cookie！

2.?設置示例（Flask）

@app.route("/set_cookie")
def set_cookie():resp = make_response("設置成功")# SameSite 可以設置為 'Strict' / 'Lax' / 'None'resp.set_cookie("session_id", "123456", samesite="Lax", secure=False)return resp

如果設置 SameSite=None，必須加 secure=True，并啟用 HTTPS。

3. SameSite 的 CSRF 防御原理

瀏覽器發起跨站請求（如：在惡意網站中自動提交表單）：

  • 如果 SameSite=Strict 或 Lax，瀏覽器不會附帶 session_id

  • 后端檢測不到登錄態，CSRF 請求失效?

4.?實際建議

場景SameSite 推薦值
普通用戶站點（需防 CSRF）Lax（推薦）
管理后臺系統（高安全性）Strict
第三方服務需帶 CookieNone + Secure + HTTPS

5. 檢查?Cookie 設置

打開瀏覽器控制臺（F12 → Application → Cookies），可以看到：

  • Name：session_id

  • Value：xxxx

  • SameSite：Strict / Lax / None

  • Secure：是否開啟

總結

SameSite 是瀏覽器級別的防御機制，用來讓“跨站請求時 Cookie 不再自動發送”，從根源上限制 CSRF 攻擊。

本文來自互聯網用戶投稿，該文觀點僅代表作者本人，不代表本站立場。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。
如若轉載，請注明出處：http://www.pswp.cn/pingmian/81722.shtml
繁體地址，請注明出處：http://hk.pswp.cn/pingmian/81722.shtml
英文地址，請注明出處：http://en.pswp.cn/pingmian/81722.shtml

如若內容造成侵權/違法違規/事實不符，請聯系多彩編程網進行投訴反饋email:809451989@qq.com，一經查實，立即刪除！

相關文章

【HTML5】【AJAX的幾種封裝方法詳解】

【HTML5】【AJAX的幾種封裝方法詳解】

【HTML5】【AJAX的幾種封裝方法詳解】 AJAX (Asynchronous JavaScript and XML) 封裝是為了簡化重復的異步請求代碼&#xff0c;提高開發效率和代碼復用性。下面我將介紹幾種常見的 AJAX 封裝方式。 方法1. 基于原生 XMLHttpRequest 的封裝 XMLHttpRequest。其主要特點如下…
閱讀更多...
C++ - 網絡編程之初始連接（Winsock2 概述、初始連接案例、初始連接案例解讀）

C++ - 網絡編程之初始連接（Winsock2 概述、初始連接案例、初始連接案例解讀）

一、Winsock2 概述 Winsock2&#xff08;Windows Sockets 2&#xff09;是微軟提供的 Windows 平臺網絡編程庫 二、初始連接案例 1、Server #include <winsock2.h> #include <ws2tcpip.h> #include <iostream>#pragma comment(lib, "ws2_32.lib&quo…
閱讀更多...
Spring Cloud Gateway深度解析：原理、架構與生產實踐

Spring Cloud Gateway深度解析：原理、架構與生產實踐

文章目錄 前言一、概述二、核心架構設計及設計原理2.1 分層架構模型網絡層&#xff08;I/O模型&#xff09;核心處理層 2.2 核心組件協作流程路由定位階段過濾器執行階段 2.3 響應式編程模型實現Reactor上下文傳遞背壓處理機制 2.4 動態路由設計原理2.5 異常處理體系2.6 關鍵路…
閱讀更多...
游戲開發實戰（一）：Python復刻「崩壞星穹鐵道」嗷嗚嗷嗚事務所---源碼級解析該小游戲背后的算法與設計模式【純原創】

游戲開發實戰（一）：Python復刻「崩壞星穹鐵道」嗷嗚嗷嗚事務所---源碼級解析該小游戲背后的算法與設計模式【純原創】

文章目錄 奇美拉項目游戲規則奇美拉(Chimeras)檔案領隊成員 結果展示&#xff1a; 奇美拉項目 由于項目工程較大&#xff0c;并且我打算把我的思考過程和實現過程中踩過的坑都分享一下&#xff0c;因此會分3-4篇博文詳細講解本項目。本文首先介紹下游戲規則并給出奇美拉檔案。…
閱讀更多...
說一下響應狀態碼有哪些？

說一下響應狀態碼有哪些？

HTTP響應狀態碼分類（RFC 7231標準） 1. 1xx（信息類） 臨時響應，表示請求已被接收，需要繼續處理 100 Continue：客戶端應繼續發送請求體 101 Switching Protocols：服務器同意升級協議（如WebSocket） 102 Processing（WebDAV）：服務器正在處理但未完成 2. 2xx（成功類）…
閱讀更多...
Linux多進程 寫時拷貝 物理地址和邏輯地址

Linux多進程 寫時拷貝 物理地址和邏輯地址

如果不采用寫時拷貝技術 直接fork子進程 會發生什么&#xff1f; 如上圖所示 橙色為父進程所占內存空間 綠色為子進程所占內存空間。 如果子進程只是需要做出一點點和父進程不一樣的 其余和父進程均為相同 第一 就會出現復制開銷比較大&#xff1b;第二占用內存空間 所以 …
閱讀更多...
【TTS回顧】Bert-VITS2深度解析：融合BERT的多語言語音合成模型

【TTS回顧】Bert-VITS2深度解析：融合BERT的多語言語音合成模型

一、基本介紹 Bert-VITS2是基于VITS（Variational Inference with adversarial learning for end-to-end Text-to-Speech）的改進版本，通過整合BERT語義編碼能力，顯著提升了語音合成的自然度和表現力。項目地址：https://github.com/fishaudio/Bert-VITS2 語種自然度相似度流…
閱讀更多...
win11下docker 的使用方案

win11下docker 的使用方案

Windows 11 Docker 使用方式對比 特性Docker Desktop (使用 WSL 2 后端)直接在 WSL 2 中安裝 Docker Engine安裝與易用性極簡&#xff0c;一鍵安裝&#xff0c;提供直觀的 GUI 界面 管理容器、鏡像、卷等相對復雜&#xff0c;需手動在 Linux 環境中安裝 Docker Daemon 并配置G…
閱讀更多...
配合本專欄前端文章對應的后端文章——從模擬到展示：一步步搭建傳感器數據交互系統

配合本專欄前端文章對應的后端文章——從模擬到展示：一步步搭建傳感器數據交互系統

對應文章&#xff1a;進一步完善前端框架搭建及vue-konva依賴的使用&#xff08;Vscode&#xff09;-CSDN博客 目錄 一、后端開發 1.模擬傳感器數據 2.前端頁面呈現數據后端互通 2.1更新模擬傳感器數據程序&#xff08;多次請求&#xff09; 2.2&#x1f9e9; 功能目標 …
閱讀更多...
牛客網NC209794:使徒襲來

牛客網NC209794:使徒襲來

牛客網NC209794:使徒襲來 題目背景 問題分析 數學建模 設三位駕駛員的戰斗力分別為 a, b, c已知條件&#xff1a;a b c n (n為輸入的正整數)目標&#xff1a;求 a b c 的最小值 解題思路 根據算術-幾何平均值不等式(AM-GM不等式)&#xff0c;對于任意正實數a, b, c&a…
閱讀更多...
動態規劃之爬樓梯模型

動態規劃之爬樓梯模型

文章目錄 爬樓梯模型LeetCode 746. 使用最小花費爬樓梯思路Golang 代碼 LeetCode 377. 組合總和 Ⅳ思路Golang 代碼 LeetCode 2466. 統計構造好字符串的方案數思路Golang 代碼 LeetCode 2266. 統計打字方案數思路Golang 代碼 爬樓梯模型 爬樓梯模型是動態規劃當中的一個經典模型…
閱讀更多...
【每天一個知識點】湖倉一體（Data Lakehouse）

【每天一個知識點】湖倉一體（Data Lakehouse）

“湖倉一體”&#xff08;Data Lakehouse&#xff09;是一種融合了數據湖&#xff08;Data Lake&#xff09;與數據倉庫&#xff08;Data Warehouse&#xff09;優勢的新型數據架構。它既繼承了數據湖對多類型數據的靈活存儲能力&#xff0c;也具備數據倉庫對結構化數據的高效查…
閱讀更多...
Linux | mdadm 創建軟 RAID

Linux | mdadm 創建軟 RAID

注&#xff1a;本文為 “Linux mdadm RAID” 相關文章合輯。 略作重排&#xff0c;未整理去重。 如有內容異常&#xff0c;請看原文。 Linux 下用 mdadm 創建軟 RAID 以及避坑 喵??&#xfecc;?? Oct 31, 2023 前言 linux 下組軟 raid 用 mdadm 命令&#xff0c;multi…
閱讀更多...
Unity自定義shader打包SpriteAtlas圖集問題

Unity自定義shader打包SpriteAtlas圖集問題

Unity打包圖集還是有一些坑的&#xff0c;至于圖集SpriteAtlas是什么請參考我之前寫的文章&#xff1a;【Sprite Atlas】Unity新圖集系統SpriteAtlas超詳細使用教程_spriteatlas 使用-CSDN博客 問題&#xff1a; 今天碰到的問題是&#xff0c;shader繪制的時候&#xff0c;因…
閱讀更多...
如何用 OceanBase 的 LOAD DATA 旁路導入進行大表遷移

如何用 OceanBase 的 LOAD DATA 旁路導入進行大表遷移

前言 在日常工作中&#xff0c;我們時常會遇到需要將某個大數據量的單表進行遷移的情況。在MySQL中&#xff0c;針對這樣的大表&#xff0c;我們通常會選擇先將原表導出為csv格式&#xff0c;然后利用LOAD DATA語法來導入csv文件&#xff0c;這種方法相較于mysqldump在效率上有…
閱讀更多...
VR 互動實訓的顯著優勢?

VR 互動實訓的顯著優勢?

&#xff08;一&#xff09;沉浸式學習&#xff0c;提升培訓效果? 在 VR 互動實訓中&#xff0c;員工不再是被動的知識接受者&#xff0c;而是主動的參與者。以銷售培訓為例&#xff0c;員工戴上 VR 設備&#xff0c;就能置身于逼真的銷售場景中&#xff0c;與虛擬客戶進行面對…
閱讀更多...
OpenCV 第6課 圖像處理之幾何變換（重映射）

OpenCV 第6課 圖像處理之幾何變換（重映射）

1. 概述 簡單來說，重映射就是把一副圖像內的像素點按照規則映射到到另外一幅圖像內的對應位置上去，形成一張新的圖像。 因為原圖像與目標圖像的像素坐標不是一一對應的。一般情況下，我們通過重映射來表達每個像素的位置（x,y），像這樣： g(x,y)=f(h(x,y)) 在這里g()是目標圖…
閱讀更多...
Java虛擬機 - 程序計數器和虛擬機棧

Java虛擬機 - 程序計數器和虛擬機棧

運行時數據結構 Java運行時數據區程序計數器為什么需要程序計數器執行流程虛擬機棧虛擬機棧作用虛擬機棧核心結構運行機制 Java運行時數據區 首先介紹Java運行時數據之前&#xff0c;我們要了解&#xff0c;對于計算機來說&#xff0c;內存是非常重要的資源&#xff0c;因為內…
閱讀更多...
MySQL數據庫——支持遠程IP訪問的設置方法總結

MySQL數據庫——支持遠程IP訪問的設置方法總結

【系列專欄】&#xff1a;博主結合工作實踐輸出的&#xff0c;解決實際問題的專欄&#xff0c;朋友們看過來&#xff01; 《項目案例分享》 《極客DIY開源分享》 《嵌入式通用開發實戰》 《C語言開發基礎總結》 《從0到1學習嵌入式Linux開發》 《QT開發實戰》 《Android開發實…
閱讀更多...
CSS- 4.6 radiu、shadow、animation動畫

CSS- 4.6 radiu、shadow、animation動畫

本系列可作為前端學習系列的筆記&#xff0c;代碼的運行環境是在HBuilder中&#xff0c;小編會將代碼復制下來&#xff0c;大家復制下來就可以練習了&#xff0c;方便大家學習。 HTML系列文章 已經收錄在前端專欄&#xff0c;有需要的寶寶們可以點擊前端專欄查看&#xff01; 點…
閱讀更多...
最新文章

Copyright @ 2022~2023