HTTP

• 클라이언트와 서버간 데이터를 주고 받는 응용 계층 프로토콜
• 웹 서비스 통신에 주로 사용
• TCP 세션 기반 으로 데이터 전달이 이루어짐

1. HTTP/1.0

1.1 1 GET / 1 CONNECT

• 한 연결 당 하나의 요청을 처리
• 서버로부터 파일을 가져올 때마다 TCP 세션을 계속 맺어야 함 → RTT(Round Trip Time) 증가
• RTT란?
  • 패킷지 목적지에 도달하고 나서 다시 출발지로 돌아오기까지 걸리는 시간
  • 한마디로 패킷 왕복 시간

RTT가 증가하면 왜 안좋은가?

• 서버 부하 증가
• 사용자 응답 시간 증가

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

이미지 스플리팅

• 대량의 이미지를 다운로드 받을 시, 합쳐진 하나의 이미지를 다운받음.
• 다운받은 하나의 이미지를 기반으로 background-image 의 position을 이용하여 이미지를 표기함.

#icons>li>a {
    background-image: url("icons.png");
    width: 25px;
    display: inline-block;
    height: 25px;
    repeat: no-repeat;
}
#icons>li:nth-child(1)>a {
    background-position: 2px -8px;
}
#icons>li:nth-child(2)>a {
    background-position: -29px -8px;
}

• 하나의 이미지인 icons.png 를 기반으로 background - position 을 통해 2개의 이미지를 설정함

코드 압축

• 코드를 압축해서 개행 문자, 빈칸을 없애서 코드의 크기(용량)를 최소화함
• 자바스크립트에서 Webpack등을 사용해 번들링할 때 주로 사용됨

const express = require('express')
const app = express()
const port = 3000
app.get('/', (req, res) => {
    res.send('Hello World!')
})

app.listen(port, () => {
    console.log(`Example app listening on port ${port}`)
})

const express=require("express"),app=express(),port=3e3;app.get("/",(e,p)=>{p.send("Hello World!")}),app.listen(3e3,()=>{console.log("Example app listening on port 3000")});

• 위를 아래와 같이 압축함

이미지 Base64 인코딩

• 이미지 파일을 64진법으로 이루어진 문자열로 인코딩
• 이미지에 대해 서버에게 별도의 HTTP 요청을 할 필요가 없어짐
  • HTTP 요청을 통해 이미지를 전달할 경우, 서버와 클라이언트는 이미지의 url을 주고 받기 때문에 추가적인 요청이 필요해짐
    • client : sever에게 이미지 파일의 url을 제공
    • server : client한테 받은 url에 접속하여 다운로드 받은 후 응답으로 전송해야함
  • 그러나 인코딩하여 이미지를 전달하면, 문자열을 주고 받는 것임으로 간편하게 통신할 수 있음
• 하지만, Base64 문자열로 변환할 경우 이미지 크기가 37% 정도 더 커지는 단점이 있음 →그니까 통신 과정은 간단해지는데 실제 전송 크기가 더 커진다는 얘기잖아. RTT에 큰 차이는 없을 것 같음.
  

1.2 Host Header의 부재

• 어느 서버로 가는지 목적지가 명확하지 않기 때문에 하나의 IP에서 하나의 도메인만 처리 가능

💡 이처럼 비연결형이라 매 요청마다 새롭게 연결해야 하고,
Host 헤더를 지원하지 않아 서버 부하가 컸음

2. HTTP/1.1

2.1 N GET / 1 CONNECT

• 매번 TCP연결을 하지 않고, 한 개의 TCP 세션을 통해 keep-alive 옵션으로 지속적인 연결을 유지함
• 이 차이점만으로도 TCP 세션 부하를 줄일 수 있고 클라이언트의 응답속도가 개선됨

2.2 Host Headers

• 버츄얼 호스팅이 가능해짐
  • 하나의 IP(Host header)로 한 서버에서 다수의 도메인을 처리할 수 있게 됨

Host Header란?

• 클라이언트와 서버가 요청과 응답으로 데이터를 교환할 때, HTTP 메서드를 주고 받음
• 이 중, Host는 포트를 포함한 서버의 도메인 이름을 나타냄

  • 어느 서버로 요청했는지 정확히 하기 위해

    // 요청헤더 예시
    GET /hello/other/top-20-mysql-best-practices/ HTTP/1.1
    **Host: net.tutsplus.com**
    User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,
    Accept-Language: ko,en;q=0.5
    Accept-Encoding: gzip,deflate
    Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    Keep-Alive: 300
    Connection: keep-alive
    Cookie: token=ejaflkaadsfase
    Pragma: no-cache
    Cache-Control: no-cache

2.3 파이프라이닝 지원

• 비동기 요청 처리가 가능해짐
• 하지만 HOL Blocking 문제로 실제 사용은 제한적임
  

