[CS] HTTP HTTP/2 HTTPS QUIC

Computer Science/CS

[CS] HTTP HTTP/2 HTTPS QUIC

owls 2023. 12. 7. 19:05

728x90

HTTP

Hypertext Transfer Protocol

클라이언트와 서버 간 통신을 위한 통신 규칙 세트 또는 프로토콜입니다.

사용자가 웹 사이트를 방문하면 사용자 브라우저가 웹 서버에 HTTP 요청을 전송하고 웹 서버는 HTTP 응답으로 응답합니다. 웹 서버와 사용자 브라우저는 데이터를 일반 텍스트로 교환합니다. 간단히 말해 HTTP 프로토콜은 네트워크 통신을 작동하게 하는 기본 기술입니다.

HTTP특징

● Stateless(무상태) : 서버가 클라이언트의 상태를 보존하지 않음

▷ 장점 : 서버 확장성 높음(응답 서버를 바꿀 수 있고 무한한 서버 증설 가능)

▷ 단점 : 클라이언트가 추가 데이터 전송

▷ 상태 유지는 쿠키나 세션 사용

→ 쿠키, 세션, 토큰을 사용해서 상태를 기억할 수 있다.

상태를 기억하는 방법
1) 쿠키
브라우저(클라이언트)에 사용자 정보를 저장
2) 세션
서버에 사용자 정보를 저장
3) 토큰, OAuth, JWT
쿠키와 세션의 문제점을 보완하기 위해 Token기반의 인증 방식이 도입.
보호할 데이터를 토큰으로 치환하여 원본 데이터 대신 토큰을 사용하는 기술
중간자 공격으로 토큰을 탈취당하더라도 데이터에 대한 정보를 알 수 없으므로, 보안성이 높은 기술

● Connectionless(비연결성) : 응답 후 클라이언트 서버 간 연결 해제

▷ 장점 : 서버 자원을 매우 효율적으로 사용할 수 있고 응답시간 빠름

▷ 단점 : 새로 연결해야하기 때문에 3-way handshake시간 추가 ( 연결/해제에 대한 오버헤드가 발생)

▷ persistent connections못함 (문제는 아닌데 실시간 처리를 못하니까)

HTTP는 클라이언트가 서버에게 요청하면 서버가 클라이언트에게 응답하는 단방향성의 통신 방식입니다.

비연결성으로 요청-응답이 이루어지면 연결이 종료됩니다.

→ KeepAlive

비연결성으로 인한 오버헤드를 줄이기 위해 HTTP KeepAlive속성을 사용할 수 있다.
KeepAlive는 지정된 시간동안 서버와 클라이언트 사이에서 패킷 교환이 없을 경우, 상대방의 안부를 묻기위해 패킷을 주기적으로 보내는것을 말합니다.
이 때 패킷에 반응이 없으면 접속을 끊게 됩니다.
주기적으로 클라이언트의 상태를 체크한다는 것으로 미루어보아 KeepAlive 역시 완벽한 해결책은 아닙니다.
KeepAlive 속성이 On 상태라해도, 서버가 바쁜 환경에서는 프로세스 수가 기하급수적으로 늘어나기 때문에 KeepAlive로 상태를 유지하기 위한 메모리를 많이 사용하게 되므로 주의해야 합니다.

Persistent Connection

기본적으로 persistent connection을 사용하게 되면 TCP연결을 맺기 위해 3way handshake 과정을 매 요청마다 할 필요가 없어진다.

1) 네트워크 혼잡 감소 : TCP, SSL/TCP connection request수가 줄어들면서

2) 네트워크 비용 감소 : 여러 개의 connection으로 하나의 client요청을 serving하는 것보다 한 개의 connection으로 client요청을 serving하는게 더 효율적이다.

3) latency감소 : 3 way handshake를 맺으면서 필요한 round-trip이 줄어들기 때문에 그만큼 latency가 감소한다.

HTTP의 역사

