Documentation_networking_tcp-thin

Chinese translated version of Documentation/networking/tcp-thin


If you have any comment or update to the content, please contact the
original document maintainer directly.  However, if you have a problem
communicating in English you can also ask the Chinese maintainer for
help.  Contact the Chinese maintainer if this translation is outdated
or if there is a problem with the translation.


Chinese maintainer: [e-mail]
---------------------------------------------------------------------
Documentation/networking/tcp-thin 的中文翻译


如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
译存在问题，请联系中文版维护者。


中文版维护者： 潘丽卡  [e-mail]
中文版翻译者： 潘丽卡  [e-mail]
中文版校译者： 黄佳露  [e-mail]








以下为正文
---------------------------------------------------------------------




Thin-streams and TCP
薄流和TCP


====================
A wide range of Internet-based services that use reliable transport
protocols display what we call thin-stream properties. This means
that the application sends data with such a low rate that the
retransmission mechanisms of the transport protocol are not fully
effective. In time-dependent scenarios (like online games, control
systems, stock trading etc.) where the user experience depends
on the data delivery latency, packet loss can be devastating for
the service quality. Extreme latencies are caused by TCP's
dependency on the arrival of new data from the application to trigger
retransmissions effectively through fast retransmit instead of
waiting for long timeouts.


广泛的基于互联网的服务，使用可靠的传输
协议显示，也就是我们所说的细流性能。这意味着应用程序用这样低的速度
发送数据，传输协议的重传机制不完全有效的。在随时间变化的情况下
（如在线游戏，控制系统，股票交易等）的用户体验取决于在数据传输延迟，
丢包可能导致服务质量的毁灭。极端的延迟所造成的TCP依赖于从应用程序
触发的新的数据到来可以有效地通过快速重传，而不是重发等待很长的超时。




After analysing a large number of time-dependent interactive
applications, we have seen that they often produce thin streams
and also stay with this traffic pattern throughout its entire
lifespan. The combination of time-dependency and the fact that the
streams provoke high latencies when using TCP is unfortunate.


在分析了大量的随着时间变化的互动式
应用中，我们已经看到，他们往往会产生细流
并且还在其整个存在时间留在这个流通量模式。
不幸的是，时间依赖性和细流的组合会在使用TCP时的引起高延迟。


In order to reduce application-layer latency when packets are lost,
a set of mechanisms has been made, which address these latency issues
for thin streams. In short, if the kernel detects a thin stream,
the retransmission mechanisms are modified in the following manner:


为了减少应用层数据包丢失时的延迟，
已提出一套机制来解决这些细流的延迟问题
。总之，如果内核检测到了细流
那么重发机制将可以以下列方式被修改：




1) If the stream is thin, fast retransmit on the first dupACK.
2) If the stream is thin, do not apply exponential backoff.


1）如果流是薄的，快速重传第一dupACK上。
2）如果流是薄的，不适用指数退避。


These enhancements are applied only if the stream is detected as
thin. This is accomplished by defining a threshold for the number
of packets in flight. If there are less than 4 packets in flight,
fast retransmissions can not be triggered, and the stream is prone
to experience high retransmission latencies.


这些增强功能仅能应用当检测到流是细的薄的。这是通过给飞行中的数据包
定义一个阈值的数量。如果有少于4个数据包在飞行中，
快速重传不能被触发，并且该流很容易引起高重传延迟。




Since these mechanisms are targeted at time-dependent applications,
they must be specifically activated by the application using the
TCP_THIN_LINEAR_TIMEOUTS and TCP_THIN_DUPACK IOCTLS or the
tcp_thin_linear_timeouts and tcp_thin_dupack sysctls. Both
modifications are turned off by default.


由于这些机制必须针对时间相关的应用程序，
他们必须在使用TCP_THIN_LINEAR_TIMEOUTS和TCP_THIN_DUPACK IOCTLS或者
tcp_thin_linear_timeouts和tcp_thin_dupack的sysctl的时候被激活。
两种修改都在默认情况下被关闭。


References
参考文献
==========


More information on the modifications, as well as a wide range of
experimental data can be found here:
"Improving latency for interactive, thin-stream applications over
reliable transport"


更多有关于修改的信息，以及广泛的实验数据可以在这里找到：
“提高互动，可靠的运输上超薄流的应用程序的延迟
http://simula.no/research/nd/publications/Simula.nd.477/simula_pdf_file