AIX 소켓프로그램의이해및튜닝 - 데이터 전문가 지식포털 · 2008-04-21 · AIX 소켓프로그램의이해및튜닝 김기완차장([email protected]) Senior IT Specialist

MTS, IBM Global Technology Services Korea

© 2008 IBM Corporation

AIX 소켓 프로그램의 이해 및 튜닝

김기완 차장([email protected])Senior IT Specialist

The Best Reliable Partner for High Availability

**

April 8, 2008

2008 2008 상반기상반기 효과적인효과적인 시스템시스템 관리를관리를위한위한 기술기술 세미나세미나 -- COEX, Seoul, KoreaCOEX, Seoul, Korea

The Best Reliable Partner for High Availability – IBM S/W Maintenance Service


2 / 88

1. 소켓 개요

2. AIX의 소켓

3. 실제 소켓 프로그램의 예 및 분석 툴의 활용

Agenda



소켓 개요


**2008 2008 상반기상반기 효과적인효과적인 시스템시스템 관리를관리를위한위한 기술기술 세미나세미나 -- COEX, Seoul, KoreaCOEX, Seoul, Korea



4 / 88

프로세스 간 통신 (Interprocess communications)

하나의 프로세스 만으로는 업무 처리가 효율적이지 못하므로 여러 프로세스간에 효과적으로 data 및정보를 주고받기 위한 목적으로 다양한 프로세스 간 통신 방법이 고안/사용되었습니다.

IPC (interprocess communication)의 종류

– Pipe (Named Pipe)

– System V Semaphore

– Systme V message queues

– Posix message queues

– Remote procedure calls (RPCs)

– Mutexes and Conditional Variables

서로 다른 시스템에 있는 두 Process가 효과적으로 통신하기 위해서는?– 유저 Application들이 다양한 IPC를 원활하게 사용할 수 있도록 kernel이 효과적인 호스트간 데이터의 전달 방법을

정의하여야 합니다. 이를 통해서 유저는 손쉽게 다양한 형태의 IPC를 이용할 수 있습니다.

– 가장 대표적으로 이용되는 노드 간 통신 환경은 TCP/IP, SNA, Netware, NetBEUI 등 다양한 형태의 프로토콜에의해서 제공되며, 해당 Protocol마다 고유의 API를 제공합니다.

– TCP/IP가 제공하는 API는 Socket API이며, 이 Socket API를 통해서 User는 손쉽게 IPC를 위한 다양한 형태의통신 프로그램을 개발할 수 있습니다.

제1장 : 소켓 개요



5 / 88

Socket API

Berkeley Socket API (BSD Socket API)가 de facto standard라 할 수 있습니다.

Unix의 경우 BSD Socket API를 대부분 지원하고 있으며, 최근에는 Microsoft Windows 역시 Winsock API 뿐만 아니라 BSD Socket API를 지원하고 있습니다. (Windows XP부터)

TCP/IP Protocol Suite에 기반하여 작성되어 있으며, 따라서 TCP/IP Stack과 유기적으로결합되어 있습니다.

Socket은 하나의 S/W structure로서 peer node와 통신하기 위한 모든 정보 뿐만 아니라, 해당 운영체제의 커널에서 동작하기 위한 모든 정보들을 포함하고 있습니다.

유저 어플리케이션은 Socket API를 이용하여 function call의 형태로 통신을 요청하게 되며, 이를 Socket API가 system call의 형태로 변환하여 kernel의 서비스를 받도록 합니다.




6 / 88

Socket Layer의 Concept제1장 : 소켓 개요

application

Socket API

Socket system call

implementations

Socket layer

functions

kernel

user

Function call

System call

Function call



7 / 88

Socket structure제1장 : 소켓 개요

프로토콜, 소켓 타입

소켓 버퍼 정보

타이머 정보

소켓 옵션 정보

소켓 큐 정보

소켓의 현재 상태

Socket structure

소켓 구조체는 해당 소켓에 대한 모든 정보를 담고있습니다. 소켓의 타입에 대한 정보(Stream, datagram, …), 소켓의 버퍼 구조체에 대한 정보, 일부 timer 및 각종option 및 queue에 대한 정보 등을 가지고 있습니다.

이는 주로, 소켓이 만들어질 때 결정되는 여러파라미터들이며, 실제 통신 중의 동적인 값들은 실제 이소켓 구조체와 연결되어 있는 해당 protocol control block (PCB)에 저장되어 있습니다.

TCP 혹은 UDP를 사용한 peer 통신의 경우에는통신하는 상대방 또한 유사한 소켓 구조체를 가지고 있으며, 이 둘 간의 논리적인 연결을 Socket connection이라고합니다.

소켓 옵션은 다양한 방법으로 주어지며, 운영체제에서결정하기도 하고, 실제 프로그램을 작성할 때에 개발자의의도대로 삽입되기도 합니다.

소켓은 process가 socket descriptor에 대한pointer를 가지고 있을 경우에만 유효합니다.



8 / 88

소켓 타입제1장 : 소켓 개요

/usr/include/sys/socket.h

#define SOCK_STREAM 1 /* stream socket */

#define SOCK_DGRAM 2 /* datagram socket */

#define SOCK_RAW 3 /* raw-protocol interface */

#define SOCK_RDM 4 /* reliably-delivered message */

#define SOCK_SEQPACKET 5 /* sequenced packet stream */

#define SOCK_CONN_DGRAM 6 /* connection datagram */

소켓의 타입은 socket.h에 정의되어 있으며, 가장 많이 사용되는 것은 1, 2, 3번의 세 가지입니다. Stream 소켓은 TCP 소켓이고, datagram socket은 UDP, raw 소켓은 유저가 transport를 직접 작성하는 native 소켓이라고 생각하시면 됩니다. 이러한 소켓 타입은 소켓이 만들어질 때 결정되며, 따라서 사용하시려는프로토콜에 맞게 정의하셔야 합니다.



9 / 88

소켓 버퍼제1장 : 소켓 개요

socket

mbuf mbuf mbuf

mbuf mbuf mbuf

send

receive

peer

User Application

buffers

buffers

send

receive

I/O multiplexing



10 / 88

소켓 옵션제1장 : 소켓 개요


#define SO_DEBUG 0x0001 /* turn on debugging info recording */#define SO_ACCEPTCONN 0x0002 /* socket has had listen() */#define SO_REUSEADDR 0x0004 /* allow local address reuse */#define SO_KEEPALIVE 0x0008 /* keep connections alive */#define SO_DONTROUTE 0x0010 /* just use interface addresses */#define SO_BROADCAST 0x0020 /* permit sending of broadcast msgs */#define SO_USELOOPBACK 0x0040 /* bypass hardware when possible */#define SO_LINGER 0x0080 /* linger on close if data present */#define SO_OOBINLINE 0x0100 /* leave received OOB data in line */#define SO_REUSEPORT 0x0200 /* allow local address & port reuse */#define SO_USE_IFBUFS 0x0400 /* Interface will supply buffers */#define SO_CKSUMRECV 0x0800 /* defer checksum until receive */#define SO_NOREUSEADDR 0x1000 /* prevent local address reuse */#define SO_KERNACCEPT 0x2000 /* derive a in-kernel only socket */#define SO_NOMULTIPATH 0x4000 /* always use first matching route */#define SO_AUDIT 0x8000 /* turn on socket auditing */#define SO_SNDBUF 0x1001 /* send buffer size */#define SO_RCVBUF 0x1002 /* receive buffer size */#define SO_SNDLOWAT 0x1003 /* send low-water mark */#define SO_RCVLOWAT 0x1004 /* receive low-water mark */#define SO_SNDTIMEO 0x1005 /* send timeout */#define SO_RCVTIMEO 0x1006 /* receive timeout */#define SO_ERROR 0x1007 /* get error status and clear */#define SO_TYPE 0x1008 /* get socket type */#define SO_PEERID 0x1009 /* get peer socket's process id, thread id, euid and egid

(*) 소켓 옵션은 프로그램 작성시에 정의할 수 있으며, 운영체제의 파라미터 형태로도 넣을 수 있습니다. 하지만 항상 프로그램 작성시에정의된 값이 우선합니다.



11 / 88

소켓 functions제1장 : 소켓 개요


int accept();

int bind();

int connect();

int getpeername();

int getsockname();

int getsockopt();

int listen();

ssize_t recv();

ssize_t recvfrom();

ssize_t recvmsg();

ssize_t send();

ssize_t sendto();

ssize_t sendmsg();

int setsockopt();

int shutdown();

int socket();

int socketpair();

(*) 이러한 소켓 function들은 kernel 내부에서 다양한 형태의 system call 및 function call, ioctl call 등으로 이루어져 있습니다.



12 / 88

소켓 상태제1장 : 소켓 개요

/usr/include/netinet/tcp_fsm.h

#define TCP_NSTATES 11

#define TCPS_CLOSED 0 /* closed */

#define TCPS_LISTEN 1 /* listening for connection */

#define TCPS_SYN_SENT 2 /* active, have sent syn */

#define TCPS_SYN_RECEIVED 3 /* have send and received syn */

/* states < TCPS_ESTABLISHED are those where connections not established */

#define TCPS_ESTABLISHED 4 /* established */

#define TCPS_CLOSE_WAIT 5 /* rcvd fin, waiting for close */

/* states > TCPS_CLOSE_WAIT are those where user has closed */

