Microsoft PowerPoint - Socket.ppt

Transcription

1 The Best Reliable Partner for High Availability * 2008 상반기효과적인시스템관리를위한기술세미나 - COEX, Seoul, Korea AIX 소켓프로그램의이해및튜닝 김기완차장 (kwk@kr.ibm.com) Senior IT Specialist MTS, IBM Global Technology Services Korea April 8, IBM Corporation

2 Agenda 1. 소켓개요 2. AIX 의소켓 3. 실제소켓프로그램의예및분석툴의활용 2/ 88

3 The Best Reliable Partner for High Availability 2008 * 상반기효과적인시스템관리를위한기술세미나 - COEX, Seoul, Korea 소켓개요 MTS, IBM Global Technology Services Korea 2008 IBM Corporation

4 프로세스간통신 (Interprocess communications) 제 1 장 : 소켓개요 하나의프로세스만으로는업무처리가효율적이지못하므로여러프로세스간에효과적으로 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 를위한다양한형태의통신프로그램을개발할수있습니다. 4/ 88

5 Socket API 제 1 장 : 소켓개요 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 의서비스를받도록합니다. 5/ 88

6 Socket Layer 의 Concept 제 1 장 : 소켓개요 application user kernel Socket API Socket system call implementations Function call System call Function call Socket layer functions 6/ 88

7 Socket structure 제 1 장 : 소켓개요 프로토콜, 소켓타입소켓버퍼정보타이머정보소켓옵션정보소켓큐정보소켓의현재상태 Socket structure 소켓구조체는해당소켓에대한모든정보를담고있습니다. 소켓의타입에대한정보 (Stream, datagram, ), 소켓의버퍼구조체에대한정보, 일부 timer 및각종 option 및 queue 에대한정보등을가지고있습니다. 이는주로, 소켓이만들어질때결정되는여러파라미터들이며, 실제통신중의동적인값들은실제이소켓구조체와연결되어있는해당 protocol control block (PCB) 에저장되어있습니다. TCP 혹은 UDP 를사용한 peer 통신의경우에는통신하는상대방또한유사한소켓구조체를가지고있으며, 이둘간의논리적인연결을 Socket connection 이라고합니다. 소켓옵션은다양한방법으로주어지며, 운영체제에서결정하기도하고, 실제프로그램을작성할때에개발자의의도대로삽입되기도합니다. 소켓은 process 가 socket descriptor 에대한 pointer 를가지고있을경우에만유효합니다. 7/ 88

8 소켓타입 제 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 소켓이라고생각하시면됩니다. 이러한소켓타입은소켓이만들어질때결정되며, 따라서사용하시려는프로토콜에맞게정의하셔야합니다. 8/ 88

9 소켓버퍼 제 1 장 : 소켓개요 User Application socket I/O multiplexing buffers send send mbuf mbuf mbuf buffers receive receive mbuf mbuf mbuf peer 9/ 88

10 소켓옵션 제 1 장 : 소켓개요 /usr/include/sys/socket.h #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 (*) 소켓옵션은프로그램작성시에정의할수있으며, 운영체제의파라미터형태로도넣을수있습니다. 하지만항상프로그램작성시에정의된값이우선합니다. 10 / 88

11 소켓 functions 제 1 장 : 소켓개요 /usr/include/sys/socket.h 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 등으로이루어져있습니다. 11 / 88

12 소켓상태 제 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 에정보가담겨있습니다. 12 / 88

13 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 을이용하여수신된패킷의정합성만확인하게됩니다. 13 / 88

14 Socket Connection (2) 제 1 장 : 소켓개요 In TCP (Connection oriented protocol) Client socket Client socket Client socket Listening socket Client socket Connection request (*) TCP Connection 이만들어지기위해서는먼저 connection request 를받아들일수있는 Listening socket 이준비되어있어야합니다. 흔히, 이렇게 listening 하고있는 socket 이있는프로세스를서버프로세스라하며, Connection request 를통하여 connection 을요청하는프로세스를클라이언트프로세스라고합니다. 경우에따라서, 이러한서버와클라이언트의역할이어플리케이션의형태와는좀다를수도있습니다. (*) 단지 1 개의 connection 을맺는소켓페어의경우에도반드시하나의 socket 은해당 port 에서 listening 을하고있어야만합니다. 물론, 양쪽모두 listening 을하고있는경우도존재할수있습니다. 14 / 88

