0130 웹서버 보안 취약점 관리

 (apach서버를 기준으로 한다.)

1. root권한으로 운영되지 않도록 전용 데몬으로 구동

2. 관리서버 디렉토리 (/usr/local/apache)의 접근 권한 확인.

- 일반 사용자가 접근할 수 없도록한다 750이하

3. 설정파일 권한 확인

- apach설치 디렉터리/conf내 디렉토리의 *.conf파일 권한 설정 확인

- 설정 파일의 indexes옵션을 삭제한다 

- 디렉토리 검색기능 -> 해당 디렉토리에 존재하는 모든 파일이 리스팅 되므로 웹서버구조 노출 및 주요 설정파일의 내용이 유출될 가능성이 있다

4. 상위 디렉토리 이동제한 설정

- 상위 경로로 이동하는 것이 가능할 경우. 접근하고자 하는 디렉토리의 하위 경로에 접속하여 상위경로로 이동함으로써 악의적인 목적을 가진 사용자의 접근이 가능해짐

 5. 로그 디렉토리 권한 설정

- apache설치 디렉터리/logs/ 및의 파일들

- 톰캣의 경우

 catalina base디렉터리/conf/web.xml 에서 

<servlet> ...

<init-param>

    <param-name>listings</param-name>

    <param-value>flase</param-value>

</init-param>

</servlet>

설정한다!

(기본적으로 . 설치하게 되면 false설정이라고 한다)

6. 적절한 로그 포맷설정

- referer설정, user-agent설정, 등 공격자 위치를 파악할 수 있는 포맷설정을 해야 함

7. 헤더 정보 사용 불가능하도록 설정

- Server에 대한 정보가 헤더에 나타나지 않도록 설정해야 함

8. 불필요한 메서드 금지

9. 파일 업로드, 다운로드 용량 제한

10. DocumentRoot디렉토리 설정 변경

11. 세션 타임아웃 설정

12. 관리자 콘솔 접근 통제 : 

- 불필요한 경우 프로세스 종료

- 필요한경우 어려운 port로 변경

13. 관리자 디폴트 계정 명 변경

- 기본유저, 패스워드를 삭제하거나 주석으로 처리하여 기본유저로의 로그인이 불가능하도록 설정한다. 

- 톰캣디렉터리/conf/tomcat-users.xml설정에서 변경

- 유추하기 쉬운 계정명 사용시 brute - forth공격에 노출되기 쉽다

14. 복잡한 패스워드 설정

- 공통기준)

- 길이: 9자리 이상, 3종류의 문자이상

- 변경주기: 3개월/ 중요 시스템의 경우 1개월

- 재사용 금지: 직전 1개 패스워드

- 계정 잠금 : 10회 실패시 .

- null패스워드 사용금지, 문자또는 숫자만으로 구성 금지, 사용자 id와 동일한 패스워드 금지, 연속적인 문자 사용금지(1111, abcd, 1234등) 

- 주기적인 패스워드 재사용 금지

- 전화번호, 생일같이 추측하기 쉬운 개인정보를 패스워드로 사용 금지

- 초기 패스워드는 사용자에게 부여한 후 최초 접속시 반드시 변경하도록 설계

- 패스워드는 마스킹 처리하여 화면상에서 읽을수없도록 표시

- 패스워드 관리기능)

- 패스워드 분실로 인한 신규 패스워드 발급 절차 적용

- 패스워드 분실시 패스워드 초기화 처리후 로그인하여 패스워드 변경을 유도 한다. 

- tomcat-users.xml파일 의 권한 설정 확인(600)

0130 dbms보안 취약점 관리

 1. 디폴트 계정,scott계정등 불필요한 계정 삭제

2. 원격에서 db서버로의 접속 제한

- 지정된 ip주소에서만 접근 가능하도록 제한해야 하고, 비인가자가 내부망에 접근할수있는 위험을 없애야 함.

3. mysql명령 히스토리 검사

- 로컬시스템에서 mysql명령을 사용하여 db에 접근할때 명령어 행에 계정 및 패스워드를 붙여서 사용하는 경우 쉘 히스토리 (.history/.sh_history)파일에 기록이 남는다.

- history파일의 권한설정(600이하)를 확인하고,

- mysql명령어 사용시 명령어 사용시 계정/패스워드 입력하지 말고 mysql -u 계정명 -p명령만 입력한후 패스워드를 개별적으로 입력할 수 있도록 한다.

4. mysql 실행파일, 데이터 파일에 대한 권한 확인

5. 개발시스템, 운영시스템의 분리 확인

- 하드웨어적으로 분리되어있어야 하며. 원칙적으로 개발자와 운영자가 분리되어야 함. 개발자의 운영시스템으로의 접근을 제한

6. 패스워드 정책 확인

7. GRANT_OPTION이 일반사용자에게 설정되어있지 않은지 점검

0130 OS 보안 취약점 고려사항들

 1. root계정으로 telnet, ssh서비스에 직접 접근이 가능한지 점검

- root계정으로 직접 접근하여 사용 x, 일반계정으로 접속후에 루트계정으로 전환하여 (su) 사용할것

