- 三次握手
- 四次挥手
- 可靠数据传输
- 流量控制
- 拥塞控制
三次握手
假设 A 为客户端，B 为服务器端。
- 首先 B 处于 LISTEN（监听）状态，等待客户的连接请求。
- A 向 B 发送连接请求报文，SYN=1，ACK=0，选择一个初始的序号 x。
- B 收到连接请求报文，如果同意建立连接，则向 A 发送连接确认报文，SYN=1，ACK=1，确认号为 x+1，同时也选择一个初始的序号 y。
- A 收到 B 的连接确认报文后，还要向 B 发出确认，确认号为 y+1，序号为 x+1。
- B 收到 A 的确认后，连接建立。
三次握手的原因
第三次握手是为了防止失效的连接请求到达服务器，让服务器错误打开连接。（避免重复连接）
客户端发送的连接请求如果在网络中滞留，那么就会隔很长一段时间才能收到服务器端发回的连接确认。客户端等待一个超时重传时间之后，就会重新请求连接。但是这个滞留的连接请求最后还是会到达服务器，如果不进行三次握手，那么服务器就会打开两个连接。如果有第三次握手，客户端会忽略服务器之后发送的对滞留连接请求的连接确认，不进行第三次握手，因此就不会再次打开连接。
RFC 793 Transmission Control Protocol
The principle reason for the three-way handshake is to prevent old duplicate connection initiations from causing confusion.
四次挥手
- A 发送连接释放报文，FIN=1。
- B 收到之后发出确认，此时 TCP 属于半关闭状态，B 能向 A 发送数据但是 A 不能向 B 发送数据。
- 当 B 不再需要连接时，发送连接释放报文，FIN=1。
- A 收到后发出确认，进入
TIME-WAIT状态，等待 2 MSL（最大报文存活时间）后释放连接。 - B 收到 A 的确认后释放连接。
四次挥手的原因
客户端发送了 FIN 连接释放报文之后，服务器收到了这个报文，就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据，传送完毕之后，服务器会发送 FIN 连接释放报文。
TIME_WAIT 状态
客户端接收到服务器端的 FIN 报文后进入此状态，此时并不是直接进入 CLOSED 状态，还需要等待一个时间计时器设置的时间 2MSL。这么做有两个理由：
- 确保最后一个确认报文能够到达。如果 B 没收到 A 发送来的确认报文，那么就会重新发送连接释放请求报文，A 等待一段时间就是为了处理这种情况的发生。
- 等待一段时间是为了让本连接持续时间内所产生的所有报文都从网络中消失，使得下一个新的连接不会出现旧的连接请求报文。
可靠数据传输
GBN
- 无缓存，只能按顺序接收分组，丢弃失序到达的分组
- 客户端累积发送 ACK
- 服务端收到 ACK=n ，表示** n 及之前的分组都接收成功**
- 如果超时，服务端重发所有 n 之后的分组
选择性重传
- 有缓冲区，可以缓存失序到达的分组
- 客户端逐个发送 ACK
- 服务端收到 ACK=n ，只表示客户端成功接收 n
- 如果超时，服务端只重发未收到 ACK 的分组
TCP
- 有缓冲区
- 客户端逐个发送 ACK
- 服务端收到 ACK=n ，表示客户端成功接收 n 之前的分组，并希望得到 n 及之后的分组
- 如果分组失序到达，客户端会缓存下来，然后发送冗余的 ACK = n ，n = 最小的未收到分组
- 如果超时或收到3次冗余的 ACK ，服务端会重发该分组（只有这一个分组）
TCP 滑动窗口
窗口是缓存的一部分，用来暂时存放字节流。发送方和接收方各有一个窗口，接收方通过 TCP 报文段中的窗口字段告诉发送方自己的窗口大小，发送方根据这个值和其它信息设置自己的窗口大小。
流量控制
流量控制是为了控制发送方发送速率，保证接收方来得及接收。
接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。
拥塞控制
- 流量控制：为了让接收方能来得及接收
- 拥塞控制：降低整个网络的拥塞程度
慢开始、拥塞避免、快重传、快恢复
