三次握手
- TCP 建立连接的过程叫做握手。
- 握手需要在客户和服务器之间交换三个TCP报文段，称之为三报文握手;
- 采用三报文握手主要是为了防止已失效的连接请求报文段突然又传送到了，因而产生错误。
为什么需要三次握手
TCP 建立连接时通过三次握手可以有效地避免历史错误连接的建立，减少通信双方不必要的资源消耗，三次握手能够帮助通信双方获取初始化序列号，它们能够保证数据包传输的不重不丢，还能保证它们的传输顺序，不会因为网络传输的问题发生混乱。
- 两次握手：无法避免历史错误连接的初始化，浪费接收方的资源；
- 四次握手：TCP 协议的设计可以让我们同时传递
ACK和SYN两个控制信息，减少了通信次数，所以不需要使用更多的通信次数传输相同的信息。
四次挥手
为什么需要四次挥手
因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，"你发的FIN报文我收到了"。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四次挥手。
TCP和UDP的区别
TCP：
- 面向连接的协议，提供面向连接服务；
- 面向报文，其传送的运输协议数据单元TPDU是 TCP报文；
- 支持点对点单播，不支持多播、广播；
- 可靠传输，使用流量控制和拥塞控制；
- 复杂，用于大多数应用。如：万维网、电子邮件、文件传输等。
UDP：
- 无连接的协议，提供无连接服务；
- 面向字节流，其传送的运输协议数据单元TPDU是 UDP报文或用户数据报；
- 支持单播、多播、广播；
- 不可靠传输，不使用流量控制和拥塞控制；
- 简单，适用于很多应用。如：多媒体应用等。
TCP如何保证可靠传输
- 应用数据被分割成 TCP 认为最适合发送的数据块；
- TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层；
- 校验和：TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段；
- TCP 的接收端会丢弃重复的数据；
- 流量控制：TCP 连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议；（TCP 利用滑动窗口实现流量控制）
- 拥塞控制：当网络拥塞时，减少数据的发送；
- ARQ协议：也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组；
- 超时重传：当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。
TCP流量控制
TCP使用滑动窗口协议（连续ARQ协议）实现流量控制。滑动窗口协议既保证了分组无差错、有序接收，也实现了流量控制。主要的方式就是接收方返回的 ACK 中会包含自己的接收窗口的大小，并且利用大小来控制发送方的数据发送。发送窗口的大小不能超过接受窗口的大小，只有当发送方发送并收到确认之后，才能将发送窗口右移。发送窗口的上限为接受窗口和拥塞窗口中的较小值。接受窗口表明了接收方的接收能力，拥塞窗口表明了网络的传送能力。
TCP拥塞控制
慢开始
- 刚开始发送数据时，先把拥塞窗口cwnd（congestion window）设置为一个最大报文段MSS的数值，每收到一个新的确认报文之后，可以把拥塞窗口增加最多一个 SMSS 的数值。这样每经过一个传输轮次（或者说是每经过一个往返时间RTT），拥塞窗口的大小就会加倍。
拥塞避免
- 当拥塞窗口的大小达到慢开始门限(slow start threshold)时，开始执行拥塞避免算法，让拥塞窗口cwnd缓慢地增大，避免出现拥塞，每经过一个传输轮次，拥塞窗口加一，使其按线性规律缓慢增大。
快重传
- 发送方只要一连收到三个重复确认，就知道接收方确实没有收到报文段，因而应当立即进行重传（即快重传），这样就不会出现超时，发送方也不就会误认为出现了网络拥塞。使用快重传可以使整个网络的吞吐量提高约20%。
快恢复
- 当发送端收到连续三个重复的确认时，由于发送方现在认为网络很可能没有发生拥塞，因此现在不执行慢开始算法，而是执行快恢复算法FR (Fast Recovery)算法：
1.慢开始门限ssthresh=当前拥塞窗口cwnd / 2 ；
2.新拥塞窗口cwnd=慢开始门限ssthresh；
3.开始执行拥塞避免算法，使拥塞窗口缓慢地线性增大。
- 当发送端收到连续三个重复的确认时，由于发送方现在认为网络很可能没有发生拥塞，因此现在不执行慢开始算法，而是执行快恢复算法FR (Fast Recovery)算法：
