实现基于HTTP请求的拥塞控制机制，大家有没有什么经验？

我们现在做的系统，要在两台机器间使用HTTP发送XML报文的方式来通讯。在压力很大的情况下，需要做拥塞控制的考虑，目前我们的想法是这样的：

客户机发送报文到A，A接到报文后，放入一个LinkedBlockingQueue，然后应答客户机。
从线程池中起另一个线程，到LinkedBlockingQueue中取排头的报文，发送给B机。

B机同样将收到的报文放入LinkedBlockingQueue，在放入之前，判断拥塞情况，如果Queue中已经超过500个报文，就在应答A的HTTP响应中设置status为900。

这样，A就需要在收到900的HTTP应答后，调整发送间隔时间，比如等待10分钟再发下一个，直到B机的应答返回的是200了，才恢复正常速度发送。

这个是我的初步设想，请问大家还有没有更好的建议？

大并发的情况下，不推荐用Http方式。
楼主为什么不考虑下rmi或者直接用socket来通信？

采用HTTP是客户要求的。
对于拥塞控制有没有什么建议？

JMS吧。应该能很好得满足要求。

你可以在你发送的XML里添加一个字段来标示需要间隔多长时间再发送

这个可以参考TCP协议的“窗口机制”，也就类似你这样做的了。

客户端-》server A-》server B
没有什么问题。server A中你可用JMS来实现这样的机制。这个还能够持久化到队列中。

大并发的情况下，不推荐用Http方式。
楼主为什么不考虑下rmi或者直接用socket来通信？

由于HTTP是TCP的，为了保证信息的正确做了一些消耗，但是这些消耗的代价是你不必担心数据错误，不必自己组装数据包，即使你自己来做那么性能不一定比TCP的算法高明。你这里的socket是指什么？二进制的数据？通讯协议呢？rmi一样是TCP，不比http高到哪里去。只是数据是二进制的而已。

看来 B 机并不需要等处理完才回应 A 机。何不让 B 机暂时将请求数据存在数据库或者文件里面？而对请求数据的处理则另起一个进程执行。