Expose HTTP.sys kernel response buffering control for HttpListener on Windows

[karimsalem1]

This PR adds an opt-in AppContext switch to enable kernel response buffering in HttpListener (Windows implementation only). When enabled, the flag HTTP_SEND_RESPONSE_FLAG_BUFFER_DATA is set on all calls to HttpSendHttpResponse and HttpSendResponseEntityBody (consistent with Win32 docs). This mirrors the behavior for setting the HttpSysOptions.EnableKernelResponseBuffering flag in ASP.NET HTTP.sys code.

Motivation in issue #123425.

Sample usage:

AppContext.SetSwitch("System.Net.HttpListener.EnableKernelResponseBuffering",true);usingvarlistener=newHttpListener();listener.Prefixes.Add("http://localhost:8080/");listener.Start();Console.WriteLine("Listening...");while(true){varcontext=awaitlistener.GetContextAsync().ConfigureAwait(false);_=Task.Run(()=>HandleRequestAsync(context));}

Notes:

• No public API changes
• Default behavior remains unchanged
• Since API is internal, tests use reflection to validate flag behavior.
• Added dedicated Windows-only test classes for HttpListener and HttpResponseStream, and consolidated existing Windows-only tests there for consistency.

Repro and validation

Setup:

• Client: Azure VM in West US 2
• Server: Azure VM in Australia East

Client uses HttpClient to send requests to the server and measures total latency. Server is running HttpListener and returns 7MB responses while varying the server-side response buffer size (from 32KB to 7MB). Server also records avg timing per individual response Write() call.

Benchmark

Kernel Buffering Disabled (Existing Behavior)

Buffer Size (bytes)	Latency (ms)	Write Time (µs)
32768	33911	158414
65536	16923	158108
131072	8609	159346
262144	4323	159938
524288	2296	163629
1048576	1181	168004
2097152	701	173846
4194304	468	206004
7000000	492	384459

Kernel Buffering Enabled (New Behavior)

Buffer Size (bytes)	Latency (ms)	Write Time (µs)
32768	1154	4589
65536	1149	9211
131072	1142	18205
262144	1107	35590
524288	1137	69975
1048576	686	75492
2097152	386	92539
4194304	451	109173
7000000	490	2356

• Enabling HttpListener kernel buffering reduces E2E latency by up to 30x (34s → 1s for 32KB buffers)
• Average Write() time drops significantly (158,414 µs → 4,589 µs at 32 KB).

These results confirm that without kernel buffering, small writes cause RTT amplification. Enabling kernel buffering eliminates small-write fragmentation over the wire and dramatically reduces latency.

Packet Capture

Packet analysis

Without kernel buffering, when the server sends a 7MB response using a 32KB buffer, packet capture shows that each server Write() results in a 32KB TCP segment (Length=32768, [PSH, ACK]). Each segment is transmitted approx. 1 RTT apart (~0.158s matching Azure-advertised RTT b/w the two regions). Transmission is effectively ACK-gated.

E2E the request takes ~34s:

With kernel buffering enabled, the TCP stack transmits large bursts of packets rather than one per RTT.

E2E latency dropped from ~34s to ~1s (first request ~1.9s due to TCP slow start, subsequent requests stabilize at ~0.95s).

TCP stream graph

The diff in behavior is best visualized using the Stevens TCP stream graph:

Without kernel buffering, the graph shows each ~32 KB increment in response transmission is separated by approx. one RTT. The slope is shallow (slow rate of growth) and evenly spaced.

With kernel buffering enabled, the slope becomes significantly steeper. Multiple segments are transmitted back-to-back before the next RTT boundary.

This visualizes the core issue: without buffering, small writes are RTT-amplified. With buffering, HTTP.sys aggregates response data in kernel space and transmits in large bursts, eliminating per-write RTT pacing.

Repro code

Init HttpListener with EnableKernelResponseBuffering switch

varlistener=newHttpListener();if(enableBuffering){AppContext.SetSwitch("System.Net.HttpListener.EnableKernelResponseBuffering",true);}listener.Prefixes.Add("http://+:80/");listener.Start();while(true){varcontext=awaitlistener.GetContextAsync();try{longresponseSize=long.Parse(context.Request.QueryString["size"]);intbufferSize=int.Parse(context.Request.QueryString["buffer"]);context.Response.StatusCode=200;awaitSendListenerResponse(context,responseSize,bufferSize);}finally{context.Response.Close();}}

Server multi-write response routine

varbuf=newbyte[bufferSize];longtotalWriteUs=0;intwriteCount=0;longtotalSent=0;while(totalSent<size){intwriteSize=(int)Math.Min(size-totalSent,bufferSize);longstart=Stopwatch.GetTimestamp();awaitstream.WriteAsync(buf.AsMemory(0,writeSize));longend=Stopwatch.GetTimestamp();totalWriteUs+=(end-start)/10;writeCount++;totalSent+=writeSize;}longavgWriteUs=totalWriteUs/writeCount;

Thanks @ManickaP for all the help!

[dotnet-policy-service]

Tagging subscribers to this area: @karelz, @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[jkotas]

No public API changes

AppContext switches are de-facto public APIs, just a different kind.

[ManickaP]

One comment otherwise LGTM. I'll await the manual validation results.

Thanks!

[jkotas]

This should be documented in https://github.com/dotnet/dotnet-api-docs/blob/main/xml/System.Net/HttpListener.xml

[karimsalem1]

This should be documented in https://github.com/dotnet/dotnet-api-docs/blob/main/xml/System.Net/HttpListener.xml

