5. HTTP.md

HTTP

목차

• HTTP
  • 목차
  • 개요
  • HTTP (Hypertext Transfer Protocol)
    • 쿠키와 세션
    • 쿠키
    • 세션
    • 쿠키와 세션의 차이점
  • HTTP 요청
    • 구성 요소
    • HTTP 요청 예시
    • 시작 줄
    • 헤더
    • 본문
  • HTTP 응답
    • 구성 요소
    • HTTP 응답 예시
    • 상태 줄
  • 그림으로 보는 HTTP의 역사
  • HTTP/1.0
    • 단점: RTT 증가
    • RTT 증가를 해결하기 위한 방법
  • HTTP/1.1
  • HTTP/2
    • 멀티 플렉싱
    • 헤더 압축
    • 서버 푸시
  • HTTPS
    • SSL/TLS
    • CA 기반 인증 매커니즘
    • 디피-헬만 키 교환 암호화 알고리즘
    • 해싱 알고리즘
    • SEO에도 도움이 되는 HTTPS
    • HTTPS 구축 방법 세 가지
  • HTTP/3
    • 초기 연결 설정 시 지연 시간 감소
  • 참고 자료

개요

HTTP의 역할과 특징, 발전 과정에 대해 이해한다.

---

HTTP (Hypertext Transfer Protocol)

• 개념

  • 웹 상에서 클라이언트와 서버 간의 데이터 전송을 위한 프로토콜이다.
  • 주로 브라우저와 웹 서버 간의 통신에 사용된다.
  • TCP/IP를 이용하는 응용 프로토콜이다.
  • 애플리케이션 계층에 해당한다.
  • HTTP 1.0부터 시작해서 발전을 거듭하여 지금은 HTTP/3 이다.

• 특징

  1. 클라이언트-서버 구조: 클라이언트가 요청을 하기 위해 연결을 연 다음, 응답을 받을 때까지 대기하는 전통적인 클라이언트-서버 모델을 따른다.
  2. 비연결성(Connectionless): 서버와 클라이언트는 요청을 주고받은 후 연결을 유지하지 않고 종료한다.
  3. 무상태(Stateless): 서버가 클라이언트의 상태를 보존하지 않는다.

쿠키와 세션

• 배경

  • HTTP의 특징이자 단점인 비연결성과 무상태을 해결하기 위해 쿠키와 세션을 사용한다.

• 문제 상황 예시

  • 통신이 끊어지면 상태정보가 유지되지 않기 때문에 매번 페이지를 이동할 때마다 다시 로그인 해야한다.
  • 상품 선택 후 구매 페이지에서 선택한 상품의 정보가 없어진다.

쿠키

• 개념

  • 클라이언트(브라우저) 로컬에 저장되는 키와 값이 들어있는 작은 데이터 파일

• 역할과 특징

  • 사용자 인증이 유효한 시간을 명시할 수 있다.
    • 유효 시간이 정해지면 브라우저가 종료되어도 인증이 유지된다.
  • 클라이언트의 상태 정보를 로컬에 저장했다가 참조한다.
  • 클라이언트에 300개까지 쿠키저장이 가능하고, 하나의 도메인당 20개의 값만 가질 수 있습니다. 하나의 쿠키값은 4KB까지 저장한다.
  • Response Header에 Set-Cookie 속성을 사용하면 클라이언트에 쿠키를 만들 수 있다.
  • 쿠키는 사용자가 따로 요청하지 않아도 브라우저가 Request시에 Request Header를 넣어서 자동으로 서버에 전송한다.

• 구성 요소

  • 이름 : 각각의 쿠키를 구별하는 데 사용되는 이름
  • 값 : 쿠키의 이름과 관련된 값
  • 유효시간 : 쿠키의 유지시간
  • 도메인 : 쿠키를 전송할 도메인
  • 경로 : 쿠키를 전송할 요청 경로

• 동작 방식

  1. 클라이언트가 페이지를 요청한다.
  2. 서버에서 쿠키를 생성한다.
  3. HTTP 헤더에 쿠키를 포함시켜 응답한다.
  4. 브라우저가 종료되어도 쿠키 만료 기간이 있다면 클라이언트에서 보관한다.
  5. 같은 요청을 할 경우 HTTP 헤더에 쿠키를 함께 보낸다.
  6. 서버에서 쿠키를 읽어 이전 상태 정보를 변경할 필요가 있을 때, 쿠키를 업데이트하여 변경된 쿠키를 HTTP 헤더에 포함시켜 응답한다.

