HttpClient vs HttpWebRequest pour de meilleures performances et de sécurité et moins de connexions

J'ai fait quelques test simple pour la comparaison et les quelques infos que j'ai trouvées

Unique HttpClient pourrait être partagée par plusieurs demande, si elle est partagée, et les demandes sont à la même destination, la demande multiple est possible de réutiliser les connexions
WebRequest besoin de recréer le lien pour chaque demande.

J'ai aussi cherché de la documentation sur d'autres façons d'utiliser HttpClient exemple

L'article suivant résume la haute vitesse authentifié NTLM partage de connexion

HttpWebRequest.UnsafeAuthenticatedConnectionSharing
Implémentations possibles que j'ai essayé sont indiqués ci-dessous

A)

private WebRequestHandler GetWebRequestHandler()
{
    CredentialCache credentialCache = new CredentialCache();
    credentialCache.Add(ResourceUriCanBeAnyUri, "NTLM", CredentialCache.DefaultNetworkCredentials);
    WebRequestHandler handler = new WebRequestHandler
    {
        UnsafeAuthenticatedConnectionSharing = true,
        Credentials = credentialCache
    };

    return handler;
}

using (HttpClient client = new HttpClient(GetWebRequestHandler(), false))
{
}

B)

using (HttpClient client = new HttpClient)
    {
    }

C)

HttpWebRequest req = (HttpWebRequest)WebRequest.Create("some uri string")

Je vous serais reconnaissant de toute aide en me faisant comprendre l'approche que je devrais prendre de façon à atteindre le max de performance , en minimisant les connexions et assurez-vous la sécurité n'est pas impacté.

HttpClient est le nouveau cool kid de la ville et il est soi-disant le meilleur de tous, prend en charge async/tâches, et est beaucoup plus mobiles que d'autres (il y a aussi WebClient). Cependant, il nécessite .NET 4.5+. Cela étant dit, je ne pense pas que vous devriez voir beaucoup de différences entre eux en termes de performances brutes lorsqu'il est utilisé correctement.
Je vous l'utilisez HttpClient ont un coup d'oeil à ce post VOUS UTILISEZ HTTPCLIENT MAL ET C'EST DÉSTABILISANT VOTRE LOGICIEL
certainement aller avec HttpClient, hormis le fait qu'il gère le regroupement de connexion, async/await hors de la boîte, il offre plus de flexibilité par leur intermédiaire des Gestionnaires et est également plus facile d'écrire des tests unitaires avec HttpClient.
HttpClient est conçu pour être instancié une fois et ré-utilisé tout au long de la durée de vie d'une application. En particulier dans les applications serveur, la création d'une nouvelle HttpClient instance pour chaque demande d'échappement, le nombre de sockets disponibles sous de lourdes charges. Cela entraînera une exception socketexception erreurs. Exemple: asp.net/web-api/overview/advanced/...

OriginalL'auteur StackOverflowVeryHelpful | 2015-01-06

  1. 16

    Si vous utilisez l'un ou l'autre avec async il devrait être bon pour le point de vue des performances qu'elle ne bloquera que les ressources d'attente pour la réponse et vous obtiendrez un bon débit.

    HttpClient est préféré au HttpWebRequest en raison de méthodes asynchrones disponible hors de la boîte et vous n'auriez pas à vous inquiéter au sujet de l'écriture de début/fin de méthodes.

    Fondamentalement, lorsque vous utilisez l'appel asynchrone (à l'aide de la classe), elle ne bloquera que les ressources d'attente pour la réponse et toute autre demande d'exploiter les ressources pour faire d'autres appels.

    Une autre chose à garder à l'esprit que vous ne devriez pas utiliser HttpClient dans l' "à l'aide" en bloc afin de permettre leur réutilisation des mêmes ressources, encore et encore pour d'autres demandes web.

    Voir le fil de discussion suivant pour plus d'informations

    Ne HttpClient et HttpClientHandler doivent être éliminés?

    Yep, juste de appris à propos de l'élimination HttpClient moi-même. Semble être la grande discussion actuellement. Longue histoire courte, ne la jetez pas!

    OriginalL'auteur Sujit Singh

  2. 1

    C'est mon ApiClient qui crée la HttpClient pour qu'une seule fois. Enregistrer cet objet en tant que singleton à votre dépendance à l'injection de la bibliothèque. Il est sûr de réutiliser car il est apatride. Ne PAS recréer HTTPClient pour chaque demande. La réutilisation Httpclient autant que possible

    using System;
