톰켓이란 무엇인가
스프링 부트는 내장 톰켓을 가진다. BUT 스프링은 아님
1. 스프링과 스프링 부트의 차이
1. 스프링 프레임워크 (Spring Framework)
스프링은 자바 엔터프라이즈 애플리케이션을 만들기 위한 포괄적인 프레임워크입니다.
IoC(제어의 역전) 컨테이너, AOP(관점 지향 프로그래밍), 트랜잭션 관리 등 다양한 엔터프라이즈 기능을 제공합니다.
스프링을 사용하면 애플리케이션 개발의 유연성과 모듈성을 높일 수 있지만, 설정이 복잡할 수 있습니다.
스프링 자체는 웹 애플리케이션 서버를 포함하지 않습니다. 웹 애플리케이션을 배포하기 위해서는 외부의 톰캣(Tomcat), 제티(Jetty) 등의 서블릿 컨테이너가 필요합니다.
2. 스프링 부트 (Spring Boot)
스프링 부트는 스프링 프레임워크를 기반으로 한, 애플리케이션을 빠르고 간편하게 개발할 수 있도록 도와주는 도구입니다.
스프링 부트는 "자동 설정(Auto-Configuration)"을 통해 복잡한 스프링 설정을 자동화하고, 기본 설정을 제공합니다. 따라서, 스프링 애플리케이션을 더 빠르게 시작하고 실행할 수 있습니다.
내장형 웹 서버(예: 톰캣, 제티, 언더토우)를 포함하고 있어, 애플리케이션을 독립적으로 실행할 수 있습니다. 이를 통해 별도의 서버 설치 없이
java -jar명령으로 애플리케이션을 실행할 수 있습니다.내장 톰캣은 스프링 부트 애플리케이션에서 기본적으로 제공되는 내장 웹 서버입니다. 외부에 설치된 톰캣에 배포할 필요 없이, 애플리케이션 내에서 톰캣 서버를 포함하여 실행할 수 있습니다.
요약
스프링은 포괄적인 엔터프라이즈 애플리케이션 개발 프레임워크입니다.
스프링 부트는 스프링을 기반으로 한 간편한 애플리케이션 개발 도구로, 내장형 톰캣 서버를 포함하고 있습니다.
따라서, 스프링 부트가 내장 톰캣 서버를 제공하는 것이 맞으며, 스프링 프레임워크 자체는 웹 서버를 포함하지 않습니다.
2. HTTP : 소켓
1) 시스템 콜(System call)
🍐 시스템 콜의 개념
프로그램이 OS 커널이 제공하는 서비스를 이용하고 싶을 때 시스템 콜을 통해 실행
시스템 콜이 발생하면 해당 커널 코드가 커널 모드에서 실행
🍐 시스템 콜의 종류
프로세스/스레드 관련
파일 I/O 관련
소켓 관련
장치(device) 관련
프로세스 통신 관련
🍐 리눅스에서 제공하는 일부 시스템 콜
리눅스는 C언어로 개발됨
2) 시스템 콜 & 인터럽트 예제 : 파일 read
🍐 전제
스레드 t1, t2
cpu : single core cpu
t1이 실행하고 있다가
read라는 시스템 콜 호출시 커널 모드로 전환
커널 모드에서는 t1의 cpu 상태 저장
파일의 위치를 찾아서 버퍼에서 읽을 수 있도록 준비 시킴
read는 block 시스템 이라 파일이 읽을 상태가 될때까지 기다려야 하기 때문에 t1을wating상태로 변환해줘야 한다.
이렇게 되면 cpu에서 일하는 스레드가 없기 때문에 스케줄링을 통해서 계속 일하게 해줘야 한다.
t2가 기다리고 있었으니
running으로 바꿔준다.
이제 유저 모드로 바뀌게 되며, 주도권을 t2가 가지고 된다.
그러고 실행 되다가.. 파일을 읽을 준비가 됐다고 하면 알려줌
뭐로 파일을 읽을 준비가 됐다고 알려줄까?
그게 바로 interrupt, 파일이 준비가 됐다는 인터럽트 발생시킴
인터럽트 처리를 위해 다시 커널모드로 전환된다.
커널모드로 갔으니, t2의 cpu 상태를 저장한다.
t1의 상태를
ready상태로 변경해 줘야 한다.t2 cpu 상태 복원
커널모드 마무리 후 유저 모드로 돌아감
t2가 실행하다가 이 방식이 멀티태스킹 방식이라 t2가 자기에게 주어진 타임슬라이트를 다 쓰면
timer라는 하드웨어를 통해 알려주게 됨이 때 알려주는 방식 또한 인터럽트이다. 타이머와 관련된 인터럽트 발생
다시 커널모드로 전환되며, t2 cpu 상태 저장
t2 ready
t1 running
t1 cpu 상태 복원
유저모드로 전환되며, 주도권 t1에게 넘어간 후 파일을 읽어올 준비가 다 끝났으니 그 작업을 하게 됨
3) 프로그래밍 언어와 시스템 콜
하드웨어 혹은 시스템 관련 기능은 어떤 프로그램이라도 반드시 시스템 콜을 통해서만 사용 가능하다.
하지만 보통 우리는 개발 시 직접 OS 시스템 콜을 사용한 적은 없었다. 그럼에도 불구하고 우리는 지금까지 파일 I/O, 네트워크 I/O, 프로세스/스레드 작업을 해왔다.
Q. 이게 어떻게 가능했던 것일까?
A. 이것은 우리가 사용하는 프로그래밍 언어들이 시스템 콜을 포장(wrapping)하여 간접적으로 사용할 수 있도록 제공했기 때문이다.
🍐 예시 java.lang.Thread class
원래대로라면 무조건 시스템 core를 필요로 하는 작업
🍐 thread.class의 일부 코드
native가 붙으면 운영체제를 보통 뜻한다.java native interface를 통해 기반이 되는 os의 시스템의 콜을 호출하게 됨 즉, 연결이 된다는 것
리눅스 기반이라면 start0() ⇒ clone이라는 시스템 콜을 호출
프로그래밍 언어는 탄생 시 자기 철학이나 입맛에 맞는 시스템 콜을 보장해서 쓸 수 있게 제공해준다.
3. 톰켓과 웹서버
1) 웹 서버 = 아파치(Apache)
요청한 파일을 응답해주는 것
HTTP 서버는 갑 즉, 을이 원하는 데이터를 가지고 있다. 그렇기 때문에 을이 갑에게 request(요청)을 한다. 이때, ip 주소를 알아야 한다.
또한 URL(Uniform Resource Location)로 만들어 자원의 위치를 요청해서 필요한 데이터를 가져올 수 있다.
response 할 때는 을의 ip주소를 몰라도 된다. 을이 요청한 ip주소 토대로 request이 자신이 누군지 밝히는데 그 정보를 토대로 그 정보에 response 해주면 된다.
이때 갑이 웹서버가 된다.
즉, 요청을 하지 않으면 응답을 할 수 없다. 왜냐하면 요청한 정보를 토대로 주소를 알기 때문이다. 만약 요청을 하지 않았는데도 알려면 소켓(socket)을 사용해야 한다. 을이 연결하는 순간 연결이 지속되어 있기 때문이다.
여기서의 자원은 static 자원 즉, 정적인 자원이다. 매번 바뀌지 않고 일치함
2) 톰켓(Tomcat)
자바 파일을 컴파일 해서 html로 번역해서 돌려준다.
자바코드를 요청하게 되면 아파치는 자바코드를 이해하지 못한다. 응답을 못한다는 것
그렇기 때문에 아파치에 톰켓을 달게 된다. 그렇게 apache가 이해하지 못하는 것을 tomcat에게 제어권을 넘겨준다. .jsp 파일에 있는 모든 자바 코드를 컴파일 한다. 컴파일 된 파일을 html로 만들어준다.
그 후 apache에게 돌려주면 받게 된다. 보통은 웹 브라우저와 통신을 하는데 웹 브라우저는 html, javascript, css, avi 등 처럼 정적인 것들만 이해할 수 있다. .jsp 파일을 받게 되면 웹 브라우저는 열리지 않고 깨지게 된다.
Last updated
