[컴퓨터 네트워크] HTTP

이번에는 HTTP가 어떻게 발전해왔는지, 버전 1.0부터 3.0까지의 내용을 정리해보도록 하겠습니다.

HTTP/1.0

• 한 연결 당 하나의 요청을 처리함
  
• ⇒RTT가 증가하는 문제점이 있다.
  • RTT: 패킷이 목적지에 도착하고 다시 출발지로 돌아오기까지 걸리는 시간=패킷의 왕복 시간
• ⇒ 서버에 부담, 사용자의 응답 시간이 증가
• 해결방법
  1. 이미지 스플리팅: 여러 이미지를 한 이미지로 합쳐 다운받게 함
  2. 코드 압축: 줄바꿈, 공백 등을 다 빼서 코드의 크기를 최소화시킴
  3. 이미지 base64 인코딩
     • 이미지를 64진법으로 이루어진 문자열로 인코딩해서 전송
     • 장점: 이미지에 대한 HTTP 요청을 서버에 따로 할 필요가 없다.
     • 단점: 37%정도 크기가 커짐

HTTP/1.1

• HTTP/1.0과 비교해 달라진 점: keep-alive!
• keep-alive: 한번 요청할 때마다 handshake와 연결 종료를 반복했는데, 이것을 한번 요청하면 계속 연결을 유지하도록 함 ⇒ 대신, 요청할 리소스 개수에 비례해 대기 시간이 길어지는 단점이 있음
  
• HOL Blocking(Head Of Line)
  • 네트워크에서 같은 큐 안의 패킷이 그 첫번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상
  • ex) 파일을 img→css→xml, 이 순서로 요청하고 순차적으로 받아야 할 때, img가 다운 받는 속도가 느릴 경우, 뒤의 css, xml도 지연된다.
• 무거운 헤더 구조: 헤더에는 메타 데이터가 압축 되지 않고, 많은 정보가 들어갔기 때문에 무거웠다.

HTTP/2

• SPDY 프로토콜에서 파생된 HTTP/1.x보다 지연시간, 응답시간이 덜 걸린다.

• 특징

  1. 멀티플렉싱

     • 여러 개의 스트림을 사용해 송수신함.
       • 스트림: 시간이 지남에 따라 사용할 수 있게 되는 일련의 데이터 요소의 데이터 흐름
         
     • 특정 스트림의 패킷이 손실되었다고 하더라도 다른 스트림과는 독립적이기 때문에 문제가 없다.
     • 한 스트림 내에 데이터들도 쪼개져 있다.(ex. img, css, js파일이 있음)
       
     • HTTP/1.x이라면 3번 요청/응답이 되어야 함, but HTTP/2.0은 1번이면 된다.
     • ⇒ 데이터를 병렬적으로 요청/응답 받을 수 있기 때문에 HTTP/1.1의 HOL Blocking을 해결

  2. 헤더압축

     • http/1.1에서 헤더가 무거운 것을 해결⇒허프만 코딩 압축 알고리즘
     • 허프만 코딩 압축 알고리즘
       • 문자열을 문자 단위로 쪼개 빈도 수를 계산한 후, 빈도 수가 낮은 정보는 비트 수를 많게, 빈도 수가 높은 정보는 비트 수를 적게 설정해 전송

  3. 서버 푸시
     

     • 클라이언트가 요청하지 않아도 서버가 리소스를 전달해줄 수 있다.
     • ex) html 파일만 서버에 요청→서버가 html, css, xml 파일을 다 보내줄 수 있음

  4. 요청의 우선순위 처리

HTTPS

• HTTP/2는 HTTPS 위에서 동작한다. HTTPS는 애플리케이션 계층과 전송 계층 사이에 신뢰 계층인 SSL/TLS 계층을 넣은 신뢰할 수 있는 HTTP 요청을 말한다. 이를 통해 ‘통신을 암호화’한다.

