Server Communication(HTTP/S)

1. HTTP 란?

HT(HyperText): 
문서와 문서가 링크로 연결되도록 하는 테크로 구성된 언어를 뜻하는
HTML(HyperText Markup Language)의 HyperText와 의미가 동일합니다. 

T(Transfer): 
전송하다는 의미를 가지며 전송은 보내는 주체, 받는 주체가 있다는 것이 특징입니다. 

P(Protocol): 
프로토콜은 협약, 통신규약의 의미를 가지며 물리적으로 떨어진 컴퓨터끼리 어떻게 HTML 파일을 주고 받을지에 대한 약속입니다. 

 

각기 다른 목적을 수행하기 위해 존재하는 서버(Server)는 네트워크 통신의 형태로 다양한 데이터를 주고 받는데 활용됩니다. 

1. 서버가 다양한 데이터를 주고 받을 때 컴퓨터들끼리 HTML 파일을 주고 받을 수 있게 하는 소통 방식 또 약속으로
   대부분 HTTP 규약 따릅니다. 

2. 클라이언트와 서버 사이에 이루어지는 요청/응답(request/response)프로토콜입니다. 

 

2. HTTP의 특징 

1. ) Request(요청) / Response(응답)

앞에서 설명한 HTTP에 T(Transfer)는 전송으로 보내는 주체와 받는 주체가 있습니다. 

보내는 주체는 받는 주체에게 요청(Request)을 보내고 받는 주체는 요청을 보낸 주체에게 응답(Response)을 보냅니다. 

예를 들어 이 블로그 글을 보기 위해 클릭 했다면 서버에게 요청을 보낸 것이고 서버는 이 요청을 처리해 클라이언트에게 블로그 글을 제공하는 것으로 응답합니다. 

2. ) Stateless 

두 번째 특징인 Statelesssms는 State(상태) + Less(없음)을 의미합니다. 

상태가 없다는 것은 기억이 없다는 것이기도 합니다. 

 

각 HTTP 통신(요청/응답)은 독립적이라 과거 통신 내용에 대해 기억하지 못합니다. 

때문에 이를 해결하기 위해 매 통신마다 필요한 모든 정보를 담아 요청하여 보내야 합니다. 

예를 들어 커피를 주문하려고 한다면 (종업원 : Server / 고객: Client)

종업원: 무엇을 드릴까요?

고객: 아메리카노 주세요. 
종업원: Ice로 드릴까요 Hot으로 드릴까요? 

고객: 아메리카노 주세요. Ice로 주세요. 

종업원: 결제는 어떻게 해드릴까요? 
고객: 아메리카노 주세요. Ice로 주세요.  카드로 결제할게요. 

 

위의 내용과 같이 매 통신마다 필요한 모든 정보를 담아 Server에게 요청을 보내야 하는 것입니다. 

온라인 쇼핑몰에서 로그인 후 장바구니 페이지로 이동하여 연속된 요청과 응답에 대한 데이터 처리가 필요한 경우

로그인 토큰 또는 브라우저의 쿠키, 세션, 로컬 스토리지 같은 기술이 필요에 의해 만들어졌습니다. 

 

 

3. HTTP 메시지 구조 

HTTP를 통한 요청과 응답 시 메시지 구조가 존재하는데 프론트엔드(클라이언트)와 백엔드(서버)는 이 구조를 활용하여 프론트는 백엔드에게 데이터를 요청하고 백엔드는 요청을 받아 응답합니다. 

 

3 -1. Request 메시지 구조

요청은 메시지이고 이 메시지 구조는 크게 세 부분으로 구성 됩니다. 

 

1. )  Start Line 

요청의 첫 줄이며 글의 제목과 같은 역할을 합니다. 

• HTTP Method: 
  해당 요청이 의도한 액션을 정의하는 부분으로 GET, POST, DELETE가 많이 사용됩니다. 
• Request Target: 
  해당 Request가 전송되는 목표 URL 입니다. 
• HTTP version: 
  말 그대로 사용되는 HTTP 버전으로 주로 1.1 버전이 많이 사용됩니다. 

 

2. ) Hearders 

해당 요청에 대한 메타 데이터(추가 정보)를 담고 있는 부분입니다. 

• { key:value } 의 Json 타입의 형태
• Hearders: {
  Host: 요청을 보내는 웹사이트의 기본 주소(www.dream.co.kr)
  User-Agent: 요청을 보내는 클라이언트의 브라우저 정보(chrome) 
  Content-Type: 해당 요청이 보내는 메시지 Body의 타입(application/json) 
  Content-Length: Body 내용의 길이(50)
  Authorization: 회원의 인증/인가를 처리하기 위해 로그인 토큰 등을 포함
  }

 

3. )  Body 

해당 요청의 실제 내용이며 요청 method에 따라 내용이 없을 수도 있습니다. 

 

• 로그인의 요청일 경우의 Body 내용 예시
  Body: {
  "username": "dream",
  "password": "dream123"
  }

 

