was 구현기

Tomcat은 Java Servlet과 JSP의 레퍼런스 구현체로, Java 기반 웹 애플리케이션을 실행하기 위한 기본 환경을 제공한다.Java로 작성된 웹 애플리케이션은 HTTP 요청을 처리할 수 있는 컨테이너가 필요하다.톰캣은 이 역할을 수행하며, Spring MV

WAS ThreadPool 크기, Docker CPU 제한, JMeter 요청 쓰레드 수의 조합에 따라 WAS 성능 분석도구측정 지표총 27개 경우의 테스트 수행, 각 조합당 100개 요청모든 조합에서 실패 없음 (SuccessRate = 100%)CPU의 코어수 보다

미니 톰캣을 구현하면서 keep-alive 옵션을 지원하기 위해 하나의 소켓으로 여러 요청을 처리하는 구조를 만들었다. RequestHandler는 InputStream과 OutputStream을 재사용하면서 여러 요청을 반복 처리하고, 마지막에 소켓을 닫는 방식으로

이게 맞는진 모르겠지만 제 생각대로 설계해 봤습니다.HTTP Keep-Alive를 지원하는 커스텀 WAS를 구현해보며, 커넥션을 재사용할 수 있는 구조를 설계했다.ConnectionManager, ConnectionContext, RequestHandler가 협력하여,

HTTP/1.1부터는 기본적으로 Keep-Alive가 활성화되어 있다.이는 하나의 TCP 커넥션을 여러 HTTP 요청/응답에 재사용하는 방식이다.클라이언트가 Connection: keep-alive 헤더를 요청에 포함시키면,서버는 해당 커넥션을 일정 시간 동안 유지한

톰캣처럼 동작하는 서블릿 기반 WAS를 구현해보면서, 자연스럽게 내부 구조에 대한 의문이 들기 시작했다.톰캣은 잘 만들어진 소프트웨어고, 실제 현업에서도 수많은 트래픽을 안정적으로 처리한다. 그런데 구조를 따라 만들다 보니, 이런 생각이 들었다:"톰캣은 내부 의존성을

HTTP 요청을 처리하면서 URL path와 method에 따라 다른 동작을 실행해야 하는 경우는 백엔드 개발의 가장 기본적인 문제다.처음에는 조건문으로 시작했지만, API가 많아질수록 유지보수성과 확장성에 문제가 있을거 같았다.분기 처리 코드가 더러워진다.각 기능별

Spring 구조를 참고했습니다오늘은 직접 구현 중인 WAS에서 라우팅과 메서드 실행 구조를 설계했다.핵심은 요청 -> DTO 매핑 -> 메서드 실행 -> 응답이라는 흐름을 어떻게 깔끔하고 확장 가능하게 만들 것인가였다.내가 고려했던 대안, 참고한 Spring의 구조,

WAS를 구현하며 표준화된 플로우를 따라 개발 하도록 만들고 싶었다. 일관성과 확장 가능성을 확보하고, 흐름을 제어하기 위해 아래와 같은 제약을 두었다.Filter, Dispatcher, Handler 인터페이스/추상클래스로 정해진 실행 순서와 시그니처를 강제.Han

WAS를 직접 구현하면서 쿠키를 다루다 보니, 세션 쿠키를 디폴트로 만들기 위해 max-age를 음수값으로 설정했다.하지만 브라우저에서 확인해보니 쿠키가 아예 존재하지 않았다.코드를 살펴봤지만 문제를 못찾았고, RFC 문서를 찾아보았다.RFC 6265 §4.1.2.2(

java.lang.IllegalStateException: Recursive update 예외가 발생했다.싱글톤 객체 생성 중, 동일 객체를 다시 요청하는 상황이 고려되지 않았다.computeIfAbsent는 초기화 중 같은 key가 다시 요청되면 이를 "중복 업데이트