AWS VPN

AWS VPN由两种服务组成:AWS站点对站点VPN和AWS客户端VPN。通过站点到站点VPN IP安全(IPSec)设置或客户机VPN传输层安全(TLS)隧道，您可以安全地、私有地访问云资源。AWS站点到站点VPN允许您安全地将您的本地网络或分支机构站点连接到您的Amazon虚拟私有云(Amazon VPC)。AWS客户端VPN使您能够安全地将用户连接到AWS或on-premises网络。

AWS站点到站点VPN功能

AWS站点到站点VPN通过IP安全(IPSec)隧道将您的数据中心或分支机构扩展到云，并支持连接到虚拟专用网关和AWS传输网关。您可以选择在IPSec隧道上运行边界网关协议(BGP)，以获得高可用性的解决方案。

安全连接

AWS站点到站点VPN允许您创建到虚拟网关或AWS传输网关的IPSec隧道。这些端点之间的隧道通信可以使用AES128或AES256加密，并使用Diffie-Hellman组进行密钥交换，提供了完美的正向保密。AWS站点到站点VPN将使用SHA1或SHA2散列功能进行身份验证。

高可用性

AWS站点到站点VPN允许您使用AWS Direct Connect创建故障转移和CloudHub解决方案。CloudHub使您的远程站点能够彼此通信，而不仅仅是与VPC通信。它运行在一个简单的轮辐模型上，您可以使用或不使用VPC。这种设计适合具有多个分支机构和现有internet连接的客户，这些客户希望为这些远程办公室之间的主连接或备份连接实现一个方便的、潜在的低成本轮辐模型。

配置和性能

AWS站点到站点VPN提供了可定制的隧道选项，包括隧道内部IP地址、预共享密钥和边界网关协议自主系统编号(BGP ASN)，因此您可以设置多个安全VPN隧道，以增加应用程序的带宽或在停机时的弹性。此外，AWS过境网关上的AWS站点到站点VPN提供了等成本的多路径路由(ECMP)，以帮助增加多路径上的流量带宽。

网络地址转换(NAT)遍历

AWS站点到站点VPN支持NAT遍历应用程序，这样您就可以在路由器背后的私有网络上使用私有IP地址，并且只有一个面向internet的公共IP地址。

监控

AWS站点到站点VPN可以向CloudWatch发送度量，从而为您提供更好的可见性和监视。CloudWatch还允许您发送自己的自定义指标，并以您选择的任何顺序和速度添加数据点。您可以将这些数据点的统计信息作为一组有序的时间序列数据检索。

 

AWS站点到站点VPN的限制

1. 每个AWS帐户每个AWS区域最多可以有五(5)个客户网关
2. 每个AWS帐户每个AWS区域最多可以有五(5)个虚拟网关
3. 您可以有多达50(50)个站点到站点VPN连接每个AWS帐户每个AWS区域
4. 每个虚拟网关最多可以有50个站点到站点的VPN连接。
5. 您可以为每个虚拟网关提供多达100条路由。

*更多信息，请查看亚马逊VPC用户指南中的VPN限制。如果您需要超过这些限制，请创建一个支持案例。

AWS客户端VPN功能

AWS客户端VPN提供了一个完全托管的VPN解决方案，可以通过Internet连接和兼容openvpn的客户端从任何地方访问该解决方案。它是弹性的，并自动缩放，以满足您的需求。它使您的用户能够连接到AWS和on-premises网络。AWS客户机VPN与现有的AWS基础设施(包括Amazon VPC和AWS目录服务)无缝集成，因此无需更改网络拓扑。

AWS客户端VPN提供以下功能:

身份验证

AWS客户端VPN将使用Active Directory或证书进行身份验证。客户端VPN与AWS目录服务集成，AWS目录服务连接到现有的on-premises Active Directory，因此不需要将数据从现有Active Directory复制到云。使用客户端VPN的基于证书的身份验证与AWS证书管理器集成，可以轻松地提供、管理和部署证书。

授权

AWS客户机VPN提供基于网络的授权，因此您可以定义访问控制规则，根据Active Directory组限制对特定网络的访问。客户端VPN可以为使用安全组的客户端VPN用户提供对特定应用程序的细粒度访问。

安全连接

AWS客户端VPN使用安全的TLS VPN隧道协议对流量进行加密。一个VPN隧道在每个客户机VPN端点终止，并为用户提供对所有AWS和内部资源的访问。

连接管理

您可以使用Amazon CloudWatch日志从AWS客户机VPN连接日志监视、存储和访问日志文件。然后，您可以从CloudWatch日志中检索相关的日志数据。因此，您可以轻松地监视、进行取证分析并终止特定连接，从而控制谁可以访问您的网络。

与员工设备的兼容性

AWS客户端VPN旨在将设备连接到您的应用程序。它允许您从基于openvpn的客户机中进行选择，让员工可以选择使用他们选择的设备，包括Windows、Mac、iOS、Android和基于linux的设备。

 

原文：https://aws.amazon.com/cn/vpn/features/

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

 

HTTP/2是HTTP/1的下一个版本，HTTP/1无法处理现在的web，因为现在的web资源更加密集，它无法有效地处理多个请求。HTTP/2有许多技术可以利用当前web体验的需求。

SPDY是HTTP/2协议的核心部分，许多HTTP/2协议技术都是SPDY的一部分。

SPDY(speed)是一种网络协议，它通过压缩报头、预测客户端请求(下面讨论的示例)和其他技术来操纵http协议，以加强web体验。

SPDY是由谷歌开发的。但是，由于支持使用SPDY技术的http/2，所以不赞成使用SPDY。谷歌说，在使用http/1之前，SPDY会提高你的网站速度，speed (SPDY)会将网站速度提高到55%。

SPDY支持所有主要的浏览器(firefox, chrome, opera, safari, ie)。

为什么速度快:

1。压缩。

快速压缩报头，它将跟踪这个特定会话中的报头是否已经发送，如果发送报头已经完成，那么在会话过期之前重新发送报头是没有用的。

2。预取:

如果客户机请求包含一些链接(css样式表)的html文件，那么在http/1协议中，客户机应该发送请求以获取这些链接(css样式表)。在这种情况下，快速服务器可以解析html、包含这些链接并发送，而无需等待客户端请求链接。

3.优先级:

HTTP/1处理有限的并行连接，如基于浏览器的6-8，如果连接更多，则我们必须等到以前的连接被解决，所以即使有重要的连接，我们也要等待。通过使用优先级流来快速解决问题，所以最紧急的请求将首先得到解决。

4 最重要的是多路复用:

如上所述，关于有限的并行连接，multiplexing可以解决这个问题，multiplexing基本上就是将多个信号组合成一个，所以快速浏览器将它的多个请求合并为一个请求并发送到服务器，然后服务器将请求(多路复用)划分为原始请求数并进行响应。

快速是快速的，因为额外的工作是由客户端和服务器完成上面的任务。

虽然http/2的核心速度很快，但http/2可以处理多主机多路复用，加密速度更快，压缩速度更快。

HTTP / Nginx 2:

Nginx从1.9.5版本开始支持http/2，所以如果您使用的是长期支持OS版本，比如Ubuntu 14.04，那么在安装Nginx之前，您应该向源列表中添加最新的Nginx deb repo。

如果您的nginx版本低于1.9.5，请遵循以下命令

wget - o - http://nginx.org/keys/nginx_sign. key | sudo ap -key add -

