요구사항: 현재 대부분의 웹사이트는 주로 Http/1.1 및 Http/2.0 버전 프로토콜을 사용하고 있으며, HTTP/2 프로토콜 버전만 지원하는 웹사이트는 기본적으로 HttpClient를 사용해 요청을 보낼 때 System.Net.Http.Http.HttpRequestException: 요청을 전송하는 과정에서 오류가 발생했습니다. ---> System.IO.IOException: 전송 연결에서 데이터를 읽을 수 없음: 호스트 내 소프트웨어가 기존 연결을 중단했습니다. ---> System.Net.Sockets.SocketException (10053): 호스트 내 소프트웨어가 기존 연결을 중단합니다. at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.CreateException(SocketError error, Boolean forAsyncThrow).
HTTP 프로토콜의 역사
연대표
HTTP/0.9
구식이 된 HTTP/0.9는 1989년에 탄생한 HTTP 프로토콜의 첫 번째 버전이었습니다. 매우 간단하여 클라이언트가 GET 요청을 보낼 수 있고 요청 헤더를 지원하지 않습니다. 프로토콜 헤더가 없기 때문에 HTTP/0.9는 단일 유형의 콘텐츠, 즉 일반 텍스트만 지원할 수 있습니다. 서버는 HTML 형식의 문자열에만 응답할 수 있으며, 다른 형식은 응답할 수 없습니다. 서버가 전송을 완료하면 TCP 연결이 종료됩니다.
HTTP/0.9는 전형적인 상태 무형성을 가지며, 각 방문은 독립적으로 처리되고 처리가 완료되면 연결이 끊깁니다. 요청된 페이지가 존재하지 않으면 오류 코드가 반환되지 않습니다.
HTTP/1
HTTP/1은 HTTP 1.0과 HTTP 1.1을 통칭하는 용어로, 각각 HTTP 프로토콜의 1.0과 1.1 버전을 의미합니다.
HTTP 1.0은 HTTP 프로토콜의 두 번째 버전으로, 오늘날까지도 널리 채택되고 있습니다. HTTP/0.9를 기반으로 다음과 같은 여러 개선과 개선을 이루어왔습니다:
텍스트뿐만 아니라 이미지, 동영상, 바이너리 등 더 많은 형식을 전송할 수 있습니다
그 위에 POST 요청 메서드가 추가되었습니다
HTTP 요청과 응답의 형식을 변경했습니다. 데이터 부분 외에도, 각 통신에는 일부 메타데이터를 설명하는 HTTP 헤더가 포함되어야 하며, 즉 요청 헤더 정보가 추가됩니다
응답 상태 코드, 다중 문자 집합 지원, 권한 부여, 캐시, 콘텐츠 인코딩과 같은 추가 기능
비록 여전히 상태 없는 프로토콜이지만, 요청에 "Connection: keep-alive" 헤더를 추가하여 긴 연결을 지원할 수 있습니다
HTTP 1.1
HTTP 1.1은 표준화된 프로토콜이며, HTTP 1.1은 많은 모호함을 제거하고 여러 개선점을 도입합니다.
특성
캐시 처리, HTTP 1.1은 엔티티 태그, If-Unmodified-Sence, If-Match, If-None-Match 등과 같은 더 많은 캐시 제어 정책을 도입하고, 캐시 정책을 제어하는 더 많은 선택적 캐시 헤더를 도입했습니다.
대역폭 최적화와 네트워크 연결 사용은 요청 헤더에 범위(range)를 도입하여, 자원의 한 부분만 요청할 수 있게 하여, 즉 206 상태 코드를 반환할 수 있게 하여 개발자가 대역폭과 링크를 자유롭게 활용할 수 있게 하고, Range와 Content-Range를 사용해 브레이크포인트 재개(breakpoint resumption) 함수를 만들 수 있습니다.
오류 알림 관리, HTTP 1.1에 24개의 새로운 오류 상태 코드가 추가되었습니다.
호스트 헤더를 추가하면 동일한 IP 주소를 가진 서버에서 서로 다른 도메인 이름을 구성할 수 있습니다.
긴 연결을 지원하며, HTTP 1.1은 긴 연결을 지원하고, TCP 연결에서 여러 HTTP 요청과 응답을 전송할 수 있어 연결 설정 및 종료 시 소모와 지연을 줄일 수 있습니다. HTTP 1.1에서는 Connection:keep-alive가 기본적으로 활성화되어 있고, 일반 브라우저는 동일한 도메인 이름에 대해 6개의 긴 링크를 동시에 설정할 수 있습니다.
첫 번째 응답이 완전히 전송되기 전에 두 번째 요청을 보낼 수 있도록 파이프라인 기술을 추가하여 큐 블로킹을 개선하지만, 응답 순서는 여전히 요청 순서대로 반환됩니다.
응답 청킹을 지원하려면 Transfer-Encoding: chunked를 chunked 응답으로 설정하여 응답 데이터를 여러 부분으로 나누고, 서버가 버퍼를 최대한 빨리 해제하여 더 빠른 응답 속도를 얻을 수 있습니다.
HTTP 2.0
HTTP 2.0은 성능이 향상되었고, 이제 웹 페이지는 점점 더 복잡해지고 독특한 애플리케이션으로 진화하고 있습니다. 미디어 재생량, 상호작용을 향상시키기 위한 스크립트 크기도 크게 증가했고, HTTP 요청을 통해 전송되는 데이터 증가도 많아 HTTP 2.0은 네트워크 효율성을 위한 많은 최적화를 했습니다.
특성
이진 프레임 분할(Binary Frame Splitting), HTTP 2.0은 텍스트 프로토콜이 아닌 이진 프로토콜로, 전송되는 모든 정보를 더 작은 메시지와 프레임으로 나누어 이진 형식으로 인코딩합니다.
다중화, 병렬 요청을 동일한 링크에서 처리할 수 있으며, 동일한 도메인 이름 내 모든 접근은 동일한 TCP 연결에서 이루어지고, HTTP 메시지는 독립적인 프레임으로 나누어지며, 서버는 식별자와 헤더에 따라 메시지를 재조립하여 HTTP 1.1의 순서 및 차단 제약을 제거합니다.
일련의 요청에서 유사한 헤더를 압축하면 중복 데이터 중복 및 전송 비용을 줄여줍니다.
서버 측 푸시에서는 서버가 클라이언트의 명시적 요청 없이도 자원을 선제적으로 클라이언트에 푸시할 수 있습니다.
HTTP 3.0
HTTP 3.0은 현재 공식화 및 테스트 단계에 있으며, 미래에 새로운 HTTP 프로토콜로 등장합니다. HTTP 3.0 프로토콜은 QUIC 프로토콜 위에 실행되며, UDP를 기반으로 신뢰성 있는 전송 속도를 달성하고 전송 속도를 조절하며 최적화합니다. UDP를 사용하면 TCP 큐 차단 문제를 피하고 네트워크 전송 속도를 높일 수 있지만, 신뢰할 수 있는 전송 메커니즘도 달성해야 합니다. HTTP 3.0은 HTTP 2.0의 확장이 아닙니다. 3.0은 완전히 새로운 프로토콜이 될 것입니다.
HttpClientHandler VS 소켓 HttpHandler
.NET 프레임워크 및 .NET Core 2.0 이전 버전에서 HttpClient가 사용하는 기본 메시지 핸들러는 HttpClientHandler입니다.
.NET Core 2.1부터 클래스소켓 HttpHandler는 더 높은 수준의 HTTP 네트워킹 클래스를 제공합니다(예: HttpClient). 소켓 HttpHandler를 사용하면 다음과 같은 장점이 있습니다:
성능은 이전 구현에 비해 크게 향상되었습니다.
배포와 서비스를 단순화하기 위해 플랫폼 의존성을 제거하세요. 예를 들어, libcurl은 더 이상 macOS용 .NET Core와 Linux용 .NET Core에 의존하지 않습니다.
모든 .NET 플랫폼에서 일관된 동작이 이루어졌습니다.
.NET 9에서 HttpClientFactory는 SocketsHttpHandler를 메인 핸들러로 사용합니다
HttpClientFactory는 이름이 명명되고 타입이 지정된 HttpMessageHandler 객체에 대해 HttpClient 파이프라인을 구성할 수 있게 해줍니다. 가장 안쪽 핸들러, 즉 실제로 네트워크에서 요청을 보내는 핸들러를 마스터 핸들러라고 부릅니다. 설정되지 않은 경우, 이 핸들러는 항상 이전에는 HttpClientHandler였습니다. 기본 마스터 핸들러는 구현 세부 정보이지만, 이를 의존하는 사용자도 있습니다. 예를 들어, 일부 사용자는 메인 핸들러를 ClientCertificates, UseCookies, UseProxy와 같은 HttpClientHandler 설정 속성에 캐스트하기도 합니다.
링크:하이퍼링크 로그인이 보입니다.
전역 구성은 HTTP 프로토콜 버전을 요청합니다
코드는 다음과 같습니다:
DefaultRequestVersion기본 설정은 HttpVersion.Version11입니다。
DefaultRequestVersion 속성은 이 HttpClient 인스턴스를 통해 전송할 요청에 사용할 기본 HTTP 버전을 지정하며, HttpRequestMessage를 생성할 때 、、、GetStreamAsyncGetAsyncGetByteArrayAsync, PatchAsyncGetStringAsync, PostAsync와 PutAsync.
DefaultRequestVersion 속성SendAsync 메서드에는 적용되지 않습니다。 HttpRequestMessage 매개변수는 SendAsync 메서드에 전달된 매개변수로, 요청에 사용되는 HTTP 버전을 제어하는 자체 Version 속성을 가집니다.
링크:하이퍼링크 로그인이 보입니다.
HttpVersionPolicy 협상 정책
RequestVersionOrLower: 요청된 버전을 사용하거나, 요청된 버전보다 높지 않은 낮은 버전으로 다운그레이드하세요. 이것이 기본 동작입니다. 간단히 말해, 가장 많이 사용되는 프로토콜 버전은 현재 버전이며, 현재 프로토콜 버전이 지원되지 않으면 다운그레이드됩니다.
RequestVersionOrHigher: 서버에서 지원하는 가장 높은 버전을 사용하되, 요청된 버전보다 낮지 않게 사용하세요. 즉, 업그레이드는 허용되며, 요청된 버전 이하의 다운그레이드는 허용되지 않습니다. 간단히 말해, 가능한 한 상위 버전 프로토콜을 사용해 통신하세요.
RequestVersionExact: 요청된 버전을 엄격히 사용하며, 업그레이드나 다운그레이드는 허용되지 않습니다.
HttpClient는 Http/2.0 버전 프로토콜을 사용합니다
테스트 코드는 다음과 같습니다:
요청은 버전 1.1을 사용하며, 최종 클라이언트와 서버는 2.0 프로토콜을 사용하기로 협상하여 최종 응답은 아래 그림과 같이 버전 2.0입니다:
참조:
하이퍼링크 로그인이 보입니다.
하이퍼링크 로그인이 보입니다.
하이퍼링크 로그인이 보입니다. |
2025-8-31 21:16:47에 게시됨
|
|
|
|
집주인|
2025-8-31 21:46:27에 게시됨
|