• SSL/TLS

  • 전송 계층에서 보안을 제공하는 프로토콜

  • SSL 1.0→2.0→ 3.0→TLS 1.0→1.3

  • 클라이언트와 서버가 통신할 때 SSL/TLS를 통해 제3자가 메세지를 도청하거나 변조하지 못하도록 한다.

  • SSL/TLS를 통해 공격자가 서버인 척하며 사용자 정보를 가로채는 네트워크 상의 ‘인터셉터’를 방지할 수 있다.

  • SSL/TLS는 보안 세션을 기반으로 데이터를 암호화하며 보안 세션이 만들어질 때 인증 메커니즘, 키 교환 암호화 알고리즘, 해싱 알고리즘이 사용된다.

    • 보안 세션
      

      • 보안이 시작되고 끝나는 동안 유지되는 세션, SSL/TLS는 핸드셰이크를 통해 보안 세션을 생성하고 이를 기반으로 상태 정보 등을 공유한다.
      • 클라이언트와 서버가 키를 공유하고 이를 기반으로 인증, 인증 확인 등의 작업이 일어나는 단 1번의 RTT가 발생하고, 그 다음부터는 데이터를 송수신한다.
      • 클라이언트에서 사이퍼 슈트를 서버에 전달하면 서버는 받은 사이퍼 슈트의 암호화 알고리즘 리스트를 제공할 수 있는지 확인한다.
      • 제공할 수 있다면 서버에서 클라이언트로 인증서를 보내는 인증 메커니즘이 시작되고 이후 해싱 알고리즘 등으로 암호화된 데이터의 송수신이 시작된다.
      • 사이퍼 슈트
        • 프로토콜, AEAD 사이퍼 모드, 해싱 알고리즘이 나열된 규약을 말하며, 5개가 있다.
        • 종류
          • TLS_AES_128_GCM_SHA256
          • TLS_AES_256_GCM_SHA384
          • TLS_CHACHA20_POLY1305_SHA256
          • TLS_AES_128_CCM_SHA256
          • TLS_AES_128_CCM_8_SHA256
        • AEAD 사이퍼 모드
          • AEAD(Authenticated Encryption with Associated Data)는 데이터 암호화 알고리즘이며 AES_128_GCM 등이 있다.
          • 예를 들어 AES_128_GCM은 128비트의 키를 사용하는 표준 블록 암호화 기술과 병렬 계산에 용이한 암호화 알고리즘 GCM이 결합된 알고리즘을 뜻한다.

    • 인증 메커니즘

      • CA(Certificate Authorities)에서 발급한 인증서를 기반으로 이루어진다.
      • 인증서는 안전한 연결을 시작하는데 있어, 클라이언트에게 공개키 제공과 접속한 서버가 신뢰할 수 있다는 것을 보장한다.
      • 인증서는 서비스 정보, 공개키, 지문, 디지털 서명 등으로 이루어져 있다.
      • 만약에 자신의 서비스가 인증을 받고 싶다면, CA에 자신의 사이트 정보와 공개키를 제출해야 한다.
      • 이후 CA는 공개키를 해시한 값인 지문(finger print)를 사용하는 CA의 비밀키 등을 기반으로 CA 인증서를 발급한다.
        • 개인키: 비밀키라고도 하며, 개인이 소유하고 있는 키이자 반드시 자신만이 소유해야 하는 키
        • 공개키: 공개되어 있는 키

    • 키 교환 암호화 알고리즘

      • 대수곡선 기반의 ECDHE 또는 모듈식 기반의 DHE를 사용한다. 둘다 디피-헬만 방식을 근간으로 만들어졌다.
        
      • 디피-헬만 키 교환 암호화 알고리즘
        • y=g^x mod p
        • g와 x, p를 안다면 y를 구하기 쉽지만, g,y,p를 알면 x를 구하기는 어렵다는 원리에 기반한 알고리즘
        • 처음에 공개 값을 공유하고 각자의 비밀 값과 혼합한 후 혼합 값(PSK: pre shared key)을 공유한다.
        • 결국 공개키, 개인키를 알게 되어도 psk를 모르면 알 수 없다

    • 해싱 알고리즘

      • 데이터를 추정하기 힘든 더 작고, 섞여 있는 조각으로 만드는 알고리즘
      • SSL/TLS는 해싱 알고리즘으로 SHA-256, SHA-384를 쓴다.
      • SHA-256
        • 해시 함수의 결과 값이 256 비트인 알고리즘이며 비트 코인을 비롯한 많은 블록체인 시스템에서도 쓰인다.
        • 해싱을 해야할 메세지에 1을 추가하는 등 전처리를 하고 전처리된 메세지를 기반으로 해시를 반환한다.

• HTTPS 서비스가 그렇지 않은 사이트보다 SEO 순위가 높다.

  • SEO(Search Engine Optimization): 검색엔진 최적화, 웹 사이트를 검색했을 때 그 결과를 페이지 상단에 노출시켜 많은 사람들이 볼 수 있도록 최적화하는 방법

• HTTPS 구축 방법

  • CA에서 구매한 인증키 기반으로 HTTPS 서비스 구축
  • 서버 앞단의 HTTPS를 제공하는 로드밸런서 두기
  • 서버 앞단에 HTTPS를 제공하는 CDN 두기

HTTP/3

• TCP 위에서 돌아가는 HTTP/2와는 달리 HTTP/3은 QUIC라는 계층 위에서 돌아가며, TCP 기반이 아닌 UDP 기반으로 돌아간다.
  
  
• 또한, HTTP/2의 멀티플렉싱을 가지고 있으며 초기 연결 설정 시 지연 시간 감소라는 장점이 있다.
• 초기 연결 설정 지연 시간 감소
  • QUIC는 TCP를 사용하지 않기 때문에 통신을 시작할 때 번거로운 3way handshake 과정을 거치지 않아도 된다.
    
  • QUIC는 첫 연결 설정에 1-RTT만 소요된다.
  • 클라이언트가 서버에 어떤 신호를 한 번 주고, 서버도 거기에 응답하기만 하면 바로 본 통신을 시작할 수 있다.
  • QUIC는 순방향 오류 수정 메커니즘(FEC, Fowraord Error Correction)이 적용되어, 전송한 패킷이 손실되었다면 수신 측에서 에러를 검출하고 수정한다. 열악한 네트워크 환경에서도 낮은 패킷 손실률을 자랑한다.