echo " deb http://nginx.org/packages/mainline/ubuntu/ trusty nginx " | sudo tee -a /etc/apt/sources.list

echo“deb-src http://nginx.org/packages/mainline/ubuntu/ trusty nginx”| sudo tee -a /etc/apt/sources.list。

sudo apt-get更新

sudo apt-get安装nginx

最后替换:

listen 443 ssl;

为

listen 443 ssl http2;

重新加载Nginx。

这是它. .你已经准备好出发了。

要检查http2是否打开，请访问:https://tools.keycdn.com/http2-test或checkout chrome嗅探扩展，显示站点的详细信息，无论是使用nginx、jquery、disqus等。如果启用了http2或spdy协议，它将显示spdy。

在阅读或讨论internet服务时，“带宽”和“延迟”这两个术语始终是最重要的。但它们是什么意思？它们有何不同？它们会影响你的上网速度吗？

虽然这两个术语经常混淆，但它们不是一回事。带宽和延迟之间有一些微妙但重要的区别，知道哪一个是你的问题可能是让你的互联网连接发挥最大效用的关键。

带宽与延迟

什么是带宽？

带宽是在特定时间内从网络中的一个点传输到另一个点的数据量的度量。它通常用于测量您可以从internet上的服务器下载到设备上的数据量。

把你的连接带宽想象成一条高速公路，把你的数据想象成六辆车以同样的速度行驶。高带宽的高速公路将有六条车道，允许所有车辆在1秒内同时到达。一条低带宽的高速公路只有一条车道，允许所有车辆在6秒内到达。

由于网络拥塞、网络开销和其他外部因素，您的实际带宽通常会小于最大带宽。例如，您的internet连接可能支持1000 Mbps的宽带（高速公路），但您的internet计划可能会关闭一些车道，并将带宽限制为400 Mbps。再加上网络拥塞、本地布线问题等，您的最高带宽可能只有300 Mbps。

一句话：带宽越高越好。

什么是延迟？

延迟是指信号到达目的地和返回目的地所需的时间。

例如，延迟在在线游戏中扮演着重要角色。在低延迟的情况下，您的输入会像跳过障碍一样立即出现在屏幕上，因为在按下按钮、服务器确认您的操作和屏幕上呈现的返回确认之间的时间间隔很短。

对于高延迟，您将看到控制器输入和屏幕上产生的跳转之间的延迟，因为往返服务器需要更长的时间。这种延迟称为输入滞后。

延迟不仅仅是一个游戏问题。每次你向你的互联网连接发出请求（在谷歌上搜索、查看社交媒体等），它都会向服务器发送一个信号，让服务器检索信息，然后将其返回给你。由于这种情况通常发生得很快，所以延迟以毫秒为单位。

底线：延迟越低越好。

专业提示：

为了测试延迟，您的计算机可以向远程服务器发送少量数据以测量往返时间。例如，您可以使用Ping实用程序查看数据到达目的地和返回目的地所需的时间。游戏玩家使用它来确定哪台服务器的连接速度更快，或者找出他们在线游戏时动作迟缓的原因。此往返时间也称为“ping速率”

带宽和延迟对您的影响

游戏

大多数具有在线连接的游戏不需要非常快速的互联网连接，因此带宽对游戏体验的影响相当小（除非有很多人同时在同一连接上玩游戏）。

您需要播放的所有内容都已安装在您的计算机或控制台上。当您的游戏和服务器交换诸如控制器输入、世界状态、玩家坐标、玩家通信等信息时，互联网连接开始发挥作用。如果你在玩离线游戏或者没有多人游戏组件（如质量效应和辐射4），带宽甚至不是问题。

但是，正如我们前面提到的，延迟对于在线游戏的良好体验至关重要，特别是在快节奏的游戏中，如Fortnite和Overwatch。高延迟表现为延迟，可能导致输入和角色动作之间的显著延迟。换言之，你可能已经死了，而你仍然试图摆脱拍摄，但你不会知道它，直到你的连接赶上。

专业提示：缓慢的互联网是否让你成为团队中的薄弱环节？了解在线游戏需要多少速度。

流处理

由于流媒体涉及从服务器下载内容，带宽往往是视频和音频流媒体的主要因素。这是因为流媒体在您端几乎没有输入的情况下进行：您只需单击并等待。

低带宽通常有两种表现。当您的连接试图跟上内容的大小时，它将表现为痛苦的缓冲量。或者，它将显示为糟糕的视频质量，因为您的流媒体服务正试图弥补下载速度慢的问题。

专业提示：

缓冲是指流媒体下载停止时。开始播放流时，视频或音频将被下载并临时存储在播放设备上。一旦视频或音频启动，服务将继续在后台下载其余部分。如果下载因任何原因停止，视频或音频会暂停，屏幕上会显示“缓冲”消息。当有足够的视频或音频文件继续播放时，该消息消失。

视频聊天

视频聊天，如FaceTime或Skype，会受到低带宽和高延迟的负面影响。低带宽会影响你的聊天质量，使事情很难被看到。延迟将导致同步问题和冻结。

浏览

即使是最基本的，每天的网络浏览也不会受到不良互联网连接的影响。低带宽将导致页面缓慢加载并分段加载（就像以前的拨号时代一样）。

由于延迟很高，页面的加载速度可能会非常快，但在开始时会有令人抓狂的延迟，看起来什么都没有发生。

提高连接速度的技巧

如果你的互联网连接让你情绪低落，你可以做一些事情。

确保您的路由器设置是可靠的

登录调制解调器和路由器，确保您的设置没有造成瓶颈。大多数路由器和无线网关都有一个设置页面，您可以在其中更改密码、调整路由器使用的频道等。

通常，登录信息直接打印在设备底部的标签上。查看我们的《提高Wi-Fi速度指南》，了解更多有关操作的详细信息。

升级你的路由器

是的，我们明白了：这些东西是永恒的。但是，如果您仍然使用2008年的旧型号，很有可能您的无线连接无法发挥其真正的潜力。虽然新的路由器不能增加你计划的带宽，但它可以提高你的无线速度。

升级您的internet软件包

如果您已经升级了设备并调整了设置，但仍然没有达到您想要的速度，下一步就是升级到更快的internet软件包。不知道你需要多少速度？我们有一个方便的速度推荐工具来帮助实现这一点。

查找新的提供商

如果其他一切都失败了，你不能从你目前的供应商那里得到一笔好交易，那么也许是时候换一个新的供应商了。互联网服务领域的竞争非常激烈，大多数地方都至少有两个很好的提供商选择。

如果您不确定从哪里开始，我们将提供最快互联网提供商的综述。通过在下面的工具中输入邮政编码，您还可以查看所有可用选项。

结论是：带宽和延迟都至关重要

带宽和延迟对于良好的在线体验都是至关重要的，但两者之间的区别可能有点令人困惑。但是有了你新发现的知识，你可以利用你所知道的快速获得更好的互联网体验。

如果你想更多地了解互联网速度是如何工作的，请查看我们全面的互联网速度指南。

关于带宽与延迟的常见问题解答

延迟和ping速率之间有什么区别？

延迟和ping速率之间没有区别。两者都指在线执行操作和看到结果之间的延迟。

什么类型的internet连接具有最低的延迟？

一般来说，有线和光纤互联网的延迟最低，而卫星互联网的延迟最高。除此之外，路由器及其位置等其他因素也会影响使用Wi-Fi时的延迟水平。