15 Data transfer 제 1 장 : 소켓개요 In TCP (Connection oriented protocol) socket Full Duplex socket (*) TCP 의경우, 논리적으로연결된 connection 을통해두개 (send, receive) 의통신채널이준비되며, 따라서 full duplex 의형태로통신이이루어집니다. 데이터를보내는것과받는것이동시에이루어지며, 따라서효과적인통신을위해서는 I/O multiplex 를할수있는방법으로프로그래밍되어야합니다. ( 흔히 select() call 을사용 ) In UDP (Connectionless protocol) socket send / receive receive / send socket (*) udp 의경우는논리적인연결이없으므로, 개별 send / receive 가각각이루어지며, 어떠한 byte offset 도제공되지않습니다. 따라서, 이러한부분을해당 user application 에서구현해주어야만합니다. 15 / 88

16 Socket Connection close 제 1 장 : 소켓개요 In TCP (Connection oriented protocol) socket close EOF close socket (*) 연결되어있는논리적인 connection 을끊습니다. 이는끊기를원하는쪽에서해당 socket descriptor 를 close() 함으로써시작되며, 이때상대방쪽으로는 EOF (end of file) 형태로전달되게됩니다. 끊는과정은 full duplex 로통신하는각각에대해서모두이루어져야하며, 흔히 4-step 으로이루어집니다. In UDP (Connectionless protocol) socket close close socket (*) 그렇지만 UDP 의경우에는명시적인논리적연결이없으므로, 각자자신의 socket 을 close 할수있습니다. close 할때어떠한경우도상대방에게통보되지않으며, 따라서이러한부분의동기화도 application 에서책임져야합니다. 16 / 88

17 Summary 제 1 장 : 소켓개요 Socket API Socket structure Connection oriented vs. Connectionless socket Connection setup Data transfer Connection close Protocol control block 17 / 88

18 The Best Reliable Partner for High Availability 2008 * 상반기효과적인시스템관리를위한기술세미나 - COEX, Seoul, Korea AIX 의소켓 MTS, IBM Global Technology Services Korea 2008 IBM Corporation

19 Socket API in AIX 제 2 장 : 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 뿐만아니라, 여러다른효과를고려하여신중하게결정하여야합니다. 19 / 88

20 Network Option command in AIX 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 를통해서대부분파라미터의의미를파악할수있습니다. 20 / 88

21 Timer in AIX kernel (for TCP/IP stack) 제 2 장 : AIX 의소켓 2 types of timer (fast timer, slow timer) boot time (*) fast timeout : kernel 이동작하기시작하면, 매 200ms (default) 마다 fast_timo event 가발생하며, 이 event 가발생할때마다, 모든 inpcb 를돌며, 적용되는 event 가있다면처리합니다. (delayed ack, nagle s algorithm ). 이값은 no parameter 로조절할수있으며, 값의범위는 ms 입니다. Dynamic 하게변경이가능합니다. 변경하게되면, 해당 event 의수가늘어날수있으므로, CPU 사용율이올라갈수있는대신, interactive 한 connection 에서 delay 를줄일수있습니다. Ex) no po fasttimo=50 boot time (*) 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 를사용하기때문입니다. 21 / 88

22 Network Memory AIX 의 network memory 의크기는 thewall network option paramter 로결정됩니다. AIX 까지는이값을유저가직접 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 를수반합니다. 22 / 88

23 Network Memory (2) (0)> kmbucket -s current_heap heaps_in_use thewall kmemfreelater wantkmemmap kmemtid threadtime...2ff20358 kmempages kmemreserve kmemgcintvl kmemgcscale kmeminuse ad80 allocated...013c1000 net_malloc_police sock_thresh_size...0d dr_token dr_rmcpucnt inet_dr_cpu_remove...312ad / 88

