HTTP 요청과 응답 구조: Request Line·Header·Body·Status Code 이해하기

HTTP 요청과 응답 구조: Request Line·Header·Body·Status Code 이해하기#

1장 HTTP 요청 한 번에는 무엇이 들어 있을까#

주차관제 장비가 중앙 Server로 차량 입차 Event를 전송한다고 생각해보겠습니다.

Application에서는 단순히:

입차 Event 전송

이라고 표현할 수 있습니다.

하지만 Network에서는 실제로 여러 단계가 일어납니다.

장비 Application
↓
HTTP Request 생성
↓
TCP
↓
IP
↓
Ethernet
↓
Network
↓
Server
↓
HTTP Request Parsing
↓
Application 처리

HTTP 관점에서 가장 먼저 이해해야 할 것은 하나의 Request가 크게 다음 요소로 구성된다는 점입니다.

Request Line
Header
빈 줄
Body

예:

POST /api/events HTTP/1.1
Host: parking.example.com
Content-Type: application/json
Content-Length: 58

{"deviceId":"gate-01","eventType":"vehicle-enter"}

이 짧은 Message 안에:

무엇을 할 것인지

어디로 보낼 것인지

어떤 형식인지

실제 데이터가 무엇인지

가 모두 들어 있습니다.

2장 Request Line은 HTTP 요청의 첫 문장이다#

HTTP/1.1 요청의 첫 줄에는 보통 다음 정보가 들어갑니다.

METHOD 경로 HTTP-Version

예:

GET /api/status HTTP/1.1

각 부분을 나누면:

GET
→ HTTP Method

/api/status
→ Request Target

HTTP/1.1
→ HTTP Version

입니다.

이 한 줄만 읽어도 Server가 어떤 요청을 받았는지 상당 부분 알 수 있습니다.

HTTP Method는 무엇을 하려는지 나타낸다#

REST API에서 많이 사용하는 Method는 다음과 같습니다.

Method 일반적인 용도
GET Resource 조회
POST Resource 생성 또는 작업 요청
PUT Resource 전체 교체
PATCH Resource 일부 수정
DELETE Resource 삭제

예:

GET /api/gates/gate-01

이라면 Gate 정보를 조회하는 API로 설계할 수 있습니다.

반대로:

POST /api/events

라면 새로운 Event를 Server에 전달하는 API가 될 수 있습니다.

단 실제 의미는 API Specification이 결정합니다.

3장 Header는 요청에 대한 추가 정보를 전달한다#

Request Line 다음에는 Header가 이어집니다.

예:

Host: parking.example.com
Content-Type: application/json
Authorization: Bearer TEST_TOKEN
User-Agent: GateController/1.0

Header는 실제 업무 데이터라기보다 HTTP Message를 어떻게 처리해야 하는지 알려주는 부가 정보에 가깝습니다.

Host#

Host: parking.example.com

어느 Host를 대상으로 하는 요청인지 나타냅니다.

하나의 Server가 여러 Domain을 처리하는 환경에서도 중요합니다.

Content-Type#

Content-Type: application/json

Body가 어떤 형식인지 알려줍니다.

예:

application/json
text/plain
application/octet-stream
multipart/form-data

등이 있습니다.

Authorization#

Authorization: Bearer ...

API 인증 정보가 들어갈 수 있습니다.

운영 환경에서는 이런 인증 정보를 Log에 그대로 남기지 않도록 주의해야 합니다.

4장 Body에는 실제 업무 데이터가 들어간다#

POST나 PUT, PATCH 같은 Request에서는 Body에 데이터를 넣는 경우가 많습니다.

예:

{
  "deviceId": "gate-01",
  "eventId": "evt-001",
  "eventType": "vehicle-enter"
}

이 부분이 Application이 실제로 처리할 업무 데이터입니다.

주차관제 시스템이라면 Body에:

Device ID

Event ID

차량 감지 시각

차량번호

Gate ID

Sensor 상태

등이 포함될 수 있습니다.

