URL处理全流程与负载均衡原理

原 作者 刘生玺 | 发表于 | 分类于 2016级

文章目录

URL处理全流程( 假设没有代理 )

  • 1.　检查 URL 语法，确定使用那个协议（http,https）
  • 2.　从　DNS 查询 IP 地址
  • 3.　浏览器根据IP地址与目标web服务器在80端口上建立TCP连接
  • 4.　浏览器获取请求页面的html代码。
  • 5.　浏览器在显示窗口内渲染HTML。
  • 6.　窗口关闭时，浏览器终止与服务器的连接。

HTTP代理服务器的工作原理

在这里插入图片描述

  • 正向代理
  • 反向代理
  • 透明代理
  1. 正向代理：客户端自己设置代理服务器地址．客户的每次请求都是直接发送到该代理服务器，由该代理服务器来请求资源．
  2. 反向代理：反向代理设置在服务端，客户端无需任何设置．用代理服务器来接受Internet上的连接请求，然后将请求转发给内网上的服务器，并将从内网服务器上接受到的结果返回给客户端．各大网站通常分区域设置了多个代理服务器，所以在不同的地方去ping一个相同的域名，就可能得到不同的IP地址（其实是代理服务器的地址）
  3. 透明代理：只能设置在网关上．用户访问的数据报必然经过网关，所以他其实就是正向代理的一种特殊情况啦！！！

在这里插入图片描述
一般代理服务器还会提供缓存资源的功能，这样自然会加快资源访问！！

DNS 服务器的工作原理

在真正在DNS服务器上查IP之前会去做的事：

  • 在浏览器DNS缓存中搜索 chrome://net-internals/#dns
  • 在操作系统DNS缓存中搜索 要启用 nscd 服务，查看：nscd dns
  • 读取系统hosts文件，查找其中是否有对应的 IP 一般是通过主机名来访问本地局域网的机器时
# Shengxi-Liu @ Shengxi-Liu-PC in ~ [11:14:07] C:1
$ sudo cat /etc/hosts 
[sudo] Shengxi-Liu 的密码：
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1     localhost localhost.localdomain localhost6 localhost6.localdomain6 //ipv6
92.16.16.10 vc.udbs.cn

在访问WebServer时，如果http_proxy设置－＞使用代理－＞环境变量http_proxy中就可能含有主机名

/etc/host.conf文件：

order hosts,bind //先hosts,然后 DNS
multi on //可以包含多个　IP　地址
  • 向本地配置的首选DNS服务器发起域名解析请求

/etc/resolv.conf文件中存放DNS服务器IP地址．

$ cat /etc/resolv.conf 
# Generated by NetworkManager
nameserver 192.168.3.1 //首选DNS地址
					　　//备选DNS地址

host -t A www.baidu.com

-t ：那种查询类型
A：域名查询方式

# Shengxi-Liu @ Shengxi-Liu-PC in ~ [11:32:41] 
$ host -t A www.baidu.com 
www.baidu.com is an alias for www.a.shifen.com.　 //别名
www.a.shifen.com has address 220.181.111.37
www.a.shifen.com has address 220.181.112.244

重点：真正DNS的原理

在这里插入图片描述

  • 代理服务器查询/etc/resolve.cof得到DNS地址
  • 内核采用UDP协议封装
  • 网络层IP封装，查询路由表看如何发送该数据报（在网络层IP地址一直不变，MAC地址会一直改变）
  • 如果在代理服务器上有对应的ARP缓存，则直接返回DNS的mac地址，没有就继续
  • 代理发起广播，然后收到应答，得到DNS的mac地址
  • 然后通过以太网驱动程序，发送到DNS，进行实际的查询．
  • 查询到对应 IP 地址后返回代理服务器

ARP(数据链路层)协议的那些事（IP地址 -> mac地址的转换）

工作原理：向自己的网络广播一个ARP请求（包含目标机器的地址），然后只有被请求的目标机器回应一个ARP应答，其中就包含了自己的物理地址．
在这里插入图片描述
看最后四个字段：

  • 发送端：填充　除目地端以太网地址，构建ARP请求
  • 接受端：发现是自己的ＩＰ，填充自己的以太网地址．交换最后四个字段．返回之！！！
ARP缓存

顾名思义－＞IP->MAC地址的缓存

arp -a

# Shengxi-Liu @ Shengxi-Liu-PC in ~ [11:43:07] 
$ arp -a 
? (192.168.3.231) at 94:87:e0:20:76:3e [ether] on wlp0s16u2
? (192.168.3.150) at 00:db:70:92:24:4b [ether] on wlp0s16u2
? (192.168.3.220) at 1c:15:1f:53:a4:49 [ether] on wlp0s16u2
gateway (192.168.3.1) at 90:94:97:10:fa:bd [ether] on wlp0s16u2

arp -d ip地址　//删除
arp -s ip地址　　mac地址 　//添加

HTTPS与HTTP

SSL(旧) ->TLS(新，更名)

  • SSL：Secure Sockets Layer
  • TLS：Transport Layer Security

