计算机网络学习 （三）传输层

UDP

一、 UDP 包头长什么样
当我们发送的UDP包到达目标机器后 发现MAC地址匹配 于是取下来 将剩下的包传给IP层 把IP头取下来 发现IP匹配 IP头里有8位协议 这里存放的使用的是TCP还是UDP 这里是UDP 然后按照UDP的格式 把数据解析出来，传输层数据处理完之后 内核的事情算是干完了 交给对应端口的应用程序就好了 UDP头很简单 只有 源端口 目标端口 UDP长度 UDP校验和 数据

二、 UDP 三大特点
1. 沟通简单 默认就认为网络世界良好 发出去的包很容易到达
2. 不会建立链接 虽然有端口号 但是监听在这个地方 谁都可以传给他 他也可以给任何人数据 甚至可以传给多个人数据
3. 不做拥塞控制 无论丢包成什么样 该怎么发还是怎么发

三、UDP 三大使用场景
1. 需要 资源少 对丢包不敏感的场景 DHCP 就是基于UDP的
2. 不需要建立链接
3. 需要处理速度快 时延低 可以容忍少数丢包的 即使网络拥塞 也会一直发

四、UDP 举例
1. QUIC 协议 是基于UDP的通信协议 TCP 需要建立链接 就算是共享链接也会出现前一个不来 后一个即便是没有关系也会等着
2. 流媒体协议 直播协议多用 RTMP 协议 RTMP 也是基于TCP的 很多直播应用都是基于UDP实现了自己的视频传输协议
3. 实时游戏 也是自定义可靠UDP协议
4. 4G网络 GTP-U 也是基于UDP协议的

TCP

一、TCP包头格式

1. 源端口 目标端口 知道是发给那个应用程序的
2. 包序号 解决乱序问题
3. 确认序号 发出去的包有没有收到就是通过确认号判断的 如果没有确认就会一直发
4. TCP是靠谱的协议 但是 从IP层来讲 如果网络状况很差 是没有可靠性保证的但是在TCP层 尽力的去保证可靠
5. 还有一些状态位 SYN 发起一个链接 ACK 回复 RST重连 FIN 结束链接 这些带状态为的包的发送 会引起双方的状态变更
6. 窗口大小

二、五大特点

1. 顺序问题 稳重不乱
2. 丢包问题 失败重传
3. 链接维护
4. 流量控制
5. 拥塞控制

三、TCP 三次握手

1. 为什么不是两次：当 A 向 B发起链接请求的时候 发出去的请求包可能绕弯路 延迟 或者B不相应 那么这时A会不断的重试 不断重发 如果始终没有链接上才会放弃。也就是说这是A实际上是发了多个请求包出去的 ，这多个请求包又可能都会到达B 那这个时候B就会告诉A ok 咱们可以连 如果是2次握手的话 AB就可能会产生多个链接 浪费！！！ 所以两次不行
2. 三次握手 A向B发起请求 B回复A 那么对于A来讲 自己的请求有一问一答，那么B给A的消息 A有没有收到呢 这是B还是不能确定和A有了链接 所以第三次就是确定B的回复A收到了 。其实 三次握手 30次也没关系 只是没有必要。
3. 三次握手过程中 还确定一个重要的东西 ------ 包序号，握手除了建立链接外 A要告诉B 我的包起始序号是多少 B也要告诉A 起始序号是多少。每个链接都要有不同的起始序号，这个起始需要是随着时间的变化而变化的。

四、TCP 四次挥手

1. A跟B发消息说不玩了 FIN seq=p
2. B确认收到A的不想玩消息 ACK ack=p+1 这是B还不能直接走开 万一B还有没弄完的数据 还需要继续传呢
3. 当B也结束时 FIN seq=q ACK ack=p+1 告诉A 我也不想完了
4. A 确认可以断开 ACK ack=q+1 此时链接断开
5. 其实就是AB两端 分别都要一次断开请求 一次确认断开的确认

五、累计应答或者累计确认
TCP为了保证顺序 在三次握手的时候 链接双方会商量一个起始ID 累计确认就是某个ID的包确认了之后，比这个ID小的包 全部确认。为记录发送的和接收的包，发送和接收端都有一个缓存来保存这些记录，发送端的缓存里按照包的ID一个一个排着，分为4中情况

1. 发送了并且确认的
2. 发送了但是未确认
3. 没发送 已经等待发送
4. 没发送 暂时还没不会发送的

六、滑动窗口

在建立链接的时候 双方会商定一个窗口大小 这个大小应该是 上边 2、3的总和 ，也就是发送了但是没确认的 未发送 但是马上要发的

七、接收端缓存 三部分

1. 接收并且确认过的
2. 还没接收 但马上可以接收
3. 不能接收
   