2. 패스워드 복잡성 설정 여부 확인

3. 로그인 실패 임계값을 설정하여 -> 잠금이 되도록 계정 보호

4. 패스워드 파일 보호

-> etc/password가 아니라 shadow 파일에저장되고있는지 확인.

etc/password에는 평문으로 저장되기도..

반드시 암호화하여 shadow파일에 저장한다

5. root이외의 uid가 0인 다른 계정이 있는지 점검

-> 해킹의 위협으로 심어진 다른 계정일수도 있고.

"/etc/passwd" 파일 내 UID 확인 (세 번째 필드 값)

루트 이외의 사용자가 슈퍼유저 권한을 가지고 있으면 권한이 중복되기도 하고 감사가 어려워지므로, 삭제하거나 적절한 uid를 100이상의 번호로 등록한다.

6. su권한 제한

- 그룹별로 권한을 제한하여. su명령어를 사용할수있는 그룹을 제한한다

7. 패스워드 최소길이 설정

- 8자 이상으로 설정되어있는지 점검

8. 패스워드 최소 사용기간 설정 여부 확인

- 패스워드 최대 사용기간 지난 후 패스워드 변경, 이후 다시 바로 이전패스워드로 변경하는 것을 방지하기 위한 설정이 필요함. 최소사용기간은 1일 이상으로.

9. 불필요한 계정 제거

- 퇴직자, 휴직자, 계약 해지자 등의 불필요한 계정, 미사용 계정 삭제

- 프로그램 설치시 디폴트로 생성되는 계정들 삭제

10. 관리자 그룹에는 최소한의 계정만 포함

11. 동일한 uid로 설정된 계정이 존재하는지 확인

- 동일한 uid를 쓰는 계정이 존재하는 경우. 타계정 소유의 파일 및 디렉터리에 접근이 가능하게 되어 침해사고가 발생할 수 있음

12. 로그인이 필요하지 않은 계정에 로그인권한이 있는지 점검.

- uid가 100dlgkdlrjsk 60000이상인 시스템계정 -> nologin설정

13. 세션 타임아웃 설정

- 5분 이내로 설정 권고.

14. root 홈, PATH 디렉터리 권한 및 PATH 설정

PATH환경변수에 .(현재디렉토리)있을경우 root계정으로 su 해서 사용할 때 비의도적으로 현재 디렉토리에 위치하고 있는 명령어가 실행될 수 있다

15. etc/passwd , etc/shadow파일의 소유자 설정 확인

- etc/passwd에서 두번째 필드가 x여야함. 

- etc/shadow파일은 root계정만 읽을수있어야 함.

16. /etc/hosts파일 소유자 및 권한 설정

- /etc/hosts파일의 권한이 600인지 확인

- 소유자가 root인지 확인

- ip 주소와 hostname을 맵핑하는데 사용되는 파일. 이 파일의 접근권한 설정이 잘못되어있을 경우 악의적인 시스템을 신뢰할 수 있어 쓰기 권한을 제거해야 한다.

17. 인터넷 슈퍼데몬 서비스 설정파일 (/etc/(x)inetd.conf)파일 소유자 및 권한 설정

- 쓰기 권한 없도록 600,

- 소유자 root인지 확인

18. /etc/syslog.conf파일 소유자 및 권한 설정

- 설정 변조를 통해 침입자의 흔적 또는 시스템 오류를 방지하기 힘들게 만들 수 있다. 644이하 및 소유자 root확인

19. etc/services 파일 권한 확인

- 설정 변조를 통해 운영 포트 번호를 변경하여 불필요한 서비스 혹은 악성 서비스를 실행할 수 있다. 644이하 및 root소유자 확인

20. setuid, setguid설정 확인

21. 환경변수 파일 소유자 및 권한 설정 

- .profile , .bashrc, .bash_profile등 환경변수 설정 파일의 타사용자 쓰기 권한을 제거

22. /dev디렉토리 내 불필요한 device존재 여부 점검

23. 접속을 허용할 ssh의. ip주소 및 포트 점검 (telnet과 같은 서비스를 사용하여 접근할 수 없도록 제한)

24. umask설정값 확인 . 022를 권장

25. finger서비스 이용가능한지 확인

- etc/passwd파일을 조회가능한 명령어. 사용 불가능하도록 설정

26. anonymous FTP사용중인지 점검

인터넷에서 FTP를 사용할 때 anonymous FTP는 사용자들이 서버에 자신을 식별시키지 않고서도 파일에 접근할 수 있는 방법을 제공한다. 보통의 FTP 사이트들은 오직 적법한 사용자 아이디와 패스워드를 가진 사람만이 이용할 수 있는데 반해, anonymous FTP는 파일을 보거나 다운로드하기 위해 해당 서버에서 부여된 사용자 아이디나 패스워드가 없더라도 작업이 가능하기 때문에 anonymous 라고 부른다. Anonymous FTP 서버에 접속한 뒤 사용자 아이디로 "anonymous" 라고 입력하고, 패스워드에는 자신의 이메일 주소를 입력하면 로그인이 허용된다 (이때, 패스워드를 넣지 않거나 어떤 내용을 넣더라도 로그인 하는데 문제가 없지만, 대개 자신의 이메일 주소를 쳐 넣는 것이 통신상의 예의로 되어있다).

