[네트워크] HTTP

2024. 10. 24. 23:21·💻 CS/네트워크

HTTP 발전 과정 및 HTTPS

HTTP는 애플리케이션 계층으로서 웹 서비스 통신에 사용되며, HTTP/1.0부터 HTTP/3까지 발전을 거듭해 왔습니다.

1. HTTP/1.0

HTTP/1.0은 기본적으로 한 연결당 하나의 요청을 처리하도록 설계되어 있습니다. 한 연결당 하나의 요청을 처리하는 방식 때문에 RTT 증가를 유발합니다. 다시 말해, 서버로부터 파일을 가져올 때마다 TCP의 Three-Way Handshake를 계속해서 열어야 하므로 RTT가 증가하는 단점이 있습니다.

📢 RTT란? 패킷이 목적지에 도달한 후 다시 출발지로 돌아오기까지 걸리는 시간, 즉 패킷의 왕복 시간을 의미합니다.

1-1. RTT 증가 문제 해결 방법

매번 연결할 때마다 RTT가 증가하면서 서버에 부담이 많이 가고 사용자 응답 시간이 길어지는 문제를 해결하기 위해 이미지 스플리팅, 코드 압축, 이미지 Base64 인코딩을 사용합니다.

  • 이미지 스플리팅: 많은 이미지를 다운로드받게 되면 과부하가 발생할 수 있습니다. 이를 해결하기 위해 많은 이미지를 하나의 이미지로 합쳐 다운로드받고, background-image의 position 속성을 이용해 이미지를 표기하는 방법입니다.
  • 코드 압축: 코드를 압축해 개행 문자와 빈칸을 제거하여 코드의 크기를 최소화하는 방법입니다.
  • 이미지 Base64 인코딩: 이미지 파일을 64진법 문자열로 인코딩하는 방법으로, 서버와의 연결을 열고 HTTP 요청을 할 필요가 없다는 장점이 있지만, Base64 문자열로 변환하면 37% 정도 크기가 커지는 단점이 있습니다.

📢 인코딩이란? 정보의 형태나 형식을 표준화, 보안, 처리 속도 향상, 저장 공간 절약 등을 위해 다른 형태나 형식으로 변환하는 처리 방식입니다.

2. HTTP/1.1

HTTP/1.1은 HTTP/1.0에서 발전된 버전입니다. 매번 TCP 연결을 하는 대신 한 번 TCP 초기화 후 keep-alive 옵션으로 여러 파일을 송신할 수 있게 바뀌었습니다. HTTP/1.0에서도 keep-alive가 있었으나 표준화되지 않았으며, HTTP/1.1부터는 표준화되어 기본 옵션으로 설정되었습니다.

한 번 TCP Three-Way Handshake가 발생하면 그 이후로는 발생하지 않지만, 다수의 리소스(이미지, 동영상, CSS 파일 등)를 처리할 때 요청할 리소스 개수에 비례해 대기 시간이 길어지는 단점이 있습니다.

성능 저하 문제로 HOL Blocking과 무거운 헤더 구조가 있습니다.

 

2-1. HOL Blocking

HOL Blocking (Head Of Line Blocking)은 네트워크에서 같은 큐에 있는 패킷이 첫 번째 패킷 때문에 지연될 때 발생하는 성능 저하 현상입니다. 첫 번째 파일이 느리게 받아지면 그 뒤의 파일들이 대기하게 되어 다운로드가 지연되는 상태를 의미합니다.

2-2. 무거운 헤더 구조

HTTP/1.1의 헤더에는 쿠키 등 많은 메타데이터가 포함되어 있으며, 압축되지 않아 무겁다는 단점이 있습니다.

3. HTTP/2

HTTP/2는 SPDY 프로토콜에서 파생되었으며, HTTP/1.x보다 지연 시간을 줄이고 응답 시간을 더 빠르게 합니다. 멀티플렉싱, 헤더 압축, 서버 푸시, 요청의 우선순위 처리를 지원하는 프로토콜입니다.

3-1. 멀티플렉싱

멀티플렉싱은 여러 개의 스트림을 사용해 데이터를 송수신하는 방법입니다. 특정 스트림의 패킷이 손실되더라도 해당 스트림에서만 영향을 미치고, 나머지 스트림은 정상적으로 동작할 수 있습니다.

📢 스트림이란? 시간이 지남에 따라 사용할 수 있게 되는 일련의 데이터 요소를 의미하는 데이터 흐름입니다.

3-2. 헤더 압축

HTTP/2는 허프만 코딩 압축 알고리즘을 사용해 헤더의 크기를 줄입니다. HPACK 압축 형식을 사용합니다.

