Tomcat 10.1.44 Release Note 요약 및 정리

Byneoclova

 

안녕하세요.

Tomcat 10.1.44 Release의 내용은 다음과 같이 정리 해보았습니다.

 

[목차]

  1. 아카이브 인덱싱 안정화 (Bloom Filter 수정)
  2. Keep-Alive 누락 수정
  3. HPACK 정수 오버플로우 수정
  4. HTTP/2 문서 개선
  5. DeltaManager에 enableStatistics 속성 추가
  6. WebSocket 확장 기능 처리 개선
  7. 독립된 favicon 제공
  8. 기타 개선사항

 

각 항목에 관한 자세한 설명은 다음과 같습니다.

 

  1. 아카이브 인덱싱 안정화 ( Bloom Filter 수정 )

Bloom Filter를수정하여 JAR 파일을 포함하는 압축된 웹 애플리케이션 아카이브(WAR)를 처리할 때, 아카이브 인덱싱을 위한 Bloom Filter의 동작을 수정 했습니다. 이는 성능과 정확성 향상에 기여합니다.

  • 개요

Tomcat 등 서버 환경에서 WAR 파일 안에 포함된 JAR 파일을 아카이브(Archive)로 처리할 때,Bloom Filter를 이용하여 인덱싱 여부를 판단합니다.

기존 로직에서는 패키지된 WAR 안의 JAR 파일이 여러 개일 경우 Bloom Filter에 제대로 반영되지 않는 문제가 발생합니다.

때문에 인덱싱 누락 가능, 검색/조회 성능 저하 및 안정성 문제가 발생할 수 있습니다.

# Bloom filter란?

– 확률적(probabilistic) 자료 구조로, 어떤 원소가 집합에 속하는지 여부를 빠르게 검사하기 위해 사용합니다.

예를 들어, 우체통에 붙어 있는 스티커를 보고 이 편지는 아마 여기에 있을 수 있다(→ 확인 필요) 혹은 절대 없다(→ 확인 불필요)를 결정하는 방식입니다.

 

  1. Keep-Alive 누락 수정

비동기 요청 후 HTTP/1.1 연결에 대한 Keep-Alive Timeout 설정이 누락된 문제를 수정했습니다.

  • 개요

HTTP/1.1에서는 비동기 요청을 처리하는 동안 HTTP 연결이 오래 열려 있어야 하는데,

Keep-Alive Timeout 설정을 짧게 해 놓으면 연결이 끊길 수 있었습니다.

  • 개선사항

이번 버전에서는 HTTP/1.1 비동기 요청 처리 중에는 타임아웃이 무시되거나 연결이 안전하게 살아있도록 연장 되도록 하였습니다.

 

  1. HPACK 정수 오버플로우 수정

HPACK 디코딩 사용 HPACK(HTTP/2 헤더 압축)에서 정수 디코딩 시 발생할 수 있는 오버플로 문제를 두 차례에 걸쳐 수정했습니다. 이를 통해 HTTP/2 통신 시 안정성을 높였습니다.

   # HPACK 압축방식이란?

– 헤더 값을 압축할 때, 가변 길이 정수(Variable-length Integer)라는 방식을 사용합니다.

쉽게 말하면, 숫자 들을 고정된 바이트 수로 할당하지 않고, 그 숫자가 들어갈 공간만 할당해서 공간을 아끼는 방법입니다.

1 → 4byte: 공간낭비, 1 → 1byte: 적절

50000 → 4byte 적절

  • 개요

어떤 숫자가 너무 커서 자바 정수형(Integer)이 표현할 수 있는 최대값을 넘어가면,

숫자가 이상하게 바뀌거나 음수로 변하는 산술 오버플로(overflow) 가 발생할 수 있습니다.

예를 들어, 최대값이 100인데 150을 넣으려 하는 상황과 비슷합니다.

이런 경우 헤더가 잘못 해석되거나 서버가 오류를 낼 수 있습니다.

  • 개선사항

이 문제를 두 단계로 방지했습니다.

① 오버플로 방지: 숫자가 정수 범위를 넘어가면 에러로 처리

② 한도 검사: HPACK 규격상 허용되는 최대값(Integer.MAX_VALUE)보다 큰 값은 처리하지 않음

→ 이렇게 해서 헤더를 안전하게 디코딩하고, 서버가 이상 상태에 빠지지 않도록 안정성을 높였습니다.

 

  1. HTTP/2 문서 개선

HTTP/2 문서 업데이트: HTTP/2 오버헤드에 대한 문서를 업데이트하여 PRIORITY 프레임의 사용 중단됨을 명확히 하고, 스트림 리셋이 항상 오버헤드를 증가시킨다는 점을 명확히 했습니다.

 # PRIORITY 프레임이란?

HTTP/2 프로토콜에서 쓰이는 특별한 제어 프레임(Control Frame)입니다.

클라이언트(예: 브라우저)가 서버에

“이 스트림(요청/응답)은 중요도가 높으니까 우선적으로 처리해줘!” 라고 알릴 때 사용합니다.

예를들어 웹페이지 로딩 시

HTML 문서는 최우선, CSS/JS는 그 다음, 이미지들은 나중.

이런 식으로 리소스 다운로드 순서를 조정할 수 있었습니다.

또한 리소스 간 의존 관계 표현합니다.

“이 JS 파일은 HTML이 먼저 와야 실행 가능해” 같은 관계를 서버에 알려줄 수 있었죠.

 

  • 개요

