文章目录
1. 传输层的两个协议
- TCP（Transmission Control Protocol）传输控制协议
- UDP (User - -Datagram Protocol ）用户数据报协议
2. UDP 报文格式
- UDP是无连接的，减少了建立和释放连接的开销
- UDP尽最大能力交付，不保证可靠交付 因此不需要维护一些复杂的参数，首部只有8个字节（TCP的首部至少20个字节）
- 端口占两个字节 可以推测出端口的取值范围是0～65535
- 客户端的源端口是临时开启的随机端口
- 目的端口是应用程序指定的(可利用端口 区分程序的不同服务)
- 防火墙可以设置开启和关闭某些端口来提高安全性
- UDP 长度
- 占16 首部的长度 + 数据的长度
- 检验和的计算内容：伪首部 + 首部 + 数据
- 伪首部：仅在计算检验和时起作用，并不会传递给网络层
- 伪首部：仅在计算检验和时起作用，并不会传递给网络层
3. TCP
3.1 TCP 数据格式
- TCP首部占20字节
3.2 格式详解
- 序号
- 占四个字节
?来解决?络包乱序问题 。在建立连接后 代表传给对方TCP数据部分的第一个字节的编号 默认从1开始 但是实际上存储的是：默认编号+相对编号
为什么要有这个编号呢？ 为了告诉对方下次你应该给我发的首字节编号为多少的数据段。
传输层数据长度可根据 网络层的总长度(在网络层首部可直接读取)-传输层的首部长度(8个字节)= 数据长度 近而可以求初当前接受到数据部分多大 可求出下次需要发送的初始seq
- 确认号(确认应答号)
- 占四个字节 ?来解决不丢包的问题。 。在建立连接后，确认号代表期望对方下一次传过来的TCP数据部分的第一个字节的编号 。 当ACK=1时，确认号字段才有效。
- 窗口（Window）
- 占2字节 这个字段有流量控制功能，用以告知对方下一次允许发送的数据大小（字节为单位）
为什么要有个窗口呢？
如果没有窗口 每发一段 就需要给对方回应一次那么通信效率极低。所以为了提高通信效率 ，每次多发几段 给对方再相应一次。那么每次发几段合适呢？这时候就有了窗口的概念。告知对方下次允许发送的数据大小。窗?的实现实际上是操作系统开辟的?个缓存空间，发送?主机在等到确认应答返回之前，必须在缓冲 区中保留已发送的数据。如果按期收到确认应答，此时数据就可以从缓存区清除。
- 数据偏移： 首部长度
- 标志位
- URG=1 时 紧急指针才有效 表明当前报文段中有紧急数据 应优先尽快传送
- ACK =1 时 确认号字段才有效
- PUSH
- RST 当RST=1 时 表明连接中出现严重差错 必须释放连接 然后再重新建立连接
比如 数据包重传多次还失败 此时就会发送rst报文
- SYN 当SYN=1 ACK=0 表明这是一个建立连接的请求 若对方同意建立连接 则回复SYN=1 ACK =1
- FIN =1 表示数据已经发送完毕 要求释放连接
3.3 TCP的特点
- 可靠传输
- 流量控制
- 拥塞控制
- 连接管理
- 建立连接
- 释放连接
3.4 可靠传输
-
ARQ（Automatic Repeat–reQuest），自动重传请求 数据发出后 对方回传数据收到的请求后 再发下一个。如果在规定时间内没收到 会再发一次数据包。
-
如果
-
若有个包重传了N次还是失败，会一直持续重传到成功为止么？
这个取决于系统的设置，比如有些系统，重传5次还未成功就会发送reset报文（RST）断开TCP连接
- 每次发一个段 都需要回传一个确认包 数据效率太低？
- 引入了窗口 每次根据窗口大小 发送多个包 再回传一个确认包。具体的传输过程如下：
- 如果多个数据其中有丢失 是否重新发送从丢失开始的字节一直到后面的所有字节呢？
在TCP通信过程中，如果发送序列中间某个数据包丢失（比如1、2、3、4、5中的3丢失了） TCP会通过重传最后确认的分组后续的分组（最后确认的是2，会重传3、4、5）
这样原先已经正确传输的分组也可能重复发送（比如4、5），降低了TCP性能
为改善上述情况，发展出了SACK（Selective acknowledgment，选择性确认）技术 告诉发送方哪些数据丢失，哪些数据已经提前收到
使TCP只重新发送丢失的包（比如3），不用发送后续所有的分组（比如4、5）
- SACK信息会放在TCP首部的选项部分
- Kind：占1字节 值为5代表这是SACK选项
- Length：占1字节。表明SACK选项一共占用多少字节
- Left Edge：占4字节，左边界
- Right Edge：占4字节，右边界
一对边界信息需要占用8字节，由于TCP首部的选项部分最多40字节，所以 SACK选项最多携带4组边界信息
SACK选项的最大占用字节数 = 4 * 8 + 2 = 34
- 为什么选择在传输层就将数据“大卸八块”分成多个段，而不是等到网络层再分片传递给数据链路层？ 因为可以提高重传的性能
- 需要明确的是：可靠传输是在传输层进行控制的
- 如果在传输层不分段，一旦出现数据丢失，整个传输层的数据都得重传
- 如果在传输层分了段，一旦出现数据丢失，只需要重传丢失的那些段即可
3.5 流量控制
- 为什么要流量控制呢？
- 如果接收方的缓存区满了,发送方还在疯狂着发送数据 接收方只能把收到的数据包丢掉,大量的丢包会极大着浪费网络资源 所以要进行流量控制
- 什么是流量控制？
- 让发送方的发送速率不要太快，让接收方来得及接收处理
- 原理
- 通过确认报文中窗口字段来控制发送方的发送速率 发送方的发送窗口大小不能超过接收方给出窗口大小 当发送方收到接收窗口的大小为0时，发送方就会停止发送数据
- 流量控制具体流程:
- 有一种特殊情况 一开始，接收方给发送方发送了0窗口的报文段后面，接收方又有了一些存储空间，给发送方发送的非0窗口的报文段丢失了发送方的发送窗口一直为零，双方陷入僵局
解决方案
当发送方收到0窗口通知时，这时发送方停止发送报文 并且同时开启一个定时器，隔一段时间就发个测试报文去询问接收方最新的窗口大小 如果接收的窗口大小还是为0，则发送方再次刷新启动定时器
3.6 拥塞控制
- 什么是拥塞控制?
防止过多的数据注入到网络中, 避免网络中的路由器或者链路过载
- 拥塞控制的特点?
拥塞控制是一个全局性的过程 设计到所有主机 路由器 以及与降低网络传输性能有关的所有因素 是大家共同努力的结果。相比而言 流量控制是点对点通信的控制
- 拥塞控制的几个方法？
- 慢开始
发送方维持一个拥塞窗口 cwnd ( congestion window )的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口。
发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。但只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数。
慢开始算法：当主机开始发送数据时，如果有大量数据字节注入到网络，那么就有可能引起网络拥塞，因为现在并不清楚网络的负荷情况。因此，较好的方法是 先探测一下，即由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞窗口数值。通常在刚刚开始发送报文段时，先把拥塞窗口 cwnd 设置为一个最大报文段MSS(每个段最大的数据部分大小 在建立连接时确定 不超过1500字节 因为数据链路层一个帧最大是1500字节 )的数值。而在每收到一个对新的报文段的确认后，乘法2。用这样的方法逐步增大发送方的拥塞窗口 cwnd ，可以使分组注入到网络的速率更加合理。 - 拥塞避免
ssthresh（slow start threshold）：慢开始阈值 。
cwnd达到阈值后，以线性方式增加
拥塞避免（加法增大）：拥塞窗口缓慢增大，以防止网络过早出现拥塞
乘法减小：只要网络出现拥塞，把ssthresh减为拥塞峰值的一半，同时执行慢开始算法（cwnd又恢复到初始值）
当网络出现频繁拥塞时，ssthresh值就下降的很快
- 快速重传
接收方 每收到一个失序的分组后就立即发出重复确认 使发送方及时知道有分组没有到达
而不要等待自己发送数据时才进行确认
发送方 只要连续收到三个重复确认（总共4个相同的确认），就应当立即重传对方尚未收到的报文段 而不必继续等待重传计时器到期后再重传
- 快速恢复
当发送方连续收到三个重复确认，说明网络出现拥塞
就执行“乘法减小”算法，把ssthresh减为拥塞峰值的一半
当发送方连续收到三个重复确认，说明网络出现拥塞
就执行“乘法减小”算法，把ssthresh减为拥塞峰值的一半
- 完整拥塞控制流程
3.5 拥塞控制的几个问题？
- 发送窗口的最大值?
发送窗口的最大值 swnd=min(swnd,rwnd)
当rwnd<cwnd时 是接收方的接受能力限制发送窗口的最大值
当cwnd<rwnd时 则是网络的拥塞限制发送窗口的最大值
- 超时重传和快速重传分别在什么时候使用呢？
- 网络收到三个重复ACK 说明网络不是很堵 所有启用快速度重传
- 没有收到重复ACK的时候 说明网络很堵 启用超时重传。
4 面向连接
4.1 什么是连接
- 为了保证可靠性和流量特地维护的状态信息，这些信息包括Socket、序列 号和窗???
Socket 由IP地址和端口组成
序列号 用来解决乱序问题
窗口大小 用来做流量控制
4.2 连接的建立过程
- ?开始，客户端和服务端都处于CLOSED状态。先是服务端主动监听某个端?，处于
LISTEN状态。
- 客户端会随机初始化序号client_isn ,将此序号置于 TCP ?部的序号字段中，同时把 SYN 标志位置为 1 ，表示 SYN 报?。接着把第?个 SYN 报?发送给服务端，表示向服务端发起连接，该报?不包含应?层数据，之后客户端处于 SYN-SENT状态。
- 服务端收到客户端的 SYN 报?后，?先服务端也随机初始化??的序号server_isn ，将此 序号填? TCP ?部的「序号」字段中，其次把 TCP ?部的「确认应答号」字段填client_isn +1 , 接着把 SYN 和 ACK 标志位置为1。最后把该报?发给客户端，该报?也不包含应?层数 据，之后服务端处于 SYN-RCVD 状态。
- 客户端收到服务端报?后，还要向服务端回应最后?个应答报?，?先该应答报? TCP ?部 ACK 标志位置为1，其次确认应答号字段填?server_isn + 1 ，最后把报?发送给服务端，这 次报?可以携带客户到服务器的数据，之后客户端处于 ESTABLISHED 状态。
- 服务器收到客户端的应答报?后，也进?ESTABLISHED 状态。
4.3 为什么是三次握手呢?
- 同步双方序列化号
TCP 协议的通信双?,都必须维护?个序列号，序列号是可靠传输的?个关键因素。
序列号作?：
接收?可以去除重复的数据；
接收?可以根据数据包的序列号按序接收；
可以标识发送出去的数据包中， 哪些是已经被对?收到的；
所以当客户端发送携带「初始序列号」的 SYN 报?的时候，需要服务端回?个 ACK 应答报?，表示客户端的 SYN 报?已被服务端成功接收，那当服 务端发送「初始序列号」给客户端的时候，依然也要得到客户端的应答回应，这样?来?回 总共三次，才能确保 双?的初始序列号能被可靠的同步。
-
节省服务端资源
- 假如由于网络拥堵,客户端在规定的时间没有收到 客户端没有收到第一个连接的回复 ，重发第二个连接后 收到第一个连接的回复了 那么此时客户端就会判断这个连接是过期无效的连接 将会通过第三次握手告诉服务端这个链接无效。如果只有两次握手 服务端无法感知无效连接 依然会在服务器端维护无效连接的状态。浪费资源
- 假如由于网络拥堵,客户端在规定的时间没有收到 客户端没有收到第一个连接的回复 ，重发第二个连接后 收到第一个连接的回复了 那么此时客户端就会判断这个连接是过期无效的连接 将会通过第三次握手告诉服务端这个链接无效。如果只有两次握手 服务端无法感知无效连接 依然会在服务器端维护无效连接的状态。浪费资源
-
节省资源