计算机网络网课笔记-运输层

上次的网络层前前后后花了两天半，顺利完结撒花~

终于到爷最爱的运输层啦！（bushi

概述

• 之前课程所介绍的计算机网络体系结构中的物理层、数据链路层以及网络层它们共同解决了将主机通过异构网络互联起来所面临的问题，实现了主机到主机的通信。
• 但实际上在计算机网络中进行通信的真正实体是位于通信两端主机中的进程。
• 如何为运行在不同主机上的应用进程提供直接的通信服务是运输层的任务，运输层协议又称为端到端协议。

运输层向高层用户屏蔽了下面网络核心的细节（如网络拓扑、所采用的路由选择协议等），它使应用进程看见的就好像是在两个运输层实体之间有一条端到端的逻辑通信信道。

根据应用需求的不同，因特网的运输层为应用层提供了两种不同的运输协议，即面向连接的TCP和无连接的UDP，这两种协议就是本章要讨论的主要内容。

运输层端口号、复用与分用

端口号

• 运行在计算机上的进程使用进程标识符PID来标志。
• 因特网上的计算机并不是使用统一的操作系统，不同的操作系统（windows，Linux，Mac OS）又使用不同格式的进程标识符。
• 为了使运行不同操作系统的计算机的应用进程之间能够进行网络通信，就必须使用统一的方法对TCP/IP体系的应用进程进行标识。
• TCP/IP体系的运输层使用端口号来区分应用层的不同应用进程。
  • 端口号使用16比特表示，取值范围0~65535；
    • 熟知端口号：0~1023，IANA把这些端口号指派给了TCP/IP体系中最重要的一些应用协议，例如：FTP使用21/20，HTTP使用80，DNS使用53。
    • 登记端口号：1024~49151，为没有熟知端口号的应用程序使用。使用这类端口号必须在IANA按照规定的手续登记，以防止重复，例如：Microsoft RDP 微软远程桌面使用的端口是3389。
    • 短暂端口号：49152~65535，留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时，就知道了客户进程所使用的动态端口号。通信结束后，这个端口号可供其他客户进程以后使用。
  • 端口号只具有本地意义，即端口号只是为了标识本计算机应用层中的各进程，在因特网中，不同计算机中的相同端口号是没有联系的。

发送方的复用与接收方的分用

TCP/IP体系的应用层常用协议所使用的运输层熟知端口号

端口号应用举例

如图所示，用户PC、DNS服务器、Web服务器通过交换机进行互联，它们处于同一个以太网中。假设Web服务器域名如图，DNS服务器中记录有该域名所对应的IP地址。

我们在用户PC中使用网页浏览器来访问Web服务器的内容，在网页浏览器的地址栏中输入Web服务器的域名。用户PC中的DNS客户端进程会发送一个DNS查询请求报文，其内容如图。

DNS查询请求报文需要使用运输层的UDP协议封装成UDP用户数据报，其首部中的源端口字段中的值在短暂端口号49151-65535挑选一个未被占用的用来标识客户端进程，例如49152。目的端口字段的值设置为53，这是DNS服务器端进程使用的熟知端口号。

之后将UDP用户数据报封装在IP数据报中通过以太网发送给DNS服务器。

DNS服务器收到该数据报后，从中解封出UDP用户数据报，UDP首部中的目的端口号为53，这表明应将UDP用户数据报的数据载荷部分，也就是DNS查询请求报文，交付给本服务器中的DNS服务器端进程。

DNS服务器端进程解析DNS查询请求报文的内容，然后按其要求查找对应的IP地址。之后，会给用户PC发送DNS响应报文，其内容如图。

DNS响应报文需要使用运输层的UDP协议封装成UDP用户数据报。其首部中的源端口字段的值设置为熟知端口号53，表明这是DNS服务器端进程所发送的UDP用户数据报。目的端口字段的值设置为49152，这是之前用户PC中发送DNS查询请求报文的DNS客户端进程所使用的短暂端口号。

之后，将UDP用户数据报封装在IP数据报中，通过以太网发送给用户PC。