3 - 2. Response 메시지 구조

응답도 요청과 마찬가지로 메시지이며 구조 역시 크게 세 부분으로 구성되었습니다. 

1. )  Start Line 

응답 첫 번째 줄로 요청에 대한 처리 상태를 클라이언트에게 알려줍니다.

• HTTP Version: 요청의 HTTP 버전과 동일
• Status Code: 응답 메시지 상태 코드(200, 400, 500 등등) 
• Statue Text: 응답 메시지의 상태를 간략하게 설명해주는 텍스트(성공이면 성공에 대한 메시지를, 실패 및 오류면 그에 해당하는 메시지를 전송) 

 

2. ) Headers 

요청의 헤더와 동일하고 응답의 추가 정보(메타 데이터)를 담고 있습니다. 

다만 응답에서만 사용되는 header의 정보들이 있습니다. (예시: 요청 브라우저 정보가 담긴 User-Agent 대신 Server header가 사용) 

• { key:value } 의 Json 타입의 형태
• Hearders: {
  Host: 요청을 보내는 웹사이트의 기본 주소(www.dream.co.kr)
  Content-Type: 해당 요청이 보내는 메시지 Body의 타입(application/json) 
  Content-Length: Body 내용의 길이(50)
  }

 

3. ) Body 

일반적으로 요청 Body와 동일하며 형태에 따라 데이터를 전송할 필요가 없는 경우 요청과 동일하게 Body가 없을 수있습니다. 많이 사용되는 Body의 데이터 타입은 JSON입니다. 

• Body: {
  "message" : "success",
  "token": "dksfksdfhksfhi"
  }

 

4. HTTP Request Methods

위의 Request(요청)의 메시지 구조의 Start Line에 HTTP Methods에 대해서 살펴보려 합니다. 

HTTP 메서드는 클라이언트가 웹 서버에 사용자 요청의 목적이나 종류를 알리는 수단으로 처음 HTTP에서는 메서드는 GET 하나 밖에 없었지만 이후 다양한 메서드들이 생겨났습니다. 

 

다양한 메서드들중 자주 사용되는 3가지 메서드에 대해 살펴보겠습니다. 

 

1. ) GET 

웹 페이지에 접속해 필요한 데이터를 서버로부터 받아올 때 사용하는 메서드이며 가장 간단하고 많이 사용됩니다. 

 

2. ) POST 

데이터를 생성 및 수정할 때 주로 사용하는 메서드로 대부분의 경우 요청에 Body가 포함되어 보내집니다. 

 

3.) DELETE 

서버에 저장된 특정 데이터를 삭제할 때 사용하는 메서드입니다.(예를 들어 장바구니 물품을 삭제하는 요청에 사용될 겁니다.) 

 

 

5. Response Status Code

요청에 대한 메서드를 알아봤다면 이번에는 응답 메시지 구조 중 Start Line에 Status Code에 대해 알아보도록 하겠습니다. 

응답 상태 코드(Response Status Code)는 요청이 어떻게 처리 되었는지 알려주는 코드로 여러 개 그룹으로 나뉘고 상태 코드 숫자에 따라 각각의 의미가 내포되어 해당 코드 숫자를 보고 응답의 성공 여부를 파악할 수 있습니다. 

 

자주 사용하고 보게 되는 응답 그룹 3개와 상태코드를 알려드리겠습니다. 

1. ) Successful Response 

• 200: Ok 
  백엔드 서버에서 요청에 대한 처리가 성공적으로 되었을 때의 상태 코드
• 201: Created 
  요청이 성공적이며 새로운 리소스가 생성되었을 때 상태코드 
  일반적으로 POST, PUT 요청 이후 사용 
• 204: No Content
  요청이 성공했으며 제공할 응답 메시지가 없을 경우 상태코드 
  주로 DELETE 요청으로 리소스가 성공적으로 삭제되고 응답으로 제공할 콘텐츠가 없을 경우 사용

 

2. ) Client Error Responses 

• 400: Bad Request 
  해당 요청이 잘못되었을 때 상태코드
  주로 요청의 Body의 내용이 잘못된 경우 사용( 데이터 타입이 String(문자열)인데 Int(정수)로 들어온 경우) 
• 401: Unauthorized
  유저가 해당 요청을 진행하려면 먼저 로그인을 하거나 회원가입이 필요하다는 의미에 상태코드 
  (로그인을 하지 않으면 요청을 보낼 수가 없는 경우) 
• 403: Forbidden
  유저가 해당 요청에 대한 권한이 없다는 의미를 나타내는 상태코드 
  접근 불가능한 정보에 접근한 경우 사용 
• 404: Not Found 
  요청된 URL이 존재하지 않는다는 의미를 나타내는 상태코드 

3. ) Server Error Response 

• 500: Internal Server Error 
  서버에서 에러가 날 경우 사용되는 상태코드 

 

6. HTTPS란? 

앞서 살펴본 것과 같이 HTTP는 클라이언트와 서버 간 통신을 위한 프로토콜입니다. 

