【初探】关于TCP的十九个问题

日期：2016.05.26

作者：i.sshe

https://github.com/isshe

TCP: 传输控制协议

1. 相关问题：

1.1 什么是TCP？

1.2 什么是字节流服务?

1.3 TCP的最大报文段长度是多少？为什么是这个值？

1.4 TCP和UDP的区别是什么？

1.5 TCP通过什么方式来提供可靠性？

1.6 TCP收到数据后，为什么要推迟几分之一秒后才发确认？

1.7 TCP头部数据格式是怎样的？都有哪些内容，各有什么用处？

1.8 一个TCP连接是如何建立的？

1.9 一个TCP连接是如何终止的？

1.10 TCP连接终止过程中，TIME_WAIT状态的时间为何要设置为2MSL(报文段最大生存时间)？

1.11 TCP连接都有哪些状态，它们是如何转换的？

1.12 在TCP客户端主动建立连接的过程中，如果第三次握手的确认包丢失，有何结果？如果在并发中，大量出现此情况，对服务器会产生什么影响？

1.13 什么是滑动窗口？工作原理？

1.14 nagle算法是什么？有什么作用？

1.15 什么是慢启动？

1.16 什么时候会发生拥塞？

1.17 什么是快速重传算法？什么是快速恢复算法？

1.18 什么是keepalive？优缺点是什么？

1.19 许多ACK同时到达发送方，可能会发生什么情况？

　　发送方多次收到相同ACK呢？

什么是socket？socket ＝ IP + port;

解答:

1.1 什么是TCP？

　TCP: Transmission Control Protocol 传输控制协议. 提供面向连接的，可靠的字节流服务．

　

1.2 什么是字节流服务?

　两个应用程序通过TCP连接交换字节(8bit = 1byte)构成的不带标识符的字节流．例如：Ａ先传10byte, 20byte, 30byte, B接收的时候可以一次60byte，也可以每次20byte三次接收．

1.3 TCP的最大报文段长度是多少？为什么是这个值？

　由MSS（最大段长度）决定，而MSS由双方协商决定．

　

1.4 TCP和UDP的区别是什么？

　面向连接－面向无连接

　可靠－不可靠

　慢－快

　

1.5 TCP通过什么方式来提供可靠性？

　概括为：超时重传，错误重传，重复丢弃，流量控制．

　1). TCP分割数据为最适合发送的数据块．

　2). TCP发送一个数据段后，启动一个定时器，超时不确认，则重传（超时重传）．

　3). TCP接收到数据后，推迟几分之一秒发送确认．（为什么, 见1.6）

　4). 保持首部和数据的检验和，有错丢弃，不发送确认，等待重发．(错误重发)

　5). 接收的数据可能失序，有必要时，TCP可排序后再交给应用层．

　6). TCP会丢弃重复数据．

　7). TCP可提供流量控制．

1.6 TCP收到数据后，为什么要推迟几分之一秒后才发确认（ACK）？

　一般是最长推迟时间是200ms, 目的是等待看是否有数据要发送，有的话ACK可以捎带发送．

　

1.7 TCP头部数据格式是怎样的？都有哪些内容，各有什么用处？

　


　

　一般首部长度为20byte, 选项最长为40byte, 故首部最长为60byte.

　URG: 紧急指针有效．

　ACK: 确认序号有效．

　PSH: 尽快交给应用层．

　RST: 重建连接．

　SYN: 同步序号，用以发起连接．

　FIN: 结束序号，发端完成发送任务．

　紧急指针(Urgent Pointer): 一个正的偏移量，该偏移量和TCP首部中序号(紧急数据开始字节)字段相加，得到紧急数据的最后一个字节的序号.

　选项：常见有MSS…(补充．．．)

　

1.8 一个TCP连接是如何建立的？

　1. 客户端发送：目的端口+自己序号+SYN(置１)

　2. 服务器应答：自己序号+客户序号加1+SYN(置1) + ACK(置1)

　3. 客户端应答：服务序号加1＋ACK(置1)

1.9 一个TCP连接是如何终止的？

　

1.10 TCP连接终止过程中，TIME_WAIT状态的时间为何要设置为2MSL(报文段最大生存时间)？

　当TCP执行主动关闭，发送最后一个ACK的时候，必须保持TIME_WAIT状态2MSL的时间．

　原因：防止这个ACK丢失．（如果丢失，另一端会重发FIN）

　MSL：报文段最大生存时间．

　

1.11 TCP连接都有哪些状态，它们是如何转换的？

　


　

1.12 在TCP 客户端主动建立连接的过程中，如果第三次握手的确认包丢失，有何结果？如果在并发中，大量出现此情况，对服务器会产生什么影响？

　Client此时是ESTABLISHED（连接建立）状态，Server是SEND_RCVD状态．

Server会重发数据包，时间间隔取整后为：1, 3, 6, 12, 48, 多个64.这个关系称为＂指数退避＂．若指定次数重发后都没有收到ACK, 则Server关闭此连接．

但是Client认为这个连接已经建立，如果Client向Server写数据，Server将以RST(重建连接)包响应．

大量出现此情况会对服务器有何影响呢？不懂！大量消耗服务器资源？

1.13 什么是滑动窗口？工作原理？

　滑动窗口实质是一块缓存．



　接收方：通告窗口．

　发送方：提供端口(offerd window)．［拥塞窗口］

