HTTP(HyperText Transfer Protocol)
HTTP 메세지에 모든 것을 전송
- HTML, TEXT
- 이미지, 음성, 영상, 파일
- JSON, XML(API)
- 거의 모든 형태의 데이터 전송 가능
- 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용
HTTP 특징
- 클라이언트 서버 구조
- 무상태 프로토콜(스테이스리스), 비연결성
- HTTP 메시지
- 단순함, 확장 가능
클라이언트 서버 구조
- Request Response 구조
- 클라이언트는 서버에 요청을 보내고, 응답을 대기
- 서버가 요청에 대한 결과를 만들어서 응답
클라이언트와 서버를 분리하는 것이 중요하다
- 비즈니스 로직과 데이터는 서버에 넣는다.
- 클라이언트는 UI를 그리고 사용성에 집중한다.
→ 클라이언트와 서버가 각각 독립적으로 진화할 수 있다.
무상태 프로토콜(Stateless)
- 서버가 클라이언트의 상태를 보존X
- 장점: 서버 확장성 높음(스케일 아웃 - 수평 확장)
- 단점: 클라이언트가 추가 데이터 전송
- 상태 유지: 중간에 다른 점원으로 바뀌면 안된다.
- 무상태: 중간에 다른 점원으로 바뀌어도 된다. 무상태는 응답 서버를 쉽게 바꿀수 있다.(무한한 서버 증설 가능)
Statless 실무 한계
1. 모든 것을 무상태로 설계 할 수 있는 경우도 있고 없는 경우도 있다.
2. 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지
3. 일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 상태 유지
4. 상태 유지는 최소한만 사용
5. 데이터를 많이 사용한다는 단점을 갖고 있다
비 연결성(connectionless)
TCP/IP 연결을 유지한다 → 서버는 연결을 계속 유지, 서버 자원 소모
TCP/IP 연결을 유지하지 않는다 → 서버는 연결을 계속 유지X, 최소한의 자원 유지
- HTTP는 기존이 연결을 유지하지 않는 모델
- 일반적으로 초 단위 이하의 빠른 속도로 응답
- 서버 자원을 매우 효율적으로 사용할 수 있음
한계와 극복
- TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가
- 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, CSS, 추가 이미지 등 수많은 자원이 함께 다운로드
- 매번 연결을 하고 받고 끊고 비효율 적이다.
- HTTP 지속 연결(Persistent Connections)로 문제 해결
- HTTP/2, HTTP/3 에서 더 많은 최적화
최대한 스테이스리스하기 설계하는게 중요!!!
-서버 개발자들이 어려워하는 업무 → 같은 시간에 딱 맞추어 발생하는 대용량 트래픽
HTTP 메세지
HTTP 메세지에 모든 것을 전송
시작 라인
start-line = request-line / status-line
request-line = method SP(스페이스) request-target SP HTTP-version CRLF(엔터)
△ HTTP 메서드
△ 요청대상(/search?q=hello&hl=ko)
△ HTTP Version
start-line = request-line / status-line
status-line = HTTP-version SP(스페이스) status-code SP reason-phrase CRLF
HTTP 상태 코드: 요청 성공, 실패를 나타냄
- 200: 성공
- 400: 클라이언트 요청 오류
- 500: 서버 내부 오류
- 이유 문구: 사람이 이해할 수 있는 짧은 상태 코드 설명 글
HTTP 헤더
용도
- HTTP 전송에 필요한 모든 부가정보 / 바디 빼고 필요한 메타데이터가 다 들어있다
- 필요시 임의의 헤더 추가 가능
HTTP 메시지 바디
- 실제 전송할 데이터
- HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능
단순함 확장 가능
- HTTP는 단순하다. 메세지도 매우 단순
- 크게 성공하는 표준 기술은 단순하지만 확장 가능한 기술
