第三次实验报告:使用Packet Tracer分析TCP连接建立过程
R(config)#router rip #
R(config-router)#version 2 #使用rap版本
R(config-router)#no auto-summary #关闭自动路由汇总
R(config-router)#network 192.168.1.0 #指定网络
R(config-router)#network 192.168.2.0
3.3 抓包,分析TCP连接建立过程
PC访问服务端
抓包:
报文:
(1)画出TCP连接建立示意图
如下图所示:
(2)分析序号和确认号的变化
在打算建立TCP连接时,向服务器发出报文段,这时首部中的同步位SYN=1,同时选择一个初始序号seq=0。
服务器连接请求报文段后,如同意建立连接,则向pc发送确认。在确认报文段中应把SYN位和ACK位都置1,确认号是ack=1,同时也为自己选择一个初始序号seq=0。
pc收到服务器的确认后,还要向服务器发送确认。在确认报文段中应把SYN位和ACK位都置1,确认号是ack=1,而自己的序号seq=1。
(3)解答:为什么连接建立需要第三次握手
为了防止已失效的连接请求报文段突然又传到了B,因而产生错误。 已失效的报文段:正常情况下:A发出连接请求,但因为丢失了,故而不能收到B的确认。于是A重新发出请求,然后收到确认,建立连接,数据传输完毕后,释放连接,A发了2个,一个丢掉,一个到达,没有“已失效的报文段” 但是,某种情况下,A的第一个在某个节点滞留了,延误到达,本来这是一个早已失效的报文段,但是在A发送第二个,并且得到B的回应,建立了连接以后,这个报文段竟然到达了,于是B就认为,A又发送了一个新的请求,于是发送确认报文段,同意建立连接,假若没有三次的握手,那么这个连接就建立起来了(有一个请求和一个回应),此时,A收到B的确认,但A知道自己并没有发送建立连接的请求,因为不会理睬B的这个确认,于是呢,A也不会发送任何数据,而B呢却以为新的连接建立了起来,一直等待A发送数据给自己,此时B的资源就被白白浪费了。但是采用三次握手的话,A就不发送确认,那么B由于收不到确认,也就知道并没有要求建立连接。总之:第三次握手,主机A发送一次确认是为了防止:如果客户端迟迟没有收到服务器返回的确认报文,这时他会放弃连接,重新启动一条连接请求;但问题是:服务器不知客户端没收到,所以他会收到两个连接请求,白白浪费了一条连接开销。
4. 拓展
(1)分析TCP连接释放