[Spring 입문] HTTP 정리

박화랑·2025년 3월 17일

Spring_개념정리

목록 보기

4/17

HTTP 1강: HyperText Transfer Protocol 개요

1. HTTP란?

HTTP (HyperText Transfer Protocol)
- 웹 상에서 데이터를 주고받는 기본 프로토콜
- 클라이언트(브라우저)와 서버 간 요청(Request)과 응답(Response) 을 처리함
- 다양한 데이터 형식 지원: HTML, JSON, 이미지, 동영상 등
HTTP의 주요 특징
1. 클라이언트-서버 구조
  - 클라이언트(사용자) → 요청 → 서버(웹사이트)
  - 서버 → 응답 → 클라이언트 (웹페이지 렌더링)
2. Stateless (무상태)
  - 서버는 각 요청을 독립적으로 처리하며, 이전 요청 정보를 저장하지 않음
  - 지속적인 상태 유지가 필요한 경우, 세션(Session), 쿠키(Cookie), 토큰(Token) 사용
3. Connectionless (비연결형)
  - 기본적으로 요청을 보내고 응답을 받으면 연결이 종료됨
  - HTTP/1.1부터는 Persistent Connection(지속 연결) 지원

☞ HTTP는 가볍고 단순하지만, 상태 유지가 필요하면 추가적인 기술이 필요함

2. HTTP 동작 과정

