막연하게 암호화헤 따른 비용 때문에 HTTPS가 더 느릴 것이라고 생각했다.
하지만 이번에 스터디 준비를 하면서 새로운 내용을 배우게 돼서 공유한다.
암호화가 정말로 느릴까?
지난 2010년 이후로 HTTPS 암호화에 쓰이는 TLS는 크게 변하지 않았지만, 클라이언트와 서버에서 쓰는 CPU와 메모리의 성능이 매우 크게 개선됐다.
실제로 여러 회사에서 TLS에 따른 암호화 비용이 크지 않다는 이야기를 한다.
구글에서 작성한 위 글을 보면
SSL/TLS is not computationally expensive any more(ssl은 더이상 값비싼 연산이 필요하지 않다)
라는 내용도 있다.
대용량 파일에서는 어떨까?
대용량 파일의 경우, HTTPS 전송에 따른 부하를 우려해서 파일 자체는 HTTP 요청으로 보내고 파일에 대한 해시값만 HTTPS 로 보내는 방식을 고려하기도 한다고 한다.
대부분의 서버는 아무리 커봐야 10Gbps 수준의 백본에 연결되어 있습니다. (더 큰 백본에 연결돼있는 서버가 있을 수도 있겠지만 10Gbps 백본을 쓴다는 것 부터가 이미 성공한 서비스라는 것을 나타내는 지표죠) 여기서 의미하는 것은 대용량 파일을 클라이언트에게 전송하기 이전에 HDD의 파일 읽는 속도가 네트워크 대역폭을 따라가지 못하며 혹시나 따라갈 수 있는 시스템을 구축해두었더라 해도 네트워크 대역폭이 같은 시간동안 CPU가 처리할 수 있는 암호화 속도를 따라갈 수가 없습니다. (출처 =HTTPS는 HTTP보다 빠르다)
결국, HDD파일 읽는 속도가 네트워크 대역폭을 따라가지 못하고, 네트워크 대역폭은 CPU 암호 처리 속도를 따라갈 수 없다는 말이다.
장비가 워낙 좋아진 덕분에, HDD나 네트워크 대역폭 성능이 CPU 성능을 따라가지도 못한다는 말이다.
또한, 위 방식은 TCP 연결을 두번이나 해야 한다. HTTP와 HTTPS 프로토콜이 다른 탓이다.
양측에서 연결을 만들어야 하니 TCP 연결이 4개가 되고, HTTPS만으로 서빙하는 것보다 더 많은 RTT가 필요해진다.
개인정보가 없다면 HTTP를 적용해도 괜찮을까?
DNS는개발 당시에 보안을 크게 고려하지 않았다고 한다. 도메인을 요청하면 IP를 보내줘에 맞춰서만 개발됐다.
대부분의 국가는 DPI를 통해서 인터넷 검열을 한다(deep packet inspection). 암호화되지 않은 HTTP 통신을 가로채 Host 헤더를 보고, 차단 여부를 판별하는 방식을 많이 쓴다.
결국 사용자가 어느 사이트에 접속하는지 어떤 행동을 하는지 감시할 수 있으며, 어떤 사용자가 a라는 사이트에 도메인 요청을 보냈고 거시서 뭘하는지 볼 수 있다.
로그인 페이지를 들어간다고 할 때(HTTPS가 아니라고 해보자)
해커가 중간 페이지를가로채서 가짜 로그인 페이지로 이동시킬 수 있다.
결론은 다음과 같다.
- 현대 장비에선 HTTP와 HTTPS간의 성능 차이는 그렇게 크지 않다.
- 대용량 파일을 HTTPS와 HTTP로 나눠서 보내면 오히려 성능이 떨어질 수 있다
- 개인정보가 포함되지 않은 페이지도 해커의 공격을 피하려면 HTTPS를 사용하는 게 좋다.