using System.Net;
using System.Net.Http;
using System.Net.Http.Headers;
using System.Text;
using System.Threading.Tasks;
//You need to install package Newtonsoft.Json > https://www.nuget.org/packages/Newtonsoft.Json/
using Newtonsoft.Json;
using Newtonsoft.Json.Serialization;
public class MyApiClient : IDisposable
{
private readonly TimeSpan _timeout;
private HttpClient _httpClient;
private HttpClientHandler _httpClientHandler;
private readonly string _baseUrl;
private const string ClientUserAgent = "my-api-client-v1";
private const string MediaTypeJson = "application/json";
public MyApiClient(string baseUrl, TimeSpan? timeout = null)
{
_baseUrl = NormalizeBaseUrl(baseUrl);
_timeout = timeout ?? TimeSpan.FromSeconds(90);   
}
public async Task<string> PostAsync(string url, object input)
{
EnsureHttpClientCreated();
using (var requestContent = new StringContent(ConvertToJsonString(input), Encoding.UTF8, MediaTypeJson))
{
using (var response = await _httpClient.PostAsync(url, requestContent))
{
response.EnsureSuccessStatusCode();
return await response.Content.ReadAsStringAsync();
}
}
}
public async Task<TResult> PostAsync<TResult>(string url, object input) where TResult : class, new()
{
var strResponse = await PostAsync(url, input);
return JsonConvert.DeserializeObject<TResult>(strResponse, new JsonSerializerSettings
{
ContractResolver = new CamelCasePropertyNamesContractResolver()
});
}
public async Task<TResult> GetAsync<TResult>(string url) where TResult : class, new()
{
var strResponse = await GetAsync(url);
return JsonConvert.DeserializeObject<TResult>(strResponse, new JsonSerializerSettings
{
ContractResolver = new CamelCasePropertyNamesContractResolver()
});
}
public async Task<string> GetAsync(string url)
{
EnsureHttpClientCreated();
using (var response = await _httpClient.GetAsync(url))
{
response.EnsureSuccessStatusCode();
return await response.Content.ReadAsStringAsync();
}
}
public async Task<string> PutAsync(string url, object input)
{
return await PutAsync(url, new StringContent(JsonConvert.SerializeObject(input), Encoding.UTF8, MediaTypeJson));
}
public async Task<string> PutAsync(string url, HttpContent content)
{
EnsureHttpClientCreated();
using (var response = await _httpClient.PutAsync(url, content))
{
response.EnsureSuccessStatusCode();
return await response.Content.ReadAsStringAsync();
}
}
public async Task<string> DeleteAsync(string url)
{
EnsureHttpClientCreated();
using (var response = await _httpClient.DeleteAsync(url))
{
response.EnsureSuccessStatusCode();
return await response.Content.ReadAsStringAsync();
}
}
public void Dispose()
{
_httpClientHandler?.Dispose();
_httpClient?.Dispose();
}
private void CreateHttpClient()
{
_httpClientHandler = new HttpClientHandler
{
AutomaticDecompression = DecompressionMethods.Deflate | DecompressionMethods.GZip
};
_httpClient = new HttpClient(_httpClientHandler, false)
{
Timeout = _timeout
};
_httpClient.DefaultRequestHeaders.UserAgent.ParseAdd(ClientUserAgent);
if (!string.IsNullOrWhiteSpace(_baseUrl))
{
_httpClient.BaseAddress = new Uri(_baseUrl);
}
_httpClient.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue(MediaTypeJson));
}
private void EnsureHttpClientCreated()
{
if (_httpClient == null)
{
CreateHttpClient();
}
}
private static string ConvertToJsonString(object obj)
{
if (obj == null)
{
return string.Empty;
}
return JsonConvert.SerializeObject(obj, new JsonSerializerSettings
{
ContractResolver = new CamelCasePropertyNamesContractResolver()
});
}
private static string NormalizeBaseUrl(string url)
{
return url.EndsWith("/") ? url : url + "/";
}
}

    L'utilisation;

    using ( var client = new MyApiClient("http://localhost:8080"))
{
var response = client.GetAsync("api/users/findByUsername?username=alper").Result;
var userResponse = client.GetAsync<MyUser>("api/users/findByUsername?username=alper").Result;
}
    Très bonne mise en œuvre

    OriginalL'auteur Alper Ebicoglu

  3. 0

    1. Il y a un problème dans votre mise en œuvre "Un". La durée de vie de l'instance retournée à partir de GetWebRequestHandler() est de courte durée (peut-être juste pour le plaisir de l'exemple?). Si cela a été fait exprès, il nie le passage de false pour le 2ème paramètre de HttpClient constructeur. La valeur de false raconte l'HttpClient pour ne pas céder sous-jacents HttpMessageHandler (qui aide à la mise à l'échelle, car il n'est pas de fermer le port de la demande). C'est, bien sûr, en supposant que la durée de vie de la HttpMessageHandler est assez long pour vous de profiter de l'avantage de ne pas l'ouverture/fermeture des ports (ce qui est un gros impact sur l'évolutivité de votre serveur). Donc, j'ai une recommandation ci-dessous de l'option "D".

    2. Il existe également une option " D " que vous n'avez pas la liste ci - dessus pour faire de la Httpclient instance static et ré-utilisé dans tous les appels d'api. C'est beaucoup plus efficace de l'allocation de mémoire et GC point de vue - ainsi que l'ouverture des ports sur le client. Vous n'avez pas la surcharge de l'allocation de la mémoire et de la création de HttpClient instances (et de tous ses objets sous-jacents) et ainsi éviter de le nettoyage par GC pour eux aussi.

    Veuillez vous référer à ma réponse sur une question similaire - Qu'est-ce que la surcharge de la création d'un nouveau HttpClient par appel dans un WebAPI client?

    OriginalL'auteur Dave Black