• 사용 예시

  • 쇼핑몰의 장바구니 기능
  • 팝업에서 "오늘 더 이상 이 창을 보지 않음" 체크

세션

• 개념

  • 쿠키를 기반하고 있지만, 사용자 정보 파일을 브라우저에 저장하는 쿠키와 달리 세션은 서버 측에서 관리한다.

• 역할과 특징

  • 클라이언트가 Request를 보내면 해당 서버의 엔진이 클라이언트에게 유일한 ID를 부여하는데, 이것이 세션 ID이다.
  • 서버에서는 클라이언트를 구분하기 위해 세션 ID를 부여한다.
    • 이를 통해 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지한다.
    • 클라이언트를 구분하여 각 클라이언트의 요구에 맞는 서비스를 제공한다.
    • 접속 시간에 제한을 두어 일정 시간 응답이 없다면 정보가 유지되지 않게 설정이 가능하다.
  • 사용자에 대한 정보를 서버에서 가진다.
    • 쿠키보다 보안에 좋지만 사용자가 많아질수록 서버 메모리를 많이 차지한다.
    • 즉, 동접자 수가 많은 웹 사이트인 경우 서버에 과부하를 주게 되므로 성능 저하의 요인이 될 수 있다.

• 동작 방식

  1. 클라이언트가 서버에 접속 시 세션 ID를 발급 받는다.
  2. 클라이언트는 세션 ID에 대해 쿠키를 사용해서 저장하고 가지고 있는다.
  3. 클라리언트는 서버에 요청할 때, 이 쿠키의 세션 ID를 같이 서버에 전달해서 요청한다.
  4. 서버는 세션 ID를 전달 받아서 별다른 작업없이 세션 ID로 세션에 있는 클라이언트 정보를 가져와서 사용한다.
  5. 클라이언트 정보를 가지고 서버 요청을 처리하여 클라이언트에게 응답한다.

• 사용 예시

  • 로그인 같이 보안상 중요한 작업을 수행할 때

쿠키와 세션의 차이점

• 저장 위치

  • 쿠키는 클라이언트 측에 저장되고, 세션은 서버 측에 저장된다.

• 서버의 자원

  • 쿠키는 서버의 자원을 전혀 사용하지 않고, 세션은 서버의 자원을 사용한다.

• 보안 & 속도

  • 세션은 서버의 처리가 필요하기 때문에, 보안 면에서는 세션이 더 우수하고 요청 속도는 쿠키가 세션보다 더 빠르다.
  • 쿠키는 클라이언트 로컬에 저장되기 때문에 변질되거나 request에서 스니핑 당할 우려가 있어서 보안에 취약하다.
  • 세션은 쿠키를 이용해서 session Id 만 저장하고 그것으로 구분해서 서버에서 처리하기 때문에 비교적 보안성이 좋다.

• 라이프 사이클

  • 쿠키도 만료시간이 있지만 파일로 저장되기 때문에 브라우저를 종료해도 계속해서 정보가 남아 있을 수 있다.
  • 또한 쿠키 만료기간을 넉넉하게 잡아두면 쿠키를 직접 삭제하기 전까지 계속 유지될 수도 있다.
  • 반면에 세션도 만료시간을 정할 수 있지만 브라우저가 종료되면 만료시간에 상관없이 삭제된다.

• 세션을 사용하면 좋은데 왜 쿠키를 사용할까?

  • 세션은 서버의 자원을 사용하기 때문에 무분별하게 만들다보면 서버의 메모리가 감당할 수 없어질 수 있고 속도가 느려질 수 있다. 따라서 쿠키가 유리한 경우가 있다.

• 쿠키/세션은 캐시와 엄연히 다르다.

  캐시: 웹에서 이미지나 css, js파일 등을 브라우저나 서버 앞 단에 저장해놓고 사용하는 것

HTTP 요청

구성 요소

1. 시작 줄
2. 헤더
3. 본문

HTTP 요청 예시

POST /signup HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "name": "John Doe",
  "email": "[email protected]"
}

• 첫 번째 줄 (시작 줄)

  • HTTP 요청 메서드, URL 경로, HTTP 프로토콜 버전 정보

• 두 번째 줄 ~ 세 번째 줄

  • HTTP 요청의 헤더 (key:value 쌍)

• 그 이후 줄

  • HTTP 요청의 바디

