目录

• MIME 类型
• 请求头
• 响应头
• 通用头
• URL 编码
• HTTPS

MIME 类型

• 通用结构：type/subtype，MIME类型对大小写不敏感，但是传统写法都是小写。
• text/plain 表示文本文件的默认值。
• application/octet-stream 表示所有其他情况的默认值。
• 超文本标记语言文本 .html、.html：text/html
• GIF 图形 .gif： image/gif
• JPEG 图形 .jpeg、.jpg： image/jpeg
• au 声音文件 .au： audio/basic

MIME对照表

请求头

响应头

HTTP通用头部参数对照表

详细解释

http 请求方式

• 当后端使用 @RequestParam 接收参数，这意味着它期望参数是通过 URL 查询字符串传递的（即 ?id=1&name=zmy...），
  • 对于 GET 方法，当后端发起 http 请求时，直接将参数拼接在 url 后面
  • 对于 POST 方法，也是直接将参数拼在后面，请求方法设为 POST 即可
• 当后端使用 @RequestBody 介绍参数，这意味着它期望从请求体中获取参数，使用json格式传输
• 前端使用 POST 下载文件

fetch('/download', {
  method: 'POST',
  body: JSON.stringify({ startDate: "2024-01-01", format: "PDF" }),
  headers: { 'Content-Type': 'application/json' }
}).then(response => response.blob().then(blob => {
  const url = URL.createObjectURL(blob);
  const a = document.createElement('a');
  a.href = url;
  a.download = 'report.pdf';
  a.click();
}));

• 后端需要设定响应的响应头：
  • Content-Disposition 强制浏览器下载（而非预览）：attachment; filename="example.zip"
  • Content-Type 指定文件类型（MIME）：application/octet-stream（通用二进制流）application/pdf（PDF专用）

Content-Type: application/octet-stream  # 确保二进制处理
Content-Disposition: attachment; filename="custom-name.ext"  # 确保下载和文件名

@GetMapping("/download/file")
public ResponseEntity<Resource> downloadFile() throws IOException {
    // 1. 读取文件
    Path filePath = Paths.get("/data/reports/report.pdf");
    Resource resource = new FileSystemResource(filePath);

    // 2. 设置响应头
    return ResponseEntity.ok()
            .header(HttpHeaders.CONTENT_DISPOSITION, 
                    "attachment; filename=\"" + filePath.getFileName() + "\"")
            .header(HttpHeaders.CONTENT_TYPE, Files.probeContentType(filePath))
            .header(HttpHeaders.CONTENT_LENGTH, String.valueOf(Files.size(filePath)))
            .header(HttpHeaders.CACHE_CONTROL, "no-cache, no-store, must-revalidate")
            .body(resource);
}
// 如果文件名包含中文或特殊字符，需要额外处理：
String encodedFileName = URLEncoder.encode("中文文件.pdf", StandardCharsets.UTF_8)
        .replaceAll("\\+", "%20"); // 替换空格编码
response.setHeader("Content-Disposition", "attachment; filename*=UTF-8''" + encodedFileName);

• Content-Disposition 取值：
  • inline 默认值。响应体应被内联显示（如浏览器直接展示图片/PDF）。尝试在页面中预览内容。
  • attachment 强制客户端下载文件而非预览。 弹出下载对话框，保存文件到本地。浏览器将使用URL的最后一段作为文件名
  • attachment; filename="report.pdf" 指定下载时的默认文件名（避免服务端URL中的随机字符）。下载的文件名显示为 report.pdf。
  • attachment; filename*=UTF-8''%E4%B8%AD%E6%96%87.txt 支持编码的非ASCII文件名（如中文）。UTF-8'' 是固定前缀。下载的文件名显示为 中文.txt。
  • filename 仅支持 ASCII 字符。如果包含中文等非 ASCII 字符，必须使用 URL 编码（Percent-encoding）。兼容性极好，所有现代浏览器和旧版浏览器都支持
  • filename* 支持 RFC 5987 标准，使用 UTF-8 编码，能直接处理中文、日文、表情符号等特殊字符。现代浏览器支持（Chrome, Firefox, Edge 等），但部分旧版浏览器（如 IE 旧版）可能不支持
  • 建议两者都设置，这是一种被称为 “回退机制” 的最佳实践。现代浏览器会优先识别并采用 filename* 的值（因为它支持 UTF-8，显示效果最好），而如果遇到不支持 filename* 的旧版浏览器，它会自动忽略 filename*，转而使用 filename 的值，从而保证文件名的正常显示

