1. 引言

如何解决通信媒介可能会丢失或者改变被传递的消息？

• 差错校验

• 尝试重新发送，直到信息最终被接收。自动重复请求(ARQ,Automatic Repeat Request)

  1.1 ARQ和重传

  多跳通信会碰到的问题：

• 分组重新排序

• 分组复制
• 分组丢失

ARQ 如何判断重发的分组已经被正确接收?

• 接收方是否已经收到分组
• 接收方收到的分组是不是与之前发送的一样

ACK发送与等待ACK的过程有什么问题？

• 发送方对于一个ACK应该等待多久？
• ACK丢失怎么办？
  • 再次发送===》接收方可能会收到>=2个相同的TCP报文
  • TCP报文有序列号，如果报文序列号已经出现过，则丢弃
• 分组被接收，但是有错怎么办？
  • 差错校验

停等协议

发送方发送一个分组，停下来直到它收到该分组的ACK

同时发送多个分组的问题：

• 发送多少个
• 保存未收到ACK的分组的副本，以防重传
• 接收方
  • 哪些分组已收到，哪些未收到
  • 乱序到达
  • 接收方的接收速率比发送慢(中间的路由器也会有速率问题)

1.2 分组窗口和滑动窗口

1.3 变量窗口：流量控制和拥塞控制

接收方相对发送方太慢，需要强迫发送发慢下来====》》

流量控制

两种方式

• 基于速率

给发送方指定某个速率，发送方永远不能超过这个速率

• 基于窗口

接收方需要通知发送方使用多大的窗口====》》》 窗口通告，窗口更新(名词)

拥塞控制

流量控制可以很好地保护接收方，但是对于中间的路由节点呢？
即使发送方的速率达到了接收方的要求，还是有可能超过中间某个路由器的能力，从而导致丢包
===》》 需要拥塞控制

发送方需要猜测自己需要慢下来

1.4 设置超时重传

要等待多久才能判定一个分组已丢失并重发

往返时间(round-trip-time)：

• 发送分组所用时间
• 接收方处理时间
• 发送一个ACK所用时间
• ACK返回到发送方所用的时间
• 发送方处理ACK的时间

这个时间是需要估计的

选择一组RTT样本的均值作为真实RTT,这个均值会随时间而改变

2. TCP的引入

2.1 TCP服务模型

• 面向连接
• 可靠的

  2.2 TCP中的可靠性

  分组的序列号实际代表了每个分组第一个字节在整个数据流中的字节偏移，而不是分组号

3. TCP头部和封装

TCP分组封装在IP数据报中

TCP头部：

为什么TCP报文要带端口号，因为TCP报文是一个进程传给另一个进程的，端口号识别进程 端到端的另一种解读233333333333

因为每一个被交换的字节都已编号
ACK包含的值是该确认号的发送方期待接收的下一个序列号
即最后被成功接收的数据字节的序列号+1