TCP 응답속도를 체크하여 성능 측정을 해보자.

네트워크 트래픽의 요청과 응답의 지연되는 속도를 계산하여 퍼포먼스 성능 개선에 이용할 수 있는 'tcprstat' 도구를 소개한다. tcprstat 는 Percona 에서 개발한 것으로 무료로 사용할 수 있다. 출력되는 내용은 *NIX 시스템에서 사용하던 vmstat, iostat 와 비슷한 형태이다.
tcprstat 는 tcpstat 도구와 비슷하기도 하지만, 이것은 응답 시간 측정에 포커스를 두고 개발되어있으므로, 전체 네트워크 트래픽에 대한 것은 반영되어 있지 않다.

파일은 다음 경로에서 다운로드 받을 수 있다:
https://launchpad.net/tcprstat

바이너리 64비트 버전:
http://github.com/downloads/Lowercases/tcprstat/tcprstat-static.v0.3.1.x86_64

실행하면 다음과 같은 형태로 출력된다.

# ./tcprstat -p 27017 -t 1 -n 0
timestamp count max min avg med stddev 95_max 95_avg 95_std 99_max 99_avg 99_std
1355270619 669 3116 202 298 290 143 445 284 84 475 291 88
1355270620 727 719 200 263 227 73 424 253 57 454 261 63
1355270621 714 802 201 286 291 81 434 276 69 448 283 73
1355270622 720 570 201 280 271 45 367 275 30 387 279 34
1355270623 729 2441 261 282 270 92 361 273 20 379 277 25
1355270624 713 906 261 290 273 53 371 282 29 390 286 32
1355270625 718 759 261 287 273 47 369 280 29 399 284 33
^C1355270626 419 811 263 298 274 58 374 292 42 388 295 47

-n 을 통해 얼마동안 반복할지 정의한 것으로 0은 무한대를 뜻한다. -t 로 1초마다 측정하고 -p 로 포트번호를 지정하였다. 응답된 쿼리 시간과 종료시간 정보를 포함하고 있다. 각 컬럼의 응답시간은 마이크로세컨드 단위이며, 95/99th percentile 정보도 포함되어 있다. 95 퍼센트의 평균 응답값이 계산된다면, 상위 5%는 제외되는 것으로 자세한 내용은 아래 참고를 살펴보기 바란다.

tcprstat 의 위키페이지에서 소개하고 있는 예를 살펴보면,

# tcprstat -f '%M\t%95M\t%99M\n' -p 3306 -t 1 -n 0
max 95_max 99_max
31221 411 3001
52721 495 2828
12173 507 1513

응답시간이 계산되어 출력되는데 처음 가장 긴 응답시간은 31221 마이크로세컨드 이다. 95% 응답시간은 411 마이크로세컨드 이하이며 99%는 3001 이다.

가장 기본적인 옵션은 -p, -i, -n 정도이며 다음과 같은 포맷코드를 이용하여 출력을 정의할 수 있다.

Format Code	Header	Default	Meaning
%n	count	y	Count of requests that completed during this iteration
%a	avg	y	Average response time
%s	sum	y	Sum of response times
%x	sqs		Sum of squares of response times
%m	min	y	Minimum response time
%M	max	y	Maximum response time
%h	med	y	Median response time
%S	stddev	y	Standard deviation of response times
%v	var		Variance of response times
%I	iter#		Iteration number
%t	elapsed		Seconds elapsed since the first iteration
%T	timestamp	y	Unix timestamp
%%			A literal %
\t			A tab character
\n			A newline character
95,99	Adds a prefix	y	A percentile indicator; see later in this section for more

이외 -r 옵션을 이용해 PCAP 파일을 바로 분석할 수도 있다. 여러분들이 운영하는 서비스가 있다면 이 도구를 이용해 퍼포먼스 측정을 해보는 것도 유용할 것이다.

[참고]
1. Percona Tcprstat
http://www.percona.com/docs/wiki/tcprstat:start
2. Tcprstat 다운로드
https://github.com/Lowercases/tcprstat/downloads
3. Wikipedia Percentile
http://en.wikipedia.org/wiki/Percentile

리눅스 3.7 커널 릴리즈: TCP Fast Open, vxLan 지원

리눅스 3.7 커널이 12월10일에 릴리즈 되었다. 이번 릴리즈는 ARM 64비트 아키텍쳐를 지원하고 서명된 커널 모듈, Btrfs 파일시스템 업데이트, strace 후의 새로운 "perf trace" 도구, 서버측면의 TCP Fast Open 기능, 안정적인 NFS 4.1 등 많은 기능이 업데이트 되었다.

눈에 띄는 변화는 ARM 멀티 플랫폼과 64 비트 지원이다. 싱글 ARM 커널 이미지로 여러 하드웨어에서 부팅이 가능해 졌다. ARM 플랫폼을 지원하도록 배포할때 더욱 쉬워지게 된 것이다.

