CS/더 깊게 깊게

HTTP/HTTPS

서영환 2024. 8. 6. 15:27
  • HTTP
    • 개요
      • Hypertext Transfer Protocol 의 약자
      • 통신을 주고받게 하는 가장 기본적인 프로토콜
      • 서버에서 브라우저로 데이터를 전송하는 용도로 가장 많이 사용
      • 전송 되는 기간 동안 데이터의 도난의 위험이 존재
    • 특징
      • 단방향성 : 클라이언트가 요청을 보내야만 응답( HTTP 2버전 이전)
      • 비연결성 : 서버와 연결된 후, 요청에 대한 응답의 데이터를 전송하면 연결을 종료
      • 실시간 통신이 안된다
    • 발전
      • 버전
        • v1.0 -> v1.1 -> v2.0 -> v3.0
        • 현재를 기준으로 v1.1을 가장 많이 사용하고 있는 중
      • v1.0
        • 연결에 성공을 하였어도 1회성으로 만사용이 가능 하다는 문제점이 발생
      • v1.1
        • v1.1의 1회성 문제를 해결 하기위하여 연결의 재사용
        • 연결을 생성하면 지정한 시간(timeout)동안은 재사용하는 방식
      • v2.0
        • Head Of Line Blocking 문제 해결
          • Head Of Line Blocking 문제란 요청이 병렬로 오면 병렬로 온 요청을 모두 확인하여 동시에 응답해야 하는 문제를 말한다. 
          • 간단하게 내가 1+1, 1+2, 1+3을 서버에게 물어봤을때 서버는 2, 3, 4를 모두 계산을 하고 난 뒤에 응답을 해주는 문제가 발생
          • v2.0에서는 요청을 프레임으로 쪼개서 순서 상관없이 처리하도록 하여 해결
        • Server Push
          • 연결 생성 후에 클라이언트 요청없이도 서버가 응답
          • 단순하게 생각하면 카카오톡의 알림이나 배달의 민족 알림 같은 우리가 따로 서버에게 요청없이 서버가 새로운 소식을 우리에게 알려주는 기능
        • HTTP/2 점유율은 40%
      • v3.0
        • 앞의 버전과는 다르게 TCP가 아 UDP기반
        • 아직까지는 사용하는 곳이 많지 않고 구글웹페이지가 v3.0을 사용하고 있는 중이다
    • 실시간 통신의 경우에는 웹소켓(WebSoket)을 주로 사용하나 웹소켓을 지원되지 않는 환경에서는 HTTP를 통하여 폴링(polling), 롱폴링(long-polling), 스트리밍(streaming) 등의 실시간 통신처럼 보일 수 있게끔하는 방식을 사용
    • HTTP 메소스
      • GET : 보통 리소스를 조회할 때 사용하며, 서버에 전달하고 싶은 데이터는 query를 통해서 전달한다. 메시지 바디를 사용해서 데이터를 전달할 수는 있지만, 지원하지 않는 곳이 많아서 권장하지 않는다.
      • POST : 주로 리소스를 새롭게 생성할 때 사용하며, 서버에 전달하고 싶은 데이터는 메시지 바디를 통해 전달한다.
      • PUT : 리소스가 있으면 대체하고 리소스가 없으면 생성한다. 즉, 데이터를 덮어쓴다.
      • PATCH : PUT과 마찬가지로 리소스를 수정할 때 사용하지만, PATCH는 리소스를 일부분만 변경할 때 사용한다.
      • DELETE : 리소스를 제거할때 사용한다.
    • HTTP 상태코드
      • 100번대 (Informational) : 요청이 수신되어 처리중
      • 200번대 (Successful) : 처리 성공
      • 300번대 (Redirection) : 다른 곳으로 유도(요청을 완료하면 추가 행동이 필요,민원처리 생각하면 될 거 같다 )
      • 400번대 (Client Error) : 클라이언트측 문제(잘못된 요청)
      • 500번대 (Server Error) : 서버측 문제(서버 에러 혹은 서버 다운등)
  • HTTPS
    • 개요
      • Hypertext Transfer Protocol Secure 의 약자
      • HTTP의 정보 도난의 위험을 해결 하기 위해 SSL(Secure Sockets Layer, 보안 소켓 계층)을 사용
        • 서버와 브라우저 사이에 안전하게 암호화된 연결을 만들 수 있게 도와주고, 서버와 브라우저가 보안정보를 주고받을때 해당 정보가 도난당하는 것 방지
        • 대칭키와 비대칭키 기반으로 사용
      • TLS: 전송 계층 보안(Transport Layer Security)
        • TLS은 SSL의 향상된, 더욱 안전한 버전
        • SSL이 더욱 일반적인 용어이기 때문에 DigiCert는 보안 인증서를 여전히 SSL로 언급하지만 DigiCert에서 SSL을 구입하면 가장 신뢰할 수 있는 최신 TLS 인증서를 얻을 수 있다
      • 웹사이트가 SSL/TLS 인증서로 보호되는 경우 HTTPS가 URL에 표시
      • 사용자는 브라우저 표시줄의 자물쇠 기호를 클릭해 발급 기관 및 웹사이트 소유자의 상호를 포함한 인증서의 세부 정보를 확인 가능
    • SSL Handshake
      • TCP/IP 연결할때 3-way Handshake 로 연결을 확인하는것처럼 HTTPS 연결할때는 SSL Handshake 를 통해 추가적인 인증을 확인
      • 칭키/비대칭키 방식을 모두 사용하여 요청/응답 정보를 모두 암호화 하며, 외부 인증기관(외부 서버)가 사이트가 유효한지(신뢰할만 한지) 보증인 역할
      • 순서
        1. 서비스를 서빙하는 서버가 CA 로부터 CA 인증서를 발급(인증서 기간 만료까지 1회성)
        2. 서비스를 서빙하는 서버는 CA에 자신의 도메인 정보와 서버 측 공개 키 전송
        3. 인증기관은 받은 두 데이터를 자신의 개인키로 암호화한 CA 인증서를 서버로 전송
        4. 브라우저에서 도메인을 쳐서 요청을 보내 클라이언트(브라우저)와 서버가 TCP 연결
        5. 서버는 브라우저가 보내준 Cipher Suite 중 하나를 고르고, 자신의 SSL/TLS 프로토콜 버전을 브라우저에게 알리면서, 서버 자신의 도메인에 대한 CA 인증서 전송
        6. 브라우저는 브라우저에 내장된 CA의 공개 키를 이용하여 CA 인증서를 복호화하여 인증서가 유효한지 검증한 후, 서버 측의 공개 키 획득
        7. 브라우저는 앞으로 서버와 통신하는데 있어 암호화를 위해 사용할 대칭 키를 만들고, 그 대칭 키를 사이트 공개 키로 암호화하여 서버 전송
        8. 서버는 자신의 개인 키를 사용하여 암호화된 것을 복호화하여 사용자 대칭 키 획득
        9. 획득한 대칭 키를 활용하여 서버와 클라이언트가 서로 데이터를 안전하게 암/복호화 하면서 통신