网络协议实践课程第3章20140301

ComputerNetworkingInternetProtocolAction李毅超2011.12第三章传输层协议引言在因特网上，传输层协议负责将数据从一个应用程序传递到另一个应用程序。它既不关心所传输的具体数据，也不关心能否正确识别目标主机。传输层目前的两个主要的协议:TCP(传输控制协议)UDP(数据报协议)第三章传输层协议TCP和UDP都提供了多路复用和多路分解，但是TCP提供的许多特性UDP却不提供，比如可靠的有序报文传输、流量控制和拥塞控制。多路复用(multiplex)和多路分解(demultiplex)传输层协议指定了用于正确定位应用程序发送端和接收端的源端口号和目的端口号。这一过程称为多路复用(multiplex)和多路分解(demultiplex)。因特网同一主机上的应用程序所产生的多个数据流复用一个输出连接。因特网同一主机上不同应用程序的多个数据流可能也会通过一个输出连接传输，但是它们最终将会被分解并传输到各自的应用程序中去。在本章的实验中，将会详细讨论这些特性。实验3.1中，将首先观察简单的TCP流。我们将观察TCP报文段的首部，并且讨论TCP如何完成可靠的有序报文传输。实验3.2中，将详细研究TCP的重传。我们将考虑致使TCP重新发送传输过的数据副本的各种事件。我们还会查看各种TCP变体，包括带选择确认的TCP。实验3.3中，将介绍UDP及其数据报首部。我们将比较传输同样数据的TCP流和UDP流，我们还会分析，对于没有接收端监听输入数据的情况，TCP和UDP的发送端是如何处理的。实验3.4中，将观察TCP流量控制和拥塞控制属性。我们将把TCP与既没有流量控制又没有拥塞控制的UDP进行比较。我们将观察两个并发运行的TCP流、一个与UDP流并发运行的TCP流，以及两个并发运行的UDP流。我们将说明TCP的发送端之间会平等地共享网络，而UDP的发送端却不会限制发送速率。实验3.1TCP介绍简介