보안적으로는 서명된 커널모듈을 지원해서, 올바르게 서명되지 않은 모듈은 커널에 로드하지 못하도록 한 것이다. 이 기능은 루트킷등을 이용해 모듈을 추가할 수 없도록 해 보안적으로도 상당히 유용한 기능이다.

네트워크 관점으로 보면 서버 측면에서 TCP Fast Open 을 지원한다. 이미 이 기능은 3.6 커널에서 추가된 것이나 이번 릴리즈는 서버측을 지원하는 것이다. TCP 연결을 맺을때 "Fast Open" 은 더욱 최적화하여 페이지 로드시 4% ~ 41% 정도 속도 향상을 가져온다. 물론 사용되는 환경마다 다르지만 말이다. 이 기능은 추후 블로그에서 다시 한번 소개할 예정이다.

또한 SMBv2 를 지원하고(시험적인 기능) NFS 4.1 이 오랜 기간을 끝내고 드디어 안정 버전으로 릴리즈 되었다. NFS 4.1 의 주 기능은 pNFS 라 하여 패러랠 NFS 을 지원한다. 이로 인해 분산된 여러 서버들 간의 파일시스템에 패러랠한 접근이 가능하다. UDP 프로토콜을 통해 레이어 2 이더넷 패킷을 전송할 수 있는 터널링 프로토콜 vxlan 을 지원한다. vxlan 은 가상화된 환경에서 터널링된 네트워크 환경을 지원하는데 주로 이용된다. VLAN 은 4096 개로 제한되었지만 이것은 24bit 로 확장되어 훨씬 많은 개수를 지원하게 된다. 이것또한 블로그에서 추후 언급할 예정이다.

마지막으로 네트워킹 관점의 변화된 주요 내용은 다음과 같다

• loopback: set default MTU to 64K (commit)
• Providing protocol type via system.sockprotoname xattr of /proc/PID/fd entries (commit)
• Use a per-task frag allocator (commit)
• Netfilter
  • Add protocol-independent NAT core (commit)
  • Add IPv6 MASQUERADE target (commit)
  • Add IPv6 NETMAP target (commit)
  • Add IPv6 REDIRECT target (commit)
  • Add IPv6 NAT support (commit)
  • Support IPv6 in FTP NAT helper (commit)
  • Support IPv6 in IRC NAT helper (commit)
  • Support IPv6 in SIP NAT helper (commit)
  • Support IPv6 in amanda NAT helper (commit)
  • Add stateless IPv6-to-IPv6 Network Prefix Translation target (commit)
  • Remove xt_NOTRACK (commit)
• Near Field Communication (NFC): Add an Link Layer Control (LLC) Core layer to HCI (commit), add an shdlc llc module to llc core(commit), LLCP raw socket support (commit)
• bonding: support for IPv6 transmit hashing (and TCP or UDP over IPv6), bringing IPv6 up to par with IPv4 support in the bonding driver (commit)
• team: add support for non-Ethernet devices (commit)
• gre: Support GRE over IPv6 (commit), add GSO support (commit), add GRO capability (commit)
• packet: Diag core and basic socket info dumping (commit)
• ethtool: support for setting MDI/MDI-X state for twisted pair wiring (commit)
• ppp: add 64-bit stats (commit)
• Add generic netlink support for tcp_metrics (commit)

[참고]
1. 리눅스 커널 3.7 릴리즈
http://kernelnewbies.org/Linux_3.7

윈도우에서 네트워크 드라이버 설정 정보 보기 (TOE, 점보프레임등 확인)

저번 TOE(TCP Offload Engine) 포스팅 이후 윈도우에서 TOE 를 사용하고 있는지 확인할 수 있는 방법에 대한 문의가 있었다. 이에 기본적으로 윈도우에서 네트워크 드라이버 설정 정보를 보는 방법에 대해 간단히 알아보고, TOE 설정 유무도 알아보고자 한다.

우선 네트워크 연결 속성에서 이더넷 카드를 선택해야 하는데, 다음 화면과 같이 로컬영역 연결 상태에서 '속성'을 눌러서 로컬 영역 연결 속성을 보거나 또는 제어판에서 네트워크 및 공유 센터의 메뉴를 통해서 접근할 수 있다.

로컬 영역 연결 속성에서 연결에 사용할 장치가 보인다. 이미지에서는 RealTek PCIe 콘트롤러가 보인다. '구성 (C) ' 을 누르면 아래와 같은 창이 보이고 여기서 '고급' 탭을 누르면 해당 이더넷 카드에 대한 속성을 볼 수 가 있다.

여기서는 이더넷 카드에 대한 몇 가지 속성을 변경할 수 있는 오프로드 뿐만 아니라, WakeOn 및 일전에 언급하였던 점보 프레임에 대한 값 등을 정의할 수 있다.

