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】

这是这个星球上DNS最佳实践和技巧最全面的列表。

在本指南中，我将分享我在DNS安全性、设计、性能等方面的最佳实践。

目录：

• DNS最佳实践
• 至少有两个内部DNS服务器
• 使用活动目录集成区域
• 域控制器上的最佳DNS顺序
• 加入域的计算机应仅使用内部DNS服务器
• 将客户端指向最近的DNS服务器
• 配置DNS记录的老化和清除
• 设置PTR记录
• 根提示vs转发（哪一个是最好的）
• 启用调试日志记录
• 对别名使用CNAME记录（而不是记录）
• DNS最佳实践分析器
• Bones:DNS安全提示

警告：我不建议在未经您的组织测试和批准的情况下对DNS等关键服务进行更改。对于这些类型的更改，您应该遵循更改管理流程。

 

至少有两个内部DNS服务器

在小到大的环境中，应该至少有两个DNS服务器用于冗余。DNS和Active Directory是关键的服务，如果它们失败了，您将遇到重大问题。拥有两台服务器将确保DNS在另一台服务器出现故障时仍能正常工作。

在一个Active Directory域中，一切都依赖DNS来正常工作。甚至浏览互联网和访问云应用程序都依赖于DNS。

我经历了一个完整的域控制器/DNS故障，我不是在开玩笑，当我说几乎所有的工作都停止了。

在上图中，我的站点有两个域控制器和DNS服务器。客户端配置为使用DHCP，DHCP服务器将自动为客户端配置主DNS服务器和辅助DNS服务器。如果DC1/DNS关闭，客户端将自动使用其辅助DNS来解析主机名。如果DC1关闭，并且没有内部辅助DNS，客户端将无法访问电子邮件、应用程序、internet等资源。

一句话：通过拥有多个DNS/Active Directory服务器，确保有足够的冗余。

使用活动目录集成区域

为了使多个DNS服务器的部署更容易，您应该使用Active Directory集成区域。只有在域控制器上配置了DNS，才能使用AD集成区。

AD集成区具有以下优势：

• 复制：AD集成区域将数据作为容器对象存储在AD数据库中。这允许将区域信息自动复制到其他域控制器。区域信息被压缩，允许将数据快速、安全地复制到其他服务器。
• 冗余：由于区域信息是自动复制的，这可以防止DNS出现单点故障。如果一个DNS服务器失败，另一个服务器具有DNS信息的完整副本，并且可以解析客户端的名称。
• 简单性：AD集成区域自动更新，无需配置区域传输。这简化了配置，同时确保冗余到位。
• 安全性：如果启用安全动态更新，则只有经过授权的客户端才能更新其在DNS区域中的记录。简而言之，这意味着只有DNS域的成员才能在DNS服务器上注册自己。DNS服务器拒绝来自不属于域的计算机的请求。

域控制器上的最佳DNS顺序

我看过很多关于这个话题的讨论。在域控制器上DNS次序的最佳做法是什么？

如果你自己搜索，你会发现不同的答案，但大多数人建议配置如下。

这也是微软的建议。

• 主DNS:设置为站点中的另一个DC
• 辅助DNS:使用环回地址设置为自身

让我们看一个真实的例子。

在上图中，我在纽约站点有两个域控制器/DNS。我已将DC1主DNS设置为其复制伙伴DC2。然后使用环回地址将辅助DNS设置为其自身。然后DC2主DNS设置为DC1，它的次DNS使用环回地址设置为自己。

Microsoft声称此配置提高了性能并增加了DNS服务器的可用性。如果首先将主DNS指向自身，则可能会导致延迟。

来源： https://technet.microsoft.com/en-us/library/ff807362(v=ws.10).aspx

加入域的计算机应仅使用内部DNS服务器

加入域的计算机应将主DNS和辅助DNS都设置为内部DNS服务器。外部DNS服务器无法解析内部主机名，因此这可能导致连接问题并阻止计算机访问内部资源。

让我们看一个例子，为什么这是一个糟糕的设置。

