【刷题】面筋-网络-TCP三次握手和四次挥手的全过程

图示

TCP

• 序列号seq：

  • 占4个字节，用来标记数据段的顺序，TCP把链接中发送的全部数据字节都编上一个序号，第一个字节的编号由本地随机产生；
  • 给字节编上序号后，就给每个报文段指派一个序号；序列号seq就是这个报文段中的第一个字节的数据编号。

• 确认号ack：

  • 占4个字节，期待收到对方下一个报文段的第一个数据字节的序号；
  • 序列号表示报文段携带数据的第一个字节的编号，而确认号指的是指望接收到下一个字节的编号；
  • 所以当前报文段最后一个字节的编号+1即为确认号。

• 确认ACK：

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

• 同步SYN：

  • 链接创建时用于同步序号。
  • 当SYN=1，ACK=0时表示：这是一个链接请求报文段。若赞成链接，则在响应报文段中使得SYN=1，ACK=1。
  • 所以，SYN=1表示这是一个链接请求，或链接接受报文。SYN这个标志位只有在TCP建产链接时才会被置1，握手完成后SYN标志位被置0。

• 终止FIN：

  • 用来释放一个链接。FIN=1表示：此报文段的发送方的数据已经发送完毕，并要求释放运输链接

• PS：

  • ACK、SYN和FIN这些大写的单词表示标志位，其值要么是1，要么是0；ack、seq小写的单词表示序号。

三次握手：

图示

解析

首先Client端发送链接请求报文，Server段接受链接后回复ACK报文，并为此次链接分配资源。Client端接收到ACK报文后也向Server段发生ACK报文，并分配资源，这样TCP链接就创建了。

最初两端的TCP进程都处于CLOSED关闭状态，A主动打开链接，而B被动打开链接。（A、B关闭状态CLOSED——B收听状态LISTEN——A同步已发送状态SYN-SENT——B同步收到状态SYN-RCVD——A、B链接已创建状态ESTABLISHED）

B的TCP服务器进程先建立传输控制块TCB，准备接受客户进程的链接请求。而后服务器进程就处于LISTEN（收听）状态，等待客户的链接请求。如有，则做出响应。
1）第一次握手：A的TCP客户进程也是首先建立传输控制块TCB，而后向B发出链接请求报文段，（首部的同步位SYN=1，初始序号seq=x），（SYN=1的报文段不能携带数据）但要消耗掉一个序号，此时TCP客户进程进入SYN-SENT（同步已发送）状态。
2）第二次握手：B收到链接请求报文段后，如赞成创建链接，则向A发送确认，在确认报文段中（SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y），测试TCP服务器进程进入SYN-RCVD（同步收到）状态；
3）第三次握手：TCP客户进程收到B的确认后，要向B给出确认报文段（ACK=1，确认号ack=y+1，序号seq=x+1）（初始为seq=x，第二个报文段因此要+1），ACK报文段能够携带数据，不携带数据则不消耗序号。TCP链接已经创建，A进入ESTABLISHED（已创建链接）。
当B收到A的确认后，也进入ESTABLISHED状态。

总结：

第一次握手：起初两端都处于CLOSED关闭状态，Client将标志位SYN置为1，随机产生一个值seq=x，并将该数据包发送给Server，Client进入SYN-SENT状态，等待Server确认；
第二次握手：Server收到数据包后由标志位SYN=1得知Client请求创建链接，Server将标志位SYN和ACK都置为1，ack=x+1，随机产生一个值seq=y，并将该数据包发送给Client以确认链接请求，Server进入SYN-RCVD状态，此时操做系统为该TCP链接分配TCP缓存和变量；
第三次握手：Client收到确认后，检查ack是否为x+1，ACK是否为1，若是正确则将标志位ACK置为1，ack=y+1，而且此时操做系统为该TCP链接分配TCP缓存和变量，并将该数据包发送给Server，Server检查ack是否为y+1，ACK是否为1，若是正确则链接创建成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client和Server就能够开始传输数据。

三次握手常见问题

为何要三次握手

TCP 创建链接，其实经过两次握手就能够创建链接了，为何要三次呢？是否是画蛇添足呢？

一、《计算机网络》中是这样说的：

为了防止已失效的链接请求报文段忽然又传送到了服务端，于是产生错误。
在书中同时举了一个例子，以下：
已失效的链接请求报文段”的产生在这样一种状况下：client发出的第一个链接请求报文段并无丢失，而是在某个网络结点长时间的滞留了，以至延误到链接释放之后的某个时间才到达server。原本这是一个早已失效的报文段。但server收到此失效的链接请求报文段后，就误认为是client再次发出的一个新的链接请求。因而就向client发出确认报文段，赞成创建链接。假设不采用“三次握手”，那么只要server发出确认，新的链接就创建了。因为如今client并无发出创建链接的请求，所以不会理睬server的确认，也不会向server发送数据。但server却觉得新的运输链接已经创建，并一直等待client发来数据。这样，server的不少资源就白白浪费掉了。采用“三次握手”的办法能够防止上述现象发生。例如刚才那种状况，client不会向server的确认发出确认。server因为收不到确认，就知道client并无要求创建链接。”

二、网络故障

好比，如今网络出现了故障，只能发请求数据包，而接收不到响应数据包，那么只要发送一次请求，服务器就创建请求，这样确定也是不对的，网络请求有来有回才能完成通信。因此三次握手是必不可少的。

Server端易受到SYN攻击？

