TCP协议

TCP 是TCP/IP体系中非常复杂的一个协议。

１、TCP的主要特点

序号	特点	描述
1	面向连接	应用程序在使用 TCP协议之前，必须先建立TCP连接。在传输数据完毕后，必须释放已经建立的 TCP连接。
2	每一条TCP连接只能有两个端点	每一条TCP连接只能是点对点的（一对一）。
3	提供可靠交付的服务	通过TCP连接传送的数据，无差错、不丢失、不重复，并且按序到达。
4	提供全双工通信	TCP 允许通信双方的应用进程在任何时候都能发送数据。TCP连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据。在发送时，应用程序把数据传输给 TCP的缓存后，就可以做自己的事，而TCP在合适的时候把数据发送出去。在接收时，TCP把收到的数据放入缓存，上层的应用进程在合适的时候读取缓存中的数据。
5	面向字节流（Byte Stream）	TCP中的流指的是流入到进程或从进程流出的字节序列。

TCP 面向 字节流 的概念：

TCP 和 UDP在 发送报文 时所采用的方式完全不同。

TCP 并不关心应用进程一次把多长的报文发送到TCP的缓存中，而是根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节（UDP发送的报文长度是应用进程给出的）。
如果应用进程传送到TCP缓存的数据块太长，TCP就可以把它划分短一些再传送。如果应用进程一次只发来一个字节，TCP也可以等待积累有足够多的字节后，再构成报文段（Segment）发送出去。

2、TCP 的连接

每一条TCP连接 有两个端点，端点叫套接字（Socket）。
:端口号拼接到IP地址就构成了套接字。

请注意：端点(endpoint) 不是主机，不是主机的IP地址，不是应用进程，也不是传输层的协议端口。

套接字 socket = （IP地址：端口号）

每一条TCP连接唯一地被通信两端的两个端点（即两个套接字）所确定：

TCP连接 ::= {socket1 , socket2} = {(IP1：port1) , (IP2：port2)}

IP1和IP2分别是两个端点主机的IP地址，port1和port2分别是两个端点主机中的端口号。

TCP连接的两个套接字就是socket1和socket2。

请注意：同一个IP地址可以有多个不同的TCP连接，而同一个端口号也可以出现在多个不同的TCP连接中。

3、TCP 可靠传输

TCP 的任务是在 IP 层的不可靠、尽力而为服务的基础上建立一种可靠数据传输服务。TCP 提供的可靠数据传输服务就是要保证接收方进程从缓冲区读出的字节流与发送方发出的字节流是完全一样的。

传输条件不够理想，采用一些可靠传输协议处理以下问题：

• 传输信道出现差错
• 接收方来不及接收数据

3.1 停止等待协议

停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认（回复ACK）。如果过了一段时间（超时时间后），还是没有收到 ACK 确认，说明没有发送成功，需要重新发送，直到收到确认后再发下一个分组。

在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认。

优缺点：

• 优点： 简单
• 缺点： 信道利用率低，等待时间长

1) 无差错情况:

发送方发送分组,接收方在规定时间内收到,并且回复确认.发送方再次发送。

2) 出现差错情况（超时重传）:

停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认，就重传前面发送过的分组（认为刚才发送过的分组丢失了）。
因此每发送完一个分组需要设置一个超时计时器，其重传时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为自动重传请求 ARQ 。

另外在停止等待协议中若收到重复分组，就丢弃该分组，但同时还要发送确认。连续 ARQ 协议 可提高信道利用率。发送维持一个发送窗口，凡位于发送窗口内的分组可连续发送出去，而不需要等待对方确认。接收方一般采用累积确认，对按序到达的最后一个分组发送确认，表明到这个分组位置的所有分组都已经正确收到了。

3) 确认丢失和确认迟到

确认丢失：确认消息在传输过程丢失。

当A发送M1消息，B收到后，B向A发送了一个M1确认消息，但却在传输过程中丢失。而A并不知道，在超时计时过后，A重传M1消息，B再次收到该消息后采取以下两点措施：

• 丢弃这个重复的M1消息，不向上层交付。
• 向A发送确认消息。（不会认为已经发送过了，就不再发送。A能重传，就证明B的确认消息丢失）。

确认迟到 ：确认消息在传输过程中迟到。

A发送M1消息，B收到并发送确认。在超时时间内没有收到确认消息，A重传M1消息，B仍然收到并继续发送确认消息（B收到了2份M1）。此时A收到了B第二次发送的确认消息。接着发送其他数据。过了一会，A收到了B第一次发送的对M1的确认消息（A也收到了2份确认消息）。
处理如下：

• A收到重复的确认后，直接丢弃。
• B收到重复的M1后，也直接丢弃重复的M1。

信道利用率

停止等待ARQ协议的优点是简答，但也有很严重的确定，就是信道利用率太低。如下图所示：

信道利用率U = TD / (TD + RTT + TA)

TD：A发送分组需要的时间
RTT：往返时间
TA：B发送确认分组需要时间

使用上述的确认和重传机制，就可以在不可靠的传输网络上实现可靠的通信。