什么是好的延迟？

对于一般的浏览和流媒体，任何低于100毫秒的都可以。对于激烈的游戏，你会希望拍摄的最大50毫秒，但30毫秒以下将是理想的。

如何检查我的网速？

检查网速最简单、最快捷的方法是使用在线速度测试。这将告诉您当前的连接速度。你可以将其与你的计划宣传的内容进行比较，以帮助解决任何问题。

 

原文：https://www.highspeedinternet.com/resources/bandwidth-vs-latency-what-i…

本文：http://jiagoushi.pro/node/1520

讨论：请加入知识星球【超级工程师】或者微信【ceo_engr】或者QQ【449846958】

本指南提供了有关如何为Red Hat OpenStack平台环境构建脊椎叶网络拓扑的信息。这包括完整的端到端场景和示例文件，以帮助在您自己的环境中复制更广泛的网络拓扑。

1.1  棘叶（Spine and Leaf) 网络

Red Hat OpenStack平台的可组合网络架构允许您调整网络以适应流行的路由脊椎叶数据中心拓扑结构。在路由spine leaf的实际应用中，leaf通常表示为数据中心机架中的可组合计算或存储角色，如图1.1“路由spine leaf示例”所示。Leaf 0机架有一个云下节点、控制器和计算节点。将可组合网络呈现给已分配给可组合角色的节点。在这个图表中：

• 将Storage Leaf网络提供给Ceph存储和计算节点。
• Network Leaf代表您可能要组成的任何网络的示例。

图1.1 路由脊椎叶示例

1.2 网络拓扑

路由的spine leaf裸机环境具有一个或多个支持第3层的交换机，这些交换机在单独的第2层广播域中的独立vlan之间路由通信。

本设计的目的是根据功能对流量进行隔离。例如，如果控制器节点在内部API网络上承载API，那么当计算节点访问API时，它应该使用自己版本的内部API网络。要使此路由工作，您需要强制内部API网络的流量使用所需接口的路由。这可以使用supernet路由进行配置。

例如，如果使用172.18.0.0/24作为控制器节点的内部API网络，则可以使用172.18.1.0/24作为第二个内部API网络，使用172.18.2.0/24作为第三个内部API网络，依此类推。因此，您可以有一个指向更大的172.18.0.0/16 supernet的路由，该supernet为每个第2层域中的每个角色使用本地内部API网络上的网关IP。

此方案使用以下网络：

表1.1 Leaf 0网络

Network	Roles attached	Interface	Bridge	Subnet
Provisioning / Control Plane	All	nic1	br-ctlplane (undercloud)	192.168.10.0/24
Storage	Controller	nic2		172.16.0.0/24
Storage Mgmt	Controller	nic3		172.17.0.0/24
Internal API	Controller	nic4		172.18.0.0/24
Tenant	Controller	nic5		172.19.0.0/24
External	Controller	nic6	br-ex	10.1.1.0/24

Table 1.2. Leaf 1 Networks

Network	Roles attached	Interface	Bridge	Subnet
Provisioning / Control Plane	All	nic1	br-ctlplane (undercloud)	192.168.11.0/24
Storage1	Compute1, Ceph1	nic2		172.16.1.0/24
Storage Mgmt1	Ceph1	nic3		172.17.1.0/24
Internal API1	Compute1	nic4		172.18.1.0/24
Tenant1	Compute1	nic5		172.19.1.0/24

Table 1.3. Leaf 2 Networks

Network	Roles attached	Interface	Bridge	Subnet
Provisioning / Control Plane	All	nic1	br-ctlplane (undercloud)	192.168.12.0/24
Storage2	Compute2, Ceph2	nic2		172.16.2.0/24
Storage Mgmt2	Ceph2	nic3		172.17.2.0/24
Internal API2	Compute2	nic4		172.18.2.0/24
Tenant2	Compute2	nic5		172.19.2.0/24

Table 1.4. Supernet Routes

Network	Subnet
Storage	172.16.0.0/16
Storage Mgmt	172.17.0.0/16
Internal API	172.18.0.0/16
Tenant	172.19.0.0/16

1.3 脊叶要求

要在具有第3层路由体系结构的网络上部署过云，必须满足以下要求：

第三层路由

网络基础设施必须配置路由以启用不同第2层网段之间的通信。这可以静态或动态配置。

DHCP中继

非云下本地的每个第2层段必须提供dhcp中继。必须将DHCP请求转发到连接undercloud的设置网段上的undercloud。

注意

undercloud使用两个DHCP服务器。一个用于裸机节点自省，另一个用于部署过云节点。配置DHCP中继时，请确保读取DHCP中继配置以了解要求。

1.4 棘叶限制

• 某些角色（如控制器角色）使用虚拟IP地址和群集。此功能背后的机制需要这些节点之间的第2层网络连接。这些节点都放在同一个叶中。
• 类似的限制适用于Networker节点。网络服务使用虚拟路由器冗余协议（VRRP）在网络中实现高可用的默认路径。由于VRRP使用虚拟路由器IP地址，因此必须将主节点和备份节点连接到同一L2网段。
• 在使用带有VLAN分段的租户或提供程序网络时，必须在所有Networker和计算节点之间共享特定的VLAN。

注意

可以使用多组Networker节点配置网络服务。每组网络共享路由，VRRP将在每组Networker节点中提供高可用的默认路径。在这种配置中，共享网络的所有Networker节点必须位于同一L2网段上。

 

原文：https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html-single/spine_leaf_networking/index#alternative-provisioning-network-methods

本文：http://jiagoushi.pro/openstack-spine-leaf-networking-introduction

讨论：请加入知识星球【首席架构师圈】或者加小号【intelligenttimes】

 

本节包含有关其他方法的信息，这些方法用于配置配置配置网络，以适应带有可组合网络的路由spine leaf。

3.1 VLAN配置网络

在本例中，控制器通过供应网络部署新的超云节点，并在第3层拓扑中使用VLAN隧道（参见图3.1，“VLAN供应网络拓扑”）。这允许控制器的DHCP服务器向任何叶发送DHCPOFFER广播。为了建立这个隧道，在机架顶部（ToR）叶交换机之间中继VLAN。在这个图中，StorageLeaf网络呈现给Ceph存储和计算节点；NetworkLeaf表示您可能要组成的任何网络的示例。

图3.1 VLAN配置网络拓扑

3.2 VXLAN供应网络

在本例中，控制器通过供应网络部署新的过云节点，并使用VXLAN隧道跨越第3层拓扑（参见图3.2，“VXLAN供应网络拓扑”）。这允许控制器的DHCP服务器向任何叶发送DHCPOFFER广播。要建立此通道，请在机架顶部（ToR）叶型交换机上配置VXLAN端点。

图3.2。VXLAN配置网络拓扑

原文：https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html-single/spine_leaf_networking/index#alternative-provisioning-network-methods

本文：

讨论：请加入知识星球【首席架构师圈】或者微信小号【intelligenttimes】

 

有两个基于NGINX的Ingress控制器实现：你可以在这个repo中找到的那个（nginxinc / kubernetes-ingress）和一个来自kubernetes / ingress-nginx repo的实现。在本文档中，我们将解释这些实现之间的主要区别。此信息可帮助您根据需求选择适当的实现，或从一个实现转移到另一个实现。

我用的是哪一个？

