广东的一起(17)做网站,地推,沃噻网站建设流程,南阳做网站 汉狮公司上一篇#x1f449;: 浏览器垃圾回收机制 文章目录 浏览器同源策略1.同源策略的定义2.同源策略的作用3.同源策略的限制范围4.解决跨域方案汇总1.CORS#xff08;跨源资源共享#xff09;2.JSONP3.postMessage 跨域4.Nginx代理跨域5.Node.js中间件代理跨域6.document.domain…上一篇: 浏览器垃圾回收机制 文章目录 浏览器同源策略1.同源策略的定义2.同源策略的作用3.同源策略的限制范围4.解决跨域方案汇总1.CORS跨源资源共享2.JSONP3.postMessage 跨域4.Nginx代理跨域5.Node.js中间件代理跨域6.document.domain iframe7.Location.hash iframe8.window.name iframe跨域9.WebSocket协议跨域 5.正向代理与反向代理的区别正向代理Forward Proxy反向代理Reverse Proxy核心差异 6.NginxNginx概念及工作原理核心特性架构层次Master Process主进程Worker Processes工作进程工作流程 浏览器同源策略
1.同源策略的定义
同源策略(Same-origin policy)是Web浏览器为保护用户信息安全而实施的一种重要安全策略。该策略规定Web浏览器允许来自同一源的文档或脚本访问彼此的资源但限制了来自不同源的交互。这里的“源”指的是协议、域名和端口号三者的组合。如果三个要素完全一致则视为同源有任何一个不相同则视为跨域。
2.同源策略的作用
保护用户数据防止恶意网站读取另一个网站的敏感数据如Cookies、存储在浏览器中的用户个人资料等。防止恶意脚本执行阻止不同源的脚本相互操作防止恶意脚本注入和执行保护用户的浏览环境安全。
3.同源策略的限制范围
同源策略主要在以下几个方面实施限制
JavaScript访问权限禁止脚本读取或修改不同源页面的DOM也无法向不同源的服务器发送Ajax请求除非目标服务器明确允许跨域。Cookie、LocalStorage和IndexedDB访问禁止脚本访问不同源的这些存储数据保护用户数据不被非法窃取或篡改。其他API限制包括Web Storage、Web Workers、Fetch API等现代Web API在内大多遵循同源策略限制跨域访问。
4.解决跨域方案汇总
1.CORS跨源资源共享
CORS跨域资源共享是一种机制确保了网页可以从不同源协议、域名、端口的服务器上获取资源而不会受到浏览器同源策略的限制。这一机制通过在HTTP请求和响应中加入特定的头部信息来工作从而允许或拒绝跨域请求。 简单请求 简单请求的特点是使用了GET、HEAD或POST方法并且HTTP头部信息限于几个特定字段。这类请求不会触发预检请求preflight request浏览器直接发起请求并在请求头中加入Origin字段表明请求源。服务器需要在响应中包含Access-Control-Allow-Origin头部以明确允许的请求源。对于简单请求服务器至少需要配置Access-Control-Allow-Origin字段。 非简单请求 包括使用了除GET、HEAD、POST之外的方法如DELETE、PUT或POST请求中包含非标准的内容类型、自定义请求头等。这类请求会在正式请求前先发送一个OPTIONS请求作为预检请求以确认实际请求是否安全可接受。预检请求会携带Origin、Access-Control-Request-Method和Access-Control-Request-Headers等头部。服务器需响应这些头部对应的允许值至少包括Access-Control-Allow-Origin、Access-Control-Allow-Methods和Access-Control-Allow-Headers。 Cookie处理 要在CORS请求中携带Cookie需满足以下条件 客户端如通过XMLHttpRequest或Fetch API需设置withCredentials属性为true表明请求需要携带凭据如Cookie。服务器响应中必须设置Access-Control-Allow-Credentials为true表明服务器允许浏览器携带Cookie。Access-Control-Allow-Origin不能设为星号*而应指定具体的源地址因为星号不允许与Access-Control-Allow-Credentials: true一起使用。 减少OPTIONS请求 为了优化性能可以通过在服务器响应中设置Access-Control-Max-Age头部来缓存预检请求的结果避免每次请求都发送OPTIONS请求。该值指定了预检请求结果的有效期单位为秒。
总之CORS通过一系列HTTP头部的精确控制实现了安全的跨域数据交互同时提供了灵活的配置选项以适应不同场景的安全需求和性能优化。
2.JSONP
JSONPJSON with Padding是一种跨域数据交互技术其原理基于浏览器对 script 标签的特性和同源策略的绕过。
原理JSONP利用了浏览器对script标签的特殊处理通过动态创建script元素并设置其src属性为包含API请求的URL由于script标签的资源请求不受同源策略限制因此可以实现跨域数据请求。请求URL中通常包含一个查询参数用于指定客户端期望调用的回调函数名称。服务器接收到请求后会将响应数据包裹在这个回调函数中返回从而在客户端执行并传递数据。
JavaScript实现
script// 创建script元素var script document.createElement(script);script.type text/javascript;// 设置src属性包含请求URL及回调函数名script.src http://www.example.com/api/data?callbackmyCallback;// 将script元素插入页面触发请求document.head.appendChild(script);// 定义回调函数处理服务器返回的数据function myCallback(data) {console.log(data);}
/script服务器响应内容示例
myCallback({status: success, message: Hello, World!});Vue中使用axios实现JSONP 在Vue项目中虽然axios本身不直接支持JSONP但可以通过封装或使用第三方库如vue-jsonp来实现。这里提供一个简化的示例说明如何模拟实现
// 注意实际开发中应使用专门的库或封装方法
this.$http.jsonp(http://www.example.com/api/data, {params: {callback: myCallback}
}).then((res) {console.log(res.data);
})后端Node.js示例 后端需要解析请求中的回调函数名并将响应数据封装进该函数返回。
const http require(http);
const querystring require(querystring);const server http.createServer((req, res) {let params querystring.parse(req.url.split(?)[1]);let callback params.callback;// 假设这是从数据库获取的数据let data {status: success, data: Sample Data};// 构造JSONP响应res.writeHead(200, {Content-Type: application/javascript});res.end(${callback}(${JSON.stringify(data)}));
});server.listen(8080, () {console.log(Server running on port 8080);
});JSONP的缺点
仅支持GET请求因为数据是通过URL查询参数传递的这限制了其适用场景不适合大型数据传输或涉及敏感信息的请求。安全性问题容易受到XSS跨站脚本攻击的威胁恶意脚本可能通过构造特殊的回调函数名注入执行。无错误处理机制相比现代的CORS等技术JSONP缺乏标准化的错误处理流程调试和错误报告较为困难。
3.postMessage 跨域
postMessage 是一种允许来自不同源的脚本采用异步方式进行有限通信的Web API。这一功能对于实现跨域消息传递至关重要尤其是在涉及iframe、窗口以及Web Worker之间的通信场景。
概念postMessage 方法允许一个窗口或iframe向另一个窗口或iframe发送消息即使这两个窗口或iframe来源于不同的源协议域名端口。这对于实现跨域通信是非常有用的技术因为它不受到同源策略的限制。
用法postMessage 方法接收两个参数
data要发送的数据。根据HTML5规范它可以是任何基本类型或可复制的对象但在某些较旧的浏览器中可能只支持字符串。因此最佳实践是使用JSON.stringify()将对象转换为字符串。origin指定哪些源的窗口应该接收消息。可以设置为特定的源如 ‘http://example.com’或者使用通配符 * 来允许任何源接收消息但这存在安全风险应谨慎使用。若要限定与当前窗口同源则可设置为 /。
应用场景
页面与其打开的新窗口间的数据传递多个窗口间的消息传递主页面与嵌入的iframe间的消息传递
示例 sender.html (位于 domain1.com/sender.html):
iframe idiframe srchttp://www.domain2.com/receiver.html styledisplay:none;/iframe
scriptvar iframe document.getElementById(iframe);iframe.onload function() {var message {content: Hello from sender!};iframe.contentWindow.postMessage(JSON.stringify(message), http://www.domain2.com);window.addEventListener(message, function(e) {if (e.origin http://www.domain2.com) {alert(Response from receiver: e.data);}}, false);};
/scriptreceiver.html (位于 domain2.com/receiver.html):
scriptwindow.addEventListener(message, function(e) {if (e.origin http://www.domain1.com) {alert(Message received from sender: e.data);var response {content: Hello back to sender!,original: JSON.parse(e.data)};e.source.postMessage(JSON.stringify(response), e.origin);}}, false);
/script注意事项
在使用postMessage时确保正确验证消息来源即检查event.origin属性以防止跨站脚本攻击(XSS)。消息接收方通过监听message事件来接收消息其中event.data包含发送的数据而event.origin则标识发送消息的源。
使用e.source.postMessage()而不是window.parent.postMessage()可以更灵活地处理消息的回传特别是在多个窗口或iframe结构中。
4.Nginx代理跨域
使用Nginx作为代理服务器解决跨域问题主要利用其强大的反向代理能力和对HTTP头部的灵活控制能力实现跨源资源共享CORS。以下是两种常见的应用场景及其解决方案
Nginx配置解决iconfont跨域问题 当静态资源服务器需要向不同源的客户端提供iconfont字体文件如.eot、.otf、.ttf、.woff、.svg格式时虽然大部分静态资源不受同源策略限制但这些字体文件可能因浏览器的安全策略遇到跨域问题。通过在Nginx配置中添加适当的Access-Control-Allow-Origin头部可以允许所有源访问这些字体文件从而解决跨域问题。
location / {add_header Access-Control-Allow-Origin *;
}这段配置表示对所有请求到该Nginx服务器的资源响应头中都会包含Access-Control-Allow-Origin: *允许任何源的请求访问。
Nginx反向代理解决接口跨域问题 对于前后端分离的应用尤其是前端请求不同源后端接口的情况可以通过Nginx设置反向代理来规避浏览器的同源策略限制。 实现思路是设置一个与前端同源域名相同端口可以不同的Nginx代理服务器该服务器接收前端的请求然后作为“中转站”去访问实际后端服务domain2并将后端响应转发回前端。这样从浏览器的角度看请求和响应都在同一个源下避免了跨域问题。
server {listen 81; # 代理服务器监听的端口server_name www.domain1.com; # 与前端同源的域名location / {proxy_pass http://www.domain2.com:8080; # 反向代理至实际后端接口地址proxy_cookie_domain www.domain2.com www.domain1.com; # 修改响应中Set-Cookie的Domain属性使前端能正确保存cookie# 当前端请求需要带cookie且涉及到跨域时需要设置如下头部add_header Access-Control-Allow-Origin http://www.domain1.com; # 允许特定源的跨域请求add_header Access-Control-Allow-Credentials true; # 允许携带凭证如cookies# 如果前端请求不涉及cookie可以简化为# add_header Access-Control-Allow-Origin *;}
}这段配置不仅实现了接口的跨域访问还通过proxy_cookie_domain指令修改了后端返回的Cookie中Domain属性确保了前端能够正确存储和使用这些Cookie这对于需要认证或状态保持的场景尤为重要。
请注意当设置Access-Control-Allow-Credentials为true时Access-Control-Allow-Origin不能设置为*而应指定确切的源地址以确保安全性。
5.Node.js中间件代理跨域
在Node.js中使用中间件实现跨域代理是一种常见的处理前后端分离项目中跨域请求问题的方法。此方法通过在Node.js服务器上部署一个代理层将前端的跨域请求转发到目标后端服务器有效绕过了浏览器的同源策略限制。下面分别介绍非Vue框架和Vue框架下的跨域代理实现方式。
非Vue框架下的跨域代理
使用Express框架配合http-proxy-middleware中间件可以快速搭建一个代理服务器用于转发前端请求到后端API服务器并处理跨域问题。
前端请求示例:
var xhr new XMLHttpRequest();
xhr.withCredentials true; // 允许携带cookie
xhr.open(GET, http://www.domain1.com:3000/login?useradmin, true);
xhr.send();Node.js服务器配置:
const express require(express);
const { createProxyMiddleware } require(http-proxy-middleware);
const app express();app.use(/, createProxyMiddleware({target: http://www.domain2.com:8080, // 目标API服务器地址changeOrigin: true, // 改变请求源头模拟从代理服务器发起请求onProxyRes: function(proxyRes, req, res) {res.header(Access-Control-Allow-Origin, http://www.domain1.com); // 设置允许的源res.header(Access-Control-Allow-Credentials, true); // 允许携带凭证},cookieDomainRewrite: www.domain1.com, // 修改响应中Cookie的Domain
}));app.listen(3000, () {console.log(Proxy server is running on port 3000);
});Vue框架下的跨域代理
在Vue项目开发过程中通常会使用Webpack作为打包工具webpack-dev-server提供了内置的代理功能可以直接在webpack.config.js中配置接口代理简化跨域处理流程。
webpack.config.js配置示例:
module.exports {// ...其他配置devServer: {historyApiFallback: true,proxy: {/login: { // 匹配的路径target: http://www.domain2.com:8080, // 目标API服务器地址changeOrigin: true, // 改变请求源头secure: false, // 如果是HTTPS接口需要设置为falsecookieDomainRewrite: www.domain1.com, // 修改响应中Cookie的Domain}},noInfo: true // 减少输出信息}
};在Vue项目的开发环境下通过上述配置webpack-dev-server会自动拦截前端向/login路径的请求并将其代理到指定的后端API服务器同时处理好跨域问题使得开发者可以无缝对接后端接口进行开发调试而无需关心跨域问题。
6.document.domain iframe
在Web开发中当遇到主域相同但子域不同的跨域问题时可以通过修改document.domain属性的方法结合iframe标签来实现跨域通信。这种方法适用于那些拥有共同顶级域名的页面间的通信需求。具体实施步骤如下
实现原理 设置document.domain: 两个页面——即父页面和子页面通过iframe嵌入——都需要通过JavaScript设置它们的document.domain属性为相同的高级别主域。这样做是为了让浏览器认为这两个页面处于同一个域下从而绕过同源策略的限制。
应用场景 限制条件: 此方案仅适用于主域名相同但子域名不同的场景。例如a.example.com和b.example.com可以使用此方法通信但example.com与anotherexample.com则不适用。
示例代码 父窗口页面 (domain.com/a.html):
!DOCTYPE html
html langen
headmeta charsetUTF-8titleParent Window/title
/head
bodyiframe idiframe srchttp://child.domain.com/b.html/iframescriptdocument.domain domain.com; // 设置document.domain为共同的基础主域var user admin; // 父窗口定义的变量/script
/body
/html子窗口页面 (child.domain.com/b.html):
!DOCTYPE html
html langen
headmeta charsetUTF-8titleChild Window/title
/head
bodyscriptdocument.domain domain.com; // 子窗口同样设置document.domain为共同的基础主域// 从父窗口获取变量console.log(获取父窗口数据: window.parent.user);/script
/body
/html注意事项
安全考量: 虽然此方法可以解决特定条件下的跨域问题但在实施前需仔细考虑安全因素确保不会无意间暴露敏感信息或引入安全漏洞。适用范围: 仅限于同主域名下的子域名相互通讯对于完全不同域名间的跨域问题无效。现代替代方案:随着CORS跨源资源共享和WebSocket等技术的发展对于跨域数据交换的需求更多地倾向于使用这些现代标准因为它们提供了更为灵活和安全的跨域通信机制。
7.Location.hash iframe
在早期的Web开发中为了解决跨域通信问题开发者常采用location.hash iframe的技巧这是一种较为原始且有限制的跨域通讯方法。这种方法通过URL的hash部分传递信息利用不同页面间的iframe元素和同源策略的特性实现在一定条件下的跨域数据交换。以下是该方法的具体实施步骤和示例代码的描述
实现原理
借助iframe和hash值传递信息不同源的页面间不能直接进行JavaScript通信但可以通过iframe加载另一个页面并利用URL的hash部分传递数据。因为改变iframe的src的hash部分不会引起页面刷新且hash变化会触发onhashchange事件这为跨域数据传输提供了可能。中间人页面在两个不同源的页面A和B之间通常需要一个同源于A的中间页面C来完成闭环通信。C页面可以访问A页面的JavaScript上下文从而实现数据的最终传递。
具体实现步骤 a.html (位于 domain1.com)
创建一个隐藏的iframe其src指向B域的b.html。通过setTimeout设置延迟改变iframe的src附加hash值如#useradmin以此向B域的页面传递信息。定义一个全局函数onCallback供同源的C页面调用来回传数据。
b.html (位于 domain2.com)
同样包含一个隐藏的iframe其src指向A域的c.html。监听自身的onhashchange事件一旦hash值发生变化即接收到A域传来的信息立即将此hash值附加到C页面的iframe src中间接传递给C页面。
c.html (位于 domain1.com)
作为同源于A页面的中间人监听自身的onhashchange事件。解析接收到的hash值通过window.parent.parent访问到A页面的上下文并调用预先定义好的onCallback函数将处理后的信息回传给A页面。
示例代码摘要 a.html:
iframe idiframe srchttp://www.domain2.com/b.html styledisplay:none;/iframe
scriptvar iframe document.getElementById(iframe);setTimeout(function() {iframe.src #useradmin;}, 1000);function onCallback(res) {alert(Data from c.html --- res);}
/scriptb.html:
iframe idiframe srchttp://www.domain1.com/c.html styledisplay:none;/iframe
scriptvar iframe document.getElementById(iframe);window.onhashchange function () {iframe.src location.hash;};
/scriptc.html:
scriptwindow.onhashchange function () {var res hello: location.hash.replace(#user, );window.parent.parent.onCallback(res);};
/script注意事项
此方法受限于同源策略且通信效率较低用户体验可能受影响。现代Web开发中更推荐使用CORS跨源资源共享、WebSockets或Fetch API等技术来处理跨域问题它们提供更强大、灵活且安全的跨域通信能力 。
8.window.name iframe跨域
利用 window.name 和 iframe 实现跨域通信是一种巧妙的技术手段尤其适用于那些受到同源策略限制的场景。这种方法的核心在于利用了 window.name 属性的两个特性一是其值在页面跳转时可以保持不变即使跳转到完全不同域名的页面二是它可以存储异常大量的数据理论上可达2MB这为跨域数据交换提供了便利。 a.html (domain1.com/a.html)
var proxy function(url, callback) {var state 0;var iframe document.createElement(iframe);iframe.src url; // 设置iframe的src为跨域页面iframe.onload function() {if (state 1) {// 第二次加载同域proxy页面完成读取并处理数据callback(iframe.contentWindow.name);destroyFrame();} else if (state 0) {// 第一次加载跨域页面成功转向同域代理页面iframe.contentWindow.location http://www.domain1.com/proxy.html;state 1;}};document.body.appendChild(iframe);function destroyFrame() {iframe.contentWindow.document.write();iframe.contentWindow.close();document.body.removeChild(iframe);}// 请求跨域b页面的数据proxy(http://www.domain2.com/b.html, function(data) {alert(data); // 数据展示或进一步处理});
};proxy.html (domain1.com/proxy.html) 此页面仅作为中转站确保跨域数据能通过同源策略传递回主页面。
!DOCTYPE html
html langen
headmeta charsetUTF-8titleProxy Page/title
/head
body
!-- 此页面无需任何额外代码为了作为同源策略下的数据中转 --
!-- 跨域数据在window.name中已准备好将被父页面通过iframe访问 --
/body
/htmlb.html (domain2.com/b.html)
scriptwindow.name This is domain2 data!; // 跨域数据存储于window.name
/script工作原理 起始a.html 使用 proxy 函数创建 iframe指向跨域的 b.html。数据载入b.html 将数据写入 window.name。回程代理首次加载完毕后iframe 的 src 被重定向到同域的 proxy.html此时 window.name 的数据依然保留。数据提取与处理proxy.html 加载时第二次 onload 触发因同源关系可以从 iframe 提取 window.name 中的数据并通过回调函数返回给 a.html。资源清理数据处理完毕后iframe 被销毁确保安全及资源管理。
安全考量 尽管此技术可规避浏览器的跨域访问限制但实施时务必重视数据的安全性和隐私保护确保跨域通信活动遵循网络安全最佳实践和法规要求。
9.WebSocket协议跨域
WebSocket协议是一种在HTML5中引入的通信协议它允许浏览器和服务器之间建立全双工、低延迟的通信渠道特别适用于实现实时交互和服务器推送技术。相较于传统的HTTP请求WebSocket能够维持长时间的连接状态且双向通信无需重复握手提高了效率和实时性。此协议还支持跨域通信打破了同源策略的限制使得不同源的客户端与服务器能直接进行数据交换。
为了简化WebSocket的使用通常会采用如Socket.io这样的库它不仅对WebSocket API进行了高级封装提供了更易于使用的接口还对不兼容WebSocket的旧版浏览器提供了向下兼容的支持。
客户端前端代码示例 HTML部分包含一个文本输入框供用户输入数据JavaScript部分则通过Socket.io与服务器建立WebSocket连接。
!-- HTML部分 --
div用户输入input typetext/div!-- 引入Socket.io库 --
script srchttps://cdn.bootcss.com/socket.io/2.2.0/socket.io.js/script!-- JavaScript部分 --
script// 创建Socket.io实例并连接到服务器var socket io(http://www.domain2.com:8080);// 监听连接成功的事件socket.on(connect, function() {// 监听来自服务器的消息socket.on(message, function(msg) {console.log(从服务器收到的数据: --- msg);});// 监听服务器断开连接的事件socket.on(disconnect, function() {console.log(服务器连接已关闭.);});});// 当用户在输入框中失去焦点时发送输入值到服务器document.getElementsByTagName(input)[0].onblur function() {socket.send(this.value);};
/script服务器端Node.js代码示例 使用Node.js和Socket.io创建一个简单的WebSocket服务器监听8080端口并处理客户端的连接与消息。
// 引入必要的模块
var http require(http);
var socket require(socket.io);// 创建HTTP服务器
var server http.createServer(function(req, res) {res.writeHead(200, {Content-type: text/html});res.end();
});// 服务器监听8080端口
server.listen(8080);
console.log(服务器正在8080端口运行...);// 使用Socket.io监听服务器上的WebSocket连接
socket.listen(server).on(connection, function(client) {// 接收到客户端消息时的处理client.on(message, function(msg) {// 向客户端回复消息client.send(你好 msg);console.log(从客户端收到的数据: --- msg);});// 处理客户端断开连接client.on(disconnect, function() {console.log(客户端连接已关闭.);});
});以上示例展示了如何利用Socket.io在前端和后端之间快速搭建WebSocket通信包括如何处理连接、消息收发和断开连接等核心功能。
5.正向代理与反向代理的区别
特性正向代理反向代理目的允许客户端通过代理访问受限资源提高服务端性能负载均衡隐藏后端服务器设置方客户端服务器端代理对象客户端隐藏客户端服务器隐藏服务器透明性需客户端配置不透明对客户端透明无需客户端配置配置需求修改客户端网络设置如浏览器修改DNS指向代理服务器客户端无感知应用场景访问控制、隐私保护、地域限制突破负载均衡、SSL终止、安全防护、CDN示例个人使用代理服务器浏览国外网站Nginx作为网站前端分配请求到后端服务器
正向代理Forward Proxy
目的帮助客户端访问受限资源。当客户端因网络策略、地理位置限制等原因无法直接访问目标服务器时正向代理作为中介接收客户端的请求然后转发给目标服务器并将服务器响应传回客户端。设置方由客户端负责配置代理服务器信息可能涉及修改浏览器或其他客户端应用的网络设置。作用隐藏客户端的真实身份对外展现的是代理服务器的IP地址。配置需求需要在客户端进行代理服务器的配置。
反向代理Reverse Proxy
目的优化服务端架构提高服务的可用性和安全性。反向代理服务器接收来自客户端的请求根据预定义的规则决定将请求分配给后端的哪一个服务器处理随后将服务器响应返回给客户端。设置方由服务器端部署和管理对客户端透明。作用隐藏后端服务器的具体信息提供统一的入口实现负载均衡、SSL终止、缓存及安全防护等功能。DNS配置通常通过修改DNS记录使域名解析到反向代理服务器的IP地址客户端无需知晓后端服务器的细节。
正向代理流程正向代理流程描述了客户端通过配置的代理服务器Proxy向目标服务器Target_Server请求数据的过程。 #mermaid-svg-B1OghRv2VEDXV6r7 {font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}#mermaid-svg-B1OghRv2VEDXV6r7 .error-icon{fill:#552222;}#mermaid-svg-B1OghRv2VEDXV6r7 .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-B1OghRv2VEDXV6r7 .edge-thickness-normal{stroke-width:2px;}#mermaid-svg-B1OghRv2VEDXV6r7 .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-B1OghRv2VEDXV6r7 .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-B1OghRv2VEDXV6r7 .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-B1OghRv2VEDXV6r7 .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-B1OghRv2VEDXV6r7 .marker{fill:#333333;stroke:#333333;}#mermaid-svg-B1OghRv2VEDXV6r7 .marker.cross{stroke:#333333;}#mermaid-svg-B1OghRv2VEDXV6r7 svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-B1OghRv2VEDXV6r7 .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-B1OghRv2VEDXV6r7 .cluster-label text{fill:#333;}#mermaid-svg-B1OghRv2VEDXV6r7 .cluster-label span{color:#333;}#mermaid-svg-B1OghRv2VEDXV6r7 .label text,#mermaid-svg-B1OghRv2VEDXV6r7 span{fill:#333;color:#333;}#mermaid-svg-B1OghRv2VEDXV6r7 .node rect,#mermaid-svg-B1OghRv2VEDXV6r7 .node circle,#mermaid-svg-B1OghRv2VEDXV6r7 .node ellipse,#mermaid-svg-B1OghRv2VEDXV6r7 .node polygon,#mermaid-svg-B1OghRv2VEDXV6r7 .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-B1OghRv2VEDXV6r7 .node .label{text-align:center;}#mermaid-svg-B1OghRv2VEDXV6r7 .node.clickable{cursor:pointer;}#mermaid-svg-B1OghRv2VEDXV6r7 .arrowheadPath{fill:#333333;}#mermaid-svg-B1OghRv2VEDXV6r7 .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-B1OghRv2VEDXV6r7 .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-B1OghRv2VEDXV6r7 .edgeLabel{background-color:#e8e8e8;text-align:center;}#mermaid-svg-B1OghRv2VEDXV6r7 .edgeLabel rect{opacity:0.5;background-color:#e8e8e8;fill:#e8e8e8;}#mermaid-svg-B1OghRv2VEDXV6r7 .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-B1OghRv2VEDXV6r7 .cluster text{fill:#333;}#mermaid-svg-B1OghRv2VEDXV6r7 .cluster span{color:#333;}#mermaid-svg-B1OghRv2VEDXV6r7 div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-B1OghRv2VEDXV6r7 :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 发出请求 转发请求 响应数据 返回数据给客户端 Client Proxy Target_Server 反向代理流程反向代理流程则展示了客户端请求通过反向代理服务器Reverse_Proxy该代理服务器根据策略选择合适的真实服务器Real_Server处理请求并将响应返回给客户端的场景。 #mermaid-svg-m7mmnQeqEP5WH4qa {font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}#mermaid-svg-m7mmnQeqEP5WH4qa .error-icon{fill:#552222;}#mermaid-svg-m7mmnQeqEP5WH4qa .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-m7mmnQeqEP5WH4qa .edge-thickness-normal{stroke-width:2px;}#mermaid-svg-m7mmnQeqEP5WH4qa .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-m7mmnQeqEP5WH4qa .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-m7mmnQeqEP5WH4qa .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-m7mmnQeqEP5WH4qa .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-m7mmnQeqEP5WH4qa .marker{fill:#333333;stroke:#333333;}#mermaid-svg-m7mmnQeqEP5WH4qa .marker.cross{stroke:#333333;}#mermaid-svg-m7mmnQeqEP5WH4qa svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-m7mmnQeqEP5WH4qa .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-m7mmnQeqEP5WH4qa .cluster-label text{fill:#333;}#mermaid-svg-m7mmnQeqEP5WH4qa .cluster-label span{color:#333;}#mermaid-svg-m7mmnQeqEP5WH4qa .label text,#mermaid-svg-m7mmnQeqEP5WH4qa span{fill:#333;color:#333;}#mermaid-svg-m7mmnQeqEP5WH4qa .node rect,#mermaid-svg-m7mmnQeqEP5WH4qa .node circle,#mermaid-svg-m7mmnQeqEP5WH4qa .node ellipse,#mermaid-svg-m7mmnQeqEP5WH4qa .node polygon,#mermaid-svg-m7mmnQeqEP5WH4qa .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-m7mmnQeqEP5WH4qa .node .label{text-align:center;}#mermaid-svg-m7mmnQeqEP5WH4qa .node.clickable{cursor:pointer;}#mermaid-svg-m7mmnQeqEP5WH4qa .arrowheadPath{fill:#333333;}#mermaid-svg-m7mmnQeqEP5WH4qa .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-m7mmnQeqEP5WH4qa .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-m7mmnQeqEP5WH4qa .edgeLabel{background-color:#e8e8e8;text-align:center;}#mermaid-svg-m7mmnQeqEP5WH4qa .edgeLabel rect{opacity:0.5;background-color:#e8e8e8;fill:#e8e8e8;}#mermaid-svg-m7mmnQeqEP5WH4qa .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-m7mmnQeqEP5WH4qa .cluster text{fill:#333;}#mermaid-svg-m7mmnQeqEP5WH4qa .cluster span{color:#333;}#mermaid-svg-m7mmnQeqEP5WH4qa div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-m7mmnQeqEP5WH4qa :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 发出请求 智能路由到 处理并响应 返回响应给客户端 Client Reverse_Proxy Real_Server 核心差异
尽管正向代理和反向代理在结构上都表现为 client-proxy-server但关键区别在于代理服务器的部署位置和代理服务的目标
部署位置正向代理靠近客户端由客户端配置使用反向代理则部署在服务器端对客户端透明。目标正向代理旨在隐藏客户端帮助客户端访问资源反向代理则是隐藏服务器端详情提供额外的安全性、性能优化和负载均衡能力。
综上所述正向代理和反向代理的主要区别在于代理服务的侧重点和部署策略分别服务于客户端的需求隐藏和服务器端的架构优化及安全增强。
6.Nginx
Nginx概念及工作原理
Nginx 是一款轻量级的 Web 服务器软件专为高效率和低资源消耗而设计。除了基本的网页服务功能Nginx 还能作为反向代理服务器、负载均衡器以及实现HTTP缓存策略广泛应用于构建高性能的现代网络架构。
核心特性
异步事件驱动模型区别于传统服务器如Apache采用的进程或线程模型Nginx运用了事件驱动的方式处理请求这种机制使它能够以更少的资源处理更多的并发连接显著提升了处理能力与响应速度。
架构层次
Master Process主进程
管理与控制Nginx架构的顶级元素是master process负责加载配置、监控状态以及维护工作进程的生命周期但不直接参与请求处理。
Worker Processes工作进程
并发处理核心由主进程创建的worker processes承担了实际的请求处理工作。得益于事件驱动设计每个worker进程能够同时处理大量HTTP请求无需为每个请求分配单独的线程或进程这是Nginx在性能上超越诸如Apache后者基于每个连接/请求分配独立进程的模型的关键所在。
工作流程
请求接收客户端发起HTTP请求至Nginx服务器。请求分发Nginx可根据配置执行反向代理或负载均衡功能将请求智能路由到后端服务器。高效处理利用epollLinux环境下等I/O多路复用技术工作进程异步非阻塞地监听和响应事件即使面对文件I/O或后端响应等待也能继续处理其他请求。响应与缓存处理完成后将响应数据返回客户端对于静态资源Nginx可实施缓存策略加速后续相同请求的响应。
综上所述Nginx凭借其独特的事件驱动架构和高度优化的工作进程模型在处理高并发场景时展现出卓越的性能成为众多大型网站和服务的首选基础架构组件。
