HTTP & HTTPS

HTTP란 Hyper Text Transfer Protocol 즉, 하이퍼텍스트 전송 규약이다.
데이터를 주고 받음에 있어 약속된 형식이다. 'ㅇ'를 보고 이게 0인지 이응인지 알파벳 O인지 구분 해야하듯이 HTTP로 그 형식을 구분한다.

HTTPS의 S는 Secure약자 이다. 여기서 알 수 있듯이, 일반적으로 HTTP 프로토콜의 문제점은 서버로부터 브라우저로 전송되는 정보가 암호화 되지 않는다는 점이 있다.
이 말은 쉽게 정보가 노출될 수 있다는 의미이다.
또한 접속하는 서버가 진짜 해당 서버인지 검증을 하는 방법이 없다.

그렇기에 HTTPS 프로토콜은 SSL(보안 소켓 계층)을 사용함으로써 보안을 유지할 수 있게 되었다.
또한 먼저 간단하게 언급하자면, HTTP는 해당 사이트가 믿을 만한 사이트인지 검증을 해주기도 하다.
=> 안전하다.

SSL 이란?

• SSL(Secure Sockets Layer)은 인터넷으로 전송된 데이터의 인증, 암호화, 암호 해독을 가능하게 하는 웹브라우저와 서버의 프로토콜. ( 쉽게 말해 암호화 기반 인터넷 프로토콜)
• 두 장치 사이 handshake 인증 프로세스로 두 장치 ID확인.
• 데이터 디지털 서명으로 데이터 송수신 과정의 무결성 보장.

HTTP 1/ 1.x / 2 / 3 의 차이는?

* HTTP 1
기본적으로 한 연결당 하나의 요청 처리를 합니다.
HTTP는 TCP연결을 하기에 한 연결 당 하나의 요청 처리를 한다고 생각한다면 매 요청마다 3way handshake를 처리해야 합니다. 이는 RTT 즉 패킷의 왕복 시간에 큰 영향을 미칠 것입니다.
이를 위해 세가지의 RTT감축 방법이 고안되었습니다.

이미지 스플리팅
코드압축
base64인코딩 이미지 스플리팅이란 이미지를 하나 하나씩 두어서 각각 다운받게 하는 것이 아닌, 하나의 이미지에 이미지들을 박아두어서 그 이미지만 다운 받고 위치를 조정해서 각각 해당하는 이미지들을 사용하는 방법입니다. 코드 압축이란 우리가 낭비적으로 개행문자나 스페이스 바를 할 수있기에 이를 아예 없애버려 코드 용량을 줄이는 방식입니다. base64인코딩이란 이미지를 html에 박는 방법 즉 이미지를 다운 받는 것이 아닌, 64진법으로 인코딩하고 그 결과를 이미지 소스에 넣어 이미지를 가져오는 방법입니다.

하지만 이러한 노력에도 아직 해결되지않는 점들이 있었습니다. 그 중 하나가 바로 TCP연결 문제. 앞서 말했듯 하나의 연결은 하나의 요청만 응답하고 사라집니다. 이를 해결하기 위해 keep alive가 표준화 되었습니다. 즉 한 번 TCP연결을 한 후 초기화하여 여러개의 파일을 송수신 할 수 있게 되었습니다.

http2가됨으로써 해결한 문제들을 무엇인가?
먼저 실행 문제. 쉽게 말하면 같은 큐의 패킷에서 앞선 패킷 요청을 처리할때 그 파일 응답시간이 오래걸린다면 뒤에 요청들은 밀리게 됩니다. 비유하자면 즉 운영체제가 비선점형이라 가정했을때 하나의 프로세스가 스케쥴링에서 독점하고 있는 상황입니다. 이를 위해 멀티
플랙싱이 고안되었습니다. 여러개의 스트림으로 송수신을 관리 합니다. 동시에 전부 실행하기에 하나가 지연되어도 다른 패킷에는 영향을 주지 않습니다. 다음으론 헤더 문제 1.x의 헤더는 크기가 컸습니다.
이를 압축하기 위해 허프만 알고리즘 즉 빈도가 높은 정보는 적은 비트, 빈도가 낮은 정보는 많은 비트를 할당해 전체 비트 수를 줄이는 방식입니다.

