一、TCP为什么连接要三次

• 在《计算机网络》一书中其中有提到，三次握手的目的是“为了防止已经失效的连接请求报文段突然又传到服务端，因而产生错误”
• 图示如下：
  • 假设A主动向B发起连接，并且A向B发送了一条消息“你好”，但是由于网络的原因，A的第一条消息被阻塞在网络链路中
  • 过了一段时间之后由于TCP的超时重传机制，A又向B发送了一条消息，此时这条消息到达了，此时A与B建立连接
  • A与B进行一系列通信之后断开连接，此时A第一次发送的消息到达了B，B以为A又要与B建立连接，但是A其实没有这个意思，于是B就一直在等待A的确认，这样白白浪费了资源

• 我们一步一步解析原因：
  • 第一次：首先A发送一个(SYN)到B，意思是A要和B建立连接进行通信； 
    • 如果是只有一次握手的话，这样肯定是不行的，A压根都不知道B是不是收到了这个请求
  • 第二次：B收到A要建立连接的请求之后，发送一个确认(SYN+ACK)给A，意思是收到A的消息了，B这里也是通的，表示可以建立连接；
    • 如果只有两次通信的话，这时候B不确定A是否收到了确认消息，有可能这个确认消息由于某些原因丢了
  • 第三次：A如果收到了B的确认消息之后，再发出一个确认(ACK)消息，意思是告诉B，这边是通的，然后A和B就可以建立连接相互通信了；
    • 这个时候经过了三次握手，A和B双方确认了两边都是通的，可以相互通信了，已经可以建立一个可靠的连接，并且可以相互发送数据
  • 第四次：这个时候已经不需要B再发送一个确认消息了，两边已经通过前三次建立了一个可靠的连接，如果再发送第四次确认消息的话，就浪费资源了。
    • 如果第二个报文段B发出的(SYN+ACK)分别发送的话，也是可以理解为四次，但是被优化了，一起发送了
  • ...以此类推，后面都是相同的原理

二、TCP为什么断开要四次

• 本质的原因是tcp是全双公的，要实现可靠的连接关闭：
  • A发出结束报文FIN，收到B确认后A知道自己没有数据需要发送了，B知道A不再发送数据了，自己也不会接收数据了
  • 但是此时A还是可以接收数据，B也可以发送数据；当B发出FIN报文的时候此时两边才会真正的断开连接，读写分开