


앱 개발 분야에서 계속 변화하는 환경 속에서 직관적이고 사용자 친화적인 인터페이스를 만드는 것은 어떤 프로젝트의 성공에 중요합니다.

사용자 경험을 향상시키는 데 개발자의 강력한 도구 중 하나는 툴팁입니다. 이러한 주석은 불가해하지만 정보 제공이 필요한 요소로, 사용자에게 보물 같은 도움을 제공하여 애플리케이션의 복잡성을 안내하고 그 기능을 최대한 활용할 수 있도록 돕습니다.

저희 Public에서는 최근 앱과 사용자 경험의 중요한 요소인 포트폴리오 화면을 재설계하는 데 상당한 시간과 노력을 투자했습니다.

이러한 변경 사항을 구현할 때, 회원들이 업데이트에 순조롭게 적응하면서 개선 사항을 소개받을 수 있도록 익숙함을 유지하는 것이 중요합니다. 이를 위한 툴팁 UI 구성요소는 이 목표를 달성하는 데 중요한 역할을 합니다.

<div class="content-ad"></div>

# Jetpack Compose에서 툴팁

저희 Public의 안드로이드 팀은 UI 코드 작성을 위해 Jetpack Compose를 전적으로 활용하고 있습니다. 따라서 저희의 툴팁 UI 구성 요소 또한 Compose를 기반으로 해야 합니다.

Compose 프레임워크 자체에는 내장된 툴팁 구성 요소가 없지만, 안드로이드 개발자 커뮤니티에서는 여러 대안을 제공하고 있습니다. 게다가 Compose를 위한 Material Design 3는 최근 v1.1 릴리스에서 새로운 옵션을 도입했습니다.

다양한 선택지가 있지만, 우리는 일관되게 공통된 문제에 직면해왔습니다: 모든 선택지는 컴포넌트를 부모 요소로 래핑해야 한다는 것입니다. 이 접근 방식은 선언적 UI API에서 흔한 것이지만, 유연성이 떨어지며, 특히 여러 툴팁이 있는 워크스루 화면을 개발할 때 번거로울 수 있습니다.

<div class="content-ad"></div>

이상적으로는 우리는 Modifier 기반 솔루션이 필요했습니다. 이를 통해 어떤 컴포넌트에 Modifier를 쉽게 적용하여 주변에 사용자 정의 툴팁을 표시할 수 있게 되었습니다.

# Modifiers로 도와주기

우리는 우리의 요구 사항과 완벽하게 일치하는 API를 개발하는 데 성공했습니다:

```js
@Composable
fun

<div class="content-ad"></div>

API를 사용하면 선택적 제목을 포함한 툴팁을 표시할 수 있고, 툴팁 위치 지정, 구성 요소 강조 및 기타 측면을 단순화하는 구성 옵션 배열을 제공합니다.

어떤 구성 요소에든 툴팁을 쉽게 추가할 수 있습니다:

MyComponent(
    modifier = Modifier.tooltip(
        text = "This is a tooltip",
        enabled = true
    )
)

그리고 이것이 동작 모습입니다:

<div class="content-ad"></div>

효율적으로 측정하면서 UI 구성 요소를 렌더링하기 위해 Compose 코드를 실행하는 Modifier 함수에는 @Composable 주석이 표시되어 있습니다. 이는 툴팁 자체, 반투명 오버레이 및 다양한 애니메이션을 처리하기 위해 Compose 코드를 실행하기 때문에 필요합니다.

그러나 중요한 점은 Popup 구성 요소를 활용한다는 것입니다. Popup은 현재 활동 위에 나타나는 부유 컨테이너입니다. 여러 개발자들이 익숙하지 않은 덜 알려진 구성 요소입니다. 저는 개인적으로 이에 대해 알지 못했지만 다행히도 동료 중 한 명이 지금 나의 구현을 작성하려고 할 때 (알지 못하고) 내 주의를 집중시켜 주었습니다.

코드의 다양한 세부 사항에 대해 깊이 파고들 수 있지만 지루하지 않도록 유지하기 위해 그것들을 모두 건너뛰고, 코드 자체가 말을 대신하도록 하여 우리가 생각한 구현의 간소화 버전을 제공하겠습니다.

<div class="content-ad"></div>

위의 코드 조각에서는 ArrowTooltip의 구현을 직접 해야하지만, 다행히 온라인에서 신뢰할 수 있는 많은 옵션이 있습니다. 또한, 오버레이와 툴팁이 나타날 때 각자의 애니메이션 세트를 추가하여 더욱 흥미롭게 만들 수 있습니다.

우리의 테스트에서 tooltip Modifier가 잘 작동했지만, 여전히 초기 단계에 있다는 점을 주의해야 합니다. 최적화할 부분이 있을 수 있고, 해결해야 할 몇 가지 남아 있는 버그가 있을 수도 있습니다.

사용 경험이 달라질 수 있지만, 여러분의 유용성이나 피드백 및 개선 제안에 대한 소식을 듣고 싶습니다.

시도해보고 싶다면, Google Play에서 Public 앱을 다운로드하시기를 권장합니다.
```


