A. 100M宽带可以多台电脑上网吗怎么计时
100M的网络是可以多人塌戚颂使用的。每个人用的网络不一样，这就要看你干什么了团郑单纯的浏览和工作是可以的，如果是下载的话就应该在10人仔慎之内吧。可以下载终结者设置每个人用的网络。也可以登陆路由来看。
B. 计算机是如何计算时间的
早上6点起床，7点吃早饭，8点上班，9点开会，10点约了合作伙伴商谈......假如时间不存在，我们做任何事情都是没有意义的。我们需要用手表、手机等显示时间的机器告诉我们现在是几点几分，这时候该干什么？同样的，计算机也要看时间，才能持续不断的运转下去。计算机是通过看晶振，来确定时间的。
晶振在电脑中的作用晶振的作用是为系统提供基本的时钟信号。通常一个系统共用一个晶振，便于各部分保持同步。它就像个标尺，工作频率不稳定会造成相关设备工作频率不稳定。有些通讯系统的基频和射频使用不同的晶振，而通过电子调整频率的方法保持同步。
晶振通常与锁相环电路配合使用，以提供系统所需的时钟频率。如果不同子系统需要不同频率的时钟信号，可以用与同一个晶振相连的不同锁相环来提供。
C. 计算机网络中的距离向量算法（RIP）的基本原理
RIP协议采用距离向量算法，在实际使用中已经较少适用。在默认情况下，RIP使用一种非常简单的度量制度：距离就是通往目的站点所需经过的链路数，取值为1~15，数值16表示无穷大。RIP进程使用UDP的520端口来发送和接收RIP分组。RIP分组每隔30s以广播的形式发送一次，为了防止出现“广播风暴”，其后续的的分组将做随机延时后发送。在RIP中，如果一个路由在180s内未被刷，则相应的距离就被设定成无穷大，并从路由表中删除该表项。RIP分组分为两种：请求分组和响应分组。
D. 计算机网络问题，概念有点混。不要复制。谢谢啊
题主的第一个问题应该是异步传输和同步传输的区分吧？那么我先回答第一个！
先来理解一下他们存在的必要性吧。
在网络通信过程中，通信双方要交换数据，需要高度的协同工作。为了正确的解释信号，接收方必须确切地知道信号应当何时接收和处理，因此定时是至关重要的。在计算机网络中，定时的因素称为位同步。同步是要接收方按照发送方发送的每个位的起止时刻和速率来接收数据，否则会产生误差。通常可以采用同步或异步的传输方式对位进行同步处理。
1. 异步传输（Asynchronous Transmission）： 异步传输将比特分成小组进行传送，小组可以是8位的1个字符或更长。发送方可以在任何时刻发送这些比特组，而接收方从不知道它们会在什么时候到达。一个常见的例子是计算机键盘与主机的通信。按下一个字母键、数字键或特殊字符键，就发送一个8比特位的ASCII代码。键盘可以在任何时刻发送代码，这取决于用户的输入速度，内部的硬件必须能够在任何时刻接收一个键入的字符。
异步传输存在一个潜在的问题，即接收方并不知道数据会在什么时候到达。在它检测到数据并做出响应之前，第一个比特已经过去了。这就像有人出乎意料地从后面走上来跟你说话，而你没来得及反应过来，漏掉了最前面的几个词。因此，每次异步传输的信息都以一个起始位开头，它通知接收方数据已经到达了，这就给了接收方响应、接收和缓存数据比特的时间；在传输结束时，一个停止位表示该次传输信息的终止。按照惯例，空闲（没有传送数据）的线路实际携带着一个代表二进制1的信号，异步传输的开始位使信号变成0，其他的比特位使信号随传输的数据信息而变化。最后，停止位使信号重新变回1，该信号一直保持到下一个开始位到达。例如在键盘上数字“1”，按照8比特位的扩展ASCII编码，将发送“00110001”，同时需要在8比特位的前面加一个起始位，后面一个停止位。
异步传输的实现比较容易，由于每个信息都加上了“同步”信息，因此计时的漂移不会产生大的积累，但却产生了较多的开销。在上面的例子，每8个比特要多传送两个比特，总的传输负载就增加25%。对于数据传输量很小的低速设备来说问题不大，但对于那些数据传输量很大的高速设备来说，25%的负载增值就相当严重了。因此，异步传输常用于低速设备。
2. 同步传输（Synchronous Transmission）：同步传输的比特分组要大得多。它不是独立地发送每个字符，每个字符都有自己的开始位和停止位，而是把它们组合起来一起发送。我们将这些组合称为数据帧，或简称为帧。
数据帧的第一部分包含一组同步字符，它是一个独特的比特组合，类似于前面提到的起始位，用于通知接收方一个帧已经到达，但它同时还能确保接收方的采样速度和比特的到达速度保持一致，使收发双方进入同步。
帧的最后一部分是一个帧结束标记。与同步字符一样，它也是一个独特的比特串，类似于前面提到的停止位，用于表示在下一帧开始之前没有别的即将到达的数据了。
同步传输通常要比异步传输快速得多。接收方不必对每个字符进行开始和停止的操作。一旦检测到帧同步字符，它就在接下来的数据到达时接收它们。另外，同步传输的开销也比较少。例如，一个典型的帧可能有500字节（即4000比特）的数据，其中可能只包含100比特的开销。这时，增加的比特位使传输的比特总数增加2.5%，这与异步传输中25 %的增值要小得多。随着数据帧中实际数据比特位的增加，开销比特所占的百分比将相应地减少。但是，数据比特位越长，缓存数据所需要的缓冲区也越大，这就限制了一个帧的大小。另外，帧越大，它占据传输媒体的连续时间也越长。在极端的情况下，这将导致其他用户等得太久。
同步传输方式中发送方和接收方的时钟是统一的、字符与字符间的传输是同步无间隔的。
异步传输方式并不要求发送方和接收方的时钟完全一样，字符与字符间的传输是异步的。
同步与异步传输的区别
1,异步传输是面向字符的传输，而同步传输是面向比特的传输。
2,异步传输的单位是字符而同步传输的单位是桢。
3,异步传输通过字符起止的开始和停止码抓住再同步的机会，而同步传输则是以数据中抽取同步信息。
4,异步传输对时序的要求较低，同步传输往往通过特定的时钟线路协调时序。
5,异步传输相对于同步传输效率较低。
-----------------------我是优雅分割线--------------------
虚电路虚电路又称为虚连接或虚通道,虚电路交换是分组交换的两种传输方式中的一种。在通信和网络中，虚电路是由分组交换通信所提供的面向连接的通信服务。在两个节点或应用进程之间建立起一个逻辑上的连接或虚电路后，就可以在两个节点之间依次发送每一个分组，接受端收到分组的顺序必然与发送端的发送顺序一致，因此接受端无须负责在收集分组后重新进行排序。虚电路协议向高层协议隐藏了将数据分割成段，包或帧的过程。
信元交换又叫ATM（异步传输模式），是一种面向连接的快速分组交换技术，它是通过建立虚电路来进行数据传输的。
信元交换技术是一种快速分组交换技术，它结合了电路交换技术延迟小和分组交换技术灵活的优点。信元是固定长度的分组，ATM采用信元交换技术，其信元长度为53字节。信元头5字节，数据48字节。
交换技术方面，经历了：电路交换——>报文交换——>分组交换——>信元交换的过程。
在信元中包括CRC校验和，其生成公式为X^8+X^2+X+1，校验和只是对信元头进行校验。
ATDM信元传输采用异步时分复用（Asynchronous Time Division Multioles），又称统计复用（Statistic Multiptx）。信息源随机地产生信息，因为信元到达队列也是随机的。高速的业务信元来得十分频繁、集中，低速的业务信元来得很稀疏。这些信元都按顺序在队列中排队，然后按输出次序复用到传输线上。具有同样标志的信元在传输线上并不对应某个固定的时间间隙，也不是按周期出现的，信息和它在时域的位置之间没有关系，信息只是按信头中的标志来区分的。而在同步时分复用方式（如PCM复用方式）中，信息以它在一帧中的时间位置（时隙）来区分，一个时隙对应着一条信道，不需要另外的信息头来表示信息的身份。
VPI字段用于选择一条特定的虚通路，VCI字段在一条选定的虚通路上选择一条特定的虚电路。当进行VP交换时，是选择一条特定的虚通路。
若在交换过程中出现拥塞，该信息被记录在信元的PT中。
E. 计算机网络(5)| 运输层
从通信和处理信息的角度看，运输层是向它上面的应用层提供通信服务的，它属于面向通信部分的最高层，同时也是用户功能中的最低层。当网络的边缘部分中的两台主机使用网络的核心部分的功能进行端到端的通信时，只有主机的协议栈才有运输层，而网络核心部分中的路由器在转发分组时都只用到下三层的功能。
运输层的两个主要协议 TCP/IP 都是互联网的正式标准，即：
（1）用户数据报协议UDP
（2）传输控制协议TCP
TCP则是面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。TCP不提供广播或者多播服务。由于TCP要提供可靠的面向连接的运输服务，因此需要增加很多的开销。
TCP/IP的运输层用一个16位端口号来标志一个端口。端口号只有本地意义。它是为了标志本计算机应用层中的各个进程在和运输层交互时的层间接口。
运输层的端口号分为以下两类：
（1）服务器端使用的端口号： 它主要分为系统端口号0～1023和登记端口号1024～49151。
（2）客户端使用的端口号： 49152～65535，这类端口号仅在客户端进程运行时才动态选择。当服务器收到客户端进程的报文时，就知道客户端进程的端口号。因而可以把数据发送给客户进程。
用户数据报协议相比于IP的数据报服务就是只增加了复用、分用和差错检测功能。UDP的主要特点是：
（1）UDP是无连接的， 发送数据之前不需要建立连接，因此减少开销和发送数据之前的时延。
（2）UDP使用尽最大努力交付， 即不保证可靠交付，因此主机不需要维持复杂的连接状态表。
（3）UDP是面向报文的。 发送方的UDP对应用交下来的报文，添加首部后就向下交付给IP层。不对报文做任何处理，因此当报文过长时，IP层可能需要进行分片处理。
（4）UDP没有拥塞控制， 网络出现的拥塞不会使源主机的发送速率减低。
（5）UDP支持一对一、一对多、多对一和多对多的交互通信。
（6）UDP的首部开销小， 只有8个字节。
UDP有两个字段：数据字段和首部字段。先介绍首部字段，它是由4个字段组成的，每个字段只有2个字节，总共有8个字节。各个字段的意义如下：
（1）源端口： 源端口号。在需要对方回信时选用。不需要时可用全0。
（2）目的端口： 目的端口号。在这终点交付报文时必须使用。
（3）长度： UDP用户数据报的长度，其最小值是8（只有首部）。
（4）检验和： 检测UDP用户数据报在传输中是否有错，有错则丢弃。
当在传送用户数据报时，如果接收方UDP发现收到的报文中目的端口号不正确（即不存在对应于该端口号的应用进程），就丢弃该报文，并由网际控制报文协议ICMP发送“端口不可达”差错报文给发送方。
TCP的主要特点如下：
（1）TCP是面向连接的运输层协议。 应用程序在使用TCP协议之前，必须先建立TCP连接。传送数据完毕后，必须释放TCP连接。
（2）每一条TCP连接只能有两个端点。 每一条TCP连接只能是点对点的。
（3）TCP提供可靠交付的服务。 通过TCP连接传送的数据，无差错、不丢失、不重复，并且按序到达。
（4）TCP提供全双工通信。 TCP允许通信双方的应用进程在任何时候都能发送数据。
（5）面向字节流。 TCP中的流指的是流入到进程或进程流出的字节序列。虽然应用程序和TCP的交互是一次一个数据块，但TCP把应用程序交下来的数据看成一连串的无结构的字节流。TCP不保证发送方发送的数据块和接收方接收的数据块一致，但保证程序接收到的字节流和程序发送的字节流一致。
TCP连接的端点叫做套接字或者插口。套接字是指将端口号拼接到IP地址之后，即：
每一条TCP连接唯一的被通信两端的两个端点所确定。即：
如图所示，A发送分组M1，发送完毕就暂停发送，等待B的确认,B收到了M1就向A发死你确认。A在收到了对M1的确认之后，就再发送下一个分组M2，以此类推。
如图所示，当B接收M1时检测出了差错，就丢弃M1，其他什么也不做。而A只要超过了一段时间没有收到确认，就会认为刚才发送的分组丢失了，因而重传前面发送过的分组，这就叫做超时重传，而实现超时重传则需要A为每一个已发送的分组都设置一个超时计时器。
需要注意以下三点：
（1）A在发送完一个分组后，必须暂时保留已发送的分组的副本。
（2）分组和确认分组必须编号，这样才能明确哪一个发出的分组收到了确认。
（3）超时计时器设置的重传时间应当比数据在分组传输的平均往返时间更长。
如图所示，B所发送的对M1确认丢失了，A在设定的超时重传时间内没有收到确认，所以无法知道自己发送的分组是怎样出错的，所以会重传M1，而当B又收到了重传的分组M1，这时应该采取两个行动：
（1）丢弃这个重复分组M1。
（2）向A发送确认。
还有一种情况就是在传输过程中没有出现差错，但B对分组M1的确认迟到了，而A会收到重复的确认，A收下后就会丢弃，B仍然会收到重复的M1，并且同样要丢弃重复的M1，并且重传确认分组。
停止等待协议的优点是简单，缺点则是信道的利用率太低。我们用TD表示A发送分组需要的时间，TA表示B发送确认分组需要的时间，RTT为往返时间，则：
为了提高传输的效率，发送方可以不使用低效率的停止等待协议，而是采用流水线传输的方式。即不必每发完一个分组就停下来等待对方的确认，这样就可以使信道上一直有数据在不间断的传送。
如图表示的是发送方维持的发送窗口，它指的是位于发送窗口内的5个分组都可以连续发送出去而不需要等待对方的确认。同时连续ARP协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。
对于接收方采用的则是累计确认的方式，即接收方不必对收到的分组逐个发送确认。而是在收到几个分组后，对按序到达的最后一个分组发送确认，这就表示：到这个分组为止的所有分组都已正确收到了。这种方式的优点是：容易实现，即使确认丢失也不必重传（意思是发送方不必重传）。但缺点是不能向发送方反映出接收方已经正确收到的所有分组信息。
TCP虽然是面向字节流的，但传送TCP的数据单元却是报文段。一个TCP报文段可以分为首部和数据两部分。
为了后面讲述的方便，我们假设数据传输只在一个方向进行，即A发送数据，B给出确认。
TCP的滑动窗口是以字节为单位的。如图所示，现在假定A收到了B发来的确认报文段，其中的窗口是20字节，而确认号是31，根据这2个数据，A就构造出自己的发送窗口。
发送窗口表示：在没有收到B的确认的情况下，A可以连续把窗口内的数据都发送出去。凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。发送窗口后面的部分表示已发送且已经收到了确认。而发送窗口前沿的部分表示不允许发送的。
现在假定A发送了序号为31~41的数据。这时发送窗口位置并未改变但是发送窗口内靠后面有11个字节表示已发送但是未收到确认。而发送窗口内靠前面的9个字节时允许发送但未发送的。如图所示：
而对于B，它的接收窗口大小是20，在接收窗口外面到30号位置的数据是接收并确认的，因此可以丢弃。在下图中，B收到了32和33的数据，但它们不是按序到达的，因为并没有收到31号数据。B只能对按序达收到的数据中的最高序号给出确认，因此B发送的确认报文字段的确认号依然是31号。
现在假定B收到了序号为31的数据，并把31～33的数据交付主机，然后B删除这些数据。接着把窗口向前移动3个序号，同时给a发送确认，其中的窗口值仍为20，但确认号变为34。表明B已经收到序号33为止的数据。
因为TCP的发送方在规定的时间内没有收到确认就要重传已经发送的报文段，但是重传时间的选择却TCP最复杂的问题之一。为此TCP采用了一种自适应算法，它记录了一个报文段发出的时间以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间RTT，同时TCP保留了RTT的加权平均往返时间RTTs。而RTTD是RTT的偏差加权平均值，它与RTTs和新的RTT样本之差有关。
超时重传时间的算法如下：
第一次测量时，加权平均往返时间取往返时间RTT，以后每次测量到一个新的RTT，按以下公式计算：
第一次测量时，RTT偏差的加权平均等于RTT的一半，以后的测里中，按以下公式计算：
综上超时重传时间RTO计算如下：
若收到的报文无差错，只是未按序号，使用选择确认SACK可是让发送方发送那些未收到的数据，而不重复发送已经收到的那些数据。如果要使用选择确认SACK，那么在建立TCP连接时，就要在TCP首部的选项中加上“允许SACK”的选项，并且双方必须都事先商量好。
流量控制就是指让发送方的发送速率不要太快，要让接收方来得及接收。而利用滑动窗口机制就可以很方便的在TCP连接上实现对发送方的流量控制。
如上图所示，接收方B进行了三次流量控制。第一次把窗口减小到rwnd=300，第二次又减到rwnd=100，最后是rwnd=0，即不允许发送方再发送数据了。
但是我们应该考虑一种情况，就是当接收方B的存储已满时，会向发送方发送零窗口的报文段，接着B的存储又有了一些空间，B再向A发送一个不为零的窗口值，但这个报文丢失了，结果就是双方一直等待下去。所以为了解决这个问题，TCP为每一个连接设有一个持续计时器。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器，当计时器到期后，就发送一个探测段文段，而对方就在确认这个探测段时给出了现在的窗口值。如果窗口仍然是0，那么收到这个报文段的一方就重新设置持续计时器，反之则死锁的僵局就可以打破了。
应用程序把数据传送到TCP的发送缓存后，TCP在何时发送这些数据？，在TCP的实现中广泛使用了Nagle算法。具体算法如下：
（1）若发送应用进程要把数据逐个字节地送到TCP的发送缓存，则发送方就把第一个数据字节先发出去，把后面到达的数据字节都缓存起来。
（2）方发送方收到对第一个数据字节的确认后，再把发送缓存中的所有数据组装成一个报文发送出去，同时继续对后续到来的数据进行缓存。
（3）只有收到对前一个报文段的确认后才继续发送下一个报文段。
当数据到达快而网络速度慢时，这种方法可以明显减少网络带宽。Nagle还规定：当到达的数据达到窗口的一半或最大报文长度时就立即发送一个报文。
但还还需要考虑一个叫做糊涂综合征的问题，具体内容是若接收方的缓存已满，应用进程每次只从缓存中取1个字节，然后向发送方确认，并把窗口设为1个字节（缓存只空了1个字节的空间），接着发送方发来1个字节，接收方发回确认，仍然将窗口设为1，这样进行下去，网络的利用率很低。
为了解决这个问题，可以让接收方等待一段时间，使得或者缓存已有足够的空间或者等到接收缓存已有一半的空闲空间。此时，接收方就发出确认报文，并向发送方通知当前窗口的大小。
拥塞 是指在某一段时间内，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就会变坏的情况。而所谓的 拥塞控制 就是防止过多的数据注入到网络当中，这样可以使网络中的路由器或者链路不致过载，它是一个全局性的过程，涉及到所有的主机和路由器，而流量控制往往是指点对点通信量的控制。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。
TCP进行拥塞控制的算法有4种：慢开始、拥塞避免、快重传和快恢复。下面在讨论这些算法时我们假定：
（1）数据是单方向传送的，对方只传送确认报文。
（2）接收方总是有足够大的缓存空间。
发送方维持一个拥塞窗口的状态变量，其大小取决于拥塞程度，并且动态变化。发送方让自己的发送窗口小于拥塞窗口（如果考虑接收方的接收能力的话，发送窗口可能小于拥塞窗口）。发送方控制拥塞窗口的原则是：只要网络没有拥塞，拥塞窗口就再增大一点，以便把更多的分组发送出去，只要出现拥塞，就减小拥塞窗口，以减少注入到网络的分组数。
下面会从“慢开始算法”讲起来讨论拥塞窗口的大小如何变化的。
慢开始的算法思路是：当主机开始发送数据时，由于并不清楚网络的负荷情况，所以如果立即把大量数据字节注入到网络中，就有可能引起网络拥塞。因此会采用由小逐渐增大发送窗口。即在通常开始发送报文时，先将拥塞窗口cwnd的值设为一个最大报文段MSS的数值，而在每收到一个新的报文段确认后，把拥塞窗口增加至多一个MSS的数值。
如上图所示，开始时cwnd=1，发送方发送一个M1，接收方收到M1发送确认，发送方收到一个确认后将cwnd加1，此时cwnd=2，因此发送方发送M2和M3两个报文段，接收方收到后返回两个确认，因此cwnd增加两次，此时cwnd=4，接着发送方发送M4～M7四个报文段。依次类推。因此使用慢开始算法后，每经过一个传输轮次，拥塞窗口就加倍。
但是为了防止拥塞窗口cwnd增加过大导致网络拥塞，需要设置一个慢开始门限ssthresh，慢开始门限用法如下：
当cwnd<ssthresh时，使用上述的慢开始算法。
当cwnd>ssthresh时，停止使用慢开始算法，使用拥塞避免算法。
当cwnd=ssthresh时，既可以使用慢开始算法，也可以使用拥塞避免算法。
这里的拥塞避免算法是指让拥塞窗口缓慢的增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是像慢开始阶段那样加倍增长。
需要注意的是无论在慢开始阶段还是拥塞避免阶段，只要发送方判断网络出现拥塞（根据是没有按时收到确认），立即把慢开始门限ssthresh设为出现拥塞时的发送窗口的一半。然后发送窗口cwnd重新设为1，执行慢开始算法。目的是迅速减少主机发送到网络分组的分组数。
快重传算法要求接收方每收到一个失序的报文段后就立即发送重复确认，如下图接收了M1和M2后，又接收到一个M4，M4属于失序报文，则发送对M2的重复确认。发送方只要连续收到三次确认重复就立即重传对方未收到的报文段M3。
与快重传算法配合的还有快恢复算法，过程如下：
（1）当发送方连续收到三个重复确认时，就把慢开始门限ssthresh减半，这是为了防止网络拥塞，接着并不执行慢开始算法。
（2）由于上图这种情况很可能不是因为网络拥塞引起的，因此这里不执行慢开始算法（即不把拥塞窗口cwnd设为1，这样速度太慢），而是把cwnd值设置为慢开始门限ssthresh减半后的数值，然后开始执行拥塞避免算法。
TCP的运输连接有是三个阶段：连接建立、数据传送和连接释放。在TCP的连接过程中要解决以下三个问题：
（1）要使每一方能够确知对方的存在。
（2）要允许双方协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量）。
（3）能够对运输实体资源进行分配。
TCP建立连接的过程叫做握手，握手需要在客户和服务器之间交换3个TCP报文段。如图是三报文握手建立的连接过程：
A最后还要发送一次确认的原因是为了防止已经失效的连接请求报文段突然又传送到了B，因而产生错误。试想一种情况：如果只有第一次和第二次握手，第二次B向A发送的确认丢失了，此时B进入了连接建立状态，A没有收到确认，过一段时间后会再次向B发送连接请求，B收到后又会再次建立连接，白白浪费B的资源。
A在TIME-WAIT状态等待2MSL（MSL，最长报文段寿命），主要是因为以下两点考虑：首先是为了保证A发送的最后一个ACK报文段能够到达B，因为这个ACK报文段可能丢失，此时B会重传连接释放报文，如果A已经关闭，则无法收到这个报文。其次，当A在发送完最后一个ACK报文段后，再经过时间2MSL，就可以使本连接持续时间内产生的所有报文段都从网络中消失。这样，下一个新连接中不会出现这种旧的连接请求报文段。
在图中每一个方框即TCP可能具有的状态。每个方框中的大写英文字符串时TCP标准所使用的的TCP连接状态名。状态之间的箭头表示可能发生的状态变迁。箭头旁边的字表明引起这种变迁的原因，或表明发生状态变迁后又出现什么动作，在图中粗实线箭头表示对客户进程的正常变迁，粗虚线箭头表示对服务器进程的正常变迁，细线箭头表示异常变迁。
F. 计算机网络的问题，麻烦知道的呃详细解答一下
很惭愧，我也不会。。
第一题，我的课本是谢希仁的计算机网络第六版，怎么没见到GBN在哪一层，你给我说一下，我们共同研究
第二题，没告诉数据传输率啊，怎么求Td呢？
第三题，这个我倒是懂，肯定是900才对。第一段数据应该是100-399，共300B，第一段确认号为400，第二段肯定是900啊，确认号就是说“900之前的都收到了”
G. 计算机网络——TCP三次握手四次挥手
用户进程和服务器进程需要完成一次通信都需要完成 三个阶段 ： 连接建立、数据传送、连接释放
参考：三次握手和四次挥手
首先先明确几个概念：
序列号seq（4B） ：用来标记数据段的顺序，TCP把连接中发送的所有数据字节都编上一个序号，第一个字节的编号由本地随机产生，给字节编上序号后，就给每一个报文段指派一个序号， 序列号seq就是这个报文段中的第一个字节的数据编号 。
确认号ack（4B） ： 期待收到对方下一个报文段的第一个数据字节的序号 ，序列号表示报文段携带数据的第一个字节的编号，而确认号指的是期望接受到下一个字节的编号，因此挡墙报文段最后一个字节的编号+1即是确认号。
确认ACK（1bit） ：仅当ACK=1，确认号字段才有效。ACK=0，确认号无效。
同步SYN ： 连接建立时 用于同步序号。SYN=1表示这是一个连接请求，或连接接收报文，SYN这个标志位只有在TCP建立连接才会被置为1，握手完成后SYN标志位被置为0.当SYN=1，ACK=0表示：这是一个连接请求报文段。若同意连接，则在响应报文段中使用SYN=1，ACK=1
终止FIN ：用来释放一个连接。
B的TCP服务器进程先创建传输控制块TCB，准备接受客户进程的连接请求。然后服务器进程就处于LISTEN（收听）状态，等待客户的连接请求。若有，则作出响应。
1）第一次握手：A首先向B发一个SYN (Synchronize) 标记的包，告诉B请求建立连接，一个 SYN包就是仅SYN标记设为1的TCP包(参见TCP包头Resources)， SYN=1的报文段不能携带数据 ，但要 消耗掉一个序号， 此时TCP客户进程进入SYN-SENT（同步已发送）状态。
2）第二次握手：B收到后会发一个对SYN包的确认包(SYN/ACK)回去，表示对第一个SYN包的确认，并继续握手操作.注意: SYN/ACK包是仅SYN 和 ACK 标记为1的包。在确认报文段中，测试TCP服务器进程进入SYN-RCVD（同步收到）状态；
3）第三次握手：TCP客户进程收到B的确认后，要向B给出确认报文段，ACK报文段可以携带数据，不携带数据则不消耗序号。TCP连接已经建立，A进入ESTABLISHED（已建立连接）。
当B收到A的确认后，也进入建立连接状态。
序列号和确认号的关系：
第一次握手序列号seq=x；
第二次握手序列号seq=y，确认号ack=x+1；
第三次握手序列号seq=x+1，确认号ack=y+1；
序列号seq是上一次的确认号，而确认号是上一次的序列号+1;这是因为SYN=1的报文段不能携带数据，但要消耗掉一个序号，所以下一个报文段要+1；
为了防止已经失效的连接请求报文段突然又传到服务端，因而产生错误”，这种情况是：一端(client)A发出去的第一个连接请求报文并没有丢失，而是因为某些未知的原因在某个网络节点上发生滞留，导致延迟到连接释放以后的某个时间才到达另一端(server)B。本来这是一个早已失效的报文段，但是B收到此失效的报文之后，会误认为是A再次发出的一个新的连接请求，于是B端就向A又发出确认报文，表示同意建立连接。如果不采用“三次握手”，那么只要B端发出确认报文就会认为新的连接已经建立了，但是A端并没有发出建立连接的请求，因此不会去向B端发送数据，B端没有收到数据就会一直等待，这样B端就会白白浪费掉很多资源。如果采用“三次握手”的话就不会出现这种情况，B端收到一个过时失效的报文段之后，向A端发出确认，此时A并没有要求建立连接，所以就不会向B端发送确认，这个时候B端也能够知道连接没有建立。（知乎上对上面的解释的评论：这个解答不是问题的本质，这个课本很多知识比较片面。问题的核心在于保证信道数据传输的可靠性，避免资源浪费仅仅是一个小的弱原因，不重要。）
从客户端到服务端释放连接的过程中，需要四次报文传输。
TCP四次挥手过程
1）A的应用进程先向其TCP发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据，主动关闭TCP连接，进入FIN-WAIT-1（终止等待1）状态，等待B的确认。
2）B收到连接释放报文段后即发出确认报文段，（ACK=1，确认号ack=u+1，序号seq=v），B进入CLOSE-WAIT（关闭等待）状态，此时的TCP处于半关闭状态，A到B的连接释放。
3）A收到B的确认后，进入FIN-WAIT-2（终止等待2）状态，等待B发出的连接释放报文段。
4）B没有要向A发出的数据，B发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），B进入LAST-ACK（最后确认）状态，等待A的确认。
5）A收到B的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），A进入TIME-WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，A才进入CLOSED状态。
大概就是A和B：
A：“我不和你说话了”
B：“知道了”
此时A单方面不和B说话，当B也没有话对A说的时候
B：“我也不和你说话了”
A：“好的”
两个人互相不说话了
TCP四次挥手总结
客户端发送FIN后，进入终止等待状态，服务器收到客户端连接释放报文段后，就立即给客户端发送确认，服务器就进入CLOSE_WAIT状态，此时TCP服务器进程就通知高层应用进程，因而从客户端到服务器的连接就释放了。此时是“半关闭状态”，即客户端不可以发送给服务器，服务器可以发送给客户端。
此时，如果服务器没有数据报发送给客户端，其应用程序就通知TCP释放连接，然后发送给客户端连接释放数据报，并等待确认。客户端发送确认后，进入TIME_WAIT状态，但是此时TCP连接还没有释放，然后经过等待计时器设置的2MSL后，才进入到CLOSE状态。
H. 计算机网络-可靠传输-停止等待协议
全双工通信的双方既是发送方也是接收方。下面为了讨论问题的方便，我们仅考虑A发送数据而B接收数据并发送确认。 因此A叫做发送方，而B叫做接收方 。因为这里是讨论可靠传输的原理，因此把传送的数据单元都称为分组，“停止等待”就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。
图5-9（a）是最简单的无差错情况。A发送分组M1,发完就暂停发送，等待B的确认。B收到了M1就向A发送确认。A在收到了对M1的确认后，就再发送下一个分组M2。同样，在收到B对M2的确认后，再发送M3。
图5-9(b)是分组在传输过程中出现差错的情况，B接收M时检测出了差错，就丢弃M1,其他什么也不做（不通知A收到有差错的分组）①。也可能是M1在传输过程中丢失了，这时B当然什么都不知道。在这两种情况下，B都不会发送任何信息。可靠传输协议是这样设计的：A只要超过了一段时间仍然没有收到确认，就认为刚才发送的分组丢失了，因而重传前面发送过的分组。这就叫做 超时重传 。要实现超时重传，就要在每发送完一个分组时设置一个 超时计时器 。如果在超时计时器到期之前收到了对方的确认，就撤销已设置的超时计时器。其实在图5-9(a)中，A为每一个己发送的分组都设置了一个超时计时器。但A只要在超时计时器到期之前收到了相应的确认，就撤销该超时计时器。
这里应注意以下三点：
第一，A在发递完一个分组后，必须暂时保留已发送的分组的副本（在发生超时重传时使用)。只有在收到相应的确认后才能清除暂时保留的分组副本。
第二，分组和确认分组都必须进行编号②。这样才能明确是哪一个发送出去的分组收到了确认，而哪一个分组还没有收到确认。
①注：在可靠传输的协议中，也可以在检测出有差错时发送“否认报文”给对方。这样做的好处是能够让发送方及早如道出现了差错。不过由于这样处理会使协议复杂化，现在实用的可靠传输协议都不使用这种否认报文了。
②注：编号并不是一个非常简单的问题。分组编号使用的位数总是有限的，同一个号码会重复使用。例如，10位的编号范围是0~1023。当编号增加到1023时，再增加一个号就又回到0，然后重复使用这些号码。因此，在所发送的分组中，必须能够区分开哪些是新发送的，哪些是重传的。对于简单链路上传送的帧，如采用停止等待协议，只要用1位编号即可，也就是发送完0号帧，收到确认后，再发送1号帧，收到确认后，再发送0号帧。但是在运输层，这种编号方法有时并不能保证可靠传输。
第三，超时计时器设置的重传时间应当比数据在分组传输的平均往返时间更长一些。图5-9(b)中的一段虚线表示如果M正确到达B同时A也正确收到确认的过程。可见重传时间应设定为比平均往返时间更长一些。显然，如果重传时间设定得很长，那么通信的效率就会很低。但如果重传时间设定得太短，以致产生不必要的重传，就浪费了网络资源。然而，在运输层重传时间的准确设定是非常复杂的，这是因为已发送出的分组到底会经过哪些网络，以及这些网络将会产生多大的时延（这取决于这些网络当时的拥塞情况），这些都是不确定因素。图5-9中把往返时间当作固定的（这并不符合网络的实际情况），只是为了讲述原理的方便，关于重传时间应如何选择， 选择确认SACK 。
图5-10(b)说明的是另一种情况，B所发送的对M1的确认丢失了。A在设定的超时重传时间内没有收到确认，并无法知道是自己发送的分组出铝、丢失，或者是B发送的确认丢失了。因此A在超时计时器到期后就要重传M1,现在应注意B的动作，假定B又收到了重传的分组M1。这时应采取两个行动。第一，丢弃这个重复的分组M1,不向上层交付；第二，向A发送确认，不能认为已经发送过确认就不再发送，因为A之所以重传M1就表示A没有收到对M,的确认。
图5-10(b)也是一种可能出现的情况。传输过程中没有出现差错，但B对分组M1的确认迟到了。A会收到重复的确认。对重复的确认的处理很简单：收下后就丢弃。B仍然会收到重复的M1,并且同样要丢弃重复的M1,并重传确认分组。
通常A最终总是可以收到对所有发出的分组的确认。如果A不断重传分组但总是收不到确认，就说明通信线路太差，不能进行通信。
使用上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信。
这种可靠传输协议常称为 自动重传请求ARQ (Automatic Repeat reQuest)。意思是重传的请求是自动进行的。接收方不需要请求发送方重传某个出错的分组。
停止等待协议的优点是简单，但缺点是信道利用率太低。我们可以用图5-11来说明这个问题。为简单起见，假定在A和B之间有一条直通的信道来传送分组。
假定A发送分组需要的时间是TD。显然，TD等于分组长度除以数据率。再假定分组正确到达B后，B处理分组的时间可以忽略不计，同时立即发回确认。假定B发送 确认分组需要时间TA 。如果A处理确认分组的时间也可以忽略不计，那么A在经过时间(TD+RTT+TA)后就可以再发送下一个分组，这里的RTT是往返时间。因为仅仅是在时间TD内才用来传送有用的数据（包括分组的首部），因此信道的利用率U可用下式计算： U=TD/TD +RTT+TA (5-3)
请注意，更细致的计算还可以在上式分子的时间TD内扣除传送控制信息（如首部）所花费的时间。但在进行粗略计算时，用近似的式(5-3)就可以了。
我们知道，(5-3)式中的往返时间RTT取决于所使用的信道。例如，假定1200km的信道的往返时间RTT=20ms。分组长度是1200bit,发送速率是1Mbit/s。若忽略处理时间和TA(TA一般都远小于TD)， TD=1200/1*10^6 ，信道的利用率U=5.66%。但若把发送速率提高到10Mbit/s,则U=5.96×10^(-4)。信道在绝大多数时间内都是空闲的。
从图5-11还可看出，当往返时间RTT远大于分组发送时间TD时，信道的利用率就会非常低。还应注意的是，图5-11并没有考虑出现差错后的分组重传。若出现重传，则对传送有用的数据信息来说，信道的利用率就还要降低。
为了提高传输效率，发送方可以不使用低效率的停止等待协议，而是采用流水线传输(如图5-12所示)。流水线传输就是发送方可连续发送多个分组，不必每发完一个分组就停顿下来等待对方的确认。这样可使信道上一真有数据不间断地在传送。显然，这种传输方式可以获得很高的信道利用率。
I. 运输层知识要点——谢希仁《计算机网络》
为了在计算机网络中有条不紊地交换数据，就必须遵守一些事先约定好的规则。这些规则明确规定了所 交换数据的格式 以及有关的 同步 问题。
同步的含义：在一定条件下应当发生什么事件，因而含有时序的意思。
网络协议：为进行网络中的数据交换而建立的规则、标准或约定。
网络协议由以下三个要素组成：
1）语法：即数据与控制信息的结构或格式
2）语义：即需要发出何种控制信息，完成何种动作以及做出何种反应
3）同步：即事件实现顺序的详细说明
一、运输层协议的概述
1.1 进程之间的通信
1.2 运输层的两个主要协议
1.3 运输层的端口
二、用户数据报协议UDP
2.1 UDP概述
2.2 UDP的首部格式
三、传输控制协议TCP概述
3.1 TCP的最主要的特点
3.2 TCP的连接
四、可靠传输的工作原理
4.1 停止等待协议
4.2 连续ARQ协议
五、TCP报文段的首部格式
六、TCP可靠传输的实现
6.1 以字节为单位的滑动窗口
6.2 超时重传时间的选择
6.3 选择确认SACK
七、TCP的流量控制
7.1 利用滑动窗口实现流量控制
7.2 必须考虑传输效率
八、TCP的拥塞控制
8.1 拥塞控制的一般原理
8.2 几种拥塞控制方法
8.3 随机早期检测RED
九、TCP的运输连接管理
9.1 TCP的连接建立
9.2 TCP的连接释放
9.3 TCP的有限状态机
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
1.1 进程之间的通信
1.只有主机的协议栈才有运输层，而网络核心部分中的路由器在转发分组时都只用到了下三层的功能
2.两个主机进行通信就是两个主机中的应用进程互相通信。从运输层的角度看，通信的真正端点并不是主机而是主机中的进程。（IP协议能把分组送到目的主机）
网络层时为主机之间提供逻辑通信，而运输层为应用进程之间提供端到端的逻辑通信。
3.运输层一个重要功能——复用、分用。 （应用进程复用、分用运输层）
1.2 运输层的两个主要协议
1.UDP—User Datagram Protocol 用户数据报协议（无连接）：DNS/RIP/DHCP/SNMP/NFS
TCP—Transmission Control Protocol 传输控制协议（面向连接）：SMTP/TELNET/HTTP/ FTP
1.3 运输层的端口
问题：为了使运行不同操作系统的计算机的应用进程能够互相通信，就必须使用统一的方法（而这种方法必须与特定操作系统无关）对TCP/IP体系的应用进程进行标识。
为什么不用进程号来区分？（第一，不同操作系统的进程标识符不同；第二，用功能来识别，而不是进程，例如邮件服务功能，而不管具体是哪个进程）
解决方案：在运输层使用协议端口号，即端口。软件端口是应用层的各种协议进程与运输实体进行层间交互的一种地址。（端口号只具有本地意义，只是为了标识本计算机应用层中各个进程在和运输层交互时的层间接口。）
端口分为两大类：
1）服务器使用的端口号：熟知端口号或系统端口号（0~1023）；登记端口号（1024~49151）
2）客户端使用的端口号：49152~65535
2.1 UDP概述
1.UDP只在IP的数据报服务至上增加了很少一点功能，就是复用、分用以及差错检测功能
2.特点
1）无连接
2）尽最大努力交付
3）面向报文 （不合并、不拆分、保留这些报文的边界）
4）UDP没有拥塞控制
5）UDP支持一对一、一对多、多对一和多对多的交互通信
6）UDP的首部开销小，只有8字节
应用进程本身可以在不影响应用的实时性的前提下，增加一些提高可靠性的措施，如采用前向纠错或重传已丢失的报文。
2.2 UDP的首部格式
1.traceroute 让发送的UDP用户数据报故意使用一个非法的UDP端口号，接收方丢弃报文，并由ICMP（网络控制报文协议）发送“端口不可达”差错报文给发送方。
2.计算检验和。IP数据报的校验和只检验IP数据报的首部，但UDP的校验和是把首部和数据部分一起都检验。（12字节的首部+真正的首部+数据来进行校验和的计算）
Q1.为什么计算校验和要加12字节的伪首部
Q2.计算校验和的原理是什么？
3.1 TCP的最主要的特点
1.面向连接的运输层协议（建立连接、传输数据、释放连接）
2.点对点，每一条TCP连接只能有两个端点
3.可靠交付（无差错、不丢失、不重复、并且按序到达）
4.全双工通信。TCP连接的两端都设有发送缓存和接收缓存。
5.面向字节流。（流指的是流入到进程或从进程流出的字节序列；面向字节流：TCP把应用程序交下来的数据看成是一连串的无结构字节流。 接收方的应用程序必须有能力识别接收到的字节流，把它还原成有意义的应用层数据。 因此TCP可以根据窗口值和当前网络状况调整发送的报文长度。划分短一点，或者积累到足够多再发送出去。）
3.2 TCP的连接
1.TCP把连接作为最基本的抽象。
2.每一条TCP连接有两个端点。TCP连接的端点叫作套接字。
套接字soket = （IP地址：端口号）
每一条TCP连接唯一地被通信两端的两个端点（即两个套接字）所确定。
TCP连接 ::= {socket1, socket2}
理想的传输条件有以下两个特点：
1）传输信道不产生差错
2）不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据
实际的网络并不具备，因此：
1）出现差错时，让发送方重传
2）接收方来不及处理时，及时告诉发送方适当降低发送数据的速度
4.1 停止等待协议
1.“停止等待”就是没发送完一个分组就停止发送，等待对方的确认，在收到确认后再发送下一个分组。
2.超时重传。在每发完一个分组就设置一个超时计时器，如果在超时计时器之前收到对方的确认，就撤销已设置的超时计时器。如果未收到，就认为刚才的分组丢失，并重传。
3.三种情况：A发送的分组出错、丢失；B发送的确认丢失；B发送的确认迟到
确认丢失：B丢弃重复的分组，向A重传确认
确认迟到：A丢弃重复的确认，B丢弃重复分组，并向A重传确认
4.常称为自动重传请求ARQ，重传时自动进行的（超时即重传）
5.缺点：信道利用率太低
U=Td/(Td+RTT+Ta)
为了提高传输效率，发送方不使用停止等待协议，而是采用流水线传输。流水线传输就是发送发可连续发送多个分组，不必等每发完一个分组就停顿下来等待对方的确认。（连续ARQ协议和滑动窗口协议）
4.2 连续ARQ协议
1.位于发送窗口内的分组都可连续发送出去，而不需要等待对方的确认。
2.累积确认：接收方不必对收到的分组逐个发送确认，而是在收到几个分组后，对按序到达的最后一个分组发送确认。
3.缺点：Go-back-N （发送前5个分组，第3个分组丢失，后面三个要重传）
1.源端口和目的端口
2.序号。 每个字节都按顺序编号。
3.确认号。 期望收到对方下一个报文段的第一个数据字节的序号。
若确认号=N，则表明：到序号N-1为止的所有数据都已正确收到。
4.数据偏移。 指出TCP报文段的数据起始处距离TCP报文段的起始处有多远（也即TCP报文段首部长度）。由于首部中还有长度不确定的选项字段，因此数据偏移字段是必要的。
5.窗口。窗口字段明确指出了现在允许对方发送的数据量。窗口值是经常在动态变化着。
6.1 以字节为单位的滑动窗口
1.发送缓存用来暂存：
1）发送应用程序传送给发送方TCP准备发送的数据；
2）TCP已发送但未收到确认德尔数据
2.接收缓存用来存放：
1）按序到达的、但尚未被接收应收程序读取的数据；
2）未按序到达的数据
3.注意三点：
1）A的发送窗口是根据B的接收窗口设置的，但是在同一时刻，由于网络传输的滞后，A的发送窗口并不总是B的接收窗口一样大
2）TCP通常对不按序到达的数据是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程
3）TCP接收方有累计确认功能（不能过分推迟发送确认，否则会导致发送方不必要的重传）
6.2 超时重传时间的选择
1.超时重传时间设置太短，会引起很多不必要的重传；如果设置太长，使网络的空闲时间增大，降低传输效率。
2.新的RTTs = (1-a)x(旧的RTTs) + ax（新的RTT样本），其中RTT样本的时间为：记录一个报文段发出的时间，以及收到相应的确认时间，时间差就是报文段的往返时间RTT。
3.RTO = RTTs + 4 x RTTd，其中RTO为超时重传时间，RTTd是RTT的偏差的加权平均值。
新的RTTd = (1-b) x （旧的RTTd）+ b x |RTTs - 新的RTT样本|
4.一个问题：发送一个报文段，设定的重传时间到了，还没有收到确认。于是重传报文段。经过一段时间，收到了确认报文段。现在的问题是：如何判定此确认报文段是对先发送的报文段的确认，还是对后来重传的报文段的确认？
1）解决方法1，在计算加权平均值RTTs时，只要报文段重传了，就不采用其往返时间样本。
引入的问题：报文段的时延突然增大的情况
2）解决方法2，报文段每重传一次，就把超时重传时间RTO增大一些（一般是2倍）。当不在发生报文段的重传时，再根据加权平均计算。
6.3 选择确认SACK
SACK文档并没有指明发送发应当怎样响应SACK。因此大多数的实现还是重传所有未被确认的数据块。
7.1 利用滑动窗口实现流量控制
1.流量控制：就是让发送方的发送速率不要太快，要让接收方来得及接收。
2.利用滑动窗口机制可很方便地在TCP连接上实现对发送方的流量控制。发送方的发送窗口不能超过接收方给出的接收窗口的数值。
3.死锁情况：B向A发送了零窗口的报文段后不久，B又有了一些缓存空间，因此B向A发送rwnd = 400.然而该报文段在传送过程中丢失。A一直等待B发送的非零窗口的通知，B也一直等待A发送的数据。（ 窗口通知不超时重传？为什么？ ）
解决方法：TCP为每个连接设有一个持续计时器。只要一方收到对方的零窗口通知，就启动计时器。计时器到期后，发送一个零窗口探测报文段，而对方就在确认这个探测报文段时给出了现在的窗口值。若仍为零，收到报文段的一方重新设置持续计时器。
7.2 必须考虑传输效率
1.应用程序把数据传送到TCP的发送缓存后，剩下的发送任务就由TCP来控制了。
2.三种不同的机制来控制TCP报文段的发送时机：
1）TCP维持一个变量，它等于最大报文段长度MSS，只要缓存中的存放的数据达到MSS，就组装成一个TCP报文段发送出去
2）由发送方的应用进程指明要求发送报文段，即TCP支持推送操作
3）发送方设置一个定时器
3.问题一、若用户只发送一个字节，则非常浪费带宽。
解决方法：若发送应用程序把要发送的数据逐个字节地送到TCP的发送缓存，则发送方就把第一个数据字节先发送出去，把后面到达的数据字节都缓存起来。当发送方收到对第一个数据字符的确认后，再把发送缓存中的所有数据组装成一个报文段发送出去。（采用收到确认就发送+并开始缓存的方式；同时当到达的数据已达到发送窗口大小的一半或已达到报文段的最大长度时，就立即发送一个报文段。）
4.问题二、糊涂窗口综合症。接收缓存已满，应用程序一次只读取一个字节，然后向发送方发送确认。
解决方法：让接收方等待一段时间，使得接收缓存已有足够空间容纳一个最长的报文段，或者等到接收缓存已有一半空闲的空间。则接收方就发出确认报文。
8.1 拥塞控制的一般原理
1.拥塞的定义：对资源的需求 > 可用资源。 在计算机网络中的链路带宽、交换结点中的缓存和处理机等，都是网络中的资源。
2.拥塞解决不能靠解决某一个部分的问题。因为这会将瓶颈转移到其他地方。问题的实质往往是整个系统的各个部分不匹配。只有所有部分都平衡了，问题才会得到解决。
3.拥塞控制与流量控制的比较。
1）拥塞控制：防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。
拥塞控制有个前提：网络能够承受现有的网络负荷
拥塞控制是一个全局性过程。（发送拥塞时，不知道在某处、什么原因造成的）
2）流量控制：点对点通信量的控制，是个端到端的问题
流量控制：抑制发送端发送数据的速率，以便使接收端来得及接收。
4.寻找拥塞控制的方案无非就是使不等式 “对资源的需求 > 可用资源 ”不再成立的条件。但是必须考虑该措施带来的其他影响。
5.计算机网络是个复杂的系统。从控制理论的角度来看拥塞控制，可以分为开环控制和闭环控制两种方法。
1）开环控制：设计网络时事先将有关发生拥塞的因素考虑周到，力求网络在工作时不产生拥塞。但一旦系统运行起来，就不再中途改正。
2）闭环控制：基于反馈环路。
步骤一、监测网络系统以便检测到拥塞在何时、何处发生；
步骤二、把拥塞发生的信息传送到可采取行动的地方
步骤三、调整网络系统的运行以解决出现的问题
8.2 几种拥塞控制方法（只考虑网络拥塞程度，即假设接收方总是有足够大的缓存空间）
1.慢开始和拥塞避免
1）发送方维持一个拥塞窗口。
拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。
控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口增大；如果网络出现拥塞，则减小。
2）慢开始的思路：由小到大逐渐增大拥塞窗口数值。每收到一个对新的报文段的确认，把拥塞窗口增加至多一个MSS的数值。（没经过一个传输轮次，拥塞窗口cwnd就加倍）
轮次：把拥塞窗口所允许发送的报文段都连续发送出去，并收到了对已发送的最后一字节的确认。
慢开始的“慢”并不是指cwnd的增长速率慢，而是指TCP开始发送报文段时先设置cwnd=1（一个MSS数值）。
3）慢开始门限ssthresh
为防止拥塞窗口增长过大，引入一个慢开始门限ssthresh。
当cwnd < ssthresh时，使用上述的慢开始算法
当cwnd > ssthresh时，停止使用慢开始算法而改用拥塞避免算法
4）拥塞避免算法
思路：让拥塞窗口cwnd缓慢增大，即没经过一个往返时间RTT就把发送方的拥塞窗口cwnd增加1，而不是加倍。
5）慢开始门限的设置
只要发送方判断网络出现拥塞（没有按时收到确认），就把慢开始门限ssthresh设置为出现拥塞时发送方窗口值的一半，然后把拥塞窗口cwnd重置为1，执行慢开始算法。
6）乘法减小和加法增大
乘法减小：网络出现拥塞时，把慢开始门限ssthresh减半（当前的ssthresh的一半），并执行慢开始算法。
加法增大：执行拥塞避免方法
2.快重传和快恢复
1）快重传（尽快重传未被确认的报文段）
首先，要求接收方每收到一个失序的报文段后就立即发出重复确认。（如接收方收到了M1和M2后都分别发出了确认，但接收方没有收到M3但接着收到了M4。此时接收方立即发送对M2的重复确认。）
其次，发送方只要一连收到三个重复确认，就应当立即重传对方尚未收到的报文段M3.
2）快恢复
要点一、当发送方连续收到三个重复确认，就执行“乘法减小”算法，把慢开始门限ssthresh减半。
要点二、由于发送方认为网络很可能没有发生拥塞（因为收到了连续的重复确认），把cwnd设置为慢开始门限ssthresh减半后的值，然后开始执行拥塞避免算法
慢开始算法只在TCP连接建立时和网络出现超时才使用。
3.发送方的窗口
发送方窗口的上限值 = Min [rwnd, cwnd]
8.3 随机早期检测RED（IP层影响TCP层的拥塞控制）
1.网络层的分组丢弃策略
网络层的策略对TCP拥塞控制影响最大的就是路由器的分组丢弃策略。
如果路由器队列已满，则后续到达的分组将都被丢弃。这就叫做尾部丢弃策略。
2.全局同步
由于TCP复用IP，若发生路由器中的尾部丢弃，就可能会同时影响到很多条TCP连接，结果就使许多TCP连接在同一时间突然都进入到慢开始状态。全局同步使得全网的通信量突然下降了很多，网络恢复正常后，其通信量又突然增大很多。
3.随机早期检测RED
使路由器的队列维持两个参数，即队列长度最小门限THmin和最大门限THmax。当每一个分组到达时，RED就先计算平均队列长度Lav。RED算法是：
1）若平均队列长度小于最小门限THmin，则把新到达的分组放入队列进行排队
2）若平均队列长度超过最大门限THmax，则把新到达的分组丢弃
3）若平均队列长度在最小门限THmin和最大门限THmax之间，则按照某一概率p将新到达的分组丢弃。
随机体现在3），在检测到网络拥塞的早期征兆时（即路由器的平均队列长度超过一定的门限值时），就先以概率p随机丢弃个别的分组，让拥塞控制只在个别的TCP连接上进行，因而避免发生全局性的拥塞控制。
4.平均队列长度Lav和分组丢弃概率p
Lav = (1-d) x (旧的Lav) +d x (当前的队列长度样本)
p = ptemp / (1- count x ptemp)
ptemp = pmax x (Lav - THmin) / (THmax - THmin)
TCP时面向连接的协议。
运输连接就有三个阶段：连接建立、数据传送和连接释放
运输连接的管理：使运输连接的建立和释放都能正常地进行。
在TCP连接建立过程中要解决以下三个问题：
1）要使每一方能够确知对方的存在
2）要允许双方协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳等等）
3）能够对运输实体资源（如缓存大小、连接表中的项目等）进行分配
9.1 TCP的连接建立
1.TCP规定，SYN=1报文段不能携带数据，但消耗一个序号
2.TCP规定，ACK=1报文段可以携带数据，如果不携带数据则不消耗序号
3.为什么A还要发送一次确认？为了防止已失效的连接请求报文突然又传送到B，因而产生错误。
“已失效的连接请求报文段”
A发出第一个连接请求报文段，在网络中滞留超时，又发出了第二个连接请求。但B收到第一个延迟的失效的连接请求报文段后，就误认为是A又发出了一次新的连接请求。于是就向A发出确认报文段，同意建立连接。假定不采用三次握手，那么只要B发出确认，新的连接就建立。此时A不会理睬B的确认，也不会发数据，但B一直等A发送数据，B的许多资源就浪费了。
采用三次握手，A不会向B发送确认，因此B就知道A并没有要求建立确认。
9.2 TCP的连接释放
1.TCP规定，FIN报文段基石不携带数据，也消耗一个序号
2.第二次握手后，TCP通知高层应用程序，因而从A到B这个方向的连接就释放，TCP连接处于半关闭状态
3.为什么A在TIME-WAIT状态必须等待2MSL的时间
1）为了保证A发送的最后一个ACK报文段能够到达B。因为ACK可能丢失，此时B可能会超时重传，然后A重传确认，并重新启动2MSL计时器
2）防止“已失效的连接请求报文段”出现在本连接中。可以使本连接持续时间内所产生的所有报文段都从网络中消失。
9.3 TCP的有限状态机