HTTP

'HyperText Transfer Protocol'의 약자로 서버와 클라이언트가 서로 데이터를 주고받기 위해 사용되는 통신 규약으로, 네트워크 장치 간에 정보를 전송하도록 설계된 애플리케이션 계층 프로토콜입니다.

⇒ web browser와 web server 사이에서 통신할 때 서로가 알아 들을 수 있는 일종의 약속인 message가 필요

• 초기에는 HTML 파일 전송만이 가능했지만(http/9.0) 현재는 이미지, JSON 등 다양한 형식의 파일을 전송할 수 있습니다.
• HTTP(애플리케이션 계층)는 TCP/IP 기반에서 동작합니다.
• 'HTTP'는 서버/클라이언트 모델로, 클라이언트와 서버 사이에 이뤄지는 요청(request)와 응답(response) 구조로 이루어져있습니다.
• 비연결(Connectionsless): 클라이언트가 요청을 서버에 보내고 서버가 적절한 응답을 클라이언트에 보내면 바로 연결이 끊깁니다.
  • 서버에서 다수의 클라이언트와 연결을 계속 유지하면 많은 리소스가 발생할 수 있습니다. 따라서 서버 연결 유지에 대한 리소스를 줄여 더 많은 연결이 가능하도록 합니다.
  • 매번 새로운 연결을 시도해야 하므로 이에 대한 오버헤드가 발생합니다.
• 무상태(Stateless): 연결을 끊는 순간 클라이언트와 서버의 통신은 끝나며, 상태 정보를 유지하지 않습니다.
  • 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입 할 수 있기 때문에 응답 서버를 쉽게 바꿀 수 있습니다. 따라서 서버의 확장성에는 용이하지만, 상태정보를 유지하지 않아 이전 클라이언트의 정보를 알 수 없고 추가 데이터를 전송해야 합니다.

장점

• 무상태 → 서버의 확장성에 용이합니다.
• 비연결 → 서버 연결 유지에 대한 리소스를 줄여 더 많은 연결이 가능하도록 합니다.
• 불특정 다수를 대상으로 한 서비스에 적합합니다.

단점

• 정보를 텍스트 기반의 평문으로 주고 받기 때문에 네트워크에서 정보를 탈취하거나 변조할 수 있는 보안적 위험이 있습니다.
• HTTP 는 누구이던 간에 리퀘스트를 보내면 리스폰스가 반환되는 매우 심플한 구조이기 때문에 통신 상대를 확인하지 않아 위장이 가능합니다.
  • 의미없는 요청도 수신하기 때문에 DOS공격을 당할 수 있습니다.
  • 통신하고 있는 상대방이 허가된 상대인지 확인할 수 없습니다.
• 완전성(정보의 정확성)을 증명할 수 없어 요청이나 응답을 상대방이 수신하기 전에 변조가 되어도 알 수 있는 방법이 없습니다.

HTTP1.0

• 한 연결당 하나의 요청을 처리하도록 설계되었습니다.
• 요청 및 응답에 대한 메타 데이터를 포함하는 헤더 필드를 제공합니다.
  • Content-Type이 존재하여 HTML이 아닌 다른 문서도 전송할 수 있습니다.
• 연결을 유지하지 않는 모델로, 트래픽이 많지 않고, 빠른 응답을 제공할 경우에 효율적입니다.
• TCP 세션을 유지하지 않습니다.
  • 각 모든 요청에 따라 새로운 연결을 열고, 응답이 전송된 후 즉시 닫기 때문에 웹브라우저로 사이트를 요청하면 수많은 자원들을 각각 다운로드 하기 위해 연결과 종료를 반복하는 비효율적인 방법을 사용합니다.
  • 통신을 할 때마다 매번 3 way handshaking을 거치기 때문에 RTT가 증가한다는 단점이 있습니다.

RTT 증가 해결 방안

