나무를 심어야지

아파치서버 동시접속자수에 따른 메모리 산정 (대략)

불펭 — Fri, 28 Oct 2011 14:42:49 +0900

Prefork 방식의 아파치 서버일 경우 한명의 client 접속시 일반적으로 5~10MB 정도의 메모리를 사용하게 된다.
-> ps aux 명령어 결과에서 RSS 크기를 참조한다. 아래 예시를 보면

# /usr/ucb/ps aux | grep apac
root 8688 0.0 0.1 5280 3936 ? S 1월 21 0:55 /home/apac
nobody 17125 0.0 0.1 5280 2536 ? S 14:02:27 0:00 /home/apac
nobody 17126 0.0 0.1 5280 2536 ? S 14:02:28 0:00 /home/apac
nobody 17127 0.0 0.1 5280 2536 ? S 14:02:28 0:00 /home/apac
nobody 17128 0.0 0.1 5280 2536 ? S 14:02:29 0:00 /home/apac
nobody 17129 0.0 0.1 5280 2536 ? S 14:02:29 0:00 /home/apac
nobody 17130 0.0 0.1 5280 2536 ? S 14:02:29 0:00 /home/apac
nobody 17131 0.0 0.1 5280 2536 ? S 14:02:29 0:00 /home/apac
root 20143 0.0 0.1 1776 1424 pts/2 S 17:55:55 0:00 grep apac

메모리가 8GB 이고, 기본적으로 OS에서 1GB 사용, DB 등 다른 S/W에서 1GB 사용하여 6GB가 여분이고, 편의상 client당 10MB 사용한다면
6GB*1024/10MB = 614.4 로 약 600여명이 동시접속 가능하게 된다.

물론, 이는 메모리만 산정할 경우를 계산한 것이다.

네트워크 밴드위스의 경우,
웹서버는 이미지 외에 크게 전송할 콘텐츠가 아니므로 보통 300KB/sec
정도면 훌륭합니다. 그러나 실제로 클라이언트 환경에 좌우되기 때문에
이 속도까지 나오지 않고 보통 10 ~ 300KB/sec 정도입니다.

여기에서는 편의상 작은 50KB/sec 으로 잡는다면
50KB/sec = 50 * 8 KBits/sec = 400Kb/sec 입니다.

10MBPS => 10Mb/sec = 10*1024Kb/sec / 400Kb/sec => 26 Clients

아파치 동시접속자수 변경 (1.3.xx 및 2.0.xx 버전)

불펭 — Fri, 28 Oct 2011 14:41:20 +0900

1. 아파치 2.0.xx 버전

기본 동시접속자수는 최대 256명. 이를 더 많은 숫자로 변경하기 위해서는 아래 파일 수정 후 재펌파일이 필요하다.
/apache/../server/mpm/prefork/prefork.c 파일에서
#define DEFAULT_SERVER_LIMIT 256
위에서 숫자 부분을 적당하게 늘려주고

/apache/../server/mpm/worker/worker.c 파일에서
#define DEFAULT_SERVER_LIMIT 16
위에서 숫자 부분을 적당하게 늘려준다.

예를 들어 prefork.c 파일에서 1280으로 늘려주었다면, worker.c 파일은 20으로 늘려주는데, 그 이유는 아래와 같다.

worker 방식은 기본적으로 16개의 child process와 그 안에 64개의 thread를 생성가능하므로, 16*64 = 1024가 된다. 따라서 prefork.c 파일에서 1280으로 늘려주게 되면, worker.c는
1280/64 = 20이 되므로 20으로 수정해 줘야 똑같이 1280명의 동시접속자가 가능하게 된다.

컴파일은 아래와 같이 수행한다.

기존에 /usr/local/apache 로 웹서비스를 사용중이라면
/usr/local/apache 가 아닌 다른 이름으로 컴파일 설치 하면 충돌없이 컴파일이 됩니다.
configure 는 컴파일 환경을 설정 해주는 것입니다.

./configure --prefix=/usr/local/apache2/
make
make install

하면 컴파일이 되겠습니다.

컴파일 후 /usr/local/apache 에 있는 설정 파일들을 /usr/local/apache2 에 복사한 후
웹사이트를 잠시 중지 할 수 있는 시간을 이용하여 apache 를 중지하고 apache2 를 가동하여
오류 여부등을 확인한 한다음 정상적으로 웹사이트가 운영이 된다면 apache 를
삭제(백업필수) 한 뒤 디렉토리명을 apache2 에서 apache 로 변경하여 정상 운영 하면 되겠습니다.
(물론 환경설정 부분이 수정될 수 있습니다. 꼼꼼히 체크 하는 것 잊지 마세요.)

2. 아파치 1.3.xx 버전

기본 동시접속자수는 최대 256명인데, 이는 MaxClients에 입력가능한 최대치를 말합니다.
256명 이상의 동시접속을 허용하고자 할 경우에는 아파치를 다시 재 컴파일해야 합니다.
아파치 디렉토리로 이동하여 ../src/include 안의 httpd.h 에서 다음과 같은 부분을 찾아
값을 높여 주시면 됩니다.

#define HARD_SERVER_LIMIT 512

위와같이 설정 한 후 http.h 파일을 재컴파일해야 정상적으로 적용이 됩니다.

만약 클라이언트가 512명 이상의 접속을 넘어서 이루어질 경우에는 다음과 같은 메시지가
로그파일에 남게 되며, 클라이언 트는 다른 요청의 접속이 끝날 때 까지 대기하거나
또는 특정시간이 지난 후 접속이 이루어질 수 없다는 메시지를 보여주게 된답니다 .

[error] server reached MaxClients setting, consider raising the MaxClients setting.

