MoonNote

반응형
     

 

 

 

HTTP(HyperText Transfer Protocol)

HTTP(HyperText Transfer Protocol)는 웹 서버 및 웹 브라우저 간 데이터 전송을 위한 프로토콜입니다. 우리가 흔히 인터넷 주소창에 'http://www.naver.com'과 같이 URL 주소를 입력하면 이 웹 서버에 명령을 보내어 작동하게 되는 것입니다.

 

HTTP는 TCP/IP 기반의 어플리케이션 프로토콜로 이를 이해하기 위해서는 OSI 7 Layer를 이해하면 좋은데요. 추후 포스팅에서 OSI 7 Layer에 대해서 다루는 시간을 가져보도록하고 본문에서는 HTTP 구성에 대해서 설명을 드리겠습니다. 앞서 TCP/IP 기반이라고 말씀드렸던 것처럼 서버-클라이언트 형태로 데이터를 주고 받으며 HTML, TEXT, 이미지, 음성, 영상, 파일, JSON, XML 등 모든 것을 전송할 수 있습니다.

 

최초의 HTTP는 1991년 HTTP/0.9가 출시되면서 처음 소개되었고 현재 가장 많이 사용하는 버전은 1997년 1월에 출시된 HTTP/1.1 입니다. 이후 2015년 HTTP/2, 2020년 HTTP/3 버전을 출시하며 개발을 이어오고 있습니다. 구성은 Method, Path, Version, Headers, Body로 구성되고 기본적으로는 클라이언트가 80번 포트로 요청을 보내게 됩니다.

HTTP Request 구성 (출처 : MDN Web Docs)

그 다음으로 HTTP의 특징으로 보면 무상태(Stateless), 비연결성(Connectionless)가 있는데요. 이 부분은 예시를 들어서 소개하겠습니다.

 

무상태(Stateless) 
서버가 클라이언트 이전 상태를 보존하지 않는다는 의미입니다.
반대 의미로 상태 유지(Stateful)이란 단어도 있습니다.
이해를 돕기 위해 Stateful 예시를 보겠습니다.

     ▪ Stateful 예시
     고객 : 돼지 고기 한근 얼마하나요?
     직원 : 14,730원입니다.
     고객 : 2근 주세요.
     직원 : 29,460원입니다. 결제는 뭘로 도와드릴까요?
     고객 : 삼성 페이요.
     직원 : 카드 올려주시고요. 결제 완료되었습니다.

     ▪Stateless 예시
     고객 : 돼지 고기 한근 얼마하나요?
     직원 : 14,730원입니다.
     고객 : 2근 주세요.
     직원 : 네? 무엇을 2근 달라는 건가요?
     고객 : 아까 말한 돼지 고기요.
     직원 : 돼지 고기 가격이요? 몇근 드릴까요?

예시에서 볼 수 있듯이 Stateless는 실시간 요청에 대해서만 반응할 뿐 따로 상태 유지를 하지 않습니다. 반면 Stateful은 상태를 보관하여 클라이언트의 요청을 일상 대화를 주고 받듯이 문맥을 이어나갈 수 있습니다. 

 

위의 예시에서 언뜻보면 Stateful이 좋은거 아냐?라고 생각하실 수 있지만 꼭 그렇지만도 않습니다. 이런 요청과 응답에 대해 서버와 클라이언트의 관계로 생각해보면 Stateful의 경우 처음 클라이언트의 응답에 반응한 서버에서 계속해서 이어서 응답을 주어야지만 상태 유지가 가능하므로 항상 같은 서버가 유지되어야합니다. 반면, Stateless는 클라이언트의 요청에 어떠한 서버가 응답하든 상관 없으므로 클라이언트 요청이 증가할 때 그냥 서버를 늘려서 이를 커버할 수 있습니다. 하지만, 로그인과 같은 상태를 유지시켜야하는 시스템의 경우 Stateless로 설계할 수 없으므로 이러한 시스템은 Stateful로 설계된다고 보시면 되겠습니다. 개인적으로 어떤 시스템이건 요구 사항에 맞게 적절히 사용하는게 중요하다고 생각합니다. 다음은 비연결성(Connectionless)입니다.

 