#define TCPS_FIN_WAIT_1 6 /* have closed, sent fin */

#define TCPS_CLOSING 7 /* closed xchd FIN; await FIN ACK */

#define TCPS_LAST_ACK 8 /* had fin and close; await FIN ACK */

/* states > TCPS_CLOSE_WAIT && < TCPS_FIN_WAIT_2 await ACK of FIN */

#define TCPS_FIN_WAIT_2 9 /* have closed, fin is acked */

#define TCPS_TIME_WAIT 10 /* in 2*msl quiet wait after close */

(*) 모든 TCP socket은 현재의 상태를 가지고 있으며, 이는 tcp control block에 정보가 담겨 있습니다.



13 / 88

Socket Connection제1장 : 소켓 개요

In TCP (Connection oriented protocol)

socket socket

(*) TCP의 경우에는 데이터를 주고받기 전에 반드시 논리적인 connection을 연결하여야만 합니다. 이러한 논리적인 connection위에서flow control, congestion control 및 error handling이 이루어집니다. 마치 file I/O를 하는 것과 유사하게 byte offset이 항상존재하며, 그러한 byte offset을 활용하여 error handling을 하게 됩니다.

In UDP (Connectionless protocol)

socket socket

(*) 그렇지만 UDP의 경우에는 명시적인 논리적 연결이 없으며, 따라서 연결 절차 없이 바로 상대방에게 원하는 데이터를 전송할 수있습니다. TCP가 제공하는 여러 기능들을 따라서 제공하지 못하며, error handling은 해당 UDP application에서 해야 합니다. 운영체제가 해 줄 수 있는 부분은 checksum을 이용하여 수신된 패킷의 정합성만 확인하게 됩니다.



14 / 88

Socket Connection (2)제1장 : 소켓 개요


Listening socket

Client socket

Client socket

Client socket

Client socketConnection request

(*) TCP Connection이 만들어지기 위해서는 먼저 connection request를 받아들일 수 있는 Listening socket이 준비되어 있어야합니다. 흔히, 이렇게 listening하고 있는 socket이 있는 프로세스를 서버 프로세스라 하며, Connection request를 통하여connection을 요청하는 프로세스를 클라이언트 프로세스라고 합니다. 경우에 따라서, 이러한 서버와 클라이언트의 역할이 어플리케이션의형태와는 좀 다를 수도 있습니다.

(*) 단지 1개의 connection을 맺는 소켓 페어의 경우에도 반드시 하나의 socket은 해당 port에서 listening을 하고 있어야만 합니다. 물론, 양 쪽 모두 listening을 하고 있는 경우도 존재할 수 있습니다.



15 / 88

Data transfer제1장 : 소켓 개요


socket socketFull Duplex

(*) TCP의 경우, 논리적으로 연결된 connection을 통해 두 개 (send, receive)의 통신 채널이 준비되며, 따라서 full duplex 의 형태로통신이 이루어집니다. 데이터를 보내는 것과 받는 것이 동시에 이루어지며, 따라서 효과적인 통신을 위해서는 I/O multiplex를 할 수 있는방법으로 프로그래밍 되어야 합니다. (흔히 select() call을 사용)


socket socket

(*) udp의 경우는 논리적인 연결이 없으므로, 개별 send / receive가 각각 이루어지며, 어떠한 byte offset도 제공되지 않습니다. 따라서, 이러한 부분을 해당 user application에서 구현해 주어야만 합니다.

send / receive

receive / send



16 / 88

Socket Connection close제1장 : 소켓 개요


socket socketEOF

(*) 연결되어 있는 논리적인 connection을 끊습니다. 이는 끊기를 원하는 쪽에서 해당 socket descriptor를 close()함으로써 시작되며, 이 때 상대방 쪽으로는 EOF (end of file) 형태로 전달되게 됩니다. 끊는 과정은 full duplex로 통신하는 각각에 대해서 모두 이루어져야하며, 흔히 4-step으로 이루어집니다.


socket socket

(*) 그렇지만 UDP의 경우에는 명시적인 논리적 연결이 없으므로, 각자 자신의 socket을 close할 수 있습니다. close할때 어떠한 경우도상대방에게 통보되지 않으며, 따라서 이러한 부분의 동기화도 application에서 책임져야 합니다.

close close

close close



17 / 88

Summary

Socket API

Socket structure

Connection oriented vs. Connectionless socket

Connection setup

Data transfer

Connection close

Protocol control block




AIX의 소켓





19 / 88

Socket API in AIX

BSD Socket API

AIX는 여러 socket option 및 네트웍 파라미터를 network option의 형태로 수정할수 있게 되어 있습니다.

현재 사용되고 있는 여러 socket option들을 netstat command로 쉽게 확인할 수있도록 되어 있습니다. (AIX V5.3부터)

일부 socket option의 경우 ifconfig command나 smitty를 통해서 interface 당설정할 수 있으며, 이를 interface specific network option (isno)라고 합니다.

System default로 설정되어 있는 많은 파라미터는 default대로 사용되어도 큰 무리가없도록 정해져 있습니다. 이를 고칠 경우에는 해당 network option 뿐만 아니라, 여러다른 효과를 고려하여 신중하게 결정하여야 합니다.

제2장 : AIX의 소켓



20 / 88

Network Option command in AIX제2장 : AIX의 socket

AIX는 시스템 파라미터를 여러 그룹으로 묶어서 관리합니다. Scheduler와 관계되는 파라미터는schedo command로, virtual memory 관련 파라미터는 vmo, I/O 관련 파라미터는 ioo, nfs 관련파라미터는 nfso를 사용합니다. Network의 경우에는 no (network option) command를 사용하며, no –a command로 모든 파라미터의 현재 값을 알 수 있습니다.

no의 여러 파라미터들은 조금씩 다른 속성을 가지고 있습니다. Dynamic하게 반영이 되는 파라미터, Connection base로 반영이 되는 파라미터, 그리고 System rebooting이 반드시 필요한 파라미터등이 있습니다. 이러한 type은 no –L command를 통하여 볼 수 있습니다.

변경할 때는 파라미터의 속성에 따라 “no –po <option=value>” 혹은 “no –ro <option=value>”등의 command를 사용할 수 있습니다. 경우에 따라서는 서로 dependency가 있는 경우가 있으므로주의하여야 합니다.

이번 세션에서 총 135개의 no parameter 중 (5.3 TL05기준) 37개의 no parameter가언급됩니다.

man no를 통해서 대부분 파라미터의 의미를 파악할 수 있습니다.



21 / 88

Timer in AIX kernel (for TCP/IP stack)제2장 : AIX의 소켓

2 types of timer (fast timer, slow timer)

boot time

boot time

(*) fast timeout : kernel이 동작하기 시작하면, 매 200ms (default)마다 fast_timo event가 발생하며, 이 event가 발생할 때 마다, 모든 inpcb를 돌며, 적용되는 event가 있다면 처리합니다. (delayed ack, nagle’s algorithm…). 이 값은 no parameter로 조절할수 있으며, 값의 범위는 50-200ms입니다. Dynamic하게 변경이 가능합니다. 변경하게 되면, 해당 event의 수가 늘어날 수 있으므로, CPU 사용율이 올라갈 수 있는 대신, interactive한 connection에서 delay를 줄일 수 있습니다.

(*) slow timeout : kernel이 동작하기 시작하면, 매 500ms마다 slow_timo event가 발생하며, 이 event가 발생할 때마다 모든inpcb를 돌며 해당 timeout 값들에 대한 처리를 하게 됩니다. (keepalive, persistent, retransmission, …) 변경은 불가능하지만, retransmission과 같은 경우는 AIX V5.3 TL05부터 새로운 timer를 도입함으로써 변경이 가능해졌습니다. no parameter 중, timer와 관계되는 paramter들의 값이 대부분 half second인 것은, 이러한 timer를 사용하기 때문입니다.

Ex) no –po fasttimo=50



22 / 88

Network Memory제2장 : AIX의 socket

AIX의 network memory의 크기는 thewall network option paramter로 결정됩니다. AIX 4.3.3까지는 이 값을 유저가 직접modify하는 것이 가능하였지만, AIX 5L로 오면서부터 system이 동적으로 결정하도록 바뀌었습니다. 하지만 여전히 no parameter로존재하며 이를 확인하는 것은 가능합니다.

For 64bit AIX kernel : min ( system memory/2 , 64GB)For 32bit AIX kernel : min ( system memory/2 , 1GB)

sockthresh no paramter : 네트웍 메모리의 사용량이 이 비율을 넘어서게 되면, 더 이상 socket request가 처리되지 않습니다. 기존에 사용중인 소켓들은 영향을 받지 않지만, 새로운 connection을 만드는 일은 더 이상 허용되지 않습니다. Default 값은85(%)입니다.

strthresh no parameter : 네트웍 메모리의 사용량이 이 비율을 넘어서게 되면, 오직 root user만이 stream을 새로 만들 수있습니다. Default 값은 85(%)입니다.

네트웍 메모리의 현재 사용량은 netstat –m이나 kdb를 통하여 (kmbucket –s)를 통하여 모니터링할 수 있습니다. 최근에는 대부분의시스템에서 5% 미만만을 사용하며, sockthresh나 strthresh에 도달하는 경우는 극히 드뭅니다. 이러한 경우 대부분 memory leak이있는 경우이며, 해당 memory leak을 찾아서 디버깅하여야 합니다.

