Http! 너무나도 익숙한 이름이다. 우리가 사용하는 인터넷 주소는 대부분 http로 시작한다. 그런데, 이 http에도 여러 버전이 있고, 역사가 있다는 것을 아는가? 이번 글에서는 Http가 무엇이고, 언제 시작하였고, 어떻게 발전해 나갔는지, 차근차근 살펴보고자 한다.
Http란 무엇인가? Http의 정의
Http는 HyperText Transfer Protocol의 약자이다. 한 마디로 문서를 전송하기 위한 프로토콜로, 여기서 말하는 hyper text는 링크, 즉 하이퍼링크가 들어가 있는 문서를 뜻한다. 이 프토콜은 클라이언트가 요청(Request)하면 서버 측에서 응답(Response) 하는 방식으로, 오늘날 웹 통신의 보편화된 표준으로 사용하고 있다.
Http의 역사
아래의 그림과 같이, Http는 점점 발전해왔다. 다만 빠진 점이 있다면 첫 시작은은 1991년에 나온 Http 0.9인데, 이 부분까지 설명하려면 내용이 복잡해져서 인지, 이미지 제작자가 삭제한 것 같다. Http 0.9는 http 첫 프로토콜로, Get 메서드만 적용이 되는, http 헤더나 상태코드는 전송되지 않고, http의 순수 데이터만 전송되는 매우 간결한 프로토콜이다.
Http 1.0
기존의 Http 0.9에서 이제 본격적으로 상용화된 프로토콜이다. 1996년에 발표가 되었고, 서버에서 데이터를 가져오는 Get메서드 뿐만 아니라, 이제 서버에 올릴 수 있도록 Post 메서도 추가가 되었다. 상태코드(status code), 소위 개발자들이 보는 success 202, error 404와 같은 코드 또한 추가되었다. 또한 content type 헤더가 추가되면서, HTML 문서 뿐만 아닌, 다른 형태의 문서도 전송이 가능해지게 되었다. 우리가 현재 사용하는 웹 문서 양식이 Http 1.0에서 갖춰줬다고 생각하면 되겠다!
Http 1.0은 단점, 그리고 이를 극복하기 위한 Http 1.1
하지만, 겉보기에도 잘 구비된 듯한 Http 1.0에도 문제가 있었다. 바로, 단기 커넥션(short-live connection)문제이다. 무슨 말인지 모르겠다고? 그럼 하나하나 파헤쳐보자. Http는 기본적으로 TCP연결로 이루어진다. TCP 연결이 뭐냐고? 음.. 간단하게 설명하자면, 서버 쪽에서 무작정 클라이언트에게 데이터를 쏘아 주는 것(UDP)이 아니라, '자 보낸다? 받았어? 오케이. 그럼 다음 거 보낼께~' 와 같이 서로 확인해 가며 조심스럽게 보내는 방식이다.
이렇게 TCP연결이 이루어 지기 위해선 '우리 이제 서로 통신하기다'와 같은 약속, 즉 핸드쉐이크(HandShake)가 먼저 이루어 져야 하고, 이를 establish connection이라 한다. 문제는, Http의 경우 매 데이터를 주기 위해 통신을 할 때마다 establish connection이 이뤄주어야 한다. 즉 매번 줄 때마다 연결이 되고, 다시 끊어지고, 다시 연결하는 단기 커넥션 형태라는 것!
이러한 단점을 극복하기 위해... Persisten Connection(연속적 연결)과, Pipelining(파이프 라이닝)이라는 기술이 Http 1.1에서 도입이 되었다!
이 두 기술은 매 연결 시 때마다 establish connection을 할 필요도 없다는 장점이 있다. 맨 좌측의 단기 커넥션과 우측과 중앙의 모식도를 보면 이해에 용이할 것이다. Pipelining은 한 번에 여러 개의 요청을 보내는 것이다. 그리고 서버 측에서 응답을 모두 받을 시, 커넥션이 종료된다.
하지만, 이러한 방식에도 문제가 발생을 하고 마는 데...
위의 그림과 같이, 바로 blocking 문제이다. TCP 연결의 특성 상, 요청을 할 시, 응답을 제대로 받고, 확인을 해야 다음 단계로 넘어간다. 문제는 요청을 여러 번 동시에 보냈다고 가정하자, 그 중에 한 요청을 서버가 처리하는 시간이 상당기간 소요되면? 나머지 요청은 대기 상태로 있게되어 지연 상태가 발생하게 된다.
Blocking의 문제를 극복해낸 Http 2.0!
2015년에 발표된 Http 2.0은 여러가지 부분에서 상당한 개선점을 보였다. Blocking 문제를 해결하기 위해, Http 2.0에서는 각 요청을 Frame단위로 나누어 mutiplexing(멀티 플렉싱)하는 방식으로 전송을 하는 것이다! 이해를 돕기 위해 아래 그림을 가져왔다.
그림을 통해 Req A요청에서 Blocking이 일어나는 것을 방지하기 위해, Frame이라는 단위로 잘게잘게 쪼개었다. 그리고 하나의 TCP connection으로 전달을 하는 것. Frame은 유동적이라, 중요하다고 느끼는 Request의 프레임을 먼저 보내거나 혹은 후순위의 경우 늦게 보낼 수 있다.
그 외에도 Http 2.0에는 다양한 기능이 개선되었다. 1. 매 요청마다 헤더가 유사할 경우, 이를 압축을 하는 Compression Header를 통해, 중복되는 다시 보낼 필요가 없도록 간편화 하였다. 2. 그 외에도, binary framing(바이너리 프레이밍)이란, 전송과 처리에 더욱 용이한 방식을 채택했다.
그럼 Http 3.0은 뭐야?
Http 3.0은 2022년에 나온 차세대 Http 통신 프로토콜로, Google에서 발표하였다. 아직 나온 지 얼마 안 되었기 때문에 여전히 Http 2.0이 가장 높은 점유율을 차지하고 있지만, 성장 속도가 상당하다고 한다. Http 3.0은 매번 약속을 하고 확인을 서로 하는 번거로운 TCP 통신 대신에, 서버 쪽에서 광범위하게 데이터를 뿌려버리는 UDP 통신을 기반으로 하는 QUICK이라는 방식을 사용하였다.
TCP의 HandShacking과 다르게 바로 QUICK 연결을 수행하면 된다고 한다. IP와 Port 번호가 아닌 Connection ID라는 식별자로 통신이 오고가기 때문에, 이동할 때마다 인터넷 권역이 바뀌는 이동형 단말기 통신에 적합하다고 한다. (자세한 내용은 어려워서 여기서 끝.)
글을 작성하는데 도움이 된 출처:
https://www.youtube.com/watch?v=ocGtt0IX0Js
'컴퓨터 과학' 카테고리의 다른 글
| 네트워크에서 데이터는 정확히, 어떻게 전송되는가? (9) | 2025.07.03 |
|---|---|
| OS(운영체제)에 대해 알아보기: System Call이란? (15) | 2025.03.12 |
| MySQL과 MongoDB와의 차이점: MongoDB를 사용하는 이유 (0) | 2025.03.09 |
| Docker(도커) vs Virtual Machine(가상머신), 왜 도커를 사용하나? (8) | 2025.03.08 |
| c10k problem: 동시 사용자 1만명 채팅서버는 어떻게 구현되는가? (4) | 2025.03.07 |
