HTTP 통신 📡

---

HTTP란?

Hyper Text Transfer Protocol의 약자로, 활용하면 HTML 텍스트 뿐 아니라 다양한 파일을 전송할 수 있다.

HTML, TEXT, 이미지, 음성, 영상, 파일, JSON, XML, 서버 간에 데이터를 주고 받을 때

1. HTTP의 특징

1-1. 클라이언트-서버 구조

클라이언트와 서버가 분리되어 있다.

• 클라이언트
  • 서버에 요청을 보내고 대기
• 서버
  • 요청 결과를 만들어서 응답을 준다

구조를 분리한 것에 대한 이점

• 클라이언트는 UI를 그리는 것에 집중할 수 있다
• 서버는 복잡한 비즈니스 로직을 담당한다

각자 구조를 발전시키는 데에도 용이하다.

1-2.무상태(stateless)

stateful과 stateless의 차이는?

예시

승객과 매표 직원의 대화

Stateful
승객: 서울에서 전주 가는 KTX는 얼마인가요?
직원: 25,000원입니다.
승객: 2장 주세요.
직원: 50,000원입니다. 결제는 무엇으로 하시겠습니까? (KTX 노선과 주문 수량에 대한 상태를 유지)
승객: 체크카드입니다.
직원: 결제과 완료되었습니다. (KTX 노선과 주문 수량, 결제 수단에 대한 상태를 유지)

=> 대화를 주고 받을 때 마다(요청과 응답) 상대는 문맥의 상태를 유지한다.

stateless
승객: 서울에서 전주 가는 KTX는 얼마인가요?
직원: 25,000원입니다.
승객: 2장 주세요.
직원: ??? 무엇을 2장 구매하시는 건가요???
승객: 아까 말했잖아요😳. 서울에서 전주 가는 KTX요!!!
직원: 몇 장인지, 결제 수단은 무엇인지 한 번에 얘기해주세요!

=> 대화를 주고 받을 때 마다(요청과 응답) 상대는문맥의 상태를 알지 못한다.
따라서 한꺼번에 이야기 해야한다.

“서울에서 전주가는 KTX 2장 체크카드로 결제할게요!”

• stateful
  서버가 클라이언트의 이전 상태를 보존한다
  상태를 유지해야함으로, 늘 같은 서버가 유지되어야 한다.
  

• 무상태(stateless)
  서버가 클라이언트의 이전 상태를 보존하지 않는다
  상태를 유지하지 않으므로, 어느 서버가 응답해도 상괸이 없다.
  따라서 클라이언트의 요청이 대폭 증가해도 서버를 증설해 해결할 수 있다.
  

하지만…
=> 모든 것을 stateless로 설계할 수 없다
단순히 로그인만 보더라도 사용자가 로그인한 상태를 서버에 유지시켜 주어야 한다.

이 경우에는 브라우저 쿠키나 서버 세션 등을 사용해 상태를 유지한다.

1-3. 비연결성(connectionless)

비연결성은 클라이언트가 서버에 요청을 하고 응답을 받으면
바로 TCP/IP 연결을 끊어 연결을 유지하지 않는 것이다.
이를 통해 서버의 자원을 효율적으로 관리하고, 수많은 클라이언트의 요청에도 대응할 수 있게 한다.

HTTP는 연결을 유지하지 않는 모델을 기본으로 한다.

수 천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수 십개 이하로 작다.
예를 들어 구글을 수 천명이 이용해도 검색을 수 천명이 동시에 이용하지는 않는다.

하지만…. 수만명이 동시에 이용하는 경우도 있는 것 같다……
마치 이번에 내가 실패한 토트넘 K리그 경기처럼…..

• 비연결성의 장점
  • HTTP는 인터넷 상에서 불특정 다수의 통신 환경을 기반으로 설계되었다.
  • 따라서 서버에서 다수와 클라이언트와 연결을 계속 유지해야 한다면, 이에 따른 많은 리소스가 발생하게 된다.

  연결을 유지하기 위한 리소스를 줄여 더 많은 연결을 할 수 있다

