当饼干遇上代码：一场HTTP与Cookie的奇幻漂流 🍪🌊

我想说一句
0 阅读6分钟

各位程序美食家们，今天我们要品尝一道经典菜肴——Node.js夹心饼干（Cookie）配HTTP浓汤！别看这组合简单，里面可是暗藏玄机，保证让你吃得开心，学得过瘾~

🧩 第一章：模块化的"左右互搏术"

在Node.js的江湖里，模块化有两种绝世武功：

// ES6派 - 优雅的"玉女剑法"
import http from 'http';

// CommonJS派 - 稳重的"降龙十八掌"
const http = require('http');

有趣的是，这两大门派如今在Node.js的擂台上和平共处了！就像咖啡配油条，看似不搭却意外和谐。Node 22版本开始，.js文件也能愉快地使用ES6模块化，再也不用为了后缀名打架了~

🚀 第二章：HTTP服务器的"开箱即用"

创建HTTP服务器比煮方便面还简单！只需要三步：

  1. 导入HTTP模块（选你喜欢的姿势）
  2. 创建服务器（给它个回调函数当"大脑"）
  3. 启动监听（找个没人占用的港口）
const server = http.createServer((req, res) => {
    res.end('你好，HTTP世界！')
});
server.listen(1234); // 占领1234港口！

端口号就像公寓门牌号：3306住着MySQL，8080住着我们的Node应用。记住千万别乱敲别人家的门（比如80端口），小心被系统保安赶出去！

🧭 第三章：路由侦探的"寻宝地图"

服务器如何知道用户想要啥？全靠路由这个"寻宝地图"：

if (req.method == 'GET' && req.url == '/style.css') {
    // 送上时尚的CSS外套
}

if (req.method == 'POST' && req.url == '/login') {
    // 检查秘密口令（账号密码）
}

URL就像快递地址：http://localhost:8080/style.css?a=1&b=2中：

  • http是运输车
  • localhost是城市名
  • 8080是小区门牌
  • /style.css是具体房间
  • ?a=1&b=2是快递备注

简单来说就是 协议 + 域名 + 端口号 + 资源 + 参数

📦 第四章：文件管家的"百宝箱"

Node.js自带三位文件管家天团：

const fs = require('fs'); // 文件搬运工
const path = require('path'); // 路径导航员

看他们如何默契配合：

fs.readFile(path.join(__dirname, 'public', 'index.html'), 
    (err, content) => {
        if (err) {
            res.writeHead(500); // 举起错误红灯
            res.end('服务器打了个喷嚏🤧');
            return;
        }
        res.writeHead(200, { 'Content-Type': 'text/html' });
        res.end(content); // 送上热腾腾的HTML大餐
});

特别提醒：__dirname是管家的GPS定位仪，永远知道当前文件夹在哪，再也不会迷路啦！任何通过path的join方法，把路径拼接，这样就得到了完整的访问路径

🍪 第五章：Cookie的"记忆饼干"

HTTP协议有个"健忘症"——它记不住你是谁！也就是HTTP协议是无状态的，不能识别用户身份，于是Cookie应运而生：

// 服务器发饼干
res.writeHead(200, {
    'Set-Cookie': 'user=admin;', // 新鲜出炉的饼干！
    'Content-Type': 'application/json'
});

// 客户端下次就会带着饼干罐子来
if (req.headers.cookie) {
    console.log('哇！有饼干吃！'); // 识别老顾客
}

Cookie工作原理就像咖啡店会员卡：

  1. 首次登录：店家给你一张会员卡（Set-Cookie）
  2. 再次光临：出示会员卡（自动携带Cookie）
  3. 店家就能喊出："王先生，还是美式咖啡吗？"

http协议是无状态的，所以是不能识别用户的身份的，就像你访问WWW.baidu.com 每个人访问的结果都是一样的

Cookie就是服务器发放给我们的，就是一个身份认证，简单来说，就是每一个用户登录后，界面都是不一样的，这都依靠于Cookie的身份认证，大家可以想想，为什么我们登录后掘金网页，如果我们下次再访问，是不是不用再登录了，这一切都是Cookie的功劳，因为服务器已经识别了我们的身份