다만 개인정보가 포함된다면 Log나 Packet Capture를 다룰 때 별도 보호가 필요합니다.

Header와 Body는 빈 줄로 구분한다#

HTTP/1.x Text Message에서는 Header가 끝난 뒤 빈 줄이 나타납니다.

개념적으로:

Header
Header
Header
\r\n
Body

입니다.

즉:

CRLF CRLF

가 Header 영역의 끝을 나타냅니다.

HTTP Message를 직접 Parsing하거나 Raw Traffic을 분석할 때 중요한 경계입니다.

5장 Content-Length는 Body 크기를 알려준다#

다음 Request를 보겠습니다.

POST /api/events HTTP/1.1
Host: parking.example.com
Content-Type: application/json
Content-Length: 18

{"status":"open"}

Content-Length는 Message Body의 길이를 Byte 단위로 나타냅니다.

Server는 이를 통해:

Body가 몇 Byte인지

판단할 수 있습니다.

문자 수와 Byte 수를 혼동하면 안 된다#

ASCII 문자만 있으면 문자 수와 Byte 수가 같아 보일 수 있습니다.

하지만 UTF-8 한글은 여러 Byte를 사용합니다.

예:

{"status":"열림"}

처럼 한글이 포함되면:

문자 수
≠
Byte 수

가 될 수 있습니다.

따라서 직접 Content-Length를 계산해야 하는 구현에서는 실제 Encoding된 Byte Length를 기준으로 해야 합니다.

6장 HTTP Response는 어떻게 생겼을까#

Server가 Request를 처리하면 Response를 보냅니다.

예:

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

{"status":"connected"}

Response 역시 크게:

Status Line
Header
빈 줄
Body

구조입니다.

Status Line#

첫 줄:

HTTP/1.1 200 OK

을 나누면:

HTTP/1.1
→ Version

200
→ Status Code

OK
→ Reason Phrase

입니다.

실제 Application Logic에서는 주로 Status Code를 기준으로 처리합니다.

7장 Status Code는 무엇을 알려줄까#

HTTP Status Code는 크게 다음 범위로 나뉩니다.

범위 의미
1xx 정보
2xx 성공
3xx Redirect
4xx Client 쪽 요청 문제
5xx Server 쪽 처리 문제

대표적인 Code는 다음과 같습니다.

200 OK
→ 일반적인 성공

201 Created
→ 새로운 Resource 생성

204 No Content
→ 성공했지만 반환 Body 없음

400 Bad Request
→ 요청 형식이나 값 문제

401 Unauthorized
→ 인증 필요 또는 인증 실패

403 Forbidden
→ 권한 부족

404 Not Found
→ Resource를 찾지 못함

409 Conflict
→ 현재 Resource 상태와 요청 충돌

500 Internal Server Error
→ Server 내부 오류

502 Bad Gateway
→ Gateway 또는 Proxy 상위 연결 문제

503 Service Unavailable
→ 일시적으로 Service 처리 불가

504 Gateway Timeout
→ Gateway가 상위 Server 응답을 기다리다 Timeout

200이라고 업무가 완료됐다는 뜻은 아닐 수 있다#

이 부분은 장비 연동에서 특히 중요합니다.

예를 들어 Server가:

HTTP/1.1 200 OK

를 반환했다고 하겠습니다.

이것이 반드시:

차단기가 실제로 열렸다.

는 의미는 아닙니다.

API가:

Command를 정상적으로 접수했다.

는 의미로 200을 반환했을 수도 있습니다.

실제 흐름은:

HTTP Request
↓
Server 수신
↓
200 OK
↓
Command Queue 저장
↓
장비 명령 전송
↓
Gate Motor 동작
↓
Sensor 확인

일 수 있습니다.

따라서 HTTP 성공과 실제 업무 완료를 분리해서 판단해야 합니다.

8장 HTTP Message와 TCP Packet은 같은 것이 아니다#

HTTP를 공부할 때 가장 많이 생기는 오해 중 하나입니다.

HTTP Request 하나
=
TCP Packet 하나

