잊지 않겠습니다.

# netstat -atn
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address          Foreign Address       State
... 생략 ...
tcp        0      0 0.0.0.0:25             0.0.0.0:*             LISTEN      <-- 포트가 열렸음
tcp        0      0 192.168.123.10:32799   207.46.106.141:1863   ESTABLISHED <-- 서로 연결중
tcp        0      0 192.168.123.10:32794   218.xxx.xx.xx:22      ESTABLISHED
tcp        0      0 192.168.123.10:32802   207.46.108.46:1863    CLOSE_WAIT  <-- 종료 대기중
tcp        0      0 192.168.123.10:33244   211.xxx.xx.x:80       ESTABLISHED


1)  TCP 연결관련 상태

  • RFC 793문서에 나온 기본적인 TCP 연결 과정


      TCP A                                                      TCP B
  1.  CLOSED                                                     LISTEN
  2.  SYN-SENT    --> < SEQ=100>< CTL=SYN>                   --> SYN-RECEIVED
  3.  ESTABLISHED <-- < SEQ=300>< ACK=101>< CTL=SYN,ACK>     <-- SYN-RECEIVED
  4.  ESTABLISHED --> < SEQ=101>< ACK=301>< CTL=ACK>         --> ESTABLISHED
  5.  ESTABLISHED --> < SEQ=101>< ACK=301>< CTL=ACK>< DATA>  --> ESTABLISHED

LISTEN      : 데몬이 요청을 발을 수 있도록 연결 요구를 기다리는 상태
  즉, 포트가 열려있음을 의미. http(80), mail(25), ftp(21), telnet(23) 등
  위에서 포트 25(mail)이 메일을 받을 수 있도록 열려 있는 상태
  윈도우즈에서는 LISTENING으로 표시
SYN_SENT    : 로컬에서 원격으로 연결 요청(SYN 신호를 보냄)을 시도한 상태
SYN_RECV    : 원격으로 부터 연결 요청을 받은 상태
  요청을 받아 SYN+ACK 신호로 응답은 한 상태이지만 ACK는 받지 못했다.
  netstat로 확인할 때 SYN_RECV가 상당히 많다면 TCP SYN 플러딩(Flooding) 공격일
  가능성이 있다.
  윈도우즈와 솔라리스에서는 SYN_RECEIVED으로, FreeBSD는 SYN_RCVD으로 표시
ESTABLISHED : 서로 연결이 되어 있는 상태
  위에서 192.168.123.10의 포트 32794과 218.xxx.xx.xx의 포트 22(ssh)이 서로
  연결되어 있는 상태

2) TCP 종료관련 상태

* 정상적인 연결 종료 과정

      TCP A                                                   TCP B

  1.  ESTABLISHED                                             ESTABLISHED
  2.  (Close)
      FIN-WAIT-1  --> < SEQ=100>< ACK=300>< CTL=FIN,ACK>  --> CLOSE-WAIT
  3.  FIN-WAIT-2  <-- < SEQ=300>< ACK=101>< CTL=ACK>      <-- CLOSE-WAIT
  4.                                                         (Close)
      TIME-WAIT   <-- < SEQ=300>< ACK=101>< CTL=FIN,ACK>  <-- LAST-ACK
  5.  TIME-WAIT   --> < SEQ=101>< ACK=301>< CTL=ACK>      --> CLOSED
  6.  (2 MSL)
      CLOSED                                                      

FIN_WAIT1   : 소켓이 닫히고 연결이 종료되고 있는 상태. 원격의 응답은 받을 수 있다.
  솔라리스에서는 FIN_WAIT_1로 표시
FIN_WAIT2   : 로컬이 원격으로 부터 연결 종료 요구를 기다리는 상태
  솔라리스에서는 FIN_WAIT_2로 표시
CLOSE_WAIT  : 원격의 연결 요청을 받고 연결이 종료되기를 기다리는 상태
  원격으로 부터 FIN+ACK 신호를 받고 ACK 신호를 원격에 보냈다.