• 파이프라인이 없는 경우 요청과 응답이 순차적으로 진행됨
  • 요청1에 대한 응답1이 없을 경우, 요청2,3도 진행되지 않아 굉장히 비효율적임
• 파이프라인이 있는 경우 요청을 보낸 후, 요청을 모두 보낸 후 응답을 받음
  • 뷰 응답 속도를 높힘

2.4 HOL Blocking(Head Of Line Blocking)

• 같은 큐에 있는 패킷이 그 첫 번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상
• 한마디로, 앞전의 요청이 밀리면 뒤도 밀림

2.5 무거운 헤더 구조

• 쿠기 등 많은 메타데이터가 들어 있고 압축이 잘 되지 않아 네트워크 성능 저하 발생

3. HTTP/2

• SPDY 프로토콜에서 파생된 HTTP/1.x보다 지연 시간 줄이고 응답 속도 더 빠르게 함

3.1 멀티플렉싱

• 여러 개의 스트림을 사용하여 송수신하여 HOL Blocking 문제 해결
  • 스트림이란?
    • 시간이 지남에 따라 사용할 수 있게 되는 일련의 데이터 요소를 가리키는 데이터 흐름
    • 즉, 여러 요청을 동시에 하나의 연결 안에서 처리함

• 병렬 스트림을 사용하여 데이터를 서빙함
• 스트림 내의 데이터가 독립된 프레임으로 쪼개져, 서로 송수신한 이후 다시 조립하여 데이터를 주고 받음

3.2 서버 푸시

• 클라이언트 요청 없이도 서버가 바로 리소스를 푸시할 수 있음
• CSS, JS 같은 파일들을 미리 푸시함으로써 초기 페이딩 로드 시간을 단축할 수 있음
  • 서버에서 html을 완성한 후 클라이언트로 전송하는 SSR의 부모격 (서버 푸시 ≠ SSR)

3.3 헤더 압축

• 허프만 코딩 압축 알고리즘을 사용하는 H PACK 압축 형식을 사용 → HTTP/1.1의 무거운 헤드 개선
• 중복된 헤더를 압축하여 네트워크 효율 개선

허프만 코딩

• 문자열을 문자 단위로 쪼개어 빈도수에 따른 비트 수를 표현함으로써 전체 비트양을 줄이는 기법
  • 빈도수가 높은 정보 : 적은 비트 수 사용
  • 빈도수가 낮은 정보 : 많은 비트 수 사용

4. HTTPS(HTTP Secure)

• HTTP/2는 HTTPS 위에서 동작함
• 신뢰 계층인 SSL/TLS 계층을 넣은 HTTP 요청 → 통신 암호화
• 한마디로 보안 제공하는 HTTP 프로토콜

4.1 SSL/TLS

• 전송 계층에서 보안을 제공하는 프로토콜
• 네트워크 인터셉트 방지 : 제 3자가 통신 내용을 가로채거나 데이터를 변조하려는 시도를 차단함

인터셉터 : 공격자가 서버인 척 사용자 정보를 가로채는 현상

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

보안 세션

• 세션이란?
  • 운영체제가 사용자로부터 응용 프로그램 등 자산 이용을 허락하는 일정 기간
• 보안이 시작되고 끝나는 동안 유지되는 세션
• SSL/TLS는 핸드셰이크를 통해 보안 세션을 생성하고 이를 기반으로 상태 정보 등을 공유

TLS의 핸드셰이크

• 클라이언트와 서버가 데이터를 주고 받기 전, 서로를 확인하는 과정
  • 둘은 “어떻게 대화를 암호화할까?”를 먼저 정함

1. ClientHello
   • 클라이언트에서 사용할 수 있는 암호화 방법 목록(사이퍼 슈트)을 서버로 보냄
   • 또한, 비밀 키를 만들기 위한 일부 정보를 제공
2. ServerHello
   • 클라이언트에게 받은 사이퍼 슈트 중 하나를 선택해 비밀키를 만들기 위한 정보를 다시 클라이언트에게 보냄
   • 여기서 양쪽이 사용할 암호화 방법이 결정됨
3. 인증 과정
   • 서버가 클라이언트에게 인증서를 보냄
   • 클라이언트는 해당 인증서가 진짜인지 확인함
4. 비밀 키 공유
   • 클라이언트와 서버가 서로의 암호화된 비밀키를 공유함
   • 이때부터 비밀 키를 사용해 암호화해서 통신할 준비가 됨
5. 대화 시작 : 서로의 비밀 키를 가지고 암호화 된 송수신이 시작됨

💡 1-RTT(최초의 왕복 시간 : 1~3번)가 생긴 후, 비밀 키를 공유하여 암호화된 데이터로 통신함

