◎ 캐시 -> 캐시는 데이터 등을 임시로 저장하는 저장소로 같은 데이터를 요청했을 때 서버에 요청을 보내고 응답을 받지 않고 캐시 저장소에서 바로 데이터를 받아 빠르게 응답을 받을 수 있다. -> 아래는 캐시가 없을 때 요청-응답 과정이다. -> 웹 브라우저에서 smile.jpg 사진을 요청을 하면 서버에서 응답을 보내준다. 이 때 서버에서 응답으로 보내는 데이터의 용량은 HTTP헤더 0.1M, HTTP 바디 1.1M로 총 1.1M다. -> 이후에 웹브라우저가 똑같은 요청을 서버에 또 보낸다면 서버에서는 똑같이 총 1.1M용량의 데이터를 응답으로 보내줄 것이다. -> 캐시가 없는 환경에서 요청-응답을 할 경우 데이터가 변경되지 않아도 매번 요청할 때마다 네트워크를 통해 데이터를 다운로드를 받아야한다. 인..

◎ 형변환 -> 변수나 리터럴의 타입을 다른 타입으로 변환하는 것 -> 기본적인 형변환 방법은 '(타입) 피연산자'의 형태로 선언하여 형변환을 한다. ◎ 자동 형변환 -> 형변환을 따로 명시하지 않아도 자동으로 형변환이 되는 것 -> 작은 범위에서 큰 범위로는 값을 넣을 수 있기 때문에 이 경우 자동으로 형변환이 된다. - 위 코드에서 1번 주석은 int 형인 iv가 long형인 lv 변수에 들어가면서 자동으로 long 형으로 형변환이 된다. long이 int보다 더 큰 숫자 범위를 표현하기 때문에 자동 형변환이 발생한다. - 2번은 int가 실수형인 dobule로 자동 형변환이 되면서 10.0이 출력이 된다. - 3번은 double이 부동 소수점을 사용하기 때문에 long보다 범위가 크므로 double..

◎ 지역 변수 -> 특정 지역에서만 사용할 수 있는 변수 -> 지역은 변수가 선언된 코드 블럭 내부를 의미한다. 지역 변수는 변수가 선언된 코드 블럭 내에서만 사용할 수 있다. -> 변수가 선언된 지역 외에서 해당 변수를 사용하면 컴파일 에러가 발생한다. - 변수 m은 main메서드에 선언이 되었기 때문에 main 메서드의 코드 블럭{} 내에서 사용이 가능하다. 반면, 변수 x는 if문 내부에 선언이 되었기 때문에 if 문 블럭을 벗어나면 사용할 수 없게 된다. - m은 main 메서드 외부에서는 사용할 수 없다. ※ 변수의 스코프라는 개념은 왜 쓸까? - 위 코드를 보면 변수가 m과 temp가 있다. temp는 if문 내에서만 사용이 된다. 하지만 temp는 main메서드에 선언이 되어 if 문뿐만 아..

◎ CI/CD -> 애플리케이션 개발 단계에서 배포까지의 과정을 자동화하여 서비스를 배포하는 방식 -> CI(Continuous Integration) : 지속적인 통합. 버그 수정 혹은 새로운 기능이 추가되어 코드의 변경이 발생하면 주기적으로 리포지토리에 빌드, 테스트되어 merge되는 과정이다. ※ CI 과정이 왜 필요할까? - 개발자들은 코드의 변경사항을 주기적으로 공유 리포지토리에 merge를 해야하는데 이 때 서로 다른 코드들을 어떤 방식으로 통합을 할지에 시간을 많이 사용하게 된다. merge과정에서 충돌이라도 발생하면 충돌을 해결하기 위해 많은 시간을 써야 한다. 주기적으로 작은 단위로 merge를 해서 merge 충돌을 최대한 피해 개발 생산성을 높일 필요가 있다. - 코드의 통합 위한 단..

◎ HTTP 헤더 -> HTTP 전송에 필요한 부가 정보를 담는다. -> 부가 정보 : 메시지 바디 내용, 메시지 바디 크기, 인증, 요청 클라이언트, 서버 정보 등 ◎ 과거 RFC2616의 HTTP 헤더 분류 -> General 헤더 : 메시지 전체에 적용되는 정보가 담긴 헤더 -> Request 헤더 : 요청을 보낼 때 들어가는 정보가 담긴 헤더 -> Response 헤더 : 응답에 들어가는 메시지들이 담긴 헤더 -> Entity 헤더 : 엔티티 바디 정보가 담긴 헤더(ex: Content-Type, Content-Length) ◎ HTTP Body(RFC2616) -> 메시지 본문은 엔티티 본문을 전달하는데 사용한다. -> 엔티티 본문은 요청이나 응답에서 전달할 실제 데이터 -> 엔티티 헤더는 엔티..

현재 ec2에 스프링 서버가 올라가 있는 상황에서 https 연결과 NGINX를 이용하여 리버스 프록시 설정을 하려고 한다. ※ NGINX선택 이유 - 사실 aws의 ec2를 사용 중이라 alb를 사용하는 것이 ssl 인증서 관리 등 더 편리하겠지만 현재 aws의 rds, ec2에 대한 비용도 있어서 여기에 alb의 비용까지 더해지면 부담이 되었고, 현재 서버를 하나만 가지고 있기 때문에 굳이 로드 밸런서를 사용할 필요가 없는 상황이다.(필요 시 NGINX에서 로드 밸런싱 설정하면 된다.) 또한 NGINX의 리버스 프록시를 사용하여 클라이언트에게 서버를 감춰 서버의 보안상 안정성을 높이기 위해 NGINX를 선택했다. - 아래와 같은 구조로 서비스를 배포할 예정이다. ◎ NGINX 설치 -> ec2에 NG..