1. 客户端向内部服务器VEGAS发出请求。
2. 客户端决定联系其第二个DNS服务器，即8.8.8.8。它询问服务器主机维加斯的IP地址是什么。
3. 外部DNS对这个主机一无所知，因此不能提供IP地址。
4. 这将导致客户端无法访问VEGAS文件服务器。

通常，如果主DNS服务器可用，它将首先使用，但它可能没有响应，这可能导致使用辅助DNS。可能需要重新启动计算机才能切换回主DNS，这可能会导致用户受挫和呼叫帮助台。

建议的解决方案是有两个内部DNS服务器，并始终将客户端指向它们，而不是指向外部服务器。

将客户端指向最近的DNS服务器

这将最小化跨广域网链路的通信量，并为客户端提供更快的DNS查询。

在上图中，客户端计算机被配置为使用其站点上的DNS服务器。如果纽约的客户机被错误地配置为使用伦敦的DNS服务器，这将导致DNS性能下降。这将影响用户的应用程序、互联网访问等。我保证你的用户会抱怨一切都有多慢。

自动配置正确DNS服务器的最佳方法是使用DHCP。您应该为每个站点设置不同的DHCP作用域，其中包括该站点的主DNS服务器和辅助DNS服务器。

配置DNS记录的老化和清除

DNS老化和清除允许自动删除旧的未使用的DNS记录。这是一个分为两部分的过程：

• 老化：新创建的DNS记录将应用时间戳。
• 清除：根据配置的时间删除具有过时时间戳的DNS记录。

为什么需要这个？

有时计算机会用不同的IP地址注册多个DNS条目。这可能是由于计算机移动到不同的位置，计算机被重新映像，计算机被丢弃并添加回域。

有多个DNS条目将导致名称解析问题，从而导致连接问题。DNS老化和清除将通过自动删除未使用的DNS记录来解决此问题。

老化和清除仅适用于动态添加的DNS资源记录。

资源：

如何配置DNS老化和清除（清除过时的DNS记录）

为DNS区域设置PTR记录

PTR记录将IP地址解析为主机名。除非您正在运行自己的邮件服务器，否则可能不需要PTR记录。

但是…它们对故障排除和提高安全性非常有帮助。

有些系统（如防火墙、路由器和交换机）只记录IP地址。以windows防火墙日志为例。

在本例中，helpdesk正在排除打印机问题，并认为10.1.2.88是一台被防火墙阻止的打印机。因为我有PTR记录设置，所以可以使用nslookup命令快速查找它。

10.1.2.88解析为nodaway.ad.activedirectorypro.com，我知道这是服务器而不是打印机。如果我没有一个PTR记录设置，我会一直在调查清单，试图找到更多关于这个IP的信息。

没有理由不设置PTR记录，它很容易设置，并且不会在服务器上造成额外的资源。请参阅关于设置反向查找区域和ptr记录的完整指南。

其他资源：

NSLookup以检查DNS记录

根提示（Root Hints）与DNS转发器（哪一个是最好的）

默认情况下，Windows DNS服务器配置为使用根提示服务器进行外部查找。外部查找的另一个选项是使用转发器。

基本上，这两个选项都是解析内部服务器无法解析的主机名的方法。

哪一个是最好的？

通过我自己的经验和研究，这真的可以归结为个人喜好。

以下是一些一般准则，它们将帮助您决定：

• 如果主要关注可靠性，请使用根提示（windows默认设置）
• 转发器可能提供更快的DNS查找。您可以使用基准测试工具来测试查找响应时间，该链接包含在资源部分中。
• 转发商还可以提供安全增强功能（更多信息见下文）
• 必须在每个DC上手动配置转发器

多年来，我使用默认设置（根提示），然后在一次安全会议上介绍了Quad9。Quad9是一个免费、递归、选播的DNS平台，为最终用户提供强大的安全保护、高性能和隐私。简言之，如果客户端向列表中的某个域发出请求，则Quad9将根据坏域列表检查DNS查找。

