[네트워크] HTTP

Lil_Young·2025년 9월 19일
네트워크면접을위한cs전공지식노트

면접을 위한 CS 전공지식 노트

목록 보기
1/1
post-thumbnail

HTTP

  • 웹에서 클라이언트와 서버가 데이터를 주고받을 때 사용하는 프로토콜
    • 클라이언트 - 서버 구조
  • 최상단 계층인 응용(애플리케이션) 계층에서 사용
    • 물-데-네-전-세-표-응
  • HTTP는 HTTP/1.0부터 HTTP/3.0까지 있음
  • 텍스트 기반 프로토콜(요청과 응답 모두 사람이 읽을 수 있는 텍스트 형식으로 주고받음)
  • 비연결성으로 요청과 응답이 끝나면 연결 상태를 유지하지 않음
    • Stateless
  • 웹 브라우저에서 페이지, 이미지, 동영상 같은 리소스를 가져오기 위한 규약

요약하면 웹에서 클라이언트와 서버가 어떻게 대화할지 정해놓은 약속이라고 생각하면 된다.

HTTP/1.0

HTTP/1.0은 기본적으로 한 연결당 하나의 요청을 처리하도록 설계되었다. 즉, 요청마다 TCP 연결을 해줘야 한다.
이는 RTT 증가를 불러오게 되었다.

RTT란?
패킷이 목적지에 도달하고 나서 다시 출발지로 돌아오기까지 걸리는 시간이다.

즉, 패킷 왕복 시간이다.

위 그림을 보면 RTT에 대해 확실하게 이해가 된다.

RTT의 증가를 해결하기 위한 방법

매번 연결할 때마다 RTT가 증가하므로 서버 부담이 많이 가고 응답 시간이 길어지는 문제점이 있다. 이를 해결 하기 위해 아래와 같은 방법을 사용했다.

  1. 이미지 스플리팅

    C 이미지는 A와 B 이미지를 하나로 합쳐 놓은 큰 이미지 파일이라고 가정한다.
    그러면 C 이미지 하나로 특정 영역만 잘라서 A 이미지, B 이미지 둘 다 보여줄 수 있다.

    .icon {
  width: 10px;
  height: 10px;
  background-image: url("C.png");
}

.icon-a {
  background-position: 0px 0px;   /* A 이미지 부분 */
}

.icon-b {
  background-position: -10px 0px; /* B 이미지 부분 */
}

  2. 코드 압축
    코드 압축은 코드를 압축해서 개행 문자, 빈칸을 없애서 코드의 크기를 최소화하는 방법이다.

    String a = 10;
String b = 20;
System.out.println(a + b);

    코드 압축 후

    String a = "10", b = "20";
System.out.println(a + b);

  3. 이미지 Base64 인코딩

    .icon {
  background-image: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA...");
}

    여러 개의 작은 이미지를 각각 요청하는 대신, HTML이나 CSS 안에 Base64 문자열로 인코딩해서 삽입할 수 있다. 이렇게 하면 별도의 네트워크 요청이 줄어들어 RTT 감소 효과가 생긴다. 하지만 Base64 문자열로 변환할 경우 코드가 37% 정도 용량이 커지는 단점(Base64 인코딩 특성)이 있다.

HTTP/1.1

HTTP/1.0에서 발전한 것이 HTTP/1.1이다.

매번 TCP 연결을 하는 것이 아니라 한 번 TCP 초기화를 한 이후에 keep-alive라는 옵션으로 여러 개의 파일을 송수신할 수 있게 바뀌었다.

  • HTTP/1.0에서도 keep-alive가 있었지만 표준화가 되어있지 않았고, HTTP/1.1부터 표준화 되어 기본 옵션으로 설정되었다.

    위 그림을 보면 한 번 TCP 3-웨이-핸드셰이크가 발생하면 그 다음부터 발생하지 않는 것을 볼 수 있다.
    하지만 문서 안에 포함된 다수의 리소스를 처리하려면 요청할 리소스 개수에 비례해서 대기 시간이 길어지는 단점이 있다.

