[HTTP] 3.HTTP 기본

[HTTP] 3.HTTP 기본

 

1. 모든 것이 HTTP

- HTML, TEXT

- IMAGE, 음성, 영상, 파일

- JSON, XML (API)

- 거의 모든 형태의 데이터 전송 가능

- 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용

 

HTTP/1.1 버전 (1997)

- 가장 많이 사용 

 

TCP 기반 : HTTP/1.1, HTTP/2

UDP 기반 : HTTP/3

-> 2,3 점점 증가

 

확인하는법 : 크롬 - F12 - Network - 오른쪽버튼 - 프로토콜

 

HTTP 특징

- 클라이언트 서버 구조

- 무상태 프로토콜(스테이스 리스), 비연결성

- HTTP 메시지

- 단순함, 확장 가능

---

2. 클라이언트 서버 구조

- Request / Response 구조

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

- 서버가 요청에 대한 결과를 만들어서 응답

- 비즈니스 로직, 데이터 ->    서버에 밀어넣음 - UI, 사용성                  ->    클라이언트에 집중 -> 이렇게하면 서버와 클라이언트 독립적으로 진화 가능

---

3. 무상태 프로토콜 (Stateless, 스테이스리스)

[HTTP는 무상태 프로토콜 지향]

 

- 서버 : 클라이언트의 상태를  보존 X

장점) 서버 확장성 높음 (스케일 아웃)

단점) 클라이언트 추가 데이터 전송

 

Stateful, Stateless 차이

- Stateful    : 상태 유지

- Stateless : 상태 유지 X

 

[무상태 예시]

- 상태유지 : 중간에 다른 점원으로 바뀌면 안됨

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

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

                > 갑자기 고객이 증가해도 점원 대거 투입 가능

                > 갑자기 클라이언트 요청이 증가해도 서버 대거 투입 가능

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

 

Stateless 실무 한계

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

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

- 상태유지    예 ) 로그인

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

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

- 상태 유지는 최소한만 사용

---

4. 비 연결성 (Connectionelss)

[HTTP는 무상태 프로토콜 지향]

 

1) 연결을 유지하는 모델 (서버-클라이언트)

- 여러 클라이언트가 서버에 연결 유지 (요청-응답)

- 클라이언트 3이 연결 요청하는동안 클라이언트1,2는 연결이 유지되고 있음

   -> 연결을 유지하는 서버의 자원 소모

 

2) 연결을 유지하지 않는 모델 (서버-클라이언트)

- 클라이언트가 서버에 요청하고 응답을 받은 후 연결이 끊어짐

 

비 연결성

- HTTP는 기본이 연결을 유지하지 않는 모델

- 일반적으로 초 단위 이하의 빠른 속도로 응답

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

  ex) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지 않는다

- 서버 자원을 매우 효율적으로 사용 가능

 

비 연결성 한계와 극복

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

- 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라, JS/css/추가이미지 등 수 많은 자원이 함께 다운로드

- 지금은 HTTP 지속 연결 (Persistent Connections)로 문제 해결

- HTTP/2, HTTP/3에서 더 많은 최적화

 

HTTP 초기 - 연결, 종료 낭비

HTTP 지속연결(Persistent Connections) - 연결-> 요청/HTML응답 -> 요청/JS응답 -> 요청/이미지응답 -> 종료

 

Stateless 기억하자

- 서버 개발자들이 어려워하는 업무

- 같은 시간에 딱 맞추어 발생하는 대용량 트래픽 ex) 선착순 이벤트, 명절 KTX, 수강 신청

---

5. HTTP 메시지

[HTTP 메시지 구조]

[HTTP 요청 메시지]

- 요청 메시지도 body 본문을 가질 수 있음

 

[HTTP 응답 메시지]

 1) 시작라인 (start-line)

[요청메시지]

- 구성 : request-line / status-line

- request-line = <1> method SP(공백) <2> request-target SP <3> HTTP-version CRLF(엔터)

 

<1> HTTP 메서드

- 종류 : GET, POST, PUT, DELETE

- 서버가 수행해야할 동작 지정

   > GET    : 리소스 조회

   > POST : 요청 내역 처리

 

<2> 요청 대상

- absolute-path[?query] (절대경로[?쿼리])

* 절대경로 = "/"로 시작하는 경로

 

<3> HTTP 버전

 

[응답메시지]

- 구성 : request-line / status-line

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

 

<1> HTTP 버전

- HTTP 상태 코드 : 요청 성공, 실패를 나타냄

- 200 : 성공 - 400 : 클라이언트 요청 오류 - 500  : 서버 내부 오류

- 이유 문구 : 사람이 이해할 수 있는 짧은 상태 코드 설명 글

 

2) HTTP 헤더

- header-field = field-name ":" OWS field-value OWS (OWS : 띄어쓰기 허용)

- filed-name은 대소문자 구분 없음

 

용도

- HTTP 전송에 필요한 모든 부가정보

- ex) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증,  요청 클라이언트(브라우저) 정보, 서버 애플리케이션 정보, 캐시 관리 정보 등

- 표준 헤더가 너무 많음

- 필요시 임의의 헤더 추가 가능

 

3) 메시지 바디

 

용도

- 실제 전송할 데이터

- HTML 문서, 이미지, 영상, JSON 등 byte로 표현 가능한 모든 데이터 전송 가능

 

---

단순함 + 확장 가능

- HTTP는 단순하다

- HTTP 메시지도 매우 단순

- 크게 성공하는 표준 기술은 단순하지만 확장 가능한 기술!