[260115] HTTP 란 (http 인증, http 응답 코드 등)

HTTP | MDN

HTTP 란 (Hypertext Transfer Protocol) 

• HTML 과 같은 하이퍼미디어 문서를 전송하기 위한 애플리케이션 계층 프로토콜 
• 웹에서 이뤄지는 모든 데이터 교환의 기초. 
• 웹 브라우저와 웹서버 간의 통신을 위해 설계되었지만, 다른 목적으로도 사용 가능. 
• 클라이언트가 요청을 하기 위해 HTTP 연결을 연 다음 응답을 받을 때까지 대기하는 "클라이언트-서버" 모델을 따름. 
• 무상태(state-less) 프로토콜로, 서버가 두 요청 간에 어떠한 데이터도 유지하지 않음. 

출처: https://developer.mozilla.org/ko/docs/Web/HTTP/Guides/Overview

 

1) HTTP 헤더의 확장성 

출처 : https://bytebytego.com/guides/important-things-about-http-headers-you-may-not-know/

• 헤더는 컨텍스트에 따라 그룹핑될 수 있음. 
  • Request header: 페치될 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더.
  • Response header: 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더 
  • 등등 
• 헤더는 클라이언트와 서버가 요청 또는 응답으로 부가적인 정보를 전송할 수 있도록 해줌. 
• 대소문자를 구분하지 않는 이름과 콜론 ' : ' 다음에 오는 값(줄 바꿈 없이) 으로 이루어져있음. 
• 클라이언트와 서버가 새로운 헤더의 시맨틱(의미)에 대해 간단한 합의만 한다면, 언제든 새로운 기능을 추가할 수 있음. 
• 즉, 헤더(Header)라는 공간 덕분에 인증, 캐싱, 보안 등 새로운 기능을 계속 추가할 수 있음.

 

2) HTTP 메시지 구조 - 요청 (request) 

Method: 수행할 작업의 종류GET(가져오기), POST(저장하기), PUT, DELETE

Path: 리소스의 위치 (URL에서 도메인 제외)/api/v1/login

Headers : 요청에 대한 부가 정보 (데이터 타입, 인증 토큰)Authorization: Bearer <JWT>, Content-Type: application/json

Body : 실제 서버로 보낼 데이터 (GET은 보통 없음){"id": "eunsil", "pw": "1234"}

 

3) HTTP 메시지 구조 - 응답 (response) 

Status Code : 요청의 결과 상태200(성공), 401(인증 안됨), 403(권한 없음)

Headers : 응답에 대한 부가 정보Content-Type: application/json, Set-Cookie

Body : 서버가 돌려준 데이터{"accessToken": "eyJ...", "user": "eunsil"}

 

 

 

HTTP 상태 코드 

• http 요청이 성공적으로 완료되었는지 알려주는 코드 
• 5개의 그룹으로 나눠짐 

1) 정보 응답 

• 요청이 수신되었으며 프로세스가 계속됨을 나타냄 

상태 코드	명칭	설명
100	Continue	지금까지의 상태는 괜찮으며, 클라이언트가 요청을 계속하거나 이미 완료한 경우 무시해도 됨을 알림
101	Switching Protocol	클라이언트의 Upgrade 헤더 요청에 따라 서버가 프로토콜을 변경할 것임을 알림
102	Processing	서버가 요청을 수신하여 처리 중이지만, 아직 응답을 줄 수 없는 상태 (WebDAV 전용)
103	Early Hints	서버가 응답을 준비하는 동안 클라이언트가 사전 로딩(preloading)을 시작할 수 있도록 함

 

2) 성공적인 응답 

• 클라이언트의 요청이 서버에서 성공적으로 처리되었음을 나타냄 

상태 코드	명칭	설명
200	OK	(중요) 요청 성공. GET은 리소스 전송, POST는 수행 결과 전송 등을 의미함
201	Created	(중요) 요청 성공 및 그 결과로 새로운 리소스가 생성됨 (주로 POST 이후)
202	Accepted	요청 수신은 되었으나 처리가 완료되지 않음 (비동기 처리에 주로 사용)
204	No Content	요청은 성공했으나 응답 바디에 보낼 콘텐츠가 없음 (보통 삭제 요청 후 사용)
206	Partial Content	클라이언트가 범위(Range) 헤더를 보낸 경우, 리소스의 일부분만 전송함

 

