Post

HTTP - 3 HTTP 기본

해당 자료는 인프런 김영한 선생님의 모든 개발자를 위한 HTTP 웹 기본 지식 강의노트입니다.


1. HTTP

HTTP 메시지에 모든 것을 전송합니다.

  • HTMl, TEXT, IMAGE, JSON, XML 등등 거의 모든 형태의 데이터 전송이 가능합니다.

현재 1997년에 나온 HTTP/1.1이 중요합니다.
HTTP/2, HTTP/3 도 있지만, HTTP/1.1이 가장 보편적으로 쓰이고 있습니다.

TCP는 HTTP/1.1, HTTP/2를 기반 프로토콜로 갖습니다.
UDP는 HTTP/3을 기반 프로토콜로 갖습니다.

크롬에서 확인하는 방법은 구글 크롬에서 “임창정”을 검색한 뒤 F12를 누른 뒤, Network 탭에 들어가면

Proto…을 보시면 h3-29로 되어있는데 현재 구글에서는 h3(HTTP3)버전을 사용하고 있는 것을 볼 수 있습니다.


2. 클라이언트 서버 구조

HTTP는 기본적으로 클라이언트-서버 구조로 동작합니다.
클라이언트는 서버에 요청을 보내고, 응답을 대기합니다.
서버가 요청에 대한 결과를 만들어서 응답합니다.


3. 무상태 프로토콜

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

먼저 stateful이란 고객이 노트북 2개를 신용카드로 구매한다고 하였을 때
서버 3개를 거칠 경우 그 서버에서 다른 서버로 보낼 때마다 노트북 수량 2개와 신용카드 라는 것을 서버에서 상태를 갖고있는 형태입니다. 그러므로 만약 서버가 바뀌는 경우 해당 서버에게 “노트북 2개, 신용카드 구매” 라는 것을 미리 알려줘야합니다.
세션을 유지하는 것을 stateful이라고 합니다.

무상태 stateless란 노트북 2개를 신용카드를 구매한다고 하였을 때
서버 3개를 거칠 경우 서버가 바뀌어도 상관이 없습니다. 그렇기 때문에 응답 서버를 쉽게 바꿀 수 있고, 무한하게 서버를 증설할 수 있습니다.

만약 서버 1이 다운되어 버리면 클라이언트는 서버 1이 살아나면 요청을 다시 보내야합니다.

무상태는 서버 1이 다운되어도 서버 2에서 응답을 해줄 수 있는 구조를 말합니다.

이렇듯 응답 서버를 많이 증설할 수 있고 이러한 것을 스케일 아웃이라고 합니다.

Stateless의 한계는 모든 것을 무상태로 설계할 수 있는 경우도 있고 없는 경우도 있습니다. 또한, 데이터를 많이 보내는 단점이 있습니다.
로그인의 경우는 상태 유지로 설계해야합니다. 이러한 상태유지는 최소한만 사용해야 합니다.


4. 비 연결성

연결에는 두가지 모델이 있습니다. 연결을 유지하는 모델과 연결을 유지하지 않는 모델이 있습니다.

연결을 유지하는 모델

모든 클라이언트에 연결되어, 요청이 들어오면 응답해주는 방식입니다.
장점으로는 이미 연결되어 있어, 3 way handshake, html 불러오는 등 작업이 필요가 없으나 서버에서는 연결유지를 위한 자원소모가 심해집니다.
위의 예제에서는 클라이언트가 3대이지만 수천 수만대의 클라이언트와 연결을 유지하는 것은 힘든일입니다.

연결을 유지하지 않는 모델

연결을 유지하지 않는 모델은 요청에 대한 응답을 해주고, 연결을 끊어버립니다.
서버 자원을 낭비하지 않는 장점이 있지만, 매 번 3 way handshake를 해줘야하고, 자바스크립트, css 등 수많은 자원이 함께 다운로드 되어집니다.

지금은 HTTP 지속연결(Persistent Connections)로 문제를 해결했습니다.

요청이 들어올 때마다 연결을 다시 해줬던 것을 연결을 유지시켜 놓고 응답이 모두 완료된 후 끊어버리는 것입니다.
위에서 설명했던 연결을 유지하는 모델과 차이점은 연결을 유지하는 모델은 무한대로계속 유지하는 것이고, HTTTP 지속 연결은 그보다 짧게 1분 정도 연결을 유지하는 방식을 말합니다.
웹 서버를 제공하는 서비스에서는 보통 기본적으로 적용됩니다.


5. HTTP 메시지

https://tools.ietf.org/html/rfc7230#section-3
에 나와있는 것을 보면 HTTP-message는 다음과 같은 스펙을 갖습니다.

1
2
3
4
HTTP-message = start-line
                *(header - field CRLF)
                 CRLF
                 [message-body]  

요청 메시지

start-line : request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터)로
+ method : GET, POST, PUT, DELETE …
+ request-target : 절대경로로 나타내는 요청 대상 (/search?~)
+ HTTP-version : 예제에서 쓰인 HTTP/1.1

응답 메시지

startline : status-line = HTTP-version SP status-code SP reason-phrases CRLF
+ HTTP 버전
+ HTTP 상태 코드 : 200(성공), 400(클라이언트 요청오류), 500(서버 내부 오류)
+ 이유 문구 : 사람이 이해할 수 있는 짧은 상태 코드 설명글(OK)

HTTP 헤더

header-field = field-name”:” OWS field-value OWS (OWS: 띄어쓰기 허용)
+ field-name은 대소문자 구문이 없지만, filed-value는 구분합니다.(서버에서 자체적으로 전부 소문자 처리할 수도 있음.)

헤더에는 HTTP 전송에 필요한 모든 부가정보가 들어갑니다. 메시지 바디의 내용, 크기, 압축, 인증, 클라이언트 정보 등…

HTTP 메시지 바디

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


This post is licensed under CC BY 4.0 by the author.