HTTP, HTTPS

---

HTTP(HyperText Transfer Protocol)와 HTTPS(HyperText Transfer Protocol Secure)는 웹에서 데이터를 전송하는 프로토콜입니다.

이들은 클라이언트(보통 웹 브라우저)와 서버 간의 통신을 정의하며, 데이터를 교환하는 데 사용됩니다.

HTTP (HyperText Transfer Protocol)

---

HTTP는 OSI의 7계층에 해당하는 애플리케이션 계층에 있고 서버와 클라이언트 사이에 데이터를 전송하는 기본 프로토콜입니다.
애플리케이션 계층에서는 웹 브라우저와 웹 서버 간의 요청/응답을 다루며, 데이터를 어떤 형식으로 주고받을지에 대한 논리적인 규칙을 정의합니다.

HTTP는 실제로 데이터를 전송하기 위해 4계층의 TCP(전송 제어 프로토콜)를 사용합니다.
HTTP는 TCP의 신뢰성 있는 데이터 전송 기능을 활용하여 데이터를 주고받습니다.
TCP는 데이터를 패킷으로 나누고, 전송 중 손실된 패킷을 재전송하며,
올바른 순서로 데이터가 도착하도록 보장합니다.

HTTP가 TCP위에서 동작하는 이유

HTTP는 사용자가 웹 페이지를 요청할 때
데이터가 손실되지 않고, 순서가 바르게 유지되며 도착하길 원합니다.
이러한 요구사항을 TCP가 해결해 줍니다.

TCP는 데이터 패킷이 중간에 손상, 손실되면 이를 확인하는 Checksum을 사용하여 감지하고
순서가 뒤바뀌지 않도록 패킷을 재정렬해줍니다.

HTTP의 특징

HTTP는 데이터를 암호화하지 않습니다. 즉, 전송되는 데이터가 평문(plain text)로 전송됩니다.

연결시 3-way handshake, 연결을 종료하는 4-way handshake를 사용합니다.

암호화 과정이 없기 때문에 빠른 성능을 가지지만 보안에 취약합니다.

Handshake

HTTP는 연결 시작과 종료시에 TCP의 handshake를 사용하여 연결을 시작하고 종료합니다.
Handshake에는 3-way handshake와 4-way handshake가 있는데 각각 연결 설정과 연결 해제를 위한 절차입니다.

3-way handshake에서는 SYN, ACK 패킷을 사용하고, 4-way handshake에서는 ACK, FIN을 사용합니다.

• SYN(Synchronize)
  • TCP 연결 설정을 시작하는 패킷입니다. 연결을 설정하려는 두 장치가 서로에게 연결 요청을 보낼 때 사용됩니다.
• ACK(Acknowledgment)
  • 데이터 수신을 확인하고, 수신한 데이터를 성공적으로 받았음을 상대방에게 알리는 패킷입니다
• FIN(Final)
  • TCP 연결을 종료하기 위한 패킷입니다. 연결을 종료하려는 한쪽이 보내며, 연결 해제 과정을 시작합니다.

3-way handshake (연결 설정)

3-Way Handshake는 서버와 클라이언트가 데이터를 전송하기 위해 네트워크 연결을 설정하는 과정입니다.

전화를 연결하는 과정을 예로 들어보겠습니다.

Client → Server (SYN)
클라이언트가 서버에 연결 요청을 보내기 위해 SYN 패킷을 보냅니다.

Server → Client (SYN-ACK)
서버는 클라이언트의 SYN요청을 받고 클라이언트에게 SYN 패킷을 보내며, 서버도 클라이언트의 SYN 패킷을 보내며 클라이언트의 SYN에 대한 확인 응답(ACK)을 포함합니다.

Client → Server (ACK)
클라이언트는 서버의 SYN-ACK 패킷을 수신하고 이를 확인한 후 서버에게 ACK 패킷을 보냅니다.
마지막 이 과정에서 클라이언트와 서버가 연결되고 데이터 전송을 시작할 준비를 끝내게 됩니다.

이렇게 3way-handshake 과정이 끝나게 되면 서버는 데이터 전송을 할 수 있고, 클라이언트는 서버에서 전송되는 데이터를 받을 수 있게 됩니다.
이어서 데이터 전송이 완료된 후에 연결을 끊는 4-way handshake 과정도 살펴보겠습니다.

