[TIL] 22.11.30 HTTP 기본

김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식 강의를 듣고 정리한 내용입니다.

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

 

HTTP 기본

모든것이 HTTP

HTTP: HyperText Transfer Protocol

• 거의 모든 형태의 데이터를 전송 가능하다.
• 서버 간에 데이터를 주고 받을 때도 대부분 http를 사용한다.

 

HTTP 역사

• HTTP/0.9: GET 메서드만 지원. http 헤더 X
• HTTP/1.0: 메서드, 헤더 추가
• HTTP/1.1: 가장 많이 사용. 가장 중요한 버전
• HTTP/2: 성능 개선
• HTTP/3: TCP 대신 UDP 사용. 성능 개선

1.1에 대부분의 기능이 들어있고, 버전 2, 3은 성능 개선에 초점이 맞춰졌기 때문에 1.1이 가장 중요하다.

 

기반 프로토콜

• TCP: HTTP/1.1, HTTP/2
• UDP: HTTP/3

현재 HTTP/1.1을 주로 사용하지만 HTTP/2, HTTP/3도 점점 증가하고 있다.

 

크롬 개발자 도구에서 http 버전 확인

크롬 개발자 도구(F12)

개발자 도구의 네트워크 탭을 들어간다.

 

Protocol 클릭

Name 필드에서 오른쪽 클릭을 하면 다른 필드들을 추가할 수 있다. 여기에서 Protocol을 선택해준다.

 

h3은 HTTP/3을 의미한다.

h2는 HTTP/2를, http/1.1은 HTTP/1.1을 의미한다.

 

프로토콜 정보가 나오는 것을 확인할 수 있다.

http/1.1은 HTTP/1.1을 의미하고, h2는 HTTP/2, h3는 HTTP/3을 의미한다.

 

HTTP 특징

• 클라이언트 서버 구조
• 무상태 프로토콜(stateless), 비연결성
• HTTP 메시지
• 단순함, 확장 가능

 

클라이언트 서버 구조

• Request Response 구조
• 클라이언트는 서버에 요청을 보내고, 응답을 대기
• 서버가 요청에 대한 결과를 만들어서 응답

분리하는 것이 중요한 이유? 클라이언트와 서버를 분리하면 양쪽이 독립적으로 진화 가능하다.

예) 서버는 비즈니스 로직과 데이터에 집중, 클라이언트는 UI와 사용성에 집중

 

Stateful, Stateless

무상태 프로토콜(Stateless)

• 서버가 클라이언트의 상태를 보존하지 않음
• 장점: 서버 확장성 높음(스케일 아웃)
• 단점: 클라이언트가 추가적인 데이터 전송

stateless는 클라이언트 서버 구조에서 엄청난 확장성을 가진다.

-> 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.

-> 응답 서버를 쉽게 바꿀 수도 있기 때문에 무한한 서버 증설이 가능하다.

 

상태 유지(Stateful)의 경우 항상 같은 서버가 유지되어야 한다.

 

상태유지에서는 중간에 서버에 문제가 생기면 클라이언트가 같은 작업을 처음부터 다시 해야하는 반면, 무상태는 아무 서버나 호출해도 되기 때문에 갑자기 서버에 장애가 생겨도 다른 서버와 통신하면 된다.

 

실무에서의 한계

• 모든 것을 무상태로 설계할 수 있는 경우가 있지만 그렇지 않은 경우도 있음
• 무상태 예시 -> 로그인이 필요없는 단순한 서비스 소개 화면
• 상태 유지 예시 -> 로그인
• 로그인한 사용자의 경우 로그인 상태를 서버에 유지 -> 일반적으로 쿠키, 세션 등을 사용
• 상태 유지는 최소한만 사용하기

 

비연결성(Connectionless)

기본적으로 TCP/IP 연결은 연결을 유지한다.

 

연결을 유지하는 모델

연결을 유지하는 모델에서는 클라이언트 1, 2, 3 순서대로 서버와 연결 시 클라이언트 3과 연결할 때도 서버는 클라이언트 1, 2와 연결을 계속 유지한다.