만약, 동시접속자 수를 기본 동시접속자 최대 수인 256명 미만으로 조정하고자 한다면,
재컴파일이 필요없이 아래 파일만 수정합니다.

../conf/httpd.conf
MaxClients 150

그리고, 아파치를 리스타트 하면 됩니다.
# apachectl restart

[출처] http://kikook.tistory.com/entry/아파치-동시접속자수-변경-13xx-및-20xx-버전

Combobox에 Key 와 Value 값을 설정해서 쓰자..

불펭 — Thu, 13 Oct 2011 17:53:27 +0900

Dictionary<Int32, String> risk = new Dictionary<int, string>();

private void test(){
risk.Add(1, "Low");
risk.Add(2, "Medium");
risk.Add(3, "High");
comboBox1.DataSource = new BindingSource(risk, null);
comboBox1.DisplayMember = "Value";
comboBox1.ValueMember = "Key";
comboBox1.SelectedIndexChanged += new EventHandler(comboBox1_SelectedIndexChanged);
}

private void cmbName_SelectedIndexChanged(object sender, EventArgs e)
{

}

[출처]http://social.msdn.microsoft.com/Forums/en-US/winforms/thread/3695ced1-18ea-4b85-93c8-2ed04bf22dc5

한동훈의 C# 쓰레드 이야기

불펭 — Fri, 07 Oct 2011 09:38:41 +0900

Invoke , BeginInvoke, MethodInvoker

불펭 — Fri, 07 Oct 2011 09:37:40 +0900

Invoke, MethodInvoker, BeginInvoke - EndInvoke

UI Control들은 폼 구동시 실행되는 하나의 쓰레드에서 구동된다. 따라서 사용자가 실행시킨 쓰레드는 별도로 실행 되기 때문에 이 메인 쓰레드에 적절한 마샬링 없이 다른쓰레드에서 직접 접근하면 다른 쓰레드를 침범하는 것이다. (Cross Thread Problem) 이런 경우에는 프로그램이 개발자가 설계한대로 잘 동작하지 않을 수 있다.(Race Condition,DeadLock) 따라서, 안전하게 동작하게 하기위하여 .Net 환경에서는 Invoke를 제공하고 있다.

본 내용을 무시한 채 프로그램을 작성하면 InvalidOperationException을 발생시키고 . Debug 창에서 "컨트롤이 자신이 만들어진 스레드가 아닌 스레드에서 액세스되었습니다."라는 메세지가 표시 된다. 하지만 디버깅 환경이 아니라면 프로그램은 겉보기에 정상 동작하는 것 처럼 보일 수 있으므로 조심해야 된다. !

난 대충 좀 안되도 상관 없다고 생각하시는 분들은 이 예외를 비활성화 할 수도 있습니다.

CheckForIllegalCrossThreadCalls 속성 값을 false로 설정하여 이 예외를 비활성화할 수 있습니다. 그러면 컨트롤이 Visual Studio 2003에서와 같은 방식으로 실행됩니다.

자 그럼 쓰레드에서 안전하게 Windows Form control을 제어하게 하는 방법에 대해 알아보자

InvokerRequired 속성은 Invoke메쏘드를 호출해야되는지 알려준다.

Invoke

쓰레드에서 폼 컨트롤 하기 위해서는 별도의(SetTextononTextBox1) 메쏘드를 만들어 사용하면 좋다. 예를들어, Textbox에 값을 입력한다면 아래와 같은 'SetTextonTextBox1' 메쏘드를 만들어서 사용하면 Cross thread 환경이든 내부 쓰레드 사용환경에서든 둘다 사용할 수 있다.

Invoke를 사용할 때 인자를 넘겨줘야 하는 메쏘드 필요하면 할때는 반드시 delegate를 선언한 후에 사용하여야 한다.

delegate void SetTextCallback(string txt);
private void SetTextonTextBox1(string txt)
{
if (this.textBox1.InvokeRequired)
{
this.Invoke(new SetTextCallback(SetTxtCB), new object[] { txt }); //그냥 txt를 넘겨줘도 된다
}
else
{
this.textBox1.Text += txt;
}
}
private void SetTxtCB(string txt)
{
this.textBox1.Text+=txt;
}

인자가 없는 메쏘드를 호출할 때는 간단하게 MethodInvoker를 사용하면 좋다.

private void SetTextonTextBox1(string txt)
{
if (this.textBox1.InvokeRequired)
{
this.Invoke(new MethodInvoker( delegate { this.textBox1.Text+=txt; }) );

}
else
{
this.textBox1.Text += txt;
}
}

BeginInvoke , EndInvoke

우선 BeginInvoke를 설명하기 전에 Windows Form 의 Control.BeginInvoke 메쏘드와 Delegate.BeginInvoke 메쏘드에 대해서 차이점을 설명하고 본 단락에서는 Winfows Form Control의 BeginInvoke만 설명하도록 하겠다.

Delegate.BeginInvoke는 Asynchronous Delegate를 만들어서 콜백을 하는 것이라고 생각하면 되겠다. 다시말해서, CLR에서 관리하는 쓰레드풀에서 해당 메쏘드를 큐잉한다. 쉽게 얘기해서 별도의 쓰레드를 만들어서 Delegate를 실행한다고 보면 된다. 장점은 IAsyncResult를 이용해서 Object 결과값을 넘겨 받을 수 있다. 보다 자세한 사항은 이곳을 참조!

Windows Form의 Control.BeginInvoke는 Control 내부 핸들이 작성된 쓰레드(메인쓰레드)에서 지정된 대리자를 비동기식으로 실행한다. 비동기식이므로 실행을 대기하지 않고 BeginInvoke는 즉시 Return 한다.