用户PC收到该数据报后，从中解封出UDP用户数据报。UDP首部中的目的端口号为49152，这表明应将该UDP用户数据报的数据载荷部分，也就是DNS响应报文，交付给用户PC中的DNS客户端进程。

DNS客户端进程解析DNS相应报文的内容，就可知道自己之前所请求的Web服务器的域名所对应的IP地址。

现在，用户PC中的HTTP客户端进程可以向Web服务器发送HTTP请求报文了，其内容如图所示。

HTTP请求报文需要使用运输层的TCP协议封装成TCP报文段，其首部中的源端口字段的值在短暂端口号49151-65535中挑选一个未被占用的，用来标识HTTP客户端进程。例如仍然使用之前用过的49152，目的端口字段的值设置为80，这是HTTP服务器端进程所使用的熟知端口号。

之后将TCP报文段封装在IP数据报中，通过以太网发送给Web服务器。

Web服务器收到该数据报后，从中解封出TCP报文段。TCP首部中的目的端口号为80，这表明应该将该TCP报文段的数据载荷部分，也就是HTTP请求报文，交付给本服务器中的HTTP服务器端进程。

HTTP服务器端进程解析HTTP请求报文的内容，然后按其要求查找首页内容。之后会给用户PC发送HTTP相应报文，其内容如图所示。HTTP相应报文需要使用运输层的TCP协议封装成TCP报文段，其首部中的源端口号字段的值设置为熟知端口号80，表明这是HTTP服务器端进程所发送的TCP报文段。目的端口字段的值设置为49152，这是之前用户PC中发送HTTP请求报文的HTTP客户端进程所使用的短暂端口号。

之后，将TCP报文段封装在IP数据报中，通过以太网发送给用户PC。

用户PC收到该数据报后，从中解封出TCP报文段，TCP首部中的目的端口号为49152，这表明应该将该TCP报文段的数据载荷部分，也就是HTTP相应报文，交付给用户PC中的HTTP客户端进程。

HTTP客户端进程解析HTTP相应报文的内容，并在网页浏览器中进行显示。这样，我们就可以在网页浏览器中看到Web服务器所提供的首页内容了。

TCP和UDP的对比

使用UDP协议的通信双方可以随时发送数据

使用TCP协议的通信双方在进行数据传输前，需要通过三报文握手建立TCP连接。TCP连接建立成功后才能进行数据传输。数据传输结束后，需要使用四报文挥手来释放TCP连接。

（这里的连接是指逻辑连接，而不是物理连接

图中是使用UDP协议的四台主机，其中任意一个主机都可以向其他主机发送广播，也可以向某个多播组发送多播，还可以向某台主机发送单播。也就是说，UDP支持一对一、一对多和一对全的通信。

使用TCP协议的通信双方，在进行数据传输之前必须要使用三报文握手来建立连接，通信双方使用这条基于TCP连接的可靠信道进行通信。TCP仅支持单播，也就是一对一的通信。

发送方的应用进程将应用层报文交付给运输层的UDP，UDP直接给应用层报文添加一个UDP首部，使之成为UDP用户数据报，然后进行发送。接收方的UDP收到该UDP用户数据报后，去掉UDP首部，将应用层报文交付给应用进程。也就是说，UDP对应用进程交下来的报文既不合并也不拆分，而是保留这些报文的边界。

发送方的TCP把应用进程交付下来的数据块仅仅看作是一连串的、无结构的字节流。TCP仅将字节流编号，并存储在自己的发送缓存中。TCP根据发送策略从发送缓存中提取一定数量的字节构造TCP报文段进行发送。接收方的TCP一方面从接收到的TCP报文段中，取出数据载荷部分并存储在接收缓存中，一方面将接收缓存中的一些字节交付给应用进程。TCP不保证接收方应用进程所收到的数据块与发送方应用进程所发出的数据块具有对应大小的关系。但接收方的应用进程收到的字节流必须和发送方应用进程发出的字节流完全一样。这是TCP实现可靠传输、流量控制、拥塞控制的基础。

当运输层使用UDP协议时，向上提供无连接的不可靠传输服务。

当运输层使用TCP协议时，向上提供面向连接的可靠传输服务。

由于UDP不提供可靠传输服务，它仅在网际层的基础上添加了用于区分应用进程的端口，因此首部非常简单，仅有8个字节。