Added public docs here, thank you.

[karimsalem1]

This PR adds an opt-in AppContext switch to enable kernel response buffering in HttpListener (Windows implementation only). When enabled, the flag HTTP_SEND_RESPONSE_FLAG_BUFFER_DATA is set on all calls to HttpSendHttpResponse and HttpSendResponseEntityBody (consistent with Win32 docs). This mirrors the behavior for setting the HttpSysOptions.EnableKernelResponseBuffering flag in ASP.NET HTTP.sys code.

Motivation in issue #123425.

Sample usage:

AppContext.SetSwitch("System.Net.HttpListener.EnableKernelResponseBuffering",true);usingvarlistener=newHttpListener();listener.Prefixes.Add("http://localhost:8080/");listener.Start();Console.WriteLine("Listening...");while(true){varcontext=awaitlistener.GetContextAsync().ConfigureAwait(false);_=Task.Run(()=>HandleRequestAsync(context));}

Notes:

• No public API changes
• Default behavior remains unchanged
• Since API is internal, tests use reflection to validate flag behavior.
• Added dedicated Windows-only test classes for HttpListener and HttpResponseStream, and consolidated existing Windows-only tests there for consistency.

Repro and validation

Setup:

• Client: Azure VM in West US 2
• Server: Azure VM in Australia East

Client uses HttpClient to send requests to the server and measures total latency. Server is running HttpListener and returns 7MB responses while varying the server-side response buffer size (from 32KB to 7MB). Server also records avg timing per individual response Write() call.

Benchmark

Kernel Buffering Disabled (Existing Behavior)

Buffer Size (bytes)	Latency (ms)	Write Time (µs)
32768	33911	158414
65536	16923	158108
131072	8609	159346
262144	4323	159938
524288	2296	163629
1048576	1181	168004
2097152	701	173846
4194304	468	206004
7000000	492	384459

Kernel Buffering Enabled (New Behavior)

Buffer Size (bytes)	Latency (ms)	Write Time (µs)
32768	1154	4589
65536	1149	9211
131072	1142	18205
262144	1107	35590
524288	1137	69975
1048576	686	75492
2097152	386	92539
4194304	451	109173
7000000	490	2356

• Enabling HttpListener kernel buffering reduces E2E latency by up to 30x (34s → 1s for 32KB buffers)
• Average Write() time drops significantly (158,414 µs → 4,589 µs at 32 KB).

These results confirm that without kernel buffering, small writes cause RTT amplification. Enabling kernel buffering eliminates small-write fragmentation over the wire and dramatically reduces latency.

Packet Capture

Packet analysis

Without kernel buffering, when the server sends a 7MB response using a 32KB buffer, packet capture shows that each server Write() results in a 32KB TCP segment (Length=32768, [PSH, ACK]). Each segment is transmitted approx. 1 RTT apart (~0.158s matching Azure-advertised RTT b/w the two regions). Transmission is effectively ACK-gated.

E2E the request takes ~34s:

With kernel buffering enabled, the TCP stack transmits large bursts of packets rather than one per RTT.

E2E latency dropped from ~34s to ~1s (first request ~1.9s due to TCP slow start, subsequent requests stabilize at ~0.95s).

TCP stream graph

The diff in behavior is best visualized using the Stevens TCP stream graph:

Without kernel buffering, the graph shows each ~32 KB increment in response transmission is separated by approx. one RTT. The slope is shallow (slow rate of growth) and evenly spaced.

With kernel buffering enabled, the slope becomes significantly steeper. Multiple segments are transmitted back-to-back before the next RTT boundary.

This visualizes the core issue: without buffering, small writes are RTT-amplified. With buffering, HTTP.sys aggregates response data in kernel space and transmits in large bursts, eliminating per-write RTT pacing.

Repro code

Init HttpListener with EnableKernelResponseBuffering switch

varlistener=newHttpListener();if(enableBuffering){AppContext.SetSwitch("System.Net.HttpListener.EnableKernelResponseBuffering",true);}listener.Prefixes.Add("http://+:80/");listener.Start();while(true){varcontext=awaitlistener.GetContextAsync();try{longresponseSize=long.Parse(context.Request.QueryString["size"]);intbufferSize=int.Parse(context.Request.QueryString["buffer"]);context.Response.StatusCode=200;awaitSendListenerResponse(context,responseSize,bufferSize);}finally{context.Response.Close();}}

Server multi-write response routine

varbuf=newbyte[bufferSize];longtotalWriteUs=0;intwriteCount=0;longtotalSent=0;while(totalSent<size){intwriteSize=(int)Math.Min(size-totalSent,bufferSize);longstart=Stopwatch.GetTimestamp();awaitstream.WriteAsync(buf.AsMemory(0,writeSize));longend=Stopwatch.GetTimestamp();totalWriteUs+=(end-start)/10;writeCount++;totalSent+=writeSize;}longavgWriteUs=totalWriteUs/writeCount;

Thanks @ManickaP for all the help!

[dotnet-policy-service]

Tagging subscribers to this area: @karelz, @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[jkotas]

No public API changes

AppContext switches are de-facto public APIs, just a different kind.

[ManickaP]

One comment otherwise LGTM. I'll await the manual validation results.

Thanks!

[jkotas]

This should be documented in https://github.com/dotnet/dotnet-api-docs/blob/main/xml/System.Net/HttpListener.xml

[karimsalem1]

This should be documented in https://github.com/dotnet/dotnet-api-docs/blob/main/xml/System.Net/HttpListener.xml