network memory의 경우는 net_malloc을 통하여 얻어지므로, 문제 분석을 위해서는 net_malloc_police를 지정하고 (buffer의크기, net_buf_size와 net_buf_type도 변경될 수 있음) extendednetstats을 enable하여야 합니다. 이는 rebooting이필요하며, 당연히 overhead를 수반합니다.



23 / 88

Network Memory (2)제2장 : AIX의 socket

(0)> kmbucket -s

netkmem @ .................3129F000

current_heap...............00000000 heaps_in_use...............00000001

thewall....................00040000 kmemfreelater..............00000000

wantkmemmap................00000000 kmemtid........... ........00000913

threadtime.................2FF20358 kmempages..................00010000

kmemreserve................00000000 kmemgcintvl................00000002

kmemgcscale................00000040 kmeminuse..................0027AD80allocated..................013C1000 net_malloc_police..........00000000

bucket.......... @.........3129F138 kbtail.......... @.........312ABAD4

largebucket..... @ ........312AB738 largekbtail..... @.........312ACCD4

alloc_lock...... @.........312ACD28 sock_thresh_size...........0D999800kmemstats....... @.........312ACD30 dr_token...................00000002

dr_rmcpucnt................00000000 dr_cpulist...... @.........312AD588

dr_lock......... @.........312AD688 inet_dr_cpu_remove.........312AD578



24 / 88

TCP Segments제2장 : AIX의 socket

User dataTCP HeaderIP HeaderEthernet Header

< Maximum Segment Size

> 20bytes20bytes18bytes ~

< Maximum Transfer Unit

MTU는 해당 link의 속성에 의해서 결정되며, routing table에 정의하거나 path MTU discovery를 통하여 동적으로 변경 할 수도있습니다. 일반적으로는 1,500바이트가 사용되며, jumbo frame을 사용할 경우 9,000byte이상의 frame도 사용 가능합니다.

Ethernet header는 type (DIX, IEEE 802.3)에 따라서, 혹은 VLAN tagging에 의해서 크기가 다양하게 결정됩니다.

MSS size는 통신하는 상대방 간에 서로 알려주게 되어 있으며, Local LAN상의 통신인지, remote와의 통신인지에 따라서 로직이달라집니다. local LAN상일 경우는 흔히 MTU-(40byte+TCP option의 길이) 로 결정되며, remote상일 경우에는 tcp_mssdflt no paramter (tcp_mssdflt – TCP option의 길이) 에 의하여 결정됩니다. (시스템 no 혹은 isno)

TCP option의 길이는 일반적으로 rfc1323과 sack의 사용 여부에 의해서 달라지게 됩니다. rfc1323이 사용되면, 모든 TCP segment의 TCP option에 12byte의 timestamp가 찍히므로, MSS가 12바이트 더 작아지게 됩니다.



25 / 88

TCP Header format제2장 : AIX의 socket

FIN

RST

ACK

User Data

TCP Options (timestamp, sack)

16-bit urgent pointer16-bit TCP checksum

16-bit window sizeSYN

PSH

URG

Reserved (6bits)4-bit header length

32-bit acknowledgement number

32-bit sequence number

16-bit destination port number16-bit source port number



26 / 88

UDP Header format제2장 : AIX의 socket

User Data

16-bit UDP checksum16-bit UDP length

16-bit destination port number16-bit source port number

UDP Checksum은 경우에 따라 사용하지 않을 수도 있으며 (optional) 이를 network option 중 udpcksum을 0으로 변경하여사용하지 않을 수 있습니다. (default는 1이며, 사용하도록 되어 있습니다.) 변경하면 더 이상 checksum 을 계산하지 않으므로 CPU cycle을 아낄 수 있지만, 데이터의 정합성은 보장되지 않습니다. 대부분의 경우 해당 UDP application이 해당 data의 정합성 여부를결정하므로, 이 option을 끄더라도 큰 영향은 없는 경우가 많습니다.



27 / 88

TCP Connection – Prepare server (listen) socket제2장 : AIX의 socket

User Application User Applicationsocket() call

File Descriptor

Socket structure

Inpcb structure

tcpcb

inpcb chain

(can be reused)

int socket ( int domain, int type, int protocol);

domain : AF_UNIX, AF_INET, …

type : SOCK_DGRAM, SOCK_STREAM, …

protocol : IPPROTO_TCP, IPPROTO_SCTP …



28 / 88

TCP Connection – Prepare server (listen) socket (2)제2장 : AIX의 socket

bind step

int bind (sockfd, name, namelength)

bind는 만들어진 socket을 특정 ip address와 port number와 연결시키는 과정입니다.

흔히 ip address로 INADDR_ANY가 사용되는데, 이는 시스템에 정의된 모든 ip address와 연결시키게 됩니다. 즉 해당 소켓을이용해서 통신할 때, 시스템의 어느 ip address를 사용하여도 된다는 의미이며, 주로 서버 소켓이 이러한 방식으로 bind됩니다.

서버가 사용하는 port number는 65535까지 아직 할당되지 않은 숫자로 사용할 수 있습니다. 이미 사용중인 port로 다시 bind를 하게되면, bind() function은 -1을 return하며, EADDRINUSE를 errno으로 setting하게 됩니다.

대부분의 경우 client는 bind과정을 거치지 않으며, AIX kernel 내에서 결정된 ip address와 port number로 (ephemeral port) 결정됩니다. 하지만, 원하는 경우 client의 소켓도 특정 ip address와 port number로 bind할 수 있습니다.

socket socketbind() call

Ip address & port #



29 / 88

TCP Connection – Prepare server (listen) socket (3)제2장 : AIX의 socket

listen step

int listen (sockfd, backlog)

listen() call을 통하여, 해당 socket은 client로부터의 connection request를 받을 수 있게 됩니다.

두 번째 parameter로 넘어가는 backlog값은 해당 Listening socket의 listen queue size가 됩니다. 이는 network option 중somaxconn 과 밀접한 관계가 있으며, 실제 queue size는 min ( somaxconn, backlog)으로 결정됩니다.

somaxconn의 default값은 1,024입니다.

Web server와 같이 다양하고 많은 client connection request를 받는 서버 프로그램은 이 backlog 사이즈를 늘려 줄 필요가 있을수 있습니다. 이 경우에는 application에서 주어진 backlog값과 somaxconn no parameter에서 주어진 값을 모두 적절히 이용하여설정하여야 합니다.

socket socket

listen() callIp address & port #Ip address & port #

listen queue



30 / 88

TCP Connection – Prepare client socket제2장 : AIX의 socket

User Application User Applicationsocket() call

File Descriptor

Socket structure

Inpcb structure

tcpcb

inpcb chain

(can be reused)

int socket ( int domain, int type, int protocol);

domain : AF_UNIX, AF_INET, …

type : SOCK_DGRAM, SOCK_STREAM, …

protocol : IPPROTO_TCP, IPPROTO_SCTP …



31 / 88

TCP Connection – Connection request제2장 : AIX의 socket

connect step

int connect (sockfd, name, namelength)

connect() call을 통하여 client socket은 server socket으로 connection을 요청하게 됩니다.

이 때, 만일 client socket이 bind되어 있지 않다면, kernel에서 implicit bind를 수행하게 됩니다. 실제 서버로의 routing 경로에 따라해당 interface가 정해지면, 해당 interface에 있는 ip address 중 primary ip address를 사용하게 되고, port number는ephemeral port 중 사용되지 않는 한 개의 port number가 사용됩니다. (ephemeral port의 range는 tcp_ephemeral_high 와tcp_ephemeral_low 두 개의 no paramter로 결정되며, default값은 각각 65,535 및 32,768입니다.)

일반적으로 해당 interface의 primary address는 처음 interface가 정의될 때 들어간 ip address로 정해집니다. (alias의 경우 첫번째 alias)

client socket server socket

connect() callIp address & port #Ip address & port #

listen queue

implicit bind



32 / 88

TCP Connection – implicit bind제2장 : AIX의 socket

ClientGateway

9.9.9.1

Server

9.9.10.9

9.9.10/24 9.9.9.1 UG 0 0 en0

en0에 있는 ip address : 211.21.33.21 9.9.9.9, 9.9.9.10 (ifconfig에서 나오는 순서대로)

9.9.9.9가 source ip address로 선택

서버의 ip address (즉, 목적지 ip address) 에 의하여 routing entry가 선택되면, 해당 routing entry에 있는 interface를 통하여데이터가 전송되므로, 해당 interface에 있는 ip address중 1개가 선택됩니다.

이 때, 사용되는 ip address는 해당 gateway와 같은 subnet에 있어야 하고, 그 중 primary로 선택되어 있는 ip address가 source ip address로 결정됩니다. 이 primary ip address는 routing table에 변경이 있을 때 달라질 수 있습니다.

이러한 implicit bind를 피하고, 원하는 ip address를 source로 사용하기 위해서는 client socket에서도 bind를 해 주시면 됩니다.



33 / 88

TCP Connection – 3 way handshaking제2장 : AIX의 socket

Performed by kernel

client serverSYN

SYN/ACK

ACK

SYN_SENT

SYN_RCVD

ESTABLISHED ESTABLISHED

위와 같이 3-way handshaking이 끝나게 되면, 양 쪽의 socket status는 ESTABLISHED상태가 되어 통신이 가능한 상태가됩니다.

SYN, ACK는 각각 TCP header의 해당 flag가 setting되어 있다는 의미입니다.