직관적인 인터페이스를 위한 디자인 Jetpack Compose에서 모디파이어 기반 툴팁 구현 하는 방법



현재 나의 직장에서는 구 가 사용하던 구 도로 마이그레이션을 마무리하려고 하고 있어. 여전히 예전 View 시스템을 사용하던 몇 개의 화면을 Compose로 변환하여 마이그레이션 중이야. 그리고 마이그레이션이 특별히 고통스럽지는 않았지만 한 가지 주제가 오랫동안 우리를 헷갈리게 만들고 있어: WebView 화면을 마이그레이션하는 것.

Compose에서 WebView를 사용하는 것에는 어떤 독특한 어려움이 따르고 있다. 동료 중 한 명은 "Compose는 WebView를 제대로 처리할 수 없어!" 라고 말했었지. 그럼에도 불구하고 이 마이그레이션을 완료하는 분위기에서 나는 이 주제를 깊이 파헤쳐서 가능한 최상의 해결책을 찾기로 결심했어!

# 탐색

내 탐색은 아마도 우리 모두가 Compose로 WebView 를 마이그레이션하는 여정을 시작했던 곳에서 시작되었을 것이다: 구글의 Accompanist 프로젝트에서. Accompanist 프로젝트 소개 페이지에서 설명했듯이, Accompanist 프로젝트는 Jetpack Compose를 필요로 하지만 아직 공식 지원을 받지 못한 기능을 보충하기 위한 라이브러리 그룹이야. 나는 구글 팀의 '테스트용 땅'으로 보고 있어, 그곳에서 '비공식' 해결책을 게시하고 있는 곳이라고 생각해.

<div class="content-ad"></div>

안타깝게도 Accompanist의 WebView 라이브러리는 몇 달 전에 사용 중단되었습니다. 그럼에도 불구하고 해당 API에서 우리가 필요한 경우 솔루션을 복제하고 자체 프로젝트로 계속 개발하도록 하는 노트를 저장소에 추가했습니다. 그래서 몇 시간의 추가 연구와 시행착오 끝에, 나는 이 라이브러리의 내 버전을 포크하고 사용하고자하는 WebView 구현이 내가 원하는 모든 기능을 갖추었으며 그에 상응하는 수준에 있음을 보장하기로 결정했습니다.

결심을 굳게 다지고, "composable-webview"라는 개인 저장소를 만들었습니다. 현재 여기에는 웹 뷰 문제에 대한 내 개인 솔루션이 호스팅되고 있습니다. 위에서 제안된 대로, 코드의 대부분은 Accompanist 프로젝트 자체에서 직접 가져왔지만, 제가 직접 추가한 추가 요소들도 있습니다.

다음 몇 단락에서는 저가 공개로 게시한 이 라이브러리, 그 사용 방법 및 Accompanist 이전 버전과 구별되는 몇 가지 고급 기능 등을 탐색해 볼 것입니다. Accompanist 설명서에서 직접 가져오는 부분이 많을 것이며, 기여한 곳에는 유익한 점수가 주어지기를 희망합니다!

# 시작하기

<div class="content-ad"></div>

안녕하세요! 안드로이드 프로젝트에 새로운 종속성을 추가할 때마다, 첫 번째 단계는 라이브러리를 프로젝트에 통합하는 것입니다. 해당 라이브러리는 현재 Jitpack 메이븐 저장소에 호스팅되어 있으므로 의존성을 해당 위치에서 가져오려고 시도하는지 확인하는 것이 첫 번째 단계입니다. 이를 위해 루트 build.gradle 또는 build.gradle.kts 파일을 열고 다음 줄을 repositories 블록의 맨 끝에 추가하세요:

```js
// build.gradle.kts
repositories {
  mavenCentral()
  maven { url ("https://jitpack.io") } // 이 줄 추가
}
```

이제 필요한 부분을 해결했으므로 실제 라이브러리를 프로젝트에 통합할 수 있습니다. 현대적인 안드로이드 앱은 최신 버전 카탈로그를 사용하여 의존성을 보유하고 관리하지만, 가능한 한 포괄적이 되도록 전통적인 방법으로 의존성을 가져오는 방법도 다룰 것입니다!

## 전통적인 방법을 사용한 의존성 관리

<div class="content-ad"></div>

만약 앱을 버전 카탈로그를 활용하도록 마이그레이션하지 않았다면, 해당 라이브러리를 통합하려는 모듈의 Gradle 빌드 파일을 열고 아래 줄을 종속성 블록에 추가하세요:

```js
// build.gradle.kts
dependencies {
  ...
  implementation("com.ivangarzab:composable-webview:0.6") // 이 줄을 추가하세요
}
```

## 버전 카탈로그 방법을 사용한 종속성 관리

그대신, Gradle 종속성을 관리하기 위해 버전 카탈로그 기능을 사용 중이라면 몇 가지 다른 단계가 필요합니다. 먼저 libs.versions.toml 파일을 열고 라이브러리를 Gradle 프로젝트에 통합하세요:

