[네트워크] HTTP 통신 요청

임유진·2025년 8월 19일

OSI 7계층 http 네트워크

클라우드/인프라

목록 보기

22/25

HTTP란?
웹 서비스를 이요할 때 사용하는 프로토콜이자, OSI 7계층의 대표적인 프로토콜SI 7계층의 대표적인 프로토콜

HTTP 요청(Request)

구조

<요청줄 Start-Line>   : [HTTP 메서드] [요청 URL 경로+쿼리] [HTTP 버전]
<요청 헤더 Headers>   : 키: 값
<빈 줄 CRLF>
<요청 바디 Body>      : 선택적 (메서드에 따라 있음/없음)

ex)

POST /users?ref=ad&utm=kr HTTP/1.1
Host: api.example.com:443
User-Agent: curl/8.7.1
Content-Type: application/json
Content-Length: 72
Cookie: sid=abc123; theme=dark

{"email":"yujin@example.com","password":"pw1234!","name":"Yujin"}

요청줄

: 클라이언트가 웹 서버에 요청하는 방식을 구분해 미리 알려주는 기능

항목	설명	예시/비고
HTTP 메서드	동작 의도(조회/생성/수정/삭제 등)	GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, TRACE
URL	요청 대상 주소	`https://api.example.com:443/users?ref=ad`
HTTP 버전	메시지 형식/기능 수준	`HTTP/1.1`, `HTTP/2`, `HTTP/3`(QUIC)

HTTP 메서드

메서드	사용 상황	특징
GET	리소스 단순 조회	캐시 가능, URL에 쿼리 파라미터 사용, 바디 지양
HEAD	GET 결과의 헤더만 응답. 상태 변화 없음.	리소스 존재 여부, 캐시 유효성 검사
POST	리소스 생성, 작업 실행	멱등성 없음, 바디 필수(JSON, Form 등)
PUT	리소스 전체 교체/업서트	멱등적, 존재하면 수정/없으면 새로 생성(정책에 따라)
PATCH	리소스 일부 변경	부분 수정용, 멱등성 보장 안 됨
DELETE	리소스 삭제	멱등적(여러 번 호출해도 결과 같음)
OPTIONS	지원 메서드 확인, CORS 프리플라이트	브라우저 자동 호출
TRACE	루프백 테스트, 요청→응답 그대로 확인	보안상 거의 차단

멱등(Idempotent)이란?
클라이언트가 같은 요청을 여러 번 반복해서 보내더라도, 서버의 상태가 이후에도 동일하게 유지됨을 보장.
예를 들어, DELETE 를 반복해도 '없음' 상태 유지하므로 DELETE는 멱등적.
멱등 요청(GET, PUT, DELETE 등)은 중간 프록시/캐시 서버가 자동으로 응답 보관하거나 최적화할 수 있어 성능에 유리함. 단, POST는 보통 캐시하지 않음. 또, 이중 수행하면 안되는 요청들 처리할 때 멱등적인 method 이용하면 안전.

URL

https://api.example.com:443/users/42?fields=name,email#top
└─프로토콜(https) └호스트     └포트 └경로      └쿼리스트링     └프래그먼트(클라용)

구성 요소	설명	예시	기본값/규칙
프로토콜 (Scheme / Protocol)	어떤 프로토콜로 접근할지 지정	`http`, `https`, `ftp`, `ssh`, `mailto`, `file`	- `http` → 80 - `https` → 443 - `ftp` → 21 - `ssh` → 22 - `telnet` → 23 - `ldap` → 389 - `ldaps` → 636 - `ws` (WebSocket) → 80 - `wss` (WebSocket Secure) → 443
호스트 (Host / Domain)	리소스를 제공하는 서버의 주소 (도메인명 또는 IP)	`www.example.com`, `192.168.0.1`	DNS로 IP 변환
포트 (Port)	서버에서 해당 프로토콜이 열려 있는 통신 포트	`:8080`, `:443`	- 생략 시 스킴 기본 포트 사용 예: `http://...` → 80, `https://...` → 443
경로 (Path)	서버 내 리소스 위치 (디렉토리·파일)	`/users/42/profile`	루트 `/`부터 시작
쿼리 스트링 (Query String)	추가 파라미터 전달 (키=값)	`?page=2&sort=asc`	`?` 시작, `&`로 구분
프래그먼트 (Fragment / Anchor)	문서 내 특정 위치(클라이언트용)	`#section2`	서버에는 전달되지 않고 브라우저에서만 해석