그러나 PRIORITY 프레임은 서버와 브라우저에서 우선순위 정보를 일관되게 처리하지 못하고, 브라우저마다 다르게 동작하는 애로사항이 있었습니다.

CDN, 프록시, 서버 구현이 제각각 → 제대로 활용되지 못함

  • 개선사항

그러므로 HTTP/2의 PRIORITY 프레임은 사실상 잘 안 쓰이고, 비효율적이라 판단되어, 기능이 중단되게 되어, 이를 HTTP/2 표준문서에 표시하게 합니다.

# 스트림 리셋이란?

어떤 스트림이 필요 없거나 에러가 났을 때, 그 스트림을 강제로 종료하는 동작입니다.

HTTP/2에서는 이때 RST_STREAM 프레임을 사용해요.

클라이언트 또는 서버가 보낼 수 있죠.

쉽게말해서, “이 스트림은 여기서 끝! 더 이상 데이터 안 주고받음”이라고 알리는 것입니다.

예로,

사용자가 다운로드를 중간에 취소했을 때 (브라우저에 있는 중지버튼)

서버가 요청을 처리하다가 문제가 생겼을 때 (권한이 없거나 리소스가 없어짐으로 인해)

클라이언트가 더 이상 응답을 기다릴 필요가 없을 때 (이미 캐시 있음)

위와 같은 상황에서 쓰입니다.

  • 개요

스트림 리셋이 일어나면, 단순히 끊고 끝이 아닙니다.

이미 전송 중이던 데이터는 버려지고, RST_STREAM 프레임 자체도 네트워크 트래픽이 되고, 양쪽(클라이언트/서버) 모두 스트림 상태를 정리해야 해서 CPU 자원 소모가 됩니다.

따라서 리셋이 잦으면 성능 저하와 리소스 낭비가 생기게 됩니다.

  • 개선사항

그러므로 이에 대한 경고를 HTTP/2 문서에 기입합니다.

  1. DeltaManager에 enableStatistics 속성 추가

DeltaManager는 클러스터의 각 노드에 세션의 변경 내용만 전송해서 세션 상태를 동기화하는 매니저입니다. (모든 노드에 델타를 전송하는 all-to-all 방식)

  • 개선사항

enableStatistics 라는 설정을 통해 DeltaManager가 세션 관련 통계를 수집하도록 할 수 있게 되었습니다. Tomcat 설정에서 이 속성의 기본값은 true입니다.

server.xml

<Cluster className=”org.apache.catalina.ha.tcp.SimpleTcpCluster”>

<Manager className=”org.apache.catalina.ha.session.DeltaManager”

enableStatistics=”true”

notifyListenersOnReplication=”true”/>

…

</Cluster>
  1. WebSocket 확장 기능 처리

WebSocket 클라이언트 확장 기능 처리 방식이 서버의 방식과 일치하도록 변경되었습니다.

  • 개요

클라이언트 웹소켓은 자기가 실제 지원하지 않는 확장도 요청(Request)에 넣는 경우가 있었습니다.

Tomcat 내부적으로 구현된 WebSocket 클라이언트 (다른 서버와 연결할 때 사용되는 부분)가 실제로는 처리할 수 없는 확장까지도 서버에게 요청 목록에 포함해서 보내는 경우가 있었습니다.

이는 비표준적이거나 예상치 못한 동작을 유발할 수 있습니다. 예를 들어, 압축 기능을 지원하지 못하면서 압축 확장을 요청하는 식입니다.

  • 개선사항

문제가 되었던 WebSocket 클라이언트의 확장 요청 로직을 수정했습니다.

수정 후에는 클라이언트가 Tomcat WebSocket 서버가 확장을 요청하는 방식과 동일하게 요청하도록 바뀌었습니다.

즉, 클라이언트는 이제 실제로 지원하고 처리할 수 있는 확장만을 요청 목록에 포함하여 보냅니다.

 

  1. 독립된 favicon 제공

Manager 및 Host Manager 웹 애플리케이션에 전용 favicon을 제공하여, ROOT 애플리케이션의 favicon 에 의존하지 않도록 했습니다.

  • 개요

이전에는 이 웹앱들이 ROOT 웹앱의 favicon을 사용하도록 되어 있었습니다.

문제점: ROOT 앱이 없거나 다른 favicon을 쓰면, Manager/Host Manager의 탭 아이콘이 일관되지 않거나 없을 수 있음

  • 개선사항


tomcat

tomcat10.1.43 → tomcat 10.1.44 로 변경되면서

각 웹앱 디렉토리(webapps/manager, webapps/host-manager)에 favicon.ico 파일이 추가됩니다.

이제 브라우저는 이 웹앱에 접속하면 전용 아이콘을 표시합니다.

그래서 ROOT 웹앱의 favicon에 의존하지 않습니다.

 

  1. 기타 개선사항
  • Checkstyle 업데이트 → v10.26.1
  • 다국어 개선

– 프랑스어 번역 향상

– 일본어 번역 향상 (기여자: tak7iji)

개인적으로 Tomcat 10.1.44 업데이트는 안정성과 표준 준수 측면에서 꽤 의미 있는 개선이 많다고 볼 수 있을 것 같습니다.

그래서 서버 운영자 입장에서는 업그레이드할 만한 충분한 가치가 있다고 생각되어지네요.

감사합니다.

 

 

자유롭게 댓글을 달아주세요! 언제나 환영합니다.
기타 문의:  info@neoclova.co.kr
네오클로바 기술블로그 홈 바로가기: https://neoclova.net
네오클로바 홈페이지: http://neoclova.co.kr

 

Post Views: 47

Similar Posts

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다