如果您不确定正在使用哪个实现，请检查正在运行的Ingress控制器的容器映像。对于nginxinc / kubernetes-ingress Ingress控制器，其Docker镜像在DockerHub上发布，可作为nginx / nginx-ingress使用。

关键差异

下表总结了nginxinc / kubernetes-ingress和kubernetes / ingress-nginx Ingress控制器之间的主要区别。请注意，该表有两列用于nginxinc / kubernetes-ingress Ingress控制器，因为它可以与NGINX和NGINX Plus一起使用。有关使用NGINX Plus的nginxinc / kubernetes-ingress的更多信息，请阅读此处。

Aspect or Feature	kubernetes/ingress-nginx	nginxinc/kubernetes-ingress with NGINX	nginxinc/kubernetes-ingress with NGINX Plus
Fundamental
Authors	Kubernetes community	NGINX Inc and community	NGINX Inc and community
NGINX version	Custom NGINX build that includes several third-party modules	NGINX official mainline build	NGINX Plus
Commercial support	N/A	N/A	Included
Load balancing configuration via the Ingress resource
Merging Ingress rules with the same host	Supported	Supported via Mergeable Ingresses	Supported via Mergeable Ingresses
HTTP load balancing extensions - Annotations	See the supported annotations	See the supported annotations	See the supported annotations
HTTP load balancing extensions -- ConfigMap	See the supported ConfigMap keys	See the supported ConfigMap keys	See the supported ConfigMap keys
TCP/UDP	Supported via a ConfigMap	Supported via a ConfigMap with native NGINX configuration	Supported via a ConfigMap with native NGINX configuration
Websocket	Supported	Supported via an annotation	Supported via an annotation
TCP SSL Passthrough	Supported via a ConfigMap	Not supported	Not supported
JWT validation	Not supported	Not supported	Supported
Session persistence	Supported via a third-party module	Not supported	Supported
Canary testing (by header, cookie, weight)	Supported via annotations	Supported via custom resources	Supported via custom resources
Configuration templates *1	See the template	See the templates	See the templates
Load balancing configuration via Custom Resources
HTTP load balancing	Not supported	See VirtualServer and VirtualServerRouteresources.	See VirtualServer and VirtualServerRouteresources.
Deployment
Command-line arguments *2	See the arguments	See the arguments	See the arguments
TLS certificate and key for the default server	Required as a command-line argument/ auto-generated	Required as a command-line argument	Required as a command-line argument
Helm chart	Supported	Supported	Supported
Operational
Reporting the IP address(es) of the Ingress controller into Ingress resources	Supported	Supported	Supported
Extended Status	Supported via a third-party module	Not supported	Supported
Prometheus Integration	Supported	Supported	Supported
Dynamic reconfiguration of endpoints (no configuration reloading)	Supported with a third-party Lua module	Not supported	Supported

 

笔记：

* 1  -  Ingress控制器用于生成NGINX配置的配置模板是不同的。 因此，对于相同的Ingress资源，生成的NGINX配置文件与一个Ingress控制器不同，这反过来意味着在某些情况下NGINX的行为也可能不同。

* 2  - 由于命令行参数不同，因此无法使用相同的部署清单来部署Ingress控制器。

如何交换入口控制器

如果您决定交换Ingress控制器实现，请准备好处理上一节中提到的差异。 至少，您需要开始使用其他部署清单。

原文：https://github.com/nginxinc/kubernetes-ingress/blob/master/docs/nginx-ingress-controllers.md

本文：http://pub.intelligentx.net/differences-between-nginxinckubernetes-ingress-and-kubernetesingress-nginx-ingress-controllers

讨论：请加入知识星球或者小红圈【首席架构师圈】

使用Active Directory管理生态系统

在任何商业组织中，都有一个复杂的、不断发展的用户、计算机、文件服务器、打印机、应用程序等生态系统。这些系统和资源可能分布在多个物理网络、站点或多个国家。即使是一个小组织也可能希望为其外部伙伴提供对其系统的访问。管理所有这些可能会很快成为一个行政头痛。

Microsoft（R）活动目录（AD）是一套工具，可帮助系统管理员管理这些复杂的网络生态系统。其基本目的是集中系统管理，帮助用户快速找到和使用组织内的资源。

活动目录产品组合

简单地说，AD常常被比作计算机系统的一种公司电话簿形式：提供一个集中的目录，存储有关网络资源的信息，以便用户能够查找并以正确的权限安全地访问这些资源。因此，例如，用户可以很容易地找到他们最近的打印机并获得使用它的权限。

事实上，这只是一个方面，而AD是一个技术组合，提供以下广泛的认证、标识和安全设施：

• 系统目录-活动目录®域服务（AD DS）
• 管理用户访问和使用内容的权限–活动目录®权限管理服务（AD RMS）
• 跨组织和跨组织之间的用户身份联合–活动目录®联合服务（AD FS）
• 处理数字证书–活动目录®证书服务（AD CS）

AD提供了一种集中处理所有这些问题的方法。它使系统和资源管理更加高效和安全，提高用户生产力，保护知识产权，并有助于解决公司政策和法规遵从性问题。

应用程序集成

许多关键的企业应用程序使用AD服务与更广泛的网络生态系统集成，并改进它们为用户提供的支持。主要示例包括Microsoft自己的企业产品，如Exchange、Office和SQL Server，以及第三方产品，如Adobe®Acrobat。

活动目录的体系结构

广告分为两层：物理层和逻辑层。物理层描述并控制AD在Windows®操作系统体系结构中的工作方式（例如，它可以访问哪些低级操作系统服务和组件）。逻辑层更加概念化，允许描述组织及其运作方式。

活动目录物理层

在物理上，AD是一个网络操作系统，建立在Windows Server®的各种迭代之上。它是安全子系统的一部分，使用了一些关键组件，如Kerberos身份验证和NET LOGON。AD使用轻量级目录访问协议（LDAP）作为其主要协议，LDAP是一种行业标准。

物理层还描述了目录信息如何存储在硬盘上，关键目录信息（如核心AD Ntds.dit文件）存储在提供服务的物理服务器上的数据库文件中。

Active Directory®还利用了域名系统（DNS），即互联网上使用的基于标准的命名和定位系统。这意味着AD需要访问DNS服务器，尽管几乎所有的组织都已经在运行一个用于Internet地址解析的服务器。Microsoft®提供了一个DNS服务器，可以在安装AD时进行配置，但也可以使用其他现有解决方案（例如Berkeley Internet Name Domain（BIND））。

活动目录逻辑层

逻辑层确定存储在这些物理组件中的数据的概念结构以及如何访问这些数据。在设计这个层时，目的是描述一个组织及其员工是如何组织和工作的，而不是担心诸如站点之间的网络连接等物理细节。

本质上，被管理的所有内容（用户、打印机、服务器等）都被认为是AD存储中的一个对象，并且具有相关的属性（遵循基本的LDAP协议模型）。因此，例如，用户对象将具有诸如名字和中间名之类的属性。逻辑层的能力来自于将对象组织到层次结构和组中，以及分配类或类型的能力。

因此，例如，AD可以设置组策略、规则和权限，这些策略、规则和权限适用于整个生态系统中的所有用户和计算机，或应用于较小的用户子组。使用组策略，管理员可以控制网络环境的许多方面，例如用户在系统上的行为（例如定义桌面配置，例如节能）、控制谁有权访问哪些资源（例如共享文件夹）和自动化关键任务（例如更新应用程序）。

