네트워크 1편 - HTTP 프로토콜

kkosang·2025년 6월 8일

network

목록 보기

1/4

들어가며

앱 개발자 뿐만 아니라, 프론트 개발을 하면 자연스럽게 서버와 통신하게 된다. 서버와 통신을 하기 위해서 안드로이드는 Retrofit이나 OkHttp 같은 라이브러리를 사용하여 네트워크 요청을 처리하고 데이터를 받아온다. 하지만 “네트워크 요청을 보낸다 라는 것이 구체적으로 어떤 흐름으로 동작하는지 알고 있나?” 라는 질문에 명확하게 대답하지 못할 것 같다. DNS 조회부터 TCP 연결, HTTP 요청 전송, 그리고 응답 수신까지 여러 단계를 거치고 있다. 이러한 과정을 모른 채, 네트워크 이슈가 발생하면 원인파악 조차 힘들 것이라고 생각한다. 따라서 그러한 문제가 발생했을 때 잘 대처하기 위해 이번 글에서는 안드로이드 앱에서 HTTP 요청이 어떻게 동작하는지, 네트워크 흐름을 단계별로 알아보자.

프로토콜 (Protocol)

두 개 이상의 통신 주체 (서버-클라이언트, 앱-앱)가 작업을 함께 수행하기 위해 미리 약속한 규칙을 의미한다.

사람 사이의 대화를 한 번 생각해보자. 보통 사람들은 서로 대화를 나눌 때 “인사 → 자기소개 → 본론” 같은 일정한 순서를 자연스럽게 지킨다. ~~다짜고자 본론부터 이야기 하는 사람은 프로토콜을 안지키는걸루..~~

컴퓨터 사이에서의 통신도 이와 유사하다. 컴퓨터가 서로 데이터를 주고받을 때에도 미리 약속된 순서와 형식을 지키는데 이러한 약속이 바로 네트워크 프로토콜이다.

네트워크 프로토콜

조금 더 구체적인 예시를 들어 알아보자.

만약 클라이언트(A)가 서버(B)로부터 사용자 정보를 얻고 싶어서 아래와 같은 요청을 보냈다.

GET/users/1

이러한 요청을 받은 서버는 프로토콜에 따라 다음과 같이 행동한다.

요청을 보낸 클라이언트가 1번 사용자의 정보를 요청했다는 사실을 인지한다.
요청을 처리한 후, 클라이언트가 이해할 수 있는 형태(JSON)로 응답을 전달한다.

클라이언트에게 전달된 형태는 아래와 같다.

{
  "id": 1,
  "name": "kkosang",
  "email": "kshyun0724@naver.com"
}

즉, 프로토콜은 무엇을 요청했고, 어떤 응답을 기대할 수 있는지에 규칙이다.

HTTP 요청

우리는 이제 프로토콜이 무엇인지 위의 설명으로 파악했다. 네트워크 프로토콜의 종류로는 여러가지 (HTTP(S), TCP/IP, UDP,SMTP,DNS)등이 있지만 그 중 앱에서 가장 많이 사용하는 HTTP 네트워크 프로토콜에 대해서 알아보자.

HTTP (Hypertext Transfer Protocol)

HTTP는 우리가 흔히 웹이나 앱에서 볼 수 있는 요청(Request)과 응답(Response)을 처리하는 표준적인 방법이다.

HTTP 통신은 기본적으로 클라이언트가 요청(Request)을 보내고, 서버가 응답(Response)하는 구조로 되어 있다.

각 요청과 응답 메시지는 크게 다음과 같은 형태를 가진다.

요청 메시지 (Request Message)
응답 메시지 (Response Message)

HTTP 요청메시지(Request)

클라이언트가 서버에게 무언가를 요청할 때 보내는 메시지로, 기본적인 구조는 아래 예시 사진과 같다.

요청메시지의 기본 구조를 파악했으니, 예시를 통해 각 line에 어떤 것이 들어가야할지 알아보자.


