네트워크 #5 : HTTP

1. HTTP 헤더

• 클라이언트가 서버에 요청을 할 땐 헤더와 바디를 서버로 보낸다.
• 헤더는 바디를 설명하는 정보를 포함해서 여러가지 정보가 담긴 정보묶음이고  바디는 컨텐츠의 본문을 말한다.
• 헤더는 일반헤더, 요청헤더, 응답헤더 3가지로 이루어져 있다.
• 유연하게 설계되어 있어 커스텀이 가능하다
• 콜론으로 서로 구분되는 {key-value}형태
  • ex) {setCookie : cookie}

1) Header의 종류

일반헤더 (General Header)

• 요청 및 응답의 메시지 모두에서 사용되지만 컨텐츠에는 적용되지 않는 헤더
• 보안정도가 설정되어있는 Referrer Policy가 포함되어 있다.
• ex) Date, Cache-Control, Connection

요청헤더 (Request Header)

• 클라이언트가 서버에 요청할 때 클라이언트가 설정하는 또는 자동으로 설정되는 헤더
• Fetch될 리소스나 클라이언트 자체에 대한 정보를 포함하여 서버로 보내진다.
• ex) 메서드, 클라이언트의 OS, 브라우저 정보

응답헤더 (Response Header)

• 서버가 클라이언트에게 응답을 보낼 때 설정하는 또는 자동으로 설정되는 헤더
• 해커의 공격을 받았을 때 피해를 줄이기 위해 정보를 숨킨다.
• ex) 서버의 소프트웨어 정보

2) body

• 쉽게 말하면 컨텐츠의 본문을 말한다.
• 서버에서 보내고자 하는 컨텐츠 본문인 JSON, html, image 등이 담겨있다.

 

2. HTTP의 발전

1) HTTP/1.0  VS  HTTP/1.1

HTTP/1.0

 

• 연결의 수명이 짧다. 
  • 각 HTTP 요청당 TCP 핸드셰이크가 발생되며 기본적으로 한 연결당 하나의 요청을 처리한다.
  • HTML, JS, CSS파일이 있다고 할때 각 파일당 TCP핸드셰이크 발생, -> 불필요한 TCP요청때문에 RTT 증가
• 연결할 때마다 TCP연결을 계속해야한다.
  •  RTT가 늘어난다.
  • keep-alive설정이 defalut가 아니기 때문에 따로 설정을 해주어야 했었다.
• 서버가 하나의 호스트만 가진다고 가정한다
  • HTTP/1.0은 하나의 IP에 하나의 호스트만 가질 수 있다.
  • * 서버는 여러 개의 호스트를 가질 수 있다.
• 파일을 다운로드 받다가 연결이 끊기면 다시 다운로드 받는 것은 불가능

 

HTTP/1.1

• HTTP/1.0의 단점을 보완한 프로토콜 (연결할때마다 RTT증가)
• keep-alive가  default로 설정됨. 
  • 매번 데이터를 요청할 때마다 TCP 연결을 하는게 아닌 한번 해놓고 계속해서 데이터를 받을 수 있게 해준다.
  • TCP요청을 줄일 수 있어 RTT를 줄여준다.

keep-alive header
● TCP연결을 유지하는 것을 알려주는 헤더
● 연결유지시간인 timeout과 최대 요청수 max를 정할 수 있다.

• 호스트 헤더
  • HTTP/1.1은 헤더에 특정 호스트를 포함할 수 있게 변경
  • 항상 호스트를 포함해서 요청
• 대역폭 최적화
  • 다운로드시 중지되어도 이어서 받기 가능해졌다.
  • Range:bytes=5000- 라는 헤더를 추가해서 다운로드 재개 요청
• 증가된 RTT를 줄이기 위해 여러 기술들을 같이 사용한다.

1. 이미지 스프라이트
● 여러개의 이미지를 한번에 합쳐서 가져오는 방법
● 작은 이미지들을 합쳐 큰 이미지로 만들어 한번만 전송하면서 RTT를 감소시킨다..

2. 코드압축
● 띄어쓰기, 개행문자등의 지워 코드를 압축하는 방법
● 컨텐츠의 크기를 줄여서 RTT를 감소시킨다.

3. Base64인코딩
● 이미지파일을 64진법으로 이루어진 문자열로 인코딩해서 이미지 서버에 http요청이 필요없도록 만드는 방법
● 하지만 문자열로 인코딩 하기 때문에 크기가 37%정도 증가한다.