다음은 HTTP/1.1의 특징이다.

1. HOL Blocking

HOL Blocking(Head Of Line Blocking)은 네트워크에서 같은 큐에 있는 패킷이 그 첫 번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상을 말한다.

예를 들어 앞의 그림처럼 image.jpg와 styles.css, data.xml을 다운로드 받을 때 보통은 순차적으로 잘 받아지지만 image.jpg가 느리게 받아진다면 그 뒤에 있는 것들이 대기하게 되며 다운로드가 지연되는 상태가 된다.

2. 무거운 헤더 구조

HTTP/1.1의 헤더에는 쿠키 등 많은 메타데이터가 들어 있고 압축이 되지 않아 무거웠다.

HTTP/2.0

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

1. 멀티플렉싱

멀티플렉싱이란 여러 개의 스트림을 사용하여 송수신한다는 것이다.

이를 통해 특정 스트림의 패킷이 손실되었다고 하더라도 해당 스트림에만 영향을 미치고 나머지 스트림은 정상적으로 동작할 수 있다.

스트림이란?
시간이 지남에 따라 사용할 수 있게 되는 일련의 데이터 요소를 가리키는 데이터 흐름

앞의 그림은 하나의 연결 내 여러 스트림을 캡쳐한 모습이다. 병렬적인 스트림들을 통해 데이터를 서빙하고 있다. 또한, 스트림 내의 데이터들도 쪼개져 있다. 애플리케이션에서 받아온 메시지를 독립된 프레임으로 조각내어 서로 송수신한 이후 다시 조립하며 데이터를 주고받는다.

이를 통해 단일 연결을 사용하여 병렬로 여러 요청을 받을 수 있고 응답을 줄 수 있다. 이렇게 되면 HTTP/1.x에서 발생하는 문제인 HOL Blocking을 해결할 수 있다.

2. 헤더 압축

HTJTP/1.x에는 크기가 큰 헤더라는 문제가 있었다.
이를 HTTP/2.0에서는 헤더 압축을 써서 해결하는데, 허프만 코딩 압축 알고리즘을 사용하는 HPACK 압축 형식을 가진다.

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

3. 서버 푸시

HTTP/1.1에서는 클라이언트가 서버에 요청을 해야 파일을 다운로드 받을 수 있었다면,
HTTP/2.0은 클라이언트 요청 없이 서버가 바로 리소스를 푸시할 수 있다.

html에는 css나 js 파일이 포함되기 마련인데 html을 읽으면서 그 안에 들어 있던 css 파일을 서버에서 푸시하여 클라이언트에 먼저 줄 수 있다.

장점으로는 RTT를 줄일 수 있어 페이지 로딩 속도가 빠른 대신에, 불필요한 리소스일 경우 대역폭 낭비다.

HTTPS

HTTP/2.0은 HTTPS 위에서 동작한다.

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

  • OSI 7 계층에서는 전송 계층과 응용(애플리케이션) 계층 사이에 보안 계층은 존재하지 않고, 데이터 인코딩, 암호화, 압축 등을 담당하는 표현 계층이 있는데 개념적으로 보면 SSL/TLS는 표현 계층에 있다고 보면 된다.
  • 실제 인터넷에선 네트워크 액세스 계층 - 인터넷 계층(IP) - 전송 계층(TCP/UDP) - 애플리케이션 계층(HTTP 등) 이 있는데, 여기서는 전송 계층 위, 애플리케이션 계층 아래에 별도로 보안 계층이 있다고 설명한다.
  • 즉, 이론적(OSI 모델)에서 SSL/TLS는 표현 계층에 해당, 실제 구현에서는 전송 계층과 애플리케이션 사이에 낀 별도의 보안 계층으로 취급한다.

SSL/TLS