24 TCP Segments Ethernet Header IP Header TCP Header User data 18bytes ~ 20bytes > 20bytes < Maximum Segment Size < 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 바이트더작아지게됩니다. 24 / 88

25 TCP Header format 16-bit source port number 16-bit destination port number 32-bit sequence number 32-bit acknowledgement number 4-bit header length Reserved (6bits) U R G A C K P S H R S T S Y N F I N 16-bit window size 16-bit TCP checksum 16-bit urgent pointer TCP Options (timestamp, sack) User Data 25 / 88

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

27 TCP Connection Prepare server (listen) socket User Application socket() call User Application File Descriptor Socket structure int socket ( int domain, int type, int protocol); domain : AF_UNIX, AF_INET, type : SOCK_DGRAM, SOCK_STREAM, protocol : IPPROTO_TCP, IPPROTO_SCTP Inpcb structure tcpcb inpcb chain (can be reused) 27 / 88

28 TCP Connection Prepare server (listen) socket (2) bind step int bind (sockfd, name, namelength) bind 는만들어진 socket 을특정 ip address 와 port number 와연결시키는과정입니다. 흔히 ip address 로 INADDR_ANY 가사용되는데, 이는시스템에정의된모든 ip address 와연결시키게됩니다. 즉해당소켓을이용해서통신할때, 시스템의어느 ip address 를사용하여도된다는의미이며, 주로서버소켓이이러한방식으로 bind 됩니다. 서버가사용하는 port number 는 까지아직할당되지않은숫자로사용할수있습니다. 이미사용중인 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 bind() call socket Ip address & port # 28 / 88

29 TCP Connection Prepare server (listen) socket (3) 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 Ip address & port # listen() call socket listen queue Ip address & port # 29 / 88

30 TCP Connection Prepare client socket User Application socket() call User Application File Descriptor Socket structure int socket ( int domain, int type, int protocol); domain : AF_UNIX, AF_INET, type : SOCK_DGRAM, SOCK_STREAM, protocol : IPPROTO_TCP, IPPROTO_SCTP Inpcb structure tcpcb inpcb chain (can be reused) 30 / 88

31 TCP Connection Connection request 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 Ip address & port # connect() call server socket listen queue Ip address & port # implicit bind 31 / 88

32 TCP Connection implicit bind Client Gateway Server / UG 0 0 en0 en0 에있는 ip address : , (ifconfig 에서나오는순서대로 ) 가 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 를해주시면됩니다. 32 / 88

33 TCP Connection 3 way handshaking Performed by kernel connect() client SYN_SENT SYN server SYN/ACK SYN_RCVD ACK ESTABLISHED ESTABLISHED 위와같이 3-way handshaking 이끝나게되면, 양쪽의 socket status 는 ESTABLISHED 상태가되어통신이가능한상태가됩니다. SYN, ACK 는각각 TCP header 의해당 flag 가 setting 되어있다는의미입니다. 위의과정은모두 kernel 에서이루어지며 user program 이관련되는부분은없습니다. 이러한일련의과정은모두 client 에서 connect() call 을함으로써시작됩니다. 33 / 88

34 TCP Connection 3 way handshaking (2) Server not responding client SYN SYN SYN SYN Server Not exist or shutdowned 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 메시지를보여줍니다. 34 / 88

35 TCP Connection 3 way handshaking (3) No listening port client SYN No listener RST Client 가 SYN 패킷을통하여 connect 를시도하였으나, 서버에해당서버 listening port 가존재하지않는경우에는서버로부터바로 RST flag 가 setting 되어있는 RST 패킷이돌아옵니다. 이경우 client 의 connect call 은바로 -1 로 return 되며 ECONNRESET 이 errno 으로세팅됩니다. 대개 Connection reset by peer 메시지를보여주게됩니다. 35 / 88

36 TCP Connection 3 way handshaking (4) What if server s listen queue is full? client SYN server Queue full TCP server 쪽의 Listen queue 에여분의공간이없을경우가있습니다. 이러한경우당연히 3-way handshaking 이정상적으로이루어지지않습니다. 36 / 88

