HTTP(Hyper Text Transfer Protocol)
http는 네트워크 상에서 데이터를 주고 받는 프로토콜이다. 프로토콜이므로 통신 규칙 정도로 이해하면 될것 같다.
http로 HTML, IMAGE, 영상, JSON, API 등 거의 모든 형태의 데이터를 전송 가능하다. http는 버전 3 즉 http/3가 현재 개발 진행 중이다. 우리가 가장 많이 사용하는 버전은 http/1.1이다. http/3은 TCP 대신 UDP 사용하는 방식으로 만들어 졌다. 정리를 하다보니 TCP와 HTTP 모두 프로토콜인데 둘 중 하나만 써야하는 것 아닌가? http가 tcp를 사용하는 것은 뭐지 라는 의문이 들어서 찾아보았다.
OSI 7 계층은 다양한 통신 시스템이 표준 프로토콜을 사용하여 통신할 수 있도록 국제 표준화 기구가 만든 개념 모델이다.
네트워크에서 통신이 일어나는 과정을 나누어 놓은 것이다. 단계별로 데이터를 감싸면서 패킷을 만드는 것 같다. 그림에서
알 수 있듯이 통신을 할 때 하나의 프로토콜만 사용하는 것이 아니다. http와 tcp는 다른 계층에 있으므로 위의 의문은 해결할 수 있다.
다음으로 http의 특징을 소개하겠다.
- 클라이언트 서버 구조 - 클라이언트와 서버를 분리시키는 것이 중요하다고 한다. 보통 비지니스 로직, 데이터는 서버에 저장하고 UI, 사용성 관련된 것들을 클라이언트에 저장한다. 이처럼 분리시켜야 유지 보수할 때 동시에 둘 다 건들이지 않아도 되고 독립적으로 발전 가능하다고 한다. 클라이언트 서버 구조는 클라이언트가 요청을 서버에 보내고 서버가 응답하는 방식으로 작동한다.
- 무상태(Stateless) 프로토콜 - 서버가 클라이언트의 상태를 보존하지 않는다. 처음에 설명을 들을 때는 장점이 존재하는지 오히려 불편한 점이 많은 것이 아닌가 생각이 들었다. 필자가 클라이언트라고 가정해보겠다. 내가 서버한테 '나는 음료는 콜라만 먹을거야.' 한 후 '음료 2잔 줘'라고 요청을 했다. 이때 서버가 콜라 2잔을 줬다면 이것은 상태 유지(Stateful)이다. 서버가 나는 콜라만 먹는다는 정보를 유지하고 있기 때문이다. 무상태 서버한테 '음료 2잔 줘'라고 했다면 서버의 반응은 '무슨 음료를 두 잔 달라는거야'이다. 무상태 서버한테는 항상 '콜라 2잔 줘'라고 요청을 해야한다. 무상태의 장점은 확장성이 높은 것이다. 서버1이 고장나서 서버2한테 요청을 해야할 때 무상태 프로토콜은 요청에 모든 메세지가 담겨 있으므로 지장이 전혀 없다. 서버를 수평적으로 계속 늘려도 (무한 서버 증설 가능) 지장이 없다는 것이다. 상태 유지라면 서버를 늘릴 때마다 기본 세팅을 다시 해주어야 한다. 여기서 알 수 있듯이 요청 메세지의 정보가 많다는 단점도 있다.
무상태로 설계하는 것이 대부분 좋지만 로그인 같은 경우는 상태 유지를 해줘야한다. 그렇지 않으면 한 회원이 로그인 후 웹 사이트에서 활동 할 때 계속 로그인 여부를 확인 해야할 것이다. 이와 같은 특수한 경우를 고려하며 상태 유지는 최소한으로 사용하는 것이 좋다. - 비연결성 - 클라와 서버 사이에서 요청과 응답 한 사이클이 완료되면 연결을 끊는다. 서버가 응답하는 속도는 초 단위 이하로 빠르다고 한다. 그래서 비연결성 때문에 동시에 처리하는 요청은 매우 적다. (1초의 오차 없이 동시에 요청이 많이 들어오는 경우는 드물다. 티켓팅, 선착순 이벤트 등등 제외하면) 덕분에 서버 자원을 매우 효율적으로 사용할 수 있다. 하지만 여기서 오는 단점도 있다. 연결을 유지하고 있지 않기에 클라에서 요청이 올때마다 3 way handshake(TCP를 사용하기에)를 진행해주어야 해서 시간이 추가된다.
이를 해결하기 위해 지속 연결(Persistent Connections)이 등장했다. 비연결성만 사용하면 웹 사이트를 사용할 때 html 파일받고 연결 끊고 다시 연결해서 css 받고 ....... 이 과정이 반복되어야 한다. 지속 연결을 사용하면 일정시간동안 TCP연결이 유지되어서 한번에 처리후 일정 시간 요청이 없을 경우 연결을 끊는다.
HTTP 메시지
우선 요청 메시지부터 분석해보겠다.
GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com
문법 : method SP(공백) request-target SP HTTP-version CRLF(엔터)
Host: 도메인
start line --> http 메서드(GET) SP(공백) request-target(/search?q=hello&hl=ko) SP(공백) HTTP-version(HTTP/1.1) CRLF(줄바꿈)
header -->Host: www.google.com (headr에는 http 정송에 필요한 모든 부가정보가 포함된다.)
SP(공백) 잘 지켜야 한다!
응답 메시지의 start line은 HTTP-version SP status-code SP reason-phrase CRLF 로 구성된다.
status-code는 요청 성공 실패를 나타낸다. 200은 성공, 400 클라이언트 오류, 500은 서버 오류 이다.
reason-phrase는 사람이 이해할 수 있는 짧은 상태 설명 역할이다 여기서는 OK라고 해주었다.
노란색 header에는 요청 메시지에서 설명했듯이 부가정보가 포함된다. 표준 헤더가 너무 많아 일일이 설명하기는 어렵다.
부가정보의 예로 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보, 캐시 관리 정보등이 있다.
파란색 message body에는 실제 전송할 데이터가 들어있다. byte로 표현할 수 있는 모든 데이터가 전송가능하다. (전송 가능한 데이터가 정말 많다. 이러한 이유로 강의에서 지금은 HTTP 시대라고 많이 강조하신다.)
'Network & CS' 카테고리의 다른 글
http 일반 헤더 (쿠키?) (3) | 2022.09.11 |
---|---|
HTTP 상태 코드 (404 error??) (1) | 2022.09.02 |
HTTP 메서드 (GET, POST, PUT, PATCH, DELETE), 메서드 속성 (0) | 2022.08.23 |
URI (0) | 2022.08.19 |
인터넷 네트워크 (IP, TCP, UDP, PORT, DNS) (0) | 2022.08.16 |