三.TCP协议

TCP（Transmission Control Protocol）传输控制协议，是一种面向连接的、可靠的、基于字节流的传输层协议。

3.1 TCP协议段格式

3.2 TCP原理

（1）确认应答机制

 当发送端发送数据时，如上图，第一次发送数据时，数据包括一个报头和载荷，报头是序号，载荷里面是要发送的数据，当第一次发送时，接收方会接受应答，并返回确认序号向发送发索要下一次的数据，通过ack的确认序号，告诉发送方我已经接受到了哪些数据；

   在进行确认应答时，往往会伴随着后发先至的情况，就是先发送的数据后到，后发的数据先到的情况，这种情况也不用担心，对于TCP来说，它会帮我们整队，在TCP内部有个接受缓存区，这是内核中的一块内存空间，当出现乱套的情况，TCP会在这个缓存区按照序号帮我们对收到的消息进行整队；

（2）超时重传机制

在网络的传输过程中，难免会发生"丢包"的情况，那么TCP就会采取重传机制，以便于发送的数据包能准确无误的到达目的地，在丢包中，一般分为两种情况：

1.第一次发送方的数据直接丢了，接收方没到到，不会发送ack;

2.接受方收到数据了，返回的ack丢了；

这种情况下，就有一个问题，当接受方返回的ack丢了之后，发送方会继续发送，这样接受方就一直收到重复的数据，这可不是一个小问题，就拿手机支付来说，本来要付1元，结果因为丢包接受方没有返回响应，就会一直扣款！！！

当然，TCP的功能是很强大的，这点问题TCP也会采取相应的措施来帮我们解决，TCP会在接收缓存区根据收到的数据的序号，来帮助我们去重，这样就保证读到的数据不会是重复的！！！

在重传的过程中，也有可能发生丢包，丢失的包继续发生重传，但是每丢包一次，超时等待的时间就会变长，TCP会认为重传也没戏了，于是就干脆放弃了（这种就是严重的网络问题），连续多次重传，都无法得到ack，此时TCP就会尝试重置连接，如果连接失败，TCP就会关闭连接，放弃网络通信了；

面试题：TCP是如何实现可靠性的？

答：确认应答+超时重传

这里不能回答三次握手和四次挥手，这个是和连接相关的，而非可靠性；

（3）三次握手，四次挥手

TCP建立连接：三次握手

所谓握手，就是通信双方，进行一次网络交互，相当于客户端和服务器之间，通过三次交互，建立了关系；

过程：  

1、第一次握手：客户端给服务器发送一个 SYN（同步报文段） 报文。

 2、第二次握手：服务器收到 SYN 报文之后，会应答一个 SYN+ACK 报文。

 3、第三次握手：客户端收到 SYN+ACK 报文之后，会回应一个 ACK 报文。

 4、服务器收到 ACK 报文之后，三次握手建立完成。

三次握手的作用：

简单点来说，就是验证了客户端和服务器端各自的发送能力和接收能留是否正常；

注：三次握手都是由内核自动完成的，应用程序干预不了；

TCP断开连接： 四次挥手

过程：

1、第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于FIN_WAIT1状态。

2、第二次握手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 + 1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT状态。

3、第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。

4、第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 + 1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态

5、服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。

在三次握手中，返回的ACK和SYN是合并发送到客户端的，而四次挥手这里的FIN和ACK是不能合并发送的，这是因为三次握手中的ACK和SYN是同一时机触发的，都是由内核完成的，而四次挥手中的ACK和FIN是不同时机触发的，ACK是在内核完成的，而FIN是由应用程序代码控制的，是在调用socket的close方法的时候才会触发FIN；

（4）滑动窗口

上面说到当发送方发送一个数据段，都要给一个ACK确认应答，收到ACK之后才会发送下一个数据段，如果我们要发送大量的数据段时，那么发送方这边就需要一条一条的等待ACK，这样就浪费了大量时间，所以为了缩短等待时间，这里就需要批量发送，以提高发送的效率；

批量传输之后：

上述批量传输数据的过程，我们就叫做滑动窗口，批量发送并不是无厘头的去发，而是发送到一定程度，就等待ACK，我们把批量发送等待的数据，称为"窗口大小"；

（5）流量控制

上面说的滑动窗口，就是为了让传输的效率更高，窗口越大，批量发送的数据越多，整体的效率就提上去了，可是并不是越快越好，如果发送太快了，就很容易把接收缓冲区给塞满了，此时你再发送数据，就很容易丢包了，TCP也有这样的机制，通过流量的控制，来限制一下发送方的速度；

那么是如何进行控制的呢？？？

我们让ACK报文中携带一个"窗口大小"的字段，当ACK为1的时候，此时就是一个ACK报文，此时窗口大小字段就会生效，这里是拿接受缓冲区的剩余空间作为窗口大小；

当发送方发现对方满了之后，就会暂停发送，但是不会一直停止，每隔一段时间就会触发一个窗口探测报文，如果发现缓冲区有容量了，就会继续批量发送；

（6）拥塞控制

我们都知道，在客户端和服务器端之间往往都有很多的交换机和路由器，很明显，在传输路径上，中间任何一个设备出了问题，都会导致传输速率受到一定的影响；拥塞控制的作用就是衡量中间节点传输的能力；

拥塞控制是通过实验的方式，来找到一个合适的发送速率；开始的时候，按照一个小的速率发送，如果不丢包，就可以适当提高一下速率，如果丢包，就把速率调小；最后得到一个合适的发送速率，这实际上也是一个动态平衡的过程；

（7）延迟应答

上面说到接收方要返回ACK给发送方，这里的延迟应答就是不是立即发送ACK，而是等一会再发送，这样做的好处就是可以增大窗口的大小，因为延迟的这一小会儿，应用程序从接受缓存区里消费了一批数据了，同时也能让发送方的发送速率大一些；

TCP中延迟应答的两种方式：

• 数量限制：每隔N个包就应答一次；
• 时间限制：超过最大延迟时间就应答一次；