안녕하세요! 피피아노입니다 🎵
이번 포스팅에서는 OSI 7계층 중에서 제3계층인 응용계층과 가장 밀접하게 연결되어 있는 HTTP에 대해서 정리를 해보려고 합니다.
HTTP의 개념과 특징을 잘 정리하고 알고 계시면 개발을 할 때에도 직접적인 도움을 많이 받으실 수 있을 겁니다!
그럼 바로 시작하겠습니다!
HTTP란?
먼저 HTTP의 특성에 대해서 배우려면 HTTP가 뭔지부터 알고 넘어가야겠죠? 정말 간단하게 설명하고 넘어가겠습니다.
HTTP(Hypertext Transfer Protocol)는 월드 와이드 웹(WWW)에서 데이터를 주고받기 위한 프로토콜입니다. 웹 브라우저와 웹 서버 간의 통신을 담당하며, 요청(Request)과 응답(Response)을 통해 정보를 주고받는 방식으로 작동합니다. HTTP는 1990년 팀 버너스 리(Tim Berners-Lee)에 의해 처음 개발되었으며, 이후 웹 기술의 핵심으로 자리 잡았습니다.
현재 HTTP의 기본적인 특성
현재 HTTP의 기본적인 특성을 뽑으라면 크게 5가지를 뽑을 수 있습니다.
- 요청-응답 기반 클라이언트-서버 구조 프로토콜
- 미디어-독립적 프로토콜
- 비연결성 프로토콜
- 스테이트리스 프로토콜
- 지속 연결 프로토콜
이렇게 5가지 입니다.
요청-응답 기반 클라이언트-서버 구조 프로토콜
자, 먼저 요청-응답 기반의 클라이언트-서버 구조부터 살펴보겠습니다.
HTTP 클라이언트는 HTTP 요청 메세지를 보내고, HTTP 서버는 HTTP 응답 메세지를 보내주는 형태로 작동합니다.
클라이언트는(예: 웹 브라우저)는 서버에 특정 자원(웹 페이지, 이미지 등)을 요청하고, 서버는 이러한 요청에 대한 응답을 반환합니다.
즉, 다시 말해서 클라이언트와 서버가 요청과 응답을 주고받으면서 메세지 송신이 이루어지는 프로토콜이 HTTP라는 것이죠!
근데 여기서 주의할 점이 그럼 클라이언트와 서버만 HTTP 메세지를 주고 받을 수 있다고 오해하시는 분들이 계시는데
아닙니다!!
서버 간에도 HTTP 메세지를 주고 받을 수 있습니다!
대표적으로 RestAPI 혹은 JSON 파일을 주고받을 때 이럴 때 서버와 서버 간에 메세지를 주고 받는데 이런 것도 HTTP가 이용됩니다.
사실상 응용계층에서 정보를 주고 받을 때 거의 대부분 HTTP를 이용하기 때문에 서버 간에도 HTTP 메세지를 주고 받을 수 있다고 이해하시면 되겠습니다.
미디어-독립적 프로토콜
HTTP는 미디어 타입에 독립적입니다.
HTTP는 오늘날 응용계층에서 데이터 통신 전체를 주관한다고 봐도 될 정도로 어떠한 형태의 데이터도 HTTP 메세지로 데이터를 주고받습니다. 그렇기 때문에 다양한 형식의 데이터를 동일한 프로토콜을 사용하여 전송할 수 있습니다. HTTP는 콘텐츠 타입을 명시하는 Content-Type 헤더를 통해 수신자가 데이터의 형식을 이해하고 적절히 처리할 수 있도록 도와줍니다.
데이터 형태 ex) HTML, JSON, XML, PDF, 이미지, 영상, 파일 등등
이러한 것을 "미디어 독립적이다."라고 표현합니다.
비연결성 프로토콜
정말 중요한 개념인 비연결성 프로토콜입니다.
HTTP는 기본적으로 비연결성 프로토콜입니다. 즉, 클라이언트와 서버 간의 연결은 요청과 응답이 완료되면 종료되는 형태를 가지고 있습니다. 이러한 형태를 가진 이유는 HTTP 프로토콜이 연결성 프로토콜이 되면 치명적인 단점을 가지기 때문입니다.
HTTP 프로토콜이 연결성 프로토콜이 되면 뭐가 안 좋냐?
만약 다수의 클라이언트가 연결을 시도할 경우에 연결을 유지하는 동안 서버의 자원 소모가 너무 커질 우려가 있기 때문에 비연결성 프로토콜로 제작이 되었습니다.
하지만 이러한 비연결성으로 인해 단점도 발생하게 되는데, 매번 연결을 설정하고 종료하는 오버헤드가 발생할 수 있습니다. 이러한 단점을 보완하기 위해 지속 연결(keep-alive) 기능이 도입이 되었다는 점 알고 계시면 되겠습니다.
스테이트리스 프로토콜
이것도 중요한 개념인데,
HTTP는 각 요청은 독립적이며, 이전 요청에 대한 상태 정보를 저장하지 않습니다. 즉, 서버는 클라이언트의 상태를 기억하지 않는다는 거죠.
그럼 HTTP는 왜 스테이트리스 기반의 프로토콜로 만들어졌냐?
만약에 HTTP가 스테이트풀 프로토콜이 된다면 클라이언트는 한 서버에 종속될 수 있다는 우려가 발생하게 됩니다.
예를 들어서 HTTP 서버가 A, B, C, D 이렇게 여러 대의 서버가 있다고 가정을 해봅시다. 그런데 클라이언트가 A라는 서버한테 요청을 보내고 응답을 받았을 때, 만약 HTTP가 스테이트풀 프로토콜이라면 A라는 서버가 해당 클라이언트 정보를 다 가지고 있을 텐데 A 서버가 문제가 생긴다? 그럼 해당 클라이언트는 통신을 할 수 없게 되니까 지금까지의 상태가 날아가게 됩니다.
그럼 서버에 문제가 안 생기면 상관이 없지 않냐?라고 생각하시는 분들이 계실 수 있는데 그렇지 않습니다.
이렇게 A, B, C, D 여러 대의 클라이언트가 존재할 때 이 클라이언트들이 하나의 서버에 동시다발적으로 접속하게 되면 A 서버는 과부하가 오게 되는데 해당 클라이언트들의 정보를 기억하는 건 A 서버 밖에 없으니 A 서버에 접속할 수밖에 없습니다.
이렇게 HTTP가 스테이트풀 프로토콜일 경우 클라이언트가 한 서버에 종속될 수 있기 때문에 스테이트리스 프로토콜로 만들어졌고 그렇기 때문에 서버의 확장에 용이해진다고 이해하시면 좋을 것 같습니다.
지속 연결 프로토콜
HTTP/1.1부터 도입된 지속 연결(keep-alive) 기능은 하나의 TCP 연결을 통해 여러 개의 요청과 응답을 처리할 수 있게 해줍니다. 즉, 한번 TCP로 연결이 됐다면 그 연결을 통해서 여러번 요청을 주고 받을 수 있다는 겁니다. 이렇게 되면 메시지를 주고 받을 때마다 연결을 요청하고 끊고를 안 해도 되니까 혼잡도도 낮아지고 시간 지연도 줄어들게 되겠죠?
이를 통해 연결 설정 및 종료에 드는 오버헤드를 줄이고, 전반적인 성능을 향상시킬 수 있습니다. 지속 연결은 특히 다수의 리소스를 요청하는 웹 페이지에서 효과적이며, 페이지 로딩 시간을 단축시키는 데 기여할 수 있다는 특징을 가지게 됩니다.
HTTP 버전별 특성
- HTTP 0.9: 단일한 요청 방법(GET 메서드), 비지속 연결
- HTTP 1.0: 기본적인 요청-응답 모델로, 각 요청마다 새로운 TCP 연결을 생성
- HTTP 1.1: 지속 연결 기능 추가
- HTTP 2.0: 바이너리 프로토콜로 전환, 멀티플렉싱 지원, 헤더 압축
- HTTP 3.0: UDP 기반 프로토콜인 QUIC로 변경되어 지연 감소, 연결 복원력 향상, 빠른 전송 속도 제공
HTTP 버전별 특성을 정리하면 위와 같이 정리할 수 있습니다. 오늘날 가장 많이 사용되는 버전은 1.1 버전과 2.0 버전입니다. HTTP 3.0 버전도 점차 점유율은 높아지고 있는 상태이지만 아직까지는 1.1과 2.0을 많이 쓴다고 이해하시면 됩니다.
감사합니다.
잘못된 내용이 있거나 더 좋은 내용 피드백은 언제나 환영합니다!
궁금하신 부분은 댓글로 질문 부탁드립니다!
'CS > 네트워크' 카테고리의 다른 글
[네트워크] LAN의 개요(2) (0) | 2023.10.15 |
---|---|
[네트워크] LAN의 개요(1) (0) | 2023.10.14 |
[네트워크] IP, TCP, UDP (2) | 2023.10.09 |
[네트워크] Internet Protocol (0) | 2023.10.07 |
[네트워크] TCP/IP 계층 구조 (0) | 2023.10.06 |