티스토리 툴바

Daum
Tistory
로그인
technology/server side | java2011/04/15 16:42

JAVA SSL 통신

매번 SSL 통신할 때마다 헷갈려서 이번에는 적어 놓는다...  (머리가 메모를 도저히 못 따라가는구나....)

I. 일반적인 웹서버 SSL 셋팅시
    -. 웹서버 또는 keytool, openssl 등을 통해서 개인키와 공개키를 생성한다. (keygen~)
        (자바에서는 keystore 생성도 포함)
    -. 생성된 공개키로 CSR 를 생성하고, 각 CA에게 전달
    -. CA로부터 전자서명된 인증서를 전달 받는다.
    -. 웹서버에 인증서와 개인키를 설정한다.
        개인키PEM으로 설정시에 간혹 PKCS#8 포맷 오류가 발생할 수 있다.
        이때 OpenSSL 사이트의 Example 참고
    -. 서버 인증서 뿐만 아니라 CA키도 함께 설정해야 한다.
    -. 개인키와 인증서를 PKCS#12로 묶어서 처리해야 하는 경우도 있는데,
        이때는 OpenSSL 등을 이용하자!!!  (자바의 keytool은 기본적으로 제공하지 않으므로, 별도 프로그램을 이용하자)
       

II. JAVA를 통한 SSL 통신
    -. 자바에서는 기본적으로 keystore를 사용하니깐, keystore를 하나 준비하고,
    -. 대상 SSL 사이트의 인증서를 keystore에 import 한다.
        ex) keytool -import -alias 별명 -keystore 키스토어파일 -file 불러들일 서버 인증서
    -. 그리고 자바 코드에서 해당 keystore에 로드한 인증서를 신뢰하겠다는 의미로 TrustKeySotre를 지정한다.
         ex) System.setProperty("javax.net.ssl.trustkeyStore", XXXX); ....
    -. 다음은 HttpsURLConnection을 이용하여 Connection을 얻어오고, In/OutputStream 처리하면 끝.
    -. 간혹 서버 인증서의 등록된 도메인과 서비스 도메인이 틀릴 경우가 왕왕 있는데...
       이럴때는 javax.net.ssl.HostnameVerifier.verify를 true로 리턴토록 처리해줘라...

저작자 표시
Posted by 승현아범
TAG https, Java, SSL, 웹서버
Trackback 0 Comment 3
technology/server side | java2010/12/13 18:32

SUN JVM Garbage Collection 관련 문서

Java HotSpot Garbage Collection
http://www.oracle.com/technetwork/java/javase/tech/index-jsp-140228.html


Diagnosing a Garbage Collection problem
http://www.oracle.com/technetwork/java/example-141412.html


Tuning Garbage Collection with the 5.0 Java[tm] Virtual Machine
http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html


Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning
http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html

저작자 표시
Posted by 승현아범
TAG GC, JVM, tuning
Trackback 0 Comment 0
technology/server side | java2010/11/17 21:23