TCP首部格式比UDP复杂得多，其最小长度为20字节，最大长度为60字节，因为TCP要实现可靠传输、流量控制、拥塞控制等服务，其首部自然会比较复杂。首部中的字段比较多、首部长度也比较长。

TCP的流量控制

• 一般来说，我们总是希望数据传输得更快一些。
  • 但如果发送方把数据发送得过快，接收方就可能来不及接收，这就会造成数据的丢失。
• 所谓流量控制（flow control）就是让发送方的发送速率不要太快，要让接收方来得及接收。
• 利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。
  • TCP接收方利用自己的接收窗口的大小来限制发送方发送窗口的大小。
  • TCP发送方收到接收方的零窗口通知后，应启动持续计时器。持续计时器超时后，向接收方发送零窗口探测报文。

TCP的拥塞控制

• 在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏。这种情况就叫做拥塞（congestion）。
  • 在计算机网络中的链路容量（即带宽）、交换结点中的缓存和处理机等，都是网络的资源。
• 若出现拥塞而不进行控制，整个网络的吞吐量将随输入负荷的增大而下降。

拥塞控制算法

下面介绍四种拥塞控制算法的基本原理，假定如下条件：

1. 数据是单方向传送，而另一个方向只传送确认。
2. 接收方总是有足够大的缓存空间，因而发送方发送窗口的大小由网络的拥塞程度来决定。
3. 以最大报文段MSS的个数为讨论问题的单位，而不是以字节为单位。

• 发送方维护一个叫做拥塞窗口cwnd的状态变量，其值取决于网络的拥塞程度，并且动态变化。
  • 拥塞窗口cwnd的维护原则：只要网络没有出现拥塞，拥塞窗口就再增大一些；但只要网络出现拥塞，拥塞窗口就减少一些。
  • 判断出现网络拥塞的依据：没有按时收到应当到达的确认报文（即发生超时重传）。
• 发送方将拥塞窗口作为发送窗口swnd，即swnd＝cwnd。
• 维护一个慢开始门限ssthresh状态变量：
  • 当cwnd＜ssthresh时，使用慢开始算法；
  • 当cwnd＞ssthresh时，停止使用慢开始算法而改用拥塞避免算法：
  • 当cwnd＝ssthresh时，既可使用慢开始算法，也可使用拥塞避免算法。

慢开始（slow-star）和拥塞避免（congestion avoidance）

• “慢开始”是指一开始向网络注入的报文段少，并不是指拥塞窗口cwnd增长速度慢；
• “拥塞避免”并非指完全能够避免拥塞，而是指在拥塞避免阶段将拥塞窗口控制为按线性规律增长，使网络比较不容易出现

快重传（fast retransmit）和快恢复（fast recovery）

• 慢开始和拥塞避免算法是1988年提出的TCP拥塞控制算法（TCP Tahoe版本）ا
• 1990年又增加了两个新的拥塞控制算法（改进TCP的性能），这就是快重传和快恢复（TCP Reno版本）
  • 有时，个别报文段会在网络中丢失，但实际上网络并未发生拥塞。
    • 这将导致发送方超时重传，并误认为网络发生了拥塞；
    • 发送方把拥塞窗口cwnd又设置为最小值1，并错误地启动慢开始算法，因而降低了传输效率。

快重传算法

• 采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失。
• 所谓快重传，就是使发送方尽快进行重传，而不是等超时重传计时器超时再重传。
  • 要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认
  • 即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。
  • 发送方一旦收到3个连续的重复确认，就将相应的报文段立即重传，而不是等该报文段的超时重传计时器超时再重传。
  • 对于个别丢失的报文段，发送方不会出现超时重传，也就不会误认为出现了拥塞（进而降低拥塞窗口cwnd为1），使用快重传可以使整个网络的吞吐量提高约20%。

快恢复算法