위의 과정은 모두 kernel에서 이루어지며 user program이 관련되는 부분은 없습니다.

이러한 일련의 과정은 모두 client에서 connect() call을 함으로써 시작됩니다.

connect()



34 / 88

TCP Connection – 3 way handshaking (2)제2장 : AIX의 socket

Server not responding

client Server

Not exist or

shutdowned

SYN

SYN_SENT

만일 SYN packet에 서버가 자신의 SYN/ACK로 응답하지 않으면, client는 정해진 시간 동안 대략 6회 정도 SYN packet을재전송합니다.

이러한 SYN의 재전송은 tcp_keepinit no parameter로 조절할 수 있으며 default값은 150입니다. (75초).

만일 이 시간 안에 server로부터의 응답이 없으면, connect() call은 -1을 return하며, ETIMEDOUT errno이 setting됩니다. (blocked connect의 경우)

일반적으로 해당 application은 “Server not responding” 메시지를 보여 줍니다.

SYN

SYN

SYN

…



35 / 88


No listening port

client No listenerSYN

Client가 SYN 패킷을 통하여 connect를 시도하였으나, 서버에 해당 서버 listening port가 존재하지 않는 경우에는 서버로부터 바로RST flag가 setting되어 있는 RST 패킷이 돌아옵니다.

이 경우 client의 connect call은 바로 -1로 return되며 ECONNRESET이 errno으로 세팅됩니다.

대개 “Connection reset by peer” 메시지를 보여 주게 됩니다.

RST



36 / 88


What if server’s listen queue is full?

client serverSYN

Queue full

TCP server 쪽의 Listen queue에 여분의 공간이 없을 경우가 있습니다. 이러한 경우 당연히 3-way handshaking이 정상적으로이루어지지 않습니다.



37 / 88

TCP Connection – Listen queue제2장 : AIX의 socket

listen queue

Connection completion queue Connection incompletion queue

* netstat –ano output

qlen q0len qlimit

client의 connection request에 대한 내용은 listen queue에 queuing됩니다. (서버 프로세스가 accept()해가기 전까지)

이 때 queueing할 수 있는 maximum은 AIX의 경우 qlimit의 1.5배 입니다.

즉, qlen과 q0len을 합한 값이 qlimit의 1.5배가 되면, 더 이상의 connection request는 처리되지 못하고 마치 서버가 존재하지 않는것과 같은 시나리오로 진행이 됩니다.

RST 패킷을 보내지 않는 이유는 client program이 에러를 만나지 않고 다시 SYN를 재전송 하였을 때, 시간이 흐른 뒤에는 listen queue full상황이 풀려 정상적으로 connection 연결이 될 수도 있기 때문입니다.



38 / 88


q0len full (connection incompletion queue full)

client serverSYN

Attack

Queue full

만일 서버의 q0len이 늘면서 listen queue가 full이 난 경우라면, SYN flood attack (Service Denail of Service attack) 의개연성이 있습니다. 즉, client에서 악의적으로 많은 수의 SYN packet을 날리고 서버의 SYN/ACK을 무시함으로써 서버의 q0len을 다채워서 qlimit의 1.5배까지 다 사용하는 경우입니다.

이러한 경우는 서버에서 netstat –an으로도 쉽게 모니터링이 가능하며 (다수의 SYN_RCVD socket들이 존재) 보다 명확하게netstat –ano를 통해 해당 listening socket의 q0len 및 qlimit를 monitoring함으로써 확인할 수 있습니다.

이러한 경우 clean_partial_conns no parameter를 1로 변경하여, 주기적으로 q0len의 entry를 비워 줌으로써 정상적인client로부터 오는 request를 받을 수 있는 빈 공간을 만들 수 있습니다.

또한 qlimit이 너무 작은 경우에도 문제가 될 수 있으므로, user program에서 backlog을 늘려 주고, 필요한 경우 somaxconn no parameter를 늘려 줘야 할 수도 있습니다.

SYN/ACK



39 / 88


qlen full (connection completion queue full)

client serverSYN

Queue full

qlen full

만일 서버의 qlen이 늘면서 queue full이 된 경우는 connection setup이 완료된 connection을 해당 Application이 accept해 가지못하는 것이 문제이므로, 해당 application이 왜 그런 상황에 있는지를 점검하여야 합니다.

Web server의 경우 worker thread의 개수가 충분한지, 현재 모든 worker thread가 사용되고 있는지를 점검하여야 하고, 실제들어오는 connection request의 숫자가 너무 많아서 그런 경우가 발생한다면, somaxconn과 backlog parameter를 각각 AIX와해당 application server에서 늘려 주셔야 합니다.

SYN (retransmission)

SYN/ACK

ACK



40 / 88


monitoring

listener full로 인하여 Connection request가 무시되었을 경우, netstat –s output의 tcp section에 해당 counter가 증가합니다. 이를 모니터링함으로써 listener queue full event가 발생하였는지를 쉽게 모니터링 할 수 있습니다. 먼저 netstat –sZ를 통하여counter를 reset한 후에 해당 counter가 증가하는지를 확인하시면 됩니다..

또한 이러한 경우, netstat –an | grep SYN 등을 통하여 서버에 SYN_RCVD가 많은 수로 남아있는지를 체크해 볼 수 있습니다. (q0len full의 경우).

만일 qlen이 full이 나는 경우라면, 해당 application (ex. Web server)이 이미 connection setup이 완료된 connection을가져가지 못하는 것이 문제이므로, 해당 application측면에서 접근하여야 합니다.

listen queue를 늘릴 때에는 반드시 somaxconn parameter를 충분히 늘려 주시고, 해당 application의 backlog 설정을증가하시고 다시 시작하셔야만 합니다.

# netstat -s | grep listen

0 discarded by listeners

0 discarded due to listener's queue full



41 / 88

TCP Connection – accept (1)제2장 : AIX의 socket

connection accept

Listener는 주기적으로 Connection completion queue를 polling하여 connection setup이 완료된 connection을accept합니다. 이렇게 새로 accept된 connection에 사용되는 소켓은 이전의 listening 소켓과는 다른 소켓입니다.

Listener process가 connection completion queue가 차는 속도보다 더 느리게 되면, 앞에서 살펴보았던 대로 qlen이증가하면서 qlimit에 도달할 수 있습니다. 이 경우 적절한 tuning (backlog, somaxconn, application program)이 필요합니다.

accept한 소켓을 처리하는 방식은 여러 가지가 있습니다.

1. Listener process (thread) 가 직접 처리하는 방법 – 이 경우 한 번에 하나의 request만 처리됩니다.

2. 새로운 process를 fork하여 처리하는 방법 – 여러 request가 처리될 수 있으나 process를 fork하는 overhead가있습니다.

3. 새로운 thread를 생성하거나, 미리 존재하는 thread에게 해당 socket descriptor를 넘겨 처리하는 방법 – 가장 효율적인방법

int accept (sockfd, name, namelength)



42 / 88


Listener process (thread)가 직접 처리

Listener socket

Connection

Completion

queue

accepted socket

Processing

requests

코드 수행을 마친 후 다시accept() 수행

이러한 경우, 한 번에 한 개의 request만 처리됩니다.

accept()

Main process



43 / 88


새로운 process를 fork()

이러한 경우, connection마다 한 개의 process가 fork되어 해당 request를 처리합니다.

경우에 따라 미리 만들어진 process에 socket descriptor만 passing하여 request를 처리하게 할 수 있습니다.

Listening socket

Connection

Completion

queue

Accepted socket Listening socket

Connection

Completion

queue

Accepted socket

fork()

Listener process Worker process



44 / 88


새로운 thread에서 처리

이러한 경우, connection은 listener thread와 다른 별도의 worker thread에서 처리됩니다. 이 때 두 thread는 같은 process에있을 수도 있고, 서로 다른 thread에 있을 수도 있습니다.

경우에 따라 미리 만들어진 thread에 socket descriptor만 passing하여 request를 처리하게 할 수 있습니다.

Listening socket

Connection

Completion

queue

Accepted socket Accepted socket

Socket descriptor passing

Listener thread Worker thread

Processing



45 / 88

TCP Connection – Socket buffer제2장 : AIX의 socket

Application

buffer

buffer

socket

send

receive

socket

receive

send

Application

buffer

buffer

send()

send()receive()

receive()

Host “A” Host “B”



46 / 88

TCP Connection – Socket buffer (2) - sender제2장 : AIX의 socket

Application

buffer

socket

buffer

32KB data

by send() call

get EAGAIN if buffer is full

MSS Chunks

만일 large_send가 enable되어 있으면, Ethernet adapter가 MSS size로data를 쪼개게 되고, kernel은 그대로32KB의 data를 전송합니다.

AIX kernel

#netstat –an

tcp4 0 2 9.187.227.211.23 9.127.254.76.49658 ESTABLISHED



47 / 88

TCP Connection – Socket buffer (3) – send/receive제2장 : AIX의 socket

Send buffer Receive bufferCongestion Control

Flow Control

Error Recovery

Congestion control : 네트웍 상의 congestion을 감지하여, sender가 전송하는 속도를 조절합니다.

Flow Control : 받는 쪽의 receive buffer의 상태에 따라 흐름 제어를 합니다. (TCP header의 window size 필드 사용)

Error Recovery : 패킷이 유실되거나, 순서가 바뀌는 등 여러 가지 event들에 대한 Error Recovery과정이 포함됩니다.

