HTTP(HyperText Transfer Protocol)
HTTP는 OSI 7 계층과 TCP/IP 4계층의 응용 계층(Application Layer)에서 데이터를 주고 받는데 사용하는 프로토콜입니다.
보통의 웹개발에서 클라이언트가 HTTP 요청을 보내고 서버가 응답하는 방식으로 동작합니다.
현재 HTTP/3까지 만들어져 있으며 HTTP/0.9 ~HTTP/2 까지는 TCP 기반으로 동작합니다.
HTTP/3은 표준화된 것이 2022년 6월 6일이기 때문에 HTTP/1.1과 HTTP/2 버전이 제일 많이 사용되고 있습니다.
버전별 특성은 아래와 같습니다.
HTTP/0.9
1. 요청은 GET이 유일합니다.
2. HTTP 헤더가 없습니다. 즉, HTML 파일만 주고 받을 수 있습니다.
3. 상태/오류 코드도 없기 때문에 특정 HTML 파일 안에 문제에 대한 설명을 보냅니다.
HTTP/1.0
1. 통신을 할 때 마다 TCP HandShake를 수행합니다.
2. HTTP 헤더를 주고받을 수 있습니다. 이로 인해 HTML 파일 외에 다른 문서들을 주고 받을 수 있게 됩니다. (Content-Type 응답 헤더 지정)
3. 상태 코드도 전송이 가능하기에 성공/실패에 대한 동작을 지정할 수 있게 되었습니다.
하지만 매번 1 request &1 response에 대한 새로운 연결을 해야하기 때문에 성능이 좋지 않습니다.
HTTP/1.1
HTTP/1.1에서는 기본적으로 영속적으로 동작합니다.
그리고 아래와 같은 두 가지 모델이 추가되었습니다.
1. Persistent connection 모델(keep-alive connection)
지정한 타임 아웃 동안 커넥션을 닫지 않는 방식으로, 연속적인 요청 사이에 커넥션을 유지하여 재사용합니다.
서버는 Keep-Alive 헤더로 연결이 최소한 얼마나 열려있어야 할지를 설정할 수 있습니다.
단점으로는 아무것도 보내지 않는 상태일때도 연결을 유지하기에 리소스 낭비가 될 수 있습니다.
2. HTTP 파이프라이닝
한 단계 더 나아간 방식으로 하나의 커넥션에서 응답을 기다리지 않고 순차적인 여러 요청을 연속적으로 보낸 후 그 순서에 맞춰 응답을 받는 방식으로 네트워크 지연을 더욱 줄이는 방식입니다.
첫번째 요청에 대한 응답이 완전히 전송되기 이전에 두번째 요청 전송을 가능케 하였습니다.
모든 종류의 HTTP 요청이 파이프라인으로 처리될 수 있는 것은 아닙니다.
GET, HEAD, PUT, DELETE 와 같은 idempotent 메서드만 가능합니다.
idempotent(멱등성) - 동일한 요청을 여러 번 보내도 결과가 같은 것
사진으로 보자면 Short-lived connections는 HTTP/1.0 버전에서 사용하고 있는 방식이고 나머지 두 방식은 위에서 설명한 HTTP/1.1에서 등장한 두 가지 모델의 동작 방식 입니다.
파이프라이닝 방식이 제일 빠르기 때문에 좋아보이지만 치명적인 문제점이 있습니다.
1. 파이프라이닝은 HOL(Head Of Line) Blocking 문제
HOL은 이전 요청이 서버에서 처리하는 시간이 길 경우 그 이후의 요청도 기다려야 한다는 것입니다.
즉, 같은 큐에 있는 패킷이 첫번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상입니다.
2. 연속된 요청의 경우에도 Header의 중복값을 고려하지 않고 모두 전송하는 문제
HTTP/2.0(SPDY)
이러한 파이프라이닝의 문제점으로 인해 '멀티플렉싱'이 등장하게 되었습니다.
HTTP/2.0은 SPDY 프로토콜 기반으로 동작합니다.
위에서 보듯이 SPDY는 항상 TLS 위에서 동작합니다.
TLS란 Transport Layer Security의 약자로 HTTP 통신 시 보안을 위해 사용합니다.
TLS의 자세한 내용은 아래의 HTTPS에서 알아보겠습니다.
SPDY의 장점은 아래와 같습니다.
1. HTTP 헤더 압축
HTTP 헤더에는 요청마다 반복되는 내용이 매우 많으므로 헤더 압축만으로도 충분한 성능 향상 효과를 얻을 수 있습니다.
2. 바이너리 프로토콜
프레임을 텍스트가 아닌 바이너리로 구성하므로 파싱이 더 빠르고, 오류 발생 가능성이 낮습니다.
3. 멀티플렉싱
하나의 커넥션 안에서 다수의 독립적인 스트림을 동시에 처리합니다.
하나의 커넥션에서 한 번에 하나만의 요청을 처리하며 요청에 대한 응답이 순차적으로 이뤄지는 HTTP와는 달리 적은 수의 커넥션으로 다수의 요청, 응답을 동시에 처리할 수 있습니다.
4. Full-deplex interleacing과 스트림 우선순위
한 스트림이 진행중이더라도 다른 스트림이 끼어드는(interleaving) 것을 허용하고 스트림의 우선순위 설정도 지원하므로, 우선순위가 높은 데이터를 더 빨리 전달할수 있습니다.
5. Server Push
클라이언트의 요청이 없어도 서버에서 콘텐츠를 직접 Push 할 수 있습니다.
HTTP와 SPDY의 차이를 표로 보자면 아래와 같이 볼 수 있습니다.
SDPY는 왜 TLS를 필수요소로 끼워 놓았을까요?
TLS 사용으로 인해 암호화/복호화 작업으로 인한 전송 지연이 발생하게 됩니다.
Google의 SPDY Whitepaper에서는 다음과 같이 이유를 밝히고 있습니다.
"장기적으로 보아 웹 환경에서 보안성은 점점 더 강조될 것이므로, SPDY의 하위 프로토콜로 TLS를 지정하여 향후 더 나은 보안성을 얻고자 한다.
현재 네트워크 인프라와의 호환, 즉 기존의 프록시를 거치는 통신과 호환성 문제가 발생하지 않도록 하기 위해 TLS가 필요하다."
HTTP/3.0(QUIC)
HTTP/1.1에서 HTTP/2.0로도 많은 부분이 변경되었고 충분히 좋아보입니다.
그렇다면 HTTP/3.0은 HTTP/2.0에 비해 어떤 부분이 변경되었을까요?
HTTP/2.0에서는 SPDY를 사용하는데 TCP 기반으로 동작하고 있습니다.
하지만 HTTP/3.0부터는 QUIC을 사용하며 QUIC은 UDP 기반으로 동작합니다.
눈으로 보이는 차이점은 TLS의 경우 별도로 분리 되어있는 것이 아닌 포함되어있는 것을 볼 수 있습니다.
QUIC은 Quick UDP Internet Connection의 약자로 UDP를 이용한 프로토콜입니다.
QUIC은 TCP의 3 Way HandShake 과정을 최적화하는 것에 초점을 맞추어 설계되었고 UDP를 사용함으로써 이를 실현했습니다.
HTTP/2.0 까지는 통신을 위해 위와 같은 작업을 필요로 합니다.
클라이언트가 보낸 요청을 서버가 처리한 후 클라이언트로 응답해주는 사이클을 RTT(Round Trip Time)이라고 하는데, TCP는 연결을 생성하기 위해 기본적으로 1 RTT가 필요하고, 여기에 TLS를 사용한 암호화까지 더한다면 TLS 자체 HandShake까지 더해져 총 3 RTT가 필요합니다.
이에 반해 QUIC 첫 연결 설정에 1 RTT만 소요됩니다.
이것이 가능한 이유는 첫번째 핸드쉐이크를 거칠 때 모든 정보를 보내버리기 때문입니다.
그리고 한번 연결에 성공했다면 서버는 그 설정을 캐싱해놓고 있다가 다음 연결 때는 캐싱된 설정을 사용하여 0 RTT 만으로 통신을 시작할 수도 있습니다.
HTTPS(HTTP + Secure)
HTTPS는 TLS를 통해 HTTP를 통해 전송되는 데이터를 암호화합니다.
TLS는 Certificate Authority(CA)라 불리는 서드 파티(기업)로부터 서버와 클라이언트의 인증을 하는데 사용됩니다.
TCP와 마찬가지로 TLS도 HandShake 과정을 통해 신뢰성 여부를 판단합니다.
TCP의 3way HandShake 과정이 끝난 이후에 바로 동작하며 다음과 같이 동작합니다.
1.클라이언트는 서버에게 ‘Client Hello’ 메세지를 보냅니다.
자신이 사용 가능한 Cipher Suite 목록, Session ID, SSL 프로토콜 버전, Random Byte도 함께 전송합니다.
Cipher Suite는 암호화 알고리즘입니다.
2.서버도 클라이언트에게 ‘Server Hello’ 메세지를 보냅니다.
Cirher Suite 목록 중 하나를 선택하고 자신의 SSL 인증서도 전달합니다.
인증서 내부에는 서버가 발행한 공개키가 들어있습니다.(개인키는 서버가 따로 소유)
3. 클라이언트는 서버가 보낸 CA의 개인키로 암호화된 이 SSL 인증서를 CA 공개키를 사용하여 복호화합니다.
4. CA 인증서가 검증되었다면 클라이언트는 데이터 암호화에 사용할 대칭키를 생성한 후(난수바이트) SSL 인증서에서 추출한 서버의 공개키를 이용해 암호화한 후 서버에게 보냅니다.
여기서 전달된 대칭키가 데이터를 실제로 암호화할 대칭키입니다.
5. 서버는 클라이언트의 인증서를 확인 후, 난수 바이트를 자신의 개인키로 복호화 후 대칭 마스터 키 생성에 활용합니다.
6. 클라이언트는 finished 메세지를 서버에 보내면서, 지금까지 보낸 교환 내역들을 해싱 후 그 값을 대칭키로 암호화하여 같이 담아 보내줍니다.
7. 서버도 동일하게 교환 내용들을 해싱한 뒤 클라이언트에서 보내준 값과 일치하는지 확인합니다.
일치하면 서버도 finished 메세지를 이번에 만든 대칭키로 암호화하여 보냅니다.
8. 클라이언트는 해당 메세지를 대칭키로 복호화하여 서로 통신이 가능한 신뢰받은 사용자란걸 인지하고, 해당 대칭키로 데이터를 주고받습니다.
그리고 HTTP 외에 응용 계층(Application Layer)에서 동작하는 프로토콜들은 전송 계층에서 다음과 같은 프로토콜과 포트번호를 사용합니다.
출처
https://byjusexamprep.com/application-layer-protocols-dns-smtp-pop-ftp-http-i
https://d2.naver.com/helloworld/140351
https://evan-moon.github.io/2019/10/08/what-is-http3/
https://sysgongbu.tistory.com/152
'Network' 카테고리의 다른 글
| TCP, UDP란? (0) | 2022.07.18 |
|---|---|
| CDN이란? (0) | 2021.09.18 |