•  HOL과 무거운 헤더(Header) 

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

● 먼저 요청한 파일부터 순차적으로 파일이 전송되는데 앞에있던 파일 크기가 크면 그 뒤 파일들은 먼저 전송되지 않아서 다운로드 시간이 길어지는 것을 말함.

무거운 헤더구조
● HTTP/1.1헤더에는 쿠키등 많은 메타데이터들이 들어있는데 압축되지 않아 무겁다.

 

2) HTTP/2.0 VS HTTP/3.0

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

• 바이너리 포맷 계층
  • 애플리케이션 계층과 전송 계층 사이에 바이너리 포맷 계층을 추가해 데이터들을 캡슐화 해서 전송한다.

● HTTP/1.0은 일반 텍스트 메시지와 줄바꿈으로 데이터를 전송한다.
● HTTP/2.0은 바이너리 데이터로 변형시켜 전송한다.
   -> 더 작은 메시지가 프레임단위로 캡슐화 되어서 전송된다.

• 멀티 플렉싱
  • 단일 TCP연결의 여러 스트림에서 여러 HTTP 요청과 응답을 비동기적으로 보낸다. -> HOT문제가 해결됨
  • 특정 스트림의 패킷이 손실되어도 해당 스트림에만 영향을 미치기 때문에 나머지 스트림은 정상동작이 가능하다.

● HTTP1.1에서는 병렬요청을 하려면 다중TCP연결을 통해서 할수 있었다.
   -> TCP 연결하나당 병렬요청은 불가능

● HTTP/2.0에서는 리소스를 작은 프레임으로 나누고 이를 스트림으로 프레임을 전달
   -> 스트림ID, 해당 청크의 크기를 나타내는 프레임이 추가됐다.
   -> 작게 나눠서 다운로드가 되더라도 결과적으로 응답데이터에서는 올바른 순서로 재조립 가능

• 서버푸시 
  • HTTP/1.1은 클라이언트가 서버에 요청해야 파일다운이 가능했다.
  • HTTP/2.0은 서버가 리소스를 클라이언트에 푸시를 할 수 있다.
  • 요청된 html파일과 함께 다른 개체를 별도로 보낼 수 있다.

• 헤더 압축
  • HTTP/1.1은 헤더가 무거웠지만 HTTP/2.0은 허프만 인코딩 등을 통해 헤더를 압축한다.
  • 중복헤더값을 제거해 보내고 공통 필드로 헤더를 재조립한다. 중복되지 않은 헤더값은 허프만 인코딩 압축방법으로 압축해서 전송한다.

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

• 우선순위를 정해서 리소스를 전달한다.

HTTP/3.0
HTTP/2는 여전히 TCP를 사용해서 초기 연결에 대한 RTT로 인한 지연시간이라는 문제점이 있었고 이를 해결한 버전

• QUIC ( Quick UDP Internet Connections )
  • QUIC라는 계층에서 TCP기반이아니라 UDP기반으로 돌아간다. 
  • -> 초기연결설정시 지연시간 감소

• RTT에 대한 문제 해결
  • TCP는 3-RTT가 필요하지만 UDT는 1-RTT만 필요하기 때문에 RTT에 대한 문제가 해결됐다.
  • HTTP/2나 HTTP/3 은 HTTPS 위에서 돌아가는데 TLS로 암호화통신을 구축할 때의 핸드셰이크를 활용하기 때문에 1-RTT만에 연결이 가능하다.

• 순방향 오류 수정 메커니즘 (FEC, Forward Error Correction)
  • 전송된 패킷이 손실 되었다면 수신측에서 에러를 검출하고 수정하는 방식
  • 낮은 패킷손실률을 자랑한다.

3. HTTPS

1) HTTPS

• 애플리케이션계층과 전송계층 사이에 신뢰계층인 SSL/TLS계층을 넣은 신뢰할 수 있는 HTTP요청
• 암호화된 HTTP 통신이 가능하다 = 통신을 암호화

2) 암호화 

• 승인된 당사자만 정보를 이해할 수 있도록 데이터를 스크램블한 방법
• 복호화를 하기 위해선 송-수신 한 사람들이 서로 동의한 KEY가 필요하다. 
• 암호화는 해커들의 하이재킹해서 민감한 데이터의 유출을 방지해주고, 데이터의 무결성을 보장한다.

 

