스프링은 내장 톰켓을 가진다.

HTTP : 소켓

1. 시스템 콜(System call)

🍐 시스템 콜의 개념

• 프로그램이 OS 커널이 제공하는 서비스를 이용하고 싶을 때 시스템 콜을 통해 실행
• 시스템 콜이 발생하면 해당 커널 코드가 커널 모드에서 실행

🍐 시스템 콜의 종류

1. 프로세스/스레드 관련
2. 파일 I/O 관련
3. 소켓 관련
4. 장치(device) 관련
5. 프로세스 통신 관련

🍐 리눅스에서 제공하는 일부 시스템 콜

• 리눅스는 C언어로 개발됨

2. 시스템 콜 & 인터럽트 예제 : 파일 read

🍐 전제

• 스레드 t1, t2
• cpu : single core cpu

1. t1이 실행하고 있다가 read라는 시스템 콜 호출시 커널 모드로 전환

2. 커널 모드에서는 t1의 cpu 상태 저장
3. 파일의 위치를 찾아서 버퍼에서 읽을 수 있도록 준비 시킴
4. read는 block 시스템 이라 파일이 읽을 상태가 될때까지 기다려야 하기 때문에 t1을 wating 상태로 변환해줘야 한다.

5. 이렇게 되면 cpu에서 일하는 스레드가 없기 때문에 스케줄링을 통해서 계속 일하게 해줘야 한다.

• t2가 기다리고 있었으니 running으로 바꿔준다.

6. 이제 유저 모드로 바뀌게 되며, 주도권을 t2가 가지고 된다.
7. 그러고 실행 되다가.. 파일을 읽을 준비가 됐다고 하면 알려줌

뭐로 파일을 읽을 준비가 됐다고 알려줄까?

그게 바로 interrupt, 파일이 준비가 됐다는 인터럽트 발생시킴

8. 인터럽트 처리를 위해 다시 커널모드로 전환된다.
9. 커널모드로 갔으니, t2의 cpu 상태를 저장한다.
10. t1의 상태를 ready 상태로 변경해 줘야 한다.
11. t2 cpu 상태 복원

12. 커널모드 마무리 후 유저 모드로 돌아감
13. t2가 실행하다가 이 방식이 멀티태스킹 방식이라 t2가 자기에게 주어진 타임슬라이트를 다 쓰면 timer라는 하드웨어를 통해 알려주게 됨
14. 이 때 알려주는 방식 또한 인터럽트이다. 타이머와 관련된 인터럽트 발생

15. 다시 커널모드로 전환되며, t2 cpu 상태 저장

• t2 ready
• t1 running
• t1 cpu 상태 복원

16. 유저모드로 전환되며, 주도권 t1에게 넘어간 후 파일을 읽어올 준비가 다 끝났으니 그 작업을 하게 됨

3. 프로그래밍 언어와 시스템 콜

하드웨어 혹은 시스템 관련 기능은 어떤 프로그램이라도 반드시 시스템 콜을 통해서만 사용 가능하다.

하지만 보통 우리는 개발 시 직접 OS 시스템 콜을 사용한 적은 없었다. 그럼에도 불구하고 우리는 지금까지 파일 I/O, 네트워크 I/O, 프로세스/스레드 작업을 해왔다.

Q. 이게 어떻게 가능했던 것일까?

A. 이것은 우리가 사용하는 프로그래밍 언어들이 시스템 콜을 포장(wrapping)하여 간접적으로 사용할 수 있도록 제공했기 때문이다.

🍐 예시 java.lang.Thread class

• 원래대로라면 무조건 시스템 core를 필요로 하는 작업

Thread thread = new Thread();
thread.start();

🍐 thread.class의 일부 코드

1. native가 붙으면 운영체제를 보통 뜻한다.
2. java native interface를 통해 기반이 되는 os의 시스템의 콜을 호출하게 됨 즉, 연결이 된다는 것
3. 리눅스 기반이라면 start0() ⇒ clone이라는 시스템 콜을 호출
4. 프로그래밍 언어는 탄생 시 자기 철학이나 입맛에 맞는 시스템 콜을 보장해서 쓸 수 있게 제공해준다.

톰켓과 웹서버

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 파일을 받게 되면 웹 브라우저는 열리지 않고 깨지게 된다.