가 아닙니다.

HTTP/1.1은 일반적으로 TCP 위에서 전달됩니다.

구조를 단순화하면:

HTTP Message
↓
TCP Byte Stream
↓
TCP Segment
↓
IP Packet
↓
Ethernet Frame

입니다.

하나의 HTTP Request가 여러 TCP Segment에 나뉠 수 있습니다.

하나의 Header가 여러 Segment에 나뉠 수도 있다#

Application에서는:

POST /api/events HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 100

...

라는 하나의 Message를 보냈지만 Packet Capture에서는:

TCP Segment 1
POST /api/events HTTP/1.1
Host: exam

TCP Segment 2
ple.com
Content-Type: application/json
...

TCP Segment 3
Body...

처럼 보일 수 있습니다.

이것은 반드시 오류가 아닙니다.

TCP는 Application에게 Message가 아니라 순서가 있는 Byte Stream을 제공합니다.

Packet Capture 한 줄만 보고 HTTP Message가 잘렸다고 판단하지 않는다#

Wireshark에서 특정 Packet 하나를 열었는데 Header 일부만 보인다고 해서:

HTTP Header가 손실됐다.

고 단정하면 안 됩니다.

다음 TCP Segment에 이어질 수 있기 때문입니다.

따라서 HTTP 분석에서는 개별 Packet뿐 아니라 TCP Stream 전체를 재구성해서 보는 것이 중요합니다.

9장 TCP ACK와 HTTP Response도 서로 다르다#

TCP와 HTTP를 함께 보다 보면 ACK의 의미를 혼동하기 쉽습니다.

TCP ACK는:

TCP Byte를 상대 TCP Stack이 수신했다.

는 Transport Layer의 확인입니다.

HTTP Response:

HTTP/1.1 200 OK

는:

HTTP Application이 Request를 처리한 결과

입니다.

그리고 실제 업무 완료는 또 다른 문제입니다.

TCP ACK
↓
Network 전달

HTTP 200
↓
Application 요청 처리

Gate Open Sensor
↓
실제 물리 동작 완료

이렇게 세 단계가 모두 다릅니다.

10장 Keep-Alive는 왜 사용하는가#

HTTP Request를 보낼 때마다 TCP Connection을 새로 만든다면 다음 과정이 반복될 수 있습니다.

TCP 연결
↓
HTTP Request
↓
HTTP Response
↓
TCP 종료

요청이 자주 발생하면 Connection 생성 비용이 누적됩니다.

그래서 HTTP/1.1에서는 하나의 TCP Connection을 여러 Request·Response에 재사용할 수 있습니다.

개념적으로:

TCP Connection
│
├─ Request 1 / Response 1
├─ Request 2 / Response 2
├─ Request 3 / Response 3
└─ ...

입니다.

Keep-Alive가 무조건 좋은 것은 아니다#

장비가 수천 대라면 Server가 많은 Idle Connection을 계속 유지해야 할 수도 있습니다.

반대로 1초마다 상태를 전송하는 장비가 매번 TCP를 새로 연결하면 불필요한 비용이 생길 수 있습니다.

따라서:

Request 빈도

동시 장비 수

Server Connection Limit

NAT

Firewall Timeout

Proxy 설정

등을 고려해야 합니다.

단순히 저빈도면 끊고 고빈도면 유지한다는 규칙만으로 결정하기보다 실제 환경을 측정하는 것이 좋습니다.

11장 Timeout과 Retry를 잘못 설계하면 중복 요청이 생긴다#

카메라가 Server에 입차 Event를 보냈다고 하겠습니다.

POST /api/events
eventId = evt-100

Server는 실제로 Event를 저장했습니다.

그런데 Response가 Network 문제로 장비에 도착하지 않았습니다.

장비 입장에서는:

응답 없음

입니다.

그래서 같은 Event를 다시 보냅니다.

POST /api/events
eventId = evt-100

Server가 단순히 매번 새 Event로 저장하면 중복 Data가 생깁니다.

Event ID와 Idempotency가 필요한 이유#

