HTTP 특징

HTTP 특징

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

클라이언트는 서버에 Request하기 Response 받기 까지 대기를 한다.

무상태 프로토콜 (Stateless)

Stateless는 서버가 클라이언트의 상태를 보존하지 않는 기법을 의미한다. 

상태 유지 (Stateful) 서버

Stateful의 경우는 클라이언트A의 상태(세션 정보, 로그인 정보 등)를 서버1이 들고 있기 때문에 서버1이 에러가 난다면 다른 서버로의 전환이 어렵다.

무상태 (Stateless) 서버

무상태 (Stateless) 서버

반면 무상태는 클라이언트의 상태 정보를 저장하지 않기 때문에 서버에러가 발생하여도 다른 서버로 전환이 쉽다.

그러므로 스케일 아웃, 즉 서버를 수평 확장함에 있어 유리하다.

무상태 (Stateless) 의 한계

모든 것을 무상태로 설계하는 것은 불가능하다!
예를 들어 로그인 정보같은 경우에는 사용자의 로그인 정보를 서버에서 가지고 있어야한다. 그러나 이러한 경우도 외부 분산 캐시나 세션 스토어(예 : Redis, Memcached, DB)로 관리하면, 서버는 Stateless에 가깝게 설계가 가능하다.

비연결성

• HTTP는 기본이 연결을 유지하지 않는 모델
• 이로 인해 서버 자원을 효율적으로 사용할 수 있음

비연결성의 한계

• 특정 작업마다 TCP/IP의 연결을 새로 맺어야한다. 이는 3 way handsake를 진행해야하므로 비효율적이다.
• 웹브라우저로 사이트를 요청하면 HTML 뿐만 아니라 수많은 자원들이 함께 다운로드된다.
• 지금은 HTTP 지속연결로 문제를 해결하였다.
• HTTP/2, HTTP/3에서 더 많은 최적화를 이루어냈다.

사진과 같이 초기에는 각 요청마다 다른 응답을 받아야했다.

최근에는 HTTP 지속 연결을 통해 연결된 상태에서 요청들에 대한 응답을 받고 연결을 종료하는 형태로 최적화 되었다.

HTTP 메세지

HTTP 메세지는 위 사진과 같은 구조를 가진다.

요청 메세지는
시작 라인 : HTTP 메서드, 요청 대상 주소, HTTP 버전
헤더 : 호스트 주소
메세지 바디 : 있을 수 있고 없을 수 있음

응답 메세지는
시작 라인 : HTTP 버전, HTTP 상태코드
헤더 : HTTP 헤더 (HTTP 전송에 필요한 부가정보, 표준헤더들 존재)
공백 라인
메세지 바디 : 실제 전송할 데이터

위와 같은 구조로 이루어져 있다.
나는 유니티 개발자라 웹 통신으로 해본 적이 없지만, 유니티에서도 UnityWebRequest를 통해 HTTP 통신의 한 아키텍처인 RESTful API형태로 통신을 주고 받는다.
Request할 패킷과 Response 받은 패킷 또한 위와 같은 구조와 거의 유사하게 이루어져 있다.
물론 이 경우는 웹 서버와 통신을 진행할 경우에 그럴 것이다.

해당 내용은 김영한님의 HTTP 웹 기초 강의(인프런)의 자료와 내용을 사용하였습니다.