HTTP 버전
- HTTP/0.9 : 가장 초기 버전. 단순히 HTML 문서를 주고 받는데 사용. 헤더로 추가할 수 있는 정보가 거의 없고, 오직 GET 메서드만 지원
- HTTP/1.0 : 간단한 요청과 응답을 처리하는데 사용. 각 요청에 대해 새로운 연결을 생성해야 함
- HTTP/1.1 : 현재 가장 일반적으로 사용하는 버전. 한 번의 연결로 여러 데이터를 받아올 수 있게 개선됨
- HTTP/2 : 헤더 압축, 우선순위 설정, 바이너리 프레임 등 새로운 기술 도입
- HTTP/3 : QUIC(Quick UDP Internet Connetcions) 사용해 빠른 연결 제공

요청 헤더

: 클라이언트와 서버가 데이터를 주고받으면서 필요한 추가 정보 제공

분류	헤더	설명/예시
대상	Host	클라이언트가 입력한 URL에서 호스트 주소와 포트 번호 설정(`HTTP/1.1`은 필수) 가상호스팅 구분: `Host: api.example.com[:포트]`
클라이언트	User-Agent	운영체제 버전, 웹 브라우저의 버전 등 클라이언트 프로그램에 대한 정보 설정 클라이언트 식별(디버깅/통계)
상태관리	Cookie	이전에 서버에서 받은 정보가 있다면 쿠키에 포함해 서버에 전송 `sid=...` 등 세션/상태 전달
콘텐츠	Content-Type	보내는 바디 타입: `application/json`, `application/x-www-form-urlencoded`, `multipart/form-data; boundary=...`
콘텐츠	Content-Length	바디 길이(바이트). 스트리밍 시 `Transfer-Encoding: chunked`
인증	Authorization	`Bearer <JWT>`, `Basic <base64>`
협상	Accept	받고 싶은 응답 타입: `application/json`
캐시/조건	If-None-Match / If-Modified-Since	304 유도(캐시 재검증)

요청 바디

: 클라이언트가 서버로 POST 메서드를 이용해 요청 보낼 때 데이터를 담는 곳

포맷	Content-Type	특징/예시
폼 URL 인코딩	`application/x-www-form-urlencoded`	기본적 문자 형태의 데이터 보낼 때 사용하는 형식 키=값&... (단순 폼) 예: `email=y%40e.com&name=Yujin`
멀티파트	`multipart/form-data; boundary=...`	사진이나 파일 업로드와 같은 데이터 전송할 때 사용 `boundary`를 이용해 각 데이터를 파트로 나누고, 파트마다 콘텐드 형식 다시 작성해 전송
JSON	`application/json`	JavaScript로 데이터 전송할 때 가장 보편적인 API 포맷. 예: `{"name":"Yujin"}`

참고: 사양상 GET 바디는 가능하지만 호환성 문제로 사실상 지양합니다.

HTTP 응답(Response)

구조

<상태줄 Status-Line>  =  HTTP/<버전> <상태코드> <상태문구>
<응답 헤더들>
<빈 줄>
<응답 바디> (선택)

ex) 리소스 생성

HTTP/1.1 201 Created
Date: Mon, 18 Aug 2025 01:30:00 GMT
Server: nginx
Content-Type: application/json
Content-Length: 49
Location: https://api.example.com/users/42
Set-Cookie: sid=abc123; HttpOnly; Secure; SameSite=Lax

{"id":42,"name":"Yujin","email":"yujin@example.com"}

상태줄

범위	코드	상태 문구	설명
1xx (정보)	100	Continue	클라이언트가 요청을 계속 보내도 됨
	101	Switching Protocols	프로토콜 전환 (예: HTTP → WebSocket)
	103	Early Hints	본문 전송 전 헤더 미리 알림
