728x90

출처 : https://blog.xenomity.com/Summary-Java-Agent-Bytecode-Instrumentation/

Summary Java Agent (Bytecode Instrumentation)

OverviewJava SE 5 에서 Bytecode Instrumentation의 범주로 새롭게 소개된 ‘Java Agent’ 명세에 대하여 간단히 소개하고자 한다. (* 일반적인 Agent 의미와 혼용되지 않는다.)

blog.xenomity.com

What are Java(JVM) Agent?
JVM Agent는 JVM에서 동작하는 Java 어플리케이션으로 JVM의 다양한 이벤트를 전달받거나 정보 질의, 바이트 코드 제어 등을 특정 API(Instrumentation API -java.lang.instrument-)를 통하여 수행할 수 있다.

보통 개발 도구 또는 모니터링 도구 개발에 응용된다.

바이트 코드 변조를 통한 개발의 편의성을 제공하는 AspectJ의 LTW(Load Time Weaver)나 Lombok과 같은 오픈소스가 대표적인 Java Agent의 활용 예이다.

Features
Agent는 지정된 JVM의 실행 가능한 최초 진입점인 ‘main’ 메서드를 가로채기 할 수 있다.
지정된 JVM에서 실행된다.
지정된 JVM의 동일한 System Class Loader 내에서 로드된다.
지정된 JVM의 Security Policy 및 Context의 영향을 받는다.
실행시간에 동적으로 bytecode를 조작할 수 있다.

Agent의 단일 진입점은 위와 같이 ‘premain’ 메서드를 구현하면 되며 바이트 코드를 포함한 추가적인 정보 수집 도구로 Instrumentation 인터페이스를 제공받을 수 있다.

728x90
728x90

출처 : https://m.blog.naver.com/PostView.nhn?blogId=rbtjqtjql&logNo=220993460343&proxyReferer=&proxyReferer=https:%2F%2Fwww.google.com%2F

BCI ( Byte Code Instrumentation ) in Java

이 글은 네이버 블로그 "욱짜 (ukja)" 님의 블로그 포스팅을 정리한 글이다. 출처는 아래를 참조한다. 출처...

blog.naver.com


■ BCI (Byte Code Instrumentation) ?
Java의 Byte Code에 직접 수정을 가해서, 소스 파일의 수정 없이 원하는 기능을 부여하는 기법
이러한 특징때문에 대부분의 Java 프로파일러나 모니터링 툴들이 BCI 기능을 사용하고 있다. Bytecode를 직접 수정할 수 있으므로 이를 통해 구현할 수 있는 기능은 무궁무진함.

■ Java Bytecode
JVM에서 인지할 수 있는 일종의 기계어(Machine Code)이며, 특정 OS / HW에 의존하지 않는, JVM에만 의존적이기 때문에 서로 다른 환경에서도 하나의 Bytecode로 구동이 가능(JVM은 공통이니까!!)

■ BCI를 활용하여 내가 생성한 클래스 파일 사용하게 하기
ClassReader 객체를 이용해 원래 클래스의 바이트 코드를 읽어들인다.
ClassAdapter 객체를 이용해 바이트 코드를 변경한다.
ClassWriter 객체를 이용해서 변경된 바이트 코드를 얻는다.

원래의 Exception 클래스를 변경(하진 않았지만)하여 새로운 Exception 클래스를 생성하고 파일을 확인하였다.

문제는 어떻게 하면 JVM의 rt.jar에서 제공하는 java.lang.Exception 클래스 파일이 아닌, 내가 생성한 Exception 클래스 파일을 쓰게 하느냐이다.

rt.jar파일을 직접 변경시킬순 없고 (매우 위험하고 법적인 문제가 될 수 있음!) 답은 -Xbootclasspath 옵션을 이용하는 것이다.

즉, -Xbootclasspath/p:<내가 작성한 Exception Class의 path>를 지정하면, JVM은 rt.jar보다 먼저(prepend) 내가 작성한 Exception Class 파일을 읽어들인다.

이렇게 함으로써 rt.jar 파일에 대한 수정을 가하지 않아도 된다.

728x90
728x90