📢 허프만 코딩이란? 문자열을 문자 단위로 쪼개 빈도수를 세어, 빈도가 높은 정보는 적은 비트 수로, 빈도가 낮은 정보는 많은 비트 수로 표현하여 전체 데이터의 표현에 필요한 비트양을 줄이는 원리입니다.

3-3. 서버 푸시

HTTP/2는 서버 푸시 기능을 통해 클라이언트의 요청 없이도 서버가 리소스를 푸시할 수 있습니다. 예를 들어, HTML 요청 시 HTML 파일뿐만 아니라 CSS 파일도 서버에서 푸시하여 클라이언트에 먼저 전송할 수 있습니다.

4. HTTPS

HTTPS/2는 HTTPS 위에서 동작합니다. HTTPS는 애플리케이션 계층과 전송 계층 사이에 신뢰 계층인 SSL/TLS 계층을 추가해 신뢰할 수 있는 HTTP 요청을 가능하게 합니다.

"통신을 암호화합니다."

4-1. SSL/TLS

SSL/TLS는 클라이언트와 서버 간 통신에서 제3자가 메시지를 도청하거나 변조하지 못하도록 보안을 제공하는 전송 계층 프로토콜입니다. SSL (Secure Socket Layer)은 SSL 1.0부터 시작해 TLS로 명칭이 변경되었으며, SSL/TLS로 합쳐 부릅니다.

SSL/TLS를 통해 공격자가 서버인 척 하여 사용자 정보를 가로채는 네트워크상의 인터셉터를 방지할 수 있습니다. 보안 세션이 만들어질 때 인증 매커니즘, 키 교환 암호화 알고리즘, 해싱 알고리즘 등이 사용됩니다.

  • 보안 세션: 보안이 시작되고 끝나는 동안 유지되는 세션으로, SSL/TLS 핸드셰이크를 통해 생성되며 이를 기반으로 상태 정보 등을 공유합니다.

📢 세션이란? 운영체제가 특정 사용자로부터 자산 이용을 허락하는 일정한 기간을 의미합니다. 즉, 사용자는 일정 시간 동안 응용 프로그램 등을 사용할 수 있습니다.

 

클라이언트는 사이퍼 슈트 (Cypher Suites)를 서버에 전달하고, 서버는 해당 사이퍼 슈트의 암호화 알고리즘 리스트를 확인해 제공 가능한지 여부를 결정합니다. 제공 가능하면 서버는 클라이언트에 인증서를 보내며, 이후 해싱 알고리즘 등을 통해 암호화된 데이터 송수신이 시작됩니다.

  • 사이퍼 슈트 (Cypher Suites): 프로토콜, AEAD 사이퍼 모드, 해싱 알고리즘 등이 나열된 규약입니다.
    • AEAD 사이퍼 모드 (Authenticated Encryption with Associated Data): 데이터 암호화 알고리즘입니다.

인증 매커니즘

CA (Certificate Authorities)에서 발급한 인증서를 기반으로 이루어지는 매커니즘입니다. CA에서 발급한 인증서는 안전한 연결을 시작하기 위한 공개키를 클라이언트에 제공하며, 서버가 신뢰할 수 있는 서버임을 보장합니다. 인증서는 서비스 정보, 공개키, 지문, 디지털 서명 등으로 구성됩니다.

  • CA는 신뢰성이 공인된 기업들만 참여할 수 있으며, 대표적으로 Comodo, GoDaddy, GlobalSign, 아마존 등이 있습니다.
CA 발급 과정

CA 인증서를 발급받기 위해서는 사이트 정보와 공개키를 CA에 제출해야 합니다. 이후 CA는 공개키를 해시한 값인 지문 (fingerprint)과 CA 비밀키 등을 사용해 CA 인증서를 발급합니다.

암호화 알고리즘

키 교환 암호화 알고리즘으로는 대수곡선 기반의 ECDHE 또는 모듈식 기반의 DHE를 사용하며, 둘 다 디피-헬만 방식을 기반으로 합니다.

  • 디피-헬만 키 교환 암호화 알고리즘: 암호키를 교환하는 하나의 방법입니다.

해싱 알고리즘

해싱 알고리즘은 데이터를 추정하기 힘든 더 작고 섞여 있는 조각으로 만드는 알고리즘입니다. SHA-256과 SHA-284 등의 알고리즘이 있습니다.

  • SHA-256: 해시 함수의 결괏값이 256비트인 알고리즘입니다. 해싱할 메시지에 1을 추가하는 등 전처리를 하고, 이를 기반으로 해시를 반환합니다.