Server는:

eventId = evt-100

을 이미 처리했는지 확인할 수 있습니다.

처음:

evt-100
→ 저장

재전송:

evt-100
→ 이미 처리됨

으로 판단합니다.

API에 따라 Idempotency-Key 같은 별도의 값을 사용할 수도 있습니다.

핵심은 Timeout이 발생했다고 최초 요청이 처리되지 않았다고 단정할 수 없다는 것입니다.

12장 GET과 POST의 재시도 위험도는 다를 수 있다#

예:

GET /api/status

같은 조회 요청은 일반적으로 동일한 요청을 다시 보내더라도 Server 상태를 직접 변경하지 않도록 설계하는 것이 보통입니다.

반면:

POST /api/payment

또는:

POST /api/gate/open

처럼 업무 동작을 일으키는 요청은 무조건 재전송하면 문제가 생길 수 있습니다.

따라서 Retry를 설계할 때는:

HTTP Method

API의 실제 의미

Idempotency 보장 여부

Request ID

Server 중복 처리 정책

을 함께 봐야 합니다.

13장 주차관제 Event API를 하나 분석해보자#

가상의 차량 입차 Event를 생각해보겠습니다.

Request:

POST /api/events HTTP/1.1
Host: test-parking-server.local
Content-Type: application/json
Authorization: Bearer TEST_TOKEN
Content-Length: 89

{
  "deviceId": "lpr-01",
  "eventId": "evt-20260924-001",
  "eventType": "vehicle-enter"
}

이를 구조적으로 보면:

POST
→ Event 등록 요청

/api/events
→ Resource 경로

Content-Type
→ JSON Body

Authorization
→ 인증 정보

eventId
→ 중복 판단에 사용할 수 있는 식별자

eventType
→ 업무 Event 종류

입니다.

Response도 업무 상태와 분리해 해석한다#

Server:

HTTP/1.1 201 Created
Content-Type: application/json

{
  "eventId": "evt-20260924-001",
  "status": "accepted"
}

이라고 응답했다고 하겠습니다.

201 Created는 Resource가 생성되었다는 의미로 사용할 수 있습니다.

그러나 Body의:

status = accepted

가 실제 장비의 모든 후속 업무까지 완료됐다는 뜻인지는 API Specification을 확인해야 합니다.

14장 HTTP 장애는 어느 단계에서 발생했는지 구분한다#

사용자는 화면에서 단순히:

장비 연결 오류

를 볼 수 있습니다.

하지만 실제 원인은 전혀 다를 수 있습니다.

TCP Connection 자체가 만들어지지 않는다#

확인:

IP Address

Subnet

Gateway

DNS

Routing

Firewall

Port

Server Process

Connection은 되지만 HTTP Response가 없다#

확인:

Application 처리 지연

Reverse Proxy

Upstream Server

Timeout

Server Thread 또는 Worker

HTTP 400이 반환된다#

확인:

JSON 문법

Required Field

Content-Type

Request Body

Parameter

HTTP 401 또는 403#

확인:

Token

Credential

권한

Token Expiration

Device Clock

HTTP 500#

Server Application Log를 확인합니다.

15장 Proxy와 Load Balancer도 함께 봐야 한다#

실제 환경에서는:

Device
↓
Switch
↓
Firewall
↓
Load Balancer
↓
Reverse Proxy
↓
Application Server

처럼 여러 계층을 통과할 수 있습니다.

그래서:

504 Gateway Timeout

이 발생했다고 Application Server 자체가 반드시 다운됐다는 뜻은 아닙니다.

Proxy가 설정된 시간 안에 Upstream 응답을 받지 못했을 수도 있습니다.

진단할 때는:

Client Log

Proxy Log

Application Log

Network Capture

의 Timestamp를 맞춰 보는 것이 유용합니다.

16장 HTTPS에서는 Packet Capture에 HTTP 내용이 그대로 보이지 않는다#

HTTP를 TLS로 보호하면 HTTPS가 됩니다.

구조:

