编译Nginx支持Tcp
我的图书馆
编译Nginx支持Tcp
Tcp wrappers ： Transmission Control Protocol (TCP) Wrappers 为由 inetd 生成的服务提供了增强的安全性。Tcp wrappers是一种对使用 /etc/inetd.sec 的替换方法。TCP Wrappers 提供防止主机名和主机地址欺骗的保护。欺骗是一种伪装成有效用户或主机以获得对系统进行未经授权的访问的方法。
1、重新编译Nginx
[root@ipython nginx-1.6.1]# tar zxf ../ngx_tcpwrappers.tar.gz -C ./[root@ipython nginx-1.6.1]# ./configure --prefix=/software/nginx --user=nginx --group=nginx --with-http_stub_status_module --with-http_ssl_module --with-http_realip_module --with-http_gzip_static_module --with-google_perftools_module --with-debug --http-client-body-temp-path=/var/tmp/nginx/client --http-proxy-temp-path=/var/tmp/nginx/proxy --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi --http-scgi-temp-path=/var/tmp/nginx/scgi --with-pcre=/root/pcre-8.35 --with-openssl=/root/openssl-1.0.1i --with-zlib=/root/zlib-1.2.8 --add-module=./ngx_tcpwrappers&[root@ipython nginx-1.6.1]# sed -i s'#CFLAGS =
-O -W -Wall -Wpointer-arith -Wno-unused-parameter -Werror#CFLAGS =
-O -W -Wall -Wpointer-arith -Wno-unused-parameter -g#' objs/Makefile ####不要make install 哦，编译好即可####[root@ipython nginx-1.6.1]# make
2、完成升级，以及模块的使用，Nginx还是很奇特的哦~~
####备份可执行文件，复制新的文件####[root@ipython nginx-1.6.1]# mv /software/nginx/sbin/nginx /software/nginx/conf/@nginx[root@ipython nginx-1.6.1]# cp objs/nginx /software/nginx/sbin/&####测试新版本的Nginx####[root@ipython nginx-1.6.1]# /software/nginx/sbin/nginx -tnginx: the configuration file /software/nginx/conf/nginx.conf syntax is oknginx: configuration file /software/nginx/conf/nginx.conf test is successful&###此时没有加入Tcp_wrappers的配置 测试下访问###[root@ipython openssl-1.0.1i]# curl -I http://www.ipython.meHTTP/1.1 200 OKServer: nginx/1.6.1Date: Mon, 11 Aug :08 GMTContent-Type: text/htmlContent-Length: 612Last-Modified: Mon, 11 Aug :25 GMTConnection: keep-aliveETag: "53e"Accept-Ranges: bytes&###平滑升级###[root@ipython nginx-1.6.1]# make upgrade&##测试模块，拒绝1.1.1.30的Nginx请求## ##在http块里加入如下配置##
tcpwrappers_
tcpwrappers_&##hosts.deny如下##[root@ipython nginx-1.6.1]# awk '!/^#/' /etc/hosts.deny nginx:1.1.1.30&##重新读取Nginx配置文件##[root@ipython nginx-1.6.1]# /software/nginx/sbin/nginx -s reload&###此时访问 就是403了###[root@itchenyi ~]# curl -I http://www.ipython.meHTTP/1.1 403 ForbiddenServer: nginx/1.6.1Date: Mon, 11 Aug :47 GMTContent-Type: text/htmlContent-Length: 168Connection: keep-alive
3、Tcp_warppers 模块指令
###ngx_Tcp_wrappers 配置指令###1、tcpwrappers 语法 ： tcpwrappers [on|off] 默认值 ： tcpwrappers off 作用域 ： http, server, location, limit_except 描述 ： 模块的开关，开启则使用TCP Wrappers 进行访问控制，关闭以避免浪费性能&2、tcpwrappers_daemon 语法 ： tcpwrappers_daemon name 默认值 ： tcpwrappers_daemon nginx 作用域 ： http, server, location, limit_except 描述 ： 该名字的定义用于在/etc/hosts.[allow|deny]识别&3、tcpwrappers_thorough 语法 ： tcpwrappers_thorough [on|off] 默认值 ： tcpwrappers_thorough off 作用域 ： http, server, location, limit_except 描述 ： 基于hosts.ctl以检查使用IP地址、用户名、反向DNS解析，模块的开发者也未提供详细的使用说明
来源： IT辰逸
原文： &&&& 作者： IT辰逸
转载本文请遵循原文要求
发表评论：
TA的最新馆藏[转]&中国领先的IT技术网站
51CTO旗下网站
游戏服务器：到底使用UDP还是TCP
一般来说你会听到人们这样说：“除非你正在写一个动作类游戏，否则你就用TCP吧” 或者是 “你能够在MMO游戏中用TCP,因为魔兽世界就用的TCP！”
作者：菜鸟浮出水 编译来源：伯乐在线| 09:51
在编写网络游戏的时候，到底使用UDP还是TCP的问题迟早都要面对。
一般来说你会听到人们这样说：&除非你正在写一个动作类游戏，否则你就用TCP吧& 或者是 &你能够在MMO游戏中用TCP,因为魔兽世界就用的TCP！&
遗憾的是，这些观点都没有反映这个问题的复杂性。
首先，说明一下，我之前主要是用TCP进行网络编程。我曾为一个流行的在线纸牌游戏编写服务器了好几年，在高峰期我们的每台服务器能够承受个连接（同一台物理机器上有多个服务器进程在跑）都没有问题。在我来看，TCP是一种安全而且常见的选择。
尽管如此，我们最新的项目却是使用UDP协议，而且我们的项目无法通过任何方式在TCP下工作。事实上，项目一开始使用的TCP，但是后来发现我们使用TCP无法达到我们需求的连接数量时，我们只能换成UDP了。
在使用中TCP表现怎么样呢
从原理上，TCP的优势有：
简单直接的长连接
可靠的信息传输
数据包的大小没有限制
任何一个和TCP打过交道的人都知道，要实现一个稳定的TCP网络连接，需要处理各种隐藏的坑，比如断线检测、慢速客户端响应阻塞数据包，对开放连接的各种dos攻击，阻塞和非阻塞IO模型等等。
除了上面列出的这些问题外，一个好的TCP模块确实不好编码实现。
但是，TCP最糟糕的特性是它对阻塞的控制。一般来说，TCP假定丢包是由于网络带宽不够造成的，所以发生这种情况的时候，TCP就会减少发包速度。
在3G或WiFi下，一个数据包丢失了，你希望的是立马重发这个数据包，然而TCP的阻塞机制却完全是采用相反的方式来处理！
而且没有任何办法能够绕过这个机制，因为这是TCP协议构建的基础。这就是为什么在3G或者WiFi环境下，ping值能够上升到1000多毫秒的原因。
为什么不用UDP
UDP相对TCP来说既简单又困难。
举个例子来说，UDP是基于数据包构建，这意味着在某些方面需要你完全颠覆在TCP下的观念。UDP只使用一个socket进行通信，不像TCP需要为每一个客户端建立一个socket连接。这些都是UDP非常不错的地方。
但是，大多数情况下你需要的仅仅是一些连接的概念罢了，一些基本的包序功能，以及所谓的连接可靠性。可惜的是，这些功能UDP都没有办法简单的提供给你，而你使用TCP却都可以免费得到。
这也是人们为什么经常推荐TCP的原因。在用TCP的时候你可以不考虑这些问题，直到你需要同步连接的数量级达到500以上的时候。
所以，是的，UDP没有提供所有的解决方法，但是就像你看到的那样，这也正是UDP好用的地方。在某种意义上来说，TCP对UDP就好比是Hibernate和手写SQL的区别。
使用TCP失败的地方
人们经常给你建议，让你去使用TCP，比如&TCP跟UDP一样快&或者&游戏X用TCP如此成功，所以TCP当然是首选&，然而，他们完全没有理解为什么在那个特定的游戏中TCP是有效的，为什么UDP不按照顺序发送数据包呢？
那么为什么魔兽世界采用TCP呢？首先我们需要解释这个问题。这个问题其实是&为什么魔兽世界有的时候1000毫秒以上的延迟还能够运行？&这是TCP的性质决定的，在发生丢包的时候，会产生巨大的延迟，因为TCP首先会去检测哪些包发生了丢失，然后重发所有丢失的包，直到他们都被接收到。
可靠的UDP也是有延迟的，但是由于它是在UDP的基础之上建立的通信协议，所以可以通过多种方式来减少延迟，不像TCP，所有的东西都要依赖于TCP协议本身而无法被更改。
就这一点来讲，一些人要开始提到Nagle算法了，实际上它是你在实现任意一个对延迟敏感的TCP模型时首先需要禁止使用的。
那么魔兽世界以及其他的一些游戏是怎么处理延迟问题的呢？
方法也很简单，他们能够隐藏掉延迟带来的影响。
在魔兽世界中，玩家和玩家是无法碰撞的：因为这类碰撞是无法通过一些预测来处理的，但是玩家和环境之间的碰撞却是可以通过预测来处理的，所以这里使用TCP是没有问题的。
我们来看一下魔兽世界的战斗就会发现，玩家的攻击指令发送给服务器的操作是放在比如&attack_entity(entity_id)&或者&cast_spell(entity_id, spell_id)&的接口中来做的，换句话说，瞄准操作是独立于进行的。如此一来，一些类似发起攻击动作和释放技能特效就能够在没有收到服务器确认的情况下就直接执行，比如展现冰冻技能的效果就可以在服务器没有返回数据前在客户端就做出来。
客户端直接开始进行计算而不等待服务端确认是一种典型的隐藏延迟的技术。
几年前，我为一个叫&Five Card Jazz&的纸牌游戏编写过客户端。它使用的是http协议，它比直接的TCP协议连接的延迟更加严重。
我们用简单的纸牌绘制和抽牌的动画来掩盖延迟的问题，所以延迟的问题只在非常糟糕的连接下才会被看出来。这种方法也非常的典型：发送请求的同时开始播放牌桌的动画，一直播放翻动最后一张牌直到接收到了服务端传回来的数据为止。魔兽世界的战斗特效就是使用类似的原理。
这也意味着，我们到底是使用TCP还是UDP取决于我们能否隐藏延迟。
TCP在什么时候失效
一个采用TCP的游戏必须能够处理好突发的延迟问题（纸牌客户端就很典型，对突发性的一秒的延迟，玩家也不会产生什么抱怨）或者是拥有缓解延迟问题的好方法。
但是如果你运行的是一个无法使用任何减缓延迟措施的游戏呢？玩家对玩家的动作类游戏通常就属于这个范畴，但是这也不仅仅限于动作类游戏。
举个例子：
我目前正在写一个多人游戏（War Arcana）。
一种常见的操作是，你快速的移动你的角色通过一张充满战争迷雾的世界地图，但是一旦你探索过，迷雾就会被打开。
为了确保游戏的规则，防止玩家作弊，服务器只能显示玩家当前位置附近的信息。这意味着不像魔兽世界，玩家无法在没有得到服务器响应的情况下，做出完整的动作。和Five Card Jazz相比，我们即使允许500毫秒的延迟，也已经非常困难了。
在实现了游戏的原型后，在局域网内一切都进行的非常顺利，但当我们在WiFi环境下测试时，操作会间歇性的卡起来或者延迟高起来。写了一些测试程序之后发现，WiFi环境下偶尔会发生丢包行为，每当发生丢包的时候，服务器的响应速度就从100-150毫秒上升到毫秒。
没有任何办法可以绕过TCP的这个设置来避开这个问题。
我们替换了TCP的代码，用了自定义的可靠的UDP来实现，把大量的丢包产生的延迟降到了仅仅只有50毫秒，甚至比以前TCP不丢包的情况一个来回的延迟还要小。当然，这只可能建立在UDP之上，这样我们才对可靠性拥有完全的掌控力。
困惑：可靠的UDP只是TCP的一种简单的实现？
你有没有听过这种说法：&可靠的UDP就像TCP一样，所以还是用TCP吧&。
问题是这种说法是错误的。可靠的UDP一点也不像TCP，要去实现一个特殊的阻塞控制。事实上，这也是你使用可靠UDP代替TCP的最大的原因，避免TCP的阻塞控制。
另一个重点是可靠的UDP的可靠性是如何保证的。这里有很多种方法去实现。我非常喜欢Quake3网络库代码里的一些想法，它们也激发了我在War Arcana中使用UDP协议。
你也可以使用许多支持可靠通信的UDP库，当然，这样在可靠性方面，相比自己手动实现全部的代码而言，可能会更加通用而失去了一些性能优势。
那么到底是用UDP还是TCP呢？
如果是由客户端间歇性的发起无状态的查询，并且偶尔发生延迟是可以容忍，那么使用HTTP/HTTPS吧。
如果客户端和服务器都可以独立发包，但是偶尔发生延迟可以容忍（比如：在线的纸牌游戏，许多MMO类的游戏），那么使用TCP长连接吧。
如果客户端和服务器都可以独立发包，而且无法忍受延迟（比如：大多数的多人动作类游戏，一些MMO类游戏），那么使用UDP吧。
这些也应该考虑在内：你的MMO客户端也许首先使用HTTP去获取上一次的更新内容，然后使用UDP跟游戏服务器进行连接。
永远不要害怕去使用最佳的工具来解决问题。
原文链接：&&&&翻译：&-&
译文链接：&
【编辑推荐】
【责任编辑： TEL：（010）】
大家都在看猜你喜欢
原创原创外电头条外电
24H热文一周话题本月最赞
讲师：1人学习过
讲师：33人学习过
讲师：0人学习过
精选博文论坛热帖下载排行
主要内容：
● 如何设计像自动售货机那样有效的用户界面。
● 深入理解窗口和对话框的管理机制。
● 为什么性能优化与我们在直觉上的理...
订阅51CTO邮刊2925人阅读
C/C++（8）
Web Server（25）
&&&&&&&&我们很自豪地宣布，开源NGINX和我们的应用交付平台--NGINIX Plus增加了一个激动人心的新能力 - UDP负载均衡。这一新功能建立在我们现有的TCP和HTTP功能上，使得NGINX成为一个功能强大，易于使用，一致性的前端，为更广泛的互联网应用程序和设备提供服务。我们很高兴能扩展负载平衡功能，让世界上最繁忙的应用程序的一大半的功耗到一组新的物联网（IOT）用户中。
为什么要添加支持UDP负载均衡呢？
&&&&&&&&大多数互联网应用依赖于HTTP进行网络通信。 像SOAP和REST高级协议是建立在HTTP的基础上，可以充分利用一些丰富的扩展功能的优势- 安全性上使用TLS，压缩数据上使用Gzip，性能增强上使用HTTP /2。
&&&&&&&&然而，为不同的目的，许多应用程序需要使用多个协议，许多核心的互联网协议早于HTTP。由于这个原因，用于负载平衡的一个完整的解决方案和反向代理的需求来支持大范围的协议，这两者都是基于TCP和UDP的。
&&&&&&&&UDP通常用于轻量级协议，本质上未涉及事务性，如DNS（用于解析域名地址），系统日志（用于轻质记录）和RADIUS（用于认证）。这些协议没有严格的可靠性要求-- 如果一个UDP消息（数据包）被丢弃，客户端可以安全地重新发送超时消息-- 但他们提供的服务是互联网服务的正确运行的关键所在。 UDP也正在成为新的物联网应用首选方案之一，其原因在于较低的带宽要求。
&&&&&&&&一年前，NGINX为我们的技术社区用户和商业客户介绍TCP负载平衡。通过添加UDP负载均衡来扩展我们的负载均衡功能，对于这点，我们现在乐意这么做。使用NGINX或者NGINX Plus，用户现在可以提供基于可靠的，可扩展的以及高性能的UDP服务。
UDP负载均衡如何运作的呢？
2UDP负载均衡如何运作的呢
&&&&&&&&NGINX监听基于管理员定义一个或多个地址（IP地址和端口）的UDP网络通信（协议如DNS，系统日志，和RADIUS）。这些地址被公布以便于让客户知道往哪里发送所需的服务请求。相对于HTTP和TCP负载均衡，UDP负载均衡的配置定义了一个上游分组-- 一组原始的服务器，这些服务器提供基于UDP的服务-- 当负载平衡的流量跨越服务器时，使用具体的算法（例如，循环赛使用，最少连接，或哈希基于源IP地址）。该配置还定义了基于每个UDP端口的虚拟服务器，具有proxy_pass指令命名那些提供了相关联的服务的上游分组:
# Load balanceUDP-based DNS traffic across two servers
upstreamdns_upstreams {
server192.168.136.130:53;
server192.168.136.131:53;
proxy_pass dns_
proxy_timeout 1s;
proxy_responses 1;
error_log logs/dns.
&&&&&&&&当NGINX接收基于一个端口的UDP数据报文（在这里，端口53上的DNS查询），它使用配置的负载均衡算法（在这里，默认轮循RoundRobin）选择哪个上游分组的服务器，将对其进行处理。在适当的地方，NGINX等待来自服务器的响应并转发该响应（以及超时周期内收到的任何后续数据包），回复应客户的请求。如果一个服务器对该请求无法响应，NGINX将其标记为“失败”，并暂时停止发送数据报给它。每隔几秒钟，NGINX检查服务器的健康状况，查看是否它通过发送直播在线信号表名自己已经恢复。
& & & &NGINX Plus R9将包括应用恢复（也称为“异步”或“合成”）健康检查的UDP服务，类似于那些HTTP和TCP流量。您可以配置NGINX Plus去发送特殊UDP请求到上游服务器，并定义服务器必须返回被认定的健康。其它功能，如支持使用UDP负载均衡包括日志事务到一个web服务器式的访问日志，基于IP地址的访问控制列表，和一系列的限速功能。
&&&&&&&&NGINXPlus R9由包括UDP指标的状态模块提供现场活动的监控数据集，你可以快速地配置UDP上游分组，使用基于HTTP的API和DNS，因为你现在可以用HTTP和TCP服务器。
UDP负载均衡使用案例
&&&&&&&&UDP负载均衡解决了两个关键案例：高可用性和横向扩展。通过设计，UDP不保证端至端传送数据的，因此需要在客户端软件来处理网络级错误和重传机制。基于UDP的协议通常定义了一对服务器； 如果客户端无法连接到其首选服务器，它必须在尝试在其他服务器前等待指定的超时时间。这可以引入长期拖延到UDP事务中。
&&&&&&&&在UDP服务器前端部署NGINX或NGINX Plus作为一个高度可用和可靠的负载均衡器可以消除或减少这种延误。客户端发送UDP请求到NGINX或NGINX Plus，它监控UDP服务器的运行状况和可用性，不发送请求到失败或负载过重的服务器。客户不会感知到连接或请求失败，因此不会遭受到与重试请求相关超时的烦恼。
&&&&&&&&使用NGINX或NGINX Plus作为负载平衡器还能够扩展一个UDP应用程序来处理特大流量。在一个典型的UDP部署中，客户知悉至多两个UDP服务器，但可扩展到满足高要求，需要有更多的UDP服务器。在这种情况下，客户端发送的UDP请求到一个或两个已知NGINX或NGINX Plus部署实例上，实际处理上，负载跨越负载过重的UDP服务器到大数量的UDP服务器上以平衡请求。
&&&&UDP负载NGINX和NGINX Plus平衡适用于任何基于UDP的应用程序，这些应用程序发送数据和可选择地期望的一种或多种响应。 NGINX也可以负载均衡专有的基于UDP的协议，如在物联网环境中找到协议。
UDP负载均衡开发时间表
&&&&&&&&UDP的负载均衡的可用性在我们发布的具体时间安排如下：
·&&&&&&&&今天 - 我们向开源软件NGINX库中提交了UDP负载均衡第一版本的代码。早期采用者和那些希望测试我们的实现功能可以克隆一份源码，并构建一个包含UDP负载均衡能力的NGINX二进制执行文件。我们欢迎您给nginx的邮件列中给予反馈。
·&&&&&&&&日 - NGINX版本1.9.13将被释放，包括UDP负载均衡（如将根据该版本的预编译的二进制）。
·&&&&&&&&2016年4月 - NGINX加版本9（R9）将包括UDP负载均衡。 NGINX此外，我们的商业应用交付平台，将扩大在开源与附加功能，为建设并监督基于UDP的服务的可靠性和可扩展性。
&&&&& &NGINX和NGINX Plus提供一个完整的负载均衡和应用交付平台，用于浩如烟海的Internet协议中。无论您是提供基于HTTP的应用，低层TCP的应用程序，或基于UDP的协议，你可以依靠NGINX和NGINX Plus在一个单一的，轻量级的应用上提供高可用性，可靠性，可扩展性和高性能的服务。我们对新的UDP负载均衡功能和它的潜力带来高性能的负载均衡和完美无瑕的应用交付给一个全新的主机设备而非常兴奋。想熟悉NGINX
Plus Release9上UDP负荷均衡吗？今天开始可以免费试用30天或为能够现场演示而联系我们吧。
欢迎加入我的微信公众号&
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：463593次
积分：8100
积分：8100
排名：第1922名
原创：337篇
译文：13篇
评论：80条
(2)(1)(1)(4)(3)(13)(11)(1)(2)(2)(1)(1)(3)(7)(9)(1)(5)(6)(7)(3)(9)(19)(38)(23)(36)(33)(14)(7)(6)(6)(2)(9)(6)(14)(21)(2)(1)(2)(1)(2)(1)(1)(2)(1)(2)(2)(1)(4)(2)(1)(1)(1)}