“教你怎么简化Server”

今天我们来谈谈教你如何简化服务器的文案。 这里简要介绍一下服务器的简化方法。 希望能帮到大家。

windowsserver是一个可靠的平台，具有可靠性、可用性、可扩展性和安全性。 由于操作简单，使用浏览器签入文件已成为广泛接受的文件传输方法。 这种方式虽然被广泛接受，但并不保证没有错误。 被确认的微软IIS的问题之一是在解决48k以上的进站文件时发生超时报告错误。 这可能是短暂的植入失败，但在其他情况下，浏览器将进入一个不断尝试重新发送数据的死循环。 因为浏览器没有对这种特定情况的标准响应。

造成此锁定的原因是iis采用了类似于asp的应用程序来解决客户端数据的签入。 当客户端开始提交数据时，iis会将最初的48k数据导入缓冲区，然后将其传播到应用程序中进行解决。 超过48k的数据将等待应用程序请求传输，通常通过命令(如request.binaryread ( request.total bytes ) )执行。 如果应用程序没有请求，这些数据将处于等待连接的状态。 这是典型的413错误。 请求实体太大。

一般来说，按照上述规则正确编码可以避免这些问题，但可能需要特定的属性设置。 例如，如果一个站点的入口由第三方isapi扩展解决，并且不遵守该方法，则需要进行一些调整以克服48k的限制。 这个限制不固定。 由名为uploadreadaheadsize的iis元数据( metabase )属性定义。 默认值为49152k，最多可设定为4gb。 如果需要，可以设置单独的站点，也可以设置整个iis服务。

这可能不是唯一需要设置的属性。 也可以修改maxrequestlength(IIS6)或maxallowedcontentlength )的属性值，以允许签入大数据，尽管默认值很大。

在某些情况下，将uploadreadaheadsize的值设置为零很有用。 这将强制iis将提交的副本直接传递到isapi扩展应用程序以解决请求。 这可能是处理这个问题时首先值得尝试的方法，但也需要观察关闭iis应用程序(不解决预读缓冲区)带来的副作用。

最后，请注意，增加uploadreadaheadsize的值会导致攻击面。 如果有人将此值设置得很高，并试图以通过签入文件来消耗带宽的方式攻击系统，那么就很容易获得。 为了不攻击，要反映客户实际采用的值，尽量反复采用认证方法，确保入驻者的身份是可靠的。

我相信通过教你如何简化server这个副本会对你有帮助。 和好朋友分享的时候，也欢迎感兴趣的朋友们一起探讨。

本文：《“教你怎么简化Server”》