TCP详解

前言

对于TCP的了解，大部分都是从搜索引擎中得到的。

我们可能知道TCP需要三次握手建立连接，四次挥手释放连接，也可能知道TCP是一个可靠的传输协议等等，那么，通过百度简单的了解到TCP之后，你们有没有一些疑问？

提出问题

记得当时我脑中有几个问题，在解决这几个问题的同时，也了解到了更加深层次的一些东西，给大家分享一下：
1.TCP协议和TCP/IP协议到底分别指什么？
2.TCP建立连接是不是一定要三次握手，TCP断开连接是不是一定要四次挥手？
3.TCP是如何实现可靠传输的？

解决问题

1.TCP协议和TCP/IP协议到底分别指什么？

像这种英文简写的专业名词，还是需要了解一下它的全称，这样更加能够理解。
TCP，Transmission Control Protocol，传输控制协议。
它是面向连接的运输层协议。所以在使用TCP进行数据传输之前，必须要建立连接，也就是经常说到的三次握手；与之对应的，数据传输完之后，需要断开连接，也就是四次挥手。
TCP/IP协议(Transmission Control Protocol/Internet Protocol)叫做传输控制/网际协议，根据翻译，好像就是多了一个网际协议，其实不是这样的。它是指能够在多个不同网络间实现信息传输的协议簇。TCP/IP协议不仅仅指的是TCP 和IP两个协议，而是指一个由FTP、SMTP、TCP、UDP、IP等协议构成的协议簇， 只是因为在TCP/IP协议中TCP协议和IP协议最具代表性，所以被称为TCP/IP协议。
可以这样通俗理解：我叫FTP，我有一个哥哥叫做TCP，一个姐姐叫做IP，他们都是985的大学生，但是我平平常常的一个人，不被人注意，邻居家聊天的时候只会说TCP/IP家里怎么怎么，不会说FTP家里怎么怎么。而我们一大家都是为了让网络之间更好通信的协议。只是由于TCP/IP比较让众人知道而已。

2.TCP建立连接是不是一定要三次握手，TCP断开连接是不是一定要四次挥手？

先来看三次握手流程图：

SYN:标志位，建立连接使用，SYN=1，ACK=0(通常省略) 代表主动建立连接，被请求方同意请求，就要回复SYN=1，ACK=1
seq:序号，因为tcp连接请求报文占一个单位长度，所以第二次发送报文会+1
ACK:标志位，在确认报文中使用，TCP只认为ACK=1有效
还是举一个例子，我是客户端，年纪很大耳朵听不清的奶奶是服务端。我想去看望奶奶，然后我首先需要电话联系一下，要不然奶奶出去打麻将了。于是拨通了电话：“奶奶，我下午想去看看您，您有空吗？不对不对，是明天下午”。（第一次握手，网络环境不会像理想状态那么好，可能会有历史请求）因为奶奶耳朵不是很好，说了几次终于听懂了，然后回应：“你明天下午要过来吗？”（第二次握手，收到请求连接报文之后，需要确认一下，万一是自己没听清呢？）然后我回复说：“是的，我是今天下午去看看您。”又说了几次之后奶奶确定了我下午过去（第三次握手）。
假如我没有和奶奶再一次确认(第三次握手)，可能是因为我突然有事没有回应她，就取消了这个计划，奶奶就会一直等。也可能奶奶听错了，听成今天下午，但是我没有给她确认，我明天下午去了，她不在，她今天等一下午，却没有等到。

例子举完不知道有没有方便大家理解?
官方解释如下：

第三次握手主要是防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。
所谓“已失效的连接请求报文段”是这样产生的。正常情况，客户端发出连接请求，
但因连接请求报文丢失而未收到确认。于是客户端再重传一次连接请求，后来收到了确认，建
立了连接，数据传输完毕后，就释放了连接。客户端发送了两次连接请求报文段，其中第一个丢失，第二个到达服务端，没有“已失效的连接请求报文段”。
假定出现了一种异常情况，客户端发送的第一个连接请求报文段未丢失，而是再某些网络节点长时间滞留，以致延误到连接连接释放以后的某个时间才到达服务端，本来这是一个早以失效的报文段。但服务端收到此失效的连接请求报文段后，就误认为是客户端又重新发起了一次连接请求，于是又向客户端发送确认报文段，同意建立连接。若无第三次握手，只要服务端发出确认，新的连接就建立了。但是客户端又没有发出建立连接的请求，因此不会理睬服务端的确认，也不会向服务端发送数据。但服务端还在一直等待客户端发来数据，服务端的很多资源就这样被浪费了。