HTTP/0.9 → Get메서드만 지원, HTTP 헤더 X / 응답도 html 파일자체만 보내줌
HTTP/1.0 → 메서드와 헤더 추가
- 요청헤더 : 버전이 생김.
- 응답헤더 : 상태코드와 content-type이 생겨 html 파일 외 다른 타입의 파일도 전송
- 단기커넥션 : connection 하나당 1 Request & 1 response 처리 가능 → 매번 새로운 연결로 선능 저하 및 서버 부하 비용 증가
- keep-alive connection 도입으로 지속 커넥션을 만들었지만 해당 기능을 지원안하는 서버가 존재
HTTP/1.1 → 가장 많이 사용
- Persistent connection : 기능 내제, 지정한 timeout 동안 연속적인 요청 사이에 커넥션을 닫지 않음
- pipelining 도입 : 하나의 커넥션에서 응답을 기다리지 않고 순차적인 여러 요청을 연속적으로 보내 그 순서에 맞춰 응답을 받는 방식으로 지연 시간을 줄이는 방식
- Head Of Line Blocking : 우선순위로 들어온 요청의 응답 시간이 길어지면 후 순위에 있는 요청의 응답 시간도 길어짐
- head구조의 중복
HTTP/2 → 성능 개선 및 확장
- 메시지 전송 방식의 변화 : 바이너리 프레이밍 계층 사용
- 파싱, 전송속도 증가 & 오류 발생 가능성 저하
- 멀티플렉싱
- HPACK 압축 : 헤더 중복값 개선
HTTP/3 → TCP 대신에 UDP 사용(Quic을 바탕으로 만듦)

HTTP Keep alive란?

HTTP keep alive는 persistent connection을 맺는 기법 중 하나

하나의 TCP connection을 활용해서 여러개의 HTTP request/response를 주고받을 수 있도록 한다.

keep-alive옵션은 설계상 여러 문제점(proxy문제)가 생기면서 HTTP/1.1부터 사용되지 않지만 여전히 많은 웹 어플리케이션에서 사용하고 있다.

기본적으로 HTTP/1.1은 persistent connection을 지원하는 반면에 HTTP/1.0 connection은 하나의 request에 응답할 때 마다 connection을 close하게 설정되어 있다.

keep-alive 커넥션

지정한 timeout동안 연결을 끊지 않는 것.
HTTP 1.0에서는 persistent connection을 원하고 지원하는 클라이언트는 서버에 connection : keep-alive를 요청헤더에 추가한다.
엔티티 헤더에 content-length 값을 정확히 명시해야 트랜잭션이 끝나는 시간에 기존 메시지의 끝과 새 메시지의 시작을 알 수 있다.
옵션 : keep-alive 헤더는 요청일 뿐이기 때문에 언제든지 서버나 클라이언트 측에서 끊을 수 있고 timeout(얼마나 유지할건지), max(몇개의 트랜잭션까지 유지할건지) 파라미터를 정할 수 있다.

keep-alive 옵션 사용 방법

HTTP header에 아래와 같이 입력해주어야 한다.만약 서버에서 keep-alive connection을 지원하는 경우 동일한 헤더를 response에 담아 보내주고, 지원하지 않으면 헤더에 담아 보내지 않는다. 서버의 응답에 해당 헤더가 없을 경우 client는 지원하지 않는다고 가정하여 connection을 재사용하지 않는다.

HTTP/1.1 200 OK
Connection : Keep-Alive
Keep-Alive : timeout=5, max=1000

● max ( MaxKeepAliveRequests) :

keep-alive connection을 통해서 주고 받을 수 있는 request의 최대 갯수

설정한 개수보다 많은 요청을 주고 받을 경우에는 connection은 close된다.

● timeout(KeepAlivetimeout) :

connection이 idle한 채로 얼마동안 유지될 것인가를 의미

이 시간이 지날 동안 request가 없을 경우에 connection은 close된다.

keep-alive의 이점

연결이 유지되면 TCP, SSL/TLS 연결 요청 횟수가 줄어들어 RTT(Round Trip Time, 왕복시간) 가 단축됩니다.

TCP연결을 하기위해 3-way handshake과정이 항상 이루어졌는데 keep-alive헤더를 사용하면 이 과정을 지속적으로 수행할 필요가 없다.

● Netowrk resource conservation( 네트워크 리소스 절약 )

클라이언트당 하나의 연결을 사용하면 네트워크 리소스에 대한 부담에 줄어든다.

● Reduced network congestion( 네트워크 혼잡도 감소)

서버와 클라이언트 간의 TCP연결 수를 줄이면 네트워크 혼잡도가 감소할 수 있다.

● Decreased latency ( 지연 시간 감소 )

3-way handshake 횟수를 줄이면 사이트 지연 시간이 개선될 수 있다.

특히 연결을 암호화하고 확인하기 위해 추가 라운드 트립(RTT)이 필요한 SSL/TLS 연결의 경우 더욱 그렇다.