📢 해시, 해싱, 해시 함수란? 🤔

  • 해시: 다양한 길이의 데이터를 고정된 길이로 매핑한 값입니다.
  • 해싱: 임의의 데이터를 해시로 바꾸는 작업입니다.
  • 해시 함수: 임의의 데이터를 입력받아 일정한 길이의 데이터로 바꿔주는 함수입니다.

4-2. SEO와 HTTPS

구글은 SSL 인증서를 강조해 왔으며, 모든 요소가 동일하다면 HTTPS 서비스를 사용하는 사이트가 그렇지 않은 사이트보다 SEO 순위가 높다고 공식 발표했습니다.

 

SEO (Search Engine Optimization)는 검색 엔진 최적화를 의미하며, 사용자가 검색 엔진을 통해 웹사이트를 검색했을 때 해당 사이트가 상단에 노출되도록 최적화하는 방법입니다. SEO 관리 방법으로는 캐노니컬 설정, 메타 설정, 페이지 속도 개선, 사이트맵 관리 등이 있습니다.

4-3. HTTPS 구축 방법

HTTPS를 구축하는 방법에는 크게 두 가지가 있습니다:

  1. 직접 CA에서 구매한 인증서를 기반으로 HTTPS 서비스를 구축합니다.
  2. 서버 앞단에 HTTPS를 제공하는 로드 밸런서나 CDN을 두어 구축합니다.

5. HTTP/3

HTTP/3은 World Wide Web에서 정보를 교환하는 HTTP의 세 번째 버전으로, HTTP/1.1 및 HTTP/2와 함께 사용됩니다. HTTP/3은 TCP 대신 UDP 기반인 QUIC 위에서 동작합니다.

HTTP/2의 장점이었던 멀티플렉싱을 포함하고 있으며, 초기 연결 설정 시 지연 시간이 줄어드는 장점이 있습니다.

초기 연결 설정 시 지연 시간 감소

QUIC은 TCP를 사용하지 않기 때문에 통신을 시작할 때 번거로운 Three-Way Handshake 과정을 거치지 않습니다. 첫 연결 설정에 1-RTT만 소요되며, 클라이언트가 서버에 신호를 보내고 서버가 응답하면 바로 본 통신을 시작할 수 있습니다.

QUIC은 순방향 오류 수정 매커니즘 (FEC, Forward Error Correction)이 적용되어, 전송한 패킷이 손실되었을 경우 수신 측에서 에러를 검출하고 수정할 수 있습니다. 이를 통해 열악한 네트워크 환경에서도 낮은 패킷 손실률을 유지할 수 있습니다.

'💻 CS > 네트워크' 카테고리의 다른 글

[네트워크] IP 주소  (0) 2024.10.24
[네트워크] 네트워크 기기  (1) 2024.10.24
[네트워크] TCP/IP 4계층 모델  (0) 2024.10.22
[네트워크] 네트워크의 기초  (3) 2024.10.22
'💻 CS/네트워크' 카테고리의 다른 글
  • [네트워크] IP 주소
  • [네트워크] 네트워크 기기
  • [네트워크] TCP/IP 4계층 모델
  • [네트워크] 네트워크의 기초
kkongdo
kkongdo
kkongdo 님의 블로그 입니다.
  • kkongdo
    숲을 바라보며 나무를 심는 아이
    kkongdo
  • 전체
    오늘
    어제
    • 분류 전체보기 (32)
      • 🌏 Web (0)
      • ☕ Java (5)
      • 🌱 Spring (9)
        • Spring Boot (7)
        • Spring Data JPA & QueryDSL (2)
      • 🗂️ Database (5)
      • 💻 CS (12)
        • 운영체제 (4)
        • 네트워크 (5)
        • 자료구조 (3)
      • 🗃️Git (1)
      • 🔍 Algorithm (0)
      • 📡 DevOps (0)
        • Docker (0)
      • 🔭 ETC (0)
  • 블로그 메뉴

    • 홈
    • 태그
    • 방명록
    • GitHub
  • 링크

  • 공지사항

  • 인기 글

  • 태그

    자료구조
    QueryDSL
    db
    spring
    네트워크기기
    @annotation
    스케줄링
    java
    DI
    JPA
    SpringMVC
    OS
    CS
    SpringSecurity
    복잡도
    springbatch
    데이터베이스
    네트워크
    운영체제
    조인
  • 최근 댓글

  • 최근 글

  • hELLO· Designed By정상우.v4.10.0
kkongdo
[네트워크] HTTP
상단으로

티스토리툴바