3.2 连续 ARQ 协议

为了提高传输效率，发送方可以不使用低效率的停止等待协议，而采用流水线传输。
当使用流水线传输时，就要使用连续AQR协议和滑动窗口协议。

发送方采用流水线传输。流水线传输就是发送方可以连续发送多个分组，不必每发完一个分组就停下来等待对方确认。如下图所示：

连续ARQ协议通常是结合滑动窗口协议来使用的，发送方需要维持一个发送窗口，如下图所示：

图（a）是发送方维持的发送窗口，它的意义是：位于发送窗口内的5个分组都可以连续发送出去，而不需要等待对方的确认，这样就提高了信道利用率。

连续ARQ协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。例如上面的图（b），当发送方收到第一个分组的确认，就把发送窗口向前移动一个分组的位置。如果原来已经发送了前5个分组，则现在可以发送窗口内的第6个分组。

接收方一般都是采用累积确认的方式。也就是说接收方不必对收到的分组逐个发送确认。而是在收到几个分组后，对按序到达的最后一个分组发送确认。如果收到了这个分组确认信息，则表示到这个分组为止的所有分组都已经正确接收到了。

累积确认的优点是容易实现，即使确认丢失也不必重传。但缺点是，不能正确的向发送方反映出接收方已经正确收到的所以分组的信息。比如发送方发送了前5个分组，而中间的第3个分组丢失了，这时候接收方只能对前2个发出确认。而不知道后面3个分组的下落，因此只能把后面的3个分组都重传一次，这种机制叫Go-back-N（回退N），表示需要再退回来重传已发送过的N个分组。

由此可知，通信线路质量不好，连续ARQ会带来负面影响。

4、TCP报文段的首部格式

源端口&目的端口

2字节,写入源端口和目的端口号。tcp的分用功能通过端口实现。

序号

4字节,tcp三次握手中的seq,表示tcp数据段发送的第一个字节的序号,范围[0,2^32 - 1],即mod 2^32; 例如,seq = 201,携带的数据有100,那么最后一个字节的序号就为300,那么下一个报文段就应该从401开始，下一个序列的首地址.

tcp是面向字节流的，在tcp连接中每一个字节流都按顺编号

确认号

4字节,为期望收到对方下一个报文段的第一个数据字节序号。注意：若确认号=N，则表示序号N-1为止的序列号已正确收到

数据偏移

4位，指出偏移多远，实际就是指定报文段的首部长度，因为占4位，最大15，因此数据最大偏移为60：即为tcp首部最大长度

控制位

6位，URG、ACK、PSH、RST、SYN

URG

为1表示高优先级数据包，紧急指针字段有效。（告诉系统此报文段有紧急数据，应尽快传输，而不要原来的排队顺序）

ACK

==1 表示确认号字段有效（连接建立后，传输的报文段都应该置为1）,
==0 确认号无效

PSH

为1表示是带有PUSH标志的数据，指示接收方应该尽快将这个报文段交给应用层而不用等待缓冲区装满。

RST

为1表示出现严重差错。可能需要重现创建TCP连接。还可以用于拒绝非法的报文段和拒绝连接请求。
RST 可称为重建位&重置位
SYN

为1表示这是连接请求或是连接接受请求，用于创建连接和使顺序号同步
当 syn=1&ack=1，表明这是一个连接请求报文段

FIN

==1 表示发送方没有数据要传输了，要求释放连接

窗口

2字节，表示从确认号开始，本报文的接受方可以接收的字节数，即接收窗口大小，用于流量控制。（窗口字段明确指出了现在允许对方发送的数据量：窗口大小经常是在动态变换着的！）

校验和

2字节，对整个的TCP报文段，包括TCP头部和TCP数据，以16位字进行计算所得。这是一个强制性的字段。对整个的TCP报文段，包括TCP头部和TCP数据，以16位字进行计算所得。这是一个强制性的字段。

紧急指针

2字节，本报文段中的紧急数据的最后一个字节的序号。本报文段中的紧急数据的最后一个字节的序号。

选项字段

—最多40字节，每个选项的开始是1字节的kind字段，说明选项的类型。 每个选项的开始是1字节的kind字段，说明选项的类型。

TCP只规定一种选项：最大报文长度

5、TCP可靠传输实现

滑动窗口协议

滑动窗口协议在在发送方和接收方之间各自维持一个滑动窗口，发送发是发送窗口，接收方是接收窗口，而且这个窗口是随着时间变化可以向前滑动的。它允许发送方发送多个分组而不需等待确认。TCP的滑动窗口是以字节为单位的。

如下图所示，发送窗口中有四个概念：

• 已发送并收到确认的数据（不在发送窗口和发送缓冲区之内）
• 已发送但未收到确认的数据（位于发送窗口之内）
• 允许发送但尚未发送的数据（位于发送窗口之内）
• 发送窗口之外的缓冲区内暂时不允许发送的数据。

接收窗口中也有四个概念：

• 已发送确认并交付主机的数据（不在接收窗口和接收缓冲区之内）