• 发送方一旦收到3个重复确认，就知道现在只是丢失了个别的报文段。于是不启动慢开始算法，而执行快恢复算法
  • 发送方将慢开始门限ssthresh值和拥塞窗口cwnd值调整为当前窗口的一半；开始执行拥塞避免算法。
  • 也有的快恢复实现是把快恢复开始时的拥塞窗口cwnd值再增大一些，即等于新的ssthresh＋3。
    • 既然发送方收到3个重复的确认，就表明有3个数据报文段已经离开了网络：
    • 这3个报文段不再消耗网络资源而是停留在接收方的接收缓存中；
    • 可见现在网络中不是堆积了报文段而是减少了3个报文段。因此可以适当把拥塞窗口扩大些。

TCP超时重传时间的选择

• 超时重传时间的选择是TCP最复杂的问题之一
  • 超时重传时间RTO小于往返时间RTT，会引起报文段不必要的重传，使网络负荷增大。
  • 超时重传时间RTO的值远大于往返时间RTT，会使网络的空闲时间增大，降低了传输效率。
  • 综合以上两种情况可以得出，超时重传时间RTO的值应略大于往返时间RTT的值。
• 不能直接使用某次测量得到的RTT样本来计算超时重传时间RTO。（网络传输速率不是固定不变的，RTT这事潘子你把握不住
  

加权平均往返时间RTTs

• 利用每次测量得到的RTT样本，计算加权平均往返时间RTTs（又称为平滑的往返时间）。
  • 起初，RTTs1=RTT1,
  • 之后的更新公式为：新的RTTs = (1-α)x 旧的RTTs + α x 新的RTT样本
  • 在上式中，0≤a＜1：
    • 若α很接近于0，则新RTT样本对RTTs的影响不大；
    • 若a很接近于1，则新RTT样本对RTTs的影响较大；
  • 已成为建议标准的RFC6298推荐的α值为1/8，即0.125。
• 用这种方法得出的加权平均往返时间RTTs就比测量出的RTT值更加平滑。
• 显然，超时重传时间RTO应略大于加权平均往返时间RTTs。

RFC6298建议的超时重传时间RTO计算方法

可以发现，RTTs和RTTD都是基于新的RTT样本进行计算的，如果测量到的样本不正确，那么计算出来的数值也不正确。然而往返时间RTT的测量是比较复杂的。

从上图可以看出，当出现超时重传后，主机无法准确测量RTT。

karn算法及其修正

• 针对出现超时重传时无法测准往返时间RTT的问题，Karn提出了一个算法：在计算加权平均往返时间RTTs时，只要报文段重传了，就不采用其往返时间RTT样本。也就是出现重传时，不重新计算RTTs，进而超时重传时间RTO也不会重新计算。
  • 这又引起了新的问题。设想出现这样的情况：报文段的时延突然增大了很多，并且之后很长一段时间都会保持这种时延。因此在原来得出的重传时间内，不会收到确认报文段。于是就重传报文段。但根据Karn算法，不考虑重传的报文段的往返时间样本。这样，超时重传时间就无法更新。这会导致报文段反复被重传。
• 因此，要对Karn算法进行修正。方法是：报文段每重传一次，就把超时重传时间RTO增大一些。典型的做法是将新RTO的值取为旧RTO值的2倍。

TCP可靠传输的实现

TCP基于以字节为单位的滑动窗口来实现可靠传输

（还有一个图没放上来，主要就是说接收方收到失序的数据，比如说当前想要31–51号的数据，但是收到了32和33，也就是31丢了。接收方不高兴了，说爷的31去哪了，于是发送ack给发送方。发送方收到后视若无睹，因为真正的程序员从来不看warning收到三次相同的重传请求才会进行重传，感觉可能缺失的数据堵路上啥的，这不一定是咱的问题啊，于是就继续发送后面的数据。过了一会接收方收到了它最爱的31号数据，很开心地告诉发送方自己收到了，发送ack说要34号数据。于是移动自己的滑动窗口，把31-33号数据交付给上层，然后把这些数据从自己的缓存里拉出来移出。接收方知道了发送方已经收到31-33号数据了，同样地移动滑动窗口，移出数据。如果发送方把自己滑动窗口内的所有数据都发送出去了，在收到接收方的确认之前都不会再移动窗口和发送数据。如果发送方一直等不到接收方的确认，就会生气超时重传，重新发送窗口内的数据。