비연결성(Connectionless)
요청에 대해 서버로부터 응답을 받으면 TCP/IP 연결을 끊어 버리는 것을 말합니다. 서버의 자원을 효율적으로 관리하고 수많은 클라이언트들의 요청에도 대응할 수 있도록 하기 위해 이러한 특성을 가집니다. 수십, 수백, 수천, 수만명이 이용하는 서비스지만 동시에 처리해야할 요청은 실제 몇 십개밖에 되지 않을 때를 생각하시면 될 듯합니다. 

     ▪ Connectionless 예시
      친구 2명이서 콘서트를 보러가기로 약속하고 A는 무리없이 티켓팅을 하였으나 B는 못한 경우
      친구 A : 나 티켓팅 완료했어. 너희도 했어? (17:00)
      친구 B : 지금하고 있는데 사이트가 뻗은거 같아...너가 할 땐 괜찮았어?
      친구 A : 아,,응 난 바로 땡하고 티켓팅하니 무리없이 진행되던데,,
      친구 B : 사람이 지금 몰렸나보다. 지금 다시 사이트 접속되는데 티켓이 모두 다 팔린 것 같아..
      *A의 요청은 정상적으로 처리 후 연결 해제
      *B의 요청은 너무 많은 요청으로 일시적인 서버 과부화, 이후 티켓팅 실패

 

HTTPS(Hypertext Transfer Protocol Secure)

HTTP 기반에서 Security 관련 항목이 추가된 개념으로 보시면 되겠습니다. 이런 측면에서 HTTPS는 HTTP over TLS, HTTP over SSL, HTTP Secure 등으로 불리기도 합니다. HTTP와는 다르게 HTTPS는 443 포트를 사용하며 제 3자가 정보를 볼 수 없도록 암호화를 지원하는 프로토콜이라고 보시면 되겠습니다. 암호화를 진행하는데 있어서 대칭키 암호화, 비대칭키 암호화를 간략히 설명드리면 다음과 같습니다.

대칭키 암호화
클라이언트와 서버가 동일한 키를 사용해 암호화/복호화를 진행함
키 노출에 각별한 주의를 요하지만 연산 속도가 빠름
비대칭 암호화
1개의 쌍으로 구성된 공개키(Public Key)와 개인키(Private Key)로 암호화/복호화를 진행
키 노출에 비교적 안정적인 편이지만 연산 속도가 느림

 

공개키로 암호화를 하게되면 개인키로만 복호화를 할 수 있으므로 자기 자신만 볼 수 있고, 개인키로 암호화하면 공개키로만 복호화하므로 모두에게 공개되어 내가 인증한 정보임을 알릴 수 있습니다.

Public Key Encryption (출처 : 위키 백과)

실제 HTTPS 연결 과정은 다음과 같은 순서로 이루어진다고 합니다.

 1. 브라우저가 웹사이트 서버에 연결을 요청
   2. 서버가 공개키를 브라우저에 전송
   3. 브라우저는 세션 키라 불리는 세 번째 키를 생성
   4. 브라우저는 서버에서 받은 공개키를 사용하여 세션 키를 암호화
   5. 암호화된 세션 키를 서버와 공유
   6. 서버는 비밀 개인키를 사용하여 받은 암호화된 세션 키를 복호화
   7. 공개키 암호화가 종료되고 대칭키 암호화로 대체
   8. 대칭키 암호화만 사용하여 서버와 세션을 유지하며 웹사이트를 나갈 때까지 이것이 유지

HTTPS 암호화 순서(출처 : tiptopsecurity)

 

 

 

 

 

 

 

 

 

 

※ 이 글이 도움이 되었다면 "👆🏻구독"과 "🤍공감" 버튼을 클릭해주세요. 클릭 한번이 글 쓰는데 큰 힘이 됩니다.

공유하기

facebook twitter kakaoTalk kakaostory naver band