网络带宽是指在单位时间（或猜一般指的是1秒钟）内能传输的数据量。网络和高速公路类似，带宽越大，就类似高速公路的车道越多友橡，其通行能力越强。网络带宽作为衡量网络特征的一个重要指标，日益受到人们的普遍关注。它不仅是政府或单位制订网络通信发展策略的重要依据，也是互联网用户和单位选择互联网接入服务商的主要因素之一。所谓带宽，是“频带宽度”的简称，原是通讯和电子技术中的一个术语，指通讯线路或设备所能传送信号的范围。而网络中的带宽是指在规定时间内从一端流到另一端的信息量，即数据传输率。带宽对模拟信号和数字信号有两种基本的应用，在本文中所说的带宽衫告型均是指数字信号。
Ⅱ 计网：运输层
本篇文章先概括介绍运输层协议的特点、进程之间的通信和端口等重要概念，然后讲述比较简单的UDP协议。然后讨论较为复杂但非常重要的TCP协议和可靠传输的工作原理，包括停止等待协议和ARQ协议。在详细讲述TCP报文段的首部格式之后，讨论TCP的三个重要问题：滑动窗口、流量控制和拥塞控制机制。最后，介绍TCP的连接管理。
从通信和信息处理的角度看，运输层向它上面的应用层提供通信服务，它属于面向通信部分的最高层，同时也是用户功能中的最低层。
当网络的边缘部分中的两台主机使用网络 的核心部分的功能进行端到端的通信时，只有主机的协议栈才有运输层，而网络核心部分中的路由器在转发分组时都只用到下三层的功能。
运输层有一个很重要的功能 复用和分用：
从IP层来说，通信的两端是两台主机。但实际上，真正进行通信的实体是 在主机中的进程，是这台主机中的一个进程和另一台主机中的一个进程在交换数据(即通信)。运输层提供应用进程间的逻辑通信。“逻辑通信”的意思是：从应用层来看，只要把应用层报文交给下面的运输层， 运输层就可以把这报文传送到对方的运输层。但事实上这两个运输层之间并没有一条水平方向的物理连接。数据的传送是沿着图中的虚线方向（经过多个层次）传送的。
从这里可以看出网络层和运输层有明显的区别。网络层为主机之间提供逻辑通信，而运输层为应用进程之间提供端到端的逻辑通信。
运输层还要对收到的报文进行差错检测，而在网络层，IP数据报首部中的检验和字段，只检验首部是否出现差错而不检查数据部分。
根据应用程序的不同需求，运输层需要有两种不同的运输协议，即面向连接的TCP和无连接的UDP,这两种协议就是本章要讨论的主要内容。
当运输层采用面向连接的TCP协议时，尽管下面的网络是不可靠的(只提供尽最大努力服务)，但这种逻辑通信信道就相当于一条全双工的可靠信道。但当运输层釆用无连接的UDP协议时，这种逻辑通信信道仍然是一条不可靠信道。
TCP/IP运输层的两个主要协议都是互联网的正式标准，即：
在TCP/IP体系中，则根据所使用的协议是TCP或 UDP，分别称之为TCP报文段或UDP用户数据报。
UDP在传送数据之前不需要先建立连接。远地主机的运输层在收到UDP报文后，不需要给出任何确认。虽然UDP不提供可靠交付，但在某些情况下UDP却是一种最有效的工作方式。
TCP则提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。TCP不提供广播或多播服务。由于TCP要提供可靠的、面向连接的运输服务，因此不可避免地增加了许多的开销，占用许多处理机资源。
前面己经提到过运输层的复用和分用功能。应用层所有的应用进程都可以通过运输层再传送到IP层（网络层），这就是复用。运输层从IP层收到发送给各应用进程的数据后，必须分别交付指明的各应用进程，这就是分用。显然，给应用层的每个应用进程赋予一个非常明确的标志是至关重要的。
为了使运行不同操作系统的计算机的应用进程能够互相通信，就必须用统一的方法（而这种方法必须与特定操作系统无关）对TCP/IP体系的应用进程进行标志。
解决这个问题的方法就是在运输层使用协议端口号，或通常简称为端口。这就是说，虽然通信的终点是应用进程，但只要把所传送的报文交到目的主机的某个合适的目的端口，剩下的工作（即最后交付目的进程）就由TCP或UDP来完成。
在协议栈层间的抽象的协议端口是软件端口，和路由器或交换机上的硬件端口是完全不同的概念。软件端口是应用层的各种协议进程与运输实体进行层间交互的一种地址。
TCP/IP的运输层用一个16位端口号来标志一个端口。但请注意，端口号只具有本地意义，它只是为了标志本计算机应用层中的各个进程在和运输层交互时的层间接口。在互联网不同计算机中，相同的端口号是没有关联的。
两个计算机中的进程要互相通信，不仅必须知道对方的IP地址（为了找到对方的计算机），而且要知道对方的端口号（为了找到对方计算机中的应用进程）。
因此运输层的端口号分为下面的两大类：
用户数据报协议UDP只在IP的数据报服务之上增加了很少一点的功能，这就是复用和分用的功能以及差错检测的功能。
UDP的主要特点是：
用户数据报UDP有两个字段：数据字段和首部字段。首部字段很简单，只有8个字节。由四个字段组成，每个字段的长度都是两个字节。各字段意义如下：
当运输层从IP层收到UDP数据报时，就根据首部中的目的端口，把UDP数据报通过相应的端口，上交最后的终点——应用进程。
如果接收方UDP发现收到的报文中的目的端口号不正确(即不存在对应于该端口号的应用进程)，就丢弃该报文，并由网际控制报文协议ICMP发送“端口不可达”差错报文给发送方。
UDP用户数据报首部中检验和的计算方法有些特殊。在计算检验和时，要在UDP用户 数据报之前增加12个字节的伪首部。所谓“伪首部”是因为这种伪首部并不是UDP用户数 据报真正的首部。只是在计算检验和时，临时添加在UDP用户数据报前面，得到一个临时的 UDP用户数据报。检验和就是按照这个临时的UDP用户数据报来计算的。伪首部既不向下传
送也不向上递交，而仅仅是为了计算检验和。
UDP计算检验和的方法和计算IP数据报首部检验和的方法相似。但不同的是：IP数据 报的检验和只检验IP数据报的首部，但UDP的检验和是把首部和数据部分一起都检验。
TCP是TCP/IP体系中非常复杂的一个协议，下面介绍TCP最主要的特点：
前面己经讲过，每一条TCP连接有两个端点，TCP连接的端点叫做套接字或插口。端口号拼接到IP地址即 构成了套接字。
因此，套接字的表示方法是在点分十进制的IP地址后面写上端口号，中间用冒号或逗号隔开，例如说：
每一条TCP连接唯一地被通信两端的两个端点(即两个套接字)所确定，例如：
这里IP1和IP2分别是两个端点主机的IP地址，而port1和port2分别是两个端点主机中的端口号。TCP连接的两个套接字就是socket1和socket2。
总之，TCP连接就是由协议软件所提供的一种抽象。
虽然有时为了方便，我们也可以说，在一个应用进程和另一个应用进程之间建立了一条TCP连接，但一定要记住：TCP连 接的端点是个很抽象的套接字，即(IP地址：端口号)。
我们知道，TCP发送的报文段是交给IP层传送的。但IP层只能提供尽最大努力服务，也就是说，TCP下面的网络所提供的是不可靠的传输。因此，TCP必须釆用适当的措施才能使得两个运输层之间的通信变得可靠。
“停止等待”就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。
停止等待协议有以下四种情况：
停止等待协议的优点是简单，但缺点是信道利用率太低。
信道利用率U可以用以下公式计算：
为了提高传输效率，发送方可以不使用低效率的停止等待协议，而是釆用流水线传输，这种传输方式可以获得很高的信道利用率。
滑动窗口协议比较复杂，是TCP协议的精髓所在。这里先给出连续ARQ协议最基本的概念，但不涉及许多细节问题。
发送方维持的发送窗口，它的意义是：位于发送窗口内的分组都可连续发送出去，而不需要等待对方的确认。这样，信道利用率就提高了。
连续ARQ协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。
如果原来己经发送了前5个分组，那么现在就可以发送窗口内的第6个分组了。
接收方一般都是釆用累积确认的方式。这就是说，接收方不必对收到的分组逐个发送 确认，而是在收到几个分组后，对按序到达的最后一个分组发送确认，这就表示：到这个分组为止的所有分组都已正确收到了。
累积确认有优点也有缺点。优点是：容易实现，即使确认丢失也不必重传。但缺点是不能向发送方反映出接收方己经正确收到的所有分组的信息。
如果发送方发送了前5个分组，而中间的第3个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落，而只好把后面的三个分组都再重传一次。这就叫做Go-back-N（回退N）。
TCP虽然是面向字节流的，但TCP传送的数据单元却是报文段。一个TCP报文段分为首部和数据两部分，而TCP的全部功能都体现在它首部中各字段的作用。
TCP报文段首部的前20个字节是固定的，后面有4n字节是根据需要而增加的选项。因此TCP首部的最小长度是20字节。
首部固定部分各字段的意义如下：
TCP的滑动窗口是以字节为单位的。
现假定A收到了 B发来的确认报文段，其中窗口是20字节，而确认号是31（这表明B期望收到的下一个序号是31,而序号30为止的数据已经收到了）。
A的发送窗口表示：在没有收到B的确认的情况下，A可以连续把窗口内的数据都发送出去。凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。
发送窗口后沿的后面部分表示己发送且己收到了确认。发送窗口后沿的变化情况有两种可能，即不动（没有收到新的确认）和前移（收到了新的确认）。
发送窗口里面的序号表示允许发送的序号。窗口越大，发送方就可以在收到对方确认之前连续发送更多的数据，因而可能获得更高的传输效率。但A的发送窗口一定不能超过B的接收窗口数值。
发送窗口前沿的前面部分表示不允许发送的。发送窗口前沿通常是不断向前移动，但也有可能不动。这对应于两种情况：一是没有收到新的确认，对方通知的窗口大小也不变；二是收到了 新的确认但对方通知的窗口缩小了，使得发送窗口前沿正好不动。
现在假定A发送了序号为31〜41的数据。这时，发送窗口位置并未改变， 但发送窗口内靠后面有11个字节（灰色小方框表示）表示己发送但未收到确认。而发送窗口内靠前面的9个字节（42〜50）是允许发送但尚未发送的。
从以上所述可以看出，要描述一个发送窗口的状态需要三个指针：P1，P2和P3，小于P1的是已发送并已收到确认的部分，而大于P3的是不允许发送的部分：
再看一下B的接收窗口。B的接收窗口大小是20。在接收窗口外面，到30号为止的数据是已经发送过确认，并且已经交付主机了。因此在B可以不再保留这些数据。接收窗口内的序号（31〜50）是允许接收的。
此时B收到了序号为32和33的数据。这些数据没有按序到达，因为序号为31的数据没有收到（也许丢失了，也许滞留在网络中的某处）。请注意，B只能对按序收到的数据中的最高序号给出确认，因此B发送的确认报文段中的确认号仍然是31 （即期望收到的序号），而不能是32或33。
现在假定B收到了序号为31的数据，并把序号为31〜33的数据交付主机，然后B删除这些数据。接着把接收窗口向前移动3个序号，同时给A发送确认，其中窗口值仍为20，但确认号是34。这表明B已经收到了到序号33为止的数据。我们注意到，B还收到了序号为37, 38和40的数据，但这些都没有按序到达，只能先暂存在接收窗口中。
A在继续发送完序号42〜53的数据后，指针P2向前移动和P3重合。发送窗口内的序号都已用完，但还没有再收到确认(图5-18)。由于A的发送窗口己满，可用窗口已减小到零，因此必须停止发送。为了保证可靠传输，A只能认为B还没有收到这些数据。于是，A在经过一段时间后(由超时计时器控制)就重传这部分数据，重新设置超时计时器，直到收到B的确认为止。
CP的发送方在规定的时间内没有收到确认就要重传已发送的报文段。这种重传的概念是很简单的，但重传时间的选择却是TCP最复杂的问题之一。
如果把超时重传 时间设置得太短，就会引起很多报文段的不必要的重传，使网络负荷增大。但若把超时重传 时间设置得过长，则又使网络的空闲时间增大，降低了传输效率。
那么，运输层的超时计时器的超时重传时间究竟应设置为多大呢？
TCP釆用了一种自适应算法，它记录一个报文段发出的时间，以及收到相应的确认的 时间。这两个时间之差就是报文段的往返时间RTT。TCP保留了 RTT的一个加权平均往返时间RTT s 。
每当第一次测量到RTT样本时，RTTs值就取为所测量到的RTT样本 值。但以后每测量到一个新的RTT样本，就按下式重新计算一次RTT s ：
显然，超时计时器设置的超时重传时间RTO应略大于上面得 出的加权平均往返时间RTT s ，所以RTO应该这样计算。
而RTT D 是RTT的偏差的加权平均值，它与RTTs和新的RTT样本之差有关。
现在发送出一个报文段，设定的重传时间到了，还没有收到确认。于是重传报文段。经过了一段时间后，收到了确认报文段。现在的问题是：如何判定此确认报文段 是对先发送的报文段的确认，还是对后来重传的报文段的确认？
Kam算法进行修正。方法是：报文段每重传一次，就把超时重传时间RTO增大一些。典型的做法是取新的重传时间为旧的重传时间的2倍。当不再发生报文段的重传时，才根据上面给出的式子计算超时重传时间。
现在还有一个问题没有讨论。这就是若收到的报文段无差错，只是未按序号，中间还缺少一些序号的数据，那么能否设法只传送缺少的数据而不重传已经正确到达接收方的数据？答案是可以的。选择确认就是一种可行的处理方法。
举一个例子来说明选择确认的工作原理。TCP的接收方在接收对方发送过来的数据字节流的序号不连续，结果就形成了一些不连续的字节块。
可以看出，序号1〜1000收到了，但序号1001〜1500没有收到。接下来的字节流又收到了，可是又缺少了3001〜3500。再后面从序号4501起又没有收到。
也就是说，接收方收到了和前面的字节流不连续的两个字节块。如果这些字节的序号都在接收窗口之内，那么接收方就先收下这些数据，但要把这些信息准确地告诉发送方，使发送方不要再重复发送这些已收到的数据。
一般说来，我们总是希望数据传输得更快一些。但如果发送方把数据发送得过快，接 收方就可能来不及接收，这就会造成数据的丢失。所谓流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。
利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。
设A向B发送数据。在连接建立时，B告诉了A：“我的接收窗口rwnd = 400”。因此，发送方的发送窗口不能超过接收方给出的接收窗口的数值。
我们应注意到，接收方的主机B进行了三次流量控制。第一次把窗口减小到rwnd = 300, 第二次又减到rwnd = 100,最后减到rwnd = 0,即不允许发送方再发送数据了。这种使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口值为止。
TCP协议使得在发送方不发送很小的报文段的同时，接收方也不要 在缓存刚刚有了一点小的空间就急忙把这个很小的窗口大小信息通知给发送方。
在计算机网络中的链路容量（即带宽）、交换结点中的缓存和处理机等，都是网络的资源。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫做拥塞，即对资源需求之和 > 可用资源。
网络拥塞往往是由许多因素引起的。简单地将处理机的速率提高或简单地扩大缓存的存储空间，可能会使上述情况缓解一些，但往往又会将瓶颈转移到其他地方。问题的实质往往是整个系统的各个部分不匹配。只有所有的部分都平衡了，问题才会得到解决。
拥塞控制与流量控制的关系密切，它们之间也存在着一些差别。拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。流量控制往往是指点对点通信量的控制，是个端到端的问题（接收端控制发送端）。
下图中横坐标是提供的负载，代表单位时间内输入给网络的分组数目。纵坐标是吞吐量，代表单位时间内从网络输出的分组数目。
实践证明，拥塞控制是很难设计的，因为它是一个动态的(而不是静态的)问题。
从大的方面看，可以分为 开环控制 和 闭环控制 两种方法：
TCP进行拥塞控制的算法有四种，即慢开始、拥塞避免、快重传和快恢复。
为了集中精力讨论拥塞控制，我们假定：
拥塞控制也叫做基于窗口的拥塞控制。为此，发送方维持一个叫做拥塞窗口cwnd的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口。
发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就可以再增大一些，以便把更多的分组发送出去，这样就可以提高网络的利用率。但只要网络出现拥塞或有可能出现拥塞，就必须把拥塞窗口减小一些，以减少注入到网络中的分组数，以便缓解网络出现的拥塞。
发送方又是如何知道网络发生了拥塞呢？我们知道，当网络发生拥塞时，路由器就要丢弃分组。因此只要发送方没有按时收到应当到达的确认报文，也就是说，只要出现了超时，就可以猜想网络可能出现了拥塞。现在通信线路的传输质量一般都很好，因传输出差错而丢弃分组的概率是很小的(远小于1%)。因此，判断网络拥塞的依据就是出现了超时。
慢开始算法的思路是这样的：当主机开始发送数据时，由于并不清楚网络的负荷情况，所以如果立即把大量数据字节注入到网络，那么就有可能引起网络发生拥塞。因此我们由小到大逐渐增大拥塞窗口数值。
新的RFC5681把初始拥塞窗口cwnd设置为不超过2至4个SMSS（发送方的最大报文段）的数值。慢开始规定，在每收到一个对新的报文段的确认后，可以把拥塞窗口增加最多一个SMSS的数值。
下面用例子说明慢开始算法的原理。在一开始发送方先设置cwnd = 1,发送第一个报文段M1，接收方收到后确认M1。发送 方收到对M1的确认后，把cwnd从1增大到2,于是发送方接着发送M2和M3两个报文 段。接收方收到后发回对M2和M3的确认。发送方每收到一个对新报文段的确认（重传的不算在内）就使发送方的拥塞窗口加1,因此发送方在收到两个确认后，cwnd就从2增大到4,并可发送M4〜M7共4个报文段。
与慢开始算法相辅助的算法是拥塞避免算法。
拥塞避免算法的思路是让拥塞窗口 cwnd缓慢地增大，即每经过一个往返时间RTT就 把发送方的拥塞窗口cwnd加1，而不是像慢开始阶段那样加倍增长。在拥塞避免阶段，拥塞窗口 cwnd按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。
为了防止拥塞窗口 cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh 状态变量。慢开始门限ssthresh的用法如下：
下面用图片说明慢开始算法和拥塞避免算法相互配合的原理。
其中ssthresh的初始值设置为16，开始时使用慢开始算法，成指数性增长，当到达ssthresh值时，TCP协议预测可能会出现拥塞，所以开始使用避免拥塞算法，成线性增长，当发生超时重传时，立即减小拥塞窗口，重复上述步骤。
但是，有时，个别报文段会在网络中丢失，但实际上网络并未发生拥塞。如果发送方迟迟收 不到确认，就会产生超时，就会误认为网络发生了拥塞。这就导致发送方错误地启动慢开 始，把拥塞窗口cwnd又设置为1,因而降低了传输效率。
釆用快重传算法可以解决上述问题。快重传算法可以让发送方尽早知道发生了个别报文段的丢失。快重传算法首先要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认，即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。
下面举一个例子来说明快重传算法的原理。接收方收到了M1和M2后都分别及时发出了确认。现假定接收方没有收到M3但却收到了 M4。本来接收方可以什么都不做。但按照快重传算法，接收方必须立即发送对M2的重复确认，以便让发送方及 早知道接收方没有收到报文段M3。发送方接着发送M5和M6。接收方收到后也仍要再次分别发出对M2的重复确认。这样，发送方共收到了接收方的4个对M2的确认，其中后3个都是重复确认。快重传算法规定，发送方只要一连收到3个重复确认，就知道接收方确实没 有收到报文段M3，因而应当立即进行重传（即“快重传”），这样就不会出现超时，发送方也不就会误认为出现了网络拥塞。
快恢复算法与快重传算法配合使用，当使用快重传算法发现是由于数据丢失而引起的超时（不是网络拥塞引起的），就使用快恢复算法，此时发送方调整门限值ssthresh=cwnd/2，同时设置拥塞窗口cwnd=ssthresh，并开始执行拥塞避免算法。
慢开始、拥塞避免、快重传和快恢复这四种算法相辅相成，构成了TCP的拥塞控制。
网络层的策略对TCP拥塞控制影响最大的就是路由器的分组丢弃策略。在最简单的情 况下，路由器的队列通常都是按照“先进先出”的规则处理到来的分组。
由于队列长度总是有限的，因此当队列已满时，以后再到达的所有分组(如果能够继续排队，这些分组都将排在队列的尾部)将都被丢弃。这就叫做尾部丢弃策略。
路由器的尾部丢弃往往会导致一连串分组的丢失，这就使发送方出现超时重传，使 TCP进入拥塞控制的慢开始状态，结果使TCP连接的发送方突然把数据的发送速率降低到 很小的数值。更为严重的是，在网络中通常有很多的TCP连接(它们有不同的源点和终 点)，这些连接中的报文段通常是复用在网络层的IP数据报中传送。在这种情况下，若发生了路由器中的尾部丢弃，就可能会同时影响到很多条TCP连接，结果使这许多TCP连接在同一时间突然都进入到慢开始状态。这在TCP的术语中称为全局同步。
为了避免发生网络中的全局同步现象，可以使用主动队列管理AQM。
所谓“主动”就是不要等到路由器的队列长度已经达到最大值时才不得不丢弃后面到达的分组。这样就太被动了。应当在队列长度达到某个值得警惕的数值时 (即当网络拥塞有了某些拥塞征兆时)，就主动丢弃到达的分组。这样就提醒了发送方放慢发送的速率，因而有可能使网络拥塞的程度减轻，甚至不出现网络拥塞。
TCP是面向连接的协议。运输连接是用来传送TCP报文的。TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。因此，运输连接就有三个阶段，即：连接建立、数据传送和连接释放。运输连接的管理就是使运输连接的建立和释放都能正常地进行。
在TCP连接建立过程中要解决以下三个问题：
TCP连接的建立釆用客户服务器方式。主动发起连接建立的应用进程叫做客户，而被动等待连接建立的应用进程叫做服务器。
TCP建立连接的过程叫做握手，握手需要在客户和服务器之间交换三个TCP报文段。
下面举一个例子来说明TCP建立连接的过程。假定主机A运行的是TCP客户程序，而B运行TCP服务器程序。最初两端的TCP进程都处于CLOSED（关闭）状态。图中在主机下面的方框分别是TCP进程所处的状态。请注意，在本例中，A主动打开连接，而B被动打开连接。
一开始，B的TCP服务器进程先创建传输控制块TCB，准备接受客户进程的连接请求。然后服务器进
Ⅲ 计算机网络自学笔记:TCP
如果你在学习这门课程，仅仅为了理解网络工作原理，那么只要了解TCP是可靠传输，数据传输丢失时会重传就可以了。如果你还要参加研究生考试或者公司面试等，那么下面内容很有可能成为考查的知识点，主要的重点是序号/确认号的编码、超时定时器的设置、可靠传输和连接的管理。
1 TCP连接
TCP面向连接，在一个应用进程开始向另一个应用进程发送数据之前，这两个进程必须先相互“握手”，即它们必须相互发送某些预备报文段，以建立连接。连接的实质是双方都初始化与连接相关的发送/接收缓冲区，以及许多TCP状态变量。
这种“连接”不是一条如电话网络中端到端的电路，因为它们的状态完全保留在两个端系统中。
TCP连接提供的是全双工服务 ，应用层数据就可在从进程B流向进程A的同时，也从进程A流向进程B。
TCP连接也总是点对点的 ，即在单个发送方与单个接收方之间建立连接。
一个客户机进程向服务器进程发送数据时，客户机进程通过套接字传递数据流。
客户机操作系统中运行的 TCP软件模块首先将这些数据放到该连接的发送缓存里 ，然后会不时地从发送缓存里取出一块数据发送。
TCP可从缓存中取出并放入报文段中发送的数据量受限于最大报文段长MSS，通常由最大链路层帧长度来决定(也就是底层的通信链路决定)。 例如一个链路层帧的最大长度1500字节，除去数据报头部长度20字节，TCP报文段的头部长度20字节，MSS为1460字节。
报文段被往下传给网络层，网络层将其封装在网络层IP数据报中。然后这些数据报被发送到网络中。
当TCP在另一端接收到一个报文段后，该报文段的数据就被放人该连接的接收缓存中。应用程序从接收缓存中读取数据流(注意是应用程序来读，不是操作系统推送)。
TCP连接的每一端都有各自的发送缓存和接收缓存。
因此TCP连接的组成包括:主机上的缓存、控制变量和与一个进程连接的套接字变量名，以及另一台主机上的一套缓存、控制变量和与一个进程连接的套接字。
在这两台主机之间的路由器、交换机中，没有为该连接分配任何缓存和控制变量。
2报文段结构
TCP报文段由首部字段和一个数据字段组成。数据字段包含有应用层数据。
由于MSS限制了报文段数据字段的最大长度。当TCP发送一个大文件时，TCP通常是将文件划分成长度为MSS的若干块。
TCP报文段的结构。
首部包括源端口号和目的端口号，它用于多路复用/多路分解来自或送至上层应用的数据。另外，TCP首部也包括校验和字段。报文段首部还包含下列字段:
32比特的序号字段和32比特的确认号字段。这些字段被TCP发送方和接收方用来实现可靠数据传输服务。
16比特的接收窗口字段，该字段用于流量控制。该字段用于指示接收方能够接受的字节数量。
4比特的首部长度字段,该字段指示以32比特的字为单位的TCP首部长度。一般TCP首部的长度就是20字节。
可选与变长的选项字段,该字段用于当发送方与接收方协商最大报文段长度，或在高速网络环境下用作窗口调节因子时使用。
标志字段ACK比特用于指示确认字段中的ACK值的有效性，即该报文段包括一个对已被成功接收报文段的确认。 SYN和FIN比特用于连接建立和拆除。 PSH、URG和紧急指针字段通常没有使用。
•序号和确认号
TCP报文段首部两个最重要的字段是序号字段和确认号字段。
TCP把数据看成一个无结构的但是有序的字节流。TCP序号是建立在传送的字节流之上，而不是建立在传送的报文段的序列之上。
一个报文段的序号是该报文段首字节在字节流中的编号。
例如，假设主机A上的一个进程想通过一条TCP连接向主机B上的一个进程发送一个数据流。主机A中的TCP将对数据流中的每一个字节进行编号。假定数据流由一个包含4500字节的文件组成(可以理解为应用程序调用send函数传递过来的数据长度)，MSS为1000字节(链路层一次能够传输的字节数)，如果主机决定数据流的首字节编号是7。TCP模块将为该数据流构建5个报文段(也就是分5个IP数据报)。第一个报文段的序号被赋为7;第二个报文段的序号被赋为1007,第三个报文段的序号被赋为2007，以此类推。前面4个报文段的长度是1000，最后一个是500。
确认号要比序号难理解一些。前面讲过，TCP是全双工的，因此主机A在向主机B发送数据的同时，也可能接收来自主机B的数据。从主机B到达的每个报文段中的序号字段包含了从B流向A的数据的起始位置。 因此主机B填充进报文段的确认号是主机B期望从主机A收到的下一报文段首字节的序号。
假设主机B已收到了来自主机A编号为7-1006的所有字节，同时假设它要发送一个报文段给主机A。主机B等待主机A的数据流中字节1007及后续所有字节。所以，主机B会在它发往主机A的报文段的确认号字段中填上1007。
再举一个例子，假设主机B已收到一个来自主机A的包含字节7-1006的报文段，以及另一个包含字节2007-3006的报文段。由于某种原因，主机A还没有收到字节1007-2006的报文段。
在这个例子中，主机A为了重组主机B的数据流，仍在等待字节1007。因此，A在收到包含字节2007-3006的报文段时，将会又一次在确认号字段中包含1007。 因为TCP只确认数据流中至第一个丢失报文段之前的字节数据，所以TCP被称为是采用累积确认。
TCP的实现有两个基本的选择:
1接收方立即丢弃失序报文段;
2接收方保留失序的字节，并等待缺少的字节以填补该间隔。
一条TCP连接的双方均可随机地选择初始序号。 这样做可以减少将那些仍在网络中的来自两台主机之间先前连接的报文段，误认为是新建连接所产生的有效报文段的可能性。
•例子telnet
Telnet由是一个用于远程登录的应用层协议。它运行在TCP之上，被设计成可在任意一对主机之间工作。
假设主机A发起一个与主机B的Telnet会话。因为是主机A发起该会话，因此主机A被标记为客户机，主机B被标记为服务器。用户键入的每个字符(在客户机端)都会被发送至远程主机。远程主机收到后会复制一个相同的字符发回客户机，并显示在Telnet用户的屏幕上。这种“回显”用于确保由用户发送的字符已经被远程主机收到并处理。因此，在从用户击键到字符显示在用户屏幕上之间的这段时间内，每个字符在网络中传输了两次。
现在假设用户输入了一个字符“C”，假设客户机和服务器的起始序号分别是42和79。前面讲过，一个报文段的序号就是该报文段数据字段首字节的序号。因此，客户机发送的第一个报文段的序号为42，服务器发送的第一个报文段的序号为79。前面讲过，确认号就是主机期待的数据的下一个字节序号。在TCP连接建立后但没有发送任何数据之前，客户机等待字节79，而服务器等待字节42。
如图所示，共发了3个报文段。第一个报文段是由客户机发往服务器，其数据字段里包含一字节的字符“C”的ASCII码，其序号字段里是42。另外，由于客户机还没有接收到来自服务器的任何数据，因此该报文段中的确认号字段里是79。
第二个报文段是由服务器发往客户机。它有两个目的:第一个目的是为服务器所收到的数据提供确认。服务器通过在确认号字段中填入43，告诉客户机它已经成功地收到字节42及以前的所有字节，现在正等待着字节43的出现。第二个目的是回显字符“C”。因此，在第二个报文段的数据字段里填入的是字符“C”的ASCII码，第二个报文段的序号为79，它是该TCP连接上从服务器到客户机的数据流的起始序号，也是服务器要发送的第一个字节的数据。
这里客户机到服务器的数据的确认被装载在一个服务器到客户机的数据的报文段中，这种确认被称为是捎带确认.
第三个报文段是从客户机发往服务器的。它的唯一目的是确认已从服务器收到的数据。
3往返时延的估计与超时
TCP如同前面所讲的rdt协议一样，采用超时/重传机制来处理报文段的丢失问题。最重要的一个问题就是超时间隔长度的设置。显然，超时间隔必须大于TCP连接的往返时延RTT，即从一个报文段发出到收到其确认时。否则会造成不必要的重传。
•估计往返时延
TCP估计发送方与接收方之间的往返时延是通过采集报文段的样本RTT来实现的，就是从某报文段被发出到对该报文段的确认被收到之间的时间长度。
也就是说TCP为一个已发送的但目前尚未被确认的报文段估计sampleRTT，从而产生一个接近每个RTT的采样值。但是，TCP不会为重传的报文段计算RTT。
为了估计一个典型的RTT，采取了某种对RTT取平均值的办法。TCP据下列公式来更新
EstimatedRTT=(1-)*EstimatedRTT+*SampleRTT
即估计RTT的新值是由以前估计的RTT值与sampleRTT新值加权组合而成的。
参考值是a=0.125，因此是一个加权平均值。显然这个加权平均对最新样本赋予的权值
要大于对老样本赋予的权值。因为越新的样本能更好地反映出网络当前的拥塞情况。从统计学观点来讲，这种平均被称为指数加权移动平均
除了估算RTT外，还需要测量RTT的变化，RTT偏差的程度，因为直接使用平均值设置计时器会有问题(太灵敏)。
DevRTT=(1-β)*DevRTT+β*|SampleRTT-EstimatedRTT|
RTT偏差也使用了指数加权移动平均。B取值0.25.
•设置和管理重传超时间隔
假设已经得到了估计RTT值和RTT偏差值，那么TCP超时间隔应该用什么值呢?TCP将超时间隔设置成大于等于估计RTT值和4倍的RTT偏差值,否则将造成不必要的重传。但是超时间隔也不应该比估计RTT值大太多，否则当报文段丢失时，TCP不能很快地重传该报文段，从而将给上层应用带来很大的数据传输时延。因此，要求将超时间隔设为估计RTT值加上一定余量。当估计RTT值波动较大时，这个余最应该大些;当波动比较小时，这个余量应该小些。因此使用4倍的偏差值来设置重传时间。
TimeoutInterval=EstimatedRTT+4*DevRTT
4可信数据传输
因特网的网络层服务是不可靠的。IP不保证数据报的交付，不保证数据报的按序交付，也不保证数据报中数据的完整性。
TCP在IP不可靠的尽力而为服务基础上建立了一种可靠数据传输服务。
TCP提供可靠数据传输的方法涉及前面学过的许多原理。
TCP采用流水线协议、累计确认。
TCP推荐的定时器管理过程使用单一的重传定时器，即使有多个已发送但还未被确认的报文段也一样。重传由超时和多个ACK触发。
在TCP发送方有3种与发送和重传有关的主要事件:从上层应用程序接收数据，定时器超时和收到确认ACK。
从上层应用程序接收数据。一旦这个事件发生，TCP就从应用程序接收数据，将数据封装在一个报文段中，并将该报文段交给IP。注意到每一个报文段都包含一个序号，这个序号就是该报文段第一个数据字节的字节流编号。如果定时器还没有计时，则当报文段被传给IP时，TCP就启动一个该定时器。
第二个事件是超时。TCP通过重传引起超时的报文段来响应超时事件。然后TCP重启定时器。
第三个事件是一个来自接收方的确认报文段(ACK)。当该事件发生时，TCP将ACK的值y与变量SendBase(发送窗口的基地址)进行比较。TCP状态变量SendBase是最早未被确认的字节的序号。就是指接收方已正确按序接收到数据的最后一个字节的序号。TCP采用累积确认，所以y确认了字节编号在y之前的所有字节都已经收到。如果Y>SendBase,则该ACK是在确认一个或多个先前未被确认的报文段。因此发送方更新其SendBase变量，相当于发送窗口向前移动。
另外，如果当前有未被确认的报文段，TCP还要重新启动定时器。
快速重传
超时触发重传存在的另一个问题是超时周期可能相对较长。当一个报文段丢失时，这种长超时周期迫使发送方等待很长时间才重传丢失的分组，因而增加了端到端时延。所以通常发送方可在超时事件发生之前通过观察冗余ACK来检测丢包情况。
冗余ACK就是接收方再次确认某个报文段的ACK，而发送方先前已经收到对该报文段的确认。
当TCP接收方收到一个序号比所期望的序号大的报文段时，它认为检测到了数据流中的一个间隔，即有报文段丢失。这个间隔可能是由于在网络中报文段丢失或重新排序造成的。因为TCP使用累计确认，所以接收方不向发送方发回否定确认，而是对最后一个正确接收报文段进行重复确认(即产生一个冗余ACK)
如果TCP发送方接收到对相同报文段的3个冗余ACK.它就认为跟在这个已被确认过3次的报文段之后的报文段已经丢失。一旦收到3个冗余ACK，TCP就执行快速重传 ，
即在该报文段的定时器过期之前重传丢失的报文段。
5流量控制
前面讲过，一条TCP连接双方的主机都为该连接设置了接收缓存。当该TCP连接收到正确、按序的字节后，它就将数据放入接收缓存。相关联的应用进程会从该缓存中读取数据，但没必要数据刚一到达就立即读取。事实上，接收方应用也许正忙于其他任务，甚至要过很长时间后才去读取该数据。如果应用程序读取数据时相当缓慢，而发送方发送数据太多、太快，会很容易使这个连接的接收缓存溢出。
TCP为应用程序提供了流量控制服务以消除发送方导致接收方缓存溢出的可能性。因此，可以说 流量控制是一个速度匹配服务，即发送方的发送速率与接收方应用程序的读速率相匹配。
前面提到过，TCP发送方也可能因为IP网络的拥塞而被限制，这种形式的发送方的控制被称为拥塞控制(congestioncontrol)。
TCP通过让接收方维护一个称为接收窗口的变量来提供流量控制。接收窗口用于告诉发送方，该接收方还有多少可用的缓存空间。因为TCP是全双工通信，在连接两端的发送方都各自维护一个接收窗口变量。 主机把当前的空闲接收缓存大小值放入它发给对方主机的报文段接收窗口字段中，通知对方它在该连接的缓存中还有多少可用空间。
6 TCP连接管理
客户机中的TCP会用以下方式与服务器建立一条TCP连接:
第一步: 客户机端首先向服务器发送一个SNY比特被置为1报文段。该报文段中不包含应用层数据，这个特殊报文段被称为SYN报文段。另外，客户机会选择一个起始序号，并将其放置到报文段的序号字段中。为了避免某些安全性攻击，这里一般随机选择序号。
第二步: 一旦包含TCP报文段的用户数据报到达服务器主机，服务器会从该数据报中提取出TCPSYN报文段，为该TCP连接分配TCP缓存和控制变量，并向客户机TCP发送允许连接的报文段。这个允许连接的报文段还是不包含应用层数据。但是，在报文段的首部却包含3个重要的信息。
首先，SYN比特被置为1。其次，该 TCP报文段首部的确认号字段被置为客户端序号+1最后，服务器选择自己的初始序号，并将其放置到TCP报文段首部的序号字段中。 这个允许连接的报文段实际上表明了:“我收到了你要求建立连接的、带有初始序号的分组。我同意建立该连接，我自己的初始序号是XX”。这个同意连接的报文段通常被称为SYN+ACK报文段。
第三步: 在收到SYN+ACK报文段后，客户机也要给该连接分配缓存和控制变量。客户机主机还会向服务器发送另外一个报文段，这个报文段对服务器允许连接的报文段进行了确认。因为连接已经建立了，所以该ACK比特被置为1，称为ACK报文段，可以携带数据。
一旦以上3步完成，客户机和服务器就可以相互发送含有数据的报文段了。
为了建立连接，在两台主机之间发送了3个分组，这种连接建立过程通常被称为 三次握手(SNY、SYN+ACK、ACK，ACK报文段可以携带数据) 。这个过程发生在客户机connect()服务器，服务器accept()客户连接的阶段。
假设客户机应用程序决定要关闭该连接。(注意，服务器也能选择关闭该连接)客户机发送一个FIN比特被置为1的TCP报文段，并进人FINWAIT1状态。
当处在FINWAIT1状态时，客户机TCP等待一个来自服务器的带有ACK确认信息的TCP报文段。当它收到该报文段时，客户机TCP进入FINWAIT2状态。
当处在FINWAIT2状态时，客户机等待来自服务器的FIN比特被置为1的另一个报文段，
收到该报文段后，客户机TCP对服务器的报文段进行ACK确认，并进入TIME_WAIT状态。TIME_WAIT状态使得TCP客户机重传最终确认报文，以防该ACK丢失。在TIME_WAIT状态中所消耗的时间是与具体实现有关的，一般是30秒或更多时间。
经过等待后，连接正式关闭，客户机端所有与连接有关的资源将被释放。 因此TCP连接的关闭需要客户端和服务器端互相交换连接关闭的FIN、ACK置位报文段。
Ⅳ 在计算机网络中，“带宽”这一术语表示
带宽又叫频宽是指在固定的的时间可传输的资料数量，亦即在传输管道中可以传递数据的能力。在数字设备中，频宽通常以bps表示，即每秒可传输之位数。在模拟设备中，频宽通常以每秒传送周期或赫兹Hertz (Hz)来表示。频宽对基本输出入系统 (BIOS ) 设备尤其重要，如快速磁盘驱动器会受低频宽的总线所阻碍。
单位时间内能够在线路上传送的数据量，常用的单位是bps(bit per second)
计算机网络的带宽是指网络可通过的最高数据率，即每秒多少比特。
描述带宽时常常把“比特/秒”省略。
例如，带宽是 10 M，实际上是 10 Mb/s。
这里的 M 是 10^6。
在网络中有两种不同的速率：
信号（即电磁波）在传输媒体上的传播速率（米/秒，或公里/秒）
计算机向网络发送比特的速率（比特/秒）
这两种速率的意义和单位完全不同。
在理解带宽这个概念之前，我们首先来看一个公式：带宽=时钟频率x总线位数/8，从公式中我们可以看到，带宽和时钟频率、总线位数是有着非常密切的关系的。其实在一个计算机系统中，不仅显示器、内存有带宽的概念，在一块板卡上，带宽的概念就更多了，完全可以说是带宽无处不在。
那到底什么是带宽呢？带宽的意义又是什么？简单的说，带宽就是传输速率，是指每秒钟传输的最大字节数（MB/S），即每秒处理多少兆字节，高带宽则意味着系统的高处理能力。为了更形象地理解带宽、位宽、时钟频率的关系，我们举个比较形象的例子，工人加工零件，如果一个人干，在大家单个加工速度相同的情况下，肯定不如两个人干的多，带宽就象是加工零件的总数量，位宽仿佛工人数量，时钟工作频率相当于加工单个零件的速度，位宽越宽，时钟频率越高则总线带宽越大,其好处也是显而易见的。
主板上通常会有两块比较大的芯片，一般将靠近CPU的那块称为北桥，远离CPU的称为南桥。北桥的作用是在CPU与内存、显卡之间建立通信接口，它们与北桥连接的带宽大小很大程度上决定着内存与显卡效能的大小。南桥是负责计算机的I/O设备、PCL设备和硬盘，对带宽的要求，相比较北桥而言，是要小一些的。而南北桥之间的连接带宽一般就称为南北桥带宽。随着计算机越来越向多媒体方向发展，南桥的功能也日益强大，对于南北桥间的连接总线带宽也是提出了新的要求，在INTEL的9X5系列主板上，南北桥的带宽将从以前一直为人所诟病的266MB/S发展到空前的2GB/S，一举解决了南北桥间的带宽瓶颈。
再来说说显卡，玩游戏的朋友都晓得，当玩一些大制作游戏的时候，画面有时候会卡的比较厉害。其实这就是显卡带宽不足的问题，再具体点说，这是显存带宽不足。众所周知，目前当道的AGP接口是AGP 8X，而AGP总线的频率是PCI总线的两倍，也就是66MHz,很容易就可以换算出它的带宽是2.1GB/S，在目前的环境下，这样的带宽就显得很微不足道了，因为连最普通的ATI R9000的显存带宽都要达到400MHZ X 128Bit/8=6.4GB/s,其余的高端显卡更是不用说了。正因为如此，INTEL在最新的9X5芯片组中，采用了PCI-Express总线来替代老态龙钟的AGP总线，与传统PCI以及更早期的计算机总线的共享并行架构相比，PCI Express最大的特点是在设备间采用点对点串行连接,如此一来即允许每毁中个设备都有自己的专用连接，不纤唯山需要向整个总线请求带宽，同时利用串行的连接特点将能轻松将数据传输速度提到一个很高的频率。在传输速度上，由于PCI Express支持双向传输模式，因此连接的每个装置都可以使用最大带宽。AGP所遇到的带宽瓶颈也迎刃而解。
为了在实际使用计算机的过程中得到更多总线带宽，根据带宽的计算公式，一般会采取两种办法，一是增加总线速度，比如INTEL的P4 CPU和塞扬CPU就是最好的例子，一个是400总线，一个是533/800总线，在实际应用的效能就有了很大的区别（当然，二级缓存也是一个重要的因素）。另外一个常用的方法是增加总线的宽度，如果当它的时钟速度一样时，总线的宽度增加一倍，那么尽管时钟下降沿同未改变之前是相同而此时每次下降沿所传输的数据量却是以前的两倍，这一点在相同核心，但是显存位宽却不一样的显卡上表现特别明显。
[u]Web Hosting[/u]
一些虚拟主机服务商会给频宽以不同的含义。再这里，山昌频宽几乎变成了一个流量概念。意思是指定时间内的下行数据总量。意味着如果一个Web Hosting公司给你2GB每月的频宽，那么意味着你的用户每月只能最多下载2GB的内容。In website hosting, bandwidth is the amount of information downloadable from the webserver over a prescribed period of time. In essence, it is the rate [data/time], but the time in this case is not seconds but rather a month or a week. So this rate is not like 56K or broadband, etc., which are also bandwidth but are measured per second. Web hosting companies often quote a monthly bandwidth limit for a website, for example 2GB/month. If visitors to the website download a total greater than 2GB in one month, the bandwidth limit will have been exceeded.
Ⅳ 计算机网络中确认帧是捎带的是什么意思
虽然很容易混淆，但是谢希仁说的很清楚，数据链路层使用自动重传请求陆凯即arq协议来实现可靠传输，跟运输层tcp协议机制非常接近所以在传输层讲。链路层中发送的单位是帧，确认的是按序收到的最后一个帧编号，比如收到12456那么他就只确认2，发含数送方就知道他起码3没收到，456还不清楚，如果是选择重传那就只需要发送3了，而这里既然是GBN那就只能退回直接重发3456，那么接受方就直接确认6这个就是连续arq，也就是不用逐个确认。而tcp报文段是面向字节的，每次确认的是按序收到的序号的下一个字节（数据部分）序号，这就是传输层和链路层在确认序号上的差别，当然，tcp是选择重传的，不是后退，链路层如果不是连续arq那就退化成普通的停止等待了，也相当于在连续arq模式中把接受窗口大小设置为1，发送方每次就只能发送一个帧，发完就谈悉首等确认。而现在底层传输一般比较稳定，因此连续arq就提高了信道的利用率得到广泛使用
Ⅵ 谁会计算机网络这一题，求高手！！！
卫星链路的传播时延是固定270ms的，这题目很坑，我网络了才知道这个信息，题目没有提示，默认你知道传播时延是多少。发送时延10ms，10/（10+270）=3.57%
Ⅶ 计算机网络
应用层（数据）：确定进程之间通信的性质以满足用户需要以及提供网络与用户应用
表示层（数据）：主要解决用户信息的语法表示问题，如加密解密
会话层（数据）：提供包括访问验证和会话管理在内的建立和维护应用之间通信的机制，如服务器验证用户登录便是由会话层完成的
传输层（段）：实现网络不同主机上用户进程之间的数据通信，可靠
与不可靠的传输，传输层的错误检测，流量控制等
网络层（包）：提供逻辑地址（IP）、选路，数据从源端到目的端的
传输
数据链路层（帧）：将上层数据封装成袭枝帧，用MAC地址访问媒介，错误检测与修正
物理层（比特流）：设备之间比特流的传输，物理接口，电气特性等
IP 地址编址方案将IP地址空间划分为 A、B、C、D、E 五类，其中 A、B、C 是基本类，D、E 类作为多播和保留使用，为特殊地址。
A 类地址：以 0 开头，第一个字节范围：0~127 。
B 类地址：以 10 开头，第一个字节范围：128~191 。
C 类地址：以 110 开头，第一个字节范围：192~223。
D 类地址：以 1110 开头，第一个字节范围：224~239 。
E 类地址：以 1111 开头，保留地址。
物理地址(MAC 地址)，是数据链路层和物理层使用的地址。
IP 地址是网络层和以上各层使用的地址，是一种逻辑地址。
其中 ARP 协议用于 IP 地址与物理地址的对应。
网络层的 ARP 协议完成了 IP 地址与物理地址的映射。
TCP(Transmission Control Protocol)，传输控制协议，是一种面向连接的、可靠的、基于字节流的传输层通信协议。
主要特山耐点如下：
FTP ：定义了文件传输协议
Telnet ：它是一种用于远程登陆
SMTP ：定义了简单邮件传送协议
POP3 ：它是和 SMTP 对应，POP3 用于接收邮件
HTTP ：从 Web 服务器传输超文本到本地浏览器的传送协议。
防止了服务器端的一直等待而浪费资源
服务器端准备为每个请求创建一个链接，并向其发送确认报文，然后等待客户端进行确认后创建。如果此时客户端一直不确认，会造成 SYN 攻击，即SYN 攻击，英文为 SYN Flood ，是一种典型的 DoS/DDoS 攻击。
TCP 协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP 是全双工模式，这就意味着：
TIME_WAIT 表示收到了对方的 FIN 报文，并发送出了 ACK 报文，就等 2MSL后即可回到 CLOSED 可用状态了。如果 FIN_WAIT_1 状态下，收到了对方同时带 FIN 标志和 ACK 标志的报文时，可以直接进入到 TIME_WAIT 状态，而无须经过 FIN_WAIT_2 状态。
如果不等，释放的端口可能会重连刚断开的服务器端口，这样依然存活在网络里的老的 TCP 报文可能与新 TCP 连接报文冲突，造成数据冲突，为避免此种情况，需要耐心等待网络老的 TCP 连接的活跃报文全部死翘翘，2MSL 时间可以满足这个需求（尽管非常保守）！
建立连接后，两台主机就可以相互传输数据了。如下图所示：
因为各种原因，TCP 数据包可能存在丢失的情况，TCP 会进行数据重传。如下图所示：
TCP 协议操作是围绕滑动窗口 + 确认机制来进行的。
滑动窗口协议，是传输层进行流控的一种措施，接收方通过通告发送方自己的窗口大小，从而控制发送方的发送速度，从而达到防止发送方发送速度过快而导致自己被淹没的目的。
TCP 的滑动窗口解决了端到端的流量控制问题，允许接受方对拍唯敏传输进行限制，直到它拥有足够的缓冲空间来容纳更多的数据。
计算机网络中的带宽、交换结点中的缓存及处理机等都是网络的资源。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就会变坏，这种情况就叫做拥塞。
通过拥塞控制来解决。拥堵控制，就是防止过多的数据注入网络中，这样可以使网络中的路由器或链路不致过载。注意，拥塞控制和流量控制不同，前者是一个 全局性 的过程，而后者指 点对点 通信量的控制。
拥塞控制的方法主要有以下四种：
1）慢开始
不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小。
2）拥塞避免
拥塞避免算法，让拥塞窗口缓慢增长，即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1 ，而不是加倍，这样拥塞窗口按线性规律缓慢增长。
3）快重传
快重传，要求接收方在收到一个 失序的报文段 后就立即发出 重复确认 （为的是使发送方及早知道有报文段没有到达对方），而不要等到自己发送数据时捎带确认。
快重传算法规定，发送方只要一连收到三个重复确认，就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。
4）快恢复
快重传配合使用的还有快恢复算法，当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把 ssthresh 门限减半。
UDP（User Data Protocol，用户数据报协议），是与 TCP 相对应的协议。它是面向非连接的协议，它不与对方建立连接，而是直接就把数据包发送过去。
主要特点如下：
DNS ：用于域名解析服务
SNMP ：简单网络管理协议
TFTP：简单文件传输协议
TCP 只支持点对点通信；UDP 支持一对一、一对多、多对一、多对多的通信模式。
TCP 有拥塞控制机制；UDP 没有拥塞控制，适合媒体通信，对实时应用很有用，如 直播，实时视频会议等
既使用 TCP 又使用 UDP 。
HTTP 协议，是 Hyper Text Transfer Protocol（超文本传输协议）的缩写，是用于从万维网服务器传输超文本到本地浏览器的传送协议。
主要特点如下：
请求报文包含三部分：
a、请求行：包含请求方法、URI、HTTP版本信息
b、请求首部字段
c、请求内容实体
响应报文包含三部分：
a、状态行：包含HTTP版本、状态码、状态码的原因短语
b、响应首部字段
c、响应内容实体
GET: 对服务器资源的简单请求。
POST: 用于发送包含用户提交数据的请求。
HEAD：类似于 GET 请求，不过返回的响应中没有具体内容，用于获取报头。
PUT：传说中请求文档的一个版本。
DELETE：发出一个删除指定文档的请求。
TRACE：发送一个请求副本，以跟踪其处理进程。
OPTIONS：返回所有可用的方法，检查服务器支持哪些方法。
CONNECT：用于 SSL 隧道的基于代理的请求。
1.明文发送，内容可能被窃听
2.不验证通信方的身份，因此可能遭遇伪装
3.无法证明报文的完整性，可能被篡改
综上所述：
需要 IP 协议来连接网络，TCP 是一种允许我们安全传输数据的机制，使用 TCP 协议来传输数据的 HTTP 是 Web 服务器和客户端使用的特殊协议。HTTP 基于 TCP 协议，所以可以使用 Socket 去建立一个 TCP 连接。
HTTPS ，实际就是在 TCP 层与 HTTP 层之间加入了 SSL/TLS 来为上层的安全保驾护航，主要用到对称加密、非对称加密、证书，等技术进行客户端与服务器的数据加密传输，最终达到保证整个通信的安全性。
端口不同：HTTP 与 HTTPS 使用不同的连接方式，端口不一样，前者是 80，后者是 443。
资源消耗：和 HTTP 通信相比，HTTPS 通信会由于加解密处理消耗更多的 CPU 和内存资源。
开销：HTTPS 通信需要证书，而证书一般需要向认证机构申请免费或者付费购买。
SSL 协议即用到了对称加密也用到了非对称加密
1）客户端发起 https 请求（就是用户在浏览器里输入一个 https 网址，然后连接到 server
的 443 端口）
2）服务端的配置（采用 https 协议的服务器必须要有一套数字证书，可以自己制作，
也可以向组织申请，这套证书就是一对公钥和私钥，这是非对称加密）。
3）传输证书（这个证书就是公钥，只是包含了很多信息）
4）客户端解析证书（由客户端 tls 完成，首先验证公钥是否有效，若发现异常，则弹出
一个警示框，提示证书存在问题，若无问题，则生成一个随机值（对称加密的私钥），然后用证书对随机值进行加密）
5）传输加密信息（这里传输的是加密后的随机值，目的是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密了）
6）服务端解密信息（服务端用私钥（非对称加密）解密后得到了客户端传来的随机值（对称加密的私钥），然后把通信内容通过该值（对称加密的私钥随机值）进行对称加密。所谓对称加密就是，将信息和私钥（对称加密的私钥）通过某种算法混在一起，这样除非知道私钥（对称加密的私钥），不然无法获取内容，而正好客户端和服务端都知道这个私钥（对称加密的私钥），所以只要加密算法够彪悍，私钥够复杂，数据就够安全）
7）传输加密的信息
8）客户端解密信息，用随机数（对称加密的私钥）来解。
默认情况下建立 TCP 连接不会断开，只有在请求报头中声明 Connection: close 才会在请求完成后关闭连接。
在 HTTP/1.0 中，一个服务器在发送完一个 HTTP 响应后，会断开 TCP 链接。但是这样每次请求都会重新建立和断开 TCP 连接，代价过大。所以虽然标准中没有设定，某些服务器对 Connection: keep-alive 的 Header 进行了支持。意思是说，完成这个 HTTP 请求之后，不要断开 HTTP 请求使用的 TCP 连接。这样的好处是连接可以被重新使用，之后发送 HTTP 请求的时候不需要重新建立 TCP 连接，以及如果维持连接，那么 SSL 的开销也可以避免.
如果维持持久连接，一个 TCP 连接是可以发送多个 HTTP 请求的。
HTTP/1.1 存在一个问题，单个 TCP 连接在同一时刻只能处理一个请求，在 HTTP/1.1 存在 Pipelining 技术可以完成这个多个请求同时发送，但是由于浏览器默认关闭，所以可以认为这是不可行的。在 HTTP2 中由于 Multiplexing 特点的存在，多个 HTTP 请求可以在同一个 TCP 连接中并行进行。
TCP 连接有的时候会被浏览器和服务端维持一段时间。TCP 不需要重新建立，SSL 自然也会用之前的。
有。Chrome 最多允许对同一个 Host 建立六个 TCP 连接。不同的浏览器有一些区别。
如果图片都是 HTTPS 连接并且在同一个域名下，那么浏览器在 SSL 握手之后会和服务器商量能不能用 HTTP2，如果能的话就使用 Multiplexing 功能在这个连接上进行多路传输。不过也未必会所有挂在这个域名的资源都会使用一个 TCP 连接去获取，但是可以确定的是 Multiplexing 很可能会被用到。
如果发现用不了 HTTP2 呢？或者用不了 HTTPS（现实中的 HTTP2 都是在 HTTPS 上实现的，所以也就是只能使用 HTTP/1.1）。那浏览器就会在一个 HOST 上建立多个 TCP 连接，连接数量的最大限制取决于浏览器设置，这些连接会在空闲的时候被浏览器用来发送新的请求，如果所有的连接都正在发送请求呢？那其他的请求就只能等等了
Ⅷ [计算机网络之六] 传输层
传输层向它上面的应用层提供通信服务，它属于面向通信部分的最高层，同时也是用户功能中的最底层。
从传输层的角度，通信的真正端点并不是主机而是主机中的进程。
传输层有 分用 和 复用 的功能。 “复用” 是指在发送方不同的应用进程都可以使用同一个运输层协议传送数据， “分用” 是指接收方的运输层在剥去报文的首部后能够把这些数据正确交付目的应用进程。
网络层和运输层有明显的区别，网络层为主机之间提供逻辑通信，而运输层为应用进程之间提供端到端的逻辑通信。
知名端口号 ：0~1023
登记端口号 ：1024~49151
客户端短暂端口号 ：49152~65535
① 无连接。 发送数据之前不需要建立连接，因此减少了开销和发送数据之前的时延。
② 尽最大努力交付。 即不保证可靠交付，因此主机不需要维持复杂的连接状态表。
③ 面向报文的。 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界，UDP 一次交付一个完整的报文。
用户数据报 UDP 有两个字段：数据字段和首部字段。首部字段很简单，只有 8 个字节，由四个字段组成，每个字段的长度都是两个字节。各字段意义如下：
① 源端口 在需要对方回信时选用。不需要时可用全0。
② 目的端口 目的端口号。这在终点交付报文时必须使用。
③ 长度 用户数据报的长度，最小值为 8 （仅有首部）。
④ 检验和 检测用户数据报在传输中是否有错。有错就丢弃。
用户数据报首部检验和的计算和校验都要计算出一个伪首部。
① 面向连接。
应用程序在使用 TCP 协议之前，必须先建立 TCP 连接；传送数据完毕后，必须释放已经建立的 TCP 连接。类似于打电话：通话前要先拨号建立连接，通话结束后要挂机释放连接。
② 一对一。
TCP 连接只能是点对点的（一对一）。
③ 可靠交付。
通过 TCP 连接传送的数据，无差错、不丢失、不重复，并且按序到达。
④ 全双工通信。
通信双方的应用进程在任何时候都能发送和接收数据，TCP 连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据。
⑤ 面向字节流。
TCP 中的 “流” 指的是流入到进程或从进程流出的字节序列。
“面向字节流” 的含义：虽然应用程序和 TCP 的交互式一次一个数据块（大小不等），但 TCP 把应用程序交下来的数据仅仅看成是一连串无结构的字节流。TCP 并不知道所传送的字节流的含义。TCP 不保证接收方应用程序锁收到的数据块和发送方应用程序所发出的数据块具有对应的大小关系。但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样，当然接收方的应用程序必须有能力识别收到的字节流，把它还原成有意义的应用层数据。
TCP 连接是协议软件提供的一种抽象，每一条 TCP 连接唯一地被通信两端的两个端点（即两个套接字）所确定，即：
TCP 连接 ::= {socket1, socket2} = {(IP1: port1), (IP2: port2)}
IP1 和 IP2 分别是两个端点主机的 IP 地址，port1 和 port2 分别是两端端点主机中的端口号。
网络只能提供最大努力的服务，是不可靠的，因此 TCP 必须采用适当的措施才能使得两个运输层之间的通信变得可靠。当出现差错时让发送方重传出现差错的数据，同时在接收方来不及处理收到的数据时，及时告知发送方适当降低发送数据的速度，这样就可以在不可靠的传输信道实现可靠传输。
ARQ（Auto Repeat-reQuest）：自动重传请求。
发送方每发送完一个分组就停止发送，等待接收方确认，在收到确认后再发送下一个分组。
A 是发送方，B 是接收方。
A 每发送一个分组后，等待 B 对该分组的确认后，再接着发送下一个分组。
【发送方】A 发送的分组在传输过程中出错，可能是丢失了，也可能是分组受到干扰出错了
【接收方】这时 B 直接丢弃分组，什么也不做（也不通知 A 受到的分组有差错）。
【解决方案】发送方在每发送完一个分组时设置一个 超时计数器 ，只要超过一段时间仍然没有接收到确认，就认为刚才发送的分组丢失了，因而重传前面发送过的分组，这叫 超时重传 。反之在超时计时器到期之前收到了相应的确认，就撤销该超时计时器。
第一，A 在发送完一个分组后， 必须暂时保留已发送的分组的副本 （在发生超时重传时使用）。只有在收到相应的确认后才能清楚暂时保留的分组副本。
第二，分组和确认分组都必须进行 编号 。这样才能明确是哪一个发送出去的分组受到了确认，而哪一个分组还没有收到确认。
第三，超时计时器设置的 重传时间应当比数据在分组传输的平均往返时间更长一些 。
【发送方】超时重传时间内没有收到确认报文，无法确认是发送出错、丢失，还是接收方的确认丢失，超时计时器到期后就要重传。
【接收方】丢弃收到的重复分组，不向上层交付；向发送方发送确认。
【发送方】收下迟到的确认，并且丢弃
发送方大部分时间都在等待确认，信道的利用率低
使用流水线的 ARQ 可以提高信道利用率
【发送方】维持一个发送窗口，位于发送窗口内的分组都可连续发送出去，而不需要等待对方的确认。
回退N帧协议 ：如果发送方发送了多个分组，但中间的某个分组丢失了，这时接收方只能对丢失分组之前的分组发出确认，而发送方无法知道丢失分组及后面分组的接收情况，只好把丢失分组及后面的分组重传一次，这叫 Go-back-N ，表示需要再退回来重传已发送过的 N 个分组。
前面 20 个字节固定，因此 TCP 首部最小长度是 20 字节。
TCP 的滑动窗口以字节为单位，窗口后沿的部分表示已发送且已收到通知，窗口里的序号表示允许发送的序号，窗口前沿之前的数据暂时不允许发送，需要等待收到接收方的确认后前沿往前移才可发送。
描述一个发送窗口需要三个指针：P1、P2 和 P3，如图所示：
小于 P1 的是已发送并已收到确认的部分，而大于 P3 的是不允许发送的部分。
P3 - P1 = A 的发送窗口
P2 - P1 = 已发送但尚未收到确认的字节数
P3 - P2 = 允许发送但当前尚未发送的字节数（又称为 可用窗口 或 有效窗口 ）
接收方 B 接收窗口大小为20，因为未收到 31 的数据，即使已收到后面的序号 32、33 的数据，返回的确认号仍然是 31。
现在接收方收到了 31、32、33，并返回确认号 33，接收窗口往前滑动 3 个序号，发送方接收到确认，发送窗口也向前滑动 3 个序号大小，现在 A 可以发送序号 51~53 的数据了。
当发送方将发送窗口内的数据都发送出去，但是接收方的确认可能由于网络拥塞滞留，这时发送方发送窗口已满，可用窗口为 0，只能等待接收方的确认报文到达。
TCP 为了保证可靠传输，要求必须受到对已发送报文的确认，如果超过一定时间未受到确认报文，则重传已发送的报文。这个时间就叫 超时重传时间 ，很明显超时重传时间的大小设置应该更贴近网络的实际情况，如果网络状况好，就设短一点，否则使网络的空闲时间增大，降低了传输效率；网络差就设长一点，否则会引起很多不必要的重传，使网络负荷增大。
TCP 采用了一种自适应的算法：
RTT（报文段的往返时间）、RTTs（加权平均往返时间），RTTs 的计算公式：
RTTd（RTT 的偏差的加权平均值）、RTO（RetransmissionTime-Out 超时重传时间）:
【场景】TCP 的接收方在接收对方发送过来的数据字节流的序号不连续，形成一些不连续的字节块，如果简单按照回退N帧协议处理，意味着要重传第一个未收到的序号数据块及之后的数据，如果能通知发送方已收到了哪些数据（选择确认），就可以让发送方只发送接收方未收到的数据。
流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。
当发送方收到接收方通知，将窗口缩小为 0 时，发送方将暂时不能发送数据了，必须等接收方通知更新接收窗口大小，但是这个通知又有可能丢失，导致发送方没收到通知。
为了避免双方互相等待死锁，TCP 为每个链接设有一个 持续计时器 ，只要 TCP 连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口 探测报文段 （仅携带 1 字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。如果窗口仍然是零，那么受到这个报文段的一方就重新设置持续计时器；如果窗口不是零，那么死锁的僵局就可以打破了。
【优点】提高网络利用率
【缺点】可能会发生某种程度的延迟
【场景】接收数据的主机如果每次都立刻回复确认应答的话，可能会返回一个较小的窗口，因为接收方刚接收完数，缓冲区已满。
【糊涂窗口综合征问题】
TCP 接收方缓存已满，而交互式的应用进程一次只从接收缓存中读取 1 个字节（这样就使接收缓存空间仅腾出 1 个字节），然后向发送方发送确认，并把窗口设置为 1 个字节（但发送的数据报是 40 字节长，TCP 首部 + IP 数据报首部）。接着，发送方又发来 1 个字节的数据（注意发送方发送的 IP 数据报是 41 字节长）。接收方发回确认，仍然将窗口设置为 1 个字节。这样进行下去，使网络的效率很低。
TCP 文件传输中，就采用了两个数据段返回一次确认应答，并且等待一定时间后没有其他数据包到达时也依然发送确认应答。
当对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏，这种情况就叫做 拥塞 。
慢开始（slow-start）、拥塞避免（congestion avoidance）、快重传（fast retransmit）和快恢复（fast recovery）。
【算法思路】
当主机开始发送数据时，由于并不清楚网络的负荷情况，所以如果立即把大量数据字节注入网络，那么就有可能引起网络发生拥塞。较好的方法是先探测一下，即 由小到大逐渐增大发送窗口 ，也就是说， 由小到大逐渐增大拥塞窗口数值 。
【处理过程】
慢开始门限值 ssthresh 决定了拥塞窗口达到多大时要执行什么算法。
① 当 cwnd < ssthresh 时，使用慢开始算法；
② 当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法；
③ 当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞避免算法。
在拥塞窗口 cwnd 达到门限值之前，发送方每一轮次收到确认应答后，cwnd 就增大为原来的两倍；达到门限值后，执行拥塞避免算法。
PS. 慢开始只是表示初始发送数据少，不代表发送速率增长速度慢，实际上是指数级增长非常快。
【算法思路】
让拥塞窗口 cwnd 缓慢地增大，即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1，而不是像慢开始阶段那样加倍增长。拥塞避免阶段有 “加法增大” 的特点，按线性规律缓慢增长，使网络比较不容易出现拥塞 。
【处理过程】
在执行拥塞避免算法阶段，当网络出现超时时，发送方判断为网络拥塞，调整门限值为当前拥塞窗口的一半，即 ssthresh = cwnd / 2，同时拥塞窗口重置为 1，即 cwnd = 1，进入慢开始阶段。
【算法原理】
① 快重传
【场景】有时，个别报文段会在网络中丢失，但实际上网络并未发生拥塞。如果发送方迟迟收不到确认，就会产生超时，就会误认为网络发生了拥塞，导致发送方错误地启动慢开始，把拥塞窗口 cwnd 又设置为 1，因而降低了传输效率。
【方案】接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认，即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认，当发送方 一连收到 3 个重复确认 ，就知道接收方确实没有收到某个报文段，因而应当 立即进行重传 。
② 快恢复：
发送方知道只是丢失了个别的报文段，于是不启动慢开始，而是执行快恢复算法，调整发送方门限值 ssthresh = cwnd / 2，同时设置拥塞窗口 cwnd = ssthresh = 8，并开始执行拥塞避免算法。
拥塞控制的流程如下：
拥塞窗口 cwnd，接收方窗口 rwnd， 发送方发送窗口的上限值 = Min[rwnd, cwnd] 。
① 当 rwnd < cwnd，接收方的接收能力限制发送方窗口大小；
② 当 cwnd < rwnd，网络的拥塞程度限制发送方窗口大小。
【问题背景】
路由器采取分组丢弃策略，即按照 先进先出（FIFO） 规则处理分组，当队列已满时，则丢弃后面到达的分组，这叫 尾部丢弃策略 。
丢失的分组会导致发送方出现超时重传，发送方转而执行慢开始算法，不同分组属于不同 TCP 连接，导致很多 TCP 同时进入慢开始状态，这种现象称为 全局同步 。
【解决方案】
主动队列管理 AQM：不等到路由器的队列长度已经达到最大值时才不得不丢弃后面到达的分组，而是在队列长度达到某个警惕值时就主动丢弃到达的分组，这样就提醒了发送方放慢发送的速率，因而有可能使网络拥塞的程度减轻，甚至不出现网络拥塞。
TCP 是面向连接的协议，运输连接有三个阶段： 连接建立、数据传送、连接释放 。
TCP 连接建立过程要解决的几个问题：
① 使每一方能够确知对方的存在；
② 允许双方协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等）；
③ 能够对运输实体资源（如缓存大小、连接表中的项目等）进行分配。
TCP 建立连接的过程叫做握手，握手需要在客户和服务器之间交换三个 TCP 报文段，即 三次握手 。
最初客户端和服务端都处于 CLOSED（关闭） 状态，A（Client）主动打开连接，B（Server）被动打开连接。
一开始，B 的 TCP 服务器进程先创建 传输控制块 TCB ，准备接受客户进程的连接请求。然后服务器进程就处于 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 都处于 ESTABLISHED 状态。
第一次挥手 ：A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP 连接。A 把连接释放报文段首部的终止控制位 FIN 置 1，其序号 seq = u，它等于前面已传送过的数据的最后一个字节的序号加 1。这时 A 进入 FIN-WAIT-1（终止等待 1）状态，等待 B 的确认。请注意，TCP 规定，FIN 报文段即使不携带数据，它也消耗掉一个序号。
第二次挥手 ：B 收到连接释放报文后即发出确认，确认号是 ack = u + 1，而这个报文段自己的序号是 v，等于 B 前面已传送过的最后一个字节的序号加 1。然后 B 就进入 CLOSE-WAIT（关闭等待）状态。TCP 服务器进程这时应通知高层应用程序，因而从 A 到 B 这个方向的连接就释放了，这时的 TCP 连接处于半关闭（half-close）状态，即 A 已经没有数据要发送了，但 B 若发送数，A 仍要接收。也就是说，从 B 到 A 这个方向的连接并未关闭，这个状态可能会持续一段时间。A 收到来自 B 的确认后，就进入 FIN-WAIT-2（终止等待 2）状态，等待 B 发出的连接释放报文段。
第三次挥手 ：若 B 已经没有要向 A 发送的数据，其应用进程就通知 TCP 释放连接。这时 B 发出的连接释放报文段必须使 FIN = 1。现假定 B 的序号为 w（在半关闭状态 B 可能又发送了一些数据）。B 还必须重复上次已发送过的确认号 ack = u + 1。这时 B 就进入 LAST-ACK（最后确认）状态，等待 A 的确认。
第四次挥手 ：A 在收到 B 的连接释放报文段后，必须对此发出确认。在确认报文段中把 ACK 置 1，确认号 ack = w + 1，而自己的序号是 seq = u + 1（根据 TCP 标准，前面发送过的 FIN 报文段要消耗一个序号）。然后进入 TIME-WAIT（时间等待）状态。请注意，现在 TCP 连接还没有释放掉。必须经过时间等待计时器（TIME-WAIT timer）设置的时间 2MSL 后，A 才进入到 CLOSED 状态，然后撤销传输控制块，结束这次 TCP 连接。当然如果 B 一收到 A 的确认就进入 CLOSED 状态，然后撤销传输控制块。所以在释放连接时，B 结束 TCP 连接的时间要早于 A。
Ⅸ tcp协议的主要功能是什么
1、完成对数据报的确认、流量控制和网络拥塞。
2、自动检测数据报，并提供错误重发的功能。
3、将多条路径传送的数据报按照原来的顺序进行排列。
4、控制超时重发，自动调整超时值。
tcp协议简介：
TCP（Transmission Control Protocol 传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793定义。在简化的计算机网络OSI模型中，它完成第如棚李四层传输层所指定的功能，用户数据报协议（UDP）是同一层内渣迟 [1] 另一个重要的传输协议。
在因特网协议族（Internet protocol suite）中，TCP层是位于IP层之上，应用层之下的中间层。不同主机的应用层之间经常需要可靠的和皮、像管道一样的连接，但是IP层不提供这样的流机制，而是提供不可靠的包交换。