차이점을 정리 하자면 Control.BeginInvoke는 실행코드의 GUI Thread에 작성된 코드이고 Delegate.BeginInvoke는 쓰레드풀 쓰레드에 사용된다. 또한 Control.BeginInvoke의 경우는 EndInvoke를 호출하지 않아도 되나 Delegate.BeginInvoke의 경우는 반드시 Delegate.EndInvoke를 호출해줘야 한다 안그러면 메모리 릭이 발생한다.

public delegate void InvokeDelegate();
private void Invoke_Click(object sender, EventArgs e)
{
myTextBox.BeginInvoke(new InvokeDelegate(InvokeMethod));
}
public void InvokeMethod()
{
myTextBox.Text = "Executed the given delegate";
}

Endinvoke

References

DATEDIFF() 날짜와 날짜 사이 간격은?

불펭 — Mon, 05 Sep 2011 15:59:21 +0900

※ 함수명 DATEDIFF()

1. 사용 : DATEDIFF() : MSSQL

2. 설명

- 지정한 두 날짜 사이에 있는 날짜와 시간 경계의 수를 반환합니다.

3. 형식

- DATEDIFF(datepart, startdate, enddate)

※datepart

year	yy, yyyy
quarter	qq, q
month	mm, m
dayofyear	dy, y
day	dd, d
week	wk, ww
Hour	hh
minute	mi, n
second	ss, s
millisecond	ms

※startdate, edndate 는 DATETIME 형식이거나 날짜형식을 띄는 문자열

4. 예제

   - SELECT DATEDIFF(Week,'20110101','20110101') : 0
   - SELECT DATEDIFF(Week,'20110101','20111231') : 52
   - SELECT DATEDIFF(Day,'20110101','20111231') : 364
   - SELECT DATEDIFF(Month,'20110101','20111231') : 11
   - SELECT DATEDIFF(Year,'20110101','20111231') : 0

윈도우 Dos공격 방어

불펭 — Tue, 30 Aug 2011 18:27:38 +0900

[SIS 학습장] 윈도우 보안 - 13. Dos공격 방어

아래와 같이 웹 서버가 초당 1000개 이상의 SYN 패킷을 받고 있었다.
앞으로 이런 유형의 공격을(DoS) 방어하기 위한 레지스트리 값을 설정하여라.

C:>netstat -na | findstr ` SYN_RECEIVED`
TCP 211.241.82.71:80 6.55.194.236:51370 SYN_RECEIVED
TCP 211.241.82.71:80 16.192.252.18:22452 SYN_RECEIVED
TCP 211.241.82.71:80 49.5.243.221:52363 SYN_RECEIVED
TCP 211.241.82.71:80 50.145.99.80:46108 SYN_RECEIVED
TCP 211.241.82.71:80 51.53.109.147:28308 SYN_RECEIVED
TCP 211.241.82.71:80 61.58.85.212:52375 SYN_RECEIVED
TCP 211.241.82.71:80 63.33.85.135:32111 SYN_RECEIVED
TCP 211.241.82.71:80 67.206.19.195:28501 SYN_RECEIVED
TCP 211.241.82.71:80 68.79.239.155:42810 SYN_RECEIVED
TCP 211.241.82.71:80 221.29.79.118:36387 SYN_RECEIVED

TCP/IP 네트워크의 기본적인 취약점인 SYN Flooding 에 대한 문제입니다.

현재까지도 완벽한 대응법은 존재하지 않으며 다만 백로그 큐를 늘려주는 방법으로 대응하고 있습니다.

이 문제는 레지스트리를 변경해야 합니다.

아래 해설은 문제를 푼다기 보다 SYN 플러딩 및 DoS공격을 대응하기 위한 레지스트리 모음입니다.

(아래 대로 하시면 문제를 클리어 할 수있습니다.)

주어진 값은 예시 이고 실제 시스템의 환경에 맞게 조정해야 합니다.

<HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip\parameters>

