计算机网络中的往返时间用图表示

① 计算机网络-可靠传输-停止等待协议

全双工通信的双方既是发送方也是接收方。下面为了讨论问题的方便，我们仅考虑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所示)。流水线传输就是发送方可连续发送多个分组，不必每发完一个分组就停顿下来等待对方的确认。这样可使信道上一真有数据不间断地在传送。显然，这种传输方式可以获得很高的信道利用率。

② 什么是RTT计算机网络里的东西

RTT(Round-Trip Time)：往返时延。是指数据从网络一端传到另一端所需的时间。通常，时延由发送时延、传播时延、排队时延、处理时延四个部分组成。

（1）发送时延

发送时延是结点将数据分组发送到传输媒介所需要的时间，也就是从分组的第一个比特开始发送算起，到最后一个比特发送完毕所需要的时间。显然，发送时延与网络接口/信道的传输速率成反比，与数据分组的长度成正比。

（2）传播时延

传播时延是电磁波在信道中传播一定距离所需要花费的时间，传播时延和信道的传输速率无关，
而是取决于传输媒介的长度，以及某种物理形式的信号在传输媒介中的传播速度。

如电磁波在自由空间的传播速度是光速，即3×105km/s。电磁波在网络传输媒体中的传播速度比在自由空间中的传播速度要略低一些，在铜线中的传播速度约为2.3×105km/s
，在光纤中的传播速度约为2.0×105km/s 。

（3）排队时延

排队时延是分组在所经过的网络结点的缓存队列中排队所经历的时延，排队时延的长短主要取决于网络中当时的通信量，当网络的通信流量大时，排队时间就长，极端情况下，当网络发生拥塞导致分组丢失时，该结点的排队时延视为无穷大。

此外，在有优先级算法的网络中，排队时延还取决于数据的优先级和结点的队列调度算法。

（4）处理时延

处理时延是分组在中间结点的存储转发过程中而进行的一些必要的处理所花费的时间，这些处理包括提取分组的首部，进行差错校验，为分组寻址和选路等。

(2)计算机网络中的往返时间用图表示扩展阅读

网络端到端的时延是几种时延的总合，其计算公式是：

总时延=传播时延+发送时延+排队时延+处理时延

根据网络的不同情况，有时有些时延可以忽略不计，如在局域网中，传播时延很小可以忽略不计；当网络没有拥塞时，分组在各个结点的排队时延可以忽略不计。

往返时延（Round-Trip Time，RTT）也是一个重要的性能指标，它表示从发送方发送数据开始，到发送方收到来自接收方的确认，总共经历的时延。对于复杂的网络，往返时延要包括各中间结点的处理时延和转发数据时的发送时延。

③ 计算机网络——TCP/UDP协议

计算机网络七层模型中，传输层有两个重要的协议：
（1）用户数据报协议UDP (User Datagram Protocol)
（2）传输控制协议TCP (Transmission Control Protocol)

UDP 在传送数据之前不需要先建立连接。远地主机的运输层在收到UDP 报文后，不需要给出任何确认。虽然UDP 不提供可靠交付，但在某些情况下UDP 却是一种最有效的工作方式。

TCP 则提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。TCP 不提供广播或多播服务。由于TCP 要提供可靠的、面向连接的运输服务，因此不可避免地增加了许多的开销，如确认、流量控制、计时器以及连接管理等。

UDP 的主要特点是：

首部手段很简单，只有8 个字节，由四个字段组成，每个字段的长度都是两个字节。

前面已经讲过，每条TCP 连接有两个端点，TCP 连接的端点叫做套接字（socket）或插口。套接字格式如下：