사용자가 브라우저에서 URL 입력 (https://www.example.com)
브라우저가 DNS 조회를 통해 해당 도메인의 IP 주소를 찾음
브라우저가 서버와 TCP 연결 (3-Way Handshake) 수행
클라이언트가 HTTP 요청(Request) 전송
서버가 요청을 처리하고 HTTP 응답(Response) 전송
브라우저가 응답 데이터를 받아 웹페이지 렌더링

☞ HTTP 요청과 응답이 쌍을 이루며 동작함

3. HTTP 메시지 구조

HTTP 요청(Request) 구조
1. Start Line (시작 줄): 요청 방식 (GET, POST 등) + URL + HTTP 버전
2. Headers (헤더): 요청의 추가 정보 (Host, User-Agent 등)
3. Body (본문, 선택 사항): 요청 데이터 (POST 요청 시 JSON 등 포함)

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0

HTTP 응답(Response) 구조
1. Status Line (상태 줄): HTTP 버전 + 상태 코드 (200 OK, 404 Not Found 등)
2. Headers (헤더): 응답의 추가 정보 (Content-Type, Server 등)
3. Body (본문, 선택 사항): 응답 데이터 (HTML, JSON, 이미지 등)

HTTP/1.1 200 OK
Content-Type: text/html

<html>
  <body>Hello, world!</body>
</html>

☞ 요청과 응답 모두 Start Line, Headers, Body로 구성됨

4. HTTP의 주요 버전

버전	특징
HTTP/1.0	단일 요청-응답 후 연결 종료
HTTP/1.1	기본적으로 지속 연결(Persistent Connection) 지원
HTTP/2	멀티플렉싱(동시 요청 처리), 헤더 압축 지원
HTTP/3	UDP 기반의 빠른 데이터 전송 (QUIC 프로토콜 사용)

☞ 현대 웹에서는 HTTP/2와 HTTP/3가 점점 더 많이 사용됨

정리

HTTP는 클라이언트와 서버 간 데이터를 주고받는 프로토콜
Stateless, Connectionless 특성을 가지며 요청-응답 방식으로 동작
HTTP 메시지는 Start Line, Headers, Body로 구성됨
HTTP/1.1 이후 지속 연결과 성능 최적화를 위한 HTTP/2, HTTP/3이 등장

HTTP 2강: HTTP Method와 상태 코드

1. HTTP Method란?

클라이언트가 서버에게 요청을 보낼 때 사용하는 방식
RESTful API 설계에서 리소스 조작을 위한 표준 방식

주요 HTTP Method

Method	설명	사용 예
GET	리소스 조회	웹페이지 로딩, 데이터 요청
POST	새로운 리소스 생성	회원가입, 글 작성
PUT	리소스 전체 수정	프로필 전체 변경
PATCH	리소스 일부 수정	비밀번호 변경
DELETE	리소스 삭제	게시글 삭제

☞ GET 요청은 데이터를 조회하는 것이므로 요청 본문을 포함하지 않음

2. HTTP Method 속성

안전성(Safe): 서버의 상태를 변경하지 않음 → GET, HEAD
멱등성(Idempotent): 같은 요청을 여러 번 보내도 같은 결과 → GET, PUT, DELETE
캐시 가능(Cacheable): 응답을 저장해 반복 요청을 줄일 수 있음 → GET, HEAD

☞ POST는 멱등성이 없으며, GET은 캐시가 가능하여 성능 최적화에 활용됨

3. HTTP 상태 코드 (Status Code)

서버가 클라이언트 요청을 어떻게 처리했는지 나타내는 코드

1xx: 정보 응답

코드	의미
100 Continue	요청을 계속 진행하세요
101 Switching Protocols	프로토콜 변경 요청 수락

2xx: 성공 응답

코드	의미
200 OK	요청 성공
201 Created	새 리소스 생성 완료
204 No Content	응답 본문 없음

3xx: 리다이렉션

코드	의미
301 Moved Permanently	URL이 영구적으로 변경됨
302 Found	일시적인 리다이렉션
304 Not Modified	캐시된 응답을 사용

4xx: 클라이언트 오류

코드	의미
400 Bad Request	잘못된 요청
401 Unauthorized	인증 필요
403 Forbidden	접근 권한 없음
404 Not Found	리소스를 찾을 수 없음

5xx: 서버 오류

코드	의미
500 Internal Server Error	서버 내부 오류
502 Bad Gateway	게이트웨이 오류
503 Service Unavailable	서비스 이용 불가

☞ 정확한 상태 코드를 설정하면 API의 가독성과 유지보수성이 향상됨

4. HTTP 상태 코드 활용 예시

회원가입 성공 시 → 201 Created
로그인 실패 (잘못된 비밀번호) → 401 Unauthorized
삭제 요청 후 리소스가 없을 경우 → 404 Not Found
서버 장애 발생 시 → 500 Internal Server Error

☞ 올바른 상태 코드 반환은 API 설계에서 매우 중요!

정리

HTTP Method: GET(조회), POST(생성), PUT(수정), DELETE(삭제)
HTTP Method 속성: 안전성, 멱등성, 캐시 가능 여부 고려
HTTP 상태 코드: 요청 처리 결과를 숫자로 표현하며, 1xx~5xx까지 다양한 범주 존재

HTTP 3강: HTTP Header와 Restful API

1. HTTP Header란?

요청(Request)과 응답(Response)에 부가 정보를 추가하는 메타데이터
헤더를 통해 인증, 캐싱, 데이터 형식, 서버 정보 등을 전달 가능

HTTP Header 구조

Header-Name: Header-Value

☞ 헤더는 대소문자를 구분하지 않으며, key-value 형식으로 구성됨

2. 주요 HTTP Header 종류

1) 요청(Request) 헤더

헤더	설명	예시
`Host`	요청 대상 서버 도메인	`Host: www.example.com`
`User-Agent`	클라이언트 정보	`User-Agent: Mozilla/5.0`
`Accept`	클라이언트가 원하는 데이터 형식	`Accept: application/json`
`Authorization`	인증 정보 포함	`Authorization: Bearer token`

2) 응답(Response) 헤더

헤더	설명	예시
`Server`	서버 정보	`Server: Apache/2.4.41`
`Content-Type`	응답 데이터 형식	`Content-Type: text/html`
`Set-Cookie`	클라이언트에 쿠키 저장	`Set-Cookie: sessionId=abc123; Path=/; HttpOnly`
`Location`	리다이렉트 주소	`Location: https://new.example.com`

☞ 요청과 응답 헤더를 활용하면 웹 통신을 효율적으로 제어할 수 있음

3. Restful API란?

REST (Representational State Transfer) 원칙을 따르는 API
HTTP Method를 활용하여 리소스를 명확하게 표현하는 방식

RESTful API 설계 규칙