keep-alive와 proxy문제 : blind relays

서버와 클라이언트가 proxy없이 직접 통신할 경우에는 keep-alive옵션이 정상 동작할 수 있지만, blind relay 즉, keep-alive옵션을 지원하지 않는 proxy는 Connection header를 이해하지 못하고 extension header로 인식하여 제대로 동작하지 않는다.

keep-alive의 대안 : HTTP/1.1

HTTP/1.0의 문제를 해결하기 위해 HTTP/1.1부터 다른 방식을 제공한다.

HTTP/1.1은 모든 connection에 대해서 별도의 설정이 없다면 persistent connection을 맺는다.

HTTP/1.1어플리케이션들은 connection을 close하기 위해 명시적으로 Connection : close 헤더를 입력해야 한다.

클라이언트는 별도로 Connecion: close 헤더가 있지 않는한 서버가 응답한 뒤에도 계속해서 재사용할 수 있다고 가정한다. (별도로 보내지 않아도 서버 및 클라이언트에서 연결을 종료할 수 있다.)

persistent connection (지속적 커넥션)

HTTP1.0에는 connection: keep-alive를 넣어야 가능하고 HTTP1.1부터는 기본으로 내장되어있음
HTTP 1.1에서는 기본적으로 persistent connection을 지원하기 때문에 필요없을 경우 요청헤더에 connection: close를 추가한다.
connection: close 포함 시 클라이언트는 해당 커넥션에 추가 요청을 보낼 수 없다.
커넥션에 있는 모든 메시지가 자신의 길이 정보를 정확히 알아야 한다. (content-length)
HTTP/1.1 프락시는 클라이언트와 서버 각각에 대해 별도의 지속 커넥션을 맺고 관리한다.
장점 : 서버의 단일 시간 내의 TCP 연결 수를적게 해 서버의 CPU나 메모리 자원을 절약할 수 있고네트워크 혼잡이나 지연의 수를 줄일 수 있다. 또한, 여러 개의 HTTP 요청과 응답을 병렬적으로 동시에 처리하기 위한 pipeline을 위해서 꼭 필요하다.
단점 : 연결 된 클라이언트의 수가 계속 증가하게 되면 서버의 자원이 고갈되어 더 많은 클라이언트의 접속에 대처가 불가능 하다. 따라서 클라이언트의 접속이 가장 많은 메인 페이지 URL같은 경우 고려할 점이 많다.

pipelining

HTTP1.1은 지속커넥션을 통해 파이프라이닝이 가능하다.
하나의 커넥션에서 응답을 기다리지 않고 순차적인 여러 요청을 연속적으로 보내 그 순서에 맞춰 응답을 받는 방식으로 지연 시간을 줄이는 방법.
서버 간 요청의 응답속도를 개선시키기 위해 적용
HTTP 클라이언트는 커넥션이 지속 커넥션인지 확인한 후 파이프라이닝을 이어서는 안된다.
HTTP 응답은 요청 순서와 같에 와야한다.
하나의 사용자 클라이언트는 서버의 과부하 방지를 위해 넉넉잡아 두개의 커넥션을 연결한다.
POST 요청같이 반복해서 보낼 경우 문제가 생기는 요청은 파이프라인을 통해 보내면 안된다. (에러 발생 시 파이프라인을 통한 요청 중 어떤 것들이 서버에서 처리됐는지 클라이언트가 알 방법X)
실제로 멀티플렉싱을 제공하는 것이 아닌 응답처리를 미루는 방식으로 각 응답의 처리는 순차적으로 처리되며, 앞에 있는 트랜잭션의 처리가 오래걸릴 경우 후순위에 있는 트랜잭션의 응답은 지연될 수 밖에 없다 이러한 문제를 Head OF Line Blocking이라 부른다. HTTP2에서는 멀티플렉싱 알고리즘으로 대체되었다.

HTTP/1.1 vs HTTP/2

가장 큰 차이는 속도입니다. 2.0은 헤더를 압축해서 보내기도 하고, 한번의 연결로 동시에 에러 메시지를 주고 받을 수 있습니다.

* HTTP1.0에서 TCP세션을 맺는 것을 중복해서 수행하는 성능 이슈가 있었습니다.

-> HTTP1.1에서 Keep-alive를 통해서 해당 문제를 해결했습니다.

* HTTP1.1에서 HOL블러킹 문제가 있었습니다.

