【发布时间】:2011-01-13 09:59:54
【问题描述】:
我在针对嵌入式设备上的 HTTP 守护程序使用 HttpWebRequest 时遇到问题。问题似乎是在写入套接字流的 http 标头和 http 有效负载(POST)之间有足够的延迟,以至于套接字将套接字缓冲区中的内容释放到服务器。这会导致 HTTP 请求被分成两个数据包(碎片)。
当然,这是完全有效的,但是如果数据包被拆分超过大约 1.8 毫秒,另一端的服务器将无法处理它。所以我想知道是否有任何现实的方法来控制这个(在客户端)。
在 HttpWebRequest 上似乎没有任何属性可以对用于发送的套接字提供这种级别的控制,并且似乎无法访问套接字本身(即通过反射),因为它只是在发送,然后发布(作为出站 http 连接池的一部分)。 BufferWriteStream 属性只是缓冲 webrequest 中的正文内容(因此它仍然可用于重定向等......),并且似乎不会影响整个请求写入套接字的方式。
那该怎么办?
(我真的在努力避免从套接字重新编写 HTTP 客户端)
一种选择可能是编写某种代理,将 HttpWebRequest 发送到(可能通过 ServicePoint),并在该实现中缓冲整个 TCP 请求。但这似乎是一项艰巨的工作。
当我运行 Fidder 时它也可以正常工作(出于同样的原因),但这在我们的生产环境中并不是一个真正的选择......
[ps:我知道分片数据包之间的间隔肯定是问题所在,因为我完成了一个套接字级别的测试,在该测试中我使用 NoDelay 套接字显式控制了分片]
【问题讨论】:
-
你做了完美的工作来理解这个问题。您唯一忘记的是服务器。它的行为是异常的,它必须在超时间隔(大约 20-100 秒)内接收所有数据包。因为它是一个 RFC 标准。是否有可能修复服务器?
-
我已经向设备供应商询问了这一点,但作为嵌入式设备,我怀疑这可能会变得复杂,这就是我试图找到客户端修复程序的原因。
标签: .net sockets httpwebrequest fragmentation