GET /users/1 HTTP/1.1
Host: api.example.com
Authorization: Bearer {access-token}
Accept: application/json

요청 라인(Request Line):
- GET: 서버에게 데이터를 요청하겠다는 메서드(method)
- /users/1: 요청할 자원의 경로(1번 사용자)
- HTTP/1.1: HTTP 프로토콜의 버전
헤더(Header):
- Host: 요청을 보낼 서버의 주소
- Authorization: 인증 정보(토큰)
- Accept: 클라이언트가 원하는 데이터 형태(JSON)

일반적으로 GET 요청에는 Body가 없고, POST나 PUT 같은 메서드는 본문을 추가할 수 있다.

HTTP 응답메시지(Response)

클라이언트의 요청을 서버에서 처리한 후, 결과를 반환할 때 사용하는 메시지로, 기본적인 구조는 아래 예시 사진과 같다.

응답 메시지 또한 예시를 통해 각 line에 대해서 알아보자.

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 1,
  "name": "kkosang",
  "email": "kshyun0724@naver.com"
}

상태 라인(Status Line):
- HTTP/1.1: 프로토콜 버전
- 200 OK: 요청이 성공했다는 상태 코드 및 메시지
헤더(Header):
- Content-Type: 서버가 응답 본문으로 보내는 데이터 타입(JSON)
메시지 본문(Body):
- 실제 데이터 (JSON 형식사용)

HTTP 상태 코드 (Status Code)

클라이언트의 요청이 항상 성공적으로 처리되는 것은 아니다. 요청 도중 네트워크 연결이 끊어지거나 여러가지 이유로 요청이 실패할 수 있다. 이때 서버에서 요청의 결과를 숫자로 알려주는 것이 HTTP 상태 코드이다.
상태 코드는 상태 라인 (Status Line)에 포함되어 클라이언트가 요청 결과로 받을 수 있다.

상태코드의 종류

상태코드는 100번대 부터 500번대까지 크게 5가지 범위로 나뉘어 표현된다.

상태 코드 범위	의미	설명
1xx (정보)	정보 제공	요청을 잘 받았고, 계속 처리 중이라는 중간 알림
2xx (성공)	성공	요청이 정상적으로 처리됨
3xx (리다이렉트)	추가 작업 필요	클라이언트가 다른 위치로 이동해야 함
4xx (클라이언트 오류)	요청 문제	요청 자체에 오류가 있음 (잘못된 요청, 인증 문제 등)
5xx (서버 오류)	서버 문제	서버 내부에서 문제가 발생해 요청 처리 실패

아래는 요청의 결과로 주로 받을 수 있는 상태코드이다.

200번대 (성공)

200 OK : 요청 성공
201 Created: 새 리소스 생성 성공 (POST 등에서 사용)
204 No Content: 요청 성공, 반환할 데이터 없음

300번대 (리다이렉트)

301 Moved Permanently: URL이 완전히 변경됨
302 Found: 임시로 다른 URL로 이동

400번대 (클라이언트 오류)

400 Bad Request: 잘못된 요청 (파라미터 오류 등)
401 Unauthorized: 인증 실패 (토큰 없음, 로그인 필요 등)
403 Forbidden: 권한 부족 (접근 권한 없음)
404 Not Found: 요청한 자원을 찾을 수 없음

500번대 (서버 오류)

500 Internal Server Error: 서버 내부 오류
502 Bad Gateway: 게이트웨이/프록시 서버 문제
503 Service Unavailable: 서버가 현재 사용 불가

마치며

HTTP 요청이 실제로 어떻게 구성되어 있고, 어떻게 동작하는지 기본적인 구조와 흐름을 단계별로 살펴보았다. 그 동안 Retrofit에 의존하여, 내부에서 어떤 과정을 거치는지 잊고있었다. 다음 글에서는 HTTP 요청이 실제로 어떤 경로로 전송되고, DNS 조회, TCP 연결 등 더 구체적인 전송 과정을 알아볼 예정이다.

kkosang

다음 포스트