URL 编码

• 也称为百分号编码或 % 编码，用于在 URL 中表示那些在 URL 中有特殊意义或无法直接在 URL 中使用的字符。URL 编码的主要目的是确保 URL 能够在互联网上传输，并被正确解析。URL 解码则是将编码后的字符串还原成原来的字符。

• URL 编码的规则：% 加十六进制 ASCII 码值

• 安全字符：这些字符可以直接在 URL 中使用，不需要编码。包括字母 A-Z、a-z、数字 0-9 以及 - _ . ~。

• 保留字符：这些字符在 URL 中有特殊的含义，通常用于分隔 URL 的各个部分。保留字符包括：

  • newline: %0A or %0D or %0D%0A \n \r \r\n
  • space: %20
  • !: %21
  • #: %23
  • $: %24
  • %: %25
  • &: %26
  • ': %27
  • (: %28
  • ): %29
  • *: %2A
  • +: %2B
  • ,: %2C
  • /: %2F
  • :: %3A
  • ;: %3B
  • =: %3D
  • ?: %3F
  • @: %40
  • [: %5B
  • ]: %5D

• 不可打印的 ASCII 字符（控制字符）：这些字符包括 ASCII 码小于 32 或大于 126 的字符，通常需要编码。控制字符的编号范围是 0-31 和 127（0x00-0x1F 和 0x7F），共 33 个字符。

• 未保留字符：这些字符可以直接在 URL 中使用，不需要编码。未保留字符包括：

  • 英文字母 A-Z、a-z
  • 数字 0-9
  • -（连字符）
  • _（下划线）
  • .（点）
  • ~（波浪线）

• 常用的编码及对应的码值(10进制)：

HTPS

• 电脑上有内置的 CA 机构的公钥，浏览器先向服务器申请证书，这个证书由 CA 颁发，其中包含：证书机构，过期时间，服务器公钥，签名等，签名就是对这些信息做个校验，得到校验和，使用 CA 的私钥对校验和进行加密，然后客户端使用内置的 CA 机构的公钥进行解密，得到校验和，然后自己再按算法对证书全部内容（TBS）计算校验和，查看是否和解密得到的校验和一致，一致则说明证书没有被更改，说明服务器公钥是正确的，然后客户端生成一个随机数（预主密钥），使用服务器公钥加密，将其发送给服务器，服务器使用私钥进行解密，然后通过这个预主密钥交换其他信息得到会话密钥，然后接下来双方使用会话密钥进行对称加密，进行数据传输。

• 证书签名过程：

  • CA 收到你的 CSR（证书请求）
  • CA 生成一个新证书，包含：
    • 你的身份信息（CN=yuanbao.tencent.com）
    • 你的公钥（使用者公钥）
    • 有效期时间
    • 发行者（CA 名称）
  • CA 对这个证书的 全部内容（TBS, To Be Signed）做哈希
  • 用 CA 的 私钥 对哈希值进行加密 → 得到 证书签名值
  • 把签名值写入证书

• 验证过程（客户端）：

  • 客户端收到证书
  • 查找 CA 的公钥（从信任库中，如 cacerts）
  • 用 CA 的公钥 解密 “证书签名值” → 得到一个哈希值 A
  • 客户端自己对证书的 TBS 内容 做哈希 → 得到哈希值 B
  • 比较 A 和 B 是否相等
  • 如果相等 → 签名有效，证书未被篡改

• 下面是一个证书信息：

  • 使用者公钥 = 服务器的公钥（Public Key）
  • 证书签名值 = CA 用自己的私钥对证书内容进行加密的结果（证书签名值 = CA 私钥(Hash(证书内容))）

整个HTTPS过程

阶段 1：客户端发起连接 → ClientHello，client_random：用于后续密钥派生

Client → Server:
  - 支持的 TLS 版本（如 TLS 1.2）
  - client_random（32 字节随机数，明文）
  - 支持的加密套件列表：
      TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
      TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
      ...
  - 支持的压缩方法
  - Server Name Indication (SNI): 192.168.66.162（可选）