• 이미지 스플리팅: 많은 이미지가 합쳐있는 하나의 이미지를 다운로드받고, position을 이용해 원하는 이미지만 사용
• 코드 압축: 코드를 압축해서 개행 문자, 빈칸을 없애서 코드의 크기를 최소화 하는 방법
• 이미지 Base64 인코딩: 이미지 파일을 64진법으로 이루어진 문자열로 인코딩하는 방법으로, 작성된 이미지와 같은 정보가 이미 문서에 포함되어 있기때문에, 서버에 HTTP 요청하지 않고도 이미지를 사용 가능합니다. 하지만 37%정도 크기가 더 커지는 단점이 있습니다.

HTTP 1.1

• 오늘날 가장 많이 사용하는 프로토콜 버전입니다.

주요 특징

• Persistent connection : 연결의 지속 시간을 설정합니다. 한개의 TCP 세션을 통해 여러 개의 컨텐츠 요청이 가능합니다.
  • Keep- Alive 속성: HTTP1.1부터 표준화되었습니다. 지정시간 동안 패킷을 전송하여 응답이 있는 지 확인합니다. 응답이 없으면 연결을 종료합니다.
  • connection request가 줄어들면서 네트워크 혼잡이 감소하고, 한 개의 connection으로 client요청을 처리하기 때문에 네트워크 비용이 감소합니다. 또한, 3 way handshake를 맺는데 필요한 RTT가 줄어들기 때문에 네트워크 지연 시간이 감소합니다.
    

• HTTP Pipelining : TCP 안에 두 개 이상의 HTTP 요청을 담아 요청을 병렬로 처리하는 파이프라이닝 기능을 지원합니다. 여러 개의 요청을 처리하는 응답 속도가 훨씬 빨라집니다.
  - 다음 요청까지의 지연 대기 시간을 없앰으로써, 네트워크 가동율을 높이고 성능을 향상시킵니다.
  - 요청을 한꺼번에 하지만 결국 순차적으로 응답 하기 때문에 HOL Blocking 문제가 발생합니다.
  

단점

• HOL Blocking(Head Of Line Blocking): 같은 큐에 있는 패킷이 첫번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상입니다.
• TCP 기반 HTTP 특성 상 3 way handshake가 반복적으로 일어나기 때문에 불필요한 RTT 증가와 네트워크 지연을 초래하여 성능을 저하시킵니다.
• 연속된 데이터의 경우, 중복된 Header(메타데이터, 쿠키)값을 전송하기 때문에 무거운 헤더구조를 가집니다.

SPDY

• Google은 Latency 관점에서 HTTP를 고속화한 SPDY라는 새로운 프로토콜을 구현했습니다.
• HTTP를 통한 전송을 재정의하는 방식으로 구현되어, 전송 계층의 구현만 변경하면 기존 HTTP 서버 프로그램을 그대로 SPDY에서 사용할 수 있습니다.
• HTTP/2.0의 초안에 SPDY 규격이 참고되었습니다.
• 헤더 압축을 통한 트래픽 절감, 자원 우선 순위를 지정해 우선 순위에 따른 웹 리소스 로딩 지원, 멀티플렉싱, 클라이언트의 요청이 없어도 서버에서 데이터 push 가능 등의 기능을 지원합니다.
• Google은 크롬6버전 부터 SPDY 프로토콜 지원 기능을 탑재 하였지만, HTTP/2 프로토콜의 이점이 크기 때문에 2016년 초 SPDY 기능을 제거하였습니다.

HTTP/2

• 2015년 IETF(국제 인터넷 표준화 기구) 표준으로 채택되어, 현재 대부분의 브라우저에서 지원합니다.

주요 특징

• HTTP Header Data Compression(HTTP 헤더 데이터 압축) : 이전 Header의 내용과 중복되는 필드를 재전송하지 않도록 하여 데이터를 절약합니다.

  • 기존의 평문이던 HTTP 헤더를 허프만 코딩을 사용한 HPACK이라는 헤더 압축 방식을 이용하여 데이터 전송 효율을 높입니다.

    ** 허프만 코딩: 데이터 문자의 빈도에 따라서 다른 길이의 부호를 사용하는 알고리즘

    

