TCP三次握手

目录

三次握手

为什么是三次而不是两次？

如何解决丢包问题、乱序问题？

四次挥手

---

        两个协议都工作在传输层，在程序之间传输数据（可以是文本文件、视频、图片）。对这两个协议来说，都是二进制数，

        两者的区别是什么？TCP是基于连接的，UDP是基于非连接的。

        

        那么TCP如何保证以上过程的呢？

        有三个关键的过程：分别为三次握手、传输确认、四次挥手

三次握手

        是建立连接的过程，客户端向服务端发起连接时，会先发一包连接请求数据，问一下能不能建立连接，这包数据称为SYN包，如果对方同意连接，就会回复一个SYN+ACK包，客户端收到之后，回复一个ACK包，然后连接建立。因为这个过程互相发送了三包数据，所以称之为三次握手。

为什么是三次而不是两次？

        如果只有两次的话，假设客户端先发送了一个SYN1包，但是这个包由于某些原因，在网络节点中滞留，而并没有发送过去，那为了建立连接，客户端会重新发送一个SYN2包，这次数据包正常送达，服务端回复SYN+ACK包，建立连接，那么之后SYN1包突然又到达。这时服务端会认为这个是客户端发送的连接请求，从而进入等待数据状态，服务端认为是两个连接，客户端认为是一个连接，造成了状态不一致，三次握手的话，服务端不收到最后的ACK包，自然不会认为建立成功，所以三次握手就是解决一个网络信道不可信的问题。TCP协议需要在不可靠的信道上，建立可靠的连接。

        

 

如何解决丢包问题、乱序问题？

        为了解决这些问题，TCP协议为每一个连接，建立了一个发送缓冲区

        从建立连接后，第一个字节的序列号为0，后面每个字节的序列号都会加1

        发送数据时，从发送缓冲区，取一部分数据组成发送报文，在TCP协议头部，会附带序列号和长度，

 

        接收端在接受数据后，会回复确认报文。

        也就是下一包数据的起始序列号

        一问一答，就可以使发送端确认，对方已经收到消息。

        发送端可以把待发送的数据，分割成一系列的碎片，发送到对端，对端根据序列号和长度，接受后重构出完整的数据，假设丢失了一部分包，接收端可以要求发送端重新传输数据。

四次挥手

        处于连接状态的客户端和服务端，都可以发送关闭连接的请求，需要四次挥手来进行连接关闭

        假设客户端主动发起断开连接的请求，需要向服务端发起一包FIN包，表示要关闭连接，自己进入终止等待1状态，服务端收到FIN包，发送了一个ACK包，表示自己进入关闭等待状态。客户端进入终止等待2状态，这是第二次挥手。等待服务端数据发送完成，服务端发送一包FIN包，进入最后确认状态，这是第三次挥手，客户端收到之后，回复ACK包，进入超时等待状态，经过超时时间后关闭连接。服务端收到ACK包后立刻关闭连接，这是第四次挥手。

 

        为什么客户端需要等待超时时间，为了保证对方已经收到ACK包，如果不是这样，那一旦发送完了最后的ACK包就释放了连接，一旦ACK包在网络中丢失，服务端将一直停留在最终确认状态。服务端如果没有收到ACK包，会重新发送FIN包，客户端相应这个FIN包，并刷新超时等待时间，也是为了在不可靠的链路中，呦可靠的连接断开。