现在我们来介绍一下TCP协议的运行问题，因为我们对TCP协议实际上是什么样子知道的并不多。
上个星期介绍TCP协议时曾许诺本文将更详细地讲解TCP协议。现在我们来介绍一下TCP协议的运行问题，因为我们对TCP协议实际上是什么样子知道的并不多。
我们说过，TCP协议在能够发送数据之前就建立起了“连接”。要实现这个连接，启动TCP连接的那一方首先将发送一个SYN(回忆一下在上一篇文章中讲到的TCP包头格式)数据包。这只是一个不包含数据的数据包，然后，打开SYN标记。如果另一方同时在它收到SYN标记的端口通话，它将发回一个SYN+ACK:SYN和ACK标志位都被打开，并将ACK(确认)编号字段设定为刚收到的那个数据包的顺序号字段的值。接下来，连接发起方为了表示收到了这个SYN+ACK信息，会向发送方发送一个最终的确认信息(ACK包)。这种SYN、SYN+ACK、ACK的步骤被称为TCP连接建立时的“三次握手”。在这之后，连接就建立起来了。这个连接将一直保持活动状态，直到超时或者任何一方发出一个FIN(结束)信号。
任何一方都可以关闭一个TCP连接，要求双方发送一个FIN信号关闭自己的通讯频道。一方可以在另一方之前关闭，或者双方同时关闭TCP连接。因此，当一方发送一个FIN信号时，另一方可发送“FIN+ACK”，开始关闭自己一方的通信并且确认收到了第一个FIN信号。发送第一个FIN信号的人接下来再发送一个“FIN+ACK”信息，确认收到第二个FIN信号。另一方就知道这个连接已经关闭了，并且关闭了自己的连接。发送第一个FIN的人没有办法收到最后一个ACK信号的确认信息。这时它会进入“TIME_WAIT”(等待时间)状态并启动一个定时器，防止另一方没有收到ACK信息并且认为连接仍是打开的。一般来说，这个状态会持续1至2分钟。
现在，我们来讨论第一个问题。如果有人(假如一个
黑客)在你的
web服务器上留下一个半开或者半关的连接，那就是一个坏消息。每一个连接都要消耗
内存，打开数千个虚假的TCP连接可能导致服务器瘫痪。当然，你实际上不可能在不影响TCP正常工作的情况下调整TCP定时器。如果你听说过TCPSYN攻击的话，那就是这个意思。为了防止出现这种情况，大多数操作系统都要限制半开连接的数量。例如，Linux默认的限制一般是256个。
我们前面提过将讨论关于持续流控制问题，现在我们就来讨论这个问题。TCP中实现它的机制是TCP滑动窗口机制。TCP协议使用“重新发送与正向ACK”来保证数据传输的可靠性。发送方将等待一段时间，如果没有收到其发送的数据包的ACK确认信息，发送方就要重新发送。顺便说一下，TCP协议中有许多定时器。这只是其中一个定时器。ACK的概念对于流控制是非常重要的，因为TCP滑动窗口协议使TCP的往复确认变得更有效率。如果TCP要发送一个数据包并且等待每一个ACK确认信息，它实际上就把数据吞吐量削减了一半。
理想的情况是，我们能够一次发送许多数据包，然后等待收到一个确认收到全部数据包的ACK信息，而不用对方发来更多的数据。但是，我们如何知道发送了多少个数据包呢?TCP窗口尺寸可以控制在“已发送但是没有确认”的状态下能够容纳多少个数据包。如果这个窗口尺寸很大，我们不必等待ACK信息就可以发送大量的数据包。这实际上就是流控制。
接收方就是控制窗口大小的那一方。如果接收方将窗口大小设为“0”，那么，发送方根本就不能发送任何数据。如果这个窗口的尺寸是“1”，那么，我们就回到了简单的“发送和等待ACK”的协议。如果最后的窗口尺寸是“0”，发送者将发出一个探测信号以搞清这个窗口什么时间再次打开。如果发送方从来没有收到ACK信息，它就一直不断地重试，直到定时器过期。请记住，这个窗口尺寸在TCP头中是一个16位字