이렇게 되면 작업을 하고 있지 않은 클라이언트와도 연결을 유지해야 하기 때문에 서버의 자원이 많이 소모된다.

 

연결을 유지하지 않는 모델

연결을 유지하지 않는 모델에서는 연결 요청 후 응답을 받으면 연결을 끊는다. 이는 서버와의 연결을 유지하지 않기 때문에 최소한의 자원을 유지할 수 있다.

 

비연결성

• HTTP는 기본적으로 연결을 유지하지 않는 모델
• 일반적으로 초 단위 이하의 빠른 속도로 응답
• 1시간동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십 개 이하로 매우 작음
• 서버 자원을 매우 효율적으로 사용 가능

 

하지만 연결을 끊었다가 다시 연결할 때 TCP/IP 연결을 새로 맺어야 하기 때문에 3 way handshake 시간이 추가된다.

특히 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 JS, CSS, 이미지 등 수 많은 자원이 함께 다운로드되기 때문에 이런 추가 시간이 발생한다는 것은 큰 단점이다.

현재는 HTTP 지속 연결(Persistent Connections)을 통해 해당 문제를 해결했고, HTTP/2와 HTTP/3에서 더 많은 최적화가 이루어졌다.

 

HTTP 초기 - 연결, 종료 낭비

HTTP 초기에는 페이지 로딩에 필요한 파일들을 각각 받아오면서 그 때마다 연결을 다시 해야 했다.

 

HTTP 지속 연결

HTTP 지속 연결을 사용하면 웬만한 html 페이지를 다 받을 때까지 지속연결을 유지한다.

 

HTTP/2, HTTP/3에서는 이런 연결들이 더 빠르게 일어난다. (특히 HTTP/3는 UDP를 사용하기 때문에 연결속도 자체도 빨라졌다.)

 

HTTP 메시지

기본적인 HTTP 메시지의 구조는 위의 그림과 같다.

 

HTTP 요청 메시지 / HTTP 응답 메시지 예시

위의 이미지처럼 요청 메시지에 body가 없다면 공백 라인만 넣고 끝낼 수도 있다. (공백라인은 필수이다!)

 

시작 라인

start-line은 request-line인지 status-line인지에 따라 다르다.

 

request-line: method SP(공백) request-target SP HTTP-version CRLF(엔터)

start-line: request-line

HTTP 메서드에는 GET, POST, PUT, DELETE 등이 있고 서버가 수행해야 할 동작을 지정한다.

 

요청 대상에는 path가 들어가고  "절대경로[?쿼리]" 형태로 사용한다. ([]는 optional. 절대경로는 "/"로 시작하는 경로를 의미)

*, http://...?x=y와 같이 다른 유형의 경로 지정 방법을 사용하기도 한다.

 

 

status-line: HTTP-version SP(공백) status-code SP reason-phrase CRLF(엔터)

start-line: status-line

상태 코드가 200이면 성공, 400이면 클라이언트 요청 오류, 500이면 서버 내부 오류를 의미한다.

이유 문구는 사람이 이해할 수 있도록 짧게 상태 코드 설명을 한다.

 

HTTP 헤더

field-name ":" OWS field-value OWS (OWS: 띄어쓰기 허용)

field-name은 대소문자를 구분하지 않는다. 이 때 주의할 점은 field-name과 콜론(:) 사이는 꼭 붙여줘야 한다는 것이다.

 

OWS는 띄어쓰기가 있어도 되고, 없어도 된다는 의미이다.

 

헤더에는 http 전송에 필요한 모든 부가정보가 들어간다. (ex. 메시지 바디 내용, 메시지 바디 크기, 압축, 인증, 요청 클라이언트 정보, 서버 애플리케이션 정보, 캐시 관리 정보 등)

많은 표준 헤더들이 존재하고, 필요시 임의의 헤더를 추가할 수도 있다.

 

HTTP 메시지 바디

http 메시지의 바디에는 실제로 전송할 데이터가 들어간다.

HTML 문서, 이미지, 영상, JSON 등 byte로 표현할 수 있는 모든 데이터는 전송 가능하다.