2xx (성공)	200	OK	요청 성공 (기본 응답)
	201	Created	새 리소스 생성됨 (Location 헤더 포함)
	202	Accepted	요청 수락, 아직 처리 안 됨
	204	No Content	성공했지만 바디 없음 (예: DELETE)
3xx (리다이렉션)	301	Moved Permanently	영구적 이동 (URL 변경됨)
	302	Found	임시 이동
	303	See Other	다른 URI 참조 (POST 후 GET으로)
	304	Not Modified	캐시된 버전 사용해도 됨
	307	Temporary Redirect	임시 리다이렉트 (메서드 유지)
	308	Permanent Redirect	영구 리다이렉트 (메서드 유지)
4xx (클라이언트 오류)	400	Bad Request	잘못된 요청 (문법 오류 등)
	401	Unauthorized	인증 필요 (로그인 필요)
	403	Forbidden	권한 없음
	404	Not Found	리소스를 찾을 수 없음
	405	Method Not Allowed	허용되지 않은 메서드 사용
	409	Conflict	리소스 충돌 (중복 데이터 등)
	429	Too Many Requests	요청 과다 (Rate Limiting)
5xx (서버 오류)	500	Internal Server Error	서버 내부 오류
	501	Not Implemented	기능 미구현
	502	Bad Gateway	게이트웨이/프록시 오류
	503	Service Unavailable	서비스 불가 (과부하, 점검 중)
	504	Gateway Timeout	게이트웨이 응답 지연
	505	HTTP Version Not Supported	지원하지 않는 HTTP 버전

응답 헤더

분류	헤더	설명/예시
서버	Server	서버 소프트웨어: `nginx`, `Apache`, 숨기기도 함
콘텐츠	Content-Type	`text/html`, `application/json`, `image/png`, `text/css` 등 응답 데이터 형식
콘텐츠	Content-Length	응답 바디 길이
리소스 위치	Location	201/3xx 시 새 위치/식별자
쿠키	Set-Cookie	속성: `HttpOnly`, `Secure`, `SameSite` 등
캐시	ETag, Last-Modified, Cache-Control	캐시/재검증 정책
재시도	Retry-After	429/503 등에서 재시점 안내(초 또는 날짜)

응답 바디

타입	Content-Type	용도
HTML	`text/html`	웹페이지 렌더링
JSON	`application/json`	API 데이터
PNG	`image/png`	이미지
CSS	`text/css`	스타일시트

프론트엔드 & 백엔드 흐름 예시

단계	프론트엔드 (브라우저/앱)	백엔드 (WAS + DB)	설명
1. 입력/이벤트 발생	사용자 입력을 HTML form/React state에 저장	-	사용자가 `id`, `pw` 입력
2. 요청 생성	JS 코드에서 `fetch`/`axios` 등으로 요청 생성: `http<br>POST /api/login HTTP/1.1<br>Host: example.com<br>Content-Type: application/json<br><br>{"email":"user@test.com","password":"1234"}`	-	프론트엔드가 API 요청 메시지 구성
3. 요청 전송	요청 패킷을 TCP/IP → HTTP로 캡슐화해서 네트워크로 전송	웹 서버(Nginx/Apache) → WAS(Spring, Node 등)에 전달	네트워크 계층 통해 서버 도달
4. 요청 처리	-	백엔드 라우터가 `POST /api/login` 매핑된 컨트롤러 실행 → 비즈니스 로직 → DB 조회	예: DB에서 `user@test.com` 검색 후 비밀번호 해시 검증
5. 응답 생성	-	로그인 성공 시 JWT 토큰 발급, 실패 시 오류 코드 생성	예: 200 OK / 401 Unauthorized
6. 응답 전송	서버 → 클라이언트로 HTTP 응답 전송: `http<br>HTTP/1.1 200 OK<br>Content-Type: application/json<br>Set-Cookie: token=eyJhbGci...; HttpOnly; Secure<br><br>{"message":"login success","userId":42}`	-	응답에는 상태 코드 + 헤더 + 바디 포함
7. 응답 처리	프론트엔드 JS에서 응답 JSON 파싱 후 상태 관리에 저장 → UI 업데이트(“로그인 성공”)	-	성공 시 메인 화면 이동, 실패 시 오류 표시

