참고
모든것이 HTTP
NOTE
네트워크를 통해 서버로부터 데이터를 가져오기 위한 통신으로 크게 2가지가 존재한다
•
HTTP 통신
◦
단순하고 확장이 가능하다.
◦
stateless 프로토콜(각 요청은 다음 요청에 영향을 미치지 않는다.), 비연결성
◦
웹 페이지 불러오기, 데이터 전송에 사용된다.
•
Socket 통신
◦
TCP/UDP 프로토콜을 직접 사용하여 통신하는 경우
◦
stateful 프로토콜
◦
실시간 어플리케이션, 게임, 채팅에 사용된다.
역사
NOTE
1.
HTTP/0.9 (1991년)
•
GET 메서드만 지원, HTTP 헤더X
2.
HTTP/1.0 (1996년)
•
메서드, 헤더 추가
3.
HTTP/1.1 (1997년)
•
가장 많이 사용, 우리에게 가장 중요한 버전
•
1997 → 1999 → 2014 순으로 개정됨
4.
HTTP/2 (2015년)
•
성능개선
5.
HTTP/3 (진행중)
•
TCP 대신에 UDP 사용, 성능 개선
메시지에 모든 것을 전송
NOTE
•
거의 모든 형태의 데이터 전송 가능
◦
HTML, TEXT , IMAGE, 음성, 영상, 파일, JSON, XML(API)
•
서버 간에 데이터를 주고받을 때도 대부분 HTTP 사용
◦
실무에서 통신할 때 TCP 프로토콜을 직접 사용해서 통신하는 경우는 게임 서버를 제외하고 거의없다.
HTTP 기반 프로토콜
NOTE
•
TCP
◦
HTTP/1.1 , HTTP/2
•
UDP
◦
HTTP/3
◦
현재는 HTTP/1.1 주로 사용, 2~3도 점점 증가하고 있다
클라이언트 서버 구조
NOTE
클라이언트 - 서버 ⇒ Request - Response 구조
클라이언트와 서버를 개념적으로 분리하는 것이 중요하다!!
•
클라이언트
◦
서버에 요청(Request)을 보내고 응답을 대기
◦
UI, UX 사용성에 집중
•
서버
◦
요청에 대한 결과를 만들어서 응답(Response)
◦
비즈니스 로직, 데이터 처리에 집중한다.
Stateful(상태유지), Stateless(무상태)
NOTE
Stateful - 상태유지
동일한 점원이 계속해서 이전값을 기억해서 대답해주고 있음
Stateless - 무상태
질문마다 점원이 바뀌어서 구체적으로 질문을 보내야함
Stateful, Stateless 차이점
NOTE
Stateful - 상태유지 (항상 같은 서버가 유지되야함)
서버1은 클라이언트 A가 요청한 노트북, 2개라는 상태를 모두 유지 중
서버1이 죽어버리면 결제를 처음부터 다시해야함..
Stateless - 무상태 ( 아무 서버나 호출해도 된다 ⇒ 확장성 유리!)
클라이언트A가 모든 정보(노트북, 2개)를 담아서 서버1에 요청하면, 서버1은 상태를 보관하지 않고 응답만한다.
서버1이 먹통이 되어도 동일한 요청을 다른 서버로 보내서 응답받으면 된다.
스케일 아웃( 서버 여러대 사용하기 )에 유리하다
실무 한계
NOTE
실무에서는 상태를 유지해야하는 경우가 있다.. 가능한 무상태로 설계하고, 상태 유지는 최소한만 사용하자!
1.
무상태
•
로그인이 필요없는 단순한 서비스 소개 화면
2.
상태 유지 - 로그인
a.
로그인한 사용자의 경우 로그인 했다는 상태를 유지해야함
b.
일반적으로 브라우저 쿠키와 서버 세션 등을 사용해 유지함
비 연결성
연결을 유지하는 모델
NOTE
각 클라이언트는 최초연결인 경우 TCP/IP 연결을 한다.
각 클라이언트는 서버와 계속 연결이 유지되고, 자원을 소모하게 됨
연결을 유지하지 않는 모델( HTTP 초기방식 )
NOTE
각 클라이언트는 최초연결인 경우 TCP/IP 연결을 한다.
각 클라이언트의 필요한 요청이 끝나면 서버와 연결을 종료한다 (최소한의 자원 유지)
비 연결성
NOTE
HTTP는 기본이 연결을 유지하지 않는 모델이다!
•
일반적으로 초 단위 이하의 빠른 속도로 응답이된다
•
1시간 동안 수천명이 사용해도 실제 서버에서 동시에 처리하는 요청은 매우 작음
단점
•
3-way-handshake의 시간이 너무 많아진다
•
TCP/IP 연결을 새로 맺어야함
◦
3 way-handshake 시간이 계속해서 추가된다.
•
웹 브라우저로 사이트를 요청하면 HTML, CSS, JS… 수많은 자원이 함께 다운로드
◦
자원을 다운로드 받을 떄마다 3 way-handshake 한다
극복
•
HTTP 지속 연결(Persistent Connections)로 해결
•
HTTP/2 , HTTP/3 에서 더 많은 최적화
HTTP 지속 연결
NOTE
HTTP 초기 - 연결, 종료 낭비
연결 → 자원 요청/HTML 응답 → 종료 ( 필요한 자원이 있을 떄마다 반복 ) 1.1 이전버전
HTTP 지속 연결(Persistent Connections)
필요한 자원이 있으면 연결을 유지하고, 없으면 종료한다 1.1 이후
Stateless 와 Connectioless의 차이
NOTE
•
Stateless
◦
클라이언트 서버 사이에 상태를 유지하지 않음
•
Connectionsless
◦
TCP/IP 커넥션 연결을 지속하지 않는다.
HTTP 요청 메시지와 HTTP 응답 메시지
NOTE
HTTP Request와 HTTP Response의 형태는 차이가 있다!
응답이 상태코드와, 여러 데이터를 더 보냄
HTTP 메시지 구조
NOTE
•
start-line
•
header
•
empty line
◦
공백 라인 (무조건 있어야 함)
•
message body
◦
요청 메시지와 응답 메시지는 start-line 부분만 차이가 있다
요청 메시지
NOTE
1.
Start-line
•
HTTP 메서드
•
path / query string
•
http 버전
2.
header
•
호스트(도메인명)
3.
empty line
4.
message body
•
전송할 데이터가 없으면 공백
응답 메시지
NOTE
1.
Start-line
•
HTTP 버전
•
HTTP-version statud-code reason-phrase CRLF(엔터)
•
status-code(HTTP 상태 코드)
2.
header
3.
empty line
4.
message body
HTTP 메시지 헤더
NOTE
HTTP 전송에 필요한 모든 부가 정보를 담는다 ( 메시지 바디 내용, 크기, 압축, 인증, 요청
클라이언트 정보 , 서버 등 …
header-field = field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용)
ex) 바디 내용, 바디 크기, 압축 등 표준헤더가 굉장히 많음 (임의 헤더 추가가능)
질문
Q. 대부분 서비스는 세션 등으로 로그인으로 상태를 유지하고 있는데, 그럼 대부분의 서비스에서 서버가 확장될 수 없다는 것인가?
NOTE
•
Q. 쿠키나 세션을 사용해 서버에 클라이언트 상태를 저장하는 경우, HTTP의 stateless한 특성이 사라지는 것인가?
NOTE
•