那么为什么有了Cookie还说http协议是无状态的呢？因为要识别身份，需要带上Cookie，如果说http协议是有状态的，那也就不需要Cookie的协助了

Cookie在哪查看呢？其实Cookie就存放在本地浏览器 image.png

🤝 第六章：前后端的"加密通话"

前端如何优雅地"撩"后端？看这段调情代码：

 if (req.method == 'GET' && req.url == '/check-login') {
        // 怎么证明登录了?
        if (req.headers.cookie) {
            res.writeHead(200, {
                'Content-Type': 'application/json'
            })
            res.end(JSON.stringify({
                loggedIn: true,
                username: 'admin'
            }))
        } else {
            res.writeHead(200, {
                'Content-Type': 'application/json'
            })
            res.end(JSON.stringify({
                loggedIn: false,
                username: ''
            }))
        }


    }

检查登录状态就像查岗：

const response = await fetch('/check-login');
const data = await response.json();

if (data.loggedIn) {
    showWelcomeMessage(); // 亲爱的你来了~
} else {
    showLoginForm(); // 哼！又忘记我是谁了？
}

有Cookie就会显示独属于你的页面状态

🎭 第七章：前端界面的"变脸戏法"

我们的HTML页面是个川剧变脸大师：

<!-- 登录面具 -->
<section id="loginSection" style="display: none;">
    <form id="loginForm">...</form>
</section>

<!-- 欢迎面具 -->
<section id="welcomeSection" style="display:none;">
    <p>Welcome, <span id="userDisplay"></span></p>
</section>

JavaScript就是幕后操纵师：

// 登录按钮触发变脸
document.getElementById('loginBtn').addEventListener('click', () => {
    document.getElementById('loginSection').style.display = 'block';
});

// 登录成功后二次变脸
if (data.loggedIn) {
    document.getElementById('loginSection').style.display = 'none';
    document.getElementById('welcomeSection').style.display = 'block';
}

这里我们做了一个简单的演示，一但有Cookie了，我们就把登录框隐藏，简单的模拟了Cookie的效果

当然Cookie这么好，也存在网络安全方面的危害

Cookie 的核心危害

  1. 会话劫持 (Session Hijacking)

    • 原理：攻击者窃取用户的会话 Cookie（如 SessionID），冒充用户身份登录账户。
    • 风险：无需密码即可操控账户（如转账、发消息、窃取数据）。

  2. 跨站脚本攻击 (XSS) 窃取 Cookie

    • 原理：黑客在网页注入恶意脚本，当用户访问时，脚本自动窃取 Cookie 并发送到攻击者服务器。
    • 风险：大规模用户会话泄露。

  3. 跨站请求伪造 (CSRF)

    • 原理：诱导用户点击恶意链接，利用浏览器自动携带 Cookie 的特性，以用户身份执行非授权操作（如修改密码）。
    • 风险：用户在不知情时账户被篡改。

  4. 敏感信息泄露

    • 原理：Cookie 未加密存储敏感数据（如身份证号、地址），可能被中间人攻击窃取。
    • 风险：违反隐私法规（如 GDPR），导致法律纠纷。

就比如以下案例

Facebook 数据泄露与剑桥分析（2018）

  • 事件：第三方应用通过 Facebook 登录 Cookie 收集 8700 万用户数据，用于政治广告精准推送。
  • 后果：Facebook 被罚款 50 亿美元，引发全球对数据滥用的声讨。
  • 原因：过度开放的第三方 Cookie 权限导致数据违规共享。

所以Cookie的存在是一把双刃剑，有利有弊

🌟 终章：从饼干盒到宇宙

今天我们完成了奇妙的HTTP之旅：

  1. 用两种模块化姿势启动服务器
  2. 设计智能路由分发请求
  3. 用文件系统提供静态资源
  4. 烤制记忆饼干（Cookie）维持状态
  5. 实现前后端加密通信
  6. 打造会变脸的交互界面

最后分享一个程序员冷笑话：

为什么Cookie不敢一个人走夜路？
因为它怕被劫持（Cookie Hijacking）！

记住：小小的饼干（Cookie）承载着HTTP无状态协议的智慧。下次当你咬下一块饼干时，不妨想想——这可能是某个程序员用代码烘焙的记忆魔法呢！

avatar
文章
阅读
粉丝