知道为啥我不放图了吗，因为动画实在是太多了

• 虽然发送方的发送窗口是根据接收方的接收窗口设置的，但在同一时刻，发送方的发送窗口并不总是和接收方的接收窗口一样大。
  • 网络传送窗口值需要经历一定的时间滞后，并且这个时间还是不确定的。
  • 发送方还可能根据网络当时的拥塞情况适当减小自己的发送窗口尺寸。
• 对于不按序到达的数据应如何处理，TCP并无明确规定。
  • 如果接收方把不按序到达的数据一律丢弃，那么接收窗口的管理将会比较简单，但这样做对网络资源的利用不利，因为发送方会重复传送较多的数据。
  • TCP通常对不按序到达的数据是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。
• TCP要求接收方必须有累积确认和捎带确认机制，这样可以减小传输开销。接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上。
  • 接收方不应过分推迟发送确认，否则会导致发送方不必要的超时重传，这反而浪费了网络的资源。
  • TCP标准规定，确认推迟的时间不应超过0.5秒。若收到一连串具有最大长度的报文段，则必须每隔一个报文段就发送一个确认［RFC 1122］。
  • 捎带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据。
• TCP的通信是全双工通信。通信中的每一方都在发送和接收报文段。因此，每一方都有自己的发送窗口和接收窗口。在谈到这些窗口时，一定要弄清楚是哪一方的窗口。

TCP的运输连接管理

• TCP是面向连接的协议，它基于运输连接来传送TCP报文段。
• TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。
• TCP运输连接有以下三个阶段：
  1. “三报文握手”建立TCP连接
  2. 数据传送
  3. “四报文挥手”释放TCP连接
• TCP的运输连接管理就是使运输连接的建立和释放都能正常地进行。

TCP的连接建立

• TCP的连接建立要解决以下三个问题：
  1. 使TCP双方能够确知对方的存在；
  2. 使TCP双方能够协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等）；
  3. 使TCP双方能够对运输实体资源（如缓存大小、连接表中的项目等）进行分配。

“三报文握手”建立连接过程

假设两台要基于TCP进行通信的主机，其中一台主机中的某应用进程主动发起TCP连接建立，称为TCP客户，另一台主机中被动等待TCP连接建立的应用进程，称为TCP服务器。我们可以将TCP建立连接的过程比喻为握手，握手需要在TCP客户和服务器之间交换三个TCP报文段。

最初，两端的TCP进程都处于关闭状态。一开始，TCP服务器进程首先创建传输控制块，用来存储TCP连接中的一些重要信息，例如TCP连接表、指向发送和接收缓存的指针、指向重传队列的指针、当前发送和接收序号等。之后，就准备接受TCP客户进程的连接请求。此时，TCP服务器进程就进入监听状态，等待TCP客户进程的连接请求。TCP服务器进程是被动等待来自TCP客户进程的连接请求，而不是主动发起。因此称为被动打开连接。

TCP客户进程也是首先创建传输控制块，然后在打算建立TCP连接时向TCP服务器进程发送TCP连接请求报文段，并进入同步已发送状态。TCP连接请求报文段首部中的同步位SYN被设置为1，表明这是一个TCP连接请求报文段。序号字段seq被设置为一个初始值x作为TCP客户进程所选择的初始序号。请注意：TCP规定SYN被设置为1的报文段不能携带数据，但要消耗掉一个序号。由于TCP连接建立是由TCP客户进程主动发起的，因此称为主动打开连接。

TCP服务器进程收到TCP连接请求报文段后，如果同意建立连接，则向TCP客户进程发送TCP连接请求确认报文段，并进入同步已接收状态。该报文段首部中的同步位SYN和确认位ACK都设置为1，表明这是一个TCP连接请求确认报文段。序号字段seq被设置为一个初始值y作为TCP服务器进程所选择的初始序号。确认号字段ack的值被设置成了x+1，这是对TCP客户进程所选择的初始序号的确认。请注意：这个报文段也不能携带数据，因为它是SYN被设置为1的报文段，但同样要消耗掉一个序号。

