传输层：负责端口与端口之间的传输
传输层的两个典型协议：UDP,TCP；

UDP协议

UDP协议特点

无连接，不可靠，面向数据报

UDP协议格式

• 16位的源端口：标识源端口（标识数据来自哪个程序）
• 16位的目的端口：标识目的端口（标识数据去往哪一个进程）
• 16位的UDP长度：UDP数据的长度，单位字节。

UDP数据最大为65536字节=UDP协议的字段长度+应用层数据

• 16位校验和：校验数据在传输过程中是否失真，发送者填充，接受者校验

如果超过UDP最大传输大小，需要拆包传输【数据长度： 是否拆分：1/0 拆分位置】
结论：对于超过UDP传输大小的应用层数据，需要应用层字节进行分包传输，分包传输本质上就是需要应用层程序自定制应用层协议
应用层协议当中应当满足分包/合包的要求+可靠传输

UDP的应用

• DSN：域名解析
• DHCP：动态主机分配协议
• TFTP：简单文件传输协议

UDP适合局域网

TCP协议

面向连接

• 数据包名称，连接双方状态，包序列管理

包序列管理：客户端和服务端都需要维护一套序号，用来标识客户端/服务端数据
确认序号=上一次对端发送数据的序号+数据长度

三次握手：

• 三次握手当中连接双方协商各自需要的起始位置
• 起始序号不一定从0开始，可以从任意序号开始，但后续要遵守序号管理规则
• 纯ack数据包不消耗序号，纯ack数据包仅仅起确认的作用

四次挥手：

• MSL：报文最大生存时间
• 2MSL=丢失的ACK的MSL+重传的FIN的MSL
• 2MSL：本质是想让主动断开连接方收到被动断开连接方重传的FIN报文，防止被动断开连接方的状态没办法重置为closed

TCP协议格式

• 16源端口
• 16位目的端口
• 32位序号：该条TCP数据携带的起始序号
• 32位确认序号：期望对方发送的数据从哪个序号（对方管理的序号）开始发送
• 4位首部长度：报头长度——1111->15：计算出来的数值*4（单位字节）
• 保留6位
• TCP类型标志位

URG：紧急标志位
ACK：确认标志位
PSH：发送数据标志位
RST：重置连接标志位
SYN：连接发起标志位
FIN：断开连接标志位

• 16位窗口大小：消息接受方告诉消息发送方，自己的接收能力是多少（动态变化），单位字节。
• 16位校验和：校验数据在发送的时候是否失真
• 16位紧急指针：背后URG标志位，发送带外数据
• MSS：最大报文长度：决定TCP连接双方每次发送数据的最大长度

1.在三次握手当中协商这个值，取决于连接双方较小值
2.协商最大报文长度本质：防止报文过大，在网络当中丢失数据，引发后续超时重传机制
3.MSS的值受到数据链路层MTU的影像
MTU：最大传输单元（一般在1500左右）

可靠传输

确保数据到达对端

确认应答机制

保证数据可靠有效的到达对端

现象：发送方发送消息需要接受方进行确认
结论：本质上是对序号的确认

超时重传机制

当发送方发送数据的时候启动超时重传计时器，当计时的时间超过“超时重传时间”之后，还没有收到确认信号，则重传该报文

• RTO：超时重传时间
• RTT：报文往返时间

RTO=RTT（上次）i+RTT（上上次）（1-i）
i一般取0.9

提高传输效率

在网络比较差的情况下，TCP发送数据完全不考虑网络的转发能力，则丢失的TCP数据包就会越来越糟，重传的数据包越来越多，从而网络当中的数据量越来越多，这样只会越来越糟糕
解决方法：
1.自身发送数据量
由于MSS决定了一次性传输数据的上限，所以没办法修改
确认应答机制：每一个TCP数据包都是需要确认的-后续的滑动窗口机制会打破
2.对方的接收English：对方接收缓冲区的大小
3.网络转发能力

滑动窗口机制

允许窗口大小的数据（不需要等待上次数据的确认）发送到网络当中进行传输，提高数据吞吐量

• 窗口大小：指的是不需要等待确认应答包二可以继续发送数据包的最大值
  优点：在不考虑网络的情况下，可以提高发送数据量
  缺点：需要防备数据丢失的情况，触发超时重传，一段触发需要将数据重新发送，也意味着在发送方没有收到确认之前，需要将数据缓冲起来

滑动窗口的四个区域

• 已经发送，且收到确认区域
• 已经发送，没有收到确认区域
• 等待发送区域
• 暂时不能发送区域

注意：在已经发送等待接收区域，如果前面发送的信息没有得到确认，及时后面发送的信息已经确认，窗口也不能进行滑动

缓冲区的本质：环形队列

滑动窗口向前滑动：当收到窗口中最早发送分组数据的确认应答，则窗口向后滑动，收到中奖分组但没有收到最早分组，窗口不滑动

滑动窗口丢包问题：

• 分组ACK丢失

结论：当多个分组中某个分组的ack丢失，可以通过后续分组的确认应答进行确认，发送方不会触发超时重传

• 数据丢失