시작 줄

1. HTTP 메서드: 클라이언트가 서버에게 특정 동작을 요청하는 방법을 정의한다.
2. 요청 타겟: 주로 URL, 또는 프로토콜, 포트, 도메인의 절대 경로로 나타낸다.
3. HTTP 버전: 응답 메시지에서 써야 할 HTTP 버전을 알려준다.

• GET

  • 개념

    • 서버로부터 특정 리소스 요청 (Read)

  • 역할

    • URL에 쿼리 매개변수를 포함하여 데이터를 전달한다.

      GET 방식은 Body에 데이터를 담을 수 없을까?
      답은 담을 수 있다 이다.
      그렇지만 GET으로는 요청만 하기로 약속했기 때문에 담지 않는다.

    • 조회할 때 POST도 사용할 수 있지만, GET 메서드는 캐싱이 가능하기에 GET을 사용하는 것이 유리하다.

  • 예시: GET /members/100?username=newcodes

• POST

  • 개념

    • 서버로 데이터 제출하여 리소스 생성하거나 업데이트 요청 (Create)

  • 역할

    • HTTP Body에 데이터를 포함하여 전송한다.
    • 만일 데이터를 GET 하는데 있어, JSON으로 조회 데이터를 넘겨야 하는 애매한 경우 POST를 사용한다.

• PUT

  • 개념

    • 지정된 리소스의 업데이트 요청

  • 역할

    • 지정된 리소스의 전체 내용을 본문에 포함하여 전송한다.
    • 만일 요청 메세지에 리소스가 있으면 덮어쓰고, 없으면 새로 생성한다.

• DELETE

  • 개념
    • 지정된 리소스 삭제 요청

• PATCH

  • 개념

    • 리소스 부분 변경 (PUT이 전체 변경, PATCH는 일부 변경)

  • 역할

    • 만일 PATCH를 지원하지 않는 서버일 경우 POST를 사용한다.

헤더

• 개념
  • 웹사이트 도메인의 호스트, 언어, 사용자의 브라우저 등 서버가 필요한 정보를 전달한다.

본문

• 개념

  • POST, PUT 요청과 같이 요청과 함께 전달되는 데이터를 포함

• 배치

  • 요청의 마지막 부분에 들어가며, 모든 요청에 본문이 들어가지는 않는다.
    • GET, HEAD, DELETE , OPTIONS처럼 리소스를 가져오는 요청은 보통 본문이 필요없다.
    • 일부 요청은 업데이트를 하기 위해 서버에 데이터를 전송한다.
    • 보통 (HTML 폼 데이터를 포함하는) POST 요청일 경우

HTTP 응답

구성 요소

1. 상태 줄
2. 헤더
3. 본문

HTTP 응답 예시

HTTP/1.1 200 OK
Date: Sat, 09 Oct 2023 14:28:02 GMT
Server: Apache
Content-Type: text/html

<html>
...
</html>

• 첫 번째 줄

  • HTTP 프로토콜 버전 정보와 HTTP 상태 코드

• 두 번째 줄 ~ 네 번째 줄

  • HTTP 응답의 헤더 (key:value 쌍)

    헤더: 브라우저가 필요한 정보를 전달

• 다섯 번째 줄 ~ 마지막 줄

  • HTTP 응답의 Body

    Body: 브라우저가 요청한 데이터 (위 예시에서는 HTML 데이터)

상태 줄

1. HTTP 버전: HTTP/1.1과 같은 HTTP 프로토콜의 버전
2. 상태 코드: 서버가 요청을 성공적으로 처리했는지 또는 오류가 발생했는지를 나타내는 숫자
3. 상태 텍스트: 상태 코드에 대한 간단한 설명을 나타내는 텍스트

• HTTP 상태 코드

  • 1XX: Informational(정보 제공)

    • 임시 응답으로 현재 클라이언트의 요청까지는 처리되었으니 계속 진행하라는 의미이다.
    • HTTP 1.1 버전부터 추가되었다.

  • 2XX: Success(성공)

    • 클라이언트의 요청이 서버에서 성공적으로 처리되었다는 의미이다.

  • 3XX: Redirection(리다이렉션)

    • 완전한 처리를 위해서 추가 동작이 필요한 경우이다.
    • 주로 서버의 주소 또는 요청한 URI의 웹 문서가 이동되었으니 그 주소로 다시 시도하라는 의미이다.

  • 4XX: Client Error(클라이언트 에러)

    • 없는 페이지를 요청하는 등 클라이언트의 요청 메시지 내용이 잘못된 경우를 의미한다.

  • 5XX: Server Error(서버 에러)

    • 서버 사정으로 메시지 처리에 문제가 발생한 경우이다.
    • 서버의 부하, DB 처리 과정 오류, 서버에서 익셉션이 발생하는 경우를 의미한다.