Added public docs here, thank you.

[karimsalem1]

This PR adds an opt-in AppContext switch to enable kernel response buffering in HttpListener (Windows implementation only). When enabled, the flag HTTP_SEND_RESPONSE_FLAG_BUFFER_DATA is set on all calls to HttpSendHttpResponse and HttpSendResponseEntityBody (consistent with Win32 docs). This mirrors the behavior for setting the HttpSysOptions.EnableKernelResponseBuffering flag in ASP.NET HTTP.sys code.

Motivation in issue #123425.

Sample usage:

AppContext.SetSwitch("System.Net.HttpListener.EnableKernelResponseBuffering",true);usingvarlistener=newHttpListener();listener.Prefixes.Add("http://localhost:8080/");listener.Start();Console.WriteLine("Listening...");while(true){varcontext=awaitlistener.GetContextAsync().ConfigureAwait(false);_=Task.Run(()=>HandleRequestAsync(context));}

Notes:

• No public API changes
• Default behavior remains unchanged
• Since API is internal, tests use reflection to validate flag behavior.
• Added dedicated Windows-only test classes for HttpListener and HttpResponseStream, and consolidated existing Windows-only tests there for consistency.

Repro and validation

Setup:

• Client: Azure VM in West US 2
• Server: Azure VM in Australia East

Client uses HttpClient to send requests to the server and measures total latency. Server is running HttpListener and returns 7MB responses while varying the server-side response buffer size (from 32KB to 7MB). Server also records avg timing per individual response Write() call.

Benchmark

Kernel Buffering Disabled (Existing Behavior)

Buffer Size (bytes)	Latency (ms)	Write Time (µs)
32768	33911	158414
65536	16923	158108
131072	8609	159346
262144	4323	159938
524288	2296	163629
1048576	1181	168004
2097152	701	173846
4194304	468	206004
7000000	492	384459

Kernel Buffering Enabled (New Behavior)

Buffer Size (bytes)	Latency (ms)	Write Time (µs)
32768	1154	4589
65536	1149	9211
131072	1142	18205
262144	1107	35590
524288	1137	69975
1048576	686	75492
2097152	386	92539
4194304	451	109173
7000000	490	2356

• Enabling HttpListener kernel buffering reduces E2E latency by up to 30x (34s → 1s for 32KB buffers)
• Average Write() time drops significantly (158,414 µs → 4,589 µs at 32 KB).

These results confirm that without kernel buffering, small writes cause RTT amplification. Enabling kernel buffering eliminates small-write fragmentation over the wire and dramatically reduces latency.

Packet Capture

Packet analysis

Without kernel buffering, when the server sends a 7MB response using a 32KB buffer, packet capture shows that each server Write() results in a 32KB TCP segment (Length=32768, [PSH, ACK]). Each segment is transmitted approx. 1 RTT apart (~0.158s matching Azure-advertised RTT b/w the two regions). Transmission is effectively ACK-gated.

E2E the request takes ~34s:

With kernel buffering enabled, the TCP stack transmits large bursts of packets rather than one per RTT.

E2E latency dropped from ~34s to ~1s (first request ~1.9s due to TCP slow start, subsequent requests stabilize at ~0.95s).

TCP stream graph

The diff in behavior is best visualized using the Stevens TCP stream graph:

Without kernel buffering, the graph shows each ~32 KB increment in response transmission is separated by approx. one RTT. The slope is shallow (slow rate of growth) and evenly spaced.

With kernel buffering enabled, the slope becomes significantly steeper. Multiple segments are transmitted back-to-back before the next RTT boundary.

This visualizes the core issue: without buffering, small writes are RTT-amplified. With buffering, HTTP.sys aggregates response data in kernel space and transmits in large bursts, eliminating per-write RTT pacing.

Repro code

Init HttpListener with EnableKernelResponseBuffering switch

varlistener=newHttpListener();if(enableBuffering){AppContext.SetSwitch("System.Net.HttpListener.EnableKernelResponseBuffering",true);}listener.Prefixes.Add("http://+:80/");listener.Start();while(true){varcontext=awaitlistener.GetContextAsync();try{longresponseSize=long.Parse(context.Request.QueryString["size"]);intbufferSize=int.Parse(context.Request.QueryString["buffer"]);context.Response.StatusCode=200;awaitSendListenerResponse(context,responseSize,bufferSize);}finally{context.Response.Close();}}

Server multi-write response routine

varbuf=newbyte[bufferSize];longtotalWriteUs=0;intwriteCount=0;longtotalSent=0;while(totalSent<size){intwriteSize=(int)Math.Min(size-totalSent,bufferSize);longstart=Stopwatch.GetTimestamp();awaitstream.WriteAsync(buf.AsMemory(0,writeSize));longend=Stopwatch.GetTimestamp();totalWriteUs+=(end-start)/10;writeCount++;totalSent+=writeSize;}longavgWriteUs=totalWriteUs/writeCount;

Thanks @ManickaP for all the help!

[dotnet-policy-service]

Tagging subscribers to this area: @karelz, @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[jkotas]

No public API changes

AppContext switches are de-facto public APIs, just a different kind.

[ManickaP]

One comment otherwise LGTM. I'll await the manual validation results.

Thanks!

[jkotas]

This should be documented in https://github.com/dotnet/dotnet-api-docs/blob/main/xml/System.Net/HttpListener.xml

[karimsalem1]

This should be documented in https://github.com/dotnet/dotnet-api-docs/blob/main/xml/System.Net/HttpListener.xml