3) 리다이렉트 

• 요청을 완료하기 위해 클라이언트의 추가 작업(주로 경로 이동)이 필요함을 나타냅니다.

상태 코드	명칭	설명
301	Moved Permanently	요청한 리소스의 URI가 영구적으로 변경됨. 새로운 URI가 응답에 포함될 수 있음
302	Found	리소스의 URI가 일시적으로 변경됨. 향후 요청은 원래 URI를 사용해야 함
304	Not Modified	(중요) 캐시 목적. 리소스가 수정되지 않았으니 클라이언트는 캐시된 버전을 사용하면 됨
307	Temporary Redirect	리소스가 다른 URI에 있으며, 이전 요청과 동일한 Method(GET/POST 등)로 다시 요청해야 함
308	Permanent Redirect	리소스가 영구적으로 다른 URI에 있으며, 이전 요청과 동일한 Method로 다시 요청해야 함

 

4) 클라이언트 에러 

• 클라이언트의 요청에 문제가 있어 서버가 처리를 거부했음을 나타냅니다.

상태 코드	명칭	설명
400	Bad Request	잘못된 문법 등으로 인해 서버가 요청을 이해할 수 없음
401	Unauthorized	(JWT 핵심) 비인증 상태. 요청을 위해 반드시 스스로를 인증(로그인 등)해야 함
403	Forbidden	클라이언트가 콘텐츠에 접근할 권한이 없음 (401과 달리 서버는 누군지 알지만 거절함)
404	Not Found	요청한 리소스를 찾을 수 없음. 경로가 잘못되었을 때 가장 흔히 발생함
405	Method Not Allowed	요청한 메소드(GET, POST 등)는 알지만 해당 리소스에서 사용할 수 없음
409	Conflict	요청이 서버의 현재 상태와 충돌함 (예: 중복된 아이디 가입 시도)
429	Too Many Requests	사용자가 짧은 시간 내에 너무 많은 요청을 보냄 (Rate Limiting)

 

5) 서버 에러 

• 서버가 유효한 요청을 명백하게 수행하지 못했음을 나타냅니다.

상태 코드	명칭	설명
500	Internal Server Error	서버 내부 오류로 요청을 처리할 방법을 모르는 상황
502	Bad Gateway	게이트웨이나 프록시 서버가 상위 서버로부터 잘못된 응답을 받음
503	Service Unavailable	서버가 일시적인 과부하나 유지보수로 인해 요청을 처리할 준비가 안 됨
504	Gateway Timeout	게이트웨이가 상위 서버로부터 제시간에 응답을 받지 못함

 

 

HTTP 로 제어하는 추가 기능들 

1)  HTTP 쿠키 

• 서버가 사용자의 웹 브라우저에 전송하는 작은 데이터 조각 
  1. 서버의 응답 : 서버 응답시, 쿠키를 생성하거나 저장하고 싶을 때 응답 헤더에 Set-Cookie 라는 필드를 포함해서 보냄
     (예시: Set-Cookie: user_id=eunsil; Max-Age=3600; Path=/)
  2. 브라우저의 저장 : 응답을 받은 브라우저는 헤더를 확인하고, 해당 정보를 자신의 쿠키 저장소에 보관
  3. 이후의 요청 : 이제 브라우저는 동일한 서버에 다시 요청을 보낼 때마다, 저장된 쿠키를 요청(Request) 헤더의 Cookie 필드에 자동으로 담아서 전송
• 쿠키 사용 목적 3가지 
  • 첫번째, 세션 관리(Session management) : 서버에 저장해야 할 로그인, 장바구니, 게임 스코어 등의 정보 관리 
  • 두번째, 개인화(Personalization) : 사용자 선호, 테마 등의 세팅 
  • 세번째, 트레킹(Tracking) : 사용자의 행동을 기록하고 분석하는 용도 
• 이를 통해 상태가 없는 http 프로토콜 환경에서도 서버가 사용자 식별,  가능해짐. 

 

 

2) HTTP 캐싱 

