[컴퓨터 네트워크] HTTP

HTTP (Hyper-Text Transfer Protocol) ?

• Socket을 이용한 웹 페이지 전송 프로토콜여기서 웹 페이지란? -> 객체(HTML, JPEG, audio/video)들의 집합
• URL(Universal Resource Locator)로 웹 페이지를 식별함 (서버에서 어떤 파일인지 지칭)
  ex. http://networks.test.ac.kr/index.html -> 해당 서버의 루트 경로에 존재하는 디폴트 파일(index.html)을 요청!
• HTTP는 상태가 없음요청이 오면 응답만 함! 즉, 따로 key 값, 상태를 저장하지 않음따라서 이전의 응답/요청 내용도 알 수 없음!하지만 '쿠키'를 이용해서 상태가 있는 것처럼 보일 수는 있음 (ex. 쇼핑몰에서의 제품 추천)

 

HTTP 패킷을 캡처해보면, 아래와 같은 결과(HTTP 요청 및 응답 예시)를 확인할 수 있다.

GET / HTTP/1.1

HTTP/1.1 200 OK (text/html)

• 클라이언트가 GET 요청을 보냄
• HTTP/1.1 버전 사용
• 200 OK -> 서버가 클라이언트의 요청 성공적으로 수행

 

HTTP Response Status Code

• 200 OK
• 301 Moved Permanently
• 400 Bad Request
• 404 Not Found
• 505 HTTP Version Not Supported

보통 300번대는 주소/파일이 바뀐 경우, 400번대는 오류(존재하지 않는 파일을 요청하는 등)가 발생한 경우, 500번대는 버전 문제와 관련된 Status Code이다.

 

 

HTTP Request Method

HTTP Request Method 종류

우리가 자주 쓰는 HTTP 메서드로는 GET, POST, PUT, DELETE 등이 있다.

여기서 Idempotent란? 멱등성, 즉 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 말한다.

GET, PUT, DELETE는 멱등성이 성립하지만 POST는 성립하지 않는다. POST의 경우에는 새로운 데이터를 추가하기 때문에 서버에 메세지를 계속 추가하게 되고, 이는 서버가 계속 바뀌는 것을 의미하게 된다.

 

그렇다면 HTTP 응답과 요청은 어떻게 이루어지는 걸까?

먼저, 클라이언트와 서버가 TCP socket을 생성한다. TCP 연결을 만들어서 해당 연결을 통해 요청과 응답을 주고 받게 되는 것.

연결 후에는 클라이언트가 서버에게 요청 메시지를 전송하고, 서버는 이를 받아 응답 메시지를 다시 클라이언트에게 전송한다.

 

 

---

 

HTTP 프로토콜의 발전

 

Summary of HTTP milestone versions

현재는 HTTP 버전이 3까지 나왔다. 하지만 보통 HTTP/2가 디폴트이고, 옛날 서버에서는 HTTP/1.1가 사용된다. HTTP/3는 구글 관련 서비스 이용 시 볼 수 있음!

 

 

HTTP/1.0

• 파일 1개마다 1개의 TCP 연결 사용 (웹 페이지 1개에 여러 개의 TCP 연결이 필요함, non-persistent HTTP)
• 하지만 만약 서버가 아주 멀리 있다면? -> 왕복지연시간 문제 발생ex. 한국-미국 간의 데이터 전송 시간은 최소 200ms 이상 소요됨. TCP 연결을 여러 개 사용하게 되는 1.0 버전의 특성상 객체 1개 요청할 때마다 200ms 이상 소요 -> 시간이 아주 많이 걸리게 됨

 

🤨 지연시간이 왜 중요할까?

대역폭, 지연시간과 Page Load Time의 관계

위의 그래프가 대역폭에 따른 Page Load Time (PLT)의 변화, 아래 그래프가 지연시간에 따른 PLT의 변화를 보여주는 그래프이다.

대역폭은 5Mbps 정도만 되어도 이후에 PLT가 크게 줄어들지 않는다는 것을 볼 수 있다. 즉 속도 개선이 크지 않다.
하지만 지역시간(RTT-Round Trip Time)은 줄어들수록 PLT도 계속해서 감소하는 것을 볼 수 있다.

따라서 페이지 로드 시간을 줄이기 위해서는 RTT를 줄여야 함! (불필요한 전송이 없는지, 압축을 잘 쓰는지, 최적화 잘 된건지, 접속자 위치에 따라 전송을 어디에 할건지 등등...)

 

" 대역폭보다 지연시간이 Page Load Time 향상에 크게 기여한다"

 

왕복지연시간 문제를 해결해보자 -> TCP 연결을 재활용하자!

 

 

HTTP/1.1

• HTTP GET 메서드 처리에 이전 TCP 연결을 재사용 (persistent HTTP)-> 1개의 TCP 연결 사용으로 왕복지연시간 감소
  * HTTP/1.1은 헤더에 'Connection: keep-alive'를 포함하여 연결을 유지하도록 함
  
