[네트워크] HTTP

HTTP (HyperText Transfer Protocol)

웹 서비스 통신(서버와 클라이언트 간의 데이터 송수신)에 사용되는 통신 규약, 애플리케이션 계층

HTTP의 역사

HTTP/0.9 : GET 메서드만 지원, HTTP 헤더 X

HTTP/1.0 : 메서드, 헤더, 상태코드 추가

• 요청 헤더 : http 버전이 생김
• 응답 헤더 : 상태코드와 content-type이 생겨 html 파일 외 다른 타입의 파일도 전송
• 단기커넥션 (Short-lived connection) : connection 하나당 1 요청, 1 응답만 처리 가능, 매번 새로운 연결로 성능 저하 (RTT 증가) 및 서버 부하 비용 증가

RTT 개선 방법

• 이미지 스플리팅 : 한 이미지를 background - position 이라는 CSS 설정을 통해 여러 이미지로 표기하는 방법
• 코드 압축 : 개행 문자, 빈칸 없애서 크기 최소화 하는 방법
• 이미지 Base64 인코딩 : 이미지 파일을 64진법의 ASCII 문자열로 인코딩하는 방법

HTTP/1.1 : 대부분의 기능이 추가

우리가 아는 대부분의 HTTP 기능이 1.1에 구현된 것이고, 2와 3에서는 성능 개선에 초점이 맞춰져 있음

• 지속 연결 (Persistent connection) : 지정한 timeout 동안 연속적인 요청 사이에 커넥션을 닫지 않음. 기존 연결에 대해 handshake 생략
  • keep-alive : persistent connection을 하기 위해, 헤더에 명시하는 옵션
• PipeLining : 여러개의 요청을 보낼 때 처음 요청이 응답될 때까지 기다리지 않고 요청을 한꺼번에 보내서 대기 시간을 줄이는 기술.
  • Head Of Line Blocking과 같은 문제점이 많아 사장됨
  • HTTP2에서 멀티플렉싱 알고리즘으로 대체됨

 

문제점

• Head of line blocking (HOLB) : 이전 패킷을 전송하는데 지연이 발생해 패킷을 전송하지 못하는 상황
• 무거운 헤더 구조, 중복된 헤더값 -> 메모리 자원 낭비

HTTP/2 : HTTP 1.1 성능 개선 및 확장

Text 형식이었던 HTTP 메시지를 더 작은 단위인 바이너리 형태로 쪼개서 캡슐화 하여 ( : Binary Framing) 아래와 같은 기능 구현

• 멀티플렉싱 (multiplexing) : HTTP 헤더 메세지를 바이너리 형태의 프레임으로 나누고, 하나의 커넥션으로 동시에 여러개의 메세지 스트림을 응답 순서에 상관없이 주고 받는 것
  • HTTP/1.1의 Connection Keep-Alive, Pipelining, Head Of Line Blocking을 개선
  • latency 감소, 네트워크 비용 감소 

    

    frame - message - stream - connection

    
    프레임 단위로 이루어진 요청과 응답 메세지는 하나의 스트림을 통해 이루어지며, 이러한 스트림들이 하나의 커넥션 내에서 병렬적로 처리된다. 하나의 커넥션에서 여러개의 스트림이 동시에 열리니 속도가 빠를수밖에 없다.
• 헤더 압축 : HPACK 압축을 통한 헤더 중복값 개선
• 서버 푸시 : 클라이언트의 요청에 대해 필요한 리소스들을 미리 클라이언트의 캐시로 전송
• 요청의 우선순위 처리 (Stream Prioritization) : 클라이언트가 스트림에 식별자(우선순위)를 설정

문제점

• 여전히 TCP를 사용하기 때문에 handshake의 RTT로 인한 지연 시간 (Latency)이 발생
• TCP는 패킷이 유실되거나 오류가 있을 때 재전송하는데, 이 과정에서 패킷의 지연 시간 발생
• 애플리케이션 계층에서 HTTP HOLB를 해결했다 하더라도, 전송 계층에서 TCP HOLB를 해결한 것은 아님

 

HTTP/3 : TCP 대신에 UDP를 이용한 QUIC 프로토콜 사용

QUIC (Quick UDP Internet Connections)이라는 계층 위에서 돌아가며, TCP 기반이 아닌 UDP 기반으로 돌아감

기존 TCP의 고질적인 지연시간(RTT)를 해결

• 보안 세션을 설정하기 위해 한 번의 handshake만 필요 (첫 연결 설정에 1-RTT만 소요)
• QUIC 내에 TLS 인증서를 내포하고 있으며, 초기 연결 설정에서 필요한 인증 정보와 데이터를 함께 전송

최초 Connection 시

재연결 Connection 시

HTTPS (HyperText Transfer Protocol Secure)

정보를 암호화하는 SSL(Secure Socket Layer)/TLS(Transport Layer Security) 프로토콜을 이용하여 클라이언트와 서버가 데이터를 주고받는 통신 규약

 

SSL/TLS 동작 방식

• 대칭키 기법과 공개키(비대칭키) 기법을 함께 사용
• 클라이언트와 서버간 데이터를 암호화하기 위한 세션키를 교환하는 과정에서 공개키(비대칭키) 사용
• 세션키 교환 후 데이터를 교환하는 과정에서 대칭키 사용

대칭키

• 암호화와 복호화에 같은 암호 키를 쓰는 알고리즘
• 중간에 누군가 암호 키를 가로채면 암호화된 정보가 유출될 수 있는데, 이 문제를 보완한 방식이 공개키

공개키 (비대칭키)

• 암호화와 복호화에 서로 다른 키를 쓰는 알고리즘
• 개인키(private key)와 공개키(public key)를 쌍으로 이룬 형태

References

• 면접을 위한 CS 전공지식 노트 - 2.5 HTTP
• HTTP 1.1과 HTTP 2.0 비교하기
• HTTP는 무엇일까요? - 기본 핵심 요약 총정리
• [Tech Trend] 구글이 제안한 인터넷통신 표준 ‘QUIC’, TCP 대체할까
• 신입 개발자 기술면접 질문 정리 - 네트워크
• 그림으로 쉽게 보는 HTTPS, SSL, TLS