阶段 2：服务器响应 → ServerHello 到 ServerHelloDone\

• 2.1 ServerHello

Server → Client:
  - 选定的 TLS 版本（如 TLS 1.2）
  - server_random（32 字节随机数，明文）
  - 选定的加密套件：TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  - 选定的压缩方法

• 2.2 Certificate

Server → Client:
  - 发送自己的证书链（你的 `tomcat.keystore` 中的证书）
    包含：
      - 主体：CN=zhumengyu, IP=192.168.66.162
      - 公钥（RSA 公钥）
      - 签名算法
      - 扩展：SAN=IP:192.168.66.162

• ✅ 客户端开始验证：
  • 证书是否可信（是否在信任库中）
  • 是否过期
  • 主机名是否匹配（IP 匹配 SAN）
• 2.3 ServerKeyExchange（关键！ECDHE 参数）

Server → Client:
  - 椭圆曲线参数（如 secp256r1）
  - 服务器的临时公钥（ECDHE 公钥）
  - 签名：用服务器的 RSA 私钥对（曲线参数 + 临时公钥）签名

• 🔐 为什么签名？
  • 防止中间人篡改 ECDHE 参数
  • 客户端用证书中的 RSA 公钥验证签名
• 2.4 CertificateRequest（可选）

Client → Server 证书（用于双向认证 mTLS）

• 2.5 ServerHelloDone

Server → Client: “我的消息发完了”

阶段 3：客户端响应

• 3.1 验证服务器证书 ✅
  • 检查信任链
  • 检查有效期
  • 检查 SAN 是否包含 192.168.66.162
  • 用 RSA 公钥验证 ServerKeyExchange 的签名
  • ❌ 如果失败 → 中断连接
  • ✅ 如果成功 → 继续
• 3.2 生成 ECDHE 共享密钥 K
  • 客户端生成自己的临时 ECDHE 密钥对
  • 用自己的临时私钥 + 服务器的临时公钥 → 计算出 pre_master_secret（共享密钥 K）
• 3.3 ClientKeyExchange

Client → Server:
  - 发送客户端的临时 ECDHE 公钥

• ✅ 服务器收到后：
  • 用自己的临时私钥 + 客户端公钥 → 计算出相同的 K
• 3.4 CertificateVerify（可选，mTLS）
• 3.5 ChangeCipherSpec ⚠️ 这是一个独立的协议层消息，不是 TLS 记录

Client → Server: “从现在开始，我用加密通信”

• 3.6 Finished

Client → Server:
  - 发送一条“加密的验证消息”
  - 内容是：对之前所有握手消息的哈希（HMAC）
  - 使用刚刚派生的密钥加密

• 🔐 作用：
  • 验证密钥是否一致
  • 验证握手过程未被篡改

阶段 4：服务器完成握手

• 4.1 ChangeCipherSpec

Server → Client: “我也开始加密通信”

• 4.2 Finished

Server → Client:
  - 发送加密的验证消息（对所有握手消息的哈希）
  - 使用派生的密钥加密

• ✅ 客户端解密并验证：
  • 如果成功 → 握手完成
  • 如果失败 → 中断连接

阶段 5：加密应用数据传输

• HTTP Request（加密）

Client → Server:
  - 加密的 HTTP 请求（如 GET /app/login）
  - 使用 AES-GCM 加密
  - 每条消息有 MAC（GCM 模式自带认证）

• HTTP Response（加密）

Server → Client:
  - 加密的响应（如 200 OK + HTML）

密钥派生全过程（关键！）

• 双方使用以下输入生成最终密钥：

pre_master_secret = ECDHE_shared_secret (K)

master_secret = PRF(pre_master_secret, "master secret",
                    client_random + server_random)
                [48 bytes]

key_block = PRF(master_secret, "key expansion",
                 server_random + client_random)

• 从 key_block 中提取：
  • 客户端写密钥（16 字节 AES-128）
  • 服务器写密钥（16 字节）
  • 客户端写 IV（12 字节，GCM 模式）
  • 服务器写 IV（12 字节）

HTTP请求问题