Added public docs here, thank you.

[karimsalem1]

This PR adds an opt-in AppContext switch to enable kernel response buffering in HttpListener (Windows implementation only). When enabled, the flag HTTP_SEND_RESPONSE_FLAG_BUFFER_DATA is set on all calls to HttpSendHttpResponse and HttpSendResponseEntityBody (consistent with Win32 docs). This mirrors the behavior for setting the HttpSysOptions.EnableKernelResponseBuffering flag in ASP.NET HTTP.sys code.

Motivation in issue #123425.

Sample usage:

AppContext.SetSwitch("System.Net.HttpListener.EnableKernelResponseBuffering",true);usingvarlistener=newHttpListener();listener.Prefixes.Add("http://localhost:8080/");listener.Start();Console.WriteLine("Listening...");while(true){varcontext=awaitlistener.GetContextAsync().ConfigureAwait(false);_=Task.Run(()=>HandleRequestAsync(context));}

Notes:

• No public API changes
• Default behavior remains unchanged
• Since API is internal, tests use reflection to validate flag behavior.
• Added dedicated Windows-only test classes for HttpListener and HttpResponseStream, and consolidated existing Windows-only tests there for consistency.

Repro and validation

Setup:

• Client: Azure VM in West US 2
• Server: Azure VM in Australia East

Client uses HttpClient to send requests to the server and measures total latency. Server is running HttpListener and returns 7MB responses while varying the server-side response buffer size (from 32KB to 7MB). Server also records avg timing per individual response Write() call.

Benchmark

Kernel Buffering Disabled (Existing Behavior)

Buffer Size (bytes)	Latency (ms)	Write Time (µs)
32768	33911	158414
65536	16923	158108
131072	8609	159346
262144	4323	159938
524288	2296	163629
1048576	1181	168004
2097152	701	173846
4194304	468	206004
7000000	492	384459

Kernel Buffering Enabled (New Behavior)

Buffer Size (bytes)	Latency (ms)	Write Time (µs)
32768	1154	4589
65536	1149	9211
131072	1142	18205
262144	1107	35590
524288	1137	69975
1048576	686	75492
2097152	386	92539
4194304	451	109173
7000000	490	2356

• Enabling HttpListener kernel buffering reduces E2E latency by up to 30x (34s → 1s for 32KB buffers)
• Average Write() time drops significantly (158,414 µs → 4,589 µs at 32 KB).

These results confirm that without kernel buffering, small writes cause RTT amplification. Enabling kernel buffering eliminates small-write fragmentation over the wire and dramatically reduces latency.

Packet Capture

Packet analysis

Without kernel buffering, when the server sends a 7MB response using a 32KB buffer, packet capture shows that each server Write() results in a 32KB TCP segment (Length=32768, [PSH, ACK]). Each segment is transmitted approx. 1 RTT apart (~0.158s matching Azure-advertised RTT b/w the two regions). Transmission is effectively ACK-gated.

E2E the request takes ~34s:

With kernel buffering enabled, the TCP stack transmits large bursts of packets rather than one per RTT.

E2E latency dropped from ~34s to ~1s (first request ~1.9s due to TCP slow start, subsequent requests stabilize at ~0.95s).

TCP stream graph

The diff in behavior is best visualized using the Stevens TCP stream graph:

Without kernel buffering, the graph shows each ~32 KB increment in response transmission is separated by approx. one RTT. The slope is shallow (slow rate of growth) and evenly spaced.

With kernel buffering enabled, the slope becomes significantly steeper. Multiple segments are transmitted back-to-back before the next RTT boundary.

This visualizes the core issue: without buffering, small writes are RTT-amplified. With buffering, HTTP.sys aggregates response data in kernel space and transmits in large bursts, eliminating per-write RTT pacing.

Repro code

Init HttpListener with EnableKernelResponseBuffering switch

varlistener=newHttpListener();if(enableBuffering){AppContext.SetSwitch("System.Net.HttpListener.EnableKernelResponseBuffering",true);}listener.Prefixes.Add("http://+:80/");listener.Start();while(true){varcontext=awaitlistener.GetContextAsync();try{longresponseSize=long.Parse(context.Request.QueryString["size"]);intbufferSize=int.Parse(context.Request.QueryString["buffer"]);context.Response.StatusCode=200;awaitSendListenerResponse(context,responseSize,bufferSize);}finally{context.Response.Close();}}

Server multi-write response routine

varbuf=newbyte[bufferSize];longtotalWriteUs=0;intwriteCount=0;longtotalSent=0;while(totalSent<size){intwriteSize=(int)Math.Min(size-totalSent,bufferSize);longstart=Stopwatch.GetTimestamp();awaitstream.WriteAsync(buf.AsMemory(0,writeSize));longend=Stopwatch.GetTimestamp();totalWriteUs+=(end-start)/10;writeCount++;totalSent+=writeSize;}longavgWriteUs=totalWriteUs/writeCount;

Thanks @ManickaP for all the help!

[dotnet-policy-service]

Tagging subscribers to this area: @karelz, @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[jkotas]

No public API changes

AppContext switches are de-facto public APIs, just a different kind.

[ManickaP]

One comment otherwise LGTM. I'll await the manual validation results.

Thanks!

[jkotas]

This should be documented in https://github.com/dotnet/dotnet-api-docs/blob/main/xml/System.Net/HttpListener.xml

[karimsalem1]

This should be documented in https://github.com/dotnet/dotnet-api-docs/blob/main/xml/System.Net/HttpListener.xml

