본 게시글은 김영한님의 HTTP 웹 기본 지식 강의를 보고 정리한 글입니다.
🔍 HTTP?
HTTP (HyperText Transfer Protocol)
HTTP는 알다시피 너무나도 대중화되있고 너무나도 잘 알려진 프로토콜이다. 그래서 HTTP라는 단어는 많이 들어보기도 하고 앞선 주제에서 말했던 URL중 대부분의 첫 시작이 http: 아니면 https: 로 시작하는것을 많이 보게 된다.
거의 모든 것이 HTTP라는 말이 있을 정도로 HTTP 메시지에 모든 것을 전송을 시켜 보내는데 보낼 수 있는 것들은 다음과 같다.
- HTML, TEXT
- IMAGE, 음성, 영상, 파일
- JSON, XML(API)
- 거의 모든 형태의 데이터 전송 가능
- 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용
HTTP의 역사
어느때서나 과거를 몰라선 나중을 알 수 없듯이 한 번 어떤 역사를 가졌는지 알아보자.
- HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더X
- HTTP/1.0 1996년: 메서드, 헤더 추가
- HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전
- RFC2068(1997) -> RFC2616(1999) -> RFC7230~7235(2014)
- HTTP/2 2015년: 성능 개선
- HTTP/3 진행중: TCP 대신에 UDP 사용, 성능 개선
그리고 또한 우리가 알고있는 프로토콜인 TCP, UDP는 각각 HTTP/1.1, HTTP/2 UDP는 HTTP/3 버전을 사용을 하고 있다. 한 번 살펴볼까?
위 그림은 이제 구글 사이트에서 "위키" 라는 것을 검색했을때의 네트워크 창을 열었을때이고 두 번째 그림은 위키백과 홈페이지를 들어갔을때 살펴봤던 네트워크 창이다.
h3, h2라고 적힌것이 있는데 HTTP/2, HTTP/3을 표현한 것이다. 근데 신기한 것이 이미 구글에서는 검색화면에서는 이미 HTTP/3 프로토콜을 적용시키고 있다는 것을 알 수 있었다.(UDP) 지금 이 순간에도 계속해서 다들 이제 UDP로 이제 넘어가려고 한다는 말이 진짜로 일어난다는 것을 눈으로 볼 수 있었다. 다음 사진에 있는 위키백과 홈페이지도 나중에는 Protocol밑에 다 h3로 변해있을 지도 모르겠다.
📌 HTTP 특징
이제 http에 대한 특징들에 대해서 하나씩 알아보겠다.
1. 클라이언트 서버 구조
HttpRequest, HttpResponse라는 메서드를 보거나 사용해본적이 있을 것이다. 음... 크롤링 할때나 다른 홈페이지에서 데이터들을 가져올때 말이다. 여기서 Request Response라는 것을 사용하는 구조자체가 클라이언트 서버 구조라는 것을 표현하는 말이기도 하다. 클라이언트가 Request를 하고 서버가 Response를 하는 구조 말이다.
그래서 통신을 할 때 1. 클라이언트에서 서버에게 요청 2. 서버의 응답을 대기 3. 서버가 요청에 대한 결과를 만들어서 클라이언트에게 응답. 하는 구조가 된다.
❗❗❗❗ 2. 무상태 프로토콜(stateless)
무상태라는 말인데 이게 무슨 말일까 해석해보면 서버가 클라이언트의 상태를 보존하지 않는다. 라는 말이다.
장점: 서버의 확장성이 높음(스케일 아웃)
단점: 클라이언트가 추가 데이터 전송
예시로 한 번 어떤 점이 문제가 생길지 알아보자.
✔Stateful 상태일 경우
고객: 이 노트북은 얼마인가요?
점원: 100만원 입니다.(노트북 상태 유지)
고객: 그럼 2개 구매할게요.
점원: 200만원입니다. 신용카드, 현금 중 어떤 걸로 구매 하실건가요?(노트북, 2개 구매 상태 유지)
고객: 신용카드요.
점원: 네 결제되셨습니다.(노트북, 2개, 신용카드 상태 유지)
그치만 중간에 점원이 바뀌게 되는 경우가 생긴다면? - 오류가 일어나게 될 것
고객: 이 노트북은 얼마인가요?
점원A: 100만원 입니다.
고객: 그럼 2개 구매할게요.
점원B: ? 어떤 걸 구매하시겠어요?
고객: 신용카드요.
점원C: ? 어떤 제품을 몇 개 신용카드로 구매하실건가요?
위 예시처럼 점원이 바뀌어도 대화가 잘 통해야되는데 잘 안 통하는걸 볼 수 있다. 그러면 다른 경우도 한 번 보자.
✔Stateless가 될 경우
고객: 이 노트북은 얼마인가요?
점원A: 100만원 입니다.
고객: 그럼 노트북 2개 구매할게요.
점원B: 200만원입니다. 신용카드, 현금 중 어떤 걸로 구매 하실건가요?
고객: 노트북 2개 신용카드로 결제할게요.
점원C: 네 결제되셨습니다.
딱히 점원이 바뀌는 경우가 일어난다고 하여도 별로 상관이 없다는 것을 알 수 있다.
💥 stateful과 stateless일때의 차이
stateful: 점원의 입장이 바뀌게 된다면 바로 대화가 통하지 않게 된다.
stateless: 점원이 바뀌든 말든 별 상관없이 대화가 통한다. 즉 점원을 바꾸어도 별 상관이 없다.
stateless의 입장에서 보면 고객들이 갑자기 마구마구 들이닥쳐도 여러 점원들이 다같이 대응을 할 수 있다. 이 말인즉슨, 갑자기 클라이언트 요청이 마구마구 증가한다 하여도 서버를 대거 투입할 수 있다는 말이다.
무상태라면 응답 서버를 쉽게 바꿀 수 있다는 뜻이 된다. 이러면! 무한한 서버의 증식이 가능하다고 한다.(가능하다면)
이것에 대하여서 글로만 작성해서는 이해하기가 쉽지 않을 거 같다. 그래서 다음과 같은 그림들을 확인하면서 이해하는 것이 좋을 거 같다.
🙄 그치만 Stateless 해야 할 게 있고 아닌게 있다.
물론 stateless를 유지하는게 좋긴하다. 그치만 모든 걸 stateless로 다 유지를 해야 할까? 라고 물어본다면 그건 아니다.
어떤 것들이 있을까? ex) 로그인
로그인이 대표적인데 이대로 유지를 안해주게 되면 다른 브라우저로 이동할 때마다 계속 다시 로그아웃되고 다시 로그인 해서 작업들을 계속해서 해야하는 불편한 상황들이 계속 일어난다.
그래서 브라우저에서는 일반적으로 쿠키와 서버 세션을 사용해서 상태들을 유지해준다고 한다. 그니까 이러한 경우 말고는 최대한 다른 것들은 stateless로 유지를 하는 것이 좋다는 거다. 이런 로그인과 같은 경우에는 어쩔 수가 없으니 말이다. ㅠㅠ 어찌보면 이런것이 한계점이라고 볼 수 있는 부분이라고 할 수 있다.
오늘 정리한 글 중 가장 중요한 Stateless를 해야 하는 이유에 대해서 알아보고 또한 그렇게 설계를 하지 못하는 경우에 대해서도 간단하게 알아봤다. 다음 시간에는 또 다른 HTTP의 특징들에 대해서 더 알아보는 시간을 가져보도록 하자.