JVM GC ReduceInitialCardMarks 옵션


  • Card-Marking Optimization Issue

  • A flaw in the implementation of a card-marking performance optimization in the JVM can cause heap corruption under some circumstances. This issue affects the CMS garbage collector prior to 6u18, and the CMS, G1 and Parallel Garbage Collectors in 6u18. The serial garbage collector is not affected. Applications most likely to be affected by this issue are those that allocate very large objects which would not normally fit in Eden, or those that make extensive use of JNI Critical Sections (JNI Get/Release*Critical).

    This issue will be fixed in the next Java SE 6 update.

    Meanwhile, as a workaround to the issue, users should disable this performance optimization by -XX:-ReduceInitialCardMarks.

    Refer to 6896647 and 6888898.

    • 저작자 표시
    Posted by 승현아범
    TAG GC, JVM, ReduceInitialCardMarks
    Trackback 0 Comment 0
    technology/server side | java2010/08/10 00:06

    부하테스트 및 최적화 작업

    요즘 부하테스트가 한창이다.
    부하테스트로 로드런너를 사용중인데, 이넘이 애를 먹여서 하루종일 헛탕만 쳤다.
    예전에는 그냥 그렇게 보이던 테스트가 내 사이트를 직접 테스트하려니 그냥 지나쳐지지가 않는다.
    TPS며, 처리시간, CPU, 메모리 등등 ... 리소스 하나하나가 내 피와 살 같다.

    테스트를 진행하며 몇가지 환경적인 제약으로 인해서 제대로 테스트가 안 되는 부분이 있는데,
    바로 네트웍이다.
    정상적인 테스트라면 DMZ 구간의 1G망에서 테스트를 하면 좋겠지만,
    여기 환경상 그렇지가 못하다.
    그래서 어쩔 수 없이 ISP업체의 100M bps 전용선을 가져다 쓰기로 했다.
    인터넷을 통한 부하테스트라...  영 찝찝하지만 ...  여기서 배운 것중에 하나가 주어진 환경에서 최선을 다한다... 아니겠는가...

    참... APM으로 제니퍼를 도입했는데, 생각보다 훌륭하다.
    JVM 환경하에서만 사용해야 한다는 단점이 있지만 JAVA 환경을 구성하고 있다면 꽤 쓸만하다.
    UI측면에서는 조금 더 가꿔가야 하겠지만 추천할만 하겠다.

    얼릉 얼릉 끝내고 ... 빨리 오픈했으면 바램 뿐이다.

    저작자 표시
    Posted by 승현아범
    TAG 로드런너, 부하테스트, 제니퍼
    Trackback 0 Comment 0
    technology/server side | java2009/08/04 17:15

    APM 뭘로 해야 선정해야 할까?

    이번에 기존 tmax로 구성된 시스템을 pure java 시스템으로 변경한다.
    apm 툴로 뭐를 사용해야 할까 고민중이다.
    제니퍼를 사용했으면 하는데 승인 받는게 만만치 않고, Wily 를 사용하자니 불안한 감이 있고, ...
    고민이다... 고민....
    저작자 표시
    Posted by 승현아범
    TAG APM, 자바, 프로젝트
    Trackback 0 Comment 0
    technology/server side | java2009/05/18 15:24

    JAVA 개발자 C 코딩하기

    정말 오랜만이다.
    C 코딩을 하게 된지가 ... (띄엄 띄엄 10년인가???)
    반면 자바에서의 String 의 강력함을 새삼 느끼게 됐다.
    출력 데이터에서 왜 쓰레기값이 포함되는지... (차라리 null 이었다면 좋았겠지만...)
    한참을 고민... 고민... 했다.
    그나마 빨리 찾아서 다행이었지만... 자바에 너무나 익숙해져버린 내 모습에...
    반쪽짜리 개발자라는 생각을 지울 수 없었다.

    포인터가 싫어서 옮겨간 자바인데... 
    아...  C ...  피해갈 수 없는 산인가 싶다...

    Posted by 승현아범
    TAG C, Java
    Trackback 0 Comment 0
    technology/server side | java2009/04/23 10:00

    Java Collection Performance

    다음글은 AaronZ Sakai 의 Java Collection Performance 을 가져왔습니다.

    This is just a helpful reference when trying to decide which collections to use in Java. I use this for my personal reference but it may help others as well. The links go to the Sun Javadocs. The collections of each type are ordered based on performance (i.e. the highest performance (highest speed) ones are listed first and will be the fastest for most operations)

    List - this is an ordered list of objects, insertion order is maintained and retrieval order is in the list order but items can also be random accessed, duplicate items are allowed, generally allow storage of null values (the ones below do), generally fast to iterate and find items by position but slow to do lookups
    • ArrayList - Unsychronized, nulls allowed (fastest)
    • Vector - Synchronized, only slightly slower in tests of sizes under 100000
    • Stack - Synchronized, same speed as Vector, LIFO queue
    • LinkedList - Unsynchronized, allows two way iteration and modification of items (like a stack or queue)
    • CopyOnWriteArrayList - Synchronized, significantly slower in tests of large numbers of items or average list changes, only slightly slower when used with very small numbers (<100)>


    Set - this a set of items with no duplicates (no two items can compare as equal), ordering is typically inconsistent over multiple set iterations depending on the implementation but you should assume the order is effectively random unless the set specifies ordered iteration, generally ok to iterate and fast to do lookups
    • HashSet - Unsychronized (fastest), slower than HashMap which it is built on, allows nulls
    • LinkedHashSet - Unsychronized, ordered by insertion, allows nulls
    • TreeSet - Unsychronized, ordered by the natural ordering of the items or a comparator provided at construction, allows nulls but there are issues with removing them
    • CopyOnWriteArraySet - Synchronized, significantly slower in tests of large numbers of items or average set changes, only slightly slower when used with very small numbers (<100)>


    Map - Stores key/value pairs (maps keys to values) where the keys must be unique, order of iteration over keys, values, or pairs is highly dependent on the implementation of the map, allowed nulls also vary by implementation, generally very fast to lookup keys and slow to lookup values
    • IdentityHashMap - Unsychronized (fastest), uses reference equality (==) instead of object equality (equals) to compare keys, actually violates the Map interface guarantee, all iterators are unordered, allows null keys and values
    • HashMap - Unsychronized, this is the fastest general purpose map, all iterators are unordered, allows null keys and values
    • ConcurrentHashMap - Synchronized, all iterators are unordered, does not allow null keys or values
    • Hashtable - Synchronized, all iterators are unordered, does not allow null keys or values
    • LinkedHashMap - Unsychronized, all iterators are ordered based on insertion order of the original key (does not change if a key is reinserted), allows null values but null keys are not allowed
    • TreeMap - Unsychronized, iterators are ordered by the natural or comparator ordering of the keys, allows null keys and values but the comparator needs to understand them

    Posted by 승현아범
    TAG Collection, Java, Performance
    Trackback 0 Comment 1
    technology/server side | java2009/03/20 21:09

    프레임워크 리팩토링

    간만에 리팩토링 관련 내용이 있어 포스팅한다.

    마이크로 소프트웨어 [2009년 3월호]
    1. 문제해결을 위한 리팩토링 노하우
    2. 애플리케이션 프레임워크 설계 원칙과 리팩토링
    3. 테스트 케이스 중심 회귀 테스트를 이용한 프레임워크 리팩토링
    4. 휴리스틱 프레임워크 리팩토링
    5. 이클립스를 활용한 프레임워크 리팩토링

    Posted by 승현아범
    TAG 리팩토링, 프레임워크
    Trackback 0 Comment 0
    technology/server side | java2009/02/11 13:33

    The * stupidest things I’ve done in my programming job

    나도 아래 ORM 뿐만 아니라 프레임웍을 만들려고 부단히도 애쓴 기억이 난다.

    2000년도 였던것으로 기억하는데... 그 때는 순수한 마음으로 여러 동료들과 레고 블럭을 만들듯이 개발하던게 어찌나 맘에 들던지...

    소스레벨 뿐만이 아닌 회사 개발 문서 또한 하나의 문서관리 프레임웍으로 취급하여 진행했었다.

    이제는 그러한 프레임웍 개발이 의미가 없게 느껴질 정도로 많은 프레임웍이 나와 있다.

    (특정 분야/기능에 대한 framework 제외)

    다음 기사는 ioannis cherouvim 에거 발췌한 내용입니다.


    I’m not ashamed of those sins any more, so here you go :)

    1. ORM

    Stupidity
        Building my own Object Relational Mapping framework.
    Consequence
        Project is a mess after 2 years of maintenance with hardcore hacks to bypass my own ORM and call custom SQL queries.
    What should I have done
        Use hibernate, iBATIS, Cayenne or something similar.

    2. EAV

    Stupidity
        Using an Entity-Attribute-Value model database schema design.
    Consequence
        Non scalable solution and total impossibility to run any useful queries on the database level.
    What should I have done
        Use an ordinary normalized database schema design.

    3. Database Access

    Stupidity
        Synchronize (serialize) database access using one shared connection.
    Consequence
        Zero scalability. Very slow response times when more than 10 users where using the application.
    What should I have done
        Don’t do that and use a connection pool such as c3p0 and use a “new” (reused) connection returned from the pool for every request/response cycle.

    4. IDE

    Stupidity
        Avoided learning and using an Integrated development environment.
    Consequence
        Inability to build test and deploy the application quickly and generally do anything useful.
    What should I have done
        Get familiar with an IDE. NetBeans, eclipse etc.

    5. Transactions

    Stupidity
        Not using them.
    Consequence
        Corrupt data in an application involving e-shop like functionality.
    What should I have done
        Use database transactions. When in MySQL use InnoDB.

    6. Prepared Statements

    Stupidity
        Using Statements, string concatenation and naive character escaping to assemble my own “safe” queries.
    Consequence
        SQL Injections possible in my application. I managed to login using ‘or 1=1;delete from users;? and alter the database state in a very nasty way.
    What should I have done
        Use Prepared Statements which correctly assemble and escape the query properly depending on the JDBC driver used.

    7. Business Logic

    Stupidity
        Doing it in the template (JSP).
    Consequence
        Messy non maintainable application.
    What should I have done
        Do it in an MVC style with servlets or with a Front Controller. Even better by using an existing open source MVC framework such as Struts, Spring MVC etc.

    Of course, all the bad choices above have probably made me a better programmer.


    Posted by 승현아범
    TAG Java
    Trackback 0 Comment 0
    technology/server side | java2009/01/28 14:26

    오픈소스의 저작권, 그리고 상용 SW 개발자가 반드시 지켜야 할 사항

    아래 내용은 앤디님의 블로그 에서 긁어온 일부 내용입니다. 전체 내용은 앤디님의 블로그를 참고하세요.

    소프트웨어 저작권의 시작
    컴 퓨터의 초창기 시절, 사용자가 곧 개발자인 시절이 있었습니다. 컴퓨터 애호가들은 서로가 작성한 코드를 펀치 테이프로 작성하여 나누던 시절입니다. 이 때 소프트웨어의 상품성에 눈을 뜨고 소프트웨어는 돈을 주고 사용해야 한다는 사람이 나타납니다. 그가 바로 빌 게이츠입니다.

    1976년 빌 게이츠는 친구 폴 앨런과 MITS Altair 8800을 위한 베이식 인터프리터를 만들었고, MITS를 통해 판매하였습니다. 그리고 이 소프트웨어는 동호인들에게 매우 인기가 높았죠.

    하 지만 곧 자신들의 소프트웨어가 복제되어 무상 배포되고 있는 것을 알게 되었고, 빌은 이에 분노하여 유명한 “Open Letter to Hobbyists”를 MITS 뉴스레터를 통해 공개합니다. 이 사건은 소프트웨어의 유료화라는 개념이 등장한 계기로 알려져 있습니다.

    이에 대해 많은 동호인들은 반감을 표시하거나, 말도 안 되는 소리 등으로 치부하기도 했습니다만 빌은 꿈쩍도 하지 않았죠. 개인용 컴퓨터 시장이 성숙하고 프로 개발자들이 등장함에 따라, 결국 소프트웨어는 돈을 주고 사야 하는 것의 지위를 차지하게 됩니다.

    자유 소프트웨어의 등장과 GPL
    그 후 대부분의 소프트웨어 개발사는 자신의 코드를 철저하게 숨기고, 소프트웨어를 상업적으로 판매하게 됩니다. 이러한 상업적 접근은 시장이 확대되어 감에 따라 더욱 큰 효과를 발휘하였고, 많은 유능한 인재들이 소프트웨어 개발에 참여하게 됩니다. 그런데 이러한 폐쇄적인 문화에 반발하는 인물이 나타납니다. 그가 바로 유명한 리차드 스톨만이죠. 자유 소프트웨어 재단의 대표이며 Emacs와 같은 걸출한 에디터를 개발한 사람입니다. 그리고 그가 이끌던 GNU 프로젝트가 없었다면, 리눅스는 지금처럼 꽃을 피우지 못 했을 겁니다.

    어쨌거나 그는 1989년 첫 버전의 GNU General Public License (GPL)을 발표합니다. 소프트웨어의 사용자에게 진정한 자유를 주고자 했던 노력의 산물이라 할 수 있겠습니다. GPL하에 배포된 소프트웨어를 개작하고, 재 배포하는 모든 일이 자유입니다. 단 GPL을 따르는 소스를 이용하여 무언가를 개발한다면, 개발된 소프트웨어 역시 GPL 라이선스를 따라야 하며, 소스가 공개 되어야 합니다. 그리고 소프트웨어 자체에 대한 비용을 청구할 수 없으며, 단지 배포를 위한 패키징 비용 정도만 청구가 가능합니다. GPL은 개발자들 간의 공유 정신에 다시금 불을 붙였고, 엄청난 인기를 누리며 오픈 소스 운동의 견인차 역할을 하게 되지만, GPL의 소스 공개 원칙은 대다수 상업용 소프트웨어 개발사들이 참여하지 못하게 하는 장벽이 되기도 했습니다. 이러한 점 때문에, 라이브러리를 위한 Lesser General Public License (LGPL)가 발표 됩니다. 기본적으로는 동일하나 적용 범위가 라이브러리로 국한된다는 점이 가장 큰 차이입니다. 즉 GPL이 적용 된 라이브러리를 상용 프로그램 개발에 사용한다면, 해당 프로그램 전체를 공개해야 합니다. 하지만 LGPL이 적용 된 라이브러리를 사용하게 되면, 해당 라이브러리만 공개하면 됩니다. 전체 소프트웨어의 나머지 부분은 공개하지 않아도 되며, 소프트웨어의 비용을 청구할 수도 있습니다.

    다양한 라이선스의 등장
    GPL과 리눅스의 발전과 함께 진행 된 오픈 소스 운동의 결과 다양한 오픈 소스 라이선스가 생겨납니다. 네오비스님의 글에서도 소개 된 바 있는 OSI (Open Source Initiative) 홈페이지에서 많은 수의 오픈 소스 라이센스를 볼 수 있으며, FSF(Free Software Foundation) 의 홈페이지에서 Free Software 라이선스 목록을 볼 수 있습니다. 그 중에는 상업용으로 사용하여도 어떠한 제한도 없는 경우도 있으며, GPL과 같이 상업적 이용이 제한되는 경우도 있습니다. 주로 사용되는 라이선스의 예를 들자면 Apache Software License, MIT License, BSD License 등을 들 수 있습니다. 반대로 매우 엄격한 제한이 걸려 있지만, 소스만 공개되는 경우도 있습니다. 예를 들자면 Intel은 자사의 일부 소프트웨어 라이브러리 소스를 공개했지만, 소스를 수정하거나 상업적으로 이용하는 것은 금지하고 있습니다. 개발 테스트 용 정도로만 사용이 가능하고, 상업용 소프트웨어에 적용하려면 별도의 라이선스 계약이 필요한 것이죠. 이러한 소스를 보고 사용하는 것은 매우 주의해야 합니다. 만약에 해당 소스의 내용을 살펴 본 후, 별 내용이 없어 독자 개발하였다 하더라도, 해당 소스 코드를 사용하였다는 판단에 따라 소송의 대상이 될 수도 있기 때문이죠. 이러한 경우 해당 오픈 소스를 보지 않았으며, 개발 중에 참조하지 않았다는 것을 증명해야 합니다.
    Posted by 승현아범
    TAG 오픈소스, 저작권
    Trackback 0 Comment 0