- 불필요한 사용자, 악의적인 사용자가 시스템에 대한 정보를 획득하게 되는 것을 방지한다. 

27. Cron관련 파일들의 권한이 640이하인지 확인

28. dos공격에 취약한 명령어 사용하지 않도록 제한

- echo

-chargen

- finger 

- nntp

- ntalk 등.

29. nts서비스 확인

30. 불필요한 rpc서비스 사용하고 있는지 점검

31.ftp서비스 사용하고 있는지 점검 , 불가능하도록 한다 (sftp를 이용)

01/28 nginx 로 allow method 설정하기

 - 설정이전. curl 메소드로 확인한다.

Allow 헤더 출력되지 않고 있다.

nginx에 설정을 추가하고

다시 확인해보자

이번에는 forbidden 으로 바뀌어있음을 확인할 수 있다!!!

01/23 웹 취약점 분석

  1. 파일업로드 

1) 확장자 체크는 화이트 리스트로 관리하기

2) 파일명저장될때 임의의 문자열을 덧붙이기

3) 업로드 디렉터리를 제한하고, 첨부파일이 저장된 디렉터리의 실행권한 chmod제한하기

2. XSS

1) 종류 

a) 반사 XSS: 서버를 이용하지 않고, link를 이용하여 스크립트를 실행 (이미지, 비디오, a href 등)

b) 저장 XSS : 서버를 이용한 스크립트 실행. 일단 서버를 타고 한번 데이터베이스에 저장되고, 저장된값이 그대로 다시 브라우저로 노출되면서 스크립트가 실행된다. 

2) 방어

- 스크립트 치환 라이브러리 사용

3. SQL injection

- prepared statement 사용.

prepared statement의 경우 미리 sql질의문을 정적으로 컴파일 한 후에, 파라메터가 들어갈 자리만 남겨둔다. 동적으로 생성되는 파라메터는 문자열로 취급되어 들어가기 때문에 안전하다. 일반 statement의 경우 파라메터와 함께 그 순간 동적으로 쿼리를 생성하기때문에 위험하다.

4. 취약한 패스워드 정책

- 세가지 종류 이상의 문자구성, 8자리 이상의 길이

-혹은 두가지 종류 이상의 문자구성, 10자리 이상의 길이

5. 자동화 공격

- brute-forth 공격을 자동화하여 패스워드 크래킹이 가능하므로, 이것을 방지하기 위해서는 인증시도 횟수를 제한하여야 한다. 

- 패스워드만 틀린것인지, 아이디/패스워드 둘다 틀린것인지 구별할 수 있어야 한다. 

6. 취약한 관리자 페이지 접근

- 관리자 로그인 페이지 주소 변경

- 관리자 로그인 페이지 접근 레벨 -> ip주소로 설정. 반드시 사내ip에서만 접근 가능해야 한다. tomcat-users

7 백업 및 테스트파일 존재 

- 공개형 솔루션의 샘플파일 

- 불필요한 테스트 페이지 혹은 개발페이지 

- 삭제, 디렉토리 경로변경, 접근제한 설정 등.

8 세션 재사용 및 타임아웃 설정

- 로그인마다 동일한 세션아이디가 생성될경우 취약

- 일정시간이 지난 후 재접속시에도 로그인 상태가 유지될 경우 취약(권고: 30분)

- 쿠키 제거 & 세션 제거 함께 해야한다. 

-로그인 시마다 새로운 세션 아이디가 발급될 수 있도록 해야한다. 

1/15 char array -> string

 해쉬함수를 사용하여 byte array 로 반환하니 음수값이 많이 나온다.

이것을 단순히 for문 돌려서 char로 바꾸어보니 값이 많이 깨졌다 (아스키코드값은 다 양수이니까)

해결하기 위하여 Base64Util을 사용하여 String 으로 반환하도록 한다. 

1/12 금융 api test 2

 

오른쪽 자물쇠 버튼 눌러서 헤더에 받은 토큰값을 넣어준다

참고로 expire time설정되어있어서 일정시간 지나면 다시 새로받아야하는 번거로움이 있다..

1/12 금융 api call test

 

API KEY등록후에 swagger로 테스트한다

{
  "code": "2ffd133a-d17a-431d-a6a5",
  "scope": "login inquiry transfer",
  "client_info": "test",
  "state": "b80BLsfigm9OokPTjy03elbJqRHOfGSY"
}

코드발급 완료

ARS 인증을 진행하고 code를 이용해서 토큰을 발급받는다