-> HTTP2.0에서 Multiplexed라는 기술을 도입하여 1개의 세션으로 여러 개의 요청을 순서에 상관없이 Stream으로 받아서 동시다발적으로 처리하고 응답할 수 있게 해결했습니다.

HTTP 1.1 문제점

* Connection 한 개당 하나의 요청을 처리하도록 설계됨
  -> 동시에 리소스를 주고 받는 것이 불가능
  -> 요청과 응답이 순차적으로 이루어짐
  -> HTTP문서 내에 포함된 다수의 리소스(image, css, script)를 처리하려면
     요청할 리소스의 개수에 비례하여 Latency(대기 시간)이 길어짐
     
 * HOL(Head Of Line) Blocking이 발생할 수 있다.
  -> HOL블로킹이란 네트워크에서 같은 큐에 있는 패킷이 첫 번째 패킷에 의해 지연될 때 발생하는
     성능 저하 현상.
     가장 앞선 요청에 대한 응답이 지연되면 이 후 응답도 모두 지연되는 현상.
     (TCP는 요청 받은 순서대로 응답해야 한다.)
     
 * RTT(Round Trip Time)증가
  -> Connection하나에 요청 한 개를 처리하는 특성 때문에 매번 요청 별로 connection을 만들게 되고
     TCP상에서 동작하는 HTTP의 특성 상 3-way handshake가 반복적으로 일어나며, 불필요한 RTT증가와
     네트워크 지연을 초래하여 성능을 지연시킨다.
     
 * 무거운 Header구조
  -> 매 요청마다 중복된 헤더 값을 전송하게 되며, 서버 도메인에 관련된 쿠키 정보도 헤더에 함께
     포함되어 전송된다. 이러한 반복적인 헤더 전송, 쿠키 정보로 인해 헤더 크기가 증가한다.
     지속 커넥션에서 주고 받는 데이터가 중복된 헤더를 가지는 경우가 많아 메모리 자원 낭비함

HTTP1.0의 커넥션마다 request를 날리는 구조에서 HTTP1.1의 지속커넥션과 파이프라인 도입으로 처리 시간을 효율적으로 줄였지만 보낸 요청 순서대로 응답을 받아야하는 부분에서 문제가 생겼다.
우선순위에 있는 요청의 응답속도가 늦어지면 후순위에있는 요청의 응답속도가 늦어진다.

HTTP/2

HTTP/2는 HTTP/1.1를 개선한 버전입니다.

End user가 느끼는 Latency나 네트워크, 서버 리소스 사용량 등과 같은 성능 위주로 개선되었습니다.

하나의 커넥션에 여러개의 스트림이 동시에 요청/응답하기에 다수 개의 요청을 병렬적으로 처리할 수 있습니다.

http의 느리고 header packet의 중복 전송 등의 단점을 극복할 수 있는 프로토콜입니다. 만일 리소스가 많지 않은 서버의 경우 http2는 비효율적일 수 있습니다.

* Multiplexed Streams 
  : Connection 한 개로 동시에 여러 개의 메시지를 주고 받을 수 있으며, 응답은 순서에 상관없이
    Stream으로 주고 받는다.
    - HTTP1.1의 Connection Keep-Alive, Pipelining, Head Of Line Blocking을 개선
    - latency만 줄여주는게 아니라 네트워크를 효율적으로 사용할 수 있게 한다.
    - 그 결과 네트워크 비용을 줄이기 되며, 특히 클라우드 시스템을 이용한다면 비용과 직결된다.
    
* Stream Prioritization
  : 리소스 간의 의존관계에 따른 우선순위를 설정하여 리소스 로드 문제를 해결함
    클라이언트는 우선순위 지정 트리를 사용하여 스트림에 식별자를 설정한다.
    (문서 내에 CSS파일 1개와 이미지 파일 2개가 존재하고 이를 클라이언트가 요청하는 상황에서
     이미지 파일보다 CSS파일의 수신이 늦어진다면 렌더링에 문제가 생기는데 이를 해결함)
   -Server Push
    : 클라이언트가 요청하지 않은 리소스를 서버가 사전에 푸쉬를 통해 전송할 수 있다.
      (푸쉬가 가능하면 클라이언트가 추후에 HTML문서를 요청할 때 해당 문서 내의 리소스를 사전에 
       클라이언트에서 다운로드할 수 있도록 하여 클라이언트의 요청을 최소화할 수 있다)
       