<div class="content-ad"></div>

```kotlin
[versions]
...
igbWebView = "0.6"

[libraries]
...
igb-webview = { group = "com.ivangarzab", name = "composable-webview", version.ref = "igbWebView" }
```

의존성을 Gradle 수준에서 선언했으므로 이제 이 WebView를 필요로 하는 모듈에 해당 의존성을 통합할 수 있습니다:

```kotlin
// build.gradle.kts
dependencies {
  ...
  implementation(libs.igb.webview) // 이 줄 추가
}
```

# 사용법

<div class="content-ad"></div>

이제 라이브러리가 프로젝트에 통합되었으므로 WebView 구현을 사용하여 필요에 맞게 작업을 시작할 수 있습니다! Accompanist 문서에서 설명한 대로 이 API의 가장 간단한 사용법은 rememberWebViewState(url) 함수 필드가 필요하며 Composable WebView을 호출하는 것뿐입니다:

```kotlin
val state = rememberWebViewState("https://your-url.com")
WebView(state = state)
```

## JavaScript 활성화

위의 코드는 URL을 로드하고 선택한 Composable 레이아웃에 표시하는 간단한 WebView을 생성합니다. 그러나 대부분의 경우 이것만으로 충분하지 않을 것입니다. 대부분의 웹 사이트는 특정 정보를 표시하거나 실행하기 위해 JavaScript를 사용합니다. 그러나 기본 WebView 구현에는 JavaScript가 활성화되어 있지 않습니다. WebView 구현에서 JavaScript를 활성화하려면 그런 기능을 달성하기 위해 추가 설정이 필요합니다.

<div class="content-ad"></div>

```kotlin
val state = rememberWebViewState("https://your-url.com")
WebView(
  state = state,
  onCreated = { webView -> webView.settings.javaScriptEnabled = true }
)
```

이 업데이트된 구현은 웹 사이트가 JavaScript에 의존하는 모든 콘텐츠를로드 할 수 있도록합니다. 그러나 Android Studio에서 빠르게 지적하듯이 WebView 구현에서 JavaScript를 활성화하면 응용 프로그램에 취약점이 발생할 수 있습니다.이 기능이 정말 필요한지 여부를 결정하기 전에 여기와 여기의 문서를 검토해주십시오.

## 백프레스 캡처

Accompanist 문서를 따르면 맞춤 WebView의 미진행 구현에서 백프레스 또는 제스처를 캡처하는 것은 captureBackPresses 매개변수를 활용하면 됩니다. WebView 구현은 기본적으로 백프레스 캡처 플래그가 활성화되어 있지만, captureBackPresses 매개변수를 활용하여 동작을 변경할 수 있습니다:

<div class="content-ad"></div>

```kotlin
val state = rememberWebViewState("https://your-url.com")
WebView(
  state = state,
  onCreated = { webView -> webView.settings.javaScriptEnabled = true },
  captureBackPresses = false
)
```

## 커스텀 WebView 서브클래싱

이 섹션에서 볼 마지막 기능은 WebView을 서브클래싱하는 내용입니다. 즉, 필요에 맞는 사용자 정의 구현이 필요할 경우 팩토리 함수 매개변수를 통해 가능합니다:

```kotlin
// 컴포저 내부
val state = rememberWebViewState("https://your-url.com")
WebView(
  state = state,
  onCreated = { webView -> webView.settings.javaScriptEnabled = true },
  captureBackPresses = false,
  factory = { context -> CustomWebView(context) }
)

// 컴포즈 외부
class CustomWebView(context: Context) : WebView(context) {
  ...
}
```

<div class="content-ad"></div>

이 기능을 사용하려면 우리가 전통적인 View 시스템에서 자체 android.webkit.Webview를 만들고 팩토리 함수 내에서 인스턴스화해야 합니다. 앞서 언급한 대로요.

# 고급 사용법

다음 섹션에서는 composable-webview 라이브러리에서 사용할 수 있는 몇 가지 고급 기능을 탐색할 것입니다. 먼저 aWebViewClient나 a WebChromeClient 그리고 WebViewNavigator를 통합하는 방법에 대해 설명하겠습니다. 그런 다음 로딩 스피너 및 우리의 기본 WebView에 대한 풀-투-새로 고침 패턴의 구현에 중점을 둘 것입니다.

## 웹 클라이언트

<div class="content-ad"></div>

View 시스템의 WebView 컴포넌트와 유사하게, Composable WebView 구현은 aWebViewClient 또는 a WebChromeClient의 사용을 허용합니다. 이 두 객체 모두 우리가로드하려는 URL에서 일부 추가 데이터를 가로채거나 받을 수 있습니다. 예를 들어, WebViewClient는 오류 또는 로딩 상태와 관련된 콜백을 받고, WebChromeClient는 웹 사이트의 아이콘이나 제목을 가져오는 데 사용할 수 있습니다.

우리의 기본 WebView Composable에 이 중 하나를 구현하려면 해당 매개 변수 필드에 AccompanistWebViewClient 또는 AccompanistWebChromeClient를 제공하기만 하면 됩니다:

```js
val state = rememberWebViewState("https://your-url.com")
val webViewClient = AccompanistWebViewClient()
val webChromeClient = AccompanistWebChromeClient()

WebView(
  state = state,
  onCreated = { webView -> webView.settings.javaScriptEnabled = true },
  client = webViewClient,
  chromeClient = webChromeClient
)
```

어느 경우에도 사용자 정의 클라이언트를 정의하지 않으면 내부적으로 기본 클라이언트가 생성되어 이러한 객체 중 하나에서 받은 정보를 추적합니다.

<div class="content-ad"></div>

## 웹 네비게이터

비슷한 방식으로, WebViewNavigator가 구성 요소 외부에서 탐색 작업을 수행하려는 경우 WebView 구현에 제공될 수 있습니다. 예를 들어, 네비게이터를 사용하여 뒤로 제스처 액션에 응답하거나 원하는대로 URL을 다시로드하는 작업을 수행할 수 있습니다.

네비게이터를 제공하는 방법은 위와 같이 작동합니다. 간단히 말해서, 모든 작업을 수행하기 위해 CoroutineScope를 수신하는 지역 인스턴스를 만들고 구성 선언 단계에서 설정하는 것입니다:

```js
val state = rememberWebViewState("https://your-url.com")
val coroutineScope = rememberCoroutineScope()
val navigator = WebViewNavigator(coroutineScope)

WebView(
  state = state,
  navigator = navigator
)
```

<div class="content-ad"></div>

## 로딩 상태 받아내기

지금까지 우리의 WebView 구현은 조금 부풀어있어 보일 수 있습니다. 그 중 일부는 아마도 생각 중이실 것입니다: "정말 그 모든 것이 필요한 걸까요?" 간단히 대답하자면 물론 NO죠. 하지만 이렇게 나중에 추가된 기능들은 더 깔끔한 동작을 위해 결합될 수 있습니다.

우리가 본 것처럼, 두 웹 클라이언트 구현 방식은 WebView의 로딩 상태를 파생하는 데 활용될 수 있습니다. WebView의 상태를 이용하여 state.loadingState를 얻고 필요에 따라 로딩 인디케이터를 만들 수 있습니다:

```js
...
val loadingState = state.loadingState
if (loadingState is LoadingState.Loading) {
  LinearProgressIndicator(
    modifier = Modifier
     .fillMaxWidth(),
    progress = { loadingState.progress },
    color = MaterialTheme.colorScheme.onSurface,
    trackColor = MaterialTheme.colorScheme.surface
  )
}
```

<div class="content-ad"></div>

클라이언트가 로딩 여부를 알 수 있는 필요한 정보를 제공하는 곳입니다. 그러나 모든 것은 이미 내부적으로 발생합니다! AccompanistWebViewClient 또는 AccompanistWebChromeClient의 사용자 정의 구현을 통해 이러한 내부 상태 변경에 대해 추가적으로 반응하고 필요한 추가 작업을 수행할 수 있습니다.

## Pull-to-Refresh

비슷한 맥락으로, WebViewNavigator를 활용하여 pull-to-refresh 패턴을 구현할 수 있으며, 이를 사용하여 명령에 따라 페이지 새로고침을 트리거하기 위해 navigator.reload() 함수를 호출할 수 있습니다:

```js
val navigator = WebViewNavigator()
// 새로고침 시
navigator.realod()
```

<div class="content-ad"></div>

이제 Pull-to-refresh 패턴을 구현하는 것은 약간 더 많은 설정이 필요하며, 자세한 내용은 다른 문서에서 설명할 것입니다. 현재 작성 중인 이 글에서는, 다음 섹션에서 우리가 이야기한 모든 내용을 완전히 구현한 것을 보여줄 것입니다. 이것은 내가 준비한 보조 Composable에 패키징되어 있는 완전한 구현입니다!

# 모두 함께 넣기

지금까지 살펴본 것처럼, Accompanist의 WebView Composable은 이미 다양한 사용자 정의 기능을 제공하고 있습니다. 그러나 초기 유연성에서 파생될 수 있는 멋진 '추가 기능'들을 고려할 때, WebViewLayout이라는 보조 Composable을 만들었습니다. 이 Composable은 이미 이러한 기능들이 많이 포장되어 있습니다!

```kotlin
@OptIn(ExperimentalMaterial3Api::class)
@Composable
fun WebViewLayout(
    state: WebViewState,
    modifier: Modifier = Modifier,
    captureBackPresses: Boolean = true,
    loadingIndicatorEnabled: Boolean = true,
    pullToRefreshState: PullToRefreshState = rememberPullToRefreshState(),
    navigator: WebViewNavigator = rememberWebViewNavigator(),
    onCreated: (WebView) -> Unit = {},
    onDispose: (WebView) -> Unit = {},
    client: AccompanistWebViewClient = remember { AccompanistWebViewClient() },
    chromeClient: AccompanistWebChromeClient = remember { AccompanistWebChromeClient() },
    factory: ((Context) -> WebView)? = null,
) { ... }
```