웹 서버와 사용자 브라우저는 데이터를 일반 텍스트로 교환하며 이런 교환을 HTTP로 요청을 전송하고 받아 응답합니다. HTTP 프로토콜은 네트워크 통신을 작동하게 하는 기본 기술입니다. 

그러나 기존 HTTP 방식은 요청 및 응답을 주고 받는 중에 전송 중인 데이터를 가로채면 누구나 데이터를 읽을 수 있었습니다. 이런 경우 중요한 정보를 서버에 전송하게 되면 전혀 암호화 되지 않은 상태로 인터넷을 돌아다니게 되는 것입니다. 

 

이러한 문제점을 해결하기 위해 나온 것이 HTTPS 입니다. 

HTTPS는 HTTP의 보안적 문제를 해결하는 프로토콜이며 SSL(Secure Sockets Layer)프로토콜 위에 돌아가게 하여 클라이언트와 서버가 주고 받은 텍스트를 암호화 시켜줍니다. 

즉, HTTPS는 HTTP프로토콜 + SSL 프로토콜 인 것입니다. HTTPS를 사용하게 되면 통신 내용이 공격자에게 공격 받는 것을 방지할 수도 있고 클라이언트는 접속하려는 서버가 신뢰할 수 있는 서버인지 판단할 수 있게 됩니다. 

 

6 - 1. SSL 프로토콜이란?

SSL 프로토콜은 CA(Certificate Authority)은 SSL 보안 인증서를 발급해주는 곳에 발급한 인증서를 사용해 작동합니다. 

SSL 인증서는 클라이언트와 서버간의 통신을 제 3자가 보증해주는 전자화된 문서로 서비스의 정보(인증서를 발급한 CA, 서비스의 도메인 등)와 서버의 공개키가 포함되어 있습니다. CA에 비공개키로 암호화가 되어 있는데, 클라이언트가 보유한 검증된 CA 공개키에 의해 복호화가 가능합니다. (브라우저는 신뢰된 CA 기업의 공개키는 모두 보유하며 해당 키로 복호화가 가능하다는 거은 해당 데이터가 CA기업으로 들어온 것임이 증명된 것이고 클라이언트는 인증서 내부 존재하는 서버의 공개키가 CA기업의 보완성 검증이 완료된 것임을 확인할 수 있습니다.)

 

클라이언트가 서버에 접속해 서버는 클라이언트에게 이 인증서 정보를 전달하고 클라이언트는 먼저 인증서의 정보가 신뢰할 수 있는지 확인 후 작업을 수행하게 됩니다. 

 

서버 측에서 사이트를 신뢰할 수 있게 되고 실제 통신 시 사용할 대칭 키인 "세션키"를 생성해 해당 키를 활용해 암호화 된 통신을 진행합니다. 

 

 

6 -2. SSL Handshake 란? 

SSL 프로토콜을 활용해 통신을 수립하는 과정을 SSL Handshake라고 합니다. 

1. ) Client hello:
클라이언트가 서버에게 다음과 같은 정보를 전달

• 클라이언트가 사용하는 SSL 버전
• 지원하는 암호화 방식 모음
• 임의의 난수
• 세션 ID (만약 이미 한 번 SSL Handshake 과정이 완료된 경우) 

2. ) Server hello:
서버는 Client hello의 응답으로 다음과 같은 정보를 전달

• 클라이언트가 지원하는 암호화 방식 중에서 서버가 지원하는 암호화 방식 
• 서버의 공개키를 가지고 있는 SSL 인증서
• 임의의 난수

3. ) Verity Server Certificate: 
클라이언트가 서버의 SSL 인증서를 검증

 

4. ) Client Key exchange:
검증이 완료되어 SSL 인증서로부터 얻은 서버의 공개키로 문자열을 암호화해 전달

 

5. ) Send Client Certificate:
만약 서버가 클라이언트의 인증서를 요구한다면 서버의 인증서와 같은 방식으로 암호화를 진행해 함께 전송

 

6. ) Verify Client Certificate:
서버가 클라이언트로 받은 암호화된 문자열을 서버의 개인키 해독

 

7. ) Client "finished":
클라이언트가 "클라이언트가 만든 임의의 난수", "서버가 만든 임의의 난수", "Client Key exchange 때 전송한 문자열"을 이용해 대칭키로 활용할 "세션키"를 생성 후 클라이언트가 세션키로 암호화된 "finished" 메시지를 전송

8. ) Server "finished":
서버가 "클라이언트가 만든 임의의 난수", "서버가 만든 임의의 난수", "Client key exchange 때 전송한 문자열"을 이용해 대칭키로 활용할 "세션키"를 생성 후 서버가 세션키로 암호화된 "finished"메시지를 전송

 

9. ) Exchange message:
클라이언트와 서버 양쪽 모두 "finished"을 전달 받으면 핸드셰이크가 완료되고, 세션키를 이용해 HTTP 통신 시작