이번 TIL은 인프런의 "모든 개발자를 위한 HTTP 웹 기본 지식"을 학습하고, 정리한 내용입니다.
만약, 제 글의 내용을 퍼갈 시에는 " 모든 개발자를 위한 HTTP 웹 기본 지식 "도 출처에 첨부하시기 바랍니다.
TCP/IP의 경우에는 기본적으로 연결을 유지한다.
그러나, 클라이언트3이 서버에 요청을 보내고 응답을 받는 동안, 클라이언트1과2는 아무것도 하지 않은채 연결만 되있다면, 서버 입장에서는 불필요한 자원을 계속 소모하게 된다.
즉, 아무런 요청도 없이 놀고 있던 클라이언트들의 연결을 잘라내는 모델을 보자!
=> 이렇게 필요한 것만 주고받고, 연결을 끊는다.
서버의 입장에서는 연결을 요청을 주고 받는 순간만 하고 끊어버려서 서버가 유지하는 자원을 최소한으로 줄일 수있다.
그리고 나중에 클라이언트1이나 2가 요청하면, 그 때 또 연결하고!!
이게 그림 상으로는 3개이지만, 실무에는 수만 대 혹은 수십 만대가 될 수도 있다. 그러나, 연결을 유지하는 것과 않는 것의 자원 소모량의 차이가 어마어마하다. => 이게 다 돈이다!!!
=> 수천 명이 동시에 검색을 하고 있는게, 아니라 결과값이 나오면 한참 읽다가 검색을 하기 때문에, 수천명이 사용해도 실제 초당 동시 처리하는 요청의 숫자는 매우 적다. 이럴 때, 비연결성으로 자원 절약을 할 수 있다.
다만, 비연결성도 단점이 존재한다.
=> 처음이라 그렇다치더라도, 상대적으로 긴 시간이 걸리는 3 웨이 악수를 지속적으로 맺어야 한다. 검색 할 때, 1번 다음 페이지로 넘어갈 때 또 1번 등 넘어갈 때마다 연결이 끊겨서 새로 해줘야하는데, 연결 시간이 추가 되서 UX에 안좋은 영향을 미친다.
=> 이런 연결 <-> 비연결의 무한반복이 너무 비효율적이다. 그래서, HTTP는 기본적으로 " 지속 연결 "이라는 것을 사용한다. 그리고 HTTP2와 3에서는 훨씬 더 최적화가 됐다.
지속연결
=> 응답을 주고 받고 연결을 끊고,
=> HTML 주세요 => JS 주세요 => 이미지 주세요
페이지 넘어갈 때 다시 연결해서 주고받고 도합 0.9초가 걸렸다고 하자
=> 지속연결은 처음 연결을 하면, 구현하는 로직마다 다르지만, 일반적으로 연결을 몇 십 초 정도 유지한거나 하는 내부 매커니즘이 있다. 이러면, 연결이 유지되는 동안, 새로운 요청을 할 때마다 더 빠르게 응답을 받을 수있어서 더 좋은 UX를 제공한다.
=> HTTP2와3에서는 이런 것들을 더 빠르게 해결했다. 심지어 3은 UDP 프로토콜을 사용하면서, 연결 속도도 확 줄였다.
=> 이런 선착순 이벤트는 진짜 동시에 수만 개의 요청이 들어온다. 이 정도되면, 비연결성 이딴 거 소용이 없다. 왜냐면, 딱 그 시간에 다 몰려오기 때문에...
=> 그럼에도 반드시 최대한 무상태성으로 설계하는 것이 중요하다!! 어떻게해서든지!!! 그렇게하면, 이런 대량 동시 접속 상황이 와도, 대응할 수 있는 부분이 많아진다.
보통 이벤트 설계할 때, 첫 페이지는 그냥 로그인도 필요없는 정적 페이지를 하나 뿌린다. 거기는 아무 상태가 없는 순수 HTML 하나 딱 두고, 사람들이 그 안에 이것저것 보면서 약간 시간을 보내게 한다음에, 이벤트 참여 버튼을 누르게 하거나 하는 식으로 트래픽을 줄인다.
중요한 것은 어떠한 상황에서도 최대한 무상태성으로 설계해야 한다는 것이다. 정말 어쩔 수없는 부분에 한해서만 상태를 유지하는 방향으로 상태를 분리하는 것이 중요하다.
다음 시간에는 본격적으로 가장 중요한 HTTP 메세지에 대해서 알아보자!!