클라이언트가 웹서버를 통해 큰 용량의 파일을 다운로드 할 때, 네트워크의 높은 사용률로 인해 부담이 될 수 있음.

웹서버에서 다운로드 할 파일을 압축하여 보냄으로써 네트워크의 부하를 줄여줄 수 있으며, 사용자의 응답시간을 줄일 수 있음.

※ 압축을 함으로써 웹서버의 자원사용률(CPU)는 가중됨.

 

■ 설정

 WEBTOB의 설정파일(http.m)에 다음과 같이 설정

  *SERVER

    Compress = [압축할 mime-type , 응답헤더의 Content-Type]

   EX) html  SVGNAME=htmlg, Minporc=10, Maxproc=10, Compress = "text/javascript"

※ WEBTOB 4.1.9.1 부터 사용 가능

 

로깅 설정에서 아래의 Format 설정 시 압축률 확인 가능

Format = "%z",

 

 

 

728x90
728x90

HP-UX의 TCP Trace Dump는 nettl이라는 command로 제공

■ nettl 사용방법

$ nettl -stop
$ nettl -start
$ nettl -tn pduin pduout -e all -f [파일경로]
~ ~ 30초 경과
$ nettl -tf -e all


■ nettl command option
tn : trace on
tf : trace off
pduin : inbound protocol data unit
pduout : outbound protocol data unit
e : entity subsystem
e all: all subsystem
tm : trace max size
m : trace 기록에서 byte 수
n : 파일 개수 지정
f : 캡쳐한 바이너리를 저장할 파일을 지정하는 옵션

TCP Trace Dump는 어마어마한 양의 Data가 기록됨.
이를 해석하기 위해 Filter라는 옵션을 제공
자신이 원하는 Data만 수집할 수 있는 기능
임의의 filter파일을 만들어 옵션을 지정합니다.
덤프를 서버상에서 확인하는 명령어는 netfmt를 사용.

■ 서버상에서 TCP Dump 내용 확인하기

1. 캡쳐 파일에서 모든 패킷에 1-liner trace 분석 파일을 만듭니다
 

$ netfmt -Nnl1f /tmp/nfssvr.TRC0 > /tmp/trace.txt


2. 캡쳐 파일에서 모든 패킷의 자세한 trace 분석결과를 만듭니다
 

$ netfmt -Nnlf /tmp/nfssvr.TRC0 > /tmp/trace.txt


3. 패킷 필터를 사용하여 1-liner trace 분석 파일을 만듭니다.

  $ netfmt -Nnl1c /tmp/filterfile -f /tmp/nfssvr.TRC0 > /tmp/trace.txt


■ netfmt 패킷 필터를 활용한 내용 확인하기
1. nettl trace를 구동하는 호스트에 의해 IP 어드레스로 전송되거나 수신되는 패킷을 보려면
   filter ip_saddr 192.6.2.1
   filter ip_daddr 192.6.2.1

2. nettl trace를 구동하는 호스트에 의해 이더넷 어드레스로 전송되거나 수신되는 패킷을 보려면
   filter source 08-00-09-00-12-3c
   filter dest 08-00-09-00-12-3c

3. trace를 하고 있는 호스트로 전송되거나 수신되는 패킷을 보려면
  NFS 패킷을 보려면
   filter udp_sport 2049 /* UDP port 2049 = nfsd */
   filter udp_dport 2049 /* UDP port 2049 = nfsd */

4. trace를 하고 있는 호스트로 전송되거나 수신되는 패킷을 보려면
  텔넷 패킷만을 보려면
   filter tcp_sport 23 /* TCP port 23 = telnet */
   filter tcp_dport 23 /* TCP port 23 = telent */

※주의: 다중 필터가 사용되면, 논리적으로 " AND"되고 "OR"되지 않습니다
        filter ip_saddr 192.6.2.1
        filter ip_daddr 192.6.2.1
        filter tcp_sport 23 /* TCP port 23 = telnet */
      이 필터는 ip 어드레스 192.6.2.1을 갖는 시스템으로/에서 오직 텔넷 커넥션 요청을 포맷할 것입니다

