wecode [TIL]

[TIL] H.T.T.P (Hyper-Text Transfer Protocol)

프린벼르 2022. 2. 13. 00:58

HTTP 표지

 

HTTP가 무엇인지, 대표적인 특성들은 무엇인지에 대해서 포스팅하려한다.  HTTP는 워낙 내용이 방대하기 때문에 오늘은 간략하게 정리해보고자 한다.

Hyper-Text Transfer Protocol 무엇인가?

  • Hyper-Text : 문서와 문서가 링크로 연결되어 있다
  • Transfer : 전송하다
  • Protocol : 통신 규약
즉, HTTP는 말 그대로 하이퍼 텍스트를 전송하는 프로토콜을 의미한다.
또한, HTTP는 클라이언트와 서버 사이에 이루어지는 요청/응답 프로토콜이다.
클라이언트, 서버 모두 HTTP를 이용해 통신 하므로 웹 개발자라면 HTTP를 잘 알아야한다.

♥ H T T P 동작

클라이언트 즉, 사용자가 브라우저를 통해서 어떠한 서비스를 url을 통하거나 다른 것을 통해서 요청(request) 하면
서버에서는 해당 요청사항에 맞는 결과를 찾아서 사용자에게 응답(response)하는 형태로 동작한다.

요청 : client -> server       //       응답 : server -> client

HTML 문서만이 HTTP 통신을 위한 유일한 정보 문서는 아니다. Plain text로 부터 JSON 데이터 및 XML과 같은 형태의 정보도 주고 받을 수 있으며, 보통은 클라이언트가 어떤 정보를 HTML 형태로 받고 싶은지, JSON 형태로 받고 싶은지 명시해주는 경우가 많다.

HTTP 동작

♥ H T T P 특징

  • 클라이언트 서버 구조
  • 무상태 프로토콜(Stateless)
  • 비 연결성(Connectionless)
  • 독립적이여서 HTTP 통신상태가 보존안됨

💁🏻‍♀️  1. 클라이언트 서버 구조

클라이언트가 서버에 요청을 보내면 서버는 그에 대한 응답을 보내는 클라이언트 서버 구조로 이루어져 있다.
①  Request Response 구조
②  클라이언트는 서버에 요청을 보내고 응답 대기
③  서버가 요청에 대한 결과를 만들어 응답

💁🏻‍♀️  2.  무상태 프로토콜 – Stateless (정보저장x / 필요정보 한번에 모두 담아서 요청해야함)

HTTP에서 서버가 클라이언트의 상태를 보존하지 않는 무상태 프로토콜이다.간단한 예시를 들자면 이렇다.클라이언트가 서버에게 “저녁에 한강가자”고 말했고 서버가 “그래”라고 답했다. 저녁이 되어 클라이언트는 서버에게 “지금 가자”고 말했고 서버는 대답했다. “뭔솔?”
※ 서버가 클라이언트 상태를 보존(저장)하지 않음
→ 장점 : 서버 확장성 높음
→ 단점 : 클라이언트가 추가 데이터 전송 (번거로움)

💁🏻‍♀️   3. 비 연결성 – Connectionless

비연결성은 클라이언트와 서버가 한 번 연결을 맺은 후, 클 라이언트 요청에 대해 서버가 응답을 마치면 맺었던 연결을 끊어 버리는 성질을 말한다.
<<<<<<<<비연결성의 장점>>>>>>>>
🙋🏻‍♀️ HTTP 프로토콜은 왜 한 번 맺은 연결을 끊는걸까?
💁🏻‍♀️ HTTP는 인터넷 상에서 불특정 다수의 통신 환경을 기반으로 설계되었다.
따라서 연결을 유지하기 위한 리소스를 줄이면 더 많은 연결을 할 수 있으므로 비연결적인 특징을 갖는다.
만약 서버에서 다수의 클라이언트와 연결을 계속 유지해야 한다면, 이에 따른 많은 리소스가 발생하게 되기 때문이다.
<<<<<<<<비연결성의 단점>>>>>>>>
💁🏻‍♀️ 위 장점으로 인한 단점도 존재한다.
서버는 클라이언트를 기억하지 않으므로 동일한 클라이언트의 모든 요청에 대해, 매번 새로운 연결을 시도/해제의 과정을
거쳐야하므로 연결/해제에 대한 오버헤드가 발생한다는 단점이 있다.

♥ 무상태 ( Stateless )

1) 무상태란?

Connectionless(비연결성)로 인해 서버는 클라이언트를 식별할 수가 없는데, 이를 Stateless라고 한다. 여기서 말하는, 클라이언트의 상태를 모른다는 것은 예를 들어보면 다음과 같다.

  1. 쇼핑몰에 접속
  2. 로그인 
  3. 상품 클릭 -> 상세화면으로 이동
  4. 로그인
  5. 주문
  6. 로그인
  7. ....

즉, 매번 새로운 인증을 해야하는 번거로움이 발생하게 된다... 🤦🏻‍♀️

2) 상태를 기억하는 방법 ① - 쿠키

