2010-02-05 67 views
7

我在使用HttpWebRequest对嵌入式设备上的HTTP守护进程时遇到问题。问题似乎是,在写入到套接字流的http头文件和http有效内容(POST)之间存在足够的延迟,即套接字将套接字缓冲区中的内容释放到服务器。这导致HTTP请求被分成两个分组(分片)。如何防止HttpWebRequest的数据包碎片

当然,这是完全有效的,但是如果数据包被拆分超过大约1.8ms,那么服务器的另一端就无法处理它。所以我想知道是否有任何现实的方法来控制这个(在客户端)。

在HttpWebRequest上没有任何属性可以控制用于发送的套接字,并且不能访问套接字本身(即通过反射),因为它只是在创建期间创建的发送,然后发布(作为出站http连接池的一部分)。 BufferWriteStream属性只是缓存webrequest中的正文内容(所以它仍然可用于重定向等),并且不会影响整个请求写入套接字的方式。

那该怎么办?

(我真的想避免从插座高达重写HTTP客户端)

一种选择可能是写某种的HttpWebRequest的发送给代理的(也许通过的ServicePoint) ,并在该实现中缓冲整个TCP请求。但是这似乎是一项艰苦的工作。

当我跑步时Fidder酒店(出于同样的原因),但不是真正的在我们的生产环境中的选项,也能正常工作......

[PS:我知道这是肯定的零碎数据包之间的时间间隔这是问题所在,因为我敲了一个套接字级测试,在那里我使用NoDelay套接字明确控制了分段]

+0

你做到完美努力理解这个问题。你唯一忘记的是服务器。它的行为是不正常的,它必须在超时间隔(大约20-100秒)内接收所有的数据包。因为它是一个RFC标准。有没有可能修复服务器? – 2010-02-05 12:20:03

+0

我已经问设备供应商这个问题,但作为一个嵌入式设备,我怀疑这可能会变得复杂,这就是为什么我试图找到客户端修补程序。 – piers7 2010-02-07 14:11:27

回答

2

最终供应商推出,其中包括一个固件升级新版本的HTTPD和问题消失了。他们使用的是BusyBox linux,显然他们遇到了HTTPD实现方面的其他问题。

在我原来的问题,我不认为有任何这样做的可靠的方式,除了编写套接字代理。上面我使用的一些解决方法是靠运气而不是设计(因为它们意味着.net一次发送整个数据包)。

0

您的嵌入式服务器是HTTP/1.1服务器吗?如果是这样,请在调用GetRequestStream()之前尝试在webrequest上设置Expect100Continue = false。这将确保HTTP堆栈在发送实体主体之前不期望来自服务器的“HTTP/1.1 100 continue”头响应。因此,即使数据包仍然会在头部和主体之间分割,数据包间隔将会缩短。

+0

通过发布我的请求作为HTTP 1.0,我已经禁用了(我假设你的意思是将'Expect'头部清空,因为请求中没有明确的Expect100Continue属性)。 – piers7 2010-02-08 00:04:55

+0

对不起,我的意思是设置ServiecPoint.Expect100Continue = false。 无论如何,我看到你有一个解决方案。但是,我同意以前的评论者,您的服务器的行为不正确。它不应该要求请求和实体进入相同的数据包。 如果您可以发布请求/响应的网络捕获(Wireshark)(在更改之前),我们可以看到究竟发生了什么,这可能有助于找出解决方案应该是什么。 – feroze 2010-02-08 22:49:16

1

什么具有似乎有固定其上与该URI相关联的的ServicePoint禁用Nagling的,和发送所述请求作为HTTP 1.0(均未自己似乎修复它):

var servicePoint = ServicePointManager.FindServicePoint(uri.Uri); 
servicePoint.UseNagleAlgorithm = false; 

然而这似乎仍然只是通过使请求更快地完成而不是强制将标头和有效负载写入为一个数据包。因此,它大概可以加载机/高延迟链路上的失败等

不知道它会怎样很难写一个碎片整理代理...

+0

您是否也禁用了Expect100Continue。尽管可能与嵌入式服务器无关,但我已经认识到这两个属性受到一些未公开的规则的约束,例如对我来说Epect100Continue = true在某些情况下禁用了naggle算法,尽管该属性被设置为true。 另请参阅SupportsPipelining。我怀疑关掉它会立即关闭连接,而不是保持打开状态,这在嵌入式服务器上可能不是个好主意。 – redcalx 2010-03-05 10:12:51