자세히 ASP.NET Core와 OWIN의 관계

전언
요즘은 일만 빼고 모든 시간을 제가 예전에 이룬 Owin 프레임을 이식하는 거예요. 코어에 이식하면 구멍이 많을 거예요. 그건 다들 아시겠지만 앞으로 몇 편의 글이 이걸 둘러싸고 얘기할 수도 있어요. 당분간'Dotnet Core 구덩이 밟기'라고 할게요.
이어서 저는 이식 과정에서 발견한 문제점을 정리했고 오늘은 주로 Owin에 대해 이야기했습니다.오윈 하면 카타나 프로젝트와 우내대신의 Tinyfox를 빼놓을 수 없다. 물론 이 두 가지 내용에 관한 이 글은 많이 언급되지 않았다. 블로거들은 스스로 블로그 마당에서 오윈에 관한 글을 검색할 수 있는 글이 꽤 많다.
　　Owin
　　ASP.NET vNext가 처음 출시되었을 때 Owin의 실현이라고 불렸는데,http://owin.org위, 지금까지도 이러한 묘사가 남아 있다.
　　Implementations

　　　　Katana

　　　　Freya

　　　　ASP.NET vNext

많은 개발자들이 자신의 Owin 프레임워크를 실현하고 실제 생산 환경에 많이 응용했다. 물론 나도 그 중의 한 사람이다.
　　ASP.NET Core
이식 과정에서 많은 차이점을 발견할 수 있고 새로운 API를 만나면 어떻게 사용하는지 모르기 때문에 이럴 때 문서를 보는 것보다 원본을 직접 보는 것이 시원하다.
AspCore를 보고 있습니다.Mvc를 보고 나서야 Owin에 대한 내용이 하나도 없다는 것을 발견했다.그러나 분명히 공식 문서에서 Owin 프로토콜을 지원한다고 했는데 나중에 나는 억지로 Kestrel Http Server와 Http Abstractions 두 항목을 보았는데 알고 보니 Owin 프로토콜 내용이 전혀 없었다는 것을 알게 되었다(MS에 반드시 나쁜 평가를 해야 한다).
알겠습니다. MS가 어떻게 Owin을 지원하는지 볼 수 있을 뿐입니다. Http Abstractions 프로젝트에서 Microsoft를 발견했습니다.AspNetCore.Owin이라는 하위 항목을 보고 나서 "그런 뜻으로 아래로 호환되는 거야?"라고 말하고 싶었어요.됐어.지금 Asp.에서만netcore 프로젝트에 Microsoft 의존 가입AspNet.Owin은 IApplication Builder 인터페이스의 확장 방법인 UseOwin에서 Owin 중간부품을 호출할 수 있습니다.다음과 같습니다.
종속성 추가:

 "dependencies": {
    "Microsoft.AspNet.Server.Kestrel": "1.0.0-*",
    "Microsoft.AspNet.Owin": "1.0.0-*"
  },

Startup에 UseOwin을 추가하려면:
 

1 public void Configure(IApplicationBuilder app)
2 {
3     app.UseOwin(pipeline =>
4   {
5         pipeline(next => OwinHello);
6   });
7 }

 
물론 OwinHello의 내용은 표준 Owin 중간부품의 내용일 것이다.

 1 public Task OwinHello(IDictionary<string, object> environment)
 2 {
 3     string responseText = "Hello World via OWIN";
 4     byte[] responseBytes = Encoding.UTF8.GetBytes(responseText);
 5     var responseStream = (Stream)environment["owin.ResponseBody"];
 6     var responseHeaders = (IDictionary<string, string[]>)environment["owin.ResponseHeaders"];
 7     responseHeaders["Content-Length"] = new string[] { responseBytes.Length.ToString(CultureInfo.InvariantCulture) };
 8     responseHeaders["Content-Type"] = new string[] { "text/plain" };
 9     return responseStream.WriteAsync(responseBytes, 0, responseBytes.Length);
10 }

　　Kestrel
새 서버가 Owin 프로토콜을 지원하지 않는 이상 어떻게 통신합니까?
이 문제는 ASP에 있습니다.NET Core 파이프 심도 분석 시리즈에서 언급되었는데, 사실 모든 Http Context는 만들어지면 IFeature Collection 집합에 의존한다.
Ifeature Collection 인터페이스는 Feature 인터페이스 세트로 구성된 객체 세트의 피쳐를 설명하는 데 사용됩니다.
Http에 대한 연결 정보를 얻기 위한 IHttpConnectionFeature 인터페이스 중 하나를 나열합니다.