🙋🏻‍♀️ 서비스를 운영하려면 서버가 클라이언트를 기억해야 할 경우가 많은데, 클라이언트를 기억할 수 있는 방법은 없을까?
💁🏻‍♀️ HTTP는 이러한 문제점을 해결하기 위해 브라우저 단에서 쿠키라는 것을 저장하여 서버가 클라이언트를 식별할 수 있도록 한다.

 

3) 상태를 기억하는 방법 ② - 세션

"쿠키" 는 사용자 정보가 브라우저에 저장되기 때문에 공격자로부터 위변조의 가능성이 높아 보안에 취약하다.
이와 달리 세션은 브라우저가 아닌 서버단에서 사용자 정보를 저장하는 구조다. 따라서 쿠키보다는 안전하다.
✋🏻그런데 세션 정보도 중간에 탈취 당할 수 있기 때문에 보안에 완벽하다고 할 수 없다.
또한 세션을 사용하면 서버에 사용자 정보를 저장하므로, 서버의 메모리를 차지하게 되고, 만약 동시 접속자 수가 많은 서비스일
경우에는 서버 과부화의 원인이 됩니다.

 

4) 상태를 기억하는 방법 ③ - 토큰 

쿠키와 세션의 문제점들을 보완하기 위해 토큰( Token )기반의 인증 방식이 도입되었다.
토큰 기반의 인증 방식의 핵심은 보호할 데이터를 토큰으로 치환하여 원본 데이터 대신 토큰을 사용하는 기술이다.
그래서 중간에 공격자로부터 토큰이 탈취당하더라도 데이터에 대한 정보를 알 수 없으므로, 보안성 높은 기술이라 할 수 있다.
대표적으로는 OAuth와 JWT가 있다. 그런데 꼭 토큰 기반의 인증이 좋다고는 할 수 없다.
그렇기에 서비스에 따라 기술의 특징을 잘 이해하여 때에 따라 쿠키, 세션, OAuth, JWT 등을 적절히 사용하는 것이 좋다.

♥ 응답 상태코드

클라이언트가 서버에 요청을 하면, 서버는 요청에 대한 처리 상태를 숫자로 반환하는데 이를 응답코드라 한다.
흔히 웹 개발을 하다 보면 응답코드로 404를 볼 일이 많았을텐데..
여기서 말하는 404 코드는 "웹 페이지를 찾을 수 없다"이다.
이처럼 HTTP 응답에는 상태 코드를 헤더에 추가하여 응답을 한다.

상태 코드를 요약하면 다음과 같다.

  • 100 - 109 ( 메시지 정보 )
  • 200 - 206 ( 요청 성공 )
  • 300 - 305 ( 리다이렉션 )
  • 400 - 415 ( 클라이언트 에러 )
  • 500 - 505( 서버 에러 )
API 개발 시 올바른 상태코드를 응답하는 것은 매우 중요하다.
예를 들어, 사용자가 요청 파라미터를 잘못 입력한 경우는 
잘못된 파라미터로 인해 비즈니스 로직에서 에러가 발생했다고하여, 500 코드를 반환하면 안된다.
사용자가 잘못 입력한 경우이므로, 이 때는 403 코드를 반환해야 맞다.
이처럼 HTTP 응답 코드는 약속이며, 모두가 이해할 수 있는 올바른 코드를 응답하는 것이 중요하다.

♥ HTTP Method

클라이언트가 서버로 요청을 할 때, 어떠한 목적을 갖는 행위인지 HTTP 메서드에 반드시 명시한다.
다음은 HTTP Method를 정리한 것이다.
GET =>  ✔️ 서버에게 리소스를 달라는 요청 ( 조회 )
=================================================================================
HEAD => ✔️ 정확히 GET과 같지만, 서버는 응답으로 엔터티 본문 반환없이 헤더만을 반환
                  ✔️ 클라이언트는 리소스를 가져올 필요 없이 헤더만을 통해 정보를 얻을 수 있음
=================================================================================
PUT => ✔️ 서버가 요청의 본문을 갖고 요청 URI의 이름대로 새 문서를 만들거나,
                    이미 URI가 존재한다면 요청 본문을 변경할 때 사용 ( 수정 )
=================================================================================
POST =>  ✔️ 서버에 입력데이터를 전송하며 요청 엔티티 본문에 데이터를 넣어 서버에 전송 ( 삽입 )
=================================================================================
DELETE => ✔️ 서버에서 요청 URI 리소스를 삭제하도록 요청 ( 삭제 )
                     ✔️  클라이언트는 항상 삭제된다고 생각하지만, 서버에서는 이 요청을 무시할 수도 있음
=================================================================================
TRACE => ✔️ 클라이언트와 목적지 서버 사이에 있는 모든 HTTP 애플리케이션의 요청/응답 연쇄를 따라가면서
                        자신이 보낸 메시지의 이상 유무를 파악
                   ✔️ 서버는 응답 메시지의 본문에 자신이 받은 요청메시지를 넣어 응답하며, 주로 진단을 위해 사용
=================================================================================
OPTIONS => ✔️ 서버에게 특정 리소스가 어떤 메소드를 지원하는지 물어볼 수 있음

 

저작자표시 (새창열림)