1 概述
1.1 进程之间的通信
运输层的作用
复用：不同的进程都能传输数据
分用：有能力传给正确的进程
运输层还要差错检测——可靠信道与不可靠信道
UDP 和 TCP 的区别
1.2 运输层靠什么来完成复用分用——运输层的端口
设计端口遇到的问题
- 不同操作系统的进程标识符不一样，无法直接使用
解决办法——端口号
- 这里指的端口是软件端口
- 软件端口和硬件端口
- 常用的熟知端口
2 UDP
2.1 UDP 的主要特点
UDP 的主要特点
UDP 是面向报文的
UDP 使用场景
- 重复请求信息：RIP DNA DHCP
- 一次传少量数据的应用（面向报文的）
- 实时应用：微信语音通话、腾讯视频
- 多媒体应用
2.2 UDP 的首部格式
3 TCP
3.1 TCP 的主要特点
可靠交付：无差错、无丢失、无重复、按序到达
- TCP 面向流的概念
可以把一个报文切开发，也可以攒着一块发 - 几个面向连接的概念
- TCP 连接、IP 地址、套接字
4
4.1 停止等待协议
4.2 连续 ARQ 协议
5 TCP 报文段的首部格式
6 TCP 可靠传输的实现
6.1 以字节为单位的滑动窗口
假设 B 收到了 31
移动窗口
A 收到了 B 的确认
A 已经都发完了，开始准备重传
6.2 超时重传时间的选择
加权平均往返时间 RTTs
超时重传时间 RTO
RTT 的测量相当复杂——因此产生了 Karn 算法
Karn 算法也有问题——因此产生了修正的 Karn 算法
6.3 选择确认 SACK
正常重传时，如果收到了 1-1000,1501-10000，只会确认 1001。虽然只丢了一点，收到了一堆，但依旧会带来大量的重传浪费。所以尝试只传送缺少的数据而不重传已经正确到达接收方的数据。
7
- 可能死锁
- 死锁的解决办法：持续计时器
7.2 TCP 的传输效率
-
TCP 发送报文都当三种时机：
-
糊涂窗口综合症
- 发送方糊涂窗口综合症
（发送一个数据字节，在等待确认的过程中也会攒一批数据到缓存，所以收到确认后可以直接发送缓存中的所有数据） - 接收方糊涂窗口综合症
- 发送方糊涂窗口综合症
8 TCP 的拥塞控制
8.1 拥塞控制的一般原理
8.1.1 拥塞
- 什么是拥塞
- 拥塞产生的原因
- 增加资源无法解决拥塞
8.1.2 拥塞控制
- 拥塞控制与流量控制的区别
- 拥塞控制的作用
- 拥塞控制的一般原理
- 拥塞控制分为开环控制（避免，难实现）和闭环控制（消除）
- 闭环控制措施
8.2 TCP 的拥塞控制方法
8.2.1 慢开始(Slow start)
meikan 没看懂 AAAAAAAAAAAAAAAAAAAAAAAA
8.2.2 拥塞避免
8.2.3 快重传 FR 算法
8.2.4 快恢复 FR 算法
8.2.5 总结
0. 慢开始
- cwnd = 16 时到 ssthresh，开始拥塞避免
- cwnd = 24 时超时,ssthresh = cwnd/2 = 12, cwnd = 1。慢开始
- cwnd = 12 时到 ssthresh，开始拥塞避免
- cwnd = 16 时发送端收到了连续三个重传，执行快恢复，ssthresh = cwnd/2 = 8, cwnd = ssthresh = 8
- cwnd = 8 到 ssthresh，开始拥塞避免
8.3 主动队列管理 AQM
8.3.1 先进先出&尾部丢弃策略
8.3.2 主动队列管理 AQM
为解决全局同步，提出了主动队列管理 AQM 算法
1 随机早期检测 RED
9 TCP 的运输连接管理
9.1 TCP 的连接建立
三报文握手的动画
- B 的 TCP 服务器进程先创建传输控制块 TCB，准备接受客户进程的连接请求。
CLOSED->LISTEN - A 的 TCP 向 B 主动发出连接请求报文段，其首部中的同步位 SYN = 1，并选择序号 seq = x。TCP 规定，SYN 报文段（即 SYN=1 的报文段）不能携带数据，但要消耗掉一个序号
CLOSED->SYN-SENT - B 的 TCP 收到连接请求报文段后，如果同意，则发回确认。SYN = 1, ACK = 1, ack = x+1, seq = y。
LISTEN->SYN-RCVD - A 收到此报文段后向 B 给出确认。ACK = 1, ack = y+1。A 的 TCP 通知上层应用，链接已经建立。TCP 规定 ACK 报文段可以携带数据，如果不携带数据，则不消耗序号（下一个数据报文段的序号仍是 seq = x+1）。
SYN-SENT->ESTABLISHED - B 的 TCP 收到主机 A 的确认后也通知其上层应用进程：TCP 连接已经建立，双方可以开始数据传送。
SYN-RCVD->ESTABLISHED
9.2 TCP 的连接释放
谁要关谁发报文
- A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP 连接。连接释放报文段首部的 FIN=1，seq=u，等待 B 的确认。TCP 规定，FIN 保温段即使不携带数据也消耗掉一个序号。
ESTABLISHED->FIN-WAIT-1 - B 发出确认，ACK=1，ack=u+1,seq=b。TCP 服务器进程通知高层应用进程。此时从 A 到 B 这个方向的连接释放掉了，TCP 连接处于半关闭状态（半关闭只不让发数据报文，控制报文还能发）。B 若发送数据，A 仍要接受。 A:
ESTABLISHED->CLOSE-WAIT。B 收到后:FIN-WAIT-1->FIN-WAIT-2 - 若 B 已经没有要向 A 发送的数据，其应用进程就通知 TCP 释放连接。FIN=1, ACK=1, ack=u+1。
CLOSE-WAIT->LAST-ACK - A 收到连接释放报文段后，必须发出确认，此时 TCP 连接还未释放掉。ACK=1, ack=w+1, seq=u+q。 A:
FIN-WAIT-2->TIME-WAIT。B 收到后:LAST-ACK->CLOSED - 经过时间等待计时器设置的时间 2MSL 后，A 释放 TCP 连接。
TIME-WAIT->CLOSED- 保证发送的最后一个 ACK 报文段能够到达 B。
如果不 2MSL，ACK 报文发一半没掉了，B 没收到就会继续发 FIN 报文，但是此时 A 已经关了，导致 TCP 不可靠 - 保证这次连接的所有数据从此从网络上消失（防止“已失效的连接请求保温段”出现在连接中）
如果 A 进入 CLOSED 之后又立刻请求和 B 建立连接，有可能老的连接和新的连接端口号一样。如果上次连接的某些数据滞留在网络中，直到新连接建立才到达，老数据则有可能和新数据混淆
- 保证发送的最后一个 ACK 报文段能够到达 B。
保活计时器
TCP 的四个计时器
- 超时重传计时器：解决 “报文丢失” 问题 —— 当发送端发出 TCP 报文后，启动该计时器；若超时未收到对应 ACK，就重传该报文。
- 持续计时器：解决 “零窗口死锁” 问题 —— 当接收端因缓存满发送
窗口=0的报文后，发送端会启动该计时器；超时后发送 “零窗口探测报文”，确认接收端是否恢复接收能力。 - 时间等待计时器：解决 “连接关闭后的残留报文” 问题 —— 客户端（主动关闭方）在第四次握手后，启动该计时器（时长为 2MSL，即报文最大生存时间的 2 倍）；超时后才彻底关闭连接。
- 保活计时器：检测 “连接空闲但对端异常”—— 当连接长时间（默认 2 小时）无数据传输时，启动该计时器；超时后发送 “保活探测报文”，若多次无响应则判定对端故障，主动关闭连接。
9.3 TCP 的有限状态机
