Appearance
网络通信
网络通信相关知识
HTTP和HTTPS
HTTP和HTTPS是构建现代Web通信的基石协议。
工作原理与安全性
HTTP 的工作方式非常简单直接:客户端(如浏览器)通过TCP连接(默认端口80)向服务器发送一个明文请求,服务器处理后再返回一个明文响应。这种透明性意味着数据在传输过程中的每一个中间环节都可能被查看或修改。
HTTPS 则通过引入 SSL/TLS协议 在HTTP和TCP之间建立了一个安全层,其核心过程(SSL/TLS握手)如下:
客户端Hello:客户端向服务器发送支持的SSL/TLS版本、加密算法列表和一个随机数。
服务器Hello:服务器选择加密算法,并发送自己的数字证书(包含公钥)和另一个随机数。
验证与预主密钥:客户端验证证书的合法性(颁发机构、有效期等)。验证通过后,会生成一个预主密钥,并用服务器的公钥加密后发送给服务器。
生成会话密钥:服务器用自己的私钥解密得到预主密钥。随后,客户端和服务器利用之前交换的两个随机数和这个预主密钥,独立计算出相同的会话密钥。
安全通信:此后,双方使用这个对称的“会话密钥”对传输的数据进行加密和解密。
这种方式巧妙地结合了非对称加密(安全性高,用于交换密钥)和对称加密(速度快,用于加密大量数据),在安全与效率之间取得了平衡。
优缺点与适用场景
HTTP的优缺点:优点是简单高效,没有加密解密的计算开销,响应速度快。其最显著的缺点是安全性极差,不适合传输任何敏感信息。现代浏览器通常会将纯HTTP网站标记为“不安全”。
HTTPS的优缺点:优点是安全性高,提供了数据加密、完整性校验和身份认证三大保障。此外,它还能提升网站在搜索引擎中的排名并增加用户信任度。缺点主要在于性能开销(但通过HTTP/2、TLS会话恢复等技术已大幅优化)和部署成本(需要申请和维护SSL证书)。
开发须知
混合内容阻塞: 当一个HTTPS页面内通过HTTP协议加载脚本、样式表、图片等子资源时,被称为“混合内容”。现代浏览器默认会阻塞这些不安全的HTTP请求,导致页面功能异常。因此,务必确保页面内所有资源的协议都是HTTPS或使用相对路径(如//example.com/resource.js)。
开发与部署:在开发阶段,可以使用自签名证书在本地启用HTTPS进行测试。部署时,则需要从可信的证书颁发机构(CA)为你的域名获取有效的SSL证书。
SSL/TLS
SSL/TLS 是现代互联网通信安全的基石。为了帮你快速建立整体认知,下面这个表格汇总了它的核心信息。
| 核心维度 | 关键说明 |
|---|---|
| 名字与缩写 | SSL (Secure Sockets Layer, 安全套接层) 和 TLS (Transport Layer Security, 传输层安全协议) |
| 核心目标 | 为网络通信提供加密、身份认证和数据完整性保障 |
| 协议关系 | TLS 是 SSL 的标准化和升级版,两者本质是同一技术的不同发展阶段,常被统称为 SSL/TLS |
| 工作原理(精要) | 1. 握手阶段:使用非对称加密(如RSA、ECDHE)安全地协商出一个仅双方知晓的“会话密钥”。 2. 通信阶段:使用第一步生成的“会话密钥”进行高效的对称加密(如AES)来传输实际数据。 |
| 关键作用 | - 加密防窃听:数据以密文传输,防止被窃听。 - 身份防冒充:通过数字证书验证服务器身份,防止钓鱼网站。 - 防篡改保完整:通过摘要算法确保数据在传输过程中未被修改。 |
| 最典型应用 | HTTPS,即 HTTP over SSL/TLS,为普通网页浏览加上安全锁。 |
💡 拓展理解
从SSL到TLS的演进:SSL 由网景公司于90年代中期推出,经历了 SSL 1.0/2.0/3.0 版本。由于安全性问题,IETF 在1999年将 SSL 3.0 标准化并更名为 TLS 1.0。此后,TLS 不断发展,陆续发布了更安全、更高效的 TLS 1.1、1.2 以及目前的 1.3 版本。因此,现在通常推荐使用 TLS 这个名称。
数字证书的关键角色:SSL/TLS 中的身份认证依赖于数字证书。它就像服务器的“网络身份证”,由受信任的第三方机构(Certificate Authority, CA)颁发,其中包含了服务器的公钥和身份信息。浏览器会验证这张证书是否有效且可信,从而确认“我正在访问的确实是真实的网站,而非冒牌货”。
与HTTPS的关系:可以简单理解为:HTTPS = HTTP + SSL/TLS。当你在浏览器中看到地址栏显示锁状图标和
https://开头时,就表示当前连接已经过 SSL/TLS 加密保护。
对称加密和非对称加密
下面这个表格清晰地对比了对称加密和非对称加密的核心差异。
| 特性 | 对称加密 | 非对称加密 |
|---|---|---|
| 密钥数量 | 单密钥,加密和解密使用同一把密钥 | 密钥对,包含一把公钥和一把私钥 |
| 核心原理 | 加密和解密是互逆的对称操作 | 公钥和私钥之间存在数学关联,用公钥加密的数据只有对应的私钥能解密,反之亦然 |
| 速度与效率 | 快,算法相对简单,适合加密大量数据 | 慢(可比对称加密慢1000倍),计算复杂,通常只用于加密少量关键信息(如会话密钥)或数字签名 |
| 安全性关键 | 密钥的绝对保密和安全管理。密钥一旦泄露,安全即被破坏。 | 私钥的绝对保密。公钥可以公开分发,无需保密。 |
| 主要挑战 | 密钥分发:如何安全地将密钥传递给通信对方? | 性能开销大,不适用于直接加密海量数据。 |
| 常见算法 | AES, DES, 3DES | RSA, ECC(椭圆曲线加密) |
| 生动比喻 | 一把钥匙开一把锁,通信双方需要提前配好同一把钥匙。 | 一个可以公开的“投递箱”(公钥)和一把只有主人有的“开箱钥匙”(私钥)。任何人都可以往投递箱里扔信件,但只有主人能用私钥打开箱子取信。 |
🚀 非对称加密如何解决密钥分发难题
非对称加密的精妙之处在于,它完美地解决了对称加密中最棘手的“密钥分发”问题。它的工作流程如下:
- 密钥生成:接收方(比如服务器)生成一对密钥:公钥和私钥。私钥自己严密保管,绝不外泄;公钥则可以公开发给任何人 。
- 加密:发送方(比如你的浏览器)拿到接收方的公钥后,用它来加密要发送的敏感信息(例如一个随机生成的“会话密钥”)。
- 解密:接收方收到加密信息后,用自己的私钥进行解密,获取原始内容。
这个过程的关键在于:即使网络上的攻击者截获了公钥和加密后的密文,他也无法解密,因为解密所需的私钥从未在网络上传输过 。
🤝 强强联合:HTTPS中的协同工作
在实际应用中(最典型的例子就是HTTPS),非对称加密和对称加密是协同工作的,结合了二者的优点 :
- 安全握手(使用非对称加密):你的浏览器连接到网站服务器后,服务器会将其公钥(通常包含在数字证书中)发送给浏览器。浏览器用这个公钥加密一个随机生成的会话密钥,然后发送给服务器。服务器用自己的私钥解密,获取这个会话密钥。
- 高效通信(使用对称加密):此后,浏览器和服务器之间的所有数据传输,都使用刚才协商好的那个会话密钥进行快速的对称加密和解密。
简单来说,非对称加密用来安全地“传递”对称加密的钥匙,而对称加密则用这把钥匙来“锁”住后续所有的通信内容。这样就既解决了密钥分发的安全问题,又保证了大数据量通信时的效率 。
💎 总结
- 对称加密:像同一个钥匙开同一把锁,速度快,适合处理大量数据,但核心挑战是如何安全地配送钥匙。
- 非对称加密:像一个公开的投递箱和一把私有的开箱钥匙,安全性高,完美解决了密钥配送问题,但速度慢。
现代安全通信协议(如HTTPS)正是将两者优势结合,先用非对称加密安全地交换一个临时密钥,再使用这个密钥进行高效的对称加密通信。
TCP
TCP(传输控制协议)是一种 面向连接 的协议,它使用三次握手来建立连接,并使用四次挥手来断开连接。
三次握手

过程:
- 第一次:客户端向服务器发送一个SYN报文,请求建立连接。报文中包含客户端的初始序列号。(证明客户端能发,服务端能收)
- 第二次:服务器收到SYN报文后,如果同意建立连接,则向客户端发送一个SYN+ACK报文,表示确认客户端的SYN报文。报文中包含服务器的初始序列号和对客户端初始序列号的确认。)(证明服务端能发,客户端能收)
- 第三次:客户端收到SYN+ACK报文后,向服务器发送一个ACK报文,表示确认服务器的SYN+ACK报文。此时,TCP连接建立完成
四次挥手