{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiIxMTAxMDAyNTg3Iiwic2NvcGUiOlsiaW5xdWlyeSIsImxvZ2luIiwidHJhbnNmZXIiXSwiaXNzIjoiaHR0cHM6Ly93d3cub3BlbmJhbmtpbmcub3Iua3IiLCJleHAiOjE2NDk3NjYxMzAsImp0aSI6ImI0ZDZiMTFmLThkZGEtNDk2NC1hMWFkLTA1ODk5MTkyY2JiZCJ9.0qaWuuG23GpeQPdlIt4Hg1uXuylpedYkbM9KnaAXkcQ",
  "token_type": "Bearer",
  "refresh_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiIxMTAxMDAyNTg3Iiwic2NvcGUiOlsiaW5xdWlyeSIsImxvZ2luIiwidHJhbnNmZXIiXSwiaXNzIjoiaHR0cHM6Ly93d3cub3BlbmJhbmtpbmcub3Iua3IiLCJleHAiOjE2NTA2MzAxMzAsImp0aSI6ImM1NGY0MzVmLWQzYWQtNGY4My1iZjY3LTFjZDk0MmJkYmRjOCJ9.13Vbe8ded-R7ezEoNzvxJozEoVTZJKGVvqO1sLPqXYw",
  "expires_in": 7775999,
  "scope": "inquiry login transfer",
  "user_seq_no": "1101002587"
}

12/31 rabbitMQ 윈도우 설치

 

1.  https://erlang.org/downloads

다운로드

2. https://rabbitmq.com/install-windows.html#installer

서버 버전 다운로드. 윈도우 인스톨러 이용

3. 윈도우 환경변수 > 시스템 환경변수 >  Path 에 각각 추가

4. ELRANG_HOME 시스템 환경변수 추가

5. 윈도우 커맨드 창 관리자 권한으로 실행 후

rabbitmq-plugins enable rabbitmq_management 

명령어 실행으로 플러그인 설치

6. 서비스 에서 rabbitMQ설치확인

--------------------------

23.1 버전의 erlang은 현재 최신버전의 rabbitMQ와 호환되지않는 문제발생하여

최신버전인 24.2로 다시 다운로드 하였다.

rabbitmq-server로 시작!!

일단 로그인의 경우 guest/guest로 가능하다.

12/31 토큰인증

 1. 토큰을 api요청시마다 확인하는건 너무 과부하.. 따라서 한번 인증되면 - 캐싱해둔다. 이때는 RDB같은 file 혹은 디스크 IO기반의 저장소보다. 메모리기반의 저장소(redis, memcached)를 사용한다

2. MSA서비스에서의 인증 / 인가 방식

1) 모든 서비스api가 공유하는 중앙저장소 사용 : redis, memcached 등

2) api gateway 에서 직접 인증/인가 구현

3) api gateway 와 auth service협력하여 인증/인가 구현

3. 토큰인증

# 필요성?

- 모바일 app의 경우, web과 달리 cookie jar기능이 없다. 따라서 세션/쿠키 방식의 전통적인 인증인가가 불가능하다.

- 모바일 app의 경우 , json으로 데이터를 주고받는데. 웹은 html로 응답하므로 불일치가 발생한다. 

=> json방식 토큰인증을 사용하여 인증/인가를 일원화할수있다는 편리함? 장점이 있다.

# 취약점?

- 토큰인증이든 쿠키인증이든.. 탈취위험성에는 쌤쌤.

그럼 탈취되었다고 가정하고. 토큰의 경우에는 서버쪽에서 이 토큰의 유효기간을 끊어낼방법이 없다고한다 ? -> 그래서 이걸 해결하려고 공유 저장소를 사용한다 

-> 근데 이러면 결국 stateless하게 인증인가한다는 장점을 버리게 되는거 아니냐?라는 . 

결국엔 장단점이 있고... 아아 좀더 공부하자!!!

인증인가가 심오하구나. 쉽게쉽게 스프링시큐리티 붙이면 되지머~ 하고 볼게 아니다.!!!

1109 thread 실습하기!

대기큐 사이즈를 0로, 스레드풀사이즈를 100으로 한정해놓고 스레드 1000개를 동시에 보냈다.!!

그랬더니 - 더이상 요청을 받아들일수없다는 에러 메시지 출력!!오오오.

1102 jsp, web 기술

 # 1. JSP란

- 서버사이드에서 동적컨텐츠를 생성해주는 랭귀지

- 자바 웹 어플리케이션에서 이용됨

- 서블릿 기술의 확장판이라고 볼 수 있다.

- HTML과 자바언어의 갭을 메꾸기 위하여 탄생

# JSP servlet의 장점?

- 태그라이브러리 등 지원

- HTML과 자바언어를 분리하여 깔끔한 코드 작성에 도움

# JSP 라이프사이클

- 번역 -> 컴파일 -> 메모리에 클래스가 로딩됨 -> 인스턴스 생성 -> 초기화

