HTTP 복습하기

말하는 감자·2025년 3월 17일

내일배움캠프

목록 보기

20/73

면접 스터디때 레스트풀 api에 관련한 키워드가 나와서 공부를 하긴했는데, 당시에는 뭔소린지 하나도 모르겠었다...
그래서 오늘은 HTTP와 RESTful에 대해서 열심히 삽질을 해볼 까 한다!
이거 조금 저거 조금 알다보니깐 서로 연관지어서 생각하고 큰 그림 보는 능력이 떨어지는 것 같다...

고럼 오늘도 출발

🍎 HTTP - Hypertext Transfor Protocol

하도 많이 봐서 약자 다외웠다!
사실 기본 개념들은 이미 알고있다.. 근데 이런 개념은 솔직히 몇번 안보고 있으면 금방 까먹기 마련이다.

HTTP는?

Hpyertext Transfor 을 하는 네트워크 통신 규칙 덩어리(Protocol)

📒Protocol 이 뭐냐면...

프로토콜은 컴퓨터나 장치들이 서로 통신할 때 지키기로 정해놓은 규칙이다.
HTTP(Hypertext Transfor Protocol) , TCP(Transmission Control Protocol) / IP(Internet Protocol) 등 컴퓨터나 다른 전자기기와 통신할 때 필요함!!!
없으면 서로 데이터를 주고받을 때 마다 언어나 데이터 포멧이 달라서 하나하나 번역해줘야한다.

우리는 현재 HTTP/1.1을 대부분 사용한다.
왜냐하면.., 으로 4가지 이유를 들 수 있다 ( 출처 )

왜 HTTP/1.1을 쓰지??

1️⃣ 연결 상태 유지(Persistent Connection)

1.0 버전까지는 응답이 수신되면 바로 TCP 연결을 종료했었다. 근데 웹 페이지가 복잡해지면서 잦은 연결과 종료가 속도를 느리게 만들었기 떄문이다.
추가적으로 TCP 자체의 흐름제어와 혼잡 제어 때문에 네트워크 성능도 좋지 않았다.
그래서, 1.1버전부터는 연결 상태 유지를 통해 한 번 연결 해놓고 계속 요청과 반환을 반복할 수 있음!!!! (아래 2번째 사진)
단, 유지 시간이 길 어질 수록 서버에 부하가 생겨서 연결 시간을 제한해야함(Keep-Alive라 부름)

2️⃣ 파이프라이닝(Pipelining)

기존: 요청->응답, 다음요청->응답, 그다음요청->응답
파이프라이닝 : 요청,다음요청,그다음요청 -> 응답오는대로받기 ( 위의 3번째 사진 )
서버-클라이언트 간의 송수신 시간을 획기적으로 줄일 수 있음!

3️⃣ 호스트 정보 필수 (Host Header)

기존 : HTTP/1.0은 하나의 IP에 하나의 웹사이트만 운영
1.1버전부터는 하나의 IP로 여러 개의 웹사이트를 운영할 수 있게 됐음.(가상 호스팅Virtual Hosting)
- 용 절감과 효율적인 서버 운영이 가능해졌다!

4️⃣ 프록시와 캐시 개선

HTTP/1.1은 캐시 관리가 더 정교해지고, 프록시 서버를 통해 웹사이트를 더 빠르게 로딩할 수 있도록 개선됐다.
캐시 제어(Cache-Control) : 요청과 응답에 대한 메타 정보를 담음

💡 왜 HTTP/2, HTTP/3로 안 가는 걸까?

HTTP/2와 HTTP/3는 성능이 훨씬 좋지만, 완전히 새로운 방식이라서 기존 웹 서버와 클라이언트가 모두 업데이트되어야 한다.
HTTP/1.1이 이미 충분히 안정적이고, 대부분의 웹사이트가 이걸로도 큰 문제 없이 운영 가능하기 때문
그래도 요즘은 대형 웹사이트(aws, cloudflare 등)나 최신 웹 서비스들은 점점 HTTP/2, HTTP/3로 이동하고 있음!!

HTTP의 진화과정

웹사이트에서 F12를 누르면 통신내역을 볼 수 있는데 여기서 HTTP의 버전도 확인이 가능하다!

네이버창인데 네이버도 H2가 훨씬많다,... 안쓰는건 아닌거같고
차근차근 옮겨가는??? 그런 분위기인가보다.

특징

위에서 언급했다싶이, HTTP는 연결을 유지하지 않는 모델이다.
HTTP가 공통으로 제공하는 특징? 들을 간단하게 꼽아보겠다.

