Hypertext Transfer Protocol
http 정의는 여러번 했으니깐 넘어가겠다.
요즘은 hypertext를 넘어서 모든 형태의 데이터를 넘길 수 있고, 서버간의 실시간 데이터도 http로 주고받는다.
대규모 게임서버들은 여전히 tcp를 쓰지만, 모바일겜같은 일방향 통신게임들은 http로도 많이들 한다.
기반 프로토콜
TCP : HTTP/1.1 HTTP/2
UDP : HTTP/3
일단은 1.1이 주류지만, 2 3 도 증가세이다.
구글같은경우 전부 3을 쓰고 네이버도 2를 쓴다.
클라 서버 구조
이 글 참조
Stateless Protocol
상태를 유지하지 않는 프로토콜이다.
상태유지를 하는 경우, 중간에 점원이 바뀌면 정보를 인수인계 해야한다.
무상태는 중간에 바꿔도 아무 문제가 없다
갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.
무상태는 응답서버를 쉽게 바꿀 수 있다.
클라이언트가 요청에 정보를 다 담아서 보내기때문에 상태를 보관할 필요가 없고 서버가 망가지더라도 교체가 가능하다.
한계
모든것을 무상태로 설계할 수는 없다.
- 로그인이 필요없는 상태화면은 없어도 된다.
- 로그인이 필요하면, 로그린이 되어있다는 상태를 유지해줘야한다.
- 로그인은 일반적으로 큌와 서버 세션을 사용해서 유지하는데 세션이 날아가면 로그인이 풀린다.
- 가능하면 적게 사용해야 한다.
- 데이터 처리양이 조금 늘어난다.
connectionless
연결을 유지하는 모델은 클라이언트가 사용안해도 연결을 유지해야해서 자원낭비가 심하다
하지만 비연결모델은 요청 후 응답이 지나면 바로 연결을 끊어버린다. 이렇게 자원을 아낄 수 있다.
단점
- 기본적으로 TCP/IP연결을 계속 해야해서 3way handshake 시간이 추가적으로 걸린다
- 요청이 오면 HTML + CSS + Image + JS 같은 수 많은 자원들이 들어온다. 이게 비효율적이다.
- HTTP는 기본적으로 지속연결을 써서 해결한다.
- 2,3 에서는 더 최적화
연결지속 방식에서는 모든 연결이 완료될때까지 지정시간동안 연결을 유지한다.
HTTP 메세지
구조는 다음과 같다.
전체구조
start-line
header
emptyline CRLF
message body
요청
GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com응답
HTTP/1.1 200 OK start-line 시작 라인
Host: www.google.com
Content-Type: text/html;charset=UTF-8
Content-Length: 3423
<html>
<body>...</body>
</html>요청 메세지 시작라인
request line = method SP(공백) request-target SP HTTP-version CRLF(엔터)
총 3가지로 구성된다.
method
GET, POST, PUT, DELETE 로 수행동작을 지정한다.
request - target
절대경로로 시작하는 목표 쿼리
http 버전
버전 들어간다.
응답 메세지 시작라인
status-line = HTTP-version SP status-code SP reason-phrase CRLF
version
버전이다
status code
응답코드이다. 200 400 500으로 구분되는 그 코드이다.
200 - 성공
400 - 클라이언트 요청 오류
500 - 서버 요청 오류
이유문구는 간단한 설명이다.
해더라인
header-field = field-name ":" OWS field-value OWS
호스트의 소대문자 구분을 하지 않는다.
용도
전송에 필요한 모든 부가정보를 가지고 있다.
메세지
실제 전송할 데이터가 있으며, byte로 표현되는 모든 데이터가 전송가능하다.
단순해서 확장 가능하다
