1. HTTP
HyperText Transfer Protocol의 약자로
웹브라우저 및 웹서버 상호간의 데이터 전송을 위한 응용계층(7계층) 프로토콜이다.
브라우저와 웹서버 간의 통신을 위해 설계되었으나 다른 목적으로도 사용 가능하다.
stateless protocol로 서버가 클라이언트-서버 요청간 어떤 상태도 유지하지 않는다.
HTTP는
웹에서 이루어지는 모든 데이터 교환의 기초로서
1990년대 초 설계되어 현재까지 지속적으로 진화한 확장 가능한 프로토콜이다.
html 뿐만 아니라 이미지, 비디오, HTML 폼 결과와 같은 내용을 서버로 POST 하기 위해 사용되고 있다.
2. HTTP의 구성요소
클라이언트에는
User-Agent가 있고 이는 사용자를 대신하여 동작하는 도구이다.
User-Agent 주로 브라우저에 의해 수행이 되며, HTML, CSS 및 각종 요청들을 하고 해당 리소스들을 혼합해 웹페이지를 표시한다.
웹페이지에는 다양한 하이퍼 텍스트가 있으며, 이러한 텍스트는 웹 상에서 돌아다닐 수 있도록 만들어주며,
브라우저는 HTTP 요청 내에서 이러한 사항들을 변환하고 사용자에게 응답을 표시해준다.
웹서버는
클라이언트의 요청에 대한 문서를 제공해준다.
단일 기계일 수도, 로드밸런싱, 캐시등과 합쳐진 집합체일 수도 있다.
여러 개의 서버를 동일한 머신 위에 호스팅하는 것도 가능하다.
프록시는
7계층에서 동작하는 컴퓨터 / 머신으로 아래와 같은 역할을 한다.
- 캐싱 (예 : 브라우저 캐시)
- 필터링 (예 : 유해컨텐츠 차단)
- 로드밸런싱 (예 : 여러서버들이 서로 다른 요청을 처리하도록 허용)
- 인증(리소스에 대한 접근 제어), 로깅(이력 정보 저장)
3. HTTP의 특징
- 간단 : http 메시지 등을 사람이 읽을 수 있게 간단하게 고안됨
- 확장가능 : http 헤더를 통한 확장 가능
- 상태는 없지만 세션은 있음
: 쿠키 등을 통하여 상태가 있는 세션을 만들고 헤더 확장을 통해 동일한 컨텍스트, 동일한 상태를 공유할 수 있다. - 연결 : 연결은 전송계층(3계층)에서 제어되므로 TCP나 UDP와 같은 표준에 의존함
4. HTTP가 제어할 수 있는 것들
- 캐시 : HTTP로 문서가 캐시되는 방식을 제어 가능
- 서버 : 캐시 대상과 기간을 프록시와 클라이언트에 지시 가능하다.
- 클라이언트 : 저장된 문서를 무시하라고 중간 캐시 프록시에게 지시 가능하다.
- origin 제약사항을 완화
- 웹 브라우저는 웹 사이트들간의 엄격한 분리를 하여 중요한 정보 탈취를 막는다.
- 동일 origin으로부터 온 페이지만 웹 페이지의 전체 정보에 접근할 수 있으나, http를 통해서 해당 사항을 완화시킬 수 있다.
- 인증 : WWW-Authenticate나 http cookie 등을 통한 인증절차 가능
- 프록시와 터널링 : http proxy를 활용한 네트워크에서의 통신
- 세션 : http cookie를 활용한 서버의 상태를 유지하도록 해줌
5. HTTP의 흐름
1. TCP Connection 연결 : 3-way-handshake
2. HTTP 메시지를 전송
3. Response를 읽음
4. 커넥션 종료 혹은 유지
6. HTTP 메시지
Requests
- Method : 클라이언트가 원하는 동작 (GET, POST 등)
- Path : URL (protocol, domain, port 등)
- Version of the Protocol
- Header : 서버에게 보내는 추가적인 정보들
- Body : 보내는 리소스
Responses
- Version of Protocol
- Status Code : request가 성공적인지, 실패인지 등
- Status Message : status code에 대한 짧은 사항 표기
- Header : 클라이언트에게 보내는 추가적인 정보들
- Body : 보내는 리소스
7. HTTP 역사
HTTP는 World Wide Web에 내재된 프로토콜이다.
HTTP는 4개의 빌딩블록으로 구성되어있는데 아래와 같다.
HTML : 하이퍼 텍스트 문서를 표현하기 위한 텍스트 형식의 언어
HTTP : 문서를 표현하기 위한 간단한 프로토콜인 하이퍼텍스트 전송 프로토콜
WWW : 문서를 디스플레이하기 위한 클라이언트
httpd : 문서에 접근하도록 해주는 것
HTTP/0.9
초기에는 버전이 없다가 점점 버전 구별을 위해 버전을 사용하였다.
요청은 단일 라인, 가능한 메서드는 GET이 유일하였다.
GET /mypage.html
HTTP/1.0
1995년까지 다양한 구현 및 접근을 하였고 1996년에 문서로 출간하였다.
좀 더 확장가능하게 만들어진 버전으로
버전정보, status code, header, html외의 다른 문서(Content-Type 활용)들도 전송기능 추가되었다.
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>
GET /myimage.gif HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
200 OK
Date: Tue, 15 Nov 1994 08:12:32 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/gif
(image content)
HTTP/1.1
1997년초에 공개된 표준 프로토콜이다.
특징으로는
파이프라이닝의 사용으로 첫번째 요청에 대한 response 전송되기 전에 두번째 request 전송 가능해져 Latency가 감소한다.
또한, response를 쪼개어서 전송이 가능하고, 캐시제어, 언어, 인코딩 혹은 type 등의 추가가 가능해졌다.
여기서 파이프라이닝은
요청들을 큐에 넣어서 한번의 커넥션에 여러 요청을 가능하게 함으로써 HTTP 1.0보다 Latency가 감소한다.
하지만, 여기에서 같은 큐에서 하나의 요청에 대한 대기가 길어지면 같은 큐의 다른 요청들이 그 요청을 기다리게 되는데
이러한 현상을 HOL(Head of Line) Blocking이라고 한다.
HTTP 1.1의 경우 전송 순서는 지켜줘야한다.
HTTP/2.0
시간이 흐름에 따라 HTTP를 사용하는 웹페이지는 더 많은 데이터의 양과 크기를 보내기 시작하였고,
HTTP/1.1과 같이 순서대로 전송을 실시해야하는 경우의 단점이 드러나기 시작했다.
구글에서는 이러한 문제들을 해결하기 위해 SPDY 프로토콜이라는 것을 구현하였고,
이를 기반으로 HTTP 2.0가 제정되었다.
HTTP2.0의 주요 기능으로는
텍스트 프로토콜이 아닌 바이너리 프로토콜로서 수동으로 읽거나 만들 수 없다.
즉, HTTP 1.0이나 1.1은 사람이 읽을 수 있는 형태로 HTTP 메시지가 구성되어 있지만
2.0부터는 사람이 읽을 수 없는 대신 binary 형태로 메시지가 되어있어 좀 더 빠르게 해당 내용을 보낼 수 있다.
또한, 헤더의 중복된 부분을 압축하여 오버헤드를 줄였다.
또한 멀티 플렉싱 기법을 사용한다.
이는 병렬로 request가 가능하다는 점인데,
HTTP 1.1과는 다르게 순서를 맞게 request를 보내고 response를 받았지만,
HTTP 2.0에서는 여러 데이터 요청을 병렬로 전송할 수 있고, response도 순서에 상관이 없어 HTTP1.1이 지닌
HOL Blocking 문제를 개선했다고 볼 수 있다.
서버푸시기능 또한 제공하는데
서버는 요청되지 않았지만 향후 요청에서 예상되는 추가 정보를 클라이언트에 전송할 수 있다.
HTTP/3.0
HTTP 2.0과 QUIC 프로토콜의 결합된 형태이다.
기존 HTTP 2.0의 멀티플렉싱은 살리되 QUIC를 통하여 데이터 손실이 발생하더라도 재전송을 자동으로 수행하여
네트워크 환경에 따른 문제를 미연에 방지할 수 있다.
위의 HTTP 1.0 / 1.1 / 2.0은 TCP 환경에서 작동하는데
HTTP3.0에서는 UDP를 사용하여 통신을 한다.
UDP에서는 빠르지만 데이터 손실이 문제이다.
하지만 QUIC를 통해서 이러한 점을 해결할 수 있다. (잃어버린 패킷 탐색이나 독립적인 재전송)
8. HTTPS
HTTP에서 보안이 강화된 버전이다.
S는 Secure의 약자로
통신의 인증, 암호화를 위해 넷스케이프에서 발명하였다.
SSL이나 TLS 프로토콜을 통해서 세션 데이터를 암호화함 안정성을 확보한다.
SSL/TLS는 아래의 링크 참고
https://jamiehun.tistory.com/170
참고자료
https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview
'Study > Network' 카테고리의 다른 글
[Network] SSL/TLS (0) | 2023.04.03 |
---|---|
[Network] OSI 참조모델 (TCP/UDP와 handshake) (0) | 2023.04.03 |
[Network] OSI 참조 모델 (OSI 7계층) (0) | 2023.04.03 |