1️⃣ 클라이언트-서버 구조
HTTP는 클라이언트(브라우저)와 서버(웹 서버)가 서로 요청(Request)과 응답(Response)을 주고받는 방식

2️⃣ 📌무상태 (Stateless)

서버는 이전 요청의 정보를 기억하지 않는다.
즉, 클라이언트가 요청할 때마다 항상 독립적인 요청으로 처리됨.
- 로그인한 후에도 HTTP 자체는 로그인 상태를 기억하지 않음 → 그래서 쿠키, 세션, JWT 같은 방식으로 상태를 유지해야 함.

3️⃣ 비연결성 (Connectionless)

연결을 유지하지 않는 모델이라 서버 자원을 효율적으로 사용할 수 있다.
예) 웹페이지의 여러 이미지, CSS 파일 등을 한 번의 연결로 받을 수 있음.
이런 비연결성은 여러 단점을 만들어낸다.
- 요청이 추가적으로 오게되면 연결(3 way handshake)을 새로 해야한다.
- 웹 사이트의 HTML, CSS, JS, 이미지 등의 정적 자원 모두를 다시 다운로드 한다.
  → 캐시, 브라우저 캐싱로 해결
- 현재는 HTTP 지속연결(Persistent Connections)로 문제를 해결한다.
  - 지속 연결 얘기는 위에서 했다!

4️⃣ 텍스트 기반 프로토콜

HTTP는 사람이 읽을 수 있는 문자 형태(Plain Text)로 요청과 응답을 주고받음.
예) 요청 방식: GET /index.html HTTP/1.1

5️⃣ Stateless하지만 확장 가능

원래 HTTP는 상태를 저장하지 않지만, 쿠키, 세션, Token등을 사용해 로그인 상태 유지 가능.
REST API 설계에서도 이런 특징을 활용함.

6️⃣ 보안 (HTTP vs HTTPS)

HTTPS(SSL/TLS 적용 HTTP)는 데이터를 암호화하여 보안성을 높일 수 잇다.

📌무상태 (Stateless)

참고링크
Stateless 구조에서 서버는 단순히 요청이 오면 응답을 보내는 역할만 수행하며, 상태 관리는 전적으로 클라이언트에게 책임이 있는 것이다.
즉, 클라이언트와 서버간의 통신에 필요한 모든 상태 정보들은 클라이언트에서 가지고 있다가 서버와 통신할때 데이터를 실어 보내는 것이 무상태 구조이다.

장점 : 대량의 트래픽 발생 시에도 서버 확장을 통해 대처를 수월하게 할 수 있다
예시 : UDP(Client와의 세션 정보를 Server가 저장하지 않는다는 점에서 Stateless 하다), HTTP

HTTP Message 구조

보이는 것과 같이 요청과 반환의 기본 형태(4단계)는 같고, 안의 내용이 다르게 나온다.
참고링크

1️⃣ Start Line

HTTP 메시지는 요청(request) 또는 응답(response)으로 나뉨.
요청은 request-line, 응답은 status-line을 사용함.
🧡Request Line
- 요청 메시지는 메서드(Method) + 요청 대상(Request-Target) + HTTP 버전으로 구성됨.
- request-line = method SP request-target SP HTTP-version CRLF
- method = token
- 너무 긴 요청 라인은 414 URI Too Long 오류를 반환해야 함.
💚Status Line
- 응답 메시지는 HTTP 버전 + 상태 코드(Status Code) + 이유 문구(Reason Phrase)로 구성됨.
- 응답의 기본 형식 = HTTP-version SP status-code SP reason-phrase CRLF
- status-code = 3DIGIT
- 상태 코드는 3자리 숫자로 구성되며, 의미는 RFC 7231 참조.

2️⃣ Header Fields

header-field = field-name ":" OWS field-value OWS
- 필드 이름: 값 형식으로 작성됨.
field-name = token
field-value = *( field-content / obs-fold )
field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ]
- 대소문자를 구분하지 않음.
field-vchar = VCHAR / obs-text
필드 간 순서는 중요하지 않으나, Host(요청)와 Date(응답) 같은 주요 필드는 먼저 보내는 것이 좋음.
단, Set-Cookie 헤더는 예외적으로 여러 개 보낼 수 있음.

3️⃣ Whitespace