HTTP
↓
TLS
↓
TCP
↓
IP

이 경우 Network Capture에서는 암호화된 TLS Data가 보입니다.

따라서 운영 환경의 HTTPS Traffic을 Capture했다고 해서:

Authorization Header

JSON Body

를 그대로 볼 수 있는 것은 아닙니다.

이것이 오히려 정상적인 보안 동작입니다.

운영 장비에서는 HTTP보다 HTTPS를 우선 고려한다#

장비 Command나 인증 정보가 평문 HTTP로 전달된다면 Network 접근자가 내용을 볼 위험이 있습니다.

특히:

Authorization Token

차량번호

회원정보

제어 명령

이 포함된다면 HTTPS 같은 암호화된 전송을 사용하는 것이 중요합니다.

17장 Log에는 무엇을 남기면 좋을까#

좋은 API Log는 장애 추적에 필요한 정보를 남기면서 민감정보는 최소화합니다.

예:

2026-09-24T14:30:12.125

DEVICE
lpr-01

REQUEST_ID
req-93851

METHOD
POST

PATH
/api/events

STATUS
201

LATENCY
84ms

이런 정보가 있으면:

어떤 장비가

언제

어떤 API를 호출했고

얼마나 걸렸으며

어떤 결과가 나왔는지

추적하기 쉽습니다.

반대로:

Authorization Bearer Token 전체

Password

개인정보 전체

를 Log에 그대로 남기는 것은 피해야 합니다.

18장 HTTP 장애 진단 순서#

현장에서 HTTP API가 동작하지 않는다면 다음 순서로 보면 좋습니다.

1. 장비 Network Link가 정상인가?
↓
2. IP·Gateway·DNS가 정상인가?
↓
3. 대상 TCP Port에 연결 가능한가?
↓
4. TLS 연결이 필요한가?
↓
5. HTTP Request가 실제로 전송됐는가?
↓
6. Method와 URL이 맞는가?
↓
7. Header가 맞는가?
↓
8. Body 형식이 맞는가?
↓
9. Status Code는 무엇인가?
↓
10. Response Body에 Error 정보가 있는가?
↓
11. Server Log에 Request가 남았는가?
↓
12. 업무 처리가 실제로 완료됐는가?

이 순서의 핵심은 연결 성공, HTTP 성공, 업무 성공을 서로 분리하는 것입니다.

19장 증상별 판단표#

증상 우선 확인
Connection Refused Port·Server Process
Connection Timeout Routing·Firewall·Network
HTTP 400 Header·Body·Parameter
HTTP 401 인증 정보·Token
HTTP 403 권한
HTTP 404 URL·Routing
HTTP 409 중복·현재 Resource 상태
HTTP 500 Server Application
HTTP 502 Proxy·Upstream 연결
HTTP 503 Service 상태·부하
HTTP 504 Proxy·Upstream Timeout
200인데 장비가 안 움직임 업무 처리·Device 상태
Event가 두 번 저장됨 Retry·Idempotency

20장 흔히 하는 잘못된 판단#

HTTP Request 하나는 Network Packet 하나다#

아닙니다.

하나의 HTTP Message가 여러 TCP Segment로 나뉠 수 있습니다.

TCP ACK가 왔으니 HTTP 처리가 성공했다#

아닙니다.

TCP ACK와 HTTP Response는 서로 다른 계층의 정보입니다.

HTTP 200이면 실제 장비 작업도 끝났다#

API 설계에 따라 Request 접수만 의미할 수도 있습니다.

Timeout이면 Server가 Request를 받지 못했다#

Server가 처리했지만 Response가 손실되거나 늦게 도착했을 수도 있습니다.

POST 요청은 Timeout 때 그냥 다시 보내면 된다#

중복 업무가 발생할 수 있으므로 Idempotency를 고려해야 합니다.

HTTP를 쓰면 데이터가 암호화된다#

아닙니다.

암호화된 HTTP 통신에는 일반적으로 HTTPS를 사용합니다.

Packet Capture에서 Header 절반만 보이면 요청이 깨졌다#

