HTTP

웹브라우저와 서버 간의 자원을 주고 받을 때 쓰는 통신규약

Application Layer의 프로토콜이다!

특징

• TCP 기반의 프로토콜이다
• Connectionless
  • 7계층 관점!
  • 사용자 요청 시 서버에 요청하고 바로 연결을 종료 -> Stateless 성질을 갖게됨
  • 간-단
  • 연결을 위한 리소스를 줄일 수 있음
  • 하지만, 연결 종료 후 추가적인 요청을 서버에 보내면 서버는 어떤 사용자인지 알 수 없음 -> 해결방법(Stateful mechanism): 쿠키, 세션, OAuth, JWT
  • 여러 요청이 발생한다면, 매번 연결/해제 과정이 필요하기 때문에 오버헤드가 발생
• 단방향성
  서버는 먼저 요청을 보내지 않음 (클라이언트의 pull)
• 자원을 주고 받을 때 암호화된 데이터가 아니라 텍스트를 교환함..!
  👉 누군가 네트워크 상에서 신호를 가로채 볼 수 있다는 보안상의 위험이 존재

HTTPS

SSL(TSL) 프로토콜을 이용해 웹브라우저와 서버가 자원을 주고 받는 통신규약

즉, SSL 프로토콜을 통해 세션 데이터를 암호화함! 다만 꼭 알아야 하는거는 HTTP와 다른 프로토콜이 아니라는 점!! 그냥 SSL/TSL 프로토콜을 이용해 암호화된 데이터를 주고 받는 HTTP임

👆 암호화를 위해 SSL/TLS 레이어를 추가로 두고 있음

👆 따라서, handshake 후 평문 데이터를 주고 받는 HTTP와 달리 HTTPS는 TLS handshake를 진행한 뒤 암호화 통신을 시작함!

그렇다면 HTTP는 왜 쓰는걸까?

• HTTPS는 암/복호화 과정 때문에 웹서버에 부하를 줄 수 있음
• HTTP: 비연결형 👉 인터넷 연결이 끊기면 다시 연결해 페이지를 계속 볼 수 있음
  HTTPS: 소켓 자체에서 인증 👉 인터넷 연결이 끊기면 소켓 연결도 끊겨 다시 HTTPS 인증이 진행되어야 함

장단점

사용자 입장에서의 장단점

• HTTP: (+)빠르지만 (-)변조 가능성이 있다
• HTTPS: (+)안전하다

공급자 입장에서의 장단점

• HTTP: (+)비교적 적은 트래픽 발생 (-)민감한 정보를 다룰 때 항상 변조, 해킹 가능성을 고려해야 한다
• HTTPS: (+)안전 ! (-)설치 및 인증서를 유지하는데 추가비용이 든다

ref

https://victorydntmd.tistory.com/286