여기서 각 오프로드 값 속성을 변경하면 된다. 또 netsh 를 통해 TCP 글로벌 매개 변수도 아래와 같이 살펴볼 수 있다.

C:\>netsh int tcp show global
활성 상태 쿼리하는 중...


TCP 글로벌 매개 변수
----------------------------------------------
받는 쪽 배율 상태                    : enabled
Chimney 오프로드 상태                : automatic
NetDMA 상태                          : enabled
DCA(직접 캐시 액세스)                : disabled
수신 창 자동 조정 수준               : normal
추가 정체 제어 공급자                : none
ECN 기능                             : disabled
RFC 1323 타임스탬프                  : disabled
** 위의 autotuninglevel 설정은 하나 이상의 프로필에 대한 로컬/정책 구성이 Window
s 배율
추론으로 다시 정의된 데 따른 결과입니다.

결과중 Chimney 오프로드 상태가 TOE 를 가르킨다고 보면 된다. 윈도우 7 환경에서는 자동으로 설정이 되어 있지만 만약 항상 활성화 시키기 위해서는 enabled 값을 사용하면 된다. 물론 중지하기 위해서는 disabled 로도 재 설정이 가능하다. 다음과 같이 설정하면 되는데, 일반 사용자 권한으로 실행시에는 다음과 같은 실행 에러를 만나게 된다.

C:\>netsh int tcp set global chimney=enabled


IPv4에서 global 설정 명령을 실행하지 못했습니다. 요청한 작업을 수행하려면 권한
상승(관리자 권한으로 실행)이 필요합니다.

도스 실행창을 관리자 권한으로 실행 후 다시 값을 설정한다.

C:\Windows\system32>netsh int tcp set global chimney=enabled
확인됨


C:\Windows\system32>netsh int tcp show global
활성 상태 쿼리하는 중...


TCP 글로벌 매개 변수
----------------------------------------------
받는 쪽 배율 상태                    : enabled
Chimney 오프로드 상태                : enabled

자 이렇게 설정을 하였는데, TOE 가 정말 이용되고 있는 것일까에 대한 의문이 생긴다. 이때는 'netstat -t' 명령어로 오프로드 상태를 볼 수 있다.  오프로드 상태에 InHost 라고 보이는 것은 현재 오프로드 상태가 아니라는 것이다. 오프로드의 상태라면 Offload 라고 표시될 것이다.

C:\>netstat -t


활성 연결


  프로토콜  로컬 주소              외부 주소              상태            오프로
드 상태


  TCP    192.168.40.2:1032      222.122.199.23:http    CLOSE_WAIT      InHost


  TCP    192.168.40.2:1038      tx-in-f125:5222        ESTABLISHED     InHost


  TCP    192.168.40.2:1039      38.126.11.28:http      CLOSE_WAIT      InHost


  TCP    192.168.40.2:2261      tb-in-f191:http        ESTABLISHED     InHost  (이하 삭제) 

필자의 데스크탑의 인터페이스는 부분적으로만 오프로드를 지원하여 InHost 상태로만 나오고 있다. 또는 여러 서비스와의 종속되는 다른 이슈들로 인하여 오프로드 상태가 Fail 될 수도 있다고 한다. 오프로드를 지원하는데도 불구하고 안된다면 BFE(Base Filtering Engine) 서비스를 중지해 보기를 바란다. 다만 서비스 중지로 인한 다른 것들은 감수해야 한다.

C:\> net stop BFE

윈도우 환경에서 TOE 상태가 잘 나타나는 분들은 경험을 댓글로 공유해 주길 부탁드립니다.


[참고]

1. Using Netsh Commands to Enable or Disable TCP Chimney Offload

http://technet.microsoft.com/en-us/library/gg162682(v=ws.10).aspx

2. Windows Server 2008 TCP Chimney 오프로드, 수신측 배율 및 네트워크 직접 메모리 액세스 기능에 대한 정보

http://support.microsoft.com/kb/951037

이더넷상의 프로토콜 오버헤드는 얼마나 될까?

네트워크 상에서의 프로토콜 오버헤드에 대한 글이 있어서 소개해 본다. 우리가 사용하고 있는 이더넷과 프로토콜 스택상에서 얼마나 빨리 전송할 수 있을지, 얼마나 많은 대역폭을 사용하는지 가늠해 볼 수 있다. 다음은 프로토콜 오버헤드를 이더넷, 기가비트 이더넷, ATM, POS 등으로 나누어 소개한 자료이다.

주소 : http://sd.wareonearth.com/~phil/net/overhead/

예를 들어 이더넷의 프레임 포맷을 살펴보면,