4-way handshake (연결 해제)

4-way handshake는 연결을 해제하는 과정입니다.
여기서는 FIN 플래그를 추가적으로 사용하는데 FIN는 Finish의 약자로 세션을 종료시키는데 사용합니다.

Half-Close 기법
TCP에서 Half Close는 한쪽에서만 데이터 전송을 중단하고 다른 쪽에서는 데이터를 전송할 수 있는 상태를 의미합니다. 즉 완전히 종료되지 않은 반만 종료하는 방법입니다.

처음 종료를 요청하는 쪽에서 FIN 패킷에 ACK를 함께 담아서 보냅니다. 이때 ACK는 “종료는 할건데 할 말이 있으면 더 해”를 의미합니다.

이후 수신자가 데이터를 모두 보낸다면 FIN 패킷을 보내면서 통신이 종료됩니다

Client → Server (FIN)
클라이언트가 연결을 종료하고 싶은 시점에 Server에게 연결 종료 의사를 전달하는 FIN 패킷을 보냅니다

실제로는 종료 의사만을 전달하고 할말이 더 있는지는 묻지 않습니다 이해하기 쉽게 예를 들어서 설명을 했습니다.

Server → Clinet (ACK)
서버는 클라이언트의 FIN 패킷을 수신하고 종료 의사를 확인한 ACK 패킷을 클라이언트에게 보냅니다.
이후 남은 전송할 데이터가 있다면 계속 전송한다. 이때 클라이언트는 서버의 FIN 패킷을 기다리며 FIN이 오기 전까지 서버의 데이터를 받을 수 있는 상태입니다.

Server → Clinet (FIN)
남은 데이터 전송을 마치고 서버도 종료하고자 할때 FIN 패킷을 클라이언트에게 보냅니다.

Client → Server (ACK)
클라이언트는 서버의 FIN 패킷을 수신하고 ACK를 서버에게 보내며 통신이 종료됩니다.

HTTP의 통신

HTTP에서 데이터를 전송하기 위해서 연결을 시작, 종료하는 handshake 과정을 진행합니다.
그 이후에 다시 통신을 하려면 어떻게 할까요??
다시 연결을 위한 3-way handshake와 종료를 위한 4way-handshake를 진행합니다.

그 이유는 HTTP 통신은 비연결 지향적인 프로토콜이기 때문인데요
요청에 대한 응답이 끊나면 기본적으로 연결이 종료되는 방식이기 때문입니다.

그래서 매 요청마다 TCP 연결이 설정되고 종료되는 방식으로 진행이 됩니다.
하지만 HTTP/1.1 부터 지속적 연결(persistent connection)이 도입되었습니다.
지속적 연결이란 클라이언트에서 헤더를 통해서 Connection: keep-alive를 설정합니다.
그러면 HTTP요청과 응답이 동일한 TCP 위에서 이루어질 수 있게 됩니다.
한 마디로 다시 handshake를 통한 연결에 대한 리소스가 줄게 된다는 뜻 입니다.

하지만 이 방법 또한 연결지향적인 방법은 아닙니다.
왜냐하면 HTTP는 기본적으로 요청-응답 모델입니다.
클라이언트가 요청을 보내고 서버가 응답을 반환하는 구조입니다.
실시간 통신에서는 서버가 클라이언트에 데이터를 푸시해야 하는 경우가 많지만,
HTTP는 이를 기본적으로 지원하지 않습니다.
그리고 지속적 연결(persistent connection)은 매 연결마다 TCP 3-way Handshake를 안해도 연결을 지속적으로 유지 하는게 목적이이지 실시간 통신을 위한 연결 지향적 방법은 아니기 때문입니다.

또한, HTTP는 상태 비유지(stateless) 특성도 가지고 있습니다.
각 요청은 독립적으로 처리되며, 이전 요청의 상태를 기억하지 않습니다.
하지만 실시간 통신에서는 연결 상태와 세션을 유지해야 하는 경우가 많습니다.

HTTP의 실시간 통신

HTTP는 단방향 통신으로 설계되어서 기본적으로 실시간 통신 방법인 양방향 통신을 지원하지 않습니다