作用：

不使用SSL/TLS的HTTP通信，就是不加密的通信。所有信息明文传播，带来了三大风险。

（1） 窃听风险（eavesdropping）：第三方可以获知通信内容。

（2） 篡改风险（tampering）：第三方可以修改通信内容。

（3） 冒充风险（pretending）：第三方可以冒充他人身份参与通信。

SSL/TLS协议是为了解决这三大风险而设计的，希望达到：

（1） 所有信息都是加密传播，第三方无法窃听。

（2） 具有校验机制，一旦被篡改，通信双方会立刻发现。

（3） 配备身份证书，防止身份被冒充。

在这里插入图片描述

  • 密钥交换：椭圆曲线加密算法的表达．
    目地：解决浏览器与服务器如何独立的生成密钥，并使得最后生成的密钥是相同的．从而使用这个相同的密钥加密数据
  • RSA：身份验证算法
  • 采用对称加密算法：

对称加密与非对称加密

在这里插入图片描述

在这里插入图片描述

Nginx　小文件：非对称加密
　　　 大文件：对称加密

TLS协议运行机制

TLS协议的基本思路是采用非对称加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。
在这里插入图片描述

  • (1) 　ClientHello 请求

在这一步，客户端主要向服务器提供以下信息。

（1） 支持的协议版本，比如TLS 1.0版。

（2） 一个客户端生成的随机数，稍后用于生成"对话密钥"。

（3） 支持的加密方法，比如RSA公钥加密。

（4） 支持的压缩方法。
  • (2) 服务器回应（SeverHello）

服务器收到客户端请求后，向客户端发出回应，这叫做SeverHello。服务器的回应包含以下内容。

（1） 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，
服务器关闭加密通信。

（2） 一个服务器生成的随机数，稍后用于生成"对话密钥"。

（3） 确认使用的加密方法，比如RSA公钥加密。

（4） 服务器证书。
  • (3) 客户端回应

客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布(需要付费购买)、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。

如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息。

（1） 一个随机数。该随机数用服务器公钥加密，防止被窃听。

（2） 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。

（3） 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，
用来供服务器校验。

上面第一项的随机数，是整个握手阶段出现的第三个随机数，又称"pre-master key"。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把"会话密钥"。

  • (4) 服务器的最后回应
    服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"。然后，向客户端最后发送下面信息。
（1）编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。

（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，
用来供客户端校验。

至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用"会话密钥"加密内容。

摘自：http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html

负载均衡

摘自知乎：https://zhuanlan.zhihu.com/p/32841479

将工作负载分布到多个服务器来提高网站、应用、数据库或其他服务的性能和可靠性。

一个没有负载均衡的 web 架构类似下面这样：

在这里插入图片描述
在这里用户是直连到 web 服务器，如果这个服务器宕机了，那么用户自然也就没办法访问了。另外，如果同时有很多用户试图访问服务器，超过了其能处理的极限，就会出现加载速度缓慢或根本无法连接的情况。

而通过在后端引入一个负载均衡器和至少一个额外的 web 服务器，可以缓解这个故障。通常情况下，所有的后端服务器会保证提供相同的内容，以便用户无论哪个服务器响应，都能收到一致的内容。
在这里插入图片描述

负载均衡器可以处理什么样的请求？

负载均衡器的管理员能主要为下面四种主要类型的请求设置转发规则：

  • HTTP
  • HTTPS
  • TCP
  • UDP

负载均衡器如何选择要转发的后端服务器？

负载均衡器一般根据两个因素来决定要将请求转发到哪个服务器。首先，确保所选择的服务器能够对请求做出响应，然后根据预先配置的规则从健康服务器池（healthy pool）中进行选择。

因为，负载均衡器应当只选择能正常做出响应的后端服务器，因此就需要有一种判断后端服务器是否「健康」的方法。为了监视后台服务器的运行状况，运行状态检查服务会定期尝试使用转发规则定义的协议和端口去连接后端服务器。如果，服务器无法通过健康检查，就会从池中剔除，保证流量不会被转发到该服务器，直到其再次通过健康检查为止。

类似保活机制

负载均衡算法

负载均衡算法决定了后端的哪些健康服务器会被选中。几个常用的算法：

  • Round Robin（轮询）：为第一个请求选择列表中的第一个服务器，然后按顺序向下移动列表直到结尾，然后循环。
  • Least Connections（最小连接）：优先选择连接数最少的服务器，在普遍会话较长的情况下推荐使用。
  • Source：根据请求源的 IP 的散列（hash）来选择要转发的服务器。这种方式可以一定程度上保证特定用户能连接到相同的服务器。

如果你的应用需要处理状态而要求用户能连接到和之前相同的服务器。可以通过 Source 算法基于客户端的 IP 信息创建关联，或者使用粘性会话（sticky sessions）。

最后，想要解决负载均衡器的单点故障问题，可以将第二个负载均衡器连接到第一个上，从而形成一个集群。
在这里插入图片描述