본문 바로가기

개인적으로 공부한 것을 정리해 놓은 블로그입니다 틀린 것이 있으면 댓글 부탁 드립니다!


Web 지식

웹 개발 기본 공부 5 - HTTP 란?

반응형

 

HTTP 특징 

 

1.클라이언트 서버 구조이다 

 

Request Response 

클라이언트는 서버에 요청을 보내고 ,응답을 대기

서버가 요청에 대한 결과를 만들어서 응답하는 구조이다.

비지니스 로직과 데이터는 서버에서 처리하고 클라이언트에서는 UI와 UX에 집중하여

클라이언트와 서버가 각각 독립적으로 진화할 수 있다.

 

 

2.무상태 프로토콜을 지향한다. (stateless)

 

-서버가 클라이언트의 상태를 보존하지 않는다

 

장점: 서버 확장성이 높다 (스케일 아웃)

단점: 클라이언트가 추가 데이터를 전송해야 한다.

 

stateless 와 stateful의 차이

 

예시1) 식당에서 햄버거를 주문한다는 예시로 stateful(상태유지)를 설명하면 아래와 같다.

 

고객: 햄버거 얼마 인가요?

점원 : 만원입니다. 

 

고객: 2개 주세요

점원: 2만원입니다,  카드 현금 뭘로 결제하시겠어요?

(고객이 햄버거를 주문한다는 상태를 유지하였기 때문에 계산이 가능하다)

 

고객:카드로 결제할게요.

점원:2만원 카드 결제되었습니다.

(고객이 햄버거 2개를 카드로 결제한다는 상태가 유지되었기 떄문에 결제가 되었다. )

 

만약 stateless (무상태) 라면?

 

고객: 햄버거 얼마 인가요?

점원 : 만원입니다. 

 

고객: 햄버거 2개 주세요 

점원: 햄버거 2개는 2만원입니다,  카드 현금 뭘로 결제하시겠어요?

 

고객: 햄버거 2개 카드로 결제할게요.

점원: 햄버거 2개 2만원 카드 결제되었습니다.

 

위의 예시에서 무상태의 단점(고객이 요청시 정보를 추가로 제공해야한다.)이

생긴다 하지만 만약 점원이 바뀌는 상황이라면?

 

 

예시2 ) 식당에서 햄버거를 주문하는 중에 점원이 바뀜 

 

stateful 

 

고객: 햄버거 얼마 인가요?

점원 : 만원입니다. 

 

고객: 2개 주세요

점원2: ? 무엇을 2개?

(점원2는 햄버거를 주문한다는 상태를 알지 못하기 때문에 다시 물어야한다)

 

stateless 라면?

 

고객: 햄버거 얼마 인가요?

점원 : 만원입니다. 

 

고객: 햄버거 2개 주세요

점원2: 햄버거 2개 2만원입니다. 

 

고객이 항상 필요한 정보를 넘기기 때문에 중간에 점원이 바뀌어도 상관없다(서버의 확장성)

 

stateful ,stateless 차이 정리 

 

상태유지 : 중간에 다른 점원으로 바뀌면 안된다. (항상 같은 서버가 유지되어야 한다.)

( 중간에 다른 점원으로 바뀔 때 상태 정보를 다른 점원에게 미리 알려줘야 한다.)

 

무상태: 중간에 다른 점원으로 바뀌어도 된다 

  - 갑자기 고객이 증가해도 점원을 대거 투입할 수 있다.  

  - 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다. 

  - 무상태는 응답 서버를 쉽게 바꿀 수 있다. ->무한한 서버 증설 가능

 

 

stateless의 한계 

 

-모든 것을 무상태로 설계 할 수 있는 경우도 있고 없는 경우도 있다. 

-무상태

  예) 로그인이 필요 없는 단순한 서비스 소개 화면 

-상태유지

  예) 로그인

-로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지

-일반적으로 브라우저 쿠키와 서버 세션등을 상용해서 상태를 유지한다 .

-상태 유지는 최소한만 사용해야 좋다.

-데이터를 너무 많이 보낸다. 

 

3. 비연결성 (conectless)

 

-요청시에 연결하여 응답이 완료되면 연결을 끊는다. 

-서버는 연결을 유지하지 않고 최소한의 자원만 유지한다.

-초단위 이하의 빠른른 속도로 응답

-1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 작다

-서버 자원을 매우 효율적으로 사용할 수 있다.

 

한계와 극복

 

한계

-TCP/IP 연결을 새로 맺어야 한다 - 3 way handshake 시간 추가 

-웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css 추가 이미지등 수 많은 자원이 함께

다운로드 된다. 

 

극복

-HTTP 지속 연결(Persistent Connections)로 문제를 해결한다.

 

 

HTTP 메시지 구조

start-line 시작 라인
header 헤더
empty line 공백 라인 (CRLF)
message body

2. header  

 

-  HTTP 전송에 필요한 모든 부가정보가 들어있다.

   예)메시지 바디의 내용, 메시지 바디의 크기 , 압축 ,인증 ,요청 클라이언트(브라우저) 정보

, 서버 애플리케이션 정보, 캐시 관리 정보

- 필요시 임의의 헤더를 추가할 수 있다.

 

3.message body

 

- 실제 전송할 데이터가 들어간다. 

- HTML 문서 , 이미지 ,영상 ,JSON 등 byte로 표현할 수 있는 모든 데이터를 전송할 수 있다.

 

 

 

HTTP 요청 메시지 구조

 

GET / search ?q=hello&hl=ko HTTP/1.1  start-line
Host: www.google.com                        header
empty line (CRLF)

 

start-line (요청 메시지)

 

-start-line은  request-line이루어져 있다.

 

request-line 구조 

 

- method SP(공백) request-target(path) SP HTTP-version CRLF(http 버전)

- method = GET, POST , PUT , DELETE ... 등이 있다  서버가 수행해야 할 동작을 지정한다

- request-target =  요청 대상을 의미하며 절대 경로 표현한다.

 

예) GET / search ?q=hello&hl=ko HTTP/1.1 

 

header (요청 메시지)

 

-header-field = field-name ":" OWS field-value OWS 

 *ows는 띄어 쓰기 허용을 의미

예)Host: www.google.com     

-field-name은 대소문자 구분하지 않는다. 

 

HTTP 응답 메시지 구조

 

HTTP/1.1 200 OK                                 start-line
content-type : text/html ;charset=UTF-8
content-length: 3423                             header
empty line (CRLF)
<html>
  <body></body>                       message body
</html>

 

시작라인 (응답 메시지)

 

-start-line은 status-line으로 이루어져 있다.

 

status-line 구조

 

HTTP-version SP status-code SP reason-phrase CRLF

-HTTP status-code :200(성공) , 400(클라이언트 요청 오류), 500 (서버 내부 오류) 등 ... 

요청 성공, 실패를 나타내는 의미를 담은 코드와 사람이 이해할 수 있는 짧은 코드를 나타낸다.    

 

 

반응형