HTTP(Hypertext Transfer Protocol)

HTTP

HTTP는 응용계층의 프로토콜. 클라이언트-서버 모델에서, 클라이언트는 HTTP요청, 서버는 HTTP응답.

웹환경에서는 모든것이 HTTP로 처리 된다.

 -> 이미지,음성,영상,파일,JSON,XML, 서버간 데이터를 주고 받을 때도 대부분 HTTP사용.

 

HTTP도 다양한 버전이 있다.

HTTP/0.9 : 1991년에 나오고 GET메소드만 지원. HTTP 헤더는 없다.

HTTP/1.0 : 1996년에 나오고 메소드 헤더 추가

HTTP/1.1 ★ : 1997년에 나옴, 가장 많이 사용한다.

HTTP/2 : 2015년에 나온 버전으로 성능개선

HTTP/3 : 현재 진행형으로 개발되고 있으며 TCP대신 UDP를 사용.

 

클라이언트-서버 구조

Request(요청,클라이언트), Response(응답,서버) 구조를 말함.

 -> 대부분의 비즈니스 로직은 서버에서 담당. 이후 완료된 결과를 클라에게 Response하는 방식의 구조

 -> 역할을 분리할 수 있다는 장점이 있음.

 

Stateless

Stateless서버는 서버가 클라이언트의 상태를 보존하지 않는 것.

서버의 확장성(스케일 아웃)이 높지만(비교적 간단하다는 의미), 클라이언트의 추가 데이터 전송이 필요.

 -> 클라이언트의 이전 행동을 모르니 매번 클라이언트측에서 추가행동을 이전의 행동을포함해 보내야함.

 

Stateless서버는 클라이언트의 요청을 매번 DB에서 값을 읽어온 후 처리한 뒤, DB에 기록하고 서버 메모리에는 들고있지 않음.

 -> 물론 아예 무상태를 유지하는게 아닌 최소한의 상태 유지는 사용한다고 함(로그인등)

 

즉 Stateless(웹서버)는 클라이언트의 상태를 유지하지 않기때문에 Scale-out이 간단하다는 장점이 존재함.

다만 Stateful서버에 비해 매번 DB에 접근해야한다는 점에서 상대적으로 속도가 느림(처리속도 및 응답성.)

Stateful

Stateful서버는 서버가 클라이언트의상태를 보존한다는 것.

 -> 게임서버는 대부분 Stateful서버.(MMORPG,FPS등등) 

 -> 많은 유저들이 서버에 접속해 실시간 상호작용을 서버에서 빠르게 처리 후 많은 클라이언트들에게 뿌려줘야함.

 -> 클라이언트의 정보를 서버 메모리에 들고있으므로 클라이언트측에서는 이전행동에 대한 추가 데이터는 필요하지않음.

 

즉 위와 같은 이유로 Stateful서버는 빠른 처리를 위해 매번 DB에서 값을 읽어오는 방식이 아닌, 서버에서 메모리를 들고 있는 방식이기에 (물론 최종 처리 후 값은 DB에 기록은 해야함) Stateless서버에 비해 속도가 빠름.(처리속도,응답성)

다만 Stateless서버에 비해 상대적으로 Scale-out이 힘든 구조.

 -> 서버에서 메모리를 들고있기때문에, 다른 B,C서버에 해당 클라이언트의 정보를 들고있다면 정합성이 무너질 수 있음.

 -> 물론 서버에서 데이터가 최신화가 되어 다른 서버에게도 통지를 해주는등 여러 방법이 있겠지만, 구조적 어려움이나 개발 난이도 상승 그리고 속도저하등의 문제가 있지 않을까 싶다. (최근에는 레디스라는 인메모리 DB를 통해 속도 저하의 문제는 어느정도 해결되지 않았나 싶다)

 

비연결성(connectionless)

TCP는 연결이라는 논리적 개념이 존재한다.

네이버와 같이 사람들이 많이 사용되는 웹의 경우에는 TCP로는 매우 많은 연결을 유지해야하고, 이는 곧 서버의 자원을 소모한다는 의미이다.

 -> 클라이언트측에서 요청을 하고 연결되었는데 몇시간동안 아무짓도 안한다면? -> 굳이 자원소모.

 

그렇기에 웹 환경에서는 비연결성이라는 개념이 기본으로 깔고간다.

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

 - 게임서버와 달리 실시간으로 클라이언트와 서버간에 주고받는 데이터가 한순간에 엄청 몰리는 경우는 많지않음.

  --> 일반적으로 하나의 요청에 대한 응답이 사람을 기준으로는 납득될 정도의 반응속도이기에.

  --> 위와같은 이유로 비연결성을 통해 서버 자원을 아끼는 방식을 채택.

 

다만 장점만 있는건 아니고, TCP환경에서 매번 연결을하고 끊는다는건 매번 3,4Way handshake과정을 거친다는 것.

또한 웹 환경에서의 요청은 매우 많은 데이터를 응답하기에 매번 연결을하고 끊는것이 마냥 효율적이진 않다는 얘기.

 

그렇기에 HTTP는 Persistent Connections라는 지속연결을 사용한다.

 -> 요청후 바로 끊어버리는게 아닌, 일정시간동안 열어두는것을 의미.

 -> http2와 http3는 더 성능이 개선됨.

 

HTTP 메시지

왼쪽밑은 응답메시

HTTP는 요청과 응답 메시지의구조.

위에서 말하는 공백라인은 꼭 필요하다고 함.

 -> 이러한 스펙들은 RFC7230을 자주 확인해보면 좋다.

 

요청 메시지의 시작 라인

start-line이라고도 하고, 요청은 request-line이라고도 한다.

request-line = method SP(공백) request-target SP HTTP-version CRLF

 -> GET /search?q=hello&hl=ko HTTP/1.1

 

HTTP 메소드는 GET,POST,PUT,DELETE등이 있음.

 -> 서버가 수행해야할 동작을 지정. (GET:리소스 조회, POST : 요청 내역 처리등)

요청대상은 /search?q=hello&hl=ko.

 -> /로 시작하는 절대경로.

HTTP 버전. 

 -> 말그대로 HTTP의 Version. (1.1~3)

 

응답메시지의 시작 라인

 

start-line이라고도 하고, 응답은 status-line이라고 한다.

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

 -> HTTP/1.1 200 OK.

 

여기서 중요한건 http 상태코드(status-code)

간단하게 200:성공, 400: 클라이언트 요청 오류, 500 : 서버 내부 오류

그리고 reason-phrase는 사람이 이해할 수 있는 짧은 상태의 문구.

 

HTTP 헤더

field-name: <- 필드네임에 콜론이 붙어있어야함.

 

HTTP헤더의 용도는 HTTP전송에 필요한 모든 부가정보가 담김.

 -> 메시지 바디의 내용, 크기, 압축,인증, 등등.. 표준 헤더 정보가 많음.

 -> https://developer.mozilla.org/ko/docs/Web/HTTP/Headers 참고.

 

HTTP 메시지 바디

실제 전송할 데이터.

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