结论：一定会触发数据重传，不过，在双方按照滑动窗口发送数据的时候，可以通过连续三次的重复确认，触发快重传。在发送方还没有触发超时重传的时候，数据以及快速重传

对方接收能力

发送方在发送打了窗口数据被对方接收后，就收方的tcp缓冲区空间急剧减少，此时需要发送方降低发送速率（滑动窗口控制），减少发送的数据量

流量控制机制

接收方通过窗口大小来控制发送方的发送速率

结论：接受方控制发送方的发送速率
方法：通过tcp报头当中的窗口大小来控制。窗口的大小数据即接受方的接收能力

• 0窗口：就收费发送窗口为0的数据包给发送方，称之为0号窗口通告
• 恢复发送：1.发送方发送窗口探测包，询问接受方能否发送数据。2.接受方主动发送闯关更新通知（发送一个不为0的窗口）

延迟应答机制

1.每次接受方回复确认应答时，会在TCP包头当中携带窗口大小，来告知发送方自己的接收能力
2.发送方要通过接收方通告的窗口大小来调整发送窗口

延迟应答思想：接收方收到数据后，等待一会，在等待时间呃逆应用层将数据读走，这样，接收缓冲区的空间变大之后，再进行应答

网络转发能力

1.TCP通过滑动窗口来流控，但是TCP认为这样不够：流控只是网络模型4层以上的事，TCP还应该更聪明的指定整个网络上的事
2.TCP不是一个自私的协议，当拥塞发生的时候，要做自我牺牲

拥塞控制机制

基于想要探测网络转发能力的需求，TCP还维护了拥塞窗口（cwnd），是发送方维护的一个状态变量，会根据网络的拥塞程度动态变化

• 网络转发能力好，拥塞窗口大
• 网络转发能力弱，拥塞窗口小

对于发送方而言，发送的数据大小w=min（发送窗口，拥塞窗口）

• 发送窗口：发送窗口取决于接收方的接收能力
• 拥塞窗口：取决于网络的转发能力

维护拥塞窗口的方式：慢启动，拥塞避免，快恢复

慢启动

随着次数的增加，拥塞窗口呈现指数增长，知道拥塞窗口达到慢开始门限当到达慢开始门限时，执行拥塞避免算法

拥塞避免

随着轮询次数的增加，拥塞窗口呈现线性增长（每次拥塞窗口大小增加1），知道发生拥塞（tcp丢包）
执行快恢复

快恢复

计算新的慢开始门限（阈值）=拥塞发生时拥塞窗口的1/2
拥塞窗口大小=新的慢开始门限值
执行拥塞避免算法

扩展

TCP中的计时器

• 超时重传计时器
• TIME_WAIT计时器
• 保活计时器：判断连接是否正常

1.服务器每收到一次客户的数据，就重新设置保活计时器，时间的设置通常是两个小时
2.若两个小时都没有收到客户端的数据，服务端就发送一个探测报文段（保活数据包/心跳），以后每个75秒发送一次
若连续发送10次都没有得到响应，服务端就会认为客户端出了故障，接着关闭这个连接

面向字节流

创建一个TCP的socket，同时在内核中创建一个发送缓冲区和一个接收缓冲区

• 调用write时，数据会先写入发送缓冲区中
• 如果发送的字节数太长，会被拆封成多个TCP数据包发出
• 如果发送的字节数太短，就会现在缓冲区等待，等到缓冲区长度差不多，或者其他合适的时机发送
• 接收数据时，数据也是从网卡驱动城区到达内核的缓冲区，然后应用程序可以调用read从接收缓冲区拿到数据
• 另一方面，TCP的一个连接，既有发送缓冲区，也有接收缓冲区，对应这样一个连接，即可以读数据，也可以写数据，这个概念叫做全双工

由于缓冲区的存在，TCP程序的读和写不需要一一匹配

• 写100个字节数据时，可以调用一次write写100个字节，也可以调用100次write每次写一个字节
• 读100个字节数据时，不需要考虑写的时候是如何写的，既可以一次read100个字节，也可以一次read1个字节重复100次

粘包问题

• 粘包问题的包指的是应用层数据包
• 在TCP的协议头中，没有像UDP一样的“报文长度”字段，但是有一个“序号”字段
• 站在传输层的角度，TCP是一个一个报文过来的，按照序号排好放在缓冲区中
• 站在应用层角度，看到的是一串连续的字节数据
• 当应用程序看到一连串的字节数据，就不知道从哪个部分开始到哪个部分结束是一个完整的应用层数据包

如何避免粘包问题？明确两个包的边界

• 对于定长的包，保证每次都按照固定的大小读取即可
• 对于变长的包，可以在包头的位置约定一个包总长度的字段，从而知道包结束位置
• 对于边长的包，还可以在包和包纸巾使用明确的分隔符（应用层协议，由程序员自己来定，要保证分隔符不合正文冲突）

对于UDP协议，是否存在粘包问题

• 对于UDP，如果还没有上层交付数据，UDP报文长度依旧在，同时，UDP是一个一个把数据交付给应用层，有很明确的数据边界
• 站在应用层的角度，使用UDP的时候，要么收到完整的UDP报文，要么不收，不会出现“一半”的情况