我们在各个站点都有 Exchange 服务器，但也在船上。船舶在海上时通过卫星链路连接到我们的网络，但在港口时切换到 WiFi 网桥。
由于高延迟（500+ 毫秒）和不常见的丢失（例如，当船舶转弯时），尝试在海上发送任何超过几兆字节的电子邮件很可能会失败并重试直到限制已经达到。结果：电子邮件无法送达，每次尝试都会消耗卫星链接上的宝贵带宽。
一种“解决方案”是将最大电子邮件大小限制为 5 MB，但这对用户来说几乎不友好，而且在端口中是不必要的限制。
我宁愿做的是将所有大于设定限制的电子邮件排队，以便在海上时稍后发送，同时立即发送所有小电子邮件。当时我想我会定期 ping 我们数据中心中的集线器传输服务器，当延迟下降到大约 400 毫秒以下时，我会开始处理大型电子邮件队列。当延迟超过 400 毫秒时，我会堵住漏洞并让电子邮件再次排队。
现在，我从 2003 版开始就没有真正接触过 Exchange。那时，您可以安排大型电子邮件以供以后发送，所以我的想法是在 Exchange 2010 中做一些类似的事情，然后编写一种方法来切换发送在“总是”和“从不”之间安排大型电子邮件。
创建这样的脚本应该不会太复杂，但后来我读到我依赖的功能在 Exchange 2007 中被删除了：
这是 Exchange 2003 中存在的一项功能，但已在 Exchange 2007 中删除。它是在 SMTP 连接器上设置的，具有“对超大邮件使用不同的传递时间”。
TechCenter：是否可以根据 Exchange 中的大小安排电子邮件发送？
这是真的吗？- 此功能是否不再存在于 Exchange 2010 中，或者它只是转换为类似的功能，我可以使用它来实现我的目标？如果是这样，是什么？
是否有另一种方法可以延迟在某些 Exchange 服务器上发送大型电子邮件？它可能基于时间表，甚至可能需要特定操作 - 我相当肯定会有某种方式通过脚本触发交付，我只需要在船上单独的队列中发送大量电子邮件。
您对此的想法将不胜感激！:-)
我偶然发现了两个 PowerShell CmdLets 我认为可以让我非常接近我的目标：
我玩了一会儿 Get-Message，看看上面的命令会处理什么样的消息。
最重要的是，这些命令接受消息大小过滤器。此命令将列出当前服务器上大于 5 MB（5,242,880 字节）的排队消息：
get-message -Filter {Size -gt 5242880}
它似乎Get-Message只从各种远程传递队列返回消息。但是在服务器内流动的消息，无论多么短暂，是否会出现在 Get/Suspend/Resume-Message 会弄乱的队列中？
如果没有，解决方案可以像每隔几分钟的预定脚本一样简单，沿着（伪代码）行： …
我目前正在设置 RHN Satellite，一切正常。我正在创建自定义频道，因为我们有某些软件应该可用于所有卫星节点，例如 puppet、facter、subversion、php（比 base 中的版本新）。
我试图找到有关这方面最佳实践的文档。它们应该如何设置，如何处理不同的 arch，如何处理 noarch 包。在自定义通道中更新自定义包时如何同步更新依赖项（例如更新 php，如何获取所有更新的依赖项）。
来自 RHEL 的频道管理文档 ( http://www.redhat.com/docs/en-US/Red_Hat_Network_Satellite/5.3/Channel_Management_Guide/html/Channel_Management_Guide-Custom_Channel_and_Package_Management.html ) 没有为我提供有关如何解决任何问题的足够信息这些问题。
所有与此相关的提示、技巧和信息都会很棒！
卫星连接通常具有大约 500 毫秒的 RTT。尽管有大量带宽，但连接通常会遭受次优传输速度的影响，因为 TCP 确认需要很长时间才能到达。
我的理解是，解决 TCP 连接问题的一个好方法是将 TCP 窗口大小设置为连接速度（以位为单位）乘以 RTT（以秒为单位）。因此，通过卫星的 1mbps 连接应该具有 512kb 的窗口大小。
这其中有哪些陷阱？是否还有其他类似的调整可以优化卫星连接？我知道许多现代操作系统会自动修改窗口大小，但它们是否足够激进，使窗口大小足够大以用于卫星通信？
顺便说一句，我将假设在经常丢弃数据包的网络上不希望使用大窗口大小，因为重传将以窗口大小进行，并且您可能会将大部分带宽用于重传开销。
谢谢，我仍在学习很多关于网络的知识，感谢您的投入。
这似乎是一个非常简单的问题。但我在网上看不到任何关于它的信息。该命令来自RHEL 文档本身，所以我希望它可以工作......但它失败了。任何见解？
命令：
/sbin/iptables -A INPUT -m state --state NEW -m tcp -p udp --dport 25150 -j ACCEPT
输出：
iptables: Invalid argument. Run `dmesg' for more information.
dmesg 日志：
[ 1719.334534] x_tables: ip_tables: tcp match: only valid for protocol 6
我哥哥在无国界医生组织的领域工作。我代表他发布这个问题。
我们使用 Outlook Express（在运行 Windows XP 的电脑上）和 9600 波特拨号卫星电话调制解调器直接从巴黎的服务器获取我们的电子邮件。由于这是一种非常昂贵的通信方式（我们的卫星费用每年超过 5 万美元，不是开玩笑），似乎尝试简化是一个好主意。
这是问题 - 当我们连接时，顺序是：
发送发件箱邮件。这进行得非常快，每封电子邮件可能需要 10-15 秒，而一封 150k 左右的电子邮件可能需要几分钟）。根据发送的电子邮件，状态栏移动得非常快。
然后系统会说“正在检查（我们的帐户名）上的新消息，以及“正在接收来自服务器的消息列表”。这需要很长时间。大约 10-15 分钟。状态栏一直在爬行。
然后它接收消息。“从服务器接收消息”。同样，每条消息需要 10-15 秒，这部分移动得相当快。
我很好奇第二部分发生了什么。它需要永远，并且似乎不是发送或接收消息本身的一部分。有没有办法通过更改与服务器通信或其他方式的偏好来加快进程？
有没有人对他加快 Outlooks Express 正在做的事情有什么建议？显然他的软件是古老的，根据连接速度添加更多软件是不现实的。
谢谢！
我一直在尝试解决 TCP 重传率非常高的网络问题。36 个样本（使用在 32 位 Windows 7 上运行的 Wireshark 1.10.8 获取）总计略多于 7 个小时，每个样本持续 2 到 53 分钟，显示重传占用总入口带宽的 43% 到 61%。
让我感到困惑的是，据我所知，此类问题只有两个原因：丢包的不稳定链路和拥塞。我相信我已经排除了这些可能性。让我列出我们的情况，我很乐意听取比我更有知识的人关于解决问题的其他调查方向的意见。
该网络位于海上的一艘船上。它使用卫星链路与互联网进行通信。不幸的是，这种类型的链路的带宽成本非常高，因此我们只能使用 1Mbps 下行/512kbps 上行连接。作为卫星链路，它的 ping 时间约为 650 毫秒。目前，我们船上大约有 300 人，全部共用该管道。
该网络由两个 VLAN 组成（一个用于船上计算机，另一个用于访客）。两个 VLAN 均通过管道传输至 SonicWall TZ 215（运行 SonicOS 增强版 5.8.1.2-6o），该 SonicWall TZ 215 控制通往 Internet 的管道。两个 VLAN 都有有线和无线客户端。有线网络由一系列 Cisco 2900 千兆交换机运行。无线网络由众多思科 AP 提供（海上钢船上的信号传播非常糟糕）。
我的第一个想法是这是一个拥塞问题，因此我寻求了各种解决方案（阻止视频聊天和流媒体等高带宽服务，窃听公司办公室支付更大的管道费用等）。遗憾的是，我们没有得到更大的管道。其他事情有一点帮助，但不足以产生真正的影响。
但这个周末我又回到了原点。队长要求我在演习期间禁止访客访问互联网。我利用这个机会在网络不拥塞时使用 Wireshark 捕获了网络。令我惊讶的是，10 分钟的样本显示 TCP 重传率与所有其他捕获几乎相同 - 58%。在该样本的持续时间内，平均带宽使用率为 98kbps，因此绝对不拥堵。
这使得数据包丢失成为可能的原因。为了测试这一点，我运行了 12 个小时的 ping。最后，该程序报告丢包率低于 1%。
哪个留下...什么？我不知道。任何额外的想法将不胜感激。
我们正在运行带有冻结 RHEL 6.3 频道的 RHN Satellite 和 RHEL 6.3 服务器。
保持旧 RHEL 6.3 服务器安全的最佳实践是什么？
重要的是：
所以...