키	값 (십진수)	설명
SynAttackProtect	2	TCP(Transmission Control Protocol)가 SYN-ACKS의 재전송을 조정하도록 합니다. 이 값을 구성하면 SYN 공격(서비스 거부 공격의 한 종류) 동안 연결 응답이 더 빨리 시간 초과됩니다.
TcpMaxHalfOpen	100	HalfOpen 의 최대치(?)
TcpMaxHalfOpenRetried	100	재시도된 HalfOpen 의 최대치(?)
TcpMaxPortsExhausted	5	SYN-ATTACK 보호가 작동하기 시작하는 시점을 결정합니다. 사용 가능한 연결 백로그가 0으로 설정되었기 때문에 시스템에서 TCPMaxPortsExhausted 연결 요청을 거부하면 SYN-ATTACK 보호가 작동하기 시작합니다. 이 경우 합법적인 방법으로 이를 사용하려는 서버나 시스템에는 거의 영향을 주지 않습니다.
TcpMaxConnectResponseRetransmissions	2	SYN이 확인되지 않은 경우 연결 요청에 대한 응답으로 SYN-ACK가 재전송되는 횟수를 결정합니다. 이 값이 2 이상인 경우 스택은 내부적으로 SYN-ATTACK 보호를 사용합니다. 이 값이 2 미만인 경우, 스택은 SYN-ATTACK 보호를 위한 레지스트리 값을 전혀 읽지 않습니다. 이 매개 변수는 부분 공개 TCP 연결을 정리하는 데 걸리는 기본 시간을 줄입니다. 심한 공격을 받는 사이트의 경우 이 값을 1처럼 매우 낮은 값으로 설정할 수도 있습니다. 0 값도 유효합니다. 그러나 이 매개 변수를 0으로 설정하면 SYN-ACK는 전혀 재전송되지 않으며 3초 이내에 시간 초과됩니다. 이 값을 이처럼 낮게 설정하면 멀리 떨어진 클라이언트에서 합법적으로 연결을 시도해도 연결되지 않습니다
EnableDeadGWDetect	0	무반응 게이트웨이 검색이 사용 가능한 경우 TCP는 연결 수에 문제가 있을 때 백업 게이트웨이로 변경하도록 IP에 요구합니다. 이 설정을 0으로 구성하면 Windows에서는 무반응 게이트웨이를 더 이상 검색하지 못하고 자동으로 다른 게이트웨이로 전환합니다.
EnablePMTUDiscovery	0	EnablePMTUDiscovery를 1로 설정하면, TCP는 MTU(maximum transmission unit) 또는 원격 호스트 경로에서 가장 큰 패킷 크기를 찾으려고 시도합니다. TCP는 경로 MTU를 찾고 TCP 세그먼트를 이 크기로 제한하여 다른 MTU와 연결되는 경로를 따라 라우터의 조각화를 제거합니다. 조각화로 인해 TCP 처리량이 줄어들 수 있습니다. 이 값을 0으로 설정하면, 로컬 서브넷의 호스트가 아닌 모든 연결에 MTU 576바이트가 사용됩니다.
KeepAliveTime	300000	TCP가 활성 상태 패킷을 보내 유휴 연결이 그대로 있음을 확인하는 빈도를 결정합니다. 원격 컴퓨터에 여전히 연결 가능한 경우 TCP는 활성 상태 패킷을 확인합니다. 기본적으로 활성 상태 패킷은 보내지지 않습니다. 프로그램을 통해 연결 시 이 값을 구성할 수 있습니다. 이 값을 기본값인 2시간에서 5분으로 낮추면 비활성 세션의 연결이 더 빨리 끊어집니다.
NoNameReleaseOnDemand	1	컴퓨터가 이름 해제 요청을 받을 때 NetBIOS 이름을 해제할지 여부를 결정합니다. 이 값은 관리자가 악의적인 이름 해제 공격으로부터 컴퓨터를 보호할 수 있도록 추가되었습니다. NoNameReleaseOnDemand 값은 1로 설정하는 것이 좋습니다.
EnableICMPRedirects	0	RRAS(라우팅 및 원격 액세스 서비스)가 ASBR(Autonomous System Boundary Router)로 구성된 경우 연결된 인터페이스 서브넷 경로를 올바로 가져올 수 없습니다. 대신 이 라우터는 OSPF(Open Shortest Path First) 경로에 호스트 경로를 삽입합니다. OSPF 라우터를 ASBR 라우터로 사용할 수 없기 때문에 연결된 인터페이스 서브넷 경로를 OSPF로 가져오면 라우팅 테이블이 이상한 라우팅 경로와 혼동됩니다.
interfacesPerformRouterDiscovery	0	네트워크 인터페이스의 라우터 찾기 수행(?)
EnableSecurityFilters	0	1로 설정하면 TCP/IP 스택이 TcpAllowedPorts와 UdpAllowedPorts에서 지정된 포트에 따라 외부로부터의 접속 요구를 걸러 줍니다.
DisableIPSourceRouting	2	IP 원본 라우팅은 데이터그램이 네트워크를 통해 취해야 할 IP 경로를 보낸 사람이 결정할 수 있도록 하는 메커니즘입니다. 이 값을 2로 설정하면 원본에서 라우팅한 모든 들어오는 패킷이 삭제됩니다.
TcpMaxDataRetransmissions	3	TCP는 각 아웃바운드 세그먼트가 IP로 전달될 때 재전송 타이머를 시작합니다. 타이머가 만료되기 전에 해당 세그먼트에서 데이터에 대한 확인이 수신되지 않은 경우 세그먼트는 세 번까지 재전송됩니다.
TcpTimedWaitDelay	100	TcpTimedWaitDelay 값은 TCP/IP가 닫힌 연결을 해제하여 자원을 다시 사용하기 전에 경과되어야 하는 시간을 결정합니다. 닫기와 해제 사이의 이 간격은 `TIME_WAIT` 상태 또는 최대 세그먼트 지속 시간의 두배(2MSL) 상태로 알려져 있습니다. 이 시간 동안 클라이언트 및 서버로의 연결을 다시 여는 것이 새 연결을 설정하는 것보다 비용이 적게 듭니다. 이 항목의 값을 줄이면 TCP/IP는 닫힌 연결을 더욱 빨리 해제할 수 있으며 새 연결에 더 많은 자원을 제공합니다. TIME_WAIT 상태에 있는 여러 연결로 인해 발생한 낮은 처리량 때문에 실행 중인 응용프로그램에 빠른 해제, 새 연결 작성 또는 조정이 필요할 경우 이 매개변수를 조정하십시오.
PerformRouterDiscovery	0	IRDP(Internet Router Discovery Protocol)를 지원하는 Windows 2000이 컴퓨터에서 기본 게이트웨이 주소를 자동으로 검색 및 구성하지 못하도록 하기 위해 설정됩니다.

<HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\parameters>

키	값 (십진수)	설명
EnableDynamicBacklog	1	FTP 서버 및 웹 서버와 같은 Windows 소켓 응용 프로그램의 연결 시도는 Afd.sys에 의해 처리됩니다. Afd.sys는 합법적 클라이언트에 대한 액세스를 거부하지 않고 부분 공개 상태에서 여러 번의 연결을 지원하도록 수정되었습니다. 관리자가 동적 백로그를 구성할 수 있도록 함으로써 이러한 지원이 가능해졌습니다. DynamicBacklogGrowthDelta는 연결이 더 필요할 때 만들 사용 가능 연결 수를 결정합니다. 값이 크면 free 연결 할당이 폭주할 수 있으므로 이 값을 주의하여 설정하십시오.
MinimumDynamicBacklog	20
MaximumDynamicBacklog	1000
DynamicBacklogGrowthDelta	10

<HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\parameters>

키	값 (십진수)	설명
NoNameReleaseOnDemand	1	컴퓨터가 이름 해제 요청을 받을 때 NetBIOS 이름을 해제할지 여부를 결정합니다. 이 값은 관리자가 악의적인 이름 해제 공격으로부터 컴퓨터를 보호할 수 있도록 추가되었습니다. NoNameReleaseOnDemand 값은 1로 설정하는 것이 좋습니다.

< 설명 출처 >

제목	저자	링크
Windows 2000 Server에서의 TCP/IP 악용 및 대책	Microsoft	http://www.microsoft.com/korea/technet/security/prodtech/windows2000/win2khg/05tcpip.mspx
Windows 성능 조정	IBM	http://publib.boulder.ibm.com/wasce/V1.0.1/ko/Tasks/Tuning/Windows.html
난, 레지스트리로 PC 관리한다	이순원	책

수고하셨습니다~~~~

-악어c

http://blog.akerc.pe.kr

[Window/TCP] 윈도우에서 TCP 파라미터 튜닝

불펭 — Tue, 30 Aug 2011 18:22:51 +0900

[Window/TCP] 윈도우에서 TCP 파라미터 튜닝

까막군's 주접 블로그

공부방/OS 관련

2011/01/05 11:44, 글쓴이 까막군

결국 윈도우에서 TCP 연결의 개수를 최대한 늘이기 위한 방법은 TcpTimedWaitDelay, MaxUserPort, MaxFreeTcbs, MaxHashTableSize 파라미터를 늘여주는 것이다.

Windows에서 TcpTimedWaitDelay를 설정

TCP 파라미터는 물론 플랫폼 별로 많은 파라미터가 존재하지만, Windows에서의 TcpTimedWaitDelay 와 Solaris의 tcp_time_wait_interval 은 동일한

파라미터로서, 커넥션이 종료 되었을 때 TIME_WAIT 상태로 머물게 되는 시간을 설정한다.

이 값의 디폴트는 4분으로 짧은 시간에 많은 클라이언트가 접속을 하면 네트웍(Network) 퍼포먼스에 영향을 줄 수 있기 때문에 60초로 제한을 두도록

권고한다.

   레지스트리 위치 : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
   유효한 범위 : 0\30~300초
값 이름 : TcpTimedWaitDelay
값 종류: DWORD
   기본값: 240초
   추천 값: 60

MaxUserPort

서버에 연결되는 Port의 숫자가 5000개 이상 (Exchange 60000) 될 경우 서버에서 네트워크 장애가 발생될 수 있음.
일반적으로 WAS와 연결되는 Windows 서버나 Exchange 서버에서 주로 발생됨.

레지스트리 위치: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
유효한 범위: 5000~65534

값 이름 : MaxUserPort
값 종류: DWORD

기본값: 5000
추천 값: 65534

MaxFreeTcbs

시스템이 TCP 연결 유지를 위해 생성하는 TCP Control Blocks(TCBs)의 숫자를 결정한다. 하나의 연결은 하나의 블록을 요구하기 때문에, 이 값은 TCP가 동시에 몇 개의 연결을 처리할 수 있느냐를 결정하게 된다. 모든 블록이 사용 중인 상황에서 새로운 연결이 들어오게 되면, TCP는 TIME_WAIT 상태인 연결 중에 하나를 강제로 끊어버리고, 블록을 해제한 후, 그 블록을 새로운 연결에 사용하게 된다.
보통 TCP는 TcpTimedWaitDelay에 지정되어 있는 시간이 지나지 않은 경우, 연결을 해제하지도 않고, 그 연결에 사용된 자원을 재사용하지도 않는다. 이 시간은 보통 TIME_WAIT 또는 2MSL (2 x maximum segment lifetime) 상태라고 불린다. 하지만 시스템이 매우 많은 연결을 받아들여 자원이 바닥날 상황에 이르면, TcpTimedWaitDelay에 지정된 시간이 아직 남아있는 경우에도 연결에 할당되어 있는 자원을 해제하게 된다.

레지스트리 위치: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

유효한 범위: 1–0xFFFFFFFF

값 이름 : MaxFreeTcbs
값 종류: DWORD

기본값: 0x1388 (십진값으로 5000)
추천 값: 2000

MaxHashTableSize

TCP Control block이 저장되는 해쉬 테이블의 크기를 결정한다.

TCP는 컨트롤 블록들을 빠르게 검색하기 위해 해쉬 테이블에다 저장한다. 만일 시스템이 동시에 생성할 수 있는 TCB의 숫자를 변경한다면(MaxFreeTcbs 값을 변경한다면), 이 항목의 값 또한 그에 비례해서 변경해줘야한다.

이 항목의 값은 반드시 2의 승수여야한다. 만일 2의 승수를 입력하지 않는다면, 시스템은 자동으로 입력한 수보다 큰 2의 승수 중에 가장 작은 것을 찾아 사용한다. 즉 128 * (시스템 cpu 개수)의 제곱

예를 들어 cpu 4장이라면, 128 * 4^2 = 2048

최대 값은 0x10000 (65,536)입니다. 연결 부하가 클 것으로 예상되는 대규모 서버에서는 최대 값을 설정하는 것이 권장됩니다. 이 테이블은 페이지 안 되는 풀을 사용하므로 서버의 가용한 페이지 안 되는 풀이 많지 않거나 연결 부하가 크지 않은 경우에는 이 값을 너무 크게 설정하면 안 된다는 사실을 명심하십시오.

레지스트리 위치: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

유효한 범위: 64 ~ 65536

값 이름 : MaxHashTableSize
값 종류: DWORD

기본값: 512

SQL Server 연결 풀링이 해제될 때 조정해야 할 수 있는 TCP/IP 설정에 대한 설명