: 초기화 된 후, 다른 인스턴스들 (servlet request 같은) 이 jsp 인스턴스에 접근할 수 있게[ 된다.  

 -> 사용자 요청 처리 -> 소멸

( 일반적인 클래스 객체의 생성과정과 동일.)

---

# 기타

## 초기화 순서

- 스태틱 변수의 기본 초기화 (이를테면, int 가 0으로 초기화되는것. )

- 명시적 초기화

- static 블록 

### 스태틱 블록이란, 말하자면 클래스의 생성자같은 존재. 

- 인스턴스 변수 기본 초기화

- 인스턴스 변수 명시적 초기화

- 인스턴스 블록

- 생성자 

## 어떻게 하나의 컨트롤러가 여러 요청을 처리할 수 있는가 ?

- 힙영역 / 메소드 영역 별로 메모리에 로딩되기 때문이다. 

## 어떻게 톰캣은 여러 유저의 요청을 동시에 처리할수있는가?

- 현재 톰캣은  NIO기반으로 돌아간다. 

- 사용자 요청이 끝날때까지 대기하는 동기방식(이전방식) 이 아니라, 요청을 다른 워커스레드에게 넘긴다. 즉 메소드 호출하고 return 하기 때문에, 더 많은 사용자 요청을 바로바로 받아들일수있게 된다. 

## 톰캣 스레드와 커넥션 객체의 관계

- 커넥션 객체는 생성 비용이 비싸다. 

- 모든 사용자가 db 커넥션을 사용하는 것은 아니기 때문에, 사용자 요청 스레드 > 커넥션 객체 수 가 된다. 

- maxIdleconnection 과 maxconnection수는 같은 것이 좋다. 만약 maxidle < maxconn 일 경우, idle수보다 커넥션객체를 더 많이 생성해야하면 그만큼 객체를 생성했다가 없앴다가 하는 비용이 들기 때문이다. 

## 로그대신 system.out.println을 사용하면 안 좋은 이유

1) 필수적인 정보들을 얻을 수 없다. 시간 정보, 유저정보, 리퀘스트 ip 정보등.

2) 사용하는 개발자의 성향에 따라 찍히므로 형식이 통일되지 않는다.

3) syso는 시스템콜을 유발하기 때문에, os의 native IO를 사용하고, 따라서 해당 어플리케이션 외의 다른 프로세스에게도 민폐를 끼치게 된다.

4) 성능면에서 10배이상 떨어진다고 한다. (위 3번에서 이어지는 이유. 시스템콜을 하고 다시 유저 모드로 컨텍스트 스위칭하는 비용이 비싸다) 

5) 로그파일로서 따로 수집되지 않는다. 

## 스프링이 유저 웹 요청을 받아들이는 순서

- 유저요청 -> dispatcherServlet -> adaptor -> controller 가 요청을 process하고 뷰네임 반환 -> adaptor -> dispatcherServlet 이 요청 반환

- 스프링은 dispatcherServlet이 일단 모든 요청을 받아들이는. 프론트 기반? 방식을 사용중. 

1031 궁금했던 것들

 1. 왜 파일을 업로드 할때 바로 inputStream으로 처리하지 않고, transferTo같은 메소드를 통해서 한번 임시파일로 저장해둔 후에 다시 해당 파일을 처리로직을 짜야 하는지 궁금했다. 

-> 이유: 

곧바로 웹 애플리케이션이 동작하고있는 중인 JVM메모리상에 곧바로 파일을 로드해버리면, 대용량파일일 경우 굉장한 부담이 될수있기 때문이다. 그렇기 때문에 일단 임시파일로서 업로드하고 처리한다!

2. system.out.println을 통해 로그를 찍으면 안좋은 이유

1) 로그에 필요한 필수적인 추적정보들이 누락되며 개발자가 어떤식으로 작성하느냐에 따라서 형식이 무분별하게 된다( ex, 어떤클래스?몇시 ? 등등)

2) log파일에 쓰여지지 않고 콘솔에 출력되기 때문에 통합적인 관리가 어렵다

3) native I/O로서 synchronized키워드를 사용한다. 성능면에서 훨씬 안좋다고 한다. 

1025 톰캣, 스레드, 스프링, 커넥션객체

[스프링]

- 메타 정보 파일 + 클래스 => 스프링 어플리케이션

1. 메타정보파일 : xml, 자바 config , db데이터 등등 다양. resourceLoader만 필요적절하게 있다면뭐든 형식오케이

- 스프링 빈 등록방법

1. 형식 : xml또는 java config

2. 방법 : 

1) 직접 bean id일일이 등록

2) component scan해서 베이스 패키지 등록 - 아래에 있는 애들 다 등록하기 . 빈스캐너 등록

3) 스테레오 타입 어노테이션 이용 (위에랑 합쳐서,할수있음)

4) 빈스캐너 : 직접 등록하기 or 해당 빈스캐너를 이미 디폴트로 들고있는 applicationcontext사용하기(우리는 보통 이쪾을 사용하니까 걍 스테레오 타입어노테이션 막붙여버리고 ㅇㅇ 아무렇지않게 쓰고있었다)

3. 반드시 필요한것 : id , class 보통 어노테이션 방식쓰면 - id는 class명에서 앞에만 소문자로 따서 ㅇㅇ만들어짐 

4. 빈 스코프설정  : 디폴트 싱글톤. 특별한 경우 prototype으로 계속 생성도 가능

5. @configuration : 이거 이용해서 여러빈을 한번에 등록. 얘 자체도 하나의 빈이기때문에 싱글톤. 설령 얘의 메소드를 직접부른다고 하더라도1!! 반환된 객체는 싱글톤이다 (오묘~~~@!)