기능	HTTP Method	예제 URL
리소스 조회	`GET`	`/users`
특정 리소스 조회	`GET`	`/users/{id}`
리소스 생성	`POST`	`/users`
리소스 수정	`PUT`	`/users/{id}`
리소스 일부 수정	`PATCH`	`/users/{id}`
리소스 삭제	`DELETE`	`/users/{id}`

☞ URI에는 동사를 포함하지 않고, 명확한 리소스를 나타내야 함

4. RESTful API의 장점과 단점

✅ 장점

URL만 보고도 기능을 예측 가능
HTTP 표준을 따르므로 다양한 클라이언트와 호환 가능
Stateless 특성으로 서버 확장성 용이

❌ 단점

초기 설계가 중요 (잘못된 설계는 유지보수 어려움)
Over-fetching & Under-fetching 문제 발생 가능
보안 적용이 필수적 (인증, 권한 관리 필요)

☞ RESTful API는 웹 서비스 설계에서 필수적인 개념!

정리

HTTP Header: 요청 및 응답에 부가 정보를 포함하는 메타데이터
RESTful API: HTTP 기반의 리소스 중심 API 설계 방식
RESTful API의 규칙: 동사 사용 지양, 일관된 URL 구조 유지

HTTP 4강: HTTP 캐시와 보안

1. HTTP 캐시(Cache)란?

동일한 요청을 여러 번 보낼 때 서버 부하를 줄이고 성능을 최적화하는 기술
불필요한 네트워크 트래픽을 감소시켜 웹 페이지 로딩 속도 향상

2. HTTP 캐시 제어 헤더

1) 요청(Request) 캐시 제어 헤더

헤더	설명
`Cache-Control: no-cache`	캐시된 데이터를 사용하지 않고, 항상 서버에서 새 데이터 요청
`Cache-Control: max-age=3600`	1시간(3600초) 동안 캐시 유지 후 새로운 요청 수행
`If-Modified-Since`	마지막으로 수정된 날짜 이후 변경이 없으면 캐시된 데이터 사용
`If-None-Match`	ETag 값을 기반으로 변경 여부 확인 후 캐시 활용

2) 응답(Response) 캐시 제어 헤더

헤더	설명
`Cache-Control: public`	모든 사용자가 캐시 가능
`Cache-Control: private`	특정 사용자만 캐시 가능
`Cache-Control: no-store`	캐시 저장 금지 (보안이 중요한 데이터)
`ETag`	리소스의 고유 식별자 (변경이 없으면 캐시된 데이터 사용)

☞ 캐시를 적절히 활용하면 웹사이트 성능이 크게 향상됨

3. HTTP 보안 (HTTPS)

HTTP는 데이터를 암호화하지 않음 → 중간에서 가로챌 위험이 있음
HTTPS (HTTP Secure)
- 데이터를 암호화하여 도청, 변조, 위조를 방지
- SSL/TLS 프로토콜을 사용하여 보안 강화

SSL/TLS 동작 과정

클라이언트가 HTTPS 요청
서버가 SSL/TLS 인증서를 클라이언트에게 전달
클라이언트가 인증서를 검증 후 암호화된 연결 설정
이후 모든 데이터는 암호화된 상태로 통신됨

☞ HTTPS는 보안이 중요한 로그인, 결제 시스템 등에 필수!

4. HTTP와 HTTPS 비교

항목	HTTP	HTTPS
보안성	데이터 평문 전송 (위험)	데이터 암호화 (안전)
인증서 필요 여부	불필요	SSL/TLS 인증서 필요
속도	빠름	암호화 오버헤드로 약간 느림
사용 예시	일반적인 웹페이지	로그인, 결제, 개인 정보 입력

☞ HTTPS는 기본적으로 모든 웹사이트에서 적용하는 것이 권장됨

정리

HTTP 캐시: 서버 부하 감소 및 성능 최적화를 위한 기술
캐시 제어 헤더: Cache-Control, ETag 등을 사용하여 효과적인 캐싱
HTTPS: 보안이 강화된 HTTP, 데이터를 암호화하여 안전한 통신 제공
SSL/TLS: HTTPS에서 사용되는 보안 프로토콜

☞ 다음 강의에서는 Web Application 개념과 서버 구조에 대해 학습할 예정!

박화랑

개발자 희망생

이전 포스트

[Spring 입문] 용어 모음집

다음 포스트