逻辑层可能会与许多构建块（域、组、目录树和林、命名模式和组织单元）一起变得相当复杂。这些逻辑结构可以按层次结构进行组织，因此，例如，林就是树的集合。对象之间的安全安排和信任在这些不同类型的构建块中有所不同。

设计和规划逻辑层是一项复杂的任务，但如果做得正确，它可以让AD支持组织更有效地运作，并有助于行政管理和安全。

总之，AD是一套工具，有助于对用户和网络资源进AD行有效的管理和管理，支持一些关键业务流程，如数字权限管理。在许多组织中，它已经成为一项关键任务服务，因此需要认真考虑灾难恢复和威胁保护。

原文：https://activereach.net/support/knowledge-base/connectivity-networking/understanding-active-directory-its-architecture/

本文：http://jiagoushi.pro/node/939

讨论：请加入知识星球【首席架构师圈】或者微信圈子【首席架构师圈】

应用交付网络

应用程序交付网络是创建技术框架的实践，这些技术协同工作以为网络应用程序提供适当级别的可用性，安全性，可见性和加速。这些应用程序交付网络技术具有自己的专有CPU，通常驻留在网络端点。它们通过各种优化技术增强了跨Internet的应用程序交付。

什么是应用交付控制器？

顾名思义，应用交付控制器（ADC）提供应用服务并控制客户端和应用服务器之间的通信。在此上下文中，术语控制器是管理（或控制）计算系统（例如客户端设备和应用程序服务）之间的数据流，优化应用程序性能，可用性和安全性的功能。

ADC充当反向代理

客户端请求与ADC交互，ADC充当反向代理，代表客户端与应用程序服务器交互。由于ADC位于数据路径中，因此可以在流中执行应用程序加速，监视，管理和安全服务。

下图显示了一种常见配置，ADC位于DMZ网络子网中，检查并保护驻留在Internet上的客户端的网络访问。

 

Application Delivery Controller服务

服务器负载平衡（SLB）

服务器负载均衡器是许多企业和云基础架构的标准组成部分。 SLB系统提供应用程序：

• 可用性
• 可扩展性
• 性能

健康监测

由于ADC位于客户端和应用程序之间的数据路径中，因此可以看到应用程序行为和性能。 ADC系统可以监控，分析和记录进入应用程序的客户端请求以及应用程序响应。通常只有在收到性能问题后，才能通过最终用户轻松获得此可见性。 ADC系统可以监控和分析应用程序或服务器不良行为。

应用程序加速

应用程序加速使用多种技术来提高网络连接的应用程序性能和响应时间。这些技术包括数据压缩，高速缓存，连接多路复用和流量整形。

加速技术包括网络优化。网络优化克服了WAN延迟，数据包丢失和带宽拥塞等网络问题。网络优化还解决了对应用程序性能产生负面影响的挑战，例如“聊天”协议，例如： HTTP和CIFS / SMB，以及TCP / IP堆栈实现中的低效率。

SSL卸载

ADC通常具有SSL卸载功能，可将终止SSL会话的负载从应用服务器移至ADC。 ADC从应用程序服务器中移除负载，应用程序服务器通常在软件中执行SSL操作，并在驻留在ADC平台中的SSL硬件平台中执行此操作。

DDoS保护

DDoS攻击频率逐年增加三到四倍。这些攻击会对企业造成严重破坏，通常会花费数百万美元。

ADC平台通常提供DDoS预防和缓解系统，可以阻止网络边缘的攻击，防止这些攻击到达应用服务器。当ADC启用SSL卸载时，可以在ADC上安全地检测和阻止使用SSL隧道流量的DDoS攻击，而不会暴露应用程序和服务器。

DNS应用程序防火墙

已部署ADC以保护，负载平衡并确保Internet和DNS服务提供商对关键DNS基础架构的可用性。

保护和优化DNS基础架构的挑战

• 攻击DNS基础结构的恶意和无效流量
• DNS基础设施上的分布式DDoS攻击
• 增加DNS基础架构压力（增长和浏览器）

减少受保护服务器的负载（最高70％）

• 仅允许合法的DNS协议流量，可以拒绝非DNS流量
• 通过高性能浪涌保护可预测负载
• 增加受保护的DNS服务器容量，同时释放资源以解决增加的负载

提高后端服务器的安全性

• 可选的隔离（重定向）恶意或无效流量以供检查
• 无论DDoS攻击如何，都可以保证正常运行时间（基于硬件的SYN Flood保护，每秒高达5000万）

Web应用防火墙

一些ADC产品内置在Web应用程序防火墙（WAF）中。 WAF用于防范Web攻击并保护应用程序免受安全漏洞的影响。这些安全威胁包括跨站点脚本（XSS），SQL注入，cookie中毒，数据形式溢出以及各种格式错误的HTTP数据包。一些供应商在此许可证中包含此功能。

中心认证

应用程序交付控制器可以充当中央身份验证点。客户端可以将其身份验证会话发送给ADC，然后ADC负责验证身份验证和授权。 ADC系统可以与各种AAM系统连接。提供中央身份验证服务可以从此处理负载中卸载应用程序服务器，并降低应用程序环境的复杂性。

多租户支持

SDN和多租户网络很复杂，需要网络系统了解这些新协议和技术。覆盖SDN协议（如VxLAN和NVGRE）封装了IP数据流。网络设备（如ADC系统）通常需要在这些封装的网络流中查看，以正确控制和控制流量。

相关条款

 

• 硬件负载均衡器
• 网络负载均衡器

 

原文：https://www.a10networks.com/blog/application-delivery-controller/

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】

此博客文章是来自nginx.conf 2017的NGINX团队成员的六个主题演讲之一。这些博客文章共同介绍了NGINX应用程序平台，新产品以及产品和战略更新。

博客文章是：

• Keynote: “Speeding Innovation”, Gus Robertson (video here)
• NGINX Product Roadmap, Owen Garrett (video here)
• Introducing NGINX Controller, Chris Stetson and Rachael Passov (video here)
• This post: Introducing NGINX Unit, Igor Sysoev and Nick Shadrin (video here, in‑depth demo here, integration with the OpenShift Service Catalog here)
• The Future of Open Source at NGINX, Ed Robinson and Owen Garrett (video here)
• NGINX Amplify is Generally Available, Owen Garrett (video here)

Nick Shadrin：现代应用已发生变化。 他们从非常小的网站，从设计为一件事的简单应用程序，到非常大而复杂的网络属性，发展壮大。 今天，它们由多个部分组成：您创建小型服务，然后将它们连接在一起。 随着基础架构的新变化，您还可以轻松地上下扩展。 您可以创建新容器 - 云中的新计算机 - 以及与应用程序的连接。 应用程序部件之间的连接非常重要。

作者：Matt Britt [CC BY 2.5]来自Wikimedia Commons

使用NGINX，您已经知道如何连接到您的应用程序。 您知道应用程序的工作原理以及与其连接的工作方式。 但是通过Unit项目，我们进一步深入到应用程序代码。 它为您提供了运行应用程序和运行应用程序代码的平台。

我们研究了现有的解决方案，发现它们缺乏一些基础技术。 其中许多都很大，很慢，并且不适合云原生应用程序。

NGINX Unit从头开始构建。 它是由核心工程团队使用NGINX工程的核心原则构建的。 Unit是NGINX应用平台的重要组成部分。 对于单片应用程序和微服务应用程序，它的工作方式相同。 它为您提供了从旧式应用程序迁移和分离服务的方法。 它为您提供了一种统一的方式，不仅可以连接到您当前正在构建的应用程序，还可以连接到明天将要构建的应用程序。