37 TCP Connection Listen queue 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 연결이될수도있기때문입니다. 37 / 88

38 TCP Connection 3 way handshaking (5) q0len full (connection incompletion queue full) client SYN Attack server SYN/ACK 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 를늘려줘야할수도있습니다. 38 / 88

39 TCP Connection 3 way handshaking (6) qlen full (connection completion queue full) client SYN SYN (retransmission) SYN/ACK server Queue full qlen full ACK 만일서버의 qlen 이늘면서 queue full 이된경우는 connection setup 이완료된 connection 을해당 Application 이 accept 해가지못하는것이문제이므로, 해당 application 이왜그런상황에있는지를점검하여야합니다. Web server 의경우 worker thread 의개수가충분한지, 현재모든 worker thread 가사용되고있는지를점검하여야하고, 실제들어오는 connection request 의숫자가너무많아서그런경우가발생한다면, somaxconn 과 backlog parameter 를각각 AIX 와해당 application server 에서늘려주셔야합니다. 39 / 88

40 TCP Connection 3 way handshaking (7) monitoring # netstat -s grep listen 0 discarded by listeners 0 discarded due to listener's queue full 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 설정을증가하시고다시시작하셔야만합니다. 40 / 88

41 TCP Connection accept (1) connection accept int accept (sockfd, name, namelength) 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 를넘겨처리하는방법 가장효율적인방법 41 / 88

42 TCP Connection accept (2) Listener process (thread) 가직접처리 Listener socket accepted socket Main process accept() 코드수행을마친후다시 accept() 수행 Connection Completion queue Processing requests 이러한경우, 한번에한개의 request 만처리됩니다. 42 / 88

43 TCP Connection accept (3) 새로운 process 를 fork() Listener process Worker process Listening socket Accepted socket Listening socket Accepted socket fork() Connection Completion queue Connection Completion queue 이러한경우, connection 마다한개의 process 가 fork 되어해당 request 를처리합니다. 경우에따라미리만들어진 process 에 socket descriptor 만 passing 하여 request 를처리하게할수있습니다. 43 / 88

44 TCP Connection accept (3) 새로운 thread 에서처리 Listener thread Worker thread Listening socket Accepted socket Socket descriptor passing Accepted socket Connection Completion queue Processing 이러한경우, connection 은 listener thread 와다른별도의 worker thread 에서처리됩니다. 이때두 thread 는같은 process 에있을수도있고, 서로다른 thread 에있을수도있습니다. 경우에따라미리만들어진 thread 에 socket descriptor 만 passing 하여 request 를처리하게할수있습니다. 44 / 88

45 TCP Connection Socket buffer Application socket socket Application buffer send() send receive receive() buffer buffer receive() receive send send() buffer Host A Host B 45 / 88

46 TCP Connection Socket buffer (2) - sender Application 32KB data socket AIX kernel buffer by send() call get EAGAIN if buffer is full buffer MSS Chunks 만일 large_send 가 enable 되어있으면, Ethernet adapter 가 MSS size 로 data 를쪼개게되고, kernel 은그대로 32KB 의 data 를전송합니다. #netstat an tcp ESTABLISHED 46 / 88

47 TCP Connection Socket buffer (3) send/receive Send buffer Congestion Control Receive buffer 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 만사용됩니다. 47 / 88

48 TCP Connection Socket buffer (4) receiver socket received data Application interrupts buffer I/O multiplexed by select() buffer MSS Chunks Inform free buffer size to sender through ACK packet #netstat an tcp ESTABLISHED 48 / 88

49 TCP Connection Socket buffer (5) Flow Control 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 하게됩니다. 49 / 88

50 TCP Connection Socket buffer (6) sizing data Send buffer Receive buffer 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 환경에서는적용되지않습니다. 50 / 88

51 TCP Connection Socket buffer (7) sizing 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 까지만사용하게되는데, 이를 scale factor 를이용하여더큰값을사용할수있도록하는것이 rfc1323 입니다. 이러한 scale factor 는 TCP connection 을맺을때 option 으로서로주고받습니다. tcp_sendspace, tcp_recvspace no parameter 를통하여설정할수있으며, isno, socket option 으로도설정이가능합니다. sb_max 이상은정의할수없으므로 default sb_max 값 (1Mbyte) 이너무작은경우적당히늘려주셔야합니다. tcp_sendspace tcp_recvspace rfc Mbps 131,072 65, Gbps 262, , Gbps > 262,144 > 262, / 88

