🤔okhttp(심화) 내부 Intercepter github 코드 분석해보기

이전에 okhttp의 개념과 애플리케이션에서 사용할 수 있는 네트워크 인터셉터와 애플리케이션 인터셉터에 대해 공부했다.

공부하며 서버에서 401을 응답하면 OkhttpClient 의 Authenticator 가 자동으로 실행되고 재요청을 보낼 수 있다.

분명 G리는 기술인데…

어떻게 이게 가능한거지? 궁금해서 okhttp의 github에 들어가게 되었다.

우선 어떤 인터셉터들이 있는지 보겠습니다.

인터셉터의 종류

어떤 인터셉터들이 있는지 확인하기 위해서 RealCall 파일에 들어갔습니다.

    val interceptors = mutableListOf<Interceptor>()
    interceptors += client.interceptors
    interceptors += RetryAndFollowUpInterceptor(client)
    interceptors += BridgeInterceptor(client.cookieJar)
    interceptors += CacheInterceptor(client.cache)
    interceptors += ConnectInterceptor
    if (!forWebSocket) {
      interceptors += client.networkInterceptors
    }
    interceptors += CallServerInterceptor(forWebSocket)

오… 우선 인터셉터들을 mutableListOf 로 관리를 하고 있구만…

이제 어떤 인터셉터들이 있는지 확인해 보겠습니다.

client.interceptors

클라이언트(Android)에서 설정한 애플리케이션 인터셉터 들이 해당됩니다.

RetryAndFollowUpInterceptor

 // * This interceptor recovers from failures and follows redirects as necessary. It may throw an
 // * [IOException] if the call was canceled.

요청 실패 및 리다이렉트 처리를 담당합니다.

이녀석이 바로 서버에서 401을 내려주면 Authenticator 를 실행시키고 재요청을 할 수 있게 해주는 아주 고마운 녀석입니다.

이 친구가 어떻게 401을 받으면 Authenticator 를 실행시키고 재요청을 보내는지는 다음 포스팅에서 다루도록 하겠습니다.

---

BridgeInterceptor

/**
 * Bridges from application code to network code. First it builds a network request from a user
 * request. Then it proceeds to call the network. Finally it builds a user response from the network
 * response.
 */

앱 코드에서 네트워크 코드로 가는 다리 역할 을 합니다.

 쉽게 말하면 OkHttp 내부에서 “사용자 요청 ↔ 실제 HTTP 요청”을 연결하는 중간처리기 역활을 합니다.

요청(Request) 표준화

• User-Agent, Accept-Encoding, Content-Type, Content-Length 등을 자동으로 추가
• Gzip 압축 요청 여부도 여기서 설정됩니다.

요청 바디 처리

• POST, PUT 등의 요청에 Body가 있는 경우, Content-Length 혹은 Transfer-Encoding: chunked를 자동 설정합니다.

응답(Response) 변환

• 네트워크로부터 받은 응답(Response)을 사용자 응답 형태로 변환합니다.

---

CacheInterceptor

/** Serves requests from the cache and writes responses to the cache. */

HTTP 및 HTTPS 응답을 파일 시스템에 저장하여 이후 재사용할 수 있도록 하는 역할을 합니다.

캐시를 사용하기 위해 OkHttpClient 를 설정할 때 Cache 를 설정해줘야 합니다.

val cacheSize = 50L * 1024L * 1024L // 50 MiB
val cache = Cache(File(application.cacheDir, "http_cache"), cacheSize)

val client = OkHttpClient.Builder()
    .cache(cache)
    .build()

이렇게 설정하면 OkHttp는 서버의 Cache-Control 헤더를 기반으로 응답을 캐시합니다. 서버가 해당 헤더를 제공하지 않는 경우, 클라이언트 측에서 인터셉터를 사용하여 캐시 동작을 제어할 수 있습니다.

즉, 네트워크에서 받은 응답이 캐시 가능하면 이를 저장하여 이후 동일한 요청 시 재사용할 수 있도록 합니다.

---

ConnectInterceptor

 * Opens a connection to the target server and proceeds to the next interceptor. The network might
 * be used for the returned response, or to validate a cached response with a conditional GET.

서버와 실제 소켓 연결(TCP/HTTPS) 을 설정합니다

즉, 실제로 서버와 연결을 수행하는 친구입니다.

이 친구가 없으면 서버와 연결이 안됩니다.

---

client.networkInterceptors(네트워크 인터셉터)

클라이언트에서 추가하는 네트워크 수준의 인터셉터(웹 소켓이 아닌경우)

---

CallServerInterceptor