* Header Compression
     : 헤더 정보를 HPACK방식으로 압축한다.

멀티플렉싱

HTTP1은 요청과 응답이 메시지라는 단위로 구분되어 있었지만 HTTP2부터는 Stream을 통해 요청과 응답이 묶일 수 있어 다수 개의 요청을 병렬적으로 처리가 가능해졌다. 따라서 응답 프레임들은 요청 순서에 상관없이 먼저 완료된 순서대로 클라이언트에 전달이 가능하다.
Head Of Line Blocking 해결

바이너리 프레이밍 레이어

HTTP/2의 모든 성능 향상 중 핵심은 HTTP메시지가 캡슐화되고 클라이언트와 서버 간에 전송되는 방식을 지정하는 새로운 바이너리 프레이밍 레이어입니다.

'layer'는 애플리케이션에 노출되는 소켓 인터페이스와 상위 HTTP API 사이에 최적화된 새로운 인코딩 메커니즘을 도입하기 위한 설계 선택을 나타냅니다. HTTP 의미 체계(예: 동사, 메서드, 헤더)는 영향을 받지 않지만 전송 중에 인코딩되는 방식은 다릅니다. 줄바꿈으로 구분된 일반 텍스트 HTTP/1.x 프로토콜과 달리 모든 HTTP/2 통신은 더 작은 메시지와 프레임으로 분할되며 각각 바이너리 형식으로 인코딩됩니다.

기존 HTTP는 플레인텍스트로 구성되어 있지만 HTTP2부터 데이터를 전송할 때 바이너리로 인코딩하여 전송한다.
바이너리 포맷의 데이터를 사용하게 되어, 데이터를 프레임 단위로 나눠 관리/전송할 수 있음.
파싱, 전송속도 증가 오류 발생 가능성이 줄어듬

프레임이란 HTTP2통신에서 데이터를 주고받을 수 있는 가장 작은 단위이고 헤더 프레임과 데이터 프레임으로 구성된다.
요청과 응답의 단위이다.
메시지는 다수의 프레임으로 구성되어 있다.
stream이랑 클라이언트와 서버 사이에 맺어진 연결을 통해 양방향으로 데이터를 주고 받는 한 개 이상의 메시지를 의미한다.
Frame > Message > Stream (프레임이 여러 개 모여 메시지가 되고 메시지가 여러 개 모여 스트림이 된다)

스트림, 메시지, 프레임

새로운 바이너리 프레이밍 메커니즘이 도입되면 클라이언트와 서버 간에 데이터가 교환되는 방식이 변경됩니다.

HTTP1.1는 HTTP요청과 응답은 Message단위 하나로만 구성되어 있습니다.

HTTP/2 에서는 Message라는 단위 외에 Frame, Stream이라는 단위가 추가되었습니다.

- Frame : HTTP/2에서 통신의 최소 단위이며, Header혹은 Data가 들어있다.
- Message : HTTP1.1과 마찬가지로 요청 혹은 응답의 단위이며 다수의 Frame으로 이루어진 배열 라인
- Stream : 연결된 Connection내에서 양방향으로 Message를 주고 받는 하나의 흐름

HTTP/2는 HTTP요청을 여러개의 Frame들로 나누고, 이 frame들이 모여 요청/응답 Message가 되고, Message는 특정 Stream에 속하게 된다. 여러개의 Stream은 하나의 Connection에 속하게 되는 구조입니다.

프레임 단위로 이루어진 요청과 응답 메세지는 하나의 스트림을 통해 이루어지며, 이러한 스트림들이 하난의 커넥션내에서 병렬적으로 처리됩니다. 하나의 커넥션에서 여러개의 스트림이 동시에 열리니 속도가 빠릅니다.

HTTP Header Data Compression

HTTP1.1에서 헤더는 아무런 압축없이 그대로 전송되었습니다. 이를 개선하기 위해 HTTP2.0에서는 HTTP메시지의 헤더를 압축하여 전송합니다.

또한 HTTP1.1에서는 연속적으로 요청되는 HTTP메세지들에게서 헤더 값이 중복되는 부분이 많아 메모리가 낭비되었습니다. HTTP2.0에서는 이전 메세지의 헤더의 내용 중 중복되는 필드를 재전송하지 않도록하여 데이터를 절약할 수 있게 되었습니다.