• HTTP 주요 상태 텍스트

  • 200 OK: 요청이 성공적으로 처리되었음을 나타낸다.
  • 404 Not Found: 요청한 리소스를 찾을 수 없음을 나타낸다.
  • 500 Internal Server Error: 서버에서 처리 중에 오류가 발생했음을 나타낸다.

그림으로 보는 HTTP의 역사

HTTP/1.0

• 개념

  • HTTP/1.0 은 한 연결당 하나의 요청을 처리하도록 설계되었다.

• 요청/응답 예시 이미지

  

단점: RTT 증가

• 서버로부터 파일을 가져올 때마다 TCP의 3-way-handshake를 계속해서 열어야 하기 때문에 RTT가 증가된다.

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

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

• 이미지 스플리팅: 많은 이미지를 다운로드 받게 되면 과부하가 걸리기 때문에, 합쳐진 하나의 이미지를 다운로드 받고, 이를 기반으로 background-image의 position을 이용하여 이미지를 표기하는 방법이다.

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

• 이미지 Base64 인코딩: 이미지 파일을 64진법으로 이루어진 문자열로 인코딩하는 방법이다.

  • 장점: 서버와의 연결 시 이미지에 대해 서버에 HTTP 요청을 할 필요가 없어 RTT가 감소
  • 단점: 크기가 37% 정도 증가

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

HTTP/1.1

• 발전

  • 매번 TCP 연결을 하는 대신 한 번 TCP 초기화를 한 후, keep-alive라는 옵션으로 여러 개의 파일을 송수신할 수 있는 기능이 표준화되어 기본 옵션으로 설정되었다.

  • 요청응답 예시 이미지

    

• 단점

  1. 대기 시간 증가
     • 문서 안에 포함된 다수의 리소스를 처리하려면 요청할 리소스 개수에 비례해서 대기 시간이 길어진다.
  2. HOL Blocking
     • Head Of Line Blocking 으로, 네트워크에서 같은 큐에 있는 패킷이 그 첫 번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상을 말한다.
  3. 무거운 헤더 구조
     • HTTP/1.1의 헤더에는 쿠키 등 많은 메타데이터가 들어 있고 압축이 되지 않아 무거웠습니다.

HTTP/2

• 발전
  • HTTP/1.x보다 지연 시간을 줄이고, 응답 시간을 더 빠르게 할 수 있으며, 다음의 기능을 지원하는 프로토콜이다.

멀티 플렉싱

• 개념

  • 하나의 연결 내 병렬적인 스트림으로 데이터를 운반한다.

• 특징

  • 특정 스트림의 패킷이 손실되었다고 하더라도 해당 스트림에만 영향을 미치고 나머지 스트림은 멀쩡하게 동작할 수 있다.

• 기존의 문제점 해결

  • 하나의 연결당 하나의 스트림을 순차적으로 처리하는 것에 비해 TCP 커넥션의 횟수도 줄고, HTTP/1.x에서 발생하는 문제인 HOL Blocking 문제도 해결했다.

헤더 압축

• 개념
  • 허프만 코딩 압축 알고리즘을 통해 HTTP/1.x의 헤더 크기 문제를 해결했다.

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

서버 푸시

• 개념

  • 클라이언트가 html 파일을 요청한 경우 그 안의 css, js 파일을 서버에서 푸시하여 클라이언트에게 먼저 전달한다.

• 기존의 문제점 해결

  • HTTP/1.1와 달리 클라이언트의 요청 없이도 서버가 필요한 리소스를 바로 푸시한다.

HTTPS

• 개념

  • HTTPS는 애플리케이션 계층과 전송 계층 사이에 신뢰 계층인 SSL/TLS 계층을 넣은 신뢰할 수 있는 HTTP 요청을 말한다.

• 특징

  • 이를 통해 통신을 암호화 한다.
  • HTTP/2는 HTTPS 위에서 동작한다.

SSL/TLS