SSL(Secure Socket Layer)은 SSL 1.0, SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.3까지 버전이 올라가며 마지막으로 TLS로 명칭이 변경되었으나, 보통 이를 합쳐 SSL/TLS로 많이 부른다.

SSL/TLS은 전송 계층에서 보안을 제공하는 프로토콜이다. 클라이언트와 서버가 통신할 때 SSL/TLS를 통해 제 3자가 메시지를 도청하거나 변조하지 못하도록 한다.

  • 여기서 전송 계층이라 표현한 이유는 전송 계층 바로 위에 별도의 보안 계층에서 제공하므로 실제로 있는 계층인 전송 계층이라 표현함.

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

SSL/TLS는 보안 세션을 기반으로 데이터를 암호화하며 보안 세션이 만들어질 때

  1. 인증 메커니즘 → 서버 인증서 확인 (CA 서명 검증, 필요 시 클라이언트 인증서도 포함)
  2. 키 교환 암호화 알고리즘 → 세션 키를 안전하게 교환(RSA, ECDHE), 세션 내 데이터 암호화(AES, Chacha20)
  3. 해싱 알고리즘 → 무결성 검증 및 메시지 인증 (SHA-256)

이 사용된다. 이 조합이 바로 사이퍼 슈트다.

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

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

예를 들어 TLS_AES_128_GCM_SHA256에서 TLS는 프로토콜, AES_128_GCM은 AEAD 사이퍼 모드, SHA256은 해싱 알고리즘을 뜻한다.

AEAD 사이퍼 모드
데이터 암호화 알고리즘이며 AES_128_GCM, CHACHA20_POLY1305 등이 있다.
AES_128_GCM의 뜻
1. AES 대칭키 암호화 알고리즘을 사용
2. 128 비트의 키를 사용하는 표준 블록 암호화 기술
3. 병렬 계산에 용이한 암호화 알고리즘 GCM
이 결합된 알고리즘을 뜻한다.

인증 메커니즘

인증 메커니즘은 CA(Certificate Authorities)에서 발급한 인증서를 기반으로 이루어진다.

CA에서 발급한 인증서는 안전한 연결을 시작하는 데 있어 필요한 공개키를 클라이언트에 제공하고, 사용자가 접속한 서버가 신뢰할 수 있는 서버임을 보장한다.

인증서는 서비스 정보, 공개키, 지문, 디지털 서명 등으로 이루어진다.

CA는 아무 기업이나 할 수 없고 신뢰성이 보장된 공인된 기업들만 참여할 수 있으며 대표적으로 Comodo, GoDaddy, GlobalSign, 아마존 등이 있다.

CA 발급 과정
자신의 서비스가 CA 인증서를 발급 받으려면

1. 사이트 운영자가 자신의 공개키와 사이트 정보(도메인명, 조직명 등)를 포함한 CSR을 만든다.
    - 여기서 공개키는 ‘내 서비스와 통신할 때 이 키를 써달라’는 의미
2. CSR 제출 (운영자 → CA)
3. CA 검증 (도메인 소유 확인)
    - CA는 제출된 사이트가 실제로 신청자 소유인지 확인한다.
        - DNS 레코드 검증, 이메일 확인 등등
4. 인증서 데이터 구성 (CA)
    - CA는 신청자의 공개키 + 사이트 정보를 모아 인증서 데이터 구조를 만든다.
5. 인증서 해시 생성 (CA)
    - 이 데이터 전체를 해싱하여 지문을 생성한다.
        - 여기서 말하는 지문은 인증서 전체 내용을 요약한 값이다.
6. 전자서명 생성 (CA)
    - 생성된 지문을 CA의 비밀키로 암호화 → 전자서명 생성
    - 이 전자서명을 인증서에 포함시킨다.
7. 인증서 발급 (CA → 운영자)
    - CA의 전자서명이 붙은 인증서를 운영자에게 전달
8. 배포 (운영자)
    - 받은 인증서를 서버에 설치한다.
    - 이후 클라이언트는 HTTPS 연결 시 이 인증서를 받아보고, 내장된 CA 공개키를 이용해 서명을 검증한다.