我使用这项服务已经一年多了，没有任何问题。由于安全性一直是我的一个大问题，所以我个人倾向于从根提示切换到Quad9转发器。它提供快速可靠的查找，并增加了安全性。

Quad9不提供任何报告或分析。被阻止的请求将记录在Windows服务器DNS调试日志中，因此请确保阅读有关如何启用它的下一节。drops将与NXDomain一起记录，因此您可以通过在日志中查找来构建报告。

其他资源：

OpenDNS 是另一家提供这项服务的公司，它的成本很高，但包括其他功能和报告。

How Quad9 Works 的工作原理–此页显示如何在单独的计算机上设置Quad9，如果您有自己的DNS服务器，则不执行此操作。您将要使用您的DNS服务器并添加quad9作为转发器。本页提供了一些额外的详细信息，这也是我将其包括在内的主要原因。您可以将这些步骤用于家庭计算机或只需要访问internet的设备。

DNS Benchmark tool -免费工具，允许您测试任何名称服务器的响应时间。这可能有助于您确定是否要坚持根提示或使用转发器。

List of Root Servers 

启用DNS调试日志记录

DNS调试日志可用于跟踪DNS查询、更新和其他DNS错误的问题。它还可用于跟踪客户活动。

使用splunk之类的日志工具，您可以在顶级域、顶级客户端上创建报告，并查找潜在的恶意网络流量。

Microsoft有一个日志分析器工具，可以生成以下输出：

您应该能够将调试日志拉入任何日志工具或脚本中，以创建自己的报告。

如何启用DNS调试日志

步骤1:在DNS控制台上右键单击DNS服务器并选择“属性”

步骤2：单击调试日志记录选项卡

如果需要，请更改默认路径和最大大小。

其他资源：

分析DNS服务器日志以跟踪活动客户端

对别名使用CNAME记录（而不是记录）

记录将名称映射到IP地址。

CNAME记录将一个名称映射到另一个名称。

如果你使用一个记录来创建别名，你将得到多个记录，随着时间的推移，这将成为一个大混乱。如果您配置了PTR记录，这也将在该区域中创建其他记录，这将增加混乱并产生更大的问题。

如果需要创建别名，最好使用CNAME记录，这将更容易管理并防止创建多个DNS记录。

如何创建别名CNAME记录

我有一个名为file1的文件服务器的记录设置，它解析为IP 192.168.0.201

我们的开发团队希望将服务器重命名为Paris，以使其更易于用户使用。我将创建一个CNAME记录，而不是重新命名服务器。

右键单击区域并单击新别名（CNAME）

化名，我要去巴黎

别名解析为文件1，因此我将其添加到目标主机框中：

单击“确定”即可完成！

现在我可以通过解析为file1的主机名访问巴黎

很容易吧？

这将保持DNS干净，并有助于防止DNS查找问题。

使用DNS最佳实践分析器

Microsoft最佳实践分析器是一个扫描服务器角色的工具，可根据Microsoft指南检查配置。这是一种快速解决和发现潜在问题的方法配置问题。

可以使用GUI或PowerShell来运行BPA，下面给出了这两种方法的说明。

如何使用GUI运行BPA DNS

打开服务器管理器，然后单击DNS

现在向下滚动到“最佳实践分析器”部分，单击“任务”，然后选择“启动BPA扫描”

扫描完成后，将显示结果。

如何使用PowerShell运行BPA DNS

您首先需要角色的ID。运行此命令以获取ID

Get-BPaModel

我可以DNS的ID是Microsoft/Windows/DNSServer。我获取这个ID并使用这个命令为DNS运行BPA。

调用BPAModel“Microsoft/Windows/DNSSerer”

你可能会出错，这很正常

上面的命令只运行分析器它不会自动显示结果。

要显示结果，请运行以下命令：

获取BpaResult Microsoft/Windows/DNSServer

附加：DNS安全提示

我想我们都同意DNS是一项重要的服务。没有了它，任何东西将如何运作？现在让我们来看看保护这项服务的几种方法，其中一些功能在Windows服务器上是默认启用的。