6. 같은 타입의빈이 여러개 있을떄 ? -.> @qualified같이 이름으로 구분하거나 / 아니면 배열로 주고 파라메터 받아서 적절하게 반환한다는 전략도 있음. HashMap으로 해서 이름/ 객체로 받을수도 있음!!! 개쩐당

- DI하기

1. 전략 : setter / 생성자 / 필드 / 일반 메소드 주입

2 . 만약에 테스트 환경같이 갈아끼울필요있으면 setter주입고려해보고.

3. 생성자주입쓰면 한번에 할수있으니까 편하다-

-스테레오타입어노테이션 

: 해당 어노테이션으로 빈등록하면 - aop쓸때 걸러낸다던지. 좀더 명확하게 클래스에 이런애입니다!! 라고 정보를 모아서 볼수있으니 편함. 이용하자. @Repository, @Controller, @Service 그외에 애매한 애들은 @Component라고 등록. 

- @Configuration에 등록하는 애들 : 개발자가 작성한 클래스가 아니라 기술적으로 필요한 애들등록할때도 사용@Bean으로. 

- 다양한 종류의 ApplicationContext가 있다. 여기는 빈들이 생성(초기화) 되고 . 한번 호출해준다!! 그러면- 이제 타고타고 유저요청에따라 main메소드가 실행되고. 

1024 스프링, 스레드, 톰캣에 대한 의문들

 1. 스프링은 빈 객체를 싱글톤전략으로 (기본적으로는) 사용한다.

2. 왜냐? 유저 요청이 들어올때마다 컨트롤러 서비스 각각 개별적으로 띄우면- 금방 메모리가 바닥날것이기 때문에 같은 빈을 공유하는 것이 효율적이다. 

3. 여기서 의문!! 그럼 아니 어떻게 하나의 컨트롤러가 유저요청을 다받아내??

4. 톰캣은 기본적으로 max스레드 수가 200으로 되어있으니까 최대 동시에 200요청을 하나의 컨트롤러가 받아낸다고 ?!! 하는 의문이 들어서 찾아보았다---

https://jeong-pro.tistory.com/204

<< 여기 글을 보고 의문을 해결할수있었다!!!

5. 결론 - 객체 주소(heap영역_)는 공유하지만, 메소드(stack영역)는 개개별 스레드마다 생성되므로- 동기화 우려가 없다. 그래서 빈 객체는 무상태로 유지해야하는 것이 중요하다! 그래야 동기화 이슈가 없다-. 그리고 메소드는stack별로 유저마다 다른 값을 가질것이므로 - 컨트롤러라는 객체를 '공유'한다는 것이 가능하다.

6. '공유'라는 개념을 헷갈리고 있었던것이당.

7. 커넥션풀과 톰캣스레드 수는다르다!!

-> 톰캣스레드별로 커넥션을 물고간다? 뭐 그런 식의 표현을 읽은적이 있다... 근데 커넥션 수 100개만 넘어가도 뻑 죽던데 왜지... 하는 의문이 있었는데그것도 해결!!

스레드를 공유하는게 아니라 객체의 수를 공유한다는 것이었땅.

1023 Java Web Application

 1. 웹 서버와 클라이언트 

- 웹서버: 아파치 서버 등등. 자원을 가지고 서비스를 제공하는 쪽

- 클라이언트: 자원을 요청하거나 자원을 스스로 만들어서 서비스를 제공받는쪽

1) HTML & HTTP

- HTML : 웹서버와 클라이언트의 언어

- HTTP : 웹서버와 클라이언트의 통신규약

2) 요청(리퀘스트) 3대요소 : URL, METHOD, 파라메터

-> restTemplate을 사용해서 getForEntity를 보낼때를 생각해보자 -

// 사용시 주의사항 : 타임아웃설정!!

일반 new RestTemplate()해서 부르면 - 타임아웃없이 그냥 설정됨!

restTemplate이란 - 스프링에서 HTTP통신을 좀더 깔끔하게 할수있도록 제공해주는 클래스이다. 추상화된 객체. 따라서 우리는 좀더 이쁘게 코딩할수있게 된다.

 getForEntity에 사용하는 요소가 무엇인가? 바로 url과, get이라는 메소드, 그리고 파라메터들이다. get을 사용하기 때문에 파라메터들은 쿼리스트링으로 url에 포함되어서 날아가게 된다 .

그럼 exchange()메소드를 사용해서 보낼때도 생각해보자. 

HttpEntity클래스안에 보낼 파라메터들을 모아서 넣을 수 있다.

HttpEntity란, 헤더와 바디를 함께 담을수있는 클래스이다.

org.springframework.http

Class HttpEntity<T>

• java.lang.Object
• org.springframework.http.HttpEntity<T>

• Type Parameters:

  T - the body type

  Direct Known Subclasses:

  RequestEntity, ResponseEntity

  ---

  
  

  public class HttpEntity<T>
  extends Object

  Represents an HTTP request or response entity, consisting of headers and body.

  Typically used in combination with the RestTemplate, like so:

   HttpHeaders headers = new HttpHeaders();
   headers.setContentType(MediaType.TEXT_PLAIN);
   HttpEntity<String> entity = new HttpEntity<String>(helloWorld, headers);
   URI location = template.postForLocation("https://example.com", entity);
   