암호화 알고리즘

키 교환 암호화 알고리즘으로는

  1. 대수곡선 기반의 ECDHE
  2. 모듈식 기반의 DHE

를 사용한다. 둘 다 디피-헬만 방식을 근간으로 만들어졌다.

디피-헬만 키 교환 암호화 알고리즘

암호키를 교환하는 하나의 방법

g, x, p를 알면 y는 구하기 쉽지만, g와 y와 p만 안다면 x를 구하기는 어렵다는 원리에 기반한 알고리즘

아래의 예시를 보면 쉽게 이해가 간다.

p = 23, g =5

A의 비밀 a = 6, B의 비밀 b = 15

A = 5^6 mod 23 = 8

B = 5^15 mod 23 = 19

교환 후

A가 계산: B^a mod 23 = 19^6 mod 23 = 2

B가 계산: A^b mod 23 = 8^15 mod 23 = 2

공격자는 공개 값 A = g^a 와 B = g^b를 볼 수 있지만, a 또는 b를 알아내려면 이산로그 문제를 풀어야 한다. 큰 소수 p와 충분히 큰 a, b를 쓰면 이 문제는 계산상 불가능하므로 공격자가 g^ab를 직접 계산할 수 없다.

해싱 알고리즘

해싱 알고리즘은 데이터를 추정하기 힘든 더 작고, 섞여있는 조각으로 만드는 알고리즘이다.
SSL/TLS는 해싱 알고리즘으로 SHA-256, SHA-384 알고리즘을 쓰며 SHA-256 알고리즘을 많이 쓴다.

SHA-256 알고리즘
해시 함수의 결과값이 256비트인 알고리즘이며 단방향이다. 비트코인을 비롯한 많은 블록체인 시스템에서도 쓰여진다.
SHA-256 알고리즘은 해싱을 해야 할 메시지에 1을 추가하는 등 전처리를 하고 전처리된 메시지를 기반으로 해시를 반환한다.

SEO에도 도움이 되는 HTTPS

SEO(Search Engine Optimization)는 검색엔진 최적화를 뜻하며 사용자들이 구글, 네이버 같은 검색엔진으로 웹 사이트를 검색했을 때 그 결과를 페이지 상단에 노출시켜 많은 사람이 볼 수 있도록 최적화하는 방법을 의미한다.

이를 위한 방법으로는

  1. 캐노니컬 설정
  2. 메타 설정
  3. 페이지 속도 개선
  4. 사이트맵 관리
  5. 모바일 최적화

등이 있다.

HTTPS 구축 방법

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

HTTP/3.0

HTTP/3.0은 HTTP/1.1 및 HTTP/2.0 과 함께 World Wide Web에서 정보를 교환하는 데 사용되는 세 번째 버전이다.

TCP 위에서 돌아가는 HTTP/2.0 과는 달리 HTTP/3.0 은 QUIC 이라는 계층 위에서 돌아가며, TCP 기반이 아닌 UDP 기반으로 돌아간다.

또한, HTTP/2.0의 장점인 멀티플렉싱을 가지고 있으며 초기 연결 설정 시 지연 시간 감소라는 장점이 있다.

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

QUIC는 TCP를 사용하지 않기 때문에 통신을 시작할 때 번거로운 3-웨이-핸드셰이크 과정을 거치지 않아도 된다.

QUIC는 첫 연결 설정에 1-RTT만 소요된다. 클라이언트가 서버에 어떤 신호를 한 번 주고, 서버도 거기에 응답하기만 하면 바로 본 통신을 시작할 수 있다.

참고로 QUIC는 순방향 오류 수정 메커니즘이 적용되었다.

이는 전송한 패킷이 손실되었다면 수신 측에서 에러를 검출하고 수정하는 방식이며 열약한 네트워크 환경에서도 낮은 패킷 손식률을 자랑한다.

profile
Lil_Young

0개의 댓글