这个系列主要学习TCP协议，主要以阅读TCP/IP Illustrated, Volume 1 (2nd Edition)和TCP/IP详解 卷1：协议为主，并结合一些网上的资料。

这章标题为：TCP: The Transmission Control Protocol (Preliminaries)，主要是介绍一些TCP协议要解决的问题，以及大致的设计思路。具体的技术细节要在之后的章节进行详细的阐述。

简单设计一个协议

TCP协议下层的协议都不是“可靠”的，它们不保证传输的可靠性。所以要建立一个可靠地传输协议需要克服一下几个问题：

1. 包内部的数据错误(packet bit errrors)。在传输的过程中有可能导致传输的数据中的bit有错误。
2. 丢包(packet erasure)
3. 包的顺序不对(packet reordering)。
4. 重复的包(packet duplication)。

解决1和2可以用重传的机制，发送端发送包给接收端，接收端接收到以后确认没有错误返回一个确认信息（ACK/acknowledge）。如果发送端没有及时收到确认信息，则重传直到收到确认信息。

解决3和4可以假如序列号（sequence number），这样接收端就可以直到收到的包的顺序和是否重复。

上面的两个简单地解决方案可以解决我们提到的四个问题。但是这个方案本身还有一些悬而未决和不足的地方：

1. 发送端应该等待多久才认为是超时了？（这个问题比较复杂，会在十四章详述）
2. 如果接收端发出来的ACK信息丢失了怎么办？（可以归类为第一个问题）
3. 如果接收端收到包但是有错误怎么处理？（假如checksum校验，如果发现有错误则不确认，即可归类为第一个问题）
4. 这个方案只能一个一个包发送，大部分情况下发送端处于空闲状态，效率低下。（下面会引入窗口概念）

窗口和滑动

解决上述方案中的第四个问题，我们可以引入一个窗口的概念。一次不是只发送一个包，而是发送一组包。可以想象成一个窗口，当前面发送的包已经被确认以后，则可以将窗口往下进行滑动去发送更多的包。窗口的基本意思可以看书上的插图，比较直观。

可以看到窗口的大小会直接影响到同时发出多少个包，这个大小的设置就直接影响到了接收端和中途的网络设备。如果太大的话可能会导致接收端无法处理，也可能导致中途的网络设备无法处理造成丢包，从而影响发送效率。太小的话则无法很好地充分利用网络资源和接收端的资源。

这里会引入两个概念。流量控制（flow control）和阻塞控制（congestion control）。

接收端可以根据自己的情况告诉发送端自己合适的窗口大小是多少，一般通过ACK包一起发送回去。这个属于流量控制，又称显式控制（explicit signaling）。

网络设备的拥堵情况则没有办法通过显式的控制，而是需要通过一些算法来计算出来一个比较合适的窗口大小。这个可以称为隐式控制（implicit signaling）。这个会在十五章里面详细讨论。

如何设置超时？

对于每一个包的传输时间（round-trip-time），即从发送到收到确认的时间，我们可以知道。我们能通过一些统计来估算出一个大概的时间当做超时。很显然平均值不是一个很好的选择，因为如果用平均值的话可能会有很多请求直接被超时了。如何设置超时也是一个需要深入讨论的问题，会在十四章中进行讨论。

介绍TCP

TCP协议是一个面向连接（connection-oriented）的协议，这个意思是两个应用必须先建立连接，然后才能进行通行。

TCP是一个可靠的协议，它具备以下几个特点确保其其可靠性：

• 强制checksum校验，保证数据传输是对的。如果传输的数据块太大则需要引入其他的中间层来保证。
• 有timer来保证超时会重发。
• 有ACK来保证接收端确认收到包。并且ACK的确认是累加性的，如果接收端收到了x+2 返送了ACK x+3，但ACK x+3丢了。下次接收端接收到x+3的时候会返回ACK x+4，这样就可以避免x+2重传。
• TCP有序列号来解决乱序和重复包的问题。
• TCP为全双工，两边都可以进行传输。

TCP头部和封装

插两张图

图中可以看到有8个比特位用来控制TCP的一些flag，用于不同的请求。可能会多于一个比特位被置成1。