cf. REST & RESTful API

REST (Representational State Transfer)란?

2000년 로이 필딩(Roy Fielding)의 박사 논문에서 제시된 웹 아키텍처 스타일

“웹은 어떻게 설계해야 확장성과 일관성을 유지할 수 있을까?” → 답이 REST

핵심은 리소스를 명확하게 식별하고, 그 리소스를 표현(Representation)으로 주고받는 방식

REST의 제약 조건

조건	설명
Client–Server 구조	프론트엔드(클라이언트)와 백엔드(서버) 역할을 분리
Stateless (무상태성)	각 요청은 독립적. 서버는 클라이언트의 상태를 세션에 저장하지 않음 → 확장성 ↑
Cacheable (캐시 가능)	응답은 캐시할 수 있어야 함 (ETag, Cache-Control)
Uniform Interface (일관된 인터페이스)	리소스 식별 (URI), 표현을 통한 조작 (JSON 등), 자기서술적 메시지, HATEOAS(선택)
Layered System (계층 구조)	중간 프록시, 게이트웨이, 로드밸런서 등을 자유롭게 끼워넣을 수 있음
Code-on-Demand (선택)	서버가 클라이언트에 실행 가능한 코드(JS 등)를 내려줄 수도 있음

REST API란?

REST 아키텍처 스타일을 따른 API
즉, 리소스(Resource)를 중심으로, HTTP 메서드(GET, POST, PUT, DELETE …)와 상태코드를 이용해 데이터를 주고받는 API

REST API 설계 규칙 (관례)

요소	원칙	예시
리소스	URI는 명사, 복수형 사용	`/users`, `/users/{id}`, `/articles/{id}/comments`
행위	HTTP 메서드로 표현	GET(조회), POST(생성), PUT(전체 수정), PATCH(부분 수정), DELETE(삭제)
응답 상태 코드	상황에 맞는 코드 사용	200 OK, 201 Created, 204 No Content, 400 Bad Request, 404 Not Found
포맷	JSON 응답 권장	`{"id":42,"name":"Yujin"}`
버저닝	URL 또는 헤더	`/api/v1/users` 또는 `Accept: application/vnd.myapp.v1+json`
에러 처리	일관된 형식	`{"code":"VALIDATION_ERROR","message":"필수 값 누락"}`

REST vs RESTful API

REST: 아키텍처 스타일 (6가지 제약 조건)
REST API: REST 원칙을 따른 API
RESTful API: REST를 가장 충실히 지킨 API (자원 중심 URI + HTTP 메서드 + 상태 코드 활용)

cf. URL vs URN vs URI