TCP는 전송하는 데이터의 모든 byte에 sequence number를 부여하여 이 sequence number를 가지고, 여러 가지 다양한 흐름제어 방식을 사용합니다.

TCP에는 negative ack는 사용하지 않으며, 오직 positive ack만 사용됩니다.



48 / 88

TCP Connection – Socket buffer (4) – receiver제2장 : AIX의 socket

Application

buffer

socket

buffer

received

data

MSS Chunks

interruptsI/O multiplexed by select()

Inform free buffer size to sender through ACK

packet

#netstat –an

tcp4 0 2 9.187.227.211.23 9.127.254.76.49658 ESTABLISHED



49 / 88

TCP Connection – Socket buffer (5) – Flow Control제2장 : AIX의 socket

Socket send buffer Socket receive buffer

Free window = 2

Send 2 chunks

Free window = 0

“zero window” situation

모든 TCP packet에는 free window size가 포함되어 있습니다. 보내는 쪽에서는 상대방의 receive buffer에 남아있는 free window size보다 더 많은 data를 보낼 수 없으며, 만일 이러한 receive window size가 0이 되면, 더 이상 전송할 수 없게 됩니다. 이때에는 persist timer가 동작하여, 주기적으로 상대방의 receive window가 다시 사용할 수 있는 공간을 가지고 있는지 check하게됩니다.



50 / 88

TCP Connection – Socket buffer (6) – sizing제2장 : AIX의 socket

Send buffer Receive buffer

data

ACK

bandwidth를 효과적으로 사용하기 위해서, 보내는 data와 앞에서 보낸 data에 대한 ACK가 wire에 최대한 차도록 receive socket buffer size를 결정하는 것이 필요합니다.

이러한 경우 흔히 bandwidth delay product라는 방법이 사용되며, 이는 해당 line의 bandwidth와 delay시간을 곱한 만큼 해당소켓의 receive window size를 정하는 것을 의미합니다. 즉, 1Mbps의 링크를 사용하고, 해당 link의 latency (round trip time)이100ms라고 했을 때, 소켓의 receive buffer size는 1Mbps * 0.1s = 100Kbit = 12.5KBytes가 됩니다. 이는 receiver 소켓의 응답없이 보내는 쪽에서 한 번에 12.5KByte를 보내면, 해당 link를 최대한 활용한다는 의미가 됩니다.

이러한 방법은 주로 latency가 큰 link의 경우에 잘 적용되며, LAN환경에서는 적용되지 않습니다.



51 / 88

TCP Connection – Socket buffer (7) – sizing제2장 : AIX의 socket

LAN 환경에서는 일반적으로 adapter의 bandwidth 처리 능력에 따라 socket buffer size를 결정하게 됩니다.

AIX에서는 adapter 및 jumbo frame 사용 여부에 따라 default 값을 결정하게 되며, 이는 주로 isno (interface specific network option)으로 정의되어 ifconfig –a 혹은 lsattr –El enx command를 통하여 확인할 수 있습니다. Isno값은 no parameter 중use_isno 가 1 (default value)로 설정되어 있는 경우에 항상 no 값보다 우선합니다.

rfc1323은 64K보다 큰 receive buffer size를 적용하려 할 때에는 반드시 설정되어야 합니다. (network option paramter) TCP header의 window size field가 16bit이므로, maximum 65535까지만 사용하게 되는데, 이를 scale factor를 이용하여 더 큰 값을사용할 수 있도록 하는 것이 rfc1323입니다. 이러한 scale factor는 TCP connection을 맺을 때 option으로 서로 주고 받습니다.

tcp_sendspace, tcp_recvspace no parameter를 통하여 설정할 수 있으며, isno, socket option으로도 설정이 가능합니다.

sb_max 이상은 정의할 수 없으므로 default sb_max 값(1Mbyte)이 너무 작은 경우 적당히 늘려 주셔야 합니다.

1131,072262,1441Gbps

1> 262,144> 262,14410Gbps

065,535131,072100Mbps

rfc1323tcp_recvspacetcp_sendspace



52 / 88

TCP Offload function제2장 : AIX의 socket

AIX의 TCP/IP는 해당 ethernet adapter의 지원 여부에 따라 두 가지의 offload function을 사용합니다.

TCP segmentation offload (large_send) : MSS 단위로 나누는 일을 AIX kernel에서 하지 않고 Ethernet adapter에서 하도록 offload하는 기능입니다. Ethernet adapter에 따라 지원될 수도, 되지 않을 수도 있습니다. Default 값은adapter에 따라 다르며, entx의 속성입니다.

TCP checksum offload (checksum_offload) : TCP header의 checksum 기능을 Ethernet adapter로offload합니다. Checksum offload를 사용하면 tcpdump, iptrace상에서의 checksum값은 0으로 보이게 됩니다.

large_send를 사용하면서 패킷 유실이 많은 경우, recovery할 때 성능이 크게 떨어질 수 있습니다. AIX는 그러한 경우 임시적으로large_send를 끄고 보낼 수 있는 기능이 있지만, 가급적 이러한 경우에는 large_send를 disable하고 패킷 유실에 대한 원인을 파악하여조치한 후 다시 large_send 기능을 enable하는 것이 좋습니다.



53 / 88

TCP Connection – data flow제2장 : AIX의 socket

HOST A HOST BSeq:2, ACK:1, size:5

Seq:1, ACK:7, size:0


Seq:1467, ACK:1, size:1460


Seq:2927, ACK:201, size:800


…



54 / 88

TCP Connection – fast retransmission제2장 : AIX의 socket

HOST A HOST B


Seq:1462, ACK:1, size:1460

Seq:2922, ACK:1, size:1460

Seq:4382, ACK:1, size:1460



Seq:1, ACK:2, size:0Seq:5842, ACK:1, size:1460


missing


Duplicate ACKs

retransmission



55 / 88

TCP Connection – fast retransmission (2)제2장 : AIX의 socket

Bulk data가 전송되는 경우에, 보내는 쪽에서는 상대방의 응답 여부에 상관없이 자기가 보낼 수 있는 만큼 데이터를 일괄 전송하게됩니다. 물론, 상대방의 receive buffer의 상태나, 네트웍의 상태에 따라 응답 없이 보낼 수 있는 데이터의 양은 달라질 수 있습니다.

이 때 패킷이 유실되면, 받는 쪽에서는 그러한 패킷에 대해서 자신이 기대하는 byte에 대해서 duplicate ACK로 응답하게 됩니다. TCP는 negative feedback을 주지 않으므로, 이러한 Duplicate ACK이 패킷 유실의 유일한 증거가 됩니다.

이러한 Duplicate ACK가 정해진 회수 이상이 되면, AIX는 패킷이 유실되었다고 판단하고, Duplicate ACK시 받은 acknowledge number부터 packet을 재전송 하게 됩니다.

Duplicate ACK의 한도는 tcprexmtthresh no paramter를 통해서 설정되며, default값은 3입니다. (이전 버전의 AIX에서는3으로 hard-coding되어 있을 수 있습니다.)

tcp_newreno no parameter를 통해서 fast recovery를 보다 효율적으로 할 수 있습니다. 이 paramter는 보내는 쪽의 설정만으로성능 향상이 이루어지며 default로 사용하도록 되어 있습니다.

sack no paramter를 통해서 이러한 fast recovery를 효율적으로 할 수 있습니다. Selective ack는 TCP connection setup시에사용 여부를 negotiation하게 되며, 양자가 모두 합의해야 사용할 수 있습니다. AIX는 4.3.3이상부터 sack을 사용할 수 있도록 하였으며, default는 사용하지 않는 것으로 되어 있습니다.

sack을 사용할 때 일부 방화벽이 문제를 야기할 수 있습니다. Connection hijacking을 막기 위하여 일부 방화벽이 sequence number를 modify하는데, 이 상황에서 sack field를 올바르게 바꾸어 주지 않으면, fast recovery 과정에서 TCP connection이stuck/reset되는 것이 가능합니다. 따라서 sack의 사용은 주변 환경을 신중히 파악하고 사용을 결정하여야 합니다.



56 / 88

TCP Connection – retransmit timeout제2장 : AIX의 socket

HOST A HOST B




missing



Retransmit timeout

retransmit



57 / 88

TCP Connection – retransmit timeout (2)제2장 : AIX의 socket

소량의 데이터를 interactive하게 주고받는 TCP connection의 경우에는 duplicate ACK가 발생하지 않을 수 있습니다. 앞에서설명되었듯이 TCP는 negative feedback을 주지 않으므로, 이러한 경우에는 보내는 쪽에서 timer를 작동시켜서 주어진 시간 안에ACK를 받지 못하게 되면, 유실된 패킷을 재전송 하게 됩니다.

이 때 재전송된 패킷 역시 응답이 없으면, TCP는 대기 시간을 늘려서 다시 재전송을 하게 됩니다. 만일 정해진 회수만큼 재전송이이루어졌음에도 ACK가 오지 않으면, 보내는 쪽에서는 RST 패킷을 보내 connection을 강제로 종료합니다.

다음의 parameter를 통해서 이러한 retransmit timeout의 동작을 제어합니다.

rto_low : 최초 retransmission timeout (default :1, 짝수로 설정)

rto_high : maximum retransmission timeout (default : 64)

rto_length : retransmit의 회수 (default : 13)