"진행중인" 패킷 관찰을 위해서는
"진행중인" 패킷 관찰을 위한 nettl_netfmt 운영 방법:
다음 명령어가 스크린에 trace 파일로 표시하고, 출력을 파일로 만듭니다. -e 파라미터로 드라이버를 지정할 수 있습니다:

$ nettl -tn 0x30800000 -e all | netfmt -FNnlc /tmp/filterfile | tee /tmp/fmt0


 trace를 정지하기 위해서는
위에 시작된 nettl 명령어에 CTRL/C를 누르고 나서,

 $ nettl -tf -e all


포맷된 trace 파일은 /tmp/fmt0 파일이 됩니다. 이때 만들어진 어떤 raw파일도 없습니다.

728x90
728x90

출처 : https://waspro.tistory.com/106

1. HP-UX

$ glance


> glance Command 창에서 s를 누른 후 CPU를 점유중인 pid를 입력
> Process 정보창에서G(shift+g)를 누른 후 Thread 별로 CPU 사용량 확인가능(space로 다음페이지 확인 가능)
> Thread 정보의 TID와 Thread Dump의 lwpid와 맵핑해서 확인 할 수 있다.

2. Linux

$ top -h


> 여기서 pid는 Thread ID
> Thread Dump의 nid와 Pid 값을 16진수로 변환해 일치하는 값을 확인

728x90
728x90

JEUS6에서 세션 클러스터링 구성 시 주의사항
1. WEBMain.xml 의 <web-container><context-group><session-config><distributable> 값이 반드시 true일 것
default값이 false이며, false 일 경우 분산식 세션매니져로 동작하게 된다. 따라서 자동으로 stickysession이 활성화 됨.
2. WEBMain.xml 의 <web-container><context-group><session-config><shared>
하나의 컨테이너에 다수의 context(application)사용 시 세션공유를 위해서는 해당옵션 값이 true여야 한다.
default 값 : false

728x90
728x90

개요
 JEUS 6008 에서 session.setMaxInactiveInterval 메소드를 통해 세션타임 무한대 설정을 하고도 서비스 세션이 유지되지 못하고 요청마다 새로이 생성됨

현상
 JEUS 6008 에서 서비스 세션이 요청마다 새로이 생성됨

원인
  session.setMaxInactiveInterval(-1) 를 통해 세션타임을 무한대로 유지한다는 설정을 하였으나,
JEUS 세션서버에서는 해당메소드의 값(-1)을 받으면 로컬에서 세션정보를 가지고 있다는 것으로 판단하여 해당 세션을 세션서버에서 삭제함

해결방안
web.xml의 session-timeout 설정을 통해 세션 타임관리를 하는 것이 좋음.
session.setMaxInactiveInterval 메소드를 사용한다면 session-timeout값과 맞출 것(무한대인 -1은 사용하지 말 것)
※ 해당문제는 JEUS 6008에서만 발생
JEUS 6009부터는 session.setMaxInactiveInterval(-1)이 지정되면 JEUSMain.xml의 <removal-to> 값만큼만 세션서버에서 해당 세션을 유지
  ※removal-to : file-db에 저장된 session 객체의 보존 기간을 지정하는 값

728x90

'IT > MiddleWare(WEB WAS)' 카테고리의 다른 글

[WEBTOB]Compression 설정  (0) 2020.12.17
[JEUS] 6버전 세션클러스터 구성 시 주의사항  (0) 2020.12.04
[WEBTOB]HSTS 설정  (0) 2020.11.23
[JEUS]jsper jsp파서 사용  (0) 2020.11.11
[MW]미들웨어 구성 시 유의사항  (0) 2020.11.05
728x90

출처 : b.luavis.kr/server/linux-performance-analysis

1. uptime

$ uptime
 23:51:26 up 21:31, 1 user, load average: 30.02, 26.43, 19.02


