TCP协议小结

TCP是什么

TCP（Transission Control Protocol）是一个位于传输层，面向连接，可靠，基于字节流的传输协议。
传输层协议：根据OSI七层模型，传输层协议必然要基于一个网络层协议实现功能，TCP是基于IP协议实现，但众所周知IP协议是无连接不可靠的，仅仅负责将数据包发出，至于走哪条链路经过哪些路由，甚至接收方能否收到准确无误的数据都无法保证，因此真正落实了数据可靠性相关功能的是作为传输层协议的TCP。
面向连接：即点对点，同时这根所谓的连接通道有一个建立和关闭的动作。
可靠：TCP协议通过建立连接和关闭连接的特定方式（三握四挥），数据发送和接收方的ACK响应机制，TCP首部的序列号规避网络包乱序，来确保数据传输的可靠性；
基于字节流：理解为建立连接双方架接了一条管道，之后的数据有如水流一般源源不断地在双方之间传输，没有边界。

如何确定唯一的TCP连接

既然将TCP连接比喻为一条功能丰富的管道，那么确定的方式自然是通过管道的两个端点：源IP地址（IP首部16位字节表示），源端口（TCP首部16位字节表示），目的IP地址（IP首部16位字节表示），目的端口（TCP首部16位字节表示）。

TCP同UDP比较

与TCP不同，UDP（User Datagram Protocol）是无连接的，不可靠的一种传输层协议。通过几个方面区别不同：
首部：TCP首部包含了20个字节的固定长度以及后续长度可变的0~40个字节的选项；UDP首部异常简单，为长度固定的8个字节；
是否建立连接：TCP有一个明确的连接建立和连接关闭过程，而UDP即时传送数据包，没有连接相关的概念；
是否可靠：TCP通过连接，通过ACK机制保证数据传输可靠性，UDP则不然，只在不可靠的IP协议基础上了封装了端口，首部长度和校验和等简单信息，即进行传输，是不可靠的；
是否有拥塞控制：TCP首部通过窗口大小字段进行流量控制；UDP没有相关功能；
是否有首部长度字段：TCP首部长度可变，因此有4个字节表示首部长度（15*4=60B）；UDP首部长度固定（2行8B），无需设定字段表示首部长度，但有一个包长度字段表示首部+数据的长度；

TCP连接建立与关闭

在谈TCP三握四挥之前，我先说说个人的一些理解。在谈到tcp建立的所谓连接时，我更多地会使用一个不那么恰当的比喻——管道，而且是一个双工管道，即不论连接的初始倡议由哪方提出，最终建立连接的节点双方均可向对方传输数据。基于这一点，我在理解TCP连接建立或是关闭的过程时，会特别把连接拆分成两部分，即A→B的连接和B→A的连接。下面开始讨论：

三次握手的过程：
一握：客户端向服务端发送一个生成了明确序列号，syn=1并且不带应用层数据的报文，示意建立连接；（这一块儿是A尝试建立A→B）
二握：服务端收到客户端请求，返回一个生成明确序列号，syn=1，ack=1，ack numbers为（客户端序列号+1）；（这一握有双重含义，B向A回复ACK表示完善落实了A→B的建立，同时B向A传输自身的序列号以及syn，是尝试建立B→A）；
三握：客户端继而向服务度传送ack=1以及ack numbers为（服务端序列号+1）；（这一握是A回应了B→A连接的建立；此外与前二握不同，这第三握，客户端已经可以连带着将应用层的数据传输给服务端，这是因为经过前两握，此时A→B的单方向连接已然建立成功）。

为啥不是二握或者四握：
二握：通过上述介绍，应该能够理解，二握只能建立A→B，而不能完善B→A的连接，显然不足以支撑一个完整连接的建立；此外，还有可能因为网络拥塞的原因，出现历史连接干扰的情况，因此二握并不可取；
四握：其实建立完整的A→B（syn，ack），B→A（syn，ack）应该是分为四个步骤，只是大家会发现在其中B给A的syn和ack可以合二为一，因此四握变三握，能省一步则省一步，何乐而不为？

下面谈谈TCP关闭连接的分手四挥：
采取与上述类似的思路，TCP关闭连接同样分为A→B和B→A两部分连接的关闭；
一挥：客户端向服务端发送FIN报文，示意再无数据传输，可以关闭连接，自此进入FIN_WAIT_1状态；（尝试A→B关闭）
二挥：服务端向客户端回复关于FIN报文的ACK，由此进入CLOSE_WAIT状态，但此时服务端手头可能还有数据传输工作，比如还有数据要回传给客户端，因此B→A的关闭还不能马上展开，因此这一挥仅仅是回复ACK，而不能将B→A方向的FIN同时发出，这就是三握和四挥存在数量差别的根本原因；同时，客户端收到这一ACK后，切换至FIN_WAIT_2状态；
三挥：经过一段缓冲时间，服务端终于处理完手头工作，向客户端发出关于B→A方向的FIN报文，示意关闭连接，由此进入LAST_ACK状态；
四挥：客户端回复B→A的ACK，进入TIME_WAIT状态，待服务端收到这第四次挥手后，便进入CLOSE状态（真的分手了），而客户端仍需候时2MSL，才进入CLOSE。

TIME_WAIT状态的意义？以及等待2MSL的依据？
先作个名词解释，所谓MSL（Maximum Segent Lifetime）即报文最大生存时间，超过这一时间的报文会被弃置；那么两倍的MSL正好是数据一来一回（A→B无限趋近MSL，B→A同样无限趋近MSL）最多能生存的时间上限。
这里通过举反例来说明问题。
试想，假如客户端回复了来自服务端FIN的ACK后就进入关闭，而没有一个所谓的TIME_WAIT的阶段会有何后果？——如果这个ACK丢失了，服务端就不能正常关闭B→A，它不断重发FIN向客户端苦苦哀求，但客户端却闭门不答（已然关闭），这样未免太绝情了。
第二个问题，试想，如果将TIME_WAIT时间设置短于2MSL，就以1倍MSL为例好了，此时由于网络拥堵，有一个旧的数据仍在网路中徘徊，它从A→B花费了接近MSL，从B到A同样花费了接近MSL的时间，等到达A时，A已经经过了TIME_WAIT，进入关闭，并且又建立了一个和C的连接，那么A就会错把这份旧数据当成是来自C的新数据，从而导致数据的错乱。

结语

至此，笔记结束。
本人计算机大数据方向自学路上小白一名，水平实在有限，这一笔记除了供个人理解和复习之用外，分享的初衷也是希望从他人观点中学习长处弥补自身不足。如有表达失准或者概念有误还请见谅，欢迎各位大佬批评指正。