rto_limit : rto_low에서 rto_high까지 이르는 데 걸리는 회수 (default 7)

위와 같은 설정을 사용하였을 경우 최초 1-1.5초 사이에 retransmit timeout이 발생하고, 7번까지 시간 간격을 넓혀서 7번째 재전송패킷은 6번째가 나간 이후 64초 이후에 나가게 됩니다. 7번째부터 13번째까지는 각각 64초 간격으로 재전송이 이루어지며, 총 9분2초만에 connection이 종료됩니다

이러한 retransmit timeout에 의한 재전송은 최소 1-1.5초의 지연을 수반한다는 점에서 response time에 큰 영향을 미치게 됩니다. 따라서 이러한 retransmit timeout을 발견하게 되면, 추가적인 조치를 통해서 패킷 유실을 방지하던지 아니면 새로운 timer를 도입하여이 시간을 짧게 고쳐야만 합니다.



58 / 88

TCP Connection – retransmit timeout (3)제2장 : AIX의 socket

AIX V5.3 TL05부터는 이러한 retransmit timeout의 impact을 줄이기 위하여 새로운 timer를 하나 더 도입하였습니다.

새로운 timer를 사용하여 10ms까지 retransmit timeout을 줄일 수 있습니다. 다만, 새로운 timer가 더 사용되는 만큼 시스템의overhead가 있습니다. 따라서, retransmit timeout으로 인하여 심각하게 성능이 저하되는 경우에만 제한적으로 사용하여야만 합니다.

이를 위하여 2개의 새로운 network option이 추가되었습니다. (timer_wheel_tick, tcp_low_rto)

timer_wheel_tick을 통해서 timer의 interval을 설정합니다. (실제 interval=timer_wheel_tick*10ms) 변경을 위해서는 시스템리부팅이 필요합니다.

timer_wheel_tick*10ms의 배수로 tcp_low_rto를 설정합니다.



59 / 88

TCP Connection – Congestion control제2장 : AIX의 socket

TCP sender에서 data를 보낼 때, 받는 상대방의 receive window size이외에 고려해야 할 사항이 하나 더 있습니다. TCP는congestion window 값을 가지고, 네트웍의 congestion을 인지하고, 동적으로 보내는 전송률을 조절할 수 있습니다.

Slow start : 최초 전송을 시작할 때는 네트웍에 갑작스런 부하를 주는 것을 막기 위하여 congestion window는 1*MSS size에서시작됩니다. (remote 네트웍에 있는 호스트와 통신할 경우) 상대방으로부터 전송된 data에 대한 ACK가 정상적으로 돌아올 때 마다, congestion window를 MSS size만큼 증가시키게 됩니다.

따라서 TCP의 전송률을 시간에 따라 그래프로 표시하면 다음과 같이 됩니다.

즉, 처음에는 혼잡을 고려하여 slow start를 하고, congestion window size가 증가하여 어느한계(ssthresh)에 도달하게 되면, 아주 천천히전송률을 늘리면서 congestion avoidance phase에 도달합니다.

패킷 유실과 같은 상황이 발생하지 않고, latency도 꾸준히 유지된다고 하면, TCP는안정적인 전송 단계에 들어가게 되어, 일정한전송률을 보이게 됩니다.

ssthresh

cwnd

time

slow start

congestion avoidance



60 / 88

TCP Connection – Congestion control (2)제2장 : AIX의 socket

만일 어느 구간에서든지 패킷 유실이 발생하면, TCP는 전송률을 떨어뜨리게 됩니다. 이는 패킷 유실을 네트웍 congestion으로간주하기 때문입니다.

congestion avoidance 중 패킷 유실이발생하고, fast retransmit을 통해 복구 되었을경우에는 congestion window를 ssthresh/2로절반 정도 낮추게 됩니다. 따라서 recovery뿐만아니라 전송률에서도 손해를 보게 됩니다.

retransmit timeout이 발생하면 다시 slow start를 하게 되므로 성능이 더 많이 떨어지게됩니다.

ssthresh

cwnd

time

ssthresh/2

Fast retransmit

Retransmit timeout



61 / 88

TCP Connection – Initial window size제2장 : AIX의 socket

앞에서 살펴본 바와 같이 TCP는 서로 다른 네트웍에 있는 호스트와 통신할 때 slow start를 하여 cwnd=1부터 통신합니다. 이러한 경우작은 데이터가 오고가는 transaction의 경우에는 response time에 문제가 될 수 있습니다.

이러한 transaction 형태의 업무에 대해서는 slow start시의 initial window size를 늘려 줌으로써 response time을 줄일 수있습니다. AIX에서는 rfc2414와 tcp_init_window no parameter로 initial window size를 변경할 수 있습니다.

rfc2414가 1로 on이 되어 있고 (default) tcp_init_window가 0이 아니면, AIX는 initial window size를 변경합니다.

sender receiver

size=1460

tcp_init_window=1, size=5000byte

Resopnse time ≈ 3RTT

sender receiver

ACK

size=1460

size=1460

ACK

size=720

ACK



ACK

ACK

size=1460

size=1460

size=1460

size=720



62 / 88

TCP Connection – Initial window size제2장 : AIX의 socket

sender receiver

size=1460



ACK

size=1460

size=1460

ACK

size=720

ACK

size=1460

ACK

size=1460

idle period > 2 sec

cwnd=1

cwnd=2

cwnd=4

cwnd=5

cwnd=1

cwnd=2

왼쪽 그림과 같이 slow start로 인하여 cwnd가처음에 1로 시작한 이후, 정상적인 ACK마다cwnd가 1씩 늘어나게 됩니다. 그렇지만, 2초 이상의시간 동안 connection이 유휴 상태로 들어가게 되면, cwnd는 다시 1로 돌아가게 됩니다.

그러므로, 매 번 트랜잭션이 일어날 때마다 필요이상의 delay (>2RTT)가 발생하게 됩니다. 서로다른 네트웍에 있을 때의 delay이기 때문에 네트웍에따라서 RTT가 수 ms에서 수십 ms, 때로는 수백ms가 될 수도 있으므로, 이러한 delay가어플리케이션에 따라서는 상당한 값이 될 수도있습니다.

따라서 업무의 특성을 먼저 파악하고, 그에 맞는튜닝이 이루어져야만 효과적인 업무 수행을 할 수있습니다.



63 / 88

TCP Connection – handling idle connection제2장 : AIX의 socket

대개의 경우는 데이터의 전송을 위하여 TCP connection을 만들고, 원하는 데이터를 전송한 후 해당 connection을 close합니다. 하지만, 트랜잭션 처리에 관련된 어플리케이션들은 connection pool을 유지하여 계속 TCP connection을 ESTABLISHED 상태에두고, 데이터 전송이 필요한 경우 connection setup/close의 overhead를 줄인 채 데이터를 전송합니다.

이러한 경우 장시간 데이터 트래픽이 없으면, TCP connection이 idle한 상태가 되는데, 이러한 상태와 통신하는 상대방 호스트가예기치 않게 (power down, crash) 네트웍에서 없어진 상태와 구별이 되지 않습니다. 이렇게 상대방 서버의 outage를 check하여불필요한 connection을 없애기 위해서 keepalive timeout을 AIX가 지원합니다.

이러한 keepalive timeout의 설정을 위해서는 반드시 해당 socket이 SO_KEEPALIVE socket option을 가지고 있어야만 합니다. 그렇지 않으면, system에서 설정된 keepalive timer는 무시됩니다.

AIX에서는 tcp_keepidle, tcp_keepcnt, tcp_keepintvl 세 가지의 parameter로 이러한 동작을 제어합니다.

sender receiverIdle period

tcp_keepidle

Probing packet

Probing OK. Partner is alive!

sender receiver

Idle period

tcp_keepidle

RST packet

Probing fails. Partner is dead!

…

SO_KEEPALIVE SO_KEEPALIVE



64 / 88

TCP Connection – handling idle connection (2)제2장 : AIX의 socket

두 호스트 사이에 방화벽 (L4 Switch)이 존재하는 경우, 방화벽이 일정 시간 이상 idle한 상태로 있는 connection을 garbage collect해 버릴 수 있습니다. 이러한 경우 상대방 서버가 살아 있음에도 불구하고 Probing에 실패할 수 있습니다. 이러한 경우에tcp_keepidle값을 조정하여, TCP connection이 garbage collection되는 것을 막을 수 있습니다.

sender receiver

Idle period

tcp_keepidle

Reset


방화벽의

Garbage collection

Not received

…

SO_KEEPALIVE

이러한 경우 왼쪽 그림과 같이 tcp_keepidle 이전에방화벽(L4 Switch)에서 connection이 garbage collect됩니다. 그런 후 Probing packet이나 실제 data packet이 전송될 때, 상대방에게 전달되지 않으므로, retransmit timeout 혹은 keepidle probing실패에 의한RST packet이 전송되며 sender쪽의 TCP connection은끊어집니다.

그렇지만 받는 쪽에서는 이러한 변화를 감지하지 못할 수있습니다. (일반적으로 server process에만SO_KEEPALIVE socket option이 들어가 있는 경우가많습니다.) 이러한 경우 받는 쪽의 socket 상태는 계속해서ESTABLISHED상태로 유지될 수 있습니다.



65 / 88

TCP Connection – handling idle connection (3)제2장 : AIX의 socket