TCP是因特网中最主要的传输层协议。它能够在两个应用程序间提供可靠的有序数据流传输，即使这两个程序运行在不同的主机上并且被一个会丢失、重排序或者破坏分组的不可靠网络所隔开。TCP能够检测传输过程中分组是否丢失、延迟和改变，如是则重传这些分组，从而提供了可靠的数据流传输。可以想像一下，你在用一台可能丢页的传真机来传送大量的文档。你可能会把文档编上页号，这样接收端就能知道哪部分丢失了。TCP报文段首部格式如图3.1.1（RFC793）：源端口字段和目的端口字段就不说了。序号字段表示分组中第一个字节的在传输字节流中的编号。确认号字段是数据流中下一个期望接收的字节的编号。数据偏移字段，它表示报文段的数据部分的开始位置。由于TCP首部的长度会因为使用可变长度选项字段而发生变化，所以设置数据偏移字段是必要的。标志部分含有6个不同的位:URGENT位、ACKNOWLEDGEMENT位、PUSH位、RESET位、SYN位和FIN位。ACKNOWLEDGEMENT位只表明确认字段是否有效。PUSH位用于表示发送端应用程序要求数据立刻发送。SYN,FIN,RESET这三位用来打开或关闭连接。URGENT位和紧急指针字段通常很少使用，所以在这里不做讨论。接收端通告窗口字段和校验和字段一、配置如图3.1.22台PC上都安装ttcp来产生具有一定特征的TCP流。先在1台PC上启动接收端，后在另1台PC上启动1个发送端。建立TCP连接，发送数据。二、实验本地ttcp连接接收端PC（02）Ethereal开始捕获启动发送端PC（00）发送端和接收端退出时候Ethereal停止捕获,将跟踪的结果保存在tcp_pcattcp_n1.cap中。三、观察跟踪记录tcp_pcattcp_n1.cap连接建立分组3到5显示的就是3次握手。第1条SYN分组。SYN位为1。序号是随机数，而Ethereal显示0为逻辑序号。第2条SYNACK分组。SYN、ACK位均为1。确认号是前SYN分组随机数+1，而Ethereal显示1为逻辑序号。序号也是另一随机数，而Ethereal显示0。第3条ACK分组，客户端发送带有标志ACK的TCP报文段来完成三次握手的过程。这个报文段将确认服务器发送的SYNACK分组，并检查TCP连接的两端是否正确地打开和运作。所有随后的TCP报文段都将拥有ACK标志，因为每端都会报告数据流中预期到来的下一个字节。如果一方没有发送数据，另一方会为余下的连接发送同样的确认号。三次握手也会用来协商连接的某些属性。比如，MSS（MaximumSegmentSize）。本地网上能发送的最大TCP报文段1460字节。单向数据流一旦连接建立了，ttcp发送端(客户端)将向数据流写入8192个字节。从应用程序的角度来看，这是作为一个单位传送的。然而，底层的网络并不能支持容纳8192个字节这样大的分组，因此TCP会将这一个逻辑传送单位分成多个报文段。跟踪记录中，包含数据的第一个报文段如分组6所示。它包含前1460个字节。再加上20个TCP首部字节和20个IP首部字节，这样就达到了1500个字节，这也是以太网所允计的最大字节长度。再加上14个字节的以太网帧首部，这个帧的总大小为1514个字节。分组7、9、10和11也都传送1460个字节,这样就传送了1460x5=7300个字节,剩下的8192-7300=892个字节将在分组13里面发送。本实验服务器不会回传任何数据给客户端。因此，所有从端口号5001到2440发送的分组都只包含TCP首部而没有数据。即使没有自身要传送的数据，服务器也要发送TCP报文段给客户端，提供哪些数据已经被成功接受的反馈。比如在分组8中，服务器发送一个确认号为2921的报文段。服务器通过宣布期望接收的下一个字节号是2921来确认分组6和分组7已经接收。连接关闭当两端交换带有FIN标志的TCP报文段并且每一端都确认另一端发送的FIN包时，TCP连接将会关闭。但那些重传的数据仍然会被传送，直到接收端确认所有的信息。在tcp_pcattcp_n1.cap中，通过分组13至16我们可以看到TCP连接被关闭。ttcp发送端写完了数据的8192个字节，它就准备断开连接了。在分组13里，包含了最后892节并且设置了FIN位指示没有额外的数据将要被传送。在分组14里，服务器确认已经收到了所有发送的数据。我们注意到这时确认号为8194而不是8193。这是由于FIN自身被当作第8193个字节了。在分组15中，服务器也发送一个FIN标志指示不会发送任何其他附加的数据了。在分组16中，客户端会发送最后一个确认号为2的报文段来确认服务器所发的FIN标志，因为FIN本身也被看作为最后的字节。2个FIN和相应ACK是用来终止一个TCP连接的较好方法。也可以通过设置RESET位来终止TCP连接。尽管设计RESET是为了处理不可恢复的错误，但是在实践中也经常用来进行快速终止连接，以避免常规的FIN-ACK交换。连接统计StatisticTCPStreamGraphTime-SequenceGraph(tcptrace)注意只能看发送端到接收端1到8194，或者接收端到发送端0到2。AnanyzeFollowTCPStream看到两端所有数据，或发送端到接收端/接收端到发送端的数据。

