https://docs.microsoft.com/en-us/iis/configuration/system.webserver/httpprotocol/
按照上面的链接的说明，尝试修改了一下keepalive，就可以了。改为false
<configuration>
<system.webServer>
<httpProtocol allowKeepAlive="false" />
</system.webServer>
</configuration>
https://docs.microsoft.com/en-us/iis/configuration/system.applicationhost/sites/site/limits
<system.applicationHost>
<sites>
<siteDefaults>
<limits connectionTimeout="00:02:00" />
</siteDefaults>
</sites>
</system.applicationHost>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="1073741824" />
</requestFiltering>
</security>
Optional uint attribute.
Specifies the maximum length of content in a request, in bytes.
The default value is 30000000, which is approximately 28.6MB.
keepalive
使用wireshark抓包
https://support.quest.com/appassure/kb/118165
Here are a few items that may indicate a networking issue:
TCP Dup ACK (tcp.analysis.duplicate_ack)
https://ask.wireshark.org/questions/39043/1500-duplicate-acks-before-retransmission
Looks like classic buffer bloating to me. The problem appears when you send large amounts of data from a high speed network to a lesser speed network real fast, causing the switch or router buffers to fill up. At that point, packet loss will occur, and the receiver will send duplicate ACKs to notify the sender of the missing segment(s).
The problem is: since the full buffer is still constantly slammed with more packets the retransmission can't get through fast but has to "get in line" like all the other packets, which means that it takes a long time to get to the receiver. That's the reason why you see very high numbers of duplicate ACKs for the same missing segment.
The only thing you can do is to have the receiver advertise a smaller receive window, to prevent overloading the network.
A packet is duplicated somewhere on the network and received twice at the receiving host.
It is very often not desireable to get these duplicates, as the receiving application might think that's "fresh" data (which it isn't).
If a sending host thinks a packet is not transmitted correctly because of a PacketLoss, it might Retransmit that packet.
The receiving host might already got the first packet, and will receive a second one, which is a duplicated packet.
- If the Duplicate ACK count is very low (Ex: TCP Dup ACK #1), this may indicate an Out-of-Order packet.
- If the Duplicate ACK count is high, this typically indicates packet loss.
TCP Out-of-order packets (tcp.analysis.out_of_order)
Indicate that the packet was received out of sequence.
This means that the packet will be held in the buffer of the receiver until the proper packets to complete the sequence are received.
Once received then the sequence can be committed.
The more out of order packets that occur the more likely the buffer will fill up.
When the buffer is full, the receiver will then start dropping the out of order packets.
When it does that it will have to start requesting retransmission of those packets.
This process increases the chances for timeouts of the data streams and failures of replication.
TCP retransmissions (tcp.analysis.retransmission)
Indicate that there is a packet that is incomplete, out of order, corrupt, timed out or lost.
When seen with many TCP Out-of-order packets it can indicate that the problem is being caused by the flow of the packets and the fact that they are not coming through in sequence.
TCP Spurious retransmissions (tcp.analysis.spurious_retransmission)
TLS Version
https://blogs.perficient.com/microsoft/2016/04/tsl-1-2-and-net-support/
https://docs.microsoft.com/en-us/dotnet/api/system.net.servicepointmanager?view=netframework-4.7
Example
.net remoting中遇到的问题
Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host.
Server stack trace:
at System.Net.Sockets.NetworkStream.Write(Byte[] buffer, Int32 offset, Int32 size)
at System.Net.ConnectStream.InternalWrite(Boolean async, Byte[] buffer, Int32 offset, Int32 size, AsyncCallback callback, Object state)
at System.Net.ConnectStream.Write(Byte[] buffer, Int32 offset, Int32 size)
at System.Runtime.Remoting.Channels.ChunkedMemoryStream.WriteTo(Stream stream)
at System.Runtime.Remoting.Channels.Http.HttpClientTransportSink.ProcessAndSend(IMessage msg, ITransportHeaders headers, Stream inputStream)
at System.Runtime.Remoting.Channels.Http.HttpClientTransportSink.ProcessMessage(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream, ITransportHeaders& responseHeaders, Stream& responseStream)
at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage(IMessage msg)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at LISA.ControlPanelBLL.Entities.IProgramManager.UpdateTransactionGroup(Int32 userid, String connString, TransactionGroup transactionGroup, String& _message)
at LISA.ControlPanelBLL.TransactionGroup.UpdateRow()
at LISA.ControlPanel.UserControls.Transaction.TransactionGroupListControl.btnWorkflow_Click(Object sender, EventArgs e)
at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
at System.Windows.Forms.ToolStripButton.OnClick(EventArgs e)
at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ToolStrip.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
https://stackoverflow.com/questions/2582036/an-existing-connection-was-forcibly-closed-by-the-remote-host
This generally means that the remote side closed the connection (usually by sending a TCP/IP RST packet). If you're working with a third-party application, the likely causes are:
- You are sending malformed data to the application
- The network link between the client and server is going down for some reason
- You have triggered a bug in the third-party application that caused it to crash
- The third-party application has exhausted system resources
It's likely that the first case is what's happening.
You can fire up Wireshark to see exactly what is happening on the wire to narrow down the problem.
Without more specific information, it's unlikely that anyone here can really help you much.
使用wireshark抓取到两次RST
