3) HTTP 기본

HTTP(HyperText Transfer Protocol)

 

요즘은 모든 것들이 HTTP로 전송이 된다.

HTML, TEXT 부터 시작해서

음성,영상,이미지, json, API 등등 거의 모든 형태의 데이터들이 전송 가능하다.

HTTP도 버전들이 있는데, HTTP1.1과 2에선 TCP가, HTTP3에선 UDP로 되어있다.

현재는 HTTP1.1을 주로 사용하고 있다 정도로만 알면 된다.

 

HTTP의 특징

• 클라이언트 서버 구조
• 무상태 프로토콜(stateless), 비연결성
• HTTP 메시지
• 단순함, 확장 가능성

 

• 클라이언트 서버 구조

• 무상태 프로토콜(stateless)
  서버가 클라이언트의 상태를 보존하지 않는다.
  서버 확장성이 높다(스케일 아웃)
  클라이언트가 추가 데이터를 전송해야 한다는 단점이 있다.
  
  이렇게만 써있다면 무슨 소리인지 잘 이해가 되지 않는다. 예시를 이해해보자.

먼저 상태 유지(Stateful)을 생각해보자.

점원은 고객이 2개라고 말한 것이 노트북이라는 것을 알고 있고, 200만원을 결제한다는 것도 이전에 알고 있다.

근데 만약 상태 유지가 안된다면? 

즉, 고객 입장에선 좀 더 구체적으로 내용을 추가해서 말해줘야한다.

마치 처음 사람에게 말해주는 것처럼.

즉, 이게 무상태라는 개념이다.

무상태인 경우, 중간에 다른 점원으로 바뀌어도 된다. 어차피 다 새로 말해줄 것이기 때문에.

그렇다는 이야기는, 요청이 증가해도 서버를 대거 투입할 수 있다는 이야기다. 

 

기존의 상태유지일 경우, 그 정보를 아는 서버 하나랑만 계속 통신을 해야한다.

그런데 그 서버가 에러가 난다면? 난리 나겠지.

하지만 무상태일 경우, 아무 서버나 호출해도 된다. 해당 서버가 고장나면 다른 서버랑 통신하면 된다.

 

예를 들어 간단한 소개 화면 등에선 상태를 유지할 필요가 없다.

그런데 로그인 상태유지처럼 상태유지가 필요한 기능이라면 추후에 배울 쿠키와 서버 세션등을 이용해 상태를 유지한다.

상태 유지의 경우 아까처럼 단점들이 있기 때문에 최소화 하는 것이 좋다.

 

*비연결성

만약 연결을 유지해야하는 모델이 있다고 생각해보자.

서버는 연결을 계속 유지해야하는데, 클라이언트들이 계속 요청을 보내면 서버의 자원이 계속 소모가 된다.

 

만약 연결을 유지하지 않는 모델이라면?

그냥 클라이언트의 요청 때마다 응답하고 TCP/IP 연결을 종료하면 된다. 그렇게 되면 최소한의 자원만 유지할 수 있다.

HTTP는 기본이 연결을 유지하지 않는 모델이다.

빠른 속도로 응답을 해야하기 때문이다.

예를 들어 1시간동안 수천명이 서비스를 사용해도 실제 서버에서 동시적으로 처리하는 요청은 많지 않다.

그렇다보니 비연결성을 사용하는 것이 효율적일 것이다.

물론 단점은 있다. 

매 번 연결을 해야하니, TCP/IP연결을 때마다 해야하고, 그렇다보면 3 way handshake하는데 시간이 걸릴 것이다

또 단순히 html이 아니라 js, css 등의 자원들도 같이 다운로드 해야하니 시간이 걸리지.

 

현재는 HTTP 지속 연결(Persistent Connections)로 문제를 해결했다.

초기에는 매 자원들마다 연결하고 받고 종료를 하다보니 시간이 너무 오래 걸리는 문제가 생겼다.

현재는 데이터들을 다 요청해서 다 받은 다음에 종료를 하게 되면 시간이 절약된다.

 

 

*HTTP 메세지

* 시작 라인

 - http 요청 메세지 : HTTP메서드(GET...) + 요청대상 + HTTP Version

 - http 응답 메세지 : HTTP Version + HTTP 상태코드 + 이유 문구

 

* 헤더

 http 전송에 필요한 모든 부가정보라고 생각하면 된다.

 

* 메세지 바디

실제 전송할 데이터 (html, json, 이미지 등등)