•  05-07-2019
  •  | 
  •  

문제

누군가 HTTP 1.0과 HTTP 1.1의 차이점에 대해 간략하게 설명해줄 수 있나요?나는 두 RFC 모두에 대해 어느 정도 시간을 보냈지만 둘 사이의 많은 차이점을 찾아내지 못했습니다.위키피디아는 이렇게 말합니다.

HTTP/1.1(1997-1999)

현재 버전;기본적으로 영구 연결이 활성화되어 있으며 프록시와 잘 작동합니다.또한 요청 파이프라인을 지원하여 여러 요청을 동시에 보낼 수 있으므로 서버가 작업 부하에 대비하고 잠재적으로 요청된 리소스를 클라이언트에 더 빠르게 전송할 수 있습니다.

하지만 그것은 나에게 큰 의미가 없습니다.나는 이것이 다소 복잡한 주제라는 것을 알고 있으므로 완전한 답변을 기대하지는 않지만 누군가 조금 더 낮은 수준에서 차이점에 대한 간략한 개요를 줄 수 있습니까?
이는 HTTP 서버나 애플리케이션을 구현하기 위해 알아야 할 정보를 찾고 있음을 의미합니다.나는 주로 스스로 알아낼 수 있도록 올바른 방향으로 쿡쿡 찌르는 방법을 찾고 있습니다.

도움이 되었습니까?

해결책

프록시 지원 및 호스트 필드:

HTTP 1.1에는 사양별로 필수 Host 헤더가 있습니다.

HTTP 1.0은 공식적으로 Host 헤더를 요구하지 않지만 추가해도 문제가 없으며 많은 애플리케이션(프록시)은 프로토콜 버전에 관계없이 Host 헤더를 볼 것으로 기대합니다.

예:

GET / HTTP/1.1
Host: www.blahblahblahblah.com

이 헤더는 프록시 서버를 통해 메시지를 라우팅할 수 있게 하고 웹 서버가 동일한 서버에 있는 여러 사이트를 구별할 수 있기 때문에 유용합니다.

따라서 이는 blahblahlbah.com과 helohelohelo.com이 모두 동일한 IP를 가리키는 경우를 의미합니다.웹 서버는 호스트 필드를 사용하여 클라이언트 시스템이 원하는 사이트를 구별할 수 있습니다.

지속적인 연결:

또한 HTTP 1.1을 사용하면 지속적인 연결이 가능합니다. 이는 동일한 HTTP 연결에서 둘 이상의 요청/응답을 가질 수 있음을 의미합니다.

HTTP 1.0에서는 각 요청/응답 쌍에 대해 새로운 연결을 열어야 했습니다.그리고 각 응답 후에 연결이 닫힙니다.이로 인해 큰 효율성 문제가 발생합니다. TCP 느린 시작.

옵션 방법:

HTTP/1.1에는 OPTIONS 메서드가 도입되었습니다.HTTP 클라이언트는 이 방법을 사용하여 HTTP 서버의 기능을 확인할 수 있습니다.주로 웹 애플리케이션의 Cross Origin 리소스 공유에 사용됩니다.

캐싱:

HTTP 1.0은 헤더를 통한 캐싱을 지원했습니다.If-수정-이후.

HTTP 1.1은 '엔티티 태그'라는 것을 사용하여 캐싱 지원을 많이 확장합니다.2개의 리소스가 동일하면 동일한 엔터티 태그를 갖게 됩니다.

HTTP 1.1은 또한 If-Unmodified-Since, If-Match, If-None-Match 조건부 헤더를 추가합니다.

Cache-Control 헤더와 같은 캐싱과 관련된 추가 추가 사항도 있습니다.

100 계속 상태:

HTTP/1.1 100 계속에 새로운 반환 코드가 있습니다.이는 클라이언트가 서버가 요청을 처리할 수 있는지 또는 요청을 처리할 권한이 있는지 확실하지 않은 경우 클라이언트가 대규모 요청을 보내는 것을 방지하기 위한 것입니다.이 경우 클라이언트는 헤더만 보내고 서버는 클라이언트에게 계속해서 본문을 진행하라고 지시합니다.

훨씬 더:

  • 다이제스트 인증 및 프록시 인증
  • 추가로 새로운 상태 코드
  • 청크 전송 인코딩
  • 연결 헤더
  • 향상된 압축 지원
  • 훨씬 더.