我们来谈谈NGINX Unit为您提供的功能。

首先，它是一个专为云原生应用程序设计的全动态应用程序服务器。

“动态”是什么意思？使用NGINX，您熟悉众所周知的重载命令。你可能已经经常重装了。

当重新加载完成后，你就不会失去联系。你很好 - 应用程序正在运行。您可以通过重新加载整个服务器继续进行更改。但是，重新加载有时会对服务器资源造成负担，而且我们的许多大用户和客户都无法像他们希望的那样频繁地重新加载。

使用Unit，系统不会重新加载进程，它只会更改其内存的一部分以及特定更改所需的进程部分。它给你的是能够随时随地进行更改。

接下来是它是如何配置的。它是通过一个简单的API配置的。

今天，每个人都喜欢进行API调用以配置服务器。每个管理系统都了解这一点，我们构建了一个非常易于理解的API，它基于行业标准的JSON。

非常重要的是这个API可以远程使用。当您无法以远程方式配置服务器时，您在做什么？您正在构建一个小代理 - 一种各种类型的代理 - 以执行这些配置步骤。

使用Unit，您可以将API公开给您的专用网络和远程代理，以便以非常简单，本机和远程方式进行配置。

接下来，Unit是多语言。

它了解多种语言。我们支持PHP，Python和Go，其他语言即将推出。这给你的是能够在同一台服务器上同时运行用这些语言编写的任何代码。但更有趣的是，您可以在同一台服务器上运行同一语言的多个版本。

您是否曾将旧的PHP应用程序从PHP 5迁移到PHP 7？现在，它就像一个API调用一样简单。您是否曾尝试在Python 2.7和Python 3.3中运行相同的应用程序？我看到有些人在观众中大笑。是的，有时甚至不起作用。现在，我们为您提供了相同的平台，可以使用该应用程序理解的语言和语言版本来运行应用程序。有趣的是，这是如何实现的。

我会请NGINX的原作者Igor Sysoev到舞台上讨论NGINX Unit的架构。 Igor具有惊人的品质：Igor以一种基本的方式构建应用程序。他在更深层次上看待问题。当他在研究如何构建应用程序时，他没有任何先入为主或妥协。

伊戈尔，请上台。我们来谈谈NGINX Unit的架构。

Igor Sysoev：早上好。我的名字是Igor Sysoev。我是NGINX的原作者，NGINX公司的联合创始人，以及我们新项目Unit的架构师。

这是Unit的架构方案：所有部件都是一个系统中的独立过程。 出于安全原因，这些过程是隔离的; 只有主进程以root身份运行。 其他进程可以作为非特权用户运行。

这个架构非常复杂，所以我将详细介绍最重要的部分。

Unit的关键特性是动态配置。 性能与现有应用程序服务器相当。

“动态配置”是什么意思？ 这意味着根本没有实际的配置文件。 您使用UNIX域套接字或TCP套接字上的RESTful JSON API与Controller进程进行交互。 您可以一次上传整个配置，也可以只上传一部分。

您可以更改或删除配置的任何部分，Unit不会重新加载整个配置 - 只重新加载相关部分。 这意味着您可以根据需要随时更改配置。 当Controller进程接受更改配置的请求时，它将更新[full stored]配置并将相应的部分发送到路由器和主进程。

 

路由器进程有几个与客户端交互的工作线程。它们接受客户端的请求，将请求传递给应用程序进程，从应用程序获取响应，并将响应发送回客户端。每个工作线程都会轮询epoll或kqueue，并且可以异步处理数千个同时连接。

当Controller向路由器发送新配置时，路由器的工作线程开始使用新配置处理新的传入连接，而现有（旧）连接继续由工作线程根据先前的配置进行处理。

因此路由器工作线程可以与几代配置同时工作而无需重新加载。

当路由器收到尚未启动的应用程序的请求时，它会要求主进程启动该应用程序。目前，应用程序进程仅在需要时启动。稍后，我们将添加prefork功能。

因此，主进程分叉新进程，在新进程中动态加载所需的应用程序模块，设置适当的凭据，然后在新进程中运行应用程序代码。

模块系统允许您在一台服务器中运行不同类型的应用程序，甚至在一台服务器中运行不同版本的PHP或Python。

Go应用程序是不同的动物。典型的Go应用程序自己侦听HTTP端口。您必须在应用程序中构建所有内容，包括所有网络和管理功能。使用Unit，您可以在没有此附加代码的情况下控制应用程序。

对于PHP或Python应用程序，您根本不需要更改代码[使用Unit运行它]。对于Go应用程序，您进行了一些微小的更改：您必须为Unit导入Go包，在Go应用程序的源代码中仅更改两行（调用Unit包而不是标准HTTP包），并构建Go应用程序包。

当主进程需要运行Go应用程序时，它会分叉一个新进程并在新进程中执行静态构建的Go应用程序。

Unit包与标准Go HTTP包兼容，因此您的应用程序仍可作为独立的HTTP服务器运行，或作为Unit服务器的一部分运行。当它独立运行时，它会侦听HTTP端口并像往常一样处理HTTP请求。

当Go运行Go应用程序时，它不会侦听HTTP端口。相反，它与Unit路由器进程通信，该进程处理所有HTTP请求并在内部与Go应用程序通信。

路由器和应用程序进程通过Unix套接字对和几个共享内存段进行通信。 套接字对和共享内存段对于每个应用程序进程都是私有的，因此如果应用程序进程异常退出，路由器进程将正常处理此故障，并且不会影响其他进程和连接。

当Go应用程序由Unit运行时，它将与路由器进程通信。 路由器进程将处理所有HTTP请求，并在内部与应用程序的线程套接字对和共享段内存进行通信。

现在，Nick Shadrin将告诉您有关Unit API配置和未来路线图的更多信息。

尼克沙德林：谢谢，伊戈尔。

我是否告诉您使用NGINX Unit API很容易？ 嗯，是的，确实如此。

在这里，您可以看到Unit API的一个简单示例。我想谈谈它是如何配置的，以及如何使用此API对环境进行更改。

您可以定义的第一个对象是[在配置的应用程序部分中]的应用程序对象。您可以为其提供一个友好，用户友好的名称，并将应用程序的类型定义为语言和语言版本。然后，您可以根据应用程序类型为应用程序定义其他参数。 PHP应用程序有一些特定的参数。 Go应用程序将具有一些其他参数。

您还可以使用UNIX系统中组名称的不同用户名定义应用程序，以便在您的环境中出于安全原因将它们分开。

除了定义应用程序之外，您还将定义侦听器，侦听器将是应用程序的IP地址和/或端口。

然后指定特定侦听器如何绑定到您定义的应用程序。您可以创建许多侦听器和许多应用程序，并以您喜欢的方式将它们绑定在一起。

现在，你如何做出改变？第一种也是最简单的方法是重新加载服务器。你可能不想这样做。您可以将整个JSON有效负载作为PUT请求发送到NGINX Unit控件套接字，或者您可以逐个进行更改，通过自己的URL分别访问每个对象和每个字符串。我们为您提供灵活的变更方式。

这就是你现在拥有的。我们来谈谈这个项目的计划。

昨天，我们在开源中发布了NGINX Unit。它可以在公共测试版中使用。我们鼓励每个人尝试并使用它。