52 TCP Offload function 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 하는것이좋습니다. 52 / 88

53 TCP Connection data flow HOST A Seq:2, ACK:1, size:5 Seq:1, ACK:7, size:0 Seq:7, ACK:1, size:1460 HOST B Seq:1467, ACK:1, size:1460 Seq:1, ACK:2927, size:200 Seq:2927, ACK:201, size:800 Seq:201, ACK:3727, size:0 53 / 88

54 TCP Connection fast retransmission Seq:2, ACK:1, size:1460 missing Seq:1462, ACK:1, size:1460 Seq:2922, ACK:1, size:1460 Seq:4382, ACK:1, size:1460 Seq:5842, ACK:1, size:1460 Seq:1, ACK:2, size:0 Seq:1, ACK:2, size:0 Seq:1, ACK:2, size:0 Seq:1, ACK:2, size:0 Seq:2, ACK:1, size:1460 HOST A retransmission Duplicate ACKs HOST B 54 / 88

55 TCP Connection fast retransmission (2) 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 는 이상부터 sack 을사용할수있도록하였으며, default 는사용하지않는것으로되어있습니다. sack 을사용할때일부방화벽이문제를야기할수있습니다. Connection hijacking 을막기위하여일부방화벽이 sequence number 를 modify 하는데, 이상황에서 sack field 를올바르게바꾸어주지않으면, fast recovery 과정에서 TCP connection 이 stuck/reset 되는것이가능합니다. 따라서 sack 의사용은주변환경을신중히파악하고사용을결정하여야합니다. 55 / 88

56 TCP Connection retransmit timeout Seq:2, ACK:1, size:1460 Seq:1, ACK:1462, size:0 Seq:1462, ACK:1, size:600 Retransmit timeout missing Seq:1462, ACK:1, size:600 Seq:1, ACK:2922, size:0 HOST A retransmit HOST B 56 / 88

57 TCP Connection retransmit timeout (2) 소량의데이터를 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) 위와같은설정을사용하였을경우최초 초사이에 retransmit timeout 이발생하고, 7 번까지시간간격을넓혀서 7 번째재전송패킷은 6 번째가나간이후 64 초이후에나가게됩니다. 7 번째부터 13 번째까지는각각 64 초간격으로재전송이이루어지며, 총 9 분 2 초만에 connection 이종료됩니다 이러한 retransmit timeout 에의한재전송은최소 초의지연을수반한다는점에서 response time 에큰영향을미치게됩니다. 따라서이러한 retransmit timeout 을발견하게되면, 추가적인조치를통해서패킷유실을방지하던지아니면새로운 timer 를도입하여이시간을짧게고쳐야만합니다. 57 / 88

58 TCP Connection retransmit timeout (3) 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 를설정합니다. 58 / 88

59 TCP Connection Congestion control 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 의전송률을시간에따라그래프로표시하면다음과같이됩니다. cwnd ssthresh slow start congestion avoidance 즉, 처음에는혼잡을고려하여 slow start 를하고, congestion window size 가증가하여어느한계 (ssthresh) 에도달하게되면, 아주천천히전송률을늘리면서 congestion avoidance phase 에도달합니다. 패킷유실과같은상황이발생하지않고, latency 도꾸준히유지된다고하면, TCP 는안정적인전송단계에들어가게되어, 일정한전송률을보이게됩니다. time 59 / 88

60 TCP Connection Congestion control (2) 만일어느구간에서든지패킷유실이발생하면, TCP 는전송률을떨어뜨리게됩니다. 이는패킷유실을네트웍 congestion 으로간주하기때문입니다. cwnd ssthresh ssthresh/2 congestion avoidance 중패킷유실이발생하고, fast retransmit 을통해복구되었을경우에는 congestion window 를 ssthresh/2 로절반정도낮추게됩니다. 따라서 recovery 뿐만아니라전송률에서도손해를보게됩니다. retransmit timeout 이발생하면다시 slow start 를하게되므로성능이더많이떨어지게됩니다. Fast retransmit Retransmit timeout time 60 / 88