TCP客户进程收到TCP连接请求确认报文段后，还要向TCP服务器进程发送一个普通的TCP确认报文段，并进入连接已建立状态。该报文段首部中的确认位ACK被设置为1，表明这是一个普通的TCP确认报文段。序号字段seq被设置为x+1，这是因为TCP客户进程发送的第一个TCP报文段的序号为x，并且不携带数据，因此第二个报文段的序号为x+1。请注意：TCP规定普通的TCP确认报文段可以携带数据。但如果不携带数据，则不消耗序号。在这种情况下，所发送的下一个数据报文段的序号仍是x+1。确认号字段ack被设置为y+1，这是对TCP服务器进程所选择的初始序号的确认。

TCP服务器进程收到该确认报文段后，也进入连接已建立状态。现在，TCP双方都进入了连接已建立状态，它们可以基于已建立好的TCP连接进行可靠的数据传输了。

“两报文握手”不可行的原因

假设使用两报文握手，此时TCP客户端进程一开始发送了一个TCP请求报文，但是由于网络状态不佳没有及时发送出去，TCP客户端进程按捺不住超时重传TCP报文，之后TCP服务器进程顺利收到了该TCP报文，于是快快乐乐地建立连接、传输数据、释放连接。此时最开始的怨种TCP报文弯弯绕绕终于到达了TCP服务器，之后TCP服务器以为还要再来一次，告诉TCP客户端进程派大星我们去抓水母吧！我准备好了我准备好了自己进入已连接状态，TCP客户端进程觉得莫名其妙进入章鱼哥状态不予理睬。这个时候TCP服务器进程一直星星眼地等待TCP客户端进程发送数据但是到头来只是一个舔狗罢了，导致TCP服务器进程被伤透了心资源被大量浪费。

综上所述，努力的结果可能只是让事情变得更糟采用三报文握手而不是两报文握手来建立TCP连接，是为了防止世界上多一个怨种已失效的连接请求报文段突然又传送到了TCP服务器进程，因而导致错误。

TCP的连接释放

“四报文挥手”释放连接过程

假设TCP客户进程的应用进程通知其主动关闭TCP连接，TCP客户进程会发送TCP连接释放报文段，并进入终止等待1状态。该报文段首部中的终止位FIN和确认位ACK的值都被设置为1，表明这是一个TCP连接释放报文段，同时也对之前收到的报文段进行确认。序号seq字段的值设置为u，它等于TCP客户进程之前已传送过的数据的最后一个字节的序号+1。请注意：TCP规定终止位FIN等于1的报文段即使不携带数据，也要消耗掉一个序号。确认号ack字段的值设置为v，它等于TCP客户进程之前已收到的数据的最后一个字节的序号+1。

太长不看：TCP客户进程不想喜欢TCP服务器进程了，发脾气了

TCP服务器进程收到TCP连接释放报文段后，会发送一个普通的TCP确认报文段并进入关闭等待状态。该报文段首部中的确认位ACK的值被设置为1，表明这是一个普通的TCP确认报文段。序号seq字段的值设置为v，它等于TCP服务器进程之前已传送过的数据的最后一个字节的序号+1。这也与之前收到的TCP连接释放报文段中的确认号匹配。确认号ack字段的值设置为u+1，这是对TCP连接释放报文段的确认。TCP服务器进程这时应通知高层应用进程：TCP用户进程要断开与自己的TCP连接。此时，从TCP客户进程到TCP服务器进程这个方向的连接就释放了。

太长不看：TCP服务器进程知道人家不开心，去哄人家，但是人家是个直男让TCP客户进程更生气了，于是TCP客户进程直接和TCP服务器进程冷战了

这时的TCP连接处于半关闭状态，也就是TCP客户进程已经没有数据要发送了，但TCP服务器进程如果还有数据要发送，TCP客户进程仍要接收。也就是说，从TCP服务器进程到TCP客户进程这个方向的连接并未关闭。这个状态可能会持续一段时间。TCP客户进程收到TCP确认报文段后，就进入终止等待2状态。等待TCP服务器进程发出的TCP连接释放报文段。

太长不看：虽然TCP客户进程和TCP服务器进程冷战了，但是还没删联系方式，TCP服务器进程还能骚扰人家。TCP客户进程就等这个b啥时候能结束

