hmk run dev
HTTP와 HTTPS 본문
HTTP 프로토콜은 어떻게 작동하나요?
HTTP는 OSI(Open Systems Interconnection) 네트워크 통신 모델의 애플리케이션 계층 프로토콜입니다. HTTP는 여러 유형의 요청과 응답을 정의합니다. 예를 들어, 웹 사이트의 일부 데이터를 보려는 경우 HTTP GET 요청을 전송합니다. 연락처 양식 작성과 같은 일부 정보를 전송하려는 경우 HTTP PUT 요청을 전송합니다.
마찬가지로, 서버는 숫자 코드 및 데이터 양식으로 다양한 유형의 HTTP 응답을 전송합니다. 다음은 몇 가지 예입니다.
- 200 - OK(정상)
- 400 - Bad request(잘못된 요청)
- 404 - Resource not found(리소스를 찾을 수 없음)
이러한 요청 및 응답 통신은 일반적으로 사용자에게 보이지 않습니다. 브라우저와 웹 서버가 사용하는 통신 방식이므로 World Wide Web은 모든 사용자에게 일관되게 작동합니다.
HTTPS 프로토콜은 어떻게 작동하나요?
HTTP는 암호화되지 않은 데이터를 전송합니다. 즉, 브라우저에서 전송된 정보를 제3자가 가로채고 읽을 수 있습니다. 이는 이상적인 프로세스가 아니었기 때문에, 통신에 또 다른 보안 계층을 추가하기 위해 HTTPS로 확장되었습니다.
HTTPS는 HTTP 요청 및 응답을 SSL 및 TLS 기술에 결합합니다.
HTTPS 웹 사이트는 독립된 인증 기관(CA)에서 SSL/TLS 인증서를 획득해야 합니다.
이러한 웹 사이트는 신뢰를 구축하기 위해 데이터를 교환하기 전에 브라우저와 인증서를 공유합니다.
SSL 인증서는 암호화 정보도 포함하므로 서버와 웹 브라우저는 암호화된 데이터나 스크램블된 데이터를 교환할 수 있습니다.
프로세스는 다음과 같이 작동합니다.
- 사용자 브라우저의 주소 표시줄에 https:// URL 형식을 입력하여 HTTPS 웹 사이트를 방문합니다.
- 브라우저는 서버의 SSL 인증서를 요청하여 사이트의 신뢰성을 검증하려고 시도합니다.
- 서버는 퍼블릭 키가 포함된 SSL 인증서를 회신으로 전송합니다.
- 웹 사이트의 SSL 인증서는 서버 아이덴티티를 증명합니다. 브라우저에서 인증되면, 브라우저가 퍼블릭 키를 사용하여 비밀 세션 키가 포함된 메시지를 암호화하고 전송합니다.
- 웹 서버는 개인 키를 사용하여 메시지를 해독하고 세션 키를 검색합니다. 그런 다음, 세션 키를 암호화하고 브라우저에 승인 메시지를 전송합니다.
- 이제 브라우저와 웹 서버 모두 동일한 세션 키를 사용하여 메시지를 안전하게 교환하도록 전환합니다.
HTTP/2, HTTP/3, HTTPS의 차이점은 무엇인가요?
1996~1997년에 출시된 최초의 HTTP 버전이 HTTP/1.1입니다.
HTTP/2와 HTTP/3은 프로토콜 자체를 업그레이드한 버전입니다.
데이터 전송 시스템을 수정하면서 효율성을 개선했습니다. 예를 들어, HTTP/2는 텍스트 형식 대신, 바이너리로 데이터를 교환합니다.
또한, 서버가 새 HTTP 요청을 기다리는 대신, 클라이언트 캐시에 응답을 사전에 전송할 수 있습니다. HTTP/3은 비교적 최근에 나온 버전이며, HTTP/2를 한 단계 더 발전시킨 것입니다. HTTP/3의 목표는 실시간 스트리밍 및 기타 최신 데이터 전송 요구 사항을 보다 효율적으로 지원하는 것입니다.
HTTPS는 HTTP에서 데이터 보안 문제를 우선시합니다. 최신 시스템에서는 SSL/TLS와 함께 HTTP/2를 HTTPS로 사용합니다. HTTP/3이 더욱 발전하면 브라우저 및 서버 기술도 결국 HTTPS에 통합될 것입니다.
HTTP보다 HTTPS를 선택하는 이유는 무엇인가요?
다음으로, HTTP와 비교했을 때 HTTPS의 몇 가지 장점에 대해 알아보겠습니다.
보안
HTTP 메시지는 일반 텍스트이므로, 권한이 없는 당사자가 인터넷을 통해 쉽게 액세스하고 읽을 수 있습니다. 반면,
HTTPS는 모든 데이터를 암호화된 형태로 전송합니다. 사용자가 민감한 데이터를 제출할 때 제3자가 네트워크를 통해 해당 데이터를 가로챌 수 없음을 확신할 수 있습니다. 신용카드 세부 정보 또는 고객 개인 정보와 같은 잠재적으로 민감한 정보를 보호하려면 HTTPS를 선택하는 것이 좋습니다.
권위
검색 엔진은 HTTP의 신뢰성이 더 낮기 때문에 보통 HTTP 웹 사이트 콘텐츠의 순위를 HTTPS 웹 페이지보다 낮게 지정합니다. 고객도 HTTP보다 HTTPS 웹 사이트를 더 선호합니다. 브라우저는 브라우저 주소 표시줄에서 웹 사이트 URL 옆에 있는 자물쇠 아이콘을 배치하여 사용자에게 HTTPS 연결을 표시합니다. 사용자는 이러한 추가 보안 및 신뢰 요소 때문에 HTTPS 웹 사이트 및 애플리케이션을 선호합니다.
성능 및 분석
HTTPS 웹 애플리케이션은 HTTP 애플리케이션보다 로드 속도가 더 빠릅니다. 마찬가지로, HTTPS는 참조 링크도 더 잘 추적합니다. 추천 트래픽은 광고 또는 소셜 미디어 백링크와 같은 서드 파티 소스에서 생성되는 웹 사이트 트래픽입니다. 분석 소프트웨어가 신뢰할 수 있는 트래픽 소스를 정확하게 식별하도록 하려면 HTTPS를 활성화해야 합니다.
음... AWS 공식문서에 HTTPS 어플리케이션이 HTTP 애플리케이션보다 로드 속도가 더 빠르다고 나와있는데, TLS 핸드셰이크 단계가 있는 HTTPS가 어째서 더 빠르다고 하는 건지 이해가 안된다...
많은 사람들은 대용량 파일을 HTTPS로 전송하면 서버 부하가 매우 커 HTTPS로 파일에 대한 해시값만 전송하고 HTTP로 파일을 서빙하는 방식을 고려하기도 합니다.
HTTPS로 해시를 전송하고 HTTP로 파일을 서빙하는 방법이 HTTPS로만 파일을 서빙하는 것보다 비효율적인 또 다른 이유는 바로 서로 다른 프로토콜로 인해 2개의 TCP 연결을 성립시켜야 한다는 점입니다. 서로 붙는 것까지 생각하면 정확히는 4개의 TCP 연결이 되겠죠
참고
HTTPS의 동작 방식 (TLS handshake)
1. ClientHello (클라이언트 → 서버):
클라이언트는 랜덤 데이터, 지원하는 암호화 알고리즘 목록, 지원하는 프로토콜 버전 등을 포함한 ClientHello 메시지를 서버에게 전송합니다.
2. ServerHello (서버 → 클라이언트):
서버는 클라이언트의 요청에 응답하여, 랜덤 데이터, 선택된 암호화 알고리즘 및 프로토콜 버전 등을 포함한 ServerHello 메시지를 클라이언트에게 전송합니다.
3. 인증서 전송 (서버 → 클라이언트):
서버는 클라이언트에게 자신의 디지털 인증서를 전송합니다. 이 인증서는 서버의 공개키를 포함하며, 클라이언트는 이를 사용하여 향후 통신을 암호화합니다.
4. Key Exchange (서버, 클라이언트 각각):
서버 및 클라이언트는 서로에게 임시 세션 키를 생성하여 전송합니다. 이 임시 키는 메인 세션 키를 나중에 만들기 위한 재료로 사용됩니다.
5. Finished (클라이언트 → 서버, 서버 → 클라이언트):
클라이언트와 서버는 이전에 교환한 모든 정보를 사용하여 Finished 메시지를 생성하고 서로에게 전송합니다. 이 메시지는 암호화되어 있어 데이터 무결성을 보장합니다.
이러한 핸드셰이크 과정이 완료되면, 클라이언트와 서버는 세션 키를 공유하고 안전한 통신을 시작합니다. 향후의 모든 데이터는 이 세션 키를 사용하여 암호화되고 복호화됩니다.
HTTPS는 느리다?
위 과정이 모두 마친 후의 실제 데이터 통신은 (매우 빠른)대칭키로 암호화하여 진행된다는 점입니다.
여기에 Keep-Alive를 이용하면 세션이 유지될테니 암호화 비용이 약간 줄일 수 있다.
암호화에 시간이 오래걸리는 만큼 "더 안전한 방식" 이라고 할 수 있습니다.
매 요청마다 이런 handshake를 진행하고 통신을 한다면 서버와 클라이언트 모두 큰 부하가 발생할 수 밖에 없습니다. 과거에는 이러한 부분이 HTTP 서버를 HTTPS로 전환하는데 매우 큰 걸림돌이 되었으며 이는 아직까지 많은 서버 개발자 및 관리자의 머릿속에 "HTTPS를 느리고 서버 부하가 크다"라고 이미지를 박아넣는 원인이 되었습니다.
차이점 요약: HTTP와 HTTPS
| HTTP | HTTPS | |
| 의미 | Hypertext Transfer Protocol | Hypertext Transfer Protocol Secure |
| 기본 프로토콜 | HTTP/1과 HTTP/2는 TCP/IP를 사용합니다. HTTP/3은 QUIC 프로토콜을 사용합니다. | HTTP 요청 및 응답을 추가로 암호화하기 위해 SSL/TLS와 함께 HTTP/2 사용 |
| 포트 | 기본 포트 80 | 기본 포트 443 |
| 용도 | 이전 텍스트 기반 웹 사이트 | 모든 최신 웹 사이트 |
| 보안 | 추가 보안 기능 없음 | 퍼블릭 키 암호화에 SSL 인증서 사용 |
| 이점 | 인터넷을 통한 통신 지원 | 웹 사이트에 대한 권위, 신뢰성 및 검색 엔진 순위 개선 |
'network' 카테고리의 다른 글
| TCP/IP? OSI 7계층? (0) | 2024.03.04 |
|---|---|
| TCP/IP 송수신 원리 (feat. nullnull) (0) | 2024.02.24 |