61 TCP Connection Initial window size 앞에서살펴본바와같이 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 를변경합니다. size=1460 size=1460 ACK size=1460 size=1460 sender size=1460 ACK receiver sender size=1460 ACK receiver size=720 size=720 ACK ACK tcp_init_window=1, size=5000byte Resopnse time 3RTT tcp_init_window=4, size=5000byte Resopnse time 1RTT 61 / 88

62 TCP Connection Initial window size size=1460 cwnd=1 ACK sender size=1460 size=1460 ACK size=720 ACK idle period > 2 sec size=1460 ACK receiver 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 가어플리케이션에따라서는상당한값이될수도있습니다. 따라서업무의특성을먼저파악하고, 그에맞는튜닝이이루어져야만효과적인업무수행을할수있습니다. size=1460 tcp_init_window=1, size=5000byte Resopnse time 3RTT 62 / 88

63 TCP Connection handling idle connection 대개의경우는데이터의전송을위하여 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 로이러한동작을제어합니다. SO_KEEPALIVE SO_KEEPALIVE Idle period sender Idle period tcp_keepidle receiver sender tcp_keepidle receiver Probing packet RST packet Probing OK. Partner is alive! Probing fails. Partner is dead! 63 / 88

64 TCP Connection handling idle connection (2) 두호스트사이에방화벽 (L4 Switch) 이존재하는경우, 방화벽이일정시간이상 idle 한상태로있는 connection 을 garbage collect 해버릴수있습니다. 이러한경우상대방서버가살아있음에도불구하고 Probing 에실패할수있습니다. 이러한경우에 tcp_keepidle 값을조정하여, TCP connection 이 garbage collection 되는것을막을수있습니다. SO_KEEPALIVE sender Idle period tcp_keepidle 방화벽의 Garbage collection receiver 이러한경우왼쪽그림과같이 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 상태로유지될수있습니다. Reset Not received Probing fails. Partner is dead! 64 / 88

65 TCP Connection handling idle connection (3) tcp_keepidle 값을조정하여, 방화벽 (L4 Switch) 의 garbage collection interval 보다 probing packet 이먼저나가도록합니다. SO_KEEPALIVE sender Idle period tcp_keepidle Probing packet receiver 왼쪽그림과같이 garbage collection 되기전에 probing packet 을보냄으로써문제를막을수있습니다. tcp_keepidle 값의단위는 half-second 이고, default 값은 14,400 (2 시간 ) 입니다. 줄수있는최대값은 65,535 입니다. ( 이보다큰값을주면 65,535 로나눈나머지로세팅됩니다.) 방화벽의 Garbage collection Probing fails. Partner is dead! 65 / 88

66 TCP Connection Delayed ACK TCP 는효과적인 bandwidth utilization 을위하여 ACK 를 delay 시킬수있습니다. 이는받는쪽에서보낼 data 가있다면 piggybacking 을하기위해서입니다. Maximum delay time 은 200ms 입니다. (fast timer) Fast timer event delayed ack (ack only) 앞에서설명된바와같이 AIX 는 200ms fast timer 를가지고있습니다. 왼쪽처럼 ACK only packet 을보내야될상황이되었을경우 TCP 는다음 fast timer event 까지 ACK 를 delay 시킵니다. sender delayed ack (ack only) receiver fast timer event 를기다리는도중보낼 data 가생기면, 그 data 와함께보낼 data 를함께보냅니다. 이러한동작은 tcp_nodelayack no option 을 1 로 setting 함으로써바꿀수있습니다. (default 는 0 입니다.) 해당 Application 에서 TCP_NODELAYACK socket option 을넣어주어도변경이가능합니다. Piggybacking 66 / 88