OWS = *( SP / HTAB )
; optional whitespace
- 선택적 공백, SP(Space) 사용 권장.
RWS = 1*( SP / HTAB )
; required whitespace
- 필수 공백, SP로 처리.
BWS = OWS
; "bad" whitespace
- 과거 버전 호환성 유지용, 새 메시지에서는 사용 금지.

Header Fields에 대해서

Header Field는 모든 요청 메서드에서 필수로 오가는 내용이다. 그래서 알아둘 내용이 좀 더 많은데,
이 내용들을 요청 헤더와 응답 헤더로 나누어서 적어보겠다.

🧡요청(Request Line)

요청 메서드

이건 줄글로 와라라라라 쓰다가 귀찮아져서 그대로 지선생께 표로 만들어달라고했음

제일 메인이되는 GET,POST,PUT,DELETE,PATCH는 잘 알아두자

📌멱등성(Idempotent)

한번을 호출하거나 수천번을 호출해도 항상 결과는 같다.

요청이 실패한 경우 재시도 하기위해 필요하다.

리소스 조회(GET Method) 재요청 중간에 변경된다면?

재요청 중간에 리소스가 변경되는것은 멱등성으로 고려하지 않는다.

요청 헤더에서 자주쓰이는 것들

Host : 요청하는 대상 서버의 도메인이나 IP 주소를 명시 Host: example.com
User-Agent : 클라이언트(브라우저, 앱 등)의 정보 제공. 웹사이트가 브라우저마다 다르게 동작할 때 참고됨
Accept : 클라이언트가 수락할 수 있는 응답 콘텐츠 타입을 명시
- Accept: application/json
- Accept: text/html,application/xhtml+xml,application/xml;q=0.9
- q 값으로 우선순위를 설정 가능
Authorization : 인증 토큰을 포함하는 헤더 (JWT, Basic Auth 등). 로그인 인증이 필요한 API에서 필수
Content-Type : 요청 본문의 데이터 형식을 지정 Content-Type: application/json
Referer : 사용자가 어디서 왔는지 알려줌 Referer: https://www.google.com/
- CSRF 공격 방어 및 트래픽 분석에 사용
Origin : 요청이 발생한 출처(도메인)를 나타냄 (CORS 관련)
Accept-Encoding : 클라이언트가 지원하는 압축 방식 명시 -> 서버가 압축하여 응답하면 네트워크 성능 개선 가능

사실 뭐라는진 잘모르겠음 Referer와 Origin의 차이점에 대해서도 좀 모호하고 ,.,.,.,,.,

💚응답(Request Line)

상태 코드(Status Line)

1️⃣ 1xx (정보)

요청 수신 후 처리중인 상태
잘 사용하지 않는다.

2️⃣ 2xx (성공)

정상 처리 완료된 상태

3️⃣ 3xx (리다이렉션)

요청을 완료하려면 추가 행동이 필요한 상태
3xx 응답 + Location HTTP Header가 있으면 Location 위치로 리다이렉트 한다.

4️⃣ 4xx (클라이언트 에러)

클라이언트측 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없다.
클라이언트의 요청이 잘못되었기 때문에, 같은 요청의 재시도는 실패한다.

5️⃣ 5xx (서버 에러)

서버 오류, 요청은 정상이지만 서버가 처리하지 못함
재시도하면 성공할 수 있다.

ex) 서버가 일정시간 다운되었다가 다시 살아난 경우

❗유의점

새로운 상태 코드가 추가되어도 변경할 필요가 없다.

디테일한 코드를 몰라도 몇 번대 코드인지만 알면 된다.

응답 코드를 상황에 맞게 잘 작성 해야 한다. 매우 기본이고 매우 중요하다.

응답 헤더에서 자주 쓰이는 것들

Content-Type : 브라우저나 클라이언트가 응답을 어떻게 해석할지 결정
- Content-Type: application/json; charset=utf-8
Content-Length : 응답 바디의 크기(바이트 단위)
Cache-Control : 클라이언트 및 프록시의 캐싱 정책을 결정 (NMN초 동안 캐싱 가능 기재)
Set-Cookie : 서버에서 쿠키를 설정하는 헤더. 여러 속성으로 보안 강화가능하다.
Location : 리다이렉트 응답 시 이동할 URL을 지정 (3xx 상태 코드와 함께 사용됨)
Access-Control-Allow-Origin :CORS 정책에 따라 요청을 허용할 도메인 지정 (특정 도메인만 허용할 수도 있음)
ETag : 리소스의 버전(해시값 등)을 제공하여 변경 여부 확인 가능
Server : 서버 소프트웨어 정보 제공.