면접을 위한 CS 전공지식 노트 정리 - 2.5 HTTP

`HTTP`: 전송 계층 위에 있는 애플리케이션 계층으로서 웹 서비스 통신에 사용

 

📌 2.5.1 HTTP/1.0

- 한 연결당 하나의 요청을 처리

-> 파일을 가져올때마다 3-way handshake를 열어야 하기에 RTT 증가 (Round Trip Time)

(`RTT`: 패킷이 목적지에 도달한 뒤 다시 출발지로 돌아오기까지 걸리는 시간, `패킷 왕복 시간`)

 

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

- 이미지 스플리팅, 코드 압축, 이미지 Base64 인코딩 사용

1) 이미지 스플리팅

- `이미지가 합쳐진 하나의 이미지`를 다운로드 받고, 이를 기반으로 이미지 표기

2) 코드 압축

- `코드를 압축`하여 개행 문자, 빈칸을 없애 코드의 크기를 최소화

3) 이미지 Base64 인코딩

- 이미지 파일을 `64진법으로 이루어진 문자열`로 인코딩

- 서버와의 연결을 열고 서버에 HTTP 요청할 필요 없음

 

📌 2.5.2 HTTP/1.1

- 매번 TCP 연결할 필요 없이, `한 번의 TCP 초기화 후 여러 개의 파일을 송수신`

- 그러나 문서 내 다수의 리소스를 처리하려면 `요청 리소스 개수에 비례하여 대기 시간`이 길어짐

 

`HOL Blocking`

- 네트워크에서 같은 큐에 있는 패킷이 첫 번째 패킷에 의해 지연될 때 발생하는 `성능 저하 현상`

ex) 맨 앞의 image.jpg 파일이 느리게 받아져 그 뒤 파일들이 대기하게 됨!

 

`무거운 헤더 구조`

- HTTP/1.1 헤더에는 많은 메타데이터가 들어 있어 압축되지 않아 무거움

 

📌 2.5.3 HTTP/2

- SPDY 프로토콜에서 파생

- HTTP/1.x보다 지연 시간을 줄이고 응답 시간을 빠르게 함

- 멀티플렉싱, 헤더 압축, 서버 푸시, 요청의 우선순위 처리 지원

 

`멀티플렉싱`

- 여러 스트림을 사용하여 송수신 (`스트림`: 일련의 데이터 요소를 가리키는 데이터 흐름)

- 특정 스트림 패킷이 손상돼도 다른 스트림 동작

- 단일 연결을 통해 `병렬`로 여러 요청을 받고 응답을 줄 수 있음 (HOL Blocking 해결!!)

 

`헤더 압축`

- 허프만 코딩 압축 알고리즘으로 헤더 압축

- `허프만 코딩`: 빈도가 높은 정보는 적은 비트 수, 빈도가 낮은 정보는 많은 비트 수로 표현

 

`서버 푸시`

- 클라이언트 요청 `없이` 서버가 바로 리소스를 푸시할 수 있음

 

📌 2.5.4 HTTPS

- HTTP/2는 HTTPS 위에서 동작

- `HTTPS`: 애플리케이션 계층과 전송 계층 사이에 신뢰 계층인 `SSL/TLS` 계층을 넣은 HTTP 요청

-> 통신을 암호화

 

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

- 전송 계층에서 보안을 제공하는 프로토콜

- 통신 시 제3자가 도청하거나 변조하지 못하도록 함

- 보안 세션을 기반으로 데이터를 암호화

- 보안 세션이 만들어질 때 인증 메커니즘, 키 교환 암호화 알고리즘, 해싱 알고리즘이 사용됨

 

`보안 세션`

- 보안이 시작되고 끝나는 동안 유지되는 세션

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

- 클라이언트와 서버가 서버와 키를 공유하고 인증, 인증 확인 등의 작업이 일어나는 단 한 번의 1-RTT 이후 데이터를 송수신 함

- 클라이언트에서 사이퍼 슈트를 서버에 전달하면 서버는 받은 사이퍼 슈트의 암호화 알고리즘 리스트를 제공할 수 있는지 확인 후 클라이언트로 인증서를 보내는 인증 메커니즘 시작

- 이후 해싱 알고리즘 등으로 암호화된 데이터 송수신 시작

 

`사이퍼 슈트`