67 TCP Connection Nagle s Algorithm 작은패킷들이다수전송됨으로써 overhead 가큰경우에, 이러한 packet 들을모아서보내어 overhead 를줄일수있습니다. 하지만, X11 어플리케이션처럼빠른 response 가필요한경우 disable 하는것이필요합니다. (default 로사용하도록되어있습니다. 1byte 2byte 1byte 3byte 1byte ACK (delayed) 6byte App. Sender ACK (delayed) Receiver Buffer 5byte 255byte Socket 5byte 255byte Socket ACK (not delayed) If tcp_nagle_limit = / 88

68 TCP Connection Nagle s Algorithm (2) Nagle s Algorithm 은 tcp_nagle_limit no parameter 를통해서동작을제어할수있습니다. Default 는 로설정되어있으며, 이는 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 를통과하는패킷의수를모니터링해야하며, 이숫자를최대한줄이도록해야합니다. 68 / 88

69 TCP Connection connection close Performed by kernel Active closer close(sd) or shutdown FIN_WAIT1 FIN Passive closer EOF ACK CLOSE_WAIT EOF FIN_WAIT2 FIN LAST_ACK close(sd) or shutdown TIME_WAIT ACK socket closed after 2MSL socket closed TCP connection 의 close 는대개 4-way 혹은 3-way 로일어납니다. 드문경우 simultaneous close 가일어나양쪽이동시에 FIN 패킷을보낼수있습니다. Simultaneous close 의경우에는양쪽소켓모두 CLOSING 을거쳐 TIME_WAIT 상태로들어갑니다. 69 / 88

70 TCP Connection Half close Performed by kernel Active closer close(sd) or shutdown FIN_WAIT1 FIN Passive closer EOF ACK FIN_WAIT2 CLOSE_WAIT 어떤이유로든 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 합니다. 70 / 88

71 TCP Connection TIME_WAIT state Performed by kernel Active closer close(sd) or shutdown FIN_WAIT1 FIN Passive closer EOF ACK CLOSE_WAIT EOF FIN_WAIT2 FIN LAST_ACK close(sd) or shutdown TIME_WAIT ACK socket closed after 2MSL socket closed Active closer 의경우에는 2MSL 동안 TIME_WAIT 로소켓이대기합니다. 이는마지막 ACK 의유실이나, 아직남아있는해당 connection 의데이터들을처리하기위해서필요한시간입니다. tcp_timewait no parameter 로시간을조절할수있으며 default 인 1 로세팅하면 maximum 15 초동안대기합니다. 5 까지세팅할수있으며, 그러면 15 초씩더 TIME_WAIT 상태로대기하게됩니다. 71 / 88

72 UDP socket buffer Application socket socket Application buffer sendto() bypass receive receivefrom() buffer buffer receivefrom() receive bypass sendto() buffer Host A No UDP send buffer, but size matters Host B 72 / 88

73 UDP socket buffer (2) 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 udp udp: datagrams received 0 incomplete headers 0 bad data length fields 1 bad checksum 2 dropped due to no socket broadcast/multicast datagrams dropped due to no socket 0 socket buffer overflows 3255 delivered 4457 datagrams output 73 / 88

74 UDP Checksum TCP 와는달리 UDP 는 header 의 checksum 계산 / 검증을하지않아도됩니다. 이는 udpcksum no parameter 로설정할수있으며 default 로는사용하도록되어있습니다. 만일 udpcksum 을사용하지않으면, checksum field 는모두 0 으로설정됩니다. 일반적으로 Local LAN 과같이신뢰할수있는구간에서성능을목적으로 disable 하는것이가능하지만, 이러한경우데이터의정합성을보장하지않으므로해당 application 에서어떠한방식으로든데이터의정합성을확인하여야합니다. 74 / 88

75 UDP Data Transfer Application Sender socket receiver socket IP fragments Data < udp_sendspace 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 하도록할수있습니다. 75 / 88

76 UDP Data Transfer No listening port Sender Data No listener ICMP Port Unreachable UDP 의경우별도의논리적연결구조가없으므로 TCP 의경우처럼 RST 패킷을보낼수없습니다. UDP 의경우 listener port 가없는경우에는 ICMP Port Unreachable error 가 sender 에게 return 됩니다. UDP 의경우에도 connect() call 을사용할수있고, connect 되었을경우에는 send(), receive() call 을사용할수있습니다. 물론 connect() 한다고해서논리적인 connection 이만들어지는것은아닙니다. 76 / 88

77 Summary 제 1 장 : 소켓개요 TCP connection phase TCP socket buffer TCP congestion control TCP flow control TCP error recovery UDP socket buffer 77 / 88

78 The Best Reliable Partner for High Availability 2008 * 상반기효과적인시스템관리를위한기술세미나 - COEX, Seoul, Korea 실제소켓프로그램및분석툴의활용 MTS, IBM Global Technology Services Korea 2008 IBM Corporation

79 Socket application Agenda 제 3 장 : 실제소켓프로그램및분석툴의활용 다양한소켓어플리케이션중 NFS 의예를보고, 동작원리및모니터링을살펴봅니다. NFS 의경우 TCP, UDP 를모두지원하기때문에두 protocol 의차이를비교하는데유용합니다. netstat, tcpdump, iptrace 및 kdb 를활용하여현재운영중인시스템의환경을살펴보고문제를분석하는데이용할수있도록합니다. Open source protocol analyzer 인 wireshark 를활용하여 NFS traffic 을분석해봅니다. Q & A 79 / 88

80 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 으로결정됩니다. 80 / 88

81 Wireshark (Protocol analyzer) 제 3 장 : 실제소켓프로그램및분석툴의활용 Wireshark 는 open source 기반의강력한 protocol analyzer 입니다. 이를이용하여다양한프로토콜의통계를얻을수있으며, 문제분석의필수툴이라고할수있습니다. 에서무료로 download 할수있으며, AIX, Linux, Mac OS X 등다양한 platform 을지원합니다. 81 / 88

82 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: IP > rooney.telnet:. ack win :19: IP rooney.telnet > : P 1:131(130) ack 0 win :19: IP > rooney.telnet:. ack 131 win :19: IP rooney.telnet > : P 131:299(168) ack 0 win :19: IP > rooney.telnet:. ack 299 win :19: IP rooney.telnet > : P 299:462(163) ack 0 win :19: IP > rooney.telnet:. ack 462 win :19: IP rooney.telnet > : P 462:625(163) ack 0 win / 88

83 NFS Server 제 3 장 : 실제소켓프로그램및분석툴의활용 mountd RPC daemon portmapper register nfsd # rpcinfo -p program vers proto port service tcp 2049 nfs udp tcp udp 2049 nfs udp 2049 nfs tcp 2049 nfs tcp 2049 nfs tcp mountd tcp mountd tcp mountd udp mountd udp mountd udp mountd 83 / 88

84 NFS mount NFS client NFS server 제 3 장 : 실제소켓프로그램및분석툴의활용 RPC 를통해 mountd 의 port number query RPC Reply. Port number is (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) NFS FSINFO request Mount Reply (OK) with filehandle NFS FSINFO reply * 실제 packet trace 와비교 84 / 88

85 NFSv3 TCP vs. UDP TCP 제 3 장 : 실제소켓프로그램및분석툴의활용 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 를사용합니다. UDP UDP 의경우에는따로 Connection 이존재하지않고, 바로 RPC request 가서버로전달됩니다. data 의정합성은 NFS layer 에서보장되어야하며, 각각의 UDP request 는별도의 transaction 으로처리됩니다. TCP 보다서버에조금더부하를줄수있습니다. ( 더많은 RPC retransmission) * 패킷유실시의차이점비교 ( 실습 ) 85 / 88

86 NFS TCP Data Flow 제 3 장 : 실제소켓프로그램및분석툴의활용 NFS Client Server nfsd Client Socket Socket thread MSS chunks rsize, wsize 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 시에정할수있습니다. 86 / 88

87 NFS UDP Data Flow 제 3 장 : 실제소켓프로그램및분석툴의활용 NFS Client Server nfsd Client Socket Socket thread IP fragments rsize, wsize 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 의값으로설정됩니다. 87 / 88

88 Q&A 감사합니다. 88 / 88