HTTP

본 포스팅은 '면접을 위한 CS 전공지식 노트'를 기반으로 작성되었습니다.

 

HTTP overview

• TCP connection 사용(socket 생성)
• stateless(서버는 과거의 client 요청을 기억하지 않는다.) 
• 위의 stateless 적인 특성 때문에 client 는 쿠키를 사용해서 상태를 기억하고, server는 DB를 두어 상태를 기억한다.

HTTP connection 의 두가지 type

1. Non-persistent HTTP
   • 한 번의 3-way handshake에 한가지 object만 보낼 수 있음
2. Persistent HTTP
   • 한 번의 3-way handshake에 여러가지 object를 보낼 수 있음..

 

HTTP/1.0

 

• Non-persistent HTTP
• RTT(Round Trip Time) : 패킷이 목적지에 도달하고 나서 다시 출발지로 돌아오기까지 걸리는 시간
•  HTTP response time = 2RTT + file transmission time
• 이같은 문제를 해결하기 위해 이미지 스플리팅, 코드 압축, 이미지 Base 64인코딩 등 사용
• 혹은 TCP 연결을 여러개 열어서 통신

HTTP/1.1

• Persistent HTTP
• 한 번의 TCP 연결에 여러 object 전송 가능

HTTP/1.1 의 한계

HOL blocking(Head of Line Blocking)

• 첫 번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상

무거운 헤더 구조

• 쿠키 등 많은 헤더 구조가 들어 있고 압축이 되지 않아 무거웠다.

HTTP/2.0

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

멀티플렉싱

• 여러 개의 스트림을 사용하여 송수신
• 특정 스트림의 패킷이 손실되었다고 하더라도 해당 스트림에만 영향을 미치고 나머지 스트림을 문제 없이 동작
• HOL blocking 문제를 보완

헤더 압축

• 허프만 코딩 압축 알고리즘을 이용해 헤더를 압축(HPACK 압축 형식)

허프만 코딩이란?

허프만 코딩 (huffman coding)은 문자열을 문자 단위로 쪼개 빈도수를 세어 빈도가 높은 정보는 적은 비트 수를 시용하여 표현하고， 빈도가 낮은 정보는 비트 수를 많이 시용하여 표현해서 전체 데이터의 표현에 필요한 비트OJ을 줄이는 원리입니다.

서버 푸시

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

HTTP/2의 한계

• single TCP 연결에서 돌아감
• Packet loss가 발생한다면 멈춰 있을 수밖에 없다.
• vanilla TCP connection 위에 보안요소가 없어 취약하다.

HTTPS

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

SSL(Secure Socket Layer)/TLS(Transport Layer Security Protocol)

• TLS -> SSL의 업그레이드 버전
• 보통 합쳐서 SSL/TLS라고 많이 부름
• 보안 세션을 기반으로 데이터 암호화
• 인증 메커니즘, 키 교환 암호화 알고리즘, 해싱 알고리즘 사용

보안세션

• 보안이 시작되고 끝나는 동안 유지되는 세션
• 핸드셰이크를 통해 보안세션 생
• 세션: OS가 어떠한 사용자로부터 자신의 자산 이용을 허락하는 일정한 기간을 뜻함.

• 클라이언트에서 사이퍼 슈트(cypher suites)를 서버에 전달
• 서버에서는 사이퍼 슈트의 암호화 알고리즘 리스트를 제공할 수 있는지 확인
• 사이퍼슈트  = 프로토콜 + AEAD 사이퍼모드 + 해싱 알고리즘

사이퍼슈트

• 프로토콜, AEAD 사이퍼 모드, 해싱알고리즘이 나열된 규약
• 5개 존재
  • TLS__AESJ 28_GCM_SHA256 
  • TLS__AES_256_GCM_SHA384
  • TLS_CHACHA20_POL Y1305_SHA256
  • TLS__AESJ 28_CCM_SHA256
  • TLS__AESJ 28_CCM_8_SHA256

 

AEAD(Authenticated Encryption with Associated Data) 사이퍼모드

• 데이터 암호화 알고리즘
• AES_128_GCM 등이 있다 -> 128비트의 키를 사용하는 표준 블록 암호화 기술과 병렬계산에 용이한 암호화 알고리즘 GCM이 결합된 알고리즘이라는 뜻

해싱 알고리즘

• SSL/TLS는 해싱알고리즘으로 SHA-256, SHA-384사용

SHA-256알고리즘

• 해시 함수의 결괏값이 256비트인 알고리즘
• 해싱을 해야 할 메시지에 1을 추가하는 등 전처리 후, 전처리된 메시지를 기반으로 해시 반영

인증 메커니즘

• CA(Certificate Authorities)에서 발급한 인증서를 기반으로 이루어짐
• CA에서 발급한 인증서는 공개키를 클라이언트에게 제공
• 사용자가 접속한 서버가 신뢰할 수 있는 서버임을 보장

CA 발급과정

• 자신의 서비스가 CA인증서를 발급 받으려면 사이트 정보 + 공개키를 CA에 제출
• 이후 CA는 공개키를 해시한 값인 finger print를 사용하는 CA의 비밀키를 기반으로 CA 인증서 발급

암호화 알고리즘

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

 

HTTPS 의 이점

• SEO(Search Engine Optimization, 검색 엔진 최적화) 에도 도움이 된다.
• 구글 같은 경우 HTTPS 를 사용할 경우 검색엔진에 우선적으로 노출될 수 있게 한다.
• P128 참조

HTTPS 구축 방법

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

HTTP/3.0

• QUIC이라는 계층 위에서 돌아감.
• UDP 기반으로 돌아감.
• QUIC은 TCP를 사용하지 않아 통신을 할 때 3-way handshake과정이 없다. -> 초기 연결 설정 지연시간 감소
• QUIC 은 FEC(Forword Error Correction)이 적용되어 낮은 패킷 손실률을 가지고 있음.

HTTP request message

• ASCII(사람이 읽을 수 있는 포맷)

HTTP method

• POST
• GET
• HEAD
• PUT

HTTP response message

• ASCII로 되어 있다.

HTTP status codes

• 200: OK
• 301: Movd Permanently
• 400: Bad Request(서버가 클라의 요청을 이해하지 못했다.)
• 404: 서버에서 해당 request document를 찾지 못한다.
• 505: 브라우저는 2.0을 지원하는데 방문한 웹사이트가 1.0을 지원할 때 뜨는 에러

 

Cookies(쿠키)

• 추후 업데이트

Web caches(proxy server)

• 추후 업데이트

CDN

• 추후 업데이트