过程:
- 第一次:当客户端没有更多数据要发送时,它会向服务器发送一个
FIN报文,请求断开连接。 - 第二次:服务器收到FIN报文后,向客户端发送一个ACK报文,表示确认客户端的FIN报文。
- 第三次:当服务器没有更多数据要发送时,它会向客户端发送一个FIN报文,请求断开连接。
- 第四次:客户端收到FIN报文后,向服务器发送一个ACK报文,表示确认服务器的FIN报文。此时,TCP连接断开完成。
为什么三次握手和四次挥手
- 三次握手的目的是为了防止失效的连接请求报文突然又传送到了服务器,从而产生错误。通过三次握手,可以确保双方都准备好建立连接。
- 四次挥手的目的是为了确保双方都能够完整地发送和接收数据。由于TCP是
全双工通信协议,因此每个方向都需要单独进行关闭。这就需要四次挥手来完成。
TCP和UDP的区别
- TCP是一种
面向连接的协议,它在传输数据之前需要建立连接。 - UDP是一种
无连接的协议,它不需要建立连接就可以直接发送数据。 - TCP提供了可靠的数据传输,它通过序列号、确认应答、重传等机制来保证数据包的有序可靠传输。而UDP不提供可靠性保证,它只负责将数据包发送出去,不保证数据包能够到达目的地。
- TCP提供了流量控制和拥塞控制机制来保证网络的稳定性。而UDP没有这些控制机制。
TCP提供了可靠的数据传输,但速度相对较慢;
而UDP速度快,但不提供可靠性保证。选择哪种协议取决于应用程序的需求。
应用场景:
TCP:
- 文件传输:比如下载大文件,需要保证数据的完整性和顺序。
- 电子邮件:确保邮件内容准确无误地送达。
- 网页浏览:保证网页元素按正确的顺序加载,显示完整。
UDP:
- 实时视频和音频流:对实时性要求高,少量数据丢失不影响整体体验。
- 在线游戏:快速响应很重要,偶尔的数据丢失可以接受。
- 域名系统(DNS)查询:数据量小,对速度要求高。
解决跨域问题
跨域是指浏览器为了安全起见,限制了脚本内发起的跨源HTTP请求。这种限制被称为同源策略。同源策略规定,只有当协议、域名和端口都相同时,两个页面才被认为是同源的。如果两个页面不同源,那么它们之间就不能进行跨域请求。
实现跨域请求的方法:
- JSONP
通过动态创建<script>标签来实现跨域请求的方法
示例:
js
// 前端代码
function jsonp(url, callback) {
const script = document.createElement('script');
script.src = `${url}?callback=${callback}`;
document.head.appendChild(script);
}
// 后端代码(Node.js)
app.get('/api/data', (req, res) => {
const data = { name: 'Young', age: 18 };
const callback = req.query.callback;
res.send(`${callback}(${JSON.stringify(data)})`);
});CORS:CORS(Cross-Origin Resource Sharing,跨源资源共享)是一种基于HTTP头的机制,它允许服务器标识除了它自己以外的其他源(域、协议或端口),使得浏览器允许这些源访问加载自己的资源。服务器可以通过设置响应头中的
Access-Control-Allow-Origin字段来指定哪些源可以访问它的资源。代理:可以在服务器端设置一个代理,将前端发出的请求转发到目标服务器上,然后再将目标服务器返回的数据转发回前端。这样,前端就可以绕过浏览器的同源策略限制,实现跨域请求。
postMessage:postMessage是HTML5中新增的一个API,它允许不同源之间的窗口进行通信。可以通过监听message事件来接收其他窗口发送过来的消息。
GET和POST的区别
GET方法用于从指定的资源请求数据。它将参数显示在URL上,例如:/test/demo_form.php?name1=value1&name2=value2。GET方法提交的数据量有限制,因为它是通过URL添加数据来发送的,而URL的长度是受限制的。GET方法只允许ASCII字符。此外,GET请求可被缓存、保留在浏览器历史记录中、收藏为书签。但是,GET请求不应在处理敏感数据时使用。
POST方法用于向指定的资源提交要被处理的数据。它通过表单提交不会显示在URL上,因此POST方法更具隐蔽性。POST方法可以传输大量的数据,对数据长度没有要求。POST方法没有限制,也允许二进制数据。此外,POST请求不会被缓存、不会保留在浏览器历史记录中、不能被收藏为书签。
常见的http状态码
HTTP状态码用来表明特定HTTP请求是否成功完成。响应被归为以下五大类:
- 信息响应 (100–199)
- 成功响应 (200–299)
- 重定向消息 (300–399)
- 客户端错误响应 (400–499)
- 服务端错误响应 (500–599)
一些常见的HTTP状态码包括:
200 OK:请求成功。
301 Moved Permanently:请求的资源的URL已永久更改。
302 Found:请求的资源的URI已暂时更改。
304 Not Modified:所请求的资源未修改,客户端可以继续使用相同的缓存版本的响应。
400 Bad Request:客户端请求的语法错误,服务器无法理解。
401 Unauthorized:请求要求用户的身份认证。
403 Forbidden:客户端没有访问内容的权限。
404 Not Found:服务器找不到请求的资源。
500 Internal Server Error:服务器内部错误,无法完成请求。
502 表示 “错误网关”(Bad Gateway)。这意味着服务器作为网关或代理,从上游服务器接收到了无效的响应。
503 表示 “服务不可用”(Service Unavailable)。这表明服务器暂时无法处理请求,通常是由于服务器过载或正在进行维护。
CDN
CDN是Content Delivery Network的缩写,即内容分发网络。它的基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节,使内容传输的更快、更稳定。
CDN的工作原理就是将源站的资源缓存到CDN各个节点上,当请求命中了某个节点的资源缓存时,立即返回客户端,避免每个请求的资源都通过源站获取,避免网络拥塞、缓解源站压力,保证用户访问资源的速度和体验。
简单来说,CDN通过在全球范围内部署大量节点服务器,将网站内容缓存在这些节点服务器上,当用户访问网站时,CDN会根据用户的地理位置和网络状况等因素,智能调度用户访问离其最近的节点服务器,从而加快网站访问速度、提高网站可用性。