HTTP

Hypertext Protocol 의 약자로, TCP/IP 기반의 서버-클라이언트 메시지 교환을 위한 프로토콜이다.

TCP/IP

전송 제어 프로토콜 Transmission Control Protocol 과 패킷 통신 방식의 인터넷 프로토콜 Internet Protocol 를 합쳐 부르는 말로, 오늘날 전세계적으로 인터넷을 통해 다양한 네트워크 통신을 이룬 표준 프로토콜 스택이다. 해당 프로토콜 스택은 인터넷에서 데이터 통신은 물론, 웹 브라우징, 이메일, 파일 전송 등 다양한 네트워크 기반 서비스에서 중요한 역할을 한다.

• Transmission Control Protocol : 네트워크 계층에서 이루어지는 프로토콜로, 데이터를 안정적으로 전송하는 역할을 담당한다. 데이터의 순서를 보존하며, 데이터 전송 중 오류, 일부 패킷의 손실이 발생하더라도 재전송하여, 보다 정확한 전송을 지원한다.
• Internet Protocol : 라우터 계층에서 이루어지는 프로토콜로 컴퓨터 간 데이터를 전송하는 주소 체계를 정의한다. 각 컴퓨터는 고유한 IP 주소를 가지며, 이 주소를 통해 데이터 패킷이 목적지로 전송된다.

흔히 말하는 TCP/IP 4계층은 크게 클라이언트/서버 - TCP - IP - Etnernet 형태로 구조를 이룬다.

TCP/IP 에 대한 추가적인 정보와, handshake 신뢰성 인증 과정은 이전 TCP, UDP 글에 작성해두었으니 이를 확인하자.

TCP와 UDP - Web 개발 필수 프로토콜 이해하기

HTTP 특징

Request,Response

HTTP 는 클라이언트가 서버에게 요청을 보내고, 서버는 클라이언트에게 응답을 보내는 구조를 가진다.

Stateless

HTTP는 상태를 유지하지 않는 무상태성 stateless 를 이룬다. HTTP 내에서 실행되는 요청과 응답은 다른 요청, 응답에 상관없이 독립적으로 이루어지며, 통신을 위한 정보외에, 서버는 클라이언트의 상태, 정보에 대해, 클라이언트는 서버의 상태, 정보에 대해 알지 못한다.

이는 상태를 따로 저장해두지 않으므로 클라이언트, 서버 각각 완전히 독립적인 형태로 자신의 업무만 수행하기 때문에 확장성이 용이하지만, 매 요청, 응답마다 필요한 통신 정보를 함께 전송해줘야 한다는 단점이 있다.

Connectionless

stateless 의 특징과 연관된 특징으로, HTTP 내에서 실행되는 요청과 응답은 서로 독립적으로 처리되며, 각 요청과 응답이 완료되면 연결 상태는 더이상 유지되지 않음을 의미한다. 요약하자면 각 요청과 응답은 이전 통신에 대한 정보를 기억하지 못하며, 항상 새로운 요청과 응답을 처리하는 형태로 연결을 이룬다.

단, 매 요청-응답 마다 TCP 커넥션 (handshake) 과정 절차를 진행하는 방식은 통신 성능에 부정적인 영향을 미치기 때문에, 추후 HTTP 1.0 에서는 persitance connection 을 HTTP 1.1 에서는 pipe- lining 을 지원하여, 어느정도의 지속적 연결을 통해 통신 성능을 높였다.

• persistance connection : 일정 시간 동안, handshake 인증 효력을 유지한다.
  (유지되는 동안 handshake 인증 과정은 무시된다.)
• pipe-lining : 다수의 요청을 연이어 보내는 것이 가능
  (본래, 이전의 요청에 대한 응답이 오기 전 까지는 요청을 보내는 것이 불가능 했다)

HTTP 구조

HTTP 구조는 크게 Header, Body 로 구분된다. 요청의 경우 RequestHeader, RequestBody , 응답의 경우 ResponseHeader, ResponseBody 등으로 표현한다.

HTTP 요청 구조