TIME_WAIT   : 연결은 종료되었으나 원격의 수신 보장을 위해 기다리고 있는 상태
  이 상태를 특히 자주 보게되는 Apache에서 KeepAlive를 OFF로 해둔 경우,
  Tomcat 서버를 쓰는 경우 등
LAST_ACK    : 연결은 종료되었고 승인을 기다리는 상태
CLOSED      : 완전히 연결이 종료된 상태


※ 위의 FIN_WAIT1, FIN_WAIT2, CLOSE_WAIT 3개 상태는 연결 종료를 위해 서로간에
   신호를 주고받는 과정에 나타나는 상태로 이해하면 된다.
   종료 요청을 한 곳에서는 FIN_WAIT1, FIN_WAIT2, TIME_WAIT 상태가
   종료 요청을 받는 곳에서는 CLOSE_WAIT, LAST_ACK 상태가 표시된다.

3) 기타

CLOSING     : 연결은 종료되었으나 전송도중 데이타가 분실된 상태
UNKNOWN     : 소켓의 상태를 알 수 없음

솔라리스의 netstat 명령에서는 다음 2개의 상태를 더 표시한다.

IDLE        : 소켓이 열렸지만 binding 되지 않은 상태
BOUND       : listen이나 연결을 위한 준비 상태

※ 참고 문서  
- netstat 맨페이지(linux, solaris)
- RFC 793 ( http://www.ietf.org/rfc/rfc0793.txt )

Posted by Y2K
,

System.Attribute

.NET Framework 2009. 1. 7. 11:22

 Attribute에 대한 내용을 사용할때마다 찾아서 적어주도록 한다. 특별하게 크게 사용한 내용들이 아직까지 많지 않은지..;; 은근슬쩍 아는 attribute가 별로 없다는 생각이 든다.

  • CSLCompliant : 어셈블리에 있는 모든 형식들이 CLS를 준수하게 된다.
  • DllImport : 일반 Dll들의 참고시에 사용된다. 이는 native os에 대한 참고로 사용된다.
  • StructLayout : 구조체의 내부 표현을 구성하는데 이용된다.
  • Dispid : Com 디스패치 인터페이스에 있는 맴버들에 대한 Dispid를 지정한다.
  • Serializable : 클래스나 구조체를 직렬화할 수 있다는 것을 나타낸다.
  • NonSerialized : 클래스나 구조체가 직렬화될 수 없다는 것을 나타낸다.
  • WebMethod : HTTP 요청을 통해 호출 될 수 있다는 것을 나타낸다.
  • SoapHeader : Soap Header가 있어야지 되는 WebService를 지칭한다. 
  • Obsolete : 사용하지 않을 class나 method에 지정한다.
Posted by Y2K
,

System.AppDomain

.NET Framework 2009. 1. 7. 11:21
각 응용프로그램들의 프로세스내의 논리적 patition.

    논리적인 분할로 인하여 내부 운영체제가 로드된 실행 프로그램을 나타내는 방법을 추상화한다.
    완전한 프로세스보다 처리에 필요한 메모리나 Clock이 저렴하다.   
    이는, 응용된 프로그램을 호스팅하는데 있어서 독립성을 강화한다.
    AppDomain은 모든 프로세스 및 다른 AppDomain에게 완전히 독립된 형태를 갖게 된다.
    따라서, 각기 고유한 AppDomain에서 실행되는 응용프로그램들은 .NET Remoting Protocol이외에는 데이터와 정보를 공유할수 없다.

.NET에서의 Process, AppDomain, Context와의 관계
    Process >> AppDomain >> Context로 나뉘게 된다.
    하나의 Process는 여러개의 AppDomain을 가질 수 있으며, AppDomain은 여러개의 Context를 가지는 것이 가능하다.
Posted by Y2K
,