套接宁socket= (IP 地址：端口号’）

每一条TCP 连接唯一地被通信两端的两个端点（即两个套接宇）所确定。即：
TCP 连接＝ {socket1, socket2} = {(IP1: port1), (IP2: port2)}

3次握手链接

4次握手释放链接

断开连接请求可以由客户端发出，也可以由服务器端发出，在这里我们称A端向B端请求断开连接。

各个状态节点解释如下：

下面为了讨论问题的万便，我们仅考虑A发送数据而B 接收数据并发送确认。因此A 叫做发送方，而B 叫做接收方。

“停止等待”就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。

使用上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信。像上述的这种可靠传输协议常称为自动重传请求ARQ (Automatic Repeat reQuest）。意思是重传的请求是自动进行的。接收方不需要请求发送方重传某个出错的分组。

滑动窗口协议比较复杂，是TCP 协议的精髓所在。这里先给出连续ARQ 协议最基本的概念，但不涉提到许多细节问题。详细的滑动窗口协议将在后面讨论。

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

连续ARQ 协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。

接收方一般都是采用 累积确认 的方式。这就是说，接收方不必对收到的分组逐个发送确认，而是可以在收到几个分组后，对按序到达的最后一个分组发送确认，这样就表示：到这个分组为止的所有分组都己正确收到了。

累积确认 的优点是容易实现，即使确认丢失也不必重传。但缺点是不能向发送方反映出接收方己经正确收到的所有分组的信息。

例如，如果发送方发送了前5 个分组，而中间的第3 个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落，而只好把后面的三个分组都再重传一次。这就叫做Go-back-N （回退N ），表示需要再退回来重传己发送过的N 个分组。可见当通信线路质量不好时，连续ARQ 协议会带来负面的影响。

TCP 的滑动窗口是以字节为单位的。现假定A 收到了B 发来的确认报文段，其中窗口是20 （字节），而确认号是31 （这表明B 期望收到的下一个序号是31 ，而序号30 为止的数据己经收到了）。根据这两个数据， A 就构造出自己的发送窗口，其位置如图所示。

发送窗口表示：在没有收到B 的确认的情况下， A可以连续把窗口内的数据都发送出去。凡是己经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。

发送窗口后沿的后面部分表示己发送且己收到了确认。这些数据显然不需要再保留了。而发送窗口前沿的前面部分表示不允许发送的，因为接收方都没有为这部分数据保留临时存放的缓存空间。

现在假定A 发送了序号为31 ～ 41 的数据。这时发送窗口位置并未改变，但发送窗口内靠后面有11个字节（灰色小方框表示）表示己发送但未收到确认。而发送窗口内靠前面的9 个字节（ 42 ～ 50 ）是允许发送但尚未发送的。】

再看一下B 的接收窗口。B 的接收窗口大小是20，在接收窗口外面，到30 号为止的数据是已经发送过确认，并且己经交付给主机了。因此在B 可以不再保留这些数据。接收窗口内的序号（31～50）足允许接收的。B 收到了序号为32 和33 的数据，这些数据没有按序到达，因为序号为31 的数据没有收到（也许丢失了，也许滞留在网络中的某处）。 请注意， B 只能对按序收到的数据中的最高序号给出确认，因此B 发送的确认报文段中的确认号仍然是31 （即期望收到的序号）。

现在假定B 收到了序号为31 的数据，并把序号为31～33的数据交付给主机，然后B删除这些数据。接着把接收窗口向前移动3个序号，同时给A 发送确认，其中窗口值仍为20，但确认号是34，这表明B 已经收到了到序号33 为止的数据。我们注意到，B还收到了序号为37, 38 和40 的数据，但这些都没有按序到达，只能先存在接收窗口。A收到B的确认后，就可以把发送窗口向前滑动3个序号，指针P2 不动。可以看出，现在A 的可用窗口增大了，可发送的序号范围是42～53。整个过程如下图：

A 在继续发送完序号42-53的数据后，指针P2向前移动和P3重合。发送窗口内的序号都已用完，但还没有再收到确认。由于A 的发送窗口己满，可用窗口己减小到0，因此必须停止发送。

上面已经讲到， TCP 的发送方在规定的时间内没有收到确认就要重传已发送的报文段。这种重传的概念是很简单的，但重传时间的选择却是TCP 最复杂的问题之一。

TCP采用了一种自适应算法 ，它记录一个报文段发出的时间，以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间RTT，TCP 保留了RTT的一个加权平均往返时间RTTs （这又称为平滑的往返时间， S 表示Smoothed 。因为进行的是加权平均，因此得出的结果更加平滑）。每当第一次测量到RTT样本时， RTTs值就取为所测量到的RTT样本值。但以后每测量到一个新的RTT样本，就按下式重新计算一次RTTs:

新的RTTs = (1 － α）×（旧的RTTs) ＋ α ×（新的RTT样本）

α 越大表示新的RTTs受新的RTT样本的影响越大。推荐的α 值为0.125，用这种方法得出的加权平均往返时间RTTs 就比测量出的RTT值更加平滑。

显然，超时计时器设置的超时重传时间RTO (RetransmissionTime-Out）应略大于上面得出的加权平均往返时间RTTs。RFC 2988 建议使用下式计算RTO:

RTO = RTTs + 4 × RTTd

RTTd是RTT 的偏差的加权平均值，它与RTTs和新的RTT样本之差有关。计算公式如下：

新的RTTd= (1- β）×（旧的RTTd) + β × |RTTs－新的RTT样本|

发现问题： 如图所示，发送出一个报文段。设定的重传时间到了，还没有收到确认。于是重
传报文段。经过了一段时间后，收到了确认报文段。现在的问题是：如何判定此确认报文段是对先发送的报文段的确认，还是对后来重传的报文段的确认？

若收到的确认是对重传报文段的确认，但却被源主机当成是对原来的报文段的确认，则这样计算出的RTTs 和超时重传时间RTO 就会偏大。若后面再发送的报文段又是经过重传后才收到确认报文段，则按此方法得出的超时重传时间RTO 就越来越长。

若收到的确认是对原来的报文段的确认，但被当成是对重传报文段的确认，则由此计算出的RTTs 和RTO 都会偏小。这就必然导致报文段过多地重传。这样就有可能使RTO 越来越短。

Kam 提出了一个算法：在计算加权平均RTTs 时，只要报文段重传了就不采用其往返时间样本。这样得出的加权平均RTTs 和RTO 就较准确。

新问题： 设想出现这样的情况：报文段的时延突然增大了很多。因此在原来得出的重传时间内，不会收到确认报文段。于是就重传报文段。但根据Kam 算法，不考虑重传的报文段的往返时间样本。这样，超时重传时间就无法更新。

解决方案： 对Kam 算法进行修正，方法是z报文段每重传一次，就把超时重传时间RTO 增大一些。典型的做法是取新的重传时间为2 倍的旧的重传时间。当不再发生报文段的重传时，才根据上面给出的公式计算超时重传时间。

流量控制（flow control）就是让发送方的发送速率不要太快，要让接收方来得及接收。

利用滑动窗口机制可以很方便地在TCP 连接上实现对发送方的流量控制。

接收方的主机B 进行了三次流量控制。第一次把窗口减小到rwnd =300，第二次又减到rwnd = 100 ，最后减到rwnd = 0 ，即不允许发送方再发送数据了。这种使发送方暂停发送的状态将持续到主机B 重新发出一个新的窗口值为止。我们还应注意到，B 向A 发送的三个报文段都设置了ACK=1，只有在ACK=1 时确认号字段才有意义。

发生死锁： 现在我们考虑一种情况。上图中， B 向A 发送了零窗口的报文段后不久， B 的接收缓存又有了一些存储空间。于是B 向A 发送了rwnd = 400 的报文段。然而这个报文段在传送过程中丢失了。A 一直等待收到B 发送的非零窗口的通知，而B 也一直等待A 发送的数据。如果没有其他措施，这种互相等待的死锁局面将一直延续下去。

解决方案： TCP 为每一个连接设有一个 持续计时器（persistence timer） 。只要TCP 连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个 零窗口探测报文段 （仅携带1 宇节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。

1 TCP连接时是三次握手，那么两次握手可行吗？

在《计算机网络》中是这样解释的：已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送ACK包。这样就会白白浪费资源。而经过三次握手，客户端和服务器都有应有答，这样可以确保TCP正确连接。

2 为什么TCP连接是三次，挥手确是四次？

在TCP连接中，服务器端的SYN和ACK向客户端发送是一次性发送的，而在断开连接的过程中，B端向A端发送的ACK和FIN是是分两次发送的。因为在B端接收到A端的FIN后，B端可能还有数据要传输，所以先发送ACK，等B端处理完自己的事情后就可以发送FIN断开连接了。

3 为什么在第四次挥手后会有2个MSL的延时？

MSL是Maximum Segment Lifetime，最大报文段生存时间，2个MSL是报文段发送和接收的最长时间。假定网络不可靠，那么第四次发送的ACK可能丢失，即B端无法收到这个ACK，如果B端收不到这个确认ACK，B端会定时向A端重复发送FIN，直到B端收到A的确认ACK。所以这个2MSL就是用来处理这个可能丢失的ACK的。

1 文件传送协议

文件传送协议FTP (File Transfer Protocol) [RFC 959］是因特网上使用得最广泛的文件传送协议，底层采用TCP协议。

盯P 使用客户服务器方式。一个FTP 服务器进程可同时为多个客户进程提供服务。FTP的服务器进程由两大部分组成：一个主进程，负责接受新的请求：另外有若干个从属进程，负责处理单个请求。

在进行文件传输时，客户和服务器之间要建立两个并行的TCP 连接：“控制连接”（21端口）和“数据连接”（22端口）。控制连接在整个会话期间一直保持打开， FTP 客户所发出的传送请求，通过控制连接发送给服务器端的控制进程，但控制连接并不用来传送文件。实际用于传输文件的是“数据连接”。服务器端的控制进程在接收到FTP 客户发送来的文件传输请求后就创建“数据传送进程”和“数据连接”，用来连接客户端和服务器端的数据传送进程。

2 简单文件传送协议TFTP

TCP/IP 协议族中还有一个简单文件传送协议TFfP (Trivial File Transfer Protocol），它是一个很小且易于实现的文件传送协议，端口号69。

TFfP 也使用客户服务器方式，但它使用UDP 数据报，因此TFfP 需要有自己的差错改正措施。TFfP 只支持文件传输而不支持交耳。

3 TELNET

TELNET 是一个简单的远程终端协议，底层采用TCP协议。TELNET 也使用客户服务器方式。在本地系统运行TELNET 客户进程，而在远地主机则运行TELNET 服务器进程，占用端口23。

4 邮件传输协议

一个电子邮件系统应具如图所示的三个主要组成构件，这就是用户代理、邮件服务器，以及邮件发送协议（如SMTP ）和邮件读取协议（如POP3)， POP3 是邮局协议（Post Office Protocol）的版本3 。

SMTP 和POP3 （或IMAP ）都是在TCP 连接的上面传送邮件，使用TCP 的目的是为了使邮件的传送成为可靠的。

④ 网络中的RTT是什么意思

RTT(Round-Trip Time): 往返时延。在计算机网络中它是一个重要的性能指标，表示从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认），总共经历的时延。 RTT(Radio Transmission Technology): 无线传输技术。参考CDMA2000词条中的CDMA2000 1xRTT。 RTT(Radiation Tracking Transcer): 红外线跟踪系统, 辐射跟踪换能器。 RTT(Radio Teletype (-writer)): 无线电电传打字电报机。 RTT(Radioteletype Transmitter): 无线电电传打字电报发射机。 RTT(Real-Time Tactics):即时战术游戏又称“实时战术”游戏。它与即时战略（RTS：Real-Time Strategy）相类似，但缺少必要的战略要素，如资源采集、建造、发展等。一种常见的误解是认为“只要是即时进行的战争游戏就是即时战略游戏”。其实即时战略游戏的定义是很严格的，即时战略的“战略（Strategy）”的谋定过程必须是即时的，如果只有战斗是即时的，而采集、建造、发展等战略元素却以回合制进行，则该游戏不能归为即时战略游戏。如果该游戏完全没有上述战略元素，则只能归为即时战术（RTT：Real-Time Tactics）游戏。

⑤ 计算机网络——应用层-Web&HTTP

计算机网络系列博文——目录

20世纪90年代初
因特网应用

Web应用的组成

由对象组成。对象是一个文件，如HTML文件，JPEG图像，Java程序，视频片段等。
对象可通过一个URL地址寻址。
Web页面常由一个HTML基本文件和多个引用对象构成。

URL(Uniform Resoure Locator)：统一资源定位器 RFC1738

用以寻址Web对象
由一个存放对象的服务器主机名和对象路径名构成。

HTTP 由客户端程序和服务端程序实现，二者通过交换HTTP报文会话。
HTTP规范定义了HTTP客户端和服务端之间的通信协议。

Web浏览器实现HTTP客户端,请求、接收、展示Web对象
Web服务器实现HTTP服务端,响应客户的请求，发送对象

HTTP使用TCP作为支撑运输层协议。

端口：80

无状态协议 服务器不保存关于客户的任何信息
服务器向客户发送被请求的文件，而不存储任何关于客户的状态信息。

往返时间（Round-Trip Time,RTT)
一个短分组从客户到服务器然后再返回客户所花费的时间。

某客户和服务器的一次会话中，每个请求/响应对通过一个单独的TCP连接传输

HTTP 1.0版本使用非持续性连接

对多个待获得的web对象，客户端一次只请求一个对象，待前一个对象接收完毕后再发送对下一个对象的请求。

时间分析

浏览器通常支持并行的TCP连接。并行TCP连接数通常为5~10个。
对多个待获得的web对象，客户端一次可同时建立多个TCP连接，以同时请求多个web对象。
时间分析

某客户和服务器的一次会话中，所有请求/响应对经同一TCP连接传输

HTTP 1.1版本在默认方式下采用持续连接，但也可由客户端/服务器配置为非持续连接。

客户端只有收到前一个响应后才发送新的请求
可理解为同个TCP内的串行

时间分析

客户端只要遇到一个引用对象就尽快发出请求
可理解为同个TCP内的并行
HTTP 1.1的默认选项

时间分析

TCP 三次握手
1.客户向服务器发送一个小TCP报文段；
2.服务器用一个小TCP报文段做出确认和响应；
3.客户向服务器返回确认和一个HTTP请求报文；
4.服务器返回相应HTML文件;

HTTP规范
RFC 1945 , RFC 2616

用ASCII文本书写
HTTP协议有两类消息，请求消息(request)和响应消息(response)

请求行 HTTP请求报文的第一行

方法

首部行 请求行后继的其它行，包含一些会话信息

空行 回车换行，分隔首部行和实体体

实体体(entity body)
GET方法下实体体为空
POST方法下实体体包含表单信息

状态行

常见状态码

首部行

空行

实体体
包含了所请求的对象

HTTP是无状态协议，但cookie技术允许服务器识别用户
cookie在无状态的HTTP之上建立一个用户会话层

参见 [RFC 6265]

cookie组件

cookie技术的争议在于它可能泄露用户的隐私

代表原Web服务器来响应HTTP请求的网络实体

Web缓冲器通常由ISP购买并安装

允许缓存器证实其缓存的副本是新的。
如果缓存器有web对象最新的版本，则初始服务器不需要向缓存器发送该web对象

在HTTP请求消息中声明所持有版本的日期
If-modified-since: <date>

如果缓存的版本是最新的，则响应消息中不包含对象
HTTP/1.0 304 Not Modified

内容分发网络（Content Distribution Network,CDN）
基于缓存器技术，CDN公司在因特网上安装许多地理上分散的缓存器，使得大流量本地化。
有共享CDN(Akamai,Limelight)，专用CDN（谷歌，微软）

⑥ 网络编程（五）TCP详解

考虑最简单的情况：两台主机之间的通信。这个时候只需要一条网线把两者连起来，规定好彼此的硬件接口，如都用 USB、电压 10v、频率 2.4GHz 等， 这一层就是物理层，这些规定就是物理层协议 。

我们当然不满足于只有两台电脑连接，因此我们可以使用交换机把多个电脑连接起来，如下图：

这样连接起来的网络，称为局域网，也可以称为以太网（以太网是局域网的一种）。在这个网络中，我们需要标识每个机器，这样才可以指定要和哪个机器通信。这个标识就是硬件地址 MAC。

硬件地址随机器的生产就被确定，永久性唯一。在局域网中，我们需要和另外的机器通信时，只需要知道他的硬件地址，交换机就会把我们的消息发送到对应的机器。

这里我们可以不管底层的网线接口如何发送，把物理层抽离，在他之上创建一个新的层次，这就是 数据链路层 。

我们依然不满足于局域网的规模，需要把所有的局域网联系起来，这个时候就需要用到路由器来连接两个局域网：

但是如果我们还是使用硬件地址来作为通信对象的唯一标识，那么当网络规模越来越大，需要记住所有机器的硬件地址是不现实的；

同时，一个网络对象可能会频繁更换设备，这个时候硬件地址表维护起来更加复杂。这里使用了一个新的地址来标记一个网络对象： IP 地址 。

通过一个简单的寄信例子来理解 IP 地址。

我住在北京市，我朋友 A 住在上海市，我要给朋友 A 写信：

因此，这里 IP 地址就是一个网络接入地址（朋友 A 的住址），我只需要知道目标 IP 地址，路由器就可以把消息给我带到。 在局域网中，就可以动态维护一个 MAC 地址与 IP 地址的映射关系，根据目的 IP 地址就可以寻找到机器的 MAC 地址进行发送 。

这样我们不需管理底层如何去选择机器，我们只需要知道 IP 地址，就可以和我们的目标进行通信。这一层就是 网络层 。网络层的核心作用就是 提供主机之间的逻辑通信 。

这样，在网络中的所有主机，在逻辑上都连接起来了，上层只需要提供目标 IP 地址和数据，网络层就可以把消息发送到对应的主机。

一个主机有多个进程，进程之间进行不同的网络通信，如边和朋友开黑边和女朋友聊微信。我的手机同时和两个不同机器进行通信。

那么当我的手机收到数据时，如何区分是微信的数据，还是王者的数据？那么就必须在网络层之上再添加一层： 运输层 ：

运输层通过 socket（套接字），将网络信息进行进一步的拆分，不同的应用进程可以独立进行网络请求，互不干扰。

这就是运输层的最本质特点： 提供进程之间的逻辑通信 。这里的进程可以是主机之间，也可以是同个主机，所以在 android 中，socket 通信也是进程通信的一种方式。

现在不同的机器上的应用进程之间可以独立通信了，那么我们就可以在计算机网络上开发出形形式式的应用：如 web 网页的 http，文件传输 ftp 等等。这一层称为 应用层 。

应用层还可以进一步拆分出表示层、会话层，但他们的本质特点都没有改变： 完成具体的业务需求 。和下面的四层相比，他们并不是必须的，可以归属到应用层中。

最后对计网分层进行小结：

这里需要注意的是，分层并不是在物理上的分层，而是逻辑上的分层。通过对底层逻辑的封装，使得上层的开发可以直接依赖底层的功能而无需理会具体的实现，简便了开发。

这种分层的思路，也就是责任链设计模式，通过层层封装，把不同的职责独立起来，更加方便开发、维护等等。

TCP 并不是把应用层传输过来的数据直接加上首部然后发送给目标，而是把数据看成一个字节 流，给他们标上序号之后分部分发送。这就是 TCP 的 面向字节流 特性：

面向字节流的好处是无需一次存储过大的数据占用太多内存，坏处是无法知道这些字节代表的意义，例如应用层发送一个音频文件和一个文本文件，对于 TCP 来说就是一串字节流，没有意义可言，这会导致粘包以及拆包问题，后面讲。

前面讲到，TCP 是可靠传输协议，也就是，一个数据交给他，他肯定可以完整无误地发送到目标地址，除非网络炸了。他实现的网络模型如下：

对于应用层来说，他就是一个可靠传输的底层支持服务；而运输层底层采用了网络层的不可靠传输。虽然在网络层甚至数据链路层就可以使用协议来保证数据传输的可靠性，但这样网络的设计会更加复杂、效率会随之降低。把数据传输的可靠性保证放在运输层，会更加合适。

可靠传输原理的重点总结一下有： 滑动窗口、超时重传、累积确认、选择确认、连续 ARQ 。

停止等待协议

要实现可靠传输，最简便的方法就是：我发送一个数据包给你，然后你跟我回复收到，我继续发送下一个数据包。传输模型如下：

这种“一来一去”的方法来保证传输可靠就是 停止等待协议 （stop-and-wait）。不知道还记不记得前面 TCP 首部有一个 ack 字段，当他设置为 1 的时候，表示这个报文是一个确认收到报文。

然后再来考虑另一种情况：丢包。网络环境不可靠，导致每一次发送的数据包可能会丢失，如果机器 A 发送了数据包丢失了，那么机器 B 永远接收不到数据，机器 A 永远在等待。

解决这个问题的方法是： 超时重传 。当机器 A 发出一个数据包时便开始计时，时间到还没收到确认回复，就可以认为是发生了丢包，便再次发送，也就是重传。

但重传会导致另一种问题：如果原先的数据包并没有丢失，只是在网络中待的时间比较久，这个时候机器 B 会受到两个数据包，那么机器 B 是如何辨别这两个数据包是属于同一份数据还是不同的数据？

这就需要前面讲过的方法： 给数据字节进行编号 。这样接收方就可以根据数据的字节编号，得出这些数据是接下来的数据，还是重传的数据。

在 TCP 首部有两个字段：序号和确认号，他们表示发送方数据第一个字节的编号，和接收方期待的下一份数据的第一个字节的编号。

停止等待协议的优点是简单，但缺点是 信道利用率 太低。

假定AB之间有一条直通的信道来传送分组

这里的TD是A发送分组所需要的时间（显然TD = 分组长度 / 数据速率）再假定TA是B发送确认分组所需要的时间（A和B处理分组的时间都忽略不计）那么A在经过TD+RTT+TA时间后才能发送下一个分组，这里的RTT是往返时间，因为只有TD是采用来传输有用的数据（这个数据包括了分组首部，如果可以知道传输更精确的数据的时间，可以计算的更精确），所有信道利用率为

为了提高传输效率，发送方可以不使用低效率的停止等待协议，而是采用 流水线传输 ：就是发送方可以 连续的发送多个分组 ，不必每发完一个分组就停下来等待对方的确认。这样可使信道上一直有数据不间断地在传送。显然这种传输方式可以获得很高的信道利用率

停止等待协议已经可以满足可靠传输了，但有一个致命缺点： 效率太低 。发送方发送一个数据包之后便进入等待，这个期间并没有干任何事，浪费了资源。解决的方法是： 连续发送数据包 。

也就是下面介绍的 连续ARQ协议 和 滑动窗口协议

连续 ARQ 协议

模型如下：

和停止等待最大的不同就是，他会源源不断地发送，接收方源源不断收到数据之后，逐一进行确认回复。这样便极大地提高了效率。但同样，带来了一些额外的问题:

发送是否可以无限发送直到把缓冲区所有数据发送完？不可以。因为需要考虑接收方缓冲区以及读取数据的能力。如果发送太快导致接收方无法接受，那么只是会频繁进行重传，浪费了网络资源。所以发送方发送数据的范围，需要考虑到接收方缓冲区的情况。这就是 TCP 的 流量控制 。

解决方法是： 滑动窗口 。基本模型如下：

在 TCP 的首部有一个窗口大小字段，他表示接收方的剩余缓冲区大小，让发送方可以调整自己的发送窗口大小。通过滑动窗口，就可以实现 TCP 的流量控制，不至于发送太快，导致太多的数据丢失。

连续 ARQ 带来的第二个问题是：网络中充斥着和发送数据包一样数据量的确认回复报文，因为每一个发送数据包，必须得有一个确认回复。提高网络效率的方法是： 累积确认 。

接收方不需要逐个进行回复，而是累积到一定量的数据包之后，告诉发送方，在此数据包之前的数据全都收到。例如，收到 1234，接收方只需要告诉发送方我收到 4 了，那么发送方就知道 1234 都收到了。

第三个问题是：如何处理丢包情况。在停止等待协议中很简单，直接一个超时重传就解决了。但，连续 ARQ 中不太一样。

例如：接收方收到了 123 567，六个字节，编号为 4 的字节丢失了。按照累积确认的思路，只能发送 3 的确认回复，567 都必须丢掉，因为发送方会进行重传。这就是 GBN（go-back-n) 思路。

但是我们会发现，只需要重传 4 即可，这样不是很浪费资源，所以就有了： 选择确认 SACK 。在 TCP 报文的选项字段，可以设置已经收到的报文段，每一个报文段需要两个边界来进行确定。这样发送方，就可以根据这个选项字段只重传丢失的数据了。

第四个问题是：拥塞控制的问题
也是通过窗口的大小来控制的，但是检测网络满不满是个挺难的事情，所以 TCP 发送包经常被比喻成往谁管理灌水，所以拥塞控制就是在不堵塞，不丢包的情况下尽可能的发挥带宽。

水管有粗细，网络有带宽，即每秒钟能发送多少数据；水管有长度，端到端有时延。理想状态下，水管里面的水 = 水管粗细 * 水管长度。对于网络上，通道的容量 = 带宽 * 往返时延。

如果我们设置发送窗口，使得发送但未确认的包为通道的容量，就能撑满整个管道。

如图所示，假设往返时间为 8 秒，去 4 秒，回 4 秒，每秒发送一个包，已经过去了 8 秒，则 8 个包都发出去了，其中前四个已经到达接收端，但是 ACK 还没返回，不能算发送成功，5-8 后四个包还在路上，还没被接收，这个时候，管道正好撑满，在发送端，已发送未确认的 8 个包，正好等于带宽，也即每秒发送一个包，也即每秒发送一个包，乘以来回时间 8 秒。

如果在这个基础上调大窗口，使得单位时间可以发送更多的包，那么会出现接收端处理不过来，多出来的包会被丢弃，这个时候，我们可以增加一个缓存，但是缓存里面的包 4 秒内肯定达不到接收端课，它的缺点会增加时延，如果时延达到一定程度就会超时重传

TCP 拥塞控制主要来避免两种现象，包丢失和超时重传，一旦出现了这些现象说明发送的太快了，要慢一点。

具体的方法就是发送端慢启动，比如倒水，刚开始倒的很慢，渐渐变快。然后设置一个阈值，当超过这个值的时候就要慢下来

慢下来还是在增长，这时候就可能水满则溢，出现拥塞，需要降低倒水的速度，等水慢慢渗下去。

拥塞的一种表现是丢包，需要超时重传，这个时候，采用快速重传算法，将当前速度变为一半。所以速度还是在比较高的值，也没有一夜回到解放前。

到这里关于 TCP 的可靠传输原理就已经介绍得差不多。最后进行一个小结：

当然，这只是可靠传输的冰山一角，感兴趣可以再深入去研究

⑦ 计算机网络有哪些常用的性能指标

计算机网络常用性能指标有：
1、速率：连接在计算机网络上的主机在数字信道上传送数据的速率。
2、带宽：网络通信线路传送数据的能力。
3、吞吐量：单位时间内通过网络的数据量。
4、时延：数据从网络一端传到另一端所需的时间。
5、时延带宽积：传播时延带宽。
6、往返时间RTT：数据开始到结束所用时间。
7、利用率信道：数据通过信道时间。

(7)计算机网络中的往返时间用图表示扩展阅读：
计算机网络中的时延是由一下几个不同的部分组成的：
（1）发送时延
发送时延是主机或路由器发送数据帧所需要的时间，也就是从发送数据帧的第一个比特算起，到该帧的最后一个比特发送完毕所需的时间。因此发送时延也叫做传输时延。发送时延的计算公式是：
发送时延=数据帧长度（bit）/发送速率（bit/s）
（2）传播时延
传播时延是电磁波在信道中传播一定的距离需要花费的时间。传播时延的计算公式是：
传播时延=信道长度（m）/电磁波在信道上大的传播速率（m/s）
电磁波在自由空间的传播速率是光速。即3.0*10^5km/s。
发送时延发生在机器内部的发送器中，与传输信道的长度没有任何关系。传播时延发生在机器外部的传输信道媒体上，而与信道的发送速率无关。信号传送的距离越远，传播时延就越大
（3）处理时延
主机或路由器在收到分组时需要花费一定时间进行处理，例如分析分组的首部，从分组中提取数据部分、进行差错检验或查找合适的路由等，这就产生了处理时延。
（4）排队时延
分组在进行网络传输时，要经过许多路由器。但分组在进入路由器后要先在输入队列中排队等待，在路由器确定了转发接口后，还要在输出队列中排队等待转发。这就产生了排队时延。排队时延的长短取决于网络当时的通信量。当网络的通信量很大时会发生队列溢出，使分组丢失，这相当于排队时延无穷大。
这样数据在网络中经历的总时延就是以上四种时延之和：总时延=发送时延+传播时延+处理时延+排队时延。
一般来说，小时延的网络要优于大时延的网络。

⑧ 什么是数据的排队时延，往返时延

排队时延：有时可用排队时延表示处理时延，而处理时延是数据在交换结点为存储转发而进行的一些的必要的的处理所花费的时间。
往返时延：在计算机网络中它也是一个重要的性能指标，它表示从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认），总共经历的时延。

⑨ 怎么计算网址的rtt

计算网址的rtt的方法是：

1、首先，先采样RTT，记下最近好几次的RTT值。

2、然后做平滑计算SRTT（ Smoothed RTT），公式为：（其中的 α 取值在0.8 到 0.9之间，这个算法英文叫Exponential weighted moving average，中文叫：加权移动平均）SRTT = ( α * SRTT ) + ((1- α) * RTT)。

3、开始计算rtt。公式如下：rtt= min [ UBOUND,max [ LBOUND, (β * SRTT) ]]。

其中：UBOUND是最大的timeout时间，上限值、LBOUND是最小的timeout时间，下限值、β 值一般在1.3到2.0之间。

RTT往返时间是：

RTT(Round-Trip Time)往返时间在计算机网络中它是一个重要的性能指标。表示从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认，不包含数据传输时间）总共经历的时间。

RTT由三个部分决定：链路的传播时间、末端系统的处理时间、路由器的缓存中的排队和处理时间。其中前两个部分的值作为一个TCP连接相对固定。

路由器的缓存中的排队和处理时间会随着整个网络拥塞程度的变化而变化。所以RTT的变化在一定程度上反映了网络拥塞程度的变化。简单来说就是发送方从发送数据开始，到收到来自接受方的确认信息所经历的时间。

⑩ 计算机网络中的往返时间怎么解释

1.时延
时延(delay 或 latency)是指数据从网络一端传到另一端所需的时间。通常，时延由发送时延、传播时延、排队时延、处理时延四个部分组成。
（1）发送时延
发送时延是结点将数据分组发送到传输媒介所需要的时间，也就是从分组的第一个比特开始发送算起，到最后一个比特发送完毕所需要的时间。显然，发送时延与网络接口/信道的传输速率成反比，与数据分组的长度成正比。

（2）传播时延
传播时延是电磁波在信道中传播一定距离所需要花费的时间，传播时延和信道的传输速率无关， 而是取决于传输媒介的长度，以及某种物理形式的信号在传输媒介中的传播速度。如电磁波在自由空间的传播速度是光速，即3×105km/s。电磁波在网络传输媒体中的传播速度比在自由空间中的传播速度要略低一些，在铜线中的传播速度约为2.3×105km/s ，在光纤中的传播速度约为2.0×105km/s 。传播时延的计算公式是：

（3）排队时延
排队时延是分组在所经过的网络结点的缓存队列中排队所经历的时延，排队时延的长短主要取决于网络中当时的通信量，当网络的通信流量大时，排队时间就长，极端情况下，当网络发生拥塞导致分组丢失时，该结点的排队时延视为无穷大。此外，在有优先级算法的网络中，排队时延还取决于数据的优先级和结点的队列调度算法。
（4）处理时延
处理时延是分组在中间结点的存储转发过程中而进行的一些必要的处理所花费的时间，这些处理包括提取分组的首部，进行差错校验，为分组寻址和选路等。
综上所述，网络端到端的时延是几种时延的总合，其计算公式是：
总时延=传播时延+发送时延+排队时延+处理时延
根据网络的不同情况，有时有些时延可以忽略不计，如在局域网中，传播时延很小可以忽略不计；当网络没有拥塞时，分组在各个结点的排队时延可以忽略不计。
2.往返时延
往返时延（Round-Trip Time，RTT）也是一个重要的性能指标，它表示从发送方发送数据开始，到发送方收到来自接收方的确认，总共经历的时延。对于复杂的网络，往返时延要包括各中间结点的处理时延和转发数据时的发送时延。
3.时延变化/时延抖动
时延抖动(jitter)指不同分组穿越网络的延迟的变化。当传输多媒体信息时，如音视频应用，更需要关心时延的变化。因为应用层信息的解码和无失真展示要求数据的时延变化在某个范围内，这时会引入时延抖动参数来描述网络性能。