• unable to find valid certification path to requested target 是证书信任问题
• 信任所有证书，跳过主机名验证

private static CloseableHttpClient createHttpClient() {
    SSLContext sslContext = null;
    try {
        // 1. 创建一个信任所有证书的 SSLContext
        sslContext = SSLContextBuilder.create().loadTrustMaterial(null, new TrustStrategy() {
            @Override
            public boolean isTrusted(X509Certificate[] chain, String authType) {
                return true; // 信任所有证书
            }
        }).build();
    } catch (Exception e) {
        logger.error("创建SSLContext异常", e);
        throw new RuntimeException(e);
    }

    // 2. 创建一个跳过主机名验证的 HostnameVerifier
    HostnameVerifier hostnameVerifier = (hostname, session) -> true;

    // 3. 创建 SSLConnectionSocketFactory，并传入 hostnameVerifier
    SSLConnectionSocketFactory sslFactory = new SSLConnectionSocketFactory(
        sslContext,
        hostnameVerifier  // ⚠️ 关键：必须传入这个参数！
    );

    return HttpClients.custom()
        .setSSLSocketFactory(sslFactory)
        .build();
}

• 信任特定证书

private static SSLConnectionSocketFactory createSSLConnSocketFactory() throws Exception {
    // 1. 加载你的自签名证书（从 .jks 或 .p12 文件）
    FileInputStream fis = new FileInputStream("conf/tomcat.keystore");
    KeyStore trustStore = KeyStore.getInstance("PKCS12"); // 或 JKS
    trustStore.load(fis, "changeit".toCharArray()); // 密码
    fis.close();

    // 2. 构建 SSLContext，只信任这个 KeyStore 中的证书
    SSLContext sslContext = SSLContextBuilder.create()
        .loadTrustMaterial(trustStore, null) // 只信任 keystore 中的证书
        .build();

    return new SSLConnectionSocketFactory(sslContext);
}

• loadTrustMaterial(trustStore, null) 把自定义证书当成了“TrustStore”（信任库），但它的角色其实是“密钥库”（KeyStore），并且你没有正确地将其中的证书提取出来用于信任验证。

// 从 keystore 中提取出服务器证书
Certificate cert = keyStore.getCertificate("tomcat"); // 别名是 tomcat

// 创建一个 TrustStrategy，只信任这个证书
TrustStrategy trustStrategy = (chain, authType) -> {
    if (chain == null || chain.length == 0) return false;
    return chain[0].equals(cert); // 只信任这个证书
};

• 生成证书信任指定IP

keytool -genkeypair `
        -alias tomcat `
        -keyalg RSA `
        -keysize 2048 `
        -storetype PKCS12 `
        -keystore tomcat.keystore `
        -validity 365 `
        -dname "CN=zhumengyu, OU=CETC, O=WA, L=Nanjing, ST=Jiangsu, C=CN" `
        -ext "SAN=IP:192.151.20.2,IP:192.151.20.3,DNS:localhost,DNS:myapp.local" `
        -storepass changeit `
        -keypass changeit

• 查看证书：keytool -list -v -keystore tomcat.keystore -alias tomcat

• 常见的证书格式及其特点

证书常用命令

# OpenSSL 生成自签名证书（PEM 格式）
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem \
            -days 365 -nodes -subj "/CN=localhost"

# 查看证书内容
openssl x509 -in cert.pem -text -noout
# 查看私钥内容
openssl rsa -in key.pem -check -noout

# 使用openssl导出站点证书
openssl s_client -connect your-ip:port -showcerts </dev/null 2>/dev/null | openssl x509 -outform PEM > besland_cert.pem

# 生成证书指纹
openssl x509 -in tomcat.crt -fingerprint -sha256 -noout
 
# 转换 DER 到 PEM
openssl x509 -inform der -in cert.der -out cert.pem

# 将 PEM 转为 PKCS12
openssl pkcs12 -export -in cert.pem -inkey key.pem -out keystore.p12 -name "tomcat"

# 导出CSR 提交给 CA 后，CA 返回正式证书
openssl req -new -newkey rsa:2048 -nodes -keyout domain.key -out domain.csr

