Intro
스프링 부트로 백엔드 서버를 접하다 보니 임베디드 톰캣을 사용하게 되고
그러다보니 WAS 서버가 어떻게 동작하는지 머릿속에 잘 그려지지 않는 것 같습니다.
관련된 내용의 개념적인 부분을 접하더라도 구체성을 이해하지 못하면 금방 잊게되는 것 같아서 직접 코드로 보려고합니다!
환경 구성
WAS 서버에서도 여러가지가 있지만 저는 아파치 톰캣(Apache tomcat)을 기준으로
작성해보겠습니다.
- DEVELOP LANGUAGE -> Java (Jdk 17)
아파치 동작 과정
동작의 프로세스 이미지는 다음과 같습니다.
-
Apache Process <1번 이미지>
위의 그림을 봤을때 이해가 어려운 부분은 이 부분이였습니다.
-
Apache Process <2번 이미지>
Thread Pool 과 request 처리에 대해서는 어느정도 들어보고 익숙한 부분이 있지만
Backlog라는 개념과 스레드가 실행되기전 waiting 되는 Queue 부분은 생소하게 다가와 조금 더 살펴보았습니다.
-
Backlog Process <3번 이미지>
위의 3번 이미지는 클라이언트와 서버가 TCP 통신을 할 때 3way-handshake 로
이를 처리하는 과정입니다.
3way-handshake 과정에서 단순하게 클라이언트 - '서버' 구조라고만 생각했던 부분이였는데 서버의 응답과정을 들여다보니 내부에서 backlog 응답에 대한 각각의 queue가 있는 것을 알 수 있었습니다.
- syn queue
- 서버는 클라이언트의 SYN 요청을 syn queue 에 저장한다.
- 이후 서버에서 클라이언트에게 SYN+ACK 요청을 했을 때 ACK응답이 오지 않는다면 클라이언트에게 재요청을 하게 된다.
- 재요청의 규칙은 syn queue에 설정된 요청 주기와 지정된 횟수에 따른다.
- syn queue는 SYN 폭주/ (SYN-Flood) 문제를 고려해야 한다.
- accept queue
- 클라이언트로부터 전달받은 ACK 패킷을 저장한다.
- 서버에서 Socket accept 처리 대기할 때 데이터는 accept queue에 저장된다.
(1번 이미지 참조)
- Backlog
- backlog에 의해 queue의 크기가 지정된다.
- 동기 처리, 스레드 수가 부족할 때 backlog의 크기는 수용할 수 있는 요청의 수를 의미할 수 있다. (대기를 시키므로)
그리고 이를 아파치 서버에 관점에서 보면 이렇게 동작하는 것을 확인할 수 있습니다.
-
Apache Backlog Process <4번 이미지>
-
Listen Queue, Backlog Queue 를 활용하여 클라이언트의 요청을 대기시키고 socket accpet 이전까지 요청을 대기시키는 것을 확인할 수 있습니다.
- ServerSocket 내부 코드
public class ServerSocket implements java.io.Closeable {
``` ( 생략 )
public ServerSocket(int port, int backlog) throws IOException {
this(port, backlog, null);
}
public ServerSocket(int port) throws IOException {
this(port, 50, null);
}
이후 ServerSocket 클래스에서 Backlog 를 생성자 파라미터로 설정할 수 있음을 확인했습니다.
이제 위에 개념들을 중간 요약 및 정리해보겠습니다.
(2번 이미지에 언급된 IDLE QUEUE, WORK QUEUE 개념은 어렵지는 않은 부분같아서 요약에 같이 첨언하였음)
<중간 정리>
-
syn queue와accept queue는 클라이언트의 ACK 요청과 서버의 socket accept를 위해 데이터 패킷을 저장하는 곳이며 이를 포함한 개념이 backlog
-
backlog는 서버가 동시에 처리할 수 있는 연결 요청의 최대 개수를 설정하는 값
- 즉, TCP 연결 요청의 대기열 크기를 설정하는 것.
-
Apache 서버는 idle queue에서 대기 중인 idle thread를 하나 가져와 이 클라이언트의 요청을 처리하게 합니다. 이 때 해당 스레드는 work queue로 이동하게 됩니다.
-
요청 처리가 완료된 work thread는 다시 idle queue로 이동하여 새로운 요청을 대기하게 됩니다