Added public docs here, thank you.

[karimsalem1]

This PR adds an opt-in AppContext switch to enable kernel response buffering in HttpListener (Windows implementation only). When enabled, the flag HTTP_SEND_RESPONSE_FLAG_BUFFER_DATA is set on all calls to HttpSendHttpResponse and HttpSendResponseEntityBody (consistent with Win32 docs). This mirrors the behavior for setting the HttpSysOptions.EnableKernelResponseBuffering flag in ASP.NET HTTP.sys code.

Motivation in issue #123425.

Sample usage:

AppContext.SetSwitch("System.Net.HttpListener.EnableKernelResponseBuffering",true);usingvarlistener=newHttpListener();listener.Prefixes.Add("http://localhost:8080/");listener.Start();Console.WriteLine("Listening...");while(true){varcontext=awaitlistener.GetContextAsync().ConfigureAwait(false);_=Task.Run(()=>HandleRequestAsync(context));}

Notes:

• No public API changes
• Default behavior remains unchanged
• Since API is internal, tests use reflection to validate flag behavior.
• Added dedicated Windows-only test classes for HttpListener and HttpResponseStream, and consolidated existing Windows-only tests there for consistency.

Repro and validation

Setup:

• Client: Azure VM in West US 2
• Server: Azure VM in Australia East

Client uses HttpClient to send requests to the server and measures total latency. Server is running HttpListener and returns 7MB responses while varying the server-side response buffer size (from 32KB to 7MB). Server also records avg timing per individual response Write() call.

Benchmark

Kernel Buffering Disabled (Existing Behavior)

Buffer Size (bytes)	Latency (ms)	Write Time (µs)
32768	33911	158414
65536	16923	158108
131072	8609	159346
262144	4323	159938
524288	2296	163629
1048576	1181	168004
2097152	701	173846
4194304	468	206004
7000000	492	384459

Kernel Buffering Enabled (New Behavior)

Buffer Size (bytes)	Latency (ms)	Write Time (µs)
32768	1154	4589
65536	1149	9211
131072	1142	18205
262144	1107	35590
524288	1137	69975
1048576	686	75492
2097152	386	92539
4194304	451	109173
7000000	490	2356

• Enabling HttpListener kernel buffering reduces E2E latency by up to 30x (34s → 1s for 32KB buffers)
• Average Write() time drops significantly (158,414 µs → 4,589 µs at 32 KB).

These results confirm that without kernel buffering, small writes cause RTT amplification. Enabling kernel buffering eliminates small-write fragmentation over the wire and dramatically reduces latency.

Packet Capture

Packet analysis

Without kernel buffering, when the server sends a 7MB response using a 32KB buffer, packet capture shows that each server Write() results in a 32KB TCP segment (Length=32768, [PSH, ACK]). Each segment is transmitted approx. 1 RTT apart (~0.158s matching Azure-advertised RTT b/w the two regions). Transmission is effectively ACK-gated.

E2E the request takes ~34s:

With kernel buffering enabled, the TCP stack transmits large bursts of packets rather than one per RTT.

E2E latency dropped from ~34s to ~1s (first request ~1.9s due to TCP slow start, subsequent requests stabilize at ~0.95s).

TCP stream graph

The diff in behavior is best visualized using the Stevens TCP stream graph:

Without kernel buffering, the graph shows each ~32 KB increment in response transmission is separated by approx. one RTT. The slope is shallow (slow rate of growth) and evenly spaced.

With kernel buffering enabled, the slope becomes significantly steeper. Multiple segments are transmitted back-to-back before the next RTT boundary.

This visualizes the core issue: without buffering, small writes are RTT-amplified. With buffering, HTTP.sys aggregates response data in kernel space and transmits in large bursts, eliminating per-write RTT pacing.

Repro code

Init HttpListener with EnableKernelResponseBuffering switch

varlistener=newHttpListener();if(enableBuffering){AppContext.SetSwitch("System.Net.HttpListener.EnableKernelResponseBuffering",true);}listener.Prefixes.Add("http://+:80/");listener.Start();while(true){varcontext=awaitlistener.GetContextAsync();try{longresponseSize=long.Parse(context.Request.QueryString["size"]);intbufferSize=int.Parse(context.Request.QueryString["buffer"]);context.Response.StatusCode=200;awaitSendListenerResponse(context,responseSize,bufferSize);}finally{context.Response.Close();}}

Server multi-write response routine

varbuf=newbyte[bufferSize];longtotalWriteUs=0;intwriteCount=0;longtotalSent=0;while(totalSent<size){intwriteSize=(int)Math.Min(size-totalSent,bufferSize);longstart=Stopwatch.GetTimestamp();awaitstream.WriteAsync(buf.AsMemory(0,writeSize));longend=Stopwatch.GetTimestamp();totalWriteUs+=(end-start)/10;writeCount++;totalSent+=writeSize;}longavgWriteUs=totalWriteUs/writeCount;

Thanks @ManickaP for all the help!

[dotnet-policy-service]

Tagging subscribers to this area: @karelz, @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[jkotas]

No public API changes

AppContext switches are de-facto public APIs, just a different kind.

[ManickaP]

One comment otherwise LGTM. I'll await the manual validation results.

Thanks!

[jkotas]

This should be documented in https://github.com/dotnet/dotnet-api-docs/blob/main/xml/System.Net/HttpListener.xml

[karimsalem1]

This should be documented in https://github.com/dotnet/dotnet-api-docs/blob/main/xml/System.Net/HttpListener.xml