• 이전에 가져온 리소스들을 재사용하는 방법. 
• 서버로부터 받은 리소스의 복자본을 저장하고 있다가 요청 시에 그것을 제공하는 기술
• 레이턴시와 트래픽을 줄여줌으로써 리소스를 보여주는데 필요한 시간을 줄여줌  
  • 저장 위치 
    • 개인 캐시 private cache : 사용자의 웹 브라우저나 앱 내부 저장소(disk/memory) 에 저장. 오직 사용자를 위한 캐시
    • 공유 캐시 shared cache : 클라이언트-서버 사이의 프록시 서버나 CDN(content delivery network) 에 저장. 여러 사용자에게 동일하게 전달되는 리소스를 저장해서 서버 부하를 줄임. 
  • 무엇을 저장하는가 
    • 리소스 자체 : HTML 문서, 이미지, 비디오, CSS 파일, js 파일 등 서버로부터 불러온 하위 문서들
    • 응답 헤더 : 해당 리소스가 언제 생성됐는지, 언제까지 유효한지(만료일), 고유 식별자(ETag) 는 무엇인지 등 
  • 어떻게 제어하는가 
    
    • cache-control : 캐싱 해야하는 대상, 유효 기간 설정 등
    • 유효성 검사(valdation) : 캐시된 데이터가 오래됐을때 서버에게 유효 여부 물음. 304 not modified 의 경우, 데이터 전송 없이 캐시를 사용함. 

 

 

3) Origin 제약 완화 (CORS) 

• 웹브라우저는 보안을 위해 동일 출처 정책(SOP) 을 따른다. 
• Origin(출처): 프로토콜(http/https) + 도메인(eunsil.com) + 포트(8080)가 모두 같아야 동일 출처라고 봄 
• 즉, 자신이 처음 로드된 도메인과 다른 도메인으로는 요청을 보낼 수 없게 제한됨. 
• 왜냐면, 만약 브라우저가 아무 사이트에나 요청 보내는걸 허용하면, 해커가 만든 사이트의 js 가 내 정보 빼갈 수 있게됨. 
• 그러나 보통 
  • (프론트개발서버) react, vue 등은 3000번 포트, (백엔드개발서버) spring boot, node.js 등은 8000번 포트 인경우 
  • 정적 파일을 빠르게 전달하기 위해 s3 같은 스토리지 서버를 사용하는 경우 
  • AWS EC2 클라우드 서버 사용 
  • 서브 도메인 등등 
  • 현실적인 이유로 주소는 다르지만, 데이터는 주고 받아야 하는 상황이 발생함 ! 
• CORS (Cross-Origin Resource Sharing): HTTP 헤더를 통해 이 제약을 안전하게 완화하는 메커니즘 
• 작동 방식: 서버가 응답 헤더에 Access-Control-Allow-Origin을 실어 보내면, 브라우저는 해당 도메인의 접근을 허용함. 

 

4) 커넥션 관리와 진화 

• http 메시지 교환을 위해서는 클라이언트와 서버 사이의 TCP 연결이 먼저 설정되어야 함. (네트워크 4계층 참고) 
• 웹이 발전하면서 더욱 빠르고 효율적인 방법이 고안되어옴. 
• "어떻게 하면 연결을 맺고 끊는 낭비를 줄이고 한 번에 더 많은 데이터를 보낼 것인가?" 를 해결하면서 진화함. 

단계	주요 특징	설명
HTTP/1.0	단기 커넥션	요청/응답 하나당 매번 새로운 TCP 연결을 맺고 끊음 (매우 비효율적).
HTTP/1.1	지속 커넥션	Connection: keep-alive 헤더를 통해 하나 연결로 여러 요청을 연속해서 처리.
HTTP/2	다중화 (Multiplexing)	단일 연결 상에서 여러 메시지를 동시에 전송하여 대기 시간을 획기적으로 줄임.
HTTP/3	QUIC (UDP 기반)	TCP 대신 UDP 기반의 QUIC 프로토콜을 사용하여 더 빠르고 안정적인 연결 제공.

 

- http 1.1 부터 지속 연결이 가능해짐. 하나의 연결로 여러 연속 요청 처리가 가능해지면서, 이미지 수십개 들어있는 웹 페이지를 빠르게 로드 가능해짐. 

- http 2부터 메시지가 캡슐화돼서 인간이 읽기 어려운 frame 구조로 전송. 

- ok http  라이브러리는 내부적으로 이런 커넥션 풀링, http2, http3 자동 지원함.