计算机网络——TCP协议相关知识总结

TCP协议相关知识总结

前言

TCP这块内容还真是挺多的，计科专业暂时没有学过计网，提前学学这块内容还是比较吃力的。
如有谬误，请各位大佬指正。

概述

TCP即Transmission Control Protocol，译为传输控制协议。它是传输层的一个重要协议，应用层的HTTP协议正是基于TCP来进行通信的。

特点

优点：可靠、面向连接、面向字节流、双向同时通信

缺点：效率较低

TCP头部

建立和断开TCP连接时，通信双方都是通过TCP报文来交换数据的；而了接TCP头部字段是下面学习TCP建立和断开连接的基础。

TCP报文由TCP头部和数据部分组成，但在TCP建立和断开连接时，交换的报文段只有头部，没有数据部分。

重要字段：

• Sequence number（序列号）：报文段数据中的第一个字节的序号
• Acknowledge number（确认号，下面简写为Ack）：假设确认号为N，则表示该确认号的发送方期待接收的下一个序列号为N，同时表示N-1及之前的报文都已成功收到
• SYN（同步位）：在建立连接的过程中用于同步序号
• FIN（终止位）：断开TCP连接时使用
• RST（重置位）
• Data offset（数据偏移）：最小为4个字节，而Options是根据需要增加的字段，所以TCP头部最小长度为20字节，在图上左侧边栏也有说明。

TCP建立连接的过程

这个过程我们一般形象地称为“三次握手”。（下图中ACK表示Acknowledge number，下面三次握手中均称为Ack）

建立TCP连接的过程如图中上1/3的部分所示

• 第一次握手：

  客户端发送TCP请求报文，其中同步位SYN设置为1，序列号seq为x（x是一个随机起始序号）。发送后客户端进入SYN_SENT状态，等待服务端确认

• 第二次握手：

  服务端收到客户端的SYN报文段，确认后发送一个确认报文。

  其中：Ack为x+1，SYN为1，seq为y（也是一个随机起始序号）。发送后服务器进入SYN_RCVD状态。

• 第三次握手：

  客户端收到确认报文，向服务器发送连接Ack报文。其中：Ack为y+1。发送后，双方都进入ESTABLISHED状态，TCP连接建立完成。

说明：

• 其中第一次和第二次握手时，因为SYN同步位为1，不能携带数据；第三次握手可以携带数据。
• 三次握手时，任何一次未收到对方的回复报文就会进行重发。

为什么需要三次握手

主要是防止服务器因为接收到了失效的客户端请求报文，导致服务器一直等待客户端而造成资源浪费。

一次、两次握手，服务器都只收到了一次请求报文，都无法证明客户端真正想要进行请求；因此需要在前两次的基础上增加第三次握手，让客户端确认需要请求服务器，这样就解决了服务器可能一直等待客户端的情况了。

断开连接的过程

我们一般称此过程为“四次挥手”。

断开TCP连接的过程如图中下面1/3的部分所示。

• 第一次挥手：

  客户端发送断开连接的请求报文。其中：FIN终止位为1。同时客户端进入FIN_WAIT_1状态。

• 第二次挥手：

  服务端收到了客户端的FIN报文，向服务端回复了一个Ack报文段（其中：Ack的值为收到报文中seq的值+1），确认收到客户端断开连接的请求。

• 第三次挥手：

  服务端向客户端发送FIN报文请求关闭连接，同时服务端进入LAST_ACK状态。

• 第四次挥手：

  客户端收到服务端的FIN报文后，向服务端发送Ack报文（其中：Ack的值为收到报文中seq的值+1），同时客户端进入TIME_WAIT状态。

  服务端收到客户端的Ack报文后关闭连接（进入CLOSED状态）。然后客户端等待2MSL（Maximum Segment Lifetime，最大报文段生存时间）后依然没有收到回复，则说明服务端正常关闭连接，客户端也关闭连接（同样进入CLOSED状态）。

为什么断开连接需要四次挥手

这样是为了保证在关闭连接前，客户端和服务端数据均发送完毕，都没有数据再发送给对方。