若使用TCP服务器进程的应用进程已经没有数据要发送了，应用进程就通知其服务器进程释放连接。由于TCP连接释放是由TCP客户进程主动发起的，因此TCP服务器进程对TCP连接的释放称为被动关闭连接。TCP服务器进程发送TCP连接释放报文段并进入最后确认状态，该报文段首部中的终止位FIN和确认位ACK的值都被设置为1，表明这是一个TCP连接释放报文段，同时也对之前收到的报文段进行确认。现在假定seq字段的值为w。这时因为在半关闭状态下TCP服务器进程可能又发送了一些数据。确认号ack字段的值为u+1，这是对之前收到的TCP连接释放报文段的重复确认。

太长不看：TCP服务器进程骚扰不动了，累了，说咱就这样吧

TCP客户进程收到TCP连接释放报文段后，必须针对该报文段发送普通的TCP确认报文段，之后进入时间等待状态。该报文段首部中的确认位ACK的值被设置为1，表明这是一个普通的TCP确认报文段。序号seq字段的值设置为u+1，这是因为TCP客户进程之前发送的TCP连接释放报文段虽然不携带数据，但要消耗掉一个序号。确认号ack字段的值设置为w+1，这时对所收到的TCP连接释放报文段的确认。TCP服务器进程收到该报文段后，就进入关闭状态。

太长不看：TCP客户进程答应了，TCP服务器进程感觉没有挽回余地了就撤了准备投入下一个应用进程的怀抱（不是

而TCP客户进程还要经过两倍的MSL后才能进入关闭状态。MSL的意思是最长报文段寿命，RFC793文档建议为两分钟。也就是说TCP客户进程进入时间等待状态后，还要经过四分钟才能进入关闭状态，这完全是从工程上来考虑的。对于现在的网络，MSL取为2分钟可能太长，因此TCP允许不同的时限，可根据具体情况使用更小的MSL值。

太长不看：TCP客户进程以为对方会挽留自己，等啊等啊等啊等，结果发现自己只是个怨种，也不干了投入下一个TCP服务器进程的怀抱（没有

设置时间等待状态的原因

如果TCP客户进程没有设置停止等待时间也就是不存对方来挽留自己的幻想，如果在TCP服务器进程处于最后确认时期，TCP客户进程发送的TCP确认报文丢失了也就是TCP服务器进程没有等来对方的回应。这时TCP客户进程已经另寻新欢进入关闭状态，而TCP服务器进程一直在苦苦地等待回应，不停地骚扰人家超时重传，但是TCP客户进程想着哪来的舔狗真下头不对该报文段进行回应，而TCP服务进程一直无法进入关闭状态。

所以舔狗不得house

因此，时间等待状态以及处于该状态2倍MSL的时长可以确保TCP服务器进程可以收到最后一个TCP确认报文段而进入关闭状态。另外，TCP客户进程在发送完最后一个TCP确认报文段后，再经过2MSL时长就可以使本次连接持续时间内所产生的所有报文段都从网络中消失，这样就可以使下一个新的TCP连接中不会出现旧连接中的报文段。

保活计时器

设想一种情况：TCP双方已经建立了连接，后来TCP客户进程所在的主机突然出现了故障。显然，TCP服务器进程以后就不能再收到TCP客户进程发来的数据。因此，应当有措施使TCP服务器进程不要再白白等待下去。换句话说，TCP服务器进程应该如何发现这种情况？方法就是使用保活计时器。

• TCP服务器进程每收到一次TCP客户进程的数据，就重新设置并启动保活计时器（2小时定时）
• 若保活计时器定时周期内未收到TCP客户进程发来的数据，则当保活计时器到时后，TCP服务器进程就向TCP客户进程发送一个探测报文段，以后则每隔75秒钟发送一次。若一连发送10个探测报文段后仍无TCP客户进程的响应，TCP服务器进程就认为TCP客户进程所在主机出了故障，接着就关闭这个连接。

也就是定期检测对方还活着，如果没有就赶紧跑路吧不要在一棵树上吊死

TCP报文段的首部格式