八、顺序问题和丢包问题

1. 确认与重发机制
   方法一、超时重试 对每一个发送了 但是没有ACK的包 都设定一个定时器，超过一定时间就重新尝试发送。时间周期的设定是通过采样RTT的时间 并且会经过网络状态的变化而变化，没超时重传一次就会将定时器的时间加倍 这样网络不好的情况下就不会频繁重发
   方法二、当接收方 收到一个序号大于下一个所期望的报文段时 例如 6 和 8都收到了 但是就是没有7 这时就会发送6的ACK 要求下一个是7 当客户端收到3个重复的ACK 就会发现7确实丢了 不等超时 马上重发。
   方法三、SACK 需要在TCP头里 加上缓存地图 例如ACK6 SACK8 SACK9 这样唯独缺7 发送发立马就知道7丢了。

九、流量控制 rwnd

防止把对方的缓冲区填满

1. 每次确认包的时候 会携带一个窗口大小
2. 如果接收方处理很慢一直不处理 那么接收方的滑动窗口就会变得越来越小 如果是0 那么发送方就不会再发了 而是会发送窗口探测包 看看有没有机会调整窗口大小 ，接收方也并不会一有窗口就更新 防止很快窗口又被填满 一般为缓冲区的一半以上。

十、拥塞控制 cwnd

防止把网络塞满 防止包丢失和超时重传

1. 拥塞窗口控制 在一开始一次只能发送一个包 当一个确认段来了之后 就加一 这是可以发送2个 当两个确认段发送回来时 就加2 这样是指数增长 涨到什么时候是个头呢 又一个值 ssthresh 为65535 超过这个值的时候就要小心一点了。每次增加就要慢一点了 比如有8个确认包 那么每次增长就变成原来的1/8 这样就变成了线性增长。但总归是增长 总有一天会水满则溢。
2. 拥塞的表现形式 丢包 超时重传 这时将cwnd变成原来的1/2 将cwnd 设置为 1 重新开始慢启动 一下回到解放前。这种方式会导致快速重传 立刻变成慢速 会导致网络卡顿
3. 快速重传算法 当发送前一个包3次ACK时 于是发送端就会快速重传 不必等超时再传。TCP认为这种情况不严重不会将窗口设置为 1 而是 原来的1/2 在这个基础上再逐渐增加 线性增长
4. 问题 1: 丢包并不代表通道满了 这时降低速度是不对的
5. 问题 2：要等中间设备都填满了 才会丢包 从而降低速度发送速度

Socket

Socket 是端到端的通信 因此也只能设置 网络层和传输层的参数 指定是 IPv4 还是 IPv6 分别对应AF_INET 和 AF_INET6 是TCP（基于数据流的）还是UDP（基于数据段的） 分别对应 SOCK_STREAM和SOCK_DGRAM

一、基于TCP的 Socket 函数调用过程

1. 服务端去监听一个端口 调用bind函数 给这个socket赋予一个IP地址和端口，当一个网络包来的时候 内核要通过TCP头里的端口 找到应用程序，一个机器可以安装多个网卡 每个网卡都有一个ip地址 可以监听所有的IP地址也可以监听某一个IP地址 这样只有发给这个网卡的网络包才会给到这个应用程序。当服务端有了IP地址和端口 就可以调用listen函数进行监听 客户端这时就可以发起链接了。
2. 在内核中 一个Socket维护两个队列 一个是已经建立了链接的队列 这时候三次握手已经完毕，处于 established 状态。一个时还没有完全建立连接的队列 这个时候三次握手还没有完成 处于 syn_rcvd状态。接下来 服务端调用accept函数 拿出一个已经完成的连接进行处理 还没有完成的 就要等待。
3. 客户端可以通过 connect 函数发起链接 先在参数中指明要链接的IP地址和端口号 然后发起三次握手 内核会给客户端临时分配一个端口 一旦握手成功 服务端accept 就会返回另一个Socket。
4. 连接建立成功后 双方开始通过read/write函数开始读写数据
5. TCP的Socket 是一个文件流 只不过这个文件不是存在硬盘中的 而是存在内存中的。

二、给予UDP的Socket 程序函数调用过程

1. 对于UDP来讲 UDP不需要连接 所以不需要三次握手 也不需要listen和connect
2. 需要有端口号和IP地址 调用bind 不需要为每对连接建立一个Socket 而是只要有一个Socket 就能够和多个客户端通信 。
3. 限制 ： 服务器在一个固定的端口上监听 等待连接。由于文件描述符限制和内存限制 导致一台机器的Socket连接最大数也有限制。
4. IO多路复用 一个线程维护多个Socket 通过注册callback函数的方式 当某个文件描述符发生变化的时候 就会主动通知