• 비연결성의 단점
  • 서버가 클라이언트를 기억하고 있지 않다.
  • 따라서 동일한 클라이언트의 모든 요청에 매번 새롭게 연결 시도/해제와 과정을 거쳐야한다.

  연결/해제에 대한 오버헤드가 발생한다

KeppAlive
이에 대한 해결책으로 오버헤드를 줄이기 위해 HTTP의 KeepAlive 속성을 사용할 수 있다.
지정된 시간동안 서버와 클라이언트 사이에서 패킷 교환이 없을 경우, 상대방의 안부를 묻기위해 패킷을 주기적으로 보내는 것을 말한다.
이 때 패킷에 반응이 없으면 접속을 끊는다.
하지만 주기적으로 클라이언트의 상태를 체크한다는 것은 완벽한 해결책이 아니다. 서버가 바쁠 때에는 프로세스 수가 기하급수적으로 늘어나기 때문에,KeepAlive로 상태를 유지하기 위한 메모리를 많이 사용하게 되므로 주의해야한다.

1-3. HTTP 상태코드(status)와 메서드(method)

• HTTP 상태코드(status)

클라이언트가 서버에 요청을 하면, 서버는 요청에 대한 처리 상태를 숫자로 반환하는데 이를 응답코드라고 한다.

HTTP 응답에는 상태 코드를 헤더에 추가하여 응답을 한다.

HTTP 응답 코드는 약속이며, 모두가 이해할 수 있는 올바른 코드를 응답하는 것이 중요하다.

• HTTP Method

클라이언트가 서버로 요청을 할 때, 어떠한 목적을 갖는 행위인지 HTTP 메서드에 명시한다.

HTTP Method 설명 (링크)

1-4. 헤더(header)

HTTP 프로토콜 상에서 클라이언트와 서버는 데이터를 패킷 단위로 잘게 쪼개서 통신을 한다.

데이터 전송 단위인 패킷에는 요청/응답에 대한 메시지가 담겨 있다.

패킷의 구조

• 시작라인 ( Request Line )
• 헤더 ( Header )
• 본문 ( Body )

HTTP header 설명 (링크)

2. 상태를 기억하는 방법

서비스를 운영하려면 서버가 클라이언트를 기억해야할 경우가 많다.
그럼 어떻게 기억하게 할 수 있을까?

2-1. 쿠키

HTTP는 이 문제점을 해결하기 위해, 브라우저 단에서 쿠키를 저장해서 서버가 클라이언트를 식별할 수 있게 한다.

• 단점 하지만 쿠키는 사용자 정보가 브라우저에 저장된다.
  따라서 위변조의 가능성이 높기 때문에 보안에 취약하다!
  

2-2. 세션

쿠키와 달리 세선은 브라우저가 아닌 서버에 사용자 정보를 저장하는 구조
따라서 쿠키보다는 안전하다.

• 단점 이 세션 정보도 중간에 탈취 당할 수 있어서 보안이 완벽하지 않다.
  세션을 사용하면 서버에 사용자가 정보를 저장하므로, 서버의 메모리를 차지하고 동시 접속자가 많은 서비스는 서버가 과부화 된다.
  

자세한 쿠키와 세션 설명 (링크)

2-3. 토큰을 사용하는 OAuth, JWT

쿠키와 세션의 문제점을 보완하기 위해 토큰(Token) 기반의 인증 방식이 도입되었다.
토큰 기반 인증 방식의 핵심은 보호할 데이터를 토큰으로 치환해서 원본 데이터 대신 토큰을 사용하는 기술이다.
그래서 중간에 토큰을 탈취당해도, 데이터에 대한 정보를 알 수 없기 때문에 보안성을 높일 수 있다.

대포적으로 OAuth, JWT가 있다.

자세한 OAth, JWT 설명 (링크)