TCP/UDP [Part II]

UDP: 首部8字节

UDP数据格式

TCP:

报文格式

1. 序号：在一个TCP连接中传送的字节(byte)流中的每一个字节都按顺序编号.
   例如，一报文段的序号字段值是301，而携带的数据共有100字节。这就表明：本报文段的数据的第一个字节的序号是301，最后一个字节的序号是400
2. 确认号：
   其序号字段值是501，而数据长度是200字节（序号501～700），这表明B正确收到了A发送的到序号700为止的数据。因此，B期望收到A的下一个数据序号是701
3. 数据偏移：需要再仔细阅读
4. 窗口：发送本报文段一方的接受窗口

6个控制位:

1. ACK: ACK=1时，确认号才有用
2. PSH: 跳过缓存，直接让应用层处理
3. RST: RST=1表明TCP中出现严重差错 [需重新建立连接]
4. SYN: SYN=1 & ACK=0则为请求连接报文 | SYN=1 & ACK=1则为接受连接请求报文

5. FIN: FIN=1， 发送方数据发送完毕，请求释放运输连接

   
   
   TCP报文段的首部格式

• 可靠传输
• 流量控制
• 拥塞控制

socket: IP + Port

协议：

1. 停止等待协议 [自动重传请求ARQ (Automatic Repeat reQuest)]

就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组

停止等待协议

• A在发送完一个分组后，必须暂时保留已发送的分组的副本
• 分组和确认分组都必须进行编号
• 超时计时器设置的重传时间应当比数据在分组传输的平均往返时间更长一些
  缺点： 信道利用率低

2. 连续ARQ协议 和 滑动窗口协议
   Note: 接收方一般都是采用累积确认的方式，对按序到达的最后一个分组发送确认
   Pro: 容易实现，即使确认丢失，但是还可以等待下一个分组的确认，来使对方知道前面的分组都已经收到了
   Con: 不能向对方实时反映已收到的分组信息。譬如第三个分组丢失了，就会被卡在这里，知道超时。发送方又得从丢失的分组起全发一遍。