tcp/udp是属于运输层的两个重要协议：
(1)用户数据报协议UDP。
(2)传输控制协议TCP。
1.UDP的主要特点
(1) UDP是无连接的，即发送数据之前不需要建立连接，因此减少了开销和发送数据之前的时延。
(2) UDP使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的连接状态表。
(3) UDP是面向报文的。发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付IP层。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。因此，应用程序必须选择合适大小的报文。
(4) UDP没有拥塞控制，因此网络出现的拥塞不会使源主机的发送速率降低。很多的实时应用（如IP电话、实时视频会议等）要去源主机以恒定的速率发送数据，并且允许在网络发生拥塞时丢失一些数据，但却不允许数据有太多的时延。UDP正好符合这种要求。
(5) UDP支持一对一、一对多、多对一和多对多的交互通信。
(6) UDP的首部开销小，只有8个字节，比TCP的20个字节的首部要短。
注意：
(1) 不使用拥塞控制功能的UDP有可能会引起网络产生严重的拥塞问题。
(2) 一些使用UDP的实时应用进程本身可以在不影响应用的实时性的前提下，增加一些提高可靠性的措施，如采用前向纠错或重传已丢失的报文。
UDP的首部格式
用户数据报UDP有两个字段：数据字段和首部字段。首部字段很简单，只有8个字节，由四个字段组成，每个字段的长度都是两个字节。各字段的意义如下：
(1) 源端口 源端口号。在需要对方回信时选用。不需要时可用全0。
(2) 目的端口 目的端口号。 这在终点交付报文时必须要使用到。
(3) 长度 UDP用户数据报的长度，其最小值是8（仅有首部）
(4) 检验和 检测UDP用户数据报在传输中是否有错。有错就丢弃。
一个UDP模块必须提供产生和验证检验和的功能，但是一个应用程序在使用UDP服务时，可以自由选择是否要求产生校检和。在计算校检和时，要在UDP用户数据报之前增加12字节的伪首部。校检和就是按照这个临时的UDP用户数据报来计算的。
UDP计算校检和的方法和计算IP数据报首部校检和的方法相似。但不同的是：IP数据报的校检和只校检IP数据报的首部，但UDP的校检和使把首部和数据部分一起都校检。
UDP的复用和分用
当运输层从IP层收到UDP数据报时，就根据首部中的目的端口，把UDP数据报通过相应的端口，上交到最后的终点——应用进程。下图是UDP基于端口分用的示意图。
基于端口的复用示意图与上图相似，只是数据报的传输方向相反。
如果接收方UDP发现收到的报文中的目的端口号不正确（即不存在对应于该端口号的应用进程），就丢弃该报文，并由网际控制报文协议ICMP发送“端口不可达”差错报文给发送方。
2.tcp的主要特点
(1)TCP是面向连接的运输层协议。就是说，引用在使用TCP协议之前，必须先建立TCP连接
(2)每一条TCP连接只能有两个端点，每一条TCP只能是点对点的
(3)TCP提供可靠交付的服务。通过TCP连接传送的数据，无差错、不丢失、不重复、并且按序到达
(4)TCP提供全双工通信。允许通信双方的引用进程在任何时候都发送数据。
(5)面向字节流。
可靠传输的工作原理
（1）以字节为单位的滑动窗口
（2）超时重传
现在假设A是发送方，B是接收方，现假定A收到了B发来的确认报文段，期中窗口为20，确认号是31（表明B期望收到的下一个序号是31，而序号30为止的数据已经收到），根据这两个数据，A就可以构造自己的发送窗口。如下图：
现假定A发送了序号为31~41的数据。这时发送窗口的位置并未改变，但是发送窗口内靠后面有11个字节表示已发送但是未收到确认，而发送窗口内靠前面的9个字节是允许发送但尚未发送的。
从上述可知描述一个窗口需要三个指针P1,P2,P3。
再看一下B的窗口，B的接收窗口的大小是20，在接收窗口外面，到30号为止的数据表示已经发送过确认，并且交付主机了。因此在B可以不再保留这些数据。接收窗口内的序号31~50是允许接收的。在上面的图5-16中，B收到了序号为32和33 的数据，这些数据没有按序到达，因为31的数据没有收到，请注意B只能对按序号收到的数据中的最高序号给出确认，因此B发送的确认报文段中的确认号仍然是31。
现在假定B收到31的数据，并把序号为31~33的数据交付主机，然后B删除这些数据。接着把窗口向前移动3个序号，（图5-17），同时给A发送确认，期中窗口的值仍然是20，但确认号是34。这表明B已经收到了到序号33为止的数据。我们注意到，B还接收到了没按序号到达的37,38和40的数据，但这些都没有按序到达，只能暂时放在接收窗口中。A收到B的确认后，就可以把发送窗口向前滑动3个序号了。
A继续发送完序号42~53的数据，由于A发送窗口已满，可用窗口减小到0，因此必须停止发送。请注意，存在下面的可能性，就是发送窗口内的数据都已经正确到达B，B也早已发出了确认。但不幸的是，所有这些确认都滞留在网络中。没有收到B的确认时，A不能猜测B收到了，为了保证可靠传输，A只能认为B还没有收到这些数据。于是A经过一段时间后（超时计时器控制）就重传这部分的数据，重新设置超时计时器。直到收到B的确认为止。
tcp首部格式
TCP虽然是面向字节流的，但TCP传送的数据单元却是报文段。一个TCP报文段分为首部和数据两部分，而TCP的全部功能体现在它首部中的各字段的作用。因此，我们需要详细了解一下TCP首部各字段的作用。
TCP报文段首部的前20个字节是固定的（下图），后面有4n字节是根据需要而增加的选项（n是整数）。因此TCP首部的最小长度是20字节。
首部固定部分各字段意义如下：
1） 源端口和目的端口 各占2个字节，分别写入源端口和目的端口。
2） 序号 占4字节。序号范围是【0，2^32 - 1】，共2^32 （即4294967296）个序号。序号增加到2^32-1后，下一个序号就又回到0。也就是说，序号使用mod 2^32运算。TCP是面向字节流的。在一个TCP连接中传送的字节流中的每一个字节都按顺序编号。整个要传送的字节流的起始序号必须在连接建立时设置。首部中的序号字段值则是指的是本报文段所发送的数据的第一个字节的序号。例如，一报文段的序号是301，而接待的数据共有100字节。这就表明：本报文段的数据的第一个字节的序号是301，最后一个字节的序号是400。显然，下一个报文段（如果还有的话）的数据序号应当从401开始，即下一个报文段的序号字段值应为401。这个字段的序号也叫“报文段序号”。
3） 确认号 占4字节，是期望收到对方下一个报文段的第一个数据字节的序号。例如，B正确收到了A发送过来的一个报文段，其序号字段值是501，而数据长度是200字节（序号501~700），这表明B正确收到了A发送的到序号700为止的数据。因此，B期望收到A的下一个数据序号是701，于是B在发送给A的确认报文段中把确认号置为701。注意，现在确认号不是501，也不是700，而是701。 总之：若确认号为= N，则表明：到序号N-1为止的所有数据都已正确收到。
4） 数据偏移 占4位，它指出TCP报文段的数据起始处距离TCP报文段的起始处有多远。这个字段实际上是指出TCP报文段的首部长度。由于首部中还有长度不确定的选项字段，因此数据偏移字段是必要的，但应注意，“数据偏移”的单位是32位字（即以4字节的字为计算单位）。由于4位二进制数能表示的最大十进制数字是15，因此数据偏移的最大值是60字节，这也是TCP首部的最大字节（即选项长度不能超过40字节）。
5） 保留 占6位，保留为今后使用，但目前应置为0 。
下面有6个控制位，用来说明本报文段的性质。
6） 紧急URG（URGent） 当URG=1时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快发送（相当于高优先级的数据），而不要按原来的排队顺序来传送。例如，已经发送了很长的一个程序要在远地的主机上运行。但后来发现了一些问题，需要取消该程序的运行，因此用户从键盘发出中断命令。如果不使用紧急数据，那么这两个字符将存储在接收TCP的缓存末尾。只有在所有的数据被处理完毕后这两个字符才被交付接收方的应用进程。这样做就浪费了很多时间。
当URG置为1时，发送应用进程就告诉发送方的TCP有紧急数据要传送。于是发送方TCP就把紧急数据插入到本报文段数据的最前面，而在紧急数据后面的数据仍然是普通数据。这时要与首部中紧急指针（Urgent Pointer）字段配合使用。
7） 确认ACK（ACKnowledgment） 仅当ACK = 1时确认号字段才有效，当ACK = 0时确认号无效。TCP规定，在连接建立后所有的传送的报文段都必须把ACK置为1。
8） 推送 PSH（PuSH） 当两个应用进程进行交互式的通信时，有时在一端的应用进程希望在键入一个命令后立即就能收到对方的响应。在这种情况下，TCP就可以使用推送（push）操作。这时，发送方TCP把PSH置为1，并立即创建一个报文段发送出去。接收方TCP收到PSH=1的报文段，就尽快地（即“推送”向前）交付接收应用进程。而不用再等到整个缓存都填满了后再向上交付。
9） 复位RST（ReSeT） 当RST=1时，表名TCP连接中出现了严重错误（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立传输连接。RST置为1还用来拒绝一个非法的报文段或拒绝打开一个连接。
10） 同步SYN（SYNchronization） 在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使SYN=1和ACK=1，因此SYN置为1就表示这是一个连接请求或连接接受报文。
11） 终止FIN（FINis，意思是“完”“终”） 用来释放一个连接。当FIN=1时，表明此报文段的发送发的数据已发送完毕，并要求释放运输连接。
12） 窗口 占2字节。窗口值是【0，2^16-1】之间的整数。窗口指的是发送本报文段的一方的接受窗口（而不是自己的发送窗口）。窗口值告诉对方：从本报文段首部中的确认号算起，接收方目前允许对方发送的数据量（以字节为单位）。之所以要有这个限制，是因为接收方的数据缓存空间是有限的。总之，窗口值作为接收方让发送方设置其发送窗口的依据。
例如，发送了一个报文段，其确认号是701，窗口字段是1000.这就是告诉对方：“从701算起，我（即发送方报文段的一方）的接收缓存空间还可接受1000个字节数据（字节序号是701~1700），你在给我发数据时，必须考虑到这一点。”总之：窗口字段明确指出了现在允许对方发送的数据量。窗口值经常在动态变化。
13） 检验和 占2字节。检验和字段检验的范围包括首部和数据这两部分。和UDP用户数据报一样，在计算检验和时，要在TCP报文段的前面加上12字节的伪首部。伪首部的格式和UDP用户数据报的伪首部一样。但应把伪首部第4个字段中的17改为6（TCP的协议号是6）；把第5字段中的UDP中的长度改为TCP长度。接收方收到此报文段后，仍要加上这个伪首部来计算检验和。若使用TPv6,则相应的伪首部也要改变。
14） 紧急指针 占2字节。紧急指针仅在URG=1时才有意义，它指出本报文段中的紧急数据的字节数（紧急数据结束后就是普通数据） 。因此，在紧急指针指出了紧急数据的末尾在报文段中的位置。当所有紧急数据都处理完时，TCP就告诉应用程序恢复到正常操作。值得注意的是，即使窗口为0时也可以发送紧急数据。
15） 选项 长度可变，最长可达4字节。当没有使用“选项”时，TCP的首部长度是20字节。
TCP最初只规定了一种选项，即最大报文段长度MSS（Maximum Segment Szie）。注意MSS这个名词含义。MSS是每一个TCP报文段中的数据字段的最大长度。数据字段加上TCP首部才等于整个的TCP报文段。所以MSS并不是整个TCP报文段的最大长度，而是“TCP报文段长度减去TCP首部长度”。
为什么要规定一个最大报文长度MSS呢？这并不是考虑接受方的接收缓存可能存放不下TCP报文段中的数据。实际上，MSS与接收窗口值没有关系。我们知道，TCP报文段的数据部分，至少要加上40字节的首部（TCP首部20字节和IP首部20字节，这里还没有考虑首部中的可选部分）才能组装成一个IP数据报。若选择较小的MSS长度，网络的利用率就降低。设想在极端情况下，当TCP报文段只含有1字节的数据时，在IP层传输的数据报的开销至少有40字节（包括TCP报文段的首部和IP数据报的首部）。这样，对网络的利用率就不会超过1/41。到了数据链路层还要加上一些开销。但反过来，若TCP报文段非常长，那么在IP层传输时就有可能要分解成多个短数据报片。在终点要把收到的各个短数据报片组成成原来的TCP报文段，当传输出错时还要进行重传，这些也都会使开销增大。
因此，MSS应尽可能大些，只要在IP层传输时不需要分片就行。由于IP数据报所经历的路径是动态变化的，因此在这条路径上确定的不需要的分片的MSS，如果改走另一条路径就可能需要进行分片。因此最佳的MSS是很难确定的。在连接过程中，双方都把自己能够支持的MSS写入这一字段，以后就按照这个数值传输数据，两个传送方向可以有不同的MSS值。若主机未填写这一项，则MSS的默认值是536字节长。因此，所有在互联网上的主机都应该接受的报文段长度是536+20（固定首部长度）=556字节。
后来又增加了几个选项如窗口扩大选项、时间戳选项等。
窗口扩大选项是为了扩大窗口。我们知道，TCP首部中窗口字段长度是16位，因此最大的窗口大小为64K字节。虽然这对早期的网络是足够用的，但对于包含卫星信道的网络，传播时延和宽带都很大，要获得高吞吐量需要更大的窗口大小。
窗口扩大选项占3字节，其中有一个字节表示移位值S。新的窗口值等于TCP首部中的窗口位数从16增大到（16+S）。移位值允许使用的最大值是14，相当于窗口最大值增大到2^（16+14）-1 =2^30-1。
窗口扩大选项可以在双方初始建立TCP连接时进行协商。如果连接的某一端实现了窗口扩大，当它不再需要扩大其窗口时，可发送S=0选项，使窗口大小回到16。
时间戳选项占10字节，其中最主要的字段是时间戳字段（4字节）和时间戳回送回答字段（4字节）。时间戳选项有以下两个概念：
第一、 用来计算往返时间RTT。发送方在发送报文段时把当前时钟的时间值放入时间戳字段，接收方在确认该报文段时把时间戳字段复制到时间戳回送回答字段。因此，发送方在收到确认报文后，可以准确地计算出RTT来。
第二、 用于处理TCP序号超过2^32 的情况，这又称为防止序号绕回PAWS。我们知道，TCP报文段的序号只有32位，而每增加2^32个序号就会重复使用原来用过的序号。当使用高速网络时，在一次TCP连接的数据传送中序号很可能被重复使用。例如，当使用1.5Mbit/s的速度发送报文段时，序号重复要6小时以上。但若用2.5Gbit/s的速率发送报文段，则不到14秒钟序号就会重复。为了使接收方能够把新的报文段和迟到很久的报文段区分开，则可以在报文段中加上这种时间戳。
tcp流量控制
流量控制方面主要有两个要点需要掌握。一是TCP利用滑动窗口实现流量控制的机制；二是如何考虑流量控制中的传输效率。
-
流量控制
所谓流量控制，主要是接收方传递信息给发送方，使其不要发送数据太快，是一种端到端的控制。主要的方式就是返回的ACK中会包含自己的接收窗口的大小，并且利用大小来控制发送方的数据发送：
image.png
这里面涉及到一种情况，如果B已经告诉A自己的缓冲区已满，于是A停止发送数据；等待一段时间后，B的缓冲区出现了富余，于是给A发送报文告诉A我的rwnd大小为400，但是这个报文不幸丢失了，于是就出现A等待B的通知||B等待A发送数据的死锁状态。为了处理这种问题，TCP引入了持续计时器（Persistence timer），当A收到对方的零窗口通知时，就启用该计时器，时间到则发送一个1字节的探测报文，对方会在此时回应自身的接收窗口大小，如果结果仍未0，则重设持续计时器，继续等待。
- 传递效率
一个显而易见的问题是：单个发送字节单个确认，和窗口有一个空余即通知发送方发送一个字节，无疑增加了网络中的许多不必要的报文（请想想为了一个字节数据而添加的40字节头部吧！），所以我们的原则是尽可能一次多发送几个字节，或者窗口空余较多的时候通知发送方一次发送多个字节。对于前者我们广泛使用Nagle算法，即：
*1. 若发送应用进程要把发送的数据逐个字节地送到TCP的发送缓存，则发送方就把第一个数据字节先发送出去，把后面的字节先缓存起来；
*2. 当发送方收到第一个字节的确认后（也得到了网络情况和对方的接收窗口大小），再把缓冲区的剩余字节组成合适大小的报文发送出去；
*3. 当到达的数据已达到发送窗口大小的一半或以达到报文段的最大长度时，就立即发送一个报文段；
对于后者我们往往的做法是让接收方等待一段时间，或者接收方获得足够的空间容纳一个报文段或者等到接受缓存有一半空闲的时候，再通知发送方发送数据。
tcp拥塞控制
网络中的链路容量和交换结点中的缓存和处理机都有着工作的极限，当网络的需求超过它们的工作极限时，就出现了拥塞。拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。常用的方法就是：
- 慢开始、拥塞控制
- 快重传、快恢复
一切的基础还是慢开始，这种方法的思路是这样的：
- 发送方维持一个叫做“拥塞窗口”的变量，该变量和接收端口共同决定了发送者的发送窗口；
- 当主机开始发送数据时，避免一下子将大量字节注入到网络，造成或者增加拥塞，选择发送一个1字节的试探报文；
- 当收到第一个字节的数据的确认后，就发送2个字节的报文；
- 若再次收到2个字节的确认，则发送4个字节，依次递增2的指数级；
- 最后会达到一个提前预设的“慢开始门限”，比如24，即一次发送了24个分组，此时遵循下面的条件判定：
*1. cwnd < ssthresh， 继续使用慢开始算法；
*2. cwnd > ssthresh，停止使用慢开始算法，改用拥塞避免算法；
*3. cwnd = ssthresh，既可以使用慢开始算法，也可以使用拥塞避免算法； - 所谓拥塞避免算法就是：每经过一个往返时间RTT就把发送方的拥塞窗口+1，即让拥塞窗口缓慢地增大，按照线性规律增长；
-
当出现网络拥塞，比如丢包时，将慢开始门限设为原先的一半，然后将cwnd设为1，执行慢开始算法（较低的起点，指数级增长）；
image.png
上述方法的目的是在拥塞发生时循序减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够的时间把队列中积压的分组处理完毕。慢开始和拥塞控制算法常常作为一个整体使用，而快重传和快恢复则是为了减少因为拥塞导致的数据包丢失带来的重传时间，从而避免传递无用的数据到网络。快重传的机制是：
- 接收方建立这样的机制，如果一个包丢失，则对后续的包继续发送针对该包的重传请求；
- 一旦发送方接收到三个一样的确认，就知道该包之后出现了错误，立刻重传该包；
- 此时发送方开始执行“快恢复”算法：
- 慢开始门限减半；
- cwnd设为慢开始门限减半后的数值；
-
执行拥塞避免算法（高起点，线性增长）；
image.png
tcp连接管理
1. 连接过程
tcp建立连接的过程也叫三次握手：假设A是客户端，B是服务器，A主动打开连接，B被动打开连接。
- 第一次握手：
A向B发起连接,这时tcp协议首部的同部位SYN=1，同时选择一个初始序号seq=x。tcp规定，SYN=1的报文段不能携带数据，但是要消耗一个序号。这时tcp客户端进入SYN_SEND状态。 - 第二次握手：
B收到连接请求后，如同意建立连接，则向A发送确认。在确认报文段中设置SYN=1，ACK=1，确认号ack=x+1，同时也为自己选择一个初始序号seq=y。这个报文段也不能携带数据，但同样也要消耗一个序号。这是服务器进入SYN_RECV状态。 - 第三次握手
tcp客户端收到B的确认后，还要向B给出确认，确认报文段的ACK=1，确认号seq=y+1，而自己的序号为ack=x+1。ACK报文段可以携带数据，但如果没有携带数据则不消耗序号，这种情况下，下个数据报文段的序号仍然是seq=x+1。这时tcp建立连接，A进入ESTABLISHED状态。
tcp连接过程图：
握手中断
- 第一次握手中断: A发送给B的SYN中断，A会周期性超时重传，直到A收到B的确认响应。
- 第二次握手中断: B发送给A的SYN、ACK中断，B会周期性超时重传，直到B收到A的确认响应。
- 第三次握手中断: A发送给B的ACK中断，A不会重传。超时后，B会重传SYN信号(即回到第二次握手)，直到B收到A的确认响应。
为什么要三次握手
以下是两种比较权威说法：
- 在谢希仁著《计算机网络》第四版中讲“三次握手”的目的是“为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”。在另一部经典的《计算机网络》一书中讲“三次握手”的目的是为了解决“网络中存在延迟的重复分组”的问题。这两种不用的表述其实阐明的是同一个问题。谢希仁版《计算机网络》中的例子是这样的，“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”
- 在Google Groups的TopLanguage中看到一帖讨论TCP“三次握手”觉得很有意思。贴主提出“TCP建立连接为什么是三次握手？”的问题，在众多回复中，有一条回复写道：“这个问题的本质是, 信道不可靠, 但是通信双发需要就某个问题达成一致. 而要解决这个问题, 无论你在消息中包含什么信息, 三次通信是理论上的最小值. 所以三次握手不是TCP本身的要求, 而是为了满足"在不可靠信道上可靠地传输信息"这一需求所导致的. 请注意这里的本质需求,信道不可靠, 数据传输要可靠. 三次达到了, 那后面你想接着握手也好, 发数据也好, 跟进行可靠信息传输的需求就没关系了. 因此,如果信道是可靠的, 即无论什么时候发出消息, 对方一定能收到, 或者你不关心是否要保证对方收到你的消息, 那就能像UDP那样直接发送消息就可以了.”。
2. 断开过程
tcp的断开过程也叫四次挥手的过程。
假设Client端发起中断连接请求，也就是发送FIN报文。Server端接到FIN报文后，意思是说"我Client端没有数据要发给你了"，但是如果你还有数据没有发送完成，则不必急着关闭Socket，可以继续发送数据。所以你先发送ACK，"告诉Client端，你的请求我收到了，但是我还没准备好，请继续你等我的消息"。这个时候Client端就进入FIN_WAIT状态，继续等待Server端的FIN报文。当Server端确定数据已发送完成，则向Client端发送FIN报文，"告诉Client端，好了，我这边数据发完了，准备好关闭连接了"。Client端收到FIN报文后，"就知道可以关闭连接了，但是他还是不相信网络，怕Server端不知道要关闭，所以发送ACK后进入TIME_WAIT状态，如果Server端没有收到ACK则可以重传。“，Server端收到ACK后，"就知道可以断开连接了"。Client端等待了2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，我Client端也可以关闭连接了。Ok，TCP连接就这样关闭了！
断开过程图：
断开过程
- A的应用进程先向其TCP发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据，主动关闭TCP连接，进入FIN-WAIT-1（终止等待1）状态，等待B的确认。
- B收到连接释放报文段后即发出确认报文段，（ACK=1，确认号ack=u+1，序号seq=v），B进入CLOSE-WAIT（关闭等待）状态，此时的TCP处于半关闭状态，A到B的连接释放。
- A收到B的确认后，进入FIN-WAIT-2（终止等待2）状态，等待B发出的连接释放报文段。
- B没有要向A发出的数据，B发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），B进入LAST-ACK（最后确认）状态，等待A的确认。
- A收到B的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），A进入TIME-WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，A才进入CLOSED状态。
为什么A在TIME-WAIT状态必须等待2MSL的时间？
MSL最长报文段寿命Maximum Segment Lifetime，MSL=2
答：两个理由：
- 保证A发送的最后一个ACK报文段能够到达B。
这个ACK报文段有可能丢失，使得处于LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认，B超时重传FIN+ACK报文段，而A能在2MSL时间内收到这个重传的FIN+ACK报文段，接着A重传一次确认，重新启动2MSL计时器，最后A和B都进入到CLOSED状态，若A在TIME-WAIT状态不等待一段时间，而是发送完ACK报文段后立即释放连接，则无法收到B重传的FIN+ACK报文段，所以不会再发送一次确认报文段，则B无法正常进入到CLOSED状态。
- 防止“已失效的连接请求报文段”出现在本连接中。
A在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段。
保活计时器
除了时间等待计时器外，tcp还设置一个保活计时器。设想有这样的情况：客户端已主动跟服务端建立连接。但后来客户端主机突然故障。显然服务器以后就不能再收到客户端发来的数据。因此应当有措施使服务器不要白白等待下去。这就是保活计时器。服务器每收到一次客户的数据，就重新设置保活计时器，时间的设置一般是2个小时。若两个小时没有收到一次客户的数据，服务器就发送一个探测报文段，以后则每隔75分钟发送一次，若一连发送十次仍然没有响应，服务器就认为客户端出了故障，接着服务器就自己关闭这个链接。