在伯克利的TCP实现中，当服务器正处于忙时，TCP是如何处理这时的呼入连接请求？

一个并发服务器调用一个新的进程来处理每个客户请求，因此处于被动连接请求的服务器应该始终准备处理下一个呼入的连接请求。那正是使用并发服务器的根本原因。但仍有可能出现当服务器在创建一个新的进程时，或操作系统正忙于处理优先级更高的进程时，到达多个连接请求。当服务器正处于忙时，TCP是如何处理这些呼入的连接请求？

在伯克利的TCP实现中采用以下规则：

1. 正等待连接请求的一端有一个固定长度的连接队列，该队列中的连接已被TCP接受，但还没有被应用层所接受。注意区分TCP接受一个连接是将其放入这个队列，而应用层接受连接是将其从该队列中移出。

2. 应用层将指明该队列的最大长度，这个值通常称为积压值。它的取值范围是0~5之间的整数，包括0和5。

3. 当一个连接请求到达时，TCP使用一个算法，根据当前连接队列中的连接数来确定是否接收这个连接。我们期望应用层说明的积压值为这一端点所能允许接受连接的最大数目，但情况不是那么简单。下图显示了积压值与传统的伯克利系统和Solaris2.2所能允许的最大接受连接数之间的关系。
   

4. 如果对于新的连接请求，该TCP监听的端点的连接队列中还有空间，TCP模块将对SYN进行确认并完成连接的建立。但应用层只有在三次握手中的第三个报文段收到后才会知道这个新连接时。另外，当客户进程的主动打开成功但服务器的应用层还不知道这个新的连接时，它可能会认为服务器进程已
   经准备好接收数据了。

5. 如果对于新的连接请求，连接队列中已没有空间，TCP将不理会收到的SYN。也不发回任何报文段。如果应用层不能及时接受已被TCP接受的连接，这些连接可能占满整个连接队列，客户的主动打开最终将超时。