하지만 애플리케이션의 발전과 사용자 요구사항으로 인해서 실시간 통신이 필요하게 되었고 그에 따라 HTTP 통신에서 실시간 통신과 유사하게끔 동작하는 기능들이 추가되었습니다.

Polling

Polling은 클라이언트가 일정한 간격으로 서버에 요청을 보내 데이터를 가져오는 방식입니다. 초기에는 실시간 데이터를 제공할 수 있는 유일한 방법 중 하나였지만 아래와 같은 단점들이 존재합니다.

• 서버에 데이터가 업데이트 되지 않을때도 요청이 계속 발생하여서 네트워크 트래픽이 증가하게 됩니다.
• 데이터가 업데이트된 후 클라이언트가 이를 확인하기까지 지연이 발생할 수 있습니다.

Long Polling

Long Polling은 Polling의 단점을 개선하기 위해 도입되었습니다. 클라이언트가 서버에 요청을 보내면, 서버는 새로운 데이터가 생길 때까지 응답을 지연시킵니다. 데이터가 생기면 서버는 응답을 보내고 클라이언트는 즉시 새로운 요청을 보냅니다. 이는 네트워크 트래픽을 줄이고 실시간 데이터를 제공하는 데 더 효율적입니다.

하지만 여전히 서버에 많은 요청이 발생할 수 있으며, 서버와 클라이언트 모두 약간의 추가 로직이 필요합니다.

Streaming

Streaming은 서버와 클라이언트 간에 지속적인 연결을 유지하며, 서버가 새로운 데이터를 지속적으로 클라이언트에 보내는 방식입니다. 이는 HTTP/1.1의 지속적 연결(persistent connection)을 활용하거나, HTTP/2의 멀티플렉싱을 이용할 수 있습니다.

클라이언트와 서버 간의 연결이 지속적으로 유지되며, 서버는 새로운 데이터가 생길 때마다 클라이언트에 데이터를 스트리밍합니다.

이렇게 실시간 통신 처럼 동작하지만 그럼에도 HTTP에서의 통신은 요청과 응답으로 작동하기 때문에 여전히 실시간 데이터 처리에는 무리가 있습니다.

그래서 실시간 통신이 필요한(라이브 스트리밍, 채팅 등) 서비스에서는 양방향 통신인 TCP/IP의 Socket 통신이나 HTTP로 연결을 맺고 사용하는 WebSocket 방식을 사용하여 실시간 통신을 합니다. 자세한 개념은 TCP/IP와 소켓통신에서 더 다루겠습니다.

HTTPS

---

HTTPS(HyperText Transfer Protocol Secure)는 HTTP(HyperText Transfer Protocol) 뒤에 Secure가 붙은 보안 통신 프로토콜입니다.

HTTPS는 HTTP 요청 및 응답을 SSL/TLS 기술에 결합하여 암호화가 되지 않는 평문 데이터를 전송하는 HTTP의 단점을 해결하기 위해 등장하였습니다. 이를 통해 HTTPS 암호화를 진행하고 발신자와 수신자만 해당 암호를 해독하여 정보를 주고받을 수 있습니다.

HTTP와 다르게 443번 포트를 사용합니다 (HTTP는 80번 포트를 사용합니다.)

HTTP 포트 (80번 포트):

• 80번 포트는 HTTP 통신을 위해 예약된 포트입니다.
• HTTP 요청은 TCP 3-way 핸드셰이크를 통해 연결을 설정하고, 그 이후에 클라이언트와 서버가 데이터를 교환합니다.

HTTPS 포트 (443번 포트):

• 443번 포트는 HTTPS 통신을 위해 예약된 포트입니다.
• HTTPS 요청은 TCP 3-way 핸드셰이크를 통해 연결을 설정한 후, SSL/TLS 핸드셰이크 과정을 통해 암호화된 연결을 설정하고, 그 이후에 암호화된 데이터를 교환합니다.

SSL/TLS란?

SSL(Secure Sockets Layer)과 TLS(Transport Layer Security)는 인터넷 상에서 데이터를 안전하게 전송하기 위한 암호화 프로토콜입니다.

