反向代理/负载均衡/session/cookie

正向代理：客户端将流量重定向到burpsuite等软件或连接到VPN再访问服务器而不是直接访问服务器的场景。流量流动方向是真正机器--代理服务器。正向代理又称代理、普通代理。

反向代理：服务器端使用反向代理服务器统一接收客户端访问，然后再按即定规则将数据包重定向到真正的服务器的场景。流量流动方向是代理服务器--真正机器，与正向代理正好相反所以称反向代理（其实我觉得这此名词应是先有代理再有反向代理再有正向代理）。

相互关系：除了名词相反外，由于代理是客户端行为反向代理是服务端行为所以可以随意使用，在技术上两不相干。

假设客户端代理访问了有反向代理的服务器：

C--客户端；PC--客户端代理服务器；PS--服务端代理服务器；S--服务器

这个例子要再次声明这样的原则：对于网络中的一跳，其从上一跳接收的数据包中的目的地址一定是它，其发往下一跳的数据包中的源地址一定是它；这不会因为包括其本身用途在内的任何原因而改变。

所以以PS为例，其收到的数据包目的地址一定是PS然后再由其重新封装数据包将目的地址改为S，而不可能PS收到的数据包的目的地址直接是S；即便它只是纯粹向S转发数据包的代理服务器。

PS要和外网交流又要和内网交流，所以其需要一张外网网卡和一张内网网卡。

负载均衡：以一设备统一接收客户端请求再按即定规则从多台相同服务器从选出一台将数据包重定向到这台服务器上的场景。

负载均衡可以理解为反向代理的子集，其在反向代理中加入了“多台相同服务器”的限定；当然你要说“不同服务器”（如一台JSP服务器和一台PHP服务器使用NGINX做反向代理）的反理也可以叫负载均衡那我也觉没什么问题。

软负载和硬负载：

软负载：就是通过软件来实现负载均衡功能；Nginx和httpd等http服务器都能实现软负载功能。

硬负载：又叫硬件负载，就是把实现负载均衡功能的软件搬到一台专门的计算机上；比如F5等设备。

软负载与硬负载的区别和软件防火墙与硬件防火墙的区别是一样的。

负载均衡与会话同步：

在负载均衡中可以将来自同一个IP的访问通过IP_HASH等方式全定向到一台机器上。这样一来所有会话（session）就全在一台机器上，就不必使用会话同步了。

但IP_HASH的问题是如果某台服务器故障而请求一样被发送过去，那么这些访问请求被发送到故障机的IP将无法得到服务，我的服务器分明还有多台正常而我的用户却只因一台故障即不能访问，这并不能最大化多台服务器的效益。

会话中保存着用户的登录状态，而如果请求是按即定算法被分配到不确定的服务器上那么就得保证会话同步，以确保在S1上登录过的用户其请求被重定向到S2时其状态也是登录的（而不是又让用户再次登录这样的网站没人愿意用）。

会话同步实现的思路是无论哪台服务器的session都存放到一台服务器上，请求无论被分配到S1还是S2都是到那台服务器上取session。

而在session服务器的存储又有两种方案，一是使用oracle等传统数据库存储，二是使 用memcache等内存数据库存储；后者方案是更加推荐的。

session比cookie更安全吗？

所谓的cookie不安全主要是指用户名/密码/登录状态等会话信息全部存在了cookie中，一是cookie被盗那么信息泄漏得多，二是如果以登录状态值标识用户登录状态从而决定是否有操作权限那么完全可能是伪造cookie实现越权。

session一般是生成一个sessionID存放到cookie中，如果cookie被盗那么攻击者一样是可以使用该sessionID登录的，只是说没泄漏用户名等信息伪造sessionID也不能伪造其登录状态（这两点安全性就提高好多了）。

禁用cookie后session就不能用了吗？

session的根本原理是以一个sessionID标识用户，客户端无论从哪把sessionID传到服务器都是可以的不一定要通过cookie，这是严谨但不负责任的回答。

在一般的session实现中我们生成sessionID并将其put到cookie中，由于是cookie是自动提交的所以，我们在设计客户端请求时完全不用考虑sessionID的上传。

如果我们不将sessionID放到cookie，那么再没第二个和cookie这样自动下传又自动上传的字段，这意味着如果不通过cookie那么在服务端下传后在客户端请求时需要手动将sessionID附到某个字段中。

轻则要附到URL中作为参数，重则要js将sessionID附到http头的其他字段中或post的body中；一两个页面还没什么，要是全站使用和考滤网站扩展性，这工作量并不是可以轻描淡写。

所心结论是禁用cookie后session还是有方法可以实现的，但这比较麻烦。