◎ 요청흐름 -> 클라이언트에서 서버로 요청을 보내면 tcp/ip 연결을 하고, 서블릿을 호출하여 응답을 보낸다. 이 서블릿을 호출하는 것이 스레드(Thread)다. ◎ 스레드 -> 프로세스 내 실행되는 소스코드의 흐름 -> 프로세스 내에 스레드는 하나만 존재할 수 있고, 여러 개가 존재할 수 있다. 동시 처리가 필요하면 스레드를 여러 개 생성한다. -> 스레드는 한 번에 하나의 코드 라인만 수행한다. ◎ 단일 스레드 -> 스레드를 하나만 사용하는 방식이다. -> 요청이 들어오기 전 초기 상태다. 스레드는 하나만 존재한다. -> 다음은 요청과 응답 과정이다. -> 요청이 들어오면 스레드를 할당하여 이 스레드가 서블릿을 호출하여 응답을 보낸다. -> 응답을 모두 마치면 다시 초기 상태로(스레드 휴식 상태)..

◎ 서블릿 -> 자바를 사용하여 웹페이지를 동적으로 생성하는 서버 프로그램 -> 다음은 클라이언트에서 POST 요청으로 서버에 데이터를 저장하는 요청을 보내는 상황이다. -> 이 상황에서 애플리케이션 서버가 해야할 일은 다음과 같다. - 서버 TCP/IP 연결 대기, 소켓 연결 - HTTP 요청 메시지 파싱하여 읽기 - POST 방식, URL 파악 - Content-Type 확인 - HTTP 메시지 바디 내용 파싱 - 저장 프로세스 실행 - 비즈니스 로직 실행 -> 데이터베이스에 저장 요청 - HTTP 응답 메시지 생성 - TCP/IP에 응답 전달 및 소켓 종료 -> 서블릿은 위의 서버가 해야할 일 중 비즈니스 로직 실행을 제외한 나머지 작업을 지원한다. -> 위 코드에서 @WebServlet애너테이션에..

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

◎ NGINX의 탄생 배경 -> NGINX 초기에는 아파치 서버의 구조적 한계를 극복하기 위해 사용되었다. -> 아파치 서버는 구조상 커넥션이 형성될 때 마다 프로세스가 생성되었다. 새로운 클라이언트의 요청이 들어오면 매번 해당 요청을 위한 프로세스가 생성되는 구조다. -> 프로세스를 생성하는 시간이 오래 걸리기 때문에 아파치에서는 프로세스를 미리 만들고 새 클라이언트의 요청이 들어오면 미리 만들어 놓았던 프로세스를 사용했다. 이 방식을 PREFORK 방식이라 한다. -> 이 구조를 통해 다양한 모듈을 만들어 서버에 빠르게 기능을 추가할 수 있었다(확장성이 높음) -> 이를 통해 동적 컨텐츠도 처리할 수 있게 되었다. -> 확장성이 좋아 요청을 받고 응답을 하는 과정을 하나의 서버에서 처리하기 좋았다. ..

◎ Web Server -> 아래 두 가지 의미가 있다. 1. 소프트 웨어적 측면으로 웹 브라우저와 같은 클라이언트로부터 HTTP 요청을 받아 *정적 컨텐츠(html, css 등)를 제공하는 프로그램 2. 하드웨어 측면으로는 1번의 기능을 제공하는 컴퓨터 프로그램을 실행하는 컴퓨터 *정적 컨텐츠 : 모든 클라이언트에 대해 동일한 응답 결과를 제공하는 컨텐츠 -> HTTP 기반으로 동작한다. -> Web Server 기능 - 클라이언트로부터 http 요청을 받는다. - 정적 컨텐츠를 제공한다. - *동적 컨텐츠 요청 시 해당 클라이언트의 요청을 WAS에 보내고 WAS에서 처리한 응답을 클라이언트에게 전달한다. *동적 컨텐츠 : 클라이언트에 따라 각각 다른 형태의 응답을 제공하는 컨텐츠 ◎ WAS(Web A..

◎ SOP(Same Origin Policy) -> 같은 *출처에서만 리소스를 공유할 수 있는 정책 *출처 : 프로토콜, 호스트, 포트를 합친 것이다. http://localhost:8080에서 프로토콜은 http, 호스트는 localhost, 포트는 8080이다. -> 만약 http://localhost:8080 출처에서 접근가능한 리소스가 있다고 가정하고, sop가 적용된 상황이라면 http://localhost:8082로는 해당 리소스에 접근할 수 없다. -> sop를 통해 다른 출처로 들어오는 악의적인 접근(ex:해커가 만든 악성 사이트에 접속하여 요청이 보내지게 되어 사용자의 정보를 탈취)으로부터 보호를 할 수 있다. -> 하지만 다른 도메인의 자원을 호출해서 사용이 필요한 경우가 있다.(ex ..