uptime은 현재 대기중인 프로세스가 얼마나 있는지를 나타내는 load average값을 확인하는 가장 쉬운 방법이다. 리눅스 시스템에서 이 값은 대기 중인 프로세스뿐만 아니라 disk I/O와 같은 I/O작업으로 block된 프로세스까지 포함되어 있다. 이를 통해서 얼마나 많은 리소스가 사용되고 있는지 확인할수 있지만, 정확하게 이해할 수는 없다.
위에 있는 3개의 숫자는 각각 1분, 5분, 15분에 load average 값이다. 이를 통해서 시간의 변화를 알 수 있는데, 예를들어서 장애가 발생했다는 소식을 듣고 해당 instance에 로그인 했을때 1분 동안의 값이 15분 값에 비해서 작다면 이는 장애가 발생하고선 내가 너무 뒤늦게 로그인했음을 알 수 있다. 위 예제에서는 1분 값이 약 30이고 15분 값이 19정도 되는것으로 볼때 최근에 상승한것을 알 수 있다. 여기서 숫자가 이 만큼 높은 것은 많은 의미를 갖고 있다. 

2. dmesg | tail

$ dmesg | tail
[1880957.563150] perl invoked oom-killer: gfp_mask=0x280da, order=0, oom_score_adj=0 [...]
[1880957.563400] Out of memory: Kill process 18694 (perl) score 246 or sacrifice child
[1880957.563408] Killed process 18694 (perl) total-vm:1972392kB, anon-rss:1953348kB, file-rss:0kB
[2320864.954447] TCP: Possible SYN flooding on port 7001. Dropping request. Check SNMP counters.


dmesg는 시스템 메세지를 확인할 수 있는 커맨드이다. 부팅시부터 시작해서 모든 커널메세지가 출력되기 때문에 tail을 이용해서 마지막 10줄만 출력한것이다. 이 메세지를 통해서 성능에 문제를 줄 수 있는 에러를 찾을 수 있는데 위의 예제에서는 oom-killer(out of memory)와 TCP request가 드랍된것을 알 수 있다.

3. vmstat 1

$ vmstat 1
procs ---------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
34 0 0 200889792 73708 591828 0 0 0 5 6 10 96 1 3 0 0
32 0 0 200889920 73708 591860 0 0 0 592 13284 4282 98 1 1 0 0
32 0 0 200890112 73708 591860 0 0 0 0 9501 2154 99 1 0 0 0
32 0 0 200889568 73712 591856 0 0 0 48 11900 2459 99 0 0 0 0
32 0 0 200890208 73712 591860 0 0 0 0 15898 4840 98 1 1 0 0 


virtual memory stat의 약자인 vmstat은 왠만한 환경에서 사용 가능한 툴이다. 1을 인자로 준 vmstat은 1초마다 정보를 보여준다. 첫번째 라인은 부팅된 뒤에 평균적인 값을 나타낸다.
 
확인해봐야할 항목

  • r: CPU에서 동작중인 프로세스의 숫자입니다. CPU 자원이 포화(saturation)가 발생하는지 확인. r 값이 CPU의 값보다 큰 경우에 포화되어 있다고 해석
  • free: free memory를 kb단위로 나타냅니다. free memory가 너무 자리수가 많은 경우 free -m를 이용하면 조금더 편하게 확인할 수 있다.
  • si, so: swap-in과 swap-out에 대한 값입니다. 0이 아니라면 현재 시스템에 메모리가 부족한것이다.
  • us, sy, id, wa, st: 모든 CPU의 평균적인 CPU time을 측정할 수 있다. 각각 user time, 커널에서 사용되는 system time, idle, wait I/O 그리고 stolen time순이다(stolen time은 hypervisor가 가상 CPU를 서비스 하는 동안 실제 CPU를 차지한 시간을 이야기한다.).

4. mpstat -p ALL 1

$ mpstat -P ALL 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
07:38:49 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
07:38:50 PM all 98.47 0.00 0.75 0.00 0.00 0.00 0.00 0.00 0.00 0.78
07:38:50 PM 0 96.04 0.00 2.97 0.00 0.00 0.00 0.00 0.00 0.00 0.99
07:38:50 PM 1 97.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 2.00
07:38:50 PM 2 98.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00
07:38:50 PM 3 96.97 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 3.03


이 커멘드는 CPU time을 CPU 별로 측정할 수 있다. 이 방법을 통하면 각 CPU별로 불균형한 상태를 확인할 수 있는데, 한 CPU만 일하고 있는것은 application이 single thread로 동작한다는 이야기다.

