当我们学习《计算机网络》这门课程的时候,一定会学习到TCP这个经典的传输层协议,TCP里面有一个特性叫做连接管理,这个特性里面引出了两个概念,TCP三次握手和四次挥手。为什么是三次,和为什么是四次这个问题困扰了初学的我很久,今天就跟大家详细讲解一下这个原因。
关于这个问题,大多数的文章会引用《计算机网络》里面的一句话。
防止已经失效的连接请求又传到了服务器端,因而产生错误
实际上这么说太宽泛了,是无法真正理解的。
TCP的通信过程是什么样子的?
互相发送报文,这是一件非常容易理解的事情。
例如这样:
那么这个时候我们需要引入一个概念,叫做TCP的缓冲区:
TCP的缓冲区可以理解为一个非常巨大的数组:
当我们的应用层里面有数据传输过来,通过系统调用接口往传输层写数据是写在TCP协议的缓冲区里面,TCP会malloc两段内存空间。拥有缓冲区的作用很明显:
- 提高应用层效率
- 只有OS,TCP协议可以知道网络,乃至对方状态明细,所以也只有TCP协议,能处理如何发,什么时候发, 发多少,出错了怎么办等细节问题,因为缓冲区的存在,所以可以做到应用层和TCP进行解耦
我的TCP缓冲区里面放了很多数据,里面有一部分数据已经发送了,有一部分还没有发送,那么我们这次建立连接的时候要从哪里开发发送呢?这不一定是从0位置(下标)开始的,因此client端和server端需要知道对方的缓冲区从哪里(数组下标)开发发送数据。
- 为了实现可靠数据传输, TCP 协议的通信双方, 都必须维护一个序列号, 以标识发送出去的数据包中, 哪些是已经被对方收到的。 三次握手的过程即是通信双方相互告知序列号起始值, 并确认对方已经收到了序列号起始值的必经步骤
- 如果只是两次握手, 至多只有连接发起方的起始序列号能被确认, 另一方选择的序列号则得不到确认
我们先来看一下TCP通信的完整过程:
大家可以看到这个双方确认序号的过程。
为什么TCP需要握手这个操作?能不能不要握手?
如果对比UDP协议的话可以发现,UDP协议中是不需要握手这个操作的,这里就需要引出TCP和UDP协议的特性了,一个关键的特性就是,TCP协议是可靠协议,UDP协议是不可靠协议。
可靠协议的含义是:接收方收到的数据是完整的,有序的,无差错的。
不可靠就代表着:接收方接收到的数据可能存在部分丢失,顺序也不可以保证。
TCP协议为了实现可靠性,通信双方就需要知道自己发送的数据是否已经被接收方收到了,如果没有收到,就需要重新发送。为了实现这个需求,就要引出序号和确认序号。
发送方在发送数据包(假设大小为 10 byte)时, 同时送上一个序号( 假设为 500),那么接收方收到这个数据包以后, 就可以回复一个确认号(510 = 500 + 10) 告诉发送方 “我已经收到了你的数据包, 你可以发送下一个数据包, 序号从 510 开始” 。
这样发送方就可以知道哪些数据被接收到,哪些数据没被接收到, 需要重发。
于是就有了上图的过程,这样就很好解释为什么是3次,而不是2次了。
有人可能对上面一张图的TCP通信流程的数据有疑问。
- 为什么三次握手最后一次握手中, 在上面的示意图中回复的 seq = x+1 。
来看一下大黑书里面的一段话:
这里说的很复杂,实际上就是:我的ACK里面的序号是我下一个需要得到的序号。
那么为什么是四次挥手呢?
难道不能像三次握手一样去挥手吗?
答案是不可以的,原因是:TCP协议是全双工的。client和server两端都是要传输和处理数据的。我client端请求关闭链接,发送FIN,由OS内核规定,发送FIN了之后会马上回显ACK来表示我收到了这个信息,但是我的server端此时可能正在处理数据,所以不可以马上关闭,只能等事情处理完了之后发送FIN给client,表示我处理完了,client收到之后回显ACK表示收到,然后server关闭,client在2MSL之后也完成关闭。
如果server端没有任何事情处理,那么FIN和ACK就会合并在一起发送,也就是所谓的三次挥手。
也就是说,相比于三次握手,四次挥手多了一个等我把事情做完再给你回电话的过程。
就好像是我找胡桃出去玩:
我:胡桃,我们出去玩儿吧!
胡桃:可以呀!但是我有事情,等我把事情办完再给你打电话。
胡桃:我事情办完了,走吧!
我:好的!
为什么client等2MSL才关闭?
这也是可靠性的保证,如果我发出去的ACK丢包了我要等着重新发送,如果我秒退了怎么办?