사내에서는 인터넷 차단이 되어있기 때문에 메이븐이나 그래들 같은 건 사용할 수 없다. 

다만, 책 등을 보면서 혼자 뭘 해보려하면 다들 기본으로 깔고 들어가기 때문에 기초정도는 알아둘 필요가 있을 것 같다.

메이븐 프로젝트 시작해보기

메이븐 프로젝트를 생성하는 과정은 다음과 같다

1. 이클립스에서 신규 프로젝트를 만들때 Maven Project를 선택한다

2. 처음 설정 창에서 Create a simple project에 체크해주고 Next 클릭

3. 다음 설정 창에서 Group Id에 com.test , Artifact Id에 testPjt로 적고 Finish 클릭

기본적인 구조는 아래와 같다.

PROJECT/

src/main/java                    <- 일반 프로젝트의 src에 해당하는 곳이다(프로덕션 코드)

src/main/resources            <- 프로덕션 코드에서 사용할 자원들이 위치한다

src/test/java                     <- 테스트 코드

src/test/resources              <- 테스트 코드의 자원

src/ 

main/

webapp/               <- 웹 프로젝트에서 JSP, JS 등의 웹 애플리케이션 컨텐츠가 위치하는 곳에 해당한다 (WEB-INF 등)

target/                             <- 메이븐 빌드 시, 빌드 된 jar 파일 등이 생성된다

pom.xml                           <- 메이븐의 설정파일

위 구조에서 제일 중요한 것은 pom.xml이다. 여기서 필요한 의존성을 설정할 수 있다. 

예를 들어 JUnit을 추가로 사용한다고 하면, 

<dependencies>

<dependency>

<groupId>junit</groupId>

<artifactId>junit</artifactId>

<version>4.12</version>

</dependency>

</dependencies>

https://search.maven.org에 접속하여 원하는 라이브러리 검색후 클릭해보면 dependency information이라는 부분에 무슨 내용을 넣어야하는지 친절하게 나와있다.

그런데 JUnit을 추가시켜보면 이클립스 기준으로 Maven Dependencies에 JUnit의 jar뿐 아니라 hamcrest-core라는 녀석도 추가되어 있는 것을 볼 수 있다.

이 jar는 JUnit을 사용하기 위해서 필요한 라이브러리로 Maven에서 JUnit을 추가할 때 자동으로 추가한 녀석이다. 

이클립스에서 pom.xml을 열어보면, Dependency Hierarchy탭에 각 라이브러리간의 상관관계를 한눈에 확인 할 수 있다.

또 로컬 레파지토리로 이동하여 해당하는 라이브러리 폴더를 뒤져보면 <library-name>.pom 파일이 있다.

이 파일을 메모장으로 열어서 <dependencies></dependencies> 태그 내용을 살펴보면 해당 라이브러리가 종속되어 있는 것이 무엇인지 보인다.

(이를 transitive dependencies 의존성 전이 라고 한다)

만약 프로젝트에서 JUnit의 다른 특정한 버전이 필요하다고 한다면 어떻게 될까?

그 때는 <version></version> 태그 안에 필요한 버전만 적어 넣으면 maven에서 알아서 다운로드하여 프로젝트에 주입시킨다.

○ SSL 매커니즘

보안과 성능상 이유로 아래 두 가지 기법을 혼용하여 사용

- 대칭키

· 동일한 키로 암호화와 복호화를 같이 하는 방식

· 대칭키 유출 시 암호의 내용을 복호화할 수 있기 때문에 암호를 주고받는 사람들 사이에서 대칭키 전달이 어려움 -> 공개키로 해결

- 공개키

· 두 개의 키로 암호화, 복호화를 하는 방식(A키로 암호화 시 B키로 복호화, 그 역도 성립)

-> 두 개의 키를 각각 비공개키, 공개키로 설정하여 비공개키는 자신만 가지고 있고 타인이 공개키로 암호화한 내용을 비공개키로 복호화

-> 비공개키로 암호화 후 공개키와 함께 암호화된 정보 전송하여 데이터가 공개키와 쌍을 이루는 비공개키로 암호화 된 것을 증명(전자서명)

○ SSL 인증서

- SSL 인증서 기능

· 통신 내용이 공격자에게 노출되는 것을 방지

· 클라이언트가 접속한 서버가 신뢰 할 수 있는 서버임을 보장

  (CA(Certificate Authority 또는 Root Certificate)라는 기업들에 의해 수행

  ex) Symantec, Comodo 등)

· SSL 통신에 사용할 공개키를 클라이언트에게 제공

- SSL 인증서 내용

· 서비스의 정보(인증서를 발급한 CA, 서비스의 도메인 등)

· 서버 측 공개키(공개키의 내용, 공개키의 암호화 방법)

 -> CA는 자신의 비공개키를 이용하여 서버가 제출한 인증서를 암호화

