保证可靠性的机制：
- 校验和
- 序列号
- 确认应答
- 超时重传
- 连接管理
- 流量控制
- 拥塞控制
提高性能机制：
- 滑动窗口
- 快速重传
- 延迟应答
- 捎带应带
定时器：
- 超时重传定时器
- 保活定时器
- TIME_WAIT定时器
基于TCP的应用协议：HTTP、HTTPS、SSH、Telnet、FTP、SMTP
校验和
目的是为了发现TCP首部和数据在发送端到接收端之间发生的任何改动。如果接收方检测到检验和有差错，则TCP段会被直接丢弃。
TCP计算校验和时，要加上一个12字节的伪首部。
序列号（Sequence Number）
去重，用来解决网络包乱序问题。
确认号（Acknowledgment Number）
确认应答
每组数据都会有一个序列号seq = x，如果收到数据会发送对应确认号ack = x + 1
用来解决不丢包的问题。
超时重传
主机没收到应答有两种情况：
- 数据根本没传过去就丢包了
- 数据再返回来的时候丢包了
Linux中以500ms为一个单位重传，下次2 * 500ms、 3 * 500ms依次地推，累计一定次数就判断网络异常，强制关闭连接。
流量控制
如果发送端发送数据太快，接收端来不及接收，可能会丢失数据。所以流量控制是让发送端不要发送太快，要让接收端来得及接收。
是通过大小可变的滑动窗口实现的。
-
滑动窗口实现机制
CP是双工的协议，会话的双方都可以同时接收和发送数据。TCP会话的双方都各自维护一个发送窗口和一个接收窗口。各自的接收窗口大小取决于应用、系统、硬件的限制，各自的发送窗口则要求取决于对端通告的接收窗口，要求相同。 -
滑动窗口的功能
保证数据的可靠传递（未确认的数据必须被发送方缓存起来，确认的数据将会移除缓冲区）
保证数据的有序传输（乱序的数据必须被接收方缓存起来）
提供End-to-End的流控机制（发送方发送太快就必须阻塞等待） -
对比滑动窗口和拥塞窗口
滑动窗口是控制接收以及同步数据范围的，通知发送端目前接收的数据范围，用于流量控制，接收端使用。
拥塞窗口是控制发送速率的，避免发的过多，发送端使用。因为tcp是全双工，所以两边都有滑动窗口。
拥塞窗口控制sender向connection传输数据的速率，使这个速率为网络拥堵状况的函数。
TCP拥塞控制
提高网络利用率，降低丢包率，并保证网络资源对每条数据流的公平性。
发送端向网络一次连续写入的数据量，我们称为SWND（Send Window，发送窗口）
这些TCP报文段的最大长度（仅数据部分）称为SMSS（Sender Maximum Segment Size，发送者最大段大小），其值一般等于MSS。
引入一个称为拥塞窗口（Congestion Window,CWND）的状态变量.
慢启动
发送方维持一个拥塞窗口CWND的状态变量。它的大小取决于网络的拥塞程度，并且在动态的变化，发送方会让自己的发送窗口等于这个拥塞窗口。
1）只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。
2）出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数。
慢启动算法：因为不清楚网络状况，所以需要进行试探，将发送窗口逐渐增大，也就是逐渐增大拥塞窗口的数值。在刚开始发送的时候，先把拥塞窗口CWND设置为最大报文段MSS，每收到一个对新报文段的确认后，就把拥塞窗口最多增加一个MSS数值。这种逐步增大的方法可以使分组注入到网络的速率更加合理。拥塞避免
每经过一个往返时间RTT就使cwnd+1，线性增长。
发送端判断网络拥塞的依据：
①传送超时，即TCP重传定时器溢出
②收到重复的确认报文快重传
快重传算法要求接收方每收到一个失序的报文段后就立即发出重复确认，而不要等到自己发送数据时才进行捎带确认。发送方只要一连收到3个同样的确认报文就应当立即重传数据报，不必等待报文段的重传计时器到期。-
快恢复
把慢开始门限减半，“乘法减小”，将cwnd设置为新的慢开始门限值，继续执行拥塞避免算法，“加法增大”
拥塞控制 自动重传请求（Automatic Repeat-reQuest，ARQ）是OSI模型中数据链路层的错误纠正协议之一。它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧，它通常会重新发送。
三次握手的原因：
三次握手可以防止已经失效的连接请求报文突然又传输到服务器端导致的服务器资源浪费。例如，客户端先发送了一个SYN，但是由于网络阻塞，该SYN数据包在某个节点长期滞留。然后客户端又重传SYN数据包并正确建立TCP连接，然后传输完数据后关闭该连接。该连接释放后失效的SYN数据包才到达服务器端。在二次握手的前提下，服务器端会认为这是客户端发起的又一次请求，然后发送SYN ，并且在服务器端创建socket套接字，一直等待客户端发送数据。但是由于客户端并没有发起新的请求，所以会丢弃服务端的SYN 。此时服务器会一直等待客户端发送数据从而造成资源浪费。
四次挥手的原因：
由于连接的关闭控制权在应用层，所以被动关闭的一方在接收到FIN包时，TCP协议栈会直接发送一个ACK确认包，优先关闭一端的通信。然后通知应用层，由应用层决定什么时候发送FIN包。应用层可以使用系统调用函数read==0来判断对端是否关闭连接。
