HTTP

WONNY_LOG·2023년 7월 26일

HTTP란 (Hyper Text Transfer Protocol)

인터넷에서 데이터를 주고 받을 수 있는 프로토콜(= 규칙)

HTTP 프로토콜의 특징

1. Client와 Server 구조

클라이언트가 HTTP 메세지 양식에 맞춰 요청을 보내면, 서버는 HTTP 양식에 맞춰 응답한다.

Client-Server 구조는 Request-Response 구조와 같은 것이다.
Server에서 비즈니스 로직과 데이터를 Client에 독립적으로 처리할 수 있도록 만든 구조이다.
웹 브라우저와 웹 서버의 소통을 위해 디자인 되었다

2. 무상태성(Stateless)

HTTP에서는 서버가 클라이언트 상태를 저장하지 않는다. 따라서 응답과 요청이 독립적이다.

장점 : 서버 확장성이 높다. 무상태는 응답 서버를 쉽게 바꿀 수있기 때문에 무한한 서버 증성이 가능하다.
단점 : Request를 보낼 때 Client가 추가 데이터를 전송해야한다.

3. 비연결성(Connectionless)

실제로 요청을 주고 받을 때만 연결을 유지하고, 응답을 주고나면 (TCP/IP) 연결을 끊는다.

불필요한 연결을 하지 않아, 최소한의 자원으로 서버를 유지할 수 있다.
HTTP 1.0 기준으로 HTTP는 연결을 유지하지 않는 모델이다.

HTTP/1.1 와 HTTP/2.0

HTTP/1.1

특징

기본적으로 Connection당 하나의 요청을 처리 하도록 설계
동시 전송이 불가능하고 요청과 응답이 순차적으로 이뤄짐
HTTP문서안에 포함된 다수의 리소스(Images.CSS.Script)를 처리하려면 요청할 리소스 개수에 비례해서 Latency(대기 시간)이 길어짐 => 대기시간에는 동작을 수행 할 수없음

문제점

1. Pipelining의 HOL(Heod Of Line) Blocking 문제
위같은 상황을 해결하기 위해 나온 Pipelining 모델
Client는 응답에 상관없이 요청을 보내고 Server에서는 응답을 요청이 들어온 순서대로 보낸다.
이때 Client에서 응답의 순서가 잘못되거나 중간에 빠졌다면 누락이 발생한 요청을 다시보내게된다.

Client에서는 1,2,3 요청을 보냈는데, 서버에서 처리하는데 1번은 100초 2번은 20초 3번은 10초가 소요된다고 가정할때. 1번 응답을 먼저 보내야하므로 2,3번 응답은 계속 Blocking된다.

2. 연속된 요청간에 중복된 헤더들

HTTP/2.0

특징

성능에 초점을 두어 하나의 Connection에 여러개의 메세지를 동시에 주고 받을 수있음
Multiplexed Streams: connection 한 개로 동시에 여러 개의 메시지를 주고 받을 수 있으며, 응답은 순서에 상관없이 stream으로 주고 받는다.
Stream Prioritization: 리소스 간의 의존관계에 따른 우선순위를 설정하여 리소스 로드 문제를 해결함
ex. 문서 내에 CSS파일 1개와 이미지 파일 2개가 존재하고 이를 클라리언트가 요청하는 상황에서 이미지 파일보다 CSS 파일의 수신이 늦어진다면 렌더링에 문제가 생기게 되는데 이를 해결함.
- Server Push : 클라이언트가 요청하지 않은 리소스를 서버가 사전에 푸쉬를 통해 전송할 수 있다.
  ex. 푸쉬가 가능하면 클라이언트가 추후에 HTML문서를 요청할 때 해당 문서 내의 리소스를 사전에 클라이언트에서 다운로드할 수 있도록 하여 클라이언트의 요청을 최소화할 수 있음
Header Compression : 헤더 정보를 HPACK 방식으로 압축한다.