• 筛选DNS请求（阻止坏域）
• 安全DNS转发器
• DNS缓存锁定
• DNS套接字池
• DNSSecFilter DNS请求（阻止坏域）

筛选DNS请求（阻止坏域）

防止病毒、间谍软件和其他恶意流量的最佳方法之一是在流量到达您的网络之前阻止它。

这可以通过一个安全设备来过滤DNS流量来实现，该设备根据坏域列表检查域名。如果域在列表中，则将丢弃通信量，以防止坏域和客户端之间的任何进一步通信。这是下一代防火墙、IPS系统（入侵防御系统）和其他安全设备上的常见功能。

我一直在使用思科的防火墙来提供这项服务。Cisco提供了一个feed（坏域列表），它会定期自动更新。此外，我可以添加额外的feed或手动将坏域添加到列表中。自从我过滤DNS请求以来，病毒和勒索软件类型的威胁已经大大减少。我一直很惊讶，有多少坏流量检测和阻塞，令人惊讶的是非常少的误报！

其他资源：

Cisco Next Generation Firewall official site
https://www.cisco.com/c/en/us/products/security/firewalls/index.html

Paloalto – Another popular firewall/IPS system
https://www.paloaltonetworks.com/products/secure-the-network/next-generation-firewall

 

安全DNS转发器

安全DNS转发器是过滤和阻止DNS查询的另一种方法。

除了阻止恶意域外，一些转发服务还提供web内容筛选。这允许您根据成人内容、游戏、毒品等类别阻止请求。与防火墙这样的内部设备相比，它的一大优势是可以在设备脱离网络时为它们提供保护。它可能需要在设备上安装客户端，但如果设备位于内部或外部网络上，它将通过安全DNS转发器引导所有DNS流量。

DNS转发筛选器列表：

• Quad9
• OpenDNS
• DNSFilter

DNS缓存锁定

DNS缓存锁定允许您控制何时可以覆盖DNS缓存。

当DNS服务器对客户端执行查找时，它会将该查找存储在缓存中一段时间。这允许DNS服务器在以后更快地响应相同的查找。如果我去了espn.com，DNS服务器将缓存该查找，因此如果有人在以后访问它，它将已经被缓存，允许更快的查找。

一种类型的攻击是用错误的记录填充缓存查找。例如，我们在缓存中有espn.com，攻击者可以更改此记录以重定向到恶意站点。下一次有人访问espn.com时，它会将他们发送到恶意站点。

DNS缓存锁定阻止缓存中的记录被更改。默认情况下，Windows Server 2016已启用此功能。

额外资源

https://nedimehic.org/2017/04/25/how-to-deploy-and-configure-dns-2016-p…

DNS套接字池

DNS套接字池允许DNS服务器使用源端口随机化进行DNS查找。通过使用随机端口，DNS服务器将从可用套接字池中随机选择一个源端口。与反复使用同一端口不同，它将从池中随机选择一个端口，这使得攻击者很难猜测DNS查询的源端口。

默认情况下，Windows server 2016也会启用此功能

额外资源

Microsoft配置套接字池

DNSSEC

DNSSEC添加了一个安全层，允许客户端验证DNS响应。此验证过程有助于防止DNS欺骗和缓存poising。

DNSSec使用数字签名来验证响应的真实性。当客户端执行DNS查询时，DNS服务器将向响应附加数字签名，这允许客户端验证响应并证明其未被篡改。

其他资源：

• Overview of DNSSec
• Step by Step implementation

你也可能喜欢…

• Top 16 DHCP Best Practices

推荐工具：SolarWinds服务器和应用程序监视器（SAM）

此实用程序旨在监视活动目录和其他关键应用程序。它将快速发现域控制器问题，防止复制失败，跟踪失败的登录尝试等等。

我最喜欢SAM的地方是它易于使用仪表板和警报功能。它还可以监视虚拟机和存储。

 

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

本指南提供了有关如何为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

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