사이퍼슈트(Cipher Suite)

• SSL/TLS 통신에서 사용하는 암호화 알고리즘들의 조합이야.
  • 그니까 클라이언트와 서버가 서로 데이터 주고받을 때, 암호화 어떻게 정할지 정하는 규칙들임
  • 프로토콜 + AEAD 사이퍼 모드 + 해싱 알고리즘
• 종류
  • TLSAES_128_GCMSHA256
  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256
  • TLS_AES_128_CCM_SHA256
  • TLS_AES_128_CCM_8_SHA25

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

• 암호화와 인증을 동시에 처리하는 암호화 방식
• 데이터 암호화 뿐 아니라, 그 데이터가 중간에서 변경되거나 해킹되지 않았는지 확인하는 역할도 수행함
• AES_128_CCM이나 CHACHA20_POLY1305 같은 모드가 있음

인증 메커니즘

• SSL/TLS에서 서버의 신원을 검증하기 위해 인증서가 필요하고 이 과정은 인증 기관(CA)을 통해 이루어짐
• CA(인증기관) : 인터넷에서 신뢰할 수 있는 회사
  • e.g.) Comodo, GoDaddy, Amazon
• 인증서 : 서버가 진짜임을 증명해주는 디지털 서류
  • 서버에 대한 정보, 공개키, 서명이 들어있음
  • 공개키는 서버와 안전하게 대화하기 위한 키. 문자 그대로 공개되어 있음.

CA 발급 과정

1. 서버가 CA에 요청 : 서버는 자신의 정보와 공개키를 CA에게 보내 인증서를 요구함
2. CA가 검증 : CA는 공개키를 CA의 비밀 키 등을 기반으로 인증서를 발급함
3. 서버가 인증서 설치 : 서버에 인증서를 설치해 클라이언트와 신뢰성 있는 통신이 가능해짐

암호화 알고리즘

• 키 교환 알고리즘으로 대수곡선 기반의 ECDHE 또는 모듈식 기반의 DHE를 사용함
• 둘다 디피-헬만 키 교환 암호화 알고리즘 방식을 근간으로 만들어짐

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

• 암호화 키를 교환하는 방법 중 하나
• 다음 공식에 기반을 둔 이론인데, 한마디로 결과값을 안다고해서 변수를 알아내는 것은 어렵다는 이론
• 그니까 공개값을 공유해도 안전하게 암호화 키 만들고 송수신 가능하다고

디피-헬만 키 교환 알고리즘에서 암호키 생성하는 과정

1. 공개 값 공유
   • 클라이언트와 서버가 공개 값을 서로 주고 받음
2. 각자의 비밀 값과 혼합
   • 서로 받은 공개 값 + 자신의 비밀 값
3. 다시 공유
   • 혼합한 값을 서로 주고 받음
4. 비밀 키 생성
   • 혼합 값 + 자신의 비밀 값
   • 공동의 비밀 키(암호화 키)인 PSK를 갖게 됨
   • 이렇게 생성된 암호화 키로 송수신함

💡PSK = 각자의 공개 값 + 상대의 비밀 값 + 각자의 비밀 값
즉, 개인키나 공개키를 가져도 PSK가 없다면 아무것도 할 수 없다!

해싱 알고리즘

• 데이터를 작은 조각으로 바꿔서 그 데이터가 바뀌었는지 아닌지 확인하는 알고리즘
• 데이터를 해시값으로 변환하여 해시 값의 변환 여부로 데이터를 관리하고 비교함
  • 해시값 : 데이터를 특정한 길이의 값으로 변환한 값

SHA-256 알고리즘

• SHA-256은 데이터가 변조되지 않았는지 확인하는 대표적인 해싱 알고리즘
• 256 비트 길이의 고유한 값으로 바꿈
  • 원본 데이터의 길이에 무관하게 무조건 256 비트 길이의 숫자로 변환됨..!! ㅇ0ㅇ
• 해싱을 해야 할 메세지에 1을 추가하는 등 전처리를 하고 전처리된 메세지를 기반으로 해시를 반환함
• 주로 데이터 무결성을 확인하는 데 사용됨
  • 블록 체인에서 많이 사용함

SHA-256 알고리즘 예시

• 08cc3029b838d4be3ed53ffe3bab5be2c2d44526218d365bfdfd15673e27831f 이 나오면 사진의 메세지가 아니라고 판단함

💡 HTTPS는 암호화와 데이터 무결성을 제공하며, 이를 위해 TLS 핸드셰이크, 사이퍼 슈트, 디피-헬만 키 교환, SHA-256 해싱 같은 기술들이 사용됨.
한마디로, HTTPS는 신뢰할 수 있는 안전한 통신을 보장함

4.2 SEO에도 도움이 되는 HTTPS

구글은 SSL 인증서를 강조해옴