다른 팁

 HTTP 1.0 (1994)

  • 여전히 사용 중입니다
  • 청크 (또는 압축) 서버를 처리 할 수없는 클라이언트가 사용할 수 있습니다.

 HTTP 1.1 (1996-2015)

  • 버전 1.0에 대한 많은 확장을 공식화합니다
  • 영구 및 파이프 라인 연결을 지원합니다
  • 청크 전송, 압축/감압을지지합니다
  • 가상 호스팅 지원 (여러 도메인을 호스팅하는 단일 IP 주소가있는 서버)
  • 여러 언어를 지원합니다
  • 바이트 범위 전송을 지원합니다. 중단 된 데이터 전송을 재개하는 데 유용합니다

HTTP 1.1은 HTTP 1.0의 향상입니다. 다음은 네 가지 주요 개선 사항을 나열합니다.

  1. 단일 IP 주소에서 여러 도메인을 제공 할 수있게하여 IP 주소를 효율적으로 사용합니다.

  2. 웹 브라우저가 단일 지속적인 연결을 통해 여러 요청을 보낼 수있게하여 더 빠른 응답.

  3. 청크 인코딩을 지원함으로써 동적으로 생성 된 페이지에 대한 더 빠른 응답은 총 길이가 알려지기 전에 응답을 전송할 수 있도록합니다.
  4. 캐시 지원을 추가하여 더 빠른 응답과 대역폭 절약.

사소한 애플리케이션 (예 : 웹 지원 온도계에서 온도 값을 산발적으로 검색) HTTP 1.0은 클라이언트와 서버 모두에 적합합니다. 베어 본 소켓 기반 HTTP 1.0 클라이언트 또는 서버를 약 20 줄의 코드로 작성할 수 있습니다.

보다 복잡한 시나리오의 경우 HTTP 1.1이가는 길입니다. 보다 복잡한 HTTP 1.1 프로토콜의 복잡성을 다루기위한 코드 크기가 3 ~ 5 배 증가 할 것으로 예상됩니다. HTTP 1.1에서는 다양한 헤더를 생성, 구문 분석 및 응답해야하기 때문에 복잡성은 주로옵니다. 클라이언트가 HTTP 라이브러리를 사용하거나 서버가 웹 애플리케이션 서버를 사용하도록 하여이 복잡성에서 응용 프로그램을 보호 할 수 있습니다.

주요 호환성 문제는 지원입니다 지속적인 연결. 최근에 HTTP/1.1을 "지원"한 서버에서 작업했지만 클라이언트가 HTTP/1.0 요청을 보냈을 때 연결을 닫지 못했습니다. HTTP/1.1을 지원하는 서버를 작성할 때 HTTP/1.0 전용 클라이언트와도 잘 작동하십시오.

내 머리 위에서 기억할 수있는 첫 번째 차이점 중 하나는 동일한 서버에서 실행되는 여러 도메인, 부분 리소스 검색이므로 리소스의 다운로드를 검색하고 속도를 높일 수 있습니다 (거의 모든 다운로드 가속기가하는 일입니다).

웹 사이트 나 이와 유사한 응용 프로그램을 개발하려면 차이점에 대해 너무 걱정할 필요가 없지만 ~해야 한다 의 차이점을 알고 있습니다 GET 그리고 POST 동사는 적어도.

이제 브라우저를 개발하려면 예, HTTP 서버를 개발하려는 경우에도 완전한 프로토콜을 알아야합니다.

HTTP 프로토콜을 알고 싶다면 1.0 대신 HTTP/1.1로 시작하는 것이 좋습니다.

HTTP 1.1은 인터넷의 TCP/IP 프로토콜 위에 실행되는 월드 와이드 웹 애플리케이션 프로토콜 인 하이퍼 텍스트 전송 프로토콜의 최신 버전입니다. HTTP 1.0과 비교하여 HTTP 1.1은 원래 HTTP보다 웹 페이지를 더 빠르게 제공하고 웹 트래픽을 줄입니다.

웹 트래픽 예 : 예를 들어 서버에 액세스하는 경우. 동시에 많은 사용자가 데이터를 위해 서버에 액세스하고 있으며 서버를 매달릴 가능성이 있습니다. 이것은 웹 트래픽입니다.

1.0에 비해 1.1은 웹 트래픽을 줄입니다

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top