第一次挥手表明客户端已经没有数据发送给服务端了。第二次挥手仅仅说明服务端收到了客户端的报文，但服务端可能还有数据要发送给客户端，此后到第三次挥手期间，服务端可能还会发送给客户端一些数据。第三次挥手表明服务端也没有数据发送给客户端了，后面双方就可以断开连接。

也就是说，不将第二次和第三次挥手过程合并到一次就是因为服务端可能还会有数据发送给客户端，这就是我比较困惑的一点的原因。

为什么客户端关闭连接前要等待2MSL的时间

1.为了保证客户端发送的最后1个连接释放确认报文能到达服务器，从而使得服务器能正常释放连接。

如果客户端在第四次握手后直接断开连接并且此时客户端的Ack报文丢失，服务端会向客户端重新发送FIN报文，而客户端已经关闭连接，不会理会服务端，这就会导致服务端无法关闭连接。

2.防止已失效的连接请求报文出现在本次连接中。
客户端发送了最后1个连接释放请求确认报文后，再经过2MSL时间，则可使本连接持续时间内所产生的所有报文段都从网络中消失。

TCP可靠传输

TCP发送的报文段是交给IP层传输的，但TCP下面提供的是不可靠的传输。因此TCP需要采用一些方法来让通信变得可靠，以达到理想传输的条件：

• 传输信道不发生错误
• 不管发送方以多快的速度发送数据，接收方总能来得及处理收到的数据

TCP通过以下方法来保证数据传输的可靠：

• 数据校验
• 数据合理分片和排序
• 确认和重传
• 流量控制
• 拥塞控制

1.数据校验

TCP报文头有校验和，接收方可以用来校验报文是否有差错，有的话会将其丢弃。

2.数据合理分片和排序

MSS（最大分段大小），是TCP里的一个概念（首部的选项字段中）。MSS是TCP数据包每次能够传输的最大数据分段，TCP报文段的长度大于MSS时，要进行分段传输。

TCP会按MTU（最大传输单元，是链路层中的网络对数据帧的一个限制）合理分片，接收方会缓存未按序到达的数据，重新排序后再交给应用层。

3.确认和重传

接收方收到请求方的报文后会进行确认；发送方一段时间后没有收到接收方的回复就会进行超时重传（解决了丢包问题）。

为了实现超时重传，就要在每发送完一个报文段后设置一个超时计时器，在计时超时前收到对方确认就撤销已设置的超时计时器。

超时计时器有下列四种：

• 重传计时器：在超时重传过程使用的计时器。
• 持续计时器：使窗口大小信息保持不断流动。避免使用滑动窗口传输数据时发生死锁。
• 保活计时器：检测空闲连接的另一端是否崩溃或重启，在保持TCP连接时使用。
• 2MSL计时器：测量一个连接处于TIME_WAIT状态的时间，在断开TCP连接时使用。

滑动窗口协议

TCP的滑动窗口是以字节为单位的流水线传输协议。它的目的主要是为了提高数据传输的效率。

在使用停止等待协议时，发送方发送一个数据段（分组）后需要等待接收方发来确认才能发送下一个数据段，这样信道利用率太低。因此提出了滑动窗口协议来提高传输效率，让发送方不必发完一个分组就停下来等待对方确认。

图一

图二：接收方确认收到31~33的数据帧：

原理概述

发送方和接收方分别维护一个发送窗口和接收窗口。

发送窗口：

发送窗口可以对发送方进行流量控制

• 在没有收到接收方确认的情况下，发送方可以连续把窗口范围内的数据都发送出去。已发送的数据在没有收到确认前都必须暂时保留，以便在超时重传时使用。
• 每接收到一个确认帧，发送窗口整体向前（也就是图中向右）移动一帧；当发送方窗口范围内的数据帧全部发送但还未收到确认时，发送方就会等待，直到接收方发来确认，窗口继续向右滑动。

接收窗口：

• 在收到数据帧后，回复发送方一个确认信息，表明之前的数据已经成功接收。发送到窗口范围外的数据帧会全部丢弃。
• 如果未按照顺序收到数据帧（如图一所示），会暂存在接受窗口中，但接收方给发送方的确认报文段中的确认号Ack仍是31。

ARQ协议

ARQ（Auto Repeat Request，自动重传请求），用来解决TCP传输过程中出现差错的问题。