public class HttpConnectionFeature : IHttpConnectionFeature
{
        public string ConnectionId { get; set; }
        public IPAddress LocalIpAddress { get; set; }
        public int LocalPort { get; set; }
        public IPAddress RemoteIpAddress { get; set; }
        public int RemotePort { get; set; }
}

kestrel 원본을 읽으면 tcp 연결을 받을 때마다 Http 흐름을 프레임 프레임에 봉인합니다. 이것은 단방향 또는 양방향 Request와response로 설명됩니다.특징 집합으로 조립하여 상부 응용에 사용하도록 한다.
최후
마지막으로 Owin 사전에서 Feature에 대응하는 원본 코드를 보내십시오:

 _entries = new Dictionary<string, FeatureMap>()
            {
                { OwinConstants.RequestProtocol, new FeatureMap(feature => feature.Protocol, () => string.Empty, (feature, value) => feature.Protocol = Convert.ToString(value)) },
                { OwinConstants.RequestScheme, new FeatureMap(feature => feature.Scheme, () => string.Empty, (feature, value) => feature.Scheme = Convert.ToString(value)) },
                { OwinConstants.RequestMethod, new FeatureMap(feature => feature.Method, () => string.Empty, (feature, value) => feature.Method = Convert.ToString(value)) },
                { OwinConstants.RequestPathBase, new FeatureMap(feature => feature.PathBase, () => string.Empty, (feature, value) => feature.PathBase = Convert.ToString(value)) },
                { OwinConstants.RequestPath, new FeatureMap(feature => feature.Path, () => string.Empty, (feature, value) => feature.Path = Convert.ToString(value)) },
                { OwinConstants.RequestQueryString, new FeatureMap(feature => Utilities.RemoveQuestionMark(feature.QueryString), () => string.Empty,
                    (feature, value) => feature.QueryString = Utilities.AddQuestionMark(Convert.ToString(value))) },
                { OwinConstants.RequestHeaders, new FeatureMap(feature => Utilities.MakeDictionaryStringArray(feature.Headers), (feature, value) => feature.Headers = Utilities.MakeHeaderDictionary((IDictionary<string, string[]>)value)) },
                { OwinConstants.RequestBody, new FeatureMap(feature => feature.Body, () => Stream.Null, (feature, value) => feature.Body = (Stream)value) },
                { OwinConstants.RequestUser, new FeatureMap(feature => feature.User, () => null, (feature, value) => feature.User = (ClaimsPrincipal)value) },
                { OwinConstants.ResponseStatusCode, new FeatureMap(feature => feature.StatusCode, () => 200, (feature, value) => feature.StatusCode = Convert.ToInt32(value)) },
                { OwinConstants.ResponseReasonPhrase, new FeatureMap(feature => feature.ReasonPhrase, (feature, value) => feature.ReasonPhrase = Convert.ToString(value)) },
                { OwinConstants.ResponseHeaders, new FeatureMap(feature => Utilities.MakeDictionaryStringArray(feature.Headers), (feature, value) => feature.Headers = Utilities.MakeHeaderDictionary((IDictionary<string, string[]>)value)) },
                { OwinConstants.ResponseBody, new FeatureMap(feature => feature.Body, () => Stream.Null, (feature, value) => feature.Body = (Stream)value) },

잘 됐다고만 말할 수 있죠,성능은 손실이 많지 않아요.잘 붙지 않아요.다 알아서 보세요.)
물론 MS가 이렇게 하는 것도 의미가 있다. 그들은 사전의 방식을 별로 좋아하지 않기 때문에 Feature라는 방식으로 이런 내용을'강유형화했다'.이것은 기본 서버의 경우 이 특징을 바탕으로 ASP를 지원하기 위한 중간부품을 2차 개발할 수 있다.NET Core는 물론 서버 내에서 이러한 성능을 직접 구현할 수도 있습니다.
API의 변화가 좀 빠르다고 말할 수 밖에 없지만, 원본을 시작하는 데는 며칠 동안 원본을 보면 다 알 수 있다. 이것은 우리dotnet 개발자들에게 정말 큰 좋은 일이다.