我们再来看四次挥手释放连接：

其实经过对第三次握手的解析，我们能很快想到，第四次挥手的作用与其基本一致，就是为了避免因“已失效的连接请求报文段”产生的错误。但是，在第四次挥手完，在状态TIME-WAIT需要等待2MS(Maximum Segment Lifetime，最长报文段寿命)L的时间，这个是为什么呢？

有两个理由：
第一：客户端最后一个应答报文段可能会丢失，若服务器没有收到该报文段，就会超时重传，而客户端在等待的2MSL时间内可以收到重传的报文，然后又可以重新发送一条应答报文，再让定时器重新恢复到2MSL。若不等待2MSL时间，服务端就可能收不到最后一条应答报文，就无法按照正常步骤进入CLOSED状态（服务端收到最后一条应答报文就释放连接）。
第二：为了防止“已失效的报文段”出现，等待2MSL时间后，就可以使得本连接所有的报文段都从网络中消失，下一个新的连接就不会出现旧的报文段了。

3.TCP是如何实现可靠传输的？

首先，什么是可靠传输？通过TCP连接传送的数据，无差错、不丢失、不重复，且按序到达。
如何才能做到呢？

滑动窗口

假设数据传输只在一个方向进行，A发送数据，B给出确认。
TCP滑动窗口是以字节为单位，我们将他们按顺序排列，红色代表已经发送成功的数据，蓝色表示正在发送的数据，黑色表示未发送的数据。蓝色的长度先不考虑。可以很清楚的看出，数据是按照顺序排列，连续的一段一段，这样就可以在理想状态下保证传输的可靠性。滑动窗口在A B双方都有，一个发送一个接收。
假设初始状态如下：

…	$56$	$57$	$58$	$59$	$60$	$61$	$62$	$63$	$64$	$65$	66	67	68	69	…

A正在对B发送58~65这一段数据，B准备接受，假设此刻收到了58，59两段数据，还记得我们之前说的seq和收到回复吗？B本地处理好这两段消息之后，需要回复一个序号，60，因为已经收到58和59，期望下一个收到的数据是60。A收到B的回复，开始处理滑动窗户，如下：

…	$56$	$57$	$58$	$59$	$60$	$61$	$62$	$63$	$64$	$65$	$66$	$67$	68	69	…

A在没有收到B的期望序号（60）之前，58，59这两段数据都需要存在本地，如果环境恶劣，可能要重新发送。收到期望序号之后，将滑动窗口右移两个单位，开始发哦那个66，67段数据。(为了便于解释，没有考虑滑动窗口大小改变的情况)

这就是理想状态的滑动窗口模型。
下面就是一场状态如何保证传输的可靠性：
1.数据不按顺序到达，B收到58~60 以及63~65两段数据，缺失61，62两段，这时候B一直在等待61，62这两段数据，由于TCP的超时重传策略，A会一直发送61～67这段数据，对网络资源的利用不利。因此TCP要求接收方必须要累计确认功能，在合适的时候发送确认，让A不要一直发送已经接收到的数据。待到所缺的数据收到之后，再统一交付给上层的应用进程。
2.在理想状态下，A发送多少，B接收多少，但如果A发送的数据较多，B没有那么多资源来接受数据怎么办？
TCP为了解决这个问题，有一种流量控制策略，所谓流量控制，就是让发送方的发送速率不要太快，要让接收方来得及接收。
在A向B建立连接的时候，B需要告诉A他的接收窗口有多大，rwnd=400，这时候A就要控制自己滑动窗口的大小。在发送过程中，可能B的资源紧缺，由400到200再到100最后到0，这个时候，A就不应该发送数据了，需要等待B告诉A有资源可以处理数据，可以慢慢加大滑动窗口变成100或者200。天有不测风云，B想加大滑动窗口，发送了rwnd=200的报文，想让A开始发送数据，这段报文遗失了。是不是A就一直不发送数据了呢？TCP解决了这个问题，为每一个连接设有一个持续计时器。只要TCP连接的一方收到对方的零窗口通知，就启动计时器，时间到了就发送一个探测报文询问，对方收到这个报文如果还是回复零，就不能发送数据，如果不是零，就要开始发送数据啦。网络再怎么不好，只要收到一条探测报文，就又可以发送数据啦。