<div class="content-ad"></div>

이 Composable 레이아웃은 모든 장점을 갖추고 있어요: Accompanist의 WebView 구현을 활용하며 동일한 사용자 정의를 가능하게 합니다. 또한 기본 pull-to-refresh 패턴과 Composable 상단에 간단한 LinearProgressIndicator를 활성화하는 옵션이 함께 제공되어 대상 URL의 로딩 상태를 더 잘 시각화할 수 있습니다.

![이미지](https://miro.medium.com/v2/resize:fit:960/1*nOihp1geDnoIa3u3PzWx1A.gif)

이 Composable을 사용하는 것은 매우 간단하며 일반 WebView Composable보다 더 많은 설정을 필요로하지 않아요. WebViewLayout을 사용하면 loading indicator 및 pull-to-refresh 기능 추가 요구 사항을 간소화하려는 아이디어입니다. 그러나 여러분의 요구 사항이 제 것과 크게 다를 수 있다는 것을 알아야 해요.

만약 그렇다면, WebViewLayout이 원래 WebView의 사용자 정의 구현 시작점으로서 도움이 되기를 바랍니다. 또는 composable-webview 프로젝트로 Feature Request 또는 Pull Request를 제공하여 더 나은 솔루션을 함께 찾아갈 수 있도록 해 주세요!

<div class="content-ad"></div>

# 마음이 바뀌면서

이 글에서는 구글 Accompanist 라이브러리에서 사용되던 WebView의 사용에 대해 다루었는데, 이를 내가 만든 composable-webview 라이브러리로 포크 및 사용자 정의한 것을 살펴보았습니다. 그 유연한 API로 할 수 있는 멋진 트릭 몇 가지를 소개했고, 내 프로젝트 안에 있는 두 번째 Composable인 WebViewLayout의 존재를 강조했습니다. 이 레이아웃은 모든 것을 통합하여 사용자에게 위에서 언급한 기능을 단일 패키지로 제공하는 것을 목표로 합니다.

이 글이 충분히 유익했기를 바랍니다. 그러나 궁금한 점이나 우려 사항이 있으면 댓글을 남기거나 GitHub 저장소에 버그 보고서 또는 기능 요청을 직접 제출해 주시기 바랍니다. 그리고 다시 한 번 강조하지만, 저희가 기여할 수 있기를 바랍니다! 이를 더 나아지게 할 수 있다고 생각한다면 프로젝트를 포크하고(링크 아래) 고려 및 토론을 위해 풀 리퀘스트로 제출할 아이디어를 자유롭게 제안해 주세요!

👾 내 프로필 👾 | 🔗 모든 다른 링크 🔗 | 라이브러리의 저장소 👇

<div class="content-ad"></div>

![An Inquiry Into the Android WebView for Jetpack Compose](/assets/img/2024-07-19-AnInquiryIntotheAndroidWebViewforJetpackCompose_0.png)

# 자원

- [composable-webview](https://github.com/ivangarzab/composable-webview)
- [accompanist](https://google.github.io/accompanist/)
- [accompanist/web](https://google.github.io/accompanist/web/)
- [accompanist/tree/main/web](https://github.com/google/accompanist/tree/main/web)
- [안전하지 않은 URI로드에 대한 Android 개발자 문서](https://developer.android.com/privacy-and-security/risks/unsafe-uri-loading)
- [보안 팁](https://developer.android.com/privacy-and-security/security-tips)


Jetpack Compose에서 Android WebView를 사용하는 방법 정리






![이미지](/assets/img/2024-07-19-HowIstheTomcatConnectorDesigned_0.png)

오늘은 Tomcat의 설계 철학을 단계별로 분석하여, 설계자들이 이러한 시스템을 만드는 질문에 어떻게 대답했는지 이해해 보려고 합니다. 이 분석을 통해 우리는 Tomcat의 전체 아키텍처, 거시적 관점에서 복잡한 시스템을 설계하는 방법, 그리고 최상위 모듈과 그들의 관계를 설계하는 방법에 대해 배울 수 있을 것입니다.

# Tomcat의 전체 아키텍처

시스템을 설계하기 위해서는 먼저 요구 사항을 이해해야 합니다. Tomcat은 두 가지 핵심 기능을 달성하기 위해 목표를 두고 있습니다:


<div class="content-ad"></div>

- 소켓 연결을 처리하며, 네트워크 바이트 스트림을 요청(Request)과 응답(Response) 객체로 변환하는 역할을 맡고 있습니다.
- 서블릿을 로딩하고 관리하며, 특히 요청(Request) 객체를 처리합니다.

그래서 Tomcat은 이러한 작업을 각각 처리하기 위해 커넥터(Connector)와 컨테이너(Container)라는 두 가지 핵심 구성 요소를 설계했습니다. 커넥터는 외부 통신을 담당하고, 컨테이너는 내부 처리를 다룹니다.

따라서 커넥터와 컨테이너는 Tomcat 구조에서 가장 중요한 부분으로 간주될 수 있습니다. 오늘은 커넥터가 어떻게 설계되었는지 분석해보겠으며, 다음 기사에서는 컨테이너의 설계를 소개하겠습니다.

커넥터에 대해 자세히 알아보기 전에, Tomcat이 지원하는 다양한 I/O 모델과 응용 계층 프로토콜에 대한 기초를 다지겠습니다.

<div class="content-ad"></div>

## Tomcat에서 지원하는 I/O 모델

- NIO: Java NIO 라이브러리를 사용하여 구현된 Non-blocking I/O.
- NIO2: JDK 7에서 제공되는 최신 NIO2 라이브러리를 사용하여 구현된 비동기 I/O.
- APR: C/C++로 작성된 네이티브 라이브러리인 Apache Portable Runtime 라이브러리를 사용하여 구현됨.

## Tomcat에서 지원하는 응용 계층 프로토콜

- HTTP/1.1: 대부분의 웹 응용 프로그램에서 사용되는 프로토콜.
- AJP: 웹 서버(예: Apache)와의 통합에 사용됨.
- HTTP/2: 웹 성능을 크게 향상시킴.

<div class="content-ad"></div>

여러 I/O 모델 및 응용 프로그램 레이어 프로토콜을 지원하기 위해 컨테이너는 여러 커넥터에 연결될 수 있습니다. 이는 한 방에 여러 개의 문이 있는 것과 유사합니다. 그러나 개별 커넥터나 컨테이너 자체는 서비스를 제공할 수 없습니다. 기능을 제공하기 위해 함께 조립돼야 하며, 이 조립을 "서비스 구성 요소"라고 합니다. 서비스 자체는 중요한 작업을 수행하지 않지만, 단순히 커넥터와 컨테이너를 둘러싼 것입니다. 톰캣에는 유연성을 위해 여러 서비스가 있을 수 있습니다. 톰캣에서 여러 서비스를 구성함으로써 동일한 기계에 배포된 다양한 애플리케이션에 다른 포트 번호를 통해 액세스할 수 있습니다.

다음과 같은 관계 다이어그램이 제공됩니다:

![릴레이션 다이어그램](/assets/img/2024-07-19-HowIstheTomcatConnectorDesigned_1.png)

다이어그램에서 볼 수 있듯이 최상위에는 서버(Server)가 있으며, 이는 톰캣 인스턴스를 가리킵니다. 서버(Server)에는 하나 이상의 서비스가 포함되며, 각 서비스에는 여러 커넥터와 하나의 컨테이너가 포함됩니다. 커넥터와 컨테이너는 표준 ServletRequest 및 ServletResponse 객체를 사용하여 서로 통신합니다.

<div class="content-ad"></div>

# 커넥터

커넥터는 프로토콜 및 I/O 모델의 차이로부터 서블릿 컨테이너를 보호합니다. HTTP 또는 AJP인지 여부에 관계없이 컨테이너는 표준 ServletRequest 객체를 수신합니다.

커넥터의 기능 요구사항을 더 구체화할 수 있습니다. 예를 들어:

- 네트워크 포트에서 수신 대기.
- 네트워크 연결 요청 수락.
- 요청 네트워크 바이트 스트림 읽기.
- 바이트 스트림을 특정 응용 프로그램 계층 프로토콜(HTTP/AJP)에 따라 구문 분석하고 통합 Tomcat Request 객체를 생성.
- Tomcat Request 객체를 표준 ServletRequest로 변환.
- 서블릿 컨테이너를 호출하여 ServletResponse를 가져옵니다.
- ServletResponse를 Tomcat Response 객체로 변환.
- Tomcat Response를 네트워크 바이트 스트림으로 변환.
- 응답 바이트 스트림을 브라우저로 다시 보냅니다.

<div class="content-ad"></div>

요구 사항이 명확해지면 다음 고려해야 할 질문은 커넥터가 가져야 할 하위 모듈입니다. 훌륭한 모듈식 설계는 높은 응집력과 낮은 결합력을 고려해야 합니다.

- 높은 응집력은 관련성이 높은 기능이 가능한 한 집중되어 흩뿌려지지 않아야 한다는 것을 의미합니다.
- 낮은 결합력은 두 관련 모듈이 종속성을 최소화하고 가능한 한 의존도를 줄여야 하며 두 모듈 간의 강한 종속성을 피하기 위해 최대한 노력해야 합니다.

커넥터의 세부 기능 목록을 분석하면, 커넥터가 세 가지 높은 응집력 있는 기능을 수행해야 한다는 것을 알 수 있습니다:

- 네트워크 통신.
- 애플리케이션 레이어 프로토콜 구문 분석.
- Tomcat 요청/응답과 Servlet 요청/응답 간의 변환.

<div class="content-ad"></div>

따라서, Tomcat의 디자이너들은 세 가지 기능을 구현하기 위해 세 가지 구성 요소인 EndPoint, Processor 및 Adapter를 설계했습니다.

이러한 구성 요소는 추상 인터페이스를 통해 상호 작용합니다. 이 접근 방식은 변화를 캡슐화하는 장점도 가지고 있습니다. 이것이 객체 지향 설계의 본질인데, 시스템의 안정적인 부분과 빈번하게 변하는 부분을 격리시켜 재사용성을 높이고 시스템 결합을 줄이는 데 도움이 됩니다.

네트워크 통신의 I/O 모델은 변경 가능합니다. 블로킹 I/O, 비동기 I/O 또는 APR이 될 수 있습니다. 또한 응용 프로그램 계층 프로토콜도 변경 가능합니다. HTTP, HTTPS 또는 AJP일 수 있습니다. 브라우저가 보내는 요청 정보도 변경 가능합니다.

그러나 전반적인 처리 로직은 변경되지 않습니다. EndPoint는 Processor에 바이트 스트림을 제공하고, Processor는 Tomcat 요청 객체를 Adapter에 제공하며, Adapter는 ServletRequest 객체를 컨테이너에 제공하는 역할을 합니다.

<div class="content-ad"></div>

새 I/O 체계나 새 응용 계층 프로토콜을 지원해야 할 때 관련 구체 하위 클래스를 구현하기만 하면 됩니다. 상위 수준의 일반 처리 로직은 변경되지 않습니다. 

I/O 모델 및 응용 계층 프로토콜은 자유롭게 조합될 수 있으므로, NIO + HTTP 또는 NIO2 + AJP와 같이, Tomcat의 디자이너들은 네트워크 통신과 응용 계층 프로토콜 구문 분석을 함께 고려하여 ProtocolHandler라는 인터페이스를 설계하여 이 두 가변 지점을 캡슐화했습니다. 각 프로토콜 및 통신 모델의 조합은 Http11NioProtocol 및 AjpNioProtocol과 같이 해당하는 구체 구현 클래스를 갖습니다.

이러한 가변 지점 외에도 시스템에는 비교적 안정적인 부분이 있으므로, Tomcat은 이러한 안정적인 부분을 캡슐화하기 위해 일련의 추상 기본 클래스를 설계했습니다. 추상 기본 클래스 AbstractProtocol은 ProtocolHandler 인터페이스를 구현합니다. 각 응용 계층 프로토콜은 AbstractAjpProtocol 및 AbstractHttp11Protocol과 같이 자체 추상 기본 클래스를 가지며, 구체적인 프로토콜 구현 클래스는 프로토콜 계층의 추상 기본 클래스를 확장합니다. 여기서 이들의 상속 관계를 정리했습니다.

![TomcatConnectorDesign](/assets/img/2024-07-19-HowIstheTomcatConnectorDesigned_2.png)

<div class="content-ad"></div>

위 다이어그램에서 상속 및 계층적 관계를 명확하게 확인할 수 있습니다. 이 설계의 목적은 가능한 한 안정적인 부분을 추상 기본 클래스에 배치하는 것이며, 각 I/O 모델 및 프로토콜 조합에는 해당하는 구체적인 구현 클래스가 있습니다. 우리는 필요할 때 자유롭게 선택하여 사용할 수 있습니다.

요약하면, 커넥터 모듈은 세 가지 핵심 구성 요소인 Endpoint, Processor 및 Adapter를 사용하여 세 가지 작업을 수행합니다. Endpoint와 Processor는 ProtocolHandler 구성 요소로 함께 추상화됩니다. 이들 간의 관계는 아래 다이어그램에 표시되어 있습니다.

![다이어그램](/assets/img/2024-07-19-HowIstheTomcatConnectorDesigned_3.png)

다음으로, 저는 두 가지 최상위 구성 요소인 ProtocolHandler와 Adapter를 자세히 소개하겠습니다.

<div class="content-ad"></div>

## ProtocolHandler 컴포넌트

이전에 언급한 대로, 커넥터는 네트워크 연결 및 응용 프로그램 계층 프로토콜을 처리하기 위해 ProtocolHandler를 사용합니다. 이것은 두 가지 중요한 부분을 포함합니다: EndPoint와 Processor. 아래에서는 그들의 작동 원리에 대해 자세히 설명하겠습니다.

EndPoint

EndPoint는 통신 엔드포인트로, 통신 수신 및 송신 처리를 위한 인터페이스, 특정 소켓 수신기 및 송신자 처리기, 그리고 전송 계층의 추상화입니다. 따라서 EndPoint는 TCP/IP 프로토콜을 구현하는 데 사용됩니다.

<div class="content-ad"></div>

EndPoint은 인터페이스이며, 해당 추상 구현 클래스는 AbstractEndpoint입니다. AbstractEndpoint의 구체적인 하위 클래스인 NioEndpoint 및 Nio2Endpoint 등에는 Acceptor 및 SocketProcessor와 같은 두 가지 중요한 하위 구성 요소가 있습니다.

Acceptor는 소켓 연결 요청을 수신하기 위해 사용됩니다. SocketProcessor는 수신된 소켓 요청을 처리하는 데 사용됩니다. 이는 Runnable 인터페이스를 구현하고 처리를 위해 Run 메서드에서 프로토콜 처리 구성 요소 Processor를 호출합니다. 처리 능력을 향상시키기 위해 SocketProcessor는 실행을 위해 스레드 풀에 제출됩니다. 이 스레드 풀은 executor라고 하며, 나준에 자세히 소개할 것입니다. 톰캣이 기본 Java 스레드 풀을 확장하는 방법에 관한 섹션에서 자세히 설명하겠습니다.

Processor

EndPoint는 TCP/IP 프로토콜을 구현하는 데 사용되는 반면 Processor는 HTTP 프로토콜을 구현하는 데 사용됩니다. Processor는 EndPoint로부터 소켓을 수신하고 바이트 스트림을 읽은 다음 Tomcat 요청 및 응답 객체로 구문 분석하여 이를 컨테이너로 제출하여 Adapter를 통해 처리합니다. Processor는 응용 프로그램 계층 프로토콜의 추상화입니다.

<div class="content-ad"></div>

프로세서(Processor)는 요청 처리를 위한 메서드를 정의하는 인터페이스입니다. 이 외의 메서드도 정의되어 있어요. 추상 구현 클래스(AbstractProcessor)는 프로토콜의 일부 공통 속성을 캡슐화하지만 메서드는 구현되어 있지 않아요. AJPProcessor 및 HTTP11Processor와 같은 구체적인 구현은 특정 프로토콜에 대한 구문 분석 및 요청 처리 메서드를 구현합니다.

커넥터의 구성 요소 다이어그램을 살펴보죠:

![커넥터 다이어그램](/assets/img/2024-07-19-HowIstheTomcatConnectorDesigned_4.png)

다이어그램에서 볼 수 있듯이 EndPoint가 소켓 연결을 받은 후에는 소켓 프로세서(SocketProcessor) 작업을 생성하고 처리를 위해 스레드 풀에 제출합니다. 소켓 프로세서의 Run 메서드는 프로세서 컴포넌트를 호출하여 응용 계층 프로토콜을 구문 분석합니다. 프로세서가 구문 분석을 통해 요청 개체(Request object)를 생성한 후에는 어댑터의 Service 메서드를 호출할 것입니다.

<div class="content-ad"></div>

지금까지 ProtocolHandler의 전체 아키텍처와 작동 원리를 배웠습니다. EndPoint의 상세 설계에 대해서는 나중에 EndPoint가 Java NIO의 비차단 및 NIO2의 비동기 기능을 최대한 활용하여 고도의 동시성을 달성하는 방법을 구체적으로 소개할 것입니다.

어댑터 구성 요소

이전에 언급했듯이 다양한 프로토콜로 인해 클라이언트가 보낸 요청 정보도 다릅니다. Tomcat은 이 요청 정보를 "저장"하기 위해 자체 Request 클래스를 정의합니다. ProtocolHandler 인터페이스는 요청을 구문 분석하고 Tomcat Request 클래스를 생성하는 역할을 담당합니다. 그러나 이 Request 객체는 표준 ServletRequest가 아니므로 Tomcat Request를 컨테이너를 호출하기 위한 매개변수로 사용할 수 없습니다. Tomcat 설계자들이 고안한 해결책은 어댑터 패턴의 클래식한 응용 중 하나인 CoyoteAdapter를 도입하는 것입니다. 커넥터는 CoyoteAdapter의 Service 메서드를 호출하며 Tomcat Request 객체를 전달합니다. CoyoteAdapter는 Tomcat Request를 ServletRequest로 변환한 다음 컨테이너의 Service 메서드를 호출하는 역할을 합니다.

# 결론

<div class="content-ad"></div>

Tomcat의 전체 아키텍처에는 두 가지 핵심 구성 요소인 커넥터와 컨테이너가 포함됩니다. 커넥터는 외부 통신을 담당하고, 컨테이너는 내부 처리를 처리합니다. 커넥터는 통신 프로토콜 및 I/O 모델의 차이를 캡슐화하기 위해 ProtocolHandler 인터페이스를 사용합니다. ProtocolHandler 내에는 EndPoint와 Processor 두 모듈이 있습니다. EndPoint는 저수준 소켓 통신을 처리하며, Processor는 응용 프로그램 계층 프로토콜 해석을 담당합니다. 컨테이너는 Adapter를 통해 컨테이너를 호출합니다.

Tomcat의 전체 아키텍처를 공부함으로써 복잡한 시스템을 설계하는 데 기본적인 아이디어를 얻을 수 있습니다. 먼저 요구 사항을 분석하고 고응집도 및 낮은 결합도의 원리에 따라 하위 모듈을 결정합니다. 그런 다음 하위 모듈 내에서 가변성과 불변성 지점을 식별합니다. 인터페이스와 추상 기본 클래스를 사용하여 불변성을 캡슐화합니다. 추상 기본 클래스에서 템플릿 메서드를 정의하고 서브 클래스가 추상 메서드를 구현하도록하면 특정 서브 클래스가 가변성 지점을 처리하게 됩니다.

![Tomcat Connector Design](/assets/img/2024-07-19-HowIstheTomcatConnectorDesigned_5.png)

Posts