3. HTTP란 무엇이며 어떻게 진화되었는가? - 2

원문 : kamranahmed.info/blog/2016/08/13/http-in-depth/

Journey to HTTP/2 – Kamran Ahmed

HTTP/1.0의 3년 후 다음 버전. HTTP/1.1은 1999년에 출시되었으며, 이전 버전보다 많이 개선되었다.

 

HTTP/1.0에 대한 주요 개선 사항

• PUT, Patch, OPTION, DELETE를 도입한 새로운 HTTP 메서드가 추가되었다.

 

• HTTP/1.0 호스트 헤더는 필요하지 않았지만, HTTP/1.1에서 호스트 헤더가 필요하게 되었다.

 

• 지속적인 연결 위에서 HTTP/1.0에서는 연결당 하나의 요청만 있었고 요청이 수행되자마자 연결이 종료되어 성능 적중 및 지연 시간 문제가 발생하였다. 그래서 HTTP/1.1은 영구적인 연결을 도입했다. 즉, 연결이 기본적으로 닫히지 않고 열려 있어서 여러 차례 순차적 요청을 허용한다. 연결을 닫으려면 요청에 Connection: close 헤더를 사용한다. 클라이언트는 일반적으로 연결을 안전하게 닫기 위해 마지막 요청에서 이 헤더를 전송한다.

 

• 클라이언트가 같은 연결에서 서버로부터 응답을 기다리지 않고 서버에 여러 요청을 보낼 수 있고, 서버는 요청을 수신한 순서와 같은 순서로 응답을 보내야 하는 파이프 라이닝에 대한 지원도 도입했다. 그러나 고객이 이것이 첫 번째 응답 다운로드가 완료되고 다음 응답을 위한 콘텐츠가 시작되는 지점임을 어떻게 알 수 있는가? 자, 이를 해결하려면 클라이언트가 응답 종료 위치를 식별하기 위해 사용할 수 있는 Content-Length 헤더가 있어야 하며, 다음 응답을 기다릴 수 있다.

 

• 지속적인 연결 또는 파이프 라이닝의 이점을 얻으려면 응답에 Content-Length 헤더를 사용할 수 있어야 하는데, 이는 전송이 완료되면 클라이언트가 알 수 있고 다음 요청을 전송(일반적인 순차적 요청 전송 방식)하거나 다음 응답을 기다릴 수 있기 때문이다(파이프 라이닝이 활성화됨). 
• 그러나 이 접근법에는 여전히 문제가 있었다. 즉, 데이터가 동적이고 서버가 미리 콘텐츠 길이를 찾을 수 없는 경우에는 어떻게 하시겠습니까? 이 HTTP/1.1을 해결하기 위해 chunked encoding을 도입했다. 이러한 경우 서버는 chunked encoding을 위해 콘텐츠 길이를 생략할 수 있다(순간적으로 더 많이). 단, 둘 중 어느 것도 사용할 수 없는 경우에는 요청이 끝나면 연결을 종료해야 한다.

 

• 청크 처리된 전송 동적 콘텐츠의 경우, 전송이 시작될 때 서버가 실제로 Content-Length를 찾을 수 없을 때, 콘텐츠가 조각으로 전송되기 시작하고(청크 단위) 전송될 때 각 청크에 대해 Content-Length를 추가할 수 있다. 그리고 모든 청크가 전송될 때, 즉, 전송이 완료된 클라이언트를 식별하기 위해 콘텐츠 길이가 0으로 설정된 청크를 전송한다. 청크 전송에 대해 클라이언트에 알리기 위해, 서버에는 Transfer-Encoding: 청크 처리 헤더가 포함되어 있다.

 

• 기본 인증만 있었던 HTTP/1.0과 달리 HTTP/1.1은 다이제스트 인증과 프록시 인증을 포함했다.
• 캐싱
• 바이트 범위
• 문자 집합
• 언어협상
• 클라이언트 쿠키
• 향상된 압축 지원
• 새로운 상태 코드들
• 등등

 

 

HTTP/1.1은 1999년에 도입되었으며, 수 년동안 표준이었습니다. 비록 인터넷이 이전 버전보다 많이 발전했지만, 웹이 매일 바뀌었습니다. 요즘 웹 페이지를 로드하는 것은 그 어느 때보다도 자원 집약적입니다. 간단한 웹페이지는 30개 이상의 연결을 열어야 합니다.

 

HTTP/1.1은 지속적인 연결을 가지고 있는데, 왜 이렇게 많은 연결이 있는가?

 

그 이유는 HTTP/1.1에서는 어느 순간에나 하나의 outstanding connection을 가질 수 있기 때문입니다. HTTP/1.1은 파이프라이닝을 도입하여 이 문제를 해결하려고 했지만, 느리거나 무거운 요청이 뒤에 있는 요청을 차단할 수 있는 헤드오프 차단 때문에 문제를 완전히 해결하지 못했으며, 요청이 파이프라인에 걸리면 다음 요청이 이행될 때까지 기다려야 했습니다. 이러한 HTTP/1.1의 단점을 극복하기 위해 개발자들은 스프라이트시트 사용, CSS에 인코딩된 이미지, 단일 유머 CSS/Javascript 파일, 도메인 샤딩 등의 해결 방법을 구현하기 시작했습니다.