　通信时，双方协商提供窗口大小．接收方提供的窗口大小通常由接收进程控制，接收缓存大小是通告窗口的最大大小．可修改插口(socket)缓存大小提高TCP性能．



　窗口合拢：发生在发送端数据被发送并确认时；

　窗口张开：发生在接收端读取已经确认的数据并释放了TCP的接收缓存时．（和合拢一样？发生在发送端数据被发送并确认时？这里不够理解）

　窗口收缩：（）．

1.14 nagle算法是什么？有什么作用？

　作用：该算法主要用于避免过多小分节报文在网络中传输，从而降低网络容量利用率，增加拥塞出现的可能．

　

　tcp_output.c文件中关于nagle算法的注释：

/* Return 0, if packet can be sent now without violation Nagle's rules:
* 1. It is full sized.
* 2. Or it contains FIN. (already checked by caller)
* 3. Or TCP_NODELAY was set.
* 4. Or TCP_CORK is not set, and all sent packets are ACKed.
*    With Minshall's modification: all sent small packets are ACKed.
*/

　中文：

1. 如果包长度达到MSS，则允许发送；
2. 如果该包含有FIN，则允许发送；
3. 设置了TCP_NODELAY选项，则允许发送；
4. 未设置TCP_CORK选项时，若所有发出去的小数据包（包长度小于MSS）均被确认，则允许发送；
5. 上述条件都未满足，但发生了超时（一般为200ms），则立即发送。

Nagle算法要求一个TCP连接上最多只能有一个未被确认的未完成的小分组，在该分组的确认到达之前不能发送其他的小分组。(TCP/IP详解卷1, P203)

［Nagle算法的详细介绍见<＜TCP/IP详解卷1：协议＞>，P203］

1.15 什么是慢启动？

　慢启动 (slow start)算法通过观察到新分组进入网络的速率应该与另一端返回确认的速率相同而进行工作。

　慢启动为发送方的 TCP增加了另一个窗口:拥塞窗口 (congestion window),记为cwnd。

　发送方取拥塞窗口与通告窗口中的最小值作为发送上限。

　拥塞窗口是发送方使用的流量控制,而通告窗口则是接收方使用的流量控制。

　

1.16 什么时候会发生拥塞？

　1). 当数据从大的管道向较小的管道发送数据时．（如数据从快速局域网发往较慢的局域网时）

　2). 当路由器的输入流大于输出流总和时．

1.17 什么是快速重传算法？什么是快速恢复算法？

　快速重传算法：当收到>=3个重复的ACK时，很有可能是报文段丢失了，此时TCP重传该报文段，不需等到超时定时器溢出．这种情况称为快速重传．

　快速恢复算法：以上情况发生后，启动的是拥塞避免算法（而不是慢启动算法），此称为快速恢复算法．（因为慢启动又从拥塞窗口１开始）

　慢启动和拥塞避免的可视化描述：

　


　快速恢复算法通常按如下过程进行实现:（摘自<＜TCP/IP详解＞>）

　　1). 当收到第 3个重复的ACK时,将ssthresh(慢启动门限)设置为当前拥塞窗口cwnd的一半。重传丢失的报文段。设置cwnd为ssthresh加上3倍的报文段大小。

　　2). 每次收到另一个重复的 ACK时, cwnd增加 1个报文段大小并发送 1个分组(如果新的cwnd允许发送)。

　　3). 当下一个确认新数据的 ACK到达时,设置cwnd为ssthresh(在第1步中设置的值)。这个ACK应该是在进行重传后的一个往返时间内对步骤 1中重传的确认。另外,这个 ACK也应该是对丢失的分组和收到的第 1个重复的ACK之间的所有中间报文段的确认。这一步采用的是拥塞避免,因为当分组丢失时我们将当前的速率减半。

　　

1.18 什么是keepalive？优缺点是什么？

　keepalive功能主要是为服务器应用程序提供的，服务器应用程序可能代表客户绑定一些资源，因此希望知道客户主机是否崩溃．

　keepalive试图在服务器端监测半开放的连接．（客户消失(关电源)，连接没有关闭，服务器还在等待数据．）

　客户主机有一下四种状态：

　　1). 客户主机依然正常运行,并从服务器可达。

　　2). 客户主机已经崩溃,并且关闭或者正在重新启动。（服务器发送10个75秒的探查，都没有确认则关闭连接）

　　3). 客户主机崩溃并已经重新启动。（探活的确认是RST(复位)，使服务器终止连接）

　　4). 客户主机正常运行,但是从服务器不可达。(TCP无法区分状态２和４)

　keepalive功能的优点：

　　1). 通常激活keepalive选项比显式地编写应用程序探测报文更容易;

　　2). keepalive探测报文比应用程序探测报文占用更少的网络带宽(因为keepalive探测报文和应答不包含任何数据);

　　3). 如果连接不是空闲的,就不会发送探测报文。

　keepalive功能的缺点：

　　1). keepalive选项可能会由于一个临时性的网络中断而引起一个非常好的连接断开;

　　2). 发送探测报文的间隔( 2小时)一般不可以根据应用程序进行配置。

　　

1.19 许多ACK同时到达发送方，可能会发生什么情况？

　　发送方多次收到相同ACK呢？

1). 这可能引起发送者以比网络实际能够处理的更快的速率向网络发送分组。

　这叫作确认压缩(ACK compression)或确认粉碎 (ACK smashing) ，它很少会导致拥塞.

2). 参考问题17.

参考资料：

　<＜TCP/IP详解 卷1: 协议＞>