• 개념

  • 전송 계층에서 보안을 제공하는 프로토콜로, 클라이언트와 서버가 통신할 때 이를 통해 제3자가 메시지를 도청하거나 변조하는 인터셉터를 방지한다.

    인터셉터: 네트워크에서 공격자가 서버인 척하며 사용자 정보를 가로채는 행위

• 원리

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

• 보안 세션

  • 개념

    • 보안이 시작되고 끝나는 동안 유지되는 세션을 말한다.

      세션: 운영체제가 어떤 사용자로부터 자신의 자산 이용을 허락하는 일정한 기간

  • 방법

    • SSL/TLS는 핸드셰이크를 통해 보안 세션을 생성하고 이를 기반으로 상태 정보 등을 공유한다.

  • SSL/TLS 핸드셰이크

    
    • 클라이언트와 서버가 키를 공유하고 이를 기반으로 인증, 인증 확인 등의 작업이 일어나는 단 한 번의 1-RTT가 생긴 후 데이터를 송수신한다.

      TLS 1.3의 경우, 사용자가 이전에 방문한 사이트로 다시 방문한다면 SSL/TLS에서 보안 세션을 만들 때 걸리는 통신을 하지 않아도 된다.
      이를 0-RTT라고 한다.

  • 사이퍼 슈트

    • 개념
      • [프로토콜]_[AEAD 사이퍼 모드]_[해싱 알고리즘]의 구조로 나열된 규약으로, 다음 다섯 개가 있다.
      • 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 사이퍼 모드: Authenticated Encryption with Associated Data 이며, 이는 데이터 암호화 알고리즘으로 AES_123_GCM 등이 있다. 예를 들어 AES_123_GCM은 128비트의 키를 사용하는 표준 블록 암호화 기술과 병렬 계산에 용이한 암호화 알고리즘 GCM이 결합된 알고리즘을 뜻한다.

CA 기반 인증 매커니즘

• 개념

  • 인증 메커니즘은 CA(Certificate Authorities)에서 발급한 인증서를 기반으로 이루어진다.
  • 이 인증서는 안전한 연결을 시작하는 데 있어 필요한 공개키를 클라이언트에 제공하고, 사용자가 접속한 서버가 신뢰할 수 있는 서버임을 보장한다.

• 특징

  • 인증서는 서비스 정보, 공개키, 지문, 디지털 서명 등으로 이루어져 있다.
  • CA는 신뢰성이 엄격하게 공인된 기업들만 참여할 수 있으며, 대표적인 기업으로 아마존이 있다.

• CA 발급 과정

  • 먼저 자신의 사이트 정보와 공개키를 CA에 제출해야 한다.
  • 이후 CA는 공개키를 해시한 값인 지문(finger print)을 사용하는 CA의 비밀 키 등을 기반으로 CA 인증서를 발급한다.

    해시: 다양한 길이를 가진 데이터를 고정된 길이를 가진 데이터로 매핑한 값

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

• 디피-헬만 키 교환(Diffie-Hellman key exchange) 암호화 알고리즘

  • 개념
    • 암호키를 교환하는 하나의 방법
    • 만약 y=g^x mod p 라는 식이 있을 때, g와 x와 p를 안다면 y는 구하기 쉽지만, g와 y와 p만 안다면 x를 구하기는 어렵다는 원리에 기반한 알고리즘이다.
  • 사용
    • 처음 클라이언트와 서버가 공개 값을 공유하고 각자의 비밀 값과 혼합한 후 혼합 값을 공유한다.
    • 그 다음 각자의 비밀 값과 다시 혼합한다.
    • 이후 공통의 암호키인 PSK(Pre-Shared Key)가 생성된다.

• 디피-헬만 방식을 근간으로 만들어진 키 교환 암호화 알고리즘

  1. 대수곡선 기반의 ECDHE(Elliptic Curve Diffie-Hellman Ephermeral)
  2. 모듈식 기반의 DHE(Diffie-Hellman Ephermeral)

해싱 알고리즘

• 개념

  • 데이터를 추정하기 힘든 더 작고 섞여있는 조각으로 만드는 알고리즘

• SHA-256 알고리즘

  • 개념
    • SSL/TLS에서 많이 쓰는 해싱 알고리즘으로, 해시 함수의 결과값이 256비트인 알고리즘이며 블록체인 시스템에서도 사용된다.
  • 사용
    • 해싱을 해야 할 메시지에 1을 추가하는 등의 전처리를 하고, 전처리된 메시지를 기반으로 해시를 반환한다.
    • SHA-256 사이트에서 다양한 해싱 알고리즘을 테스팅할 수 있습니다.

