Linux 下 HTTP 会话机制实战：Cookie 与 Session 原理及 C++ 实现

测试验证：

• 交互验证：首次输入正确密码后，服务器返回 Set-Cookie，后续请求即使不传密码也能成功访问，证明 Cookie 被浏览器自动携带。
• 过期验证：等待 5 分钟后，Cookie 失效，访问返回 404。
• 路径限制：修改 path 属性后，仅在特定路径下 Cookie 才会生效。

二、Session 机制详解

1. 为什么需要 Session？

虽然 Cookie 解决了部分状态保持问题，但数据存储在客户端仍不安全。Session 将敏感数据保存在服务端，客户端仅持有唯一的 Session ID（通常通过 Cookie 传递）。这样即使 Cookie 被盗，黑客也无法直接获取用户隐私数据，只能冒充身份直到 Session 过期。

2. 工作流程

1. 创建 Session：用户首次登录，服务器生成唯一 Session ID，将用户信息存入服务端内存/数据库。
2. 下发 ID：服务器将 Session ID 作为 Cookie 发送给浏览器。
3. 身份识别：后续请求携带 Session ID，服务器查找对应资源确认身份。

3. C++ 模拟实现

我们需要一个全局管理器来维护 Session ID 与用户资源的映射关系。

Session 类设计：

class session {
public:
    session(const string& username, const string& status)
        :_username(username), _status(status) {
        _create_time = time(nullptr);
        _terminal_time = _create_time + 300; // 默认 5 分钟过期
    }
    string _username;
    string _status;
    uint64_t _create_time;
    uint64_t _terminal_time;
};

Session 管理器：

class session_manager {
public:
    string add_session(session_ptr s) {
        uint32_t randomid = rand() + time(nullptr);
        string sessionid = std::to_string(randomid);
        _sessions.insert(std::make_pair(sessionid, s));
        return sessionid;
    }
    session_ptr get_session(string sessionid) {
        if(_sessions.find(sessionid) == _sessions.end()) return nullptr;
        return _sessions[sessionid];
    }
private:
    unordered_map<string, session_ptr> _sessions;
};

验证逻辑：

// 检查 Session 是否存在且未过期
if(!re.get_password().empty()) {
    session_ptr sn = ursm->get_session(re.get_password());
    if(sn && sn->_terminal_time > time(nullptr)) {
        // Session 有效，直接放行
        res.set_route("./wwwroot/video.html");
        goto again;
    } else {
        // 过期或不存在
        res.set_route("./wwwroot/404.html");
    }
} else {
    // 首次登录，创建 Session
    if(pw == "666") {
        session_ptr sn = make_shared<session>(user, "login");
        string sessionid = ursm->add_session(sn);
        res.set_cookie_session(sessionid);
        res.set_route("./wwwroot/video.html");
    }
}

测试验证：

• 免密登录：首次登录后，后续请求无需密码即可访问，因为 Session ID 已验证身份。
• 过期处理：超过设定时间后，Session 失效，强制重新登录。
• 服务重启：若服务器重启，内存中的 Session 丢失，导致 Cookie 中的 ID 失效，需重新登录。

4. 常见 Bug 与解决方案

在实际工程化过程中，可能会遇到以下问题：

• Bug 1：服务重启导致 Session 丢失。由于 Session 通常存储在内存中，进程重启后数据清空。解决方案是将 Session 持久化到 Redis 或数据库中。
• Bug 2：多进程环境下的数据隔离。如果 HTTP 服务器采用多进程模型（如 fork），子进程会复制父进程的内存空间，但 Session 管理器的哈希表可能因进程隔离而无法共享。解决方案是使用单进程模型进行测试，或在生产环境中引入线程池/共享内存机制。

三、总结

Cookie 和 Session 是 Web 会话管理的基石。Cookie 负责在客户端存储标识，Session 负责在服务端维护状态。两者结合使用，既保证了用户体验的连续性，又提升了数据的安全性。但在实际开发中，仍需注意 HTTPS 加密、HttpOnly 标志以及 Session 超时策略，以防范中间人攻击和会话劫持。