tcp_keepidle값을 조정하여, 방화벽 (L4 Switch)의 garbage collection interval보다 probing packet이 먼저 나가도록 합니다.

sender receiver

Idle period

tcp_keepidle


방화벽의

Garbage collection

Probing packet

SO_KEEPALIVE

왼쪽 그림과 같이 garbage collection되기 전에 probing packet을 보냄으로써 문제를 막을 수 있습니다.

tcp_keepidle값의 단위는 half-second이고, default값은14,400 (2시간) 입니다.

줄 수 있는 최대값은 65,535입니다. (이보다 큰 값을 주면65,535로 나눈 나머지로 세팅됩니다.)



66 / 88

TCP Connection – Delayed ACK제2장 : AIX의 socket

TCP는 효과적인 bandwidth utilization을 위하여 ACK를 delay시킬 수 있습니다. 이는 받는 쪽에서 보낼 data가 있다면 piggy-backing을 하기 위해서입니다. Maximum delay time은 200ms입니다. (fast timer)

sender receiver

앞에서 설명된 바와 같이 AIX는 200ms fast timer를가지고 있습니다. 왼쪽처럼 ACK only packet을 보내야 될상황이 되었을 경우 TCP는 다음 fast timer event까지ACK를 delay시킵니다.

fast timer event를 기다리는 도중 보낼 data가 생기면, 그data와 함께 보낼 data를 함께 보냅니다.

이러한 동작은 tcp_nodelayack no option을 1로setting함으로써 바꿀 수 있습니다. (default는 0입니다.)

해당 Application에서 TCP_NODELAYACK socket option을 넣어 주어도 변경이 가능합니다.

Fast timer event

delayed ack (ack only)

delayed ack (ack only)

Piggybacking



67 / 88

TCP Connection – Nagle’s Algorithm제2장 : AIX의 socket

작은 패킷들이 다수 전송됨으로써 overhead가 큰 경우에, 이러한 packet들을 모아서 보내어 overhead를 줄일 수 있습니다.