불펭 — Tue, 30 Aug 2011 18:11:34 +0900

기술 자료 ID	:	328476
마지막 검토	:	2006년 2월 17일 금요일
수정	:	7.0

이 페이지에서

요약

추가 정보

MaxUserPort 및 TcpTimedWaitDelay 설정 조정

WinsockListenBacklog 설정 조정

요약

SQL Server ODBC 드라이버, SQL Server OLE DB 공급자 또는 System.Data.SqlClient 관리 공급자를 사용하면 해당 API(응용 프로그래밍 인터페이스)를 사용하여 연결 풀링을 해제할 수 있습니다. 풀링을 해제하는 경우 응용 프로그램에서 자주 연결을 열고 닫으면 기본 SQL Server 네트워크 라이브러리의 스트레스가 증가할 수 있습니다. 이 문서에서는 이러한 조건에서 조정해야 할 수 있는 특정 TCP/IP 설정을 설명합니다.

위로 가기

추가 정보

풀링을 해제하면 기본 SQL Server 네트워크 드라이버가 SQL Server를 실행하는 컴퓨터에 대한 새 소켓 연결을 빠르게 열고 닫을 수 있습니다. 더 높은 스트레스 수준을 처리하려면 운영 체제 및 SQL Server를 실행하는 컴퓨터의 기본 TCP/IP 소켓 설정을 변경해야 할 수 있습니다.

이 문서에서는 TCP/IP 프로토콜을 사용할 때 SQL Server 네트워크 라이브러리에 영향을 주는 설정만 설명합니다. 풀링을 끄면 명명된 파이프 같이 다른 SQL Server 프로토콜에 스트레스 관련 문제를 야기시킬 수 있지만 이에 대해서는 설명하지 않습니다. 이 문서는 고급 사용자를 위한 것입니다. 이 문서의 항목이 이해가 되지 않을 경우 TCP/IP 소켓에 대한 설명서를 참조하는 것이 좋습니다.

SQL Server 드라이버에는 항상 풀링을 사용하는 것이 좋습니다. 풀링을 사용하면 SQL Server 드라이버를 사용할 때 클라이언트측과 SQL Server측 모두에서 전반적인 성능이 크게 향상되고 SQL Server를 실행하는 컴퓨터에 대한 네트워크 트래픽도 상당히 줄어듭니다. 예를 들어, 풀링을 설정한 상태에서 SQL Server 연결을 20,000번 열고 닫는 예제 테스트에서 총 23,520바이트의 네트워크 작업에 대해 약 160개의 TCP/IP 네트워크 소켓을 사용했지만 풀링을 해제한 상태에서는 동일한 예제 테스트가 총 27,209,622바이트의 네트워크 작업에 대해 225,129개의 TCP/IP 네트워크 소켓을 생성했습니다.

SQL Server 네트워크 라이브러리에 이러한 스트레스 관련 TCP/IP 소켓 문제가 나타날 경우 SQL Server를 실행하는 컴퓨터에 연결하려고 하면 다음 오류 메시지 중 하나 이상이 나타날 수 있습니다.

SQL Server가 없거나 액세스가 거부되었습니다.

시간이 초과되었습니다.

일반 네트워크 오류입니다.

SQL Server에 다른 문제가 발생할 때도 이러한 특정 오류 메시지가 나타날 수 있습니다. 예를 들어, SQL Server를 실행하는 원격 컴퓨터가 종료되거나 TCP/IP 소켓을 전혀 수신 대기하지 않는 경우, 네트워크 케이블이 뽑혀서 SQL Server를 실행하는 컴퓨터에 대한 네트워크 연결이 끊어진 경우, DNS 확인 문제가 있는 경우 이러한 오류 메시지가 나타날 수 있습니다. 기본적으로 SQL Server를 실행하는 컴퓨터에 대해 클라이언트가 TCP/IP 소켓을 열 수 없도록 하는 문제는 오류 메시지를 수반할 수 있습니다. 그러나 스트레스 관련 소켓 문제가 있으면 스트레스가 증가하거나 감소함에 따라 문제가 간헐적으로 발생합니다. 컴퓨터가 오류 없이 몇 시간 동안 실행되다가 오류가 한 두 번 발생한 다음 다시 여러 시간 동안 오류 없이 실행될 수 있습니다. 또한 이 문제가 있으면 SQL Server에 대한 일반 연결은 한 인스턴스에서 작동하고 다음 인스턴스에서는 실패하고 그 다음 인스턴스에서는 다시 작동하게 됩니다. 즉, 스트레스 관련 소켓 문제는 대개 산발적으로 발생하지만 SQL Server의 실제 네트워크 연결 문제는 산발적으로 발생하지 않습니다.

SQL Server TCP/IP 프로토콜을 사용하는 동안 풀링을 해제하면 일반적으로 두 가지 주요 스트레스 관련 문제가 발생합니다. 클라이언트 컴퓨터에 익명 포트가 없거나 SQL Server를 실행하는 컴퓨터에서 기본 WinsockListenBacklog 설정을 초과할 수 있습니다.

익명 포트에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.