다음으론 서버 푸시.
즉 클라이언트가 요청을 해야만 서버가 응답을 했으나 이젠 클라이언트가 요청을 하지않아도 예를 들어 html을 파싱하는 과정에서 css가 발견된다면 이를 서버에 푸시하여 클라이언트에 먼저 줄 수 있게 되었습니다.
이렇게 보완된 내용들로 http2가 탄생합니다. 조금 더 나아가 http3가 나오게 됩니다.
http3는 TCP가 아닌, QUIC이라는 계층 위에서 돌아갑니다. 이는 UDP기반으로 TCP의 세번의 RTT보다 적은 한번의 RTT로 충분합니다. http2의 모든 장점을 갖으며 더욱이 초기 연결 설정 시 한번의 RTT만을 사용해도 되기에 큰 장점을 가집니다. 특징? 1. 클라이언트 - 서버 구조.
클라이언트의 단방향 통신
클라이언트는 요청을, 서버는 응답을 한다.

2. stateless 프로토콜
stateless 즉 무상태 프로토콜이다.
이는 클라이언트와 통신을 하면 그 정보를 기억하지 않는다. 기억을 한다면 비용이 클 것이기 때문.
그렇기에 토큰 , 쿠키와 세션 으로 보완함(이전 포스팅 참고)
이는 어떠한 서버도 응답을 할 수있기에 서버 장애에 대응이 좋고, 확장에 유리하다.

3. 비연결성
빠른 응답 가능.
실제로 요청을 주고 받고 할때만 연결이 유지된다. 응답을 주고 나면 끊김. (최소한의 자원으로 서버 유지)끊기면 새롭게 3way handshake필요.
-> keep alive로 극복
응답을 주고 나서도 연결. 주기적으로 패킷을 보냄. 허나 응답이 계속없다면 연결 종료.
어떤 원리 ?
대칭키 / 비대칭키(공개키)

대칭키
문자 + 어떤 알고리즘 = 전혀 알수 없는 암호문

내 클라이언트와 서버에 동일한 어떤 알고리즘(키)를 알고 있다면 클라이언트와 서버만 무엇인지 복호화 할 수 있을 것이다. (중간에 누가 훔쳐보더라도 문제없음.)
어떻게 이 동일한 키를 양쪽이 공유하는가?
=> 그 알고리즘을 한번즘은 클라이언트에 알려주는 과정이 필요하게 된다. 이는 문제 발생.

이를 보완하기 위해 '비대칭키' 가 고안되었다.
공개키와 개인키를 구분합니다.
공개키는 대중들의 클라이언트에 뿌립니다. 공개키만으로 공개키를 해석할 순 없을것입니다.
그리고 개인키는 서버만 갖고 있습니다.
이제 사용자는 공개키를 서버에 보냅니다. 그리고 서버는 공개키를 받아 개인 키로 해석해서 데이터를 다시 보내줍니다.

그렇다면 이 사이트를 어떻게 증명하는 지 소개 해보겠습니다.
해당 사이트에서 우리에게 보내는 정보 일부는 해당 사이트 개인키로 암호화 되어있습니다.
우리가 공개키로 풀 수 있는 암호는 해당 사이트의 개인키로 암호화 된 것 뿐일 겁니다.
신뢰할 수 있는 기관(CA)에서 우리의 클라이언트에 해당 사이트의 공개키임을 인증 해준다면 우리는 이걸 기준으로 안전하게 사이트 사용이 가능하다. CA는 우리의 브라우저에 내장되어있다.

좀 더 자세히는,
우리 클라이언트는 서버를 믿을 수 없습니다. 그렇기에 데이터를 주고 받을 사이트와 먼저 handshaking을 합니다.(무작위 데이터) 그 과정에서 우리는 해당사이트의 인증서를 받습니다.
인증서를 우리는 받고 이를 CA의 공개키로 해독을 해보고자 시도합니다. 이 때 복호화가 성사 된다면 CA에 등록된 사이트로 안전한 사이트라는 뜻입니다.

그 후 서버와 클라이언트는 비대칭키와 대칭키의 방식을 혼합해서 데이터를 주고 받습니다.
물론 모든 데이터를 비대칭키로 주고 받으면 좋지만, 모든 데이터를 일일이 비대칭키로 주고 받으면 일일이 암호화 복호화를 해야하기 때문에 컴퓨터에 부담이 커집니다. 악수할 때 생성된 임시 데이터들을 혼합해서 임의의 키를 만듭니다. 이 임시 키는 서버의 공개키로 암호화 되서 서버로 보내진 다음, 양쪽에서 일련의 과정을 거쳐서 동일한 대칭키를 만듭니다. 이 때 이 대칭키는 서버와 클라이언트만 갖고 있기에 안전 합니다.