/* This is the last interceptor in the chain. It makes a network call to the server. /

최종적으로 서버와 통신하여 요청을 보내고 응답을 받는 역활을 합니다.

 CallServerInterceptor를 거쳐 진짜 HTTP 통신이 시작됩니다.

1.	writeRequestHeaders: 요청 헤더 전송
2.	writeTo: 요청 바디 전송 (POST, PUT 등)
3.	finishRequest: 요청 종료
4.	readResponseHeaders: 응답 헤더 수신
5.	openResponseBody: 응답 바디 수신
6.	응답 객체 Response 빌드 후 반환

---

chain.proceed(request)

위에서 Intercepter 들의 종류와 역활에 대해 알아봤습니다.

그러면 어떻게 이런 형태로 동작하게 되는걸까요?

이러한 역활을 수행할 수 있게 해주는 RealInterceptorChain 에 대해 알아보겠습니다.

class RealInterceptorChain(
  internal val call: RealCall,
  private val interceptors: List<Interceptor>,
  private val index: Int,
  internal val exchange: Exchange?,
  internal val request: Request,
  internal val connectTimeoutMillis: Int,
  internal val readTimeoutMillis: Int,
  internal val writeTimeoutMillis: Int,
) : Interceptor.Chain {

}

//RealCall.kt
val chain = RealInterceptorChain(...)
	  val interceptors = mutableListOf<Interceptor>()
    interceptors += client.interceptors
    interceptors += RetryAndFollowUpInterceptor(client)
    interceptors += BridgeInterceptor(client.cookieJar)
    interceptors += CacheInterceptor(client.cache)
    interceptors += ConnectInterceptor
    if (!forWebSocket) {
      interceptors += client.networkInterceptors
    }
    interceptors += CallServerInterceptor(forWebSocket)
 try {
      val response = chain.proceed(originalRequest)
      if (isCanceled()) {
        response.closeQuietly()
        throw IOException("Canceled")
      }
      return response
    } catch (e: IOException) {
      calledNoMoreExchanges = true
      throw noMoreExchanges(e) as Throwable
    } finally {
      if (!calledNoMoreExchanges) {
        noMoreExchanges(null)
      }
    }

우선 Interceptor.Chain interface를 사용하고 있는 모습입니다.

RealCall 파일에서는 chain을 RealInterceptorChain(...) 으로 생성해서 chain.proceed 을 실행한 response를 반환하고 있습니다.

어떻게 RealInterceptorChain 이 동작하는지 한번 알아보겠습니다.

RealInterceptorChain 은 Interceptor.Chain 인터페이스를 사용하고 있기 때문에

override fun proceed(request: Request): Response 를 꼭 override 해야 합니다.

실제로 RealCall 파일에서 .proceed를 호출하는 구현부가 이곳이기도 하구요.

어떻게 구현했는지 보겠습니다.

private var calls: Int = 0

class RealInterceptorChain(
  internal val call: RealCall,
  private val interceptors: List<Interceptor>,
  private val index: Int,
  internal val exchange: Exchange?,
  internal val request: Request,
  internal val connectTimeoutMillis: Int,
  internal val readTimeoutMillis: Int,
  internal val writeTimeoutMillis: Int,
) : Interceptor.Chain {
  private var calls: Int = 0

  internal fun copy(
    index: Int = this.index,
    exchange: Exchange? = this.exchange,
    request: Request = this.request,
    connectTimeoutMillis: Int = this.connectTimeoutMillis,
    readTimeoutMillis: Int = this.readTimeoutMillis,
    writeTimeoutMillis: Int = this.writeTimeoutMillis,
  ) = RealInterceptorChain(
    call,
    interceptors,
    index,
    exchange,
    request,
    connectTimeoutMillis,
    readTimeoutMillis,
    writeTimeoutMillis,
  )
@Throws(IOException::class)
  override fun proceed(request: Request): Response {
    check(index < interceptors.size)

    calls++

    if (exchange != null) {
      check(exchange.finder.routePlanner.sameHostAndPort(request.url)) {
        "network interceptor ${interceptors[index - 1]} must retain the same host and port"
      }
      check(calls == 1) {
        "network interceptor ${interceptors[index - 1]} must call proceed() exactly once"
      }
    }

    // Call the next interceptor in the chain.
    val next = copy(index = index + 1, request = request)
    val interceptor = interceptors[index]

    @Suppress("USELESS_ELVIS")
    val response =
      interceptor.intercept(next) ?: throw NullPointerException(
        "interceptor $interceptor returned null",
      )

    if (exchange != null) {
      check(index + 1 >= interceptors.size || next.calls == 1) {
        "network interceptor $interceptor must call proceed() exactly once"
      }
    }

    return response
  }
 }

우선 각 변수, 함수들에 대해 알아보겠습니다.

• exchange: Exchange?
  • 네트워크 교환(실제 소켓이나 HTTP 스트림 등)을 나타내며, 네트워크 인터셉터 단계에서 사용됩니다.
    만약 네트워크 인터셉터 외의 단계라면 null일 수 있습니다.
• calls
  • 전체 HTTP 요청/응답 사이클을 대표하는 RealCall 인스턴스로, 호출과 관련된 전반적 정보를 포함합니다
• index: Int
  • 현재 체인에서 실행할 인터셉터의 인덱스입니다.
    이 값이 증가하면서 인터셉터들이 순차적으로 호출됩니다.

• request: Request
  • 현재 처리 중인 HTTP 요청 객체입니다.

이제 proceed 함수가 어떻게 동작하는지 보겠습니다.

1. 체인 인덱스 검증

   check(index < interceptors.size)

   • 현재 index가 전체 인터셉터 리스트의 크기보다 작은지 확인합니다
   • 만약 index가 인터셉터의 개수를 초과했다면 논리 오류가 발생하게 됩니다

2. 호출 카운트 증가

   calls++

   • 현재 인터셉터가 proceed()를 호출한 횟수를 기록합니다.
   • 네트워크 인터셉터는 반드시 한 번만 proceed()를 호출해야 하므로 이를 검사할 기반이 됩니다.

3. 네트워크 인터셉터에 대한 추가 검증 (exchange가 있을 경우)

   if (exchange != null) {
     check(exchange.finder.routePlanner.sameHostAndPort(request.url)) {
       "network interceptor ${interceptors[index - 1]} must retain the same host and port"
     }
     check(calls == 1) {
       "network interceptor ${interceptors[index - 1]} must call proceed() exactly once"
     }
   }

   • 현재 요청(request)이 이전에 사용한 라우트 플래너의 호스트와 포트와 동일한지 확인합니다.
   • 네트워크 인터셉터는 요청의 목적지가 변경되면 안 됩니다.
   • 현재 인터셉터가 proceed()를 한 번만 호출했는지 확인합니다.

4. 다음 체인 준비

   val next = copy(index = index + 1, request = request)

   • 현재 체인 상태를 복사하면서 인덱스를 1 증가시킵니다.
   • 새 객체(next)는 다음 인터셉터가 처리할 체인 정보를 담고 있습니다
   • 여기서 copy를 하는 이유는  불변성(immutability) 및 상태 보호를 위해서 입니다.

   각 인터셉터가 호출될 때마다 원본 체인의 상태(예를 들어, 현재 인덱스, 요청 정보, 타임아웃 값 등)를 그대로 유지하면서 새로운 변경된 값을 적용해야 합니다.
   이를 위해 copy()를 통해 새로운 체인 객체를 생성하면, 이전 체인의 상태에 영향을 주지 않고 안전하게 상태를 업데이트할 수 있습니다. 즉, 한 인터셉터에서 발생한 변경이 다른 인터셉터에 부정적인 영향을 주지 않게 됩니다.

5. 인터셉터 선택

   val interceptor = interceptors[index]

   • 현재 인덱스에 해당하는 인터셉터를 선택합니다.

6. 인터셉터(index +1) 실행

   @Suppress("USELESS_ELVIS")
   val response =
     interceptor.intercept(next) ?: throw NullPointerException(
       "interceptor $interceptor returned null",
     )

   • 선택된 인터셉터의 intercept() 메서드를 호출하면서, 새 체인(next)을 전달합니다.
   • 인터셉터의 결과로 Response 객체를 받아옵니다.

7. 네트워크 인터셉터에 대한 후처리 검증 (exchange가 있을 경우)

   if (exchange != null) {
     check(index + 1 >= interceptors.size || next.calls == 1) {
       "network interceptor $interceptor must call proceed() exactly once"
     }
   }

   • 만약 현재가 네트워크 인터셉터 관련 체인이라면, 다음 체인(next)에서 proceed()가 정확히 한 번 호출되었는지 다시 확인합니다.

8. 응답 반환

   return response

   • 최종적으로 응답 객체를 반환하며, 이는 체인을 거쳐 최종적으로 서버에서 받은 응답일 수도 있고, 중간 인터셉터에서 변환된 응답일 수도 있습니다.

자세히 다루진 않았지만 RealInterceptorChain 파일에서

withConnectTimeout, withReadTimeout, withWriteTimeout 메서드를 통해 타임아웃을 조정할 수 있습니다.

또한 네트워크 인터셉터에서는 이 Timeout을 변경할 수 없도록 제한합니다.

공부를 하면서 왜 이름을 Chain 이라고 네이밍을 한 지 알게되었습니다.

잘못된 정보가 있다면 알려주시면 감사하겠습니다!!🙏

네트워킹이 이루어지는 과정을 도식화한 그림으로 마무리 하겠습니다. 읽어주셔서 감사합니다!

요청

응답