一、传输层概述
1. 进程间的通信
传输层为相互通信的应用进程提供逻辑通信，通信的真正端点并不是主机而是主机中的进程。
传输层有一个重要的功能：复用和分用。
- 复用：发送方不同的应用进程都可以使用同一个运输层协议传送数据。
- 分用：接收方的传输层在剥去报文的首部后能够把这些数据正确交付目的应用进程。
2. 主要协议
-
用户数据报协议 UDP：无连接的，尽最大可能交付，面向报文（对于应用程序传下来的报文不合并也不拆分，只是添加 UDP 首部），没有拥塞控制，支持一对一、一对多、多对一和多对多的交互通信，首部开销小，只有 8 个字节。
-
传输控制协议 TCP：面向连接的，提供可靠交付，有流量控制，拥塞控制，提供全双工通信，面向字节流（把应用层传下来的报文看成字节流，把字节流组织成大小不等的数据块），每一条 TCP 连接只能是点对点的（一对一）。
二、UDP
1. 首部格式
UDP 有两个字段：数据字段和首部字段，首部字段只有 8 个字节。
- 源端口：原端口号，在需要对方回信时选用，不需要时可用全 0。
- 目的端口：目的端口号，在终点交付报文时必须使用。
- 长度：UDP 用户数据报的长度，最小值是 8 （仅有首部）。
- 检验和：检测 UDP 用户数据报在传输中是否有错，有错就丢弃。
2. 检验和
UDP 的检验和是把首部和数据部分一起都检验，计算检验和时，要在 UDP 用户数据报之前增加 12 个字节的伪首部。
先把 全零 放入检验和字段，再把伪首部以及 UDP 用户数据报看成是由许多 16 位的字串接起来的，按二进制反码计算出这些 16 位字的和。
三、TCP
1. 首部格式
TCP 首部的最小长度是 20 字节。
- 序号：用于对字节流进行编号，例如，一报文段的序号字段值是 301，携带的数据共有 100 字节，下一个报文段的序号就应当从 401 开始。
- 确认号：期望收到对方下一个报文段的第一个数据字节的序号。
- 数据偏移：数据部分距离报文段起始处的偏移量，实际上指的是首部的长度。
- 确认 ACK：当 ACK = 1 时确认号字段有效，否则无效。TCP 规定，在连接建立后所有传送的报文段都必须把 ACK 置 1。
- 同步 SYN：当 SYN = 1 时表示这是一个连接请求或连接接受报文。当 SYN = 1，ACK = 0 时，表明这是一个连接请求报文；若对方同意建立连接，则相应报文中 SYN = 1，ACK = 1。
- 终止 FIN ：用来释放一个连接，当 FIN=1 时，表示此报文段的发送方的数据已发送完毕，并要求释放连接。
- 窗口 ：窗口值作为接收方让发送方设置其发送窗口的依据。
2. 套接字 socket
TCP 把连接作为最基本的抽象，每一条 TCP 连接唯一地被通信两端的两个端点（即两个套接字）所确定。
套接字 socket = (IP 地址 : 端口号)
TCP 连接 = {socket1, socket2} = {(IP1 : port1), (IP2 : port2)}
四、TCP 连接管理
1. 三次握手 - 建立连接
TCP 协议提供可靠的连接服务，采用三次握手建立一个连接。
- 建立连接时，客户端发送 SYN 包到服务器，随机选择一个初始序号 x，并进入 SYN_SENT 状态，等待服务器确认；
- 服务器收到 SYN 包，必须确认客户的 SYN (ack = x + 1)，同时自己也发送一个 SYN 包 (seq = y)，即 SYN + ACK 包，此时服务器进入 SYN_RECV 状态；
- 客户端收到服务器的 SYN + ACK 包，向服务器发送确认包 ACK (ack = y + 1)，此包发送完毕，客户端和服务器进入 ESTABLISHED 状态，完成三次握手。
建立连接为什么是三次？可以改成二次握手么？
采用三次握手是为了防止失效的连接请求报文段突然又传送到服务器，因而产生错误。
假定出现一种异常情况，即 A 发出一个连接请求报文在某些网络结点长时间滞留了，以致延误到连接释放以后的某个时间才到达 B。本来这是一个早已失效的报文段。但 B 收到此失效的连接请求后，就误认为是 A 又发出一次新的连接请求。于是就向 A 发出确认报文段，同意建立连接。假设不采用握手，那么只要 B 发出确认，新的连接就建立了。
由于现在 A 并没有发出建立连接的请求，因此不会理睬 B 的确认，也不会向 B 发送数据。但 B 却以为新的运输连接已经建立了，并一直等待 A 发来数据。B 的许多资源就这样白白浪费了。
采用三报文握手的方法，在上述异常下，A 不会向 B 的确认发出确认，B 收不到确认，就知道 A 并没有要求建立连接。
2. 四次挥手 - 释放连接
- Clinet 发送一个 FIN，用来关闭 Clinet 到 Server 的数据传送，Client 进入 FIN_WAIT_1 状态；
- Server 收到 FIN 后，发送一个 ACK 给 Client，确认序号为收到序号 + 1，Server 进入 CLOSE_WAIT 状态，发送还未传送完毕的数据；
- Server 发送一个 FIN，用来关闭 Server 到 Client 的数据传送，Server 进入 LAST_ACK 状态；
- Client 收到 FIN 后，Client 进入 TIME_WAIT 状态接着发送一个 ACK 给 Server，确认序号为收到序号 + 1，Server 进入 CLOSED 状态，完成四次挥手。
为什么客户端在 TIME_WAIT 状态需要等待 2MSL 的时间？
- 确保最后一个确认报文能够到达。如果 服务器 没收到 客户端 发送来的确认报文，那么就会重新发送连接释放请求报文，客户端 等待一段时间就是为了处理这种情况的发生。
- MSL 为最长报文段寿命，等待一段时间是为了让本连接持续时间内所产生的所有报文都从网络中消失，使得下一个新的连接不会出现旧的连接请求报文。
五、可靠传输
1. 超时重传
TCP 使用超时重传来实现可靠传输：如果一个已经发送的报文段在超时时间内没有收到确认，那么就重传这个报文。
2. 滑动窗口
窗口是缓存的一部分，用来暂时存放字节流。发送方和接收方各有一个窗口，接收方通过 TCP 报文段中的窗口字段告诉发送方自己的窗口大小，发送方根据这个值和其它信息设置自己的窗口大小。
发送窗口内的字节都允许被发送，接收窗口内的字节都允许被接收。如果发送窗口左部的字节已经发送并且收到了确认，那么就将发送窗口向右滑动一定距离，直到左部第一个字节不是已发送并且已确认的状态；接收窗口的滑动类似，接收窗口左部字节已经发送确认并交付主机，就向右滑动接收窗口。
接收窗口只会对窗口内最后一个按序到达的字节进行确认，例如接收窗口已经收到的字节为 {31, 34, 35}，其中 {31} 按序到达，而 {34, 35} 就不是，因此只对字节 31 进行确认。发送方得到一个字节的确认之后，就知道这个字节之前的所有字节都已经被接收。
3. 流量控制
让发送方的发送速率不要太快，要让接收方来得及接收。
利用 滑动窗口机制 在 TCP 连接上实现对发送方的流量控制。发送方的发送窗口不能超过接收方给出的接收窗口的数值。将窗口字段设置为 0，则发送方不能发送数据。
4. 拥塞控制
若果网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏，这种情况被称为拥塞。
如果网络出现拥塞，分组将会丢失，此时发送方会继续重传，从而导致网络拥塞程度更高。因此当出现拥塞时，应当控制发送方的速率。这一点和流量控制很像，但是出发点不同。流量控制是为了让接收方能来得及接收，而拥塞控制是为了降低整个网络的拥塞程度。
TCP 主要通过四个算法来进行拥塞控制：慢开始、拥塞避免、快重传、快恢复。
发送方需要维护一个叫做拥塞窗口（cwnd）的状态变量，注意拥塞窗口与发送方窗口的区别：拥塞窗口只是一个状态变量，实际决定发送方能发送多少数据的是发送方窗口。
慢开始与拥塞避免
发送的最初执行慢开始，令 cwnd = 1，发送方只能发送 1 个报文段；当收到确认后，将 cwnd 加倍，因此之后发送方能够发送的报文段数量为：2、4、8 …
注意到慢开始每个轮次都将 cwnd 加倍，这样会让 cwnd 增长速度非常快，从而使得发送方发送的速度增长速度过快，网络拥塞的可能性也就更高。设置一个慢开始门限 ssthresh，当 cwnd >= ssthresh 时，进入拥塞避免，每个轮次只将 cwnd 加 1。
如果出现了超时，则令 ssthresh = cwnd / 2，然后重新执行慢开始。
快重传与快恢复
在接收方，要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。例如已经接收到 M1 和 M2，此时收到 M4，应当发送对 M2 的确认。
在发送方，如果收到三个重复确认，那么可以知道下一个报文段丢失，此时执行快重传，立即重传下一个报文段。例如收到三个 M2，则 M3 丢失，立即重传 M3。
在这种情况下，只是丢失个别报文段，而不是网络拥塞。因此执行快恢复，令 ssthresh = cwnd / 2 ，cwnd = ssthresh，注意到此时直接进入拥塞避免。
慢开始和快恢复的快慢指的是 cwnd 的设定值，而不是 cwnd 的增长速率。慢开始 cwnd 设定为 1，而快恢复 cwnd 设定为 ssthresh。
六、面试题自检
- 说一下 TCP 三次握手？为什么是三次，两次可以吗？
- 说一下TCP 四次挥手？为什么会有 CLOSE_WAIT 状态？为什么有 TIME_WAIT 状态？
- TCP 和 UDP 的区别？
- TCP 是如何保证可靠传输的？
- 说一下 TCP 的拥塞控制？