header에 넣을 부가정보 있으면 넣어주고 (이를테면, 콘텐츠타입 지정)

URL당연히 넣어주어야 하고

파라메터 넣을 거있으면 바디에 넣어주고 해서 -> REST요청 보내기!!

이 클라이언트 - 서버 관계는 상대적이다.

요새는 MSA구조를 많이들쓰니까.. 자원을 요청하는 쪽이 누구냐? 에 따라서 - 웹서버가 클라이언트가 되어서 다른 웹서버에게 요청을 하기도 하는것이다.

3) response 3대요소: status code, content type , content 

-> 마찬가지로 똑같이 restTemplate상상하면 쉽다!!

restTemplate에서 getStatusCode()해서 부를수있고, getBody()해서 콘텐츠 꺼내오는 거!!

- 참고: mime type = content type동의어이다.

4) url

통신규약 :// 호스트의주소:포트번호/자원의 위치

2. JSP & Servlet

- 사용이유 : 동적콘텐츠 생성.

어떤 콘텐츠들은 자주 변경된다. 이런 콘텐츠를 서버에다 전부 넣어두면- 넘 비효율적이고 비대하다. 따라서 이러한 콘텐츠들은 동적으로 생성해서 요청시마다 반영한다. 

3. 웹 컨테이너 

1) 톰캣은 웹 컨테이너이다.

2) 웹 컨테이너란 ? 간단하게 말하자면, 사용자의 요청을 받아 response를 주는 스레드이다. 톰캣도 결국엔 하나의 스레드이고- 웹 요청 이라는 작업!! 을 처리하는 녀석인 것이다.

3) 요청을 처리하는 순서 : request받음 -> servlet찾음 -> 서블릿이 작업처리하면 그것을 response로 보냄

4. 웹 컨테이너의 장점

1) 효율적인 비지니스 로직 처리 : socket을 자바단에서 만들어서 포트생성하고.. 요청계속 기달리고.. 요청끊기면 막 그거 따라서 close떄려주고.. 이런 low레벨의 코딩을 안해도 된다. 톰캣이 알아서 요청 받아서 샥샥 처리해준다. 

2) 서블릿 스레드 생성 처리 : 톰캣이 유저요청에 따라서 알아서 서블릿 스레드를 생성해준다. 우리가 스레드를 일일이 유저별로 안만들어줘도 된다!!

3) 멀티스레드 지원 

4) pool관리: 기본적으로 톰캣 max pool은 200. 하지만 여기에 비동기처리를 한다면? 톰캣스레드 1명이서 웹 요청 처리하고 return하고, 워커스레드 슉슉슉 만들어서 더 효율적으로 처리할수있음!! 이런 풀관리를 컨테이너 차원에서 할수있으니까 개발자는 넘 편해진다. 

0921 소켓 프로그래밍

 

알쏭달쏭...

서버: 인풋 아웃풋 스트림을 소켓으로부터 받아서 연다.

가지고 있는 해쉬맵(클라이언트 접속정보 저장) 에 모두에게 메시지를 보낸다.

클라이언트: 인풋으로 읽고 아웃풋으로 쓴다.

코드를 보면 ~~ 쉬운것같기도 하고~~~ 우아앙.

뭔가 확!! 풀리지가 . 않네~~ 

0915 java Socket , java7

 28장 다른 서버로 데이터를 보내려면 어떻게 하면 되나요?

#네트워크 프로그래밍

 - 어플리케이션 레이어의 HTTP, 텔넷, FTP통신등- 전부 TCP통신 위에서 이루어진다. 자바의 경우 소켓을 이용하여 tcp통신을 구현할 수 있다. 

#서버- 클라이언트간 소켓통신

- 서버: SocketServer 객체 생성하여 포트를 연다.

클라이언트로부터 데이터를 받을 Socket객체 열고 accept()하여 데이터를 받을 준비를 한다. 

socket객체로부터 인풋스트림열어서 while(true)걸어주면서 계속 데이터 받는다.

데이터가 더이상 없으면 close한다.

- 클라이언트: 데이터를 보낼 Socket객체를 생성하고, 호스트ip와 포트번호를 생성자에 넣어서 생성한다. TCP/IP통신에서는 포트번호/호스트주소/프로세스id로 식별하기 때문이다.

socket객체로부터 아웃풋스트림 열어서 데이터 전송한다.

전송이 완료되면 close를 때려준다.

#UDP통신

- TCP통신과 다르게 데이터를 그냥 통으로 보낸다. 쪼개서 보내지 않는다. 그래서 Datagram이라는 객체를 이용한다. 버퍼의 사이즈/ 데이터의 length를 지정한다. 데이터를 그냥뭉텅이로 통으로 보내기 때문에 - 버퍼의 사이즈 >= 데이터 length여야한다. 