• 未按序收到的数据（位于接收窗口之内）

• 允许的数据（位于接收窗口之内）

• 不允许接收的数据（位于发送窗口之内）
  
  规则：

• 凡是已经发送过的数据，在未收到确认之前，都必须暂时保留，以便在超时重传时使用。

• 只有当发送方A收到了接收方的确认报文段时，发送方窗口才可以向前滑动几个序号。

• 当发送方A发送的数据经过一段时间没有收到确认（由超时计时器控制），就要使用回退N步协议，回到最后接收到确认号的地方，重新发送这部分数据。

6 、TCP的流量控制

TCP 利用滑动窗口实现流量控制。

流量控制是为了控制发送方发送速率，保证接收方来得及接收。 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。

7、TCP的拥塞控制

在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫拥塞。
拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

为了进行拥塞控制，TCP 发送方要维持一个 拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。

TCP的拥塞控制采用了四种算法，即 慢开始 、拥塞避免 、快重传 和 快恢复。在网络层也可以使路由器采用适当的分组丢弃策略（如主动队列管理 AQM），以减少网络拥塞的发生。

• 慢开始： 慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd初始值为1，每经过一个传播轮次，cwnd加倍。
• 拥塞避免： 拥塞避免算法的思路是让拥塞窗口cwnd缓慢增大，即每经过一个往返时间RTT就把发送放的cwnd加1.
• 快重传与快恢复： 在 TCP/IP 中，快速重传和恢复（fast retransmit and recovery，FRR）是一种拥塞控制算法，它能快速恢复丢失的数据包。没有 FRR，如果数据包丢失了，TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。有了 FRR，如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。有了 FRR，就不会因为重传时要求的暂停被耽误。 　当有单独的数据包丢失时，快速重传和恢复（FRR）能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时，它则不能很有效地工作。

8 、TCP的运输链接管理

TCP是面向连接的协议。运输连接是用来传送TCP报文的。
TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。
因此，运输连接就有三个阶段，即：连接建立、数据传送和连接释放。运输连接的管理就是使运输连接的建立和释放都能正常地进行。

8.1、 TCP的连接建立

假定主机A运行的是TCP客户程序，而B运行TCP服务器程序。最初两端的TCP都处于CLOSED（关闭）状态。图中在主机下面的方框分别是TCP进程所处的状态。注意：本例中，A主动打开连接，而B被动打开连接。

一开始，B的TCP服务器进程先创建传输控制块TCB（存储了每一个连接中的一些重要信息，如：TCP连接表，指向发送和接收缓存的指针，指向重传队列的指针，当前的发送和接收序号，等等），准备接受客户进程的连接请求。然后服务器进程就处于LISTEN（收听）状态，等待客户的连接请求。如有，即作出响应。

A的TCP客户进程也是首先创建传输控制块TCB。然后，在打算建立TCP连接时，向B发出连接请求报文段，这时首部中的同步位SYN=1，同时选择一个初始序号seq=x。TCP规定，SYN报文段（即SYN=1的报文段）不能携带数据，但要消耗掉一个序号。这时，TCP客户进程进入SYN-SENT（同步已发送）状态。

B收到连接请求报文段后，如同意建立连接，则向A发送确认。在确认报文段中应把SYN位和ACK位都置1，确认号是ack=x+1，同时也为自己选择一个初始序号seq=y。注意：这个报文段也不能携带数据，但同样要消耗掉一个序号。这时TCP服务器进程进入SYN-RCVD（同步收到）状态。

TCP客户进程收到B的确认后，还要向B给出确认。确认报文段的ACK置1，确认号ack=y+1，而自己的序号seq=x+1。TCP的标准规定，ACK报文段可以携带数据。但如果不携带数据则不消耗序号，在这种情况下，下一个数据报文段的序号仍是seq=x+1。这是TCP连接已经建立，A进入ESTABLISHED（已建立连接）状态。

当B收到A的确认后，也进入ESTABLISHED状态。

为什么A最后还要发送一次确认？

主要是为了防止已失效的连接请求报文段突然又传送到了B，因而产生错误。

为什么要三次握手

三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。

• 第一次握手：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常
• 第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常
• 第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常

所以三次握手就能确认双发收发功能都正常，缺一不可。

第二次握手传回来了ACK，为什么还要传回SYN？

接收端传回发送端所发送的ACK是为了告诉客户端，我接收到的信息确实就是你所发送的信号了，这表明从客户端到服务端的通信是正常的。而回传SYN则是为了建立并确认从服务端到客户端的通信。

8.2、TCP的连接释放

数据传输完毕后，双方都可释放连接。最开始的时候，客户端和服务器都是处于ESTABLISHED状态，然后客户端主动关闭，服务器被动关闭。

• 客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
• 服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
• 客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
• 服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
• 客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗ *∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
• 服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

为什么客户端最后还要等待2MSL？

MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。

• 第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。
• 第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

为什么建立连接是三次握手，关闭连接确是四次挥手呢？

建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。

如果已经建立了连接，但是客户端突然出现故障了怎么办？

CP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。