• 메서드(Method) : 요청이 어떤 동작을 수행할지를 나타내는 부분으로, 일반적으로 GET, POST, PUT, DELETE 등이 있다.
• URI(Uniform Resource Identifier) : 요청 대상의 식별자을 의미하며, 클라이언트가 어떤 자원에 요청을 하는지를 나타낸다.
• 헤더(Header) : 요청에 대한 부가적인 정보를 포함한다. 예를 들면 클라이언트 정보, 전송하는 데이터 유형, 인증 정보 등이 있다. stateless 특징의 단점으로, 매 요청, 응답마다 필요한 통신 정보를 함께 전송해야한다고 이야기 했는데, 그 정보들이 바로 이 공간에 담겨 전송이 된다.
• 바디(Body) : 응답 시 필요한 클라이언트에서의 데이터를 보내는 부분이다. 주로 POST 메서드를 통해 클라이언트 영역의 데이터를 DB 에 저장하는 용도로 많이 사용된다.

HTTP 응답 구조

• 상태 코드(Status Code) : 서버의 처리 상태를 나타내는 세자리 형태의 숫자이며, 성공, 실패, 리다이렉트 등 다양한 상태를 표현한다. 예를들어 200은 성공, 404는 찾을 수 없음, 500은 서버 내부 에러 등이 있다.
• 헤더(Header) : 응답에 대한 부가적인 정보를 포함한다. 클라이언트에게 전송하려는 데이터의 유형, 서버 정보, 쿠키 등이 여기에 포함된다.
• 바디(Body) : 요청에 대한 처리 결과로 클라이언트로 전송할 데이터가 담기는 부분이다. HTML 페이지, JSON 데이터 등이 여기에 포함된다.

HTTPS

HyperText Transfer Protocol Secure의 약자로, HTTP의 약점을 보완하기 위해 등장했다. 443 포트를 사용하며, HTTP 인증과정 중 바로 밑단에 SSL 인증 과정을 추가하여, HTTP 정보를 보내기전에서 모든 데이터 정보를 암호화하고 상대방에 대한 추가적인 인증과정을 거치는 것으로, 신뢰성을 높이며 통신과정에서 데이터를 가로채려는 공격 등에 대하여 대응 할 수 있게 되었다.

HTTPS는 어플리케이션 계층의 새롭게 등장한 프로토콜 개념이 아니며, HTTP 프로토콜 과정 이후 SSL 혹은 TLS 프로토콜을 추가하는 형태이다.

SSL

보안 소켓 계층 Socket Secure Layer 의 약자로, Netscape Communications Corporation에서 웹 서버와 웹 브라우저간의 보안을 위해 만든 프로토콜이다. SSL 의 주요 특징은 다음과 같다.

• 기밀성(Confidentiality) : SSL 은 전송되는 데이터를 암호화하여, 중간에 제3자가 정보를 엿보더라도 실제 데이터를 이해하지 못하도록 보호한다.
• 무결성(Integrity) : 암호화된 정보가 원본 정보와 일치하는지 혹은 중간에 데이터가 변경, 손상되지 않았는지 등을 체크하여 암호화된 정보에 대한 데이터 무결성을 보장한다.
• 인증 (Authentication) : 인증서를 통해 서버-클라이언트 간 신뢰성을 한층 더 강화했다.

TLS

SSL 프로토콜을 토대로 발전한 프로토콜로서, 당시 SSL 프로토콜을 개발했던 Netscape가 IETF(Internet Engineering Task Force, 국제 인터넷 표준화 기구)에 프로토콜 권리를 양도하여 이름을 바꾸게 되었다. 실제 TLS 1.0은 SSL 3.1과 동일한 프로토콜이다.

대칭키 암호화 및 비대칭키 암호화

HTTPS는 대칭키 암호화방식과 비대칭키 암호화 방식을 모두 사용한다.

대칭키

키를 하나만 사용하는 암호화 방식으로, 하나의 키로 암호화 및 복호화를 진행한다.

비대칭키

