实现基于HTTP请求的拥塞控制机制，大家有没有什么经验？
我们现在做的系统，要在两台机器间使用HTTP发送XML报文的方式来通讯。在压力很大的情况下，需要做拥塞控制的考虑，目前我们的想法是这样的：
客户机发送报文到A，A接到报文后，放入一个LinkedBlockingQueue，然后应答客户机。
从线程池中起另一个线程，到LinkedBlockingQueue中取排头的报文，发送给B机。
B机同样将收到的报文放入LinkedBlockingQueue，在放入之前，判断拥塞情况，如果Queue中已经超过500个报文，就在应答A的HTTP响应中设置status为900。
这样，A就需要在收到900的HTTP应答后，调整发送间隔时间，比如等待10分钟再发下一个，直到B机的应答返回的是200了，才恢复正常速度发送。
这个是我的初步设想，请问大家还有没有更好的建议？
1 楼 rwl6813021 2009-09-03 大并发的情况下，不推荐用Http方式。
楼主为什么不考虑下rmi或者直接用socket来通信？ 2 楼 weaveph 2009-09-04 rwl6813021 写道大并发的情况下，不推荐用Http方式。
楼主为什么不考虑下rmi或者直接用socket来通信？
采用HTTP是客户要求的。
对于拥塞控制有没有什么建议？ 3 楼 魔力猫咪 2009-09-04 JMS吧。应该能很好得满足要求。 4 楼 lyy3323 2009-11-19 你可以在你发送的XML里添加一个字段来标示需要间隔多长时间再发送 5 楼 vlinux 2009-11-20 这个可以参考TCP协议的“窗口机制”，也就类似你这样做的了。
6 楼 fireflyc 2009-11-20 客户端-》server A-》server B
没有什么问题。server A中你可用JMS来实现这样的机制。这个还能够持久化到队列中。
大并发的情况下，不推荐用Http方式。
楼主为什么不考虑下rmi或者直接用socket来通信？
由于HTTP是TCP的，为了保证信息的正确做了一些消耗，但是这些消耗的代价是你不必担心数据错误，不必自己组装数据包，即使你自己来做那么性能不一定比TCP的算法高明。你这里的socket是指什么？二进制的数据？通讯协议呢？rmi一样是TCP，不比http高到哪里去。只是数据是二进制的而已。 7 楼 yiding_he 2009-11-20 看来 B 机并不需要等处理完才回应 A 机。何不让 B 机暂时将请求数据存在数据库或者文件里面？而对请求数据的处理则另起一个进程执行。
