问题标签 [network-protocols]

我正在使用通过 GPRS 进行通信的分布式应用程序。我使用 UDP 数据包发送业务数据并使用 ICMP ping 来验证连接性。现在我在计算提供商将向我收费的流量时遇到问题。我必须考虑以下因素：

1. UDP 有效负载：这很明显。
2. UDP 开销：UDP 头 + IP 头 = 8 + 20 字节。
3. 没有数据的 ICMP 回显请求：IP 标头 + ICMP 有效负载 = 28 字节。
4. ICMP 回显回复：如 3。

上面的意思是，对于每个数据包，我需要为有效载荷 + 28 个字节和每个 ping 56 个字节付费。我是对的还是我错过/误解了什么？

我想要一个程序来确定在捕获的 TCP 会话中使用的TCP 拥塞控制算法。

引用的维基百科文章指出：

TCP New Reno 是最常实现的算法，SACK 支持非常普遍，是 Reno/New Reno 的扩展。其他大多数是仍需要评估的竞争提案。从 2.6.8 开始，Linux 内核将默认实现从 reno 切换到 BIC。在 2.6.19 版本中，默认实现再次更改为 CUBIC。

还：

Compound TCP 是 Microsoft 的 TCP 实现，它同时维护两个不同的拥塞窗口，目标是在 LFN 上实现良好的性能，同时不损害公平性。它已与 Microsoft Windows Vista 和 Windows Server 2008 一起广泛部署，并已移植到较旧的 Microsoft Windows 版本以及 Linux。

确定正在使用哪种 CC 算法（来自捕获会话的第三方）的一些策略是什么？

更新

这个项目已经建立了一个工具来做到这一点：

互联网最近已经从同构拥塞控制发展到异构拥塞控制。几年前，互联网流量主要由标准 TCP AIMD 算法控制，而现在互联网流量由许多不同的 TCP 拥塞控制算法控制，如 AIMD、BIC、CUBIC、CTCP、HSTCP、HTCP、HYBLA、ILLINOIS、LP、 STCP、VEGAS、VENO、WESTWOOD+ 和 YEAH。然而，关于异构拥塞控制的互联网性能和稳定性研究的工作却很少。一个根本原因是缺乏不同 TCP 算法的部署信息。该项目的目标是：

系统可以使用 UDP 并使用前向纠错来传输整个消息，而无需重新传输，即使丢失了一些数据包。这在实践中是否运作良好，或者额外的开销是否过多浪费？

我和我的一个朋友还有另一个争论。

考虑需要设计一个简单的基于 JSON 的协议，该协议基本上用于在各方之间发送某种事件（消息）。

说，像

我建议像上面一样保留这个协议，而我的朋友建议做类似的事情：

他的论点是，就像 TCP 和 HTTP 处于不同的“责任”层一样，该协议应该使用“详细信息”子对象以保持数据分离。

他的另一个论点是处理匹配事件的处理程序不应该知道任何有关“路由”信息（例如 event_id）的信息。

我的论点是：

1. 为了向处理程序隐藏这些信息，我们正在增加每条消息的长度（以及网络流量，这对于与大量消息交换的系统可能很重要）

2. 处理程序确实需要知道“路由”信息，例如，才能正确回答它们：

   /li>

3. 即使我们需要从处理程序中隐藏 event_id 和类似的东西，我们也可以在传递给处理程序之前将它们去掉，这样仍然可以节省流量

该协议非常简单，不应该被其他任何人使用。

你怎么看？

是否有在 actionscript 3 和 C# 中实现的精简（不是 xml 或 json）数据包协议？如果有一个已经有两种语言的实现，那就太好了。如果没有，我可能不得不编码一侧。话虽如此，找出（或查找）C# 的序列化规范的文档然后使用它是愚蠢/不安全的，所以我只需要制作一个 AS3 到 C# 对象编码器吗？

我正在使用一个不太流行的应用程序（即时通讯程序）。我试图找到它使用的协议。我知道它正在使用 TCP/IP，但我想找出它发送到服务器并从服务器接收的所有命令。

我尝试了几个嗅探器，但它们无法通过名称识别此应用程序，而且我得到的只是一些不相关的十六进制代码。

有什么想法可以找到应用程序的规格吗？

（请注意：我用谷歌搜索了它，一无所获，也没有作者的文档。）

SQL Server 客户端协议中的 VIA 协议是什么？

更准确地说，VIA 代表什么？

是芯片制造商威盛的吗？

当 TCP 服务器在端口上接受套接字时，它会获得一个新的套接字来与该客户端一起工作。
接受套接字对该端口仍然有效，并且可以接受该端口上的更多客户端。

为什么最初的 FTP 规范RFC 959决定同时创建控制端口和数据端口？

在类似的自定义协议中是否有任何理由这样做？

在我看来，这可以很容易地在单个端口上指定。

考虑到防火墙和带有 FTP 的 NATS 的所有问题，似乎单个端口会好得多。

对于一般协议实现，我认为您想要这样做的唯一原因是您可以从不同于命令的主机提供文件。

我可以看到有状态的协议可以减少像 cookie 这样的“模拟状态”。

但是测试变得更加难以确保您的实现正确并重新连接，并且会话继续可能很难处理。

始终使用无状态协议是否被认为是更好的做法，还是真的是特定领域的？

我认为在处理有状态协议时身份验证会变得更容易，但是还有其他原因应该使用有状态协议吗？

是否有任何开源的高级工具可以促进和简化使用 GUI 的实验性网络协议 (TCP/UDP) 的开发？

基本上，类似于动态状态机编辑器，它允许您定义“数据包”、“消息”、“状态”、“验证器”、“处理程序”等。

优选地，这样的工具将足够全面以处理协议的所有相关方面（即客户端和服务器），以便可以将高级协议描述序列化为 XML/RDF 文件，在其中它可以用于动态创建实现协议的应用程序代码（即在 Python 中）。