DNS

使用UDP 53端口

多路复用和多路分解

无连接运输UDP

UDP无需建立连接，速度快

无连接状态，不需要维护序列号，可以支持更多用户活跃（游戏服务器）

首部只有8个字节，源端口号和目的端口号，长度和check sum

为什么需要checksum校验和：

• 在路由器内存中可能有bit差错
• 链路传输不可靠

checksum最终为1111111…则可能无差错

端到端原则：某种功能应该在较高级别提供，在较低级别上设置该功能可能会冗余

UDP只能检查错误，不能纠错

DNS服务采用UDP

何时UDP，何时TCP？

• 不希望延迟报文的发送，TCP有拥塞控制机制，并容忍数据的丢失

可靠数据传输

差错检测

接收方反馈：

• ACK肯定确认
• NAK否定确认

ACK 0接收成功，ACK 1接收失败

重传，收方发现差错，发送方重传

序号，检测哪个数据包出错进行重传

数据包可靠传输：

• 在没有ack的情况下，等待一定的时间后进行重传
• 序号可以保证传输不冗余（接收方检测是否冗余）

发送方需要实现：

• 没发送或者重传一个分组，启动定时器countdown timer
• 定时器过期后响应
• 终止定时器

流水线可靠传输协议：

• 采用极小的数据包，接收方收到最后一bit立即ack

GBN协议（回退N步），滑动窗口协议

限制数据包的序号，直到相应序号ack之后再发送后续的序号，用长度为N的窗口控制。

GBN发送方：

• 发送数据包时，检查发送窗口，未满则返回未发送的分组
• 收到ack后，对分组中的序号累积确认，表明接收方，正确接收到序号为n的分组以及以前的所有分组，[0, N]
• 超时，发送方重传所有未被确认的分组

接收方收到的分组都是有序的，如果出现无序，会丢弃后面的数据包，等待重传

选择重传

避免不必要的重传

发送方接收方都维护一个窗口

发送方：

• 收到send base后窗口右移到第一个没确认的分组处
• 接收ack将窗口内分组标记为ack
• 定时器防止分组丢失

接收方：

• 接收的分组落在窗口内，返回ack
• 如果序号不连续，直接缓存
• 如果分组序号等于rcv_base将从rcv base开始的已缓存分组交付给上层，窗口移动
• 序号落在窗口之外，[rcv_base-N, rcv_base-1]上一个窗口中，返回ack

窗口长度不能太大

TCP

运行与端系统中，路由器等视角下看到的是数据报

全双工

socket是对tcp协议的封装

流量控制

每一方都设置接收缓存，数据先放在缓存中，应用程序从缓存中读取数据。

目的是消除发送方使接收方缓存溢出的可能。匹配发送方和接收方的读写速率。

收发各自维护接收窗口。保存接收方还有多少缓存空间rwnd。

发送方维持为确认的数据量在rwnd之内。

如果剩余空间为0，发送方发送只有一个字节的报文。

UDP没有流量控制，因此可能会出现缓冲区溢出。

三次握手

1. 客户端发送SYN=1，随机选择一个序列号seq=x
2. 服务器读取该报文，为tcp连接分配资源，对客户端发送SYN=1，ack=x+1，seq=y（随机选取）
3. 客户端为该连接分配资源（缓存和变量），发送SYN=0，ack=y+1，seq=x+1

为什么三次？ 确保双方的收发能力都是正常的最小次数。

握手能不能携带数据？ 第一二次握手不能携带数据，第三次握手可以携带数据

四次挥手

1. 客户端发送FIN=1
2. 服务器响应ACK
3. 服务器发送FIN=1
4. 客户端发挥ACK

拥塞控制

丢包的原因？

• 网络堵塞后，路由器缓存溢出

方法：

• 慢启动
• 快速重传
• 拥塞避免
• 快速恢复