정리 아파치 톰캣 아키텍처
여러 명의 클라이언트를 받기 위한
소켓 : 80 포트
아파치 톰캣은 멀티스레드 기반으로 만들어져 있다.
소켓 80 포트는
누가 들어오길 기다리는 리스너이다.
리스너가 통신할까?
아니다! 얘는 클라이언트의 요청만 받는 애이다.
리스너가 응답까지 다 하면
다른 클라이언트의 연결을 받지 못한다.
웹브라우저에서 주소창에 엔터를 치는 행위 : GET 요청
통신을 위한 새로운 소켓을 서버 쪽에서 만들어낸다.
포트번호가 랜덤 하게(5001이라고 하자) 열린다.
새로운 소켓이 생기고 클라이언트와 연결되면
새로운 소켓은 응답만 한다.
새로운 스레드로!!
클라이언트는 리스너에게 요청하고
새로운 소켓이 응답해주는 방향을 가진다.
요청할 때마다 소켓이 만들어지는 건데
자세히 보면 서블릿이 만들어지는 것이다.
서블릿(Servlet) : 자바를 사용하여 웹페이지를 동적으로 생성하는 서버 측 프로그램
서블릿은 하나만 new 된 것인데 (클래스)
클라이언트가 요청할 때마다 만들어지는
스레드들이 이 서블릿을 공유하는 것이다.
응답이 완료되고 나면
연결되었던 선을 끊어버린다.
=> stateless
계속 유지하고 있는 것은 낭비니까!
네이버 주소를 보면 https://www.naver.com/ 이다.
https이다.
Secure 통신을 하는 것이다.
네이버의 포트번호는 443번으로 정해져 있는 포트이기 때문에
80번 포트로 디폴트 포트가 잡히지 않는 것이다.
웹 브라우저에서 F12를 누르고
주소창에 네이버 주소를 치고 엔터를 눌러 Get 요청을 하면
http 헤더 정보를 볼 수 있다.
Referrer Policy 참조 정책
- 어디서 내 사이트로 넘어왔는지 알려준다.
이런 General 정보들은 버퍼에 String으로 담기는데
만약 정책이 허용되지 않으면 버퍼에 담기지도 않는다.
request 헤더는 요청하는 애플리케이션의 http 헤더이고,
response 헤더는 응답을 해주는 서버 쪽에서 만든 http 헤더이다.
내가 요청을 할 때 실어 보낼 데이터들을
http의 Body라고 하고,
데이터에 대한 부가적인 설명들을
http의 Header라고 한다.
응답하는 쪽도 마찬가지이다!
서버로부터 응답받으면 브라우저가 예쁘게 파싱 해준다.
http 프로토콜
get(SELECT), post(INSERT), put(UPDATE), delete(DELETE)
클라이언트는 요청 시에 http 헤더와 바디를 보낸다.
그런데 Get(줘) 요청은 바디가 없다.
줄 데이터가 없고 달라고 요청하는 것이기 때문이다.
구체적인 요청은 쿼리 스트링으로 하기 때문!
Get 요청의 응답은 http 헤더와 바디가 모두 필요하다.
post(줄게) 요청은 Body가 있다.
post을 응답해줄 때는 http 바디가 있어도 되고 없어도 된다.
바디가 있을 때는 회원가입이 성공적으로 되었다는 데이터를 보낼 수도 있고
없을 때는 http 헤더에 status code가 201로 뜰 것이다. 성공적으로 생성되었다는 말이다.
put(수정해줘) 요청은 Body가 있다.
put 응답도 post 응답과 마찬가지이다.
delete(삭제해줘) 요청은 Body가 없다.
삭제는 보통 PK로 요청을 많이 한다.
PK에 대한 정보를 바디에 적지 않고 주소에 적어준다.
delete : http://localhost:80/first?id=1
이 4가지 http 요청 메서드를 CRUD라고 한다.
Create Read Update Delete
Insert Select Update Delete (DB 키워드)
Post Get Put Delete (http 요청 메서드)
좀 더 자세히 들어가 보자
클라이언트 A가
0시 0분 0초에 자바 관련 요청을 했다.
서버 소켓이 새로운 소켓을 만드는데
일단 그건 생각하지 말자!
서버 소켓이 커넥션하고
이 요청을 분석함(CPU) 0시 0분 2초
서버 입장에서 DB에 커넥션하고 줘! 요청을 한다.
(I/O행위 5초 걸림)
서버 입장에서는 디비와 일대일 통신을 한다.
DB가 응답 0시 0분 7초 (램, 하드디스크)
그동안 cpu가 노는 시간(멍 때리는 시간) 5초
-> I/O 때문에!
cpu가 멍 때리는 시간이 있다는 건
동기 프로그램이라는 것이다.
클라이언트 B가 0시 0분 1초에
자바 관련 요청을 한다.
서버 소켓은 2초가 걸리는 분석 중이니까
B는 1초 대기해야 한다.
-> 스레드 필요!!
만약 단일 스레드로 돌리게 되면
시간차 때문에 너무 많은 대기가 필요하게 된다.
서버 소켓은 메인 스레드로 요청만 받고,
분석하고 I/O 기다리는 것을
새로운 스레드에게 맡겨버려야 한다.
그래야 다른 클라이언트가 요청했을 때
대기하지 않아도 된다.
그리고 새로운 클라이언트에게 요청을 받을 때마다
새로운 스레드를 만든다.
새로운 스레드가 일하는 부분을
서블릿 클래스라고 한다.
new 되어 메모리에 뜨게 된다.
서블릿 클래스 하나를
많은 스레드들이 공유해서 사용이 가능하다.
클라이언트가 들어올 때마다 서블릿이 새로 만들어지는 게 아닌
하나를 공유하는 것이다.
메서드의 내부 스택은 요청 시에 메모리에 뜨기 때문에
공유되지 않는다.
다른 메모리 공간을 가리킨다!!
한번 new 되어 힙에 뜬 서블릿의 공간은 같지만,
t1이 실행시킨 메서드와
t2가 실행시킨 메서드의 스택 메모리 공간은 다르다.
자원이 공유될 일이 없기 때문에
동시에 접근이 가능한 것이다.
모든 요청에 관한 실행이 끝나면
응답하기 직전에 선이 연결되고,
응답한 이후 선을 끊어버린다.
그렇기 때문에 응답을 위한 소켓은
하나만 만들어 스레드로 재사용한다.
순차적으로 응답하기 때문이다.
이 소켓이 서블릿 클래스이다.
하나의 스레드가 선을 연결하고
응답을 해주는 동안 다른 스레드들은 대기하고 있는다.
순차적이니까!
DB에 read 할 때는 상관없는데
write 할 때는 DB에서 락을 걸어버려서
한 명의 연산이 끝날 때까지 다른 사람이 못 들어오게 하기 때문에 (트랜잭션!!)
스레드들이 줄을 서고 대기열을 만든다.
이때 컨텍스트 스위칭 없이 cpu가 놀고 있다.
응답이 끝난 스레드들은 응답 후에 사라질까?
스레드는 풀링(pooling) 기술을 사용한다.
톰캣은 스레드를 50개 정도 가지고 있다.
사용한 스레드들은 없애지 않고 재사용한다.
만들었다 없앴다가 하는 연산을 줄이는 것이다.
아파치는 풀링 기술을 사용해서
스레드를 50개까지 가지고 있다.
51명이 들어오면? 한 명은 계속 로딩 중인 상태이다.
더 많은 클라이언트가 들어오게 하려면
똑같은 컴퓨터를 복제하든지,
컴퓨터의 성능을 더 높이든지!
1. 요청이 들어오면 서블릿 클래스 힙에 NEW
2. 리스너가
3. 만들어놓은 서블릿 클래스 사용,
서블릿 클래스의 내부에 소켓이 있는 것,
새로운 사람이 들어왔으니까 스레드 하나 생성
아파치가 web_lab으로 들어와서
컨텍스트 패스 분석하고
webapp 자동 이동 -> a.html 찾아냄
파일을 FR로 읽고 버퍼에 담아서
클라이언트에게 응답하고 선 해제
a.jsp를 요청이 오면
아파치가 톰캣에게 위임하여
.jsp 파일 내부에 자바 관련 코드만 컴파일하고 실행해서
적절한 위치에 배치까지 해준 후
순수한 html 파일을 아파치에게 응답
-> 아파치가 클라이언트에게 응답하고 선 해제
브라우저가 자바 관련 코드를 이해하지 못하기 때문에
서버에서 처리한 후 응답하는 것이다.
[출처]
https://cafe.naver.com/metacoding
메타코딩 : 네이버 카페
코린이들의 궁금증
cafe.naver.com
메타 코딩 유튜브
https://www.youtube.com/c/%EB%A9%94%ED%83%80%EC%BD%94%EB%94%A9
메타코딩
문의사항 : getinthere@naver.com 인스타그램 : https://www.instagram.com/meta4pm 깃헙 : https://github.com/codingspecialist 유료강좌 : https://www.easyupclass.com
www.youtube.com