我们现在的首要任务是为您提供稳定版本和稳定代码的记录，我们希望您对NGINX装置的信心与NGINX一样。

我们将向Unit添加一长串新语言，但我们将要开发的第一批语言是Java和Node.js.一旦我们从社区获得更多语言和更多不同语言的贡献，您将看到扩展NGINX单元以支持您喜欢的应用程序语言非常容易。

接下来，我们将围绕HTTP / 2和更多HTTP功能添加功能。对于服务网格和服务到服务通信，我们将直接向NGINX单元添加代理和网络功能。

昨天，我们将代码上传到GitHub并公开发布给所有人。我们已经在社交媒体上看到了数百条评论。我们是这个项目的黑客新闻的头条新闻。

我们有数百颗星。我们已经在GitHub仓库中创建了拉取请求和问题。社区的反应非常热烈，自项目发布以来只有24小时。

我们鼓励您前往GitHub开始浏览代码，阅读并为其做出贡献。 我们将与您一起制作此软件，NGINX Unit核心工程团队将与您一起处理拉取请求和GitHub问题。

现在，让我们看看我们准备了哪些其他资源，以便您可以开始使用NGINX Unit。

我们在unit.nginx.org上传了文档，代码也可以在我们的标准Mercurial存储库和GitHub存储库中找到。您可以使用众所周知的处理NGINX项目的过程或使用GitHub过程来为代码做出贡献。

今天，在休息之后，我们将在这个会议室的NGINX部门进行深度探讨。在深度潜水课程中，我们不会有任何幻灯片。当我们处理项目的现场演示时，我们发现为了向您展示所有功能以及如何使用它，演示实际上将采用整个会话。

准备好看到很多命令行输出和许多在同一服务器上运行多个PHP，Python和Go应用程序的新方法。如果您想在邮件列表中与我们合作，请发送电子邮件至unit@nginx.org。它已经可用，您可以通过网络订阅，也可以发送电子邮件至unit-subscribe@nginx.org。

对于我们的NGINX Plus商业用户来说更令人惊奇的是，他们已经在NGINX的NGINX技术表上拥有了这个惊人的通信渠道。如果您对NGINX Unit有疑问，可以使用您已知的相同支持渠道询问他们。

这就是我今天对你有关NGINX Unit的看法。让我们一起构建软件，让我们看看它是如何工作的，让我们看看如何使用Unit运行新的应用程序。谢谢。

 

原文：https://www.nginx.com/blog/introducing-nginx-unit/

本文：http://pub.intelligentx.net/introducing-nginx-unit

讨论：请加入知识星球或者小红圈【首席架构师圈】

应用程序交付控制器（ADC）是数据中心中的计算机网络设备，通常是应用程序交付网络（ADN）的一部分，它帮助执行常见任务，例如由Web加速器完成的任务，以从Web服务器本身移除负载。 许多还提供负载平衡。 ADC通常放置在外部防火墙或路由器与Web场之间的DMZ中。

特征

一个常见的误解是ADC是一种先进的负载均衡器。 这不是一个充分的描述。 ADC是一种网络设备，可帮助站点引导用户流量，以消除两台或多台服务器的多余负载。 实际上，ADC包括许多OSI第3-7层服务，包括负载平衡。 大多数ADC中常见的其他功能包括SSL卸载，Web应用程序防火墙，NAT64，DNS64和代理/反向代理等。 它们倾向于提供更高级的功能，例如内容重定向以及服务器运行状况监视。

ADC供应商

有许多类型的ADC供应商。 纯软件ADC供应商包括Avi Networks，KEMP Technologies，Buoyant，NGINX，Snapt Inc，LiteSpeed Technologies和Pulse Secure。 传统的ADC供应商包括A10 Networks，F5 Networks和Citrix Systems。 随着市场的发展，将会有越来越多的供应商提供云集成和以软件为中心而非基于硬件。

历史

第一代ADC从2004年左右开始，提供简单的应用加速和负载平衡。 2006年，ADC开始应用高级应用服务，如压缩，缓存，连接多路复用，流量整形，应用层安全，SSL卸载和内容交换，以及服务器负载均衡等服务，优化和优化的集成服务框，架安全的业务关键应用程序流

 

市场

到2007年，许多公司都提供了应用程序加速产品，例如F5 Networks，Juniper Networks，Microsoft，KEMP Technologies，AVANU WebMux，Snapt Inc和aiScaler。[2]思科系统公司提供应用交付控制器，直到2012年离开市场。像F5 Networks，Radware和Citrix这样的市场领导者在过去几年中一直在从思科获得市场份额。[3]

ADC市场细分为两大领域：1）通用网络优化和2）应用/框架特定优化。这两种类型的设备都可以提高性能，但后者通常更了解最适合特定应用程序框架的优化策略，例如，专注于ASP.NET或AJAX应用程序。

 

原文：https://en.wikipedia.org/wiki/Application_delivery_controller

本文：http://pub.intelligentx.net/application-delivery-controller-0

讨论：请加入知识星球或者小红圈【首席架构师圈】

 

不久前，我的队友Yariv在博客中介绍了OpenDNS智能代理，该代理使我们能够超越DNS层并阻止恶意HTTP通信。 此后，我们的团队一直专注于其他项目，例如拥有并整合了我们基础架构中最古老的部分之一，即着陆器，从而释放了70多个服务器，以及一些我们将要讨论的令人兴奋的新功能 关于什么时候开始

今天，我想更详细地介绍智能代理及其支持的技术，即Nginx。

按照惯例，代理是在操作系统的网络设置中或在特定程序（例如HTTP代理的Chrome或Firefox）中明确配置的。

此外，协议还可以确保代理服务器始终可以在请求时确定客户端的预期目的地。但是，正如Yariv在他的帖子中所解释的那样，我们采用了一种非常规的方法，而不是代理所有内容（无论是否是显性的），而是通过DNS层选择性地将对可疑域的请求重新路由到我们的代理。这种选择性对于减少延迟，负载和影响非常有用，但同时也带来了一些有趣的工程挑战-主要围绕识别用户并确定原始目的地。

例如，当用户尝试浏览到“ some-website.net”时，如果该域被归类为可疑，则OpenDNS解析器将返回最近的Intelligent Proxy服务器的IP地址。客户，例如Firefox或Chrome对此一无所知，并假设接收到的IP地址属于实际托管“ some-website.net”的服务器。对于纯HTTP，很容易确定原始目标是什么，因为HTTP / 1.1要求在每个HTTP请求中设置Host标头，现代浏览器将正确包含此标头。例如，共享主机提供商在为单个IP后面的多个网站提供服务时依赖于此标头。同样，可以利用TLS协议的服务器名称指示（SNI）扩展来代理HTTPS通信。对于其他端口和协议，此过程更为复杂（甚至不可能）。

另一个重要的概念是“正向”代理与“反向”代理的思想。前向代理服务于一组客户端，充当单个访问点并代表客户端查询原始服务器。如前所述，这是在操作系统或Firefox之类的浏览器中配置代理时使用的类型。

反向代理的作用相反，它充当多个服务器组件（例如CGI脚本，文件服务器或数据库）的单点访问。这些代理也通常用作负载平衡器和SSL终结点。

基于此，在服务已路由到它的客户端请求时，我们的智能代理是前向代理。但是它在内部也有一些反向代理，特别是当我们添加新功能和新的数据检查层时。一开始我也提到过，我们选择的技术是Nginx，熟悉Nginx的读者会知道它的设计纯粹是一种反向代理。

