TCP协议给使用者提供了两种服务,分别是面向连接的服务和可靠的数据传输服务,我们简单介绍一下。简单来说面向连接的含义是客户机和服务器之间需要建立连接,在位于应用层的数据开始交互之前,TCP协议首先要先让客户机和服务器进行一次握手。这么做相当于告知彼此接下来需要进行数据的交互,请双方做好准备,具体的实现方式为双方在传输层交互信息。握手阶段结束之后,就能够建立起TCP连接,双方应用程序的数据交互完毕之后,还需要切断这个连接。
所谓TCP连接是一种逻辑上的连接,它可以提供全双工服务,即应用层数据可以在建立连接的进程之间相互传输。TCP连接也是点对点的,因为这是针对单个发送方和单个接收方之间的连接。
接下来再看看何谓可靠的数据传输服务,即双方的数据交互在TCP协议的保障下,彼此发出的数据能够无差别、按照正确顺序传递给对方。即TCP会将发送方通过套接字传出的字节流,在保证字节不发生丢失和出现多余的情况下,将字节流交付给接收方的套接字。
源端口、目的端口:各占2字节,端口是运输层与应用层的服务接口,运输层的复用和分用功能都要通过端口才能实现。
序号:占4字节,TCP连接中传送的数据流中的每一个字节都编上一个序号,序号字段的值则指的是本报文段所发送的数据的第一个字节的序号。
确认号:占4字节,是期望收到对方的下一个报文段的数据的第一个字节的序号。
首部长度:占4位,它指出TCP报文段的数据起始处距离TCP报文段的起始处有多远,的单位是32位字(以4字节为计算单位)。
保留:占6位,保留为今后使用,但目前应置为0。
接收窗口:占2字节,用于流量控制,指示接收方愿意接收的字节数量,单位为字节。
检验和:占2字节。检验和字段检验的范围包括首部和数据这两部分。在计算检验和时,要在TCP报文段的前面加上12字节的伪首部。
选项:长度可变。TCP最初只规定了最大报文段长度MSS,表示缓存所能接收的报文段的数据字段的最大长度是MSS个字节。
紧急URG:当URG=1时,表明紧急指针字段有效。它告诉系统此报文段中有紧急数据,应尽快传送(相当于高优先级的数据)。
确认ACK:只有当ACK=1时确认号字段有效,当ACK=0时确认号无效。
推送PSH(PuSH):接收TCP收到PSH=1的报文段,就尽快地交付接收应用进程,不再等到整个缓存都填满了后再向上交付。
复位RST(ReSeT):当RST=1时,表明TCP连接中出现严重差错(如由于主机崩溃或其他原因)必须释放连接,然后再重新建立运输连接。
同步SYN:同步SYN=1表示这是一个连接请求或连接接受报文。
终止FIN(FINish):用来释放一个连接。FIN=1表明此报文段的发送端的数据已发送完毕,并要求释放运输连接。
首先使用Wireshark来获取文件从计算机到远程服务器的TCP传输的数据包内容。通过访问一个网页,在网页上输入您计算机上储存的文件名称,然后使用HTTPPOST方法将文件传输到Web服务器,并在此期间运行Wireshark以获取从计算机发送和接收的TCP区段的内容。执行如下操作:
1.在电脑上保存一个ASCII文件:
2.打开http://gaia.cs.umass.edu/wireshark-labs/TCP-wireshark-file1.html:
3.使用此表单中的“选择文件”按钮上传文件:
4.启动Wireshark并开始数据包捕获:
5.返回浏览器,按“Uploadalice.txtfile”按钮将文件上传到gaia.cs.umass.edu服务器:
6.停止Wireshark数据包捕获:
干扰巨大,现成的包来分析吧。
在过滤器指定窗口中输入“tcp”过滤Wireshark视窗中显示的数据包:
可以应该看到的是计算机和gaia.cs.umass.edu之间的一系列TCP和HTTP讯息,首先是看到包含SYN讯息的初始三次握手。
接下来有HTTPPOST信息。
在Wireshark显示的Info列中有不少“[重新组装的PDU的TCP段]”,以指示此TCP区段包含属于上层协议讯息的数据(这里是HTTP)。
还有gaia.cs.umass.edu返回到您的计算机的TCP ACK区段。
回答以下问题:
1.将文件传输到gaia.cs.umass.edu的客户端计算机(源)使用的IP地址和TCP端口号是什么?
IP地址:192.168.1.102
TCP端口号:1161
2.gaia.cs.umass.edu的IP地址是什么?在哪个端口号上发送和接收此连接的TCP区段?
IP地址:128.119.245.12
接收连接的端口号:80
现在我们关注TCP而不是HTTP,因此更改Wireshark的“捕获数据包列表”视窗,以便显示有关包含HTTP讯息的TCP区段的信息。要让Wireshark执行此操作,选择Analyze->EnabledProtocols。
然后取消勾选HTTP框,并选择确定。
这些是计算机和gaia.cs.umass.edu之间发送的一系列TCP区段。
回答下列问题:
1.用于在客户端计算机和gaia.cs.umass.edu之间启动TCP连接的TCPSYN区段的序列号是什么?将区段标识为SYN区段的区段有什么功能?
序列号为0,功能是开始三次握手,主机发送SYN请求服务器建立连接,这是三次握手的第一步。
2.gaia.cs.umass.edu发送给客户端计算机以回复SYN的SYNACK区段的序列号是多少?
序列号为0。
SYNACK区段中的Acknowledgment栏位的值是多少?
Acknowledgment栏位的值是1。
Gaia.cs.umass.edu是如何确定此Acknowledgment的数值的?在将区段标识为SYNACK区段的区段在连线中有什么功能?
Ack字段用于表示确认字段中的值是有效的,功能是说明服务器成功接收了我们发出的连接请求,并发送SYN-ACK确认报文。
3.包含HTTPPOST命令的TCP区段的序列号是多少?
序列号为1,其中PSH表示有数据传输。
4.将包含HTTPPOST的TCP区段视为TCP连接中的第一个区段。前六个TCP区段的长度是多少?在这个TCP连线中前6个TCP区段的序列号是什么(包括包含HTTPPOST的段)?每区段发送的时间是什么时候?收到的每个区段的ACK是什么时候?鉴于发送每个TCP区段的时间与收到确认的时间之间的差异,六个区段中每个区段的RTT值是多少?收到每个ACK后,EstimatedRTT值是什么?假设第一个EstimatedRTT的值等于第一个区段的测量RTT。
EstimatedRTT运算公式
EstimatedRTT=(1-a)×EstimatedRTT+a×SampleRTT
其中a使用推荐值0.125。
区段一:
长度:565
序列号:1
发送时间:2004年8月21日21:44:20.596858000
RTT:0.027460000seconds
EstimatedRTT=RTT=0.027460000seconds
区段二:
长度:1460
序列号:566
发送时间:2004年8月21日21:44:20.612118000
RTT:0.035557000seconds
EstimatedRTT=0.875×0.027460000+0.125×0.035557000=0.028472125seconds
区段三:
长度:1460
序列号:2026
发送时间:2004年8月21日21:44:20.624407000
RTT:0.070059000seconds
EstimatedRTT=0.875×0.028472125+0.125×0.070059000=0.033670484seconds
区段四:
长度:1460
序列号:3486
发送时间:2004年8月21日21:44:20.625071000
RTT:0.114428000seconds
EstimatedRTT=0.875×0.033670484+0.125×0.114428000=0.043765173seconds
区段五:
长度:1460
序列号:4946
发送时间:2004年8月21日21:44:20.647786000
RTT:0.139894000seconds
EstimatedRTT=0.875×0.043765173+0.125×0.139894000=0.055781277seconds
区段六:
长度:1460
序列号:6406
发送时间:2004年8月21日21:44:20.648538000
RTT:0.189645000seconds
EstimatedRTT=0.875×0.055781277+0.125×0.189645000=0.072514242seconds
5.对于整个跟踪包,收到的最小可用缓冲区空间量是多少?缺少接收器缓冲区空间是否会限制发送方传送TCP区段?
对于服务器而言,收到的最小可用缓冲区空间量为6780。
对于主机而言,收到的最小可用缓冲区空间量为5840。
缺少接收器缓冲区空间会限制发送方传送TCP区段,这是因为TCP的流量控制服务,能够消除发送方使接收方缓存溢出的可能性,使得发送方的发送速率与接收方应用程序的读取速率相匹配。实现的方式是滑动窗口协议,具体可参考后文附带的资料。
6.在跟踪文件中是否有重传的区段?
检查数据包的时间序列:
因为序列号呈增大趋势,因此没有重传。
7.接收器通常在ACK中确认多少数据?是否可以识别接收方每隔一个接收到的区段才发送确认的情况?
(这个回答难以保证正确,欢迎纠错)接收器通常在ACK中确认序列号,可以确认,根据ACK序列号的顺序来推测。
8.TCP连接的吞吐量(每单位时间传输的⫿节数)是多少?如何计算这个值?
平均吞吐量=传输数据的比特数F÷接收方接收所有数据所用时间T
首先看看传输数据的比特数F=164090bytes
再看看接收方接收所有数据所用时间T=5.297341000seconds
吞吐量=164090÷5.297341000=30.975917918064Kb/s
现在检查从客户端服务器的每单位时间发送的数据量,从Wireshark窗口中的原始数据计算这些数值。
每个点代表一个发送的TCP区段,绘制区段的序列号与发送的时间,堆叠在一起的一组点表示发送方背靠背发送的一系列数据包。使用时序图(Stevens)查看从客户端发送到gaia.cs.umass.edu服务器的区段的序列号与时间关系图。您能否确定TCP的慢启动阶段的开始和结束位置,以及拥塞避免接管的位置?
慢启动的原理是:连接开始时,发送速率呈指数型增长。因此TCP开始发送的速率很慢,但是慢启动阶段增长很快。
如图所示,慢启动阶段的开始肯定是在第一个TCP区段发出去的时候,也就是分组5发送的时候。
结束位置是什么时候?观察到这样的指数型增长的速率在分组23处卡壳了,说明这个时候发生了拥塞,进入拥塞避免阶段。
这个区域就是拥塞避免区段。
2.评论测量数据与我们在文本中研究的TCP的理想化行为的不同之处。
慢启动是TCP在拥塞控制方面做的努力之一,但是对于一些数据量较小的小文件,在网络畅通的情况下发送非常快,甚至可能在慢启动结束之前就已经发送完毕。这个问题要怎么理解呢?例如我需要发送一个5单位大小的文件,假定一个窗口在一个单位时间内可以发送一个单位大小的数据报。如果是初始窗口为1个的慢启动,窗口按照指数型增长,就需要3个单位时间才能发送完毕。而如果一开始就拥有大于5个的窗口,则1个单位时间就可以发送完毕,这个时候慢启动反而来制约了文件的快速发送,从而影响了效率。
由此可见慢启动并不是永远都是高效的,在一些情况下效率不会达到最好。这种情况不可否认,不过慢启动在拥塞控制方面的贡献,在总体上仍然是一个很好的手法!
[1]滑动窗口协议