（以下内容全部出自上述课程）
目录
- 传输层提供的服务
-
- [1. 总结概述](#1. 总结概述)
- [2. 端口](#2. 端口)
-
- [2.1 传输层端口号的概念](#2.1 传输层端口号的概念)
- [2.2 进程、端口号、传输层协议之间的关系](#2.2 进程、端口号、传输层协议之间的关系)
- [2.3 熟知端口号](#2.3 熟知端口号)
- [2.4 端口号的分类](#2.4 端口号的分类)
- [3. 传输层的功能](#3. 传输层的功能)
- UDP数据报
-
- [1. 有连接的传输 vs 无连接的传输](#1. 有连接的传输 vs 无连接的传输)
- [2. 可靠的传输 vs 不可靠的传输](#2. 可靠的传输 vs 不可靠的传输)
- [3. UDP协议、UDP数据报、UDP首部](#3. UDP协议、UDP数据报、UDP首部)
- [4. TCP协议、TCP报文段、TCP首部](#4. TCP协议、TCP报文段、TCP首部)
- [5. UDP数据报格式](#5. UDP数据报格式)
- [6. 小结](#6. 小结)
- UDP检验
-
- [1. 一种新的差错检验方法](#1. 一种新的差错检验方法)
- [2. UDP检验](#2. UDP检验)
- [3. 小结](#3. 小结)
- TCP协议的框架梳理
- TCP报文段
-
- [1. 端口](#1. 端口)
- [2. 序号、确认号、ACK⭐](#2. 序号、确认号、ACK⭐)
- [3. 数据偏移、保留](#3. 数据偏移、保留)
- [4. URG、PSH、RST、紧急指针](#4. URG、PSH、RST、紧急指针)
- [5. SYN、FIN⭐](#5. SYN、FIN⭐)
- [6. 窗口⭐](#6. 窗口⭐)
- [7. 检验和](#7. 检验和)
- [8. 选项⭐](#8. 选项⭐)
- [9. 小结](#9. 小结)
- TCP连接管理
-
- [1. 建立连接（三次握手）](#1. 建立连接（三次握手）)
-
- [1.1 序号变化](#1.1 序号变化)
- [1.2 TCP变化](#1.2 TCP变化)
- [1.3 建立连接阶段耗时分析](#1.3 建立连接阶段耗时分析)
- [2. 释放连接（四次挥手）](#2. 释放连接（四次挥手）)
-
- [2.1 序号变化](#2.1 序号变化)
- [2.2 TCP变化](#2.2 TCP变化)
- [2.3 释放连接阶段耗时分析](#2.3 释放连接阶段耗时分析)
- [3. 小结](#3. 小结)
传输层提供的服务
1. 总结概述
2. 端口
2.1 传输层端口号的概念
IP地址+端口号=网络上一台主机的特定进程（可以理解为你手机上的一个软件）
2.2 进程、端口号、传输层协议之间的关系
- 进程：手机上的软件，比如微信
- 端口号：微信的输入框
- 传输层协议：文字聊天（TCP）or语音聊天（UDP）
- 套接字：我的手机上的微信可以选择文字聊天和语音聊天（绑定路径了，你和这个人的下一次聊天还是这个聊天页面）
- 微信文字聊天 → 用 TCP：不能丢消息，顺序不能乱。
- 微信语音/视频通话 → 用 UDP：允许偶尔丢包（声音卡一下），但要求低延迟。
注意：
- 你的手机和我的手机的端口号是可以重名的-->两台主机的端口号是相互独立的
- 文字聊天和语音聊天的端口号也是可以重名的-->TCP和UDP的端口号是相互独立的
2.3 熟知端口号
因为下面的应用程序都是装机必备的，所以都会分配固定的端口号给他们。
2.4 端口号的分类
- 客户端：主动发起通信
- 服务器：被动通信
- ps ：分类只是建议，而不是强制
3. 传输层的功能
- 复用：比如微信和qq都可以文字聊天和视频通话
- 分用 ：微信只能接到微信的聊天和通话，qq只能接到qq的聊天和通话
UDP数据报
1. 有连接的传输 vs 无连接的传输
- TCP：有连接的传输
- UDP：无连接的传输
2. 可靠的传输 vs 不可靠的传输
- TCP：可靠的传输
- UDP：不可靠的传输
3. UDP协议、UDP数据报、UDP首部
可以和下方的TCP做对比
- 首部只有8B：毕竟都无连接不可靠传输了，也不可能装太多东西
- 不支持报文自动拆分、重装：所以如果有长报文，就只能手动分好了再用UDP传输
- 无连接不可靠、不支持拥塞控制：堵了就是堵了，它没有告诉别人堵了的能力
- 支持一对一、一对多：可以传输到很多台主机的同一个UDP端口上
4. TCP协议、TCP报文段、TCP首部
- 首部20~60B：可靠有连接，自然占的就大一点儿（因为要装好多东西，源地址目的地址blabla...）
- 支持报文自动拆分、重装：方便√
- 可靠有连接、支持拥塞控制：它可以告诉自己来的地儿有点儿堵，让它发货发慢一点儿
- 仅支持一对一：因为需要先建立连接
5. UDP数据报格式
首部只有8B，也就是88=64bit=164，也就是下面的四块
- 源端口号：匿名不用回复就不告诉自己是谁，想要回复就写自己的
- 目的端口号：必备，因为要给对方发送这个数据
- UDP长度：必备，包含首部，以字节为单位
- UDP检验和：必备，看自己发过去的数据有没有错
- UDP数据报 ：理论是65535B，但是受IP协议的限制，所以实际上是65515B
6. 小结
UDP检验
1. 一种新的差错检验方法
16+16+16 得到的结果取反
检验的时候再全部加回去，因为是取反后的（红色），和正常取反前的结果（黑色的加在一起）加在一起，没出错的话结果肯定都是1
溢出一位就另起一行，在最后给它加回去
2. UDP检验
- 伪首部：用于计算检验，无其他实际作用
3. 小结
IP的首部检验和UDP的大差不差，只是有些细节不太一样：
- IP检验不需要伪首部，仅IP首部16bit16bit地相加
TCP协议的框架梳理
TCP报文段
1. 端口
发送肯定有发送方（源端口）和接收方（目的端口）
2. 序号、确认号、ACK⭐
- 序号seq ：用于标记数据部分第一个字节 在原始字节流 中的位置，发送方自己设置
- 确认号ack_seq ：用于反馈，表示序号 在该确认号之前 的所有字节都已正确收到
- ACK ：和确认号ack绑定的，0的话确认号就无效，1的话确认号就有效
- 序号 ：可以看到图中发送方将起始序号设置为500，按照传输数据长度依次往下排序号
- ACK和ack ：只有握手1的ACK=0 ，其他的ACK都为1
- 确认号ack_seq ：用于反馈，表示序号 在该确认号之前 的所有字节都已正确收到
接受方只接收到了1、2、4的报文，但是因为ack表示的是累加确认 ，就是到谁之前都正确收到了
1、2、4都受到了，但是也只能说明3之前的都正确收到了，所以ack_seq=2500（3的序号）
3. 数据偏移、保留
- 数据偏移：TCP首部长度
- 保留 ：没用
4. URG、PSH、RST、紧急指针
- URG：紧急位，加急插队
- PSH：推送位，希望对方快速回复
- RST：复位位，表示出现严重错误，必须释放连接。
- 紧急指针 ：也是序号，但是是另起的序号，和上面的序号一点儿关系都没。
- 紧急指针 ：也是序号，但是是另编的序号，和上面的序号一点儿关系都没。
5. SYN、FIN⭐
- SYN ：同步位，表示这是一个连接请求 或连接接受报文。（用于握手）
- FIN ：终止位，表示此报文段的发送方的数据已发送完毕 ，要求释放传输连接。（用于挥手）
6. 窗口⭐
- 窗口 ：流量控制
接收缓冲区已经接收了1、2也就是2000B，窗口设置的大小是2500B，所以就只剩500B的剩余空间，就不可能放得下3了。
7. 检验和
和UDP的校验相同。
8. 选项⭐
主要考MSS
- 握手1和握手2会在选项中协商MSS
9. 小结
TCP连接管理
1. 建立连接（三次握手）
1.1 序号变化
- SYN ：同步位，表示这是一个连接请求 或连接接受报文 。（用于握手）
握手1发出请求，握手2接受，所以就这两个为1. - ACK ：和确认号ack绑定的，0的话确认号就无效，1的话确认号就有效
握手1是第一次发出的请求，之前也没有进行字节传输，所以只有握手1是0. - 确认号ack_seq ：用于反馈，表示序号 在该确认号之前 的所有字节都已正确收到
握手1ACK=0，所以ack无效； - FIN ：终止位，表示此报文段的发送方的数据已发送完毕 ，要求释放传输连接。（用于挥手）
finish，这才刚刚开始，根本用不到，所以都是0 - 序号seq ：用于标记数据部分第一个字节 在原始字节流 中的位置，发送方 自己设置
客户设置自己的序号，服务器也设置自己的序号，互不干涉。
- 确认号ack_seq ：用于反馈，表示序号 在该确认号之前 的所有字节都已正确收到
seq-->ack，发送方的seq序号转化为接收方的ack序号+1 - 序号seq ：用于标记数据部分第一个字节 在原始字节流 中的位置，发送方 自己设置
握手1、握手2不能携带数据，但是要消耗一个序号
- 握手1、2不能携带数据，握手3可以携带数据
- 握手1、2固定消耗一个序号
- 握手3如果不携带数据就不消耗序号
1.2 TCP变化
- 客户 ：连接关闭-->发送握手1-->同步已发送 -->接受握手2-->发送握手3-->已建立连接
- 服务器 ：连接关闭-->监听 -->接受握手1-->发送挥手2-->同步已收到 -->接受握手3-->已建立连接
- 总结 ：握手1之后的就是同步XX状态，连接3之后就是已建立连接状态
1.3 建立连接阶段耗时分析
- 客户端：1RTT
- 服务器端 ：1.5RTT
2. 释放连接（四次挥手）
2.1 序号变化
- SYN ：同步位，表示这是一个连接请求 或连接接受报文 。（用于握手）
用于握手的，自然在挥手的时候就没用了 - ACK ：和确认号ack绑定的，0的话确认号就无效，1的话确认号就有效
只有握手1是0. - FIN ：终止位，表示此报文段的发送方的数据已发送完毕 ，要求释放传输连接。（用于挥手）
发送方，自然是谁先发送谁就是1，挥手1先发送所以为1，挥手2是回应挥手1所以为0，挥手3是服务器发送所以为1，挥手4是回应为0
- 确认号ack_seq ：用于反馈，表示序号 在该确认号之前 的所有字节都已正确收到
seq-->ack，发送方的seq序号转化为接收方的ack序号+1（发送+回应，有来有回） - 序号seq ：用于标记数据部分第一个字节 在原始字节流 中的位置，发送方 自己设置
- 序号seq ：用于标记数据部分第一个字节 在原始字节流 中的位置，发送方 自己设置
中间又传送了一次数据，所以要算上数据的长度
2.2 TCP变化
- 客户：已建立连接 -->发送挥手1-->终止等待1 -->接受挥手2-->终止等待2 -->接受挥手3-->发送挥手4-->时间等待-->连接关闭
- 服务器：已建立连接 -->接受挥手1-->发送挥手2-->关闭等待 -->发送挥手3-->最后确认 -->接受挥手4-->连接关闭
2.3 释放连接阶段耗时分析
如果在客户的时间等待状态 中又接收到挥手3，就会重新发送挥手4，直到时间等待状态可以平安无事地过去。
- 客户：1RTT+2MSL
- 服务器 ：1.5RTT
3. 小结