• Pipelining요청 병렬 전송, 응답 병렬 처리1.0에서는 html에 대한 요청, 응답 처리 완료 -> css 요청, 응답 이랬는데
  1.1에서는 html,css 요청 -> html 응답, css 응답이 가능해짐
  but, 순차 전송

 

하지만 1.1에서의 문제 -> 객체의 순차 전송으로 인해 병목현상 발생 (Head-of-Line Blocking)

Head-of-Line Blocking 문제란? html 파일을 전송해야 하는데, 용량이 크고 다운로드 시간이 긴 동영상, 음악 파일의 전송 순서가 먼저일 때 이런 파일이 전송 x -> 뒤의 파일들도 전송되지 못하고 막혀있게 됨.. 로딩 시간 늘어나고 늘어나고 늘어나고...

 

🤨 HTTP/1.1의 도메인 샤딩으로 HoL Blocking 현상을 줄일 수 있지 않을까?

 

HTTP/1.1에서는 도메인 샤딩(domain sharding)을 이용한다. 도메인 샤딩이란 여러 개의 TCP 연결 제한을 피하기 위해 도메인 서버를 여러 개 두는 방법이다.

도메인 샤딩을 이용하지 않는 경우 (case 1)

도메인 하나에 2개의 TCP 연결을 하는 경우, '2개의 요청 처리 완료 -> 다른 2개의 요청 처리'와 같은 과정으로 요청을 처리하기 때문에 시간이 꽤 걸릴 수 있다.

도메인 샤딩을 이용하는 경우 (case 2)

하지만 도메인 샤딩을 사용한다면 같은 서버로 연결되는 도메인을 여러 개로 분할하여 리소스를 가져오기 때문에 하나의 도메인에서 요청을 모두 처리하는 case 1보다 더 빠르게 요청을 처리할 수 있게 된다. ( 순차 직렬 연결인 case 1 -> 동시 병렬 요청인 case 2)

 

하지만, 도메인 당 최대 연결 수가 제한되어 있기 때문에 도메인 샤딩도 HoL Blocking을 완전히 해결할 수는 없다...

 

 

HTTP/2

• Head-of-Line Blocking (HoL Blocking)을 줄이자!
• 멀티플렉싱 (HoL Blocking 현상 제거)
  파일을 순차적으로 전송하지 않고, 섞어서 전송 가능하도록 함
• 우선순위 지원
• 바이너리 프레임
  원래는 텍스트를 이용했는데, 텍스트는 용량이 큼 -> 바이너리로 변경하여 용량 줄임
  ASCII를 사용하던 이전 버전들과 다르게 바이너리로 바꾸면서 패킷 캡처를 해서 볼 때 안 보임
• 서버 푸시
  일반적으로 서버는 클라이언트가 요청하는 경우에만 개체를 제공하게 됨
  2에서는 클라이언트가 요청하기 전에 서버가 클라이언트에게 푸시할 수 있도록 함!
• 헤더 압축
  요청을 여러 번 보낼 때 HTTP 헤더의 중복되는 정보를 계속 보내야 함. 따라서 헤더 압축을 통해 중복 정보를 제거하고, 이를 통해 로드 속도를 빠르게 할 있음

🤨 HTTP/2의 헤더는 'Connection: keep-alive'를 포함하지 않는다.

HTTP/1.1에서는 TCP 연결을 유지하도록 하기 위해 헤더에 'Connection: keep-alive'를 포함해야 한다. 하지만 마찬가지로 TCP 지속 연결을 사용하는 HTTP/2에서는 헤더에 해당 구문이 포함되지 않는다. 그 이유는 무엇일까?

 

위에서 봤듯이, HTTP/1.1은 HTTP/1.0에 persistent connection을 추가한 것이다. 하지만 HTTP/1.1은 기본적으로 연결을 닫는 방식으로 동작(여러 개의 TCP 연결을 이용)한다. 따라서 TCP 연결을 유지하기 위해서는 헤더에 명시적으로 keep-alive를 포함하여 처리해야 한다.

HTTP/2는 경우에는 프로토콜 자체가 persistent connection을 지원하기 때문에 헤더에 명시적으로 설정할 필요가 없다. HTTP/2는 하나의 TCP 연결을 사용하면서도 여러 요청 및 응답을 병렬로 처리할 수 있다.

 

병목현상을 줄이긴 했지만 HTTP/2도 TCP를 사용하기 때문에 패킷 손실 등으로 인한 HoL 병목현상이 발생할 수 있음

 

 

HTTP/3

• HTTP/2의 HoL 병목현상을 해결하자 -> TCP 대신 UDP 사용

TCP / UDP

• TCP-연결형, UDP-비연결형
• TLS 1.2+는 TCP 위에서 동작하며, 암호화를 통해 응용계층의 메세지를 제 3자에게 보이지 않도록 함
• UDP를 사용하는 HTTP에서도 암호화가 필요하기 때문에 이는 TLS 1.3에서 수행함
• TCP에는 혼잡제어와 손실복구 기능이 있지만 UDP에는 없음 -> QUIC에 해당 기능을 구현!
  즉, QUIC에 HTTP/2의 TCP, TLS 기능을 그대로 구현했다고 볼 수 있음