在网络层之上，是传输层。由于网络层提供的尽力而为的服务，不保证数据传输的准确性，于是传输层提供了保证准确性的 TCP 协议。TCP 协议提供的是<b>面向字节流</b>和<b>面向连接</b>的服务，<b>面向字节流</b>指的是：应用层提供的数据是一串无结构的字节流，传输层可以对数据进行分段，数据没有长度限制；而<b>面向连接</b>指的是：发送端传输层和接收端传输层之间开始数据传输前有协调过程，且提供的是按序、可靠的传输服务。传输层的另外一个协议是 UDP 协议，UDP 协议提供的是<b>面向报文</b>和<b>面向无连接</b>的服务，<b>面向报文</b>指的是：应用层提供的一系列报文，传输层不对报文进行分割和拼装，报文长度受到限制；<b>面向无连接</b>指的是：发送端传输层和接收端传输层之间开始数据传输前没有协调过程，且提供的是不按序、不可靠的传输服务。
端口号
IP 地址是全网的统一编址，标识着互联网中不同的终端，具有全球意义，而端口号是在终端中统一编址，标识终端中不同的应用进程，具有本地意义。我们把 32 位 IP 地址加上 16 位的端口号成为 48 位<b>插口</b>。
端口号是由<b>互联网数字分配机构（The Internet Assigned Numbers Authority, IANA）</b>分配的，分为著名端口号、注册端口号和临时端口号三种类型。著名端口号的范围是 0 ~ 1023，由 IANA 统一分配，如 UDP 著名端口号： 53 用于 DNS 服务、67 / 68 用于 DHCP 服务，TCP 著名端口号：20 用于 FTP 数据连接服务，21 用于 FTP 控制连接服务等等；注册端口号的范围是 1024 ~ 49151，由用户向 IANA 申请注册；最后的临时端口号 49152 ~ 65535 用于本地分配。
UDP
UDP 提供的服务比较简单，因此 UDP 首部也比较简单，如下：
- 源端口和目的端口：16 位。用于标识发送进程和接收进程
- 长度：16 位。以字节为单位给出 UDP 报文长度
- 检验和：16 位。用于对包括数据的 UDP 报文进行检错
TCP
TCP 提供的是按序、可靠的传输服务，需要注意的是，TCP 协议没有对传输速率作任何保证。
- 源端口和目的端口：16 位。用于标识发送进程和接收进程
- 序号： 32 位。TCP 连接中传送的字节流中的每一个字节都编上一个序号。序号字段的值指的是本报文段所发送的数据的第一个字节的序号
- 检验和：16 位。用于对包括数据的TCP报文进行检错
- 确认序号：32 位。指的是期望收到对方的下一个报文段的数据的第一个字节的序号。所有序号小于确认序号的报文都被正确接收了
- TCP首部长度：4 位。以 4 个字节为单位，TCP 首部的
最大长度为15×4=60字节，也称为数据偏移字段 - 保留：6 位。保留为今后使用，但目前应置为 0
- 紧急位（URG） ：当 URG = 1 时，告诉系统此报文段中有紧急数据， 应尽快传送（相当于高优先级的数据）
- 确认位（ACK）：只有当 ACK = 1 时，确认序号字段才有效
- 推送位（PSH）：当接收到 PSH = 1 的 TCP 报文时，就尽快地交付接收应用进程
- 复位（RST）：当 RST = 1 时，表明 TCP 连接中出现严重差错（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立连接
- 同步位（SYN）：如果SYN = 1、ACK = 0，意味着是连接请求 TCP 报文；如果 SYN = 1、ACK = 1，意味着是同意建立连接的响应 TCP 报文。 即如果 SYN = 1，则处于 TCP 连接建立过程。
- 终止位（FIN）：当 FIN = 1，表明发送端已完成数据传输，请求释放 TCP 连接
- 窗口：16 位。发送端允许发送的数据的字节数的上限，发送端实际发送的数据的字节数还受网络状态制约
- 检验和：16位。用于对包括数据的 TCP 报文进行检错
- 紧急指针： 16 位。指出在本报文段中紧急数据共有多少个字节（紧急数据放在本报文段数据的最前面）
- 可选项：长度可变，最多 40 字节。目前TCP的增强功能都通过可选项实现
建立和释放连接的过程
发送窗口
发送窗口指的是发送端允许发送的序号范围，假设接收窗口大小为 WS，最后一次收到的确认序号为 A，则发送窗口是 A + 1 ~ A + 1 + WS
接收窗口
接收窗口指的是接收端的可用窗口长度，假设接收端的缓冲区长度为 L，已经确认但仍未向应用层提交的字节数为 X，则接收窗口是 L - X
差错控制机制
差错控制机制的本质是出错重传，一般来说，以下情况视为出错：
- TCP 报文在传输过程中丢失
- TCP 报文内容在传输过程中出错，被接收端丢弃
- 由于错序使得 TCP 报文中字节的序号不属于接收窗口，被接收端丢弃
发送端确定某个 TCP 报文出错的依据有两个：一是发送端长时间未收到确认应答，重传定时器溢出；二是连续接收到 4 个确认序号相同的确认应答
对于偶而丢失 TCP 报文的情况：
- 发送端在发送窗口内按序发送
- 当接收到连续4个确认序号相同的应答帧，重传数据
- 定时器溢出，重传数据
- 一般情况下重传定时器溢出时间大于接收到4个确认序号相同的确认应答时间
对于丢失大量 TCP 报文的情况：
必然导致重传定时器溢出
拥塞控制机制
<b>拥塞</b>是指分组交换设备中经过某条链路的流量超出链路的传输能力，使得输出队列中等待输出的报文越来越多，以至于发生输出队列溢出，报文丢弃的情况
<b>拥塞窗口（CWND）</b>：网络能承载的发送端至接收端的流量
因此，发送端的实际窗口值 = MIN[CWND, 接收端公告的窗口字段值]
在 TCP 连接刚建立时，发送端采用<b>慢启动</b>的方式探测网络状态，具体过程如下：
- TCP 连接刚建立时，发送 1 个 TCP 报文
- 收到确认应答后，发送 2 个 TCP 报文
- 往后依次成倍增大，直到达到接收端公告的窗口值或探测到报文丢失
如果发送端重传定时器溢出，说明发生了较为严重的拥堵，此时调整方案如下：
- 重新开始慢启动，将当前拥塞窗口的一半作为慢启动阈值
- 一旦超过该阈值，流量线性增长，逐步接近拥塞点
如果连续收到多个重复确认应答，说明拥堵不是很严重，采用如下调整方案：
- 流量下降到当前拥塞窗口的一半
- 流量线性增长
参考资料：
传输层的服务特性
端口号
TCP 的特点与格式
建立和释放连接过程
TCP 差错控制机制
TCP 拥塞控制机制