5. pidstat 1

$ pidstat 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
07:41:02 PM UID PID %usr %system %guest %CPU CPU Command
07:41:03 PM 0 9 0.00 0.94 0.00 0.94 1 rcuos/0
07:41:03 PM 0 4214 5.66 5.66 0.00 11.32 15 mesos-slave
07:41:03 PM 0 4354 0.94 0.94 0.00 1.89 8 java
07:41:03 PM 0 6521 1596.23 1.89 0.00 1598.11 27 java
07:41:03 PM 0 6564 1571.70 7.55 0.00 1579.25 28 java
07:41:03 PM 60004 60154 0.94 4.72 0.00 5.66 9 pidstat
07:41:03 PM UID PID %usr %system %guest %CPU CPU Command
07:41:04 PM 0 4214 6.00 2.00 0.00 8.00 15 mesos-slave
07:41:04 PM 0 6521 1590.00 1.00 0.00 1591.00 27 java
07:41:04 PM 0 6564 1573.00 10.00 0.00 1583.00 28 java
07:41:04 PM 108 6718 1.00 0.00 0.00 1.00 0 snmp-pass
07:41:04 PM 60004 60154 1.00 4.00 0.00 5.00 9 pidstat


pidstat은 process당 top명령을 수행하는것과 비슷하다. 다만 차이점은 스크린 전체에 표시하는것이 아니라 지속적으로 변화하는 상황을 띄워주기 떄문에 상황변화를 기록하기 좋다.
위 예제를 보면 두개의 java process의 CPU 사용량이 엄청나다. %CPU 항목은 모든 CPU의 전체 사용량을 이야기한다. 따라서 1591%를 사용중인 java process들은 16CPU 가까이 사용중임을 나타내는것이다.

6. iostat -xz 1

$ iostat -xz 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
             73.96 0.00 3.73 0.03 0.06 22.21
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
xvda    0.00 0.23 0.21 0.18 4.52 2.08 34.37 0.00 9.98 13.80 5.42 2.44 0.09
xvdb    0.01 0.00 1.02 8.94 127.97 598.53 145.79 0.00 0.43 1.78 0.28 0.25 0.25
xvdc    0.01 0.00 1.02 8.86 127.79 595.94 146.50 0.00 0.45 1.82 0.30 0.27 0.26
dm-0   0.00 0.00 0.69 2.32 10.47 31.69 28.01 0.01 3.23 0.71 3.98 0.13 0.04
dm-1   0.00 0.00 0.00 0.94 0.01 3.78 8.00 0.33 345.84 0.04 346.81 0.01 0.00
dm-2   0.00 0.00 0.09 0.07 1.35 0.36 22.50 0.00 2.55 0.23 5.62 1.78 0.03


block device(HDD, SSD, …)가 어떻게 동작하는지 이해하기 좋은 툴이다.
 
확인해봐야할 항목

  • r/s, w/s rkB/s, wkB/s: read 요청과 write 요청, read kB/s, write kB/s를 나타낸다. 어떤 요청이 가장 많이 들어오는지 확인해볼 수 있는 중요한 지표다. 성능 문제는 생각보다 과도한 요청때문에 발생하는 경우도 있기 때문이다.
  • await: I/O처리 평균 시간을 밀리초로 표현한 값이다. application한테는 I/O요청을 queue하고 서비스를 받는데 걸리는 시간이기 때문에 application이 이 시간동안 대기하게 된다. 일반적인 장치의 요청 처리 시간보다 긴 경우에는 블럭장치 자체의 문제가 있거나 장치가 포화된 상태임을 알 수 있다.

7. free -m

$ free -m
            total used free shared buffers cached
Mem: 245998 24545 221453 83 59 541 -/+ buffers/cache: 23944 222053
Swap: 0 0 0


확인해봐야할 항목

  • buffers: Block 장치 I/O의 buffer 캐시, 사용량
  • cached: 파일 시스템에서 사용되는 page cache의 양