• 6 바이트 목적지 주소
• 6 바이트 출발지 주소
• 필요시 이용되는 4바이트의 802.1q VLAN 태그 (옵션)
• 2 바이트 길이/타입
• 46-1500 바이트 데이터 (페이로드)
• 4 바이트 CRC

로 구성되어 있다. 이더넷의 오버헤드 요소를 살펴보면 ,

  12 gap + 8 preamble + 14 header + 4 trailer = 38 bytes/packet w/o 802.1q
  12 gap + 8 preamble + 18 header + 4 trailer = 42 bytes/packet with 802.1q

로 된다. VLAN 태그가 없이도 38 바이트 사용하는 경우 42 바이트가 된다. 이더넷 페이로드를 포함한 데이터 비율은 다음과 같이 된다:

  1500/(38+1500) = 97.5293 %   w/o 802.1q tags
  1500/(42+1500) = 97.2763 %   with 802.1q tags

1) 이더넷상의 TCP 전송

 헤더 압축은 없다고 가정
 IPv4 헤더에 20 바이트 또는 IPv6 헤더에 40 바이트 추가
 TCP 헤더 20 바이트 추가
 TCP 타임스탬프 옵션 값 12 바이트 추가
 이더넷을 통한 최대 TCP 페이로드 데이터 전송률은 다음과 같다:

  (1500-40)/(38+1500) = 94.9285 %  IPv4, minimal headers
  (1500-52)/(38+1500) = 94.1482 %  IPv4, TCP timestamps
  (1500-52)/(42+1500) = 93.9040 %  802.1q, IPv4, TCP timestamps
  (1500-60)/(38+1500) = 93.6281 %  IPv6, minimal headers
  (1500-72)/(38+1500) = 92.8479 %  IPv6, TCP timestamps
  (1500-72)/(42+1500) = 92.6070 %  802.1q, IPv6, ICP timestamps

2) 이더넷상의 UDP 전송

 IPv4 헤더에 20 바이트 또는 IPv6 헤더에 40 바이트 추가
 UDP 헤더 8바이트 추가
 이더넷을 통한 최대 UDP 페이로드 데이터 전송률은 다음과 같다:

  (1500-28)/(38+1500) = 95.7087 %  IPv4
  (1500-28)/(42+1500) = 95.4604 %  802.1q, IPv4
  (1500-48)/(38+1500) = 94.4083 %  IPv6
  (1500-48)/(42+1500) = 94.1634 %  802.1q, IPv6

이렇게 소개하고 있다. 이외 기가비트 이더넷은 점보 프레임을 사용하는 경우 최대 전송은 990.042 Mbps 이며, 점보 프레임 없이는 941.482 Mpbs 이다. 이론적으로만 보면 점보 프레임을 사용하는 경우가 전송률 면에서 더 유리하다. 점보프레임은 얼마전 블로그에서 소개한 적이 있으니 참고해 보길 바란다.

프로토콜 오버헤드를 참고 삼아 알아두면 좋을것 같다.

[참고]
1. Protocol Overhead
http://sd.wareonearth.com/~phil/net/overhead/
2. 점보프레임(Jumbo Frame)으로 전송속도 높이기
http://www.packetinside.com/2012/03/jumbo-frame.html

TCP 3 Way 핸드쉐이크의 사랑이란?...

오늘은 TCP 3 Way HandShake 의 과정을 이용하여 '사랑' 을 표현한 재미있는 만화 하나를 소개하고자 한다.

TCP가 UDP 와 다른점이 신뢰성 이다. UDP 는 패킷을 보내고 이것이 제대로 전달되었는지 확인하지 않는다.

그런데, TCP 는 3 Way 핸드쉐이크라는 과정을 거친다. UDP 보다 좀더 신뢰성이 있는 통신을 하는 것이다. 아래 이미지를 보면 SYN 을 보내고 SYN+ACK 를 받고 ACK 를 보내면서 통신 연결이 이뤄진다.

이미지출처 : www.tcpipguide.com

이러한 과정을 이용해 '사랑'을 표현한 것으로 한번 살펴보자. 남자가 SYN 을 보내고 여자는 이에 대한

대답으로 SYN-ACK 를 보낸다. 남자는 다시 ACK 를 보내고 환호한다. 데이트하기 위한 첫 과정은

성공했다 생각했을 것이다. 기뻐하는 것도 잠시, 여자가 RST 를 보내 단호히 거절한다. 그 후 남성의 표정은

확 바뀐다. 마지막 문구를 보면 TCP 를 비록 사용한다고 하더라도 사랑은 신뢰될 수 없단다.

이 그림을 보고 얼마나 웃음이 나오던지. TCP를 이해하고 있는 사람이라면 왜 웃음이 나오는지

금방 이해가 될 것이다.  ^.^

출처 : http://blog.ksplice.com/2010/04/dating-is-rough-at-the-transport-layer/