○ SSL의 동작

- 신뢰할 수 있는 서비스 증명: 웹브라우저가 서버에 접속 > 서버가 인증서 제공 > 제공된 인증서의 CA가 브라우저에 내장된 CA리스트내에 있는지 확인 > CA의 공개키를 이용해 인증서 복호화 > 복호화가 되면 인증서가 해당 CA의 비공개키에 의해 암호화된 것이므로 신뢰할 수 있는 서비스인 것이 증명

- 데이터 암호화: 네트워크 통신(악수 → 전송 → 세션종료)시 SSL이 데이터를 암호화함(실제 데이터는 대칭키로, 대칭키의 키는 공개키로 암호화)

· 악수(handshake):

1) 클라이언트가 서버에 접속(Client Hello) 및 주고받는 데이터:

 ☞ 클라이언트 측에서 생성한 랜덤 데이터

 ☞ 클라이언트가 지원하는 암호화 방식(클라이언트와 서버가 지원하는 암호화 방식이 달라, 어떤 암호화 방식을 사용할 것인지 협상 필요)

 ☞ 세션 아이디: 추후 악수 과정을 생략하기 위해 사용자 세션을 서버로 전송

2) 서버 측 응답(Server Hello) 및 주고받는 데이터

 ☞ 서버 측에서 생성한 랜덤 데이터

 ☞ 서버가 선택한 클라이언트 암호화 방식

 ☞ 인증서

3) 클라이언트가 내장된 CA리스트 확인 및 해당 CA의 공개키를 통한 복호화 과정을 거쳐 신뢰할 수 있는 서버인지 확인 > 클라이언트가 클라이언트 랜덤 데이터와 서버 랜덤 데이터를 조합하여 대칭키(pre master secret)를 생성 > 서버로부터 받은 인증서에 들어있는 공개키를 이용해서 pre master secret값을 암호화 후 서버로 전송

4) 서버가 전송받은 pre master secret값을 자신의 비공개키로 복호화(서버와 클라이언트 모두 pre master secret을 공유) > 서버가 pre master secret값을 일련의 과정을 거쳐 master secret값으로 생성 > master secret이 session key를 생성 > session key값을 이용하여 클라이언트와 서버간 데이터를 대칭키 방식으로 암호화하여 전송(서버와 클라이언트 모두 session key를 공유)

5) 클라이언트와 서버가 악수단계 종료를 서로에게 알림

· 세션(정보를 주고 받는 단계): 정보를 상대방에게 전송시 session key값을 이용해 대칭키 방식으로 암호화, 상대방은 해당 대칭키를 통해 복호화

* 공개키 방식이 많은 컴퓨터 파워를 사용하기 때문에 많은 접속이 물리는 서버에 큰 부하를 가져오며, 대칭키 전송시 암호화 되지 않는 인터넷을 통해서 전송하는 것은 위험

-> 속도는 느리지만 데이터를 안전하게 주고받을 수 있는 공개키로 대칭키를 암호화하여 실제 데이터 전송시에는 대칭키를 사용

· 세션종료: 데이터 전송이 끝나면 SSL통신이 끝났음을 서로에게 알리고 session key 폐기



□ HTTP vs HTTPS(Hypertext Transfer Protocol Over Secure Socket Layer)

○ 차이점

HTTP의 보안을 강화한 것이 HTTPS로 SSL프로토콜 위에서 돌아가는 프로토콜임. HTTP는 암호화되지 않은 방법으로 데이터를 전송하기 때문에 서버와 클라이언트 간의 메시지를 감청당할 위험이 있음.

○ 모든 웹사이트가 HTTPS를 쓰지 않는 이유

- 보안인증 비용, SSL(or TLS) 키 교환 시 호출시간 소요(웹 서버 부하),

- 불특정 다수에게 공개해도 상관없는 페이지는 http로, 메일이나 로그인 등의 페이지는 https로 하는 것이 효율적

안드로이드 앱 개발을 하려다 보니, 네이티브를 배우기 너무 귀찮다. 안그래도 할 것도 많고.

웹개발은 어느정도 지식이 있으니 Phonegap을 이용해서 개발하자 싶었는데, 이것도 은근히 할게 많다.(디자인이라든지...)

관련해서 프레임워크, 부트스트랩 류의 것들이 뭐가 있나 찾아보다가 Framework7라는 녀석을 알게됐다. 

jQuery와 비슷한 문법으로 DOM 이벤트 처리도 가능하고, Ionic이나 다른 것보다 이리저리 다른 것들에 비해서 편해보인다(학습 곡선이 낮아보인다). 

일단 이녀석을 가지고 해보기로 결정.

그런데 튜토리얼이 꽤 부실하고 커뮤니티가 잘 안되어 있어서 걱정도 된다. 

https://framework7.io/