버퍼와 캐시 값들이 0에 가까워 지면 안된다. 이는 곧 높은 Disk I/O가 발생하고 있음을 의미한다(iostat으로 확인 가능). 위 예제는 버퍼와 캐시가 각각 59MB, 541MB로 괜찮은 정도에 속한다.
““-/+ buffers/cache”는 사용중인 메모리와 여유 메모리의 양을 나타낸다. 리눅스는 빠르게 다시 애플리케이션에 메모리가 할당될 수 있도록 캐시메모리를 사용한다. 따라서 캐시 메모리도 여유 메모리에 포함되어 보여야한다. 

8. sar -n DEV 1

$ sar -n DEV 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
12:16:48 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
12:16:49 AM eth0 18763.00 5032.00 20686.42 478.30 0.00 0.00 0.00 0.00
12:16:49 AM lo 14.00 14.00 1.36 1.36 0.00 0.00 0.00 0.00
12:16:49 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
12:16:49 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
12:16:50 AM eth0 19763.00 5101.00 21999.10 482.56 0.00 0.00 0.00 0.00
12:16:50 AM lo 20.00 20.00 3.25 3.25 0.00 0.00 0.00 0.00
12:16:50 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00


이 툴을 사용하면 network throughput(Rx, Tx KB/s)을 측정할수 있다. 위 예제에서는 eth0의 수신량이 약 22Mbytes/s(21999.10rxkB/s)이다. 이는 176Mbits/s인데 한계인 1Gbit/s에 아직 많이 못 미치는 값이다.
위 값중 %ifutil은 nicstat로도 측정 가능한 네트워크 장치 사용률이다. 하지만 nicstat에서도 그렇듯 정확한 값을 가져오는게 어려워서 위 예제에서도 잘 작동하지 않는다.

9. sar -n TCP,ETCP 1

$ sar -n TCP,ETCP 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
12:17:19 AM active/s passive/s iseg/s oseg/s
12:17:20 AM 1.00 0.00 10233.00 18846.00
12:17:19 AM atmptf/s estres/s retrans/s isegerr/s orsts/s
12:17:20 AM 0.00 0.00 0.00 0.00 0.00
12:17:20 AM active/s passive/s iseg/s oseg/s
12:17:21 AM 1.00 0.00 8359.00 6039.00
12:17:20 AM atmptf/s estres/s retrans/s isegerr/s orsts/s
12:17:21 AM 0.00 0.00 0.00 0.00 0.00


이 값은 TCP 통신량을 요약해서 보여준다.

  • active/s: 로컬에서부터 요청한 초당 TCP 커넥션 수를 보여준다 (예를들어, connect()를 통한 연결).
  • passive/s: 원격으로부터 요청된 초당 TCP 커넥션 수를 보여준다 (예를들어, accept()를 통한 연결).
  • retrans/s: 초당 TCP 재연결 수를 보여준다.

active와 passive 수를 보는것은 서버의 부하를 대략적으로 측정하는데에 편리하다. 위 설명을 보면 active를 outbound passive를 inbound 연결로 판단할 수 있는데, 꼭 그렇지만은 않다. (예를들면 localhost에서 localhost로 연결같은 connection)
retransmits은 네트워크나 서버의 이슈가 있음을 이야기한다. 신뢰성이 떨어지는 네트워크 환경이나(공용인터넷), 서버가 처리할 수 있는 용량 이상의 커넥션이 붙어서 패킷이 드랍되는것을 이야기한다. 위 예제에서는 초당 하나의 TCP 서버가 들어오는것을 알 수 있다.

10. top

$ top
top - 00:15:40 up 21:56, 1 user, load average: 31.09, 29.87, 29.92
Tasks: 871 total, 1 running, 868 sleeping, 0 stopped, 2 zombie
%Cpu(s): 96.8 us, 0.4 sy, 0.0 ni, 2.7 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 25190241+total, 24921688 used, 22698073+free, 60448 buffers
KiB Swap: 0 total, 0 used, 0 free. 554208 cached Mem
  PID USER    PR NI   VIRT    RES   SHR S %CPU %MEM     TIME+ COMMAND
20248 root     20 0  0.227t 0.012t 18748 S 3090  5.2  29812:58 java
 4213 root     20 0 2722544  64640 44232 S 23.5  0.0 233:35.37 mesos-slave