服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，因此服务器容易受到SYN洪泛攻击，SYN攻击就是Client在短期内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，因为源地址不存在，所以Server须要不断重发直至超时，这些伪造的SYN包将长时间占用未链接队列，致使正常的SYN请求由于队列满而被丢弃，从而引发网络拥塞甚至系统瘫痪。

四次挥手

图示

解析

假设Client端发起中断链接请求，也就是发送FIN报文。Server端接到FIN报文后，意思是说"我Client端没有数据要发给你了"，可是若是你还有数据没有发送完成，则没必要急着关闭Socket，能够继续发送数据。因此你先发送ACK，"告诉Client端，你的请求我收到了，可是我还没准备好，请继续你等个人消息"。这个时候Client端就进入FIN_WAIT状态，继续等待Server端的FIN报文。当Server端肯定数据已发送完成，则向Client端发送FIN报文，"告诉Client端，好了，我这边数据发完了，准备好关闭链接了"。Client端收到FIN报文后，"就知道能够关闭链接了，可是他仍是不相信网络，怕Server端不知道要关闭，因此发送ACK后进入TIME_WAIT状态，若是Server端没有收到ACK则能够重传。“，Server端收到ACK后，"就知道能够断开链接了"。Client端等待了2MSL后依然没有收到回复，则证实Server端已正常关闭，那好，我Client端也能够关闭链接了。Ok，TCP链接就这样关闭了！

数据传输结束后，通讯的双方均可释放链接，A和B都处于ESTABLISHED状态。（A、B链接创建状态ESTABLISHED——A终止等待1状态FIN-WAIT-1——B关闭等待状态CLOSE-WAIT——A终止等待2状态FIN-WAIT-2——B最后确认状态LAST-ACK——A时间等待状态TIME-WAIT——B、A关闭状态CLOSED）

1）A的应用进程先向其TCP发出链接释放报文段（FIN=1，序号seq=u），并中止再发送数据，主动关闭TCP链接，进入FIN-WAIT-1（终止等待1）状态，等待B的确认。
2）B收到链接释放报文段后即发出确认报文段，（ACK=1，确认号ack=u+1，序号seq=v），B进入CLOSE-WAIT（关闭等待）状态，此时的TCP处于半关闭状态，A到B的链接释放。
3）A收到B的确认后，进入FIN-WAIT-2（终止等待2）状态，等待B发出的链接释放报文段。
4）B没有要向A发出的数据，B发出链接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），B进入LAST-ACK（最后确认）状态，等待A的确认。
5）A收到B的链接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），A进入TIME-WAIT（时间等待）状态。此时TCP未释放掉，须要通过时间等待计时器设置的时间2MSL后，A才进入CLOSED状态。

总结四次挥手过程：

起初A和B处于ESTABLISHED状态——A发出链接释放报文段并处于FIN-WAIT-1状态——B发出确认报文段且进入CLOSE-WAIT状态——A收到确认后，进入FIN-WAIT-2状态，等待B的链接释放报文段——B没有要向A发出的数据，B发出链接释放报文段且进入LAST-ACK状态——A发出确认报文段且进入TIME-WAIT状态——B收到确认报文段后进入CLOSED状态——A通过等待计时器时间2MSL后，进入CLOSED状态。

四次挥手常见问题

为何要四次挥手呢

TCP协议是一种面向链接的、可靠的、基于字节流的运输层通讯协议。TCP是全双工模式，这就意味着，当 Client 发出FIN报文段时，只是表示 Client 已经没有数据要发送了，Client 告诉 Server，它的数据已经所有发送完毕了；可是，这个时候 Client 仍是能够接受来自 Server 的数据；当 Server 返回ACK报文段时，表示它已经知道 Client 没有数据发送了，可是 Server 仍是能够发送数据到 Client 的；当 Server 也发送了FIN报文段时，这个时候就表示 Server 也没有数据要发送了，就会告诉 Client ，我也没有数据要发送了，以后彼此就会愉快的中断此次TCP链接。若是要正确的理解四次分手的原理，就须要了解四次分手过程当中的状态变化。

为何A在TIME-WAIT状态必须等待2MSL的时间？

MSL最长报文段寿命Maximum Segment Lifetime，MSL=2

答：两个理由：1）保证A发送的最后一个ACK报文段可以到达B。2）防止“已失效的链接请求报文段”出如今本链接中。

1）这个ACK报文段有可能丢失，使得处于LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认，B超时重传FIN+ACK报文段，而A能在2MSL时间内收到这个重传的FIN+ACK报文段，接着A重传一次确认，从新启动2MSL计时器，最后A和B都进入到CLOSED状态，若A在TIME-WAIT状态不等待一段时间，而是发送完ACK报文段后当即释放链接，则没法收到B重传的FIN+ACK报文段，因此不会再发送一次确认报文段，则B没法正常进入到CLOSED状态。
2）A在发送完最后一个ACK报文段后，再通过2MSL，就可使本链接持续的时间内所产生的全部报文段都从网络中消失，使下一个新的链接中不会出现这种旧的链接请求报文段。

为何链接的时候是三次握手，关闭的时候倒是四次握手？

答：由于当Server端收到Client端的SYN链接请求报文后，能够直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。可是关闭链接时，当Server端收到FIN报文时，极可能并不会当即关闭SOCKET，因此只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端全部的报文都发送完了，我才能发送FIN报文，所以不能一块儿发送。故须要四步握手。

为何TIME_WAIT状态须要通过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

答：虽然按道理，四个报文都发送完毕，咱们能够直接进入CLOSE状态了，可是咱们必须假象网络是不可靠的，有能够最后一个ACK丢失。因此TIME_WAIT状态就是用来重发可能丢失的ACK报文。

END