（见下页截图）StatisticsProtocolHierarchy在这种情况下，Ethereal会报告在整个跟踪文件中总共有9090个字节的数据、8988个字节的TCP通信。在我们的跟踪记录中，有6个分组(分组6,7,9,10,11和13）含有数据，它们都包含有54个字节的首部（20个字节的TCP首部、20个字节的IP首部和14个字节的以太网首部）即总共54x6=324字节+8192字节数据=8516字节，另外8个分组不含数据，54x8=432字节，总和正好为8988字节。远程SSH连接(交互式双向数据流）

除了在本地网上由ttcp产生的一个TCP连接以外，我们还在本地机和一个远程服务器之间产生一个SSH连接。将所捕获的网络通信保存在文件tcp_ssh.cap中。客户端和服务器都发送数据。通过使用FollowTCPStream来分离开每一方的数据通道，你能够很快地发现不同之处。实际操作来看看SSH客户端会发送很多只有少量数据的报文段，因为这种连接代表一种交互式的数据流，而不是大量传输8192个字节的ttcp流。看看其TCP报文段首部的PUSH标志位。TCP层正常情况下尝试在通过网络发送数据之前收集足够多的数据来最大限度地填满一个报文段。在应用程序要求该报文段不等填满便立即被发送的时候，PUSH标志位置1。TCP首部消耗了整个数据流中的较大比例。在SSH流中即使最大报文段大小仍为1460个字节，事实上，大多数报文段包含的数据都少于100个字节。整个会话过程的字节数是8606个。这比起ttcp流中的8192个字节来说并不算多，但是却一共需要118个报文段包含数据，而不是6个报文段。在这个实验中TCP数据流包含有8606个字节的数据，而总共传输却有18508个字节（数据占46%）。而在ttcp流中含有8192个字节的数据，总共传输8988个字节（数据占91%）。小节本堂课，我们用Ethereal逆向分析了TCP协议的一些细节，让我们对TCP报文段格式、TCP连接建立、连接关闭、单向或双向数据流传输以及传输的开销都有了直观基本的认识。实验3.2TCP重传简介本节重点探讨TCP在一个不可靠的网络上如何依靠接收端返回的检查丢失或错误的反馈来提供一个可靠的数据传输。在这个实验里，将观察发生重传时TCP连接的跟踪记录。重传计时器当一个TCP发送端传输一个报文段的同时也设置了一个重传计时器。确认到达时，该计时器就自动取消。如果在数据的确认信息到达之前这个计时器超时，那么数据将会重传。重传计时器能够自动灵活设置。最初，TCP是基于初始的SYN和SYNACK之间的时间来设置重传计时器的。在整个TCP连接中，TCP都会注意每个报文段的发送和收到相应的确认所经历的时间。我们会计算出这些时间的一个平均值，那样的话，累积平均值会比最近采样更具有说服力。TCP也会把一系列重复确认的分组当作是数据丢失的先兆。也就是说发送端不一定非得等到超时重传。如果接收端期望的字节号是1000，然而接收到的字节号却是2000到3000，那么它们必须继续设置确认号为1000。如果包含字节号从1000到1099的段丢失了，那么它们将继续为每个新接收的报文段发送确认号1000。当发送端看见带有同样确认号的一系列报文段的时候，它会假设虽然数据到达了另外一端并且发送了确认号，但是包含第1000字节的报文段却丢失了。TCP后来的版本为接收端提供了一种方法，可以指示已经接收到的报文段中哪些是失序的。这称为选择确认，具有这种特征的TCP常常被称作TCPSACK。发送端和接收端可以在连接建立的三次握手期间协商是否使用SACK这样的附加特征。一、配置便携式电脑使用无线接口，方便对其进行一个强信号的干扰。使用ttcp来产生一个具有特殊属性的TCP流，通过TCP连接下载一个文件。二、实验本地TTCP连接便携式电脑（02）运行一个ttcp流的接收端携式电脑随后启动Ethereal开始捕获台式机先启动Ethereal开始捕获随后台式机（00）启动ttcp流发送端发送端和接收端程序都退出时，停止数据捕获。将从发送端(台式机)捕获的跟踪记录保存在pcattcp_retrans_t.cap，将从接收端(便携式电脑)捕获的跟踪记录保存在文件pcattcp_retrans_r.cap。三、跟踪分析SACK选项协商观察建立连接的三次握手。在SYN分组(两个跟踪文件中的分组1)中，台式机在TCP的首部选项中通过包括SACKpermitted选项来希望使用TCPSACK。在SYNACK包(两个跟踪文件中的分组2)中，便携式电脑表示愿意使用SACK。这样，双方就都同意接收选择性确认信息。SACK选项见图3.2.2。在TCPSACK里，如果连接的一端接收了失序数据，它将使用选项区字段来发送关于失序数据起始和结束的信息。这样允许发送端仅仅重传丢失的数据。在若干分组丢失情况下，这一点特别有用，因为重复的确认仅仅作为一个分组丢失的提示。任何接收到的失序数据要么被丢掉，要么被暂时缓存起来。TCP发送端必须保存一份已发送的数据的副本，以防数据需要重发。发送端必须保存数据直到它们收到数据的确认信息为止。接收端通常会分配一个固定大小的缓冲区空间来存储这些失序数据和需要等待一个应用程序读取的数据。如果缓冲区空间不能够容纳下更多数据，那么接收端只有将数据丢掉。接收端的通告窗口字段用来通知发送端接收端还有多少空间可以用于输入的数据。如果数据发送的速度快于应用程序处理数据的速度，接收端就会发送一些信息来告知发送端其接收窗口正在减小。在这个跟踪文件中，便携式电脑发送的接收端通告窗口的大小是变化的，从16520个字节到17520个字节。可以用便携式电脑的显示过滤器(如tcp.srcport==5001)来分离这些响应。TCP发送端在发送之前也有一个容纳数据的有限空间。然而，和接收端不同的是，发送端是限制自己的发送速率。如果缓冲区的空间满了，尝试写入更多数据的应用程序将会被阻塞直到有更多的空间可以利用为止。分组的丢失与重传（选择性重传的例子）观察pcattcp_retrans_t.cap，用显示过滤器tcp.analysis.retransmission寻找重传(见图3.2.3)。分组12是这9次重传的第1次。分组12序号是1001，使用过滤器tcp.seq==1001，我们发现分组5也拥有同样的序号。有趣的是，分组5是对1001到2460号字节的传输，而分组12仅是对1001到2000号字节的重传。分组20实际上是对2001到2460号字节的重传。

分组4传输1-1000号字节，分组5传输1001-2460号字节，分组7传输2461-3920号字节。观察pcattcp_retrans_r.cap。分组4传输1-1000号字节，分组5确认1-1000号字节。分组6传送2461-3920号字节（而不是分组7）。接收端没有看到发送端1001-2460号字节的传输。但是他们确实被发送了，仅可能在发送端和接收端之间的某个环节丢失了。接收端是如何来处理这些丢失的。在分组4到达以后，接收端会以确认号1001（分组5）响应。在分组6的2461-3920号字节到达之后，接收端仍然是以确认号1001（分组7）响应。在分组7的首部的可选择字段里还包含有一些选择性确认信息。其中SACK选项通过左边界684449229和右边界684450689表示它接收了失序数据。要了解SACK选项，请记住初始的序号是随机选择的。而684449229到684450689正好是1460个失序字节。同样，在含有3921-5381号字节的分组8到达之后，接收端再次响应1001确认号。然而分组9里面的SACK选项的右边界增至684452149，反映接收到了更多失序数据，仅仅简单延伸已存在的失序区域的右边界就足够了。最后，分组12重传1001-2000号字节，分组14接收端增加确认号到2001。分组19重传2001-2460号字节（对应pcattcp_retrans_t.cap的分组20），接收端立即从确认字节2001跳到确认字节11221。对发送速率的影响44085001的数据流中选一个分组，操作StatisticTCPStreamGraphTimeSequenceGraphs(Steven’s)分别大约在0.15秒、1.8秒、3.1秒和4.0秒看见四组垂直的点。1.8秒的那组包括一个孤立的点，它位于序号20000上面，后面跟着一组在25000上面彼此接近的点。该最低点是在0.15秒附近的已经发送的序号的重传点。这是由于SACK信息允许发送端仅仅重传丢失的那一段，因此在同一垂直组中，那个重传点和其他的点分开。这个分组的丢失和重传导致了在数据发送过程中的一个明显延迟。远程TCP连接（全部重传的例子）用本地计算机和远程服务器之间的TCP来跟踪HTTP连接。我们将捕获的结果保存在tcp_http.cap文件中。这个实验只能从接收端的角度去跟踪。三次握手发生在分组1到分组3。我们的本地机发送SYN分组并且在TCP首部的选项字段中含有SACKpermitted选项。然而在本例中远程服务器并未在SYNACK分组中包括SACKpermitted选项，因此选择确认不会在这个连接中发送。也就是说该丢失分组之后的所有分组都要重传。小节1.用Ethereal观察TCP重传细节，直观认识TCP重传实验3.3TCP和UDP比较简介TCP提供可靠传输、流量控制、拥塞控制、点对点连接UDP只是在IP层上简单扩展、不可靠传输，非点对点连接一、配置

使用ttcp来生成两个TCP流，然后再生成两个UDP流。二、实验第一个TCP流和UDP流尝试着发送相同数量的数据到一个处于等待状态的接收端那里。可以将TCP和UDP作为一种传输具有类似特性的流的手段进行比较。第二个TCP流和UDP流也尝试发送同样的数据，但这时却没有处于等待状态的接收端。可以比较TCP和UDP对于发送失败都会作出什么反映。将两次TCP流的跟踪记录保存文件tcp_2transmit.cap中，并将两次UCP流的跟踪保存文件udp_2transmit.cap中。用TTCP生成TCP和UDP通信第一个TCP流便携式电脑上运行接收端5001端口监听。台式机传输每个缓冲区1000字节的5个缓冲区数据5000字节。接收用2.48秒，传送用0秒第一个UDP流在便携式电脑上运行接收端。在UDP端口5001上开始监听台式机传输每个缓冲区为1000字节5个缓冲区数据5000字节。接收用0.01秒，传送用0秒。UDP比TCP时间少得多。

观察分析TCP传输的正常数据：tcp_2transmit.cap的分组1-3建立连接，10-13关闭连接。分组4发送1000字节，分组5发送1460字节、分组6接收端确认、分组7发送1460字节，分组8发送1080字节，分组9接收端确认。Ethereal显示2.48秒正好是从初始化连接的分组1开始到关闭连接的分组10结束。第一个包含数据的分组4和最后一个分组8之间的时间大约0.01=UDP接收端所报告的0.01秒。这样的话，增加TCP传输时间的主要因素就是分组10中的重传。公平地说，UDP是幸运的，因为它所有分组都在第一时间被接收。

观察分析UDP正常数据传输：udp_2transmit.cap分组1到分组11,虽然像TCP流那样传输了相同的数据，但是还是有很多的不同。UDP无SYN和SYNACK分组显式连接，无FIN和FINACK分组显式关闭连接。所有11个分组都发送数据，1是特殊4字节数据报，7-11特殊4字节数据报（由于UDP无起始，应用程序ttcp只有依靠它们来标志起始）。UDP2-6分组是5个1000字节直接打包5个UDP数据报。UDP在传输的数据中不会加上序号，接收端不可能确定丢失和重排序重传的情况。UDP不提供接收端到发送端的反馈（确认或降速）。TCP和UDP的另外一个不同之处在于TCP连接是点对点的。换句话说，TCP的使用是在一个接收端和一个发送端之间的。而对于UDP来说，一个发送端可能发向多个接收端或者多个发送端能够发给一个接收端。TCP和UDP最后一个不同之处是它们首部的大小。不少于20字节&固定8字节。TCP和UDP接收端不存在（不启动接收端）TCP发送端的输出（可以看到连接和传输失败信息）UDP发送端的输出（与数据传输成功一致，看不出传输失败）观察分析tcp_2transmit.cap。TCP连接在tcp_2transmit.cap的分组14-19中。分组14发送端试图通过向接收端发送一个SYN分组来打开TCP连接，分组15接收端回复了一个通告窗口是0并且具有RESET标志置位1的TCP报文段，这明确表示接收端并不愿意在这个连接上接收任何数据。发送端上的TCP层实际上尝试不止两次（14、16、18分组）发送SYN分组来建立一个连接，但是接收端返回分组15、17、19，内容都一样。值得注意的是，新连接的端口号和前面的成功连接不一样(是4958而不是4957）。TCP会发现连接失败，所以它能够向传输应