Added public docs here, thank you.

[karimsalem1]

This PR adds an opt-in AppContext switch to enable kernel response buffering in HttpListener (Windows implementation only). When enabled, the flag HTTP_SEND_RESPONSE_FLAG_BUFFER_DATA is set on all calls to HttpSendHttpResponse and HttpSendResponseEntityBody (consistent with Win32 docs). This mirrors the behavior for setting the HttpSysOptions.EnableKernelResponseBuffering flag in ASP.NET HTTP.sys code.

Motivation in issue #123425.

Sample usage:

AppContext.SetSwitch("System.Net.HttpListener.EnableKernelResponseBuffering",true);usingvarlistener=newHttpListener();listener.Prefixes.Add("http://localhost:8080/");listener.Start();Console.WriteLine("Listening...");while(true){varcontext=awaitlistener.GetContextAsync().ConfigureAwait(false);_=Task.Run(()=>HandleRequestAsync(context));}

Notes:

• No public API changes
• Default behavior remains unchanged
• Since API is internal, tests use reflection to validate flag behavior.
• Added dedicated Windows-only test classes for HttpListener and HttpResponseStream, and consolidated existing Windows-only tests there for consistency.

Repro and validation

Setup:

• Client: Azure VM in West US 2
• Server: Azure VM in Australia East

Client uses HttpClient to send requests to the server and measures total latency. Server is running HttpListener and returns 7MB responses while varying the server-side response buffer size (from 32KB to 7MB). Server also records avg timing per individual response Write() call.

Benchmark

Kernel Buffering Disabled (Existing Behavior)

Buffer Size (bytes)	Latency (ms)	Write Time (µs)
32768	33911	158414
65536	16923	158108
131072	8609	159346
262144	4323	159938
524288	2296	163629
1048576	1181	168004
2097152	701	173846
4194304	468	206004
7000000	492	384459

Kernel Buffering Enabled (New Behavior)

Buffer Size (bytes)	Latency (ms)	Write Time (µs)
32768	1154	4589
65536	1149	9211
131072	1142	18205
262144	1107	35590
524288	1137	69975
1048576	686	75492
2097152	386	92539
4194304	451	109173
7000000	490	2356

• Enabling HttpListener kernel buffering reduces E2E latency by up to 30x (34s → 1s for 32KB buffers)
• Average Write() time drops significantly (158,414 µs → 4,589 µs at 32 KB).

These results confirm that without kernel buffering, small writes cause RTT amplification. Enabling kernel buffering eliminates small-write fragmentation over the wire and dramatically reduces latency.

Packet Capture

Packet analysis

Without kernel buffering, when the server sends a 7MB response using a 32KB buffer, packet capture shows that each server Write() results in a 32KB TCP segment (Length=32768, [PSH, ACK]). Each segment is transmitted approx. 1 RTT apart (~0.158s matching Azure-advertised RTT b/w the two regions). Transmission is effectively ACK-gated.

E2E the request takes ~34s:

With kernel buffering enabled, the TCP stack transmits large bursts of packets rather than one per RTT.

E2E latency dropped from ~34s to ~1s (first request ~1.9s due to TCP slow start, subsequent requests stabilize at ~0.95s).

TCP stream graph

The diff in behavior is best visualized using the Stevens TCP stream graph:

Without kernel buffering, the graph shows each ~32 KB increment in response transmission is separated by approx. one RTT. The slope is shallow (slow rate of growth) and evenly spaced.

With kernel buffering enabled, the slope becomes significantly steeper. Multiple segments are transmitted back-to-back before the next RTT boundary.

This visualizes the core issue: without buffering, small writes are RTT-amplified. With buffering, HTTP.sys aggregates response data in kernel space and transmits in large bursts, eliminating per-write RTT pacing.

Repro code

Init HttpListener with EnableKernelResponseBuffering switch

varlistener=newHttpListener();if(enableBuffering){AppContext.SetSwitch("System.Net.HttpListener.EnableKernelResponseBuffering",true);}listener.Prefixes.Add("http://+:80/");listener.Start();while(true){varcontext=awaitlistener.GetContextAsync();try{longresponseSize=long.Parse(context.Request.QueryString["size"]);intbufferSize=int.Parse(context.Request.QueryString["buffer"]);context.Response.StatusCode=200;awaitSendListenerResponse(context,responseSize,bufferSize);}finally{context.Response.Close();}}

Server multi-write response routine

varbuf=newbyte[bufferSize];longtotalWriteUs=0;intwriteCount=0;longtotalSent=0;while(totalSent<size){intwriteSize=(int)Math.Min(size-totalSent,bufferSize);longstart=Stopwatch.GetTimestamp();awaitstream.WriteAsync(buf.AsMemory(0,writeSize));longend=Stopwatch.GetTimestamp();totalWriteUs+=(end-start)/10;writeCount++;totalSent+=writeSize;}longavgWriteUs=totalWriteUs/writeCount;

Thanks @ManickaP for all the help!

[dotnet-policy-service]

Tagging subscribers to this area: @karelz, @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[jkotas]

No public API changes

AppContext switches are de-facto public APIs, just a different kind.

[ManickaP]

One comment otherwise LGTM. I'll await the manual validation results.

Thanks!

[jkotas]

This should be documented in https://github.com/dotnet/dotnet-api-docs/blob/main/xml/System.Net/HttpListener.xml

[karimsalem1]

This should be documented in https://github.com/dotnet/dotnet-api-docs/blob/main/xml/System.Net/HttpListener.xml

