[HTTP2 In Action] 1. http의 역사와 https

 

해당 서적으로 스터디를 시작한지 2주가 되어간다.

잊지 않기 위해 기록한다.

 

들어가기 전에!!

리소스는 무엇인가?

웹의 리소스는 인터넷상에서 고유하게 식별되고 액세스할 수 있는 모든 콘텐츠나 서비스를 의미한다.

이 리소스에 고유하게 접근할 수 있는 식별자를 URI 라고 부르는데

URN 과 URL 모두 URI 이다.

요즘엔 URL 과 URI 를 혼용해서 쓰기도 한다.

HTTP 는 무엇인가?

HTTP 는 이름대로 하이퍼텍스트를 전송하기 위한 프로토콜이지만 다른 미디어들도 전송할 수 있다.

따라서 사실상 HTTP 는 웹에서 데이터를 주고받기 위한 프로토콜이다.

요청-응답 구조로 stateless 하다.

 

HTTP 는 TCP/IP 가 제공하는 안정적인 네트워크 연결에 의존하는데

 

TCP/IP 는 OSI 모델의 여러 계층(둘 에서 세 개의 계층) 에 걸쳐있다. 

 

OSI 7계층?

 

 

 

HTTP 의 역사

기존 HTTP 통신은 매우 단순했다. 

 

이미지를 불러온다던가 다른 미디어를 보낼 수 없었다.

 

사용자가 늘어나고 다양한 요구 사항이 생김에 따라

 

HTTP는 발전해갔다.

 

HTTP 0.9

짧은 길이의 사양 문서를 가지고 있었는데

 

TCP/IP 를 통해 서버와 선택적인 포트로 맺어짐을 지정한다.

 

메소드는 GET 뿐이다.

 

문서 주소는 공백 문자 없어야 한다.

 

또한 메세지는 서버의 연결 종료로 끝나야 한다.

 

따라서 0.9 로 요청을 보내고 응답을 받으면 연결이 종료된다.

 

오류 응답은 HTML 문법으로 된 사람이 읽을 수 있는 텍스트로 제공된다.

 

그리고 요청은 멱등이며 요청에 대해 어떤 정보도 서버는 저장할 필요 없다. (stateless)

 

HTTP 1.0

드디어 HTTP 1.0 이 되며 텍스트만 받던 0.9 에서 미디어나 더 많은 것들을 GET 메서드로 받아올 수 있게 되었고

 

헤더가 추가되는 큰 변경이 생겼다.

 

이 추가된 헤더로 인해 리소스가 변경될 때만 가져오게 하는 조건 GET을 가능하게 했다.

 

또한 POST 와 HEAD 메소드가 생겼다.

 

HEAD 는 리소스 자체를 다운받지 않고 메타 정보 (헤더라던가) 만 가져올 수 있는 요청이며, 

 

POST는 클라이언트가 서버에게 데이터를 가시적이지 않게 보낼 수 있도록 한다. 

 

 

HTTP 1.1

1.0 을 더 개량한 버전이다.

 

1.1 은 버전 네이밍에서도 보이듯 큰 변화라기 보다는 약간의 개선 버전이다.

 

Cache-Control 헤더를 통해 기존에 있던 캐싱 방법을 더 개선해 브라우저의 캐시에 리소스를 저장해서

 

필요할 때 재사용하도록 클라이언트에게 지시할 수 있고

 

다른 추가 사항들로는 쿠키, 프록시, 인증,새로운 상태 코드와 후행 헤더가 있다.

 

 

이 중 눈여겨 볼 헤더가 있는데 Keep-Alive 이다.

 

웹에 미디어가 여러 개의 HTTP 리소스들이 필요해짐에 따라

 

기존의 매번 연결을 맺고 끊는 방식이 낭비로 밝혀졌다.

 

이 낭비를 해결하기 위해 나온 것이 Keep-Alive 이다.

클라이언트가 서버에게 추가적인 요청 전송하는 것을 허용하고자 연결을 맺은채로 두는 것이다.

따라서 요청이 끝나자마자 다른 요청을 보낼 수 있다는 것이다.

 

이 Keep-Alive는 HTTP 1.0 사양에 없는데 많은 HTTP 1.0 서버가 지원할 정도로 1.1의 중요한 변경점이다.

하지만 1.0 과 1.1 은 여전히 요청-응답 프로토콜이며

HTTP 연결에서 요청 하나가 처리되는 동안

해당 연결은 다른 요청에서 사용할 수 없다.

 

 

 

HTTPS

기존 HTTP 통신은 일반 텍스트 프로토콜이기 때문에

 

ISP 로부터 다른 참여자의 인터넷을 통해 요청이 전달되어서

 

요청의 내용을 누구나 볼 수 있는 문제가 있었다. 

 

HTTPS 는 HTTP 통신에 전송 계층 보안 프로토콜을 사용해 암호화하는

 

HTTP 의 보안 버전이다. 

 

중요한 개념 세 가지는

 

암호화

 

메세지는 전송 중에 제 3자에게 읽힐 수 없다.

 

무결성

암호화된 메세지가 디지털 서명되고 서명이 복호화되기 전에 암호학적으로 검증되어 메세지는 전송 중에 변경되지 않는다.

 

인증

서버는 클라이언트가 메세지를 주고 받으려던 그 서버다.

 

 

HTTPS 는 공개키를 통해 암호화해서 보내면

 

(여기서 공개키가 해당 서버의 것이라는 것은 디지털 서명을 통해 알 수 있다.)

 

복호화할 수 있는 것은 서버만이 가지고 있기에 해당 내용은 서버만 볼 수 있다.

 

하지만 이 공개키 암호화 방식은 느리기 때문에

 

이후 효율적으로 소통하기 위해 공유하기 위한 공유 암호화키(대칭키) 를 협상하는데만 사용한다.

 

이후 이렇게 협상된 대칭키를 사용해 직접 암호화/복호화하여 빠르게 통신할 수 있다.

 

 

HTTPS 도 문제가 있는데

 

HTTPS 는 연결의 암호화는 보장하지만 상대방의 신뢰성은 보장하지 않는다는 점이다.

 

암호화된 연결이라도 잘못된 서버와 연결되는 것이다.

 

이를 해결하기 위해

 

EV 인증서를 사용하는 방법이 있는데

 

높은 비용과 복잡한 발급 절차와 긴 처리 시간으로 보안이 중요한 일부 업계에서만 사용한다.

 

 

 

요약

 

• 웹이 발전함에 따라 다양한 형태의 리소스를 주고 받을 일이 생겼고 이를 위해 단순한 HTTP 0.9 버전에서 발전이 이루어 졌음.
• HTTP 1.0 에 헤더가 추가되고 GET 을 통해 다양한 미디어 등을 가져올 수 있게 되었음.
• HTTP 1.1 부터 Keep-Alive 를 지원하여 매번 연결을 맺고 끊는 대기 시간이 단축되었고 이는 HTTP 1.0 에도 적용되었음.
• HTTPS는 표준 HTTP 메세지를 암호화하지만 연결의 암호화만 보장하고 상대방의 신뢰성은 보장하지 않는다.