SSL은 초기 버전이고 TLS은 뒤에 나온 버전이지만 일반적으로 두개를 합쳐서 SSL/TLS라고 부르거나 TLS라고 부릅니다.

SSL/TLS는 암호화, 데이터 무결성, 인증을 제공합니다.

데이터를 전송할때 암호화하여 중간에 도청되더라도 내용을 알 수 없게 암호호화하고, 전송된 데이터가 중간에 변경되지 않음을 보장하는 데이터 무결성, 서버와 클라이언트가 서로의 신원을 확인할 수 있도록합니다.

SSL/TLS는 클라이언트와 서버 간의 안전한 연결을 설정하기 위해 여러 단계를 거칩니다. 이 과정은 핸드셰이크(Handshake)라고 불리며, 대칭 키 암호화를 사용하기 위한 초기 설정을 수행합니다.

• Client → Server : 클라이언트 헬로 (Client Hello)
  • 클라이언트는 서버에 TLS 연결을 시작하기 위한 헬로 메시지를 보냅니다.
  • 클라이언트가 지원하는 TLS 버전, 암호화 알고리즘, 압축 방법, 클라이언트 랜덤 값 등이 포함됩니다.
• Server → Client : 서버 헬로 (Server Hello)
  • 서버는 클라이언트의 헬로 메시지를 수신하고, 서버 헬로 메시지로 응답합니다.
  • 이 메시지에는 서버가 선택한 TLS 버전, 암호화 알고리즘, 압축 방법, 서버 랜덤 값 등이 포함됩니다.
• Server → Client : 서버 인증서 전송 (Server Certificate)
  • 서버는 자신의 SSL/TLS 인증서를 클라이언트에 전송합니다.
  • 이 인증서는 서버의 신원을 확인하고, 서버의 공개 키를 포함합니다.
• Server → Client :서버 완료 (Server Hello Done)
  • 서버는 클라이언트에 서버 헬로 완료 메시지를 전송합니다.
  • 서버가 클라이언트에게 보낼 메시지를 모두 보냈다는 뜻입니다.
• Client → Server : 클라이언트 키 교환 (Client Key Exchange)
  • 클라이언트는 서버의 공개 키를 사용하여 프리마스터 시크릿을 암호화하고 서버에 전송합니다.
• Server & Client : 변경 암호 사양 (Change Cipher Spec)
  • 클라이언트는 암호화 알고리즘을 사용하여 이후 메시지를 암호화할 준비가 되었음을 서버에 알립니다.
  • 서버도 동일한 메시지로 응답합니다.
• 핸드셰이크 완료 (Finished)
  • 클라이언트와 서버는 암호화된 핸드셰이크 완료 메시지를 교환합니다.
  • 이 메시지를 통해 핸드셰이크가 성공적으로 완료되었음을 확인합니다.

HTTPS의 SEO 효과

구글은 HTTPS를 순위 결정 신호로 사용되고 있고 상위 검색결과 95% 이상이 HTTPS입니다. 즉 HTTPS를 사용하지 않으면 검색 결과 하단으로 밀려나게 됩니다.

또한 구글은 HTTPS를 사용하지 않는다면 안전하지 않은 페이지라고 보여주고 있습니다.

구글 SEO(Search Engine Optimization)는 웹사이트가 검색 엔진 결과 페이지(SERP)에서 더 높은 순위에 나타나도록 최적화하는 과정입니다. 이를 통해 웹사이트의 가시성을 높이고, 더 많은 트래픽을 유도할 수 있습니다. 구글은 가장 인기 있는 검색 엔진이므로, 구글 SEO는 웹사이트가 구글 검색 결과에서 더 잘 보이게 하는 데 중점을 둡니다.

마무리

---

이번에는 HTTP와 HTTPS에 대해서 포스팅을 하게 되었는데요
HTTP와 HTTPS가 무엇이 다른지 그리고 어떻게 동작하는지에 대해서 더 자세하게 알게 된 것 같습니다.

그리고 handshake과정을 직접 그리면서 조금 더 쉽게 설명하기 위해서 노력했는데
그림을 그리면서 저도 한층 더 깊게 이해하는 계기가 되지 않았나 싶습니다.

긴글 읽어주셔서 감사합니다. 질문과 피드백은 언제나 환영합니다 🤗