Added public docs here, thank you.

[karimsalem1]

This PR adds an opt-in AppContext switch to enable kernel response buffering in HttpListener (Windows implementation only). When enabled, the flag HTTP_SEND_RESPONSE_FLAG_BUFFER_DATA is set on all calls to HttpSendHttpResponse and HttpSendResponseEntityBody (consistent with Win32 docs). This mirrors the behavior for setting the HttpSysOptions.EnableKernelResponseBuffering flag in ASP.NET HTTP.sys code.

Motivation in issue #123425.

Sample usage:

AppContext.SetSwitch("System.Net.HttpListener.EnableKernelResponseBuffering",true);usingvarlistener=newHttpListener();listener.Prefixes.Add("http://localhost:8080/");listener.Start();Console.WriteLine("Listening...");while(true){varcontext=awaitlistener.GetContextAsync().ConfigureAwait(false);_=Task.Run(()=>HandleRequestAsync(context));}

Notes:

• No public API changes
• Default behavior remains unchanged
• Since API is internal, tests use reflection to validate flag behavior.
• Added dedicated Windows-only test classes for HttpListener and HttpResponseStream, and consolidated existing Windows-only tests there for consistency.

Repro and validation

Setup:

• Client: Azure VM in West US 2
• Server: Azure VM in Australia East

Client uses HttpClient to send requests to the server and measures total latency. Server is running HttpListener and returns 7MB responses while varying the server-side response buffer size (from 32KB to 7MB). Server also records avg timing per individual response Write() call.

Benchmark

Kernel Buffering Disabled (Existing Behavior)

Buffer Size (bytes)	Latency (ms)	Write Time (µs)
32768	33911	158414
65536	16923	158108
131072	8609	159346
262144	4323	159938
524288	2296	163629
1048576	1181	168004
2097152	701	173846
4194304	468	206004
7000000	492	384459

Kernel Buffering Enabled (New Behavior)

Buffer Size (bytes)	Latency (ms)	Write Time (µs)
32768	1154	4589
65536	1149	9211
131072	1142	18205
262144	1107	35590
524288	1137	69975
1048576	686	75492
2097152	386	92539
4194304	451	109173
7000000	490	2356

• Enabling HttpListener kernel buffering reduces E2E latency by up to 30x (34s → 1s for 32KB buffers)
• Average Write() time drops significantly (158,414 µs → 4,589 µs at 32 KB).

These results confirm that without kernel buffering, small writes cause RTT amplification. Enabling kernel buffering eliminates small-write fragmentation over the wire and dramatically reduces latency.

Packet Capture

Packet analysis

Without kernel buffering, when the server sends a 7MB response using a 32KB buffer, packet capture shows that each server Write() results in a 32KB TCP segment (Length=32768, [PSH, ACK]). Each segment is transmitted approx. 1 RTT apart (~0.158s matching Azure-advertised RTT b/w the two regions). Transmission is effectively ACK-gated.

E2E the request takes ~34s:

With kernel buffering enabled, the TCP stack transmits large bursts of packets rather than one per RTT.

E2E latency dropped from ~34s to ~1s (first request ~1.9s due to TCP slow start, subsequent requests stabilize at ~0.95s).

TCP stream graph

The diff in behavior is best visualized using the Stevens TCP stream graph:

Without kernel buffering, the graph shows each ~32 KB increment in response transmission is separated by approx. one RTT. The slope is shallow (slow rate of growth) and evenly spaced.

With kernel buffering enabled, the slope becomes significantly steeper. Multiple segments are transmitted back-to-back before the next RTT boundary.

This visualizes the core issue: without buffering, small writes are RTT-amplified. With buffering, HTTP.sys aggregates response data in kernel space and transmits in large bursts, eliminating per-write RTT pacing.

Repro code

Init HttpListener with EnableKernelResponseBuffering switch

varlistener=newHttpListener();if(enableBuffering){AppContext.SetSwitch("System.Net.HttpListener.EnableKernelResponseBuffering",true);}listener.Prefixes.Add("http://+:80/");listener.Start();while(true){varcontext=awaitlistener.GetContextAsync();try{longresponseSize=long.Parse(context.Request.QueryString["size"]);intbufferSize=int.Parse(context.Request.QueryString["buffer"]);context.Response.StatusCode=200;awaitSendListenerResponse(context,responseSize,bufferSize);}finally{context.Response.Close();}}

Server multi-write response routine

varbuf=newbyte[bufferSize];longtotalWriteUs=0;intwriteCount=0;longtotalSent=0;while(totalSent<size){intwriteSize=(int)Math.Min(size-totalSent,bufferSize);longstart=Stopwatch.GetTimestamp();awaitstream.WriteAsync(buf.AsMemory(0,writeSize));longend=Stopwatch.GetTimestamp();totalWriteUs+=(end-start)/10;writeCount++;totalSent+=writeSize;}longavgWriteUs=totalWriteUs/writeCount;

Thanks @ManickaP for all the help!

[dotnet-policy-service]

Tagging subscribers to this area: @karelz, @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[jkotas]

No public API changes

AppContext switches are de-facto public APIs, just a different kind.

[ManickaP]

One comment otherwise LGTM. I'll await the manual validation results.

Thanks!

[jkotas]

This should be documented in https://github.com/dotnet/dotnet-api-docs/blob/main/xml/System.Net/HttpListener.xml

[karimsalem1]

This should be documented in https://github.com/dotnet/dotnet-api-docs/blob/main/xml/System.Net/HttpListener.xml

Added public docs here, thank you.

