Scalable networking

Facet udowania, że OpenBSD (s. 65, 73) nie nadaje się do zastosowań sieciowych ;)

Workaround na alteona

Alteon to sprzętowy balancer. Źle działający (źle skonfigurowany) powoduje objawy w postaci SocketException: Connection reset. Workaround to napisanie proxy poprzedzającego alteona (po ServerSocket.accept() tworzymy wątek do obsługi klienta):

BufferedInputStream bis = new BufferedInputStream(cli.getInputStream());
dst = new Socket();
dst.setKeepAlive(true);
dst.setReceiveBufferSize(1024);
dst.setSendBufferSize(1024);
dst.setReuseAddress(true);
dst.setSoLinger(true, 3000);
dst.setTcpNoDelay(true);
dst.setSoTimeout(30000);
int n = bis.read(buff);
System.out.println("---- outgoing ----");
System.out.println(new String(buff, 0, n));
dst.connect(new InetSocketAddress(dstHost, dstPort), 10000);
OutputStream os = dst.getOutputStream();
InputStream is = dst.getInputStream();
os.write(buff, 0, n);
os.flush();
Thread.sleep(10000);
int m = is.read(buff);
System.out.println("---- incoming ----");
System.out.println(new String(buff, 0, m));
cli.getOutputStream().write(buff, 0, m);
cli.close();
dst.close();

Co jest tutaj ważne? Keep-alive. Ponadto po zapisaniu całej wiadomości wychodzącej nie zamykamy strumienia wyjściowego, a przed czytaniem ze strumienia od alteona, śpimy przez kilka sekund.

Z dokumentacji: Preventing Denial of Service: Alteon Web Switches can thwart Denial of Service (DoS) attacks or TCP SYN attacks without blocking valid session requests. Through “delayed binding” Alteon Web OS intercepts client SYN requests before they reach the server. The Web Switch then responds to the client with a SYN ACK that contains embedded client information and does not allocate a session until a valid SYN ACK is received from the client or the three-way handshake is complete. By temporarily terminating each TCP connection until content has been received, Alteon Web Switches prevent the server from being inundated with SYN requests. Half-open sessions are a result of an incomplete three-way handshake between the server and client. To detect SYN attacks, Alteon Web OS enables tracking of the number of new half-open sessions over a set period of time. If the value exceeds a specified threshold, then the Alteon Web Switch triggers a trap to notify the administrator.

Rozmiary okien TCP

www.wp.pl 4380
www.onet.pl 5792
www.google.pl 5672
www.gazeta.pl 32768
www.microsoft.com 8190

Jak uaktywnia się skalowanie okna TCP

W przypadku Axis-a można to rozwiązać tak:

System.setProperty("tcp.window.size", "64000");
AxisProperties.setProperty("axis.socketFactory", "CustomSocketFactory");

Czasy WebService'u dla rozmiaru okna:

1460 (RWIN=MSS :) => 21860 ms
5000, 7000, 17000, 33000, 64000 => 4500-6500 ms

TCP Window Scaling

Diagnostyka i konfiguracja. Po drodze może być stary Cisco IOS Firewall obcinający pakiety spoza okna (którego rozmiar jest w rzeczywistości przeskalowany przez 2^wscale)...

Yet another firewall issue

Pod koniec wywołania WebService'u ginie segment TCP; warstwa transportowa ciągle próbuje dokończyć transmisję, co widać jako wiszenie WebService'u. Co ciekawe, w takim przypadku w kliencie .NET ustawienie timeout-u nic nie daje i aplikacja kliencka będzie cała wisieć.

W trybie debugowania pojawia się ContextSwitchDeadlockException: The CLR has been unable to transition from COM context 0x21def80 to COM context 0x21df1d0 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.
netsh int tcp set global autotuninglevel=disabled
DefaultTTL=128, SackOpts=0

Duża liczba połączeń w stanie CLOSE_WAIT na Apache'u

W ramach rekomendacji poaudytowych Altkom radzi firmom bezkrytycznie włączać najlepiej wszystkie reguły SmartDefense na firewallu CheckPoint. Gdyby chociaż raz przetestowali to, co proponują, to by wiedzieli, że mogą swoim doradztwem zrobić ludziom bajzel na produkcji.

Zablokowanie połączeń TPC/IP keep-alive realizowane jest w ten sposób, że firewall preparuje pojedyńczy pakiet FIN+ACK, który wysyła do hosta. Host ten liczy, że wyśle ACK-a i dostanie w odpowiedzi FIN+ACK, a po wysłaniu LAST_ACK zamknie połączenie. Tymczasem taka wyminana pakietów nie zachodzi i mamy wiszące połączenia w stanie CLOSE_WAIT. Po pewnym czasie procesy Apache'a strasznie się mnożą, a cały serwis WWW przestaje odpowiadać.

Workaround w httpd.conf:
KeepAlive Off
TimeOut 60