2025年01月03日美蜥（杭州普瑞兼職）二面

目錄

  1. 為何 nginx 可以實現跨域請求，原理是什么
  2. 為何 nodejs 可以實現跨域請求，原理是什么
  3. 瀏覽器的請求頭有哪些
  4. 瀏覽器的響應頭有哪些
  5. 瀏覽器輸入網址后發生什么
  6. http 協議和 https 有什么區別
  7. 你的核心優勢是什么
  8. 瀏覽器緩存機制
  9. https 的加密機制
  10. tcp 的三次握手和四次揮手
  11. get 和 post 有什么區別
  12. 講一下 xss 攻擊
  13. 講一下瀏覽器同源策略問題
  14. 講一下進程線程的區別

1. 為何 nginx 可以實現跨域請求，原理是什么

以下是關于 Nginx 可以實現跨域請求的原理和解釋：

1. 跨域請求的基本概念
  • 跨域請求是指瀏覽器在執行 JavaScript 時，由于同源策略（Same-Origin Policy）的限制，當請求的源（協議、域名、端口）不同時，瀏覽器會阻止請求。例如，從 http://localhost:8080 向 http://api.example.com 發送請求，如果沒有特殊處理，會被視為跨域請求。
2. Nginx 實現跨域請求的原理
  • 添加響應頭：
    • Nginx 可以通過添加相應的 HTTP 響應頭來允許跨域請求。
    • 常用的跨域響應頭包括：
      • Access-Control-Allow-Origin：指定允許的源，可以是具體的域名，也可以是 *（表示允許任何源）。
      • Access-Control-Allow-Methods：允許的 HTTP 方法，如 GET, POST, PUT, DELETE 等。
      • Access-Control-Allow-Headers：允許的請求頭。
      • Access-Control-Allow-Credentials：是否允許攜帶憑證，如 cookie 等。
3. 示例配置

以下是一個簡單的 Nginx 配置示例，展示如何添加跨域響應頭：

