HTTP & HTTPS

HyperText Transfer Protocol

  • 인터넷 상의 커뮤니케이션 방식

  • 웹 상에서 정보를 주고받는 프로토콜

  • 클라이언트와 서버 사이의 요청/응답 프로토콜

HTTP

  • 원래는 TCP 사용하다가 http/3부터 UDP(QUIC) 사용

  • 포트번호는 80

  • 웹브라우저가 http로 서버로부터 html이나 정보를 요청하면 서버가 이에 대해 응답으로 정보를 사용자에게 전달

  • http:로 시작하는 url로 조회

HTTP 메세지

  • 최초엔 get메소드만 존재하고 응답은 무조건 html로만, 요즘은 종류를 가리지 않는다

  • 요청과 응답은 평문(아스키) 메세지로 이루어짐

  • 메세지는 요청 내용 + 헤더 + 빈줄 + 바디

    • 요청 메세지는 메서드+요청url+http버전 + 헤더 + 바디

    • 응답 메세지는 버전+상태코드+상태설명 + 헤더 + 바디

  • http 메소드 종류(요청 방식)로는 get(요청), head, post(생성), put(변경), delete(삭제), connect, options, trace, patch가 있다

  • 상태코드 종류 : ex) 200 OK, 400 Bad Request, 404 Not Found

  • 각각의 데이터 요청이 서로 독립적으로 관리

connectless와 stateless

  • 서버에 연결하고 요청해서 응답을 받으면 연결을 끊는다 (반례. FTP, Telnet)

  • 연결을 최소한으로 유지하여 많은 요청을 처리할 수 있게하지만 클라이언트의 이전 상태를 몰라 http에선 쿠키를 사용

  • 쿠키 - 클라이언트와 서버의 상태 정보를 담고 있는 정보 조각

HTTP3

TCP로 통신하던 기존의 HTTP/1과 HTTP/2와 달리 UDP 기반의 QUIC(Quick UDP Internet Connection) 프로토콜로 통신 하나의 요청응답마다 하나의 tcp 연결이 필요해 많은 핸드셰이크가 필요하던 기존 버전에서 udp를 사용함으로서 핸드셰이크 과정을 없애고 다른 방법으로 연결의 신뢰성을 확보 또한 패킷 손실 때의 오버헤드도 큼 장점 : Zero RTT - 기본 TCP 연결이 1RTT + tls를 이용한 암호화를 위한 tls 핸드셰이크 2RTT에서 첫 연결 설정 때 1RTT 이후는 캐시 활용 (tls 1.3부턴 비슷한 성능 가능) 패킷 손실에 대한 빠른 반응 - 멀티플렉싱(여러 스트림으로 나누어 패킷 손실이 발생해도 해당 스트림만 재전송, http2부터 사용), 패킷마다 고유 패킷 번호 부여하여 빠른 패킷 손실 감지 사용자 IP가 바뀌어도 연결 유지 - ip주소와 포트로 연결을 식별하던 tcp와 달리 ip주소와는 무관한 connection id를 이용하여 서버와 연결하여 클라이언트의 ip가 변경되어도 연결을 유지 인터넷 연결 상태가 좋지 못한 경우(wifi에서 셀룰러로, 다른 wifi로 전환)에서도 https연결이 유지되어 동영상을 끊김 없이 시청 가능한 정도이다. 패킷 전송에 있어서 제약이 거의 없는 비연결성 전송 계층을 기반으로 TCP 프로토콜의 무결성 보장 알고리즘과 SSL이 이식됨으로써 높은 성능과 괜찮은 정확성과 부인방지 특성을 충족 TLS(Transport Layer Security = SSL(secure sockets layer)) 암호화 사용(전자 서명이 포함된 인증서, 내용 암호화)

HyperText Transfer Protocol over Security socket layer

  • 월드 와이드 웹 통신 프로토콜인 http의 보안 강화 버전

  • 통신의 인증과 암호화를 위해 사용 클라이언트와 서버가 통신하는 정보를 클라이언트와 서버만 알아볼 수 있게 암호화, 신뢰할 수 있는 사이트인지 보장

  • 소켓 통신에서 일반 텍스트 대신 ssl이나 tls 프로토콜로 세션 데이터를 암호화

  • 포트는 443

  • 웹 브라우저의 구현 정확도와 서버 소프트웨어, 암호화 알고리즘에 따라 보호 수준이 다름

htttps의 통신방법

  • 대칭키 방식

    • 암호화와 복호화에 동일한 키 사용

    • http로 통신할 때 키가 노출되므로 양쪽이 같은 키를 보유하는 것이 힘듦

  • 비대칭키(공개키)

    • 암호화와 복호화에 서로 다른 키 사용

    • 다른 사이트의 메세지를 원하는 사이트의 키로 복호화할 수 없으므로 https의 두가지 기능 모두 지원

  • https의 통신 방법 - 핸드셰이크

  • 가장 먼저 클라이언트가 서버에게 랜덤한 메세지(ClientHello)(tls버전, 서버 도메인, 세션 식별자, 암호 설정) 전송

  • 서버도 랜덤한 메세지(ServerHello)(tls버전, 세션 식별자, 암호 설정)와 함께 서버 인증서(Certificate)를 보낸다

  • 클라이언트가 브라우저를 통해 CA에 서버 인증서 정보를 확인한다

    • CA인증받은(우리가 원하는 신뢰할 수 있는) 서버의 인증서는 CA의 비공개키로 암호화 되어있으므로 브라우저에 저장된 CA의 공개키로 서버 인증서를 복호화 가능

  • 클라이언트는 앞에서 사용한 두 메세지로 임시키를 만들어 서버가 보낸 서버 인증서에 포함된 서버의 공개키로 암호화하여 서버에 전송한다.

  • 각각 임시키를 이용하여 세션 키를 생성하고 앞으로의 통신의 대칭키로 사용한다

    • 모든 메세지를 비대칭키를 이용하여 암호화하고 복호화하면 좋겠지만 비용이 많이 드므로 메세지는 대칭키로 암호복호

Previous대칭키 & 공개키NextTLS/SSL handshake

Last updated