Chinaunix首页 | 论坛 | 博客
  • 博客访问: 274404
  • 博文数量: 138
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 971
  • 用 户 组: 普通用户
  • 注册时间: 2015-03-03 10:05
文章分类

全部博文(138)

文章存档

2016年(1)

2015年(137)

我的朋友

分类: 网络与安全

2015-08-18 12:34:43

TCP报文段首部格式:

序号:本报文段所发送的数据的第一个字节的序号。

确认号ack期待收到对方下一个报文段的第一个数据字节的序号

确认ACK:占1位,仅当ACK=1时,确认号字段才有效。ACK=0时,确认号无效

同步SYN:连接建立时用于同步序号。当SYN=1,ACK=0时表示:这是一个连接请求报文段。

              若同意连接,则在响应报文段中使得SYN=1,ACK=1。因此,SYN=1表示这是一个连接请求,或连接接受报文。

终止FIN:用来释放一个连接。FIN=1表示:此报文段的发送方的数据已经发送完毕,并要求释放运输连接

 

三次握手(三次联络)

  
① SYN=1 表示连接请求 ,序列号是x;
② SYN=1 表示连接响应;ACK=1,表示确认号ack有效;ack是对请求序列号x的响应,所以ack=x+1;同时,发出自己的序列号y,(用以下一条来确认)。
③ ACK=1 表示ack有效,同时ack是对上一条的seq的响应,所以ack=y+1; 这条请求是客户A发送给B的,所以,是上一条A发送给B的消息的下一条,所以是序列号是 x+1;

还要再发送一次确认是为了,防止已失效的连接请求报文段突然又传到了B,因而产生错误。

已失效的报文段:正常情况下:A发出连接请求,但因为丢失了,故而不能收到B的确认。于是A重新发出请求,然后收到确认,建立连接,数据传输完毕后,释放连接,A发了2个,一个丢掉,一个到达,没有“已失效的报文段”

但是,某种情况下,A的第一个在某个节点滞留了,延误到达,本来这是一个早已失效的报文段,但是在A发送第二个,并且得到B的回应,建立了连接以后,这个报文段竟然到达了,于是B就认为,A又发送了一个新的请求,于是发送确认报文段,同意建立连接,假若没有三次的握手,那么这个连接就建立起来了(有一个请求和一个回应),此时,A收到B的确认,但A知道自己并没有发送建立连接的请求,因为不会理睬B的这个确认,于是呢,A也不会发送任何数据,而B呢却以为新的连接建立了起来,一直等待A发送数据给自己,此时B的资源就被白白浪费了。但是采用三次握手的话,A就不发送确认,那么B由于收不到确认,也就知道并没有要求建立连接。

有可能会出现 延迟的请求建立 和 同时延迟的 请求建立和相应信号;三次握手都可以解决!

四次握手(两个二次握手)

 
① A给B发送释放连接请求,所以 ,FIN=1;同时,序列号表征A发给B的消息的条数 seq=u; 同时 A进入FIN_WAIT1
② B对A的请求进行确认,ACK=1,ack=u+1;同时发送自己的消息序列号v;B进入colos_wait状态,A进入FIN_wait2状态
此时 B被动关闭 A对B只接受 不发送 A主动关闭。在B将自己的消息发送完毕之后,B请求主动关闭;
③ B向A发送请求关闭 所以 FIN=1,并对之前A的请求关闭信号做出主动响应,所以ACK=1,且ack=u+1(对之前A的序列u进行响应),同时,B发出自己的序列号 w(因为和v之间还可能有其他数据传送,所以,w不是紧挨着v的);B进入LAST_ACK状态
④ A借到B的主动关闭请求后 对该请求做出响应ACK=1 ,ack=w+!;同时发出自己的序列号seq=u+1;A进入TIME_WAIT状态,维持2MSL;(如果B没有收到该响应,B会超时重发,此时A处于TIME_WAIT,保持可接受状态)

B收到连接释放报文段后就立即发送确认,然后就进入close-wait状态,此时TCP服务器进程就通知高层应用进程,因而从A到B的连接就释放了。此时是“半关闭”状态。即A不可以发送给B,但是B可以发送给A。

此时,若B没有数据报要发送给A了,其应用进程就通知TCP释放连接,然后发送给A连接释放报文段,并等待确认。

A发送确认后,进入time-wait,注意,此时TCP连接还没有释放掉,然后经过时间等待计时器设置的2MSL后,A才进入到close状态。

为什么要等待呢?

①、为了保证A发送的最后一个ACK报文段能够到达B即最后这个确认报文段很有可能丢失,那么B会超时重传,然后A再一次确认,同时启动2MSL计时器,如此下去。如果没有等待时间,发送完确认报文段就立即释放连接的话,B就无法重传了(连接已被释放,任何数据都不能出传了),因而也就收不到确认,就无法按照步骤进入CLOSE状态,即必须收到确认才能close。

②、防止“已失效的连接请求报文段”出现在连接中。经过2MSL,那些在这个连接持续的时间内,产生的所有报文段就可以都从网络中消失。即在这个连接释放的过程中会有一些无效的报文段滞留在楼阁结点,但是呢,经过2MSL这些无效报文段就肯定可以发送到目的地,不会滞留在网络中。这样的话,在下一个连接中就不会出现上一个连接遗留下来的请求报文段了。

可以看出:B结束TCP连接的时间比A早一点,因为B收到确认就断开连接了,而A还得等待2MSL.

阅读(1033) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~