• 为了实现可靠传输，TCP采用了面向字节流的方式。
• 但TCP在发送数据时，是从发送缓存取出一部分或全部字节并给其添加一个首部使之成为TCP报文段后进行发送。
  • 一个TCP报文段由首部和数据载荷两部分构成；
  • TCP的全部功能都体现在它首部中各字段的作用。

源端口字段

• 占16比特，写入源端口号
• 用来标识发送该TCP报文段的应用进程。

目的端口字段

• 目的端口：占16比特，写入目的端口号
• 用来标识接收该TCP报文段的应用进程。

序号字段

• 占32比特，取值范围$[0,2^{32}—1]$，序号增加到最后一个后，下一个序号就又回到0。指出本TCP报文段数据载荷的第一个字节的序号。
  

确认号字段

• 占32比特，取值范围$[0,2^{32}—1]$，确认号增加到最后一个后，下一个确认号就又回到0。
• 指出期望收到对方下一个TCP报文段的数据载荷的第一个字节的序号，同时也是对之前收到的所有数据的确认。
• 若确认号=n，则表明到序号n-1为止的所有数据都已正确接收，期望接收序号为n的数据。

确认标志位ACK字段

• 取值为1时确认号字段才有效；取值为0时确认号字段无效。
• TCP规定，在连接建立后所有传送的TCP报文段都必须把ACK置1。

数据偏移字段

• 占4比特，并以4字节为单位。
• 用来指出TCP报文段的数据载荷部分的起始处距离TCP报文段的起始处有多远。
• 这个字段实际上是指出了TCP报文段的首部长度。
  • 首部固定长度为20字节，因此数据偏移字段的最小值为$(0101)_2$
  • 首部最大长度为60字节，因此数据偏移字段的最大值为$(1111)_2$

保留字段

• 占6比特，保留为今后使用，但目前置为0

果然人类都是喜欢为不确定的未来做点确定的无用功

窗口字段

• 占16比特，以字节为单位。指出发送本报文段的一方的接收窗口。
• 窗口值作为接收方让发送方设置其发送窗口的依据。
• 这是以接收方的接收能力来控制发送方的发送能力，称为流量控制。

（发送窗口的大小还取决于拥塞窗口的大小，取接收窗口和拥塞窗口的小者

校验和字段

• 占16比特，检查范围包括TCP报文段的首部和数据载荷两部分。
• 在计算校验和时，要在TCP报文段的前面加上12字节的伪首部。

同步标志位SYN

• 在TCP连接建立时用来同步序号

终止标志位FIN

用来释放TCP连接

复位标志位RST

• 用来复位TCP连接。
• 当RST=1时，表明TCP连接出现了异常，必须释放连接，然后再重新建立连接。
• RST置1还用来拒绝一个非法的报文段或拒绝打开一个TCP连接。

推送标志位PSH

接收方的TCP收到该标志位为1的报文段会尽快上交应用进程，而不必等到接收缓存都填满后再向上交付。

紧急标志位URG、紧急指针字段

用于实现紧急操作

• 紧急标志位URG：取值为1时紧急指针字段有效；取值为0时紧急指针字段无效。
• 紧急指针：占16比特，以字节为单位，用来指明紧急数据的长度。

当发送方有紧急数据时，可将紧急数据插队到发送缓存的最前面，并立刻封装到一个TCP报文段中进行发送。紧急指针会指出本报文段数据载荷部分包含了多长的紧急数据，紧急数据之后是普通数据。

接收方收到紧急标志为1的报文段，会按照紧急指针字段的值从报文段数据载荷部分取出紧急数据，并直接上交应用进程，而不必在接收缓存中排队。

选项字段

增加选项可以增加TCP的功能，目前有以下选项：

• 最大报文段长度MSS选项：用于指出TCP报文段数据载荷部分的最大长度。
• 窗口扩大选项：为了扩大窗口（提高吞吐率）。
• 时间戳选项：
  • 用来计算往返时间RTT
  • 用于处理序号超范围的情况，又称为防止序号绕回PAWS。
• 选择确认选项：用来实现选择确认功能。

填充字段

由于选项的长度可变，因此使用填充来确保报文段首部能被4整除（因为数据偏移字段，也就是首部长度字段，是以4字节为单位的）。