我想调整将承载基于TCP的网络服务的服务器的TCP实现.发送的每请求大小将是“小”(例如< 256字节).好吧,你明白了,这是一个游戏服务器(震惊！). 仅供参考,因为游戏不像quake一样,我对这个特定服务的UDP(或者在ENet和RakNet上看到的UDP上的可靠层)不感兴趣;必须可靠地接收所有数据包,这就是TCP的设计目标.因此,iPhone客户端和服务之间的连接将是“长期存在的”(尽可能地 – 隧道和电梯被诅咒！). 仅供参考,我在运行Linux 2.6.18-164.9.1.el5的服务器上以100Mbps的上行链路运行该服务.
我的目标是同时：
>尽可能降低延迟;和
>最小化每个连接客户端使用的内存量.
有大量与TCP相关的旋钮可以调整！经过一些基础研究后,似乎大多数人都建议按原样保留设置.但是,有一些设置似乎应该针对特定情况进行调整.我知道这有点模糊,这就是我寻求帮助的原因.
要考虑调整片状网络上的小请求/响应,同时尽可能减少内存,可能是：
> TCP / IP实现可用的内存
>设置“nodelay”选项(禁用Nagle算法,因为这是一个半实时游戏服务器)
>拥塞控制算法
>等等(还有什么？)
考虑TCP congestion control algorithms：
> reno：几乎所有其他操作系统都使用的传统TCP
>立方体：CUBIC-TCP
> bic：BIC-TCP
> htcp：汉密尔顿TCP
>拉斯维加斯：TCP Vegas
> westwood：针对有损网络进行了优化
我的服务器默认为bic,其“目标是设计一种协议,可以在高速长途网络上将其性能扩展到每秒几十吉比特,同时保持强大的公平性,稳定性和TCP友好性.”
仅从微小的描述来看,Westwood听起来更合适,因为它“旨在更好地处理大带宽延迟产品路径(大型管道),由于传输或其他错误(漏管道)而潜在的数据包丢失,以及动态负载(动态)管道)”.
我在这里过得太深还是这个课程的标准？
您通常会调整哪些类型的TCP / IP？怎么样？有什么经验法则可以知道？
你对我的具体案例有什么智慧之言？
非常感谢！
解决方法
对于这种特殊情况,由于请求较小,您将希望尝试尽可能地保持连接打开,因为每个请求一个连接将分别获取五个数据包,而您可以将平均值降低到如果你保持联系,那么两个以上的数据包.
NODELAY是游戏服务器的正确选择;你想要立即传送256个字节,而这不是一个整段,所以除非你使用NODELAY,否则Nagle会暂停.
如果您的服务器有大量内存,那么内存选项没什么大不了的,新内核就是正确的.
至于拥塞控制算法,你发现了Westwood.另一种选择是CUBIC.你可以选择一个,或者你可以做一些研究并对它们进行基准测试.这可能是相当多的工作,但对于1000万客户来说,这是值得的.因此,我会考虑在Mac或三台上使用流量生成器运行模拟(因为它们具有与手机相同的TCP实现),在充当路由器之间的Linux机箱(稍后会详细介绍)和你的一台服务器,看它是怎么回事.
现在,中间的Linux盒子应该运行ns-3,这样你就可以模拟一个比以太网交换机更复杂的路径.然后,您可以在TCP连接的发送端捕获一些数据包跟踪,并使用tcptrace或wireshark的tcptrace图形模式对其进行分析. tcptrace文档是分析TCP拥塞行为的一个很好的介绍.
