http?

Parker.Park·2022년 3월 18일

Http transfer 코드캠프

코드캠프

목록 보기

4/34

http?

Hyper Text Transfer Protocol 의 약자로 웹상에서 정보를 주고 받을 수 있는 프로토콜이다.
클라이언트와 서버 사이에 이루어지는 요청(request)/응답(response)에 관한 프로토콜이다.

그렇다면 통신 프로토콜(protocol)이란?(220920 수정)

TCP/IP Model, 그림 출처 : https://commons.wikimedia.org/wiki/File:TCPIP_Model.jpg

~~일종의 통신 규약이다.~~ 일종의 규칙? 형식? 상호간의 통신 할 때 약속같은 것으로 볼 수 있다. 컴퓨터나 원거리 통신 장비 사이에서 메시지를 주고 받는 약식과 규칙의 체계이다. 프로토콜에는 신호 처리법, 오류처리, 암호, 인증, 주소 등을 포함한다고 한다.
통신 프로토콜은 신호체계, 인증 그리고 오류 감지 및 수정 기능을 포함할 수 있다. 형식, 의미론, 통신의 동기과정을 정의하는 반면, 구현되는 방법이 독립적이기 때문에 하드웨어 또는 소프트웨어 그리고 때로는 모두를 사용하여 구현 되기도 한다.(?) 물리적인 것과 소프트웨어적(논리적)인 것들이 맞물려 있다는 의미론 해석하였다.

위 그림을 보면 HTTP라는 aplicaiton으로 도달하기 전에 TCP/UDP라는 transport 계층을 지나야 한다. 여기서 TCP와 UDP라는 전송계층에서 몇 가지 특징에 대해서 짚어보자. 처음 헷갈렸던 것이 http만이 프로토콜이 존재하는 줄 알았지만 http가 나오기 이전에 이미 TCP 프로토콜이라는 것이 존재 하였고(대표적으로 TCP / IP protocol suite라고 있다.), TCP / UDP기반으로 http 프로토콜을 구현 한다고 볼 수 있다.

TCP protocol 특징

OSI 7Layer 나 TCP / IP Model 에서 전송계층에 속하며 네트워크 망에 연결된 컴퓨터의 데이터를 순서대로, 에러없이 교환할 수 있게 하는 역할이다. 여기서 특징은 데이터의 손실을 최소화 한다는 것이다.

TCP protocol에서 여러 특징이 있겠으나 그 중 대표적인 3-way Handshake를 다뤄보겠다.

3-way handshake

three way handshake, 그림 출처 : https://commons.wikimedia.org/wiki/File:Three-way-handshake-example.gif

TCP 연결을 전화를 거는 것처럼 상대와 연결을 설정하려고 시작하는 것이 특징이다. 상대방과 3번의 통신이 오고가기 때문에 three way handshake라고 한다.

상대에게 통신을 하고 싶다는 메시지를 보낸다.(SYN)
상대는 받은 메시지에 대한 응답과 통신 준비과 되었다는 메시지를 보낸다.(SYN-ACK)
2번에서 받은 메시지에 응답을 보낸다.(ACK)

이런 특징으로 TCP는 속도보다는 신뢰성에 좀더 무게를 둔 프로토콜이다. 반면 UDP(User Datagram Protocol)은 비연결성이고 전송속도가 빠르며 데이터의 순차적인 전송을 보장하지 않는다. TCP 와는 반대로 가볍고 빠르다는 것이 특징이다.

HTTP/0.9 - 원-라인 프로토콜

HTTP 초기 버전에는 버전번호가 없었다. 이후 나오는 버전과 차별을 두기위해 0.9로 불리게 되었다고 한다. 일반적으로 http에서 아는 GET/POST/PUT/DELETE 방식과는 달리 0.9에서는 GET방식만 있었다. 또한 TCP/IP 링크를 통해 실행되었다고 한다.

HTTP 1.0 - 확장성 만들기

다음과 같은 특징들이 있다고 한다.

버전 정보가 각 용청 사이내로 전송되기 시작하였다.( HTTP/1.0 이 GET 라인에 붙은 형태이다.)
상태 코드 라인 또한 응답의 시작부분에 붙어 전송되었다. 그래서 브라우저가 요청에 대한 성공과 실패를 알 수 있게 되었고, 그 결과에 대한 동작을 할 수 있게 되었다.
HTTP 헤더 개념은 요청과 응답 모두를 위해 도입되어, 메타데이터 전송을 허용하였고 프로토콜을 유연하고 확장 가능하다록 만들어 주었다.
새로운 HTTP 헤더의 도움으로, 평이한 HTML 파일들 외에 다른 문서들을 전송하는 기능이 주가 되었다.(Content-Type같은 것들 말이다.)

// 일반적인 요청과 응답이다.
//출처 : MDN사이트
GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
A page with an image
  <IMG SRC="/myimage.gif">
</HTML>

HTTP/1.1 - 표준 프로토콜

1995년 부터 다양한 HTTP/1.0 구현이 동시에 진행되어 합당한 표준화가 진행 중 이었다. 그리고 HTTP/1.0이 나온지 몇 달 안되어 HTTP/1.1이 최초 공개가 되었다. HTTP/1.1은 모호함을 명확하게 하고 많은 개선사항들을 도입했다.

