TCP到底是个啥，又为啥要握手，怎么握手几次都还要管，还只能固定握手呢?
哎呀，管好多啊，怎么肥事……
今天老杨给你重新梳理一遍，适合小白阅读。
1. 到底啥是TCP?
TCP的中文名叫做传输控制协议，是供已经连接因特网的计算机进行通信的通信协议。
计算机通信协议是对那些计算机必须遵守以便彼此通信的的规则的描述。TCP是互联网协议之一，也是主要的协议之一。
为啥?
因为它起源于最初的网络实施，在网络实施中，它对互联网协议起到了重要的补充作用。因此，整个套件通常被人称呼为TCP/IP。
TCP/IP 定义了电子设备(比如计算机)如何连入因特网，以及数据如何在它们之间传输的标准。
TCP主要是给在用IP网络通信的主机上运行的应用程序之间，提供一种可靠、有序且经过错误检查的八位字节流传递。万维网、文件传输、远程管理等主要互联网应用都依赖于TCP。
如果是那种不需要靠数据流服务的应用程序，就可以使用UDP(用户数据报协议)，它和TCP(传输控制协议)不同，前者强调降低延迟，后者强调可靠有序。
再说一点：TCP负责发现传输的问题，一有问题就发出信号，要求重新传输，直到所有数据安全正确地传输到目的地。而IP则是给因特网的每一台电脑规定一个地址。
有小白看到这里会问，那为啥计算机里一定要用到“xx协议”来传输信息呢?
因为单一的计算机并没有办法为人类发挥出最大的效用，只有把一台又一台的电脑连接起来，才能发挥出我们现在的功效。
这个连接不仅仅是单纯的网络连接，连起来也并不是简单的用电线把你的心和我的心串一串就可以解决的，那咋整?
我举个例子啊：
每个电脑都运行着不同的操作系统，来给你提供对应的服务，对吧?
那么，电脑基于不同的系统，它们对于同个信息的表达是完全不一样的，就想美国人说Good Morning，日本人说哦害哟，我说早啊大兄弟。
那语言不通，不能友好交流，就得想个办法，我们一起制定一个共通的规则来进行交流就行了嘛。
于是TCP/IP这样的协议就出现了。
计算机因为有了这类型的很多协议，就像人类学了多门外语一样，就终于可以和其他的计算机终端放飞自我的交流了。
2. TCP是啥时候出现的?
讲到TCP的诞生，就要回顾到1974年的那个夏天。
卡恩描述了一种使用网络节点间分组交换来共享资源的互联网协议，这就是TCP/IP的雏形。
1974年的那个冬天，卡恩和瑟夫的第一份tcp协议详细说明正式发表。
当时，他们做了一个试验，将信息包通过点对点的卫星网络，通过陆地电缆，再通过卫星网络，然后由地面传输，贯串欧洲和美国，经过各种电脑系统，全程9.4万公里，竟然没有丢失一个数据位!
这样的远距离可靠数据传输，证明了TCP/IP协议的成功。
1983年元旦，运行了比较长时间的、曾被人们习惯了的NCP被停止使用，从此以后，TCP/IP协议就成了因特网上所有主机间的共同协议，被作为一种必须遵守的规则被肯定和应用。
3. TCP的“三次握手”是什么意思?
介绍完了TCP到底是个啥，现在我们来讲讲，TCP这个“握手”是怎么个回事儿。
“握手”你可以理解为是TCP发功时所需要的仪式。
因为TCP常常用来发送大批量的数据，所以，为了提供可靠的的传送服务，TCP在发送数据之前，都需要用一种特定的顺序将数据包编号，并将这些数据包传送给目标，再确认消息。当对应的程序收到数据后，确认收到也需要用到TCP。
其实呢，三次握手就是为了对每次发送的数据量进行跟踪与协商，确保数据段的发送和接收同步，根据所接收到的数据量而确认数据发送、接收完毕后何时撤消联系，并建立虚连接。
那说了半天，到底握手是怎么握?
Step 1：TCP客户端准备发送一个syn段，用来指明客户打算链接的服务器端口以及isn(初始序号)。那么这个syn就被称为“报文段1”。
Step 2：那么，接下来，TCP服务端就会发回包含TCP服务端isn的syn段(即报文段2)作为回应。与此同时，TCP服务端会将确认序号设置为TCP客户端的isn+1，以对TCP客户端的s y n报文段进行确认。
Step 3：最后，TCP客户端也必须将确认的序号设置为TCP服务端的isn+1，作为对TCP服务端syn报文段的确认(即报文段3)这三个报文段就代表了连接的建立，而这个过程，就是TCP的三次握手(three-wayhandshake)。
4. TCP 为什么是三次握手
而不是两次或四次?
当有人谈论这个问题的时候，实则是在谈论：
当 TCP 服务端发送连接请求确认报文段之后，当 TCP 客户端收到这个报文，其实就算建立连接了，这个时候直接发送数据不就行了，为什么还要再次发送一个 TCP 普通确认报文段呢?这就这个问题的“真实翻译”。
我们从两个角度来解释一下：
(1) 过程论证
我们就把这个过程简单点说吧，别整的那么复杂。
我们假设一下，如果只握手两次，会是什么情况?
假设，客户端发送的第一个连接请求没有成功，那服务端就没办法收到这个报文段，对吧?
你如果给女朋友发微信没发出去，肯定会再发一次啊。那客户端也是这么想的啊，它准备重新发送连接+请求报文段，那，服务器这下可算收到这个报文段了，进入连接建立好了状态。
客户端这个时候，也进入了连接，建立状态，可以进行数据传输了对吧?
但是呢，第一次的请求报文发送失败了，它悄咪咪的开始了超时重传，但客户端和服务端都早已建立好了链接，这个时候就导致TCP的服务端白白等待，浪费大量资源。
所以两次握手性价比不高，稳定性不足。
再简单一点举个例子：小明给小红发消息，小红呢，收到小明消息后，回了个消息。
那么证明了一点，就是小明发送能力没有问题，小红接收能力也没有问题。
那如果小明不回了，那小明到底看到没看到消息就无法判断了，小红就会想：到底是啥原因他不回我消息啊?我做错了啥啊?
所以啊，小明如果在再发一次消息给小红的话，就确认了小明其实看到了小红的消息，也确认了小明的接收能力是正常的。
同时，小红也的确真的给小明发了消息，所以他才会回复，所以小红的发送能力也是正常的。
这就是TCP非要握手三次不可的原因。
(2) 他人论证
还不懂得的，可以围观一下谢希仁版的《计算机网络》，它全面介绍了计算机网络的发展和原理体系结构、物理层、数据链路层等内容，应该没有没看过的IT人吧?
书里说过，TCP的握手，其实是为了保证双方互相明确对方收发能力的最低值。两次太少，四次太多，三次正正好。
而且啊，其实不论握手多少次都不能确认一条信道是“可靠”的，但通过3次握手可以至少确认它是“可用”的，再往上加握手次数，其实就不过是提高“它是可用的”这个结论的可信程度。
而且严格来说，三次握手其实是双方各握手一次，然后各确认一次，其中，一次握手+确认是合并在一起的，这才是“三次”的由来。