스크램블

• 문자를 패턴에 따라 암호화하는 것이 아니라 무작위 방식으로 개별 데이터 비트를 섞는 것

 

KEY를 이용한 암호화

• 대칭암호화
  • KEY1개만 사용하는 암호화 방식
  • ex ) DES, AES

• 비대칭 암호화(공개키 암호화)
  
  • KEY를 2개 사용하는 암호화 방식 (공개키, 개인키)
  • ex) RSA, DH(Diffie–Hellman)
    • RSA는 클라이언트가 생성한 임시 암호값을 서버로 전송하지만 DH의 경우 클라이언트와 서버가 서로 교환한 DH 매개변수를 사용해 개인키를 만든다.
    • 클라이언트에서 생성한 임시 암호값이 탈취당한 경우 해킹의 위험
    • 그래서 RSA사용안하고 DH를 사용한다. 

TLS 핸드셰이크
● 부분적으로 비대칭 암호화를 사용한다.
● 비대칭암호화로 인증을 한 후, 대칭 암호화로 보안적 통신을 시작한다.
● TLS 핸드셰이크 과정에서 처음 인증할 때 비대칭암호화를 하고 그 이후 클라이언트와 서버는 "세션키"라고 하는 키를 기반으로 대칭 암호화를 기반으로 암호화된 통신을 한다.
● 0-RTT : 세션키를 기반으로 소통해서 인증할 때 드는 비용이 없다.

TLS/SSL
● SSL의 버전이 올라가면서 명칭이 TLS로 변경됨 -> 같은 의미
● 전송계층에서 보안을 제공하는 프로토콜
● 클라이언트가 서버와 통신할 때 TLS를 통해 제 3자가 페이지를 도청하거나 변조를 못하도록 한다.


TLS 과정
● 사용할 TLS버전을 정하고, 사이퍼슈트, 서버의 공개키, SSL인증서를 기반으로 인증작업을 수행한다.
   이후, 대칭 암호화를 위해 세션키를 생성한다,

● 1. Client Hello
   TSL버전, 사이퍼슈트, 클라이언트 랜덤값,임시 DH매개변수를 서버로 보내는 과정
● 2. Server Hello, EncryptedExtensions, Certificate, CertificateVerify
  서버에서 TLS버전 확인 후 인증을 위한 정보를 클라이언트에게 보내면 클라이언트와 서버가 서로 교환한 DH 매개변수를 사용하여 임시 암호 키(세션키)를 생성한다.
● 3. Finished
   클라이언트 - 서버 는 세션키를 기반으로 대칭 암호화된 통신이 시작된다 (=보안세션이 시작된다.)

DH ( Diffie-Hellman ) 매개변수

● 서로 공개값 공유, 비밀값과 혼합, 혼합값과 공유, 각자의 비밀값과 혼합해서 공통의 암호키를 만드는 알고리즘
● 보통은 DH + 타원곡선암호화를 섞은 ECDHE를 쓴다.

타원 곡선 암호화

● 곡선을 사용하여 개인 키 보유자만 알 수 있는 타원곡선을 그려 교차점을 생성한다
● 생성한 교차점의 수를 기반으로 암호화 한다.

사이퍼슈트
● 프로토콜 , AEAD사이퍼모드 , 해싱알고리즘이 나열된 규약
● 한마디로 암호제품군이라 할수 있다.
● TLS3.1버전에는 5개가 있다.
ex )
TLS_AES_128_GCM_SHA256
프로포폴 + AEAD 사이퍼 모드 + 해싱알고리즘

AEAD사이퍼모드 : DATA 암호화 알고리즘
ex) AES_128_GCH
     -> 128비트 KEY를 사용하는 표준 블록암호화 기술 + 병렬계산에 용이한 GCM을 결합한 알고리즘

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

ex) SHA-256, SHA-384
-> 해시함수 결과값이 256비트인 알고리즘

TLS에 해싱 알고리즘이 쓰이는 이유
인증서가 올바른 알고리즘인지 확인할 때 전자서명을 사용하는데 이때 해싱 알고리즘이 사용된다
먼저 인증생성작업을 통해 전자서명만들때 서명되는 메세지를 해싱하고, 인증확인작업을 통해 메세지 복호화 후 해시를 서로 비교해 올바른 메세지인지 확인하는 작업을 한다.