319502 (http://support.microsoft.com/kb/319502/) PRB: IMAP 연결 제한을 늘린 후 익명 포트를 통해 연결하려고 하면 "WSAEADDRESSINUSE" 오류 메시지가 나타난다

위로 가기

MaxUserPort 및 TcpTimedWaitDelay 설정 조정

연결 풀링을 사용하지 않고 SQL Server를 실행하는 원격 컴퓨터에 대한 연결을 빠르게 열고 닫는 클라이언트 컴퓨터에 대해서만 MaxUserPort 및 TcpTimedWaitDelay 설정을 적용할 수 있습니다. 예를 들어, 이러한 설정은 많은 수의 들어오는 HTTP 요청을 서비스하고 SQL Server를 실행하는 원격 컴퓨터에 대한 연결을 열고 닫으며 풀링이 해제된 상태에서 TCP/IP 프로토콜을 사용하는 인터넷 정보 서비스(IIS) 서버에 적용할 수 있습니다. 풀링이 설정된 경우에는 MaxUserPort 및 TcpTimedWaitDelay 설정을 조정할 필요가 없습니다.

TCP/IP 프로토콜을 사용하여 SQL Server를 실행하는 컴퓨터에 대한 연결을 열면 기본 SQL Server 네트워크 라이브러리에서 SQL Server를 실행하는 컴퓨터에 대한 TCP/IP 소켓을 엽니다. 이 소켓을 열면 SQL Server 네트워크 라이브러리는 SO_REUSEADDR TCP/IP 소켓 옵션을 설정하지 않습니다. SO_REUSEADDR 소켓 설정에 대한 자세한 내용은 MSDN(Microsoft Developer Network)의 "Setsockopt" 항목을 참조하십시오.

보안을 이유로 SQL Server 네트워크 라이브러리는 SO_REUSEADDR TCP/IP 소켓 옵션을 명시적으로 설정하지 않습니다. SO_REUSEADDR이 설정되면 악의 있는 사용자가 SQL Server에 대한 클라이언트 포트를 하이재킹하고 클라이언트가 SQL Server를 실행하는 컴퓨터에 액세스하기 위해 제공하는 자격 증명을 사용합니다. 기본적으로 SQL Server 네트워크 라이브러리는 SO_REUSEADDR 소켓 옵션을 설정하지 않기 때문에 클라이언트측에서 SQL Server 네트워크 라이브러리를 통해 소켓을 열고 닫을 때마다 소켓은 4분 동안 TIME_WAIT 상태에 들어갑니다. 풀링을 해제한 상태에서 TCP/IP를 통해 SQL Server 연결을 빠르게 열고 닫는 경우 TCP/IP 소켓을 빠르게 열고 닫습니다. 즉, SQL Server 연결마다 TCP/IP 소켓이 하나씩 있습니다. 4분 미만으로 4,000개의 소켓을 빠르게 열고 닫을 경우 클라이언트 익명 포트에 대한 기본 최대 설정에 도달하고 기존의 TIME_WAIT 소켓 집합이 시간 초과될 때까지 새로운 소켓 연결 시도는 실패합니다.

클라이언트측에서는 풀링이 해제되었을 때 319502에서 설명하는 MaxUserPort 및 TcpTimedWaitDelay 설정을 늘려야 할 수 있습니다. 클라이언트측에서 얼마나 많은 SQL Server 연결을 열고 닫는지에 따라 이러한 값 설정이 결정됩니다. 클라이언트 컴퓨터에서 Netstat 도구를 사용하여 얼마나 많은 클라이언트 포트가 TIME_WAIT 상태에 있는지 확인할 수 있습니다. 다음과 같이 -n 플래그와 함께 Netstat 도구를 실행하고 TIME_WAIT 상태에 있는 SQL Server IP 주소에 대한 클라이언트 소켓 수를 계산합니다. 이 예에서 SQL Server를 실행하는 원격 컴퓨터의 IP 주소는 10.10.10.20이고 클라이언트 컴퓨터의 IP 주소는 10.10.10.10이며 설정된 연결 세 개와 연결 두 개가 TIME_WAIT 상태에 있습니다.

C:\>netstat -n

Active Connections

  Proto  Local Address         Foreign Address       State
  TCP    10.10.10.10:2000      10.10.10.20:1433      ESTABLISHED
  TCP    10.10.10.10:2001      10.10.10.20:1433      ESTABLISHED
  TCP    10.10.10.10:2002      10.10.10.20:1433      ESTABLISHED
  TCP    10.10.10.10:2003      10.10.10.20:1433      TIME_WAIT
  TCP    10.10.10.10:2004      10.10.10.20:1433      TIME_WAIT

netstat -n을 실행한 후 SQL Server를 실행하는 대상 컴퓨터의 IP 주소에 대한 약 4,000개의 연결이 TIME_WAIT 상태이면 클라이언트 익명 포트가 부족해지지 않도록 기본 MaxUserPort 설정을 늘리고 TcpTimedWaitDelay 설정을 줄일 수 있습니다. 예를 들어, MaxUserPort 설정을 20000으로 설정하고 TcpTimedWaitDelay 설정을 30으로 설정할 수 있습니다. TcpTimedWaitDelay 설정이 낮아지면 소켓이 TIME_WAIT 상태로 대기하는 시간이 줄어듭니다. MaxUserPort 설정이 높아지면 TIME_WAIT 상태에 있는 소켓 수가 늘어날 수 있습니다.

MaxUserPort 또는 TcpTimedWaitDelay 설정을 조정하는 경우 Microsoft Windows를 다시 시작해야 새 설정이 적용됩니다. MaxUserPort 및 TcpTimedWaitDelay 설정은 TCP/IP 소켓을 통해 SQL Server를 실행하는 컴퓨터와 통신하는 클라이언트 컴퓨터에 사용할 수 있습니다. SQL Server를 실행하는 로컬 컴퓨터에 대한 로컬 TCP/IP 소켓 연결을 설정하지 않은 경우에는 SQL Server를 실행하는 컴퓨터에 이러한 설정이 적용되지 않습니다.

netstat를 이용한 TCP/IP 네트워크 관리 - TIME_WAIT

불펭 — Tue, 30 Aug 2011 18:08:56 +0900

netstat를 이용한 TCP/IP 네트워크 관리

TCP/IP 소개

지금의 인터넷이 있게한 프로토콜이다. 이들에 대한 자세한 내용은 TCP/IP 미니사이트 문서를 읽어보기 바란다.

이 문서는 유닉스 환경에서 TCP/IP를 관리하기 위해서 중요하게 사용되는 툴들을 설명한다.

netstat

네트워크 연결상태를 알려준다. 이 프로그램을 통해서 알 수 있는 정보는 다음과 같다.

네트워크 연결 상태
유닉스 도메인 소켓 연결 상태
네트워크연결에 사용된 프로세스 - 리눅스 에서만 가능 -

netstat를 통해서 얻을 수 있는 가장 중요한 정보는 1번이 될 것이다. netstat를 사용하면 현재 네트워크에 연결이 되어있는 상태뿐만 아니라, TIME_WAIT와 SYN_RECV 상태까지도 얻어올 수 있다.

TIME_WAIT를 이해하기 위해서는 소켓의 종료 상태에 대해서 알고 있어야 한다. TIME_WAIT 상태는 소켓이 연결을 종료하는 과정에서 거치는 과정인데 마지막 ACK 신호를 보내지 못하는 경우가 있다. 이 경우 ACK를 재전송하기 위해서 기다리는데, 이를 TIME_WAIT 상태라고 한다.

이것은 2MSL(maximum segment life time)이라고 불리운다. 서버에서 데이터를 모두 다 보내면 연결을 닫기 위해서 close() 함수를 호출하게 된다. 그리고 서버는 ACK신호를 보내고 TIME_WAIT 상태에 들어간다. 클라이언트로 부터 ACK에 대한 응답이 있어야지만 연결이 완전히 종료가 된다. 만약 상대편 클라이언트가 ACK에 대한 응답을 보내지 않고 종료되어 버렸다면, 서버는 2MSL 시간만큼을 기다리게 된다.

TIME_WAIT는 하는 일은 없지만, 클라이언트로 부터의 종료메시지를 기다리는 상태가 되므로 다른 연결을 받아들이지 못하게 된다. 이는 TIME_WAIT 상태가 지나치게 많아지게 될 경우, 그만큼의 연결을 유지해야 하므로 서버프로그램에 문제가 생길 수 있다.

만약 다수의 SYN_RECV 가 있다면, DOS 공격을 의심할 수 있을 것이다. SYN_RECV는 클라이언트가 마지막 3번째 패킷을 서버에게 보내지 않음으로써, 불완전한 연결이 유지되게 된다. 반쪽자리 연결이라고 볼 수 있는데, 이러한 연결을 다수 생성해서 서비스가 거부되도록 공격하는 경우가 종종 발생한다.

# netstat -na : grep 80


tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN


tcp        0      0 218.234.19.87:80        122.152.181.156:11962   SYN_RECV


tcp        0      0 218.234.19.87:80        122.152.181.156:47119   SYN_RECV


tcp        0      0 218.234.19.87:80        122.152.181.156:3429    SYN_RECV


tcp        0      0 218.234.19.87:80        122.152.181.156:8208    SYN_RECV


tcp        0      0 218.234.19.87:80        122.152.181.156:59406   SYN_RECV


tcp        0      0 218.234.19.87:80        122.152.181.155:40277   SYN_RECV


tcp        0      0 218.234.19.87:80        122.152.181.155:35498   SYN_RECV


tcp        0      0 218.234.19.87:80        122.152.181.156:29028   SYN_RECV


tcp        0      0 218.234.19.87:80        122.152.181.156:55652   SYN_RECV


tcp        0      0 218.234.19.87:80        122.152.181.156:42340   SYN_RECV


tcp        0      0 218.234.19.87:80        122.152.181.156:16741   SYN_RECV


tcp        0      0 218.234.19.87:80        122.152.181.155:26965   SYN_RECV


tcp        0      0 218.234.19.87:80        122.152.181.156:33807   SYN_RECV


tcp        0      0 218.234.19.87:80        122.152.181.156:50873   SYN_RECV


tcp        0      0 218.234.19.87:80        122.152.181.156:38586   SYN_RECV


tcp        0      0 218.234.19.87:80        122.152.181.156:25274   SYN_RECV


tcp        0      0 218.234.19.87:80        122.152.181.155:48810   SYN_RECV


tcp        0      0 218.234.19.87:80        122.152.181.155:1366    SYN_RECV


tcp        0      0 218.234.19.87:80        122.152.181.155:9899    SYN_RECV


tcp        0      0 218.234.19.87:80        122.152.181.156:64185   SYN_RECV


tcp        0      0 218.234.19.87:80        122.152.181.155:18432   SYN_RECV


tcp        0      0 218.234.19.87:80        122.152.181.155:31744   SYN_RECV


tcp        0      0 218.234.19.87:80        122.152.181.156:20495   SYN_RECV


tcp        0      0 218.234.19.87:80        122.152.181.155:57343   SYN_RECV


tcp      567      0 218.234.19.87:36126     121.185.96.43:80        CLOSE_WAIT


tcp        0      0 218.234.19.87:22        222.119.23.60:2801      ESTABLISHED


tcp        0      0 218.234.19.87:37489     121.185.96.48:80        ESTABLISHED


tcp        0      0 218.234.19.87:80        222.231.42.193:34267    TIME_WAIT


tcp        0      0 218.234.19.87:80        66.249.73.50:63782      ESTABLISHED


tcp        0      0 218.234.19.87:80        210.116.196.225:39776   FIN_WAIT2


tcp        0      0 218.234.19.87:80        74.6.27.107:44671       TIME_WAIT


tcp        0  18981 218.234.19.87:80        141.85.90.195:2982      FIN_WAIT1

이 서버는 SYN_RECV 상태의 연결이 지나치게 많다. DOS공격이 의심되는 상황이다.

출처 : http://blog.naver.com/cosmo1492?Redirect=Log&logNo=120045042065