- 프로토콜, AEAD 사이퍼 모드, 해싱 알고리즘이 나열된 `규약`으로 5가지가 있음

 

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

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

- 처음에 공개 값을 공유하고 각자의 비밀 값과 혼합한 후 혼합 값을 공유, 그 뒤 각자의 비밀 값과 또 혼합 -> 공통의 암호키

 

`해싱 알고리즘`

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

- `SHA-256 알고리즘이 많이 쓰임

- 해싱해야 할 메시지에 1을 추가하는 등의 전처리 후 해시 반환

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

- `해싱`: 임의의 데이터를 해시로 바꿔주는 일

 

SEO에도 도움이 되는 HTTPS

- 사이트 내 모든 요소가 동일하다면 HTTPS 서비스 사이트가 SEO 순위가 높을 것

- `SEO` (search engine optimization): 검색엔진 최적화

-> 검색엔진으로 `웹 사이트를 검색했을 때 결과를 페이지 상단에 노출시켜 많은 사람들이 보도록 최적화`하는 방법

- 따라서 서비스를 운영한다면 SEO 관리는 필수적

- 이를 위한 방법으로는 캐노니컬 설정, 메타 설정, 페이지 속도 개선, 사이트맵 관리 등이 있음

 

HTTPS 구축 방법

1) 직접 CA에서 구매한 인증키를 기반으로 HTTPS 서비스 구축

2) 서버 앞단의 HTTPS를 제공하는 로드밸런스 두어 구축 

3) 서버 앞단에 HTTPS를 제공하는 CDN을 두어 구축

 

📌 2.5.5 HTTP/3

- TCP 위에서 돌아가는 HTTP/2와는 달리 3은 QUIC이라는 계층 위에서 돌아감

+ TCP 기반 대신 `UDP` 기반으로 돌아감

- 멀티플렉싱, 초기 연결 설정 시 지연 시간 감소

 

초기 연결 설정 시 지연 시간 감소 (QUIC에 대한 설명)

- QUIC은 TCP 대신 UDP를 사용하기에 시작 시 3-웨이 핸드쉐이크 과정을 거치지 않아도 됨

- 첫 연결 설정에 1-RTT만 소요 (클라이언트가 서버에 신호 + 서버가 응답 -> 바로 통신 시작)

- 순방향 오류 수정(FEC, Forword  Error Correction) 메커니즘이 적용

- 전송한 패킷 손실 시 수신 측에서 에러를 검출하고 수정 -> 낮은 패킷 손실률

 

 

📌 요약

`HTTP/1.0`

• 특징: 한 연결당 하나의 요청 처리.
• 문제점: 파일 가져올 때마다 3-way handshake 필요 -> RTT 증가.
• 해결 방법: 이미지 스플리팅, 코드 압축, 이미지 Base64 인코딩.

`HTTP/1.1`

• 특징: 한 번의 TCP 연결로 여러 파일 송수신.
• 문제점: 요청 리소스 개수에 비례하여 대기 시간 증가, HOL Blocking, 무거운 헤더 구조.

`HTTP/2`

• 특징: SPDY 프로토콜에서 파생, 지연 시간 줄이고 응답 시간 빠르게.
• 기술:
  • 멀티플렉싱: 단일 연결로 병렬 요청/응답, HOL Blocking 해결.
  • 헤더 압축: 허프만 코딩 사용.
  • 서버 푸시: 클라이언트 요청 없이 서버가 리소스 푸시 가능.

`HTTPS`

• 특징: HTTP/2는 HTTPS 위에서 동작, SSL/TLS로 통신 암호화.
• SSL/TLS:
  • 보안 세션: 단 한 번의 1-RTT 후 데이터 송수신.
  • 사이퍼 슈트: 프로토콜, 암호화, 해싱 알고리즘 규약.
  • 디피-헬만 키 교환: 공개 값을 공유해 공통의 암호키 생성.
  • 해싱 알고리즘: SHA-256 등.
• SEO 장점: HTTPS 사이트가 SEO 순위 높음.
• 구축 방법: CA 인증키 구매, HTTPS 로드밸런스, HTTPS CDN.

`HTTP/3`

• 특징: QUIC 계층 위에서 돌아감, UDP 기반.
• 장점:
  • 지연 시간 감소: 초기 연결 시 1-RTT 소요.
  • FEC 메커니즘: 낮은 패킷 손실률.