TCP协议略详解-三次握手-传输过程-四次挥手

TCP三次握手和四次挥手

三次握手

三次握手的过程演示：（动图来自IM编程网收录文章，原作者为老钱，钱文品：http://www.52im.net/thread-1729-1-1.html）

三次握手即A->B B->A A->B。

A先向B发出**“oi”，B接收到了A的信号并且笑着发出“oi”的信号，A接收到B的”oi“并露出会心的笑**容，然后二位老表开始了愉快的交流。

“oi”代表着寻求确认，笑代表着回复对方。

有两个中间状态，syn_sent和syn_rcvd，这两个状态叫着「半打开」状态，就是向对方发出“oi”了，但是还没来得及看到对方的微笑。syn_sent是主动打开方的「半打开」状态，syn_rcvd是被动打开方的「半打开」状态。客户端是主动打开方，服务器是被动打开方。

TCP协议是这样子的，必须得“事事有回应，件件有着落，凡事有交代，久处不厌，闲谈不烦，从不敷衍，绝不怠慢”，才能谈（划掉）交流下去这样子。

开始数据传输

TCP的数据传输号称不遗失，不错漏，安全超可靠。

那么怎么才能做到呢，当然是饱和式发出消息。在三次握手后建立连接，双方开始传输数据包，每传出去一条数据包（或者双方规定的发送和接受速率）就必须要接收到一次回应，只要没收到回应，不管是因为消息没传递过去还是消息传递过去了但回复消息未成功传递，都会重新传输一遍数据包。

但这样很显然会出现重传问题，但这不是问题，因为去重这项工作操作系统的网络内核模块会处理好的。

双发约定好的传输和接收速率就是TCP窗口大小。

网络环境的数据交互同人类之间的对话还要复杂一些，它存在数据包乱序的现象。同一个来源发出来的不同数据包在「网际路由」上可能会走过不同的路径，最终达到同一个地方时，顺序就不一样了。操作系统的网络内核模块会负责对数据包进行排序，到用户层时顺序就已经完全一致了。

四次挥手

这一块呢，有些奇怪，没有理解地非常透彻，直接搬运原文（来自im即时通讯网收录，老钱原文）

TCP断开链接的过程和建立链接的过程比较类似，只不过中间的两部并不总是会合成一步走，所以它分成了4个动作，张三挥手(fin)——李四伤感地微笑(ack)——李四挥手(fin)——张三伤感地微笑(ack)。

之所以中间的两个动作没有合并，是因为tcp存在「半关闭」状态，也就是单向关闭。张三已经挥了手，可是人还没有走，只是不再说话，但是耳朵还是可以继续听，李四呢继续喊话。等待李四累了，也不再说话了，超张三挥了挥手，张三伤感地微笑了一下，才彻底结束了。

上面有一个非常特殊的状态time_wait，它是主动关闭的一方在回复完对方的挥手后进入的一个长期状态，这个状态标准的持续时间是4分钟，4分钟后才会进入到closed状态，释放套接字资源。不过在具体实现上这个时间是可以调整的。

它就好比主动分手方要承担的责任，是你提出的要分手，你得付出代价。这个后果就是持续4分钟的time_wait状态，不能释放套接字资源(端口)，就好比守寡期，这段时间内套接字资源(端口)不得回收利用。

它的作用是重传最后一个ack报文，确保对方可以收到。因为如果对方没有收到ack的话，会重传fin报文，处于time_wait状态的套接字会立即向对方重发ack报文。

同时在这段时间内，该链接在对话期间于网际路由上产生的残留报文(因为路径过于崎岖，数据报文走的时间太长，重传的报文都收到了，原始报文还在路上)传过来时，都会被立即丢弃掉。4分钟的时间足以使得这些残留报文彻底消逝。不然当新的端口被重复利用时，这些残留报文可能会干扰新的链接。

4分钟就是2个MSL，每个MSL是2分钟。MSL就是maximium segment lifetime——最长报文寿命。这个时间是由官方RFC协议规定的。至于为什么是2个MSL而不是1个MSL，我还没有看到一个非常满意的解释。

四次挥手也并不总是四次挥手，中间的两个动作有时候是可以合并一起进行的，这个时候就成了三次挥手，主动关闭方就会从fin_wait_1状态直接进入到time_wait状态，跳过了fin_wait_2状态。