구분	한 줄 정의	웹 예시	일상 비유
URL (Locator)	어디에 있는지 + 어떻게 가는지 (위치 기반)	`https://example.com/books/123.html`	서울시 강남구 아파트 101동 1001호 집 주소
URN (Name)	무엇인지 이름만 (위치와 무관)	`urn:isbn:9783161484100`	주민등록번호 / 도서 ISBN 번호
URI (Identifier)	리소스를 식별할 수 있는 모든 것 (URL, URN 다 포함)	URL과 URN 모두가 URI (`/qwe` 식별자가 `C:\test\abc.html`이면 URI 경로 끝부분에 클라이언트가 `/qwe`라고만 해도 서버가 클라이언트에 전달하는 데이터는 `C:\test\abc.html`	사람을 특정할 수 있는 모든 방법(주소, 주민번호, 전화번호 등)

실무에서는 URI/URL을 거의 구분하지 않고 “URL”이라 부르는 경우가 많음

복습 문제

Q1. 웹 서버와 웹 브라우저가 데이터를 주고받을 때 사용하는 7계층의 대표적인 프로토콜은 무엇인가? HTTP 프로토콜

Q2. 웹 브라우저가 웹 서버에 데이터를 요청할 때 어떤 데이터를 원하는지 또는 데이터를 요청하는 데 필요한 데이터를 서버 쪽으로 보내면서 요청하는데, 이때 데이터를 URL에 포함해 보내는 HTTP 메서드는 무엇인가? GET

Q3. 웹 브라우저가 웹 서버에 데이터를 요청할 때 어떤 데이터를 원하는지 또는 데이터를 요청하는 데 필요한 데이터를 서버 쪽으로 보내면서 요청하는데, 이때 데이터를 HTTP 보디에 포함해 보내는 HTTP 메서드는 무엇인가? POST

Q4. 웹 브라우저로 웹 서버로부터 전달받는 웹 페이지 중에서 화면에 표시되는 실제 내용을 작성해 둔 문서 파일은 무엇인가? HTML

Q5. 웹 브라우저로 웹 서버로부터 전달받는 웹 페이지 중에서 화면에 표시되는 내용의 디자인을 작성해 둔 파일로, 버튼의 위치나 그림 파일의 크기 등을 설정하는 파일은 무엇인가? CSS

Q6. 웹 브라우저로 웹 서버로부터 전달받은 웹 페이지 중에서 특정 기능이 실행될 수 있도록 하는 스크립트 코드를 작성하는 파일은 무엇인가? JavaScript

Q7. 프런트엔드 코드와 백엔드 코드를 나누는 기준은 어느 쪽 컴퓨터에서 실행되느냐인데 이때 프런트엔드 코드는 클라이언트 컴퓨터에서 실행되고, 백엔드 코드는 서버 컴퓨터에서 실행된다.

Q8. 서버 프로그램이 실행 중인 컴퓨터에서 특정 파일이 저장된 위치를 찾아가기 위한 주소는 무엇인가? URL

Q9. 클라이언트가 서버에서 파일을 내려받을 때 서버가 지정한 식별자를 이용해서 내려받도록 하는 주소는 무엇인가? URI

Q10. 클라이언트에서 서버로 POST 메서드를 이용해서 데이터를 HTTP 프로토콜의 보디에 사진이나 파일 업로드와 같은 데이터를 전송할 때 사용하는 콘텐트 형식은 무엇인가? multipart/form-data

Q11. 서버 컴퓨터에 저장된 HTML, CSS, 자바스크립트와 같은 웹 페이지나 이미지, 동영상, 음성 등의 파일을 HTTP 응답 프로토콜에 담아 클라이언트에 보내는 서버는 무엇인가? 웹 서버

Q12. 서버에 저장도니 프로그램 코드를 실행한 후 그 결과를 HTTP 응답 프로토콜에 담아 보내는 서버는 무엇인가? 웹 어플리케이션 서버

Q13. 일반적으로 웹 사이트를 운영할 때 데이터를 저장해두는 용도로 사용하는 데이터베이스 서버는 데이터를 표 형태로 저장한다.

Q14. 데이터를 저장하거나 전송할 때 많이 사용되는 형식으로 키와 값의 쌍으로 나타내는 데이터 형식은 무엇인가? JSON

Q15. 클라이언트가 웹 서버에 요청한 파일이 웹 서버에 없을 때 웹 서버가 보내는 HTTP 프로토콜의 상태 코드와 상태 문구는 무엇인가? 404 Not Found

Q16. 클라이언트가 권한이 없는 파일을 웹 서버에 요청했을 때 웹 서버가 보내는 HTTP 프로토콜의 상태 코드와 상태 문구는 무엇인가? 403 Forbidden

Q17. 웹 서버가 클라이언트의 요청을 처리하다가 오류가 발생한 경우 웹 서버가 보내는 HTTP 프로토콜의 상태 코드와 상태 문구는 무엇인가? 500 Internal Server Error

Q18. 웹 서버에 접속한 사용자가 너무 많거나 디도스 공격을 받을 때 웹 서버가 보내는 HTTP 프로토콜의 상태 코드와 상태 문구는 무엇인가? Service Unavailable

Q19. HTML, CSS, 자바스크립트처럼 클라이언트 컴퓨터에서 실행되는 코드를 무엇이라고 하는가? 프런트엔드 코드

Q20. 웹 애플리케이션 서버에서 실행되는 코드로, 요청을 받으면 코드의 실행 결과만 응답으로 보내는 코드를 무엇이라고 하는가? 백엔드 코드

임유진

말하는 고구마

이전 포스트

[네트워크] 프로그램이 데이터를 주고받는 방법(OSI 4계층)

다음 포스트