다음 TCP Segment에 나머지가 있을 수 있으므로 Stream 전체를 확인해야 합니다.

21장 현장 체크리스트#

□ HTTP Method가 맞는가?

□ URL과 Path가 맞는가?

□ HTTP Version을 장비가 지원하는가?

□ Host Header가 필요한가?

□ Content-Type이 맞는가?

□ Body Encoding은 무엇인가?

□ Content-Length가 맞는가?

□ Authorization Header가 필요한가?

□ Token이 만료되지 않았는가?

□ 장비 시간이 맞는가?

□ TCP Connection이 만들어지는가?

□ TLS Handshake가 정상인가?

□ Status Code를 기록하는가?

□ Response Body의 Error를 기록하는가?

□ Timeout 값을 정의했는가?

□ Retry 횟수를 제한했는가?

□ POST Retry에 중복 방지 정책이 있는가?

□ Request ID 또는 Event ID가 있는가?

□ 200 응답과 실제 업무 완료를 구분하는가?

□ Authorization Token을 Log에 남기지 않는가?

□ 개인정보를 Masking하고 있는가?

22장 자기 점검#

HTTP Request의 기본 구성은 무엇인가#

HTTP/1.x 기준으로 Request Line, Header, 빈 줄, 선택적인 Body로 구성됩니다.

Header와 Body는 어떻게 구분하는가#

HTTP/1.x Text Message에서는 Header 뒤의 빈 줄, 즉 CRLF CRLF를 기준으로 구분합니다.

HTTP 200과 201의 차이는 무엇인가#

200은 일반적인 요청 성공을 나타내며 201은 새로운 Resource가 생성되었음을 나타냅니다.

TCP ACK를 받으면 HTTP Request 처리가 완료된 것인가#

아닙니다. TCP ACK는 Transport Layer의 Byte 전달 확인이며 HTTP Application 처리 결과와는 다릅니다.

Timeout 후 POST 요청을 다시 보낼 때 무엇을 고려해야 하는가#

최초 요청이 이미 처리되었을 가능성이 있으므로 Request ID, Event ID 또는 Idempotency 정책을 이용해 중복 처리를 방지해야 합니다.

23장 이 글을 마치며#

HTTP Request는 단순히:

URL로 JSON을 보낸다.

가 아닙니다.

전체 구조는:

Request Line
↓
Header
↓
Body
↓
TCP Byte Stream
↓
Server
↓
Application 처리
↓
Status Code
↓
Response Header
↓
Response Body

로 이어집니다.

그리고 실무에서는 한 단계가 더 있습니다.

HTTP 성공
↓
업무 처리
↓
Database 저장
↓
장비 Command
↓
실제 장비 상태 변화

이 과정은 각각 다른 완료 상태입니다.

특히 다음 다섯 가지를 기억하면 됩니다.

HTTP Request는 Method·경로·Header·Body를 통해 Server에 무엇을 요청하는지 전달합니다.

HTTP Response의 Status Code는 요청 처리 결과를 알려주지만 실제 장비의 물리적 동작 완료까지 항상 보장하는 것은 아닙니다.

HTTP Message와 TCP Segment의 경계는 일치하지 않으므로 Packet Capture에서는 개별 Packet보다 TCP Stream 전체를 봐야 합니다.

Timeout이 발생해도 최초 요청이 이미 처리되었을 수 있으므로 Retry에는 중복 방지와 Idempotency 설계가 필요합니다.

장비 제어와 개인정보가 포함된 API에서는 HTTPS·인증·권한 관리와 안전한 Logging을 함께 고려해야 합니다.

결국 HTTP 통신을 이해한다는 것은 GET, POST, 200 같은 단어를 외우는 것이 아닙니다.

하나의 Request가 Network를 지나 Server에 도착하고, Application에서 처리된 뒤 Response로 돌아오며, 그 결과가 실제 업무 상태와 어떻게 연결되는지를 단계별로 추적할 수 있는 것이 핵심입니다.

이 페이지의 목차