비연결성 비신뢰성이기 때문에 데이터가 잘 안보내져도 책임지지 않는다. 설령 server쪽에서 포트를 안열고 있다고 하더라도 오류가 발생하지 않는다. 검사하지 않기 때문이다. 

일반적으로 UDP를 사용해서 프로그래밍하게 될 일은 별로 없다고 한다. (쓰더라도 tcp랑 섞어쓰게 될듯)

30장 java7에서 달라진 것들에는?

# 숫자표현

- 0을 앞에 붙이면 8진수, 0x를 앞에 붙이면 16진수, 0b를 앞에 붙이면 2진수

- _를 이용해서 큰 숫자 표현가능

# switch-case문에 String 사용가능

# 제네릭과 다이아몬드

- 타입체크에 유의한다

- 배열의 경우 컴파일시 타입이 남고 / 제네릭의 경우 컴파일시 타입이 남지않음

- 제네릭의 타입은 컴파일시 소거되고, Object타입으로 변환됨

#  예외처리

-try -catch-resouces문 이용하여 Closable이용한 객체의 경우 명시적으로 close()부르지 않아도 깔끔하게 자원반납가능

- |를 이용하여 다수의 예외를 한꺼번에 처리가능 

0909 HTTP통신

 1. HTTP는 무상태 프로토콜이다.

이와 반대로, FTP는 상태유지 프로토콜이다.

팀 버너스리 박사가 HTTP를 발명하기 전에, FTP는 이미 널리 사용되고 있었다. 그럼 왜 굳이 FTP를 사용하지 않고 HTTP프로토콜을 만든걸까?

그 이유는 훨씬 가볍고 편리하니까!! 이다. FTP의 경우 계속해서 상태를 유지하기 때문에 - 데이터의 오버헤드가 너무 크고, 인증을 받아야 하기때문에 접속을 위해서는 서버 관리자에게 요청해서 권한을 받아야 한다. 

반면 HTTP는 상태유지를 하지 않기때문에 훨씬 빠르고 통신절차가 간편하다.

2. 무상태 프로토콜의 한계점을 극복하기 위한 쿠키와 세션

쿠키: 간편하지만 보안의 문제가 있다. 그냥 탈취하면 그만이기 땜에.. 그리고 용량의 한계도 있다. 

그래서 세션을 이용한다. 사용자가 접속하면 sessionID가 부여되는데, 이 세션ID를 쿠키에 담아서 사용자에게 전달한다. 그러면 사용자가 다시 접속했을때 쿠키가 존재하는지 안하는지 확인하고, 존재할 경우 까봐서 해당 sessionID가 서버의 세션정보에 저장되어 있는지 확인한다. 이렇게 하여 무상태프로토콜을 쓰면서도 각각의 페이지의 연결성을 유지할수 있도록 context를 만들어준다. 

이를 테면 장바구니 구현같은 것도 세션쿠키로 할 수 있다. 해당 sessionID의 테이블 정보에 장바구니 품목을 함께 저장하는 것이다. ( 서버 오버헤드가 크다는 문제점은 있겠지만) 그렇게 함으로써 사용자가 페이지를 나갔다가 돌아와도 장바구니 안에 담았던 품목들이 유지된다. 

but 세션을 끊으면 당연히 해당 내용은 날라간다. 다른 브라우저로 접속한다던지, 아니면 로그아웃 한다던지. 

0906 get, post, 퍼센트 인코딩

 1. get

입력한 매개변수값이 URI에 쿼리스트링으로 그대로 노출된다.

보안에 약할 수 있다.

부작용이 없다 = 언제나 같은 값을 보장한다. (정적)

내가 보낸 값이 그래도 URI에 저장되기 때문에 다른사람에게 그대로 페이지를 전달하기 용이하다.

글자수 제한이 있다(아마 255자 정도)

2. post

입력한 매개변수가 노출되지 않고body에 들어감.

글자수 제한이 없다.

get보다 보안에 강하다( 매개변수 노출x)

부작용이 있다 = 내가 보낸 결과가 항상 같은 페이지를 돌려주지는 않을 것이다. 

3. 퍼센트 인코딩

한글의 경우 어떻게 쿼리스트링으로 날라가는 것인가?

퍼센트인코딩( 앞글자에 %가 들어가는 식으로 구분되기 때문에 그렇게들 부른다) 을 브라우저가 처리하여, 한글또한 읽힐수있도록 인코딩-디코딩 처리를해준다. 그래서 영어권의 언어가 아니어도 값을 전달할 수 있다. 

4. UTF-8 

원래는 아스키 값 사용 - but. 한글, 중국어 일본어 등등.. 아스키 코드(1바이트)로는 턱없이 표현불가능한 문자들이 있음

그래서 유니코드 사용 - 불변 크기. 무조건 4바이트로 통일함. 영어같은경우 1바이트면 표현할 수 있는데 얘는 무조건 다 4바이트로 처리함. 비효율적.

그래서 UTF-8이 등장했다. 언어별로 가변적 크기를 할당하여 효율적으로 처리한다. 바이트의 앞자리에 어떤 숫자가 오는가로 바이트 크기를 계산하고(1바이트줄지 2바이트 줄지 등등) 크기 할당함.