클라이언트 (Client)

클라이언트(Client)는 서버에 연결해 요청을 보내고 돌아온 응답을 받아 처리하는 프로그램, 또는 그 프로그램이 통신에서 맡는 역할입니다. HTTP 표준은 클라이언트와 서버를 특정 연결에서 프로그램이 맡는 역할로 정의하므로, 같은 프로그램이 한 연결에서는 클라이언트가 되고 다른 연결에서는 서버가 될 수 있습니다. 웹 브라우저가 가장 익숙한 예이고, 명령줄 도구, 모바일 앱, 웹 크롤러도 요청을 보내면 클라이언트입니다.

요청과 응답으로 나뉘는 클라이언트의 역할

HTTP 의미 체계를 정한 RFC 9110은 HTTP 클라이언트를 HTTP 요청을 하나 이상 보내려고 서버와 연결을 맺는 프로그램으로 정의합니다. 같은 문서에 따르면 클라이언트는 의도를 담은 요청 메시지를 만들어 원 서버로 보내고, 응답을 받으면 상태 코드와 내용을 보고 의도가 이뤄졌는지 확인한 뒤 다음에 할 일을 정합니다.

요청 메시지에는 메서드와 요청 대상이 들어가고, 필요하면 요청 조건, 클라이언트 정보, 표현 메타데이터를 담은 헤더 필드와 본문이 붙습니다. 응답 메시지에는 상태 코드가 하나씩 들어갑니다. MDN의 클라이언트-서버 개요는 메서드가 클라이언트가 원하는 동작을 나타낸다고 설명하며, 자원을 가져오는 GET, 새 자원 생성 등의 처리를 요청하는 POST, 기존 자원을 고치거나 없으면 새로 만드는 PUT, 자원을 지우는 DELETE를 예로 듭니다.

HTTP는 상태를 저장하지 않는(stateless) 프로토콜이라 요청 메시지 하나하나를 따로 해석합니다. 서버는 같은 연결로 들어온 두 요청이 같은 사용자 에이전트에서 왔다고 가정하지 않으며, 연결이 보호돼 있고 그 에이전트 전용일 때만 예외입니다. MDN 개요는 로그인 상태를 이어가는 방법으로 쿠키를 설명합니다. 서버가 발급한 식별 키를 클라이언트 쪽 쿠키에 담아 요청과 함께 보내면 서버가 그 키로 로그인 상태와 접근 권한을 확인합니다.

사용자 에이전트, 서버, 중개자와의 구분

RFC 9110은 클라이언트와 서버라는 말이 특정 연결에서 프로그램이 맡는 역할만 가리킨다고 밝힙니다. 문서가 그림으로 든 중개자 B는 A 말고도 여러 클라이언트에게서 요청을 받으면서, 같은 시간에 C가 아닌 다른 서버로 요청을 넘길 수 있습니다.

사용자 에이전트(user agent)는 요청을 시작하는 클라이언트 프로그램을 통틀어 부르는 말입니다. 같은 문서는 범용 웹 브라우저가 가장 익숙한 형태지만 전체 구현 가운데 작은 비율이라고 적고, 웹 크롤러, 명령줄 도구, 펌웨어 업데이트 스크립트, 모바일 앱, 가전제품을 다른 예로 듭니다. 요청 시점에 사람이 직접 조작하고 있을 필요도 없어서, 많은 사용자 에이전트가 백그라운드에서 실행되며 결과를 나중에 확인하도록 저장합니다.

사용자 에이전트와 원 서버 사이에는 프록시, 게이트웨이, 터널 같은 중개자가 끼어 연결이 여러 개로 나뉠 수 있습니다. 중개자 셋을 거치는 메시지는 연결 네 개를 지나갑니다. 프록시는 클라이언트가 보통 로컬 설정으로 고르는 메시지 전달 에이전트이고, 조직의 HTTP 요청을 보안 서비스, 주석 서비스, 공유 캐시를 위해 공통 중개자 하나로 모으는 데 자주 쓰입니다.

브라우저 클라이언트 코드의 동작 조건

브라우저의 JavaScript 코드는 HTTP 요청을 보내고 응답을 처리할 때 Fetch API를 쓸 수 있습니다. MDN의 Fetch API 사용 안내는 Fetch를 XMLHttpRequest를 대체하는 프로미스 기반 인터페이스로 소개합니다. fetch()는 창(window)과 워커(worker) 문맥 양쪽에서 전역 함수로 쓸 수 있고, 서버 응답을 나타내는 Response 객체로 이행되는 프로미스를 돌려주며, 기본 메서드는 GET입니다. 서버가 404 같은 오류 상태로 응답해도 fetch()는 프로미스를 거부하지 않으므로 클라이언트 코드는 응답 상태를 따로 확인합니다.

브라우저의 코드가 교차 출처 응답을 읽으려면 서버의 CORS 응답 헤더가 맞아야 합니다. fetch()의 mode 기본값은 cors이고, 단순 요청이 아니면 브라우저가 먼저 사전 요청(preflight)을 보내 서버가 알맞은 CORS 헤더로 답할 때만 실제 요청을 보냅니다. 쿠키 같은 자격 증명은 기본적으로 같은 출처 요청에만 실리며, credentials를 include로 바꿔도 서버가 Access-Control-Allow-Credentials 헤더와 클라이언트의 출처를 명시한 Access-Control-Allow-Origin 헤더를 보내지 않으면 브라우저는 호출한 코드에 네트워크 오류를 돌려줍니다.

요청과 응답 본문은 ReadableStream 객체라서 클라이언트는 응답 전체를 기다리지 않고 네트워크에서 도착하는 조각을 차례로 처리할 수 있습니다. 요청을 보내면 본문 스트림을 읽기 때문에, 본문 스트림을 이미 소비한 같은 Request 객체를 그대로 다시 보낼 수 없습니다. 요청을 중간에 취소할 때는 AbortController의 AbortSignal을 요청의 signal 속성에 넣고 abort()를 호출하며, 응답을 기다리던 fetch()는 AbortError로 거부됩니다. 응답을 이미 받았다면 아직 끝나지 않은 본문 읽기가 이 오류로 실패할 수 있습니다.