• Binary Framing Layer: HTTP 메시지가 텍스트 형식에서 Binary로 인코딩되어 프레임에 담겨 전송됩니
  • Frame: HTTP/2에서 통신의 최소 단위이며, Header 혹은 Data가 들어있습니다.
  • Message: 요청과 응답의 단위로, 다수의 Frame으로 이루어진 배열 라인입니다.
  • Stream: 연결된 Connection 내에서 양방향 Message를 주고 받는 하나의 흐름 입니다.

⇒ HTTP 요청을 여러 개의 Frame들로 나누고, 이 Frame 들이 모여 요청/응답 Message가 되고 Message가 특정 Stream에 속하게 되고, 여러 개의 Stream은 하나의 Connection에 속하는 구조 입니다.

• 멀티플렉싱 : 여러 개의 스트림을 동시에 생성하여 다수의 요청/응답 처리가 가능합니다.
  • Stream은 양방향 데이터 흐름이 가능하고, 각 Stream에는 고유 식별자와 우선순위 정보가 있습니다.
  • 특정 스트림의 패킷이 손실되어도 해당 스트림에만 영향을 미칩니다.
  • 하나의 TCP 커넥션에서 수행이 가능하여 handshake 비용을 절감합니다.

• 서버 푸시 : 클라이언트 요청 없이 서버가 함께 보내야 한다고 판단되면 자동으로 푸쉬하는 기능입니다.

단점

• TCP 레벨의 HOLB 문제
  • TCP는 패킷이 유실되거나 오류가 생기면 패킷을 재전송하고, 이러한 재전송 과정에서 패킷의 지연이 발생하면서 결국 HOLB 문제가 발생합니다.
  • 애플리케이션 레이어에서 해결했다고 하더라도 TCP 에서 해결하지 못했습니다.
• 서버 부하 증가 위험
  • 커넥션 하나에서 대규모 요청을 일괄 처리시 과도한 서버 부하가 발생할 위험이 있습니다.

HTTP/3

• UDP 기반의 프로토콜인 QUIC를 사용하여 통신하는 프로토콜 입니다.
• QUIC (Quick UDP Internet Connections): Google에서 개발한 인터넷 상에서 데이터를 빠르고 안전하게 전송하기 위한 프로토콜로, 주로 웹 브라우저와 서버 간의 통신을 최적화하기 위해 사용됩니다.

  • 빠른 연결 수립: 1-RTT 만에 연결 수립과 보안을 동시에 진행합니다.

    • TCP위에 TLS가 독립적으로 존재하여 TCP 연결 수립 후 보안에 대한 추가적인 작업을 해주는 것과 달리 TLS를 QUIC 안에 내장하고 있어 연결 수립을 위해 처음 보내는 요청부터 보안이 필요한 정보까지 함께 전송합니다.
    • 이전에 연결했던 정보를 캐싱해둠으로써 0-RTT에도 가능합니다.
    • TLS 1.3 보안프로토콜의 기능들을 통합함으로써 암호화의 작업을 애플리케이션 계층에서 전송 계층으로 내렸고, 연결 수립의 속도를 향상시켰습니다.

    

• 멀티 플렉싱 : 개별 파일을 구분하여 하나의 패킷 손실이 발생해도, 해당 파일의 스트림만 정지됩니다.

• 순방향 오류 수정 메커니즘: 전송한 패킷이 손실되었다면 에러를 검출하고 수정하는 방식으로 낮은 패킷 손실률을 보입니다.
• Connection ID : 연결을 식별할 때 Connection ID라는 랜덤값을 사용합니다. 와이파이가 바뀌거나 지하철에서 기지국이 달라져 네트워크가 끊여져도 연결이 유지됩니다. → 클라이언트 IP와 무관하기 때문에 Client ID가 바뀌어도 연결이 유지됩니다.
  • End Point에서 연결을 식별할 때 사용할 뿐, 네트워크 망에서 패킷을 송신할 때 Connection ID로 목적지를 찾는 것은 아닙니다.
• Google, Youtube, 네이버
  • stream id를 통해 패킷의 손실이 확인된 경우, 해당 패킷을 다시 요청하고 손실된 패킷을 받아오는 동안 다른 패킷은 보관합니다. 따라서 상관없는 패킷은 지연이 발생하지 않고, 손실된 패킷과 관련된 패킷에만 지연이 발생합니다.