在下一篇文章中，我将讨论我们因此而采取的更多非常规方法，以及我们必须解决的挑战。

 

原文：https://umbrella.cisco.com/blog/2015/09/18/lets-talk-about-proxies/

本文：http://jiagoushi.pro/lets-talk-about-proxies

讨论：请加入知识星球或者微信圈子【首席架构师圈】

当我刚开始使用OpenDNS时，我的首要任务是弄清楚Nginx的工作方式，并为其编写一个自定义C模块来处理一些业务逻辑。 Nginx将反向代理到Apache Traffic Server（ATS），它将执行实际的正向代理。 这是一个简化图：

事实证明，Nginx易于理解和使用。 这与ATS相反，后者更大，更复杂，而且简直不好玩。 结果，“为什么我们不整个使用Nginx？”成为一个流行的问题，尤其是在确定代理将不进行任何缓存之后。

正向代理
尽管Nginx是旨在与明确定义的上游一起使用的反向代理：

http {
 upstream myapp1 {
  server srv1.example.com;
  server srv2.example.com;
  server srv3.example.com;
 }

 server {
  listen 80;
  location / {
   proxy_pass http://myapp1;
  }
 }
}

也可以将其配置为基于某些变量使用上游，例如Host标头：

http {
 server {
  listen 80;
  location / {
   proxy_pass http://$http_host$request_uri;
  }
 }
}

这实际上工作得很好。 主要警告是Host标头可以匹配配置中的预定义上游{}（如果存在）：

http {
 ...
 upstream foo {
  server bar;
 }
 ...
 server {
  listen 80;
  location / {
   proxy_pass http://$http_host$request_uri;
  }
 }
}

然后，这样的请求将匹配foo并被代理到bar：

GET / HTTP/1.1
Accept: */*
Host: foo

可以通过在自定义模块中使用新变量来扩展此方法，而不是使用内置的$ http_host和$ request_uri进行更好的目标控制，错误处理等。

一切工作都非常好-请注意，这是一个HTTP（端口80）代理，在此我们不考虑HTTPS情况。 一方面，Nginx无法识别显式HTTPS代理中使用的CONNECT方法，因此将永远无法工作。 正如我在之前的博客文章中提到的那样，我们的智能代理通常采用一种更加非常规的方法。

一个大问题是性能。 我们使用ATS进行的初始负载测试得出的数据少于理想值。 Nginx的“ hack”对其性能有没有影响？

负载测试

跳过更详细的信息，我们的设置使用wrk作为负载生成器，并使用自定义C程序作为上游。 定制上游是非常基本的。 它所做的就是接受连接，并通过静态二进制Blob响应任何看起来像HTTP的请求。 永远不会显式关闭连接，以消除不必要的额外TCP会话导致的结果中的任何潜在偏差。

我们首先通过直接加载上游服务器来建立基准：

Running 30s test
 10 threads and 100 connections
 Thread Stats Avg Stdev Max +/- Stdev
 Latency 3.27ms 680.48us 5.04ms 71.95%
 Req/Sec 3.21k 350.69 4.33k 69.67%
 911723 requests in 30.00s, 3.19GB read
 100 total connects (of which 0 were reconnects)
Requests/sec: 30393.62
Transfer/sec: 108.78MB

一切看起来都不错，wrk按预期创建了100个连接，并设法每秒挤出3万个请求。

现在，让我们通过Nginx转发代理（2个工作组）进行重复：

Running 30s test
 10 threads and 100 connections
 Thread Stats Avg Stdev Max +/- Stdev
 Latency 6.42ms 14.37ms 211.84ms 99.50%
 Req/Sec 1.91k 245.53 2.63k 83.75%
 552173 requests in 30.00s, 1.95GB read
 5570 total connects (of which 5470 were reconnects)
Requests/sec: 18406.39
Transfer/sec: 66.53MB

这几乎使可能的吞吐量减半。

通过手动请求，我们发现通过Nginx并不会真正增加任何明显的延迟。 Nginx工作人员在测试期间获得了接近100％的CPU使用率，但是增加工作人员人数并没有多大帮助。

上游情况如何，在两种情况下会看到什么？

快速更新以打印一些统计信息后，在直接情况下一切看起来都很好-wrk和上游服务器报告的数字符合预期。 但是，在查看上游服务器统计信息时，我们在代理情况下发现了一些令人吃惊的事情：

status: 552263 connects, 552263 closes, 30926728 bytes, 552263 packets

看起来Nginx为往上游的每个请求创建了一个新连接，尽管wrk仅向下游进行了100个连接…

深入Nginx核心并更全面地阅读文档，事情开始变得有意义。 Nginx是一个负载均衡器，其中“负载”等于请求，而不是连接。连接可以发出任意数量的请求，重要的是在后端之间平均分配这些请求。就目前而言，Nginx在每个请求之后关闭上游连接。上游keepalive模块尝试通过始终保持一定数量的持久连接保持打开状态来对此进行轻微补救。 Nginx Plus提供了诸如会话持久性（Session Persistence）之类的额外功能（顺便说一句，还存在一个等效的开源模块）—使请求可以更一致地路由到相同的上游。

我们真正想要的是客户端及其各自上游之间的一对一持久连接映射。在我们的案例中，上游是完全任意的，我们要避免创建不必要的连接，更重要的是，不要以任何方式“共享”上游连接。我们的会议是整个客户连接本身。

补丁

该解决方案非常简单，我们已经在Github 上提供了该解决方案。

通过此更改重新运行负载测试，我们可以获得更好的结果，概述了保持TCP连接持久性并避免那些昂贵的打开/关闭操作的重要性：

Running 30s test
 10 threads and 100 connections
 Thread Stats Avg Stdev Max +/- Stdev
 Latency 10.82ms 48.67ms 332.65ms 97.72%
 Req/Sec 3.00k 505.22 4.46k 95.81%
 854946 requests in 30.00s, 3.02GB read
 8600 total connects (of which 8500 were reconnects)
Requests/sec: 28498.99
Transfer/sec: 103.01MB

上游的数字与wrk的数字匹配：

status: 8600 connects, 8600 closes, 47882016 bytes, 855036 packets

但是，仍然存在问题。有8600个连接，而不仅仅是100个。 Nginx决定关闭上游和下游的许多连接。当进行调试以查看原因时，我们最终追溯到“ lingering_close_handler”：

...
nginx: _ngx_http_close_request(r=0000000000C260D0) from ngx_http_lingering_close_handler, L: 3218
nginx: ngx_http_close_connection(00007FD41B057A48) from _ngx_http_close_request, L: 3358
...

由于即使使用此行为，整体效果还是令人满意的，因此我暂时不这样做了。

收盘中

我们已经将Nginx作为生产中的正向HTTP代理运行了一段时间，几乎没有问题。我们希望继续扩展Nginx的功能，并推动新的界限。请留意未来的博客文章和代码片段/补丁。

*这是一个重写的补丁程序（原始补丁有点笨拙），这个新代码最近才投入生产。如果有任何问题，我将进行任何调整以更新公共补丁。

 

原文：https://umbrella.cisco.com/blog/2015/11/03/lets-talk-about-proxies-pt-2-nginx-as-a-forward-http-proxy/

本文：http://jiagoushi.pro/node/917

讨论：请加入知识星球或者微信圈子【首席架构师圈】