#从 PEM 转为 JKS（用于 Tomcat）
# 1. 合并证书链（可选）
cat domain.crt intermediate.crt > fullchain.pem
# 2. 转为 PKCS12
openssl pkcs12 -export -in fullchain.pem -inkey domain.key \
               -out keystore.p12 -name "tomcat"
# 3. 转为 JKS（或直接在 Tomcat 中用 P12）
keytool -importkeystore -srckeystore keystore.p12 -srcstoretype PKCS12 \
        -destkeystore keystore.jks -deststoretype JKS
        
# keytool 生成PKCS证书
keytool -genkeypair `
        -alias tomcat `
        -keyalg RSA `
        -keysize 2048 `
        -storetype PKCS12 `
        -keystore tomcat.keystore `
        -validity 365 `
        -dname "CN=zhumengyu, OU=CETC, O=WA, L=Nanjing, ST=Jiangsu, C=CN" `
        -ext "SAN=IP:192.151.20.2,IP:192.151.20.3,DNS:localhost,DNS:myapp.local" `
        -storepass changeit `
        -keypass changeit
# keytool 查看证书
keytool -list -v -keystore tomcat.keystore -alias tomcat

# keytool 导出证书
keytool -exportcert -keystore tomcat.keystore -alias tomcat -storepass changeit -file temp.crt

# 导入证书（默认密码: changeit）
# 找到JRE的cacerts文件位置
# 通常位于 $JAVA_HOME/lib/security/cacerts
keytool -import -alias besland -keystore $JAVA_HOME/lib/security/cacerts -file besland_cert.pem

#使用 openssl 工具来转换 PKCS12 文件（.keystore）为 PEM 格式：
# 1. 提取证书（cert.pem）
# -nokeys：不导出私钥，只导出证书。
# -passin pass:changeit：指定密钥库密码（changeit 是你设置的密码）。
openssl pkcs12 -in tomcat.keystore -nokeys -out cert.pem -passin pass:changeit

# 2. 提取私钥（key.pem）
# -nocerts：不导出证书，只导出私钥。
# -nodes：不加密私钥（否则会要求输入新的密码）。
openssl pkcs12 -in tomcat.keystore -nocerts -out key.pem -passin pass:changeit -nodes

• tomcat.keystore 是一个 密钥库（Keystore），它是一个“容器”，可以存储：
  • PrivateKeyEntry：私钥 + 证书链（最常见）
  • TrustedCertificateEntry：只包含一个受信任的 CA 证书（不包含私钥）
• java 本身包含的 $JAVA_HOME/lib/security/cacerts 中只有 TrustedCertificateEntry，存放 Java 默认信任的权威 CA 证书。当使用程序访问 HTTPS 网站时，Java 会用它来验证服务器证书是否由可信 CA 签发。而tomcat.keystore 是由服务端的tomcat使用，cacerts 作为 Java 应用（作为客户端）使用

🔍 一、先看「签名」到底做了什么？ 假设你有一段数据 M（比如一个文件、一条消息），你想向全世界证明： 这条消息是我发的（身份认证） 消息在传输中没被篡改（完整性） 📝 签名的标准流程（以 RSA 为例）： 步骤 1️⃣：计算哈希（Hash） text

编辑

H = SHA256(M) 把任意长度的消息压缩成固定长度的“数字指纹”（如 256 位） 哈希不可逆，且微小改动会导致哈希巨变 步骤 2️⃣：用私钥对哈希进行“签名运算” text

编辑

Signature = RSA_Sign(H, 私钥) 这一步看起来像“加密”，但密码学上叫 “签名生成” 实际实现可能是：对哈希值做 RSA 私钥运算（带填充，如 PSS 或 PKCS#1 v1.5） 步骤 3️⃣：把 原始消息 M + 签名 Signature 一起发送出去 📌 注意：原始消息 M 是明文！没有被加密！ 🔐 二、别人怎么验证？ 接收方拿到 (M, Signature) 后： 步骤 1️⃣：用同样的哈希算法计算 H' = SHA256(M) 步骤 2️⃣：用你的公钥对 Signature 做“验签运算” text

编辑

H'' = RSA_Verify(Signature, 公钥) 步骤 3️⃣：比较 H' 和 H'' 如果相等 → 消息确实来自你，且未被篡改 ✅ 如果不等 → 要么消息被改，要么签名是伪造的 ❌