커넥션이 재사용 될 수 있게 하여, 리소스들을 디스플레이하기 위해 다시 연결해야하는 시간을 절약하게 하였다.
Host 헤더 덕분에 동일 IP주소에 다른 도메인을 호스트하는 기능이 서버 코로케이션을 가능케 하였다.
언어, 인코딩 혹은 타입을 포함한 컨테츠 협상이 도입되어, 클라이언트와 서버로 하여금 교환하려는 가장 적합한 컨텐츠에 대한 동의를 가능케 하였다.
하나의 커넥션에서 응답을 기다리지 않고 순차적으로 여러 요청을 연속적으로 보내 그 순서에 맞춰 응답을 받는 방식인, 파이프라이닝(Pipelining)이 추가되어 커뮤니케이션 레이턴시를 낮췄다.

아래는 하나의 단일 커넥션에 대한 요청의 전형적인 전체 흐름의 예시이다.

 GET /en-US/docs/Glossary/Simple_header HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header

200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding

(content)


GET /static/img/header-background.png HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header

200 OK
Age: 9578461
Cache-Control: public, max-age=315360000
Connection: keep-alive
Content-Length: 3077
Content-Type: image/png
Date: Thu, 31 Mar 2016 13:34:46 GMT
Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT
Server: Apache

(image content of 3077 bytes)

HTTP/1.1에서는 Head of Line Blocking이라고 하여, 순차적으로 응답을 해야 하기 때문에 첫 번째 요청에 대한 응답이 늦어질 경우 뒤에 들어온 요청에 대한 응답이 막히는 현상을 야기시켰다. 또한 연속된 요청에 대한 헤더들의 중복은 문제점으로 안고 있었다.

HTTP/2 - 더 나은 성능을 위한 프로토콜

Google에서 실험적으로 SPDY프로토콜을 구현하였다. 응답성 증가와 전송 데이터 중복에 관한 문제를 해결하면서 HTTP/2 프로토콜 기초에 기여하였다. HTTP/1.1과 비교하여 몇 가지 근복적인 차이점을 가지고 있다.

텍스트 프로토콜이 아닌 이진 프로토콜이다. 기존 텍스트 전송방식에서 바이너리 프레이밍 계층으로 전송하였다.
요청 및 응답 다중화를 통하여 Head of Line Blocking 현상을 해결 하였다.
스트림 우선순위를 지정하여 리소스간 우선순위를 설정 가능하게 하였다.
서버에서 먼저 데이터를 보내는 서버 푸시 기능이 등장 하였다.
헤더를 압축하여 헤더 크기를 줄여 로드 시간을 감소시켰다.

HTTP/3 - QUIC

HTTP/3은 전송 계층(TCP 나 UDP와 같은) 프로토콜이고, UDP기반의 QUIC프로토콜을 사용한다. QUIC은 2013년에 구글에서 공개하였으며 대부분의 구글 관련 제품에서 기본적으로 상용하는 프로토콜이라고 한다.

앞에서 잠깐 언급하였지만 UDP프로토콜은 전송 순서도 보장하지 않고 신뢰성이 낮은 것이 문제이다. 반면 단순하고 가벼워 전송속도가 빠르다는 것이 특징이다.

이전에 HTTP프로토콜은 신뢰성을 기반으로한 TCP를 기반으로 하였는데, TCP는 신뢰성을 확보하기 위해서 헤더가 다소 무거울 수 밖에 없었다. 반면 UDP 헤더는 별도의 기능없이 데이터 전송에만 집중하였기 때문에 헤더가 단순하였고, 원하는 기능을 구현할 여지가 많았다고 한다. 장점으로는 다음과 같다.

TCP에서 Tree-hand-shake와 같은 절차를 없애고 바로 연결 설정 + 데이터 전송을 통해서 전송속도를 향상 시켰다. 또한 연결이 성공하면 connection UUID라는 고유한 식별자로 캐싱하여 다음 연결 때 재수립 할 필요 없이 기존에 연결을 유지할 수 있다고 한다. 예를 들면 와이파이에서 LTE로 바뀌어도 커넥션을 재수립할 필요가 없어졌다는 뜻이다.
TLS를 기본적으로 적용하고, IP Spoofing, Replay Attack 방지와 같은 기술이 적용되어 보안성이 향상되었다.

다시 http - http에서 지원하는 요청 메시지

요청 종류는 다음 과 같다.

-GET: 클라이언트가 서버에게 URL에 해당하는 자료의 전송을 요청한다.
-HEAD: GET 요청으로 반환될 데이터 중 헤더 부분에 해당하는 데이터만 요청한다.
-POST: 클라이언트가 서버에서 처리할 수 있는 자료를 보낸다. 예를 들어, 게시판에 글을 쓸 때 클라이언트의 문서가 서버로 전송되어야 한다.
-PATCH: 클라이언트가 서버에게 지정한 URL의 데이터를 부분적으로 수정할 것을 요청한다.
-PUT: 클라이언트가 서버에게 지정한 URL에 지정한 데이터를 저장할 것을 요청한다.
-DELETE: 클라이언트가 서버에게 지정한 URL의 정보를 제거할 것을 요청한다.
-TRACE: 클라이언트가 서버에게 송신한 요청의 내용을 반환해 줄 것을 요청한다.
-CONNECT: 클라이언트가 특정 종류의 프록시 서버에게 연결을 요청한다.
-OPTIONS: 해당 URL에서 지원하는 요청 메세지의 목록을 요청한다.

몇 가지 특징들로는 safe Method 라는것과 처리결과가 동일하다는 Idempotent Method라는 것이 있지만 넘어가자.
이 중 입문 단계라면 GET, POST, PUT, DELETE(소위 CRUD라고 한다.)만 알고 넘어가도 좋다.
[CRUD 란?]

요청을 하고 응답할 때 응답 코드들이 있는데 아래 링크를 참조하자.
[HTTP 응답코드]