Hash algorithms

Either Murmur2 or FNV-1a would be a good fit, according to the answer on StackExchange.

Syn Attack Protection

In a performance test, a bug was reported: a web application cannot handle clients' requests.

Server side:

• more than 10k TIME_WAIT;
• no error - no entry in Event Log or log files;
• performance is OK (by measuring CPU, MEM, DISK, etc. using performance counter)
• except the counts of received requests and processed requests are under expected
• the count goes to 0 from certain time for certain clients in the order of test load (the most heavy working client gets blocked first)
• the firewall is disabled
  

Client sides: all clients are running the same tests using the same test tool, except for the test data and test load

• for certain client, if it fails, it fails forever
• generates the following exception: System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.
  

There seems no obvious errors in source code, both server side and client side.

Finally, I figure out it could possibly be the Syn Attack Protection problem, which is enabled by default and cannot be changed since Windows Vista.
In our case it's not like a typical syn flood attack, but based on the Cause analysis of the "General Network Error" of BizTalk, it could possibly be a Syn Attack, and protected by Windows 2008 SP1.

Other resources:
Next Generation TCP/IP Stack (and especially the changes to registry)
WinNT TCP/IP May Reuse TIME-WAIT Connections Prior to 2MSL

Too many TIME_WAIT:
System.Diagnostics.Stopwatch/QueryPerformanceCounter not working on Amazon AWS, other symptoms, and the solution
The cost on server side

The socket also ties up that particular src/dst IP address and port so it cannot be reused for the duration of the TIME_WAIT interval. (This is the intended purpose of the TIME_WAIT state.) Tying up the port is not usually an issue unless you need to reconnect a with the same port pair. Most often one side will use an ephemeral port, with only one side anchored to a well known port. However, a very large number of TIME_WAIT sockets can exhaust the ephemeral port space if you are repeatedly and frequently connecting between the same two IP addresses. Note this only affects this particular IP address pair, and will not affect establishment of connections with other hosts.

HttpWebRequest related
Howto keep connection live
Timing out after awhile;

Worth a read
Avoiding TCP/IP Port Exhaustion: only the Cause section
A short explanation on TIME_WAIT
TIME_WAIT Effects on Busy Servers: maybe outdated, and tested on SunOS
64k ephemeral port limit is per IP address, not per machine

Outdated
Configure the max limit for concurrent TCP connections
How to harden the TCP/IP stack against denial of service attacks in Windows Server 2003
Registry Settings that can be Modified to Improve Network Performance
Exhaustion of the ephemeral ports
Problems when you make Web service requests from ASP.NET applications
TCP settings that can impact BizTalk Server
MaxUserPort and TcpTimedWaitDelay