顾名思义，一旦TCP传输过程中出现差错，发送方会重新传输相关的数据。

停等式ARQ

发送接收方每发送一帧。发送方等到接收方的应答信号后才能发送下一帧；若发送方没有收到应答信号则必须一直等待

后退N帧ARQ

接受窗口大小为1，接收方只能按顺序接收数据帧。当发送方某一数据帧丢包或出错时，不考虑确认序号之后的分组是否已经发送到接收方，接收方会要求发送方重新发送当前滑动窗口中所有已发送的数据帧。

累计确认：收到多个分组后，只需要对按序到达的最后一个分组发送确认回复

选择重传ARQ

上面滑动窗口协议时的例子使用的就是选择重传ARQ，即发送窗口和接受窗口大小都>1，这里不再多说。

4.TCP流量控制

当接收方来不及处理发送方的数据，会通知发送方缩小发送窗口，让其降低发送的速率，防止丢包；相应的，当网络状况好转时，接收方可以通知发送方增大发送窗口，提高效率。

下图中rwnd的值表示发送窗口不能超过接收方给出的接收窗口的数值。

持续计时器

上文超时重传提到过这个计时器，它的作用就是：在一方收到对方的零窗口通知时（即rwnd=0），启动持续计时器。时间到了后发送一个零窗口探测报文段验证当前的窗口值（收到回复后会重置计时器），以避免双方因为丢包而互相等待的死锁局面。

5.TCP拥塞控制

拥塞：网络中某一资源的需求>该资源能提供的可用部分，导致网络性能变差。

拥塞控制的作用就是防止过多数据注入网络中，使得网络中的路由器或链路不至于过载。

TCP进行拥塞控制的算法有下面几种：

• 慢开始
• 拥塞避免
• 快重传
• 快恢复

拥塞窗口

拥塞控制也叫基于窗口的拥塞控制，它需要发送方维护一个拥塞窗口cwnd（congestion window）的状态变量。它的大小取决于网络的拥塞程度，并且在动态变化。发送方让自己的发送窗口等于拥塞窗口。

慢开始

主机开始发送数据时，由小到大逐渐增大拥塞窗口数值，发送窗口也跟着由小到大增加。也就是一个“慢热”的过程。

• 刚刚开始发送报文段时，先将初始拥塞窗口cwnd设为1_{2个（新规定是2}4个）发送方最大报文段SMSS（Sender Maximum Segment Size）
• 每收到一个新的报文段确认后，可以将拥塞窗口最多增加一个SMSS的数值
• 每经过一个传输轮次（将cwnd所允许发送的报文段都连续发送出去，并收到了已发送的最后一个字节的确认），就将拥塞窗口加倍

拥塞避免

防止cwnd增长过快，让拥塞窗口cwnd缓慢增大，每经过一个往返时间RTT（这个时间和一个传输轮次的时间相等）将发送方的cwnd+1

• 当cwnd
• 当cwnd>ssthresh，改用拥塞避免算法
• 当cwnd=ssthresh时，两种算法都可以使用

快重传

接收方一旦收到失序的报文段就立即发送连续3次的重复确认，它可以让发送方尽早知道发送了个别报文段的丢失而立即发送对方尚未收到的报文段，而不必等到重传计时器计时结束。

上面图5-25中点4就是执行了快重传算法。

优点：避免发送方出现超时而误以为网络出现了拥塞；使网络吞吐量提高了约20%

快恢复

在发送方收到连续3个重复确认时，就执行快恢复算法。

• 发送方将门限值ssthresh调整为当前拥塞窗口cwnd的一半
• 同时设置拥塞窗口cwnd为ssthresh的值，并开始执行拥塞避免算法

例子：

上图5-25中快恢复就在4点进行快重传后执行，ssthresh调整为1/2cwnd = 8，cwnd设置为ssthresh = 8，并开始执行拥塞避免算法。

TCP和UDP的区别

上面所述的主要区别在于：是否面向连接、传输形式、传输可靠性和首部字节大小。

参考资料

《计算机网络-谢希仁》

计算机网络：这是一份非常全面&详细的TCP/IP协议学习指南

TCP可靠传输再回顾