server {listen 80;server_name api.example.com;location /api/ {add_header Access-Control-Allow-Origin *;add_header Access-Control-Allow-Methods 'GET, POST, PUT, DELETE, OPTIONS';add_header Access-Control-Allow-Headers 'Content-Type, Authorization';if ($request_method = 'OPTIONS') {return 204;}...proxy_pass http://backend;}
}
  • 在這個配置中：
    • add_header 指令添加了跨域所需的響應頭。
    • 對于 OPTIONS 請求（預檢請求），使用 if ($request_method = 'OPTIONS') 進行處理，通常返回 204 狀態碼，因為預檢請求只是瀏覽器在發送實際請求前的檢查，不需要返回實際數據。
4. 代理服務器的角色
  • 代理機制：
    • Nginx 可以作為代理服務器，將客戶端的請求轉發到實際的后端服務器，然后將后端服務器的響應轉發給客戶端。
    • 當作為代理服務器時，客戶端請求的是 Nginx 服務器，而不是直接請求后端服務器，Nginx 服務器和客戶端是同源的，因此不存在跨域問題。
    • 例如：
server {listen 80;server_name frontend.example.com;location /api/ {proxy_pass http://backend.example.com;}
}
  • 這里，前端應用在 frontend.example.com 向 /api/ 發送請求時，請求會先到 Nginx 服務器，Nginx 會將請求轉發到 backend.example.com，對于前端應用來說，它只與 frontend.example.com 的 Nginx 服務器通信，避免了跨域問題。
5. 解釋與應用場景

  • 解釋：

    • 當瀏覽器發起跨域請求時，Nginx 可以通過添加跨域響應頭告訴瀏覽器允許跨域，或者作為代理服務器繞過同源策略的限制。
    • 對于簡單請求（如 GET 和 POST 請求，且請求頭只包含簡單的頭信息），添加 Access-Control-Allow-Origin 等響應頭通常可以解決跨域問題。
    • 對于復雜請求（如 PUT、DELETE 或包含自定義請求頭），瀏覽器會先發送 OPTIONS 預檢請求，Nginx 可以處理這些預檢請求并添加相應的響應頭，確保后續請求可以正常進行。

  • 應用場景：

    • 在前后端分離的架構中，前端和后端部署在不同的域名下，Nginx 可以作為中間的代理服務器，實現跨域請求的處理。
    • 在微服務架構中，不同服務可能部署在不同的域名或端口，Nginx 可以用來協調不同服務之間的請求，解決跨域問題。
面試回答示例

“Nginx 可以實現跨域請求主要有兩種方式。首先，它可以通過添加相應的 HTTP 響應頭來允許跨域請求，如添加 Access-Control-Allow-Origin、Access-Control-Allow-Methods 等響應頭，通過這些響應頭告訴瀏覽器允許哪些源、哪些方法和哪些請求頭的跨域請求。對于預檢請求（如 OPTIONS 請求），可以根據需要進行處理，通常返回 204 狀態碼。其次，Nginx 可以作為代理服務器，將客戶端的請求轉發到后端服務器，這樣客戶端與 Nginx 服務器同源，避免了跨域問題。在實際應用中，這在前后端分離架構和微服務架構中非常有用，它可以解決前端和后端不同源時的跨域問題，確保請求可以正常進行。”

通過這樣的回答，可以向面試官展示你對 Nginx 實現跨域請求的原理的理解，包括添加響應頭和作為代理服務器的機制，以及在不同架構中的應用場景，體現你對 Nginx 服務器和跨域問題的深入認識。

2. 為何 nodejs 可以實現跨域請求，原理是什么

以下是 Node.js 可以進行跨域處理的原理和原因：

1. 跨域的基本概念
  • 跨域是由于瀏覽器的同源策略（Same-Origin Policy）引起的，它限制了來自不同源（協議、域名、端口）的腳本訪問當前源的資源。例如，從 http://localhost:3000 向 http://api.example.com 發送請求，會被瀏覽器視為跨域請求。
2. Node.js 中的跨域處理方式
  • 設置響應頭：
    • Node.js 可以在服務器端設置響應頭，允許跨域請求。
    • 常見的是使用 Express 框架進行處理，以下是一個簡單的 Express 示例：
const express = require('express');
const app = express();app.use((req, res, next) => {res.setHeader('Access-Control-Allow-Origin', '*');res.setHeader('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS');res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');if (req.method === 'OPTIONS') {res.sendStatus(204);} else {next();}
});app.get('/api', (req, res) => {res.send('Hello from API');
});app.listen(3000, () => {console.log('Server is running on port 3000');
});
  • 在這個示例中：
    • res.setHeader('Access-Control-Allow-Origin', '*')：允許來自任何源的請求。
    • res.setHeader('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS')：允許的請求方法。
    • res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization')：允許的請求頭。
    • 對于 OPTIONS 請求（預檢請求），使用 res.sendStatus(204) 進行處理，返回 204 狀態碼，因為預檢請求只是瀏覽器的檢查，不需要返回實際數據。
3. 中間件的使用
  • Node.js 中的中間件可以方便地處理跨域請求。
  • 可以將跨域處理封裝成一個中間件，然后在多個路由中使用，提高代碼的復用性和可維護性。
  • 例如：
const express = require('express');
const app = express();const corsMiddleware = (req, res, next) => {res.setHeader('Access-Control-Allow-Origin', '*');res.setHeader('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS');res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');if (req.method === 'OPTIONS') {res.sendStatus(204);} else {next();}
};app.use(corsMiddleware);app.get('/api', (req, res) => {res.send('Hello from API');
});app.listen(3000, () => {console.log('Server is running on port 3000');
});
4. CORS 中間件的使用
  • 為了更方便地處理跨域，可以使用 cors 中間件。
  • 首先安裝 cors 中間件：
npm install cors
  • 然后使用：
const express = require('express');
const cors = require('cors');
const app = express();app.use(cors());app.get('/api', (req, res) => {res.send('Hello from API');
});app.listen(3000, () => {console.log('Server is running on port 3000');
});
  • cors 中間件會自動處理跨域請求，添加必要的響應頭，根據請求的源和方法自動設置 Access-Control-Allow-Origin 等響應頭。
5. 原理解釋

  • 服務器端控制：

    • 跨域限制是由瀏覽器實施的，而 Node.js 作為服務器端，在服務器端設置響應頭時，瀏覽器會讀取這些響應頭并根據它們來決定是否允許跨域請求。
    • 當 Node.js 服務器設置了 Access-Control-Allow-Origin 等響應頭，瀏覽器會根據這些信息判斷是否允許請求訪問資源。

  • 預檢請求的處理：

    • 對于復雜請求（如 PUT、DELETE 或包含自定義請求頭），瀏覽器會先發送 OPTIONS 預檢請求，Node.js 服務器可以通過設置相應的響應頭和狀態碼來處理這些預檢請求，確保后續請求可以正常進行。
面試回答示例

“Node.js 可以進行跨域處理，主要是因為它可以在服務器端設置相應的 HTTP 響應頭來允許跨域請求。使用 Node.js 中的 Express 框架時，我們可以手動設置響應頭，如 Access-Control-Allow-Origin、Access-Control-Allow-Methods 和 Access-Control-Allow-Headers 等，來允許不同源的請求訪問資源。對于預檢請求（OPTIONS 請求），可以根據需要設置 204 狀態碼進行處理。另外，Node.js 可以使用中間件來處理跨域，將跨域處理邏輯封裝在中間件中，方便在多個路由中復用。還可以使用 cors 中間件，它會自動處理跨域請求，根據請求的源和方法添加必要的響應頭。其原理是，跨域限制是瀏覽器實施的，Node.js 作為服務器端可以通過設置響應頭來告訴瀏覽器是否允許跨域，對于瀏覽器發送的預檢請求，Node.js 可以正確處理，確保后續請求正常進行。”

通過這樣的回答，可以向面試官展示你對 Node.js 處理跨域的深入理解，包括具體的實現方式、中間件的使用和原理，體現你對 Node.js 開發和跨域問題的掌握。

3. 瀏覽器的請求頭有哪些

瀏覽器的請求頭（HTTP Request Headers）是瀏覽器在向服務器發送請求時附帶的一組鍵值對，用于傳遞請求的元信息（如瀏覽器類型、支持的編碼、Cookie等）。以下是常見的請求頭及其作用：

1. 通用請求頭（General Headers）

適用于所有類型的請求（GET、POST等）：

  • Host：請求的目標域名和端口（如 Host: example.com）。
  • Connection：控制連接是否保持活動（如 Connection: keep-alive）。
  • Cache-Control：指定緩存機制（如 Cache-Control: no-cache）。
  • User-Agent：標識瀏覽器和操作系統（如 User-Agent: Mozilla/5.0 (Windows NT 10.0)）。
  • Accept：聲明客戶端可處理的響應內容類型（如 Accept: text/html, */*）。
  • Accept-Encoding：支持的壓縮算法（如 Accept-Encoding: gzip, deflate）。
  • Accept-Language：優先的語言（如 Accept-Language: en-US, en;q=0.9）。
2. 請求專用頭（Request-Specific Headers）
  • Authorization：身份驗證憑證（如 Authorization: Bearer xxxxx）。
  • Cookie：發送服務器設置的Cookie（如 Cookie: name=value; name2=value2）。
  • Referer：當前頁面的來源URL（可能被隱私設置屏蔽）。
  • Origin：請求的源（用于跨域請求，如 Origin: https://example.com）。
  • Content-Type：請求體的數據類型（如 Content-Type: application/json）。
  • Content-Length：請求體的字節數（如 Content-Length: 348）。
3. 條件請求頭（Conditional Headers）

用于基于特定條件發送請求：

  • If-Modified-Since：資源修改時間比對（緩存控制）。
  • If-None-Match：ETag比對（緩存驗證）。
  • If-Match / If-Unmodified-Since：用于并發控制。
4. 安全相關頭（Security Headers）
  • Upgrade-Insecure-Requests：自動升級HTTP到HTTPS（如 Upgrade-Insecure-Requests: 1）。
  • Sec-Fetch-*：安全策略相關（如 Sec-Fetch-Site: same-origin）。
5. CORS相關頭（跨域請求）
  • Access-Control-Request-Method：預檢請求中聲明實際請求方法（如 OPTIONS 請求）。
  • Access-Control-Request-Headers：預檢請求中聲明自定義頭。
示例：典型GET請求頭
GET /index.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html,application/xhtml+xml
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cookie: session_id=123456
注意事項
  • 請求頭可通過瀏覽器開發者工具（F12 → Network）查看。
  • 部分頭由瀏覽器自動添加（如 User-Agent），部分可手動設置（如通過JavaScript的 fetch() 或 XMLHttpRequest）。
  • 安全限制下，某些頭不可修改（如 Origin、Host）。

如果需要完整列表，可參考 MDN HTTP Headers 或實際抓包分析。

4. 瀏覽器的響應頭有哪些

瀏覽器的響應頭（HTTP Response Headers）是服務器返回給瀏覽器的一組鍵值對，用于傳遞響應的元信息（如內容類型、緩存策略、安全策略等）。以下是常見的響應頭及其作用：

1. 通用響應頭（General Headers）

適用于所有類型的響應：

  • Date：響應生成的日期和時間（如 Date: Tue, 15 Nov 2022 08:12:31 GMT）。
  • Connection：控制連接是否保持活動（如 Connection: keep-alive）。
  • Cache-Control：指定緩存機制（如 Cache-Control: no-store 或 max-age=3600）。
  • Transfer-Encoding：傳輸編碼方式（如分塊傳輸 Transfer-Encoding: chunked）。
2. 響應專用頭（Response-Specific Headers）
  • Content-Type：響應體的數據類型（如 Content-Type: text/html; charset=utf-8）。
  • Content-Length：響應體的字節數（如 Content-Length: 1024）。
  • Content-Encoding：響應體的壓縮算法（如 Content-Encoding: gzip）。
  • Content-Language：內容使用的語言（如 Content-Language: en-US）。
  • Last-Modified：資源最后修改時間（用于緩存驗證，如 Last-Modified: Mon, 14 Nov 2022 12:00:00 GMT）。
  • ETag：資源的唯一標識符（用于緩存驗證，如 ETag: "33a64df5"）。
3. 緩存控制頭（Caching Headers）
  • Expires：響應過期的絕對時間（如 Expires: Thu, 01 Dec 2022 16:00:00 GMT）。
  • Age：資源在緩存中已存儲的時間（秒）（如 Age: 600）。
  • Vary：指定緩存依據的請求頭（如 Vary: Accept-Encoding）。
4. 安全相關頭（Security Headers）
  • Strict-Transport-Security (HSTS)：強制HTTPS（如 Strict-Transport-Security: max-age=63072000）。
  • X-Content-Type-Options：禁止MIME類型嗅探（如 X-Content-Type-Options: nosniff）。
  • X-Frame-Options：防止點擊劫持（如 X-Frame-Options: DENY）。
  • Content-Security-Policy (CSP)：限制資源加載來源（如 Content-Security-Policy: default-src 'self'）。
  • X-XSS-Protection：啟用XSS過濾器（已逐步被CSP取代）。
5. CORS相關頭（跨域資源共享）
  • Access-Control-Allow-Origin：允許的源（如 Access-Control-Allow-Origin: * 或 https://example.com）。
  • Access-Control-Allow-Methods：允許的HTTP方法（如 Access-Control-Allow-Methods: GET, POST）。
  • Access-Control-Allow-Headers：允許的請求頭（如 Access-Control-Allow-Headers: Content-Type）。
  • Access-Control-Allow-Credentials：是否允許發送Cookie（如 Access-Control-Allow-Credentials: true）。
6. 重定向相關頭（Redirection Headers）
  • Location：重定向目標URL（如 Location: https://example.com/new-page）。
  • Refresh：自動刷新或重定向（如 Refresh: 5; url=https://example.com）。
7. Cookie相關頭
  • Set-Cookie：服務器設置Cookie（如 Set-Cookie: sessionId=abc123; Path=/; Secure）。
示例：典型200響應頭
HTTP/1.1 200 OK
Date: Tue, 15 Nov 2022 08:12:31 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 1024
Content-Encoding: gzip
Cache-Control: public, max-age=3600
Last-Modified: Mon, 14 Nov 2022 12:00:00 GMT
ETag: "33a64df5"
Strict-Transport-Security: max-age=63072000
X-Content-Type-Options: nosniff
注意事項
  • 響應頭可通過瀏覽器開發者工具（F12 → Network → 點擊請求 → Headers）查看。
  • 安全頭（如CSP、HSTS）對Web安全至關重要，建議在生產環境中配置。
  • 部分頭由服務器框架自動添加（如 Server: nginx），部分需手動配置。

完整列表可參考 MDN HTTP Headers 或實際抓包分析。

5. 瀏覽器輸入網址后發生什么

以下是從輸入 URL 到頁面呈現的詳細過程：

1. 用戶輸入 URL
  • 用戶在瀏覽器的地址欄中輸入一個 URL（Uniform Resource Locator），例如 https://www.example.com。
2. URL 解析
  • 瀏覽器會對輸入的 URL 進行解析，將其拆分成幾個部分：
    • 協議：如 https，確定使用的通信協議。
    • 域名：如 www.example.com，用于定位服務器。
    • 端口：如果沒有指定，對于 https 協議默認是 443，對于 http 協議默認是 80。
    • 路徑：如 /index.html，表示請求的資源路徑。
    • 查詢參數：如 ?param1=value1&param2=value2，提供額外的信息。
    • 片段標識符：如 #section1，用于定位頁面內的特定部分。
3. DNS 查詢
  • 瀏覽器會首先檢查本地 DNS 緩存，看是否已經解析過該域名。
  • 如果沒有，瀏覽器會向操作系統的 DNS 解析器發送請求，操作系統會先查看本地的 hosts 文件。
  • 如果還沒有，請求會發送到 DNS 服務器，DNS 服務器會根據域名的層次結構進行解析，從根域名服務器到頂級域名服務器，再到權威域名服務器，最終找到對應的 IP 地址。
4. 建立 TCP 連接
  • 瀏覽器使用獲取到的 IP 地址，與服務器建立 TCP 連接。
  • 對于 HTTPS，還需要進行 TLS 握手，包括：
    • 客戶端向服務器發送 ClientHello 消息，包含支持的加密算法、隨機數等。
    • 服務器向客戶端發送 ServerHello 消息，選擇的加密算法、證書等。
    • 客戶端驗證證書，生成一個隨機的預主密鑰，使用服務器的公鑰加密并發送給服務器。
    • 服務器使用私鑰解密得到預主密鑰，雙方根據預主密鑰和之前交換的隨機數生成會話密鑰。
5. 發送 HTTP 請求
  • 一旦 TCP 連接建立（包括 TLS 握手完成），瀏覽器會向服務器發送 HTTP 請求。
  • 請求包括請求行（請求方法、請求路徑、HTTP 協議版本）、請求頭（包含各種信息，如 User-Agent、Accept 等）和請求體（如果有）。
6. 服務器處理請求
  • 服務器收到請求后，會根據請求的信息進行處理：
    • 可能會調用后端程序（如 PHP、Node.js、Java 等），處理動態內容。
    • 或者直接從文件系統中讀取靜態文件（如 HTML、CSS、JavaScript、圖片等）。
7. 服務器響應請求
  • 服務器會發送 HTTP 響應，包括：
    • 響應行（HTTP 協議版本、狀態碼、狀態消息）。
    • 響應頭（包含內容類型、內容長度、緩存信息等）。
    • 響應體（實際的數據內容）。
8. 瀏覽器接收和解析響應
  • 瀏覽器收到響應后，會檢查狀態碼：
    • 對于 200 OK 等成功狀態碼，會繼續處理響應。
    • 對于 404 Not Found 等錯誤狀態碼，會顯示相應的錯誤頁面。
  • 瀏覽器會根據響應頭中的 Content-Type 解析響應體：
    • 對于 HTML，會開始解析 HTML 結構，構建 DOM 樹。
    • 對于 CSS，會解析 CSS 規則，構建 CSSOM 樹。
    • 對于 JavaScript，會執行 JavaScript 代碼，可能會修改 DOM 或 CSSOM。
9. 渲染頁面
  • 瀏覽器會將 DOM 樹和 CSSOM 樹結合起來，構建渲染樹（Render Tree）。
  • 計算渲染樹中每個節點的布局（Layout），確定元素的位置和大小。
  • 最后將渲染樹繪制（Paint）到屏幕上，顯示頁面。
10. 后續操作
  • 瀏覽器會繼續加載其他資源，如圖片、CSS 文件、JavaScript 文件等，根據需要進行緩存操作。
  • 還會處理頁面中的腳本，如監聽用戶事件、執行異步請求等。

在面試中可以這樣回答：“當用戶輸入 URL 時，瀏覽器會對其進行解析，然后進行 DNS 查詢找到服務器的 IP 地址。對于 HTTPS 請求，會進行 TLS 握手確保通信安全。接著建立 TCP 連接，發送 HTTP 請求。服務器收到請求后進行處理，然后發送 HTTP 響應。瀏覽器收到響應后，根據狀態碼和響應頭處理響應內容，對于 HTML 會構建 DOM 樹，對于 CSS 會構建 CSSOM 樹，然后結合兩者構建渲染樹，進行布局和繪制操作，最終將頁面呈現出來。后續還會繼續加載其他資源并進行緩存操作，處理頁面中的腳本等。這個過程涉及多個步驟，包括網絡、安全、解析和渲染等多個方面，確保頁面的正確呈現和用戶的良好體驗。”

這樣的回答可以讓面試官看到你對整個從輸入 URL 到頁面呈現的完整流程的理解，同時也可以根據需要進一步細化每個步驟的解釋，比如詳細說明 TCP 連接的三次握手、TLS 握手的詳細過程等，展現你對網絡和前端開發的深入知識。

6. http 協議和 https 有什么區別

HTTP（HyperText Transfer Protocol）和HTTPS（HTTP Secure）是用于在客戶端和服務器之間傳輸數據的協議，但它們在安全性、工作原理和性能等方面有顯著區別。以下是主要區別：

1. 安全性

  • HTTP：

    • 不加密，數據以明文形式傳輸，容易被竊聽、篡改或中間人攻擊。
    • 不適合傳輸敏感信息（如密碼、銀行卡號等）。

  • HTTPS：

    • 加密傳輸，通過 SSL/TLS 協議對數據進行加密，確保數據的機密性和完整性。
    • 防止數據被竊取或篡改，適合敏感信息傳輸。
2. 協議與端口

  • HTTP：

    • 基于 TCP/IP，默認使用 80 端口。

  • HTTPS：

    • 在 HTTP 基礎上加入 SSL/TLS 加密層，默認使用 443 端口。
3. 證書與身份驗證
  • HTTPS 需要數字證書：
    • 由受信任的 CA（證書頒發機構） 簽發，用于驗證服務器身份，防止釣魚網站。
    • 證書包含公鑰、域名、有效期等信息。
  • HTTP 無證書，無法驗證服務器真實性。
4. 性能與速度

  • HTTP：

    • 無加密開銷，速度稍快（但差異在現代硬件中已不明顯）。

  • HTTPS：

    • 加密/解密過程會增加少量計算開銷（TLS 握手階段）。
    • 現代優化技術（如 TLS 1.3、HTTP/2、會話復用）已大幅降低性能影響。
5. SEO 與瀏覽器支持
  • HTTPS 是搜索引擎的排名因素：
    • Google 等搜索引擎優先收錄 HTTPS 網站。
  • 瀏覽器標記不安全：
    • 現代瀏覽器（Chrome、Firefox）會將 HTTP 網站標記為“不安全”。
    • HTTPS 網站顯示鎖圖標，增強用戶信任。
6. 應用場景
  • HTTP：
    • 僅適用于不涉及敏感信息的場景（如靜態博客、新聞網站）。
  • HTTPS：
    • 必需：電商、銀行、登錄頁面、API 接口等。
    • 現代瀏覽器已強制要求 HTTPS 支持新特性（如地理位置、Service Worker）。
7. 工作原理對比
步驟HTTPHTTPS
建立連接TCP 三次握手TCP 握手 + TLS 握手（交換密鑰）
數據傳輸明文加密（對稱加密，如 AES）
驗證服務器無通過證書驗證身份
為什么 HTTPS 是趨勢？
  1. 隱私保護：防止流量劫持、釣魚攻擊。
  2. 合規要求：如 GDPR、PCI-DSS 要求數據加密。
  3. 技術發展：免費證書（Let’s Encrypt）、自動化工具降低了部署成本。
總結
特性HTTPHTTPS
加密無SSL/TLS 加密
端口80443
安全性低高（防竊聽、篡改）
證書不需要需要 CA 簽發證書
速度略快稍慢（可優化）
適用場景非敏感數據敏感數據、現代網站

建議：當前所有網站都應遷移到 HTTPS，尤其是涉及用戶數據的服務。

7. 你的核心優勢是什么

我有 8 年大型前端架構經驗，主導過多個百萬級項目，我的核心優勢是：高并發場景下的前端系統設計和通過技術驅動業務增長，具體體現在三個層面：

  1. 技術架構層面：

在美條電商大促項目中（峰值QPS 10w+），設計并落地了 邊緣計算方案（Cloudflare Workers + SSR），將動態內容渲染耗時從800ms降至200ms，支撐了秒殺場景下零白屏的體驗，GMV同比提升18%；

搭建前端監控體系（ELK + Sentry），實現從埋點、告警到根因分析的閉環，線上故障率下降60%。

  1. 工程體系層面：

從 0 到 1 構建團隊前端微前端基座（基于qiankun2.0），整合6條業務線獨立交付能力，容器化部署效率提升70%；

主導開發低代碼平臺（ProCode + LowCode混合模式），覆蓋中后臺80%表單/列表場景，人力成本降低50%。

  1. 業務協同層面：

作為前端 TL 與產品/后端共建灰度發布系統，實現AB測試流量分層和指標監控，功能迭代ROI評估效率提升3倍；

在外匯國際化項目中，設計多語言編譯時方案（基于AST轉換），減少運行時開銷，首屏性能達標率100%。

我關注到貴司正在推進XX技術方向（如智能化/體驗優化），我的架構經驗和業務視角可以快速適配，也希望能在團隊技術規劃上深度參與。

8. 瀏覽器緩存機制

瀏覽器緩存機制是提升網頁加載速度、減少服務器負載的關鍵技術，通過將靜態資源（如 HTML、CSS、JS、圖片等）存儲在本地，避免重復請求。以下是瀏覽器緩存的詳細機制和工作流程：

一、緩存類型

瀏覽器緩存分為兩類：

  1. 強緩存
    • 直接使用本地緩存，不發送請求到服務器。
    • 通過 Cache-Control 和 Expires 響應頭控制。
  2. 協商緩存
    • 向服務器驗證緩存是否過期，若未過期則返回 304 Not Modified，繼續使用緩存；否則返回新資源。
    • 通過 Last-Modified/If-Modified-Since 或 ETag/If-None-Match 實現。
二、緩存控制字段
1. 強緩存相關字段

  • Cache-Control（HTTP/1.1 優先級高于 Expires）
    常見指令：

    • max-age=3600：資源緩存有效期（秒）。
    • no-cache：禁用強緩存，需走協商緩存。
    • no-store：完全禁止緩存（敏感數據適用）。
    • public：允許代理服務器緩存。
    • private：僅允許瀏覽器緩存。

  • Expires（HTTP/1.0）

    • 指定緩存過期時間（如 Expires: Wed, 21 Oct 2025 07:28:00 GMT），依賴客戶端時間，可能因時鐘不同步失效。
2. 協商緩存相關字段

  • Last-Modified / If-Modified-Since

    • 服務器返回 Last-Modified（資源最后修改時間）。
    • 瀏覽器下次請求時帶上 If-Modified-Since，服務器對比時間決定返回 304 或 200。
    • 缺點：精度僅到秒，頻繁修改可能無法識別。

  • ETag / If-None-Match（優先級高于 Last-Modified）

    • 服務器返回 ETag（資源的唯一標識符，如哈希值）。
    • 瀏覽器下次請求時帶上 If-None-Match，服務器對比 ETag 決定返回 304 或 200。
    • 解決 Last-Modified 的精度問題。
三、緩存工作流程

  1. 首次請求

    • 無緩存，直接向服務器請求資源。
    • 服務器返回資源及緩存頭（如 Cache-Control: max-age=3600）。

  2. 再次請求

    • 強緩存生效：檢查 Cache-Control/Expires，若未過期則直接讀取本地緩存（狀態碼 200 (from disk cache)）。
    • 強緩存失效：
      • 向服務器發送請求，攜帶 If-Modified-Since 或 If-None-Match。
      • 服務器驗證后返回 304（使用緩存）或 200（返回新資源）。
四、用戶行為對緩存的影響
用戶操作強緩存協商緩存
正常刷新（F5）失效生效
強制刷新（Ctrl+F5）失效失效
地址欄回車/前進后退生效生效
五、實際應用建議

  1. 靜態資源（CSS/JS/圖片）

    • 設置長期強緩存：Cache-Control: max-age=31536000（1年）。
    • 通過文件名哈希（如 app.a1b2c3.js）實現內容更新后緩存失效。

  2. HTML 文件

    • 禁用強緩存：Cache-Control: no-cache，確保用戶獲取最新版本。

  3. API 接口

    • 根據場景選擇 no-cache 或短時間 max-age，避免數據過期。
六、示例配置（Nginx）
# 靜態資源（強緩存）
location ~* \.(js|css|png|jpg)$ {expires 1y;add_header Cache-Control "public, max-age=31536000";
}# HTML 文件（協商緩存）
location / {add_header Cache-Control "no-cache";
}
七、調試工具
  • Chrome DevTools：
    • Network 面板：查看請求的緩存狀態（from disk cache 或 304）。
    • Application → Cache Storage：檢查緩存的資源。
總結

瀏覽器緩存通過減少網絡請求顯著提升性能，合理配置需要結合資源類型和更新頻率。強緩存優先用于靜態資源，協商緩存確保動態內容的及時更新。

9. https 的加密機制

HTTPS 的加密機制通過 SSL/TLS 協議 實現，結合 對稱加密、非對稱加密、數字證書 和 散列算法，確保數據在傳輸過程中的 機密性、完整性 和 身份認證。以下是詳細的分步解析：

一、HTTPS 加密的核心組件

  1. 對稱加密（如 AES）

    • 作用：加密實際傳輸的數據。
    • 特點：加密/解密速度快，但需共享密鑰。

  2. 非對稱加密（如 RSA、ECC）

    • 作用：在握手階段交換對稱加密的密鑰。
    • 特點：公鑰加密、私鑰解密，安全性高但性能差。

  3. 數字證書（CA 簽發）

    • 作用：驗證服務器身份，防止中間人攻擊。
    • 內容：包含公鑰、域名、簽發機構等信息。

  4. 散列算法（如 SHA-256）

    • 作用：生成消息摘要，確保數據完整性（防篡改）。
二、HTTPS 加密流程（TLS 握手）

以 TLS 1.2 為例（簡化版）：

步驟 1：Client Hello
  • 客戶端向服務器發送：
    • 支持的 TLS 版本、加密套件（如 TLS_AES_256_GCM_SHA384）。
    • 隨機數（Client Random），用于后續生成密鑰。
步驟 2：Server Hello
  • 服務器返回：
    • 選定的 TLS 版本和加密套件。
    • 隨機數（Server Random）。
    • 數字證書（包含公鑰和 CA 簽名）。
步驟 3：證書驗證
  • 客戶端驗證證書：
    1. 檢查證書是否過期、域名是否匹配。
    2. 通過 CA 的公鑰（內置在操作系統/瀏覽器中）驗證簽名是否合法。
    • 若驗證失敗：瀏覽器提示“不安全連接”。
步驟 4：密鑰交換
  • 客戶端生成 預主密鑰（Pre-Master Secret），用服務器的公鑰加密后發送。
  • 服務器用私鑰解密獲取預主密鑰。
步驟 5：生成會話密鑰
  • 客戶端和服務器通過 Client Random、Server Random 和 Pre-Master Secret，使用相同算法生成 主密鑰（Master Secret），再派生出 會話密鑰（Session Key）（對稱加密密鑰）。
步驟 6：加密通信
  • 雙方使用會話密鑰進行對稱加密通信（如 AES-256），后續數據傳輸均加密。
三、關鍵安全機制

  1. 混合加密

    • 非對稱加密 用于安全交換對稱密鑰（解決密鑰分發問題）。
    • 對稱加密 用于高效加密數據（解決性能問題）。

  2. 數字證書防偽

    • CA 機構對證書簽名，客戶端通過預置的 CA 公鑰驗證，確保服務器身份真實。

  3. 完整性校驗

    • 使用 HMAC 或 AEAD 模式（如 AES-GCM）防止數據被篡改。

  4. 前向保密（Forward Secrecy）

    • 通過 ECDHE 密鑰交換協議，即使服務器私鑰泄露，歷史會話也無法解密。
四、TLS 1.3 的優化
  • 簡化握手：減少為 1-RTT（甚至 0-RTT），提升速度。
  • 廢棄不安全算法：移除 RSA 密鑰交換、SHA-1 等。
  • 強制前向保密：僅支持 ECDHE 密鑰交換。
五、示例對比（HTTP vs HTTPS）
階段HTTPHTTPS（TLS 加密）
數據傳輸明文加密（AES-256）
身份驗證無數字證書驗證
密鑰交換無非對稱加密（RSA/ECDHE）
防篡改無散列算法（SHA-256）
六、常見問題

  1. 為什么不用純非對稱加密？

    • 性能差（RSA 加密比 AES 慢 1000 倍以上）。

  2. 如何防止中間人攻擊？

    • 依賴 CA 簽發的證書，瀏覽器內置可信 CA 列表。

  3. HTTPS 一定安全嗎？

    • 不一定，若服務器配置錯誤（如使用弱加密套件）或客戶端忽略證書警告，仍可能被攻擊。
七、配置建議
  • 使用 TLS 1.2/1.3，禁用舊版本（如 SSLv3）。
  • 選擇強加密套件（如 AES256-GCM-SHA384）。
  • 定期更新證書（推薦免費證書：Let’s Encrypt）。
總結

HTTPS 的加密機制通過 混合加密 和 證書體系，在安全與性能之間取得平衡。理解其原理有助于優化配置和排查安全問題。現代網站應強制啟用 HTTPS，并遵循最佳實踐（如 HSTS、OCSP Stapling）。

10. tcp 的三次握手和四次揮手

TCP（傳輸控制協議）是一種面向連接的可靠傳輸協議，三次握手用于建立連接，四次揮手用于終止連接。以下是詳細解析：

一、TCP 三次握手（建立連接）

目的：確保雙方（客戶端和服務端）的發送和接收能力正常，并同步初始序列號（ISN）。
流程：

  1. 第一次握手（SYN=1, seq=x）：

    • 客戶端發送 SYN 包（同步序列號）到服務端，并隨機生成初始序列號 x（ISN）。
    • 客戶端進入 SYN_SENT 狀態。

  2. 第二次握手（SYN=1, ACK=1, seq=y, ack=x+1）：

    • 服務端收到 SYN 后，回復 SYN+ACK 包：
      • 確認客戶端的序列號（ack=x+1）。
      • 發送自己的初始序列號 y（ISN）。
    • 服務端進入 SYN_RCVD 狀態。

  3. 第三次握手（ACK=1, seq=x+1, ack=y+1）：

    • 客戶端收到 SYN+ACK 后，回復 ACK 包（ack=y+1）。
    • 服務端收到 ACK 后，雙方進入 ESTABLISHED 狀態，連接建立完成。

為什么需要三次？

  • 防止歷史重復連接的初始化（如舊的 SYN 包延遲到達）。
  • 確保雙方發送和接收能力均正常（兩次無法確認客戶端的接收能力）。
二、TCP 四次揮手（終止連接）

目的：雙方安全關閉連接，確保數據完整傳輸。
流程（假設客戶端主動關閉）：

  1. 第一次揮手（FIN=1, seq=u）：

    • 客戶端發送 FIN 包，進入 FIN_WAIT_1 狀態，表示不再發送數據。

  2. 第二次揮手（ACK=1, ack=u+1）：

    • 服務端收到 FIN 后，回復 ACK 包（ack=u+1），進入 CLOSE_WAIT 狀態。
    • 客戶端收到 ACK 后進入 FIN_WAIT_2 狀態。
    • 此時服務端仍可發送未傳完的數據。

  3. 第三次揮手（FIN=1, ACK=1, seq=v, ack=u+1）：

    • 服務端完成數據發送后，發送 FIN+ACK 包，進入 LAST_ACK 狀態。

  4. 第四次揮手（ACK=1, seq=u+1, ack=v+1）：

    • 客戶端收到 FIN 后，回復 ACK 包，進入 TIME_WAIT 狀態（等待 2MSL）。
    • 服務端收到 ACK 后關閉連接，客戶端在 2MSL 后也關閉連接。

為什么需要四次？

  • TCP 是全雙工的，必須分別關閉兩個方向的連接：
    • 客戶端關閉發送（第一次揮手）。
    • 服務端關閉接收（第二次揮手）。
    • 服務端關閉發送（第三次揮手）。
    • 客戶端關閉接收（第四次揮手）。
三、關鍵問題解析
1. TIME_WAIT 狀態的作用
  • 等待 2MSL（最大報文段生存時間）：
    • 確保最后一個 ACK 能到達服務端（若丟失，服務端會重發 FIN）。
    • 讓網絡中殘留的舊報文失效，避免影響新連接。
2. SYN 洪水攻擊
  • 攻擊者偽造大量 SYN 包但不回復 ACK，耗盡服務端資源。
  • 防御：啟用 SYN Cookie 或限制并發連接數。
3. 為什么握手三次、揮手四次？
  • 握手時，服務端的 SYN+ACK 可以合并為一步。
  • 揮手時，服務端的 ACK 和 FIN 通常不能合并（因為中間可能有數據待發送）。
四、示意圖
三次握手
客戶端                         服務端|-------- SYN (x) ------->|  |<----- SYN+ACK (y, x+1)--|  |------- ACK (y+1) ------>|
四次揮手
客戶端                         服務端|-------- FIN (u) ------->|  |<------- ACK (u+1) ------|  |<------- FIN (v) --------|  |------- ACK (v+1) ------>|
五、實際應用注意
  1. 優化 TIME_WAIT：
    • 高并發服務器可調整內核參數（如 net.ipv4.tcp_tw_reuse）。
  2. 快速重傳：
    • 若連續收到重復 ACK，立即重傳丟失的包（無需等待超時）。
  3. 長連接：
    • HTTP/1.1 的 Keep-Alive 或 HTTP/2 復用連接，減少握手開銷。
總結
  • 三次握手：解決同步初始序列號和雙向通信能力確認問題。
  • 四次揮手：確保全雙工連接的兩個方向安全關閉。
  • TCP 的可靠性依賴于序列號、確認機制和狀態機設計，理解這些細節對網絡調試和優化至關重要。

11. get 和 post 有什么區別

GET 和 POST 是 HTTP 協議中最常用的兩種請求方法，它們在設計目的、使用場景和底層實現上有顯著區別。以下是詳細對比：

一、核心區別總結
特性GETPOST
語義獲取資源（冪等）提交數據（非冪等）
數據位置URL 的查詢字符串（?key=value）請求體（Body）
數據長度限制受 URL 長度限制（通常 2KB~8KB）無限制（服務器可配置限制）
安全性數據明文暴露在 URL 中（不適合敏感信息）數據在 Body 中，HTTPS 下更安全
緩存可被緩存（瀏覽器/CDN）默認不緩存
歷史記錄保留在瀏覽器歷史/日志中不保留
編碼類型僅 application/x-www-form-urlencoded支持多種（如 multipart/form-data、JSON）
冪等性冪等（多次請求結果相同）非冪等（可能修改服務器狀態）
二、深入解析
1. 設計目的

  • GET：

    • 用于安全操作（Safe），即不應修改服務器狀態（如查詢數據）。
    • 符合冪等性（Idempotent），多次請求效果相同。

  • POST：

    • 用于非安全操作（可能修改數據，如提交表單）。
    • 非冪等（重復提交可能產生副作用，如多次下單）。
2. 數據傳輸方式

  • GET：

    GET /search?q=hello&page=1 HTTP/1.1
Host: example.com
    • 數據通過 URL 的**查詢參數（Query String）**傳遞，明文可見。

  • POST：

    POST /submit HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencodedusername=admin&password=123456
    • 數據放在請求體（Body）中，支持多種編碼格式（如 JSON、文件上傳）。
3. 安全性誤區
  • GET 不安全？
    • 即使使用 HTTPS，GET 的 URL 參數仍可能被瀏覽器歷史記錄、服務器日志記錄，導致信息泄露。
  • POST 更安全？
    • 僅在 HTTPS 下安全（Body 加密），但 HTTP 下 Body 仍是明文。敏感數據（如密碼）必須用 HTTPS + POST。
4. 緩存機制
  • GET：
    • 可被瀏覽器、代理服務器緩存（通過 Cache-Control 或 Expires 頭控制）。
    • 適合靜態資源請求（如 JS、CSS）。
  • POST：
    • 默認不緩存（除非顯式設置 Cache-Control）。
5. 冪等性與網絡問題
  • GET：
    • 請求失敗時可自動重試（不影響結果）。
  • POST：
    • 重試可能導致重復提交（如支付場景需額外防重機制）。
三、使用場景
適合 GET 的情況：
  • 檢索數據（如搜索、分頁查詢）。
  • 無副作用的操作（如獲取用戶信息）。
  • 需要緩存的請求（如靜態資源）。
適合 POST 的情況：
  • 提交敏感數據（如登錄、支付）。
  • 上傳文件或大量數據（如表單提交）。
  • 修改服務器狀態的操作（如創建訂單、刪除數據）。
四、常見面試問題
1. GET 能否傳 Body？POST 能否用 Query String？
  • GET 的 Body：
    • 協議不禁止，但多數服務器會忽略（如 curl -X GET --data "key=value"）。
  • POST 的 Query String：
    • 可以（但數據通常放在 Body 中更合理）。
2. 為什么 POST 更安全？
  • 僅因為數據不直接暴露在 URL 中，但實際安全性依賴 HTTPS。
3. RESTful API 中的用法：
  • GET /users：獲取用戶列表。
  • POST /users：創建新用戶。
五、總結
  • GET：輕量、可緩存、適合讀操作。
  • POST：靈活、無長度限制、適合寫操作。
  • 關鍵選擇依據：
    • 是否修改服務器狀態？ → 是則用 POST。
    • 數據是否敏感或超長？ → 是則用 POST + HTTPS。

永遠不要用 GET 傳輸密碼或敏感信息！

12. 講一下 xss 攻擊

一、XSS攻擊基本概念

XSS（Cross-Site Scripting，跨站腳本攻擊）是一種常見的Web安全漏洞，攻擊者通過在目標網站上注入惡意腳本，當其他用戶訪問該頁面時，這些腳本會在用戶的瀏覽器中執行。

為什么叫XSS而不是CSS？

為了避免與層疊樣式表(CSS)混淆，安全專家將其縮寫為XSS。

二、XSS攻擊的三種主要類型
1. 反射型XSS（非持久型）
  • 特點：惡意腳本來自當前HTTP請求
  • 攻擊流程：
    1. 攻擊者構造包含惡意腳本的URL
    2. 誘騙用戶點擊該URL
    3. 服務器將惡意腳本"反射"回用戶的瀏覽器執行
  • 示例：
    http://example.com/search?q=<script>alert('XSS')</script>
2. 存儲型XSS（持久型）
  • 特點：惡意腳本被永久存儲在目標服務器上
  • 攻擊流程：
    1. 攻擊者將惡意腳本提交到網站數據庫（如評論區）
    2. 其他用戶訪問包含該內容的頁面時自動執行
  • 危害性：更大，影響所有訪問者
3. DOM型XSS
  • 特點：完全在客戶端執行，不涉及服務器
  • 攻擊流程：
    1. 惡意腳本通過修改DOM環境在客戶端執行
    2. 通常利用URL片段(#)或hash值
  • 示例：
    // 假設網站有這段代碼
document.write(location.hash.substring(1));// 攻擊URL
http://example.com#<script>alert('XSS')</script>
三、XSS攻擊的危害
  1. 竊取用戶Cookie：獲取用戶會話信息
  2. 釣魚攻擊：偽造登錄表單
  3. 鍵盤記錄：監控用戶輸入
  4. 篡改頁面內容：顯示虛假信息
  5. 傳播蠕蟲：自動轉發攻擊內容
四、XSS防御措施
1. 輸入過濾
  • 對用戶輸入進行嚴格驗證
  • 過濾或轉義特殊字符（<, >, &, ", '等）
  • 示例代碼：
    function escapeHtml(str) {return str.replace(/[&<>'"]/g, tag => ({'&': '&amp;','<': '&lt;','>': '&gt;',"'": '&#39;','"': '&quot;'}[tag]));
}
2. 輸出編碼
  • 根據輸出上下文使用不同的編碼：
    • HTML實體編碼：< → &lt;
    • JavaScript編碼：' → \x27
    • URL編碼：& → %26
3. 使用CSP（內容安全策略）

HTTP頭部設置：

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com

限制：

  • 內聯腳本執行
  • 外部資源加載源
4. 其他措施
  • 設置HttpOnly Cookie：防止JavaScript訪問
  • 使用X-XSS-Protection頭部（現代瀏覽器已棄用）
  • 框架自帶防護（如React的JSX自動轉義）
五、現代Web開發中的XSS防護
  1. 前端框架：React/Vue/Angular等都有內置防護
  2. 模板引擎：如Handlebars、EJS等自動轉義
  3. 安全庫：DOMPurify、sanitize-html等
六、測試XSS漏洞
  1. 使用簡單payload測試：<script>alert(1)</script>
  2. 工具：
    • OWASP ZAP
    • Burp Suite
    • XSS Hunter（用于盲測）

XSS攻擊雖然歷史悠久，但在現代Web應用中仍然常見。開發者需要采取多層次防御策略，從輸入驗證到輸出編碼，結合現代開發框架的安全特性，才能有效防范這類攻擊。

14. 講一下瀏覽器同源策略問題

一、同源策略基本概念

同源策略(Same-Origin Policy)是瀏覽器最核心的安全策略之一，它限制了一個源(origin)的文檔或腳本如何與另一個源的資源進行交互。

1. 什么是"同源"？

兩個URL在以下三個方面完全相同才被認為是同源：

  • 協議相同（http/https）
  • 域名相同（example.com）
  • 端口相同（默認80/443）
URL1URL2是否同源原因
https://example.com/ahttps://example.com/b是協議、域名、端口相同
http://example.comhttps://example.com否協議不同
https://example.comhttps://api.example.com否域名不同
https://example.com:8080https://example.com否端口不同
二、同源策略的限制范圍

同源策略主要限制以下三類行為：

1. DOM訪問限制
  • 不同源的頁面無法通過JavaScript訪問彼此的DOM
  • 例如：iframe.contentWindow、window.open()返回的窗口對象
2. 網絡請求限制
  • 通常禁止向不同源發送AJAX請求（可通過CORS解除）
  • 限制WebSocket和Fetch API的跨源請求
3. 存儲訪問限制
  • 限制不同源頁面訪問彼此的Cookie、LocalStorage、IndexedDB等
三、同源策略的例外情況
1. 允許跨源嵌入的資源
  • <script src="..."> (JSONP利用此特性)
  • <link rel="stylesheet" href="...">
  • <img>, <video>, <audio>等媒體標簽
  • <iframe> (但限制父子文檔間的DOM訪問)
2. 允許跨源寫入
  • 表單提交（但無法讀取響應結果）
  • 重定向
3. 允許有限跨源讀取
  • 某些嵌入資源可以讀取部分信息：
    • iframe的window.length
    • 圖片的width/height
    • 腳本的錯誤信息
四、解決跨源問題的方案
1. CORS (跨源資源共享)
  • 服務端設置Access-Control-Allow-Origin響應頭
  • 預檢請求(preflight)處理復雜請求
  • 示例：
    Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type
2. JSONP (僅限GET請求)
  • 利用<script>標簽不受同源策略限制的特性
  • 示例：
    function handleResponse(data) {console.log(data);
}
const script = document.createElement('script');
script.src = 'https://api.example.com/data?callback=handleResponse';
document.body.appendChild(script);
3. 代理服務器
  • 同源服務器轉發跨源請求
  • 示例(Nginx配置)：
    location /api/ {proxy_pass https://api.example.com/;
}
4. postMessage API
  • 跨文檔通信的標準方法
  • 示例：
    // 發送方
otherWindow.postMessage('Hello', 'https://target.com');// 接收方
window.addEventListener('message', (event) => {if (event.origin !== 'https://trusted.com') return;console.log(event.data);
});
5. 修改document.domain (僅限子域)
  • 適用于主域相同、子域不同的情況
  • 示例：
    // a.example.com和b.example.com都設置
document.domain = 'example.com';
五、現代Web開發中的同源策略
1. 開發環境解決方案
  • Webpack DevServer代理
  • Chrome禁用安全標志(僅限開發)
    google-chrome --disable-web-security --user-data-dir=/tmp
2. 生產環境最佳實踐
  • 合理配置CORS
  • 使用JWT代替Cookie進行身份驗證
  • 對敏感操作實施CSRF保護
六、安全注意事項

  1. 不要隨意設置Access-Control-Allow-Origin: *

    • 僅對需要公開的API使用通配符
    • 敏感API應指定具體域名

  2. 正確處理postMessage的origin驗證

    window.addEventListener('message', (event) => {if (event.origin !== 'https://trusted.com') return;// 處理消息
});

  3. 避免不安全的JSONP實現

    • 確保JSONP端點不返回敏感數據
    • 考慮棄用JSONP轉向CORS

同源策略是Web安全的基石，理解其工作原理和解決方案對于現代Web開發至關重要。合理使用CORS、postMessage等技術可以在保證安全性的同時實現必要的跨源功能。

15. 講一下進程線程的區別

一、基本概念對比
特性進程 (Process)線程 (Thread)
定義操作系統資源分配的基本單位CPU調度和執行的基本單位
獨立性獨立的內存空間和系統資源共享所屬進程的內存和資源
創建開銷大（需要分配獨立資源）小（共享進程資源）
通信方式進程間通信(IPC)：管道、消息隊列等直接讀寫進程的共享內存
穩定性一個進程崩潰不影響其他進程一個線程崩潰會導致整個進程終止
并發性進程間并行線程間并發
二、技術層面深度解析
1. 內存結構差異

進程內存模型：

  • 獨立地址空間
  • 包含：代碼段、數據段、堆、棧
  • 通過虛擬內存機制隔離

線程內存模型：

  • 共享進程的地址空間
  • 每個線程有獨立的棧空間
  • 共享堆、全局變量等內存區域

圖示：

進程A
├── 代碼段
├── 數據段
├── 堆
└── 線程1└── 棧
└── 線程2└── 棧
2. 上下文切換成本

  • 進程切換：

    • 需要保存/恢復：內存映射、寄存器、文件描述符等
    • 通常涉及TLB刷新
    • 開銷大（微秒級）

  • 線程切換：

    • 只需保存/恢復：寄存器、棧指針等
    • 共享地址空間，無需TLB刷新
    • 開銷小（納秒級）
三、實際應用場景
適合使用進程的情況：
  1. 需要高度穩定性的服務（如系統守護進程）
  2. 需要嚴格隔離的任務（如瀏覽器多標簽頁）
  3. 利用多核CPU實現真正并行
適合使用線程的情況：
  1. 需要頻繁通信的任務（如GUI應用）
  2. 需要快速創建/銷毀的輕量級任務
  3. IO密集型應用（避免進程切換開銷）
四、現代技術發展
1. 協程（Coroutine）
  • 更輕量級的"用戶態線程"
  • 由程序員控制調度（非搶占式）
  • 典型實現：Go語言的goroutine
2. 線程池優化
  • 避免頻繁創建/銷毀線程
  • Java的ExecutorService
  • C++的std::thread_pool
3. 多進程架構新趨勢
  • 容器化技術（Docker）使多進程部署更輕量
  • 微服務架構提倡進程級隔離
五、常見面試問題解析
Q1：為什么線程比進程更輕量級？

A：線程共享進程資源，創建時無需分配新內存空間，上下文切換只需保存少量寄存器狀態。

Q2：多線程程序一定比單線程快嗎？

A：不一定。對于CPU密集型任務，線程數超過CPU核心數反而會因頻繁切換降低性能。IO密集型任務通常能受益于多線程。

Q3：何時會引發線程安全問題？

A：當多個線程同時訪問共享資源且至少有一個線程執行寫操作時。典型場景：

  • 修改全局變量
  • 操作共享文件描述符
  • 訪問共享內存數據結構
六、編程語言實現差異
語言進程創建線程創建
Cfork()pthread_create()
Pythonos.fork()threading.Thread()
JavaProcessBuilder.start()new Thread().start()
Go無原生支持，需execgo func() { … }
七、性能優化建議

  1. 避免線程爆炸：

    • 使用線程池控制線程數量
    • 一般設置為CPU核心數的1-2倍

  2. 減少鎖競爭：

    • 使用讀寫鎖替代互斥鎖
    • 考慮無鎖數據結構

  3. 進程間通信優化：

    • 大數據傳輸使用共享內存
    • 小消息使用管道或消息隊列

理解進程與線程的區別是系統編程的基礎，合理選擇并發模型可以顯著提升程序性能和穩定性。現代開發中通常采用混合模式（如Nginx的多進程+單線程事件循環），根據實際需求平衡隔離性與性能開銷。

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

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

相關文章

如何選擇合適的光源？

如何選擇合適的光源？

目錄 工業相機光源類型全面指南 1. 環形光源及其變體 高角度環形光源 優點 缺點 典型應用場景 低角度環形光源&#xff08;暗場照明&#xff09; 優點 缺點 典型應用場景 2. 條形光源與組合照明系統 技術特點 組合條形光源 優點 缺點 典型應用場景 3. 同軸光源…
閱讀更多...
「OC」源碼學習——對象的底層探索

「OC」源碼學習——對象的底層探索

「OC」源碼學習——對象的底層探索 前言 上次我們說到了源碼里面的調用順序&#xff0c;現在我們繼續了解我們上一篇文章沒有講完的關于對象的內容函數&#xff0c;完整了解對象的產生對于isa賦值以及內存申請的內容 函數內容 先把_objc_rootAllocWithZone函數的內容先貼上…
閱讀更多...
【C++指南】STL list容器完全解讀（一）：從入門到掌握基礎操作

【C++指南】STL list容器完全解讀（一）：從入門到掌握基礎操作

. &#x1f493; 博客主頁&#xff1a;倔強的石頭的CSDN主頁 &#x1f4dd;Gitee主頁&#xff1a;倔強的石頭的gitee主頁 ? 文章專欄&#xff1a;《C指南》 期待您的關注 文章目錄 一、初識list容器1.1 什么是list&#xff1f;1.2 核心特性1.3 典型應用場景 二、核心成員函數…
閱讀更多...
labelimg快捷鍵

labelimg快捷鍵

一、核心標注快捷鍵 ?W?&#xff1a;調出標注十字架&#xff0c;開始繪制矩形框&#xff08;最常用功能&#xff09;?A/D?&#xff1a;切換上一張(A)或下一張(D)圖片&#xff0c;實現快速導航?Del?&#xff1a;刪除當前選中的標注框 二、文件操作快捷鍵 ?CtrlS?&…
閱讀更多...
linux-文件操作

linux-文件操作

在 Linux 系統中&#xff0c;文件操作與管理是日常使用和系統管理的重要組成部分。下面將詳細介紹文件的復制、移動、鏈接創建&#xff0c;以及文件查找、文本處理、排序、權限管理等相關知識。 一、文件的復制 在 Linux 里&#xff0c;cp 命令可用于復制文件或目錄&#xff…
閱讀更多...
C++ 復習

C++ 復習

VS 修改 C 語言標準 右鍵項目-屬性 輸入輸出 //引用頭文件&#xff0c;用<>包裹起來的一般是系統提供的寫好的代碼 編譯器會在專門的系統路徑中去進行查找 #include <iostream> //自己寫的代碼文件一般都用""包裹起來 編譯器會在當前文件所在的目錄中査…
閱讀更多...
openGauss新特性 | HTAP新特性介紹

openGauss新特性 | HTAP新特性介紹

一、行列融合功能簡介 HTAP 行列融合特性在單機、主備場景下&#xff0c;通過節點的行列雙格式內存模式&#xff0c;實現openGauss HTAP一體化數據庫架構。 通過高效的行列轉換技術方案&#xff0c;節點讀取磁盤行存數據&#xff0c;生成列存儲單元&#xff08;Column Unit&am…
閱讀更多...
雙目測量中的將視差圖重投影成三維坐標圖

雙目測量中的將視差圖重投影成三維坐標圖

雙目測距主要步驟如下&#xff1a; 左右兩張圖片 → 匹配 → 得到視差圖 disp&#xff1b; 使用 cv2.reprojectImageTo3D(disp, Q) 將視差圖 重投影 成三維坐標圖 → 得到 points_3d 什么是 points_3d&#xff1f; points_3d cv2.reprojectImageTo3D(disp, Q)points_3d.shap…
閱讀更多...
《深度剖析：SOAP與REST，API集成的兩極選擇》

《深度剖析：SOAP與REST，API集成的兩極選擇》

API作為不同系統之間交互的橋梁&#xff0c;其設計與實現的優劣直接影響著整個軟件生態的運轉效率。而在API的設計領域&#xff0c;SOAP和REST猶如兩座巍峨的山峰&#xff0c;各自代表著截然不同的設計理念與應用方向&#xff0c;成為開發者在構建API時必須慎重權衡的關鍵選項。…
閱讀更多...
非對稱加密算法（RSA、ECC、SM2）——密碼學基礎

非對稱加密算法（RSA、ECC、SM2）——密碼學基礎

對稱加密算法&#xff08;AES、ChaCha20和SM4&#xff09;Python實現——密碼學基礎(Python出現No module named “Crypto” 解決方案) 這篇的續篇&#xff0c;因此實踐部分少些&#xff1b; 文章目錄 一、非對稱加密算法基礎二、RSA算法2.1 RSA原理與數學基礎2.2 RSA密鑰長度…
閱讀更多...
Pillow 玩圖術：輕松獲取圖片尺寸和顏色模式

Pillow 玩圖術：輕松獲取圖片尺寸和顏色模式

前言 在這個“圖像為王”的時代，誰還敢說自己沒被一張圖折磨過？一張圖片不講武德，說崩就崩，說卡就卡，仿佛像素里藏著程序員的眼淚。不管你是網頁設計師、AI煉丹師，還是只是想把貓片修得像藝術品，圖片的尺寸和顏色模式都是你必須掌握的第一手情報。如果你不知道它有多寬…
閱讀更多...
下載core5compat 模塊時，被禁止，顯示 - servese replied: Forbbidden. --＞換鏡像源

下載core5compat 模塊時，被禁止，顯示 - servese replied: Forbbidden. --＞換鏡像源

怎么解決&#xff1f; --->換鏡像源 方法 1&#xff1a;使用命令行參數指定鏡像源 在運行 Qt 安裝器時&#xff0c;通過 --mirror 參數指定鏡像源&#xff1a; # Windows qt-unified-windows-x64-online.exe --mirror https://mirrors.ustc.edu.cn/qtproject# Linux/macO…
閱讀更多...
WPF中Behaviors

WPF中Behaviors

行為的好處 可以把復雜的界面邏輯抽象出去&#xff0c;讓xaml的界面設計更簡單&#xff0c;更清爽 1.安裝包 Microsoft.Xaml.Behaviors.Wpf2.簡單實現拖動效果 <Border Width"100"Height"100"Background"Red"><i:Interaction.Behav…
閱讀更多...
GitHub 趨勢日報 (2025年05月03日)

GitHub 趨勢日報 (2025年05月03日)

本日報由 TrendForge 系統生成 https://trendforge.devlive.org/ &#x1f4c8; 今日整體趨勢 Top 10 排名項目名稱項目描述今日獲星總星數語言1hacksider/Deep-Live-Camreal time face swap and one-click video deepfake with only a single image? 1582? 59337Python2aip…
閱讀更多...
Oracle OCP認證考試考點詳解083系列08

Oracle OCP認證考試考點詳解083系列08

題記&#xff1a; 本系列主要講解Oracle OCP認證考試考點&#xff08;題目&#xff09;&#xff0c;適用于19C/21C,跟著學OCP考試必過。 36. 第36題&#xff1a; 題目 解析及答案&#xff1a; 關于數據庫閃回&#xff08;FLASHBACK DATABASE&#xff09;功能&#xff0c;以下…
閱讀更多...
優化01-統計信息

優化01-統計信息

Oracle 的統計信息是數據庫優化器生成高效執行計劃的核心依據。它記錄了數據庫對象&#xff08;如表、索引、列等&#xff09;的元數據信息&#xff0c;幫助優化器評估查詢成本并選擇最優執行路徑。以下是關于 Oracle 統計信息的詳細介紹&#xff1a; 一、統計信息的分類 表統…
閱讀更多...
動態規劃-面試題08.01三步問題-力扣(LeetCode)

動態規劃-面試題08.01三步問題-力扣(LeetCode)

一、題目解析 此題可以類比第N個泰波那契數 二、算法解析 1、狀態表示 根據上面的分析和題目要求&#xff0c;dp[i]表示&#xff1a;到達i位置&#xff0c;一共有多少種方法 2、狀態轉移方程 以i位置的狀態&#xff0c;以最近一步劃分問題 dp[i] 從i-1->i dp[i-1] 從…
閱讀更多...
kotlin中枚舉帶參數和不帶參數的區別

kotlin中枚舉帶參數和不帶參數的區別

一 ? 代碼對比總結 第一段&#xff08;帶參數 工具方法&#xff09; enum class SeatPosition(val position: Int) {DRIVER_LEFT(0),DRIVER_RIGHT(1),SECOND_LEFT(2),SECOND_RIGHT(3);companion object {fun fromPosition(position: Int): SeatPosition? {return SeatPosi…
閱讀更多...
Java使用JDBC操作數據庫

Java使用JDBC操作數據庫

1.創建一個數據庫一會用來連接 2.使用idea新建一個Java項目 3.在pom文件中加上相關依賴&#xff0c;并配置Maven路徑 <dependencies><dependency><groupId>mysql</groupId><artifactId>mysql-connector-java</artifactId><version>…
閱讀更多...
重名導致does not name a type

重名導致does not name a type

今天在Ubuntu24.04上編成時&#xff0c;makefile編譯報錯: falsecolor.h:48:9: error: ‘FalseColor’ does not name a type48 | FalseColor* content ;| ^~~~~~~~~~falsecolor.h的部分代碼如下: class FalseColor {public:FalseColor(int w, int h){width …
閱讀更多...
最新文章

Copyright @ 2022~2023