HTTP/2는 어떤 방식으로든 HTTP의 애플리케이션 의미 체계를 수정하지 않습니다. HTTP 메서드, 상태 코드, URI, 헤더 필드와 같은 모든 핵심 개념은 그대로 유지됩니다. 대신 HTTP/2는 클라이언트와 서버 간에 데이터의 형식 지정 (프레임) 및 전송 방식을 수정하고 두 서버 모두 전체 프로세스를 관리하고 애플리케이션의 모든 복잡성을 새 프레이밍 레이어 내에 숨깁니다. 따라서 기존의 모든 애플리케이션을 수정 없이 제공할 수 있습니다.

QUIC

tcp자체의 Head Of Line Blocking이 존재하기 때문에 HTTP2의 한계가 있다.

전송 계층 프로토콜(TCP/UDP같은것)
Google에서 만듦
UDP 기반 -> TCP는 신뢰성을 확보하지만 지연을 줄이기 힘들고 UDP는 데이터 전송에 집중했기 때문에 원하는 기능을 구현할 수 있어 UDP를 채택
장점 : 전송 속도 향상 , 첫 연결 설정에서 필요한 정보와 함께 데이터를 전송 → 연결 성공 시 설정을 캐싱하여 다음 연결 때 바로 사용 가능
Connection UUID라는 고유한 식별자로 서버와 연결해 커넥션 재수립이 필요X
TLS 기본 적용과 IP Spoofing/ REplaty Attack 방지로 보안성 향상
독립 스트림 → 향상된 멀티플렉싱 기능 (HTTP2이 멀티플렉싱을 적용해도 TCP 자체로 Head Of Line Blocking이 존재함)keep-alive 커넥션

HTTPS

Hypertext Transfer Protocol Secure

이름에서 알 수 있듯이 HTTPS는 HTTP의 확장 버전 또는 더 안전한 버전입니다.

HTTP는 암호화되지 않은 평문 데이터를 전송하는 프로토콜이기에 비밀번호나 주민등록번호 등을 주고 받으면 제3자가 정보를 조회할 수 있었습니다. 이러한 문제를 해결하기 위해 HTTPS가 나왔습니다.

HTTPS에서는 브라우저와 서버가 데이터를 전송하기 전에 안전하고 암호화된 연결을 설정합니다.

동작 방식

HTTPS는 대칭키 암호화와 비대칭키 암호화를 모두 사용하여 빠른 연산 속도와 안전성을 모두 얻고 있습니다.

HTTPS 연결과정에서는 먼저 서버와 클라이언트 간에 세션키를 교환합니다.

여기서 세션키는 주고 받는 데이터를 암호화하기 위해 사용되는 대칭키이며, 데이터 간의 교환에는 빠른 연산 속도가 필요하므로 세션키는 대칭키로 만들어집니다.

세션키를 클라이언트와 서버가 교환하기 위한 과정에서 비대칭키가 사용됩니다.

즉, 처음 연결 성립하여 안전하게 세션키를 공유하는 과정에서 비대칭키가 사용되는 것이고, 이후에는 데이터를 교환하는 과정에서는 빠른 연산 속도를 위해 대칭키가 사용되는 것입니다.

1. 브라우저는 웹사이트 서버에 접속하여 연결을 요청합니다.
2. 서버는 공개 키를 보냅니다. 개인 키를 비밀로 유지합니다.
3. 브라우저는 세션 키라는 세 번째 키를 생성합니다.
4. 세션 키는 서버에서 얻은 공개 키를 사용하여 컴퓨터에서 암호화합니다.
5. 암호화된 세션 키와 공유됩니다.
6. 서버는 비밀 개인 키를 사용하여 사용자로부터 받은 세션 키를 복호화합니다.
   이제 클라이언트와 서버 양쪽에 컴퓨터가 생성한 세션 키가 있습니다.
7. 공개키 암호화는 종료되고 대칭 암호로 대체됩니다.
8. 대칭 암호화만 사용하여 세션 연결이 되고, 웹 사이트를 떠날 때까지 이 상태가 유지됩니다.

서버가 비대칭키를 발급 받을 때는 독립된 인증 기관(CA)에서 SSL/TLS 인증서를 획득해야 합니다.

그림으로 쉽게 설명한 블로그가 있어서 링크 첨부합니다.

https://brunch.co.kr/@swimjiy/47

HTTP vs 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 인증서 사용
장점	인터넷을 통한 통신 지원	웹 사이트에 대한 권위, 신뢰성 및 검색 엔진 순위 개선