SEO에도 도움이 되는 HTTPS

• 구글은 SSL 인증서를 강조해왔고, 사이트 내 모든 요소가 동일하다면 HTTPS 서비스를 하는 사이트가 그렇지 않은 사이트보다 SEO 순위가 높을 것이라고 공식적으로 밝혔다.

• 검색엔진 최적화를 뜻하는 SEO(Search Engine Optimization)는 사용자들이 검색엔진으로 검색 시 그 결과를 페이지 상단에 노출시켜 많은 사람이 볼 수 있도록 최적화하는 방법을 의미한다. SEO 관리를 위한 방법에는 다음과 같은 것들이 있다.

  • 캐노니컬 설정: 사이트 link 에 캐노니컬을 설정한다.

    <link rel="canonical" href="https://example.com/page2.php">

  • 메타 설정: html 파일의 가장 윗부분인 메타를 잘 설정해야 한다.
  • 페이지 속도 개선: 사이트의 속도를 빠르게 만든다. 구글의 PageSpeedInsight로 자신의 서비스에 대한 리포팅을 주기적으로 받으며 관리할 수 있다.
    • 페이지 인사이트 링크
  • 사이트맵 관리: 사이트맵(sitemap.xml)을 정기적으로 관리해야 한다.
    • 사이트맵 제너레이터를 사용하거나 직접 코드를 만들어 구축하기도 한다.

HTTPS 구축 방법 세 가지

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

HTTP/3

• 개념

  • World Wide Web에서 정보를 교환하는 데 사용되는 HTTP의 세 번째 버전

• 이전 버전과의 비교

  
  • TCP 위에서 돌아가는 HTTP/2와 달리 QUIC라는 계층 위에서 돌아가며, TCP 기반이 아닌 UDP 기반으로 돌아간다.
  • HTTP/2의 장점인 멀티 플렉싱을 가지고 있고, 초기 연결 설정 시 지연 시간 감소라는 장점이 있다.

• 참고 정보

  • 2012년, 구글에서 QUIC(Quick UDP Internet Connections)이라는 범용 전송 계층 네트워크 프로토콜을 발표했다.
  • 2022년, IETF(국제 인터넷 표준화 기구)에서 QUIC 프로토콜을 기반으로 동작하는 HTTP/3 표준화 문서인 RFC 9114를 제정했다.
  • 이런 흐름에 맞춰 네이버가 국내에서 처음으로 HTTP/3 도입했다.

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

• QUIC은 UDP 기반이기에 3-way-handshake 과정을 거치지 않아도 된다.
• QUIC은 첫 연결 설정에 TLS Handshake 통해 1-RTT만 소요된다. (cf. TCP에서는 3-RTT 소요)
• QUIC은 순방향 오류 수정 메커니즘(FEC, Forward Error Correction)이 적용된다.
  • 전송한 패킷이 손실되었다면 수신 측에서 에러 검출하고 수정하는 방식으로, 열악한 네트워크 환경에서도 낮은 패킷 손실률을 자랑한다.

---

참고 자료

• 관련 서적
  • 면접을 위한 CS 전공지식 노트(주홍철)
• 참고 문서
  • https://docs.tosspayments.com/resources/glossary/http-protocol#http-요청과-응답
  • HTTP/3: https://medium.com/rate-labs/quic-프로토콜-구글-또-너야-932befde91a1
  • HTTP 메서드: https://inpa.tistory.com/entry/WEB-🌐-HTTP-메서드-종류-통신-과정-💯-총정리
  • HTTP 요청과 응답: 응답 메시지에서 써야 할 HTTP 버전을 알려주는 역할
  • HTTP 상태코드: https://hongong.hanbit.co.kr/http-상태-코드-표-1xx-5xx-전체-요약-정리/
  • 쿠키 세션: https://velog.io/@octo__/쿠키Cookie-세션Session
  • HTTP 역사: https://velog.io/@wlwl99/HTTP의-특징
  • TLS/SSL Handshake
  • TLS 1.3
  • HTTPS 패킷 분석 (TLS 1.2와 TLS 1.3)
  • RSA, DHE 키 교환 방법
  • TLS1.3 (8) - TLS1.3 Handshake / 1-RTT&0-RTT / 완전 협상&단축 협상
  • QUIC 프로토콜