[Computer Science] HTTP (Hyper Text Transfer Protocol)

HTTP 통신

인터넷에서 클라이언트와 서버 간의 통신에 사용되는 애플리케이션 계층 프로토콜
주로 웹 페이지, 이미지, 동영상 등 다양한 리소스를 요청하고 전달하는 역할

특징

요청(request)과 응답(response)을 중심으로 작동
클라이언트가 요청을 보내면, 서버는 해당 요청에 대한 응답을 보냄.
HTTP 요청은 메서드(예: GET, POST, PUT, DELETE 등), header, body로 구성

요청 메서드는 수행할 작업을 나타내며, 응답에는 요청 결과와 상태 코드(예: 200 OK, 404 Not Found)가 포함됨.

 

상태가 없는(stateless) 프로토콜.
각 요청이 독립적으로 처리되며, 이전 요청의 정보를 유지하지 않음

이를 해결하기 위해 쿠키와 세션을 사용해 상태를 추적함

쿠키는 클라이언트에 저장된 작은 데이터 조각이며, 이후 요청 시 자동으로 서버에 전송됨

세션은 서버 측에 저장되어 클라이언트 활동을 추적하는 데 사용

 

가장 큰 단점은 보안이 취약하다는 점임.
전송되는 데이터가 암호화되지 않아 중간에서 탈취될 가능성이 있음.
이를 개선하기 위해 HTTPS(HTTP Secure) 프로토콜이 등장함.
HTTPS는 HTTP 위에 SSL/TLS 암호화 계층을 추가해 데이터를 안전하게 전송함.

HTTP/1.0

1996년에 RFC 1945로 표준화된 초기 HTTP 버전

웹의 초창기 기술 발전과 함께 등장해 현재의 HTTP와 비교해 몇 가지 중요한 한계와 특징을 가짐

 

연결의 비효율성

• HTTP/1.0에서는 요청-응답 후 연결이 바로 종료되는 비연결형 모델을 사용함.
• 각 리소스에 대해 별도의 연결을 설정해야 하므로 네트워크 지연(latency)이 발생함.
  • 예를 들어, 한 웹 페이지를 구성하는 여러 이미지와 CSS 파일에 대해 각각의 HTTP 연결을 새로 만들어야 함.

헤더와 메서드의 제한:

• HTTP/1.0은 GET, POST와 같은 제한된 메서드만 지원하며, 현재의 HTTP에서 사용되는 다양한 메서드와 헤더가 포함되지 않음.
• 콘텐츠 압축, 캐싱, 상태 코드에 대한 세부 제어도 제한적이었음.

캐싱의 비효율성:

• HTTP/1.0에서는 캐시 제어가 단순하게 동작함.
• 주로 응답에 포함된 Expires 헤더를 통해 캐시 만료 시점을 지정
  • 유연하지 못하고, 시간 차이로 인해 캐시 불일치 문제가 발생할 수 있었음.

HTTP/1.0의 이러한 한계는 웹이 점차 복잡해지면서 성능 병목을 유발함. 이후 등장한 HTTP/1.1에서 여러 개선점이 추가되어 더 나은 연결 관리와 확장된 기능을 제공

 

  HTTP 1.2, HTTP 1.3  ->  대부분 HTTP/2 및 HTTP/3 을 잘못 표기한것

( HTTP 1.2, HTTP 1.3 이 실재로 존재하긴 했음)

HTTP/2

HTTP/2는 2015년에 표준화되었으며, HTTP/1.x의 성능 문제를 해결하기 위해 등장함.

Google의 SPDY 프로토콜을 기반으로 개발됨.

 

멀티플렉싱(Multiplexing):

• HTTP/2에서는 하나의 TCP 연결을 통해 여러 요청과 응답을 동시에 주고받을 수 있음.
• 이를 통해 네트워크 지연을 줄이고, 여러 리소스가 동시에 로드되도록 함.

헤더 압축:

• HTTP/2는 HPACK이라는 알고리즘을 사용해 HTTP 헤더를 압축함.
• 이로 인해 대역폭 사용량이 감소하고 응답 속도가 빨라짐.

서버 푸시(Server Push):

• HTTP/2는 클라이언트가 요청하지 않은 리소스도 서버가 미리 전송할 수 있는 푸시 기능을 제공함.
• 예를 들어, HTML 문서를 요청할 때 관련 CSS와 JavaScript 파일을 서버가 미리 클라이언트에 보낼 수 있음.

보안:

• HTTP/2는 HTTPS를 기본으로 사용하도록 권장함.
• 대부분의 HTTP/2 연결은 암호화된 TLS 위에서 작동함.

HTTP/3

HTTP/3는 2020년에 표준화된 최신 프로토콜로, UDP 기반의 QUIC 프로토콜을 사용함.

TCP의 한계를 극복하고 더욱 빠르고 안정적인 전송을 목표로 함.

 

빠른 연결 수립:

• HTTP/3에서는 초기 연결 설정이 매우 빠름.
• 기존의 TCP와 TLS 핸드셰이크 과정을 단축해 첫 요청-응답 시간을 줄임.

손실 복구 개선:

• HTTP/2는 하나의 연결에서 패킷이 손실되면 전체 연결에 영향을 미침.
• 반면 HTTP/3는 QUIC의 멀티플렉싱 기능 덕분에, 개별 스트림의 패킷 손실이 다른 스트림에 영향을 미치지 않음.

모바일 환경에 적합:

• HTTP/3는 네트워크 환경이 불안정한 모바일 환경에서도 더 나은 성능을 제공함.
• QUIC은 IP가 바뀌더라도 연결을 유지할 수 있어, 예를 들어 와이파이에서 LTE로 전환해도 연결이 끊기지 않음.

HTTP/2와 HTTP/3는 모두 현대 웹의 성능과 사용자 경험을 크게 개선함.

특히 대용량 데이터나 실시간 애플리케이션에서 효율적인 통신을 제공함.

HTTP/3의 채택은 아직 초기 단계지만, 점점 더 많은 웹사이트와 브라우저가 이를 지원하고 있음.