HTTP, HTTPS, 그리고 API들
웹 통신이 작동하는 방식: HTTP는 요청을 구조화하고, HTTPS는 이를 보안하며, API는 소프트웨어 시스템이 상호작용하는 방식을 정의합니다.
HTTP가 해결하는 문제
TCP는 신뢰할 수 있는 연결을 제공하지만, HTTP는 클라이언트와 서버가 서로를 이해할 수 있게 해주는 구조화된 언어를 정의합니다.
- 클라이언트가 특정 리소스(파일, 데이터, API)를 공식적으로 요청하는 방식을 정의합니다.
- 메타데이터와 콘텐츠가 어떻게 패키징되고 전송되는지 표준화합니다.
- 클라이언트와 서버 사이의 명확한 요청–응답 모델을 확립합니다.
상세정보
TCP가 신뢰할 수 있는 연결을 설정하면, 두 컴퓨터는 안전하게 바이트를 주고받을 수 있습니다. 하지만 원시 바이트 자체에는 의미가 없습니다. 공유된 프로토콜이 없으면 서버는 그 바이트가 파일 요청인지, 폼 제출인지, 아니면 전혀 다른 것인지 알 수 없습니다.
HTTP(Hypertext Transfer Protocol)는 통신을 위한 구조화된 형식을 정의합니다. 클라이언트는 request(예: GET /index.html)를 보내고, 서버는 상태 정보와 데이터를 포함한 response를 반환합니다.
HTTP는 리소스를 요청하는 방법, 메타데이터를 포함하는 방법, 응답을 형식화하는 방법을 표준화합니다. 이를 통해 웹 통신은 브라우저, 서버, 플랫폼 전반에서 예측 가능하고 상호 운용 가능해집니다.
간단히 말해, TCP는 전달을 보장합니다. HTTP는 이해를 보장합니다.
HTTP 요청의 구조
HTTP 요청은 메서드, 대상 경로, 헤더, 그리고 선택적인 본문으로 구성된 구조화된 메시지입니다.
GET /users/123 HTTP/1.1 Host: api.example.com Authorization: Bearer xyz User-Agent: Browser
POST /users HTTP/1.1 Host: api.example.com Content-Type: application/json Authorization: Bearer xyz { "name": "Alice" }
- Method는 의도된 동작을 정의합니다(GET, POST, PUT, DELETE).
- Path는 요청되는 특정 리소스를 식별합니다.
- Headers and Body는 메타데이터와 선택적인 데이터 페이로드를 전달합니다.
상세정보
HTTP 요청은 request line으로 시작합니다. 여기에는 메서드와 경로가 포함됩니다. 예를 들면:
GET /users/123 HTTP/1.1
이는 서버에 어떤 동작이 요청되는지와 어떤 리소스가 대상인지 알려줍니다.
method는 의도를 전달합니다.
GET은 데이터를 가져옵니다.POST는 새 데이터를 전송합니다.PUT은 기존 데이터를 업데이트합니다.DELETE는 데이터를 삭제합니다.
headers는 Content-Type 같은 콘텐츠 타입, Authorization 같은 인증 자격 증명, 또는 User-Agent 같은 클라이언트 정보와 같은 추가 컨텍스트를 제공합니다.
마지막으로, 일부 요청에는 body가 포함됩니다. 예를 들어, POST 요청에는 서버로 전송되는 JSON 데이터가 포함될 수 있습니다.
이러한 구성 요소들이 함께 서버가 올바르게 파싱하고 해석할 수 있는 예측 가능한 구조를 만듭니다.
HTTP 응답 구조
HTTP 응답은 상태 코드, 헤더, 그리고 본문을 반환하며 — 클라이언트에게 어떤 일이 일어났는지 알려주고 요청된 데이터를 전달합니다.
HTTP/1.1 200 OK Content-Type: application/json Content-Length: 27 Cache-Control: no-cache { "id": 123, "name": "Alice" }
HTTP/1.1 404 Not Found Content-Type: application/json Content-Length: 29 Cache-Control: no-cache { "error": "사용자를 찾을 수 없음" }
- 상태 코드는 결과를 나타냅니다 (200, 404, 500).
- 헤더는 응답에 대한 메타데이터를 설명합니다.
- 본문은 클라이언트에게 반환되는 실제 콘텐츠를 포함합니다.
상세정보
HTTP 응답은 다음과 같은 상태 줄로 시작합니다:
HTTP/1.1 200 OK
상태 코드는 요청의 결과를 전달합니다.
200은 성공을 의미합니다.404는 리소스를 찾을 수 없음을 의미합니다.500은 서버 측 오류를 나타냅니다.
그다음에는 응답에 대한 메타데이터를 제공하는 헤더가 나옵니다. 여기에는 Content-Type(예: JSON 또는 HTML), Content-Length, 캐싱 규칙, 또는 보안 정책이 포함될 수 있습니다.
마지막으로 본문에는 HTML 페이지, JSON 객체, 파일과 같은 실제 요청 데이터가 포함됩니다.
응답 구조는 클라이언트가 어떤 일이 일어났는지와 어떤 데이터가 반환되었는지를 모두 이해할 수 있게 해줍니다.
HTTP가 무상태인 이유
HTTP는 각 요청을 서로 독립적으로 처리합니다 — 서버는 이전 상호작용을 자동으로 기억하지 않습니다.
- 각 요청은 서로 분리되어 처리됩니다.
- 서버는 기본적으로 이전 요청의 기억을 유지하지 않습니다.
- 상태는 명시적으로 관리해야 합니다(예: 쿠키, 토큰, 세션).
상세정보
HTTP는 무상태 프로토콜로 설계되었습니다. 즉, 클라이언트가 요청을 보내면 서버는 이전 맥락을 가정하지 않고 이를 처리합니다.
예를 들어, 웹페이지를 불러온 뒤 버튼을 클릭하면 두 번째 요청에는 첫 번째 요청의 기억이 자동으로 포함되지 않습니다. 서버가 이를 처리하는 데 필요한 모든 정보는 각 요청에 포함되어 있어야 합니다.
무상태성은 확장성을 단순하게 만듭니다. 서버가 저장된 연결 상태에 의존하지 않기 때문에, 요청을 로드 밸런서 뒤의 여러 머신에 분산할 수 있습니다.
로그인 세션이나 장바구니처럼 연속성이 필요한 애플리케이션은 쿠키, 세션 식별자, 또는 인증 토큰을 사용해 상태를 명시적으로 구현합니다.
HTTPS가 추가하는 것
HTTPS는 TCP 위에 TLS를 계층화하여 HTTP를 보호하고, 전송 중인 데이터를 안전하게 지킵니다.
- HTTPS는 클라이언트와 서버 사이의 모든 HTTP 트래픽을 암호화합니다.
- HTTPS는 디지털 인증서를 사용해 서버의 신원을 검증합니다.
- HTTPS는 암호학적 무결성 검사를 통해 변조를 방지합니다.
상세정보
HTTPS는 TLS(Transport Layer Security) 위의 HTTP를 의미합니다. HTTP 메시지를 평문으로 보내는 대신, 전송 전에 데이터를 암호화합니다.
HTTPS에서는 헤더와 본문을 포함한 HTTP 요청과 응답의 모든 내용이 암호화됩니다. 이를 통해 네트워크상의 공격자가 비밀번호나 토큰 같은 민감한 정보를 읽지 못하게 됩니다.
또한 HTTPS는 서버가 유효한 디지털 인증서를 제시하도록 요구합니다. 브라우저는 이 인증서를 신뢰할 수 있는 인증 기관(Certificate Authorities)과 대조하여 서버의 진위를 확인합니다.
추가로, TLS는 데이터가 전송 중에 수정되지 않았는지 확인하기 위해 암호학적 무결성 검사를 적용합니다.
요약하면, HTTPS는 웹 통신의 기밀성, 진위성, 무결성을 보호합니다.
TLS 핸드셰이크
암호화된 통신이 시작되기 전에, TLS는 알고리즘을 합의하고, 신원을 검증하며, 공유 암호화 키를 설정하기 위해 핸드셰이크를 수행합니다.
클라이언트
서버
클라이언트: 제가 지원하는 암호화 방식은 다음과 같습니다.
- Client Hello는 지원하는 암호화 알고리즘과 랜덤 데이터를 제안합니다.
- Server Hello + Certificate는 파라미터를 선택하고 신원을 증명합니다.
- Key Agreement는 암호화를 위한 공유 비밀값을 설정합니다.
상세정보
클라이언트가 HTTPS 서버에 연결하면, TLS는 어떤 HTTP 데이터도 전송되기 전에 먼저 핸드셰이크를 수행합니다.
이 과정은 Client Hello로 시작됩니다. 클라이언트는 지원하는 암호화 알고리즘(cipher suites)을 제안하고, 나중에 키 생성에 사용될 랜덤 데이터를 보냅니다.
서버는 암호화 파라미터를 선택한 Server Hello로 응답합니다. 또한 신뢰할 수 있는 Certificate Authority가 서명한, 자신의 공개 키를 포함한 디지털 인증서도 전송합니다.
클라이언트는 인증서를 검증하고 key agreement 과정(예: Diffie-Hellman)을 수행합니다. 양쪽은 이 값을 직접 전송하지 않고도 동일한 공유 비밀값을 독립적으로 도출합니다.
핸드셰이크가 완료되면 대칭 암호화 키가 설정되고, 이후의 모든 HTTP 트래픽은 암호화됩니다.
인증서 및 신뢰
디지털 인증서를 사용하면 클라이언트가 공격자가 아니라 정상적인 서버와 통신하고 있음을 확인할 수 있습니다.
- 인증 기관(CA)은 서버의 신원을 서명하고 검증합니다.
- 인증서에는 서버의 공개 키가 포함됩니다.
- 브라우저는 신뢰를 설정하기 전에 도메인 소유권을 검증합니다.
상세정보
디지털 인증서는 **인증 기관(CA)**이라고 하는 신뢰할 수 있는 제3자가 발급합니다. CA는 인증서를 요청한 조직이 실제로 해당 도메인 이름을 제어하고 있는지 확인합니다.
인증서에는 도메인에 대한 식별 정보와 함께 서버의 공개 키가 포함됩니다. 이 공개 키는 TLS 핸드셰이크 동안 암호화된 통신을 설정하는 데 사용됩니다.
브라우저가 웹사이트에 연결할 때, 이미 신뢰하는 CA가 서명한 인증서인지 확인합니다. 브라우저에는 신뢰할 수 있는 인증 기관 목록이 기본으로 포함되어 있습니다.
인증서가 유효하고, 만료되지 않았으며, 요청한 도메인과 일치하면 브라우저는 보안 연결을 진행합니다. 그렇지 않으면 경고를 표시합니다.
따라서 HTTPS에서의 신뢰는 다음과 같은 체인에 기반합니다:
당신은 CA를 신뢰함 → CA는 서버를 신뢰함 → 당신은 서버를 신뢰함.
API란 무엇인가?
API는 소프트웨어 시스템이 예측 가능한 방식으로 통신할 수 있게 하는 구조화된 계약을 정의합니다.
- 시스템이 외부 클라이언트에 노출하는 작업 집합을 정의합니다.
- 요청 구조, 인증, 응답 형식에 대한 엄격한 계약을 설정합니다.
- 내부 구현과 외부 소비자를 분리하는 안정적인 경계를 만듭니다.
상세정보
**API(Application Programming Interface)**는 소프트웨어 구성 요소가 상호작용하는 방식을 정의하는 공식 명세입니다. 어떤 작업을 사용할 수 있는지, 그리고 그 작업에 어떻게 접근하는지를 규정합니다.
웹 시스템에서 API는 일반적으로 HTTP를 사용합니다. 클라이언트는 GET 또는 POST 같은 정의된 메서드를 사용해 특정 엔드포인트(예: /users/123)로 요청을 보냅니다.
API는 또한 예상되는 요청 형식(예: 요청 본문의 JSON)과 서버가 반환하는 응답 형식의 구조를 정의합니다.
API가 없으면 시스템은 문서화되지 않은 규칙이나 강하게 결합된 통합에 의존하게 됩니다. API는 명확한 경계를 만들어 독립적인 개발, 확장성, 그리고 서비스 간 상호운용성을 가능하게 합니다.
REST API
REST는 HTTP 메서드와 리소스 기반 URL을 사용하여 예측 가능하고 확장 가능한 웹 API를 만드는 아키텍처 스타일입니다.
GET /users/42
{
"id": 42,
"name": "Alex",
"role": "admin"
}- RPC 스타일의 작업이 아니라, 리소스와 그 표현을 중심으로 API를 구성합니다.
- 의도를 표현하기 위해 표준 HTTP 의미론을 사용합니다(GET = 안전한 읽기, POST = 생성 등).
- 수평 확장을 가능하게 하기 위해 상태 비저장(stateless) 상호작용을 강제합니다.
상세정보
REST(Representational State Transfer)는 API를 작업이 아니라 리소스를 중심으로 구성합니다. 리소스는 /users 또는 /orders/123 같은 URL로 표현됩니다.
URL에 동사를 넣는 대신, REST는 HTTP 메서드를 사용해 작업을 정의합니다:
GET은 데이터를 조회합니다.POST는 새 데이터를 생성합니다.PUT은 기존 데이터를 업데이트합니다.DELETE는 데이터를 삭제합니다.
REST API는 상태 비저장(stateless) 이므로, 각 요청에는 필요한 모든 정보가 포함됩니다. 서버는 현재 요청을 처리하기 위해 이전 요청에 의존하지 않습니다.
대부분의 REST API는 JSON 형식으로 데이터를 주고받습니다. JSON은 가볍고, 사람이 읽기 쉬우며, 기계가 쉽게 파싱할 수 있습니다.
이러한 구조는 REST API를 일관되고 확장 가능하며, 분산 시스템 전반에서 쉽게 이해할 수 있게 만듭니다.
일반적인 HTTP/HTTPS/API 실패 시나리오
모든 웹 실패가 같은 계층에서 발생하는 것은 아닙니다 — 오류는 애플리케이션 로직, 전송 계층, 또는 TLS 보안에서 발생할 수 있습니다.
- 404 찾을 수 없음 → 애플리케이션 수준 라우팅에서 리소스를 찾지 못함.
- 500 내부 서버 오류 → 서버에서 내부 처리 오류가 발생함.
- 연결 거부 또는 SSL 인증서 오류 → 전송 계층 또는 TLS 계층 실패.
상세정보
404 찾을 수 없음 오류는 서버에는 도달할 수 있지만, 요청한 경로나 리소스가 존재하지 않는다는 뜻입니다. 이는 일반적으로 애플리케이션 수준의 라우팅 문제입니다.
500 내부 서버 오류는 요청이 서버에 도달했지만, 실행 중에 어떤 문제가 발생했음을 나타냅니다 — 예를 들어 크래시, 처리되지 않은 예외, 또는 데이터베이스 실패 등이 있습니다.
연결 거부 오류는 스택의 더 앞단에서 발생합니다. 클라이언트가 TCP 연결을 설정할 수 없으며, 이는 보통 서버가 내려가 있거나 대상 포트에서 수신 중인 프로세스가 없기 때문입니다.
SSL 인증서 오류는 TLS 핸드셰이크 중에 인증서가 유효하지 않거나, 만료되었거나, 도메인과 일치하지 않을 때 발생합니다. 브라우저는 사용자를 보호하기 위해 연결을 차단합니다.
혼합 콘텐츠 경고는 HTTPS 페이지가 HTTP 리소스를 로드하려고 할 때 나타납니다. 이는 HTTPS의 보안 보장을 깨뜨리므로 최신 브라우저에서 경고로 표시됩니다.
실패가 어디에서 발생했는지 — 애플리케이션, 전송 계층, 또는 TLS — 를 이해하는 것은 효과적인 디버깅에 매우 중요합니다.
질문 섹션
1 / 5