하지만, X11 어플리케이션처럼 빠른 response가 필요한 경우 disable하는 것이 필요합니다. (default로 사용하도록 되어 있습니다.

App.

Buffer

Sender

Socket

Receiver

Socket

1byte2byte1byte3byte

1byte

ACK (delayed)

6byte

ACK (delayed)

5byte255byte

If tcp_nagle_limit = 250

5byte

255byte

ACK (not delayed)



68 / 88

TCP Connection – Nagle’s Algorithm (2)제2장 : AIX의 socket

Nagle’s Algorithm은 tcp_nagle_limit no parameter를 통해서 동작을 제어할 수 있습니다. Default는 65535로 설정되어있으며, 이는 IP maximum datagram size입니다. 따라서, 항상 Nagle’s algorithm이 동작하도록 되어 있습니다.

Nagle’s Algorithm을 사용하지 않기 위해서는 tcp_nagle_limit을 0이나 1로 설정하시면 됩니다. 또는 Application에서TCP_NODELAY socket option을 설정해 주거나, interface specific network option에 tcp_nodelay를 1로 enable하시면됩니다. 그렇게 되면, send 소켓 버퍼에 들어온 packet들을 delay없이 상대방에게 전송하게 됩니다.

경우에 따라, Nagle’s algorithm을 disable했을 경우, 작은 패킷들이 과다하게 발생하여 ethernet adapter가 정상적으로 동작하지못하는 경우가 발생할 수 있습니다. 이러한 경우에는 해당 application에서 버퍼링을 활용하여 이러한 tinygram들이 발생하지 않도록하거나, Nagle’s algorithm을 사용하여야 합니다.

tinygram이 ethernet adapter가 견디기 힘들 정도로 많이 들어오게 되면, 해당 adapter의 DMA overrun 에러가 로깅됩니다. DMA overrun이 발생하는 경우 단위 시간당 ethernet adapter를 통과하는 패킷의 수를 모니터링 해야 하며, 이 숫자를 최대한 줄이도록해야 합니다.



69 / 88

TCP Connection – connection close 제2장 : AIX의 socket

Performed by kernel

Active closer Passive closerFIN

ACK

ACK

close(sd) or shutdown

FIN

EOF


EOF

FIN_WAIT1

CLOSE_WAIT

LAST_ACK

FIN_WAIT2

TIME_WAIT

TCP connection의 close는 대개 4-way 혹은 3-way로 일어납니다. 드문 경우 simultaneous close가 일어나 양 쪽이 동시에 FIN 패킷을 보낼 수 있습니다. Simultaneous close의 경우에는 양 쪽 소켓 모두 CLOSING을 거쳐 TIME_WAIT상태로 들어갑니다.

socket closed

socket closed after 2MSL



70 / 88

TCP Connection – Half close 제2장 : AIX의 socket

Performed by kernel


ACK


EOFFIN_WAIT1

CLOSE_WAITFIN_WAIT2

어떤 이유로든 passive closer가 자신의 소켓을 close하지 않으면 양 쪽의 소켓은 각각 FIN_WAIT2, CLOSE_WAIT 상태로 있게됩니다.

이 때, FIN_WAIT2로 대기하고 있는 소켓은 tcp_finwait2의 시간 동안 데이터를 주고받지 않으면, socket을 강제로 close하고 해당pcb를 detach해 버립니다. (default는 1,200이며 이는 10분입니다.) 그렇지만, close_wait로 남아있는 쪽은 해당 socket descriptor를 application이 close해야만 없어지므로, 반드시 해당 원인을 찾아 조치를 취해야 합니다.

특정 application은 이러한 half close를 사용하여 single-sided connection을 만들기도 합니다. (rsh, …) 이러한 경우는 일정시간이 지나면, passive closer로부터 FIN 패킷이 전송되어 정상적으로 connection을 close합니다.



71 / 88

TCP Connection – TIME_WAIT state제2장 : AIX의 socket

Performed by kernel


ACK

ACK


FIN

EOF


EOF

FIN_WAIT1

CLOSE_WAIT

LAST_ACK

FIN_WAIT2

TIME_WAIT

Active closer의 경우에는 2MSL 동안 TIME_WAIT로 소켓이 대기합니다. 이는 마지막 ACK의 유실이나, 아직 남아 있는 해당connection의 데이터들을 처리하기 위해서 필요한 시간입니다. tcp_timewait no parameter로 시간을 조절할 수 있으며 default인1로 세팅하면 maximum 15초 동안 대기합니다. 5까지 세팅할 수 있으며, 그러면 15초씩 더 TIME_WAIT 상태로 대기하게 됩니다.

socket closed

socket closed after 2MSL



72 / 88

UDP socket buffer제2장 : AIX의 socket

Application

buffer

buffer

socket

bypass

receive

socket

receive

bypass

Application

buffer

buffer

sendto()

sendto()receivefrom()

receivefrom()

Host “A” Host “B”

No UDP send buffer, but size matters



73 / 88

UDP socket buffer (2)제2장 : AIX의 socket

UDP는 TCP와는 달리 send buffer를 따로 사용하지 않습니다. 이는 TCP처럼 error recovery를 하지 않기 때문이며, 보내야 할데이터만큼 mbuf를 할당하여 바로 IP스택으로 보내 버립니다. 하지만 여전히 udp_sendspace no parameter는 존재합니다. 이것은udp_sendspace를 통하여 Maximum UDP packet size를 제한하는 목적으로 사용됩니다.

따라서 일부 application의 경우는 UDP send buffer가 작아 데이터를 보낼 때에 EMSGSIZE (message too long) 에러를받으며 전송에 실패할 수 있습니다. 이 경우에는 UDP send buffer를 충분히 키워 주셔야 합니다.

sb_max 이상은 정의할 수 없으므로 default sb_max 값(1Mbyte)이 너무 작은 경우 적당히 늘려 주셔야 합니다.

receive buffer size는 TCP와 동일한 의미를 갖습니다. 다만, TCP와 같은 flow control 메커니즘이 없으므로, buffer overflow가발생할 수 있습니다. 이는 netstat –p udp 커맨드로 쉽게 확인할 수 있습니다. 만일 socket buffer overflow가 다수 발생한다면, udp_recvspace 값을 보다 크게 설정하셔야 합니다.

buffer overflow로 drop된 UDP 패킷들은 해당 Application에서 recovery하여야 합니다.

# netstat -p udpudp:

1621059 datagrams received0 incomplete headers0 bad data length fields1 bad checksum2 dropped due to no socket1617801 broadcast/multicast datagrams dropped due to no socket0 socket buffer overflows3255 delivered4457 datagrams output



74 / 88

UDP Checksum제2장 : AIX의 socket

TCP와는 달리 UDP는 header의 checksum 계산/검증을 하지 않아도 됩니다.

이는 udpcksum no parameter로 설정할 수 있으며 default로는 사용하도록 되어 있습니다.

만일 udpcksum을 사용하지 않으면, checksum field는 모두 0으로 설정됩니다.

일반적으로 Local LAN과 같이 신뢰할 수 있는 구간에서 성능을 목적으로 disable하는 것이 가능하지만, 이러한경우 데이터의 정합성을 보장하지 않으므로 해당 application에서 어떠한 방식으로든 데이터의 정합성을 확인 하여야합니다.



75 / 88

UDP Data Transfer제2장 : AIX의 socket

Sender

socket

receiver

socket

UDP는 flow control 및 congestion control 기능이 없으므로, application이 data를 전송하면, send 버퍼 크기만 체크하고 바로전송합니다. 데이터가 MTU보다 크고 DF bit이 없다면, 해당 데이터그램은 여러 개의 fragment로 쪼개어져서 상대방에게 전송됩니다. 이러한 fragment는 통신의 상대방에 가서야 비로소 다시 하나의 데이터그램으로 합쳐집니다.

이 때, fragment 중 missing이 발생하면, 성능 문제를 일으킬 수 있습니다. UDP receive buffer를 점유하기 때문인데, 이를 위해서ipfrag_ttl (default=2, 1초)을 더 줄여서 (minimum 1, 0.5초) 소켓 버퍼를 더 빨리 clear하도록 할 수 있습니다.

Application

Data <

udp_sendspace

IP fragments



76 / 88

UDP Data Transfer제2장 : AIX의 socket

No listening port

Sender No listenerData

ICMP Port Unreachable

UDP의 경우 별도의 논리적 연결 구조가 없으므로 TCP의 경우처럼 RST 패킷을 보낼 수 없습니다. UDP의 경우 listener port가 없는경우에는 ICMP Port Unreachable error가 sender에게 return됩니다.

UDP의 경우에도 connect() call을 사용할 수 있고, connect되었을 경우에는 send(), receive() call을 사용할 수 있습니다. 물론connect() 한다고 해서 논리적인 connection이 만들어 지는 것은 아닙니다.



77 / 88

Summary

TCP connection phase

TCP socket buffer

TCP congestion control

TCP flow control

TCP error recovery

UDP socket buffer




실제 소켓 프로그램 및 분석 툴의 활용





79 / 88

Socket application제3장 : 실제 소켓 프로그램 및

분석 툴의 활용

다양한 소켓 어플리케이션 중 NFS의 예를 보고, 동작 원리 및 모니터링을 살펴봅니다.

NFS의 경우 TCP, UDP를 모두 지원하기 때문에 두 protocol의 차이를 비교하는 데 유용합니다.

netstat, tcpdump, iptrace 및 kdb를 활용하여 현재 운영중인 시스템의 환경을 살펴보고문제를 분석하는 데 이용할 수 있도록 합니다.

Open source protocol analyzer인 wireshark를 활용하여 NFS traffic을 분석해 봅니다.

Q & A

Agenda



80 / 88

Network File System (NFS)제3장 : 실제 소켓 프로그램 및


SUN microsystems의 network file sharing protocols로서 Remote Procedure Call (RPC) 기반으로 되어 있습니다.

Stateless protocol로서 서버는 어떠한 클라이언트가 현재 자신의 file system을 remote로mount하고 있는지 알지 못합니다.

AIX에서는 Version 2,3,4가 지원되며, Version 2는 UDP만, Version 4는 TCP만 지원하며, Version 3는 TCP, UDP 모두를 지원합니다.

AIX에서 NFS 서버 기능은 nfso command를 통해 튜닝 할 수 있으며, 클라이언트의 기능은대부분 mount시의 option으로 결정됩니다.



81 / 88

Wireshark (Protocol analyzer)제3장 : 실제 소켓 프로그램 및


Wireshark는 open source기반의 강력한 protocol analyzer입니다. 이를 이용하여 다양한 프로토콜의 통계를 얻을 수 있으며, 문제분석의 필수 툴이라고 할 수 있습니다.

www.wireshark.org에서 무료로 download할 수 있으며, AIX, Linux, Mac OS X 등 다양한 platform을 지원합니다.



82 / 88

tcpdump / iptrace제3장 : 실제 소켓 프로그램 및


tcpdump는 AIX, Linux 및 기타 유닉스 운영체제에서 널리 사용되며, 간단한 online monitoring시에 매우 유용한 툴입니다.

iptrace는 AIX 고유의 packet 캡춰 tool로서 startsrc/stopsrc로 운영을 제어할 수 있는 장점이 있습니다.

# tcpdump -i en2

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on en2, link-type 1, capture size 96 bytes

19:19:58.736580 IP 9.127.254.47.51946 > rooney.telnet: . ack 2923702575 win 64425 19:19:58.736697 IP rooney.telnet > 9.127.254.47.51946: P 1:131(130) ack 0 win 65535 19:19:58.936238 IP 9.127.254.47.51946 > rooney.telnet: . ack 131 win 64295

19:19:58.936337 IP rooney.telnet > 9.127.254.47.51946: P 131:299(168) ack 0 win 65535 19:19:59.135284 IP 9.127.254.47.51946 > rooney.telnet: . ack 299 win 65535

19:19:59.135350 IP rooney.telnet > 9.127.254.47.51946: P 299:462(163) ack 0 win 65535 19:19:59.336686 IP 9.127.254.47.51946 > rooney.telnet: . ack 462 win 65372

19:19:59.336754 IP rooney.telnet > 9.127.254.47.51946: P 462:625(163) ack 0 win 65535



83 / 88

NFS Server제3장 : 실제 소켓 프로그램 및


RPC daemon

portmapper

mountd nfsd

register

# rpcinfo -p

program vers proto port service

...

100003 4 tcp 2049 nfs

200006 4 udp 2049

200006 4 tcp 2049

100003 2 udp 2049 nfs

100003 3 udp 2049 nfs

100003 2 tcp 2049 nfs

100003 3 tcp 2049 nfs

...

100005 1 tcp 32828 mountd

100005 2 tcp 32828 mountd

100005 3 tcp 32828 mountd

100005 1 udp 33073 mountd

100005 2 udp 33073 mountd

100005 3 udp 33073 mountd



84 / 88

NFS mount제3장 : 실제 소켓 프로그램 및


NFS client NFS server

RPC를 통해 mountd의 port number query

RPC Reply. Port number is 33073 (portmapper)

Mount Null Call (test)

Mount Null Reply

RPC를 통해 nfsd의 port number query

RPC Reply. Port number is 2049 (portmapper)

NFS Null Call (test)

NFS Null Reply

Mount Call (/nfs)

Mount Reply (OK) with filehandle

NFS FSINFO request

NFS FSINFO reply

* 실제 packet trace와 비교



85 / 88

NFSv3 TCP vs. UDP

AIX NFS Client는 NFS server와 1개의 TCP connection을 유지합니다. 이 한 개의 TCP connection을 통하여 모든 NFS RPC request를 서버로 전송합니다. 이 connection은 NFS file system이 umount되어도 유지됩니다.

NFS가 TCP를 이용하는 경우 data의 정합성은 TCP layer에서 보장합니다. Loss된 packet에 대한 재전송 또한 TCP가 보장합니다. 그렇지만, 서버와의 접속이 불가능할 경우도 있으므로, NFS protocol역시 timeout period를 가지고 있습니다. 즉, TCP의 retransmit timeout process가 끝나기 전에 NFS client가 서버 쪽으로 RST packet을 보내 connection을 강제 종료할 수 있습니다.

RST으로 끊은 후에 바로 다시 connection을 요청하며 이전에 사용하던 port와 같은 port를 사용합니다.

TCP

UDP의 경우에는 따로 Connection이 존재하지 않고, 바로 RPC request가 서버로 전달됩니다.

data의 정합성은 NFS layer에서 보장되어야 하며, 각각의 UDP request는 별도의 transaction으로 처리됩니다. TCP보다 서버에조금 더 부하를 줄 수 있습니다. (더 많은 RPC retransmission)

UDP

제3장 : 실제 소켓 프로그램 및분석 툴의 활용

* 패킷 유실시의 차이점 비교 (실습)



86 / 88

NFS TCP Data Flow제3장 : 실제 소켓 프로그램 및


NFS

Client

Client

Socket

Server

Socket

nfsd

thread

rsize, wsize

MSS chunks

rsize와 wsize는 mount option이며, AIX에서는최대 64KB까지 사용할 수 있습니다. Linux의 경우는32KB가 maximum입니다.

rsize, wsize만큼의 I/O가 하나의 RPC request로처리됩니다.

NFS 서버는 하나의 RPC Request마다 하나의 nfsd thread를만들어서 서비스합니다. nfsd thread의 개수가 따라서 매우중요합니다.

NFS 서버의 파일 시스템의 meta data정보를 client가 알지못하기 때문에 client는 file 혹은 directory access를 할 때마다meta data를 먼저 query하고 자신의 local cache에 저장하여보관합니다. Local cache의 expiration time은 client가mount시에 정할 수 있습니다.



87 / 88

NFS UDP Data Flow제3장 : 실제 소켓 프로그램 및


NFS

Client

Client

Socket

Server

Socket

nfsd

thread

rsize, wsize

IP fragments

rsize와 wsize는 mount option이며, AIX에서는최대 64KB까지 사용할 수 있습니다. Linux의 경우는32KB가 maximum입니다.

rsize, wsize만큼의 I/O가 하나의 RPC request로처리됩니다.

UDP의 경우에는 rsize, wsize만큼 한 번에 I/O를 일으키며, 따라서 IP fragmentation이 다수 발생합니다.

nfsd는 socket option을 통하여 udp_sendspace와udp_recvspace를 변경하므로, no에서 설정하여도 nfsd의 값으로설정됩니다.



88 / 88

감사합니다.감사합니다.

Q&A

Documents

AIX 소켓프로그램의이해및튜닝 - 데이터 전문가 지식포털 · 2008-04-21 · AIX 소켓프로그램의이해및튜닝 김기완차장([email protected]) Senior IT Specialist