두 개의 다른 키 (공개 키, 개인 키)를 한 쌍으로 하여 데이터를 암호화하거나 복호화를 진행한다.

• 공개 키 : 모두에게 공개가 가능한 키
• 개인 키 : 나만 소유해야하는 키

암호화를 공개키로 하느냐 개인 키로 하느냐에 따라 얻는 효과가 다르며, 다음과 같은 효과를 얻을 수 있다.

• 공개 키 암호화 : 공개 키로 암호화하고 개인 키로 복호화를 진행한다. → 암호화된 데이터는 오직 개인 키를 소유한 서버만 해독하는 것이 가능하므로 데이터 보안을 높이고 무결성을 보장한다.
• 개인 키 암호화 : 개인 키로 암호화하고 공개 키로 복호화를 진행한다. → 복호화 성공 시 해당 데이터가 인증된 정보라는 것을 보장할 수 있다.

HTTPS 연결 과정

HTTPS 연결과정에서는 서버와 클라이언트 간의 세션 키 교환이 진행된다. 세션 키란, 주고 받는 데이터를 암호화하기 위해 사용되는 대칭 키이다.

클라이언트와 서버가 대칭 키를 공유하는 과정에서는 비대칭 키 암호화가 사용되며, 인증 이후에는 빠른 데이터 교환을 위해, 연산작업이 필요하지 않는 대칭 키 전략을 사용하는 것이다.

SSL handshake 흐름

1. 클라이언트가 서버에 최초 연결을 시도한다.
   이 단계에서 클라이언트가 서버에게 보내는 옵션은 다음과 같다.

   • 클라이언트 측에서 생성한 랜덤 데이터 (무작위 문자열)
   • 사이퍼 슈트 : 암호화 알고리즘 리스트로, 클라이언트가 현재 가능한 암호화 알고리즘 들을 선택하여 보낸다.
   • 임시 DH 매개변수

2. 서버는 인증서를 클라이언트에게 전달한다.

   서버는 클라이언트 모두 지원하는 가장 높은 TLS 버전을 식별하여 결정하며, 서버의 사이퍼 슈트 지원 여부를 확인하여 암호화 알고리즘을 결정하여 CA 를 통해 얻은 인증서를 클라이언트에게 응답 정보로 보낸다. 해당 정보에서 서버가 보내는 정보는 다음과 같다.

   • 서버 측에서 생성한 랜덤 데이터
   • SSL 인증서
   • 임시 DH 매개변수

3. 클라이언트는 서버가 선택한 인증서를 CA 리스트의 공개키로 복호화한다.

   보내진 인증서가 정상적인 인증서 인지를 확인한다. 브라우저 내에는 CA 리스트가 있으며, 정식적으로 인증서를 발급하는 기관의 경우 인증서를 해독할 수 있는 공개 키가 CA 리스트에 있다. 공개 키 복호화 결과가 정상적으로 이루어진다면, 해당 기관이 인증하는 인증서라는 것을 확인되는 것이며, 이를 보낸 서버는 신뢰를 할 수 있는 서버 임을 증명하는 것이 된다.

   이후 클라이언트와 서버가 생성하여 주고 받은 랜덤 데이터들을 기반으로 임시 암호키 (세션키)를 생성한다.

4. 클라이언트는 세션 키(대칭 키)를 생성하여 소유하고, 이를 CA 공개 키를 통해 암호화하여 서버에게 보낸다.

5. 서버는 소유한 CA의 개인 키를 통해, 클라이언트가 보낸 세션 키(대칭 키)를 복호화한다.

   이를 통해 서버와 클라이언트는 SSL handshake 과정을 통해 서로를 신뢰할 수 있음이 확인된 것이다.

6. 이후 통신 작업은 세션 키 (대칭 키)를 통해 인증을 진행하며 데이터를 주고 받는다.

7. 통신 세션이 모두 완료되면 세션 키 (대칭 키)를 폐기한다.

참고
[HTTP] HTTP는 Stateless, Connectionless하다
TCP/IP 쉽게 이해하기
[10분 테코톡] 헌치, 써머의 HTTP