[karimsalem1]

This PR adds an opt-in AppContext switch to enable kernel response buffering in HttpListener (Windows implementation only). When enabled, the flag HTTP_SEND_RESPONSE_FLAG_BUFFER_DATA is set on all calls to HttpSendHttpResponse and HttpSendResponseEntityBody (consistent with Win32 docs). This mirrors the behavior for setting the HttpSysOptions.EnableKernelResponseBuffering flag in ASP.NET HTTP.sys code.

Motivation in issue #123425.

Sample usage:

AppContext.SetSwitch("System.Net.HttpListener.EnableKernelResponseBuffering",true);usingvarlistener=newHttpListener();listener.Prefixes.Add("http://localhost:8080/");listener.Start();Console.WriteLine("Listening...");while(true){varcontext=awaitlistener.GetContextAsync().ConfigureAwait(false);_=Task.Run(()=>HandleRequestAsync(context));}

Notes:

• No public API changes
• Default behavior remains unchanged
• Since API is internal, tests use reflection to validate flag behavior.
• Added dedicated Windows-only test classes for HttpListener and HttpResponseStream, and consolidated existing Windows-only tests there for consistency.

Repro and validation

Setup:

• Client: Azure VM in West US 2
• Server: Azure VM in Australia East

Client uses HttpClient to send requests to the server and measures total latency. Server is running HttpListener and returns 7MB responses while varying the server-side response buffer size (from 32KB to 7MB). Server also records avg timing per individual response Write() call.

Benchmark

Kernel Buffering Disabled (Existing Behavior)

Buffer Size (bytes)	Latency (ms)	Write Time (µs)
32768	33911	158414
65536	16923	158108
131072	8609	159346
262144	4323	159938
524288	2296	163629
1048576	1181	168004
2097152	701	173846
4194304	468	206004
7000000	492	384459

Kernel Buffering Enabled (New Behavior)

Buffer Size (bytes)	Latency (ms)	Write Time (µs)
32768	1154	4589
65536	1149	9211
131072	1142	18205
262144	1107	35590
524288	1137	69975
1048576	686	75492
2097152	386	92539
4194304	451	109173
7000000	490	2356

• Enabling HttpListener kernel buffering reduces E2E latency by up to 30x (34s → 1s for 32KB buffers)
• Average Write() time drops significantly (158,414 µs → 4,589 µs at 32 KB).

These results confirm that without kernel buffering, small writes cause RTT amplification. Enabling kernel buffering eliminates small-write fragmentation over the wire and dramatically reduces latency.

Packet Capture

Packet analysis

Without kernel buffering, when the server sends a 7MB response using a 32KB buffer, packet capture shows that each server Write() results in a 32KB TCP segment (Length=32768, [PSH, ACK]). Each segment is transmitted approx. 1 RTT apart (~0.158s matching Azure-advertised RTT b/w the two regions). Transmission is effectively ACK-gated.

E2E the request takes ~34s:

With kernel buffering enabled, the TCP stack transmits large bursts of packets rather than one per RTT.

E2E latency dropped from ~34s to ~1s (first request ~1.9s due to TCP slow start, subsequent requests stabilize at ~0.95s).

TCP stream graph

The diff in behavior is best visualized using the Stevens TCP stream graph:

Without kernel buffering, the graph shows each ~32 KB increment in response transmission is separated by approx. one RTT. The slope is shallow (slow rate of growth) and evenly spaced.

With kernel buffering enabled, the slope becomes significantly steeper. Multiple segments are transmitted back-to-back before the next RTT boundary.

This visualizes the core issue: without buffering, small writes are RTT-amplified. With buffering, HTTP.sys aggregates response data in kernel space and transmits in large bursts, eliminating per-write RTT pacing.

Repro code

Init HttpListener with EnableKernelResponseBuffering switch

varlistener=newHttpListener();if(enableBuffering){AppContext.SetSwitch("System.Net.HttpListener.EnableKernelResponseBuffering",true);}listener.Prefixes.Add("http://+:80/");listener.Start();while(true){varcontext=awaitlistener.GetContextAsync();try{longresponseSize=long.Parse(context.Request.QueryString["size"]);intbufferSize=int.Parse(context.Request.QueryString["buffer"]);context.Response.StatusCode=200;awaitSendListenerResponse(context,responseSize,bufferSize);}finally{context.Response.Close();}}

Server multi-write response routine

varbuf=newbyte[bufferSize];longtotalWriteUs=0;intwriteCount=0;longtotalSent=0;while(totalSent<size){intwriteSize=(int)Math.Min(size-totalSent,bufferSize);longstart=Stopwatch.GetTimestamp();awaitstream.WriteAsync(buf.AsMemory(0,writeSize));longend=Stopwatch.GetTimestamp();totalWriteUs+=(end-start)/10;writeCount++;totalSent+=writeSize;}longavgWriteUs=totalWriteUs/writeCount;

Thanks @ManickaP for all the help!

[dotnet-policy-service]

Tagging subscribers to this area: @karelz, @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[jkotas]

No public API changes

AppContext switches are de-facto public APIs, just a different kind.

[ManickaP]

One comment otherwise LGTM. I'll await the manual validation results.

Thanks!

[jkotas]

This should be documented in https://github.com/dotnet/dotnet-api-docs/blob/main/xml/System.Net/HttpListener.xml

[karimsalem1]

This should be documented in https://github.com/dotnet/dotnet-api-docs/blob/main/xml/System.Net/HttpListener.xml

Added public docs here, thank you.