三次握手过程
建立TCP连接时,需要客户端和服务器共发送3个包。
• 第一次:客户端发送初始序号x和syn=1请求标志
• 第二次:服务器发送请求标志syn,发送确认标志ACK,发送自己的序号seq=y,发送客户端的确认序号ack=x+1
• 第三次:客户端发送ACK确认号,发送自己的序号seq=x+1,发送对方的确认号ack=y+1
3.1 四次挥手过程
• 第一次挥手:客户端发出释放FIN=1,自己序列号seq=u,进入FIN-WAIT-1状态
• 第二次挥手:服务器收到客户端的后,发出ACK=1确认标志和客户端的确认号ack=u+1,自己的序列号seq=v,进入CLOSE-WAIT状态
• 第三次挥手:客户端收到服务器确认结果后,进入FIN-WAIT-2状态。此时服务器发送释放FIN=1信号,确认标志ACK=1,确认序号ack=u+1,自己序号seq=w,服务器进入LAST-ACK(最后确认态)
• 第四次挥手:客户端收到回复后,发送确认ACK=1,ack=w+1,自己的seq=u+1,客户端进入TIME-WAIT(时间等待)。客户端经过2个最长报文段寿命后,客户端CLOSE;服务器收到确认后,立刻进入CLOSE状态。
为什么三次握手和四次挥手?
• 三次握手时,服务器同时把ACK和SYN放在一起发送到了客户端那里
• 四次挥手时,当收到对方的 FIN 报文时,仅仅表示对方不再发送数据了但是还能接收数据,己方是否现在关闭发送数据通道,需要上层应用来决定,因此,己方 ACK 和 FIN 一般都会分开发送。
4.2为什么客户端最后还要等待2MSL?
• 客户端需要保证最后一次发送的ACK报文到服务器,如果服务器未收到,可以请求客户端重发,这样客户端还有时间再发,重启2MSL计时。
作者:车小胖
链接:https://www.zhihu.com/question/271701044/answer/398114686
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
ISN代表什么?意义何在?
ISN,发送方的字节数据编号的原点,让对方生成一个合法的接收窗口。
ISN是固定不变的吗?
动态随机。
ISN为何要动态随机?
增加安全性,为了避免被第三方猜测到,从而被第三方伪造的RST报文Reset。
还有吗?
ISN动态随机使得每个tcp session的字节序列号没有重叠,如果出现tcp五元组冲突这种极小概率情况的发生,一个session的数据也不会被误认为是另一个session的。
刚才你提到第三方可以伪造RST报文,需要满足什么条件才能得逞?
需要sequence number 位于对方的合法接收窗口内。 而由于ISN是动态随机的,猜出对方合法接收窗口难度加大。
如果ISN = 0,那么猜出的难度就大大降低。
三次握手的第一次可以携带数据吗?为何?
不可以,三次握手还没有完成。
对方难道不可以将数据缓存下来,等握手成功再提交给应用程序?
这样会放大SYN FLOOD攻击。
如果攻击者伪造了成千上万的握手报文,携带了1K+ 字节的数据,而接收方会开辟大量的缓存来容纳这些巨大数据,内存会很容易耗尽,从而拒绝服务。
第三次可以携带数据吗?为何?
可以。
能够发出第三次握手报文的主机,肯定接收到第二次(服务器)握手报文,对吗?
因为伪造IP的主机是不会接收到第二次报文的。
所以,能够发出第三次握手报文的,应该是合法的用户。
尽管服务器侧的状态还没有“established”,接收到第三次握手的瞬间,状态就会切换为“established”,里面携带的数据按照正常流程走就好。
看到有人说,只看到过TCP状态位为 ’FIN +ACK’,但从来没有看过状态位只有 ‘FIN’,你应该怎样给他解释?
RFC793明确规定,除了第一个握手报文SYN除外,其它所有报文必须将ACK = 1。
很好,RFC规定的背后肯定有合理性的一面,能否深究一下原因?
TCP作为一个可靠传输协议,其可靠性就是依赖于收到对方的数据,ACK对方,这样对方就可以释放缓存的数据,因为对方确信数据已经被接收到了。
但TCP报文是在IP网络上传输,丢包是家常便饭,接收方要抓住一切的机会,把消息告诉发送方。最方便的方式就是,任何我方发送的TCP报文,都要捎带着ACK状态位。
ACK状态位单独能承担这个消息传递的任务吗?
不能!需要有 Acknowledge Number配合才行。
如果我方发出的Acknowledge Number == 10001,那意味着序列号10000及之前的字节已经成功接收。
如果对方占据字节序列号10000是应用层数据,那么就是确认应用层数据。
如果对方占据字节序列号10000是’FIN’状态位,那么就是确认接收到对方的’FIN’。