66128 titancl+ 20 0   24344   2332  1172 R  1.0  0.0   0:00.07 top
 5235 root     20 0 38.227g 547004 49996 S  0.7  0.2   2:02.74 java
 4299 root     20 0 20.015g 2.682g 16836 S  0.3  1.1  33:14.42 java


top 명령어는 위에서 체크해본 다양한 측정치를 쉽게 체크할 수 있다. 시스템 전반적으로 값을 확인하기 쉽다는 장점이 있다. 화면이 지속적으로 바뀌는 점 떄문에 패턴을 찾는것이 어렵다. 일시적으로 멈추는 현상을 잡기 위해서도 화면을 주기적으로 빠르게 멈춰주지 않으면 찾기 힘들다(Ctrl+S는 업데이트를 중지시키고, Ctrl+Q는 다시 시작시킨다), 그리고 화면이 지워져버린다.

728x90
728x90

1. HSTS (HTTP Strict Transport Security) 란?
일반적으로 HTTPS를 강제하게 될 때 서버측에서 302 Redirect 를 이용하여 전환(웹서버 설정을 통해)시켜 줄 수 있음. 하지만 이것이 취약점 포인트로 작용될 수 있다.

이러한 이유로 클라이언트 (브라우저) 에게 HTTPS를 강제 하도록 하는 것이 권장되는데, 이것이 HSTS (HTTP Strict Transport Security) 다. 클라이언트 (브라우저)에서 강제 하기 때문에 Plain Text (HTTP) 를 이용한 연결 자체가 최초부터 시도되지 않으며 클라이언트 측에서 차단된다는 장점이 있음. 

 

사용자가 최초로 사이트에 접속시도를 하게 되면 웹서버는 HSTS 설정에 대한 정보를 브라우저에게 응답하게 됨. 브라우저는 이 응답을 근거로 일정시간 (max-age) 동안 HSTS 응답을 받은 웹사이트에 대해서 https 접속을 강제화 함. (Response Header에 Strict-Transport-Security 값으로 존재)

 

 

크롬에서는 다음과 같은 명령어로 브라우저에 들어있는 HSTS값이 확인 가능

chrome://net-internals/#hsts

 

아래의 사이트에서 HSTS가 적용된 사이트인지 확인 가능

https://hstspreload.org

 

1.1. HSTS의 오점 

HSTS를 웹서버에서 리스폰스 헤더로 제공하는건 최초의 HTTP로 연결시에 HSTS 헤더가 내려오기전에 SSL 스트립이 가능한 문제가 여전히 존재. 따라서 웹페이지에 들어가지 않고도 브라우저 내장 preload를 갖추는게 가장 안전한데, 크롬 측에 조건 갖추고 제출하면 크롬 preload 리스트에 들어갈 수 있음. 크롬 리스트는 다른 브라우저도 공유함. // END

2. HSTS (HTTP Strict Transport Security) 의 설정방법
WEBTOB 설정파일(http.m)에서 다음과 같은 설정 추가
*HEADERS
HSTS ACTION="AddResponse",
FIELDNAME="Strict-Transport-Security",
FIELDVALUE="max-age=[시간ms]"
*VHOST
HEADERS="HSTS",

 

3. HSTS (HTTP Strict Transport Security) 를 이용한 SSL Strip 방어

MITM (Man in the Middle) 공격을 보안하기 위함. 일반적으로 TLS/SSL로 암호화 된 세션은 중간에서 공격자가 그 내용을 감청하더라도 암호화 되어 있기 때문에 데이터가 보호 될 수 있습니다. 따라서 MITM은 SSL Strip (SSL/TLS 로 암호화 된 세션을 강제로 암호화 하지 않은 HTTP 세션으로 유도) 을 통해 공격 

 

이러한 공격은 HSTS를 적용을 통해 SSL 연결을 강제화하여 방어 할 수 있음.

 

 

 

 

728x90
728x90

JEUS6
<commnad-option> -Djeus.servlet.jsp.modern=true </commnad-option>
 
- 오픈소스 등 웹 프레임워크를 보다 잘 지원하고 호환성 문제를 줄이기 위해서 톰캣 Jasper 기반의 JSP 파서를 사용

728x90

+ Recent posts