또, 사이트 내 모든 요소가 동일하다면 HTTPS 서비스를 하는 사이트가 그렇지 않은 사이트보다 SEO 순위가 높을 것이라고 공식적으로 밝힘

SEO(Search Engine Optimiztion)

• 검색 엔진 최적화
• 사용자들이 검색엔진으로 웹 사이트 검색했을 때, 페이지 상단에 노출시키는 최적화 방법
• SEO를 관리하는 방법에는 캐노니컬 설정, 메타 설정, 페이지 속도 개선, 사이트 맵 관리 등이 있음

캐노니컬 설정

• HTTPS 전환 시 중복된 페이지 문제를 해결하기 위해 캐노니컬 태그를 설정함
• 동일한 페이지의 여러 버전 중 하나의 URL을 대표로 설정해 검색엔진이 이를 인식하게 함

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

메타 설정

애플의 사이트

• HTTPS로 전환할 때 메타 태그에서 적절한 설정이 필요함
• robots.txt나 메타 로봇 태그를 설정해 검색 엔진이 HTTPS 버전을 크롤링하게 함

페이지 속도 개선

• 구글의 PageSpeedInsights로 가서 자신의 서비스에 대한 리포팅을 주기적으로 받으며 관리해야함

사이트맵 관리

• 다음과 같은 형식의 xml 파일

<?xml version="1.0" encoding="utf-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>http://kundol.co.kr/</loc>
<lastmod>수정날짜</lastmod>
<changefreq>daily</changefreq>
<priority>1.1</priority>
</url> 
</urlset>

• HTTPS로 전환하면 사이트맵에 포함된 모든 URL을 HTTPS로 업데이트해야 함
• 이를 통해 검색 엔진이 HTTPS 사이트를 빠르게 인덱싱할 수 있게 됨

4.3 HTTPS 구축 방법

HTTPS를 구축하는 방법은 크게 3가지이다.

• 직접 CA에서 구매한 인증키를 기반으로 HTTPS 서비스 구축
• 서버 앞단의 HTTPS를 제공하는 로드밸런서를 둠
  • 로드밸런서 : 여러 서버들 앞에서 트래픽을 나눠주는 역할
  • 로드밸런서가 HTTPS 연결을 대신 해주고, 서버는 그 뒤에서 안전하게 데이터를 처리함
  • 즉, 로드밸런서가 서버 대신 HTTPS를 제공해주기 때문에 서버에 직접 설치할 필요 x
• 서버 앞단에 HTTPS를 제공하는 CDN을 둬서 구축
  • CDN : 웹 사이트의 이미지, 동영상 같은 파일을 전 세계 여러 곳에 빠르게 보내주는 서비스
  • 어디서든 빠르게 웹사이트에 접속 가능함
  • 자동으로 HTTPS를 제공해주기 때문에, 서버에 HTTPS를 따로 설치할 필요 x
    • e.g. ) AWS CloundFront

그러니까, HTTPS 서비스를 배포하려면 다음과 같은 인프라 아키텍처 전략을 쓸 수 있을 것 같음

1. 사용자 → CDN (HTTPS 제공) → 2. 로드밸런서 → 3. 웹 서버 → 4. 백엔드 서버 → 5. 데이터베이스 서버

5. HTTP/3

• TCP 위에서 돌아가는 HTTP/2와 달리 QUIC 계층 위에서 돌아감
  • QUIC계층
    • OSI 7 Layer의 4계층(전송계층)에 해당됨
    • 전통적인 TCP를 대체하기 위해 설계된 프로토콜
• TCP 기반이 아닌 UDP 기반으로 돌아가서 상대적으로 빠른 속도
• HTTP/2의 멀티플렉싱 장점을 유지하여 초기 연결 설정 시 지연 시간을 감소하는 장점이 있음

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

• TCP 사용하지 않기 때문에, 3-웨이 핸드셰이크 과정 거치지 않아도 됨
  

• 첫 연결 설정에서 1-RTT만 소요됨
  • 클라이언트와 서버가 각각 한번 응답하면 통신이 시작됨
• 순방향 오류 수정 메커니즘이 적용되어 패킷 손실률을 낮춤
  • 순방향 오류 수정 메커니즘
    • 데이터를 보내기 전, 미리 여러 정보를 덧붙혀서 보내는 방식
    • 전송 중에 패킷이 손실되거나 깨져도 미리 보낸 정보를 기반으로 데이터를 복구할 수 있음
    • 데이터를 재전송하지 않고도 복구할 수 있어 효율적인 통신이 가능함

💡 HTTPS는 보안 강화와 SEO에도 유리하며 다양한 방법으로 구축 가능함
HTTP/3는 QUIC 기반으로 빠른 연결과 패킷 손실 복구를 제공해 성능을 크게 향상시킴