위 그림처럼 클라이언트가 요청을 두 번 보낸다고 가정하면, HTTP1.1의 경우 헤더 중복이 발생해도 중복 전송한다. 하지만 2.0의 경우 헤더에 중복이 있는 경우 Static/Dynamic Header Table 개념을 이용하여 중복을 검출해내고, 해당 테이블에서의 index값 + 중복되지 않은 Header 정보를 Huffman Encoding 방식으로 인코딩한 데이터를 전송한다.

공개키 (비대칭키) 방식이 뭔가요?

대칭키 암호화 방식은 암복호화에 사용하는 키가 동일한 암호화 방식을 말한다.

해당 키를 아는 사람이 문서를 복호화할 수 있게 된다.
공개키 암호화 방식에 비해 연산 속도가 빠르다는 장점이 있지만, 키를 교환해야 하는 문제가 발생한다.
키를 교환하는 중 키가 탈취될 수도 있다
사용자가 증가할수록 각각의 키가 필요하기에 관리해야 할 키가 방대하게 많아진다.

=> 이러한 문제를 해결하기 위한 방법으로 키의 사전 공유, 키 배포 센터 사용, Diffie-Hellman 키 교환, 공개키 암호화 방식이 있다

공개키 암호화 방식은 암복호화에 사용하는 키가 서로 다른 암호화 방식을 말한다.

효율은 떨어지지만, 대칭키 암호화 방식의 키를 교환해야 하는 문제를 해결하기 위해 등장했다.

예시로
A가 B에게 데이터를 보낸다고 할 때, A는 B의 공개키로 데이터를 암호화해서 보내고 B는 본인의 개인키로 해당 암호화된 데이터를 복호화해서 보게 된다.
암호화된 데이터는 B의 공개키에 대응되는 개인키를 갖고 있는 B만이 볼수 있게 된다.
공개키는 키가 공개되어 있기 때문에 따로 키 교환이나 분배를 할 필요가 없게 된다. 중간 공격자가 B의 공개키를 얻는다고 해도 B의 개인키로만 복호화가 가능하다.

-> 키 전달 문제를 해결하여 더 안전하지만, 암호화와 복호화를 위해 복잡한 수학 연산을 수행하기 때문에 대칭키 알고리즘에 비해 속도가 느리다는 단점이 있다.

HTTPS와 HTTP 차이

HTTPS(https://)는 SSL(Secure Socket Layer) 인증서를 사용하는 HTTP(http://)이다.

SSL(또는 TLS) 인증서는 일반 HTTP 요청 및 응답을 암호화한다. 따라서 HTTPS는 HTTP보다 더 안전한 보안용 프로토콜이라고 할 수 있다.
HTTPS를 사용한 웹 페이지를 통해 전송되는 모든 데이터는 추가적인 보안 계층이 있다.
=> 이를 TLS(전송 계층 보안) 프로토콜이라고한다.
모든 유형의 데이터는 변경되거나 손상될 수 없는 HTTPS 사이트를 통해 전달되며 제3자로부터 보호된다.

SSL: 보안 소켓 계층(Secure Sockets Layer)

서버와 브라우저 사이에(또는 두 서버 사이) 안전하게 암호화된 연결을 만들 수 있게 도와주고 서로 민감한 정보를 주고받을 때 정보가 도난당하는 것을 막아준다.

HTTPS

공개(비 대칭)키 방식으로 대칭키를 전달하고, 서로 공유된 대칭키를 가지고 통신하게 된다.

순서
1. A는 B의 공개키로 암호화 통신에 사용할 대칭키를 암호화해서 B에게 보낸다.
2. B는 암호문을 받고 자신의 비밀키로 복호화한다.
3. B는 A로부터 얻은 대칭키로 A에게 보낼 평문을 암호화하여 A에게 보낸다.
4. A는 자신의 대칭키로 암호문을 복호화한다.
5. 앞으로 해당 대칭키로 계속 통신한다.
즉, 사용자 측에서는 대칭키 알고리즘을 통해 안전하게 키 교환을 한 후 해당 키로 대칭키 알고리즘을 통해 통신하게 된다.